JP2007280026A

JP2007280026A - 無線基地局装置

Info

Publication number: JP2007280026A
Application number: JP2006105340A
Authority: JP
Inventors: Chiaki Nakamura; 千秋中村; Takashi Kumachi; 貴九町
Original assignee: Hitachi Kokusai Electric Inc
Current assignee: Hitachi Kokusai Electric Inc
Priority date: 2006-04-06
Filing date: 2006-04-06
Publication date: 2007-10-25

Abstract

【課題】上位装置からの通信プロトコルが異なるアプリケーション・タスクの機能実行要求メッセージに対して、共通化設計を可能とする。
【解決手段】上位装置１９からある通信プロトコルによる固有仕様の機能実行要求メッセージは（ステップＳ１）、無線基地局装置において、有線通信制御部７で受信され（ステップＳ２）、中央処理部メッセージ変換部１７で解読されて解析され（ステップＳ３）、この解析結果に基づいて同じ要求内容の標準仕様の機能実行要求メッセージに変換される（ステップＳ４）。この標準仕様の機能実行要求メッセージにより、該当するアプリケーション・タスクの実行が要求され、このアプリケーション・タスク２０が実行される（ステップＳ６）。
【選択図】図５

Description

本発明は、移動無線通信システムなどの無線基地局装置に係わり、特に、上位装置から異なる通信プロトコルでアプリケーションの実行を要求するメッセージを受信する無線基地局装置に関する。

近年、Ｗ−ＣＤＭＡ方式やＣＤＭＡ２０００方式などによる無線通信システムにおいて、携帯電話端末機のユーザがビジネスユーザからパーソナルユーザへと利用範囲が広がり、現在では、子供からお年寄りまで幅広い年齢層で使用されてるようになってきている。そして、このようなユーザの増加に伴い、多数の会社が携帯電話事業に参加し、各社の事業競争が激化し、各社が独自の機能，サービスを提供するなど事業戦略を図っている。このため、多数のシステムが存在したり、同じシステム内で相似した装置が存在したりしている状況にある。

例えば、無線基地局装置の管理・運営についてみると、無線基地局装置に管理・運営のために所定の動作を行なわせるものであるが、かかる動作、即ち、アプリケーション・タスクを実行させるために、上部装置からそのための要求メッセージを送信する。この場合、携帯電話事業に参画した各社で個々に開発が行なわれると、例えば、かかる要求メッセージのための通信プロトコルも各社毎に異なる場合もあり、これを処理するためのハードウェアやソフトウェアが夫々の会社毎に開発されることになる（例えば、特許文献１参照）。
特開２００６ー２０１４３

ところで、各社が個々に事業開発を行なうことにより、上記のように、要求メッセージの通信プロトコルが異なると、共通する部分がありながら、各社毎に必要なハードウェアやソフトウェアを開発することになる。例えば、上記のように、無線基地局装置にその管理・運営のためのアプリケーション・タスクを設定し、かかるアプリケーション・タスクを上位装置からの要求メッセージによって実行させるにしても、アプリケーション・タスクやそれを実行させるためのソフトウェアなどを各社が夫々開発することになり、その開発に膨大な費用と時間がかかることになり、サービス運用までに必要以上の時間を要することになるし、また、同じアプリケーション・タスクを実行させるにしても、それを実行させるためのソフトウェアやハードウェアが異なるため、装置の信頼性や安定性が低くなるという問題がある。

このため、かかるソフトウェアやハードウェアを共通化可能とする共通化設計を考慮したシステムや装置の開発が必要とされるものであるが、従来では、この点の配慮がなされていなかった。

本発明は、かかる点に鑑みてなされたものであって、その目的は、上位装置からの通信プロトコルが異なるアプリケーション・タスクの機能実行要求メッセージに対して、共通化設計を可能とした無線基地局装置を提供することにある。

上記目的を達成するために、本発明は、上位装置から通信プロトコルが異なる固有仕様の機能実行要求メッセージを受信し、該機能実行メッセージで要求されるアプリケーション・タスクを実行する無線基地局装置であって、受信した該固有仕様の機能実行要求メッセージを共通の標準仕様の機能実行要求メッセージに変換する変換部を設け、該標準仕様の機能実行メッセージで共通のアプリケーション・タスクの実行を要求することを特徴とするものである。

本発明によると、各社毎の仕様の機能実行要求メッセージが標準仕様の機能実行要求メッセージに変換され、この標準仕様の機能実行要求メッセージによってアプリケーション・タスクの実行が要求されるものであるから、アプリケーション・タスクを実行させるためのソフトウェアを各社共通化できる。そして、かかるソフトウェアの共通化により、このソフトウェアの流通率が向上し、共通のソフトウェアを使用することから、装置の信頼性／安定性も向上し、また、かかる共通のソフトウェアは既に開発されているものであるので、システムの早期開発やコストの削減も達成できることになる。

以下、本発明の実施形態を図面を用いて説明する。

図１は移動無線通信システムの概略構成を示すシステム図であって、１ａ，１ｂは無線基地局装置、２，２Ａ，２Ｂ，２ＣはＲＮＣ（Radio Network Controller：無線ネットワーク制御装置）、３，３Ａ，３Ｂ，３ＣはＯＭＣ（Operation and Maintenance Center：運用管理センタ）、４は携帯電話端末である。

同図において、各エリア（セル）毎に無線基地局１ａ，１ｂ，……が設置されており、携帯電話端末４は、これが存在するセルに設置されている無線基地局装置１ａ，１ｂ，……と無線通信することができる。これら無線基地局装置１ａ，１ｂ，……は、その上位装置であるＲＮＣ２と、例えば、インターネットなどの有線の通信回線を介して接続され、かかるＲＮＣ２によって通話などの制御がなされる。また、無線基地局装置１ａ，１ｂ，……とＲＮＣ２からなる無線通信システムは、さらにその上位装置としてのＯＭＣ３によって運営・管理されている。かかるＯＭＣ３はＲＮＣ２と専用回線によって接続されている。

ＲＮＣ２としては、各社が開発したものが使用されており、ＲＮＣ２ＡはＡ社が開発したもの、ＲＮＣ２ＢはＢ社が開発したもの、ＲＮＣ２ＣはＣ社が開発したものである。また、ＯＭＣ３としても、各社が、自社が開発したＲＮＣ２を管理・運営するために開発したものが使用されており、ＯＭＣ３ＡはＲＮＣ２Ａを管理・運営するためのＡ社が開発したもの、ＯＭＣ３ＢはＲＮＣ２Ｂを管理・運営するためのＢ社が開発したもの、ＯＭＣ３ＣはＲＮＣ２Ｃを管理・運営するためのＣ社が開発したものである。

かかる移動無線通信システムにおいては、ＯＭＣ３の運営・管理の基に、ＲＮＣ２が無線基地局装置１ａ，１ｂ，……を制御することにより、一方の携帯電話携帯４と他方の携帯電話端末４との間で通話やデータ通信などの通信が行なわれるが、Ａ社製の携帯電話端末４から発呼（通信要求メッセージ）があると、これを受信した無線基地局装置１ａはこれをＲＮＣ２に送るが、この通信要求メッセージがＡ社による通信プロトコルによる仕様（フォーマット）に基づくものであることから、これらＲＮＣ２のうちのかかる通信プロトコルを受け付けるＡ社のＲＮＣ２Ａがこの通信要求メッセージを受信し、相手先の携帯電話端末と通信可能なセルに設置された無線基地局装置１ｂに送る。この無線基地局装置１ｂでは、ＲＮＣ２Ａからの通信要求メッセージを受信すると、相手先の携帯電話端末と通信可能であるか否かを判定し、その判定結果を、通信応答メッセージとして、Ａ社製のＲＮＣ２Ａに送る。この判定結果が通信可能であるということであれば、このＲＮＣ２Ａは、無線基地局装置１ａ，１ｂを制御して通信要求メッセージを発生した発信元の携帯電話端末４と相手先の携帯電話端末との間の通信を可能とし、通信できないとの判定結果があったときには、発信元の携帯電話装置４に発信元側の無線基地局装置１ａからその旨を通知させる。

また、ＯＭＣ３Ａ，３Ｂまたは３Ｃは、各無線基地局装置１ａ，１ｂ，……を運営・管理するために、同じ会社が開発した該当するＲＮＣ２Ａ，２Ｂまたは２Ｃから無線基地局装置１ａ，１ｂ，……に所定の機能（アプリケーション）を実行させるための要求メッセージ（以下、機能実行要求メッセージという）を送る。この機能実行要求メッセージは、これを発生するＲＮＣ２の会社の通信プロトコルによる仕様に従うものであり、各社毎に仕様が異なるものである。以下では、各社毎の機能実行要求メッセージを固有仕様の機能実行要求メッセージという。

かかる固有仕様の機能実行要求メッセージを取得した無線基地局装置１ａ，１ｂ，……は、この固有仕様の機能実行要求メッセージによって要求されるアプリケーション・タスクを実行するが、このために、取得された固有仕様の機能実行要求メッセージは、一旦全社共通となる標準の仕様の機能実行要求メッセージ（以下、標準仕様の機能実行要求メッセージという）に変換され、この標準仕様の機能実行要求メッセージによって該当するアプリケーション・タスクが指定されて実行される。また、このアプリケーション・タスクの実行の結果が、応答メッセージとして、上位装置のＲＮＣ２に返されるが、この場合も、無線基地局装置１ａ，１ｂ，……で得られるアプリケーション・タスクの実行の結果を表わす応答メッセージは標準の仕様に従うものであり、これがＲＮＣ２から送られてきた固有仕様の機能実行要求メッセージと同じ固有仕様の機能実行応答メッセージに変換され、このＲＮＣ２に送信される。

図２は図１に示す移動無線通信システムに用いられる本発明による無線基地局装置の一実施形態を示すブロック構成図であって、１はこの実施形態の無線基地局装置、５は無線通信制御部、６は中央処理部、７は有線通信制御部、８はソフトウェア部、９はプログラム部、１０はＯＳ（Operating System：基本ソフトウェア）部、１１はメモリ部、１２は揮発メモリデバイス、１３は不揮発メモリデバイス、１４はクロック部、１５は電源部、１６はメンテナンスツールである。

同図において、中央処理部６は、プログラム部９やＯＳ部１０，メモリ部１１などのソフトウェア部８、ＲＡＭなどの揮発性メモリデバイス１２及びＲＯＭなどの不揮発メモリデバイス１３を備えており、ソフトウェア部８は不揮発メモリデバイス１３に格納されている。電源部１５からの電源が投入されると、不揮発メモリデバイス１３からソフトウェア部８のＯＳ部１０が中央処理部６に読み取られ、中央処理部６がこのＯＳ部１０を基に動作することにより、各種のアプリケーション・ソフトが動作する環境を作り、無線通信制御部５を携帯電話端末４（図１）と無線通信可能とし、有線通信制御部７を上位装置のＲＮＣ２と有線通信可能とする。また、中央処理部６は、かかる環境で揮発メモリデバイス１２を用いて各種の処理を行なう。ソフトウェア部８のメモリ部１１は、揮発メモリデバイス１２や不揮発モメリデバイス１３でのデータやプログラムを読み書きのためのプログラムである。

上位装置のＲＮＣ２（図１）がこの無線基地局装置１にその管理のための機能実行要求メッセージを送るときには、この機能実行要求メッセージはインターネットなどの有線通信回線で送信され、無線基地局装置１では、有線通信制御部７で受信されて中央処理部６に転送される。ここで、この機能実行要求メッセージは、上記のように、上位装置であるＲＮＣ２Ａ，２Ｂ，２Ｃ、従って、Ａ社，Ｂ社，Ｃ社固有の通信プロトコルに応じた仕様のメッセージ、即ち、固有仕様の機能実行要求メッセージである。中央処理部６は、かかる固有仕様の要求メッセージに対しては、ソフトウェア部８のプログラム部９を実行することにより、固有仕様の機能実行要求メッセージを解読・解析して該当する標準仕様の機能実行要求メッセージに変換し、かかる標準仕様の機能実行要求メッセージにより、これが要求する（従って、受信した固有仕様の機能実行要求メッセージが要求する）アプリケーション・タスクを実行する。この際、ロギング制御処理も行なわれ、この処理過程で得られるロギング情報が、メモリ部１１の実行により、不揮発メモリデバイス１３に記憶される。かかるロギング情報は、メンテナンスツール１６で読み取り、それを解析したり、表示したりすることができる。

中央処理部６は、要求されたアプリケーション・タスクの実行結果を応答データとして取得し、これに所定の情報を付加して標準仕様の機能実行応答メッセージを作成する。そして、中央処理部６は、プログラム部９を実行することにより、この標準仕様の機能実行応答メッセージを、受信した上記の固有仕様の機能実行要求メッセージと同じ会社の通信プロトコルによる仕様の機能実行応答メッセージ、即ち、固有仕様の機能実行応答メッセージに変換し、有線通信制御部７からインターネットなどの有線通信回線を介して上記の固有仕様の機能実行要求メッセージを送った上位装置、即ち、ＲＮＣ２Ａ，２Ｂ，２Ｃのいずれかに送信する。

このようにして、各社毎に仕様が異なる機能実行要求メッセージを受けても、無線基地局装置１は、標準仕様の機能実行要求メッセージに変換して要求されるアプリケーション・タスクを実行するものであるから、ＲＮＣ２Ａ，２Ｂ，２Ｃ毎の異なるメッセージに対し、装置内部のアプリケーション・タスクに対するソフトウェアに共通のインタフェースを提供するソフトウェア共通化設計が可能となる。また、かかる固有仕様の機能実行要求メッセージに対する機能実行応答メッセージも、この固有仕様の機能実行要求メッセージと同じ会社の通信プロトコルによる仕様の固有仕様の機能実行応答メッセージとしてＲＮＣ２に送られるので、機能実行要求メッセージを送ったＲＮＣ２も、確実に機能実行要求メッセージに対する機能実行応答メッセージを取得することができる。

図３は図２に示す無線基地局装置１のメッセージの変換機能インタフェースを示す構成図であって、１７はメッセージ変換部、１８はアプリケーション、１９は上位装置である。

同図において、メッセージ変換部１７は、図２において、中央処理部６でのプログラム部９によって固有仕様の機能実行要求メッセージを標準仕様の機能実行要求メッセージに変換したり、逆に、標準仕様の機能実行要求メッセージを固有仕様の機能実行要求メッセージに変換したりする部分である。

メッセージ変換部１７と上位装置１９（図１の場合、ＲＮＣ２）との間のインタフェースは、各社毎に異なる仕様のインタフェース（各社相違インタフェース）をなすものであり、Ａ社，Ｂ社，Ｃ社毎に仕様が異なる機能実行要求／応答（要求または応答）メッセージが通信され、メッセージ変換部１７とアプリケーション１８との間のインタフェースは、各社共通の標準仕様のインタフェース（標準インターフェース）をなすものであり、標準仕様の機能実行要求／応答メッセージが通信される。

図４は図２に示す無線基地局装置１のメッセージに対するソフトウェア・タスクを示す構成図であって、２０はアプリケーション・タスク、２１はプラットフォーム・タスク、２２はミドルウェア・タスク、２３は共通ライブラリ、２４は装置ドライバ、２５はＩＰＬ（Initial Program Loader：初期プログラムローダ）、２６は通信ドライバであり、図３に対応する部分には同一符号をつけて重複する説明を省略する。

同図において、電源部１５（図２）の電源が投入されると、ＩＰＬ２５が起動してＯＳ部１０を不揮発メモリディバイス１３（図２）から読み出し、これによって中央処理部６（図２）が起動する。

かかる状態で、上位装置１９から固有仕様の機能実行要求メッセージが送信されると、この固有仕様の機能実行要求メッセージは通信ドライバ２６を介して有線通信制御部７で受信され、中央処理部６のメッセージ変換部で標準仕様の機能実行要求メッセージに変換される。この標準仕様の機能実行要求メッセージにより、これによって要求されるアプリケーション・タスク２０が実行される。また、このアプリケーション・タスク２０の実行中、プラットフォーム・タスク２１やミドルウェア・タスク２２，共通ライブラリ２３，装置ドライバ２４のうちの必要なタスクが実行される。かかるタスクの実行中に得られるロギング情報が、図２で説明したように、不揮発メモリデバイス１３に記憶される。

アプリケーション・タスク２０の実行が終了すると、その実行結果に対する標準仕様の機能実行応答メッセージがメッセージ変換部１７に供給され、先に送られてきた固有仕様の機能実行要求メッセージと同じ仕様の機能実行応答メッセージ、即ち、固有仕様の機能実行応答メッセージに変換され、有線通信制御部７からウィンドネット２６を介して上記の固有仕様の機能実行要求メッセージを送ってきた上位装置１９に送信する。

図５は図２に示す無線基地局装置１の機能実行要求メッセージによる処理動作の流れの一具体例を示すフローチャートであって、２７はロギングライブラリであり、前出図面に対応する部分には同一符号をつけて重複する説明を省略する。

同図において、上位装置１９から固有仕様の機能実行要求メッセージがあると（ステップＳ１）、無線基地局装置１では、これが有線通信制御部７で受信され（ステップＳ２）、中央処理部６（図２）のメッセージ変換部１７に供給される。このメッセージ変換部１７では、供給された固有仕様の機能実行要求メッセージが解読されて解析され（ステップＳ３）、この解析結果に基づいて同じ要求内容の標準仕様の機能実行要求メッセージに変換される（ステップＳ４）。そして、この変換とともに、かかる標準仕様の機能実行要求メッセージを受けたことを示す、即ち、実行要求があった機能（アプリケーション）の種類などを示すロギング情報がロギングライブラリ２７に格納される（ステップＳ５）。なお、このロギングライブラリイ２７は、不揮発メモリデバイス１３（図２）に設けられている。

また、この標準仕様の機能実行要求メッセージにより、該当するアプリケーション・タスクの実行が要求され、要求するアプリケーション・タスク２０が実行される（ステップＳ６）。

このアプリケーション・タスク２０の実行が終了すると、標準仕様の機能実行応答メッセージが得られる（ステップＳ７）。また、このアプリケーション・タスク２０の実行中に得られたロギング情報も、ロギングライブラリイ２７に記憶される（ステップＳ８）。この標準仕様の機能実行応答メッセージは、メッセージ変換部１７により、上記の固有仕様の機能実行要求メッセージを提供した上記の上位装置１９の通信プロトコルによる固有仕様の機能実行応答メッセージに変換され（ステップＳ９）、有線通信制御部７から上位装置１９に送信される（ステップＳ１０，Ｓ１１）。

このように、無線基地局装置１では、上位装置１９からの異なる通信プロトコルによる仕様の機能実行要求メッセージを受信し、また、異なる通信プロトコルによる仕様の機能実行応答メッセージを上位装置１９に送信することから、有線通信制御部７では、図６に示すように、例えば、インターネットなどのＴＣＰ／ＩＰネットワークを管理するプロトコル「ＳＮＭＰ（Simple Network Management Protocol）」のインタフェース部やオブジェクト間のインタフェース仕様である「ＣＯＲＢＡ（Common Object Request Broker Architecture）」などのインタフェース部を備えている。メーセージ変換部１７は、かかるインターフェース部によって取得した固有仕様の機能実行要求メッセージを解読・解析して標準仕様の機能実行要求メッセージに変換する。また、メーセージ変換部１７で標準仕様の機能実行要求メッセージから変換された固有仕様の機能実行要求メッセージは、これに該当するインタフェース部から上位装置１９に送信される。

図７は図２に示す無線基地局装置１でのメッセージ変換を示す図であって、２８Ａ，２８Ｂ，２８Ｃは夫々Ａ，Ｂ，Ｃ社の固有仕様の機能実行要求／応答メッセージ、２９は標準仕様の機能実行要求／応答メッセージであり、前出図面に対応する部分には同一符号をつけて重複する説明を省略する。

同図において、固有仕様の機能実行要求／応答メッセージ２８、即ち、Ａ社の機能実行要求／応答メッセージ２８ＡとＢ社の機能実行要求／応答メッセージ２８ＢとＣ社の機能実行要求／応答メッセージ２８Ｃとは、通信プロトコルが異なってその仕様が異なるものである。これに対し、標準仕様の機能実行要求／応答メッセージ２９は、その仕様が１つであり、図示するように、アプリケーション・タスクに対するメッセージヘッダとアプリケーション・タスクに対するメッセージのコマンドＩＤ（IDentification）と要求または応答メッセージの内容を示す標準共通パラメータとから構成される。メッセージ変換部１７は、これら固有仕様の機能実行要求／応答メッセージ２８と標準仕様の機能実行要求／応答メッセージ２９との間の変換を行なう。

図８は標準仕様の機能実行要求／応答メッセージ２９の内容の一具体例を示す図である。

同図において、実行が要求される機能（アプリケーション・タスク）の項目としては、ここでは、障害管理（FaultManagement）、構成管理（Coｎfiguration Management）、測定管理（Performance Management）、セキュリティ管理（Security Management）、ファイル転送(File Transfer)などを示している。ここでは、図示しないが、機能（アプリケーション）の項目には、メッセージヘッダＮｏが割り当てられている。これら機能項目毎にタスク、即ち、アプリケーション・タスクが展開されており、例えば、誤動作管理の機能項目についていうと、「ＡＬＭ（アラーム）状態復旧」，「ＡＬＭ状態監視開始」，「ＡＬＭ状態監視停止」，「ＡＬＭフィルタ設定」などといったアプリケーション・タスクが展開され、夫々毎に、そのタスクの実行を要求するためのメッセージを表わす標準共通パラメータが設定されている。そして、標準仕様の機能実行要求メッセージでは、これら毎に標準コマンドＩＤが割り当てられている。ここでは、この標準コマンドＩＤは１６進数（ｈ）で表わされる。例えば、アプリケーション・タスク「ＡＬＭ状態復旧」の要求メッセージ「ＡＬＭ状態復旧要求」に対しては、「0101」が割り当てられている。かかる標準仕様の機能実行要求／応答メッセージ２９の一覧が、テーブルとして、図２における不揮発メモリデバイス１３に格納されており、中央処理部６がプログラム部９による動作で適宜読み出すことができる。

図９は図２に示す実施形態でのメッセージ変換の一具体例を詳細に示す図である。２８Ｒ_AはＡ社固有の仕様の機能実行要求メッセージ、２８Ｒ_BはＢ社固有の仕様の機能実行要求メッセージ、２８Ｃ_AはＡ社固有の仕様の機能実行応答メッセージ、２８Ｃ_BはＢ社固有の仕様の機能実行応答メッセージ、２９Ｒは標準仕様の機能実行要求メッセージ、２９Ｃは標準仕様の機能実行応答メッセージである。

図９（ａ）はＡ社の固有仕様の機能実行要求メッセージ２８Ｒ_Aを標準仕様の機能実行要求メッセージ２９Ｒ_Aに変換する場合を示し、図９（ｃ）はＢ社の固有仕様の機能実行要求メッセージ２８Ｒ_Bを標準仕様の機能実行要求メッセージ２９Ｒ_Bに変換する場合を示している。

同図（ａ）において、Ａ社の固有仕様の機能実行要求メッセージ２８Ｒ_Aは、シーケンスＮｏとグループＮｏと要求メッセージを表わす要求メッセージデータとで形成されるフォーマットをなしているものとしている。ここでは、シーケンスＮｏは１，グループＮｏも１であって、要求メッセージ内容は要求メッセージデータａ，ｂ，ｃで表わされており、これにより、アプリケーション・タスク「ＡＬＭ状態復旧」の実行を要求しているものとする。Ａ社の固有仕様の機能実行要求メッセージ２８Ｒ_Aはメッセージ変換部１７によって解読・解析されるが、この結果に基づいて、まず、シーケンスＮｏとグループＮｏとを有するフォーマットをなすことから、この機能実行要求メッセージ２８Ｒ_AがＡ社固有の仕様の要求メッセージであると判定する。かかる判定は、各社の機能実行要求／応答メッセージのフォーマットの一覧をテーブルとして、例えば、無線基地局装置１の不揮発メモリデバイス１３に保持されており、かかるテーブルを用いることにより、行なうことができる。

そして、このように判定したＡ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aに対しては、
（ｉ）シーケンスＮｏとグループＮｏとの組み合わせが標準コマンドＩＤと一対一に対応しており、このことから、まず、標準コマンドＩＤが選択される。ここでは、シーケンスＮｏ．１で、かつグループＮｏ．１であるとき、図８における標準コマンドＩＤ「0101」が選択されたものとする。このために、各社固有の仕様の機能実行要求／応答メッセージのシーケンスＮｏやグループＮｏなどと標準コマンドＩＤとの対応表が、テーブルとして、例えば、無線基地局装置１の不揮発メモリデバイス１３に保持されている。
（ii）次に、選択された標準コマンドＩＤから該当するアプリケーション・タスクを選択し、これを指定するメッセージヘッダＮｏを作成する。メッセージヘッダＮｏは図８の機能項目毎に割り当てられており、機能項目「誤動作管理（FaultManagement）」にメッセージヘッダＮｏ．１が割り当てられているとすると、標準コマンドＩＤ「0101」に対してメッセージヘッダＮｏ．１が設定される。
（iii）次に、Ａ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aの要求メッセージデータａ，ｂ，ｃを標準仕様の機能実行要求メッセージの要求の標準共通パラメータに変換する。これは、上記のようにして得られたメッセージヘッダＮｏと標準コマンドＩＤとを用いて行なわれ、ここでは、メッセージヘッダＮｏが１、標準コマンドＩＤが「0101」であることから、図８に示すメッセージ「ＡＬＭ状態復旧要求」に対する標準共通パラメータが、要求メッセージデータＡ，Ｂ，Ｃとして設定される。

以上により、Ａ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aに対する標準仕様の機能実行要求メッセージ２９Ｒが作成されることになる。上記の例では、標準仕様の機能実行要求メッセージ２９Ｒでは、メッセージヘッダＮｏが１、標準コマンドＩＤが「Ox0101」（但し、「Ox」は１６進数であることを表わすもの）、標準共通パラメータが要求メッセージデータＡ，Ｂ，Ｃであり、かかる標準仕様の機能実行要求メッセージ２９Ｒにより、機能項目「誤動作管理」の「ＡＬＭ状態復旧」というアプリケーション・タスクの実行が要求され、該当するアプリケーション・タスクが標準仕様の機能実行要求メッセージ２９Ｒの要求メッセージデータＡ，Ｂ，Ｃを用いて実行される。

次に、図９（ｂ）において、Ａ社固有の仕様の機能実行要求メッセージ２９Ｒ_Aから変換された標準仕様の機能実行要求メッセージ２９Ｒで要求されたアプリケーション・タスクが実行が終了すると、
（i）その結果に応じて、図７で説明したように、メッセージヘッダと標準コマンドＩＤと標準共通パラメータ（応答データ）とからなる標準仕様の機能実行応答メッセージ２９Ｃが作成される。ここでは、メッセージヘッダＮｏを１とし、標準コマンドＩＤを「Ox0181」とし、標準共通パラメータを応答データＺとしており、この応答データＺが「誤動作管理」の「ＡＬＭ状態復旧」というアプリケーション・タスクの実行結果に応じた情報を表わしている。
（ii）次に、メッセージ変換部１７では、この標準仕様の機能実行応答メッセージ２９ＣをＡ社固有の仕様の機能実行応答メッセージに変換するのであるが、この機能実行応答メッセージを生じさせたアプリケーション・タスクの機能実行要求メッセージがＡ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aであることから、Ａ社についての上記の対応表のテーブルから、この標準仕様の機能実行応答メッセージ２９Ｃでの標準コマンドＩＤ「Ox0181」に対するＡ社固有の仕様の機能実行応答メッセージ２８Ｃ_AでのシーケンスＮｏ（例えば、シーケンスＮｏ．２）とグループＮｏ（例えば、グループＮｏ．１）とを選択し、上記の各社の機能実行要求／応答メッセージのフォーマットの一覧をテーブルから、この選択したシーケンスＮｏ．２とグループＮｏ．１とに対する応答データを選択する。この応答データは、標準仕様の機能実行応答メッセージ２９Ｃの応答データＺに対応するものであって、これを「データｚ」とする。

このようにして、シーケンスＮｏ．２、グループＮｏ．１で応答データｚのＡ社固有の仕様の機能実行応答メッセージ２８Ｃ_Aが得られる。これが、上位装置１９のＲＮＣ２Ａ（図１）に送信される。

Ｂ社固有の仕様の機能実行要求メッセージ２８Ｒ_Bの場合には、図９（ｃ）に示すように、シーケンスＮｏを持つが、グループＮｏを持たず、また、要求メッセージデータも、図９（ａ）に示すＡ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aと同じ要求でありながら、要求メッセージデータａ，ｃからなってデータｂを持たないことから、Ａ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aとフォーマットが異なっている。

かかるＢ社固有の仕様の機能実行要求メッセージ２８Ｒ_Bについては、かかるフォーマットを基に、上記の各社の機能実行要求／応答メッセージのフォーマット一覧をテーブルにより、Ｂ社固有の仕様のものと判定する。そして、
（ｉ）シーケンスＮｏから、まず、標準コマンドＩＤが選択される。ここでは、Ｂ社固有の仕様の機能実行要求メッセージ２８Ｒ_BでシーケンスＮｏが１であることから、上記の各社固有の仕様の機能実行要求／応答メッセージのシーケンスＮｏやグループＮｏなどと標準コマンドＩＤとの対応表のテーブルにより、Ａ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aの場合と同じ標準コマンドＩＤ「0101」（図８）が選択される。
（ii）次に、Ａ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aの場合と同様、選択された標準コマンドＩＤ「0101」から該当するアプリケーション・タスク、即ち、図８での機能項目「誤動作管理（FaultManagement）」に対するメッセージヘッダＮｏ.１が作成される。
（iii）次に、Ｂ社固有の仕様の機能実行要求メッセージ２８Ｒ_Bの要求メッセージデータａ，ｃを標準仕様の機能実行要求メッセージの標準共通パラメータに変換するが、メッセージヘッダＮｏがＮｏ.１，標準コマンドＩＤが「０１０１」であることから、上記のＡ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aの場合と同様、標準メッセージ「ＡＬＭ状態復旧要求」に対する標準共通パラメータが、要求メッセージデータＡ，Ｂ，Ｃとして、設定される。

以上により、Ｂ社固有の仕様の機能実行要求メッセージ２８Ｒ_Bに対する標準仕様の機能実行要求メッセージ２９Ｒ（これは、Ａ社固有の仕様の機能実行要求メッセージ２８Ｒ_Aの場合と同じ）が作成されることになる。従って、この場合も、同じ標準仕様の機能実行要求メッセージ２９Ｒにより、機能項目「誤動作管理」の「ＡＬＭ状態復旧」というアプリケーション・タスクの実行が要求され、該当するアプリケーション・タスクが標準仕様の機能実行要求メッセージ２９Ｒの要求メッセージデータＡ，Ｂ，Ｃを用いて実行される。

次に、図９（ｄ）において、Ｂ社固有の仕様の機能実行要求メッセージ２９Ｒ_Bから変換された標準仕様の機能実行要求メッセージ２９Ｒで要求されたアプリケーション・タスクの実行が終了すると、
（i）その結果に応じて、図７で説明したように、メッセージヘッダと標準コマンドＩＤと標準共通パラメータ（応答データ）とからなる標準仕様の機能実行応答メッセージ２９Ｃが作成される。ここでは、メッセージヘッダをＮｏ．１とし、標準コマンドＩＤを「Ox0181」とし、応答データを「データＺ’」としており、この応答データ「データＺ’」が「誤動作管理」の「ＡＬＭ状態復旧」というアプリケーション・タスクの実行結果に応じた情報を表わしている。ここでは、Ａ社固有の仕様の機能実行要求メッセージＲ_Aの場合と同じ標準仕様の機能実行要求メッセージ２９Ｒにより、同じアプリケーション・タスクが実行されるが、その実行結果が異なる場合もあり得るので、応答データを「データＺ’」とした。
（ii）次に、メッセージ変換部１７では、この標準仕様の機能実行応答メッセージ２９ＣをＢ社固有の仕様の機能実行応答メッセージに変換するのであるが、この機能実行応答メッセージを生じさせたアプリケーション・タスクの機能実行要求メッセージがＢ社固有の仕様の機能実行要求メッセージ２８Ｒ_Bであることから、Ｂ社についての上記の対応表のテーブルから、この標準仕様の機能実行応答メッセージ２９Ｃでの標準コマンドＩＤ「Ox0181」に対するＢ社固有の仕様の機能実行要求メッセージ２８Ｒ_BでのシーケンスＮｏ（例えば、シーケンスＮｏ．２）を選択し、上記の各社の機能実行要求／応答メッセージのフォーマットの一覧をテーブルから、この選択したシーケンスＮｏ．２に対する応答データを選択する。この応答データは、標準仕様の機能実行応答メッセージ２９ＣＡの標準共通パラメータ「データＺ’」に対応するものであって、例えば、「データｚ’」とする。

このようにして、シーケンスＮｏ．２、グループＮｏ．１で応答データｚ’のＡ社固有の仕様の機能実行応答メッセージ２８ＣＡが得られる。これが、上位装置１９のＲＮＣ２Ａ（図１）に送信される。

以上のようにして、各社毎の仕様の機能実行要求メッセージが標準仕様の機能実行要求メッセージに変換され、この標準仕様の機能実行要求メッセージによってアプリケーション・タスクの実行が要求されるものであるから、アプリケーション・タスクを実行させるためのソフトウェアを各社共通化できる。そして、かかるソフトウェアの共通化により、このソフトウェアの流通率が向上し、共通のソフトウェアを使用することから、装置の信頼性／安定性も向上し、また、かかる共通のソフトウェアは既に開発されているものであるので、システムの早期開発やコストの削減も達成できることになる。さらに、装置間ロギング機能も備えているので、システムの運用状態の解析も可能となる。

なお、以上の実施形態では、２つの会社または３つの会社を例に説明したが、２以上の任意の数の会社に対して適用可能であることはいうまでもない。

上記の通信プロトコルや標準仕様の機能実行要求メッセージについては、一例として示すものであって、本発明は、これらのみに限るものではない。

移動無線通信システムの概略構成を示すシステム図である。本発明による無線基地局装置のソフトウェア共通化設計装置の一実施形態を示すブロック構成図である。図２に示す無線基地局装置のメッセージの変換機能インタフェースを示す構成図である。図２に示す無線基地局装置のメッセージに対するソフトウェアタスクを示す構成図である。図２に示す実施形態の要求メッセージによる動作の流れの一具体例を示すフローチャートである。図２における有線通信制御部の構成を概略的に示す図である。図２に示す無線基地局装置でのメッセージ変換の一具体例を概略的に示す図である。図２に示す無線基地局装置で用いる標準仕様の機能実行要求／応答メッセージの内容の一具体例を示す図である。図２に示す無線基地局装置でのメッセージ変換の一具体例を詳細に示す図である。

符号の説明

１，１ａ，１ｂ無線基地局装置
２，２Ａ〜２ＣＲＮＣ
３，３Ａ〜３ＣＯＭＣ
４携帯電話端末
５無線通信制御部
６中央処理部
７有線通信制御部
８ソフトウェア部
９プログラム部
１０ＯＳ部
１１メモリ部
１２揮発メモリデバイス
１３不揮発メモリデバイス
１７メッセージ変換部
１８アプリケーション
１９上位装置
２０アプリケーション・タスク
２１プラットフォーム・タスク
２２ミドルウェア・タスク
２３共通ライブラリ
２４装置ドライバ
２７ロギングライブラリ
２８Ｒ_A Ａ社固有の仕様の機能実行要求メッセージ
２８Ｒ_B Ｂ社固有の仕様の機能実行要求メッセージ
２８Ｃ_A Ａ社固有の仕様の機能実行応答メッセージ
２８Ｃ_B Ｂ社固有の仕様の機能実行応答メッセージ
２９Ｒ標準仕様の機能実行要求メッセージ
２９Ｃ標準仕様の機能実行応答メッセージ

Claims

上位装置から通信プロトコルが異なる固有仕様の機能実行要求メッセージを受信し、該機能実行メッセージで要求されるアプリケーション・タスクを実行する無線基地局装置において、
受信した該固有仕様の機能実行要求メッセージを共通の標準仕様の機能実行要求メッセージに変換する変換部を設け、
該標準仕様の機能実行メッセージで共通のアプリケーション・タスクの実行を要求することを特徴とする無線基地局装置。