(57)【要約】【課題】実行時に遅延時間が変動しても規格で定められた時間制約に対応した通信を行うソフトウェア無線機を提供すること。【解決手段】本発明にかかるソフトウェア無線機は、たとえば、ソフトウェアを利用して所定のベースバンド処理を実行する受信処理部１２と、受信処理部１２が実行しているベースバンド処理の進捗を所定のタイミングで確認し、進捗確認結果に基づいて、受信処理部１２がその後のベースバンド処理で実行する処理内容を決定する進捗管理部１１と、を備える。【選択図】図２
2010278829.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアを利用して所定のベースバンド処理を実行する信号処理部と、
前記信号処理部が実行しているベースバンド処理の進捗を所定のタイミングで確認し、進捗確認結果に基づいて、前記信号処理部がその後のベースバンド処理で実行する処理内容を決定する進捗管理部と、
を備えることを特徴とするソフトウェア無線機。
【請求項２】
前記進捗管理部は、
前記信号処理部が実行しているベースバンド処理に対応する通信規格に基づいて当該ベースバンド処理が順調に進んでいるかどうかを確認し、順調に進んでいない場合には、前記信号処理部に対し、実行中の処理を処理負荷の軽い処理に切り換えるように指示する
ことを特徴とする請求項１に記載のソフトウェア無線機。
【請求項３】
前記進捗管理部は、
前記信号処理部が実行しているベースバンド処理の終了予定時刻を前記通信規格に基づいて算出し、また、前記信号処理部が所定量の作業を終了するごとに当該ベースバンド処理の開始時からの経過時間を確認し、さらに、前記終了予定時刻および経過時間の確認結果に基づいて、前記ベースバンド処理が順調に進んでいるかどうかを判断する
ことを特徴とする請求項２に記載のソフトウェア無線機。
【請求項４】
前記進捗管理部は、
前記信号処理部が所定量の作業を終了するごとに当該信号処理部が実行しているベースバンド処理の開始時からの経過時間を確認し、経過時間の確認結果、および前記通信規格に基づき決定された、システムで許容される最大遅延量、に基づいて、前記ベースバンド処理が順調に進んでいるかどうかを判断する
ことを特徴とする請求項２に記載のソフトウェア無線機。
【請求項５】
前記進捗管理部は、
前記信号処理部がこれから実行するベースバンド処理が順調に進むかどうかを過去の進捗確認結果に基づいて推測し、順調に進まないと推測した場合には、前記信号処理部に対し、前記過去の進捗確認結果を取得した際に当該信号処理部が実行していた処理よりも処理負荷が軽い処理を実行するように指示する
ことを特徴とする請求項１に記載のソフトウェア無線機。
【請求項６】
前記進捗管理部は、さらに、
通信路の状態に応じて前記信号処理部が実行している処理を切り替えるように指示する
ことを特徴とする請求項５に記載のソフトウェア無線機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア無線機に関する。
【背景技術】
【０００２】
近年、無線通信のベースバンド処理において、ソフトウェア／プロセッサベースの処理システムが注目されてきている（たとえば、下記特許文献１参照）。このような処理システムでは、ソフトウェアを用いて処理を実現するため、設計効率の改善や複数の無線規格（通信規格）に容易に対応することができるなどのメリットがある。
【０００３】
たとえば、プロセッサを用いた実装において１つの汎用プロセッサだけでは処理能力が足りない場合には、特殊なプロセッサを用いる，マルチプロセッサ構成とする，一部の処理については専用のハードウェアブロックで実施する，などの方法を利用することによって所望の無線機を実現する。以下、このようにして実現されている無線機を「ソフトウェア無線機」と呼ぶ。
【０００４】
ここで、上述したソフトウェア無線機を実現する際に考慮しなければならないことの一つとして、処理の遅延時間が挙げられる。一般に、無線信号処理において、対応しているそれぞれの無線規格で遅延時間が定められている場合、それを守らなければならない。例えば、無線ＬＡＮシステムでは、信号を受信後、ＳＩＦＳ（Short  Interframe  space）以内にＡＣＫを返さなければならないことになっている。そのため、受信信号処理は、ＳＩＦＳ（=16μs）以内にＡＣＫの返答ができるくらいの遅延時間で終えなければならないが、ソフトウェア無線機で信号処理を行う場合には、この遅延時間に特別な配慮が必要となる。なぜなら、専用ハードウェアによる実装と違い、処理の遅延時間が実行時の状況に依存して変動する可能性があるためである。
【０００５】
信号処理を専用ハードウェアで作りこむ場合は、基本的にシステム設計者が設計した遅延時間で処理が終了し、遅延時間が変動することはない。しかしながら、ソフトウェア無線機の場合には、その構成にもよるが、キャッシュミスやリソース競合など、実行時のさまざまな要因によって遅延時間が変動する。例えば、マルチプロセッサ構成の実装でプロセッサ間の同期が必要な場合、同期に必要な時間によって遅延時間が変動する可能性がある。一般的にプロセッサ間の同期に必要な時間は静的に決まらないからである。また、別の例として、プロセッサやハードウェアブロック間を共有バスで結合している場合、バスの競合が発生すると待たされるハードウェアブロックが出てくる。バス競合はバスの使用度合によって発生したりしなかったりするので、基本的に静的に見積もることはできない。他にも、あるプロセッサが各種ハードウェアブロックに処理を割り当てて、処理が終わったら割り込みを受け付けるようなシステム実装の場合、多重割り込みが発生して優先度の低い割り込み処理が待たされる可能性がある。このように、ソフトウェア無線機の構成によっては、専用ハードウェアにて実現された無線機にはない遅延時間の変動要因が存在する。
【０００６】
したがって、ソフトウェア無線機の設計では、上記のような実行時に現れる処理遅延に関して何も考慮しないでシステムを設計すると、実行時に遅延時間が延びることで無線規格の時間制約を守れない可能性が出てくる。たとえば、無線ＬＡＮの場合であれば、処理遅延に起因してＳＩＦＳ以内にＡＣＫを返せなくなり、受信側がＡＣＫを返さなければ、送信側で受信失敗として扱われてしまう。そのため、実行時に現れる処理遅延を考慮し、無線規格の時間制約を守れるようなシステムの実現が望まれており、従来のソフトウェア無線機では、主に、実行時に現れる処理遅延分をマージンとして考慮して設計する手法が採用されていた。例えば、ある無線規格から導かれる処理遅延余裕が１６μｓの場合に、このタイミングバジェット１６μｓに対し、処理の実行時には２μｓ分の処理遅延が発生すると見込まれれば、１４μｓ以内に処理が終わるように設計する、というような手法が採用されていた。
【０００７】
しかしながら、上記のような設計手法を採用した場合、考慮しておいた遅延量（マージン）を超える処理遅延が発生した場合には対処することができず、システムで規定された時間制約を満足できない。一方、全ての遅延要因が重なった最悪ケースを想定してマージン設計を行うことによりマージンを超える処理遅延の発生は回避できるが、タイミングバジェットは非常に小さくなり設計が困難になる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−４０２５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、実行時に遅延時間が変動しても規格で定められた時間制約に対応した通信を行うソフトウェア無線機を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本願発明の一態様によれば、ソフトウェアを利用して所定のベースバンド処理を実行する信号処理部と、前記信号処理部が実行しているベースバンド処理の進捗を所定のタイミングで確認し、進捗確認結果に基づいて、前記信号処理部がその後のベースバンド処理で実行する処理内容を決定する進捗管理部と、を備えるソフトウェア無線機が提供される。
【発明の効果】
【００１１】
本発明によれば、処理の実行中に想定外の遅延が発生した場合であっても、発生した遅延をキャンセルして予定通りに処理を終了させることができる。そのため、遅延時間が変動しても無線規格で定められた時間制約に対応した通信を行うことが可能となり、設計時に確保しておく処理遅延についてのマージンを極力少なくすることができる、という効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】図１は、ソフトウェア無線機のシステム構成例を示す図。
【図２】図２は、ソフトウェア無線機の機能ブロック図。
【図３】図３は、ソフトウェア無線機の動作を説明するための図。
【図４】図４は、ソフトウェア無線機の動作を説明するための図。
【図５】図５は、ソフトウェア無線機の動作を説明するための図。
【図６】図６は、ソフトウェア無線機の動作を説明するための図。
【図７】図７は、ソフトウェア無線機の動作を説明するための図。
【図８】図８は、ソフトウェア無線機の動作を説明するための図。
【図９】図９は、ソフトウェア無線機の動作を説明するための図。
【図１０】図１０は、ソフトウェア無線機の動作を説明するための図。
【図１１】図１１は、受信処理部の内部構成例を示す図。
【発明を実施するための形態】
【００１３】
以下に添付図面を参照して、本発明の実施の形態にかかるソフトウェア無線機を詳細に説明する。なお、この実施の形態により本発明が限定されるものではない。
【００１４】
（実施の形態）
本実施の形態では、一例として、ソフトウェア無線機の受信動作について説明する。図１は、本実施の形態にかかるソフトウェア無線機のシステム構成例を示す図である。
【００１５】
図１に示したように、本実施の形態のソフトウェア無線機は、プロセッサ１，２、入力信号に対して特定の信号処理を行うハードウェアエンジン３、および、入力信号に対してＦＩＲフィルタ処理を行うフィルタ４，５を備え、これらの各構成要素は、図示を省略した内部メモリをそれぞれ有し、また、バス６に接続されている。なお、図１は、説明を簡単化するため、ソフトウェア無線機の特徴的な動作を実現するために必要な部分を抽出して示したものである。そして、本実施の形態にかかるソフトウェア無線機においては、対向する通信装置（通信相手）から送信された信号を受信した場合、ソフトウェアを利用したベースバンド処理を行い、送信信号を復元する。具体的には、まず、図示を省略した２系統のアンテナで信号を受信した場合、受信した各アナログ信号に対して、図示を省略したアナログ信号処理部が所定の処理を実行し、その結果に基づいて生成された２系統のデジタル信号それぞれに対して、フィルタ４，５がＦＩＲフィルタ処理を行う。次に、ＦＩＲフィルタ処理を実施して得られた各信号に対し、プロセッサ１，２およびハードウェアエンジン３が、復調処理や復号処理を含む所定のデジタル信号処理（ベースバンド処理）を実施して、送信されてきたデータ系列を復元する。
【００１６】
図２は、図１に示したアーキテクチャを有するソフトウェア無線機の機能ブロック図である。図示したように、本実施の形態のソフトウェア無線機は、進捗管理部１１、受信処理部１２および計時部１３を備える。なお、図２では、図１と同様に、特徴的な動作を実現するために必要な構成要素を抽出して示している。また、本実施の形態では受信動作について説明を行うため、信号の受信動作に関連しない機能ブロックについては省略している。
【００１７】
進捗管理部１１は、受信処理部１２が実行している処理の進捗を管理する。受信処理部１２は、信号処理部（図示せず）を構成しており、対向通信装置から受信した信号が入力された場合、復調処理や復号処理を含む所定のデジタル信号処理（ベースバンド処理）を実行する。すなわち、受信処理部１２は、図１に示したプロセッサ１，２およびハードウェアエンジン３により実現される。計時部１３は、時間の管理を行う。なお、進捗管理部１１および計時部１３はプロセッサ１および／またはプロセッサ２により実現される。
【００１８】
つづいて、上記構成のソフトウェア無線機の特徴的な動作について、上記の図１，２、および図３〜図１０を必要に応じて参照しながら説明する。なお、図３〜図１０は、ソフトウェア無線機の動作を説明するための図である。本実施の形態にかかるソフトウェア無線機は、一般的なソフトウェア無線機と比較して、以下の点が異なる。すなわち、本実施の形態のソフトウェア無線機は、信号処理を実施している状態では、時計などを利用し、どのくらいの時間でどのくらい処理が進んだかをモニターする。そして、仮に、処理の進捗がシステムの想定するスピードより遅れていたら（実行時に現れる遅延要因によって予定より遅れ出したことを検出したら）、ソフトウェアによる処理の一部を変更して処理速度を高速化することにより、遅れを取り戻す。たとえば、図２に示した受信処理部１２が受信処理を実行する場合、進捗管理部１１は、受信処理部１２における一連の受信処理が遅延することなく順調に進んだ場合の終了予定時刻を算出し、また、受信処理部１２における処理の進捗（処理の進行状況）を適宜確認し、この確認結果、および計時部１３から得られる時間情報（確認を行った時刻の情報）に基づいて、受信処理が終了予定時刻までに終了するかどうかを判断する。そして、終了予定時刻までに処理が終了しないと判断した場合、進捗管理部１１は、受信処理部１２に対して処理の一部を変更して処理速度を高速化するように指示を出す。受信処理部１２は、進捗管理部１１から変更指示を受けた場合、指示内容に従って処理の一部を変更し、受信処理をスピードアップする。
【００１９】
この動作を無線ＬＡＮシステムの受信側の通信装置として動作する場合の例で説明すると次のようになる。ソフトウェア無線機は、無線ＬＡＮのフレーム受信処理においては、まず、受信処理部１２がヘッダ部の受信処理を実行し、データ部のデータ長（Ｌとする）の情報を得る。そして、データ長Ｌの情報が得られると、このデータ長Ｌと受信処理部１２の処理能力などから、どのくらいの時間でフレーム全体の受信処理が終了するかを、進捗管理部１１が計算する。算出した、受信処理が終わると予定される時刻をＴとする。ここで、受信処理の終了時刻が時刻Ｔより遅くなるとＳＩＦＳ（規定時間）以内にＡＣＫが返せなくなってしまうものと仮定した場合、受信処理部１２は、受信処理全体を時刻Ｔまでに完了させる必要がある。
【００２０】
この状況について図３を用いて説明する。図３の直線３０は、ソフトウェア無線機の受信処理部１２において、実行時の遅延時間の変動がなく順調に処理が進んだ場合の処理の進捗状況を表している。つまり図３は、実行時に現れる遅延が全く無く進んだ場合の動作の進捗状況を示しており、データ長Ｌを時刻Ｔだけかかって受信処理することを表している。
【００２１】
データ長Ｌに基づく時刻Ｔ（受信処理の終了予定時刻Ｔ）の算出処理が終了し、その後、データ部分の受信処理を開始すると、ソフトウェア無線機では、進捗管理部１１が、計時部１３から得られる時刻情報を使用し、受信処理部１２がどのくらいの時間でどのくらいのデータ処理を行ったかをモニターする。例えば、無線ＬＡＮシステムで扱うフレームのデータ部をシンボルと呼ばれるブロック単位でデータ処理するのであれば、所定数のシンボル（たとえば１シンボル）に対する処理が終了する毎にその時点の時刻を記録することで処理の進捗をモニターする。具体的な動作を示すと、たとえば、受信処理部２は、所定数のシンボルに対する処理が終了する毎にその旨を進捗管理部１１に通知し、この通知を受けた進捗管理部１１は、その時点の時刻の情報を計時部１３から取得する。そして、進捗管理部１１は、取得した時刻情報および上記の終了予定時刻Ｔに基づいて、受信処理部２における受信処理が終了予定時刻Ｔまでに終了するかどうかを判定する。
【００２２】
実行時に遅延が発生せずに順調に（事前に見積もった処理能力の通りに）受信処理が進めば、１シンボル終了毎に得られる時刻は図３で示した直線上に載ることとなる（図４参照）。なお、図４に示した点はソフトウェア無線機を実際に動作させたときの受信処理部１２における処理の進捗を表しており、たとえば１シンボルに対する処理が終了する毎に計測した時間をプロットした結果である。もし何らかの要因で遅延が発生した場合は、これらの点（プロット結果）は、図５に示したようなものとなり、直線より右側にずれてくる。つまり、受信処理の実行中に発生した遅延により、順調に処理が進む場合と比較して遅れる。そして、このまま処理を続けた場合、図５の点線で示したように、その後の処理が順調に進んでも予定終了時刻Ｔには間に合わない。そのため、ソフトウェア無線機は、このような場合には、以下に示すような手法で受信処理を加速し、予定終了時刻Ｔに間に合うように動作する。
【００２３】
例えば、ソフトウェア無線機の受信処理部１２は、Equalize処理における、補正量の更新間隔を伸ばして処理の負荷を軽くすることにより、処理速度を加速する。Equalize処理は通信路により影響を受けた受信信号を数値計算により補正する処理であるが、一般的には無線通信路は時刻とともに変動するので、補正量も無線通信路の変動に合わせて更新していく必要がある。この補正量の更新処理を省く（たとえば、定期的に実行する更新処理を間引いて更新間隔を広げる）ことで受信時の計算負荷を軽くしてスピードアップすることができる。このようにEqualize処理の補正量の更新間隔を伸ばすことで、受信処理のスピードアップが実現され、上記の図５に示した受信処理が遅れた状態を、図６に示したように、モニター結果を示す点が太線６０上となるまで改善できる。図６は、点Ａまで処理が進んだ時点で処理を切り替えて受信処理を高速化することで、予定終了時刻Ｔに間に合わせた場合の例を示している。
【００２４】
なお、ここでは無線ＬＡＮシステムの受信動作において処理速度を高速化し、処理を予定終了時刻Ｔまでに終了させる場合の例について示したが、さまざまなバリエーションが考えられる。すなわち、送信動作や他の通信システムにおける信号処理動作（送受信動作）においても同様の手法（所定の処理についての負荷を軽減すること）で全体の処理速度を高速化できる。
【００２５】
また、本実施の形態にかかるソフトウェア無線機の特徴的な動作は、以下の（ステップＳ１）〜（ステップＳ３）で示した３つの要素から成り立っている。
【００２６】
（ステップＳ１）：「時刻および当該時刻までに終了した作業量の組」を進捗管理部１１が取得する。
（ステップＳ２）：進捗管理部１１は、ステップＳ１で取得した情報に基づいて、処理の進捗（予定終了時刻よりも遅れているか、または進んでいるか）を判断する。
（ステップＳ３）：ステップＳ２で「遅れている」と判断した場合は、高速な処理に切り替える。すなわち、進捗管理部１１は、受信処理部１２に対して処理速度を加速するように指示を行い、この指示内容に従い、受信処理部１２では、処理速度を加速する。
【００２７】
これらの各ステップについて、詳しく説明する。まず、ステップＳ１で、「時刻および当該時刻までに終了した作業量の組」を取得する場合、進捗管理部１１は、計時部１３に対して時刻を問い合わせ、時刻情報を取得する。「時刻情報」はフレームの先頭位置を０とするなど、適切な時点からの時刻とする。「当該時刻までに終了した作業量」は、作業量を定量的に示す情報であれば何でも良い。例えば、処理が終了したデータ量（バイト数やシンボル数など）とすればよい。また、繰り返し復号を行う場合、何回目の繰り返しが終わったかを示す情報を「当該時刻までに終了した作業量」としてもよい。なお、何らかの処理が終了した時点のデータの量と言っても、どの「処理」が終了した時点におけるデータの量とするかは選択肢がある。例えば、処理済のシンボル数とする場合、受信処理が（１）ＦＦＴ（Fast  Fourier  Transform）処理、（２）Equalize処理、（３）Demapping処理の順でパイプライン式に実行されるのであれば、（１）を終了したデータシンボル数なのか、（２）を終了したデータシンボルなのか、それとも（３）を終了したデータシンボル数を図るのか…、など適当な位置を選ぶ必要がある。進捗管理部１１は、このような作業量の情報を受信処理部１２から取得する。
【００２８】
ステップＳ１の処理を実装する場合の例としては次のようなものがある。ハードウェアで実行する処理の進捗を知りたい場合、データ処理量をカウントするカウンタを用意しておき、そのカウンタが既定値となった時点、すなわち、一定量のデータ（たとえば１シンボルデータ）に対する処理が終了した時点で進捗管理部１１が計時部１３から時刻情報を取得することで、時刻とデータ処理量の組を得る。また、ソフトウェアで実行する処理の進捗を知りたい場合であれば、処理の終了時点（例えば、特定の関数による処理が終了した時点）で進捗管理部１１が計時部１３から時刻情報を取得すればよい。また、受信処理がハードウェアとそのハードウェアを制御するプロセッサで構成されている場合、プロセッサがそのハードウェアから割り込みを受けるなどしてハードウェアで所定の処理が終わったことを知ることができるので、その割り込みが入る毎に進捗管理部１１が計時部１３から時刻情報を取得することにより、そこまでの処理が終わった時点の時刻情報を得ることができる。
【００２９】
ステップＳ２では、ステップＳ１で取得した情報（時刻と終了した作業量の組）に基づいて処理の進捗を判断するが、これは、上記の図６に示した点Ａを決定する（処理を軽減してスピードアップを図るタイミングを決定する）ことに相当する。このステップＳ２の実現方法は、大きく分けて、以下の２つがある。
【００３０】
一つ目の方法（方法１）では、一連の受信処理が終了していなければならない予定時間から逆算してそれぞれの処理のデッドラインをあらかじめ求めておき、実際の処理の進捗がそのデッドラインより遅れだしたら、処理を切り替える。
【００３１】
もう一つの方法（方法２）では、期待される処理の進捗を予め決めておき、実際の処理が決めておいた進捗からある一定以上遅れだしたら（許容範囲を超える遅延が発生したら）、処理を切り替える。
【００３２】
方法１の具体例について示す。無線ＬＡＮシステムの例で述べたように、多くの通信方式においては、通信路を流れているデータが終わる時刻（Ｔendとする）から一定の時間内にＡＣＫを返すということが規格で決められている。通信路を流れるデータが終わる時刻Ｔendは、受信データ（受信したフレーム）に含まれるデータ長の情報をデコードすれば計算できる。データ長の情報は、無線ＬＡＮシステムの場合に限らず一般的にフレームの先頭に置かれることが多いので、フレームの受信を開始して早い段階でＴendは計算できる。よって、ソフトウェア無線機は、時刻Ｔendに基づき、また、ＡＣＫを送信するための処理時間などを考慮して、規格で定められた一定時間内にＡＣＫを返すためには、どのくらいの時刻までに受信処理を終えなければならないか、すなわち受信処理終了予定時刻Ｔを決めることができる（たとえばＴ＜Ｔend＋ＳＩＦＳ）。これらのＴendおよびＴを算出する場合、ソフトウェア無線機では、受信処理部１２が、データ長の情報についてのデコード処理が終了すると、このデータ長の情報を進捗管理部１１へ通知し、進捗管理部１１は、通知された情報に基づいて、ＴendおよびＴを算出する。
【００３３】
このようにして終了予定時刻Ｔを決めた後、ソフトウェア無線機は、上述の無線ＬＡＮシステムの例（図３〜図６に示した例）のように、遅れを検出したら負荷の軽い処理に変更するものとして、終了予定時刻Ｔにぎりぎり間に合うようなタイミング（図６に示した点Ａに相当）を求める。すなわち、図６において処理の進捗が太線６０より右側に行きそうになったところで処理を切り替える。太線６０は負荷が軽い処理に切り替えて高速化した場合のソフトウェア無線機の受信処理能力（受信処理部１２の処理能力）を表しているので、太線６０より右側に入ってしまった場合、高速化したとしても終了予定時刻Ｔに間に合わせることができない。よって、点Ａは処理を切り替えれば時刻Ｔに間に合うであろうぎりぎりの点である。
【００３４】
上記の太線６０をどのように引くかは状況によって異なる。例えば、太線６０は高速化した後、順調に（実行時に遅延が発生しないで）処理が進んだ場合の処理能力とすることもできるし、高速化した後にもある程度実行時に発生する遅延を考慮した平均的な処理能力とすることもできる。また、デッドライン（上記の太線６０に相当）は本当にぎりぎりのラインで引いてしまうとそのラインより少しでも遅れたら間に合わなくなってしまうので、実際には少し余裕をもって引くことが考えられる。また、処理を切り替える点Ａを求める際には、処理の切り替えに伴うオーバーヘッドについても考慮すべきである。処理の切り替えに伴うオーバーヘッドとは、例えばソフトウェアの実行で切り替える場合であれば、分岐による遅延，命令キャッシュや命令メモリの内容の切り替えなどによる遅延である。また、「処理の切り替えができる場所はシンボルの区切れ目だけ」と言う制約がある場合は、処理を切り替えたいからと言ってすぐに切り替えることができないので、それを考慮する必要がある。
【００３５】
なお、図６にはソフトウェア無線機の通常の処理能力を示す直線６１も描かれているが、この方法１のようにデッドライン（太線６０）に基づいて判断する方法では、直線６１に対応する情報は必要ない。また、図６では複数の「時刻とデータ処理済量」の点（受信処理の進捗を示すモニター結果）が定期的に描かれており、各点で遅れているかどうかの判断が行われているが、この点は不定期でも良い（処理の進捗確認を実行する周期は不定期でもよい）。
【００３６】
次に、方法２の具体例について図７を用いて説明する。図７において、直線７２は、処理実行時の遅延を含まない通常の処理能力を表している。また、直線７０は、直線７２から一定量の遅れ、すなわちシステムで許容される最大遅延量を考慮して引かれた直線であり直線７２に平行である。また、図中の各点は、受信処理の進捗（モニター結果）を示している。なお、上記最大遅延量は、実行する処理に対応する通信規格などから導き出された時間制約を考慮し、この時間制約を満足できるように決定される。たとえば、ソフトウェア無線機の設計時に決定される。この方法２では、モニター結果を示す点が直線７０より右側に行きそうになったら、すなわち、期待される処理の進捗（直線７２）から一定以上遅れ出したら、処理を高速化する。図７の例では、点Ｂで直線７０の右側に達し、予定（直線７２）から一定以上遅れ出したことを進捗管理部１１が検出する。そして、進捗管理部１１は受信処理部１２に対し、負荷の軽い処理に切り換えるように指示を行い、受信処理部１２は、点Ｂから直線７１に示されるような処理速度の処理に変更して加速することで遅れを取り戻している。
【００３７】
また、図７に示した動作では、点Ｂの後、点Ｃで遅延が解消されたことを進捗管理部１１が検出し、その結果、受信処理部１２は高速な処理を終了して直線７２に対応する処理を開始している。なお、点Ｃで元の処理（直線７２で示された処理速度の処理）に戻したが、点Ｃの位置の選び方は任意である。また、元の処理に戻るのは必須ではなく、他の処理が選択可能であればそれを開始するようにしてもよい。
【００３８】
この方法２は、上述した方法１とは異なり、終了予定時刻Ｔを求めなくても適用できるので、放送の受信システムなどでも利用可能である。放送受信システムに適用する場合には、放送の無線処理の後段処理（動画像のデコード処理など）から要求される遅延時間に基づいて図７に示した直線７０に相当する直線を求めれば良い。
【００３９】
上記の方法１や２は、一連の受信処理を行っている途中で進捗を判断し高速処理に切り替えるものであるが、高速処理に切り替えるかどうかを過去の進捗状況（動作結果）に基づき判断することも可能である。すなわち、ある処理を実行する場合に、同じ処理を前回実行した際に遅延が発生していた場合には今回も同様の遅延が発生する可能性が高いと推測し、実行する処理の処理負荷を予め軽減する（通常よりも高速な処理を実行する）。例えば、無線ＬＡＮシステムであれば「１つ前のフレームの処理時は予定より時間がかかったので、今回は高速な処理を使う」というように処理を切り替えていく方法である。これは、以前の進捗が大きく遅れた場合は今回なるべく速い処理を適用し、以前少し遅れただけであれば今回少しだけ高速化する、というように、以前の進捗状況に応じて高速化の適用を変えていく方法である。この方法では、一度高速な処理に切り替えると、逆に想定より早く終わってしまう可能性もある。そのため、想定より早く終わりそうな場合には、元の処理に戻すなどして処理を適切に切り替える。
【００４０】
上記の方法１，２，過去の進捗に基づいて高速処理に切り替えるかどうかを判断する方法は、２つ以上を組み合わせて使用することも可能である。たとえば、方法２として示した制御を途中まで行い、最後に終了予定時刻Ｔに間に合わせるために方法１として示した制御を適用するなどである。
【００４１】
ステップＳ３を実行し、受信処理部１２が実行する処理を高速化する場合、無線ＬＡＮシステムにおける受信処理であれば、Equalize処理の一部を省くことで処理の負荷を軽減できることを既に述べたが、無線規格や無線機の実装方法に応じて様々な手法が適用可能である。主なものとしては、（手法Ａ）動作周波数を向上させる。（手法Ｂ）計算リソースを増強する。（手法Ｃ）一部の処理を省く。（手法Ｄ）アルゴリズムを変更する。（手法Ｅ）扱う処理データ量を減らす。などが挙げられる。
【００４２】
（手法Ａ），（手法Ｂ）は計算能力を高めることによりノイズ耐性を低下させることなく処理を高速化する方法である。（手法Ａ）の動作周波数を向上させる方法は、低電力動作のためにＤＶＦＳ（Dynamic  Voltage  Frequency  Scaling）などにより下げていた電圧や周波数を元に戻して動作させるなどして実現する。また、基板バイアス効果を利用することでより高い周波数での動作を可能にすることもできる。これらの方法により、回路のクリティカルパスに間に合う範囲であれば、周波数を高めることができる。（手法Ｂ）の実現は、現在利用中の計算リソース以外のリソースがあることが前提になる。例えば、低電力動作のために一部のプロセッサコアの電源を落として動作していた場合に、それらのプロセッサコアの電源を入れて使用するようにして、計算能力を高める。また、他の処理で利用中の計算リソースであっても、そこで実行中の処理がクリティカルなものでなければ、そのリソースを取得して使用することにより計算能力を高める方法も考えられる。例えば、バスリクエストの競合がボトルネックになって現在の処理が遅れている場合、優先させたい処理以外のバスリクエストの優先度を下げる，またはリクエスト自体を発生させないようにする，などの方法を取ることで実現する。
【００４３】
（手法Ｃ），（手法Ｄ），（手法Ｅ）は、ノイズ耐性を犠牲にして処理を高速化させるような方法である。（手法Ｃ）は、丸め誤差対策の計算をソフトウェアで行っている場合それをしないように変更する，繰り返し復号を行う誤り訂正処理における繰り返し回数を減らす，組織符号について誤り訂正のデコードをしない，などの変更を行うことにより実現する。また、（手法Ｄ）は、Equalizeの方式変更（Sphere  Decoder，MMSE，Zero  Forcinng）により処理を軽減して高速化することにより実現する。（手法Ｅ）は、たとえば、量子化ビット数を減らしてメモリアクセスやバスの負荷を軽減する，マルチプロセッサ構成でＭＩＭＯ（Multiple  Input  Multiple  Output）デコーディングを行う場合において、デコード時に必要な情報を渡すためのプロセッサ間の通信を省く，などにより実現する。
【００４４】
なお、（手法Ａ）〜（手法Ｅ）のうちの２つ以上を組み合わせて高速化することも可能である。処理を高速化する際、高速化の選択肢（方法）が複数ある場合には、どの処理を変更するか選択する必要がある。一般的に、高速化は消費電力の増大またはノイズ耐性の劣化につながるので、これらと高速化の実現はトレードオフの関係にある。そのため、ソフトウェア無線機では、状況によってどの方法で高速化を行うかを適応的に決定できることが望ましい。例えば、ノイズの多い環境では、あまり処理の軽い処理を選んでノイズ耐性を劣化させてしまうと受信できなくなる（ＣＲＣエラーなどになる）可能性があるため、通信路の状態と処理の変更による性能劣化を考慮して、変更する処理を選ぶとよい。通信路の状態を知るためには、一般的なＲＳＳＩの値やパイロット信号の電力，ＥＶＭ（Error  Vector  Magnitude），誤り訂正のデコーダの状態（ビタビデコーダならばパスメトリックの積算値，ターボ符号などの繰り返し復号を行うデコーダであれば停止までの繰り返し回数），Equalize処理時の補正値の量，などを参照する。
【００４５】
通信路の状態に応じて処理を切り替える場合の例を図８および図９を使用して説明する。なお、ソフトウェア無線機の受信処理部１２は、通常、図８および図９の直線８０で示した受信処理能力を持つものとする。また、受信処理部１２は負荷軽減の選択肢が直線８１で示した処理速度の動作と直線８２で示した処理速度の動作の２つであり、直線８１に対応する動作は直線８０に対応する動作（直線８０で示した処理速度の通常動作）より負荷が軽いがノイズ耐性は弱く、直線８２に対応する動作は直線８１に対応する動作よりさらに負荷が軽く、さらにノイズ耐性が弱いものとする。図８は、ソフトウェア無線機が通信路のノイズが十分に小さい状態で受信処理を行った場合の動作結果の一例を示している。具体的には、処理の途中で遅延増加を検出し、負荷の軽い処理に切り替えた場合の処理の進捗結果の一例を示している。図８に示した例では、直線８２は最もノイズ耐性が弱いが、通信路中のノイズが十分に小さいので全体として受信可能な品質を維持したまま時間制約を満たした処理を達成できる。一方、図９は、ソフトウェア無線機が、通信路中のノイズが図８より大きい状態で受信処理を行った場合の動作結果の一例を示している。具体的には、処理の途中で遅延増加を検出し、負荷の軽い処理に切り替えた場合の処理の進捗結果の一例を示している。
【００４６】
図８，図９に示したような動作を行う場合、ソフトウェア無線機では、進捗管理部１１が、受信処理部１２から取得可能なＲＳＳＩ値などを参考に通信路中のノイズ量を見積もり、どの処理を負荷の軽い処理に変更することにより全体として受信可能な品質を保つことができるか判断する。例えば図９に示した場合において、進捗管理部１１は、現在の通信路の状態では直線８２に対応するような負荷の軽い処理に切り替えると品質が低下しすぎてＣＲＣエラーが発生してしまうので、最低限直線８１に対応する処理は行って受信品質を維持したいと判断する。そして、受信処理中に遅延が発生して直線８０から遅れ出し、処理の進捗確認結果（モニター結果）が直線８１より右側に行きそうになった時点で受信処理部１２が実行している処理を切り替えて時間制約に間に合わせる。このように制御することにより、ある程度の受信品質を維持したまま、処理実行時に発生する遅延に対応できる。
【００４７】
どの処理を負荷の軽いものに変更するかについては、各処理の特徴と動作環境に着目して決定することもできる。例えば、通常は図１０の直線１００に示した処理速度で動作するソフトウェア無線機において、処理速度を高速化するための負荷軽減の候補としてEqualize処理（処理＃１）とビタビデコード処理（処理＃２）の２つがあるとした場合に、処理＃１を負荷の軽い処理に変更すると処理速度が直線１００から直線１０１に切り替わり、一方、処理＃２を変更すると処理速度が直線１００から直線１０２に切り替わるとする。このような場合には、図１０からわかる通り、処理＃１と処理＃２のどちらを変更しても同程度にしかスピードアップしない。そのため、加速という点では処理＃１，＃２どちらに切り替えても良いが、進捗管理部１１は、処理＃１，＃２どちらに切り替えるかについてその処理の特徴を考慮して決定する。例えばEqualize時の補正量が大きいときに、処理＃１を変更してEqualize処理を丁寧に行わないようなアルゴリズムに変更してしまうと品質劣化が大きいと予想できるので、処理＃２のビタビデコード処理の負荷を軽くすることで高速化を図る。逆に、Equalize時の補正量がほとんどなく、ビタビデコードのパスメトリックの積算値が大きい場合は、処理＃２は変更せず処理＃１のEqualize処理を変更することで高速化を図る。
【００４８】
さらに、負荷の軽い処理に切り替える際に、どの処理を変更するかについて、データの重要度を考慮して処理を選択する方法も考えられる。例えば、通信の制御情報が入っている部分についての受信処理は重要なのでなるべく処理を省かないように制御する方法などが考えられる。
【００４９】
最後に、受信処理を変更して処理速度を高速化する場合の具体例について説明する。図１１は、受信処理部１２の内部構成例を示す図である。図示したように、受信処理部１２は、ＦＩＲフィルタ２１−１および２１−２と、ＡＦＣ部２２−１および２２−２と、ＦＦＴ部２３−１および２３−２と、MIMO  decoding部２４と、arrangement部２５と、Viterbi  decoding部２６と、を備える。
【００５０】
ＦＩＲフィルタ部２１−１および２１−２は、図示を省略した２系統のアンテナで受信された各アナログ信号に対して所定の処理を実行し、得られた２系統のデジタル信号それぞれに対してＦＩＲフィルタ処理を行う。ＡＦＣ部２２−１および２２−２は、前段のＦＩＲフィルタ２１−１および２１−２から入力された信号に対してＡＦＣ（Automatic  frequency  control）処理を実行して周波数オフセットを補償する。ＦＦＴ部２３−１および２３−２は、前段のＡＦＣ部２２−１および２２−２から入力された信号に対してＦＦＴ処理を実行する。MIMO  decoding部２４は、ＦＦＴ部２３−１および２３−２から入力された信号に対して、Equalize処理を含むMIMO復号処理を実行する。なお、MIMO  decoding部２４が出力するMIMO復号処理結果は、軟判定値となる。arrangement部２５は、MIMO  decoding部２４から入力された信号に対して、データの入れ替えや整列処理を実行して、各データを正しい並び順に戻す。Viterbi  decoding部２６は、arrangement部２５から入力された信号に対してビタビ復号処理を実行する。
【００５１】
このような構成の受信処理部１２においては、MIMO復号処理における軟判定値の量子化ビット数を減らすことにより処理負荷を軽減し、受信信号処理の高速化が実現できる。
【００５２】
軟判定値の量子化ビット数を減らすことで処理負荷を軽減可能な理由について説明する。なお、上述した受信処理部１２のＦＩＲフィルタ２１−１および２１−２の後段で実行する各処理のうち、Viterbi  decoding部２６における処理を専用のハードウェア（図１に示したハードウェアエンジン３に相当）で実行し、その他の処理はソフトウェア（図１に示したプロセッサ１，２に相当）で実行するものとする。このように処理を切り分けた場合、軟判定値の量子化ビット数を減らすことにより、プロセッサ１や２において内部メモリへの書き込み量を減らせる。そのため、各プロセッサでの処理時間が短縮されて処理速度の高速化が実現される。加えて、プロセッサ１および２からハードウェアエンジン３へ転送するデータ量が減少するため、バスの占有時間が減り、バスアクセスの競合による処理時間の増加が少なくなる。さらに、ハードウェアエンジン３で行うビタビ復号化処理の内部演算精度を下げることができるため、動作周波数を上げることができ、誤り訂正処理の時間短縮が見込める。
【００５３】
ただし、軟判定値の量子化ビット数を減らして処理負荷を軽減する場合、注意すべき点が存在する。まず、デコードの途中で軟判定値のビット数が変わることへの対応が必要となる。例えば、デコードの途中で軟判定値を6bitから4bitに変更する場合、パスメトリックの積算値が2bit分ずれるのでそれを補正する必要がある。具体的な対応方法としては、4bitに切り替える前までのパスメトリック値を1/4にするか、4bitへ切り替えた後はブランチメトリックを４倍して使用する。また、量子化ビット数を減らして動作周波数を上げる機能を実装する場合、量子化ビット数を減らして動作周波数を上げた後も正しく動作するように考慮した上で回路設計を行う必要である。
【００５４】
このように、本実施の形態のソフトウェア無線機は、処理の進捗をモニターし、処理の進捗（速度）が予め想定していたスピードより遅れたことを検出した場合（遅延要因によって予定より遅れ出したことを検出した場合）、ソフトウェアによる処理の一部を負荷の軽い処理に変更して処理を高速化し、遅れを取り戻すように動作することとした。これにより、処理の実行中に想定外の遅延が発生した場合であっても、発生した遅延をキャンセルして予定通りに処理を終了させることができる。この結果、遅延時間が変動しても無線規格で定められた時間制約に対応した通信を行うことが可能となり、システム設計時に確保しておく処理遅延についてのマージンを極力少なくすることができる。
【符号の説明】
【００５５】
１，２  プロセッサ、３  ハードウェアエンジン、４，５  フィルタ、１１  進捗管理部、１２  受信処理部、１３  計時部、２１−１，２１−２  ＦＩＲフィルタ、２２−１，２２−２  ＡＦＣ部、２３−１，２３−２  ＦＦＴ部、２４  ＭＩＭＯ  ｄｅｃｏｄｉｎｇ部、２５  ａｒｒａｎｇｅｍｅｎｔ部、２６  Ｖｉｔｅｒｂｉ  ｄｅｃｏｄｉｎｇ部。
【図１】
2010278829.tif 000003
【図２】
2010278829.tif 000004
【図３】
2010278829.tif 000005
【図４】
2010278829.tif 000006
【図５】
2010278829.tif 000007
【図６】
2010278829.tif 000008
【図７】
2010278829.tif 000009
【図８】
2010278829.tif 000010
【図９】
2010278829.tif 000011
【図１０】
2010278829.tif 000012
【図１１】
2010278829.tif 000013