JP3560522B2 - Ｉｅｅｅ１３９４上のデータ受信装置における受信方法 - Google Patents
Ｉｅｅｅ１３９４上のデータ受信装置における受信方法 Download PDFInfo
- Publication number
- JP3560522B2 JP3560522B2 JP35452499A JP35452499A JP3560522B2 JP 3560522 B2 JP3560522 B2 JP 3560522B2 JP 35452499 A JP35452499 A JP 35452499A JP 35452499 A JP35452499 A JP 35452499A JP 3560522 B2 JP3560522 B2 JP 3560522B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- ieee
- bus
- output
- receiving
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はＩＥＥＥ１３９４上のデータ受信装置における受信方法に関するものである。
【０００２】
【従来の技術】
ＬＳＩ技術の向上に伴って映像情報や音声情報をディジタル化して伝送するネットワークが開発されつつある。映像信号や音声信号はリアルタイムで再生される必要があるため、リアルタイム伝送が可能なネットワークが必要となる。
【０００３】
このようなリアルタイム伝送に適したネットワークとしてＩＥＥＥ１３９４というネットワークが提案、規格化されている。ＩＥＥＥ１３９４はシリアル伝送を行う高速バスシステムで、データを同期伝送できるため、リアルタイム伝送が可能である。
【０００４】
ＩＥＥＥ１３９４は、家庭用ディジタルＶＣＲ（以下ＤＶと記述）を始め、多くのディジタル映像音声機器（以下ＡＶ機器と記述）に外部用インタフェースとして搭載されようとしている。例えばＤＶにおいては、ＩＥＥＥ１３９４を用いることにより、外部機器からＤＶの動作制御を行ったり、また外部機器とＤＶとの間でのデータ伝送を行うことができる。
【０００５】
またＩＥＥＥ１３９４を用いて、ＤＶのようなＡＶ機器のデータを伝送したり、機器制御を行うためのプロトコルとしてＩＥＣ６１８８３が規格化されている。
【０００６】
一方パーソナルコンピュータ（以下ＰＣと記述）においても、標準ＯＳであるＭｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ９８などに正式にＩＥＥＥ１３９４がサポートされるようになったことにより、ＰＣの世界でもＩＥＥＥ１３９４は急速に普及しつつある。
【０００７】
こうしたＰＣとＤＶなどのＡＶ機器との融合が進められてきている。
【０００８】
さて、ＤＶから出力されるデータを、ＰＣで受信する方法について、図１から図９および図１２から図１５を用いて説明する。
【０００９】
図１は、ＩＥＥＥ１３９４バス上に接続されたＰＣとＤＶを示す図である。図１において、１０１はＰＣ、１０２はＤＶ、１０３はアプリケーション、１０４はＤＶ用ドライバ、１０５はＩＥＥＥ１３９４ドライバ、１０６はＩＥＥＥ１３９４インタフェース、１０７はデータ出力部、１０８はｏＰＣＲ［０］、１０９はＩＥＥＥ１３９４インタフェース、１１０はＩＥＥＥ１３９４バス、１１１はＤＶデータ、１１２はＣＩＰ、１１４は動作指示、１１５はＩＥＥＥ１３９４ドライバ１０５へのリクエスト、１１６はリクエスト１１５に対する応答、１１７はレジスタデータである。
【００１０】
図２は、ＣＩＰ１１２の構成例である。図２において、２０１はパケットデータ、２０２はＣＩＰヘッダである。ＣＩＰヘッダ２０２には、データを出力している機器のノード番号を示すＳＩＤ（ｓｏｕｒｃｅ ｎｏｄｅ ＩＤ）フィールドや、またどのようなデータが伝送されているかを示す情報が記述されている。データを受信する機器は、ＳＩＤフィールドを参照することによって送信機器が誰であるかを判断することが出来、後述するブロードキャスト伝送やポイントツーポイント伝送の接続管理を行う際に活用される。
【００１１】
図３は、アイソクロナスパケットの構成例である。図３において、３０１はアイソクロナスヘッダ、３０２はヘッダＣＲＣ、３０３はデータＣＲＣである。アイソクロナスヘッダ３０１には、データを伝送するチャンネルが記述されている。
【００１２】
図４は、ｏＰＣＲの構成である。図４から明らかなように、ｏＰＣＲには、ブロードキャストコネクションカウンター（ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、ポイントツーポイントコネクションカウンター（ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、チャンネル番号（ｃｈａｎｎｅｌ ｎｕｍｂｅｒ）などが記述されている。
【００１３】
図５は、ｉＰＣＲの構成である。図５から明らかなように、ｉＰＣＲにも、ブロードキャストコネクションカウンター（ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、ポイントツーポイントコネクションカウンター（ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、チャンネル番号（ｃｈａｎｎｅｌ ｎｕｍｂｅｒ）などが記述されている。
【００１４】
図６は、ＩＥＣ６１８８３におけるブロードキャスト伝送の概念図である。図６において、６０１は受信装置、６０２は送信装置である。
【００１５】
図７は、ＩＥＣ６１８８３におけるポイントツーポイント伝送の概念図である。
【００１６】
図８は、ＩＥＣ６１８８３におけるブロードキャスト伝送とポイントツーポイント伝送とが同時に行われているときの状態を表す概念図である。
【００１７】
図９は、送信装置６０２のｏＰＣＲ［０］、および受信装置６０１のｉＰＣＲ［０］の値の一例である。すなわち、図９では、送信装置６０２のｏＰＣＲ［０］、及び受信装置６０１のｉＰＣＲ［０］の値の一例が、初期状態、図６の状態（ブロードキャスト伝送を行っている時の状態）、図７の状態（ポイントツーポイント伝送を行っている時の状態）、図８の状態（同時にブロードキャスト伝送とポイントツーポイント伝送を行っている時の状態）に分けて示されている。これについては後述する。
【００１８】
図１２から図１５は、ｏＰＣＲ［０］１０８内の値がどのように書き替えられていくかを示す遷移表である。ｂｃｃはｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒを、ｐ２ｐはｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒを表す。
【００１９】
まずＩＥＣ６１８８３におけるブロードキャスト伝送およびポイントツーポイント伝送の概念について説明する。
【００２０】
ブロードキャスト伝送は、図６に示すように、送信装置６０２は例えばチャンネル番号６３（以下ｃｈ６３と記述）に出力するだけで、どの機器が出力されたデータを受信するかは一切気にしない。一方、受信装置６０１は、ｃｈ６３に伝送されているデータを吸い上げるだけで、そのデータを出力したのがどの機器であるかを気にする必要はない。
【００２１】
これに対してポイントツーポイント伝送は、送信する機器と受信する機器を明確にすることで、図７に示すように送信装置６０２と受信装置６０１との間で１対１のデータ伝送を行うものである。必要に応じて、例えば送信する機器が同じポイントツーポイント伝送を複数同時に行うことで、１対多数の伝送を行うことも可能である。
【００２２】
またブロードキャスト伝送とポイントツーポイント伝送とを同時に行うことも可能である。例えば図８に示すように、送信装置６０２はｃｈ６３にブロードキャストでデータを出力すると同時に、受信装置６０１にポイントツーポイント伝送で１対１の伝送も行うことが可能である。
【００２３】
次にＩＥＣ６１８８３において、どのようにブロードキャスト接続およびポイントツーポイント接続を行うかを説明する。
【００２４】
ＩＥＣ６１８８３準拠の送信装置６０２は、出力制御用レジスタとしてｏＰＣＲ（ｏｕｔｐｕｔ ｐｌｕｇ ｃｏｎｔｒｏｌ ｒｅｇｉｓｔｅｒ）を持っている。同じくＩＥＣ６１８８３準拠の受信装置６０１は、入力制御用レジスタとしてｉＰＣＲ（ｉｎｐｕｔ ｐｌｕｇ ｃｏｎｔｒｏｌ ｒｅｇｉｓｔｅｒ）を持っている。ｏＰＣＲの構成は図４に、ｉＰＣＲの構成は図５のようになっている。ｏＰＣＲおよびｉＰＣＲは複数個持つことが可能であり、Ｎ番目のレジスタをｏＰＣＲ［Ｎ］もしくはｉＰＣＲ［Ｎ］と表記する。ここでは０番目のレジスタを使用するものとして、送信装置６０２のｏＰＣＲ［０］および受信装置６０１のｉＰＣＲ［０］について考える。
【００２５】
まず初期状態すなわち何も接続されていない状態では、図９の初期状態の欄に示すように、ｏＰＣＲ［０］のｂｃｃ、ｐ２ｐ共に０であり、また同様にｉＰＣＲ［０］のｂｃｃ、ｐ２ｐも共に０である。ｃｈａｎｎｅｌ ｎｕｍｂｅｒには、初期値の一例として、６３が入っているものとする。
【００２６】
送信装置６０２があるチャンネルにブロードキャスト伝送で出力を行う場合には、ｏＰＣＲ［０］のｂｃｃに１を代入する。同様に受信装置６０１がブロードキャスト伝送で入力を行う場合には、ｉＰＣＲ［０］のｂｃｃに１を代入する。すなわち図６のようなブロードキャスト伝送が行われているときには、送信装置６０２のｏＰＣＲ［０］および受信装置６０１のｉＰＣＲ［０］のｂｃｃ、ｐ２ｐ、ｃｈａｎｎｅｌ ｎｕｍｂｅｒのそれぞれの値は、図９の中の図６の欄のようになっている。もちろん送信装置６０２が出力したデータを受信装置６０１が受信するには、ｃｈａｎｎｅｌ ｎｕｍｂｅｒが同じである必要がある。送信装置６０２がブロードキャスト伝送での出力を終了する場合には、ｏＰＣＲ［０］のｂｃｃを０に戻す。同様に受信装置６０１がブロードキャスト伝送での入力を終了する場合には、ｉＰＣＲ［０］のｂｃｃを０に戻す。
【００２７】
送信装置６０２と受信装置６０１とがポイントツーポイントで伝送を行うときには、いずれかの機器（送信装置６０２でも受信装置６０１でもあるいは第３の機器のいずれであっても構わない）が、送信装置６０２のｏＰＣＲ［０］のｐ２ｐに１を加算し、同時に受信装置６０１のｉＰＣＲ［０］のｐ２ｐにも１を加算する。すなわち図７のようなポイントツーポイント伝送が行われているときには、送信装置６０２のｏＰＣＲ［０］および受信装置６０１のｉＰＣＲ［０］のｂｃｃ、ｐ２ｐ、ｃｈａｎｎｅｌ ｎｕｍｂｅｒのそれぞれの値は、図９の中の図６の欄のようになっている。
【００２８】
ここでは受信装置６０１のｉＰＣＲ［０］および送信装置６０２のｏＰＣＲ［０］のｃｈａｎｎｅｌ ｎｕｍｂｅｒは共に６３のままで伝送を行ったが、必要であればポイントツーポイント伝送を張った機器は受信装置６０１のｉＰＣＲ［０］および送信装置６０２のｏＰＣＲ［０］のｃｈａｎｎｅｌ ｎｕｍｂｅｒを共に０〜６２までのいずれかの値に変更し、ポイントツーポイント伝送を別のチャンネルで行うようにすることも可能である。
【００２９】
送信装置６０２と受信装置６０１との間のポイントツーポイント伝送を終了するときには、そのポイントツーポイント接続を張った機器が、送信装置６０２のｏＰＣＲ［０］のｐ２ｐから１減算し、同時に受信装置６０１のｉＰＣＲ［０］のｐ２ｐからも１減算する。
【００３０】
ブロードキャスト伝送とポイントツーポイント伝送を同時に行う場合には、それぞれの接続を行うときに上記動作を同じように行えばよい。例えば図８のように送信装置６０２がｃｈ６３にブロードキャストで出力を行うと同時に受信装置６０１に対してポイントツーポイントでデータ伝送を行っているときには、図９の図８の欄に示すように、送信装置６０２のｏＰＣＲ［０］のｂｃｃおよびｐ２ｐの値は共に１になっている。このとき受信装置６０１のｉＰＣＲ［０］のｐ２ｐは１になっている。ただし受信装置６０１は同時に必ずブロードキャストで受信する必要はないので、ｉＰＣＲ［０］のｂｃｃを１にするかどうかは受信装置６０１に任されている。
【００３１】
ところで、ブロードキャスト伝送であろうと、ポイントツーポイント伝送であろうと、ＩＥＥＥ１３９４バス１１０上で伝送を行う場合には、チャンネルおよび帯域の２つのリソースを確保する必要がある。ＩＥＣ６１８８３では、あるチャンネルにおいていずれかの接続を最初に行った機器がこれらのリソースを確保し、最後に接続を切った機器がこれらのリソースを解放しなければならないことになっている。
【００３２】
さて、送信装置であるＤＶ１０２からＰＣ１０１にデータを伝送する方法について説明する。
【００３３】
まずＤＶ１０２の動作について説明する。
【００３４】
ＤＶ１０２は再生開始指示を受けると、ｏＰＣＲ［０］１０８内のｂｃｃに１を代入する。データ出力部１０７は、ＤＶデータ１１１をＩＥＥＥ１３９４インタフェース１０９に出力を開始する。ＩＥＥＥ１３９４インタフェース１０９は受け取ったＤＶデータ１１１を分割したパケットデータ２０１に、ＣＩＰヘッダ２０２を付加し図２のようなＣＩＰ１１２を作成し、さらにアイソクロナスヘッダ３０１、ヘッダＣＲＣ３０２およびデータＣＲＣ３０３を付加し図３のようなアイソクロナスパケットを作成し、ＩＥＥＥ１３９４バス１１０に出力する。このとき出力するチャンネルはｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒに書き込まれている値によって決まる。ｂｃｃを１にする直前までｐ２ｐが０、すなわちいずれの接続もされていない場合には、ＩＥＥＥ１３９４インタフェース１０９はｃｈａｎｎｅｌ ｎｕｍｂｅｒに書き込まれているチャンネルおよび必要な帯域を確保してから、ＩＥＥＥ１３９４バス１１０への出力を開始する。
【００３５】
ＤＶ１０２は再生停止指示を受けると、ｏＰＣＲ［０］１０８内のｂｃｃを０に戻し、データ出力部１０７はＩＥＥＥ１３９４インタフェース１０９への出力を停止し、ＩＥＥＥ１３９４インタフェース１０９はＩＥＥＥ１３９４バス１１０への出力を停止する。このときｂｃｃおよびｐ２ｐが共に０で、いずれの接続も行われていない状態になれば、ＩＥＥＥ１３９４インタフェース１０９は確保されているチャンネルおよび帯域のリソースを解放する。
【００３６】
次にＰＣ１０１の動作について説明する。
【００３７】
ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信開始指示を受けると、まずＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６を通して、ＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を送信してもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、送信要求を受け取ると、ｏＰＣＲ［０］１０８からレジスタデータ１１７を取り出しＩＥＥＥ１３９４インタフェース１０６に送信する。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６が受け取ったレジスタデータ１１７を応答１１６としてＤＶ用ドライバ１０４に出力する。
【００３８】
ＤＶ用ドライバ１０４は、レジスタデータ１１７の内容を見て、ｏＰＣＲ［０］１０８のｂｃｃが１であるか、ｐ２ｐが１以上の値であれば、ｏＰＣＲ［０］１０８内のｐ２ｐの値に１加えた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５としてｏＰＣＲ［０］１０８にレジスタデータ１１７を書き込む指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を書き換えてもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、書き込み要求を受け取ると、新しいレジスタデータ１１７が正当な値であれば、新しいレジスタデータ１１７をｏＰＣＲ［０］１０８に書き込む。
【００３９】
その後ＤＶドライバ１０４は、ｏＰＣＲ［０］１０８内のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されていた値、例えばｃｈ６３からデータ受信を開始する指示をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５として受信開始指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４バス１１０上のｃｈ６３からデータであるアイソクロナスパケットの受信を開始する。ＩＥＥＥ１３９４ドライバ１０５は、受信したアイソクロナスパケットからＣＩＰ１１２を取り出しＤＶ用ドライバ１０４に出力する。ＤＶ用ドライバ１０４は、ＣＩＰ１１２からパケットデータ２０１を取り出し、パケットデータ２０１からＤＶデータ１１１を作成し、アプリケーション１０３に出力する。
【００４０】
またＤＶ用ドライバ１０４は、レジスタデータ１１７の内容を見て、ｏＰＣＲ［０］１０８のｂｃｃおよびｐ２ｐが共に０であれば、ＩＥＥＥ１３９４バス１１０で他の機器が使っていないチャンネル、例えばｃｈ０をｏＰＣＲ［０］１０８内のｃｈａｎｎｅｌｎｕｍｂｅｒに代入し、かつｏＰＣＲ［０］１０８内のｐ２ｐの値に１加えた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５としてｏＰＣＲ［０］１０８にレジスタデータ１１７を書き込む指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を書き換えてもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、書き込み要求を受け取ると、新しいレジスタデータ１１７が正当な値であれば、新しいレジスタデータ１１７をｏＰＣＲ［０］１０８に書き込む。同時にＤＶ用ドライバ１０４は、ＩＥＥＥ１３９４バス１１０のリソースであるｃｈ０と必要な帯域の確保を行い、その後ｃｈ０からデータ受信を開始する指示をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５として受信開始指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４バス１１０上のｃｈ０からデータであるアイソクロナスパケットの受信を開始する。ＤＶ１０２がデータを出力していない場合には、ＩＥＥＥ１３９４ドライバ１０５はデータが出力されるまで待機する。
【００４１】
以降の動作は、ｏＰＣＲ［０］１０８のｂｃｃが１である場合と同様である。
【００４２】
一方、ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信停止指示を受けると、まずＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する指示をリクエスト１１５としてＩＥＥＥ１３９４インタフェース１０５に送信する。ＩＥＥＥ１３９４インタフェース１０５は受信停止指示を受け取ると、ＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する。
【００４３】
次にＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信停止指示を受けると、ＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。ＤＶ用ドライバ１０４は、ｏＰＣＲ［０］１０８内のｐ２ｐの値から１引いた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。上記と同様の動作によって、ＤＶ１０２のｏＰＣＲ［０］１０８の値を変更する。ｏＰＣＲ［０］１０８のｂｃｃが０でかつ先にＤＶ用ドライバ１０４がＩＥＥＥ１３９４バス１１０のリソースを確保していたのであれば、このとき同時にＤＶ用ドライバ１０４はＩＥＥＥ１３９４バス１１０のリソースを解放する。このときＤＶ用ドライバ１０４は、必要であればｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒの値を元に戻す。
【００４４】
以上の動作において、ＤＶ１０２のｏＰＣＲ［０］１０８の値およびＩＥＥＥ１３９４バス１１０のリソースを誰が確保し、誰が解放するかを表にしたものの一例が図１２から図１５である。
【００４５】
ＤＶ１０２の再生開始とＰＣ１０１の受信開始とどちらが先に行われたか、またＤＶ１０２の再生停止とＰＣ１０１の受信停止のどちらが先に行われたかで合計４通りの動作が考えれる。
【００４６】
図１２は、ＰＣ１０１の受信開始とＤＶ１０２の再生停止が先である場合である。ＰＣ１０１が受信を開始するときには、ＤＶ１０２の再生が開始されていないのでｏＰＣＲ［０］１０８のｂｃｃおよびｐ２ｐは共に０である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ０に、ｐ２ｐを１に変更し、かつＩＥＥＥ１３９４バス１１０のリソースを確保する。ＤＶ１０２が再生を開始するときには、すでにｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの確保は行わず、ｂｃｃを１に変更する。
【００４７】
ＤＶ１０２が再生を停止したときには、まだｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの解放を行わず、ｂｃｃを０に戻す。
【００４８】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ６３に戻し、同時にｐ２ｐも０に戻す。この時点でＤＶ１０２は再生していないのでｏＰＣＲ［０］１０８のｂｃｃも０である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００４９】
図１３は、ＰＣ１０１の受信開始とＰＣ１０１の受信停止が先である場合である。ＰＣ１０１が受信を開始するときには、ＤＶ１０２の再生が開始されていないのでｏＰＣＲ［０］１０８のｂｃｃおよびｐ２ｐは共に０である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ０に、ｐ２ｐを１に変更し、かつＩＥＥＥ１３９４バス１１０のリソースを確保する。ＤＶ１０２が再生を開始するときには、すでにｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの確保を行わず、ｂｃｃを１に変更する。
【００５０】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ６３に戻し、同時にｐ２ｐも０に戻す。この時点でＤＶ１０２はまだ再生しているのでｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放しない。
【００５１】
ＤＶ１０２が再生を停止したときには、ｂｃｃを０に戻すが、すでにｐ２ｐも０になっており、いずれの接続もされていないので、ＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００５２】
図１４は、ＤＶ１０２の再生開始とＰＣ１０１の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行い、さらにｂｃｃを１にする。
【００５３】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを１に変更するだけで、ｃｈａｎｎｅｌ ｎｕｍｂｅｒは変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。
【００５４】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを０に戻す。この時点でＤＶ１０２はまだ再生しているのでｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する必要はない。
【００５５】
ＤＶ１０２が再生を停止したときには、ｂｃｃを０に戻すが、すでにｐ２ｐも０になっており、いずれの接続もされていないので、ＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００５６】
図１５は、ＤＶ１０２の再生開始とＤＶ１０２の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行い、さらにｂｃｃを１にする。
【００５７】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを１に変更するだけで、ｃｈａｎｎｅｌ ｎｕｍｂｅｒは変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。
【００５８】
ＤＶ１０２が再生を停止したときには、まだｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの解放を行わず、ｂｃｃを０に戻す。
【００５９】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを０に戻す。この時点でＤＶ１０２は再生していないのでｏＰＣＲ［０］１０８のｂｃｃも０である。このときＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する必要があるが、ＩＥＥＥ１３９４ドライバ１０５およびＤＶ用ドライバ１０４は自分が確保したリソースでなければ解放できないという特徴を持っているため、リソースの解放を行えないことになる。
【００６０】
すなわち、ＤＶ１０２等のＩＥＥＥ１３９４バス１１０に接続されている機器は一般に他の機器が確保したリソースを解放することが出来る。これに対して、Ｗｉｎｄｏｗｓ９８が搭載されているＰＣ１０１では、自らが確保したリソースは解放できるが、他の機器が確保したリソースを解放することが出来ないという特徴を持っている。
【００６１】
前述したように、ＩＥＣ６１８８３では、あるチャンネルにおいていずれかの接続を最初に行った機器がこれらのリソースを確保し、最後に接続を切った機器がこれらのリソースを解放しなければならないことになっている。従って、ＩＥＣ６１８８３の規格に従えばＰＣ１０１０がリソースを解放すべきであるが、ＰＣ１０１の特徴によりリソースを解放することが出来ない。
【００６２】
一度リソースの解放が正しく行われないと、ＩＥＥＥ１３９４バス１１０にバスリセットを発生させないとそれらのリソースを再び使用できない。
【００６３】
【発明が解決しようとする課題】
しかしながら上記した従来の構成では、図１５のような順序で動作を行った場合、ＩＥＥＥ１３９４バスのリソースの解放を正しく行えず、それ以降それらのリソースを使用できなくなるという問題点があった。
【００６４】
本発明はこのような従来の問題点を鑑みてなされたものであって、ＩＥＥＥ１３９４バスのリソースを常に正しく解放できるデータ伝送方法を提供することを目的とするものである。
【００６５】
【課題を解決するための手段】
上述した課題を解決するために、第１の本発明（請求項１に対応）は、ＩＥＣ６１８８３準拠のデータ受信装置と、ＩＥＣ６１８８３準拠のデータ送信装置とがＩＥＥＥ１３９４バスに接続されている場合、
前記データ受信装置が、ＩＥＥＥ１３９４インタフェースと、前記ＩＥＥＥ１３９４バスに接続されている機器の全部または一部を制御する機器制御手段とを有し、かつ自身が確保していないＩＥＥＥ１３９４バスにおける帯域を解放することができないパーソナルコンピュータである場合、
前記データ受信装置は、受信開始指示を受け取ると、前記データ送信装置がブロードキャスト伝送を用いて出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力している場合に、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張らずに前記出力データの受信を行うことを特徴とする受信方法である。
【００６６】
また、第２の本発明（請求項２に対応）は、前記データ送信装置は、出力制御レジスタを保有しており、
前記出力制御レジスタには、ブロードキャスト伝送を行っているかどうかを示すフラグと、前記出力データをどのチャンネルに出力するかを示すチャンネル番号とが含まれており、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は、前記フラグを読むことにより、前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力している場合には、
前記データ受信装置は、前記チャンネル番号の変更を行わず、前記チャンネル番号に記述されているチャンネルから前記出力データを受信することを特徴とする第１の本発明に記載の受信方法である。
【００６７】
また、第３の本発明（請求項３に対応）は、前記データ送信装置は、出力制御レジスタを保有しており、
前記出力制御レジスタには、内部にブロードキャスト伝送を行っているかどうかを示すフラグと、出力データをどのチャンネルに出力するかを示すチャンネル番号とが含まれており、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は、前記フラグを読むことにより、前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ受信装置は、前記チャンネル番号を任意の値Ｎ（Ｎは０から６３までの整数）に変更した後、チャンネル番号が前記Ｎであるチャンネルから前記出力データを受信することを特徴とする第１の本発明に記載の受信方法である。
【００６８】
また、第４の本発明（請求項４に対応）は、前記データ送信装置が前記出力データをＩＥＥＥ１３９４バスに出力していない場合、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張った後、前記データ送信装置が前記出力データを前記ＩＥＥＥ１３９４バスに出力を開始すると同時に、前記データ受信装置は前記出力データの受信を行うことを特徴とする第２または３の本発明に記載の受信方法である。
【００６９】
また、第５の本発明（請求項５に対応）は、前記ＩＥＥＥ１３９４バスには、ＩＥＣ６１８８３準拠の第２のデータ受信装置が接続されており、
前記データ送信装置が、前記第２のデータ受信装置に対しポイントツーポイント接続を張られているまたは張っている状態で、かつブロードキャスト伝送を用いずに、前記ＩＥＥＥ１３９４バスに前記出力データの出力を行っている場合には、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張り、 前記出力データの受信を行うことを特徴とする第２から４の本発明のいずれかに記載の受信方法である。
【００７０】
また、第６の本発明（請求項６に対応）は、前記データ送信装置は、家庭用ディジタルＶＣＲであることを特徴とする第１から５の本発明のいずれかに記載の受信方法である。
【００７１】
また、第７の本発明（請求項７に対応）は、前記データ送信装置は、ＭＰＥＧデータを出力するセットトップボックスであることを特徴とする第１から５の本発明のいずれかに記載の受信方法である。
【００７２】
また、第８の本発明（請求項８に対応）は、第１から７の本発明のいずれかに記載の受信方法の全部または一部のステップの全部または一部の動作をコンピュータにより実行させるためのプログラム及び／またはデータを記録した記録媒体であって、
コンピュータにより読み取り可能なことを特徴とするプログラム記録媒体である。
【００７３】
【発明の実施の形態】
（実施の形態１）
以下、本発明の第１の実施形態について、図１から図５および図１０から図１３を用いて説明する。
【００７４】
ＤＶ１０２の構成および動作は従来例と同様であり、またＰＣ１０１の構成も従来例と同様である。
【００７５】
なお、本実施の形態のＤＶ１０２は本発明のデータ送信装置の例であり、本実施の形態のＰＣ１０１は本発明のパーソナルコンピュータの例であり、本実施の形態のＤＶ用ドライバ１０４、ＩＥＥＥ１３９４ドライバ１０５は本発明の機器制御手段の例である。
【００７６】
ＰＣ１０１の動作について説明する。
【００７７】
ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信開始指示を受けると、まずＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６を通して、ＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を送信してもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、送信要求を受け取ると、ｏＰＣＲ［０］１０８からレジスタデータ１１７を取り出しＩＥＥＥ１３９４インタフェース１０６に送信する。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６が受け取ったレジスタデータ１１７を応答１１６としてＤＶ用ドライバ１０４に出力する。
【００７８】
ＤＶ用ドライバ１０４は、レジスタデータ１１７の内容を見て、ｏＰＣＲ［０］１０８のｂｃｃが１であれば、ＤＶ１０２に対してポイントツーポイント接続を張らず、すなわちそのままｏＰＣＲ［０］１０８内のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示された値、例えばｃｈ６３からデータ受信を開始する指示をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５として受信開始指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４バス１１０上のｃｈ６３からデータであるアイソクロナスパケットの受信を開始する。
【００７９】
以降の動作は従来例と同様である。
【００８０】
またｏＰＣＲ［０］１０８のｂｃｃが０である場合の動作は従来例と同じである。
【００８１】
一方、ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信停止指示を受けると、まずＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する指示をリクエスト１１５としてＩＥＥＥ１３９４インタフェース１０５に送信する。ＩＥＥＥ１３９４インタフェース１０５は受信停止指示を受け取ると、ＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する。
【００８２】
次にＤＶ用ドライバ１０４は、受信開始時にｏＰＣＲ［０］１０８内のｐ２ｐの値に１を加えてポイントツーポイント接続を行っている場合には、ＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。その後ＤＶ用ドライバ１０４は、ｏＰＣＲ［０］１０８内のｐ２ｐの値から１引いた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。上記と同様の動作によって、ＤＶ１０２のｏＰＣＲ［０］１０８の値を変更する。ｏＰＣＲ［０］１０８のｂｃｃが０でかつ先にＤＶ用ドライバ１０４がＩＥＥＥ１３９４バス１１０のリソースを確保していたのであれば、このとき同時にＤＶ用ドライバ１０４はＩＥＥＥ１３９４バス１１０のリソースを解放する。このときＤＶ用ドライバ１０４は、必要であればｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒの値を元に戻す。
【００８３】
またＤＶ用ドライバ１０４は、受信開始時にＤＶ１０２に対してポイントツーポイント接続を張っていない場合には、そのまま何もせず処理を終了する。
【００８４】
以上の動作において、ＤＶ１０２のｏＰＣＲ［０］１０８の値およびＩＥＥＥ１３９４バス１１０のリソースを誰が確保し、誰が解放するかを表にしたものの一例が図１０から図１３である。
【００８５】
従来例と同様に、ＤＶ１０２の再生開始とＰＣ１０１の受信開始とどちらが先に行われたか、またＤＶ１０２の再生停止とＰＣ１０１の受信停止のどちらが先に行われたかで合計４通りの動作が考えれる。
【００８６】
図１０は、ＤＶ１０１の再生開始とＰＣ１０１の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行う。
【００８７】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｃｈａｎｎｅｌ ｎｕｍｂｅｒおよびｐ２ｐの値を何も変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。すなわちポイントツーポイント接続を行わず、ブロードキャスト伝送のみを使用することになる。
【００８８】
ＰＣ１０１が受信を停止したときには、ＤＶ１０２はまだ再生しているのでｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する必要はない。
【００８９】
ＤＶ１０２が再生を停止したときには、ｂｃｃを０に戻すが、ｐ２ｐも０のままであり、いずれの接続もされていないので、ＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００９０】
図１１は、ＤＶ１０２の再生開始とＤＶ１０２の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行う。
【００９１】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを１に変更するだけで、ｃｈａｎｎｅｌ ｎｕｍｂｅｒは変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。
【００９２】
ＤＶ１０２が再生を停止したときには、やはりｐ２ｐが０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０２はリソースの解放を行う。
【００９３】
ＰＣ１０１が受信を停止したときには、すでにＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放しており、ＰＣ１０１は受信を停止するだけでよい。
【００９４】
ＰＣ１０１の受信開始を先に行う場合の動作は、従来例と同じく図１２および図１３のようになる。
【００９５】
以上により、ＰＣ１０１が自らが確保したリソースは解放出来るが、他の機器が確保したリソースは解放することが出来ないという特徴を持っている場合でも、ＰＣ１０１の受信開始／停止、ＤＶ１０２の再生開始／停止がどういう順序で行われても、ＩＥＥＥ１３９４バス１０５のリソースの確保・解放を必ず正しく行われるようになる。
【００９６】
なお、ＤＶ１０２のｏＰＣＲ［０］１０８に初期状態で書き込まれているｃｈａｎｎｅｌ ｎｕｍｂｅｒの値はｃｈ６３としたが、０から６３のいずれかの整数値であれば構わない。
【００９７】
またＰＣ１０１が、ＤＶ１０２に対してポイントツーポイント接続を行ったときに、ＤＶ１０２のｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒの値をｃｈ０にするとしたが、すでに他の機器が確保していないチャンネルであれば０から６３のうちのいずれかの整数値でも構わない。
【００９８】
またＩＥＥＥ１３９４バス１１０上には、ＰＣ１０１とＤＶ１０２とが接続されているとしたが、他のＩＥＥＥ１３９４機器が接続されていても構わない。
【００９９】
また初期状態でＤＶ１０２のｏＰＣＲ［０］１０８のｐ２ｐは０、すなわちＤＶ１０２は他のいずれの機器との間でポイントツーポイント接続が張られていない状態であるとしたが、初期状態でＤＶ１０２は他の機器との間にポイントツーポイント接続が張られていても構わない。
【０１００】
また、本実施の形態では、ＰＣ１０１の動作を説明したが、本実施の形態のＰＣ１０１以外の機器すなわち他の機器が確保したリソースを解放することが出来る機器がＤＶ１０２からデータを受信する場合、本実施の形態のＰＣ１０１の動作と同様の動作をしても構わないし、あるいは従来の技術で説明したＰＣ１０１と同様の動作をしても構わない。
【０１０１】
また、データ受信装置は、ハードウェア、ソフトウェアもしくはその両方を用いて構成されていても構わない。
【０１０２】
また、本発明の受信方法の全部または一部のステップの全部または一部の動作をコンピュータにより実行させるためのプログラム及び／またはデータを記録したプログラム記録媒体であって、コンピュータにより読み取り可能であり、読み取られた前記プログラム及び／またはデータが前記コンピュータと協動して前記機能を実行することを特徴とするプログラム記録媒体も本発明に属する。
【０１０３】
【発明の効果】
以上説明したように、本発明によれば、データ送信装置がすでにブロードキャスト伝送で送信を行っている場合には、データ受信装置はポイントツーポイント接続を張らずにブロードキャスト伝送で受信を行うようにすることで、データ伝送終了時にＩＥＥＥ１３９４バスのリソースを常に正しく解放する事が可能となった。
【図面の簡単な説明】
【図１】本発明の第１実施形態および従来例におけるデータ送信装置およびデータ受信装置の例を示す図
【図２】ＣＩＰ１１２の構成例を示す図
【図３】アイソクロナスパケットの構成例を示す図
【図４】ｏＰＣＲの構成を示す図
【図５】ｉＰＣＲの構成を示す図
【図６】ＩＥＣ６１８８３におけるブロードキャスト伝送の概念図
【図７】ＩＥＣ６１８８３におけるポイントツーポイント伝送の概念図
【図８】ＩＥＣ６１８８３におけるブロードキャスト伝送とポイントツーポイント伝送とが同時に行われているときの状態を表す概念図
【図９】送信装置６０２のｉＰＣＲ［０］、および受信装置６０１のｏＰＣＲ［０］の値の一例を示す図
【図１０】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１１】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１２】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１３】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１４】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１５】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【符号の説明】
１０１ ＰＣ
１０２ ＤＶ
１０３ アプリケーション
１０４ ＤＶ用ドライバ
１０５ ＩＥＥＥ１３９４ドライバ
１０６ ＩＥＥＥ１３９４インタフェース
１０７ データ出力部
１０８ ｏＰＣＲ［０］
１０９ ＩＥＥＥ１３９４インタフェース
１１０ ＩＥＥＥ１３９４バス
１１１ ＤＶデータ
１１２ ＣＩＰ
１１４ 動作指示
１１５ リクエスト
１１６ 応答
１１７ レジスタデータ
２０１ パケットデータ
２０２ ＣＩＰヘッダ
３０１ アイソクロナスヘッダ
３０２ ヘッダＣＲＣ
３０３ データＣＲＣ
６０１ 受信装置
６０２ 送信装置
【発明の属する技術分野】
本発明はＩＥＥＥ１３９４上のデータ受信装置における受信方法に関するものである。
【０００２】
【従来の技術】
ＬＳＩ技術の向上に伴って映像情報や音声情報をディジタル化して伝送するネットワークが開発されつつある。映像信号や音声信号はリアルタイムで再生される必要があるため、リアルタイム伝送が可能なネットワークが必要となる。
【０００３】
このようなリアルタイム伝送に適したネットワークとしてＩＥＥＥ１３９４というネットワークが提案、規格化されている。ＩＥＥＥ１３９４はシリアル伝送を行う高速バスシステムで、データを同期伝送できるため、リアルタイム伝送が可能である。
【０００４】
ＩＥＥＥ１３９４は、家庭用ディジタルＶＣＲ（以下ＤＶと記述）を始め、多くのディジタル映像音声機器（以下ＡＶ機器と記述）に外部用インタフェースとして搭載されようとしている。例えばＤＶにおいては、ＩＥＥＥ１３９４を用いることにより、外部機器からＤＶの動作制御を行ったり、また外部機器とＤＶとの間でのデータ伝送を行うことができる。
【０００５】
またＩＥＥＥ１３９４を用いて、ＤＶのようなＡＶ機器のデータを伝送したり、機器制御を行うためのプロトコルとしてＩＥＣ６１８８３が規格化されている。
【０００６】
一方パーソナルコンピュータ（以下ＰＣと記述）においても、標準ＯＳであるＭｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ９８などに正式にＩＥＥＥ１３９４がサポートされるようになったことにより、ＰＣの世界でもＩＥＥＥ１３９４は急速に普及しつつある。
【０００７】
こうしたＰＣとＤＶなどのＡＶ機器との融合が進められてきている。
【０００８】
さて、ＤＶから出力されるデータを、ＰＣで受信する方法について、図１から図９および図１２から図１５を用いて説明する。
【０００９】
図１は、ＩＥＥＥ１３９４バス上に接続されたＰＣとＤＶを示す図である。図１において、１０１はＰＣ、１０２はＤＶ、１０３はアプリケーション、１０４はＤＶ用ドライバ、１０５はＩＥＥＥ１３９４ドライバ、１０６はＩＥＥＥ１３９４インタフェース、１０７はデータ出力部、１０８はｏＰＣＲ［０］、１０９はＩＥＥＥ１３９４インタフェース、１１０はＩＥＥＥ１３９４バス、１１１はＤＶデータ、１１２はＣＩＰ、１１４は動作指示、１１５はＩＥＥＥ１３９４ドライバ１０５へのリクエスト、１１６はリクエスト１１５に対する応答、１１７はレジスタデータである。
【００１０】
図２は、ＣＩＰ１１２の構成例である。図２において、２０１はパケットデータ、２０２はＣＩＰヘッダである。ＣＩＰヘッダ２０２には、データを出力している機器のノード番号を示すＳＩＤ（ｓｏｕｒｃｅ ｎｏｄｅ ＩＤ）フィールドや、またどのようなデータが伝送されているかを示す情報が記述されている。データを受信する機器は、ＳＩＤフィールドを参照することによって送信機器が誰であるかを判断することが出来、後述するブロードキャスト伝送やポイントツーポイント伝送の接続管理を行う際に活用される。
【００１１】
図３は、アイソクロナスパケットの構成例である。図３において、３０１はアイソクロナスヘッダ、３０２はヘッダＣＲＣ、３０３はデータＣＲＣである。アイソクロナスヘッダ３０１には、データを伝送するチャンネルが記述されている。
【００１２】
図４は、ｏＰＣＲの構成である。図４から明らかなように、ｏＰＣＲには、ブロードキャストコネクションカウンター（ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、ポイントツーポイントコネクションカウンター（ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、チャンネル番号（ｃｈａｎｎｅｌ ｎｕｍｂｅｒ）などが記述されている。
【００１３】
図５は、ｉＰＣＲの構成である。図５から明らかなように、ｉＰＣＲにも、ブロードキャストコネクションカウンター（ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、ポイントツーポイントコネクションカウンター（ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒ）、チャンネル番号（ｃｈａｎｎｅｌ ｎｕｍｂｅｒ）などが記述されている。
【００１４】
図６は、ＩＥＣ６１８８３におけるブロードキャスト伝送の概念図である。図６において、６０１は受信装置、６０２は送信装置である。
【００１５】
図７は、ＩＥＣ６１８８３におけるポイントツーポイント伝送の概念図である。
【００１６】
図８は、ＩＥＣ６１８８３におけるブロードキャスト伝送とポイントツーポイント伝送とが同時に行われているときの状態を表す概念図である。
【００１７】
図９は、送信装置６０２のｏＰＣＲ［０］、および受信装置６０１のｉＰＣＲ［０］の値の一例である。すなわち、図９では、送信装置６０２のｏＰＣＲ［０］、及び受信装置６０１のｉＰＣＲ［０］の値の一例が、初期状態、図６の状態（ブロードキャスト伝送を行っている時の状態）、図７の状態（ポイントツーポイント伝送を行っている時の状態）、図８の状態（同時にブロードキャスト伝送とポイントツーポイント伝送を行っている時の状態）に分けて示されている。これについては後述する。
【００１８】
図１２から図１５は、ｏＰＣＲ［０］１０８内の値がどのように書き替えられていくかを示す遷移表である。ｂｃｃはｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒを、ｐ２ｐはｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒを表す。
【００１９】
まずＩＥＣ６１８８３におけるブロードキャスト伝送およびポイントツーポイント伝送の概念について説明する。
【００２０】
ブロードキャスト伝送は、図６に示すように、送信装置６０２は例えばチャンネル番号６３（以下ｃｈ６３と記述）に出力するだけで、どの機器が出力されたデータを受信するかは一切気にしない。一方、受信装置６０１は、ｃｈ６３に伝送されているデータを吸い上げるだけで、そのデータを出力したのがどの機器であるかを気にする必要はない。
【００２１】
これに対してポイントツーポイント伝送は、送信する機器と受信する機器を明確にすることで、図７に示すように送信装置６０２と受信装置６０１との間で１対１のデータ伝送を行うものである。必要に応じて、例えば送信する機器が同じポイントツーポイント伝送を複数同時に行うことで、１対多数の伝送を行うことも可能である。
【００２２】
またブロードキャスト伝送とポイントツーポイント伝送とを同時に行うことも可能である。例えば図８に示すように、送信装置６０２はｃｈ６３にブロードキャストでデータを出力すると同時に、受信装置６０１にポイントツーポイント伝送で１対１の伝送も行うことが可能である。
【００２３】
次にＩＥＣ６１８８３において、どのようにブロードキャスト接続およびポイントツーポイント接続を行うかを説明する。
【００２４】
ＩＥＣ６１８８３準拠の送信装置６０２は、出力制御用レジスタとしてｏＰＣＲ（ｏｕｔｐｕｔ ｐｌｕｇ ｃｏｎｔｒｏｌ ｒｅｇｉｓｔｅｒ）を持っている。同じくＩＥＣ６１８８３準拠の受信装置６０１は、入力制御用レジスタとしてｉＰＣＲ（ｉｎｐｕｔ ｐｌｕｇ ｃｏｎｔｒｏｌ ｒｅｇｉｓｔｅｒ）を持っている。ｏＰＣＲの構成は図４に、ｉＰＣＲの構成は図５のようになっている。ｏＰＣＲおよびｉＰＣＲは複数個持つことが可能であり、Ｎ番目のレジスタをｏＰＣＲ［Ｎ］もしくはｉＰＣＲ［Ｎ］と表記する。ここでは０番目のレジスタを使用するものとして、送信装置６０２のｏＰＣＲ［０］および受信装置６０１のｉＰＣＲ［０］について考える。
【００２５】
まず初期状態すなわち何も接続されていない状態では、図９の初期状態の欄に示すように、ｏＰＣＲ［０］のｂｃｃ、ｐ２ｐ共に０であり、また同様にｉＰＣＲ［０］のｂｃｃ、ｐ２ｐも共に０である。ｃｈａｎｎｅｌ ｎｕｍｂｅｒには、初期値の一例として、６３が入っているものとする。
【００２６】
送信装置６０２があるチャンネルにブロードキャスト伝送で出力を行う場合には、ｏＰＣＲ［０］のｂｃｃに１を代入する。同様に受信装置６０１がブロードキャスト伝送で入力を行う場合には、ｉＰＣＲ［０］のｂｃｃに１を代入する。すなわち図６のようなブロードキャスト伝送が行われているときには、送信装置６０２のｏＰＣＲ［０］および受信装置６０１のｉＰＣＲ［０］のｂｃｃ、ｐ２ｐ、ｃｈａｎｎｅｌ ｎｕｍｂｅｒのそれぞれの値は、図９の中の図６の欄のようになっている。もちろん送信装置６０２が出力したデータを受信装置６０１が受信するには、ｃｈａｎｎｅｌ ｎｕｍｂｅｒが同じである必要がある。送信装置６０２がブロードキャスト伝送での出力を終了する場合には、ｏＰＣＲ［０］のｂｃｃを０に戻す。同様に受信装置６０１がブロードキャスト伝送での入力を終了する場合には、ｉＰＣＲ［０］のｂｃｃを０に戻す。
【００２７】
送信装置６０２と受信装置６０１とがポイントツーポイントで伝送を行うときには、いずれかの機器（送信装置６０２でも受信装置６０１でもあるいは第３の機器のいずれであっても構わない）が、送信装置６０２のｏＰＣＲ［０］のｐ２ｐに１を加算し、同時に受信装置６０１のｉＰＣＲ［０］のｐ２ｐにも１を加算する。すなわち図７のようなポイントツーポイント伝送が行われているときには、送信装置６０２のｏＰＣＲ［０］および受信装置６０１のｉＰＣＲ［０］のｂｃｃ、ｐ２ｐ、ｃｈａｎｎｅｌ ｎｕｍｂｅｒのそれぞれの値は、図９の中の図６の欄のようになっている。
【００２８】
ここでは受信装置６０１のｉＰＣＲ［０］および送信装置６０２のｏＰＣＲ［０］のｃｈａｎｎｅｌ ｎｕｍｂｅｒは共に６３のままで伝送を行ったが、必要であればポイントツーポイント伝送を張った機器は受信装置６０１のｉＰＣＲ［０］および送信装置６０２のｏＰＣＲ［０］のｃｈａｎｎｅｌ ｎｕｍｂｅｒを共に０〜６２までのいずれかの値に変更し、ポイントツーポイント伝送を別のチャンネルで行うようにすることも可能である。
【００２９】
送信装置６０２と受信装置６０１との間のポイントツーポイント伝送を終了するときには、そのポイントツーポイント接続を張った機器が、送信装置６０２のｏＰＣＲ［０］のｐ２ｐから１減算し、同時に受信装置６０１のｉＰＣＲ［０］のｐ２ｐからも１減算する。
【００３０】
ブロードキャスト伝送とポイントツーポイント伝送を同時に行う場合には、それぞれの接続を行うときに上記動作を同じように行えばよい。例えば図８のように送信装置６０２がｃｈ６３にブロードキャストで出力を行うと同時に受信装置６０１に対してポイントツーポイントでデータ伝送を行っているときには、図９の図８の欄に示すように、送信装置６０２のｏＰＣＲ［０］のｂｃｃおよびｐ２ｐの値は共に１になっている。このとき受信装置６０１のｉＰＣＲ［０］のｐ２ｐは１になっている。ただし受信装置６０１は同時に必ずブロードキャストで受信する必要はないので、ｉＰＣＲ［０］のｂｃｃを１にするかどうかは受信装置６０１に任されている。
【００３１】
ところで、ブロードキャスト伝送であろうと、ポイントツーポイント伝送であろうと、ＩＥＥＥ１３９４バス１１０上で伝送を行う場合には、チャンネルおよび帯域の２つのリソースを確保する必要がある。ＩＥＣ６１８８３では、あるチャンネルにおいていずれかの接続を最初に行った機器がこれらのリソースを確保し、最後に接続を切った機器がこれらのリソースを解放しなければならないことになっている。
【００３２】
さて、送信装置であるＤＶ１０２からＰＣ１０１にデータを伝送する方法について説明する。
【００３３】
まずＤＶ１０２の動作について説明する。
【００３４】
ＤＶ１０２は再生開始指示を受けると、ｏＰＣＲ［０］１０８内のｂｃｃに１を代入する。データ出力部１０７は、ＤＶデータ１１１をＩＥＥＥ１３９４インタフェース１０９に出力を開始する。ＩＥＥＥ１３９４インタフェース１０９は受け取ったＤＶデータ１１１を分割したパケットデータ２０１に、ＣＩＰヘッダ２０２を付加し図２のようなＣＩＰ１１２を作成し、さらにアイソクロナスヘッダ３０１、ヘッダＣＲＣ３０２およびデータＣＲＣ３０３を付加し図３のようなアイソクロナスパケットを作成し、ＩＥＥＥ１３９４バス１１０に出力する。このとき出力するチャンネルはｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒに書き込まれている値によって決まる。ｂｃｃを１にする直前までｐ２ｐが０、すなわちいずれの接続もされていない場合には、ＩＥＥＥ１３９４インタフェース１０９はｃｈａｎｎｅｌ ｎｕｍｂｅｒに書き込まれているチャンネルおよび必要な帯域を確保してから、ＩＥＥＥ１３９４バス１１０への出力を開始する。
【００３５】
ＤＶ１０２は再生停止指示を受けると、ｏＰＣＲ［０］１０８内のｂｃｃを０に戻し、データ出力部１０７はＩＥＥＥ１３９４インタフェース１０９への出力を停止し、ＩＥＥＥ１３９４インタフェース１０９はＩＥＥＥ１３９４バス１１０への出力を停止する。このときｂｃｃおよびｐ２ｐが共に０で、いずれの接続も行われていない状態になれば、ＩＥＥＥ１３９４インタフェース１０９は確保されているチャンネルおよび帯域のリソースを解放する。
【００３６】
次にＰＣ１０１の動作について説明する。
【００３７】
ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信開始指示を受けると、まずＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６を通して、ＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を送信してもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、送信要求を受け取ると、ｏＰＣＲ［０］１０８からレジスタデータ１１７を取り出しＩＥＥＥ１３９４インタフェース１０６に送信する。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６が受け取ったレジスタデータ１１７を応答１１６としてＤＶ用ドライバ１０４に出力する。
【００３８】
ＤＶ用ドライバ１０４は、レジスタデータ１１７の内容を見て、ｏＰＣＲ［０］１０８のｂｃｃが１であるか、ｐ２ｐが１以上の値であれば、ｏＰＣＲ［０］１０８内のｐ２ｐの値に１加えた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５としてｏＰＣＲ［０］１０８にレジスタデータ１１７を書き込む指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を書き換えてもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、書き込み要求を受け取ると、新しいレジスタデータ１１７が正当な値であれば、新しいレジスタデータ１１７をｏＰＣＲ［０］１０８に書き込む。
【００３９】
その後ＤＶドライバ１０４は、ｏＰＣＲ［０］１０８内のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されていた値、例えばｃｈ６３からデータ受信を開始する指示をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５として受信開始指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４バス１１０上のｃｈ６３からデータであるアイソクロナスパケットの受信を開始する。ＩＥＥＥ１３９４ドライバ１０５は、受信したアイソクロナスパケットからＣＩＰ１１２を取り出しＤＶ用ドライバ１０４に出力する。ＤＶ用ドライバ１０４は、ＣＩＰ１１２からパケットデータ２０１を取り出し、パケットデータ２０１からＤＶデータ１１１を作成し、アプリケーション１０３に出力する。
【００４０】
またＤＶ用ドライバ１０４は、レジスタデータ１１７の内容を見て、ｏＰＣＲ［０］１０８のｂｃｃおよびｐ２ｐが共に０であれば、ＩＥＥＥ１３９４バス１１０で他の機器が使っていないチャンネル、例えばｃｈ０をｏＰＣＲ［０］１０８内のｃｈａｎｎｅｌｎｕｍｂｅｒに代入し、かつｏＰＣＲ［０］１０８内のｐ２ｐの値に１加えた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５としてｏＰＣＲ［０］１０８にレジスタデータ１１７を書き込む指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を書き換えてもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、書き込み要求を受け取ると、新しいレジスタデータ１１７が正当な値であれば、新しいレジスタデータ１１７をｏＰＣＲ［０］１０８に書き込む。同時にＤＶ用ドライバ１０４は、ＩＥＥＥ１３９４バス１１０のリソースであるｃｈ０と必要な帯域の確保を行い、その後ｃｈ０からデータ受信を開始する指示をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５として受信開始指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４バス１１０上のｃｈ０からデータであるアイソクロナスパケットの受信を開始する。ＤＶ１０２がデータを出力していない場合には、ＩＥＥＥ１３９４ドライバ１０５はデータが出力されるまで待機する。
【００４１】
以降の動作は、ｏＰＣＲ［０］１０８のｂｃｃが１である場合と同様である。
【００４２】
一方、ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信停止指示を受けると、まずＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する指示をリクエスト１１５としてＩＥＥＥ１３９４インタフェース１０５に送信する。ＩＥＥＥ１３９４インタフェース１０５は受信停止指示を受け取ると、ＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する。
【００４３】
次にＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信停止指示を受けると、ＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。ＤＶ用ドライバ１０４は、ｏＰＣＲ［０］１０８内のｐ２ｐの値から１引いた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。上記と同様の動作によって、ＤＶ１０２のｏＰＣＲ［０］１０８の値を変更する。ｏＰＣＲ［０］１０８のｂｃｃが０でかつ先にＤＶ用ドライバ１０４がＩＥＥＥ１３９４バス１１０のリソースを確保していたのであれば、このとき同時にＤＶ用ドライバ１０４はＩＥＥＥ１３９４バス１１０のリソースを解放する。このときＤＶ用ドライバ１０４は、必要であればｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒの値を元に戻す。
【００４４】
以上の動作において、ＤＶ１０２のｏＰＣＲ［０］１０８の値およびＩＥＥＥ１３９４バス１１０のリソースを誰が確保し、誰が解放するかを表にしたものの一例が図１２から図１５である。
【００４５】
ＤＶ１０２の再生開始とＰＣ１０１の受信開始とどちらが先に行われたか、またＤＶ１０２の再生停止とＰＣ１０１の受信停止のどちらが先に行われたかで合計４通りの動作が考えれる。
【００４６】
図１２は、ＰＣ１０１の受信開始とＤＶ１０２の再生停止が先である場合である。ＰＣ１０１が受信を開始するときには、ＤＶ１０２の再生が開始されていないのでｏＰＣＲ［０］１０８のｂｃｃおよびｐ２ｐは共に０である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ０に、ｐ２ｐを１に変更し、かつＩＥＥＥ１３９４バス１１０のリソースを確保する。ＤＶ１０２が再生を開始するときには、すでにｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの確保は行わず、ｂｃｃを１に変更する。
【００４７】
ＤＶ１０２が再生を停止したときには、まだｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの解放を行わず、ｂｃｃを０に戻す。
【００４８】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ６３に戻し、同時にｐ２ｐも０に戻す。この時点でＤＶ１０２は再生していないのでｏＰＣＲ［０］１０８のｂｃｃも０である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００４９】
図１３は、ＰＣ１０１の受信開始とＰＣ１０１の受信停止が先である場合である。ＰＣ１０１が受信を開始するときには、ＤＶ１０２の再生が開始されていないのでｏＰＣＲ［０］１０８のｂｃｃおよびｐ２ｐは共に０である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ０に、ｐ２ｐを１に変更し、かつＩＥＥＥ１３９４バス１１０のリソースを確保する。ＤＶ１０２が再生を開始するときには、すでにｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの確保を行わず、ｂｃｃを１に変更する。
【００５０】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒをｃｈ６３に戻し、同時にｐ２ｐも０に戻す。この時点でＤＶ１０２はまだ再生しているのでｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放しない。
【００５１】
ＤＶ１０２が再生を停止したときには、ｂｃｃを０に戻すが、すでにｐ２ｐも０になっており、いずれの接続もされていないので、ＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００５２】
図１４は、ＤＶ１０２の再生開始とＰＣ１０１の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行い、さらにｂｃｃを１にする。
【００５３】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを１に変更するだけで、ｃｈａｎｎｅｌ ｎｕｍｂｅｒは変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。
【００５４】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを０に戻す。この時点でＤＶ１０２はまだ再生しているのでｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する必要はない。
【００５５】
ＤＶ１０２が再生を停止したときには、ｂｃｃを０に戻すが、すでにｐ２ｐも０になっており、いずれの接続もされていないので、ＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００５６】
図１５は、ＤＶ１０２の再生開始とＤＶ１０２の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行い、さらにｂｃｃを１にする。
【００５７】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを１に変更するだけで、ｃｈａｎｎｅｌ ｎｕｍｂｅｒは変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。
【００５８】
ＤＶ１０２が再生を停止したときには、まだｐ２ｐが１すなわちポイントツーポイント接続がされている状態なので、リソースの解放を行わず、ｂｃｃを０に戻す。
【００５９】
ＰＣ１０１が受信を停止したときには、ＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを０に戻す。この時点でＤＶ１０２は再生していないのでｏＰＣＲ［０］１０８のｂｃｃも０である。このときＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する必要があるが、ＩＥＥＥ１３９４ドライバ１０５およびＤＶ用ドライバ１０４は自分が確保したリソースでなければ解放できないという特徴を持っているため、リソースの解放を行えないことになる。
【００６０】
すなわち、ＤＶ１０２等のＩＥＥＥ１３９４バス１１０に接続されている機器は一般に他の機器が確保したリソースを解放することが出来る。これに対して、Ｗｉｎｄｏｗｓ９８が搭載されているＰＣ１０１では、自らが確保したリソースは解放できるが、他の機器が確保したリソースを解放することが出来ないという特徴を持っている。
【００６１】
前述したように、ＩＥＣ６１８８３では、あるチャンネルにおいていずれかの接続を最初に行った機器がこれらのリソースを確保し、最後に接続を切った機器がこれらのリソースを解放しなければならないことになっている。従って、ＩＥＣ６１８８３の規格に従えばＰＣ１０１０がリソースを解放すべきであるが、ＰＣ１０１の特徴によりリソースを解放することが出来ない。
【００６２】
一度リソースの解放が正しく行われないと、ＩＥＥＥ１３９４バス１１０にバスリセットを発生させないとそれらのリソースを再び使用できない。
【００６３】
【発明が解決しようとする課題】
しかしながら上記した従来の構成では、図１５のような順序で動作を行った場合、ＩＥＥＥ１３９４バスのリソースの解放を正しく行えず、それ以降それらのリソースを使用できなくなるという問題点があった。
【００６４】
本発明はこのような従来の問題点を鑑みてなされたものであって、ＩＥＥＥ１３９４バスのリソースを常に正しく解放できるデータ伝送方法を提供することを目的とするものである。
【００６５】
【課題を解決するための手段】
上述した課題を解決するために、第１の本発明（請求項１に対応）は、ＩＥＣ６１８８３準拠のデータ受信装置と、ＩＥＣ６１８８３準拠のデータ送信装置とがＩＥＥＥ１３９４バスに接続されている場合、
前記データ受信装置が、ＩＥＥＥ１３９４インタフェースと、前記ＩＥＥＥ１３９４バスに接続されている機器の全部または一部を制御する機器制御手段とを有し、かつ自身が確保していないＩＥＥＥ１３９４バスにおける帯域を解放することができないパーソナルコンピュータである場合、
前記データ受信装置は、受信開始指示を受け取ると、前記データ送信装置がブロードキャスト伝送を用いて出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力している場合に、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張らずに前記出力データの受信を行うことを特徴とする受信方法である。
【００６６】
また、第２の本発明（請求項２に対応）は、前記データ送信装置は、出力制御レジスタを保有しており、
前記出力制御レジスタには、ブロードキャスト伝送を行っているかどうかを示すフラグと、前記出力データをどのチャンネルに出力するかを示すチャンネル番号とが含まれており、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は、前記フラグを読むことにより、前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力している場合には、
前記データ受信装置は、前記チャンネル番号の変更を行わず、前記チャンネル番号に記述されているチャンネルから前記出力データを受信することを特徴とする第１の本発明に記載の受信方法である。
【００６７】
また、第３の本発明（請求項３に対応）は、前記データ送信装置は、出力制御レジスタを保有しており、
前記出力制御レジスタには、内部にブロードキャスト伝送を行っているかどうかを示すフラグと、出力データをどのチャンネルに出力するかを示すチャンネル番号とが含まれており、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は、前記フラグを読むことにより、前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ受信装置は、前記チャンネル番号を任意の値Ｎ（Ｎは０から６３までの整数）に変更した後、チャンネル番号が前記Ｎであるチャンネルから前記出力データを受信することを特徴とする第１の本発明に記載の受信方法である。
【００６８】
また、第４の本発明（請求項４に対応）は、前記データ送信装置が前記出力データをＩＥＥＥ１３９４バスに出力していない場合、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張った後、前記データ送信装置が前記出力データを前記ＩＥＥＥ１３９４バスに出力を開始すると同時に、前記データ受信装置は前記出力データの受信を行うことを特徴とする第２または３の本発明に記載の受信方法である。
【００６９】
また、第５の本発明（請求項５に対応）は、前記ＩＥＥＥ１３９４バスには、ＩＥＣ６１８８３準拠の第２のデータ受信装置が接続されており、
前記データ送信装置が、前記第２のデータ受信装置に対しポイントツーポイント接続を張られているまたは張っている状態で、かつブロードキャスト伝送を用いずに、前記ＩＥＥＥ１３９４バスに前記出力データの出力を行っている場合には、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張り、 前記出力データの受信を行うことを特徴とする第２から４の本発明のいずれかに記載の受信方法である。
【００７０】
また、第６の本発明（請求項６に対応）は、前記データ送信装置は、家庭用ディジタルＶＣＲであることを特徴とする第１から５の本発明のいずれかに記載の受信方法である。
【００７１】
また、第７の本発明（請求項７に対応）は、前記データ送信装置は、ＭＰＥＧデータを出力するセットトップボックスであることを特徴とする第１から５の本発明のいずれかに記載の受信方法である。
【００７２】
また、第８の本発明（請求項８に対応）は、第１から７の本発明のいずれかに記載の受信方法の全部または一部のステップの全部または一部の動作をコンピュータにより実行させるためのプログラム及び／またはデータを記録した記録媒体であって、
コンピュータにより読み取り可能なことを特徴とするプログラム記録媒体である。
【００７３】
【発明の実施の形態】
（実施の形態１）
以下、本発明の第１の実施形態について、図１から図５および図１０から図１３を用いて説明する。
【００７４】
ＤＶ１０２の構成および動作は従来例と同様であり、またＰＣ１０１の構成も従来例と同様である。
【００７５】
なお、本実施の形態のＤＶ１０２は本発明のデータ送信装置の例であり、本実施の形態のＰＣ１０１は本発明のパーソナルコンピュータの例であり、本実施の形態のＤＶ用ドライバ１０４、ＩＥＥＥ１３９４ドライバ１０５は本発明の機器制御手段の例である。
【００７６】
ＰＣ１０１の動作について説明する。
【００７７】
ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信開始指示を受けると、まずＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６を通して、ＩＥＥＥ１３９４インタフェース１０９にｏＰＣＲ［０］１０８内のレジスタデータ１１７を送信してもらうように要求する。ＩＥＥＥ１３９４インタフェース１０９は、送信要求を受け取ると、ｏＰＣＲ［０］１０８からレジスタデータ１１７を取り出しＩＥＥＥ１３９４インタフェース１０６に送信する。ＩＥＥＥ１３９４ドライバ１０５は、ＩＥＥＥ１３９４インタフェース１０６が受け取ったレジスタデータ１１７を応答１１６としてＤＶ用ドライバ１０４に出力する。
【００７８】
ＤＶ用ドライバ１０４は、レジスタデータ１１７の内容を見て、ｏＰＣＲ［０］１０８のｂｃｃが１であれば、ＤＶ１０２に対してポイントツーポイント接続を張らず、すなわちそのままｏＰＣＲ［０］１０８内のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示された値、例えばｃｈ６３からデータ受信を開始する指示をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送信する。ＩＥＥＥ１３９４ドライバ１０５は、リクエスト１１５として受信開始指示を受け取ると、ＩＥＥＥ１３９４インタフェース１０６を通してＩＥＥＥ１３９４バス１１０上のｃｈ６３からデータであるアイソクロナスパケットの受信を開始する。
【００７９】
以降の動作は従来例と同様である。
【００８０】
またｏＰＣＲ［０］１０８のｂｃｃが０である場合の動作は従来例と同じである。
【００８１】
一方、ＤＶ用ドライバ１０４は、アプリケーション１０３から動作指示１１４として受信停止指示を受けると、まずＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する指示をリクエスト１１５としてＩＥＥＥ１３９４インタフェース１０５に送信する。ＩＥＥＥ１３９４インタフェース１０５は受信停止指示を受け取ると、ＩＥＥＥ１３９４バス１１０からデータを受信するのを停止する。
【００８２】
次にＤＶ用ドライバ１０４は、受信開始時にｏＰＣＲ［０］１０８内のｐ２ｐの値に１を加えてポイントツーポイント接続を行っている場合には、ＤＶ１０２のｏＰＣＲ［０］１０８の値を取得するよう要求をリクエスト１１５としてＩＥＥＥ１３９４ドライバ１０５に送る。その後ＤＶ用ドライバ１０４は、ｏＰＣＲ［０］１０８内のｐ２ｐの値から１引いた値をｏＰＣＲ［０］１０８のｐ２ｐに代入したものを新たなレジスタデータ１１７としてｏＰＣＲ［０］１０８に書き込む指示をリクエスト１１５として、ＩＥＥＥ１３９４ドライバ１０５に送信する。上記と同様の動作によって、ＤＶ１０２のｏＰＣＲ［０］１０８の値を変更する。ｏＰＣＲ［０］１０８のｂｃｃが０でかつ先にＤＶ用ドライバ１０４がＩＥＥＥ１３９４バス１１０のリソースを確保していたのであれば、このとき同時にＤＶ用ドライバ１０４はＩＥＥＥ１３９４バス１１０のリソースを解放する。このときＤＶ用ドライバ１０４は、必要であればｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒの値を元に戻す。
【００８３】
またＤＶ用ドライバ１０４は、受信開始時にＤＶ１０２に対してポイントツーポイント接続を張っていない場合には、そのまま何もせず処理を終了する。
【００８４】
以上の動作において、ＤＶ１０２のｏＰＣＲ［０］１０８の値およびＩＥＥＥ１３９４バス１１０のリソースを誰が確保し、誰が解放するかを表にしたものの一例が図１０から図１３である。
【００８５】
従来例と同様に、ＤＶ１０２の再生開始とＰＣ１０１の受信開始とどちらが先に行われたか、またＤＶ１０２の再生停止とＰＣ１０１の受信停止のどちらが先に行われたかで合計４通りの動作が考えれる。
【００８６】
図１０は、ＤＶ１０１の再生開始とＰＣ１０１の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行う。
【００８７】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｃｈａｎｎｅｌ ｎｕｍｂｅｒおよびｐ２ｐの値を何も変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。すなわちポイントツーポイント接続を行わず、ブロードキャスト伝送のみを使用することになる。
【００８８】
ＰＣ１０１が受信を停止したときには、ＤＶ１０２はまだ再生しているのでｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はＩＥＥＥ１３９４バス１１０のリソースを解放する必要はない。
【００８９】
ＤＶ１０２が再生を停止したときには、ｂｃｃを０に戻すが、ｐ２ｐも０のままであり、いずれの接続もされていないので、ＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放する。
【００９０】
図１１は、ＤＶ１０２の再生開始とＤＶ１０２の受信停止が先である場合である。ＤＶ１０２が再生を開始するときには、まだｐ２ｐは０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０１はリソースの確保を行う。
【００９１】
ＰＣ１０１が受信を開始するときには、すでにＤＶ１０２の再生が開始されておりｏＰＣＲ［０］１０８のｂｃｃは１である。このためＰＣ１０１はｏＰＣＲ［０］１０８のｐ２ｐを１に変更するだけで、ｃｈａｎｎｅｌ ｎｕｍｂｅｒは変更せず、またＩＥＥＥ１３９４バス１１０のリソースの確保も行わない。
【００９２】
ＤＶ１０２が再生を停止したときには、やはりｐ２ｐが０すなわちポイントツーポイント接続がされていない状態なので、ＤＶ１０２はリソースの解放を行う。
【００９３】
ＰＣ１０１が受信を停止したときには、すでにＤＶ１０２はＩＥＥＥ１３９４バス１１０のリソースを解放しており、ＰＣ１０１は受信を停止するだけでよい。
【００９４】
ＰＣ１０１の受信開始を先に行う場合の動作は、従来例と同じく図１２および図１３のようになる。
【００９５】
以上により、ＰＣ１０１が自らが確保したリソースは解放出来るが、他の機器が確保したリソースは解放することが出来ないという特徴を持っている場合でも、ＰＣ１０１の受信開始／停止、ＤＶ１０２の再生開始／停止がどういう順序で行われても、ＩＥＥＥ１３９４バス１０５のリソースの確保・解放を必ず正しく行われるようになる。
【００９６】
なお、ＤＶ１０２のｏＰＣＲ［０］１０８に初期状態で書き込まれているｃｈａｎｎｅｌ ｎｕｍｂｅｒの値はｃｈ６３としたが、０から６３のいずれかの整数値であれば構わない。
【００９７】
またＰＣ１０１が、ＤＶ１０２に対してポイントツーポイント接続を行ったときに、ＤＶ１０２のｏＰＣＲ［０］１０８のｃｈａｎｎｅｌ ｎｕｍｂｅｒの値をｃｈ０にするとしたが、すでに他の機器が確保していないチャンネルであれば０から６３のうちのいずれかの整数値でも構わない。
【００９８】
またＩＥＥＥ１３９４バス１１０上には、ＰＣ１０１とＤＶ１０２とが接続されているとしたが、他のＩＥＥＥ１３９４機器が接続されていても構わない。
【００９９】
また初期状態でＤＶ１０２のｏＰＣＲ［０］１０８のｐ２ｐは０、すなわちＤＶ１０２は他のいずれの機器との間でポイントツーポイント接続が張られていない状態であるとしたが、初期状態でＤＶ１０２は他の機器との間にポイントツーポイント接続が張られていても構わない。
【０１００】
また、本実施の形態では、ＰＣ１０１の動作を説明したが、本実施の形態のＰＣ１０１以外の機器すなわち他の機器が確保したリソースを解放することが出来る機器がＤＶ１０２からデータを受信する場合、本実施の形態のＰＣ１０１の動作と同様の動作をしても構わないし、あるいは従来の技術で説明したＰＣ１０１と同様の動作をしても構わない。
【０１０１】
また、データ受信装置は、ハードウェア、ソフトウェアもしくはその両方を用いて構成されていても構わない。
【０１０２】
また、本発明の受信方法の全部または一部のステップの全部または一部の動作をコンピュータにより実行させるためのプログラム及び／またはデータを記録したプログラム記録媒体であって、コンピュータにより読み取り可能であり、読み取られた前記プログラム及び／またはデータが前記コンピュータと協動して前記機能を実行することを特徴とするプログラム記録媒体も本発明に属する。
【０１０３】
【発明の効果】
以上説明したように、本発明によれば、データ送信装置がすでにブロードキャスト伝送で送信を行っている場合には、データ受信装置はポイントツーポイント接続を張らずにブロードキャスト伝送で受信を行うようにすることで、データ伝送終了時にＩＥＥＥ１３９４バスのリソースを常に正しく解放する事が可能となった。
【図面の簡単な説明】
【図１】本発明の第１実施形態および従来例におけるデータ送信装置およびデータ受信装置の例を示す図
【図２】ＣＩＰ１１２の構成例を示す図
【図３】アイソクロナスパケットの構成例を示す図
【図４】ｏＰＣＲの構成を示す図
【図５】ｉＰＣＲの構成を示す図
【図６】ＩＥＣ６１８８３におけるブロードキャスト伝送の概念図
【図７】ＩＥＣ６１８８３におけるポイントツーポイント伝送の概念図
【図８】ＩＥＣ６１８８３におけるブロードキャスト伝送とポイントツーポイント伝送とが同時に行われているときの状態を表す概念図
【図９】送信装置６０２のｉＰＣＲ［０］、および受信装置６０１のｏＰＣＲ［０］の値の一例を示す図
【図１０】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１１】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１２】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１３】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１４】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【図１５】ｏＰＣＲ［０］１０８内の値の遷移を示す図
【符号の説明】
１０１ ＰＣ
１０２ ＤＶ
１０３ アプリケーション
１０４ ＤＶ用ドライバ
１０５ ＩＥＥＥ１３９４ドライバ
１０６ ＩＥＥＥ１３９４インタフェース
１０７ データ出力部
１０８ ｏＰＣＲ［０］
１０９ ＩＥＥＥ１３９４インタフェース
１１０ ＩＥＥＥ１３９４バス
１１１ ＤＶデータ
１１２ ＣＩＰ
１１４ 動作指示
１１５ リクエスト
１１６ 応答
１１７ レジスタデータ
２０１ パケットデータ
２０２ ＣＩＰヘッダ
３０１ アイソクロナスヘッダ
３０２ ヘッダＣＲＣ
３０３ データＣＲＣ
６０１ 受信装置
６０２ 送信装置
Claims (8)
- ＩＥＣ６１８８３準拠のデータ受信装置と、ＩＥＣ６１８８３準拠のデータ送信装置とがＩＥＥＥ１３９４バスに接続されている場合、
前記データ受信装置が、ＩＥＥＥ１３９４インタフェースと、前記ＩＥＥＥ１３９４バスに接続されている機器の全部または一部を制御する機器制御手段とを有し、かつ自身が確保していないＩＥＥＥ１３９４バスにおける帯域を解放することができないパーソナルコンピュータである場合、
前記データ受信装置は、受信開始指示を受け取ると、前記データ送信装置がブロードキャスト伝送を用いて出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力している場合に、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張らずに前記出力データの受信を行うことを特徴とする受信方法。 - 前記データ送信装置は、出力制御レジスタを保有しており、
前記出力制御レジスタには、ブロードキャスト伝送を行っているかどうかを示すフラグと、前記出力データをどのチャンネルに出力するかを示すチャンネル番号とが含まれており、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は、前記フラグを読むことにより、前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力している場合には、
前記データ受信装置は、前記チャンネル番号の変更を行わず、前記チャンネル番号に記述されているチャンネルから前記出力データを受信することを特徴とする請求項１記載の受信方法。 - 前記データ送信装置は、出力制御レジスタを保有しており、
前記出力制御レジスタには、内部にブロードキャスト伝送を行っているかどうかを示すフラグと、出力データをどのチャンネルに出力するかを示すチャンネル番号とが含まれており、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は、前記フラグを読むことにより、前記データ送信装置がブロードキャスト伝送を用いて前記出力データを前記ＩＥＥＥ１３９４バスに出力しているかどうかを判断し、
前記データ受信装置は、前記チャンネル番号を任意の値Ｎ（Ｎは０から６３までの整数）に変更した後、チャンネル番号が前記Ｎであるチャンネルから前記出力データを受信することを特徴とする請求項１記載の受信方法。 - 前記データ送信装置が前記出力データをＩＥＥＥ１３９４バスに出力していない場合、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張った後、前記データ送信装置が前記出力データを前記ＩＥＥＥ１３９４バスに出力を開始すると同時に、前記データ受信装置は前記出力データの受信を行うことを特徴とする請求項２または３記載の受信方法。 - 前記ＩＥＥＥ１３９４バスには、ＩＥＣ６１８８３準拠の第２のデータ受信装置が接続されており、
前記データ送信装置が、前記第２のデータ受信装置に対しポイントツーポイント接続を張られているまたは張っている状態で、かつブロードキャスト伝送を用いずに、前記ＩＥＥＥ１３９４バスに前記出力データの出力を行っている場合には、
前記データ受信装置が、前記パーソナルコンピュータである場合、
前記データ受信装置は前記データ送信装置にポイントツーポイント接続を張り、 前記出力データの受信を行うことを特徴とする請求項２から４のいずれかに記載の受信方法。 - 前記データ送信装置は、家庭用ディジタルＶＣＲであることを特徴とする請求項１から５のいずれかに記載の受信方法。
- 前記データ送信装置は、ＭＰＥＧデータを出力するセットトップボックスであることを特徴とする請求項１から５のいずれかに記載の受信方法。
- 請求項１から７のいずれかに記載の受信方法の全部または一部のステップの全部または一部の動作をコンピュータにより実行させるためのプログラム及び／またはデータを記録した記録媒体であって、
コンピュータにより読み取り可能なことを特徴とするプログラム記録媒体。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35452499A JP3560522B2 (ja) | 1999-12-14 | 1999-12-14 | Ｉｅｅｅ１３９４上のデータ受信装置における受信方法 |
| US09/691,298 US6937599B1 (en) | 1999-10-21 | 2000-10-18 | Data source, data conversion device, inverse data conversion device, auxiliary data file generation device, reception method, medium and information aggregate |
| EP00122874A EP1094637B1 (en) | 1999-10-21 | 2000-10-20 | IEEE 1394 bus interface |
| CNB001371533A CN1290025C (zh) | 1999-10-21 | 2000-10-20 | 接收方法 |
| DE60025128T DE60025128T2 (de) | 1999-10-21 | 2000-10-20 | Busschnittstelle für IEEE 1394 |
| KR1020000062098A KR20010060188A (ko) | 1999-10-21 | 2000-10-21 | 데이터 소스, 데이터 변환 장치, 데이터 역변환 장치,보조 데이터 파일 생성장치, 수신 방법, 매체 및 정보 집합 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35452499A JP3560522B2 (ja) | 1999-12-14 | 1999-12-14 | Ｉｅｅｅ１３９４上のデータ受信装置における受信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001175592A JP2001175592A (ja) | 2001-06-29 |
| JP3560522B2 true JP3560522B2 (ja) | 2004-09-02 |
Family
ID=18438144
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP35452499A Expired - Fee Related JP3560522B2 (ja) | 1999-10-21 | 1999-12-14 | Ｉｅｅｅ１３９４上のデータ受信装置における受信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3560522B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3758045B2 (ja) | 2003-01-31 | 2006-03-22 | 船井電機株式会社 | Ｉｅｅｅ１３９４シリアルバスへの接続機器 |
-
1999
- 1999-12-14 JP JP35452499A patent/JP3560522B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001175592A (ja) | 2001-06-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1330895B1 (en) | Bridging system for interoperation of remote groups of devices | |
| US20090210548A1 (en) | Method of and apparatus for providing isochronous services over switched ethernet including a home network wall plate having a combined ieee 1394 and ethernet modified hub | |
| CZ20011592A3 (cs) | Seskupená sí»ová zařízení | |
| JP4468519B2 (ja) | プロトコールインターフェース方法 | |
| US6041286A (en) | Apparatus for and method of accurately obtaining the cycle time of completion of transmission of video frames within an isochronous stream of data transmitted over an IEEE 1394 serial bus network | |
| JP3291926B2 (ja) | 電子機器制御方式 | |
| US7154910B2 (en) | Method for any speed dubbing using isochronous packets on isochronous channels or on asynchronous streams over an IEEE 1394-2000 serial bus network | |
| JPH10145420A (ja) | 異なるシステムに接続された機器の制御方法及び変換機器 | |
| JP3560522B2 (ja) | Ｉｅｅｅ１３９４上のデータ受信装置における受信方法 | |
| JP2004509518A (ja) | 通信システムおよびデバイス | |
| JP2001057567A (ja) | 伝送路間のブリッジシステム及び方法 | |
| EP1061692A2 (en) | Controlling device, communication system and controlling method | |
| JP2002057683A (ja) | 制御機器および制御方法 | |
| JP3972288B2 (ja) | 信号処理システム、信号出力装置、信号入力装置及び通信制御方法 | |
| KR101119609B1 (ko) | 버스 구조 네트워크 상에서 통신을 수행하는 방법 및 디바이스 | |
| JP3704773B2 (ja) | 電子機器及びその制御方法 | |
| KR100763716B1 (ko) | 정보 제어 방법, 정보 처리 장치, 및 정보 제어 시스템 | |
| JP3739087B2 (ja) | Ａｖ機器及びその制御方法、ａｖ機器ネットワークシステム | |
| JP2002538732A (ja) | バス上のデータを該バスにより制御される装置に転送、又は装置から転送するための方法及び装置 | |
| Kobayashi | Design and Implementation of a Firewire Device Driver on FreeBSD. | |
| JP3637817B2 (ja) | 機器接続方法およびプログラム記録媒体 | |
| JP3152232B2 (ja) | データ伝送方法 | |
| JP3341758B2 (ja) | データ転送方法 | |
| JP3702888B2 (ja) | 通信制御方法及び通信システム | |
| JP2005167800A (ja) | データ通信装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040309 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040412 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040518 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040525 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |