JP2007528681A - 高データレートインタフェース装置及び方法 - Google Patents

高データレートインタフェース装置及び方法 Download PDF

Info

Publication number
JP2007528681A
JP2007528681A JP2007503036A JP2007503036A JP2007528681A JP 2007528681 A JP2007528681 A JP 2007528681A JP 2007503036 A JP2007503036 A JP 2007503036A JP 2007503036 A JP2007503036 A JP 2007503036A JP 2007528681 A JP2007528681 A JP 2007528681A
Authority
JP
Japan
Prior art keywords
packet
data
client
host
field
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.)
Pending
Application number
JP2007503036A
Other languages
English (en)
Other versions
JP2007528681A5 (ja
Inventor
アンダーソン、ジョン・ジェームズ
スティール、ブライアン
ウィレイ、ジョージ・エー．
シェカー、シャシャンク
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2007528681A publication Critical patent/JP2007528681A/ja
Publication of JP2007528681A5 publication Critical patent/JP2007528681A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/724094—Interfacing with a device worn on the user's body to provide access to telephonic functionalities, e.g. accepting a call, reading or composing a message
    • H04M1/724097—Worn on the head
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Abstract

【課題】高データレートインタフェース装置及び方法。
【解決手段】事前に選択された１セットのデジタル制御データとデジタルプレゼンテーションデータを通信するための通信プロトコルを形成するために、共にリンクされるパケット構造を使用して、通信経路上で、ホストとクライアントとの間でデジタルデータを転送するためのデータインタフェース。通信プロトコルを形成するパケットを生成、送信、及び受信するように、そして、デジタルデータを１つ又は複数のタイプのデータパケットに形成するように、構成され、少なくとも１つがホスト装置に常駐しそして通信経路を通してクライアントに結合されている、リンクコントローラによって、信号プロトコルは使用される。インタフェースは、短距離「シリアル」タイプデータリンク上で、コスト効率のよい、低電力の、双方向の、高速データ転送機構を提供し、それは、ポータブルコンピュータや無線通信装置のためのウェアラブルマイクロディスプレイのようなディスプレイエレメントを接続する際に特に有用な小型コネクタ及び薄い可撓ケーブルを備えたインプリメンテーションに適している。
【選択図】 図５

Description

（米国特許法１１９条のもとでの優先権の主張）
本特許出願は、本譲受人に委譲され、参照してここに明示的に組み込まれる、２００４年３月１０日に出願された「切り替え可能閾値差動インタフェース（Ｓｗｉｔｈｃｈａｂｌｅ Ｔｈｒｅｓｈｏｌｄ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｉｎｔｅｒｆａｃｅ）」と題される米国特許仮出願第６０／５５２，１７６号、及び、２００４年３月１７日に出願された「切り替え可能閾値差動インタフェース（Ｓｗｉｔｈｃｈａｂｌｅ Ｔｈｒｅｓｈｏｌｄ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｉｎｔｅｒｆａｃｅ）」と題される米国特許仮出願第６０／５５４，３０９号、に対する優先権を主張する。
（分野）
本開示の中の本発明の実施形態は、ホスト装置とクライアント装置との間において高データレート（at high data rates）で信号を通信する或いは転送するための、デジタル信号プロトコル、プロセス、そして、集積回路及びコンポーネントを含む装置に関する。より具体的には、本開示は、内蔵装置アプリケーション及び外部装置アプリケーションを有する低電力高データレート転送機構を使用して、エンドユーザに対するプレゼンテーション又はディスプレイの(presentation or display)ためにホスト又はコントローラ装置からクライアント装置にマルチメディア及び他の種類のデジタル信号を転送する技術に関する。
コンピュータ、電子ゲーム関連製品及び多様なビデオ技術（例えばＤＶＤ及び高解像度ＶＣＲ）は、ますますより高解像度化する静止画像、ビデオ画像、ビデオオンデマンド画像、及びグラフィック画像のプレゼンテーションを、いくつかの種類のテキストを含む場合でさえも、このような装置のエンドユーザに提供するために、過去数年間に著しく進歩した。これらの進歩は、結果として、高解像度ビデオモニタ、ＨＤＴＶモニタ、又は特殊画像投影エレメントのような、より高解像度の電子ディスプレイ装置の使用を必要とした。ＣＤ型音響再生、ＤＶＤ、サラウンドサウンド、及び音声信号出力に関連する他の装置を使用する時のように、このような視覚映像を高解像度又は高品質音声データと組み合わせることが、エンドユーザに対してよりリアル感がありコンテンツリッチな或いは真のマルチメディア経験を作り出すために、使用される。更に、ＭＰ３プレーヤのような、移動性の高い、高品質サウンドシステム及びミュージックトランスポート機構が、エンドユーザへの音声専用プレゼンテーションのために開発されてきた。これは、コンピュータからテレビそして電話さえまでの、商業用電子機器の典型的なユーザの期待を高める結果となり、今では、高い或いはプレミアムな品質の出力に慣れ、期待している。
電子製品を必要とする典型的なビデオプレゼンテーションシナリオでは、ビデオデータは通常、毎秒約１キロビットから１０キロビットであって、遅い又は中ぐらいと最もよく呼ばれることが出来るであろうレートで現在の技術を使用して転送される。このデータはこのあと、所望されるディスプレイ装置上での遅れた（後の）再生のためにバッファに入れられるか、或いは、一時的な又は長期の記憶装置に記憶される。例えば、画像は、画像をデジタルで表すのに有効なデータを受信又は送信するために、モデム又は他のタイプのインターネット接続装置を有するコンピュータに常駐するプログラムを使用するインターネットを使用して又は「全体にわたって(across)」転送されてよい。類似する転送は、無線モデム又は無線パーソナルデータアシスタント（ＰＤＡ）又は無線電話を備えるポータブルコンピュータなどの無線装置を使用して行われることができる。
いったん受信されると、データは、プレイバックのために、小型ハードドライブのような内蔵又は外部の記憶装置を含む、ＲＡＭ又はフラッシュメモリのような、メモリエレメント、回路又は装置の中でローカルに記憶される。データ量と画像解像度に応じて、プレイバックは、相対的に迅速に開始するか、或いは、より長期間の遅延を伴って示される可能性がある。すなわち、いくつかの例では、画像プレゼンテーションは、多くのデータを必要としない、或いは何らかのタイプのバッファリングを使用する非常に小さい又は低い解像度の画像に対し、ある程度のリアルタイムプレイバックを可能にするので、少し遅延した後に、より多くのデータ(material)が転送されている間にいくらかのデータ(material)が提示される。転送リンクにおいて中断がない、或いは、使用されている転送チャネルに関して他のシステム又はユーザからの干渉がないならば、いったんプレゼンテーションが開始すると、転送は、ディスプレイ装置のエンドユーザに適度にトラスペアレントである。必然的に、結線されたインターネット接続のような単一の通信経路を複数のユーザが共用する場合は、転送は中断される或いは所望されるよりも遅くなる可能性がある。
静止画像又は動画ビデオのどちらかを作成するために使用されるデータは、通信リンク上でのデータの転送を加速するために、多くの場合、ジェイペグ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）（ＪＰＥＧ）、エムペグ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）（ＭＰＥＧ）、及び、メディア業界、コンピュータ業界、及び通信業界における周知の標準規格組織又は企業によって指定される技術のような、いくつかの周知の技術の１つを使用して圧縮される。これにより、既定量の情報を転送するために、より少ない数のビットを使用して、画像又はデータをより速く転送することが可能になる。
データがいったん、メモリ或いは磁気記憶素子又は光学記憶素子のような保存メカニズムを有するコンピュータのような「ローカル」装置に、或いは他の受取人装置に、転送されると、結果として生じる情報は、解凍され（あるいは特殊な復号プレーヤを使用して再生され）、必要な場合には復号され、対応する使用可能なプレゼンテーション解像度及び制御エレメントに基づいて適切なプレゼンテーションのために準備される。例えば、Ｘピクセル×Ｙピクセルの画面解像度の観点での典型的なコンピュータビデオ解像度は、所望されるか或いは必要とされるかに応じて種々の他の解像度が一般的に可能であるが、通常は、４８０ピクセル×６４０ピクセルほどの低さから６００×８００から１０２４×１０２４の範囲にある。
画像プレゼンテーションは、画像コンテンツ及び既定のビデオコントローラのある特定の予め定義されたカラーレベル(color level)又はカラー深さ(color depth)（色を生成するために使用されるピクセルあたりビット）及び輝度(intensity)に関して画像を操作する能力、及び追加の利用されているオーバヘッドビットによっても影響を受ける。例えば典型的なコンピュータプレゼンテーションは、他の値にも遭遇するが、多様な色（陰影と色相）を表現するために１ピクセルあたり約８から３２まで、或いはそれよりも多くのビットを予想するであろう。
前記値から、既定の画面画像はそれぞれ最低から最高の典型的な解像度と深度の範囲で約２．４５メガビット（Ｍｂ）から約３３．５５Ｍｂのデータの転送を必要とすることが分かる。毎秒３０コマのレートでビデオ又は動画タイプの画像を見るとき、必要とされるデータ量は、毎秒約７３．７メガビットから１，００６メガビット、つまり毎秒９．２１メガバイトから１２５．７５メガバイトである。更に、マルチメディアプレゼンテーション用のような画像と共に、或いはＣＤ品質の音楽のような別個の高解像度音声プレゼンテーションとして、音声データを提示することを所望する場合がある。対話型コマンド、コントロール、又は信号を処理する更なる信号もまた利用されてよい。これらの各々は、転送される更により多くのデータを追加するオプションをもつ。更に、高精細度（ＨＤ）テレビ及び映画録画を含むより新しい伝送技術は、なお更に多くのデータと制御情報を追加できる。何れの場合も、コンテンツリッチな経験を作り出すために、高品質又は高解像度の画像データと高品質音声情報又はデータ信号をエンドユーザに転送することを所望するとき、プレゼンテーションエレメントと、このようなタイプのデータを提供するように構成されているソース又はホストの装置との間では、高データ転送レートリンクが必要とされる。
１秒当たり約１１５キロバイト（ＫＢｐｓ）又は９２０キロビット（Ｋｂｐｓ）のデータレートは、幾つかの現代のシリアルインタフェースによって日常的に処理できる。ＵＳＢシリアルインタフェースのような他のインタフェースは、１２Ｍｂｐｓほどの高いレートでのデータ転送に対応でき、米国電気電子技術者協会（ＩＥＥＥ）１３９４標準規格を使用して構成される転送のような特殊高速度転送は、約１００ＭＢｐｓから４００ＭＢｐｓのレートで行われることが出来る。残念なことに、これらのレートは、ポータブルビデオディスプレイ又は音声装置を駆動するための高解像度でコンテンツリッチな出力信号を提供するために未来の無線データ装置及び他のサービスと共に使用するために意図される前述された所望される高データレートには及ばない。これは、事業用コンピュータ及びその他のプレゼンテーション、ゲーム機などを含む。加えて、これらのインタフェースは、操作するためにはかなりの量のホスト又はシステム及びクライアントソフトウェアの使用を必要とする。そのソフトウェアプロトコルスタックは、特にモバイルワイヤレス機器又は電話の応用例が意図される場合に、望ましくないほど大量のオーバヘッドも生じさせる。このような装置は、既に酷使されている計算能力だけでなく、厳しいメモリ制限と電力消費量制限も有する。更に、これらのインタフェースのいくつかは、高度に美的指向のモバイルアプリケーションには重すぎて不満足なかさばるケーブル、コストを追加する、或いは単に消費電力が多すぎる複雑なコネクタ、を利用する。
アナログビデオグラフィックスアダプタ（ＶＧＡ）、デジタルビデオインタラクティブ（ＤＶＩ）又はギガビットビデオインタフェース（ＧＶＩＦ）インタフェースのような、他の公知のインタフェースがある。これらの最初の２つは、より高速の転送レートでデータを処理するが、重いケーブルも利用し、数ワット台の大量の電力を消費する、並列型インタフェースである。これらの特性のどれも、携帯型家庭用電子機器と共に使用するのには適していない。３番目のインタフェースでさえも電力消費が大きすぎ、高価なあるいはかさばるコネクタを使用する。
上記インタフェースのいくつかと、他の非常に高いレートのデータシステム／プロトコル又は固定インストールコンピュータ装置用のデータ転送に関連付けられた転送機構、については、別の主要な欠点がある。所望されるデータ転送レートに対処することは、相当量の電力及び／又は高電流レベルでの動作も必要とする。これは、高度に移動性の消費財のためのこのような技術の実用性を大きく削減する。
一般に、例えば光ファイバ型接続及び転送エレメントのような代替策を使用してこのようなデータ転送レートに対処することは、真に商業的な消費財に所望されるよりももっと多い複雑さと費用をもたらす多数の更なる変換器及びエレメントも必要とする。今のところはまだ光学系システムの一般的に費用のかかる性質は別にして、それらの電力要件と複雑さは、軽量で低電力の携帯型アプリケーション用の一般的な使用を妨げる。
携帯型で無線又はモバイルアプリケーションのために業界で欠如してきたものは、それが音声であろうが、ビデオであろうが、或いはマルチメディアベースであろうがに関係なく、移動性の高いエンドユーザに対して高品質のプレゼンテーション経験を提供するための技術である。すなわち、携帯型コンピュータ、無線電話、ＰＤＡ又は他の高度に移動性の通信装置又は機器を使用するとき、使用されている現在のビデオプレゼンテーションシステム又は装置及び音声プレゼンテーションシステム又は装置は、所望される高品質レベルで出力を全く配信することができない。多くの場合、認識された欠けている品質は、高品質プレゼンテーションデータを転送するために必要とされる入手不能の高データレートによってもたらされたものである。これは、エンドユーザに対するプレゼンテーションのためのより効率的で高度な又は機能満載（ｆｅａｔｕｒｅ ｌａｄｅｎ）の外付け装置への転送と、携帯装置、例えばコンピュータ、ゲーム機、そして携帯電話のような無線装置など、の内部のクライアントとホストとの間の転送と、を含み得る。
後者の場合、更により高い解像度の内蔵ビデオ画面、そして他の特殊入力装置及び／出力装置と接続とを、いわゆる第三世代電話のような無線装置に、そしていわゆるラップトップコンピュータに、追加することにおいて大きな前進があった。然しながら、ホスト及び／又は多様な他の制御エレメント及び出力コンポーネントが存在する主要筐体に、ビデオ画面又は他のエレメントを取り付ける又は接続する、回転式又はスライド式蝶番又は蝶番状の構造にかかるブリッジを含んでよい内蔵データバスと接続。一般に、高帯域幅、或いは高スループットインタフェースがある。一例としては、例えば、無線電話で所望されるスループットを達成するためには、最大９０個までの導体或いはそれよりも多くを必要とし得る先行技術を使用して高スループットデータ転送インタフェースを構築することは非常に困難である。現在の解決策は、相互接続を、もっとコスト高に、より信頼の少ないものにさせ、そして装置機能と干渉するであろう放射妨害波を潜在的に発生させる可能性がある比較的高い信号レベルを有する、並列型インタフェースを使用することを一般に伴う。これは、克服するための、多くの製造上のコスト及び信頼性の挑戦的課題を示す。
このような問題点及び要件は、通信装置又は計算型装置が、一例として、高度なデータ機能、インターネット及びデータ転送接続又は内蔵エンターテインメントを提供するために、電気製品及び他の消費者装置に追加される、固定ロケーション装置にもまた見られる。別の例は、個別ビデオ及び音声プレゼンテーション画面がシートバックに取り付けられた、飛行機及びバスであろう。然しながら、これらの状況においては、メインの記憶、処理及び通信制御のエレメントを、情報のプレゼンテーションのための相互接続リンク又はチャネルを用いて可視画面又は音声出力からある距離離れて位置させることが、多くの場合、より便利で、効率的、且つ容易に使いやすい。このリンクは、前述されたように所望のスループットを達成するためにかなりの量のデータを処理することを必要とする。
従って、データを提供するホスト装置とエンドユーザに出力を提示するクライアントディスプレイ装置又はエレメントとの間のデータスループットを増加するためには新しい転送機構が必要とされる。
出願人は、このような新しい転送機構を、２００４年７月６日にＺｏｕ他に特許発行され現在は米国特許第４，７６０，７７２号である２００１年１２月１４日に出願された米国特許出願シリアル番号第１０／０２０，５２０号、及び２００２年９月６日に出願された米国特許出願シリアル番号第１０／２３６，６５７号、の中で提案した、なお、両出願とも、「高データレート信号転送のための通信プロトコル及びインタフェースを作成することと実現すること（Ｇｅｎｅｒａｔｉｎｇ Ａｎｄ Ｉｍｐｌｅｍｅｎｔｉｎｇ Ａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ａｎｄ Ｉｎｔｅｒｆａｃｅ Ｆｏｒ Ｈｉｇｈ Ｄａｔａ Ｒａｔｅ Ｓｉｇｎａｌ Ｔｒａｎｓｆｅｒ）」と題され、現在許可され、本発明の譲受人に譲渡され、参照してここに組み込まれる。また、「より高速なデータレートのための信号プロトコル及びインタフェースを作成することと実現すること（Ｇｅｎｅｒａｔｉｎｇ Ａｎｄ Ｉｍｐｌｅｍｅｎｔｉｎｇ ａ Ｓｉｇｎａｌ Ｐｒｏｔｏｃｏｌ ａｎｄ Ｉｎｔｅｒｆａｃｅ ｆｏｒ Ｈｉｇｈｅｒ Ｄａｔａ Ｒａｔｅｓ）」と題された米国特許出願シリアル番号第１０／８６０，１１６号が２００４年６月２日に出願されている。それらの出願で説明されている技術は、高速度データ信号の中の大量のデータのための転送レートを大幅に改善できる。然しながら、特にビデオプレゼンテーションに関連するような、増え続けるデータレートに対する需要は伸び続ける。データ信号技術における他の継続中の開発をもってしても、なお一層より速い転送レート、改善された通信リンク効率、そしてもっと強力な通信リンクを目指して努力する必要がある。従って、ホスト装置とクライアント装置との間のデータスループットを高めるために必要とされる新しい或いは改善された転送機構を開発することに対し継続しているニーズがある。
［要約］
技術的に存在する上記の欠点及び他は、新しいプロトコル及びデータ転送手段、方法、及び機構が、高データレートで(at high data rate)ホスト装置と受取人クライアント装置との間においてデータを転送するために開発された、本発明の実施形態により対処される。
本発明の実施形態は、事前に選択された１セット(a pre-selected set)のデジタル制御及びプレゼンテーションデータをホスト装置とクライアント装置との間で通信するための通信プロトコルを形成するために複数の又は一連のパケット構造を使用する通信経路上で、ホスト装置とクライアント装置との間を高レートで(at high rate)デジタルデータを転送するためのモバイルデータデジタルインタフェース（ＭＤＤＩ）を対象としている。信号通信プロトコル又はリンク層は、ホスト又はクライアントリンクコントローラ、レシーバ、又はドライバの物理層によって使用される。ホスト装置内に常駐する少なくとも１つのリンクコントローラ又はドライバは、通信経路又はリンクを通してクライアント装置に結合され、通信プロトコルを形成するパケットを生成し、送信し、そして受信するように、そしてデジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成される(configured)。インタフェースは、共通した全体的なハウジング又はサポート構造内に常駐できるホスト及びクライアント間の情報の双方向転送を提供する。
インプリメンテーション(the implementation)は、一般に、差動ドライバとレシーバを除いて、本質的に全てデジタルであり、デジタルＣＭＯＳチップ上で容易に実現でき、６信号のように少ない信号を必要とし、システムデザイナにとって便利な、ほとんど任意のデータレートで動作する。シンプルな物理的及びリンク層プロトコルは、統合することを容易にし、そして、この簡潔さ(simplicity)にハイバネーション状態(a hibernation state)が加わり、ポータブルシステムは非常に低いシステム電力消費を有することが可能となる。
使用と受容を支援するために、インタフェースは、装置のコストをほとんど増加せず、標準電池電圧を使用するインタフェースを通じてディスプレイに電力を供給できる一方で、ほんの少しの電力消費を可能とし、そして、ポケットサイズのフォームファクタを有する装置に対応できる。インタフェースはＨＤＴＶを超える解像度をサポートするためにスケラブル(scalable)であり、ディスプレイ装置に対する同時ステレオビデオと７．１音声をサポートし、任意の画面領域への条件付更新を実行し、両方向での複数のデータタイプをサポートする。
本発明の実施形態の更なる態様(aspects)では、少なくとも１つのクライアントリンクコントローラ、レシーバ、装置、又はドライバが、クライアント装置内に配置され、通信経路又はリンクを通じてホスト装置に結合される。クライアントリンクコントローラはまた、通信プロトコルを形成するパケットを生成し、送信し、そして受信するように、そして、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように、構成される。一般的に、ホスト又はリンクコントローラは、コマンド又はあるタイプの信号作成及び照会処理で使用されるデータパケットを処理するための状態機械を使用するが、通信プロトコルで使用されるデータ及びあまり複雑ではないパケットのいくつかを操作するためにより低速の汎用プロセッサを使用できる。ホストコントローラは、１つ又は複数の差動ラインドライバを備える；一方、クライアントレシーバは、通信経路に結合される１つ又は複数の差動ラインレシーバを備える。
パケットは、予め定められた数(a pre- determined number)の異なる可変長を有するパケットを備えた予め定義された固定長(a pre-defined fixed length)を有し、ホスト装置とクライアント装置との間で通信される、メディアフレーム内で共にグループ化される。パケットは、各々、パケット長フィールド(a packet length field)、１つ又は複数のパケットデータフィールド(packet data fields)、及びサイクリックリダンダンシーチェックフィールド(a cyclic redundancy check field)を備える。サブフレームヘッダパケット(a Sub-frame Header Packet)は、ホストリンクコントローラからの他のパケットの転送の初めに転送される又は位置づけられる。１つ又は複数のビデオストリーム型パケット(Video Stream type packets)及び音声ストリーム型パケット(Audio Stream type packets)は、クライアント装置ユーザへのプレゼンテーションのために、順方向リンク上で、ホストからクライアントに、ビデオタイプデータと音声タイプデータを夫々転送するために通信プロトコルによって使用される。１つ又は複数の逆方向リンクカプセル化タイプパケット(Reverse Link Encapsulation type packets)は、クライアント装置からホストリンクコントローラにデータを転送するために通信プロトコルによって使用される。いくつかの実施形態におけるこれらの転送は、少なくとも１つのＭＤＤＩ装置を有する内蔵コントローラから内蔵ビデオ画面へのデータの転送を含む。他の実施形態は、内部サウンドシステムへの転送及びジョイスティック(joystics)及び複雑なキーボードを含む多様な入力装置から内蔵ホスト装置への転送を含む。
フィラー型パケット(Filler type packets)は、データを有さない順方向リンク伝送の期間を占有するために、ホストリンクコントローラによって生成される。複数の他のパケットは、ビデオ情報を転送するために通信プロトコルによって使用される。このようなパケットは、カラーマップパケット、ビットブロック転送パケット、ビットマップ領域塗りつぶしパケット、ビットマップパターン塗りつぶしパケット、及びトランスペアレントカラーイネーブル型パケット(Color Map, Bit Block Transfer, Bitmap Area Fill, Bitmap Pattern Fill, and Transparent Color Enable type packets)を含む。ユーザ定義ストリーム型パケット(User-Defined Stream type packets)は、インタフェースユーザ定義データを転送するために通信プロトコルによって使用される。キーボードデータ及びポインティングデバイスデータ型パケット(Keyboard Data and Pointing Device Data type packets)は、クライアント装置と関連付けられるユーザ入力装置に、又は、から、データを転送するために、通信プロトコルによって使用される。リンクシャットダウン型パケット(a Link Shutdown type packet)は、前記通信経路上のどちらの方向にもデータの転送を終了するため通信プロトコルによって使用される。
システムパワー消費又はシステムリソース消費のもとを最小化するため、ディスプレイのようなクライアントが使用されていない又は電流アクティブ使用にない時に、特定のディスプレイコントローラハードウェアを低電力状態に置くための構造、手段、又は方法を提供するためにディスプレイパワー状態パケット(Display Power State Packets)が生成される。一実施形態においては、クライアントは、クライアント機能パケット(a Client Capability Packet)のクライアント特徴機能インジケータフィールドビット９を使用してディスプレイパワー状態パケットに応答する能力を示す。
ディスプレイパワー状態パケット用の一実施形態のフォーマット、このタイプのパケットは、パケット長、パケットタイプ、ｈＣｌｉｅｎｔ ＩＤ、パワー状態、及びＣＲＣフィールドを有するように構成される。このタイプのパケットは、一般に、２−バイトタイプフィールドの中においてタイプ７５パケットとして識別される。２-バイトｈＣｌｉｅｎｔ ＩＤフィールドは、Ｃｌｉｅｎｔ ＩＤのために確保される情報又は値を含む。パワー状態フィールドは、特定のディスプレイをある事前に選択されたビットの値に応じた指定されたパワー状態に置くために使用される情報を指定する。２バイトＣＲＣフィールドは、パケット長を含むパケットにおいて全バイトのＣＲＣを含む又は指定する。
通信経路は、通常、一連の４本又はそれより多くの導線(conductors)と１つのシールドを有するケーブルを備え、又は使用する。更に、プリントワイヤ又は導体を所望されるように使用でき、幾つかはフレキシブル基板上に存在する。
ホストリンクコントローラは、前記クライアントが前記インタフェースを通じてどんなタイプのデータとデータレートに対処できるのかを決定するためにクライアント装置からディスプレイ機能情報(display capability infomation)を要求する。クライアントリンクコントローラは、少なくとも１つのクライアント機能型パケット(Client Capability type packet)を使用してディスプレイ機能又はプレゼンテーション機能をホストリンクコントローラに伝達する。複数の転送モードが通信プロトコルによって使用され、各々は既定の期間にわたって平行して異なる最大数のビットのデータの転送を可能にし、各モードは、ホストリンクコントローラとクライアントリンクコントローラとの間の交渉によって選択可能である。これらの転送モードは、データの転送中に動的に調整可能であり、順方向リンクで使用されるのと同じモードが逆方向リンクで使用される必要はない。
本発明のいくつかの実施形態の他の態様では、ホスト装置は、無線電話、無線ＰＤＡ、又はその中に配置される無線モデムを有するポータブルコンピュータのような、無線通信装置を備える。典型的なクライアント装置は、マイクロディスプレイ装置及び／又は携帯型音声プレゼンテーションシステムのような、ポータブルビデオディスプレイを備える。更に、ホストは、クライアント装置ユーザに提供されるために転送されるプレゼンテーションデータ又はマルチメディアデータを保存するための記憶手段又はエレメントを使用してよい。
いくつかの実施形態の更に他の態様では、ホスト装置は、無線電話、無線ＰＤＡ又はポータブルコンピュータのような無線通信装置、のような携帯型電子装置内に常駐する、後述されるような、ドライバ付きのコントローラ又は通信リンク制御装置を備える。この構成の典型的なクライアント装置は、ホストに結合され同装置内に常駐する、そして、携帯電話用の高解像度画面のような内蔵ビデオディスプレイ、及び／又は携帯型音声プレゼンテーションシステムに結合された、或いは、代替の何らかのタイプの入力システム又は装置の中の、クライアント回路又は集積回路又はモジュールを備える。
［詳細な説明］
本発明の多様な実施形態の構造及び動作だけではなく、本発明の更なる特徴及び利点が、添付図面を参照して以下に詳細に説明される。図面においては、同様の参照番号は一般に、同一の、機能上類似する、及び／又は構造上類似するエレメント又は処理ステップを示す。
Ｉ．概要
本発明の全般的な目的は、下記に説明されるように、「シリアル」型のデータリンク又はチャネルを使用して、ディスプレイエレメントのような、クライアント装置とホスト装置との間の、短距離通信リンク上での高速度又は非常に高速度のデータ転送を可能にする、コスト的に効率がよく、低電力消費の転送機構をもたらす又は与える、モバイルディスプレイデジタルインタフェース（ＭＤＤＩ）を提供することである。本機構は、内部の（ハウジング又はサポートフレームに対し内側の）ディスプレイ又は出力エレメント又は装置、又は入力装置を、中央コントローラ又は通信エレメント又は装置に接続するのに特に有用な、小型コネクタと薄い可撓ケーブルを用いるインプリメンテーションに向いている。更に、この接続機構は、ウェアラブルマイクロディスプレイ（ゴーグル又はプロジェクタ）或いは他のタイプの視覚的、聴覚的、触覚的な情報プレゼンテーション装置のような外部ディスプレイエレメント又は装置を、ポータブルコンピュータ、無線通信装置、又はエンターテインメント装置に、接続する場合に非常に有用である。
用語モバイル(Mobile)及びディスプレイ(Display)がプロトコル(protocol)のネーミングに関連付けられているけれども、これは、インタフェースとプロトコルを扱う仕事をする当業者によって容易に理解される標準的なネームを有するという点からみて、便宜上だけのためである、ということが理解されるべきである。それがＶＩＳＡ標準規格及びその標準規格の様々なアプリケーションに関連するように。然しながら、多くの非モバイル(non-mobile)及び非ディスプレイ(non-display)に関連のアプリケーションが、このプロトコルのアプリケーション、結果として生じるインタフェース構造、又は転送機構、から恩恵を受け、そして、ＭＤＤＩラベルは、本発明又はその様々な実施形態の本質又は有用性に何らかの制限を含むことを意味するようには意図されていない、ということが、以下に示される実施形態の検討後に、容易に理解されるであろう。
本発明の実施形態の利点は、非常に柔軟でありながら、複雑度が低く、低コストで、信頼性が高く、使用環境によく適合し、非常に堅牢である、データ転送のための技術が提供されることである。
本発明の実施形態は、一般に、音声、ビデオ又はマルチメディアのアプリケーション用の大量のデータを、このようなデータが、例えば特定の装置に転送されるなどのために生成され、操作され、或いはそうでなければ処理され、又は保存されるところの、ホスト又はソース装置から、ビデオ画面又はプロジェクションエレメント、音声スピーカ、或いは他のプレゼンテーション装置のような、クライアント又は受信装置に、高レートで伝達又は転送するために、様々な状況において使用されることが出来る。下記に説明される典型的なアプリケーションは、ポータブルコンピュータか或いは無線電話又はモデムから、例えば小型映写レンズ及びスクリーンを含むゴーグル又はヘルメットの形をとって、ウェアラブルマイクロディスプレイ器具や小型ビデオ画面のような視覚ディスプレイ装置への、或いは、ホストからそのようなコンポーネント内のクライアント装置への、データの転送である。すなわち、クライアントを使用する様々な内部又は外部の入力装置から内部に位置する（同じ装置のハウジング又はサポート構造内に配置される）或いはケーブル又は導線で接続されるホストへと同様に、プロセッサ又はコントローラから内蔵スクリーン又は他のプレゼンテーションエレメントへもである。
ＭＤＤＩの特性又は属性は、それらが特定のディスプレイ又はプレゼンテーション技術に無関係であるようなものである。それは、そのデータの内部構造にも或いはそれが実現するデータ又はコマンドの機能上の態様にも関係なくに、高レートでデータを転送するための高度に柔軟な機構である。これは、転送されているデータパケットのタイミングを、例えばある特定の装置に対する特定のディスプレイ要望に対するようなある特定のクライアント装置の特異性に適応するように、或いは、いくつかのＡ−Ｖシステム用の、又は、ジョイスティック、タッチパッド、などのようなある特定の入力装置用の、結合された音声及びビデオの要件を満たすように、調整されることを可能にする。選択されたプロトコルに従う限り、インタフェースは、まさにディスプレイエレメント又はクライアント装置不可知論者(agnostic)である。加えて、集合シリアルリンクデータ又はデータレートは、桁違いに変化でき、通信システム又はホスト装置設計者が、コスト、電力要件、クライアント装置複雑さ、そしてクライアント装置更新レートを最適化するのを可能にする。
データインタフェースは、主に、「有線」信号リンク又は小型ケーブル上で大量の高レートデータを転送する際に使用するために提供される。然しながら、いくつかのアプリケーションは、それがインタフェースプロトコルのために開発された同じパケット及びデータ構造を使用するように構成されるならば、光学的ベースのリンクを含み、同様に無線リンクも利用でき、そして、十分に低い電力消費量で又は実用性を残した複雑さで所望されるレベルの転送を維持できる。
ＩＩ．環境
典型的なアプリケーションは図１Ａと図１Ｂにおいて見られることができ、ここでは、ポータブル又はラップトップコンピュータ１００と無線電話又はＰＤＡ装置１０２とが、夫々、音声再生システム１０８及び１１２と共に、ディスプレイ装置１０４及び１０６とデータを通信しているのが示されている。更に、図１Ａは、より大型のディスプレイ又は画面１１４或いは画像プロジェクタ１１６への潜在的な接続を示し、それらは、明確にするために、１つの図において示されているだけであるが、無線装置１０２にも同様に接続可能である。無線装置は、現在データを受信中でありえ、或いは、無線装置のエンドユーザによるビューイング及び／又はヒアリングのための後のプレゼンテーション用にある特定の量のマルチメディアタイプデータを記憶素子又は記憶装置に前に記憶している。典型的な無線装置は、大体の場合、音声及び単純なテキスト通信用に使用されるので、情報を装置１０２のユーザに通信するために寧ろ小型のディスプレイ画面と単純な音声システム（スピーカ）を有する。
コンピュータ１００は、もっと大型の画面を有するが、依然として不十分な外部サウンドシステムを有し、依然として、高精細度テレビ又は映画のスクリーンのような、他のマルチメディアプレゼンテーション装置には及ばない。コンピュータ１００は図解の目的に使用され、そして他のタイプのプロセッサ、対話型ビデオゲーム、又は家庭用電子機器もまた本発明と共に使用されることができる。コンピュータ１００は、無線通信のために無線モデル又は他の内蔵装置、但しこれらに或いはこれらによって限定されない、を利用できる、或いは所望されるようにケーブル又は無線リンクを使用してこのような装置に接続されることが出来る。
これは、より複雑な或いは「リッチな」データのプレゼンテーションを有用な或いは楽しめる経験とは言えないものにする。従って、業界は、エンドユーザに情報を提示し、最小レベルの所望される楽しみ又は積極的な経験を提供するために、他の機構及び装置を開発中である。
前述されたように、装置１００のエンドユーザに情報を提示するために幾つかのタイプのディスプレイ装置が開発された又は開発中である。例えば、１社又は複数の企業が、視覚的ディスプレイを提示するために装置ユーザの目の前で画像を投影するウェアラブルゴーグルのセットを開発した。正しく配置されると、このような装置は、視覚的な出力を提供するエレメントよりはるかに大きい「仮想画像」を、ユーザの目によって知覚されるように、効果的に「投影」する。つまり、非常に小さいプロジェクションエレメントにより、ユーザの目（複数の場合がある）は、典型的なＬＣＤ画面等で可能であるよりはるかに大規模に画像を「見る」ことができる。より大型の仮想画面画像を使用することにより、もっと限定されたＬＣＤ画面ディスプレイで可能となるよりはるかに高い解像度の画像の使用も可能になる。他のディスプレイ装置は、表面等の上に画像を投影するために、小型ＬＣＤ画面又は様々なフラットパネルディスプレイエレメント、映写レンズ及びディスプレイドライバ、但しこれらに限定されないが、を含むことができるであろう。
順番に信号を他のどこかに転送する又はそれらを保存する別の装置に、又は別のユーザに、出力を提示するために、無線装置１０２又はコンピュータ１００に接続される又は無線装置１０２又はコンピュータ１００の使用に関連付けられる、更なるエレメントもまたあってよい。例えば、データは、フラッシュメモリ中に、光学的形式で、例えば書き込み可能ＣＤ媒体を使用して、又は、後の使用のために、磁気媒体上に、例えば、磁気テープレコーダ及び類似する装置の中に、記憶されることができる。
更に、多くの無線装置とコンピュータは現在、他の高度なサウンドデコーダとサウンドシステムと同様に、内蔵ＭＰ３ミュージック復号機能も有している。ポータブルコンピュータは、一般的な傾向として、ＣＤプレイバック機能とＤＶＤプレイバック機能を利用し、あるものは事前に記録された音声ファイルを受信するための小型専用フラッシュメモリ読取装置も有する。このような機能を有することの問題点は、復号とプレイバックのプロセスが対応出来る場合のみに、デジタルミュージックファイルは高度に強化されたフィーチャリッチ（ｆｅａｔｕｒｅ ｒｉｃｈ）な経験を約束するという点である。同じことはデジタルビデオファイルにも当てはまる。
音声再生を支援するために、前部と後部のサウンドプロジェクション用の「サラウンドサウンド」スピーカ、或いは、サブウーファーのような追加エレメントを伴うことも出来るであろう、外部スピーカ１１４が図１Ａに示されている。同時に、スピーカ又はイヤホン１０８が、図１Ｂのマイクロディスプレイ装置のサポートフレーム又は機構に内蔵のももとして示されている。知られているであろうように、電力増幅又は音声整形の装置を含む他の音声又はサウンド再生のエレメントが使用されることが出来る。
いずれにせよ、前述されたように、データソースからエンドユーザに対して１つ又は複数の通信リンク１１０上で高品質又は高解像度の画像データ及び高品質の音声情報又はデータ信号を転送することを所望する時は、高データレートが必要とされる。すなわち、転送リンク１１０は、前述されたようなデータの通信においては、明らかに潜在的なボトルネックであり、又、現在の転送機構は通常所望されるような高データレートを達成しないので、システム性能を制限している。例えば前述されたように、１０２４ピクセル×１０２４ピクセルのような高解像度の場合は、１ピクセルあたり２４から３２ビットのカラー深さと３０ｆｐｓのデータレートを用いると、データレートは７５５Ｍｂｐｓ以上を凌ぐレートに近づくことができる。加えて、このような画像は、音声データ、そして対話型ゲーム又は通信に対処する潜在的な追加信号、或いは様々なコマンド、制御又は信号を含む、マルチメディアプレゼンテーションの一部として提示されてよく、量又はデータ及びデータレートを更に増加する。
データリンクを確立するために必要とされるケーブル又は相互接続がより少ないということは、ディスプレイに関連付けられるモバイル機器がより使用しやすく、より大きなユーザベースに採用される可能性がより高いことを意味することもまた明らかである。これは、特に、複数の装置が完全な視聴覚経験を確立するために一般的に使用される場合に、そして更に特にディスプレイと出力装置の品質レベルが増加するにつれて当てはまる。
ビデオ画面及び他の出力装置や入力装置における上記及び他の改善の多くに関連する別の典型的なアプリケーションは、図１Ｃと図１Ｄに見られることができ、ここでは、ポータブル又はラップトップコンピュータ１３０と無線電話又はＰＤＡ装置１４０とが、夫々、音声再生システム１３６及び１４６と共に、「内蔵」ディスプレイ装置１３４及び１４４とデータを通信しているのが示される。
図２Ａ及び図２Ｂにおいて、全体的な電子装置又は製品の小さな切取内部図が、装置の一部分の中の１つ又は複数の内部ホスト及びコントローラの位置を示すために使用されており、装置は、それらを、今日ではエレクトロニクス産業の全体にわたって使用されている何らかの公知のタイプの回転接続部を越えて、対応するクライアントを有するビデオディスプレイエレメント又は画面に夫々接続する、汎用通信リンク、ここでは１３８及び１４８、を備えている。これらの転送に関与するデータ量は、リンク１３８及び１４８を構成するのに多数の導線を必要とする、ということが分かる。このようなデータを転送するために利用できる並行の又は他の公知のインタフェース技術のタイプのために、このような装置上で、高度なカラーでグラフィカルなインタフェース、ディスプレイエレメントを利用することに対する今日の増大する必要性を満たすために、このような通信リンクは９０以上の導線に近づいていると推定される。
残念なことに、より高いデータレートは、データを転送するために利用可能な現在の技術を超えている。単位時間あたりに転送されるために必要とする未処理のデータ量の点、信頼性のあるコスト効率のよい物理的な転送機構を製造することの点、の両方からみて。
必要とされるのは、常に変わることのない（より）低い電力、軽量、及び可能な限り簡略且つ経済的なケーブル布線構造を可能にする、プレゼンテーションエレメントとデータソースとの間のデータ転送リンク又は通信経路のための、より高レートでデータを転送する技術、構造、手段又は方法である。出願人は、所望される低消費電力と複雑さを維持する一方で、モバイル機器、携帯機器、又は固定位置の装置さえ、のアレイが、データを、所望されるディスプレイ、マイクロディスプレイ、又は音声転送エレメントに、非常に高いデータレートで転送することを可能とするように、これらの及び他の目標を達成するために、新しい技術、或いは方法及び装置を開発した。
ＩＩＩ．高レートデジタルデータインタフェースシステムアーキテクチャ
新しいデバイスインタフェースを作成し効率的に利用するために、低電力信号を使って非常に高速のデータ転送レートを提供する信号プロトコルとシステムアーキテクチャが明確に示されている。該プロトコルは、データ又はデータタイプの事前に選択されたセットをインタフェースに課されるコマンド又は操作構造と共に通信するためのプロトコルを形成するために共にリンクされた構造、又はパケットと共通フレーム構造、に基づく。
Ａ．概要
ＭＤＤＩリンクによって接続される又はＭＤＤＩリンク上で通信する装置は、ホスト及びクライアントと呼ばれ、他の出力装置と入力装置も意図されるが、クライアントは通常何らかのタイプのディスプレイ装置である。ホストからディスプレイへのデータは順方向（順方向トラフィック又はリンクと呼ばれる）で移動し、クライアントからホストへのデータは、ホストによりイネーブルされるように逆方向（逆方向トラフィック又はリンク）で移動する。これは図３に示される基本的な構成において図示されている。図３においては、ホスト２０２は、順方向リンク２０８と逆方向リンク２１０とを備えているとして図示されている双方向通信チャネル２０６を使用してクライアント２０４に接続される。然しながら、これらのチャネルは、そのデータ転送が順方向リンク動作と逆方向リンク動作との間で効果的に切り替えられる導線の１つの共通したセットにより形成されている。これにより、導線の数は大幅に削減され、モバイル電子装置向けのような低電力環境における高速度データ転送に対する現在の手法に直面する多くの問題の１つに即座に対処できる。
他のどこかで説明されるように、ホストは、本発明を使用することから恩恵を受けることができる複数のタイプの装置の内の１つを備える。例えば、ホスト２０２は、携帯用装置、ラップトップ装置、又は類似するモバイル計算機器の形をしたポータブルコンピュータでありえるであろう。それはまた、パーソナルデータアシスタント（ＰＤＡ）、ページング装置、又は多くの無線電話又はモデムの１つでもありえるであろう。一方、ホスト２０２は、ポータブルＤＶＤ又はＣＤプレーヤ、又はゲームプレイ装置のような、ポータブルエンターテインメント装置又はプレゼンテーション装置でありえるであろう。
更に又、ホストは、クライアントとの高速通信リンクが所望される、種々の他の広く使用されている、又は計画されている商品の中にホスト装置又は制御エレメントとして常駐できる。例えば、ホストは、ビデオ記録装置から応答の改善のために記憶装置ベースのクライアントに、或いはプレゼンテーションのために高解像度大型画面に、高レートでデータを転送するために使用されることができるであろう。機載在庫又は計算システム、及び／又は、他の家庭用装置に対するブルーツース接続、を組み込んだ冷蔵庫のような電気製品は、インターネットモード又はブルーツース接続モードで動作している時に改善されたディスプレイ機能を有することができる、或いは電子コンピュータ又は電子制御システム（ホスト）がキャビネット内のどこかに常駐する間はドア内（ｉｎ−ｔｈｅ−ｄｏｏｒ）ディスプレイ（クライアント）及びキーパッド又はスキャナ（クライアント）に対し配線の必要性を削減することができる。一般的には、当業者は、新規に追加されたか既存かの何れかのコネクタ又はケーブルにおいて利用可能な限定された数の導線を利用し情報のより高速なデータレートトランスポートで旧い装置を改良する能力だけではなく、このインタフェースの使用から恩恵を受ける可能性のある種々様々な最新の電子装置と家庭用製品を理解するであろう。
同時に、クライアント２０４は、エンドユーザに情報を提示するため、或いはユーザからホストに情報を提示するために有用な種々の装置を備えることができるであろう。例えばゴーグル又はめがねに組み込まれているマイクロディスプレイ、帽子又はヘルメットに内蔵されているプロジェクション装置、ウィンドウ又はフロントガラス等の車両に内蔵される小型画面又はホログラフィック素子、又は多様なスピーカ、ヘッドフォン、あるいは高品質のサウンド又は音楽を提示するためのサウンドシステム等である。他のプレゼンテーション装置は会議用、あるいは映画とテレビの画像用に情報を提示するために使用されるプロジェクタ又はプロジェクション装置を含む。別の例は、ユーザからの接触又はサウンド以外の実際の「入力」がほとんどない装置又はシステムユーザから大量の情報を転送するように要求される可能性のあるタッチパッド又は敏感な装置、音声認識入力装置、セキュリティスキャナ、等の使用であろう。加えて、コンピュータ及びカーキット又はデスクキット、及び無線電話用のホルダのためのドッキングステーションは、エンドユーザ又は他の装置及び機器に対するインタフェース装置として動作してよく、特に高速ネットワークが関係する場合にデータの転送を支援するためにクライアント（マウスのような出力又は入力装置）又はホストのどちらかを利用してよい。
然しながら、当業者は、本発明がこれらの装置に限定されず、保存とトランスポートの観点或いはプレイバック時のプレゼンテーションの観点の何れかから、高品質の画像と音声をエンドユーザに提供するように意図された、多くの他の装置が市場にあり、使用が提案されていることを容易に認識するであろう。本発明は、所望されるユーザ経験を実現するために必要とされる高データレートに対処するために様々なエレメント又は装置の間のデータスループットを増加するという点で有効である。
本発明のＭＤＤI及び通信信号プロトコルは、コスト又は複雑さ及び関連する電力と制御の要件又はこれらの接続の制約を削減するために、装置又は装置ハウジング又は構造体の内部（内蔵モードと呼ばれる）のホストプロセッサ、コントローラ、又は回路コンポーネント（例えば）、そしてディスプレイの間の相互接続を簡略化するために、そして、外部エレメント、装置又は機器（外部モードと呼ばれる）に対する、又はへの単に接続のためではなく、それらの信頼性を高めるために使用されてよい。
このインタフェース構造により使用される各信号ペアの集合シリアルリンクデータレートは、大きさが何桁も変化でき、システム又は装置設計者が、既定のアプリケーション又は目的のためにコスト、電力、インプリメンテーションの複雑さ及びディスプレイ更新レートを容易に最適化することを可能にする。ＭＤＤＩの属性はディスプレイ又は他のプレゼンテーション装置（ターゲットクライアント）技術とは無関係である。インタフェースを通して転送されるデータパケットのタイミングは、ディスプレイ装置、サウンドシステム、記憶及び制御エレメント、又は視聴覚システムの結合されたタイミング要件のような、特定のクライアントの特異性に適応するように容易に調整されることができる。これにより、電力消費が非常に小さいシステムを有することができる一方、少なくともなんらかのレベルでＭＤＤＩプロトコルを利用するためにフレームバッファを有することは多様なクライアントの要件ではない。
Ｂ．インタフェースタイプ
ＭＤＤIは、少なくとも４種類、そして潜在的にはそれよりも多くの、通信業界及びコンピュータ業界で見られる何らかの異なる物理的なタイプのインタフェースに対処するように意図されている。それらが使用されている特定のアプリケーション或いはそれらが関連している業界に応じて、他のラベル又は名称が当業者によって適用されてもよいが、これらは単純に１型、２型、３型及び４型と名付けられている。例えば、単純な音声システムは、より複雑なマルチメディアシステムよりもより少ない接続を使用しており、「チャネル」のように特徴を別に参照してよい、等である。
１型インタフェースは、それを携帯又は無線電話、ＰＤＡ、電子ゲーム、及びポータブル媒体プレーヤ、例えばＣＤプレーヤなど、又はＭＰ３プレーヤ、及び類似した装置又は類似したタイプの電子消費者技術で使用される装置に適したものにする、６ワイヤ、又は他のタイプの導線又は導電素子、インタフェースとして構成される。一実施形態では、インタフェースは、ラップトップコンピュータ、ノート型パソコン、又はデスクトップパソコン及び類似した装置又はアプリケーションにもっと適し、迅速なデータの更新を必要とせず、そして、内蔵ＭＤＤＩリンクコントローラを持たない、８ワイヤ（導線）インタフェースとして構成されることができる。このインタフェースのタイプは、大部分のパソコンで見られる既存のオペレーティングシステム又はソフトウェアサポートに対応するのにきわめて有効である、追加の２線ユニバーサルシリアルバス（ＵＳＢ）インタフェースの使用によってもまた区別可能である。
２型、３型、及び４型インタフェースは、高性能クライアント又は装置に適しており、データ信号に適切な遮蔽及び低損失転送を提供するために、追加のツイストペアタイプ導線を備えたより大きくもっと複雑なケーブル布線を使用する。
１型インタフェースは、ディスプレイ、音声、制御及び制限されたシグナリング情報を備えることができる信号を送出し、通常、高解像度全レートビデオデータを必要としないモバイルクライアント又はクライアント装置のために使用される。１型インタフェースは５．１チャネル音声に加えて３０ｆｐｓでＳＶＧＡ解像度を容易にサポートでき、最小の構成で、データ伝送用の２組と電力伝送用の１組の合計３ワイヤ組だけを使用する可能性がある。このタイプのインタフェースは主にモバイル無線機器のような装置向けに意図されており、そこではＵＳＢホストは、このような装置内では、信号の接続及び転送に通常使用できない。この構成では、モバイル無線装置は、ＭＤＤＩホスト装置であり、通常は、プレゼンテーション、ディスプレイ又はプレイバックのためにクライアントに（順方向トラフィック又はリンク）データを送信する、ホストからの通信リンクを制御する「マスタ」として働く。
このインタフェースでは、ホストは、クライアントに、指定された期間にそれがバス（リンク）を占有しそして逆方向パケットとしてホストにデータを送信することを可能にする特殊なコマンド又はパケットタイプを送信することによって、クライアントからの（逆方向トラフィック又はリンク）通信データのホストでの受信を可能にする。このことは図４において図示されており、ここでは、カプセル化パケット（後述される）と呼ばれるタイプのパケットが、転送リンク上での逆方向パケットの転送に対処するために使用され、逆方向リンクを生じさせている。ホストがデータのためにクライアントをポーリングするために割り当てられた時間間隔は、ホストによって予め決定され、又、それぞれの指定されたアプリケーションの要件に基づいている。このタイプの半二重双方向データ転送は、ＵＳＢポートがクライアントからの情報又はデータの転送に使用できない場合に、特に便利である。
ＨＤＴＶ型又は類似した高解像度が可能な高性能ディスプレイは、フルモーションビデオをサポートするために約１．５Ｇｂｐｓレートのデータストリームを必要とする。２型インタフェースは並列で２ビットを送信することによって、３型は並列で４ビットを送信することによって、高データレートをサポートし、そして４型インタフェースは並列で８ビットを転送する。２型及び３型インタフェースは、１型と同じケーブルとコネクタを使用するが、ポータブル装置上でより高性能のビデオアプリケーションをサポートするためにデータレートの２倍及び４倍で動作できる。４型インタフェースは、非常に高性能のクライアント又はディスプレイに適しており、追加のツイストペアデータ信号を含むわずかに大きなケーブルを必要とする。
ＭＤＤＩによって使用されるプロトコルは、各１型、２型、３型又は４型のホストが、
、何が使用されることが出来る可能な最高のデータレートなのかを交渉することによって、１型、２型、３型又は４型のクライアントと一般に通信するのを、可能にする。最も低機能の装置と呼ばれ得るものの能力又は利用可能な機能は、リンクのパーフォーマンスを設定するために使用される。通例、ホストとクライアントが両方とも２型、３型又は４型のインタフェースを使用することが可能であるシステムの場合にさえ、両方とも１型インタフェースとして動作を開始する。ホストは、次に、ターゲットクライアントの機能を決定し、そして、特定のアプリケーションに対し適切に、２型、３型又は４型のモードのどれかへのハンドオフ動作又は再構成動作を交渉する。
一般的には、ホストが、適切なリンク層プロトコルを使用し（更に後述される）、省電力のためにより低速なモードに通常どんなときでも下げる、つまり再び動作を設定し直す、或いは、より高い解像度のディスプレイコンテンツ用のような、より高速な転送をサポートするためにより高速なモードに上げることが可能である。例えば、ホストは、システムが電池のような電源からＡＣ電力に切り替わる時に、或いは、ディスプレイ媒体のソースがより低い解像度フォーマット又はより高い解像度フォーマットに切り替わる時に、或いはこれらの組み合わせ又は他の条件又は事象がインタフェースタイプ、又は転送モードを変更する根拠とみなされてよい時に、インタフェースタイプを変更してよい。
システムが一方向で１つのモードを使用し、別方向で別のモードを使用してデータを通信することもまた可能である。例えば、４型インタフェースモードは、高レートでディスプレイにデータを転送するために使用されることができるであろうが、一方では、１型モードが、キーボード又はポインティングデバイスのような周辺装置からホスト装置にデータを転送する時に使用される。ホストとクライアントが発信データを異なるレートで通信してよいことは当業者によって理解されるであろう。
多くの場合、ＭＤＤＩプロトコルのユーザは「外部」モードと「内部モード」とを区別してよい。外部モードは、ある装置内のホストを、その装置の外部にあってホストから約２メートルかそのくらいまであるクライアントに接続するためのプロトコルとインタフェースの使用を説明する。この状況では、ホストは、両方の装置がモバイル環境で容易に動作できるように外部クライアントに電力を送信してもよい。内部モードは、ホストが、同じ装置の内部、例えば共通ハウジング又はサポートフレーム或いは何らかの種類の構造体などの内側、に含まれるクライアントに、いつ接続されるのかを説明する。一例は、無線電話又は他の無線装置、或いは、クライアントがディスプレイ又はディスプレイドライバ、或いはキーパッド又はタッチパッドのような入力装置、或いはサウンドシステムであり、ホストが中央コントローラ、グラフィックエンジン又はＣＰＵエレメントである、ポータブルコンピュータ又はゲーム装置、のアプリケーションであろう。クライアントは、内部モードアプリケーションにおいては、外部モードアプリケーションとは対照的に、ホストにはるかに近く位置するので、このような構成においてはクライアントに対する電力接続について検討される要件は一般にない。
Ｃ．物理インタフェース構造
ホスト装置とクライアント装置との間で通信を確立するための装置又はリンクコントローラの一般的な配置が図５及び図６に示されている。図５と図６においては、ＭＤＤＩリンクコントローラ４０２及び５０２が、ホスト装置２０２内に取り付けられて示され、ＭＤＤＩリンクコントローラ４０４及び５０４がクライアント装置２０４内に取り付けられて示される。前述されたように、ホスト２０２は、一連の導線を備える双方向通信チャネル４０６を使用してクライアント２０４に接続される。後述されるように、ホストリンクコントローラとクライアントリンクコントローラの両方とも、ホストコントローラ（ドライバ）又はクライアントコントローラ（レシーバ）のどちらかとして対応するように設定、調整又はプログラミングされることができる単一の回路設計を使用して集積回路として製造されることができる。これは、単一回路装置のより大規模な製造のために、より低いコストを提供する。
図６では、ＭＤＤＩリンクコントローラ５０２は、ホスト装置２０２’に取り付けられて示されており、ＭＤＤＩリンクコントローラ５０４は、クライアント装置２０４’に取り付けられて示されている。前述されたように、ホスト２０２’は一連の導線を備える双方向通信チャネル５０６を使用してクライアント２０４’に接続されている。前述されたように、ホストリンクコントローラとクライアントリンクコントローラの両方とも単一回路設計を使用して製造されることができる。
ＭＤＤＩリンク上で、又は使用されている物理的な導線上で、ホストとクライアント例えばディスプレイ装置などとの間で受け渡される信号もまた図５及び図６に図示されている。図５と図６において見られるように、ＭＤＤＩを通してデータを転送するためのプライマリ経路又は機構は、ＭＤＤＩ＿Ｄａｔａ０＋／−ＭＤＤＩ＿Ｓｔｂ＋／−と呼ばれるデータ信号を使用する。これらのそれぞれは、ケーブル内の差動ペアのワイヤ上で転送される低電圧データ信号である。インタフェース上で送信される各ビットに対しては、ＭＤＤＩ＿Ｄａｔａ０ペア又はＭＤＤＩ＿Ｓｔｂペアのどちらかでの１つの遷移しかない。これは電圧ベースの転送機構であって電流ベースではなく、従って、静的な電流消費はほぼゼロである。ホストは、クライアントディスプレイへのＭＤＤＩ＿Ｓｔｂ信号を駆動する。
データは、ＭＤＤＩ＿Ｄａｔａペア上で順方向と逆方向の両方で流れることができるが、つまりそれは双方向転送経路であるが、ホストは、データリンクのマスタ又はコントローラである。ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ−Ｓｔｂ信号経路は、雑音排除性を最大限にするために差動モードで操作される。これらのラインでの信号のためのデータレートは、ホストによって送信されるクロックのレートで決定され、約１ｋｂｐｓから４００Ｍｂｐｓ以上の範囲にわたって可変である。
２型インタフェースは、ＭＤＤＩ＿Ｄａｔａ１＋／−と呼ばれる、１型のそれを超える１つの更なるデータペア又は導線又は経路を含む。３型インタフェースは、ＭＤＤＩ＿Ｄａｔａ２＋／−及びＭＤＤＩ＿Ｄａｔａ３＋／−と呼ばれる、２型インタフェースのそれを超える２つの更なるデータペア又は信号経路を含む。４型インタフェースは、夫々、ＭＤＤＩ＿ｄａｔａ４＋／−、ＭＤＤＩ＿Ｄａｔａ５＋／−、ＭＤＤＩ＿Ｄａｔａ６＋／−、及びＭＤＤＩ＿Ｄａｔａ７＋／−と呼ばれる、３型インタフェースのそれを超える４つの更に多くのデータペア又は信号経路を含む。上記インタフェース構成の各々において、ホストは、ＨＯＳＴ＿ＰｗｒとＨＯＳＴ＿Ｇｎｄと示されるワイヤペア又は信号を使用して、クライアント又はディスプレイに電力を送ることができる。更に後述されるように、電力伝達は、もし所望されれば、使用可能である或いは他のモードのために存在するより更に少ない導体を利用するインタフェース「型(Type)」が使用されている時、幾つかの構成において、ＭＤＤＩ＿Ｄａｔａ４＋／−、ＭＤＤＩ＿Ｄａｔａ５＋／−、ＭＤＤＩ＿Ｄａｔａ６＋／−、又はＭＤＤＩ＿Ｄａｔａ７＋／−の導線上で対処されることもできる。電力伝達は、通常は外部モードに対し利用され、いくつかのアプリケーションは異なるかもしれないが、内部モードに対しては通常必要ない。
様々なモードについてＭＤＤＩリンク上でホストとクライアント（ディスプレイ）との間で受け渡される信号の要約が、インタフェースタイプに従って、以下の表Ｉに示される。
Figure 2007528681
ホストからの転送のためのＨＯＳＴ＿Ｐｗｒ／Ｇｎｄ接続が外部モードに対し通常提供されることにも注意する。内部アプリケーション又は動作モードは、当業者には明らかであるように、電力を他の内部リソースから直接に引き出し、電力分配を制御するためにＭＤＤＩを使用しないクライアントを一般に有する、従ってこのような分配はここでは更に詳細には説明されない。然しながら、当業者によって理解されるように、例えば何らかの種類の電力制御、同期、又は相互接続の便利さを可能にするために、ＭＤＤＩを通して電力が配分されるようにすることは確かに可能である。
上記構造及び動作を実現するために通常使用されるケーブル布線は、名目上長さ約１．５メートル、一般には２メートル又はそれより小さい、そしてそれぞれが同様にマルチストランド３０ＡＷＧワイヤである３本のツイストペアの導線を含む。フォイルシールドカバリングが、巻き付けられるか、そうでなければ追加のドレイン線として３本のツイストペアの上に形成される。技術的によく知られているように、ツイストペアとシールドドレイン導線は、クライアントコネクタにおいてクライアント用のシールドに接続されているシールドで終端し、又、ケーブル全体を覆う絶縁層がある。ワイヤは、ＨＯＳＴ＿ＧｎｄとＨＯＳＴ＿Ｐｗｒ、ＭＤＤＩ＿Ｓｔｂ＋とＭＤＤＩ＿Ｓｔｂ−、ＭＤＤＩ＿Ｄａｔａ０＋とＭＤＤＩ＿Ｄａｔａ０−、ＭＤＤＩ＿Ｄａｔａ１＋とＭＤＤＩ＿Ｄａｔａ１−、等のようにペアにされる。然しながら、技術的に理解されるように、固有のアプリケーションに応じて、本発明の実施形態を実現するために様々な導線とケーブル布線とが使用されることが出来る。例えば、幾つかのアプリケーションにおいては、ケーブルを保護するために、より厚い外側コーティング或いはメタリック層でさえ使用されてよく、一方では、他のアプリケーションには、より薄い、よりフラットな導電性リボンタイプ構造体が良く適しているかもしれない。
Ｄ．データタイプ及びレート
一連のユーザ経験とアプリケーションにとって有用なインタフェースを達成するために、モバイルデジタルデータインタフェース（ＭＤＤＩ）は、制御情報、及びその組み合わせと共に、様々なクライアントと、ディスプレイ情報、音声トランスデューサ、キーボード、ポインティングデバイス、そして、モバイル通信、計算、又はディスプレイ装置に統合されるかもしれない、又は、と協力して動作する可能性のある、多くの他の入力又は出力装置と、に対しサポートを提供する。ＭＤＤＩは、最小数のケーブル又は導線を使用して、順方向又は逆方向の何れかでホストとクライアントとの間で行き来する様々な潜在的なタイプのデータストリームに対処できるように設計される。等時性ストリームと非同期ストリーム（更新）の両方がサポートされる。集合データレートが、最大シリアルレートと利用されるデータペアの数により制限される最大所望ＭＤＤＩリンクレート以下である限り、データタイプの多くの組み合わせが考えられる。これらは、以下の表ＩＩと表ＩＩＩに一覧表示されるそれらのアイテムを含むことがあるであろうが、これらに限定されない。
Figure 2007528681
Figure 2007528681
インタフェースは固定されていないが、将来のシステム柔軟性のためにユーザ定義データを含む種々の情報「タイプ」の転送をサポートできるように拡張可能である。対処されるデータの具体例は、全画面又は部分画面ビットマップフィールド又は圧縮ビデオのいずれかの形式のフルモーションビデオ、電力を節約しインプリメンテーション費用を削減するための低速の静的ビットマップ、種々の解像度又はレートでのＰＣＭ又は圧縮音声データ、ポインティングデバイス位置及び選択、そして、まだ定義されていない機能のためのユーザ定義可能なデータ、である。このようなデータはまた、装置機能を検出する又は操作パラメータを設定するために制御情報又は状態情報と共に転送されてもよい。
本発明の実施形態は、映画（ビデオディスプレイ及び音声）を見ること、個人ビューイングが制限されたパソコン（グラフィックディスプレイ、ビデオと音声とが結合されることもある）を使用すること、ビデオゲームをＰＣ、コンソール、又はパーソナルデバイス（動画グラフィックスディスプレイ又は同期ビデオと音声）でプレイすること、ビデオ電話（双方向低速ビデオと音声）、静止デジタル写真用カメラ、又はデジタルビデオ画像を取り込むためのカムコーダ、の形で装置を使用してインターネットを「サーフィンすること」、電話、コンピュータ、又はプレゼンテーションを行うためにプロジェクタにドッキングされるか、ビデオモニタ、キーボード及びマウスに接続されるデスクトップドッキングステーションにドッキングされるＰＤＡ、を使用すること、そして、無線ポインティングデバイスとキーボードデータとを含む携帯電話、スマートフォン、又はＰＤＡによる生産性の強化又はエンターテインメント使用のため、を含む、但しこれらに限定されない、データ転送での使用のための技術を進展させる。
ワイヤライン又はケーブル型リンクとして通常構成される通信又は転送リンク上で大量のＡ−Ｖ型データを提供する、という観点で、後述されるような高速データインタフェースが示される。然しながら、信号構造、プロトコル、タイミング、又は転送機構は、もしそれが所望されるレベルのデータ転送を持続できる場合は、光媒体又は無線媒体の形をとるリンクを提供するように調整されることができるであろうことは容易に明らかになる。
ＭＤＤＩ信号は、基本的な信号プロトコル又は構造のための共通フレームレート（ＣＦＲ）として知られている概念を使用する。共通フレームレートを使用する背景にある考えは、マルチストリーム用のフレームタイミング又はクロックを取り出すために使用されることが出来るレートでサブフレームヘッダパケットを送ることにより、同時等時性データストリームに同期パルスを与えることである。サブフレームヘッダパケットが送られるレートは、共通フレームレートである。クライアント装置はこの共通フレームレートを時間基準として使用できる。低ＣＦＲは、サブフレームヘッダを送信するためにオーバヘッドを減少させることによりチャネル効率を高める。他方、高ＣＦＲは待ち時間を減少させ、音声サンプル用により小さく、融通の利くデータバッファを可能にする。本発明のＣＦＲは、動的にプログラム可能であり、特定のアプリケーションで使用される等時性ストリームに適切である多くの値の内の１つとして設定されてよい。つまり、ＣＦ値は、所望されるように、既定のクライアントとホストの構成に最も適するように選択される。
ビデオ又はミクロディスプレイ用のようなアプリケーションと共に使用されることが最もありそうである等時性データストリーム用の、調整可能又はプログラム可能である、サブフレームごとに通常必要とされるバイト数が、表ＩＶに示される。
Figure 2007528681
サブフレームあたりのバイトの分数のカウントは、簡易プログラマブルＭ／Ｎカウンタ構造を使用して容易に得られる。例えば、サブフレームあたり２６−２／３バイトのカウントは、各々が２６バイトを含む１つのサブフレームによって後に続かれる、２７バイトを含む２つのフレームを転送することによって実現される。より小さいＣＦＲは、サブフレームあたりバイトの整数を生じさせるために選択されてよい。然しながら、一般的に言えば、ハードウェア内で簡易なＭ／Ｎカウンタを実現することは、本発明の実施形態の一部又は全てを実現するために使用される集積回路チップ又は電子モジュール内では、より大きい音声サンプルＦＩＦＯバッファに必要とされる面積よりも少ない面積を必要とするはずである。
異なるデータ転送レートとデータタイプの影響を示す例示的なアプリケーションは、カラオケシステムである。カラオケの場合、システムでは１エンドユーザ又はユーザがミュージックビデオプログラムに沿って歌う。歌の歌詞は、画面上のどこか、通常は最下部に表示され、従ってユーザは、歌われるべき歌詞を、そして歌のタイミングを大まかに、知る。このアプリケーションは、不定期にグラフィック更新されるビデオディスプレイと、ユーザの１つの又は複数の声をステレオ音声ストリームでミキシングすることを必要とする。
３００Ｈｚの共通フレームレートを前提とする場合は、このとき、各サブフレームは、クライアントへの順方向リンク上で９２，１６０バイトのビデオコンテンツと５８８バイトの音声コンテンツ（ステレオにおける、１４７個の１６ビットのサンプルに基づく）からなり、平均２６．６７（２６−２／３）バイトの音声がマイクからモバイルカラオケ機械に送り返される。非同期パケットがホストとおそらくヘッドマウント式のディスプレイの間で送信される。これは、１／３０ｔｈの秒間隔又は期間で歌詞テキストと共に更新されるボトム クォータ−画面高さ(the bottom quarter-screen height)と、歌詞が更新されていない時にサブフレームの中で送られる他のいろいろな制御及びステータスコマンドを含む。
表Ｖは、カラオケ例のサブフレーム内でデータがどのように割り当てられるのかを示す。使用されている合計レートは約２７９Ｍｂｐｓであるように選択される。２８０Ｍｂｐｓというわずかにより高いレートは、サブフレームあたり別の約４００バイトのデータが転送されるのを可能にし、臨時の制御メッセージと状態メッセージの使用を可能にする。
Figure 2007528681
ＩＩＩ．（続き）高レートデジタルデータインタフェースシステムアーキテクチャ
Ｅ．リンク層
ＭＤＤI高速シリアルデータ信号を使用して転送されるデータは、次々にリンクされる時分割パケットのストリームからなる。たとえ送信側装置が送信するデータを有さない時でも、ＭＤＤＩリンクコントローラは、通常自動的にフィラーパケットを送信し、このようにしてパケットのストリームを維持する。単純なパケット構造の使用は、ビデオ信号又は音声信号或いはデータストリームのための信頼性の高い等時性タイミングを確実にする。
パケットのグループは、サブフレームと呼ばれる信号エレメント又は構造の中に含まれ、サブフレームのグループは、メディアフレームと呼ばれる信号エレメント又は構造の中に含まれる。サブフレームは、そのそれぞれのサイズとデータ転送用途に応じて１つ又は複数のパケットを含み、メディアフレームはもう１つのサブフレームを含む。ここに示される実施形態によって使用されるプロトコルにより提供される最大サブフレームは約２３２−１、つまり４，２９４，９６７，２９５バイトであり、最大メディアフレームサイズは約２１６−１、つまり６５，５３５サブフレームとなる。
特殊なサブフレームヘッダパケットは、後述されるように、各サブフレームの始まりに表示される固有の識別子を含む。その識別子はまた、ホストとクライアントとの間の通信が開始される時にクライアント装置でフレームタイミングを獲得するために使用される。リンクタイミング獲得は以下に更に詳細に説明される。
通常、ディスプレイ画面は、フルモーションビデオが表示されている時はメディアフレームあたりに一度更新される。該ディスプレイフレームレートは該メディアフレームレートと同じである。リンクプロトコルは、所望されるアプリケーションに応じ、ディスプレイ全体にわたってフルモーションビデオを、或いは静的画像によって囲まれるフルモーションビデオコンテンツの小さな領域だけを、サポートする。ウェブページ又はｅメールをビューイングすることのような、幾つかの低電力のモバイルアプリケーションでは、ディスプレイ画面はときおりしか更新される必要がないかもしれない。それらの状況では、単一のサブフレームを送信し、そのあと、電力消費を最小限にするためにリンクをシャットダウンする、又は非アクティブ化することが有利である。インタフェースはまた、ステレオビジョンのような効果もサポートし、グラフィックスプリミティブを処理する。
サブフレームは、システムが周期ベースで優先順位が高いパケットの伝送をイネーブルにすることを可能にする。これは、同時等時性ストリームが最小量のデータバッファリングと共存するのを可能にする。これは、実施形態がディスプレイプロセスに提供する１つの利点であり、複数のデータストリーム（ビデオ、音声、制御、状態、ポインティングデバイスデータ等の高速通信）が、本質的に１つの共通したチャネルを共用するのを可能にする。それは、比較的に少ない信号を使用して情報を転送する。また、それはまた、ディスプレイ-技術−特殊作用が、ＣＲＴモニタのための、或いは他のクライアント-技術−特殊作用のための水平同期パルス及びブランキング間隔のように、存在することを可能にする。
Ｆ．リンクコントローラ
図５及び図６に示されるＭＤＤＩリンクコントローラは、ＭＤＤＩデータとストローブ信号を受信するために使用される差動ラインレシーバを除き、完全にデジタルなインプリメンテーションとなるように製造又は組み立てられる。然しながら、差動ラインドライバと差動ラインレシーバでさえ、ＣＭＯＳ型ＩＣを作成する時のように、リンクコントローラと共に同じデジタル集積回路内で実現されることができる。アナログ機能又は位相ロックループ（ＰＬＬ）は、ビット回復のために、或いはリンクコントローラ用のハードウェアを実現するために、必要とされない。ホストリンクコントローラとクライアントリンクコントローラは、リンク同期のために状態機械を含むクライアントインタフェースを除き、非常に類似した機能を含む。従って、本発明の実施形態は、ホスト又はクライアントのいずれかとして構成されることができる単一のコントローラ設計又は回路を作成できるという実用的な利点を可能にし、全体として、リンクコントローラの製造コストを削減できる。
ＩＶ．インタフェースリンクプロトコル
Ａ．フレーム構造
パケット転送のために順方向リンク通信を実現するために使用される信号プロトコル又はフレーム構造が、図７に図示されている。図７に示されているように、情報又はデジタルデータは、パケットとして知られるエレメントにグループ化される。複数のパケットは、「サブフレーム」と呼ばれるものを形成するために、同様に共にグループ化され、複数のサブフレームは、「メディア」フレームを形成するために、同様に共にグループ化される。フレームの形成及びサブフレームの転送を制御するために、各サブフレームは、サブフレームヘッダパケット（ＳＨＰ）と呼ばれる、特別に予め定義されたパケットで開始する。
ホスト装置は、既定の転送に使用されるデータレートを選択する。このレートは、ホスト、又はホストによりソースから取り出されるデータ、の最大転送機能と、クライアント又はデータが転送されている先の他の装置、の最大機能と、の両方に基づいてホスト装置によって動的に変更されることが出来る。
ＭＤＤＩ又は本発明の信号プロトコルのために設計された、又は、の能力がある、と共に作業する、受取人クライアント装置は、それが使用できる最大の又は現在最大のデータ転送レートを決定するために、ホストにより照会できる、或いは、使用可能なデータタイプ及びサポートされている特徴と同様に、デフォルトのより低速な最小レートも使用されてよい。この情報は、更に後述されるように、クライアント機能パケット(a Client Capability Packet)（ＤＣＰ）を使用して転送できるであろう。クライアントディスプレイ装置は、事前に選択された最小データレートで又は最小データレート範囲内で、インタフェースを使用してデータを転送することが或いは他の装置と通信することができ、そして、ホストは、クライアント装置の完全な機能を突き止めるためにこの範囲内のデータレートを使用して照会を実行する。
クライアントのビットマップ及びビデオフレームレート機能の性質を定義する他の状態情報が、ステータスパケットの中でホストに転送されることができるので、ホストはインタフェースを、実用的であるように効率的に又は最適に、或いは任意のシステム制約の中で所望されるように構成できる。
ホストは、現在のサブフレームの中に転送されるデータがない（それ以上の）時に、或いはホストが順方向リンクに選ばれるデータ伝送レートに後れを取らないほど十分なレートで転送できない時に、フィラーパケットを送信する。各サブフレームはサブフレームヘッダパケットで始まるため、前のサブフレームの最後は、正確に前のサブフレームを充填するパケット（多分フィラーパケット）を含む。データをのせて運ぶパケット自体のための余地が欠如している場合は、フィラーパケットは、多分、サブフレーム中の最後のパケットである、或いは直前のサブフレームの最後でサブフレームヘッダパケットの前にある。各パケットがそのサブフレーム内で送信されるための十分な空間がサブフレーム内に残っていることを保証することは、ホスト装置における制御動作のタスクである。同時に、いったんホスト装置がデータパケットの送信を開始すると、ホストは、データアンダーラン状況(a data under-run condition)を生じさせずにフレーム内でそのサイズのパケットを無事に完了できなければならない。
実施形態の一態様においては、サブフレーム伝送は２つのモードを有する。１つのモードは、周期的なサブフレームモード、或いはライブビデオと音声ストリームを送信するために使用される周期的なタイミングエポックである。このモードでは、サブフレーム長は非ゼロであると定義される。第２のモードは、新しい情報が入手可能である時にフレームがクライアントにビットマップデータを提供するために使用される非同期或いは非周期モードである。このモードはサブフレームヘッダパケット内でサブフレーム長をゼロに設定することによって定義される。周期モード使用時、サブフレームパケット受信は、クライアントが順方向リンクフレーム構造に同期した時に開始してよい。これは、図４９又は図６３に関して後述される状態図に従って定義された「同期中」状態に対応する。非同期非周期サブフレームモードでは、第１のサブヘッダパケットが受信された後に受信が開始する。
Ｂ．全体的なパケット構造
本実施形態により実現される、データ転送のための通信又はプロトコル又は方法又は手段を開発するために使用されるパケットのフォーマット又は構造が、インタフェースが拡張可能でありそして更なるパケット構造が所望されるとおりに追加できるということに留意しつつ、以下に示されている。パケットは、インタフェースにおけるそれらの機能、つまり、それらが転送する、或いは関連する、コマンド、情報、値、又はデータの点で、様々な「パケットタイプ」に呼ばれ、或いは分類される。従って、各パケットタイプは、転送されているパケットとデータを操作する上で使用される既定のパケット(a given packet)の予め定義されたパケット構造(a pre-defined packet structure)を示す。容易に明らかとなるように、パケットは事前に選択された長さを有するか、或いはそれらの夫々の機能に応じて可変又は動的に変更可能な長さを有してよい。パケットはまた、同じ機能が依然として実現されるとしても、標準規格への承認の間にプロトコルが変更される時に発生するように、異なる名称も持つことができるであろう。様々なパケットにおいて使用されるバイト又はバイト値は、マルチビット（８ビット又は１６ビット）の符号なし整数として構成される。その「タイプ」名称と共に使用され、タイプ順で一覧表示されている、パケットのまとめは、表ＶＩ−１からＶＩ−４に示される。
各表は、説明及び理解を容易にするために、全体的なパケット構造の中のパケットの一般的な「タイプ」を表す。これらのグループ分けによって、本発明に対し、含有され又は表わされる制限又は他の影響はなく、パケットは、所望されるとおりに多くの他の様式で編成されることができる。パケットの転送が有効であると見なされる方向も注記される。
Figure 2007528681
Figure 2007528681
Figure 2007528681
Figure 2007528681
本文の他の説明から明らかであることは、サブフレームヘッダ(the Sub- frame Header)、フィラー(Filler)、逆方向カプセル化(Reverse Encapsulation)、リンクシャットダウン(Link Shutdown)、クライアント機能(Client Capability)、それにクライアント要求及びステータス(Client Request and Status)のパケットは、それぞれ、外部モード動作のための通信インタフェースの多くの実施形態において、非常に重要であると見なされる、或いは必要とされる、ということである。然しながら、逆方向カプセル化、リンクシャットダウン、クライアント機能、それにクライアント要求及びステータスのパケットは、内部モード動作に対しては、オプションである可能性があり、或いは、オプションと見なされる可能性が高い。このことは、通信パケットの縮小セットを用いた非常に高速でのデータ通信と、対応する制御及びタイミングの簡略化とを可能にする、更に別のタイプのＭＤＤＩプロトコルを作り出す。
パケットは、図８において図示される、パケット長フィールド、パケットタイプフィールド、データバイトフィールド（複数の場合がある）、及びＣＲＣフィールドを備える、最小のフィールドの共通の基本的な構造又は全体的な集合を有する。図８において示されるように、パケット長フィールドは、パケットの中のビット総数、又はパケット長フィールドとＣＲＣフィールドとの間のその長さを指定するマルチビット値又はマルチバイト値の形をした情報を含む。一実施形態では、パケット長フィールドは、パケット長を指定する１６ビット又は２バイト幅の符号なし整数を含む。パケットタイプフィールドは、パケットの中に含まれる情報のタイプを指定する別のマルチビットフィールドである。例示的な実施形態では、これは、１６ビットの符号なし整数の形を取る１６ビット又は２バイト幅の値であり、ディスプレイ機能、ハンドオフ、ビデオストリーム又は音声ストリーム、状態等のようなデータタイプを指定する。
第３のフィールドは、ホスト装置とクライアント装置の間でそのパケットの一部として転送又は送信されているビット又はデータを含むデータバイトフィールドである。データのフォーマットは、転送されているデータの特定のタイプに従い各パケットタイプに対し詳細に定義され、又、各々がそれ自体のフォーマット要件を備える一連の追加のフィールドに分離されてよい。つまり、各パケットタイプは、この部分又はフィールドの定義されたフォーマットを有するであろう。最後のフィールドは、パケット内で情報の完全性を確認するために使用される、データバイトフィールド、パケットタイプフィールド、及びパケット長フィールド上で計算される１６ビットサイクリックリダンダンシーチェックの結果を含むＣＲＣフィールドである。言い換えると、ＣＲＣフィールド自体を除きパケット全体で計算される。クライアントは通常、検出されたＣＲＣエラーの総カウントを保存し、このカウントをクライアント要求及びステータスパケットでホストに報告する（更に以下を参照）。
一般的には、これらのフィールド幅と編成は、２バイトフィールドを偶数バイト境界で位置合わせされた状態に、及び４バイトフィールドを４バイト境界で位置合わせされた状態に保つように設計される。これにより、大部分の或いは通常に使用されるプロセッサ又は制御回路について遭遇されるデータタイプ位置合わせルールに違反することなく、パケット構造が、ホストとクライアントの、或いは、に関連付けられた、メインメモリのスペースの中に容易に組み込まれるのを可能にする。
パケットの転送中、フィールドは、最初に最下位ビット（ＬＳＢ）で開始して送信され最後に送信される最上位ビット（ＭＳＢ）で終了する。長さが１バイトを超えるパラメータは、最下位バイトを最初に使用して送信され、その結果、ＬＳＢが最初に送信される、より短いパラメータに対して使用されるのと同じビット伝送パターンが、長さ８ビットよりも大きなパラメータに対し使用されることになる。各パケットのデータフィールドは、通常、それらが以下の後の項で定められる順序で送信され、一覧表示されている最初のフィールドが最初に送信され、記述されている最後のフィールドが最後に送信される。ＭＤＤＩ＿Ｄａｔａ０信号経路上のデータは、モード１型、２型、３型又は４型のどれかでインタフェース上で送信されるバイトのビット「０」と位置合わせされる。
ディスプレイ用にデータを操作するとき、ピクセルのアレイのためのデータは、エレクトロニクス技術において従来から行なわれているように、最初に行、次に列の単位で送信される。言い換えると、ビットマップの中の同じ行に現れる全てのピクセルは、最も左のピクセルが最初に送信され、最も右のピクセルが最後に送信される順序で送信される。行の最も右のピクセルが送信された後、そのときシーケンスの中の次のピクセルは、続く行の最も左のピクセルである。他の構成が必要に応じて適応されることができるが、ピクセルの行は通常、大部分のディスプレイの場合上から下への順で送信される。更に、ビットマップを処理する上で、ここで従われる従来の手法は、ビットマップの左上角をロケーション又はオフセット「０、０」と名付けることによって基準点を定めることである。ビットマップの中で位置を定める又は決定するために使用されるＸ及びＹ座標は、それぞれ、ビットマップの右と下部に近づくにつれて値が増加する。第１の行と第１の列（画像の左上角）はゼロのインデックス値で開始する。Ｘ座標の大きさは、ディスプレイのユーザによって見られるときに画像の右側に向かって大きくなり、Ｙ座標の大きさは画像の下部に向かって大きくなる。
ディスプレイウィンドウは、ビットマップの可視部分、つまり物理的なディスプレイ媒体上でユーザによって見られることができるビットマップの中のピクセルの部分である。ディスプレイウィンドウ及びビットマップが同じサイズである場合が多い。ディスプレイウィンドウの左上角は常にビットマップピクセルロケーション０、０を表示する。ディスプレイウィンドウの幅はビットマップのＸ軸に対応し、この実施形態のディスプレイウィンドウ幅は、対応するビットマップの幅よりも小さい又は等しい。ウィンドウの高さはビットマップのＹ軸に対応し、この実施形態のディスプレイウィンドウ高さは、対応するビットマップの高さよりも小さい又は等しい。ディスプレイウィンドウ自体は、それがビットマップの可視部分として定義されるだけであるので、プロトコルの中ではアドレス指定可能ではない。
ビットマップとディスプレイウィンドウとの関係は、コンピュータ、電子技術、インターネット通信、及び他のエレクトロニクス関連の技術でよく知られている。従って、これらの原理についての更なる検討及び説明はここでは提供されない。
Ｃ．パケット定義
１．サブフレームヘッダパケット
サブフレームヘッダパケットは、あらゆるサブフレームの最初のパケットであり、図９に図示されているような基本的な構造を有する。サブフレームヘッダパケットは、ホスト−クライアント同期のために使用され、あらゆるホストはこのパケットを作成できなければならないが、一方、あらゆるクライアントはこのパケットを受信し、解釈できなければならない。図９における一実施形態で分かるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、固有のワードフィールド、予約１フィールド、サブフレーム長フィールド、プロトコルバージョンフィールド、サブフレームカウントフィールド及びメディアフレームカウントフィールドを、通常その順序で有するように構造化されている。一実施形態では、このタイプのパケットは通常１５３５９型（０ｘ３ｂｆｆ １６進）パケットとして識別され、パケット長フィールドを含まずに２０バイトという事前に選択された固定長を使用する。
パケットタイプフィールドと固有のワードフィールドは各々２バイト値（１６ビットの符号なし整数）を使用する。これらの２つのフィールドの４バイトの組み合わせは共に、優れた自己相関のある３２ビットの固有のワードを形成する。一実施形態では、実際の固有のワードは０ｘ００５ａ３ｂｆｆであり、ここでは下位の１６ビットはパケットタイプとして最初に送信され、最上位の１６ビットが後に送信される。
予約１フィールドは、将来の使用のために予約される２バイトを含み、通常この時点で全てのビットがゼロに設定されて構成される。このフィールドの１つの目的は、次の２バイトのフィールドを１６ビットのワードアドレスに位置合わせさせ、４バイトのフィールドを３２ビットのワードアドレスに位置合わせさせることである。最下位バイトは、ホストが複数のクライアント装置をアドレス指定できるかどうかを示すために予約される。このバイトに対しゼロの値が、ホストが単一のクライアント装置とのみ動作できることを示すために、予約される。
サブフレーム長フィールドは、４バイトの情報又は値を含み、サブフレームあたりのバイト数を指定する。一実施形態では、このフィールド長は、リンクがシャットダウンされアイドル常態になる前に、１つのサブフレームだけがホストによって送信されることを示すためにゼロに設定されてよい。このフィールドの値は、あるサブフレームから次のサブフレームに遷移する時に、「オンザフライで」動的に変更されることができる。この機能は、等時性データストリームに対処するために同期パルスにおいて軽微なタイミング調整を行うために有効である。もしサブフレームヘッダパケットのＣＲＣが有効ではない場合、そのときは、リンクコントローラは、現在のサブフレームの長さを推定するために以前の知られた良好なサブフレームヘッダパケットのサブフレーム長を使用しなければならない。
プロトコルバージョンフィールドは、ホストによって使用されるプロトコルバージョンを指定する２バイトを含む。プロトコルバージョンフィールドは、プロトコルの第１のバージョン又はカレントバージョンを使用されているとして指定するために「０」に設定されてよい。この値は、新しいバージョンが作成されるにときに経時変化し、そして、幾つかのバージョンフィールドに対しては既に「１」の値に更新されている。バージョン値は、多分或いは通常は、知られているように、ＭＤＤＩのようなインタフェースに対応する承認された標準規格ドキュメントの現在バージョン番号に従う。
サブフレームカウントフィールドは、メディアフレームの開始以来送信されているサブフレームの数を示すシーケンス番号を指定する２バイトを含む。メディアフレームの第１のサブフレームは、ゼロのサブフレームカウントを有する。メディアフレームの最後のサブフレームはｎ−１の値を有し、この場合ｎはメディアフレームあたりのサブフレーム数である。サブフレームカウントフィールドの値は、ゼロのカウントを有するメディアフレームの第1のサブフレームを除いて、その前のサブフレームパケットの中に送られたサブフレームカウントにプラス１したものである。もしサブフレーム長がゼロ（非周期サブフレームを示す）に設定されている場合はサブフレームカウントもまたゼロに等しく設定されている、ということに注意が必要である。
メディアフレームカウントフィールドは、転送されている現在のメディアアイテム又はデータの開始以来送信されているメディアフレームの数を示すシーケンス番号を指定する４バイト（３２ビットの符号なし整数）を含む。メディアアイテムの第１のメディアフレームは、ゼロのメディアフレームカウントを有する。メディアフレームカウントは、各メディアフレームの第１のサブフレームの直前にインクリメントし、最大メディアフレームカウント（例えば、メディアフレーム数２３−１＝４，２９４，９６７，２９５）が使用された後にゼロにラップバックする（ｗｒａｐｓ ｂａｃｋ）。メディアフレームカウント値は、通常、エンドアプリケーションのニーズに合うようにホストによっていつでもリセットされてよい。
２．フィラーパケット
フィラーパケットは、順方向リンク又は逆方向リンクのどちらかで送信するために利用可能な他の情報がない時にクライアント装置に、又はから、転送されるパケットである。必要とされる時に他のパケットを送信する上で最大の柔軟性を可能にするために、フィラーパケットが最小長を有することが推奨される。サブフレーム又は逆方向リンクカプセル化パケットのまさに最後に（以下を参照）、リンクコントローラは、パケット完全性を維持するために、残りの空間を充填するためのフィラーパケットのサイズを設定する。フィラーパケットは、ホスト又はクライアントが送信又は交換する情報を持たない時に、リンク上でタイミングを維持するために有効である。あらゆるホストとクライアントは、インタフェースを効果的に使用するために、このパケットを送受できる必要がある。
フィラーパケットのフォーマット及びコンテンツの例示的な実施形態は図１０に示されている。図１０において示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、フィラーバイトフィールド、及びＣＲＣフィールドを有するように構造化されている。一実施形態では、このタイプのパケットは通常、２バイトタイプフィールドにおいて示される、タイプ０として識別される。フィラーバイトフィールドの中のビット又はバイトは、フィラーパケットが所望される長さになることを可能とするために、可変数の全ゼロビット値を備える。最小のフィラーパケットは、このフィールドにバイトを含まない。すなわち、パケットは、パケット長、パケットタイプ、及びＣＲＣのみからなり、一実施形態では、６バイトの事前に選択された固定長、又は４のパケット長値を使用する。ＣＲＣ値は、何らかの他のパケットタイプにおいて排除されてよい、パケット長を含むパケットの中のすべてのバイトについて決定される。
３．ビデオストリームパケット
ビデオストリームパケットは、通常、ディスプレイ装置の矩形領域を更新するために、ビデオデータを搬送する。この領域のサイズは、単一のピクセルと同程度に小さいか、ディスプレイ全体と同じ程度大きくてよい。ストリームを表示するために必要とされる全てのコンテキストはビデオストリームパケット内に含まれるので、同時に表示され、システムリソースによって制限される、ほぼ無制限な数のストリームがありうる。ビデオストリームパケット（ビデオデータフォーマット記述子）の一実施形態のフォーマットは、図１１に示される。図１１において見られるように、一実施形態では、このタイプのパケットは、パケット長（２バイト）フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔ ＩＤフィールド、ビデオデータ記述子フィールド、ピクセルディスプレイ属性フィールド、Ｘ左端縁フィールド、Ｙ上部端縁フィールド、Ｘ右端縁フィールド、Ｙ下部端縁フィールド、Ｘ開始フィールドとＹ開始フィールド、ピクセルカウントフィールド、パラメータＣＲＣフィールド、ピクセルデータフィールド及びピクセルデータＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、２バイトタイプフィールドにおいて示される１６型として識別される。一実施形態では、クライアントは、クライアント機能パケットのＲＧＢフィールド、白黒フィールド、及びＹ Ｃｒ Ｃｂ機能フィールドを使用して、ビデオストリームパケットを受信する能力を示す。
一実施形態では、ｂＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤに対し予約される２バイトの情報を含む。これは新規に開発された通信プロトコルであるので、実際のクライアントＩＤは未だ知られておらず或いは十分に通信可能ではない。従って、このフィールドの中のビットは、このようなＩＤ値が知られるまで通常ゼロに等しく設定されている、なおＩＤ値が知られる時点ではＩＤ値は、当業者に明らかであるように挿入され又は使用されることができる。同じプロセスが、後述されるクライアントＩＤフィールドに一般的には当てはまる。
上述されたように、例示的なビデオデータ記述子フィールドの動作を実現するために使用されるフォーマット及びコンテンツは、図１２Ａから図１２Ｅに示される。図１２Ａから図１２Ｅでは、ビデオデータフォーマット記述子フィールドは、本パケットの本ストリームにおけるピクセルデータの中の各ピクセルのフォーマットを指定する１６ビットの符号なし整数の形の２バイトを含む。異なるビデオストリームパケットが異なるピクセルデータフォーマットを使用できる、すなわち、ビデオデータフォーマット記述子において異なる値を使用できる、そして同様に、ストリーム（ディスプレイの領域）がそのデータフォーマットをオンザフライで変更できる、ということは可能である。ピクセルデータフォーマットは、クライアント機能パケットにおいて定義されるようなクライアントの有効なフォーマットの内の少なくとも１つに従わなければならない。ビデオデータフォーマット記述子は、一定のフォーマットがある特定のビデオストリームの持続期間の間に使用し続けられるという意味を暗に含まない本パケットだけのピクセルフォーマットを定義する。
図１２Ａから図１２Ｄは、ビデオデータフォーマット記述子がどのようにしてコード化されるのかを図示する。これらの図で使用されるように、又この実施形態においては、ビット［１５：１３］が図１２Ａに示されるように「０００」に等しい時、そのときビデオデータは、ピクセルあたりのビット数がビデオデータフォーマット記述子ワードのビット３から０で定義される、白黒ピクセルのアレイのみからなる。ビット１１から４は、通常、将来の使用又はアプリケーションのために予約され、そしてこの状況ではゼロに設定されている。ビット［１５：１３］がその代わりに、図１２Ｂに示されるように、値「００１」に等しい時、そのときビデオデータは、カラーマップ（パレット）を通してそれぞれが色を指定するカラーピクセルのアレイのみからなる。この状況では、ビデオデータフォーマット記述子ワードのビット５から０は、ピクセルあたりのビット数を定義し、そしてビット１１から６は、通常、将来の使用又はアプリケーションのために予約され、ゼロに等しく設定されている。ビット［１５：１３］がその代わりに、図１２Ｃに示されるように、値「０１０」に等しい時、そのときビデオデータは、赤のピクセルあたりのビット数がビット１１から８によって定められ、緑のピクセルあたりビット数がビット７から４によって定められ、そして青のピクセルあたりビット数がビット３から０によって定められる、カラーピクセルのアレイのみからなる。この状況では、各ピクセルのビットの総数は、赤、緑及び青に使用されるビット数の合計である。
然しながら、ビット［１５：１３］が、その代わりに、図１２Ｄに示されるように、値又はストリング(string)「０１１」に等しい時、そのときはビデオデータは、輝度とクロミナンス情報を備える４：２：２ＹＣｂＣｒフォーマットのビデオデータのアレイのみからなり、ここでは、ルミナンス（Ｙ）のピクセルあたりのビットの数は、ビット１１から８によって定義され、Ｃｂ成分のビット数はビット７から４によって定義され、そしてＣｒ成分のビット数はビット３から０によって定義される。各ピクセルの中のビットの総数は、赤、緑及び青に使用されるビットの数の合計である。Ｃｂ成分とＣｒ成分はＹのレートの半分で送信される。加えて、このパケットのピクセルデータ部分の中のビデオサンプルは次の通りに編成される：Ｃｂｎ、Ｙｎ、Ｃｒｎ、Ｙｎ＋１、Ｃｂｎ＋２、Ｙｎ＋２、Ｃｒｎ＋２、Ｙｎ＋３，．．、ここでは、ＣｂｎとＣｒｎはＹｎとＹｎ＋１とに関連付けられ、Ｃｂｎ＋２とＣｒｎ＋２はＹｎ＋２とＹｎ＋３とに関連付けられる、等である。
Ｙｎ、Ｙｎ＋１、Ｙｎ＋２、及びＹｎ＋３は、左から右へ単一行における４つの連続ピクセルの輝度値である。ビデオストリームパケットにより参照されるウィンドウの中の１行に奇数のピクセルがある場合（Ｘ右端縁−Ｙ左端縁＋１）は、そのとき各行の最後のピクセルに対応するＹ値には次の行の第１のピクセルのＣｂ値が続き、Ｃｒ値は、行における最後のピクセルに対して送信されない。Ｙ Ｃｂ Ｃｒフォーマットを使用するウィンドウは偶数のピクセルである幅を有することが推奨される。パケットにおけるピクセルデータは偶数のピクセルを含むべきである。それは、ピクセルデータの最後のピクセルがビデオストリームパケットヘッダに指定されるウィンドウの中の行の最後のピクセルに対応する場合、つまりピクセルデータの最後のピクセルのＸロケーションがＸ右端縁に等しい時、奇数又は偶数のピクセルを含んでよい。
ビット［１５：１３］が代わりに値「１００」に等しい時、そのときは、ビデオデータは、ピクセルあたりビット数がビデオデータフォーマット記述子ワードのビット３から０までで定義される、Ｂａｙｅｒピクセルのアレイのみからなる。ピクセルグループパターンは、図１２Ｅに示されるように、ビット５と４によって定義される。ピクセルデータの順序は、水平又は垂直であってよく、そして行又は列の中のピクセルは順方向順又は逆方向順で送信されてよく、ビット８から６までによって定義される。ビット１１から９までは、ゼロに設定されているべきである。Ｂａｙｅｒフォーマットにおけるピクセルグループの中の４個のピクセルのグループは、いくつかのディスプレイ技術において単一ピクセルと多くの場合に呼ばれるものに似ている。然しながら、Ｂａｙｅｒフォーマットの１ピクセルは、ピクセルグループモザイクパターンの４個の色つきピクセルの内の１つに過ぎない。
図において示される全ての５つのフォーマットの場合、「Ｐ」として示されるビット１２は、ピクセルデータサンプルがパック(pack)されるのか、或いはバイト位置合わせピクセルデータであるのか、を指定する。このフィールドの「０」の値は、ピクセルデータフィールドの各ピクセルがＭＤＤバイト境界とバイト位置合わせされていることを示す。「１」の値は、ピクセルデータにおける各ピクセルと各ピクセル内の各色が、その前のピクセル又は未使用のビットを残さないピクセル内の色に直面してパックされる(packed up against)ことを示す。バイト位置合わせされたピクセルデータフォーマットとパックされたピクセルデータフォーマットの相違点は図１３においてより詳細に示されており、ここでは、バイト位置合わせされたデータが、未使用の部分を残さないパックされたピクセルフォーマットと対照的に、データサブフレームの未使用の部分を残していることが、明確に分かる。
４．音声ストリームパケット
音声ストリームパケットは、クライアントの音声システムを通して、或いはスタンドアロン音声プレゼンテーション装置用に、再生される音声データを搬送する。様々な音声データストリームが、使用されている音声システムのタイプに応じて、サウンドシステムの別々の音声チャネル、例えば左前、右前、中央、左後ろ、及び右後ろ、に割り当てられてよい。音声チャネルの完全な補完物は、機能強化された空間−音響信号処理を含むヘッドセットに提供される。クライアントは、クライアント機能パケットの音声チャネル機能フィールドと音声サンプルレートフィールドを使用して音声ストリームパケットを受信する能力を示す。音声ストリームパケットのフォーマットは図１４に示されている。
図１４に示されるように、このタイプのパケットは、一実施形態において、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔ ＩＤフィールド、音声チャネルＩＤフィールド、予約１フィールド、音声サンプルカウントフィールド、サンプルあたりビット及びパッキングフィールド、音声サンプルレートフィールド、パラメータＣＲＣフィールド、デジタル音声データフィールド及び音声データＣＲＣフィールドを有するように構造化されている。一実施形態では、このタイプのパケットは、通常３２型パケットとして識別される。
ｂＣｌｉｅｎｔ ＩＤフィールドは、以前に使用されたように、クライアントＩＤに予約される２バイトの情報を含む。予約１フィールドは、将来の使用のために予約される２バイトを含み、通常、この時点で全てのビットがゼロに設定されて、構成される。
サンプルあたりビット及びパッキングフィールドは、音声データのパッキングフォーマットを指定する８ビットの符号なし整数の形を取る１バイトを含む。通常使用されているフォーマットは、ＰＣＭ音声サンプルあたりのビット数を定めるためのビット４から０用である。次にビット５は、デジタル音声データサンプルがパックされるかどうかを指定する。パックされた音声サンプルとバイト位置合わせされた音声サンプルとの相違点は、ここでは１０ビットのサンプルを使って、図１５に図示されている。「０」の値は、デジタル音声データフィールドの中の各ＰＣＭ音声サンプルがＭＤＤＩバイト境界とバイト位置合わせされていることを示し、そして「１」の値は、各連続ＰＣＭ音声サンプルがその前の音声サンプルに直面してパックされることを示す。このビットは通常、ビット４から０まで（ＰＣＭ音声サンプルあたりのビット数）の中で定義される値が８の倍数ではない時にだけ有効である。ビット７から６は将来の使用に予約され、通常、ゼロの値で設定されている。
５．予約ストリームパケット
一実施形態においては、パケットタイプ１から１５、１８から３１、及び３３から５５が、遭遇される様々なアプリケーションについて所望されるように、パケットプロトコルの将来のバージョン又は変形での使用のために定義されるストリームパケットに予約される。再度、これは、他の技術に比較して絶え間なく変わる技術及びシステム設計に直面し、ＭＤＤＩをより柔軟且つ有効にすることの一部である。
６．ユーザ定義ストリームパケット
５６型から６３型として知られている８つのデータストリームタイプが、ＭＤＤＩリンクと共に使用するために装置製造業者によって定義されてよい独自仕様のアプリケーションで使用するために予約されている。これらはユーザ定義ストリームパケットとして知られている。このようなパケットは任意の目的で使用されてよいが、ホストとクライアントは、このような使用の結果が非常によく理解されている又は知られている状況においてこのようなパケットを使用するのみにすべきである。これらのパケットタイプのためのストリームパラメータ及びデータの特定の定義は、このようなパケットタイプを実現する又はその使用を求める、特定の装置製造業者又はインタフェース設計者に委ねられる。ユーザ定義ストリームパケットのいくつかの例示的な使用は、試験パラメータと試験結果、工場校正データ、及び独自仕様の特殊使用データを伝達することである。一実施形態で使用されるようなユーザ定義ストリームパケットのフォーマットは、図１６に示されている。図１６に示されるように、このタイプのパケットは、パケット長（２バイト）フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔ ＩＤ番号フィールド、ストリームパラメータフィールド、パラメータＣＲＣフィールド、ストリームデータフィールド及びストリームデータＣＲＣフィールドを有するように構造化されている。
７．カラーマップパケット
カラーマップパケットは、クライアントのために色を提示するために使用されるカラーマップルックアップテーブルのコンテンツを指定する。いくつかのアプリケーションは、単一のパケットで送信されることが出来るデータ量よりもより大きいカラーマップを必要とすることがある。これらの場合、後述されるオフセットフィールドと長さフィールドを使用することによって、各々がカラーマップの異なるサブセットを備える、複数のカラーマップパケットが転送されることができる。一実施形態でのカラーマップパケットのフォーマットが、図１７において示されている。図１７に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、カラーマップアイテムカウントフィールド、カラーマップオフセットフィールド、パラメータＣＲＣフィールド、カラーマップデータフィールド、及びデータＣＲＣフィールドを有するように構造化されている。一実施形態では、このタイプのパケットは通常、パケットタイプフィールド（２バイト）において指定されるような６４型パケット（ビデオデータフォーマット及びカラーマップパケット）として識別される。クライアントは、クライアント機能パケットのカラーマップサイズフィールドとカラーマップ幅フィールドを使用してカラーマップパケットを受信する能力を示す。
８．逆方向リンクカプセル化パケット
例示的な実施形態では、データは逆方向リンクカプセル化パケットを使用して逆方向で転送される。順方向リンクパケットは送信され、ＭＤＤＩリンク動作（転送方向）は、パケットが逆方向で送信できるようにこのパケットの真中のあたりで変更又は方向転換される。一実施形態における逆方向リンクカプセル化パケットのフォーマットは図１８に示されている。図１８に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣＬｉｅｎｔ ＩＤフィールド、逆方向リンクフラグフィールド、逆方向レート除数フィールド、方向転換１長フィールド、方向転換２長フィールド、パラメータＣＲＣフィールド、全ゼロ１フィールド、方向転換１フィールド、逆方向データパケットフィールド、方向転換２フィールド、及び全ゼロ２フィールドを有するように構造化されている。一実施形態では、このタイプのパケットは通常６５型パケットとして識別される。外部モードの場合、あらゆるホストがこのパケットを生成し、データを受信することができなければならず、そして、所望のプロトコル及び結果として生じるスピードを効率よく利用するために、あらゆるクライアントはデータを受信し、ホストに送信できなければならない。このパケットのインプリメンテーションは、内部モードの場合はオプションであるが、しかし、逆方向リンクカプセル化パケットは、ホストがデータをクライアントから受信するために使用される。
ＭＤＤＩリンクコントローラは、逆方向リンクカプセル化パケットを送信している間に特別な方法で動作する。ＭＤＤは、通常リンクのコントローラとしてホストによって常に駆動されるストローブ信号を有する。ホストは、それが逆方向リンクカプセル化パケットの方向転換部分と逆方向データパケット部分の各ビットについてゼロを送信しているかのように動作する。ホストは、２回の方向転換時間の間、及び逆方向データパケットに割り当てられる時間の間、各ビット境界でＭＤＤＩ＿Ｓｔｒｏｂｅ信号を切り換える(toggle)。すなわち、ホストは、全ゼロ１フィールドの始めから全ゼロ２フィールドの終わりまでＭＤＤＩ＿Ｓｔｂを切り換える。（これは、それがあたかも全ゼロデータを送信しているかの如くと同じ動作である。）
ホストは、ＭＤＤＩデータ信号線ドライバをディスエーブルにし、通常、方向転換１フィールドの最後のビットの前にそれらが完全にディスエーブルされてしまっていることを確実なものとし、そしてそのあと、方向転換２フィールドの間にそのラインドライバを再イネーブルにし、通常、方向転換２フィールドの最後のビットの前にドライバが完全に再イネーブルされていることを確実にする。クライアントは方向転換長パラメータを読み取り、方向転換１フィールドにおける最後のビットの直後にホストに向かってデータ信号を起動する。すなわち、クライアントは、以下の及びどこかでのパケットコンテンツの記載で具体的に記されているように、ＭＤＤＩストローブの特定の立ち上がりでリンクの中に新しいデータの時間を記録する（ｃｌｏｃｋｓ）。クライアントは、ホストにパケットを送信するために利用可能なそれが有する時間の長さを知るために、パケット長と方向転換長のパラメータを使用する。クライアントは、それがホストに送信するデータを持たない時、
フィラーパケットを送信する、或いはデータラインをゼロ状態に駆動してよい。データラインがゼロに駆動されると、ホストはこれをゼロ長（有効長ではない）を備えたパケットとして解釈し、ホストは、現在の逆方向リンクカプセル化パケットの期間の間、クライアントからそれ以上のパケットを受け入れない。
一実施形態では、クライアント要求及びステータスパケットの逆方向リンク要求フィールドは、クライアントがデータをホストに送り返すために逆方向リンクカプセル化パケットの中で必要とするバイト数をホストに知らせるために使用されてよい。ホストは、逆方向リンクカプセル化パケットにおいて、少なくともそのバイト数を割り当てることによって要求を許可しようとする。ホストは、１サブフレームで1つより多くの逆方向リンクカプセル化パケットを送信してよい。クライアントは、ほぼいつでもクライアント要求及びステータスパケットを送信してよく、ホストは１サブフレームで要求される総バイト数として逆方向リンク要求パラメータを解釈する。
９．クライアント機能パケット
ホストは、通常最適な又は所望される方法でホストからクライアントへのリンクを構成するためにそれが通信しているクライアント（ディスプレイ）の機能を知る必要がある。ディスプレイは、順方向リンク同期が取得された後にホストにクライアント機能パケットを送信することが薦められる。このようなパケットの伝送は、逆方向リンクカプセル化パケットにおいて逆方向リンクフラグを使用してホストによって要求される時に必須と見なされる。クライアント機能パケットは、ホストにクライアントの機能を知らせるために使用される。外部モードの場合、あらゆるホストはこのパケットを受信できるべきであり、又、あらゆるクライアントは、このインタフェースとプロトコルを完全に活用するために、このパケットを送信できるべきである。この状況においては、ディスプレイ、キーボード、又は他の入力／出力装置のようなクライアントの機能は、なんらかのタイプの単一のコンポーネント又はユニットへの製造又はアッセンブリの時点で、既によく定義され且つホストに知られているべきであるので、このパケットのインプレイメンテーションは、内部モードに対してはオプションである。
一実施形態におけるクライアント機能パケットのフォーマットは図１９に図示されている。図１９に示されているように、この実施形態の場合は、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔＩＤフィールド、プロトコルバージョンフィールド、最小プロトコルバージョンフィールド、データレート機能フィールド、インタフェースタイプ機能フィールド、代替（Ａｌｔ）ディスプレイナンバフィールド、予約１フィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、ディスプレイウィンドウ幅フィールド、ディスプレイウィンドウ高さフィールド、カラーマップサイズフィールド、カラーマップＲＧＢ幅フィールド、ＲＧＢ機能フィールド、白黒機能フィールド、予約２フィールド、Ｙ Ｃｒ Ｃｂ機能フィールド、Ｂａｙｅｒ機能フィールド、予約３フィールド、クライアント特徴機能フィールド、最大ビデオフレームレートフィールド、最小ビデオフレームレートフィールド、最小サブフレームレートフィールド、音声バッファ深さフィールド、音声チャネル機能フィールド、音声サンプルレート機能フィールド、音声サンプル解像度フィールド、マイクサンプル解像度フィールド、マイクサンプルレート機能フィールド、キーボードデータフォーマットフィールド、ポインティングデバイスデータフォーマットフィールド、コンテンツ保護タイプフィールド、製造業者名フィールド、製品コードフィールド、予約４フィールド、シリアル番号フィールド、製造週フィールド、製造年フィールド及びＣＲＣフィールドを有するように構造化されている。例示的な実施形態では、このタイプのパケットは通常、６６型パケットとして認識される。
１０．キーボードデータパケット
キーボードデータパケットは、クライアント装置からホストにキーボードデータを送信するために使用される。無線（又は有線）キーボードは、ヘッドマウントビデオディスプレイ／音声プレゼンテーション装置を含むが、これに限定されない多様なディスプレイ又は音声の装置と共に使用されてよい。キーボードデータパケットは、幾つかの知られたキーボードのような装置の１つから受信されるキーボードデータをホストに中継する。このパケットは、キーボードにデータを送信するために順方向リンクで使用することもまたできる。クライアントは、クライアント機能パケットのキーボードデータフィールドを使用してキーボードデータパケットを送受する能力を示す。
キーボードデータパケットのフォーマットは、図２０において示され、キーボードからの、又はキーボード用の可変数のバイトの情報を含んでいる。図２０に示されているように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔ ＩＤフィールド、キーボードデータフォーマットフィールド、キーボードデータフィールド、及びＣＲＣフィールドを有するように構造化されている。ここでは、このタイプのパケットは、通常、６７型パケットとして識別される。
ｂＣｌｉｅｎｔ ＩＤは、前述同様に、予約されたフィールドであり、ＣＲＣは、パケットの全バイトにわたって実行される。キーボードデータフォーマットフィールドは、キーボードデータフォーマットを記述する２バイト値を含む。ビット６から０までは、クライアント機能パケットにおけるキーボードデータフォーマットフィールドと同一であるべきである。この値は１２７に等しくない。ビット１５から７までは、将来の使用のために予約され、従って、現在はゼロに設定されている。
１１．ポインティングデバイスデータパケット
ポインティングデバイスデータパケットは、クライアントからホストへ、無線マウス又は他のポインティングデバイスからの位置情報を送信する、方法、構造、又は手段として使用される。データは、このパケットを使用して順方向リンク上でポインティングデバイスに送信されることもまたできる。ポインティングデバイスデータパケットの例示的なフォーマットは、図２１において示され、ポインティングデバイスから、又はポインティングデバイス用の可変数のバイトの情報を含む。図２１に示されているように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔ ＩＤフィールド、ポインティングデバイスフォーマットフィールド、ポインティングデバイスデータフィールド、及びＣＲＣフィールドを有するように構造化されている。例示的な実施形態では、このタイプのパケットは通常１バイトタイプフィールドにおける６８型パケットとして識別される。
１２．リンクシャットダウンパケット
リンクシャットダウンパケットは、ＭＤＤＩデータとストローブがシャットダウンされ、低電力消費「ハイバネーション」状態に入ることを示す方法又は手段として、ホストからクライアントに送信される。このパケットは、リンクをシャットダウンし、そして、静的ビットマップが移動通信装置からディスプレイに送信された後に、或いはホストからクライアントに転送する更なる情報が当面の間ない時に、電力を節約するために有効である。ホストがパケットを再び送信する時に通常動作が再開される。ハイバネーション後に送信される最初のパケットは、サブフレームヘッダパケットである。一実施形態のためのクライアントステータスパケットのフォーマットは、図２２において示されている。図２２に示されているように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ＣＲＣフィールド、及び全ゼロフィールドを有するように構造化される。一実施形態では、このタイプのパケットは、通常１バイトタイプフィールドにおける６９型パケットとして識別される。
パケット長フィールドは、パケット長フィールドを含まないでパケットにおけるバイトの合計数を指定するために２バイトを使用する。一実施形態においては、このパケットのパケット長は、リンクシャットダウンパケットが送られる時に有効なインタフェースタイプ又はリンクモードに依存する。従って、典型的なパケット長は、１型モードの場合は２０バイト（パケットにおいて合計２２バイト）、２型モードの場合は３６バイト（パケットにおいて合計３８バイト）、３型モードリンクの場合は６８バイト（パケットにおいて合計７０バイト）、そして４型モードの場合は１３２バイト（パケットにおいて合計１３４バイト）、になる。
全ゼロフィールドは、ホストのラインドライバをディスエーブルにする前に、クライアントがＭＤＤＩ＿Ｓｔｂのみを使ってクロックを回復することを開始するのを可能にするために十分な時間の間、ＭＤＤＩ＿Ｄａｔａ信号が論理ゼロレベルにあることを確かにするために可変数のバイトを使用する。全ゼロフィールドの長さは、リンクシャットダウンパケットが送られる時に有効なインタフェースタイプ又はリンク動作モードに依存する。全ゼロフィールドの長さは、任意のインタフェースタイプ環境に対しＭＤＤＩ＿Ｓｔｂ上に６４パルスを生成するように意図されている。従って、各インタフェースタイプに対し全ゼロ長は、１型の場合１６バイト、２型の場合３２バイト、３型の場合６４バイト、そして４型の場合１２８バイトになる。
ＣＲＣフィールドは、パケット長からパケットタイプまでの１６ビットＣＲＣのバイトを含む２バイトを使用する。
低電力ハイバネーション状態では、ＭＤＤＩ＿Ｄａｔａ０ドライバは、全ゼロフィールドの最下位ビットの後の１６番目から４８番目のＭＤＤＩ＿Ｓｔｂサイクル又はパルス後に開始する高インピーダンス状態にディスエーブルされる。２型、３型、又は４型のリンクの場合、ＭＤＤＩ＿Ｄａｔａ１からＭＤＤＩ＿ＤａｔａＰｗｒ７までの信号もまた、ＭＤＤＩ＿Ｄａｔａ０ドライバがディスエーブルされる同じ時に、高インピーダンス状態に置かれる。ホスト又はクライアントのいずれかは、他の箇所で説明されているように、ＭＤＤＩリンクをハイバネーション状態から「ウェイクアップ(wake up)」させてもよく、それが本発明にとって重要な進展であり、本発明の利点である。
全ゼロフィールドの定義において説明されたように、クライアントコントローラにおいて順序だったシャットダウンを容易にするために、ＭＤＤＩ＿Ｓｔｂは、リンクシャットダウンパケットのＣＲＣフィールドの最上位ビットに続く６４サイクルの間、切り換わる(toggle)。１つのサイクルは、「ｈｉｇｈからｌｏｗへの遷移」が続く「Ｌｏｗからｈｉｇｈへの遷移」、或いは、「ｌｏｗからｈｉｇｈへの遷移」が続く「ｈｉｇｈからｌｏｗへの遷移」である。全ゼロフィールドが送られた後に、ホスト中のＭＤＤＩ＿Ｓｔｂドライバはディスエーブルにされる。
１３．クライアント要求及びステータスパケット
ホストは、それが通常最適にホストからクライアントへのリンクを構成できるように、クライアントから少量の情報を必要とする。クライアントが１つのクライアント要求及びステータスパケットをサブフレームごとにホストに送信することが推奨される。クライアントは、それが確実にホストに配信されることを保証するために逆方向リンクカプセル化パケット内で最初のパケットとしてこのパケットを送信するべきである。このパケットを転送することもまた、逆方向リンクカプセル化パケット内で逆方向リンクフラグを使用してホストによって要求される時に達成される。クライアント要求及びステータスパケットは、ホストにエラーと状態を報告するために使用される。外部モード動作の場合、あらゆるホストは、このパケットを受信できるべきであり、そしてあらゆるクライアントは、ＭＤＤＩプロトコルを適切に又は最適に利用するために、このパケットを送信できるべきである。内部動作の場合にも、そのことが推奨されるが、それは内部ホスト及び内部クライアントであり、このパケットに対してサポートがあるべきであり、それは要求されない。
クライアント要求及びステータスパケットのフォーマットは図２３において示されている。図２３に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、逆方向リンク要求フィールド、機能変更フィールド、クライアントビジーフィールド、ＣＲＣエラーカウントフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、１バイトタイプフィールドの７０型パケットとして識別され、通常は１２バイトの事前に選択された固定長を使用する。
逆方向リンク要求フィールドは、ホストのデータを送り返すために逆方向カプセル化パケットにおいてクライアントが必要とするバイト数をホストに知らせるために使用されてよい。ホストは、逆方向リンクカプセル化パケット内で少なくともその数のバイトを割り当てることによって要求を許可しようと試みるべきである。ホストは、データに対処するためにサブフレーム内で複数の逆方向リンクカプセル化パケットを送信してよい。クライアントは、いつでもクライアント要求及びステータスパケットを送信してよく、そしてホストは、逆方向リンク要求パラメータを１つのサブフレームで要求されるバイトの総数として解釈する。逆方向リンクデータがどのようにしてホストに送り返されるのかの更なる詳細及び具体的な例が以下に示される。
１４．ビットブロック転送パケット
ビットブロック転送パケットは、任意の方向でディスプレイの領域をスクロールするための手段、構造、及び方法を提供する。この機能を有するディスプレイは、クライアント機能パケットのディスプレイ特徴機能インジケータフィールドのビット０において機能を報告する。ビットブロック転送パケットの一実施形態のためのフォーマットは、図２４において示されている。図２４に示されているように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、ウィンドウＸ移動フィールド、ウィンドウＹ移動フィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは通常７１型パケットとして識別され、そして一実施形態においては１５バイトの事前に選択された固定長を使用する。
フィールドは、移動されるウィンドウの左上角の座標のＸ値とＹ値、移動されるウィンドウの幅と高さ、及びウィンドウが水平に移動されるピクセル数、及び垂直に移動されるピクセル数をそれぞれ指定するために使用される。後者の２つのフィールドの正の値はウィンドウを右及び下方へ移動させ、それぞれ負の値は左と上に移動させる。
１５．ビットマップ領域塗りつぶしパケット
ビットマップ領域塗りつぶしパケットは、ディスプレイの領域を単一の色に容易に初期化する手段、構造、及び方法を提供する。この機能を有するディスプレイは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット１で該機能を報告する。ビットマップ領域塗りつぶしパケットのフォーマットの一実施形態は図２５において示されている。図２５に示されているように、この場合、このタイプのパケットはパケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、データフォーマット記述子フィールド、ピクセル領域塗りつぶし値フィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、１バイト型フィールドで７２型パケットとして識別され、１７バイトの事前に選択された固定長を使用する。
１６．ビットマップパターン塗りつぶしパケット
ビットマップパターン塗りつぶしパケット(Bitmap Pattern Fill Packet)は、事前に選択されたパターンにディスプレイの領域を容易に初期化する手段又は構造を提供する。この機能を有するディスプレイはクライアント機能パケットのクライアント特徴機能フィールドのビット２で該機能を報告する。水平又は垂直のパターンのオフセットが非ゼロでなければ、塗りつぶしパターンの左上角は、塗りつぶされるウィンドウの左上角と位置合わせされる。もし塗りつぶされるウィンドウが塗りつぶしパターンよりもより幅が広く、或いは背がより高い場合、そのときパターンはウィンドウを塗りつぶすために何回も水平に又は垂直に繰り返されてよい。最後に繰り返されるパターンの右又は下部は必要に応じて切り捨てられる。もしウィンドウが塗りつぶしパターンよりもより小さい場合、そのとき塗りつぶしパターンの右側又は下部はウィンドウに適合するように切り捨てられてよい。
もし水平パターンオフセットが非ゼロである場合、そのときウィンドウの左側と左側プラス水平パターンオフセットとの間のピクセルは、パターンの最も右側のピクセルで塗りつぶされる。水平パターンオフセットは、パターン幅よりは小さくあるべきである。同様に、もし垂直パターンオフセットが非ゼロである場合、そのときウィンドウの上側と上側プラス垂直パターンオフセットとの間のピクセルは、パターンの最も下側のピクセルで塗りつぶされる。垂直パターンオフセットは、パターン高さよりは小さくあるべきである。
ビットマップ塗りつぶしパケットのフォーマットの一実施形態は図２６において示されている。図２６に示されているように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウィンドウ幅フィールド、ウィンドウ高さフィールド、パターン幅フィールド、パターン高さフィールド、水平パターンオフセットフィールド、垂直パターンオフセットフィールド、データフォーマット記述子フィールド、パラメータＣＲＣフィールド、パターンピクセルデータフィールド及びピクセルデータＣＲＣフィールドを有するように構造化されている。幾つかの実施形態においては、このタイプのパケットは一般に１バイト型フィールドにおいて７３型パケットとして識別される。
１７．通信リンクデータチャネルパケット
通信リンクデータチャネルパケットは、ＰＤＡのような高水準計算機能を備えたクライアントが携帯電話又は無線データポート装置のような無線トランシーバと通信するための構造、手段、又は方法を提供する。この状況において、ＭＤＤＩリンクは、通信装置とモバイルディスプレイ付きの計算装置のと間の便利な高速インタフェースとして働いており、ここでは。このパケットはデータを該装置のオペレーティングシステムのデータリンク層でトランスポートする。例えば、このパケットは、もしウェブブラウザ、ｅメールクライアント、又はＰＤＡ全体がモバイルディスプレイの中に内蔵される場合には、使用されることができるであろう。この機能を有するディスプレイは、クライアント機能パケットのクライアント特徴機能フィールドのビット３において該機能を報告する。
通信リンクデータチャネルパケットのための一実施形態のフォーマットは、図２７に示されている。図２７に示されているように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、パラメータＣＲＣフィールド、通信リンクデータフィールド、及び通信データＣＲＣフィールドを有するように構造化されている。一実施形態においては、このタイプのパケットは、通常、タイプフィールドおいて７４型パケットとして識別される。
１８．ディスプレイパワー状態パケット
ディスプレイパワー状態パケットは、ディスプレイのようなクライアントが使用されていない又は現在活発な使用にない時に、システムパワー消費又はシステムリソース上の消費のもとを最小化するために、特定の制御されたクライアント又は関連付けられ、接続されたクライアント、又はコントローラハードウェアを低電力状態に置くための構造、手段、又は方法を提供する。このタイプのパケットは、インタフェース又はインタフェース構造及びプロトコルの外部モードの構造又は動作へのアプリケーションに最も有用である。このようなアプリケーションにおいては、外部装置がバッテリのような限られた電力リソースで作動している、或いは他の電力制約及び懸念事項、例えば限られたスペース内でのオーバヒートなど、を有している、という可能性が高く、期間又は不活発又は不使用に対し最小限の動作条件が所望される。一実施形態においては、クライアントは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット９を使用し、ディスプレイパワー状態パケットに応答する能力を示す。
ディスプレイパワー状態パケットのための一実施形態のフォーマットは、図２８において示される。図２８に示されているように、一実施形態においては、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、パワー状態フィールド、及び通信データＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、２バイト型フィールドおいて７５型パケットとして識別される。２バイトｈＣｌｉｅｎｔ ＩＤフィールドは、以前に使用されたように、Ｃｌｉｅｎｔ ＩＤ用に予約される情報又は値を含む。このフィールドは、一般に将来使用のために予約されるので、ビットを「０」に設定することにより現在の値はゼロに設定されているのであるが、それは所望の情報を転送するために当業者によって使用されることが出来る。
パワー状態フィールド、ここでは２バイト、は特定の装置、ハードウェアの構成要素、又はディスプレイのようなクライアントに関連した機器を、特定のパワー状態に設置するために使用される。ディスプレイのために使用される時は、このフィールドのビット０は、パケットがメインディスプレイに適用するのかどうか、或いは代替ディスプレイに適用するのかどうかを指定する。もしビット０が１に等しい場合は、そのときパケットはメインディスプレイに適用する。もしビット０が０に等しい場合は、そのときパケットは、ビット１１から８までによって特定された代替ディスプレイに適用する。ビット１は、将来使用のために確保され、通常はゼロに設定されている。
パワー状態フィールドのビット３から２は、ビット１１から８まで及びビット０によって選択されたディスプレイのパワー状態を特定する。ビット［３：２］が「００」の値を有する時、選択されたディスプレイは明るくされないで最小限の量の電力を消費している必要があり、そして、フレームバッファのコンテンツは、この状態の間、保持されることを保証されない。ビット［３：２］が「０１」の値を有する時、選択されたディスプレイは明るくされないで最小限の量の電力を消費しており、そして、フレームバッファのコンテンツは、この状態の間は保持されることを保証される。ディスプレイは、この状態においては状態００においてよりも多くの電力を消費するかもしれない。クライアントは、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット１０を介して状態０１をサポートする能力を示すことが出来る。パワー状態フィールドのビット［３：２］が「１０」の値を有する時、選択されたディスプレイは明るくされ、その関連したフレームバッファからの画像を表示している。ビット［３：２］の「１１」の値は、将来使用のために予約された値又は状態であり、使用されない。
ディスプレイアップリケーションの場合に最も有用であるが、このパケットの使用はディスプレイのみに本発明によって限定されず、そして、ＭＤＤＩが共に使用されている、或いはクライアントがそのために制御している又は通信している、他のハードウェアエレメントに関して、パワー制御が必要とされ得る又は所望され得る他のアプリケーション、構成、或いは状況があり得る、ということを、当業者は認識するであろう。このような状況においては、上記に開示されたビットは、同様の機能を有することができるが、理解されるであろうように、そのようなエレメントの中のメイン及び二次的なものをアクティブにしている、或いは、パワーレベルを設定している等の可能性がある。
パワー状態フィールドのビット１１から８までは、パワー状態が適用される代替ディスプレイを指定する４ビット符号なし整数を形成する。クライアントがビット１１から８までを代替ディスプレイナンバとして解釈するために、ビット０は論理ゼロ値に設定されている。もしビット０が１に等しいのであれば、このときビット１１から８まではゼロである。
ビット７から４まで及びビット１５から１２までは、将来使用のために確保され、通常は、現在のアプリケーション又は設計のために論理ゼロレベル又は値に設定されている。
２バイトＣＲＣフィールドは、パケット長を含むパケットにおいて全バイトのＣＲＣを指定又は含む。
１９．実行型ハンドオフパケット
実行型ハンドオフパケットは、ホストがこのパケットで指定されるモードにハンドオフするようにクライアントに命令するために使用するための、手段、構造、又は方法である。これは、クライアント機能パケットにおいて説明されたように、クライアントによってサポートされるインタフェースタイプ設定の内の１つであるべきである。ホストとクライアントは、このパケットが送信された直後に、指定された順方向及び逆方向リンクインタフェースタイプに切り換えるべきである。実行型ハンドオフパケットのための一実施形態のフォーマットは、図２９において示されている。１型以外のインタフェースをサポートするホスト及びクライアントは、このパケットに対するサポートを提供すべきである。
一般に、ホストが、それが実行型ハンドオフパケットをクライアントがホストと同期していることを確認するために送る直前に、クライアント要求及びステータスパケットを読むことが推奨される。
図２９に示されているように、一実施形態において、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、インタフェースタイプフィールド、予約１フィールド、遅延フィラーフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常２バイト型フィールドにおける７７型パケットとして識別され、そして、パケット長フィールド及び遅延フィラーフィールドの外側の、６バイトの事前に選択された固定長を使用する。
一実施形態においては、インタフェースタイプフィールドは、リンク用に使用又は採用される予定の新しいインタフェースタイプを確認するために、１バイト値を使用する。このフィールドにおける値は、次の方法で、インタフェースタイプを指定又は表わす。ビット２から０は、順方向リンク上で使用される予定のインタフェースタイプを定義し、１の値は１型モードのハンドオフを、２の値は２型モードのハンドオフを、３の値は３型モードのハンドオフを、４の値は４型モードのハンドオフを、意味し又は指定する。ビット５から３は、逆方向リンク上で使用される予定のインタフェースタイプを定義し、１の値は１型モードのハンドオフを、２の値は２型モードのハンドオフを、３の値は３型モードのハンドオフを、４の値は４型モードのハンドオフを、意味し又は指定する。ビット０、６及び７は、将来使用のために目下確保されており、そしてそのようなものとして典型的には、しかし必ずしも必要ではないが、論理ゼロレベルに設定されている。
遅延フィラーフィールドは、クライアントが、実行インタフェース型ハンドオフパケットにすぐに続くパケットの初めに、新しいインタフェースタイプ設定を使用するために使用或いはセットアップを切り換えるように準備する又は構成されるために、システム部分上十分な時間を与えるための手段、構造、又は方法として生成される。このフィールドは、全てが論理ゼロレベル又は値に或いは等しく設定されている１グループのバイト又は８ビット値を含む。このフィールド中で使用されるバイトの数は、それが結果として６４ＭＭＤＩ＿Ｓｔｂサイクルと等価な長さであるこのフィールドになるように選択される。遅延フィラーフィールドの長さは、１型順方向リンクインタフェースタイプの場合は１６バイト、２型インタフェースタイプの場合は３２バイト、３型インタフェースタイプの場合は６４バイト、そして４型順方向リンクインタフェースタイプを特定する又は使用する時は１２８バイトとなるであろう順方向リンクのインタフェースタイプ設定に基づく。
予約１フィールド（ここでは１バイト）は、情報を与えることにおいての将来の使用のために確保される。このフィールドの全ビットは、通常、論理ゼロレベルに設定されている。このようなフィールドの目的は、現在のところは、全てのその後に続く２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、そして４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。ＣＲＣフィールド（ここでは２バイト）は、パケット長を含むパケットにおける全バイトの１６ビットＣＲＣを含む。
２０．順方向音声チャネルイネーブルパケット
このパケットは、ホストがクライアントにおける音声チャネルをイネーブル又はディスエーブルにすることを可能にする構造、方法、又は方法を提供する。この機能は有用であり、クライアント（例えばディスプレイ）が、ホストによって出力される予定の音声がない時に節電するために、音声増幅器又は同様な回路エレメントの電源を切ることができる。これは、単にインジケータとして音声ストリームの存在又は不在を使用して暗黙的に実現するのはかなり困難である。クライアントシステムが電源投入される時のデフォルト状態は、全ての音声チャネルがイネーブルにされる。順方向音声チャネルイネーブルパケットの一実施形態のフォーマットは、図３０において示されている。図３０に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、音声チャネルイネーブルマスクフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、１バイト型フィールドにおいて７８型パケットとして識別され、４バイトの事前に選択された固定長を使用する。
２１．逆方向音声サンプルレートパケット
このタイプのパケットは、ホストがクライアントにおける音声チャネルをイネーブル又はディスエーブルにすることを可能にする構造、方法、又は方法を提供する。この機能は有用であり、クライアントが、ホストによって出力される予定の音声がない時に節電するために、音声増幅器又は同様な回路エレメントの電源を切ることができる。これは、音声ストリームの存在又は不在を使って暗黙的に実現するのはかなり困難である。クライアントシステムが電源投入される又はホストに接続される時のデフォルト状態は、全ての音声チャネルがイネーブルにされる。ホスト及びクライアントに接続される音声システムは、ゼロから１状態又は値に遷移した音声チャネルイネーブルマスクフィールドにおけるビットの内の少なくとも１つを有する順方向音声チャネルイネーブルパケットをクライアントが受け取った後の約１ミリ秒以内に、意図された又は所望された方法で、音声信号を出力する準備ができている或いは出力出来ることが必要である。クライアントは、クライアント機能パケットの音声チャンネル機能フィールドのビット１５にセットされた値を使って順方向音声チャネルイネーブルパケットに応答する能力を示す。
このパケットは、ホストが、逆方向リンク音声チャネルをイネーブル又はディスエーブルにし、そしてこのストリームの音声データサンプルレートを設定することを可能にする。ホストは、クライアント機能パケットの中で有効であると定義されるサンプルレートを選択する。もしホストが無効なサンプルレートを選択すると、そのあとクライアントはホストに音声ストリームを送信せず、又、適切なエラー、エラー値、又はエラー信号がクライアントエラーレポートパケットでホストに送信されてよい。ホストは、サンプルレートを２５５の値に設定することによって逆方向リンク音声ストリームをディスエーブルにしてよい。クライアントシステムが最初に電源を入れられる、或いは接続されるときに想定されるデフォルトの状態は、逆方向リンク音声ストリームがディスエーブルにされている。逆方向音声サンプルレートパケットのための一実施形態のフォーマットは、図３１において示されている。図３１に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、音声サンプルレートフィールド、予約１フィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、７９型パケットとして識別され、４バイトの事前に選択された固定バイトを使用する。
２２．デジタルコンテンツ保護オーバヘッドパケット
このパケットは、使用されているデジタルコンテンツ保護方法に関連するメッセージをホストとクライアントとが交換することを可能にする、構造、方法、及び手段を提供する。将来の別の保護スキーム指定のための余地を確保して、現在、二つのタイプのコンテンツ保護、デジタル伝送コンテンツ保護（ＤＴＣＰ）或いは高帯域幅デジタルコンテンツ保護システム（ＨＤＣＰ）、が熟考されている。使用されている方法は、このパケットのコンテンツ保護タイプパラメータによって指定される。デジタルコンテンツ保護オーバヘッドパケットのための一実施形態ののフォーマットは、図３２においてに示されている。図３２に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔＩＤフィールド、コンテンツ保護タイプフィールド、コンテンツ保護オーバヘッドメッセージフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、８０型パケットとして識別されている。
２３．透明色イネーブルパケット
透明色イネーブルパケットは、どの色がディスプレイにおいて透明であるのかを指定するために、そして、画像を表示するため透明色の使用をイネーブルに又はディスエーブルにするために、使用される構造、方法、又は手段である。この機能を有するディスプレイは、クライアント機能パケットのクライアント特徴機能フィールドのビット４でその機能を報告する。透明色用の値を備えるピクセルがビットマップに書き込まれる時、色は、以前の値から変化しない。透明色イネーブルパケットのフォーマットは図３３において示されている。図３３に示されるように、一実施形態においてはこのタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、透明色イネーブルフィールド、予約１フィールド、アルファ−カーソル識別子フィールド、データフォーマット記述子フィールド、透明ピクセル値フィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、通常、１バイト型フィールドにおける８１型パケットとして識別され、そして、１０バイトの事前に選択された固定長を使用する。
２４．往復遅延測定パケット
往復遅延測定パケットは、ホストからクライアント（ディスプレイ）への伝搬遅延に加えてクライアント（ディスプレイ）からホストへ戻る遅延を測定するために使用される、構造、方法、又は手段を提供する。この測定は、本質的に、ラインドライバとラインレシーバ、及び相互接続サブシステムに存在する遅延を含む。この測定は、上記に概して説明された、逆方向リンクカプセル化パケットにおける、方向転換遅延と逆方向リンクレート除数パラメータを設定するために使用される。このパケットは、ＭＤＤＩリンクが特定のアプリケーション用に意図された最大スピードで運転している時に最も有効である。パケットは、１型モードで、そして、往復遅延測定の範囲を増加させるためにより低速のデータレートで送られてよい。ＭＤＤＩ＿Ｓｔｂ信号は、あたかも全ゼロデータが次のフィールド、すなわち、両方のガード時間、全ゼロ、及び測定期間、の間に送信されているかのように動作する。これは、ＭＤＤＩ＿Ｓｔｂを、それが測定期間中にクライアントにおける周期クロックとして使用されることが出来るように、データレートの半分で切り替え(toggle)させる。
一実施形態では、クライアントは、通常、クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット１８の使用を通して往復遅延測定パケットをサポートする能力を示す。すべてのクライアントが往復遅延測定をサポートすることが薦められるが、ホストが、最大ケーブル遅延に基づき、そして最大のドライバとレシーバの遅延に基づき、最悪のケースの往復遅延を知ることは、可能である。これは、インタフェースが使用されている装置の既知の設計エレメント（銅線長、回路網種類、及び特徴等）の一態様であるので、ホストは、内部モードで使用されるＭＤＤＩリンクに先行して往復遅延を知る可能性もある。
往復遅延測定パケットのフォーマットは図３４において示されている。図３４に示されるように、一実施形態では、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、パラメータＣＲＣフィールド、ガード時間１フィールド、測定期間フィールド、全ゼロフィールド、及びガード時間２フィールドを有するように構成されている。このタイプのパケットは、通常８２型パケットとして識別され、１５９ビットの事前に選択された固定長を使用する。
往復遅延測定パケットの間に発生するイベントのタイミングは、図３５において示されている。図３５では、ホストは、全ゼロ１フィールドとガード時間１フィールドが後に続くパラメータＣＲＣフィールドとストローブ位置合わせフィールドの存在によって示される、往復遅延測定パケットを送信する。パケットがクライアントディスプレイ装置又は処理回路網に達する前に、遅延３５０２が発生する。クライアントがパケットを受信すると、それは、クライアントにより決定されるような測定期間の初めに実用上できる限り正確に、０ｘｆｆ、０ｘｆｆ及び３０バイトの０ｘ００パターンを送信する。クライアントがこのシーケンスの送信を開始する実際の時間は、ホストの観点からは、測定期間の始まりから遅延している。この遅延量は、実質的には、パケットが、ラインドライバ及びレシーバそれに相互接続サブシステム（ケーブル、導線）を通して伝搬するのに要する時間である。同様の遅延量３５０４が、クライアントからホストに伝搬して戻るパターンについて発生する。
クライアントに、及びクライアントから、行き来する信号に対する往復遅延時間を正確に決定するために、ホストは、測定期間の開始後、０ｘｆｆ、０ｘｆｆ、及び３０バイトの０ｘ０シーケンスの始まりが到着時に検出されるまでに発生する順方向リンクビット時間期間の数をカウントする。この情報は、往復信号がホストからクライアントに伝わりそして再び戻ってくる時間量を求めるために使用される。従って、この量の約２分の１は、クライアントへの信号の一方向の通過のために生じる遅延に帰する。
ホストとクライアントの両方とも、ＭＤＤＩ＿ＤＡＴＡラインを定められた状態に保つために、両方のガード時間中にラインを論理ゼロレベルに駆動する。両方のガード時間中のホスト及びクライアントのイネーブル時間及びディスエーブル時間は、ＭＤＤＩ＿Ｄａｔａ信号がどんな有効な往復遅延時間も有効な低レベルにあるようなものである。
２５．順方向リンク歪み校正パケット
順方向リンク歪み校正パケットは、クライアント又はディスプレイがＭＤＤＩ＿Ｓｔｂ信号に関してＭＤＤＩ＿Ｄａｔａ信号の伝搬遅延における差異に対しそれ自体を校正するのを可能にする。遅延歪み補償を行わなければ、最大データレートは、一般に、これらの遅延における潜在的な最悪のケースの変動を説明するのに限定される。一般に、このパケットは、順方向リンクデータが約５０Ｍｂｐｓ以下のレートに構成される時にだけ送信される。ディスプレイを校正するためにこのパケットを送信した後に、データレートは５０Ｍｂｐｓを超えて強化される。もしデータレートが歪み補償プロセスの間に高すぎに設定されている場合は、ディスプレイは、遅延歪み補償設定を１ビット時間よりも長くオフにさせ、その結果として誤ったデータクロッキングを生じさせるであろう、ビット期間のエイリアスに同期するかもしれない。最高データレートタイプのインタフェース又は最大可能インタフェースタイプが、すべての既存のデータビットが校正されるように、順方向リンク歪み校正パケットを送信する前に選択される。
順方向リンク歪み校正パケットのフォーマットの一実施形態が、図５６において示されている。図５６に示されるように、このタイプのパケットは、パケット長（２バイト）フィールド、パケットタイプフィールド、ｈＣｃｌｉｅｎｔ ＩＤフィールド、パラメータＣＲＣフィールド、全ゼロ１フィールド、校正データシーケンスフィールド及び全ゼロ２フィールドを有するように構造化されている。このタイプのパケットは通常、タイプフィールドにおいて８３型タイプとして識別され、そして５１９の事前に選択された長さを有する。
仮想制御パネル
仮想制御パネル（ＶＣＰ）を使用すると、ホストは、クライアントにおけるある一定のユーザ制御を設定できる。これらのパラメータがホストにより調整されるのを可能にすることによって、クライアントにおけるユーザインタフェースは、ユーザが音声音量又はディスプレイ輝度のようなパラメータを調整することを可能にする画面がクライアント内の１つ又は複数のマイクロプロセッサによってよりも寧ろホストソフトウェアによって生成されることがきるので、簡略化されることができる。ホストは、クライアントのパラメータ設定値を読み取りそして各制御に対する有効値の範囲を求める能力、を有する。クライアントは、一般に、どの制御パラメータが調整されることができるのかをホストに報告する機能を有する。
制御コード（ＶＣＰコード）及び一般的に指定される関連データ値は、クライアントの制御と設定値を指定するために活用される。ＭＤＤＩ仕様におけるＶＣＰコードは、パケット定義における適切なデータフィールド位置合わせを保存するために、そして、将来において、このインタフェースに或いは将来の機能強化に固有である補足値をサポートするために、１６ビットに拡大される。
２６．ＶＣＰ特徴要求パケット
ＶＣＰ特徴要求パケットは、ホストが特定の制御パラメータ又は全ての有効な制御パラメータの現在の設定を要求するための手段、機構又は方法を提供する。一般的には、クライアントは、ＶＣＰ特徴応答パケットにおける適切な情報でＶＣＰパケットに応答する。一実施形態では、クライアントは、クライアント機能パケットのクライアント特徴機能インジケータのビット１３を使用してＶＣＰ特徴要求パケットをサポートする能力を示す。
一実施形態におけるＶＣＰ特徴要求パケットのフォーマットは、図６９において示されている。図６９で見られるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、ＭＣＣＳ ＶＣＰコードフィールド及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、一般に、２バイト型フィールドにおいて示される１２８型として一実施形態において識別される。パケット長フィールドを含まないパケット内のビットの総数を指定するパケット長は、通常、このタイプのパケットについては８ビットの長さに固定されている。
ｈＣｌｉｅｎｔ ＩＤフィールドは、将来のインプリメンテーションにおけるクライアントＩＤとしての使用のために予約され、通常は、ゼロに設定されている。ＭＣＣＳ ＶＣＰコードフィールドは、ＭＣＣＳ ＶＣＰ制御コードパラメータを指定する２バイトの情報を備える。０から２５５の範囲の値は、ＶＣＰ特徴応答パケットを、指定されたＭＣＣＳコードに対応するＶＣＰ特徴応答リスト内の単一のアイテムと共に返されるようにする。６５５３５（０ｘｆｆｆ）のＭＣＣＳ ＶＣＰコードは、クライアントによってサポートされる各制御に対し特徴応答リストアイテムを含むＶＣＰ特徴応答リスト付きのＶＣＰ特徴応答パケットを要求する。このフィールドのための２５６から６５５３４までの値は、将来の使用のために予約され、現在は使用されていない。
２７．ＶＣＰ特徴応答パケット
ＶＣＰ特徴応答パケットは、クライアントが特定の制御パラメータ又は全ての有効制御パラメータの現在の設定でホスト要求に応えるための手段、機構又は方法を提供する。一般に、クライアントは、ＶＣＰ特徴要求パケットに応えてＶＣＰ特徴応答パケットを送信する。このパケットは、特定のパラメータの現在の設定を判断し、特定の制御のための有効な範囲を決定し、特定の制御がクライアントによってサポートされているかどうかを判断し、或いはクライアントによってサポートされている制御のセットを決定するために有用である。もし、クライアント内でインプリメントされていない特定の制御を参照するＶＣＰ特徴要求が送信される場合、そのときは、ＶＣＰ特徴応答パケットは、適切なエラーコードを含むインプリメントされていない制御に対応する単一ＶＣＰ特徴応答リストアイテムと共に返される。一実施形態では、クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット１３を使用してＶＣＰ特徴応答パケットをサポートする能力を示す。
一実施形態におけるＶＣＰ特徴応答パケットのフォーマットは、図７０において示されている。図７０において見られるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、ＭＣＣＳバージョンフィールド、応答シーケンス番号フィールド、ＶＣＰ特徴応答リストフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、一実施形態においては、一般に、２バイト型フィールドにおいて示されるように、１２９型として識別される。
ｃＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤのために予約される情報を含む。このフィールドは、将来の使用のために予約され、通常はゼロに設定されている。ＭＣＣＳバージョンフィールドは、クライアントによって実現されるＶＥＳＡ ＭＣＣＳ仕様のバージョンを指定する２バイトの情報を含む。
２バイトの応答シーケンス番号フィールドは、クライアントによって返されるＶＣＰ特徴応答パケットのシーケンス番号を指定する情報又はデータを含む。クライアントは、６５５３５のＭＣＣＳ制御コード値と共に、ＶＣＰ特徴要求パケットに応えて１つ又は複数のＶＣＰ特徴応答パケットを返す。クライアントは、複数のＶＣＰ特徴応答パケット上で特徴応答リストを広めてもよい又は転送してもよい。この場合、クライアントは、各連続パケットにシーケンス番号又は識別子を割り当てるべきであり、そして、単一のＶＣＰ特徴要求パケットに応えて送信されるＶＣＰ特徴応答パケットのシーケンス番号は、通常、ゼロで開始し、１インクリメントする。最後のＶＣＰ特徴応答パケット内のＶＣＰ特徴応答リストアイテムは、パケットが最後のパケットであり且つ返されるパケットのグループの最も大きいシーケンス番号を含むことを識別するために、０ｘｆｆｆｆに等しいＭＣＣＳ ＶＣＰ制御コード値を含むべきである。もし、ただ１つのＶＣＰ特徴応答パケットがＶＣＰ特徴要求パケットに応じて送信される場合、そのとき、その単一のパケット内の応答シーケンス番号は一般にゼロに設定されており、そして、ＶＣＰ特徴応答リストは、０ｘｆｆｆｆに等しいＶＣＰ特徴応答リストアイテムにおけるＭＣＣＳ ＶＣＰコードを有するリストアイテムを含む。ＶＣＰ特徴応答リストアイテムパケットにおける最大値フィールド及び現在値フィールド（図７１）は、ＭＣＣＳ ＶＣＰ制御コードが０ｘｆｆｆｆに等しい時、ゼロに設定されている。
リストフィールドの中の特徴の数は、このパケットの中のＶＣＰ特徴応答リスト内にあるＶＣＰ特徴応答リストアイテムの数を指定する２バイトを含んでいる、一方、ＶＣＰ特徴応答リストフィールドは１つ又は複数のＶＣＰ特徴応答リストアイテムを含むバイトのグループである。一実施形態における単一のＶＣＰ特徴応答リストアイテムのフォーマットは、図７１において示される。
図７１に示されように、各ＶＣＰ特徴応答リストアイテムは、長さが１２バイトであり、ＭＣＣＳ ＶＣＰコードフィールド、結果コードフィールド、最大値フィールド及び現在値フィールドを備える。２バイトのＭＣＣＳ ＶＣＰ制御フィールドは、このリストアイテムと関連付けられるＭＣＣＳ ＶＣＰ制御コードパラメータを指定するデータ又は情報を含む。ＶＥＳＡ ＭＣＣＳ仕様書バージョン２以降に定められた制御コード値だけが、この実施形態の場合、有効と見なされる。２バイト結果コードフィールドは、指定されたＭＣＣＳ ＶＣＰ制御に関する情報の要求に関連するエラーコードを指定する情報を含む。このフィールドの「０」の値は、エラーがないことを意味し、一方、「１」の値は、指定された制御がクライアントにおいてインプリメントされていないことを意味する。２から６５５３５のこのフィールド用の更なる値が、将来の使用及び技術によって熟考される他のアプリケーションのインプリメンテーションのために現在予約されているが、当分は使用される予定にない。
４バイトの最大値フィールドは、指定されたＭＣＣＳ制御が設定されることが出来る最大可能値を指定する。もし要求される制御がクライアントの中でインプリメントされていない場合は、この値はゼロに設定されている。もし返された値が長さで３２ビット（４バイト）未満である場合、このとき、値は、３２ビット整数の中に入れられ、最上位（未使用）バイトをゼロに設定されたままにしておく。４バイトの現在値フィールドは、指定されたＭＣＣＳ ＶＣＰ連続（Ｃ）又は非連続（ＮＣ）制御の現在値を指定する情報を含む。もし要求された制御がクライアントの中でインプリメントされていない場合、或いは、もし制御がインプリメントされているが、テーブル（Ｔ）データ型である場合、このとき、この値はゼロに設定されている。もし返される値がＶＥＳＡ ＭＣＣＳ仕様に準拠して長さが３２ビット（４バイト）未満である場合、このときは、値は、３２ビット整数の中に入れられ、最上位（未使用）バイトをゼロに設定されたままにしておく。もし、指定されたＭＣＣＳ ＶＣＰコードが非連続制御又はテーブルデータ型である場合、このとき最大値フィールドはゼロであるように設定されている又は選択されている。
２８．ＶＣＰ特徴設定パケット
ＶＣＰ特徴設定パケットは、ホストがクライアント内での連続制御と非連続制御の両方にＶＣＰ制御値を設定するための手段、機構又は方法を提供する。一実施形態では、クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット１３を使用してＶＣＰ特徴設定パケットをサポートする能力を示す。
一実施形態におけるＶＣＰ特徴設定パケットのフォーマットは、図７２において示されている。図７２において見られるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、ＭＣＣＳ ＶＣＰコードフィールド、リスト中の値の数フィールド、制御値リストフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、一般に、２バイト型フィールドにおいて示されるように、１３０型として識別され、パケット長フィールドを除いて２０バイトの長さである。
ｈＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤとして指定するために或いはＣｌｉｅｎｔ ＩＤとして働くために、２バイト値を再度使用する。このフィールドは、将来の仕様のために予約され、そして現在はゼロに設定されている。ＭＣＣＳ ＶＣＰコードフィールドは、調整される予定のＭＣＣＳ ＶＣＰ制御コードパラメータを指定するための２バイトの情報、又は値を使用する。２バイトのリスト中の値の数フィールドは、制御値リストにおいて存在する１６ビット値の数を指定する情報又は値を含む。制御値リストは、ＭＣＣＳ制御コードがクライアント内のテーブルに関連しない限り、通常１つのアイテムを含むであろう。非テーブル関連制御の場合、制御値リストは、ＭＣＣＳ ＶＣＰコードフィールドにより指定される制御パラメータに書き込まれる新しい値を指定する値を含むであろう。テーブル関連制御の場合、制御値リスト中のデータのフォーマットは、指定されたＭＣＣＳ ＶＣＰコードのパラメータ記述によって指定される。もしリストが１バイトより大きい値を含む場合、そのときは、他の箇所で定義された方法に整合して、最下位ビットが最初に送信される。最終的に、２バイトのＣＲＣフィールドは、パケット長を含むパケット内の全てのバイトの１６ビットＣＲＣを含む。
２９．有効パラメータ要求パケット
有効パラメータ要求パケットは、指定された非連続（ＮＣ）又は表（Ｔ）制御によってサポートされているパラメータのリストを含む有効パラメータ応答パケットをクライアントが返すことを要求するために有用な、手段又は機構として使用される。このパケットは、クライアント内の表に関連する制御又は非連続制御のみを指定すべきであって、全ての制御を指定するための６５５３５（０ｘｆｆｆｆ）のＭＣＣＳ ＶＣＰコード値を指定すべきでない。もしサポートされていない又は無効のＭＣＣＳ ＶＣＰコードが指定される場合、そのときは適切なエラー値が有効パラメータ応答パケットで返される。一実施形態においては、クライアントは、ディスプレイ機能パケットのクライアント特徴機能フィールドのビット１３を使用して有効パラメータ要求パケットをサポートする能力を示す。
一実施形態における有効パラメータ要求パケットのフォーマットは、図７３において示されている。図７３に見られるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、ＭＣＣＳ ＶＣＰコードフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは一般に、実施形態において、２バイト型フィールドにおいて示されるように、１３１型として識別される。
パケット長は、２バイトのパケット長フィールドに示されているように、一般に、８のパケット長フィールドを含まずにパケット中のバイトの総数を有するように設定される。ｈＣｌｉｅｎｔ ＩＤは、再びクライアントＩＤを指定するが、当業者には明らかであるように、現在は将来の使用のために予約されており、そしてゼロに設定されている。２バイトのＭＣＣＳ ＶＣＰコードフィールドは、照会される予定の非連続ＭＣＣＳ ＶＣＰ制御コードパラメータを指定する値を含む。このフィールドの値は、クライアントにおいてインプリメントされる非連続制御に対応すべきである。値２５６から６５５３５（０ｘｆｆｆｆ）は、通常、予約されるか或いは有効と見なされ、そして、エラー応答の中ではインプリメントされていない(unimplemented)制御として見なされる。
３０．有効パラメータ応答パケット
有効パラメータ応答パケットは、有効パラメータ要求パケットに応えて送信される。それは、非連続ＭＣＣＳ ＶＣＰ制御又は表のコンテンツを返す制御のための有効な設定値を識別するための手段、方法又は機構として使用される。もし制御がクライアント内の表に関する場合、そのときは、ＶＣＰパラメータ応答リストは、要求された順次表値の特定なリストを単に含むだけである。もし表のコンテンツが単一の有効パラメータ応答パケットに適合しない場合、そのときは、順次応答シーケンス番号の付いた複数のパケットがクライアントによって送信されることができる。一実施形態では、クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット１３を使用して有効パラメータ応答パケットをサポートする能力を示す。
ホストは、以下の方法で、テーブルのコンテンツを要求してよい：ホストは、読み取り／書き込みパラメータ、ＬＵＴオフセット、及びＲＧＢ選択のような、必要な又は所望されるパラメータを含むＶＣＰ特徴設定パケットを送信する；次に、所望される制御を指定する有効パラメータ要求パケットがホストによって送信される；次に、クライアントが、表データを含む１つ又は複数の有効パラメータ応答パケットを返す。動作のこのシーケンスが、ＭＣＣＳ動作モデルにおいて説明される表読み取り機能として同様な機能を実行する。
もし特定のクライアントパラメータがクライアントによってサポートされていない場合、そのとき一実施形態においては、このパケットの対応するフィールドは２５５の値を含むであろう。クライアントにおいて使用されるパラメータの場合、対応するフィールドはクライアントにおけるパラメータの値を含む必要がある。
一実施形態のための有効パラメータ応答パケットのフォーマットは図７４において示されている。図７４で分かるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、ＭＣＣＳ ＶＣＰコードフィールド、応答コードフィールド、応答シーケンス番号フィールド、リスト中の数値フィールド、ＶＣＰパラメータ応答リストフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットは、一般に、２バイト型フィールドにおいて示されているように、１３２型として、一実施形態の場合、識別される。
ｃＣｌｉｅｎｔ ＩＤフィールドは、上記の説明から知られるように、将来のクライアントＩＤのために予約されている、一方、３バイトのＭＣＣＳ ＶＣＰコードパケットはこのパケットによって記述される非連続ＭＣＣＳ ＶＣＰ制御コードパラメータを指定する値を含む。もし無効なＭＣＣＳ ＶＣＰ制御コードが有効パラメータ要求パケットによって指定される場合、そのときは、応答コードフィールドにおける適切な値と共に、このフィールドにおいては同じ無効パラメータ値が指定されるであろう。もしＭＣＣＳ制御コードが無効である場合は、そのとき、ＶＣＰパラメータ応答リストはゼロ長を有するであろう。
応答コードフィールドは、指定されたＭＣＣＳ ＶＣＰ制御に関する情報に対する要求に関連する応答の性質を指定する２バイトの情報又は値を含む。もしこのフィールドにおける値が０に等しい場合、このときは、エラーはこのデータ型に存在しているとは見なされず、そして、シーケンスの中の最後の有効パラメータ応答パケットが送信され、それは最も大きい(the highest)応答シーケンス番号を有している。このフィールドにおける値が１に等しい場合、このときは、エラーが存在すると見なされないが、より大きい(higher)シーケンス番号を有する他の有効パラメータ応答パケットが送信される。もしこのフィールドにおける値が２に等しい場合、このときは、指定された制御がクライアントにおいてインプレメントされているとは見なされない。もしこのフィールドｉｄの値が３に等しい場合、このときは、指定された制御は非連続制御ではない（それはゼロからその最大値までの全ての値の有効なセットをいつも有する連続制御である）。４から６５５３５まで等しいこのフィールドの値は、将来の使用のために予約され、そして一般に、使用されるべきではない。
２バイト応答シーケンス番号フィールドは、クライアントによって返される有効パラメータ応答パケットのシーケンス番号を指定する。クライアントは、有効パラメータ要求パケットに応えて１つ又は複数の有効なパラメータ応答パケットを返す。クライアントは、複数の有効パラメータ応答パケット上でＶＣＰパラメータ応答リストを広めてもよい。この後者のケースでは、クライアントは、各連続パケットにシーケンス番号を割り当て、シーケンス内の最後のパケットを除く全てにおいて応答コードを１に設定するであろう。シーケンス内の最後の有効パラメータ応答パケットは、最も大きな応答シーケンス番号を有し、そして応答コードは０の値を含むであろう。
２バイトのリスト中の値の数フィールドは、ＶＣＰパラメータ応答リストに存在する１６ビット値の数を指定する。もし応答コードがゼロに等しくない場合、そのとき、リスト中の値の数パラメータはゼロである。ＶＣＰパラメータ応答リストフィールドは、ＭＣＣＳ 制御コードフィールドにより指定される非連続制御の有効な値のセットを示す０から３２７６０の２バイト値のリストを含む。非連続制御コードの定義は、ＶＥＳＡ ＭＣＣＳ仕様において指定される。最終的に、本実施形態においては、ＣＲＣフィールドは、パケット長を含むパケット内の全てのバイトの１６ビットＣＲＣを含む。
スケールドビデオストリーム画像
ＭＤＤI又はプロトコル機構、構造、手段、又は方法は、ホストが元の画像より大きく又は小さく拡大縮小される画像(scaled larger or smaller)をクライアントに送信するのを可能にするスケールドビデオストリーム画像(scaled video stream images)に対するサポートを提供し、拡大縮小された(scaled)画像はメイン画像バッファにコピーされる。スケールドビデオストリーム機能性(the Scaled Video Stream functionality)と関連プロトコルサポートの概要は他の箇所で示される。スケールドビデオストリームをサポートする能力は、特殊ステータス要求パケット(a Request Specific Status Packet)に応えて送信されるスケールドビデオストリーム機能パケット(the Scaled Video Stream Capability Packet)によって、或いは中で定義される。
以下に説明されるスケールドビデオストリームパケットのヘッダは、ヘッダが画像を表示するために必要な全体のコンテキストを含む簡易画像ストリームパケットとわずかに異なる。スケールドビデオストリームパケットは、送信元及び行先のウィンドウサイズ及び位置のパラメータを定義するためにセットアップパケットを、そして、ピクセルデータを送信するために別のスケールドビデオストリームパケットを、使用する。クライアントは、セットアップパケットからのストリームパラメータと各ストリームに関連したピクセルデータの部分を保存するために、各ストリームに関連した内部記憶領域を割り当てる。各ストリーム用に要求される記憶容量は、発信元及び行先の画像サイズとセットアップパケットにおいて指定される値とに応じて異なるであろう。この理由のために、プロトコルは、クライアントが各スケール済みのビデオストリームに関連する記憶装置の割り当てのためにダイナミックメモリ割り当てをインプリメントすることを可能にするように、設計される。
プログラムソースに固有のサイズを有するディスプレイにビデオストリームを送ること、そして、ディスプレイに個別のエンドアプリケーション用に適切な方法で画像を拡大縮小及び位置付けさせること、は有用である。複数のビデオ画像のリアルタイムスケーリング(real-time scaling)のためのインプリメンテーションは、クライアントにおいてこの特徴のサポートをオプショナルとするには十分複雑である。
３１．スケールドビデオストリーム機能パケット
スケールドビデオストリーム機能パケット(the Scaled Video Stream Capability Packet)は、クライアントの中の或いはクライアントによって使用されるスケールドビデオストリームソース画像の特性を定義する。スケールドビデオストリーム機能パケットは、概して図７５において示されている。図７５で分かるように、一実施形態では、スケールドビデオストリーム機能パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、最大ストリーム数フィールド、ソース最大Ｘサイズフィールド、ソース最大Ｙサイズフィールド、ＲＧＢ機能フィールド、白黒機能フィールド、予約１フィールド、Ｙ Ｃｒ Ｃｂ機能フィールド、予約２フィールド、及びＣＲＣフィールドを有するように構造化されている。パケット長は、一実施形態において、長さフィールドに示されているように、クライアントＩＤの使用のために予約され、それ以外の場合ゼロに設定されている、２バイトのｃＣｌｉｅｎｔ ＩＤフィールド、及びＣＲＣフィールドを含む、固定された２０バイトであるように選択されている。一実施形態では、クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中で１４３のパラメータ値を使用してスケールドビデオストリーム機能パケットをサポートする能力を示す。
２バイトの最大ストリーム数フィールドは、一度に割り当てられてよい同時スケールドビデオストリームの最大数を識別するための値を含む。一実施形態では、クライアントは、もし最大数のスケールドビデオストリームがすでに割り当てられている場合は、スケールドビデオストリームを割り当てる要求を拒絶しなければならない。もし最大数未満のスケールドビデオストリームが割り当てられている場合は、クライアントはまたクライアントにおける他のリソース制限に基づく割り当て要求を拒絶してもよい。
ソース最大ＸサイズフィールドとＹサイズフィールド（２バイト）は、ピクセルの数として表されるスケールドビデオストリームソース画像の、最大の幅と高さの値を夫々指定する。
ＲＧＢ機能フィールドは、ＲＧＢフォーマットで表示されることができる解像度のビット数を指定する値を使用する。もしスケールドビデオストリームがＲＧＢフォーマットを使用できない場合、そのとき、この値はゼロに等しく設定されている。ＲＧＢ機能ワードは、３つの別々の符号なし値から構成されており:ビット３から０までは各ピクセルにおいて青の最大ビット数（青輝度）を定義し、ビット７から４までは各ピクセルにおいて緑の最大ビット数（緑輝度）を定義し、そしてビット１１から８までは各ピクセルにおいて赤の最大ビット数（赤輝度）を定義し、一方、ビット１５から１２までは、将来の機能定義において使用するために予約され、通常はゼロに設定されている。
１バイトの白黒機能フィールドは、白黒フォーマットで表示されることができる解像度のビット数を指定する値を含む。もしスケールドビデオストリームが白黒フォーマットを使用できない場合、このとき、この値はゼロに設定されている。ビット７から４までは、将来の使用のために予約され、従って、当業者によって理解されるであろうように、これは経時的に変化する可能性はあるが、現在のアプリケーションの場合はゼロ（「０」）に設定されるべきである。ビット３から０までは、各ピクセルに存在できるグレイスケールの最大ビット数を定義する。これらの４個のビットは、各ピクセルが１から１５ビットのみからなることを指定することを可能にする。もし値がゼロである場合、このときは、白黒フォーマットはスケールドビデオストリームによってサポートされていない。
予約１フィールド（ここでは１バイト）は、スケールドビデオストリームパケット情報又はデータに関係する値を提供することにおいて将来使用のために予約されている。従って、現在のところ、このフィールドの全てのビットは論理「０」に設定されている。このフィールドの１つの目的は、全ての以後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、そして４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。
２バイトのＹ Ｃｂ Ｃｒ機能フィールドは、Ｙ Ｃｂ Ｃｒフォーマットで表示されることが出来る解像度のビット数を指定する値を含む。もしスケールドビデオストリームがＹ Ｃｂ Ｃｒフォーマットを使用できない場合、このときこの値はゼロである。Ｙ Ｃｂ Ｃｒ機能ワードは３つの別々の符号なし値から構成されており:ビット３から０はＣｒサンプルを指定するビット最大数を定義し；ビット７から４はＣｂサンプルを指定するビット最大数を定義し；ビット１１から８はＹサンプルを指定するビット最大数を定義し；そしてビット１５から１２は、将来の使用に予約されており、通常はゼロに設定されている。
１バイトの機能ビットフィールドは、スケールドビデオストリームに関連する機能を指定する１セットのフラグを含む。フラグは次のとおりに定義される：ビット０はスケールドビデオストリームパケット中のピクセルデータをカバーし、パックフォーマット中でありうる。パックされそしてバイト位置合わせされたデータは図１２において示されている。ビット１は将来の使用のために予約され、一般にゼロに設定されている；ビット２もまた将来の使用のために予約されそしてゼロに設定されている；ビット３は、カラーマップデータフォーマットにおいて指定されることができるスケールドビデオストリームをカバーする。メイン画像バッファ及びアルファ−カーソル画像平面のために使用されているようなのと同じカラーマップテーブルが、スケールドビデオストリームのために使用される。カラーマップは、ほかのどこかで説明されるカラーマップパケットを使用して構成され、そしてビット７から４は将来の使用のために予約され、一般にゼロに設定されている。
予約２フィールド（ここでは１バイト）は、スケールドビデオストリームパケット情報又はデータに関係する値を提供する上で将来の使用のため予約されている。従って、現
在のところは、このフィールドの全ての値は論理「０」に設定されている。このフィールドの１つの目的は、全ての以後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、そして４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。
３２．スケールドビデオストリームセットアップパケット
スケールドビデオストリームセットアップパケットは、スケールドビデオストリームのパラメータを定義するために使用される手段、構造、又は方法を提供し、クライアントは、画像のバッファリング及びスケーリングのために内部記憶領域を割り当てるために情報を使用する。ストリームは、Ｘ画像サイズフィールドとＹ画像サイズフィールドがゼロに等しい状態で、このパケットを送信することによって割り当て解除されてよい。割り当て解除されたスケールドビデオストリームは、後で、同じ又は異なるストリームパラメータを用いて割り当てし直されてよい。一実施形態では、クライアントは有効ステータス応答リストパケットの有効パラメータ応答リストにおける１４３のパラメータ値を使用して、及びスケールドビデオストリーム機能パケットの最大ストリーム数フィールドにおける非ゼロ値を使用することによって、スケールドビデオストリームセットアップパケットをサポートする能力を示す。
スケールドビデオストリームセットアップパケットのフォーマットは概して図７６において示されている。図７６で分かるように、一実施形態では、スケールドビデオストリームセットアップパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔフィールド、ストリームＩＤフィールド、視覚データフォーマット記述子フィールド、ピクセルデータ属性フィールド、Ｘ左端縁フィールド、Ｙ上部端縁フィールド、Ｘ右端縁フィールド、Ｙ下部端縁フィールド、Ｘ画像サイズフィールド、Ｙ画像サイズフィールド、及びＣＲＣフィールドを有するように構造化されている。
２バイトのパケット長フィールドは、パケット長フィールドを含まないパケットの中のバイト総数を指定する。一実施形態では、このパケット長は２４で固定されている。２バイトのパケットタイプフィールドは、パケットをスケールドビデオストリームセットアップパケットとして識別するために１３６の値を利用する。２バイトのｈＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤとしての将来の使用のために予約されており、通常、当面、或いは、知られているであろうように、プロトコルユーザがどのＩＤ値が使用されるべきかを判断するまで、全ビットゼロ値に設定されている。
ストリームＩＤフィールドは、ストリームＩＤの固有の識別子を指定するために２バイトを使用する。この値は、ホストにより割り当てられ、ゼロからクライアント機能パケットにおいて指定される最大ストリームＩＤ値までの値で変動する。ホストは、各アクティブストリームが固有の値を割り当てられていることを、そして、もはやアクティブではないストリームが割り当てを解除される、或いは再び割り当てられることを、保証するために注意深くストリームＩＤ値の使用を管理しなければならない。
一実施形態では、ビデオデータフォーマット記述子フィールドは、現在のパケットの現在のストリームのピクセルデータの各ピクセルのフォーマットを指定するために２バイトを使用する。ピクセルデータフォーマットは、アルファカーソル画像機能パケットにおいて定義されるとおりのアルファ−カーソル画像平面のための、又は上記で説明された他のパケット内で一般に定義されるような他の事前に定義された画像パターンのための、有効なフォーマットの少なくとも１つと準拠する必要がある。ビデオデータフォーマット記述子は、現在のパケット専用のピクセルフォーマットを定義し、一定のフォーマットが特定のビデオストリームの持続期間中に使用し続けられることを暗に意味しない。図１１は、ビデオデータフォーマット記述子がどのようにコード化されるのかの、そして、他のパケットについて上記で説明されたような、実施形態を図示する。
一実施形態では、２バイトのピクセルデータ属性フィールドは、次のとおりに解釈される値を有し、ビット１及び０は、将来の使用のために予約され、一般に、当面はゼロに設定されており、そしてビット２は、ピクセルデータがインタレースフォーマットにあるのかどうかを示す。ビット２が０である時、そのときは、ピクセルデータは標準プログレッシブフォーマットにある。行番号（ピクセルＹ座標）は、ある行から次の行に進む時に１インクリメントされる。ビット２が１である時、そのときは、ピクセルデータはインタレースフォーマットにある。行番号（ピクセルＹ座標）は、ある行から次の行に進む時に２インクリメントされる。
ビット３は、ピクセルデータが代替のピクセルフォーマットにあるかどうかを示す。これは、ビット２によってイネーブルにされる標準インタレースモードに類似しているが、インターレーシングは水平ではなくて垂直である。ビット３が０であるとき、ピクセルデータは標準プログレッシブフォーマットにある。列番号（ピクセルＸ座標）は、各連続ピクセルが受信されるとき１インクリメントされる。ビット３が１である時、このときは、ピクセルデータは代替ピクセルフォーマットにある。列番号（ピクセルＸ座標）は、各ピクセルが受信されるとき、２インクリメントされる。
ビット４から１５まではまた、将来の使用のために予約され、そして一般に、論理ゼロレベルに又は現在のアプリケーション又は設計用の値に設定されている。
３３．スケールドビデオストリーム肯定応答パケット
スケールドビデオストリーム肯定応答パケットは、クライアントがスケールドビデオストリームセットアップパケットの受信を確認するのを可能にする。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４３のパラメータ値を介して、そしてスケールドビデオストリーム機能パケットの最大ストリーム数フィールドの中の非ゼロ値を介して、スケールドビデオストリーム肯定応答パケットをサポートする能力を示す。
スケールドビデオストリーム肯定応答パケットのフォーマットは、概して図７７おいて示されている。図７７において分かるように、一実施形態では、スケールドビデオストリーム肯定応答パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔフィールド、ストリームＩＤフィールド、ＡＣＫコードフィールド、及びＣＲＣフィールドを有するように構造化されている。２バイトのパケット長フィールドは、このパケットタイプのための１０の値で、パケット長フィールドを除く、バイトの総数を指定するために使用され、一方、１３７のパケットタイプは、パケットをスケールドビデオストリーム肯定応答パケットとして識別する。
２バイトのｃＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤのための将来の使用のために予約されており、通常はゼロに設定されている。２バイトのストリームＩＤフィールドは、ストリームＩＤの固有の識別子を指定する。これはスケールドビデオストリームセットアップパケットのホストによって割り当てられるのと同じ値である。
２バイトの肯定応答コードフィールドは、指定されたスケールドビデオストリームを更新しようとする試みの結果を説明するコードを含む値を、提供する。一実施形態では、コードは次のとおりに定義される：
◎
０−ストリーム割り当て試行は成功した。
◎
１−ストリーム割り当て解除試行は成功した。
◎
２−すでに割り当てられているストリームＩＤを割り当てようとする無効な試行。
◎
３−すでに割り当て解除されているストリームＩＤを割り当て解除しようとする無効な試行。
◎
４−クライアントはスケールドビデオストリームをサポートしない。
◎
５−ストリームパラメータはクライアントの機能と整合していない。
◎
６−ストリームＩＤ値はクライアントによって許可される最大値より大きい。
◎
７−指定されたストリームを割り当てるには不十分なクライアント内で入手可能なリソース。
２バイトのＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを含む。
３４．スケールドビデオストリームパケット
スケールドビデオストリームパケットは、特殊なスケールドビデオストリームと関連したピクセルデータを送信するために使用される。このパケットにより参照される（ｒｅｆｅｒｅｎｃｅ）領域のサイズは、スケールドビデオストリームセットアップパケットにより定義される。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４３のパラメータ値を介して、そしてスケールドビデオストリーム肯定応答パケットのＡｃｋコードフィールド内での成功したスケールドビデオストリーム割り当て反応を使用して、スケールドビデオストリームパケットをサポートする能力を示すことが出来る。
スケールドビデオストリームパケットの１つの実施形態のフォーマットは、概して図７８において示されている。図７８において分かるように、スケールドビデオストリームパケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔ ＩＤフィールド、ストリームＩＤフィールド、ピクセルデータ属性フィールド、ピクセルカウントフィールド、パラメータＣＲＣフィールド、ピクセルデータフィールド、及びピクセルデータＣＲＣフィールドを有するように構造化されている。２バイトのパケットタイプフィールドは、スケールドビデオストリームパケットとしてパケットを識別するために１８の値を使用する。ｈＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤのために予約されており、一般にゼロに設定されている。前述されたように、２バイトのストリームＩＤフィールドは、ストリームＩＤの固有の識別子を指定する。この値は、スケールドビデオストリームセットアップパケット内のホストによって指定され、スケールドビデオストリーム肯定応答パケット内で確認される。一実施形態においては、２バイトのピクセルデータ属性フィールドは、ピクセルデータ経路情報及びディスプレイ更新又はバッファ場所を指定する値を有する。これらの値は、一実施形態にある。
一実施形態においては、２バイトのピクセルデータ属性フィールドは、ピクセルデータ経路情報及びディスプレイ更新又はバッファ場所を指定する値を有する。これらの値は、一実施形態においては、次のように解釈される。ビット１及び０で、ピクセルデータが経路設定されるべきディスプレイを選択する。「１１」又は「００」のビット値の場合は、ピクセルデータは両眼に又は用に表示され、ビット値「１０」の場合は、左眼へのみに経路設定され、そしてビット値「０１」の場合は、右眼へのみに経路設定される。
ビット７及び６は、ピクセルデータが書き込まれるべきフレームバッファを指定するディスプレイ更新ビットである。フレーム更新ビットの効果は、他のところでもっと詳細に説明される。ビット［７：６］が「０１」のとき、ピクセルデータはオフライン画像バッファに書き込まれ、ビット［７：６］が「００」のとき、ピクセルデータはディスプレイをリフレッシュするために使用される画像バッファに書き込まれる。ビット［７：６］が「１１」のとき、ピクセルデータは全画像バッファに書き込まれる。もしビット［７：６］が「１０」のときは、これは無効値として処理される。これらのビットは現在のところ将来の使用のために予約されている。この状況下では、ピクセルデータは無視され、どの画像バッファにも書き込まれないであろう。ビット２から５まで及びビット８から１５までは、将来の使用のために予約され、一般に、論理ゼロレベル又は値に設定されている。
２バイトのピクセルカウントフィールドは、以下のピクセルデータフィールド内のピクセル数を指定する。２バイトパラメータＣＲＣフィールドは、パケット長からピクセルカウントへの全てのバイトのＣＲＣを有する。もしＣＲＣがチェックできない場合、そのときは、パケット全体が廃棄される。２バイトピクセルデータフィールドは、拡大縮小され(to be scaled)その後にディスプレイされる予定の未処理のビデオ情報を含む。データは、ビデオデータフォーマット記述子フィールドによって記述される方法でフォーマットされる。データは、前に定義されたように、一度に１行送信される。
２バイトのピクセルデータＣＲＣフィールドは、ピクセルデータだけのＣＲＣを含む。もしこのＣＲＣがチェックできない場合には、そのとき、ピクセルデータが依然として使用されことができるが、ＣＲＣエラーカウントはインクリメントされる。
３５．特殊ステータス要求パケット
特殊ステータス要求パケットは、このパケットに指定されるように、クライアントが機能又はステータスパケットをホストに送り返すことをホストが要求するための手段、機構又は方法を提供する。クライアントは、次の逆方向リンクカプセル化パケット内に指定されるタイプのパケットを返す。クライアントは、もしクライアントが特殊ステータス要求パケットに応答する機能を有する場合は、クライアント機能パケットのクライアント特徴機能フィールドの中でビット１７を、一般に、設定するであろう。ホストが、クライアントが返す又は転送できるステータスパケットの全てのタイプを判断するために使用する便利な方法は、他のところで説明された有効ステータス応答リストパケットを使用することである。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット２１を使用して有効ステータス応答リストパケットで応答する能力を示すことが出来る。
特殊ステータス要求パケットの一実施形態のフォーマットは、概して図７９に示されている。図７９において分かるように、特殊ステータス要求パケットは、パケット長フィールド、パケットタイプフィールド、ｈＣｌｉｅｎｔＩＤフィールド、ステータスパケットＩＤフィールド、及びＣＲＣフィールドを有するように構造化されている。パケット長フィールドは、パケット長フィールドを含まないパケット内のバイト総数を指定し、そして通常、このパケットタイプの場合は１０の値で固定されている。１３８のパケットタイプは、パケットを特殊ステータス要求パケットとして識別する。ｈＣｌｉｅｎｔ ＩＤフィールド（２バイト）は、クライアントＩＤのための将来の使用のために予約され、そして当面ゼロに設定されており、一方、２バイトのステータスパケットＩＤフィールドは、クライアントがホストに送信しようとする機能又はステータスパケットのタイプを指定する。典型的なタイプは次の通りである：
◎
６６−クライアント機能パケットがクライアントによって送信される。
◎
１３３−アルファ−カーソル画像機能パケットがクライアントによって送信される。
◎
１３９−クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス応答リストパケットが送信される。
◎
１４０−パケット処理遅延パラメータパケットがクライアントによって送信される。
１４１−個人クライアント機能パケットがクライアントによって送信される。
◎
１４２−クライアントエラーレポートパケットがクライアントによって送信される。
◎
１４３−スケールドビデオストリーム機能パケットがクライアントによって送信される。
◎
１４４−クライアント識別パケットがクライアントによって送信される。
パケットタイプ５６から６３までは、製造業者に特殊な機能識別子と状態識別子に使用されることができる。
ＣＲＣフィールドは、パケット長を含むパケット内の全てのバイトのＣＲＣを再び含む。
３６．有効ステータス応答リストパケット
有効ステータス応答リストパケットは、ホストに、クライアントが返す機能を有するステータスパケットと機能パケットのリストを持つための構造、手段、又は方法を与える。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット２１を使用して有効ステータス応答リストパケットをサポートする能力を示すことができる。
有効ステータス応答リストパケットの一実施形態のフォーマットは、概して図８０において示されている。図８０において分かるように、有効ステータス応答リストパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、リスト中の値の数フィールド、有効パラメータ応答リストフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットのパケット長は、通常１０の値に固定され、そして１３９のタイプ値は、パケットを有効ステータス応答パケットとして識別する。ｃＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤとしての将来の使用のために予約され、通常ゼロに設定されている。２バイトのリスト中の値の数フィールドは、以下の有効パラメータ応答リスト内で項目の数を指定する。
有効パラメータ応答リストフィールドは、クライアントがホストに送信できる機能パケット又はステータスパケットのタイプを指定する２バイトのパラメータのリストを含む。もしクライアントが、それが（クライアント機能パケットのクライアント特徴機能フィールドのビット２１を使用して）特殊ステータス要求パケットに応答できることを示した場合、そのときは、それは少なくともクライアント機能パケット（パケットタイプ＝６６）と有効ステータス応答リストパケット（パケットタイプ＝１３９）を送信することが可能である。クライアントによって送信されることが出来、そしてこのリストの中に含められてよいパケットタイプは、一実施形態の目的のためのそのそれぞれの割り当てと共に、以下のとおりである：
６６−クライアント機能パケット
１３３−アルファ−カーソル画像機能パケット
１３９−クライアントが送信できる機能パケットとステータスパケットの正確なタイプを識別する有効ステータス応答リストパケット
１４０−パケット処理遅延パラメータパケット
１４１−パーソナルディスプレイ機能パケット
１４２−クライアントエラーレポートパケット
１４３−スケールドビデオストリーム機能パケット
１４４−クライアント識別パケット
１４５−代替ディスプレイ機能パケット
５６から６３までのパケットタイプは、−製造業者に特殊な機能識別子及び状態識別子のために使用されることができる。
ＣＲＣフィールドは、パケット長を含むパケット内の全てのバイトのＣＲＣを含む。
３７．パケット処理遅延パラメータパケット
パケット処理遅延パラメータパケットは、ホストが特定のパケットタイプの受信に関連した処理を完了するために必要とされる時間を計算するのを可能とする、パラメータのセットを提供する。ホストにより送信されるいくつかのコマンドは、ゼロ時間内にクライアントによって完了されることができない。ホストは、特定の機能がクライアントによって完了されたかどうかを判断するために、クライアント要求及びステータスパケットでステータスビットをポーリングしてよい、或いはホストは、パケット処理遅延パラメータパケットでクライアントにより返されるパラメータを使用して、完了時間を計算してよい。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストにおける１４０のパラメータ値を使用してパケット処理遅延パラメータパケットをサポートする能力を示すことが出来る。
パケット処理遅延パラメータパケットの一実施形態のフォーマットは、図８１Ａにおいて一般的に示されている。図８１Ａにおいて分かるように、パケット処理遅延パラメータパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、リストアイテム数フィールド、遅延パラメータリストフィールド、及びＣＲＣフィールドを有するように構造化されている。このタイプのパケットのパケット長は通常１０の値で固定され、１４０のタイプ値はパケットをパケット処理遅延パラメータパケットとして識別する。ｃＣｌｉｅｎｔ ＩＤフィールドは、クライアントＩＤとしての将来の使用に予約されており、通常ゼロに設定されている。２バイトのリストアイテム数フィールドは、続く有効パラメータ応答リストの中のアイテムの数を指定する。
遅延パラメータリストフィールドは、１つ又は複数の遅延パラメータリストアイテムを含むリストである。単一の遅延パラメータリストアイテムの一実施形態のためのフォーマットは、図８１Ｂに示されており、ここでは、遅延のためのパケットタイプフィールド、ピクセル遅延フィールド、水平ピクセル遅延フィールド、垂直ピクセル遅延フィールド、及び固定遅延フィールドが示されている。
各遅延パラメータリストアイテムは、一般に、長さが６バイトであるように制限されており、更に次のとおり定義されている。２バイトの遅延のためのパケットタイプフィールドは、以下の遅延パラメータが適用するパケットタイプを指定する。ピクセル遅延フィールド（１バイト）は、遅延値に対するインデックスを備える。表から読み取られる値は、パケットの宛先フィールドのピクセル総数で乗算される。ピクセル総数は、パケットによって参照されるビットマップの宛先領域の幅×高さである。１バイトの水平ピクセル遅延フィールドは、遅延値表（ＤＰＶＬと同じ表）に対するインデックスである値を含む。表から読み取られる値は、パケットの宛先フィールドの（ピクセル単位の）幅で乗算される。１バイトの垂直ピクセル遅延フィールドは、遅延値表（一般にＤＰＶＬと同じ表を使用する）に対するインデックスである値を含む。表から読み取られる値は、パケットの宛先フィールドの（ピクセル単位の）高さで乗算される。
固定遅延フィールドは、遅延値表（ＤＰＶＬと同じ表）に対するインデックスとして１バイトを使用する。表から読み取られる値は、パケットに指定されているどのパラメータ値にも関係のないパケットを処理するために必要とされる時間を表す固定遅延パラメータである。総遅延、又はパケット処理完了時間遅延は、次の関係に従って求められる。
◎
遅延＝（パケット処理遅延（ピクセル遅延）・ピクセル合計）＋
（パケット処理遅延（水平ピクセル遅延）・幅）＋
（パケット処理遅延（垂直ピクセル遅延）・高さ）＋
パケット処理遅延（固定遅延）
いくつかのパケットの場合、ピクセル合計、幅、又は高さは、それらのパラメータが対応するパケットにおいて参照されないので適用しない。それらのケースでは、対応するピクセル遅延パラメータは、一般にゼロに設定されている。
３８．パーソナルディスプレイ機能パケット
パーソナルディスプレイ機能パケットは、ヘッドマウントディスプレイ又はディスプレイ眼鏡のようなパーソナルディスプレイ装置の機能を記述するパラメータのセットを提供する。これは、ホストに、クライアントの特定の機能に従ってディスプレイ情報をカスタマイズするのを可能にする。クライアントは、他方、有効ステータス応答リストパケットの有効パラメータ応答リストの中の対応するパラメータを使用することによってパーソナルディスプレイ機能パケットを送信する能力を示す。
パーソナルディスプレイ機能パケットの一実施形態のフォーマットは、概して図８２において示されている。図８２において分かるように、パーソナルディスプレイ機能パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、サブピクセルレイアウトフィールド、ピクセル形状フィールド、水平視野フィールド、垂直視野フィールド、視軸交差フィールド、左／右画像フィールド、シースルーフィールド、最大輝度フィールド、光学機能フィールド、最小ＩＰＤフィールド、最大ＩＰＤフィールド、像面湾曲の点リストフィールド、及びＣＲＣフィールド(Packet Length, Packet Type, cClientID, Sub-Pixel Layout, Pixel Shape, Horizontal Field of View, Vertical Field of View, Visual Axis Crossing, Lft./Rt. Image, See Through, Maximum Brightness, Optical Capability, Minimum IPD, Maximum IPD, Points ofIFeld of Curvature List and CRC fields)を有するように構造化されている。一実施形態においては、パケット長フィールド値は６８で固定されている。１４１のパケットタイプ値は、パケットをパーソナルディスプレイ機能パケットとして識別する。ｃＣｌｉｅｎｔ ＩＤフィールドは将来の使用のために予約されており、一般に当面ゼロに設定されている。
サブピクセルレイアウトフィールドは、上から下への及び左から右へのサブピクセルの物理的なレイアウトを、次の値を使用して、指定する：すなわち、０はサブピクセルレイアウトが定義されていないことを示し；１は赤、緑、青の縞を示し；２は青、緑、赤の縞を示し；３は、左上に赤、右下に青、そして一方が左下で他方が右上の２個の緑のサブピクセルの、２×２のサブピクセル配列を有するクワッドピクセルを示し；４は、左下に赤、右上に青、そして一方が左上で他方が右下の２個の緑のサブピクセルの、２×２のサブピクセル配列を備えたクワッドピクセルを示し；５はデルタ（トライアド）を示し；６は、赤、緑及び青がオーバレイされた（例、フィールド順次色のＬＣＯＳディスプレイ）モザイクを示し；そして値７から２５５までは、将来の使用のために一般に予約されている。
ピクセル形状フィールドは、次の値を使用し、特殊な構成のサブピクセルから構成されている各ピクセルの形状を指定する:すなわち、０はサブピクセル形状が定められていないことを示し；１は円形を示し；２は正方形を示し；３は矩形を示し；４は長円を示し；５は楕円を示し；そして値６から２５５までは、当業者によって理解されることができるように、所望される形状を示す上での将来の使用のために予約されている。
１バイトの水平視野（ＨＦＯＶ）フィールドは、０．５度のインクリメントで水平視野を指定する（例、もしＨＦＯＶが３０度である場合、この値は６０である）。もしこの値がゼロである場合、そのときＨＦＯＶは指定されていない。
１バイトの垂直視野（ＶＦＯＶ）フィールドは、０．５度のインクリメントで垂直視野を指定する（例、もしＶＦＯＶが３０である場合、この値は６０である）。もしこの値がゼロである場合、そのときは、ＶＦＯＶは指定されていない。
１バイト視軸交差フィールドは、０．０１ジオプター（１／ｍ）インクリメントで視軸交差を指定する（例、視軸交差が２．２２メートルである場合、この値は４５である）。もしこの値がゼロである場合、そのときは、視軸交差は指定されていない。
１バイトの左／右画像重複フィールドは、左画像と右画像の重複のパーセンテージを指定する。画像重複の許容可能な範囲はパーセントで１から１００である。１０１から２５５の値は、無効であり、普通は使用されるべきでない。もしこの値がゼロである場合、そのときは、画像重複は指定されていない。
１バイトシースルーフィールドは、画像のシースルーパーセンテージを指定する。シースルーの許容範囲はパーセントで０から１００である。１０１から２５４の値は、無効であり、使用されるべきでない。もしこの値が２５５である場合、そのときは、シースルーパーセンテージは指定されていない。Ａ１バイト最大輝度フィールドは、２０ニットのインクリメントで最大輝度を指定する（例、もし最大輝度が１００ニットである場合は、この値は５である）。もしこの値がゼロである場合、そのときは、最大輝度は指定されていない。
２バイト光学機能フラグフィールドは、ディスプレイの光学機能を指定する多様なフィールドを含む。これらのビット値は、通常、以下に従って割り当てられる：
ビット１５から５までは、将来の使用のために予約され、一般に、論理ゼロ状態に設定されている。
ビット４はメガネ焦点調整を選択し、「０」の値はディスプレイにメガネ焦点調整がないことを意味し、「１」の値はディスプレイがメガネ焦点調整を有することを意味する。
ビット３から２までは、以下に従って両眼機能を選択する：０の値は、ディスプレイが両眼用であり、２次元（２Ｄ）画像だけを表示できることを意味し；１は、ディスプレイが両眼用であり、３次元（３Ｄ）画像を表示できることを意味し；２は、ディスプレイが単眼用であることを意味し；そして、３は将来の使用のために予約されている。
ビット１から０は、左右像面湾曲対称(Left-Right Field Curvature Symmetry)を選択し、０の値は、像面湾曲(Field Curvature)が定義されていないことを意味する。もしこのフィールドがゼロである場合、そのときは、Ａ１からＥ５までの全ての像面湾曲値は、点Ｃ３を除きゼロに設定されるべきであり、それはディスプレイの焦点距離を指定する或いは焦点距離が指定されていないことを示すためにゼロに設定されるべきである。１の値は、左右のディスプレイが同じ対称性を有することを意味し；２は、左右のディスプレイが垂直軸（列Ｃ）でミラーリングされていることを意味し；そして３は、将来の使用のために予約されている。
１バイト相互瞳孔間距離（ＩＰＤ）最小フィールドは、ミリメートル（ｍｍ）で最小の相互瞳孔間距離を指定する。もしこの値がゼロである場合、そのときは最小相互瞳孔間距離が指定されない。１バイトの相互瞳孔間距離（ＩＰＤ）最大フィールドは、ミリメートル（ｍｍ）で最大相互瞳孔間距離を指定する。もしこの値がゼロである場合、そのときは、最大相互瞳孔間距離は指定されない。
像面湾曲の点リストフィールド(the Points of Field Curvature)は、１から６５５３５（例、１は０．００１ジオプターであり、６５５３５は６５．５３５ジオプターである）の範囲でジオプター（１／ｍ）の千分の１で焦点距離を指定する、２５の２バイトパラメータのリストを含む。像面湾曲の点リストの中の２５のエレメントは、図８３において示されるようにＡ１からＥ５までラベルで表示されている。該点は、ディスプレイのアクティブ領域全体にわたって均一に分布されるべきである。列Ｃは、ディスプレイの垂直軸に対応し、行３はディスプレイの水平軸に対応する。列ＡとＥは、夫々、ディスプレイの左端縁と右端縁に対応する。そして、行１と５は、夫々、ディスプレイの上部端縁と下部端縁に対応する。リスト中の２５の点の順序は：Ａ１、Ｂ１、Ｃ１、Ｄ１、Ｅ１、Ａ２、Ｂ２、Ｃ２、Ｄ２、Ｅ２、Ａ３、Ｂ３、Ｃ３、Ｄ３、Ｅ３、Ａ４、Ｂ４、Ｃ４、Ｄ４、Ｅ４、Ａ５、Ｂ５、Ｃ５、Ｄ５、Ｅ５、である。
ＣＲＣフィールドは、パケット長を含むパケット内のすべてのバイトのＣＲＣを含む。
３９．クライアントエラーレポートパケット
クライアントエラーレポートパケットは、クライアントがホストに動作エラーのリストを提供することを可能にするための機構又は手段として働く。クライアントは、ホストからある特定のコマンドを受信した結果としてその通常の動作の過程において幅広い範囲のエラーを検出してよい。これらのエラーの例は以下を含む：クライアントはそれがサポートしていないモードで動作するように命令された可能性がある、クライアントは、範囲外である或いはクライアントの能力を超えているある特定のパラメータを含むパケットを受信した可能性がある、クライアントは不適切なシーケンスでモードに入るように命令された可能性がある。クライアントエラーレポートパケットは、通常の動作中にエラーを検出するために使用されることができるが、ホストシステムとクライアントシステムの開発及び統合における問題点を診断するシステム設計者と統合者にとって最も役に立つ。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストにおける１４２のパラメータ値を使用して、クライアントエラーレポートパケットを送信する機能を示す。
クライアントエラーレポートパケットの一実施形態のフォーマットは、概して図８４Ａにおいて示されている。図８４Ａにおいて分かるように、クライアントエラーレポートパケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、リストアイテム数フィールド、エラーコードリストフィールド、及びＣＲＣフィールドを有するように構造化されている。１４２のパケットタイプ値は、パケットをクライアントエラーレポートパケットとして識別する。ｃＣｌｉｅｎｔ ＩＤフィールドは、将来の使用のために予約され、一般に、当面はゼロに設定されている。リストアイテム数フィールド（２バイト）は、次のエラーコードリストの中のアイテム数を指定する。エラーコードリストフィールド（ここでは８バイト）は、１つ又は複数のエラーレポートリストアイテムを含むリストである。単一のエラーレポートリストアイテムのフォーマットは図８７Ｂにおいて示されている。
一実施形態においては、図８７Ｂに示されるように、各エラーレポートリストアイテムは、長さにおいて正確に４バイトであり、そして一実施形態においては、報告されているエラーのタイプを指定する２バイトのディスプレイエラーコードフィールドを備え、２バイトのエラーサブコードフィールドはクライアントエラーコードパケットにより定められるエラーに関してより大きなレベルの詳細を指定する、構造を有する。各クライアントエラーコードの固有の定義は、クライアントの製造業者によって定義されている。エラーサブコードは、全てのディスプレイエラーコードについて定義される必要はなく、そしてエラーサブコードが定義されていないそれらの場合には、該値はゼロに設定されている。各エラーサブコードの固有の定義はクライアントの製造業者により定義される。
４０．クライアント識別パケット
クライアント識別パケットは、クライアントが特殊ステータス要求パケットに応えて識別データを返すことを可能にする。一実施形態では、クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４４のパラメータ値を使用してクライアント識別パケットを送信する能力を示す。ホストが、クライアントからのこのデータを読み取ることによってクライアント装置の製造業者名及び型番を決定できるのは、有用である。情報は、クライアントがクライアント機能パケットに記述されることができない特殊な機能を有するかどうかを判断するために使用されてよい。クライアントから識別情報を読み取るための潜在的に２つの方法、手段又は機構がある。一方は、ベースＥＤＩＤ構造でのフィールドに類似するフィールドを含む、クライアント機能パケットの使用による。他方の方法は、クライアント機能パケット内の類似するフィールドに比較される、より優れた情報のセットを含むクライアント識別パケットの使用による。これは、ホストが、３文字ＥＩＳＡコードを割り当てられていない製造業者を識別するのを可能にし、シリアル番号が英数字文字を含むことを可能にする。
クライアント識別パケットの一実施形態のフォーマットは、概して図８５において示される。図８５において見られるように、クライアント識別パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、製造週フィールド、製造年フィールド、製造業者名の長さフィールド、製品名の長さフィールド、シリアル番号の長さフィールド、製造業者名文字列フィールド、製品名文字列フィールド、シリアル番号文字列フィールド、及びＣＲＣフィールドを有するように構造化されている。
２バイトのパケットタイプフィールドは、パケットをクライアント識別パケットとして識別する値を含む。この値は、一実施形態においては、１４４であるように選択される。ｃＣｌｉｅｎｔ ＩＤフィールド（２バイト）は再びクライアントＩＤ用の将来の使用のために予約され、一般にゼロに設定されている。ＣＲＣフィールド（２バイト）は、パケット長を含むパケット内のすべてのバイトの１６ビットＣＲＣを含む。
１バイトの製造週フィールドは、ディスプレイの製造週を定める値を含む。少なくとも一実施形態においては、この値は、もしそれがクライアントによってサポートされる場合は、１から５３までの範囲内にある。もしこのフィールドがクライアントによってサポートされていない場合、そのときは、それは一般にゼロに設定されている。１バイトの製造年フィールドは、クライアント（ディスプレイ）の製造の年を定める値を含む。他のベース年も使用されることができるであろうが、この値は開始点としての年１９９０からオフセットである。１９９１から２２４５の範囲の年が、このフィールドによって表されることができる。例：年２００３は１３の製造年値に対応する。このフィールドがクライアントによってサポートされていない場合には、それはゼロの値に設定されるべきである。
製造業者名の長さフィールド、製品名の長さフィールド、そして、シリアル番号の長さフィールドは、各々２バイトの値を含み、夫々、どんなヌル終端又はヌルパッド文字(any null termination or null pad characters)も含む製造業者名文字列フィールドの長さ、どんなヌル終端又はヌルパッド文字も含む製品名文字列フィールドの長さ、そして、どんなヌル終端文字又はヌルパッド文字も含むシリアル番号文字列フィールドの長さ、を指定する。
製造業者名文字列フィールド、製品名文字列フィールド、そして、シリアル番号文字列フィールドは、各々、製造業者名長フィールド、製品名フィールド、そして、シリアル番号フィールドによって夫々指定される可変数のバイトを含み、夫々、ディスプレイの製造業者、製品名、そして、英数字シリアル番号を指定するＡＳＣＩＩ文字列を含む。これらの文字列の各々は、少なくとも１つのヌル文字で終端する。
４１．代替ディスプレイ機能パケット
代替ディスプレイ機能パケット(the Alternate Display Capability Packet)は、ＭＤＤＩクライアントコントローラに取り付けられる代替ディスプレイの機能を示す手段、構造、又は方法として使用される。それは特殊ステータス要求パケットに応えて送信される。プロンプトを出されると、クライアント装置は、サポートされている各代替ディスプレイに対し代替ディスプレイ機能パケットを送信する。もしクライアントが２以上の代替ディスプレイを有する場合、そのとき、クライアントは、これは効率が少し悪いが、いくつかの構成は所望されるように複数の特殊ステータス要求パケットを使用できるが、単一の特殊ステータス要求パケットに応えて、複数の代替ディスプレイ機能パケットを、各ディスプレイに対しては１つ、送信、生成、又は提供しなければならない。クライアントは、代替ディスプレイナンバフィールド(the Alt Display Number field)の値に基づき、「不連続順序(non-sequential order)」と呼ばれることが出来る順序で、代替ディスプレイ機能パケットを送信してもよい。クライアントは、有効ステータス応答リストパケットの有効パラメータ応答リストの中の１４５のパラメータ値を介して代替ディスプレイ機能パケットを送信する能力を示すことが出来る。
内部モードで操作されているＭＤＤＩシステムの場合、ＭＤＤＩクライアントコントローラに接続される複数のディスプレイを有することは、一般的かもしれない。一例のアプリケーションは、フリップの内側に大型ディスプレイ、外側に小型のディスプレイを備えたモバイル電話である。２つの可能性のある理由のため、内部モードクライアントが代替ディスプレイ機能パケットを返すことは、必要ではない。第一に、機能が一般の装置又はハウジングの中で使われているので、ホストは既にプログラムされている又はそうでなければ製造中に機能を知らされている可能性がある。第二に、２つのアッセンブリのため、クライアントはホストへの接続から容易には切り離される又は分離されることが出来ず、そして、ホストは、クライアント機能のハードコードされたコピーを含んでいる、又は、それらはクライアントにおける変更があっても、そうでなければ発生するようには、変わらない、ということを少なくとも知っている可能性がある。
クライアント機能パケットの代替ディスプレイナンバフィールド(the Number of Alt Displays field of the Client Capability Packet)は、複数のディスプレイが取り付けられているということを報告するために使用され、そして代替ディスプレイ機能パケットが各代替ディスプレイの機能を報告する、る。ビデオストリームパケットは、クライアント装置の中の各代替ディスプレイに対処するためにピクセルデータ属性フィールドの中に４ビットを含む。
代替ディスプレイ機能パケットの一実施形態のフォーマットは、概して図８９において示されている。図８６において分かるように、代替ディスプレイ機能パケットは、パケット長フィールド、パケットタイプフィールド、ｃＣｌｉｅｎｔ ＩＤフィールド、代替ディスプレイナンバフィールド、予約１フィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、ディスプレイウィンドウ幅フィールド、ディスプレイウィンドウ高さフィールド、カラーマップＲＧＢ幅フィールド、ＲＧＢ機能フィールド、白黒機能フィールド、予約２フィールド、Ｙ Ｃｂ Ｃｒ機能フィールド、ディスプレイ特徴機能フィールド、予約３フィールド、及びＣＲＣフィールドを有するように構造化されている。１４５のパケットタイプ値は、パケットを代替ディスプレイ機能パケットとして識別する。ｃＣｌｉｅｎｔ ＩＤフィールドは、将来の使用のためのクライアントＩＤのために予約され、一般にゼロに設定されている。
代替ディスプレイナンバフィールドは、０から１５の範囲内の整数で代替ディスプレイの識別情報を示すために１バイトを使用する。第１の代替ディスプレイは、通常、数字０として示され、そしてその他の代替ディスプレイは、固有の代替ディスプレイナンバ値で識別され、使用されている最大数は、代替ディスプレイの総数から１を引いたものである。代替ディスプレイの総数から１を引いたものより大きい値は、使用されない。例：一次ディスプレイとＭＤＤＩクライアントに接続されている発呼者ＩＤディスプレイとを有するモバイル電話は、１つの代替ディスプレイを有するので、発呼者ＩＤディスプレイの代替ディスプレイナンバはゼロであり、クライアント機能パケットの代替ディスプレイナンバフィールドは１の値を有する。
予約１フィールド（１バイト）は、将来の使用のために予約されている。このフィールドの中のすべてのビットはゼロに設定されている。このフィールドの１つの目的は、全ての以後の２バイトフィールドを１６ビットのワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードのアドレスに位置合わせさせることである。
ビットマップ幅フィールドは、ピクセル数として表されるビットマップの幅を指定する２バイトを使用する。ビットマップ高さフィールドは、ピクセル数として表されるビットマップの高さを指定する２バイトを使用する。ディスプレイウィンドウ幅フィールドは、ピクセル数として表されるディスプレイウィンドウの幅を指定する２バイトを使用する。ディスプレイウィンドウ高さフィールドは、ピクセル数として表されるディスプレイウィンドウの高さを指定する２バイトを使用する。
カラーマップＲＧＢ幅フィールドは、カラーマップ（パレット）表示モードで表示されることが出来る赤、緑、及び青の色成分のビット数を指定する２バイトを使用する。色成分（赤、緑、及び青）ごとに最大８ビットが使用されることができる。８ビットの各色成分がカラーマップパケットで送信されるとしても、このフィールドに定義される各色成分の最下位ビットの数だけが使用される。もしディスプレイクライアントがカラーマップ（パレット）フォーマットを使用できない場合、このときはこの値はゼロである。カラーマップＲＧＢ幅ワードは、３つの別々の符号なし値から構成されている。
ビット３から０までは、各ピクセル内の青の最大ビット数を定義し、０から８の値が有効と考えられる。ビット７から４までは、各ピクセル内の緑の最大ビット数を定義し、０から８の値が有効と考えられる。ビット１１から８は、各ピクセル内の赤の最大ビット数を定義し、０から８の値が有効と考えられる。ビット１４から１２までは将来の使用のために予約されており、通常ゼロに設定されている。ビット１５は、パックフォーマット又はアンパックフォーマットでカラーマップピクセルデータを受け入れるクライアントの能力を示すために使用される。ビット１５が論理１レベルに設定されている時、これは、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでカラーマップピクセルデータを受け入れることができることを示す。もしビット１５が論理ゼロに設定される場合、これは、クライアントがアンパックフォーマットでのみカラーマップピクセルを受け入れることができることを示す。
ＲＧＢ機能フィールドは、ＲＧＢフォーマットで表示されることができる解像度のビット数を指定するための２バイトを使用する。一実施形態においては、もしクライアントがＲＧＢフォーマットを使用できない場合、このときこの値はゼロに等しく設定される。ＲＧＢ機能ワードは、次の３つの別々の符号なし値から構成されている：ビット３から０までは、各ピクセル内の青の最大ビット数（青輝度）を定義し、ビット７から４までは各ピクセル内の緑の最大ビット数（緑輝度）を定義し、そしてビット１１から８までは各ピクセル内の赤の最大ビット数（赤輝度）を定義する。ビット１４から１２までは将来の使用のために予約されており、ゼロに設定されている。ビット１５は、パックフォーマット又はアンパックフォーマットでＲＧＢピクセルデータを受け入れるためのクライアントの能力を示すために使用される。ビット１５が論理１レベルに設定されている時、これは、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでＲＧＢピクセルデータを受け入れることができることを示す。もしビット１５が論理ゼロに設定される場合、これは、クライアントがアンパックフォーマットだけでＲＧＢピクセルデータを受け入れることができることを示す。
１バイトの白黒機能フィールドは、白黒フォーマットで表示されることができる解像度のビット数を指定するための値又は情報を含む。もしクライアントが白黒フォーマットを使用できない場合、このときはこの値はゼロに等しく設定される。ビット６から４までは、将来の使用のために予約され、通常はゼロに設定されている。ビット３から０までは、各ピクセルに存在できるグレイスケールの最大ビット数を定義する。これらの４つのビットは、各ピクセルが１ビットから１５ビットのみからなることを指定することを可能にする。もし値がゼロである場合、このとき白黒フォーマットはクライアントによってサポートされていない。ビット７は、１に設定時、クライアントがパックフォーマット又はアンパックフォーマットのどちらかで白黒ピクセルデータを受け入れることができることを示す。もしビット７がゼロに設定されている場合、これはクライアントがアンパックフォーマットだけで白黒ピクセルデータを受け入れることができることを示す。
予約２フィールドは、将来の使用のために予約されている１バイト幅のフィールドであり、通常、このフィールドの中の全てのビットが論理ゼロレベルに設定されている。一実施形態では、このフィールドの一つの目的は、全ての以後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。
２バイトのＹ Ｃｂ Ｃｒ機能フィールドは、Ｙ Ｃｂ Ｃｒフォーマットで表示されることが出来る解像度のビット数を指定する。もしクライアントがＹ Ｃｂ Ｃｒフォーマットを使用出来ない場合、このときこの値はゼロである。Ｙ Ｃｂ Ｃｒ機能ワードは以下の３つの別々の符号なし値から構成されている。ビット３から０はまで、Ｃｂサンプルを指定する最大ビット数を定義し、ビット７から４まではＣｒサンプルを指定する最大ビット数を定義し、ビット１１から８まではＹサンプルを指定する最大ビット数を定義し、ビット１４から１２までは将来の使用のために予約され、ゼロに設定されている。ビット１５は、１に設定時に、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでＹ Ｃｂ Ｃｒピクセルデータを受け入れることが出来ることを示す。もしビット１５がゼロに設定されている場合、これはクライアントがＹ Ｃｂ Ｃｒピクセルデータをアンパックフォーマットだけで受け入れることが出来ることを示す。
２バイトＢａｙｅｒ機能フィールドは、解像度、ピクセルグループ及びＢａｙａｅｒフォーマットで転送できるピクセル順序のビット数を指定する。もしクライアントがＢａｙｅｒフォーマットを使用できない場合、このときこの値はゼロに設定されている。Ｂａｙｅｒ機能フィールドは次の値から構成されている：ビット３から０までは各ピクセルに存在する輝度の最大ビット数を定義し、ビット５から４までは、必要とされる可能性のあるピクセルグループパターンを定義し、ビット８から６までは必要とされるピクセル順序を定義し、そしてビット１４から９までは将来の使用のために予約され、ゼロに設定されている。ビット１５は、１に設定時、クライアントがパックフォーマット又はアンパックフォーマットのどちらかでＢａｙｅｒピクセルデータを受け入れることが出来ることを示す。もしビット１５がゼロに設定されている場合、これは、クライアントがアンパックフォーマットだけでＢａｙｅｒピクセルデータを受け入れることが出来ることを示す。
２バイトのＣＲＣフィールドは、パケット長を含むパケット内の全てのバイトの１６ビットＣＲＣを含む。
４２．レジスタアクセスパケット
レジスタアクセスパケットは、ホスト又はクライアントのどちらかに、ＭＤＤＩリンクの反対端の構成レジスタとステータスレジスタにアクセスする手段、機構又は方法を与える。レジスタは、各ディスプレイ又はデバイスコントローラに固有となる可能性がある。これらのレジスタは、設定構成、動作モードを必要とする多くのディスプレイに既に存在し、他の有用且つ必要な設定値を有している。レジスタアクセスパケットは、ＭＤＤＩホスト又はクライアントがレジスタに書き込むことをもＭＤＤＩリンクを使用してレジスタを読み取ることを要求することをも両方とも可能にする。ホスト又はクライアントがレジスタ読み取りを要求する時、反対端は、レジスタデータを同じパケットタイプで送信することによってだけでなく、これが読み取り／書き込み情報フィールドを使用して特定のレジスタから読み取られたデータであることを示すことによっても、応答しなければならない。レジスタアクセスパケットは、１より大きいレジスタカウントを指定することによって複数のレジスタを読み取る、又は書き込むために使用されてよい。クライアントは、クライアント機能パケットのクライアント特徴機能フィールドのビット２２を使用してレジスタアクセスパケットをサポートする能力を示す。クライアントは、レジスタアクセスパケットを送信するためにカプセル化パケットを使用し、その結果、パケットコンフィギュレーション或いは構造内にパケットとして現れるものを提供するであろう。
レジスタアクセスパケットの一実施形態のフォーマットは、概して図８７において示されている。図８７で分かるように、レジスタアクセスパケットは、パケット長フィールド、パケットタイプフィールド、ｂＣｌｉｅｎｔ ＩＤフィールド、読み取り／書き込みフラグフィールド、レジスタアドレスフィールド、パラメータＣＲＣフィールド、レジスタデータリストフィールド及びレジスタデータＣＲＣフィールドを有するように構造化されている。１４６のパケットタイプ値は、パケットをレジスタアクセスパケットとして識別する。ｂＣｌｉｅｎｔ ＩＤフィールドは、将来の使用のために予約されており、一般に、当面ゼロに設定されている。
２バイトの読み取り／書き込みフラグフィールドは、書き込み、又は読み取り、或いは読み取りに対する応答、の何れかとして特定のパケットを指定し、データ値のカウントを提供する。
ビット１５から１４までは、読み取り／書き込みフラグとして働く。もしビット［１５：１４］が「００」である場合、このときこのパケットはレジスタアドレスフィールドによってアドレス指定されるレジスタに書き込まれるべきデータを含む。指定されたレジスタに書き込まれるべきデータは、レジスタデータリストフィールドに含まれている。もしビット［１５：１４］が「１０」である場合、このときこれはレジスタアドレスフィールドによってアドレス指定される１つ又は複数のレジスタからのデータに対する要求である。もしビット［１５：１４］が［１１］である場合、このときそのパケットは、読み取り／書き込みフラグのビット１５：１４が「１０」に設定されているレジスタアクセスパケットに応じて要求されたデータを含む。レジスタアドレスフィールドは、第１のレジスタデータリストアイテムに対応するレジスタのアドレスを含み、そして、レジスタデータリストフィールドは、１つ又は複数のアドレスから読み取られたデータを含む。もしビット［１５：１４］が「０１」である場合は、これは無効値として処理され、この値は将来のために確保され、そして現時点では使用されないが、当業者は、将来のアプリケーションのためにそれをどのように使うかを理解するであろう。
ビット１３：０はレジスタデータリストフィールドで転送されるべき３２ビットのレジスタデータアイテムの数を指定するために１４ビットの符号なし整数を使用する。もしビット１５：１４が「００」に等しい場合、そのときビット１３：０は、レジスタアドレスフィールドにより指定されるレジスタで開始するレジスタに書き込まれるためにレジスタデータリストフィールドに含まれる３２ビットのレジスタデータアイテムの数を指定する。もしビット１５：１４が「１０」に等しい場合、そのときビット１３：０は、受信側装置がそのレジスタが読み取られるのを要求する装置に送信する３２ビットのレジスタデータアイテムの数を指定する。このパケットの中のレジスタデータリストフィールドは、アイテムを含まず、ゼロ長である。もしビット１５：１４が「１１」に等しい場合、このときビット１３：０は、レジスタデータリストフィールドに含まれているレジスタから読み取られた、３２ビットレジスタデータアイテムの数を指定する。ビット１５：１４は、無効値と見なされている「０１」に等しくは、現在のところ設定されておらず、そうではなくて将来の指定又は使用のために確保されている。
レジスタアクセスフィールドは、書き込まれるべき又は読み取られるべきレジスタアドレスを示すために４バイトを使用する。そのアドレス指定が３２ビット未満であるレジスタをアドレス指定する場合、上位ビットはゼロに設定される。
２バイトパラメータＣＲＣフィールドは、パケット長からレジスタアクセスまでの全てのバイトのＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。
レジスタデータリストフィールドは、クライアントレジスタに書き込まれるべき４バイトのレジスタデータ値又はクライアント装置レジスタから読み取られた値のリストを含む。
２バイトのレジスタデータＣＲＣＦフィールドは、レジスタデータリストだけのＣＲＣを含む。もしこのＣＲＣがチェックできない場合、このときレジスタデータは依然として使用されてよいが、ＣＲＣエラーカウントがインクリメントされる。
Ｄ．パケットＣＲＣ
ＣＲＣフィールドは、パケットの最後に、そして、ときには、著しく大きなデータフィールドを有するかもしれないパケット中のある種のよりクリティカルなパラメータの後に、現れる、従って、転送中のエラーの可能性が増加する。２つのＣＲＣフィールドを有するパケットにおいては、ＣＲＣジェネレータは、ただ一方だけが使用されるときに、長いデータフィールドの後のＣＲＣ計算がパケットの始まりでパラメータによって影響を及ぼされないように、第１のＣＲＣの後に再初期化される。
複数のビットエラーを含むパケットが良質のＣＲＣを生成する可能性はありそうもない(a remote mossibility)。エラーを含んだパケット上で良質のＣＲＣを検出する確率は、多くのエラーを含む非常に長いパケット上で７．６×１０−６に近づいている。設計によって、ＭＤＤＩリンクは、非常に低い又はゼロのエラーレートを有するであろう。ＣＲＣは、リンクの健全状態をモニタするために使用するように意図されており、パケットが再送信すべきかどうかを判断するために特定のパケット上のエラーを検出するようには意図されていない。
例示的な実施形態では、ＣＲＣ計算のために使用される多項式は、ＣＲＣ−１６、又はＸ１６＋Ｘ１５＋Ｘ２＋Ｘ０として知られている。本発明を実現するために有効なＣＲＣジェネレータとチェッカ３６００のサンプルインプリメンテーションが、図３６において示されている。図３６において、ＣＲＣレジスタ３６０２が、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｂｅｆｏｒｅ＿ＣＲＣライン上の入力であるパケットの第１のビットの転送の直前に０ｘ０００１の値に初期化され、次にパケットのバイトがＬＳＢで最初に開始するレジスタの中にシフトされる。この図のレジスタビット番号は、使用されている多項式の順序に対応するが、ＭＤＤＩによって使用されるビット位置には対応しない、ということに注意が必要である。単一方向でＣＲＣレジスタをシフトする方がより効率的であり、これは、ＭＤＤＩビット位置１４に達するまで、ＣＲＣビット１５をＭＤＤＩ ＣＲＣフィールドのビット位置０に、ＣＲＣレジスタビット１４をＭＤＤＩ ＣＲＣフィールドビット位置１に表示させる等の結果をもたらす。
一例として、もしクライアント要求ステータスパケットのパケットコンテンツが、０ｘ０００ｃ、０ｘ００４６、０ｘ０００、０ｘ０４００、０x００、０x００、０ｘ００００（或いは０ｘ０ｃ、０ｘ００、０ｘ４６、０ｘ００、０x００、０ｘ００、０x００、０ｘ０４、０ｘ００、０ｘ００、０ｘ００、０x００のようなバイトのシーケンスとして表わせる）であって、マルチプレクサ３６０４及び３６０６とＡＮＤゲート３６０８の入力を使用して提出される場合、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｗｉｔｈ＿ＣＲＣライン上で結果として生じるＣＲＣ出力は、０ｘｄ９ａａ（又は０ｘａａ、０ｘｄ９のようなシーケンスとして表わせる）である。
ＣＲＣジェネレータとチェッカ３６００が１つのＣＲＣチェッカとして構成されるとき、Ｒｘ＿ＭＤＤＩ＿Ｄａｔａライン上で受信されるＣＲＣは、マルチプレクサ３６０４と排他的ＯＲ（ＸＯＲ）ゲート３６１２に入力され、ＮＯＲゲート３６１０、ＡＮＤゲート３６０８、及びＡＮＤゲート３６１４を使用してＣＲＣレジスタ内で見つけられる値とビット単位で比較される。もし、ＡＮＤゲート３６１４による出力として、なんらかのエラーがある場合には、ゲート３６１４の出力をレジスタ３６０２の入力のに接続することにより、ＣＲＣは、ＣＲＣエラーを含む全てのパケットに対し一度インクリメントされる。図３６の図に示される例の回路が、既定のＣＨＥＣＫ＿ＣＲＣ＿ＮＯＷウィンドウ内で複数のＣＲＣエラー信号を出力できる（図３７Ｂを参照）、ということに注意を要する。従って、ＣＲＣエラーカウンタは、通常、ＣＨＥＣＫ＿ＣＲＣ＿ＮＯＷがアクティブである各間隔内に第１のＣＲＣエラインスタンスだけをカウントする。もしＣＲＣジェネレータとして構成される場合は、ＣＲＣは、パケットの最後と一致する時間に、ＣＲＣレジスタからの退出時間を記録される。
入力信号及び出力信号そしてイネーブル信号のタイミングが、図３７Ａ及び図３７Ｂにおいて図示されている。ＣＲＣの生成とデータのパケットの伝送が、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｂｅｆｏｒｅ＿ＣＲＣ信号及びＴｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｗｉｔｈ＿ＣＲＣ信号に加え、Ｇｅｎ＿Ｒｅｓｅｔ信号、Ｃｈｅｃｋ＿ＣＲＣ＿Ｎｏｗ信号、Ｇｅｎｅｒａｔｅ＿ＣＲＣ＿Ｎｏｗ信号及びＳｅｎｄｉｎｇ＿ＭＤＤＩ＿Ｄａｔａ信号の状態（０又は１）と共に、図３７Ａにおいて示されている。データのパケットの受信及びＣＲＣ値のチェックが、Ｒｘ＿ＭＤＤＩ＿Ｄａｔａ信号及びＣＲＣエラー信号に加え、Ｇｅｎ＿Ｒｅｓｅｔ信号、Ｃｈｅｃｋ＿ＣＲＣ＿Ｎｏｗ信号、Ｇｅｎｅｒａｔｅ＿ＣＲＣ＿Ｎｏｗ信号、及びＳｅｎｄｉｎｇ＿ＭＤＤＩ＿Ｄａｔａ信号の状態と共に図３７Ｂに示されている。
Ｅ．パケットＣＲＣのためのエラーコードオーバロード
データパケットとＣＲＣだけがホストとクライアントとの間で転送されている時はいつも、対処されているエラーコードはない。唯一のエラーは同期の損失である。それ以外の場合、リンクが良好なデータ転送経路又はパイプラインの欠如からタイムアウトするのを待機してから、リンクをリセットし、先に進まなければならない。残念なことに、これは多大な時間を必要とし、いくぶん非効率である。
一実施形態で使用するために、パケットのＣＲＣ部分がエラーコード情報を転送するために使用される新しい技術が開発された。これは概して図６５において示されている。すなわち、１つ又は複数のエラーコードが、通信処理又はリンクの内に発生する可能性のある特定の予め定められたエラー又は不具合を示すデータ転送を処理するプロセッサ又は装置によって作成される。エラーに遭遇すると、適切なエラーコードが作成され、パケットのＣＲＣのためのビットを使用して転送される。つまり、ＣＲＣ値は、ＣＲＣフィールドの値を監視するエラーモニタ又はチェッカによって受信端で検出されることができる所望されるエラーコードでオーバロードされるか、又は上書きされる。エラーコードが何らかの理由からＣＲＣ値に一致するケースでは、エラーのコンプリメント(compliment)が混乱を妨げるために転送される。
一実施形態では、ロバストなエラー警告検出システムを提供するために、エラーコードは、エラー検出後に転送又は送信される一連のパケット、通常は全て、を使用して、数回転送されてよい。これは、エラーを生じさせた状態がシステムから取り除かれる時点まで発生し、その時点ではいつもの(regular)ＣＲＣビットが別の値にオーバロードされることなく転送される。
ＣＲＣ値をオーバロードするこの技術は、最小量の余分なビット又はフィールドを使用しながらシステムエラーに対するはるかに迅速な対応を提供する。
図６６において示されているように、前に説明された或いは知られている他の回路網の一部を形成でき、通信リンク又はプロセスの中でのエラーの存在又は実在を検出する、エラー検出器又は検出手段６６０２を使用する、ＣＲＣ上書き機構又は装置６６００が示されている。他の回路網の一部として形成されることができる、或いは、事前に選択されるエラーメッセージを保存するためにルックアップテーブルのような技術を使用できる、エラーコードジェネレータ又は手段６６０４は、発生中として検出された特定の予め定義されたエラー又は不具合を示すために１つ又は複数のエラーコードを作成する。装置６６０２と６６０４は、所望されるように、単一の回路又は装置として、或いは他の知られたプロセッサとエレメントのためのプログラミングされたシーケンスのステップの一部として形成されることができることは容易に理解される。
１つ又は複数の選択されたエラーコードが転送されているＣＲＣ値と同じであるかどうかを確かめチェックするためのＣＲＣ値コンパレータ又は比較手段６６０６が示されている。そうである場合、そのときコードコンプリメントジェネレータ又は生成手段又は装置が、元のＣＲＣパターン又は値と間違われないように、そして検出方式を混乱させないように或いは複雑化しないように、エラーコードのコンプリメントを提供するために使用される。エラーコードセレクタ又は選択手段エレメント又は装置６６１０は、そのあと、挿入する又は上書きすることが所望されるエラーコード又は値を、或いは必要に応じてそれらのそれぞれのコンプリメントを、選択する。エラーコードＣＲＣオーバーラーター又は上書き機構又は手段６６１２は、挿入されるべき所望されるコード、パケット、データストリームを受信し、所望されるエラーコードを受信側装置に転送するために対応する又は適切なＣＲＣ値を上書きする装置である。
言及されたように、エラーコードは、一連のパケットを使用して数回転送されてよいため、オーバーライター６６１２は、処理中にコードのコピーを維持するためにメモリ記憶素子を利用してもよい、或いは、必要に応じて、又は所望されるように、それらの値を記憶する又は保存するために使用されることが出来る以前のエレメント又は他の知られた保存場所からこれらのコードを呼び戻してもよい。
図６６の上書き機構が実行する全般的な処理が、図６７Ａ及び図６７Ｂにおいて更に詳細に示されている。図６７Ａにおいて、１つ又は複数のエラーが、通信データ又はプロセスのステップ６７０２で検出され、そして、この状態を示すためにステップ６７０４でエラーコードが選択される。同時に、又は適切な時点で、置換されるべきＣＲＣ値はステップ６７０６においてチェックされ、そしてステップ６７０８で所望されるエラーと比較される。この比較の結果は、もっと前に説明されたように、所望されたコード又は他の代表的な値が現在のＣＲＣ値と同じであるかどうかに関する決定である。これが当てはまる場合、そのときは、処理はステップ６７１２に進み、ここで、所望されるような、コンプリメント或いはいくつかのケースでは別の代表値が、挿入するコードとして選択される。ステップ６７１０及び６７１４において、どのエラーコード又は値が挿入されるべきかがいったん決定されると、その適切なコードが挿入のために選択される。これらのステップは明確にするために別々に図示されているが、一般には、ステップ６７０８の決定の出力に基づき単一の選択を表す。最後に、ステップ６７１６において、プロセスのターゲットとされているパケットで転送するために、適切な値がＣＲＣロケーションに上書きされる。
パケット受信側では、図６７Ｂに示されるように、パケットＣＲＣ値は、ステップ６７２２で監視されている。一般的に、ＣＲＣ値は、データ転送においてエラーが発生したかどうか、そして、１つ又は複数のパケットの再送を要求するか否か、或いは更なる動作を抑制するかどうか等、を判断するために、システム内で１つ又は複数のプロセスによって監視されており、そのうちのいくつかは上記で説明されている。このような監視の一部として、情報は、値を知られた又は事前に選択されたエラーコード或いは代表的な値と比較し、エラーの存在を検出するためにも使用されることが出来る。代わりに、別々のエラー検出プロセスとモニタが実行されることが出来る。もしコードが存在すると考えられる場合、ステップ６７２４において、それは抽出され或いはそれ以外の場合は更なる処理のために注記される。これが実際のコードであるのかどうか或いはコンプリメントであるのかどうかについての決定がステップ６７２６において下されることが出来、その場合、更なるステップ６７２８が、値を所望されるコード値に変換するために使用される。どちらのケースでも、結果として生じる抽出されたコード、コンプリメント、又は他の回復された値は、そのあと、ステップ６７３０において、送信されたコードからどんなエラーが発生したのかを検出するために使用される。
Ｖ．リンクハイバネーション
ＭＤＤＩリンクは、ハイバネーション状態にすぐに入りそしてハイバネーションからすぐにウェイクアップ(wake up)することが出来る。それは使用のために非常に速く再度ウェイクアップできるので、この反応性は、通信システム又は装置が、消費電力を低減するために、ＭＤＤＩリンクをハイバネーションに頻繁に強制することを可能にする。一実施形態においては、外部モードのクライアントが初めてハイバネーションからウェイクアップするとき、それは、１Ｍｂｐｓと整合するストローブパルスタイミングとデータレートでそのように行なう、すなわち、ＭＤＤＩ＿Ｓｔｂペアは５００ｋＨｚレートで切り換わらなければならない(should toggle)。ひとたび、クライアントの特性が、ホストによって知られる或いはホストに伝達されると、そのあとホストは、１Ｍｂｐｓからクライアントが動作できる最大レートまでの概して任意のレートでリンクをウェイクアップできる。内部モードのクライアントは、ホストとクライアントの両方が動作できる任意のレートでウェイクアップできる。これは、内部モードのクライアントがウェイクアップする最初の時にもまた一般に適用可能である。
一実施形態においては、リンクがハイバネーションからウェイクアップする時、ホストとクライアントはパルスのシーケンス(a sequence of pulses)を交換する。最大リンク動作スピードで信号を受け取ることを要求される差動レシーバとして、わずかの電流のみを消費する、低速ラインレシーバを使って、これらのパルスは検出されることが出来る。ホスト又はクライアントの何れもリンクをウェイクアップできるので、ウェイクアッププロトコルは、もしホストとクライアントの両方が同時にウェイクアップしようとする場合に発生することがある、起こり得る競合に対処するように設計される。
ハイバネーション状態の間、ＭＤＤＩ＿ＤＡＴＡ及びＭＤＤＩ＿Ｓｔｂの差動ドライバは、高インピーダンス状態でディスエーブルされており、全ての差動ペア間の差動電圧はゼロボルトである。ハイバネーションからのウェイクアップの間にパルスのシーケンスを検出するために使用される差動ラインレシーバは、意図的な電圧オフセットを有する。一実施形態においては、これらのレシーバにおける、論理１と論理ゼロのレベル間の閾値は、約１２５ｍＶである。これは、駆動されていない差動ペアが、リンクウェイクアップシーケンスの間、論理ゼロレベルのように見られる原因となる。
ハイバネーション状態に入るために、ホストは、リンクシャットダウンパケットのＣＲＣの後に６４ＭＤＤＩ＿Ｓｔｂサイクルを送る。ホストは、ＣＲＣの後に１５ＭＤＤＩ＿Ｓｔｂサイクルから５６ＭＤＤＩ＿Ｓｔｂサイクルの範囲にあるホストのＭＤＤＩ＿Ｄａｔａ０出力をディスエーブルする（出力ディスエーブル伝播遅延を含む）。ホストは、それがウェイクアップシーケンスを起動する前に、リンクシャットダウンパケットのＣＲＣの後に６４ＭＤＤＩ＿Ｓｔｂサイクルを送ることを終える。一実施形態においては、ホスト起動ウェイクアップ(the host-initiated wake-up)は、ホストはＭＤＤＩ＿Ｓｔｂ上でパルスを駆動する前にＭＤＤＩ＿Ｄａｔａ０が有効論理１レベルに到達した後少なくとも１００ｎｓｅｃ待たなければならないと定められる。一実施形態においては、クライアントは、ホストをウェイクアップさせようとするためにそれがＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動する前にリンクシャットダウンパケットのＣＲＣの後、少なくとも６０ＭＤＤＩ＿Ｓｔｂサイクル待つ。
ハイバネーション状態から「ウェイクアップ」するために、幾つかのアクション或いはプロセスが取られる。クライアント、ここではディスプレイ、がホストからのデータ又は通信或いはサービスを必要とする時、それは、ＭＤＤＩ＿Ｄａｔａ０ラインを、約７０から１００μｓｅｃの間、論理１状態に駆動することによって要求パルスを発生する、一方、ＭＤＤＩ＿Ｓｔｂは、インアクティブにあり、ＭＤＤＩ＿Ｓｔｂがアクティブになった後の約７０ＭＤＤＩ＿Ｓｔｂサイクル（６０から８０の範囲にわたって）の間、ＭＤＤＩ＿Ｄａｔａ０ラインが論理１レベルに駆動されるのを保つが、他の期間は所望されるように使用されることが出来る。
もしＭＤＤＩ＿Ｓｔｂがハイバネーションの間アクティブであれば、起こりそうもないことではあるが、そのときは、クライアントは、約７０ＭＤＤＩ＿Ｓｔｂサイクル（６０から８０の範囲にわたって）の間、ＭＤＤＩ＿Ｄａｔａ０ラインを論理１状態に駆動しただけの可能性がある。この動作はホストに、順方向リンク（２０８）上でデータトラフィックを起動させ又は再起動させ、そしてこの状態についてクライアントに対するポーリングを行なわせる。
ホストは、要求パルスの存在を検出し、そして、ＭＤＤＩ＿Ｓｔｂを論理０レベルにそしてＭＤＤＩ＿Ｄａｔａ０を論理ｈｉｇｈレベルに、少なくとも約２００ｎｓｅｃの間、最初に駆動する起動シーケンスを開始しなければならない。そしてその後、トグリング(toggling)の間、ＭＤＤＩ＿Ｓｔｂは、ＭＤＤＩ＿Ｄａｔａ０を、論理１レベルに約１５０ＭＤＤＩ＿Ｓｔｂサイクル（１４０から１６０の範囲）の間、そして論理０レベルに約５０ＭＤＤＩ＿Ｓｔｂサイクルの間、駆動し続ける。クライアントは、もしそれが論理１状態のＭＤＤＩ＿Ｄａｔａ０を８０ＭＤＤＩ＿Ｓｔｂサイクルよりも長い間検出した場合は、サービス要求パルスを送るべきでない。クライアントが論理１レベルのＭＤＤＩ＿Ｄａｔａ０を６０から８０のＭＤＤＩ＿Ｓｔｂサイクルの間検出した時は、それは、ホストがＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに５０ＭＤＤＩ＿Ｓｔｂサイクルの持続期間駆動するところの間隔(the interval)をサーチし始める。ホストが、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに５０ＭＤＤＩ＿Ｓｔｂサイクルの持続期間駆動した後、そのときホストはリンク上でパケットを送ることを開始する。送られる最初のパケットはサブフレームヘッダパケットである。ＭＤＤＩ＿Ｄａｔａ０が、５０サイクル間隔の４０ＭＤＤＩ＿Ｓｔｂサイクルの間、論理ゼロレベルとなった後に、クライアントはサブフレームヘッダパケットを探し始める。ハイバネーションプロセス及び起動シーケンスに関連する時間間隔の許容差及び時間の選択の性質は、以下に更に説明される。（以下の図６８Ａ−Ｃを参照。）
ホストは、最初にＭＤＤＩ＿Ｓｔｂをイネーブルにし同時にそれを論理ゼロレベルに駆動することによって、ウェイクアップを起動してもよい。ＭＤＤＩ＿Ｓｔｂは、下記に説明されるようにパルスが出力されるまで論理１レベルに駆動されるべきでない。ＭＤＤＩ＿Ｓｔｂが論理ゼロに到達した後に、ホストは、ＭＤＤＩ＿Ｄａｔａ０をイネーブルにし、そして同時にそれを論理１レベルに駆動する。ＭＤＤＩ＿Ｄａｔａ０は、下記に説明されるように５０ＭＤＤＩ＿Ｓｔｂパルスの間隔の間にそれが論理ゼロレベルに駆動されるところの間隔までのウェイクアッププロセスの間では、論理ゼロレベルに駆動されるべきでない。ホストは、ＭＤＤＩ＿Ｓｔｂ上のパルスを駆動する前にＭＤＤＩ＿Ｄａｔａ０が有効論理１レベルに到達してから少なくとも２００ｎｓｅｃ待つ必要がある。このタイミングの関係は、ワーストケースの出力イネーブル遅延(the worst case output enable delays)を考慮する限り、存在する。これは、クライアントが、ホストによって駆動されたＭＤＤＩ＿Ｄａｔａ０上の論理１レベルによって起こされた(awakened)後に、そのＭＤＤＩ＿Ｓｔｂレシーバを十分にイネーブルにするための十分な時間を有することを、実質上保証する。
競合状態のない典型的なクライアントサービス要求イベント３８００のための処理ステップの例が、図３８において図示されており、ここでは、説明の便宜上、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ及びＧを使用してイベントがラベル表示されている。プロセスは、ホストがクライアント装置に、リンクが低電力ハイバネーション状態に遷移することをそれに知らせるために、リンクシャットダウンパケットを送信する時に点Ａで開始する。次のステップで、ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルし、そしてＭＤＤＩ＿Ｓｔｂドライバを、点Ｂで示されるように、論理ゼロに設定することによって、低電力ハイバネーション状態に入る。ＭＤＤＩ＿Ｄａｔａ０は、高インピーダンスバイアスネットワークによって論理ゼロレベルに駆動される。しばらくしてから、クライアントは、ＭＤＤＩ＿Ｄａｔａ０を、点Ｃで見られるように、論理１レベルに駆動することによって、サービス要求パルスをホストに送信する。ホストは、高インピーダンスバイアスネットワークを使用して依然として論理ゼロレベルをアサートするが、クライアントの中のドライバが強制的に回線を論理１レベルにする。５０μｓｅｃ以内に、ホストはサービス要求パルスを認識し、そして、点Ｄで見られるように、そのドライバをイネーブルすることによってＭＤＤＩ＿Ｄａｔａ０上で論理１レベルをアサートする。クライアントは、このあと、サービス要求パルスをアサートしようとするのやめ、そして、クライアントは、点Ｅで見られるように、そのドライバを高インピーダンス状態に置く。ホストは、点Ｆで示されるように、５０μｓｅｃの間ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、そしてまた、ＭＤＤＩ＿Ｄａｔａ０の論理ゼロレベルと整合する方法でＭＤＤＩ＿Ｓｔｂを生成し始める。クライアントは、ＭＤＤＩ＿Ｄａｔａ０が４０ＭＤＤＩ＿Ｓｔｂサイクルの間論理ゼロレベルであった後に、サブフレームヘッダパケットを探し始める。ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルにアサートしそしてＭＤＤＩ＿Ｓｔｂを５０μｓｅｃの間駆動した後に、ホストは、点Ｇで示されるように、サブフレームヘッダパケットを送信することにより順方向リンクでデータを送信することを開始する。
類似する例が、図３９において示されており、ここでは、リンク再起動シーケンスが開始した後にサービス要求がアサートされいる、そして、イベントは、また、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ及びＧを使用してラベル表示されている。これは、クライアントからの要求パルス又は信号がサブフレームヘッダパケットを破壊しそうになる最悪のケースのシナリオを表している。プロセスは、ホストがクライアント装置に、リンクが低電力ハイバネーション状態に遷移することをそれに知らせるために再びリンクシャットダウンパケットを送信するときに、点Ａで開始する。次のステップでは、ホストは、点Ｂで示されるように、ＭＤＩ＿Ｄａｔａ０ドライバをディスエーブルし、そしてＭＤＤＩ＿Ｓｔｂドライバを論理ゼロレベルに設定することによって、低電力ハイバネーション状態に入る。前記のように、ＭＤＤＩ＿Ｄａｔａ０は、高インピーダンスバイアスネットワークによって論理ゼロレベルに駆動される。しばらくすると、ホストは、点Ｃで見られるように１５０μｓｅｃの間論理１レベルにＭＤＤＩ＿Ｄａｔａ０を駆動することによってリンク再起動シーケンスを開始する。リンク再起動シーケンス開始後５０μｓｅｃが経過する前に、ディスプレイはまた、点Ｄで見られるように、７０μｓｅｃの持続期間ＭＤＤＩ＿Ｄａｔａ０をアサートする。これは、ディスプレイがホストからのサービスを要求する必要があり、ホストが既にリンク再起動シーケンスを開始したことを認識していないために、生じる。クライアントはそのあと、サービス要求パルスをアサートしようとすることをやめ、点Ｅで見られるように、クライアントはそのドライバを高インピーダンス状態に置く。ホストは、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動し続ける。ホストは、点Ｆに示されているように、５０μｓｅｃの間ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、そしてまた、ＭＤＤＩ＿Ｄａｔａ０での論理ゼロレベルと整合する方法でＭＤＤＩ＿Ｓｔｂを生成し始める。ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルにアサートしそしてＭＤＤＩ＿Ｓｔｂを５０μｓｅｃの間駆動した後に、ホストは、サブフレームヘッダパケットを送信することにより、順方向リンクでデータを送信することを開始する。
上記説明から、前の解決策は、ウェイクアップシーケンスの一部としてホストに２つの状態を経させることを伴ったことが分かる。第１の状態の場合、ホストは１５０μｓの間ＭＤＤＩ＿Ｄａｔａ０信号をｈｉｇｈに駆動し、そしてそのあと、ＭＤＤＩ＿Ｓｔｂラインをアクティブな状態にしながら５０μｓの間ＭＤＤＩ＿Ｄａｔａ０信号をｌｏｗに駆動し、そしてそのあとＭＤＤＩパケットを送信し始める。このプロセスは、ＭＤＤＩ装置及び方法を使用して達成可能なデータレートという観点から技術水準を高めるためにうまく働く。然しながら、前述されたように、状態に対する応答時間の短縮の観点からの更なるスピード、或いは次のステップ又はプロセスをより迅速に選択することが出来ること、はプロセス又はエレメントを簡略化する能力であり、いつも要求されている。
出願者は、ホストが信号トグリングのためにクロックサイクルベースのタイミングを使用するウェイクアッププロセス及びタイミングに対する新しい発明の手法を発見した。この構成では、ホストは、ホストがウェイクアップシーケンスの始まりにＭＤＤＩ＿Ｄａｔａ０信号をｈｉｇｈに駆動してから０から１０μｓｅｃ、ＭＤＤＩ＿Ｓｔｂのトグリングを開始し、そして信号がｌｏｗに駆動されるまで待機しない。ウェイクアップシーケンスの間、ホストは、ＭＤＤＩ＿Ｄａｔａ０信号がつねに論理ゼロレベルであるかのようにＭＤＤＩ＿Ｓｔｂを切り換える(toggle)。これは事実上クライアント側から時間の概念を排除し、そしてホストは、最初の２つの状態のための先の１５０μｓの期間と５０μｓの期間から、これらの期間のための、１５０クロックサイクルと５０クロックサイクルに変わる。
ホストは今、そのデータラインをｈｉｇｈに駆動することに責任を持つようになり、１０−クロックサイクル内に、データラインがゼロであるかのようにストローブ信号の送信を開始する。ホストが１５０クロックサイクルの間データラインをｈｉｇｈに駆動した後、ホストは、ストローブ信号を送信し続けながら５０クロックサイクルの間データラインをｌｏｗに駆動する。ホストは、これらのプロセスの両方ともを完了後、最初のサブフレームヘッダパケットの送信を開始できる。
クライアント側では、クライアントインプリメンテーションはここで、データラインが最初ｈｉｇｈでそして次にｌｏｗのクロックサイクル数を計算するために生成されたクロックを使用できる。両方において発生する必要のあるクロックサイクル数は、ｈｉｇｈ状態に駆動されたデータラインでは１５０であり、ｌｏｗ状態に駆動されたデータラインでは５０である。このことは、適切なウェイクアップシーケンスのために、クライアントは、ｌｏｗであるデータラインの少なくとも５０の連続クロックサイクルが後に続く、ｈｉｇｈであるデータラインの少なくとも１５０の連続クロックサイクルをカウントしなくてはならない、ということを意味する。いったんこれらの２つの条件が満たされると、クライアントは、第１のサブフレームの固有のワードの検索を開始できる。このパターンの中断は、カウンタを、クライアントがｈｉｇｈであるデータラインの最初の１５０連続クロックサイクルを再び探す、初期状態に戻すための根拠として使用される。
ホストベースのハイバネーションからのウェイクアップのための本発明のクライアントインプリメンテーションは、前述されたように、クロックレートが１Ｍｂｐｓでスタートするのを強制されないことを除き、初起動ケースに非常に類似している。代わりに、クロックレートは、通信リンクがハイバネーションに入った時はどんな前のレートでアクティブであっても、再開する(resume)ために設定されることができる。もしホストが前述されたようにストローブ信号の伝送を開始する場合は、クライアントは、ｌｏｗであるデータラインの少なくとも５０連続クロックサイクルが後に続く、ｈｉｇｈであるデータラインの少なくとも１５０連続クロックサイクルを再びカウントできなければならない。いったんこれらの２つの条件が満たされると、クライアントは固有のワードの検索を開始できる。
クライアントベースのハイバネーションからのウェイクアップのための本発明のクライアントインプリメンテーションは、それがクライアントにデータラインを駆動させていることによってスタートするという点を除き、ホストベースのウェイクアップに類似している。クライアントは、ホスト装置をウェイクアップするために、クロックを使用せずにデータラインを非同期で駆動できる。いったんホストが、データラインがクライアントによってｈｉｇｈに駆動されていると認識すると、それはそのウェイクアップシーケンスを開始できる。クライアントは、そのウェイクアッププロセスを開始する或いはそのウェイクアッププロセスの間の、ホストによって生成されるクロックサイクルの数をカウント出来る。いったんクライアントがｈｉｇｈであるデータの７０連続クロックサイクルをカウントすると、それはデータラインをｈｉｇｈに駆動するのを停止できる。この時点では、ホストは、既にデータラインを同様にｈｉｇｈに駆動しているべきである。クライアントは、次に、ｈｉｇｈであるデータラインの１５０クロックサイクルに達するために、ｈｉｇｈであるデータラインの別の８０連続クロックサイクルをカウント出来、そして次にｌｏｗであるデータラインの５０クロックサイクルを探すことができる。いったんこれらの３つの条件が満たされると、クライアントは固有のワードを探し始めることが出来る。
ウェイクアッププロセスのこの新しいインプリメンテーションの利点は、それが時間測定装置に対する必要性を排除することである。これが発振器であるのか、或いはコンデンサ放電回路であるのか、或いは他のこのような知られた装置であるのかに関係なく、クライアントは起動状態を確認するためにもはやこのような外部装置を必要としない。これは、コントローラ、カウンタ等をクライアント装置ボード上にインプリメントする時に、資金と回路面積を節約する。これは、クライアントにとって利点のようでないかもしれないが、ホストにとっては、この技術は、コア回路網のために使用されている超高密度論理回路（ＶＨＤＬ）の点で、ホストを潜在的に簡略化するはずである。コアエレメントがホストベースのウェイクアップを待機するために外部回路網が実行している必要がないため、ウェイクアップ通知及び測定ソースとしてデータライン及びストローブラインを使用することの電力消費も低くなる。使用されたサイクル又はクロック期間の数は例示的であり、当業者にとって明らかであるように他の期間が使用されることができる。
ウェイクアッププロセスのこの新しいインプリメンテーションの利点は、それが時間測定装置に対する必要性を排除することである。これが発振器であるのか、或いはコンデンサ放電回路であるのか、或いは他のこのような知られた装置であるのかに関係なく、クライアントは起動状態を確認するためにもはやこのような外部装置を必要としない。これは、コントローラ、カウンタ等をクライアント装置ボード上でインプリメントする時に、資金と回路面積を節約する。これは、クライアントにとって利点のようでないかもしれないが、ホストにとっては、この技術は、コア回路網のために使用されている超高密度論理回路（ＶＨＤＬ）の点で、ホストを潜在的に簡略化するはずである。コアエレメントがホストベースのウェイクアップを待機するために外部回路網が実行している必要はないため、ウェイクアップ通知及び測定ソースとしてデータライン及びストローブラインを使用することの電力消費も低くなる。
この新しい技術の動作を明確にしそして説明するために、ＭＤＤＩ＿Ｄａｔａ０、ＭＤＤＩ＿Ｓｔｂ、及びクロックサイクルに関連する多様な動作のタイミングが、図６８Ａ、図６８Ｂ及び図６８Ｃにおいて示されている。
競合のない典型的なホスト起動ウェイクアップのプロセスステップの例が、図６８Ａにおいて示されており、ここでは、イベントが再び、説明上便宜のために、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ及びＧを使用して、ラベル表示されている。プロセスは、ホストがクライアント装置にリンクシャットダウンパケットを、それにリンクが低電力ハイバネーション状態に遷移することを知らせるために、送信する時、点Ａで開始する。次のステップ、点Ｂでは、ホストは、ＭＤＤＩ＿Ｓｔｂが切り替わるのを(toggling)停止する前にクライアントによる処理が完了されるのを可能とするために、約６４サイクル（或いはシステム設計のために所望されるとおりに）ＭＤＤＩ＿Ｓｔｂを切り換え(toggle)、クライアント装置内の回復したクロックを停止する。ホストはまた、初めにＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに設定し、それから、ＭＤＤＩ＿Ｄａｔａ０出力を、ＣＲＣ後に１６サイクルから４８サイクル（通常は出力ディスエーブル伝播遅延を含む）の範囲でディスエーブルする。ＣＲＣから４８サイクル後で次の段階（Ｃ）の前に、しばらく、クライアント内のＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのための高速レシーバを低電力状態に置くことは望ましいかもしれない。クライアントは、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのためのその高速レシーバを、リンクシャットダウンパケットのＣＲＣ後の４８番目のＭＤＤＩ＿Ｓｔｂサイクルの立ち上がり後のいつでも、ハイバネーションに置く。クライアントが、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのためのその高速レシーバを、リンクシャットダウンパケットのＣＲＣ後の６４番目のＭＤＤＩ＿Ｓｔｂサイクルの立ち上がりの前にハイバネーションに置くこと、が推奨される。
ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバとＭＤＤＩ＿Ｓｔｂドライバをディスエーブルしそしてホストコントローラを低電力ハイバネーション状態にすることによって、点又はステップＣで、低電力ハイバネーション状態に入る。所望されるように、ＭＤＤＩ＿Ｓｔｂドライバを、論理ゼロレベルに（高インピーダンスバイアスネットワークを使用して）、或いは、ハイバネーションの間トグリングを続けるように、設定するもまたことが出来る。クライアントもまた低電力レベルハイバネーション状態にある。
しばらくの期間後、ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバ出力とＭＤＤＩ＿Ｓｔｂドライバ出力をイネーブルすることによって、点Ｄでリンク再起動シーケンスを開始する。ホストは、ドライバがそのそれぞれの出力を完全にイネーブルにするために要する時間の限り、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルにそしてＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに駆動する。ホストは、通常、ＭＭＤＩ＿Ｓｔｂ上でパルスを駆動する前に、これらの出力が所望される論理レベルに達してから約２００ナノ秒待機する。これは、クライアントに受信する準備をする時間を与える。
ホストドライバがイネーブルされ、そしてＭＤＤＩ＿Ｄａｔａ０が論理１レベルに駆動されている状態で、ホストは、点Ｅで見られるように、１５０ＭＤＤＩ＿Ｓｔｂサイクルの持続期間中、ＭＤＤＩ＿Ｓｔｂのトグルを開始する。ホストは、点Ｆで示されているように、５０サイクルも間、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、そしてクライアントは、ＭＤＤＩ＿Ｄａｔａ０が４０ＭＤＤＩ＿Ｓｔｂサイクルの間論理ゼロレベルにあった後にサブフレームヘッダパケットを探し始める。ホストは、点Ｇで示されているように、サブフレームヘッダパケットを送信することによって順方向リンクでデータ送信を開始する。
競合のない典型的なクライアント起動ウェイクアップのプロセスステップの例が、図６８Ｂにおいて示されており、ここでは、説明上便宜のために、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ及びＩを使用して、イベントがラベル表示されている。前記のように、プロセスは、ホストが、リンクが低電力状態に遷移することをクライアントに知らせるために、リンクシャットダウンパケットを送信する時に、点Ａで開始する。
点Ｂで、ホストは、ＭＤＤＩ＿Ｓｔｂが切り替わるのを(toggling)停止する前にクライアントによる処理が完了されるのを可能にするために約６４サイクル（又はシステム設計のために所望されるとおりに）ＭＤＤＩ＿Ｓｔｂを切り換え(toggle)、クライアント装置内の回復されたクロックを停止する。ホストはまた、最初にＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに設定し、次にＣＲＣ後に１６から４８サイクル（通常は出力ディスエーブル伝搬遅延を含む）の範囲でＭＤＤＩ＿Ｄａｔａ０出力をディスエーブルする。ＣＲＣ後のＣＲＣから４８サイクル後で次の段階（Ｃ）の前に、しばらく、クライアント内のＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂのための高速レシーバを低電力状態に置くことは望ましいかもしれない。
ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバとＭＤＤＩ＿Ｓｔｂドライバをディスエーブルしそしてホストコントローラを低電力ハイバネーション状態に置くことによって、点又はステップＣで、低電力ハイバネーション状態に入る。所望されるように、ＭＤＤＩ＿Ｓｔｂドライバを、論理ゼロレベルに（高インピーダンスバイアスネットワークを使用して）、或いは、ハイバネーションの間トグリングを続けるように、設定することも又出来る。クライアントもまた低電力レベルハイバネーション状態にある。
しばらくの期間後、クライアントは、ＭＤＤＩ＿Ｓｔｂレシーバをイネーブルにすることによって、そして又、ホストがそのＭＤＤＩ＿Ｓｔｂドライバをイネーブルにする前にＭＤＤＩ＿Ｓｔｂの受信されたバージョンの状態はクライアントにおいて論理ゼロレベルであることを保証するために、ＭＤＤＩ＿Ｓｔｂレシーバ内のオフセットをイネーブルにすることによって、点Ｄで、リンク再起動シーケンスを開始する。所望されるように、有効な差動信号の受信を保証しそして誤りのある信号を抑止するために、クライアントが、レシーバをイネーブルにするのよりわずかに先にオフセットをイネーブルにすることが望ましいかもしれない。クライアントは、ＭＤＤＩ＿Ｄａｔａ０ラインを論理１レベルに駆動しながら、ＭＤＤＩ＿Ｄａｔａ０ドライバをイネーブルにする。もし、オフセットをイネーブルにし標準ＭＤＤＩ＿Ｓｔｂ差動レシーバをイネーブルにする時間が２００ナノ秒よりも短い場合は、ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂが同時にイネーブルにされるのが可能となる。
約１ｍｓｅｃ以内に、点Ｅ内に、ホストはクライアントからのサービス要求パルスを認識し、そしてホストはＭＤＤＩ＿Ｄａｔａ０ドライバ出力とＭＤＤＩ＿Ｓｔｂドライバ出力とをイネーブルにすることによってリンク再起動シーケンスを開始する。ホストは、ドライバがそのそれぞれの出力をイネーブルするのに要する限り、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルにそしてＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに駆動する。ホストは通常、ＭＤＤＩ＿Ｓｔｂ上でパルスを駆動する前にこれらの出力が所望される論理レベルに達してから約２００ナノ秒待機する。これは、クライアントに受信する準備をする時間を与える。
ホストドライバがイネーブルにされそしてＭＤＤＩ＿Ｄａｔａ０が論理１レベルに駆動されている状態で、ホストは、点Ｆで見られるように、１５０ＭＤＤＩ＿Ｓｔｂサイクルの持続期間、ＭＤＤＩ＿Ｓｔｂ上でパルスを出力し始める。クライアントは、ＭＤＤＩ＿Ｓｔｂ上で最初のパルスを認識する時、それはそのＭＤＤＩ＿Ｓｔｂレシーバ内のオフセットをディスエーブルする。クライアントは、７０ＭＤＤＩ＿Ｓｔｂサイクルの間論理１レベルにＭＤＤＩ＿Ｄａｔａ０を駆動し続け、そして、点ＧでＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルする。ホストは、更なる８０ＭＤＤＩ＿Ｓｔｂパルスの持続期間、間論理１レベルにＭＤＤＩ＿Ｄａｔａ０を駆動し続け、そして、点ＨでＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動する。
点ＧとＨで見られるように、ホストは５０サイクルの間ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、クライアントは、ＭＤＤＩ＿Ｄａｔａ０が４０ＭＤＤＩ＿Ｓｔｂサイクルの間論理ゼロレベルにあった後サブフレームヘッダパケットを探し始める。ＭＤＤＩ＿Ｓｔｂを５０サイクルの持続期間駆動した後、ホストは、点Ｉで見られるように、サブフレームヘッダパケットを送信することにより順方向リンク上でデータ送信を開始する。
クライアントからの競合がある、つまりクライアントもまたリンクをウェイクアップすることを望む、典型的なホスト起動ウェイクアップのためのプロセスステップの例が、図６８Ｃにおいて示されている。イベントは再び、説明上の便宜のために、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ及びＩを使用して、ラベル表示されている。前記のように、プロセスは、ホストが、リンクが低電力状態に遷移することをクライアントに知らせるために、リンクシャットダウンパケットを送信する時に、点Ａで開始し、クライアントによる処理が完了するのを可能とするためにＭＤＤＩ＿Ｓｔｂが約６４サイクルの間（又はシステム設計のために所望されるとおりに）切り換えられる(toggled)点Ｂに進み、それから、ＭＤＤＩ＿Ｄａｔａ０ドライバとＭＤＤＩ＿Ｓｔｂドライバをディスエーブルしそしてホストコントローラを低電力ハイバネーション状態に置くことによって、ホストが低電力ハイバネーション状態に入る、点Ｃに進む。しばらくの期間の後、ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバ出力とＭＤＤＩ＿Ｓｔｂドライバ出力をイネーブルすることによって、点Ｄでリンク再起動シーケンスを開始し、そして、点Ｅで見られるように、１５０ＭＤＤＩ＿Ｓｔｂサイクルの持続期間、ＭＤＤＩ＿Ｓｔｂを切り換えること(to toggle)を開始する。
点Ｅの後、７０ＭＤＤＩ＿Ｓｔｂサイクルまでのところ、ここ点Ｆで、クライアントは未だ、ホストがＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動していることを認識していないので、クライアントもまたＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動する。これは、クライアントが、サービスを要求する望みを有するがしかしそれが通信しようとしているホストが既にリンク再起動シーケンスを開始していることを認識していないために、ここで発生する。点Ｇでは、クライアントは、ＭＤＤＩ＿Ｄａｔａ０を駆動するのをやめ、そして、その出力をディスエーブルすることによってそのドライバを高インピーダンス状態にする。ホストは、追加の８０サイクルの間ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動し続ける。
ホストは、点Ｈで示されているように、５０サイクルの間、ＭＤＤＩ＿Ｄａｔａ０を論理ゼロレベルに駆動し、そしてクライアントは、ＭＤＤＩ＿Ｄａｔａ０が４０ＭＤＤI＿Ｓｔｂサイクルの間論理ゼロレベルにあった後にサブフレームヘッダパケットを探し始める。ホストは、点で示されているように、サブフレームヘッダパケットを送信することによって順方向リンク上でデータの転送を開始する。
ＶＩ．インタフェース電気仕様
例の実施形態では、非ゼロ復帰(a Non-Return-to-Zero)（ＮＲＺ）フォーマットは、クロック情報をデータ信号とストローブ信号の中に埋め込むことを可能にするデータ−ストローブ信号又はＤＡＴＡ−ＳＴＢフォーマットを使用して符号化される。クロックは、複雑な移送ロックループ回路網を使用しなくても回復できる。前述されたように、他の導線、プリント配線、又は転送エレメントが使用されることが出来るが、通常はワイヤラインケーブルを使用して実現される、双方向差動リンク上で、データは伝搬される。ストローブ（ＳＴＢ）信号は、ホストによってのみ駆動される単向性のリンク上で伝搬される。ストローブ信号は、データライン又は信号上で同じ状態のままである、連続状態、０又は１、がある時はいつも値（０又は１）を切り替える(toggle)。
どのようにして「１１１０００１０１１」のようなデータシーケンスがＤＡＴＡ−ＳＴＢ符号化を使用して送信されることが出来るかの例が、図４０においてグラフの形で示されている。図４０では、ＤＡＴＡ（データ）信号４００２は信号タイミングチャートの一番上の行に示され、そしてＳＴＢ（ストローブ）信号４００４は２番目の行に示され、毎回適宜位置合わせされている（共通開始点）。時間の経過と共に、データライン４００２（信号）で発生する状態の変化がある時、そのときＳＴＢライン４００４（信号）は前の状態を維持し、このように、ＤＡＴＡ信号の第１の「１」状態は、ＳＴＢ信号の第１の「０」状態、その開始値、と相関関係にある。然しながら、もし又は、ＤＡＴＡ信号の状態、レベル、が変化しない時、そのときＳＴＢ信号は、ＤＡＴＡが別の「１」値を提供する図４０におけるケースのように、反対の状態、つまり今の例においては「１」に切り替わる(toggle)。つまり、ＤＡＴＡとＳＴＢの間にはビットサイクルあたりただ１つの遷移しかない。従って、ＤＡＴＡ信号が「１」でとどまるときＳＴＢ信号は再び、今回は「０」に、遷移し、そしてＤＡＴＡ信号がレベルを「０」に変えるときこのレベル又は値を保持する。ＤＡＴＡ信号はレベル又は値を変える或いは保持するので、ＤＡＴＡ信号が「１」にとどまる時は、ＳＴＢ信号は、反対の状態つまり今の例においては「１」に切り替わる(toggle)、などである。
これらの信号を受信すると、所望されるデータ信号とストローブ信号との相対比較のためにタイミングチャートの下部に示されている、クロック信号４００６を生成するために、ＤＡＴＡ信号とＳＴＢ信号とに関し排他的ＯＲ（ＸＯＲ）演算が実行される。ホストにある入力データからＤＡＴＡとＳＴＢの出力又は信号を生成し、そのあとクライアントでＤＡＴＡ及びＳＴＢの信号からをデータを回復する又は再現するための有用な回路網の１例が図４１において示されている。
図４１において、伝送部分４１００は、中間信号経路４１０２上でオリジナルのＤＡＴＡ信号とＳＴＢ信号を生成し送信するために使用される、一方、受信部分４１２０は、信号を受信し、そしてデータを回復するために使用される。図４１において示されるように、ホストからクライアントにデータを転送するために、ＤＡＴＡ信号は、回路をトリガするためのクロック信号と共に、２つのＤ型フリップフロップ回路エレメント４１０４と４１０６に入力される。２つのフリップフロップ回路出力（Ｑ）は、そのあと、２つの差動ラインドライバ４１０８と４１１０（電圧モード）を使用し、夫々、信号ＭＤＤＩ＿Ｄａｔａ０＋、ＭＤＤＩ＿Ｄａｔａ０−、そしてＭＤＤＩ＿Ｓｔｂ＋、ＭＤＤＩ＿Ｓｔｂ−の差動ペアに分かれる。３入力排他的ＮＯＲ（ＸＮＯＲ）ゲート、回路、又は論理素子４１１２は、両方のフリップフロップのＤＡＴＡと出力を受信するために接続され、そして、同様にＭＤＤＩ＿Ｓｔｂ＋信号、ＭＤＤＩ＿Ｓｔｂ−信号を生成する第２のフリップフロップにデータ入力を供給する出力を生成する。便宜上、ＸＮＯＲゲートは、それがストローブを生成するフリップフロップのＱ出力を有効に反転していることを示すように設置された反転バブル(inversion bubble)を有する。
図４１の受信部分４１２０では、ＭＤＤＩ＿Ｄａｔａ０＋信号、ＭＤＤＩ＿Ｄａｔａ０−信号、そしてＭＤＤＩ＿Ｓｔｂ＋信号、ＭＤＤＩ＿Ｓｔｂ−信号が、差動信号から単一の出力を生成する２つの差動ラインレシーバ４１２２と４１２４の各々によって受け取られる。増幅器の出力はそのあと、クロック信号を生成する２入力排他的ＯＲ（ＸＯＲ）ゲート、回路、又は論理素子４１２６の入力の各々に入力される。クロック信号は、遅延素子４１３２を通してＤＡＴＡ信号の遅延バージョンを受信する２つのＤ型フリップフロップ回路４１２８と４１３０の各々をトリガするために使用され、その内の一方（４１２８）はデータ「０」値を生成し、他方（４１３０）はデータ「１」値を生成する。クロックは、ＸＯＲ論理に依存しない出力も同様に有する。クロック情報はＤＡＴＡラインとＳＴＢラインとの間に分配されるので、どの信号も、クロックレートの半分よりも速く状態の間を遷移しない。クロックは、ＤＡＴＡ信号とＳＴＢ信号の排他的ＯＲ処理を使用して再生されるので、システムは、クロック信号が単一の専用データライン上で直接的に送信される時の状況に比べて、入力データとクロックとの間の歪み量の二倍を実質上許容する。
ＭＤＤＩ ＤＡＴＡペア、ＭＤＤＩ＿Ｓｔｂ＋信号及びＭＤＤＩ＿Ｓｔｂ−信号は、ノイズの負の影響からの免疫を最大限にするために差動モードで運用される。各差動ペアは、信号を転送するために使用されているケーブル又は導線の特性インピーダンスで並列に終端されている。概して、全ての並列終端はクライアント装置の中にある。これは、順方向トラフィック（データはホストからクライアントに送られる）のための差動レシーバに近いが、逆方向トラフィック（データはクライアントからホストに送られる）のためのケーブル又は他の導線又は転送エレメントの駆動端にある。逆方向トラフィックの場合、信号は、クライアントによって駆動され、ホストでの高インピーダンスによって反射され、そしてクライアントで終端となる。他のところで説明されたように、逆方向データ又は逆方向リンク上のデータは、ケーブルにおける往復遅延の逆数よりも大きなデータレートで転送又は送信されることが出来る。ＭＤＤＩ＿Ｓｔｂ＋及びＭＤＤＩ＿Ｓｔｂ−の導線又は信号は、ホストによって駆動されるだけである。
本発明のＭＤＤIの一部として信号を転送するためのドライバ、レシーバ及び終端を実現するために有用なエレメントの１例示的構成が、図４２において示されている。この例示的インタフェースは、１ボルト未満の振幅(swing)と低電力消費(low power drain)で、低電圧検知、ここでは２００ｍＶ、を使用する。各信号ペアのドライバは、差動電流出力を有する。ＭＤＤＩパケットを受信するのであるが、ＭＤＤＩ＿ＤａｔａとＭＤＤＩ＿Ｓｔｂのペアは、ゼロボルトの差動電圧閾値を持った従来の差動レシーバを使用する。ハイバネーション状態においては、ドライバ出力はディスエーブルされ、そして並列終端レジスタは、各信号ペア上の差動電圧をゼロボルトに引っ張る。ハイバネーションの間、ＭＤＤＩ＿Ｄａｔａ０ペア上の特別のレシーバは、ハイバネーションラインレシーバに論理ゼロレベルとして駆動されていない信号ペアを解釈させる、正の１２５ｍＶのオフセット入力差動閾値を有する。
差動ペアの差動電圧は、正（＋）の信号上の電圧から負（−）の信号上の電圧を引いた差として定義される。差動ペア信号の名称は「＋」又は「−」のどちらかで終わり、夫々、ペアの正又は負の信号を示す。差動ペアのドライバの出力電流は、正（＋）の出力から流れる電流とし定義される。差動ドライバの負（−）の出力を通して流れる電流は、同じ差動ドライバの正（＋）の出力を通して流れる電流と比較して、いつも、大きさが等しいが、方向が反対である。
時々、ホスト又はクライアントは、データの流れ方向が変わる（ホストからクライアントへ、又は、クライアントからホストへ）時にペア上の有効な論理レベルを保証するために、差動ペアを論理１レベル又は論理ゼロレベルに同時に駆動する。出力電圧範囲と出力仕様は依然と、同じ論理レベルに駆動される同時駆動される出力に満たされる。幾つかのシステムにおいては、ハイバネーション中のある時間にそしてリンクがハイバネーション状態からウェイキングアップ(waking up)する時に小さなオフセット電圧を生成するために、小さな電流を終端となる差動ペアに駆動することが必要であるかもしれない。それらの状況下では、イネーブル状態のオフセット電流バイアス回路は、次のように参照される電流レベルを駆動する：ＩＥＳＤ−ａｎｄ−Ｒｘ−内部ＥＳＤダイオード及び差動レシーバ入力、但し一般にＩＥＳＤ−ａｎｄ−Ｒｘ≦１μＡ；ＩＴｘ−Ｈｉ―Ｚ−高インピーダンス状態における差動ドライバ出力、但し一般にＩＴｘ−Ｈｉ―Ｚ≦１μＡ；そしてＩｅｘｔｅｒｎａｌ−ＥＳＤ−外部ＥＳＤ保護ダイオードを通してのリーク、但し一般にＩｅｘｔｅｒｎａｌ−ＥＳＤ≦３μＡ。
これらのリーク電流の各々は、図４７において図示されている。プルアップ及びプルダウン回路は、全てが同時に発生する時の上記説明されたワーストケースのリーク状態の下で、最小差動電圧を達成する必要がある。全リークは、外部ＥＳＤ保護ダイオード無しの内部モードの場合、≦４μＡ、そして、外部ＥＳＤ保護ダイオード付の外部モードの場合、≦１０μＡである。
一例示的な実施形態のための差動ラインドライバと差動ラインレシーバの電気的なパラメータと特性が、表ＶＩＩａ−ＶＩＩｄにおいて記述されている。機能的に、ドライバは、入力上での論理レベルを直接的に正の出力に、入力の逆数を負の出力に転送する。入力から出力への遅延は、差動的に駆動される差動ラインに十分に整合されている。大部分のインプリメンテーションでは、出力での電圧振幅は、電力消費と電磁放射線を最小限に抑えるために、入力での振幅より少ない。一実施形態においては、約０．５Ｖの最小電圧振幅がある。然しながら、当業者により知られるであろうように、他の値が使用されることができ、そして発明者らは、設計の制約に応じ、いくつかの実施形態においては、より小さい値を意図する。
差動ラインレシーバは、高速電圧コンパレータと同じ特性を有する。図４１において、バブル(the bubble)のない入力は正の入力であり、バブルのある入力は負の入力である。出力は、もし（Ｖｉｎｐｕｔ＋）−（Ｖｉｎｐｕｔ−）がゼロより大きい場合には、論理１である。これを説明する別の方法は、出力が論理０と１の電圧レベルでクリップされた(clipped)、非常に大きな（事実上無限の）利得を有する差動増幅器、である。
異なるペア間の遅延歪みは、差動伝送システムを最も高速の潜在的スピードで動作させるために、最小限に抑えられるべきである。
Figure 2007528681
Figure 2007528681
Figure 2007528681
Figure 2007528681
図４２において、通信リンク４２０６上でパケットを転送しているホストコントローラ４２０２とクライアント又はディスプレイコントローラ４２０４が示されている。ホストコントローラは、転送されるべきクライアントＤＡＴＡ信号を受信するためにだけではなく、転送されるべきホストＤＡＴＡ信号とホストＳＴＢ信号を受信するために、一連の３つのドライバ４２１０、４２１２、及び４２１４を使い、一方クライアントは、３つのドライバ４２３０、４２３２、及び４２３４を使う。ホストＤＡＴＡ（４２１２）の通過に関与するドライバは、一般にホストからクライアントへの転送が所望されるときにだけ通信リンクの起動を可能にするためのイネーブル信号入力を使用する。ＳＴＢ信号はデータの転送の一部として形成されるので、そのドライバ（４２１２）のために更なるイネーブル信号は使用されない。クライアントＤＡＴＡレシーバとクライアントＳＴＢレシーバ（４１３２、４２３０）の各々の入力は、夫々それらの間にペースされた(paced)、終端インピーダンス又は抵抗４２１８及び４２２０を有する。クライアントコントローラにおけるドライバ４２３４は、クライアントから入力側のドライバ４２１４がデータを処理するホストに転送されているデータ信号を、準備するために使用される。
特別のレシーバ（ドライバ）４２１６及び４２３６は、ＤＡＴＡラインに結合され又は接続され、そして、他のところで説明されたハイバネーション制御の一部として、前に説明された１２５ｍＶ電圧オフセットを生成又は使用する。オフセットは、ハイバネーションラインレシーバに、ドライブされていない信号ペアを論理ゼロレベルとして解釈させる。
前記ドライバ及びインピーダンスは、個別のコンポーネントとして、或いは回路モジュールの一部として又は、よりコスト効率の高いエンコーダ又はデコーダ解決手法として働く特定用途向け集積回路（ＡＳＩＣ）の一部として、形成されることができる。
ＨＯＳＴ＿ＰｗｒとＨＯＳＴ＿Ｇｎｄのラベル表示された信号をペアの導線上で使用して、パワーがホスト装置からクライアント装置つまりディスプレイに移送されることが、容易に理解されることができる。信号のＨＯＳＴ＿Ｇｎｄ部分は、クライアント装置のための、基準グラウンド及びパワーサプライ戻り経路又は信号として働く。ＨＯＳＴ＿Ｐｗｒ信号は、ホスト装置によって駆動されるクライアント装置パワーサプライとして働く。例示的な構成においては、ローパワーアップリケーションの場合、クライアント装置は５００ｍＡまで引き上げること可能とされる。ＨＯＳＴ＿Ｐｗｒ信号は、リチウムイオン型電池又はホスト装置内に常駐する電池パックのような、ただしこれらに限定されない、携帯電源から提供されることが出来、そして、ＨＯＳＴ＿Ｇｎｄを基準にして３．２ボルトから４．３ボルトの範囲を有することができる。
ＶＩＩ．タイミング特性
Ａ．概要
ハイバネーション状態（サービスは要求、所望、或いは必要とされていない）に入るために、そして、ホストからのクライアントに対するサービスを確保するために、ホスト又はクライアントのいずれかの開始によって使用されるステップ及び信号レベルが、図４３ａ、４３ｂ、及び４３ｃにおいて夫々示されている。図４３ａ、４３ｂ、及び４３ｃにおいて、図示されている信号の最初の部分は、ホストから転送されているリンクシャットダウンパケットであり、データラインは、次に高インピーダンスバイアス回路を使用して論理ゼロ状態に駆動される。データは、そのドライバがディスエーブルにされているクライアント、又はホスト、によっては送信されていない。ＭＤＤＩ＿Ｓｔｂはリンクシャットダウンパケットの間アクティブであるので、ＭＤＤＩ＿Ｓｔｂ信号ラインのための一連のストローブパルスがボトムに見られることができる。いったんこのパケットが終了すると、ホストがバイアス回路とロジックをゼロに駆動するので論理レベルはゼロに変化する。これは、ホストからの最後の信号転送あるいはサービスの終了を表わしており、これまでいつでも発生できたであろうし、そして、サービスの前のセッション、及びサービス開始の前の信号の状態を示すために含まれている。要望されるのであれば、このホスト装置によって着手されている「既知の」事前の通信無しに(without a 'known’ prior communication having been undertaken by this host device)、適切な状態に通信リンクを単にリセットするような信号が送信されることが出来る。
図４３ａにおいて示されるように、又上記にリンクシャットダウンパケットについて説明されたように、低電力ハイバネーション状態においては、ＭＤＤＩ＿Ｄａｔａ０ドライバは、リンクシャットダウンパケットにおける全ゼロフィールドの最後のビットの後の１６番目から４８番目のＭＤＤＩ＿Ｓｔｂサイクル又はパルスの後に開始する高インピーダンス状態にディスエーブルされる。２型、３型、又は４型のリンクの場合、ＭＤＤＩ＿Ｄａｔａ０ドライバがディスエーブルされる同じ時に、ＭＤＤＩ＿Ｄａｔａ１からＭＤＤＩ＿ＤａｔａＰｗｒ７までの信号もまた高インピーダンス状態に置かれる。全ゼロフィールドの定義において説明されたように、クライアントによる処理がクライアントコントローラにおいて完了されそして順序だったシャットダウンを容易にするのを可能とするために、リンクシャットダウンパケットのＣＲＣフィールドのＭＳＢに続く６４サイクルの間（又はシステム設計に対し望まれるように）ＭＤＤＩ＿Ｓｔｂは切り替わる(toggles)。１つのサイクルは、ｈｉｇｈからｌｏｗへの遷移が後に続くｌｏｗからｈｉｇｈへの遷移であるか、又は、ｌｏｗからｈｉｇｈへの遷移が後に続くｈｉｇｈからｌｏｗへの遷移である。全ゼロフィールドが送られた後に、ホスト中のＭＤＤＩ＿Ｓｔｂ及びＭＤＤＩ＿Ｄａｔａ０のドライバはディスエーブルされ、そしてホストは低電力ハイバネーション状態に入る。しばらくの時間後、ホスト又はクラアント起動ウェイクアップ要求の何れかでの一部として、ホストは、ＭＤＤＩ＿Ｄａｔａ０及びＭＤＤＩ＿Ｓｔｂのライン又はドライバ出力をイネーブルにすることによって、図４３ｂ及び４３ｃにおいて示されるようにリンク再起動シーケンスを開始し、そしてＭＤＤＩ＿Ｓｔｂを切り換え(toggle)始める。
図４３ｂにおいて示されるように、ＭＤＤＩ＿Ｄａｔａ０及びＭＤＤＩ＿Ｓｔｂ用のドライバからの信号出力がディスエーブルされた状態でしばらくの時間が経過した後、ホストは、ラインが論理ゼロレベルに駆動されるｔｓｔｂ−ｄａｇｔａ−ｅｎｂｌと示された時間の期間、そのＭＤＤＩ＿Ｓｔｂドライバを、それが完全にイネーブルにされるまで、イネーブルにすることによって、そしてさらにそのＭＤＤＩ＿Ｄａｔａ０ドライバをイネーブルにすることによって、サービス又はハイバネーションからのウェイクアップを起動する。ホストは、ＭＤＤＩ＿Ｄａｔａ０がｈｉｇｈ又は論理１レベルに達した後、ＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに維持し、それはｔｃｌｉｅｎｔ−ｓｔａｒｔｕｐと示される時間の期間にわたって起こる。ｔｃｌｉｅｎｔ−ｓｔａｒｔｕｐ期間の終わりで、ホストは次にＭＤＤＩ＿Ｓｔｂ信号又はラインを切り換える(toggle)。ｔreｓｔａｒｔ―ｈｉｇｈと示される期間、クライアントはＭＤＤＩ＿Ｄａｔａ０ラインを駆動しないが、ホストは、ＭＤＤＩ＿Ｄａｔａ０ラインをｈｉｇｈ、論理１レベル、に駆動し、そしてそのあと、ｔreｓｔａｒｔ―ｌｏｗと示される期間、ＭＤＤＩ＿Ｄａｔａ０ラインをｌｏｗ、つまり論理ゼロレベルに、駆動する。この後、第１の順方向トラフィックがサブフレームヘッダパケットで始まり、そして順方向トラフィックパケットがそのとき転送される。ＭＤＤＩ＿Ｓｔｂ信号は、ｔreｓｔａｒｔ―ｌｏｗ期間及びその後に続くサブフレームヘッダパケットの間、アクティブである。
図４３ｃにおいて示されるように、ＭＤＤＩ＿Ｄａｔａ０及びＭＤＤＩ＿Ｓｔｂ用のドライバからの信号出力がディスエーブルされた状態でしばらくの時間が経過した後、クライアントは、ホストがそのＭＤＤＩ＿Ｓｔｂドライバをイネーブルにする前、上記に説明されたように、ｔｓｔｂ−ｄａｇｔａ−ｅｎｂｌと示された時間の期間、ＭＤＤＩ＿Ｓｔｂレシーバ又は出力信号におけるオフセットをイネーブルにすることによって、サービス要求又はハイバネーションからのウェイクアップを起動する。クライアントはそのあと、ホストがＭＤＤＩ＿Ｓｔｂトグリング(toggling)を始める前に、ラインが論理ゼロレベルに駆動されるｔｈｏｓｔ−ｄｅｔｅｃｔと示された時間の期間、そのＭＤＤＩ＿Ｄａｔａ０ドライバをイネーブルにする。
ホストがｔｈｏｓｔ−ｄｅｔｅｃｔの間に要求を検出する前に、ある時間量が、経過する或いは必要とされるかもしれないが、その後、ホストは、ホストがｔｒｅｓｔａｒ―ｈｉｇｈ期間の間にＭＤＤＩ＿Ｄａｔａ０を論理１又はｈｉｇｈレベルに駆動することによってリンクスタートアップシーケンスでＭＤＤＩ＿Ｓｔｂを切り換えること(toggling)を始める前に、ｔｓｔｂ−ｓｔａｒｔｕｐと示された期間の間そのＭＤＤＩ＿Ｓｔｂを論理ゼロレベルに維持することによって応える。クライアントがＭＤＤＩ＿Ｓｔｂ上に第１パルスを認識する時、それはＭＤＤＩ＿Ｓｔｂレシーバにおけるオフセットをディスエーブルにする。クライアントは、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに又はｔｃｌｉｅｎｔ−ｄｅｔｅｃｔと示される期間、ホストがラインを駆動しているのをそれが検出するまで、駆動し続ける。この時点で、クライアントは、要求をアサートすることを止め(de-assert)、そしてクライアントからの出力が再び論理ゼロレベルに向かうようにＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルにし、そしてホストは、ＭＤＤＩ＿Ｄａｔａ０を駆動している。前記同様に、ホストはｔｒｅｓｔａｒ―ｈｉｇｈ期間の間、ＭＤＤＩ＿Ｄａｔａ０を論理１レベルに駆動し続け、そしてそのあとｔｒｅｓｔａｒ―ｌｏｗ期間の間、ＭＤＤＩ＿Ｄａｔａ０ラインをｌｏｗに駆動し、その後、第１の順方向トラフィックがサブフレームヘッダパケットで始まる。ＭＤＤＩ＿Ｓｔｂ信号は、ｔreｓｔａｒｔ―ｌｏｗ期間及びその後に続くサブフレームヘッダパケットの間、アクティブである。
表ＶＩＩＩは、上記で説明された様々な期間の長さに対する代表的な時間或いは処理期間、そして例示的な最小及び最大のデータレートの関係を示す、ここで:
Figure 2007528681
Figure 2007528681
当業者は、図４１及び図４２において図示されている個々のエレメントの機能が良く知られ、そして図４２におけるエレメントの機能が図４３ａ、４３ｂ、及び４３ｃのタイミング図で確認されることを、容易に理解するであろう。図４２に示されている直列終端及びハイバネーション抵抗についての詳細は、その情報が、データ−ストローブ符号化を実行しそしてそこからクロックを回復する方法の説明には不必要であるため、図４１からは省略された。
Ｂ．データ−ストローブタイミング順方向リンク
ホストドライバ出力からの順方向リンク上でのデータの転送のスイッチング特性は、表ＩＸ−１に示されている。表ＩＸは、表形式で、発生するある信号遷移(certain signal transitions)についての所望される最小及び最大の時間対典型的な時間を示す。例えば、データ値（「０」又は「１」の出力）の始まりから終わりまでに起こる遷移、ｔｔｄｄ−（ｈｏｓｔ−ｏｕｔｐｕｔ）と名づけられている、Ｄａｔａ０からＤａｔａ０への遷移、の場合の典型的な時間の長さは、ｔｔｂｉｔであり、一方、最小時間は約ｔｔｂｉｔ-０．５ｎｓｃであり、最大は約ｔｔｂｉｔ＋０．５ｎｓｃである。Ｄａｔａ０、他のデータライン（ＤａｔａＸ）、及びストローブライン（Ｓｔｂ）上の遷移間の相対的間隔は、図４４において図示されており、ここでは、Ｄａｔａ０からストローブ、ストローブからストローブ、ストローブからＤａｔａ０、Ｄａｔａ０から非Ｄａｔａ０、非Ｄａｔａ０から非Ｄａｔａ０、非Ｄａｔａ０からストローブ、そしてストローブから非Ｄａｔａ０の遷移が示され、それらは、夫々、ｔｔｄｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｓｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｓｄ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｄｘ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｘｄｘ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｘｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、及びｔｔｓｄｘ−（ｈｏｓｔ−ｏｕｔｐｕｔ）と称されている。
Figure 2007528681
順方向リンク上でデータを転送している同じ信号のクライアントレシーバ入力のための典型的なＭＤＤＩタイミング要件は、表ＩＸ−２に示されている。時間は遅延しているが同じ信号が説明されているので、当業者によって理解されるであろうように、夫々のラベルの信号特性又は意味を説明するための新しい図は必要とされない。
Figure 2007528681
図４５と図４６は、ホストがホストドライバをイネーブル又はディスエーブルする時に発生し得る応答における遅延の存在を、夫々図示する。ある特定のパケット、例えば逆方向リンクカプセル化パケット又は往復遅延測定パケットなど、を転送しているホストの場合は、所望されるパケット、例えば、転送されてしまっているような、図４５に示されるパラメータＣＲＣパケット、ストローブ位置合わせパケット、及び全ゼロパケットなど、が転送された後に、ホストはラインドライバをディスエーブルする。然しながら、図４５に示されているように、ラインの状態は必ずしも「０」から所望のより高い値に瞬時に切り替わらず、これはある特定の制御素子又は回路素子が存在する状態では潜在的に達成可能であるけれども、しかし応答のホストドライバディスエーブル遅延期間と称される時間を要する。この時間の長さが０ナノ秒（ｎｓｅｃ）であるように実質上瞬時にそれは発生できるであろうが、ガード時間１パケット期間或いは方向転換１パケット期間の間に発生する、所望される最大期間長である、１０ｎｓｅｃのいくぶんより長い期間に、より容易にそれは及ぶであろう。
図４６を見ると、逆方向リンクカプセル化パケット又は往復遅延測定パケットのようなパケットを転送するためにホストドライバがイネーブルにされている時に、信号レベル変化を受けたことがわかる。ここでは、ガード時間２パケット期間又は方向転換２パケット期間の後、ホストドライバは、イネーブルにされ、そしてレベル、ここでは「０」、を駆動し始めるが、この値は、送信される第１パケットの前に、ドライバ再イネーブル期間の間に発生するホストドライバイネーブル遅延期間と称される期間にわたって近づけられ又は到達される。
クライアント装置、ここではディスプレイ、のための信号転送及びドライバの場合に、同様のプロセスが発生する。これらの期間の長さについての一般的なガイドライン、及びそれらの夫々の関係が、下記の表Ｘに示されている。
Figure 2007528681
Ｃ．ホスト及びクライアント出力イネーブル及びディスエーブル時間
逆方向リンクカプセル化パケット構造及び期間に関連しての、ホスト及びクライアント出力イネーブル及びディスエーブル時間又は動作についてのスイッチング特性及び相対的タイミングが、図４８において示されている。ドライバ出力機能又は動作は：ホスト出力イネーブル時間についてはｔｈｏｓｔ−ｅｎａｂｌｅ、ホスト出力ディスエーブル時間についてはｔｈｏｓｔ−ｄｉｓａｂｌｅ、クライアント出力イネーブル時間についてはｔｃｌｉｅｎｔ−ｅｎａｂｌｅ、そして、クライアント出力ディスエーブル時間についてはｔｃｌｉｅｎｔ−ｄｉｓａｂｌｅ、とラベル表示されている。ある特定の信号遷移の典型的な時間が以下に説明される。これらの動作の最小期間は、ゼロナノ秒で、インタフェースを使用するシステム設計から決定される典型的な又は最大の値は、多分、約８ナノ秒或いはそれよりも大きいであろう。
これらの期間の長さについての一般的なガイドライン、（ホスト及びクライアント イネーブル／ディスエーブル 時間）及びそれらの夫々の関係が、下記の表ＸＩに示されている。
Figure 2007528681
ＶＩＩＩ．リンクコントロール（リンクコントローラ動作）のインプリメンテーション
Ａ．状態機械パケットプロセッサ
ＭＤＤＩリンク上で転送されているパケットは、所望されるように、より低いレートは勿論適応されるけれども、非常に迅速に、典型的には、約３００Ｍｂｐｓ以上のレートで送信される。このタイプのバス又は転送リンクのスピードは速すぎて、現在市販されている（経済的な）汎用マイクロプロセッサ又は同様の類は制御出来ない。従って、このタイプの信号転送を達成するための実用的なインプリメンテーションは、それらが意図されている適切な視聴覚サブシステムに転送される又はリダイレクトされる(redirected)パケットを生成するために入力パケットストリームを解析する(parse)プログラマブル状態機械を活用することである。このような装置は、よく知られており、所望される高速又は超高速の動作を達成するために、限られた数の動作、機能、又は状態に一般に専用化された回路を使用する。
汎用コントローラ、プロセッサ、又は処理エレメントは、より低いスピード要求を有する、制御パケット又はステータスパケットのようななんらかの情報、により適切に作用する、或いは、を操作するために、使用されることができる。それらのパケット（制御、ステータス、又は他の予め定義されたパケット）が受信される時、音声パケットと視覚パケットが動作のためにその適切な宛て先に転送される間に、パケットが、所望される結果（効果）を提供するために作用を受けることが出来るように、状態機械は、それらをデータバッファ又は同様な処理エレメントを通して汎用プロセッサに渡す必要がある。もし将来、マイクロプロセッサ又は他の汎用コントローラ、プロセッサ、又は処理エレメントがより速いデータレート処理機能を達成するために製造される場合、そのときは、下記に説明される状態又は状態機械もまた、典型的には記憶エレメント又は媒体に保存されるプログラムとして、そのような装置のソフトウェア制御を使用して実現されるかもしれない。
いくつかのモデム又はグラフィックプロセッサが、幾つかの機能を実行しそしてハードウェアの複雑さ及びコストを軽減するために、コンピュータにおいて見られるＣＰＵの処理力を利用するのとほぼ同じ方法で、コンピュータアプリケーションにおけるマイクロプロセッサ（ＣＰＵｓ）、或いは無線装置において見られるコントローラ、プロセッサ、デジタル信号プロセッサ（ＤＳＰｓ）、専門化された回路、又はＡＳＩＣ、に利用可能な処理能力又は過多サイクルを上手く利用することによって、汎用プロセッサ機能は、幾つかの実施形態において実現されることが出来る。然しながら、このサイクル共用又は使用は、このような素子の処理スピード、タイミング、又は全体的な動作にマイナス影響を及ぼす可能性があるので、多くのアプリケーションにおいては、この汎用処理のための専用回路又は素子が好まれる。
画像データがディスプレイ（マイクロディスプレイ）上に表示されるために、或いはホスト装置によって送信される全てのパケットを確実に受信するために、クライアント信号処理は、順方向リンクチャネルタイミングと同期される。すなわち、クライアント及びクライアント回路に到達する信号は、適切な信号処理が発生するように実質的に時間同期される必要がある。一実施形態のための信号によって実現される状態(states)のハイレベルダイアグラム(a high level diagram)が、図４９の説明図において示されている。図４９では、状態機械４９００に関しての起こりうる順方向リンク同期「状態」が、１つのＡＳＹＮＣ ＦＲＡＭＥ ＳＴＡＴＥ（非同期フレーム状態）４９０４、２つのＡＣＱＵＩＲＩＮＧ ＳＹＮＣ ＳＴＡＴＥ（同期獲得状態）４９０２及び４９０６、そして３つのＩＮ−ＳＹＮＣ ＳＴＡＴＥ（同期中状態）４９０８、４９１０、及び４９１２として分類されて、示されている。
開始ステップ又は状態４９０２によって示されるように、プレゼンテーション装置のようなディスプレイ又はクライアントは、事前に選択された「同期なし」状態で開始し、そして、検出される第１のサブフレームヘッダパケット中の固有のワードを検索する。この同期なし状態が、１型インタフェースが選択される「後退」設定(“fall-back” setting)又は最小通信設定(“the minimum communication setting”)、を表す、ということに注意しなければならない。固有のワードが検索中に発見される時、クライアントはサブフレーム長フィールドを保存する。この第１のフレームに関する処理のための、或いは同期が得られるまで、ＣＲＣビットのチェックはない。もしこのサブフレーム長がゼロである場合、そのとき同期状態処理は、それに応じて、同期がまだ達成されていないことを示す「非同期フレーム」状態とここでラベル表示された状態４９０４に進む。処理のこのステップは、図４９において、ｃｏｎｄ３、或いはコンディション３(condition 3)に遭遇したとラベル表示されている。それ以外の場合、もしフレーム長がゼロより大きい場合、そのとき同期状態処理は、インタフェース状態が「１つの同期フレームを発見した」(“found one sync frame”)として設定されている状態４９０６、に進む。処理のこのステップは、図４９において、ｃｏｎｄ５、或いはコンディション５に遭遇しているとラベル表示されている。更に、もし状態機械が、ゼロより大きいフレーム長に対し、フレームヘッダパケット及び良好なＣＲＣ決定を見る場合、処理は「１つの同期フレームを発見した」状態に進む。これは、図４９において、ｃｏｎｄ６、又はコンディション６に会っているとラベル表示されている。
システムが「同期なし」以外の状態にある各々の状況では、もし良好なＣＲＣ結果を有するパケットが検出される場合、そのときインタフェース状態は「同期中」状態４９０８に変更される。処理におけるこのステップは、図４９において、ｃｏｎｄ１、又はコンディション１に遭遇したとラベル表示されている。他方、もし何れのパケットにおけるＣＲＣも正しくない場合には、そんとき同期状態処理は、「ＮＯ ＳＹＮＣ ＦＲＡＭＥ（同期なしフレーム）」状態のインタフェース状態４９０２に進む、又は戻る。処理のこの部分は、図４９の状態図において、ｃｏｎｄ２、又はコンディション２に遭遇しているとラベル表示されている。
Ｂ．同期の獲得時間
インタフェースは、同期が失われたと決定しそして「ＮＯ ＳＹＮＣ ＦＲＡＭＥ（同期なしフレーム）」状態に戻る前に、ある特定の数の「同期エラー」に対処するように構成されることができる。図４９において、いったん状態機械が「ＩＮ−ＳＹＮＣ ＳＴＡＴＥ（同期中状態）」に到達しそしてエラーが検出されないと、それは、連続してｃｏｎｄ１結果に遭遇し続け、そして「ＩＮ−ＳＹＮＣ（同期中）」状態にとどまる。然しながら、いったん１つのｃｏｎｄ２結果が検出されると、処理は状態を「１同期エラー」状態４９１０に変更する。この時点で、もし処理が別のｃｏｎｄ１結果を検出する結果となると、そのとき状態機械は「同期中」状態に戻り、そうでなければ、それは別のｃｏｎｄ２結果に遭遇し、そして「ＴＷＯ−ＳＹＮＣ−ＥＲＲＯＲＳ（２同期エラー）」状態４９１２に移る。再び、もしｃｏｎｄ１が発生すると、処理は状態機械を「ＩＮ−ＳＹＮＣ（同期中）」状態に戻す。そうでなければ、別のｃｏｎｄ２が遭遇され、状態機械は「同期なし」状態に戻る。もしインタフェースが「リンクシャットダウンパケット」に遭遇すれば、そのときこれは、リンクにデータ転送を終了させ、同期するものがないので、図４９の状態図において、ｃｏｎｄ４或いはコンディション４に会っていると呼ばれる「同期なしフレーム」状態に戻させる、ということもまた理解可能である。
そこではサブフレーム内のどこか固定されたロケーションに現れる可能性のある固有のワードの繰り返しの「偽のコピー」(a repeating “false copy”)が存在する可能性があることが理解される。その状況では、サブフレームヘッダパケット上のＣＲＣは、ＭＤＤＩ処理が「ＩＮ ＳＹＮＣ（同期中）」状態に進むために処理される時もまた、有効であらなければならないので、状態機械がサブフレームに同期するであろう可能性はきわめて低い。
サブフレームヘッダパケット内のサブフレーム長は、リンクがシャットダウンされる前にホストがただ１つのサブフレームを送信することを示すために、ゼロに設定されることができ、そしてＭＤＤＩは、休止ハイバネーション状態(an idle hibernation state)に置かれる、或いはコンフィギュレーションされる。この場合、クライアントは、リンクがアイドル状態に遷移する前にただ１つのサブフレームだけが送信されるので、サブフレームヘッダパケットを検出後に、直ちに、順方向リンク上でパケットを受信しなければならない。正常な又は通常の動作では、サブフレーム長は非ゼロであり、そしてクライアントは、インタフェースが図４９で「ＩＮ−ＳＹＮＣ（同期中）」状態として集合的に示されているそれらの状態の中にある間、順方向リンクパケットを処理するだけである。
ホストが既に順方向リンクデータシーケンスを送信している間、外部モードクライアントは、ホストに接続され(attached)てもよい。この状況では、クライアントはホストに同期しなければならない。クライアントが順方向リンク信号に同期するのに要する時間は、サブフレームサイズと順方向リンクデータレートに応じて可変である。順方向リンクにおいて無作為な、或いはもっと無作為な、データの一部として、固有のワードの「偽のコピー」を検出することの可能性は、サブフレームサイズがより大きい時により大である。同時に、順方向リンクデータレートがより遅い時は、偽検出から回復する能力はより低く、そしてそうするために要する時間はより長い。
1以上の実施形態については、ＭＤＤＩホストは、それが低電力モードに行くために或いはリンクを完全にシャットダウンするために順方向リンク伝送をストップする前に、ＭＤＤＩ逆方向リンクが安定していることを確実にするために、ある特定の更なるステップを実行すべきである、ということが推奨される或いは理解される。
発生しうる1つの問題は、もしホストが往復遅延値の不正確な測定値を使用する場合は、たとえ順方向リンクが問題無いように見えるとしても、これは、その後に受信される全てのクライアントからの逆方向データ伝送に障害を起こさせ得る、ことである。これは、もしホストが、クライアントが順方向リンクに同期がとれていない時に往復遅延測定パケットを送信しようと試みる場合に、或いは、往復遅延に悪影響を与える差動ドライバ及びレシーバの伝播遅延において対応する大きな変化をもたらす、極端な周囲温度変化に原因して、起こり得るであろう。間欠的に発生するケーブル或いはコネクタの接触不良もまた、クライアントに一時的に同期を失いそしてそのあと同期を回復させることがあり得るであろうが、その間、それは往復遅延測定パケットを受信しそこなう可能性がある。その後に続く逆方向リンクパケットは、ホストによって、適切に復号されることが出来ないであろう。
発生しうる別のタイプの問題は、もしクライアントが一時的に同期を失う場合、そしてホストが、クライアントが同期を回復出来る前に、リンクシャットダウンパケットを送る、ことである。クライアントが、それがリンクシャットダウンパケットを受信しなかったのでハイバネーション状態に入ることが出来ず、そして、リンクがハイバネーションの中にあるのでクロックを有さない間に、ホストはハイバネーションの中にあるであろう。
そのような問題を克服するために有用な1つの技術或いは実施形態は、ホストに、リンクをハイバネーション状態に入れる前にクライアントが順方向リンクと同期していることを確認させることである。もしＭＤＤＩホストがこのことを出来ない又はそのような機会を持たない場合、例えば、動作中に発生するケーブル、導線、又はコネクタの分離、ブレーク、又は切断に起因してそれがパワーを失くす或いはリンクが突如壊れる又は障害を起こす時など、そのときホストは、往復遅延測定プロセスを開始する又は逆方向リンクカプセル化パケットを送信する前に、クライアントが同期していることを最初に確認するように試みるべきである。
ホストは、順方向リンク完全性を判断するために、クライアントから送られたクライアント要求及びステータスパケット中のＣＲＣエラーカウントフィールドを観察できる。このクライアントからのパケットはホストによって要求される。然しながら、大きなリンク障害又は破壊の場合には、クライアントが適切にパッケットを復号できず、或いは多分それを全く受信さえ出来ないであろう故、この要求は、答えが無いままである可能性が高い。逆方向リンクカプセル化パケットにおいて送信されるクライアント要求及びステータスパケットを使用してのＣＲＣエラーカウントの要求は、最初の完全性チェック、一種の最初の防御ライン、として働く。更に、ホストは、同期がずれてしまったクライアントについての仮定が有効なものかどうかを確認するために往復遅延測定パケットを送信できる。もしクライアントが往復遅延測定パケットに応答しない場合は、ホストは、クライアントが同期からずれていると結論付け、そしてそのあとそれを同期に戻させるプロセスを開始出来る。
いったんホストが、クライアントは恐らく順方向リンクとの同期を失ってしまったと結論すると、それは、フィラーパケット以外のいずれかのパケットを送信しようとする前に次のサブフレームヘッダを待つ。これは、クライアントに、サブフレームヘッダパケットの中に含まれる１つの固有のワードを検出する或いは探すのに十分な時間を与えるために、行なわれる。これに引き続いて、ホストは、クライアントがそれが正しい場所で固有のワードを見つけなかったのでそれ自身をリセットしてしまったであろうと、仮定するかもしれない。この時点で、ホストは、往復遅延測定パケットでサブフレームヘッダパケットをフォローしてもよい。もしクライアントが依然として往復遅延測定パケットに正しく応答しない場合は、ホストは、再同期プロセスを繰り返してよい。正しい応答は、クライアントが、指定されたシーケンスを往復遅延測定パケットの測定期間中にホストに送り返すものである。もしこのシーケンスが受信されない場合、そうなら、逆方向リンクカプセル化パケット中の逆方向データを受信する試みは失敗するであろう。この種の連続する失敗は、何らかの他のシステムエラーを示している可能性があり、それは、何らかの他の方法で処置されなければならない、そしてこの時点ではリンク同期にかかわっていない。
然しながら、もし、成功した往復遅延測定パケット後にホストが依然と逆方向リンクカプセル化パケット中に壊れたデータを見る或いは応答を見ない場合は、それは、往復遅延測定パケットを再送信することによって、逆方向データサンプリングが正確であることを確認すべきである。もしこれが何回かの試みの後も成功しない場合、一実施形態については、ホストが、逆方向レート除数値(the reverse rate divisor value)を増やすことによって逆方向データレート(the reverse data rate)を減らす、ということが推奨される。
ホストは、ＭＤＤＩリンクをハイバネーション状態に置く前に、上記で説明されたリンク失敗検出ステップとそして多分リンク再同期ステップ(the Link Failure Detection and possibly the Link Resynchronization steps)を実行すべきである。これは一般に、リンクが後で再起動される時に実行される往復遅延測定パケットが成功していることを、確実にする。もしホストがリンクの失敗を疑う理由を有さない、そして逆方向リンクカプセル化パケットとゼロ順方向リンクＣＲＣエラーへの正確な応答がクライアントによって報告されている場合は、ホストは、全てのものがそれに応じて或いは適切に（例えばリンク障害なし）動作している或いは機能していると仮定し、そしてパワーダウン／ハイバネーションプロセスを進めてよい。
ホストが同期のために検査できる別の方法は、ホストが往復遅延測定パケットを送りそしてクライアントから適切な応答を確認することである。もし適切な応答がホストによって受信される場合は、クライアントは順方向リンクパケットを成功裏に解釈していると合理的に(reasonably)想定されることが出来る。
Ｃ．初期化
前述されたように、「起動」時に、ホストは、順方向リンクを、最低限必要な、或いは所望の、１Ｍｂｐｓのデータレート以下で動作するように構成し(configure)、そしてサブフレーム長とメディアフレームレートをある特定のアプリケーション用(for a given application)に適切に構成する。つまり、順方向リンクと逆方向リンクの両方が１型インタフェースを使用して動作を開始する。これらのパラメータは一般に、ホストがクライアントディスプレイ（又は他のタイプのクライアント装置）のための機能又は所望される構成を決定する間に、一時的に使用されることになるだけであろう。ホストは、ディスプレイ又はクライアントがディスプレイ機能パケットで応答することを要求するために、要求フラグのビット「０」がｏｎｅ（１）の値に設定された逆方向リンクカプセル化パケットが後に続く、順方向リンク上でサブフレームヘッダパケットを送信又は転送する。いったんディスプレイが順方向リンク上で（又は順方向リンクとの）同期を獲得すると、それはクライアント機能パケットとクライアント要求及びステータスパケットを逆方向リンク又はチャネル上で送信する。
ホストは、最適の又は所望されるレベルの性能のためのリンクを再構成する(reconfigure)方法を決定するためにクライアント機能パケットの内容を調べる。ホストは、ホストとクライアントとが互いに互換性のあるプロトコルのバージョン(versions)を使用することを確認するためにプロトコルバージョンフィールドと最小プロトコルバージョンフィールドを調べる。プロトコルの他のエレメントが互換性がないかもしれない或いは互換性があるものとして完全には理解されないかもしれない時でさえ、互換性が決定されることが出来るように、プロトコルバージョンは、一般に、クライアント機能パケットの最初の２つのパラメータとして留まる。
内部モードにおいては、ホストは、クライアント機能パケットを受信する必要もなく、あらかじめクライアントのパラメータを知ることが出来る。リンクは、ホストとクライアントが両方とも動作できる任意のデータレートで起動出来る。多くの実施形態において、システム設計者は、データ転送を早めるために最大達成可能データレートでリンクを起動するのを選ぶ可能性が最も高いが、然しながら、これは、要求されておらず、又、多くの状況下では使用されないかもしれない。内部モードの場合、ハイバネーションシーケンスからのリンク再起動中に使用されるストローブパルスの周波数は、普通、この所望のレートと整合する。
Ｄ．ＣＲＣ処理
全てのパケットタイプに対し、パケットプロセッサ状態機械は、ＣＲＣチェッカが適切に又は正確に制御されることを保証する。それは又、ＣＲＣ比較の結果１つ又は複数のエラーが検出される時、ＣＲＣエラーカウンタをインクリメントし、そしてそれは、処理されている各サブフレームの始まりにＣＲＣカウンタをリセットする。
Ｅ．同期チェックの代替損失
前記の一連のステップ又は状態は、より高いデータレート又はスループットスピードを発生させるように働くが、出願人は、クライアントが使用しホストとの同期の損失があることを宣言するコンディション(conditions)での代替配列又は変更が、更により高いデータレート又はスループットを達成するために有効に使用されることが出来ることを発見した。新しい発明の実施形態は、同じ基本構造を有するが、状態(state)を変更するためのコンディション(conditions)が変更されている。更に、新しいカウンタが、サブフレーム同期のためにチェックを行うのに役立つようにインプリメントされている。これらのステップ及びコンディション(conditions)は、方法又は状態機械の動作を確立する際に有用な一連の状態(states)及びコンディション(conditions)を示す状態機械図６３、に関連して示されている。明確にするために「ＡＣＱＵＩＲＩＮＧ−ＳＹＮＣ ＳＴＡＴＥＳ（同期獲得状態）」部分と「ＩＮ−ＳＹＮＣ ＳＴＡＴＥＳ（同期中状態）」部分のみが示されている。加えて、結果として生じる状態(states)は、状態機械自体と実質的には同じであるため、それらは同じ番号付けを使用する。然しながら、状態(state)を変更するためのコンディション(conditions)（及び状態機械の動作）は多少変わっており、従って、相違点を識別する際に便利なように、２つの図（１、２、３、４、５、及び６ 対 ６１、６２、６３、６４、及び６５）の間で明確にするために、全てが番号を変更されている。ＡＳＹＮＣ ＦＲＡＭＥ（非同期フレーム）状態はこの説明においては考慮されないので、１つの状態（４９０４）及びコンディション(condition)（６）は、図においてはもはや使用されていない。
図６３においては、図４９においてのように、システム又はクライアント（ディスプレイ又はプレゼンテーション用）が、事前に選択された「同期なし」状態(state)４９０２において状態機械５０００で開始する。同期なしコンディション(condition)４９０２から状態を変更するための第１状態変化は、同期パターンの発見であるコンディション(condition)６４の中にある。サブフレームヘッダのＣＲＣもまたこのパケット上で通過すると仮定する（コンディション(condition)６１を満たす）と、パケットプロセッサ状態機械の状態は、同期中状態４９０８に変更されることが出来る。同期エラー、コンディション(condition)６２、は、状態機械を状態４９１０に、そして第２の発生を状態４９１２にシフトさせるであろう。然しながら、ＭＤＤＩパケットのどんなＣＲＣ障害も、状態機械を同期状態４９０８から外れて１同期エラー状態４９１０に移動させるであろう、ことが発見されている。何れかのＭＤＤＩパケットの別のＣＲＣ障害は、２同期障害状態４９１２への移動の原因となるであろう。正しいＣＲＣ値で復号されるパケットは、状態機械を同期中状態４９０８に戻させるであろう。
変更されたのは、「全ての」パケットのためのＣＲＣ値又は決定を利用することである。すなわち、サブフレームヘッダパケットを単に観察する代わりに、同期の損失を決定するために、状態機械に全てのパケットのためのＣＲＣ値を調べさせることである。この構成(configuration)又はプロセスでは、同期の損失は、固有のワードそして単にサブフレームヘッダＣＲＣ値を使用しては決定されない。
新しいインタフェースインプリメンテーションは、ＭＤＤＩリンクが、同期障害をよりずっと速く認識することを、従って、同様に、それらからより速く回復することを、可能にする。
このシステムを更にロバストにするために、クライアントはサブフレームカウンタを追加又は活用もすべきである。クライアントはそれから、固有のワードの存在を、それが到着又は信号内で発生することが予想される時にチェックする。もし固有のワードが正しい時点で発生しないならば、クライアントは、それがサブフレーム長よりももっと長い複数（ここでは３）のパケット回数又は期間待機しなければならなかった場合よりもずっと速くに同期障害が発生したことを認識出来る。もし固有のワードのテストが、それが存在しない、言い換えるとタイミングが正しくないことを示すと、そのときクライアントは直ちに、同期のリンク損失を宣言出来、そして、同期なし状態に移ることが出来る。正確な固有のワードの存在をチェックするプロセスは、固有のワードが正しくないと示している、状態機械にコンディション６５（ｃｏｎｄ６５）を追加する。もしサブフレームパケットが、クライアント上で受信されることを予想され、そして予想に十分に応えられない場合は、クライアントは、直ちに同期なし状態４９０２に移動出来、通常は状態４９１０と４９１２を通って行き来して遭遇される複数の同期エラー（コンディション６２）を待つ更なる時間を省く。
この変化は、サブフレーム長をカウントするためにクライアントコア内で追加のカウンタ又はカウント機能を使用する。一実施形態においては、カウントダウン機能が使用され、そして現在処理されていた任意のパケットの転送が、もしカウンタが終了した場合は、サブフレーム固有ワードがないかチェックするために中断される。或いは、カウンタは、カウントアップでき、現在のパケットがチェックされる時点で、カウントは、所望される最大の、又は特定の所望される値と比較される。このプロセスは、クライアントを、異常に長いパケット長を持ってクライアント上で不正確に受信されるパケットを復号するのを防ぐ。もしサブフレーム長カウンタが、復号されていた何らかの他のパケットを中断することを必要とされた場合には、パケットはサブフレーム境界を越えてはならないので、同期の損失が決定されることができる。
ＩＸ．パケット処理
状態機械が受信する前述された各タイプのパケットに対し、それは、インタフェースの動作を実現する(implement)ために、特定のプロセスステップ又は一連のステップを引き受けてとりかかる。順方向リンクパケットは、通常、以下の表ＸＩＩに一覧表示される例示的な処理に従って処理される。
Figure 2007528681
Figure 2007528681
Ｘ．逆方向リンクデータレートの減速
発明者らにより、ホストリンクコントローラのために使用されるある特定のパラメータが、非常に望ましい最大又はより最適化された（スケール）逆方向リンクデータレートを達成するために特殊な方法で調整又は構成されることが出来ることが観察された。例えば、逆方向リンクカプセル化パケットの逆方向データパケットフィールドを転送するために使用される時間中、ＭＤＤＩ＿Ｓｔｂ信号ペアは、順方向リンクデータレートの半分で周期的なデータクロックを生成するために切り換える(toggle)。ホストリンクコントローラが、それがあたかも全ゼロを送信しているかのように、ＭＤＤＩ＿Ｄａｔａ０信号に対応するＭＤＤＩ＿Ｓｔｂ信号を生成させるので、これは発生する。ＭＤＤＩ＿Ｓｔｂ信号は、ホストからクライアントに転送され、そこではそれはクライアントから逆方向リンクデータを転送するためのクロック信号を生成するために使用され、それを使用して逆方向データがホストに送り戻される。ＭＤＤＩを使用するシステムにおいて順方向経路及び逆方向経路上で信号転送及び処理のために遭遇される典型的な量の遅延の説明図が、図５０において示されている。図５０において、一連の遅延値１．５ｎｓｅｃ、８．０ｎｓｅｃ、２．５ｎｓｅｃ、２．０ｎｓｅｃ、１．０ｎｓｅｃ、１．５ｎｓｅｃ、８．０ｎｓｅｃ、及び２．５ｎｓｅｃが、Ｓｔｂ＋／−生成、クライアントへのケーブル転送、クライアントレシーバ、クロック生成、信号時間記録(signal clocking)、Ｄａｔａ０＋／−生成、ホストへのケーブル転送、及びホストレシーバのステージのための処理部分近くに、夫々、示されている。
順方向リンクデータレート及び遭遇される信号処理遅延次第では、この「往復」効果又はイベントのセットが完了されるためにはＭＤＤＩ＿Ｓｔｂ信号上での１サイクルよりもより多くの時間を要する可能性があり、それは、望ましくない量の時間又はサイクルの消費の原因となる。この問題を回避するために、逆方向レート除数が、逆方向リンク上の１ビット時間がＭＤＤＩ＿Ｓｔｂ信号の複数のサイクルに及ぶことを、可能にする。これは、逆方向リンクデータレートが順方向リンクレート未満である、ことを意味する。
インタフェースを通る信号遅延の実際の長さは、使用されている各特定のホスト−クライアントシステム又はハードウェアに応じて異なる可能性がある、ということに注意する必要がある。要求はされていないが、各システムは一般に、逆方向レート除数が最適値に設定されることが出来るように、システム内での実際の遅延を測定するために往復遅延測定パケットを使用することによって、よりよく機能するように作られることが出来る。ホストは、より簡単であるがより遅いスピードで動作する基本データサンプリングか又はより複雑ではあるがより高い逆方向データレートをサポートする高度データサンプリングかのを、サポートできる。両方の方法をサポートするクライアント機能は、同様に考慮される。
往復遅延は、ホストに往復遅延測定パケットをクライアントに送信させることにより測定される。クライアントは、測定期間フィールドと呼ばれるそのパケットの中の事前に選択された測定ウィンドウの、内部で、又は期間に、１のシーケンス(a sequence of ones)をホストに送り返すことによってこのパケットに応答する。この測定の詳細なタイミングは前に説明された。往復遅延は、逆方向リンクデータが安全にサンプリングされることができるレートを決定するために使用される。
往復遅延測定は、０ｘｆｆ、０ｘｆｆ、０ｘ００応答シーケンスがクライアントからホストに返され受信される時、測定期間フィールドの始まりと時間期間の始まりとの間で発生する順方向リンクデータクロック間隔の数を決定すること、検出すること、或いはカウントすることのみからなる(consist of)。測定カウントがインクリメントしようとする前にごくほんの少しの順方向リンククロック期間、クライアントからの応答が受信されることが出来るであろうことが起こりうる、ということに注意してください。もしこの未修正の値が逆方向レート除数を計算するために使用される場合は、それは、信頼できないデータサンプリングのために逆方向リンク上でビットエラーを生じさせることがあり得るであろう。この状況の一例は、図５１において図示されており、ここでは、ホストでのＭＤＤＩ＿Ｄａｔａ、ホストでのＭＤＤＩ＿Ｓｔｂ、ホストの内部の順方向リンクデータクロック、及び遅延カウント、を表す信号がグラフ形式で図示されている。図５１では、遅延カウントがまさに６から７にインクリメントしようとする前にほんの少しの順方向リンククロック期間、応答シーケンスがクライアントから受信された。もし遅延が６であると見なされる場合、そのときホストは逆方向データを、ビット遷移の直後に或いは多分ビット遷移の最中にサンプリングするであろう。これは、ホストでの誤ったサンプリングの原因となり得るであろう。このため、測定遅延は、典型的には、それが逆方向除数を計算するために使用される前に１インクリメントされるべきである。
逆方向レート除数は、逆方向リンクデータをサンプリングする前にホストが待機しなければならないＭＤＤＩ＿Ｓｔｂサイクルの数である。ＭＤＤＩ＿Ｓｔｂは順方向リンクレートの２分の１であるレートで循環されるので、補正往復遅延測定は、２で除算されそのあと次の整数に切り上げられる必要がある。数式として表わされると、この関係は以下のとおりである：
Figure 2007528681
与えられた例の場合、これは次のようになる：
Figure 2007528681
この例で使用される往復遅延測定が、６とは全く異なって７であった場合、このときは逆方向レート除数もまた、４に等しくなるであろう。
逆方向リンクデータは、逆方向リンククロックの立ち上がりでホストによりサンプリングされる。逆方向リンククロックを生成するためホストとクライアント（ディスプレイ）の両方に存在するカウンタ又は類似する知られた回路又は装置がある。カウンタは、逆方向リンククロックの第１の立ち上がりが、逆方向リンクカプセル化パケットの逆方向リンクパケットフィールド中の第１のビットの始まりで発生するように、初期化される。これは、以下に与えられる例について、図５２Ａにおいて図示されている。カウンタはＭＤＤＩ＿Ｓｔｂ信号の各立ち上がでインクリメントし、そしてそれらがラップアラウンド(wrap around)するまで発生しているカウント数は、逆方向リンクカプセル化パケットの中の逆方向レート除数パラメータにより設定されている。ＭＤＤＩ＿Ｓｔｂ信号は順方向リンクレートの２分の１で切り替わる(toggle)ので、そのとき逆方向リンクレートは、逆方向レート除数で除算された順方向リンクレートの２分の１である。例えば、もし順方向リンクレートが２００Ｍｂｐｓであり、そして逆方向レート除数が４である場合、そのとき逆方向リンクデータレートは以下のように表される：
Figure 2007528681
逆方向リンクカプセル化パケット内のＭＤＤＩ＿Ｄａｔａ０信号ラインとＭＤＤＩ＿Ｓｔｂ信号ラインのタイミングを示す例は、図５２において示されている、ここでは、説明のために使用されているパケットパラメータは以下の値を有する：
パケット長＝１０２４（０ｘ０４００） 方向転換１長＝１
パケットタイプ＝６５（０ｘ４１） 方向転換２長＝１
逆方向リンクフラグ＝０ 逆方向レート除数＝２
パラメータＣＲＣ＝０ｘｄｂ４３ 全ゼロは０ｘ００である
パケット長フィールドとパラメータＣＲＣフィールドとの間のパケットデータは次のとおりである：
０ｘ００、０ｘ０４、０ｘ４１、０ｘ００、０ｘ０２、０ｘ０１、０ｘ０１、０ｘ４３、０ｘｄｂ、０ｘ００、．．．
クライアントから返された第１の逆方向リンクパケットは、７のパケット長及び７０のパケットタイプを有するクライアント要求及びステータスパケットである。このパケットは、バイト値０ｘ０７、０ｘ００、０ｘ４６、．．．等で開始する。然しながら、第１のバイト（０ｘ０７）だけが図５２において目に見える。この第１の逆方向リンクパケットは、実際の逆方向リンク遅延を図示するために、図において、ほぼ１逆方向リンククロック期間時間移動されている。ゼロのホストからクライアントまでの往復遅延を有する理想の波形が、点線トレースとして示されている。
パラメータＣＲＣフィールドのＭＳバイトは、転送され、パケットタイプによって先行され、次に全ゼロフィールドが続く。ホストからのストローブは、ホストからのデータがレベルを変更するにつれて、１からゼロに、そして元の１に切り替わり、より幅の広いパルスを形成する。データがゼロになると、ストローブはより高いレートで切り替わり、データライン上でのデータの変化だけが、位置合わせフィールドの最後近くで変化を引き起こす。ストローブは、長時間の間、データ信号の固定された０レベル又は１レベルのために、図の残りの部分についてより高いレートで切り替わり、そして遷移はパルスパターン（端縁）で起こる(the transitions falling on the pulse pattern (edge))。
ホストの逆方向リンククロックは、クロックが逆方向リンクパケットに対処するために起動される方向転換１期間の最後までゼロである。図の下部の矢印は、開示の残りの部分から明らかとなるであろうように、データがいつサンプリングされるのかを示している。方向転換１の後に開始し、転送されているパケットフィールドの第１のバイトが示されており（ここでは１１００００００）、そしてラインレベルは、ディスエーブルにされているホストドライバから安定化している。第１のビットの通過の遅延は、そしてビット３について見られるように、データ信号のための点線から見られることが出来る。
図５３では、順方向リンクデータレートに基づいて逆方向レート除数の典型的な値を観察出来る。実際の逆方向レート除数は、適切な逆方向リンク動作を保証するために、往復リンク測定の結果として求められる。第１の領域５３０２は、安全な動作の領域に対応し、第２の領域５３０４は限界性能(marginal performance)の領域に対応する、一方、第３の領域５３０６は、適切に機能する可能性が低い設定値を示す。
往復遅延測定及び逆方向レート除数設定は、それらが、送信される又は受信されるビットの数よりは寧ろ実際のクロック期間の単位によって表わされそして操作されるので、順方向又は逆方向リンク上の何れかでのインタフェースタイプ設定のどれかで動作している間は、同じである。
一般に、最も可能性の高い逆方向レート除数は、Ｉ型インタフェース又はこの例の場合は
Figure 2007528681
を使って往復遅延測定パケットの測定ウィンドウにおいて送信されることが出来るビットの数の半分である。
逆方向ビット時間が往復遅延よりもより小さいことを可能とする代替手段として、高度な逆方向データサンプリング方法が使用されることもまた出来る。この技術の場合、ホストは、往復遅延を測定するだけでなく、ゼロ遅延のリンクとクライアントの「理想的な」ビット境界に関してクライアントからの応答のフェーズを決定することもまた出来る。クライアント装置応答のフェーズを知ることによって、ホストは、クライアントから逆方向データビットをサンプリングする相対的に安全な時間を決定出来る。往復遅延測定は、ホストに、逆方向データパケットフィールドの始まりに関して逆方向データの最初のビットの位置を示す。
高度な逆方向データサンプリングの1例の一実施形態が、図５２Bにおいてグラフ形式で図示されている。ゼロ往復遅延を有した理想的な逆方向データ信号が点線波形として示されている。３．５ＭＤＤＩ＿Ｓｔｂサイクルと４ＭＤＤＩ＿Ｓｔｂサイクルとの間の実際の往復遅延は、実線波形と理想波形との間に遅延の差として観測されることが出来る。これは、往復遅延測定パケットを使って測定され、そして７順方向リンクビット時間に等しい測定往復遅延値(a measured round-trip delay value)であるであろうのと、同じ遅れである。この実施形態においては、逆方向データビットは長さ２ＭＭＤＩ＿Ｓｔｂパルスであり、それは４順方向リンクビット時間であり、それは２に等しい逆レート除数に相当する。高度逆方向データサンプリングの場合、他の所で説明されたようにそれを計算する代わりに、２の事前に選択された逆方向レート序数を使用することが便利である。これは、理想のサンプリング点が上記に説明された従来の測定を使って容易に決定されることが出来るので、高度な逆方向データサンプリングの場合は実質上最適な選択であるように思える。
逆方向データ用の理想的なサンプリング点は、逆方向ビットあたり順方向リンククロックを除いて往復遅延(round-trip delay modulo forward link clocks per reverse)、又は、逆方向ビットあたり順方向リンククロックの数で割られた合計の往復遅延のリマインダ(reminder)をとることにより容易に計算されることが出来る。次に、データ遷移から離れた安全点を得るために１又は２を引く。この例では、７ｍｏｄ４＝３、次に３−１＝２、又は３−２＝１。安全サンプリング点は、ゼロ往復遅延用の「理想的な」ビット境界の端から１又は２の順方向リンクビット時間である。図は、タイミングダイアグラムのボトムで一連の垂直の矢によって示されているように、理想的なビット境界から２順方向リンクビット時間にサンプリング点を示す。第１のサンプリング点は、測定された往復遅延の後の第１の理想的なビット境界、プラス(plus)、安全サンプリングのためのオフセットである。この例では、往復遅延測定値は７であり、従って次の理想的なビット境界は８番目のビット時間にあり、次に安全サンプリング点のために１又は２を加え、従って第１のビットは、逆方向データパケットフィールドの開始後９又は１０の順方向リンクビット時間でサンプリングされなければならない。
ＸＩ．方向転換及びガード時間
逆方向リンクカプセル化パケットの中の方向転換１フィールドは、ホストドライバがディスエーブルし、そしてクライアントドライバが同時にイネーブルにする時間を与える。往復遅延測定パケットの中のガード時間１フィールドは、ホストとクライアントのオーバーラップを可能にするので、ホストインタフェースドライバがディスエーブルされる前に、クライアントドライバはイネーブルに出来る。逆方向リンクカプセル化パケットの中の方向転換２フィールドは、クライアントからの前のフィールド中のデータが、ホストドライバがイネーブルにされる前に、完全に送信されることを可能にする。ガード時間２フィールドは、クライアントとホストのドライバが論理ゼロレベルで同時に駆動するのを可能にする時間値又は時間期間を提供する。ガード時間１フィールドとガード時間２フィールドは、一般に、調整されるように意図されていない長さの事前に設定された又は事前に選択された値で充填されている。使用されているインタフェースハードウェアに応じて、これらの値は、経験的データを使用して作成され(developed)、そしていくつかの例では動作を改善するために調整されることができる。
方向転換１
いくつかの要因は方向転換１の長さの決定に寄与し、そしてこれらは、順方向リンクデータレート、ホスト内のＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間、及び一般にホストディスエーブル時間と同じであるクライアントドライバのイネーブル時間、である。方向転換１フィールドの長さは、２４ｔＢＩＴ （表ＸＩ）であるように選択される。方向転換１フィールドの順方向リンクバイトの数での長さは、インタフェースタイプファクタを使用し決定され、そして次の関係を使って計算される：
Figure 2007528681
但し、インタフェースタイプファクタは、１型の場合は１、２型の場合は２、３型の場合は４、そして４型の場合は８である。
方向転換２
方向転換２に一般に使用される時間の長さを決定する要因は、通信リンクの往復遅延、クライアントにおけるＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間、及びクライアントドライバディスエーブル時間と同じであるように特定されるホストドライバのイネーブル時間である。最大ホストドライバイネーブル時間及びクライアントドライバディスエーブル時間は別のところで指定される。往復遅延はｔＢＩＴの単位で測定される。方向転換２フィールドの順方向リンクバイトの数で指定される最小長さは、次の関係に従って計算される：
Figure 2007528681
例えば、１０順方向リンククロックの往復遅延を有する３型順方向リンクは、典型的に、ほぼ次の関係の方向転換２遅延を使用する：
Figure 2007528681
ＸＩＩ．代替逆方向リンクタイミング
上記されたタイミングと保護周波数帯は、高データ転送レートインタフェースを達成するように機能するが、発明者らは、逆方向タイミング発見を変更することにより、往復時間よりもより短い逆方向ビット長を可能にする技術を発見した。
上記に示されたように、クロックサイクルの数が、逆方向タイミングパケットのガード時間１の最後のビットから最初のビットがＩＯクロックの立ち上がりでサンプリングされるまでカウントされるように、逆方向リンクのタイミングに対する以前のアプローチが構成されている。それは、ＭＤＤIの入力と出力を計時するために使用されるクロック信号（複数の場合がある）である。逆方向レート除数のための計算はそこで次によって与えられる：
Figure 2007528681
これは、往復遅延に等しいビット幅を提供し、結果として、非常に信頼できる逆方向リンクをもたらす。然しながら、逆方向リンクは、より速く、或いはより高いデータ転送レートで作動出来ることが示されており、発明者らはそれを利用することを望んでいる。新しい本発明の技術は、より高いスピードを達成するために、インタフェースの更なる機能を利用することを可能にする。
これは、ホストに、１がサンプリングされるまでクロックサイクル数をカウントさせることによって達成されるが、ホストは、逆方向タイミングパケットの間、立ち上がりと立ち下りの両方でデータラインをサンプリングする。これは、ホストが、ビットが安定していることを確実にするために、逆方向ビット内で最も有用で或いは最適でもあるサンプリング点を選ぶことを可能にする。つまり、逆方向トラフィック逆方向カプセル化パケットにとってデータをサンプリングするための最も有用で或いは最適な立ち上がりを発見することである。最適なサンプリング点は、逆方向リンク除数と、第１のものが立ち上がりで検出されたのか或いは立ち下りで検出されたのかどうか、の両方に依存している。新しいタイミング方法は、ホストが、逆方向カプセル化パケットにおいてどこでサンプリングするのかを決定するために、逆方向リンクタイミングのためにクライアントによって送信される０ｘＦＦ ０ｘＦＦ ０ｘ００パターンの第１の端縁を単に(just)探すことを可能にする。
到着する逆方向ビットと、そしてそのビットがどのようにして様々な逆方向レート除数を探すのか、の例が、ガード時間１の最後のビット以来ずっと発生した多くのクロックサイクルと共に、図６４において示されている。図６４では、もし最初の端縁が立ち上がりと立ち下り（立ち上がり／立ち下りとラベル表示される）の間で発生すると、それが逆方向ビットの期間内で発生する唯一の立ち上がりであるので、１の逆方向レート除数の最適サンプリング点、最適サンプル点は、「ｂ」とラベル表示されているクロックサイクル端縁である、ということが分かる。２の逆方向レート除数の場合、サイクル端縁「ｃ」は「ｂ」よりビット端縁により近いので、最適サンプリング点はおそらく依然としてクロックサイクル前縁「ｂ」である。４の逆方向レート除数の場合、最適サンプリング点は、それは、値がおそらく安定化した逆方向ビットのバックエッジにより近いので、おそらくクロックサイクル端縁「ｄ」である。
図６４に戻ると、もし、然しながら、第１の端縁が立ち下りと立ち上がり（立ち下り／立ち上がりとラベル表示される）の間で発生すると、１の逆方向レート除数の最適サンプリング点は、それが逆方向ビット期間内の唯一の立ち上がりであるため、サンプリング点クロックサイクル端縁「ａ」である。２の逆方向レート除数の場合、最適サンプリング点は端縁「ｂ」であり、そして４の逆方向レート除数の場合、最適サンプリング点は端縁「ｃ」である。
逆方向レート除数がどんどんより大きくなるにつれて、真ん中にもっとも近いのは立ち上がりでなければならないので、最適サンプリング点は、確かめる又は選択するのがより容易になる、ということが分かる。
ホストは、タイミングパケットデータの立ち上がりデータ端縁がデータライン上で観察される前に、立ち上がりクロックの数を見つけるためにこの技術を使用できる。それは、次に、ビットがいつも可能な限り真中近くでサンプリングされることを合理的に確実にするために、端縁(edge)が立ち上がりと立ち下りの間で発生するのか或いは立ち下りと立ち上がりの間で発生するのか、そして逆方向レート除数が何であるのか、に基づき、数カウンタに加える更なるクロックサイクル数を決定出来る。
いったんホストがクロックサイクル数を選択又は決定すると、それは、特定の逆方向レート除数が機能するかどうかを判断するために、クライアントと様々な逆方向レート除数を「調査」できる。ホスト（及びクライアント）は、１の除数で開始し、そして、この逆方向レートがデータを転送するために適切に機能するかどうかを判断するために、クライアントから受信される逆方向ステータスパケットのＣＲＣをチェック出来る。もしＣＲＣが破壊されている場合は、おそらくサンプリングエラーがあり、そしてホストは、逆方向レート除数を増やし、そしてステータスパケットの要求を再び試みることが出来る。もし第２の要求されたパケットが破壊されている場合には、除数は再び増加されることが出来、そして要求は再び行われることができる。もしこのパケットが正しく復号されている場合は、この逆方向レート除数は、全ての将来の逆方向パケットについて使用されることが出来る。
この方法は、逆方向タイミングが初期の往復タイミング推定値から変化すべきでないので、効果的且つ有用である。もし順方向リンクが安定している場合は、クライアントは、たとえ逆方向リンク障害があったとしても、順方向リンクパケットを復号し続けるべきである。言うまでもなく、この方法は完全な逆方向リンクを保証しないので、リンクのための逆方向リンク除数を設定することは、今までどおりホストの責任である。加えて、除数は主として、ＩＯクロックを生成するために使用されるクロックの質に左右される。もしそのクロックがかなりの量のジッタを有している場合は、サンプリングエラーのより高い可能性がある。このエラー確率は、往復遅延においてクロックサイクルの量と共に増加する。
このインプリメンテーションは、１型逆方向データの場合に最も上手く機能するように思えるが、２型から４型までの逆方向データの場合は、データライン間の歪みが潜在的に大きすぎて、単に１つのデータペアのために最も上手く機能するレートでリンクを実行できないために、問題を与えるかもしれない。然しながら、データレートは多分、動作のために２型から４型までを用いても、前の方法にまで減速される必要はない。この方法はまた、理想的な又は最適なクロックサンプルロケーションを選択するために、各データライン上で繰り返されれば(if duplicated)、最も上手く機能するかもしれない。もしそれらが各データペアに対し同じサンプル時間にある場合は、この方法は機能し続けるであろう。もしそれらが異なるサンプル期間にある場合は、２つの異なる手法が使用されてよい。最初のものは、たとえそれが各データペアに対し同じでないにしても、各データポイントに対し所望される或いはもっと最適化されたサンプルロケーションを選択することである。ホストは次に、データペアのセットから全てのビットをサンプリングした後にデータストリームを再構築出来る：２型の場合は２ビット、３型の場合は４ビット、そして４型の場合は８ビット。もう一方のオプションは、全てのデータペアに対しデータビットが同じクロック端縁でサンプリングされることが出来るように、ホストが逆方向レート除数を増加させることである。
ＸＩＩＩ．リンク遅延及び歪みの影響
ＭＤＤＩ＿ＤａｔａペアとＭＤＤＩ＿Ｓｔｂとの間の順方向リンク上での遅延歪みは、遅延歪み補償が使用されなければ、最大可能のデータレートを制限し得る。タイミング歪みを引き起こす遅延の差異は、コントローラ論理回路、ラインドライバ及びレシーバ、そして以下に概略されるようなケーブルとコネクタに起因している。
Ａ．歪みによって制限されるリンクタイミング分析（ＭＤＤＩ １型）
１．1型リンクの遅延及び歪みの例
図４１において示されるインタフェース回路に類似した典型的なインタフェース回路が、１型インタフェースリンクに対処することのために、図５７に示されている。図５７においては、ＭＤＤＩ１型順方向リンクの複数の処理又はインタフェースのステージ(stages)の各々に対し、伝搬遅延と歪みのための例示的な又は典型的な値が示されている。ＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿Ｄａｔａ０の間の遅延の歪みは、出力クロックのデューティサイクルを変形させる(distorted)。フリップフロップ５７２８、５７３２を使用するレシーバフリップフロップ（ＲＸＦＦ）ステージのＤ入力でのデータは、クロック端縁後にわずかしか変化しない(changes slightly)ので、それは確実にサンプリングされることが出来る。図は、このタイミング関係を生じさせることで２つの異なる問題を解決するために使用されている２つのカスケード式遅延ライン５７３２ａと５７３２ｂを示している。実際のインプリメンテーションでは、これらは単一の遅延エレメントに結合されてよい。
インタフェースを通した例示的な信号処理のための１型リンク上でのデータ、Ｓｔｂ（ストローブ）及びクロック回復タイミングが、図５８において示されている。
重大な意味をもつ総遅延歪みは、一般に、次のステージにおける歪みの総和から発生する又は生じる：フリップフロップ５７０４、５７０６付きのトランスミッタフリップフロップ（ＴＸＦＦ）；ドライバ５７０８、５７１０付きのトランスミッタドライバ（ＴＸＤＲＶＲ）；ケーブル５７０２；レシーバ５７２２、５７２４付きのレシーバラインレシーバ（ＲＸＲＣＶＲ）；及びレシーバＸＯＲ論理回路（ＲＸＸＯＲ）。遅延１ ５７３２ａは、次の関係によって決定されるＲＸＸＯＲステージにおけるＸＯＲゲート５７３６の遅延にマッチングする(match)か又を超える(exceed)べきである：
Figure 2007528681
レシーバフリップフロップ５７２８、５７３２のＤ入力が、そのクロック入力の前に変化しないように、この要件を満たすことが望ましい。これはＲＸＦＦの保持時間がゼロである場合に有効である。
遅延２の目的又は機能は、次の関係に従ってＲＸＦＦフリップフロップの保持時間を補償することである。
Figure 2007528681
多くのシステムにおいては、保持時間がゼロであるので、これはゼロとなり、そして言うまでもなくその場合には、遅延２の最大遅延もまたゼロであり得る。
レシーバＸＯＲステージにおける最悪のケースの歪みへの寄与は、データ−遅い／ストローブ−早い 場合にあり、この場合、遅延１は最大値にあり、そして、ＸＯＲゲートからのクロック出力は次の関係に従って可能な限り早く生じる：
Figure 2007528681
この状況においては、データは、ビットｎ＋１がレシーバフリップフロップの中にクロックドインされる(clocked into)時間に非常に近い２つのビット、ｎとｎ＋１、の間で変化する可能性がある。
ＭＤＤＩ １型リンクの最大データレート（最小ビット期間）は、ＭＤＤＩリンク内の全てのドライバ、ケーブル、及びレシーバを通して遭遇される最大歪みにＲＸＦＦステージにセットアップされた総データを加えた関数である。ＲＸＲＣＶＲステージの出力までのリンク中の総遅延歪みは次のように表現でき：
Figure 2007528681
なお、「ケーブル」は、様々な導線又は相互接続又はワイヤ及び対応する遅延を表わしており、そして最小ビット期間は次式によって与えられる：
Figure 2007528681
図５７において示される例では、外部モードの場合、ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＝１０００ｐｓｅｃであり、最小ビット期間は次のように表現されることが出来る：
ｔＢＩＴ−ｍｉｎ＝１０００＋２・１２５＋６２５＋１２５＋２００＋０＋１００
＝２３００ｐｓｅｃ、
或いは約４３４Ｍｂｐｓとして述べられる。図５７において示される例では、内部モードの場合、ｔＳＫＥＷ−ｍａｘ（ＬＩＮＫ）＝５００ｐｓｅｃであり、最小ビット期間は次のように表現されることが出来る：
ｔＢＩＴ−ｍｉｎ＝５００＋２・１２５＋６２５＋１２５＋２００＋０＋１００
＝１８００ｐｓｅｃ、
或いは約５５５Ｍｂｐｓとして述べられる。
Ｂ．ＭＤＤＩ ２型、３型、及び４型のリンクタイミング分析
図４１と図５７において示されるインタフェース回路に類似する典型的なインタフェース回路が、２型、３型、及び４型インタフェースリンクに対処することのために図５９において示されている。更なるエレメントが、更なる信号処理に対処するために、ＴＸＦＦ（５９０４）、ＴＸＤＲＶＲ（５９０８）、ＲＸＲＣＶＣＲ（５９２２）、及びＲＸＦＦ（５９３２、５９２８、５９３０）ステージにおいて使用される。図５９では、ＭＤＤＩ ２型順方向リンクのいくつかの処理又はインタフェースのステージの各々に対し伝搬遅延と歪みの例示的な又は典型的な値が示されている。出力クロックのデューティサイクルに影響を及ぼすＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿Ｄａｔａ０との間の遅延における歪みに加えて、これらの２つの信号の両方と他のＭＤＤＩデータ信号との間にもまた歪みがある。フリップフロップ５９２８と５９３０のみからなる(consisting of)レシーバフリップフロップＢ（ＲＸＦＦＢ）ステージのＤ入力でのデータは、クロック端縁の後、わずかしか変更されない(changed slightly)ので、それは確実にサンプリングされることが出来る。もしＭＤＤＩ＿Ｄａｔａ１がＭＤＤＩ＿Ｓｔｂ又はＭＤＤＩ＿Ｄａｔａ０よりもより早くに到着する場合、ＭＤＤＩ＿Ｄａｔａ１はそのとき、少なくとも遅延歪みの量の分、サンプリングされるために遅れさせるべきである。これを達成するためには、データは遅延３遅延ラインを使用して遅延されている。もしＭＤＤＩ＿Ｄａｔａ１がＭＤＤＩ＿ＳｔｂとＭＤＤＩ＿Ｄａｔａ０よりもより遅く到着し、そしてそれが遅延３の分遅延する場合、そのときＭＤＤＩ＿Ｄａｔａ１が変化する点は、次のクロック端縁のより近くに移動する。このプロセスが、ＭＤＤＩ ２型、３型、又は４型のリンクのデータレートの上限を決定する。２つのデータ信号とＭＤＤＩ＿Ｓｔｂの互いに関するタイミング又は歪みの関係について、いくつかの例示的な異なる可能性が、図６０Ａ、図６０Ｂ、及び図６０Ｃににおいて示されている。
ＭＤＤＩ＿ＤａｔａＸが可能な限り早く到着する時、ＲＸＦＦＢにおいて確実にデータをサンプリングするために、遅延３は次の関係に従って設定されている：
Figure 2007528681
最大リンクスピードは、最小許容ビット期間により決定される。これは、ＭＤＤＩ＿ＤａｔａＸが可能な限り遅れて到着する時に最も影響を受ける。その場合、最小許容サイクル時間は次式によって与えられる：
Figure 2007528681
リンクスピードの上限はそのとき：
Figure 2007528681
そして、次のとおり仮定すると：
Figure 2007528681
上記で与えられた例では、最小ビット期間の下限は次の関係により与えられる：
ｔＢＩＴ−ｍｉｎ（ｌｏｗｅｒ−ｂｏｕｎｄ）
＝２・（１０００＋２・１２５＋６２５＋２００）＋１５００＋１００＋０
＝５７５０ｐｓｅｃ、
これは約１７４Ｍｂｐｓである。
これは、１型リンクで使用されることが出来る最大データレートよりはずっと遅い。ＭＤＤＩの自動遅延歪み補償機能は、ファクタが有効データセットアップのちょうどふちにある最大リンクレートに遅延歪みが与える影響を大幅に減少させる。ＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂの間の較正された歪みは：
ｔＳＫＥＷ−ｍａｘ（Ｃａｌｉｂｒａｔｅｄ）＝２・ｔＴＡＰ−ＳＰＡＣＩＮＧ−ｍａｘ
であり、そして最小ビット期間は次のとおりである：
Figure 2007528681
ここで、「ＴＢ」又はｔＢは、ビット境界から最小出力レベルまでの信号ジッタ(signal jitter)を表わす。非対称(aymmetry)は、差動レシーバを通しての又は差動レシーバの内部遅延の非対称性の性質(asymmetrical nature)を単純に指す。「ＴＰ４」は、クライアント用の差動ラインドライバ及びレシーバのための接続又はインタフェース（クライアントの中のＭＤＤＩコントローラ装置のピン）に関連している、或いは電気的な特徴付け及びテストの目的(electrical characterization and testing purposes)のためにクライアント用の差動ラインドライバ及びレシーバのための接続又はインタフェース（クライアントの中のＭＤＤＩコントローラ装置のピン）として効果的に定義されている。それは、便利な又は予め定められた点を表わし、そこから、システムの残り全体にわたって、信号遅延が、リンクについて測定されそして特徴付けられる。一実施形態においては、ＴＰ４でのパラメータｔＢの最大値は、次の関係で定義される。
クライアントトランスミッタの外部モードの場合は、
ｔＤｉｆｆｅｒｅｎｔｉａｌ-Ｓｋｅｗ−ＴＰ４−ＤＲＶＲ−ＥＸＴ ＝０．３・ｔＢＩＴ
クライアントトランスミッタの内部モードの場合は、
ｔＤｉｆｆｅｒｅｎｔｉａｌ-Ｓｋｅｗ−ＴＰ４−ＤＲＶＲ−ＩＮＴ ＝０．６・ｔＢＩＴ
そして、クライアントレシーバの外部モードの場合は、
ｔＢ−ＴＰ４−ＲＣＶＲ−ＥＸＴ ＝０．０５１・ｔＢＩＴ＋１７５
である。
ラベルＴＰ４は、インタフェース及びリンクにおける種々のテストポイント（ＴＰ）を番号付けする際に実に有用である。一実施形態においては、このテストポイントロケーションは、内部と外部の両方のモードに対し同じであるように定義される。差動ラインドライバ及びレシーバを含むホストにおけるＭＤＤＩ＿コントローラ装置の接続又はインタフェースピンのための、又は、に関連している、対応する「ＴＰ０」テストポイントがある。この実施形態においては、ＴＰ０でのパラメータＴＢの最大値は、次の関係で定義される。
ホストレシーバの内部モードの場合は、
ｔＢ−ＴＰ０−ＲＣＶＲ−ＩＮＴ ＝０．０５１・ｔＢＩＴ＋５０ｐｓ
ホストレシーバの外部モードの場合は、
ｔＢ−ＴＰ０−ＲＣＶＲ−ＥＸＴ ＝０．０５１・ｔＢＩＴ＋１７５ｐｓ
そして、ホストトランスミッタの場合は、
ｔＢ−ＴＰ０ ＝０．１０２・ｔＢＩＴ
である。
図５９において示される例では、
ｔＳＫＥＷ−ｍａｘ（Ｄａｔａ０−Ｓｔｂ−Ｃａｌｉｂｒａｔｅｄ）＝３００ｐｓｅｃ
そして最小ビット期間は：
ｔＢＩＴ−ｍｉｎ−Ｃａｌｉｂｒａｔｅｄ ＝３００+２・１２５＋６２５＋２００＋１７５＋１００
＝１６５０ｐｓｅｃ、
約６０６Ｍｂｐｓである。
ＭＤＤＩ＿Ｄａｔａ１が可能な限り早く到着する時、ＲＸＦＦＢにおいて確実にデータをサンプリングするために、関連したプログラマブル遅延は、１タップの正確さで最適の設定に調整され、そして更なるタップ遅延が安全のために加えられる。最大リンクスピードは、最小許容ビット期間により決定される。これは、ＭＤＤＩ＿Ｄａｔａ１が可能な限り遅れて到着する時に最も影響を受ける。その場合、最小許容サイクル時間は：
ｔＢＩＴ−ｍｉｎ−Ｄａｔａ１−Ｃａｌｉｂｒａｔｅｄ ＝２・ｔＴＡＰ−Ｓｐａｃｉｎｇ−ｍａｘ＋２・ｔＴＡＰ−ＴＰ４、
ここで、「ＴＡ」又はｔＡは、ビット境界からセンタクロス(center crossing)までの信号ジッタを表わす。
図５９において与えられた例においては、サンプリングＭＤＤＩ＿Ｄａｔａに基づく最小ビット期間の下限は：
ｔＢＩＴ−ｍｉｎ―Ｄａｔａ１−Ｃａｌｉｂｒａｔｅｄ ＝２・１５０＋２・１２５ ＝５５０ｐｓｅｃ
一実施形態では、内部モードの場合のホストトランスミッタにおける遅延歪み、遅延非対称、及びクロックジッタに対する典型的な総遅延時間は次のように定義されるであろう：
ｔＡｓｙｍｍｅｒｔｙ−ＴＸＦＦ＋ｔＡｓｙｍｍｅｔｒｙ−ＴＸＤＲＶＲ＋ｔＳｋｅｗ−ＴＸＦＦ＋ｔＳｋｅｗ−ＴＸＤＲＶＲ＋ｔｊｉｔｔｅｒ−ｈｏｓｔ ＝０．４６７・（ｔＢＩＴ−１５０ｐｓ）、
そして外部モードの場合は次のように：
ｔＡｓｙｍｍｅｒｔｙ−ＴＸＦＦ＋ｔＡｓｙｍｍｅｔｒｙ−ＴＸＤＲＶＲ＋ｔＳｋｅｗ−ＴＸＦＦ＋ｔＳｋｅｗ−ＴＸＤＲＶＲ＋ｔｊｉｔｔｅｒ−ｈｏｓｔ ＝０．ＴＢＤ・（ｔＢＩＴ−１５０ＴＢＤｐｓ）、
一方、内部モードの場合のクライアント装置（ｔＢ−ＴＰ４）における遅延歪み、遅延非対称、及びセットアップ時間に対する典型的な総遅延時間は：
ｔＡｓｙｍｍｅｒｔｙ−ＲＸＲＣＶＲ＋ｔＡｓｙｍｍｅｔｒｙ−ＲＸＸＯＲ＋ｔＳｋｅｗ−ＲＸＲＣＶＲ＋ｔＳｋｅｗ−ＲＸＸＯＲ＋ｔｓｅｔｕｐ−ＲＸＦＦ ＝０．３０７・（ｔＢＩＴ−１５０ｐｓ）
そして外部モードの場合は次のように：
ｔＡｓｙｍｍｅｒｔｙ−ＲＸＲＣＶＲ＋ｔＡｓｙｍｍｅｔｒｙ−ＲＸＸＯＲ＋ｔＳｋｅｗ−ＲＸＲＣＶＲ＋ｔＳｋｅｗ−ＲＸＸＯＲ＋ｔｓｅｔｕｐ−ＲＸＦＦ ＝０．ＴＢＤ・（ｔＢＩＴ−ＴＢＤｐｓ）、
ここで用語ＴＢＤは、将来のラベルを、外部モードについての様々なよく理解された特性及び動作条件に基づくであろう決定された値であるように、維持しているフレキシブルな場所である。
ＸＩＶ．物理層相互接続説明
本発明に従ってインタフェースを実現するために有用な物理接続は、市販されているパーツ、例えば、ホスト側ではヒロセ電機株式会社（Ｈｉｒｏｓｅ Ｅｌｅｃｔｒｉｃ Ｃｏｍｐａｎｙ Ｌｔｄ．）により製造されるようなパーツ番号３２６０−８Ｓ２（０１）など、そしてクライアント装置側ではヒロセ電機株式会社（Ｈｉｒｏｓｅ Ｅｌｅｃｔｒｉｃ Ｃｏｍｐａｎｙ Ｌｔｄ．）により製造されるようなパーツ番号３２４０−８Ｐ−Ｃ、など、を使用して実現されることが出来る。１型／２型インタフェースと共に使用されるこのようなコネクタ向けの例示的なインタフェースピン割り当て、つまり「ピン配列」は、表ＸＩＩＩに一覧表示され、そして図６１において図示されている。
Figure 2007528681
シールドは、ホストインタフェース内のＨＯＳＴ＿Ｇｎｄに接続され、そしてケーブルの中のシールドドレイン線はクライアントコネクタのシールドに接続されている。然しながら、シールドとドレイン線はクライアントの内部の回路接地には接続されていない。
相互接続エレメント又は装置は、比較上の装置サイズに比べて邪魔であること無しに、或いは悪趣味であること無しに、ＰＤＡ及び無線電話、或いは携帯ゲーム装置、のような、移動体通信装置及び計算装置に使用するために十分小型であるように選ばれる、或いは設計されている。どんなコネクタ及びケーブル布線も、典型的な消費者環境での使用に対し十分耐久性があるべきであり、そして小型サイズを、特にケーブル布線の場合、及び相対的に低コストを、可能としなければならない。転送エレメントは、１型と２型の場合は最高約４５０Ｍｂｐｓまでの、８ビット並列４型バージョンの場合は最高３．６Ｇｂｐｓまでの転送レートを有する差動ＮＲＺデータであるデータ信号とストローブ信号とに対処しなければならない。
内部モードアプリケーションの場合、使用されている導線に対して同じ向きのコネクタが無いか、或いはこのような接続エレメントは非常に小型化される傾向がある。１つの例は、ホスト又はクライアント装置のどちらかを収納しているエレメント或いは集積回路を受け入れるためのゼロ挿入力「ソケット」である。別の例は、ホストとクライアントが、様々な相互接続導体と共にプリント基板上で常駐し、集積回路の相互接続のために導体上のコンタクトにはんだ付けされているハウジングから延長している「ピン」又はコンタクトを有する場合、である。
ＸＶ．動作
本発明の実施形態を使用するインタフェースの動作中にデータとパケットを処理する上で講じられる一般的なステップのまとめが、図５５においてのパケットを処理するインタフェース装置の概略と共に、図５４Ａ及び図５４Ｂにおいて示されている。これらの図中、プロセスは、クライアント及びホストが通信経路、ここではケーブル、を使用して接続されているかどうかについて決定を行うステップ５４０２において、開始する。これは、（ＵＳＢインタフェースについて見られるように）ホストへの入力でのコネクタ又はケーブル又は信号の存在を検出するソフトウェア又はハードウェアを使用する、ホストによる周期的なポーリング、或いは他の知られている技術、の使用を通して起こりうる。もしホストに接続されているクライアントがない場合、そのときそれは、アプリケーションに応じて単にある予め定められた長さの待機状態に入る、ハイバネーションモードに入る、或いはユーザにホストを再アクティブ化するための処置を講じることを要求するかもしれない将来の使用に待機するためにイナクティブな状態にされる、ことが出来る。例えば、ホストがコンピュータタイプの装置に常駐する時、ユーザは、画面アイコンをクリックしなければならないかもしれない、或いはクライアントを探すためにホスト処理をアクティブな状態にするプログラムを要求しなければならないかもしれない。再び、ＵＳＢ型接続の簡単なプラグインが、ホスト又は常駐ホストソフトウェアの機能と構成(configuration)に応じて、ホスト処理をアクティブな状態にすることが出来るであろう。
いったんクライアントが、ホストに接続される、又は逆も同様、或いは存在しているとして検出される場合、クライアント又はホストの何れかが、ステップ５４０４と５４０６において、サービスを要求する適切なパケットを送信する。クライアントはステップ５４０４において、クライアントサービス要求パケット又はステータスパケットの何れかを送信することが出来るであろう。リンクは、上記で説明されたように、前にシャットダウンされていたことがあり得るであろうから或いはハイバネーションモードであり得るであろうから、これは、その後に続く通信リンクの完全な初期化ではないかもしれない、ということに注意すべきである。いったん通信リンクが同期されそしてホストがクライアントと通信しようとすると、クライアントもまた、ステップ５４０８におけるように、ホストにクライアント機能パケットを提供する。ホストはここで、クライアントが対処できる転送レートを含むサポートのタイプを決定することを開始できる。
一般的に、ホストとクライアントはまた、ステップ５４１０において、使用されるサービスモードのタイプ（レート／スピード）、例えば１型、２型、などを交渉する。いったんサービスタイプが確立されると、ホストは情報の転送を開始できる。加えて、ホストは、ステップ５４１１において示されるように、他の信号処理と並列に通信リンクのタイミングを最適化するために往復遅延測定パケットを使用してよい。
前の方で述べられたように、全ての転送は、ステップ５４１２において転送されているのが示されるサブフレームヘッダパケットで始まり、ステップ５４１４において転送されているのが示されるデータのタイプ、ここではビデオ及び音声ストリームパケット、そしてフィラーパケット、が後に続く。音声及びビデオのデータは前に準備されている又はパケットの中にマッピングされているであろう、そして、フィラーパケットは、メディアフレーム用の必要数のビットを書き込むために必要に応じて或いは所望されるように挿入される。ホストは、サウンド装置をアクティブにするために、順方向音声チャネルイネーブルパケット等のパケットを送信できる。加えて、ホストは、上記で説明された他のパケットタイプを使用してコマンド及び情報を転送でき、ここではステップ５４１６においてカラーマップ、ビットブロック転送、又は他のパケットの転送として示されている。更に、ホストとクライアントは、適切なパケットを使用してキーボード又はポインティングデバイスに関連するデータを交換できる。
動作中、インタフェースモードの異なるデータレート又はタイプを所望するホスト又はクライアントにつながる、いくつかの異なるイベントの１つが発生することがあり得る。例えば、データを通信するコンピュータ又は他の装置は、パケットの作成又はプレゼンテーションにおいて減速の原因となるデータを処理する際に荷重条件に遭遇することがあり得るであろう。データを受信するクライアント装置は、専用ＡＣ電源からより限られたバッテリ電源に変更することがあり得るであろう、そして、より限られたバッテリパワー設定の下では、データを迅速に転送できない、コマンドを容易に処理できない、或いは同程度の解像度又はカラー深さを使用できないであろう。或いは、制限条件が排除される又は消滅することができ、何れの装置もより高いレートで転送することを可能にすることができるであろう。これはより望ましく、より高い転送レートモードに変更するように要求されることができる。
もしこれらの或いは他のタイプの知られている条件が発生する或いは変化する場合、ホスト又はクライアントのどちらかはそれらを検出し、そしてインタフェースモードを再交渉しようとしてよい。これはステップ５４２０において示され、ここでは、ホストは、別のモードへのハンドオフを要求するクライアントに、インタフェースタイプハンドオフ要求パケットを送信し、クライアントは、変更が求められることを確認するインタフェースタイプ肯定応答パケットを送信し、そしてホストは、指定されたモードに変更するために実行型ハンドオフパケットを送信する。
処理の特定の順序を要求していないが、クライアントとホストは、このようなエレメントはホスト側にもまた存在するかもしれないけれども、主にクライアントに関連する、ポインティングデバイス、キーボード、又は他のユーザ型入力装置、を対象とした、又は、から受信された、データに関連するパケットを交換することもまた出来る。これらのパケットは、通常、状態機械（５５０２）ではなく、汎用プロセッサタイプのエレメントを使用して処理される。加えて、上記で説明されたコマンドのいくつかもまた、汎用プロセッサ（５５０４、５５０８）によって処理されるであろう。
データ及びコマンドがホストとクライアントの間で交換された後、ある時点で、更なるデータが転送されるべきかどうか、或いはホスト又はクライアントが転送をサービスすることを中止しようとしているのかどうかに関して、決定が下される。これはステップ５４２２に示されている。もしリンクがハイバネーション状態に入る予定であるか又は完全にシャットダウンされる予定であるかの何れかである場合、ホストは、クライアントにリンクシャットダウンパケットを送信し、そして両方の側がデータの転送を終了する。
上記の動作処理において転送されているパケットは、ホストコントローラとクライアントコントローラに関連して前に説明されたドライバとレシーバを使用して転送される。これらのラインドライバ及び他の論理エレメントは、図５５の概略において示されるように、上記に説明された状態機械と汎用プロセッサに接続されている。図５５において、状態機械５５０２と汎用プロセッサ５５０４及び５５０８は、更に、示されていない他のエレメント、例えば、専用のＵＳＢインタフェース、メモリ素子、又は、ビューディスプレイ装置用のデータソースとビデオ制御チップを含むがこれらに限定されない、それらが対話するリンクコントローラの外部に常駐している、他のコンポーネントなど、に接続されてよい。
プロセッサ及び状態機械は、通信リンクの効率的な確立又は終了、及びパケットの転送を確実なものとするために、ガード時間等に関連して上記で説明されたようにドライバのイネーブル及びディスエーブル(enabling and disabling)の制御を提供する。
ＸＶＩ．ディスプレイフレームバッファ
ビデオデータバッファリング要件は、コンピュータグラフィックスと比較して、動画ビデオ画像の場合は異なっている。ピクセルデータは、クライアント上の画像が局所的にリフレッシュされることができるように、ほとんどの場合クライアント内のローカルフレームバッファに保存される。
フルモーションビデオが表示されている（ディスプレイ内のほぼすべてのピクセルが各メディアフレームを変更する）時、ディスプレイ上の画像が第２のフレームバッファからリフレッシュされている間に１つのフレームバッファの中に入信ピクセルデータを保存することが普通は好まれる。３以上のディスプレイバッファが、下記に説明されるように可視アーチファクト(artifacts)を除去するために使用されてよい。画像全体が１フレームバッファの中で受け取られる時、そのときバッファの役割は交換されることが出来、そして新規に受信された画像は次にディスプレイをリフレッシュするために使用され、もう一方のバッファは画像の次のフレームで充填される。この概念は図８８Ａにおいて図示されており、ここでは、ピクセルデータは、ディスプレイ更新ビットを「０１」に設定することによって、オフライン画像バッファに書き込まれる。
他のアプリケーションにおいては、ホストは、画像全体を塗り直す必要なく、画像の小さな部分だけを更新する必要がある。この状況においては、図８８Ｂにおいて詳細に示されるように、新しいピクセルを、ディスプレイをリフレッシュするために使用されているバッファに、直接的に書き込むことが望まれる。
小型ビデオウィンドウ付きの固定画像を有するアプリケーションでは、図８８Ｃに示されるように、固定された画像を両方のバッファに書き込み（「１１」に等しいディスプレイ更新ビット）、そしてそのあと後にディスプレイ更新ビットを「０１」に設定することによりオフラインバッファに動画のピクセルを書き込むことが最も容易である。
以下の規則は、同時に新しい情報をクライアントに書き込みそしてディスプレイをリフレッシュする間のバッファポインタの有用な操作を記述している。３つのバッファポインタが存在する：ｃｕｒｒｅｎｔ＿ｆｉｌｌは、ＭＤＤＩリンク上でデータから現在充填されているバッファを指す。ｊｕｓｔ＿ｆｉｌｌｅｄは、最後に(most recently)充填されたバッファを指す。ｂｅｉｎｇ＿ｄｉｓｐｌａｙｅｄは、ディスプレイをリフレッシュするために現在使用されているバッファを指す。全ての３つのバッファポインタは、０からＮ−１の値を含んでよい、ここで、Ｎはディスプレイバッファの数であり、Ｎ≧２である。バッファポインタ上の演算はｍｏｄＮであり、例えばＮ＝３そしてｃｕｒｒｅｎｔ＿ｆｉｌｌ＝２の時、ｃｕｒｒｅｎｔ＿ｆｉｌｌをインクリメントすることは、ｃｕｒｒｅｎｔ＿ｆｉｌｌが０に設定される原因になる。Ｎ＝２である単純な場合には、ｊｕｓｔ＿ｆｉｌｌｅｄはいつもｃｕｒｒｅｎｔ＿ｆｉｌｌの補数である。全てのＭＤＤＩメディアフレーム境界（ゼロに等しいサブフレームカウントフィールドを備えたサブフレームヘッダパケット）に関して、指定された順序で以下のオペレーションを実行する：ｊｕｓｔ＿ｆｉｌｌｅｄをｃｕｒｒｅｎｔ＿ｆｉｌｌに等しく設定し、ｃｕｒｒｅｎｔ＿ｆｉｌｌをｃｕｒｒｅｎｔ＿ｆｉｌｌ＋１に設定する。
ＭＤＤＩビデオストリームパケットは、以下の構造或いは手法に従ってバッファ更新する：ディスプレイ更新ビットが「０１」に等しい時、ピクセルデータは、ｃｕｒｒｅｎｔ＿ｆｉｌｌによって指定されるバッファに書き込まれる；ディスプレイ更新ビットが「００」に等しい時、ピクセルデータは、ｊｕｓｔ＿ｆｉｌｌｅｄによって指定されるバッファに書き込まれる；そして、ディスプレイ更新ビットが「１１」に等しい時、ピクセルデータは全てのバッファに書き込まれる。ディスプレイは、ｂｅｉｎｇ＿ｄｉｓｐｌａｙｅｄポインタによって指定されるバッファからリフレッシュされる。ディスプレイが１つのフレームリフレッシュエポックの最後のピクセルをリフレッシュした後、そしてそれが次のフレームリフレッシュエポックの中の最初のピクセルのリフレッシュを開始する前に、ディスプレイ更新プロセスは、ｂｅｉｎｇ＿ｒｅｆｒｅｓｈｅｄをｊｕｓｔ＿ｆｉｌｌｅｄに等しく設定する動作を実行する。
ピクセルデータ属性フィールドを備えたパケットは、ピクセルデータが書き込まれるべきフレームバッファを指定する１対のディスプレイ更新ビットを含む。クライアント機能パケットは、ディスプレイ更新ビットのどの組み合わせがクライアントにおいてサポートされるのかを示す３つの追加ビットを有する。多くの場合、コンピュータにより生成される画像は、ユーザ入力に基づいて増分的に(incrementally)更新される必要がある、或いはコンピュータネットワークから受信される情報から引き出される必要がある。ディスプレイ更新ビット組み合わせ「００」と「１１」は、ピクセルデータを、表示されているフレームバッファに或いは両方のフレームバッファに書き込ませることによってこの動作モードをサポートする。
ビデオ画像に対処する時、図８９は、どのようにしてビデオ画像が、表示更新ビットが「０１」に等しい状態でビデオデータがＭＤＤＩリンク上で送信される時に１ペアのフレームバッファを使用して、表示されるのかを示す。メディアフレーム境界がＭＤＤＩリンク上で検出された後に、ディスプレイリフレッシュプロセスは、現在リフレッシュされているフレームのリフレッシュプロセスが完了する時、次のフレームバッファからのリフレッシュを開始する。
図８９に関連する重要な仮定は、画像が、クライアントがディスプレイをリフレッシュするためにフレームバッファからピクセルを読み取る（通常、左上から、行ごとに読み取り、画面の右下角へ）のに使用するのと同じ順序で送信されるピクセルの連続ストリームとして、ホストから受信されるという点である。これは、ディスプレイリフレッシュ動作と画像転送動作が同じフレームバッファを参照している場合に重要な詳細である。
部分的な画像を表示するのを回避するために、ディスプレイリフレッシュフレームレートは、画像転送フレームレートよりもより大きいことが必要である。図９０は、どのようにして遅いディスプレイリフレッシュレートで、即ち、ディスプレイリフレッシュが画像転送よりもより遅い状態で、画像フラグメンテーションが発生しうるのかを示す。
コンピュータグラフィックス画像と動画ビデオ画像との組み合わせを含む画像においては、ビデオピクセルデータがメディアフレームの小さい部分を占有している可能性がある。これは、ディスプレイリフレッシュ動作と画像転送とが同じフレームバッファを参照する状況において、重要であり得るであろう。これらの状況は、図９１において斜行平行線の陰影により示されており、ここでは、ディスプレイをリフレッシュするためにバッファから読み取られたピクセルは、２フレーム前にバッファに書き込まれたピクセルである可能性がある、或いは、それらは、同じフレームバッファに直ちに書き込まれているフレームに対応する可能性がある。
クライアントにおいての３つのフレームバッファの使用は、図９２において示されるように、フレームバッファへのアクセスに対する競合の小さなウィンドウの問題を解決するであろう。
然しながら、もしディスプレイリフレッシュレートが、図９３に示されているように、ＭＤＤＩリンク上のメディアフレームレートよりも小さい場合には、依然として問題がある。
図９４に示されるように、単一バッファを動画ビデオ画像用に使用することは多少問題がある。バッファへの画像転送よりもより速いディスプレイリフレッシュの状態で、時々、リフレッシュされている画像が、書き込まれているフレームの上部を示すであろう、そして、画像の下部は、前に転送されたフレームであろう。画像転送よりもより速いディスプレイリフレッシュ（好ましい動作モード）の状態で、同様な分割された画像を示すフレームのもっと頻繁な場合があるであろう。
ＸＶＩＩ．遅延値表
パケット処理遅延パラメータパケットは、クライアント中のある特定のコマンドを処理するために予測遅延を計算する表索引(a table lookup)機能を使用する。表の中の値は、遅延値の非常に幅広い動的範囲を提供するために、対数的に増加する。本発明の実施形態をインプリメントするための有効な例示的な遅延値一覧表が、対応する指数値対遅延値と共に、下記の表ＸＸで得られる。
Figure 2007528681
遅延は、表のインデックスとして指定パラメータを使用する表索引を実行することにより計算される。これは、遅延がＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＴａｂｌｅ（ｉｎｄｅｘ）（パケット処理表（インデックス））に等しいことを意味する。例えば：もし遅延パラメータリストアイテムからのパラメータの１つが、１３４に等しい８ビット値である場合、そのとき遅延は、１６μｓｅｃであるＰａｃｋｅｔＰｒｏｃｅｓｓｉｎｇＴａｂｌｅ（１３４）に等しい。値２５５は、コマンド完了時間が計算によって決定されることができないことを、そしてホストがクライアント要求及びステータスパケットのグラフィックスビジーフラグ又はＭＣＣＳ ＶＣＰ制御パラメータＢ７ｈをチェックするであろうことを示す。
いくつかのケースでは、この遅延は、宛先画像の高さ、幅、又はピクセル数で乗算され、そして全体的なパケット処理遅延を計算するために他の遅延に加算される。
ＸＶＩＩＩ．マルチプルクライアントサポート
現在のプロトコルバージョンは、複数のクライアント装置を直接的にサポートしているように思われない。然しながら、大部分のパケットは、複数のクライアントを備えたシステムにおいて特定のクライアント装置に対応するように使用されることができる予約クライアントＩＤフィールドを含んでいる。現在、多くのアプリケーションの場合、このクライアントＩＤ又はこれらのクライアントＩＤはゼロに設定されている。サブフレームヘッダパケットもまた、ホストが複数のクライアントシステムをサポートするか否かを示すためのフィールドを含む。従って、複数のクライアント装置が、システム設計者が複数のクライアントホスト及びクライアントとの将来の互換性のために計画するのを支援するためのＭＤＤI又はプロトコルの将来のアプリケーションにおいて、接続されそして対応されそうであるであろう方法がある。
複数のクライアントを有するシステムにおいては、クライアントがホストに、図９５に示されるように、クライアントのデイジーチェーン(a daisy-chain)、又はハブを使用して、或いは図９６に示されるようにこれらの技術の組み合わせを使用して、接続されていることは有用である。そのようなディスプレイは唯一のクライアントとして動作するように設定されていることを予想される又は設定されているので、マルチクライアントシステムの場合あってはならないケースである、アドレス０を要求する1又は複数のクライアントが接続されている時のエラーメッセージのような、ある特定のエラーメッセージを、ホストが、接続されたクライアントを管理するために表示することもまた有用である。
ＸＩＸ．補遺
本発明の実施形態のためのアーキテクチャ及びプロトコルを実現するために使用される多様なパケットについて上記されたフォーマット、構造、及びコンテンツに加えて、更に詳しいフィールドコンテンツ又は動作が、パケットタイプのいくつかについてここに示されている。これらは、当業者が種々のアプリケーションのために本発明をもっと容易に理解しそして利用することを可能とするようにそれらの夫々の使用又は動作を更に明確にするためここに示されている。未だ説明されていないフィールドの内の数個のみがここでは更に説明される。更に、これらのフィールドは、上記に示された実施形態に関連した例示的な定義及び値を用いて示されている。然しながら、このような値は、本発明を限定するものとして解釈されるべきではなく、インタフェースとプロトコルを実現するために有用な１つ又は複数の実施形態を表しており、そして必ずしも全ての実施形態が一緒に又は同時に実践される必要はない。当業者により理解されるであるように、他の実施形態においては他の値が、データ又はデータレート転送結果の所望されるプレゼンテーションを達成するために、使用されることが出来る。
Ａ．ビデオストリームパケットについて
一実施形態においては、ピクセルデータ属性フィールド（２バイト）は、以下のように解釈される一連のビット値を有する。ビット１と０は、どのようにしてディスプレイピクセルデータが送られるのかを選択する。ビット値「１１」の場合、ピクセルデータは両目に、又は両目用にディスプレイされ、ビット値「１０」の場合、ピクセルデータは左目だけに送られ、そしてビット値「０１」の場合、ピクセルデータは右目だけに送られ、そして「００」のビット値の場合、ピクセルデータは、下記に説明されるビット８から１１までによって指定されることができるように代替ディスプレイに送られる。もしクライアントにおける或いはクライアントによって使用されている又は操作されている主ディスプレイが、ある形式の立体画像又は画像化(stereo images or imaging)をサポートしていない場合、そのときこれらのコマンドは、ディスプレイの要望どおりに効果(impact)を有するように効果的に植えつけられることが出来ない。このような状況又はコンフィギュレーションにおいては、結果として生じるコマンド又は制御がディスプレイによって実行されないであろうから、クライアントは、ビット値に拘らずに或いはビット値「０１」、「１０」、又は「１１」の何れに対してもピクセルデータを主ディスプレイに送るべきである。ステレオディスプレイ機能をサポートしないクライアントにおける主ディスプレイをアドレス指定するために値「１１」が使用されることが推奨されるが、実施形態によって要求されない。
ビット２は、ピクセルデータがインタレースフォーマットで提示されているのかどうかを示し、「０」の値で、ピクセルデータが標準プログレッシブフォーマットであることを意味し、そして行番号（ピクセルＹ座標）が、ある行から次の行に進むときに１インクリメントされることを意味する。このビットが「１」の値を有する時、ピクセルデータはインタレースフォーマットであり、そして行番号は、ある行から次の行に進むときに２インクリメントされる。ビット３は、ピクセルデータが代替ピクセルフォーマットにあることを示す。これはビット２によってイネーブルにされる標準インタレースモードに類似しているが、インタレースは、水平の代わりに垂直である。ビット３が「０」である時、ピクセルデータは標準プログレッシブフォーマットであり、そして列番号（ピクセルＸ座標）が、各連続ピクセルが受信されると１インクリメントされる。ビット３が「１」である時、ピクセルデータは代替ピクセルフォーマットにあり、そして列番号は、各ピクセルが受信されると２インクリメントされる。
データは、無線電話又は同様な装置又はポータブルコンピュータ又は上記で説明されたようなそのような他の装置のための内部ディスプレイに、又はから、転送されている、或いは、データは、装置に内蔵された又は直接的に結合されたカメラに、又はから、転送されている、ので、ビット４は、ピクセルデータがディスプレイ或いはカメラに関連しているのかどうかを示す。ビット４が「０」である時、ピクセルデータは、ディスプレイフレームバッファに、又はから、転送されている。ビット４が「１」である時、ピクセルデータは、何らかのタイプのカメラ又はビデオ装置に、又はから、転送されており、このような装置は本技術分野でよく知られている。
ビット５は、ピクセルデータがいつディスプレイ内のピクセルの次の連続行を含むのかを示すために使用される。これは、ビット５が「１」に等しく設定されているケースと見なされる。ビット５が「１」に設定されている時、そのときＸ左端縁、Ｙ上部端縁、Ｘ右端縁、Ｙ下部端縁、Ｘ開始、及びＹ開始のパラメータは、定義されておらず、そしてクライアントによって無視される。ビット１５が論理１レベルに設定される時、これは、このパケットの中のピクセルデータが画像の中のピクセルの最後の行であることを示す。クライアント機能パケットのクライアント特徴機能インジケータフィールドのビット８は、この特徴がサポートされているかどうかを示す。
ビット７と６は、ピクセルデータが書き込まれる予定のフレームバッファを指定するディスプレイ更新ビットである。更に具体的な効果は他のところで説明される。「０１」のビット値の場合、ピクセルデータはオフライン画像バッファに書き込まれる。「００」のビット値の場合、ピクセルデータは、ディスプレイをリフレッシュするために使用される画像バッファに書き込まれる。「１１」のビット値の場合、ピクセルデータは全ての画像バッファに書き込まれる。「１０」のビット値又は組み合わせは、無効な値又は指定として処理され、そしてピクセルデータは無視され、画像バッファのどれにも書き込まれない。この値は、インタフェースの将来のアプリケーションに対し用途を有するかもしれない。
ビット８から１１までは、代替ディスプレイ又はピクセルデータが送られるべきディスプレイロケーションを指定する４ビットの符号なし整数を形成する。ビット０と１は、ディスプレイクライアントがビット８から１１までを代替ディスプレイナンバとして解釈するために、「００」に等しく設定されている。もしビット０と１が「００」に等しくない場合、そのときビット８から１１までは、論理ゼロレベルに設定されている。
ビット１２から１４までは、将来の使用のために予約され、通常論理ゼロレベルに設定されている。ビット１５は、説明されたように、ビット５と共に使用され、そして論理１への設定ビット１５は、ピクセルデータフィールドにおけるピクセルの行がデータのフレームにおけるピクセルの最後の行であることを示す。論理１に設定されるビット５を有する次のビデオストリームパケットは、次のビデオフレームのピクセルの第１の行に対応する。
２バイトのＸ開始フィールドとＹ開始フィールドは、ピクセルデータフィールドにおける第１のピクセルの点（Ｘ開始、Ｙ開始）の絶対Ｘ座標と絶対Ｙ座標を指定する。２バイトのＸ左端縁フィールドとＹ上部端縁フィールドは、ピクセルデータフィールドによって充填される画面ウィンドウの左端縁のＸ座標と上部端縁のＹ座標、上部端縁のＹ座標を指定し、一方、Ｘ右端縁フィールドとＹ下部端縁フィールドは更新されているウィンドウの右端縁のＸ座標と下部端縁のＹ座表を指定する。
ピクセルカウントフィールド（２バイト）は、以下のピクセルデータフィールドの中のピクセルの数を指定する。
パラメータＣＲＣフィールド（２バイト）は、パケット長からピクセルカウントまでの全てのバイトのＣＲＣを含む。このＣＲＣがチェックできない場合、そのときはパケット全体が廃棄される。
ピクセルデータフィールドは、ディスプレイされる予定の未処理ビデオ情報(the raw video information)を含み、そしてそれは、ビデオデータフォーマット記述子フィールドによって記述される方法でフォーマットされる。データは、他のどこかで説明されたように、一度に一「行」送信される。ピクセルデータ属性フィールドのビット５が論理レベル１にセットされている時、そのときピクセルデータフィールドは、正確に１行のピクセルを含み、送信されつつある最初のピクセルは、最も左のピクセルに対応し、そして、送信される最後のピクセルは、最も右のピクセルに対応する。
ピクセルデータＣＲＣフィールド（２バイト）は、ピクセルデータのみの１６ビットＣＲＣを含む。もしこの値のＣＲＣ検証が失敗すると、そのときピクセルデータは依然として使用され得るが、ＣＲＣエラーカウントはインクリメントされる。
Ｂ．音声ストリームパケットについて
一実施形態においては、音声チャネルＩＤフィールド（１バイト）は、音声データがクライアント装置によって送信される特定の音声チャネルを識別するために、８ビットの符号なし整数値を使用する。物理音声チャネルは、０、１、２、３、４、５、６、又は７の値として、このフィールドによって物理チャネルに指定される、或いは物理チャネルにマッピングされ、これらの値は、夫々、左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中央チャネル、サブウーファーチャネル、サラウンド左チャネル、及びサラウンド右チャネルを示す。２５４の音声チャネルＩＤ値は、デジタル音声サンプルの単一のストリームが左前チャネルと右前チャネルの両方に送信されることを示す。これは、音声通信にステレオヘッドセットが使用される、生産性強化アプリケーションプログラムがＰＤＡで使用される、などの場合のようなアプリケーション、或いは、単純なユーザインタフェースが警告音を生成する場合の他のアプリケーション、のための通信を簡略化する。８から２５３までと２５５の範囲にわたるＩＤフィールドのための値は、当業者によって予期されるように、新しい設計が更なる指定を所望する場合の使用のために現在予約されている。
予約１フィールド（１バイト）は通常将来の使用のために予約されており、このフィールド全てのビットはゼロに設定される。このフィールドの１つの機能は、全てのその後の２バイトフィールドを１６ビットワードアドレスに位置合わせさせ、４バイトフィールド２を３２ビットワードアドレスに位置合わせさせることである。
音声サンプルカウントフィールド（２バイト）は、このパケットにおける音声サンプルの数を指定する。
サンプルあたりビット及びパッキングフィールドは、音声データのパッキングフォーマットを指定する１バイトを含む。一実施形態においては、一般に使用されるフォーマットは、ビット４から０までが、ＰＣＭ音声サンプルあたりのビットの数を定義するためのものである。ビット５は次に、デジタル音声データサンプルがパックされている(packed)かどうかを指定する。上記されたように、図１２は、パックされたサンプルとバイト位置合わせされた音声サンプルとの間の差異を示す。ビット５に対する「０」の値は、デジタル音声データフィールドの中の各ＰＣＭ音声サンプルがインタフェースバイト境界とバイト位置合わせされていることを示し、そして「１」の値は、各連続ＰＣＭ音声サンプルが前の音声サンプルに対してパックアップされている(packed up against)ことを示す。このビットは、ビット４から０まで（ＰＣＭ音声サンプルあたりのビット数）に定義される値が８の倍数ではない時にだけ有効である。ビット７から６は、システム設計が更なる指定を所望する場合の使用のために予約され、そして一般にゼロの値に設定されている。
音声サンプルレートフィールド（１バイト）は、音声ＰＣＭサンプルレートを指定する。使用されるフォーマットは、０の値は毎秒８，０００サンプル（ｓｐｓ）のレートを示し、１の値は１６，０００ｓｐｓを示し、２の値は２４，０００ｓｐｓ、３の値は３２，０００ｓｐｓ、４の値は４０，０００ｓｐｓ、５の値は４８，０００ｓｐｓ、６の値は１１，０２５ｓｐｓ、７の値は２２，０５０ｓｐｓ、そして８の値は４４，１００ｓｐｓを夫々示し、９から２５５までの値は将来の使用のために予約されており、従ってそれらは現在ゼロに設定されている。
パラメータＣＲＣフィールド（２バイト）は、パケット長から音声サンプルレートまでの全てのバイトの１６ビットＣＲＣを含む。もしこのＣＲＣが適切にチェックできない時、そのときパケット全体が廃棄される。デジタル音声データフィールドは、再生される予定の未処理音声サンプルを含み、そして、通常、符号なし整数として線形フォーマットの形をしている。音声データＣＲＣフィールド（２バイト）は、音声データだけの１６ビットＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのとき音声データは依然として使用されることができるが、ＣＲＣエラーカウントはインクリメントされる。
Ｃ．ユーザ定義ストリームパケットについて
一実施形態においては、２バイトのストリームＩＤ番号フィールドは、特定のユーザが定義したストリームを識別するために使用される。ストリームパラメータフィールドとストリームデータフィールドのコンテンツは、通常、ＭＤＤＩ装置製造業者によって定義される。２バイトのストリームパラメータＣＲＣフィールドは、パケット長から始まり音声コーディングバイトまでのストリームパラメータの全てのバイトの１６ビットのＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。ＭＤＤＩのエンドアプリケーションにより必要とされない場合、つまりスそれらがオプションと考えられている場合、ストリームパラメータフィールドとストリームパラメータＣＲＣフィールドの両方とも廃棄されてよい。２バイトのストリームデータＣＲＣフィールドは、ストリームデータだけのＣＲＣを含む。もしこのＣＲＣが適切にチェックできない場合、そのときストリームデータの使用は、アプリケーションの要件に応じ、オプションである。ＣＲＣが良好であることを条件としたストリームデータの使用は、一般に、ＣＲＣが良好であると確認されるまで、ストリームデータがバッファに入れられることを必要とする。ＣＲＣエラーカウントは、もしＣＲＣがチェックしない場合は、インクリメントされる。
Ｄ．カラーマップパケットについて
２バイトのｈＣｌｉｅｎｔＩＤフィールドは、以前に使用されたように、クライアントＩＤに予約される情報又は値を含む。このフィールドは一般に将来の使用のために予約されるので、現在の値は、ビットを「０」に設定することによって、ゼロに設定されている。
２バイトのカラーマップアイテムカウントフィールドは、カラーマップデータフィールドに含まれる３バイトのカラーマップアイテムの、或いはこのパケットの中のカラーマップデータに存在するカラーマップテーブルエントリの、総数を指定する値を使用する。この実施形態では、カラーマップデータのバイトの数は、カラーマップアイテムカウントの３倍である。カラーマップアイテムカウントは、カラーマップデータを送信しないためにゼロに等しく設定されている。もしカラーマップサイズがゼロである場合、そのときカラーマップオフセット値は一般に依然と送信されるが、それはディスプレイによって無視される。カラーマップオフセットフィールド（４バイト）は、クライアント装置におけるカラーマップテーブルの最初からこのパケット内のカラーマップデータのオフセットを指定する。
２バイトのパラメータＣＲＣフィールドは、パケット長から音声コーディングバイトまでの全てのバイトのＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。
カラーマップデータフィールドの場合、各カラーマップロケーションの幅はカラーマップアイテムサイズフィールドによって指定され、一実施形態においては、第１の部分が青の大きさ(the magnitude)を指定し、第２の部分が緑の大きさを指定し、そして第３の部分が赤の大きさを指定する。カラーマップサイズフィールドは、カラーマップデータフィールドに存在する３バイトのカラーマップテーブルアイテムの数を指定する。もし単一のカラーマップが１つのビデオデータフォーマットとカラーマップパケットの中に適合できない場合、そのときカラーマップ全体が、各パケット内に異なるカラーマップデータとカラーマップオフセットを有する複数のパケットを送信することによって指定されてよい。各カラーマップデータアイテム内の青、緑、そして赤のビット数は、ディスプレイ機能パケットのカラーマップＲＧＢ幅フィールドに指定されるのと一般に同じである。
２バイトのカラーマップデータＣＲＣフィールドは、カラーマップデータだけのＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときカラーマップデータは依然として使用されることができるが、ＣＲＣエラーカウントはインクリメントされる。
各カラーマップデータアイテムは、次の順序で送信されなければならない：青、緑、赤で、各成分の最下位ビットが最初に送信される。各カラーマップアイテムの個々の赤、緑及び青の成分はパックされ(packed)るが、各カラーマップアイテム（青の成分の最下位ビット）はバイト位置合わせされる必要がある。図９７は、６ビットの青、８ビットの緑、及び７ビットの赤を備えたカラーマップデータアイテムの１例を示す。この例の場合、カラーマップパケットのカラーマップアイテムサイズは２１に等しく、そしてクライアント機能パケットのカラーマップＲＧＢ幅フィールドは０ｘ０７８６に等しい。
Ｅ．逆方向リンクカプセル化パケットについて
パラメータＣＲＣフィールド（２バイト）は、パケット長から方向転換長までの全てのバイトの１６ビットＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。
一実施形態においては、逆方向リンクフラグフィールド（１バイト）は、クライアントからの情報を要求しそして逆方向リンクタイプを指定するために１セットのフラグを含む。もしビット（例えばビット０）が論理１レベルに設定されている場合、そのときホストは、指定された情報をクライアントに要求する。しかしもしビットが論理０レベルに設定されている場合、そのときホストはクライアントからの情報を必要としない。ビット０は、一般にクライアントによってホストに逆方向データパケットフィールド中で送信されるクライアント機能パケットをホストがいつ要望するかを示すために使用される。ビット１は、クライアントによってホストに逆方向データパケットフィールド中で送信されるクライアント要求及びステータスパケットをホストがいつ要望するかを示すために使用される。残りのビット（ここではビット２から７まで）は将来の使用のために予約され、そしてゼロに設定されている。然しながら、逆方向リンクのためのフラグを設定するために所望されるようにもっと多くのビットが使用されることが出来る。
逆方向レート除数フィールド（１バイト）は、逆方向リンクデータクロックに関連して発生するＭＤＤＩ＿Ｓｔｂサイクルの数を指定する。逆方向リンクデータクロックは、逆方向レート除数の２倍で除算される順方向リンクデータクロックに等しい。逆方向リンクデータレートは、逆方向リンクデータクロックと逆方向リンク上のインタフェースタイプに関連する。この実施形態においては、１型インタフェースの場合、逆方向データレートは逆方向リンクデータクロックに等しく、２型、３型、及び４型インタフェースの場合、逆方向データレートは、夫々、逆方向リンクデータクロックの２倍、４倍、及び８倍に等しい。
全ゼロ１フィールドは、ビットを論理ゼロレベルに設定することによって値がゼロに等しく設定されている１グループのバイト、ここでは８、を含み、そして、クライアントが、方向転換１フィールドの間にホストのラインドライバをディスエーブルにする前にＭＤＤＩ＝Ｓｔｂのみを使用してクロックの回復を開始するのを可能とするのに十分な時間、全てのＭＤＤＩ＿Ｄａｔａ信号が論理ゼロレベルにあることを保証するために使用される。一実施形態では、全ゼロ１フィールドの長さは、ケーブルの往復遅延における順方向リンクバイト伝送時間数(the number of forward link byte transmission times)よりも大きい又は同じである。
方向転換１長フィールド（１バイト）は、方向転換１に割り当てられるバイトの総数を指定し、第１の方向転換期間を確立する。方向転換１フィールド（１バイト）は、方向転換１長パラメータにより指定されるバイトの数を使用し、ホスト内のラインドライバがディスエーブルにされる前に、クライアント内のＭＤＤＩ＿Ｄａｔａラインドライバがイネーブルにすることを可能とするように割り当てられている。クライアントは、方向転換１のビット０の間にそのＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルにし、そしてホストは、方向転換１の最後のビットの前に完全にディスエーブルにされるようにその出力をディスエーブルにする。あたかもＭＤＤＩ＿Ｄａｔａ０が、方向転換１期間の全期間、論理ゼロレベルにあるかのように、ＭＤＤＩ＿Ｓｔｂ信号は動作する。方向転換１の設定についてのより完全な説明は上記に与えられている。
逆方向データパケットフィールドは、クライアントからホストへ転送される一連のデータパケットを含む。クライアントは、それがホストに送信するデータを持たない時、フィラーパケットを送信してもよく、或いは、ＭＤＤＩ＿Ｄａｔａラインを論理ゼロ状態又はレベルに駆動してもよい。この実施形態においては、もしＭＤＤＩ＿Ｄａｔａラインがゼロに駆動されると、ホストはこれをゼロ長（有効長ではない）のパケットとして解釈し、そしてホストは、現在の逆方向リンクカプセル化パケットの持続期間中、クライアントから更なるパケットを受け入れないであろう。
方向転換２長フィールド（１バイト）は、第２の方向転換期間を確立するために、方向転換２に割り当てられるバイトの総数を指定する。方向転換２の推奨される長さは、往復遅延に対し要求されるバイトの数に、ホストがそのＭＤＤＩ＿Ｄａｔａドライバをイネーブルにするために要求される時間をプラス(plus)したものである。方向転換２長はまた、ホストにおいて逆方向リンクパケットを処理するのに十分な時間を与える最小限要求された又は計算された値よりもより大きな値であり得る。
方向転換２フィールドは、方向転換長パラメータによって指定されるようなバイトの数のみからなる(consisit of)。ホストは、それがそのＭＤＤＩ＿Ｄａｔａラインドライバを方向転換２の間イネーブルにする前に、少なくとも往復遅延時間待機する。方向転換２の最後のビットの前にそれら（ホストのＭＤＤＩ＿Ｄａｔａラインドライバ）が概して完全にイネーブルにされるように、ホストはそのＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルにし、そして、方向転換２の最後のビットの前にそれら（クライアントの出力）が概して完全にディスエーブルにされるように、クライアントはその出力をディスエーブルにする。方向転換２フィールドの目的は、逆方向データパケットフィールドからのデータの残量がクライアントから送信される又は転送されることを可能とすることである。割り当てられた安全マージン量とインタフェースをインプリメントする異なるシステムにおいては差異(variations)があり、ホストの中の、又はホストでの、ラインレシーバによって見られるように、ホストもクライアントも、方向転換２フィールド期間のある部分の間、ＭＤＤＩ＿Ｄａｔａ信号を論理ゼロレベルに駆動しないであろうことは可能である。あたかも方向転換２期間の実質上全期間でＭＤＤＩ＿Ｄａｔａ０が論理ゼロレベルであるかのように、ＭＤＤＩ＿Ｓｔｂ信号は動作する。方向転換２の設定の説明は上記に与えられている。
逆方向データパケットフィールドは、クライアントからホストに転送されている一連のデータパケットを含む。前に説明されたように、フィラーパケットは、他のパケットタイプによって使用されていない残りのスペースを充填するために送信される。
全ゼロ２フィールドは、ビットを論理ゼロレベルに設定することによって値でゼロに等しく設定されている１グループのバイト（この実施形態では８）を含み、そして、方向転換２フィールドに続くホストのラインドライバをイネーブルにした後にＭＤＤＩ＿Ｄａｔａ０とＭＤＤＩ＿Ｓｔｂの両方を使用してクライアントがクロックを回復することを開始するのを可能にする、十分な時間の間、全てのＭＤＤＩ＿Ｄａｔａ信号が論理ゼロレベルにあることを確かなものにするために使用される。
Ｆ．クライアント機能パケットについて
一実施形態に対し説明されているように、プロトコルバージョンフィールドは、クライアントによって使用されるプロトコルバージョンを指定する。初期のバージョンは、現在１に等しく設定されており、そして、知られているであろうように新バージョンが作成されるときいずれ変更されるであろう、一方、最小プロトコルバージョンフィールドは、クライアントが使用する又は解釈する最小プロトコルバージョンを指定するために２バイトを使用する。この場合、ゼロ値もまた有効値である。データレート機能フィールド（２バイト）は、クライアントがインタフェースの順方向リンク上で各データペアに関し受信できる最大データレートを指定し、そして秒当たりメガバイト（Ｍｂｐｓ）の形式で指定される。インタフェースタイプ機能フィールド（１バイト）は、順方向リンク上及び逆方向リンク上でサポートされているインタフェースタイプを指定する。「１」に設定されているビットは、指定されたインタフェースタイプはサポートされていることを示し、そして「０」に設定されているビットは、指定されたインタフェースタイプはサポートされていないことを示す。ホスト及びクライアントは、少なくとも1型を順方向及び逆方向リンク上でサポートすべきである。隣接する範囲のインタフェースタイプをサポートすべき要件はない。例えば、インタフェースにおいて、１型及び２型のみをサポートするが３型及び４型はサポートしないことは、完全に有効であろう。順方向リンクと逆方向リンクが同じインタフェースで動作することもまた、必ずしも必要ではない。然しながら、リンクがハイバネーションを解除する時、他のモードが交渉され得る、選択され得る、又はそうでなければホスト及びクライアントの両方によって使用のために承認され得るまで、順方向及び逆方向の両リンクは１型モードにおける動作を開始すべきである。
一実施形態においては、サポートされているインタフェースが、順方向リンク上で２型（２ビット）、３型（４ビット）、又は４型（８ビット）の何れかを夫々選択するためにビット０、ビット１、又はビット２を選択することによって；そして逆方向リンク上で２型、３型、又は４型の何れかを夫々選択するためにビット３、ビット４、又はビット５を選択することによって；示されており、ビット６及び７は予約されそして一般にこの時ゼロに設定されている。ビットマップ幅フィールドと高さフィールド、ここでは各々２バイトであり、それぞれ、ピクセルで、ビットマップの幅と高さを指定する。
白黒機能フィールド（１バイト）は、白黒フォーマットで表示されることが出来る解像度のビットの数を指定するために使用される。もしディスプレイが白黒フォーマットを使用できない場合、このときこの値はゼロに設定されている。ビット７から４までは将来の使用のために予約され、従ってゼロとして設定されている。ビット３から０までは、各ピクセルに対して存在できるグレイスケールの最大ビット数を定義する。これらの４ビットは、各ピクセルに対して１から１５の値を指定することを可能にする。もし値がゼロである場合、そのとき白黒フォーマットはディスプレイによってサポートされていない。
Ｂａｙｅｒ機能フィールドは、解像度、ピクセルグループ、及びＢａｙｅｒフォーマットで転送されることができるピクセル順序、のビットの数を指定するために１バイトを使用する。もしクライアントがＢａｙｅｒフォーマットを使用できない場合、そのときこの値はゼロである。Ｂａｙｅｒ機能フィールドは、次の値から構成される：ビット３から０までは、各ピクセルに存在する輝度(intensity)の最大ビット数を定義し、一方ビット５から４までは、必要とされるピクセルグループパターンを定義し、一方ビット８から６までは必要とされるピクセル順序を定義し；ビット１４から９までは、将来の使用ために予約されており、一般に、当面ゼロに設定されている。ビット１５は、論理１レベルに設定される時、クライアントがパックフォーマット又はアンパックフォーマットの何れかでＢａｙｅｒピクセルデータを受け入れることが出来ることを示す。もしビット１５がゼロに設定されていると、これは、クライアントがアンパックフォーマットでのみＢａｙｅｒピクセルデータを受け入れることが出来ることを示す。
カラーマップ機能フィールド（３バイト）は、ディスプレイのカラーマップテーブルに存在するテーブルアイテムの最大数を指定する。もしディスプレイがカラーマップフォーマットを使用できない場合、そのときこの値はゼロに設定されている。
ＲＧＢ機能フィールド（２バイト）は、ＲＧＢフォーマットで表示されることが出来る解像度のビットの数を指定する。もしディスプレイがＲＧＢフォーマットを使用できない場合、そのときこの値はゼロに等しい。ＲＧＢ機能ワードは３つの別々の符号なし値から構成され：各ピクセルにおいて、ビット３から０までは青の最大ビット数を定義し、ビット７から４までは緑の最大ビット数を定義し、そしてビット１１から８までは赤の最大ビット数を定義する。現在、ビット１４から１２までは将来の使用のために予約されそして一般にゼロに設定されている。ビット１４から１２までは将来の使用のために予約されそして通常ゼロに設定されている。ビット１５は、論理１レベルに設定される時、クライアントがパックフォーマット又はアンパックフォーマットの何れかでＢＧＢピクセルデータを受け入れることが出来ることを示す。もしビット１５が論理ゼロレベルに設定されている場合、これは、クライアントがアンパックフォーマットでのみＲＧＢピクセルデータを受け入れることが出来ることを示す。
Ｙ Ｃｒ Ｃｂ機能フィールド（２バイト）は、Ｙ Ｃｒ Ｃｂフォーマットで表示されることができる解像度のビットの数を指定する。ディスプレイがＹ Ｃｒ Ｃｂフォーマットを使用できない場合、そのときこの値はゼロに等しく設定されている。Ｙ Ｃｒ Ｃｂ機能ワードは３つの別々の符号なし値から構成され：ビット３から０までは、Ｃｂサンプルの最大ビット数を定義し、ビット７から４まではＣｒサンプルの最大ビット数を定義し、ビット１１から８まではＹサンプルの最大ビット数を定義し、そしてビット１５から１２までは将来の使用のために予約されそしてゼロに設定されている。
クライアント特徴機能フィールドは、サポートされているクライアントでの特定の特徴を示す１セットのフラグを含む４バイトを使用する。論理１レベルに設定されるビットは、機能がサポートされていることを示し、一方論理ゼロレベルに設定されるビットは、機能がサポートされていないことを示す。一実施形態においては、ビット０の値は、ビットマップブロック転送パケット（パケットタイプ７１）がサポートされているかどうかを示す。ビット１、２、及び３の値は、ビットマップ領域塗りつぶしパケット（パケットタイプ７２）、ビットマップパターン塗りつぶしパケット（パケットタイプ７３）、又は通信リンクデータチャネルパケット（パケットタイプ７４）が、夫々、サポートされているかどうかを示す。ビット４の値は、クライアントが１つの色を透明にする機能があるかどうかを示し、一方ビット５と６の値は、夫々、クライアントがパックフォーマットでビデオデータ又は音声データを受け入れることができるかどうかを示し、そしてビット７の値は、クライアントがカメラから逆方向リンクビデオストリームを送信できるかどうかを示す。ビット８の値は、クライアントがピクセルデータのフルライン(a full line)を受信しそしてビデオストリームパケットのピクセルデータ属性フィールドのビット５によって指定されるようなディスプレイアドレス指定を無視する能力を有するかどうかを示し、そしてクライアントはまたピクセルデータ属性フィールドのビット１５を使用してビデオフレームデータのフレーム同期又は最後も検出できる。
ビット１１と１２の値は、いつ、クライアントが、ポインティングデバイスと交信中でポインティングデバイスデータパケットを送受信できる又はキーボードと交信中でキーボードデータパケットを送受信できる、のかを夫々示す。ビット１３の値は、ＶＣＰ特徴パケット、すなわち、ＶＣＰ特徴要求パケット、ＶＣＰ特徴応答パケット、ＶＣＰ設定特徴パケット、有効パラメータ要求パケット、及び有効パラメータ応答パケット、をサポートすることにより、クライアントが１つ又は複数の音声又はビデオのパラメータを設定する能力を有するかどうかを示す。ビット１４の値は、クライアントがピクセルデータをオフラインのディスプレイフレームバッファに書き込む能力を有するかどうかを示す。もしこのビットが論理１レベルに設定されている場合、そのときディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性のビット７と６）は値「０１」に設定されてよい。
ビット１５の値は、いつ、クライアントが、ピクセルデータを、現在ディスプレイ画像をリフレッシュするために使用されているディスプレイフレームバッファのみに書き込む能力を有するのかを示す。もしこのビットが１に設定されている場合、そのときディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性のビット７と６）は値「００」に設定されてよい。ビット１６の値は、いつ、クライアントが、単一のビデオストリームパケットからのピクセルデータを、全てのディスプレイフレームバッファに書き込む能力を有するのかを示す。もしこのビットが１に設定されている場合、そのときディスプレイ更新ビット（ビデオストリームパケットのピクセルデータ属性のビット７と６）は値「１１」に設定されてよい。
ビット１７の値は、いつ、クライアントが、特殊ステータス要求パケットに応答する能力を有するのかを示し、ビット１８の値は、いつ、クライアントが、往復遅延測定パケットに応答する能力を有するのかを示し、そしてビット１９の値は、いつ、クライアントが、順方向リンク歪み校正パケット往復遅延測定パケットに対する能力を有するのかを示す。
ビット２０の値は、いつ、クライアントが、ディスプレイパワー状態パケットに応答する能力を有するのかを示す。
ビット２１の値は、いつ、クライアントが、特殊ステータス要求パケットを解釈しそして有効ステータス応答リストパケットで応答する能力を有するのかを示す。クライアントは、他のところで説明されたように、有効ステータス応答リストパケットの有効パラメータ応答リストフィールドで更なる状態を返す能力を示す。
ビット２２の値は、クライアントがレジスタアクセスパケットに応答する能力を有するかどうかを示す。ビット９から１０まで及び２３から３１までは、システム設計者に有用な代替の指定又は将来の使用のために現在予約され、そして一般にゼロに等しく設定されている。
ディスプレイビデオフレームレート機能フィールド（１バイト）は、フレーム／秒で(in frames per second)ディスプレイの最大ビデオフレーム更新機能を指定する。ホストは、このフィールドで指定される値よりもより低いレートで画像を更新することを選んでよい。
音声バッファ深さフィールド（２バイト）は、各音声ストリームに専用であるディスプレイ内の弾性バッファの深さ(the depth)を指定する。
音声チャネル機能フィールド（２バイト）は、どの音声チャネルがクライアント又はクライアント接続装置によってサポートされているのかを示す１グループのフラグを含む。１に設定されるビットは、チャネルがサポートされていることを示し、そしてゼロに設定されているビットは、そのチャネルがサポートされていないことを示す。ビット位置は異なるチャネルに割り当てられ、例えば一実施形態におけるビット位置０、１、２、３、４、５、６、及び７は、左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中心チャネル、サブウーファーチャネル、サラウンド左チャネル、及びサラウンド右チャネルを、夫々示している。ビット８から１４までは、将来の使用のために現在予約されており、そして一般にゼロに設定されている。一実施形態においては、ビット１５は、クライアントが順方向音声チャネルイネーブルパケットに対しサポートを提供するのかどうかを示すために使用されている。もしこの場合であれば、ビット１５は論理１レベルに設定される。然しながら、もしクライアントが順方向音声チャネルイネーブルパケットの結果として音声チャネルをディスエーブルに出来ない場合、或いは、クライアントが何れの音声機能もサポートしない場合、そのときこのビットは論理ゼロレベル又は値に設定されている。
２バイトの音声サンプルレート機能フィールドは、順方向リンクに対し、クライアント装置の音声サンプルレート機能を示すために１セットのフラグを含む。ビット位置は、それに応じ異なるレートが割り当てられ、例えばビット０、１、２、３、４、５、６、７、及び８は、夫々、８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、及び４４，１００サンプル／秒（ＳＰＳ）に割り当てられ、ビット９から１５までは、所望されるように、将来の又は代替のレートの使用のために予約されているので、それらは現在「０」に設定されている。これらのビットの内の１つに対しビット値を「１」に設定することは、その特定のサンプルレートがサポートされていることを示し、ビットを「０」に設定することは、そのサンプルレートはサポートされていないことを示す。
最小サブフレームレートフィールド（２バイト）は、フレーム／秒で最小サブフレームレートを指定する。最小サブフレームレートは、クライアントステータス更新レートを、クライアント内のある特定のセンサ又はポインティングデバイスを読み取るのに十分であるように維持する。
２バイトのマイクサンプルレート機能フィールドは、逆方向リンクに対し、クライアント装置内のマイクの音声サンプルレート機能を示す１セットのフラグを含む。ＭＤＤＩの目的のために、クライアント装置マイクは、少なくとも８，０００サンプル／秒 レートを最小限度サポートするように構成される。このフィールドのビット位置は、異なるレートに割り当てられ、ビット位置０、１、２、３、４、５、６、７、及び８は、例えば、夫々、８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、及び４４，１００のサンプル／秒（ＳＰＳ）を表すために使用され、ビット９から１５までは、所望されるように、将来又は代替のレートの使用のために予約されているので、それらは現在「０」に設定されている。これらのビットの内の１つのビット値を「１」に設定することは、その特定のサンプルレートがサポートされていることを示し、そしてビットを「０」に設定することは、そのサンプルレートがサポートされていないことを示す。もしマイクが接続されていない場合、そのときマイクサンプルレート機能ビットの各々はゼロに等しく設定されている。
キーボードデータフォーマットフィールド（ここでは１バイト）は、キーボードがクライアントシステムに接続されているかどうかを、そして接続されているキーボードのタイプを指定する。一実施形態においては、ビット６から０までによって確立された値が、接続されているキーボードのタイプを定義するために使用される。もし値がゼロ（０）であれば、そのときキーボードタイプは未知(unknown)と見なされる。１の場合は、キーボードデータフォーマットは、標準ＰＳ−２様式であると見なされる。現在、２から１２５までの範囲の値は使用されておらず、ＭＤＤＩ及び対応するクライアント又はホストと共に使用するために特定のキーボード又は入力装置を定義するように、システム設計者及びインタフェースインコーオポレータ又は製品開発者の使用のために予約されている。１２６の値は、キーボードデータフォーマットがユーザ定義であることを示すために使用され、一方、１２７の値は、キーボードがこのクライアントに接続されることが出来ないことを示すために使用されている。更に、ビット７は、キーボードがクライアントと通信できるかどうかを示すために使用されることが出来る。このビットの意図された使用は、いつ、キーボードが、無線リンクを使用してクライアントと通信出来るかを示すことである。もしビット６から０までが、キーボードはクライアントに接続されることが出来ないこと、を示しているのであれば、ビット７は、ゼロレベルに設定されているであろう。従って、一実施形態の場合、ビット７の値が０の時、キーボードとクライアントとは通信出来ず、一方、もしビット７の値が１であれば、キーボード及びクライアントは、それらが互いに通信出来ることを確認する。
ポインティングデバイスデータフォーマットフィールド（ここでは１バイト）は、ポインティングデバイスがクライアントシステムに接続されているかどうかを、そして接続されているポインティングのタイプを指定する。一実施形態においては、ビット６から０までによって確立された値が、接続されているポインティングデバイスのタイプを定義するために使用される。もし値がゼロ（０）であれば、そのときポインティングデバイスタイプは未知(unknown)と見なされる。１の場合は、ポインティングデバイスデータフォーマットは、標準ＰＳ−２様式であると見なされる。現在、２から１２５までの範囲の値は使用されておらず、ＭＤＤＩ及び対応するクライアント又はホストと共に使用するために特定のポインティングデバイス又は入力装置を定義するように、システム設計者及びインタフェースインコーオポレータ又は製品開発者の使用のために予約されている。１２６の値は、ポインティングデバイスデータフォーマットがユーザ定義であることを示すために使用され、一方、１２７の値は、ポインティングデバイスがこのクライアントに接続されることが出来ないことを示すために使用されている。更に、ビット７は、ポインティングデバイスがクライアントと通信できるかどうかを示すために使用されることが出来る。このビットの意図された使用は、いつ、キーボードが、無線リンクを使用してクライアントと通信出来るかを示すことである。もしビット６から０までが、ポインティングデバイスはクライアントに接続されることが出来ないこと、を示しているのであれば、ビット７は、ゼロレベルに設定されているであろう。従って、一実施形態の場合、ビット７の値が０の時、ポインティングデバイスとクライアントとは通信出来ず、一方、もしビット７の値が１であれば、ポインティングデバイス及びクライアントは、それらが互いに通信出来ることを確認する。
コンテンツ保護タイプフィールド（２バイト）は、ディスプレイによってサポートされているデジタルコンテンツ保護のタイプを示す１セットのフラグを含む。現在、ビット位置０は、いつＤＴＣＰがサポートされているのかを示すために使用され、そしてビット位置１はいつＨＤＣＰがサポートされているのかを示すために使用され、ビット位置２から１５までは、所望されるような或いは利用出来るような他の保護スキームと共に使用するために予約されているので、それらは現在ゼロに設定されている。
製造業者名フィールド（ここでは２バイト）は、ＶＥＳＡ ＥＤＩＤ 仕様におけるのと同じ方法で３つの５ビットキャラクタにパックされる、製造業者のＥＩＳＡ ３−キャラクタＩＤを含む。キャラクタ「Ａ」は、００００１バイナリとして表わされ、キャラクタ「Ｚ」は、１１０１０バイナリとして表わされ、そして「Ａ」と「Ｚ」との間の全ての文字は、「Ａ」と「Ｚ」との間のアルファベット順に対応する連続バイナリ値として表わされる。製造業者名フィールドの最上位ビットは、使用されておらず、一般に、将来のインプリメンテーションにおいて使用されるまで当分は論理ゼロに設定される。例えば、文字列「ＸＹＺ」によって表わされる製造業者は、０ｘ６３３ａの製造業者名値を有するであろう。もしこのフィールドがクライアントによってサポートされていない場合は、それは一般にゼロに設定されている。製品コードフィールドは、ディスプレイ製造業者によって割り当てられた製品コードを含む２バイトを使用する。もしこのフィールドがクライアントによってサポートされていない場合は、それは一般にゼロに設定されている。
予約１、予約２、そして予約３のフィールド（ここでは各２バイト）は、情報を伝えることにおいて将来使用のために予約されている。これらのフィールドの全てのビットは、一般に、論理ゼロレベルに設定されている。このようなフィールドの目的は、現在のところ、続いて起こる２バイトのフィールドの全てを１６ビットワードアドレスに位置合わせさせ、そして４バイトフィールドを３２ビットワードアドレスに位置合わせさせることである。
シリアル番号フィールドは、値の書式でディスプレイのシリアル番号を指定するために、この実施形態においては４バイトを使用する。もしこのフィールドがクライアントによってサポートされていない場合、それは一般にゼロに設定されている。
１バイトの製造週フィールドは、ディスプレイの製造の週を定義するために１バイトを使用する。この値は、それがクライアントによってサポートされる場合は、典型的に、１から５３の範囲内にある。もしこのフィールドがクライアントによってサポートされていない場合は、それはゼロに設定されている。製造年フィールドは、ディスプレイの製造の年を定義する１バイトである。この値は、年１９９０からのオフセットである。１９９１から２２４５の範囲の年は、このフィールドによって表されることができる。例：年２００３は、１３の製造年値に対応する。もしこのフィールドがクライアントによってサポートされていない場合には、それはゼロに設定されている。
ＣＲＣフィールド（ここでは２バイト）は、パケット長を含むパケット内の全てのバイトの１６ビットＣＲＣを含む。
Ｇ．クライアント要求及びステータスパケットについて
逆方向リンク要求フィールド（３バイト）は、ホストに情報を送信するために次のサブフレームの逆方向リンクでクライアントが必要とするバイトの数を指定する。
ＣＲＣエラーカウントフィールド（１バイト）は、メディアフレームの開始以来どのくらいの数のＣＲＣエラーが発生したのかを示す。ゼロのサブフレームカウントと共にサブフレームヘッダパケットが送信される時、ＣＲＣカウントはリセットされている。もしＣＲＣエラーの実際の数が２５５を超えると、このときこの値は一般に２５５で飽和する。
機能変更フィールドは、クライアントの機能の変化を示すために１バイトを使用する。これは、ユーザが、周辺装置、例えばマイク、キーボード、又はディスプレイなど、を接続する場合、或いは、何らかの他の理由のために、発生し得るであろう。ビット「７：０」が０に等しい時、そうであれば、機能は、最後のクライアント機能パケットが送信されて以来、変化していない。然しながら、ビット［７：０］が１から２５５に等しい時は、機能は変更している。クライアント機能パケットは、新しいディスプレイ特性を決定するために調べられる。
クライアントビジーフラグフィールド(The Client Busy Flags field)は、クライアントが特定の機能を実行しておりそしてその機能に関連する別のパケットを未だ受理する準備が出来ていない、ことを示すために２バイトを使用する。論理１レベル又は値に設定されているビットは、クライアントによって特定の機能が現在実行されていることを、そしてクライアントにおける関連する機能がビジー(busy)であることを、示す。もしクライアントにおける関連する機能が準備できている場合、そのときビットは、論理ゼロに設定されている。クライアントは、クライアントにおいてサポートされていない全ての機能に対し、ビジーステータスを返さなければならない。
一実施形態においては、これらのバイトは、次の関係に従い解釈される：もしビット０が「１」であればそのときビットマップブロック転送機能はビジーであり、一方、もしビット１が「１」であればそのときビットマップ領域塗りつぶし機能はビジーであり、そして、もしビット２が「１」であればそのときビットマップパターン塗りつぶし機能はビジーである。現在のところは、ビット３から１５までは将来の使用のために予約されたままであり、そしてこれらのビットが将来割り当てられる場合に備えてビジーステータスを示すために、一般に論理１レベル又は状態に設定されている。
Ｈ．ビットブロック転送パケットについて
ウィンドウ左上座標Ｘ値フィールドとＹ値フィールドは、移動される予定のウィンドウの左上角の座標のＸ値とＹ値を指定するために、各々２バイトを使用する。ウィンドウ幅フィールドとウィンドウ高さフィールドは、移動される予定のウィンドウの幅と高さを指定するために、各々２バイトを使用する。ウィンドウＸ移動フィールドとＹ移動フィールドは、ウィンドウが水平と垂直に夫々移動される予定のピクセルの数を指定するために、各々２バイトを使用する。典型的には、これらの座標は、Ｘの正の値がウィンドウを右に移動させられるようにし、そして負の値が左への移動を生じさせるように、構成されている、一方、Ｙの正の値はウィンドウを下方に移動させられるようにし、負の値は上方移動を生じさせる。
Ｉ．ビットマップ領域塗りつぶしパケットについて
ウィンドウ左上座標Ｘ値フィールドとＹ値フィールドは、塗りつぶされるべき(to be filled)ウィンドウの左上角の座標のＸ値とＹ値を指定するために各々２バイトを使用する。ウィンドウ幅フィールドとウィンドウ高さフィールド（各２バイト）は、塗りつぶされるべきウィンドウの幅と高さを指定する。ビデオデータフォーマット記述子フィールド（２バイト）は、ピクセル領域塗りつぶし値のフォーマットを指定する。フォーマットは、ビデオストリームパケット内の同じフィールドと同じである。ピクセル領域塗りつぶし値フィールド（４バイト）は、上記に説明されたフィールドによって指定されたウィンドウの中に充填されるべき(to be filled)ピクセル値を含む。このピクセルのフォーマットは、ビデオデータフォーマット記述子フィールドに指定される。
Ｊ．ビットマップパターン塗りつぶしパケットについて
ウィンドウ左上座標Ｘ値フィールドとＹ値フィールドは、塗りつぶされるべきウィンドウの左上角の座標のＸ値とＹ値を指定するために各々２バイトを使用する。ウィンドウ幅フィールドと高さフィールド（各２バイト）は、塗りつぶされるべきウィンドウの幅と高さを指定する。パターン幅フィールドとパターン高さフィールド（各２バイト）は塗りつぶしパターンの幅と高さを夫々指定する。水平パターンオフセットフィールド（２バイト）は、指定された塗りつぶされるべきウィンドウの左端縁からのピクセルデータパターンの水平オフセットを指定する。指定されている値は、パターン幅フィールドの中の値未満としなければならない。垂直パターンオフセットフィールド（２バイト）は、指定された塗りつぶされるべきウィンドウの上端縁からのピクセルデータパターンの垂直オフセットを指定する。指定されている値は、パターン高さフィールドの中の値未満としなければならない。
２バイトのビデオデータフォーマット記述子フィールドは、ピクセル領域塗りつぶし値のフォーマットを指定する。図１１は、ビデオデータフォーマット記述子がどのようにして符号化されるのかを示す。フォーマットは、ビデオストリームパケットの中の同じフィールドと同じである。
パラメータＣＲＣフィールド（２バイト）は、パケット長からビデオフォーマット記述子までの全てのバイトのＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。パターンピクセルデータフィールドは、ビデオデータフォーマット記述子により指定されるフォーマットの塗りつぶしパターンを指定する未処理ビデオ情報を含む。データはバイトにパックされ、そして各行の第１のピクセルはバイト位置合わせされなければならない。塗りつぶしパターンデータは、一度に一行ずつ送信される。パターンピクセルデータＣＲＣフィールド（２バイト）は、パターンピクセルデータのみのＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパターンピクセルデータは依然として使用されることができるが、ＣＲＣエラーカウントはインクリメントされる。
Ｋ．通信リンクデータチャネルパケット
パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプまでの全てのバイトの１６ビットＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。
通信リンクデータフィールドは、通信チャネルからの未処理データを含む。このデータは、ディスプレイのコンピュータデバイスに単に渡される。
通信リンクデータＣＲＣフィールド（２バイト）は、通信リンクデータのみの１６ビットＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのとき通信リンクデータは依然として使用される或いは有効であるが、ＣＲＣエラーカウントはインクリメントされる。
Ｌ．順方向音声チャネルイネーブルパケットについて
音声チャネルイネーブルマスクフィールド（１バイト）は、どの音声チャネルがクライアントでイネーブルされなければならないのかを示す１グループのフラグを含む。１に設定されるビットは、対応するチャネルをイネーブルにし、そしてゼロに設定されるビットは、対応するチャネルをディスエーブルにする。ビット０から５までは、左前チャネル、右前チャネル、左後チャネル、右後チャネル、前中心チャネル、及びサブウーファーチャネルを夫々アドレス指定するチャネル０から５までを指定する。ビット６と７は、将来の使用のために予約されており、そして当面の間は一般にゼロに等しく設定されている。
Ｍ．逆方向音声サンプルレートパケットについて
音声サンプルレートフィールド（１バイト）は、デジタル音声サンプルレートを指定する。このフィールドの値は、異なるレートに割り当てられ、０、１、２、３、４、５、６、７、及び８の値は、夫々、８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０、及び４４，１００サンプル／秒（ＳＰＳ）を示すために使用され、９から２５４までの値は、所望されるように、代替のレートと共に使用するために予約されているので、それらは現在は「０」に設定されている。２５５の値は、逆方向リンク音声ストリームをディスエーブルにするために使用される。
サンプルフォーマットフィールド（１バイト）は、デジタル音声サンプルのフォーマットを指定する。ビット［１：０］が「０」に等しい時、デジタル音声サンプルは線形フォーマットにあり、それらが１に等しい時には、デジタル音声サンプルはμ法則フォーマットにあり、そしてそれらが２に等しい時、デジタル音声サンプルはＡ−法則フォーマットにある。ビット［７：２］は、所望されるように、音声フォーマットを指定する上での代替使用に予約されており、そして一般にゼロに等しく設定されている。
Ｎ．デジタルコンテンツ保護オーバヘッドパケットについて
コンテンツ保護タイプフィールド（１バイト）は、使用されるデジタルコンテンツ保護方法を指定する。「０」の値はデジタル伝送コンテンツ保護（ＤＴＣＰ）を示すが、一方１の値は高帯域幅デジタルコンテンツ保護システム（ＨＤＣＰ）を示す。２から２５５までの値の範囲は、現在指定されていないが、所望されるように代替の保護方式と共に使用するために予約されている。コンテンツ保護オーバヘッドメッセージフィールドは、ホストとクライアントとの間で送信されるコンテンツ保護メッセージを含む可変長のフィールドである。
Ｏ．透明色イネーブルパケットについて
透明色イネーブルフィールド（１バイト）は、いつ、透明色モードがイネーブルにされるのか或いはディスエーブルにされるのかを指定する。もしビット０が０に等しいならばそのとき透明色モードはディスエーブルにされ、もしそれが１に等しいならばそのとき透明色モードはイネーブルにされ、そして透明色は以下の２つのパラメータによって指定される。このバイトのビット１から７までは、将来の使用のために予約され、そして通常ゼロに等しく設定されている。
ビデオデータフォーマット記述子フィールド（２バイト）は、ピクセル領域塗りつぶし値のフォーマットを指定する。図１１は、ビデオデータフォーマット記述子がどのようにして符号化されるのかを示す。フォーマットは、一般にビデオストリームパケット内の同じフィールドと同じである。
ピクセル領域塗りつぶし値フィールドは、上記に指定されるウィンドウの中に充填されるべきピクセル値のために割り当てられる４バイトを使用する。このピクセルのフォーマットは、ビデオデータフォーマット記述子フィールドに指定されている。
Ｐ．往復遅延測定パケットについて
２バイトのパケット長フィールドは、パケット長フィールドを含まないパケット内のバイト総数を指定し、そして一実施形態においては、１５９の固定長を有するように選択されている。このパケットタイプを８２の値で識別する２バイトのパケットタイプフィールドは、往復遅延測定パケットとしてパケットを識別している。ｈＣｌｉｅｎｔ ＩＤフィールドは、前記のように、クライアントＩＤとして将来使用するために予約されており、そして一般にゼロに設定されている。
一実施形態では、パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプまでの全てのバイトの１６ビットＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。
ガード時間１フィールド（ここでは６４バイト）は、クライアントにおけるＭＤＤＩ＿Ｄａｔａラインドライバが、ホストにおけるラインドライバがディスエーブルにされる前に、イネーブルにするのを可能とするために使用される。クライアントはそのＭＤＤＩ＿Ｄａｔａラインドライバを、ガード時間１のビット０の間、イネーブルにし、そしてホストはそのラインドライバを、ガード時間１の最後のビットの前に完全にディスエーブルにされるように、ディスエーブルにする。ホストとクライアントは共に、それらがディスエーブルにされていない時、ガード時間１の間に論理ゼロレベルを駆動する。このフィールドの別の目的は、ホストのラインドライバをディスエーブルにすることの前にクライアントがＭＤＤＩ＿Ｓｔｂのみを使用してクロック又はクロック信号を回復することを開始するのを可能にする十分な時間の間、全てのＭＤＤＩ＿Ｄａｔａ信号が論理ゼロレベルにある、ということを保証することである。
測定期間フィールドは、順方向リンク上で使用されるデータレートの半分で０ｘｆｆの２バイト、及び０ｘ００の３０バイトでクライアントが応答するのを可能にするために使用される、６４バイトのウィンドウである。このデータレートは、１の逆方向リンクレート除数に対応する。クライアントは、それが測定期間の始まりであると知覚すると直ちにこの応答を返す。クライアントからのこの応答は、正確に、リンクの往復遅延にホストでの測定期間の第１のビットの開始後のクライアントにおける論理遅延をプラスした遅延で、ホストで受信される。
全ゼロ１フィールド（２バイト）は、ＭＤＤＩ＿Ｄａｔａがいつも駆動されているようにホスト及びクライアントにおけるＭＤＤＩ＿Ｄａｔａラインドライバが重複するのを可能とするために、ゼロを含んでいる。ホストは、全ゼロ１フィールドのビット０の間、ＭＤＤＩ＿Ｄａｔａラインドライバをイネーブルにし、そしてクライアントもまた、測定期間の最後でそれが行ったように、信号を論理ゼロレベルに駆動し続ける。
ガード時間２フィールド（６４バイト）の値は、往復遅延が測定期間中に測定されることができる最大量である時に、クライアントによって駆動される測定期間の重複を可能にする。クライアントはそのラインドライバを、ガード時間２のビット０の間、ディスエーブルにし、そしてホストはそのラインドライバを、ガード時間２の最後のビットの直後にイネーブルにする。ホストとクライアントの両方とも、それらがディスエーブルにされていない時、ガード時間２の間、論理ゼロレベルを駆動する。このフィールドの別の目的は、ホストのラインドライバをイネーブルにした後にＭＤＤＩ＿ＤａｔａとＭＤＤＩ＿Ｓｔｂの両方を使用してクライアントがクロック信号を回復することを開始するのを可能にする十分な時間の間、全てのＭＤＤＩ＿Ｄａｔａ信号が論理ゼロレベルにある、ということを保証することである。
Ｑ．順方向リンク歪み校正パケットについて
一実施形態においては、パラメータＣＲＣフィールド（２バイト）は、パケット長からパケットタイプまでの全てのバイトの１６ビットＣＲＣを含む。もしこのＣＲＣがチェックできない場合、そのときパケット全体が廃棄される。
全ゼロフィールドは、校正データシーケンスフィールドの開始時にＭＤＤＩ＿Ｓｔｂ上に遷移があるであろうことを確かなものにするために８バイトを使用する。一般に、これらのバイトは、ゼロに等しい８ビット符号なしの整数を使用する。それはまた、クライアントコアロジックが、ＭＤＤＩ＿０とＭＤＤＩ＿ＳｔｂのＸＯＲを使用することからＭＤＤＩ＿Ｓｔｂ又はＭＤＤＩ＿Ｓｔｂ信号を回復されたクロックとして単に使用することへクロック回復回路のモードを変更するために十分な時間を提供する。
校正データシーケンスフィールドは、ＭＤＤＩ＿Ｄａｔａ信号をデータ期間ごとに切り換え(toggle)させるデータシーケンスを含む。校正データシーケンスフィールドの長さは、順方向リンク上で使用されるインタフェースによって決定される。校正データシーケンスの処理中、ＭＤＤＩホストコントローラは、全てのＭＤＤＩ＿Ｄａｔａ信号をストローブ信号に等しく設定する。校正データシーケンスフィールドがクライアントによって受信されている間、クライアントクロック回復回路は、データクロックを回復するためにＭＤＤＩ＿Ｓｔｂ ＸＯＲ ＭＤＤＩ＿Ｄａｔａ０よりは寧ろＭＤＤＩ＿Ｓｔｂのみを使用するべきである。校正データシーケンスフィールドの始まりでのＭＤＤＩ＿Ｓｔｂ信号の正確な位相に応じて、校正データシーケンスは一般に、このパケットが送信されるときに使用されるインタフェースタイプに基づき、以下の１つとなるであろう:
１型−（６４バイトデータシーケンス）０ｘａａ、０ｘａａ・・・又は０ｘ５５、０ｘ５５・・・
２型−（１２８バイトデータシーケンス）０ｘｃｃ、０ｘｃｃ・・・又は０ｘ３３、０ｘ３３・・・
３型−（２５６バイトデータシーケンス）０ｘｆ０、０ｘｆ０・・・又は０ｘ０ｆ、０ｘ０ｆ・・・
４型−（５１２バイトデータシーケンス）０ｘｆｆ、０ｘ００、０ｘｆｆ、０ｘ００・・・又は０ｘ００、０ｘｆｆ、０ｘ００、０ｘｆｆ・・・
クライアントコアロジックが、ＭＤＤＩ＿Ｓｔｂ信号を回復されたクロックとして使用することからＭＤＤＩ＿０とＭＤＤＩ＿ＳｔｂのＸＯＲを使用することへクロック回復回路のモードをオリジナルの状態に変更するのに十分な時間を提供するために、全ゼロ２フィールドは、８バイトを使用する。一般に、これらのバイトは、ゼロに等しい８バイト符号無し整数を使用する。
１型インタフェースと２型インタフェースの両方の場合の可能なＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形の１例が、図６２Ａと図６２Ｂにおいて夫々示されている。
ＸＸ．結論
本発明の様々な実施形態が上記に説明されてきたが、それらはほんの１例として示されており、限定するものではない、ということが理解されるべきである。従って、本発明の幅及び範囲は、何れの上記説明された例示的な実施形態によっても限定されるべきではなく、添付の特許請求の範囲の請求項及びその均等に従ってのみ定義されるべきである。
図１Ａは、ポータブルコンピュータ又は他のデータ処理装置と共にマイクロディスプレイ装置又はプロジェクタを使用することを含む、本発明の実施形態が動作しうる基本的環境を示す。 図１Ｂは、無線トランシーバと共に使用されるマイクロディスプレイ装置又はプロジェクタ及び音声プレゼンテーションエレメントを使用することを含む、本発明の実施形態が動作しうる基本的環境を示す。 図２Ａは、ポータブルコンピュータにおいて使用される内蔵ディスプレイ又は音声プレゼンテーションの装置を使用することを含む、本発明の実施形態が動作しうる基本的環境を示す。 図２Ｂは、無線トランシーバにおいて使用される内蔵ディスプレイ又は音声プレゼンテーションのエレメントを使用することを含む、本発明が動作しうる可能性のある基本的環境を示す。 図３は、ホストとクライアントの相互接続を備えたモバイルデジタルデータインタフェースの全体的な概念を示す。 図４は、クライアント装置からホスト装置へのデータ転送を実現するために有用なパケットの構造を示す。 図５は、ＭＤＤＩリンクコントローラの使用と、１型インタフェース用物理データリンク導線上でホストとクライアントの間で受け渡される信号のタイプとを示す。 図６は、ＭＤＤＩリンクコントローラの使用と、２型インタフェース、３型インタフェース、及び４型インタフェースのための物理データリンク導線上でホストとクライアントとの間で受け渡される信号のタイプとを示す。 図７は、インタフェースプロトコルを実現するために使用されるフレーム及びサブフレームの構造を示す。 図８は、インタフェースプロトコルを実現するために使用されるパケットの一般構造を示す。 図９は、サブフレームヘッダパケットのフォーマットを示す。 図１０は、フィラーパケットのフォーマット及びコンテンツを示す。 図１１は、ビデオストリームパケットのフォーマットを示す。 図１２Ａは、図１１で使用されるビデオデータフォーマット記述子のフォーマット及びコンテンツを示す。 図１２Ｂは、図１１で使用されるビデオデータフォーマット記述子のフォーマット及びコンテンツを示す。 図１２Ｃは、図１１で使用されるビデオデータフォーマット記述子のフォーマット及びコンテンツを示す。 図１２Ｄは、図１１で使用されるビデオデータフォーマット記述子のフォーマット及びコンテンツを示す。 図１２Ｅは、図１１で使用されるビデオデータフォーマット記述子のフォーマット及びコンテンツを示す。 図１３は、データのパックフォーマットとアンパックフォーマットの使用を示す。 図１４は、音声ストリームパケットのフォーマットを示す。 図１５は、データのためのバイト位置合わせされたＰＣＭフォーマットとパックされたＰＣＭフォーマットの使用を示す。 図１６は、ユーザ定義のストリームパケットのフォーマットを示す。 図１７は、カラーマップパケットのフォーマットを示す。 図１８は、逆方向リンクカプセル化パケットのフォーマットを示す。 図１９は、クライアント機能パケットのフォーマットを示す。 図２０は、キーボードデータパケットのフォーマットを示す。 図２１は、ポインティングデバイスデータパケットのフォーマットを示す。 図２２は、リンクシャットダウンパケットのフォーマットを示す。 図２３は、クライアント要求及びステータスパケットのフォーマットを示す。 図２４は、ビットブロック転送パケットのフォーマットを示す。 図２５は、ビットマップ領域塗りつぶしパケットのフォーマットを示す。 図２６は、ビットマップパターン塗りつぶしパケットのフォーマットを示す。 図２７は、通信リンクデータチャネルパケットのフォーマットを示す。 図２８は、ディスプレイパワー状態パケットのフォーマットを示す。 図２９は、実行型ハンドオフパケットのフォーマットを示す。 図３０は、順方向音声チャネルイネーブルパケットのフォーマットを示す。 図３１は、逆方向音声サンプルレートパケットのフォーマットを示す。 図３２は、デジタルコンテンツ保護オーバヘッドパケットのフォーマットを示す。 図３３は、透明色イネーブルパケットのフォーマットを示す。 図３４は、往復遅延測定パケットのフォーマットを示す。 図３５は、往復遅延測定パケット期間のイベントのタイミングを示す。 図３６は、本発明を実現するために有用なＣＲＣジェネレータ及びチェッカのサンプルインプリメンテーションを示す。 図３７Ａは、データパケットを送信するときの図３６の装置のＣＲＣ信号のタイミングを示す。 図３７Ｂは、データパケットを受信するときの図３６の装置のＣＲＣ信号のタイミングを示す。 図３８は、競合のない典型的なサービス要求に対する処理ステップを示す。 図３９は、リンク起動を競合する、リンク再起動シーケンスが開始した後にアサートされた典型的なサービス要求、に対する処理ステップを示す。 図４０は、ＤＡＴＡ−ＳＴＢ符号化を使用してどのようにしてデータシーケンスを送信できるかを示す。 図４１は、ホストで入力データからＤＡＴＡ信号とＳＴＢ信号を生成し、そのあとにクライアントでデータを回復するために有用な回路を示す。 図４２は、一実施形態を実現するために有用なドライバと終端レジスタを示す。 図４３ａは、ホストからのサービスを保証するためにクライアントによってそしてこのようなサービスを提供するためにホストによって使用されるステップ及び信号レベルを示す。 図４３ｂは、ホストからのサービスを保証するためにクライアントによってそしてこのようなサービスを提供するためにホストによって使用されるステップ及び信号レベルを示す。 図４３ｃは、ホストからのサービスを保証するためにクライアントによってそしてこのようなサービスを提供するためにホストによって使用されるステップ及び信号レベルを示す。 図４４は、Ｄａｔａ０、他のデータライン（ＤａｔａＸ）、及びストローブライン（Ｓｔｂ）上での遷移間の相対的な間隔を示す。 図４５は、ホストがパケット転送後にホストドライバをディスエーブルにする時に起こり得る応答における遅延の存在を示す。 図４６は、パケットを転送するためにホストがホストドライバをイネーブルにする時に起こり得る応答における遅延の存在を示す。 図４７は、リーク電流分析を示す。 図４８は、ホスト及びクライアント出力イネーブル及びディスエーブル時間についてのスイッチング特性及び時間の相対的タイミング関係を示す。 図４９は、状態機械を使用して同期が実現されることができる信号処理ステップとコンディションのハイレベルダイアグラムを示す。 図５０は、ＭＤＤＩを使用するシステムにおける順方向経路及び逆方向経路上で信号処理のために遭遇される典型的な遅延量を示す。 図５１は、マージナル往復遅延測定を示す。 図５２Ａは、逆方向リンクデータレート変化を示す。 図５２Ｂは、高度逆方向データサンプリングの例を示す。 図５３は、逆方向レート除数対順方向リンクデータレートの値のグラフィック表現を示す。 図５４は、インタフェースの動作で講じられるステップを示す。 図５４Ｂは、インタフェースの動作で講じられるステップを示す。 図５５は、インタフェース装置処理パケットの概要を示す。 図５６は、順方向リンクパケットのフォーマットを示す。 図５７は、１型リンクインタフェースにおける伝搬遅延及び歪みについての典型的な値を示す。 図５８は、インタフェースを通した例示的な信号処理のための１型リンク上でのＤａｔａ、Ｓｔｂ、及びクロック回復タイミングを示す。 図５９は、２型、３型又は４型リンクインタフェースにおける伝搬遅延及び歪みについての典型的な値を示す。 図６０Ａは、理想的である、早い、及び遅れている、２つのデータ信号及びＭＤＤＩ＿Ｓｔｂの互いに関するタイミングの異なる可能性を示す。 図６０Ｂは、理想的である、早い、及び遅れている、２つのデータ信号及びＭＤＤＩ＿Ｓｔｂの互いに関するタイミングの異なる可能性を示す。 図６０Ｃは、理想的である、早い、及び遅れている、２つのデータ信号及びＭＤＤＩ＿Ｓｔｂの互いに関するタイミングの異なる可能性を示す。 図６１は、１型／２型インタフェースと共に使用されるインタフェースピン割り当て例示的コネクタを示す。 図６２Ａは、１型インタフェースのための可能なＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形を示す。 図６２Ｂは、２型インタフェースのための可能なＭＤＤＩ＿Ｄａｔａ波形とＭＤＤＩ＿Ｓｔｂ波形を示す。 図６３は、状態機械を使用して同期を実現できる別の信号処理ステップとコンディションのハイレベルダイアグラムである。 図６４は、一連のクロックサイクルと様々な逆方向リンクパケットビット及び除数値のタイミングとの間の例示的な相対的タイミングを示す。 図６５は、例示的なエラーコード転送処理を示す。 図６６は、エラーコード転送処理に有効な装置を示す。 図６７Ａは、コード過負荷のためのエラーコード転送処理を示す。 図６７Ｂは、コード受信のためのエラーコード転送処理を示す。 図６８Ａは、ホストによって起動されるウェイクアップのための処理ステップを示す。 図６８Ｂは、クライアントによって起動されるウェイクアップのための処理ステップを示す。 図６８Ｃは、ホストとクライアントによって起動される競合状態にあるウェイクアップのための処理ステップを示す。 図６９は、要求ＶＣＰ特徴パケットのフォーマットを示す。 図７０は、ＶＣＰ特徴応答パケットのフォーマットを示す。 図７１は、ＶＣＰ特徴応答パケットリストのフォーマットを示す。 図７２は、セットＶＣＰ特徴パケットのフォーマットを示す。 図７３は、要求有効パラメータパケットのフォーマットを示す。 図７４は、有効パラメータ応答パケットのフォーマットを示す。 図７５は、スケールドビデオストリーム機能パケットのフォーマットを示す。 図７６は、スケールドビデオストリームセットアップパケットのフォーマットを示す。 図７７は、スケールドビデオストリーム肯定応答パケットのフォーマットを示す。 図７８は、スケールドビデオストリームパケットのフォーマットを示す。 図７９は、特殊ステータス要求パケットのフォーマットを示す。 図８０は、有効ステータス応答リストパケットのフォーマットを示す。 図８１Ａは、パケット処理遅延パラメータパケットのフォーマットを示す。 図８１Ｂは、遅延パラメータリストアイテムのフォーマットを示す。 図８２は、パーソナルディスプレイ機能パケットのフォーマットを示す。 図８３は、像面湾曲の点リストにおけるエレメントを示す。 図８４Ａは、クライアントエラーレポートパケットのフォーマットを示す。 図８４Ｂは、エラーレポートリストアイテムのフォーマットを示す。 図８５は、クライアント識別パケットのフォーマットを示す。 図８６は、代替ディスプレイ機能パケットのフォーマットを示す。 図８７は、レジスタアクセスパケットのフォーマットを示す。 図８８Ａは、可視アーチファクトを減らす２つのディスプレイバッファの使用を示す。 図８８Ｂは、可視アーチファクトを減らす２つのディスプレイバッファの使用を示す。 図８８Ｃは、可視アーチファクトを減らす２つのディスプレイバッファの使用を示す。 図８９は、画像転送よりもより速いディスプレイリフレッシュ付きの２つのバッファを示す。 図９０は、画像転送よりもより遅いディスプレイリフレッシュ付きの２つのバッファを示す。 図９１は、画像転送よりも更により速いディスプレイリフレッシュ付きの２つのバッファを示す。 図９２は、画像転送よりもより速いディスプレイリフレッシュ付きの３つのバッファを示す。 図９３は、画像転送よりもより遅いディスプレイリフレッシュ付きの３つのバッファを示す。 図９４は、画像転送よりもより速いディスプレイリフレッシュ付きの１つのバッファを示す。 図９５は、デイジーチェーンとハブを介するホスト−クライアント接続を示す。 図９６は、ハブとデイジーチェーンの組み合わせを介して接続されるクライアント装置を示す。 図９７は、カラーマップを示す。

Claims (33)

  1. 通信経路上で、ホスト装置とクライアント装置との間において高レートでデジタルプレゼンテーションデータを転送するためのデジタルデータインタフェースであって、
    前記通信経路上で、ホストとクライアントとの間において事前に選択された１セットのデジタル制御データとデジタルプレゼンテーションデータを通信するための通信プロトコルを形成するために、共にリンクされる複数のパケット構造と、そして
    前記通信経路を通って前記クライアントに結合された前記ホスト装置の中に常駐し、前記通信プロトコルを形成するパケットを生成、送信、及び受信するように、そしてプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成されている、少なくとも１つのリンクコントローラと、
    を備える、デジタルデータインタフェース。
  2. 予め定められた数の異なる可変長を有する前記パケットを備えた予め定義された固定長を有し、前記ホストとクライアントとの間で通信される、メディアフレーム内で、共にグループ化される前記パケットを更に備える、請求項１に記載のインタフェース。
  3. 前記ホストからのパケットの転送の初めに位置づけられるサブフレームヘッダパケット(a Sub-frame Header Packet)を更に備える、請求項１に記載のインタフェース。
  4. 特定のクライエント関連のハードウェアを低電力状態に置くディスプレイパワー状態パケット(a Display Power State Packet)を更に備える、請求項１に記載のインタフェース。
  5. 前記リンクコントローラはホストリンクコントローラであって、前記通信経路を通って前記ホストに結合された前記クライアント装置の中に常駐し、前記通信プロトコルを形成するパケットを生成、送信、及び受信するように、そしてデジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成されている、少なくとも１つのクライアントリンクコントローラを更に備える、請求項１に記載のインタフェース。
  6. 各々が既定の期間にわたって異なる最大数のビットのデータを並列に転送することを可能にする複数の転送モードを更に備え、各モードは前記ホストリンクドライバとクライアントリンクドライバの間の交渉により選択可能であり、そして
    前記転送モードは、データの転送中に前記モード間で動的に調整可能である、
    請求項２に記載のインタフェース。
  7. 前記通信経路上でどちらの方向へもデータの転送を終了するための、前記ホストによる前記クライアントへの伝送に対するリンクシャットダウン型パケット(a Link Shutdown type packet)を更に備える、請求項１に記載のインタフェース。
  8. 前記クライアントが前記ホストをハイバネーション状態からウェイクアップするための手段を更に備える、請求項１に記載のインタフェース。
  9. ユーザへのプレゼンテーションのために通信経路上でホスト装置とクライアント装置との間において高レートでデジタルデータを転送する方法であって、
    複数の予め定義されたパケット構造の内の１つ又は複数を生成し、予め定義された通信プロトコルを形成するためにそれらを共にリンクすることと；
    前記通信プロトコルを使用して、前記通信経路上で、前記ホストと前記クライアントの装置間で、事前に選択された１セットのデジタル制御データとデジタルプレゼンテーションデータを通信することと；
    前記ホスト装置に常駐する少なくとも１つのホストリンクコントローラを、前記通信経路を通して前記クライアント装置に結合することと、なお、前記ホストリンクコントローラは、前記通信プロトコルを形成するパケットを生成し、送信し、及び受信するように、そして、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように、構成されている；そして
    前記リンクコントローラを使用して前記通信経路上でパケットの形でデータを転送することと；
    を備える、方法。
  10. 前記ホストとクライアントとの間の通信のためにメディアフレーム内に前記パケットを共にグループ化することを更に備え、前記メディアフレームは、予め定められた数の異なる可変長を有する前記パケットを備えた予め定義された固定長を有する、請求項９に記載の方法。
  11. サブフレームヘッダ型パケットを用いて前記ホストからのパケットの転送を開始することを更に備える、請求項９に記載の方法。
  12. 前記通信経路を通して前記ホスト装置に結合された、前記クライアント装置の中に常駐する少なくとも１つのクライアントリンクコントローラを通して、前記通信プロトコルを形成するパケットを生成し、送信し、そして受信することを更に備える、請求項９に記載の方法。
  13. ホストリンクドライバとクライアントリンクドライバとの間で各方向における複数の転送モードの内の１つの使用を交渉することと、なお、各々は既定の期間にわたって異なる最大ビット数のデータの並列転送を可能にする；そして
    データの転送中に前記転送モード間で動的に調整することと；
    を更に備える、請求項１２に記載の方法。
  14. 前記ホストによる前記クライアントへの伝送に対し、リンクシャットダウン型のパケットを使用し、前記通信経路上でどちらの方向へもデータの転送を終了することを更に備える、請求項９に記載の方法。
  15. 前記クライアントとの通信によりハイバネーション状態から前記ホストをウェイクアップすることを更に備える、請求項９に記載の方法。
  16. 特定のクライエントハードウェアを低電力状態に置くディスプレイパワー状態パケットを生成することを更に備える、請求項９に記載の方法。
  17. ユーザへのプレゼンテーションのために通信経路上でホスト装置とクライアント装置との間を高レートでデジタルデータを転送するための装置であって、
    複数の予め定義されたパケット構造の１つ又は複数を生成し、予め定義された通信プロトコルを形成するためにそれらを共にリンクするために、そして、前記通信プロトコルを使用して前記通信経路上で、前記ホスト装置と前記クライアント装置との間で事前に選択された１セットのデジタル制御データとデジタルプレゼンテーションデータを通信するために、前記ホスト装置内に配置される少なくとも１つのホストリンクコントローラと；
    前記クライアント装置内に配置され、前記通信経路を通して前記ホストリンクコントローラに結合される、少なくとも１つのクライアントコントローラと；そして
    前記通信プロトコルを形成するパケットを生成、送信、及び受信するように、そして、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように、構成されている各リンクコントローラと：
    を備える、装置。
  18. 前記ホストコントローラは状態機械を備える、請求項１７に記載の装置。
  19. 前記ホストコントローラは汎用信号プロセッサを備える、請求項１７に記載の装置。
  20. 前記ホストからのパケットの転送の開始時にサブフレームヘッダ型パケットを更に備える、請求項１７に記載の装置。
  21. 前記ホストコントローラは１つ又は複数の差動ラインドライバを備え、そして、前記クライアントレシーバは前記通信経路に結合される１つ又は複数の差動ラインレシーバを備える、請求項１７に記載の装置。
  22. 前記ホストリンクコントローラとクライアントリンクコントローラは、各方向における複数の転送モードの内の１つを使用するように構成されており、なお各々は既定の期間にわたって異なる最大ビット数のデータの並列転送を可能にし；そして、データの転送中に前記転送モード間で動的に調整することが可能である、請求項１７に記載の装置。
  23. 前記ホストコントローラは、前記通信経路上でどちらの方向へもデータの転送を終了するために、前記クライアント手段にリンクシャットダウン型パケットを送信するように構成されている、請求項１７に記載の装置。
  24. 前記ホストコントローラは、特定のディスプレイコントローラハードウェアを低電力状態に置くディスプレイパワー状態パケットを生成するように構成されている、請求項１７に記載の装置。
  25. ユーザへのプレゼンテーションのために、通信経路上で、ホスト装置とクライアント装置との間で高レートでデジタルデータを転送する電子システムにおいて使用するためのコンピュータプログラム製品であって、
    アプリケーションプログラムを前記コンピュータシステム上で実行させるために、媒体において具現化されるコンピュータ読み取り可能プログラムコード手段を有するコンピュータ使用可能な前記媒体を備え；
    前記コンピュータ読み取り可能プログラムコード手段は、
    コンピュータシステムに、複数の予め定義されたパケット構造の１つ又は複数を生成させ、そして、予め定義された通信プロトコルを形成するためにそれらを共にリンクさせるための、コンピュータ読み取り可能第１プログラムコード手段と；
    前記コンピュータシステムに、前記通信プロトコルを使用して前記通信経路上で、前記ホスト装置と前記クライアント装置との間で、事前に選択された１セットのデジタル制御データとデジタルプレゼンテーションデータを通信させるための、コンピュータ読み取り可能第２プログラムコード手段と；
    前記コンピュータシステムに、前記ホスト装置の中に配置される少なくとも１つのホストリンクコントローラを、前記クライアント装置の中に配置される少なくとも１つのクライアントコントローラに、前記通信経路を通して結合させるための、コンピュータ読み取り可能第３プログラムコード手段と、なお、前記リンクコントローラは、前記通信プロトコルを形成するパケットを生成、送信、及び受信するように、そして、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように、構成されている；そして
    前記コンピュータシステムに、前記リンクコントローラを使用して前記通信経路上でパケットの形でデータを転送させるための、コンピュータ読み取り可能第４プログラムコード手段と；
    を備える、
    コンピュータプログラム製品。
  26. 前記コンピュータシステムに、予め定義されたパケット構造を生成させ、そして、予め定義された通信プロトコルを形成するためにそれらを共にリンクさせるための、コンピュータ読み取り可能プログラムコード手段を備える、請求項２５に記載のコンピュータプログラム製品。
  27. ユーザへのプレゼンテーションのために、通信経路上で、ホスト装置とクライアント装置との間において、高レートでデジタルデータを転送するための装置であって、
    複数の予め定義されたパケット構造の１つ又は複数を生成し、予め定義された通信プロトコルを形成するためにそれらを共にリンクするための手段と；
    前記通信プロトコルを使用して前記通信経路上で前記ホスト装置と前記クライアント装置との間で、事前に選択された１セットのデジタル制御データ及びデジタルプレゼンテーションデータを通信するための手段と；
    前記ホストとクライアントの各々に１つ、そして各々は前記通信プロトコルを形成するパケットを生成、送信、及び受信するように、そして、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成するように構成されている、少なくとも２つのリンクコントローラを、前記通信経路を通して互いに結合するための手段と；そして
    前記リンクコントローラを使用して前記通信経路上で、パケットの形でデータを転送するための手段と；
    を備える、装置。
  28. サブフレームヘッダ型パケットを用いて、前記ホストからパケットの転送を開始するための手段を更に備える、請求項２７に記載の装置。
  29. 特定のハードウェアを低電力状態に置くように構成されたディスプレイパワー状態パケットを生成することを備える手段を更に備える、請求項２７に記載の装置。
  30. 前記クライアントが前記インタフェースを通してどのタイプのデータとデータレートに対応できるのかを決定するように、ホストリンクコントローラによってクライアントからディスプレイ機能情報を要求するための手段を更に備える、請求項２７に記載の装置。
  31. 通信経路上でホスト装置とクライアント装置との間を高レートでデジタルデータを転送する電子システムにおいて使用するためのプロセッサであって、複数の予め定義されたパケット構造の１つ又は複数を生成しそして予め定義された通信プロトコルを形成するためにそれらを共にリンクするように、デジタルプレゼンテーションデータを１つ又は複数のタイプのデータパケットに形成し、前記通信プロトコルを使用して前記通信経路上で前記ホスト装置と前記クライアント装置との間で事前に選択された１セットのデジタル制御データとデジタルプレゼンテーションデータを通信し、そして前記通信経路上でパケットの形でデータを転送するように、構成されたプロセッサ。
  32. 通信経路上でホスト装置とクライアント装置との間を高レートでデジタルデータを転送する電子システムにおいて同期を取る際に使用するための状態機械であって、少なくとも１つの非同期フレーム状態同期状態(Async Frames State synchronization state)と、少なくとも２つの同期獲得状態同期状態(Acquiring Sync States synchronization states)と、そして、少なくとも３つの同期中状態同期状態(In-Sync States synchronization states)と、を有するように構成された状態機械。
  33. 通信経路上でホスト装置とクライアント装置との間を高レートでデジタルデータを転送する電子システムにおいて同期を取る際に使用するための状態機械であって、少なくとも１つの同期獲得状態同期状態と、少なくとも２つの同期中状態同期状態と、を有するように構成された状態機械。
JP2007503036A 2004-03-10 2005-03-10 高データレートインタフェース装置及び方法 Pending JP2007528681A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US55217604P 2004-03-10 2004-03-10
US55430904P 2004-03-17 2004-03-17
PCT/US2005/008073 WO2005088939A1 (en) 2004-03-10 2005-03-10 High data rate interface apparatus and method

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2010166196A Division JP2011023009A (ja) 2004-03-10 2010-07-23 高データレートインタフェース装置及び方法

Publications (2)

Publication Number Publication Date
JP2007528681A true JP2007528681A (ja) 2007-10-11
JP2007528681A5 JP2007528681A5 (ja) 2008-05-29

Family

ID=34962140

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2007503036A Pending JP2007528681A (ja) 2004-03-10 2005-03-10 高データレートインタフェース装置及び方法
JP2010166196A Pending JP2011023009A (ja) 2004-03-10 2010-07-23 高データレートインタフェース装置及び方法
JP2013111024A Pending JP2013258691A (ja) 2004-03-10 2013-05-27 高データレートインタフェース装置及び方法

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2010166196A Pending JP2011023009A (ja) 2004-03-10 2010-07-23 高データレートインタフェース装置及び方法
JP2013111024A Pending JP2013258691A (ja) 2004-03-10 2013-05-27 高データレートインタフェース装置及び方法

Country Status (12)

Country Link
US (3) US8669988B2 (ja)
EP (5) EP2375675B1 (ja)
JP (3) JP2007528681A (ja)
KR (1) KR100919761B1 (ja)
CN (1) CN101827103B (ja)
AU (1) AU2005222371C1 (ja)
BR (1) BRPI0508582A (ja)
CA (3) CA2775784A1 (ja)
IL (1) IL177985A0 (ja)
MX (1) MXPA06010312A (ja)
RU (1) RU2337497C2 (ja)
WO (1) WO2005088939A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010533388A (ja) * 2008-05-06 2010-10-21 クゥアルコム・インコーポレイテッド モバイル・ディスプレイ・ディジタル・インターフェース用パケット構造
US8356331B2 (en) 2007-05-08 2013-01-15 Qualcomm Incorporated Packet structure for a mobile display digital interface
WO2022009574A1 (ja) * 2020-07-09 2022-01-13 ソニーセミコンダクタソリューションズ株式会社 送信装置、通信システム、及び情報送信方法

Families Citing this family (98)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760772B2 (en) 2000-12-15 2004-07-06 Qualcomm, Inc. Generating and implementing a communication protocol and interface for high data rate signal transfer
US8812706B1 (en) 2001-09-06 2014-08-19 Qualcomm Incorporated Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system
US7136304B2 (en) 2002-10-29 2006-11-14 Saifun Semiconductor Ltd Method, system and circuit for programming a non-volatile memory array
US7178004B2 (en) 2003-01-31 2007-02-13 Yan Polansky Memory array programming circuit and a method for using the circuit
KR101168839B1 (ko) 2003-06-02 2012-07-26 퀄컴 인코포레이티드 고속 데이터 레이트를 위한 신호 프로토콜 및 인터페이스의 생성 및 구현
KR101178080B1 (ko) 2003-08-13 2012-08-30 퀄컴 인코포레이티드 더 높은 데이터 레이트를 위한 신호 인터페이스
KR100951158B1 (ko) 2003-09-10 2010-04-06 콸콤 인코포레이티드 고속 데이터 인터페이스
US8694652B2 (en) 2003-10-15 2014-04-08 Qualcomm Incorporated Method, system and computer program for adding a field to a client capability packet sent from a client to a host
CN1902880A (zh) 2003-10-29 2007-01-24 高通股份有限公司 高数据速率接口
CN101729205A (zh) 2003-11-12 2010-06-09 高通股份有限公司 具有改进链路控制的高数据速率接口
BRPI0416895A (pt) 2003-11-25 2007-03-06 Qualcomm Inc interface de alta taxa de dados com sincronização de link melhorada
EP2247072B1 (en) 2003-12-08 2013-09-25 QUALCOMM Incorporated High data rate interface with improved link synchronization
US7599665B2 (en) * 2003-12-19 2009-10-06 Nokia Corporation Selection of radio resources in a wireless communication device
WO2005088939A1 (en) 2004-03-10 2005-09-22 Qualcomm Incorporated High data rate interface apparatus and method
JP4519903B2 (ja) 2004-03-17 2010-08-04 クゥアルコム・インコーポレイテッド 高速データレートインタフェース装置及び方法
KR101019935B1 (ko) 2004-03-24 2011-03-09 퀄컴 인코포레이티드 고 데이터 레이트 인터페이스 장치 및 방법
EP1978692B1 (en) 2004-06-04 2011-07-27 QUALCOMM Incorporated High data rate interface apparatus and method
US8650304B2 (en) 2004-06-04 2014-02-11 Qualcomm Incorporated Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
US7702369B1 (en) * 2004-06-25 2010-04-20 Cypress Semiconductor Corporation Method of increasing battery life in a wireless device
US7638850B2 (en) 2004-10-14 2009-12-29 Saifun Semiconductors Ltd. Non-volatile memory structure and method of fabrication
US8667363B2 (en) 2004-11-24 2014-03-04 Qualcomm Incorporated Systems and methods for implementing cyclic redundancy checks
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
US8699330B2 (en) 2004-11-24 2014-04-15 Qualcomm Incorporated Systems and methods for digital data transmission rate control
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US8539119B2 (en) 2004-11-24 2013-09-17 Qualcomm Incorporated Methods and apparatus for exchanging messages having a digital data interface device message format
US8723705B2 (en) 2004-11-24 2014-05-13 Qualcomm Incorporated Low output skew double data rate serial encoder
US20060140265A1 (en) * 2004-12-29 2006-06-29 Adimos Inc. System circuit and method for transmitting media related data
EP1746645A3 (en) 2005-07-18 2009-01-21 Saifun Semiconductors Ltd. Memory array with sub-minimum feature size word line spacing and method of fabrication
KR100685664B1 (ko) * 2005-08-12 2007-02-26 삼성전자주식회사 호스트 및 클라이언트로 구성된 데이터 통신 시스템 및데이터 통신 시스템의 작동 방법
US8730069B2 (en) 2005-11-23 2014-05-20 Qualcomm Incorporated Double data rate serial encoder
US8692839B2 (en) 2005-11-23 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US7808818B2 (en) 2006-01-12 2010-10-05 Saifun Semiconductors Ltd. Secondary injection for NROM
US7692961B2 (en) 2006-02-21 2010-04-06 Saifun Semiconductors Ltd. Method, circuit and device for disturb-control of programming nonvolatile memory cells by hot-hole injection (HHI) and by channel hot-electron (CHE) injection
EP1992118B1 (fr) 2006-03-07 2011-09-14 Thomson Licensing Dispositif de communication et base pour un affichage evolue
US7831854B2 (en) * 2006-03-21 2010-11-09 Mediatek, Inc. Embedded system for compensating setup time violation and method thereof
JP5170972B2 (ja) * 2006-03-28 2013-03-27 株式会社東芝 無線通信装置及び無線通信システム
US8032672B2 (en) 2006-04-14 2011-10-04 Apple Inc. Increased speed of processing of audio samples received over a serial communications link by use of channel map and steering table
KR100735566B1 (ko) * 2006-04-17 2007-07-04 삼성전자주식회사 이동 통신 단말기를 포인터로 이용하는 시스템 및 그 방법
US7701779B2 (en) 2006-04-27 2010-04-20 Sajfun Semiconductors Ltd. Method for programming a reference cell
TW200742988A (en) * 2006-05-05 2007-11-16 Inventec Appliances Corp Interface transmission structure between modules and its method
EP2030437B1 (en) * 2006-06-07 2018-09-05 ATI Technologies ULC Display information feedback
WO2008076700A2 (en) * 2006-12-13 2008-06-26 Rambus Inc. Interface with variable data rate
CN100544447C (zh) * 2007-07-11 2009-09-23 中兴通讯股份有限公司 一种移动多媒体广播业务数据流的传输方法
TWI390699B (zh) * 2008-01-31 2013-03-21 Realtek Semiconductor Corp 具有靜電保護功能之網路通訊裝置
US8497905B2 (en) 2008-04-11 2013-07-30 nearmap australia pty ltd. Systems and methods of capturing large area images in detail including cascaded cameras and/or calibration features
US8675068B2 (en) 2008-04-11 2014-03-18 Nearmap Australia Pty Ltd Systems and methods of capturing large area images in detail including cascaded cameras and/or calibration features
US8457160B2 (en) * 2009-05-27 2013-06-04 Agilent Technologies, Inc. System and method for packetizing image data for serial transmission
US8687648B2 (en) * 2009-07-17 2014-04-01 Qualcomm Incorporated Wireless transmission of data using an available channel of a spectrum
GB2469345B (en) * 2009-07-24 2011-05-04 Wolfson Microelectronics Plc Audio circuit
US10218467B2 (en) 2009-12-23 2019-02-26 Pismo Labs Technology Limited Methods and systems for managing error correction mode
US9787501B2 (en) * 2009-12-23 2017-10-10 Pismo Labs Technology Limited Methods and systems for transmitting packets through aggregated end-to-end connection
IT1399417B1 (it) * 2010-04-12 2013-04-16 Sisvel Technology Srl Metodo per la generazione e ricostruzione di un flusso video stereoscopico compatibile e relativi dispositivi di codifica e decodifica.
US8681839B2 (en) 2010-10-27 2014-03-25 International Business Machines Corporation Calibration of multiple parallel data communications lines for high skew conditions
US8767531B2 (en) 2010-10-27 2014-07-01 International Business Machines Corporation Dynamic fault detection and repair in a data communications mechanism
US20120106539A1 (en) * 2010-10-27 2012-05-03 International Business Machines Corporation Coordinating Communications Interface Activities in Data Communicating Devices Using Redundant Lines
EP2661879B1 (en) 2011-01-03 2019-07-10 HFI Innovation Inc. Method of filter-unit based in-loop filtering
CN102073469A (zh) * 2011-01-19 2011-05-25 广东威创视讯科技股份有限公司 一种基于多桌面系统的图片显示方法
JP5770925B2 (ja) * 2011-04-06 2015-08-26 ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング 直列バスシステム内でデータ伝送容量を上げるための方法及び装置
US9880956B2 (en) 2011-04-06 2018-01-30 Robert Bosch Gmbh Method and apparatus for adapting the data transmission security in a serial bus system
WO2012146631A1 (de) * 2011-04-26 2012-11-01 Robert Bosch Gmbh Verfahren und vorrichtung zur an speichergrössen angepassten seriellen datenübertragung
US8843825B1 (en) * 2011-07-29 2014-09-23 Photo Mambo Inc. Media sharing and display system with persistent display
US8452323B2 (en) * 2011-09-22 2013-05-28 Qualcomm Incorporated Method and system for selecting a thermally optimal uplink for a portable computing device
US8898504B2 (en) 2011-12-14 2014-11-25 International Business Machines Corporation Parallel data communications mechanism having reduced power continuously calibrated lines
US9355585B2 (en) * 2012-04-03 2016-05-31 Apple Inc. Electronic devices with adaptive frame rate displays
US9063595B2 (en) * 2012-06-08 2015-06-23 Apple Inc. Devices and methods for reducing power usage of a touch-sensitive display
US9411750B2 (en) 2012-07-30 2016-08-09 International Business Machines Corporation Efficient calibration of a low power parallel data communications channel
RU2015111194A (ru) * 2012-08-28 2016-10-20 Конинклейке Филипс Н.В. Устройство пересылки звука и соответствующий способ
JP6213817B2 (ja) * 2012-09-03 2017-10-18 パナソニックＩｐマネジメント株式会社 画像送信が可能な電子機器
US9092327B2 (en) 2012-12-10 2015-07-28 Qualcomm Incorporated System and method for allocating memory to dissimilar memory devices using quality of service
JP6396342B2 (ja) * 2013-03-08 2018-09-26 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． オーディオ−ビデオ用のワイヤレスドッキングシステム
US9430239B2 (en) * 2013-03-12 2016-08-30 Qualcomm Incorporated Configurable multicore network processor
CN104956641B (zh) 2013-03-19 2018-11-13 惠普发展公司，有限责任合伙企业 互连组件
KR102097452B1 (ko) * 2013-03-28 2020-04-07 삼성전자주식회사 프로젝터를 포함하는 전자 장치 및 그 제어 방법
US9419879B2 (en) * 2013-06-20 2016-08-16 International Business Machines Corporation Selectively refreshing address registration information
US9374004B2 (en) * 2013-06-28 2016-06-21 Intel Corporation I/O driver transmit swing control
US9601085B2 (en) 2013-09-20 2017-03-21 Synaptics Incorporated Device and method for synchronizing display and touch controller with host polling
US9319980B1 (en) 2013-10-30 2016-04-19 Google Inc. Efficient digital image distribution
KR102209068B1 (ko) 2014-04-02 2021-01-28 삼성전자주식회사 마스터 단말과 슬레이브 단말을 재연결하는 방법
US9778894B2 (en) * 2014-06-30 2017-10-03 Kabushiki Kaisha Toshiba System and method for outputting extended display identification data to another electronic device to achieve power savings
EP3310042B1 (en) * 2015-06-12 2021-12-15 Sony Interactive Entertainment Inc. Control device, control method, and program
GB2557384B (en) 2015-08-25 2019-08-28 Ultrasoc Technologies Ltd Packet data protocol
US10623454B2 (en) * 2015-10-13 2020-04-14 Dell Products L.P. System and method for multimedia redirection for cloud desktop conferencing
JP6626573B2 (ja) * 2015-11-02 2019-12-25 ドルビー ラボラトリーズ ライセンシング コーポレイション ハイダイナミックレンジ映像の、ｃｒｃコードを含むレイヤ表現および配信
US9474034B1 (en) 2015-11-30 2016-10-18 International Business Machines Corporation Power reduction in a parallel data communications interface using clock resynchronization
MX2019003659A (es) * 2016-09-30 2019-08-05 Ericsson Telefon Ab L M Agrupamiento de recursos de informacion de estado de canal (csi) aperiodica y de señal de referencia (rs) de csi.
CN110169007B (zh) * 2017-01-18 2022-06-07 索尼互动娱乐股份有限公司 通信装置、生成数据大小控制方法和程序
US11671301B2 (en) * 2017-03-22 2023-06-06 Interdigital Patent Holdings, Inc. Methods, apparatus, systems, architectures and interfaces for channel state information reference signal for next generation wireless communication systems
US10860449B2 (en) * 2017-03-31 2020-12-08 Intel Corporation Adjustable retimer buffer
KR102384773B1 (ko) 2017-10-12 2022-04-11 삼성전자주식회사 스토리지 장치, 컴퓨팅 시스템, 그리고 그것의 디버깅 방법
JP7322366B2 (ja) * 2018-09-11 2023-08-08 富士フイルムビジネスイノベーション株式会社 画像受信装置、画像送受信システム及び画像受信プログラム
US11127214B2 (en) * 2018-09-17 2021-09-21 Qualcomm Incorporated Cross layer traffic optimization for split XR
US11704257B1 (en) 2022-04-15 2023-07-18 Graco Minnesota Inc. System provisioning using virtual peripherals
US11546187B2 (en) 2018-12-17 2023-01-03 Graco Minnesota Inc. Large packet daisy chain serial bus
US10931972B2 (en) * 2019-01-24 2021-02-23 Dell Products, L.P. Forward channel contextual error concealment and sync for virtual, augmented, or mixed reality (XR) content in connectivity-constrained environments
US11430141B2 (en) 2019-11-04 2022-08-30 Facebook Technologies, Llc Artificial reality system using a multisurface display protocol to communicate surface data
US11145107B2 (en) 2019-11-04 2021-10-12 Facebook Technologies, Llc Artificial reality system using superframes to communicate surface data
CN111294622B (zh) * 2020-02-13 2022-01-25 腾讯科技（深圳）有限公司 一种互动方法和相关装置
US11320885B2 (en) 2020-05-26 2022-05-03 Dell Products L.P. Wide range power mechanism for over-speed memory design

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002049314A2 (en) * 2000-12-15 2002-06-20 Qualcomm Incorporated Generating and implementing a communication protocol and interface for high data rate signal transfer
JP2003111135A (ja) * 2001-10-02 2003-04-11 Nec Corp 輻輳制御システム

Family Cites Families (481)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7274652B1 (en) 2000-06-02 2007-09-25 Conexant, Inc. Dual packet configuration for wireless communications
US3594304A (en) 1970-04-13 1971-07-20 Sun Oil Co Thermal liquefaction of coal
US4042783A (en) 1976-08-11 1977-08-16 International Business Machines Corporation Method and apparatus for byte and frame synchronization on a loop system coupling a CPU channel to bulk storage devices
US4393444A (en) 1980-11-06 1983-07-12 Rca Corporation Memory addressing circuit for converting sequential input data to interleaved output data sequence using multiple memories
US4363123A (en) 1980-12-01 1982-12-07 Northern Telecom Limited Method of and apparatus for monitoring digital transmission systems in which line transmission errors are detected
JPS57136833A (en) * 1981-02-17 1982-08-24 Sony Corp Time-division multiplex data transmitting method
DE3475202D1 (en) * 1984-03-15 1988-12-22 Hoxan Kk Apparatus for producing polyacetylene film
US4660096A (en) 1984-12-11 1987-04-21 Rca Corporation Dividing high-resolution-camera video signal response into sub-image blocks individually raster scanned
DE3531809A1 (de) * 1985-09-06 1987-03-26 Kraftwerk Union Ag Katalysatormaterial zur reduktion von stickoxiden
US4769761A (en) 1986-10-09 1988-09-06 International Business Machines Corporation Apparatus and method for isolating and predicting errors in a local area network
JPS63226762A (ja) 1987-03-16 1988-09-21 Hitachi Ltd デ−タ処理方式
US4764805A (en) 1987-06-02 1988-08-16 Eastman Kodak Company Image transmission system with line averaging preview mode using two-pass block-edge interpolation
US4821296A (en) * 1987-08-26 1989-04-11 Bell Communications Research, Inc. Digital phase aligner with outrigger sampling
US5227783A (en) 1987-10-13 1993-07-13 The Regents Of New Mexico State University Telemetry apparatus and method with digital to analog converter internally integrated within C.P.U.
JPH0727571B2 (ja) 1987-10-26 1995-03-29 テクトロニックス・インコーポレイテッド ラスタ走査表示装置及び図形データ転送方法
US5155590A (en) 1990-03-20 1992-10-13 Scientific-Atlanta, Inc. System for data channel level control
US4891805A (en) * 1988-06-13 1990-01-02 Racal Data Communications Inc. Multiplexer with dynamic bandwidth allocation
US5167035A (en) 1988-09-08 1992-11-24 Digital Equipment Corporation Transferring messages between nodes in a network
US5136717A (en) 1988-11-23 1992-08-04 Flavors Technology Inc. Realtime systolic, multiple-instruction, single-data parallel computer system
US5079693A (en) 1989-02-28 1992-01-07 Integrated Device Technology, Inc. Bidirectional FIFO buffer having reread and rewrite means
US6014705A (en) * 1991-10-01 2000-01-11 Intermec Ip Corp. Modular portable data processing terminal having a higher layer and lower layer partitioned communication protocol stack for use in a radio frequency communications network
US5224213A (en) 1989-09-05 1993-06-29 International Business Machines Corporation Ping-pong data buffer for transferring data from one data bus to another data bus
US5495482A (en) 1989-09-29 1996-02-27 Motorola Inc. Packet transmission system and method utilizing both a data bus and dedicated control lines
US5543939A (en) 1989-12-28 1996-08-06 Massachusetts Institute Of Technology Video telephone systems
US5138616A (en) 1990-03-19 1992-08-11 The United States Of America As Represented By The Secretary Of The Army Continuous on-line link error rate detector utilizing the frame bit error rate
JP2584526B2 (ja) 1990-04-24 1997-02-26 大日本スクリーン製造株式会社 顕微鏡用対物レンズ
US5111455A (en) 1990-08-24 1992-05-05 Avantek, Inc. Interleaved time-division multiplexor with phase-compensated frequency doublers
US5131012A (en) 1990-09-18 1992-07-14 At&T Bell Laboratories Synchronization for cylic redundancy check based, broadband communications network
GB2249460B (en) 1990-09-19 1994-06-29 Intel Corp Network providing common access to dissimilar hardware interfaces
JP3007926B2 (ja) 1990-11-15 2000-02-14 オムロン株式会社 データキャリア及び識別システム
GB2250668B (en) 1990-11-21 1994-07-20 Apple Computer Tear-free updates of computer graphical output displays
IL100213A (en) 1990-12-07 1995-03-30 Qualcomm Inc Mikrata Kedma phone system and its antenna distribution system
US5359595A (en) 1991-01-09 1994-10-25 Rockwell International Corporation Skywave adaptable network transceiver apparatus and method using a stable probe and traffic protocol
US5345542A (en) 1991-06-27 1994-09-06 At&T Bell Laboratories Proportional replication mapping system
US5231636A (en) 1991-09-13 1993-07-27 National Semiconductor Corporation Asynchronous glitchless digital MUX
DE69233608T2 (de) * 1991-10-01 2007-03-01 Broadcom Corp., Irvine Lokales Funkfrequenznetzwerk
US5396636A (en) 1991-10-21 1995-03-07 International Business Machines Corporation Remote power control via data link
US5751445A (en) 1991-11-11 1998-05-12 Canon Kk Image transmission system and terminal device
CA2064541C (en) 1992-03-31 1998-09-15 Thomas A. Gray Cycling error count for link maintenance
US5331642A (en) 1992-09-01 1994-07-19 International Business Machines Corporation Management of FDDI physical link errors
JP3305769B2 (ja) 1992-09-18 2002-07-24 株式会社東芝 通信装置
JPH06124147A (ja) 1992-10-13 1994-05-06 Sanyo Electric Co Ltd 情報処理装置
GB9222282D0 (en) * 1992-10-22 1992-12-09 Hewlett Packard Co Monitoring network status
US5745523A (en) 1992-10-27 1998-04-28 Ericsson Inc. Multi-mode signal processing
US5513185A (en) * 1992-11-23 1996-04-30 At&T Corp. Method and apparatus for transmission link error rate monitoring
US5867501A (en) * 1992-12-17 1999-02-02 Tandem Computers Incorporated Encoding for communicating data and commands
US5619650A (en) * 1992-12-31 1997-04-08 International Business Machines Corporation Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message
GB9304638D0 (en) * 1993-03-06 1993-04-21 Ncr Int Inc Wireless data communication system having power saving function
JPH06332664A (ja) 1993-03-23 1994-12-02 Toshiba Corp 表示制御システム
US5418452A (en) 1993-03-25 1995-05-23 Fujitsu Limited Apparatus for testing integrated circuits using time division multiplexing
WO1994024200A1 (en) 1993-04-16 1994-10-27 Akzo Nobel N.V. Liquid stabilizer comprising metal soap and solubilized metal perchlorate
JP3197679B2 (ja) 1993-04-30 2001-08-13 富士写真フイルム株式会社 写真撮影システムおよび方法
US5420858A (en) 1993-05-05 1995-05-30 Synoptics Communications, Inc. Method and apparatus for communications from a non-ATM communication medium to an ATM communication medium
US5519830A (en) 1993-06-10 1996-05-21 Adc Telecommunications, Inc. Point-to-multipoint performance monitoring and failure isolation system
JP2768621B2 (ja) 1993-06-25 1998-06-25 沖電気工業株式会社 分散送信される畳み込み符号の復号装置
US5477534A (en) 1993-07-30 1995-12-19 Kyocera Corporation Acoustic echo canceller
US5430486A (en) 1993-08-17 1995-07-04 Rgb Technology High resolution video image transmission and storage
US5426694A (en) 1993-10-08 1995-06-20 Excel, Inc. Telecommunication switch having programmable network protocols and communications services
US5490247A (en) 1993-11-24 1996-02-06 Intel Corporation Video subsystem for computer-based conferencing system
US5510832A (en) * 1993-12-01 1996-04-23 Medi-Vision Technologies, Inc. Synthesized stereoscopic imaging system and method
US5583562A (en) * 1993-12-03 1996-12-10 Scientific-Atlanta, Inc. System and method for transmitting a plurality of digital services including imaging services
US5565957A (en) 1993-12-27 1996-10-15 Nikon Corporation Camera
US5724536A (en) 1994-01-04 1998-03-03 Intel Corporation Method and apparatus for blocking execution of and storing load operations during their execution
US5844606A (en) 1994-03-03 1998-12-01 Fuji Photo Film Co., Ltd. Videocamera having a multiconnector connectable to a variety of accessories
JP2790034B2 (ja) 1994-03-28 1998-08-27 日本電気株式会社 非運用系メモリ更新方式
US5483185A (en) * 1994-06-09 1996-01-09 Intel Corporation Method and apparatus for dynamically switching between asynchronous signals without generating glitches
JP3329076B2 (ja) 1994-06-27 2002-09-30 ソニー株式会社 ディジタル信号伝送方法、ディジタル信号伝送装置、ディジタル信号受信方法及びディジタル信号受信装置
US5560022A (en) 1994-07-19 1996-09-24 Intel Corporation Power management coordinator system and interface
US5748891A (en) 1994-07-22 1998-05-05 Aether Wire & Location Spread spectrum localizers
CN1124039C (zh) 1994-07-25 2003-10-08 西门子公司 可视电话通信建立连接和控制的方法
US5664948A (en) 1994-07-29 1997-09-09 Seiko Communications Holding N.V. Delivery of data including preloaded advertising data
US5733131A (en) 1994-07-29 1998-03-31 Seiko Communications Holding N.V. Education and entertainment device with dynamic configuration and operation
JP3592376B2 (ja) 1994-08-10 2004-11-24 株式会社アドバンテスト 時間間隔測定装置
EP0735490A4 (en) 1994-09-27 1998-01-21 Sega Enterprises Kk DATA TRANSFER DEVICE AND VIDEO GAME WITH THIS DEVICE
GB2296123B (en) * 1994-12-13 1998-08-12 Ibm Midi playback system
US5495469A (en) 1994-12-16 1996-02-27 Chrysler Corporation Communications network, state machine therefor
US5559459A (en) 1994-12-29 1996-09-24 Stratus Computer, Inc. Clock signal generation arrangement including digital noise reduction circuit for reducing noise in a digital clocking signal
FR2729528A1 (fr) 1995-01-13 1996-07-19 Suisse Electronique Microtech Circuit de multiplexage
GB2298109B (en) 1995-02-14 1999-09-01 Nokia Mobile Phones Ltd Data interface
US5530704A (en) 1995-02-16 1996-06-25 Motorola, Inc. Method and apparatus for synchronizing radio ports in a commnuication system
US5646947A (en) 1995-03-27 1997-07-08 Westinghouse Electric Corporation Mobile telephone single channel per carrier superframe lock subsystem
US6117681A (en) 1995-03-29 2000-09-12 Bavarian Nordic Research Inst. A/S Pseudotyped retroviral particles
KR100411372B1 (ko) 1995-04-11 2004-05-06 마츠시타 덴끼 산교 가부시키가이샤 비디오정보조정장치,비디오정보송신장치및비디오정보수신장치
US5521907A (en) 1995-04-25 1996-05-28 Visual Networks, Inc. Method and apparatus for non-intrusive measurement of round trip delay in communications networks
US5963564A (en) 1995-06-13 1999-10-05 Telefonaktiebolaget Lm Ericsson Synchronizing the transmission of data via a two-way link
SE506540C2 (sv) 1995-06-13 1998-01-12 Ericsson Telefon Ab L M Synkronisering av överföring av data via en dubbelriktad länk
JPH0923243A (ja) 1995-07-10 1997-01-21 Hitachi Ltd 電子紙面情報配信システム
US6055247A (en) * 1995-07-13 2000-04-25 Sony Corporation Data transmission method, data transmission apparatus and data transmission system
JPH0936871A (ja) 1995-07-17 1997-02-07 Sony Corp データ伝送システムおよびデータ伝送方法
US5604450A (en) * 1995-07-27 1997-02-18 Intel Corporation High speed bidirectional signaling scheme
JPH0955667A (ja) * 1995-08-10 1997-02-25 Mitsubishi Electric Corp マルチプレクサ，及びデマルチプレクサ
US5742840A (en) 1995-08-16 1998-04-21 Microunity Systems Engineering, Inc. General purpose, multiple precision parallel operation, programmable media processor
KR100272472B1 (ko) * 1995-09-19 2000-11-15 씨. 필립 채프맨 디지탈 프로그램가능 임계 레벨을 가진 마이크로컨트롤러 재작동 기능
US5748642A (en) 1995-09-25 1998-05-05 Credence Systems Corporation Parallel processing integrated circuit tester
US5818255A (en) 1995-09-29 1998-10-06 Xilinx, Inc. Method and circuit for using a function generator of a programmable logic device to implement carry logic functions
US5550489A (en) 1995-09-29 1996-08-27 Quantum Corporation Secondary clock source for low power, fast response clocking
US5732352A (en) * 1995-09-29 1998-03-24 Motorola, Inc. Method and apparatus for performing handoff in a wireless communication system
US5751951A (en) 1995-10-30 1998-05-12 Mitsubishi Electric Information Technology Center America, Inc. Network interface
EP0772119A3 (en) 1995-10-31 1997-12-29 Cirrus Logic, Inc. Automatic graphics operation
US5958006A (en) 1995-11-13 1999-09-28 Motorola, Inc. Method and apparatus for communicating summarized data
US7003796B1 (en) * 1995-11-22 2006-02-21 Samsung Information Systems America Method and apparatus for recovering data stream clock
US5844918A (en) 1995-11-28 1998-12-01 Sanyo Electric Co., Ltd. Digital transmission/receiving method, digital communications method, and data receiving apparatus
US5790551A (en) 1995-11-28 1998-08-04 At&T Wireless Services Inc. Packet data transmission using dynamic channel assignment
US6865610B2 (en) 1995-12-08 2005-03-08 Microsoft Corporation Wire protocol for a media server system
EP0781068A1 (en) 1995-12-20 1997-06-25 International Business Machines Corporation Method and system for adaptive bandwidth allocation in a high speed data network
JP3427149B2 (ja) 1996-01-26 2003-07-14 三菱電機株式会社 符号化信号の復号回路及びその同期制御方法， 同期検出回路及び同期検出方法
US5903281A (en) 1996-03-07 1999-05-11 Powertv, Inc. List controlled video operations
US6243596B1 (en) 1996-04-10 2001-06-05 Lextron Systems, Inc. Method and apparatus for modifying and integrating a cellular phone with the capability to access and browse the internet
US5815507A (en) 1996-04-15 1998-09-29 Motorola, Inc. Error detector circuit for digital receiver using variable threshold based on signal quality
US6130602A (en) 1996-05-13 2000-10-10 Micron Technology, Inc. Radio frequency data communications device
JPH09307457A (ja) 1996-05-14 1997-11-28 Sony Corp パラレルシリアル変換回路
US5982362A (en) 1996-05-30 1999-11-09 Control Technology Corporation Video interface architecture for programmable industrial control systems
US5983261A (en) 1996-07-01 1999-11-09 Apple Computer, Inc. Method and apparatus for allocating bandwidth in teleconferencing applications using bandwidth control
GB9614561D0 (en) 1996-07-11 1996-09-04 4Links Ltd Communication system with improved code
US6298387B1 (en) 1996-07-12 2001-10-02 Philips Electronics North America Corp System for detecting a data packet in a bitstream by storing data from the bitstream in a buffer and comparing data at different locations in the buffer to predetermined data
KR100221028B1 (ko) 1996-07-23 1999-09-15 윤종용 그래픽 가속기 및 이를 이용한 메모리 프리패치 방법
US6886035B2 (en) * 1996-08-02 2005-04-26 Hewlett-Packard Development Company, L.P. Dynamic load balancing of a network of client and server computer
US6185601B1 (en) * 1996-08-02 2001-02-06 Hewlett-Packard Company Dynamic load balancing of a network of client and server computers
US5969750A (en) 1996-09-04 1999-10-19 Winbcnd Electronics Corporation Moving picture camera with universal serial bus interface
CA2214743C (en) 1996-09-20 2002-03-05 Ntt Mobile Communications Network Inc. A frame synchronization circuit and communications system
US5990852A (en) 1996-10-31 1999-11-23 Fujitsu Limited Display screen duplication system and method
US5864546A (en) * 1996-11-05 1999-01-26 Worldspace International Network, Inc. System for formatting broadcast data for satellite transmission and radio reception
US6308239B1 (en) * 1996-11-07 2001-10-23 Hitachi, Ltd. Interface switching apparatus and switching control method
US6078361A (en) * 1996-11-18 2000-06-20 Sage, Inc Video adapter circuit for conversion of an analog video signal to a digital display image
US6002709A (en) 1996-11-21 1999-12-14 Dsp Group, Inc. Verification of PN synchronization in a direct-sequence spread-spectrum digital communications system
KR100211918B1 (ko) 1996-11-30 1999-08-02 김영환 비동기식전송모드셀 경계 식별장치
US5862160A (en) * 1996-12-31 1999-01-19 Ericsson, Inc. Secondary channel for communication networks
US5995512A (en) 1997-01-17 1999-11-30 Delco Electronics Corporation High speed multimedia data network
US6064649A (en) 1997-01-31 2000-05-16 Nec Usa, Inc. Network interface card for wireless asynchronous transfer mode networks
US6081513A (en) 1997-02-10 2000-06-27 At&T Corp. Providing multimedia conferencing services over a wide area network interconnecting nonguaranteed quality of services LANs
EP0859326A3 (en) 1997-02-14 1999-05-12 Canon Kabushiki Kaisha Data transmission apparatus, system and method, and image processing apparatus
US6584144B2 (en) 1997-02-24 2003-06-24 At&T Wireless Services, Inc. Vertical adaptive antenna array for a discrete multitone spread spectrum communications system
US6359923B1 (en) 1997-12-18 2002-03-19 At&T Wireless Services, Inc. Highly bandwidth efficient communications
DE19733005B4 (de) 1997-03-12 2007-06-21 Storz Endoskop Gmbh Einrichtung zur zentralen Überwachung und/oder Steuerung wenigstens eines Gerätes
US6480521B1 (en) 1997-03-26 2002-11-12 Qualcomm Incorporated Method and apparatus for transmitting high speed data in a spread spectrum communications system
JP2001524209A (ja) 1997-03-31 2001-11-27 ライス ユニバーシティ 薄膜導体のための静電付着テスター
US7143177B1 (en) 1997-03-31 2006-11-28 West Corporation Providing a presentation on a network having a plurality of synchronized media types
US5963557A (en) 1997-04-11 1999-10-05 Eng; John W. High capacity reservation multiple access network with multiple shared unidirectional paths
US6405111B2 (en) 1997-05-16 2002-06-11 Snap-On Technologies, Inc. System and method for distributed computer automotive service equipment
JP3143079B2 (ja) 1997-05-30 2001-03-07 松下電器産業株式会社 辞書索引作成装置と文書検索装置
US5867510A (en) * 1997-05-30 1999-02-02 Motorola, Inc. Method of and apparatus for decoding and processing messages
KR100550190B1 (ko) * 1997-06-03 2006-04-21 소니 가부시끼 가이샤 휴대용정보처리장치의제어방법,및휴대용정보처리장치
US6236647B1 (en) 1998-02-24 2001-05-22 Tantivy Communications, Inc. Dynamic frame size adjustment and selective reject on a multi-link channel to improve effective throughput and bit error rate
US6314479B1 (en) * 1997-08-04 2001-11-06 Compaq Computer Corporation Universal multi-pin plug and display connector for standardizing signals transmitted between a computer and a display for a PC theatre interconnectivity system
WO1999010719A1 (en) 1997-08-29 1999-03-04 The Regents Of The University Of California Method and apparatus for hybrid coding of speech at 4kbps
US6288739B1 (en) 1997-09-05 2001-09-11 Intelect Systems Corporation Distributed video communications system
US6377993B1 (en) 1997-09-26 2002-04-23 Mci Worldcom, Inc. Integrated proxy interface for web based data management reports
AU9806098A (en) 1997-10-14 1999-05-03 Alation Digital radio-frequency transceiver
US6894994B1 (en) 1997-11-03 2005-05-17 Qualcomm Incorporated High data rate wireless packet data communications system
US6574211B2 (en) 1997-11-03 2003-06-03 Qualcomm Incorporated Method and apparatus for high rate packet data transmission
TW408315B (en) 1997-11-07 2000-10-11 Sharp Kk Magnetic recording device, magnetic recording and reproducing device, and magnetic recording method
US6246876B1 (en) 1997-11-13 2001-06-12 Telefonaktiebolaget L M Ericsson (Publ) Synchronization messages for hand-off operations
US6091709A (en) 1997-11-25 2000-07-18 International Business Machines Corporation Quality of service management for packet switched networks
JPH11163690A (ja) * 1997-11-26 1999-06-18 Toshiba Corp 周波数逓倍回路
US20010012293A1 (en) 1997-12-02 2001-08-09 Lars-Goran Petersen Simultaneous transmission of voice and non-voice data on a single narrowband connection
US6049837A (en) * 1997-12-08 2000-04-11 International Business Machines Corporation Programmable output interface for lower level open system interconnection architecture
US6393008B1 (en) 1997-12-23 2002-05-21 Nokia Movile Phones Ltd. Control structures for contention-based packet data services in wideband CDMA
KR100286080B1 (ko) 1997-12-30 2001-04-16 윤종용 데이터링크를이용한데이터송신및수신방법
KR100251708B1 (ko) 1997-12-31 2000-04-15 윤종용 비동기 전송 모드 스위치에서 링크 대역폭 할당 및 관리 방법
KR100251963B1 (ko) * 1997-12-31 2000-04-15 윤종용 종합정보통신망과 연동 가능한 비동기전송모드 망 접속영상전화 단말장치
TW459184B (en) 1998-01-23 2001-10-11 Shiu Ming Wei Multimedia message processing system
IL137628A (en) * 1998-02-20 2005-09-25 Deep Video Imaging Ltd Multi-layer display and a method for displaying images on such a display
JP3004618B2 (ja) 1998-02-27 2000-01-31 キヤノン株式会社 画像入力装置及び画像入力システム及び画像送受信システム及び画像入力方法及び記憶媒体
JPH11249987A (ja) 1998-03-05 1999-09-17 Nec Corp メッセージ処理装置およびその方法ならびにメッセージ処理制御プログラムを格納した記憶媒体
PL343258A1 (en) 1998-03-16 2001-07-30 Jazio High speed signaling for interfacing vlsi cmos circuits
KR100566040B1 (ko) 1998-03-19 2006-03-30 가부시끼가이샤 히다치 세이사꾸쇼 방송 정보 공급 시스템
US6243761B1 (en) 1998-03-26 2001-06-05 Digital Equipment Corporation Method for dynamically adjusting multimedia content of a web page by a server in accordance to network path characteristics between client and server
US6199169B1 (en) * 1998-03-31 2001-03-06 Compaq Computer Corporation System and method for synchronizing time across a computer cluster
EP1341339A3 (en) 1998-04-01 2004-01-02 Matsushita Graphic Communication Systems, Inc. Activation of multiple xDSL modems with implicit channel probe
US6252888B1 (en) 1998-04-14 2001-06-26 Nortel Networks Corporation Method and apparatus providing network communications between devices using frames with multiple formats
US6101601A (en) 1998-04-20 2000-08-08 International Business Machines Corporation Method and apparatus for hibernation within a distributed data processing system
US6430196B1 (en) 1998-05-01 2002-08-06 Cisco Technology, Inc. Transmitting delay sensitive information over IP over frame relay
KR100413417B1 (ko) 1998-05-04 2004-02-14 엘지전자 주식회사 이동통신시스템에서 단말기의 호 접속 제어 방법.
US6611503B1 (en) 1998-05-22 2003-08-26 Tandberg Telecom As Method and apparatus for multimedia conferencing with dynamic bandwidth allocation
JP3792894B2 (ja) 1998-05-27 2006-07-05 キヤノン株式会社 固体撮像素子及び固体撮像装置
US6043693A (en) 1998-06-01 2000-03-28 3Dfx Interactive, Incorporated Multiplexed synchronization circuits for switching frequency synthesized signals
US6850282B1 (en) 1998-06-02 2005-02-01 Canon Kabushiki Kaisha Remote control of image sensing apparatus
JP3475081B2 (ja) 1998-06-03 2003-12-08 三洋電機株式会社 立体映像再生方法
JP3937269B2 (ja) * 1998-06-04 2007-06-27 ソニー株式会社 情報処理装置および方法、並びに提供媒体
US6092231A (en) 1998-06-12 2000-07-18 Qlogic Corporation Circuit and method for rapid checking of error correction codes using cyclic redundancy check
JP4267092B2 (ja) 1998-07-07 2009-05-27 富士通株式会社 時刻同期方法
US6510503B2 (en) 1998-07-27 2003-01-21 Mosaid Technologies Incorporated High bandwidth memory interface
US6359479B1 (en) * 1998-08-04 2002-03-19 Juniper Networks, Inc. Synchronizing data transfers between two distinct clock domains
US6532506B1 (en) * 1998-08-12 2003-03-11 Intel Corporation Communicating with devices over a bus and negotiating the transfer rate over the same
US6728263B2 (en) * 1998-08-18 2004-04-27 Microsoft Corporation Dynamic sizing of data packets
JP2002525913A (ja) 1998-09-11 2002-08-13 シェアウェーブ・インコーポレーテッド コンピュータ・ネットワーク内の通信を制御するための方法および装置
US6513085B1 (en) 1998-10-13 2003-01-28 Texas Instruments Incorporated Link/transaction layer controller with integral microcontroller emulation
WO2000027079A1 (en) 1998-10-30 2000-05-11 Broadcom Corporation Internet gigabit ethernet transmitter architecture
US6421735B1 (en) 1998-10-30 2002-07-16 Advanced Micro Devices, Inc. Apparatus and method for automatically selecting a network port for a home network station
US7180951B2 (en) * 1998-10-30 2007-02-20 Broadcom Corporation Reduction of aggregate EMI emissions of multiple transmitters
TW466410B (en) 2000-06-16 2001-12-01 Via Tech Inc Cache device inside peripheral component interface chipset and data synchronous method to externals
US6836829B2 (en) 1998-11-20 2004-12-28 Via Technologies, Inc. Peripheral device interface chip cache and data synchronization method
US6545979B1 (en) 1998-11-27 2003-04-08 Alcatel Canada Inc. Round trip delay measurement
CN1240198C (zh) 1998-12-07 2006-02-01 三星电子株式会社 在码分多址移动通信系统中用于选通发送的设备和方法
US6791379B1 (en) 1998-12-07 2004-09-14 Broadcom Corporation Low jitter high phase resolution PLL-based timing recovery system
US6363439B1 (en) * 1998-12-07 2002-03-26 Compaq Computer Corporation System and method for point-to-point serial communication between a system interface device and a bus interface device in a computer system
JP3557975B2 (ja) 1998-12-14 2004-08-25 セイコーエプソン株式会社 信号切り替え回路及び信号切り替え方法
JP4018827B2 (ja) 1998-12-14 2007-12-05 Ｎｅｃエンジニアリング株式会社 データ多重化回路及びデータ分離回路
US6252526B1 (en) 1998-12-14 2001-06-26 Seiko Epson Corporation Circuit and method for fast parallel data strobe encoding
US6297684B1 (en) 1998-12-14 2001-10-02 Seiko Epson Corporation Circuit and method for switching between digital signals that have different signal rates
JP2000196986A (ja) * 1998-12-25 2000-07-14 Olympus Optical Co Ltd 電子的撮像装置
US6950428B1 (en) 1998-12-30 2005-09-27 Hewlett-Packard Development Company, L.P. System and method for configuring adaptive sets of links between routers in a system area network (SAN)
US6549538B1 (en) * 1998-12-31 2003-04-15 Compaq Information Technologies Group, L.P. Computer method and apparatus for managing network ports cluster-wide using a lookaside list
US6836469B1 (en) 1999-01-15 2004-12-28 Industrial Technology Research Institute Medium access control protocol for a multi-channel communication system
JP2000216843A (ja) 1999-01-22 2000-08-04 Oki Electric Ind Co Ltd デジタル復調器
US6636508B1 (en) 1999-02-12 2003-10-21 Nortel Networks Limted Network resource conservation system
US6493824B1 (en) 1999-02-19 2002-12-10 Compaq Information Technologies Group, L.P. Secure system for remotely waking a computer in a power-down state
EP1163607A2 (en) 1999-03-05 2001-12-19 Accenture LLP Method and apparatus for creating an information summary
US6199099B1 (en) 1999-03-05 2001-03-06 Ac Properties B.V. System, method and article of manufacture for a mobile communication network utilizing a distributed communication network
JP4181685B2 (ja) * 1999-03-12 2008-11-19 富士通株式会社 電力制御方法及び電子機器並びに記録媒体
US6429867B1 (en) * 1999-03-15 2002-08-06 Sun Microsystems, Inc. System and method for generating and playback of three-dimensional movies
US6636922B1 (en) 1999-03-17 2003-10-21 Adaptec, Inc. Methods and apparatus for implementing a host side advanced serial protocol
US6609167B1 (en) 1999-03-17 2003-08-19 Adaptec, Inc. Host and device serial communication protocols and communication packet formats
FI107424B (fi) 1999-03-22 2001-07-31 Nokia Mobile Phones Ltd Menetelmä ja järjestelmä multimediaan liittyvän informaation välittämiseen valmistautumiseksi pakettikytkentäisessä solukkoradioverkossa
JP2000278141A (ja) 1999-03-26 2000-10-06 Mitsubishi Electric Corp マルチプレクサ
KR100350607B1 (ko) * 1999-03-31 2002-08-28 삼성전자 주식회사 음성 및 화상 송수신을 위한 휴대용 복합 통신단말기 및 그 동작방법과 통신시스템
US6222677B1 (en) 1999-04-12 2001-04-24 International Business Machines Corporation Compact optical system for use in virtual display applications
JP2000358033A (ja) 1999-06-14 2000-12-26 Canon Inc データ通信システム及びデータ通信方法
US6618360B1 (en) 1999-06-15 2003-09-09 Hewlett-Packard Development Company, L.P. Method for testing data path of peripheral server devices
US6457090B1 (en) 1999-06-30 2002-09-24 Adaptec, Inc. Structure and method for automatic configuration for SCSI Synchronous data transfers
JP2001025010A (ja) 1999-07-09 2001-01-26 Mitsubishi Electric Corp マルチメディア情報通信装置およびその方法
US6865609B1 (en) * 1999-08-17 2005-03-08 Sharewave, Inc. Multimedia extensions for wireless local area network
US6597197B1 (en) 1999-08-27 2003-07-22 Intel Corporation I2C repeater with voltage translation
KR20010019734A (ko) 1999-08-30 2001-03-15 윤종용 유무선 통신을 이용한 컴퓨터 교육용 시스템
US7010607B1 (en) * 1999-09-15 2006-03-07 Hewlett-Packard Development Company, L.P. Method for training a communication link between ports to correct for errors
JP3116090B1 (ja) 1999-09-17 2000-12-11 郵政省通信総合研究所長 通信システム、送信装置、受信装置、送信方法、受信方法、および、情報記録媒体
JP4207329B2 (ja) * 1999-09-20 2009-01-14 富士通株式会社 フレーム同期回路
US6782277B1 (en) 1999-09-30 2004-08-24 Qualcomm Incorporated Wireless communication system with base station beam sweeping
US6678751B1 (en) 1999-10-15 2004-01-13 Micro Motion, Inc. System for setting frame and protocol for transmission in a UART device
US6643787B1 (en) 1999-10-19 2003-11-04 Rambus Inc. Bus system optimization
US6662322B1 (en) 1999-10-29 2003-12-09 International Business Machines Corporation Systems, methods, and computer program products for controlling the error rate in a communication device by adjusting the distance between signal constellation points
AU6458399A (en) 1999-11-11 2001-06-06 Ascom Powerline Communications Ag Communication system, especially for indoors
US6438363B1 (en) 1999-11-15 2002-08-20 Lucent Technologies Inc. Wireless modem alignment in a multi-cell environment
AU1580301A (en) 1999-11-16 2001-05-30 Broadcom Corporation Network switch with high-speed serializing/deserializing hazard-free double datarate switching
AU7728300A (en) 1999-11-22 2001-06-04 Ericsson Inc. Buffer memories, methods and systems for buffering having seperate buffer memories for each of a plurality of tasks
GB2372606B (en) 1999-11-22 2004-06-02 Seagate Technology Llc Peer to peer interconnect diagnostics
TW513636B (en) 2000-06-30 2002-12-11 Via Tech Inc Bus data interface for transmitting data on PCI bus, the structure and the operating method thereof
US6804257B1 (en) 1999-11-25 2004-10-12 International Business Machines Corporation System and method for framing and protecting variable-lenght packet streams
JP4058888B2 (ja) * 1999-11-29 2008-03-12 セイコーエプソン株式会社 Ｒａｍ内蔵ドライバ並びにそれを用いた表示ユニットおよび電子機器
JP4191869B2 (ja) 1999-12-20 2008-12-03 富士フイルム株式会社 ディジタルカメラを用いたコンピュータシステム
US7373650B1 (en) * 2000-02-01 2008-05-13 Scientific-Atlanta, Inc. Apparatuses and methods to enable the simultaneous viewing of multiple television channels and electronic program guide content
US7383350B1 (en) 2000-02-03 2008-06-03 International Business Machines Corporation User input based allocation of bandwidth on a data link
US6778493B1 (en) 2000-02-07 2004-08-17 Sharp Laboratories Of America, Inc. Real-time media content synchronization and transmission in packet network apparatus and method
JP3490368B2 (ja) 2000-02-07 2004-01-26 インターナショナル・ビジネス・マシーンズ・コーポレーション 信号出力装置、ドライバ回路、信号伝送システム、および信号伝送方法
JP2001236304A (ja) 2000-02-21 2001-08-31 Mitsubishi Electric Corp マイクロコンピュータ
JP4449141B2 (ja) 2000-02-22 2010-04-14 ソニー株式会社 電源制御装置、電源制御システム
EP2259652B1 (en) 2000-03-03 2012-02-29 Qualcomm Incorporated Method, system and apparatus for participating in group communication services in an existing communication system
US6477150B1 (en) 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
JP2001282714A (ja) 2000-03-30 2001-10-12 Olympus Optical Co Ltd マルチカメラデータ転送方式及びデータ転送方式
JP2001292146A (ja) 2000-04-07 2001-10-19 Sony Corp 電子機器およびディジタルシリアルデータのインタフェース装置のバス初期化フェーズにおける処理方法
US6882361B1 (en) 2000-04-19 2005-04-19 Pixelworks, Inc. Imager linked with image processing station
JP2001306428A (ja) 2000-04-25 2001-11-02 Canon Inc ネットワーク機器、ネットワークシステム、通信方法及び記録媒体
JP2001319745A (ja) 2000-05-08 2001-11-16 Honda Tsushin Kogyo Co Ltd 変換用アダプタ
JP2001320280A (ja) 2000-05-10 2001-11-16 Mitsubishi Electric Corp 並列−直列変換回路
US6760722B1 (en) 2000-05-16 2004-07-06 International Business Machines Corporation Computer implemented automated remote support
JP4292685B2 (ja) 2000-05-23 2009-07-08 日本電気株式会社 データ転送システム、データ送受信システム、データ送受信方法、フォーマット変換装置、フォーマット変換方法およびフォーマット変換プログラムを記録したコンピュータ読み取り可能な記録媒体
KR100360622B1 (ko) 2000-06-12 2002-11-13 주식회사 문화방송 엠펙 데이터 프레임과 이를 이용한 송수신 시스템
US6754179B1 (en) 2000-06-13 2004-06-22 Lsi Logic Corporation Real time control of pause frame transmissions for improved bandwidth utilization
JP3415567B2 (ja) 2000-06-21 2003-06-09 エヌイーシーマイクロシステム株式会社 Ｕｓｂ転送制御方法およびｕｓｂコントローラ
US6714233B2 (en) * 2000-06-21 2004-03-30 Seiko Epson Corporation Mobile video telephone system
US6999432B2 (en) * 2000-07-13 2006-02-14 Microsoft Corporation Channel and quality of service adaptation for multimedia over wireless networks
TW522306B (en) 2000-08-08 2003-03-01 Replaytv Inc Method and system for remote television replay control
US6892071B2 (en) * 2000-08-09 2005-05-10 Sk Telecom Co., Ltd. Handover method in wireless telecommunication system supporting USTS
US6784941B1 (en) 2000-08-09 2004-08-31 Sunplus Technology Co., Ltd. Digital camera with video input
US6725412B1 (en) 2000-08-15 2004-04-20 Dolby Laboratories Licensing Corporation Low latency data encoder
JP2002062990A (ja) 2000-08-15 2002-02-28 Fujitsu Media Device Kk インターフェイス装置
GB2366926A (en) 2000-09-06 2002-03-20 Sony Uk Ltd Combining material and data
US7138989B2 (en) 2000-09-15 2006-11-21 Silicon Graphics, Inc. Display capable of displaying images in response to signals of a plurality of signal formats
US6747964B1 (en) 2000-09-15 2004-06-08 Qualcomm Incorporated Method and apparatus for high data rate transmission in a wireless communication system
US7466978B1 (en) 2000-09-18 2008-12-16 International Business Machines Corporation Telephone network node device
JP4146991B2 (ja) 2000-09-18 2008-09-10 キヤノン株式会社 電子カメラシステム、電子カメラ及び電子カメラシステムの制御方法
US6760882B1 (en) 2000-09-19 2004-07-06 Intel Corporation Mode selection for data transmission in wireless communication channels based on statistical parameters
US6738344B1 (en) 2000-09-27 2004-05-18 Hewlett-Packard Development Company, L.P. Link extenders with link alive propagation
US7336613B2 (en) * 2000-10-17 2008-02-26 Avaya Technology Corp. Method and apparatus for the assessment and optimization of network traffic
US6690655B1 (en) 2000-10-19 2004-02-10 Motorola, Inc. Low-powered communication system and method of operation
US7869067B2 (en) 2000-10-20 2011-01-11 Visioneer, Inc. Combination scanner and image data reader system including image management and software
US7278069B2 (en) 2000-10-31 2007-10-02 Igor Anatolievich Abrosimov Data transmission apparatus for high-speed transmission of digital data and method for automatic skew calibration
US8996698B1 (en) 2000-11-03 2015-03-31 Truphone Limited Cooperative network for mobile internet access
WO2002041540A1 (en) 2000-11-17 2002-05-23 Samsung Electronics Co., Ltd Apparatus and method for measuring propagation delay in an nb-tdd cdma mobile communication system
US7464877B2 (en) 2003-11-13 2008-12-16 Metrologic Instruments, Inc. Digital imaging-based bar code symbol reading system employing image cropping pattern generator and automatic cropped image processor
FI115802B (fi) 2000-12-04 2005-07-15 Nokia Corp Kuvakehyksien päivittäminen muistillisessa näytössä
GB2397734B (en) 2000-12-06 2004-09-29 Fujitsu Ltd Data recovery circuitry
US6973039B2 (en) 2000-12-08 2005-12-06 Bbnt Solutions Llc Mechanism for performing energy-based routing in wireless networks
US6760772B2 (en) 2000-12-15 2004-07-06 Qualcomm, Inc. Generating and implementing a communication protocol and interface for high data rate signal transfer
US7023924B1 (en) * 2000-12-28 2006-04-04 Emc Corporation Method of pausing an MPEG coded video stream
JP2002208844A (ja) 2001-01-12 2002-07-26 Nec Eng Ltd グリッチ除去回路
US6947436B2 (en) 2001-02-01 2005-09-20 Motorola, Inc. Method for optimizing forward link data transmission rates in spread-spectrum communications systems
US7301968B2 (en) 2001-03-02 2007-11-27 Pmc-Sierra Israel Ltd. Communication protocol for passive optical network topologies
KR20020071226A (ko) 2001-03-05 2002-09-12 삼성전자 주식회사 이동통신 시스템에서 역방향 링크 송신 제어 장치 및 방법
JP4106226B2 (ja) 2001-03-26 2008-06-25 松下電器産業株式会社 電源制御装置
CN1165141C (zh) 2001-03-27 2004-09-01 华为技术有限公司 路由器接口驱动数据转发过程的方法
JP2002300299A (ja) 2001-03-29 2002-10-11 Shunichi Toyoda 携帯電話材のメモリを利用した情報端末装置による教育システム
CN1159935C (zh) 2001-03-30 2004-07-28 华为技术有限公司 一种提高市区环境下蜂窝移动台定位精度的方法和装置
JP3497834B2 (ja) 2001-03-30 2004-02-16 株式会社東芝 ルートリピータ、ｕｓｂ通信システム、ｕｓｂ通信制御方法
JP2002359774A (ja) 2001-03-30 2002-12-13 Fuji Photo Film Co Ltd 電子カメラ
US20030189927A1 (en) 2001-04-27 2003-10-09 Foster Michael S. Method and system for multiframe buffering in a routing device
US6889056B2 (en) 2001-04-30 2005-05-03 Ntt Docomo, Inc. Transmission control scheme
JP3884322B2 (ja) 2001-05-16 2007-02-21 株式会社リコー ネットワークインターフェース
US7392541B2 (en) 2001-05-17 2008-06-24 Vir2Us, Inc. Computer system architecture and method providing operating-system independent virus-, hacker-, and cyber-terror-immune processing environments
JP2002351689A (ja) 2001-05-30 2002-12-06 Nec Corp データ転送システム
US7191281B2 (en) * 2001-06-13 2007-03-13 Intel Corporation Mobile computer system having a navigation mode to optimize system performance and power management for mobile applications
JP2003006143A (ja) 2001-06-22 2003-01-10 Nec Corp バス共有化システムと装置及び方法
US7165112B2 (en) * 2001-06-22 2007-01-16 Motorola, Inc. Method and apparatus for transmitting data in a communication system
US6745364B2 (en) 2001-06-28 2004-06-01 Microsoft Corporation Negotiated/dynamic error correction for streamed media
JP2003046595A (ja) 2001-07-06 2003-02-14 Texas Instruments Inc データ通信の方法および装置
US7051218B1 (en) 2001-07-18 2006-05-23 Advanced Micro Devices, Inc. Message based power management
CN100470654C (zh) 2001-07-23 2009-03-18 松下电器产业株式会社 将信息记录到信息记录介质的装置及方法
US7184408B2 (en) * 2001-07-31 2007-02-27 Denton I Claude Method and apparatus for programmable generation of traffic streams
WO2003013080A1 (en) * 2001-07-31 2003-02-13 Comverse Ltd. Email protocol for a mobile environment and gateway using same
JP2003044184A (ja) 2001-08-01 2003-02-14 Canon Inc データ処理装置及び電力制御方法
GB2415314B (en) * 2001-08-08 2006-05-03 Adder Tech Ltd Video switch
US6758678B2 (en) * 2001-08-14 2004-07-06 Disney Enterprises, Inc. Computer enhanced play set and method
JP4733877B2 (ja) 2001-08-15 2011-07-27 富士通セミコンダクター株式会社 半導体装置
JP2003069544A (ja) 2001-08-23 2003-03-07 Hitachi Kokusai Electric Inc 通信制御方法及び通信制御装置
JP4322451B2 (ja) 2001-09-05 2009-09-02 日本電気株式会社 Ｄｓｐメモリ間あるいはｄｓｐメモリとｃｐｕ用メモリ（ｄｐｒａｍ）間データ転送方式
KR20040036945A (ko) 2001-09-06 2004-05-03 퀄컴 인코포레이티드 하이 데이터 레이트 신호 전송을 위한 통신 프로토콜 및인터페이스의 생성 및 구현
CA2459941C (en) 2001-09-06 2013-09-17 Qiuzhen Zou Generating and implementing a communication protocol and interface for high data rate signal transfer
US8812706B1 (en) * 2001-09-06 2014-08-19 Qualcomm Incorporated Method and apparatus for compensating for mismatched delays in signals of a mobile display interface (MDDI) system
DE10145722A1 (de) 2001-09-17 2003-04-24 Infineon Technologies Ag Konzept zur sicheren Datenkommunikation zwischen elektronischen Bausteinen
US20030061431A1 (en) * 2001-09-21 2003-03-27 Intel Corporation Multiple channel interface for communications between devices
KR100408299B1 (ko) 2001-09-29 2003-12-01 삼성전자주식회사 모드 판단 장치 및 방법
US7570668B2 (en) 2001-10-03 2009-08-04 Nokia Corporation Data synchronization
EP1309133A1 (de) 2001-10-31 2003-05-07 Siemens Aktiengesellschaft Verfahren, Empfangseinrichtung und Sendeeinrichtung zur Bestimmung des schnellsten Nachrichtenpfades ohne Uhrensynchronisation
KR100408525B1 (ko) 2001-10-31 2003-12-06 삼성전자주식회사 네트워크에 적응적인 실시간 멀티미디어 스트리밍 시스템및 방법
US20030125040A1 (en) 2001-11-06 2003-07-03 Walton Jay R. Multiple-access multiple-input multiple-output (MIMO) communication system
US7126945B2 (en) 2001-11-07 2006-10-24 Symbol Technologies, Inc. Power saving function for wireless LANS: methods, system and program products
US20030110234A1 (en) 2001-11-08 2003-06-12 Lightsurf Technologies, Inc. System and methodology for delivering media to multiple disparate client devices based on their capabilities
US6990549B2 (en) * 2001-11-09 2006-01-24 Texas Instruments Incorporated Low pin count (LPC) I/O bridge
US7536598B2 (en) 2001-11-19 2009-05-19 Vir2Us, Inc. Computer system capable of supporting a plurality of independent computing environments
US6891545B2 (en) 2001-11-20 2005-05-10 Koninklijke Philips Electronics N.V. Color burst queue for a shared memory controller in a color sequential display system
GB2382502B (en) 2001-11-23 2005-10-19 Actix Ltd Network testing systems
JP2003167680A (ja) 2001-11-30 2003-06-13 Hitachi Ltd ディスク装置
US20030112758A1 (en) 2001-12-03 2003-06-19 Pang Jon Laurent Methods and systems for managing variable delays in packet transmission
US7486693B2 (en) 2001-12-14 2009-02-03 General Electric Company Time slot protocol
US6993393B2 (en) 2001-12-19 2006-01-31 Cardiac Pacemakers, Inc. Telemetry duty cycle management system for an implantable medical device
JP2003198550A (ja) 2001-12-25 2003-07-11 Matsushita Electric Ind Co Ltd 通信装置及び通信方法
KR100428767B1 (ko) 2002-01-11 2004-04-28 삼성전자주식회사 트래픽 정보를 이용한 가입자 라우팅 설정 방법 및 이를위한 기록매체
US20030135863A1 (en) 2002-01-17 2003-07-17 Koninklijke Philips Electronics N.V. Targeted scalable multicast based on client bandwidth or capability
US20050120208A1 (en) 2002-01-25 2005-06-02 Albert Dobson Robert W. Data transmission systems
US20030144006A1 (en) 2002-01-25 2003-07-31 Mikael Johansson Methods, systems, and computer program products for determining the location of a mobile terminal based on delays in receiving data packets from transmitters having known locations
US6690201B1 (en) * 2002-01-28 2004-02-10 Xilinx, Inc. Method and apparatus for locating data transition regions
JP2003255921A (ja) * 2002-03-04 2003-09-10 Yamaha Corp 表示装置の電源制御方法及び電源制御装置
US7145411B1 (en) 2002-03-18 2006-12-05 Applied Micro Circuits Corporation Flexible differential interconnect cable with isolated high frequency electrical transmission line
US6797891B1 (en) 2002-03-18 2004-09-28 Applied Micro Circuits Corporation Flexible interconnect cable with high frequency electrical transmission line
US6867668B1 (en) 2002-03-18 2005-03-15 Applied Micro Circuits Corporation High frequency signal transmission from the surface of a circuit substrate to a flexible interconnect cable
US7336139B2 (en) 2002-03-18 2008-02-26 Applied Micro Circuits Corporation Flexible interconnect cable with grounded coplanar waveguide
US20030185220A1 (en) 2002-03-27 2003-10-02 Moshe Valenci Dynamically loading parsing capabilities
US7310535B1 (en) 2002-03-29 2007-12-18 Good Technology, Inc. Apparatus and method for reducing power consumption in a wireless device
US7425986B2 (en) 2002-03-29 2008-09-16 Canon Kabushiki Kaisha Conversion apparatus for image data delivery
JP2003303068A (ja) 2002-04-10 2003-10-24 Ricoh Co Ltd 画像出力システム、画像出力方法、プログラム及び記憶媒体
US7430001B2 (en) 2002-04-12 2008-09-30 Canon Kabushiki Kaisha Image sensing system, communication apparatus and image sensing apparatus having remote control function, and their control method
TWI235917B (en) 2002-04-15 2005-07-11 Via Tech Inc High speed data transmitter and transmission method thereof
US7158539B2 (en) * 2002-04-16 2007-01-02 Microsoft Corporation Error resilient windows media audio coding
US7599689B2 (en) 2002-04-22 2009-10-06 Nokia Corporation System and method for bookmarking radio stations and associated internet addresses
JP4029390B2 (ja) 2002-04-23 2008-01-09 ソニー株式会社 情報処理システム、情報処理装置および方法、プログラム格納媒体、並びにプログラム
US7284181B1 (en) 2002-04-24 2007-10-16 Juniper Networks, Inc. Systems and methods for implementing end-to-end checksum
CN1166995C (zh) * 2002-04-27 2004-09-15 西安交通大学 高速视频处理接口控制器及其处理方法
US7206516B2 (en) 2002-04-30 2007-04-17 Pivotal Decisions Llc Apparatus and method for measuring the dispersion of a fiber span
US7574113B2 (en) 2002-05-06 2009-08-11 Sony Corporation Video and audio data recording apparatus, video and audio data recording method, video and audio data reproducing apparatus, and video and audio data reproducing method
US20050091593A1 (en) * 2002-05-10 2005-04-28 General Electric Company Method and system for coordinated transfer of control of a remote controlled locomotive
US6886067B2 (en) 2002-05-23 2005-04-26 Seiko Epson Corporation 32 Bit generic asynchronous bus interface using read/write strobe byte enables
US7036066B2 (en) * 2002-05-24 2006-04-25 Sun Microsystems, Inc. Error detection using data block mapping
US7269153B1 (en) 2002-05-24 2007-09-11 Conexant Systems, Inc. Method for minimizing time critical transmit processing for a personal computer implementation of a wireless local area network adapter
US7543326B2 (en) 2002-06-10 2009-06-02 Microsoft Corporation Dynamic rate control
JP2003098583A (ja) 2002-06-10 2003-04-03 Nikon Corp 書換え可能なメモリを使用するカメラ
JP2004021613A (ja) * 2002-06-17 2004-01-22 Seiko Epson Corp データ転送制御装置、電子機器及びデータ転送制御方法
DE60212104T2 (de) 2002-06-18 2006-10-19 Matsushita Electric Industrial Co., Ltd., Kadoma Auf Empfänger basierte Umlaufzeitmessung in TCP
KR100469427B1 (ko) * 2002-06-24 2005-02-02 엘지전자 주식회사 이동통신 시스템의 동영상 재생 방법
US7486696B2 (en) 2002-06-25 2009-02-03 Avaya, Inc. System and method for providing bandwidth management for VPNs
JP4175838B2 (ja) 2002-07-09 2008-11-05 三菱電機株式会社 待機モード付情報処理装置およびその待機モード開始方法と待機モード解除方法
DE10234991B4 (de) * 2002-07-31 2008-07-31 Advanced Micro Devices, Inc., Sunnyvale Hostcontrollerdiagnose für einen seriellen Bus
US7403511B2 (en) 2002-08-02 2008-07-22 Texas Instruments Incorporated Low power packet detector for low power WLAN devices
US6611221B1 (en) 2002-08-26 2003-08-26 Texas Instruments Incorporated Multi-bit sigma-delta modulator employing dynamic element matching using adaptively randomized data-weighted averaging
US7876821B2 (en) 2002-09-05 2011-01-25 Agency For Science, Technology And Research Method and an apparatus for controlling the rate of a video sequence; a video encoding device
US20040140459A1 (en) 2002-09-13 2004-07-22 Haigh Scott D. Enhanced shadow reduction system and related techniques for digital image capture
US7257087B2 (en) 2002-10-04 2007-08-14 Agilent Technologies, Inc. System and method to calculate round trip delay for real time protocol packet streams
CN1266976C (zh) 2002-10-15 2006-07-26 华为技术有限公司 一种移动台定位方法及其直放站
US20040082383A1 (en) * 2002-10-24 2004-04-29 Motorola, Inc Methodology and wireless device for interactive gaming
JP4028356B2 (ja) 2002-10-31 2007-12-26 京セラ株式会社 通信システム、無線通信端末、データ配信装置及び通信方法
US7949777B2 (en) 2002-11-01 2011-05-24 Avid Technology, Inc. Communication protocol for controlling transfer of temporal data over a bus between devices in synchronization with a periodic reference signal
GB0226014D0 (en) 2002-11-08 2002-12-18 Nokia Corp Camera-LSI and information device
US7336667B2 (en) * 2002-11-21 2008-02-26 International Business Machines Corporation Apparatus, method and program product to generate and use CRC in communications network
US7327735B2 (en) * 2002-11-27 2008-02-05 Alcatel Canada Inc. System and method for detecting lost messages transmitted between modules in a communication device
JP3642332B2 (ja) 2002-12-20 2005-04-27 松下電器産業株式会社 折り畳み式携帯電話装置
US7191349B2 (en) 2002-12-26 2007-03-13 Intel Corporation Mechanism for processor power state aware distribution of lowest priority interrupt
US6765506B1 (en) 2003-01-06 2004-07-20 Via Technologies Inc. Scrambler, de-scrambler, and related method
GB2397709B (en) 2003-01-27 2005-12-28 Evangelos Arkas Period-to-digital converter
US7047475B2 (en) 2003-02-04 2006-05-16 Hewlett-Packard Development Company, L.P. CRC encoding scheme for conveying status information
JP4119764B2 (ja) 2003-02-13 2008-07-16 京セラ株式会社 カメラ付き携帯端末
US20040176065A1 (en) 2003-02-20 2004-09-09 Bo Liu Low power operation in a personal area network communication system
US7787886B2 (en) * 2003-02-24 2010-08-31 Invisitrack, Inc. System and method for locating a target using RFID
US6944136B2 (en) 2003-02-28 2005-09-13 On-Demand Technologies, Inc. Two-way audio/video conferencing system
US20040184450A1 (en) 2003-03-19 2004-09-23 Abdu H. Omran Method and system for transport and routing of packets over frame-based networks
JP4112414B2 (ja) 2003-03-28 2008-07-02 京セラ株式会社 携帯端末装置
US7260087B2 (en) 2003-04-02 2007-08-21 Cellco Partnership Implementation methodology for client initiated parameter negotiation for PTT/VoIP type services
JP2004309623A (ja) 2003-04-03 2004-11-04 Konica Minolta Opto Inc 撮像装置及び携帯端末並びに撮像装置製造方法
JP4288994B2 (ja) * 2003-04-10 2009-07-01 株式会社日立製作所 端末装置、配信サーバ、映像データの受信方法及び映像データの送信方法
US7403487B1 (en) 2003-04-10 2008-07-22 At&T Corporation Method and system for dynamically adjusting QOS
WO2004093451A2 (en) * 2003-04-17 2004-10-28 Thomson Licensing Data requesting and transmitting devices and processes
US20040221315A1 (en) 2003-05-01 2004-11-04 Genesis Microchip Inc. Video interface arranged to provide pixel data independent of a link character clock
US6895410B2 (en) 2003-05-02 2005-05-17 Nokia Corporation Method and apparatus for providing a multimedia data stream
US7477604B2 (en) 2003-05-14 2009-01-13 Ntt Docomo, Inc. Packet communications system
EP1645082A2 (en) 2003-05-28 2006-04-12 Artimi Ltd Ultra-wideband network, device, device controller, method and data packet for establishing a mesh network and forwarding packets on another channel
US7110420B2 (en) 2003-05-30 2006-09-19 North Carolina State University Integrated circuit devices having on-chip adaptive bandwidth buses and related methods
US6975145B1 (en) 2003-06-02 2005-12-13 Xilinx, Inc. Glitchless dynamic multiplexer with synchronous and asynchronous controls
KR101168839B1 (ko) * 2003-06-02 2012-07-26 퀄컴 인코포레이티드 고속 데이터 레이트를 위한 신호 프로토콜 및 인터페이스의 생성 및 구현
JP4278439B2 (ja) 2003-06-02 2009-06-17 パイオニア株式会社 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体
US20040260823A1 (en) 2003-06-17 2004-12-23 General Instrument Corporation Simultaneously transporting multiple MPEG-2 transport streams
JP3834819B2 (ja) * 2003-07-17 2006-10-18 船井電機株式会社 プロジェクタ
KR100538226B1 (ko) * 2003-07-18 2005-12-21 삼성전자주식회사 복수의 아날로그 입력 신호를 고속으로 처리하는아날로그/디지털 변환 장치 및 이를 이용한 디스플레이 장치
US7526350B2 (en) * 2003-08-06 2009-04-28 Creative Technology Ltd Method and device to process digital media streams
KR101178080B1 (ko) 2003-08-13 2012-08-30 퀄컴 인코포레이티드 더 높은 데이터 레이트를 위한 신호 인터페이스
KR100951158B1 (ko) * 2003-09-10 2010-04-06 콸콤 인코포레이티드 고속 데이터 인터페이스
US7467202B2 (en) * 2003-09-10 2008-12-16 Fidelis Security Systems High-performance network content analysis platform
US7015838B1 (en) * 2003-09-11 2006-03-21 Xilinx, Inc. Programmable serializing data path
KR20050028396A (ko) * 2003-09-17 2005-03-23 삼성전자주식회사 멀티 세션 방식을 이용한 데이터 기록 방법 및 그정보저장매체
JP2005107683A (ja) 2003-09-29 2005-04-21 Sharp Corp 通信コントローラ、通信システム、通信機器、および通信方法
ATE387824T1 (de) * 2003-10-08 2008-03-15 Research In Motion Ltd Verfahren und vorrichtung zur dynamischen paketübertragung in cdma2000 netzwerken
US8694652B2 (en) 2003-10-15 2014-04-08 Qualcomm Incorporated Method, system and computer program for adding a field to a client capability packet sent from a client to a host
CN1902880A (zh) 2003-10-29 2007-01-24 高通股份有限公司 高数据速率接口
CN101729205A (zh) 2003-11-12 2010-06-09 高通股份有限公司 具有改进链路控制的高数据速率接口
US7219294B2 (en) 2003-11-14 2007-05-15 Intel Corporation Early CRC delivery for partial frame
US7143207B2 (en) 2003-11-14 2006-11-28 Intel Corporation Data accumulation between data path having redrive circuit and memory device
US7447953B2 (en) 2003-11-14 2008-11-04 Intel Corporation Lane testing with variable mapping
BRPI0416895A (pt) 2003-11-25 2007-03-06 Qualcomm Inc interface de alta taxa de dados com sincronização de link melhorada
EP2247072B1 (en) 2003-12-08 2013-09-25 QUALCOMM Incorporated High data rate interface with improved link synchronization
US7451362B2 (en) 2003-12-12 2008-11-11 Broadcom Corporation Method and system for onboard bit error rate (BER) estimation in a port bypass controller
US7340548B2 (en) 2003-12-17 2008-03-04 Microsoft Corporation On-chip bus
US20050163085A1 (en) 2003-12-24 2005-07-28 International Business Machines Corporation System and method for autonomic wireless presence ping
US7317754B1 (en) 2004-01-12 2008-01-08 Verizon Services Corp. Rate agile rate-adaptive digital subscriber line
CN100524451C (zh) 2004-01-28 2009-08-05 Nxp股份有限公司 用于矩阵显示器的显示方法及显示系统
US7158536B2 (en) * 2004-01-28 2007-01-02 Rambus Inc. Adaptive-allocation of I/O bandwidth using a configurable interconnect topology
US7868890B2 (en) 2004-02-24 2011-01-11 Qualcomm Incorporated Display processor for a wireless device
JP3786120B2 (ja) 2004-03-09 2006-06-14 セイコーエプソン株式会社 データ転送制御装置及び電子機器
WO2005088939A1 (en) 2004-03-10 2005-09-22 Qualcomm Incorporated High data rate interface apparatus and method
JP4519903B2 (ja) 2004-03-17 2010-08-04 クゥアルコム・インコーポレイテッド 高速データレートインタフェース装置及び方法
KR101019935B1 (ko) 2004-03-24 2011-03-09 퀄컴 인코포레이티드 고 데이터 레이트 인터페이스 장치 및 방법
DE102004014973B3 (de) 2004-03-26 2005-11-03 Infineon Technologies Ag Parallel-Seriell-Umsetzer
EP1745556A4 (en) 2004-04-21 2012-09-19 DEVICE AND METHOD FOR MULTI-DATA PROCESSING IN A WIRELESS TERMINAL
US20050265333A1 (en) 2004-06-01 2005-12-01 Texas Instruments Incorporated Method for enabling efficient multicast transmission in a packet-based network
US7088294B2 (en) 2004-06-02 2006-08-08 Research In Motion Limited Mobile wireless communications device comprising a top-mounted auxiliary input/output device and a bottom-mounted antenna
EP1978692B1 (en) 2004-06-04 2011-07-27 QUALCOMM Incorporated High data rate interface apparatus and method
US8650304B2 (en) * 2004-06-04 2014-02-11 Qualcomm Incorporated Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
US20060034301A1 (en) * 2004-06-04 2006-02-16 Anderson Jon J High data rate interface apparatus and method
US7383399B2 (en) * 2004-06-30 2008-06-03 Intel Corporation Method and apparatus for memory compression
US7095435B1 (en) 2004-07-21 2006-08-22 Hartman Richard L Programmable multifunction electronic camera
EP1799643B1 (en) 2004-07-22 2010-09-22 UCB Pharma, S.A. Indolone derivatives, processes for preparing them and their uses
CN101041989A (zh) 2004-08-05 2007-09-26 邱则有 一种钢筋砼立体承力结构楼盖
KR100604323B1 (ko) 2004-08-28 2006-07-24 삼성테크윈 주식회사 내장형 카메라 장치 및 이를 구비한 휴대폰
KR100624311B1 (ko) 2004-08-30 2006-09-19 삼성에스디아이 주식회사 프레임 메모리 제어 방법 및 그것을 이용한 표시 장치
US7161846B2 (en) * 2004-11-16 2007-01-09 Seiko Epson Corporation Dual-edge triggered multiplexer flip-flop and method
US6990335B1 (en) * 2004-11-18 2006-01-24 Charles G. Shamoon Ubiquitous connectivity and control system for remote locations
US8539119B2 (en) 2004-11-24 2013-09-17 Qualcomm Incorporated Methods and apparatus for exchanging messages having a digital data interface device message format
US8667363B2 (en) 2004-11-24 2014-03-04 Qualcomm Incorporated Systems and methods for implementing cyclic redundancy checks
US8723705B2 (en) * 2004-11-24 2014-05-13 Qualcomm Incorporated Low output skew double data rate serial encoder
US8699330B2 (en) * 2004-11-24 2014-04-15 Qualcomm Incorporated Systems and methods for digital data transmission rate control
CA2588702C (en) 2004-11-24 2012-01-03 Qualcomm Incorporated Methods and systems for synchronous execution of commands across a communication link
US7315265B2 (en) * 2004-11-24 2008-01-01 Qualcomm Incorporated Double data rate serial encoder
US8873584B2 (en) 2004-11-24 2014-10-28 Qualcomm Incorporated Digital data interface device
WO2006058045A2 (en) 2004-11-24 2006-06-01 Qualcomm Incorporated Digital data interface device
US8692838B2 (en) 2004-11-24 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US20060161691A1 (en) 2004-11-24 2006-07-20 Behnam Katibian Methods and systems for synchronous execution of commands across a communication link
KR100672987B1 (ko) 2004-12-20 2007-01-24 삼성전자주식회사 고속 아날로그 인벨롭 디텍터
JP2006211394A (ja) * 2005-01-28 2006-08-10 Toshiba Corp 折り畳み型携帯端末装置
US7412642B2 (en) 2005-03-09 2008-08-12 Sun Microsystems, Inc. System and method for tolerating communication lane failures
JP4428272B2 (ja) 2005-03-28 2010-03-10 セイコーエプソン株式会社 表示ドライバ及び電子機器
US7605837B2 (en) 2005-06-02 2009-10-20 Lao Chan Yuen Display system and method
JP2007012937A (ja) 2005-06-30 2007-01-18 Seiko Epson Corp 表示ドライバ
JP4756950B2 (ja) 2005-08-08 2011-08-24 キヤノン株式会社 撮像装置及びその制御方法
US7302510B2 (en) * 2005-09-29 2007-11-27 International Business Machines Corporation Fair hierarchical arbiter
US20070098002A1 (en) 2005-10-28 2007-05-03 Inventec Corporation Media center operating mode selection control method and system
US8730069B2 (en) * 2005-11-23 2014-05-20 Qualcomm Incorporated Double data rate serial encoder
US8692839B2 (en) 2005-11-23 2014-04-08 Qualcomm Incorporated Methods and systems for updating a buffer
US7813451B2 (en) 2006-01-11 2010-10-12 Mobileaccess Networks Ltd. Apparatus and method for frequency shifting of a wireless signal and systems using frequency shifting
US7893990B1 (en) 2006-07-31 2011-02-22 Cisco Technology, Inc. Digital video camera with retractable data connector and resident software application
JP4250648B2 (ja) 2006-09-21 2009-04-08 株式会社東芝 情報処理装置
US7912503B2 (en) * 2007-07-16 2011-03-22 Microsoft Corporation Smart interface system for mobile communications devices
JP2009284281A (ja) 2008-05-23 2009-12-03 Nec Electronics Corp 無線通信機器、及び無線通信状態表示方法
US20100032295A1 (en) * 2008-08-06 2010-02-11 Genome Corporation Continuous film electrophoresis
KR200469360Y1 (ko) 2008-12-26 2013-10-11 대성전기공업 주식회사 시트 온도 조절 스위치 장치
KR101925412B1 (ko) * 2012-07-03 2018-12-05 삼성전자주식회사 휴대 단말기의 슬립 모드 제어 방법 및 장치

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002049314A2 (en) * 2000-12-15 2002-06-20 Qualcomm Incorporated Generating and implementing a communication protocol and interface for high data rate signal transfer
JP2004531916A (ja) * 2000-12-15 2004-10-14 クゥアルコム・インコーポレイテッド 通信プロトコルの発生と実施および高いデータレート信号転送のためのインターフェース
JP2003111135A (ja) * 2001-10-02 2003-04-11 Nec Corp 輻輳制御システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8356331B2 (en) 2007-05-08 2013-01-15 Qualcomm Incorporated Packet structure for a mobile display digital interface
JP2010533388A (ja) * 2008-05-06 2010-10-21 クゥアルコム・インコーポレイテッド モバイル・ディスプレイ・ディジタル・インターフェース用パケット構造
WO2022009574A1 (ja) * 2020-07-09 2022-01-13 ソニーセミコンダクタソリューションズ株式会社 送信装置、通信システム、及び情報送信方法
US11902162B2 (en) 2020-07-09 2024-02-13 Sony Semiconductor Solutions Corporation Transmission apparatus, communications system, and information transmission method

Also Published As

Publication number Publication date
KR100919761B1 (ko) 2009-10-07
EP2375675B1 (en) 2013-05-01
EP2375677B1 (en) 2013-05-29
EP1733537A1 (en) 2006-12-20
CA2559234A1 (en) 2005-09-22
CA2775784A1 (en) 2005-09-22
CN101827103A (zh) 2010-09-08
RU2006135633A (ru) 2008-04-20
US20050213593A1 (en) 2005-09-29
WO2005088939A1 (en) 2005-09-22
AU2005222371B2 (en) 2009-05-21
MXPA06010312A (es) 2007-01-19
CA2559234C (en) 2012-07-10
EP2375676A1 (en) 2011-10-12
US20110199383A1 (en) 2011-08-18
US20110199931A1 (en) 2011-08-18
IL177985A0 (en) 2006-12-31
US8669988B2 (en) 2014-03-11
EP2309695A1 (en) 2011-04-13
US8625625B2 (en) 2014-01-07
US8730913B2 (en) 2014-05-20
RU2337497C2 (ru) 2008-10-27
BRPI0508582A (pt) 2007-08-14
AU2005222371A1 (en) 2005-09-22
AU2005222371C1 (en) 2009-12-24
EP2375675A1 (en) 2011-10-12
KR20060120289A (ko) 2006-11-24
JP2013258691A (ja) 2013-12-26
JP2011023009A (ja) 2011-02-03
EP2375677A1 (en) 2011-10-12
CA2775734A1 (en) 2005-09-22
CA2775734C (en) 2014-01-07
EP2375676B1 (en) 2013-06-26
CN101827103B (zh) 2012-07-04

Similar Documents

Publication Publication Date Title
JP4902355B2 (ja) 改良されたリンク同期を備えた高速データレートインタフェース
JP5032301B2 (ja) 高データレートインターフェース装置および方法
JP5275284B2 (ja) 高速データレートインタフェース装置及び方法
JP4519903B2 (ja) 高速データレートインタフェース装置及び方法
JP4782694B2 (ja) 改善されたリンク制御を有する高速データレートインタフェース
JP4838132B2 (ja) 高速データレートインタフェース
JP5795403B2 (ja) さらに高速なデータレート用の信号インタフェース
JP5237319B2 (ja) 高速データレートインタフェース
US8650304B2 (en) Determining a pre skew and post skew calibration data rate in a mobile display digital interface (MDDI) communication system
KR100919761B1 (ko) 고 데이터 레이트 인터페이스 장치 및 방법
US20060034301A1 (en) High data rate interface apparatus and method
JP2007512785A (ja) 改良されたリンク同期を備えた高速データレートインタフェース

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080409

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090421

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090721

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091021

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20091028

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100121

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100323

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100723

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20100730

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20100820