(57)【要約】      （修正有）【課題】ＡＶストリームデータの伝送エラー部分を簡単に視聴する。【解決手段】第１の無線通信装置からＡＶデータをリアルタイムに送信して第２の無線通信装置で再生する無線通信システムにおいて、第１の無線通信装置はデータを当該送信とは独立して第２の無線通信装置に送信する独立送信手段を有しており、第２の無線通信装置にて受信したＡＶデータに回復不能な伝送エラーが発生した場合には、その発生区間を特定して当該区間を含む区間のデータを第１の無線通信装置に要求して蓄積し、当該データを再生中のＡＶデータとは独立してピクチャインピクチャ機能などにより再生する。【選択図】図１０
2005295342.tif 000002
【特許請求の範囲】
【請求項１】
ＡＶデータをリアルタイムに送信する送信部を有する第１の無線通信装置と、該第１の無線通信装置から送られたＡＶデータをリアルタイムに受信する受信部と、受信したＡＶデータを出力する出力部と、を有する第２の無線通信装置と、を有する無線通信システムであって、
前記第１の無線通信装置は、前記第２の無線通信装置から要求される前記データをリアルタイムに送信している前記ＡＶデータとは独立して前記第２の無線通信装置に送信する独立送信手段を有しており、
前記第２の無線通信装置は、前記第１の無線通信装置から前記第２の無線通信装置へ伝送中の前記ＡＶデータにリアルタイムには回復不能な伝送エラーが発生した場合にその区間を特定する伝送エラー発生区間特定手段と、前記区間を含むある区間のデータを前記第１の無線通信装置に要求する要求手段と、該要求に応じて前記第１の無線通信装置から送信された前記データの少なくとも一部を蓄積する蓄積手段と、該蓄積手段に蓄積したデータを現在再生中の前記ＡＶデータとは独立して再生する独立再生手段と
を有することを特徴とする無線通信システム。
【請求項２】
前記独立再生手段は、前記区間内の前記ＡＶデータ及び該ＡＶデータと対応し前記蓄積手段に蓄積されたデータとを合成する合成手段を含むことを特徴とする請求項１に記載の無線通信システム。
【請求項３】
前記独立再生手段は、ピクチャインピクチャ機能を用いて前記区間内の前記ＡＶデータ及び該ＡＶデータと対応し前記蓄積手段に蓄積されたデータと合成する手段を有することを特徴とする請求項２の無線通信システム。
【請求項４】
前記独立再生手段は、オーディオミキサ機能を用いて前記区間内の前記ＡＶデータ及び該ＡＶデータと対応し前記蓄積手段に蓄積されたデータと合成する手段を有することを特徴とする請求項２の無線通信システム。
【請求項５】
前記独立送信手段は、前記第２の無線通信装置側から要求された複数のエラー区間を含む一定区間のデータを送信することを特徴とする請求項１から４までのいずれか１項に記載の無線通信システム。
【請求項６】
前記要求手段は、複数の回復不能なエラー区間を含む一定区間を指定して要求することを特徴とする請求項１から５までのいずれか１項に記載の無線通信システム。
【請求項７】
前記独立再生手段は、複数のＡＶデータ片をまとめて再生する手段を有していることを特徴とする請求項１から６までのいずれか１項に記載の無線通信システム。
【請求項８】
さらに、前記要求手段によりデータを要求する際に、ＡＶデータの送信を行っていないチャネル又は現在使用しているチャネルにおける現在使用していない帯域を調べる手段と、一度に要求するデータが前記チャネルの伝送容量又は前記使用していない帯域の伝送容量を超えないように要求するデータを分割する手段と、を備えることを特徴とする請求項１から７までのいずれか１項に記載の無線通信システム。
【請求項９】
前記独立再生手段は、前記蓄積手段へのデータ蓄積に応じて自動的に再生を開始する機能を有していることを特徴とする請求項１から８までのいずれか１項に記載の無線通信システム。
【請求項１０】
前記要求手段が分割して区間データを要求した場合に、前記蓄積手段へのデータ蓄積を検知した後に自動的に再生を開始するタイミングとして分割した全ての区間データの蓄積後を選択することを特徴とする請求項９に記載の無線通信システム。
【請求項１１】
前記第２の無線通信装置が要求したデータが前記蓄積手段に蓄積された旨を報知する報知手段と、再生タイミングを入力により指示する入力手段と、を有し、前記独立再生手段は、前記入力手段に入力されたタイミングに基づいて前記蓄積手段に蓄積されたデータを再生することを特徴とする請求項１から１０までのいずれか１項に記載の無線通信システム。
【請求項１２】
前記報知手段が、受信している前記ＡＶデータを表示する表示装置以外の手段であることを特徴とする請求項１１に記載の無線通信システム。
【請求項１３】
前記報知手段は、受信している前記ＡＶデータを現在表示している表示装置上に表示するオンスクリーンディスプレイ（ＯＳＤ）であることを特徴とする請求項１１又は１２に記載の無線通信システム。
【請求項１４】
前記報知手段により前記蓄積手段にデータが蓄積されたことが報知された後の一定時間内において再生タイミングに関する指示の有無を検出する検出手段と、
前記検出手段により、指示が無いことが検出された時に、前記蓄積手段に蓄積されたデータを破棄するように制御することを特徴とする請求項１１から１３までのいずれか１項に記載の無線通信システム。
【請求項１５】
前記第２の無線通信装置が前記蓄積手段に蓄積したデータを再生する際に、ＡＶデータの構成要素から選択して再生する機能を備えることを特徴とする請求項１から１４までのいずれか１項に記載の無線通信システム。
【請求項１６】
複数の第２の無線通信装置を備えており、
前記第１の無線通信装置が一定時間内に複数の前記第２の無線通信装置から区間データの送信を要求されたか否かを判定する判定手段を備えており、該判定手段が一定時間内に複数の前記第２の無線通信装置からの要求を受けたと判断した時に、該第２の無線通信装置に送信する区間データをブロードキャストまたはマルチキャストにより送信する手段を有することを特徴とする請求項１から１５までのいずれか１項に記載の無線通信システム。
【請求項１７】
前記第１の無線通信装置から送信される区間データが、一定時間内に複数の前記第２の無線通信装置から要求された、複数または全ての区間を含むデータであることを特徴とする請求項１６に記載の無線通信システム。
【請求項１８】
送信元からリアルタイムに送信されるＡＶデータを受信する受信部と、受信した前記ＡＶデータを出力する出力部と、を有する無線通信装置であって、
前記ＡＶデータにリアルタイムには回復不能な伝送エラーが発生した場合にその区間を特定する伝送エラー発生区間特定手段と、
前記区間を含むある区間のデータを前記送信元に要求する要求手段と、
該要求に応じて前記送信元から送信された前記データの少なくとも一部を蓄積する蓄積手段と、
該蓄積手段に蓄積したデータを現在再生中の前記ＡＶデータとは独立して再生する独立再生手段と
を有することを特徴とする無線通信装置。
【請求項１９】
ＡＶデータをリアルタイムに送信する送信部を有する第１の無線通信装置であって、
前記第１の無線通信装置は、送信先から要求されるデータを、リアルタイムに送信している前記ＡＶデータとは独立して前記送信先に送信する独立送信手段を有しいていることを特徴とする無線通信装置。
【請求項２０】
送信元からリアルタイムに送信されるＡＶデータを受信する受信部と、受信した前記ＡＶデータを出力する出力部と、を有する無線通信装置を用いた無線通信方法であって、
前記ＡＶデータにリアルタイムには回復不能な伝送エラーが発生した場合にその区間を特定するステップと、
前記区間を含むある区間のデータを前記送信元に要求するステップと、
該要求に応じて前記送信元から送信された前記データの少なくとも一部を蓄積するステップと、
蓄積したデータを現在再生中の前記ＡＶデータとは独立して再生するステップと
を有することを特徴とする無線通信方法。
【請求項２１】
送信元からリアルタイムに送信されるＡＶデータを受信する受信部と、受信した前記ＡＶデータを出力する出力部と、を有する無線通信装置に、
前記ＡＶデータにリアルタイムには回復不能な伝送エラーが発生した場合にその区間を特定するステップと、
前記区間を含むある区間のデータを前記送信元に要求するステップと、
該要求に応じて前記送信元から送信された前記データの少なくとも一部を蓄積するステップと、
蓄積したデータを現在再生中の前記ＡＶデータとは独立して再生するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線通信技術に関し、特に、複数のリンクが同時に使用できるネットワーク環境下における、ＡＶストリーム等のストリーム情報の伝送技術に関する。
【背景技術】
【０００２】
従来、主として企業内で使用されていたＬＡＮを中心にしたネットワーク技術は、パーソナルコンピュータに代表される個人向け情報機器やＡＶ機器を含むデジタル放送対応機器などに代表される情報処理関連製品も普及し、一般家庭における利用を考慮したネットワーク技術が提案されてきている。家庭内での利用を前提とした場合に、特にＡＶデータ伝送を容易にするための規格としてＩＥＥＥ１３９４やＵＳＢなどのような、いわゆるアイソクロナス伝送モードを備える伝送ネットワーク規格が提案されている。
【０００３】
このアイソクロナス伝送は、単位時間当たりにある一定量までのデータをネットワークに送信することが許可されている転送方式であり、ネットワークの帯域効率を守りつつ、リアルタイム性を要求するＡＶデータ伝送に必要な低レイテンシを実現できる。しかしながら、一般的なアイソクロナス伝送においては、低レイテンシを確保するために、受信に失敗したデータの再送処理を行わないため、本来は時間的な連続性を持っている必要がある映像情報が欠落するというような問題が生じる。かかる問題を解決するために、アシンクロナス伝送を利用して再送処理を行い損失したデータの回復を試みることにより、アイソクロナス伝送上のパケット損失に関するデータ補完機構を備える技術が提案されている（例えば、特許文献１、２参照）。
【０００４】
一方、従来からネットワークの伝送路としては有線媒体が使用されていたが、利便性のために伝送路として無線媒体を使用する技術も提案されてきている。イーサネット（ＩＥＥＥ８０２．３等）を無線化するものとして無線ＬＡＮ（ＩＥＥＥ８０２．１１等）が、ＡＴＭを無線化するものとしてＨｉＳＷＡＮ(ARIB STD T70)が、ＩＥＥＥ１３９４を無線化するものとして無線ホームリンク（ARIB STD T72）が提案されている。これらの方式は通信媒体のエラーが有線環境よりもはるかに多いという無線環境に適応させるために、冗長符号を利用してエラーの回復を試みる方法を提供し、或いは、自動再送処理を使用して有線環境下とさほど変わらない通信環境を提供している。
【特許文献１】特開２０００−４９８３３号公報
【特許文献２】特開２０００−３４１２５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１又は２に記載の技術のように、アイソクロナス伝送上のパケット損失に関してアシンクロナス伝送を利用して再送処理を行い、損失したデータの回復を試みる機構を備える場合、以下のような問題が生じる。
１）送信側と受信側両方に再送管理用のバッファを用意して、全てのデータについてバッファに通す必要があるため、バッファ通過分の時間だけレイテンシが増えてしまう。
２）伝送媒体が無線のようにエラーが多かったり、トランザクションに時間を要する媒体であったりする場合は、バッファの大きさを大きくする必要があり、同時にバッファ通過分だけレイテンシも大きくなってしまう。
３）さらに、伝送媒体の総帯域に比べて、その帯域のかなりの割合を占めるストリームデータを伝送する場合には、再送用の帯域が足りず、再送データの伝送が間に合わずに伝送中のストリームが途切れてしまい、その結果表示できない映像が発生する。
４）無線環境下では伝送路上に障害物が発生するなどの理由で比較的長時間にわたって回復不能なエラーが発生することがあり、トランザクションを要して欠落したデータの再送処理を行ってもリアルタイムにＡＶデータを視聴できない場合が発生する。
【０００６】
本発明は、上記１）〜４）までの少なくともいずれかの問題点を解決する手段を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る無線通信装置は、第１の伝送手段によるデータ伝送と並行して、受信側端末から要求されたデータを第１の伝送手段とは異なる第２の伝送手段２を用いて再送する手段を送信側端末に設ける。前記第１の伝送手段において発生した回復不能なエラーに関してこのエラーが発生した区間のデータを送信側端末に要求する手段と、前記第１の伝送手段と第２の伝送手段とで送られたデータをそれぞれ受信し再生する複数の再生手段を受信側端末に備える。これにより、第１の伝送手段におけるデータ再生に影響を与えずに再送データについても同時に再生することができる。
【０００８】
すなわち、本発明の一観点によれば、ＡＶデータをリアルタイムに送信する送信部を有する第１の無線通信装置と、該第１の無線通信装置から送られたＡＶデータをリアルタイムに受信する受信部と、受信したＡＶデータを出力する出力部と、を有する第２の無線通信装置と、を有する無線通信システムであって、前記第１の無線通信装置は、前記第２の無線通信装置から要求される前記データをリアルタイムに送信している前記ＡＶデータとは独立して前記第２の無線通信装置に送信する独立送信手段を有しており、前記第２の無線通信装置は、前記第１の無線通信装置から前記第２の無線通信装置へ伝送中の前記ＡＶデータにリアルタイムには回復不能な伝送エラーが発生した場合にその区間を特定する伝送エラー発生区間特定手段と、前記区間を含むある区間のデータを前記第１の無線通信装置に要求する要求手段と、該要求に応じて前記第１の無線通信装置から送信された前記データの少なくとも一部を蓄積する蓄積手段と、該蓄積手段に蓄積したデータを現在再生中の前記ＡＶデータとは独立して再生する独立再生手段とを有することを特徴とする無線通信システムが提供される。これにより、伝送エラーの無い品質の良いデータに基づいて、不良区間のデータを独立して再生することができる。
【発明の効果】
【０００９】
以上説明したように、本発明の無線通信装置によれば、エラーが多かったりトランザクションに時間を要したりする回線においても主要ＡＶデータの受信に大きなバッファを用いること無く、低レイテンシを確保したアイソクロナス伝送を行うことができ、エラーが発生した部分については自動的にデータを取得し自動的にデータの関連する部分の視聴を行うことが可能となる。
【発明を実施するための最良の形態】
【００１０】
本明細書において、「ＡＶデータとは独立して再生する独立再生手段」とは、例えば、リアルタイムに再生されるＡＶデータとは異なるデータとして作成され、ＡＶデータの再生タイミングとしてもＡＶデータに関する再生時間とは異なる時間に再生することを意味する。
【００１１】
以下、本発明の無線通信技術の一実施の形態について、図面を参照しつつ説明を行う。図２（Ａ）は、本発明に係る無線通信技術を用いた無線通信システムの基本構成を示す図である。図２（Ａ）に示すように、本発明に係る無線通信システムは、例えば、モバイル液晶テレビジョン装置などを含み、送信ユニット１と、この送信ユニットとは基本的に分離して用いることができる受信ユニット２と、を有して構成されている。上述したモバイル液晶テレビジョン装置を例にすると、送信ユニット１は、チューナと無線送信機とを有しており、例えばテレビ放送による音声と映像とを含む情報をチューナにより受像し、受像した情報を送信可能な形態に処理した後のデータを送信機から受信ユニット２に向けて無線により送信する。受信ユニット２は、無線受信機と出力部、例えばスピーカとモニタとを有しており、ユーザは、送信ユニット１を介して音声を含む映像データをモニタとスピーカとにより視聴することができる。
【００１２】
図１は、図２（Ａ）に示した無線通信システムの構成をより詳細に示した図であり、本発明の第１の実施の形態による無線通信装置の受信側と送信側との構成例を示す図である。図１に示すように、本実施の形態による無線通信装置は、ＡＶデータの送信ブロック１０１とＡＶデータの受信ブロック１０２とを有している。送信側ブロック１０１は、パケットデータを送受信するトランシーバユニット１０３と、トランシーバ１０３に入出力する電波を送受信するためのアンテナ１０４と、入力されるオーディオストリームとビデオストリームとを混合するマルチプレクサ１０５と、マルチプレクサ１０５から出力されたデータにタイマ１０７からのデータに従ってタイムスタンプを付加するタイムスタンプ付加ブロック１０６と、現在時刻を示しつづけるタイマブロック１０７と、タイムスタンプを付加した送信パケットを送信前と送信後において共にある程度（例えば決められた一定量）だけ残しておくための送信バッファブロック１０８と、制御部１１０からの指示に従って送信バッファ１０８内に蓄積されているデータを読み出し、定期的にトランシーバ１０３へ送り、また制御部１１０からの非同期パケットを送信バッファから１０８の送信データと衝突しないようにし、またトランシーバ１０３からの受信データを制御部１１０に送る調停ブロック１０９と、タイマ１０７、送信バッファ１０８、調停ブロック１０９を制御して送信側ブロック全体を制御する制御ブロック１１０と、を有している。
【００１３】
受信側ブロック１０２は、その中に、パケットデータを送受信するためのトランシーバユニット１１１と、トランシーバ１１１に入出力する電波を送受信するためのアンテナ１１２と、トランシーバ１１１で受信されたパケットの種類を判定し、エラー判定ブロック１１４と制御部１１８とに振り分けるパケット識別ブロック１１３と、タイムスタンプが付加された一連のストリームパケット中からエラーが発生している部分を検出し、そのエラーの発生している部分のタイムスタンプを制御部１１８に通知するエラー判定ブロック１１４と、エラー判定ブロック１１４から出力されたストリームパケットからビデオストリームとオーディオストリームとに分離するデマルチプレクサ１１５と、２つのデマルチプレクサ１１５・１２３から出力されたビデオストリームをピクチャインピクチャで合成するＰｉｎＰブロック１１６と、２つのデマルチプレクサ１１５・１２３から出力されたオーディオストリームを混合するミキサブロック１１７と、受信側ブロック内の各ブロックを監視ならびに制御して受信側ブロック全体を制御するブロック１１８と、現在時刻を示しつづけるタイマブロック１１９と、制御部１１８からの指示で様々な表示を行う表示部ブロック１２０と、受信側ブロック１０２を操作する人によって操作され、受信側ブロック１０２の動作モードを設定したり、制御部１１８に対して種種のイベントを発生させる操作ブロック１２１と、制御部１１８からの制御で再表示用のデータを一時的に蓄える再表示バッファメモリブロック１２２と、再表示バッファ１２２から出力されるストリームデータをビデオストリームとオーディオストリームとに分離するデマルチプレクサ１２３と、を有している。ＰｉｎＰブロック１１６は、後述する調停回路１１０４（図１１、図１２）を有している。
【００１４】
次に、図１に示す無線通信システムの動作について詳細に説明する。本実施の形態による無線通信システムは、その最小構成単位として、図２（Ａ）においても説明したように送信側無線装置１０１と受信側無線装置１０２とをそれぞれ１つずつ備えている。ＡＶストリームを送信するに先立って、送信側１０１と受信側１０２とでリンクを張り（例えばお互いのＩＤを知らせ合い）、ストリーム用の帯域を確保する必要がある。リンクを張る手順と帯域を確保する手順に関しては無線通信技術においては公知であり、その説明を省略するが、例えば、具体的な手順としては、ＩＥＥＥ１３９４規格で使用している手順がそのまま適用可能である。
【００１５】
図２（Ｂ）は、無線通信に使用する帯域を確保した状態の概要を示す図である。適宜図１も参照しつつ説明を行う。図２（Ｂ）に示すように、無線通信に使用する帯域中には、定期的に送られるフレーム開始信号２０１と、フレーム開始信号２０１に続いて確保された帯域の帯域信号２０２とが存在し、その後に余剰帯域として使用される余剰信号２０３が位置する。リンクを確保した後に、送信側１０１は、例えば放送局から送信され送信側１０１で受信されたストリームデータの受信側１０２への送信を開始する。ストリームデータは、オーディオ（音響）ストリームとビデオ（映像）ストリームとを含むものとする。
【００１６】
図３に示すように、まず、マルチプレクサ１０５にオーディオ（音響）ストリームとビデオ（映像）ストリームとを入力する。マルチプレクサ１０５はオーディオストリームとビデオストリームとを一定時間毎に切り出し、交互に並べることにより多重化を行う（マルチプレックス（多重化）ストリームを作成する。
【００１７】
図４は、タイムスタンプを付加する手順を示す図である。適宜図１も参照する。図４に示すように、タイムスタンプ付加ブロック１０６において、多重化されたマルチプレクスストリームデータに対してタイムスタンプを付加する。マルチプレクサ１０５において、交互に並んでいるオーディオストリームデータとビデオストリームデータとの１つずつの組に対してタイマ１０７から送られてくる現在時刻を示すタイムスタンプを付加する。タイムスタンプを付加された多重化ストリームは、送信バッファ１０８に送られ蓄積される。送信バッファ１０８は、例えば大きなリングバッファの形態を有しており、送信後のストリームデータも送信バッファ１０８が一周するまでの間は保持され、制御部１１０からの要求に従って取り出せるようになっている。
【００１８】
調停部１０９は、制御部１１０からの定期的な指示に従って送信バッファ１０８から図５に示すように一定量のデータ（Ｄ）を取り出し、取り出したデータにパケットヘッダ（ＰＨ）を付加する。パケットヘッダＰＨにはエラー検出のためのチェックサムと、単純増加でサイクリックなシーケンス番号と、が含まれ、受信側１０２でパケットの抜けが発生した場合にこのパケット抜けを検出するために用いられる。サイクリックの周期は、定常的な発生が予想されるエラー発生期間に比べて十分に大きくなるように設定する必要がある。
【００１９】
図６に示すように、パケットヘッダＰＨを付加されたパケット群は、制御部１１０によってトランシーバ１０３に送られ、アンテナ１０４から電波として送信される。この時、制御部１１０はタイマ１０７を監視しつづけて正確なタイミングで一定時間t毎に調停部１０９に対して一定量のストリームデータをトランシーバ１０３へ送るように指示する。送信データは、トランシーバ１０３、アンテナ１０４を経由して空中に放射され、受信側ブロック１０２に到達しアンテナ１１２より取り込まれ、トランシーバ１１１によって復調される。復調されたパケットは全てパケット識別１１３へ送られる。ストリームパケットはエラー判定部１１４へ送られ、ストリームパケット以外のパケットは制御部１１８へ送られる。
【００２０】
エラー判定部１１４に送られたストリームパケットは、パケットに付加されたパケットヘッダＰＨに含まれるチェックサムによってパケットの内容の正当性が検査された後に、パケットヘッダＰＨに含まれるシーケンス番号と多重化されたストリームデータに付加されているタイムスタンプと、に基づいて、エラー等でどのパケットが損失したかについて判定される。シーケンス番号を使用して判定する場合は、順次受信されるパケットヘッダ中のシーケンス番号を調べ、シーケンス番号が単純増加しているか、或いは、サイクリック周期に従って初期状態となっているかを調べることによりエラーの判定を行う。この様子を図７に示す。図７に示す判定においては、サイクリック周期よりも長いエラーは検出できない可能性があるため、以下に説明する方法であって、ストリームデータ内のタイムスタンプによる判定方法も併用してエラー判定を行う。
【００２１】
ストリームデータ内のタイムスタンプを利用してエラーの判定を行う方法は、予めリンクを確保した時点で帯域が決められるため、単位時間に送られてくるストリームデータの量を監視することによって行うことができる。まず、受信したパケット群からシーケンス番号による判定で失われた損失パケット（図８ａ）が含まれるタイムスタンプ・データのブロックを取り除く（図８ｂ）。残ったストリームデータから付加されているタイムスタンプを取り出し、タイムスタンプ直後から次のタイムスタンプまでのデータサイズが、次のタイムスタンプまでの間隔に対して送られて来るべきデータ量に比べて少ない場合に、その間でパケットの損失が発生したと判断することができる（図８ｃ）。
【００２２】
エラー判定部１１４は、パケットの損失が発生したと判断されたときは、損失が発生した区間の前後のタイムスタンプＴＳを制御部１１８に通知する。尚、エラー判定部１１４は、チェックサムによるエラー検出によりエラーと判定されたエラーパケットＥＰのみを破棄し（図９ａ）、それ以外のデータは、デマルチプレクサ１１５に送られる。エラーが検出されなかったストリームデータは、デマルチプレクサ１１５に送られる。デマルチプレクサ１１５において不良（異常）ブロックＡＰを検出・除去し（図９ｂ）、タイムスタンプＴＳも除去した後に（図９ｃ）、多重化されたストリームデータをビデオストリームＶＳとに分離する（図９ｄ）。この際、伝送中のエラーで片方のストリームだけが壊れている場合（再生不可ブロックＢＶＳ）には、壊れていない方のストリーム（図ではオーディオストリームＡＳ）の出力は止めないようにする。
【００２３】
図１０は、以上の手順を実現した際のメッセージフローの一例を示す図である。図１０に示す例では、矢印で示される受信側からの１回の追加ストリームパケット要求ＡＳＰＲに対して、送信側が追加ストリームパケットＡＳＰを２度に分けて送信している。デマルチプレクサ１１５が分離したビデオストリームはピクチャインピクチャ部１１６へ、オーディオストリームはミキサ部１１７へ送られる。ピクチャインピクチャ部１１６は、マルチプレクサ１１５から出力された第１のビデオストリームに、もう１のデマルチプレクサ１２３から第２のビデオストリームが出力された時に、ピクチャインピクチャ機能を利用して、出力するビデオストリームに第１と第２の２つのビデオストリームを合成するブロックである。このピクチャインピクチャは、一般的な主画像中の一部の領域に副画像を合成して表示させるものである。
【００２４】
図１１は、ピクチャインピクチャ処理を行うためのＰｉｎＰ処理部の構成例を示す図である。図１１に示すように、ＰｉｎＰ処理部は、符号化された主ビデオストリームを復号する第１デコーダ１１０１と、入出力にＦＩＦＯを備えており復号されたビデオ情報をフレームメモリ１１０５に書き込む際に衝突が起こらないように調停を行う第１調停ブロック１１０２と、副ビデオストリームの符号化を復号する第２デコーダ１１０３と、入出力にＦＩＦＯを備えてフレームメモリ１１０５に書き込む際に衝突が起こらないようにする第２調停ブロック１１０４と、復号したビデオ情報を書き込んで出力用のビデオ情報を合成し一時保存するフレームメモリ１１０５と、入出力にＦＩＦＯを備えておりフレームメモリ１１０５からビデオ情報を読み出す際に衝突が起こらないようにする調停ブロック１１０６と、調停ブロック１１０６が読み出したビデオ情報をビデオ信号に変換するビデオ信号エンコーダ１１０７と、を有している。
【００２５】
図１１に示すＰｉｎＰ処理部の動作について図１２を参照しつつ説明を行う。図１１及び図１２に示すように、主ビデオストリーム側の第１調停部１１０２は、フレームメモリ１１０５上に実画像サイズでビデオ情報を書き込み、副ビデオの第２調停部１００４は、主ビデオの第１調停部１１０２が書き込んだビデオ情報の上から副ビデオのビデオ情報を上書きする。この際、ビデオ情報の大きさを縮小して予め決められた場所に書き込む。ビデオ信号エンコーダ１１０７に情報を送るための第３調停部１１０６は、副ビデオの第２調停部１１０４が副ビデオ情報を上書きしたことを確認した後に、フレームメモリ１１０５から全画面のビデオ情報を読み出し、そのビデオ情報をビデオ信号エンコーダ１１０７に送る。ビデオ信号エンコーダ１１０７は、第３調停部１１０６から出力されたビデオ情報を再びビデオストリームにエンコードし直す。尚、フレームメモリ１１０５上にビデオ情報を書き込む際に、副画面の情報を強調するために主ビデオのビデオ情報の輝度を下げる処理を行ったり副ビデオのビデオ情報の輝度を上げる処理を行ったりしても良い。また、副ビデオに表示するべき情報が無い場合は、副ビデオの表示そのものを停止してもよい。
【００２６】
図１に示すミキサ部１１７は、デマルチプレクサ１１５から出力されたオーディオストリームに、もう１つのデマルチプレクサ１２３からオーディオストリームが出力された場合に出力のオーディオストリームに双方のオーディオストリームを加算したものを出力する。図１３は、ミキサ部１１７の構成例を示す図である。図１３に示すように、ミキサ部１１７は、符号化された主オーディオストリームを復号して波形加算ブロック１３０３に送る第１デコーダ１３０１と、符号化された副オーディオストリームを復号して波形加算ブロック１３０３に送る第２デコーダ１３０２と、復号された主オーディオストリームと副オーディオストリームとの波形データを加算して合成された波形を生成する波形加算ブロック１３０３と、波形加算ブロック１３０３において合成された波形データを再び符号化して合成オーディオストリームを生成するオーディオエンコーダ１３０４と、を有する。尚、図１３に示す構成の代わりに、副オーディオを強調するために波形合成時に主オーディオストリームの波形の振幅を減少させたり、副オーディオストリームの波形の振幅を増加させたりする構成にしても良い。
【００２７】
次いで、以下にエラーが発生したときの処理の流れについて図１４を参照しつつ詳細に説明する。適宜、図１を参照して説明する。エラー判定部１１４からエラーが発生したストリームデータの時間情報を受け取った制御部１１８は、エラーが発生した区間にマージンとして例えば前後１秒間を加えた時間帯のストリームデータを送信側に要求する。ストリームデータを要求する際は、ストリームデータ要求パケット１４０１を制御部１１８が生成し、それをトランシーバ１１１に対して送信する要求を行い、送信側ユニットにこの要求を伝える。送信側ユニット１０１では、トランシーバ１０３で受信したストリームデータ要求パケット１４０１をデコードし、調停ブロック１０９を経由して制御部１１０に送る。
【００２８】
ストリームデータ要求を受けた制御部１１０は、送信バッファ１０８を調べ、要求された時間帯のストリームデータが送信バッファ１０８内に残っているか否かを調べ、残っていればそのデータを一度制御部１１０に読み出し、追加ストリームデータ１４０２のパケットを生成し、調停ブロック１０９に対し受信側ユニット１０２に追加ストリームデータ１４０２のパケットを送信させる。
【００２９】
この際、調停ブロック１０９は送信中のストリームデータを送るために確保した帯域以外の帯域を使用して送信するように調停する。残っている帯域が少ない場合は、調停ブロック１０９は複数回に分けて追加ストリームデータ１４０２を送信しもよい。この様子を図１４（Ｂ）に示す。図１４（Ａ）と異なり、ストリームパケット１４０１が定期的かつ頻繁に流れるために、追加ストリームデータ１４０２を一度に送ることが出来るほどの余剰帯域（時間的に隣接するストリームパケット１４０１間の時間間隔）がない場合についての説明である。このような場合は、図１４（Ｂ）に示すように追加ストリームデータ１４０２を余剰帯域に収まるように複数のパケットに分割し、定期的に流れるストリームパケット１４０１の間の時間領域に当てはまるように割り当てて送信する。図１４（Ｂ）では、３つに分割した追加ストリームデータパケット１４０２を、余剰帯域に送信した場合が示されている。分割された追加ストリームデータパケット１４０２には、受信した際に不足分の判定が可能なようにそれぞれに対してパケットヘッダ１４０４が付加される。
【００３０】
調停ブロック１０９がトランシーバ１０３経由で追加データストリームパケットを受信側ユニット１０２に送信し、受信側ユニット１０２はトランシーバを経由してパケット識別ブロック１１３に送られる。パケット識別ブロック１１３では、ストリームパケットではないために受け取った追加ストリームデータパケット１４０２は制御部１１８へ送られる。制御部１１８は、受信した追加データストリームパケットから追加ストリームデータ１４０２を取り出し、再表示バッファ１２２に送る。再表示バッファ１２２は、例えばリングバッファを構成しており、再表示後のデータはある程度保持される。また、古いデータは自動的に新しいデータを読み込むことで破棄される。
【００３１】
追加ストリームデータパケット１４０２に含まれるパケットヘッダにより、全ての追加ストリームデータパケット１４０２が受信でき再表示バッファ１２２に送られたか否かを判定する。一定時間が経過しても全ての追加ストリームデータパケット１４０２を受信できなかった場合は、再表示バッファ１２２の内容を破棄する。これは、時間がある程度経過してしまうと、送信側ユニット１０１内の送信バッファ１０８はリングバッファであるため、新しいデータにより更新されてしまい古いデータが無くなっている可能性が大きいためである。そこで、要求した時間帯のストリームデータが全て再表示バッファ１２２内に格納された時点で、制御部１１８はデマルチプレクサ１２３に追加ストリームデータを入力する。
【００３２】
この際、操作部１２１に設定された動作モードにより、デマルチプレクサ１２３にデータを入力するタイミングを変える必要がある。操作部１２１において動作モードが自動モードに設定されている場合は、追加ストリームデータが再表示バッファ１２２に全て格納された直後にデマルチプレクサ１２３に送られる。動作モードが手動モードに設定されている場合は、制御部１１８は再表示バッファ１２２に追加ストリームデータが全て格納された時点で表示部１２０に再表示用データがある旨を表示する。その後、制御部１１８が新たなエラーを検出した場合は、新たな追加データストリーム要求を行ってもよい。
【００３３】
制御部１１８は、表示用データが存在する旨の表示と同時に、タイマ１１９から現在時刻を取得し、一定時間、例えば１分間程度、操作部１２１から再表示要求の指示が無かった場合は、表示部１２０から再表示用データがある旨の表示を中止し、再表示バッファ１２２内から追加データストリームを削除する。一定時間内に操作部１２１から再表示の指示があった場合は、制御部１１８は再表示バッファ１２２に追加データストリームをデマルチプレクサ１２３に送るように指示し、同時に、表示部１２０に表示している再表示用データが存在する旨の表示を中止する。また、再表示後一定時間内、例えば１分以内に操作部１２１より再表示の指示があった場合は、再度再表示バッファ１２２から追加ストリームデータをデマルチプレクサ１２３に入力し、再表示動作を行うようにする。
【００３４】
デマルチプレクサ１２３は、再表示バッファ１２２から送られてくる追加ストリームデータ１４０２の多重化を解除してビデオストリームとオーディオストリームとに分離し、ビデオストリームをピクチャインピクチャブロック１１６へ、オーディオストリームをミキサブロック１１７へ送る。以上の動作により、エラーが発生して受信できなかった部分を含んだＡＶデータの有無を、現在受信しているＡＶデータの受信を止めずに確認することができる。
【００３５】
次に、本発明の第２の実施の形態について図面を参照しつつ説明を行う。本実施の形態による無線通信システムは、複数の追加ストリームパケット（データ）を同時に扱うことができる技術であり、ここでは、例として２つの追加ストリームに対応可能でありエラー部分の取り寄せ完了の表示にＯＳＤ表示を利用する技術を例に説明を行う。図１５は、本実施の形態による無線通信システムの一構成例を示すブロック図である。図１５に示すように、本実施の形態による無線通信システムは、ＡＶデータ送信側の送信装置１５０１と、ＡＶデータ受信側の送信装置１５０２とを有している。送信装置１５０１中は、パケットデータを送受信するトランシーバユニット１５０３と、トランシーバユニット１５０３に入出力する電波を送受信するためのアンテナ１５０４と、入力されるオーディオストリームとビデオストリームとを混合するマルチプレクサ１５０５と、マルチプレクサ１５０５から出力されたデータにタイマ１５０７からのデータに従ってタイムスタンプを付加するブロック１５０６と、現在時刻を示しつづけるタイマブロック１５０７と、タイムスタンプを付加した送信パケットを送信前・送信後共に一定量を蓄える送信バッファブロック１５０８と、制御部１５１０からの指示に従って送信バッファ１５０８内のデータを読み出して定期的にトランシーバ１５０３へ送り、また制御部１５１０からの非同期パケットを送信バッファから１５０８の送信データと衝突しないようにし、またトランシーバ１５０３からの受信データを制御部１５１０に送る調停ブロック１５０９と、タイマ１５０７、送信バッファ１５０８、調停ブロック１５０９とを制御して送信側ブロック全体を制御する制御ブロック１５１０と、を有している。
【００３６】
受信側装置１５０２は、パケットデータを送受信するためのトランシーバユニット１５１１と、トランシーバ１５１１に入出力する電波を送受信するためのアンテナ１５１２と、トランシーバ１５１１において受信されたパケットの種類を判定し、エラー判定ブロック１５１４と制御部１５１８とに振り分けるパケット識別ブロック１５１３と、タイムスタンプが付加された一連のストリームパケット中からエラーが発生している部分を検出し、そのエラーの発生している部分のタイムスタンプを制御部１５１８に通知するエラー判定ブロック１５１４と、エラー判定ブロック１５１４から出力されたストリームパケットからビデオストリームとオーディオストリームとを分離するデマルチプレクサ１５１５と、制御部１５１８からの指示で予め決められたＯＳＤパターンを出力するビデオストリーム上に合成するＰｉｎＰブロック１５１６と、受信側ブロック内の各ブロックを監視ならびに制御を行い受信側ブロック全体を制御する制御ブロック１５１８と、現在時刻を継続して指示するタイマブロック１５１９と、受信側ブロック１５０２を操作する人によって操作され、受信側ブロック１５０２の動作モードを設定したり、制御部１５１８に対して種種のイベントを発生させる操作部１５２１と、制御部１５１８からの制御により再表示用のデータを一時的に蓄える第１の再表示バッファ１５２２と、第１の再表示バッファ１５２２から出力されるストリームデータをビデオストリームとオーディオストリームとに分離する第１のデマルチプレクサ１５２３と、制御部１５１８からの制御により再表示用のデータを一時的に蓄える第２の再表示バッファ１５２４と、第２の再表示バッファ１５２４から出力されるストリームデータをビデオストリームとオーディオストリームとに分離する第２のデマルチプレクサ１５２５と、を有する。
【００３７】
次に、上述のように構成された無線通信システムの動作について詳細に説明する。図１５に示すマルチプレクサ１５０５から入力されたオーディオストリーム（Ａ  ｓｔｒｅａｍ）とビデオストリーム（Ｖ  ｓｔｒｅａｍ）とを多重化し、タイムスタンプ付加ブロック１５０６においてタイムスタンプを付加し、送信バッファ１５０８に蓄積されながら調停ブロック１５０９と、トランシーバ１５０３と、を経由して受信側ブロック１５０２へ送信される動作は上記の実施の形態による動作と同様である。送信データは、トランシーバ１５０３とアンテナ１５０４とを経由して空中に放射され、受信側ブロック１５０２に到達し、アンテナ１５１２より取り込まれ、トランシーバ１５１１によって復調される。復調されたパケットは全てパケット識別１５１３に送られる。ストリームパケットはエラー判定部１５１４へ送られ、それ以外のパケットは制御部１５１８へ送られる。
【００３８】
エラー判定部１５１４に送られたストリームパケットは、パケットに付加されたパケットヘッダに含まれるチェックサムに基づいてパケットの内容の正当性が検査された後に、パケットヘッダに含まれるシーケンス番号と多重化されたストリームデータとに付加されているタイムスタンプを元にしてエラー等でいずれのパケットが損失したかを判定する。この手順は上記の実施の形態において説明した手順と同様である。エラー判定部１５１４は、パケットの損失が発生したと判断されたときは、損失が発生した区間の前後のタイムスタンプを制御部１５１８に通知する。尚、エラー判定部１５１４は、チェックサムによるエラー検出でエラーと判定されたパケットのみを破棄し、それ以外のデータはデマルチプレクサ１５１５に送られるものとする。
【００３９】
エラーが検出されなかったストリームデータは、デマルチプレクサ１５１５に送られる。デマルチプレクサ１５１５では不良ブロックを取り除き、タイムスタンプを除去した後に、多重化されたストリームデータをビデオストリームとオーディオストリームとに分離する。この時、伝送中のエラーにより片方のストリームだけが壊れる場合は、壊れていない方のストリームの出力は止めないようにする。この手順も上記の実施の形態の手順と同様である。但し、エラーが検出された際の処理が複数のスレッドにより平行して処理される点で上記の実施の形態とは異なる。この場合の手順を実現するためのフローの一例を図１６に示す。図１６に示すフローでは、同時に２つの要求（追加ストリームパケット要求ＡとＢ）が発生し、それぞれの受信側からの一回の追加ストリームパケット要求に対して送信側から追加ストリームパケットＡ及びＢのそれぞれが２度に分けられて送信されている。
【００４０】
エラー判定部１５１４からエラーの発生の通知を受けた制御部１５１８は、送信側ブロック１５０１に対し追加ストリームパケット要求を行う。この時、複数のスレッドに対応させるために要求時にユニークな番号を発生させ、その番号を追加ストリーム要求時に添付し、後に複数の追加ストリームパケットを識別する時に使用する。
【００４１】
本実施の形態による技術では、発生したエラーの間隔が短い場合は複数のエラーをまとめて１つのエラーとして扱う点で上記第１の実施の形態による無線通信システムとは異なる。図１７に示すように、符号１７０１はデータストリームであり、符号１７０２は図１７に示される区間内に発生した１つ目のエラーを示し、符号１７０３は２つめのエラーを示し、符号１７０４は３つ目のエラーを示し、符号１７０５は１つ目のエラーと２つ目のエラーとの間隔を示し、符号１７０６は２つ目のエラーと３つ目のエラーとの間隔を示す。エラーの間隔が一定時間以下であれば（図１７では、１つ目のエラーと２つ目のエラーとの間隔１７０５が該当する）、これらをまとめて１つのエラーとみなし、１つ目のエラーの開始時点から２つ目のエラーの終了時点までの期間１７０７を１つのエラー期間と見なす。エラーとエラーとの間隔が一定時間以上であれば（２つ目のエラーと３つ目のエラーの間隔１７０６が該当する）、これらを別個のエラーとして取り扱う。すなわち、３つ目のエラー１７０４は単独のエラーとして扱われる。
【００４２】
追加ストリームパケットの要求は、受信側ユニット１５０２（図１５）で同時に扱える数だけ、すなわち本実施の形態においては、追加ストリームパケットの要求を同時に２つまで発行できる。図１６では、２つの追加ストリームパケットが存在する場合を例示しているが３以上でも良い。デマルチプレクサ１５１５が分離したビデオストリームは、ピクチャインピクチャ部１５１６へ送られ、オーディオストリームはそのまま出力される。ピクチャインピクチャ部１５１６は、デマルチプレクサ１５１５から出力されたビデオストリームに、予め決められたパターンを制御部１５１８からの指示によって重ねて合成する機能ブロックである。図１８は、このようなＯＳＤに基づくピクチャインピクチャ部１５１６の一構成例を示す図である。図１８に示すように、ピクチャインピクチャ部１５１６は、主ビデオストリームの符号化を復号するデコーダ１８０１と、入出力にＦＩＦＯを備えて復号されたビデオ情報をフレームメモリ１８０５に書き込む際に衝突が起こらないように調停を行う第１調停ブロック１８０２と、制御部１５１８からの指示によりパターンメモリ１８０８から適当なパターンを選んでＯＳＤデータの第２調停部１８０４に入力するコントローラ１８０３と、入出力にＦＩＦＯを備えてフレームメモリ１８０５に書き込む際に衝突が起こらないようにするブロック１８０４と、復号したビデオ情報を書き込んで出力用のビデオ情報を合成し一時保存するブロック１８０５と、入出力にＦＩＦＯを備えてフレームメモリ１８０５からビデオ情報を読み出す際に衝突が起こらないようにする調停ブロック１８０６と、調停ブロック１８０６が読み出したビデオ情報をビデオ信号に変換するビデオ信号エンコーダ１８０７と、予め決められたＯＳＤパターンが記録されているパターンメモリ１８０８と、を有している。
【００４３】
図１９は、上記の調停処理の様子を示す図である。図１９に示すように、ビデオ信号の第１調停部１８０２は、フレームメモリ１８０５上に実画像サイズでビデオ情報を書き込む。コントローラ１８０３は、ビデオ信号用の第１調停部１８０２が書き込んだビデオ情報の上から制御部１５１８（図１５）の指示によって選択されたパターンメモリ１８０８上のパターンデータを読み出し、ＯＳＤパターン用の第２調停部１８０４に送り込む。ＯＳＤパターン用の第２調停部は、この選択されたＯＳＤパターンをフレームメモリ１８０５上のビデオ情報に上書きする。ビデオ信号エンコーダ１８０７に情報を送るための第３調停部１８０６はＯＳＤパターン用の第２調停部１８０４がＯＳＤ情報を上書きしたことを確認した後に、フレームメモリ１８０５から全画面のビデオ情報を読み出し、そのビデオ情報をビデオ信号エンコーダ１８０７に送る。ビデオ信号エンコーダ１８０７は、調停部１８０６から出力されたビデオ情報を再びビデオストリームにエンコードし直す。
【００４４】
以下、エラーが発生した際の処理の流れについて説明する。図１５に示すエラー判定部１５１４からエラーが発生したストリームデータの時間情報を制御部１５１８が受け取ると、エラーが発生した区間に前後１秒を加えた時間帯のストリームデータを送信側に要求する。ストリームデータを要求する際は、ストリームデータ要求パケットを制御部１５１８が生成し、それをトランシーバ１５１１に対して送信要求し、送信側ユニットに要求を伝える。この時、複数の要求を特定可能にするためにユニークな番号を生成し、パケットヘッダに付加する。
【００４５】
送信側ユニット１５０１では、トランシーバ１５０３で受信したストリームデータ要求パケットをデコードし、調停ブロック１５０９を経由して制御部１５１０に送られる。ストリームデータ要求を受けた制御部１５１０は、送信バッファ１５０８を調べ、要求された時間帯のストリームデータが送信バッファ１５０８内に残っているか否かを調べる。要求された時間帯のストリームデータが残っていれば、そのデータを一旦制御部１５１０に読み出し、追加ストリームデータパケットを生成し、調停ブロック１５０９に対し受信側ユニット１５０２に追加ストリームデータパケットを送信させる。この時、いずれの追加ストリーム要求パケットに対する追加ストリームデータパケットであるのかを区別するために、追加ストリームパケットのヘッダに対応する追加ストリーム要求パケットに付加されていたユニークな番号を付加する。
【００４６】
追加要求パケットの送信時には、調停ブロック１５０９は送信中のストリームデータを送るために確保した帯域以外の帯域を使用して送信するように調停する必要がある。これは、前述の実施の形態において説明した通りである。分割して送信する必要がある場合は、前述の実施の形態において説明したようにパケットヘッダ１４０４を付加する。調停ブロック１５０９がトランシーバ１５０３経由で追加データストリームパケットを受信側ユニット１５０２に送信し、受信側ユニット１５０２はトランシーバを経由してパケット識別ブロック１５１３に送られる。パケット識別ブロック１５１３においては、追加データストリームパケットはストリームパケットではないため、受け取った追加データストリームパケットは制御部１５１８へ送られる。
【００４７】
制御部１５１８は、受信した追加データストリームパケットから追加データストリームを取り出し、第１再表示バッファ１５２２または第２再表示バッファ１５２４に送る。この時、同じ追加ストリームデータ要求については同じ再表示バッファに送るようにする。同じかどうかの区別は追加ストリームデータパケットに含まれるユニークな番号によって行う。それぞれの再表示バッファ１５２２、１５２４において、追加データストリームパケットに含まれるパケットヘッダに基づいて全ての追加データストリームパケットが受信でき再表示バッファ１２２に送られたか否かを判定する。一定時間が経過しても全ての追加ストリームデータが受信できなかった場合は、第１再表示バッファ１５２２または第２再表示バッファ１５２４の内容を破棄する。これは、時間がある程度経過してしまうと、送信側ユニット１５０１内の送信バッファ１５０８はリングバッファであるため、古いデータは新しいデータで上書きされている可能性が大きいためである。要求した時間帯のストリームデータが全て第１再表示バッファ１５２２または第２再表示バッファ１５２４内に格納された時点で、制御部１５１８は対応する第１デマルチプレクサ１５２３または第２デマルチプレクサ１５２５に追加ストリームデータを入力する。この時、操作部１５２１に設定された動作モードによりデマルチプレクサ１１５、１２３（図１）にデータを入力するタイミングを変える必要がある。操作部１５２１で動作モードが自動モードに設定されているときは、追加ストリームデータが第１再表示バッファ１５２２又は第２再表示バッファ１５２４に全て格納された直後にデマルチプレクサ１１５、１２３（図１）または１５２５に送られる。
【００４８】
動作モードが手動モードに設定されているときは、制御部１５１８は第１再表示バッファ１５２２または第２再表示バッファ１５２４に追加ストリームデータが全て格納された時点で、ピクチャインピクチャプロック１５１６に対し再表示用データがある旨を表示するよう指示する。同時に、タイマ１５１９から現在時刻を取得し、一定時間、例えば１分間、操作部１５２１から再表示要求の指示が無かった場合はピクチャインピクチャブロック１５１６に対し再表示用データがある旨の表示を停止するよう指示し、第１再表示バッファ１５２２または第２再表示バッファ１５２４内から追加データストリームを削除する。一定時間内に操作部１５２１から再表示の指示があった場合は、制御部１５１８は第１再表示バッファ１５２２または第２再表示バッファ１５２４に対して追加データストリームを第１デマルチプレクサ１５２３または第２デマルチプレクサ１５２５に送るように指示し、同時にピクチャインピクチャプロック１５１６に表示している再表示用データがある旨の表示を中止するように指示する。この操作部１５２１からの指示が、追加ストリームデータの一部のみを再生するものであった場合、例えばビデオのみの再生が指示された、或いは、オーディオのみの再生が指示された場合は、制御部１５１８は第１デマルチプレクサ１５２３または第２デマルチプレクサ１５２５に対して該当ストリームのみを再生するように指示する。
【００４９】
第１デマルチプレクサ１５２３、第２デマルチプレクサ１５２５は、第１再表示バッファ１５２２、第２再表示バッファ１５２４から送られてくる追加データストリームの多重化を解除してビデオストリームとオーディオストリームとに分離し、ビデオストリーム、オーディオストリームとして出力する。第１デマルチプレクサ１５２３、第２デマルチプレクサ１５２５より出力されたデータはそれぞれの再生ユニットにより再生される。これによりエラーが発生して受信できなかった部分を含んだ複数のＡＶデータを現在受信しているＡＶデータを止めることなく確認することが出来る。
【００５０】
次に、１つの送信ユニットから複数の受信ユニットに対してＡＶストリームを送信する場合について説明を行う。以下に、１つの送信ユニットから２つの受信ユニットに対してＡＶストリームを送信する例を、図２０を参照して説明する。図２０に示すように、ＡＶデータの送信ユニット２００１と、第１の受信ユニット（受信ユニットＡ）２００２と、第２の受信ユニット（受信ユニットＢ）２００３と、を含む。送信ユニット２００１から受信ユニットＡ２００２と受信ユニットＢ２００３に対して同一のＡＶストリームを同時に送信する。受信ユニットＡ２００２と受信ユニットＢ２００３とは同一の構成でも良い。構成は上述の実施の形態による送信ユニット、受信側ユニットと同様の構成を有するユニットを使用することができる（図１）。
【００５１】
エラーが発生した際のフローを、図２１を参照して説明する。符号２１０１は定常的に送信されているＡＶストリーム、符号２１０２は受信ユニットＡ２００２がＡＶストリームを受信した際に発生したエラーブロック（エラーＡ）、符号２１０３はエラーＡ２１０２に対応して発生した追加ストリーム要求パケット（追加ストリーム要求Ａ）、符号２１０４は受信ユニットＢがＡＶストリームを受信した際に発生したエラーブロック（エラーＢ）、符号２１０５はエラーＢに対応した追加ストリーム要求パケット（追加ストリーム要求Ｂ）、符号２１０６は追加ストリーム要求Ａ２１０３に対応した追加ストリームパケット（追加ストリームＡ）、符号２１０７は追加ストリーム要求Ｂ２１０５に対応した追加ストリームパケット（追加ストリームＢ）である。送信側ユニット２００１は要求を受けた受信ユニットに対し対応する追加ストリームパケットを対象のユニットに送信する。
【００５２】
受信側ユニットの数が増えてくると、追加ストリーム要求数が増え、送信側ユニットが追加ストリームを送信することが難しくなることが考えられる。また、送信側ユニットが送信する追加ストリームの数が増えてくると、追加ストリーム同士で輻輳を起こす可能性もある。これらの問題を緩和するためには、予め追加ストリーム用の帯域を確保する方法、同一の時間帯又は一部が重なる時間帯の複数の追加ストリーム要求は一つにまとめてマルチキャストにより送信する方法を利用すれば良い。以下、これらの方法について説明する。
【００５３】
図２０と同様の送信ユニット、受信ユニットを有する構成について説明を行う。送信ユニット、受信側ユニットの構成は上記実施の形態と同様の構成を使用することができる（図１）。送信ユニットは、ＡＶストリーム用の帯域が予約された時に、同時に追加ストリーム送信用の帯域を予約する。この一例について図２２を参照して説明を行う。図２２に示すように、符号２２０１はＡＶストリーム用に予約された帯域、符号２２０２は同時に予約された追加ストリーム送信用帯域、符号２２０３は残った非同期送信用帯域を表す。図２３は、エラー時のメッセージフローを示す。ある時間のフレームの受信状況を図２３Ａに示す。符号２３１１は送信部から受信部Ａ、受信部ＢにＡＶストリームを送信したときに受信部Ａで発生した受信エラーである。図２３Ａに示したフレームの次のフレームを図２３Ｂに示す。符号２３２１は前フレームの受信エラー２３１１に対応した追加ストリーム要求であり、符号２３２２は新たに受信部Ａで発生した受信エラーであり、符号２３２３は新たに受信部Ｂで発生した受信エラーを表す。ここに示したように、受信部は受信エラーが発生した場合は即座に追加ストリーム要求を行ってよい。
【００５４】
図２３Ｂに示したフレームの次のフレームを図２３Ｃに示す。符号２３３１は受信部Ａで発生した受信エラー２３２２に対応した追加ストリーム要求であり、符号２３３２は受信部Ｂで発生した受信エラーに対応する追加ストリーム要求を表す。追加ストリーム要求を受けた送信部は、すぐには追加ストリームパケットを送信しない。一定時間だけ待ち、その間に他の受信部が同一の区間に対して、または比較的短い区間に対して複数の追加ストリーム要求が発生するか否かを調べる。図２３に示した例に関して、追加ストリーム要求の処理を行うフローを図２４に示す。
【００５５】
図２３Ｄにおいて、符号２３４１は一定時間内に受けた追加ストリーム要求に対応する追加ストリーム要求である。図に示しているようにこの追加ストリームパケットは追加ストリームパケット用に割り当てられた帯域を用いて送信される。
【００５６】
図２４（Ａ）に追加ストリーム要求を受けた状況を示す。符号２４０１は追加ストリーム要求２３２１に対応する部分、符号２４０２は追加ストリーム要求２３３１と追加ストリーム要求２３３２に対応する部分である。これらの追加ストリーム要求は短い区間に発生しているため、生成する追加ストリームはこれらの区間をカバーできるものとする。この様子を図２４（Ｂ）に示す。図２４（Ｂ）において、符号２４０３は追加ストリームとして生成する範囲を示す。送信部は生成した追加ストリームを受信部Ａと受信部Ｂに対してマルチキャストで送信する。送信する相手が多い場合はブロードキャストを用いても良い。受信部はマルチキャストで送信される追加ストリームパケットは自分が指定されているか否かを判断し、指定されていた場合は全て受信しなければならない。ブロードキャストで送信される追加ストリームパケットについては全て受信しなければならない。追加ストリームを受信した受信部は、受信した追加ストリームパケットの範囲に自身が要求した追加ストリーム要求の範囲が含まれているかを判定する。含まれていた場合は必要な範囲を切り出して再生する。この様子を図２５に示す。
【００５７】
図２５（Ａ）において、符号２５０１は受信した追加ストリームパケット、符号２５０２は自身が要求した追加ストリーム要求の範囲を示す。図２５（Ｂ）において、符号２５０３は受信部が切り出して再生する部分を示す。以上のフローに基づく処理を行うことにより、受信ユニットが増えて追加ストリーム要求の数が増えても、予め追加ストリームパケットを送るための帯域を確保してあるため、追加ストリームパケットを送ることが出来ないという状況を回避できる。また複数の受信ユニットから短期間に集中して追加ストリーム要求を受ける場合も重複している部分を判断してマルチキャスト送信を用いることで追加ストリームパケットの送信数を減らすことが出来、追加ストリーム同士で輻輳することを防ぐことができる。
【００５８】
以上説明したように、本実施の形態による無線通信装置によれば、エラーが多かったりトランザクションに時間がかかる回線においても主要ＡＶデータの受信に大きなバッファを用いることがなく、低レイテンシを確保したアイソクロナス伝送を行い、エラーが発生した部分については自動的に取得し、専用の手段により自動的に視聴することが可能となる。
【００５９】
尚、本侍史の形態においては、「ＡＶデータとは独立して再生する独立再生手段」を用いるため、リアルタイムに再生されるＡＶデータとは異なるある区間データとして作成されるが、この作成されたデータといずれかの記録装置に記録されたＡＶデータとに基づいて、不良部分を修正した一連のＡＶデータを作成するようにしても良い。
【図面の簡単な説明】
【００６０】
【図１】本発明の第１の実施の形態による無線通信装置の構成例を示す機能ブロック図である。
【図２】図２（Ａ）は、本実施の形態による無線通信システムの概略構成例を示す図であり、図２（Ｂ）は、帯域予約時の動作の概要を示した図である。
【図３】マルチプレクサの動作の概要を信号の配列に基づいて示す図である。
【図４】タイムスタンプ付加処理の概要を示す図である。
【図５】パケットヘッダ追加処理の概要を示す図である。
【図６】アイソクロナス伝送処理の概要を示す図である。
【図７】欠落ブロック検査処理の概要を示す図である。
【図８】ａ〜ｃは、データ欠落の検出処理の概要を示す図である。
【図９】ａ〜ｄは、デマルチプレクサの動作の概要を示す図である。
【図１０】追加ストリーム要求を行う際のメッセージフローを示す図である。
【図１１】ＰｉｎＰブロックの構成例を示す機能ブロック図である。
【図１２】ＰｉｎＰブロックの動作の概要を示す図である。
【図１３】ミキサブロックの構成例を示す機能ブロック図である。
【図１４】（Ａ）、（Ｂ）は、追加ストリームデータを分割して送信する場合の動作の概要を示す図である。
【図１５】本発明の第２の実施の形態による無線通信システムの構成例を示す機能ブロック図である。
【図１６】複数回の追加ストリームパケット要求を行う際のメッセージフローの例を示す図である。
【図１７】複数のエラーを１つのエラーとみなす処理の一例を示した図である。
【図１８】ＯＳＤの構成例を示す機能ブロック図である。
【図１９】ＯＳＤの動作の概要を示す図である。
【図２０】受信側の無線通信装置（ユニット）が複数存在するシステムの概要を示す図である。
【図２１】複数の受信ユニットから追加ストリーム要求を行う際のメッセージフローの一例を示した図である。
【図２２】追加ストリームパケット用の帯域を予約した場合の概要を示した図である。
【図２３Ａ】複数の受信ユニットにおいて別々にエラーが発生した場合のメッセージフローの一例を示す図である。
【図２３Ｂ】複数の受信ユニットにおいて別々にエラーが発生した場合のメッセージフローの一例を示す図である。
【図２３Ｃ】複数の受信ユニットにおいて別々にエラーが発生した場合のメッセージフローの一例を示す図である。
【図２３Ｄ】複数の受信ユニットにおいて別々にエラーが発生した場合のメッセージフローの一例を示す図である。
【図２４】（Ａ）、（Ｂ）は、追加ストリームをまとめる際の動作概要の一例を示した図である。
【図２５】（Ａ）、（Ｂ）は、受信した追加ストリームから必要な部分を切り出す動作の概要を示した図である。
【符号の説明】
【００６１】
１０１…ＡＶデータの送信ブロック（第１の無線通信装置）、１０２…ＡＶデータの受信ブロック（第２の無線通信装置）、１０３…トランシーバユニット、１０４…アンテナ、１０５…マルチプレクサ、１０６…タイムスタンプ付加ブロック、１０７…タイマ、１０８…送信バッファブロック、１０９…調停ブロック、１１０…制御部、１１１…トランシーバユニット、１１２…アンテナ、１１３…パケット識別ブロック、１１４…エラー判定ブロック、１１５…デマルチプレクサ、１１６…ＰｉｎＰブロック、１１７…ミキサブロック、１１８…制御ブロック、１１９…タイマ、１２０…表示部、１２１…操作ブロック、１２２…再表示バッファメモリブロック、１２３…デマルチプレクサ。
【図１】
2005295342.tif 000003
【図２】
2005295342.tif 000004
【図３】
2005295342.tif 000005
【図４】
2005295342.tif 000006
【図５】
2005295342.tif 000007
【図６】
2005295342.tif 000008
【図７】
2005295342.tif 000009
【図８】
2005295342.tif 000010
【図９】
2005295342.tif 000011
【図１０】
2005295342.tif 000012
【図１１】
2005295342.tif 000013
【図１２】
2005295342.tif 000014
【図１３】
2005295342.tif 000015
【図１４】
2005295342.tif 000016
【図１５】
2005295342.tif 000017
【図１６】
2005295342.tif 000018
【図１７】
2005295342.tif 000019
【図１８】
2005295342.tif 000020
【図１９】
2005295342.tif 000021
【図２０】
2005295342.tif 000022
【図２１】
2005295342.tif 000023
【図２２】
2005295342.tif 000024
【図２３Ａ】
2005295342.tif 000025
【図２３Ｂ】
2005295342.tif 000026
【図２３Ｃ】
2005295342.tif 000027
【図２３Ｄ】
2005295342.tif 000028
【図２４】
2005295342.tif 000029
【図２５】
2005295342.tif 000030