そんな訳で、まずはその問題のIsochronous INのTransferである。これは極めて簡単で、Photo01の様にHostはACK TPを送ると、これに対してDeviceがDPを順次送って終り、である。あらかじめDPの数は決まっている(これはここまで書いたとおり、Isochronous Transferに関してはそもそもDeviceの設計の時点で何をどれだけ転送するか、が決まっていなくてはならない)から、それに合わせてACK TPはSequence NumberにDPの数を入れた形でDeviceに送られ、Deviceはこれと同じだけの数のDPをHostに順次送り出して終りである。

Photo01で最後にLPFとあるのは、最後のDP中の実Data SizeがPakcetのMaximum Packet Sizeに満たない場合に、LPF(Last Packet Flag)を1にセットせよという話であって、もし最後のDPのData Sizeもきっちりだった場合、これをセットする必要はない(もっともこのあたり、Specificationではややあいまいさが残る。というのは、別の箇所では"For isochronous endpoint this field is used to identify that this is the last packet of the last burst in the current service interval"(Isochronous転送の場合、Endpointは現在のService IntervalにおけるBurst転送の最後のPacketであることを示すためにこれを利用する)なんて表現があるからで、これを読むと最終DPには無条件でLPFを立てたほうが良いようにも思える。逆に「最終Packetでデータサイズがきっちりの場合、LPFを立ててはいけない」とは何処にも書いてないので、最終パケットにはLPFを無条件で立てるという実装が実際には正しいのかもしれない)。

ちなみに転送はこれで終了であり、Hostから受信完了を示すACK TPは送られないし、エラーによる再送などもサポートされない。

Photo01: Universal Serial Bus 3.0 SpecificationのFigure 8-46から抜粋

一方Isochronous OUT TrasnferはPhoto02に示すように、既にDeviceからのACK TPも何もなく、一方的にHostからDPを送りつけて終り、となっている。

Photo02: Universal Serial Bus 3.0 SpecificationのFigure 8-47から抜粋

ちなみにIsochronous IN/OUT共に、1回のService Interval内で最大で許されるDPの数は48となっている。で、前回もちょっと触れた話だが、もしHostがあるService IntervalではDeviceに何も送る必要がないと判断した場合、Hostは単純にそのService Intervalに何も送らないという形でハンドリングする。逆にDeviceからHostに送るべきデータがない場合、Data Lengthが0のDPを1個送る形となる。

また、先にも述べたようにエラーがあってもRetryすることは出来ないため、例えばIsochronous OUTでエラーがあったら単純にそのデータを破棄するだけである。Isochronous IN/OUTともにエラーがあれば、その時点でそのService Interval内のTransactionは終了となり、それをSoftwareに通知して終わる。逆に言えば、Interrupt IN/OUTの様に、NRDY/ERDYを使ってサービスを一時中断したりといった機能は持ち合わせていないので、仮にあるService Intervalがエラーで終了しても、また次のService Intervalが来れば次のTransactionが始まることになる。これを中断する、あるいはエラーの原因を取り除くといった処理は、USB Hostから見たアプリケーションソフトウェア(つまりドライバ以上)でカバーする仕組みとなっている。

ところで連続して転送できるDPの数は最大48であると書いたが、その一方で1回に送る事ができるDPの数はそこまで多くない。この結果として、毎回Isochronous IN/OUTを使って大量のデータを送るケースでは、Photo03/04の様に何回かのBurst Transferを繋ぎ合わせて転送を行う様な形となる。

Photo03: Universal Serial Bus 3.0 SpecificationのFigure 8-50から抜粋

Photo04: Universal Serial Bus 3.0 SpecificationのFigure 8-51から抜粋

こうしたケースで問題になるのは、複数のBurst Transferが組み合わされる可能性があることだ。例えばDPが11個続くケースでは、

  • Single Burst×11
  • 8 DPのBurst×1の後でSingle Burst×3
  • 4 DPのBurst×2の後でSingle Burst×3
  • 2 DPのBurst×5の後でSingle Burst×1

の4通りのパターンがあり、特にIsochronous INの場合はどれが来るかが不明である。従ってHost側はこのどれが来ても対応できるような柔軟な構成が必要である。とされている。

(続く)