JP2006101061A

JP2006101061A - 通信方法

Info

Publication number: JP2006101061A
Application number: JP2004283170A
Authority: JP
Inventors: Yukihiro Yamamoto; 幸宏山本; Hiroyuki Inuzuka; 浩之犬塚
Original assignee: Toyota Industries Corp
Current assignee: Toyota Industries Corp
Priority date: 2004-09-29
Filing date: 2004-09-29
Publication date: 2006-04-13

Abstract

【課題】既存の装置との共存性を確保しながら、通信品質の向上を図る。
【解決手段】ＭＡＣヘッダおよびＬＬＣ／ＳＮＡＰヘッダが付与されたユーザデータを複数のブロックに分割し、各ブロックに誤り訂正符号ＥＣＣを付与することにより複数のＦＥＣ符号語を生成する。複数のＦＥＣ符号語全体に対してＣＲＣ演算を行う。誤り訂正を行うことを表す情報は、ＬＬＣ／ＳＮＡＰヘッダに設定される。
【選択図】図１

Description

本発明は、データおよびそのデータを送信するための制御情報を含むデータフレームを送受信する通信方法に係わる。

従来より、通信システム（特に、無線通信システム）は、しばしば、伝送データの正常性をチェックする機能および／またはビット誤りが発生したデータを訂正する機能を備えている。ここで、伝送データの正常性をチェックする誤り検査機能は、たとえば、ＣＲＣ（Cyclic Redundancy Check）符号等により実現されている。また、ビット誤りを訂正する機能は、例えば、前方誤り訂正（ＦＥＣ：Forward Error Correction）の誤り訂正符号（ＥＣＣ：Error Correction Code）等により実現されている。なお、これらの技術は、特に、高い通信品質（ＱｏＳ：Quality of Service）が要求される動画像データや音声データの無線伝送において重要である。

図７（ａ）は、フレーム誤り検査するためのＦＣＳ（Frame Check Sequence）フィールドが付与されたデータフレームの例である。ここでは、一例として、IEEE802.11bにおけるショートプリアンブルの場合の無線層フレームフォーマットを示す。

このデータフレームには、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダ、ＭＡＣヘッダ、ＬＬＣ／ＳＮＡＰヘッダが付与されている。そして、送信側の通信装置において、ＭＡＣヘッダ、ＬＬＣ／ＳＮＡＰヘッダ、ユーザデータからなるデータフレームに対してＦＣＳ演算が実行され、その計算結果がフレームの末尾に付与される。受信側の通信装置は、このＦＣＳを利用してデータフレームの正常性を検出することができる。

図７（ｂ）は、誤り訂正符号ＥＣＣが適用されたデータフレームの例である。ここでは、ユーザデータが複数のブロックに分割され、各ブロック毎に誤り訂正符号ＥＣＣが付与されている。そして、受信側の通信装置は、伝送路上でビット誤りが生じたときは、その誤り訂正符号ＥＣＣを利用してその誤りを訂正することができる。

なお、特許文献１には、誤り検出／訂正処理をヘッダおよびデータに分離して行い、さらに分離したヘッダおよびデータに対して、誤り検出処理および誤り訂正処理を独立して行う技術が記載されている。また、特許文献２には、パケットのヘッダに対して誤り訂正を行う技術が記載されている。さらに、特許文献３には、複数のパケットのヘッダ部およびデータ部をそれぞれ連結し、連結したヘッダ部および連結してデータ部に対して個々に前方誤り訂正ＦＥＣを行う技術が記載されている。
特開平１０−１３５９８５号公報（図１、段落００１９〜００２６、要約）特開平９−１５４１６６号公報（図６、段落０００８〜００１０、００３６）特開平１０−２４７９４２号公報（図２、段落００１２〜００１６、要約）

上述のように、誤り検出機能および誤り訂正機能の双方を行う技術、あるいはヘッダ部分に対して誤り訂正を行う技術が知られている。
一方、すでに広く普及している通信システムに新しい方式を導入する際には、既存の装置との共存性や相互接続性の確保が重要である。例えば、IEEE802.11系の無線ＬＡＮシステムにおいても、前方誤り訂正ＦＥＣの導入が検討されている。しかし、上述の特許文献１〜３に記載の方式では、大幅な仕様変更または仕様追加が避けられず、既存の装置との共存性または相互接続性の確保が困難である。

本発明の目的は、既存の装置との共存性を確保しながら、通信品質の向上を図ることである。

本発明の通信方法は、通信装置間でユーザデータを送信する方法であって、まず、宛先アドレスを含む第１のヘッダおよびその第１のヘッダよりも上位レベルの通信制御情報を格納する第２のヘッダを生成する。そして、誤り訂正を行う場合には、上記第２のヘッダ内に誤り訂正を行うことを表す第１の値を設定し、上記第１のヘッダおよび第２のヘッダが付与されたユーザデータから１または複数の誤り訂正符号語を生成し、上記１または複数の誤り訂正符号語全体に対する誤り検出コードを計算し、上記１または複数の誤り訂正符号語に上記誤り検出コードを付与して送信する。一方、誤り訂正を行わない場合には、上記第２のヘッダ内に上記第１の値と異なる所定の第２の値を設定し、上記第１のヘッダおよび第２のヘッダが付与されたユーザデータ全体に対して誤り検出コードを計算し、上記第１のヘッダおよび第２のヘッダが付与されたユーザデータに上記誤り検出コードを付与して送信する。

この方法によれば、受信側の通信装置は、第２のヘッダに設定されている値に基づいて誤り訂正処理の要否を検出できる。よって、誤り訂正機能を持たない既存の通信装置および誤り訂正機能を有する通信装置を容易に共存させることができる。また、誤り検出機能および誤り訂正機能の双方を備えるので、通信品質が向上する。

なお、受信側の通信装置において、上記誤り検出コードにより誤りが検出されず且つ上記第２のヘッダに上記第２の値が設定されていたときにユーザデータを取得するようにしてもよい。この動作は、誤り訂正機能を持たない既存の通信装置および誤り訂正機能を有する通信装置の双方で同じである。よって、これらの装置の共存性を確保できる。

また、誤り訂正機能を有する受信側の通信装置において、上記誤り検出コードにより誤りが検出されず且つ上記第２のヘッダに上記第１の値が設定されていたときに、上記１または複数の誤り訂正符号語からそれぞれ誤り訂正符号を削除することによりユーザデータを取得するようにしてもよい。この場合、誤りが検出されなかったときは、誤り訂正符号を利用して復号処理を必要としないので、受信処理に要する負荷が増加することはない。

さらに、誤り訂正機能を有する受信側の通信装置において、上記誤り検出コードにより誤りが検出されたときに、各誤り訂正符号語を復号して検出された誤りを訂正することによりユーザデータを取得するようにしてもよい。この場合、検出した誤りを訂正できるので、通信品質が向上する。また、このとき、ユーザデータを取得する処理は、先頭の誤り訂正符号語を復号する処理、復号された先頭の誤り訂正符号語内の上記第２のヘッダ内に上記第１の値が設定されていたときに限り後続の誤り訂正符号語を復号する処理、を含むようにしてもよい。この手順を導入すれば、不要な復号処理の発生を抑制できる。

本発明の他の態様の通信方法は、上記第１および第２のヘッダを生成する工程と、上記第２のヘッダ内に誤り訂正を行うことを表す情報を設定する工程と、上記第１のヘッダおよび第２のヘッダが付与されたユーザデータから１または複数の誤り訂正符号語を生成する工程と、上記１または複数の誤り訂正符号語全体に対する誤り検出コードを計算する工程と、上記１または複数の誤り訂正符号語に上記誤り検出コードを付与して送信する工程を有する。そして、先頭の誤り訂正符号語は、上記第１のヘッダ、上記第２のヘッダ、上記ユーザデータの一部または全部、及びそれらについての誤り訂正符号から構成される。この方法によれば、先頭の誤り訂正符号語には、ヘッダだけでなくユーザデータも格納される。よって、符号語の数を少なくできる。

本発明によれば、誤り訂正機能を持たない既存の通信装置と誤り訂正機能を有する通信装置との共存性または相互接続性を確保できる。よって、既存の設備を利用しながら、新たな機能を持った通信装置を徐々に増やしていくことができる。また、誤り検出機能に加えて誤り訂正機能を備えるので、データ再送が抑制されるので、伝送効率が向上する。

図面を参照しながら本発明に係る通信方法の実施形態について説明する。以下の実施形態において、本発明に係る通信方法は、通信装置間で無線フレームを送受信する無線ネットワークにおいて使用される。また、無線ネットワークは、例えば、IEEE802.11に準拠する無線ＬＡＮである。この場合、無線ＬＡＮシステムは、複数のステーションがアクセスポイントを介して通信を行う方式（インフラモード）であってもよいし、アクセスポイントを設けることなくステーション間で通信を行う方式（アドホックモード）であってもよい。

IEEE802.11に準拠する無線ＬＡＮにおいては、伝送データの正常性をチェックするフレーム誤り検査が採用されているが、ビット誤りを訂正する機能は導入されていない。このため、既存の通信装置においては、ビット誤りを検出したときにそれを訂正することは出来ず、送信側にフレームの再送を依頼する必要があった。そこで、本発明に係る通信装置は、フレーム誤り検査機能および誤り訂正機能の双方を備える構成としている。また、本発明に係る通信装置は、誤り訂正機能を持たない既存の通信装置との共存性を可能な限り図っている。

図１（ａ）は、誤り訂正を行わない場合の無線フレームのフォーマットの例である。ＰＬＣＰ（Physical Layer Convergence Protocol）プリアンブルは、無線フレーム信号受信同期処理に必要な固定パターン信号である。ＰＬＣＰヘッダは、伝送速度を表す情報、変調方式を表す情報等を格納する。ＭＡＣ（Medium Access Control）ヘッダには、無線チャネルのアクセス制御のための情報等が格納されている。尚、フレームのタイプ（マネジメントフレーム／制御フレーム／データフレーム）を表す情報、フレームの送信先アドレスは、このＭＡＣヘッダに格納される。ＬＬＣ（Logical Link Control）／ＳＮＡＰ（SubNetwork Access Protocol）ヘッダは、ＭＡＣヘッダに格納される情報よりも上位レベルの情報（例えば、イーサネットフレームのカプセル化に関する情報）を格納する。ＦＣＳ（Frame Check Sequence）フィールドは、誤り検出コードであり、例えば、ＣＲＣ（Cyclic Redundancy Check）符号により実現されている。なお、この場合、ＣＲＣ演算は、フレーム全体（すなわち、ＭＡＣヘッダ、ＬＬＣ／ＳＮＡＰヘッダおよびユーザデータからなるデータフレーム全体）に対して行われる。

図１（ｂ）は、誤り訂正を行う場合の無線フレームのフォーマットである。ここで、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダ、ＭＡＣヘッダは、基本的に、誤り訂正を行わない場合と同じである。ＬＬＣ／ＳＮＡＰヘッダは、後で詳しく説明するが、イーサネットフレームのカプセル化に関する情報の代わりに、誤り訂正を行うことを表す情報が設定されている。

ＦＥＣ（Forward Error Correction）符号語は、誤り訂正符号語であり、ＭＡＣヘッダおよびＬＬＣ／ＳＮＡＰヘッダが付与されたユーザデータを複数のブロックに分割し、各ブロックにそれぞれ対応する誤り訂正符号ＥＣＣ（Error Correction Code）を付与することにより生成される。この例では、各ＦＥＣ符号語の長さは２２８バイトであり、２０８バイトのデータ領域および２０バイトの誤り訂正符号ＥＣＣから構成されている。また、誤り訂正符号ＥＣＣは、特に限定されるものではないが、例えば、リードソロモンである。そして、データフレーム全体（すなわち、複数のＦＥＣ符号語全体）に対して実行されたＣＲＣ演算の結果がＦＣＳフィールドに書き込まれる。

なお、上述の複数のＦＥＣ符号語の中の先頭のＦＥＣ符号語のデータ領域には、ＭＡＣヘッダ、ＬＬＣ／ＳＮＡＰヘッダ、およびユーザデータの一部が格納される。ただし、ユーザデータが１７６バイト以下の場合は、ＦＥＣ符号語が１つだけ生成され、そのＦＥＣ符号語のデータ領域には、ＭＡＣヘッダ、ＬＬＣ／ＳＮＡＰヘッダ、およびユーザデータの全部が格納されることになる。

このように、図１（ｂ）に示す無線フレームにおいては、誤り訂正符号ＥＣＣが付与されているので、ＣＲＣを利用して検出された誤りを訂正できる。これにより、通信品質が向上する。また、データ再送の頻度が減るので、データ伝送効率も向上する。さらに、ユーザデータだけでなく通信制御のために重要な情報を含むＭＡＣヘッダに対しても誤り訂正が適用されるので、このことも通信品質の向上に寄与する。

なお、特許請求の範囲に記載の「第１のヘッダ」および「第２のヘッダ」は、それぞれＭＡＣヘッダおよびＬＬＣ／ＳＮＡＰヘッダに相当する。
図２は、ＬＬＣ／ＳＮＡＰヘッダの実施例である。ＬＬＣ／ＳＮＡＰヘッダは、無線フレームがユーザデータを伝送するときに付与される情報であり、詳しくはIEEE802.1Hに記載されている。

ＬＬＣヘッダは、ＤＳＡＰ（Destination Service Access Point）、ＳＳＡＰ（Source Service Access Point）、ＣＴＬ（Control）から構成されており、それぞれ予め決められた値が設定される。また、ＳＮＡＰヘッダは、３バイトのＯＵＩ（Organizationally Unique Identifier）および２バイトのtype情報から構成されている。ここで、ＲＦＣ１０４２で規定されているEncapsulationでユーザデータを送信する場合には、ＯＵＩとして「0x00-0x00-0x00」が設定され、Ethernet Bridge-Tunnel Encapsulationでユーザデータを送信する場合には、ＯＵＩとして「0x00-0x00-0xF8」が設定される。そして、これらの場合、例えば、IEEE802.1Hにおいては、ＯＵＩに続くtype情報として、上位層（例えば、TCP/IPプロトコルスタック）から通知された値が使用される。具体的には、上位層から通知されたtype情報が「0x80f3」または「0x8137」であれば、「ＯＵＩ＝0x00-0x00-0xF8」が設定され、「0x80f3」または「0x8137」でないtype情報が通知された場合には、「ＯＵＩ＝0x00-0x00-0x00」が設定される。さらに、ＯＵＩに続くtypeフィールドには、上位層から通知されたtype情報が設定される。なお、上記のように、EncapsulationやEthernet Bridge-Tunnel Encapsulationでユーザデータを送信する場合（誤り訂正を行わない場合）に設定されるtype情報は、Ether typeと呼ばれる。

これに対して、誤り訂正を行う場合には、ＯＵＩとして予め決められた所定の値（例えば、本発明に係る通信サービスを提供するベンダを識別する値）が設定される。図２に示す例においては、「0x00-0xC0-0x74」が設定されている。そして、この場合、type情報は、ＯＵＩ値により識別されるベンダにより決定される。

なお、特許請求の範囲に記載されている「誤り訂正を行うことを表す情報」「誤り訂正を行うことを表す第１の値」は、例えば「ＯＵＩ＝0x00-0xC0-0x74」に相当する。また、「第２の値」は、例えば「ＯＵＩ＝0x00-0x00-0x00」又は「ＯＵＩ＝0x00-0x00-0xF8」に相当する。

次に、本発明に係る通信装置の動作についてフローチャートを参照しながら説明する。
図３は、送信側の通信装置の動作を示すフローチャートである。なお、このフローチャートの処理は、送信すべきユーザデータが作成されたときに実行される。

ステップＳ１では、ＭＡＣヘッダが作成される。ここで、ＭＡＣヘッダには、着信先アドレス、及びデータフレームであることを表す情報等が設定される。ステップＳ２は、誤り訂正を行うか否かを判断する分岐ステップである。なお「誤り訂正を行うか否か」は、例えば、予め固定的に決められていてもよいし、着信先アドレスに応じて決められるようにしてもよい。

誤り訂正を行わない場合は、ステップＳ３において、ＬＬＣ／ＳＮＡＰヘッダを作成する。このとき、ＬＬＣヘッダには、図２に示した固定値が設定される。また、ＳＮＡＰヘッダには、図２に示した「ＯＵＩ＝0x00-0x00-0x00」又は「ＯＵＩ＝0x00-0x00-0xF8」が設定される。ステップＳ４では、ユーザデータを所定のメモリ領域にセットする。ステップＳ５では、図１（ａ）に示すように、ＭＡＣヘッダ、ＬＬＣ／ＳＮＡＰヘッダおよびユーザデータからなるデータフレーム全体に対してＦＣＳ（この例では、ＣＲＣ）を計算する。これにより、データフレームとＦＣＳとからなるＭＡＣプロトコルデータユニットＭＰＤＵが作成される。そして、このＭＡＣプロトコルデータユニットＭＰＤＵにＰＬＣＰプリアンブル及びＰＬＣＰヘッダが付与されて送信される。

誤り訂正を行う場合には、ステップＳ１１において、ＬＬＣ／ＳＮＡＰヘッダを作成する。このとき、ＬＬＣヘッダには図２に示した固定値が設定されるが、ＳＮＡＰヘッダには、誤り訂正を行うことを表す値が設定される。「誤り訂正を行うことを表す値」は、図２に示す例では「ＯＵＩ＝0x00-0xC0-0x74」である。

ステップＳ１２では、ユーザデータを所定のメモリ領域にセットし、１または複数のＦＥＣ符号語を生成する。ＦＥＣ符号語については、図１（ｂ）を参照しながら説明した通りである。ステップＳ１３では、図１（ｂ）に示すように、データフレーム全体（１または複数のＦＥＣ符号語全体）に対してＦＣＳを計算する。これにより、データフレームとＦＣＳとからなるＭＡＣプロトコルデータユニットＭＰＤＵが作成され、ＰＬＣＰプリアンブル及びＰＬＣＰヘッダが付与されて送信される。

このように、本発明に係る通信装置は、図１（ａ）または図１（ｂ）に示す無線フレームを作成して送信する。なお、誤り訂正機能を有していない通信装置は、ステップＳ１〜Ｓ５を実行することにより、図１（ａ）に示す無線フレームを作成して送信する。

図４は、誤り訂正機能を持たない通信装置の受信動作を示すフローチャートである。このフローチャートの処理は、無線フレームを受信したときに実行される。
ステップＳ２１では、誤り検出コードであるＦＣＳを利用してデータ誤りの有無を調べる。そして、誤りが検出されなかったときは、ステップＳ２２において、ＭＡＣヘッダに設定されている宛先アドレスを調べる。

受信フレームが自局宛てであった場合、または受信フレームがブロードキャストフレームであった場合には、ステップＳ２３においてＭＡＣヘッダに設定されているフレームタイプを調べる。このとき、受信フレームがデータフレームであれば、ステップＳ２４においてＬＬＣ／ＳＮＡＰヘッダの設定値を調べる。そして、ＬＬＣ／ＳＮＡＰヘッダに「ＯＵＩ＝0x00-0x00-0x00」または「ＯＵＩ＝0x00-0x00-0xF8」が設定されていれば、ユーザデータを取り込む。

なお、ステップＳ２１において誤りが検出された場合、およびステップＳ２２において宛先アドレスが他の通信装置を指していた場合は、受信フレームを廃棄する。また、ステップＳ２４においてＬＬＣ／ＳＮＡＰヘッダに「ＯＵＩ＝0x00-0xC0-0x74」が設定されていた場合は、受信フレームが１または複数のＦＥＣ符号語を含んでいるものとみなし、その受信フレームを廃棄する。一方、ステップＳ２３において受信フレームがマネジメントフレームまたは制御フレームであった場合は、そのフレームにより指示される処理を実行する。

このように、誤り訂正機能を持たない通信装置は、ＦＥＣ符号語を含む受信フレームからユーザデータを取得することはできないが、ＬＬＣ／ＳＮＡＰヘッダに「ＯＵＩ＝0x00-0x00-0x00」または「ＯＵＩ＝0x00-0x00-0xF8」が設定されていれば、受信フレームからユーザデータを取得できる。すなわち、誤り訂正機能を有する通信装置から送信されたフレームであっても、そのＬＬＣ／ＳＮＡＰヘッダに「ＯＵＩ＝0x00-0x00-0x00」または「ＯＵＩ＝0x00-0x00-0xF8」が設定されていれば、そのフレームからユーザデータを取得できる。これにより、誤り訂正機能を有する通信装置から誤り訂正機能を持たない通信装置への接続性が確保される。

図５は、誤り訂正機能を有する通信装置の受信動作を示すフローチャートである。このフローチャートの処理も、無線フレームを受信したときに実行される。
ステップＳ３１〜Ｓ３４は、基本的に、図４を参照しながら説明したステップＳ２１〜Ｓ２４と同じである。ただし、ステップＳ３１において誤りが検出された場合は、その受信フレームを廃棄することなく、ステップＳ４１以降の誤り訂正処理を実行する。また、ステップＳ３４において、ＬＬＣ／ＳＮＡＰヘッダに「ＯＵＩ＝0x00-0xC0-0x74」が設定されていた場合は、受信フレームに含まれている１または複数のＦＥＣ符号語の処理を行う。具体的には、各ＦＥＣ符号語から誤り訂正符号ＥＣＣを削除する。これにより、受信フレームからユーザデータが取得される。

ステップＳ４１〜Ｓ４７は、ステップＳ３１において誤りが検出された場合に実行される誤り訂正処理である。ただし、ステップＳ３１の誤り検出処理は、誤りの有無を検出することは出来るが、誤りの場所を特定することはできない。よって、誤りが検出された受信フレームからユーザデータを取得するためには、すべての符号語について誤り訂正処理が実行される。

ステップＳ４１およびＳ４２では、先頭（第１番目）のＦＥＣ符号語を復号する。すなわち、先頭のＦＥＣ符号語に対して、誤り訂正符号ＥＣＣを利用してデータ部分の誤り訂正を試みる。この結果、誤り訂正が成功であれば、ステップＳ４３に進み、誤り訂正が失敗であれば、受信パケットを廃棄する。なお、無線フレームの受信時において当該符号語に誤りが無かった場合は、誤り訂正が成功であったものとして処理を進める。

ステップＳ４３〜Ｓ４５は、基本的に、ステップＳ３２〜Ｓ３４と同じである。すなわち、受信フレームが自局宛てであった場合、または受信フレームがブロードキャストフレームであった場合にはステップＳ４４に進み、受信フレームがデータフレームであればステップＳ４５に進み、ＬＬＣ／ＳＮＡＰヘッダに「ＯＵＩ＝0x00-0x00-0x00」または「ＯＵＩ＝0x00-0x00-0xF8」が設定されていればステップＳ４６に進む。

ステップＳ４６およびＳ４７では、２番目以降のＦＥＣ符号語を復号する。そして、すべての符号語について誤り訂正が成功であれば、ユーザデータを取り込む。一方、１以上の符号語について誤り訂正に失敗した場合には、受信フレームを廃棄する。

このように、実施形態の通信方法によれば、誤り検出コードによりビット誤りが検出されたときは、まず、先頭のＦＥＣ符号語を復号し、その中に格納されているＭＡＣヘッダおよびＬＬＣ／ＳＮＡＰヘッダを抽出する。そして、それらのヘッダ情報に基づいて必要に応じて後続のＦＥＣ符号語を復号し、ユーザデータを取得する。

また、誤り訂正を導入したフレームであっても、ＰＬＣＰヘッダおよびＭＡＣヘッダは既存仕様と同じである。よって、誤り訂正機能を持たない既存の通信装置との共存が容易である。

図６は、本発明に係る通信装置と誤り訂正機能を持たない既存の通信装置との接続性について説明する図である。ここで、無線局１、２は、誤り訂正機能を有する通信装置であり、無線局３、４は、誤り訂正機能を持たない通信装置である。

無線局１、２は、図５を参照しながら説明したように、誤り訂正符号ＥＣＣが付与された無線フレームを受信することができると共に、誤り訂正符号ＥＣＣが付与されていない既存仕様の無線フレームを受信することもできる。すなわち、無線局１、２は、いずれの無線局からの無線フレームの受信することができる。

一方、無線局３、４は、誤り訂正符号ＥＣＣが付与されていない既存仕様の無線フレームであれば、誤り訂正機能を有する通信装置から送出されたものであっても、それを受信できる。したがって、無線局１、２から無線局３、４へデータを送信するときは、無線局１、２において図１（ａ）に示す既存仕様のフレームを作成するようにすればよい。これにより、無線局１〜４の共存性（すなわち、相互接続性）が確保される。

なお、本発明の通信方法は、上述の実施例に限定されるものではなく、下記の態様に適用することも可能である。
（１）ＦＥＣ符号語の語長および符号化率は、図１（ｂ）に示す実施例に限定されるものではない。

（２）ＭＡＣヘッダを含むＦＥＣ符号語の符号化率を他のＦＥＣ符号語よりも低くしてもよい。この構成を導入すれば、重要な情報を含むＭＡＣヘッダに対する誤り訂正能力が高くなる。ここで、以降のユーザデータは、ＭＡＣヘッダを正常に解読できた場合にのみ利用可能となるので、ＭＡＣヘッダを含む符号語の誤り訂正能力を高めることは重要である。なお、この動作は、ＰＬＣＰヘッダを基準としてビット数をカウントし、ＭＡＣヘッダを含む符号語と後続の符号語との境界を検出することにより実現可能である。

（３）既存仕様のＭＡＣヘッダをそのまま残すと共に、ＭＡＣヘッダ内の一部または全部の情報をユーザデータ領域に書き込むことによりユーザデータ領域内に仮想的なヘッダを作成し、その仮想的なヘッダを含むユーザデータ領域に対して誤り訂正を行うようにしてもよい。

（４）ＦＣＳにより誤りが検出されなかったにもかかわらず、ＭＡＣヘッダ等の通信管理情報において未定義情報が検出された場合には、誤り訂正処理を実行するようにしてもよい。この手順は、ＦＣＳの誤り検出能力よりもＦＥＣの誤り訂正能力の方が高いときに有効である。

（５）送信側の通信装置においてＦＣＳを付与しなくてもよい。この場合、受信側の通信装置においてＦＣＳチェックを行うと、エラーが発生することになる。しかし、誤り訂正機能を持たない既存の通信装置においては、図６を参照しながら説明したように、もともとＦＥＣ符号語を復号できないので、データフレームを受信できないという点では同じ結果になる。また、誤り検出機能を有する通信装置においては、ＦＣＳエラーが発生すると図５のステップＳ４１以降の処理が実行されるので、データフレームを受信できる。この方式によれば、ＦＣＳの分だけフレーム長を短くでき、オーバヘッドが減るので、通信の効率が向上する。

（６）フレームを受信したときに、ＦＥＣ計算およびＦＥＣ処理を並列に実行するようにしてもよい。この方式を導入すれば、受信処理に要する時間が短縮される。
（７）２番目以降のＦＥＣ符号語の一部について誤りを訂正できなかったときは、その一部のＦＥＣ符号語に格納されていたユーザデータ部分のみについて再送処理を行うようにしてもよい。ただし、この場合、受信側の通信装置から送信元の通信装置へＡＣＫ信号を返送する際に、ＦＥＣ符号語を識別する情報を通知する機能が必要である。

（８）本実施形態では、特許請求の範囲に記載されている「誤り訂正を行うことを表す情報」「誤り訂正を行うことを表す第１の値」「第２の値」はＯＵＩ値に相当するとし、このＯＵＩ値から誤り訂正を行うかどうか判断しているが、「誤り訂正を行うことを表す情報」「誤り訂正を行うことを表す第１の値」「第２の値」はＯＵＩ値とtype情報に相当するとして、この２つの値から誤り訂正を行うかどうかを判断してもよい。

（９）第２のヘッダ（ＬＬＣ／ＳＮＡＰヘッダ）を拡張してもよい。例えば、ＳＮＡＰヘッダを３バイトのＯＵＩ値および４バイトのtype情報から構成し、Ether type（２バイト）とベンダにより決定されるtype情報（２バイト）を４バイトのtype情報として設定してもよい。

（ａ）は、誤り訂正を行わない場合の無線フレームのフォーマットの例、（ｂ）は、誤り訂正を行う場合の無線フレームのフォーマットの例である。ＬＬＣ／ＳＮＡＰヘッダの実施例である。送信側の通信装置の動作を示すフローチャートである。誤り訂正機能を持たない通信装置の受信動作を示すフローチャートである。誤り訂正機能を有する通信装置の受信動作を示すフローチャートである。本発明に係る通信装置と誤り訂正機能を持たない既存の通信装置との接続性について説明する図である。（ａ）は、誤り検査フィールドが付与されたデータフレームの例、（ｂ）は、誤り訂正符号が導入されたデータフレームの例である。

符号の説明

１、２本発明に係る通信装置
３、４誤り訂正機能を持たない既存の通信装置

Claims

通信装置間でユーザデータを送信する通信方法であって、
宛先アドレスを含む第１のヘッダおよびその第１のヘッダよりも上位レベルの通信制御情報を格納する第２のヘッダを生成し、
誤り訂正を行う場合には、
上記第２のヘッダ内に誤り訂正を行うことを表す第１の値を設定し、
上記第１のヘッダおよび第２のヘッダが付与されたユーザデータから１または複数の誤り訂正符号語を生成し、
上記１または複数の誤り訂正符号語全体に対する誤り検出コードを計算し、
上記１または複数の誤り訂正符号語に上記誤り検出コードを付与して送信し、
誤り訂正を行わない場合には、
上記第２のヘッダ内に上記第１の値と異なる所定の第２の値を設定し、
上記第１のヘッダおよび第２のヘッダが付与されたユーザデータ全体に対して誤り検出コードを計算し、
上記第１のヘッダおよび第２のヘッダが付与されたユーザデータに上記誤り検出コードを付与して送信する
ことを特徴とする通信方法。
請求項１に記載の通信方法であって、
受信側の通信装置において、
上記誤り検出コードにより誤りが検出されず、且つ、上記第２のヘッダに上記第２の値が設定されていたときには、ユーザデータを取得する
ことを特徴とする通信方法。
請求項１に記載の通信方法であって、
誤り訂正機能を有する受信側の通信装置において、
上記誤り検出コードにより誤りが検出されず、且つ、上記第２のヘッダに上記第１の値が設定されていたときには、上記１または複数の誤り訂正符号語からそれぞれ誤り訂正符号を削除することによりユーザデータを取得する
ことを特徴とする通信方法。
請求項１に記載の通信方法であって、
誤り訂正機能を有する受信側の通信装置において、
上記誤り検出コードにより誤りが検出されたときは、各誤り訂正符号語を復号して検出された誤りを訂正することによりユーザデータを取得する
ことを特徴とする通信方法。
請求項４に記載の通信方法であって、
上記ユーザデータを取得する処理は、
先頭の誤り訂正符号語を復号する処理と、
復号された先頭の誤り訂正符号語内の上記第２のヘッダ内に上記第１の値が設定されていたときに限り後続の誤り訂正符号語を復号する処理、を含む
ことを特徴とする通信方法。
通信装置間でユーザデータを送信する通信方法であって、
宛先アドレスを含む第１のヘッダおよびその第１のヘッダよりも上位レベルの通信制御情報を格納する第２のヘッダを生成する工程と、
上記第２のヘッダ内に誤り訂正を行うことを表す情報を設定する工程と、
上記第１のヘッダおよび第２のヘッダが付与されたユーザデータから１または複数の誤り訂正符号語を生成する工程と、
上記１または複数の誤り訂正符号語全体に対する誤り検出コードを計算する工程と、
上記１または複数の誤り訂正符号語に上記誤り検出コードを付与して送信する工程を有し、
先頭の誤り訂正符号語は、上記第１のヘッダ、上記第２のヘッダ、上記ユーザデータの一部または全部、およびそれらについての誤り訂正符号から構成される
ことを特徴とする通信方法。