(57)【要約】【課題】ヘッダが特定の条件で不正な場合には、正常に受信したペイロードを保持してヘッダのみが再送される場合に対応するための回路構成の増加を抑制すること。【解決手段】本発明にかかるデバイス装置は、ホスト装置から受信した第１のパケットの第１のヘッダに所定のエラーが含まれる場合、当該第１のヘッダを破棄し、当該第１のパケットの第１のペイロードを後段へ送信する第１の処理部と、第１の処理部から受信した第１のペイロードを破棄し、第１のパケットの再送要求をホスト装置へ送信する第２の処理部と、を備える。【選択図】図５
2018045417.tif 000002
【特許請求の範囲】
【請求項１】
ホスト装置から受信した第１のパケットの第１のヘッダに所定のエラーが含まれる場合、当該第１のヘッダを破棄し、当該第１のパケットの第１のペイロードを後段へ送信する第１の処理部と、
前記第１の処理部から受信した前記第１のペイロードを破棄し、前記第１のパケットの再送要求を前記ホスト装置へ送信する第２の処理部と、
を備えるデバイス装置。
【請求項２】
前記第１の処理部は、前記第１のヘッダを破棄した際に、疑似的な正常受信応答を前記ホスト装置へ送信し、
前記第２の処理部は、前記第１のペイロードを破棄すると共に、前記第１のパケットの再送要求を前記ホスト装置へ送信する
請求項１に記載のデバイス装置。
【請求項３】
前記第１の処理部は、
前記第１のヘッダに前記所定のエラーが含まれる場合、当該第１のヘッダの再送要求を前記ホスト装置へ送信し、
前記ホスト装置から前記第１のヘッダの再送要求に応じたペイロードなしの第２のパケットの第２のヘッダを受信し、
前記受信した第２のヘッダが正常な場合に、当該第２のヘッダを前記第２の処理部へ送信し、
前記第２の処理部は、
前記第１の処理部から前記第２のヘッダを受信した場合に、前記第１のパケットの再送要求を前記ホスト装置へ送信する
請求項１に記載のデバイス装置。
【請求項４】
前記第１の処理部は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）３．１  Ｇｅｎ２に対応するリンク層であり、
前記第２の処理部は、ＵＳＢ３．１  Ｇｅｎ２に対応するプロトコル層である、
請求項１に記載のデバイス装置。
【請求項５】
前記所定のエラーは、前記第１のヘッダのＣＲＣがエラー値、かつ、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａ領域が正常値である、
請求項４に記載のデバイス装置。
【請求項６】
請求項３に記載のデバイス装置に前記第１のパケットを送信するホスト装置であって、
前記第１の処理部からの前記第１のヘッダの再送要求を受信した場合に、前記第１のペイロードの送信を中止し、前記第２のパケットの送信を開始する
ホスト装置。
【請求項７】
前記ホスト装置は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）３．１  Ｇｅｎ２に対応する
請求項６に記載のホスト装置。
【請求項８】
第１のパケットを送信するホスト装置と、
前記ホスト装置から前記第１のパケットを受信するデバイス装置と、を備え、
前記デバイス装置は、
前記第１のパケットの第１のヘッダに所定のエラーが含まれる場合、当該第１のヘッダを破棄し、当該第１のパケットの第１のペイロードを後段へ送信する第１の処理部と、
前記第１の処理部から受信した前記第１のペイロードを破棄し、前記第１のパケットの再送要求を前記ホスト装置へ送信する第２の処理部と、
を備える、データ転送システム。
【請求項９】
前記ホスト装置は、
前記第１の処理部からの前記第１のヘッダの再送要求を受信した場合に、前記第１のペイロードの送信を中止し、ペイロードなしの第２のパケットの送信を開始する
請求項８に記載のデータ転送システム。
【請求項１０】
ホスト装置からデバイス装置へデータ転送を行うデータ転送方法であって、
前記デバイス装置の第１の処理部において、前記ホスト装置から受信した第１のパケットの第１のヘッダに所定のエラーが含まれる場合、当該第１のヘッダを破棄し、当該第１のパケットの第１のペイロードを後段へ送信し、
前記第１の処理部の後段の第２の処理部において、前記第１の処理部から受信した前記第１のペイロードを破棄し、前記第１のパケットの再送要求を前記ホスト装置へ送信する、
データ転送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイス装置、データ転送システム及びデータ転送方法に関し、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）３．１  Ｇｅｎ２に対応するデバイス装置、データ転送システム及びデータ転送方法に関する。
【背景技術】
【０００２】
ＵＳＢ３．１  Ｇｅｎ１（ＵＳＢ３．０）のＯＵＴ転送におけるデータパケット（Ｄａｔａ  Ｐａｃｋｅｔ（ＤＰ））は、データパケットヘッダ（Ｄａｔａ  Ｐａｃｋｅｔ  Ｈｅａｄｅｒ（ＤＰＨ））とデータパケットペイロード（Ｄａｔａ  Ｐａｃｋｅｔ  Ｐａｙｌｏａｄ（ＤＰＰ））の２つのパケットで構成されている。そして、ＤＰの転送は、ＤＰＨ、ＤＰＰの順序で行われる。
【０００３】
ここで、ＵＳＢ３．１  Ｇｅｎ１では、ＤＰＨに何らかのパケットエラーが発生した場合、ＵＳＢデバイス装置のリンク層にてＤＰＨ及びＤＰＰの組を破棄する。そのため、ＵＳＢデバイス装置のプロトコル層は、エラーにかかるパケットを受信することがなかったため、プロトコル層においてパケットエラー時の処理は不要であった。
【０００４】
また、後続の仕様であるＵＳＢ３．１  Ｇｅｎ２では、ＤＰＨにＬｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域が追加された。そして、ＤＰＨ内のＣＲＣ値がエラー、かつ、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域が正常値である場合、リンク層でＤＰＨのみを破棄し、対応するＤＰＰをプロトコル層に送るように規格が変更された（非特許文献１）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Universal Serial Bus 3.1 Specification Revision.1.0, Chapter 7 and 8
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、非特許文献１では、ＤＰＨが特定の条件で不正な場合には、正常に受信したＤＰＰを保持してＤＰＨのみが再送される場合に対応するための回路構成が必要となるという問題点があった。
【０００７】
その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【０００８】
一実施の形態によれば、デバイス装置は、ホスト装置から受信したパケットのヘッダに所定のエラーが含まれる場合、ヘッダを破棄し、ペイロードを後段へ送信する第１の処理部と、受信したペイロードを破棄し、パケットの再送要求をホスト装置へ送信する第２の処理部と、を備える。
【発明の効果】
【０００９】
前記一実施の形態によれば、回路面積の増加を抑制することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施の形態１にかかるホスト装置とデバイス装置の構成を示すブロック図である。
【図２】本実施の形態１にかかるリンク層におけるＤＰＨ受信処理の流れを説明するためのフローチャートである。
【図３】本実施の形態１にかかるプロトコル層におけるＤＰＨ受信処理の流れを説明するためのフローチャートである。
【図４】本実施の形態１にかかるプロトコル層におけるＤＰＰ受信処理の流れを説明するためのフローチャートである。
【図５】本実施の形態１にかかるＤＰＨに所定のエラーが発生した場合の各層の処理の流れを示すシーケンス図である。
【図６】本実施の形態２にかかるリンク層におけるＤＰＨ受信処理の流れを説明するためのフローチャートである。
【図７】本実施の形態２にかかるプロトコル層におけるＤＰＰ受信処理の流れを説明するためのフローチャートである。
【図８】本実施の形態２にかかるＤＰＨに所定のエラーが発生した場合の各層の処理の流れを示すシーケンス図である。
【図９】本実施の形態３にかかるホスト装置におけるＤＰ送信処理の流れを説明するためのフローチャートである。
【図１０】本実施の形態３にかかるＤＰＨに所定のエラーが発生した場合の各層の処理の流れを示すシーケンス図である。
【図１１】本実施の形態４にかかるリンク層におけるＤＰＰ受信処理の流れを説明するためのフローチャートである。
【図１２】本実施の形態４にかかるＤＰＨとＤＰＰの受信順序が逆の場合の各層の処理の流れを示すシーケンス図である。
【図１３】ＵＳＢ３．１  Ｇｅｎ１においてＤＰＨにＣＲＣエラーが発生した場合の各層の処理の流れを示すシーケンス図である。
【図１４】ＵＳＢ３．１  Ｇｅｎ２において一般的な実装を行った際に、ＤＰＨに所定のエラーが発生した場合の各層の処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【００１１】
以下では、上述した課題を解決するための手段を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
【００１２】
以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、応用例、詳細説明、補足説明等の関係にある。また、以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。
【００１３】
さらに、以下の実施の形態において、その構成要素（動作ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではない。同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数等（個数、数値、量、範囲等を含む）についても同様である。
【００１４】
ここで、以下の実施の形態を想到するに至った経緯について説明する。まず、以前の規格であるＵＳＢ３．１  Ｇｅｎ１においてＤＰＨにＣＲＣエラーが発生した場合の各層の処理の流れを図１３のシーケンス図を用いて説明する。ここでは、ＵＳＢ３．１  Ｇｅｎ１におけるＢｕｌｋ  ＯＵＴ転送の途中からの動作を示している。すなわち、デバイス装置は、ホスト装置から送信されたシーケンス番号（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ（Ｓｎｕｍ））＝Ｘ−１までのＤＰを正常に受信済みであるものとする。
【００１５】
そこで、まず、デバイス装置のプロトコル層は、ＡＣＫ（Ｓｎｕｍ＝Ｘ）をホスト装置へ送信する。これに応じて、ホスト装置は、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置へ送信する。そして、デバイス装置では、物理層及びリンク層にてＳｎｕｍ＝ＸのＤＰＨを受信する。この時、受信したＤＰＨにおいてＣＲＣエラーが検出されたものとする。そこで、ＵＳＢ３．１  Ｇｅｎ１におけるリンク層は、ＤＰＨを破棄し、併せて、ＤＰＨの後に受信するＳｎｕｍ＝ＸのＤＰＰを破棄する。このとき、当該リンク層は、後段のプロトコル層へＳｎｕｍ＝ＸのＤＰＨ及びＤＰＰを転送しない。また、当該リンク層は、ＤＰＨの再送要求としてＬＢＡＤコマンドをホスト装置に対して送信する。
【００１６】
ホスト装置は、ＬＢＡＤコマンドの受信に応じてＬＲＴＹコマンドをデバイス装置に対して送信する。ここで、デバイス装置は、ホスト装置からＬＲＴＹコマンドを受信するまで、ホスト装置から送信されるデータを無視する。ホスト装置は、ＬＲＴＹコマンドの送信後に、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置へ再送信する。デバイス装置のリンク層は、受信したＤＰＨが正常である場合、ＬＧＯＯＤコマンドをホスト装置に対して送信し、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをプロトコル層へ転送する。デバイス装置のプロトコル層は、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰを正常に受信すると、正常受信及び次のデータＳｎｕｍ＝Ｘ＋１の送信要求を示すＡＣＫ（Ｓｎｕｍ＝Ｘ＋１）をホスト装置へ送信する。
【００１７】
次に、後続の規格であるＵＳＢ３．１  Ｇｅｎ２において一般的な実装を行う場合について説明する。ＵＳＢ３．１  Ｇｅｎ２では、上述したようにＤＰＨ内のＣＲＣ値がエラーであっても新たに追加されたＬｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域が正常値である場合には、リンク層でＤＰＨのみを破棄し、対応するＤＰＰをプロトコル層に送ることとなった。そのため、ＤＰＨがエラーのためＤＰＨは転送されずＤＰＰのみがプロトコル層に転送された場合に備えて、プロトコル層に専用のバッファを設けることが考えられる。この専用のバッファは、元々搭載されている特定のエンドポイント用のデータバッファとは異なるものである。そして、ＤＰＨが再送された後に、Ｓｎｕｍが対応する受信済みのＤＰＰと再送されたＤＰＨとの格納順序を入れ替える制御回路もプロトコル層に設けることが考えられる。そのため、ＵＳＢ３．１  Ｇｅｎ２に対応するために一般的な実装を行う場合、これらのバッファや制御回路の追加による回路面積が増加してしまう。例えば、データバッファには、概算で最低１パケット（１０２４バイト）分のデータを格納するためのフリップフロップ又はＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）が必要と考えられる。
【００１８】
続いて、ＵＳＢ３．１  Ｇｅｎ２において一般的な実装を行った際に、ＤＰＨにＣＲＣエラーが発生した場合の各層の処理の流れを図１４のシーケンス図を用いて説明する。ここでは、ＵＳＢ３．１  Ｇｅｎ２におけるＢｕｌｋ  ＯＵＴ転送の途中からの動作を示している。すなわち、デバイス装置は、ホスト装置から送信されたＳｎｕｍ＝Ｘ−１までのＤＰを正常に受信済みであるものとする。
【００１９】
そこで、ＵＳＢ３．１  Ｇｅｎ２に対応するホスト装置は、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置へ送信する。そして、ＵＳＢ３．１  Ｇｅｎ２に対応するデバイス装置では、物理層及びリンク層にてＳｎｕｍ＝ＸのＤＰＨを受信する。この時、受信したＤＰＨにおいてＣＲＣエラーが検出され、かつ、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域が正常値であるものとする。ここで、正常値とは、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域の値が一定の範囲内であることをいう。その後、ＵＳＢ３．１  Ｇｅｎ２におけるリンク層は、ＤＰＨを破棄し、ＤＰＰをプロトコル層へ転送する。また、当該リンク層は、ＬＢＡＤコマンドをホスト装置に対して送信する。
【００２０】
プロトコル層は、受信したＤＰＰを上記で追加されたバッファへ格納する。また、ホスト装置は、ＬＢＡＤコマンドの受信に応じてＬＲＴＹコマンドを送信し、続いて、Ｓｎｕｍ＝ＸのＤＰＨのみをデバイス装置へ再送信する。このとき、再送されるＤＰＨを「ＤＰＰなしＤＰＨ」（又はＮｕｌｌＤＰＰ）と呼ぶこととする。デバイス装置のリンク層は、受信した「ＤＰＰなしＤＰＨ」が正常である場合、ＬＧＯＯＤコマンドをホスト装置に対して送信し、Ｓｎｕｍ＝Ｘの「ＤＰＰなしＤＰＨ」をプロトコル層へ転送する。デバイス装置のプロトコル層は、Ｓｎｕｍ＝ＸのＤＰＨを正常に受信すると、上述した制御回路により、Ｓｎｕｍ＝Ｘの受信済みのＤＰＰと今回受信したＤＰＨの順序を入れ替えてデータバッファに格納し直す。その後、プロトコル層は、正常受信及び次のデータＳｎｕｍ＝Ｘ＋１の送信要求を示すＡＣＫ（Ｓｎｕｍ＝Ｘ＋１）をホスト装置へ送信する。
【００２１】
このように、ＵＳＢ３．１  Ｇｅｎ２において一般的な実装を行った際に、所定のエラーが発生した場合には、上述の課題が生じ得る。そこで、上述の課題を解決するための実施の形態を以下に説明する。
【００２２】
＜実施の形態１＞
図１は、本実施の形態１にかかるホスト装置１とデバイス装置２の構成を示すブロック図である。ホスト装置１は、ＵＳＢ３．１  Ｇｅｎ２規格に対応するホスト機能を内蔵する半導体装置である。又は、ホスト装置１は、コンピュータ等であってもよい。デバイス装置２は、ＵＳＢ３．１  Ｇｅｎ２規格に対応するペリフェラル機能を内蔵する半導体装置である。ここで、ホスト装置１とデバイス装置２とはＵＳＢ３．１ＩＦにより接続されているものとする。尚、ホスト装置１とデバイス装置２とを含む構成をデータ転送システム１０００と呼ぶこともできる。
【００２３】
デバイス装置２は、プロトコル層２１とリンク層２２とを含むデバイスコア２０と、データバッファ２４と、物理層２３とを備える。ここで、リンク層２２は、第１の処理部の一例であり、プロトコル層２１は、第２の処理部の一例である。尚、第１の処理部は、物理層２３とリンク層２２とに対応させてもよい。
【００２４】
物理層２３は、物理制御部２３１を備える。物理制御部２３１は、ＵＳＢ３．１  Ｇｅｎ２規格に対応し、ホスト装置１との間で物理層レベルのデータの送受信を制御する。リンク層２２は、リンク制御部２２１を備える。リンク制御部２２１は、ＵＳＢ３．１  Ｇｅｎ２規格に対応し、物理層２３とのデータの送受信及びプロトコル層２１とのデータの送受信を行う。また、リンク制御部２２１は、送受信されるデータについてリンク層レベルのパケット処理の制御を行う。プロトコル層２１は、パイプ制御部２１１と、リンクＩＦ２１２と、データＩＦ２１３とを備える。リンクＩＦ２１２は、ＵＳＢ３．１  Ｇｅｎ２規格に対応し、リンク層２２とのデータの送受信を行う。データＩＦ２１３は、データバッファ２４とのデータの送受信を行う。パイプ制御部２１１は、パイプＩＮ／ＯＵＴ２１４を備える。パイプＩＮ／ＯＵＴ２１４は、ＵＳＢ３．１  Ｇｅｎ２規格に対応し、プロトコル層レベルのパケット処理の制御を行う。
【００２５】
データバッファ２４は、ホスト装置１の間で送受信するデータを格納するための記憶領域である。データバッファ２４には、例えば、ＤＰＨやＤＰＰが格納される。
【００２６】
図２は、本実施の形態１にかかるリンク層２２におけるＤＰＨ受信処理の流れを説明するためのフローチャートである。
【００２７】
まず、リンク層２２のリンク制御部２２１は、ホスト装置１から物理層２３を介してＤＰＨを受信する（Ｓ１０１）。次に、リンク制御部２２１は、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａ領域が正常値か否かを判定する（Ｓ１０２）。ここで、当該領域が正常値、つまり、一定の範囲内の値である場合、リンク制御部２２１は、受信したＤＰＨがＣＲＣエラーであるか否かを判定する（Ｓ１０３）。ＣＲＣエラーである場合、リンク制御部２２１は、受信したＤＰＨを破棄する（Ｓ１０４）。つまり、リンク層２２は、受信したＤＰＨを後段のプロトコル層２１へは転送しない。そして、リンク制御部２２１は、ＤＰＨに引き続き受信するＤＰＰについて、プロトコル層２１へ転送する（Ｓ１０５）。つまり、リンク層２２は、破棄されたＤＰＨのＳｎｕｍと同じＳｎｕｍにおけるＤＰＰについては、破棄せずにプロトコル層２１へ転送する。また、リンク層２２は、物理層２３を介してホスト装置１へＬＢＡＤコマンドを送信する（Ｓ１０６）。
【００２８】
ステップＳ１０２においてＬｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａ領域が正常値でない場合、リンク制御部２２１は、規定のエラー処理を行う（Ｓ１０７）。尚、当該エラー処理は公知のものであるため、詳細な説明を省略する。尚、ステップＳ１０２においては、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａ領域が正常値か否かの判定だけでなく、ＣＲＣエラー以外の他のエラーについても判定されており、ＣＲＣエラー以外の何らかのエラーが検出された場合には、ステップＳ１０７のエラー処理が行われるものとする。
【００２９】
また、ステップＳ１０３において、受信したＤＰＨがＣＲＣエラーでない、つまり、ＣＲＣが正常値である場合、リンク制御部２２１は、受信したＤＰＨ及び引き続き受信するＤＰＰについて、後段のプロトコル層２１へ転送する（Ｓ１０８）。併せて、リンク層２２は、物理層２３を介してホスト装置１へＬＧＯＯＤコマンドを送信する（Ｓ１０９）。
【００３０】
図３は、本実施の形態１にかかるプロトコル層２１におけるＤＰＨ受信処理の流れを説明するためのフローチャートである。まず、プロトコル層２１は、リンク層２２からＤＰＨを受信する（Ｓ２０１）。次に、プロトコル層２１は、リンクＩＦ２１２において、受信したＤＰＨが正常か否かを判定する（Ｓ２０２）。ＤＰＨが正常な場合、リンクＩＦ２１２において、は、受信したＤＰＨがＮｕｌｌＤＰＰか否かを判定する（Ｓ２０３）。つまり、プロトコル層２１は、受信したＤＰＨの後続にＤＰＰがあるか否か、言い換えると、受信したＤＰＨの直後に、同じＳｎｕｍのＤＰＰが存在するか否かを判定する。ステップＳ２０３において、受信したＤＰＨがＮｕｌｌＤＰＰの場合、プロトコル層２１は、Ｒｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）を、リンク層２２及び物理層２３を介してホスト装置１へ送信する（Ｓ２０４）。ここで、Ｒｅｔｒｙ  ＡＣＫは、プロトコル層でのＤＰの再送要求を示す。
【００３１】
ステップＳ２０３において、リンクＩＦ２１２が受信したＤＰＨがＮｕｌｌＤＰＰではないと判定した場合、プロトコル層２１は、受信したＤＰＨをデータバッファ２４に保存し（Ｓ２０５）、後述するＤＰＰ受信処理を行う（Ｓ２０６）。また、ステップＳ２０２において、リンクＩＦ２１２がＤＰＨが正常でないと判定した場合、プロトコル層２１は、規定のエラー処理を行う（Ｓ２０７）。
【００３２】
図４は、本実施の形態１にかかるプロトコル層２１におけるＤＰＰ受信処理の流れを説明するためのフローチャートである。尚、図４は、図３のステップＳ２０６の詳細な処理として実行される場合もあるが、ＤＰＨの受信処理なしに単独で実行される場合もあるものとする。
【００３３】
まず、プロトコル層２１は、リンク層２２からＤＰＰを受信する（Ｓ２１１）。次に、プロトコル層２１は、リンクＩＦ２１２において、受信したＤＰＰが正常か否かを判定する（Ｓ２１２）。受信したＤＰＰが正常な場合、リンクＩＦ２１２は、ＤＰＨなしのＤＰＰであるか否かを判定する（Ｓ２１３）。つまり、プロトコル層２１は、今回受信したＤＰＰの前に同じＳｎｕｍのＤＰＨが受信済みか否か、又は、以前に同じＳｎｕｍのＤＰＰを破棄したか否かを判定する。ステップＳ２１３において、ＤＰＨなしのＤＰＰであると判定した場合、プロトコル層２１は、受信したＤＰＰを破棄する（Ｓ２１４）。例えば、プロトコル層２１は、受信したＤＰＰをデータバッファ２４に保存しない。または、プロトコル層２１は、受信したＤＰＰをデータバッファ２４に保存するが、後続のデータ保存において上書き可能とする。
【００３４】
ステップＳ２１３において、リンクＩＦ２１２がＤＰＨなしのＤＰＰではないと判定した場合、つまり、直前に同じＳｎｕｍのＤＰＨを受信及び保存済みの場合、プロトコル層２１は、受信したＤＰＰをデータバッファ２４に保存する（Ｓ２１５）。併せて、プロトコル層２１は、ＡＣＫ（Ｓｎｕｍ＝Ｘ＋１）を、リンク層２２及び物理層２３を介してホスト装置１へ送信する（Ｓ２１６）。
【００３５】
また、ステップＳ２１２において、リンクＩＦ２１２がＤＰＰが正常でないと判定した場合、プロトコル層２１は、規定のエラー処理を行う（Ｓ２１７）。
【００３６】
図５は、本実施の形態１にかかるＤＰＨにＣＲＣエラーが発生した場合の各層の処理の流れを示すシーケンス図である。ここでは、ＵＳＢ３．１  Ｇｅｎ２におけるＢｕｌｋ  ＯＵＴ転送の途中からの動作を示している。すなわち、デバイス装置２は、ホスト装置１から送信されたＳｎｕｍ＝Ｘ−１までのＤＰを正常に受信済みであるものとする。尚、以後のシーケンス図についても同様である。
【００３７】
そこで、ホスト装置１は、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置２へ送信する。そして、デバイス装置２では、物理層２３及びリンク層２２にてＳｎｕｍ＝ＸのＤＰＨを受信する。この時、受信したＤＰＨにおいてＣＲＣエラーが検出され、かつ、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域が正常値であるものとする。その後、リンク層２２は、ＤＰＨを破棄し、ＤＰＰをプロトコル層２１へ転送する。また、リンク層２２は、ＬＢＡＤコマンドを物理層２３を介してホスト装置１に対して送信する。
【００３８】
プロトコル層２１は、受信したＤＰＰが正常であり、かつ、ＤＰＨなしのＤＰＰであるため、受信したＤＰＰを破棄する。また、ホスト装置１は、ＬＢＡＤコマンドの受信に応じてＬＲＴＹコマンドを送信し、続いて、Ｓｎｕｍ＝Ｘの「ＤＰＰなしＤＰＨ」をデバイス装置２へ再送信する。
【００３９】
リンク層２２は、受信した「ＤＰＰなしＤＰＨ」が正常であるため、ＬＧＯＯＤコマンドをホスト装置１に対して送信し、Ｓｎｕｍ＝Ｘの「ＤＰＰなしＤＰＨ」をプロトコル層２１へ転送する。プロトコル層２１は、Ｓｎｕｍ＝Ｘの「ＤＰＰなしＤＰＨ」を正常に受信すると、ＤＰＨをデータバッファ２４に格納し、併せて、Ｒｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）を、リンク層２２及び物理層２３を介してホスト装置１へ送信する。ホスト装置１は、Ｒｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）に応じて、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置２へ送信する。ここでは、ＤＰＨ及びＤＰＰが正常に受信されるものとする。
【００４０】
そのため、リンク層２２は、受信したＤＰＨのＣＲＣエラーを検出せず、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをそのままプロトコル層２１へ転送し、ホスト装置１に対してＬＧＯＯＤコマンドを送信する。プロトコル層２１は、受信したＤＰＨ及びＤＰＰをデータバッファ２４へ格納し、ＡＣＫ（Ｓｎｕｍ＝Ｘ＋１）をホスト装置１へ送信する。
【００４１】
このように、本実施の形態１では、プロトコル層においてＤＰＨなしのＤＰＰの受信時はＤＰＰを格納せずに破棄し、次回のＤＰの正常な受信時にホスト装置に対し再送要求であるＲｅｔｒｙ  ＡＣＫ  ＴＰを送信することで、確実にＤＰ受信を行う事が出来る。
【００４２】
それ故、ＤＰＨなしのＤＰＰの受信時の一時的に必要なＤＰＰ格納領域が不要になることで、ＤＰＰ格納領域分の回路面積を低減することが出来る。また、一時的に格納したＤＰＰを次回のＤＰＨ受信時の情報から本来格納すべき格納領域への格納制御が不要になることで、格納制御分の回路面積を低減することが出来る。さらに、本実施の形態１は、ＵＳＢ３．１  Ｇｅｎ２規格に対応するホスト装置１に改変を加えることなく適用できる点で有益である。
【００４３】
ここで、本実施の形態１は次のように表現することができる。すなわち、デバイス装置は、ホスト装置から受信した第１のパケットの第１のヘッダに所定のエラーが含まれる場合、当該第１のヘッダを破棄し、当該第１のパケットの第１のペイロードを後段へ送信する第１の処理部と、前記第１の処理部から受信した前記第１のペイロードを破棄し、前記第１のパケットの再送要求（例えば、Ｒｅｔｒｙ  ＡＣＫ）を前記ホスト装置へ送信する第２の処理部と、を備える。これにより、上述したように回路面積の増加を抑制することができる。
【００４４】
さらに、本実施の形態１にかかる前記第１の処理部は、前記第１のヘッダに前記所定のエラーが含まれる場合、当該第１のヘッダの再送要求（例えば、ＬＢＡＤコマンド）を前記ホスト装置へ送信し、前記ホスト装置から前記第１のヘッダの再送要求に応じたペイロードなしの第２のパケットの第２のヘッダ（例えば、ＤＰＰなしＤＰＨ）を受信し、前記受信した第２のヘッダが正常な場合に、当該第２のヘッダを前記第２の処理部へ送信し、前記第２の処理部は、前記第１の処理部から前記第２のヘッダを受信した場合に、前記第１のパケットの再送要求を前記ホスト装置へ送信するものである。これにより、ＵＳＢ３．１  Ｇｅｎ２規格の既存のコマンドを有効活用しつつ、回路面積の増加を抑制できる。
【００４５】
さらに、前記第１の処理部は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）３．１  Ｇｅｎ２に対応するリンク層であり、前記第２の処理部は、ＵＳＢ３．１  Ｇｅｎ２に対応するプロトコル層であることが望ましい。
【００４６】
また、前記所定のエラーは、前記第１のヘッダのＣＲＣがエラー値、かつ、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａ領域が正常値である。これにより、ＵＳＢ３．１  Ｇｅｎ１からＵＳＢ３．１  Ｇｅｎ２への規格変更に柔軟に対応することができる。
【００４７】
＜実施の形態２＞
本実施の形態２は、上述した実施の形態１の改良例である。すなわち、本実施の形態２にかかる前記第１の処理部は、前記第１のヘッダを破棄した際に、疑似的な正常受信応答を前記ホスト装置へ送信し、前記第２の処理部は、前記第１のペイロードを破棄すると共に、前記第１のパケットの再送要求を前記ホスト装置へ送信するものである。これにより、実施の形態１と比べてデータ再送処理時間を短縮することができる。
【００４８】
図６は、本実施の形態２にかかるリンク層２２におけるＤＰＨ受信処理の流れを説明するためのフローチャートである。図６では、図２のステップＳ１０６がステップＳ１０６ａに置き換わったものである。その他のステップは図２と同等であるため適宜、説明を省略する。
【００４９】
具体的には、リンク制御部２２１は、所定のエラーを含むＤＰＨを破棄（Ｓ１０４）した後、後続のＤＰＰをプロトコル層２１へ転送し（Ｓ１０５）つつ、疑似的にＬＧＯＯＤコマンドをホスト装置１へ送信する（Ｓ１０６ａ）。尚、疑似的なＬＧＯＯＤコマンドの内容は、通常のＬＧＯＯＤコマンドと同等であるものとする。言い換えると、リンク層２２は、ステップＳ１０６ａにおいて、ＬＢＡＤコマンドの代わりにＬＧＯＯＤコマンドをホスト装置１へ送信する。
【００５０】
図７は、本実施の形態２にかかるプロトコル層２１におけるＤＰＰ受信処理の流れを説明するためのフローチャートである。図７は、図４のステップＳ２１４と併せて、ステップＳ２１８を実行することが追加されたものである。その他のステップは図２と同等であるため適宜、説明を省略する。
【００５１】
具体的には、ステップＳ２１３において、リンクＩＦ２１２において、ＤＰＨなしのＤＰＰであると判定した場合、プロトコル層２１は、受信したＤＰＰを破棄する（Ｓ２１４）と共に、Ｒｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）を、リンク層２２及び物理層２３を介してホスト装置１へ送信する（Ｓ２１８）。
【００５２】
図８は、本実施の形態２にかかるＤＰＨにＣＲＣエラーが発生した場合の各層の処理の流れを示すシーケンス図である。まず、ホスト装置１は、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置２へ送信する。そして、デバイス装置２では、物理層２３及びリンク層２２にてＳｎｕｍ＝ＸのＤＰＨを受信する。この時、受信したＤＰＨにおいてＣＲＣエラーが検出され、かつ、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域が正常値であるものとする。その後、リンク層２２は、ＤＰＨを破棄し、ＤＰＰをプロトコル層２１へ転送する。また、リンク層２２は、ＬＢＡＤコマンドの代わりにＬＧＯＯＤコマンドを物理層２３を介してホスト装置１に対して送信する。
【００５３】
プロトコル層２１は、リンク層２２から受信したＤＰＰを破棄する。併せて、プロトコル層２１は、Ｒｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）を、リンク層２２及び物理層２３を介してホスト装置１へ送信する。ホスト装置１は、Ｒｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）に応じて、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置２へ送信する。以降は、図５と同等である。
【００５４】
つまり、本実施の形態２では、リンク層２２が本来ＬＢＡＤコマンドを送信すべきところ正常応答であるＬＧＯＯＤコマンドを送信することと、プロトコル層２１がＤＰＨなしＤＰＰを受信した場合に、即時にＲｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）を送信するものである。このため、ホスト装置１は、ＬＲＴＹコマンドや「ＤＰＰなしＤＰＨ」を送信することなく、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰを再送することができる。それ故、実施の形態１と比べて、ＬＲＴＹコマンドや「ＤＰＰなしＤＰＨ」の送信及び受信に伴う各処理時間を短縮できる。また、本実施の形態２は、実施の形態１と同様、ＵＳＢ３．１  Ｇｅｎ２規格に対応するホスト装置１に改変を加えることなく適用できる点で有益である。
【００５５】
また、本実施の形態２では、リンク層からＬＢＡＤコマンドを送らないことでホスト装置のＬＲＴＹコマンド及び再送のＤＰＰなしＤＰＨを待たずに、プロトコル層にてＲｅｔｒｙ  ＡＣＫを送る事で、実施の形態１よりも転送パフォーマンスを向上出来る。
【００５６】
＜実施の形態３＞
本実施の形態３は、上述した実施の形態１の別の改良例である。すなわち、本実施の形態３にかかるホスト装置は、前記第１の処理部からの前記第１のヘッダの再送要求を受信した場合に、前記第１のペイロードの送信を中止し、前記第２のパケットの送信を開始するものである。これにより、実施の形態１と比べて、所定のエラー時の再送時間を短縮することができる。
【００５７】
図９は、本実施の形態３にかかるホスト装置１におけるＤＰ送信処理の流れを説明するためのフローチャートである。まず、ホスト装置１は、ＤＰＨをデバイス装置２へ送信する（Ｓ３０１）。続いて、ホスト装置１は、送信したＤＰＨと同じＳｎｕｍのＤＰＰの送信を開始する（Ｓ３０２）。その後、ホスト装置１は、ＤＰＰの送信中に、デバイス装置２からＬＢＡＤコマンドを受信したか否かを判定する（Ｓ３０３）。ＬＢＡＤコマンドを受信した場合、ホスト装置１は送信中のＤＰＰの送信を中止し（Ｓ３０４）、併せて、ＬＲＴＹコマンドをデバイス装置２へ送信する（Ｓ３０５）。以降、ホスト装置１は、ＤＰＨ及びＤＰＰを再送する。
【００５８】
図１０は、本実施の形態３にかかるＤＰＨにＣＲＣエラーが発生した場合の各層の処理の流れを示すシーケンス図である。まず、ホスト装置１は、Ｓｎｕｍ＝ＸのＤＰＨ及びＤＰＰをデバイス装置２へ送信する。但し、ＤＰＰは送信中とする。そして、デバイス装置２では、物理層２３及びリンク層２２にてＳｎｕｍ＝ＸのＤＰＨを受信する。この時、受信したＤＰＨにおいてＣＲＣエラーが検出され、かつ、Ｌｅｎｇｔｈ  Ｆｉｅｌｄ  Ｒｅｐｌｉｃａの領域が正常値であるものとする。その後、リンク層２２は、ＤＰＨを破棄し、プロトコル層２１へのＤＰＰの転送を開始する。また、リンク層２２は、ＬＢＡＤコマンドを物理層２３を介してホスト装置１に対して送信する。
【００５９】
ここで、ホスト装置１は、ＬＢＡＤコマンドの受信に応じて、送信中のＳｎｕｍ＝ＸのＤＰＰの送信を中止する。そして、ホスト装置１は、ＬＲＴＹコマンドを送信し、続いて、Ｓｎｕｍ＝ＸのＤＰＰなしＤＰＨをデバイス装置２へ再送信する。以降は、図５と同等である。
【００６０】
このように、ＬＢＡＤコマンドを受信後に送信中のＤＰＰは不要になることから、ＬＢＡＤコマンドの受信後、即時にＤＰＰ送信を中止し、ＬＲＴＹコマンドの送信及びＤＰＨの再送動作を早める事で、転送パフォーマンスを向上することが出来る。
【００６１】
＜実施の形態４＞
本実施の形態４は、同じＳｎｕｍにおけるＤＰＨとＤＰＰの受信順序が逆になった場合に、リンク層に適用できる処理について説明する。
図１１は、本実施の形態４にかかるリンク層２２におけるＤＰＰ受信処理の流れを説明するためのフローチャートである。まず、リンク層２２は、ＤＰＰを受信する（Ｓ４０１）。次に、リンク制御部２２１は、当該ＤＰＰのＳｎｕｍと同じＳｎｕｍのＤＰＨが受信前であるか否かを判定する（Ｓ４０２）。ＤＰＨの受信前の場合、リンク層２２は、ＤＰＰを破棄する（Ｓ４０３）。ＤＰＨの受信後の場合、リンク層２２は、ＤＰＰをプロトコル層２１へ転送する。
【００６２】
図１２は、本実施の形態４にかかるＤＰＨとＤＰＰの受信順序が逆の場合の各層の処理の流れを示すシーケンス図である。まず、ホスト装置１は、Ｓｎｕｍ＝ＸのＤＰＰ、ＤＰＨの順序でデバイス装置２へ送信する。リンク層２２は、ホスト装置１から物理層２３を介してＤＰＰを受信する。このとき、リンク層２２は、Ｓｎｕｍ＝ＸのＤＰＨの受信前であるため、受信したＤＰＰを破棄する。その後、リンク層２２は、Ｓｎｕｍ＝ＸのＤＰＨを受信し、正常であるため、受信したＤＰＨをプロトコル層２１へ転送し、ＬＧＯＯＤコマンドを物理層２３を介してホスト装置１へ送信する。プロトコル層２１は、リンク層２２からＤＰＨを正常に受信するが、ＮｕｌｌＤＰＰと判定し、ホスト装置１に対してＲｅｔｒｙ  ＡＣＫ（Ｓｎｕｍ＝Ｘ）を送信する。以降は、図５と同等である。
【００６３】
尚、図１２では、ホスト装置１による送信順序がＤＰＰ、ＤＰＨであったが、送信順序が正常にＤＰＨ、ＤＰＰとされても、通信異常等により受信順序が前後した場合にも適用可能である。
【００６４】
また、図１２において、最初のＤＰＰの次に送信されるＤＰＨが所定のエラーであっても、リンク層２２はホスト装置１へＬＢＡＤコマンドを送信するが、リンク層２２からプロトコル層２１へは何も送られないこととなる。その場合、実施の形態１と同様に、ホスト装置１からＤＰＰなしＤＰＨが送信され、以降、図５と同じ処理となる。
【００６５】
尚、本実施の形態４は、以下の付記のように表現することもできる。
（付記）ホスト装置から第１のパケットの第１のペイロードを受信した場合に、当該第１のパケットの第１のヘッダが受信済みか否かを判定し、受信済みでないと判定した場合に、当該第１のペイロードを破棄し、前記ホスト装置から受信した前記第１のパケットの前記第１のヘッダが正常な場合に、後段へ当該第１のヘッダを送信する第１の処理部と、
前記第１の処理部から前記第１のヘッダを受信し、前記第１のペイロードを受信していない場合に、前記第１のパケットの再送要求を前記ホスト装置へ送信する第２の処理部と、
を備えるデバイス装置。
【００６６】
また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（Central Processing Unit）等のプロセッサにコンピュータプログラムを実行させることにより実現することも可能である。
【００６７】
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【００６８】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は既に述べた実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能であることはいうまでもない。
【符号の説明】
【００６９】
１０００  データ転送システム
１  ホスト装置
２  デバイス装置
２０  デバイスコア
２１  プロトコル層
２１１  パイプ制御部
２１２  リンクＩＦ
２１３  データＩＦ
２１４  パイプＩＮ／ＯＵＴ
２２  リンク層
２２１  リンク制御部
２３  物理層
２３１  物理制御部
２４  データバッファ
【図１】
2018045417.tif 000003
【図２】
2018045417.tif 000004
【図３】
2018045417.tif 000005
【図４】
2018045417.tif 000006
【図５】
2018045417.tif 000007
【図６】
2018045417.tif 000008
【図７】
2018045417.tif 000009
【図８】
2018045417.tif 000010
【図９】
2018045417.tif 000011
【図１０】
2018045417.tif 000012
【図１１】
2018045417.tif 000013
【図１２】
2018045417.tif 000014
【図１３】
2018045417.tif 000015
【図１４】
2018045417.tif 000016