JP4131736B2

JP4131736B2 - 無線通信装置及び無線通信方法

Info

Publication number: JP4131736B2
Application number: JP2006014455A
Authority: JP
Inventors: 弘吉田; 伸一菅野; 武司富澤; 稔行方; 博史鶴見; 雄三玉田
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1998-12-21
Filing date: 2006-01-23
Publication date: 2008-08-13
Anticipated expiration: 2019-12-10
Also published as: JP2006203911A

Description

本発明は無線通信装置に関し、特に無線機能を記述する専用言語を用いて無線機能をソフトウェア化する無線通信装置及び無線通信方法に関する。

現在携帯電話をはじめ移動通信システムに対する需要が非常に高くまた端末市場は活況を呈している。ところが、現在世の中にはいろいろな種類の通信システムが林立しているのが現状である。

例えば携帯電話では日本ではＰＤＣ方式、米国ではＡＭＰＳ方式やＣＤＭＡ方式、欧州ではＧＳＭ方式と、さまざまな方式が混在している。さらに同じ日本国内においても携帯電話とは別にＰＨＳというシステムが存在する。

ＩＭＴ−２０００という世界統一方式の標準化作業がすすめられているが、日米欧で全く同一のシステムとなる可能性は低い。

このような状況下において、複数のシステムに使用可能な、移動通信端末のマルチモード化に対する需要は非常に高い。しかしながら、端末におけるこのようなマルチモード化は非常に困難であり、物理的に２種類の端末をひとつの筐体の中へ内蔵するという単純な構成によってデュアルモード化するのが限度であった。

無線通信装置の従来例について以下、図面を参照して説明する。

図１６は、無線通信装置の従来例の構成を示す。図中７０１はＲＦ（高周波）の信号を増幅するアンプである。７０２は周波数変換をおこなうミキサである。７０３はミキサ７０２にたいして信号を供給するシンセサイザである。７０４はアナログ信号をディジタル信号に変換するＡＤ変換器である。７０５はディジタル信号をアナログ信号に変換するＤＡ変換器である。７０６は専用ＩＣ（ＡＳＩＣ）である。７０７はディジタル信号処理プロセッサ（ＤＳＰ）である。７０８は専用ＩＣ（ＡＳＩＣ）である。７０９は中央演算処理装置（ＣＰＵ）である。７１０はＩ／Ｏインターフェイスである。７１１はアンプ７０１〜Ｉ／Ｏインターフェイス７１０からなるハードウェア（の集合）である。７１２はＯＳである。７１３はＯＳ７１２上で動作するアプリケーションプログラムである。７１４はＤＳＰ７０７上で動作するアプリケーションプログラムである。７１５はＯＳ７１２〜アプリケーションプログラム７１４からなるソフトウェア（の集合）である。

図１６に示す従来例では、無線機はアンプ７０１、ミキサ７０２、シンセサイザ７０３、ＡＤ変換器７０４及びＤＡ変換器７０５等のアナログ回路と、専用ＩＣ（ＡＳＩＣ）７０６，７０８、ＤＳＰ７０７及びＣＰＵ７０９等のディジタル回路と、Ｉ／Ｏインターフェイス７１０等とからなるハードウェア７１１と、ＣＰＵ７０９上で動くＯＳ７１２およびそのＯＳ上で動くアプリケーションプログラム７１３や、ＤＳＰ用のプログラム７１４等からなるソフトウェア７１５から構成されていた。

次に図１６を参照し、無線端末の従来例の動作について説明する。受信時は、図示しないアンテナから入力された高周波信号をＲＦ部（図中７０１、７０２、７０３）で周波数の低いベースバンド信号に変換し、ＡＤ変換器７０４で所望信号をディジタル信号に変換し、ＤＳＰ７０７やＣＰＵ７０９を用いて送信されてきた信号を復調する動作をおこなう。

送信時は、送信するもとの信号に対してＣＰＵ７０９やＤＳＰ７０７で変調の操作をおこない、その信号をＤ／Ａ変換器７０５でアナログ信号に変換し、ＲＦ部で高周波信号に変換してアンテナより送信する動作をおこなう。

上述のＤＳＰやＣＰＵが実行するプログラムはソフトウェア７１２、７１３、７１４として無線端末の内部のメモリ等に保存されている。

またアナログ部に対する制御は例えばＡＳＩＣ７０８を介してアプリケーションプログラム７１３からおこなわれる。図ではアナログ部の制御はＡＳＩＣ７０８からなされるが、実際にはＣＰＵ７０９やＤＳＰ７０７などから直接制御される場合もある。

ここで、このような無線端末の従来例には次のような間題があった。すなわち無線端末の従来例ではアプリケーションプログラム７１３、７１４がＤＳＰ７０７あるいはＣＰＵ７０９専用のプログラムであり、汎用性がなかった。したがってこれらのプログラムはある特定のハードウェアアーキテクチャ専用のものであり、他の異なるハードウェアアーキテクチャを持つ無線機でそのまま利用することが不可能であった。

またアナログ回路からなるＲＦ部に対する制御はＡＳＩＣやゲートアレイなどの専用のＬＳＩを用いてなされるため、他の異なるハードウェアで利用することが不可能であった。

このように、上述した従来の無線通信装置においては、アプリケーションプログラムは、汎用性がなく、その利用はハードウェアに依存した特定目的に限定されるという間題点があった。

本発明はかかる問題点に鑑みてなされたものであって、汎用性を有し、ハードウェアアーキテクチャに依存しないアプリケーションプログラムを利用可能な無線通信装置及びその無線通信方法を提供することを目的とする。

本発明の請求項１に係る無線通信装置は、無線信号を送受信する送受信手段と、受信した前記無線信号をディジタル信号に変換して出力するＡＤ変換手段と、送信するディジタル信号を前記無線信号に変換して出力するＤＡ変換手段と、前記ＡＤ変換手段の出力に対するディジタル信号処理及び前記ＤＡ変換手段の入力に対するディジタル信号処理を行うディジタル信号処理手段とを有するハードウェアによって複数の無線機能を実現する移動通信のための無線通信装置であって、所定の無線機能を実現するための関数を含み前記ハードウェアに依存した第１のライブラリを記憶する記憶手段と、アプリケーションプログラムのコンパイル時に前記ハードウェアに依存しない第２のライブラリがリンクされて生成された実行ファイルをダウンロードし、実行に際して前記第１のライブラリが含む前記関数を参照する前記実行ファイルを基本ソフトウェア上で実行させることにより、前記送受信手段と、前記ＡＤ変換手段と、前記ＤＡ変換手段と、前記ディジタル信号処理手段との少なくとも１つを制御して前記複数の無線機能を実現する制御手段とを具備することを特徴とする。

本発明によれば、汎用性を有し、ハードウェアアーキテクチャに依存しないアプリケーションプログラムを利用可能となるという効果を有する。

以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は本発明の第１の実施の形態を説明するための説明図である。

図中１はＲＦの信号を増幅するアンプである。２は周波数変換をおこなうミキサである。３はミキサ２にたいして信号を供給するシンセサイザである。４はアナログ信号をディジタル信号に変換するＡＤ変換器である。５はディジタル信号をアナログ信号に変換するＤＡ変換器である。６はプログラマブルロジック（ＦＰＧＡ）である。７はディジタル信号処理プロセッサ（ＤＳＰ）である。８はＩ／Ｏインターフェイスである。９は中央演算処理装置（ＣＰＵ）である。１０はアンプ１〜ＣＰＵ９からなるハードウェアである。

１１はＯＳである。１２はハードウェアの動作をＯＳから制御するためのデバイスドライバである。１３はさまざまな関数群が記述されたライブラリである。１４はアプリケーションである。１５はＯＳ１１〜アプリケーション１４からなるソフトウェアである。

次に本実施の形態である無線端末の動作について説明する。

図１のようにＣＰＵ９上でＯＳ１１が動作し、このＯＳ１１が無線機全体の動作を制御する。ＯＳ１１はＣＰＵ９に依存した基本ソフトウェアである。ＣＰＵ９以外のハードウェア、例えばアンプ１、ミキサ２、シンセサイザ３、ＡＤＣ４、ＤＡＣ５、ＦＰＧＡ６、ＤＳＰ７、Ｉ／Ｏインターフェイス８と、ＯＳ１１の間にはデバイスドライバ１２が介在し、このデバイスドライバ１２は、ＯＳ１１より出力された命令をそれぞれのハードウェアが実行可能な命令に変換しＣＰＵ９を経由してデータを送出し、また、各ハードウェアから状態を示す出力があればそれはＣＰＵ９を介してデバイスドライバ１２に引き渡されてＯＳ１１が解釈できる信号に変換する役割を果たす。

したがって、デバイスドライバ１２はＯＳ１１とハードウェア１０に密接に関係があり、ハードウェア１０が異なればデバイスドライバ１２はそれに合わせて異なるものが必要となり、またＯＳ１１が変わればそれに対応したデバイスドライバ１２が必要になる。

ライブラリ１３はハードウェア１０を制御し、あるいは機能そのものを実現するソフトウェアの集合体であり、複数の関数（命令セット）からなる。ライブラリ１３はアプリケーション１４から出される命令の中で汎用性が高い機能、およびハードウェア構成に依存する関数の集合である。したがってライブラリ１３はハードウェア１０やＯＳ１１に依存したものとなる。

以上述べたＯＳ１１、デバイスドライバ１２およびライブラリ１３は、ハードウェア１０に依存するソフトウェアであり、これらをまとめてここでは基本ソフトウェアと呼ぶ。

アプリケーション１４は無線機能を記述する専用言語（ここでは以下「radio description language」と呼ぶ）を用いて記述して得たプログラムであり、その記述はハードウェア１０に依存しない。すなわち、アプリケーション１４はハードウェア１０が変わっても同じプログラムが利用できる。

異なるハードウェア１０に対する制御の相違は、上述のデバイスドライバ１２、ＯＳ１１、ライブラリ１３によって吸収することができ、アプリケーション１４の変更は不要である。換言すると、アプリケーション１４とＯＳ１１あるいはライブラリ１３との間のインターフェイスが同じであればアプリケーション１４は異なるハードウェア上で動作可能となる。アプリケーション１４は上述したように無線記述言語を用いて記述されて得られる。

次に図２を用いて本実施の形態の無線機のソフトウェアの実行方法を説明する。

図２は、本実施の形態のソフトウェアの動作を説明する説明図である。図２において、図１と同等の構成を示すものについては同一の番号を付して説明する。図２中、１０は無線機のハードウェアを示しており、図１におけるアンプ１〜ＣＰＵ９等から構成される。１１はハードウェア１０上で動作するＯＳである。２０は無線機能が記述されたアプリケーションプログラムであり、図２の例ではソースファイルを示している。１２はデバイスドライバであり、アプリケーションなどによってＯＳ１１に出された命令をハードウェア１０に対する命令へ変換する動作をおこなう。１３は関数などが記述されたライブラリである。１６はアプリケーションプログラム２０を実行ファイル（Executable File）１７に変換するコンパイラである。

なお、図１のアプリケーション１４は、図２における実行ファイル１７に相当する。しかし、アプリケーションプログラム２０がコンパイル不要なインタプリタ言語等で記述されている場合には、アプリケーションプログラム２０は図１のアプリケーション１４そのものである。

無線記述言語で記述されたアプリケーションプログラム２０は、実行する前にコンパイルされる。コンパイルはソースプログラムのＯＳが解釈できる機械語への変換を意味し、コンパイラ１６を用いておこなうことによってなされる。

コンパイラ１６によってコンパイルされた実行ファイル１７はＯＳ１１上で実行される。実行時に実行ファイル１７に記述された命令に応じてライブラリ１３から必要な関数を引いて来て利用することによって実際の無線機能がソフトウェア的に実現される。

ライブラリ１３には無線機能をハードウェア上で実現するための制御情報を生成するプログラムや、ＦＰＧＡやＤＳＰなどのプログラムそのものが予め関数として用意されており、アプリケーションによって与えられた関数とパラメータに基づいて、必要なプログラムを適切なパラメータとともにＯＳ１１へ引き渡す。

このライブラリ１３は、あるハードウェア構成の場合はハードウェア的に実現されていた機能が、別のハードウェア構成の場合はソフトウェアで実現するような場合があるなど、ハードウェア構成によって異なるものとなる。

したがってライブラリ１３はハードウェアに依存したものとなり、ハードウェア１０が変更されるとそれに伴って変更される性質のものである。

また上述の方法を用いた場合、用意しておくライブラリが膨大なものとなる場合がある。しかしながらこのライブラリを全て無線機側で保持しておく必要はなく、頻繁に利用されるライブラリのみを無線機側で持ち、それ以外のライブラリは外部のものを利用し、コンパイル時にリンクしてしまう方法もある。

このようにライブラリを構成することで、無線機で持たなければならないライブラリを必要最小限に留めることが可能となる。

この場合の流れを図３に示す。図３のように、ここではライブラリは、無線機側にもつ第１のライブラリ３１と外部にもつ第２のライブラリ３２に分けられ、コンパイル時に第２のライブラリ３２がリンクされ実行ファイルが作成され、この実行ファイルの実行時に第１のライブラリ３１が参照されることによって無線機としての動作を実現する。

頻繁に参照される関数を第１のライブラリに用意し、残りの関数を第２のライブラリに用意することで、無線機側で持たなければならないライブラリの規模を大幅に縮小することができる。

ところで、図２及び図３の例では、アプリケーションプログラム２０及びコンパイラ１６を設ける位置は、限定されていない。図１のアプリケーション１４に相当する実行ファイル１７が無線機内のメモリに保持されるのに対し、アプリケーションプログラム２０（ソースファイル）及びコンパイラ１６は、無線機内に保持してもよく、無線機外部に保持してもよい。

図２の例では、アプリケーションプログラム２０に対してコンパイラ１６を用いたコンパイル処理によって作成した実行ファイル１７をメモリに格納し、このメモリを無線機の製造時に無線機に搭載することが一般的である。

これに対し、図３の例では、第２のライブラリ３２を機能拡張用と考えると、その性質上、第２のライブラリ３２のリンク処理及びコンパイル処理は、無線機の販売後に実施されることになる。無線機のメモリ容量、ＣＰＵの負荷等を考慮すると、アプリケーションプログラム２０及びコンパイラ１６を第２のライブラリ３２と共に、無線機外部に用意した方がよい。例えば、アプリケーションプログラム２０及びコンパイラ１６を基地局等に用意し、基地局等においてアプリケーションプログラム２０をコンパイルすると共に第２のライブラリ３２をリンクし、これによって生成した実行ファイル１７を無線機にダウンロードさせる。

なお、アプリケーションプログラム２０及びコンパイラ１６を無線機内のメモリに保持し、基地局等からダウンロードした第２のライブラリを用いて、無線機内で実行ファイル１７を生成するようにしてもよいことは明らかである。

次にＯＳ１１の動作を説明する。ＯＳ１１はコンパイルされた実行ファイル１７とライブラリ１３によって与えられる命令をハードウェアブロックのデバイスドライバ１２へ振り分ける作業をおこなう。

実行ファイルから出力された命令が、ＤＳＰに対するものであればＤＳＰ７のデバイスドライバに動作プログラムを送り、またミキサへの制御命令であればミキサ２のデバイスドライバに制御情報を送出する。

デバイスドライバ１２はＯＳ１１を介して実行ファイル１７（およびライブラリ１３）によって与えられた命令をハードウェアレベルでの命令に変換する役割を果たす。この命令は最終的にはＣＰＵ９を介して各ハードウェアに対して信号を送り、所望の機能を実現させる。

次に、本実施の形態の具体的処理例を説明する。

始めに、受信周波数の設定を例に、本実施の形態の無線機の動作を説明する。上述の如く、アプリケーション１４には受信周波数を設定するための関数が用意されており（ここで関数名を”set-receive-frequency”とする）、次のように記述されている。

#-----Application Source Program
$freq_recv = 1.9e9;
set_receiving_frequency($freq_recv);
#-----
この例は１９００ＭＨｚの信号を受信するための命令を示しており、実行時には上記関数set_receiving_frequencyは変数$freq_recvを引数としてＯＳ１１に引き渡す
実際に受信周波数を設定するためにはシンセサイザの発振周波数の設定を行う必要がある。このような受信周波数→シンセサイザ発振周波数への変換はハードウェアの構成によって異なるものであるため、アプリケーションの実行時にライブラリ１３が参照されそこに用意された関数によってなされる。

たとえばライブラリ１３には受信周波数の設定を受けてそれをシンセサイザ発振周波数へ変換する関数(仮に”receiving-freq-to-synthesizer”とする)が引かれ、次のようになる。

#-----Library
$freq_synth = receiving_freq_to_synthesizer（1.9e9);
#-----
なお上記の例ではアルファベット文字で記述されているが実際には上記の意味を持つ機械語である。

次に図４を用いて、動作例を説明する。図４は、本実施の形態に係る無線機のハードウェア構成を信号の流れに沿って示す図である。図中１はアンプ、２はミキサ、３はシンセサイザ、４はＡ／Ｄ変換器であり、アンテナから受信された信号はアンプ１によって増幅された後、ミキサ２によってシンセサイザ３から供給される信号と乗算されて低いＩＦ周波数へ周波数変換され、Ａ／Ｄ変換器でディジタル信号へ変換される。

ここで例えばＩＦが３８０ＭＨｚである場合、シンセサイザの発振周波数は受信周波数（１．９ＧＨｚ）とＩＦ（３８０ＭＨｚ）との差であるところの１５２０ＭＨｚとなる。受信周波数からシンセサイザの発振周波数への変換が、コンパイルされたアプリケーションプログラムの実行時にライブラリ１３によってなされる。

このような受信周波数→シンセサイザ発振周波数への変換はハードウェアに依存した部分であるために、変換処理が直接アプリケーションプログラムに記述されることはなく、実行時にライブラリの部分で変換処理に相当する処理が行われる。

さらに、コンパイルされたバイナリがライブラリ１３を参照して実際にＯＳ１１上で動作するとき、上記ライブラリによって決定されたシンセサイザの発振周波数の設定はＯＳ１１を介してデバイスドライバ１２の処理によって実行される。

そのときにデバイスドライバ１２へ渡す命令はやはりライブラリ１３によって生成される。例えば次のような命令となる。

#-----Output to device driver through OS
$freq_pdet=2.0e5; #位相比較周波数は200,000Hz(=200kHz)
$freq_ref=1.0e7; #基準周波数は10,000,000Hz(=10MHz)
$1 = $freq_synth; #変数$1は$freq_synthに格納された値
$2 = $freq_pd ; #変数$2は位相比較周波数
$3 = $freq_ref; #変数$3は基準周波数
out_to_syn($1、$2、$3); #シンセサイザに対して変数$1、$2、$3を出力
#-----
ここまでの動作はコンパイルされたアプリケーションが実行時にライブラリ１３を参照することによってなされる。

次に、この命令を受けたＯＳ１１はデバイスドライバ１２のうちシンセサイザ３を駆動するデバイスドライバに対してパラメータ＄１、＄２、＄３を引き渡す。out_to_synという関数がシンセサイザ３のデバイスドライバに対する命令であることを意味している。

ＯＳ１１はシンセサイザ３のデバイスドライバに出力するためのアドレスを保持しており、この命令を受けたＯＳ１１は予め定められたシンセサイザのＩ／Ｏポートに対して３つのパラメータ（＄１、＄２、＄３）を出力する。

ここでは＄１が発振周波数、＄２が位相比較周波数（２００ｋＨｚ）、＄３が基準周波数（１０ＭＨｚ）の値が入力されている例を示している。ここでは位相比較周波数や基準周波数はハードウェア１０の構成に応じて自動的に設定されるためにアプリケーション１４によって明示的に与えられることはなく、ライブラリ１３によって自動的に与えられる。

次にシンセサイザ３の詳細を示すハードウェア構成の例を図５に示す。図５中１８はリファレンスカウンタ、１９はプログラマブルカウンタ、２３はスワローカウンタ、２４はプリスケーラであり、リファレンスカウンタ１８は入力された水晶発振器等の基準信号を分周して位相比較器に供給する。

またプログラマブルカウンタ１９、スワローカウンタ２３、プリスケーラ２４はこれらを組み合わせることによって全体として比較的大きな分周をおこなう可変分周器として動作する。

これらの分周器の動作は、一般的な分周器と同様であるので詳細説明は省略する。またリファレンスカウンタ１８、プログラマブルカウンタ１９、スワローカウンタ２３、プリスケーラ２４はＰＬＬ−ＩＣ２５に内蔵されている。

ここで、ＯＳ１１からパラメータを受け取ったデバイスドライバ１２は、＄１、＄２、＄３のパラメータの値をシンセサイザ３で利用しているＰＬＬ−ＩＣ２５の設定信号に変換して送出するという動作をおこなう。

例えばこの場合、
・発振周波数と位相比較周波数の比が１９００ＭＨｚ／２００ｋＨｚ＝９５００
→比較周波数側の総分周数が９５００
・基準周波数と位相比較周波数の比１０ＭＨｚ／２００ｋＨｚ＝５０
→基準周波数側の分周数が５０
と算出される。シンセサイザ３の構成が図５に示されるものであった場合、これらの値をもとに、分周器の分周数が計算され、
・プログラマブルカウンタ２２のカウント値が１４８
・スワローカウンタ２３のカウント値が２８
・リファレンスカウンタ２１のカウント値が５０
となるような信号がデバイスドライバ１２からシンセサイザ３のＰＬＬ−ＩＣ２５に対して送出され、シンセサイザ３の発振周波数が最終的に設定される。

デバイスドライバ１２ではこれらの値が２値のディジタル信号に変換され、次のようなビット列が生成される。（カウンタは全て８ビットを仮定）
#-----Synthesizer Data
#-----Programable Counter
10010100 #148を二進数に変換
#-----Swallow Counter
00011100 #28を二進数に変換
#-----Reference Counter
00110010 #50を二進数に変換
#-----
このあと、デバイスドライバ１２は生成されたビット列をＣＰＵ９に送出する。ＣＰＵ９は与えられたデータをハードウェアすなわちＰＬＬ−ＩＣ２５に対してシリアルで、例えば図６に示すようなｄａｔａとｃｌｏｃｋとｓｔｒｏｂｅ信号を送出する。

なお本実施の形態ではＣＰＵ９から直接シンセサイザ３へ信号を出力する例を挙げているが、Ｉ／Ｏ用の専用デバイスを設けそこから信号出力をおこなってもよい。

図６はＣＰＵ９からシンセサイザ３に対して送出されるデータ列の例を示したものであり、上記の例のプログラマブルカウンタに分周数１４８を設定する例を示している。

信号は３種類のシリアル信号として送られ、データの内容を示すＤＡＴＡ、データの区切りを示すＣＬＯＣＫ、そしてデータの送出終了を示すＳＴＲＯＢＥからなる。

データはＣＬＯＣＫ信号の立ち下がりでラッチされる。順に１００１０１００というデータをこのクロックの立上りに同期させて送出することで所望の分周数がプログラマブルカウンタに送られる。

データ送出終了後にＳＴＲＯＢＥ信号が立ち上がってデータが終了したことが示されプログラマブルカウンタの分周数として設定される。

このような動作を、スワローカウンタ、リファレンスカウンタに対して同様におこなうことによって、シンセサイザには所望の分周数が設定される。これによって最終的に所望の発振周波数が得られ、所望の周波数の信号の受信が可能となる。

以上のような段階を経て、最初アプリケーションプログラムに記述された、「１９００ＭＨｚの信号を受信せよ」という命令が、最終的に、ロジックデータとしてシンセサイザのＰＬＬ−ＩＣに送出されるという命令に変換され実際に受信が可能となる。

このようにアプリケーションプログラムには物理層制御の命令のみを記述するだけで、ライブラリ／ＯＳ／デバイスドライバ／ハードウェアが適切に動作することによって所望の動作を実行することが可能となる。

以上のように無線機を構成することによって、アプリケーションプログラムから無線機側を見たインターフェイス上には、動作対象がハードウェアであるかソフトウェアであるかという区別が無いため、ハード／ソフトを意識しないプログラミングが可能となり、また、ハードウェア側から見れば、アプリケーションプログラムとのインターフェイスを統一的に取り扱うことによってあらゆるアプリケーションプログラムが汎用的に利用可能となる。

また、パーソナルコンピュータ等の計算機では無線の物理層制御をアプリケーションプログラムからハードウェアに依存せずに実行することは不可能であったが、本発明の無線機を用いることによってアプリケーションプログラムからハードウェアに依存しない無線物理層制御が可能となる。

なお、一般的なコンピュータシステムにおいても、アナログ回路の制御は、上述した従来例と同様に、そのアナログ回路を制御するための専用のハードウェアを設けて行うようになっており、本実施の形態のようにライブラリを用いてアナログ回路を制御する技術は考えられていない。

図７及び図８は本発明の他の実施の形態を示すフローチャートである。

図１６の実施の形態における無線通信装置のハードウェアは、アナログ部とディジタル部からなるが、無線機能をアナログ部で実現するか、ディジタル部で実現するかは本ハードウェア上で動作するソフトウェアによって選択することが可能である。たとえば、アナログ部にベースバンドのアクティブフィルタが具備されており、ディジタル部にＦＰＧＡによるＦＩＲフィルタが具備されているような場合を考えると、アナログベースバンドフィルタをローパスフィルタとして用い、入力受信信号の余分な周波数成分を取り除くことが可能であるが、このアナログフィルタをスルーで用い、ディジタル部のＦＩＲフィルタに適切なタップ係数を付与することによって、全く同一又は類似した周波数特性を持つフィルタを形成可能である。

もちろん同一機能を実現できる範囲（たとえばローパスフィルタの例ではカットオフ周波数や次数等）はハードウェアによって制限されるが、特性的にオーバーラップする部分がある。本発明におけるアプリケーションプログラムはハードウェアの区別なく記述されているので、ある機能を実現する回路部分（以下、機能ブロックという）がアナログ部とディジタル部とのいずれにあっても実現可能である場合には、その割り振りが問題となる。機能ブロック、即ち、ある機能を実現するハードウェアの選択をライブラリ１３がおこなうことが本実施の形態の特徴である。

まず第１の方法は、ライブラリはアプリケーションプログラムの命令をできる限りアナログブロックで実現する方向で全体をコンフィギュレーションする方法である。たとえば機能Ａがアナログ部でもディジタル部でも実現できる場合に、その機能を優先的にアナログ部に割り当ててゆくという方法である。

図７はこの方法の詳細な手順を示している。まずアプリケーションプログラムのコンパイル時に、アプリケーションプログラム内に記述された無線機能に関する命令を解読する（ステップＳ1 ）。次にその機能がディジタルとアナログ部のいずれかまたは両方で実現可能であるかどうかを調べる（ステップＳ2 ）。このときもしディジタル部あるいはアナログ部の一方でしか実現できない場合には実現できるブロックで実行するようにコンパイルされるが、ディジタル部とアナログ部の両方で実現可能である場合、優先的にその機能をアナログ部で実現するようにコンパイルされる（ステップＳ4 ）。またもしディジタル部でもアナログ部でも実現できない場合は異常終了する。

このようにコンパイルすることによって、たとえばディジタル部で実現するとディジタル回路の消費電力が必要であるのに対して、アナログ部で実現した場合、たとえばその機能がパッシブ回路によって実現可能であるような場合には消費電力を０にすることが可能となり、無線装置の低消費電力化が可能となる。

次に第２の方法は、第１の方法とは逆に、ライブラリはアプリケーションプログラムの命令をできる限りディジタルブロックで実現する方向で全体をコンフィギュレーションする方法である。

図８はこの方法の詳細な手順を示している。まずアプリケーションプログラムのコンパイル時に、アプリケーションプログラム内に記述された無線機能に関する命令を解読する（ステップＳ1 ）。次にその機能がディジタルとアナログ部のいずれかまたは両方で実現可能であるかどうかを調べる（ステップＳ2 ）。このときもしディジタル部あるいはアナログ部の一方でしか実現できない場合には実現できるブロックで実行するようにコンパイルされる。ディジタル部とアナログ部の両方で実現可能である場合、優先的にその機能をディジタル部で実現するようにコンパイルされる（ステップＳ5 ）。またもしディジタル部でもアナログ部でも実現できない場合は異常終了する。

このようにコンパイルすることによって、たとえばアナログ部で実現すると特性があまりよくない場合に、ディジタル部で実現した場合、理想的な特性が実現でき、無線装置の全体の良好な特性が得られる。

上記のディジタル部／アナログ部の実現手段の選択は、すべての無線機能に関して一律に設定されるのではなく、無線機能ブロックごとに区分けし、たとえばフィルタはディジタル部優先、周波数変換器はアナログ部優先などとあらかじめ定めておくことによって、全体として特性の向上を実現することが可能となり、さらにこの選択に関してはアプリケーションプログラムはまったく関与しないため、アプリケーションの開発は独自に可能で、ハードウェアに依存した無線機能実現の手段はコンパイラやライブラリが自動的に割り当てられるため理想的な構成が実現できる。

以上述べた、アナログ部／ディジタル部の機能の選択は、その法則（ディジタルから割り当てるか、アナログから割り当てるか）をあらかじめライブラリに記述することによって、アプリケーションプログラムの内容によって、自動的に振り分けることが可能となる。たとえば上述のようにアナログのローパスフィルタに比べて、ディジタルフィルタの消費電力が大きい場合、可能な限りアナログフィルタで処理した方が、無線機全体の低消費電力化が図れる。このような場合はライブラリによって、優先的にアナログ部に処理されるように、無線機が制御される。

この場合、ライブラリは、アナログ部とディジタル部の両方で実現可能な無線機能についてのテーブルを保持し、テーブルに記述された無線機能の限界性能、および、法則を参照することによって、ある機能をアナログ部又はディジタル部のいずれに割り当てるかを決定する。

上記実施の形態においては、機能ブロック別にアナログ／ディジタル部での実現の振り分け方法を決めたが、信号処理速度によって別けてももちろんよい。

さらに本実施の形態のバリエーションとして次のような実施の形態が挙げられる。すなわちアナログ部、ディジタル部両方で機能が実現できる場合、ある判定条件を元にどちらで機能を実現できるか決定する方法である。図９はこの方法を示すフローチャートである。

まずアプリケーションプログラムのコンパイル時に、アプリケーションブログラム内に記述された無線機能に関する命令を解読する（ステップＳ1 ）。次にその機能がディジタルとアナログ部のいずれかまたは両方で実現可能であるかどうかを調べる（ステップＳ2 ）。このときもしディジタル部あるいはアナログ部の一方でしか実現できない場合には実現できるブロックで実行するようにコンパイルされる。ディジタル部とアナログ部の両方で実現可能である場合、次のステップＳ3 へ進む。次のステップＳ3 では、あらかじめ定められた判定基準をもとにディジタル部で実行するかアナログ部で実行するかを判断し、ステップＳ4 又はステップＳ5 において、アナログ部又はディジタル部のいずれかで機能を実現する。

上記判断基準としては次のようなものが挙げられる。

（１）消費電力が少ない方を選択する
（２）特性がよい方を選択する
（３）遅延時間が少ないほうを選択する
（４）ディジタル部とアナログ部間の信号の往復が少ない方を選択する
上記（１）はアナログ部、ディジタル部で実現した場合の消費電力を見積もりそれをもとに少ないほうを選択する。（２）はたとえば所望の特性はアナログ部、ディジタル部いずれでも選択可能であるが、ディジタル部の方がより良好な特性を実現可能である場合はディジタル部を選択する。（３）は機能を実現するための信号処理時間を見積もり、より遅延時間の少ないほうを選択する。（４）はたとえば所望の無線信号処理機能をディジタル部で実現した場合に、受信信号がいったんアナログ部を出てディジタル部へ入り所望の処理を行い、再度アナログ部へ入力する必要があるような場合は、信号のディジタル部とアナログ部間の往復を避けるためにアナログ部で処理するように選択する。

以上のように動作することによって、最適な無線部の構成が実現可能となる。

図１０は本発明の第３の実施の形態において採用されるアナログの機能ブロック（アナログブロック）を示す説明図である。本実施の形態は、アナログブロックの構成が異なるのみであり、ディジタルの機能ブロック及びソフトウェアの構成は図１と同様であり、図示を省略する。

図１０において、アナログブロック１３１は仕様記述部１３２を有している。なお、図１における全てのアナログブロックがアナログブロック１３１と同様に仕様記述部１３２を備えていてもよく、一部のアナログブロックのみが仕様記述部１３２を備えていてもよい。なお、上述したように、アナログブロックとしては、例えばアンプ、ミキサ、シンセサイザなどがある。

仕様記述部１３２は、アナログブロック１３１の仕様が記述されている。仕様記述部１３２は仕様を記憶することができれば、不揮発性のメモリ等によって構成してもよく、また、スイッチ等によって構成してもよい。仕様記述部１３２に記述されているアナログブロック１３１の仕様は、外部からのアクセスによって読み出すことができるようになっている。例えば、図１では、主としてＣＰＵ９が各アナログブロックの特性を読み出すことができるようになっている。

図１１はアナログブロックが例えば図１のシンセサイザ３に相当するシンセサイザ１４１である場合を示す。シンセサイザ１４１に関する仕様は仕様記述部１４２に記述されている。例えば、仕様記述部１４２には、発振可能周波数、位相雑音、周波数切換時間、周波数安定度等が次のような形で書込まれている。

発振可能周波数 1895.15〜1917.95MHz
周波数切換時間 1msec
位相雑音 -27dB
周波数安定度 ±2.5ppm
なお、仕様記述部１４２の仕様は、予め定義された基準に従って記述される。例えば、周波数安定度については温度範囲等の基準が、また、位相雑音についてはその積分範囲等の基準が予め設定され、これらの基準にのっとって仕様が記述されている。

また、図１２にはアナログブロックが図１のアンプ１に相当するアンプ１５１である場合を示す。アンプ１５１に関する仕様は仕様記述部１５２において、例えば使用可能周波数、利得可変範囲、ＮＦ等が次のような形で書込まれている。

使用可能周波数 1.5〜2GHz
利得可変範囲 0〜40dB
ＮＦ 2.0dB
ライブラリ側は、デバイスドライバやＯＳ等の基本ソフトウェアを介してこれらの情報を読みとることが可能であり、必要な性能が得られるか否か等の判断材料として利用することが可能となる。例えばこれらの情報によって、ある特定のハードウェア上で、無線機全体として必要な特性が得られるかどうかの判断がライブラリ側からソフトウェア的に判断可能となる。

また、アナログ部はハードウェア的にシンセサイザ、アンプ、ミキサ等が分離しておらず、１チップ化されている場合があるが、このような場合にはＩＣの内部に、１チップ化されているいくつかの機能ブロックに関する上記の情報をまとめて記述する仕様記述部を設けるか、あるいは分散させて記述する複数の仕様記述部を設け、これらの仕様記述部をＣＰＵ側から読み取れるように構成しておけばよい。

たとえば図１３にはシンセサイザとアンプが１チッブ化されたＩＣの例を示している。アナログブロック１６１は、図１のアンプ１及びシンセサイザ３に相当するものであり、仕様記述部１６２にはアナログブロック１６１のアンプ部とシンセサイザ部の各仕様が記述されており、ＣＰＵ側からこれらの情報をそれぞれ別々に読み出すことが可能である。

次にこれらの情報の記述方法について述べる。例えば、あらかじめアナログブロックにＲＯＭなどのメモリを作りこんでおき、そのなかに情報を書き込んでおく方法がある。この場合には、ＲＯＭの情報を引き出すための専用のデータ端子とアドレス端子とを設け、ＣＰＵからアドレスを指定することによってデータ端子からアナログブロックの特性をディジタルデータの形で出力させることができる。

図１４は本発明の第４の実施の形態において採用されるアナログの機能ブロック（アナログブロック）を示す説明図である。本実施の形態は、図１０の第３実施の形態に対して仕様記述部の構成が異なる。

すなわち、本実施の形態では仕様記述部に仕様そのものを記述するのではなく、そのアナログブロックの識別番号を記述しておくのである。そしてその識別番号とそのアナログブロックの仕様に関してはライブラリの中に対照表をあらかじめ用意することによって、ＣＰＵはアナログブロックの特性に関する情報を得ることができる。

図１４において、アナログブロック１３１に確保された仕様記述部１３２は、アナログブロック１３１の識別番号が記述されている。ＣＰＵ９はアナログブロック１３１の仕様記述部１３２から識別番号を読み取り、その識別番号をもとに、ライブラリ１３に記述された識別番号と仕様との対照表を参照することによって、必要な情報をライブラリから得ることができる。

このように構成することによって、図１０に示した構成に比べて、情報を得るための手順は煩雑になるが、アナログブロックに記述しておく情報量を大幅に削減することができ、より好ましい方法であるといえる。仕様記述部に仕様を直接記述した場合、その情報量はたとえば仕様項目が５、各仕様の内容の記述に２０バイト必要であるものとすると、合計１００バイトとなるのに対し、識別番号だけであればたとえば４バイト程度と、２５分の１のサイズに抑えることが可能となる。識別番号として４バイトを記憶させる場合でも、３２ビット分（２の３２乗）の種類の識別が可能であるため十分であるといえる。

識別番号の付し方については図１５に示すように次のような方法が考えられる。すなわち、最初のブロックに機能１８１（たとえばシンセサイザ、ミキサ、アンプなど）、次のブロックに製造業社名１８２、そして最後に識別番号１８３とする。機能はたとえば４ビットのバイナリで下記のように表現する。

００００ミキサ
０００１受信用アンプ
００１０シンセサイザ
００１１送信用アンプ
０１００アッテネータ
…… ……
また、次の４ビットは製造者を表す。

００００製造者Ａ
０００１製造者Ｂ
００１０製造者Ｃ
００１１製造者Ｄ
０１００製造者Ｅ
…… ……
なお上記は一例であってたとえば機能を表現するビット数は必ずしも４ビットである必要はなく、また製造者をあらわす部分に関しても同様であり、必要に応じたビット数をあらかじめ勘案して決定すればよい。

また本実施の形態についてはアナログ部の場合をのべたが、専用機能を有し、その特性を外部からの設定によって変更することが可能であるディジタル部、たとえばタップ係数をパラメータとして与えるタイプのディジタルフィルタや、局部発振器の発振周波数をバラメータとして与えるディジタル直交復調器などのＩＣにも同様の仕様記述部を設けておくことは有効であることは言うまでもない。たとえばディジタルフィルタの場合は次のような仕様を記述しておくとよい。

最大タップ数２５６
タップ係数の精度１６ビット
最大処理速度５０Ｍサンプル／秒
ディジタル部は内部がディジタル回路によって構成されているため、ディジタル的にその仕様を外部へ出力する構成をなすことは上述のアナログブロックの場合に比して特に製造しやすいので本実施の形態の方法によりなじんだ方法であるともいえる。

本発明においては、発明の精神及び範囲から逸脱することなく、広い範囲において異なる実施態様を、本発明に基づいて構成することができることは明白である。本発明は、添付のクレームによって限定される以外には、それの特定の実施態様によって制約されない。

本発明の第１の実施の形態を説明するための図である。本発明のコンパイラの動作を示す図である。本発明のコンパイラの動作を示す図である。アナログ部の構成を示す図である。シンセサイザの構成を示す図である。シンセサイザ設定データを示す図である。本発明の他の実施の形態を示すフローチャートである。本発明の他の実施の形態を示すフローチャートである。本発明の他の実施の形態を説明するためのフローチャートである。本発明の第３の実施の形態において採用されるアナログの機能ブロック（アナログブロック）を示す説明図である。アナログブロックが例えば図１のシンセサイザ３に相当するシンセサイザ１４１である場合を示す説明図である。アナログブロックが図１のアンプ１に相当するアンプ１５１である場合を示す説明図である。シンセサイザとアンプが１チッブ化されたＩＣの例を示す説明図である。本発明の第４の実施の形態において採用されるアナログの機能ブロック（アナログブロック）を示す説明図である。識別番号の付し方を説明するための説明図ある。従来例を説明するための図である。

符号の説明

１・・・アンプ
２・・・ミキサ
３・・シンセサイザ
４・・・ＡＤ変換器
５・・・ＤＡ変換器
７・・・ＤＳＰ
９・・・ＣＰＵ
１０・・ハードウェア
１１・・ＯＳ
１２・・デバイスドライバ
１３・・ライブラリ
１４・・アプリケーションプログラム
１５・・ソフトウェア

Claims

無線信号を送受信する送受信手段と、受信した前記無線信号をディジタル信号に変換して出力するＡＤ変換手段と、送信するディジタル信号を前記無線信号に変換して出力するＤＡ変換手段と、前記ＡＤ変換手段の出力に対するディジタル信号処理及び前記ＤＡ変換手段の入力に対するディジタル信号処理を行うディジタル信号処理手段とを有するハードウェアによって複数の無線機能を実現する移動通信のための無線通信装置であって、
所定の無線機能を実現するための関数を含み前記ハードウェアに依存した第１のライブラリを記憶する記憶手段と、
アプリケーションプログラムのコンパイル時に前記ハードウェアに依存しない第２のライブラリがリンクされて生成された実行ファイルをダウンロードし、実行に際して前記第１のライブラリが含む前記関数を参照する前記実行ファイルを基本ソフトウェア上で実行させることにより、前記送受信手段と、前記ＡＤ変換手段と、前記ＤＡ変換手段と、前記ディジタル信号処理手段との少なくとも１つを制御して前記複数の無線機能を実現する制御手段と
を具備することを特徴とする無線通信装置。
無線信号を送受信する送受信手段と、受信した前記無線信号をディジタル信号に変換して出力するＡＤ変換手段と、送信するディジタル信号を前記無線信号に変換して出力するＤＡ変換手段と、前記ＡＤ変換手段の出力に対するディジタル信号処理及び前記ＤＡ変換手段の入力に対するディジタル信号処理を行うディジタル信号処理手段と、記憶手段とを有するハードウェアによって複数の無線機能を実現する移動通信のための無線通信装置を、制御手段がソフトウェアによって制御する無線通信方法であって、
アプリケーションプログラムのコンパイル時に前記ハードウェアに依存しない第２のライブラリがリンクされて生成された実行ファイルを、前記制御手段がダウンロードし、
前記記憶手段には所定の無線機能を実現するための関数を含み前記ハードウェアに依存した第１のライブラリが記憶されており、
前記制御手段が、実行に際して前記第１のライブラリが含む前記関数を参照する前記実行ファイルを基本ソフトウェア上で実行させることにより、前記送受信手段と、前記ＡＤ変換手段と、前記ＤＡ変換手段と、前記ディジタル信号処理手段との少なくとも１つを制御して前記複数の無線機能を実現する
ことを特徴とする無線通信方法。