JP2009094588A - ネットワークシステム - Google Patents

Abstract

【課題】 何らかの理由でマスタノードから切り離されてしまった装置群があった場合でも、その装置群の間で、ループ状の伝送経路に沿って一定周期で循環させるフレームを用いたデータ伝送を行えるようにする。
【解決手段】 それぞれ送信Ｉ／Ｆと受信Ｉ／Ｆを２組備えた複数のノードをカスケード接続し、マスタノードが生成する、複数の音響信号の記録領域を備えたＴＬフレームを、各ノード間に一定周期毎に循環させることにより、ノード間で音響信号の伝送を行うオーディオネットワークシステムにおいて、各ノードがＲＴＬモードとＴＴＬモードの動作を選択的に行えるようにし、ノード間の接続の切断によって生じた２つのノード群のうち、マスタノードが存在する側のノード群の各ノードは、ＲＴＬモードの動作を維持し、マスタノードが存在しない側のノード群の各ノードは、自動的にＴＴＬモードの動作に移行するようにした。
【選択図】 図２１

Description

この発明は、複数のノード間で音響信号の伝送を行うためのネットワークシステムに関する。

従来から、複数のノード間で音響信号の伝送を行うためのオーディオネットワークシステムが知られており、コンサート、演劇、音楽製作、構内放送等において用いられている。このようなオーディオネットワークシステムの例としては、以下の非特許文献１，２に記載のような、ＣｏｂｒａＮｅｔ（商標），ＥｔｈｅｒＳｏｕｎｄ（商標）が知られている。

「CobraNet(TM)」、[online]、バルコム株式会社、［平成１８年３月２１日検索］、インターネット＜ＵＲＬ：http://www.balcom.co.jp/cobranet.htm＞ Carl Conrad、「EtherSound(TM) in a studio environment」、[online]、Digigram S.A.、［平成１８年３月２１日検索］、インターネット＜ＵＲＬ：http://www.ethersound.com/news/getnews.php?enews_key=101＞

また、オーディオネットワークシステムには、一般的に、アナログ入力，アナログ出力，デジタル入力，デジタル出力，ミキシング，エフェクト付与，録音再生，リモート制御，あるいはこれらの組み合わせ等の各種機能を有する音響機器を任意に接続できることが要望される。

しかしながら、このような従来のオーディオネットワークシステムには、以下のような問題があった。
すなわち、例えばＣｏｂｒａＮｅｔ（商標）においては、バス型のネットワークに複数のノードがそれぞれ作成したフレーム（複数フレーム）を送信するので、フレーム間のギャップが生じて伝送効率が悪いという問題があった。

また、物理的に伝送可能なチャンネル（ｃｈ）数が、ノード間の結線（ネットワークの構成）の変更によって変化するため、フレームの伝送ルートを考慮して、必要なｃｈ数の伝送ができるようにシステムを構成しなければならず、設計が難しいという問題があった。
これは、送信元のノードから末端のノードまでのノード数によってデータが届くまでの時間が変わり、かつ、全ノードにデータが届くまで次の通信をしないため、ネットワークを構成するノード数が多いとデータの転送に時間がかかり、帯域をロスする等の理由によるものである。

また、ＥｔｈｅｒＳｏｕｎｄ（商標）においては、障害発生時に音切れを防止する対策が取られておらず、ノード間の結線の切断が生じた場合に音声がストップしてしまうという問題があった。フレームに複数のパケットが含まれているため、伝送制御が複雑になる上に、時間当たりで伝送できるデータ量が十分でないという問題もあった。
さらに、ＣｏｂｒａＮｅｔ（商標）の場合と同様、フレームの伝送ルートを考慮して、必要なｃｈ数の伝送ができるようにシステムを構成しなければならず、設計が難しいという問題もあった。

そこで、本件出願人は、これらの問題を解決する技術として、所定周期で音声伝送フレームを循環させるリング型の伝送経路を有するオーディオネットワークシステムを提案した（特願２００６−８４２５３）。
このネットワークシステムにおいては、音声伝送フレーム内に波形データをベタで記録しているため、管理が簡単であり、通信帯域を無駄なく利用して音声伝送を行うことができる。また、音声伝送フレームにシステム内の全ノードを巡回させるため、フレームの伝送ルートを特に意識せずにノード間の結線の変更を簡単に行うことができる。

また、このネットワークシステムは、システムを構成可能なノードが接続された場合に、音声伝送フレームの生成を行うマスタノードを自動的に決定し、接続されたノード間で音声信号を伝送するモードに移行する構成となっている。
そして、このネットワークシステムにおいては、一旦音声信号を伝送するモードに移行した後、ケーブルの切断やノードの異常等により、音声伝送フレームの伝送経路が切断された場合でも、マスタノードの存在する側では、切断の生じた位置で伝送経路を切り縮めて、縮小された伝送経路の範囲で音声伝送フレームの伝送を継続できる。

しかしながら、このネットワークシステムにおいては、切断により分断されたシステムのうち、マスタノードの存在しない側では、リング型の伝送経路を用いたデータ伝送ができなくなってしまうという問題があった。
一方、リング型の伝送経路を循環させるフレームには、波形データ以外にも、コマンドやイーサネットフレーム等の種々のデータを記載して伝送し、そのデータをノード間で授受させることが考えられる。従って、マスタノードと切り離されてしまった装置についても、リング型の伝送経路を用いたデータ伝送を維持したいという要望があった。
そして、上述したこれまでのネットワークシステムでは、このような要求に十分に応えることはできなかった。

この発明は、このような問題を解決し、マスタノードが生成する、複数の音響信号の記憶領域を備えた音声伝送フレームを各装置間に形成されるループ状の伝送経路に沿って一定周期で循環させるネットワークシステムを構成する際に、何らかの理由でマスタノードから切り離されてしまった装置群があった場合でも、その装置群の間で、ループ状の伝送経路に沿って一定周期で循環させるフレームを用いたデータ伝送を行えるようにすることを目的とする。

上記の目的を達成するため、この発明のネットワークシステムは、それぞれ単方向の通信を行う受信手段及び送信手段を２組備えた複数のノードを、あるノードの１組の受信手段及び送信手段を次のノードの１組の送信手段及び受信手段とそれぞれ通信ケーブルで接続することにより順次接続して形成したネットワークシステムにおいて、上記各ノードに、（ａ）上記複数のノードのうち１つを臨時のマスタノードと定め、その臨時のマスタノードが生成する、コマンド伝送のための初期通信フレームの記憶領域を備えた伝送フレームを各装置間に形成されるループ状の伝送経路に沿って一定周期で循環させ、各ノードでその伝送フレームへ上記初期通信フレームの書き込み及び／又は読み出しを行うことにより、接続された一連のノード間で初期通信フレームの伝送を行う臨時通信モード、及び（ｂ）上記複数のノードのうち１つをマスタノードと定め、そのマスタノードが生成する、複数の音響信号の記憶領域を備えた音声伝送フレームを各装置間に形成されるループ状の伝送経路に沿って一定周期で循環させ、各ノードでその音声伝送フレームへ音響信号の書き込み及び／又は読み出しを行うことにより、接続された一連のノード間で音響信号の伝送を行う音声伝送モードによる通信を選択的に実行する通信制御手段を設け、そのネットワークシステムにおいてマスタノードが設定された場合に、そのマスタノードによる制御の下で、上記各ノードに上記音声伝送モードの動作を開始させ、そのネットワークシステムのいずれかの箇所においてノード間の接続の切断が生じた場合に、その切断によって生じた２つのノード群のうち、上記マスタノードが存在する側のノード群の各ノードは、上記音声伝送モードの動作を維持してその各ノードにより形成されるループ状の伝送経路にそって上記音声伝送フレームの循環を継続し、上記マスタノードが存在しない側のノード群の各ノードは、自動的に上記臨時通信モードの動作に移行するようにしたものである。

このようなネットワークシステムにおいて、上記各ノードの通信制御手段を、上記送信手段からその送信手段と接続されている隣接装置に対して上記初期通信フレームを送信させる初期通信モードの動作も可能な手段であり、かつ、ノードの起動時又はリセット時にはその初期通信モードで動作する手段とし、そのネットワークシステムにおいて、上記音声伝送モード又は上記臨時通信モードにおいて形成されるループ状の伝送経路の端部に位置するノードは、上記初期通信モードで動作中のノードが自ノードに直接接続されていることを検出した場合にその初期通信モードで動作中のノードにアクセスしてそのノードを自ノードが属するループ状の伝送経路に組み入れ、上記臨時通信モードで動作中のノードが自ノードに直接接続されていることを検出した場合にその臨時通信モードで動作中のノードにリセット命令を送信してリセットを行わせ、そのノードの動作を上記初期通信モードに戻した上でそのノードにアクセスしてそのノードを自ノードが属するループ状の伝送経路に組み入れる動作を行うようにするとよい。

さらに、上記各ノードに、上記リセット命令を受信した場合に、上記ループ状の伝送経路の形成に関する自機の機能をリセットして上記ループ状の伝送経路から離脱すると共に、そのリセット命令を受信した側と反対側の隣接装置に対してリセット命令を送信するリセット伝達手段を設けるとよい。

さらに、上記初期通信モードで動作中のノードが、同じく初期通信モードで動作中のノードが自ノードに直接接続されていることを検出した場合に、その検出したノードとネゴシエーションして、自ノードとその検出したノードのいずれかを上記臨時のマスタノードに設定し、自ノードとその検出したノードとを上記臨時通信モードに移行させて、自ノードとその検出したノードとで上記ループ状の伝送経路を形成するようにするとよい。
さらに、上記音声伝送モード又は上記臨時通信モードにおいて形成されるループ状の伝送経路の端部に位置するノードは、自ノードと異なるループ状の伝送経路を形成し、かつ上記音声伝送モードで動作中のノードが自ノードに直接接続されていることを検出した場合、その検出したノードを自ノードが属するループ状の伝送経路に組み入れる動作を行わないようにするとよい。

以上のようなこの発明のネットワークシステムによれば、マスタノードが生成する、複数の音響信号の記憶領域を備えた音声伝送フレームを各装置間に形成されるループ状の伝送経路に沿って一定周期で循環させるネットワークシステムを構成する際に、何らかの理由でマスタノードから切り離されてしまった装置群があった場合でも、その装置群の間で、ループ状の伝送経路に沿って一定周期で循環させるフレームを用いたデータ伝送を行えるようにすることができる。

以下、この発明を実施するための最良の形態を図面に基づいて具体的に説明する。
１． この発明の実施形態のオーディオネットワークシステムの概要
１．１ 全体構成
まず、図１に、この発明のネットワークシステムの実施形態であるオーディオネットワークシステムの概略を示す。
図１（ａ），（ｂ）に示すように、このオーディオネットワークシステム１は、それぞれ単方向の通信を行う受信手段である受信インタフェース（Ｉ／Ｆ）と送信手段である送信Ｉ／Ｆの組を２組備えたノードＡ〜Ｃを、通信ケーブルＣＢで順次接続することにより構成したものである。ここでは３つのノードにより構成した例を示しているが、ノードの数は任意でよい。

ノードＡにおいては、受信Ｉ／Ｆ＿ＡＲ１と送信Ｉ／Ｆ＿ＡＴ１が一組のＩ／Ｆで、受信Ｉ／Ｆ＿ＡＲ２と送信Ｉ／Ｆ＿ＡＴ２がもう一組のＩ／Ｆである。ノードＢ及びＣについても、符号の先頭の文字「Ａ」を「Ｂ」あるいは「Ｃ」に置き換えたＩ／Ｆが、同様な関係に当たる。

そして、ノード間の接続は、１組の受信Ｉ／Ｆ及び送信Ｉ／Ｆを、別のノードの１組の送信Ｉ／Ｆ及び受信Ｉ／Ｆとそれぞれ通信ケーブルＣＢで接続することにより行っている。例えば、ノードＡとノードＢとの間では、受信Ｉ／Ｆ＿ＡＲ２と送信Ｉ／Ｆ＿ＢＴ１とを接続すると共に、送信Ｉ／Ｆ＿ＡＴ２と受信Ｉ／Ｆ＿ＢＲ１とを接続している。また、ノードＢとノードＣとの間では、ノードＢのもう１組のＩ／Ｆと、ノードＣの１組のＩ／Ｆとを接続している。
なお、図１に示す各ノードは、アナログ入力，アナログ出力，デジタル入力，デジタル出力，ミキシング，エフェクト付与，録音再生，リモート制御，あるいはこれらの組み合わせ等の各種機能を有する音響信号処理装置である。ノード毎に機能が違っていても当然構わない。

ここで、（ａ）に示すように、各ノードを、端部を有する１本のラインのように接続した状態を、「カスケード接続」と呼ぶことにする。そしてこの場合、各ノード間を結ぶケーブルＣＢにより、破線で示すように１つのリング状のデータ伝送経路を形成することができ、各ノードは、この経路でフレームを一定周期で循環させるように伝送し、そのフレームに対して必要な情報を読み書きすることにより、経路上の任意のノードとの間でデータの送受信を行うことができる。このように、システム内に１つのリング状のデータ伝送経路が構築する動作モードを、「シングルモード」と呼ぶことにする。
そして、オーディオネットワークシステム１内において、１つのノードがマスタノードとなり、音響信号を伝送するためのフレームを生成し、定期的に伝送経路を循環させたり、ネットワークの管理を行ったりする。このマスタノードが生成するフレームを、その他のフレームと区別して「ＴＬフレーム」と呼ぶことにする。

また、（ａ）に示したカスケード接続に加え、両端のノードで使用していないＩ／Ｆ同士も通信ケーブルＣＢで接続すると、（ｂ）に示すように、リング状のデータ伝送経路を２つ形成することができる。そして、各ノードは、これらの経路でそれぞれフレームを伝送し、その各フレームに対して必要な情報を読み書きすることにより、経路上の任意のノードとの間でデータの送受信を行うことができる。このようなノード間の接続状態を、「ループ接続」と呼ぶことにする。また、システム内に２つのリング状のデータ伝送経路を構築する動作モードを、「ツインモード」と呼ぶことにする。

ただし、オーディオネットワークシステム１においては、シングルモードの動作が基本形であり、ツインモードの動作を許可するか否かは、マスタノードに設定しておく。そして、ツインモードの動作を許可しない設定がなされている場合には、後述のように、ループ接続がなされた場合でもシングルモードの動作を継続する。従って、接続状態と動作モードとは、必ずしも対応しない。

また、図１ではケーブルを２本示しているが、１組の受信Ｉ／Ｆと送信Ｉ／Ｆとを近接してあるいは一体として設ければ、２本を束ねて１本にしたケーブルにより、１組のＩ／Ｆ同士の接続を行うことも可能である。
また、各ノードには、必要なＩ／Ｆを設ければ、（ｃ）に示すように、外部機器Ｎを接続し、外部機器Ｎから受信したデータをＴＬフレームに書き込んで他のノードに送信したり、ＴＬフレームから読み出したデータを外部機器Ｎに送信したりすることもできる。

このような外部機器Ｎとしては、例えば外付けのコンソールが考えられる。そして、コンソールがユーザから受け付けた操作に応じたコマンドをノードＢに送信し、ノードＢがこれをＴＬフレームに書き込んで他のノードに送信したり、他のノードがＴＬフレームに書き込んで送信してきた応答やレベルデータ等をノードＢが読み出してコンソールに送信し、コンソールにおける操作子状態の表示やレベル表示に使用するといった動作を行わせることが考えられる。

１．２ ＴＬフレームの構成
次に、図２に、上述した伝送経路で伝送されるＴＬフレームの構成例を示す。また、図３に、ＴＬフレーム中の波形データ領域、イーサネットフレーム領域及びＩＴＬフレーム領域のより詳細な構成を示す。なお、これらの図に示した各領域の幅は必ずしもデータ量と対応しない。

図２に示すように、このＴＬフレーム１００は、サイズが１２８２バイトであり、先頭から順に、プリアンブル１０１，管理データ１０２，波形データ（オーディオデータ）領域１０３，制御データ領域１０４，ＦＣＳ（Frame Check Sequence）１０５の各領域からなる。各領域のサイズは、その領域に記載するデータ量に関わらずそれぞれ一定である。また、ここで示すＦＣＳ１０５以外の各領域のサイズは一例であり、適宜変更してよい。

そして、プリアンブル１０１は、計８バイトのデータであり、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．３で規定されるプリアンブルとＳＦＤ（Start Frame Delimiter）とを記載する。

また、このオーディオネットワークシステム１においては、送信Ｉ／Ｆから送出されるフレームは、１本の接続ケーブルＣＢで接続された受信Ｉ／Ｆにしか届かないから、アドレスの記載はあまり意味がない。そこで、ＴＬフレーム１００には、宛先アドレスは記載する必要はなく、ここではその記載領域は設けていない。

また、管理データ１０２は、８バイトのデータであり、オーディオネットワークシステム１内の各ノードがＴＬフレームに含まれるデータの管理に利用するデータとして、フレームの種類を区別するためのフレームタイプ，システム内のどの伝送経路を循環させるかフレームかを示すリングＩＤ，フレーム通し番号であるフレームＩＤ，波形データ１０３中の波形データのｃｈ数等を記載する。なお、フレームタイプとしては、このフレームがＴＬフレームであることを示すデータを記載する。また、ツインモードを許可しない場合、システム内の伝送経路は１つのみであるから、リングＩＤは固定の値となる。

そして、波形データ領域１０３としては１０２４バイトを確保し、音響信号のデータである１サンプル３２ビットの波形データを２５６ｃｈ分記載できる。すなわち、本システムでは、１つのＴＬフレーム１００を循環させることにより、２５６ｃｈ分の音響信号を伝送することができる。なお、２５６ｃｈ中の伝送に使われていないｃｈ（空きｃｈ）の領域については、そこに何が記載されているか気にしなくて良い。本実施形態では、伝送する波形データのビット数が３２ビットでない例えば１６ビットや２４ビットなどの場合でも、各ｃｈ毎に３２ビットの領域を用意しその領域内に記載するようになっている。しかし、波形データのビット数に応じて各ｃｈの領域のサイズを変更するようにしてもよい。その場合、１６ビットの波形データは５１２ｃｈ分伝送可能であり、２４ビットであれば３４０ｃｈ分伝送可能になる。

また、図３（ａ）に示すように、波形データ領域１０３においては、予めオーディオネットワークシステム１を構成する各ノードにｃｈを割り当てておき、各ノードは、自身に割り当てられたｃｈの位置に、出力波形データの書き込みを行う。このｃｈの割り当ては、システム全体を制御するコントローラ（例えば、何れかのノードの制御ＣＰＵや図１（ｃ）に示した外部機器）が行うものであり、システムの動作中に適宜変更可能である。また、ノード毎に連続した位置のｃｈを割り当てる必要はないし、どのノードにも割り当てない空きｃｈがあってもよい。

一方、制御データ領域１０４としては２３８バイトを確保し、ここには、イーサネットフレーム領域１０６、ＩＴＬフレーム領域１０７、および管理データ領域１０８設けている。
このうちイーサネットフレーム領域１０６には、ＩＰ（Internet Protocol）に基づくノード間通信用のパケットであるＩＰパケットをさらにフレーム化したＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．３形式のフレーム（イーサネットフレーム）を記載する。

また、記載すべきイーサネットフレームが用意したサイズ（ここでは１７８バイト）に収まらない場合には、フレームの送信側で必要な数のブロックに分割し、ＴＬフレーム１つにつき、そのブロック１つを記載する。そして、フレームの受信側で複数のＴＬフレーム１００からデータを取り出して結合し、分割前のフレームを復元することにより、通常のイーサネット（登録商標）での伝送と同様にイーサネットフレームをノード間で伝送することができる。
ＩＥＥＥ８０２．３形式のフレームの最大サイズは１５２６バイトであり、一方、分割・復元の制御用に数バイトの分割制御データを加えたとしても、１ＴＬフレーム毎に約１７０バイトの送信ができるので、１つのイーサネットフレームの送信は、最大でも９フレームで完了する。

図３（ｂ）に、このイーサネットフレーム領域１０６に記載するデータの詳細を示す。
このうち、ブロック数は、送信するフレームをいくつのブロックに分割したかを示す情報である。
ブロック番号は、該当ブロックが分割したブロックのうち何番目のブロックであるかを示す情報である。
送信元ＩＤは、イーサネットフレーム領域１０６へデータを書き込んだノードを示す情報である。後述するフリートークンは、この送信元ＩＤを特殊な値に設定することにより記載できる。また、送信元ＩＤは、装置のＭＡＣアドレスにより記載することができる。なお、オーディオネットワークシステム１のノードとなる各装置は、送信Ｉ／Ｆと受信Ｉ／Ｆを２つずつ備えているが、それぞれ別個のＭＡＣアドレスを持つのではなく、装置として１つのＭＡＣアドレスを持つ。

データサイズは、該当ブロックに記載したフレームデータのサイズを示す情報である。
フレームデータは、送信するイーサネットフレームのデータである。最終ブロックについては、末尾に空き領域ができるが、受信側で、データサイズの情報に従って、データのある領域のみ読み取るようにすれば問題ない。

また、ＩＴＬフレーム領域１０７には、隣接ノード間でのコマンド及びコマンドに対する応答の伝送に使用するフレームであるＩＴＬフレームのデータを記載する。このＩＴＬフレームは、後述のように、システム形成初期の情報伝達にも使用するし、システム形成後の情報伝達にも使用する。
またここでも、イーサネットフレーム領域１０６の場合と同様、記載すべきＩＴＬフレームが用意したサイズ（ここでは５０バイト）に収まらない場合には、フレームの送信側で必要な数のブロックに分割して記載し、受信側でこれを結合して復元することができる。

図３（ｃ）に、このＩＴＬフレーム領域１０７に記載するデータの詳細を示す。
この図に示したブロック数、ブロック番号、データサイズ、フレームデータ、空き領域は、上述のイーサネットフレーム領域１０６の場合と同趣旨である。
しかし、ＩＴＬフレームの場合は、基本的には隣接ノードへの情報の伝達に用いるものである。そして、離れたノードに伝達する場合でも、後述のように、途中のノードが一旦内容を参照した上で同じ内容のフレームを次のノードに送信する、という方式で伝送を行う。従って、ＩＴＬフレーム領域１０７にデータを書き込んだノードは、必ずその書き込んだノードの隣接ノード（ＴＬフレームを入力した受信Ｉ／Ｆと直接接続されているノード）である。このため、ＩＴＬフレーム領域１０７には送信元ノードＩＤの記載は必要ない（ただし、後述のように、ＩＴＬフレーム自体には送信元ノード及び宛先ノードを示す情報としてそれらのノードのＭＡＣアドレスを記載する）。

管理データ領域１０８は、オーディオネットワークシステム１内の各ノードがＴＬフレームに含まれるデータの管理に利用するデータを記載する領域である。ここに記載するデータとしては、例えば、ＴＬフレーム１００が伝送中に切断されたことを示す切断検出フラグＳＤＦ，ＴＬフレーム１００の伝送にエラーが生じたことを示すエラーフラグＥＤＦ，レベル表示に使用するレベルデータ等が挙げられる。
なお、制御データ領域１０４内にＩＴＬフレームや管理データを記載する専用の領域（ここでは各１０バイト）を設けたのは、それらのデータを定常的に伝達するためである。
また、ＦＣＳ１０５は、ＩＥＥＥ８０２．３で規定される、フレームのエラーを検出するためのフィールドである。

次に、図４に、ＩＴＬフレームのデータ構成を示す。
ＩＴＬフレームの形式には２通りのものがあり、上述のＩＴＬフレーム領域１０７に書き込むのは、図４（ａ）に示す通常の形式のものである。（ｂ）に示すのは、特殊な用途に用いるＩＴＬフレームの形式である。
このうち、（ａ）に示す通常のＩＴＬフレーム１１０は、プリアンブル１１１，フレームタイプ１１２，データサイズ１１３，送信元ＩＤ１１４，宛先ＩＤ１１５，送信元ポート１１６，コマンド種類１１７，パラメータ１１８，ダミーデータ１１８ａ，ＦＣＳ１１９の各領域からなる。

そして、このうちプリアンブル１１１及びＦＣＳ１１９の形式は、図２に示したＴＬフレーム１００の場合と同様である。
また、フレームタイプ１１２は、ＴＬフレーム１００に管理データ１０２として記載されているフレームタイプと同趣旨のデータである。ただし、ここでは、このフレームがＩＴＬフレームであることを示すデータを記載する。
ＴＬフレーム１００においてフレームタイプを管理データ１０２の先頭バイトに記載するとすると、ＴＬフレーム１００とＩＴＬフレーム１１０とでは、プリアンブル１１１、フレームタイプ１１２及びＦＣＳ１１９が、共通のフォーマットとなる。

また、データサイズ１１３としては、ダミーデータ１１８ａを除くフレーム中のデータ量を示す情報を記載する。
送信元ＩＤ１１４及び宛先ＩＤ１１５としては、それぞれ送信元装置及び宛先装置のＭＡＣアドレスを記載する。
また、送信元ポート１１６としては、各ノードが複数備える送信Ｉ／Ｆのうち、どの送信Ｉ／Ｆから送信したかを示す情報を記載する。
コマンド種類１１７としては、このＩＴＬフレーム１１０がどのコマンド（又は応答）を伝達するものであるかを示すコマンドＩＤを記載する。コマンドの内容については後にいくつか例を挙げる。
パラメータ１１８としては、コマンド毎に異なるパラメータデータを記載する。
ダミーデータ１１８ａは、フレーム長を一定にするための、特に意味を持たないデータである。

また、（ｂ）に示す特殊なＩＴＬフレーム１２０は、プリアンブル１１１、フレームタイプ１１２及びＦＣＳ１１９のみからなる。これらのデータの形式は、ＩＴＬフレーム１１０の場合と同様である。そして、ＩＴＬフレーム１２０の場合、フレームタイプ１１２の情報として、フレームの用途を示す情報を記載する。
このような形式のＩＴＬフレーム１２０は、オーディオネットワークシステム１においては、後述するノード間の距離計測や切断通知のような、特殊な用途に用いる。そこで、以後、ＩＴＬフレームの符号として「１１０」を用いるが、特に断らない限り、ＩＴＬフレーム１２０についても同等な取扱いが可能である。

１．３ ＴＬフレームの伝送方式
次に、図５に、図２に示したＴＬフレーム１００の伝送タイミングを示す。
この図に示すように、オーディオネットワークシステム１においては、ＴＬフレーム１００を、９６ｋＨｚ（キロヘルツ）のサンプリング周期１周期である１０．４μｓｅｃ（マイクロ秒）毎に１つ、ノード間で循環させ、各ノードはＴＬフレームの所望のｃｈへの音響信号の書き込みないし所望のｃｈからの音響信号の読み出しを行うようになっている。従って、各サンプリング周期に、２５６の伝送ｃｈについて、それぞれ１サンプル分の波形データを、各ノード間で伝送できる。

１Ｇｂｐｓ（ギガビット・パー・セカンド）のイーサネット（登録商標）方式のデータ転送を採用すれば、ＴＬフレーム１００の時間長は、１ナノ秒×８ビット×１２８２バイト＝１０．２６μｓｅｃであり、１サンプリング周期内に伝送が完了する。
なお、１２８２バイトの場合、フレーム間の時間間隔を無視すれば、計算上は１ｓｅｃ／１０．２６μｓｅｃ＝９７．４７ｋＨｚのサンプリング周期まで対応可能であり、９６ｋＨｚのサンプリング周期であれば、１０．４μｓｅｃ／８ビット／１ナノ秒＝１３００バイトのフレームサイズまで伝送可能である。しかし、フレーム間には所定時間以上の空きが必要であり、また、フレームの伝送タイミングが前後に揺れる可能性があるので、ＴＬフレームのサイズ（時間長）はそれらを考慮した上で決定される。

次に、図６に、オーディオネットワークシステム１上での音響信号の伝送時（音声伝送モード）における、図２に示したＴＬフレームの伝送状況を示す。図６に示すのは、シングルモードの場合の例である。
ここでは、ノードＡからノードＤまでの４つのノードをカスケード接続したオーディオネットワークシステムを考える。そして、このシステム内の各ノードに図２に示したＴＬフレーム１００を循環させる場合、いずれか１つのノードをマスタノードに定め、そのノードのみが新たなサンプリング周期のＴＬフレーム（通し番号の異なるＴＬフレーム）の生成を行い、サンプリング周期毎に生成されたＴＬフレームを次のノードへ送信する。マスタノード以外のノードはスレーブノードであり、それぞれ前のノードからＴＬフレームを受信し、次のノードへ送信する転送処理を行う。

そして、マスタノードＢが最初に図で右向きに、ワードクロックのタイミングに合わせて、ノードＣに向かってＴＬフレームを送信すると、そのＴＬフレームは、破線で示すように、ノードＢ→Ｃ→Ｄ→Ｃ→Ｂ→Ａ→Ｂの順で伝送され、ノードＢに戻ってくる。マスタノードから見て、一巡するＴＬフレームを最初に送信する側を前方側と呼び、２回目に送信する側を後方側と呼ぶ。また、この伝送の際、各ノードは、ＴＬフレームを受信してから送信するまでに、他のノードから受信すべき波形データや制御データをＴＬフレームから読み取り、また他のノードに送信すべき波形データや制御データをＴＬフレームに書き込む。

そして、マスタノードは、ＴＬフレームが伝送経路を１周して戻ってくると、そのＴＬフレームの管理データ１０２を書き換えて後のサンプル周期のＴＬフレームを生成し、適当なサンプル周期での送信に供する。またこのとき、マスタノードも他のノードと同様にＴＬフレームに対してデータの読み書きを行う。ＴＬフレームの生成については後に詳述する。

以上を繰り返すことにより、１サンプリング周期につき１つのＴＬフレームに、（ａ）から（ｅ）に時系列的に示すように、各ノードを循環させることができる。これらの図において、黒塗りの矢印はＴＬフレームの先頭を、黒丸はＴＬフレームの末端を示す。線の矢印は、ＴＬフレームの切れ目を分かり易くするために記載したものである。

なお、各スレーブノードは、ＴＬフレームの全てを受信してからデータの読み書きや次のノードへの送信を行う必要はなく、先頭から必要なバイト数だけ受信したら、データの読み書きや次のノードへの送信の処理を開始してしまってよい。そしてその後、ＴＬフレームの末端まで、受信するのとほぼ同じ速さでデータの読み書きや送信を行って行けばよい。ただし、マスタノードについては、後述する通り、ＴＬフレームの全てを受信してから、その内容に基づいて新たなＴＬフレームの生成を行うことが好ましい。

また、シングルモードの場合、両端のノード以外のノードは、１周のうちに２度ＴＬフレームを通過させることになるが、このうちＩＴＬフレーム領域１０７以外のデータの読み書きを行うのは１度のみである。どちらでその読み書きを行うかは、最初にＴＬフレームを通過させる時、図で右向きにＴＬフレームを通過させる時等、任意に定めればよい。読み書きを行わない場合には、単に送信元アドレスと後述する存在確認情報だけ書き換えてＴＬフレームの残りの部分はスルーさせればよい。

ＩＴＬフレームについては、両方向の隣接ノードに伝達できることが好ましい。そこで、図で右向きにＴＬフレームを通過させる時には、右側の隣接ノード（又はその先にあるノード）に送信すべきＩＴＬフレームのデータをＩＴＬフレーム領域１０７に書き込み、図で左向きにＴＬフレームを通過させる時には、左側の隣接ノード（又はその先にあるノード）に送信すべきＩＴＬフレームのデータをＩＴＬフレーム領域１０７に書き込んで送信するようにするとよい。

また、各ノードにおいて、ＴＬフレームのデータを書き換えるためや、受信側のネットワーククロック（送信元のノードの動作クロックに対応）と送信側のネットワーククロック（当該ノードの動作クロックに対応）の周波数やタイミングの差を吸収するために、ＴＬフレームの受信時にバッファリングを行う必要があるので、ＴＬフレームの受信開始から送信開始まで幾分かのタイムラグが生じる。

そして、ネットワークで伝送される音響信号の伝送遅延（サンプリング周期単位）を最小にしたい場合は、上記のタイムラグの量を考慮して、マスタノードがあるワードクロックのタイミングで送信開始したＴＬフレームを、次の次のワードクロックより所定時間α（マスタノード内での新ＴＬフレームの準備に係る時間に対応する）だけ前のタイミングに、マスタノードが受信完了できるようにすればよい。

後に詳述するが、この場合、例えばＳ番目のＴＬフレームに基づいて、２サンプリング周期先に送信するＳ＋２番目のＴＬフレームを生成する。
しかし、２サンプリング周期先に送信するＴＬフレームを生成することは必須ではなく、ｋを２以上の自然数として、Ｓ番目のＴＬフレームに基づいて、ｋサンプリング周期先に送信するＳ＋ｋ番目のＴＬフレームを生成するようにすることも可能である。この場合のｋを、「周期更新量ｋ」と呼ぶことにする。

そして、一般に、ｋの値に応じて、マスタノードがあるワードクロックのタイミングで送信開始したＴＬフレームを、ｋ周期先のワードクロックより所定時間αだけ前のタイミングに、マスタノードが受信完了できるようにすれば、音響信号の伝送が可能である。従って、ノード数が増え、送信したＴＬフレームがマスタノードに戻ってくるまでの時間が増加した場合でも、ｋの値を増加させることにより、音響信号が伝送可能な状態を維持することができる。

この周期更新量ｋは、マスタノードが適宜設定し、その内容を、周期更新量ｋの設定を示すパラメータ設定フレームをブロードキャストする等により、システム中の全ノードに伝達すればよい。
ただし、本システムでは各ノードで受信する音響信号のタイミングを相互に合わせているので、ｋを大きくしてマスタノードにおけるＴＬフレームの受信完了タイミング遅れを許容できるようにする（許容量はワードクロック単位で定められる）と、その分だけ、伝送される音響信号にワードクロック単位で伝送遅延が生じる。

本システムにおいては、以上のような方式のデータ伝送を行うことにより、１サンプリング周期内にＴＬフレームを１周させることのできる程度のノード数であれば、ネットワーク内で常にＴＬフレームのサイズに応じた一定の伝送帯域幅を確保することができる。そして、この帯域幅は、特定のノード間でのデータ伝送量の多寡には影響されない。

なお、ツインモードの場合には、図１からわかるように、マスタノードＢが生成して図で右向きに送信したＴＬフレームを、ノードＢ→Ｃ→Ｄ→Ａ→Ｂの順で伝送する伝送経路と、マスタノードＢが生成して図で左向きに送信したＴＬフレームを、ノードＢ→Ａ→Ｄ→Ｃ→Ｂの順で伝送する伝送経路とができることになる。そして。この伝送の際、各ノードは、ＴＬフレームを受信してから送信するまでに、他のノードから受信すべき波形データや制御データをＴＬフレームから読み取り、また他のノードに送信すべき波形データや制御データをＴＬフレームに書き込む。

また、ツインモードの場合、ＴＬフレームが伝送経路を１周する間に全てのノードを１回ずつ通過することになるため、各ノードは、その通過の際にデータの読み書きを行う。
そして、オーディオネットワークシステム１の全体として、２つの伝送経路のフレームに同じデータを書き込んで循環させる二重化通信と、２つの伝送経路のフレームに別々のデータを書き込んで循環させる二倍化通信とを、選択的に行うことができる。

このうち、二重化通信の場合には、フレームは２つになっても同じデータを記載するため、１サンプリング周期当たりに伝送可能な情報量、すなわち通信の帯域幅は、カスケード接続の場合と同じである。しかし、１ヶ所で断線が生じても速やかにカスケード接続の伝送に移行し、同じ帯域幅でのデータ伝送を維持することができる。また、２つのフレームの内容を比較することにより、データが正確に伝送されているかどうかを確認することができる。
一方、二倍化通信の場合には、１サンプリング周期当たりにフレーム２つ分のデータを伝送可能であるから、通信の帯域幅を、カスケード接続の場合の２倍にすることができる。
このどちらを行うかは、マスタノードに設定しておけばよい。

１．４ システムを構成する各装置のハードウェア構成及び基本動作
次に、以上説明してきたようなＴＬフレームの伝送を行うためのハードウェア及びその動作について説明する。
まず、図７に、上述のオーディオネットワークシステム１を構成する各ノードとなる音響信号処理装置のハードウェア構成を示す。
図７に示すように、この音響信号処理装置２は、ＣＰＵ２０１，フラッシュメモリ２０２，ＲＡＭ２０３，外部機器Ｉ／Ｆ（インタフェース）２０４，表示器２０５，操作子２０６を備え、これらがシステムバス２０７により接続されている。また、外部機器Ｉ／Ｆ２０４とシステムバス２０７とに接続するカードＩ／Ｏ（入出力部）２１０も備えている。

そして、ＣＰＵ２０１は、この音響信号処理装置２の動作を統括制御する制御手段であり、フラッシュメモリ２０２に記憶された所要の制御プログラムを実行することにより、表示器２０５における表示を制御したり、操作子２０６の操作を検出してその操作に従ってパラメータの値の設定／変更や各部の動作を制御したり、コマンドをカードＩ／Ｏ２１０を介して他の音響信号処理装置に送信したり、カードＩ／Ｏ２１０を介して他の音響信号処理装置から受信したコマンドに従った処理を行ったりする。

フラッシュメモリ２０２は、ＣＰＵ２０１が実行する制御プログラムを始め、電源を切っても残しておくべきデータを記憶する書き換え可能な不揮発性記憶手段である。
ＲＡＭ２０３は、一時的に記憶すべきデータを記憶したり、ＣＰＵ２０１のワークメモリとして使用したりする記憶手段である。

外部機器Ｉ／Ｆ２０４は、種々の外部機器を接続し入出力を行うためのインタフェースであり、例えば外部のディスプレイ、マウス、文字入力用のキーボード、操作パネル、ＰＣ（パーソナルコンピュータ）等を接続するためのインタフェースが用意される。
外部機器Ｉ／Ｆ２０４は、カードＩ／Ｏ２１０のオーディオバス２１７にも接続しており、オーディオバス２１７を流れる波形データを外部装置に送信したり、外部装置から受信した波形データをオーディオバス２１７に入力したりすることができる。

表示器２０５は、ＣＰＵ２０１による制御に従って種々の情報を表示する表示手段であり、例えば、液晶ディスプレイ（ＬＣＤ）や発光ダイオード（ＬＥＤ）によって構成することができる。
操作子２０６は、音響信号処理装置２に対する操作を受け付けるためのものであり、種々のキー、ボタン、ダイヤル、スライダ等によって構成することができる。

また、カードＩ／Ｏ２１０は、オーディオバス２１７と制御バス２１８を備え、これらのバスに種々のカードモジュールを装着することにより、音響信号処理装置２に対する音響信号及び制御信号の入出力及びその処理を行うことができるようにするためのインタフェースである。ここに装着される各カードモジュールは、オーディオバス２１７を介して相互に波形データを送受信すると共に、制御バス２１８を介してＣＰＵ２０１との間で制御信号を送受信し、ＣＰＵ２０１の制御を受ける。

オーディオバス２１７は、任意のカードから任意のカードへ、複数チャンネルの波形データをサンプリング周期に基づくタイミングで各１サンプルずつ時分割伝送する音響信号伝送用ローカルバスである。接続された複数カードの何れか１つがマスタとなり、当該カードが生成し供給するワードクロックに基づいてオーディオバス２１７の時分割伝送の基準タイミングを制御する。その他の各カードはスレーブとなり、その基準タイミングに基づいて各カードのワードクロックを生成する。

すなわち、各カードで生成されるワードクロックは、マスタとなるカードのワードクロックに同期した共通のクロックとなり、ノード内の複数のカードは、共通のサンプリング周波数で波形データの処理を行う。さらに、各カードは、自身のワードクロックに基づいて処理した波形データ及び処理すべき波形データを、上記の基準タイミングに基づく時分割タイミングで、オーディオバス２１７を介して他のカードに送信し、また他のカードから受信する。

図７には、カードＩ／Ｏ２１０にＤＳＰ（デジタル・シグナル・プロセッサ）カード２１１，２１２，アナログ入力カード２１３，アナログ出力カード２１４，ネットワークＩ／Ｆカード２１５を装着した例を示している。
カードＩ／Ｏ２１０に装着される各種カードは、そのカードの機能に応じた波形データの処理を、それぞれ、ワードクロック（波形データのサンプリング周期）に基づくタイミングで実行する。

このうち、ＤＳＰカード２１１，２１２は、オーディオバス２１７から取得した波形データに対し、ワードクロックに基づくタイミングで、ミキシング、イコライジング、エフェクト付与を始めとする種々の処理を行う信号処理手段である。処理後のデータも、オーディオバス２１７に出力する。また、複数ｃｈの波形データの入力を受け付けて処理し、複数ｃｈの波形データを出力することができる。

アナログ入力カード２１３は、Ａ／Ｄ（アナログ／デジタル）変換回路を備え、マイク等の音声入力装置から入力するアナログ音響信号を、デジタルの波形データに変換してオーディオバス２１７に供給する機能を有する。複数ｃｈの信号を並列して処理することも可能である。
アナログ出力カード２１４は、Ｄ／Ａ（デジタル／アナログ）変換回路を備え、オーディオバス２１７から取得したデジタルの波形データをアナログの音響信号に変換して、スピーカ等の音声出力装置に出力する機能を有する。

ネットワークＩ／Ｆカード２１５は、送信Ｉ／Ｆと受信Ｉ／Ｆを２組備え、図１乃至図６を用いて説明したＴＬフレーム１００及びＩＴＬフレーム１１０の伝送と、ＴＬフレーム１００に対する波形データや制御データ等の読み書きを行う機能とを有する。その詳細については後述する。また、カードＩ／Ｏ２１０には、ネットワークＩ／Ｆカードを複数枚装着することが可能であり、各ネットワークＩ／Ｆカード毎に別々のオーディオネットワークに接続することができる。その場合、音響信号処理装置２は、複数のオーディオネットワークを接続するブリッジとしての動作を行う。
また、ここで挙げたもの以外でも、その他カード２１６として、デジタル入出力、音源、レコーダ、エフェクタ等の、種々のカードモジュールを装着可能とすることが考えられる。

なお、上述のように、カードＩ／Ｏ２１０に装着されたカードは、共通のワードクロックに従って音響信号の処理を行うが、音響信号処理装置２がマスタノードである場合は、装着されたカードのうちの何れか１枚がネットワークＩ／Ｆカード２１５を含む他のカードへワードクロックを供給し、ネットワークＩ／Ｆカード２１５はマスタノードとしてサンプリング周期毎にＴＬフレームを送信する。音響信号処理装置２がスレーブノードである場合は、ネットワークＩ／Ｆカード２１５がＴＬフレームの受信タイミングに基づいてワードクロックを生成（再生）し、カードＩ／Ｏ２１０に装着された他のカードへワードクロックを供給する。

次に、図８に、ネットワークＩ／Ｆカード２１５の構成をより詳細に示す。
図８に示すように、ネットワークＩ／Ｆカード２１５は、フレームの送受信に使用する第１，第２の受信Ｉ／Ｆ３１，３３及び第１，第２の送信Ｉ／Ｆ３４，３２を備え、また、フレームを用いたデータ送受信に関する処理を行うフレーム処理部２２０と、音響信号処理装置２のうちネットワークＩ／Ｆカード２１５以外の部分とのインタフェースとなる上位層Ｉ／Ｆ７０とを有する。

このうち、第１，第２の受信Ｉ／Ｆ３１，３３及び第１，第２の送信Ｉ／Ｆ３４，３２は、図１に示した２組の受信Ｉ／Ｆ及び送信Ｉ／Ｆと対応する通信手段であり、それぞれ通信ケーブルと接続するための所定のコネクタ（メス側）を備えている。通信ケーブルの接続に際しては、第１の受信Ｉ／Ｆ３１と第１の送信Ｉ／Ｆ３４とを１組とし、第２の送信Ｉ／Ｆ３２と第２の受信Ｉ／Ｆ３３とを１組とする。これらのＩ／Ｆは、上述した１サンプリング周期内のＴＬフレームの伝送に十分な能力を有していれば、どのような通信方式でデータ通信行うＩ／Ｆであってもよいが、ここでは１Ｇｂｐｓのイーサネット方式のデータ転送を行うＩ／Ｆを採用している。

現在、１Ｇイーサネットには、通信ケーブルＣＢとしてＲＪ４５コネクタ付きＣＡＴ５ｅケーブル（シールドされていないツイストペア）を使用する１０００ＢＡＳＥ−Ｔと、光ファイバやＳＴＰケーブル（シールドされたツイストペア）を使用する１０００ＢＡＳＥ−Ｘの２種類があるが、本実施形態にはその何れを用いることもできる。また、１Ｇイーサネット以外の広帯域ネットワーク技術を用いても良い。例えば、FiberChannel、ＳＤＨ（Synchronous Digital Hierarchy）／ＳＯＮＥＴ（Synchronous Optical NETwork）などである。

受信Ｉ／Ｆは、通信ケーブルＣＢを伝播する電気信号や光信号からキャリアであるネットワーククロックを抽出し、抽出されたクロックに基づいて該電気信号や光信号からバイト単位（ないしワード単位）のデジタルデータのデータ列を復調して出力する。送信Ｉ／Ｆは、ネットワーククロックと送信すべきバイト単位（ないしワード単位）のデジタルデータ列を入力し、該ネットワーククロックをキャリアとして伝送用の電気信号や光信号に変調して通信ケーブルＣＢに出力する。

また、上位層Ｉ／Ｆ７０は、図７に示したオーディオバス２１７及び制御バス２１８に対してデータを入出力するためのインタフェースである。
そして、ここでは５つのデータ入出力ポートを備えており、このうち２つのIP_Packetポートは、ＴＬフレーム１００のイーサネットフレーム領域１０６から読み出したイーサネットフレームに含まれるＩＰパケットや、イーサネットフレームを生成してイーサネットフレーム領域１０６に書き込んで送信するＩＰパケットの制御バス２１８を介した入出力を行うためのものである。

また、COMポートは、ネットワークＩ／Ｆカード２１５側の制御部４０と、音響信号処理装置２本体側のＣＰＵ２１０との間で、制御バス２１８を介してコマンドやデータを送受信するためのポートである。
Audio_Inポート及びAudio_Outポートは、オーディオバス２１７を介して波形データを入出力するためのポートである。

一方、フレーム処理部２００は、大別すると、第１及び第２のデータ入出力部１０，２０，セレクタ３５〜３８，制御部４０，ワードクロック生成部４１を有する。
このうち、制御部４０は、ＣＰＵ，ＲＯＭ，ＲＡＭ等を有し、ネットワークＩ／Ｆカード２１５の動作に関する全般的な制御及び、後述するような、ＩＴＬフレームを用いて伝達されたコマンドや応答に関する制御を行う。制御バス２１８を介して通信可能な本体側のＣＰＵ２０１から、ネットワークＩ／Ｆカード２１５の動作に必要な、音響信号処理装置２のＭＡＣアドレス、動作モード（マスタ／スレーブ，シングルモードのみ／ツインモード可等）等の設定情報を取得する機能も有する。
そして、制御部４０は、ノードの接続順を示す後述するトポロジーテーブルの管理も行う。

また、ワードクロック生成部４１は、オーディオバス２１７における波形データの転送や、オーディオバス２１７に接続される各種カードモジュールにおける信号データ処理のタイミングの基準となるワードクロックを生成するワードクロック生成手段である。
マスタノードにおいては、ワードクロック生成部４１は、ネットワークＩ／Ｆカード２１５独自のタイミング、ないし、オーディオバス２１７を介して供給される他のカードからのワードクロックに同期したタイミングでワードクロックを生成し、そのクロックをＴＬフレーム１００の送信タイミングの基準としても用いるが、スレーブノードにおいては、ワードクロック生成部４２はＴＬフレームの受信タイミングを基準としてワードクロックを生成する。

また、第１，第２のデータ入出力部１０，２０はそれぞれ、図示しない動作クロック発生部の発生する動作クロックに基づいて動作し、対応する受信Ｉ／Ｆが受信したＴＬフレーム１００から所望のデータを読み出す読出手段及び、受信したＴＬフレーム１００に対して所望のデータの書き込みを行う書込手段として機能する。また、ＴＬフレーム１００を循環させる伝送経路が確立されていないノードに対し、ＩＴＬフレーム１１０の送受信を直接（ＴＬフレーム１００に書き込まずに）行う機能も有する。そして、これらの、第１，第２のデータ入出力部１０，２０入出力部の機能は同等なものであるので、第１のデータ入出力部１０について代表して説明する。

第１のデータ入出力部１０は、ＴＬフレーム受信部１１，波形データ受信バッファ１２，ＴＬデータ受信バッファ１３，ＭＡＣ処理部１４，ディレイバッファ１５，波形データ送信バッファ１６，ＴＬデータ送信バッファ１７，ＴＬフレーム送信部１８，ＩＴＬフレーム受信部５１，ＩＴＬデータ受信バッファ５２，ＩＴＬデータ送信バッファ５３，ＩＴＬフレーム送信部５４を備える。これらのうち各送受信部及び各バッファは、基本的には先に書き込まれたデータが先に読み出されるＦＩＦＯ（ファーストイン・ファーストアウト）形式で動作するものである。

これらのうち、ＴＬフレーム受信部１１は、受信したＴＬフレーム１００からのデータの読み出しを行うと共に、そのＴＬフレーム１００をディレイバッファ１５に格納する機能を有し、ＩＴＬフレーム受信部５１は、受信したＩＴＬフレーム１１０からのデータの読み出しを行う機能を有する。

そして、ＴＬフレーム受信部１１及びＩＴＬフレーム５１は、第１の受信Ｉ／Ｆ３１がキャリアとして抽出したネットワーククロックＮＣ１の供給を受けて、それに同期して第１の受信Ｉ／Ｆ３１からのデータの受け取りを行う。ただし、ＴＬフレーム受信部１１が第１の受信Ｉ／Ｆからのデータを受け取るのは、セレクタ３５が第１の受信Ｉ／Ｆ側を選択している場合のみである。

第１の受信Ｉ／Ｆ３１から受け取るデータがどのフレームに係るものであるかは、図２及び図４を用いて説明した各フレーム中のフレームタイプのデータを参照すればわかるため、ＴＬフレーム受信部１１及びＩＴＬフレーム受信部５１は、自身が処理すべきフレーム以外は、読み捨てるようにすればよい。特に、ＩＴＬフレーム受信部５１には、全てのフレームのデータを受け取ることになるが、ＩＴＬフレーム１１０，１２０以外のフレームは、特に処理せずに廃棄する。

ここで、ＩＴＬフレーム１１０の送受信に関する第１のデータ入出力部１０の機能について先に説明する。
ＩＴＬフレーム受信部５１は、ＩＴＬフレーム１１０を受信した場合、そのデータをＩＴＬデータ受信バッファ５２に書き込む。そして、フレームにエラーがないことを確認して制御部４０に出力し、制御部４０はそのフレームに記載されたコマンドの内容に従った処理（自機宛でないコマンドを転送する処理も含む）を行う。

また、ＩＴＬデータ送信バッファ５３は、第２の送信Ｉ／Ｆ３２に接続されているノードに送信すべきＩＴＬフレーム１１０のデータを格納するバッファであり、制御部４０が、その書き込みを行う。
そして、セレクタ３６がＩＴＬフレーム送信部５４側を選択している場合、ＩＴＬフレーム送信部５４が、適当なタイミングでＩＴＬデータ送信バッファ５３に格納されているＩＴＬフレーム１１０を読み出し、第２の送信Ｉ／Ｆ３２に供給して接続先のノードに対して送信させる。セレクタ３６がＴＬフレーム送信部１８側を選択している場合には、ＩＴＬデータ送信バッファ５３に格納されているＩＴＬフレーム１１０の送信はＴＬフレーム送信部１８が行うため、ＩＴＬフレーム送信部５４は特に何の動作もしない。

これらの、ＩＴＬフレーム受信部５１及びＩＴＬフレーム送信部５４によるＩＴＬフレーム１１０の送受信は、ブロックには分割せず、フレーム単位で行う。
以上の各部の機能により、ネットワークＩ／Ｆカード２１５は、ＩＴＬフレーム１１０を用いた隣接ノードとの通信を、図で右向きの伝送経路で行うことができる。図で左向きの伝送経路で通信を行う場合には、第２のデータ入出力部２０を用いる。

次に、ＴＬフレーム１００の送受信に関する第１のデータ入出力部１０の機能について説明する。
まず、ＴＬフレーム受信部１１は、ＴＬフレーム１００のデータを受け取ると、そのデータのうち、読み出すべき伝送ｃｈの波形データを波形データ受信バッファ１２に書き込み、ＩＴＬフレーム領域１０７のデータをＩＴＬデータ受信バッファ５２に書き込み、読み出すべきイーサネットフレーム領域１０６のデータ及び管理データを、ＴＬデータ受信バッファ１３に書き込む機能を有する。
データエラー等の検出があった場合には、これらの各バッファへのデータの書き込みを行わなかったり、一旦書き込んだデータを変更したりする場合もあるが、この点については後述する。

また、ＴＬフレーム受信部１１は、受け取ったＴＬフレーム１００のデータ全てをそのままディレイバッファ１５にも書き込む機能を有する。
そして、波形データ受信バッファ１２に書き込まれた各伝送ｃｈの波形データは、上位層Ｉ／Ｆ７０のAUDIO_Outポートに対し、ワードクロックに同期して１サンプルずつ出力され、オーディオバス２１７を介して他のカードに伝送される。
また、ＩＴＬデータ受信バッファ５２に書き込まれたデータは、ＩＴＬフレーム１つ分が揃った時点で、制御部４０に出力され、制御部４０はそのフレームに記載されたコマンドの内容に従った処理（自機宛でないコマンドを転送する処理も含む）を行う。

ＴＬデータ受信バッファ１３に書き込まれたデータは、イーサネットフレームのデータについては、イーサネットフレーム１つ分が揃った時点で、ＭＡＣ処理部１４に出力される。そして、ＭＡＣ処理部１４が自機宛てであることを確認したイーサネットフレームについては、ＭＡＣ処理部１４がそこからＩＰパケットを取り出して上位層Ｉ／Ｆ７０のIP_Packetポートに対して出力し、制御バス２１８を介して本体側のＣＰＵ２０１に渡される。イーサネットフレーム以外のデータ、例えばメータデータ等は、ＭＡＣ処理部１４を介して制御部４０に渡され、制御部４０が上位層Ｉ／Ｆ７０のCOMポートを介して必要に応じて本体側のＣＰＵ２０１に渡す。

なお、波形データについては、制御部４０が、少なくともどの伝送ｃｈのデータを読み取るべきか把握しており、そのデータがＴＬフレーム１００の何バイト目に記載されているかは計算で求められるため、制御部４０がその位置をＴＬフレーム受信部１１に指示し、その位置のデータのみを波形データ受信バッファ１２に書き込ませるようにすればよい。

ＩＴＬフレーム領域１０７，イーサネットフレーム領域１０６，及び管理データについては、ＴＬフレーム中の固定的な位置に記載されているから、一旦その位置からデータを読み出した上で、ＴＬフレーム受信部１１が制御部４０又はＭＡＣ処理部１４に出力すべきデータを適宜選別して、ＩＴＬデータ受信バッファ５２やＴＬデータ受信バッファ１３に書き込むようにすればよい。あるいは、ＴＬフレーム受信部１１は単純に該当領域のデータを全て受信バッファに書き込み、データの選別を制御部４０が行うようにしてもよい。
選別の手法については後述する。

一方、波形データ送信バッファ１６は、ＴＬフレーム１００に記載して出力すべき波形データを格納するバッファであり、上位層Ｉ／Ｆ７０は、オーディオバス２１７から供給される出力すべき波形データを、サンプリング周期毎にAudio_INポートから出力して波形データ送信バッファ１６に書き込む。複数の伝送ｃｈ分の波形データを書き込むことも当然可能であり、ＴＬフレームの先頭に近いバイトに書き込むデータを先に波形データ送信バッファ１６に書き込んでおけばよい。なお、第２のデータ入出力部２０も波形データの読み書きに使用する場合には、上位層Ｉ／Ｆ７０は波形データ送信バッファ２６にも出力すべき波形データの書き込みを行うが、波形データ送信バッファ１６と波形データ送信バッファ２６とで別々の波形データを書き込むことはもちろん可能である。

また、ＴＬデータ送信バッファ１７は、ＴＬフレームに記載して出力すべきイーサネットフレームのデータ及び管理データを格納するバッファであり、ＭＡＣ処理部１４が、上位層Ｉ／Ｆ７０のIP_Packetポートから出力される送信すべきＩＰパケットに基づいて生成したイーサネットフレーム及び、制御部４０から供給される出力すべき制御データをＴＬデータ送信バッファ１７に書き込む。
また、ＩＴＬフレーム１１０の送受信についての説明で述べた通り、制御部４０は、第２の送信Ｉ／Ｆ３２に接続されているノードに送信すべきＩＴＬフレーム１１０のデータを、ＩＴＬデータ送信バッファに書き込む。

そして、自機がスレーブノードである場合、ディレイバッファ１５にＴＬフレーム１００のデータが所定量（第１の所定量）蓄積されると、蓄積の進行に合わせて、ＴＬフレーム送信部１８がその蓄積されたＴＬフレーム１００を先頭から順に読み出して自身が有するバッファに蓄積する。そして、蓄積の進行に合わせて、波形データ送信バッファ１６，ＴＬデータ送信バッファ１７及びＩＴＬデータ送信バッファ５３のデータを適当なアドレスに書き込んでＴＬフレーム１００の内容を書き換える。この書き換えは、後述する送信タイミングに間に合うよう、フレームの先頭側から順に行うとよい。

ＴＬフレーム１００の何バイト目にどのデータを書き込めばよいかは、波形データについては、制御回路４０が書き込むべき伝送ｃｈに基づいて算出し、ＴＬフレーム送信部１８に指示する。その他、イーサネットフレームやＩＴＬフレーム等についても、図２に示した区分に従いデータの種類毎に自動的に決定される。
また、ディレイバッファ１５への所定量の蓄積を検出してそれをＴＬフレーム送信部１８による読み出し及び書き換えのトリガとする代わりに、ＴＬフレーム１００を取り込み開始してから所定時間の経過を検出して、それをトリガするようにしてもよい。

そして、自機がスレーブノードである場合、ＴＬフレーム送信部１８のバッファにＴＬフレーム１００のデータが第２の所定量だけ蓄積されると、ＴＬフレーム送信部１８は書き換え後のＴＬフレームの出力を開始し、ＴＬフレーム送信部１８による差し替え後のＴＬフレーム１００は、セレクタ３６がＴＬフレーム送信部１８からの出力ラインを選択していれば、第２の送信Ｉ／Ｆ３２から隣接ノードに対して出力される。このとき、第１のデータ入出力部１０の動作クロックが、そのままネットワーククロックＮＣ２として、第２の送信Ｉ／Ｆ３２に供給され、第２の送信Ｉ／Ｆは、ＴＬフレームのデータをネットワーククロックＮＣ２をキャリアとして順次変調して通信ケーブルＣＢに出力する。

なお、第２の所定量の蓄積を検出してそれを送信のトリガとする代わりに、ＴＬフレーム１００を取り込み開始してから所定時間の経過を検出して、それをトリガとして送信を開始するようにしてもよい。
また、図２及び図３を用いて説明したように、イーサネットフレームやＩＴＬフレーム１１０をＴＬフレーム１００に書き込んで送信する場合、これらのデータを複数の（１つの場合もある）ブロックに分割する。この分割と、ブロック毎のブロック番号等の生成は、ＴＬフレーム送信部１８が行い、ＴＬフレーム１００のデータ書き換えタイミングまでに、書き換えに使用するブロックのデータを用意しておく。

なお、本実施形態では、ディレイバッファ１５に記憶されたＴＬフレーム１００に対するＴＬフレーム送信部１８による内容の書き換えと、出力とを同時に行うようになっていたが、先に書き換えを行ってから、書き換えの済んだ部分から順に出力するようにしてもよい。

また、本実施形態では、ＴＬフレーム送信部１８のバッファに記憶された音声伝送フレームへの内容の書き換えと、ＴＬフレーム送信部１８からの音声伝送フレームの出力を独立して行うようになっていたが、その書き換えと出力を一度に行うようにしてもよい。すなわち、受信したＴＬフレーム１００のディレイバッファ１５への所定量の蓄積をトリガとしてＴＬフレーム送信部１８によるそのＴＬフレーム１００の読み出しを開始し、波形データ送信バッファ１６，ＴＬデータ送信バッファ１７及びＩＴＬデータ送信バッファ５３のデータにより内容を差し替えつつ出力するようにしてもよい。

また、データの差し替えは、ＴＬフレーム１００の各バイト（又はワード）のデータを出力する際に、ディレイバッファ１５から読み出したデータと、波形データ送信バッファ１６に格納されていたデータ、ＴＬデータ送信バッファ１７に格納されていたデータ、およびＩＴＬデータ送信バッファ５３に格納されていたデータのうち適切なものを選択して送信するようにしてもよい。この場合、ディレイバッファ１５から読み出したＴＬフレームのデータのうち、選択されなかったデータは破棄されることになる。そして、この処理によっても、ＴＬフレーム送信部１８は、実質的に、ＴＬフレーム受信部１１が受信したＴＬフレーム１００の適当な領域に、出力すべきデータを上書きしたＴＬフレームを出力することができる。

また、上述のように、シングルモードの場合、各ノードはＴＬフレームに伝送経路を１周させる間、ＩＴＬフレーム領域１０７以外のデータは、１回しか読み書きを行わない。従って、ＩＴＬフレーム領域１０７以外のデータは、第１，第２のデータ入出力部１０，２０のいずれか一方でしかデータの読み書きを行わない。そして、ＩＴＬフレーム領域１０７以外のデータの読み書きを行わない方のデータ入出力部では、ＩＴＬフレーム領域１０７以外の部分のデータは、単にスルーさせるのみとする。

また、マスタノードにおいては、後述するように、ＴＬフレーム１００全体の受信が完了してからＴＬフレーム１００の更新を行うようになっており、ＴＬフレーム１００へのデータの書き込みのタイミングおよびＴＬフレーム１００の送信開始のタイミングが、スレーブノードとは異なる。しかし、ＴＬフレーム１００中のデータの書き込み位置については、スレーブノードの場合と同様に定めることができる。また、ＴＬフレーム１００中の管理データ１０２の書き換えも行うが、この書き換えも、新たなＴＬフレームに記載すべきデータをＴＬデータ送信バッファ１７に書き込んでおき、このデータをフレームバッファに蓄積されたＴＬフレームに上書きして行うことができる。
以上がＴＬフレーム１００の送受信に関する第１のデータ入出力部１０の機能である。

ところで、図１（ａ）等からわかるように、ある装置が受信したＴＬフレーム１００のその装置からの送信先は、そのＴＬフレーム１００の送信元と別の装置になる場合（図１（ａ）のノードＢ）と、送信元と同じ装置になる場合（同ノードＡ，Ｃ）とがある。そして、前者の場合、ＴＬフレーム１００の送信は、ＴＬフレーム１００を受信した受信Ｉ／Ｆと別の組の送信Ｉ／Ｆから行い、後者の場合、同じ組の送信Ｉ／Ｆから行う。
セレクタ３５〜３８は、このような送信先の切り替えを行うために設けたものである。
このうち、セレクタ３５，３７はそれぞれ、ＴＬフレーム受信部１１，２１に入力するデータを、受信Ｉ／Ｆ３１，３３で受信したデータとするか、ＴＬフレーム送信部２８，１８が出力したデータとするかを選択するセレクタである。

一方、セレクタ３６，３８はそれぞれ、送信Ｉ／Ｆ３２，３４から送信するデータを、ＴＬフレーム送信部１８，２８が出力するＴＬフレームとするか、ＩＴＬフレーム送信部５４，６４が出力するＩＴＬフレームとするかを選択するセレクタである。
そして、これらのうちセレクタ３６とセレクタ３７とは連動して動作し、セレクタ３６がＴＬフレーム送信部１８の出力を第２の送信Ｉ／Ｆ３２に流す状態では、セレクタ３７は第２の受信Ｉ／Ｆ３３で受信したデータをＴＬフレーム受信部２１に渡し、第２のＩ／Ｆ側に接続されている装置からＴＬフレームを受信可能な状態となる。

一方、セレクタ３７を折り返しラインＬＢ１側に切り替え、ＴＬフレーム送信部１８の出力をＴＬフレーム受信部２１に渡す状態とすると、第１の受信Ｉ／Ｆ３１が受信したＴＬフレーム１００は、第１のデータ入出力部１０→折り返しラインＴＬ１→第２のデータ入出力部２０を通って、第１の送信Ｉ／Ｆ３４から出力されることになる（セレクタ３８がＴＬフレーム送信部２８側を選択していれば）。従って、受信したＴＬフレーム１００をその送信元に対して折り返し送信することになる。

また、セレクタ３６はセレクタ３７の折り返しラインＬＢ１側への切り替えに連動してＩＴＬフレーム送信部５４側に切り替わり、第２のＩ／Ｆ側の装置に対しては、ＴＬフレーム１００ではなくＩＴＬフレーム１１０を送信する状態となる。一方、第２の受信Ｉ／Ｆ３３がＩＴＬフレーム１１０を受信した場合には、このフレームはＩＴＬフレーム受信部６１にて処理することができる。
従って、ＴＬフレーム１００を折り返す状態でも、ＴＬフレーム１００の送信を行わない側に接続されている装置との間で、ＩＴＬフレームを用いた通信を行う経路は確保される。

この経路による通信は、後述する接続検出コマンドや接続要求コマンド及びそれらに対する返答の送受信等、初期処理においてオーディオネットワークシステムを組み立てたり、システムの構成変更に係る処理を行ったりする際の通知やコマンドの送受信等に用いる。
また、ここではセレクタ３６，３７について説明したが、セレクタ３８，３５も、連動して動作することにより同様な機能を有する。そして、第２の受信Ｉ／Ｆ３３から受信したＴＬフレーム１００に関し、折り返しを行うか否かを切り換えることができる。

以上をまとめると、音響信号処理装置２においては、所属するオーディオネットワークシステム中での各ノードの接続状態と、自機がマスタノードかスレーブノードかとに従い、図８に示したネットワークＩ／Ｆカード２１５のハードウェアが、上述した処理を行うことにより、図１乃至図６を用いて説明したようなＴＬフレーム及びデータの伝送に係る機能を実現することができる。

２．オーディオネットワークシステムの形成及びその構成変更について
２．１ 各装置の通信モード
次に、図７に示した音響信号処理装置２において制御部４０のＣＰＵが実行する、オーディオネットワークシステムの構築や構成変更に関連する処理について説明する。
図７に示した音響信号処理装置２において、ネットワークＩ／Ｆカード２１５は、起動時には、セレクタ３５，３７の両方が折り返しライン側を選択した状態となっている。この状態では、ネットワークＩ／Ｆカード２１５はＴＬフレームを複数のノード間で循環させるオーディオネットワークシステムは形成しておらず、外部とはＩＴＬフレームにより通信を行う状態である（この状態を「初期通信（ＩＴＬ）モード」と呼ぶ）。

そしてその後、送受信Ｉ／Ｆが、同様なネットワークＩ／Ｆカード２１５を有し、オーディオネットワークシステム１を形成可能な他の装置と接続されたことを検出すると、その接続された側のセレクタを受信Ｉ／Ｆ側に切り替え、接続された装置との間で、ＴＬフレーム１００を循環させるリング状の伝送経路を形成する。この時点で、リング状の伝送経路を形成している各装置が、一連のシステムとして機能を始めることになる。

ただし、この状態では、まだＴＬフレーム１００に対して波形データの読み書きは行わないが、イーサネットフレーム、ＩＴＬフレーム、管理データ等、波形データ以外のデータは、ＴＬフレーム１００に記載して装置間で送受信できる（この状態を「臨時通信（ＴＴＬ）モード」と呼ぶ）。このＴＴＬモードでは、伝送経路の端に位置する装置のうち、フリーな送受信Ｉ／Ｆがある側に新たな装置が接続されると、その新たに接続された装置を伝送経路に組み込むことができる。

その後、いずれかの装置がマスタノードに指定されると、その時点で接続されている装置間で再度リング状の伝送経路の形成が行われ、波形データも含めた全てのデータをＴＬフレームに記載して各装置（ノード）間で伝送するオーディオネットワークシステム１が形成される（この状態を「音声伝送（ＲＴＬ）モード」と呼ぶ）。このＲＴＬモードでも、伝送経路の端に位置する装置のうち、フリーな送受信Ｉ／Ｆがある側に新たな装置が接続されると、その新たに接続された装置を伝送経路に組み込むことができる。

ネットワークＩ／Ｆカード２１５を備える装置は、これらのＩＴＬモード、ＴＴＬモード、ＲＴＬモードを流動的に遷移することにより、各装置の接続状態に応じてオーディオネットワークシステム１を構築したり、構成を変更したりすることができる。以下、このシステムの構成や構成変更のための処理について説明する。

２．２ システム形成段階の動作
次に、図７に示した音響信号処理装置２において制御部４０のＣＰＵが実行する、オーディオネットワークシステムの構築や構成変更に関連する処理について説明する。
図９は、制御部４０のＣＰＵが電源ＯＮ時及びリセット時に実行する、システムの構築に関する処理のフローチャートである。なお、この処理は、送受信Ｉ／Ｆの組毎に、独立して行うものである。例えば、図８に示したネットワークＩ／Ｆカード２１５の場合、制御部４０のＣＰＵは、第１の送受信Ｉ／Ｆ３１，３４に対応する処理と、第２の送受信Ｉ／Ｆ３２，３３に対応する処理とを行う。以後の説明において、単に送信Ｉ／Ｆ，受信Ｉ／Ｆと言った場合には、実行中の処理と対応するＩ／Ｆを指すものとする。
また、制御部４０のＣＰＵは、電源ＯＮ時には、この処理と別に、本体側のＣＰＵ２０１から自機のＭＡＣアドレスや動作モードの設定に関する情報を取得する処理を行う。

制御部４０のＣＰＵは、電源ＯＮ時及びリセット時に、少なくとも自機のＭＡＣアドレスが取得できると、図９のフローチャートに示す処理を開始する。そして、まず図１０に示す物理接続確認処理の要求側動作を実行し、送受信Ｉ／Ｆにオーディオネットワークシステム１を形成する能力を有する装置が物理的に接続されているか否かを確認する（Ｓ１１）。

図１０に、この物理接続確認処理のフローチャートを示す。
この図に示すように、図９のステップＳ１１で実行する物理接続確認処理の要求側動作において、制御部４０のＣＰＵはまず、接続検出（ＡＳ）コマンドのＩＴＬフレームを、送信Ｉ／Ｆから出力する。このＡＳコマンドは、送信Ｉ／Ｆに何らかの装置が接続されていれば、その装置が受信する。

そして、受信した装置もネットワークＩ／Ｆカード２１５を備えていれば、その制御部４０のＣＰＵは、図１０の返答側動作のフローチャートに示す処理を開始する。
そして、この処理においては、返答側装置の制御部４０のＣＰＵは、受信したＡＳコマンドに対する応答であるＡＳ応答を生成し、応答のＩＴＬフレームとしてＡＳコマンドの送信元装置に返す（Ｓ４５）。この応答に記載する情報は、ステップＳ４１〜Ｓ４４で決定するが、自装置のＭＡＣアドレスを把握できていれば、そのＭＡＣアドレスを記載し（Ｓ４１，Ｓ４２）、自装置がＴＴＬモード又はＲＴＬモードのシステムに既に参加していれば、そのシステムのネットワークＩＤ及びシステム内での自機のノードＩＤも記載する（Ｓ４３，Ｓ４４）。

なお、ネットワークＩＤは、ＴＴＬモードの場合には「０」、ＲＴＬモードの場合にはシステムに固有な値である。また、システムに参加していない場合には、ＡＳ応答にネットワークＩＤとして「不定値」を示すコードを記載するとよい。また、ノードＩＤは、システム内で特定のノードを識別するためのＩＤであり、その値はシステム内でノード毎に固有な値である。

一方、ＡＳコマンドの送信を行った装置は、ＡＳ応答の受信を監視しつつ待機する。そして、所定時間経過してタイムアウトする前にＡＳ応答を受信すると（Ｓ３２）、送受信Ｉ／Ｆにオーディオネットワークシステム１を形成する能力のある装置が接続されていることがわかる。そこで、受信したＡＳ応答の内容に基づき、トポロジーテーブルの内容を更新する（Ｓ３３）。トポロジーテーブルは、自機と直接に又は他の装置を介して間接に接続されている各装置の接続順を登録するテーブルである。

図１１に、このトポロジーテーブルの例を示す。
この図に示すように、トポロジーテーブルには、自機のバックワード側とフォワード側にそれぞれどのような装置がどのような順で接続されているかを、ネットワークＩＤ，ノードＩＤ及びＭＡＣアドレスによって登録する。これらのうち、ＭＡＣアドレスは装置固有であるが、ネットワークＩＤ及びノードＩＤは、システムへの参加状況に応じて可変である。また、トポロジーテーブルに、装置の機種ＩＤや、後述する装置間のフレーム伝送遅延時間（又は装置間の距離）も登録するようにしてもよい。

また、トポロジーテーブルはここでは、バックワード側とフォワード側についてそれぞれ、図で一番上の欄が自機に直接接続されている装置の情報を示し、その次の欄が、一番上の欄に記載されている装置の１つ先に接続されている装置の情報を示し、という具合に記載する。

２組の送受信Ｉ／Ｆのうち、どちらに接続されている側がフォワード側であるかは、起動時には、Ｉ／ＦのＩＤ等により、任意に定めればよい。また、装置によって、異なる向きをフォワード側と認識していても、各装置の相対的な位置関係は把握できるので、特に問題はない。しかし、一旦ＴＴＬモード又はＲＴＬモードに移行した場合、図４の説明で述べたように、マスタノードから見て、一巡する音声伝送フレームを最初に送信する側をフォワード側に統一する。
あるいは、第１の送受信Ｉ／Ｆがバックワード側、第２の送受信Ｉ／Ｆがフォワード側、というように向きを固定し、装置間でフォワード側同士やバックワード側同士が接続された場合には、エラーとするようにしてもよい。このようにすると、ユーザによる接続の自由度は低下するが、システムの制御は容易である。

図１０の説明に戻ると、制御部４０のＣＰＵは、ステップＳ３３の後、返答側装置との間で適宜ＩＴＬフレームを送受信して、返答側装置に対しトポロジーテーブルの内容を伝達する（Ｓ３４）。具体的には、返答側装置と反対側に接続されている装置のデータを、接続順の情報も含めて送信し、その情報を、返答側装置のトポロジーテーブルに登録させる。
その後、返答側装置の情報を伝えるテーブル送信通知のＩＴＬフレームを生成し、ＡＳ応答を受信した側と反対側の送信Ｉ／Ｆから送信して（Ｓ３５）、図１０の処理を終了し、図９のステップＳ１２の処理に進む。

なお、図示は省略したが、このテーブル送信通知を受け取った装置は、自機のノードテーブルに、通知された返答側装置のデータを登録する。また、テーブル送信通知を受信した側と反対側に装置が接続されていれば、その装置にも、返答側装置の情報を伝えるテーブル送信通知のＩＴＬフレームを送信する。このようにして、図１０の処理を行った要求側装置から見て、返答側装置と反対側に接続されている装置全てにおいて、ノードテーブルに返答側装置のデータが登録される。
ただし、要求側動作自体は、ステップＳ３５の送信が完了した時点で終了してよい。

また、ステップＳ３２でタイムアウトした場合には、送信Ｉ／Ｆには装置が接続されていないか、又は接続されていても、オーディオネットワークシステム１を形成する能力のある装置ではないとわかるため、そのまま図１０の処理を終了し、図９のステップＳ１２の処理に進む。
なお、ステップＳ３１の時点で受信Ｉ／Ｆがネットワーククロックを検出できない等、送受信Ｉ／Ｆに装置が接続されていないことが明らかである場合には、ＡＳコマンドの送信を行わずに、ステップＳ３２の判断をＮＯとしてもよい。

図１０の処理が終了すると、制御部４０のＣＰＵは、図９のステップＳ１２において、物理接続確認処理において送受信Ｉ／Ｆにオーディオネットワークシステム１を形成する能力のある装置の接続が確認されたか否か（ステップＳ３２のＹ／Ｎ）を判断する。
そして、接続が確認されていなければ、ステップＳ１１に戻って再度物理接続確認処理を行う（所定時間待機した後でもよい）が、確認されていた場合には、図１２に示す論理接続準備処理に進み、接続が確認された相手装置との間で、どのような形でＴＴＬモード又はＲＴＬモードのシステムを形成できるかを判断する（Ｓ１３）。

この論理接続準備処理は、大まかに言えば、自装置と相手装置のネットワークＩＤを参照し、ＲＴＬ＞ＴＴＬ＞ＩＴＬの優先順位で、優先順位の低いモードの装置を、優先順位の高いモードの装置が参加しているシステムに組み込むことを決定する処理である。また、論理接続とは、装置間でＴＬフレームを循環させる共通の伝送経路を形成すること、又は既にある伝送経路に新たな装置を加えることを言う。

図１２に、この論理接続準備処理のフローチャートを示す。
この図に示すように、論理接続準備処理においては、制御部４０のＣＰＵはまず、自装置のネットワークＩＤにより、自装置がＲＴＬ，ＴＴＬ，ＩＴＬのうちどのモードであるかを判定する（Ｓ５１）。

そして、ＩＴＬモード又はＴＴＬモードの場合、次に、相手装置のネットワークＩＤを確認し、相手装置がＲＴＬ，ＴＴＬ，ＩＴＬのうちどのモードであるかを判定する（Ｓ５２）。ここでＲＴＬモードの場合、自装置の方が優先順位の低いモードであることがわかるため、自装置を相手装置が参加しているＲＴＬモードのシステムに組み込ませることを決定する。
そして、自装置がＩＴＬモードであれば、そのままシステムに組み込ませることができる状態であるので、図９のステップＳ１９の論理接続確立処理において、ＲＴＬモード移行のため返答側動作を行うことを決定する。

また、自装置がＴＴＬモードであれば、一旦リセットを受け、ＴＴＬモードのシステムから抜けてから相手装置が参加しているシステムに組み入れてもらうため、相手装置からのリセット命令を待つ状態に移行することを決定する。ここで一旦リセットを受けることを要求するのは、リング状の伝送経路が形成されている２つのシステムの端のノード同士をそのまま接続してしまうと、２つのリングが融合した伝送経路が形成され、接続時には伝送経路上に２つのＴＬフレームが存在してしまうことになり、フレーム伝送が正常に行えなくなってしまうためである。
そして、以上のように自装置の行うべき動作が決定すると、図１２の処理を終了し、図９のステップＳ１４の処理に進む。

また、ステップＳ５２でＩＴＬモード又はＴＴＬモードの場合、ステップＳ５３に進む。
そして、自装置がＩＴＬモードであって（Ｓ５３）、相手装置がＴＴＬモードである場合（Ｓ５４）、自装置の方が優先順位の低いモードであることがわかるため、自装置を相手装置が参加しているＴＴＬモードのシステムに組み込ませることを決定する。そこで、図９のステップＳ１９の論理接続確立処理において、ＴＴＬモード移行のため返答側動作を行うことを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。

また、自装置と相手装置が共にＩＴＬモードである場合、自装置と相手装置とでＴＴＬモードのシステムを形成することを決定するが、この時、システム内でどちらが暫定マスタノードとなるかを決める必要がある。この決定アルゴリズムは、任意のものでよいが、ここでは、ＭＡＣアドレスの大小で決定するようにしている。そこで、この場合、自装置のＭＡＣアドレスが相手装置のＭＡＣアドレスより大きいか否か判断する（Ｓ５５）。そして、自装置が大きければ、自装置を暫定マスタに設定し（Ｓ５６）、ＴＴＬモードへの移行を主導的に行うため、図９のステップＳ１９の論理接続確立処理においてＴＴＬモード移行のため要求側動作を行うことを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。

ステップＳ５５で自装置が小さければ、相手装置が暫定マスタとなるため、相手装置によりシステムに組み込んでもらうため、ＴＴＬモード移行のため返答側動作を行うことを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。
なお、暫定マスタを決定するためのアルゴリズムとしては、ＭＡＣアドレス大小の他、物理接続確認処理においてＡＳコマンドを送った方を暫定マスタとする、電源ＯＮ又はリセットからの時間が長い方を暫定マスタとする、これらの条件の組み合わせ、等も考えられる。

次に、ステップＳ５３で自装置がＴＴＬモードであった場合、相手側装置と接続すると、ツインモードの伝送経路が形成されるか否か判断する（Ｓ５７）。具体的には、相手装置が、自身が参加しているシステムの反対側の端に位置するノードであるか否か判断する。この判断は、トポロジーテーブルから、反対側の端のノードのＭＡＣアドレスを取得して行えばよい。

そして、この実施形態では、ＴＴＬモードはＲＴＬモードに移行するまでの暫定的な通信モードであることに鑑み、ＴＴＬモードでは、ネットワークの基本構成であるシングルモードの動作しか許可しない。このため、ステップＳ５７でＹＥＳの場合には、相手装置との間で論理接続を行わない。そこで、物理接続確認処理に戻ることを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。なお、この場合に相手装置と論理接続を行わないようにしたとしても、相手装置は少なくともＴＴＬモードのシステムには参加しているため、ＴＴＬモードのシステムに参加できない装置が出る恐れはない。

また、この場合、装置間の接続状況が変わらなければ、再度の物理接続確認処理後の論理接続準備処理でも、ステップＳ５７でＹＥＳとなるので、常にここまでの処理を繰り返すことになる。しかし、装置間の接続状況が変わった場合に、速やかに各装置を適当な通信モードに移行させられるよう、物理接続確認処理と論理接続準備処理とを定期的に行っておくことが好ましい。

また、ステップＳ５７でＮＯである場合、相手装置がＩＴＬモードであれば（Ｓ５８）、自装置の方が優先順位の高いモードであることがわかるため、相手装置を自装置が参加しているＴＴＬモードのシステムに組み込むことを決定する。そこで、図９のステップＳ１９の論理接続確立処理においてＴＴＬモード移行のため要求側動作を行うことを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。

また、相手装置がＴＴＬモードであれば（Ｓ５８）、自装置と相手装置が別々のＴＴＬモードのシステムに参加していることがわかる。この場合には、いずれか一方の装置を一旦システムから離脱させ、その装置を他方の装置が参加するシステムに組み入れる動作を行う（この場合、後述するように、装置を離脱させた側のシステムは、その後、解体されることになる）。

この場合に、どちらの装置を離脱させてもよいのであるが、ここでは、ステップＳ５５の場合と同様、接続された装置同士のＭＡＣアドレスの大小により決定するようにしている（Ｓ５９）。そこで、自装置のＭＡＣアドレスが相手装置のＭＡＣアドレスより大きい場合には、相手装置をシステムから離脱させるべく、リセット指示コマンドのＩＴＬフレームを相手装置に送信する（Ｓ６０）。また、相手装置はリセットにより後述のようにＩＴＬモードに戻るため、再度物理接続確認処理から処理をやり直すことを決定して図１２の処理を終了し、図９のステップＳ１４の処理に進む。
この場合、装置間の接続状況が変わらなければ、再度の物理接続確認処理後の論理接続準備処理の際には、ステップＳ５８で下側に進むことになる。

また、ステップＳ６０で自装置が小さければ、相手装置に自装置が参加するシステムを解体させるため、相手装置からのリセット命令を待つことを決定して図１２の処理を終了し、図９のステップＳ１４の処理に進む。
なお、ステップＳ６０の場合には、ステップＳ５５の説明で例示したアルゴリズムに加え、システムを構成するノードが少ない方を解体する、といったアルゴリズムも採用可能である。

また、ステップＳ５１で自装置がＲＴＬモードであった場合、相手装置がＩＴＬモードであれば（Ｓ６１）、自装置の方が優先順位の高いモードであることがわかるため、相手装置を自装置が参加しているＲＴＬモードのシステムに組み込むことを決定する。そこで、図９のステップＳ１９の論理接続確立処理においてＲＴＬモード移行のため要求側動作を行うことを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。

また、ステップＳ６１で相手装置がＴＴＬモードである場合も、自装置の方が優先順位の高いモードであることがわかるため、相手装置を自装置が参加しているＲＴＬモードのシステムに組み込むことを決定する。しかしこの場合、相手装置を一旦参加中のシステムから離脱させた上で組み込みを行う必要があるため、リセット指示コマンドのＩＴＬフレームを相手装置に送信する（Ｓ６２）。また、相手装置はリセットにより後述のようにＩＴＬモードに戻るため、再度物理接続確認処理から処理をやり直すことを決定して図１２の処理を終了し、図９のステップＳ１４の処理に進む。この場合、装置間の接続状況が変わらなければ、再度の物理接続確認処理後の論理接続準備処理の際には、ステップＳ６１で左側に進むことになる。

また、ステップＳ６１で相手装置がＲＴＬモードである場合には、基本的には、相手装置との間の論理接続は行わない。本実施形態においては、ＲＴＬモードは、オーディオネットワークシステム１を実際に音響信号処理に使用するモードであるとの位置づけであり、ユーザからの明示の意思なしにこのようなＲＴＬモードのシステムを壊すことは好ましくないので、ＲＴＬモードのシステム同士を結合することは行わないようにしているためである（システムに装置を追加すること自体は差し支えない）。

しかし、自装置が、自装置の参加するシステムの反対側の端の装置と接続された場合には、接続形態がカスケード接続からリング接続に変化することになるので、動作モードをシングルモードからツインモードに移行させることが考えられる。ＲＴＬモードの場合、この移行を許可するか否かは、図１の説明で述べた通り、マスタノードにおいてなされているモード設定によって決まる。

そこで、相手装置とネットワークＩＤが一致し、かつツインモード許可が設定されていた場合には（Ｓ６３）、ツインモードへの移行を決定する。そして、この場合、自装置と相手装置のどちらが論理接続処理で主導権を持つかが問題となるが、ここでは、バックワード側に位置する装置に主導権を持たせることとしている。そこで、ステップＳ６４での判断結果に応じて、図９のステップＳ１９の論理接続確立処理においてツインのＲＴＬモード移行のため要求側動作又は返答側動作を行うことを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。

また、ステップＳ６３でＮＯとなるのは、（ａ）相手装置とネットワークＩＤが異なる場合、すなわち別々のＲＴＬモードのシステム同士が接続された場合、又は（ｂ）ツインモードの動作が許可されていない場合である。これらのいずれの場合にも、相手装置との間で論理接続を行わないので、物理接続確認処理に戻ることを決定して、図１２の処理を終了し、図９のステップＳ１４の処理に進む。

また、この場合、装置間の接続状況が変わらなければ、再度の物理接続確認処理後の論理接続準備処理でも、ステップＳ６３でＮＯとなるので、常にここまでの処理を繰り返すことになる。しかしここでも、ステップＳ５７でＹＥＳの場合と同様、処理を定期的に行っておくことが好ましい。

再度図９の説明に戻る。
図１２に示した論理接続準備処理が終了すると、次に実行すべき処理が、論理接続処理、リセット待ち、物理接続処理のいずれかに決まった状態で、図９のステップＳ１４に進むことになる。
そして、その決まった処理が物理接続処理の場合、ステップＳ１４及びＳ２１でＮＯとなり、ステップＳ１１に戻って処理を繰り返す。

また、リセット待ちの場合、ステップＳ２１からＳ２２に進み、所定時間待機して、相手装置からのリセット要求を待つ。ここで、相手装置の側でも、電源ＯＮ時又はリセット時には図９に示す処理を開始している。そして、論理接続準備処理において、自装置と相手装置との関係が「リセット待ち」となる関係であった場合、相手装置が実行する論理接続準備処理において、相手装置はステップＳ６０又はＳ６２でリセット指示コマンドのＩＴＬフレームを送信してくるはずである。

ここで、図１３に、このリセット指示を受信した場合に制御部４０のＣＰＵが実行する処理のフローチャートを示す。この処理は、割り込みにより、他の処理とは独立して実行するものである。
そして、制御部４０のＣＰＵは、リセット指示を受信すると、まず自装置のリセットを行う（Ｓ７１）。この処理には、両側のセレクタ３５〜３８を折り返しライン／ＩＴＬフレーム送信部側に切り替え、自身をＩＴＬモードに戻すと共に、トポロジーテーブル及びネットワークＩＤを初期化する処理を含む。ただし、ＭＡＣアドレスや、マスタ／スレーブ、ツイン許可／不許可、二倍化／二重化の設定を消去する必要はない。

以上の後、リセット指示元にリセット完了を示すリセット応答のＩＴＬフレームを送信する（Ｓ７２）と共に、リセット指示を受信した側と反対側の送信Ｉ／Ｆから隣接ノードに対してリセット指示コマンドのＩＴＬフレームを送信し（Ｓ７３）、処理を終了する。
なお、制御部４０のＣＰＵは、ステップＳ７１でのリセット時に、それまで行っていた図９の処理は、中止する。そして、リセットに応じて改めて図９に示した処理を開始する。ただし、他装置からリセット指示があった場合、続けて接続要求コマンド等を受信することも考えられるため、図９に示した処理を開始するまでに、所定時間待機するようにしてもよい。
逆に、相手装置にリセット指示コマンドを送信した装置は、次の物理接続確認処理は、相手装置からのリセット応答の受信をトリガに開始するとよい。この時点であれば、相手装置はＩＴＬモードに戻っており、システムに組み入れることができると期待できるためである。

また、図１３のステップＳ７３から明らかなように、あるシステムの端の装置がリセットされると、システムに参加していた全ての装置が順次リセットされ、ＩＴＬモードに戻り、別のシステムに参加可能な状態となる。ＴＴＬモードで動作中のシステム同士を結合させる場合や、ＲＴＬモードで動作中のシステムにＴＴＬモードで動作中のシステムを吸収させる場合には、このように、リセットにより吸収される側のシステムに参加している装置を全て一旦ＩＴＬモードに戻すようにしている。

また、図示は省略したが、リセット応答を受け取った装置は、自装置のノードテーブルから、リセットを行った装置及びその先に接続されていた装置の情報を削除する。また、この削除を反対側に接続されている装置にも伝達し、リセットを行った装置及びその先に接続されていた装置の情報を順次削除させる。

再度図９の説明に戻る。
ステップＳ１３の論理接続準備処理において、論理接続確立処理を実行することを決定した場合、処理はステップＳ１４からＳ１５に進む。そして、要求側として論理接続確立処理を実行する場合には、相手装置を自装置が参加しているシステムに組み入れてもＴＬフレームの伝送に支障がないか否かを判断する（Ｓ１６〜Ｓ１８）。ここでは、この判断は、ノード数及びフレーム伝送経路の総距離を基準に行う。

このうちノード数は、トポロジーテーブルを参照して容易に把握することができ、相手装置を組み入れても所定数以内に収まれば、問題なしとする。ただし、ツインモードへ移行する場合、接続は、既にシステムに参加しているノードとの間で行うため、接続によってノード数は増加しないことに注意する必要がある。

また、フレーム伝送経路の総距離については、まず、自装置と相手装置との間の距離を計測する。この計測は、相手装置に対し、距離計測用のＩＴＬフレーム（図４（ｂ）に示した形式のもの）を送信してから、相手装置がその受信後直ちに返してくる応答のＩＴＬフレーム（こちらも図４（ｂ）に示した形式のもの）を受信するまでの時間を計測することにより、行うことができる。相手装置が距離計測用のＩＴＬフレームを受信してから応答のＩＴＬフレームを送信するまでに要する時間は、ネットワークＩ／Ｆカード２１５の種類やバージョン毎に一定であると考えられるから、計測した時間から、その一定な時間を引いた時間が、装置間の距離に比例する時間となる。計測は何度か行い、そのうち安定とみなせる値の中の最大値を採用するとよい。また、この計測を行う間は、誤差を防止するため、ＡＳコマンド等の他のＩＴＬフレームの送受信は行わないようにするとよい。

そして、各装置をシステムに参加させる際に、必ずこの距離計測を行って、隣接装置間の距離をトポロジーテーブル等に記録しておけば、それらを合計して、新たな装置を組み入れた場合のフレーム伝送経路の総距離を求めることができる。そして、この総距離が所定値以内に収まれば、問題なしとする。

ただし、システムがツインモードで動作中の場合、システムのどこかで接続の切断やノードの停止が起こると、その両側で伝送経路の折り返しが設定され、２つのリングが結合した１つのリング状の伝送経路が形成されて、シングルモードの動作に戻ることになる。この場合、一般に、ツインモードの時の伝送経路よりも、シングルモードに戻った後の伝送経路の方が長くなる。

そこで、ツインモードで動作中の場合、現に使用している伝送経路に相手装置を組み入れた場合についてだけでなく、どの部分で接続の切断やノードの停止が起こってシングルモードの動作に戻ったとしても、その戻った後の伝送経路の総距離が所定値以内に収まる場合に、問題なしとする。
そして、ノード数と総距離のどちらも問題なしの場合、ステップＳ１８からＳ１９に進み、論理接続確立処理を実行する。また、問題ありの場合、相手装置をシステムに組み入れることはできないため、ステップＳ１８からステップＳ１１に戻り、処理を繰り返す。このとき、組み入れ不可の通知を送信するようにしてもよい。

なお、ステップＳ１６やＳ１７の基準を設けた理由の１つは、ノード数が多かったり、伝送経路の総距離が長かったりすると、ＴＬフレームに伝送経路を１周させるのに要する時間が長くなり、マスタノードから送信されたＴＬフレームを、後の周期のＴＬフレームの生成に必要なタイミングまでにマスタノードに戻せなくなってしまうためである。
従って、この点を考慮すると、
（周期更新量ｋに応じて決まるフレーム伝送遅延の許容時間）
−（１ノード当たりの伝送遅延時間）×（ノード数）
＞（伝送経路の総距離に依存する伝送遅延時間）
であれば、ステップＳ１８で問題ないと判断してよいとも考えられる。
また、周期更新量ｋに応じて決まるフレーム伝送遅延の許容時間は、ｋサンプリング周期より、マスタノード内での新ＴＬフレームの準備に係る時間である所要時間αだけ短い時間である。従って、ｋを増加させれば、許容時間も増加させることができる。
そこで、ノード数や伝送経路の総距離が上記の条件を満たさない場合に、ｋを増加させることにより、条件を満足させることも考えられる。

次に、図１４に、図９のステップＳ１９で実行する論理接続確立処理のフローチャートを示す。
この処理は、要求側動作を行う装置が、返答側動作を行う装置を、自装置が参加しているシステムに組み入れ可能であることを最終的に確認し、この組み入れを実行する処理である。また、返答側動作は、基本的に受身の処理であり、要求側動作を行う装置から受信したコマンドに応じた処理を行うものである。また、論理接続準備処理において、自装置と相手装置との関係が「返答側動作」となる関係であった場合、相手装置が実行する論理接続準備処理において、相手装置は論理接続準備処理において「要求側動作」を行う決定をするはずである。

この論理接続処理において、要求側装置はまず、相手装置（返答側装置）がシステムに組み入れ可能な状態であることを最終的に確認するための接続要求（ＣＱ）コマンドのＩＴＬフレームを、送信Ｉ／Ｆから出力する（Ｓ８１）。なお、このＣＱコマンドに、相手装置をどのモードのシステム（ＲＴＬ／ＴＴＬ及びシングル／ツイン）に組み入れるかを示す情報を記載しておき、相手装置に、そのモードでの通信の準備をさせるようにするとよい。

そしてその相手装置は、ＣＱコマンドを受信すると、制御回路４０のＣＰＵが、自装置の状況に応じて、論理接続準備中，ＲＴＬ動作中，ＴＴＬ動作中，接続可のいずれかの状態を示すＣＱ応答のＩＴＬフレームを、ＣＱコマンドの送信元に返してくる（Ｓ１０１）。
ここで、相手装置がシステムに組み入れ可能な状態であることは、論理接続準備処理において確認しているため、応答は基本的には「接続可」になるはずである。しかし、相手側装置から見て自装置と反対側にも他の装置が接続されている場合、自装置がステップＳ１４〜Ｓ１８の処理を行っている間に、反対側の装置からの要求により、そちら側のシステムに組み入れられてしまっていたり、組み入れ準備が進行してしまっていたりすることも考えられる。

上記の「接続可」以外の応答は、このような場合になされるものである。そして、「論理接続準備中」は、他の装置からＣＱコマンドを受信し、その後通信モード切替指示（ＴＭ）コマンドの受信を待っている状態であることを示す。「ＲＴＬ動作中」及び「ＴＴＬ動作中」は、既にＲＴＬモードのシステム又はＴＴＬモードのシステムに組み入れられたことを示す。

一方、ＣＱコマンドの送信を行った装置は、ＣＱ応答の受信を監視しつつ待機する。そしてここで、所定時間経過してタイムアウトするか、論理接続準備中を示すＣＱ応答を受信した場合（Ｓ８２）、所定回数まではリトライする（Ｓ８８，Ｓ８９）。しかし、それでも内容が変わらなければ、今回はシステムへの組み入れはあきらめて物理接続確認処理に戻ることを決定し、図１４の処理を終了する。なお、応答タイムアウトの場合にはステップＳ８９で所定時間待機する必要はない。

また、ＲＴＬ動作中を示すＣＱ応答を受信した場合（Ｓ８３）、相手装置をシステムに組み入れることはできないため、やはり物理接続確認処理に戻ることを決定し、図１４の処理を終了する。
また、ＴＴＬ動作中を示すＣＱ応答を受信した場合には（Ｓ８４）、自装置がＲＴＬモードのシステムに参加しているか、又は自装置のＭＡＣアドレスが相手装置より大きい場合（ＴＴＬモードのシステム同士が接続されたとして相手装置をシステムから離脱させてよい場合）には（Ｓ８０）、リセット指示コマンドのＩＴＬフレームを相手装置に送信する（Ｓ８１）。そして、初めから処理をやり直して相手装置をシステムに組み入れるべく、物理接続確認処理に戻ることを決定し、図１４の処理を終了する。また、ステップＳ９０でＮＯの場合には、相手装置をシステムに組み入れることはできないため、単に物理接続確認処理に戻ることを決定し、図１４の処理を終了する。

一方、接続可を示すＣＱ応答を受信した場合には、ステップＳ８２〜Ｓ８４の判断が全てＮＯとなる。そして、相手装置に対して最終的に動作モードの変更を要求する通信モード切替指示（ＴＭ）コマンドを、送信Ｉ／Ｆから送信する（Ｓ８５）。なお、このＴＭコマンドには、相手装置をどのモード（ＲＴＬ／ＴＴＬ及びシングル／ツイン）に移行させるか、及び相手装置を組み入れるシステムのネットワークＩＤの情報を記載しておく。

そしてその相手装置は、ＴＭコマンドを受信すると、制御回路４０のＣＰＵが、まず移行了解を示すＴＭ応答のＩＴＬフレームを、ＴＭコマンドの送信元に送信する（Ｓ１０３）。そして、その後直ちに、ＴＭコマンドを受信した側について、ＴＬフレームのループバックを解除する（Ｓ１０４）。この解除は、解除する側の２つのセレクタを、それぞれ受信Ｉ／Ｆ側及びＴＬフレーム送信部側に切り替えればよい。

新たにシステムに組み入れられる装置は、まだＴＬフレームの送受信は行っていないため、どのタイミングでループバックの解除を行っても問題ない。また、どのモードに切り換える場合でも、ループバックの解除は同じように行う。ただし、ループバックを解除してしまうと、解除した側では、ＩＴＬフレームの直接送信ができなくなってしまう（ただし、ＴＬフレームに書き込めば送信できる）ため、ＴＭ応答の送信は、ループバックの解除前に行っておく。

ステップＳ１０４の後は、ＣＰＵは、自機の動作モード及びネットワークＩＤを、ＴＭコマンドの指定に従って変更する（Ｓ１０５）と共に、モード移行完了を上位層（本体側ＣＰＵ）に通知して（Ｓ１０６）、処理を終了する。ステップＳ１０５の時点で、動作モード及びシステムの構成に応じて、第１，第２のデータ入出力部１０，２０のどちら（又は両方）を用いてＴＬフレームに対する波形データやイーサネットフレームの読み書きを行うかや、ＴＬフレームに対する波形データの読み書きを行うか否か、等の設定を行う。

一方、要求側装置は、ＴＭコマンドの送信後、相手装置からタイムアウト前にＴＭ応答を受信すると（Ｓ８６）、ＴＬフレームの送受信をしていないタイミングでセレクタを切り替え、相手装置側のループバックを解除する（Ｓ８７）。既にシステムに参加している装置では、ＴＬフレームの送受信中にループバックを解除してしまうと、ＴＬフレームを途中から別の送信先に送信してしまい、フレームを壊してしまうことになる。そこで、図５にあるような、フレームとフレームの合い間でループバックの解除を行うことが重要である。また、要求側装置が初めて他の装置と論理接続を行う場合には、ステップＳ８７の段階ではまだＴＬフレームの循環を行っていない。そこで、ステップＳ８７の後、マスタノード（ＴＴＬモードの場合は暫定）として、ＴＬフレームの生成と送出を開始すればよい。
そして、以上で図１４の論理接続処理を終了する。

また、ステップＳ８６でタイムアウトした場合には、今回はシステムへの組み入れはあきらめて物理接続確認処理に戻ることを決定し、図１４の処理を終了する。
また、返答側装置も、ＣＱ応答の送信後所定時間内にＴＭコマンドの受信がなかった場合、タイムアウトと判断し（Ｓ１０２）、今回はシステムへの組み入れはあきらめて物理接続確認処理に戻ることを決定し、論理接続処理を終了する。返答側動作の開始後所定時間内にＣＱコマンドを受信しなかった場合も、同様とするとよい。

再度図９の説明に戻るが、図１４に示した論理接続確立処理の終了後は、ステップＳ２０に進む。そして、論理接続確立処理において接続が確立した（要求側動作のステップＳ８７または返答側動作のステップＳ１０４を実行した）場合にはそのまま処理を終了する。一方、再度物理接続を行うことを決定した場合には、ステップＳ１１に戻って処理を繰り返す。

そして、複数の音響信号処理装置２において、制御部４０のＣＰＵが図９乃至図１４を用いて説明した処理を実行することにより、電源がＯＮされ、ケーブルが接続された装置から順に、自動的に、ＴＴＬモードでＴＬフレームを循環させるネットワークシステムを形成することができる。

この状態では、まだ波形データの伝送は行われないものの、システムを構成するノードとなった各装置間では、イーサネットフレーム及びＩＴＬフレームを、ＴＬフレームに書き込んで任意に送受信することができる。従って、ある装置のコンソールを操作し、その操作内容を他の装置に伝達してその装置におけるパラメータの値を編集するといった動作は、問題なく行うことができる。また、イーサネットフレームを用いたＩＰパケットの送受信により、複雑なアルゴリズムに従ったネゴシエーションも容易に行なうことができる。

なお、上述のように、図９に示した処理は、送受信Ｉ／Ｆの組毎に、独立して行うものである。また、複数の装置によりシステムが形成された後は、その両端の装置が、ループバックを行っている側の送受信Ｉ／Ｆについて、独立して行うものである。
従って、システムの両側で同時に新たな装置がシステムに組み入れられてしまい、それぞれ片方のみの組み入れではステップＳ１６〜Ｓ１８の条件を満たすのに、両側の組み入れがなされた状態ではこの条件を満たさなくなってしまうこともあり得る。
このような場合には、フォワード側でもバックワード側でも、予め定めておいた一方の側で組み入れられた装置を、マスタノードの判断により強制的にシステムから除外して、ＴＬフレームの循環が可能な状態を保つようにするとよい。

ところで、ここまでに説明した処理には、ＲＴＬモードのシステムに新たな装置を組み込む処理は含まれているが、最初に装置をＲＴＬモードに設定する処理は含まれていない。次に、この処理について説明する。
本実施形態においては、マスタノードを指定するためのコマンドとして、動作モード切替（ＯＭ）コマンドを用意しており、このコマンドを受け取った装置が、自身をマスタノードに設定して、最初にＲＴＬモードに移行する。

また、ＯＭコマンドは、何れかの装置がマスタノードを自動的に決定して発行することも妨げられないが、ユーザの指示に応じて発行することが好ましい。この場合、オーディオネットワークシステム１を構成させようとする装置の少なくとも１つには、ユーザからマスタノードの選択を受け付ける機能を設ける。この機能としては、トポロジーテーブルを参照して、通信可能な範囲の装置のリストをユーザに提示し、その中からマスタノードを選択させるものでよい。この時、同時に動作モード（ツイン許可／不許可，ツイン時二倍化／二重化等）の設定も受け付けるとよい。

なお、ＩＴＬフレームを用いれば、各装置の動作モードによらず、物理接続がなされている範囲の全ての装置と通信可能である。ＴＴＬモード（ＲＴＬモードでも）で動作中の装置間では、ＩＴＬフレームをＴＬフレームに記載して伝送し、ＴＬフレームの伝送経路が途切れている部分は、ＩＴＬフレームをＩＴＬフレーム送信部からそのまま送信すればよい。

そして、ユーザによりマスタノードの選択がなされた場合、その選択を受け付けた装置は、マスタノードとして選択された装置を送信先として、パラメータとして動作モードの設定を記載した、ＯＭコマンドのＩＴＬフレームを送信する。この送信は、トポロジーテーブルを参照し、送信先の装置が存在している側に対して行う。

図１５に、このＯＭコマンドを受信した場合に制御部４０のＣＰＵが実行する処理のフローチャートを示す。
この図に示すように、ＯＭコマンドを受信した装置の制御部４０のＣＰＵは、まず、受信したコマンドが自装置宛か否か判断する（Ｓ１１１）。そして、自装置宛でなければ、受信したＯＭコマンドのＩＴＬフレームを、そのまま受信した側と反対側に送信して（Ｓ１１７）処理を終了する。ＯＭコマンドが宛先の装置に届くまでは、途中の各装置がこのように順次ＩＴＬフレームの伝送を仲介する。この点は、他のコマンドの場合でも同様である。

一方、ステップＳ１１１で自装置宛であれば、ＯＭ応答のＩＴＬフレームを、ＯＭコマンドの送信元装置を送信先として、その装置が存在する側に対して送信する（Ｓ１１２）。その後、図１３のステップＳ７１の場合と同様、自装置をリセットし、現在何らかのシステムに参加していれば、そのシステムを一旦離脱する（Ｓ１１３）。その後、自装置をマスタノードに設定する（Ｓ１１４）と共に、自装置にＲＴＬモードの固有のネットワークＩＤを設定する（Ｓ１１５）。その後、両側にリセット指示コマンドのＩＴＬフレームを送信して（Ｓ１１６）、処理を終了する。

この後、両側の装置から始まって通信可能な範囲の装置が順次リセットされていく。そして、マスタノードとなった装置自体も、図９に示した処理を開始し、ＲＴＬモードのシステムに参加している装置として、両側に接続されている装置を、条件の許す限り順次システムに組み込んでいく。なお、図９に示した処理は、隣接ノードからのリセット応答の受信をトリガに開始するとよい。この時点であれば、隣接ノードはＩＴＬモードに戻っており、システムに組み入れることができると期待できるためである。
以上の処理により、音声伝送の可能なＲＴＬモードのオーディオネットワークシステム１を、ユーザの指示に応じてマスタノードを設定して形成することができる。

なお、一度システムが形成された後でも、両端に新たな装置が接続された場合には、随時その装置をシステムに組み入れることができる。また、ユーザは、マスタノードや動作モードを変更したい場合、随時指示を行ってＯＭコマンドを発行することができる。
そして、オーディオネットワークシステム１がＲＴＬモードで動作中であっても、いずれかのノードが自分宛のＯＭコマンドを受け取ると、そのノードが新たなマスタノードとなり、図１５に示した処理によりシステム全体をリセットして再度オーディオネットワークシステム１の形成を行う。

２．３ システム形成の具体例
次に、図１６乃至図２０を用いて、ここまでに説明してきた処理による、オーディオネットワークシステムの形成手順の具体例を説明する。
まず、図１６及び図１７には、装置Ａ乃至装置Ｅの５台の装置が予め通信ケーブルで接続されており、装置Ａから装置Ｅの電源を順次ＯＮしていく場合の、システムの構成手順の例を示す。

まず、図１６（ａ）に示すように装置Ａ，Ｂの電源がＯＮされると、これらの装置は、それぞれ図９に示した処理を開始し、図１０に示した物理接続確認処理によりＡＳコマンドとＡＳ応答を交換することにより互いの存在を認識して情報を交換し、トポロジーテーブルに互いの情報を登録する（変更部分をハッチングで示した、以下同様）。そして、図１２の論理接続準備処理において、双方がＩＴＬモードであることから、ステップＳ５５，Ｓ５６でいずれかの装置を暫定マスタノードとして、図１４の論理接続処理により、装置Ａと装置Ｂとで、ＴＴＬモードのシステムを構成することができる。

次に、（ｂ）に示すように装置Ｃの電源がＯＮされると、装置Ｂは物理接続確認処理により装置Ｃの存在を認識して装置Ｃと情報を交換し、トポロジーテーブルに互いの情報を登録する。
その後、（ｃ）に示すように、装置Ｂは装置Ｃに反対側に既に接続されている装置Ａの情報を通知し、装置Ａには反対側に新たに接続された装置Ｃの情報を通知する。その結果装置Ａ〜Ｃの全てに、電源ＯＮ済みの全ての装置の情報が揃うことになる。
また、装置ＢがＴＴＬモードで、装置ＣがＩＴＬモードであるから、図１４の論理接続処理により、装置Ｂが装置Ｃをシステムに組み入れる。

次に（ｄ）に示すように装置Ｄの電源がＯＮされた場合も、（ｂ）の場合と同様、装置Ｃは物理接続確認処理により装置Ｄの存在を認識して装置Ｄと情報を交換し、トポロジーテーブルに互いの情報を登録する。

その後、図１７（ｅ）に示すように、装置Ｃは装置Ｄに反対側に既に接続されている装置Ｂ，Ａの情報を通知し、装置Ｂには反対側に新たに接続された装置Ｄの情報を通知する。また、（ｆ）に示すように、装置Ｂは装置Ｃから通知された装置Ｄの情報を、反対側に接続されている装置Ａに通知する。以上の結果、装置Ａ〜Ｄの全てに、電源ＯＮ済みの全ての装置の情報が揃うことになる。
また、装置ＣがＴＴＬモードで、装置ＤがＩＴＬモードであるから、図１４の論理接続処理により、装置Ｃが装置Ｄをシステムに組み入れる。

同様にして、（ｇ）で装置Ｅの電源がＯＮされた場合も、システムの端のノードである装置Ｄが新たに検出された装置Ｅとコンタクトし、システムに組み入れる。また、ノードテーブルの情報も、（ｈ）に示すように、各装置が把握していない情報を順次通知することにより、装置Ａ〜Ｅの全てに、電源ＯＮ済みの全ての装置の情報が揃うことになる。
以上の手順により、順次電源のＯＮされた装置Ａ〜Ｅにより、ＴＴＬモードでＴＬフレームを循環させるネットワークシステムを自動的に形成することができる。上記の例において、電源ＯＮをケーブル接続に置き換えても同様な動作をすることは、もちろんである。

次に、図１８に、ＴＴＬモードで動作中のシステム同士が接続された場合の動作例を示す。
この図には、装置Ａ〜装置ＣがＴＴＬモードのシステムを形成しており、装置Ｄ，装置Ｅが、これとは別のＴＴＬモードのシステムを形成している状態で、装置Ｃと装置Ｄとが新たに通信ケーブルにより接続された場合の例を示している。
この場合、装置Ｃと装置Ｄは、定期的に図９のステップＳ１１で物理接続確認処理を行っている状態であるから、この物理接続確認処理により、互いの存在を確認する（ａ）。

そして、ステップＳ１３の論理接続準備に進むと、ＴＴＬモードの装置同士が接続されたため、ＭＡＣアドレスの大きい装置Ｃが、図１２のステップＳ６０で、装置Ｄに対してリセット指示コマンドを送信する。その結果、装置Ｄはシステムを離脱してＩＴＬモードに戻る（ｂ）。

また、装置Ｄは、リセット処理の一環として、装置Ｃの反対側の装置Ｅにもリセット指示コマンドを送信する。その結果、装置ＥもＩＴＬモードに戻る（ｃ）。
一方、装置Ｃは、装置Ｄにリセット指示コマンドを送信した後、再度物理接続確認処理、論理接続準備処理、論理接続確立処理を順次行って、ＩＴＬモードとなった装置Ｄを、自身の参加しているシステムに組み入れる（ｄ，ｅ）。

また、装置Ｄは、システムに組み入れられた後、システムの端のノードとして物理接続確認処理、論理接続準備処理、論理接続確立処理を順次行って、ＩＴＬモードとなっている隣接の装置Ｅを、自身の参加しているシステムに組み入れる（ｅ，ｆ）。
ＴＴＬモードで動作中のシステム同士が接続された場合、以上の手順により、これらを結合した１つのシステムを自動的に形成することができる。

次に、図１９に、ＴＴＬモードで動作中のシステムを構成する装置が動作モード切替（ＯＭ）コマンドを受信した場合の動作例を示す。
この図には、装置Ａ〜装置ＥがＴＴＬモードのシステムを形成しており、このうち装置ＢがＯＭコマンドを受信した場合の例を示している。

この場合、ＯＭコマンドを受信した装置Ｂは、図１５に示した処理により、自身をリセットして参加中のシステムから離脱すると共に、自身をマスタに設定し、ＲＴＬモードに移行する（ａ，ｂ）。そしてさらに、両側の装置にリセット指示コマンドを送信し、両側の装置も参加中のシステムから離脱させ、ＩＴＬモードに戻す（ｃ）。
このリセット指示コマンドは、（ｄ）では装置Ｃから装置Ｄへ、（ｅ）では装置Ｄから装置Ｅへの、接続されている全ての装置に順次伝達され、全ての装置が一旦ＩＴＬモードに戻される。

一方、装置Ｂは、装置Ａ及び装置Ｃがリセットを完了してリセット応答を送信してくると、図９に示す処理を開始する。そして、物理接続確認処理、論理接続準備処理、論理接続確立処理を順次行って、ＩＴＬモードとなっている隣接の装置Ａ，Ｃを、それぞれ自身をマスタとするＲＴＬモードのシステムに組み入れる（ｄ，ｅ）。

また、その後、（ｅ）の時点でシステムの端のノードとなっている装置Ｃが、物理接続確認処理、論理接続準備処理、論理接続確立処理を順次行って、ＩＴＬモードとなっている隣接の装置Ｄを、自身の参加しているシステムに組み入れる（ｆ）。そして、装置Ｄも、同様に装置Ｅを自身の参加しているシステムに組み入れる（ｇ）。

ＴＴＬモードで動作中のシステムを構成する装置がＯＭコマンドを受信した場合、以上の手順により、ＴＴＬモードのシステムをＲＴＬモードのシステムに組み替えることができる。なお、ＲＴＬモードで動作中のシステムを構成する装置がＯＭコマンドを受信した場合でも、各装置の動作は同様なものである。

次に、図２０に、シングルモードからツインモードへの移行動作例を示す。
この図には、装置Ｄ→Ｅ→Ａ→Ｂ→Ｃの順で接続され、ＲＴＬモードで動作しているシステムにおいて、両端の装置Ｃと装置Ｄとがケーブルにより接続された場合の例を示している。ただし、ツインモードへの移行は許可されているとする。

この場合、装置Ｃと装置Ｄとは、定期的に図９のステップＳ１１で物理接続確認処理を行っている状態であるから、ケーブルにより接続されると、この物理接続確認処理により、互いの存在を確認する（ａ，ｂ）。また、トポロジーテーブルには、互いの情報が、反対側の端のノードの情報として登録されているが、これに加え、新たに接続された側のノードとしても登録する（ｂ）。装置Ｃと装置Ｄは、この時点で、物理接続がリング状になされたことを把握できる。

また、装置Ｃと装置Ｄは、カスケード接続の場合には、新たに接続された装置の情報を、その装置と反対側に接続されている装置に通知する。しかし、リング接続の場合にこれを行うと、装置Ｃが発した通知と、装置Ｄが発した通知とが重複してしまうし、接続に端がないため、どこで通知をやめればよいかもはっきりしない。

そこで、リング接続の場合には、フォワード側の装置のみが、新たに接続された装置の情報を、その装置と反対側に接続されている装置に通知することとしている。また、この通知を受けた各装置は、自機が追加された旨の通知であると判断した場合には、それ以上先に通知を行わないこととしている。

図の例では、装置Ｄが、装置Ｃが追加された旨の通知を反対側の装置Ｅに対して行い、その通知が装置Ｅ→Ａ→Ｂ→Ｃと順次伝わっていく。しかし、装置Ｃは、この通知を、自機が追加された旨の通知であると判断し、このことにより通知がシステムを１周したことがわかるため、ここで通知の伝達は終了する。
以上の処理により、各装置は、フォワード側の（形式的な）端とバックワード側の（形式的な）端が同じ装置であること、すなわち接続がリング状になったことを把握することができる（ｃ）。

また、装置Ｃについては、論理接続準備処理において、図１２のステップＳ６４の判断がＹＥＳとなり、その後の論理接続確立処理において、装置Ｃと装置Ｄが互いの間のループバックを解除することにより、フレーム伝送経路が、２つのリング状の経路に変化し、ツインモードの接続が確立される。
ＲＴＬモードで動作しているシステムにおいて、両端の装置がケーブルにより接続された場合、以上の処理により、ツインモードの動作に移行することができる。

２．４ 伝送経路の切断時の動作
次に、ＲＴＬモード又はＴＴＬモードで動作中のオーディオネットワークシステムにおいてノード間の接続の切断が発生した場合の動作について説明する。
ＲＴＬモード又はＴＴＬモードで動作中のオーディオネットワークシステムにおいて、各ノードは、隣接ノードとの間の接続が切断されたことを検出した場合、切断を検出した側のセレクタを折り返しライン／ＩＴＬフレーム送信部側に切り替え、切断を検出した側にＴＬフレームの伝送経路のループバックを設定する。

隣接ノードとの間の接続が切断された状態でその隣接ノードに対してＴＬフレームを送信しても、そのＴＬフレームは単に失われるだけであるので、切断された接続より先のノードはシステムから除外し、残りのノードだけで新たな伝送経路を形成してＴＬフレームの循環を継続するためである。
なお、以下の図２１及び図２２では、ＲＴＬモードのシステムに切断が生じた場合の例を示しているが、ＴＴＬモードの場合にも、ＲＴＬをＴＴＬと読み替えれば同様な動作となる。

図２１に、接続切断時のシステム構成変更手順の例を示す。
この図は、装置Ａ〜装置Ｆの６台の装置によりＲＴＬモードのオーディオネットワークシステムが形成されている状態で、装置Ｄと装置Ｅとの間の結線が切断された場合の例を示している。なお、結線の切断には、通信ケーブル自体が物理的に切断された場合の他、通信ケーブルが装置から抜き取られた場合や何れか一方の装置において故障によりオーディオネットワークへの送信ないし受信ができなくなった場合も含む。また、図中の「Ｍ」は、マスタノード、「ＬＢ」は、ループバックが設定されている装置を示す。

そして、図２１（ａ）に示すように結線に切断が発生すると、両方向の伝送路が切断された場合は切断箇所の両側の装置で、片方向の伝送路のみが切断された場合はその切断された伝送路の受信側の装置で、切断箇所のある側の隣接装置からのＴＬフレームの信号が途絶えたり、ネットワーククロックの抽出ができなくなったりする。

この場合、ＴＬフレームの途中で信号が途切れたこと、あるいは、ネットワーククロックが抽出できなくなったことを検出した装置は、その側で切断が発生したと判断し、直ちに検出した側のセレクタを折り返しライン／ＩＴＬフレーム送信部側に切り替え、切断を検出した側にＴＬフレームの伝送経路のループバックを設定する。

例えば、図８に示した第２の受信Ｉ／Ｆ３３が切断を検出した場合、セレクタ３７を折り返しライン側に、セレクタ３６をＩＴＬフレーム送信部５４側に切り換える。
ただし、これだけでは、隣接装置の送信Ｉ／Ｆから自機の第２の受信Ｉ／Ｆ３３に至る伝送経路が切断されたとわかるだけで、自機の第２の送信Ｉ／Ｆ３２から隣接装置の受信Ｉ／Ｆに至る通信経路が切断されたか否か、さらには、隣接装置が切断を検出できているか否かは定かではない。

そこで、切断を検出した受信Ｉ／Ｆと対応する送信Ｉ／Ｆ（ここでは第２の送信Ｉ／Ｆ３２）から、切断発生を通知する切断通知コマンドを隣接装置に対して送信する。このコマンドは、ＩＴＬフレーム送信部５４が、ＩＴＬフレーム１２０の形式で生成して送信Ｉ／Ｆに供給する。そして、この切断通知コマンドにより、隣接装置に、切断が発生したことを確実に伝達できる。

なお、両方向の伝送路が切断されている場合には、隣接装置側でも切断を検出できているはずであるから、切断通知コマンドが届かなくても問題ない。また、切断通知コマンドの送信は、切断が解消するか、新たな装置が接続されて、切断の発生した側から接続検出（ＡＳ）コマンドを受信するまで、定期的に行う。

（ｂ）は、切断点の両側の装置が、切断を検出した側にループバックを設定した状態を示す。図に示す例では、このことにより、装置Ａから装置Ｄまでを循環する伝送経路と、装置Ｅと装置Ｆの間を循環する伝送経路とが形成される。

なお、切断が発生した場合、各装置はＴＬフレームの通過中にループバックを設定することも考えられる。そしてこの場合、送信中のＴＬフレームは破損する。しかし、この場合でも、後述のように、システム内の各ノードはＴＬフレームの破損を検出できるし、マスタノードも破損したフレームを廃棄して新たなフレームを作成できるため、大きな問題にはならない。従って、切断によって生じた２つの装置群のうち、マスタノードが存在する側は、切断箇所やタイミングによって０〜２のＴＬフレームに記載されていたデータを失うものの、ＲＴＬモードの動作を継続することができる。

一方、切断によりマスタノードと切り離されてしまった装置については、もはやマスタノードが送信したＴＬフレームが到達しないため、ＲＴＬモードでの動作はできない。各装置は、トポロジーテーブルを参照することにより、切断によりマスタノードと切り離されたか否かを判断できるので、マスタノードと切り離されたと判断した装置は、自身をリセットすると共に、切断側と反対側にも、リセット要求を送信する。
そして、図１３に示した処理により、マスタノードと切り離されたノードは（ｃ）に示すように全て一旦ＩＴＬモードに戻る。

ただし、その後は、適宜図９に示す処理を開始し、図１６等を用いて説明したものと同様な手順で、（ｄ）に示すように装置Ｅ及び装置ＦはＴＴＬモードのシステムを自動的に形成することができる。そして、切断された結線が復旧されると、一旦切り離された装置Ｅ及び装置Ｆを、図１８等を用いて説明したものと同様な手順で、ＲＴＬモードで動作中のシステムに組み入れることができる。

なお、切断を検出した装置は、ＩＴＬフレーム又はＴＬフレーム中の管理データにより、切断の発生を、切断箇所と反対側の装置に順次通知する。そして、切断の通知を受けた各装置は、切断箇所より先に接続されていた装置の情報を、トポロジーテーブルから削除する。

また、切断発生時点でＴＬフレームの先頭が装置Ｅ又は装置Ｆに位置していた場合、何も対応しないと、装置Ｅと装置Ｆの間をＴＬフレームが循環し続けることも考えられる。そこで、このような事態を防止するため、ＴＬフレームの受信時にフレーム通し番号を確認し、２度同じ通し番号のＴＬフレームを受信した場合には、そのＴＬフレームを折り返さずに破棄するようにするとよい。

また、図２２に、接続切断時のシステム構成変更手順の別の例を示す。
この図には、装置が停止した場合の例を示している。結線に変化がなくでも、急に電源が切断される等して装置が停止することも考えられる。そして、この場合にも、停止した装置の両側の装置は、隣接装置からのネットワーククロックが検出できなくなるため、このことをトリガに、図２２（ａ）に示すように伝送経路の切断を検出することができる。停止した装置の隣の装置（Ｄ，Ｆ）では、装置の停止は、結線の切断と区別できないが、対処処理も同じなので特に問題はない。

すなわち、図２２（ｂ），（ｃ）に示すように、図２１の場合と同様、伝送経路の切断を検出した装置が、その切断を検出した側に折り返しを設定し、マスタノードが、切断発生時に壊れたＴＬフレームを破棄して新たなＴＬフレームの生成と送信を続行する。そして、このことにより、マスタノードが存在する側の伝送経路には、切断発生後もＴＬフレームが伝送され、伝送経路が維持できる範囲で、波形データやイーサネットフレーム等の伝送を継続することができる。

なお、各装置は、機能が全面的に停止しない場合でも、制御回路４０がハングアップする等して、ＴＬフレームに対してデータの読み書きを正常に行えなくなる場合がある。そして、この状態でＴＬフレームの伝送を継続すると、その内容の正確さが保証できなくなるため、ある装置がこの状態に陥った場合、その装置は機能が停止したとして、図２２に示したような構成変更を行うことが好ましい。

３．ＴＬフレームに対するデータの読み書きについて
次に、ＴＬフレームに対するデータの読み書きについて説明する。
なお、ここで説明する動作及び処理は、ＲＴＬモードに関するものである。しかし、ＴＴＬモードの場合も、ＴＬフレームに対する波形データの読み書きを行わない点以外は、ＲＴＬモードの場合と全く同じ処理を採用可能である。

また、ここで説明する動作及び処理は、波形データやイーサネットフレームの読み書きを行うデータ入出力部にＴＬフレームのデータが入力される場合の処理である。波形データやイーサネットフレームの読み書きを行わないデータ入出力部にＴＬフレームのデータが入力される場合には、これらのデータの入出力に関する処理は行わない。またこの場合、マスタノードであっても、新たなＴＬフレームの生成は行わないため、スレーブノードの場合と同様な処理を行う。

また、説明の都合上、ネットワークＩ／Ｆカード２１５のデータ入出力部が備えるバッファや送受信部の符号には、第１のデータ入出力部１０における符号を用いる。しかし、第２のデータ入出力部２０を用いてデータの読み書きを行う場合に、第２のデータ入出力部２０が備える各部が動作することは、もちろんである。

３．１ ＴＬフレームの生成
まず、マスタノードにおけるＴＬフレーム１００の生成について説明する。
既に述べたように、この実施形態のオーディオネットワークシステムにおいて、新たな（フレームＩＤの異なる）ＴＬフレームを生成するのは、マスタノードのみである。そして、マスタノードは、自身が送信し、伝送経路を１周して戻ってきたＴＬフレームのデータを一部加工して、新たなＴＬフレームの生成を行う。
この加工の内容は、ヘッダや管理データ（フレームＩＤを含む）を更新すると共に、マスタノードが送信する波形データや制御データ等を書き込むものであり、他のノードが書き込んだ波形データや制御データは、そのまま新たなＴＬフレームに残るようにする。

しかし、このような生成方式を採る場合、戻ってきたＴＬフレームのエラーを確認せずに新たなＴＬフレームを生成すると、伝送される波形データに大きなノイズが発生してしまうおそれがある。そこで、この実施形態のマスタノードでは、伝送経路を１周して戻ってきたＴＬフレーム全体を一旦バッファに保存し、ＴＬフレームの全体を正常に受信できたことを確認してから、そのＴＬフレームに基づいて新たなＴＬフレームを生成するようにしている。

また、マスタノードがＴＬフレームを受信できなかった場合、新たなＴＬフレームは、別のＴＬフレームに基づいて生成しなければならない。そこで、正常に受信できた、すなわちループ状の伝送経路を正常に循環したＴＬフレームのうち最新のものを、送受信用とは別に保存しておき、ＴＬフレームが正常に受信できなかった場合には、そのＴＬフレームに基づいて生成する予定だったＴＬフレームを、保存しておいたＴＬフレームに基づいて生成するようにしている。

またこのため、マスタノードにおいては、図２３に示すように、ＴＬフレームの生成を行うデータ入出力部においては、ＴＬフレーム送信部１８に設けるＴＬフレームの加工用バッファを、複数のバッファで構成し、その各バッファに対し「送信バッファ（兼保存バッファ）」又は「受信バッファ」の機能を割り当てることができるようにしている。そして、ＴＬフレーム送信部１８内には、周期更新量ｋより１だけ多い（ｋ＋１）個のバッファが必要である。

ここで、図２４に、マスタノードにおけるＴＬフレームの送受信及び生成のタイミング例を示す。この図において、Ｓは整数であり、ワードクロックの各周期が何番目の周期であるかを示す番号である。そして、このＳは、そのＳ番目の周期にマスタノードが送信するＴＬフレームを示すフレーム番号としても使用する。

マスタノードは、図５及び図６を用いて説明したように、サンプリング周期毎に１つのＴＬフレームを送信する。また、この図に示すのは、周期更新量ｋが「２」の場合の例であり、この場合、送信したＴＬフレームの先頭は、約１サンプリング周期でシステムを循環する。そして、多くの場合、図２４に示すように、Ｓ番目のＴＬフレームの全体の受信が完了する前に、Ｓ＋１番目のＴＬフレームの送信を開始しなければならない。また、Ｓ＋２番目のＴＬフレームの送信を開始するより、マスタノード内での新ＴＬフレームの準備に係る時間である所定時間αだけ前のタイミングまでに、Ｓ番目のＴＬフレームの全体を受信する。図２４には、この所定時間αを、符号Ｘで示している。

この場合、送信バッファに格納してあるＳ番目のＴＬフレームの送信と、受信したＳ−１番目のＴＬフレームの受信バッファへの格納とを並行して行っている。フレームバッファ１６において、受信バッファは、現在の送信バッファの次のバッファとするとよい。また、マスタノードがＴＬフレームから読み取るべきデータは、受信バッファへの格納の際に読み取ってもよいし、格納してから読み取ってもよい。そして、Ｓ−１番目のＴＬフレームの受信が完了した時点で、受信したＴＬフレームのエラーチェックを行い、異常がなければその受信バッファを次の送信バッファとして指定するとともに、その指定された送信バッファ（現在の受信バッファ）の次のバッファを次の受信バッファとして指定する。そして、次の送信バッファに格納されているＳ−１番目のＴＬフレームを加工してＳ＋１番目のＴＬフレームの生成する。

さらに、間もなくＳ番目のＴＬフレームも戻ってくるので、準備されている次のバッファを受信バッファに変更して、受信したＳ番目のＴＬフレームの格納を開始する。続いて、Ｓ番目のＴＬフレームの送信が完了した時点で、送信バッファを開放する。

そして、次のワードクロックの開始タイミングで、準備されている次のバッファを送信バッファに変更するとともに、そこに格納されているＳ＋１番目のＴＬフレームの送信を開始し、その後、Ｓ番目のＴＬフレームの受信が完了した時点で、受信したＴＬフレームのエラーチェックを行い、異常がなければそのＴＬフレームを格納した受信バッファを次の送信バッファとして指定するとともに、その指定された送信バッファ（現在の受信バッファ）の次のバッファを次の受信バッファとして指定する。そして、次の送信バッファに格納されているＳ番目のＴＬフレームを加工してＳ＋２番目のＴＬフレームを生成する。

以上の手順を繰り返すことにより、常に、全体が正常であると判断できたＴＬフレームに基づいて、新たなＴＬフレームを生成することができる。
なお、１番目と２番目のＴＬフレームについては、基になるＴＬフレームがないため、所定の雛形に基づいて生成するようにするとよい。

また、フレームバッファ内でＴＬフレームを加工する代わりに、スレーブノードの場合と同様に、出力時に、バッファからＴＬフレームを読み出し、その読み出されたＴＬフレームのヘッダ及び内容を波形データ送信バッファ１６，ＴＬデータ送信バッファ１７，ＩＴＬデータ送信バッファ５３からのデータにより差し替えつつ出力するようにしてもよい。この場合、送信バッファに保存されているのが受信したままのＴＬフレームである点が異なるが、必要とされるバッファ数は同じく（ｋ＋１）個である。

また、各バッファの動作速度を倍にして、送信しながら受信できるように設計すれば、マスタノードにＴＬフレームが戻ってくるタイミングで、その時点の「送信バッファ」を同時に「受信バッファ」として使うことができるので、バッファの数を上述した実施例より１つ少ないｋ個とすることができる。

また、図２５に、Ｓ番目以降のＴＬフレームが、ループ状の伝送経路を正常に循環できていない場合の、マスタノードにおけるＴＬフレームの送受信及び生成のタイミングを示す。ここで、正常にできていない場合とは、マスタノードがＴＬフレームを受信した時点のフレームに異常が検出された場合の他、他のノードにおいて異常が検出され、その旨がフレームに記録されている場合も含む。

この場合、マスタノードが、正常に循環しなかった（データが破壊されている恐れのある）Ｓ番目のＴＬフレームに基づいてＳ＋２番目のＴＬフレームを生成すると、伝送される波形データが不連続となりノイズが発生するおそれがある。そこで、フレームが正常に循環しなかったことを検出したマスタノードは、受信バッファのＴＬフレームを破棄し、該バッファを次の受信バッファとして指定するとともに、その時点の送信バッファを次の送信バッファとして指定する。その時点で送信バッファはまだ送信中であり、新規のＴＬフレームの生成はその送信完了を待ってから行う。すなわち、Ｓ＋１番目のＴＬフレームの送信完了時、マスタノードは、次の送信バッファに格納されているＳ＋１番目のＴＬフレーム（伝送経路を正常に循環したことを確認済みの最新のＴＬフレームであるＳ−１番目のＴＬフレームのデータを含む）を加工してＳ＋２番目のＴＬフレームを生成する。

また、Ｓ＋１番目のＴＬフレームも正常に受信できなかった場合は、Ｓ＋３番目のＴＬフレームを生成する際にも、送信バッファを再度次の送信バッファとして指定し、Ｓ＋２番目のＴＬフレームの送信が完了後、格納されているＳ＋２番目のＴＬフレームに基づいてＳ＋３番目のＴＬフレームを生成する。以後も、ＴＬフレームが正常に受信できるまでは、同じバッファを送信バッファとして繰り返し使用し、その送信バッファに格納されているＴＬフレーム（Ｓ−１番目のＴＬフレームのデータを含む）に基づいて新たなＴＬフレームの生成を行うことを続ける。

このようにしても、Ｓ−１番目のＴＬフレームに記載されていたデータのうち、マスタノードが上書きせずにそのまま次のノードに送信するデータは、Ｓ＋２番目のＴＬフレームにも、Ｓ＋３番目のＴＬフレームにも、その後のＴＬフレームにも、変わらずに残る。従って、Ｓ−１番目のＴＬフレームのデータを別途保存しておき、毎回その保存しておいたＴＬフレームに基づいて新たなＴＬフレームを生成する場合と同じ結果が得られる。

次に、マスタノードにおいて図２４及び図２５に示した動作を実現するための処理について説明する。
まず、図２６に、マスタノードがＳ番目のＴＬフレームの受信開始を検出した場合に実行する処理のフローチャートを示す。
マスタノードにおける制御部４０のＣＰＵは、Ｓ番目のＴＬフレームの受信開始を検出した場合、図２６に示す処理を開始する。そしてまず、受信したフレームに管理データとして記載されているリングＩＤ及びフレームＩＤを確認し（Ｓ１２１）、正しい値か否か判断する（Ｓ１２２）。フレームＩＤは、前のＴＬフレームと連続番号になっていれば正しい値である。リングＩＤは、フレームを受信した受信Ｉ／Ｆが属する伝送経路のＩＤであれば、正しい値である。

そして、フレームＩＤ及びリングＩＤが正しい値であれば、特に問題ないので図２６の処理を終了してＴＬフレームの受信とバッファへの蓄積を継続する。しかし、これらの値に異常がある場合、フレームが欠落していたり、伝送経路の形状が変化していたりすることが考えられる。そこで、エラー処理（Ｓ１２３）において、フレームにエラーがあったことを記憶しておき、次の図２７のステップＳ１３２において、エラーありと判断させるようにする。

次に、図２７に、マスタノードがＳ番目のＴＬフレームの受信完了を検出した場合に実行する処理のフローチャートを示す。
マスタノードにおける制御部４０のＣＰＵは、Ｓ番目のＴＬフレームの受信完了を検出した場合、図２７に示す処理を開始する。そしてまず、ＦＣＳ１０５により、受信完了したＴＬフレームのエラー有無を検出する（Ｓ１３１）。そして、エラーがなく、かつ受信したＴＬフレームに記載されているエラーフラグＥＤＦの値がエラー無しを示す「０」である場合（Ｓ１３２）、受信したＴＬフレームは伝送経路を正常に循環したと判断し、受信したＳ番目のＴＬフレームに基づいてＳ＋２番目のＴＬフレームを生成することを決定する（Ｓ１３３）。なお、新たなＴＬフレーム生成のベースとするＴＬフレームのことを、「対象フレーム」と呼ぶことにする。

その後、対象フレームに対し、新たなフレームＩＤを書き込んで新たなＴＬフレームとする（Ｓ１３４）と共に、波形データ，イーサネットフレーム，ＩＴＬフレーム，およびその他の情報の読み取り及び書き込みの処理を行い（Ｓ１３５〜Ｓ１３８）、Ｓ＋２番目のＴＬフレームに、出力すべきデータが書き込まれた状態にする。
どのようなデータをフレームから読み出し、また書き込むかは、図８を用いて説明した通りである。また、ステップＳ１３５〜Ｓ１３８の処理は、順不同であり、読み取りのみ先に全て行ってから、書き込みを行うという処理順でもよい。
なお、ＩＴＬフレームについては、書き込むべきデータがない場合でも、その旨を示すデータをＩＴＬフレーム領域１０６に書き込む。このデータは、例えばブロック数「１」、ブロック番号「１」、データサイズ「０」のブロックのデータとして記載することができる。この点は、他のステップのＩＴＬフレーム書込処理でも同様である。

そして、ステップＳ１３８の後、対象フレームにＦＣＳを付与してＴＬフレームとして完成させ（Ｓ１３９）、Ｓ＋２番目のワードクロックのタイミングまで待機して（Ｓ１４０）、ワードクロックのタイミングに合わせて、生成したＳ＋２番目のＴＬフレームの送信を開始する（Ｓ１４１）。

一方、ステップＳ１３２で、エラーあり、又はエラーフラグＥＤＦの値がエラーありを示す「１」であった場合には、受信したＴＬフレームは伝送経路を正常に循環していないと判断し、伝送経路を正常に循環したことを確認済みの最新のＴＬフレームに基づいてＳ＋２番目のＴＬフレームを生成することを決定する（Ｓ１４２）。この場合にも、新たなＴＬフレーム生成のベースとするＴＬフレームのことを、「対象フレーム」と呼ぶことにする。

その後、対象フレームに対し、フリートークンを書き込む（Ｓ１４３）。このフリートークンは、ＴＬフレーム１００のイーサネットフレーム領域１０６が現在使用されておらず、イーサネットフレームの送信を希望するノードがイーサネットフレーム領域１０６にデータを書き込んでもよいことを示すデータである。そして、このフリートークンは、本実施形態では送信元ＩＤの値（例えば「０」）として書き込むようにしている。

なお、ステップＳ１４３でフリートークンの書き込みを行うのは、イーサネットフレーム領域１０６については、対象フレームに記載されている、既に過去に送信したデータを同じデータを再度送信しても意味がないので、領域を解放するためである。なお、その後、マスタノード自身がイーサネットフレーム領域１０６に送信すべきイーサネットフレームのデータを書き込む場合はある。

また、ＣＰＵはその後、ステップＳ１３２でＮＯとなったことに伴うエラー処理を行う（Ｓ１４４）。この処理は、後で図２９を用いて説明するスレーブノードにおける処理と同様、受信したＴＬフレームに記載されているデータが信頼できないことに伴う処理である。また、上位層にエラーを通知する等の処理を行ってもよい。

そして、ステップＳ１４４の後は、対象フレームに対し、新たなフレームＩＤを書き込んで新たなＴＬフレームとする（Ｓ１４５）と共に、波形データ，イーサネットフレーム，ＩＴＬフレーム，およびその他の情報の書き込みの処理を行い（Ｓ１４６〜Ｓ１４９）、Ｓ＋２番目のＴＬフレームに、出力すべきデータが書き込まれた状態にする。ステップＳ１４６〜Ｓ１４９の処理が順不同であることはステップＳ１３５〜Ｓ１３８の場合と同様であるが、ここでは、対象フレームからデータを読み出す必要はない。
ステップＳ１４９の後は、ステップＳ１３９に進み、生成した新たなＴＬフレームを、エラーなしの場合と同様に送信開始して処理を終了する。

以上の処理を行うことにより、マスタノードは、伝送経路を正常に循環して戻ってきたことが確認できているＴＬフレームに基づいて新たなＴＬフレームを生成することができるため、常に正しいＴＬフレームを生成することができる。
なお、エラーフラグＥＤＦの値が「１」であっても、受信したＴＬフレーム自体にエラーがない場合には、直前のノードが書き込んだデータは信用できるため、受信したＴＬフレームのデータのうち、ＩＴＬフレーム領域のデータのみは読み出して処理に利用するようにするとよい。

また、図２４〜図２７を用いて以上に説明した動作は、周期更新量ｋが「２」の場合のものであったが、周期更新量ｋが２より大きい値である場合には、「Ｓ番目のＴＬフレームを基にしてＳ＋ｋ番目のＴＬフレームを生成する」ことを正常時の基本動作として、周期更新量ｋが「２」の場合と同様の動作を行う。

すなわち、図２４のタイミング図に相当する動作では、Ｓ番目のＴＬフレームを正常に受信完了すると、マスタノードは、そのＴＬフレームに基づいてＳ＋ｋ番目のＴＬフレームを生成し、Ｓ＋ｋ番目のワードクロックのタイミングで送信開始する。図２５に相当する動作では、Ｓ番目のＴＬフレームが正常に受信できなかったとき、マスタノードは、Ｓ＋ｋ−１番目のＴＬフレームの送信完了を待って、そのＴＬフレームに含まれている「最後に正常受信されたＴＬフレームのデータ」に基づいてＳ＋ｋ番目のＴＬフレームを生成し、Ｓ＋ｋ番目のワードクロックのタイミングで送信開始する。

周期更新量ｋを大きくすることにより、オーディオネットワークシステムにおけるＴＬフレーム循環の上限時間を大きくすることができ、その分だけノード間の距離を長くしたり、システムに組み入れるノード数を増やしたりすることができる。しかしながら、周期更新量ｋを大きくした分だけ、オーディオネットワークにおける音響信号の伝達遅延が大きくなるというトレードオフがある。

３．３ スレーブノードにおけるデータの利用
図６及び図８等を用いて説明したように、オーディオネットワークシステム中で音声伝送モードで動作中の各ノードにおいては、ＴＬフレームから自機が使用するデータを読み出し、他の装置に送信すべきデータをＴＬフレームに書き込む。
次に、スレーブノードにおけるＴＬフレームの送受信に関する処理について説明する。
まず、図２８に、スレーブノードがＳ番目のＴＬフレームの受信開始を検出した場合に実行する処理のフローチャートを示す。

スレーブノードにおける制御部４０のＣＰＵは、Ｓ番目のＴＬフレームの受信開始を検出した場合、図２８に示す処理を開始する。そしてまず、受信中のＴＬフレームに管理データとして記載されているリングＩＤ及びフレームＩＤを確認し（Ｓ１６１）、正しい値か否か判断する（Ｓ１６２）。この判断は、マスタノードにおける図２６のステップＳ１２１，Ｓ１２２と同様なものであり、正しくない場合には、エラー処理（Ｓ１７１）として、受信したＴＬフレームをそのままスルーさせる。この場合、伝送経路上の以降のノードも同様にＴＬフレームをスルーさせ、マスタノードまで戻すことになる。また、ＦＣＳエラーの場合と同様、エラーフラグＥＤＦを「１」にセットするようにしてもよい。

一方、ステップＳ１６２で問題なければ、受信したＴＬフレームに対し、波形データ，イーサネットフレーム，ＩＴＬフレーム，およびその他の情報の読み取り及び書き込みの処理を行う（Ｓ１６３〜Ｓ１６６）。
なお、図８の説明で述べた通り、スレーブノードは、ＴＬフレームの受信完了を待たずに、受信したＴＬフレームに対するデータの読み書きを行い、次のノードへの送信も開始する。従って、これらの処理は、フレームの受信進行に応じて適当なタイミングで順次行うものであり、必ずしもフローチャートの記載順に従うとは限らない。また、どのようなデータをフレームから読み出し、また書き込むかは、図８を用いて説明した通りである。さらに、次のノードへの送信開始も、フレームの所定量のデータが蓄積されたタイミングで、図２８の処理とは独立に開始及び進行させる。

このため、スレーブノードにおいては、ＴＬフレームに対してデータを読み書きする時点では、そのフレームにおけるエラー有無を把握できないが、この点については、後述の図２９，図３１及び図３２に示す処理により対処する。
また、ステップＳ１６６の後、ＴＬフレームのＦＣＳを受信できると、そのＦＣＳにより、受信中のＴＬフレームのエラー有無を検出する（Ｓ１６７）。そして、エラーがあった場合には（Ｓ１６８）、受信中のＴＬフレームのエラーフラグＥＤＦを、エラーありを示す「１」をセットする（Ｓ１６９）。ここでエラーがあった場合、受信したＴＬフレームに記載されていたデータは正確性が保証できないことがわかる。ただし、自身がＴＬフレームに書き込んで出力したデータは、元のデータに上書きしているため、正確性が保証できる。

また、ステップＳ１６７でエラーなしの場合には、エラーフラグＥＤＦの値は変更せず、「１」がセットされていてもそのままとする。エラーフラグＥＤＦは、ＴＬフレームの循環中に１度でもエラーが発生したか否かを示すフラグだからである。
そしていずれの場合も、最後に、受信したＴＬフレームに正しいＦＣＳを付与して（Ｓ１７０）、処理を終了する。このＦＣＳを付与することにより、送信先のノードでは、このノードが出力したフレームはエラーなしと認識することになる。エラーフラグＥＤＦの値が「１」であれば、マスタノードから自ノードまでの間のどこかでエラーが生じたことは認識できる。

以上の処理を実行することにより、スレーブノードは、受信したＴＬフレームを次のノードに送信するまでに、そのＴＬフレームに対して必要なデータの読み書きを行うことができる。

次に、図２９に、スレーブノードがＳ番目のＴＬフレームの受信完了を検出した場合に実行する処理のフローチャートを示す。
この処理は、受信したＴＬフレームのエラーチェック結果に応じて、そのＴＬフレームから読み出したデータの採否を決定する処理である。そして、スレーブノードにおける制御部４０のＣＰＵは、Ｓ番目のＴＬフレームの受信開始を検出した場合、図２９に示す処理を開始する。

そしてまず、ＦＣＳエラーあり又はエラーフラグＥＤＦの値が「１」であった場合には（Ｓ１８１）、Ｓ番目のＴＬフレームから読み出した波形データは正確性が保証できないことがわかる。このため、そのデータを破棄し、前の周期の波形データをホールドして、読み出した波形データの代わりに第Ｓ周期のデータとする（Ｓ１８２）。図示は省略したが、ステップＳ１８１でＹＥＳの場合、ステップＳ１６６で読み出したその他の情報についても、破棄するようにするとよい。

また、ＦＣＳエラーありであった場合には（Ｓ１８３）、Ｓ番目のＴＬフレームのＩＴＬフレーム領域１０７から読み出したデータは正確性が保証できないことがわかる。このため、そのデータを含むＩＴＬフレームを廃棄する（Ｓ１８４）。ＩＴＬフレームを複数のブロックに分割してＩＴＬフレーム領域１０７に記載している場合、１つのブロックでも正確性が保証できないものがあると、ＩＴＬフレーム全体の正確性が保証できないためである。
以上で図２９の処理を終了する。

以上の処理を実行することにより、スレーブノードは、受信したＴＬフレームのエラー有無を確認するまえにそのＴＬフレームに対してデータを読み書きしてしまっても、事後的にエラーデータを後段の処理から排除することができる。
なお、図２９には、イーサネットフレーム領域のデータを排除する処理はないが、この処理については、次項で述べる。

また、ＦＣＳエラーがなければ、エラーフラグＥＤＦの値が「１」であっても、ＩＴＬフレーム領域１０７のデータは正確性が保証できる。ＩＴＬフレーム領域１０７に自ノードが読み取るべき書かれている場合、そのデータを書き込んだのは直前のノードであり、そのノードから自ノードまでの間に伝送エラーが発生していないことは、ＦＣＳによって保証されるためである。

また、図２８に示した処理の変形としてステップＳ１７０でＦＣＳの付与をしないようにすることも考えられる。この場合、一旦エラーの生じたＴＬフレームは、そのエラーを有したまま伝送経路を循環してマスタノードに戻ることになる。このため、エラーフラグＥＤＦによってエラーの発生を先のノードに伝えることは必要なくなるが、一旦エラーの生じたフレームは、ＩＴＬフレーム領域１０７も含めた全てのデータについて正確性が保証できなくなる。

３．４ イーサネットフレームデータの送受信
既に述べたように、オーディオネットワークシステム１においては、イーサネットフレームを、ＴＬフレームに記載して任意のノード間で送受信できるようにしている。しかし、イーサネットフレームは、波形データと異なり、各ノードにおいて非同期に、随時送信の要求が生じるものである。このため、イーサネットフレームについては、波形データの場合とは異なる送受信制御の機能を設けている。

次に、この点について説明する。なお、以下に説明する処理及び動作は、マスタノードとスレーブノードに共通のものである。
まず、音響信号処理装置２において、送信するイーサネットフレームを生成し、また受信したイーサネットフレームを受け取るのは、ネットワークＩ／Ｆカード２１５のＭＡＣ処理部１４である。そして、制御部４０を始めとするネットワークＩ／Ｆカード２１５の各部は、その送受信を仲介するという位置づけになる。

ここで、イーサネットフレームの送受信は、送信側ではネットワーク内の全ての装置にフレームを送信し、受信側で、自装置宛でないイーサネットフレームを受信した場合には読み捨てる、という処理を行うことになるので、本実施形態の送受信制御もこれに沿ったものとしている。ただし、自装置宛でないフレームを読み捨てるのは、ＭＡＣ処理部１４が行う処理であり、ネットワークＩ／Ｆカード２１５の制御部４０は、適切に送信されてきた全てのＭＡＣ処理部１４に渡す。

すなわち、制御部４０が行うのはイーサネットの物理層（ＰＨＹ）に相当する処理であり、この項でいう「上位層」は、ＭＡＣ層の処理を行うＭＡＣ処理部１４を指す。本体側のＣＰＵ２０１は、さらに上位の層ということになる。
従って、ＭＡＣ処理部１４自体も、ＣＰＵ２０１からのデータ（ＩＰパケット等）送信要求に応じてそのデータを送信するためのイーサネットフレームを生成したり、自ノード宛のイーサネットフレームから必要なデータを取り出してＣＰＵ２０１に渡したりする処理を行う。

ここで、以上のようなイーサネットフレームの送受信を行うために制御部４０のＣＰＵが実行する処理について説明する。
まず、図３０に、制御部４０のＣＰＵが上位層から送信すべきイーサネットフレームを受け取った場合に実行する処理のフローチャートを示す。
制御部４０のＣＰＵは、上位層である本体側のＣＰＵ２０１から送信すべきイーサネットフレームを受け取ると、図３０に示す処理を開始する。そしてまず、受け取ったイーサネットフレームのデータをＴＬデータ送信バッファ１７に書き込む（Ｓ１９１）。

その後、書き込んだバッファに最大フレームサイズ分の空き領域が残っていない場合には（Ｓ１９２）、これ以上イーサネットフレームを受け取ってしまうと適切に処理できないため、上位層に転送中断を指示して（Ｓ１９３）処理を終了する。空き領域があった場合には、そのまま処理を終了する。
以上の処理により、制御部４０のＣＰＵは、上位層から受け取ったイーサネットフレームを、送信待機状態にすることができる。なお、上位層に指示した転送中断は、ＴＬデータ送信バッファ１７の容量が十分確保できた時点で、適宜解除する。

次に、図３１に、制御部４０のＣＰＵがＴＬフレームのイーサネットフレーム領域のデータを読み込んだ場合に実行する処理のフローチャートを示す。なお、ここではこの処理を制御部４０のＣＰＵが実行するとして説明するが、ＴＬフレーム受信部１１やＴＬフレーム送信部１８のハードウェアに一部を分担させてもよい。
制御部４０のＣＰＵは、図２７のステップＳ１３６又は図２８のステップＳ１６４の処理においてＴＬフレーム１００のイーサネットフレーム領域１０６のデータを読み出した場合、図３１に示す処理を開始する。

そして、まず読み込んだデータに、送信元ＩＤとして何が記載されているかを判別する（Ｓ２０１）。まずは、フリートークン，自ノードＩＤ，その他の区別ができればよい。
このうちフリートークンは、上述のように、ＴＬフレーム１００のイーサネットフレーム領域１０６が現在使用されておらず、イーサネットフレームの送信を希望するノードがイーサネットフレーム領域１０６にデータを書き込んでもよいことを示すデータである。そして、このフリートークンは、本実施形態では送信元ＩＤの特定の値（例えば「０」）として書き込むようにしている。その他は、通常は他ノードのＩＤであるが、データの記載されていたＴＬフレームが破損していた場合には、全く意味のないデータとなっている場合もある。

そして、ステップＳ２０１でフリートークンであった場合、取り込んだデータはイーサネットフレームのデータではないため、取り込んだデータを廃棄する（Ｓ２０２）。また、自ノードにイーサネットフレームの送信権が渡されたことがわかるため、イーサネットフレームの送信に関するステップＳ２０３以下の処理に進む。

この処理においては、ＴＬデータ送信バッファ１７に送信すべきデータがあれば（Ｓ２０３）、自ノードを通過中のＴＬフレーム１００のイーサネットフレーム領域１０６に対して送信すべきデータの書き込みを行う。また、イーサネットフレームの送信は、図２，図３を用いて説明した通り、フレームをブロックに分割して行い、１つのＴＬフレームに対しては１ブロック分のデータを書き込む。

より具体的には、イーサネットフレームを送信中（一部のブロックのみ送信した状態）であれば（Ｓ２０４）、送信中のフレームの次のブロックのデータを準備して（Ｓ２０５）、そのブロックのデータをイーサネットフレーム領域１０６に書き込む（Ｓ２０６）。なお、ブロックの準備とは、イーサネットフレームのデータのうち１ブロック分を切り取り、図３（ｂ）に示したようにブロック数，ブロック番号等のデータを付して、イーサネットフレーム領域１０６に書き込む形式のデータを作成することを指す。

ステップＳ２０４で送信中でなければ（新しいイーサネットフレームの送信をこれから開始する状態であれば）、送信するフレームとその送信に要するブロック数を特定し（Ｓ２０７）、送信するフレームの第１ブロックを準備して（Ｓ２０８）、そのブロックのデータをイーサネットフレーム領域１０６に書き込む（Ｓ２０６）。
いずれの場合も、ステップＳ２０６の後、処理を終了する。

また、ステップＳ２０１で自ノードＩＤであった場合、取り込んだデータは、伝送経路を１周して戻ってきた、自ノードが前回書き込んで送信したデータであると考えられる。そこで、データのブロック番号や内容を参照し、このことが確認できた場合（Ｓ２０９）、取り込んだデータは他ノードから送信されてきたイーサネットフレームのデータではないため、取り込んだデータを廃棄する（Ｓ２１０）。またここでは、前回イーサネットフレーム領域１０６に書き込みを行ったノードは、イーサネットフレーム１つ分のデータの送信を完了するまで送信権を維持できるようにしているため、この場合も、イーサネットフレームの送信に関するステップＳ２１１以下の処理に進む。

この処理においては、送信中のイーサネットフレームにまだ送信していないブロックがあれば（Ｓ２１１）、送信中のフレームの次のブロックのデータを準備して（Ｓ２１２）、そのブロックのデータを、自ノードを通過中のＴＬフレーム１００のイーサネットフレーム領域１０６に書き込み（Ｓ２１３）、処理を終了する。
また、全ブロックの送信が完了していれば、フリートークンをそのイーサネットフレーム領域１０６に書き込んで（Ｓ２１４）、送信権を他の装置に渡すと共に、上位層にフレームの送信完了を通知して（Ｓ２１５）、処理を終了する。

また、ステップＳ２０９でＮＯであった場合、イーサネットフレームの送信にエラーが生じたことが考えられる。そこで、エラー処理（Ｓ２１６）を行う。この処理としては、例えば、現在送信中のイーサネットフレームの送信を中止し、エラーの発生を上位層及びシステム内の全ノードに通知することが考えられる。この通知は、ＴＬフレーム１００のイーサネットフレーム領域１０６に、所定フォーマットの無効データを書き込んで送信することにより、行うことができる。
なお、エラーが発生した場合のイーサネットフレームの再送信は、ネットワークＩ／Ｆカード２１５の側で自動的には行わず、必要であれば上位層からネットワークＩ／Ｆカード２１５に要求する。

また、ステップＳ２０１でその他であった場合、処理は図３２のステップＳ２１７に進む。この場合、取り込んだデータは、他ノードから送信されてきたイーサネットフレームのデータであると考えられるため、イーサネットフレームの受信に関する処理を行う。
そしてまず、取り込んだデータのブロック欠落有無を確認する（Ｓ２１７）。この処理は、送信元毎に、ブロックを番号順に受け取っていることを確認するものである。複数の送信元からのデータを交互に受け取ったとしても送信元毎に見たときに番号順になっていればよい。

そして、ブロックの欠落がなければ（Ｓ２１８）、取り込んだブロックのフレームデータをＴＬデータ受信バッファ１３に書き込む（Ｓ２１９）。この時に書き込むのは、読み込んだイーサネットフレーム領域１０６のデータのうち、連結するとイーサネットフレームになるフレームデータの部分のみでよく、ブロック数やブロック番号等のデータは、欠落確認のために記憶しておけば、ＴＬデータ受信バッファ１３に書き込む必要はない。末尾に空き領域がある場合も、その部分のデータは蓄積不要である。なお、複数の送信元からのデータが混在する場合、データは送信元毎に分けて記憶させるものとする。

そして、ステップＳ２１９の書き込みにより、ＴＬデータ受信バッファ１３に１つのイーサネットフレームについて全ブロックのデータが揃った場合には（Ｓ２２０）、蓄積した各ブロックのデータを連結して得られるイーサネットフレームのデータを上位層に出力し（Ｓ２２１）、処理を終了する（図３１参照）。揃っていない場合には、そのまま処理を終了する。

また、ステップＳ２１８で欠落があった場合には、データの送信に不具合があったとみなし、それまでにＴＬデータ受信バッファに蓄積したデータをクリアする（Ｓ２２２）。このとき、データの送信元が特定できるのであれば、その送信元からのデータのみクリアするようにしてもよい。また、取り込んだデータが、図３１のステップＳ２１６で書き込まれた無効データであったり、取り込んだデータにつき、ノードＩＤがシステム内のノードのものでなかったり、データが全く意味不明なものであったりした場合にも、ステップＳ２１８でＮＯとし、そのデータをクリアする。

また、ステップＳ２２２の後、スレーブノードはそのまま処理を終了するが、マスタノードにおいては、エラー処理を行い（Ｓ２２３）、通信の状況を確認する。この処理は、例えば、テストデータをイーサネットフレーム領域１０６に書き込んで送信し、これが正常に戻ってくることを確認するものである。そして、正常に戻ってきた場合には、エラーは一時的なものであったと認識し、イーサネットフレーム領域１０６にフリートークンを書き込んで、再度イーサネットフレーム領域１０６の利用が可能な状態にする。

オーディオネットワークシステム１においては、各装置が以上の処理を実行することにより、イーサネットフレームの送信権を各装置間で適切に調停し、ＴＬフレーム１００のイーサネットフレーム領域１０６を用いたノード間のイーサネットフレーム送受信を行うことができる。

なお、図２１，２２を用いて説明した接続の切断等の理由により、イーサネットフレーム領域１０６にデータを書き込んだノードがシステムから除外されてしまうことも考えられる。そしてこの場合、図３１のステップＳ２０１で、システム内に送信元ＩＤが自ノードＩＤであると判断するノードがいないため、どのノードもイーサネットフレーム領域１０６の書き換えをしない状態になってしまう。

このような事態に対処するため、例えばマスタノードが、送信元ＩＤをトポロジーテーブルの内容と照合し、送信元ＩＤがシステム内のノードのＭＡＣアドレスでない場合、イーサネットフレーム領域１０６のデータを廃棄してフリートークンを書き込んでしまうようにしてもよい。このようにすれば、イーサネットフレーム領域１０６にデータを書き込んだノードがシステムから除外された場合に、速やかにイーサネットフレーム領域１０６を解放することができる。
ステップＳ２２３のエラー処理によってもイーサネットフレーム領域１０６の解放は可能であるが、この場合、同じデータを２度読み出したことを確認した上でテストデータの送受信確認を行うため、トポロジーテーブルを確認する場合に比べ、開放に時間がかかる。

また、図３１の例では、各ノードは、一旦データの送信を開始すると、１フレーム分のデータの送信が完了するまで送信権を維持できるようにしていた。しかし、他の調停アルゴリズムを採用することも考えられる。例えば、１ブロック送信する毎にフリートークンを書き込んで次のノードに送信権を委譲したり、逆に、複数フレームであっても必要なデータを全て送信するまで送信権を維持できる等である。もちろん、その他にも種々のアルゴリズムが考えられる。

また、イーサネットフレーム領域を複数に分割し、領域毎に独立にフリートークンを用意して送信権を調停できるようにしてもよい。この場合、図３１のステップＳ２１５における送信完了の通知は、全ての領域についてデータの送信完了が確認できた場合に行う。
また、受信してＴＬデータ受信バッファ１３に書き込んだデータについて、所定時間内に全ブロックのデータが揃わなかった場合、通信エラーとみなして、それまでに受信したデータをクリアするようにしてもよい。

４．変形例
以上で実施形態の説明を終了するが、装置の構成、データの構成、具体的な処理内容等が上述の実施形態で説明したものに限られないことはもちろんである。
例えば、１サンプリング周期に１つのＴＬフレームを循環させることは必須ではなく、１サンプリング周期に複数のＴＬフレームを循環させたり、複数サンプリング周期につき１つのＴＬフレームを循環させ、そこに複数サンプリング周期分の波形データを記載することも考えられる。

また、１サンプリング周期に複数のＴＬフレームを循環させる場合において、フリートークンを用いたイーサネットフレーム領域への書き込み／読み出し制御は、サンプリング周期内の各ＴＬフレームについて独立に行うようにするとよい。この場合、例えば、あるサンプリング周期の１番目のＴＬフレームと、２番目のＴＬフレームには、別々のノードがイーサネットフレーム領域への書き込みを行えることになる。

また、上述の実施形態では、マスタノードとスレーブノードとで機能が異なるように説明を行なったが、どの装置がマスタノードになるかは、実際にオーディオネットワークシステムを形成するまでは、装置自身には認識できない。そこで、各装置は、マスタノードとスレーブの両方として機能できるように構成しておき、ＴＴＬモード移行時に自身が臨時マスタになると決定したり、ＯＭコマンドによりＲＴＬモードのマスタになる指定を受けたりしたか否かに応じて適切な機能を有効にするようにするとよい。ただし、マスタノードの機能を設けない装置もシステムに組み入れ可能とし、その装置は自動的には（暫定も含めて）マスタにならず、かつマスタとして指定できないようにしてもよい。このとき、これを理由にマスタが決定できない場合には、ＩＴＬモードからＴＴＬモードに移行できないようにすればよい。

また、ＴＬフレームの構成について、波形データと制御データの領域の比率を変更してもよいことは、もちろんである。いずれかの領域のサイズを０にしてもよい。
それ以外にも、上述の実施形態では、周期更新量ｋを可変値としていたが、固定値であってもよい。その場合、その周期更新量ｋに対応する上限時間も固定値となり、システムに追加できるノードの数はその上限時間により制限される。
ＴＬフレームを含む各種フレームはＩＥＥＥ８０２．３の形式に限らず、他の任意の形式であってよい。

上述の実施形態では、サンプリング周波数は９６ｋＨｚであったが、８８．２ｋＨｚ、１９２ｋＨｚ等任意の周波数で設計することができる。また、サンプリング周波数を切り換えられるようにしてもよい。
また、これらの変形及び実施形態の説明において述べた変形は、矛盾しない範囲で任意に組み合わせて適用可能である。また逆に、ネットワークシステム及び音響信号処理装置が実施形態の説明において述べた特徴を全て有している必要もない。

以上の説明から明らかなように、この発明のネットワークシステムによれば、マスタノードが生成する、複数の音響信号の記憶領域を備えた音声伝送フレームを各装置間に形成されるループ状の伝送経路に沿って一定周期で循環させるネットワークシステムを構成する際に、何らかの理由でマスタノードから切り離されてしまった装置群があった場合でも、その装置群の間で、ループ状の伝送経路に沿って一定周期で循環させるフレームを用いたデータ伝送を行えるようにすることができる。
従って、この発明を適用することにより、ネットワークシステムの利便性を向上させることができる。

この発明のネットワークシステムの実施形態であるオーディオネットワークシステムの概略を示す図である。 図１に示した伝送経路で伝送されるＴＬフレームの構成例を示す図である。 図２に示したＴＬフレーム中の波形データ領域、イーサネットフレーム領域及びＩＴＬフレーム領域のより詳細な構成を示す図である。 ＩＴＬフレームのデータ構成を示す図である。 図２に示したＴＬフレームの伝送タイミングを示す図である

オーディオネットワークシステム上でのシングルモードの音響信号の伝送時における、図２に示したＴＬフレームの伝送状況を示す図である。 図１に示したオーディオネットワークシステムを構成する各ノードとなる音響信号処理装置のハードウェア構成を示す図である。 図７に示したネットワークＩ／Ｆカードの構成をより詳細に示す図である。 ネットワークＩ／Ｆカードの制御部のＣＰＵが電源ＯＮ時及びリセット時に実行する、システムの構築に関する処理のフローチャートである。 図９に示した物理接続確認処理のフローチャートである。

トポロジーテーブルの例を示す図である。 図９に示した論理接続準備処理のフローチャートである。 リセット処理を受信した場合の処理のフローチャートである。 図９に示した論理接続確立処理のフローチャートである。 動作モード切替（ＯＭ）コマンドを受信した場合の処理のフローチャートである。

オーディオネットワークシステムの形成手順の具体例を示す図である。 図１６の続きを示す図である。 オーディオネットワークシステムの形成手順の別の例を示す図である。 その更に別の例を示す図である。 その更に別の例を示す図である。

接続切断時のシステム構成変更手順の例を示す図である。 その別の例を示す図である。 マスタノードにおいてＴＬフレームを記憶させるバッファの構成を示す図である。 マスタノードにおけるＴＬフレームの送受信及び生成のタイミング例を示す図である。 その別の例を示す図である。

マスタノードがＳ番目のＴＬフレームの受信開始を検出した場合に実行する処理のフローチャートである。 マスタノードがＳ番目のＴＬフレームの受信完了を検出した場合に実行する処理のフローチャートである。 スレーブノードがＳ番目のＴＬフレームの受信開始を検出した場合に実行する処理のフローチャートである。 スレーブノードがＳ番目のＴＬフレームの受信完了を検出した場合に実行する処理のフローチャートである。 ネットワークＩ／Ｆカードの制御部のＣＰＵが上位層から送信すべきイーサネットフレームを受け取った場合に実行する処理のフローチャートである。 同じくＴＬフレームのイーサネットフレーム領域のデータを読み込んだ場合に実行する処理のフローチャートである。 その続きのフローチャートである。

符号の説明

１…オーディオネットワークシステム、２…音響信号処理装置、１０…第１のデータ入出力部、１１，２１…ＴＬフレーム受信部、１４，２４…ＭＡＣ処理部、１５，２５…ディレイバッファ、１８，２８…ＴＬフレーム送信部、３１，３３…第１，第２の受信Ｉ／Ｆ、３２，３４…第２，第１の送信Ｉ／Ｆ、３５〜３８…セレクタ、４０…制御部、４１…ワードクロック生成部、５１，６１…ＩＴＬフレーム受信部、５４，６４…ＩＴＬフレーム送信部、７０…上位層Ｉ／Ｆ、１００…ＴＬフレーム、１１０、１２０…ＩＴＬフレーム、２１５…ネットワークＩ／Ｆカード、２２０…フレーム処理部、ＮＣ１〜ＮＣ４…ネットワーククロック、ＬＢ１，ＬＢ２…折り返しライン

Claims (5)

1. それぞれ単方向の通信を行う受信手段及び送信手段を２組備えた複数のノードを、あるノードの１組の受信手段及び送信手段を次のノードの１組の送信手段及び受信手段とそれぞれ通信ケーブルで接続することにより順次接続して形成したネットワークシステムであって、
   前記各ノードが、
   （ａ）前記複数のノードのうち１つを臨時のマスタノードと定め、その臨時のマスタノードが生成する、コマンド伝送のための初期通信フレームの記憶領域を備えた伝送フレームを各装置間に形成されるループ状の伝送経路に沿って一定周期で循環させ、各ノードで該伝送フレームへ前記初期通信フレームの書き込み及び／又は読み出しを行うことにより、接続された一連のノード間で初期通信フレームの伝送を行う臨時通信モード、及び
   （ｂ）前記複数のノードのうち１つをマスタノードと定め、そのマスタノードが生成する、複数の音響信号の記憶領域を備えた音声伝送フレームを各装置間に形成されるループ状の伝送経路に沿って一定周期で循環させ、各ノードで該音声伝送フレームへ音響信号の書き込み及び／又は読み出しを行うことにより、接続された一連のノード間で音響信号の伝送を行う音声伝送モード
   による通信を選択的に実行する通信制御手段を有し、
   当該ネットワークシステムにおいてマスタノードが設定された場合に、該マスタノードによる制御の下で、前記各ノードに前記音声伝送モードの動作を開始させ、
   当該ネットワークシステムのいずれかの箇所においてノード間の接続の切断が生じた場合に、その切断によって生じた２つのノード群のうち、前記マスタノードが存在する側のノード群の各ノードは、前記音声伝送モードの動作を維持して該各ノードにより形成されるループ状の伝送経路にそって前記音声伝送フレームの循環を継続し、前記マスタノードが存在しない側のノード群の各ノードは、自動的に前記臨時通信モードの動作に移行することを特徴とするネットワークシステム。
2. 請求項１記載のネットワークシステムであって、
   前記各ノードの通信制御手段が、前記送信手段から該送信手段と接続されている隣接装置に対して前記初期通信フレームを送信させる初期通信モードの動作も可能な手段であり、かつ、ノードの起動時又はリセット時には該初期通信モードで動作する手段であり、
   当該ネットワークシステムにおいて、
   前記音声伝送モード又は前記臨時通信モードにおいて形成されるループ状の伝送経路の端部に位置するノードは、前記初期通信モードで動作中のノードが自ノードに直接接続されていることを検出した場合にその初期通信モードで動作中のノードにアクセスしてそのノードを自ノードが属するループ状の伝送経路に組み入れ、前記臨時通信モードで動作中のノードが自ノードに直接接続されていることを検出した場合にその臨時通信モードで動作中のノードにリセット命令を送信してリセットを行わせ、そのノードの動作を前記初期通信モードに戻した上でそのノードにアクセスしてそのノードを自ノードが属するループ状の伝送経路に組み入れる動作を行うことを特徴とするネットワークシステム。
3. 請求項２に記載のネットワークシステムであって、
   前記各ノードに、前記リセット命令を受信した場合に、前記ループ状の伝送経路の形成に関する自機の機能をリセットして前記ループ状の伝送経路から離脱すると共に、該リセット命令を受信した側と反対側の隣接装置に対してリセット命令を送信するリセット伝達手段を備えることを特徴とするネットワークシステム。
4. 請求項２又は３に記載のネットワークシステムであって、
   当該ネットワークシステムにおいて、
   前記初期通信モードで動作中のノードが、同じく初期通信モードで動作中のノードが自ノードに直接接続されていることを検出した場合に、その検出したノードとネゴシエーションして、自ノードとその検出したノードのいずれかを前記臨時のマスタノードに設定し、自ノードとその検出したノードとを前記臨時通信モードに移行させて、自ノードとその検出したノードとで前記ループ状の伝送経路を形成することを特徴とするネットワークシステム。
5. 請求項２乃至４のいずれか一項に記載のネットワークシステムであって、
   前記音声伝送モード又は前記臨時通信モードにおいて形成されるループ状の伝送経路の端部に位置するノードは、自ノードと異なるループ状の伝送経路を形成し、かつ前記音声伝送モードで動作中のノードが自ノードに直接接続されていることを検出した場合、該検出したノードを自ノードが属するループ状の伝送経路に組み入れる動作を行わないことを特徴とするネットワークシステム。

Images