無線基地局装置評価システム、無線基地局装置及びそれに用いる無線基地局装置評価方法
【課題】 人為的確認ミスを生ずることなく、試験工程における工数を削減可能とし、より確実な試験実施を効率的に行うことが可能な無線基地局装置評価システムを提供する。
【解決手段】 無線基地局装置１においては、実装されるＡＰＩ部１２の試験用の試験ＡＰ部１１と、試験ＡＰ部１１とのインタフェースを持つ試験実施端末２とを設け、ＡＰＩ部１２の実行結果を試験ＡＰ部１１にて吸い上げ、かつ目視による確認手順を試験ＡＰ部１１にて判断させている。試験ＡＰ部１１はその判断結果を、試験実施端末２を通してデータベース３に登録する。
【解決手段】 無線基地局装置１においては、実装されるＡＰＩ部１２の試験用の試験ＡＰ部１１と、試験ＡＰ部１１とのインタフェースを持つ試験実施端末２とを設け、ＡＰＩ部１２の実行結果を試験ＡＰ部１１にて吸い上げ、かつ目視による確認手順を試験ＡＰ部１１にて判断させている。試験ＡＰ部１１はその判断結果を、試験実施端末２を通してデータベース３に登録する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線基地局装置評価システム、無線基地局装置及びそれに用いる無線基地局装置評価方法に関し、特にＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）システムにおける無線基地局装置の試験工程を実行する無線基地局装置評価方法に関する。
【背景技術】
【０００２】
Ｗ−ＣＤＭＡ方式による移動通信システムにおいて、特に無線基地局装置のファームウェアには、各機能を実現するためのＣＰＵ（中央処理装置）を搭載したカード（以下、スレーブカードとする）が存在する。また、ファームウェアには、スレーブカードが個別に保有する情報を監視・制御してアプリケーションプログラム［以下、ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）とする］とのインタフェースを持つ監視カード（以下、マスタカードとする）が存在する。
【０００３】
Ｗ−ＣＤＭＡシステムにおいて、無線基地局装置はＡＰから指示されるアプリケーションインタフェース［以下、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）とする］の発行によって動作している。ここで、ＡＰＩとはあるプラットフォーム［ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ミドルウェア、ファームウェア等］向けのソフトウェアを開発する際に使用できる命令や関数の集合を示している。
【０００４】
ＡＰから発行されるＡＰＩは複数存在し、かつＡＰＩ毎にパラメータが複数あり、パラメータも固定で発行されない。よって、ＡＰＩではＡＰから指示される発行順序、パラメータ内容等、いかなる条件下、状況下の場合でも仕様に即した結果をＡＰに通知することが求められている。
【０００５】
これらＡＰＩの試験を実施するにあたり、各ＡＰＩ発行順序の組合せ、及びＡＰＩ毎のパラメータを考慮した実行パターンの試験を実施する必要性がある。また、これらの試験の組合せを実施した場合、膨大な数の試験を実施しなければならず、試験の工数は計り知れないものとなる。
【０００６】
従来、これらの組合せ試験はすべてを網羅せず、各ＡＰＩを単発で実行するメンテナンスツールを用いて実行し、ＡＰＩの正常性を確認している。メンテナンスツールでは、各ＡＰＩのパラメータが固定化され、画面上に出力される結果を目視で確認することで、ＡＰＩの正常性が確認されている。
【０００７】
尚、無線基地局装置の送受信機の試験方法としては、動作確認試験や保守点検用のツールとして使用される高速ハイエンドマシンのパーソナルコンピュータ（以下、パソコンとする）を用いる方法も提案されている（例えば、特許文献１参照）。
【０００８】
上記の試験方法では、送受信機が、デバッグ時に接続された治具パソコンから送信されるレジスタ設定マクロのコマンド処理によって、送受信機に組込まれたＣＰＵの使用率が上昇する場合に、ＣＰＵの使用率を監視して予め設定された閾値を超えた時に、電力制御を含む通常処理のためにＣＰＵに定期的に出力されている割込み信号をマスクすることで、ＣＰＵにＨＡＬＴ状態を生じさせないようにしている。
【０００９】
【特許文献１】特開２００３−３４８０２８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述した従来の無線基地局装置評価方法では、各ＡＰＩを単発で実行するメンテナンスツールを用いて実行しているので、ＡＰＩ毎のこれらの組合せ試験工程における試験実施数が莫大な量となり、リソース（人員）による試験結果の確認工数は図り知れないものとなる。また、試験結果の確認は目視によって行っているので、その確認において人為的ミスが発生する場合が考えられ、フィードバック作業に試験実施と同等の工数が発生することとなる。
【００１１】
併せて、試験結果を登録する際には、これらの試験結果を記入する必要性が発生し、一項目を実施するにあたり、目視による試験結果の確認、試験結果の記入等の作業が必ず発生する。
【００１２】
また、上記の特許文献１に記載の技術では、接続された治具パソコンから送信されるレジスタ設定マクロのコマンド処理によってデバッグを行っているため、ＡＰＩ毎に組合せ試験工程を実行しようとすると、試験実施数が莫大な量となり、リソースによる試験結果の確認工数が図り知れないものとなるため、上記の問題を解決することはできない。
【００１３】
そこで、本発明の目的は上記の問題点を解消し、人為的確認ミスを生ずることなく、試験工程における工数を削減することができ、より確実な試験実施を効率的に行うことができる無線基地局装置評価システム、無線基地局装置及びそれに用いる無線基地局装置評価方法を提供することにある。
【課題を解決するための手段】
【００１４】
本発明による無線基地局装置評価システムは、各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価システムであって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装している。
【００１５】
本発明による無線基地局装置は、各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装している。
【００１６】
本発明による無線基地局装置評価方法は、各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価方法であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装している。
【００１７】
すなわち、本発明の無線基地局装置評価システムは、無線基地局装置において実装されるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）試験用の試験ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）と、試験ＡＰとのインタフェースを持つ試験実施端末とを設け、ＡＰＩの実行結果を試験ＡＰにて吸い上げ、かつ目視による確認手順を試験ＡＰにて判断させている。
【００１８】
従来、ＡＰＩ毎の結合試験工程では、メンテナンスツールを用いて各ＡＰＩの動作を目視で確認しているが、本発明の無線基地局装置自動評価システムでは、メンテナンスツールを使用せずに、試験ＡＰにて各ＡＰＩの動作を確認しているので、人為的確認ミスを生ずることなく、試験工程における工数を削減することが可能となり、より確実な試験実施を効率的に行うことが可能となる。併せて、本発明の無線基地局装置評価システムでは、確認結果収集についても、試験結果をデータベースに自動登録させ、閲覧させることが可能となる。
【００１９】
上記のように、ＡＰＩ毎の結合試験工程の試験結果は設計工程から予め結果が判定できるものであり、予め確認対象とすべき内容を予測することができるのであれば、ソフトウェアとして組込んでおくことが可能である。つまり、本発明の無線基地局装置評価システムでは、ＡＰＩの動作確認用試験ＡＰとして、ＡＰＩに試験ＡＰを実装し、試験実施させることによって、これらを自動で確認させることが可能となる。併せて、試験ＡＰにおいて試験結果をデータベースに出力することによって、試験結果の自動登録並びに試験進捗状況をデータベースから取出して確認することが可能となる。
【発明の効果】
【００２０】
本発明は、以下に述べるような構成及び動作とすることで、人為的確認ミスを生ずることなく、試験工程における工数を削減することができ、より確実な試験実施を効率的に行うことができるという効果が得られる。
【発明を実施するための最良の形態】
【００２１】
次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例による無線基地局装置評価システムの構成を示すブロック図である。図１において、本発明の一実施例による無線基地局装置評価システムは無線基地局装置１と、試験実施端末（トレース出力）２と、データベース３とから構成されている。
【００２２】
無線基地局装置１はＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）方式による移動通信システムを構成する要素であり、試験ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）部１１と、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）部１２と、ファームウェア部１３とから構成されている。
【００２３】
ファームウェア部１３はＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）部１３１と、各機能を実現するためのＣＰＵ１３３ａ−１〜１３３ａ−Ｎ（ＣＰＵ１３３ａ−２〜１３３ａ−Ｎは図示せず）を搭載したスレーブカード１３３−１〜１３３−Ｎと、これらのスレーブカード１３３−１〜１３３−Ｎが個別に保有する情報を監視・制御し、ＡＰ部１３１とのインタフェースを持つマスタカード１３２とから構成されている。
【００２４】
無線基地局１において、試験ＡＰ部１１はＡＰＩ部１２の実行結果を判断し、ＡＰＩ部１２は動作が規定されている。また、ファームウェア部１３は規定された動作を実現するＡＰＩ部１２との関連性を有している。
【００２５】
試験実施端末２はＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）インタフェースによって試験ＡＰ部１１に接続されており、試験ＡＰ部１１に対して試験を実施するイベントを出力し、試験ＡＰ部１１の試験結果を受取る。試験実施端末２は試験ＡＰ部１１から受取った試験結果をデータベース３に登録する。
【００２６】
図２は本発明の一実施例による発行ＡＰＩとパラメータの有効／無効の一覧を示す図であり、図３は本発明の一実施例におけるパラメータの範囲を示す図であり、図４は本発明の一実施例におけるＡＰＩ発行順序試験パターンの一例を示す図である。これら図１〜図４を参照して本発明の一実施例による無線基地局装置評価システムの動作について説明する。
【００２７】
試験ＡＰ部１１ではＡＰＩ部１２を実行するにあたり、図２に示すようなＡＰＩを発行可能とし、さらにＡＰＩ毎に発行可能なパラメータが規定されている。ＡＰＩ部１２は単独発行のみを意識しており、連続的に発行されることを基本的に意識していない。これらを意識するのは試験ＡＰ部１１側であり、図２に示すＡＰＩを項番「１」〜「１０」の順序で発行するか否かは試験ＡＰ部１１にて意識する。これらは正常終了の条件であり、原則、発行不可であることはない。また、一部限られたＡＰＩは、あるＡＰＩが発行済みであることが（正常終了）条件の場合もある。
【００２８】
図２に示すようなＡＰＩはある条件下による設定がなされており、ＡＰＩ側では、この条件下のもと、ＡＰＩが発行されることを前提としている。仮に、本条件下以外で発行されたとしても、発行自体は実施可能であり、結果としてＮＧの扱いとなる。
【００２９】
図２において、項番「１」はＡＰＩ名が「ｃＡｂｃＡＰＩ」であり、パラメータ「Ａ」，「Ｂ」が有効（○）となっており、パラメータ「Ｃ」，「Ｄ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「２」はＡＰＩ名が「ｃＢｃｄＡＰＩ」であり、パラメータ「Ｄ」，「Ｈ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｉ」が無効（×）となっている。
【００３０】
項番「３」はＡＰＩ名が「ｃＣｄｅＡＰＩ」であり、パラメータ「Ｄ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「４」はＡＰＩ名が「ｃＤｅｆＡＰＩ」であり、パラメータ「Ｂ」，「Ｆ」が有効（○）となっており、パラメータ「Ａ」，「Ｃ」，「Ｄ」，「Ｅ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。
【００３１】
項番「５」はＡＰＩ名が「ｃＥｆｇＡＰＩ」であり、パラメータ「Ｃ」，「Ｉ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｄ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」が無効（×）となっている。項番「６」はＡＰＩ名が「ｃＦｇｒＡＰＩ」であり、パラメータ「Ａ」，「Ｄ」，「Ｈ」が有効（○）となっており、パラメータ「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｉ」が無効（×）となっている。
【００３２】
項番「７」はＡＰＩ名が「ｃＧｈｉＡＰＩ」であり、パラメータ「Ｆ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」，「Ｅ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「８」はＡＰＩ名が「ｃＨｉｋＡＰＩ」であり、パラメータ「Ｄ」，「Ｇ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｈ」，「Ｉ」が無効（×）となっている。
【００３３】
項番「９」はＡＰＩ名が「ｃＬｍｋＡＰＩ」であり、パラメータ「Ｅ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」，「Ｆ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「１０」はＡＰＩ名が「ｃＭｎｌＡＰＩ」であり、パラメータ「Ｇ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」，「Ｅ」，「Ｆ」，「Ｈ」，「Ｉ」が無効（×）となっている。
【００３４】
図３では図２に示すようなＡＰＩのパラメータ範囲について述べている。試験ＡＰ部１１から指示されるＡＰＩ部１２ではパラメータがそれぞれ存在し、パラメータ範囲に関しても規定されることとなる。試験実施する場合には、ＡＰＩ毎にパラメータを振りわける試験が必要であり、ＡＰＩ毎にこれらのパラメータを振り分け、実行結果を判定する必要がある。
【００３５】
図３において、パラメータ名「Ａ」は値の範囲が「０〜３」であり、パラメータ名「Ｂ」は値の範囲が「０〜２５５」であり、パラメータ名「Ｃ」は値の範囲が「０，１」であり、パラメータ名「Ｄ」は値の範囲が「０〜６５５３５」であり、パラメータ名「Ｅ」は値の範囲が「０〜１０」であり、パラメータ名「Ｆ」は値の範囲が「１〜３」であり、パラメータ名「Ｇ」は値の範囲が「１〜５」であり、パラメータ名「Ｈ」は値の範囲が「０〜９」であり、パラメータ名「Ｉ」は値の範囲が「０，１」である。
【００３６】
ここで、上記の図２及び図３に記載している内容に関する具体例としては、項番「１」、ＡＰＩ名「ｃＡｂｃＡＰＩ」では、有効パラメータが「Ａ」，「Ｂ」とあり、それぞれのパラメータのとりうる範囲は、パラメータ「Ａ」が「０〜３」であり、パラメータ「Ｂ」が「０〜２５５」である。これらの組合せでＡＰＩ名「ｃＡｂｃＡＰＩ」の発行試験を実施した場合の項目数は、「４×２５６＝１０２４」項目となる。
【００３７】
図４では、図２に示すようなＡＰＩに関して、ＡＰＩの発行順序を規定した場合の試験パターンを記載している。図２に示すような条件下に当てはめた場合、試験パターン項番「１」のみが正常終了する試験パターンであり、試験パターン項番「２」〜「１１」はＮＧとなる試験パターンである。
【００３８】
試験パラメータ項番「１」のＡＰＩ発行順序（数字は項番）は「１→２→３→４→５→６→７→８→９→１０」であり、試験パラメータ項番「２」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→１」であり、試験パラメータ項番「３」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→２」であり、試験パラメータ項番「４」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→３」であり、試験パラメータ項番「５」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→４」である。
【００３９】
試験パラメータ項番「６」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→５」であり、試験パラメータ項番「７」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→６」であり、試験パラメータ項番「８」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→７」であり、試験パラメータ項番「９」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→８」であり、試験パラメータ項番「１０」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→９」であり、試験パラメータ項番「１１」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→１→１０」である。
【００４０】
図５は本発明の一実施例による試験ＡＰ部１１の動作を示すシーケンスチャートである。これら図１〜図５を参照して本発明の一実施例による試験ＡＰ部１１の動作について説明する。本実施例による試験パターンは、試験実施端末（トレース出力）２から試験ＡＰ部１１に指示され、試験ＡＰ部１１にて上述したような試験パターンが実行されることとなる。図５においては、試験実施端末２から試験ＡＰ部１１〜ＡＰＩ部１２に指示された電文の流れを試験ＡＰ部１１の動作の流れとして記載している。
【００４１】
試験ＡＰ部１１は試験実施端末２から試験コマンド（試験パターンｎ）を受信すると（図５のａ１参照）、図４に示すような試験パターンのうちのいずれかをを実行する（図５のａ２参照）。例えば、試験ＡＰ部１１が試験パターン項番「１」として認識した場合において、試験ＡＰ部１１は図２に示すようなＡＰＩを項番「１」から順番に発行する（図５のａ３参照）。
【００４２】
試験ＡＰ部１１はＡＰＩを発行し、その発行結果をＡＰＩ部１２から受取ると（図５のａ４参照）、その発行結果を判断する（図５のａ５参照）。ＡＰＩ部１２からの発行結果が試験ＡＰ部１１で想定した内容でなければ、試験ＡＰ部１１は異常終了を試験実施端末２に出力する（図５のａ６参照）。
【００４３】
また、ＡＰＩ部１２からの発行結果が試験ＡＰ部１１で想定した内容であれば、試験ＡＰ部１１は試験実施端末２にＡＰＩ実行結果を出力し（図５のａ７参照）、図２にしめすような項番「２」のＡＰＩ発行を実行する。以降、試験ＡＰ部１１は試験パターン項番「１」におけるＡＰＩを最後まで発行し、試験ＡＰ部１１での判断結果が一致であれば、試験パターン項番「１」の終了報告を試験実施端末２に出力し（図５のａ８，ａ９参照）、処理を終了する。
【００４４】
併せて、試験ＡＰ部１１が発行するＡＰＩにおけるパラメータは、図３に示すようなパラメータで発行可能であるため、発行する際にはパラメータをすべて振り分けることも可能とする。
【００４５】
試験実施端末２においては、試験ＡＰ部１１から受信した電文である、「試験パターンｎ終了報告」を受信することによって、データベース３に試験ＡＰ部１１からの本試験結果を登録する。「試験パターンｎ終了報告」では、電文内容として、試験パターン項番、試験結果、ＮＧ理由をデータとして保持することによって、項番毎に試験実施結果が判断可能となる。
【００４６】
上記のように、ＡＰＩ毎の組合せ試験工程の試験結果は、設計工程から予め結果が判定できるものであり、予め確認対象とすべき内容を予測することができるのであれば、ソフトウェアとして組込んでおくことができる。つまり、本実施例では、ＡＰＩの動作確認用試験ＡＰとして、ＡＰＩに試験ＡＰを実装し、試験実施させることによって、これらを自動で確認させることができる。併せて、本実施例では、試験ＡＰにおいて試験結果をデータベースに出力することによって、試験結果の自動登録並びに試験進捗状況をデータベースから取出して確認することができる。
【００４７】
このように、本実施例では、人為的確認ミスを生ずることなく、試験工程における工数を削減することができ、より確実な試験実施を効率的に行うことができる。
【図面の簡単な説明】
【００４８】
【図１】本発明の一実施例による無線基地局装置評価システムの構成を示すブロック図である。
【図２】本発明の一実施例による発行ＡＰＩとパラメータの有効／無効の一覧を示す図である。
【図３】本発明の一実施例におけるパラメータの範囲を示す図である。
【図４】本発明の一実施例におけるＡＰＩ発行順序試験パターンの一例を示す図である。
【図５】本発明の一実施例による試験ＡＰ部の動作を示すシーケンスチャートである。
【符号の説明】
【００４９】
１ 無線基地局装置
２ 試験実施端末（トレース出力）
３ データベース
１１ 試験ＡＰ部
１２ ＡＰＩ部
１３ ファームウェア部
１３１ ＡＰ部
１３２ マスタカード
１３３−１〜１３３−Ｎ スレーブカード
１３３ａ−１ ＣＰＵ
【技術分野】
【０００１】
本発明は無線基地局装置評価システム、無線基地局装置及びそれに用いる無線基地局装置評価方法に関し、特にＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）システムにおける無線基地局装置の試験工程を実行する無線基地局装置評価方法に関する。
【背景技術】
【０００２】
Ｗ−ＣＤＭＡ方式による移動通信システムにおいて、特に無線基地局装置のファームウェアには、各機能を実現するためのＣＰＵ（中央処理装置）を搭載したカード（以下、スレーブカードとする）が存在する。また、ファームウェアには、スレーブカードが個別に保有する情報を監視・制御してアプリケーションプログラム［以下、ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）とする］とのインタフェースを持つ監視カード（以下、マスタカードとする）が存在する。
【０００３】
Ｗ−ＣＤＭＡシステムにおいて、無線基地局装置はＡＰから指示されるアプリケーションインタフェース［以下、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）とする］の発行によって動作している。ここで、ＡＰＩとはあるプラットフォーム［ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ミドルウェア、ファームウェア等］向けのソフトウェアを開発する際に使用できる命令や関数の集合を示している。
【０００４】
ＡＰから発行されるＡＰＩは複数存在し、かつＡＰＩ毎にパラメータが複数あり、パラメータも固定で発行されない。よって、ＡＰＩではＡＰから指示される発行順序、パラメータ内容等、いかなる条件下、状況下の場合でも仕様に即した結果をＡＰに通知することが求められている。
【０００５】
これらＡＰＩの試験を実施するにあたり、各ＡＰＩ発行順序の組合せ、及びＡＰＩ毎のパラメータを考慮した実行パターンの試験を実施する必要性がある。また、これらの試験の組合せを実施した場合、膨大な数の試験を実施しなければならず、試験の工数は計り知れないものとなる。
【０００６】
従来、これらの組合せ試験はすべてを網羅せず、各ＡＰＩを単発で実行するメンテナンスツールを用いて実行し、ＡＰＩの正常性を確認している。メンテナンスツールでは、各ＡＰＩのパラメータが固定化され、画面上に出力される結果を目視で確認することで、ＡＰＩの正常性が確認されている。
【０００７】
尚、無線基地局装置の送受信機の試験方法としては、動作確認試験や保守点検用のツールとして使用される高速ハイエンドマシンのパーソナルコンピュータ（以下、パソコンとする）を用いる方法も提案されている（例えば、特許文献１参照）。
【０００８】
上記の試験方法では、送受信機が、デバッグ時に接続された治具パソコンから送信されるレジスタ設定マクロのコマンド処理によって、送受信機に組込まれたＣＰＵの使用率が上昇する場合に、ＣＰＵの使用率を監視して予め設定された閾値を超えた時に、電力制御を含む通常処理のためにＣＰＵに定期的に出力されている割込み信号をマスクすることで、ＣＰＵにＨＡＬＴ状態を生じさせないようにしている。
【０００９】
【特許文献１】特開２００３−３４８０２８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述した従来の無線基地局装置評価方法では、各ＡＰＩを単発で実行するメンテナンスツールを用いて実行しているので、ＡＰＩ毎のこれらの組合せ試験工程における試験実施数が莫大な量となり、リソース（人員）による試験結果の確認工数は図り知れないものとなる。また、試験結果の確認は目視によって行っているので、その確認において人為的ミスが発生する場合が考えられ、フィードバック作業に試験実施と同等の工数が発生することとなる。
【００１１】
併せて、試験結果を登録する際には、これらの試験結果を記入する必要性が発生し、一項目を実施するにあたり、目視による試験結果の確認、試験結果の記入等の作業が必ず発生する。
【００１２】
また、上記の特許文献１に記載の技術では、接続された治具パソコンから送信されるレジスタ設定マクロのコマンド処理によってデバッグを行っているため、ＡＰＩ毎に組合せ試験工程を実行しようとすると、試験実施数が莫大な量となり、リソースによる試験結果の確認工数が図り知れないものとなるため、上記の問題を解決することはできない。
【００１３】
そこで、本発明の目的は上記の問題点を解消し、人為的確認ミスを生ずることなく、試験工程における工数を削減することができ、より確実な試験実施を効率的に行うことができる無線基地局装置評価システム、無線基地局装置及びそれに用いる無線基地局装置評価方法を提供することにある。
【課題を解決するための手段】
【００１４】
本発明による無線基地局装置評価システムは、各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価システムであって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装している。
【００１５】
本発明による無線基地局装置は、各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装している。
【００１６】
本発明による無線基地局装置評価方法は、各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価方法であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装している。
【００１７】
すなわち、本発明の無線基地局装置評価システムは、無線基地局装置において実装されるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）試験用の試験ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）と、試験ＡＰとのインタフェースを持つ試験実施端末とを設け、ＡＰＩの実行結果を試験ＡＰにて吸い上げ、かつ目視による確認手順を試験ＡＰにて判断させている。
【００１８】
従来、ＡＰＩ毎の結合試験工程では、メンテナンスツールを用いて各ＡＰＩの動作を目視で確認しているが、本発明の無線基地局装置自動評価システムでは、メンテナンスツールを使用せずに、試験ＡＰにて各ＡＰＩの動作を確認しているので、人為的確認ミスを生ずることなく、試験工程における工数を削減することが可能となり、より確実な試験実施を効率的に行うことが可能となる。併せて、本発明の無線基地局装置評価システムでは、確認結果収集についても、試験結果をデータベースに自動登録させ、閲覧させることが可能となる。
【００１９】
上記のように、ＡＰＩ毎の結合試験工程の試験結果は設計工程から予め結果が判定できるものであり、予め確認対象とすべき内容を予測することができるのであれば、ソフトウェアとして組込んでおくことが可能である。つまり、本発明の無線基地局装置評価システムでは、ＡＰＩの動作確認用試験ＡＰとして、ＡＰＩに試験ＡＰを実装し、試験実施させることによって、これらを自動で確認させることが可能となる。併せて、試験ＡＰにおいて試験結果をデータベースに出力することによって、試験結果の自動登録並びに試験進捗状況をデータベースから取出して確認することが可能となる。
【発明の効果】
【００２０】
本発明は、以下に述べるような構成及び動作とすることで、人為的確認ミスを生ずることなく、試験工程における工数を削減することができ、より確実な試験実施を効率的に行うことができるという効果が得られる。
【発明を実施するための最良の形態】
【００２１】
次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例による無線基地局装置評価システムの構成を示すブロック図である。図１において、本発明の一実施例による無線基地局装置評価システムは無線基地局装置１と、試験実施端末（トレース出力）２と、データベース３とから構成されている。
【００２２】
無線基地局装置１はＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）方式による移動通信システムを構成する要素であり、試験ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）部１１と、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）部１２と、ファームウェア部１３とから構成されている。
【００２３】
ファームウェア部１３はＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）部１３１と、各機能を実現するためのＣＰＵ１３３ａ−１〜１３３ａ−Ｎ（ＣＰＵ１３３ａ−２〜１３３ａ−Ｎは図示せず）を搭載したスレーブカード１３３−１〜１３３−Ｎと、これらのスレーブカード１３３−１〜１３３−Ｎが個別に保有する情報を監視・制御し、ＡＰ部１３１とのインタフェースを持つマスタカード１３２とから構成されている。
【００２４】
無線基地局１において、試験ＡＰ部１１はＡＰＩ部１２の実行結果を判断し、ＡＰＩ部１２は動作が規定されている。また、ファームウェア部１３は規定された動作を実現するＡＰＩ部１２との関連性を有している。
【００２５】
試験実施端末２はＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）インタフェースによって試験ＡＰ部１１に接続されており、試験ＡＰ部１１に対して試験を実施するイベントを出力し、試験ＡＰ部１１の試験結果を受取る。試験実施端末２は試験ＡＰ部１１から受取った試験結果をデータベース３に登録する。
【００２６】
図２は本発明の一実施例による発行ＡＰＩとパラメータの有効／無効の一覧を示す図であり、図３は本発明の一実施例におけるパラメータの範囲を示す図であり、図４は本発明の一実施例におけるＡＰＩ発行順序試験パターンの一例を示す図である。これら図１〜図４を参照して本発明の一実施例による無線基地局装置評価システムの動作について説明する。
【００２７】
試験ＡＰ部１１ではＡＰＩ部１２を実行するにあたり、図２に示すようなＡＰＩを発行可能とし、さらにＡＰＩ毎に発行可能なパラメータが規定されている。ＡＰＩ部１２は単独発行のみを意識しており、連続的に発行されることを基本的に意識していない。これらを意識するのは試験ＡＰ部１１側であり、図２に示すＡＰＩを項番「１」〜「１０」の順序で発行するか否かは試験ＡＰ部１１にて意識する。これらは正常終了の条件であり、原則、発行不可であることはない。また、一部限られたＡＰＩは、あるＡＰＩが発行済みであることが（正常終了）条件の場合もある。
【００２８】
図２に示すようなＡＰＩはある条件下による設定がなされており、ＡＰＩ側では、この条件下のもと、ＡＰＩが発行されることを前提としている。仮に、本条件下以外で発行されたとしても、発行自体は実施可能であり、結果としてＮＧの扱いとなる。
【００２９】
図２において、項番「１」はＡＰＩ名が「ｃＡｂｃＡＰＩ」であり、パラメータ「Ａ」，「Ｂ」が有効（○）となっており、パラメータ「Ｃ」，「Ｄ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「２」はＡＰＩ名が「ｃＢｃｄＡＰＩ」であり、パラメータ「Ｄ」，「Ｈ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｉ」が無効（×）となっている。
【００３０】
項番「３」はＡＰＩ名が「ｃＣｄｅＡＰＩ」であり、パラメータ「Ｄ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「４」はＡＰＩ名が「ｃＤｅｆＡＰＩ」であり、パラメータ「Ｂ」，「Ｆ」が有効（○）となっており、パラメータ「Ａ」，「Ｃ」，「Ｄ」，「Ｅ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。
【００３１】
項番「５」はＡＰＩ名が「ｃＥｆｇＡＰＩ」であり、パラメータ「Ｃ」，「Ｉ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｄ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｈ」が無効（×）となっている。項番「６」はＡＰＩ名が「ｃＦｇｒＡＰＩ」であり、パラメータ「Ａ」，「Ｄ」，「Ｈ」が有効（○）となっており、パラメータ「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｇ」，「Ｉ」が無効（×）となっている。
【００３２】
項番「７」はＡＰＩ名が「ｃＧｈｉＡＰＩ」であり、パラメータ「Ｆ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」，「Ｅ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「８」はＡＰＩ名が「ｃＨｉｋＡＰＩ」であり、パラメータ「Ｄ」，「Ｇ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｅ」，「Ｆ」，「Ｈ」，「Ｉ」が無効（×）となっている。
【００３３】
項番「９」はＡＰＩ名が「ｃＬｍｋＡＰＩ」であり、パラメータ「Ｅ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」，「Ｆ」，「Ｇ」，「Ｈ」，「Ｉ」が無効（×）となっている。項番「１０」はＡＰＩ名が「ｃＭｎｌＡＰＩ」であり、パラメータ「Ｇ」が有効（○）となっており、パラメータ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」，「Ｅ」，「Ｆ」，「Ｈ」，「Ｉ」が無効（×）となっている。
【００３４】
図３では図２に示すようなＡＰＩのパラメータ範囲について述べている。試験ＡＰ部１１から指示されるＡＰＩ部１２ではパラメータがそれぞれ存在し、パラメータ範囲に関しても規定されることとなる。試験実施する場合には、ＡＰＩ毎にパラメータを振りわける試験が必要であり、ＡＰＩ毎にこれらのパラメータを振り分け、実行結果を判定する必要がある。
【００３５】
図３において、パラメータ名「Ａ」は値の範囲が「０〜３」であり、パラメータ名「Ｂ」は値の範囲が「０〜２５５」であり、パラメータ名「Ｃ」は値の範囲が「０，１」であり、パラメータ名「Ｄ」は値の範囲が「０〜６５５３５」であり、パラメータ名「Ｅ」は値の範囲が「０〜１０」であり、パラメータ名「Ｆ」は値の範囲が「１〜３」であり、パラメータ名「Ｇ」は値の範囲が「１〜５」であり、パラメータ名「Ｈ」は値の範囲が「０〜９」であり、パラメータ名「Ｉ」は値の範囲が「０，１」である。
【００３６】
ここで、上記の図２及び図３に記載している内容に関する具体例としては、項番「１」、ＡＰＩ名「ｃＡｂｃＡＰＩ」では、有効パラメータが「Ａ」，「Ｂ」とあり、それぞれのパラメータのとりうる範囲は、パラメータ「Ａ」が「０〜３」であり、パラメータ「Ｂ」が「０〜２５５」である。これらの組合せでＡＰＩ名「ｃＡｂｃＡＰＩ」の発行試験を実施した場合の項目数は、「４×２５６＝１０２４」項目となる。
【００３７】
図４では、図２に示すようなＡＰＩに関して、ＡＰＩの発行順序を規定した場合の試験パターンを記載している。図２に示すような条件下に当てはめた場合、試験パターン項番「１」のみが正常終了する試験パターンであり、試験パターン項番「２」〜「１１」はＮＧとなる試験パターンである。
【００３８】
試験パラメータ項番「１」のＡＰＩ発行順序（数字は項番）は「１→２→３→４→５→６→７→８→９→１０」であり、試験パラメータ項番「２」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→１」であり、試験パラメータ項番「３」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→２」であり、試験パラメータ項番「４」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→３」であり、試験パラメータ項番「５」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→４」である。
【００３９】
試験パラメータ項番「６」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→５」であり、試験パラメータ項番「７」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→６」であり、試験パラメータ項番「８」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→７」であり、試験パラメータ項番「９」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→８」であり、試験パラメータ項番「１０」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→９→９」であり、試験パラメータ項番「１１」のＡＰＩ発行順序は「１→２→３→４→５→６→７→８→１→１０」である。
【００４０】
図５は本発明の一実施例による試験ＡＰ部１１の動作を示すシーケンスチャートである。これら図１〜図５を参照して本発明の一実施例による試験ＡＰ部１１の動作について説明する。本実施例による試験パターンは、試験実施端末（トレース出力）２から試験ＡＰ部１１に指示され、試験ＡＰ部１１にて上述したような試験パターンが実行されることとなる。図５においては、試験実施端末２から試験ＡＰ部１１〜ＡＰＩ部１２に指示された電文の流れを試験ＡＰ部１１の動作の流れとして記載している。
【００４１】
試験ＡＰ部１１は試験実施端末２から試験コマンド（試験パターンｎ）を受信すると（図５のａ１参照）、図４に示すような試験パターンのうちのいずれかをを実行する（図５のａ２参照）。例えば、試験ＡＰ部１１が試験パターン項番「１」として認識した場合において、試験ＡＰ部１１は図２に示すようなＡＰＩを項番「１」から順番に発行する（図５のａ３参照）。
【００４２】
試験ＡＰ部１１はＡＰＩを発行し、その発行結果をＡＰＩ部１２から受取ると（図５のａ４参照）、その発行結果を判断する（図５のａ５参照）。ＡＰＩ部１２からの発行結果が試験ＡＰ部１１で想定した内容でなければ、試験ＡＰ部１１は異常終了を試験実施端末２に出力する（図５のａ６参照）。
【００４３】
また、ＡＰＩ部１２からの発行結果が試験ＡＰ部１１で想定した内容であれば、試験ＡＰ部１１は試験実施端末２にＡＰＩ実行結果を出力し（図５のａ７参照）、図２にしめすような項番「２」のＡＰＩ発行を実行する。以降、試験ＡＰ部１１は試験パターン項番「１」におけるＡＰＩを最後まで発行し、試験ＡＰ部１１での判断結果が一致であれば、試験パターン項番「１」の終了報告を試験実施端末２に出力し（図５のａ８，ａ９参照）、処理を終了する。
【００４４】
併せて、試験ＡＰ部１１が発行するＡＰＩにおけるパラメータは、図３に示すようなパラメータで発行可能であるため、発行する際にはパラメータをすべて振り分けることも可能とする。
【００４５】
試験実施端末２においては、試験ＡＰ部１１から受信した電文である、「試験パターンｎ終了報告」を受信することによって、データベース３に試験ＡＰ部１１からの本試験結果を登録する。「試験パターンｎ終了報告」では、電文内容として、試験パターン項番、試験結果、ＮＧ理由をデータとして保持することによって、項番毎に試験実施結果が判断可能となる。
【００４６】
上記のように、ＡＰＩ毎の組合せ試験工程の試験結果は、設計工程から予め結果が判定できるものであり、予め確認対象とすべき内容を予測することができるのであれば、ソフトウェアとして組込んでおくことができる。つまり、本実施例では、ＡＰＩの動作確認用試験ＡＰとして、ＡＰＩに試験ＡＰを実装し、試験実施させることによって、これらを自動で確認させることができる。併せて、本実施例では、試験ＡＰにおいて試験結果をデータベースに出力することによって、試験結果の自動登録並びに試験進捗状況をデータベースから取出して確認することができる。
【００４７】
このように、本実施例では、人為的確認ミスを生ずることなく、試験工程における工数を削減することができ、より確実な試験実施を効率的に行うことができる。
【図面の簡単な説明】
【００４８】
【図１】本発明の一実施例による無線基地局装置評価システムの構成を示すブロック図である。
【図２】本発明の一実施例による発行ＡＰＩとパラメータの有効／無効の一覧を示す図である。
【図３】本発明の一実施例におけるパラメータの範囲を示す図である。
【図４】本発明の一実施例におけるＡＰＩ発行順序試験パターンの一例を示す図である。
【図５】本発明の一実施例による試験ＡＰ部の動作を示すシーケンスチャートである。
【符号の説明】
【００４９】
１ 無線基地局装置
２ 試験実施端末（トレース出力）
３ データベース
１１ 試験ＡＰ部
１２ ＡＰＩ部
１３ ファームウェア部
１３１ ＡＰ部
１３２ マスタカード
１３３−１〜１３３−Ｎ スレーブカード
１３３ａ−１ ＣＰＵ
【特許請求の範囲】
【請求項１】
各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価システムであって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装したことを特徴とする無線基地局装置評価システム。
【請求項２】
前記試験パターンは、設計工程から予め試験結果を判定可能とするとともに、予め確認対象とすべき内容を予測可能とし、
前記試験ＡＰは、前記試験パターンによる試験結果を判定することを特徴とする請求項１記載の無線基地局装置評価システム。
【請求項３】
前記試験ＡＰは、前記ＡＰＩの前記試験パターンの実行結果を取得し、その実行結果から前記試験結果の判定を行うことを特徴とする請求項２記載の無線基地局装置評価システム。
【請求項４】
前記試験ＡＰとのインタフェースを持つ試験実施端末を含み、
前記試験実施端末は、前記インタフェースを介して受信した前記試験ＡＰによる前記判定の結果をデータベースに登録することを特徴とする請求項２または請求項３記載の無線基地局装置評価システム。
【請求項５】
各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装したことを特徴とする無線基地局装置。
【請求項６】
前記試験パターンは、設計工程から予め試験結果を判定可能とするとともに、予め確認対象とすべき内容を予測可能とし、
前記試験ＡＰは、前記試験パターンによる試験結果を判定することを特徴とする請求項５記載の無線基地局装置。
【請求項７】
前記試験ＡＰは、前記ＡＰＩの前記試験パターンの実行結果を取得し、その実行結果から前記試験結果の判定を行うことを特徴とする請求項６記載の無線基地局装置。
【請求項８】
前記試験ＡＰとのインタフェースを持つ試験実施端末に接続可能とし、
前記試験ＡＰによる前記判定の結果を前記インタフェースを介して前記試験実施端末に送り、前記判定の結果を前記試験実施端末を通してデータベースに登録することを特徴とする請求項６または請求項７記載の無線基地局装置。
【請求項９】
各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価方法であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装したことを特徴とする無線基地局装置評価方法。
【請求項１０】
前記試験パターンは、設計工程から予め試験結果を判定可能とするとともに、予め確認対象とすべき内容を予測可能とし、
前記試験ＡＰは、前記試験パターンによる試験結果を判定することを特徴とする請求項９記載の無線基地局装置評価方法。
【請求項１１】
前記試験ＡＰは、前記ＡＰＩの前記試験パターンの実行結果を取得し、その実行結果から前記試験結果の判定を行うことを特徴とする請求項１０記載の無線基地局装置評価方法。
【請求項１２】
前記試験ＡＰとのインタフェースを持つ試験実施端末が、前記インタフェースを介して受信した前記試験ＡＰによる前記判定の結果をデータベースに登録することを特徴とする請求項１０または請求項１１記載の無線基地局装置評価方法。
【請求項１】
各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価システムであって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装したことを特徴とする無線基地局装置評価システム。
【請求項２】
前記試験パターンは、設計工程から予め試験結果を判定可能とするとともに、予め確認対象とすべき内容を予測可能とし、
前記試験ＡＰは、前記試験パターンによる試験結果を判定することを特徴とする請求項１記載の無線基地局装置評価システム。
【請求項３】
前記試験ＡＰは、前記ＡＰＩの前記試験パターンの実行結果を取得し、その実行結果から前記試験結果の判定を行うことを特徴とする請求項２記載の無線基地局装置評価システム。
【請求項４】
前記試験ＡＰとのインタフェースを持つ試験実施端末を含み、
前記試験実施端末は、前記インタフェースを介して受信した前記試験ＡＰによる前記判定の結果をデータベースに登録することを特徴とする請求項２または請求項３記載の無線基地局装置評価システム。
【請求項５】
各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装したことを特徴とする無線基地局装置。
【請求項６】
前記試験パターンは、設計工程から予め試験結果を判定可能とするとともに、予め確認対象とすべき内容を予測可能とし、
前記試験ＡＰは、前記試験パターンによる試験結果を判定することを特徴とする請求項５記載の無線基地局装置。
【請求項７】
前記試験ＡＰは、前記ＡＰＩの前記試験パターンの実行結果を取得し、その実行結果から前記試験結果の判定を行うことを特徴とする請求項６記載の無線基地局装置。
【請求項８】
前記試験ＡＰとのインタフェースを持つ試験実施端末に接続可能とし、
前記試験ＡＰによる前記判定の結果を前記インタフェースを介して前記試験実施端末に送り、前記判定の結果を前記試験実施端末を通してデータベースに登録することを特徴とする請求項６または請求項７記載の無線基地局装置。
【請求項９】
各々１以上のパラメータを持つ複数のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）のうちのいずれかをＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）から指示して発行することで動作する無線基地局装置の評価を行う無線基地局装置評価方法であって、前記ＡＰＩに、当該ＡＰＩの動作を確認するための試験パターンを試験実施する試験ＡＰを実装したことを特徴とする無線基地局装置評価方法。
【請求項１０】
前記試験パターンは、設計工程から予め試験結果を判定可能とするとともに、予め確認対象とすべき内容を予測可能とし、
前記試験ＡＰは、前記試験パターンによる試験結果を判定することを特徴とする請求項９記載の無線基地局装置評価方法。
【請求項１１】
前記試験ＡＰは、前記ＡＰＩの前記試験パターンの実行結果を取得し、その実行結果から前記試験結果の判定を行うことを特徴とする請求項１０記載の無線基地局装置評価方法。
【請求項１２】
前記試験ＡＰとのインタフェースを持つ試験実施端末が、前記インタフェースを介して受信した前記試験ＡＰによる前記判定の結果をデータベースに登録することを特徴とする請求項１０または請求項１１記載の無線基地局装置評価方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００６−３４００２２（Ｐ２００６−３４００２２Ａ）
【公開日】平成１８年１２月１４日（２００６．１２．１４）
【国際特許分類】
【出願番号】特願２００５−１６２０８４（Ｐ２００５−１６２０８４）
【出願日】平成１７年６月２日（２００５．６．２）
【出願人】（０００２３２２５４）日本電気通信システム株式会社 (586)
【Ｆターム（参考）】
【公開日】平成１８年１２月１４日（２００６．１２．１４）
【国際特許分類】
【出願日】平成１７年６月２日（２００５．６．２）
【出願人】（０００２３２２５４）日本電気通信システム株式会社 (586)
【Ｆターム（参考）】
[ Back to top ]