JPH0993250A - ネットワークおよびデータ伝送方法 - Google Patents

Abstract

(57)【要約】 【目的】電子機器間を接続する論理的パスのネットワー
ク上で、アイソクロナス転送とマルチキャスト転送を可
能とする。 【構成】ノード＃１とノード＃２、ノード＃２とノード
＃３、ノード＃３とノード＃４とは物理的なケーブルで
接続される。このケーブル上に、所定の帯域とアイソク
ロナス・チャンネル番号とを用いるアイソクロナス転送
のパスと、割り当てられたマルチキャスト・チャンネル
番号を用いるマルチキャスト転送とのパスを設定して、
このパスによりデータを転送する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のノード間が
バス上に構築された論理的なパスにより接続されるネッ
トワークおよびデータ伝送方法に関するものであり、特
に、ＭＩＤＩ（Musical Instrument Digital Interfac
e）データやオーディオデータの伝送に適用して好適な
ものである。

【０００２】

【従来の技術】最近のＡＶシステムにおいては、多くの
電子機器を関連させて接続することによりネットワーク
を構築するようにしているが、関連する電子機器間の接
続は、同軸ケーブル、シールドケーブル、あるいは平行
ライン等を用いて個別に行っている。これは、ＭＩＤＩ
においても同様であって、ＭＩＤＩにおいては楽器同士
を同軸ケーブルやシールドケーブル等により個別に接続
することにより、楽器のネットワークを構築している。

【０００３】このように、現在のＭＩＤＩ (を含む電子
音楽環境) では物理的な接続形態が機器間の経路となっ
ており、この形態ではある場所でのネットワーク構成を
別の場所で再現しようとした場合にユーザに負担を強い
ることになる。さらに、このようなネットワークにおい
ては、電子機器間を接続する接続線の数が多く、その占
有場所をかなり必要とすること、および、一度はずして
しまうと元にもどす配線作業が大変であるという欠点が
ある。そこで、電子機器間の接続線を１本とし、この接
続線上で電子機器間のデータのやり取りを行うようにし
たネットワークが種々提案されている。

【０００４】その一例のネットワークにおけるプロトコ
ル階層の概略を図３５に示す。このプロトコル階層は、
物理層１０２、リンク層１０３、トランザクション層１
０４、およびシリアル・バス・マネージャ１０１からな
っている。物理層１０２には、ノード間を接続する物理
的なインターフェースが定義されており、電気的な信号
とリンク層１０３が扱う論理シンボルとの変換が行われ
ている。変換された電気的な信号は、さまざまなシリア
ル・バス・メディア上で転送される。この場合、物理層
１０２はアービトレーションによって１ノードだけがデ
ータを転送できるように制御されている。すなわち、同
時に複数のノードからデータが転送されることはない。

【０００５】リンク層１０３は、ノードからノードへの
アドレッシング、データの検査とフレーム化を行い、ト
ランザクション層１０４に対して一方向のデータ転送サ
ービスを提供している。データの転送は受信側からのＡ
ＣＫによって確認される。また、後述するアイソクロナ
ス転送方式による転送サービスも提供している。トラン
ザクション層は、例えばIEEE 1212 ＣＳＲ（Control an
d Status Register ）アーキテクチャに基づいたノード
間のトランザクション・サービス（要求−応答のプロト
コル）を提供している。ただし、アイソクロナス・デー
タに対してはいかなるサービスも行わない。シリアル・
バス・マネージャ１０１は、各ノードの機能を表すＣＳ
Ｒを管理するエンティティであり、アイソクロナス・チ
ャンネルや帯域をローカルバス内で集中的に管理してい
る。

【０００６】なお、アイソクロナス転送では、例えば１
２５μｓｅｃの周期でサイクルが設定されており、アイ
ソクロナス・チャンネル番号を確保しているノードは、
このサイクルに一回だけ確保した帯域分のパケット化し
たデータを転送することができる。また、このアイソク
ロナス転送は、特定のノードに対してパケットを転送す
るのではなく、アイソクロナス・チャンネル番号が付さ
れたパケットが全ノード宛にブロードキャストされる。
アイソクロナス転送をサポートしているそれぞれのノー
ドは受信したすべてのアイソクロナス・パケットをリン
ク層１０３に通知する。リンク層１０３はパケットに付
されたチャンネル番号を検出して転送されたデータを取
り込むか否かを決定する。

【０００７】このように構成されるネットワークは、例
えば、IEEE P1394 高性能シリアルバス規格として提案
されているが、図１に実線で示すように物理的にはノー
ド間をケーブルで接続するだけで良く、このネットワー
クでアイソクロナス転送を行う場合、送信側はデータを
転送するためのリソースとしてチャンネル番号と帯域を
確保し、受信側は特定の送信ポートからのデータを受信
するためにチャンネル番号を指定する。これにより、送
信ポートからブロードキャストされたアイソクロナス・
パケットを特定の受信ポートが受信できるようになる。
受信すべきアイソクロナス・パケットか否かの判断は前
記したようにリンク層１０３により行われ、受信された
パケットは上位層に渡される。

【０００８】

【発明が解決しようとする課題】しかしながら、前記し
たアイソクロナス転送のように、常に伝送帯域を確保し
ておくネットワークにおいては、ＭＩＤＩメッセージの
ように離散的なデータを転送する場合には、確保した伝
送帯域が１００％常時使用されるものとは限らないため
有効に機能せず、ネットワークの使用効率を低下させる
という問題点があった。そこで、本発明は離散的なデー
タを伝送する場合にも使用効率の低下しないネットワー
クおよびデータ伝送方法を提供することを目的としてい
る。また、ネットワークの動作中に新たな電子機器の参
入、あるいは離脱が行われても、ネットワークの再初期
化や再構築を自動的に行うことのできるネットワークを
提供することを他の目的としている。

【０００９】

【課題を解決するための手段】前記目的を達成するため
に、本発明のネットワークは、複数のノードと、該複数
のノードが接続されると共に、該ノード間を接続する論
理的なパスが構築されるバスにより構成されるネットワ
ークにおいて、前記ノードの各々は、少なくとも１つの
ポートを有し、該ポートのタイプとして、アイソクロナ
ス・チャンネル番号と所定の帯域がバインドされたアイ
ソクロナス・トーカー、アイソクロナス・チャンネル番
号がバインドされたアイソクロナス・リスナー、マルチ
キャスト・チャンネル番号がバインドされたマルチキャ
スト・トーカー、およびマルチキャスト・チャンネル番
号がバインドされたマルチキャスト・リスナーのタイプ
が少なくとも用意されているようにしたものである。

【００１０】また、前記ネットワークにおいて、前記バ
スに構築された論理的なパスがリセットされた場合、ア
イソクロナス・トーカー及びマルチキャスト・トーカー
が、それぞれ獲得したリソース情報をトーカー情報報告
パケットとしてブロードキャストし、各ノードはこのト
ーカー情報報告パケット、および受信側のノード上で保
持されているパス情報に基づいて、前記論理的パスを再
構築するようにしたものであり、さらに、トランスポー
ト層が少なくとも、前記各ノードで獲得されたアイソク
ロナス・リソース情報と、該アイソクロナス・リソース
のバインド情報を管理するアイソクロナス・マネージャ
と、前記各ノードで獲得されたマルチキャスト・リソー
ス情報と、該マルチキャスト・リソース情報のバインド
情報を管理するマルチキャストマネージャと、マルチキ
ャスト転送やアイソクロナス転送を行うポート間に前記
論理的なパスを設定するサービスを上位層に対して提供
すると共に、設定されたパスの管理を行うパス情報管理
（ＰＩＭ）とを含むようにしたものである。

【００１１】また、本発明のデータ伝送方法は、複数の
ノードが接続されると共に、該ノード間を接続する論理
的なパスが構築されるバスによりデータを伝送するデー
タ伝送方法において、１転送サイクルが、アイソクロナ
ス・チャンネルを用いた所定の帯域のデータを転送する
アイソクロナス転送と、マルチキャスト・チャンネルを
用いたマルチキャスト転送からなり、離散的に発生され
るデータは、主に前記マルチキャスト転送により伝送さ
れるようにしたものである。

【００１２】本発明によれば、物理的な接続形態に依存
しない仮想的な経路 (論理的なパス) をネットワークの
内部に構築することができる。すなわち、そのネットワ
ークに接続されていれば、それぞれの機器の位置関係に
関係なく２つの機器間に経路を設定し、その経路を使っ
てデータを交換することができる。これによって接続形
態に関わらず仮想的な経路を確立することができるの
で、例えば機器の繋ぎ順を間違えることがなくデータを
転送できないというミスがなくなる。また、論理的に接
続されているため、物理的な接続を変更せずに機器間の
接続を変更することができるようになる。

【００１３】仮想的な経路のパス情報はネットワークに
接続されている各機器がそれぞれ記憶する。そして、ネ
ットワーク内の全てのパス情報を一括して別メディアに
保存すれば、再構成を行なう場合でもそれをネットワー
クにロードすることによって素早く正確に構成を再現す
ることができる。さらに、本発明はこのようなネットワ
ークにおいて、所定の帯域を確保してデータを伝送する
ことのできるアイソクロナス転送に加えて、転送データ
がある時に指定された複数のノードにデータの転送を行
えるマルチキャスト転送を行うこともできる。したがっ
て、離散的なデータか否かにかかわらず、効率的な伝送
を可能とすることができる。すなわち、リアルタイム性
を要求されるＭＩＤＩデータやオーディオデータ等を効
率よく伝送することができるようになる。

【００１４】

【発明の実施の形態】本発明のネットワーク（musical
Local Area Network：以下、ｍＬＡＮと記す）の説明を
以下の順序で行なう。 １．ｍＬＡＮの概要 １．１ 通信形態の概要 １．２ ｍＬＡＮプロトコル階層 １．３ ｍＬＡＮトランスポート層 １．４ データ転送時のアドレッシング １．４．１ パス １．４．２ ＰＩＭ（パス情報管理） ２．ｍＬＡＮトランスポート層の仕様 ２．１ ｍＬＡＮトランスポート層のサービス ２．１．１ ポート ２．２ ｍＬＡＮトランスポート層の構成 ２．３ アイソクロナス転送のサービス ２．３．１ アイソクロナス・マネージャ ２．３．２ アイソクロナス・リソースの確保とバイン
ド処理 ２．３．３ アイソクロナス・リソース・バインド処理 ２．３．４ アイソクロナス送信データ受付処理、アイ
ソクロナス送信処理 ２．３．５ アイソクロナス受信処理 ２．３．６ トーカー重複検出処理 ２．３．７ 下位層とのコミュニケーション ２．３．８ ＰＩＭとのコミュニケーション ２．３．９ バスリセット対応処理、バスリセット完了
通知受信処理 ２．３．１０ トーカー情報変更処理 ２．３．１１ ＮＩＭとのコミュニケーション ２．４ マルチキャスト転送のサービス ２．４．１ マルチキャスト・マネージャ ２．４．２ マルチキャスト・リソースの確保とバイン
ド処理 ２．４．３ トーカー情報変更処理 ２．４．４ マルチキャスト送信処理 ２．４．５ マルチキャスト・リソース・バインド処理 ２．４．６ マルチキャスト受信処理 ２．４．７ 下位層とのコミュニケーション ２．４．８ ＰＩＭとのコミュニケーション ２．４．９ ＮＩＭとのコミュニケーション ２．４．１０ バスリセット対応処理、バスリセット完
了通知受信処理 ２．５ ＰＩＭ（パス情報管理） ２．５．１ パスの設定処理 ２．５．２ パスに対するデータ送信処理 ２．５．３ パスの解放処理 ２．５．４ バスリセット対応処理、トーカー情報変更
処理 各種不成功通知処理 ２．５．５ ＮＩＭとのコミュニケーション ２．６ ＮＩＭ（ノード情報管理） ２．６．１ ポート情報問い合わせ処理 ２．６．２ トーカー情報報告パケット処理 ２．６．３ 下位層とのコミュニケーション ２．６．４ バスリセット対応処理、バスリセット完了
時処理 ２．７ ｍＬＡＮトランスポート層のファシリティ ２．７．１ パス情報テーブル ２．７．２ ノード情報テーブル ２．７．３ マルチキャスト情報テーブル ２．７．４ アイソクロナス情報テーブル ２．７．５ ポート情報エントリー ２．７．６ トーカー情報報告パケット ２．８ ｍＬＡＮサイクル・ストラクチャー ２．９ マルチキャスト転送とアイソクロナス転送との
使い分け ２．１０ プラグ・アンド・プレイ

【００１５】１．ｍＬＡＮの概要 １．１ 通信形態の概要 ｍＬＡＮの通信形態の概要を図１に示す。この図に示す
ように、ｍＬＡＮにおいては、ノード＃１とノード＃
２、ノード＃２とノード＃３、ノード＃３とノード＃４
とは物理的なケーブルにより接続されている。各ノード
には送信ポートあるいは受信ポートというアクセスポイ
ントが定義されている。このアクセスポイントは上位ア
プリケーションが直接アクセスすることができる最上位
のものである。本発明のネットワークにおいては、この
ポート間に図示するような仮想的な経路（論理的パス）
を確立し、この経路によりデータを転送できるようにし
ている。

【００１６】例えば、図１に示すように仮想的経路が設
定された場合は、ノード＃１からは送信ポート１−Ｔ１
とノード＃４の受信ポート４−Ｒ２との経路により、ノ
ード＃１からノード＃４にデータを転送することができ
る。また、ノード＃３の送信ポート３−Ｔ１は仮想的な
経路によりノード＃１の受信ポート１−Ｒ１、ノード＃
２の受信ポート２−Ｒ１、およびノード＃４の受信ポー
ト４−Ｒ１と接続されており、ノード＃３からノード＃
１、＃２、＃４にこの経路により、データを転送するこ
とができる。

【００１７】ｍＬＡＮにおいては、転送方式のひとつと
してアイソクロナス転送方式が定義されており、あらか
じめ帯域を確保して時間的な遅延が保証されたリアルタ
イム性の高いデータ転送を行なうことが可能である。し
かしアイソクロナス転送方式は連続的に帯域を使用して
いるため、MIDI メッセージのように離散的なデータを
転送する場合には有効に機能しない。そこで、ｍＬＡＮ
ではアイソクロナス転送に加え非同期マルチキャスト転
送という１対多の転送方式が新たに定義されている。ア
イソクロナス転送方式も１対多の転送を行なうことがで
き、ｍＬＡＮでは非同期転送のパケットについてもチャ
ンネルという概念を導入している。

【００１８】非同期マルチキャスト転送方式では送信元
からブロードキャストされるパケットを受信側が選択し
て受信するような”受信側主導型”の転送を行なう。こ
の方式は同じ内容のパケットを複数の送信先に転送する
場合に、パケットを１つだけ送信すればよいので帯域を
効果的に利用することができる。また、この方式ではデ
ータを受信する選択権は受信側にあるので、例えば受信
側のノード数が増えた場合でも送信側の負担は変わらな
い。このように、転送に関する処理の多くを受信側に行
なわせることによって送信側の負担を少なくし、パケッ
ト送信におけるリアルタイム性を向上することができ
る。

【００１９】１．２ ｍＬＡＮプロトコル階層 次に、本発明のｍＬＡＮのプロトコル階層の一例を図２
に示す。この図ではｍＬＡＮのプロトコル階層を、ＯＳ
Ｉ（Open System Interconnection ）参照モデルと対応
付けて示している。ｍＬＡＮのプロトコル階層は、下位
層インフラストラクチャと上位層インフラストラクチャ
に大きく分けることができる。下位層インフラストラク
チャはＯＳＩ参照モデルの第１層〜第４層、上位層イン
フラストラクチャは第５層〜第７層までに相当する。下
位層インフラストラクチャではアプリケーション間でメ
ッセージを交換するための手段が定義され、上位層イン
フラストラクチャではアプリケーション間で交換される
メッセージの内容が定義される。この下位層インフラス
トラクチャは転送経路を確立し、上位層に対して End-
to-Endの転送サービスを提供する機能を有している。

【００２０】ｍＬＡＮの上位層インフラストラクチャで
は、転送される情報についての意味づけを行ない、それ
らの情報を利用するためのアプリケーション・サービス
を定義する。この上位層はプレゼンテーション層 (ＯＳ
Ｉ第６層）２６に相当するｍＬＡＮプロトコル群１１
と、アプリケーション層 (ＯＳＩ第７層）２７に対応す
るｍＬＡＮアプリケーション１２からなる。なお、セッ
ション層 (ＯＳＩ第５層) ２５で実現される機能は、ｍ
ＬＡＮトランスポート層１０以下の階層で実現されるの
でｍＬＡＮはセッション層２５に相当する階層は有して
いない。

【００２１】ｍＬＡＮプロトコル群１１では音楽情報の
転送を効果的に行なうための付加的な制御メカニズムの
定義、各種のデータ・フォーマットや転送プロトコルの
定義を行なう。このプロトコルとしては、 MIDI プロト
コル、Digital Audio プロトコル等が用意される。ま
た、ｍＬＡＮアプリケーション１２はｍＬＡＮプロトコ
ル群１１で定義されたデータ交換方式を実際に利用する
ために構築されるアプリケーションである。

【００２２】ｍＬＡＮの下位層インフラストラクチャ
は、トランスポート層（ＯＳＩ第４層）２４に相当する
ｍＬＡＮトランスポート層１０と、ネットワーク層（Ｏ
ＳＩ第３層）２３に相当するトランザクション層３と、
データリンク層（ＯＳＩ第２層）２２に相当するリンク
層２と、物理層（ＯＳＩ第１層）２１に相当する物理層
１と、ノードコントローラ（Node Controller ）４とか
ら構成されている。ｍＬＡＮトランスポート層１０は、
ノード内にポートと呼ばれるサブアドレスが導入され
て、ポート対ポートの通信が実現されると共に、下位層
の規格の違いが吸収される。また、ｍＬＡＮ上位層に対
して下位層の形式に依存しない共通の形式のサービス・
インターフェイスを提供する。したがって、規格の異な
る下位層が複数ある場合は、ｍＬＡＮトランスポート層
１０はそれぞれの下位層に対して設けられる。

【００２３】ｍＬＡＮトランスポート層１０内部には、
ＰＩＭ (パス情報管理) ８、アイソクロナス・マネージ
ャ（Isochronous Manager ）７、マルチキャスト・マネ
ージャ（Multicast Manager ）６、トランザクション・
マネージャ（Transaction Manager ）５、およびＮＩＭ
（ノード情報管理）９が定義されている。また、物理層
１では、ノード間を接続する物理的なインターフェイス
が定義されており、電気的な信号とリンク層が扱う論理
シンボルとの変換が行なわれている。また、ｍＬＡＮで
はケーブル環境だけを使用するものとする。

【００２４】さらに、リンク層２は、ノードからノード
へのアドレッシング、データの検査とフレーム化を行な
い、トランザクション層３に対して一方向のデータ転送
サービスを提供している。データの転送は受信側からの
ACK によって確認される。また、リンク層２はアイソ
クロナス方式による転送サービスも提供している。トラ
ンザクション層３は、例えば IEEE 1212 CSR アーキテ
クチャ IEEE1212に基づいたノード間のトランザクショ
ン・サービス (要求−応答のプロトコル)を提供してい
る。また、ノードコントローラ（シリアルバス管理に相
当）４は各ノードの機能を表す CSR を管理するエンテ
ィティであり、アイソクロナス・チャンネル番号や帯域
をローカルバス内で集中的に管理している。

【００２５】１．３ ｍＬＡＮトランスポート層 ｍＬＡＮトランスポート層１０ではノード内にポートと
呼ばれるサブアドレスを定義しており、このポート間で
データを交換するための転送サービスを提供する。ま
た、ｍＬＡＮトランスポート層１０はアイソクロナス転
送、非同期パケット転送 (トランザクション) に加えて
マルチキャスト転送と呼ばれる１つの送信ポートから複
数の受信ポートへのデータ転送プロトコルが定義されて
いる。

【００２６】１．４ データ転送時のアドレッシング ポート間でマルチキャスト転送やアイソクロナス転送に
よる転送を行なう場合には、ポートに対してチャンネル
をバインドしてから転送を行なわなければならない。送
信側はデータを転送するためのリソースとしてチャンネ
ル番号を確保し、受信側は特定の送信ポートからのデー
タを受信するためにチャンネル番号を指定する。チャン
ネル番号は転送を行なう際に各送信／受信ポートに対し
てダイナミックに割り当てられる資源であり、パスの初
期化を行うバスリセットが行われた場合、その前後でポ
ートに同じチャンネル番号が割り当てられるとは限らな
い。また、受信側ノードが送信側のノードを特定する場
合にはノードＩＤが使われる。バスの初期化の際に各ノ
ードに対して一意なノードＩＤが割り当てられる。した
がって、ＳＣＳＩ（Small Computer System Interface
）ＩＤのようにユーザーが設定する必要がなくなり、
また物理層１レベルでダイナミックな割り当てを行なう
ことによってローカルバス上でのノードＩＤの一意性が
保証される。

【００２７】このようにデータ転送のアドレッシングに
用いられるノードＩＤとチャンネル番号はバスリセット
によって再割り当てが行なわれ、それがバスリセット前
後で異なる場合がある。そのため、アイソクロナス転送
やマルチキャスト転送を行なっている時にバスリセット
が発生するとアドレッシングが変更され、転送が継続で
きなくなる可能性がある。そこで、バスリセットをアプ
リケーション・ユーザーに意識させることなく、またバ
スリセットの前後でノードＩＤやチャンネル番号が変わ
った場合でも転送が継続できるように、ｍＬＡＮトラン
スポート層１０ではパスという経路情報を保存し、この
パス情報をもとに転送経路の再構成を行なうようにして
いる。

【００２８】１．４．１ パス また、アイソクロナス転送とマルチキャスト転送を行な
うポートに設定される転送経路に関する情報であるパス
は、コネクション・オリエンテッドなものではないと共
に、複数の受信ポートにデータを転送するための経路情
報である。この場合、データ転送自体はコネクションレ
スで行なわれる。パスは転送経路の受信側となるノード
上に保存され、バスリセットやパワーリセットによって
バスの初期化が行なわれた後にｍＬＡＮトランスポート
層１０によって再設定が行なわれる。設定されたパス情
報はｍＬＡＮトランスポート層内のＰＩＭ (パス情報管
理)８と呼ばれるモジュールによって管理される。

【００２９】なお、アイソクロナス転送やマルチキャス
ト転送では１ (送信側) 対多 (受信側) の転送方式を取
るため、送信側でパスの再構成を行なうものとすると送
信側が行なわなければならない作業が多くなり、データ
転送のリアルタイム性が損なわれる可能性がある。例え
ば、送信側が受信側のリストを保存していた場合、その
リストの中の受信ノードがバス上に見つからないと送信
側がその状況を解決しなければならない。また、送信側
には不特定多数の受信ノードへのパス情報を記憶する容
量を確保するのが困難なノードが存在する。例としてマ
ウス、キーボードなどの簡単な機構を持ったノードがあ
げられる。以上のような理由でパス情報は受信側ノード
上で保持されている。

【００３０】前記したようにパス情報はバスリセットに
よってノードＩＤやチャンネル番号が変更された場合に
転送経路を再構築するために保持される情報である。し
たがって、パス情報として保持される情報はバスリセッ
トによって変更されないパラメータでなければならな
い。そこでパス情報は、 ・送信側ポートのポートＩＤ ・送信側ポートがあるノードの Node Unique ID ・受信側のポートＩＤ という形で保持される。これを図示すると、図４に示す
ようなテーブルとなる。

【００３１】なお、ポートＩＤはアプリケーションによ
って決定され、Node Unique ID は工場出荷時に製品ご
とに異なるＩＤが設定されるのでバスリセットによって
変更されることはない。ｍＬＡＮトランスポート層１０
は、バスリセットによって変更されるチャンネル番号や
ノードＩＤの変化に対しては内部的に情報更新を行な
い、上位アプリケーションに対してはバスリセットによ
って変化しないリソースを提供する。これによってアプ
リケーションはバスリセットの発生に関係なく継続して
転送を行なうことができる。

【００３２】１．４．２ ＰＩＭ（パス情報管理） また、ｍＬＡＮトランスポート層１０内に定義されてい
るＰＩＭ (パス情報管理) ８は、ポート間に設定される
パスの管理を行なうモジュールであり、パスの設定／解
放、設定されたパス情報の保持などを行なう。また、Ｐ
ＩＭ８はバスの動作中におけるノードの参入／離脱や電
源再投入によって発生するバス初期化プロセス後に保持
されていたパスを自動的に再構成する機能を有してい
る。そして、ＰＩＭ８はマルチキャスト転送やアイソク
ロナス転送を行なうポート間にパスを設定するサービス
を上位アプリケーションに提供し、このサービスによっ
て設定されたパスは、図４に示すパス情報テーブルとし
てＰＩＭによって記憶される。

【００３３】また、ノードの物理的な参入／離脱によっ
てバスリセットが発生し、バスの再初期化が行なわれる
場合、この再初期化のプロセスで各ノードに対して動的
にノードＩＤが割り当てられるので、バスリセットの前
後ではノードに割り当てられるノードＩＤが変更される
可能性がある。ノードＩＤが変更されるとバスリセット
前後でノードに対するアドレッシングが変更されること
になるので正しい転送が行なえなくなる。ＰＩＭ８はこ
のようにバス構成に変更があった場合に、内部で保持し
ているパス情報テーブルを更新してバスリセット後も障
害なくデータ転送が行なわれるようにする。これによっ
て上位層はバスリセットによるバス構成の変更を意識す
る必要がなくなる。またＰＩＭ８が保持したパス情報は
電源 OFF 後も保持されるので、電源再立ち上げ時にも
パスは自動的に再設定される。

【００３４】２．ｍＬＡＮトランスポート層の仕様 ２．１ ｍＬＡＮトランスポート層のサービス ｍＬＡＮトランスポート層１０は上位層に対して３種類
の転送方式を提供する。３種類の転送方式は、マルチキ
ャスト転送、アイソクロナス転送、およびトランザクシ
ョン転送であり、それぞれの転送方式は以下のような特
徴を持っている。 Ａ．マルチキャスト転送 マルチキャスト転送は１つの送信用ポートから複数の受
信用ポートに対して行なわれる非同期パケット転送であ
る。この転送方式はｍＬＡＮトランスポート層１０で定
義されている。マルチキャスト転送はブロードキャスト
機能を利用するので ACK は返らない。したがって送信
側が転送の成否を知ることができないが、送信するパケ
ットは１つですむので帯域を効率的に使うことができ
る。

【００３５】Ｂ．アイソクロナス転送 アイソクロナス転送方式はリンク層２で定義されている
データ転送である。送信遅延が保証されており、あらか
じめ各ノードが帯域を確保してから転送を行なうのでネ
ットワーク全体の負荷は管理されている。この転送方式
は、定期的に一定量の転送要求が行なわれるデータある
いは厳密なタイミングが要求されるようなデータの転送
に適している。 Ｃ．トランザクション トランザクションはトランザクション層３で定義されて
いる１対１の双方向通信である。コネクションレスでは
あるが ACK / リトライ機能が実装されているので高品
質のデータ転送を行うことが可能である。

【００３６】２．１．１ ポート 次に、ｍＬＡＮトランスポート層１０におけるサービス
・アクセス・ポイントであるポートについて説明する。
上位層はポートに対してアクセスすることによってｍＬ
ＡＮトランスポート層１０が提供するサービスを利用す
ることができる。前述したような各種方式によるデータ
転送は特定の属性を持つポート間でのみ可能とされる。
すなわち、異なる属性を持つポートに対して転送を行な
うことはできない。また、ポートの持つ属性はバインド
されるリソースによって決まるが、ポートの属性とバイ
ンドされるリソースは以下のように分類される。

【００３７】Ａ．トランザクション・ポート（transact
ion port） トランザクションを行なうポートであり、１つのポート
で送受信が可能とされ、リソースとしてノード内のアド
レスがバインドされる。 Ｂ．アイソクロナス・トーカー（isochronous talker） アイソクロナス・データの送信を行なうポートであり、
リソースとしてアイソクロナス・チャンネル番号とアイ
ソクロナス帯域がバインドされる。 Ｃ．アイソクロナス・リスナー（isochronous listene
r） アイソクロナス・データの受信を行なうポートであり、
リソースとしてアイソクロナス・チャンネル番号がバイ
ンドされ、そのチャンネル番号で送出されたパケットを
受信することができる。 Ｄ．マルチキャスト・トーカー（multicast talker） マルチキャスト・データの送信を行なうポートであり、
リソースとしてマルチキャスト・チャンネル番号がバイ
ンドされる。 Ｅ．マルチキャスト・リスナー（multicast listener） マルチキャスト・データの受信を行なうポートであり、
リソースとしてマルチキャスト・チャンネル番号がバイ
ンドされ、そのチャンネル番号で送出されたパケットを
受信することができる。

【００３８】なお、ｍＬＡＮトランスポート層１０での
トランザクションはトランザクション層３のレベルで見
れば（ポートにバインドされた）アドレスに対するトラ
ンザクションである。この方法によれば、ｍＬＡＮトラ
ンスポート層１０で提供されているサービスを利用して
ポートにバインドされていないアドレス (例えば Confi
guration ROM 内のエントリー) に対するアクセスは行
なえないことになる。そこで、これを行なうために各ノ
ード上に内部情報を提供するためのＮＩＭ（ノード情報
管理) ９が定義されている。他のノードはこのＮＩＭ９
に対して要求を行なうことによって，ノード情報（Node
Unique ID、ノード内のポートの数、各ポートの属性な
ど）を獲得することができる。

【００３９】２．２ ｍＬＡＮトランスポート層の構成 ｍＬＡＮトランスポート層１０は前記したように以下に
挙げる５つのモジュールで構成されている。 Ａ．アイソクロナス・マネージャ７ アイソクロナス転送を行なうためのリソース (アイソク
ロナス・チャンネル番号と帯域) を獲得し、アイソクロ
ナス・トーカーにバインドする。また、各ノードで獲得
されたアイソクロナス・リソースと、そのリソースのバ
インド情報を管理する。

【００４０】Ｂ．マルチキャスト・マネージャ６ マルチキャスト転送を行なうためのチャンネルを獲得
し、マルチキャスト・トーカーにバインドする。また、
各ノードで獲得されたマルチキャスト・チャンネルと、
そのチャンネルのバインド情報を管理する。 Ｃ．トランザクション・マネージャ５ トランザクション・ポートに対するリソースの割り当て
を管理する。 Ｄ．ＰＩＭ（パス情報管理）８ アイソクロナス・ポート／マルチキャスト・ポートにパ
スを設定する機能を提供し、設定されたパスの管理を行
なう。 Ｅ．ＮＩＭ（ノード情報管理）９ ノード・コントローラ４の上位モジュールとして機能す
る。ノード・コントローラ４から通知されたバスの状態
変化にしたがって他のモジュールに対して設定変更など
の操作を行なう。

【００４１】２．３ アイソクロナス転送サービス 次に、アイソクロナス転送サービスについての説明を行
う。アイソクロナス転送を行なう送信ポートはアイソク
ロナス・トーカーと呼ばれ、受信ポートはアイソクロナ
ス・リスナーと呼ばれる。アイソクロナス転送では、例
えば、１２５μｓｅｃの周期でサイクルが設定されてお
り、アイソクロナス・チャンネル番号を確保しているノ
ードはこのサイクルの間に１回だけ確保した帯域分のデ
ータを転送することができる。

【００４２】新規に作成されたポートをアイソクロナス
・トーカーとしてアイソクロナス転送方式でのデータ送
信を行う場合は、そのポートに対してアイソクロナス・
チャンネル番号と帯域をバインドする必要がある。アイ
ソクロナス転送方式でのデータ転送は特定のノードに対
してパケットが転送されるのではなく、アイソクロナス
・チャンネル番号を付されたパケットが全ノード宛にブ
ロードキャストされる。アイソクロナス転送をサポート
しているそれぞれのノードは、受信した全てのアイソク
ロナス・パケットをリンク層２に通知する。リンク層２
はパケットに付されたチャンネル番号を見て転送された
データを取り込むかどうかを決定する。

【００４３】２．３．１ アイソクロナス・マネージャ アイソクロナス転送において、アイソクロナス・マネー
ジャ７は各ノード上にあるアイソクロナス・リソースを
管理するｍＬＡＮトランスポート層１０内部のモジュー
ルであり、アイソクロナス・マネージャ７は上位アプリ
ケーションからの要求によってアイソクロナス・リソー
ス (アイソクロナス・チャンネル番号とアイソクロナス
帯域) を獲得し、それらをアイソクロナス・トーカーに
バインドする。

【００４４】このバインドの手続きによってアイソクロ
ナス・トーカーは送信を行なうことができるようにな
る。また、アイソクロナス・リスナーに対してはアイソ
クロナス・チャンネル番号がバインドされる。チャンネ
ル番号をバインドされたアイソクロナス・リスナーはそ
のチャンネル番号で送信されるアイソクロナス・データ
を受信することができる。また、アイソクロナス・マネ
ージャ７は以上の手続きによって得たリソースを保持す
る。そしてバスリセットが発生してバスの初期化が行な
われた後、アイソクロナス・ポートに対して保持してい
たリソースの再バインドを行なう。

【００４５】２．３．２ アイソクロナス・リソースの
確保とバインド処理 次に、アイソクロナス・トーカーに対するアイソクロナ
ス・リソースの確保とバインド処理について、図１０に
示すフローチャートを参照しながら説明する。アイソク
ロナス・マネージャ７がＰＩＭ８からのアイソクロナス
・リソース・バインド要求（Isochronous Manager Bind
Resource Request ）を受け取ると、アイソクロナス・
リソースの確保とバインド処理が開始され、以下の手順
でアイソクロナス・リソースが獲得され、そのリソース
がアイソクロナス・トーカーに対してバインドされる。
まず、ステップＳ１０にてアイソクロナス・マネージャ
７はバス・マネージャに対してアイソクロナス・チャン
ネル番号と帯域の割り当て要求を行なう。これはバス・
マネージャ上の CSR に対して１対１の排他的なトラン
ザクションにより行なわれる。

【００４６】次いで、上位層からの要求通りにアイソク
ロナス・リソースを獲得できたか否かがステップＳ２０
にて判定されるが、獲得できたと判定された場合、ステ
ップＳ３０にてアイソクロナス・マネージャ７はアイソ
クロナス・トーカーに対してそれらのリソースをバイン
ドする。ただし、実際には後述するトーカー情報変更処
理においてバインド相当の処理が行なわれ、このためこ
の処理は破線で示されている。次いで、ステップＳ４０
にてアイソクロナス・トーカーが作成されたことを示す
ために、獲得したリソースの内容を添付した図９に示す
フォ−マットとされたトーカー情報報告パケットをブロ
ードキャストする。そして、ステップＳ５０にてＰＩＭ
８にリソース・バインドの成否を通知するが、この場合
はリソース・バインドが成功しているのでその旨を通知
する。

【００４７】なお、トーカー情報報告パケットは、図９
に示すように、トーカー情報報告パケットであることを
示すＩＤに続いて、トーカーのポートＩＤ、トーカーの
ノードＩＤ、トーカーのノードユニークＩＤ、トーカー
の獲得したリソース情報とから構成される。また、ステ
ップＳ２０にてアイソクロナス・リソースが獲得できな
かったと判定された場合は、ステップＳ５０にてリソー
スバインドの不成功の通知をＰＩＭ８に対して行う。以
上の処理が終了すると、リターンされて、アイソクロナ
ス・トーカーはアイソクロナス転送を行なうことができ
るようになる。

【００４８】２．３．３ アイソクロナス・リソース・
バインド処理（リスナー） ところで、アイソクロナス転送の受信を行なう場合、ア
イソクロナス・マネージャ７はアイソクロナス・リスナ
ーに対してリソースをバインドする必要がある。このア
イソクロナス・リソース・バインド処理を図１１に示す
フローチャートを参照しながら説明する。アイソクロナ
ス・マネージャ７が上位層からのアイソクロナス・リソ
ース・バインド要求を受け取ると、アイソクロナス・リ
ソースの確保とバインド処理が開始され、以下の手順で
アイソクロナス・リソースがアイソクロナス・リスナー
に対してバインドされる。

【００４９】まず、リスナー側のアイソクロナス・マネ
ージャ７はステップＳ６０にてリスナーと指定されたポ
ートに、指定されたトーカーのアイソクロナス・チャン
ネル番号をバインドする。この場合は、チャンネル番号
や帯域を新たに確保する必要はなく、単に受信チャンネ
ルの番号をリスナーにバインドするだけである。ただ
し、リスナーにバインドされるアイソクロナス・チャン
ネル番号はすでにトーカーによって確保されているチャ
ンネルの番号でなければならない。そして、ステップＳ
７０にてアイソクロナス情報テーブルに新たにエントリ
ーされたリスナー・ポートに関する情報が書き込まれ
る。このアイソクロナス情報テーブルを図７に示すが、
このテーブルには、ポートＩＤ、ポートタイプ、アイソ
クロナス・リソースが登録されている。

【００５０】次いで、ステップＳ８０にてアイソクロナ
ス・マネージャ７がアイソクロナス情報テーブルによっ
て保持している受信チャンネルリストがリンク層２に渡
される。リンク層２は、すべてのアイソクロナス・パケ
ットを受信しているが、この受信チャンネルリストにあ
るチャンネル番号のアイソクロナス・パケットを受信し
た場合のみ、アイソクロナス・マネージャ７に受信通知
を行なう。次いで、ステップＳ９０にてＰＩＭ８にリソ
ース・バインドの成否を通知するが、通常はリソース・
バインドに失敗することはないので、通常はリソース・
バインド成功の通知がＰＩＭ８に行なわれる。以上によ
り、リスナーにおけるアイソクロナス・リソース・バイ
ンド処理が終了する。

【００５１】２．３．４ アイソクロナス送信データ受
付処理、アイソクロナス送信処理 このようにして、アイソクロナス・トーカーおよびアイ
ソクロナス・リスナーにアイソクロナス・リソースがバ
インドされて、アイソクロナス転送を行えるようにな
る。アイソクロナス転送を行なう場合は、まずアイソク
ロナス送信データの受付処理が行なわれて、次にアイソ
クロナス送信処理が行なわれるようになる。そこで、ア
イソクロナス送信データ受付処理を図１２（ａ）に示す
フローチャートを、アイソクロナス送信処理を同図
（ｂ）に示すフローチャートを参照しながら説明する。

【００５２】ＰＩＭ８からアイソクロナス・マネージャ
７が、アイソクロナス・トーカーから転送されるアイソ
クロナス送信データの転送要求を受け取ると、アイソク
ロナス送信データ受付処理が開始され、ステップＳ１０
０にてアイソクロナス・マネージャ７は、まず内部に保
持している図７に示すアイソクロナス情報テーブルを参
照して、指定されたアイソクロナス・トーカーにバイン
ドされているアイソクロナス・チャンネル番号を獲得す
る。次いで、ステップＳ１１０にて転送すべき転送デー
タとアイソクロナス・チャンネル番号とを一時保存す
る。これは、アイソクロナス転送が所定サイクルの開始
通知を受けて行なわれるので、サイクルが開始されるま
で待機するためである。

【００５３】アイソクロナス送信データ受付処理が終了
し、リンク層２よりアイソクロナス・サイクルの開始が
通知されると、アイソクロナス送信処理が開始される。
この処理は、まず、ステップＳ１２０にてアイソクロナ
ス・マネージャ７が獲得されたアイソクロナス・チャン
ネル番号を使用して、リンク層２に対してアイソクロナ
ス転送要求を発行する。この場合、転送データもリンク
層２に渡されて、アイソクロナス転送データは、リンク
層２を介して物理層１から全ノードにブロードキャスト
されるようになる。

【００５４】２．３．５ アイソクロナス受信処理 このようにしてブロードキャストされたアイソクロナス
転送されたパケットの受信を行なう場合のアイソクロナ
ス受信処理を、図１３（ａ）に示すフローチャートを参
照して説明する。アイソクロナス・マネージャ７がリン
ク層２からの受信通知を受け取ると、アイソクロナス受
信処理が開始され、ステップＳ１３０にてアイソクロナ
ス・マネージャ７は内部の図７に示すアイソクロナス情
報テーブルを参照して、アイソクロナス・チャンネル番
号からアイソクロナス・パケットを渡すリスナーのポー
ト番号を取得する。そして、ステップＳ１４０にて、取
得したポートに受信通知を行ない、受信データをそのポ
ートを指定して転送する。

【００５５】２．３．６ トーカー重複検出処理 ところで、１つのアイソクロナス・チャンネル番号がバ
インドされるアイソクロナス・トーカーはただ１つであ
る。すなわち、特定のアイソクロナス・チャンネル番号
でパケットを送出しているアイソクロナス・トーカーは
ただ１つとされる。したがって、複数のアイソクロナス
・トーカーから同一のアイソクロナス・チャンネル番号
でパケットが送信されていることを、リンク層２からの
通知によりアイソクロナス・マネージャ７が検出した場
合、上位層に対する受信通知をリンク層２において中止
し、アイソクロナス・チャンネル番号が重複しているこ
とを上位層に通知する。

【００５６】この場合に行なわれるトーカー重複検出処
理のフローチャートを図１３（ｂ）に示すが、トーカー
の重複が検出された場合、ステップＳ１５０にてトーカ
ーの重複していることが、リンク層２よりの重複受信の
通知を受けて、アイソクロナス・マネージャ７はＰＩＭ
８へ通知する。この場合、重複しているトーカーに関係
のあるポート番号が指定されてＰＩＭ８に通知される。
また、ＰＩＭ８に対するアイソクロナス転送の受信通知
はリンク層２のレベルで中止される。

【００５７】２．３．７ 下位層とのコミュニケーショ
ン 以上説明したアイソクロナス転送サービスにおいて、ｍ
ＬＡＮトランスポート層１０のアイソクロナス・マネー
ジャ７はリンク層２と、次のようなサービス・プリミテ
ィブによりコミュニケーションを行なう。ｍＬＡＮトラ
ンスポート層１０は、 Link Isochronous Request のサ
ービス・プリミティブを利用してリンク層２に対してア
イソクロナス・パケットの転送を要求する。また、Link
Isochronous Indication のサービス・プリミティブ
は、リンク層２からアイソクロナス・マネージャ７に対
して発行され、アイソクロナス・パケットを受信したこ
とが通知される。

【００５８】さらに、Link Cycle Start Indication の
サービス・プリミティブはリンク層２からアイソクロナ
ス・マネージャ７に対して発行され、アイソクロナス・
サイクルが開始されたことを示す。アイソクロナス・マ
ネージャ７はこの通知を受け取ったあと、送信すべきデ
ータがあった場合に Link Isochronous Request のサー
ビス・プリミティブによってデータの転送を行なう。さ
らに、アイソクロナス・マネージャ７はLink Isochrono
us Control Requestのサービス・プリミティブを利用し
て、ノード内のアイソクロナス・リスナーにバインドさ
れている全てのアイソクロナス・チャンネル番号を Ch
annel Receive List としてリンク層２に渡す。リンク
層２はこのリストに含まれているチャンネルを持つアイ
ソクロナス・パケットを受信した場合にアイソクロナス
・マネージャ７に対して Link Isochronous Indication
を発行する。

【００５９】２．３．８ ＰＩＭとのコミュニケーショ
ン 次に、アイソクロナス・マネージャ７とＰＩＭ８とのコ
ミュニケーションについて説明する。Isochronous Mana
ger Data Request のサービス・プリミティブは、ＰＩ
Ｍ８からアイソクロナス・マネージャ７に対して発行さ
れ、アイソクロナス・マネージャ７はこれを受けて指定
されたデータの転送を行なう。Isochronous Manager Da
ta Indication のサービス・プリミティブは、アイソク
ロナス・マネージャ７からＰＩＭ８に対して発行され、
アイソクロナス・パケットを受信したことがＰＩＭ８に
対して通知される。Isochronous Manager Bind Resourc
e Request のサービス・プリミティブは、ＰＩＭ８から
アイソクロナス・マネージャ７に対して発行され、アイ
ソクロナス・マネージャ７は指定されたポートに対して
リソースのバインドを行なう。

【００６０】Isochronous Manager Bind Resource Conf
irmation のサービス・プリミティブは、アイソクロナ
ス・マネージャ７からＰＩＭ８に対して発行され、Isoc
hronous Manager Bind Resource Request によるバイン
ド要求に対する成否が返される。Isochronous Manager
Release Resource Request 、および、Isochronous Ma
nager Release Resource Confirmation のサービス・プ
リミティブは、獲得したリソースをリリースするための
ものである。

【００６１】２．３．９ バスリセット対応処理、バス
リセット完了通知受信処理 ところで、新たなノードがバスに参入された場合は、バ
スリセットを行なってすべてのパスをリセットし、次い
でノードにノードＩＤを新たにつけ替えてパスを再構築
する。この場合、バスリセット対応処理に続いてバスリ
セット完了通知受信処理が行なわれる。バスリセット対
応処理を図１５に示すフローチャートを参照して説明す
ると、バスリセットが発生するとＮＩＭ９からアイソク
ロナス・マネージャ７に対してリセット要求 (Isochron
ous Manager control request (Reset))が発行され、バ
スリセット対応処理が開始される。このリセット要求を
受け取ったアイソクロナス・マネージャ７は、ステップ
Ｓ１９０にてＰＩＭ８からのアイソクロナス転送要求を
reject する。そして、バスリセット対応処理は終了す
る。この場合、アイソクロナス情報テーブルで保持され
ているアイソクロナス・トーカーとアイソクロナス・チ
ャンネル番号は保持される。

【００６２】そして、バスリセットが完了するとＮＩＭ
９からアイソクロナス・マネージャ７に対してイニシャ
ライズ要求 (Isochronous Manager control request (I
nitialize)) が発行される。このイニシャライズ要求を
受け取ったアイソクロナス・マネージャ７は、バスリセ
ット完了通知受信処理を行なう。バスリセット完了通知
受信処理を図１６に示すフローチャートを参照しながら
説明すると、まず、アイソクロナス・マネージャ７は、
ステップＳ２００にて図７に示すアイソクロナス情報テ
ーブルから１つの Talker entry を取り出して、ステッ
プＳ２１０にてバス・マネージャにアイソクロナス・チ
ャンネル番号と帯域の割当を要求する。これはバス・マ
ネージャ上の CSR に対して１対１の排他的なトランザ
クションにより行なわれる。

【００６３】次いで、要求通りにアイソクロナス・リソ
ースを獲得できたか否かがステップＳ２２０にて判定さ
れるが、獲得できたと判定された場合、ステップＳ２３
０にてアイソクロナス・マネージャ７はアイソクロナス
・トーカーに対してそれらのリソースをバインドする。
ただし、実際には前記したトーカー情報変更処理におい
てバインド相当の処理が行なわれ、このためこの処理は
破線で示されている。次いで、ステップＳ２４０にてア
イソクロナス・トーカーが作成されたことを示すため
に、獲得したリソースの内容を添付した図９に示すフォ
−マットとされたトーカー情報報告パケットをブロード
キャストする。そして、ステップＳ２５０にてＰＩＭ８
にリソースバインドの成否を通知するが、この場合はリ
ソースバインドが成功しているのでその旨が通知され
る。

【００６４】また、要求通りにアイソクロナス・リソー
スを獲得できなかったとステップＳ２２０にて判定され
た場合は、ステップＳ２５０にてリソースバインドの不
成功がＰＩＭ８に通知される。このステップＳ２５０の
処理が終了すると、ステップＳ２６０にてアイソクロナ
ス・リソースをバインドしていない Talker entry が残
っているか否か判定されて、残っていると判定された場
合は、ステップ２００ないしステップＳ２５０のアイソ
クロナス・トーカーにリソースをバインドする処理が、
再度行なわれることにより、すべての Talker entry に
アイソクロナス・リソースをバインドする処理が行なわ
れ、この処理は終了する。これによって、アイソクロナ
ス・マネージャ７は外部からの要求を受け付けることが
できるようになる。

【００６５】２．３．１０ トーカー情報変更処理 次に、トーカー情報報告パケットをＮＩＭ９が受信した
ことがアイソクロナス・マネージャ７に通知（Isochron
ous Manager control request (Talker Info Received
））されると、talker 情報変更処理が行なわれる。
このtalker 情報変更処理の説明を図１４に示すフロー
チャートを参照しながら次に行なう。まず、ステップＳ
１６０にて受信された図９に示すフォ−マットのトーカ
ー情報報告パケットから、トーカー・ポートＩＤ、トー
カー・リソース情報を取り出して、新たなトーカーの e
ntry を作成して、図７に示すアイソクロナス情報テー
ブルの更新を行なう。次いで、ステップＳ１７０にてト
ーカー情報報告パケットをＰＩＭ８に転送することによ
り、ＰＩＭ８にパス情報の変更を報告する。この場合、
ＰＩＭ８は後述するように、パス情報テーブルを書き換
えてパスの接続処理を行なう。

【００６６】さらに、ステップＳ１８０にてＮＩＭ９に
アイソクロナス情報テーブルの更新結果を報告して、こ
の処理は終了する。この talker 情報変更処理は、ノー
ドにトーカーが作成された際にブロードキャストされる
トーカー情報報告パケットの受信により行なわれるが、
他のノードからブロードキャストされたトーカー情報報
告パケットに限らず、自ノードからブロードキャストさ
れたトーカー情報報告パケットによっても行なわれる処
理である。

【００６７】２．３．１１ ＮＩＭとのコミュニケーシ
ョン なお、ＮＩＭ９からアイソクロナス・マネージャ７に発
行されるIsochronousManager Control Request のサー
ビス・プリミティブにより以下のパラメータが渡され
る。 ・RESET ：アイソクロナス・マネージャ７は内部状態の
リセットを行なう。 ・INITIALIZE：アイソクロナス・マネージャ７は内部状
態の初期化を行なう。 ・TALKER INFO RECEIVED：ＮＩＭ９がトーカー情報報告
パケットを受信したことを通知する。 また、アイソクロナス・マネージャ７からＮＩＭ９に対
して発行されるIsochronous Manager Control Confirma
tion のサービス・プリミティブにより、 Isochronous
Manager Control Requestによる制御要求に対する成否
が返される。さらに、アイソクロナス・マネージャ７か
らＮＩＭ９に対して発行される Isochronous Manager E
vent Indication のサービス・プリミティブにより、ア
イソクロナス・マネージャ７の内部状態の変化を報告す
る。

【００６８】２．４ マルチキャスト転送サービス 次に、マルチキャスト転送サービスについての説明を行
なう。マルチキャスト転送は１つの送信ポートから複数
の受信ポートに対して行なわれる非同期コネクションレ
スのデータ転送方式である。マルチキャスト転送方式で
パケットを送出するポートがマルチキャスト・トーカ
ー、このパケットを受信するポートがマルチキャスト・
リスナーであり、マルチキャスト転送はｍＬＡＮトラン
スポート層１０で定義されている。アプリケーション・
ユーザはマルチキャスト・トーカーでの転送を行なう前
にポートに対してマルチキャスト・チャンネル番号をバ
インドしておく必要がある。これは、そのポートがその
チャンネルにおける送信権を獲得することを意味してい
る。

【００６９】あるマルチキャスト・チャンネル番号を使
ってパケットを送信できるのはそのチャンネル番号がバ
インドされているマルチキャスト・トーカーだけであ
り、マルチキャスト・トーカーから送信されるパケット
は特定のマルチキャスト・リスナーに送られるのではな
く、トランザクション層３で定義されているブロードキ
ャスト機能によって全ノードに対して転送される。各ノ
ードがマルチキャスト・パケットを受信した場合、トラ
ンザクション層３からマルチキャスト・マネージャ６に
対して受信通知が発行される。受信されたパケットには
マルチキャスト・トーカーに割り当てられてたマルチキ
ャスト・チャンネル番号が添えられているので、受信側
のマルチキャスト・マネージャ６はこのチャンネル番号
を検査して実際に受信すべきパケットであるかどうかを
判断する。したがって、マルチキャスト・トーカーは送
信したパケットをどのマルチキャスト・リスナーが受信
しているのかわからない。

【００７０】マルチキャスト・トーカーにバインドされ
るマルチキャスト・チャンネル番号は、バインドを行な
う際にｍＬＡＮトランスポート層１０内部のマルチキャ
スト・マネージャ６が確保する。また、マルチキャスト
・リスナーにバインドされるマルチキャスト・チャンネ
ル番号は、すでにいずれかのマルチキャスト・トーカー
にバインドされている番号とされる。

【００７１】マルチキャスト転送の転送メカニズムを図
３を参照しながら説明すると、この図ではノード＃１の
ポート＃１とポート＃３がマルチキャスト・トーカーと
して機能している。それぞれのポートにはマルチキャス
ト・チャンネル番号の＃２と＃４がバインドされてい
る。例えばノード＃１のポート＃１に対して上位アプリ
ケーションからデータ転送要求が発行されると、そのデ
ータはマルチキャスト・チャンネル＃２でローカルバス
中の全ノードにパケットとしてブロードキャストされ
る。各ノードは、送出されたパケットをブロードキャス
ト機能により受信するため、受信されたパケットは下位
層からｍＬＡＮトランスポート層１０に渡されて、その
パケットを受信する。

【００７２】一方、ノード＃２ではポート＃２が、ノー
ド＃３ではポート＃３がマルチキャスト・チャンネル＃
２を受信するためのマルチキャスト・リスナーとして機
能しているので、それぞれのノードのｍＬＡＮトランス
ポート層１０は、マルチキャスト・チャンネル＃２で受
信したパケット内のデータをそれぞれのマルチキャスト
・リスナーに渡す。これにより、１対多のマルチキャス
ト転送が実現される。同様にノード＃１のポート＃３か
ら送出されたパケットはマルチキャスト・チャンネル＃
４によって各ノードに転送され、ノード＃２ではポート
＃３ (マルチキャスト・チャンネル＃４がバインドされ
たマルチキャスト・リスナー) によって受信される。ノ
ード＃３ではマルチキャスト・チャンネル＃４はどのポ
ートにもバインドされていないのでそのチャンネルでｍ
ＬＡＮトランスポート層１０が受信したパケットは破棄
される。

【００７３】２．４．１ マルチキャスト・マネージャ マルチキャスト・マネージャ (Multicast Manager)６
は、マルチキャスト転送を行なうポートのためにマルチ
キャスト・チャンネル番号を獲得し、それをポートにバ
インドする機能を持つモジュールである。マルチキャス
ト・マネージャ６はトーカー情報報告パケットを発行す
ることによってマルチキャスト・チャンネルを獲得す
る。また、ローカルバス内で発行されるトーカー情報報
告パケットを全て受信し、それぞれのマルチキャスト・
トーカーとバインドされているマルチキャスト・チャン
ネル番号の対応テーブルを、図６に示すマルチキャスト
情報テーブルとして保持する。

【００７４】トーカー情報報告パケットを受信したマル
チキャスト・マネージャ６は受信順によってそのトーカ
ーのマルチキャスト・チャンネル番号を決定し、図６に
示すマルチキャスト情報テーブルを作成する。この場
合、自ノードから送出されたトーカー情報報告パケット
を受信したマルチキャスト・マネージャ６は、自ノード
のマルチキャスト・チャンネル番号を決定することにな
る。また、この対応テーブルはマルチキャスト・リスナ
ーがマルチキャスト・トーカーにバインドされているマ
ルチキャスト・チャンネル番号を探すために使われる。
マルチキャスト・マネージャ６は上位アプリケーション
からの要求によってその情報を提供する。マルチキャス
ト転送を行なうポート (マルチキャスト・トーカー /
マルチキャスト・リスナー) を持つノードにはマルチキ
ャスト・マネージャ６が実装される。

【００７５】２．４．２ マルチキャスト・リソースの
確保とバインド処理 次に、マルチキャスト・リソースの確保とバインド処理
について、図１７に示すフローチャートを参照しながら
説明する。マルチキャスト・トーカーとなるポートにバ
インドされるマルチキャスト・リソースの確保とバイン
ド処理は、マルチキャスト・マネージャ６が行なう。上
位層であるＰＩＭ８からマルチキャスト・チャンネル・
バインド要求（MulticastManager Bind Resource Reque
st ）を受け取ると開始され、ステップＳ６００にてマ
ルチキャスト・マネージャ６は、獲得したマルチキャス
ト・リソースであるマルチキャスト・チャンネル番号
を、 Node Unique ID とポートＩＤをパラメータとして
持つ図９に示すフォ−マットのトーカー情報報告パケッ
トに添付して全ノードにブロードキャストする。

【００７６】そして、ステップＳ６１０にてマルチキャ
スト・チャンネル番号が確保されたと判断された場合に
は、確保されたリソース（マルチキャスト・チャンネル
番号）を指定されたマルチキャスト・トーカーにバイン
ドする。次いで、ＰＩＭ８にリソースバインドの成否の
通知を行なうが、この場合には成功の通知が行なわれ
る。また、マルチキャスト・チャンネル番号が確保でき
なかったと判断された場合には、ステップＳ６１０から
ステップＳ６３０に進み、この旨の通知がＰＩＭ８に行
なわれる。これで、この処理は終了する。なお、ステッ
プＳ６１０およびステップＳ６２０の処理が破線で示さ
れているのは、実際にはトーカー情報報告パケットをブ
ロードキャストすることにより、後述するトーカー情報
変更処理において、リソース・バインドに相当する処理
が行なわれるためである。

【００７７】２．４．３ トーカー情報変更処理 ところで、ブロードキャストされたトーカー情報報告パ
ケットは各ノードのＮＩＭ９により受信されて、トーカ
ー情報変更処理が行なわれる。このトーカー情報変更処
理を、図２１に示すフローチャートを参照しながら説明
する。トーカー情報変更処理は、各ノード上のＮＩＭ９
からトーカー情報報告パケットの受信通知がマルチキャ
スト・マネージャ６に対して行なわれると開始され、ま
ずステップＳ７５０にてマルチキャスト・チャンネル番
号を、トーカー情報報告パケットの受信順に各ノードに
おいて割り当てるために、各ノードのマルチキャスト・
マネージャ６に備えられたパケット・カウンタを”１”
だけインクリメントする。すなわち、マルチキャスト・
マネージャ６はバスリセットによって”０”にリセット
されるパケット・カウンタを持ち、バスリセット後に送
信された全てのトーカー情報報告パケットを受信してそ
の数をカウントしている。

【００７８】次に、ステップＳ７６０にてマルチキャス
ト・マネージャ６は受信したトーカー情報報告パケット
に基づいて Node Unique ID、ポートＩＤ、マルチキャ
スト・チャンネル番号の対応テーブルである図６に示す
マルチキャスト情報テーブルを更新する。この場合、ト
ーカー情報報告パケットからポートＩＤが取り出される
と共に、その時のパケット・カウンタ値がリソース情報
として利用されて、Talker の entry が作成される。
次いで、ステップＳ７７０にてＰＩＭ８にトーカー情報
報告パケットを転送してパス情報の更新を報告し、さら
にステップＳ７８０にてＮＩＭ９に更新結果を報告して
この処理は終了する。すなわち、トーカー情報報告パケ
ットをブロードキャストしたマルチキャスト・マネージ
ャ６は、自分自身が送信したパケットを受信した時点で
のカウンタの値を、自ノードのマルチキャスト・トーカ
ーにバインドするマルチキャスト・チャンネル番号とし
て使用することになる。このマルチキャスト・チャンネ
ル番号はローカルバス内で最大２５６個 (０〜２５５)
まで割り当てることができる。なお、動作中にカウンタ
が２５６を越えてしまった場合、マルチキャスト・マネ
ージャ８は上位層に対して通知を行なう。

【００７９】２．４．４ マルチキャスト送信処理 次に、マルチキャスト送信処理を図１９に示すフローチ
ャートを参照しながら説明すると、マルチキャスト送信
処理は、上位層であるＰＩＭ８からマルチキャスト・マ
ネージャ６が転送データを受信した時に開始される。す
ると、ステップＳ６７０にて転送データを受信したマル
チキャスト・マネージャ６は、まず内部に保持している
図６に示すマルチキャスト情報テーブルを参照して、送
出すべきマルチキャスト・トーカーにバインドされてい
るマルチキャスト・チャンネル番号を獲得する。次い
で、ステップＳ６８０にて獲得されたマルチキャスト・
チャンネル番号を指定し、転送データをトランザクショ
ン層３に送ることにより、マルチキャスト転送要求を発
行する。これにより、転送データはマルチキャスト転送
されるが、この場合、マルチキャスト転送は実際にはブ
ロードキャストによる送信であるため ACK は返らな
い。

【００８０】２．４．５ マルチキャスト・リソースの
バインド処理（リスナー） 次に、マルチキャスト・リスナーについて説明を行なう
が、マルチキャスト・リスナーにおいてマルチキャスト
・パケットを受信するためにはそのマルチキャスト・パ
ケットに含まれているマルチキャスト・チャンネル番号
がリスナーにバインドされている必要がある。このため
に行なわれるマルチキャスト・リソースのバインド処理
を図１８に示すフローチャートを参照しながら説明する
と、この処理はＰＩＭ８よりリソースバインドの要求
（Multicast Manager Bind Resource Request ）を受信
すると開始される。まず、ステップＳ６４０にて内部に
保持されているマルチキャスト情報テーブルが参照され
て、受信すべきマルチキャスト・チャンネル番号が、指
定されたポートにバインドされる。

【００８１】次いで、ステップＳ６５０にてマルチキャ
スト情報テーブルにそのポートＩＤ、ポートタイプ、マ
ルチキャスト・リソース（マルチキャスト・チャンネル
番号）が新たな entry として書き込まれ、さらに、ス
テップＳ６６０にてＰＩＭ８にリソースバインドの成否
が通知される。ただし、リソース・バインドにはトーカ
ーで既に確保されているチャンネルにバインドするよう
な要求しかないので、リソース・バインドに失敗するこ
とはない。したがって、ここでは成功の通知がＰＩＭ８
に行なわれて、この処理は終了する。このようにして、
マルチキャスト・リスナーにマルチキャスト・リソース
がバインドされると、マルチキャスト転送を受信できる
ようになる。

【００８２】２．４．６ マルチキャスト受信処理 次に、マルチキャスト転送されたマルチキャスト・パケ
ットを受信するマルチキャスト受信処理を図２０に示す
フローチャートを参照しながら説明する。この処理は、
トランザクション層３からの受信通知により開始され、
まず、ステップＳ７００にてトーカーが重複しているか
否かが検出される。これは、マルチキャスト・パケット
に含まれるマルチキャスト・チャンネル番号とは、その
パケットを送出したマルチキャスト・トーカーにバイン
ドされているマルチキャスト・チャンネル番号であり、
１つのマルチキャスト・チャンネル番号がバインドされ
るマルチキャスト・トーカーはただ１つである。すなわ
ち、特定のマルチキャスト・チャンネル番号でパケット
を送出しているマルチキャスト・トーカーはただ１つと
なるからである。

【００８３】そこで、複数のマルチキャスト・トーカー
から同一のマルチキャスト・チャンネル番号でパケット
が送信されていることをマルチキャスト・マネージャ６
が検出した場合、ステップＳ７３０に進み上位層である
ＰＩＭ８に対する受信通知を中止すると共に、重複して
いるマルチキャスト・チャンネル番号に関連するポート
番号を指定して重複していることをＰＩＭ８に通知す
る。また、ステップＳ７００にてトーカーが重複されて
いないと検出された場合は、ステップＳ７１０に進みマ
ルチキャスト・マネージャ６は、マルチキャスト情報テ
ーブルを参照してリスナーのポートを取得する。次い
で、ステップＳ７２０にて各マルチキャスト・リスナー
にバインドされているチャンネル番号と一致した場合の
み、そのポートに対してパケット受信の通知を行なう。

【００８４】なお、下位層であるトランザクション層３
から受信通知により、全てのマルチキャスト・パケット
をマルチキャスト・マネージャ６は受信するが、パケッ
ト内に示されるマルチキャスト・チャンネル番号が、自
ノードの各マルチキャスト・リスナーにバインドされて
いる番号と一致した場合のみ、そのポートに対してパケ
ット受信の通知を行なう。これにより、リスナーはマル
チキャスト・データを受信することができる。また、該
当するリスナーが複数ある場合にはマルチキャスト・マ
ネージャ６がデータの複製を行う。そして、マルチキャ
スト・チャンネル番号がどのリスナーにもバインドされ
ていなかったパケットは破棄される。以上でマルチキャ
スト受信処理は終了する。

【００８５】２．４．７ 下位層とのコミュニケーショ
ン 以上説明したようにｍＬＡＮトランスポート層１０のマ
ルチキャスト・マネージャ６は、マルチキャスト転送を
行なうためにトランザクション層３とコミュニケーショ
ンを行なう。この時、ｍＬＡＮトランスポート層１０は
トランザクション層３で定義される以下のサービス・プ
リミティブを利用する。 Transaction Data Request：マルチキャスト・マネージ
ャ６はマルチキャスト転送を開始するためにトランザク
ション層３に対してこのプリミティブを発行する。マル
チキャスト転送はトランザクション層３のブロードキャ
スト機能を利用して行なわれるので、Transaction Type
として BROADCAST WRITE が指定される。 Transaction Data Indication ：トランザクション層３
からマルチキャスト・マネージャ６に対してブロードキ
ャスト・データの受信が通知される。

【００８６】２．４．８ ＰＩＭとのコミュニケーショ
ン また、マルチキャスト・マネージャ６は、マルチキャス
ト転送を行なうためにＰＩＭ８ともコミュニケーション
を行なう。この時、マルチキャスト・マネージャ６は上
位モジュールであるＰＩＭ８とコミュニケートするため
に以下のようなサービス・プリミティブが定義される。 Multicast Manager Data Request：ＰＩＭ８からマルチ
キャスト・マネージャ６に対して発行される。マルチキ
ャスト・マネージャ６は指定されたデータの転送を行な
う。 Multicast Manager Data Indication ：マルチキャスト
・マネージャ６からＰＩＭ８に対して発行される。マル
チキャスト・パケットを受信したことをＰＩＭ８に対し
て通知する。

【００８７】Multicast Manager Bind Resource Reques
t ：ＰＩＭ８からマルチキャスト・マネージャ６に対し
て発行される。マルチキャスト・マネージャ６は指定さ
れたポートに対してリソースのバインドを行なう。この
サービス・プリミティブによって、ポートＩＤおよびマ
ルチキャスト・チャンネル番号（ポートＩＤによって指
定されるポートのポートタイプが MULTICAST LISTENER
である場合に必要。）のパラメータが渡される。 Multicast Manager Bind Resource Confirmation：マル
チキャスト・マネージャ６からＰＩＭ８に対して発行さ
れ、Multicast Manager Bind Resource request による
バインド要求に対する成否が返される。

【００８８】２．４．９ ＮＩＭとのコミュニケーショ
ン また、マルチキャスト・マネージャ６は、マルチキャス
ト転送を行なうためにＮＩＭ９ともコミュニケーション
を行なう。この時、マルチキャスト・マネージャ６は上
位モジュールであるＮＩＭ９とコミュニケートするため
に以下のようなサービス・プリミティブが定義され、Ｎ
ＩＭ９はマルチキャスト・マネージャ６の内部のリセッ
トや初期化を行なうためにこれらのサービス・プリミテ
ィブを利用する。

【００８９】Multicast Manager Control Request ：Ｎ
ＩＭ９からマルチキャスト・マネージャ６に対して発行
される。このサービス・プリミティブによって以下のパ
ラメータが渡される。 ・RESET ：マルチキャスト・マネージャ６は内部状態の
リセットを行なう。 ・INITIALIZE：マルチキャスト・マネージャ６は内部状
態の初期化を行なう。 ・TALKER INFO RECEIVED：ＮＩＭ９がトーカー情報報告
パケットを受信したことを通知する。 Multicast Manager Control Confirmation：マルチキャ
スト・マネージャ６からＮＩＭ９に対して発行される。
Multicast Manager CONTROL.request による制御要求に
対する成否が返される。 Multicast Manager Event Indication：マルチキャスト
・マネージャ６からＮＩＭ６に対して発行される。マル
チキャスト・マネージャの内部状態の変化を報告する。

【００９０】２．４．１０ バスリセット対応処理、バ
スリセット完了通知受信処理 次に、バスリセット時の動作について説明するが、前記
したように新たなノードがバスに参入された場合は、バ
スリセットを行なってすべてのパスをリセットし、次い
で各ノードにノードＩＤを新たにつけ替えてパスを再構
築する。この場合、バスリセット対応処理に続いてバス
リセット完了通知受信処理が行なわれる。バスリセット
対応処理を図２２に示すフローチャートを参照しながら
説明すると、バスリセットが発生するとＮＩＭ９からマ
ルチキャスト・マネージャ６に対してリセット要求 (Mu
lticast Manager control request (Reset))が発行さ
れ、バスリセット対応処理が開始される。すると、ステ
ップＳ８００にてこのリセット要求を受け取ったマルチ
キャスト・マネージャ６は、トーカー情報報告パケット
カウンタを”０”にリセットする。さらに、マルチキャ
スト情報テーブルで保持されているマルチキャスト・チ
ャンネル番号をクリアすると共に、ステップＳ８１０に
てＰＩＭ８からのマルチキャスト転送要求を reject す
る。そして、バスリセット対応処理は終了する。

【００９１】そして、バスリセットが完了するとＮＩＭ
９からマルチキャスト・マネージャ６に対してイニシャ
ライズ要求 (Multicast Manager control request (Ini
tialize)) が発行される。このイニシャライズ要求を受
け取ったマルチキャスト・マネージャ６は、バスリセッ
ト完了通知受信処理を行なう。バスリセット完了通知受
信処理を図２３に示すフローチャートを参照しながら説
明すると、内部のマルチキャスト情報テーブルでポート
ＩＤが保持されており、かつそのポートＩＤに対応する
マルチキャスト・チャンネル番号がクリアされていた場
合、そのポートにバインドされていたマルチキャスト・
チャンネル番号がバスリセットによってクリアされたこ
とを意味している。

【００９２】そこで、ステップＳ８２０にてマルチキャ
スト情報テーブルからリソースがクリアされた１つの T
alker entry を取り出し、ステップＳ８３０にてマルチ
キャスト・マネージャ６は、その Talker entry に対す
るマルチキャスト・チャンネル番号を獲得し、リソース
（マルチキャスト・チャンネル番号）の内容を添付した
トーカー情報報告パケットをブロードキャストする。そ
して、ステップＳ８４０にてリソースが確保されたか否
かが判断されるが、確保されたと判断された場合はステ
ップＳ８５０に進み、取り出された Talker entry に対
するマルチキャスト・チャンネル番号がバインドされ
る。次いで、ステップＳ８６０にてＰＩＭ８にリソース
バインドの成否を通知するが、この場合はリソース・バ
インドが成功しているのでその旨が通知される。

【００９３】また、ステップＳ８４０にてリソースの確
保に失敗したと判断された場合は、リソース・バインド
の不成功がＰＩＭ８に通知される。なお、ステップＳ８
４０およびステップＳ８５０の処理が破線とされている
のは、前記２．４．５ マルチキャスト・リソースの確
保とバインド処理で述べた理由と同じ理由による。この
処理が終了すると、ステップＳ８７０にてまだマルチキ
ャスト・リソースがバインドされていない Talker entr
y が残っているか否か判定されて、残っていると判定さ
れた場合は、ステップＳ８２０に戻り前記マルチキャス
ト・トーカーにリソースをバインドする処理が、再度行
なわれることにより、すべての Talker entry にマルチ
キャスト・リソースをバインドする処理が行なわれ、 T
alker entry のすべてにリソースがバインドされると、
この処理は終了する。これによって、マルチキャスト・
マネージャ６は外部からの要求を受け付けることができ
るようになる。

【００９４】２．５ ＰＩＭ（パス情報管理） 次に、ｍＬＡＮトランスポート層１０内における上位層
であるＰＩＭ (パス情報管理) ８の詳細な説明する。Ｐ
ＩＭ８はｍＬＡＮトランスポート層１０の中に存在し、
トーカー・ポートとリスナー・ポートの間にパスを設定
するモジュールである。ＰＩＭ８は設定したパスに関す
る情報を保持し、バスリセットによってバスの再初期化
が行なわれた場合にも設定されていたパスを自動的に再
設定する機能を有している。ただし、ＰＩＭ８が保持す
るパス情報はｍＬＡＮトランスポート層１０で定義され
ている前記した３つの転送方式のうち、アイソクロナス
転送とマルチキャスト転送を行なうポートに関してのみ
である。

【００９５】すなわち、ＰＩＭ８は上位層に対して以下
のようなサービスを提供する。 Ａ．パスの設定 / 解放：アイソクロナス転送やマルチ
キャスト転送を行なうポート間にパスを設定する。ま
た、設定されているパスを解放することができる。 Ｂ．パス情報の記憶：ＰＩＭ８が提供するサービスを利
用して設定されたパスを記憶する。PIM は電源を落とし
た状態でもこのパス情報を保持し、このパス情報を使っ
て電源再投入後のパスの再構成を行なう。 Ｃ．電源再投入後のパスの再構成：電源再投入によるバ
スの初期化後、ＰＩＭ８は保持しているパス情報をもと
に自動的にパスの再設定を行ない、バス初期化前の接続
情報を再現する。 Ｄ．他ノード上のＰＩＭ８とのパス情報の交換：ＰＩＭ
８はパス情報管理プロトコルしたがって上位アプリケー
ションの要求によって他ノード上のパス情報を問い合わ
せる。この場合の他ノードとは、例えばフロッピーディ
スクドライブである。

【００９６】さらに、ＰＩＭ８はローカル・ノード上に
あるリスナー・ポートとリモート・ノードのトーカー・
ポートの間でパスを設定／削除するサービスを提供して
いる。したがって、ＰＩＭ８はリモート・ノードにある
トーカーとリスナーの間にパスを設定することはできな
い。この機能は上位アプリケーションであるバス・マネ
ージャによって実現される。

【００９７】２．５．１ パスの設定処理 次に、ＰＩＭ８が行なうパスの設定処理を図２４に示す
フローチャートを参照しながら説明する。パスの設定処
理は、リスナー・ノード上のＰＩＭ８が、上位アプリケ
ーションからのパス設定要求（PIM Set Path Request）
を受け取ると、開始される。まず、上位アプリケーショ
ンからパス設定要求を受け取ったＰＩＭ８は、ステップ
Ｓ３００にてトーカー・ポートに関する属性を獲得す
る。次に、ステップＳ３１０にてリスナーポートの属性
を、獲得されたトーカー・ポートと同じ属性に合わせ
る。

【００９８】そして、ステップＳ３２０にてＰＩＭ８
は、下位のチャンネル管理モジュール(ポートタイプが
アイソクロナスの場合はアイソクロナス・マネージャ
７、ポートタイプがマルチキャストの場合はマルチキャ
スト・マネージャ６）にバインドを要求する。この場
合、トーカーについてはすでにバインドが完了している
ので、このバインドはリスナーについてのみ行なわれ
る。次いで、パスが正常に設定されたとして、ステップ
Ｓ３３０にてこのパス情報によりパス情報テーブルを変
更する。この場合の変更は、接続状態フラグが Disconn
ected であったものを Connectedに書き換える変更とな
る。

【００９９】そして、ステップＳ３４０にて上位層に対
してパス設定要求に対する成否を報告するが、この場合
は成功の報告が行なわれる。なお、このパスの設定はト
ーカーで既に確保されているリソースを、リスナーのリ
ソースにコピーする処理であるので通常は失敗すること
はない。これにより、パスの設定処理は終了する。な
お、パス設定処理においては１つのトーカーポートに対
して複数のリスナー・ポートへ接続するパスを設定する
ことはできるが、逆に１つのリスナー・ポートを複数の
トーカー・ポートに接続するパスを設定することはでき
ない。また、パスの設定はリスナー上のＰＩＭ８によっ
て行なわれ、ＰＩＭ８のレベルではトーカーがリスナー
を指定してパスを設定することはできない。

【０１００】２．５．２ パスに対するデータ送信処理 次に、パスに対するデータ送信処理について、図２５に
示すフローチャートを参照しながら説明する。上位層よ
りＰＩＭ８が送信するデータを受信すると、パスに対す
るデータ送信処理が開始され、まず、ステップＳ３６０
にてＮＩＭ９が保持する図８に示すポート情報エントリ
ーが参照されることにより、データを送信するポートタ
イプが参照される。そして、ステップＳ３７０にてポー
トタイプがトーカーか否かが判定され、ポートタイプが
トーカーと判定されると、さらにステップＳ３８０にて
ポートタイプがマルチキャストか否かが判定される。こ
こで、ポートがマルチキャストのポートと判定される
と、ステップＳ３９０にてＰＩＭ８はマルチキャスト・
マネージャ６にデータを転送する。マルチキャスト・マ
ネージャ６では、これを受けて前記したマルチキャスト
送信処理が行なわれる。

【０１０１】また、ポートがアイソクロナスポートと判
定された場合は、ステップＳ３８０からステップＳ４０
０に進み、アイソクロナス・マネージャ７にデータを転
送する。アイソクロナス・マネージャ７では、これを受
けて、前記図１２に示すアイソクロナス送信処理が行な
われる。以上でパスに対するデータ送信処理は終了す
る。なお、ステップＳ３７０にてポートがトーカーと判
断されない場合は、そのまま終了する。

【０１０２】２．５．３ パスの解放処理 次に、パスの解放処理を図２６に示すフローチャートを
参照しながら説明するが、すでに設定されているパス情
報は、リスナー・ノード上のＰＩＭ８が保持するパス情
報テーブルに記憶されているので、実際にパスを解放す
る作業はリスナー・ノードのＰＩＭ８で行われる。この
場合、トーカーに対する確認を行なうことなくパスの解
放が行なわれる。ＰＩＭ８は上位層からパス解放要求
（PIM Release Path Request）を受け取ると、パスの解
放処理が開始される。まず、ステップＳ４１０にてＰＩ
Ｍ８は、図４に示すパス情報テーブルを参照してリスナ
ー・ポートに対して該当するようなパスが接続されてい
るかどうかを確認する。

【０１０３】そして、ステップＳ４２０にてパスが接続
されているか否かの判断を行ない、パスが接続されてい
た場合にはステップＳ４３０にてリスナー・ポートにバ
インドされているリソースを解放し、パス情報テーブル
から対応するエントリーを削除する。次いで、ステップ
Ｓ４４０にて上位層に対してパス開放要求の返答を行な
うが、この場合はパス開放の返答を行なう。また、ステ
ップＳ４２０にてパスが接続されているか否かの判断を
行ない、パスが接続されていないと判断された場合は、
上位層に対してその旨の返答をステップＳ４４０にて行
なう。

【０１０４】２．５．４ バスリセット対応処理、トー
カー情報変更処理 各種不成功通知処理 ところで、ｍＬＡＮトランスポート層１０では、非同期
マルチキャスト転送に用いるチャンネルをダイナミック
に獲得しているため、バスリセットが発生した場合、ト
ーカーは新たにマルチキャスト・チャンネル番号を獲得
する必要がある。したがって、バスリセットの前後では
トーカーにバインドされるマルチキャスト・チャンネル
番号が変更される可能性がある。したがって、リスナー
には新たにトーカーにバインドされたマルチキャスト・
チャンネル番号を設定しないと、データを受信すること
ができなくなる。

【０１０５】そこでＰＩＭ８は、バスリセット時にバス
リセット対応処理をまず行ない、次にトーカー情報変更
処理を行なう。バスリセット対応処理を図２７を参照し
ながら説明する。バスリセットが発生するとＮＩＭ９か
らＰＩＭ８に対してリセット要求 (PIMcontrol reques
t (Reset)) が発行されると、バスリセット対応処理が
開始される。ＰＩＭ８はこの要求を受け取ると、ステッ
プＳ４５０にてパス情報テーブル内の全てのエントリー
の接続状態フラグを DISCONNECT に設定する。つまりパ
ス情報テーブルは保持しているが、このパス情報に基づ
く転送は行なえない状態とする。

【０１０６】また、前記したようにバスリセットが完了
すると各ノードはそれぞれのノード内のアイソクロナス
・トーカーとマルチキャスト・トーカーに対してリソー
スの再バインドを行なう。ここで正常にリソースの再バ
インドが行なわれた場合、このトーカーについての更新
された情報が、図９に示すフォ−マットのトーカー情報
報告パケットによってバス内の全ノードにブロードキャ
ストされる。そして、このパケットの受信はマルチキャ
スト・マネージャ６かアイソクロナス・マネージャ７を
通してＰＩＭ８に対して通知され (IM event indicatio
n()あるいは MM event indication()) 、トーカー情報
変更処理が開始される。

【０１０７】このトーカー情報変更処理のフローチャー
トを図２９に示すが、まずステップＳ４６０にて各ノー
ド上のＰＩＭ８はパス情報テーブルを参照して、ノード
・ユニーク・ＩＤを検出することにより、通知が行なわ
れたトーカーに対応するエントリーが探される。次い
で、そのトーカー・ポートの属性がステップＳ４７０に
て獲得され、さらに、そのトーカー・ポートとパスによ
って接続されるリスナー・ポートの属性がステップＳ４
８０にて獲得される。

【０１０８】そして、ステップＳ４９０にて獲得された
両ポートを接続することが可能か否かが判断され、可能
と判断された場合は、さらにステップＳ５００にてポー
トのタイプがマルチキャストか否かが判断される。そし
て、マルチキャストと判断された場合はステップＳ５１
０にてマルチキャスト・マネージャ６にマルチキャスト
・リソースのバインドを要求し、アイソクロナスと判定
された場合はステップＳ５２０にてアイソクロナス・マ
ネージャ７にアイソクロナス・リソースのバインドを要
求する。これを受けたいずれかの下位のチャンネル管理
モジュールは、該当するリスナーにリソースのバインド
処理を行ない、その結果をＰＩＭ８に通知する。この通
知を受けてＰＩＭ８は、ステップＳ５３０にてリソース
のバインドが成功したか否か判断し、バインドが成功し
たと判断した場合はステップＳ５４０にてパス情報テー
ブルの接続状態フラグを Connected に変更する。

【０１０９】なお、ステップＳ４９０にて獲得された両
ポートを接続することが不可能と判断された場合は、ス
テップＳ５５０にてエラー処理が行なわれる。また、ス
テップＳ５３０にて下位のチャンネル管理モジュールか
らバインドが不成功と通知された場合も、ステップＳ５
５０にてエラー処理が行なわれる。以上の処理が行なわ
れてトーカー情報変更処理は終了する。ＰＩＭ８はトー
カー情報報告パケットを受け取るたびに、このトーカー
情報変更処理を行なう。しかし、例えばバスリセット以
前に転送を行なっていたトーカーのノードが引き抜かれ
たような場合には、バスリセット完了後にそのトーカー
はバス上に存在しないので、このトーカーに関するトー
カー情報報告パケットはブロードキャストされないこと
になる。このような場合、このトーカーに関するパス情
報エントリーは DISCONNECTED の状態で保持されるの
で、情報としては保持されているがパスは再設定されな
いことになる。

【０１１０】このような場合、パス情報としてはそのま
ま保持されているので、次のバスリセットでまたバスに
接続されトーカー情報報告パケットがブロードキャスト
されればパスの再接続を行なうことができる。また、Ｐ
ＩＭ８はこのような「保持されているが接続されていな
い」パス情報を消去するためのサービスを上位層に対し
て提供することもできる。この作業によって上位アプリ
ケーションはバスリセットの前後でデータ転送を継続し
て行なうことができる。また、ＰＩＭ８には各種不成功
通知が下位モジュールから通知されるが、この場合には
図２８に示す各種不成功通知処理が行なわれる。この処
理では、ＰＩＭ８はステップＳ５６０にて上位層に問題
発生を通知して終了する。

【０１１１】２．５．５ ＮＩＭとのコミュニケーショ
ン ＰＩＭ８はＮＩＭ９とコミュニケーションを行なうため
に以下のようなサービス・プリミティブが定義されてい
る。 PIM Control Request PIM Control Confirmation PIM Event Indication ＮＩＭ９はＰＩＭ８の内部のリセットや初期化を行なう
ためにこれらのサービス・プリミティブを利用する。

【０１１２】２．６ ＮＩＭ (ノード情報管理) ９ ＮＩＭ９は各ノードのｍＬＡＮトランスポート層１０内
に存在し、以下のような機能を有している。 Ａ．バスの状態変化にもとづくｍＬＡＮトランスポート
層１０の初期化 ＮＩＭ９はノード・コントローラ４の上位層として位置
し、ノード・コントローラ４から通知されるバス状態の
変化にしたがって、ｍＬＡＮトランスポート層１０内部
の各モジュールのリセット／初期化を行なう。

【０１１３】Ｂ．他ノードに対するノード情報の提供 ｍＬＡＮトランスポート層１０ではポート間でデータを
交換するためのサービスが提供されているが、上位アプ
リケーションは他ノードの内部アドレスに対して直接ア
クセスすることができない。各ノード上の情報や機能設
定のためのレジスタが内部のアドレス上に配置されてい
るので、上位アプリケーションはこれらのアドレスに対
して操作を行なう場合にはＮＩＭ９を通じて行なう。Ｎ
ＩＭ９は他ノードからの問い合わせを受け付けるための
トランザクション・ポートを１つ持つ。このポートをＮ
ＩＭポートと呼ぶ。ＮＩＭポートのポートＩＤは全ノー
ド共通であり、全てのノードはそのＩＤをあらかじめ知
っている必要がある。ＮＩＭ９は Configuration ROM
のエントリーやポート情報エントリーを参照して問い合
わせ要求のあった情報を requester に返す。

【０１１４】Ｃ．トーカー情報報告パケットの処理 トーカー情報報告パケットは、前記したようにアイソク
ロナス・トーカーやマルチキャスト・トーカーが作成さ
れた時にそれぞれのマネージャによって発行されるパケ
ットである。このパケットはトーカー・ポートに関する
情報を報告するためにローカルバス内の全ノードのＮＩ
Ｍポートに対して発行される。ＮＩＭ９はこのパケット
を受信するとパケットの内容をノード内のアイソクロナ
ス・マネージャ７かマルチキャスト・マネージャ６に渡
す。どちらのマネージャに渡すかはトーカー・ポートに
バインドされているリソースによって決定する。

【０１１５】次に以上の機能を奏するためのＮＩＭ９の
動作について説明する。 ２．６．１ ポート情報の問い合わせ処理 上位アプリケーションがノード内のリスナー・ポートに
リソースをバインドしようとする場合、このアプリケー
ションは特定のトーカー・ポートにバインドされている
リソースを知らなければならない。このような場合、上
位アプリケーションはＮＩＭ９に問い合わせてトーカー
・ポートに関する情報を得るようにする。このポート情
報の問い合わせ処理を、図３０に示すフローチャートを
参照しながら説明する。この処理は、上位層からＮＩＭ
９は問い合わせ要求を受け取ると開始され、ステップＳ
９００にてポート情報テーブルを参照することにより、
問い合わせのあった entry の情報を入手して上位層に
返答する。また、他ノードのポート情報については、そ
のノード上のＮＩＭ９とトランザクション通信を行なう
ことにより、トーカー・ポートに関するポートタイプお
よびリソース情報を入手し、その情報を上位層に対して
通知する。これによりこの処理は終了する。

【０１１６】２．６．２ トーカー情報報告パケット処
理 ＮＩＭ９は、トーカー情報報告パケットを受信すると、
トーカー情報報告パケット処理を行なうが、この処理を
図３１に示すフローチャートを参照しながら説明する。
トーカー情報報告パケットをＮＩＭ９が受信すると、ト
ーカー情報報告パケット処理が開始され、まずステップ
Ｓ９１０にて受信したトーカー情報報告パケットに応じ
て、ノード情報テーブルにノードＩＤとノード・ユニー
クＩＤを書き込むことにより更新する。次に、ステップ
Ｓ９２０にてトーカー情報報告パケット内のトーカーに
バインドされているリソース情報から、トーカーがアイ
ソクロナス・トーカーかマルチキャスト・トーカーかを
判断する。そして、アイソクロナス・トーカーと判断さ
れた場合は、ステップＳ９３０に進みアイソクロナスマ
ネージャ７にトーカー情報報告パケットを転送し、マル
チキャスト・トーカーと判断された場合は、ステップＳ
９４０にてマルチキャストマネージャ６にトーカー情報
報告パケットを転送する。これで、この処理は終了す
る。

【０１１７】２．６．３ 下位層とのコミュニケーショ
ン ＮＩＭ９はノード・コントローラ４によって定義されて
いる以下のサービス・プリミティブを利用してノード・
コントローラ４とコミュニケーションを行なう。 SB Control Request (SB_CONTROL.request) SB Control Confirmation (SB_CONTROL.confirmation) SB Event indication (SB_EVENT.indication)

【０１１８】２．６．４ バスリセット対応処理、バス
リセット完了時処理 バスリセットが発生するとノード・コントローラ４から
ＮＩＭ９に対してバスリセット要求（ SB event indica
tion (BUS RESET START)）が発行され、この通知をＮＩ
Ｍ９が受け取ると、バスリセット対応処理が開始され
る。この処理を図３２に示しフローチャートを参照しな
がら説明する。バスリセット要求がＮＩＭ９で受信され
ると、ステップＳ９５０にてＮＩＭ９は、ｍＬＡＮトラ
ンスポート層１０内部のアイソクロナス・マネージャ７
に対して内部状態のクリアを要求するためのリセット要
求（Isochronous Manager Control Request （Reset
））を発行する。次いで、ステップＳ９６０にてマル
チキャスト・マネージャ６に対して内部状態のクリアを
要求するためのリセット要求（Multicast Manager Cont
rol Request （Reset ））を発行する。さらに、ステッ
プＳ９７０にてＰＩＭ８に対して内部状態のクリアを要
求するためのリセット要求（PIM Control Request （Re
set ））を発行し、この処理は終了する。

【０１１９】また、バスリセットが完了するとノード・
コントローラ４からＮＩＭ９に対してバスリセット完了
（ SB event indication (BUS RESET COMPLETE) ）が発
行される。ＮＩＭ９が、この通知を受け取ると図３３に
示すフローチャートのバスリセット完了時処理が開始さ
れる。バスリセット完了時処理が開始されると、ステッ
プＳ９８０にてＮＩＭ９はｍＬＡＮトランスポート層１
０内部のアイソクロナス・マネージャ７にリセット完了
を発行し、次いで、ステップＳ９９０にてマルチキャス
ト・マネージャ６にリセット完了を発行する。これで、
この処理は終了する。

【０１２０】２．７ ｍＬＡＮトランスポート層のファ
シリティ ２．７．１ パス情報テーブル パス情報テーブルはノード上のリスナー・ポート (アイ
ソクロナス・リスナー/ マルチキャスト・リスナー)
に設定されているパスを記憶しておくためのテーブルで
ある。このパス情報テーブルはＰＩＭ８によって管理さ
れている。また、このテーブルの内容はＮＩＭ９からも
参照されＮＩＭ９によって他ノードに渡される。パス情
報テーブルのフォーマットを図４に示すが、パス情報テ
ーブルで１つのパスに関する情報がパス情報エントリで
ある。１つのパス情報エントリには以下の情報が含まれ
る。

【０１２１】Ａ．リスナーのポートＩＤ (16ビット) ：
ローカルノードのポート番号。 Ｂ．トーカーのポートＩＤ (16ビット) ：リモートノー
ドのポート番号。 Ｃ．トーカーがあるノードの Node Unique ID (64 ビッ
ト) ：リモートノードを特定するために用いるＩＤであ
り、６４ビットの長さを持ち、各メーカによって各ノー
ドごとにあらかじめ設定されている。バスリセットやパ
ワーリセットによって変更されることがない。 Ｄ．接続状態フラグ：このエントリで示されるパスの接
続状態を示すフラグ。パス情報テーブル内に記憶されて
いても再初期化後のネットワーク構成の変化によってパ
スの再設定が行なわれないエントリもある (例えばリモ
ートノードが見つからなかった場合) 。このような場合
にこのエントリのパスが実際に設定されているかどうか
を示すフラグである。

【０１２２】２．７．２ ノード情報テーブル ノード情報テーブルはローカルバス内のノードのノード
ＩＤと Node Unique ID の対応を示すテーブルである。
ノード情報テーブルはＮＩＭ９によって管理される。ｍ
ＬＡＮではバスリセットによってノードＩＤが変更され
る場合があるので、バスリセット後はＮＩＭ９によって
更新が行なわれる。ノード情報テーブルは次の情報から
なり、そのフォ−マットを図５に示す。 Ａ．ノードＩＤ：バスの初期化時に各ノードに動的に割
り当てられるＩＤ。 Ｂ．Node Unique ID：各ノードにあらかじめ割り当てら
れている６４ビットのＩＤである。ｍＬＡＮでは上位２
４ビットを Node Vendor ID とし、下位４０ビットを V
endor Unique ID とする。これによって Node Unique I
D の一意性が保証されている。

【０１２３】２．７．３ マルチキャスト情報テーブル マルチキャスト・マネージャ６によって管理される情報
テーブル。ノード内のマルチキャスト・ポートのポート
ＩＤと、そのポートにバインドされているマルチキャス
ト・リソースの対応を示すテーブルである。それぞれの
マルチキャスト・ポートに対する情報テーブルのエント
リーには、次の情報が含まれ、そのフォ−マットを図６
に示す。 Ａ．ポートＩＤ：マルチキャスト・リソースがバインド
されているポートのＩＤである。 Ｂ．ポートタイプ：マルチキャスト・トーカーあるいは
マルチキャスト・リスナーのいずれかを示している。 Ｃ．マルチキャスト・リソース：マルチキャスト・チャ
ンネル番号である。

【０１２４】なお、バスリセットが発生するとマルチキ
ャスト・リソース（チャンネル番号）はクリアされる。
マルチキャスト・ポートのポートＩＤに関する内容はバ
スリセットの前後で保持されるので、バスリセット完了
後それぞれのポートに対して新たなマルチキャスト・チ
ャンネル番号を割り当てるための処理が行なわれる。た
だし、このテーブルの内容はパワーリセット (電源の O
N / OFF) では保存されない。

【０１２５】２．７．４ アイソクロナス情報テーブル アイソクロナス・マネージャ７によって管理される情報
テーブル。ノード内のアイソクロナス・ポートのポート
ＩＤと、そのポートにバインドされているアイソクロナ
ス・リソースの対応を示すテーブルであり、それぞれの
アイソクロナス・ポートに対する情報テーブルのエント
リーには、以下の情報が含まれ、そのフォ−マットを図
７に示す。

【０１２６】Ａ．ポートＩＤ：アイソクロナス・リソー
スがバインドされているポートのＩＤである。 Ｂ．ポートタイプ：アイソクロナス・トーカーあるいは
アイソクロナス・リスナーのいずれかを示す。 Ｃ．アイソクロナス・リソース：バインドされているリ
ソースを示す。アイソクロナス・トーカーに対してはア
イソクロナス・チャンネル番号と帯域、アイソクロナス
・リスナーに対してはアイソクロナス・チャンネル番号
がバインドされている。なお、アイソクロナス情報テー
ブルの内容はバスリセットが発生した場合にも保持され
ている。

【０１２７】２．７．５ ポート情報エントリー ポート情報エントリーはＮＩＭ９によって管理され、ノ
ード内に作成されるポートの属性が記述される。ポート
情報エントリーは各ノード内のアドレス空間上に配置さ
れる。各ポートの情報エントリーはポートＩＤから一意
に指定されるオフセット上に配置される。リモート・ノ
ードから直接ポート情報エントリーのアドレスにアクセ
スすることはできない。それぞれのポート情報エントリ
ーにはポートタイプに応じたリソースに関するエントリ
ーが含まれ、そのフォーマットを図８に示す。

【０１２８】Ａ．ポートＩＤ：ポートを特定するために
各ポートに割り当てられるＩＤ (１６bit) であり、ポ
ートＩＤは１つのノード内での一意性が保証されてい
る。特定の用途に使われるポート (例．ＰＩＭ８／ＮＩ
Ｍ９など) のポートＩＤは固定的に割り当てられ、全ノ
ードで等しいＩＤが割り当てられるようにする。 Ｂ．ポートタイプ：ポートが扱うことのできる転送方式
を示す。４ビット（d dd d ）で転送方式の種類 (マル
チキャスト /アイソクロナス / トランザクション) を
示し、別の４ビット（k k k k ）で転送方向（送信／受
信／送受信）を示す。 Ｃ．リソース：ポートにバインドされているリソースを
示す。ポートタイプに応じたリソースとなる。

【０１２９】２．７．６ トーカー情報報告パケット このパケットはトーカーが作成されて、リソースがバイ
ンドされたことをローカルバス中の全ノードに報告する
ためのパケットである。このパケットは各ノードのＮＩ
Ｍ９に対してブロードキャストされる。マルチキャスト
・トーカーの場合にはポートが作成された時に，このパ
ケットがブロードキャストされる。各ノードのトランス
ポート層１０はこのパケットの受信順でマルチキャスト
・トーカーに対して割り当てるマルチキャスト・チャン
ネル番号を決定する。アイソクロナス・トーカーの場合
には各ノードのアイソクロナス・マネージャがリソース
を確保した時点で発行される。トーカー情報報告パケッ
トには以下の情報が含まれ、そのフォ−マットを図９に
示す。

【０１３０】Ａ．パケットＩＤ：トーカー情報パケット
を示すパケットＩＤである。 Ｂ．トーカー・ポートＩＤ：作成されたトーカーのポー
トＩＤである。 Ｃ．トーカー・ノードＩＤ：トーカーが属するノードの
ノードＩＤである。 Ｄ．トーカー・ユニークＩＤ：前記したとおり、各ノー
ドにあらかじめ割り当てられている６４ビットのＩＤで
ある。 Ｅ．トーカー・リソース情報：作成されたトーカーにバ
インドされているリソース情報である。

【０１３１】２．８ ｍＬＡＮサイクル・ストラクチャ
ー 以上説明したｍＬＡＮのサイクル・ストラクチャーの一
例を図３４に示す。この図では、サイクル＃ｍのサイク
ルが主に示されており、この例では各１転送サイクル
（nominal cycle period）は１２５μｓｅｃとされてい
る。この転送サイクルの開始タイミング（cycle sync）
はサイクル・マスターから全ノードに通知される。アイ
ソクロナス・マネージャ７はこれを受信して送信すべき
データがある時にはアイソクロナス転送を行なう。この
転送は、物理層１のアービトレーションにより１ノード
だけが転送できるように制御される。この結果、例えば
図示するようにアイソクロナス・チャンネルＪ、チャン
ネルＫ、・・・チャンネルＮでそれぞれ確保した帯域分
のデータがそれぞれのチャンネルで順次転送される。な
お、アイソクロナス転送においては各転送サイクルにお
いて帯域が確保されているので、各転送サイクルごとに
データは転送される。

【０１３２】アイソクロナス転送が終了すると、マルチ
キャスト・マネージャ６によるマルチキャスト転送が行
なわれる。この転送も１ノードだけが転送できるように
制御される。この例では、チャンネルＡ、チャンネル
Ｂ、チャンネルＣがマルチキャスト・チャンネルとされ
ている。なお、このマルチキャスト転送においては帯域
はある幅の中で任意とされるためパケットが１転送サイ
クル期間中で終了しない場合が生じる。この場合は、１
転送サイクルを越えてパケットが終了するまでマルチキ
ャスト転送が継続される。そして、図示するように次の
サイクル（＃ｍ＋１）の開始が遅延される。マルチキャ
スト転送は、送出するデータがある時にだけ転送すれば
良いため、離散的に発生するデータを送出するには好適
な転送方式である。

【０１３３】２．９ マルチキャスト転送とアイソクロ
ナス転送との使い分け アプリケーションより見た場合、ノード間の情報は、あ
るポートを指定して情報を送出／受信するだけで、マル
チキャスト転送でもアイソクロナス転送でもまったく同
じように転送されているように見える。したがって、同
じＭＩＤＩメッセージでもデータの帯域や、アイソクロ
ナス・チャンネルの空き具合に応じて、マルチキャスト
転送で転送したり、アイソクロナス転送で転送したりす
ることができる。

【０１３４】この場合、トーカーに対応するポート・タ
イプはアプリケーションの実行の状態に応じて変化する
ものとなるが、リスナーのポート・タイプはトーカーの
ポート・タイプと一致させる必要があるので、ＰＩＭ８
の行なうパスの設定処理において、トーカーのポート・
タイプをリスナーに引き継ぐ（コピーする）ようにす
る。これにより、アプリケーションのユーザ（特にリス
ナー）はアイソクロナス転送か、マルチキャスト転送か
を考慮することなく、パスを設定することができるよう
になる。ここで、トーカー側のアプリケーションでは、
利用者が転送の方式を設定するようにしてもよく、アイ
ソクロナス・チャンネルの帯域の利用状況を見て、アプ
リケーションが自動的に判別するようにしてもよい。

【０１３５】２．１０ プラグ・アンド・プレイ プラグ・アンド・プレイは各種電子機器をケーブル等に
接続するだけで、煩雑な内部設定をすることなく電子機
器を利用可能にする技術である。ｍＬＡＮにおいては、
すべての情報をパス情報が必要なマルチキャスト転送ま
たはアイソクロナス転送で転送するので、パスの設定を
行なっていない機器（ノード）同士を接続した場合、何
も信号の送受を行なうことができず、機器として動作で
きないこととなる。そこで、本発明のｍＬＡＮにおいて
プラグ・アンド・プレイを実現するために、Well-known
チャンネルを定義する。初期状態においては、特定の
プロトコルを特定のチャンネル番号で送受する。これに
より、取りあえずデータの送受をプロトコルごとに行な
うことができる。

【０１３６】Well-known チャンネルは、パス情報がま
ったく設定されてない場合においての動作を保証するも
のであるが、パス情報が設定されているネットワークに
おいて新たな機器（ノード）が参入された場合にも、何
もデータを送受できないことが起こりえる。受信の場合
は、ノード追加時に発生されるバスリセットに応じて、
トーカー情報報告パケットがブロードキャストされるの
で、それを元にトーカーとバインドされているチャンネ
ル番号を検出し、対応するプロトコルのトーカーに対応
するリスナー・ポートを複数作成することにより、受信
することができる。この場合、上位層のアプリケーショ
ンは、それらの複数のポートからの情報をミックスして
利用することになる。送信の場合は、リスナーの状態に
影響を与えることなく、情報を受信させることが不可能
であるので、この場合は何も行なわない。

【０１３７】なお、ＭＩＤＩメッセージはそのままパケ
ット化して転送することが効率の上からは良い。また、
リアルタイム性が必要とされず、信頼性が要求されるよ
うなデータについては、例えば通常のファイル転送のよ
うな別プロトコルとして転送しても良い。また、ディジ
タル・オーディオデータはストリームとしてアイソクロ
ナス転送方式で転送するのが好適である。

【０１３８】

【発明の効果】本発明は以上のように構成されているの
で、物理的な接続形態に依存しない仮想的な経路 (論理
的なパス) をネットワークの内部に構築することができ
る。すなわち、そのネットワークに接続されていれば、
それぞれの機器の位置関係に関係なく２つの機器間に経
路を設定し、その経路を使ってデータを交換することが
できる。これによって接続形態に関わらず仮想的な経路
を確立することができるので、例えば機器の繋ぎ順を間
違えることがなくデータを転送できないというミスがな
くなる。また、論理的に接続されているため、物理的な
接続を変更せずに機器間の接続を変更することができる
ようになる。

【０１３９】仮想的な経路のパス情報はネットワークに
接続されている各機器がそれぞれ記憶する。そして、ネ
ットワーク内の全てのパス情報を一括して別メディアに
保存すれば、再構成を行なう場合でもそれをネットワー
クにロードすることによって素早く正確に構成を再現す
ることができる。さらに、本発明はこのようなネットワ
ークにおいて、所定の帯域を確保してデータを伝送する
ことのできるアイソクロナス転送に加えて、転送データ
がある時に指定された複数のノードにデータの転送を行
えるマルチキャスト転送を行うこともできる。したがっ
て、離散的なデータか否かにかかわらず、効率的な伝送
を可能とすることができる。すなわち、リアルタイム性
を要求されるＭＩＤＩデータやオーディオデータ等を効
率よく伝送することができるようになる。

【図面の簡単な説明】

【図１】 本発明のｍＬＡＮの通信形態の概要を示す図
である。

【図２】 本発明のｍＬＡＮのプロトコル階層を示す図
である。

【図３】 マルチキャスト転送を説明するための図であ
る。

【図４】 パス情報テーブルのフォ−マットを示す図で
ある。

【図５】 ノード情報テーブルのフォ−マットを示す図
である。

【図６】 マルチキャスト情報テーブルのフォ−マット
を示す図である。

【図７】 アイソクロナス情報テーブルのフォ−マット
を示す図である。

【図８】 ポート情報エントリーのフォ−マットを示す
図である。

【図９】 トーカー情報報告パケットのフォ−マットを
示す図である。

【図１０】 アイソクロナス・マネージャにおけるアイ
ソクロナス・リソースの確保とバインド処理のフローチ
ャートを示す図である。

【図１１】 アイソクロナス・マネージャにおけるアイ
ソクロナス・リソース・バインド処理のフローチャート
を示す図である。

【図１２】 アイソクロナス・マネージャにおけるアイ
ソクロナス送信データ受付処理およびアイソクロナス送
信処理のフローチャートを示す図である。

【図１３】 アイソクロナス・マネージャにおけるアイ
ソクロナス受信処理およびトーカー重複検出処理のフロ
ーチャートを示す図である。

【図１４】 アイソクロナス・マネージャにおけるトー
カー情報変更処理のフローチャートを示す図である。

【図１５】 アイソクロナス・マネージャにおけるバス
リセット対応処理のフローチャートを示す図である。

【図１６】 アイソクロナス・マネージャにおけるバス
リセット完了通知受信処理のフローチャートを示す図で
ある。

【図１７】 マルチキャスト・マネージャにおけるマル
チキャスト・リソースの確保とバインド処理のフローチ
ャートを示す図である。

【図１８】 マルチキャスト・マネージャにおけるマル
チキャスト・リソース・バインド処理のフローチャート
を示す図である。

【図１９】 マルチキャスト・マネージャにおけるマル
チキャスト送信処理のフローチャートを示す図である。

【図２０】 マルチキャスト・マネージャにおけるマル
チキャスト受信処理のフローチャートを示す図である。

【図２１】 マルチキャスト・マネージャにおけるトー
カー情報変更処理のフローチャートを示す図である。

【図２２】 マルチキャスト・マネージャにおけるバス
リセット対応処理のフローチャートを示す図である。

【図２３】 マルチキャスト・マネージャにおけるバス
リセット完了通知受信処理のフローチャートを示す図で
ある。

【図２４】 ＰＩＭにおけるパスの設定処理のフローチ
ャートを示す図である。

【図２５】 ＰＩＭにおけるパスに対するデータ送信処
理のフローチャートを示す図である。

【図２６】 ＰＩＭにおけるパスの解放処理のフローチ
ャートを示す図である。

【図２７】 ＰＩＭにおけるバスリセット対応処理のフ
ローチャートを示す図である。

【図２８】 ＰＩＭにおける各種不成功通知処理のフロ
ーチャートを示す図である。

【図２９】 ＰＩＭにおけるトーカー情報変更処理のフ
ローチャートを示す図である。

【図３０】 ＮＩＭにおけるポート情報問い合わせ処理
のフローチャートを示す図である。

【図３１】 ＮＩＭにおけるトーカー情報報告パケット
処理のフローチャートを示す図である。

【図３２】 ＮＩＭにおけるバスリセット対応処理のフ
ローチャートを示す図である。

【図３３】 ＮＩＭにおけるバスリセット完了時処理の
フローチャートを示す図である。

【図３４】 本発明のｍＬＡＮのサイクルストラクチャ
ーの一例を示す図である。

【図３５】 従来のネットワークのプロトコル階層を示
す図である。

【符号の説明】

１−Ｔ１，３−Ｔ１ 送信ポート、２−Ｒ１，４−Ｒ
１，４−Ｒ２ 受信ポート、ＰＩＭ パス情報管理、Ｎ
ＩＭ ノード情報管理、ＭＣ マルチキャスト、ＩＳＯ
アイソクロナス

Claims (4)

【特許請求の範囲】
1. 【請求項１】 複数のノードと、該複数のノードが接
   続されると共に、該ノード間を接続する論理的なパスが
   構築されるバスにより構成されるネットワークにおい
   て、 前記ノードの各々は、少なくとも１つのポートを有し、
   該ポートのタイプとして、アイソクロナス・チャンネル
   番号と所定の帯域がバインドされたアイソクロナス・ト
   ーカー、アイソクロナス・チャンネル番号がバインドさ
   れたアイソクロナス・リスナー、マルチキャスト・チャ
   ンネル番号がバインドされたマルチキャスト・トーカ
   ー、およびマルチキャスト・チャンネル番号がバインド
   されたマルチキャス・トリスナーのタイプが少なくとも
   用意されていることを特徴とするネットワーク。
2. 【請求項２】 前記バスに構築された論理的なパスが
   リセットされた場合、アイソクロナス・トーカー及びマ
   ルチキャスト・トーカーが、それぞれ獲得したリソース
   情報をトーカー情報報告パケットとしてブロードキャス
   トし、各ノードはこのトーカー情報報告パケット、およ
   び受信側のノード上で保持されているパス情報に基づい
   て、前記論理的パスを再構築することを特徴とする請求
   項１記載のネットワーク。
3. 【請求項３】 トランスポート層が少なくとも、前記
   各ノードで獲得されたアイソクロナス・リソース情報
   と、該アイソクロナス・リソースのバインド情報を管理
   するアイソクロナス・マネージャと、前記各ノードで獲
   得されたマルチキャスト・リソース情報と、該マルチキ
   ャスト・リソース情報のバインド情報を管理するマルチ
   キャスト・マネージャと、マルチキャスト転送やアイソ
   クロナス転送を行うポート間に前記論理的なパスを設定
   するサービスを上位層に対して提供すると共に、設定さ
   れたパスの管理を行うパス情報管理（ＰＩＭ）とを含む
   ことを特徴とするネットワーク。
4. 【請求項４】 複数のノードが接続されると共に、該
   ノード間を接続する論理的なパスが構築されるバスによ
   りデータを伝送するデータ伝送方法において、 １転送サイクルが、アイソクロナス・チャンネルを用い
   た所定の帯域のデータを転送するアイソクロナス転送
   と、マルチキャスト・チャンネルを用いたマルチキャス
   ト転送からなり、 転送すべきデータを、データの性質や前記チャンネルの
   空き状態に応じた前記アイソクロナス転送あるいは前記
   マルチキャスト転送により伝送することを特徴とするデ
   ータ伝送方法。