(57)【要約】【課題】  バスリセット後、送信元ノードＩＤが確定していない期間に同一チャネル番号を有する二つまたはそれ以上のアイソクロナスパケットを受信した場合にもそれらを区別し、所望のパケットだけを受信可能な送受信装置を提供する。【解決手段】  アイソクロナスパケットの受信ノードはパケットを受信開始する前に送信ノードのコンフィグレーションＲＯＭ１５内にあるｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを確認する。送信ノードは送信するアイソクロナスパケット内に自ノードのｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを挿入して送信する。受信ノードは前もって識別情報格納部１６に格納しておいたｒｏｍ＿ｃｒｃ＿ｖａｌｕｅと、受信したアイソクロナスパケット内のｒｏｍ＿ｃｒｃ＿ｖａｌｕｅとの一致を確認することで、バスリセット等の要因で他のノードから同一チャネルのアイソクロナスパケットを受信しても、それらを識別することが可能となる。【選択図】      図１                                                  
2005229230.tif 000002
【特許請求の範囲】
【請求項１】
規則的な間隔でバス全体に転送するアイソクロナスパケットの送受信機能を含むパケット送受信装置であって、前記アイソクロナスパケットの送信時に当該パケット内にバスリセットで変化しない送信元の識別情報を格納する手段を有することを特徴とするパケット送受信装置。
【請求項２】
自ノードの特徴及び機能を示す情報を少なくとも格納するコンフィグレーション格納媒体を含み、
前記送信元の識別情報を格納する手段は、前記アイソクロナスパケット内部の所定の領域に前記コンフィグレーション格納媒体内の識別情報を格納するとともに、所定プロトコルのヘッダを付加してパケット化することを特徴とする請求項１記載のパケット送受信装置。
【請求項３】
前記アイソクロナスパケットの受信時に予め送信元の識別情報を保持する識別情報格納領域と、前記アイソクロナスパケットの受信時に当該パケット内部の所定の領域から抜き出した識別情報と前記識別情報格納領域に保持された識別情報とを比較して前記送信元を確認する手段とを含むことを特徴とする請求項１または請求項２記載のパケット送受信装置。
【請求項４】
前記識別情報は、予め設定された所定領域のデータのＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）値を示すｒｏｍ＿ｃｒｃ＿ｖａｌｕｅの少なくとも一部であることを特徴とする請求項１から請求項３のいずれか記載のパケット送受信装置。
【請求項５】
規則的な間隔でバス全体に転送するアイソクロナスパケットの送受信機能を含むパケット送受信装置のパケット識別方法であって、前記パケット送受信装置側に、前記アイソクロナスパケットの送信時に当該パケット内にバスリセットで変化しない送信元の識別情報を格納するステップを有することを特徴とするパケット識別方法。
【請求項６】
自ノードの特徴及び機能を示す情報を少なくとも格納するコンフィグレーション格納媒体を前記パケット送受信装置に含み、
前記送信元の識別情報を格納するステップは、前記アイソクロナスパケット内部の所定の領域に前記コンフィグレーション格納媒体内の識別情報を格納するとともに、所定プロトコルのヘッダを付加してパケット化することを特徴とする請求項５記載のパケット識別方法。
【請求項７】
前記アイソクロナスパケットの受信時に予め送信元の識別情報を保持する識別情報格納領域を前記パケット送受信装置に含み、
前記パケット送受信装置側に、前記アイソクロナスパケットの受信時に当該パケット内部の所定の領域から抜き出した識別情報と前記識別情報格納領域に保持された識別情報とを比較して前記送信元を確認するステップを含むことを特徴とする請求項５または請求項６記載のパケット識別方法。
【請求項８】
前記識別情報は、予め設定された所定領域のデータのＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）値を示すｒｏｍ＿ｃｒｃ＿ｖａｌｕｅの少なくとも一部であることを特徴とする請求項５から請求項７のいずれか記載のパケット識別方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパケット送受信装置及びそれに用いるパケット識別方法に関し、特に同一チャネルのアイソクロナス（Ｉｓｏｃｈｒｏｎｏｕｓ）パケットが存在するバスにて受信すべきアイソクロナスパケットを識別する方法に関する。
【背景技術】
【０００２】
コンピュータの性能は年々加速化し、それに合わせて記憶装置等の周辺装置もますます高度化している。従来、家電製品とコンピュータ製品とは明確に区分されてきたが、近年、コンピュータの家電化と家電製品のディジタル化とが進み、両者互いに共存することができる環境が必要となっている。
【０００３】
このような背景において、高速かつ大容量のデータ転送を実現することができるインタフェースとしてＩＥＥＥ（Ｔｈｅ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ）１３９４で標準化された高速シリアルバス（以下、ＩＥＥＥ１３９４バスとする）があげられる（例えば、非特許文献１参照）。
【０００４】
ＩＥＥＥ１３９４バスの大きな特徴としては、電源を切ることなく、ＩＥＥＥ１３９４バスのネットワークに新しくノードを追加したり、取り外したりすることができることがある。ＩＥＥＥ１３９４ではＩＥＥＥ１２１２規格にしたがった６４ビット固定アドレシングを採用している。
【０００５】
ＩＥＥＥ１３９４のアドレスマップを図７に示す。図７において、アドレスマップの上位１６ビットはＮＯＤＥ＿ＩＤ（識別情報）４０１を示す。ＮＯＤＥ＿ＩＤ４０１は、さらに上位１０ビットのＢＵＳ＿ＩＤ４０２と、下位６ビットのＰＨＹ（Ｐｈｙｓｉｃａｌ）＿ＩＤ４０３とに分けられる。
【０００６】
ＢＵＳ＿ＩＤ４０１は「０」から「１０２３」までを指定することができるが、「１０２３」はローカルバス４０４（データ転送元であるノードに直接接続されているバス）を示す。また、ＰＨＹ＿ＩＤ４０３は「０」から「６３」までを指定することができるが、「６３」はブロードキャスト４０５（バス内で接続されている全てのノードに宛てられるデータ）を示す。
【０００７】
よって、ＩＥＥＥ１３９４においては、バス数が「１０２３」、各々のバスに「６３」のノード、合計６４４４９台の接続が可能である。各々のノードに割り当てられたアドレス空間は、残りの４８ビット（２５６テラバイト）である。「０」から「ＦＦＦＦ＿ＤＦＦＦ＿ＦＦＦＦ（１６進法）」にメモリ空間４０８、「ＦＦＦＦ＿Ｅ０００＿００００（１６進法）」から「ＦＦＦＦ＿ＥＦＦＦ＿ＦＦＦＦ（１６進法）」にプライベート空間４０７、「ＦＦＦＦ＿Ｆ０００＿００００（１６進法）」から「ＦＦＦＦ＿ＦＦＦＦ＿ＦＦＦＦ（１６進法）」にレジスタ空間４０６がそれぞれ割り当てられる。
【０００８】
ＩＥＥＥ１３９４のレジスタはＩＥＥＥ１２１２で規格されているＣＳＲ（Ｃｏｎｔｒｏｌ  ａｎｄ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒｓ）アーキテクチャの採用しているスタイルによって規定されている。ＣＳＲは、レジスタ空間の「０００＿００００（１６進法）」から「０００＿０１ＦＦ（１６進法）」までをＣＳＲコアと基本的なレジスタ空間４０９とによって構成されている。
【０００９】
続けて、「０００＿０２００（１６進法）」から「０００＿０３ＦＦ（１６進法）」までをバス依存の用途４１０で予約している。さらに、「０００＿０８００（１６進法）」以降の空間も初期ユニットの中にノード依存のリソースのための空間４１２として予約している。
【００１０】
トランザクション対応のノードは、コンフィグレーション（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）空間４１１にノードの特徴や機能を示す情報を実装しなくてはならない。
【００１１】
一般的なコンフィグレーションＲＯＭのフォーマットを図８に示す。ＩＥＥＥ１３９４では、最初の５クワドレット（ｑｕａｄｌｅｔ）（１クワドレット＝４バイト）はこの形式とするように規定されている。また、６クワドレット目以降は機器を構成している機能によって変化する。
【００１２】
この中で、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ５０２は「ＦＦＦＦ＿Ｆ０００＿０４００番地」からｃｒｃ＿ｌｅｎｇｔｈ５０１で示されている番地までのデータのＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）値を示しており、ＩＥＥＥ１２１２では、コンフィグレーションＲＯＭ全体をｃｒｃ＿ｌｅｎｇｔｈ５０１及びｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ５０２によって保護することが推奨されている。
【００１３】
また、ｎｏｄｅ＿ｖｅｎｄｅｒ＿ＩＤ５０３、ｃｈｉｐ＿ＩＤ＿ｈｉ５０４、ｃｈｉｐ＿ＩＤ＿ｌｏ５０５をあわせてＥＵＩ（Ｅｘｔｅｎｄｅｄ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）−６４Ｂｉｔと呼び、このフィールドが一致する機器は二つと存在しない。よって、同等の機能を所有し、他のフィールドが同じコンフィグレーションＲＯＭを有する機器も、ＥＵＩ−６４が必ず違うため、基本的にはｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ５０２も一致しない。
【００１４】
ＩＥＥＥ１３９４バス上では、パケットを転送するプロセスをサブアクション（ｓｕｂａｃｔｉｏｎ）と呼び、大きく分けて下記に示す二種類が存在する。一つはアイソクロナス（Ｉｓｏｃｈｒｏｎｏｕｓ）サブアクションと呼ばれ、ＩＥＥＥ１３９４バスの特徴でもあるパケットを規則的な間隔で転送するという機能を持っている。このサブアクションでは、特定のノードに転送するのでなく、チャネルを使用してバス全体に転送する。
【００１５】
アイソクロナスサブアクションの主な用途として、ＩＥＣ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ  Ｃｏｍｍｉｓｓｉｏｎ）６１８８３で規定されているような、ディジタルＡＶ機器間の映像やオーディオの転送が挙げられる。
【００１６】
もう一つは非同期（Ａｓｙｎｃｈｒｏｎｏｕｓ）サブアクションと呼ばれる、非同期の転送方法である。非同期サブアクションはアイソクロナスサブアクションとは異なり、規則的な間隔でデータを転送することはできない。数バイトのヘッダ情報と実データとを指定されたノードに転送し、データを受信したノードは必ず認識パケット（Ａｃｋｎｏｗｌｅｄｇｅ  Ｐａｃｋｅｔ）を返す。
【００１７】
但し、転送先ＰＨＹ＿ＩＤが６３のブロードキャストや、ＩＥＥＥ１３９４−１９９５の拡張規格であるＩＥＥＥ１３９４ａ−２０００から定義されているアシンクロナスストリームパケット（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｓｔｒｅａｍ  Ｐａｃｋｅｔ）等の認識パケットを必要としないサブアクションの場合には、認識パケットを返さない。
【００１８】
アイソクロナスパケットを送信したいノードは、ＩＲＭ（Ｉｓｏｃｈｒｏｎｏｕｓ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｒ）内のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスしてチャネル番号を確保し、また、ＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスして帯域を確保することによって、初めてＩＥＥＥ１３９４バス上にアイソクロナスパケットを送信することができる。以下、チャネルと帯域とを合わせてアイソクロナスリソースと記す。
【００１９】
ＩＥＥＥ１３９４バスに新しいノードが接続された時や、バスからノードが外れた時には、バスリセットと呼ばれるバスのイニシャライズが行われ、バス上のすべてのノードＩＤが新たに割振られ、ＩＲＭが確定する。バスリセット発生後、アイソクロナスパケットの送信を続けるノードは、ＩＲＭが確定したら、再度、上記のアイソクロナスリソースを確保するためのアクセスを実行しなければならない。
【００２０】
しかしながら、バスリセット発生前にアイソクロナスパケットを送信していたノードは、バスリセットが発生してから１秒間の間、新規アイソクロナスリソースの確保前でもバスリセット前に確保していたアイソクロナスリソースを使用してアイソクロナスパケットを送信し続けることが許されている。
【００２１】
図９にＩＥＥＥ１３９４及びＩＥＣ６１８８３で規定されているアイソクロナスパケットのフォーマットを示す。ＩＥＥＥ１３９４では、アイソクロナスパケット３１０のフォーマットとして、パケットヘッダ３０１、ヘッダＣＲＣ３１１、データペイロード３１２、データＣＲＣ３１３の構成となっている。また、ＩＥＣ６１８８３にて、データペイロード３１２の先頭２クワドレット（８バイト）の領域をＣＩＰ（Ｃｏｍｍｏｎ  Ｉｓｏｃｈｒｏｎｏｕｓ  Ｐａｃｋｅｔ）ヘッダ３０４とすることが規定されている。
【００２２】
パケットヘッダ３０１の中に、上記のチャネル番号を示すｃｈａｎｎｅｌフィールド３１４があり、パケットを受信するノードはこのｃｈａｎｎｅｌフィールド３１４を見て、受信したいパケットを判断する。また、ＣＩＰヘッダ３０４の中に、送信元のノードＩＤ（ノード番号）を示すＳＩＤフィールド３１５があり、ＩＥＣ６１８８３で規定されたパケットを受信するノードは、このＳＩＤフィールド３１５を見ることによって、受信中のパケットを送信しているノードのノードＩＤを特定することができる。
【００２３】
【特許文献１】特開平１１−３０８２５５号公報
【非特許文献１】「ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  ａ  Ｈｉｇｈ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｓｅｒｉａｌ  Ｂｕｓ」（ＩＥＥＥ１３９４）
【発明の開示】
【発明が解決しようとする課題】
【００２４】
上述した従来のパケット認識方法では、例えば、別の二つのＩＥＥＥ１３９４バス上で、同一のチャネル番号でアイソクロナスパケットが流れていた時に、それらのバスを接続するとバスリセットが発生するが、それからＩＲＭが確定してチャネルや帯域を確保するまでの間、同一バスで、同一チャネル番号の二つのアイソクロナスパケットが転送されることになる。この場合、バスリセット前までアイソクロナスパケットを受信していたノードは、同一チャネルのどちらのパケットを受信して良いか、判断する手段がない。
【００２５】
また、従来のパケット認識方法では、バスリセットに付随したイニシャライズによって、送信元のノードＩＤも変化している可能性が高いため、ＣＩＰヘッダ５０４内のＳＩＤフィールド５１５からも確定することができないという問題がある。
【００２６】
そこで、本発明の目的は、上記の問題点を解消し、バスリセット後、送信元ノードＩＤが確定していない期間に同一チャネル番号を有する二つまたはそれ以上のアイソクロナスパケットを受信した場合にもそれらを区別し、所望のパケットだけを受信することができるパケット送受信装置及びそれに用いるパケット識別方法を提供することにある。
【課題を解決するための手段】
【００２７】
本発明によるパケット送受信装置は、規則的な間隔でバス全体に転送するアイソクロナスパケットの送受信機能を含むパケット送受信装置であって、前記アイソクロナスパケットの送信時に当該パケット内にバスリセットで変化しない送信元の識別情報を格納する手段を備えている。
【００２８】
本発明によるパケット識別方法は、規則的な間隔でバス全体に転送するアイソクロナスパケットの送受信機能を含むパケット送受信装置のパケット識別方法であって、前記パケット送受信装置側に、前記アイソクロナスパケットの送信時に当該パケット内にバスリセットで変化しない送信元の識別情報を格納するステップを備えている。
【００２９】
すなわち、本発明のパケット識別方法は、アイソクロナス（Ｉｓｏｃｈｒｏｎｏｕｓ）パケット内にバスリセットで変化しない送信元の個別情報を格納することにより、パケットを受信するノードは受信すべきアイソクロナスパケットと他のノードから送信された同一チャネルで別のアイソクロナスパケットとを区別できる機構を設けたことを特徴としている。ここで、アイソクロナスパケットとは規則的な間隔で転送するパケットであり、特定のノードに転送されるのでなく、チャネルを使用してバス全体に転送されるパケットである。
【００３０】
本発明のパケット識別方法では、送信するノードがアイソクロナスパケット内に自ノードのｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを挿入し、受信するノードがそのフィールドを確認するという動作を実行する。したがって、バスリセット後、以前まで受信していたチャネルを有するアイソクロナスパケットが２つ存在した場合も、継続して以前まで受信していたパケットを受信することが可能となる。
【発明の効果】
【００３１】
本発明は、以下に述べるような構成及び動作とすることで、バスリセット後、送信元ノードＩＤが確定していない期間に同一チャネル番号を有する二つまたはそれ以上のアイソクロナスパケットを受信した場合にもそれらを区別し、所望のパケットだけを受信することができるという効果が得られる。
【発明を実施するための最良の形態】
【００３２】
次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例による送受信装置の構成を示すブロック図である。図１においては、本発明の一実施例の形態として、アイソクロナス（Ｉｓｏｃｈｒｏｎｏｕｓ）パケット識別機能を搭載した送信回路及び受信回路を搭載した装置の構成例を示している。
【００３３】
つまり、本発明の一実施例による送受信装置はリンク（Ｌｉｎｋ）層１と、ＣＰＵ（中央処理装置）２と、ＡＶコーデック（Ｃｏｄｅｃ）３と、物理層（ＰＨＹ：Ｐｈｙｓｉｃａｌ）４とから構成されている。
【００３４】
リンク層１はホスト（Ｈｏｓｔ）Ｉ／Ｆ（インタフェース）１１と、アプリケーション（ＡＰ）Ｉ／Ｆ１２と、非同期パケットコントローラ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｐａｃｋｅｔ  Ｃｏｎｔｒｏｌｌｅｒ）１３と、ＣＳＲ（Ｃｏｎｔｒｏｌ  ａｎｄ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒｓ）１４と、コンフィグレーション（Ｃｏｎｓｉｇｕｒａｔｉｏｎ）ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）（以下、コンフィグＲＯＭとする）１５と、識別情報格納部（Ｓｏｕｒｃｅ  ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ）１６と、パケット変換部（Ｐａｃｋｅｔｉｚｅｒ）１７と、送信データバッファ（Ｔｘ  Ｄａｔａ  Ｂｕｆｆｅｒ）１８と、受信フィルタ（Ｒｘ  Ｆｉｌｔｅｒ）１９と、受信データバッファ（Ｒｘ  Ｄａｔａ  Ｂｕｆｆｅｒ）２０と、リンクコア（Ｌｉｎｋ  Ｃｏｒｅ）２１とから構成されている。
【００３５】
ホストＩ／Ｆ１１はＣＰＵ２とデータを送受信するインタフェースを持ち、ファームウェア（以下、Ｆ／Ｗとする）から非同期（Ａｓｙｎｃｈｏｎｏｕｓ）パケットの送受信や、ＣＳＲ１４、コンフィグＲＯＭ１５等の設定を行う際に動作する。アプリケーションＩ／Ｆ１２はＡＶコーデック３等、ストリームデータをアイソクロナス（Ｉｓｏｃｈｒｏｎｏｕｓ）で送受信するデータを使用するブロックと、ディジタルデータやその他必要な信号を受け渡しするブロックとからなる。
【００３６】
非同期パケットコントローラ１３は非同期パケットの送受信を行い、またそのために必要な情報を各ブロックから受取ったり、結果を各ブロックに反映したりするブロックである。ＣＳＲ１４は図７に示すＣＳＲ  ｃｏｒｅ４０９やＳｅｒｉａｌ  Ｂｕｓ  Ｄｅｐｅｎｄｅｎｔ４１０等、ＩＥＥＥ１３９４バスからアクセス可能なレジスタを備えているブロックである。
【００３７】
コンフィグＲＯＭ１５はノードの特徴や機能を示す情報を実装するブロックである。一般的なコンフィグＲＯＭ１５のフォーマットは、上述したように、図８に示すような構成となる。ＩＥＥＥ１３９４では、最初の５クワドレット（ｑｕａｄｌｅｔ）（１クワドレット＝４バイト）はこの形式とするように規定されている。また、６クワドレット目以降は機器を構成している機能によって変化する。
【００３８】
識別情報格納部１６はアイソクロナスパケットを受信する時に必要なブロックであり、受信すべきアイソクロナスパケットの送信元ノードから読出したｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを格納しておくブロックである。ここで、アイソクロナスパケットとは規則的な間隔で転送するパケットであり、特定のノードに転送されるのでなく、チャネルを使用してバス全体に転送されるパケットである。
【００３９】
また、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅは、上述したように、「ＦＦＦＦ＿Ｆ０００＿０４００番地」からｃｒｃ＿ｌｅｎｇｔｈで示されている番地までのデータのＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）値を示しており、ＩＥＥＥ１２１２では、コンフィグレーションＲＯＭ１５全体をｃｒｃ＿ｌｅｎｇｔｈ及びｒｏｍ＿ｃｒｃ＿ｖａｌｕｅによって保護することが推奨されている。
【００４０】
パケット変換部１７は送信するストリームデータに、図９に示すＣＩＰ（Ｃｏｍｍｏｎ  Ｉｓｏｃｈｒｏｎｏｕｓ  Ｐａｃｋｅｔ）ヘッダ３０４、パケットヘッダ３０１と、さらに自ノードのｒｏｍ＿ｃｒｃ＿ｖａｌｕｅとを挿入し、アイソクロナスパケットのフォーマットに整形するブロックである。
【００４１】
送信データバッファ１８はアプリケーションＩ／Ｆ１２から受信したデータをアイソクロナスパケット内に入れるために格納しておくＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）方式のバッファを持つブロックである。
【００４２】
受信フィルタ１９は受信したアイソクロナスパケットから、パケットヘッダと、ＣＩＰヘッダと、さらにｒｏｍ＿ｃｒｃ＿ｖａｌｕｅとを比較して受信すべきパケットであれば受信し、受信すべきパケットでなければ破棄するといった、パケットを選別するブロックである。
【００４３】
受信データバッファ２０は受信フィルタ１９を通過して受信したデータを格納し、アプリケーションＩ／Ｆ１２へ渡すブロックである。リンクコア２１は物理層４とのインタフェースを持ち、トランザクションの管理を行うブロックである。
【００４４】
ＣＰＵ２は非同期パケットの送受信や、ＣＳＲ等、各ブロックの初期化等、装置の管理を行う。ＩＥＣ６１８８３であれば、実際にＡＶコマンドの送受信や、プラグのコネクションの管理を行う。ＡＶコーデック３は映像や音声をエンコードして送信するデータを生成し、またアプリケーションＩ／Ｆ１２から受信したデータをデコードして映像データや音声データを生成するブロックである。
【００４５】
物理層４はＩＥＥＥ１３９４の物理層のハードウェア（以下、Ｈ／Ｗとする）である。ＩＥＥＥ１３９４バス１００はその接続先に別のノード（図示せず）が接続されており、実際に非同期パケットやアイクロナスパケットが流れるバスである。
【００４６】
次に、アイクロナスパケットの送信回路について説明する。アイクロナスパケットを送信するノードは、ＩＲＭ（Ｉｓｏｃｈｒｏｎｏｕｓ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｒ）からアイクロナスリソースを確保したら、パケット変換部１７にて獲得したリソースの情報や送信するデータにパケットヘッダやＣＩＰヘッダを挿入し、またコンフィグＲＯＭ１５からｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを挿入してアイクロナスパケットを生成し、そのアイクロナスパケットを送信する。この動作は送信する全てのアイクロナスパケットにおいて同じ動作となる。
【００４７】
続いて、アイクロナスパケットの受信回路について説明する。アイクロナスパケットを受信するノードはプラグのコネクション等によって受信するパケットの送信元が決定したら、先ず送信ノードのｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを読出すために、Ｒｅａｄ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔなる非同期パケットを送信する。
【００４８】
図２はＲｅａｄ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔなる非同期パケットのフォーマットを示す図である。図２において、パケットを送信する相手のノードＩＤ（識別情報）を示すｄｅｓｔｉｎａｔｉｏｎ＿ＩＤ１０１は、この場合、アイソクロナスパケットを送信するノードのノードＩＤとなる。
【００４９】
トランザクションラベル（ｔｌ）１０２はトランザクションにつけられる任意のラベルである。リトライコード（ｒｔ）１０３はＩＥＥＥ１３９４で規定されているリトライの種類を示すフィールドである。トランザクションコード（ｔｃｏｄｅ）１０４はパケットの種類を示しており、Ｒｅａｄ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔは（０１００）である。プライオリティ（ｐｒｉ）１０５はケーブル環境では特に使用しない。
【００５０】
パケット送信元のノードＩＤを示すｓｏｕｒｃｅ＿ＩＤ１０６は、この場合、アイソクロナスパケットを受信するノードＩＤとなる。ｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔ１０７は送信先のオフセットアドレスを示しており、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを読む場合には「ＦＦＦＦ＿Ｆ０００＿０４００（１６進法）」が入る。ｈｅａｄｅｒ＿ＣＲＣ１０８はｄｅｓｔｉｎａｔｉｏｎ＿ＩＤ１０６からｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔ１０７までのデータのＣＲＣ値が入る。
【００５１】
上述したＲｅａｄ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔ形式の非同期パケットを受けたノード、つまりアイソクロナスパケットを送信するノードは、Ｒｅａｄ  Ｒｅｓｐｏｎｓｅ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔなる非同期パケットにて応答する。
【００５２】
図３はＲｅａｄ  Ｒｅｓｐｏｎｓｅ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔなる非同期パケットのフォーマットを示す図である。図３において、ｄｅｓｔｉｎａｔｉｏｎ＿ＩＤ２０１は、この場合、アイソクロナスパケットを受信するノードのノードＩＤとなる。
【００５３】
トランザクションラベル（ｔｌ）２０２は、図２に示すトランザクションラベル（ｔｌ）１０２と同様であるが、Ｒｅｓｐｏｎｓｅパケット内のこのフィールドは先に受信したＲｅｑｕｅｓｔパケット内のトランザクションラベル（ｔｌ）１０２を挿入する。リトライコード（ｒｔ）２０３及びプライオリティ（ｐｒｉ）２０５は、図２に示すリトライコード（ｒｔ）１０３及びプライオリティ（ｐｒｉ）１０５と同様である。
【００５４】
トランザクションコード（ｔｃｏｄｅ）２０４は、Ｒｅａｄ  Ｒｅｓｐｏｎｓｅ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔの（０１１０）である。ｓｏｕｒｃｅ＿ＩＤ２０６は、この場合、アイソクロナスを送信するノードのノードＩＤとなる。レスポンスコードを示すｒｃｏｄｅ２０７は、先に受信したＲｅｑｕｅｓｔパケットにエラーがあればその内容を、正常に完了していれば、ｒｅｓｐｏｎｓｅ＿ｃｏｍｐｌｅｔｅを示す「００００」を挿入する。
【００５５】
ｒｅｓｅｒｖｅｄ２０８は予約領域であり、「０００＿００００＿００００（１６進法）」を挿入する。ｑｕａｄｌｅｔ＿ｄａｔａ２０９は、先に受信したＲｅｑｕｅｓｔパケット内に指定されたｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔ１０７にあるデータを挿入する。この場合、先のパケットにて「ＦＦＦＦ＿Ｆ０００＿０４００番地」を求めているので、コンフィグＲＯＭ１５の０番地、つまり、図８に示すｉｎｆｏ＿ｌｅｎｇｔｈ５０１からｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ５０２までの１クワドレットのデータが入る。
【００５６】
受信ノードは、上述した非同期パケットの送受信によってアイクロナスパケットの送信ノードからｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを獲得して識別情報格納部１６に格納する。
【００５７】
これ以降に受信したアイクロナスパケットに関して、図４に示す処理動作にしたがって、アイクロナスパケットを受信する度に、パケットヘッダとＣＩＰヘッダとの識別に加えて、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを識別情報格納部１６に保持された値（Ｓｏｕｒｃｅ  ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ）と比較することによって、より確実にパケットを識別することが可能となる。
【００５８】
図４は本発明の一実施例によるアイクロナスパケットの識別処理を示すフローチャートである。これら図１〜図４を参照して本発明の一実施例によるアイクロナスパケットの識別処理について説明する。
【００５９】
リンク層１ではプラグが接続され（図４ステップＳ１）、アイソクロナスパケットを受信すると（図４ステップＳ２）、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅが取得済かどうかをチェックする（図４ステップＳ３）。
【００６０】
リンク層１はｒｏｍ＿ｃｒｃ＿ｖａｌｕｅが取得済であれば、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅが識別情報格納部１６に保持された値と一致するかをチェックする（図４ステップＳ４）。
【００６１】
リンク層１はｒｏｍ＿ｃｒｃ＿ｖａｌｕｅが識別情報格納部１６に保持された値と一致すると、そのパケットのヘッダがＯＫであれば（図４ステップＳ５）、受信したパケットを受信データバッファ２０に格納する（図４ステップＳ６）。
【００６２】
また、リンク層１はｒｏｍ＿ｃｒｃ＿ｖａｌｕｅが識別情報格納部１６に保持された値と一致しなければ、あるいはそのパケットのヘッダがＯＫでなければ（図４ステップＳ５）、受信したパケットを破棄する（図４ステップＳ７）。
【００６３】
一方、バスリセットが発生し、アイクロナスパケットの送信ノードの機能が追加、もしくは削除されてコンフィグＲＯＭ１５の内容が変わらない限り、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅは変化しないため、一度、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを獲得しておけば、プラグが切断される等に起因されてアイクロナスパケットの受信を止めるまで、識別情報格納部１６に保持された値は有効である。よって、従来の技術では識別できなかった同一チャネルのアイクロナスパケットを、この機能を使用することによって、識別することが可能となる。
【００６４】
図５は本発明の一実施例においてアイクロナスパケット内にｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを格納した例を示す図である。図５において、この格納例では、ＣＩＰヘッダ３０４内に拡張のために予約されている（ｒｅｓｅｒｖｅ）領域が殆どないため、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ３０３はＣＩＰヘッダ３０４の外に挿入されている。
【００６５】
このような場合、ＩＥＣ６１８８３で規定しているフォーマットに対して、パケットサイズが１クワドレット多くなるので、事前に送受信ノード間でＡＶＣコマンド等によって、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ３０３を挿入することを宣言する必要がある。
【００６６】
図６は本発明の一実施例においてアイクロナスパケット内にｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを格納した他の例を示す図である。図６において、この格納例では、ＩＥＣ６１８８３−４（ＭＰＥＧ２−ＴＳ  ｄａｔａ  ｔｒａｎｓｍｉｓｓｉｏｎ）で規定されているフォーマット内に挿入することを想定してあるが、この場合のように、ｒｅｓｅｒｖｅ領域が１６ビット以上ある場合には、そこにｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ３０３を挿入することによって、この機能をサポートしていない機器とも接続することが可能となる。また、ｒｏｍ＿ｃｒｃ＿ｖａｌｕｅ３０３の一部を使用すれば、１６ビット以下のｒｅｓｅｒｖｅ領域への挿入も可能となる。
【００６７】
このように、本実施例では、アイクロナスパケット内にｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを挿入することによって、受信ノードがチャネルに加えて、そのフィールドが同じパケットのみを受信することによって、同一チャネルのほかのパケットを安全にフィルタリングすることができるという効果が得られる。
【００６８】
尚、本発明は上述した実施例に限定されず、本発明の技術思想の範囲内において、実施例が適宜変更され得ることは明らかである。
【図面の簡単な説明】
【００６９】
【図１】本発明の一実施例による送受信装置の構成を示すブロック図である。
【図２】Ｒｅａｄ  Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔなる非同期パケットのフォーマットを示す図である。
【図３】Ｒｅａｄ  Ｒｅｓｐｏｎｓｅ  ｆｏｒ  Ｄａｔａ  Ｑｕａｄｌｅｔなる非同期パケットのフォーマットを示す図である。
【図４】本発明の一実施例によるアイクロナスパケットの識別処理を示すフローチャートである。
【図５】本発明の一実施例においてアイクロナスパケット内にｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを格納した例を示す図である。
【図６】本発明の一実施例においてアイクロナスパケット内にｒｏｍ＿ｃｒｃ＿ｖａｌｕｅを格納した他の例を示す図である。
【図７】ＩＥＥＥ１３９４のアドレスマップを示す図である。
【図８】Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ＲＯＭのフォーマットを示す図である。
【図９】ＩＥＥＥ１３９４及びＩＥＣ６１８８３で規定されているアイクロナスパケットのフォーマットを示す図である。
【符号の説明】
【００７０】
１  リンク層
２  ＣＰＵ
３  ＡＶコーデック
４  物理層
１１  ホストＩ／Ｆ
１２  アプリケーションＩ／Ｆ
１３  非同期パケットコントローラ
１４  ＣＳＲ
１５  コンフィグレーションＲＯＭ
１６  識別情報格納部
１７  パケット変換部
１８  送信データバッファ
１９  受信フィルタ
２０  受信データバッファ
２１  リンクコア
【図１】
2005229230.tif 000003
【図２】
2005229230.tif 000004
【図３】
2005229230.tif 000005
【図４】
2005229230.tif 000006
【図５】
2005229230.tif 000007
【図６】
2005229230.tif 000008
【図７】
2005229230.tif 000009
【図８】
2005229230.tif 000010
【図９】
2005229230.tif 000011