(57)【特許請求の範囲】
【請求項１】
規格により定められた不使用ビット列であって、データ群に含まれたエラーチェック対象部分の前記不使用ビット列を対応する既知のビットパターンで置き換えた後に、前記エラーチェック対象部分に対してエラーチェックを行うことを特徴とする情報処理方法。
【請求項２】
前記データ群は、通信において受信したフレームであることを特徴とする請求項１に記載の情報処理方法。
【請求項３】
前記フレームは、超広帯域無線通信におけるフィジカル・レイヤ・コンバージェンス・プロトコルフレームであり、
前記エラーチェック対象部分は、前記フィジカル・レイヤ・コンバージェンス・プロトコルフレームのヘッダ部分であることを特徴とする請求項２に記載の情報処理方法。
【請求項４】
注目フレームの前の所定の期間におけるエラーの検出率が所定の閾値以下である場合において、前記注目フレームに対して、前記置換えを行わずにエラーチェックを行うことを特徴とする請求項２または３に記載の情報処理方法。
【請求項５】
データ群に含まれたエラーチェック対象部分に対して、規格により定められた不使用ビット列を対応する既知のビットパターンで置き換える置換部と、
該置換部による置換えが行われた前記エラーチェック対象部分に対してエラーチェックを行うエラーチェック部と、
を備えたことを特徴とする情報処理装置。
【請求項６】
通信フレームを受信する受信部をさらに備え、
前記データ群は、該受信部により受信したフレームであることを特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記フレームは、超広帯域無線通信におけるフィジカル・レイヤ・コンバージェンス・プロトコルフレームであり、
前記エラーチェック対象部分は、前記フィジカル・レイヤ・コンバージェンス・プロトコルフレームのヘッダ部分であることを特徴とする請求項６に記載の情報処理装置。
【請求項８】
注目フレームの前の所定の期間におけるエラーの検出率が所定の閾値以下である場合において、前記注目フレームに対して前記置換部による処理を中止させる制御部をさらに備え、
前記エラーチェック部は、前記置換部の処理が中止された場合において、置換えが行われていない前記注目フレームに対するエラーチェックを行うことを特徴とする請求項６または７に記載の情報処理装置。
【請求項９】
データ群に含まれたエラーチェック対象部分に対して、規格により定められた不使用ビット列を対応する既知のビットパターンで置き換える手順と、
置き換えが行われた前記エラーチェック対象部分に対してエラーチェックを行う手順とをコンピュータに実行せしめることを特徴とするプログラム。
【請求項１０】
前記データ群は、通信において受信したフレームであることを特徴とする請求項９に記載のプログラム。
【請求項１１】
前記フレームは、超広帯域無線通信におけるフィジカル・レイヤ・コンバージェンス・プロトコルプレーヤフレームであり、
前記エラーチェック対象部分は、前記フィジカル・レイヤ・コンバージェンス・プロトコルプレーヤフレームのヘッダ部分であることを特徴とする請求項１０に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はエラーチェック、特に通信において受信したフレームに対するエラーチェック技術に関する。
【背景技術】
【０００２】
デジタル時代の今、デジタルデータはあらゆる場面で使われている。デジタルデータは伝送しやすい特性を有することから、通信の分野において、データをデジタル化して伝送することが主流となりつつある。
【０００３】
データ伝送を行う通信機間において、データはフレームと呼ばれるデータ集合の単位で扱われる。受信する側において、受信したデータが正常であるか否かを確認するために、受信したフレームに対してエラーチェックを行う必要がある（特許文献１、特許文献２参照）。
【０００４】
そのために、フレーム毎にエラーチェック用のデータを組み込み、それをチェックすることによって、その伝送単位のデータが正常か否かを確認する仕組みが利用されている。
【０００５】
たとえば、非特許文献１に記載されたように、ＵＷＢ（Ｕｌｔｒａ  Ｗｉｄｅ  Ｂａｎｄ：超広帯域無線）通信において、ＰＬＣＰ（Ｐｈｙｓｉｃａｌ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ：フィジカル・レイヤ・コンバージェンス・プロトコル）のフレームのヘッダ部分に対してエラーチェックを行い、その結果によってフレームが正常か否かを確認している。そして、確認の結果に応じて、正常であればデータを出力し、正常ではなければ、送信側に再送をリクエストする処理をし、データの通信を確実にすることが行われている。
【特許文献１】特開２００６−０５０３９６号公報
【特許文献２】特開平１１−１２７１７４号公報
【非特許文献１】ＭＢＯＡ  ＰＨＹ  ＬＡＹＥＲ  ＴＥＣＨＮＩＣＡＬ  ＳＰＥＩＦＩＣＡＴＩＯＮ，Ｖｅｒ．  ０．９５
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、ＵＷＢ通信において、ＰＬＣＰフレームを受信した際に行われるエラーチェックは、ヘッダ部分のすべてのビット（計１２０ビット）に対して行われ、１ビットでもエラーがあれば、すべてのフレームが廃棄される。フレームの破棄は、当該フレームの再送のための処理が伴うので、フレームの破棄率は、データ伝送の効率を左右する１つの要因である。
【０００７】
一方、ＰＬＣＰフレームのヘッダには、リザーブビットなど、規格により使用しないように規定されているビットがある。これらのビットは使用されていないにもかかわらず、エラーがあればフレーム全体の破棄を引き起こし、通信効率を下げてしまう。
【課題を解決するための手段】
【０００８】
本発明の一つの態様は情報処理方法である。この情報処理方法は、データ群に含まれたエラーチェック対象部分の不使用ビット列を対応する既知のビットパターンで置き換えた後に、エラーチェック対象部分に対してエラーチェックを行う。
【０００９】
なお、上記態様の方法を、装置、システム、プログラムに置き換えたものも、本発明の態様としては有効である。
【発明の効果】
【００１０】
本発明にかかる情報処理方法によれば、データ群に含まれるエラーを効率良く検出することができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００１２】
図１は、本発明の実施の形態にかかる通信装置１００を示す。通信装置１００は、送受信のインターフェースとなる通信インターフェース２０と、通信インターフェース２０を介して受信したフレームが正常であるか否かを確認し、正常であれば後段処理部７０に出力し、正常ではなければ送信元に再送をリクエストするなどの処理を行うフレーム処理部４０と、フレーム処理部４０から出力されてきたフレームを保存したり、アプリケーションに渡したりするなど、用途に応じた処理を行う後段処理部７０とを備える。なお、通信装置１００は、ＵＷＢ通信に対応するものであり、通信インターフェース２０を介して受信したフレームは、ＰＬＣＰフレームを含む。
【００１３】
図２は、図１に示す通信装置１００におけるフレーム処理部４０の構成を示す。フレーム処理部４０は、置換部４２と、エラーチェック部４４と、出力処理部４６とを有する。なお、フレーム処理部４０の様々な処理を行う機能ブロックとして図中に記載れた各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００１４】
ここで、ＰＬＣＰフレームのフォーマットを説明しながら、フレーム処理部４０の各機能ブロックの詳細を説明する。
【００１５】
図３の上部は、ＰＬＣＰフレームの一部を示す。ＰＬＣＰフレームは、伝送されるデータのペイロード（Ｐａｙ  Ｌｏａｄ。図示せず）以外に、ＰＨＹヘッダ、Ｔａｉｌ  ビット、ＭＡＣヘッダ、ＨＣＳを有し、それぞれのビット数は、４０ビット、６ビット、８０ビット、１６ビットである。このうち、ＰＨＹヘッダとＭＡＣヘッダは、エラーチェック対象部分である。
【００１６】
従来、ＰＬＣＰフレームに対してエラーチェックをする際に、ＰＨＹヘッダとＭＡＣヘッダの合わせて１２０ビットの各ビットに対してエラーチェックを行い、１ビットでもエラーがあれば、フレーム全体が正しくないとし、フレームを廃棄する。しかし、図３の下部に示すように、ＰＨＹヘッダには、規格で規定され、使用しないビット（以下不使用ビットという）が多数存在する。具体的には、すべてのリザーブビットと、ＲＡＴＥの上位２ビットは、不使用ビットである。ＭＡＣヘッダにおいても同じように、不使用ビットが多数存在する。これらの不使用ビットのいずれかにおいてエラーがあれば、従来はこのフレームを廃棄していた。
【００１７】
ところで、不使用ビットにエラーがあっても、フレームの伝送、使用に障害を来たすわけではないので、従来のエラーチェック方法では、不使用ビットのエラーに起因するフレームの破棄、およびそれに伴うフレームの再送などにより、通信の効率を下げていた。
【００１８】
それに対して、本実施の形態の通信装置１００において、フレーム処理部４０は、ＰＬＣＰフレームに対してエラーチェックをする際に、まず、置換部４２により、ＰＨＹヘッダおよびＭＡＣヘッダにある不使用ビット列を、対応する既知のビットパターンで置き換える。ここで、不使用ビット列に「対応する」ビットパターンとは、そのビット数が不使用ビット列と同じであるビットパターンを意味する。また、「既知のビットパターン」は、エラーとして検出されないいかなるビットパターンであればよく、ここで例として、置換部４２は、すべての不使用ビットを０で置き換える。
【００１９】
エラーチェック部４４は、ＰＬＣＰのＰＨＹヘッダとＭＡＣヘッダの１２０ビットに対してエラーチェックをする。ここで、エラーチェック部４４によりチェックされるフレームのＰＨＹヘッダとＭＡＣヘッダは、それらに含まれる不使用ビットが置換部４２により０に置き換えられたものである。すなわち、受信したフレームのヘッダ部分に含まれる不使用ビットにエラーがあっても、他のビットにエラーがなければ、エラーチェック部４４によるエラーチェックは、このフレームのヘッダ部分にエラーがないことを示す結果を得る。
【００２０】
ここで図４に示す例を用いて、本実施の形態における置換部４２およびエラーチェック部４４の処理を説明する。図４の上部は、フレームのＰＨＹヘッダ部分にエラーがある場合の例を示しており、図中陰影部分はエラーのあるビットである。この例では、リザーブビットのうちの３ビット（図中左端の３ビットのリザーブビットのうちの１ビットと、Ｒａｔｅビットの右側の１２ビットのうちの２ビット）と、Ｒａｔｅビットの不使用部分の２ビットのうちの１ビットはエラービットになっている。従来では、不使用ビット以外のビットにエラーがなくても、このようなＰＨＹヘッダを有するフレームを異常フレームとして破棄していた。
【００２１】
それに対して、本実施の形態において、まず、置換部４２は、ヘッダに含まれる不使用ビット列をオール０であるビットパターンに置換え、これにより、図４上部に示すＰＨＹヘッダは図４下部に示すようになる。ＭＡＣヘッダについても同じである。
【００２２】
その結果、ヘッダ部分の不使用ビットの置換えが行われたフレームに対して、エラーチェック部４４がエラーチェックを行うため、不使用ビット以外のビットにエラーがなければ、ヘッダからエラーが検出されず、フレームは正常フレームとして出力される。
【００２３】
出力処理部４６は、エラーチェック部４４によるエラーチェックの結果に応じて処理を行う。具体的には、エラーが検出されれば、出力処理部４６は、このフレームを破棄するとともに、送信元にフレームの再送をリクエストする。一方、エラーが検出されていなければ、出力処理部４６は、このフレームを後段処理部７０に出力する。
【００２４】
図５は、通信装置１００におけるフレーム処理部４０の処理を示すフローチャートである。フレーム処理部４０は、通信インターフェース２０を介してＰＬＣＰフレームを受信すると、置換部４２が、受信したＰＬＣＰフレームに含まれるヘッダ部分（ＰＨＹヘッダとＭＡＣヘッダ）中の不使用ビットを０に置き換える（Ｓ１０、Ｓ２０）。エラーチェック部４４は、ステップＳ２０においてビットの置換えが行われたＰＬＣＰフレームの１２０ビットに対してエラーチェックを行い、その結果を出力処理部４６に送信する（Ｓ３０）。出力処理部４６は、エラーが検出されたフレームに対して、このフレームを破棄する処理と、送信元にフレームの再送をリクエストする処理を含むフレーム破棄処理を行う（Ｓ４０：Ｙｅｓ、Ｓ５０）。一方、エラーが検出されていないフレームに対しては、出力処理部４６は、このフレームを後段処理部７０に出力する（Ｓ６０）。
【００２５】
このように、本実施の形態の通信装置１００によれば、ＰＬＣＰフレームに対して、エラーチェック対象部分となるヘッダ部分に含まれる不使用ビットを０で置換えた後にエラーチェックをするようにしている。こうすることによって、元々規格で使用しないように規定された不使用ビットのみにエラーがある場合に、フレームが正常フレームとして出力されるため、フレームの頻繁な破棄を防ぎ、通信効率を高めることができる。
【００２６】
図６は、本発明の他の実施の形態にかかる通信装置２００の構成を示す。通信装置２００は、送受信のインターフェースとなる通信インターフェース２０と、通信インターフェース２０を介して受信したフレームが正常であるか否かを確認し、正常であれば後段処理部７０に出力し、正常ではなければ送信元に再送をリクエストするなどの処理を行うフレーム処理部１４０と、フレーム処理部１４０から出力されてきたフレームを保存したり、アプリケーションに渡したりするなど、用途に応じた処理を行う後段処理部７０とを備える。なお、通信装置２００は、ＵＷＢ通信に対応するものであり、通信インターフェース２０を介して受信したフレームは、ＰＬＣＰフレームを含む。ここで、通信装置２００に含まれる機能ブロックに対して、通信装置１００の相対応する機能ブロックと同じものについては、同じ符号を付与するとともに、それらの詳細な説明を省略する。
【００２７】
図７は、図６に示す通信装置２００におけるフレーム処理部１４０の構成を示す。フレーム処理部１４０は、置換部１４２、エラーチェック部１４４、出力処理部４６、制御部１４８を備える。
【００２８】
置換部１４２が動作するか否かは、制御部１４８により制御される。なお、置換部１４２が動作する場合は、通信装置１００における置換部４２と同じ処理をする。
【００２９】
エラーチェック部１４４は、置換部１４２が動作している場合においては、置換部１４２により不使用ビット列の置換えが行われたフレームに対してエラーチェックを行い、置換部１４２が動作していない場合においては、フレーム処理部１４０に入力されたフレーム（置換部１４２による置換えが行われていないフレーム）に対してエラーチェックを行う。
【００３０】
制御部１４８は、エラーチェック部１４４による各フレームに対するエラーチェックの結果に対して統計をとって、エラーチェックをしようとするフレーム（以下注目フレームという）の直前の所定の期間におけるエラー検出率を得るとともに、このエラー検出率が所定の閾値Ｔ以下かそれより大きいかに応じて置換部１４２とエラーチェック部１４４を制御する。ここで、所定の期間は、所定の長さの時間区間であってもよいし、連続した所定のフレーム枚数であってもよい。本実施の形態において、エラー検出率として、注目フレームの直前の連続した１０枚のフレームにおいて、エラーフレームがないこと（すなわち上記閾値Ｔが０であること）を満たすか否かに応じて制御を行う。
【００３１】
制御部１４８は、エラー検出率が閾値Ｔ以下である場合、ここの例では、エラーが検出されなかったフレームが１０枚続いた場合において、置換部１４２による置換処理を中止させる。
【００３２】
図８は、通信装置２００におけるフレーム処理部１４０の処理を示すフローチャートである。フレーム処理部１４０は、通信インターフェース２０を介してＰＬＣＰフレームを受信すると、制御部１４８は、エラー検出率を確認する（Ｓ１１０、Ｓ１１４）。制御部１４８は、注目フレームの直前の連続した１０枚のフレームのそれぞれからエラーが検出されたか否か、およびこの１０枚のフレームのうち、エラーが検出されたフレームの枚数を記憶する図示しないメモリを有し、その初期値はたとえば「直前にチェックした１０枚の連続フレームのすべてからエラーが検出されていた」ことを示す１０に設定されている。
【００３３】
制御部１４８は、エラー検出率が閾値Ｔより大きい場合（ここではメモリに記憶された値が０以外である場合に相当する）において、置換部１４２を動作させ、置換部１４２は、受信したＰＬＣＰフレームに含まれるヘッダ部分（ＰＨＹヘッダとＭＡＣヘッダ）中の不使用ビットを０に置き換える（Ｓ１１４：Ｎｏ、Ｓ１２０）。一方、ステップＳ１１４において、エラー検出率が閾値Ｔ以下である場合（ここではメモリに記憶された値が０である場合に相当する。Ｓ１１４：Ｙｅｓ）においては、制御部１４８は、置換部１４２による処理を中止させ、フレーム処理部１４０に入力されてきたフレームをそのままエラーチェック部１４４に処理させる。
【００３４】
エラーチェック部１４４は、置換部１４２が動作している場合において置換部１４２によりビットの置換えが行われたＰＬＣＰフレーム、または置換部１４２が動作していない場合においてフレーム処理部１４０に入力されてきたＰＬＣＰフレームの合わせて１２０ビットに対してエラーチェックを行い、その結果を制御部１４８と出力処理部１４６に送信する（Ｓ１３０）。
【００３５】
制御部１４８は、注目フレームに対するエラーチェックの結果をもって、エラー検出率を更新する（Ｓ１３４）。本実施の形態において、制御部１４８は、具体的には、注目フレームからエラーが検出されていれば、図示しないメモリに記憶された最も先のフレームのエラーチェックの結果を削除し、注目フレームのエラーチェックの結果を１０枚目のフレームの結果として記憶させるとともに、エラー検出率を示す枚数を更新する。たとえば、最も先のフレームが「エラーが検出されたフレーム」である場合において、エラー検出率としての「直前の連続した１０枚のフレームからエラーが検出されたフレームの数」をそのままにする。一方、最も先のフレームが「エラーが検出されなかったフレーム」である場合においては、エラー検出率として、エラーが検出されたフレームの数に１を加算する。
【００３６】
また、注目フレームからエラーが検出されていなければ、制御部１４８は、図示しないメモリに記憶された最も先のフレームのエラーチェックの結果を削除し、注目フレームのエラーチェックの結果を１０枚目のフレームの結果として記憶させるとともに、エラー検出率を更新する。たとえば、最も先のフレームが「エラーが検出されたフレーム」である場合において、エラー検出率として、エラーが検出されたフレームの数から１を減算する。一方、最も先のフレームが「エラーが検出されなかったフレーム」である場合においては、エラー検出率をそのままにする。
【００３７】
出力処理部４６は、エラーが検出されたフレームに対して、このフレームを破棄する処理と、送信元にフレームの再送をリクエストする処理を含むフレーム破棄処理を行う（Ｓ１４０：Ｙｅｓ、Ｓ１５０）。一方、エラーが検出されていないフレームに対しては、出力処理部１４６は、このフレームを後段処理部７０に出力する（Ｓ１４０：Ｎｏ、Ｓ１６０）。
【００３８】
このように、本実施の形態の通信装置２００によれば、図１に示す通信装置１００と同じ効果を得ることができるとともに、エラーが発生する割合が少ない場合において、ヘッダに含まれる不使用ビットを置き変える処理を中止しているので、装置全体の効率向上を図ることができる。
【００３９】
以上、実施の形態をもとに本発明を説明した。実施の形態は例示であり、本発明の主旨から逸脱しない限り、さまざまな変更、増減を加えてもよい。これらの変更、増減が加えられた変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００４０】
【図１】本発明の実施の形態にかかる通信装置を示す図である。
【図２】図１に示す通信装置におけるフレーム処理部の構成を示す図である。
【図３】ＰＬＣＰフレームのフォーマットを示す図である。
【図４】図２に示すフレーム処理部における置換部の処理を説明するための図である。
【図５】図２に示すフレーム処理部における処理の流れを示すローチャートである。
【図６】本発明の他の実施の形態にかかる通信装置を示す図である。
【図７】図６に示す通信装置におけるフレーム処理部の構成を示す図である。
【図８】図７に示すフレーム処理部における処理の流れを示すフローチャートである。
【符号の説明】
【００４１】
２０  通信インターフェース  ４０  フレーム処理部
４２  置換部  ４４  エラーチェック部
４６  出力処理部  ７０  後段処理部
１００  通信装置  １４０  フレーム処理部
１４２  置換部  １４４  エラーチェック部
１４６  出力処理部  １４８  制御部
２００  通信装置
【図１】
0004818783.tif 000002
【図２】
0004818783.tif 000003
【図３】
0004818783.tif 000004
【図４】
0004818783.tif 000005
【図５】
0004818783.tif 000006
【図６】
0004818783.tif 000007
【図７】
0004818783.tif 000008
【図８】
0004818783.tif 000009