Ellisysが実現する高度な解析

Ellisysが実現する高度な解析
一歩進んだプロトコル解析の要領と手順
« 初回投稿
IOGear GUWH104KITのWireless USBハブとドング
ルを分析してみよう
私たちが Wireless USB と WiMedia のプロトコルアナライザの開発に取り組み始めてもう 3 年
以上が経ちます。ですから、やっと Certified Wireless USB 準拠製品を入手できるようになったこ
とにとても興奮しています。このときをどれほど待ったことでしょう。数年前に購入した初期の
WiMedia 製品は、わずか数フレームしか無線伝送できなかったにもかかわらず、40,000 ドル以
上もしたのを覚えています。そこへいくと 200 ドルの IOGear はかなりお値打ちだといえるでしょう。
優秀なエンジニアがまず最初に知りたいと思うその中身は次の通りです。
- HWAドングルに組み込まれている Intel Wireless UWB Link 1480 チップ
- DWAハブに組み込まれている NEC uPD720180 チップ
- Stonestreet One社製ドライバ
これまでのところは非常に良い感じです。では、実際に製品を試してみましょう。
CD-ROM のインストール
まず最初にすべきことは、CD-ROM からドライバをインストールすることです。CD-ROM には、
Windows XP コンピュータに Wireless USB サポートを追加する Stonestreet One 社製の
WiCenter アプリケーションとドライバが格納されています。WiCenter は Windows とよく調和して
いて、そのインターフェースは見やすく、とても使いやすくできています。
Wireless USB ハブのアソシエーション
次のステップでは、セキュリティの目的でWireless USBハブとホストとのアソシエーションを行いま
す。アソシエーションの間、無線伝送の暗号化に使用されるマスターセキュリティキーがデバイス
とホスト間で交換されます。ハブのアソシエーションは、従来の堅牢な有線USBケーブルを使用し
て行います。このアソシエーションプロシージャの様子を、Ellisys USB Explorer 200 PROプロト
コルアナライザでマスターキーを抽出して見てみます。マスタキーを抽出しておくと、無線で取得
されるデータをWiMediaプロトコルアナライザで解読するときにも便利です。この作業はとても簡
単です。最後の要求であるSetAssociationResponseに、要求したマスターキー「64 FB 9F BB
C1 92 62 9E 41 90 8C 7A 77 9F 9F E6」が含まれています。
» 「有線USBケーブルを使用したハブアソシエーションのトレース」のダウンロード
» 「Ellisys USBトレースビューワ」のダウンロード
ドングルのセットアップ
さらに、ドングルのエニュメレーションを探ってその機能を見てみます。ドライバのインストールは
簡単です。トレースを見てみましょう。トレースで最初に目に付くことは、デバイスに 2 フェーズのエ
ニュメレーションが使用されていることです。1 つ目のドライバは、ベンダー要求 0xF0 で 256 KB
のファームウェアをロードするようです。この新しいファームウェアによって USB から一度切断さ
れ、別の ID で USB に再接続されます（この手法はリニュメレーションとして知られています）。
デバイスは再接続されると、自らを Wire Adapter として宣言します。これは私たちの予想どおりで
す。この Wire Adapter がロードされると、Wire Adapter 要求を見れるようになります。このハード
ウェアでは 64 の Remote Pipe（RPipe）がサポートされています。Wireless USB 規格では、
「Remote Pipe は、Wire Adapter を介し、特定のデバイス上の特定のエンドポイントへのデータ
フローを形成する論理抽象的コネクションである」と定義されています。つまり、このドングルは 64
のエンドポイントとの同時通信をサポートしていることを意味します。このデバイスでの RPipe は
アイソクロナス転送をサポートしていないようですが、第 1 世代のハードウェアであることを考えれ
ば、そう驚くことでもありません。堅牢なアイソクロナス転送を可能にするにはかなりの労力がいる
ため、アイソクロナス転送が必要とされるようなアプリケーションであっても、バルク転送や割り込
み転送といった簡単な方法が好まれることが多いのです。
有線 USB についてはこれくらいにして、いよいよ無線の話に移りましょう！
» 「ドングルのエニュメレーショントレース」のダウンロード
» 「Ellisys USBトレースビューワ」のダウンロード
ワイヤレスへ
さて、これで無線通信の準備ができました。ドングルが接続されている状態で、Ellisys WiMedia
Explorer 300 を使用してWiMediaチャネルをスキャンし、ドングルがどのチャネルで伝送を行って
いるのかを調べてみましょう。このEllisys製アナライザは、チャネルTFC5 でトラフィックを検出しま
す。このチャネルで記録をとり、記録されるトラフィックをリアルタイムで観察します（これはEllisys
製品の素晴らしい機能です）。ドングルは自らの存在を他のWiMedia対応デバイスに通知するた
めにWiMediaビーコンを送信すると同時に、Wireless USB MMCも送信します。MMCは、伝送を
スケジューリングし、通知を許可するために、ホストからデバイスに送信されるコマンドです。
Wireless USBプロトコルについて興味がある方は、Ellisysの白書「Challenges of Migrating
from USB to Wireless」を参照してください。日本総代理店のガイロジック㈱では、翻訳した
「Wireless USBへの移行に伴う課題」を用意していますので、必要な方はお問い合わせ下さい。
いよいよ Wireless USB ハブの電源を入れます。ハブは MMC DNTS スロットで DN_Connect
通知を送信し、自らの存在をホストに通知します。ホストはこれを検知し、エニュメレーションプロ
シージャを開始します。[Wireless USB Overview] 画面では、すべて順調にいっているように見え
ます。ホストは、このデバイスが DWA であることを検知し、対応するドライバをロードしました。
ハブ記述子を見てみましょう。まず、前に記録されたキーを使用して、データを解読する必要があ
ります。[Security] ビューを開き、[Master Key] に “64 FB 9F BB C1 92 62 9E 41 90 8C 7A 77
9F 9F E6” を設定します。これで、ソフトウェアによって一時キーが自動的に計算され、すべての
データが解読されます。BOS 記述子から、このハードウェアが自己ビーコン送信デバイスであり、
53.3～480 Mbps の利用可能なすべてのデータレートをサポートしていることが分かります。エン
ドポイントは、パフォーマンスを向上させるバースティングをサポートしています。
» 「Wireless USBハブのエニュメレーショントレース」のダウンロード
(データを解読するには、まずこのトレースを開き、[View] メニュー > [Security] から、[Master Key] に
“64 FB 9F BB C1 92 62 9E 41 90 8C 7A 77 9F 9F E6” を設定します。これで、必要な一時キーが自
動的に決定されます)
» 「Ellisys Wireless USBトレースビューワ」のダウンロード
リンク品質の予測
トレースを見ると、[Instant Timing] ビューに次のような興味深い鋸歯状の波形が表示されていま
す。
これは何を意味するのでしょう？[Instant Timing] の X 軸は時間を、Y 軸はフレームのデータレー
トを表しています。フレームが高いほど、データレートが高くなります。各フレームの PHY ヘッダ
データレートフィールドを見てみると、最初のフレームが 53.3 Mbps で送信され、2 番目が 80
Mbps、3 番目が 106.7 Mbps・・・と続き、最高 480 Mbps までのデータレートで送信されています。
以下のスクリーンショットは、フレームをより詳しく表示しています。左側にある 2 つの高フレーム
は 480 Mbps で送信されるデータフレームであり、右側にある大きな青いフレームは 53.3 Mbps
で送信されるデータフレームです。同じデータ量を送信する場合、480 Mbps で送信すると 53.3
Mbps で送信した場合の 10 分の 1 以下の時間で済むのが分かります。
これらのフレームはWireless USB要求「LoopbackDataWrite」および「LoopbackDataRead」で
送信されます。Wireless USBフレームワークでもこれらの要求が特別である理由は、標準規則に
準じていないからです。データステージで送信されるデータパケットは 512 バイトに制限されてお
らず、データレートも制限されていません（53.3 Mbpsに限りません）。これらの要求は様々な目的
に使用できます。今回のケースでは、リンク品質の予測に使用されています。ホストは大きなデー
タパケットを 53.3 Mbpsでデバイスに書き込み、それを読み出します。転送に成功すると、再び 80
Mbpsで同じことを試み、順次 480 Mbpsまで行います。データレートとパケット長を変えていくこと
で、ホストはこの特定のデバイスの特定のセッションで最適なパラメータを見つけることができます。
最高のスループットを得るには、データレートを微細に調整することが非常に重要です。そして、こ
れは思うほどそう単純ではありません。5 メートルの距離では、エラーレートの理由から、108
Mbpsでの伝送が 480 Mbpsでの伝送よりもはるかに効率的なことがあります。詳しくは、Ellisys
の白書「Challenges of Migrating from USB to Wireless」の”Cutting the Wire Means More
Errors”を参照してください。（和文の「Wireless USBへの移行に伴う課題」では”無線にするとエ
ラーが増える”にあたります。）
パフォーマンス
次に、ワイヤレスハブに接続されているフラッシュディスクから、大きなファイルをコピーしてみま
す。フラッシュディスクの接続は簡単です。ハブが Wireless USB DWA プロトコルを介して有線
USB デバイスにこの接続を通知すると、ホストが Mass Storage ドライバをインストールします。
45 MB ファイルのコピーには 24 秒かかったため、スループットは 1.875 MB/秒です。このスルー
プットは驚くに値しません。Wireless USB ではもっと高いパフォーマンスを得られます。最大限の
スループットを得たいときに、非ネイティブの Wireless USB デバイスを使うのが最善策でないこと
は明らかですが、この条件を考慮してもスループットはもっと高くてよいはずです。では一体なに
が起こったのでしょう？USB 2.0 ポートに接続された同じフラッシュドライブで 7.5 MB/秒のスルー
プットを達成していることから、ワイヤレスハブでもより高いスループットを達成できるはずです。
データバーストモードでは、ホストはいくつかのデータパケットを 1 つのトランザクションにスケジ
ューリングします。以下のスクリーンショットは、Device Receive （DR） CTA をスケジューリング
する最初の MMC（オレンジ色のフレーム）を示しています。CTA は MMC の下に表示されていま
す（最後の 2 本のラインは WiMedia DRP に予約されていますが、ここでの説明は省略します）。
DR CTA は、ホストからデータを受信するためには無線を ON にしなくてはならないことをデバイ
スに通知します。MMC の直後に、ホストは Data OUT パケットをスケジュールされたとおりに送
信します（青色フレーム）。2 番目の MMC は再び DR CTA をスケジューリングしますが、今度は
3 パケットのバーストです。したがって 3 つの Data OUT パケットが表示されています。ホストは再
び 4 パケットのバーストをスケジューリングすると同時に、デバイスからハンドシェイク・パケットを
読み出すために Device Transmit （DT） CTA をスケジューリングします。バースティングはうまく
いっているようです。
では、何が問題なのでしょう？低スループットを説明するものとして唯一思い当たることは、低デ
ータレートが使用されていることです。大容量データ転送で、ホストは 53.3 Mbps と 80 Mbps の
データレートを使用しています。ドングルとハブがかなり近接していることを考えると、このデータレ
ートには首を傾げたくなります。リンク品質予測時に、大きなフレームは 480 Mbps で正常に送受
信できています。ですので、大容量転送に対しても、ホストは 480 Mbps または最低でも 320
Mbps を問題なく選択できると思われます。
ドライバによってパフォーマンス向上が期待できる部分は他にもいくつかあります。以下のスクリ
ーンショットを見ると、短縮可能なタイミングがあることが分かります。DRP 予約の開始時から最
初の MMC までの 136.901 μs です。この MMC を早めに開始することで時間を節約できます。次
に、ホストは 54.985 μs という長すぎる DR CTA をスケジューリングしています。これを回避でき
る可能性があります。また、1 つの MMC の終わりから次の MMC までの間にも 133.014 μs あり
ます。ホストによってデータ伝送がスケジューリングされていない場合は、この遅延を長くしてデバ
イスのバッテリを節約することも考えられますが、データバースト中は短縮できる可能性がありま
す。フレームが 480 Mbps で送信されるとき、このようにパフォーマンスを調整することでスループ
ットを大幅に向上できます。
以下のスクリーンショットは、バースト内の 2 つのフレーム間に約 35 μs の間隔があることを示し
ています。[Details] ビューから、フレームには BM ビットが設定されておらず、WiMedia バースト
ではないことが分かります。短時間の厳密なタイミングを得るために、実際の WiMedia バースト
は PHY によって管理されます。実際のバーストでは、PHY で SIFS（10 μs）の間隔でフレームが
分離されるか、もしくは Short Preamble モードも使用されている場合には MIFS（2.5 μs）で分離
されます（データレートが 320 Mbps 以上の場合のみ）。ここでも、いくらかの帯域幅を節約してス
ループットを上げることができます。
» 「DWA側マスストレージのトレース」のダウンロード
(マスターキーは “64 FB 9F BB C1 92 62 9E 41 90 8C 7A 77 9F 9F E6” です。)
» 「Ellisys Wireless USBトレースビューワ」のダウンロード
プロトコルへの準拠
Ellisys 社製アナライザはプロトコルの様々なアスペクトを検証し、規格に準拠していることを確認
します。ここではソフトウェアによって検出されたいくつかの項目を見ていきましょう。
再び [Instant Timing] ビューを開きます。タイミング違反は赤色のバーで表示されています。最初
にチェックするエラーは、WUSB チャネルのタイムスタンプの誤りです。以下のスクリーンショットで
は、エラーのある MMC が強調表示されています。このエラーは、MMC チャネルのタイムスタンプ
が公称値から 2 μs ずれていることを示しています。[Details] ビューから [Overview] にタイムスタ
ンプフィールドをドラッグし、カラムとして追加します（非常に便利な機能です）。タイムリファレンス
は、エラーのある MMC の前の MMC に設定します。アナライザによって測定された MMC 間の
実時間差は 282.995 μs です。レポートされたチャネルタイムスタンプ間の差は 1,180.005 ms 1,179.720 ms = 0.285 ms で、すなわち 285 μs です。チャネルタイムスタンプは、ソフトウェアに
よって通知された時間から実際に 2μs ずれています。
以下のスクリーンショットは、Ellisys ソフトウェアによって通知されたもう一つの興味深いことがら
を示しています。左側に、スーパーフレームの終わりに近い 3 つの MMC が見えます。左側の最
後の MMC は、予約の終わりの前に次の MMC をスケジューリングしますが、ホストは次の予約
の開始時にこの MMC の送信を決定します。これによってデバイスのバッテリが無意味に消費さ
れます。以下のスクリーンショットでは、デバイスがウェークアップして、ホストによってスケジューリ
ングされた次の MMC を検知します。デバイスは MMC が受信されるまで RX に留まります。この
場合は、間違った MMC がスケジューリングされているために、デバイスは 4,593 μs 間 RX に留
まります。正しくスケジューリングされた MMC を検知するために RX に留まらなくてならない時間
は約 40 μs であるため、この小さな誤りによって 100 MMC を受信するのと同じくらいの電力が消
費されます。
次に報告されたエラーは OUT パケット違反です。以下のスクリーンショットがこの違反を示してい
ます。ホストは OUT パケットを Device Receive CTA に送信しています。スケジューリングされた
DR CTA はごく小さいものですが、ホストによって送信されたパケットはかなり大きいため、CTA
に収まりません。このエラーはほんの数回発生するだけで、目に見えるほどのパフォーマンスの
低下があるわけではありません。しかし、ホストが自らのために CTA をスケジューリングしておき
ながら、長すぎるパケットを送信するのには驚きです。
[Overview] を見ると、奇妙なエラーパタンがあることが分かります。ループバック中、数回の要求
成功後に必ず 3 つか 4 つの要求が失敗しています。最初は高データレートが原因かと思いました
が、そうではありませんでした。どのデータレートでもこのエラーが発生しています。より厳密に調
べてみると、このエラーは常にスーパーフレームの始まりで発生しています。ビーコン周期後、ハ
ブは予想以上に長くホストに応答していないようです。以下のスクリーンショットから、約 10 ms の
間ハブがホスト要求に応答していないことが分かります。
このソフトウェアには WiMedia プロトコルへの準拠をテストするための優れた機能があります。こ
のツールは、[Tools] メニュー > [WiMeida Protocol Examiner] から使用できます。このツールは
非常に詳細な検証を実行して、ビーコン、DRP 予約などの WiMedia MAC 規格の様々なアスペ
クトをチェックします。このツールはデバイスの適合性を検証する目的で WiMedia Platform
Compliance イベントで使用されます。
最初にデバイスの EUI-48 を設定する必要があります。DUT は 00-17-C4-06-1B-CA、INTD は
FF-FF-FF-FF-FF-FF です。これでテストを実行すると、結果が得られます。1 つのエラーは、トレ
ース内にテストシステムが存在しないことに関連するもので、これは予想どおりです。通常、このツ
ールは準拠トレースに基づいて実行されますが、実際にはどのトレースに対してもうまく機能して
います。もっとも関連性の高いエラーは BPC-06 です。このエラーは、ビーコングループに対して
デバイスビーコンの同期が取れていない場合に発生します。
[Instant Beacons] 機能を使ってビーコンの同期化を見ることができます。この機能の素晴らしい
ところは、リアルタイムで記録されたかのようにトレースを再生できる点です。トレース内で何が起
こったのかを知るのに非常に便利です。HWA と DWA のトラフィックを再生してみると、まったくビ
ーコンの同期が取られていないことが分かります。これは WiMedia 準拠の観点からは深刻なエ
ラーだと言えます。あるデバイスがビーコンを生成し、2 番目のデバイスがビーコングループに参
加すると、BPST が非同期となってデバイスが切断され、再試行が繰り返されます。WiMedia 非
準拠の動作によって Wireless USB の動作が影響を受けることはありませんが、他の WiMedia
デバイスがこれらのデバイスと同じチャネルで動作する必要がある場合には何らかの問題が生じ
るでしょう。
Ellisys では WiMedia Platform Compliance をテストするための完全なソリューションを提供して
います。このソリューションでは Ellisys 社製のジェネレータを使用して 27 のテストケースでデバ
イスにストレスを加え、WiMedia MAC 規格のすべてのアスペクトをテストし、さらに Ellisys 社製
アナライザですべてのトラフィックを記録し、検証します。ビーコニングが機能していないため、この
ステップで Ellisys WiMedia Platform Compliance ソフトウェアを実行してもあまり意味はありま
せん。これについては今後のドライバとファームウェアのアップデートを待つことにしましょう。
1 つのチャネルで 2 つのドングルを使用する
次に、やや高度な構成を試してみます。まず最初に、同じチャネル上で 2 つのキットを使用してみ
ます。Certified Wireless USB に使用される WiMedia Platform は、1 つのチャネルが複数のア
プリケーションでどのように共有されるのかを管理します。2 つの Wireless USB ホストが同一チ
ャネル上にあるとき、これらのホストは使用可能な帯域幅を半分ずつ使用します。1 つのホストは、
完全に空いている別のチャネルを探すために、チャネルスキャンを継続することもできます。2 つ
のドングルに同一チャネルを使用させるため、WiCenter アプリケーションでこのチャネルを強制し
ます。
2 つのドングルは 2 台のコンピュータに接続されています。アナライザは、両方のドングルが一緒
にビーコニングしていることを示しており（[Instant Beacons] 参照）、接続されている一方のドング
ルがスーパーフレーム全体を予約し、他方のドングルが帯域幅をまったく確保していないことを示
しています（[Instant Superframe] 参照）。2 番目のドングルには使用できる帯域幅がないため
MMC を送信することができず、したがってどのデバイスもこのドングルを認識せず、接続すること
ができません。
ここで 2 つのハブを起動し、どうなるか見てみます。2 つのハブはドングルのビーコングループに
参加し、非常に安定した状態で同時にビーコニングしています。デバイスが 2 台のときよりも 4 台
のときのほうが、ビーコニングははるかにうまく機能しています。これはさほど驚くことではありま
せん。デバイスが 2 台しかない場合、一方のデバイスは他方のデバイスと同期を取ります。デバ
イスが 4 台の場合、1 台のデバイスは 3 台のデバイスに対して同期を取るため、より頑強です。
» 「同時にビーコンを送信する 2 つのドングル」のダウンロード
» 「同時にビーコンを送信する 2 つのキット」のダウンロード
» 「Ellisys Wireless USBトレースビューワ」のダウンロード
2 台のハブで 1 つのドングルを使用する
次に、1 つのドングルで 2 つのハブを接続してみます。これが非常にうまく機能したことは嬉しい
驚きでした。USB の初期のワイヤレスバージョン（Certified Wireless USB に準拠していないも
の）のほとんどは、ポイントツーポイントにしか対応していませんでした。つまり、1 つのドングル
には１つのハブしか使用できません。Certified Wireless USB では、有線 USB の場合と同様に、
ホスト上で最大 127 台までのデバイスを接続できます。
ハブが本当に機能していることを検証するために、各ハブでフラッシュディスクを接続し、大きなフ
ァイルを同時に転送してみます。このときも素晴らしい結果が得られました！2 ファイルのコピーが
問題なく処理され、パフォーマンスは良好でした。このことは、WirelssUSB スタックがきわめて堅
牢であることを実証しています。
»「同一ドングルで 2 台のハブを使用して 2 台のフラッシュディスクを接続する」のダ
ウンロード
» 「Ellisys Wireless USBトレースビューワ」のダウンロード
まとめ
全体として、IOGrear ソリューションのビルディングブロックは非常にうまく機能しています。もちろ
ん、消費電力を減らしたりパフォーマンスを上げるために、いくつかの点はまだ改善の余地があり
ますが、これらの問題のほとんどはドライバとファームウェアのアップグレードによって解決できま
す。これらの製品は、市場に出回り始めたばかりの初期の WirelssUSB 製品であることを忘れて
はなりません。初期の Bluetooth 製品や USB 製品を試したことがありますか？私はあります。だ
からこそ、このキットの堅牢さに非常に感動しています。クラッシュは一度もなく、パフォーマンスは
安定しています。次の Wireless USB 製品を早く試してみたいものです。
WiMedia と Wireless USB は非常に複雑なプロトコルです。USB でさえ以前の RS-232 に比べ
ればかなり複雑でしたが、USB 2.0 から Wirelss USB への移行にもそれと同じくらいの複雑さが
伴います。そこには、WiMedia プラットフォーム、セキュリティ、電力管理、パフォーマンスチュー
ニングなど、優れた製品をつくるために開発者が克服せねばならない新たな課題があります。貴
重な時間を節約するためにも、開発者らには是非とも高性能のプロトコルアナライザを利用して
欲しいと思います。
Ellisysのサイトにある、Customers Applicationも参考にしてください。ガイロジック㈱では、顧
客事例としてこれらの和文の文書を用意していますので、必要な方はお問い合わせ下さい。
本文書は、Ellisys 社が著作権を持つ文書 "IOGear GUWH104KIT Wireless USB hub &
dongle dissected" を翻訳したものです。原文との差異がある場合は、原文に従って下さい。
日本総代理店：ガイロジック株式会社
〒180-0005 東京都武蔵野市御殿山 1-6-8 ムサシヤビル 1 階
電話： 0422-26-8211、 email： sales@gailogic.co.jp

Download Report