JP2020014050A - 装置 - Google Patents

Abstract

【課題】 正常にフレームを伝送できる装置を実現する。【解決手段】 実施形態によれば、スクランブラを備える外部装置との間で、シリアル・アタッチド・スモール・コンピュータ・システム・インターフェース（ＳＡＳ）のパケットモードでフレームを送受信可能な装置は、デスクランブラとコントローラとを具備する。デスクランブラは、前記スクランブラによってスクランブルされたフレームデータをデスクランブルするように構成される。コントローラは、前記外部装置から、第１フレーム内の第１フィールドに対応する第１フレームデータが受信された場合、前記第１フレームデータと、前記第１フレームデータが前記スクランブラによってスクランブルされる前の第１の値とを用いて、前記デスクランブラを前記スクランブラに同期させる。【選択図】 図６

Description

本発明の実施形態は、シリアル・アタッチド・スモール・コンピュータ・システム・インターフェース（シリアル・アタッチドＳＣＳＩ：ＳＡＳ）を用いて接続される装置に関する。

ＳＡＳは、２つの装置間を接続するためのインターフェース規格の１つである。ＳＡＳでは、例えば、イニシエータ・デバイス（以下、イニシエータとも称する）とターゲット・デバイス（以下、ターゲットとも称する）との間で接続を確立し、コマンドやユーザデータ等を送受信するための仕様が規定されている。

イニシエータとターゲットとはそれぞれ、送受信されるインターフェイスデータのビットの偏りを減少させるための機構であるスクランブラおよびデスクランブラを備える。イニシエータのスクランブラとターゲットのデスクランブラとが同期している場合、イニシエータにより送信され、ターゲットにより受信されるインターフェイスデータは、適切にスクランブル／デスクランブルされる。同様に、ターゲットのスクランブラとイニシエータのデスクランブラとが同期している場合、ターゲットにより送信され、イニシエータにより受信されるインターフェイスデータは、適切にスクランブル／デスクランブルされる。

ＳＡＳ４では、ＳＡＳ Ｇｅｎ５が新たに規格されている。ＳＡＳ Ｇｅｎ５では、ＳＡＳ Ｇｅｎ４でサポートされていたｄｗｏｒｄモードに替わり、パケットモードがサポートされる。ｄｗｏｒｄモードではインターフェイスデータが４０ビット単位で扱われるのに対して、パケットモードではインターフェイスデータが１５０ビット単位で扱われる。

米国特許第８４９９２０５号明細書 米国特許第９４９７０２０号明細書 米国特許出願公開第２０１１／０１４２２３２号明細書

また、ｄｗｏｒｄモードとパケットモードとでは、スクランブラとデスクランブラとが同期されるタイミングが異なっている。ｄｗｏｒｄモードでは、フレームの開始を示すプリミティブの送信に応じてスクランブラが初期化され、このプリミティブの受信に応じてデスクランブラが初期化される。

これに対して、パケットモードでは、ＰＡＣＫＥＴ＿ＳＹＮＣエクステンデッド・バイナリ・プリミティブ（以下、ＰＡＣＫＥＴ＿ＳＹＮＣとも称する）の送信に応じてスクランブラが初期化され、このＰＡＣＫＥＴ＿ＳＹＮＣの受信に応じてデスクランブラが初期化される。ＰＡＣＫＥＴ＿ＳＹＮＣが送受信されるタイミングは、フレームの送受信とは何等関係がない。そのため、予期せぬ動作によってスクランブラとデスクランブラとの同期ずれが発生した場合には、再度、ＰＡＣＫＥＴ＿ＳＹＮＣが送受信されるまで同期ずれが継続し、イニシエータとターゲットとの間で伝送されるフレームにエラーが発生し続ける可能性がある。

本実施形態が解決しようとする課題は、正常にフレームを伝送できる装置を提供することである。

実施形態によれば、スクランブラを備える外部装置との間で、シリアル・アタッチド・スモール・コンピュータ・システム・インターフェース（ＳＡＳ）のパケットモードでフレームを送受信可能な装置は、デスクランブラとコントローラとを具備する。デスクランブラは、前記スクランブラによってスクランブルされたフレームデータをデスクランブルするように構成される。コントローラは、前記外部装置から、第１フレーム内の第１フィールドに対応する第１フレームデータが受信された場合、前記第１フレームデータと、前記第１フレームデータが前記スクランブラによってスクランブルされる前の第１の値とを用いて、前記デスクランブラを前記スクランブラに同期させる。

実施形態に係る装置を含む情報処理システムの構成を示すブロック図。 図１の情報処理システム内で伝送されるインターフェイスデータを説明するための図。 同実施形態の装置によって送受信されるパケットの構成を示す図。 同実施形態の装置における、ＰＡＣＫＥＴ＿ＳＹＮＣが正常に受信される場合と正常に受信されない場合のパケット受信のタイミングチャート。 同実施形態の装置によって、既定値フィールドの値と既定期待値とを用いて受信フレームがデスクランブルされる例を説明するための図。 同実施形態の装置の構成を示すブロック図。 同実施形態の装置に設けられるスクランブラおよびデスクランブラの構成を示すブロック図。 同実施形態の装置で用いられる前進するように遷移するＬＦＳＲと、後退するように遷移するＬＦＳＲとの構成を示す図。 同実施形態の装置によって送受信されるアイデンティファイ・アドレス・フレームのフォーマットの例を示す図。 同実施形態の装置によって、アイデンティファイ・アドレス・フレーム内の既定値フィールドを用いて、線形フィードバック・シフト・レジスタ（ＬＦＳＲ）の状態とスクランブリングデータが算出される例を説明するための図。 図１０の既定値フィールドの値の算出に用いられたスクランブリングデータが生成された時点のＬＦＳＲの状態を復元するための関数の例を示す図。 図１０のアイデンティファイ・アドレス・フレームに後続するＥＯＡＦプリミティブ（以下、ＥＯＡＦとも称する）が受信される時点のＬＦＳＲの状態を算出するための関数の例を示す図。 図１０のアイデンティファイ・アドレス・フレームをデスクランブルするためのスクランブリングデータを算出するための関数の例の第１部分を示す図。 図１３の第１部分に後続する第２部分を示す図。 図１４の第２部分に後続する第３部分を示す図。 図１５の第３部分に後続する第４部分を示す図。 図１６の第４部分に後続する第５部分を示す図。 図１７の第５部分に後続する第６部分を示す図。 同実施形態の装置によって送受信されるオープン・アドレス・フレームのフォーマットの例を示す図。 同実施形態の装置によって、オープン・アドレス・フレーム内の既定値フィールドを用いて、ＬＦＳＲの状態とスクランブリングデータが算出される例を説明するための図。 同実施形態の装置によって、オープン・アドレス・フレーム内の既定値フィールドの値を用いてＬＦＳＲの状態とスクランブリングデータが算出される別の例を説明するための図。 同実施形態の装置によって実行されるアドレス・フレームの送信制御処理の手順の例を示すフローチャート。 同実施形態の装置によって実行されるプリミティブ・セグメント送信処理の手順の例を示すフローチャート。 同実施形態の装置によって実行されるフレーム・セグメント送信処理の手順の例を示すフローチャート。 同実施形態の装置によって実行されるアドレス・フレームの受信制御処理の手順の例を示すフローチャート。 同実施形態の装置によって実行される復元処理の手順の例を示すフローチャート。 同実施形態の装置によって実行されるアドレス・フレームの検証処理の手順の例を示すフローチャート。 同実施形態の装置によって送受信されるシリアル・スモール・コンピュータ・システム・インターフェース・プロトコル（ＳＳＰ）フレームのフォーマットの例を示す図。 同実施形態の装置によって、ＳＳＰフレーム内の既定値フィールドを用いて、ＬＦＳＲの状態とスクランブリングデータが算出される例を説明するための図。 同実施形態の装置によって実行されるＳＳＰフレームの送信制御処理の手順の例を示すフローチャート。 同実施形態の装置によって実行されるＳＳＰフレームの受信制御処理の手順の例を示すフローチャート。 同実施形態の装置によって実行されるＳＳＰフレームの検証処理の手順の例を示すフローチャート。

以下、実施の形態について図面を参照して説明する。
まず、図１を参照して、一実施形態に係る装置を含む情報処理システムの構成を説明する。この情報処理システム１は、ＳＡＳインターフェースにより相互に接続される２つの装置を備える。これら装置の一方はイニシエータ・デバイス（以下、イニシエータとも称する）１０であり、他方はターゲット・デバイス（以下、ターゲットとも称する）２０である。

イニシエータ１０は、例えば、コンピュータ等のホストである。ターゲット２０は、例えば、ＨＤＤ、ＳＳＤ等のストレージデバイスである。イニシエータ１０とターゲット２０とは、ＳＡＳの規定に基づき動作するインターフェース装置１０Ａ，２０Ａをそれぞれ備えている。

イニシエータ１０とターゲット２０とは、インターフェース装置１０Ａ，２０Ａを介して、コマンドやユーザデータ等を送受信することができる。イニシエータ１０とターゲット２０とは、それぞれ、フレームを送信するトランスミッタ・デバイス（Ｔｘ）とフレームを受信するレシーバ・デバイス（Ｒｘ）のいずれとしても動作可能である。伝送されるフレームは、アイデンティファイ・アドレス・フレーム、オープン・アドレス・フレーム、シリアル・スモール・コンピュータ・システム・インターフェース・プロトコル（ＳＳＰ）フレーム、シリアル・マネージメント・プロトコル（ＳＭＰ）フレーム、またはシリアル・アドバンスド・テクノロジー・アタッチメント・トンネルド・プロトコル（ＳＴＰ）フレームである。また、各フレームは、ＣＲＣを含み、フレームデータの信頼性が確保されている。

イニシエータ１０のインターフェース装置１０Ａとターゲット２０のインターフェース装置２０Ａとはそれぞれ、送受信されるインターフェイスデータのビットの偏りを減少させるための機構であるスクランブラおよびデスクランブラを備える。以下では、インターフェース装置１０Ａ，２０Ａが、ＳＡＳ Ｇｅｎ５のスクランブラおよびデスクランブラを備えることを想定する。

ＳＡＳ Ｇｅｎ５の装置であるイニシエータ１０およびターゲット２０では、パケットモードにおいて、スクランブラおよびデスクランブラは以下のように構成される。
（１）ＰＡＣＫＥＴ＿ＳＹＮＣの送信に応じてスクランブラが初期化される。
（２）プリミティブの送信時にスクランブラが動作する。
（３）ＰＡＣＫＥＴ＿ＳＹＮＣの受信に応じてデスクランブラが初期化される。
（４）プリミティブの受信時にデスクランブラが動作する。
（５）フレーム内のｄｗｏｒｄまたはフレーム外のｄｗｏｒｄの送信時に、スクランブラがｄｗｏｒｄをスクランブルし、動作する。
（６）フレーム内のｄｗｏｒｄまたはフレーム外のｄｗｏｒｄの受信時に、デスクランブラがｄｗｏｒｄをデスクランブルし、動作する。

このように、スクランブラは、プリミティブが送信されるときに動作するが、プリミティブをスクランブルしない。また、デスクランブラは、プリミティブが受信されるときに動作するが、プリミティブをデスクランブルしない。

ここで、スクランブラが動作するとは、スクランブラの動作回数が増加し、スクランブラの状態が次の状態に遷移することを意味する。スクランブラは、状態が遷移する毎に、スクランブルのための異なるパターンを生成する。また、デスクランブラが動作するとは、デスクランブラの動作回数が増加し、デスクランブラの状態が次の状態に遷移することを意味する。デスクランブラは、状態が遷移する毎に、デスクランブルのための異なるパターンを生成する。以下では、「スクランブルが動作する」を、「スクランブラがラン（ＲＵＮ）する」とも称する。

イニシエータ１０からターゲット２０に、フレームを構成するフレームデータが送信される場合、イニシエータ１０は、スクランブラによってスクランブルされたフレームデータをターゲット２０に送信し、ターゲット２０は、イニシエータ１０から受信したフレームデータをデスクランブラによってデスクランブルする。同様に、ターゲット２０からイニシエータ１０にフレームデータが送信される場合、ターゲット２０は、スクランブラによってスクランブルされたフレームデータをイニシエータ１０に送信し、イニシエータ１０は、ターゲット２０から受信したフレームデータをデスクランブラによってデスクランブルする。

上述したように、スクランブラとデスクランブラとはそれぞれ、ラン毎に状態が遷移し、それによりスクランブル／デスクランブルに用いられるパターンが切り替わる。スクランブラとデスクランブラとは初期状態からのラン回数が同じであれば、すなわち、スクランブラとデスクランブラとが同期しているならば、同一のパターンを生成する。つまり、スクランブラとデスクランブラとの初期状態からのラン回数が同じあることは、スクランブラとデスクランブラとが同期していることを意味する。なお、スクランブラとデスクランブラとが同期しているか否かは、スクランブラとデスクランブラの各々の状態が遷移する時刻や、各々がパターンを生成する時刻とは何等関係せず、初期状態からのラン回数が同じであるか否かのみに依存する。

図２を参照して、トランスミッタ・デバイス３０とレシーバ・デバイス４０との間で、スクランブルされたデータが送受信される例を説明する。イニシエータ１０とターゲット２０の一方がトランスミッタ・デバイス３０として動作するとき、他方はレシーバ・デバイス４０として動作する。また、イニシエータ１０およびターゲット２０では、レシーバ・デバイス４０としての動作と、トランスミッタ・デバイス３０としての動作が並行して行われてもよい。

トランスミッタ・デバイス３０では、送信される対象のフレームデータ（以下、送信データとも称する）３８１と、スクランブラによって生成されたパターンであるスクランブリングデータ３８２とが排他的論理和（ＸＯＲ）演算されることにより、スクランブルされたデータ３８３が生成される。スクランブルされたデータ３８３は、トランスミッタ・デバイス３０からレシーバ・デバイス４０に送信されるインターフェイスデータである。

レシーバ・デバイス４０では、スクランブルされたデータ３８３と、デスクランブラによって生成されたスクランブリングデータ３８４とがＸＯＲ演算されることにより、受信データ３８５が生成される。トランスミッタ・デバイス３０内のスクランブラとレシーバ・デバイス４０内のデスクランブラとが同期し、スクランブリングデータ３８２，３８４の値が同一であるならば、レシーバ・デバイス４０は、同期ずれに起因する受信エラーが発生していない受信データ３８５を生成することができる。この場合、受信データ３８５は、送信データ３８１がエラーなく復元されたものであり、したがって、送信データ３８１と同一である。なお、受信エラーは、例えば、ＣＲＣエラーである。

しかし、トランスミッタ・デバイス３０のスクランブラとレシーバ・デバイス４０のデスクランブラとの間で同期ずれが発生した場合には、アイドル中に検出する術はなく、フレームの受信時に受信エラーとして検出されることになる。

ところで、ＳＡＳ Ｇｅｎ４の装置では、ｄｗｏｒｄモードにおいて、フレームの開始を示すプリミティブ（例えば、ＳＯＡＦ、ＳＯＦ）の送信に応じてスクランブラが初期化され、このプリミティブの受信に応じてデスクランブラが初期化される。そのため、あるフレームの伝送前のアイドル期間中にスクランブラとデスクランブラとが同期していたか否かが、そのフレームの伝送に影響を与えることはない。

これに対して、ＳＡＳ Ｇｅｎ５の装置では、パケットモードにおいて、ＰＡＣＫＥＴ＿ＳＹＮＣの送信に応じてスクランブラが初期化され、ＰＡＣＫＥＴ＿ＳＹＮＣの受信に応じてデスクランブラが初期化される。ＰＡＣＫＥＴ＿ＳＹＮＣは、例えば、リンクアップの直前にトランスミッタ・デバイス３０からレシーバ・デバイス４０に送信され、リンクアップ後は定期的に送信される。

トランスミッタ・デバイス３０とレシーバ・デバイス４０とは、ＳＡＳ Ｇｅｎ５インターフェースにより接続され、パケットモードにおいて、ＰＡＣＫＥＴ＿ＳＹＮＣのようなプリミティブやフレームデータを含むフレームをパケット単位で送受信することができる。アイデンティファイ・アドレス・フレーム、オープン・アドレス・フレーム、ＳＳＰフレーム、ＳＭＰフレーム、およびＳＴＰフレームは、それぞれ１つ以上のパケットで構成される。

図３は、イニシエータ１０とターゲット２０との間で送受信されるパケット（ＳＡＳプロトコル・レイヤ（ＳＰＬ）パケット）３１の構成を示す。図３に示すように、パケット３１は、１５０ビットのサイズを有し、先頭に配置された２ビットのヘッダ３１１と、１２８ビットのペイロードと、２０ビットのフォワード・エラー・コレクション（ＦＥＣ）コードとを含む。１２８ビットのペイロードは、パケット３１において、１つの２８ビットのペイロード部分３１２と、４つの２５ビットのペイロード部分３１４，３１６，３１８，３２０とに分割されている。また、ＦＥＣコードは、パケット３１において、４つの５ビットのコード部分３１３，３１５，３１７，３１９に分割されている。これら５つのペイロード部分３１４，３１６，３１８，３２０と４つのコード部分３１３，３１５，３１７，３１９とは、パケット３１内で交互に配置されている。

ヘッダ３１１は、ペイロード部分３１２，３１４，３１６，３１８，３２０から構成されるペイロードの種別を特定する。ペイロードは、アイドルｄｗｏｒｄセグメント、プリミティブ・セグメント、スクランブルド・アイドル・セグメント、およびＳＰＬフレーム・セグメントの内のいずれか１つのセグメントを含む。

アイドルｄｗｏｒｄセグメントは、４つのアイドルｄｗｏｒｄを含み、フレーム外で送信される。プリミティブ・セグメントは、プリミティブ、バイナリ・プリミティブ、プリミティブ・パラメータ、またはエクステンデッド・バイナリ・プリミティブを含む。スクランブルド・アイドル・セグメントは、任意の４つのＤａｔａ ｄｗｏｒｄを含む。ＳＰＬフレーム・セグメントは、例えば、アドレス・フレームの４つのＤａｔａ ｄｗｏｒｄを含むアドレス・フレーム・セグメントと、ＳＳＰフレームの４つのＤａｔａ ｄｗｏｒｄを含むＳＳＰフレーム・セグメントのいずれかを含む。

また、コード部分３１３，３１５，３１７，３１９から構成されるＦＥＣコードには、エラー検出およびエラー訂正のためのコードが含まれており、例えば、リード・ソロモン符号が用いられる。

レシーバ・デバイス４０は、受信したパケットにＦＥＣデコード処理を施す。このＦＥＣデコード処理には、ＦＥＣコードを用いた、エラー検出およびエラー訂正のための処理が含まれる。レシーバ・デバイス４０は、ＦＥＣコードを用いてエラーを検出し、当該エラーを訂正できなかった場合、パケットにＦＥＣエラーが発生していると判断し、当該パケットを破棄する。

ＳＡＳ（ＳＡＳ Ｐｒｏｔｏｃｏｌ Ｌａｙｅｒ−４（ＳＰＬ−４））では、レシーバ・デバイス４０内のステートマシンＳＰ＿ＰＳによって受信状態が監視される。このＳＰ＿ＰＳは、特定の回数（例えば、４回）連続して、ＦＥＣエラーが発生しているパケットが受信された場合に、受信パケットの境界を見失ったと判断して、パケット境界の再探索処理が始まり、フレームの受信が不可能な状態になる。しかし、その特定の回数よりも少ない回数（例えば、３回）連続して、ＦＥＣエラーが発生しているパケットを受信したとしても、その直後に受信したパケットにＦＥＣエラーが発生していなければ、フレームの送受信が可能な状態であるＰｈｙ Ｌａｙｅｒ Ｒｅａｄｙが継続され得る。そのため、比較的通信状態が悪く、断続的にパケットにＦＥＣエラーが発生する状態であっても、Ｐｈｙ Ｌａｙｅｒ Ｒｅａｄｙが継続される場合がある。このような場合には、ＰＡＣＫＥＴ＿ＳＹＮＣを含むパケットにＦＥＣエラーが発生し得る。

また、受信状態が良い期間であっても、静電放電（ＥＳＤ）や電圧ドロップのような電気的なエラーの影響で瞬時的に通信エラーが発生した場合等に、ＰＡＣＫＥＴ＿ＳＹＮＣを含むパケットにＦＥＣエラーが発生することがある。

ＰＡＣＫＥＴ＿ＳＹＮＣを含むパケットにＦＥＣエラーが発生した場合、レシーバ・デバイス４０のデスクランブラが初期化されないので、トランスミッタ・デバイス３０のスクランブラとの間で同期ずれが発生する。そして、再度、ＰＡＣＫＥＴ＿ＳＹＮＣが送受信されるまで同期ずれが継続し、トランスミッタ・デバイス３０からレシーバ・デバイス４０に伝送されるフレームに受信エラー（例えば、ＣＲＣエラー）が発生し続ける可能性がある。

その結果、例えば、伝送されるフレームがオープン・アドレス・フレームである場合、トランスミッタ・デバイス３０のオープン・タイムアウト・タイマによるタイムアウトが発生する。フレームがアイデンティファイ・アドレス・フレームである場合、トランスミッタ・デバイス３０のアイデンティファイ・タイムアウト・タイマによるタイムアウトが発生し、リンク・リセット・シーケンスが再実行される。また、フレームがＳＳＰフレームである場合、受信エラーが発生したことを示すＮＡＫプリミティブをトランスミッタ・デバイス３０に送信するための処理が発生する。

さらに、レシーバ・デバイス４０のデスクランブラとトランスミッタ・デバイス３０のスクランブラとが同期しないまま、トランスミッタ・デバイス３０からのタスクフレームにも応答できなかった場合には、ターゲット２０が情報処理システム１から切り離されてしまう可能性もある。タスクフレームは、例えば、ターゲット２０に異常が発生している可能性がある場合に、リードやライトの中断（アボート）を要求するためのフレームである。

図４は、レシーバ・デバイス４０によるパケット受信において、ＰＡＣＫＥＴ＿ＳＹＮＣが正常に受信される場合の第１タイミングチャート３５と、ＰＡＣＫＥＴ＿ＳＹＮＣが正常に受信されない場合の第２タイミングチャート３６とを例示する。

まず、第１タイミングチャート３５では、レシーバ・デバイス４０は、アイドル期間内に受信される複数のパケット３５１，３５３の間の、ＰＡＣＫＥＴ＿ＳＹＮＣを含むパケット３５２を正常に受信している。これにより、レシーバ・デバイス４０のデスクランブラは初期化され、このパケット３５２の送信時に初期化されるトランスミッタ・デバイス３０のスクランブラと同期する。

そして、レシーバ・デバイス４０は、アイドル期間内のパケット３５３の後に受信される複数のパケット３５４，３５５，３５６から、プリミティブ（ここでは、ＳＯＡＦおよびＥＯＡＦ）だけでなく、フレームデータ（ここでは、アドレス・フレームのフレームデータ）も正しく認識することができる。つまり、レシーバ・デバイス４０は、トランスミッタ・デバイス３０のスクランブラと同期したデスクランブラによって生成されるスクランブリングデータを用いて、パケット３５５から、同期ずれに起因する受信エラーが発生していないフレームデータを取得することができる。

これに対して、第２タイミングチャート３６では、アイドル期間内に受信される複数のパケット３６１の内のパケット３６１ＥにＦＥＣエラーが発生している。しかし、特定の回数以上連続して、ＦＥＣエラーが発生したパケット３６１Ｅを受信していないので、トランスミッタ・デバイス３０とレシーバ・デバイス４０との間でフレーム送受信が可能な状態が継続されている。

その後、レシーバ・デバイス４０では、ＰＡＣＫＥＴ＿ＳＹＮＣを含むパケット３６２でもＦＥＣエラーが発生している。これによって、このパケット３６２の送信時にトランスミッタ・デバイス３０のスクランブラが初期化される一方、レシーバ・デバイス４０のデスクランブラは初期化されず、レシーバ・デバイス４０のデスクランブラとトランスミッタ・デバイス３０のスクランブラとの間に同期ずれが発生する。

次いで、アイドル期間内に受信される複数のパケット３６３の内のパケット３６３ＥにＦＥＣエラーが発生している。しかし、特定の回数以上連続して、ＦＥＣエラーが発生したパケット３６３Ｅを受信していないので、レシーバ・デバイス４０とトランスミッタ・デバイス３０との間でフレーム送受信が可能な状態が継続されている。

また、レシーバ・デバイス４０は、ＰＡＣＫＥＴ＿ＳＹＮＣを含むパケット３６２が正常に受信されず、レシーバ・デバイス４０のデスクランブラとトランスミッタ・デバイス３０のスクランブラとの間に同期ずれが発生した以降に、トランスミッタ・デバイス３０によって送信されるパケット３６３，３６４，３６５，３６６から、プリミティブは正しく認識できるものの、プリミティブではないフレームデータは認識することができない。プリミティブはスクランブル／デスクランブルされないので、レシーバ・デバイス４０は、パケット３６４からＳＯＡＦを認識し、パケット３６６からＥＯＡＦを認識することができる。しかし、ｄｗｏｒｄで構成されるフレームデータはスクランブル／デスクランブルされるので、レシーバ・デバイス４０は、パケット３６５からフレームデータを認識することができない。

このように、ＰＡＣＫＥＴ＿ＳＹＮＣが、パケットが壊れた等の要因によって正常に受信されなかった場合、次にＰＡＣＫＥＴ＿ＳＹＮＣが正常に受信されるまでの間、受信されるフレームを認識することができない。そのため、レシーバ・デバイス４０では、トランスミッタ・デバイス３０のスクランブラとレシーバ・デバイス４０のデスクランブラとの同期ずれに起因する受信エラーが繰り返し発生し得る。

ＳＡＳ（ＳＰＬ−４）では、スクランブラ・イニシャライゼーション・タイマを用いて、フレーム送受信が可能な状態であるＰｈｙ Ｌａｙｅｒ Ｒｅａｄｙになった後、例えば、このタイマがタイムアウトする毎にＰＡＣＫＥＴ＿ＳＹＮＣを送信することが規定されている。これにより、スクランブラとデスクランブラとが定期的に同期される。

このスクランブラ・イニシャライゼーション・タイマには、ベンダ独自の値が設定され、任意の送信間隔でＰＡＣＫＥＴ＿ＳＹＮＣを送信することができる。しかし、定期的にＰＡＣＫＥＴ＿ＳＹＮＣが送信されることは、スクランブラとデスクランブラとの同期を何等保証するものではない。スクランブラ１０４とデスクランブラ１０８との同期ずれは、ＰＡＣＫＥＴ＿ＳＹＮＣを含むパケットにＦＥＣエラーが発生することによるＰＡＣＫＥＴ＿ＳＹＮＣの取りこぼしによるものであるので、ＰＡＣＫＥＴ＿ＳＹＮＣを頻繁に送信すればするほど良いというものでもない。

本実施形態では、このようなスクランブラとデスクランブラとの同期ずれに起因するフレームの受信エラーが発生した場合に、レシーバ・デバイス４０のデスクランブラをトランスミッタ・デバイス３０のスクランブラに同期させると共に、そのフレームを適切にデスクランブルし得る。レシーバ・デバイス４０は、受信フレーム内の特定のフィールドの値を用いて、すなわち、この特定のフィールドに対応するフレームデータを用いて、デスクランブラとスクランブラを同期させ、受信フレームをデスクランブルする。これにより、レシーバ・デバイス４０のリンクレベルでの受信エラーに対する耐性が向上する。

受信フレーム内の特定のフィールドは、当該フィールドの値のスクランブル前の値が、レシーバ・デバイス４０によって予め保持されているフィールドである。つまり、この特定のフィールドは、レシーバ・デバイス４０にとって認識可能な既定の値が含まれ得るフィールドである。以下では、受信フレーム内の特定のフィールドを既定値フィールドとも称する。

図５を参照して、スクランブラとデスクランブラとの同期ずれに起因するフレームの受信エラーが発生した場合に、レシーバ・デバイス４０のデスクランブラをトランスミッタ・デバイス３０のスクランブラに同期させると共に、そのフレームを適切にデスクランブルするための方法について説明する。

上述したように、既定値フィールドは、受信フレーム１５内の当該フィールドの値１５１のスクランブル前の値が、レシーバ・デバイス４０によって予め保持されているフィールドである。つまり、レシーバ・デバイス４０は、受信フレーム１５内の既定値フィールドの値１５１がデスクランブルされなくとも、その値のデスクランブル後の値が分かっている。この既定値フィールドは、例えば、特定の値（例えば、０）が設定されることが予め規定されているフィールドや、レシーバ・デバイス４０のＳＡＳアドレスのような、レシーバ・デバイス４０において既知である値が設定されるフィールドである。以下では、レシーバ・デバイス４０によって予め保持されている、既定値フィールドの値１５１のスクランブル前の値を、既定期待値１５０とも称する。

レシーバ・デバイス４０が、ある受信フレーム１５内の連続する特定の数以上のビットに対して、そのスクランブル前の値である既定期待値１５０を予め保持していれば、それらビットの値を既定値フィールドの値１５１として用いることができる。この特定の数は、スクランブラ／デスクランブラ１０４，１０８に設けられるパターン・ジェネレータに応じて決定される。

例えば、パターン・ジェネレータが、２３ビットの線形フィードバック・シフト・レジスタ（ＬＦＳＲ）を備える場合、この特定の数は２３である。この場合、レシーバ・デバイス４０が、受信フレーム１５内の連続する少なくとも２３ビットの値に対して、そのスクランブル前の値である既定期待値１５０を保持していれば、それら少なくとも２３ビットの値を既定値フィールドの値１５１として用いることができる。以下では、パターン・ジェネレータが、２３ビットのＬＦＳＲを備える場合（すなわち、２^２３−１の生成多項式を用いる場合）について主に例示する。

レシーバ・デバイス４０は、受信フレーム１５内の既定値フィールドの値１５１と、このレシーバ・デバイス４０内に予め保持されている、この値のスクランブル前の値である既定期待値１５０とを用いて、レシーバ・デバイス４０のデスクランブラ１０８をトランスミッタ・デバイス３０のスクランブラ１０４に同期させることができる。レシーバ・デバイス４０は、２３ビットのＬＦＳＲが用いられ、受信フレーム１５内の連続する少なくとも２３ビットの値に対して、そのスクランブル前の値である既定期待値１５０を保持している場合、その少なくとも２３ビットの値からなる既定値フィールドの値１５１と、既定期待値１５０とを用いて、どの時点のＬＦＳＲの状態でもＸＯＲ演算のみで一意に算出することができる。

より具体的には、レシーバ・デバイス４０は、受信フレーム１５内の既定値フィールド値１５１と、このレシーバ・デバイス４０内に保持されている既定期待値１５０とを用いて、その既定値フィールドの値１５１を生成するために用いられたスクランブリングデータ１５２を算出する。スクランブリングデータ１５２の具体的な算出方法については後述する。

そして、レシーバ・デバイス４０は、算出されたスクランブリングデータ１５２が生成された時点のスクランブラ／デスクランブラ１０４，１０８の状態１５３を復元する。スクランブリングデータ１５２が生成された時点のスクランブラ／デスクランブラ１０４，１０８の状態１５３は、復元された状態とも称する。

レシーバ・デバイス４０は、スクランブラ／デスクランブラ１０４，１０８の状態を、復元された状態１５３から、ある回数だけ前進するように遷移させること、あるいはある回数だけ後退するように遷移させることにより、スクランブラ／デスクランブラ１０４，１０８を任意の時点の状態１５４，１５５に設定できる。これにより、レシーバ・デバイス４０のデスクランブラ１０８をトランスミッタ・デバイス３０のスクランブラ１０４に同期させることができるので、これらデバイス間で正常にフレームを伝送することができる。

より具体的には、レシーバ・デバイス４０は、例えば、デスクランブラ１０８内のＬＦＳＲに、任意の時点の状態１５４，１５５に対応する値を設定する。デスクランブラ１０８の状態（すなわち、ラン回数）に対応するＬＦＳＲの状態（すなわち、ＬＦＳＲの各ビットの値）は一意に特定可能である。ＬＦＳＲの具体的な構成については、図８を参照して後述する。

スクランブラ／デスクランブラ１０４，１０８の状態を前進するように遷移させるとは、スクランブラ／デスクランブラ１０４，１０８の状態を次の状態に進めることを意味する。スクランブラ／デスクランブラ１０４，１０８の状態を次の状態に進めることは、スクランブラ／デスクランブラ１０４，１０８が動作（ラン）することと同じである。スクランブラ／デスクランブラ１０４，１０８の状態を、例えば、復元された状態１５３から、この復元された状態１５３よりも後の任意の時点の状態１５５まで前進するように遷移させる場合、復元された状態１５３を次の状態Ａに遷移させ、この状態Ａを次の状態Ｂに遷移させる、と云った繰り返しの遷移により、スクランブラ／デスクランブラ１０４，１０８の状態を、復元された状態１５３から任意の時点の状態１５５まで前進するように遷移させることができる。スクランブラ／デスクランブラ１０４，１０８が次の状態に進む遷移は、そのラン回数が１だけ増加することに対応する。したがって、例えば、次の状態Ａであるスクランブラ／デスクランブラ１０４，１０８のラン回数は、復元された状態１５３であるスクランブラ／デスクランブラ１０４，１０８のラン回数よりも１だけ多い。

スクランブラ／デスクランブラ１０４，１０８の状態を後退するように遷移させるとは、スクランブラ／デスクランブラ１０４，１０８の状態を１つ前の状態に戻すことを意味する。スクランブラ／デスクランブラ１０４，１０８の状態を、例えば、復元された状態１５３から、この復元された状態１５３よりも前の任意の時点の状態１５４まで後退するように遷移させる場合、復元された状態１５３を１つ前の状態Ｃに遷移させ、この状態Ｃを１つ前の状態Ｄに遷移させる、と云った繰り返しの遷移により、スクランブラ／デスクランブラ１０４，１０８の状態を、復元された状態１５３から任意の時点の状態１５４まで後退するように遷移させることができる。スクランブラ／デスクランブラ１０４，１０８が１つ前の状態に戻る遷移は、そのラン回数が１だけ減少することに対応する。したがって、例えば、１つ前の状態Ｃであるスクランブラ／デスクランブラ１０４，１０８のラン回数は、復元された状態１５３であるスクランブラ／デスクランブラ１０４，１０８のラン回数よりも１だけ少ない。

さらに、レシーバ・デバイス４０は、スクランブラ／デスクランブラ１０４，１０８を、復元された状態１５３から、前進するように遷移させる計算と、後退するように遷移させる計算の少なくとも一方を用いて、受信フレーム１５全体をデスクランブルするためのスクランブリングデータ１５６を算出できる。前進するように遷移させる計算と、後退するように遷移させる計算の少なくとも一方を用いてスクランブリングデータ１５６を算出するとは、スクランブラ／デスクランブラ１０４，１０８を実際に遷移させてスクランブリングデータ１５６を生成するのではなく、前進と後退の少なくとも一方の遷移に相当する数値計算によってスクランブリングデータ１５６を算出することを意味する。

レシーバ・デバイス４０は、算出されたスクランブリングデータ１５６を用いて、受信フレーム１５をデスクランブルする。これにより、デスクランブラ１０８によってデスクランブルされた受信フレーム１５に、スクランブラ１０４とデスクランブラ１０８との同期ずれに起因する受信エラーが発生する場合にも、既定値フィールドの値１５１と既定期待値１５０とを用いて、適切にデスクランブルされたフレーム１５７（以下、復元フレームとも称する）を算出することができる。

以下では、上記の動作を実現するための構成について具体的に例示する。
図６は、ＳＡＳ Ｇｅｎ５の装置の構成を示す。この装置は、イニシエータ１０とターゲット２０のいずれとしても動作し得る。また、上述したように、イニシエータ１０とターゲット２０の一方がトランスミッタ・デバイス３０として動作するとき、他方はレシーバ・デバイス４０として動作する。以下では、ＳＡＳ Ｇｅｎ５の装置を、イニシエータ／ターゲット１０，２０とも表記する。

イニシエータ／ターゲット１０，２０は、コントローラ１００、送信フレームコントローラ１０１、ＣＲＣジェネレータ１０２、プリミティブ・ジェネレータ１０３、スクランブラ１０４、ＦＥＣエンコーダ１０５、ＦＥＣデコーダ１０６、プリミティブ・デコーダ１０７、デスクランブラ１０８、ＣＲＣデコーダ１１６、受信フレームコントローラ１０９、および復元モジュール１１を備える。

コントローラ１００は、イニシエータ／ターゲット１０，２０内の様々なコンポーネントの動作を制御する。コントローラ１００は、別のイニシエータ／ターゲット１０，２０にフレームを送信するためにイニシエータ／ターゲット１０，２０内の各部を制御し、別のイニシエータ／ターゲット１０，２０からフレームを受信するためにイニシエータ／ターゲット１０，２０内の各部を制御する。

以下では、フレームが送信される場合とフレームが受信される場合とについて、イニシエータ／ターゲット１０，２０内の各部の動作を説明する。

まず、イニシエータ／ターゲット１０，２０（トランスミッタ・デバイス３０）が別のイニシエータ／ターゲット１０，２０（レシーバ・デバイス４０）にフレームを送信する場合について説明する。この場合、コントローラ１００、送信フレームコントローラ１０１、ＣＲＣジェネレータ１０２、プリミティブ・ジェネレータ１０３、スクランブラ１０４、およびＦＥＣエンコーダ１０５が動作する。

プリミティブ・ジェネレータ１０３は、コントローラ１００またはＣＲＣジェネレータ１０２による要求（通知）に応じて、プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブを生成する。プリミティブが生成された場合、プリミティブ・ジェネレータ１０３は、そのプリミティブに２ビットのヘッダを付加することにより生成した１３０ビットの情報をスクランブラ１０４に出力する。また、バイナリ・プリミティブまたはエクステンデッド・バイナリ・プリミティブが生成された場合、プリミティブ・ジェネレータ１０３は、そのバイナリ・プリミティブまたはエクステンデッド・バイナリ・プリミティブをスクランブラ１０４に出力する。

送信フレームコントローラ１０１は、コントローラ１００による要求に応じて、フレームに含まれるフレームデータの送信を制御する。送信フレームコントローラ１０１は、例えば、パケットのペイロードとなる１２８ビット単位のフレームデータ（１６個のデータバイト）と、２ビットのヘッダとをＣＲＣジェネレータ１０２に出力する。

ＣＲＣジェネレータ１０２は、フレームに含まれるフレームデータのＣＲＣ値を算出する。ＣＲＣジェネレータ１０２は、パケット単位で、フレームデータおよび／またはＣＲＣ値とヘッダとをスクランブラ１０４に出力する。また、ＣＲＣジェネレータ１０２は、フレームに含まれる全てのフレームデータを用いてＣＲＣ値を算出した後に、プリミティブ・ジェネレータ１０３に、Ｂ＿ＥＯＦｓ（より詳しくは、Ｂ＿ＥＯＦ（０）、Ｂ＿ＥＯＦ（１）、Ｂ＿ＥＯＦ（２）、またはＢ＿ＥＯＦ（３））プリミティブ（以下、Ｂ＿ＥＯＦｓとも称する）またはＥＯＡＦプリミティブの生成を要求し、ＣＲＣ値が算出されたことを通知する。この要求または通知に応じて、プリミティブ・ジェネレータ１０３はＢ＿ＥＯＦｓまたはＥＯＡＦを生成する。

より具体的には、Ｂ＿ＥＯＦｓの生成が要求された場合、プリミティブ・ジェネレータ１０３は、送信されるフレーム内のフレームデータに含まれるＤａｔａ ｄｗｏｒｄの数（以下、送信データ数とも称する）に応じて、Ｂ＿ＥＯＦ（＄ＰＡＤ）を生成する。＄ＰＡＤは変数であり、下記の式（１）により決定される。
＄ＰＡＤ ＝ ４−（送信データ数 ｍｏｄ ４） 式（１）
この変数＄ＰＡＤは、送信されるフレーム内のフレームデータのサイズが４Ｄｗｏｒｄの倍数でない場合に、４Ｄｗｏｒｄの倍数になるようにフレームデータに追加されるパッドｄｗｏｒｄの数を表す。また、ＣＲＣ値の算出には、追加されるパッドｄｗｏｒｄは用いられない。そのため、プリミティブ・ジェネレータ１０３は、レシーバ・デバイス４０がフレームデータに追加されたパッドｄｗｏｒｄの数を判別し得るように、この数に対応するＢ＿ＥＯＦ（＄ＰＡＤ）を生成する。

スクランブラ１０４は、プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブが入力された場合、スクランブラ１０４の状態を次の状態に遷移させる、すなわち、スクランブラ１０４の動作回数（ＲＵＮ回数）を１だけ増加させる。なお、スクランブラ１０４は、プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブをスクランブルしない。スクランブラ１０４は、送信されるパケットのペイロードである、プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブを含むプリミティブ・セグメントをＦＥＣエンコーダ１０５に出力する。

また、スクランブラ１０４は、フレームデータおよび／またはＣＲＣ値が入力された場合、ビットの偏りを減少させるために、フレームデータおよび／またはＣＲＣ値をスクランブルする。スクランブルされたフレームデータおよび／またはＣＲＣ値を含むフレーム・セグメントは、送信されるパケットのペイロードである。また、このペイロードには、２ビットのヘッダが付加されている。スクランブラ１０４は、ヘッダとペイロードとをＦＥＣエンコーダ１０５に出力する。そして、フレームデータをスクランブルした後、スクランブラ１０４の状態は次の状態に遷移する、すなわち、スクランブラ１０４の動作回数（ＲＵＮ回数）が１だけ増加する。

図７は、スクランブラ１０４の構成を示す。スクランブラ１０４は、繰り返しのパターンを減少させるために、パターン・ジェネレータ１７によって生成されたスクランブリングデータと、入力データ１６１の各ビットとを排他的論理和（ＸＯＲ）演算１８することにより、入力データ１６１がスクランブルされた出力データ１６２を取得する。例えば、入力データ１６１および出力データ１６２は１２８ビットのデータであり、パターン・ジェネレータ１７は１２８ビットのパターンであるスクランブリングデータを生成する。パターン・ジェネレータ１７は、例えば、線形フィードバック・シフト・レジスタ（ＬＦＳＲ）１７Ａを備え、パターン・ジェネレータ１７の動作（ＲＵＮ）が有効になったことを示すｖａｌｉｄ信号に応じて、その状態が次の状態に遷移する（すなわち、動作回数（ＲＵＮ回数）が１だけ増加する）。なお、スクランブラ１０４は、フレーム・セグメントをスクランブルするが、プリミティブ・セグメントをスクランブルしない。

また、ＰＡＣＫＥＴ＿ＳＹＮＣが送信されるとき、スクランブラ１０４は初期化される。つまり、パターン・ジェネレータ１７が初期状態に設定される。

パターン・ジェネレータ１７内のＬＦＳＲ１７Ａは、その状態が遷移する毎に１ビットの値を出力する。パターン・ジェネレータ１７は、ＬＦＳＲ１７Ａにより連続して出力された１２８ビット分の値を用いて、スクランブリングデータを生成する。

図８（Ａ）に示すように、ＬＦＳＲ１７Ａは、例えば、ビット０からビット２３までの２３ビットのフリップフロップ回路（ＦＦ）と、５つのＸＯＲ演算器とで構成されている。

ＬＦＳＲ１７Ａでは、状態が遷移する毎に以下の動作が並列に行われる。
（１）ビット０，２，３，５，６，８，９，１０，１１，１２，１３，１４，１６，１７，１８，１９，２１の各値を、その１つ上のビットに出力する。
（２）ビット１の値とビット２２の値とのＸＯＲ演算結果を、ビット２に出力する。
（３）ビット４の値とビット２２の値とのＸＯＲ演算結果を、ビット５に出力する。
（４）ビット７の値とビット２２の値とのＸＯＲ演算結果を、ビット８に出力する。
（５）ビット１５の値とビット２２の値とのＸＯＲ演算結果を、ビット１６に出力する。
（６）ビット２０の値とビット２２の値とのＸＯＲ演算結果を、ビット２１に出力する。
（７）ビット２２の値を、ビット０と外部とに出力する。
ＬＦＳＲ１７Ａの状態を次の状態に遷移させた結果、上記の動作が行われる。

ＬＦＳＲ１７Ａから外部に連続して出力された１２８ビット分の値は、１２８ビットの入力フレームデータ１６１をスクランブルするためのスクランブリングデータとして用いられる。つまり、ＬＦＳＲ１７Ａから連続して出力された１２８ビット分の値と、１２８ビットの入力フレームデータ１６１とがＸＯＲ演算１８されることにより、１２８ビットの出力フレームデータ（すなわち、４つのｄｗｏｒｄ）１６２が得られる。

ＬＦＳＲ１７Ａは、２^２３−１ビット分の値が出力されたこと、あるいはＰＡＣＫＥＴ＿ＳＹＮＣが送信されることに応じて、初期状態に戻る。

したがって、ＰＡＣＫＥＴ＿ＳＹＮＣの送信に応じたスクランブラ１０４の初期化は、より具体的には、このＬＦＳＲ１７Ａの初期化を意味している。また、スクランブラ１０４による一度のスクランブリング動作において、１２８ビットの入力データ１６１が１２８ビットのスクランブリングデータでスクランブルされる場合、スクランブラ１０４（パターン・ジェネレータ１７）の１回の状態遷移は、ＬＦＳＲ１７Ａの１２８回の状態遷移に相当する。このような関係から、スクランブラ１０４の状態（すなわち、ラン回数）に基づいて、対応するＬＦＳＲ１７Ａの状態（すなわち、ＬＦＳＲ１７Ａの各ビットの値）が特定可能であり、同様に、ＬＦＳＲ１７Ａの状態に基づいて、対応するスクランブラ１０４の状態が特定可能である。

スクランブラ１０４は、上記のＬＦＳＲ１７Ａの回路構成を、生成多項式を用いた数値計算を実行するプロセッサの構成として実装してもよい。ＬＦＳＲ１７Ａによる出力は、例えば、下記の生成多項式を用いて算出できる。
Ｇ（ｘ）＝ｘ^２３＋ｘ^２１＋ｘ^１６＋ｘ^８＋ｘ^５＋ｘ^２＋１
この生成多項式を用いて、ＬＦＳＲ１７Ａによって出力される２^２３−１ビット分の値が算出可能である。

つまり、スクランブラ１０４は、ＬＦＳＲ１７Ａを用いて算出されるスクランブリングデータや、ＬＦＳＲ１７Ａの状態を、上述した回路のような構成で算出できるだけでなく、生成多項式を用いた数値計算の結果として取得することもできる。

図６に戻り、ＦＥＣエンコーダ１０５は、入力された情報（ヘッダとペイロード）にＦＥＣエンコード処理を施すことにより、２０ビットのＦＥＣコードを付加して、１５０ビットの情報を生成する。上述したように、ＦＥＣコードには、エラー検出およびエラー訂正のためのコードが含まれている。ＦＥＣエンコーダ１０５は、生成された１５０ビットの情報で構成されるパケットを別のイニシエータ／ターゲット１０，２０（レシーバ・デバイス４０）に送信する。

以上の動作により、イニシエータ／ターゲット１０，２０は、プリミティブまたはフレームデータを含むパケットを別のイニシエータ／ターゲット１０，２０に送信することができる。

また、イニシエータ／ターゲット１０，２０（レシーバ・デバイス４０）が別のイニシエータ／ターゲット１０，２０（トランスミッタ・デバイス３０）からフレームを受信する場合、コントローラ１００、ＦＥＣデコーダ１０６、プリミティブ・デコーダ１０７、デスクランブラ１０８、ＣＲＣデコーダ１１６、受信フレームコントローラ１０９、および復元モジュール１１が動作する。

ＦＥＣデコーダ１０６は、別のイニシエータ／ターゲット１０，２０から受信された１５０ビット毎の情報（パケット）にＦＥＣデコード処理を施すことにより、１３０ビットの情報を生成する。生成される１３０ビットの情報には、２ビットのヘッダと１２８ビットのペイロードとが含まれる。また、ＦＥＣデコード処理には、ＦＥＣコードを用いたエラー検出およびエラー訂正のための処理が含まれる。ＦＥＣデコーダ１０６は、デコードの成功または失敗をコントローラ１００等に通知するようにしてもよい。デコードが成功した場合、ＦＥＣデコーダ１０６は、生成された１３０ビットの情報を、プリミティブ・デコーダ１０７、デスクランブラ１０８、および復元モジュール１１に出力する。

プリミティブ・デコーダ１０７は、入力された情報のペイロードとして、プリミティブ・セグメント（プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブ）が含まれる場合、入力された情報から２ビットのヘッダが除かれた１２８ビットの情報（プリミティブ）を取得する。

プリミティブ・デコーダ１０７は、入力された情報に含まれるプリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブを識別し、コントローラ１００等と連携してそのプリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブに応じた動作を行う。

入力された情報にＰＡＣＫＥＴ＿ＳＹＮＣが含まれる場合、プリミティブ・デコーダ１０７は、ＰＡＣＫＥＴ＿ＳＹＮＣが受信されたことをデスクランブラ１０８に通知する。

入力された情報にＢ＿ＥＯＦｓまたはＥＯＡＦが含まれる場合、プリミティブ・デコーダ１０７は、ＣＲＣデコーダ１１６に対して、ＣＲＣの検証を要求する。

デスクランブラ１０８は、入力された情報のペイロードとして、プリミティブ・セグメント（プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブ）が含まれる場合、デスクランブラ１０８の状態を次の状態に遷移させる。なお、デスクランブラ１０８は、プリミティブ・セグメントをデスクランブルしない。

また、デスクランブラ１０８は、入力された情報のペイロードとして、フレーム・セグメント（フレームデータおよび／またはＣＲＣ値）が含まれる場合、当該ペイロードをデスクランブルする。デスクランブラ１０８は、デスクランブルされたフレーム・セグメントをＣＲＣデコーダ１１６に出力する。フレーム・セグメントをデスクランブルした後、デスクランブラ１０８の状態は次の状態に遷移する。

デスクランブラ１０８は、図７および図８を参照して上述したスクランブラ１０４と同様の構成を有する。すなわち、デスクランブラ１０８は、パターン・ジェネレータ１７によって生成されたスクランブリングデータと、入力データ１６１の各ビットとを排他的論理和（ＸＯＲ）演算１８することにより、入力データ１６１がスクランブルされた出力データ１６２を取得する。なお、このスクランブリングデータと、出力データ１６２の各ビットとをＸＯＲ演算することにより、入力データ１６１が得られる。つまり、スクランブリングデータでスクランブルされた入力データ１６１は、当該スクランブリングデータでさらにスクランブル（すなわち、デスクランブル）されたならば、スクランブル前の入力データ１６１に戻る。

また、プリミティブ・デコーダ１０７によって、ＰＡＣＫＥＴ＿ＳＹＮＣが受信されたことが通知されたとき、デスクランブラ１０８（より詳しくはパターン・ジェネレータ１７）は初期化される。すなわち、デスクランブラ１０８内のＬＦＳＲ１７Ａが初期状態に戻る。デスクランブラ１０８の初期化は、より具体的には、このデスクランブラ１０８内のＬＦＳＲ１７Ａの初期化を意味している。

ＣＲＣデコーダ１１６は、受信されたフレーム内のデスクランブルされたフレームデータとＣＲＣ値とを用いて、当該フレームにＣＲＣエラーが発生しているかどうかを判定する。ＣＲＣデコーダ１１６は、例えば、プリミティブ・デコーダ１０７によって、Ｂ＿ＥＯＦｓまたはＥＯＡＦが受信されたことが通知されたとき、フレームにＣＲＣエラーが発生しているかどうかを判定する。

あるフレームデータがスクランブルされたときのスクランブラ１０４の状態と、当該フレームデータがデスクランブルされたときのデスクランブラ１０８の状態とが一致しているならば、すなわち、これらスクランブラ１０４とデスクランブラ１０８とが同期しているならば、デスクランブラ１０８は、フレームデータやＣＲＣ値を適切にデスクランブルすることができる。そして、フレームデータとＣＲＣ値とが適切にデスクランブルされた場合、受信されたフレームから、スクランブラ１０４とデスクランブラ１０８の同期ずれに起因するＣＲＣエラーは検出されない。

一方、あるフレームデータがスクランブルされたときのスクランブラ１０４の状態と、当該フレームデータがデスクランブルされたときのデスクランブラ１０８の状態とが一致していないならば、すなわち、これらスクランブラ１０４とデスクランブラ１０８とが同期していなければ、デスクランブラ１０８は、フレームデータやＣＲＣ値を適切にデスクランブルすることができない。ＣＲＣデコーダ１１６は、フレームデータやＣＲＣ値が適切にデスクランブルされなかった場合、受信されたフレームにＣＲＣエラーが発生していることを検出する。

ＣＲＣエラーが発生していない場合、ＣＲＣデコーダ１１６は、デスクランブルされたフレームデータを受信フレームコントローラ１０９に出力する。この場合、受信フレームコントローラ１０９は、コントローラ１００等と連携して、入力されたフレームデータ（デスクランブルされたフレームデータ）を処理する。例えば、ストレージデバイスであるイニシエータ／ターゲット１０，２０がユーザデータを含むフレームを受信したならば、ユーザデータを記憶媒体に格納するための処理等が行われる。

また、例えば、フレームがアイデンティファイ・アドレス・フレームであるならば、コントローラ１００は、上述したパケットを送信するための動作により、アイデンティファイ・アドレス・フレームを構成するフレームデータを含む複数のパケットを送信するように、イニシエータ／ターゲット１０，２０内の各部を制御してもよい。フレームが接続要求のためのオープン・アドレス・フレームであるならば、コントローラ１００は、接続要求を承認することを示すＯＰＥＮ＿ＡＣＣＥＰＴプリミティブ、あるいは接続要求を拒絶することを示すＯＰＥＮ＿ＲＥＪＥＣＴプリミティブを含むパケットを送信するように、イニシエータ／ターゲット１０，２０内の各部を制御してもよい。さらに、フレームがＳＳＰフレームであるならば、コントローラ１００は、上述したパケットを送信するための動作により、肯定応答を示すＡＣＫプリミティブを含むパケットを送信するように、イニシエータ／ターゲット１０，２０内の各部を制御してもよい。

一方、デスクランブラ１０８によってデスクランブルされた受信フレーム１５にＣＲＣエラーが発生している場合、すなわち、このデスクランブラ１０８と、トランスミッタ・デバイス３０内のスクランブラ１０４との同期ずれに起因して、デスクランブルされた受信フレーム１５にＣＲＣエラーが発生している場合、ＣＲＣデコーダ１１６は、復元モジュール１１によって受信フレーム１５から復元された復元フレーム１５７にＣＲＣエラーが発生しているかどうかを判定する。復元モジュール１１は、デスクランブラ１０８において生成されたスクランブリングデータではなく、受信フレーム１５内の既定値フィールドの値１５１と既定期待値１５０とを用いて算出されたスクランブリングデータ１５６で受信フレーム１５をデスクランブルすることにより、復元フレーム１５７を取得する。ＣＲＣデコーダ１１６は、復元フレーム１５７内のフレームデータとＣＲＣ値とを用いて、当該復元フレーム１５７にＣＲＣエラーが発生しているかどうかを判定する。復元フレーム１５７を生成する復元モジュール１１の具体的な構成について、以下で説明する。

復元モジュール１１は、受信フレーム１５内の既定値フィールドに対応するフレームデータ１５１と、既定期待値１５０とを用いて、このイニシエータ／ターゲット１０，２０のデスクランブラ１０８を、受信フレーム１５を送信した別のイニシエータ／ターゲット１０，２０のスクランブラ１０４と同期させ、受信フレーム１５を適切にデスクランブルするための機能を有する。復元モジュール１１は、復元コントローラ１１０、フレーム・バッファ１１Ａ、ＸＯＲ演算器１１１，１１５、ＬＦＳＲ復元部１１２、ＬＦＳＲ算出部１１３、およびＬＦＳＲロールバック部１１４を備える。

復元コントローラ１１０は、ＦＥＣデコーダ１０６から、ＳＯＦまたはＳＯＡＦが含まれる情報が入力されてから、Ｂ＿ＥＯＦｓまたはＥＯＡＦを含む情報が入力されるまで、ＦＥＣデコーダ１０６から入力される情報をフレーム・バッファ１１Ａに保存する。復元コントローラ１１０は、例えば、バッファフラグを用いてフレーム・バッファ１１Ａへの情報の保存を制御する。復元コントローラ１１０は、ＳＯＦまたはＳＯＡＦを含む情報が入力されたことに応じてバッファフラグを立て、Ｂ＿ＥＯＦｓまたはＥＯＡＦを含む情報が入力されたことに応じてバッファフラグをクリアする。そして、バッファフラグが立っている間、ＦＥＣデコーダ１０６から入力される情報である受信フレーム１５がフレーム・バッファ１１Ａに保存される。

したがって、例えば、ＳＯＦが受信されてからＢ＿ＥＯＦｓが受信されるまでの間に受信された受信フレーム１５（例えば、ＳＳＰフレーム）がフレーム・バッファ１１Ａに保存される。また、例えば、ＳＯＡＦが受信されてからＥＯＡＦが受信されるまでの間に受信された受信フレーム１５（例えば、アイデンティファイ・アドレス・フレームまたはオープン・アドレス・フレーム）がフレーム・バッファ１１Ａに保存される。

復元コントローラ１１０は、フレーム・バッファ１１Ａに保存される情報が、アイデンティファイ・アドレス・フレームと、オープン・アドレス・フレームと、ＳＳＰフレームのいずれのフレームであるかを識別する。より具体的には、復元コントローラ１１０は、ＳＯＦが受信された後にフレーム・バッファ１１Ａに保存される情報をＳＳＰフレームであると判断する。また、復元コントローラ１１０は、ＳＯＡＦが受信された後にフレーム・バッファ１１Ａに保存される情報を、アイデンティファイ・アドレス・フレームの交換後であれば、オープン・アドレス・フレームであると判断し、その交換前であれば、アイデンティファイ・アドレス・フレームであると判断する。

復元コントローラ１１０は、識別された受信フレーム１５に応じて、そのフレーム１５内の既定値フィールドを認識し、当該既定値フィールドに対応する既定期待値１５０を取得する。上述したように、既定値フィールドは、例えば、特定の値が設定されることが予め規定されているフィールドや、レシーバ・デバイス４０のＳＡＳアドレスのような、レシーバ・デバイス４０において既知である値が設定されるフィールドである。復元モジュール１１には、例えば、フレームの種別毎に、その既定値フィールドと既定期待値１５０とを示す情報が保持されていてもよい。

ＸＯＲ演算器１１１は、フレーム・バッファ１１Ａに、既定値フィールドに対応するフレームデータ１５１が保存されたことに応じて、このフレームデータ１５１と既定期待値１５０とをＸＯＲ演算することにより、フレームデータ１５１の生成に用いられたスクランブリングデータ１５２を算出する。

ＸＯＲ演算器１１１による演算が行われる時点では、少なくとも受信フレーム１５内の既定値フィールドに対応するフレームデータまでが、フレーム・バッファ１１Ａに保存されていればよい。

ＬＦＳＲ復元部１１２は、算出されたスクランブリングデータ１５２を用いて、このスクランブリングデータ１５２が生成された時点のＬＦＳＲの状態（すなわち、復元された状態）１５３を算出する。ＬＦＳＲ復元部１１２は、このスクランブリングデータ１５２を構成する複数の値をそれぞれ生成するように動作した場合の、ＬＦＳＲの各ビットの値を算出する。例えば、図８（Ａ）を参照して上述したように、ＬＦＳＲのビット２２の値は外部に出力され、スクランブリングデータ１５２を構成する値として用いられる。したがって、スクランブリングデータ１５２を構成するある値は、ある時点のビット２２に設定されていた値である。さらに、ビット２２に設定されていた値は、１つ前のＬＦＳＲの状態において、ビット２１に設定されていた値である。このように、図８（Ａ）を参照して上述したＬＦＳＲ１７Ａの動作（１）〜（７）に基づき、スクランブリングデータ１５２を構成する複数の値の生成が開始された時点において、ＬＦＳＲの各ビットに設定されていた値を算出することができる。より具体的な算出方法については、図１１を参照して後述する。

ＬＦＳＲ算出部１１３は、ＬＦＳＲの状態を、復元された状態１５３から、前進するように遷移させること、あるいは後退するように遷移させることにより、ＬＦＳＲの任意の時点の状態１５４，１５５を算出できる。ＬＦＳＲ算出部１１３は、例えば、既定値フィールドに対応するフレームデータ１５１よりも後のプリミティブまたはフレームデータが受信される時点のＬＦＳＲの状態を算出する。

より具体的には、ＬＦＳＲ算出部１１３は、受信フレーム１５のサイズと受信フレーム１５内での既定値フィールドの位置に基づいて、復元された状態１５３からその任意の時点の状態１５４，１５３に遷移させるために、ＬＦＳＲを前進または後退させるべき回数を決定する。つまり、ＬＦＳＲ算出部１１３は、復元された状態１５３からその任意の時点の状態１５４，１５３に遷移させるために、ＬＦＳＲを何ビット分、前進または後退させればよいかを決定する。ＬＦＳＲ算出部１１３は、決定された回数（あるいはビット数）に基づいて、ＬＦＳＲの状態を、復元された状態１５３から、前進するように遷移させる計算、あるいは後退するように遷移させる計算により、ＬＦＳＲの任意の時点の状態１５４，１５５を算出する。以下では、ＬＦＳＲ算出部１１３が、受信フレーム１５の直後のＢ＿ＥＯＦｓもしくはＥＯＡＦを含むパケット、またはこのＢ＿ＥＯＦｓもしくはＥＯＡＦを含むパケットの直後のパケットが受信される時点のＬＦＳＲの状態を算出することを想定する。

図８（Ａ）を参照して上述したＬＦＳＲ１７Ａは、状態が前進するように遷移するＬＦＳＲである。ＬＦＳＲ１７Ａの１回の動作によって、ＬＦＳＲの状態を前進させること、すなわち、次の状態に遷移させることができる。ＬＦＳＲ算出部１１３は、このＬＦＳＲ１７Ａの状態を任意の回数だけ遷移させる数値計算を用いて、復元された状態１５３から前進した任意の時点の状態１５４を算出する。

これに対して、図８（Ｂ）は、上記のＬＦＳＲ１７Ａにおける状態遷移とは逆向きに、状態が後退するように遷移するＬＦＳＲ１７Ｂを示す。ＬＦＳＲ１７Ｂでは、状態が遷移する毎に以下の動作が並列に行われる。
（１）ビット２２，２０，１９，１８，１７，１５，１４，１３，１２，１１，１０，９，７，６，４，３，１の各値を、その１つ下のビットに出力する。
（２）ビット２１の値とビット０の値とのＸＯＲ演算結果を、ビット２０に出力する。
（３）ビット１６の値とビット０の値とのＸＯＲ演算結果を、ビット１５に出力する。
（４）ビット８の値とビット０の値とのＸＯＲ演算結果を、ビット７に出力する。
（５）ビット５の値とビット０の値とのＸＯＲ演算結果を、ビット４に出力する。
（６）ビット２の値とビット０の値とのＸＯＲ演算結果を、ビット１に出力する。
（７）ビット０の値を、ビット２２に出力する。
（８）ビット２２の値を、外部に出力する。

このようなＬＦＳＲ１７Ｂの１回の動作によって、ＬＦＳＲの状態を後退させること、すなわち、１つ前の状態に遷移させることができる。ＬＦＳＲ算出部１１３は、このＬＦＳＲ１７Ｂの状態を任意の回数だけ遷移させる数値計算を用いて、復元された状態１５３から後退した任意の時点の状態１５５を算出する。

上記のＬＦＳＲ１７Ｂの回路構成も、生成多項式を用いた数値計算を実行するプロセッサの構成として実装することができる。つまり、ＬＦＳＲ１７Ｂを用いて算出されるスクランブリングデータや、ＬＦＳＲ１７Ｂの状態は、上述した回路のような構成で算出できるだけでなく、生成多項式を用いた数値計算の結果として取得することもできる。

図６に戻り、ＬＦＳＲロールバック部１１４は、受信フレーム１５をデスクランブルするためのスクランブリングデータ１５６を算出する。ＬＦＳＲロールバック部１１４は、復元された状態１５３から、前進するように遷移させる計算と、後退するように遷移させる計算の少なくとも一方を用いて、受信フレーム１５全体をデスクランブルするためのスクランブリングデータ１５６を算出できる。

例えば、ＬＦＳＲ算出部１１３によって、受信フレーム１５の直後のＢ＿ＥＯＦｓ／ＥＯＡＦが受信される時点のＬＦＳＲの状態１５４が算出されている場合を想定する。その場合、ＬＦＳＲロールバック部１１４は、算出されたＬＦＳＲの状態１５４から後退するように遷移させる計算を用いて、受信フレーム１５全体をデスクランブルするためのスクランブリングデータ１５６を算出する。

ＸＯＲ演算器１１５は、算出されたスクランブリングデータ１５６を用いて、フレーム・バッファ１１Ａに保存された受信フレーム１５をデスクランブルする。これにより、デスクランブルされた受信フレームである復元フレーム１５７が生成される。

以上により、復元モジュール１１において、受信フレーム１５内の既定値フィールドの値１５１と、既定期待値１５０とを用いて、レシーバ・デバイス４０によって受信フレーム１５の直後のＢ＿ＥＯＦｓもしくはＥＯＡＦを含むパケット、またはこのＢ＿ＥＯＦｓもしくはＥＯＡＦを含むパケットの直後のパケットが受信される時点のＬＦＳＲの状態と、復元フレーム１５７とを取得することができる。

ＣＲＣデコーダ１１６は、デスクランブラ１０８によってデスクランブルされた受信フレーム１５にＣＲＣエラーが発生している場合、すなわち、このデスクランブラ１０８とトランスミッタ・デバイス３０内のスクランブラ１０４とが同期していないことに起因して、デスクランブルされた受信フレーム１５にＣＲＣエラーが発生している場合、復元モジュール１１によるデスクランブルで得られた復元フレーム１５７にＣＲＣエラーが発生しているかどうかを判定する。上述したように、復元フレーム１５７は、デスクランブラ１０８において生成されたスクランブリングデータではなく、受信フレーム１５内の既定値フィールドの値１５１と既定期待値１５０とを用いて算出されたスクランブリングデータ１５６で、受信フレーム１５をデスクランブルして得られたフレームである。ＣＲＣデコーダ１１６は、復元フレーム１５７内のフレームデータとＣＲＣ値とを用いて、当該復元フレーム１５７にＣＲＣエラーが発生しているかどうかを判定する。

ＣＲＣデコーダ１１６は、この復元フレーム１５７にＣＲＣエラーが発生していない場合、復元フレーム１５７に含まれるフレームデータを受信フレームコントローラ１０９に出力する。デスクランブラ１０８によってデスクランブルされたフレームデータが受信フレームコントローラ１０９に出力される場合と同様に、受信フレームコントローラ１０９は、コントローラ１００等と連携して、入力されたフレームデータ（デスクランブルされたフレームデータ）を処理する。

さらに、コントローラ１００は、デスクランブラ１０８を、この受信フレーム１５を送信した別のイニシエータ／ターゲット１０，２０のスクランブラ１０４と同期させる。より具体的には、コントローラ１００は、デスクランブラ１０８内のＬＦＳＲ１７Ａの状態を、ＬＦＳＲ算出部１１３によって算出された、受信フレーム１５の直後のＢ＿ＥＯＦｓもしくはＥＯＡＦを含むパケット、またはこのＢ＿ＥＯＦｓもしくはＥＯＡＦを含むパケットの直後のパケットが受信される時点の状態に設定する。

これにより、デスクランブラ１０８によりデスクランブルされた受信フレーム１５に、スクランブラ１０４とデスクランブラ１０８との同期ずれに起因する受信エラー（例えば、ＣＲＣエラー）が発生している場合にも、適切にデスクランブルされた復元フレーム１５７を算出することができる。また、受信側のイニシエータ／ターゲット１０，２０のデスクランブラ１０８をイニシエータ／ターゲット１０，２０のスクランブラ１０４に同期させることができるので、これ以降に受信されるフレームも適切にデスクランブルすることができる。

なお、ＣＲＣデコーダ１１６は、復元フレーム１５７にＣＲＣエラーが発生している場合、フレームを破棄し、ＣＲＣエラーが発生していることを受信フレームコントローラ１０９に通知し得る。そして、例えば、フレームがＳＳＰフレームである場合、受信フレームコントローラ１０９は、コントローラ１００等と連携して、上述したＳＰＬパケットを送信するための動作により、ＣＲＣエラーが発生したことを示すＮＡＫ（ＣＲＣ ＥＲＲＯＲ）プリミティブを含むＳＰＬパケットを送信するように、イニシエータ／ターゲット１０，２０内の各部を制御する。また、例えば、フレームがアイデンティファイ・アドレス・フレームまたはオープン・アドレス・フレームである場合、何も応答しない。

このように、本実施形態のイニシエータ／ターゲット１０，２０では、デスクランブラ１０８によってデスクランブルされた受信フレーム１５にＣＲＣエラーが発生している場合に、復元モジュール１１による受信フレーム１５のデスクランブルにより得られた復元フレーム１５７にＣＲＣエラーが発生していないならば、このデスクランブルされた受信フレーム１５を復元フレーム１５７で置き換えることができる。また、受信側のイニシエータ／ターゲット１０，２０のデスクランブラ１０８を、送信側のイニシエータ／ターゲット１０，２０のスクランブラ１０４と同期させることができる。

以下では、イニシエータ／ターゲット１０，２０であるレシーバ・デバイス４０が、別のイニシエータ／ターゲット１０，２０であるトランスミッタ・デバイス３０から、アイデンティファイ・アドレス・フレーム、オープン・アドレス・フレーム、およびＳＳＰフレームを受信する場合について、それぞれ具体的に説明する。

図９は、アイデンティファイ・アドレス・フレームのフォーマットの例を示す。アイデンティファイ・アドレス・フレームは３２バイトのサイズを有している。

図９に示すように、アイデンティファイ・アドレス・フレームには、その２３バイト目から２７バイト目までに、５バイト（＝４０ビット）のサイズを有するＲｅｓｅｒｖｅｄフィールドが含まれている。Ｒｅｓｅｒｖｅｄフィールド内には、０ビット目から３９ビット目までの各ビットの値が設定されている。

ＳＡＳ Ｇｅｎ５の規格において、このＲｅｓｅｒｖｅｄフィールド内の各ビットには０が設定されるべきことが規定されている。つまり、Ｒｅｓｅｒｖｅｄフィールドには既定期待値が設定される。そのため、このＲｅｓｅｒｖｅｄフィールドの０ビットから３９ビットの内の連続する少なくともＮビットを、既定値フィールドとして用いることができる。２３ビットのＬＦＳＲ１７Ａが用いられる場合、Ｎ＝２３である。

図１０を参照して、アイデンティファイ・アドレス・フレーム内の既定値フィールドを用いて、ＬＦＳＲの状態とスクランブリングデータとが算出される例を説明する。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から、フレームの開始を示すＳＯＡＦを含むプリミティブ・セグメント４１を受信した後、アイデンティファイ・アドレス・フレームを構成する複数のフレーム・セグメント４２を受信する。フレーム・バッファ１１Ａには、少なくとも、アイデンティファイ・アドレス・フレームの先頭から、既定値フィールドであるＲｅｓｅｒｖｅｄフィールドまでのフレームデータが、すなわち、アイデンティファイ・アドレス・フレームの０バイト目から２７バイト目までのフレームデータが、保存される。

上述したように、Ｒｅｓｅｒｖｅｄフィールドには、ＳＡＳ Ｇｅｎ５の規格において、０が設定されるべきことが規定されている。そのため、スクランブリングデータとのＸＯＲ演算によりスクランブルされたＲｅｓｅｒｖｅｄフィールドの値は、そのスクランブリングデータと同一の値になる。

したがって、レシーバ・デバイス４０は、保存されたアイデンティファイ・アドレス・フレームのＲｅｓｅｒｖｅｄフィールドの値（すなわち、２３バイト目から２７バイト目までの値）４２１を、この値４２１の算出に用いられたスクランブリングデータ４２１Ｓとして算出する。なお、ＬＦＳＲ１７Ａが２３ビットで構成されている場合、Ｒｅｓｅｒｖｅｄフィールドは４０ビット（＝５バイト）のサイズを有しているので、その内の連続した２３ビットがスクランブリングデータ４２１Ｓとして算出されてもよい。

レシーバ・デバイス４０は、Ｒｅｓｅｒｖｅｄフィールド（既定値フィールド）に対応するスクランブリングデータ４２１Ｓに基づいて、このスクランブリングデータ４２１Ｓが算出された時点のＬＦＳＲの状態を算出（復元）できる。ＬＦＳＲの状態は、例えば、ＬＦＳＲを構成する各ビットの値で表される。以下では、既定値フィールドに対応するスクランブリングデータ４２１Ｓが算出された時点のＬＦＳＲの状態を、ＬＦＳＲの復元された状態とも称する。

図１１は、２３ビットのスクランブリングデータ４２１Ｓを用いて、対応するＬＦＳＲの状態を復元する数値計算のための関数ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ（ｉｎｐｕｔ ［２２：００］ ｉｎ）の例を示す。この関数の引数ｉｎとして、２３ビットのスクランブリングデータ４２１Ｓが用いられる。したがって、引数ｉｎ［００］〜ｉｎ［２２］が、スクランブリングデータ４２１Ｓのビット０〜ビット２２の値をそれぞれ表す。また、図示されている記号“＾”はＸＯＲ演算を表す。

ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［００］〜ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［２２］は、復元されるＬＦＳＲのビット０〜ビット２２の値をそれぞれ示す。図１１に示すように、ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［００］〜ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［２２］は、引数ｉｎ［００］〜ｉｎ［２２］を用いて算出される。

例えば、ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［２２］の値は、ｉｎ［００］の値と等しい。ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［２１］の値は、ｉｎ［０１］の値と等しい。また、ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［２０］の値は、ｉｎ［００］の値とｉｎ［０２］の値とのＸＯＲ演算結果である。

同様にして、図１１に示すように、ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［００］〜ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［２２］は、引数ｉｎ［００］〜ｉｎ［２２］の値を用いて、あるいは引数ｉｎ［００］〜ｉｎ［２２］の値を用いたＸＯＲ演算により、算出することができる。

図１０に戻り、レシーバ・デバイス４０は、復元されたＬＦＳＲの状態（例えば、図１１のｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［００］〜ｒｓｔｒ＿ｃｕｒｒ＿ｌｆｓｒ［２２］）が前進するように遷移させる計算か、あるいは算出されたＬＦＳＲの状態が後退するように遷移させる計算を用いて、任意の時点のＬＦＳＲの状態を算出することができる。例えば、レシーバ・デバイス４０は、アイデンティファイ・アドレス・フレームを構成するフレーム・セグメント４２の内のあるフレーム・セグメントが受信される時点のＬＦＳＲの状態、アイデンティファイ・アドレス・フレームの送信完了を示すＥＯＡＦを含むプリミティブ・セグメント４３が受信される時点のＬＦＳＲの状態、あるいは、このＥＯＡＦを含むプリミティブ・セグメント４３に後続するセグメント４４が受信される時点のＬＦＳＲの状態、等を算出できる。

レシーバ・デバイス４０は、この任意の時点のＬＦＳＲの状態として、レシーバ・デバイス４０のデスクランブラ１０８内のＬＦＳＲを、トランスミッタ・デバイス３０のスクランブラ１０４内のＬＦＳＲに同期させるための状態（以下、同期用状態とも称する）を算出することもできる。同期用状態には、例えば、アイデンティファイ・アドレス・フレームの送信完了を示すＥＯＡＦを含むプリミティブ・セグメント４３が受信される時点のＬＦＳＲの状態、あるいは、このＥＯＡＦを含むプリミティブ・セグメント４３に後続するセグメント４４が受信される時点のＬＦＳＲの状態が用いられる。

図１２は、アイデンティファイ・アドレス・フレームの２４バイト目から２６バイト目までのＲｅｓｅｒｖｅｄフィールドの内の、９ビット目から３１ビット目までの２３ビットを既定値フィールドとして、ＥＯＡＦを含むプリミティブ・セグメント４３が受信される時点のＬＦＳＲの状態を示す同期用状態を算出する数値計算のための関数ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ（ｉｎｐｕｔ ［２２：００］ ｉｎ）の例を示す。

この関数の引数ｉｎとして、ＬＦＳＲの復元された状態を示す２３ビットの値が用いられる。したがって、引数ｉｎ［００］〜ｉｎ［２２］が、ＬＦＳＲの復元された状態を示すビット０〜ビット２２の値をそれぞれ表す。また、図示されている記号“＾”はＸＯＲ演算を表す。

ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［００］〜ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［２２］は、復元されるＬＦＳＲのビット０〜２２の値をそれぞれ示す。図１２に示すように、ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［００］〜ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［２２］は、引数ｉｎ［００］〜ｉｎ［２２］を用いて算出される。

例えば、ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［００］の値は、ｉｎ［００］、ｉｎ［０３］、ｉｎ［０７］、ｉｎ［０９］、ｉｎ［１０］、ｉｎ［１１］、ｉｎ［１２］、ｉｎ［１３］、ｉｎ［１４］、ｉｎ［１５］、ｉｎ［１６］、ｉｎ［１８］、ｉｎ［２０］、ｉｎ［２１］、およびｉｎ［２２］のＸＯＲ演算結果である。

同様にして、図１２に示すように、ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［００］〜ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［２２］は、引数ｉｎ［００］〜ｉｎ［２２］の値を用いたＸＯＲ演算により算出することができる。

図１０に戻り、レシーバ・デバイス４０は、アイデンティファイ・アドレス・フレームを構成するフレーム・セグメント４２を一括してデスクランブルするためのスクランブリングデータ４２Ｓを算出することもできる。３２バイトのアイデンティファイ・アドレス・フレーム（フレーム・セグメント４２）をデスクランブルするために、２５６ビット（＝３２バイト）のスクランブリングデータ４２Ｓが算出される。

レシーバ・デバイス４０は、例えば、ＥＯＡＦを含むプリミティブ・セグメント４３に後続するセグメント４４が受信される時点のＬＦＳＲの状態を、アイデンティファイ・アドレス・フレームの先頭のセグメントが受信される時点の状態まで後退するように遷移させる計算を用いて、スクランブリングデータ４２Ｓを算出する。

あるいは、レシーバ・デバイス４０は、例えば、ＥＯＡＦを含むプリミティブ・セグメント４３が受信される時点のＬＦＳＲの状態（例えば、図１２のｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［００］〜ｃａｌｃ＿ｎｅｘｔ＿ｌｆｓｒ［２２］）を、アイデンティファイ・アドレス・フレームの先頭のセグメントが受信される時点の状態まで後退するように遷移させる計算を用いて、スクランブリングデータ４２Ｓを算出してもよい。

図１３乃至図１８は、ＥＯＡＦを含むプリミティブ・セグメント４３が受信される時点のＬＦＳＲの状態を、アイデンティファイ・アドレス・フレームの先頭のセグメントが受信される時点の状態まで後退するように遷移させる過程において、２５６ビットのスクランブリングデータ４２Ｓを数値計算により算出するための関数ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ（ｉｎｐｕｔ ［２２：００］ ｉｎ）の例を示す。

この関数の引数ｉｎとして、ＬＦＳＲの同期用状態（ここでは、ＥＯＡＦを含むプリミティブ・セグメント４３が受信される時点のＬＦＳＲの状態）を示す２３ビットの値が用いられる。したがって、引数ｉｎ［００］〜ｉｎ［２２］が、ＬＦＳＲの同期用状態を示すビット０〜ビット２２の値をそれぞれ表す。また、図示されている記号“＾”はＸＯＲ演算を表す。

ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［０００］〜ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［２５５］は、算出されるスクランブリングデータ４２Ｓのビット０〜２５５の値をそれぞれ示す。図１３乃至図１８に示すように、ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［０００］〜ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［２５５］は、引数ｉｎ［００］〜ｉｎ［２２］を用いて算出される。

例えば、ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［０００］の値は、ｉｎ［００］の値と等しい。ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［００１］の値は、ｉｎ［０１］の値と等しい。また、ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［００２］の値は、ｉｎ［００］の値とｉｎ［０２］の値とのＸＯＲ演算結果である。

同様にして、図１３乃至図１８に示すように、ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［０００］〜ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［２５５］は、引数ｉｎ［００］〜ｉｎ［２２］の値を用いて、あるいは引数ｉｎ［００］〜ｉｎ［２２］の値を用いたＸＯＲ演算により、算出することができる。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から受信され、フレーム・バッファ１１Ａに保存されたフレーム・セグメント４２と、算出されたスクランブリングデータ４２Ｓ（例えば、図１３乃至図１８のｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［０００］〜ｒｏｌｌ＿ｂａｃｋ＿ｌｆｓｒ［２５５］）とをＸＯＲ演算することにより、フレーム・セグメント４２をデスクランブルする。

そして、レシーバ・デバイス４０は、デスクランブルされたフレーム・セグメント４２のＣＲＣを検証する。ＣＲＣエラーが発生していないならば、レシーバ・デバイス４０は、デスクランブルされたフレーム・セグメント４２を、トランスミッタ・デバイス３０から受信され、デスクランブルされたアイデンティファイ・アドレス・フレームとして用いることができる。したがって、デスクランブラ１０８によってデスクランブルされたフレーム・セグメントにＣＲＣエラーが発生した場合に、そのＣＲＣエラーが発生したフレーム・セグメントを、スクランブルデータ４２Ｓを用いてデスクランブルされたフレーム・セグメント４２に置き換えることができる。

さらに、デスクランブルされたフレーム・セグメント４２にＣＲＣエラーが発生していないならば、デスクランブラ１０８内のＬＦＳＲ１７Ａを、例えば、後続するセグメント４４が受信される時点の状態を示す同期用状態に設定することにより、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラ１０４とを同期させることができる。

以上により、受信されたアイデンティファイ・アドレス・フレームをデスクランブラ１０８によってデスクランブルした場合にＣＲＣエラーが発生していたとしても、当該フレーム内の既定値フィールドの値と対応する既定期待値とを用いて、フレームを適切にデスクランブルすることができると共に、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラ１０４とを同期させることができる。

図１９は、オープン・アドレス・フレームのフォーマットの例を示す。オープン・アドレス・フレームは３２バイトのサイズを有している。

図１９に示すように、オープン・アドレス・フレームには、その４バイト目から１１バイト目までに、８バイト（＝６４ビット）のサイズを有するＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドが含まれている。ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドには、０ビット目から６３ビット目までの各ビットの値が設定されている。

このＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドには、このフレームを受信するレシーバ・デバイス４０のＳＡＳアドレスが設定される。レシーバ・デバイス４０において自身のＳＡＳアドレスは既知であり、したがって、レシーバ・デバイス４０にとって既定の値がＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドに設定されることになる。そのため、ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールド内の連続する少なくともＮビットを、既定値フィールドとして用いることができる。２３ビットのＬＦＳＲ１７Ａが用いられる場合、Ｎ＝２３である。

また、オープン・アドレス・フレームには、その２５バイト目から２７バイト目までに、３バイト（＝２４ビット）のサイズを有するＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドが含まれている。ＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドには、０ビット目から２４ビット目までの各ビットの値が設定されている。

ＳＡＳ Ｇｅｎ５の規格において、このＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドの各ビットには０が設定されるべきことが規定されている。つまり、ＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドには既定値が設定される。そのため、このＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールド内の連続する少なくとも２３ビットを、既定値フィールドとして用いてもよい。

図２０を参照して、オープン・アドレス・フレーム内の既定値フィールドを用いて、ＬＦＳＲの状態とスクランブリングデータとが算出される例を説明する。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から、フレームの開始を示すＳＯＡＦを含むプリミティブ・セグメント５１を受信した後、オープン・アドレス・フレームを構成する複数のフレーム・セグメント５２を受信する。フレーム・バッファ１１Ａには、少なくとも、オープン・アドレス・フレームの先頭から、既定値フィールドであるＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドまでのフレームデータが、例えば、オープン・アドレス・フレームの０バイト目から１１バイト目までのフレームデータが、保存される。

なお、オープン・アドレス・フレームの先頭から、ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールド内の連続する少なくとも２３ビットを含むフレーム・セグメントまでが、フレーム・バッファ１１Ａに保存されてもよい。この場合、オープン・アドレス・フレームの０バイト目から７バイト目までのフレームデータが、フレーム・バッファ１１Ａに保存される。

レシーバ・デバイス４０は、保存されたオープン・アドレス・フレームのＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの値（ここでは、４バイト目から７バイト目までの値）５２１と、既定期待値１５０として自身のＳＡＳアドレスの３２ビット目から６３ビット目までの値（以下、ＳＡＳアドレス［６３：３２］と表記する）１５０ＡとをＸＯＲ演算する。これにより、このＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの値５２１の算出に用いられたスクランブリングデータ５２１Ｓが算出される。なお、ＬＦＳＲ１７Ａが２３ビットである場合、ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの値と自身のＳＡＳアドレス［６３：３２］１５０Ａとは３２ビット（＝４バイト）のサイズを有しているので、その内の連続した少なくとも２３ビットがＸＯＲ演算に用いられてもよい。

レシーバ・デバイス４０は、スクランブリングデータ５２１Ｓに基づいて、このスクランブリングデータ５２１Ｓが算出された時点のＬＦＳＲの状態を算出できる。ＬＦＳＲの状態は、例えば、ＬＦＳＲを構成する各ビットの値で表される。

また、レシーバ・デバイス４０は、算出されたＬＦＳＲの状態が前進するように遷移させる計算か、あるいは算出されたＬＦＳＲの状態が後退するように遷移させる計算を用いて、任意の時点のＬＦＳＲの状態を算出することができる。例えば、レシーバ・デバイス４０は、オープン・アドレス・フレームを構成するフレーム・セグメント５２の内のあるフレーム・セグメントが受信される時点のＬＦＳＲの状態、フレームの送信完了を示すＥＯＡＦを含むプリミティブ・セグメント５３が受信される時点のＬＦＳＲの状態、あるいは、このＥＯＡＦを含むプリミティブ・セグメント５３に後続するセグメント５４が受信される時点のＬＦＳＲの状態、等を算出できる。

レシーバ・デバイス４０は、この任意の時点のＬＦＳＲの状態として、レシーバ・デバイス４０のデスクランブラ１０８内のＬＦＳＲを、トランスミッタ・デバイス３０のスクランブラ１０４内のＬＦＳＲに同期させるための同期用状態を算出することもできる。同期用状態には、例えば、オープン・アドレス・フレームの送信完了を示すＥＯＡＦを含むプリミティブ・セグメント５３が受信される時点のＬＦＳＲの状態、あるいは、このＥＯＡＦを含むプリミティブ・セグメント５３に後続するセグメント５４が受信される時点のＬＦＳＲの状態が用いられる。

さらに、レシーバ・デバイス４０は、オープン・アドレス・フレームを構成するフレーム・セグメント５２をデスクランブルするためのスクランブリングデータ５２Ｓを算出することもできる。レシーバ・デバイス４０は、例えば、ＥＯＡＦを含むプリミティブ・セグメント５３に後続するセグメント５４が受信される時点のＬＦＳＲの状態を、オープン・アドレス・フレームの先頭のセグメントが受信される時点の状態まで後退するように遷移させる計算を用いて、スクランブリングデータ５２Ｓを算出する。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から受信され、フレーム・バッファ１１Ａに保存されたフレーム・セグメント５２と、算出されたスクランブリングデータ５２ＳとをＸＯＲ演算することにより、フレーム・セグメント５２をデスクランブルする。

そして、レシーバ・デバイス４０は、デスクランブルされたフレーム・セグメント５２のＣＲＣを検証する。ＣＲＣエラーが発生していないならば、レシーバ・デバイス４０は、デスクランブルされたフレーム・セグメント５２を、トランスミッタ・デバイス３０から受信され、デスクランブルされたオープン・アドレス・フレームとして用いることができる。したがって、デスクランブラ１０８によってデスクランブルされたフレーム・セグメントにＣＲＣエラーが発生した場合に、そのＣＲＣエラーが発生したフレーム・セグメントを、スクランブリングデータ５２Ｓを用いてデスクランブルされたフレーム・セグメント５２に置き換えることができる。

さらに、デスクランブルされたフレーム・セグメント５２にＣＲＣエラーが発生していないならば、デスクランブラ１０８内のＬＦＳＲ１７Ａを、例えば、後続するセグメント５４が受信される時点のＬＦＳＲの状態を示す同期用状態に設定することにより、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラ１０４とを同期させることができる。

図２１は、オープン・アドレス・フレーム内の、ＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドを用いて、ＬＦＳＲの状態とスクランブリングデータとが算出される例を示す。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から、フレームの開始を示すＳＯＡＦを含むプリミティブ・セグメント５１を受信した後、オープン・アドレス・フレームを構成する複数のフレーム・セグメント５２を受信する。フレーム・バッファ１１Ａには、少なくとも、オープン・アドレス・フレームの先頭から、既定値フィールドであるＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドまでのフレームデータが、すなわち、オープン・アドレス・フレームの０バイト目から２７バイト目までのフレームデータが、保存される。

上述したように、ＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドには、ＳＡＳ Ｇｅｎ５の規格において０が設定されるべきことが規定されている。そのため、スクランブリングデータとのＸＯＲ演算によりスクランブルされたＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドの値は、そのスクランブリングデータと同一の値になる。

したがって、レシーバ・デバイス４０は、保存されたアイデンティファイ・アドレス・フレームのＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドの値（すなわち、２５バイト目から２７バイト目までの値）５２２を、この値５２２の算出に用いられたスクランブリングデータ５２２Ｓとして算出する。なお、ＬＦＳＲ１７Ａが２３ビットで構成されている場合、ＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドは２４ビット（＝３バイト）のサイズを有しているので、その内の連続した２３ビットがスクランブリングデータ５２２Ｓとして算出されてもよい。

レシーバ・デバイス４０は、スクランブリングデータ５２２Ｓに基づいて、このスクランブリングデータ５２２Ｓが算出された時点のＬＦＳＲの状態を算出できる。ＬＦＳＲの状態とは、例えば、ＬＦＳＲを構成する各ビットの値である。

また、レシーバ・デバイス４０は、算出されたＬＦＳＲの状態が前進するように遷移させる計算か、あるいは算出されたＬＦＳＲの状態が後退するように遷移させる計算を用いて、任意の時点のＬＦＳＲの状態を算出することができる。例えば、レシーバ・デバイス４０は、オープン・アドレス・フレームを構成するフレーム・セグメント５２の内のあるフレーム・セグメントが受信される時点のＬＦＳＲの状態、オープン・アドレス・フレームの送信完了を示すＥＯＡＦを含むプリミティブ・セグメント５３が受信される時点のＬＦＳＲの状態、あるいは、このＥＯＡＦを含むプリミティブ・セグメント５３に後続するセグメント５４が受信される時点のＬＦＳＲの状態、等を算出できる。

レシーバ・デバイス４０は、この任意の時点のＬＦＳＲの状態として、レシーバ・デバイス４０のデスクランブラ１０８内のＬＦＳＲを、トランスミッタ・デバイス３０のスクランブラ１０４内のＬＦＳＲに同期させるための同期用状態を算出することもできる。同期用状態には、例えば、オープン・アドレス・フレームの送信完了を示すＥＯＡＦを含むプリミティブ・セグメント５３が受信される時点のＬＦＳＲの状態、あるいは、このＥＯＡＦを含むプリミティブ・セグメント５３に後続するセグメント５４が受信される時点のＬＦＳＲの状態が用いられる。

さらに、レシーバ・デバイス４０は、オープン・アドレス・フレームを構成するフレーム・セグメント５２をデスクランブルするためのスクランブリングデータ５２Ｓを算出することもできる。レシーバ・デバイス４０は、例えば、ＥＯＡＦを含むプリミティブ・セグメント５３に後続するセグメント５４が受信される時点のＬＦＳＲの状態を、オープン・アドレス・フレームの先頭のセグメントが受信される時点の状態まで後退するように遷移させる計算を用いて、スクランブリングデータ５２Ｓを算出する。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から受信され、フレーム・バッファ１１Ａに保存されたフレーム・セグメント５２と、算出されたスクランブリングデータ５２ＳとをＸＯＲ演算することにより、フレーム・セグメント５２をデスクランブルする。

レシーバ・デバイス４００は、デスクランブルされたフレーム・セグメント５２のＣＲＣを検証する。ＣＲＣエラーが発生していないならば、レシーバ・デバイス４０は、デスクランブルされたフレーム・セグメント５２を、トランスミッタ・デバイス３０から受信され、デスクランブルされたオープン・アドレス・フレームとして用いることができる。したがって、デスクランブラ１０８によってデスクランブルされたフレーム・セグメントにＣＲＣエラーが発生した場合に、そのＣＲＣエラーが発生したフレーム・セグメントを、スクランブリングデータ５２Ｓを用いてデスクランブルされたフレーム・セグメント５２に置き換えることができる。

さらに、デスクランブルされたフレーム・セグメント５２にＣＲＣエラーが発生していないならば、デスクランブラ１０８内のＬＦＳＲ１７Ａを、例えば、後続するセグメント４４が受信される時点のＬＦＳＲの状態を示す同期用状態に設定することにより、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラ１０４とを同期させることができる。

以上により、受信されたオープン・アドレス・フレームをデスクランブラ１０８によってデスクランブルした場合にＣＲＣエラーが発生していたとしても、当該フレーム内の既定値フィールドの値と対応する既定期待値とを用いて、フレームを適切にデスクランブルすることができると共に、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラとを同期させることができる。

図２２から図２７のフローチャートを参照して、イニシエータ／ターゲット１０，２０によって実行されるアドレス・フレームの送信制御処理、受信制御処理、および復元処理の手順について説明する。以下では、上述の記載と同様に、送信側のイニシエータ／ターゲット１０，２０をトランスミッタ・デバイス３０と記載し、受信側のイニシエータ／ターゲット１０，２０をレシーバ・デバイス４０と記載する。

図２２のフローチャートは、トランスミッタ・デバイス３０によって実行されるアドレス・フレームの送信制御処理の手順の例を示す。

まず、トランスミッタ・デバイス３０は、レシーバ・デバイス４０へアドレス・フレームを送信する必要があるか否かを判定する（ステップＳ１０１）。アドレス・フレームを送信する必要がない場合（ステップＳ１０１のＮＯ）、ステップＳ１０１に戻り、レシーバ・デバイス４０へアドレス・フレームを送信する必要があるか否かが再度判定される。なお、この場合に、トランスミッタ・デバイス３０は、例えば、アイドルｄｗｏｒｄセグメントを含むパケットをレシーバ・デバイス４０に送信してもよい。

アドレス・フレームを送信する必要がある場合（ステップＳ１０１のＹＥＳ）、トランスミッタ・デバイス３０は、ＳＯＡＦを生成し（ステップＳ１０２）、このＳＯＡＦを含むパケットをレシーバ・デバイス４０に送信するためのプリミティブ・セグメント送信処理を実行する（ステップＳ１０３）。このプリミティブ・セグメント処理については、図２３のフローチャートを参照して後述する。

次いで、トランスミッタ・デバイス３０は、フレームを構成する未送信のフレームデータがあるか否かを判定する（ステップＳ１０４）。未送信フレームデータがある場合（ステップＳ１０４のＹＥＳ）、トランスミッタ・デバイス３０は、１パケット分以上の未送信フレームデータがあるか否かを判定する（ステップＳ１０５）。１パケット分以上の未送信フレームデータがある場合（ステップＳ１０５のＹＥＳ）、トランスミッタ・デバイス３０は、未送信フレームデータで構成されるフレーム・セグメントを含むパケットをレシーバ・デバイス４０に送信するためのフレーム・セグメント送信処理を実行し（ステップＳ１０６）、ステップＳ１０４に戻る。フレーム・セグメント送信処理については、図２４のフローチャートを参照して後述する。

１パケット分以上の未送信フレームデータがない場合（ステップＳ１０５のＮＯ）、トランスミッタ・デバイス３０は、フレームを構成するフレームデータのＣＲＣ値を算出する（ステップＳ１０７）。そして、トランスミッタ・デバイス３０は、未送信フレームデータと算出されたＣＲＣ値とで構成されるフレーム・セグメントを含むパケットをレシーバ・デバイス４０に送信するためのフレーム・セグメント送信処理を実行する（ステップＳ１０８）。

また、未送信フレームデータがない場合（ステップＳ１０４のＮＯ）、例えば、フレームを構成する全てのフレームデータがレシーバ・デバイス４０に送信済みである場合、トランスミッタ・デバイス３０は、フレームを構成するフレームデータのＣＲＣ値を算出する（ステップＳ１０９）。そして、トランスミッタ・デバイス３０は、算出されたＣＲＣ値で構成されるフレーム・セグメントを含むパケットをレシーバ・デバイス４０に送信するためのフレーム・セグメント送信処理を実行する（ステップＳ１１０）。

フレームを構成する全てのフレームデータとＣＲＣ値とがパケット単位でレシーバ・デバイス４０に送信された後（ステップＳ１０８またはステップＳ１１０の後）、トランスミッタ・デバイス３０は、アドレス・フレームの送信完了を示すＥＯＡＦを生成し（ステップＳ１１１）、このＥＯＡＦを含むパケットをレシーバ・デバイス４０に送信するためのプリミティブ・セグメント送信処理を実行し（ステップＳ１１２）、処理を終了する。

図２３のフローチャートは、トランスミッタ・デバイス３０により実行されるプリミティブ・セグメント送信処理の手順の例を示す。

まず、トランスミッタ・デバイス３０は、送信されるプリミティブの種別に応じて処理を分岐する（ステップＳ２１）。プリミティブが送信される場合（ステップＳ２１のプリミティブ）、トランスミッタ・デバイス３０は、そのプリミティブを１２８ｂ１３０ｂ変換し、プリミティブ・セグメントを生成する（ステップＳ２２）。一方、バイナリ・プリミティブまたはエクステンデッド・バイナリ・プリミティブが送信される場合（ステップＳ２１のバイナリ・プリミティブまたはエクステンデッド・バイナリ・プリミティブ）、トランスミッタ・デバイス３０は、そのバイナリ・プリミティブまたはエクステンデッド・バイナリ・プリミティブを用いて、プリミティブ・セグメントを生成する（ステップＳ２３）。

次いで、トランスミッタ・デバイス３０は、スクランブラ１０４の状態を次の状態に遷移させる（ステップＳ２４）。つまり、トランスミッタ・デバイス３０は、スクランブラ１０４の動作回数（ＲＵＮ回数）を１だけ増加させる。

そして、トランスミッタ・デバイス３０は、ＦＥＣのためのパリティ・シンボルが付加されたパケットを生成し（ステップＳ２５）、当該パケットをレシーバ・デバイス４０に送信する（ステップＳ２６）。

以上により、プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブを含むパケットを送信することができる。その際、スクランブラ１０４は、プリミティブ、バイナリ・プリミティブ、またはエクステンデッド・バイナリ・プリミティブをスクランブルしないが、スクランブラ１０４の状態は次の状態に遷移する。

なお、送信されるプリミティブがＰＡＣＫＥＴ＿ＳＹＮＣである場合には、例えば、ステップＳ２４の後に、スクランブラ１０４が初期化される。この初期化により、スクランブラ１０４内のＬＦＳＲ１７Ａが初期状態に戻る。

図２４のフローチャートは、トランスミッタ・デバイス３０によって実行されるフレーム・セグメント送信処理の手順の例を示す。

まず、トランスミッタ・デバイス３０は、送信されるフレームデータとＣＲＣ値の少なくとも一方を含むフレーム・セグメントを生成する（ステップＳ３１）。トランスミッタ・デバイス３０は、スクランブラ１０４によりフレーム・セグメントをスクランブルする（ステップＳ３２）。そして、トランスミッタ・デバイス３０は、スクランブラ１０４の状態を次の状態に遷移させる（ステップＳ３３）。

次いで、トランスミッタ・デバイス３０は、ＦＥＣのためのパリティ・シンボルが付加されたパケットを生成し（ステップＳ３４）、当該パケットをレシーバ・デバイス４０に送信する（ステップＳ３５）。

以上により、フレームデータとＣＲＣ値の少なくとも一方を含むパケットを送信することができる。その際、フレームデータおよびＣＲＣ値がスクランブラ１０４によりスクランブルされると共に、スクランブラ１０４の状態は次の状態に遷移する。

図２５のフローチャートは、レシーバ・デバイス４０によって実行されるアドレス・フレームの受信制御処理の手順の例を示す。

まず、レシーバ・デバイス４０は、トランスミッタ・デバイス３０からパケットを受信したか否かを判定する（ステップＳ４０１）。パケットを受信していない場合（ステップＳ４０１のＮＯ）、ステップＳ４０１に戻り、パケットを受信したか否かが再度判定される。

パケットを受信した場合（ステップＳ４０１のＹＥＳ）、レシーバ・デバイス４０は、そのパケットにＦＥＣデコード処理を施す（ステップＳ４０２）。ＦＥＣデコード処理では、エラーの有無の判定、エラー位置の特定、エラー訂正、デコードの成功または失敗の通知等が行われる。ＦＥＣデコード処理が成功した場合には、レシーバ・デバイス４０は、デコードされたパケットに含まれるセグメントがプリミティブ・セグメントであるか否かを判定する（ステップＳ４０３）。

パケットに含まれるセグメントがプリミティブ・セグメントである場合（ステップＳ４０３のＹＥＳ）、レシーバ・デバイス４０は、デスクランブラ１０８の状態を次の状態に遷移させる（ステップＳ４０４）。

次いで、レシーバ・デバイス４０は、プリミティブ・セグメントにアドレス・フレームの送信開始を示すＳＯＡＦが含まれているか否かを判定する（ステップＳ４０５）。プリミティブ・セグメントにＳＯＡＦが含まれている場合（ステップＳ４０５のＹＥＳ）、レシーバ・デバイス４０はバッファフラグを立て（ステップＳ４０６）、ステップＳ４０１に戻る。バッファフラグは、受信されたセグメントをフレーム・バッファ１１Ａに保存するか否かを示す。このバッファフラグが立っている間に受信されたプリミティブ・セグメント以外のセグメントは、フレーム・バッファ１１Ａに保存される。

プリミティブ・セグメントにＳＯＡＦが含まれていない場合（ステップＳ４０５のＮＯ）、レシーバ・デバイス４０は、プリミティブ・セグメントにＰＡＣＫＥＴ＿ＳＹＮＣが含まれているか否かを判定する（ステップＳ４０７）。プリミティブ・セグメントにＰＡＣＫＥＴ＿ＳＹＮＣが含まれている場合（ステップＳ４０７のＹＥＳ）、レシーバ・デバイス４０は、デスクランブラ１０８を初期化し（ステップＳ４０８）、ステップＳ４０１に戻る。この初期化により、デスクランブラ１０８内のＬＦＳＲ１７Ａが初期状態に戻る。

また、プリミティブ・セグメントにＰＡＣＫＥＴ＿ＳＹＮＣが含まれていない場合（ステップＳ４０７のＮＯ）、レシーバ・デバイス４０は、プリミティブ・セグメントにアドレス・フレームの送信完了を示すＥＯＡＦが含まれているか否かを判定する（ステップＳ４０９）。プリミティブ・セグメントにＥＯＡＦが含まれている場合（ステップＳ４０９のＹＥＳ）、受信フレーム１５を検証し、必要に応じて復元フレーム１５７に置換するための検証処理を実行する（ステップＳ４１０）。レシーバ・デバイス４０は、バッファフラグをクリアする（ステップＳ４１１）。そして、レシーバ・デバイス４０は、受信されたセグメントが保存されたフレーム・バッファ１１Ａ内の領域を解放し（ステップＳ４１２）、ステップＳ４０１に戻る。検証処理については、図２７のフローチャートを参照して後述する。

プリミティブ・セグメントにＥＯＡＦが含まれていない場合（ステップＳ４０９のＮＯ）、そのプリミティブ・セグメントに含まれるプリミティブに応じた動作を行い（ステップＳ４１１）、ステップＳ４０１に戻る。

また、パケットに含まれるセグメントがプリミティブ・セグメントでない場合（ステップＳ４０３のＮＯ）、レシーバ・デバイス４０はバッファフラグが立っているか否かを判定する（ステップＳ４１４）。プリミティブ・セグメントでないセグメントは、アイドルｄｗｏｒｄセグメント、およびスクランブルド・アイドル・セグメントのいずれかである。バッファフラグが立っている場合（ステップＳ４１４のＹＥＳ）、レシーバ・デバイス４０はセグメントをフレーム・バッファ１１Ａに保存する（ステップＳ４１５）。フレーム・バッファ１１Ａに保存されるセグメントは、ＳＯＡＦを含むパケットが受信されてから、ＥＯＡＦを含むパケットが受信されるまでの間に受信されるセグメントである。フレーム・バッファ１１Ａに保存されたセグメントは、デスクランブラ１０８内のＬＦＳＲ１７Ａを任意の時点の状態に設定し、受信フレーム１５を適切にデスクランブルするための復元処理に用いられる。復元処理については、図２６のフローチャートを参照して後述する。なお、バッファフラグがクリアされている場合（ステップＳ４１４のＮＯ）、ステップＳ４１５はスキップされる。

次いで、レシーバ・デバイス４０は、セグメントを、デスクランブラ１０８を用いてデスクランブルする（ステップＳ４１６）。そして、レシーバ・デバイス４０は、デスクランブラ１０８の状態を次の状態に遷移させ（ステップＳ４１７）、すなわち、デスクランブラ１０８の動作回数（ＲＵＮ回数）を１だけ増加させ、ステップＳ４０１に戻る。

図２６のフローチャートは、レシーバ・デバイス４０によって実行される復元処理の手順の例を示す。この復元処理は、上述した受信制御処理と並行して実行され得る。

まず、レシーバ・デバイス４０は、受信されているアドレス・フレームのタイプを識別する（ステップＳ５１）。レシーバ・デバイス４０は、例えば、ＳＯＡＦが受信された後に後にフレーム・バッファ１１Ａに保存される情報を、アイデンティファイ・アドレス・フレームの交換後であれば、オープン・アドレス・フレームと判断し、その交換前であれば、アイデンティファイ・アドレス・フレームと判断する。

レシーバ・デバイス４０は、識別されたアドレス・フレームのタイプに応じて、フレーム内の既定値フィールドを設定する（ステップＳ５２）。上述したように、既定値フィールドは、受信されているアドレス・フレームのタイプによって異なる。例えば、レシーバ・デバイス４０は、フレームがアイデンティファイ・アドレス・フレームである場合、フレーム内の２３バイト目から２７バイト目までのＲｅｓｅｒｖｅｄフィールドの内の少なくとも２３ビットを、既定値フィールドとして設定する。また、レシーバ・デバイス４０は、フレームがオープン・アドレス・フレームである場合、フレーム内の４バイト目から１１バイト目までのＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの内の少なくとも２３ビットか、あるいは２５バイト目から２７バイト目までのＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールドの内の少なくとも２３ビットを、既定値フィールドとして設定する。

次いで、レシーバ・デバイス４０は、フレーム・バッファ１１Ａに、設定された既定値フィールドの値１５１が保存されたか否かを判定する（ステップＳ５３）。既定値フィールドの値１５１が保存されていない場合（ステップＳ５３のＮＯ）、ステップＳ５３に戻り、既定値フィールドの値１５１が保存されたか否かが再度判定される。

既定値フィールドの値１５１が保存された場合（ステップＳ５３のＮＯ）、レシーバ・デバイス４０は、保存された既定値フィールドの値１５１と、スクランブリング前にその既定値フィールドに設定されているべき既定期待値１５０とをＸＯＲ演算することにより、この既定値フィールドの値１５１の生成に用いられた第１スクランブリングデータ１５２を生成する（ステップＳ５４）。そして、レシーバ・デバイス４０は、第１スクランブリングデータ１５２を用いて、対応するＬＦＳＲの状態を算出する（ステップＳ５５）。

次いで、レシーバ・デバイス４０は、デスクランブラ１０８内のＬＦＳＲ１７Ａを、トランスミッタ・デバイス３０のスクランブラ１０４内のＬＦＳＲ１７Ａに同期させるために、デスクランブラ１０８内のＬＦＳＲ１７Ａに設定すべき同期用状態を算出する（ステップＳ５６）。レシーバ・デバイス４０は、例えば、デスクランブラ１０８によって次にデスクランブルされるべきパケットを決定し、そのパケット内のセグメントを適切にデスクランブルするためのＬＦＳＲの状態を同期用状態として算出する。デスクランブラ１０８によって次にデスクランブルされるべきパケットは、例えば、受信しているアドレス・フレームに後続するＥＯＡＦを含むパケットや、このＥＯＡＦを含むパケットの次のパケットである。

レシーバ・デバイス４０は、ＬＦＳＲを、算出された同期用状態から後退するように遷移させる計算により、受信されているアドレス・フレームをデスクランブルするための第２スクランブリングデータ１５６を生成する（ステップＳ５７）。第２スクランブリングデータ１５６は、例えば、図１３乃至図１８に示したような、３２バイトのアドレス・フレームを復元するための２５６ビットのパターンである。

次いで、レシーバ・デバイス４０は、受信されているアドレス・フレームを構成する全てのフレームデータがフレーム・バッファ１１Ａに保存されたか否かを判定する（ステップＳ５８）。アドレス・フレームを構成する全てのフレームデータがフレーム・バッファ１１Ａに保存されていない場合（ステップＳ５８のＮＯ）、ステップＳ５８に戻る。

一方、アドレス・フレームを構成する全てのフレームデータがフレーム・バッファ１１Ａに保存された場合（ステップＳ５８のＹＥＳ）、レシーバ・デバイス４０は、第２スクランブリングデータ１５６を用いて、保存された受信フレーム１５のフレームデータをデスクランブルすることにより、復元フレーム１５７を生成する（ステップＳ５９）。

これにより、ＰＡＣＫＥＴ＿ＳＹＮＣを受信し、初期化された時点からの動作回数に応じてデスクランブラ１０８（ＬＦＳＲ１７Ａ）によって生成されたスクランブリングデータではなく、受信フレーム１５内の既定値フィールドの値１５１とそれに対応する既定期待値１５０とを用いて算出された第２スクランブリングデータ１５６を用いて、受信フレーム１５内のフレームデータがデスクランブルされた復元フレーム１５７を取得することができる。

図２７のフローチャートは、レシーバ・デバイス４０によって実行されるアドレス・フレームの検証処理の手順の例を示す。この検証処理は、図２５のフローチャートを参照して上述したように、例えば、アドレス・フレームの送信完了を示すＥＯＡＦが受信されたことに応じて実行される。ここでは、検証処理が開始される前に復元処理が完了していることを想定する。

まず、レシーバ・デバイス４０は、デスクランブラ１０８によってデスクランブルされたセグメントで構成される受信フレーム１５のＣＲＣを検証し（ステップＳ６０１）、受信フレーム１５にＣＲＣエラーが発生しているか否かを判定する（ステップＳ６０２）。

受信フレーム１５にＣＲＣエラーが発生していない場合（ステップＳ６０２のＮＯ）、レシーバ・デバイス４０は、この受信フレーム１５に応じて、応答のためのプリミティブ・セグメントとフレーム・セグメントの少なくとも一方を生成し、生成されたセグメントを含むパケットをトランスミッタ・デバイス３０に送信する（ステップＳ６０８）。例えば、受信フレームが接続要求のためのオープン・アドレス・フレームである場合には、接続要求を受け入れるＯＰＥＮ＿ＡＣＣＥＰＴプリミティブか、あるいは接続要求を拒絶するＯＰＥＮ＿ＲＥＪＥＣＴプリミティブを含むパケットが送信される。また、受信フレームがアイデンティファイ・アドレス・フレームである場合には、応答のためのアイデンティファイ・アドレス・フレームを送信するために、ＳＯＡＦプリミティブ、当該フレームを構成するフレーム・セグメント、およびＥＯＡＦプリミティブを含むパケットが送信される。この送信では、図２３および図２４を参照して上述したプリミティブ・セグメント送信処理およびフレーム・セグメント送信処理が実行され得る。

一方、受信フレーム１５にＣＲＣエラーが発生している場合（ステップＳ６０２のＹＥＳ）、レシーバ・デバイス４０は、復元処理において生成された復元フレーム１５７のＣＲＣを検証し（ステップＳ６０３）、復元フレーム１５７にＣＲＣエラーが発生しているか否かを判定する（ステップＳ６０４）。

復元フレーム１５７にＣＲＣエラーが発生している場合（ステップＳ６０４のＹＥＳ）、レシーバ・デバイス４０は、受信フレーム１５および復元フレーム１５７を破棄し（ステップＳ６０５）、トランスミッタ・デバイス３０に対して何等応答しない。つまり、受信フレーム１５と復元フレーム１５７の両方にＣＲＣエラーが発生している場合に、それらフレームが破棄される。

一方、復元フレーム１５７にＣＲＣエラーが発生していない場合（ステップＳ６０４のＮＯ）、レシーバ・デバイス４０は、受信フレーム１５を復元フレーム１５７に置き換える（ステップＳ６０６）。つまり、ＣＲＣエラーが発生している受信フレーム１５が破棄され、復元フレーム１５７がトランスミッタ・デバイス３０から受信されたフレームとして処理される。レシーバ・デバイス４０は、デスクランブラ１０８内のＬＦＳＲ１７Ａを、復元処理により算出された同期用状態に設定する（ステップＳ６０７）。そして、レシーバ・デバイス４０は、復元フレーム１５７に応じて、応答のためのプリミティブ・セグメントとフレーム・セグメントの少なくとも一方を生成し、生成されたセグメントを含むパケットをトランスミッタ・デバイス３０に送信する（ステップＳ６０８）。

以上の処理により、レシーバ・デバイス４０では、受信されたアドレス・フレームをデスクランブラ１０８によってデスクランブルした場合にＣＲＣエラーが発生していたとしても、当該フレーム内の既定値フィールドの値と対応する既定期待値とを用いて、フレームを適切にデスクランブルすることができると共に、当該レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラとを同期させることができる。

図２８は、ＳＳＰフレームのフォーマットの例を示す。ＳＳＰフレームは任意のサイズを有している。

図２８に示すように、ＳＳＰフレームには、その１バイト目から３バイト目までに、３バイト（＝２４ビット）のサイズを有するＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドが含まれている。ＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドには、０ビット目から２３ビット目までの各ビットの値が設定されている。

このＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドには、このフレームを受信するレシーバ・デバイス４０のＳＡＳアドレスのハッシュ値が設定される。レシーバ・デバイス４０において自身のＳＡＳアドレスのハッシュ値は既知であり、したがって、このレシーバ・デバイス４０にとって既定の値がＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールド設定されることになる。そのため、ＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールド内の連続する少なくともＮビットを、既定値フィールドとして用いることができる。２３ビットのＬＦＳＲ１７Ａが用いられる場合、Ｎ＝２３である。

図２９を参照して、ＳＳＰフレーム内の既定値フィールドを用いて、ＬＦＳＲの状態とスクランブリングデータとが算出される例を説明する。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から、フレームの開始を示すＳＯＦを含むプリミティブ・セグメント６１を受信した後、ＳＳＰフレームを構成する複数のフレーム・セグメント６２を受信する。フレーム・バッファ１１Ａには、少なくとも、ＳＳＰフレームの先頭から、既定値フィールドであるＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドまでのフレームデータが、すなわち、ＳＳＰフレームの０バイト目から３バイト目までのフレームデータが、保存される。

レシーバ・デバイス４０は、保存されたＳＳＰフレームのＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの値（すなわち、１バイト目から３バイト目までの値）６２１と、既定期待値１５０として自身のＳＡＳアドレスのハッシュ値１５０ＢとをＸＯＲ演算する。これにより、このＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの値６２１の算出に用いられたスクランブリングデータ６２１Ｓが算出される。なお、ＬＦＳＲ１７Ａが２３ビットで構成されている場合、ＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの値と自身のＳＡＳアドレスのハッシュ値１５０Ｂとは２４ビット（＝３バイト）のサイズを有しているので、その内の連続した２３ビットがＸＯＲ演算に用いられてもよい。

レシーバ・デバイス４０は、スクランブリングデータ６２１Ｓに基づいて、このスクランブリングデータ６２１Ｓが算出された時点のＬＦＳＲの状態を算出できる。ＬＦＳＲの状態は、例えば、ＬＦＳＲを構成する各ビットの値で表される。

また、レシーバ・デバイス４０は、算出されたＬＦＳＲの状態が前進するように遷移させる計算か、あるいは算出されたＬＦＳＲの状態が後退するように遷移させる計算を用いて、任意の時点のＬＦＳＲの状態を算出することができる。例えば、レシーバ・デバイス４０は、ＳＳＰフレームを構成するフレーム・セグメント６２の内のあるフレーム・セグメントが受信される時点のＬＦＳＲの状態、ＳＳＰフレームの送信完了を示すＢ＿ＥＯＦｓを含むプリミティブ・セグメント６３が受信される時点のＬＦＳＲの状態、あるいは、このＢ＿ＥＯＦｓを含むプリミティブ・セグメント６３に後続するセグメント６４が受信される時点のＬＦＳＲの状態、等を算出できる。

さらに、レシーバ・デバイス４０は、ＳＳＰフレームを構成するフレーム・セグメント６２をデスクランブルするためのスクランブリングデータ６２Ｓを算出することもできる。レシーバ・デバイス４０は、例えば、Ｂ＿ＥＯＦｓを含むプリミティブ・セグメント６３に後続するセグメント６４が受信される時点のＬＦＳＲの状態を、ＳＳＰフレームの先頭のセグメントが受信される時点の状態まで後退するように遷移させる計算を用いて、スクランブリングデータ６２Ｓを算出する。あるいは、レシーバ・デバイス４０は、ＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの値６２１の算出に用いられたスクランブリングデータ６２１Ｓが算出された時点のＬＦＳＲの状態を、ＳＳＰフレームの先頭のセグメントが受信される時点の状態まで後退するように遷移させる計算と、ＳＳＰフレームの末尾のセグメントが受信される時点の状態まで前進するように遷移させる計算とを用いて、スクランブリングデータ６２Ｓを算出してもよい。

レシーバ・デバイス４０は、トランスミッタ・デバイス３０から受信され、フレーム・バッファ１１Ａに保存されたフレーム・セグメント６２と、算出されたスクランブリングデータ６２ＳとをＸＯＲ演算することにより、フレーム・セグメント６２をデスクランブルする。

そして、レシーバ・デバイス４０は、デスクランブルされたフレーム・セグメント６２のＣＲＣを検証する。ＣＲＣエラーが発生していないならば、レシーバ・デバイス４０は、デスクランブルされたフレーム・セグメント６２を、トランスミッタ・デバイス３０から受信され、デスクランブルされたＳＳＰフレームとして用いることができる。したがって、デスクランブラ１０８によってデスクランブルされたフレーム・セグメントにＣＲＣエラーが発生した場合に、そのＣＲＣエラーが発生したフレーム・セグメントを、スクランブリングデータ６２Ｓを用いてデスクランブルされたフレーム・セグメント６２に置き換えることができる。

さらに、デスクランブルされたフレーム・セグメント６２にＣＲＣエラーが発生していないならば、デスクランブラ１０８内のＬＦＳＲ１７Ａを、例えば、後続するセグメント６４が受信される時点の状態に設定することにより、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラ１０４とを同期させることができる。

以上により、受信されたＳＳＰフレームをデスクランブラ１０８によってデスクランブルした場合にＣＲＣエラーが発生していたとしても、当該フレーム内の既定値フィールドの値と対応する既定期待値とを用いて、フレームを適切にデスクランブルすることができると共に、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラとを同期させることができる。

図３０のフローチャートは、トランスミッタ・デバイス３０によって実行されるＳＳＰフレームの送信制御処理の手順の例を示す。

まず、トランスミッタ・デバイス３０は、レシーバ・デバイス４０へＳＳＰフレームを送信する必要があるか否かを判定する（ステップＳ７０１）。フレームを送信する必要がない場合（ステップＳ７０１のＮＯ）、ステップＳ７０１に戻り、レシーバ・デバイス４０へフレームを送信する必要があるか否かが再度判定される。なお、この場合に、トランスミッタ・デバイス３０は、例えば、アイドルｄｗｏｒｄセグメントを含むパケットをレシーバ・デバイス４０に送信してもよい。

フレームを送信する必要がある場合（ステップＳ７０１のＹＥＳ）、トランスミッタ・デバイス３０は、ＳＯＦを生成し（ステップＳ７０２）、このＳＯＦを含むパケットをレシーバ・デバイス４０に送信するためのプリミティブ・セグメント送信処理を実行する（ステップＳ７０３）。このプリミティブ・セグメント処理については、図２３のフローチャートを参照して上述した通りである。

次いで、トランスミッタ・デバイス３０は、フレームを構成する未送信のフレームデータがあるか否かを判定する（ステップＳ７０４）。未送信フレームデータがある場合（ステップＳ７０４のＹＥＳ）、トランスミッタ・デバイス３０は、１パケット分以上の未送信フレームデータがあるか否かを判定する（ステップＳ７０５）。１パケット分のフレームデータは、例えば、４つのｄｗｏｒｄに相当するフレームデータである。１パケット分以上の未送信フレームデータがある場合（ステップＳ７０５のＹＥＳ）、トランスミッタ・デバイス３０は、未送信フレームデータで構成されるフレーム・セグメントを含むパケットをレシーバ・デバイス４０に送信するためのフレーム・セグメント送信処理を実行し（ステップＳ７０６）、ステップＳ７０４に戻る。フレーム・セグメント送信処理については、図２４のフローチャートを参照して上述した通りである。

１パケット分以上の未送信フレームデータがない場合（ステップＳ７０５のＮＯ）、トランスミッタ・デバイス３０は、フレームを構成するフレームデータのＣＲＣ値を算出する（ステップＳ７０７）。そして、トランスミッタ・デバイス３０は、未送信フレームデータと算出されたＣＲＣ値とで構成されるフレーム・セグメントを含むパケットをレシーバ・デバイス４０に送信するためのフレーム・セグメント送信処理を実行する（ステップＳ７０８）。

また、未送信フレームデータがない場合（ステップＳ７０４のＮＯ）、例えば、フレームを構成する全てのフレームデータがレシーバ・デバイス４０に送信済みである場合、トランスミッタ・デバイス３０は、フレームを構成するフレームデータのＣＲＣ値を算出する（ステップＳ７０９）。そして、トランスミッタ・デバイス３０は、算出されたＣＲＣ値とパッドｄｗｏｒｄとで構成されるフレーム・セグメントを含むパケットをレシーバ・デバイス４０に送信するためのフレーム・セグメント送信処理を実行する（ステップＳ７１０）。

フレームを構成する全てのフレームデータとＣＲＣ値とがパケット単位でレシーバ・デバイス４０に送信された後（ステップＳ７０８またはステップＳ７１０の後）、トランスミッタ・デバイス３０は、フレームの送信完了を示すＢ＿ＥＯＦｓを生成し（ステップＳ７１１）、このＢ＿ＥＯＦｓを含むパケットをレシーバ・デバイス４０に送信するためのプリミティブ・セグメント送信処理を実行する（ステップＳ７１２）、処理を終了する。

図３１のフローチャートは、レシーバ・デバイス４０によって実行されるＳＳＰフレームの受信制御処理の手順の例を示す。

まず、レシーバ・デバイス４０は、トランスミッタ・デバイス３０からパケットを受信したか否かを判定する（ステップＳ８０１）。パケットを受信していない場合（ステップＳ８０１のＮＯ）、ステップＳ８０１に戻り、パケットを受信したか否かが再度判定される。

パケットを受信した場合（ステップＳ８０１のＹＥＳ）、レシーバ・デバイス４０は、そのパケットにＦＥＣデコード処理を施す（ステップＳ８０２）。ＦＥＣデコード処理では、エラーの有無の判定、エラー位置の特定、エラー訂正、デコードの成功または失敗の通知等が行われる。ＦＥＣデコード処理が成功した場合には、レシーバ・デバイス４０は、デコードされたパケットに含まれるセグメントがプリミティブ・セグメントであるか否かを判定する（ステップＳ８０３）。

パケットに含まれるセグメントがプリミティブ・セグメントである場合（ステップＳ８０３のＹＥＳ）、レシーバ・デバイス４０は、デスクランブラ１０８の状態を次の状態に遷移させる（ステップＳ８０４）。

次いで、レシーバ・デバイス４０は、プリミティブ・セグメントにＳＳＰフレームの送信開始を示すＳＯＦが含まれているか否かを判定する（ステップＳ８０５）。プリミティブ・セグメントにＳＯＦが含まれている場合（ステップＳ８０５のＹＥＳ）、レシーバ・デバイス４０はバッファフラグを立て（ステップＳ８０６）、ステップＳ８０１に戻る。バッファフラグは、受信されたセグメントをフレーム・バッファ１１Ａに保存するか否かを示す。このバッファフラグが立っている間に受信されたプリミティブ・セグメント以外のセグメントは、フレーム・バッファ１１Ａに保存される。

プリミティブ・セグメントにＳＯＦが含まれていない場合（ステップＳ８０５のＮＯ）、レシーバ・デバイス４０は、プリミティブ・セグメントにＰＡＣＫＥＴ＿ＳＹＮＣが含まれているか否かを判定する（ステップＳ８０７）。プリミティブ・セグメントにＰＡＣＫＥＴ＿ＳＹＮＣが含まれている場合（ステップＳ８０７のＹＥＳ）、レシーバ・デバイス４０は、デスクランブラ１０８を初期化し（ステップＳ８０８）、ステップＳ８０１に戻る。この初期化により、デスクランブラ１０８内のＬＦＳＲ１７Ａが初期状態に戻る。

また、プリミティブ・セグメントにＰＡＣＫＥＴ＿ＳＹＮＣが含まれていない場合（ステップＳ８０７のＮＯ）、レシーバ・デバイス４０は、プリミティブ・セグメントにＳＳＰフレームの送信完了を示すＢ＿ＥＯＦｓが含まれているか否かを判定する（ステップＳ８０９）。Ｂ＿ＥＯＦｓは、Ｂ_ＥＯＦ（０）、Ｂ_ＥＯＦ（１）、Ｂ_ＥＯＦ（２）、Ｂ_ＥＯＦ（３）、Ｂ_ＥＯＦ（０）（ＲＥＳＥＲＶＥＤ １）、Ｂ_ＥＯＦ（１）（ＲＥＳＥＲＶＥＤ １）、Ｂ_ＥＯＦ（１）（ＲＥＳＥＲＶＥＤ ２）、Ｂ_ＥＯＦ（２）（ＲＥＳＥＲＶＥＤ １）、Ｂ_ＥＯＦ（２）（ＲＥＳＥＲＶＥＤ ２）、Ｂ_ＥＯＦ（３）（ＲＥＳＥＲＶＥＤ １）、およびＢ_ＥＯＦ（３）（ＲＥＳＥＲＶＥＤ ２）である。プリミティブ・セグメントにＢ＿ＥＯＦｓが含まれている場合（ステップＳ８０９のＹＥＳ）、受信フレーム１５を検証し、必要に応じて復元フレーム１５７に置換するための検証処理を実行する（ステップＳ８１０）。レシーバ・デバイス４０は、バッファフラグをクリアする（ステップＳ８１１）。そして、レシーバ・デバイス４０は、受信されたセグメントが保存されたフレーム・バッファ１１Ａ内の領域を解放し（ステップＳ８１２）、ステップＳ８０１に戻る。検証処理については、図３２のフローチャートを参照して後述する。

プリミティブ・セグメントにＢ＿ＥＯＦｓが含まれていない場合（ステップＳ８０９のＮＯ）、そのプリミティブ・セグメントに含まれるプリミティブに応じた動作を行い（ステップＳ８１３）、ステップＳ８０１に戻る。

また、パケットに含まれるセグメントがプリミティブ・セグメントでない場合（ステップＳ８０３のＮＯ）、レシーバ・デバイス４０はバッファフラグが立っているか否かを判定する（ステップＳ８１４）。バッファフラグが立っている場合（ステップＳ８１４のＹＥＳ）、レシーバ・デバイス４０はセグメントをフレーム・バッファ１１Ａに保存する（ステップＳ８１５）。フレーム・バッファ１１Ａに保存されるセグメントは、ＳＯＦを含むパケットが受信されてから、Ｂ＿ＥＯＦｓを含むパケットが受信されるまでの間に受信されるセグメントである。フレーム・バッファ１１Ａに保存されたセグメントは、デスクランブラ１０８内のＬＦＳＲ１７Ａを任意の時点の状態に復元し、ＣＲＣエラーが発生した受信フレームを適切にデスクランブルするための復元処理に用いられる。復元処理については、図２６のフローチャートを参照して上述した通りである。なお、ＳＳＰフレームが受信されている場合、図２６に示した復元処理のステップＳ５１において、レシーバ・デバイス４０は、フレーム内の１バイト目から３バイト目までのＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールドの内の少なくとも２３ビットを、既定値フィールドとして設定する。バッファフラグがクリアされている場合（ステップＳ８１４のＮＯ）、ステップＳ８１５はスキップされる。

次いで、レシーバ・デバイス４０は、セグメントを、デスクランブラ１０８を用いてデスクランブルする（ステップＳ８１６）。そして、レシーバ・デバイス４０は、デスクランブラ１０８の状態を次の状態に遷移させ（ステップＳ８１７）、すなわち、デスクランブラ１０８の動作回数（ＲＵＮ回数）を１だけ増加させ、ステップＳ８０１に戻る。

図３２のフローチャートは、レシーバ・デバイス４０によって実行されるＳＳＰフレームの検証処理の手順の例を示す。この検証処理は、図３１のフローチャートを参照して上述したように、例えば、ＳＳＰフレームの送信完了を示すＢ＿ＥＯＦｓが受信されたことに応じて実行される。ここでは、検証処理が開始される前に復元処理が完了していることを想定する。

まず、レシーバ・デバイス４０は、デスクランブラ１０８によってデスクランブルされたセグメントで構成される受信フレーム１５のＣＲＣを検証し（ステップＳ９０１）、受信フレーム１５にＣＲＣエラーが発生しているか否かを判定する（ステップＳ９０２）。

受信フレーム１５にＣＲＣエラーが発生していない場合（ステップＳ９０２のＮＯ）、レシーバ・デバイス４０はＡＣＫを生成し（ステップＳ９０９）、このＡＣＫを含むパケットをトランスミッタ・デバイス３０に送信するためのプリミティブ・セグメント送信処理を実行する（ステップＳ９１０）。このプリミティブ・セグメント処理については、図２３のフローチャートを参照して上述した通りである。

一方、受信フレーム１５にＣＲＣエラーが発生している場合（ステップＳ９０２のＹＥＳ）、レシーバ・デバイス４０は、復元処理において生成された復元フレーム１５７のＣＲＣを検証し（ステップＳ９０３）、復元フレーム１５７にＣＲＣエラーが発生しているか否かを判定する（ステップＳ９０４）。

復元フレーム１５７にＣＲＣエラーが発生している場合（ステップＳ９０４のＹＥＳ）、レシーバ・デバイス４０は、受信フレーム１５および復元フレーム１５７を破棄し、ＮＡＫ（ＣＲＣ ＥＲＲＯＲ）を生成する（ステップＳ９０５）。レシーバ・デバイス４０は、このＮＡＫ（ＣＲＣ ＥＲＲＯＲ）を含むパケットをトランスミッタ・デバイス３０に送信するためのプリミティブ・セグメント送信処理を実行する（ステップＳ９０６）。

一方、復元フレーム１５７にＣＲＣエラーが発生していない場合（ステップＳ９０４のＮＯ）、レシーバ・デバイス４０は受信フレーム１５を復元フレーム１５７に置き換える（ステップＳ９０７）。つまり、ＣＲＣエラーが発生している受信フレーム１５が破棄され、復元フレーム１５７がトランスミッタ・デバイス３０から受信されたフレームとして処理される。レシーバ・デバイス４０は、デスクランブラ１０８内のＬＦＳＲ１７Ａを、復元処理により算出された同期用状態に設定する（ステップＳ９０８）。そして、レシーバ・デバイス４０はＡＣＫを生成し（ステップＳ９０９）、このＡＣＫを含むパケットをトランスミッタ・デバイス３０に送信するためのプリミティブ・セグメント送信処理を実行する（ステップＳ９１０）。

以上の処理により、レシーバ・デバイス４０では、受信されたＳＳＰフレームをデスクランブラ１０８によってデスクランブルした場合にＣＲＣエラーが発生していたとしても、当該フレーム内の既定値フィールドの値と対応する既定期待値とを用いて、フレームを適切にデスクランブルすることができると共に、当該レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラ１０４とを同期させることができる。

以上説明したように、本実施形態によれば、正常にフレームを伝送することができる。レシーバ・デバイス４０のデスクランブラ１０８は、トランスミッタ・デバイス３０（外部装置）のスクランブラ１０４によってスクランブルされたフレームデータをデスクランブルする。復元モジュール１１は、トランスミッタ・デバイス３０から、受信フレーム１５内の既定値フィールドに対応するフレームデータ１５１が受信された場合、フレームデータ１５１と、当該フレームデータ１５１がスクランブラ１０４によってスクランブルされる前の既定期待値１５０とを用いて、レシーバ・デバイス４０のデスクランブラ１０８をトランスミッタ・デバイス３０のスクランブラ１０４に同期させる。

これにより、トランスミッタ・デバイス３０からレシーバ・デバイス４０に、正常にフレームを伝送することができる。

また、復元モジュール１１は、受信フレーム１５の受信が完了する時点よりも後のデスクランブラ１０８（ＬＦＳＲ１７Ａ）の第３状態を算出し、この第３状態から後退するようにデスクランブラ１０８を遷移させる計算を用いて、受信フレーム１５を構成する複数のフレームデータをデスクランブルするためのスクランブリングデータ１５６を算出する。

デスクランブラ１０８は、受信フレーム１５を構成する複数のフレームデータをデスクランブルする。そして、このデスクランブルされた複数のフレームデータに受信エラーが発生している場合、復元モジュール１１は、算出されたスクランブリングデータ１５６を用いて受信フレーム１５を構成する複数のフレームデータをデスクランブルすることにより、デスクランブルされたフレーム１５７を生成する。

したがって、レシーバ・デバイス４０のデスクランブラ１０８とトランスミッタ・デバイス３０のスクランブラ１０４との間で同期ずれが発生していて、デスクランブラ１０８によってデスクランブルされた受信フレーム１５に受信エラーが発生している場合にも、算出されたスクランブリングデータ１５６を用いて適切にデスクランブルされたフレーム１５７が生成される。したがって、フレームを正常に伝送することができる。

また、本実施形態に記載された様々な機能の各々は、回路（処理回路）によって実現されてもよい。処理回路の例には、中央処理装置（ＣＰＵ）のような、プログラムされたプロセッサが含まれる。このプロセッサは、メモリに格納されたコンピュータプログラム（命令群）を実行することによって、記載された機能それぞれを実行する。このプロセッサは、電気回路を含むマイクロプロセッサであってもよい。処理回路の例には、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、マイクロコントローラ、コントローラ、他の電気回路部品も含まれる。本実施形態に記載されたＣＰＵ以外の他のコンポーネントの各々もまた処理回路によって実現されてもよい。

また、本実施形態の各種処理はコンピュータプログラムによって実現することができるので、このコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体を通じてこのコンピュータプログラムをコンピュータにインストールして実行するだけで、本実施形態と同様の効果を容易に実現することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０…イニシエータ、２０…ターゲット、１００…コントローラ、１０１…送信フレームコントローラ、１０２…ＣＲＣジェネレータ、１０３…プリミティブ・ジェネレータ、１０４…スクランブラ、１０５…ＦＥＣエンコーダ、１０６…ＦＥＣデコーダ、１０７…プリミティブ・デコーダ、１０８…デスクランブラ、１０９…受信フレームコントローラ、１１…復元モジュール、１１０…復元コントローラ、１１Ａ…フレーム・バッファ、１１１，１１５…ＸＯＲ演算器、１１２…ＬＦＳＲ復元部、１１３…ＬＦＳＲ算出部、１１４…ＬＦＳＲロールバック部、１１６…ＣＲＣデコーダ、１５０…既定期待値。

Claims (13)

1. スクランブラを備える外部装置との間で、シリアル・アタッチド・スモール・コンピュータ・システム・インターフェース（ＳＡＳ）のパケットモードでフレームを送受信可能な装置であって、
   前記スクランブラによってスクランブルされたフレームデータをデスクランブルするように構成されるデスクランブラと、
   前記外部装置から、第１フレーム内の第１フィールドに対応する第１フレームデータが受信された場合、前記第１フレームデータと、前記第１フレームデータが前記スクランブラによってスクランブルされる前の第１の値とを用いて、前記デスクランブラを前記スクランブラに同期させるように構成されるコントローラとを具備する装置。
2. 前記コントローラは、前記第１フレームデータと前記第１の値とを用いて、前記第１フレームデータよりも後に受信するプリミティブまたは前記第１フレームデータよりも後に受信する第２フレームデータに対応する前記デスクランブラの第２状態を算出するように構成される請求項１記載の装置。
3. 前記コントローラは、前記デスクランブラを前記第２状態に設定するように構成される請求項２記載の装置。
4. 前記スクランブラと前記デスクランブラとはそれぞれ線形フィードバック・シフト・レジスタを備え、
   前記コントローラは、
   前記第１フレームデータと前記第１の値とを排他的論理和演算することにより、前記第１フレームデータの生成に用いられた第１スクランブリングデータを算出し、
   前記第１スクランブリングデータに基づいて、当該第１スクランブリングデータが生成される時点の前記線形フィードバック・シフト・レジスタの第１状態を算出し、
   前記第１状態から前進するように前記線形フィードバック・シフト・レジスタを遷移させる計算を用いて、前記第２状態を算出するように構成される請求項２記載の装置。
5. 前記コントローラは、前記デスクランブラ内の前記線形フィードバック・シフト・レジスタに、前記デスクランブラの前記第２状態に対応する値を設定するように構成される請求項４記載の装置。
6. 前記第２フレームデータは、前記第１フレームを構成する複数のフレームデータの全てを受信した直後に受信されるフレームデータである請求項２記載の装置。
7. 前記コントローラは、さらに、
   前記第１フレームの受信が完了する時点よりも後の前記デスクランブラの第３状態を算出し、前記第３状態から後退するように前記デスクランブラを遷移させる計算を用いて、前記第１フレームを構成する複数のフレームデータをデスクランブルするための第２スクランブリングデータを算出するように構成される請求項１記載の装置。
8. 前記デスクランブラは、前記複数のフレームデータをデスクランブルするように構成され、
   前記コントローラは、デスクランブルされた前記複数のフレームデータに受信エラーが発生している場合、前記第２スクランブリングデータを用いて前記複数のフレームデータをデスクランブルすることにより、デスクランブルされた前記第１フレームを生成するように構成される請求項７記載の装置。
9. 前記第１フレームは、アイデンティファイ・アドレス・フレームであり、
   前記第１フィールドは、Ｒｅｓｅｒｖｅｄフィールド内の連続する少なくともＮビットのサイズを有するフィールドであり、
   前記第１の値は、０である請求項１記載の装置。
10. 前記第１フレームは、オープン・アドレス・フレームであり、
    前記第１フィールドは、ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールド内の、連続する少なくともＮビットのサイズを有するフィールドであり、
    前記第１の値は、前記装置のＳＡＳアドレスである請求項１記載の装置。
11. 前記第１フレームは、オープン・アドレス・フレームであり、
    前記第１フィールドは、ＭＯＲＥ ＣＯＭＰＡＴＩＢＬＥ ＦＥＡＴＵＲＥＳフィールド内の、連続する少なくともＮビットのサイズを有するフィールドであり、
    前記第１の値は、０である請求項１記載の装置。
12. 前記第１フレームは、シリアル・スモール・コンピュータ・システム・インターフェース・プロトコル（ＳＳＰ）フレームであり、
    前記第１フィールドは、ＨＡＳＨＥＤ ＤＥＳＴＩＮＡＴＩＯＮ ＳＡＳ ＡＤＤＲＥＳＳフィールド内の、連続する少なくともＮビットのサイズを有するフィールドであり、
    前記第１の値は、前記装置のＳＡＳアドレスのハッシュ値である請求項１記載の装置。
13. 前記スクランブラと前記デスクランブラとはそれぞれ、前記Ｎビットの線形フィードバック・シフト・レジスタを備える請求項９乃至請求項１２のいずれか一項に記載の装置。

Images