(57)【要約】  可動性のディスプレイ・ディジタル・インターフェース（ＭＤＤＩ）用のパケット構造は、効率的に大きなパケットを送信するためにフレキシブル・サブフレーム長さを含んでいる。いくつかのパラメーターが不変の場合、ウインドウのないビデオ・ストリーム・パケットは、ビデオ・パケットの反復の送信を回避して帯域幅を節約している。機能強化された逆カプセル化パケットは、個別の逆カプセル化パケットと個別の往復遅れパケットの特徴を組み合わせている。リンク凍結は、送信のどの時点でもデータ・ストリームの送信を停止させて、かつホストによる送信を再開するために使用される。
2010533388.tif 000002
【特許請求の範囲】
【請求項１】
電子装置内においてクライアント及びホストを連結する送信リンクに亘って少なくとも１つのパケットを含むフレキシブル・サブフレームを送信する方法であって、
前記ホストから前記クライアントに向けてサブフレーム境界で近接され、サブフレーム長の指標を含む第１のサブフレーム・ヘッダ・パケットを送る工程と、
前記ホストから前記クライアントに向けて前記少なくとも１つのパケットを転送する工程と、
を具備する方法。
【請求項２】
前記ホストから前記クライアントに向けて少なくとも１つのパケットが前記少なくとも１つの境界を越えた後に転送された少なくとも１つのパケットの終端で第２のサブフレーム・ヘッダ・パケットを転送する工程を更に具備する方法において、前記サブフレーム長がフレキシブル長である請求項１の方法。
【請求項３】
第１のサブフレームが目標とするサブフレーム長を越えた量だけ第２のサブフレーム長を調整して平均サブフレーム長さに対応させる請求項２の方法。
【請求項４】
前記サブフレーム長さが無制限の長さを含む請求項１の方法。
【請求項５】
電子装置内においてクライアント及びホストを連結する送信リンクに亘って少なくとも１つのパケットから構成されるフレキシブル・サブフレームを送信するシステムであって、
前記ホストから前記クライアントに向けてサブフレーム境界で近接され、サブフレーム長の指標を含む第１のサブフレーム・ヘッダ・パケットを送る手段と、
前記ホストから前記クライアントに向けて前記少なくとも１つのパケットを転送する手段と、
を具備するシステム。
【請求項６】
前記ホストから前記クライアントに向けて少なくとも１つのパケットが前記少なくとも１つの境界を越えた後に転送された少なくとも１つのパケットの終端で第２のサブフレーム・ヘッダ・パケットを転送する手段を更に具備するシステムにおいて、前記サブフレーム長がフレキシブル長である請求項５のシステム。
【請求項７】
前記第２のサブフレーム・ヘッダ・パケットを送る手段は、第１のサブフレームが目標とするサブフレーム長を越えた量だけ第２のサブフレーム長を調整して平均サブフレーム長さに対応させる手段を具備する請求項６のシステム。
【請求項８】
前記サブフレーム長さが無制限の長さを含む請求項５のシステム。
【請求項９】
電子装置内においてクライアント及びホストを連結する送信リンクに亘って少なくとも１つのパケットから構成されるフレキシブル・サブフレームを送信させるコードと、
前記ホストから前記クライアントに向けてサブフレーム境界で近接され、サブフレーム長の指標を含む第１のサブフレーム・ヘッダ・パケットを送らせるコードと、及び
前記ホストから前記クライアントに向けて前記少なくとも１つのパケットを転送させるコードと、
を具備するコンピュータで読み込み可能な媒体を含むコンピュータ・プログラム・プロダクト。
【請求項１０】
前記ホストから前記クライアントに向けて少なくとも１つのパケットが前記少なくとも１つの境界を越えた後に転送された少なくとも１つのパケットの終端で第２のサブフレーム・ヘッダ・パケットを転送させるコードを更に具備するコンピュータ・プログラム・プロダクトにおいて、前記サブフレーム長がフレキシブル長である請求項９のコンピュータ・プログラム・プロダクト。
【請求項１１】
第１のサブフレームが目標とするサブフレーム長を越えた量だけ第２のサブフレーム長を調整して平均サブフレーム長さに対応させる請求項１０のコンピュータ・プログラム・プロダクト。
【請求項１２】
前記サブフレーム長さが無制限の長さを含む請求項９のコンピュータ・プログラム・プロダクト。
【請求項１３】
電子装置内のクライアント及びホストを連結する送信リンクに亘ってウインドウのないビデオデータ・パケットを送る方法であって、
ビデオデータ・パケットからＸ左フィールド座標及びＸ右フィールド座標、Ｙ上方フィールド座標、Ｙ下方フィールド座標、Ｘ始点フィールド座標及びＹ始点フィールド座標を除く工程と、
ビデオデータ・パケットのフィールドにデータ・スクリーンの最初のラインを示す垂直同期を用意する工程であって、前記除去及び用意する工程にウインドウのないビデオデータ・パケットを生成する工程が含まれているところの工程と、及び
前記ホストから前記クライアントに前記ウインドウのないビデオデータ・パケットを送る工程と、
を具備する方法。
【請求項１４】
前記データ・スクリーンの全ラインを更新する工程を更に含む請求項１３の方法。
【請求項１５】
前記ホストから前記クライアントに前記データ・スクリーン上におけるピクセル・データの位置の増加を除く前記垂直同期を備えた第２のウインドウのないビデオデータ・パケットを送る工程を更に具備する請求項１４の方法。
【請求項１６】
電子装置内においてクライアント及びホストを連結する送信リンクに亘ってウインドウのないビデオデータ・パケットを送信するシステムであって、
ビデオデータ・パケットからＸ左フィールド座標及びＸ右フィールド座標、Ｙ上方フィールド座標、Ｙ下方フィールド座標、Ｘ始点フィールド座標及びＹ始点フィールド座標を除く手段と、
ビデオデータ・パケットのフィールドにデータ・スクリーンの最初のラインを示す垂直同期を用意する工程であって、前記除去及び用意する工程にウインドウのないビデオデータ・パケットを生成する工程が含まれているところの手段と、及び
前記ホストから前記クライアントに前記ウインドウのないビデオデータ・パケットを送手段と、
を具備するシステム。
【請求項１７】
前記データ・スクリーンの全ラインを更新する手段を更に含む請求項１６のシステム。
【請求項１８】
前記ホストから前記クライアントに前記データ・スクリーン上におけるピクセル・データの位置の増加を除く前記垂直同期を備えた第２のウインドウのないビデオデータ・パケットを送る手段を更に具備する請求項１７のシステム。
【請求項１９】
電子装置内においてクライアント及びホストを連結する送信リンクに亘るウインドウのないビデオデータ・パケットを送信させるコードと、
ビデオデータ・パケットからＸ左フィールド座標及びＸ右フィールド座標、Ｙ上方フィールド座標、Ｙ下方フィールド座標、Ｘ始点フィールド座標及びＹ始点フィールド座標を除かせるコードと、
ビデオデータ・パケットのフィールドにデータ・スクリーンの最初のラインを示す垂直同期を用意させるコードであって、前記フィールド座標の除去及び前記垂直同期を用意は、ウインドウのないビデオデータ・パケットを生成することを含んでいるところのコードと、及び
前記ホストから前記クライアントに前記ウインドウのないビデオデータ・パケットを送らせるコードと、
を具備するコンピュータで読み込み可能な媒体を含むコンピュータ・プログラム・プロダクト。
【請求項２０】
前記データ・スクリーンの全ラインを更新するコードを更に含む請求項１９のコンピュータ・プログラム・プロダクト。
【請求項２１】
前記ホストから前記クライアントに前記データ・スクリーン上におけるピクセル・データの位置の増加を除く前記垂直同期を備えた第２のウインドウのないビデオデータ・パケットを送るコードを含む請求項２０のコンピュータ・プログラム・プロダクト。
【請求項２２】
電子装置内においてクライアント及びホストを連結する送信リンクに亘ってフレキシブル・ビデオデータ・パケットを送信する方法において、
ビデオデータ・パケットにパケット・コンテンツ・フィールドを挿入する工程であって、このパケット・コンテンツ・フィールドにおける各ビットは、いずれのかの少なくとも１つの対応フィールドがビデオデータ・パケット中にあるかを示し、前記フレキシブルビデオ・データを生成することを含む工程と、
前記ホストからクライアントに前記フレキシブル・ビデオデータ・パケットを送らせる工程と、
を具備する方法。
【請求項２３】
電子装置内において、クライアント及びホストを連結する送信リンクに亘ってフレキシブル・ビデオデータ・パケットを送信するシステムにおいて、
ビデオデータ・パケットにパケット・コンテンツ・フィールドを挿入する手段であって、このパケット・コンテンツ・フィールドにおける各ビットは、いずれのかの少なくとも１つの対応フィールドがビデオデータ・パケット中にあるかを示し、前記フレキシブルビデオ・データを生成する手段を含む挿入する手段と、
前記ホストからクライアントに前記フレキシブル・ビデオデータ・パケットを送らせる手段と、
を具備するシステム。
【請求項２４】
電子装置内において、クライアント及びホストを連結する送信リンクに亘ってフレキシブル・ビデオデータ・パケットを送信させるコードと、
ビデオデータ・パケットにパケット・コンテンツ・フィールドを挿入させるコードであって、このパケット・コンテンツ・フィールドにおける各ビットは、いずれのかの少なくとも１つの対応フィールドがビデオデータ・パケット中にあるかを示し、前記フレキシブルビデオ・データを生成することを含むコードと、
前記ホストからクライアントに前記フレキシブル・ビデオデータ・パケットを送らせるコードと、
を具備するコンピュータで読み込み可能な媒体を含むコンピュータ・プログラム・プロダクト。
【請求項２５】
電子装置内のクライアント及びホストを連結する送信リンクに亘って機能強化されたリバース・リンク・カプセル化パケットを提供する方法であって、
前記ホストから前記クライアントに転送される前記機能強化されたリバース・リンク・カプセル化パケット内に第１のフラグをセットして前記クライアントから前記ホストに同期パターンが転送されるべきである旨を要求する工程と、
前記ホストから前記クライアントに転送される前記機能強化されたリバース・リンク・カプセル化パケット内に第２のフラグをセットして前記クライアントから前記ホストに転送されるバイト数をカウントする旨を要求する工程と、
前記ホストへの前記クライアントの転送の為に前記機能強化されたリバース・リンク・カプセル化パケット内に固定時間期間を与える工程と、
前記クライアントによって転送される前記機能強化されたリバース・リンク・カプセル化パケットのリバース・データ部内に同期パターンを与える工程と、
前記ホストから前記クライアントに転送されることが予想される全バイト数を示すバイトカウントを与える工程と、
同期パターンを用いて往復遅れを測定する工程と、及び
前記クライアントに前記ホストのバイトカウントを一致させる工程と、
を具備する方法。
【請求項２６】
前記クライアントから前記ホストにデータ・パケットを送信する工程を更に含む請求項２５の方法。
【請求項２７】
前記同期パターンを与える工程は、前記クライアントから特定の連続的バイトを転送してリバース・リンクに実際のパケットが転送される前に前記ホストにリバース・データを同期させることを許すことを含む請求項２５の方法。
【請求項２８】
次に転送される機能強化されたリバース・リンク・カプセル化パケットの為にフラグをセットすることなく、また、同期パターンを送ることなく、既に測定された往復遅れを用いる工程を更に含む請求項２５の方法。
【請求項２９】
前記クライアントから前記ホストにバイトカウント値を送って前記機能強化されたリバース・リンク・カプセル化パケットのリバース・データ部分中に現在割り付けられているより少ないバイトを送ることを示す工程を更に含む請求項２５の方法。
【請求項３０】
前記バイトカウント値は、前記機能強化されたリバース・リンク・カプセル化パケットの最大バイト・フィールドに示された値に比べ少しも大きくない請求項２９の方法。
【請求項３１】
前記クライアントが前記バイト値に示されるバイト数だけ転送した後に、前記クライアント及び前記ホストにおける処理が前記機能強化されたリバース・リンク・カプセル化パケット中の次のフィールドに向けられる請求項３０の方法。
【請求項３２】
前記機能強化されたリバース・リンク・カプセル化パケット上に送信されるべきバイトカウントのためのフラグをセットせず、最大のバイト・フィールドにおける値と等しくなるように最大バイト数まで転送されることが許可される工程を更に含む請求項２５の方法。
【請求項３３】
電子装置内のクライアント及びホストを連結する送信リンクに亘って機能強化されたリバース・リンク・カプセル化パケットを供給するシステムであって、
前記ホストから前記クライアントに転送される前記機能強化されたリバース・リンク・カプセル化パケット内に第１のフラグをセットして前記クライアントから前記ホストに同期パターンが転送されるべきである旨を要求する手段と、
前記ホストから前記クライアントに転送される前記機能強化されたリバース・リンク・カプセル化パケット内に第２のフラグをセットして前記クライアントから前記ホストに転送されるバイト数をカウントする旨を要求する手段と、
前記ホストへの前記クライアントの転送の為に前記機能強化されたリバース・リンク・カプセル化パケット内に固定時間期間を与える手段と、
前記クライアントによって転送される前記機能強化されたリバース・リンク・カプセル化パケットのリバース・データ部内に同期パターンを与える手段と、
前記ホストから前記クライアントに転送されることが予想される全バイト数を示すバイトカウントを与える手段と、
同期パターンを用いて往復遅れを測定する手段と、及び
前記クライアントに前記ホストのバイトカウントを一致させる手段と、
を具備するシステム。
【請求項３４】
前記クライアントから前記ホストにデータ・パケットを送信する手段を更に具備する請求項３３のシステム。
【請求項３５】
前記同期パターンを与える手段は、前記クライアントから特定の連続的バイトを転送してリバース・リンクに実際のパケットが転送される前に前記ホストにリバース・データを同期させることを許す手段を含む請求項３３のシステム。
【請求項３６】
次に転送される機能強化されたリバース・リンク・カプセル化パケットの為にフラグをセットしない手段及び同期パターンを送らない手段、既に測定された往復遅れを用いる手段を更に含む請求項３３のシステム。
【請求項３７】
前記クライアントから前記ホストにバイトカウント値を送って前記機能強化されたリバース・リンク・カプセル化パケットのリバース・データ部分中に現在割り付けられているより少ないバイトを送ることを示す手段を更に含む請求項３３のシステム。
【請求項３８】
前記バイトカウント値は、前記機能強化されたリバース・リンク・カプセル化パケットの最大バイト・フィールドに示された値に比べ少しも大きくない請求項３７のシステム。
【請求項３９】
前記クライアントが前記バイト値に示されるバイト数だけ転送した後に、前記クライアント及び前記ホストにおける処理が前記機能強化されたリバース・リンク・カプセル化パケット中の次のフィールドに向けられる請求項３０のシステム。
【請求項４０】
前記機能強化されたリバース・リンク・カプセル化パケット上に送信されるべきバイトカウントのためのフラグをセットしない手段及び最大のバイト・フィールドにおける値と等しくなるように最大バイト数まで転送されることを許可する手段を更に含む請求項３３のシステム。
【請求項４１】
電子装置内のクライアント及びホストを連結する送信リンクに亘って機能強化されたリバース・リンク・カプセル化パケットを提供させるコードと、
前記ホストから前記クライアントに転送される前記機能強化されたリバース・リンク・カプセル化パケット内に第１のフラグをセットさせて前記クライアントから前記ホストに同期パターンが転送されるべきである旨を要求させるコードと、
前記ホストから前記クライアントに転送される前記機能強化されたリバース・リンク・カプセル化パケット内に第２のフラグをセットさせて前記クライアントから前記ホストに転送されるバイト数をカウントする旨を要求させるコードと、
前記ホストへの前記クライアントの転送の為に前記機能強化されたリバース・リンク・カプセル化パケット内に固定時間期間を与えさせるコードと、
前記クライアントによって転送される前記機能強化されたリバース・リンク・カプセル化パケットのリバース・データ部内に同期パターンを与えさせるコードと、
前記ホストから前記クライアントに転送されることが予想される全バイト数を示すバイトカウントを与えさせるコードと、
同期パターンを用いて往復遅れを測定させるコードと、及び
前記クライアントに前記ホストのバイトカウントを一致させるコードと、
を具備するコンピュータで読み込み可能な媒体を含むコンピュータ・プログラム・プロダクト。
【請求項４２】
前記クライアントから前記ホストにデータ・パケットを送信させるコードを更に含む請求項４１のコンピュータ・プログラム・プロダクト。
【請求項４３】
前記同期パターンを与えるコードは、前記クライアントから特定の連続的バイトを転送してリバース・リンクに実際のパケットが転送される前に前記ホストにリバース・データを同期させることを許すコードを含む請求項４１のコンピュータ・プログラム・プロダクト。
【請求項４４】
次に転送される機能強化されたリバース・リンク・カプセル化パケットの為にフラグをセットすることなく、また、同期パターンを送ることなく、既に測定された往復遅れを用いさせるコードを更に含む請求項４１のコンピュータ・プログラム・プロダクト。
【請求項４５】
前記クライアントから前記ホストにバイトカウント値を送って前記機能強化されたリバース・リンク・カプセル化パケットのリバース・データ部分中に現在割り付けられているより少ないバイトを送ることを示させるコードを更に含む請求項４１のコンピュータ・プログラム・プロダクト。
【請求項４６】
前記バイトカウント値は、前記機能強化されたリバース・リンク・カプセル化パケットの最大バイト・フィールドに示された値に比べ少しも大きくない請求項４５のコンピュータ・プログラム・プロダクト。
【請求項４７】
前記クライアントが前記バイト値に示されるバイト数だけ転送した後に、前記クライアント及び前記ホストにおける処理が前記機能強化されたリバース・リンク・カプセル化パケット中の次のフィールドに向けさせるコードを更に具備する請求項４６のコンピュータ・プログラム・プロダクト。
【請求項４８】
前記機能強化されたリバース・リンク・カプセル化パケット上に送信されるべきバイトカウントのためのフラグをセットせず、最大のバイト・フィールドにおける値と等しくなるように最大バイト数まで転送されることが許可させるコードを更に含む請求項４１のコンピュータ・プログラム・プロダクト。
【請求項４９】
モバイルのディスプレイ・ディジタル・インターフェース（ＭＤＤＩ）コミュニケーション装置内のクライアント及びホストを連結する送信リンクに亘ってリンク・フリーズを与える方法であって、
前記ホストによるデータ・ストリームの送信を停止させる工程と、
１送信ビットのビット時間より大きな時間期間の間、データ及びストロボ信号の両方の現出力ビットを維持する工程と、
前記データ及び前記ストロボ信号の最後に送信されたビットの一部として出力レベルの値を保持する工程と、及び
前記ホストによるデータ・ストリームの送信を再開する工程と、
を具備する方法。
【請求項５０】
モバイルのディスプレイ・ディジタル・インターフェース（ＭＤＤＩ）コミュニケーション装置内のクライアント及びホストを連結する送信リンクに亘ってリンク・フリーズを与えるシステムであって、
前記ホストによるデータ・ストリームの送信を停止させる手段と、
１送信ビットのビット時間より大きな時間期間の間、データ及びストロボ信号の両方の現出力ビットを維持する手段と、
前記データ及び前記ストロボ信号の最後に送信されたビットの一部として出力レベルの値を保持する手段と、及び
前記ホストによるデータ・ストリームの送信を再開する手段と、
を具備するシステム。
【請求項５１】
モバイルのディスプレイ・ディジタル・インターフェース（ＭＤＤＩ）コミュニケーション装置内のクライアント及びホストを連結する送信リンクに亘ってリンク・フリーズを与えさせるコードと、
前記ホストによるデータ・ストリームの送信を停止させる工程と、
１送信ビットのビット時間より大きな時間期間の間、データ及びストロボ信号の両方の現出力ビットを維持させるコードと、
前記データ及び前記ストロボ信号の最後に送信されたビットの一部として出力レベルの値を保持させるコードと、及び
前記ホストによるデータ・ストリームの送信を再開させるコードと、
を具備するコンピュータで読み込み可能な媒体を含むコンピュータ・プログラム・プロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、この発明は、コミュニケーション・リンクに係り、特に、モバイル・ディスプレイ・ディジタル・インターフェース（ＭＤＤＩ）リンクの為に改良されたパケット構造を提供するための方法、システム及びコンピュータ・プログラム・プロダクツに関する。
【０００２】
この出願に対しては、「ＶＥＳＡスタンダード・ディスプレイ・ディジタル・インターフェース・バージョン１．５」として２００７年５月８日に仮出願され、譲受人に譲渡された特許出願６０／９２８，４８８の優先権を主張し、また、この出願に参照の為にこの基礎特許出願が組込まれることを表明する。
【０００３】
この出願に対しては、共通に譲渡された「ハイスピード・データ転送の為の通信プロトコル及びインターフェースの生成並びに履行」とタイトルが付され、２００４年７月６日に特許された米国特許６，７６０，７７２Ｂ２と、「ダブル・データ・レート・シリアル・エンコーダ」とタイトルが付され、２００８年１月１日に特許された米国特許７，３１５，２６５とに関連している。
【背景技術】
【０００４】
相互接続の技術分野において、特に、ビデオのプレゼンテーションに関連するような技術において、データ・レートをより増加させる要求が大きくなっている。
【０００５】
モバイル・ディスプレイ・ディジタル・インターフェース（ＭＤＤＩ）は、良好なコスト効率で、且つ、低い電力消費であり、まさにホストとクライアントとの間のような短い範囲のコミュニケーション・リンクにおいて、非常に高いデータ転送を可能とする転送機構である。ＭＤＤＩは、毎秒３．２ギガビット（Ｇｂｉｔ）に達する最大の帯域幅を実現する双方向データ転送の為のパワーに加えて最少４つの配線を必要とする。
【０００６】
1つの応用分野として、ＭＤＤＩは、ＬＣＤ表示部及び／又はカメラをディジタル・ベースバンド・コントローラーに相互接続させる為に携帯電話機のヒンジを横切る配線の数を著しく縮小させることができ、折り畳み型電話器における信頼度を増加させ、電力消費を減少させることができる。この配線の減少は、折り畳み携帯電話の設計或いはスライディング携帯電話の設計を更に単純化することができ、携帯電話器メーカーが開発費を低下させることを可能にすることができる。更に、ＭＤＤＩで採用されている差動信号伝達は、従来の並列接続上に生じる電気磁気干渉を減少させている。
【０００７】
現在のＭＤＤＩシステムには、いくつかの改良が必要とされる。現在のサブフレームは、固定サブフレーム長及びタイミング間隔を含んでいる。これはシステムを各サブフレームでビット数を固定に制限し、固定レートで作動させている。これは、パケットが1つのサブフレームから次のサブフレームに跨ることを防止している。大きなパケットは、次のサブフレームが送信されるまで遅延が与えられなければならず、帯域幅を浪費し、かつ、待ち時間を増加させることとなる。フレキシブル・サブフレーム長を備えるシステムは、より効率的にこれらの大きなパケットを送信するために必要とされる。固定サブフレーム長に関する他の改良は、休止状態からリンクが出現する場合に、無制限のサブフレーム長を使用することができる能力にある。サブフレームのヘッダー・パケットがスタートアップ時にクライアントに同期を許可するために一度だけ送信されることから、これが更に帯域幅を縮小することとなる。
【０００８】
既存のシステムに必要とされる他の改良には、パラメーターのうちのいくつかが不変の場合に、あるビデオ・パケット・データの反復の再送信を回避する方法にある。再び、これは帯域幅を縮小することとなる。これはウインドウ(窓）のないビデオ・ストリーム・パケットを提供することにより遂行される。更に、システムは、いくつかの値が変わらない場合に、どこのフィールドがビデオ・ストリーム・パケット内に含まれるか明示する方法を提供するために必要とされる。繰り返し前パケット中で送られたものと同一の値を含んでいるフィールドを再送達することは、帯域幅を浪費することとなる。このことは、フレキシブルなビデオ・ストリーム・パケットのパケット・コンテンツ分野で生じている。
【０００９】
既存のシステムは、最初に往復遅延測定パケットを送信し、次に、ホストがクライアントからデータを受け取るために分離され、逆送されるカプセル化パケットを送信する。この出願で請求項に記載された発明は、現在のシステムに関する著しい改良であり、２つのパケットの機能性を組み合わせて単一の機能強化された、逆送されるカプセル化パケットとされている。
【発明の概要】
【００１０】
ここで、開示されたクレームに記述の発明の態様は、フレキシブル・サブフレーム長から構成されるフレーム構造を使用する方法、システム及びコンピュータ・プログラム・プロダクトを提供することにより、上記の述べた要求に対処することとなる。フレキシブル・サブフレームは、サブフレーム長の表示を備えたサブフレーム境界でサブフレーム・ヘッダ・パケットを送る。パケットがＭＤＤＩインターフェースに送信されることが要求される場合、それは、現サブフレーム中で不十分な残存スペースがあることに基づき送信がブロックされることはない。これは、パケットには１つ又は１つ以上のサブフレーム境界が生じるかもしれない。あるサブフレーム境界が跨る場合、他のサブフレーム・ヘッダ・パケットは、境界を跨るパケットの後に送信された最初のパケッとなる。この第２のサブフレームは、前のサブフレームがサブフレーム長を越える所の量に等しい量だけ短くされる。これは、固定サブフレーム長を使用するサブフレームタイミングに類似する平均タイミングを維持する。しかし、それは、パケットの任意長の送信を防止しない。更に、これは、クライアントが同期を失った際にサブフレーム・ヘッダ・パケットが半周期で送信されるべきであることを可能としている。無制限のサブフレーム長であっても、処理することができ、それによってリンクが休眠状態から出現する際に、パケット・データを含んでいるサブフレームが無制限長でなる場合、１つのサブフレーム・ヘッダ・パケットだけが送信される。
【００１１】
導入された他のユニークな態様は、ウインドウ（窓）のないビデオデータ・パケットである。この態様では、ウインドウを再定義することなく単に再使用されるべきと最初に定義されるウインドサイズを許可することとなる。これは、ビデオデータ・パケットからＸ左フィールド座標及びＸ右、Ｙトップ、Ｙ底、Ｘスタート及びＹスタートフィールド座標を除去することにより実現される。既存のフィールド内のビットは垂直の同期を表わし、データ・スクリーンの第１のラインを特定する。
【００１２】
フレキシブル・サブフレームが効率的に大きなパケットを送信するために導入される。更に、送信パケット中にフレキシブルなビデオ・パケットのいずれかにオプションフィールドがあることを示すフィールドを含むことをフレキシブルなビデオデータ・パケットを開示することにある。
【００１３】
更に新しい態様では、強化されたリバース・リンク・カプセル化パケットが開示されている。この強化されたリバース・リンク・カプセル化パケットは、往復遅延パケットの特徴を単一パケット内の逆カプセル化パケットに組み合わされている。この逆転送の第１部分は、リバース・リンク・データにホストを同期させることを許し、正確に逆データをサンプルする結果となる前触れとなる。逆データの第２の部分はバイトカウントを含んでいる。これは、動的なリバース・リンク帯域幅がクライアントの必要に基づいて割り付けられることを可能にする。ホストは、最大のバイト・フィールドでこの逆データの最大限しきい値を設定することができる。
【００１４】
ここに導入された他の態様には、リンク凍結（フリーズ）がある。これは、ホストによってデータ・ストリームの内のどの時点でもデータ・ストリームの送信を停止させるか凍結することにある。クライアントは、入力されるＭＤＤＩデータ・ストリームを介してクロックオフされ、したがって、ＭＤＤＩリンクを止める結果は、クロックサイクルがもはやクライアント内にもはや存在しないこととなる。このモードに入る場合、ホストは最後に送信されたデータ・ビットに対応する差レベルを維持する。その後、ホストはデータ・ストリームを再開することができる。請求項に記載された現発明の様々な態様、特徴及び効果は、請求項に記載されたこの発明の種々の態様の動作及び構造と同様に下記に図面を参照して詳細に記載される。
【図面の簡単な説明】
【００１５】
【図１】ＭＤＤＩインターフェースを使用している環境例を示すブロック図である。
【図２Ａ】典型的なＭＤＤＩパケット構造を示している。
【図２Ｂ】典型的な前方のリンク構造を示している。
【図３】固定長を備えた従来のサブフレームを示している。
【図４】フレキシブル長のサブフレームを示している。
【図５】無制限長のサブフレームを示している。
【図６】ウインドウを備えないビデオ・ストリーム・パケットを示している。
【図７】フレキシブルなビデオ・ストリーム・パケットを示している。
【図８】機能強化されたリバース・リンク・カプセル化パケットを示している。
【図９】リンク凍結を示してしている。
【詳細な説明】
【００１６】
「例示的」の用語は、「例、実例あるいは実例として役立つ」ことを意味するためにここに使用されている。「例示的」とここに記述されたいずれの態様も、必ずしも他の態様のように好ましく或いは効果的に構成される必要がないことを明記しておくものとする。
【００１７】
記述された態様、また、明細中に「1つの態様」、「ある態様」、「例示的態様」等と参照されることは、記述された態様が特別の特徴、構造あるいは特性を含むかもしれないことを示している。しかし、すべての態様は、必ず特別の特徴、構造あるいは特性をかならずしも含んでいるとは限らないものである。更に、そのような記載は、必ずしも同様な態様を必ず参照するものではない。更に、特別の特徴、構造或いは特性が態様に関して記述される場合、説明的に記載されている或いはいないに拘わらず、他の態様に関連する特徴、構造あるいは特性に影響する技術における当業者の知識内にあるものとする。
【００１８】
モバイル・ディスプレイ・ディジタル・インターフェース（ＭＤＤＩ）は、コスト効率が良く、低い電力消費で、ホストとクライアントの間の短い範囲のコミュニケーション・リンクに亘って高速シリアル・データ転送を可能にするトランスファー・メカニズム（転送機構）を実現している。新しい特徴がここに導入されたことを十分に認識するために、ＭＤＤＩシステムに関して簡潔に下記に説明する。
【００１９】
携帯電話の上部側折り畳み部に格納されているカメラ・モジュールに関するＭＤＤＩの実例を下記に例示することとする。ここで、カメラ・モジュールに対して機能的に等価な特徴を有しているどのようなモジュールであっても、容易に代用することができ、この発明の態様において、使用することができることは、当業者において、明白なことである。
【００２０】
更に、この発明の態様によれば、ＭＤＤＩホストは、クレームされた現発明の使用から恩恵を得ることができるいくつかのタイプの装置のうちの1つを含んでも良い。例えば、ホストは、携帯機器、ラップトップあるいは同様のモバイル・コンピューティング装置の形をしているポータブルコンピューターであっても良い。また、それは、個人用データ・アシスタント（ＰＤＡ）、ページング装置あるいは多くの無線電話あるいはモデムのうちの1つであっても良い。
【００２１】
或いは、ホストは、ポータブルＤＶＤ或いはＣＤプレイヤーのようなポータブル娯楽器又はプレゼンテーション装置、あるいはゲーム装置であっても良い。更に、ホストは、高速コミュニケーション・リンクがクライアントで望まれる、様々な他の広く用いられている商用製品あるいは計画された製品中のホスト装置かコントロール要素として存在することができる。例えば、改良された応答性を与える為に高レートでビデオ録画装置からクライアント用記憶装置まで、或いは、プレゼンテーション用の大きな高解像度スクリーンまでデータを転送する為にホストを使用することができる。オンボード在庫システム或いはオンボード・コンピュータ・システム及び／又は他の家電製品へのブルートゥース接続装置を組み込んだ冷蔵庫のような機器は、インターネット或いはブルートゥース接続モードでの動作時に表示能力を改良することができ、或いは、キャビネット内のいずれに電子計算機或いは制御システム（ホスト側）があっても、扉埋め込み型ディスプレイ（クライアント側）及びキーパッド或いはスキャナ（クライアント側）に必要とされる配線を減少させることができる。一般に、新に追加のコネクターあるいは既存のコネクター、或いは、ケーブルのいずれかにおいて利用可能な制限のある導体数を利用する、より高いデータ・レートでの情報転送を備えるように、当業者は、より古い装置を改造する能力と同様に、このインターフェースの使用から利益を得ることができるかもしれない、現代の電子装置及び器具の広い種類を評価することとなる。また、ＭＤＤＩクライアントは、エンドユーザに情報を提示し、ユーザからホストまで情報を提示するに役立つ様々な装置を含んでも良い。例えば、ゴーグルまたは眼鏡に組み込まれたミクロのディスプレイ、帽子或いはヘルメット中に組み込まれた投影装置、ウインドウ或いはウインドシールドのような車両中に組み込まれたテレビ或いはホログラフィーの要素、又は、高品質音あるいは音楽を提供するヘッドホーンあるいはサウンド・システムを含んでも良い。他のプレゼンテーション装置は、会議のための、あるいは映画及びテレビ・イメージのための情報を提示すために使用されるプロジェクターあるいは投影装置を含んでも良い。他の例には、タッチパッド或いは感知装置、音声認識入力装置、セキュリティ・スキャナ及びユーザからのタッチあるいは音以外の小さな実際の「入力」を与える装置またはシステムのユーザから重要な量情報を転送する要求に応じることができる装置がある。更に、コンピュータ及び自動車キット用ドッキングステーションあるいは無線電話用のデスクトップキット及びホルダーは、エンドユーザへの、あるいは他の装置及び設備へのインターフェース装置の役割を有し、特に高速ネットワークが必要とされるところで、データの転送を助けるためにクライアント(マウスのような出力または入力の装置)あるいはホストのいずれかを使用しても良い。しかしながら、当業者は、クレームされた現発明がこれらの装置に制限されていないことを容易に認識し、また、マーケット上の他の多くの装置であって、記憶装置及び転送の点から、或いは、再生時における表示の点からもエンドユーザに高品質イメージ及びサウンドを提供す���ように意図されている提案された装置に提供することができることは明らかである。クレームされたこの発明は、様々な要素あるいは望ましいユーザ経験の実現に必要とされる高いデータ・レートを提供する装置或いは素子間のデータ処理能力を増加させることにおいて有用となる。
【００２２】
図１は、ＭＤＤＩインターフェースを使用する例を示すブロック図である。この図１の例においては、ＭＤＤＩは、折り畳み電話１００のヒンジを横切ってモジュールを相互結合するに用いられている。クレームされた発明のある態様は、折り畳み電話におけるＭＤＤＩ相互連結のような特定の例として記述されているが、これは、図示の為になされたものであってこの発明をそのような態様に制限するためにのみ使用されるべきでないことは明記しておきます。ここにおける記載に基づいて関連技術分野における当業者によって理解されるように、クレームされた発明の態様は、ＭＤＤＩ相互連結を有することから効果を生ずるかもしれないいずれの他の装置で使用されても良い。
【００２３】
図１を参照して、折り畳み電話１００の下方側折り畳み部１０４は、携帯電話局用モデム（ＭＳＭ）ベースバンド・チップ１０２を含んでいる。ＭＳＭ１０２はディジタル・ベースバンド・コントローラーである。折り畳み電話１００の上部側折り畳み部１１４は、液晶ディスプレイ（ＬＣＤ）モジュール１１６及びカメラ・モジュール１１８を含んでいる。
【００２４】
また、図１を参照すると、ＭＤＤＩリンク１１０は、ＭＳＭ１０２にカメラ・モジュール１１８を接続している。典型的には、ＭＤＤＩリンク・コントローラーは、各々のカメラ・モジュール１１８及びＭＳＭ１０２へ一体化されている。図１の例では、ＭＤＤＩクライアント１０６がＭＤＤＩリンク１１０のＭＳＭ側にある一方、ＭＤＤＩホスト１２２は、カメラ・モジュール１１８に一体化されている。典型的には、ＭＤＤＩホストは、ＭＤＤＩリンクのマスター・コントローラーとなる。図１の例では、カメラ・モジュール１１８からのピクセル・データは、ＭＤＤＩリンク１１０上に送信される前にＭＤＤＩホスト１２２によってＭＤＤＩパケットに受け渡されてフォーマットされる。ＭＤＤＩクライアント１０６は、ＭＤＤＩパケットを受け取り、それらをカメラ・モジュール１１８によって生成された同様のフォーマットのピクセル・データに再変換している。その後、ピクセル・データは、処理のためにＭＳＭ１０２中の適切なブロックに送信される。
【００２５】
また図１を参照すると、ＭＤＤＩリンク１１２は、ＬＣＤモジュール１１６をＭＳＭ１０２に接続している。図１の例では、ＭＤＤＩリンク１１２は、ＬＣＤモジュール１１６に集積化されたＭＤＤＩクライアント１２０及びＭＳＭ１０２に集積化されたＭＤＤＩホスト１０８を相互に連結させている。この図１の例では、ＭＳＭ１０２のグラフィックス・コントローラーによって生成された表示データは、ＭＤＤＩリンク１１２上に送信される前にＭＤＤＩホスト１０８によって受け取られてＭＤＤＩパケットへフォーマットされる。ＭＤＤＩクライアント１２０は、ＭＤＤＩパケットを受け取り、それらをＬＣＤモジュール１１６で使用されるディスプレイ・データに再変換する。
【００２６】
フレーム構造
オリジナルのフレーム構造は、「高いデータ・レート信号転送の為の通信プロトコル及びインターフェースの生成並びに履行」とタイトルが付され、２００４年７月６日に特許された米国特許６，７６０，７７２Ｂ２に記述されている。このオリジナルのパケット構造２００は、図２Ａに示されている。図２Ａの実例中で描かれたフィールドは、典型例では、パケット長フィールド２０２を含んでいないパケット中における全バイト数を特定する１６ビット値のパケット長２０２、パケット２００に含まれる情報のタイプを特定する１６ビットの符号なし整数であるパケット・タイプ２０４、ホスト及びクライアント間に送られるデータのデータ・バイト２０６及びデータ・バイト２０６、パケット・タイプ２０４及びパケット長フィールド２０２に亘って計算された１６ビットサイクルの冗長検査であるＣＲＣ２０８を含んでいる。
【００２７】
図２Ｂに示されるようにＭＤＤＩリンクを通過して送信された情報は、パケットにグループ化される。多数のパケットは、サブフレーム２１０にグループ化され、また、多重化（マルチプル）サブフレームは、メディア・フレーム２１２に作り上げられる。各サブフレーム２１０は、サブフレーム・ヘッダ・パケット２１４から始まっている。
【００２８】
図３は、固定長を備えた従来技術のサブフレームを示している。この図３には、サブフレーム・ヘッダ・パケット２１４、埋め込みパケット２１８が後続するパケット・データ２１６、及びサブフレーム境界２２０が示されている。図に示されるように、保留中の流出パケット222がサブフレーム218の残存部分内に適合することができない程大きすぎるときに問題が生ずる。次のサブフレームが転送されるまで、保留流出パケット222は、待ちのままとされなければならない。代わりに、埋め込みパケットは、現サブフレームの存続の為に送信される。このことは、帯域幅を浪費し、不必要に補助的な電力を消費することとなる。下に記述される新なフレーム構造は、'772特許に開示されるのと同一モードで作動させることができる。しかしながら、'772特許とは異なり、サブフレーム長及びタイミングの定義を改変した２つの新な動作モードを提案してパフォーマンスを改善している。下記のリストに記載された２つの動作モードは、サブフレーム・ヘッダ・パケット内に含まれているプロトコル・バージョン・フィールドと同一である。ホストにハード的配線をされていないクライアント装置については、互換性を保証するように、ＭＤＤＩリンクが提示されて、クライアントが下記に導入された新しいフレーム構造をサポートすることができるかの確認を従来技術のフレーム構造に最初に附加される。一度確認されると、ホストは新しいフレーム構造に移ることができる。これはすべて、最初のサブフレームでなされて下記に記述された２つのフォーマットのいずれかへの迅速な推移を提供することができる。
【００２９】
フレキシブル・サブフレーム長
図４に示されるように、第１のオペレーション・モードは、「フレキシブル」サブフレーム長を与えている。フレキシブル長のサブフレーム３００は、サブフレーム・ヘッダ・パケット３０４、パケット・データ３１６及び識別されるサブフレーム境界３２０を有している。フレキシブル長のサブフレーム３００では、サブフレーム境界３２０でサブフレーム・ヘッダ・パケット３０４が送られる。パケットが送信されることが要求される時、パケットが１つ以上のサブフレーム境界３２０を横切っても、パケットは、ブロックされることはない。このオペレーションのモードは、ＭＤＤＩホストに対してロールオーバー・データ３２２を含み、サブフレーム長フィールドで伝送される多数のバイトが全て整えられた後の次の利用可能な機会に次のサブフレーム・ヘッダ・パケット３０４を送信することを許可している。このオペレーション・モードの利点は、第１のサブフレームの転送の終わりでデータが利用される場合、パケットが２つのサブフレーム間でスプリットされる必要もないことにある。同様に、現サブフレームで適合されずに残されたバイトにおけるパケットのために次のサブフレームが送信されるまで遅れることを防止することとなる。現在のパケットが、パケット・エンド３２４で特定されるサブフレーム長に亘って現パケットが現サブフレーム中で全バイト数を転送させた後にサブフレーム・ヘッダ・パケット３０４は、最初のパケットを転送させるべきである。この方法は、完全な信頼のない送信リンクに対して再同期ポイントを与えるサブフレーム・ヘッダ・パケット３０４を提供することとなる。長いサブフレームの後のサブフレームで送られたテキストは、前の長いサブフレームが超えた量だけ短くされて平均サブフレーム長さを作成している。フレキシブル・サブフレーム長の概念は、図３に示される固定サブフレーム長システムのサブフレームタイミングに類似されるように平均化されるタイミングを維持すべきであるが、パケットの送信を妨げず、また、帯域幅を浪費してはならない。
【００３０】
無制限なサブフレーム長
図５に示されるように、この第２の動作モードは、ホストに対してアクティブＭＤＤＩリンクがある間にただ１つのサブフレームの使用を許可している。このことは、リンクが休眠状態から脱し、それ以上送信しないときに、ＭＤＤＩホストがただ１つのサブフレーム・ヘッダ・パケット４０４を送信することを意味している。この動作モードへの利点は、他のサブフレーム・ヘッダ・パケットを送信するために使用される付加的な帯域幅がないことにある。この動作モードにある間に、サブフレーム・ヘッダ・パケットを送信することが許容されたままにあり、再同期が許されている。しかしながら、これらのパケット間のバイトの数は、任意とされ、ＭＤＤＩホストにおける判別で送信されることとなる。
【００３１】
ウインドウのないビデオ・ストリーム・パケット
ウインドウのないビデオ・ストリーム・パケットは、ビデオ・パケットから省かれる情報をウインドウ化すること許している。従来バージョンのビデオ・ストリーム・パケットにおけるウインドウ化情報は、Ｘ左端、Ｙ最上端、Ｘ右端、Ｙ最下端、Ｘ始点及びＹ始点を含んでいる。図６は、ウインドウのないビデオ・ストリーム・パケットを示している。図から明らかなように、属性のいくつかは、従来技術に係るビデオ・ストリーム・パケットに類似している。ウインドウのないビデオ・ストリーム・パケット５００は、バイトの総数、ウインドウのないビデオ・ストリーム・パケット５００においては、２バイトをマイナスしたバイト総数を指定する１６ビットの整数を含む２バイトを含んでいるパケット長５０２を含んでいる。パケット・タイプ５０４は、２バイトでパケットのタイプを特定する１６ビット整数を含んでいる２バイトから成っている。この例においては、ウインドウのないビデオ・ストリーム・パケット５００のオペレーションのためにパケット・タイプが２２として特定されている。次に、ｂクライアントＩＤ５０６のフィールドが示されている。これらは、クライアントＩＤの識別のために１６ビットの符号なしの整数を含んでいる２バイトである。次に、ビデオデータ・フォーマット・ディスクリプタ５０８がある。このビデオデータ・フォーマット・ディスクリプタ５０８は、新なフレームの開始の為の情報を与え、これは、２バイト、１６ビットの符号なしの整数である。次に、ピクセル・データ５１０がある。これは、ピクセル・データの様々な属性を特定する２バイト、１６ビットの符号なしの整数である。ピクセル・カウント５１２は、ピクセル・データ５１６のフィールドにおいてピクセル数を特定する２バイト、１６ビットの符号なしの整数を含んでいる。パラメーターＣＲＣ５１４は、パケット長５０２からピクセル・カウント５１２までのすべてのバイトの１６ビットＣＲＣを含む２バイトで構成される。ピクセル・データ５１６は、表示される純粋なビデオ情報を含んでいる。ピクセル・データＣＲＣ５１８は、ピクセル・データ５１６だけの１６ビットＣＲＣを含んでいる２バイトで構成される。ディスプレイ領域全体が絶えずリフレッシュされる場合、このパケットは動作モードのために使用される。
【００３２】
フレキシブルなビデオ・ストリーム・パケット
図７に示されるフレキシブルなビデオ・ストリーム・パケットは、フィールド・プリゼント・ビットを含んでいるビデオ・ストリーム・パケット内にいずれのフィールドが含まれるかを特定する方法を与えている。このフィールド内の各ビットは、パケットが対応するフィールドを含むか否かを示している。フィールドがパケットに含まれていない場合、値は、フィールドがビデオ・パケット中で送信された最後の時と同じのままであるべきであると仮定されている。そのフィールドが以前に送信されていない場合、値は０であると仮定することができる。
【００３３】
フレキシブルなビデオ・ストリーム・パケット６００は次のようなパケット・コンテンツを有している。
【００３４】
パケット長６０２は、パケット長フィールドに含まれないパケット中における総バイト数を指定する１６ビットの符号なしの整数を含んでいる２バイトから構成される。この値は、いずれのパケットが含まれることとなるかと同様にピクセル・データ・サイズに依存することとなる。
【００３５】
パケット・タイプ６０４は、１６ビットの符号なしの整数を含んでいる２バイトから構成される。この例においては、パケット・タイプの１７は、パケットをフレキシブルなビデオ・ストリーム・パケット６００である旨を特定している。
【００３６】
次のフィールドは、クライアントＩＤのために設けられた１６ビットの符号なしの整数を含んでいる２バイトから構成されるｂクライアントＩＤ６０６となる。
【００３７】
フィールド・プリゼント・ビット６０８で、各ビットに対する値が「１」であれば、フィールドがパケットの中にあることを示している。また、各ビットに対する値が「０」であれば、フィールドが存在しないことを示している。図７に示されるように、フィールドが配列されている。
【００３８】
ビデオデータ・フォーマット・ディスクリプタ６１０は、新たなフレームの開始に対する情報を与え、２バイト、１６ビットの符号なしの整数とされる。次のピクセル・データ属性６１２は、ピクセル・データの様々な属性を特定する２バイト、１６ビットの符号なしの整数とされる。Ｘ左端６１４は、ピクセル・データ６３２のフィールドに充填されたスクリーン・ウィンドウの左端のＸ座標を特定する１６ビットの符号なしの整数を含む２バイトで構成されている。Ｙ最上端６１６は、ピクセル・データ６３２のフィールドに充填されたスクリーン・ウィンドウの最上端のＹ座標を特定する１６ビットの符号なしの整数を含む２バイトで構成される。Ｘ右端６１８は、ピクセル・データ６３２フィールドに充填されたスクリーン・ウィンドウの右端のＸ座標を特定する１６ビットの符号なしの整数を含む２バイトで構成されている。Ｙ下端６２０は、ピクセル・データ６３２のフィールドに充填されたスクリーン・ウィンドウの下端のＹ座標を特定する１６ビットの符号なしの整数を含む２バイトで構成される。Ｘ始点６２２は、絶対Ｘ座標を特定する１６ビットの符号なしの整数を含む２バイトで構成されている。ここで、ポイント（Ｘ始点６２２及びＹ始点６２４）は、ピクセル・データ６３２のフィールドにおける最初のピクセルの点である。Ｙ始点６２４は、絶対Ｙ座標を特定する１６ビットの符号なしの整数を含む２バイトで構成されている。ここで、ポイント（Ｘ始点６２２及びＹ始点６２４）は、ピクセル・データ６３２のフィールドにおいて最初のピクセルの点である。
【００３９】
ピクセル・カウント６２８は、ピクセル・データ６３２のフィールドに中のピクセル数を特定する２バイト、１６ビットの符号なしの整数で構成される。パラメーターＣＲＣ６３０は、パケット長６０２からちょうどこのパラメーターＣＲＣ６３０に先立って送信されたバイトまでのすべてのバイトの１６ビットのＣＲＣを含んでいる２バイトから構成される。ピクセル・データ６３２は、表示される純粋なビデオ情報を含んでいる。この例においては、ピクセル・データ属性のフィールドのビット５が１にセットされれば、ピクセル・データ６３２のフィールドは、正確に１列のピクセルを含むこととなる。ここで、送信された第１のピクセルは、左端のピクセルに相当します。また、送信された最後のピクセルは、右端のピクセルに相当します。
【００４０】
ピクセル・データＣＲＣ６３４は、ピクセル・データ６３２のみの１６ビットＣＲＣを含んでいる２バイトから構成される。
【００４１】
機能強化されたリバース・リンク・カプセル化パケット
機能強化されたリバース・リンク・カプセル化パケットは、図８に示されている。このパケットは、ＭＤＤＩシステムの先のバージョンに記述されるように、クライアントからホストまでデータを転送するために使用されるリバース・リンク・カプセル化パケットを備える到達データ・ストリームに対してホストを調整させることを助けるために往復トリップ遅れ測定パケット(round trip delay measurement packet)の機能を組み合わせている。このパケットは、同期パターンを使用して到達バイト・データの整列を見出している。同期パターンが到達データ・ストリームで見出されると、ホストは、確実に残るリバース・リンク・データ・ビットをサンプリングしてリバース・リンク・データ及びパケット・ストリームを統合する。
【００４２】
機能強化されたリバース・リンク・カプセル化パケット７００のパケット・コンテンツは、以下の通りである。
【００４３】
パケット長７０２は、パケット長７０２のフィールドを含まないパケット中の総バイト数を特定する１６ビットの符号なしの整数を含む２バイトから構成される。
【００４４】
パケット・タイプ７０４は、１６ビットの符号なしの整数を含んでいる２バイトから構成されている。この例において、パケット・タイプ７０４が８４であることは、パケットを機能強化されたリバース・リンク・カプセル化パケット７００であると特定している。
【００４５】
次のフィールドは、クライアントＩＤのために予約された１６ビットの符号なしの整数を含んでいる２バイトから構成されるｈクライアントＩＤ７０６である。
【００４６】
リバース・リンク・フラグ７０８は、クライアントに情報を要請し、かつリバース・リンク・インターフェース・タイプを特定するために１セットのフラグを含んでいる８ビットの符号なしの整数を含む１バイトから構成される。この例において、ビットが１にセットされる場合、ホストはクライアントに指定された情報を要請する。ビットがそのとき０である場合、ホストは、クライアントからの情報を必要としないこととなる。例えば、ビット０は、ホストがクライアント能力パケットを必要とすることを示すとすることができる。それは、リバース・データ・パケット７２４のフィールドにおいて、クライアントによってホストに送られる。ビット１は、ホストがクライアント・リクエスト及びステータス・パケットを必要とすることを示すことができる。それは、リバース・データ・パケット７２４のフィールドにおいて、クライアントによってホストに送られる。ビット２は、リバース・リンク・パケット７２４の第１のデータ・バイトを送信する前に同期バイトを送信するために、ホストがクライアントを必要とすることを示すことができる。ビット３は、ホストがリバース・パケット送信を始める前に期待するべきリバース・バイトの量を送信することをクライアントに要求することを示すことがでる。これは、クライアントの要求に正確に合致させる動的サイズのリバース・リンク・パケットに対して現継続中のリバース・リンク・データをアップデートさせること許している。
【００４７】
リバース・レイト除数７１０は、リバース・リンク・データ・クロックの単位で生じるＭＤＤＩ＿Ｓｔｂサイクルの数を特定する８ビットの符号なしの整数を含んでいる１バイトから構成される。リバース・リンク・データ・クロックは、２回のリバース・レイト除数７１０としての量で割られた前方のリンク・データ・クロックと等しい。リバース・リンク・データ・レートは、次の例におけるリバース・リンク上のリバース・リンク・データ・クロック及びインターフェース・タイプに関係がある。
【００４８】
インターフェース・タイプ１は、リバース・データ・レートがリバース・リンク・データ・クロックと等しいことを示している。
【００４９】
インターフェース・タイプ２は、リバース・データ・レートが２回のリバース・リンク・データ・クロックと等しいことを示している。
【００５０】
インターフェース・タイプ３は、リバース・データ・レートが４回のリバース・リンク・データ・クロックと等しいことを示している。
【００５１】
そして、
インターフェース・タイプ４は、リバース・データ・レートが８回のリバース・リンク・データ・クロックと等しいことを示している。
【００５２】
第１転換の長さ７１２は、第１転換に配分されるバイトの総数を特定する８ビットの符号なしの整数を含んでいる１バイトから構成される。
【００５３】
第１転換の推奨長さは、ホスト内のＭＤＤＩデータ・ドライバにそれらの出力を不能にするのに必要なバイトの数とされる。これは、出力不能時間、フォワード・リンク・データ・レート及び使用されているフォワード・リンク・インターフェース・タイプ・セレクションに基づいている。第２転換の長さ７１４は、第２転換に分配されるバイトの総数を特定する８ビットの符号なしの整数を含む１バイトから構成される。第２転換の推奨長さは、ホストに対してＭＤＤＩデータ・ドライバを可能にするに必要な時間を加えた往復の遅れのために必要とされるバイト数である。第２転換の長さは、ホストにおいてリバース・リンク・パケットを処理する十分な時間を許すように計算された必要とされる最小値よりも大きな任意の値であっても良い。最大のリバース・バイト７１６は、どれだけのリバース・バイトがクライアントからホストに送信されかを示す２バイトで構成される。これは、同期パターン或いはリバース・リンク・フラッグ７０８のフィールド中のビットで要求された際にリバース・リンク・データに先行するかもしれないクライアント転送バイト長のフィールドのような任意に必要とされるバイトを含んでいない。ビット３がセットされる場合、クライアントは、最大リバース・バイト７１６のフィールドにおける値よりも小さいあるデータを送ることを要求するかもしれない。クライアントが最大リバース・バイト７１６のフィールドよりも小さい数を送信する時、ＭＤＤＩは、クライアント・リクエストを最大限にするためにリバース・データ及び同期７２４フィールドの予期される期間を短くする。パラメーターＣＲＣ７１８は、パケット長７０２から方向転換長７１２及び最大リバース・バイト７１６に至る１６ビットＣＲＣの全バイトを含む２バイトで構成される。このＣＲＣがチェックに失敗にしたならば、全パケットは、廃棄される。全ゼロ１７２０は、０に等しい８ビットの符号なしの整数を各々含んでいる８バイトから構成される。このフィールドは、ＭＤＤＩデータ信号が十分な時間の間、論理レベルゼロであればクライアントに対して方向転回１７２２のフィールドの間ホスト・ライン・ドライバを不能にするに先立ってＭＤＤＩ＿Ｓｔｂのみを用いる回復クロックを開始させることを保証している。第１転換７２２は、第１の方向転換期間から構成されている。第１転換長７１２のパラメーターによって特定されるバイト数は、配分されてホストに対するライン・ドライバが無効になる前にクライアントにおけるＭＤＤＩデータ・ライン・ドライバが動作可能としている。第１転換７２２のビットがビット０である間にクライアントがＭＤＤＩデータ・ライン・ドライバを動作可能とし、ホストがその出力を可能とするとともに第１転換７２２の最終ビットに先立って完全に動作不能とされる。ＭＤＤＩ＿Ｓｔｂ信号は、あたかもＭＤＤＩデータ（）が第１転換７２２の全ての期間の間、論理ゼロレベルであったが如くに振る舞うこととなる。
【００５４】
リバース同期、バイトカウント及びデータ・パケット７２４は、図８において、一つのフィールドとして示されている。もし２つのビットによって要求されてリバース・リンク・フラッグ７０８のフィールドにおいて論理１が設定されたならば、このフィールの第１のバイトは、同期パターン（０ｘ０５３Ｆ）となるべきとされている。３つのビットがセットされる場合、次に送信されるリバース・リンク・フィールドは、クライアントがリバース・リンクに送信するバイトの数であるべきとされている。このデータが要求されない場合、クライアントは、最大リバース・バイト７１６のフィールドで特定されたバイトの数までのリバース・リンク・データを送信することができる。第１のリバース・リンク・パケットのパケット長のフィールドにこのフィールドが続くべきとされている。十分な余地がある場合、１つ以上のパケットをリバース・データ期間中に送信することができる。ホストに送るデータを持っていない場合、クライアントは論理ゼロレベルに埋め込みパケットを送るか、あるいはＭＤＤＩデータ・ラインを駆動するするかもしれない。ＭＤＤＩデータ・ラインがゼロで動作される場合、ホストは、このことをゼロ長さ（有効な長さでない）を備えたパケットと解釈することとなり、また、ホストは、現機能強化されたリバース・リンク・カプセル化パケット７００がある間クライアントから何ら付加パケットを受理しないことを受け入れることとなる。第２転換７２６は、第２の方向転換期間から構成される。バイトの数は、第２転換の長さ７１４のパラメーターによって特定される。ホストは、ＭＤＤＩデータ・ライン・ドライバを動作可能として第２転換７２６の最後のビットに先立って完全に動作可能となる。また、クライアントは、その出力を不能にし、第２転換７２６の最後のビットに先立って完全に動作不能とされる。第２転換７２６の目的は、リバース・データ・パケット７２４のフィールドからの残りの量のデータが、クライアントから送信されることを可能にすることにある。異なるシステムにおける変化及び割り振られた安全性の限界の量に基づいて、ホスト側でのライン・レシーバーで見られるように方向転回２７２６のある部分の間、ホストのみならずクライアントもＭＤＤＩデータ信号を論理ゼロレベルで駆動させることはないこととなる。あたかもＭＤＤＩ＿Ｄａｔａ０が第２転換７２６の期間の間論理ゼロのレベルにあるかのように、ＭＤＤＩ＿Ｓｔｂ信号は、振る舞うこととなる。全ての２つのゼロ２７２８は、夫々がゼロに等しい８ビットの符号なしの整数を含んでいる８バイトで構成される。このフィールドは、全てのＭＤＤＩ＿Ｄａｔａ信号が十分な時間の間論理ゼロレベルであり、クライアントに対して第２転換７２６に続くホスト・ライン・ドライバを動作可能とした後にＭＤＤＩ＿Ｄａｔａ０及びＭＤＤＩ＿Ｓｔｂの両方を使用してクロックの回復を開始させることを許すこととなる。
【００５５】
ＭＤＤＩリンク凍結
それがＭＤＤＩデータリンクを停止させる必要があるかリンクのオペレーションを休止する必要がある時をＭＤＤＩホストが見出しても良い。図９は、クレームされた発明のリンク凍結態様を示している。図９は、ＭＤＤＩデータ９００、ストロボ（ＳＴＢ）９０２及び回復されたクロック９０４を示している。この態様は、ＭＤＤＩデータ９００が時間９０６の短期のために止められ、ＭＤＤＩクライアントの現状を凍結することを可能にしている。クライアントにおける回復されたクロック９０４は、入って来るＭＤＤＩデータ９００及びＭＤＤＩストロボ９０２から引き出され、その結果、ＭＤＤＩリンクを止めることは、クライアント側においても判るようにいずれのクロックも止めることとなる。このモードを入れる場合、ホストは、最後に送信されたデータ・ビットに対応する差異レベルを維持しなければならなくなる。ＭＤＤＩホストは、それがこのモードに入り、必要ならば出現パケットの最中のリンクを凍結しても良いことを示す特別なパケットも送信することは要求されない。これは、他のデータ・ソースが出現ＭＤＤＩデータ・ストリームに簡単に維持できない場合に、ＭＤＤＩホストの設計内におけるアンダーフローを防ぐために使用することができる。
【００５６】
ＭＤＤＩデータ９００及びストロボ９０２信号を駆動させ続けるための付加的な電力消費が原因で、この状態は、短い持続状況の中のみで使用されるべきとされる。より長期間の間意味のある内容を送信してはならない場合、休眠状態モードは、電力消費を最小に維持するために使用されるべきとされる。
【００５７】
多くのクライアントでは、至来パケットを解読するための処理パイプライン遅れが生ずる。パケットがホストから送信された直後に、ＭＤＤＩを区画することは、クライアントの要求を満たしていないこととなる。また、クライアントは、最後のパケット内に含まれていたデータを処理する機会を得ているべきあるとされる。
【００５８】
ＭＤＤＩクライアントから来る信号は、更にクロックの不足により特別の状態で冷凍される。ＭＤＤＩの使用をクライアントにするどんな設計も、この条件の可能性を認識していることとなる。
【００５９】
この明細書は、要求された発明の特徴を組込む１つ以上の態様を示している。ここに示された態様は単にクレームされた発明を例証すぎない。クレームされた発明の範囲は示された態様に制限されない。その発明はここに追加されたクレームによって定義される。
【００６０】
当業者は、情報と信号が様々な異なる技術及び技術のうちのどれでも使用して表わされるかもしれないと理解することとなる。例えば、上記の記述の全体にわたって参照が付けられるかもしれないデータ、指示、コマンド、情報、信号、ビット、シンボル及びチップは、電圧、電流、電磁波、磁界、粒子、光学分野、粒子、あるいはそれの任意のコンビネーションによって表わされるかもしれない。
【００６１】
当業者は、両方の電子ハードウェア、コンピューターソフトあるいはコンビネーションとして様々な実例となる論理的なブロック、モジュール、回路、及びここに示された具体化に関して記述されたアルゴリズム・ステップがインプリメントされるかもしれないことを更に認識することとなる。明白にハードウェアとソフトウェアのこの互換性を例証するために、様々な実例となるコンポーネント、ブロック、モジュール、回路及びステップは、それらの機能性の点から一般に上述するように説明されている。ハードウェアまたはソフトウェアが全面的なシステムに課された特別の適用及び設計制約に依存するとともに、そのような機能性がインプリメントされている。熟練した職人は個々の特別の適用の方法を変える際に記述された機能性をインプリメントしても良い。しかし、そのようなインプリメンテーション決定は現在の発明の範囲からの出発を引き起こすとは解釈されるべきではない。
【００６２】
様々な実例となる論理的なブロック、モジュール、及びここに示された具体化に関して記述された回路は、一般的な目的プロセッサー、デジタル信号プロセサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドのプログラム可能なゲート・アレイ（ＦＰＧＡ）あるいは他のプログラム可能なロジック装置、ディスクリートゲート或いはトランジスター・ロジック、ディスクリートハードウエア或いはこれらの組み合わせでインプリメントされるかもしれず、また、実施されるかもしれない。一般的な目的プロセッサーはマイクロプロセッサーかもしれません。しかし、代案では、プロセッサーは任意の従来のプロセッサー、コントローラー、マイクロコントローラあるいはステートマシンかもしれない。プロセッサーも、計算する装置、例えばＤＳＰとマイクロプロセッサーのコンビネーション、多くのマイクロプロセッサー、ＤＳＰコアと協働する１個以上のマイクロプロセッサーあるいは他のそのような構成のコンビネーションとしてインプリメントされるかもしれません。
【００６３】
ここに示された具体化に関して記述された方法かアルゴリズムのステップは、ハードウェア、プロセッサーによって実行されたソフトウェア・モジュール、あるいは２つのコンビネーションで直接具体化されるかもしれない。ソフトウェア・モジュールはランダム・アクセス・メモリー（ＲＡＭ）に存在するかもしれず、フラッシュ・メモリー、読み出し専用メモリ、電気的にプログラマブルなＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なプログラマブル（ＥＥＰＲＯＭ）、レジスター、ハードディスク、消去可能なディスク、ＣＤ−ＲＯＭ（ＥＥＰＲＯＭ）、あるいは当技術中で既知の記憶ミディアムの他の形式に設けられても良い。典型的な記憶ミディアムはプロセッサーにつながれ、プロセッサーが情報を読むことができるそのようなもの、また情報を書く記憶ミディアムであっても良い。代案では、記憶ミディアムはプロセッサーに不可欠かもしれない。プロセッサー及び記憶ミディアムはＡＳＩＣに存在するかもしれない。ＡＳＩＣはユーザ・ターミナルに存在するかもしれない。変更例では、プロセッサー及び記憶ミディアムはユーザ・ターミナルの個別のコンポーネントとして存在するかもしれない。
【００６４】
上述した実施例の記述は、当業者に対して現発明を行なうか使用することを可能にするために提供されている。これらの具体化への様々な修正は、当業者に容易に明白となるものである。また、ここに定義された総括的な法則は、発明の精神か範囲から外れずに、他の具体化に適用されるかもしれないことを明記しておきます。したがって、現発明は、ここに示された具体化に制限されたようには意図されず、ここに示された法則と新規な特徴と一致する最も広い範囲を与えられることとなる。
【図１】
2010533388.tif 000003
【図２Ａ】
2010533388.tif 000004
【図２Ｂ】
2010533388.tif 000005
【図３】
2010533388.tif 000006
【図４】
2010533388.tif 000007
【図５】
2010533388.tif 000008
【図６】
2010533388.tif 000009
【図７】
2010533388.tif 000010
【図８】
2010533388.tif 000011
【図９】
2010533388.tif 000012