リアルタイム通信向けネットワークコンピューティング技術の研究

(1)

リアルタイム通信向け

ネットワークコンピューティング技術の研究

Network Computing Technologies for Real-time Communication Systems

2005 _年 12 _月

早稲田大学大学院情報生産システム研究科

情報生産システム工学専攻知能化ネットワーク研究

山田哲靖

(2)

(3)

目次 i

1 序論

1.1 背景と目的

近年の、特にプロセッサを中心としたコンピュータハードウェア技術の進展は、従来、専用ハードが必要であった領域を汎用コンピュータで代替できる可能性を広げている。また、ハードウェア技術の進展は、ソフトウェアの機能性という点でもメリットをもたらしている。旧式のハードウェアでは、性能やメモリ量の制約から不可能であったソフトウェア処理が、今や可能となっている。例えば、現在では、ソフトウェアのポータビリティを向上させるための仮想ハードウェアインタフェースが利用可能である。

これらの流れは、ソフトウェアの生産性、流通性の点で大きなメリットをもたらすものである。ソフトウェアがさらにパッケージ化、プラットフォーム非依存化が進められることで、ソフトウェア開発リソースはサービス高度化のために振り向けられることになり、高度情報化社会の発展を加速させる方向に向かうであろう。

一方、従来の交換機に代表されるようなリアルタイム通信システムにおいては、専用ハードと専用OSをベースとしたシステム構築により、リアルタイム性、高信頼性を実現してきた。このようなミッションクリティカルなマス向け通信システムの領域においては、ソフトウェアの実行環境を汎用コンピュータに置き換えただけでは、要求品質を満たすことができない。そのため、リアルタイム性、高信頼性を、汎用コンピュータ上で実現する技術が新たに求められる。

このような背景の下で、本論文は、ミッションクリティカルなマス向け通信システムに対し、汎用コンピュータ、汎用OSを適用した上で、従来並のリアルタイム性と高信頼性を実現するソフトウェア技術を明らかにしている。具体的には、インタオペラビリティを確保しつつ、リアルタイムかつ高信頼な分散オブジェクト間通信を実現するソフトウェア分散機構の実現方法を明らかにする

(課題1)。ソフトウェアの階層構造や、アプリケーションの第三者による開発に対応し、階層間の独

立性を高めた上で高信頼化を実現する技術を明らかにする(課題2)。ノンストップでプログラムを動かし続けるためにあらゆるバグフィックスをシステム運用中に行うための高信頼化技術について明らかにする(課題3)。最後に、マルチプラットフォーム環境におけるソフトウェア性能の向上技術について明らかにする(課題4)。

さらに、本論文では、ソフトウェア工学的観点から、言語、OSといったソフトウェア開発環境、

実行環境についても現実のものに即した実現手法を提案する。そして、プロトタイプによる評価結果を併せて報告することで、提案するソフトウェア技術の実現性と有効性を明らかにする。これにより、提案技術が、今後のリアルタイム通信システムの中核技術として利用可能な実用的技術であることを示す。

1.2 要求条件と課題

ミッションクリティカルなマス向け通信システムに対し、汎用コンピュータ、汎用OSを適用した上で、従来並みのリアルタイム性と高信頼性を実現するために、通信ソフトウェアに要求される条

(10)

件と課題について本節で述べる。

(1) 交換機においては、専用の通信機構により、分散ハードウェア構成に対応してきた。しかし、

汎用コンピュータを組み合わせた分散構成においては、インタオペラビリティを確保しつつ、

リアルタイムかつ高信頼な分散オブジェクト間通信技術が必要である。

(2) 交換機においては、専用的なソフトの作り込みにより、呼救済等の高信頼化機能を具備してきた。しかし、ソフトウェアの階層構造や、アプリケーションの第三者による開発などを考えると、階層間の独立性を高めた上で高信頼化を実現する技術が必要である。

(3) リアルタイム通信システムにおいては、ノンストップでプログラムを動かし続ける必要がある。そのためにはあらゆるバグフィックスをシステム運用中に行う必要がある。しかしながら、

現状の技術では予め修正が予想される箇所以外のバグフィックスのためにはシステムをリブートする必要がある。従って、あらゆる部分のバグフィックスをシステム運用中に行える技術が必要である。

(4) ハードの変化があっても過去に開発したソフトウェアが使用可能であることが望まれる。そのためには、Javaのような、ハードウェアを高度に仮想化するマルチプラットフォームなソフト環境が必要である。しかし、仮想化による性能低下は、超多重処理を行なうリアルタイム通信システムにおいては致命的である。従って、マルチプラットフォーム環境におけるソフトウェア性能の向上技術が必要である。

上記のような要求条件を満足するためには、以下に示す5つの通信ソフトウェア技術に関する課題を検討しなければならない。

課題1 リアルタイム分散機構の実現技術の明確化

課題2 オープンなソフトウェア構造におけるサービス継続技術の明確化課題3 マルチプラットフォームでの高信頼化技術の明確化

課題4 マルチプラットフォームでのソフトリアルタイム技術の明確化

1.3 論文の構成と各章の概要

本論文では、汎用コンピュータをベースとしたリアルタイム通信向けネットワークコンピューティング技術に関する研究成果をまとめたものである。本研究の全体構成を以下に示す。

1.3.1 第2章の概要

リアルタイム通信システムのうち、もっとも要求条件の厳しい部類である交換システムを例に、ソフトウェアの観点から高性能・高信頼性の実現技術について、これまでの達成点を示している。リアルタイム通信システムにおけるソフトウェア技術については、これまで数多くの研究がなされてき

(11)

1.3. 論文の構成と各章の概要 3 ている。例えば、ソフトウェア生産性向上のためにはオブジェクト指向技術を採り入れたり、サービス無中断でのバグ修正のための機構を専用で開発したりしてきた。本論文では、リアルタイム通信ソフトウェアへの要求条件を整理し、その実現のためにソフトウェア階層の各部において適用されている技術をまとめるとともに、従来技術の到達点として、呼処理性能、呼救済処理、生産性について総括する。

従来技術は専用ハードウェアの機能を最大限に活用してリアルタイムかつ高信頼なシステムを作り上げることを目的としたものであった。本章で総括するように、これまでこれまでに提案されてきたソフトウェア技術では汎用コンピュータベースのリアルタイム通信システム実現という要求条件に応えることが出来ないことを明らかにするとともに、第1章で述べた課題の妥当性を示す。

1.3.2 第3章の概要

ここでは、課題1に関し、リアルタイム通信システムに適用可能なソフトウェア分散機構の実現手法について明らかにする。リアルタイム性を要求されるシステムにおいて、汎用の分散機構を利用する技術として、高速オブジェクト間通信のための機構を提案する。具体的には、リアルタイム通信システムの機能要素を分散オブジェクトにマッピングする方法、分散構成を隠蔽する通信機構の実現方法、リアルタイム通信のための処理負荷低減技術について明らかにしている。また、実運用のために必要な機構として、システムの拡張技術、サービス救済のための機構について提案する。

さらに、性能条件の厳しいプロトコルの例として共通線(SS7)処理を題材とした適用例と性能評価結果を提示することで、提案技術の実現性と有効性を示す。

従来、リアルタイム性能を要求されるオブジェクト間通信にインタオペラビリティのある機構を適用した例はなく、筆者が世界で初めて提案したものである。また、ここで提案するオブジェクト間通信技術は、アプリケーションレベルの通信だけではなく、性能条件の厳しいプロトコル処理にも適用可能であることから、広い適用先が期待できる。

1.3.3 第4章の概要

ここでは、課題2に関し、汎用コンピュータをベースとし、ベアラ制御と通信制御を分離したアーキテクチャを実現するための技術を明確化する。このような、新アーキテクチャにおいて要求されるオープンなソフトウェア構造と、その実現技術を明確化する。特に、階層化ソフトウェア構造を採った場合でも障害発生時のサービス継続性が実現可能な手法を明確化する。

従来、このようなオープンな構造のソフトウェアにおいては、上位アプリケーションのサービス継続性は考慮されていない。ここで提案するサービス継続技術は、筆者が初めて提案したものである。また、この技術は、さまざまなリアルタイム通信サービスに幅広く活用できる。

1.3.4 第5章の概要

ここでは、課題3に関し、マルチプラットフォーム環境であるJavaにおけるノンストップでのソフトウェアメンテナンスを可能とするオンラインプラグイン技術について明確化する。Javaに代表されるようなマルチプラットフォーム環境は、ソフトウェアの開発・維持管理コストの大幅削減の

(12)

ために必須な技術であり、今後とも適用領域を広げていくであろう。しかしながら、通信システムの領域にこのような技術を適用するためには、ノンストップでの運用に耐える高信頼性を実現する必要がある。ここで提案するオンラインプラグイン技術は、Javaプログラムを完全に無停止のままメソッドを入れ替えるものである。

従来、Javaにおけるメソッド入れ替えは提案されていたが、デバッグ用途のみであり、オンラインコンパイラに対応しておらず性能が著しく劣化するものであった。また、異常発生時のロールバックができないことから実サービス向けにはてきようできていなかった。ここで提案するJavaオンラインプラグイン機構は、実サービス向けのソフトウェアメンテナンス機能としては筆者が初めて提案したものである。また、本技術は通信システムのみならず、ノンストップ性が要求されるデータベースサーバ等、幅広い分野で利用可能である。

1.3.5 第6章の概要

ここでは、課題4に関し、マルチプラットフォームを実現するための技術であるJava言語について、リアルタイム性能向上技術として、動的コード配置技術と、動的データ配置技術を提案し、その実現手法を提示する。具体的には、次の2つの技術を提案している。実行時のプロファイルデータに基づき、メソッドをメモリ上に最適配置を行なうことでインストラクションキャッシュのヒット率を向上させる動的コード配置技術、および、生成するオブジェクトを高頻度アクセスヒープと低頻度アクセスヒープに分離して配置することによりデータキャッシュのヒット率を向上させる動的データ配置技術である。性能評価結果により本技術の有効性を示している。即ち、従来のマルチプラットフォーム環境上で実現できなかった超多重処理を効率よく処理するソフトリアルタイム性を実現できることを明らかにしている。

ここで提案する2つの技術は、それぞれ単独でも利用できるが、組み合わせての実施も可能である。また、本技術における最適化技術は、大規模な通信システムはもちろん、リソースの限られている組み込み系のシステムにも応用可能である。

1.3.6 第7章の概要

本論文では、リアルタイム通信システムに適用可能な、ソフトウェア分散機構、オープンなソフトウェア構造でのサービス継続技術、マルチプラットフォームでの高信頼化技術、マルチプラットフォームでのソフトリアルタイム技術の4つを提案し、これらの提案技術の実装および評価を通じて、それらの実現性を検証した結果について、総括する。さらに、本研究が汎用コンピュータをベースとしたリアルタイム通信向けネットワークコンピューティング技術の構築に果たす役割を述べる。

(13)

5

2 交換システムにおけるソフトウェア技術

2.1 要求条件

電話サービスは、社会のライフライン的な役割を担っており、電話サービスを提供するネットワーク機器のシステム障害の影響は甚大なものとなる。

さらに、通信システムの全国展開を考えると、さまざまなトラヒック量に対応できるものでなければならない。

上記の要求条件から、高信頼、高拡張性、高生産性、ソフトウェアの維持管理コストが低く、サービス機能追加が迅速に行なえる、高性能なリアルタイム通信システムが求められる。

ここで、要求条件を整理する。

• 高生産性と低維持管理コスト

サービス追加や変更が頻繁に発生しても、ソフトウェアの高生産性と低維持管理コストを維持する必要がある。

• 拡張性

システムアーキテクチャは、小規模から大規模までのレンジをカバーするものでなければならない。

• リアルタイム処理

一般的な構成のCPUを用ながらも、数千アーランにおよぶ呼処理をこなす性能が必要である。

• 高信頼

仮にシステムがダウンしても、安定状態の呼は、コールデータと呼ばれる呼状態を保存したメモリの内容から復旧できる必要がある。

(14)

筆者は、上記の要求を満たすシステムとして、アナログPOTS、ナローバンドISDN、ATM(ブロードバンドISDN含む)、IN等のリアルタイム通信システムを開発に携わってきた。

上記のシステムは、リアルタイムオペレーティングシステム(リアルタイムOS)を使用し、階層化されたソフトウェア構造を採っている[9, 16]。

まずは、リアルタイムソフトウェア構造について見ていく。キー技術としては、レイヤ階層を採ったソフトウェア構造 [15, 23, 24] と、アプリケーション実行環境であるCHILLランタイムルーチン [25, 26]である。

2.2 レイヤ階層ソフトウェア構造

レイヤ階層ソフトウェア構造(layerd hierarchical software structure)は、良論理構造の通信ソフトウェアを開発するために必要な技術である。

レイヤ構造は、ソフトウェアを各レイヤ毎に独立に開発可能とし、最終的にはソフトウェア生産性を高めることになる[7]。

2.2.1 レイヤ構造

本技術におけるレイヤ構造は、サービスレイヤ、リソースレイヤ、そして実行制御レイヤの3ソフトウェアレイヤからなる(図 1) [12, 14, 27–33]。

2.2.2 サービスレイヤ

サービスレイヤ(service layer)は、サービスロジックを実行する。また、サービスロジック実行に必要な、サービス分析の機能も具備する。

2.2.3 リソースレイヤ

リソースレイヤ(resource layer)は、サービス記述のためのS2インタフェースを提供する。S2インタフェースによって、ハードウェアやシステム依存の情報を隠蔽することで、サービスレイヤにおける、メディア種別に依存しないソフトウェア開発を可能とする。

2.2.4 実行制御

実行制御レイヤ(execution control layer)は、S1インタフェースを提供する。S1インタフェースは、プロセッサや通信系ハードの詳細を隠蔽し仮想化する。ハードウェアの仮想化により、プロセッサや通信系ハードの進化に応じたハードウェア変更を可能とする。

ここではリアルタイムOSとしてCTRONカーネル[33–36]を適用した場合の検討を示す。

信頼性と生産性向上のため、CHILLランタイムルーチン(CHILL RTR)をCTRONカーネル上に実装した。CHILL RTRは、アプリケーションの実行制御を行なうものであり、アプリケーションに対し、CTRONカーネルインタフェースを隠蔽する。

(15)

2.2. レイヤ階層ソフトウェア構造 7

Services and C al l C o nt ro l

R eso u rces and C o nnect io n C o nt ro l

V irt u al M ach ine N et w o rk / N o de/ M o du l e W ide

C o nt ro l and A ddress Sp ace

N o de/ M o du l e W ide C o nt ro l and A ddress Sp ace

M o du l e W ide C o nt ro l and A ddress Sp ace

O A & M So f t w are

O A & M So f t w are Service L ay er

R eso u rce L ay er

E x ecu t io n C o nt ro l L ay er S2

S1

図 1: 交換機の論理的なレイヤ

(16)

CHILL RTRはCTRONカーネルに加え、以下の機能を提供する。

(1) 並列オブジェクトが同一論理メモリ空間に存在する場合、その間でのメッセージ通信をスタック間の直接コピーにて実現する。直接コピー方式により、中間バッファへのコピーオーバヘッドを削減する。

(2) システムが再起動した場合でも、プロセスの識別子(プロセスID)は変更しない。プロセスID の保持機能により、旧プロセスIDをそのまま使った高速な呼救済処理が可能となる。

(3) プロセッサ間通信機能を提供する。同一プロセッサ上のプロセスにメッセージを送るのと、他プロセッサ上のプロセスにメッセージを送るのが完全に同一手順で行なえる。この機能により、送信先プロセスの厳密な位置をアプリケーションが知る必要がなくなる。

加えて、他プロセッサが再起動して復旧した後でも、それを意識せずにメッセージを送ることができる。

2.3 通信システムモデル

論理的な通信システムモデルについてここで説明する。

論理的な通信システム構成のモデルを、上記のソフトウェア構造に直接マップした(図2)。

以降で各レイヤに含まれるコンポーネントについて解説する。

2.4 サービスレイヤ

2.4.1 サービスレイヤの機能

サービスレイヤ(service layer)は、ネットワークワイドなマルチメディア呼制御環境を提供する。

さまざまな呼処理サービスを実現するための、高レベルの機能とサービス部品がサービスレイヤに含まれる。例えば、POTS呼制御サービスシナリオや呼転送サービスシナリオ等を提供する。

サービスレイヤについては、複雑かつ革新的な呼処理アーキテクチャを自由に設計できることが望まれる。また、ソフトウェア開発を簡易化する環境も必要である。

2.4.2 サービスレイヤののハードウェア非依存性

サービスレイヤはハードウェア仕様に非依存であり、ハードウェア仕様とそれぞれ独立に進化可能である。サービスレイヤの内部のソフトウェアコンポーネント間と、サービスレイヤ– リソースレイヤ間については、論理IDやオブジェクトIDにより参照しあっている。従って、物理リソースを示す物理IDや、ハードウェアの詳細を表す情報は、本レイヤには含まれない。

(17)

2.4. サービスレイヤ 9

Subscriber D atabase

Subscriber L ine Sp eech P ath To ne G enerato r Serv ice C ircuit Virtual Trunk

[ C aller] [ C allee]

E nh anced Serv ice Analy z er

Basic Serv ice Analy z er

Serv ice(1 )Serv ice(1 )Serv ice (1 ) Serv ice(1 )Serv ice(1 )Serv ice (1 )

Serv ice(1 )Serv ice(1 )C all (1 ) (Serv er) Serv ice(1 )Serv ice(1 )C all (1 )

(Serv er) Serv ice(1 )Serv ice(1 )C all (m + 1 ) (Serv er) Serv ice(1 )Serv ice(1 )C all (m + 1 )

(Serv er)

(m ) (n)

(n)

F ree d ial C red it E nh anced Serv ice Scenario

P O TS O ut-g o ing P o lice call Basic Serv ice Scenario

C o nf erence call

Serv ice(1 )A-SubscriberServ ice(1 ) L ine (1 ) Serv ice(1 )A-SubscriberServ ice(1 )

L ine (1 ) (n)

Serv ice(1 )Serv ice(1 )I SD N - Subscriber

L ine (1 ) Serv ice(1 )Serv ice(1 )I SD N - Subscriber

L ine (1 ) (n)

Serv ice(1 )Serv ice(1 )Sp eech P ath (1 ) Serv ice(1 )Serv ice(1 )Sp eech P ath (1 )

(n)

Serv ice(1 )Serv ice(1 )To ne (1 ) Serv ice(1 )Serv ice(1 )To ne (1 )

(n)

Serv ice(1 )Serv ice(1 )Serv ice C ircuit (1 ) Serv ice(1 )Serv ice(1 )Serv ice

C ircuit (1 ) (n)

Serv ice(1 )Serv ice(1 )M ulti- F req uency O G T (1 ) Serv ice(1 )Serv ice(1 )M ulti- F req uency O G T (1 )

(n)

Serv ice(1 )Serv ice(1 ) B-C h annel (1 ) Serv ice(1 )Serv ice(1 ) B-C h annel (1 )

(n)

C H I L L run-tim e ro utine (R TR ) K ernel

(Sch ed uling , task co ntro l, m em o ry m anag em ent, etc. ) I O C S D riv ers Serv ice

L ay er

R eso urce L ay er

E x ecutio n C o ntro l L ay er (H ard w are

L ay er) H ard w are

S2

S1

図2: 交換機の論理モデル

(18)

2.4.3 S2インタフェース

S2インタフェースは、通信サービスを提供するために、サービスレイヤからS2を通じたメッセージによって制御可能なリソースが何であるかを定義したものである。

S2インタフェースにおいては、物理リソースを示す物理IDや、ハードウェアの詳細を表す情報は現れない。

2.4.4 サービスレイヤのオブジェクトモデル

サービスレイヤモデルは、caller(発側オブジェクト)とcallee(着側オブジェクト)の存在により特徴づけられる。

サービスはcallerとcallee間の通信により実現される。callerとcalleeは、サービス種別に応じたサービスシナリオを利用しサービスを実行する。サービスシナリオは、加入者種別や加入者のリクエストに応じ、それぞれのサービスを行なうための手続きのセットである。

ハードウェアモジュール内やハードモジュール間の基本的なサービスは、以下のような手順で実行される。

呼出中や通信中のフェーズにおいて、callerはPOTS入接続シナリオ(POTS in-coming schenario) に関連づけられ、calleeは、POTS出接続シナリオ(POTS out-going scenario)に関連づけられる。

新たなイベント、例えば第三者によるフッキングの割り込みがcallerに通知されると、callerは新たなサービスシナリオと関連づけられる。このように、callerとcalleeは呼処理の実行部品に対して、サービス実行環境を提供する。

2.5 リソースレイヤ

2.5.1 リソースレイヤの機能

リソースレイヤ(resource layer)は、サービスレイヤのサーバとして機能する。リソースレイヤは、単一メディアの呼処理と、ハードウェアリソースの抽象化ビューのための基本的なビルディングブロックからなっている。例えば、コネクション制御(connection control)、各種回線や各種トランク種別の制御等をサービスレイヤに提供する。また、リソース管理の機能を提供する。

付加サービス的な回線選択機能、例えば加入者回線グループ選択(パイロットダイレクトナンバ) や、トランクグループ選択はリソース階層ではなくサービスレイヤで行なわれる。リソース階層で提供するのはシングルエンドの機能である。複数端末接続の機能は、サービスレイヤにおいて、リソースレイヤのシングルエンド機能を利用して提供される。リソースレイヤは、新しい回線やトランク種別、一般的なハードウェアの進化をカバーし、将来のサービス機能の開発のために、比較的に不変な基盤を提供する。

(19)

2.6. 実行制御レイヤ 11

2.5.2 リソースレイヤの構造

リソースレイヤのソフトウェアは、ビルディングブロック構成を想定した設計がなされている。例えば、複数のハードウェアモジュールによって構成された通信システムにおいて、モジュール間に渡る制御や仮想的なアドレス空間をカバーするものである。

この構成は、通信リソース(例えば、共通線機能、MFトランク等)がノード内の別のハードウェアモジュールモジュールに存在するような場合にも適用できる。

2.5.3 サービスレイヤとの共通的機能

サービスレイヤとリソースレイヤは、いくつかの共通的な機能を持つ。それぞれのレイヤでは、

レイヤ内の各部を管理、保守(OA&M)するための半自立的なオペレーション機能を持つ。例えば、

リソースレイヤの中の保守運用機能は、通信ハードを保守するためのものである。サービスレイヤの保守運用機能は、さまざまな呼処理機能(例えばダイアル数字翻訳機能など)が正しく動作しているかどうかを監視する。

しかしながら、通信システム全体の高レベルでの機能を維持するために、リソースレイヤとサービスレイヤの双方を統括するシステム全体としてのOA&M機能が必要である。

2.6 実行制御レイヤ

実行制御レイヤ(execution control layer)にはリアルタイムOSが必要である。リアルタイムOS

としてCTRONカーネルを採用した。しかしながら、通信システムにCTRONカーネルだけを採用

したのでは、次のような問題がある。

(1) システムの部分的な初期設定と、メモリ保存による呼救済機能のための標準的なインタフェースが用意されていない。

こういったインタフェースの追加は、CTRON仕様にアーキテクチャ依存の機能(システムコール)を追加することになる。

しかし、アーキテクチャ依存の追加システムコールを使用したアプリケーションプログラムはポータブルでなくなり、別のアーキテクチャ依存のシステムコールを持った他のOSへ移植できなくなる。

(2) CTRONのタスク同期と通信機能は論理メモリ空間の異なるタスク間のために設計されている。

この設計は汎用的ではあるが、処理負荷は軽くはない。共通な論理メモリ空間内で動作している並列オブジェクト間の通信手段としては不適当である。

(3) CTRONカーネルは、ハードウェアモジュール間での軽量なプロセッサ間通信機構を用意して

いない。

(20)

高信頼なリアルタイム通信システムにおいては、上記の問題を解決する必要がある。

問題解決のため、CHILLランタイムルーチン(CHILL RTR)の実装を行なった。

CHILL RTRは、CHILL言語仕様に準拠しながら、通信システムに適合た初期設定機能と呼救済

機能を提供するものである。

2.6.1 CHILLランタイムルーチンによる実行制御

CHILL RTRは、CTRONカーネル機能を利用して、CHILLプロセスの実行環境を提供する。

CHILL RTRは、CHILLプロセスをCTRONタスクにマッピングする(図3)。

Supporting CHILL (CCITT Z.200) by RTR

Conc urrent Ex ec ution by O pera ting Sys tem CHILL

P roc es s CHILL

P roc es s CHILL P roc es s

CTRO N Ta s k CTRO N

Ta s k CTRO N

Ta s k RTR

CHILL Environment

CTRO N

Environment

図3: CHILL RTRによる実行制御

CHILL RTRは、CHILlプロセスそれぞれに対応するPCB(process control block)、シグナルキュー、メモリプールを管理する。PCBにはそれぞれ、CTRONタスクIDが含まれる。CHILL RTRはCHILLプロセスIDをCTRONタスクIDに変換および逆変換を行なう(図 4)。その他の RTRインタフェースコールはCTRONシステムコールにマッピングされる。

2.6.2 シグナル通信機構

ハードウェアモジュール間のプロセッサ間通信のために、シグナル通信機構を拡張した(図5)。

この機構は、高信頼かつ高速なモジュール間メッセージ通信機構であるMET(message transferring

equipment)を使用して、シグナルを他モジュールにあるプロセスに届ける機構である。

加えて、ユーザプログラムはこの機能を用いて、同一のソフトウェアインタフェース(CHILL RTR インタフェース)によりモジュール内のプロセス間シグナル通信も可能である。送信先プロセスID

(21)

2.6. 実行制御レイヤ 13

PCB no.

Proc ess ID Proc ess na m e

: T a sk ID

:

User ID = PCB no.

: PCB

Inst a nc e p ri m i t i v e

CT R O N t a sk c ont rol b l oc k

( T CB) R T R i nt erf a c e CT R O N i nt erf a c e

h el d b y

CH IL L u ser p rog ra m h el d b y

R T R h el d b y

CT R O N

図 4: CHILLプロセスとCTRONタスクの関係

SEND a _ s i g n a l

TO p r o c e s s # 1 R EC EI V E

C H I L L

P r o c e s s # 0 C H I L L

P r o c e s s # 1

l o c a t i o n i n f o . R TR

l o c a t i o n i n f o . M R TR

E T i / f

M E T

M E i / f T M E

T

Mo d u l e # j Mo d u l e # i

V i r t u a l R TR ( v i s i b l e t o C H I L L u s e r p r o g r a m )

MET: Me s s a g e Tr a n s f e r De v i c e ( I n t e r m o d u l e c o m m u n i c a t i o n u n i t )

図5: プロセッサ間でのシグナリング

(22)

の内容により通信先プロセスが存在するモジュールじ動的に判別されるため、ユーザプログラムがシグナルを送ろうとするプロセスの位置を隠蔽することができる。

シグナル通信のインタフェースは以下のものを含む。

(1) シグナル登録

• このルーチンは、シグナルに対する論理的なシグナル番号を設定する。モジュール間のシグナル通信において、シグナル名はCHILl RTRによって論理シグナル番号に変換される。

(2) サーバ登録

• このルーチンは、プロセスに対する論理的なサーバ番号を設定する。

(3) サーバ参照

• このルーチンは、論理サーバ番号をプロセス番号に変換する。

この機構は、いくつかのハードウェアモジュールに配置されたプログラムを、一つのモジュールに縮退して配置することを可能とする。加えて、同じ手順にて、別論理メモリ空間(非共有メモリ空間)の間でのプロセス間メッセージ通信を可能とする。

2.7 呼救済

信頼性の向上のため、CHILL RTRは呼救済のための機能を提供する。システム障害の際に、通話中であったサービスは、システム復旧後もそのまま継続される。

2.7.1 コールデータ

コールデータ(call data)とは、呼毎の情報を記録したもので、呼救済処理や呼処理のために利用される。コールデータはメモリ空間の連続域に配置される。それは、コールデータ自体を容易に保護するためと、コールデータ以外のデータをまとめて消去できるためである。

2.7.2 コールデータを元にした呼救済処理

システム障害が発生すると、コールデータ以外のデータは初期化される。呼状態は、コールデータを元に復元される。この時、接続中の通話バスはハードウェア的に保持されたままとなっている。

しかし、異常だったり不完全な呼がコールデータに含まれるかも知れない。これは、障害がコールデータに影響を与えたり、逆にコールデータの異常により障害が引き起こされた可能性があるからである。

従って、障害から復旧する再起動処理の間に、異常と思われるコールデータは検出し、消去する必要がある。

(23)

2.7. 呼救済 15

2.7.3 コールデータとしてのプロセスID

CHILL RTRのlプロセスIDはコールデータとして扱われる。CTRONカーネル中のタスクは全

て再起動処理中に消去される。呼処理に必要なタスクはその後に再生成される。

再起動処理において、プロセスIDは復旧時間を短縮するために、障害前と同じに保たれる。この理由は、コールデータ内のプロセスIDを更新するのは複雑な処理が必要であるからである。CHILl RTRは、変換機能により、プロセスIDを新たなタスクIDと関連づける。

2.7.4 救済呼の判定論理

救済する呼を選択するには2つの基準がある。

(1) 安定状態(通話中や呼出中など)ではない呼は救済しない(削除される)。

(2) コールデータ間での関係をチェックすることにより、不整合のあるコールデータに対応する呼は救済しない(削除される)。

2.7.5 タスクの再生成とプロセスIDの保持

プロセスIDはコールデータ中に保存されている。システム再起動処理中にカーネル内の全てのタスクが消去されても、呼処理に必要なタスク(呼切断や付加サービス等)は復元される。この処理において、呼救済処理の短縮のためプロセスIDは変更されない。この理由は、コールデータ内の各所に保存されているプロセスIDを新たなものに変換する処理が複雑なためである。CHILL RTR はプロセスIDを新たなタスクIDと対応づける機能を持つ。

2.7.6 シグナルの保持

各プロセスに対応したシグナルキューに保存されたシグナルは、再起動処理の間も保持することが可能である。しかしながら、システムの障害がシグナルによって引き起こされた可能性もあるため、異常なプロセスに到着していたシグナルは廃棄することとした。呼処理は、シグナルが廃棄されても、タイムアウトや新たなシグナルの到着により処理を継続できるように設計する必要がある。

2.7.7 異常プロセスの消去

再起動処理の後、いくつかの無効なプロセス(復元されたタスクと関連づけされていない)が残るかも知れない。そのようなプロセスのPCBは消去される。

(24)

2.7.8 呼救済処理のまとめ

呼救済処理は次のようにまとめられる(図 6)。

(1) コールデータ以外のデータ領域は全て消去する。例えば、

• アプリケーションのワークデータ

• カーネル内のデータ(タスクやメモリプールなど)

(2) 呼を救済するかどうか、コールデータの内容を用いて判断する

• 呼が安定状態でなければ救済の対象とはしない

• コールデータ内で一貫性のない呼は救済対象とはしない (3) プロセスの復元

• PCBは保存され、新たに作られたタスクと関連づけられる (4) 異常プロセスの消去

• 新たなタスクと関連づけられなかったプロセスのPCBとシグナルキュー消去される

2.8 到達点

上記技術を適用した通信システムにおける達成点を以下にまとめる。

2.8.1 呼処理性能

1コールの呼処理ステップは、さほど増加しない。従来の非オブジェクト指向のソフト構造より若干増加しているものの、直列オブジェクトやコンパイル時のメソッドバインディング等の工夫により、オーバヘッドは抑えられている。

CHILL RTRを適用したオーバヘッドは4000アーラン級の通信システムへの適用にあたっては問

題とならなかった。

2.8.2 呼救済処理

サービス受け付け中断時間は、障害検出時間、ハードウェア初期化時間、ソフトウェア呼救済処理時間の合計である。サービス受け付け中断時間の目標値は従来の通信システムと同様の30秒以下と設定した。

今回のシステムにおいて、4000アーランの通信システムにおいて、呼救済時間は12秒であった。

この呼救済時間に障害検出とハードウェア初期化時間を加えても上記の目標は達成できる。

さらに呼の救済判定処理のさらなるチューニングにより、より時間が短縮される可能性もある。

CTRONカーネルだけを用いた場合と比較し、CHILL RTRの適用により呼救済時間が短縮され

た。CTRON上で同等の処理を行なった場合、より処理時間が必要であることが分かった。

(25)

2.8. 到達点 17

Figure 7: Call Saving Processing

Service L ay er

&

R esource L ay er ( a)

st at e= t alk ing

PI D = # 1 st at e= unst ab le

PI D = # 0 st at e= ringing

PI D = # 2 . . . . st at e= t alk ing

PI D = # 2 . . . . T I D = 8 2 5 6 T I D = 8 5 1 2 T I D = 8 0 0 0 . . . . T I D = 8 2 5 6 T I D = 8 5 1 2 T I D = 8 0 0 0 . . . .

U I D = # 2 U I D = # 0 U I D = # 1 . . . .

( b )

( c)

R T R

CT R O N Call D at a

N ot Call D at a 8 0 0 0 8 2 5 6 8 5 1 2

# 0 # 1 # 2

PI D ->

<- T I D ( m em ory ad d ress) PCB

T CB

* 0 * 1 * 2

Call Processing

Service L ay er

&

R esource L ay er st at e= t alk ing

PI D = # 2 . . . .

T I D = T I D = T I D = . . . .

cleared cleared cleared . . . .

R T R

N ot Call D at a 8 0 0 0 8 2 5 6 8 5 1 2

# 0 # 1 # 2

PI D ->

T CB

* 0 * 1 * 2

J ud ging & R est rat ion of Processes

Service L ay er

&

R esource L ay er st at e= t alk ing

PI D = # 1 cleared st at e= ringing

PI D = # 2 . . . .

cleared T I D = 8 0 0 0 T I D = 8 2 5 6 . . . .

U I D = # 1 U I D = # 2 . . . .

R T R

N ot Call D at a 8 0 0 0 8 2 5 6 8 5 1 2

# 0 # 1 # 2

PI D ->

T CB

* 0 * 1 * 2

D elet ion of I nvalid Processes

Y E S N O Y E S <- saved

cleared

図 6: 呼救済処理

(26)

2.8.3 生産性

CHILl RTRの適用と、オブジェクト指向設計の適用により、CTRONシステムコールを直接利用

した場合と比較して、プログラムコード規模が削減され、プログラム可読性が向上した。

サービスレイヤの生産性は、従来のシステムより高い。一方、リソースレイヤの生産性は従来と変わらなかった。

機能拡張は主にサービスレイヤに集中するため、トータルな生産性は初期開発時でも高いが、機能追加時により高くなる。

従って、本ソフトウェア構造の適用により、高い生産性が実現できた。[17]。

2.9 残課題

2.9.1 汎用分散機構

通信システムのスケーラビリティを確保するためには分散処理の考え方を取り入れる必要がある。

さらに機能拡張性を考慮すると、分散処理機構としてはある程度広く使われている汎用な技術を用いるのが望ましい。従来の通信システムは、専用OSや専用ミドルウェアによる分散通信は実現できているが、ヘテロジニアスな環境で利用できる汎用な分散機構は適用できていない。

2.9.2 オープンなAPI

複数メディア種別に対して統合的にサービスを提供するためには、メディア種別に非依存となるよう抽象化されたAPIを規定する必要がある。このような抽象化APIを、リアルタイムかつ高信頼に実現したシステムはこれまでに存在していない。

2.9.3 マルチプラットフォームでの信頼性

Javaに代表されるようなマルチプラットフォーム環境は、ソフトウェアの開発・維持管理コストの大幅削減のために必須な技術であり、今後とも適用領域を広げていくべきである。しかしながら、

通信システムの領域にこのような技術を適用するためには、ノンストップでの運用に耐える高信頼性が実現できていない。

2.9.4 マルチプラットフォームでのリアルタイム性

超多重処理を効率よくこなすというソフトリアルタイム性は、特に大規模な通信システムにおいては最重要な要求条件である。このようなソフトリアルタイム性は、Javaのようなマルチプラットフォーム環境上では実現できていない。

(27)

2.10. 結言 19

2.10 結言

通信システムへの階層化ソフト構造とオブジェクト指向の適用は、高信頼性と高生産性を実現する。

しかし、第2.9章で示した4つの課題についてはこれまでの技術では達成されていない。これら残課題について、以降の章にて解決方法を提案する。

(28)

3 リアルタイム分散機構の実現技術

3.1 研究の背景

リアルタイム通信システムは、スケーラブルであるだけではなく、キャリアが新たなネットワークサービスを容易かつ迅速に提供できなければならない。そのためには、ソフトウェアを効率的に開発でき、かつ、安価に維持できることを可能にする必要がある。

また、新たな通信システムが追加されたり、サービス機能を追加変更した場合でも、ノンストップでのサービス提供が求められる。

さらに、システムが再起動したとしても、実行中サービスは継続されなければならない。

スケーラビリティとサービスの迅速な提供を両立させる一つの有効なアプローチとして、オブジェクト指向設計と分散OSの適用が考えられる[10, 23]。

そして、一つのソフトウェアファイルがあらゆるシステム容量、あらゆるシステムアーキテクチャに適用可能なような、オブジェクトが通信システムの中に柔軟に配置可能なソフトウェア構造を確立する必要がある。

さらに、オブジェクトが追加や移動した場合においても、サービスの実行には影響を与えてはならない。

前述の点を考慮して、NOSES(Non-stop Service Enhanceable Software) [8, 11, 15]において開発したプラットフォームを、CORBA [37] を用いた分散コンピューティング環境に適合するように機能追加を行なった。

なぜならば、CORBAは広く使われ、一般的なオペレーティングシステム(OS)上で動作することから、次世代システムの分散オブジェクト環境として適切であると考えたからである。

CORBAオブジェクト指向のフレームワークを、リアルタイム通信ソフトウェア構造に適合させ

る方法を明らかにする。

そして、電話、ISDN、PHS、パケット通信、ブロードバンドISDN(B-ISDN)、インテリジェントネットワーク(IN)のようなさまざまな種類のリアルタイム通信サービスの構築を容易とするためのオブジェクトの定義と配置について述べる。

(29)

3.2. 要求条件 21 まず最初に、新しいソフトウェア構造のための必要条件および前提条件を明確にし、次にオブジェクト構造を示す。次に、システムの高信頼化のため、システムが再起動した場合にも、実行中のサービスを救済する機構を明らかにする。そして、分散オブジェクト間通信のオーバヘッドを見積もる。

最後に、これらのデータと傾向について要約する。

3.2 要求条件

3.2.1 階層化構造

本ソフトウェアプラットフォームは、電話、ISDN、PHS、パケット通信、ブロードバンドISDN(B-

ISDN)、インテリジェントネットワーク(IN)のようなさまざまな種類の通信システムにおいて利用

されている。

ソフトウェア構造は、図1に示すような階層構造を採っている。

3.2.2 プラットフォームの機能

ソフトウェアプラットフォーム部分の主要機能を表1 に示す。

ここにあげた機能は、各種の通信システムにおいて共通的に利用される機能である。

3.2.3 ソフトウェアコンポーネント

上記の機能要素それぞれをソフトウェアコンポーネントと呼ぶことにする。

ソフトウェアコンポーネントは、相互に密接に関連したC++クラスの集合体であり、ソフトウェアの管理単位である。それぞれのソフトウェアコンポーネントは、5から10のC++クラスを含み、

一体となって特定の役割を担う。

例えば、TCAP (ITU-T Rec. Q.77x)ソフトウェアコンポーネントは、TCAPプロトコル仕様に定義された役割を果たし、その配下にあるクラスは、Q.77xモデルにおいて定義された機能要素(コンポーネントサブレイヤ、トランザクションサブレイヤ、マネージメント機能等)に対応する。通信システムを構成する他の要素も、同様にソフトウェアコンポーネントとして実装される。

各コンポーネントは、外部からアクセス可能な1つのC++クラスを持っている。各コンポーネン

トはC++インタフェースルーチンによりアクセスされる[15]。

これらの機構により、ソフトウェアコンポーネントは1つのC++クラスであるかのように振舞う図7。

3.2.4 分散オブジェクト指向実現のための要求条件

CORBAに基づく分散オブジェクト指向ソフトウェアプラットフォームを確立するために、まず

CORBAの特性を明らかにする必要がある。

次に、ソフトウェアコンポーネントを、CORBAのフレームワークの中で機能要素としてマッピングするかを考える。

(30)

表1: プラットフォームの主要ソフトウェアコンポーネント

Entities Roles

device management for each device: fault processing, configuration control

system initialization complete system initialization, partial initialization [30, 31]

file update complete system file update without affecting calls in service [30, 31]

plug-in on-line partial file modification [12, 14]

processor replacement replacement of existing processor with new one without affecting calls in service

back up management back up of system file

file management file access, creation/deletion of file/directory office data handling modification or addition of office data [32]

TMN command message handling conversion of CMIP messages to internal command/message format, command execution control, logging, etc. [27–29]

alarm handling handling of system alarms

file transfer file transfer based on FTAM or FTP [27]

OSI communication communication control based on ITU-T X.200 series Recommendations

common channel signalling protocol handling of the common channel signalling protocols, such as MTP3, SCCP or TCAP (ITU-T Q.700 series Recommenda- tions) [33]

etc. etc.

(31)

3.2. 要求条件 23

! " # $

% & ' ( $ ) * ! + , -

# ' " # ) * # .

図 7: ソフトウェアコンポーネントとインタフェースルーチン

! " "# $ %$ & ! $

" % ' $ % ' $ ($ " # $

) %

*,+ -/. 0 1 2

図 8: CORBAモデル

リアルタイム通信向け ネットワークコンピューティング技術の研究