リモート・ノード動作
リモート・ノード・ハードウェア
各ノードは、1394b物理層コントローラを組み込んだものとします。各ノードは1394aまたは、1394bリンク層コントローラを組み込むことができる。
各リモート・ノードには、外部コネクタを介して各ノードのすべてのポートを利用できるようにする必要があります。 これは、シングル・ポイント障害を構成しているため、異なるバス上のポートからの接続は、単一のコネクタ内に混在させることはできません。
コンフィグレーションROM（オプション）
各リモート・ノードには、コンフィグレーションROMを実装することができます。コンフィグレーションROMは、ハードウェアまたは、ソフトウェアで実施することができます （例えば：ソフトウェアまたは、ROM、EPROM、EEPROMなどの個別の不揮発メモリ内に格納）。 単純な非同期トランザクションを利用することを計画しているなら、最小限のコンフィグレーションROMを含むことを推奨します。
ノーマル・バス動作
リモート・ノードは、アイソクロナス・リソース・マネージャ、バス・マスタ、ルート・ノード、またはサイクル・マネージャーを争奪するルート・ホールドオフ・ビット（RHB）を設定してはなりません。
各リモート・ノードは、少なくとも2つのチャンネルを監視しなければなりません。 2つのチャンネルはSTOFチャンネルに対して使用され（この例では、チャンネル31）、いずれかのチャンネルを使用し、システム設計によりそのノードの固有のチャンネルです。
バスの初期化および、「3.2.5 IEEE-1394bデータ・バス初期化とコンフィグレーション」で説明したようなコンフィグレーションに続き、 各リモート・ノードは、CCが送信するSTOFメッセージを待機しなければなりません。 STOFメッセージの後に、必要に応じて新しいSTOFオフセットを決定するため、 リモート・ノードは、CCから受信した最初の有効なメッセージをチェックしなければなりません。
システム設計を介して、各リモート・ノードは、システムの実装によって要求されるように、±0.5％のSTOFフレーム・レート、CC（STOF送信オフセット）にデータを送信するSTOFに対する時間を割当てなければなりません。 複数のCCツリーに接続されているノードは、サプライヤーにより定義され、買い手が承認したアルゴリズムを使用してSTOFを選択されます。 各リモート・ノードは、それぞれの電源投入時／初期化時に、一度だけ、送信するためにその時間を再設定することができなければなりません。 各リモート・ノードはSTOFメッセージの後CCに、システムの実装に依存した時間データを送信することが可能でなければなりません。 ノードが他のリモート・ノードへのメッセージを含めて、送信する複数のメッセージを持っている場合、それらのメッセージは、オフセットSTOFの送信に基づいて、Back-to-Backされなければなりません。 CCへのメッセージは、最初に、続いて、Back-to-Back、他のノードにアドレスされた任意のメッセージが、送信されなければなりません。 STOF送信オフセット・タイム割当て内に、すべてのメッセージが送信されなければなりません。 リモート・ノードは、それが使用しているSTOFオフセット（デフォルトまたはCC更新）と1-3パケット・トレーラのワードを埋めるものとする。
システムの実装によって要求されるように、±0.5％のSTOFフレーム・レート、各リモート・ノードは、CC（STOF受信オフセット）からのデータを待つSTOFに対する時間を割当てなければなりません。 複数のCCブランチに接続されているノードは、サプライヤーによって定義され、買い手が承認したアルゴリズムを使用してSTOFを選択します。 各リモート・ノードは、それぞれの電源投入時／初期化時に、一度だけ、CCからのデータを待つために、再設定することができなければなりません。 各リモート・ノードは、STOFメッセージの後に、CCからシステム実装に依存する時間データを受信可能でなければなりません。 リモート・ノードに送信された複数のメッセージは、リモート・ノードで、連続的に受信されなければなりません。 任意のレイテンシ・クリティカル・データ・メッセージは、STOF受信オフセットに基づいて行われなければなりません。
この文書を通して、各リモート・ノードは、データポンプ（STOFデータ・ダンプ・オフセット）の目的のために使用することができるSTOFに対する時間、 システムの実装に必要とされる±0.5%のSTOFフレーム・レートを割当てなければなりません。複数のCCブランチに接続されたノードは、サプライヤーによって定義され、 買い手が承認したアルゴリズムを使用してSTOFを選択します。
各リモート・ノードは、それぞれの電源投入時／初期化時に、一度だけ、データポンプのデータを送信するために、その時間を再設定することができなければなりません。 各リモート・ノードは、STOFメッセージの後に、データポンプのデータをシステム実装に依存する時間を送信可能でなければなりません。
各リモート・ノードは、レイテンシ・クリティカル出力または、レイテンシ・クリティカル入力のどちらかを持ちますこの定義は、システム設計によって提供されなければなりません。
非同期ストリーム・パケットのみで構成される、バス動作の全体図は、図16を参照してください。これは、100Hzのフレーム・レートの場合について示しています。
図16 通常バス動作
データポンプ・データ説明 [Datapump Data Description]
一方向のみのデータポンプ・メッセージは、統合とテスト動作をサポートするために、内部ソフトウェア・パラメータまたは、メモリ位置のデータを含みます。 データワードは、リモート・ノードからの通常の送信メッセージにすでに含まれていない情報になります。 データポンプ・メッセージ・ノード・チャンネルの割当ては、システム設計により特定のシステムのために確立されています。 データ・メッセージは、受信されたメッセージ・トレーラで、STOFデータポンプ・オフセット・ワードによって、定義されたバス上に送信されます。
リモート・ノード・スタートアップ／初期化 [Remote Node Start-Up/Initialization]
電源投入または、リセット時、自身の初期化および、任意のセルフテスト完了後、リモート・ノードはCCからの入力を監視しなければなりません。 リモート・ノードは、適切にフレーム定義された数に相当する期間の後にCCからSTOFメッセージのタイミングを検出していない場合、 リモート・ノードはCCが無効であることを認識しなければならないが、有効なSTOFメッセージのためにバスの監視を継続しなければなりません。
有効なSTOFメッセージを受信すると、CCによって送信された最初のメッセージのために、STOF受信オフセットでリモート・ノードは、その割当てられた送信先チャンネルを監視しなければなりません。 CCからリモート・ノードへ送信された最初のメッセージは、送信、受信および、データポンプのためのSTOFオフセット時間を含まなければなりません。 これらのオフセットは、システム設計によって割当てられたものとは、異なっていても、異なっていなくてもかまいません。 これらのSTOFオフセット時間のいずれか、または、全てが割当てられたオフセットと異なる場合、リモート・ノードは、新しいオフセットを使用し、次のSTOFフレームを開始しなければなりません。 電源投入または、リセットが発生する前に、異なるSTOFオフセットが、任意の連続するパケットを受信した場合、リモート・ノードは、それらを無視し、前のオフセットを継続して使用しなければなりません。
リモート・ノードは、その後、通常の動作やバス通信を開始しなければなりません。
システム整合性管理
各リモート・ノードは、CC（STOFメッセージを含む）の故障状態を判断するため、適切な1394バス動作を確認するため、および、 正しく動作するメッセージを生成するCCソフトウェア検証のため、CCからの入力を監視しなければなりません。
ノードが通常のバス動作中に、CCからのデータを受け入れるようにするためには、次のすべての条件を満たさなければなりません；
a. STOFメッセージは、リモート・ノードによって決定される場合に有効です。
b. STOFメッセージが有効
c. STOFメッセージは、CCがlegal動作モードであり、「良い」状態であることを示す。
d. CCからノードへのメッセージが有効
次の例では、100Hzのフレーム・レートを想定しています。
条件1：
STOFメッセージが、以前のメッセージから10.0msec ± 50usec～150usecで受信された場合、
以前のSTOFの有効（条件1および、2によって決定される）にかかわらず、有効とみなさなければなりません。
STOFメッセージが、連続するフレームの定義された数のために、上記の条件を満たしていない場合、リモート・ノードは、失敗したと判断して、適切なCCを認識しなければなりません。
例外は、CCが電源投入／初期化または、セルフテスト・モードにあるときに行われる必要があります。
条件2：
STOFメッセージ・タイミングが条件1ごとに正しい場合、ノードは、メッセージの有効性をチェックしなければなりません。
データ有効性指標（例えば、垂直パリティ・チェック）が正しい場合は、メッセージが有効とみなされなければなりません。
上記の条件が失敗した場合、リモート・ノードは、CCからリモート・ノードへのメッセージを無視しなければなりません。 STOFメッセージが、連続するフレームの定義された数のために無効である場合、リモート・ノードは、失敗したと判断して、適切なCCを認識しなければなりません。
条件3：
STOFメッセージは、条件1および、2を介して有効であると決定されると、リモート・ノードはCCの状態をチェックしなければなりません。
ステータス表示が、失敗であると示している場合、失敗したと判断して、CCを認識し、CCからの任意のメッセージを無視しなければなりません。
前述の3つの条件のいずれかが失敗した場合、CCの故障状態にかかわらず、リモート・ノードは（決定可能であれば）適切な時間にCCにデータを送信し続けなければなりません。 リモート・ノードが適切な送信時間を決定することができない場合、送信を中止しなければなりません。
条件4：
STOFメッセージが、条件3を介して良好なCCの状態を示している場合、ノードは受信したメッセージの有効性をチェックしなければなりません。
次の条件を満たしている場合、データ・メッセージは有効なものであると判断されます：
- ASMメッセージ・ヘッダ内のハートビートが、最後の受信したメッセージ以降インクリメントされていること
- データ有効性指標（垂直パリティ・チェックおよび、ヘルス・ステータス・ワード）が正しいこと
上記の条件のいずれかが失敗した場合、リモート・ノード（決定可能であれば）は、メッセージを無視しなければなりません。 リモート・ノードは、受信したメッセージの障害状態にかかわらず、適切な時間にCCにデータを送信し続けなければなりません。 上記条件のいずれかが失敗した場合、連続するフレームの定義された数のために、リモート・ノードは、失敗したと判断して、適切なCCを認識しなければなりません。 リモート・ノードが適切な送信時間を決定することができない場合は、送信を中止しなければなりません。
図17 システム整合性管理のフローチャート
データ・パケット・タイプ
IEEE-1394ネットワークは、非同期ストリームをサポートしなければなりません。非同期とアイソクロナス・パケットは必須では無く、必要に応じて使用することができます。 典型的な非同期ストリーム・パケットを図5に示します。
非同期ストリーム
非同期ストリームは、指定された周期的レートで発生しなければなりません。周期は、利用可能な帯域幅とメッセージの使用量に基づいて定義されなければなりません。 すべての非同期ストリーム・メッセージは、「3.2.4.1.7 ASM ヘッダ [ASM Header]」で定義された、匿名サブスクライバ・メッセージ・ヘッダおよび、 「3.2.4.1.9 パケット・トレーラ [Packet Trailer]」で定義されたパケット・トレーラを含むSTOFおよび、テストモード・メッセージを除かなければなりません。 バス上のすべてのリモート・ノードは、フレーム毎に、少なくとも一つの非同期ストリーム・メッセージを送信しなければならないので、CCは接続状態を維持することができます。
非同期トランザクション
非同期トランザクションは、コマンドおよび、制御に使用され、必要に応じて、メッセージのために本質的に非同期とみなされてもよい。 非同期トランザクションに対する応答または、リターンが非同期トランザクションの受信ではなくSTOFオフセット時間送信に続いて返信されなければなりません。 受信ノードが非同期トランザクションの無効なメッセージIDを検出した場合、アドレス・エラー応答を返します。ルールは、非同期パケットは、システムのタイミング制約に準拠していることを定義する必要があります。
アイソクロナス・パケット
アイソクロナス・パケットは必須では無く、必要に応じてストリーミング・オーディオやビデオなどのタスクのために使用することができます。 アイソクロナス・パケットは、ASMヘッダやパケット・トレーラを使用せずに、IEEE-1394標準のアイソクロナス・メッセージのパケット・フォーマットを使用します。
アイソクロナス・パケットを使用しながら、AS5643仕様書に定められた固定フレーム・レートの方法論の整合性を維持するために、 非同期ストリームとアイソクロナス・パケットの両方のために（時間に変換）必要な帯域幅を、明示的に固定されたフレーム間隔内に配置される必要があり、その結果、
Total Frame Time = Asynchronous Stream Time + Isochronous Time
全フレーム時間 = 非同期ストリーム時間 + アイソクロナス時間
となります。はじめに、全フレーム時間内のアイソクロナス・メッセージ時間集合を合計し、合計フレーム時間からその分を差し引きます。 そして、非同期ストリーム・パケットの残り時間を割当てると全体の時間になります。これについて、図18に示します。
図の上半分に示す「予約済み非同期ストリーム帯域幅全体」は、その残りに割当てられた非同期ストリーム・ノード・トラフィックに割当てられ100%となります。 しかし、STOF送信オフセット時間は、各ノードに割当てられ、それらは、図18の下半分に示すように、インターレース・アイソクロナス・データを収容する総フレーム時間間隔にわたって広がっている。 アイソクロナスデータパケットは、常にそれぞれのサイクルが公称125μsec周期で起動するには、次のバス・アクセスに最初に優先されます。 バス・トラフィックの両方のタイプを、明示的に総フレーム時間内に割当てているので、両方の合計は、各フレームの時間内に必要なすべてのトランザクションを完了することができます。
図18 予約された帯域幅の割当て、および、混合データとのSTOF送信オフセット
アイソクロナス・メッセージ送信用のチャンネル番号は非同期ストリーミング・パケットと同様に事前に定義されなければなりません。 しかし、それはサイクル・マスタ（CM）機能を利用する必要があります。そのため、125μsec周期サイクルの始まりは、それらを期待するアイソクロナス・ソースに使用可能です。 これは、サイクル・マスタ機能を実行することが望ましく、また、IRMが原因でシステムの決定に考慮するために利用されるものでは無く、 「1.4.5 帯域の事前割当て」で定義された帯域をあらかじめ割当てることが望ましいです。
同期および、非同期ストリーム・パケット・タイプのインターリビングは、各リモート・ノードのSTOF時間のための「soft（柔軟）」不定期境界を作成する効果を持つことになります。 アイソクロナス・パケットの収容によって導入された「softness（柔軟性）」の度合いは、アイソクロナス・パケットに使用するバス帯域幅の量、アイソクロナス・パケットの最大サイズ、 および、アイソクロナス・パケット・ソースの規則性と反復率の関数になります。
個々のシステムは、現在の「soft（柔軟）」STOFオフセット・タイムの程度と一致し、STOF割当てを設計する必要があります。
この「softness（柔軟性）」のため、レイテンシ・クリティカル非同期ストリームが必要とされる場合、アイソクロナス転送および、サイクル開始パケットを利用すべきではありません。