JP2016116178A - 通信装置及び通信方法 - Google Patents

Abstract

【課題】所定の通信インターフェース規格に則って、映像や音声の信号を好適に伝送する通信装置を提供する。【解決手段】ＭＨＬケーブルで接続されたＭＨＬデバイス間でＣＢＵＳを経由してデータ伝送を行なう際、コマンドに優先順位を付ける。コマンドの送信処理の際、伝送待ちのコマンドが存在する場合でも、優先順位の高いコマンドからＣＢＵＳ上に伝送するようにして、伝送遅延に起因する問題を解消できる。また、受信処理の際、優先度の高いコマンドから受信処理を行なうい、規定時間内にコマンド処理を終了させることができる。【選択図】 図１８

Description

本明細書で開示する技術は、所定の通信インターフェース規格に則ってデータ伝送を行なう通信装置及び通信方法に係り、例えばＭＨＬ（ＭｏｂｉｌｅＨｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）に則って音声・映像信号の伝送を行なう通信装置及び通信方法に関する。

近年、スマートフォンやタブレットなど、高精細な音声・映像を表示可能な携帯機器の普及が進んである。これに伴って、携帯機器向けの高速に音声・映像を伝送するための通信インターフェース規格であるＭＨＬの開発が進められている（例えば、特許文献１を参照のこと）。非圧縮のディジタル映像伝送を実現する通信インターフェース規格として、ＨＤＭＩ（登録商標）（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）も挙げられる。これに対し、ＭＨＬには、音声・映像伝送に必要な最小限のピン構成として実装面積を最小にしたことや、電源供給をサポートしたことに主な特徴がある。

ＭＨＬ機器は、音声・映像信号を送信するソース機器と、映像信号を受信し表示するシンク機器と、ＭＨＬ形式の映像信号を他の映像信号に変換するドングル機器というカテゴリーに分類される。そして、ＭＨＬ機器間の接続並びに信号伝送には、ＭＨＬ規格を満たすＭＨＬケーブルが使用される。ソース機器には、パーソナル・コンピューターや、スマートフォン、タブレット端末、ゲーム機器、ディジタルカメラなどが含まれる。また、シンク機器には、ディジタルＴＶなどのディスプレイ装置が含まれる。ソース機器とシンク機器をＭＨＬケーブル１本で接続することで、高精細映像を伝送すると同時に、電源の供給（ソース機器の充電）を行なうことができる。ＭＨＬ規格では、基本的には、ソース機器からシンク機器への一方向で音声・映像信号を伝送することを想定している。

ＭＨＬ規格は、映像や音声の信号伝送用の（Ｔｒａｎｓｉｔｉｏｎ Ｍｉｎｉｍｉｚｅｄ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｓｉｇｎａｌｉｎｇ：遷移数最少差動信号伝送方式）チャネルの他、伝送制御や機器連携などの通信に用いられる制御信号ＣＢＵＳ（Ｃｏｎｔｒｏｌ Ｂｕｓ）若しくはｅＣＢＵＳ、電源供給に使用される電源線ＶＢＵＳ（Ｖｏｌｔａｇｅ Ｂｕｓ）を含んでいる。

通常のＭＨＬプロセスでは、シンク機器は、ＴＭＤＳ信号で映像や音声の信号が受信可能になると、ＣＢＵＳを介してソース機器に通知する。ソース機器は、この通知を受けると、ＣＢＵＳを使ってシンク機器のＥＤＩＤ（Ｅｘｔｅｎｄｅｄ Ｄｉｓｐｌａｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｄａｔａ）を読み込み、シンク機器側で対応する映像や音声のフォーマット、ケーパビリティー情報などを取得して、伝送方法を最適化する。また、ディジタル・コンテンツの不正使用を防止するために、ＣＢＵＳ上でＨＤＣＰ（Ｈｉｇｈ−Ｂａｎｄｗｉｄｔｈ Ｄｉｇｉｔａｌ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）認証を行なう。

データは、８ビット毎に１６ビット中のＣＢＵＳパケットを構成して、ＣＢＵＳ上をシリアル伝送される。ＣＢＵＳパケットで伝送するデータの種類は、ＤＤＣ（Ｄｉｓｐｌａｙ Ｄａｔａ Ｃｈａｎｎｅｌ）コマンド、ＭＳＣ（ＭＨＬ Ｓｉｄｅｂａｎｄ Ｃｈａｎｎｅｌ）コマンドの２種類に大別される。現状では、各コマンドは伝送要求が行なわれた順番で時系列に並べられ、先頭から順に８ビットずつパケットを構成してＣＢＵＳ上で伝送される。

しかしながら、ＣＢＵＳのトラフィック量が増大して、送信キューに多数のコマンドが送信待ちとなっているとき、伝送遅延の問題がある。時間に制約が有って至急伝送する事が望ましいコマンドでも、前のコマンドがすべて伝送されるまで待機しなければならない。例えば、定期的にＨＤＣＰの人に証を行なう機器間処理ＤＤＣコマンドを使って行なうが、伝送遅延が発生すると認証に失敗して、一瞬ディスプレイ画面がブラックアウトするトラブルが発生する。

また、ＭＨＬ規格には、デバイスＡに装備されたキーボードやスイッチを使い、デバイスＡとＭＨＬケーブルで接続されたデバイスＢをコントロールする機能がある。このとき、デバイスＡで入力したキーコードをＭＳＣコマンドにしてデバイスＢに伝送するが、伝送遅延が発生するとデバイスＢのレスポンスが遅延量に比例して遅れることになり、商品に対する質的な問題が発生する。

特開２０１２−１６９７０２号公報

本明細書で開示する技術の目的は、所定の通信インターフェース規格に則って、映像や音声の信号を好適に伝送することができる、優れた通信装置及び通信方法を提供することにある。

本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
少なくとも音声・映像伝送用のチャネルと双方向データ・バスを含み、所定の通信インターフェース規格に則った伝送ケーブルで通信相手と接続される通信装置であって、
コマンドの処理の優先度を管理する優先度管理部と、
前記双方向データ・バスを経由して前記通信相手とコマンドの送受信を処理する送受信部と、
を具備する通信装置である。

本願の請求項２に記載の技術によれば、請求項１に記載の通信装置の前記優先度管理部は、タスクから非同期で伝送要求されるコマンドを送信する優先度を管理するように構成されている。

本願の請求項３に記載の技術によれば、請求項１に記載の通信装置の前記優先度管理部は、受信したコマンドを受信処理するタスクにコマンドを引き渡す優先度を管理するように構成されている。

本願の請求項４に記載の技術によれば、請求項２に記載の通信装置の前記優先度管理部は、優先順位別の複数種類の送信バッファーと、伝送要求するタスクが希望する優先度に対応した送信バッファーにコマンドを書き込む振分け処理部と、優先度の順に各送信バッファーからコマンドを取り出して前記送受信部に引き渡す処理取出し部を備えている。

本願の請求項５に記載の技術によれば、データ長が異なる複数のコマンド・フォーマットが規定されている。そして、請求項４に記載の通信装置の前記取出し処理部は、コマンド・フォーマットに応じて１コマンド分ずつ送信バッファーから取り出して前記送受信部に引き渡すように構成されている。

本願の請求項６に記載の技術によれば、請求項３に記載の通信装置の前記優先度管理部は、優先順位別の複数種類の受信バッファーと、前記送受信部が受信したパケットを優先度に対応した受信バッファーにコマンドを書き込む振分け処理部と、優先度の順に各受信バッファーからパケットを取り出して対応するコマンドの処理を行なうタスクに引き渡す処理取出し部を備えている。

本願の請求項７に記載の技術によれば、データ長が異なる複数のコマンド・フォーマットが規定されている。そして、請求項６に記載の通信装置の前記振分け処理部は、コマンド・フォーマットに応じて１コマンド分のパケットを優先度に対応する受信バッファーに書き込み、前記取出し処理部は、１コマンド分のパケットを受信バッファーから取り出して対応するタスクに引き渡すように構成されている。

本願の請求項８に記載の技術によれば、請求項１に記載の通信装置の前記優先度管理部は、条件に応じて優先度の段階数を切り換えるように構成されている。

本願の請求項９に記載の技術によれば、請求項１に記載の通信装置の前記優先度管理部は、前記双方向データ・バスのトラフィック量に応じて優先度の段階数を切り換えるように構成されている。

本願の請求項１０に記載の技術によれば、請求項１に記載の通信装置の前記双方向データ・バス上で伝送するパケットに優先度を示す優先度フィールドを設定し、前記優先度管理部は、前記優先度フィールドに設定された値に基づいて、パケットで伝送するコマンドの処理の優先度を管理するように構成されている。

本願の請求項１１に記載の技術によれば、請求項１に記載の通信装置の前記優先度管理部は、コマンドのタイプに応じて、コマンドの処理の優先度を管理するように構成されている。

本願の請求項１２に記載の技術によれば、請求項１１に記載の通信装置の前記優先度管理部は、条件に応じてコマンド・タイプ毎の優先度を切り換えるように構成されている。

本願の請求項１３に記載の技術によれば、請求項１に記載の通信装置の前記通信インターフェース規格はＭＨＬ規格である。

また、本願の請求項１４に記載の技術は、
所定の通信インターフェース規格に則った伝送ケーブルに含まれる音声・映像伝送用のチャネルで音声・映像信号を伝送するステップと、
伝送要求されたコマンドを優先度に応じて前記伝送ケーブルに含まれる双方向データ・バスに送信するステップと、
前記双方向データ・バス経由で受信したコマンドを優先度に応じて処理するステップと、
を有する通信方法である。

本明細書で開示する技術によれば、所定の通信インターフェース規格に則って、映像や音声の信号を好適に伝送することができる、優れた通信装置及び通信方法を提供することができる。

本明細書で開示する技術によれば、例えばＭＨＬケーブルで接続されたＭＨＬデバイス機器間で双方向データ・バス（ＣＢＵＳ）を経由してデータ伝送を行なう際に、コマンドに優先順位を付けることができるので、ＣＢＵＳ上の伝送順序を優先順位に基づいて変えることができる。したがって、伝送待ちのコマンドが存在する場合でも、優先順位の高いコマンドからＣＢＵＳ上に伝送するようにして、伝送遅延に起因する問題を解消することができる。

なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、ＭＨＬ規格に則った通信システム１の基本構成を模式的に示した図である。 図２は、ＣＢＵＳ及びｅＣＢＵＳモード時に使用するＭＨＬケーブル２００の構成を示した図である。 図３は、Ｍｉｃｒｏ−Ｂプラグ２０１とＨＤＭＩ（登録商標） Ｔｙｐｅ−Ａプラグ２０２間のケーブル結線図である。 図４は、ＭＨＬソース機器側で接続した相手を判定する方法を説明するための図である。 図５は、ＣＢＵＳモード時のＭＨＬパケットの構成を示した図である。 図６は、ｅＣＢＵＳ−Ｓ及びｅＣＢＵＳ−Ｄモード時のＭＨＬパケットの構成を示した図である。 図７は、ＭＳＣコマンドの構成を示した図である 図８は、ＤＤＣ Ｒｅａｄコマンドの一例としてＥＤＩＤを読み出す手順を示した図である。 図９は、ＭＨＬデバイス間でＭＨＬケーブルを介してコマンドを伝送する仕組みを模式的に示した図である。 図１０は、ＨＤＣＰ認証手順のステップ１における処理シーケンスを模式的に示した図である。 図１１は、ＨＤＣＰ認証手順のステップ３における処理シーケンスを模式的に示した図である。 図１２は、ＭＨＬで伝送するビデオ信号の１フレーム当りの構成を示した図である。 図１３は、ＤＤＣ Ｓｈｏｒｔ Ｒｅａｄコマンドのフォーマットを示した図である。 図１４は、ＭＨＬ規格の機器連携操作を行なうシステムの構成例を示した図である。 図１５は、ＲＣＰサブコマンドのフォーマットを示した図である。 図１６は、ＣＢＵＳモード時のＭＨＬパケット（優先順位の情報あり）の構成を示した図である。 図１７は、ｅＣＢＵＳ−Ｓ及びｅＣＢＵＳ−Ｄモード時のＭＨＬパケット（優先順位の情報あり）の構成を示した図である。 図１８は、ＭＨＬデバイス間でＭＨＬケーブルを介して優先順位を考慮してコマンドを伝送する仕組みを模式的に示した図である。 図１９は、ＭＳＣコマンド、及びＤＤＣコマンドのフォーマットを示した図である。

以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

図１には、ＭＨＬ規格に則って映像や音声を伝送する通信システム１の基本構成を模式的に示している。通信システム１は、ＭＨＬソース機器１０とＭＨＬシンク機器２０の組み合わせで構成される。ソース機器１０は、映像情報や音声情報の供給元であり、スマートフォンなどの携帯機器を想定している。また、シンク機器２０は、映像情報や音声情報の出力先であり、テレビ受信機など大画面を持つ設置機器を想定している。

ＭＨＬソース機器１０はＭＨＬ送信部１１を備え、ＭＨＬシンク機器２０はＭＨＬ受信部２１を備えており、ＭＨＬ送信部１１とＭＨＬ受信部２１の間は、ＭＨＬケーブル３０で接続されている。

ＭＨＬケーブル３０は、ＴＭＤＳチャネル３１と、ＣＢＵＳ（若しくはｅＣＢＵＳ）３２と、ＶＢＵＳ３３を含んでいる。

ＴＭＤＳチャネル３１は、主に、非圧縮のままの動画映像情報と音声情報を伝送するために使用される差動対線である。１本のＴＭＤＳチャネルを「レーン」と呼ぶ。非圧縮で映像を伝送する場合、ＭＨＬソース機器１０とＭＨＬシンク機器２０間で圧縮コーデックの互換性を考慮する必要がなく、映像の劣化と伝送遅延は発生しにくい。なお、ＴＭＤＳは、ＶＥＳＡ（ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）によって標準化されたディジタル映像信号の伝送方式であるが、詳細な説明は省略する。

ＣＢＵＳ３２は、主に映像及び音声伝送の制御や機器連携などのための通信に用いられる双方向データ・バスである。ＭＨＬのバージョン１〜２ではＣＢＵＳ、バージョン３以降ではｅＣＢＵＳと呼ばれるが、以下では総称して「ＣＢＵＳ」ということにする。

ＶＢＵＳ３３は、主に電源供給に使用される電源線である。基本的には、商用電源が接続されるテレビ受信機などのシンク機器２０からスマートフォンなどバッテリー駆動のソース機器１０への方向で、例えば５Ｖの電源が供給される。

ＭＨＬソース機器１０側のＭＨＬ送信部１１には、図示しない情報再生部で再生される映像情報（Ｖｉｄｅｏ）並びに音声情報（Ａｕｄｉｏ）が供給される。そして、送信部１１は、非圧縮のままの動画映像情報と音声情報を、ＴＭＤＳチャネル３１を使って送信する。一方、ＭＨＬシンク機器２０側のＭＨＬ受信部２１は、ＴＭＤＳチャネル３１を使って伝送される動画映像情報と音声情報を受信すると、図示しない情報出力部で画面表示や音声出力を行なう。

通常モードのＭＨＬプロセスについて説明しておく。ＭＨＬシンク機器２０は、ＴＭＤＳ信号で映像や音声の信号が受信可能になると、ＣＢＵＳ３２を介してソース機器１０に通知する。ＭＨＬソース機器１０は、この通知を受けると、ＣＢＵＳを使ってシンク機器のＥＤＩＤ−ＲＯＭ２２からＥＤＩＤを読み込み、ＭＨＬシンク機器２０側で対応する映像や音声のフォーマット、ケーパビリティー情報などを取得して、伝送方法を最適化する。また、ディジタル・コンテンツの不正使用を防止するために、ＣＢＵＳ３２上でＨＤＣＰ認証を行なう。

ＭＨＬにおけるデータ伝送レートは、ＭＨＬ１及びＭＨＬ２（ＣＢＵＳ）とＭＨＬ３（ｅＣＢＵＳ−Ｓ及びｅＣＢＵＳ−Ｄ）では異なる。バージョン毎のデータ伝送レートを以下の表１に示す。

図２には、ＣＢＵＳ並びにｅＣＢＵＳモード時に使用するＭＨＬケーブル２００の構成を示している。ＭＨＬケーブル２００の一端２０１はＭｉｃｒｏ−Ｂプラグで構成され、他端２０２は、ＨＤＭＩ（登録商標） Ｔｙｐｅ−Ａプラグで構成される。また、ＣＢＵＳ並びにｅＣＢＵＳ−Ｓモード時のＭＨＬソース機器側のピン割り当てを表２に示し、同じくＣＢＵＳ及びｅＣＢＵＳ−Ｓモード時のＭＨＬシンク機器側のピン割り当てを表３に示す。

また、図３には、Ｍｉｃｒｏ−Ｂプラグ２０１とＨＤＭＩ（登録商標） Ｔｙｐｅ−Ａプラグ２０２間のケーブル結線図を示している。ＭＨＬソース機器はＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）関連のＭｉｃｒｏ−Ｂプラグ２０１を使用し、ＭＨＬシンク機器はＨＤＭＩ（登録商標） Ｔｙｐｅ−Ａプラグ２０２を使用する。図示のように、ＭＨＬソース機器は、５本のライン（ＭＨＬ＋、ＭＨＬ−、ＣＢＵＳ／ｅＣＢＵＳ−Ｓ、ＶＢＵＳ、ＧＮＤ）で、ＭＨＬケーブルを介してＭＨＬシンク機器と接続される。

Ｍｉｃｒｏ−Ｂプラグの３番ピンのＭＨＬ＋と２番ピンのＭＨＬ−は、１対のツイストペアで、ＭＨＬソース機器からＭＨＬシンク機器方向にＡＶストリームを伝送する。伝送レートは、ＭＨＬ１／ＭＨＬ２では最大３Ｇｂｐｓであるのに対し、ＭＨＬ３では最大６Ｇｂｐｓである。

Ｍｉｃｒｏ−Ｂプラグの４番ピンは、ＭＨＬ１とＭＨＬ２ではＣＢＵＳ、ＭＨＬ３ではｅＣＢＵＳ−Ｓとなる。ＣＢＵＳは、ＤＤＣコマンドとＭＳＣコマンドを双方向に伝送するために使用される。ＤＤＣコマンドは、ＥＤＩＤ読み出しやＨＤＣＰの認証に使用する。また、ＭＳＣコマンドは、ＥＤＩＤ読み出し制御、各種レジスターのリード・ライト、リモコン制御などに使用する。伝送レートは１Ｍｂｐｓで半２重通信が可能である。一方、ｅＣＢＵＳ−Ｓモードでは、上記のＣＢＵＳの機能に加え、ＵＳＢ１、ＨＳＩＣ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｉｎｔｅｒ−Ｃｈｉｐ）、ＨＩＤ（Ｈｕｍａｎ Ｉｎｔｅｒｆａｃｅ Ｄｅｖｉｃｅ）、Ａｕｄｉｏの各データのトンネリング機能を持つ。伝送レートは７５Ｍｂｐｓで全２重通信が可能ある。

表４には、ｅＣＢＵＳＤモード時のＭＨＬソース機器側のピン割り当てを示している。表５には、同じくｅＣＢＵＳ−Ｄモード時のＭＨＬシンク機器側のピン割り当てを示している。

表４及び表５に示すように、ｅＣＢＵＳ−Ｄモードでは、データ・バスとして、ＣＢＵＳ／ｅＣＢＵＳ−Ｓラインの代わりに、ｅＣＢＵＳ−Ｄ＋とｅＣＢＵＳ−Ｄ−の差動線を使用する。本願の出願時点では、ｅＣＢＵＳ−Ｄモードで使用するケーブルは定義されていない。

ＭＨＬソース機器とＭＨＬシンク機器は、接続されたケーブルを経由し、初期状態から、お互いを認識し合ってＡＶコンテンツやＣＢＵＳパケット伝送が可能になるアクティブ状態になるまでの手順を実行する。前述したように、ＭＨＬソース機器側はＵＳＢ Ｍｉｃｒｏ−Ｂプラグを使用し、ＵＳＢ機器と兼用できる仕組みになっている。また、ＭＨＬシンク機器側はＨＤＭＩ（登録商標） Ｔｙｐｅ−Ａプラグを使用し、ＨＤＭＩ（登録商標）機器と兼用できる仕組みになっている。例えば、ＭＨＬケーブルの場合、図３に示したように、ＨＤＭＩ（登録商標）Ｔｙｐｅ−Ａプラグ内部で２ピンと１５ピン間を３．３ｋΩの抵抗で接続している。一方、ＨＤＭＩ（登録商標）ケーブル（図示しない）では、このような抵抗は使用されていないので、ＭＨＬシンク機器は、２ピンと１５ピン間の抵抗値を見てＭＨＬケーブルが接続されているか否かを判断することができ、ＭＨＬケーブルが接続されていると判断した場合にはＨＤＭＩ（登録商標）モードからＭＨＬモードに切り替える。

図４には、ＭＨＬソース機器側で接続された相手を判定する方法を図解している。また、表６には、ＭＨＬソース機器側のＭｉｃｒｏＵＳＢレセプタクルのピン割り当てを示しているが、ＭＨＬレセプタクルと兼用するものとする。

ＭＨＬソース機器は、まずＩＤピンの抵抗値を見て、１００ｋΩ以上であれば、接続された相手はＭｉｃｒｏＵＳＢ Ａ−Ｄｅｖｉｃｅとみなし、１０Ω以下ならＭｉｃｒｏＵＳＢＢ−Ｄｅｖｉｃｅとみなし、それぞれＵＳＢモードに移行する。また、ＩＤピンの抵抗値が０．８ｋΩ〜１．２ｋΩの範囲なら、接続された相手はＭＨＬシンク機器であると判断して、ＭＨＬモードに切り替える。表７には、ＭＨＬモードに移行した後のＭＨＬソース機器側のＭｉｃｒｏＵＳＢレセプタクルのピン割り当てを示している。

その後、ＭＨＬソース機器とＭＨＬシンク機器はＡＶコンテンツやＣＢＵＳパケット伝送が可能になるアクティブ状態になるまでの手順を実行する。但し、この過程は、本明細書で開示する技術と直接関連しないので、詳細な説明は省略する。

図５には、ＣＢＵＳモード時のＭＨＬパケットの構成を示している。以下、ＣＢＵＳモード時のＭＨＬパケットの各フィールドについて説明する。

Ｈｅａｄｅｒフィールドは、パケットが８ビットのペイロードで伝送するコマンドの種別を２ビットで示す。表８には、Ｈｅａｄｅｒフィールドのビット値とコマンドの種別の関係を示している。Ｈｅａｄｅｒが００であれば、当該パケットはＤＤＣコマンド伝送のであることを示し、１０であればＭＳＣコマンド伝送であることを示す。０１及び１１のビット値は使用しない。

Ｃｏｎｔｒｏｌフィールドは、パケットの８ビットのペイロードの種別を１ビットで示す。表９には、Ｃｏｎｔｒｏｌフィールドのビット値とペイロードの種別の関係を示している。Ｃｏｎｔｒｏｌビットが１であれば、当該パケットのペイロードに各コマンド種別（ＤＤＣ又はＭＳＣ）のうちコマンド・コードが格納されていることを示し、０であれはコマンドに付随するデータが格納されていることを示す。

Ｄａｔａ ｏｒ Ｃｏｍｍａｎｄフィールドは、Ｃｏｎｔｒｏｌビットが１であれば、ＤＤＣコマンド又はＭＳＣコマンド、０であればデータの１バイトを格納するためのペイロードである。Ｄａｔａ ｏｒ Ｃｏｍｍａｎｄフィールドに続くＰａｒｉｔｙビットは、偶数パリティーとして使用する。

また、図６には、ｅＣＢＵＳ−Ｓ及びｅＣＢＵＳ−Ｄモード時のＭＨＬパケットの構成を示している。Ｐａｒｉｔｙが５ビットのＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）に置き換わる以外はＣＢＵＳモード時のＭＨＬパケットの構成（図５を参照のこと）と同じなので、ここでは説明を省略する。

表１０には、ＭＨＬパケットで伝送するＭＳＣコマンド一覧を示している。また、図７には、ＭＳＣコマンドの構成を示している。図７（Ａ）に示すようにコマンド１バイトのみで構成される場合と、図７（Ｂ）に示すようにコマンド１バイトの後に１バイト以上のデータが付加される場合がある。これらをＭＨＬパケットで伝送するとき、Ｃｏｎｔｒｏｌビットは、コマンドの場合に１、データの場合は０となる。

表１１には、ＭＨＬパケットで伝送するＤＤＣコマンド一覧を示している。また、表１２には、ＤＤＣコントロール・コード一覧を示している。ＤＤＣコマンドは、ＭＳＣコマンドのようにコマンド種別に応じた特定のコード番号が割り当てられているのではなく、表１２で示すコントロール・コードの組み合わせた一連の手順で表現される。

図８には、ＤＤＣ Ｒｅａｄコマンドの一例として、ＥＤＩＤを読み出す手順を示している。同図は、ＭＨＬソース機器がＥＤＩＤのｎ番目のブロック（但し、０≦ｎ≦１２７，１ブロックは１２８バイトとする）の先頭からＥＤＩＤデータをＭＨＬシンク機器から読み出す手順である。図中、２重の６角形はコマンドを伝送するＭＨＬパケット（Ｃｏｎｔｒｏｌビット＝１）を表し、１重の６角形はデータを伝送するＭＨＬパケット（Ｃｏｎｔｒｏｌビット＝０）を表すものとする。また、左から右に向かう矢印（→）は、ＭＨＬソース機器からＭＨＬシンク機器の方向に伝送されるＭＨＬパケットであることを示し、右から左に向かう矢印（←）は、ＭＨＬシンク機器からＭＨＬソース機器の方向に伝送されるＭＨＬパケットであることを示すものとする。また、各ＭＨＬパケット内の３ビット「３ｂ´ｈｈｃ」の「ｈｈ」はＭＨＬパケットの２ビットのＨｅａｄｅｒであり、「ｃ」はＣｏｎｔｒｏｌビットである。

まず、参照番号８０１、８０２で示すように、ＭＨＬソース機器がＭＨＬシンク機器に、フレーム開始を指示するコマンド（ＳＯＦ）と、セグメント・ポインターのＷｒｉｔｅポート・アドレス（０ｘ６０）を指定するデータを伝送する。これに対し、ＭＨＬシンク機器は、参照番号８０３で示すように、ＡＣＫ（受信ＯＫ）コマンドを返す。

次いで、ＭＨＬソース機器は、参照番号８０４で示すように、ＥＤＩＤのセグメント値（０〜１２７）を示すデータを伝送する。これに対し、ＭＨＬシンク機器は、参照番号８０５で示すように、ＡＣＫ（受信ＯＫ）コマンドを返す。

次いで、ＭＨＬソース機器は、参照番号８０６、８０７で示すように、フレーム開始を指示するコマンド（ＳＯＦ）と、ＥＤＩＤデバイスのアドレスとしてＲｅａｄポート・アドレス（０ｘＡ１）を指定するデータを伝送する（Ｗｒｉｔｅポート・アドレスは０ｘＡ０である）。これに対し、ＭＨＬシンク機器は、参照番号８０８で示すように、ＡＣＫ（受信ＯＫ）コマンドを返す。

次いで、ＭＨＬソース機器は、参照番号８０９で示すように、ＣＯＮＴ（指定セグメントの先頭読み出し要求）コマンドを伝送する。これに対し、ＭＨＬシンク機器は、参照番号８１０で示すように、セグメント先頭データを伝送し、その後ポインターを１だけインクリメントする。

そして、ＭＨＬソース機器からのＣＯＮＴ（指定セグメントの次の読み出し要求）コマンドの伝送と、ＭＨＬシンク機器からのセグメント先頭データの伝送及びポインターのインクリメントという手順が、必要な回数だけ繰り返される。

最後に、ＭＨＬソース機器は、参照番号８１１で示すように、ＳＴＯＰ（伝送終了）コマンドを伝送し、続いて参照番号８１２で示すように、ＥＯＦ（コマンド終了）コマンドを伝送して、ＥＤＩＤを読み出す手順を完了させる。

また、図示を省略するが、ＨＤＣＰ認証でＤＤＣコマンドを発行する場合、ポート・アドレス０ｘ７４（Ｗｒｉｔｅポート）と０ｘ７５（Ｒｅａｄポート）を使い、上記と同様の手順で行なう。

ＭＨＬデバイス（ＭＨＬソース機器並びにＭＨＬシンク機器を含む）内では複数のタスクが実行されている。そして、別々のタスクが非同期でＭＳＣコマンドやＤＤＣコマンドの伝送要求を行なうことが想定される。

図９には、ＭＨＬデバイス間でＭＨＬケーブルを介してコマンドを伝送する仕組みを模式的に示している。同図中、ＭＨＬデバイス９０１とＭＨＬデバイス９０２のうち一方はＭＨＬソース機器として動作し、他方はＭＨＬシンク機器として動作する。ＭＨＬデバイス９０１側では、コマンドの伝送を要求するｍ個の送信要求タスク（タスク１〜タスクｍ）と、受信コマンドの処理を行なうｎ個の受信処理タスク（タスクｍ＋１〜タスクｍ＋ｎ）が実行されている。また、ＭＨＬデバイス９０１は、伝送要求されたコマンドを書き込む送信バッファー９１１と、ＭＨＬデバイス９０２から受信したコマンドを書き込む受信バッファー９１２と、ＭＨＬケーブル９０３内に含まれるデータ・バスであるＣＢＵＳ若しくはｅＣＢＵＳを介してＭＨＬデバイス９０２側とコマンドの送受信を行なうトランスミッター／レシーバー９１３を備えている。ＣＢＵＳ若しくはｅＣＢＵＳを介したコマンドの送受信処理という観点からは、ＭＨＬデバイス９０２はＭＨＬデバイス９０１と同様の構成であるとする。

ｍ個の送信要求タスクは非同期にコマンドの伝送要求を行ない、各コマンドは要求された順に送信バッファー９１１にキューイングされる。送信要求バッファー９１１はいわゆる先入れ先出し（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ：ＦＩＦＯ）形式に構成されており、トランスミッター／レシーバー９１３は、キューイングされた順序を変えずにコマンドを取り出して、ＣＢＵＳ若しくはｅＣＢＵＳ経由でＭＨＬデバイス９０２に伝送する。

また、トランスミッター／レシーバー９１３は、ＣＢＵＳ若しくはｅＣＢＵＳ経由でＭＨＬデバイス９０２からコマンドを受信すると、受信した順に受信バッファー９１２に書き込む。受信バッファー９１２もＦＩＦＯ形式に構成されており、書き込まれた順で受信コマンドを対応する受信処理タスクに引き渡す。

図９に示した例では、ＭＨＬデバイス９０１とＭＨＬデバイス９０２の双方向で、すべてのコマンドを分け隔てなく（言い換えれば、優先順位なしに）取り扱っている。このような方式では、キューイングされたコマンドの中に緊急性を必要とするものが含まれている場合、トラフィック量が多い状況下では、規定時間内にコマンド処理を終了できないことがあり、これが原因となってＭＨＬデバイスの誤動作を招くおそれがある。

規定時間以内にコマンド処理が終了しない一例として、ＨＤＣＰ認証に失敗した場合について説明する。ＭＨＬのバージョン１及び２では、ＨＤＣＰバージョン１．４をサポートする。ＨＤＣＰは、伝送路の暗号化プロトコルを適用してコンテンツの不正コピーを防止する著作権保護技術の１つである。ＨＤＣＰ認証は、ステップ１、ステップ２、及びステップ３の３つのステップからなる。このうち、ステップ２はリピーター・デバイスに関する手順で、リピーター・デバイスを持たないＭＨＬでは必要ないので、ここではステップ１とステップ３についてだけ説明する。なお、ＨＤＣＰの手順のうち、応答時間に関する部分が本実施形態に関係するもので、それ以外の各パラメーターの意味や算出方法など直接関係しない部分については詳細な説明を省略する。

図１０には、ＨＤＣＰ認証手順のステップ１における処理シーケンスを模式的に示している。但し、左側のＨＤＣＰ Ｔｒａｎｓｎｉｔｔｅｒ［Ｄｅｖｉｃｅ−Ａ］はＭＨＬソース機器であり、右側のＨＤＣＰ Ｒｅｃｅｉｖｅｒ［Ｄｅｖｉｃｅ−Ｂ］はＭＨＬシンク機器である。ステップ１は、ＭＨＬケーブルで接続されているＭＨＬソース機器とＭＨＬシンク機器がアクティブ状態になり、ＭＨＬソース機器が著作権保護されたコンテンツを送ろうとする直前に行なう認証手順である。

まず、Ｄｅｖｉｃｅ−Ａは、参照番号１００１で示すように、６４ビットの疑似乱数値（Ａｎ）を生成すると、次いで、参照番号１００２で示すように、この疑似乱数値（Ａｎ）を自身の４０ビットの公開キー（Ａｋｓｖ）ととともにＤｅｖｉｃｅ−ＢにＤＤＣ Ｗｒｉｔｅコマンドを使って伝送する（Ｄｅｖｉｃｅ−ＢのＨＤＣＰポートに書き込む）ことによって、当該認証手順を開始する。

次いで、Ｄｅｖｉｃｅ−Ａは、参照場号１００３で示すように、Ｄｅｖｉｃｅ−Ｂの４０ビットの公開キー（Ｂｋｓｖ）とＲＥＰＥＡＴＥＲビットをＨＤＣＰポートからＤＤＣ Ｒｅａｄコマンドで読み出す。ここで、ＲＥＰＥＡＴＥＲビットはＭＨＬの場合必ず０（Ｒｅｐｅａｔｅｒではないから）となる。

また、Ｄｅｖｉｃｅ−Ｂは、Ｄｅｖｉｃｅ−Ａの疑似乱数値（Ａｎ）と公開キー（Ａｋｓｖ）を受信してから１００ミリ秒以内に、参照番号１００４で示すように、疑似乱数値（Ａｎ）と公開キー（Ａｋｓｖ）に基づいて１６ビットのＲ₀´を計算して（Ｒ₀´＝ｆ（Ａｎ，Ａｋｓｖ）とする）、参照番号１００５で示すように、ＨＤＣＰポートの該当エリアにセットする。

最後に、Ｄｅｖｉｃｅ−Ａは、疑似乱数値（Ａｎ）と自分の公開キー（Ａｋｓｖ）をＤｅｖｉｃｅ−Ｂに伝送してから少なくとも１００ミリ秒が経過した後に、参照番号１００６で示すように、Ｄｅｖｉｃｅ−ＢのＨＤＣＰポートからＲ₀´を読み出す。そして、Ｄｅｖｉｃｅ−Ａは、自身で疑似乱数値（Ａｎ）と公開キー（Ａｋｓｖ）に基づいて計算した１６ビットのＲ₀を読み出したＲ₀´と比較し、両者が等しい場合（Ｒ₀＝Ｒ₀´）は、ステップ１が成功したと判断して、ステップ３に進む。

また、図１１には、ＨＤＣＰ認証手順のステップ３における処理シーケンスを模式的に示している。但し、左側のＨＤＣＰ Ｔｒａｎｓｎｉｔｔｅｒ［Ｄｅｖｉｃｅ−Ａ］はＭＨＬソース機器であり、右側のＨＤＣＰ Ｒｅｃｅｉｖｅｒ［Ｄｅｖｉｃｅ−Ｂ］はＭＨＬシンク機器である（同上）。

ステップ３の認証は、２秒後又は１２８フレーム後のＶ−ブランキング期間中に毎回行なう。図１１では、１２８フレーム毎に認証を行なう例を示している。図１２には、ＭＨＬで伝送するビデオ信号の１フレーム当りの構成を示している。各フレームは、ビデオ画像に相当するビデオ・データと、ビデオ・データを持たない２つの空白期間、すなわちＶ−ブランキングとＨ−ブランキングの３つの領域からなる。例えば、図１２中で示す各数値は、１９２０×１０８０画素の、６０Ｈｚのビデオ・フォーマットの場合を示し、１秒間にこれを６０回繰り返す。また、各ビデオ・データ間のＶ−ブランキングは４５ラインであり、これはおよそ６６７マイクロ秒に相当する。その計算式は下式（１）の通りである。

図１１に示す処理シーケンスにおいて、ｉはフレーム・カウンターであり、ビデオ信号を１フレーム送受信する毎に１ずつ加算される。Ｄｅｖｉｃｅ−Ａは、参照番号１１０１で示すように、１２８フレーム毎に、関数ｈｄｃｐｂｌｋＣｉｐｈｅｒを用いて認証の完全性を示すパラメーターＲ_iを計算する。同様に、Ｄｅｖｉｃｅ−Ｂは、参照番号１１０２で示すように、１２８フレーム毎にパラメーターＲ_i´を計算する。

次いで、Ｄｅｖｉｃｅ−Ａは、参照番号１１０３で示すように、ｉが１２８の倍数（ｉ ｍｏｄ １２８＝＝０）になるＶ−ブランキング内で、Ｄｅｖｉｃｅ−ＢからＲ_i´を読み出す。そして、参照番号１１０４で示すように、Ｄｅｖｉｃｅ−Ａは、１ミリ秒以内に自身で計算したパラメーターＲ_iを、Ｄｅｖｉｃｅ−Ｂから読み出したパラメーターＲ_i´と比較し終えなければならない。両パラメーターの値が一致すれば（Ｒ_i＝Ｒ_i´）、認証に成功したものとして、Ｄｅｖｉｃｅ−Ａは次のビデオ・データを引き続きＨＤＣＰ暗号化して伝送を継続する。一方、以下の２つのケース（１）又は（２）の場合には、Ｄｅｖｉｃｅ−Ａは認証に失敗したと判断する。

（１）Ｒ_i≠Ｒ_i´のとき
（２）ＤＤＣ ＲｅａｄコマンドでＲ_i´読み出しを開始してから１ミリ秒以内に動作を完了できなかったとき

認証に失敗すると、Ｄｅｖｉｃｅ−Ａは、一端Ｄｅｖｉｃｅ−Ｂを未認証と見なして、ステップ１（図１０を参照のこと）からやり直す。このとき、Ｄｅｖｉｃｅ−Ｂ（ＭＨＬシンク機器）の画像と音声は、ＨＤＣＰの認証が完了するまでの間、ミューティング状態になる。

図９に示したコマンド伝送方式では、ＣＢＵＳ若しくはｅＣＢＵＳ上を伝送するコマンドはすべて均等に扱われ、受信バッファーに入力された順番に取り出されて処理される。例えば、送信要求が輻輳して送信バッファーに大量の送信待ちコマンドがキューイングされている場合や、受信バッファーに大量の処理待ちコマンドがキューイングされている場合に、ＨＤＣＰ認証手順のステップ３（図１１を参照のこと）を実施する場合について考察してみる。

Ｄｅｖｉｃｅ−Ａは、参照番号１１０３で示す、パラメーターＲ_i´の読み出しには、ＤＤＣ Ｓｈｏｒｔ Ｒｅａｄコマンドを使う。図１３には、ＤＤＣ Ｓｈｏｒｔ Ｒｅａｄコマンドのフォーマットを示している。パケットの表記方法などは図８と同様である。

まず、参照番号１３０１、１３０２で示すように、Ｄｅｖｉｃｅ−Ａは、フレーム開始を指示するコマンド（ＳＯＦ）と、ＨＤＣＰポート・アドレス（０ｘ７５）を指定するデータを伝送する。これに対し、Ｄｅｖｉｃｅ−Ｂは、参照番号１３０３で示すように、ＡＣＫ（受信ＯＫ）コマンドを返す。

次いで、Ｄｅｖｉｃｅ−Ａは、参照番号１３０４で示すように、ＣＯＮＴ（指定セグメントの先頭読み出し要求）コマンドを伝送する。これに対し、Ｄｅｖｉｃｅ−Ｂは、参照番号１３０５で示すように、セグメント先頭データを伝送し、その後ポインターを１だけインクリメントする。

そして、Ｄｅｖｉｃｅ−ＡからのＣＯＮＴ（指定セグメントの次の読み出し要求）コマンドの伝送と、Ｄｅｖｉｃｅ−Ｂからのセグメント先頭データの伝送及びポインターのインクリメントという手順が必要な回数だけ繰り返されるここで、パラメーターＲ_i´は１６ビット長なので、Ｄｅｖｉｃｅ−Ａは、２回データを読み出し（すなわち、ｎ＝２）、最後に、参照番号１３０６、１３０７で示すようにＳＴＯＰ及びＥＯＦを伝送して、パラメーターＲ_i´の読み出しの処理を終える。

図１１を参照しながら説明したように、図１３に示すＤＤＣ Ｓｈｏｒｔ Ｒｅａｄコマンドは１ミリ秒以内に完了しなければならない。具体的には、図１１において、参照番号１１０３で示す処理を実行するタスク（仮に、タスクＡとする）が、ＤＤＣ Ｓｈｏｒｔ Ｒｅａｄコマンドの先頭データ「ＳＯＦ」の送信要求出すと同時に、１ミリ秒タイマーをスタートする。そして、タイムアウトする前に最後の「ＥＯＦ」送信要求を出さなければならない。ここで、タスクＡが「ＳＯＦ」の送信要求を出したときに、たまたまトラフィック量が高く、Ｄｅｖｉｃｅ−ＡとＤｅｖｉｃｅ−Ｂの送信／受信バッファーに処理前のコマンドが貯まっている場合、その分、ＤＤＣ Ｓｈｏｒｔ Ｒｅａｄコマンドの完了に時間がかかってしまう。また、途中で伝送エラーが発生すると、ＭＨＬパケットの再送を行なわなければならず、さらに時間がかかる。このような条件が重なると、ＤＤＣ Ｓｈｏｒｔ Ｒｅａｄコマンドの実行時間が１ミリ秒を超えてしまい、その結果、認証に失敗する可能性がある。

また、規定時間以内にコマンド処理が終了しない他の例として、機器連携操作を行なう場合を挙げることができる。ＭＨＬ規格では、機器連携操作を可能にするリモート・コマンド・パススルー（ＲＣＰ）機能が用意されている。図１４に示すように、スマートフォンなどのＭＨＬソース機器１４０１とＴＶ受信機などのＭＨＬシンク機器１４０２がＭＨＬケーブル１４０３で接続されているとき、ユーザーは、リモコン１４０４を用いてＭＨＬソース機器１４０１を操作することができる。ＭＨＬシンク機器１４０２からＭＨＬソース機器１４０１へのリモート・コマンドの通信には、ＣＢＵＳ若しくはｅＣＢＵＳが使用される。１４０４リモコンのキーが押下されると、対応するリモコン・キーがＭＨＬシンク機器１４０２からＭＨＬソース機器１４０１に、ＭＳＣコマンドを使って伝送される。これによって、ＭＨＬソース機器１４０１が持つ動画や写真などのコンテンツをＭＨＬシンク機器１４０２で再生しながら、リモコン１４０４でＰｌａｙ、Ｓｔｏｐ、Ｆｏｒｗａｒｄ、Ｂａｃｋｗａｒｄなどの表示制御を行なうことができる。

リモコン１４０４上でリモコン・キーが押下されると、ＭＨＬシンク機器１４０２にリモコン・コマンドが送信され、ＭＨＬシンク機器１４０２は、ＲＣＰサブコマンドでＭＨＬケーブル１４０３に伝送する。図１５には、ＲＣＰサブコマンドのフォーマットを示している。例えば、ＲＣＰサブコマンドでキーコードとしてＰｌａｙ（０ｘ４４）をＭＨＬソース機器１４０１に伝送すると、ＭＨＬソース機器１４０１は、コンテンツの再生を開始し、ＭＨＬケーブル１４０３内のＴＭＤＳチャネルで非圧縮映像を伝送し、ＭＨＬシンク機器１４０２はこれを受信して表示する。また、画面を一時停止させたい場合には、Ｐａｕｓｅ（０ｘ４６）を、早送りしたい場合には、Ｆｏｒｗａｒｄ（０ｘ４Ｂ）を、ＲＣＰサブコマンドでＭＨＬソース機器１４０１に伝送する。

リモート・コマンド・パススルー機能を実行する際に、たまたまトラフィック量が高く、ＭＨＬシンク機器１４０２又はＭＨＬソース機器１４０１の送信／受信バッファーに処理前のコマンドが貯まっている場合、その分、ＲＣＰサブコマンドの処理に時間がかかってしまう。また、途中で伝送エラーが発生すると、ＭＨＬパケットの再送を行なわなければならず、さらに時間がかかる。その結果、ユーザーがリモコン・キーを押してから画面が反応するまでに大きなタイムラグが発生する可能性がある。

以上で、ＨＤＣＰバージョン１．４の認証とリモート・コマンド・パススルーで発生する問題点を指摘した。ＭＨＬのバージョン３では、ＨＤＣＰ１．４よりも認証手順が複雑なＨＤＣＰバージョン２．２をサポートしていたり、ｅＣＢＵＳ上で音声やＵＳＢをトンネリングする機能を追加したりするなど、トラフィック量は増大傾向にある。また、さらに将来のＭＨＬで優先処理が必要な機能が追加される可能性を考えると、すべてのＭＨＬパケットを同列に扱うには限界が有り、必要に応じて優先的にパケットを伝送する機能が必要であると思料される。

そこで、ＭＨＬケーブルで接続されたＭＨＬデバイス間で双方向データ・バス（ＣＢＵＳ）を経由してデータ伝送を行なう際に、コマンドに優先度を付けて、送受信するコマンドを優先度に応じて管理できるようにする。具体的には、コマンドの送信処理の際には、伝送待ちのコマンドが存在する場合でも、優先順位の高いコマンドからＣＢＵＳ上に伝送するようにして、伝送遅延に起因する問題を解消することができる。また、受信処理の際にも、優先度の高いコマンドから受信処理を行なうことができ、規定時間内にコマンド処理を終了させることができるようになる。

図１６及び図１７には、優先順位の情報を付加したＭＨＬパケットの構成例を示している。図１６は、図５に示したＣＢＵＳモード時のＭＨＬパケットのＣｏｎｔｒｏｌビットの後ろに、３ビットのＰｒｉｏｒｉｔｙフィールドを追加した例を示している。また、図１７には、図６に示したｅＣＢＵＳ−Ｓ及びｅＣＢＵＳ−Ｄモード時のＭＨＬパケットのＣｏｎｔｒｏｌビットの後ろに、３ビットのＰｒｉｏｒｉｔｙフィールドを追加した例を示している。また、表１３には、Ｐｒｉｏｒｉｔｙフィールド値と処理優先度の関係を示している。Ｐｒｉｏｒｉｔｙフィールド値の０ｂ０００の優先度が最も低く、値が１だけ増加する毎に優先度は高くなり、０ｂ１１１の優先度が最も高い。なお、Ｐｒｉｏｒｉｔｙフィールドのビット長３は一例に過ぎず、２ビット以下又は４ビット以上で優先度を表現してもよい。以下ではＰｒｉｏｒｉｔｙフィールドが３ビット長に統一して説明する。

図１８には、ＭＨＬデバイス間でＭＨＬケーブルを介して優先順位を考慮してコマンドを伝送する仕組みを模式的に示している。図９に示したシステムとは相違し、３ビットのＰｒｉｏｒｉｔｙフィールドを持つＭＨＬパケット（図１６又は図１７を参照のこと）がＭＨＬケーブルに伝送されるものとする。

図１８中、ＭＨＬデバイス１８０１とＭＨＬデバイス１８０２のうち一方はＭＨＬソース機器として動作し、他方はＭＨＬシンク機器として動作する。ＭＨＬデバイス１８０１側では、コマンドの伝送を要求するｍ個の送信要求タスク（タスク１〜タスクｍ）と、受信コマンドの処理を行なうｎ個の受信処理タスク（タスクｍ＋１〜タスクｍ＋ｎ）が実行されている。

ＭＨＬデバイス１８０１は、伝送要求されたコマンドを優先順位別に書き込む８種類の送信バッファーからなる送信バッファー群１８１１と、ＭＨＬデバイス１８０２から受信したコマンドを優先順位別に書き込む８種類の受信バッファーからなる受信バッファー群１８１２と、ＭＨＬケーブル１８０３内に含まれるデータ・バスであるＣＢＵＳ若しくはｅＣＢＵＳを介してＭＨＬデバイス１８０２側とコマンドの送受信を行なうトランスミッター／レシーバー１８１３を備えている。また、ＭＨＬデバイス１８０１は、送信コマンドの優先度を管理するために振分け処理部１８１４及び取出し処理部１８１５と、受信コマンドの優先度を管理するための振分け処理部１８１６及び取出し処理部１８１７をさらに備えている。送信バッファー群１８１１及び受信バッファー群１８１２に含まれる各バッファーはそれぞれＦＩＦＯ形式で構成されるが、振分け処理部１８１４及び取出し処理部１８１５、振分け処理部１８１６及び取出し処理部１８１７によって書き込み及び取出しの優先度が管理される。なお、ＣＢＵＳ若しくはｅＣＢＵＳを介したコマンドの送受信処理という観点からは、ＭＨＬデバイス１８０２はＭＨＬデバイス１８０１と同様の構成であるとする。

まず、ＭＨＬデバイス１８０１における優先度に応じたコマンドの送信処理について説明する。

ｍ個の送信要求タスクは非同期にコマンドの伝送要求を行なうが、ＭＨＬパケットのＰｒｉｏｒｉｔｙフィールドに示すＰｒｉｏｒｉｔｙ値（表１３を参照のこと）のうち、希望する値をセットした後、振分け処理部１８１４に送信要求する。そして、振分け処理部１８１４は、送信バッファー群１８１１のうち、タスクが希望するＰｒｉｏｒｉｔｙ値に対応する送信バッファーにコマンドを書き込む。

取出し処理部１８１５は、送信バッファー群１８１１に含まれる８種類の送信バッファーを、優先度の高い順（０ｂ１１１、０ｂ１１０、０ｂ１０１、０ｂ１００、０ｂ０１１、０ｂ０１０、０ｂ００１、０ｂ０００の順）にスキャンする。そして、取出し処理部１８１５は、送信待機中のＭＨＬパケットをスキャンしている送信バッファー中に見つけたら、１コマンド分のパケットをトランスミッター／レシーバー１８１３に引き渡す。

図１９には、ＭＳＣコマンド、及びＤＤＣコマンドのフォーマットを示している。図１９（Ａ）に示すように、Ｃｏｎｔｒｏｌコードの１バイトだけから構成されるコマンドと、図１９（Ｂ）に示すように、Ｃｏｎｔｒｏｌコードに加え、それに付随する１バイト以上のデータから構成されるコマンドがある。また、後者の１バイト以上のデータが付随するコマンドは、Ｃｏｎｔｒｏｌコードの種類により固定長のデータを持つ場合と、可変長のデータを持つ場合がある。可変長のデータが付随する場合、図１９（Ｂ）に示すように、最後にＥＯＦ（０ｘ３２）が付加されることで、コマンドの最後を識別することができる。ＣｏｎｔｒｏｌコードとＤａｔａのいずれであるか、ＭＨＬパケットのＣｏｎｔｒｏｌビットで区別ことができる（表９並びに図７に示したように、Ｃｏｎｔｒｏｌビットが１であればＣｏｎｔｒｏｌコードであり、Ｃｏｎｔｒｏｌビットが０であればＤａｔａである）。

取出し処理部１８１５は、図１９に示すコマンド・フォーマットを判別し、コマンドの先頭（Ｃｏｎｔｒｏｌビット＝１）から終わりまでをＣｏｎｔｒｏｌコードの種類から判断し、先頭から終わりまで１コマンド分を送信バッファーから取り出してトランスミッター／レシーバー１８１３に引き渡す。また、同じ優先度の送信バッファーに次のコマンドが書き込まれていても、取出し処理部１８１５は、読み込まないで残しておく（次のコマンドは、次のスキャン時に取出し処理する）。

取出し処理部１８１５は、上述したような優先度に応じた送信バッファー群１８１１のスキャンと送信バッファーからのコマンドの取出しを行なうことで、常に優先度の高いコマンドからトランスミッター／レシーバー１８１３に引き渡すことができる。

続いて、ＭＨＬデバイス１８０１における優先度に応じたコマンドの受信処理について説明する。

振分け処理部１８１６は、トランスミッター／レシーバー１８１３で受信したＭＨＬパケットに対し、図１９で示すコマンド・フォーマットを判別して、コマンドの先頭から最後までの１コマンド分のパケットを、受信バッファー群１８１２のうち、Ｐｒｉｏｒｉｔｙフィールドで示す優先順位に対応する受信バッファーに書き込む。

取出し処理部１８１７は、受信バッファー群１８１２に含まれる８種類の受信バッファーを、優先度の高い順（０ｂ１１１、０ｂ１１０、０ｂ１０１、０ｂ１００、０ｂ０１１、０ｂ０１０、０ｂ００１、０ｂ０００の順）にスキャンする。そして、取出し処理部１８１７は、処理待機中のＭＨＬパケットを受信バッファー中に見つけたら、図１９で示す１コマンド分のパケットを対応するコマンド処理を行なうタスクに引き渡す。また、優先度の同じ受信バッファーに次のコマンドが書き込まれていても、取出し処理部１８１７は、読み込まないで残しておく（次のコマンドは、次のスキャン時に取出し処理する）。

表１３には、８種類のＰｒｉｏｒｉｔｙ値に対して８段階の優先度を与える例を示したが、上述したような優先度に基づくコマンドの管理を実現するために、８段階に限定されない。例えば、異なる段階数の優先度を幾つか用意して、伝送環境などの条件によって優先度の段階数をダイナミックに切り替えてシステムを運用するようにしてもよい。表１４には、８種類のＰｒｉｏｒｉｔｙ値に対して異なる段階の優先度を与える例を示している。表１４の左側のテーブルは優先度の高い順にＨｉｇｈ＞Ｍｉｄｄｌｅ−Ｈｉｇｈ＞Ｍｉｄｄｌｅ＞Ｍｉｄｄｌｅ−Ｌｏｗ＞Ｌｏｗの５段階の優先度を用意し、真ん中のテーブルはＨｉｇｈ＞Ｍｉｄｄｌｅ＞Ｌｏｗの３段階の優先度を用意し、右側のテーブルはＨｉｇｈ＞Ｌｏｗの２段階の優先度を用意している。

基本的には、ＣＢＵＳ若しくはｅＣＢＵＳのトラフィック量が大きいほど優先度の段階数を多くし、トラフィック量が小さくなると優先度の段階数を少なくしてもよいと思料される。表１４に示したテーブルの使い分けの例を以下に挙げておく。

（１）トンネリング機能を使用していないときは、２段階テーブルを使用する。
（２）Ａｕｄｉｏ／ＵＳＢ１／ＨＩＤのうち、１つのトンネリング中は３段階テーブル又は５段階テーブルを使用する。
（３）２つ以上トンネリングしている場合は８段階テーブルを使用する。

また、図１６や図１７に示したようなＭＨＬパケットにＰｒｉｏｒｉｔｙフィールドを設定する方法に代えて、あらかじめＭＳＣコマンド並びにＤＤＣコマンドのタイプ別に優先度を決めておく方法もある。コマンドを伝送する際には、図５や図６に示した現状のＭＨＬパケットのフォーマットのままで伝送要求する。振分け処理部１８１４は、各コマンド・タイプの優先度をあらかじめ把握しており、伝送要求されたコマンドのコマンド・タイプを参照しながら、送信バッファー群１８１１のうち該当する優先度の送信バッファーに書き込みを行なう。また、取出し処理部１８１５や、振分け処理部１８１６並びに取出し処理部１８１７においても、コマンド・タイプごとの優先度に従って処理を行なう。コマンド・タイプ別に優先度を決めておく方法によれば、ＭＨＬパケットにＰｒｉｏｒｉｔｙフィールドを設定する必要がないので、コマンドの伝送効率が向上するという利点がある。また、上述したように、伝送環境（例えば、トラフィック量）などの条件によって各コマンド・タイプの優先度をダイナミックに切り替えるようにしてもよい。

本実施形態によれば、ＭＨＬ規格に則った通信システムにおいて、送受信するコマンドを優先度に応じて管理することによって、ＨＤＣＰ認証失敗問題や、リモート・コマンド・パススルーのレスポンスが遅くなる問題を改善することができる。さらに、ＭＨＬにおける将来のバージョンで時間制約のあるコマンドや機能が追加された場合でも、ＣＢＵＳバス若しくはｅＣＢＵＳバスのトラフィック量に応じて優先度に基づくコマンドの送受信処理を実施することで、遅延の問題を解消することができる。

以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本明細書では、ＭＨＬをベースにした通信インターフェースで機器同士が接続される通信システムに本明細書で開示する技術を適用した実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。映像伝送用のチャネルと双方向データ・バスを有するさまざまな通信インターフェース規格に基づく通信システムに、同様に本明細書で開示する技術を適用することができる。

要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）少なくとも音声・映像伝送用のチャネルと双方向データ・バスを含み、所定の通信インターフェース規格に則った伝送ケーブルで通信相手と接続される通信装置であって、
コマンドの処理の優先度を管理する優先度管理部と、
前記双方向データ・バスを経由して前記通信相手とコマンドの送受信を処理する送受信部と、
を具備する通信装置。
（２）前記優先度管理部は、タスクから非同期で伝送要求されるコマンドを送信する優先度を管理する、
上記（１）に記載の通信装置。
（３）前記優先度管理部は、受信したコマンドを受信処理するタスクにコマンドを引き渡す優先度を管理する、
上記（１）に記載の通信装置。
（４）前記優先度管理部は、優先順位別の複数種類の送信バッファーと、伝送要求するタスクが希望する優先度に対応した送信バッファーにコマンドを書き込む振分け処理部と、優先度の順に各送信バッファーからコマンドを取り出して前記送受信部に引き渡す処理取出し部を備える、
上記（２）に記載の通信装置。
（５）データ長が異なる複数のコマンド・フォーマットが規定されており、
前記取出し処理部は、コマンド・フォーマットに応じて１コマンド分ずつ送信バッファーから取り出して前記送受信部に引き渡す、
上記（４）に記載の通信装置。
（６）前記優先度管理部は、優先順位別の複数種類の受信バッファーと、前記送受信部が受信したパケットを優先度に対応した受信バッファーにコマンドを書き込む振分け処理部と、優先度の順に各受信バッファーからパケットを取り出して対応するコマンドの処理を行なうタスクに引き渡す処理取出し部を備える、
上記（３）に記載の通信装置。
（７）データ長が異なる複数のコマンド・フォーマットが規定されており、
前記振分け処理部は、コマンド・フォーマットに応じて１コマンド分のパケットを優先度に対応する受信バッファーに書き込み、
前記取出し処理部は、１コマンド分のパケットを受信バッファーから取り出して対応するタスクに引き渡す、
上記（６）に記載の通信装置。
（８）前記優先度管理部は、条件に応じて優先度の段階数を切り換える、
上記（１）に記載の通信装置。
（９）前記優先度管理部は、前記双方向データ・バスのトラフィック量に応じて優先度の段階数を切り換える、
上記（１）に記載の通信装置。
（１０）前記双方向データ・バス上で伝送するパケットに優先度を示す優先度フィールドを設定し、
前記優先度管理部は、前記優先度フィールドに設定された値に基づいて、パケットで伝送するコマンドの処理の優先度を管理する、
上記（１）に記載の通信装置。
（１１）前記優先度管理部は、コマンドのタイプに応じて、コマンドの処理の優先度を管理する、
上記（１）に記載の通信装置。
（１２）前記優先度管理部は、条件に応じてコマンド・タイプ毎の優先度を切り換える、
上記（１１）に記載の通信装置。
（１３）前記通信インターフェース規格はＭＨＬ規格である、
上記（１）に記載の通信装置。
（１４）所定の通信インターフェース規格に則った伝送ケーブルに含まれる音声・映像伝送用のチャネルで音声・映像信号を伝送するステップと、
伝送要求されたコマンドを優先度に応じて前記伝送ケーブルに含まれる双方向データ・バスに送信するステップと、
前記双方向データ・バス経由で受信したコマンドを優先度に応じて処理するステップと、
を有する通信方法。

１…通信システム
１０…ＭＨＬソース機器、１１…ＭＨＬ送信部
２０…ＭＨＬシンク機器、２１…ＭＨＬ受信部
３０…ＭＨＬケーブル、３１…ＴＭＤＳチャネル
３２…ＣＢＵＳ、３３…ＶＢＵＳ
２００…ＭＨＬケーブル、２０１…Ｍｉｃｒｏ−Ｂプラグ
２０２…ＨＤＭＩ（登録商標） Ｔｙｐｅ−Ａプラグ
９０１、９０２…ＭＨＬデバイス、９０３…ＭＨＬケーブル
９１１…送信バッファー、９１２…受信バッファー
９１３…トランスミッター／レシーバー
１４０１…ＭＨＬソース機器、１４０２…ＭＨＬシンク機器
１０４３…ＭＨＬケーブル、１４０４…リモコン
１８０１、１８０２…ＭＨＬデバイス、１８０３…ＭＨＬケーブル
１８１１…送信バッファー群、１８１２…受信バッファー群
１８１３…トランスミッター／レシーバー
１８１４…振分け処理部、１８１５…取出し処理部
１８１６…振分け処理部、１８１７…取出し処理部

Claims (14)

1. 少なくとも音声・映像伝送用のチャネルと双方向データ・バスを含み、所定の通信インターフェース規格に則った伝送ケーブルで通信相手と接続される通信装置であって、
   コマンドの処理の優先度を管理する優先度管理部と、
   前記双方向データ・バスを経由して前記通信相手とコマンドの送受信を処理する送受信部と、
   を具備する通信装置。
2. 前記優先度管理部は、タスクから非同期で伝送要求されるコマンドを送信する優先度を管理する、
   請求項１に記載の通信装置。
3. 前記優先度管理部は、受信したコマンドを受信処理するタスクにコマンドを引き渡す優先度を管理する、
   請求項１に記載の通信装置。
4. 前記優先度管理部は、優先順位別の複数種類の送信バッファーと、伝送要求するタスクが希望する優先度に対応した送信バッファーにコマンドを書き込む振分け処理部と、優先度の順に各送信バッファーからコマンドを取り出して前記送受信部に引き渡す処理取出し部を備える、
   請求項２に記載の通信装置。
5. データ長が異なる複数のコマンド・フォーマットが規定されており、
   前記取出し処理部は、コマンド・フォーマットに応じて１コマンド分ずつ送信バッファーから取り出して前記送受信部に引き渡す、
   請求項４に記載の通信装置。
6. 前記優先度管理部は、優先順位別の複数種類の受信バッファーと、前記送受信部が受信したパケットを優先度に対応した受信バッファーにコマンドを書き込む振分け処理部と、優先度の順に各受信バッファーからパケットを取り出して対応するコマンドの処理を行なうタスクに引き渡す処理取出し部を備える、
   請求項３に記載の通信装置。
7. データ長が異なる複数のコマンド・フォーマットが規定されており、
   前記振分け処理部は、コマンド・フォーマットに応じて１コマンド分のパケットを優先度に対応する受信バッファーに書き込み、
   前記取出し処理部は、１コマンド分のパケットを受信バッファーから取り出して対応するタスクに引き渡す、
   請求項６に記載の通信装置。
8. 前記優先度管理部は、条件に応じて優先度の段階数を切り換える、
   請求項１に記載の通信装置。
9. 前記優先度管理部は、前記双方向データ・バスのトラフィック量に応じて優先度の段階数を切り換える、
   請求項１に記載の通信装置。
10. 前記双方向データ・バス上で伝送するパケットに優先度を示す優先度フィールドを設定し、
    前記優先度管理部は、前記優先度フィールドに設定された値に基づいて、パケットで伝送するコマンドの処理の優先度を管理する、
    請求項１に記載の通信装置。
11. 前記優先度管理部は、コマンドのタイプに応じて、コマンドの処理の優先度を管理する、
    請求項１に記載の通信装置。
12. 前記優先度管理部は、条件に応じてコマンド・タイプ毎の優先度を切り換える、
    請求項１１に記載の通信装置。
13. 前記通信インターフェース規格はＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）規格である、
    請求項１に記載の通信装置。
14. 所定の通信インターフェース規格に則った伝送ケーブルに含まれる音声・映像伝送用のチャネルで音声・映像信号を伝送するステップと、
    伝送要求されたコマンドを優先度に応じて前記伝送ケーブルに含まれる双方向データ・バスに送信するステップと、
    前記双方向データ・バス経由で受信したコマンドを優先度に応じて処理するステップと、
    を有する通信方法。