JP2007507955A - パケット交換ネットワークを介したリアルタイム伝送用のメディアパケット構造 - Google Patents

Abstract

本発明は、メディアデータのブロック（BMD）を有するインセンシティブ部分（ISP）と、センシティブ部分（SP）とを有するメディアパケット構造を提案する。そのインセンシティブ部分はチェックサム（CS）により保護され、そのセンシティブ部分はそのインセンシティブ部分（ISP）に含まれるメディアデータのブロック（BMD）を訂正する誤り訂正コード（FEC）を有する。本発明を用いて、インセンシティブ部分に損傷を有するメディアパケットは拒否されず、誤り訂正コード（FEC）を使用して修復される。

Description

本発明は、ネットワークを介して伝送されるメディアパケット構造と、そのようなメディアパケットを送信する送信機と、そのようなメディアパケットを受信する受信機と、そのようなメディアパケットを送信する方法と、そのようなメディアパケットを受信する方法とに関する。

本発明は、インターネットでのメディアストリーミング又はブロードキャストに特に有用である。

インターネットのような交換パケットネットワークでのマルチメディアコンテンツのストリーミング又はブロードキャストが広まってきている。マルチメディアコンテンツは符号化され、パケット化され、ネットワークを介してメディアパケットとして伝送される。このようなアプリケーションは、無線伝送がメディアパケットのビット損失を引き起こす無線ネットワーク接続のような誤りの生じやすいネットワーク接続で実施されることがある。更に、ルータの輻輳がランダムなパケット損失を引き起こすことがある。

双方のアプリケーションは、例えばUser Datagram Protocol（UDP、RFC768）及びReal Time Protocol（RTP、RFC1889）のようなトランスポートネットワークプロトコルを有し、そのトランスポートネットワークプロトコルは、誤りが生じたときにメディアパケットを拒否し、任意選択で全メディアパケットの再送信を求める。

多すぎる再送信は、このようなリアルタイムアプリケーションの厳格な遅延要件に適合しないという問題がある。

2003年8月にIETF（Internet Engineering Task Force）により公開されたLarzon他によるインターネットドラフトは、UDP-Liteと呼ばれる新しいトランスポートプロトコルについて記載している。UDP-Liteは、UDP（RFC768）と類似しているが、誤りの生じやすいネットワーク環境で部分的に損傷したペイロードを破棄するのではなく配信する方を選ぶアプリケーションを提供する。UDP-Liteを使用して、パケットは、チェックサムによりカバーされるセンシティブ部分（sensitive part）と、チェックサムによりカバーされないインセンシティブ部分（insensitive part）とに構成される。インセンシティブ部分の誤りは、パケットが受信エンドホストのトランスポートレイヤにより破棄されることを引き起こさない。全パケットの損失を処理するよりペイロードの損失をうまく処理するように設計された音声及びビデオ用のコーデックでは有利になる。

しかし、損失データをネットワークで破棄するのではなく配信することから利益を受けるこの種類のアプリケーションは、必ずしも損失データを回復できるとは限らない。このような場合、表示されるデコード済マルチメディアコンテンツの品質が低下する。

本発明の目的は、損失マルチメディアをより良く修復する対策を提供することである。

このことは、メディアデータのブロックを有するインセンシティブ部分とセンシティブ部分とを有するメディアパケット構造により実現され、そのセンシティブ部分は、チェックサムにより保護され、そのセンシティブ部分は、そのインセンシティブ部分に含まれるメディアデータのブロックを訂正する誤り訂正コードを有する。

損失を受けると、本発明によるメディアパケットのインセンシティブ部分に含まれるメディアデータのブロックは、データパケットのセンシティブ部分に含まれる誤り訂正コードを使用して修復され得る。このような訂正は、ルータ、受信機又は何らかのネットワーク装置により実現されてもよく、誤り回復デコーダによる何らかの処理に先行する。従って、本発明を用いて、前訂正ステップが提供され、誤り回復デコーダにより受信された受信メディアビットストリームは、少ない誤りでデコーダに送信される。従って、誤り回復デコーダは、受信メディアデータをうまくデコードする大きな可能性を有する。このように、本発明によるメディアパケットの利点は、デコード済マルチメディアコンテンツの品質向上に寄与することである。

更に、本発明によるメディアパケットのセンシティブ部分で転送される誤り訂正コードは、信頼性のあるデータを構成する。実際に、ルータ又は受信機は、メディアパケットの送信前に、データパケットのセンシティブ部分のチェックサムが有効であることをチェックする。有効でない場合、全メディアパケットが拒否される。従って、受信機により受信された誤り訂正コードは有効であり、メディアデータの損傷の有効な訂正を可能にする。

このような誤り訂正コードの使用は、1999年12月にIETFにより公開され、“An RTP Payload Format for Generic Forward Error Correction”という題のJ.Rosenberg及びH.ShulzrinneによるRequest For Comment（RFC）2733の文献から既に知られている点に留意すべきである。このような文献は、前方誤り訂正コードを転送するパケットデータ構造を指定しており、これにより、損失したリアルタイムメディアデータの一般的な前方誤り訂正が可能になる。これらの前方誤り訂正コードは、Loss Erasure Code（LEC）とも呼ばれ、メディアパケットと同じストリームで送信されないパケットに送信者により入れられる。LECパケットは１つ以上のメディアパケットを訂正する前方誤り訂正コードを有する。受信機側で、LECパケット及び元のメディアパケットが受信される。メディアパケットが損失していない場合、LECコードは無視され得る。損失の場合には、LECパケットは受信された他のメディアパケット及びLECパケットと結合され、損失したメディアパケットの回復を生じる。

本発明によるメディアパケットの利点は、誤り訂正コードが回復されるメディアデータのブロックではなく同じメディアパケットに格納されるという点にある。従って、受信機側で関与する訂正手順は、損失メディアパケットに対応するLECパケットを検索する必要がないため、かなり簡単になる。

圧縮効率の理由で、LECパケットは通常では複数のメディアパケット（例えば10のメディアパケット）に関連する。しかし、誤り訂正コードを計算することに関与するアルゴリズムの複雑性は、訂正されるメディアデータのブロックのサイズと共に増加することが、当業者にわかる。本発明によるメディアパケット構造に格納される誤り訂正コードは、同じメディアパケットに格納されるメディアデータのブロックのみに関連する。従って、本発明を用いて、送信機、ルータ又は受信機側で関与するアルゴリズムの複雑性が低減される。

本発明の前記及び他の態様は、以下に説明する実施例から明らかになり、それを参照して説明する。

本発明について一例として添付図面を参照して詳細に説明する。

図１は、従来技術による通信システムを示す図である。このような通信システムは、送信機1（ソースホストとも呼ばれる）と、ネットワーク2と、受信機3（宛先ホストとも呼ばれる）とを有する。ネットワーク2は、如何なる種類のパケット交換ネットワークでもよく、好ましくはインターネットである。ネットワークは無線接続（例えば基地局から携帯電話のようなモバイル受信機まで）を有してもよい。

このようなネットワーク3は、レイヤのスタックとして構成され、それぞれ１つが下のものを基礎とする。各レイヤの目的は、上位レイヤに特定のサービスを提供することであり、提供されるサービスが実際にどのように実装されるかについての詳細からこれらのレイヤを隠蔽する。送信機のレイヤは、プロトコルにより規定される規則及び仕様に従って、受信機又はルータの対応するレイヤとの対話を伝える。

ネットワークプロトコルスタックの従来のモデルは、インターネットレイヤを有し、インターネットレイヤは、公式のIPパケットフォーマットとIP（Internet Protocol）と呼ばれるプロトコルとを規定する。インターネットレイヤの目的は、伝送することになっているIPパケットを配信することである。ネットワークプロトコルスタックは、インターネットレイヤの上にトランスポートレイヤを更に有し、ソースホストと宛先ホストとのピア・エンティティ（peer entity）が対話を伝えることを可能にする。トランスポートレイヤは、通常では以下の２つのエンド・ツー・エンド・プロトコルにより規定される。
−信頼性のないコネクションレス型プロトコルであるUDPプロトコル（User Datagram Protocol）
−リアルタイム特性を有するデータを運び、場合によってはサービス品質を監視するためにRTCP（Real Time Control Protocol）に関連するRTP（Real-Time Protocol9プロトコル
トランスポートレイヤはUDP及びRTP以外のプロトコルにより規定されてもよい点に留意すべきである。例えば、独自仕様のプロトコルが開発されている。より一般的に、携帯電話からハンドフリーのイヤホンまでのBluetoothでのオーディオ又はビデオストリーミングのような専用アプリケーション用に、独自仕様のネットワークプロトコルスタックモデルが実装されている。

Real-Timeアプリケーション以外のアプリケーションについて、RTPが信頼性のあるコネクション指向型プロトコルであるTCP（Transmission Control Protocol）により交換される点にも留意すべきである。TCPにより、ソースホストで生じたパケットストリームがインターネットの如何なる宛先ホストにも誤りなしに配信されることが可能になり、また、TCPは制御フローを扱う。TCPにより提供される制御フローはルータの輻輳を生じることがあり、そのルータの輻輳はルータレベルでランダムなパケットの拒否に導く。

図１を参照すると、送信機1は、音声又はビデオのようなマルチメディアコンテンツMMをメディアデータビットストリームMD_BSTRにエンコードするエンコーダMD_ENCを有する。ビデオコンテンツでは、例えばエンコーダMD_ENCはMPEG-4（Moving Picture Expert Group）又はH.264標準を実装する。ビデオコンテンツでは、例えばエンコーダMD_ENCはAMR（Advanced Multi Rate）標準を実装する。メディアデータビットストリームは、パケット化手段PACKによりメディアデータのブロックBMDに構成され、メディアデータのブロックBMDは、ネットワークプロトコルスタックにより規定されるように、送信ネットワークプロトコル手段TNPMによりメディアパケットMPに埋め込まれる。

図２ａは、ネットワークプロトコルスタックを実装した送信ネットワークプロトコル手段TNPMを示しており、それはインターネットを介したリアルタイムストリーミング又はブロードキャストアプリケーションに適用される。

送信機側で、ネットワーク3で送信されるメディアデータのブロックBMDは、まずRTPプロトコルにより処理され、そのRTPプロトコルはRTPヘッダRTP_HDとRTPペイロードRTP_PLDとを有するRTPパケットを生成する。RTPペイロードはメディアデータのブロックBMDにより形成され、RTPヘッダはRTPに関するメタデータ（例えばRTPペイロードを制御するシーケンス番号又はタイムスタンプ等）を有する。

得られたRTPパケットRTP_Pは、UDPプロトコルにより更に処理され、そのUDPプロトコルは、RTPパケットにUDPヘッダを追加することにより、UDPパケットUDP_Pを生成する。従って、UDPパケットは、UDPヘッダに続いて、UDPペイロードUDP_PLDを有する。UDPペイロードはRTPパケットを有し、UDPヘッダはメタデータ（ソースアドレス、宛先アドレス及びチェックサム等）を有する。

チェックサムは、UDPパケットにより運ばれるmビット（mは整数である）のシーケンスにおける誤りを検出するために使用される。有利には、多項式符号方法が使用される。送信機及び受信機は事前に生成多項式G(x)に合意しなければならない。多項式M(x)に対応するmビットのシーケンスのチェックサムを計算するために、mビットのシーケンスは生成多項式G(x)より長くなければならない。概念は、mビットのシーケンスに続いてチェックサムにより表される多項式がG(x)で割り切れるようになるように、チェックサムをmビットのシーケンスの最後に付加することである。受信機がmビットのシーケンスとチェックサムとを有するパケットを取得すると、それをG(x)で割ろうとする。剰余が存在する場合には、伝送誤りが存在している。この場合、UDPパケットはUDPプロトコルにより完全に拒否される。

ネットワーク2は、パケットPを指定の宛先にルーティングするために、いくつかのルータROUTを有してもよい。

受信パケットRPは受信機3により受信され、受信機3は、ネットワークプロトコルに規定されるようにメディアデータの受信ブロックを抽出する受信ネットワークプロトコル手段RNPMを有する。受信ネットワークプロトコル手段RNPMは、図２ａに示す送信ネットワークプロトコル手段NTPMと対称でもよい。受信パケットRJPにおいてチェックサムの誤りがUDPレイヤにより検出されると、受信パケットRJPが拒否される。

有効なパケットから生じたメディアデータの受信ブロックRBMDは、逆パケット化手段DEPACKにより逆パケット化され、その逆パケット化手段DEPACKは受信メディアデータストリームMD_BSTRをデコーダMD_DECに配信する。

以下では新しいプロトコルについて検討する。新しいプロトコルにより、部分チェックサム（すなわち、パケットの一部のみをカバーするチェックサム）を計算することが可能になる。このようなプロトコルは、例えばUDP-Liteプロトコル又はDCCP（Data Congestion Control Protocol）プロトコルであり、これらはまだ標準化されていない。

図２ｂは、センシティブ部分SPとインセンシティブ部分ISPとを有するUDP-Liteパケットを示しており、チェックサムCSはセンシティブ部分でのみ計算される。UDP-Liteプロトコルは、パケットのセンシティブ部分が有効であることのみをチェックする。従って、インセンシティブ部分に誤りを有するUDPパケットは、RTPプロトコルに送信され得る。

UDPプロトコルと異なり、UDP-Liteプロトコルは、損傷のあるパケットを拒否する代わりに、それを訂正することを可能にする。利点は、損傷のあるパケットのシステム的な再送信を回避する点である。

図３ａは、UDP-Liteヘッダの構造を示している。そのUDP-Liteヘッダは、既にUDPプロトコルにより使用されているソースアドレスSRCと宛先アドレスDESTとチェックサム値CSとのフィールドに加えて、センシティブ部分SPの長さを示すチェックサム対象フィールドCSCを有する。

UDP-Liteパケットのセンシティブ部分は従来ではUDP-Liteパケットの初めに入れられるが、部分チェックサムの使用を可能にする他のプロトコルが（例えばメディアパケットの終わりにあるセンシティブ部分SPを用いて）他のパケット構造を提供してもよい点に留意すべきである。

図３ｂは、本発明の第１の実施例によるメディアパケットを示している。このようなメディアパケットは、センシティブ部分SPと、インセンシティブ部分ISPとを有する。インセンシティブ部分は、メディアパケットにより転送されるメディアデータのブロックBMDを有する。センシティブ部分SPは、RTP及びUDP-LiteプロトコルによりメディアデータのブロックBMDに追加されたヘッダ（RTP_HD、UDP-L_HD）と、誤り訂正コードとを有する。その誤り訂正コードは、本発明によるデータパケットのインセンシティブ部分の潜在的な損傷を訂正するために使用されることを目的とする。

本発明はUDP-Liteプロトコルに限定されず、メディアパケットのリアルタイム伝送に採用されて部分チェックサムの使用を可能にする何らかのネットワークプロトコルに限定される点に留意すべきである。

本発明の第１の実施例では、このような誤り訂正コードは、前方誤り訂正コード（FECコードとも呼ばれる）である。1999年12月にIETFで公開され、“An RTP Payload Format for Generic Forward Error Correction”という題のJ.Rosenberg及びH.Schlzrinneによる文献Request For Comment（RFC）2733に記載されているように、FECコードは、パリティ、Reed-Solomon又はHammingコードのような従来の誤り訂正コードである。このようなFECコードの利点は、このようなFECコードを計算することに関与する計算アルゴリズムがXOR演算に低減され得るという点である。

本発明によるメディアパケットのセンシティブ部分SPに挿入される前方誤り訂正コードの長さは、FECコードのコストを表し、アプリケーションの要件にかなり依存する点に留意すべきである。メディアデータのブロックの損傷の部分的な訂正と比べて、完全な訂正には多くのFECコードが必要である。コストと効率との間でトレードオフが行われる必要がある。例えば、IPでの音声伝送の何らかのアプリケーションは、キーワード適応的FECコードを使用する。このようなキーワード適応的FECコードは、伝送状態が悪化した場合にのみ計算されて送信される。

有効なFECコードのみが受信機により受信され、メディアデータの受信ブロックRBMDで損傷を訂正するために使用されることを確保するために、FECコードは、本発明によるメディアパケット構造のセンシティブ部分SP内に配置される。

図３ｂでは、FECコードはRTPヘッダとメディアデータのブロックとの間に配置される。代替の配置は、UDPヘッダとRTPヘッダとの間である。より一般的には、FECコードは本発明によるデータパケットのセンシティブ部分の如何なる場所に配置されてもよい点に留意すべきである。

図４は、本発明の第１の実施例に従ってデータパケットを送信する送信機を機能的に示している。その送信機は、メディアビットストリームMD_BDTRをメディアデータのブロックBMDに構成するパケット化器10を有し、各ブロックはメディアパケットに入れられることになる。メディアデータのブロックBMDは、FEC計算手段11により更に処理され、そのFEC計算手段11は、メディアデータのブロックBMDの一部又は全体を訂正するFECコードを計算することを目的とする。前記の文献に記載されているように、メディアデータの損傷ブロックの訂正に適用されるFECコードを計算することに関与するアルゴリズムは、複数の受信メディアデータパケットの中から１つのメディアデータパケットの回復に適用されるFECコードを計算することに関与するものと同じでなくてもよい点に留意すべきである。しかし、このようなアルゴリズムは当業者に公知である。

新しいデータのブロックFEC_BMDを作るために、得られたFECコードは、メディアデータのブロックBMDに更に追加される。データのブロックFEC_BMDは、送信ネットワークプロトコル手段12により処理され、その送信ネットワークプロトコル手段12は、ネットワークプロトコルスタックに含まれるネットワークプロトコルに関係するヘッダを計算する。

メディアパケットMPが出力され、そのメディアパケットMPにおいて、RTPペイロードは、データのブロックFEC_BMDを有する。チェックサム計算手段14は、センシティブ部分の長さの認識からUDP-Liteチェックサムフィールドに書き込まれるチェックサムを計算する。センシティブ部分の長さは、メディアパケットMPの全長に対してパケット化器10により提供されるメディアデータのブロックの長さBMD_Lを減算することにより得られる。従って、センシティブ部分SPは、ヘッダとFECコードとを有する。センシティブ部分の長さBMD_Lは、チェックサム対象値CSCとしてUDP-Liteヘッダに格納される。メディアパケットのセンシティブ部分SPに対応するチェックサム値が計算され、メディアデータパケットMPのUDPヘッダのチェックサムフィールドCSが更新される。

本発明の第１の実施例はまた、ネットワーク3を介してマルチメディアコンテンツMMを送信する方法に関し、その方法は、
−そのマルチメディアコンテンツMMをメディアビットストリームMD_BSTRにエンコードするステップ10と、
−そのメディアビットストリームMD_BSTRをメディアデータのブロックにパケット化するステップ11と、
−メディアデータのブロックBMDについて誤り訂正コードFECを計算するステップ12と、
−そのメディアデータのブロックBMDをメディアパケットMPのインセンシティブ部分ISPに埋め込み、その誤り訂正コードFECをセンシティブ部分SPに埋め込むステップ13と、
−そのメディアパケットMPのそのセンシティブ部分SPを保護するチェックサムCSを計算するステップ14と
を有する。

図５は、本発明の第１の実施例による受信機を機能的に示している。このような受信機は、受信メディアデータパケットRPにネットワークプロトコルを適用する受信ネットワークプロトコル手段20を有する。インターネットプロトコルIPは、IPヘッダIP_HDを抽出及び分析し、IPペイロードをUDP-Liteプロトコルに送信する。UDP-Liteプロトコルは、UDP-Liteヘッダを抽出及び分析する。特に、チェックサム手段21は、チェックサム対象値により定められた受信パケットのセンシティブ部分でチェックサムCSをチェックする。受信パケットのチェックサムCSが有効である場合、受信パケットのUDP-LiteペイロードはRTPレイヤに送信される。そうでない場合、受信パケットは拒否される。RTPプロトコルはRTPヘッダを抽出及び分析し、FECコードとメディアデータの受信ブロックRBMDとを有するRTPペイロードをFECデコード手段22に送信する。FECデコード手段22は、FECコードが計算されたメディアデータのブロックを再計算することができる。メディアデータの受信ブロックRBMDが有効である場合、FECコードは無視される。一方、メディアデータの受信ブロックRBMDは訂正され、訂正されたメディアデータのブロックCBMDは、訂正メディアビットストリームCMD_BSTRを作る逆パケット化手段23に送信される。訂正メディアビットストリームは、デコード済マルチメディアコンテンツDMMを提供するために、デコーダ24により更にデコードされる。

本発明の第１の実施例はまた、ネットワーク3を介してメディアパケットRMPを受信する方法に関し、その方法は、
−その受信メディアパケットRMPのインセンシティブ部分ISPからメディアデータの受信ブロックを抽出し、センシティブ部分SPから誤り訂正コードFECを抽出するステップと、
−そのセンシティブ部分SPを保護するチェックサムCSが有効であるか否かをチェックするステップと、
−そのチェックサムが無効である場合に、受信メディアパケットRMPを拒否するステップと、
−その誤り訂正コードを使用してそのメディアデータの受信ブロックRBMDを訂正するステップと、
−受信メディアビットストリームRMD_BTSRにその訂正されたメディアデータのブロックCBMDを挿入するステップと、
−その受信メディアビットストリームRMD_BTSRをデコードするステップと
を有する。

図６は、本発明の第１実施例によるルータを機能的に示している。ルータは、メディアパケットMPを正確な方向にルーティングすることを目的とする。このため、ルータは、UDP-Liteプロトコルまでネットワークプロトコルのヘッダを抽出及び分析するルータネットワークプロトコル手段30を有する。特に、ルータネットワークプロトコル手段30の目的はメディアパケットMPの宛先アドレスを抽出することであり、それはトランスポートレイヤにより提供され、この場合にはUDP-Liteヘッダに格納される。UDP-Liteプロトコルは、UDP-Liteヘッダに格納されたチェックサムCSをチェックし、無効なチェックサムを有するメディアパケットMPを拒否する。有効なメディアパケットは再び埋め込まれ、その宛先に対してネットワークに再送信される。

本発明の第１の実施例はまた、ネットワーク3を介して受信されたメディアパケットRMPを受信機にルーティングする方法に関し、その方法は、
−その受信メディアパケットRMPのインセンシティブ部分ISPからメディアデータの受信ブロックRBMDを抽出し、センシティブ部分SPから誤り訂正コードFECを抽出するステップと、
−そのセンシティブ部分SPを保護するチェックサムが有効であるか否かをチェックするステップと、
−そのチェックサムが無効である場合に、受信メディアパケットを拒否するステップと、
−その誤り訂正コードを使用してメディアデータの受信ブロックRBMDを訂正するステップと、
−再送信メディアパケットRTMPのインセンシティブ部分に訂正されたメディアデータのブロックCBMDを再埋め込みし、センシティブ部分に誤り訂正コードを再埋め込みし、そのセンシティブ部分はチェックサムにより保護されるステップと
を有する。

本発明の第１の実施例では、パケット化器10により提供されるメディアデータのブロックBMDは、メディアパケットのインセンシティブ部分に完全に格納されている。

図７は、本発明の第２の実施例によるメディアパケット構造を示している。本発明の第２の実施例では、メディアパケットのセンシティブ部分SPは、メディアデータの第２のブロックBMD2を更に有する。従って、メディアデータの第２のブロックBMD2は、UDP(-Lite)チェックサムにより保護される。

本発明の第２の実施例によるメディアデータの第２のブロックは、ビデオデコーダのイメージサイズ若しくはフレームレート、又は何らかのデコーダのコンテキスト情報のように、その他のものより重要なメディアデータを転送するのに特に有利である。この種類の情報がなければ、ビデオデコーダは適切に動作できない。スケーラブルメディアビットストリームの始まりに最も重要なメディアデータを送信するように、メディアデータの区分を実現するビデオデコーダが存在する点に留意すべきである。例えば、第２のメディアデータは、そのようなビデオエンコーダ及びメディアパケットのインセンシティブ部分により提供される第１のデータ区分DP1と、その後のデータ区分DP2,DP3...DPN（Nは整数である）とを有してもよい。

図８は、本発明の第３の実施例による送信機を機能的に示している。このような送信機は、本発明によるメディアパケットMPのインセンシティブ部分ISPに格納されたメディアデータのブロックBMDに関するLoss Erasure Code（LEC）を計算する手段40を更に有する。LECコードは、送信ネットワークプロトコル手段12によりパケットLEC_Pに入れられ、メディアデータの対応するブロックを有するメディアパケットMP以外のパケットストリームで、ネットワークで送信される。代替の対策では、LECパケットは受信機の他のポートに送信される。

図９は、本発明の第３の実施例による受信機を機能的に示している。このような受信機は、メディアデータパケットRPと、更にLECパケットR_LEC_Pとを受信することを目的とする。受信メディアデータパケットRPは、受信ネットワークプロトコル手段20により前述したように処理される。

UDP-LiteチェックサムCSが有効である場合、受信メディアパケットRPは前述のように処理される。

UDP-LiteチェックサムCSが有効でない場合、メディアデータパケットは完全に拒否される。このメディアデータパケットの損失は、RTPプロトコルにより更に通知される。そのRTPプロトコルは、受信LECパケットの中で損失メディアパケットに対応するLECパケットLEC_Pを検索するように、検索手段50に求める。対応する受信LEPパケットLEC_Pが見つかると、LECデコード手段51によりデコードされる。メディアデータの回復ブロックLEC_BMDは逆パケット化手段23に送信され、逆パケット化手段23は回復メディアビットストリームLEC_MD_BSTRをデコーダ24に提供する。

前述のように、LECコードは通常では複数のメディアブロックのデータについて計算される。例えば、１つのLECパケットはNのメディアパケット（Nは整数であり、ほぼ10に等しい）について送信される。LECパケットにより、Nのメディアデータパケットの中から１つのメディアデータパケットを訂正することが可能になる。従って、LECコードは１つのメディアパケットの損失を補う。１つより多くのメディアデータパケットが損失した場合、損失メディアデータの完全な回復は不可能である。しかし、Nのメディアデータパケットの中で１つより多いメディアデータパケットの部分的な回復を可能にする何らかの種類のLECコードが存在する点に留意すべきである。これは、誤り訂正と圧縮効率との間のトレードオフであり、アプリケーションの要件に依存する。

従って、LECコードの計算に含まれるN-1の他のメディアパケットはまた、損失メディアデータパケットを回復するために必要になる。

本発明の第３の実施例の利点は、損傷を受けて受信されたメディアデータパケットを訂正する対策と、完全に損失したパケットを回復する対策との双方を提供する点である。

前述の説明及び図面は、本発明を限定するものではなく、例示するものである。特許請求の範囲内にある多数の選択肢が存在することは明らかである。これに関して以下の結びが行われる。ハードウェア若しくはソフトウェア又はその双方のアイテムを用いて機能を実装する多数の方法が存在する。これに関して、図面は非常に概略的であり、それぞれ本発明の唯一の可能な実施例を表している。このように、図面は異なるブロックとして異なる機能を示しているが、これは、ハードウェア又はソフトウェアの単一のアイテムが複数の機能を実行することを決して除外するものではなく、単一の機能がハードウェア若しくはソフトウェア又はその双方のアイテムの集合により実行されることを除外するものではない。例えば、図１、５及び９に記載のものと異なり、デコーダ24は受信機2から独立した遠隔装置でもよい。

請求項の如何なる参照符号も請求項を限定するものとして解釈される部できはない。“有する”という動詞及びその活用形の使用は、請求項に記載のもの以外の要素又はステップの存在を除外するものではない。単数の要素又はステップは、そのような要素又はステップの複数の存在を除外するものではない。

従来技術による通信システム IP／UDP／RTPのネットワークプロトコルスタック ネットワークプロトコルUDP-Liteにより使用されるデータパケット構造 UDP-Liteヘッダの構造 本発明の第１の実施例によるメディアパケット構造 本発明の第１の実施例による送信機の機能図 本発明の第１の実施例による受信機の機能図 本発明の第１の実施例によるルータの機能図 本発明の第２の実施例によるメディアパケット構造 本発明の第３の実施例による送信機の機能図 本発明の第３の実施例による受信機の機能図

Claims (11)

1. メディアデータのブロックを有するインセンシティブ部分とセンシティブ部分とを有するメディアパケット構造であって、
   前記センシティブ部分は、チェックサムにより保護され、
   前記センシティブ部分は、前記インセンシティブ部分に含まれるメディアデータのブロックを訂正する誤り訂正コードを有するメディアパケット構造。
2. 請求項１に記載のメディアパケットであって、
   前記誤り訂正コードは、前方誤り訂正コードであるメディアパケット。
3. 請求項１に記載のメディアパケットであって、
   メディアデータの第２のブロックを有し、
   前記メディアデータの第２のブロックは、前記センシティブ部分に含まれるメディアパケット。
4. ネットワークを介して受信機にマルチメディアコンテンツを送信する送信機であって：
   −前記マルチメディアコンテンツをメディアデータビットストリームにエンコードするメディアエンコード手段と、
   −前記メディアデータビットストリームをメディアデータのブロックに構成するパケット化手段と、
   −メディアデータのブロックを訂正する誤り訂正コードを計算する手段と、
   −前記メディアデータのブロックをメディアパケットのインセンシティブ部分に埋め込み、前記誤り訂正コードをセンシティブ部分に埋め込む送信ネットワークプロトコル手段と
   を有し、
   前記送信ネットワークプロトコル手段は、前記センシティブ部分を保護するチェックサムを計算するチェックサムサブ手段を有する送信機。
5. ネットワークを介して送信されるメディアパケットを受信する受信機であって：
   −前記受信メディアパケットのインセンシティブ部分からメディアデータの受信ブロックを抽出し、センシティブ部分から誤り訂正コードを抽出し、前記センシティブ部分で計算されたチェックサムが有効であるか否かをチェックするチェックサム計算サブ手段を有する受信ネットワークプロトコル手段と、
   −前記誤り訂正コードを使用して前記メディアデータの受信ブロックを訂正する手段と、
   −前記訂正されたメディアデータのブロックを受信メディアビットストリームに挿入する逆パケット化手段と、
   −前記受信メディアビットストリームをデコードするメディアデコード手段と
   を有する受信機。
6. ネットワークを介して受信されたメディアパケットを受信機にルーティングするルータであって、
   前記メディアパケットは、メディアデータのブロックを有するインセンシティブ部分とセンシティブ部分とを有し、
   前記センシティブ部分は、チェックサムにより保護され、
   前記センシティブ部分は、誤り訂正コードを有し、
   前記ルータは、前記チェックサムが有効であることをチェックするチェック手段と、前記メディアデータのブロックを訂正する誤り訂正手段とを有するルータネットワークプロトコル手段を有するルータ。
7. ネットワークを介してマルチメディアコンテンツを送信する方法であって：
   −前記マルチメディアコンテンツをメディアビットストリームにエンコードするステップと、
   −前記メディアビットストリームをメディアデータのブロックにパケット化するステップと、
   −メディアデータのブロックについて誤り訂正コードを計算するステップと、
   −前記メディアデータのブロックをメディアパケットのインセンシティブ部分に埋め込み、前記誤り訂正コードをセンシティブ部分に埋め込むステップと、
   −前記メディアパケットの前記センシティブ部分を保護するチェックサムを計算するステップと
   を有する方法。
8. ネットワークを介してメディアパケットを受信する方法であって：
   −前記受信メディアパケットのインセンシティブ部分からメディアデータの受信ブロックを抽出し、センシティブ部分から誤り訂正コードを抽出するステップと、
   −前記センシティブ部分を保護するチェックサムが有効であるか否かをチェックするステップと、
   −前記チェックサムが無効である場合に、前記受信メディアパケットを拒否するステップと、
   −前記誤り訂正コードを使用して前記メディアデータの受信ブロックを訂正するステップと、
   −受信メディアビットストリームに前記訂正されたメディアデータのブロックを挿入するステップと、
   −前記受信メディアビットストリームをデコードするステップと
   を有する方法。
9. ネットワークを介して受信されたメディアパケットを受信機にルーティングする方法であって：
   −前記受信メディアパケットのインセンシティブ部分からメディアデータの受信ブロックを抽出し、センシティブ部分から誤り訂正コードを抽出するステップと、
   −前記センシティブ部分を保護するチェックサムが有効であるか否かをチェックするステップと、
   −前記チェックサムが無効である場合に、前記受信メディアパケットを拒否するステップと、
   −前記誤り訂正コードを使用してメディアデータの受信ブロックを訂正するステップと、
   −再送信メディアパケットのインセンシティブ部分に訂正されたメディアデータのブロックを再埋め込みし、センシティブ部分に誤り訂正コードを再埋め込みし、前記センシティブ部分はチェックサムにより保護されるステップと
   を有する方法。
10. プロセッサ又はコンピュータにロードされると、前記プロセッサ又はコンピュータに請求項７ないし９のうちいずれか１項に記載の方法の１つを実行させる一式の命令を有するコンピュータプログラム。
11. 請求項１０に記載のコンピュータプログラムを運ぶ信号。

Images