データパケット損失の補償のためのクライアントとシステム、及びその方法
【課題】データパケット損失の補償のためのクライアントとシステム、及びその方法を提供する。
【解決手段】サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、クライアントがデータパケットを受信するステップと、受信されたデータパケットの補償如何を決定するステップと、データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、補償するデータパケットを受信してパケットを再整列するステップと、を含むことを特徴とするデータパケットの補償方法である。また、データパケットの補償要請があるか否かを判断するステップと、データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で補償要請したクライアントへ損失したデータパケットを伝送するステップとを含む。
【解決手段】サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、クライアントがデータパケットを受信するステップと、受信されたデータパケットの補償如何を決定するステップと、データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、補償するデータパケットを受信してパケットを再整列するステップと、を含むことを特徴とするデータパケットの補償方法である。また、データパケットの補償要請があるか否かを判断するステップと、データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で補償要請したクライアントへ損失したデータパケットを伝送するステップとを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）マルチキャストに係り、特にＩＰマルチキャストで損失されたデータパケットを補償するための装置及び方法に関する。
【背景技術】
【０００２】
インターネット上で、サーバーコンピュータ（以下、サーバーと称する）からクライアントコンピュータ（以下、クライアントと称する）へデータパケットを伝送するためのルーティング技術には、エニーキャスト、ブロードキャスト、マルチキャスト、ユニキャストなどがある。
【０００３】
しかし、最近、ＩＰ ＴＶまたはインターネットＴＶの発達と共に、マルチキャスト技術が広く拡散されている。
【０００４】
マルチキャストとは、一つのソース（または、サーバー）から特定のマルチキャストグループに加入した複数のクライアントに同時に同じデータパケットを伝送する方式である。
【０００５】
多様な種類のマルチキャスト技術のうち最も広く使われる代表的なものが、ＩＰインフラに基づいたＩＰマルチキャストである。ＩＰマルチキャストによれば、まず、サーバーから特定のマルチメディアコンテンツを提供されようとするクライアントが集まって一つのマルチキャストグループを形成し、それらは、同じマルチキャストアドレス（または、ＩＰ目的地アドレス）を共有する。次いで、サーバーは、前記特定の目的地アドレスを含むデータパケットを一回のみインターネット上へ伝送する。その後には、ネットワーク上のルータが前記データパケットを複製して、前記マルチキャストグループに加入したクライアントへ伝送する。
【０００６】
ＩＰマルチキャスト技術による場合、大容量のマルチメディアコンテンツを同時に複数のクライアントへ伝送できるので、ユニキャストの場合に発生しうる情報渋滞現象を防止できるという長所がある。
【０００７】
しかし、ネットワーク環境の悪化や端末器の一時的な過負荷などの原因により、ＩＰマルチキャストサーバーから伝送したデータパケットの一部が損失（欠落または損傷）された場合、さらに、その損失されたパケットがＡ／Ｖデータの再生に必要なヘッダ情報を含むか、またはその他の重要なパケットである場合には、クライアントは、一定時間受信した映像や音響データを再生できなくなる。
【０００８】
これについての解決策として提示された従来技術としては、ＰＧＭ（Ｐｒａｇｍａｔｉｃ Ｇｅｎｅｒａｌ Ｍｕｌｔｉｃａｓｔ）などがある。かかる従来技術によれば、クライアントは、ユニキャストの方式でサーバーに連結して、損失したデータパケットの再伝送を要請する。しかし、伝送チャンネルの伝送率が高い場合には、損失したデータパケットの再伝送が困難であり、逆に損失したデータパケットの再伝送がサーバーの他のパケット伝送を妨害するという問題点がある。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、前記した従来技術の問題点を克服して、サーバーのデータ伝送を妨害せずにクライアントが損失したデータパケットを補償するための装置及び方法を提供するところにある。
【課題を解決するための手段】
【００１０】
前記目的を達成するために、本発明によるクライアントは、マルチメディアコンテンツを提供するサーバーから伝送されたデータパケットの損失如何をモニタリングするパケットモニタリングブロックと、前記パケットモニタリングブロックが損失されたデータパケットを発見した場合、他のクライアントに損失されたデータパケットの補償を要請するか、または他のクライアントからデータパケットの補償要請がある場合、前記補償要請を処理するための補償要請処理ブロックとを備えることを特徴とする。
【００１１】
前記目的を達成するために、本発明によるデータパケット損失補償システムは、マルチメディアコンテンツを提供するサーバーと、マルチキャストグループを構成する二つ以上のクライアントと、前記サーバー及び前記二つ以上のクライアントを電気的に連結するネットワークとを備え、前記クライアントのうち一部が、前記サーバーが伝送したデータパケットを損失した場合、他のクライアントから前記損失したデータパケットを補償されることを特徴とする。
【００１２】
前記目的を達成するために、本発明によるデータパケットの補償方法は、サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、前記クライアントがデータパケットを受信するステップと、前記受信されたデータパケットの補償如何を決定するステップと、データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、補償するデータパケットを受信してパケットを再整列するステップとを含むことを特徴とする。
【００１３】
前記目的を達成するために、本発明によるデータパケットの補償要請処理方法は、データパケットの補償要請があるか否かを判断するステップと、データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で、補償要請したクライアントへ損失したデータパケットを伝送するステップとを含むことを特徴とする。
【００１４】
前記目的を達成するために、本発明によるマルチキャストデータパケットは、ヘッダ部分及びデータ部分から構成されるデータパケットであって、前記ヘッダ部分は、再び連続性情報及びパケットの重要度情報を含むことを特徴とする。
【発明の効果】
【００１５】
本発明による場合、クライアントは、一時的にデータパケットを損失しても補償されるので、損失されたデータパケットによるＡ／Ｖデータの再生の中断を防止できる。
【００１６】
また、クライアントは、他のクライアントにより損失したデータパケットを補償されるため、サーバーのデータ伝送を妨害するという従来技術の問題点を解決する。
【発明を実施するための最良の形態】
【００１７】
以下、添付された図面を参照して、本発明による望ましい実施形態を説明する。
【００１８】
図１は、本発明によるデータパケットの損失補償のためのシステムの概要図である。
【００１９】
前記システムは、ストリーミングサービスを提供するためのサーバー１１及びクライアント１３，１４，１５を備え、前記サーバー及びクライアントは、ネットワーク１２（例えば、インターネット）を通じて電気的に連結される。また、前記システムは、ＩＰマルチキャスト技術を支援する。
【００２０】
サーバー１１は、クライアントに多様なマルチメディアコンテンツ（または、Ａ／Ｖデータパケット）をストリーミング方式で提供するが、代表的な例がＩＰ ＴＶサービス、画像会議サービスなどがある。
【００２１】
クライアントは、サーバーからデータパケットを受信するために、マルチキャストグループに加入する。正確に言えば、クライアントは、二つのマルチキャストグループに加入するが、そのうち一つは、サーバーからデータパケットの受信のためのマルチキャストグループであり、他の一つは、前記データパケットを損失した場合、それを補償するためのマルチキャストグループである。しかし、一般的に、後者の構成メンバーは、前者の構成メンバーと同一である。また、一般的に、前記マルチキャストグループに類似したＩＰアドレスが割り当てられる（例えば、２２４．０．０．１及び２２４．０．０．２）。
【００２２】
前記サーバーとクライアントとを連結するネットワークの一例として、ＩＰ基盤のインターネットが挙げられる。
【００２３】
図２は、本発明によるパケット損失補償装置及び方法を支援するためのデータパケットの構造を示す図である。図２のａは、サーバーからマルチキャストグループに属したクライアントへ伝送されるマルチキャストデータパケットの構造を示す。前記マルチキャストパケットは、ヘッダ部分２１及びデータ部分２２を備える。
【００２４】
図２のｂは、図２のａのパケットのさらに詳細な構成を示す。
【００２５】
ヘッダ部分２１は、さらに連続性情報２１１及びパケットの重要度情報２１２を含む。ヘッダ部分２１がＲＴＰ（Ｒｏｕｔｉｎｇ Ｔａｂｌｅ Ｐｒｏｔｏｃｏｌ）ヘッダである場合、ＲＴＰヘッダは、総１２バイトで構成されるが、前記１２バイトのうち空いているバイトに前記連続性情報及びパケットの重要度情報を挿入する。
【００２６】
連続性情報とは、連続される一連のデータパケットに与えられる順序であって、一定な周期を有して反復される（例えば、１−２−３....−Ｎ−１−２−....）。また、パケットの重要度情報とは、パケットが損失された場合、その補償如何を表示する情報である。重要度情報の一例として、パケットの種類を使用できる。すなわち、損失されたパケットの種類がＡ／Ｖデータの再生のためのヘッダ、その他の重要なデータを含むものであるときは、前記システムは、損失されたパケットを補償するものである。この場合、重要度情報は、現在のパケットの種類及び次のパケットの種類を含むか、または現在のパケットの種類及び以前のパケットの種類を含む。
【００２７】
データ部分２２は、さらにヘッダデータ及び／またはＡ／Ｖデータを備える。ヘッダデータとは、前記Ａ／Ｖデータの再生に必要な情報である。
【００２８】
図２のｃは、一周期のデータパケットを連続性情報によって配列したものである。各パケットには、その順序によって１からＮまでの連続的な番号が付与される。前記Ｎの値は、クライアントのメモリのサイズ、システムの要請処理速度、パケット損失の程度、パケット伝送速度などを考慮して、適切な大きさの値を決定する（例えば、Ｎ＝ＦＦ）。
【００２９】
図３は、本発明による損失パケット補償システムを構成するクライアントの詳細な構造を示す図である。
【００３０】
クライアント１３，１４，１５は、それぞれメインブロック１３１，１４１，１５１、パケットモニタリングブロック１３２，１４２，１５２、補償要請処理ブロック１３３，１４３，１５３及び送／受信ブロック１３４，１４４，１５４を備える。
【００３１】
メインブロックは、前記サーバーや他のクライアントから受信したパケットの属性を把握する。すなわち、送／受信ブロックを通じて受信したパケットがデータパケット、フラッグ除去要請パケット、パケット補償要請パケットのうちいずれかに該当するかを決定する。
【００３２】
パケットモニタリングブロックは、前記サーバーから受信した一連のデータパケットをモニタリングする。すなわち、データパケットのヘッダ部分に含まれた連続性情報を利用してパケットの損失如何を決定し、もし、一部のパケットが損失されたものと決定されれば、その損失されたパケットの以前のパケット（または、次のパケット）のパケット重要度情報を調べて、損失されたパケットがヘッダデータなどの重要データを含んでおり、パケット補償を要請する必要があるか否かを判断する。
【００３３】
補償要請処理ブロックは、そのブロックを含んだクライアントがパケットを損失したか否かによってその役割が変わる。
【００３４】
すなわち、パケットを損失したクライアントの補償要請処理ブロックは、データパケット損失を補償するための要請を、送／受信部ブロックを通じてマルチキャストグループ内の他のクライアントへ伝送する。
【００３５】
一方、他のクライアントの補償要請処理ブロックは、前記補償要請に対応して伝送衝突が発生しない方式で、送／受信部ブロックを通じて前記損失されたパケットを、前記データパケットを損失したクライアントへ伝送する。
【００３６】
その他にも、前記クライアントは、受信したデータパケットを保存するためのバッファ（または、パケットプール）、保存部（例えば、ＲＯＭ、ＲＡＭなど）及び補償フラッグなど（図示せず）を備える。
【００３７】
図４は、本発明によるデータパケットの損失補償方法の動作を示すフローチャートである。
【００３８】
ステップ４１では、二つ以上のクライアントがマルチキャストグループに加入する。
【００３９】
サーバーからデータパケット（または、マルチメディアコンテンツ）を受信しようとする二つ以上のクライアントが集まって、一つのマルチキャストグループを形成する。前記クライアントに同じマルチキャストアドレスが付与される。
【００４０】
ステップ４２では、クライアントがデータパケットを受信する。サーバーは、特定のマルチキャストアドレス、連続性情報、パケット重要度情報などを含むデータパケットを前記ネットワークへ伝送する。ステップ４１でマルチキャストグループに加入したクライアントが前記データパケットを受信する。これと共に、それぞれのクライアントは、受信したデータの再生のために特定量のデータパケットをバッファリングする。バッファリングされるデータパケットの量は、伝送チャンネルの伝送速度、バッファの容量などを考慮して決定される。
【００４１】
ステップ４３で、それぞれのクライアントは、データパケットの補償が必要であるか否かを判断する。
【００４２】
まず、クライアントが受信したデータパケットのヘッダに含まれたパケットの連続性情報を調べて、パケットの連続性如何を判断する。
【００４３】
以下、説明の便宜のために第１クライアント１３が受信したデータパケットのうち一部が損失されたと仮定する。
【００４４】
もし、第１クライアント１３へ伝送された一部のパケット（例えば、図２の三番目のパケット）が損失（損傷または欠落）されれば、第１クライアント１３は、再び損失されたパケットの以前のパケット（または、次のパケット）のヘッダを調べて、損失されたパケットの種類を調べる。調査結果、もし、損失されたパケットがＡ／Ｖデータの再生に必要な情報（ヘッダデータなど）を含んだ重要なものであれば、第１クライアント１３は、ステップ４３を行うが、そうでない場合には、再びステップ４２に戻る。
【００４５】
ステップ４４は、損失したデータパケットを補償されるために、補償要請パケット（以下、補償要請と称する）を伝送するステップである。第１クライアント１３は、補償要請をマルチキャストグループに属する他のクライアント１４，１５へ伝送する。前記補償要請は、第１クライアント１３が損失したデータパケットの連続性番号などを含む。
【００４６】
ステップ４５は、補償要請を処理するステップである。第１クライアント１３から補償要請を受けたクライアント１４，１５が、伝送衝突を回避する方式で第１クライアントへ損失されたデータパケットを伝送するステップである。このステップについては、今後図５を参照してさらに詳細に説明する。
【００４７】
ステップ４６は、パケットの順序を再整列するステップである。第１クライアント１３は、他のクライアント１４または１５からデータパケットを受信して、そのパケットの連続性番号を参照してバッファリングされた他のデータパケット（パケットプール）の間に挿入する。
【００４８】
これにより、損失されたデータパケットの補償手順が完了する。
【００４９】
図５は、図４の補償要請処理ステップ４５のさらに具体的な動作を示すフローチャートである。
【００５０】
図４と同様に、第１クライアント１３がデータパケットを損失し、他のクライアント１４，１５がその損失されたパケットを補償すると仮定する。
【００５１】
ステップ５１では、他のクライアント１４，１５が伝送チャンネルを観察して、第１クライアント１３から補償要請があるか否かを判断する。各クライアントは、保存部（図示せず）に一周期Ｎのパケットを保存する。前記保存部は、ＲＡＭ、ＲＯＭなどで構成され、損失されたデータパケットの補償に対応してデータパケットを保存する。
【００５２】
第１クライアント１３から補償要請があると判断された場合、第２クライアント１４及び第３クライアント１５は、それぞれ自身の補償フラッグを設定する（ステップ５２）。しかし、補償要請がない場合には、クライアントは、自身が受信したパケットを処理し、次いで、伝送チャンネルを観察する（ステップ５１）。
【００５３】
ステップ５３は、他のクライアント１４，１５が任意の時間を待機するステップである。補償要請を受けたクライアントは、第１クライアント１３から要請されたパケットを伝送する前に、任意の時間を待機する。その理由は、補償要請を受けた他のクライアントとの伝送衝突を防止するためである。このために、クライアントは、任意の数字を生成するステップをさらに含み、その生成された数字に対応する任意の時間を待機する。以下、第２クライアント１４の待機時間（または、任意時間）は、第３クライアント１５の待機時間よりさらに短いと仮定する。
【００５４】
ステップ５４では、任意の待機時間を待機したクライアント１４，１５は、他のクライアントから補償フラッグ除去要請があるか否かを判断するステップである。
【００５５】
第２クライアント１４の待機時間は、第３クライアント１５の待機時間より短いので、第２クライアント１４は、第３クライアント１５からフラッグ除去要請を受けていない。
【００５６】
したがって、第２クライアント１４は、第３クライアント１５にフラッグ除去を要請する（ステップ５５）。次いで、第２クライアントは、第１クライアント１３が損失したパケットに対応するパケットを自身の保存部から読み取って第１クライアント１３へ伝送する（ステップ５６）。
【００５７】
一方、第３クライアント１５の待機時間は、第２クライアント１４の待機時間より長いので、第３クライアント１５は、第２クライアント１４から補償フラッグ除去要請を受ける。第３クライアント１５は、前記ステップ５２で設定したフラッグを除去する（ステップ５７）。
【００５８】
本発明による方法は、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムにより読み取られるデータが保存されるあらゆる種類の記録装置を含む。コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ（リードオンリメモリ）、ＲＡＭ（ランダムアクセスメモリ）、ＣＤ−ＲＯＭ、磁気テープ、ハードディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、光データ保存装置などがあり、またキャリアウェーブ（例えば、インターネットを通じた伝送）の形態で具現されるものも含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なコードが保存されて実行されうる。
【００５９】
これまで、本発明について、その望ましい実施形態を中心に述べた。当業者は、本発明が、本発明の本質的な特性から逸脱しない範囲で変形された形態に具現可能であるということを理解できるであろう。したがって、開示された実施形態は、限定的な観点ではなく、説明的な観点で考慮されねばならない。本発明の範囲は、前述した説明ではなく、特許請求の範囲に表れており、それと同等な範囲内にあるあらゆる相違点は、本発明に含まれていると解釈されねばならない。
【産業上の利用可能性】
【００６０】
本発明は、ＩＰマルチキャスト関連の技術分野に適用可能である。
【図面の簡単な説明】
【００６１】
【図１】本発明によるデータパケットの損失補償のためのシステムの概要図である。
【図２】本発明によるパケット損失補償装置及び方法を支援するためのデータパケットの構造を示す図である。
【図３】本発明によるパケット損失補償システムを構成するクライアントの詳細な構造を示す図である。
【図４】本発明によるデータパケットの損失補償方法の動作を示すフローチャートである。
【図５】図４の補償要請処理ステップ４５のさらに具体的な動作を示すフローチャートである。
【符号の説明】
【００６２】
１１ サーバー
１２ ネットワーク
１３，１４，１５ クライアント
１３１，１４１，１５１ メインブロック
１３２，１４２，１５２ パケットモニタリングブロック
１３３，１４３，１５３ 補償要請処理ブロック
１３４，１４４，１５４ 送／受信ブロック
【技術分野】
【０００１】
本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）マルチキャストに係り、特にＩＰマルチキャストで損失されたデータパケットを補償するための装置及び方法に関する。
【背景技術】
【０００２】
インターネット上で、サーバーコンピュータ（以下、サーバーと称する）からクライアントコンピュータ（以下、クライアントと称する）へデータパケットを伝送するためのルーティング技術には、エニーキャスト、ブロードキャスト、マルチキャスト、ユニキャストなどがある。
【０００３】
しかし、最近、ＩＰ ＴＶまたはインターネットＴＶの発達と共に、マルチキャスト技術が広く拡散されている。
【０００４】
マルチキャストとは、一つのソース（または、サーバー）から特定のマルチキャストグループに加入した複数のクライアントに同時に同じデータパケットを伝送する方式である。
【０００５】
多様な種類のマルチキャスト技術のうち最も広く使われる代表的なものが、ＩＰインフラに基づいたＩＰマルチキャストである。ＩＰマルチキャストによれば、まず、サーバーから特定のマルチメディアコンテンツを提供されようとするクライアントが集まって一つのマルチキャストグループを形成し、それらは、同じマルチキャストアドレス（または、ＩＰ目的地アドレス）を共有する。次いで、サーバーは、前記特定の目的地アドレスを含むデータパケットを一回のみインターネット上へ伝送する。その後には、ネットワーク上のルータが前記データパケットを複製して、前記マルチキャストグループに加入したクライアントへ伝送する。
【０００６】
ＩＰマルチキャスト技術による場合、大容量のマルチメディアコンテンツを同時に複数のクライアントへ伝送できるので、ユニキャストの場合に発生しうる情報渋滞現象を防止できるという長所がある。
【０００７】
しかし、ネットワーク環境の悪化や端末器の一時的な過負荷などの原因により、ＩＰマルチキャストサーバーから伝送したデータパケットの一部が損失（欠落または損傷）された場合、さらに、その損失されたパケットがＡ／Ｖデータの再生に必要なヘッダ情報を含むか、またはその他の重要なパケットである場合には、クライアントは、一定時間受信した映像や音響データを再生できなくなる。
【０００８】
これについての解決策として提示された従来技術としては、ＰＧＭ（Ｐｒａｇｍａｔｉｃ Ｇｅｎｅｒａｌ Ｍｕｌｔｉｃａｓｔ）などがある。かかる従来技術によれば、クライアントは、ユニキャストの方式でサーバーに連結して、損失したデータパケットの再伝送を要請する。しかし、伝送チャンネルの伝送率が高い場合には、損失したデータパケットの再伝送が困難であり、逆に損失したデータパケットの再伝送がサーバーの他のパケット伝送を妨害するという問題点がある。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、前記した従来技術の問題点を克服して、サーバーのデータ伝送を妨害せずにクライアントが損失したデータパケットを補償するための装置及び方法を提供するところにある。
【課題を解決するための手段】
【００１０】
前記目的を達成するために、本発明によるクライアントは、マルチメディアコンテンツを提供するサーバーから伝送されたデータパケットの損失如何をモニタリングするパケットモニタリングブロックと、前記パケットモニタリングブロックが損失されたデータパケットを発見した場合、他のクライアントに損失されたデータパケットの補償を要請するか、または他のクライアントからデータパケットの補償要請がある場合、前記補償要請を処理するための補償要請処理ブロックとを備えることを特徴とする。
【００１１】
前記目的を達成するために、本発明によるデータパケット損失補償システムは、マルチメディアコンテンツを提供するサーバーと、マルチキャストグループを構成する二つ以上のクライアントと、前記サーバー及び前記二つ以上のクライアントを電気的に連結するネットワークとを備え、前記クライアントのうち一部が、前記サーバーが伝送したデータパケットを損失した場合、他のクライアントから前記損失したデータパケットを補償されることを特徴とする。
【００１２】
前記目的を達成するために、本発明によるデータパケットの補償方法は、サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、前記クライアントがデータパケットを受信するステップと、前記受信されたデータパケットの補償如何を決定するステップと、データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、補償するデータパケットを受信してパケットを再整列するステップとを含むことを特徴とする。
【００１３】
前記目的を達成するために、本発明によるデータパケットの補償要請処理方法は、データパケットの補償要請があるか否かを判断するステップと、データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で、補償要請したクライアントへ損失したデータパケットを伝送するステップとを含むことを特徴とする。
【００１４】
前記目的を達成するために、本発明によるマルチキャストデータパケットは、ヘッダ部分及びデータ部分から構成されるデータパケットであって、前記ヘッダ部分は、再び連続性情報及びパケットの重要度情報を含むことを特徴とする。
【発明の効果】
【００１５】
本発明による場合、クライアントは、一時的にデータパケットを損失しても補償されるので、損失されたデータパケットによるＡ／Ｖデータの再生の中断を防止できる。
【００１６】
また、クライアントは、他のクライアントにより損失したデータパケットを補償されるため、サーバーのデータ伝送を妨害するという従来技術の問題点を解決する。
【発明を実施するための最良の形態】
【００１７】
以下、添付された図面を参照して、本発明による望ましい実施形態を説明する。
【００１８】
図１は、本発明によるデータパケットの損失補償のためのシステムの概要図である。
【００１９】
前記システムは、ストリーミングサービスを提供するためのサーバー１１及びクライアント１３，１４，１５を備え、前記サーバー及びクライアントは、ネットワーク１２（例えば、インターネット）を通じて電気的に連結される。また、前記システムは、ＩＰマルチキャスト技術を支援する。
【００２０】
サーバー１１は、クライアントに多様なマルチメディアコンテンツ（または、Ａ／Ｖデータパケット）をストリーミング方式で提供するが、代表的な例がＩＰ ＴＶサービス、画像会議サービスなどがある。
【００２１】
クライアントは、サーバーからデータパケットを受信するために、マルチキャストグループに加入する。正確に言えば、クライアントは、二つのマルチキャストグループに加入するが、そのうち一つは、サーバーからデータパケットの受信のためのマルチキャストグループであり、他の一つは、前記データパケットを損失した場合、それを補償するためのマルチキャストグループである。しかし、一般的に、後者の構成メンバーは、前者の構成メンバーと同一である。また、一般的に、前記マルチキャストグループに類似したＩＰアドレスが割り当てられる（例えば、２２４．０．０．１及び２２４．０．０．２）。
【００２２】
前記サーバーとクライアントとを連結するネットワークの一例として、ＩＰ基盤のインターネットが挙げられる。
【００２３】
図２は、本発明によるパケット損失補償装置及び方法を支援するためのデータパケットの構造を示す図である。図２のａは、サーバーからマルチキャストグループに属したクライアントへ伝送されるマルチキャストデータパケットの構造を示す。前記マルチキャストパケットは、ヘッダ部分２１及びデータ部分２２を備える。
【００２４】
図２のｂは、図２のａのパケットのさらに詳細な構成を示す。
【００２５】
ヘッダ部分２１は、さらに連続性情報２１１及びパケットの重要度情報２１２を含む。ヘッダ部分２１がＲＴＰ（Ｒｏｕｔｉｎｇ Ｔａｂｌｅ Ｐｒｏｔｏｃｏｌ）ヘッダである場合、ＲＴＰヘッダは、総１２バイトで構成されるが、前記１２バイトのうち空いているバイトに前記連続性情報及びパケットの重要度情報を挿入する。
【００２６】
連続性情報とは、連続される一連のデータパケットに与えられる順序であって、一定な周期を有して反復される（例えば、１−２−３....−Ｎ−１−２−....）。また、パケットの重要度情報とは、パケットが損失された場合、その補償如何を表示する情報である。重要度情報の一例として、パケットの種類を使用できる。すなわち、損失されたパケットの種類がＡ／Ｖデータの再生のためのヘッダ、その他の重要なデータを含むものであるときは、前記システムは、損失されたパケットを補償するものである。この場合、重要度情報は、現在のパケットの種類及び次のパケットの種類を含むか、または現在のパケットの種類及び以前のパケットの種類を含む。
【００２７】
データ部分２２は、さらにヘッダデータ及び／またはＡ／Ｖデータを備える。ヘッダデータとは、前記Ａ／Ｖデータの再生に必要な情報である。
【００２８】
図２のｃは、一周期のデータパケットを連続性情報によって配列したものである。各パケットには、その順序によって１からＮまでの連続的な番号が付与される。前記Ｎの値は、クライアントのメモリのサイズ、システムの要請処理速度、パケット損失の程度、パケット伝送速度などを考慮して、適切な大きさの値を決定する（例えば、Ｎ＝ＦＦ）。
【００２９】
図３は、本発明による損失パケット補償システムを構成するクライアントの詳細な構造を示す図である。
【００３０】
クライアント１３，１４，１５は、それぞれメインブロック１３１，１４１，１５１、パケットモニタリングブロック１３２，１４２，１５２、補償要請処理ブロック１３３，１４３，１５３及び送／受信ブロック１３４，１４４，１５４を備える。
【００３１】
メインブロックは、前記サーバーや他のクライアントから受信したパケットの属性を把握する。すなわち、送／受信ブロックを通じて受信したパケットがデータパケット、フラッグ除去要請パケット、パケット補償要請パケットのうちいずれかに該当するかを決定する。
【００３２】
パケットモニタリングブロックは、前記サーバーから受信した一連のデータパケットをモニタリングする。すなわち、データパケットのヘッダ部分に含まれた連続性情報を利用してパケットの損失如何を決定し、もし、一部のパケットが損失されたものと決定されれば、その損失されたパケットの以前のパケット（または、次のパケット）のパケット重要度情報を調べて、損失されたパケットがヘッダデータなどの重要データを含んでおり、パケット補償を要請する必要があるか否かを判断する。
【００３３】
補償要請処理ブロックは、そのブロックを含んだクライアントがパケットを損失したか否かによってその役割が変わる。
【００３４】
すなわち、パケットを損失したクライアントの補償要請処理ブロックは、データパケット損失を補償するための要請を、送／受信部ブロックを通じてマルチキャストグループ内の他のクライアントへ伝送する。
【００３５】
一方、他のクライアントの補償要請処理ブロックは、前記補償要請に対応して伝送衝突が発生しない方式で、送／受信部ブロックを通じて前記損失されたパケットを、前記データパケットを損失したクライアントへ伝送する。
【００３６】
その他にも、前記クライアントは、受信したデータパケットを保存するためのバッファ（または、パケットプール）、保存部（例えば、ＲＯＭ、ＲＡＭなど）及び補償フラッグなど（図示せず）を備える。
【００３７】
図４は、本発明によるデータパケットの損失補償方法の動作を示すフローチャートである。
【００３８】
ステップ４１では、二つ以上のクライアントがマルチキャストグループに加入する。
【００３９】
サーバーからデータパケット（または、マルチメディアコンテンツ）を受信しようとする二つ以上のクライアントが集まって、一つのマルチキャストグループを形成する。前記クライアントに同じマルチキャストアドレスが付与される。
【００４０】
ステップ４２では、クライアントがデータパケットを受信する。サーバーは、特定のマルチキャストアドレス、連続性情報、パケット重要度情報などを含むデータパケットを前記ネットワークへ伝送する。ステップ４１でマルチキャストグループに加入したクライアントが前記データパケットを受信する。これと共に、それぞれのクライアントは、受信したデータの再生のために特定量のデータパケットをバッファリングする。バッファリングされるデータパケットの量は、伝送チャンネルの伝送速度、バッファの容量などを考慮して決定される。
【００４１】
ステップ４３で、それぞれのクライアントは、データパケットの補償が必要であるか否かを判断する。
【００４２】
まず、クライアントが受信したデータパケットのヘッダに含まれたパケットの連続性情報を調べて、パケットの連続性如何を判断する。
【００４３】
以下、説明の便宜のために第１クライアント１３が受信したデータパケットのうち一部が損失されたと仮定する。
【００４４】
もし、第１クライアント１３へ伝送された一部のパケット（例えば、図２の三番目のパケット）が損失（損傷または欠落）されれば、第１クライアント１３は、再び損失されたパケットの以前のパケット（または、次のパケット）のヘッダを調べて、損失されたパケットの種類を調べる。調査結果、もし、損失されたパケットがＡ／Ｖデータの再生に必要な情報（ヘッダデータなど）を含んだ重要なものであれば、第１クライアント１３は、ステップ４３を行うが、そうでない場合には、再びステップ４２に戻る。
【００４５】
ステップ４４は、損失したデータパケットを補償されるために、補償要請パケット（以下、補償要請と称する）を伝送するステップである。第１クライアント１３は、補償要請をマルチキャストグループに属する他のクライアント１４，１５へ伝送する。前記補償要請は、第１クライアント１３が損失したデータパケットの連続性番号などを含む。
【００４６】
ステップ４５は、補償要請を処理するステップである。第１クライアント１３から補償要請を受けたクライアント１４，１５が、伝送衝突を回避する方式で第１クライアントへ損失されたデータパケットを伝送するステップである。このステップについては、今後図５を参照してさらに詳細に説明する。
【００４７】
ステップ４６は、パケットの順序を再整列するステップである。第１クライアント１３は、他のクライアント１４または１５からデータパケットを受信して、そのパケットの連続性番号を参照してバッファリングされた他のデータパケット（パケットプール）の間に挿入する。
【００４８】
これにより、損失されたデータパケットの補償手順が完了する。
【００４９】
図５は、図４の補償要請処理ステップ４５のさらに具体的な動作を示すフローチャートである。
【００５０】
図４と同様に、第１クライアント１３がデータパケットを損失し、他のクライアント１４，１５がその損失されたパケットを補償すると仮定する。
【００５１】
ステップ５１では、他のクライアント１４，１５が伝送チャンネルを観察して、第１クライアント１３から補償要請があるか否かを判断する。各クライアントは、保存部（図示せず）に一周期Ｎのパケットを保存する。前記保存部は、ＲＡＭ、ＲＯＭなどで構成され、損失されたデータパケットの補償に対応してデータパケットを保存する。
【００５２】
第１クライアント１３から補償要請があると判断された場合、第２クライアント１４及び第３クライアント１５は、それぞれ自身の補償フラッグを設定する（ステップ５２）。しかし、補償要請がない場合には、クライアントは、自身が受信したパケットを処理し、次いで、伝送チャンネルを観察する（ステップ５１）。
【００５３】
ステップ５３は、他のクライアント１４，１５が任意の時間を待機するステップである。補償要請を受けたクライアントは、第１クライアント１３から要請されたパケットを伝送する前に、任意の時間を待機する。その理由は、補償要請を受けた他のクライアントとの伝送衝突を防止するためである。このために、クライアントは、任意の数字を生成するステップをさらに含み、その生成された数字に対応する任意の時間を待機する。以下、第２クライアント１４の待機時間（または、任意時間）は、第３クライアント１５の待機時間よりさらに短いと仮定する。
【００５４】
ステップ５４では、任意の待機時間を待機したクライアント１４，１５は、他のクライアントから補償フラッグ除去要請があるか否かを判断するステップである。
【００５５】
第２クライアント１４の待機時間は、第３クライアント１５の待機時間より短いので、第２クライアント１４は、第３クライアント１５からフラッグ除去要請を受けていない。
【００５６】
したがって、第２クライアント１４は、第３クライアント１５にフラッグ除去を要請する（ステップ５５）。次いで、第２クライアントは、第１クライアント１３が損失したパケットに対応するパケットを自身の保存部から読み取って第１クライアント１３へ伝送する（ステップ５６）。
【００５７】
一方、第３クライアント１５の待機時間は、第２クライアント１４の待機時間より長いので、第３クライアント１５は、第２クライアント１４から補償フラッグ除去要請を受ける。第３クライアント１５は、前記ステップ５２で設定したフラッグを除去する（ステップ５７）。
【００５８】
本発明による方法は、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムにより読み取られるデータが保存されるあらゆる種類の記録装置を含む。コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ（リードオンリメモリ）、ＲＡＭ（ランダムアクセスメモリ）、ＣＤ−ＲＯＭ、磁気テープ、ハードディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、光データ保存装置などがあり、またキャリアウェーブ（例えば、インターネットを通じた伝送）の形態で具現されるものも含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なコードが保存されて実行されうる。
【００５９】
これまで、本発明について、その望ましい実施形態を中心に述べた。当業者は、本発明が、本発明の本質的な特性から逸脱しない範囲で変形された形態に具現可能であるということを理解できるであろう。したがって、開示された実施形態は、限定的な観点ではなく、説明的な観点で考慮されねばならない。本発明の範囲は、前述した説明ではなく、特許請求の範囲に表れており、それと同等な範囲内にあるあらゆる相違点は、本発明に含まれていると解釈されねばならない。
【産業上の利用可能性】
【００６０】
本発明は、ＩＰマルチキャスト関連の技術分野に適用可能である。
【図面の簡単な説明】
【００６１】
【図１】本発明によるデータパケットの損失補償のためのシステムの概要図である。
【図２】本発明によるパケット損失補償装置及び方法を支援するためのデータパケットの構造を示す図である。
【図３】本発明によるパケット損失補償システムを構成するクライアントの詳細な構造を示す図である。
【図４】本発明によるデータパケットの損失補償方法の動作を示すフローチャートである。
【図５】図４の補償要請処理ステップ４５のさらに具体的な動作を示すフローチャートである。
【符号の説明】
【００６２】
１１ サーバー
１２ ネットワーク
１３，１４，１５ クライアント
１３１，１４１，１５１ メインブロック
１３２，１４２，１５２ パケットモニタリングブロック
１３３，１４３，１５３ 補償要請処理ブロック
１３４，１４４，１５４ 送／受信ブロック
【特許請求の範囲】
【請求項１】
マルチメディアコンテンツを提供するサーバーから伝送されたデータパケットの損失如何をモニタリングするパケットモニタリングブロックと、
前記パケットモニタリングブロックが損失されたデータパケットを発見した場合、他のクライアントに損失されたデータパケットの補償を要請するか、または他のクライアントからデータパケットの補償要請がある場合、前記補償要請を処理するための補償要請処理ブロックとを備えることを特徴とするクライアント。
【請求項２】
前記クライアントは、あらかじめマルチキャストグループに加入することを特徴とする請求項１に記載のクライアント。
【請求項３】
前記マルチキャストグループは、サーバーからデータパケットの受信のためのマルチキャストグループと、データパケットを損失した場合、それを補償するためのマルチキャストグループとを備えることを特徴とする請求項２に記載のクライアント。
【請求項４】
前記クライアントは、前記サーバーや他のクライアントから受信したパケットの属性を把握するためのメインブロックをさらに備えることを特徴とする請求項１に記載のクライアント。
【請求項５】
前記データパケットは、一定な周期を有する連続性情報及びパケットの重要度情報をさらに含むことを特徴とする請求項１に記載のクライアント。
【請求項６】
前記クライアントは、他のクライアントからパケット補償要請如何を表示するための補償フラッグをさらに備えることを特徴とする請求項１に記載のクライアント。
【請求項７】
前記クライアントは、データパケットの損失補償要請に対応して受信したデータパケットを保存するための保存部をさらに備えることを特徴とする請求項１に記載のクライアント。
【請求項８】
マルチメディアコンテンツを提供するサーバーと、
マルチキャストグループを構成する二つ以上のクライアントと、
前記サーバー及び前記二つ以上のクライアントを電気的に連結するネットワークと、を備え、
前記クライアントのうち一部が、前記サーバーが伝送したデータパケットを損失した場合、他のクライアントから前記損失したデータパケットを補償されることを特徴とするデータパケット損失補償システム。
【請求項９】
サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、
前記クライアントがデータパケットを受信するステップと、
前記受信されたデータパケットの補償如何を決定するステップと、
データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、
補償するデータパケットを受信してパケットを再整列するステップとを含むことを特徴とするデータパケットの補償方法。
【請求項１０】
前記データパケットの補償方法は、前記クライアントがマルチキャストグループに加入するステップをさらに含むことを特徴とする請求項９に記載のデータパケットの補償方法。
【請求項１１】
前記データパケットの補償方法は、クライアントがＡ／Ｖデータの再生のために複数のデータパケットをバッファリングするステップをさらに含むことを特徴とする請求項９に記載のデータパケットの補償方法。
【請求項１２】
前記データパケットの補償如何を決定するステップは、データパケットの損失如何を判断するステップと、損失されたパケットの重要度を判断するステップと、を含むことを特徴とする請求項９に記載のデータパケットの補償方法。
【請求項１３】
前記データパケットの損失如何を判断するステップは、受信したデータパケットに含まれた連続性情報を利用することを特徴とする請求項１２に記載のデータパケットの補償方法。
【請求項１４】
前記データパケットの重要度を判断するステップは、受信したデータパケットに含まれたパケット重要度情報を利用することを特徴とする請求項１２に記載のデータパケットの補償方法。
【請求項１５】
データパケットの補償要請があるか否かを判断するステップと、
データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で、補償要請したクライアントへ損失したデータパケットを伝送するステップとを含むことを特徴とするデータパケットの補償要請処理方法。
【請求項１６】
前記補償要請を受けたクライアントは、パケット補償要請の受信如何を表示するための補償フラッグを設定するステップをさらに含むことを特徴とする請求項１５に記載のデータパケットの補償要請処理方法。
【請求項１７】
前記補償要請を受けたクライアントは、伝送衝突を回避するためにそれぞれ任意時間を待機するステップを行うことを特徴とする請求項１５に記載のデータパケットの補償要請処理方法。
【請求項１８】
前記補償要請を受けたクライアントは、任意時間を待機した後、補償要請を受けた他のクライアントから補償フラッグの除去要請がない場合に限り、損失したデータパケットを補償要請したクライアントへ伝送することを特徴とする請求項１７に記載のデータパケットの補償要請処理方法。
【請求項１９】
前記補償要請を受けたクライアントは、任意時間を待機した後、補償要請を受けた他のクライアントから補償フラッグの除去要請がある場合には、補償フラッグを除去することを特徴とする請求項１７に記載のデータパケットの補償要請処理方法。
【請求項２０】
前記データパケットの補償方法は、クライアントがデータパケットの補償要請に備えて受信したデータパケットを保存するステップをさらに含むことを特徴とする請求項１５に記載のデータパケットの補償要請処理方法。
【請求項２１】
サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、
前記サーバーがデータパケットを伝送するステップと、
前記伝送されたデータパケットの補償如何を決定するステップと、
データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、
補償するデータパケットを受信してパケットを再整列するステップとを含むデータパケットの補償方法をコンピュータ上で行うためのコンピュータプログラムを保存した記録媒体。
【請求項２２】
データパケットの補償要請があるか否かを判断するステップと、
データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で、補償要請したクライアントへ損失したデータパケットを伝送するステップとを含むデータパケットの補償要請処理方法をコンピュータ上で行うためのコンピュータプログラムを保存した記録媒体。
【請求項２３】
ヘッダ部分及びデータ部分から構成されるデータパケットであって、前記ヘッダ部分は、再び連続性情報及びパケットの重要度情報を含むことを特徴とするマルチキャストデータパケット。
【請求項２４】
前記連続性情報及びパケット重要度情報は、前記データパケットの損失時に補償如何を判断するためのものであることを特徴とする請求項２３に記載のマルチキャストデータパケット。
【請求項２５】
前記パケット重要度情報は、現在または次のデータパケットの種類を表示することを特徴とする請求項２４に記載のマルチキャストデータパケット。
【請求項１】
マルチメディアコンテンツを提供するサーバーから伝送されたデータパケットの損失如何をモニタリングするパケットモニタリングブロックと、
前記パケットモニタリングブロックが損失されたデータパケットを発見した場合、他のクライアントに損失されたデータパケットの補償を要請するか、または他のクライアントからデータパケットの補償要請がある場合、前記補償要請を処理するための補償要請処理ブロックとを備えることを特徴とするクライアント。
【請求項２】
前記クライアントは、あらかじめマルチキャストグループに加入することを特徴とする請求項１に記載のクライアント。
【請求項３】
前記マルチキャストグループは、サーバーからデータパケットの受信のためのマルチキャストグループと、データパケットを損失した場合、それを補償するためのマルチキャストグループとを備えることを特徴とする請求項２に記載のクライアント。
【請求項４】
前記クライアントは、前記サーバーや他のクライアントから受信したパケットの属性を把握するためのメインブロックをさらに備えることを特徴とする請求項１に記載のクライアント。
【請求項５】
前記データパケットは、一定な周期を有する連続性情報及びパケットの重要度情報をさらに含むことを特徴とする請求項１に記載のクライアント。
【請求項６】
前記クライアントは、他のクライアントからパケット補償要請如何を表示するための補償フラッグをさらに備えることを特徴とする請求項１に記載のクライアント。
【請求項７】
前記クライアントは、データパケットの損失補償要請に対応して受信したデータパケットを保存するための保存部をさらに備えることを特徴とする請求項１に記載のクライアント。
【請求項８】
マルチメディアコンテンツを提供するサーバーと、
マルチキャストグループを構成する二つ以上のクライアントと、
前記サーバー及び前記二つ以上のクライアントを電気的に連結するネットワークと、を備え、
前記クライアントのうち一部が、前記サーバーが伝送したデータパケットを損失した場合、他のクライアントから前記損失したデータパケットを補償されることを特徴とするデータパケット損失補償システム。
【請求項９】
サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、
前記クライアントがデータパケットを受信するステップと、
前記受信されたデータパケットの補償如何を決定するステップと、
データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、
補償するデータパケットを受信してパケットを再整列するステップとを含むことを特徴とするデータパケットの補償方法。
【請求項１０】
前記データパケットの補償方法は、前記クライアントがマルチキャストグループに加入するステップをさらに含むことを特徴とする請求項９に記載のデータパケットの補償方法。
【請求項１１】
前記データパケットの補償方法は、クライアントがＡ／Ｖデータの再生のために複数のデータパケットをバッファリングするステップをさらに含むことを特徴とする請求項９に記載のデータパケットの補償方法。
【請求項１２】
前記データパケットの補償如何を決定するステップは、データパケットの損失如何を判断するステップと、損失されたパケットの重要度を判断するステップと、を含むことを特徴とする請求項９に記載のデータパケットの補償方法。
【請求項１３】
前記データパケットの損失如何を判断するステップは、受信したデータパケットに含まれた連続性情報を利用することを特徴とする請求項１２に記載のデータパケットの補償方法。
【請求項１４】
前記データパケットの重要度を判断するステップは、受信したデータパケットに含まれたパケット重要度情報を利用することを特徴とする請求項１２に記載のデータパケットの補償方法。
【請求項１５】
データパケットの補償要請があるか否かを判断するステップと、
データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で、補償要請したクライアントへ損失したデータパケットを伝送するステップとを含むことを特徴とするデータパケットの補償要請処理方法。
【請求項１６】
前記補償要請を受けたクライアントは、パケット補償要請の受信如何を表示するための補償フラッグを設定するステップをさらに含むことを特徴とする請求項１５に記載のデータパケットの補償要請処理方法。
【請求項１７】
前記補償要請を受けたクライアントは、伝送衝突を回避するためにそれぞれ任意時間を待機するステップを行うことを特徴とする請求項１５に記載のデータパケットの補償要請処理方法。
【請求項１８】
前記補償要請を受けたクライアントは、任意時間を待機した後、補償要請を受けた他のクライアントから補償フラッグの除去要請がない場合に限り、損失したデータパケットを補償要請したクライアントへ伝送することを特徴とする請求項１７に記載のデータパケットの補償要請処理方法。
【請求項１９】
前記補償要請を受けたクライアントは、任意時間を待機した後、補償要請を受けた他のクライアントから補償フラッグの除去要請がある場合には、補償フラッグを除去することを特徴とする請求項１７に記載のデータパケットの補償要請処理方法。
【請求項２０】
前記データパケットの補償方法は、クライアントがデータパケットの補償要請に備えて受信したデータパケットを保存するステップをさらに含むことを特徴とする請求項１５に記載のデータパケットの補償要請処理方法。
【請求項２１】
サーバーから二つ以上のクライアントにデータパケットを送信するにおいて、
前記サーバーがデータパケットを伝送するステップと、
前記伝送されたデータパケットの補償如何を決定するステップと、
データパケットの補償が必要な場合、他のクライアントにデータパケットの補償を要請するステップと、
補償するデータパケットを受信してパケットを再整列するステップとを含むデータパケットの補償方法をコンピュータ上で行うためのコンピュータプログラムを保存した記録媒体。
【請求項２２】
データパケットの補償要請があるか否かを判断するステップと、
データパケットの補償要請がある場合、補償要請を受けた他のクライアントとの伝送衝突を回避する方式で、補償要請したクライアントへ損失したデータパケットを伝送するステップとを含むデータパケットの補償要請処理方法をコンピュータ上で行うためのコンピュータプログラムを保存した記録媒体。
【請求項２３】
ヘッダ部分及びデータ部分から構成されるデータパケットであって、前記ヘッダ部分は、再び連続性情報及びパケットの重要度情報を含むことを特徴とするマルチキャストデータパケット。
【請求項２４】
前記連続性情報及びパケット重要度情報は、前記データパケットの損失時に補償如何を判断するためのものであることを特徴とする請求項２３に記載のマルチキャストデータパケット。
【請求項２５】
前記パケット重要度情報は、現在または次のデータパケットの種類を表示することを特徴とする請求項２４に記載のマルチキャストデータパケット。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００８−２２８２９０（Ｐ２００８−２２８２９０Ａ）
【公開日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願番号】特願２００８−４０５８６（Ｐ２００８−４０５８６）
【出願日】平成２０年２月２１日（２００８．２．２１）
【出願人】（３９００１９８３９）三星電子株式会社 (8,520)
【氏名又は名称原語表記】ＳＡＭＳＵＮＧ ＥＬＥＣＴＲＯＮＩＣＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】４１６，Ｍａｅｔａｎ−ｄｏｎｇ，Ｙｅｏｎｇｔｏｎｇ−ｇｕ，Ｓｕｗｏｎ−ｓｉ，Ｇｙｅｏｎｇｇｉ−ｄｏ ４４２−７４２（ＫＲ）
【Ｆターム（参考）】
【公開日】平成２０年９月２５日（２００８．９．２５）
【国際特許分類】
【出願日】平成２０年２月２１日（２００８．２．２１）
【出願人】（３９００１９８３９）三星電子株式会社 (8,520)
【氏名又は名称原語表記】ＳＡＭＳＵＮＧ ＥＬＥＣＴＲＯＮＩＣＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】４１６，Ｍａｅｔａｎ−ｄｏｎｇ，Ｙｅｏｎｇｔｏｎｇ−ｇｕ，Ｓｕｗｏｎ−ｓｉ，Ｇｙｅｏｎｇｇｉ−ｄｏ ４４２−７４２（ＫＲ）
【Ｆターム（参考）】
[ Back to top ]