無線回線制御技術の進化と深化
Evolution and deepening of the wireless communication control technology
磯部 洋次＊
Yoji Isobe

無線通信分野は、＜第1世代（1G）＞アナログ方式の携帯電話（FDMA方式）、＜第2世代（2G）＞デジタル方式携帯電話（TDMA方式）、＜第3世代（3G）＞デジタル方式携帯電話（W-CDMA方式）と無線周波数の有効利用に向けたデジタル化が進むと共に、インターネットの普及によるパケット伝送の需要が急増、低コスト化・高速化・低遅延化のための伝送技術の標準化、さらに次世代への大容量高速通信化へと変化を遂げている。
無線回線制御技術においても、制御するデータ量ならびにユーザ数（呼数）が増大し、リアルタイム組込ソフトウェアの重要性が高まる中、当社は、通信制御装置の組込ソフトウェア開発に従事し、時代に応じた市場の発展に伴うキャリアの要求に応えるべく、経験を積んできた。
本論文では、これまでの開発経験を踏まえた無線回線制御におけるソフトウェア設計に関する変遷（構造化設計からオブジェクト指向へ）、ならびに、アーキテクチャの進化と深化について述べる。
In the field of wireless communication, with the advance of the digitization to utilize the radio
frequency, throughout ＜the first generation（1G）＞ analog cell-phone（FDMA method）, ＜thesecond generation（2G）＞ digital cell-phone（TDMA method）, and ＜the third generation（3G）＞ digital cell-phone（W-CDMA method）, the technology has changed to rapidly increase of
demand for packet transmission by the spread of Internet, the standardization of the transmission
technology for price reduction, speeding up and low delay, furthermore a large-capacity high speed
communication toward the next generation.
In the wireless communication control technology, quantity of to control data and the number ofusers（the number of calls）increased, and importance of real-time embedded software isincreased.
Under such situations, we have engaged in development of real-time embedded software, andacquired experiences to meet the demand of the carriers with the development of the market.
In this article, we describe the change about the software design（from a structured design toobject-oriented design）on the basis of past development experience and evolution and deepeningof the architecture in the wireless communication control.

1．まえがき無線制御装置、第三世代無線基地局のS/W開発を経て現在に至る（図１）。

1980年代に登場したアナログ方式は音声中心の携帯電2．システム概要話であったが、1990年代にアナログ方式からデジタル方式へ、加えて、低速データ通信も始まった。2000年代後半には、音声、画像、高速データ通信が広まり、公衆網一般的に無線通信インフラのシステム構成は、図２のようになる。のIP化に伴う大容量高速通信の需要が高まり、現在で伝送装置は、ネットワークを通じて、情報（データやは、第四世代（4G）に向けた拡張が行われており、当音声等）を伝える装置である。例えば、電話のように有社が無線通信制御装置（無線回線制御技術）の開発に携

線や無線で情報を伝達する際、外部からの雑音などの影わったのは1993年頃で、90年代には第二世代無線基地局、響により、情報が欠損したり、破損して正しい情報が伝35＊関西事業部 第三技術部

わらなかったりすることがあるが、伝送装置で情報を伝クチャでは、仕様変更・追加に強い設計が求められ、４達しやすい信号に変換することで、相手に正確に情報をつの機能ブロックをさらに機能単位で分割するような構伝えることができる。

造化設計が主流であった。

基地局は、移動局との通信を行うための装置である。

一方、最近の開発では、性能や信頼性だけでなく、仕有線網と無線網の末端に位置し、有線・無線間の情報変様変更・追加の容易性ならびに短期開発も重視されるよ

換、移動局の管理、制御を行う。

うになってきており、従来の構造化設計からオブジェク

移動局は、携帯電話、船舶・航空機の局のように、移動する無線局のことである。近くの基地局と通信を行い、情報を発着信する。

ト指向設計に変遷を遂げている。
以降の章では、1990年代に開発したA装置と2000年代に開発したB装置を例に、ソフトウェア・アーキテクチ
ャの変遷もしくは変化について述べる。

1990年

第二世代無線基地局
1993年〜1999年：第二世代無線基地局

運用・保守管理無線制御装置1998年：無線制御装置加入者収容装置
2000年

認証管理

無線管理

第三世代無線基地局
2002年：第三世代無線基地局
2005年：第三世代無線小型基地局
2009年：第三世代無線超小型基地局呼制御

負荷試験装置2006年：負荷試験装置

OS

通信装置
2007年：通信装置

2010年

図１

ハードウェア制御
図３

当社の歩み

3.1

機能ブロック図

A装置

A装置は、１つの装置がカバーするエリア範囲が狭く、収容数も少ない小規模システムである。
アーキテクチャ設計では、過去の実績（流用）も視野
ネットワーク
管理システム

伝送装置に、構造化設計を採用した。
3.1.1

基地局

移動局
（携帯端末）

ソフトウェア構成

A装置のソフトウェア構成は、当該システムが並列処理する機能単位でタスク分割し、リアルタイム性を確保

基地局
保守端末

図２

データベース・位置情報
・加入者情報コア・ネットワーク ・認証情報
・課金情報

システム構成図3．ソフトウェア・アーキテクチャ
無線通信制御装置では、大きくは４つの機能ブロックで構成される。①無線管理、②認証管理、③呼制御、④運用・保守管理である。
90年代の無線通信制御装置のソフトウェアのアーキテする構造とした。
例えば、無線チャネルの割当、閉塞制御、リスタート処理、規制制御、再同期制御等、チャネル全般に関連する機能はチャネル管理タスク、同期確立、電解監視、通信品質監視、同期はずれ制御、チャネル切替、切断、エ
ア側（L2以下）障害監視、通信品質報告等の通信チャネルに関わる機能はリソース管理タスクというように、機能とタスクを紐づけた構成となっている。
本装置のソフトウェア構造のように、機能単位でタスクを分割することのメリットは、機能構造が明確でわかりやすく、設計誤りが見つけやすい点にあるが、システ

MSS技報・Vol.22

36

3.3
スタータ
タスク

LAPB
タスク

デバッグタスク

アイドル
タスク

チャネル管理
タスク

Dch
パケット
タスク

LAPDC
タスクの4+1ビュー（ユースケースビュー、配置ビュー、プロき、規定・設計した。

ユニット間通信タスク

3.3.1

ユースケースビュー

当該ソフトウェアの機能網羅性を観点に、適用するシーケンスのパターンを抽出、それらを全て処理できるア

呼処理タスク（信号変換含む）

棲み分け 着呼制御
タスク
タスク

通信基盤フレームワークのアーキテクチャは、RUP
セスビュー、論理ビュー、実装ビュー）の考え方に基づ

障害監視
タスク

保守制御タスク

リソース管理
タスク

グループ
保守制御
タスク

時刻管理
タスク

通信基盤フレームワーク

ーキテクチャの実現により、設計の妥当性を担保した。

レイヤ 3
タスク

3.3.2

配置ビュー

配置ビューについては、スコープを呼制御のみとした
ため、ソフトウェアと実行環境の対応が1:1となり、今図４回の設計では対象外とした。

A装置ソフトウェア構成図

ムが複雑になると、構造化設計での開発は処理を複雑に3.3.3

プロセスビューしてしまう可能性があり、かつサービス追加に伴う仕様

呼制御プロセスのソフトウェアは１プロセスで動作変更では、影響範囲が多岐に渡り、デグレードの誘発、し、並列処理が必要なクラスについては、スレッドで実開発工数・工期の肥大化等のデメリットを経験した。

装する。スレッドで動作するクラスは、論理ビューで示した論理クラスのうち、アクティブオブジェクトとして3.2

B装置規定されているもの（各パッケージの論理クラス図内でB装置では、「高信頼性」「高性能」の実現要件が条件であり、かつ大規模システムであるため、アーキテクチ
ャ設計においては、従来の構造化設計からオブジェクト指向設計とした。ただし、本装置のようなイベントドリ

act

アクティビティ

プロトコルライブラリ

開始

ブン方式のS/Wでは、オブジェクトは受動的となり、複数イベントが発生した際に時間制約条件が異なるもの

メッセージ受信を限られたCPU能力で、すべて満足できるかどうかを立証することが難しくなる。そこで、アクティブオブジ
ェクトの概念に基づきタスク設計を行った。

デコード(From Unit#1)

デコード(From Unit#2)

デコード(From Unit#3)

デコード(From Unit#4)

また、アーキテクチャ設計を行うにあたり、システムスペック上の観点に加え、開発環境（大規模、短納期）、仕様変更のし易さを考慮して、呼処理の「通信基盤フレユニット毎に並列に処理を実行ームワーク」を構築した。
装置状態管理イベント実行【呼処理フレームワーク】【イベントハンドラ】

呼制御スレッド

呼処理ハンドラ呼状態スレッド

呼処理ハンドラ・・・
制御ハンドラThread Pool

プロトコル
スレッド

MsgQ

制御ハンドラ
・・・
MsgQ

共通OAM

Config
DataMsgQ

呼状態管理

プロトコル
ライブラリ A
プロトコル
ライブラリ B

呼毎に並列に処理を実行

プロトコル
ライブラリ Cプロトコル
ライブラリ Dプロトコル
ライブラリ E

イベント実行イベント実行

終了

終了

イベント送信処理

イベント受信スレッド

SAF
各種プロトコル (SNMP,FTP,TCP,UDP,IP・・・)【共通基盤】

図５37リソース管理ライブラリ

アーキテクチャ構成図

図６

並行性設計のアクティビティ図スレッドと明記したもの）が該当する。スレッドの優先⑷メモリの動的確保は行わない。インスタンスはアプ度については、応答時間の制限よりも、スループットのリケーション起動時に必要数生成しておき、インス重要性を加味し、タイムシェアリングでOSが動的に割タンスが必要な場合は、Factoryクラスから払い出り当てることとした。並行処理を実施する箇所を図６にす。不要になった場合はFactoryクラスへ返却す示す。

る。
⑸

3.3.4

論理ビュー

スレッド間通信では、インスタンスのコピーは行わない。ポインタの受け渡しとする。

機能分割した各機能は論理パッケージとして表現し、論理パッケージ構成は、以下の通り。

論理パッケージ内にはパッケージの機能を構成する主要な論理クラスを規定、また、規定した論理クラス群が、

アプリケーションパッケージ：

ユースケースビューで抽出したユースケースをどのようメインパッケージであり、アプリケーション全体を制に実現するかの検証を行った。全パッケージに共通した御するクラスから構成する。独自のコンフィグレーショ

基本方針は以下のとおりである。

ンファイルの管理や局データへのアクセサクラスを提供⑴

する。

論 理 的 な レ イ ヤ 構 造 と し て、 仕 様 に 特 化 す る
Application Layerと、OSのシステムコール等、仕様に特化しないSystem Layerの2つに分けた。このレイヤ構造により、実行環境に依存する処理は、System Layerで吸収できる。また、ハードウェアの性能に応じたチューニング、実行環境の不具合等

class Application

ProtocolController::
メッセージ中継管理+ インバウンドメッセージ送信()+ アウトバウンドメッセージ送信()+ 初期化()

1

1<<process>>
メインプロセスの影響範囲の絞り込みが容易になる。
⑵

スレッド
Debug::デバッグ管理
1

CPUは効率を最大限に活かすため、アーキテクチ
ャが複雑にならない範囲（保守性とのトレードオフ）

111局データ管理

1+ スレッド処理()

1

1

1
キュー付スレッド
装置状態管理::装置状態管理

設定ファイル管理

でスレッド化した。なお、スレッドは、論理クラス+ メッセージ受信処理()

図でアクティブオブジェクトとして定義する。
⑶

Application Layer内のパッケージ分割については、各パッケージが明確な責務を持ち、疎結合となるよ

図８

アプリケーションパッケージ論理クラス図うにした。このことにより、保守性の向上を図っている。

デバッグパッケージ：
本ソフトウェアの開発者向けのデバッグ機能を制御するクラスから構成する。

close 呼処理

Application Layer
アプリケーション

装置制御処理+ 設定ファイル管理+ メインプロセス+ 局データ管理<< use >><< use >>プロトコルライブラリ

アプリ共通ライブラリパッケージ：

呼制御処理+ アクティブ状態+ アイドル状態+ 初期化状態+ 閉塞状態+ ユニット間メッセージ（対 A ユニット）受信待ち状態+ ユニット間メッセージ（対 B ユニット）受信待ち状態+ アイドル状態ーユニット間 IF+ 装置状態遷移<< use >>+ 局データ管理+ 装置状態管理+ メッセージ中継管理+ 装置制御ーネットワークI/F
ー無線 IFするユーティリティ的なクラス群から構成する。タイマ<< use >><< use >>装置状態管理呼状態管理<< use >>リソース管理+ 呼状態遷移+ 呼状態管理+ 呼制御

Application Layerのパッケージにおいて共通で使用+ リソース管理<< use >>の管理を行うクラスや、受信したイベントの処理に必要なデータを保持するセッションクラスが本パッケージに含まれる。

<< use >><< use >><< use >><< use >>アプリ共通ライブラリ+ イベント情報+ イベント情報ファクトリ+ タイマファクトリ

デバッグ+ デバッグ管理

プロトコルライブラリパッケージ：
他ユニット間との通信、エンコード/デコード等、プロトコル処理に特化したクラスから構成する。他パッケ

System Layer
共通基盤ライブラリ

共通ライブラリ+ メッセージ+ メッセージキュー+ プロセス+ キュー付スレッド+ スレッド+ スレッドプール管理<< use >>+ バッファ管理+ カード間 IF+ ログ管理
+ タスク管理+ タイマー管理

ージは本パッケージを介して他ユニットとの通信を行う。呼を意識しないプロトコル毎に汎用的な処理の責任を持つ。プロトコルのレイヤ、コネクション毎に並行して処理を行うことで、処理性能の向上を図る。

図７

論理パッケージ構成図

MSS技報・Vol.2238

class CallController

class ProtocolController
メッセージ中継管理+ インバウンドメッセージ送信()+ アウトバウンドメッセージ送信()+ 初期化()
1

1

1

System::キュー付スレッド

1

1

1

ネットワークI/F+ スレッド処理()+ スレッド開始()+ デコード()+ エンコード()+ インバウンドメッセージ送信()+ アウトバウンドメッセージ送信()+ デコード()+ インバウンドメッセージ送信()+ アウトバウンドメッセージ送信()

1

1

1

1

1

呼状態管理

呼状態遷移

- スレッドプール：スレッドプール管理+ メッセージ受信処理()+ メッセージポスト()+ 全呼状態遷移スレッド停止()
1

1

1

1 1..*+ スレッド処理()+ イベント設定()

呼制御+ ユニット間メッセージ(対Aユニット)イベント処理()
1 1..* + ユニット間メッセージ(対Bユニット)イベント処理()+ 無線通信リソース割当イベント処理()+ 無線通信接続イベント処理()

1
System::スレッドプール管理

ユニット間IF+ スレッド処理()+ インバウンドメッセージ送信()+ アウトバウンドメッセージ送信()

図９+ スレッド処理()+ スレッド開始()

1

System::スレッド

無線IF

System::スレッド+ メッセージ受信処理()+ メッセージポスト()+ スレッド処理()

1

1+ スレッド実行()+ スレッド停止()

プロトコルライブラリパッケージ論理クラス図

図11

呼状態管理パッケージ論理クラス図

バーヘッドを回避した。

装置状態管理パッケージ：
ユニット状態および運用・保守系のイベント処理を管

なお、呼状態管理クラスは特定の呼ごとの状態管理、理するクラスから構成する。全ての呼の一括処理、呼をおよび状態毎の処理を呼状態遷移オブジェクトとしてス意識しない処理の責任を持つ。

レッドプール管理クラスに渡すことで、当該処理の実行

プロトコルライブラリからのメッセージは、本パッケを委譲する。

ージで終端するか、呼毎の処理であれば呼状態制御パッ呼制御処理パッケージ

ケージに処理を委譲する。

呼としての状態に応じたイベント処理を実行するクラス群から構成する。

class 装置状態管理
スレッド
System::キュー付スレッド

本パッケージのクラスは、ひとつの呼の状態遷移での+ メッセージ受信処理()+ メッセージポスト()+ スレッド処理()

各状態をクラスとし、イベントはクラスのメソッドとなる。
装置制御
装置状態遷移装置状態管理+ メッセージ受信処理()+ イベント実行()
1

1

1

1..*

+ アクティベートイベント処理()+ 呼イベント処理()+ ページングイベント処理()+トランザクション開始イベント処理()

リソース管理パッケージ：
通信リソースを扱うクラス群から構成し、通信リソー

図10

装置状態管理パッケージ論理クラス図

スは、本パッケージで一元管理する。
本パッケージのクラスは、通信を実現するために必要

状態制御処理パッケージ：

な無線区間、有線区間、他ユニット間の物理/論理回線

状態に応じたイベント処理を実行するクラス群から構を制御するための資源を一元管理するクラスである。通成する。StateパターンにおけるConcreteStateに該当し、信路を生成する際、関連するリソース管理オブジェクト

本パッケージのクラスは装置制御クラスから派生する。

種別毎にインスタンスを生成し、各種インスタンスを相ユニットの状態遷移における各状態をクラスとし、イ互管理することで論理的に通信回線の制御を行う。

ベントはクラスのメソッドとなる。
共通基盤ライブラリパッケージ：
呼状態管理パッケージ：
呼の状態を管理するクラスから構成する。特定の呼を対象とした処理の責任を持つ。呼毎の処理を並列化し、共通ソフトウェアをラップするクラスから構成する。
C言語APIで提供される共通ソフトウェアからさらに高水準のC++APIを提供する。

処理性能の効率化を図る。
受信したイベントから呼を識別した上で、処理を実行

共通ライブラリパッケージ：する。当該オブジェクトが存在しない場合は新たにオブ仕様に特化しないスレッドやメッセージ制御、キュージェクトを生成し、呼が解放された時点でオブジェクト制御等の汎用的な機能を提供するクラスから構成する。

を削除する。

システムコールを隠蔽し、高水準のAPIを提供すること

また、オブジェクトを起動時に予め最大数プールしておき、オブジェクトの動的生成に要する処理時間のオー39を目的とする。3.3.5

実装ビュー

本論文で紹介した通信基盤フレームワークも、イベン

本アーキテクチャにおける機能面の検証はプロセスビ

ト処理の並列化、状態遷移・シーケンス制御のフレームューのユースケース実現で行ったが、性能面等の動的な化、システム固有のビジネスロジックを分離しており、検証については、プロトタイプを作成して行った。

上述の課題解決の実現に向け、一歩近づいたものと考え

4. むすびる。
今後は、この通信基盤フレームワークを洗練化させ、「大規模近年の通信制御装置のソフトウェア開発は、他機種、他装置への横展開を推進し、要件から実装まで化」「高信頼性」「高性能」要件に加え、「短工期」、「低コのトレーサビリティ確保、ならびに、開発手法をガイドスト化」が求められ、また、市場投入後のサービス追加ライン化し、ソフトウェア開発における「包括フレームによる仕様追加・変更の容易性が求められ、加えて、短ワーク」として、深化させていく所存である。

工期、大人数での同時並行開発に耐え得るアーキテクチ
ャが必要になる。さらに、他社との競争力強化の観点でも機会損失を防ぐ手立てが必要となり、これら課題を解決するには、• レガシーな構造化設計からオブジェクト指向設計ソフトウェアへの変革• 基盤フレームワーク適用による「方式設計の流用率向上」の実現が不可欠であると考える。

MSS技報・Vol.22

40