(57)【特許請求の範囲】
【請求項１】
メディア・ストリームをリアルタイム転送プロトコルによりネットワークにパケット送信するメディア配信装置と、
前記ネットワークに接続され、前記メディア・ストリームを遅延の大きい通信リンクへ送信する中継装置と、
前記中継装置に到着する前記パケットをモニターし、前記ネットワークの状況を示すフィードバック情報を前記メディア配信装置に送信するパケット解析手段と、を備え、前記メディア配信装置は、前記フィードバック情報に基づいて前記メディア・ストリームを変更するよう構成されたメディア・ストリーミング配信システムにおいて、
前記メディア・ストリームは、ＩピクチャおよびＰピクチャのシーケンスを含む動画であり、
前記メディア配信装置は、
１つの動画について、第１の配置でＩピクチャを含む第１のメディア・ストリーム、および該第１の配置とは異なる第２の配置でＩピクチャを含む第２のメディア・ストリームを少なくとも含む複数のメディア・ストリームを格納する記憶装置と、
前記パケット欠落の判断に応じて、該欠落の発生した宛先について、該欠落したパケットのピクチャの後、先にＩピクチャが現れるメディア・ストリームを前記複数のメディア・ストリームから選択し、送信するメディア・ストリームを該選択されたメディア・ストリームに切り換える切り換え手段と、
を有するメディア・ストリーミング配信システム。
【請求項２】
前記フィードバック情報は、前記中継装置に前記メディア・ストリームのパケットが到来するごとに送信される確認応答である請求項１に記載の配信システム。
【請求項３】
前記フィードバック情報は、前記メディア・ストリームから欠落したパケットのシーケンス番号である請求項１に記載の配信システム。
【請求項４】
前記遅延の大きい通信リンクは無線リンクである請求項１に記載の配信システム。
【請求項５】
前記メディア・ストリームは、ＩピクチャおよびＰピクチャのシーケンスを含む動画であり、
前記メディア配信装置は、前記メディア・ストリームを生成する符号化装置を備え、
該符号化装置は、前記パケット欠落の判断に応じて、Ｉピクチャからはじまるメディア・ストリームを生成するよう構成されている請求項１に記載のシステム。
【請求項６】
一連のパケットで構成されるメディア・ストリームを配信するメディア配信装置であって、
前記メディア・ストリームの配信経路上でのパケットの欠落に関するフィードバックに応答して前記欠落の影響を小さくするよう前記メディア・ストリームを変更するよう構成されたメディア配信装置において、
前記メディア・ストリームは、ＩピクチャおよびＰピクチャのシーケンスを含む動画であり、
１つの動画について、第１の配置でＩピクチャを含む第１のメディア・ストリーム、および該第１の配置とは異なる第２の配置でＩピクチャを含む第２のメディア・ストリームを少なくとも含む複数のメディア・ストリームを格納する記憶装置と、
前記パケット欠落の判断に応じて、該欠落の発生した宛先について、該欠落したパケットのピクチャの後、先にＩピクチャが現れるメディア・ストリームを前記複数のメディア・ストリームから選択し、送信するメディア・ストリームを該選択されたメディア・ストリームに切り換える切り換え手段と、
を備えるメディア配信装置。
【請求項７】
前記メディア・ストリームは、ＩピクチャおよびＰピクチャのシーケンスを含む動画であり、
前記メディア配信装置は、前記メディア・ストリームを生成する符号化装置を備え、
該符号化装置は、前記パケット欠落の判断に応じて、Ｉピクチャからはじまるメディア・ストリームを生成するよう構成されている請求項６に記載のメディア配信装置。
【請求項８】
前記パケットの欠落に関するフィードバックは、前記配信経路が遅延の小さなリンクから遅延の大きなリンクへ切り替わる箇所で観測された前記パケットの欠落に関するフィードバックである請求項７に記載のメディア配信装置。
【請求項９】
前記遅延の小さいリンクは有線リンクであり、前記遅延の大きいリンクは無線リンクである請求項８に記載のメディア配信装置。
【請求項１０】
前記パケット解析装置からのフィードバック情報によりパケットの欠落が検出されることに応じて、前記符号化装置は、少なくとも該欠落の発生した宛先に送信するメディア・ストリームについてＩピクチャの頻度を高くするよう構成されている請求項６に記載のメディア配信装置。
【請求項１１】
前記パケット解析装置からのフィードバック情報によりパケットの欠落が検出されることに応じて、前記符号化装置は、Iピクチャからはじまるメディア・ストリームを、該欠落の生じた宛先に送信するよう構成されている請求項６に記載のメディア配信装置。
【請求項１２】
前記メディア配信装置は前記パケットの欠落に関するフィードバック情報に基づいて前記パケットの再送を行う請求項９に記載のメディア配信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、メディアのストリーミングに関し、より具体的にはクライアントに無線によりメディア・ストリームを送信する場合など、ストリームの伝送経路の遅延時間が伝送経路の途中から大きくなる場合のストリーミングに関する。なお、以下の説明では遅延の大きい伝送経路として無線リンクを例に挙げて説明するが、これに限定するわけではない。
【０００２】
【従来の技術】
近年、通信技術のめざましい発展により、無線通信によりマルチメディア配信を行うことが可能になってきた。無線による配信を受けるクライアントにおいてリアルタイムでマルチメディアを再生するためには、通信路のQoS制御（送信レート制御やパケットロス耐性制御）が重要になってくる。
【０００３】
下に示す非特許文献１には、無線基地局においてシェイピング・ポイント（フロー制御ポイント）の後にＲＴＰモニタリングエージェントを設けることが記載されている。ＲＴＰ（リアルタイム転送プロトコル）モニタリングエージェントは、無線基地局に到達し、無線送信されるべきマルチメディア・ストリームをモニターし、メディア・サーバから無線基地局に至る有線ネットワークの輻輳状況を表す情報をメディア・サーバにフィードバックする。無線基地局からの無線を受信するクライアントは、ＲＴＣＰプロトコルにしたがって受信の確認情報をメディア・サーバに送信する。
【０００４】
メディア・サーバは、ＲＴＰモニタリングエージェントからのフィードバック情報とクライアントからの受信報告とに基づいて、有線ネットワークの輻輳状態および無線リンクにおけるエラー状態を判断する。メディア・サーバは、有線ネットワークの輻輳によってパケットロスが発生しているときは、メディア・ストリームの送信レートを下げ、無線リンクのエラーによってパケットロスが発生しているときは、メディアの符号化のパケットロス耐性を高める。パケットロス耐性は、たとえばビデオ符号化におけるフレーム内符号化のレートを高めることによって高められる。
【０００５】
【非特許文献１】
「モバイルマルチメディア配信のためのＲＴＰモニタリングエージェントによるＱｏＳ制御アーキテクチャ」  吉村  健  ほか、ＩＰＳＪ  ＤＩＣＯＭＯ  2001年６月。
【０００６】
【発明が解決しようとする課題】
このような従来の手法では、パケットロスが発生してから、パケットロス耐性が高められるまでにかなりの時間を要する。有線ネットワークの輻輳に対応してフロー制御によりビデオ・ストリームのＩピクチャを含むパケットが破棄され、後続の複数のＰピクチャのパケットが無線送信された場合、クライアントは、Ｐピクチャの再生のために参照すべきＩピクチャがないためにＰピクチャを再生することができない。また、あるＰピクチャが破棄された場合も、次のＩピクチャが受信されるまでは、そのＰピクチャに依存する後続のＰピクチャも再生できない。一般のＴＣＰ通信では、伝送に失敗したパケットは、フィードバック情報に基づいて再送される。しかし、リアルタイムにメディアを再生するストリーミングでは、クライアントのバッファサイズが小さいなどの場合には再送が間に合わないことがある。有線ネットワークの輻輳によってパケットが破棄されると、破棄されたパケットだけにとどまらず、受信に成功した後続の複数のパケットに含まれるＰピクチャの再生エラーを生じる。
【０００７】
したがって、無線などの低速通信の基地局以前のネットワークで生じたパケットロスの影響が、後続のパケットに含まれるメディアの再生に波及する、という現象を低減させる必要性が存在する。
【０００８】
【課題を解決するための手段】
この発明のメディア・ストリーミング配信システムは、一面によると、メディア・ストリームをリアルタイム転送プロトコルによりネットワークにパケット送信するメディア配信装置と、前記ネットワークに接続され、前記メディア・ストリームを無線などの低速通信で送信する基地局と、を備える。このシステムは、さらに無線基地局に到着する前記パケットをモニターし、パケットの欠落に関するフィードバック情報を前記メディア配信装置に送信するパケット解析装置を備える。
【０００９】
この発明は、一面によると、上記のようなシステムに含まれるメディア配信装置を提供する。
【００１０】
この発明の一形態によると、パケット解析装置は、パケットのヘッダに含まれるシーケンス番号をフィードバック情報として前記メディア配信装置に送る。
【００１１】
また、この発明の一形態では、メディア配信装置は、フィードバック情報に基づいてパケットの欠落を判断し、パケット欠落の判断に応じて、パケット欠落の影響を小さくするようメディア・ストリームを変更する。
【００１２】
さらに、一形態では、メディア・ストリームは、ＩピクチャおよびＰピクチャのシーケンスを含む動画である。メディア配信装置は、１つの動画について、第１の配置でＩピクチャを含む第１のメディア・ストリーム、および該第１の配置とは異なる第２の配置でＩピクチャを含む第２のメディア・ストリームを少なくとも含む複数のメディア・ストリームを格納する記憶装置を備える。
【００１３】
メディア配信装置は、前記パケット欠落の判断に応じて、該欠落の発生した宛先について、該欠落したパケットのピクチャの後、先にＩピクチャが現れるメディア・ストリームを前記複数のメディア・ストリームから選択し、送信するメディア・ストリームを該選択されたメディア・ストリームに切り換える切り換え手段を有する。こうすることにより、パケット欠落の影響が後続のパケットに含まれるメディアの再生に波及する現象を低減することができる。
【００１４】
この発明の一形態では、フレーム内符号化されたＩピクチャの頻度が異なるメディア・ストリームを用意しておき、パケット欠落に応じてＩピクチャの頻度の高いメディア・ストリームに切り換える。
【００１５】
また、この発明の他の形態によると、メディア配信装置は、メディア・ストリームを生成する符号化装置を備える。この符号化装置は、パケット欠落の判断に応じて、Ｉピクチャからはじまるメディア・ストリームを生成するよう構成されている。
【００１６】
この発明の一形態では、符号化装置は、パケット解析装置からのフィードバック情報によりパケットの欠落が検出されることに応じて、少なくとも欠落の発生した宛先に送信するメディア・ストリームについてＩピクチャの頻度を高くするよう構成されている。
【００１７】
さらに、一形態によると、メディア配信装置は、メディア・ストリームの宛先の無線端末装置からパケット受信に関する宛先フィードバック情報を受け取り、この宛先フィードバック情報とパケット解析装置からのフィードバック情報とに基づいて、パケット欠落がネットワークにおける有線送信または無線基地局からの無線送信のいずれで生じたかを判断する。
【００１８】
また、発明の一実施形態では、メディア配信装置はパケットの欠落に関するフィードバック情報に基づいてパケットの再送を行う。
【００１９】
また、発明の一実施形態では、メディアストリームの中継装置と端末装置の両方からのフィードバックに基づいて、メディア配信装置から中継装置までの送出レート及び中継装置から端末装置までの送出レートを求め、送出レートの大きい方で余剰帯域を再送もしくは前方誤り訂正のために使用することで、通信品質を向上させる。
【００２０】
【発明の実施の形態】
次に図面を参照して、この発明の一実施例を説明する。図１は、この発明の一実施例の全体的構成を示す図である。メディア配信装置11は、マルチメディアのリアルタイム配信を行う。マルチメディアには、映像、音声、テキスト、グラフィックスなどが含まれ、それぞれのストリームがパケット送信され、受信装置によってリアルタイムに再生される。以下の説明では、これらのメディアのうち動画のビデオ・ストリームについて記述する。メディア配信装置11は、オン・デマンド・ビデオ配信の形態、またはブロードキャストの形態でメディア・ストリームを配信することができる。
【００２１】
携帯電話、携帯端末（ＰＤＡ）、無線通信装置を備えたコンピュータなどの無線端末装置19からメディア配信のリクエストがあると、メディア配信装置11は、メディア・ストリームをパケット化し、ＲＴＰ（Real-time Transport Protocol、リアルタイム転送プロトコル）ヘッダおよびＩＰヘッダを付けて有線ネットワーク21に送信する。パケットは、インターネット・プロトコル（ＩＰ）に従って経路制御(routing)を受け、無線基地局10に達する。ＩＰは、コネクションレスの通信プロトコルであり、ネットワークに輻輳が発生すると、オーバーフローしたパケットは、ネットワークから破棄されることがある。
【００２２】
無線基地局10は、ネットワーク21から受信したパケットを無線で無線端末19に送信する。この発明によると、パケット解析装置15が無線基地局10に備えられ、無線基地局10に到着するメディア・ストリームのパケットをモニターする。１つの無線端末装置19に送信されるメディア・ストリームの一連のパケットは、ＩＰヘッダに含まれるソースアドレスおよび宛先アドレス(destination address)の対並びにＵＤＰヘッダに含まれるソース・ポート番号および宛先ポート番号の対によって特定することができる。後に詳しく述べるように、パケットにはＲＴＰヘッダが含まれており、ＲＴＰヘッダは、メディア・ストリームの中でのそのパケットにユニークなシーケンス番号を含んでいる。
【００２３】
パケット解析装置15は、同じソースアドレスおよび宛先アドレスで、かつ同じソース・ポート番号および宛先ポート番号をもつパケットの一連の流れを検出すると、そのＲＴＰヘッダに含まれるパケット番号をメディア配信装置にフィードバック（ACK）する。メディア配信装置11は、このフィードバック情報からパケットロスを検出することができる。メディア配信装置11は、パケットのシーケンス番号からＩピクチャのパケットが欠落したことを検出すると、メディアのフォーマットをＩピクチャの頻度が大きいフォーマットに切り換える。
【００２４】
こうすることにより、無線端末装置19は、早期にＩピクチャを受信することができるので、動画再生の品質が低下するのを防ぐことができる。
【００２５】
次に図２を参照して、この発明の一実施例をより詳しく説明する。メディア配信装置11は、マルチメディア・コンテンツのデータベース27に、Ａ、Ｂ、Ｃ、Ｄのビデオコンテンツを２つの異なるフォーマットで格納している。すなわち、ビデオＡは、第１フォーマットのビデオコンテンツＡ１と第２フォーマットのビデオコンテンツＡ２の形で格納されている。同様にビデオＢは、第１フォーマットのコンテンツＢ１および第２フォーマットのコンテンツＢ２として格納され、ビデオＣは、第１フォーマットのコンテンツＣ１および第２フォーマットのコンテンツＣ２として格納されている。
【００２６】
図５は、２つのフォーマットの例を示す。図５（Ａ）は、第１フォーマットの例を示し、図５（Ｂ）は、第２フォーマットの例を示す。第２フォーマットの方が第１フォーマットよりもＩピクチャの頻度が高く設定されている。図でＩは、フレーム内符号化されたＩピクチャを示し、Ｐは、Ｉピクチャに基づいて予測符号化されたＰピクチャを示す。Ｉピクチャと当該Ｐピクチャとの間に先行する他のＰピクチャがあるときは、当該Ｐピクチャは、Ｉピクチャおよびこれらの先行するＰピクチャに基づいて予測符号化される。この実施例では、動画は、ＭＰＥＧ４に従って符号化されている。
【００２７】
ＭＰＥＧ４標準では、入力画像の各フレーム（ピクチャ）は、他のフレームの画像とは独立にそのフレームだけの情報を使って圧縮符号化するＩピクチャと、Ｉピクチャの画像に基づいて予測を行い、予測誤差を符号化して伝送するＰピクチャとに分けられる。
【００２８】
ＩピクチャおよびＰピクチャは、それぞれＤＣＴ（Discrete Cosign Transform、離散コサイン変換）によりＤＣＴ係数に変換される。このＤＣＴ係数と動き位置情報がエントロピー符号化される。その際、一つのピクチャは、８×８画素のブロックに分割され、ブロックごとにＤＣＴが行われる。隣接する４つのブロックが１つのマクロブロック（ＭＢ）にまとめられ、複数のマクロブロックが１つのグループオブブロック（ＧＯＢ）としてまとめられる。図４（Ｂ）に示すように複数のマクロブロックが１つのパケットに入れられて伝送される。
【００２９】
この実施例では、メディア配信装置11は、オンデマンド方式でマルチメディア配信を行う。図にはビデオコンテンツだけを示してあるが、動画と同期して再生される音声コンテンツも同様にデータベースに格納されており、ビデオコンテンツと並行して送信される。
【００３０】
フォーマット切換部29は、フィードバック制御部35からの指示に応じて、データベース27から取り出すコンテンツを第１フォーマットと第２フォーマットとの間で切り換える。
【００３１】
パケット解析装置15に含まれるマルチメディア・ストリーム検出部37は、無線基地局10に到達するＩＰパケットから、ＲＴＰヘッダを含むパケットを検出し、そのパケットのソースアドレスおよび宛先アドレスの対ならびにソース・ポート番号および宛先ポート番号の対に基づいてマルチメディア・ストリームを検出する。ＲＰＴヘッダモニター部39は、マルチメディア・ストリーム検出部37が検出したマルチメディア・ストリームのＩＰパケットに含まれるＲＴＰヘッダをモニターし、ＲＴＰヘッダに含まれるパケットのシーケンス番号を点検する。複数のパケットにわたるシーケンス番号の点検から、シーケンス番号の欠落を検出すると、ＲＴＰヘッダモニター部39は、欠落したＩＰパケットを特定する情報をフィードバック・ジェネレータ41に送る。一実施例では、ＩＰパケットを特定する情報には、ソースアドレス、宛先アドレス、欠落したＲＴＰパケットのシーケンス番号が含まれる。また、別の実施例では、ＲＴＰモニター部39は、欠落したＲＴＰパケットのシーケンス番号ではなく、ＲＴＰパケットを検出するごとにそのシーケンス番号をフィードバック・ジェネレータ41に送る。
【００３２】
フィードバック・ジェネレータ41は、ＲＴＰパケットを受信するごとにそのシーケンス番号をソースアドレスにＡＣＫとして返す。代替実施例では、フィードバック・ジェネレータ41は、ＲＴＰヘッダモニター部39から情報が渡されることに応答して、所定の期間の間に生じるＲＴＰパケットの欠落を一連のRTPパケットのシーケンス番号から判断し、欠落したRTPパケットのシーケンス番号をソースアドレスに向けて送信する。この場合のフィードバックは、RTCPを拡張して送信することもできる。これらの送信は、有線ネットワーク21に対して行われる。
【００３３】
メディア配信装置11のフィードバック制御部35は、パケット解析装置15からフィードバック情報を受信し、欠落したパケットのシーケンス番号を受け取ることに応答して、メディア・フォーマットの切換指令をフォーマット切換部29に送る。別の実施例では、フィードバック制御部35は、パケット解析装置15から送られてくるＡＣＫ情報から、パケットのシーケンス番号の欠落を監視し、欠落が検出されると、メディア・フォーマットの切換指令をフォーマット切換部29に送る。
【００３４】
いずれの実施例においても、フィードバック制御部35は、パケットの欠落が検出されたとき、フォーマットの切換指令をフォーマット切換部29に送る。欠落したパケットがＰピクチャのものであったときは、Ｉピクチャの場合に比べて影響の深刻さは低い。したがって、この切り換えによる効果が相対的に小さい場合（たとえば、次のＩピクチャまでの間にわずかの枚数のＰピクチャしかない場合など）には、フォーマット切換を行わないようにしてもよい。
【００３５】
いま、第１フォーマットのメディアＡ１が無線端末装置19に提供されているとすると、フォーマット切換部29は、第２フォーマットのメディアＡ２に切り換える。再び図５（Ａ）を参照すると、メディアＡ１のストリームのうち、Ｉピクチャ51のマクロブロックを含む複数のパケットの１つまたは複数が欠落したか、またはＰピクチャ51aのマクロブロックを含むパケットが欠落したとする。フォーマット切換部29は、フィードバック制御部35からの指令に応じて、メディアを第２フォーマットのＡ２に切り換え、タイミング的にメディアＡ１のＩピクチャ51またはＰピクチャ51aの欠落後、メディアＡ２で最初に現れるＩピクチャ57から送信を開始する。
【００３６】
無線端末装置19においては、Ｉピクチャ51のパケットの１つまたは複数が欠落したため、またはＰピクチャ51aのパケットが欠落したため、Ｉピクチャ51またはＰピクチャ51aに依存した符号化がなされている後続のＰピクチャ51b、51c、51d、51eを正しく再生することができない。しかし、メディア配信装置11が、メディアのフォーマットをＩピクチャの頻度が高い第２フォーマットに切り換え、図５（Ｂ）に示す第２フォーマットのＩピクチャ57から送信を開始するので、無線端末装置19は、Ｉピクチャ57からメディアを正しく再生することができる。
【００３７】
図６は、この発明によるメディア配信システムにおける通信および処理のシーケンスの一例を示す。
【００３８】
データベース27から取り出されたコンテンツは、パケット化部31で、パケット化され、ストリーム送信部33から有線ネットワーク21に送り出される。図６を参照すると、ストリーム送信部33は、RTP処理ルーチン111およびRTCP処理ルーチンを実行する。
【００３９】
RTP処理ルーチンは、１パケット分の圧縮データにその圧縮符号化の形式を特定する圧縮符号ヘッダを付け、さらにＲＴＰヘッダ、ＵＤＰヘッダおよびＩＰヘッダを付加する。図４（A）は、そのようなパケットのフォーマットの一例を示す。ＲＴＰヘッダには、パケットのシーケンス番号が含まれている。このシーケンス番号の初期値は、乱数によって定められ、各パケットに初期値からはじまる連続番号が付けられる。ＲＴＰヘッダには、ＳＳＲＣ識別子（Synchronization Source identifier、同期送信元識別子）が含まれている。この識別子は、たとえば同一ユーザの音声ストリームと映像ストリームなど、組み合わせて扱うべき複数のストリームに同じ値が付けられている。
【００４０】
処理ルーチン111は、ＲＴＰヘッダが付けられたＲＴＰパケットＵＤＰヘッダおよびＩＰヘッダを付け、ＵＤＰ／ＩＰプロトコルを用いて送信する。ＩＰヘッダには、送信元を示すソースアドレスおよび宛先を示す宛先アドレスが含まれている。また、ＵＤＰヘッダには、送信元のポート番号を示すソース・ポート番号および宛先のポート番号を示す宛先ポート番号が含まれる。
【００４１】
図４（Ｂ）は、ＭＰＥＧの標準に従って１つのフレームのピクチャが複数のパケットに分割されて送信される形態を示す。たとえば、Ｉピクチャは、情報量が多いため、複数のパケットに分割されて伝送されることになる。ネットワークに大きな輻輳が生じるとＩピクチャの一部のパケットが破棄されることがあり、完全なＩピクチャが無線端末装置19に届かない状態が発生する可能性がある。図４（Ｂ）で、ＧＯＢはグループのブロック、ＭＢはマクロブロックを示す。
【００４２】
RTCP処理ルーチン113は、RTPパケットを送出するネットワークとの間で制御情報を交換する。RTCP（Real-Time Transfer Control Protocol、RTP制御プロトコル）は、RTPを補助するプロトコルで、送信装置と受信装置との間で制御情報を通知し合うことによって、フロー制御、クロック同期、音声データと映像データの間のメディア間同期などの制御を実現する。
【００４３】
RTCP処理ルーチン113は、RTPパケットの送信に先立って、情報源に関する記述であるSDES(Source Description)をRTCPパケット115にし、これにIPヘッダ、UDPヘッダを付けて、UDP/IPプロトコルを用いてネットワークに送出する。これに続いてRTP処理ルーチンがRTPパケット117、119、121を順次ネットワークに送出する。
【００４４】
図２において無線基地局10の前に置かれたシェイピング・ポイント13は、メディア配信装置11から無線基地局に至る経路の有線ネットワークに存在するフロー制御を司る１つまたは複数の中継装置を表している。無線基地局10は、シェイピング・ポイントに対応するものとして、たとえばレイヤー３スイッチを備えており、有線ネットワーク21から高速で受け取ったパケットをバッファし、無線基地局10の無線部の処理速度に合わせた速度で無線部に提供する。
【００４５】
再び図６を参照すると、無線基地局10のパケット解析装置15は、RTCPパケット115およびこれに続くRTPパケット117、119、121から、これらが一つのメディア・ストリームの一部であることを検出し、所定期間にわたって受信したパケットから、パケット廃棄率、ジッタなどを計算し（131）、メディア配信装置11に向けたRTCPパケットにこれらの情報を載せて有線ネットワークに送出する。
【００４６】
パケット解析装置15は、またメディア配信装置11からの同一メディア・ストリームのRTPパケットを検出するたびにそのRTPパケットのシーケンス番号を含む受信確認信号（ACK）をメディア配信装置11に送る。代替実施例では、パケット解析装置15は、RTPパケットの受信のたびにACKを返すのではなく、同一メディア・ストリームに属するRTPパケットのシーケンス番号が連続しているかどうかを監視し、シーケンス番号が欠落したことを検出すると、欠落したRTPパケットのシーケンス番号を含む受信失敗信号(NACK)をメディア配信装置11に送る。
【００４７】
メディア配信装置11のRTCP処理ルーチン113は、送出したRTCPパケット115に対する応答であるRTCPパケット133を受け取ると、これに含まれるパケット廃棄率その他の制御情報に応じて、送出するメディア・ストリームの送信レートを変更する。また、RTCP処理ルーチン113で検出されるパケット廃棄率が高いときは、フィードバック制御ルーチン35は、後続のメディア・ストリームのフォーマットをIピクチャの比率が高いフォーマットに切り換える制御信号をフォーマット切り換え部29（図２）に送る。
【００４８】
メディア配信装置11のRTP処理ルーチン111は、無線基地局10からのACKパケット105、107、109を受信するたびに、ACKパケットに含まれる、無線基地局10が受信したRTPパケットのシーケンス番号をフィードバック制御部35に渡す。フィードバック制御部35は、送出したパケットのうち無線基地局10に到達しなかったものがあるかどうか、すなわちパケットに欠落があるかどうかを点検する(141)。パケットの欠落が検出されると、そのRTPパケットに含まれたデータがIピクチャであったかどうか判定する（143）。欠落したパケットがIピクチャのものであるときは、直ちに上述したフォーマット切り換え手順に入る（145）。
【００４９】
ステップ143において欠落したパケットがPピクチャのものであると判定されるときは、Pピクチャ欠落の場合の再送基準に達したかどうかを判定する（147）。Pピクチャ欠落は、Ｉピクチャの場合に比べて影響の深刻さは低い。したがって、予め定めた基準に到達したときにフォーマット切り換えを行い（149）、この基準に達するまではフォーマット切り換えを行わない。たとえば、次のＩピクチャまでの間にわずかの枚数のＰピクチャしかない場合などには、フォーマット切換を行わないよう基準を設定する。
【００５０】
無線基地局の無線部は、受け取ったＩＰパケットを無線に載せて送信する。無線端末装置19は、この無線を受信し、メディア・ストリームを再生する。無線によるＩＰパケットの送受信は公知の技術なので詳細な説明は省略する。
【００５１】
無線端末装置19の構成によっては、メディア配信装置11にＡＣＫ信号を送ることができる。具体的には、３ＧＰＰ標準に準拠している無線端末装置の場合には、パケット解析装置15のようにＡＣＫ信号を送ることはできない。この標準に準拠する必要がない場合には、ＡＣＫ信号を送るよう構成することが可能である。フィードバック制御部35は、パケット解析装置15からのフィードバック情報と無線端末装置19からの情報とを比較することによって、無線基地局10から無線端末装置19への無線通信の品質を知ることができる。無線通信の品質が低いことが判断されると、フィードバック制御部は、フォーマット切換部29に、メディアのフォーマットをＩピクチャの頻度が高いフォーマットに切り換える指令を送る。メディアのフォーマットは、２種類にとどまらず、多数のフォーマットを用意することができ、通信状態に応じて、複数のフォーマットの間で切換を行うことができる。たとえば、Ｉピクチャの頻度が高いフォーマットで送信を行っているとき、十分良好な通信状態が測定されると、Ｉピクチャの頻度の低いフォーマットに切り換えることができる。こうして、メディア配信装置11は、ストリーム送信の負荷を調整することができる。
【００５２】
次に図３を参照して、この発明のもう一つの実施例を説明する。図３において、図２の実施例と同じ要素は、同じ参照番号で示されている。メディア配信装置11は、リアルタイムで入力画像30を符号化部28で圧縮符号化し、パケット化部31によりパケット化し、メディア・ストリームとして有線ネットワーク21に送り出す。入力画像30は、予め録画され、記憶装置に記憶されたものでも、テレビ中継のようにビデオカメラを用いてリアルタイムに撮像されるものであってもよい。
【００５３】
符号化部28は、既に説明したＭＰＥＧ４標準にしたがって入力画像を符号化する。符号化部28は、トランスコーダの機能をもっており、フィードバック制御部35からの指令に応じて、符号化におけるＩピクチャの頻度を変更する。すなわち、パケット解析装置15からのフィードバック情報により、無線基地局10に到達するメディア・ストリームにＩピクチャのマクロブロックを含むパケットの欠落が検出されることに応答して、符号化部28は、Ｉピクチャの頻度を高くするよう符号化を切り換える。
【００５４】
次に、無線基地局からのフィードバックに基づき欠落したパケットの再送を行うもう一つの実施例について説明する。
【００５５】
無線リンクでは通常は遅延時間が大きい。メディア配信装置と無線基地局の間の往復時間は無線基地局と無線端末のクライアントとの間の往復時間に比べてかなり短い。したがって、無線端末に備えられる受信バッファの大きさ（すなわち、パケット再送によるパケット到着の遅れにどれだけ耐えられるか）に基づいて、メディア配信装置から無線基地局に至る有線ネットワーク及び無線基地局から無線端末に至る無線リンクにおいてパケットの欠落が生じた場合に、欠落したパケット復元の態様として、有線ネットワークあるいは無線リンク上で欠落したパケットの再送を行うかそれとも前方誤り訂正（ＦＥＣ）を行うかを決定して夫々の通信経路のスループットを最適化することができる。ＦＥＣは具体的には当業者には周知のReed-Solomon符号等のエラー訂正符号を用いて実現される。また、バースト・エラーへの耐性を更に向上させるため、これも当業者に周知のインターリーブをかけてもよい。インターリーブによってバースト・エラーに対するエラー訂正能力を向上させる周知例としては、例えばＣＤ−ＤＡで使用されているＣＩＲＣ(Cross Interleaved Reed-Solomon Code)がある。
【００５６】
パケット再送／ＦＥＣの使い分けのため、無線端末の受信バッファの大きさに基づいてこれら２つの通信経路上での欠落パケット復元の態様として３つのモードを設ける。これらのモードについては後に詳細に説明する。
【００５７】
図７は、このような機能を備えたメディア・ストリーム配信システムの全体的な構成を示す。図１，図２、図３と同じ構成要素は同じ参照番号で示している。無線基地局10は、第１のフィードバック部71、ＦＥＣデコーダ72、無線基地局におけるフロー制御を行うシェイピング・ポイント13’、ＦＥＣジェネレータ18、第２のフィーバック部73、および無線送信装置14を備える。ＦＥＣデコーダ72の役割は、ネットワーク21上でＦＥＣを使用して欠落パケットの復元を行うモード（以下で説明するモード３）である場合に、ネットワーク21上で送られてくるエラー訂正符号情報を使用して欠落したパケットを復元し、またエラー訂正コードを除去してデータ本体だけを次段ヘ送ることである。シェイピング・ポイント13’は、無線基地局10にそのバッファ容量を超えるパケットが到来するとき、パケットの一部を廃棄する。すなわち、シェイピング・ポイント13’は、ネットワークから受信するパケットの通過を調整する調整手段である。ＦＥＣジェネレータ18の役割は、無線装置14と無線端末19の間の無線リンク上でＦＥＣを使用して欠落パケットの復元を行うモード（以下で説明するモード２及びモード３）である場合に、無線リンク上へ送り出すデータ・ストリームに付加するエラー訂正コードを生成することである。
【００５８】
図８は、図７のシステムにおいて、メディア配信装置がフォーマット切り換え方式をとる場合の実施例を示す図であり、図２の実施例と対応する。マルチメディア・ストリーム検出部37’は、無線基地局10に到達するＩＰパケットから、ＲＴＰヘッダを含むパケットを検出し、そのパケットのソースアドレスおよび宛先アドレスの対ならびにソース・ポート番号および宛先ポート番号の対に基づいてマルチメディア・ストリームを検出する。
【００５９】
ＲＴＰヘッダモニター部39’は、マルチメディア・ストリーム検出部37’が検出したマルチメディア・ストリームのＩＰパケットに含まれるＲＴＰヘッダをモニターし、ＲＴＰヘッダに含まれるパケットのシーケンス番号を点検する。複数のパケットにわたるシーケンス番号の点検から、シーケンス番号の欠落を検出すると、ＲＴＰヘッダモニター部39’は、欠落したＩＰパケットを特定する情報をフィードバック・ジェネレータ41’に送る。一実施例では、ＩＰパケットを特定する情報には、ソースアドレス、宛先アドレス、欠落したＲＴＰパケットのシーケンス番号が含まれる。また、別の実施例では、ＲＴＰモニター部39’は、欠落したＲＴＰパケットのシーケンス番号ではなく、ＲＴＰパケットを検出するごとにそのシーケンス番号をフィードバック・ジェネレータ41’に送る。
【００６０】
フィードバック・ジェネレータ41’は、ＲＴＰパケットを受信するごとにそのシーケンス番号をソースアドレスにＡＣＫとして返す。代替実施例では、フィードバック・ジェネレータ41’は、ＲＴＰヘッダモニター部39’から情報が渡されることに応答して、所定の期間の間に生じるＲＴＰパケットの欠落を一連のRTPパケットのシーケンス番号から判断し、欠落したRTPパケットのシーケンス番号をソースアドレスに向けて送信する。更に別の代替実施例では、個々のＲＴＰパケットの受信あるいは欠落の判明毎にソースアドレスに対して応答を帰す代りに、複数のＲＴＰパケット毎にまとめて応答する。より具体的に説明すれば、Ｎ個のパケット毎に、各パケットが正常に受信されたかそれとも欠落したかを示す受信／欠落データを帰す。まとめられるパケットの個数Ｎは、この応答の遅延時間がソースアドレスからのパケットの再送が間に合う範囲に収まるように決定される。
【００６１】
図９は、図８のシステムの通信シーケンスを示す図である。図６を参照して説明したのと同様に、メディア配信装置11は、RTP処理部111およびRTCP処理部113を有する。RTCP処理部113は、PTCPパケットの送信に先行して発信者情報（SDES）を含むRTCPパケット115を無線基地局10に向けて有線ネットワーク21に送出する。無線基地局10の第１のフィードバック部71は、RTCPパケット115およびこれに続いて送られてくるRTPパケット117、119、121に応答して有線ネットワーク21におけるパケットの廃棄率およびネットワーク伝送の遅延時間を計算し、これらの情報をRTCPパケット133に載せてメディア配信装置に送る。
【００６２】
無線基地局10の第２のフィードバック部73は、メディア・ストリームのRTPパケットを受け取るたびにRTPパケットのシーケンス番号を受信確認信号（ACK）に含めてメディア配信装置に送り返す。図９では、RTPパケット117の受信に応答してACK105が返され、RTPパケット119の受信に応答してACK107が、RTPパケット121に応答してACK109が返されている。もちろん、図８のフィードバック・ジェネレータ41'について説明したように、正常に受け取ったパケットのシーケンス番号をメディア配信装置へ送り返す代りに、欠落したパケットの番号を送り返しても良いし、また複数のパケットについてまとめて到着・未着応答を返すようにしても良い。
【００６３】
図８を参照すると、第２のフィードバック部73は、マルチメディア・ストリーム検出部37’、RTPヘッダモニター部39’、およびフィードバック・ジェネレータ41’を備えている。これらの各部の機能は、図２および図３を参照して説明したパケット解析装置15に含まれるマルチメディア・ストリーム検出部37、RTPヘッダモニター部39、およびフィードバック・ジェネレータ41のものと同じである。
【００６４】
メディア配信装置11のRTCP処理部113は、RTCPパケット133に含まれるパケット廃棄率および遅延時間をフィードバック制御部35に渡す。フィードバック制御部35は、これらの情報に基づいて、メディア・ストリームの送信モードを選択する（157）。
【００６５】
以下で上述の３つのモードを説明するが、その前に、無線基地局10からの２つのフィードバックNet-Feeds、SP-Feeds及び図７、図８において線25で表されている無線端末19からのフィードバック（クライアント・フィードバック）を使って、メディア配信装置11がメディア・ストリームの送出レートや送信モードを決定するために必要なパラメータを取得する方法について説明する。
【００６６】
先ず、使用する記号を以下のように定義する：
ｌ1     有線ネットワーク21上でのパケット損失率
Ｒ*l    有線ネットワーク21上で許容される最大送出レート
Ｒ1     メディア配信装置11からの送出レート
Ｒ'1    無線基地局10での受信レート
Ｒ1(2)  ＦＥＣのためのエラー訂正情報をＦＥＣデコーダ72で除去した後であってシェイピング・ポイント13'でのパケット廃棄処理を行う前の無線基地局内部レート
Ｒ1(3)  シェイピング・ポイント13'を出た後の無線基地局内部レート
ｌ2     無線リンク上（つまり、無線装置14と無線端末19の間）でのパケット損失率
Ｒ*2    無線リンク上で許容される最大送出レート
Ｒ2     無線基地局10からの送出レート
Ｒ'2    無線端末19での受信レート
ｒ      メディア・ストリームのコーディング・レート
ここで、無線リンク上への最大送出レートＲ*2は以下の２つの方法の一方を使って無線基地局10で定めることができる。
【００６７】
第１の方法は、無線リンク設定の過程で理想的な最大送出レート情報を使用することである。すなわち、無線リンクを設定する際、この無線リンクに割り当てる資源、具体的にはバンド幅を決めるので、このバンド幅から理想的な、つまり最大限の最大送出レートが決まる。この値をＲ*2として採用する。この方法では、この無線リンクを使用したセッションの間の当該レートは、無線端末19の場所が移動した場合等で使用される無線基地局が変更された場合以外は固定されている。
【００６８】
第２の方法は、無線基地局10から無線リンクへ送出されるために待機しているパケットが入っている無線基地局10内の送信バッファの充填率からこの最大送出レートＲ*2を求める方法である。すなわち、送信バッファの充填率が低下していくか空になっている状態が続いているなら現在の送出レートは最大レートよりも低いことがわかり、逆に充填率が増加傾向にあれば、その逆であることがわかる。このようにして求められるレートＲ*2は多くの場合時間によって変動する。
【００６９】
このような最大送出レートＲ*2の決定は無線基地局10内の例えば無線装置14やそれを制御する装置等で行うことができる。
【００７０】
メディア配信装置11及び無線基地局10からの送出レートＲ1及びＲ2（つまり送信端でのレート）はメディア・ストリームに関連するすべてのパケット、つまりメディア・ストリームのデータ本体だけではなくそれに付加されたＦＥＣ用のパケットや再送されたパケットなども含むすべてのパケットのレートである。有線ネットワークや無線リンク上で起こり得るパケットの欠落のために、夫々の受信端でのレートであるＲ'1及びＲ'2は送信端でのレート以下になる。すなわち下式が成立する。
【００７１】
Ｒ'1≦Ｒ1、  Ｒ'2≦Ｒ2
パケットが有線ネットワークから無線基地局10に到着すると、先ずＦＥＣデコーダ72に与えられ、ＦＥＣが適用されていればここでそのデコードが行われる。その結果、ＦＥＣデコーダを出た後のレートＲ1(2)は無線基地局の受信レートＲ'1以下になる。
【００７２】
ここで、本実施例において使用されているＦＥＣでは、ＦＥＣを適用した結果の出力は元のデータ・パケットとパリティ・パケットからなっており、またパリティ・パケットは元のデータ・パケットとは別のストリームとして送られるものとする。このようなＦＥＣについては、たとえばRFC2733 (An RTP Payload Format for Generic Forward Error Correction)を参照されたい。ＦＥＣデコーダ（無線基地局10に設けられているＦＥＣデコーダ72及び無線端末19に設けられているＦＥＣデコーダ（図示せず））は欠落した元のデータ・パケットを、別ストリームで送られてくるパリティ・パケットを使って再構成する。
【００７３】
パケットが無線基地局を離れる前に、ＦＥＣジェネレータ18は、シェイピング・ポイント13'を出た後のレートＲ1(3)を無線リンクの最大レートＲ*2と比較する。Ｒ1(3)＜Ｒ*2ならば、ＦＥＣジェネレータ18は余剰のバンド幅Ｒ*2−Ｒ1(3)を無線リンク上の欠落パケットを復元するためのＦＥＣのために使用する。結局、無線基地局10からの送出レートＲ2は常に無線リンク上で許容される最大送出レートＲ*2に漸近する。
【００７４】
シェイピング・ポイント13'は、ＦＥＣデコーダ72とＦＥＣジェネレータ18の間に設けられ、有線ネットワーク上のＦＥＣを除去した後のレートＲ1(2)が無線リンクのバンド幅、つまりその最大レートＲ*2よりも大きな場合に、パケットを廃棄する。また、同じＲＴＰシーケンス番号を持っている重複パケットもここで検出して削除する。
【００７５】
無線基地局10からメディア配信装置11への２つのフィードバックNet-Feeds及びSP-Feedsは、それぞれＦＥＣデコーダ72及びＦＥＣジェネレータ18の直前から第１のフィードバック部71及び第２のフィードバック部73を介して行われる。
【００７６】
シェイピング・ポイント13'の前でフィードバックを行う第１のフィードバック部71はフィードバックNet-Feedsをメディア配信装置11へ送り、現在の有線ネットワークの状況を通知する。フィードバックNet-Feedsは統計的なフィードバックであり、中程度の期間（例えば数秒程度）上のパケット損失率や往復時間の平均及び分散のような、パケットウインドウ上で収集された情報をまとめたものを含む。このような統計的なフィードバックは周知であり、もし必要ならばたとえばRFC1889 (Rtp: A transport protocol for real-time application)を参照されたい。
【００７７】
シェイピング・ポイント13'の後でフィードバックを行う第２のフィードバック部73はフィードバックSP-Feedsをパケット受信確認パケット（ACK）の形態でメディア配信装置11へ送り、無線送信の前にどのパケットが欠落したかをメディア配信装置11が判定できるようにする。フィードバックSP-Feedsは短い期間（例えば１秒以内）で送出される。
【００７８】
フィードバックNet-Feeds及びSP-Feedsに加えて、本実施例では無線端末19からも比較的短い間隔で時間遅れの少ないフィードバックをメディア配信装置11へ戻す。
【００７９】
これらのフィードバックによって、メディア配信装置11は以下のような情報を得る。
【００８０】
まず、フィードバックNet-Feedsによって、メディア配信装置11は有線ネットワーク上で許容される最大送出レートＲ*lを知ることができる。また、有線ネットワーク上でのパケット損失率ｌ1はフィードバックNet-Feeds中に明示的に示されている。
【００８１】
フィードバックSP-Feedsによって有線ネットワークの端部での高分解能の、つまりパケット単位のフィードバックが与えられるので、メディア配信装置11はどのパケットが無線基地局10に正しく到着したかが正確にわかる。
【００８２】
更に、フィードバックSP-Feedsと無線端末19からのクライアント・フィードバックによって、メディア配信装置11は無線リンク上でのパケット損失率ｌ2及び無線リンク上で許容される最大送出レートＲ*2を以下の様にして求めることができる。すなわち、先ずフィードバックSP-FeedsをＦＥＣのためのパリティ・パケット・ストリームを除外した元のデータ・パケット・ストリームのみについてのクライアント・フィードバックと比較することによって、メディア配信装置11は無線リンクのＦＥＣ適用後のパケット損失率を求めることができる。また、パリティ・パケット用ストリームについてのクライアント・フィードバックから、メディア配信装置11は無線リンク上でどれだけの量のＦＥＣが適用されているか、つまりパリティ・パケット・ストリームのために使用されているバンド幅を求めることができる。ＦＥＣ適用後のパケット損失率とＦＥＣのためのパリティ・パケット・ストリームのバンド幅（つまりパリティ・パケットのレート）の２つがわかれば、ＦＥＣ適用前の無線リンクの「生の」パケット損失率ｌ2を求めることができる。
【００８３】
本実施例では、無線基地局10はメディア・ストリームに要求される遅延特性、つまり無線端末19の受信バッファ容量に基づいて３つのモードのうちの１つを自動的に選択して動作する。以下にこれらのモード、モード１からモード３を説明する。
【００８４】
モード１
無線リンク上で欠落パケットを所要回数再送することによるパケット到着タイミングの大きなジッタを許容することができる大きな受信バッファを無線端末19（クライアント）を備えている場合にこのモードが適用される。なお、第３世代携帯電話の通信方式においては、当業者に周知のようにリンクレイヤで再送を行うように無線基地局10が無線端末19側に設定を行うことができる。その具体的な構成・動作自体は本願発明とは直接に関係しないが、必要ならH. Holma and A. Toskala, Eds., WCDMA for UMTS: Radio Access for Third Generation Mobile Communications, Wiley, 2001を参照されたい。従って、モード１の実現に当たって、第３世代携帯電話のリンクレイヤでの再送機能を利用することができる。すなわち、無線基地局10が無線端末19との間のエラー制御モードを再送を行うモードに設定しておけば、アプリケーションレイヤからはトランスペアレントな態様で、リンクレイヤが以下の動作を行う。すなわち、リンクレイヤにおいて、無線端末19で欠落パケットが検出されると、無線端末19は無線基地局10へ当該パケットの再送を要求する。無線基地局10はこの再送要求を受け取ると、当該パケットのこれまでの再送回数を当該モード設定時に定めた最大再送回数と比較し、既に最大再送回数に達している場合には再送失敗を無線端末19へ通知する。まだ最大再送回数に達していない場合には、無線基地局10は一時的に記憶している送信済みパケットから該当するものを無線端末19へ向けて再送する。欠落パケットの最大再送回数は、無線リンクのパケット損失率ｌ2及び再送を行うことによるパケット損失率改善の目標値によって決まるが、これらは適切なあるいは標準的な値が予めわかっていたり、あるいは上述のようにして測定によって求めることができる。再送されたパケットを受信した無線端末19は、再送されたパケットを用いてメディア・ストリームの修復を行う。従って、アプリケーションレイヤからは、単に最初にエラー制御モードを上述の再送を行うモードに設定するだけで、メディア・ストリームが無線基地局10から誤りなしで受信されているように見える。これにより、無線基地局10から無線端末19への無線リンクは実質的にパケット損失はないが、パケットの伝送遅延には大きなばらつきがもたらされる。
【００８５】
また、無線基地局10からのフィードバックNet-Feedsを使って、メディア配信装置11において有線ネットワークの輻輳制御が行われる。
【００８６】
更に、無線基地局10からのフィードバックSP-Feedsを使って、有線ネットワーク上での欠落パケットの再送がアプリケーションレイヤで行われる。モード１においては無線リングはパケット欠落がほとんどないので、無線基地局10からのフィードバックは無線端末からのフィードバックとほとんど同じものになるが、フィードバックSP-Feedsは無線端末からのフィードバックに比べてメディア配信装置11への到着が大幅に早くなる。
【００８７】
エラー訂正コードを常に付加するＦＥＣに比べて、パケット欠落が実際に起こった時だけパケット再送を行う方が効率が良い。モード１ではパケット再送に伴う遅延やジッタは問題にならないので、有線ネットワークと無線リンクの両方でＦＥＣではなく再送を採用するのである。
【００８８】
モード２
無線端末19の受信バッファの大きさが、有線ネットワークで欠落パケットを所要回数再送するには充分であるが、無線リンク上でのそのような再送を許容するほどには大きくない場合にこのモードになる。
【００８９】
モード２においては、有線ネットワーク上でパケットの欠落が起こった時は、モード１と同様に、無線基地局10からのフィードバックSP-Feedsによりメディア配信装置11が欠落したパケットの再送を行い、無線基地局10と無線端末19の間の無線リンク上で発生するパケット欠落に対しては、ＦＥＣを適用することで対応する。
【００９０】
通常は、無線リンクの方が有線ネットワークに比べて伝送レートが小さいため、ここではそのような典型的な場合、つまりＲ*l＞Ｒ*2が成立することを仮定する。上述したように、メディア配信装置11はフィードバック情報からＲ*2、Ｒ*l、ｌ2を求めることができる。これにより、メディア配信装置11はメディア・コーディング・レート（つまりメディア・ストリームの送信レート）ｒを適切に選択して、無線リンク上でメディア・ストリームに使用されないバンド幅Ｒ*2−ｒが無線リンク上の損失率ｌ2に抗してエラー訂正を行って欠落パケットをほとんど復元するのに充分なエラー訂正用のパリティ・パケット・ストリームを伝送できるようにする。
【００９１】
有線ネットワーク上ではその余剰のバンド幅Ｒ*1−ｒを使って、アプリケーション・レイヤでの再送を行う。また、重複したパケットは無線基地局10で廃棄されるので、そのようなパケットが無線リンクのバンド幅を占有してしまうことはない。
【００９２】
モード３
無線基地局10のバッファ容量が非常に小さいために、無線リンク上での再送だけではなく、有線ネットワーク上で欠落パケットの所要回数の再送を行うことによる遅延も許容できない場合、このモードが適用される。
【００９３】
モード３においては、メディア配信装置11は有線ネットワーク上のエラー・レートなどのエラー特性に適合したＦＥＣを適用してメディア・ストリームを無線基地局へ向けて送出する。このＦＥＣ用のパリティ・ストリームは無線基地局10のＦＥＣデコーダ72によって除去される。ＦＥＣジェネレータ18は無線リンクのエラー特性に適合した別のＦＥＣを適用して無線端末19へ向けて送出する。
【００９４】
再び図９を参照すると、フィードバック制御部35は、RTCP処理部から渡される無線基地局10のリセプション・レポートに含まれる情報から上述の３つの送信モードのうちどれが適当かを判定し、送信モードを決定する（157）。
【００９５】
フィードバック制御部35は、第2のフィードバック部73から送られてくるRTPパケットの受信確認信号（ACK）に基づいてメディア・ストリームのパケットの欠落を判定し（141）、パケット欠落が検出されたときは、通信がモード１またはモード２で行われているかどうか判定する（151）。モード１またはモード２で通信が行われているときは、図６のブロック143、145、147、149に関連して説明したパケットの再送手順を実行する（153）。通信がモード３で行われているときは、もし可能であってかつそうすることが望ましいならば、使用するエラー訂正符号をより適切なものに変更する（155）。
【００９６】
以上にこの発明を具体的な実施例について説明したが、この発明はこのような実施例に限定されるものではない。
【図面の簡単な説明】
【図１】この発明の一実施形態の概念を示すブロック図。
【図２】この発明の一実施例の構成を示すブロック図。
【図３】この発明の代替実施例の構成を示すブロック図。
【図４】ビデオの圧縮符号化フォーマットの一例を示す図。
【図５】ＭＰＥＧのＩピクチャおよびＰピクチャのシーケンスの例を示す図。
【図６】この発明の第１および第２の実施例における通信のシーケンスを示す図。
【図７】この発明のさらにもう一つの実施例の概念を示すブロック図。
【図８】図7の実施例の詳細な構成を示すブロック図。
【図９】この発明の第３の実施例における通信のシーケンスを示す図。
【符号の説明】
１０        無線基地局
１１        メディア配信装置
１３        シェイピング・ポイント（調整手段）
１５        パケット解析装置
１９        無線端末装置
【図１】
0004116470.tif 000002
【図２】
0004116470.tif 000003
【図３】
0004116470.tif 000004
【図４】
0004116470.tif 000005
【図５】
0004116470.tif 000006
【図６】
0004116470.tif 000007
【図７】
0004116470.tif 000008
【図８】
0004116470.tif 000009
【図９】
0004116470.tif 000010