JP2002522932A

JP2002522932A - インテリジェント分散型ネットワークアーキテクチャのための方法およびシステム

Info

Publication number: JP2002522932A
Application number: JP2000564133A
Authority: JP
Inventors: ロバート・バーンハウス; ダグ・カーディ; ケルヴィン・ポーター; ケン・ランボー; キャロル・ウォラー; ウェンディー・ウォン; ジョージ・ヤオ
Original assignee: エムシーアイ・ワールドコム・インコーポレーテッド
Priority date: 1998-08-05
Filing date: 1999-07-30
Publication date: 2002-07-23
Also published as: WO2000008565A1; US20020059411A1; US6393476B1; DE69929340D1; ATE315250T1; US7979518B2; US6850977B2; US7013335B2; EP1103027A1; EP1103027A4; US20050066030A1; DE69929340T2; US8693666B2; CA2369038A1; EP1103027B1; US20110249812A1; US6418461B1; US6260067B1; US20030088707A1; US6560646B2

Abstract

(57)【要約】本発明のインテリジェント呼処理機構は、機能の少なくとも１つがサービス処理機能であり、機能の少なくとも１つが呼処理であり、そして機能の少なくとも１つが通信設備処理である複数の機能を有する論理プラットホーム、および該複数の機能を実行するための処理機構を備える。該インテリジェント交換ノードは、インテリジェント呼処理機構、および該インテリジェント呼処理機構に通信可能であるようにリンクされ、該インテリジェント呼処理機構から論理的に分離されているリソースコンプレックスを備える。該インテリジェント通信網は、複数のインテリジェント分散型ネットワークノード、広域ネットワークおよび該複数のインテリジェント交換ノードを監視および制御するためのネットワーク管理システム、および該複数のインテリジェント分散型ネットワークノードおよびネットワーク管理システムを相互接続するための該広域ネットワークを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、概して電気通信システムでのネットワーク交換に関し、さらに特定
するとサービス処理用のインテリジェント分散型ネットワークアーキテクチャの
ための方法およびシステムに関する。

【０００２】

【従来の技術および発明が解決しようとする課題】

ネットワークサービスとは、一人または複数の加入者との対話に応えて、デー
タまたは電話などの通信網、およびその関連リソースにより実行される１つの機
能である。例えば、呼転送または音声メールアクセスなどの電話網常駐サービス
は、特別な一連の数字をダイヤルすることによって加入者により呼び出すことが
できる。それ以外のネットワークサービスは、ネットワーク所有者を機密保護、
バリデーション、および認証で補助することを目的としてよい。サービスを追加
または修正するには、通信網で変更を加えることが必要になる。

【０００３】大部分の従来の電気通信網は、相互接続された交換機および通信装置から構成
されている。これらの交換機は、交換機製造メーカによって設計される独自のソ
フトウェアまたはファームウェアによって動作される統合されたまたは埋め込ま
れた処理機構により制御される。典型的には、該交換機製造メーカのソフトウェ
アまたはファームウェアは、サービス処理、呼処理、通信設備（ｆａｃｉｌｉｔ
ｙ）処理、およびネットワーク管理というすべての機能面をサポートしなければ
ならない。つまり、ネットワーク所有者が新しいサービスの実現または既存のサ
ービスの修正を希望するとき、ネットワーク内のあらゆる交換機のソフトウェア
は多様な交換機製造メーカによって改訂されなければならない。

【０００４】該ネットワークにはさまざまな製造メーカの異なる交換機の型が含まれるとい
う事実は、新しいソフトウェアの注意深い開発、試験および配備を必要とする。
新しいソフトウェアを開発、試験および配備するために要する時間は、各交換機
におけるコードサイズが、新しく改訂されるたびにさらに拡大し、さらに複雑に
なるために長期化している。このようにして、このプロセスは数年を要すること
がある。加えて、この増大した複雑さが、さらに交換機処理装置に負担をかけ、
交換機誤動作の確率を高め、交換機の改修または交換を要することがある。

【０００５】さらに、複数のネットワーク所有者が交換機製造メーカの１つの共通したセッ
トに依存するという事実により、競合を制限する２つの望ましくない状況が生じ
る。第１に、製造メーカのソフトウェアリリースは、複数のネットワーク所有者
により要求される変更を組み込もうとしてよく、このようにしてネットワーク所
有者が真に自らのサービスをその競争相手によって提供されているサービスから
差別化するのを妨げている。また、これにより、いくつかのネットワーク所有者
は、製造メーカが他のネットワーク所有者からの要求を新しいリリースの中に組
み込むまで強制的に待たされる。第２に、新しいサービスを実現するためにある
ネットワーク所有者によって要求される通りに機能を組み込む交換機ソフトウェ
アのリリースは、他のネットワーク所有者によって故意にではなくアクセスでき
るようになる。

【０００６】これらの問題点は、新規ネットワークサービスに対する需要が、加入者の移動
性の増大、トラフィックの多様性および帯域幅の増加、従来の番号付け計画の崩
壊、さらに高度なサービス、および高まる競争により、過去５年から１０年に急
激に増大するに従い耐えがたいものになってきた。このようにして、新規ネット
ワークアーキテクチャが、サービス論理を作成、配備および実行するさらに柔軟
性のある方法を組み込む必要があることは広く認識されている。これ以降説明さ
れる本発明の新規のアーキテクチャを完全に理解するために、関連する従来の技
術の以下の説明が、図１から図４に関して提供される。

【０００７】図１を参照すると、本発明を含む多様な交換アーキテクチャの論理表記が示さ
れている。通常２０として示されるモノリシック交換機は、サービス処理機能２
２、呼処理機能２４、通信機能処理機能２６、および交換機機構（ｆａｂｒｉｃ
）２８を含む。これらの機能２２、２４、２６および２８のすべては、グループ
３０により符号で表されるように、ハードコーディングされ、混ぜられ、未分化
である。さらに、機能２２、２４、２６および２８は交換機製造メーカによって
設計され、製造メーカごとに変わる独自のプラットホームで動作する。その結果
、これらの機能２２、２４、２６および２８は製造メーカの補助なしには修正す
ることはできず、サービス開発および実現を減速し、新規サービスを市場に送り
出す費用を増加する。したがって、新規の革新的なサービス、呼処理、データ処
理、信号処理およびネットワーク動作の開発は、製造メーカのその独占的な交換
機ハードウェアおよびソフトウェアに対する管理、および業界規格の確立と実現
の固有の困難さにより制約される。

【０００８】サービス処理機能２２はモノリシック交換機２０の中で符号化され、ローカル
データコンテンツおよびダイヤルされた番号に基づいたこのプロセスのローカル
制御だけを可能にする。このローカル情報は、符号化されたサービス機能を実行
する手作業でコーディングされた（ｈａｎｄｃｏｄｅｄ）プロセスエンジンによ
って解釈される。該呼処理機能２４はハードコーディングされ、呼の発信機能お
よび呼の成端機能を提供する。実際には、このプロセスが、呼を完了するために
個々のコネクションを立ち上げ、立ち下げる（ｔａｋｅｓｄｏｗｎ）。同様に
、通信設備処理機能２６もハードコーディングされ、呼に関わる物理的なリソー
スに関するすべてのデータ処理を提供する。該交換機機構２８は、ノーザンテレ
コム社（ＮｏｒｔｈｅｒｎＴｅｌｅｃｏｍＩｎｃ．）などの交換機製造メー
カにより提供されるモノリシックソフトウェアを実行するための交換機およびコ
ンピュータのハードウェア構成部品を表す。該交換機機構２８はコネクションを
確立するために必要な物理的な通信設備を提供し、ベアラーデバイス（ＴＩおよ
びＤＳＯ）、交換マトリックスデバイス（ネットワーク平面（ｐｌａｎｅ）およ
びその処理機構）、リンク層信号処理機構（ＳＳ７、ＭＴＰ、ＩＳＤＮ、ＬＡＰ
Ｄ）および特殊回線（会議ポート、音声トーン検出器）を含んでよいが、それら
に限られない。

【０００９】前述された問題点を処理しようとして、国際電気通信連合（Ｉｎｔｅｒｎａｔ
ｉｏｎａｌＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＵｎｉｏｎ）および欧州
電気通信標準化機構は、ＩＴＵ−Ｔインテリジェントネットワーク規格（「ＩＮ
」）を是認した。同様に、ベルコア（Ｂｅｌｌｃｏｒｅ）は高度インテリジェン
トネットワーク規格（「ＡＩＮ」）を是認した。これらの２つの規格は、プレゼ
ンテーションおよび進化の状態において異なるが、ほぼ同一の目的および基本概
念を持っている。その結果、これらの規格は、サービス処理機能２２が交換機か
ら分離される単一のネットワークアーキテクチャと見なされている。

【００１０】ＩＮアーキテクチャおよびＡＩＮアーキテクチャを使用すると、おそらくネッ
トワーク所有者は、本質的には、指定の種別の呼の間に呼び出されるサービス個
別構築ブロック（「ＳＩＢＢ」）のテーブルである、新しいサービス論理プログ
ラム（「ＳＬＰ」）を作成し、配備することにより新規サービスを初公開後に拡
大して売り出すことができるだろう。このアプローチに従って、多くの特定の要
素タイプが、ネットワーク加入者にサービスを提供するためにＳＬＰと関連して
相互運用する。その結果、新しい、または潜在的なサービスは、既存のＳＩＢＢ
によって制限される。

【００１１】通常４０として示されているＩＮアーキテクチャまたはＡＩＮアーキテクチャ
は、モノリシック交換機２０の機能をサービス制御ポイント（「ＳＣＰ」）４２
、およびサービス交換ポイント（「ＳＳＰ」）と交換システム４４に論理的に分
離する。該ＳＣＰ４２はサービス処理機能２２を含むが、該ＳＳＰと交換システ
ム４４は、呼処理機能２４、通信設備処理機能２６および交換機機構２８を含む
。この場合、呼処理機能２４、通信設備処理機能２６、および交換機機構２８は
、グループ４６によって符号で表されるように、ハードコーディングされ、混ぜ
られ、未分化である。

【００１２】該サービス交換ポイント（「ＳＳＰ」）は、加入者の信号方式がいつダイヤル
された番号だけに基づいた単純な経路選択以上のものを必要とするのかを認識す
るために交換機に常駐する機能モジュールである。該ＳＳＰは、それが、本質的
には多くの交換機のためのデータベースサーバとして動作するリモートＳＣＰ４
２に対する呼の正しい処理に関する問い合わせを起動する間、呼の追加処理を保
留する。この処理の分割の結果、特別なサービス呼を処理するという頻繁ではな
いが時間のかかるタスクが、交換機からオフロードされることになる。さらに、
この適度な集中化は、あらゆる交換機でのリポジトリの完全なコピーの配備に対
する、ネットワーク全体にサービスを提供する１つの容易に修正可能な多量に負
担がかけられるリポジトリを有することの間で釣り合いを取る（ｄｒａｗｓ）。

【００１３】図２を参照すると、ＩＮアーキテクチャまたはＡＩＮアーキテクチャを利用す
る電気通信システムの図が示され、通常５０として表されている。ＩＳＤＮ端末
５２、第１電話５４、および第２電話５６などの多様なカスタマシステムが、Ｓ
ＳＰおよび交換システム４４に接続されている。ＩＳＤＮ端末５２は、信号回線
６０およびトランスポート回線６２によってＳＳＰおよび交換システム４４に接
続されている。該第１電話５４は、トランスポート回線６４によってＳＳＰおよ
び交換システム４４に接続されている。該第２電話５６は、トランスポート回線
６８によって遠隔交換システム６６に接続され、遠隔交換システム６６は、トラ
ンスポート回線７０によってＳＳＰおよび交換システム４４に接続されている。

【００１４】図１に関して前述されたように、ＳＳＰ７０は、加入者の信号が、ダイヤルさ
れた番号に基づいた単純な経路選択以上のものをいつ必要とするのかを認識する
ために、交換機に常駐する機能モジュールである。該ＳＳＰ７０は、それが該呼
の正しい処理に対する照会を起動している間は、該呼の追加処理を保留する。こ
の照会は、ＳＣＰ４２へのＳＳ７メッセージ通信の形で遠隔送信される。該サー
ビス制御ポイント４２は、それが加入者にとっては多くの範囲を定める（ｓｕｂ
ｔｅｎｄｉｎｇ）交換機を通して接続されているように見えるので、このロケー
ションでのデータベースコンテンツの変更がネットワーク機能を改変できるため
に、このように名付けられている。該照会は、これらの要素間のＳＳ７メッセー
ジ通信用ルータにすぎない信号転送ポイント（「ＳＴＰ」）７４に、信号回線７
２を通って、それからＳＣＰ４２へ信号回線７６を通って送信される。

【００１５】総合サービス管理システム（「ＩＳＭＳ」）７８は、サービスを配備または改
変するため、あるいはサービスへの加入者ごとの（ｐｅｒ−ｓｕｂｓｃｒｉｂｅ
ｒ）アクセスを管理するための管理ツールとして構想されている。該ＩＳＭＳ７
８は、おもに、ＳＳＰ７０よびＳＣＰ４２内に記憶されている動作論理およびデ
ータを改変することにより動作する。該ＩＳＭＳ７８は、多様なユーザインタフ
ェース８０と８２を有する。このＩＳＭＳ７８は、動作回線８４によってＳＣＰ
４２に、動作回線８６によってＳＳＰおよび交換システム４４に、および動作回
線９０によってインテリジェント周辺機器（「ＩＰ」）８８に接続される。該イ
ンテリジェント周辺機器８８は、音声応答システムまたは音声認識システムなど
の、交換機上で利用できない機能をネットワークに追加するために使用されるデ
バイスである。該ＩＰ８８は、信号回線９２およびトランスポート回線９４によ
ってＳＳＰおよび交換システム４４に接続される。

【００１６】今度は図２および図３を参照すると、従来の技術に従った呼の処理が説明され
るだろう。該呼は、ブロック１００で、カスタマが受話器を取り上げ、ダイヤル
し始めると起動される。企業交換機での該ＳＳＰ７０は、ブロック１０２でダイ
ヤル呼出しを監視し、トリガシーケンスを認識する。該ＳＳＰ７０は、ブロック
１０４でサービス論理を調べることができるまで該呼の追加処理を保留する。そ
れから、該ＳＳＰ７０は標準ＳＳ７メッセージを作文し、ブロック１０４でそれ
をＳＴＰ（Ｓ）７４を通ってＳＣＰ４２に送信する。該ＳＣＰ４２は、ブロック
１０６でメッセージを受信、復号し、ＳＬＰを呼び出す。該ＳＬＩは、ブロック
１０６で、データベースルックアップなどの他の機能の作動を要求する可能性の
あるＳＬＰを解釈する。該ＳＣＰ４２は、ブロック１０８で、該呼の処理に関し
てＳＳＰおよび交換システム４４にＳＳ７メッセージを戻すか、そうでなければ
、正しいサービスを実行するためにネットワーク要素にメッセージをディスパッ
チする。呼の完了時に、ＳＳ７メッセージは呼を分解するために交換機の間で送
信され、ブロック１１０で、呼の詳細レコードが呼に関わる各交換機によって作
成される。該呼詳細レコードは、ブロック１１２で区域外通話の料金請求書作成
発行を引き出すために呼ごとに、収集され、相互に関連付けられ、オフラインで
解決される。呼処理は、ブロック１１４で完了する。

【００１７】ＩＮアーキテクチャおよびＡＩＮアーキテクチャは、すべての予見可能なサー
ビスをサポートするために機能の標準セットを事前に定義しようと試みる。これ
らの標準機能はすべて、交換機内の多様な状態機械の中にハードコーディングさ
れる。残念なことに、新しい技術、それに関連して生じるであろうあらゆる新規
機能、または予見できないサービスニーズは、多くのベンダプラットホーム全体
でのネットワークソフトウェアの広範囲なオーバーホールおよび試験なしに実現
することはできない。さらに、新規機能が標準化された呼のモデル、プロトコル
、またはインタフェースに対する変更を要求する場合、その機能を活用するサー
ビスの実現は、該変更が業界規格団体によって批准されるまで遅延される可能性
がある。しかし、草案の規格がＩＮおよびＡＩＮによってサポートされている機
能セットを広げようと試みていた折しも、装置供給業者は、コードの複雑さの圧
倒的な拡大のためにこれらの草案規格を是認するのを拒絶してきた。

【００１８】今度は図４を参照すると、従来の技術に従った汎用サービス作成のためのプロ
セスが説明されるだろう。該ネットワーク所有者は、ブロック１２０で、新しい
サービス、新しい呼の状態、および新しいプロトコルを含む新規機能を要求する
。新しい呼のモデルが決定ブロック１２２で要求されると、提案が規格団体に提
出されなければならず、該ネットワーク所有者は、ブロック１２４で、１年から
３年を要することがある新しい規格の業界採用を待たなければならない。決定ブ
ロック１２２で決定されるように、新しい規格が採用された後、あるいは新しい
呼のモデルが要求されない場合、該ネットワーク所有者は、ブロック１２６で新
規機能を実現するために、６ヶ月から１８ヶ月を要することがある、それぞれの
製造メーカからのコード更新を要求し、待機しなければならない。

【００１９】該ネットワーク所有者は、ブロック１２８で、製造メーカごとの新規機能およ
びすべての過去の機能を試験しなければならず、１ヶ月から３ヶ月を要すること
がある。決定ブロック１３０で決定されるように、すべての試験が無事終了しな
い場合、および決定ブロック１３２で決定されるように、故障の原因が設計の問
題である場合には、プロセスはブロック１２２で再開されなければならない。し
かしながら、決定ブロック１３２で決定されるように、故障の原因がコードの問
題である場合には、製造メーカはブロック１３４で該コードを修理しなければな
らず、試験はブロック１２８で再度実行されなければならない。

【００２０】決定ブロック１３０で決定されるように、すべての試験が無事終了し、決定ブ
ロック１３６で決定されるように、製造メーカがサービスを作成する場合には、
該ネットワーク所有者は、ブロック１３８で、該製造メーカから新しいサービス
バージョンを要求し、試験済みのバージョンの送達を待機しなければならない。
しかしながら、決定ブロック１３６で決定されるように、ネットワーク所有者が
サービスを作成すると、該ネットワーク所有者は、作成ツールを使用してサービ
スの新しいバージョンを作成し、該新規サービスがブロック１４０で正しく作動
することを確認するために、ユニット試験を繰り返さなければならない。どちら
のケースでも、該ネットワーク所有者は、それから、ブロック１４２で統合試験
を実行し、すべての過去のサービスが依然として適切に動作することを確認する
。それから、システム試験は、ブロック１４４で、ＳＣＰと交換機間の適切な調
整を確実にするために実行されなければならない。それから、該ネットワーク所
有者は、ブロック１４６で、ネットワーク内のすべての交換機およびＳＣＰに対
する新しいソフトウェアリリースの同じロードを調整しなければならない。該新
規機能のインプリメンテーションは、ブロック１４８で完了する。

【００２１】今度は図２を参照し直すと、ＩＮアーキテクチャおよびＡＩＮアーキテクチャ
のそれ以外の制限は、呼処理機能および通信設備処理機能、すなわち交換機内部
で動作する該ＳＳＰ７０を有することから生じる。その結果、これらの機能は各
交換機製造メーカによって、独自のソフトウェアを使用して提供されなければな
らない。したがって、ネットワーク所有者は、新しい機能をサポートするために
、依然として製造メーカのソフトウェアリリースに甚だしく依存している。さら
に事態を複雑化するのは、該ネットワーク所有者が、統一された開発試験環境で
それ以外のモジュールと関連してＳＳＰ７０モジュールを試験することはできな
いということである。さらに、交換機製造メーカの処理環境向けのＳＳＰが、該
ネットワーク所有者のサービス作成環境と互換性があるだろうという保証もない
。

【００２２】複数のネットワーク所有者が交換機製造メーカの１つの共通セットに依存する
結果、競争を制限する２つの望ましくない状況が生じる。第１に、製造メーカの
ソフトウェアリリースは、複数のネットワーク所有者によって要求される変更を
組み込もうとし、それによりネットワーク所有者が、自らのサービスをその競争
相手によって提供されているサービスから真に差別化するのを妨げている。これ
は、また、製造メーカがその他のネットワーク所有者からの要求を新しいリリー
スに組み込むまで、数人のネットワーク所有者に強制的に待機させる。第２に、
該ネットワーク所有者によって新しいサービスを実現するように要求されるよう
に、機能を組み込んだ交換機ソフトウェアリリースは、それ以外のネットワーク
所有者に故意にではなくアクセスできるようになる。したがて、ＩＮアーキテク
チャおよびＡＩＮアーキテクチャの意図に関わらず、該ネットワーク所有者は、
ネットワークサービス動作を形作る機能要素を完全に支配したり、それらにアク
セスしていないために、該ネットワーク所有者の新しいサービスの作成、試験お
よび配備は、依然として妨げられている。

【００２３】これらの問題を解決するための別の試みにおいて、通常１５０（図１）と呼ば
れている分離交換機インテリジェンスおよび交換機機構（「ＳＳＩ／ＳＦ」）ア
ーキテクチャが、該ＳＳＰ７０を交換システム４４から論理的に分離する。今度
は図１を参照し直すと、該交換機インテリジェンス１５２は、円１５４と１５６
によって符号で表されている対応するハードコーディングされた状態の機械エン
ジンとともに分離状態テーブルで符号化される呼処理機能２４および通信設備処
理機能２６を含む。交換機機構機能１５８と交換機インテリジェンス機能１５２
間のインタフェースは、該交換機機構１５８および交換機インテリジェンス１５
２が、必ずしも物理的にともに位置し、同じ処理機構内で実行されるか、あるい
は１対１の対応関係を持たなくてもよいように、通信ネットワークを通って拡張
されてよい。その結果として、該交換機インテリジェンス１５２は、簡略な、サ
ービスに特殊ではなく、製造メーカに特殊ではない、すべての交換機に共通の機
能の一貫したインタフェースを提供する。

【００２４】インテリジェントコンピューティングコンプレックス（「ＩＣＣ」）１６０は
、サービス処理機能２２を含み、複数の交換機インテリジェンス要素１５２と通
信する。このアプローチは、大部分の初歩的な機能以外のすべてが、製造メーカ
に特殊なコードという領域外に移されるため、柔軟なサービスインプリメンテー
ションにおいてネットワーク所有者の優位点を提供する。追加の改良は、サービ
ス論理の作成、開発、試験および実行に、さらに統一した環境を提供することに
より実現されてよい。

【００２５】前述されたように、現在のネットワーク交換機はモノリシックな独占的なハー
ドウェアおよびソフトウェアに基づいている。ネットワーク交換機は数百万ドル
かかることがあるが、このような装置は、現在利用可能なコンピューティング技
術という点で見ると、処理速度という点で相対的に低速である。例えば、これら
の交換機は６０ＭＨｚという範囲で実行中の縮小命令セットコンピュータ（「Ｒ
ＩＳＣ」）処理機構に基づき、典型的には、交換ネットワークの多様なプラット
ホーム間で毎秒９．６Ｋｂという伝送速度をサポートするＸ．２５などのデータ
通信プロトコルを使用して互いと通信する。これは、２００ＭＨｚ以上で実行中
の処理機構を持つコンピュータ、および毎秒１５０ＭｂのＦＤＤＩインタフェー
スおよびＡＴＭインタフェースを提供するハイエンドコンピュータワークステー
ションと比較すると、きわめて低速である。したがって、ネットワーク所有者は
、独占的なハードウェアの代わりにハイエンドワークステーションを使用できる
必要がある。

【００２６】

【課題を解決するための手段】

本発明は、通信システムで使用するためのインテリジェント呼処理機構、イン
テリジェント交換ノードおよびインテリジェント通信ネットワークを含んでよい
。該インテリジェント呼処理機構は、該機能の内の少なくとも１つがサービス処
理機構であり、該機能の内の少なくとも１つが呼処理であり、該機能の内の少な
くとも１つが通信設備処理である複数の機能を有する論理プラットホーム、およ
び該複数の機能を実行するための処理機構を含んでよい。該インテリジェント交
換ノードは、インテリジェント呼処理機構、および該インテリジェント呼処理機
構に通信可能であるようにリンクされ、該インテリジェント呼処理機構から論理
的に分離されているリソースコンプレックスを含んでよい。該インテリジェント
通信ネットワークは、複数のインテリジェント分散型ネットワークノード、広域
ネットワークおよび複数のインテリジェント交換ノードを監視、制御するための
ネットワーク管理システム、および複数のインテリジェント分散型ネットワーク
ノードおよびネットワーク管理システムを相互接続する広域ネットワークを含ん
でよい。

【００２７】

【発明の実施の形態】

本発明の前記の、および追加の優位点は、添付図面とともに以下の説明を参
照することによりさらによく理解されてよい。

【００２８】ここで図１を参照すると、本発明に従ったインテリジェント分散型ネットワー
クアーキテクチャ（「ＩＤＮＡ」）は、通常１７０として表されている。本発明
は、ＳＳＩ／ＳＦアーキテクチャ１５０のＩＣＣ１６０および交換機インテリジ
ェンス１５２を、１つのインテリジェント呼処理機構（「ＩＣＰ」）１７２に統
一する。その機能が状態テーブルに規定されているＩＮアーキテクチャまたはＡ
ＩＮアーキテクチャまたはＳＳＩ／ＳＦアーキテクチャ４０とは異なり、ＩＣＰ
１７２は、ブロック１７４、１７６および１７８によって符号で表されているオ
ブジェクト指向型プラットホームの管理オブジェクトとして、サービス制御機能
２２、呼処理機能２４、および通信設備処理機能２６を含む。該ＩＣＰ１７２は
、該リソースコンプレックス１８０から論理的に分離されている。

【００２９】ここで図５を参照すると、本発明に従ったインテリジェント分散型ネットワー
クアーキテクチャを利用する電気通信システムが説明され、通常２００として示
されている。該広域ネットワーク（「ＷＡＮ」）２０２は、広い地理学上の区域
全体でのアプリケーションおよびデータの分散をサポートするシステムである。
該トランスポートネットワークは、同期光学ネットワーク（「ＳＯＮＥＴ」）に
基づき、ＩＤＮＡノード２０４を接続し、互いにと通信するためにそれらのノー
ド内でアプリケーションをイネーブルする。

【００３０】各ＩＤＮＡノード２０４は、インテリジェント呼処理機構（「ＩＣＰ」）１７
２およびリソースコンプレックス１８０（図１）を含む。図５は、リソースコン
プレックスＡ（「ＲＣＡ」）２０６およびリソースコンプレックスＢ（「ＲＣＢ
」）２０８を有するＩＮＤＡノード２０４を示す。該ＩＣＰ１７２は、対処、料
金請求書作成発行、および回復などの既存のサポート機能を提供する補助処理機
構２１０にリンクできる。最終的には、補助処理機構２１０によって提供される
機能は、ネットワーク管理システム（「ＮＭＳ」）２１２内の機能によって吸収
されるだろう。ＩＣＰ１７２は、シグナリング２１６およびベアラーリンク２１
８を有する直接リンク２１４を通して、その他のＩＣＰ１７２、その他のネット
ワーク（図示されていない）およびその他のデバイス（図示されていない）にリ
ンクすることもできる。直接リンクは、接続されているデバイス間の待ち時間を
防止し、デバイスが専用の言語で通信できるようにする。該ＩＣＰ１７２はＩＤ
ＮＡノード２０４の「脳」であり、好ましくは、ＩＤＮＡノード２０４の処理要
件に従って、単一メモリ記憶装置付きの単一処理機構から大規模コンピュータネ
ットワークまでの範囲となってよい汎用コンピュータである。好ましくは、該汎
用コンピュータは冗長な処理、メモリ記憶域およびコネクションを有するだろう
。

【００３１】ここに使用されるように、汎用コンピュータとは、特に電話交換用途向けに構
成、設計された専用デバイスとは対照的に、市販されている既製の構成部品であ
る、あるいはそれらを使って組立てられてよいコンピュータを指す。汎用コンピ
ュータの発呼側ネットワーク内での統合は、多数の優位点を提供する。

【００３２】該汎用コンピュータの使用は、ＩＣＰ１７２に、増大する処理ニーズを満たす
ために追加ハードウェアを使って大型化する能力を与える。これらの追加は、処
理力の増加、データ記憶、および通信帯域幅の能力を含む。また、これらの追加
は、発呼側ネットワーク内の各交換機での各製造メーカに特殊なソフトウェアお
よび／またはハードウェアの修正を必要としない。その結果、新しいサービスお
よびプロトコルは、交換ネットワーク内で個々のデバイスの修正を行わなくても
大局的な規模で実現、インストールされてよい。本発明は、モノリシック交換機
２０（図１）からインテリジェント呼処理機構１７２に変更することによって前
記優位点および拡大する機能を提供する。

【００３３】さらに大きな処理力を要するアプリケーションのケースでは、多重処理が、呼
処理のための価格／性能比率を最適化するために、より安価な処理機構の使用を
可能にする。それ以外のアプリケーションでは、さらに高い処理率を備える、ミ
ニコンピュータなどのさらに強力な機械を使用することが有利、必要、またはさ
らに経済性に優れる場合がある。

【００３４】該ＩＣＰ１７２は、前記に注記されたように、例えば、ＵＮＩＸ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）ＮＴオペレーティングシステム上で動作している汎用コンピュータのクラスタを備える。例えば、単一リソースコンプレックスで１００，０００ポートまでサポートする大きなアプリケーションでは、該ＩＣＰ１７２は、対称マルチプロセッサクラスタ内で３３３ＭＨＺで動作している一六（１６）台の３２ビット処理機構から成り立ってよい。該処理機構は、例えば、それぞれ４台の処理機構の付いた４台の別々のサーバに分割できるだろう。個々のプロセッサは、システムエリアネットワーク（「ＳＡＮ」）またはそれ以外のクラスタ化技術をもって接続されるだろう。該プロセッサクラスタは、レイド（「ＲＡＩＤ」）モジュラーデータ記憶装置へのアクセスを共用できるだろう。共用される記憶域は、モジュラーディスク記憶装置を追加または削除することにより調整されてよい。該クラスタ内の該サーバは、好ましくはＲＣ１８０（図１）への冗長リスクを共用するだろう。

【００３５】図解されるように、およびパソコンの「プラグアンドプレイ」機能のように、
ＩＣＰソフトウェアアーキテクチャは、（１）管理ソフトウェア、（２）ＩＣＰ
アプリケーション、（３）コンピューティングハードウェアおよびソフトウェア
、（４）リソースコンプレックス構成部品、および（５）サービスアーキテクチ
ャおよび処理さえの互換性を可能にする開放処理モデルである。このような汎用
アーキテクチャは、標準化のための保守費用を削減し、規模の経済から引き出さ
れる利点を提供する。

【００３６】このようにして、本発明は開発作業の分割およびサービスのさらに高速な開発
とインプリメンテーションを生じさせるモジュラーツールの使用を可能にする。
さらに、サービス管理の使用およびサービス管理の関連する態様は、固定された
メッセージ通信プロトコル、または指定された製造メーカによって供給されるハ
ードウェアとソフトウェアのある特定の組み合わせによって課される制約とは対
照的に、必要に応じてネットワーク運用者の管理下にある。

【００３７】管理オブジェクトを使用することにより、本発明は、容量および使用量などの
任意の数の要因に基づいて、ネットワーク全体でサービスおよび機能を柔軟に（
どこでそれを使用したいのか）、かつ動的に（「進行中に」）分散できるように
する。サービス処理２２（図１）、呼処理２４（図１）および通信設備処理２６
（図１）が同種プラットホームで動作するため、性能は改善される。さらに、本
発明は、以前はアクセスすることができなかった呼副要素（ｓｕｂ−ｅｌｅｍｅ
ｎｔｓ）の監視および操作を可能にする。また、本発明は、該ネットワーク運用
者が機能またはサービスの使用量を、それらが時代遅れになったとき、あるいは
未使用なときにそれらを排除できるように監視できるようにする。

【００３８】該リソースコンプレックス（「ＲＣ」）１８０（図１）は、ベアラーに信号サ
ービスおよび接続サービスを提供する物理デバイス、つまりリソースの集合体で
ある。インテリジェント周辺装置８８を含むことのある該ＲＣ１８０は、ＩＮア
ーキテクチャまたはＡＩＮアーキテクチャまたはＳＳＩ／ＳＦアーキテクチャの
交換機機構２８および１５８（図１）を置換する。ＩＮアーキテクチャまたはＡ
ＩＮアーキテクチャとは異なり、ＲＣＡ２０６などのリソースコンプレックスの
制御はさらに低いレベルにある。さらに、該ＲＣＡ２０６は複数の交換機機構１
５８を含むことができる。該交換機機構１５８またはそれ以外のカスタマインタ
フェース（図示されていない）は、標準電話コネクションを介して、複数の加入
者および交換ネットワークに接続する。これらのカスタマシステムは、ＩＳＤＮ
端末５２、ファックス機械２２０、電話５４、およびＰＢＸシステム２２２を含
んでよい。該ＩＣＰ１７２は、該ＲＣ１８０（図１）、ＲＣＡ２０６およびＲＣ
Ｂ２０８を高速データ通信パイプ（最小、毎秒１００Ｍｂイーサネット（登録商標）コネクション）２２４を通して制御し、それらと通信する。該ＲＣ１８０，２０６、および２０８はパソコンに類似することがあり、そこでは該パソコンはプリンタを制御するためにドライバを使用する。ＩＤＮＡノード２０４での該「ドライバ」は、リソースコンプレックスプロクシ（「ＲＣＰ」）（図示されていない）であり、図６に関して後述されるだろう。これにより、製造メーカは、ＩＤＮＡモデルを組み込むためにそのソフトウェアのすべてを作成し直さなくても、このインタフェースを使用してＩＤＮＡ準拠のノードを提供することができる。

【００３９】さらに、該リソースコンプレックス１８０（図１）、ＲＣＡ２０６およびＲＣ
Ｂ２０８の制御は、典型的にＡＩＮアーキテクチャまたはＩＮアーキテクチャに
よって提供されるより低いレベルにある。その結果、リソースコンプレックス製
造メーカは、通信設備処理およびネットワーク管理処理をサポートするには単一
インタフェースを提供しさえすればよい。つまり、彼らはネットワーク所有者に
特殊な呼処理およびサービス処理を提供する必要はないのである。低レベルのイ
ンタフェースは、さらに分離した動作に引き離される。単一インタフェースを持
つことにより、該ネットワーク所有者は、判断を価格および性能に基づかせてい
る幅広い範囲のリソースコンプレックス製造メーカから選ぶことができるように
なる。インテリジェンスは、該ＲＣ１８０を変更から分離し、その複雑さを削減
する該ＲＣ１８０よりむしろＩＣＰ１７２に付加される。該ＲＣ１８０の役割は
簡略化されているので、変更はより容易に加えられ、このようにして非同期転送
モード（「ＡＴＭ」）などの代替交換伝送技術に移行することはさらに容易であ
る。

【００４０】インテリジェント周辺装置（「ＩＰ」）８８は、実際の呼伝送経路内に含まれ
ている情報を処理し、それに作用する能力を提供する。ＩＰ８８は、通常、ＲＣ
Ｂ２０８などの別個のリソースコンプレックス内にあり、ＲＣＡ２０６と同様に
該ＩＣＰ１７２によって制御される。ＩＣＰ８８は、デジタル信号処理（「ＤＳ
Ｐ」）技術を使用してリアルタイムで実際の呼伝送路内でデータを処理する能力
を提供することができる。

【００４１】該ネットワーク管理システム（「ＮＭＳ」）２１２は、ＩＤＮＡネットワーク
２００内でハードウェアおよびサービスを監視、制御するために使用される。提
案されたＮＭＳ２１２インプリメンテーションが、ＩＤＮＡネットワーク２００
内で構成部品の管理を提供する、電気通信管理ネットワーク（「ＴＭＮ」）に準
拠したフレームである可能性がある。さらに特定すると、該ＮＭＳ２１２はサー
ビスの配備を制御し、それらのサービスの健康を維持し、それらのサービスにつ
いての情報を提供し、ＩＤＮＡネットワーク２００にネットワークレベル管理機
能を与える。該ＮＭＳ２１２は、ＩＤＮＡノード２０４内でのエージェント機能
性を通してサービスおよびハードウェアにアクセスし、制御する。該ＩＤＮＡノ
ード２０４内の該ＩＣＰ−ＮＭＳエージェント（図示されていない）は、該ＮＭ
Ｓ２１２によって発行されるコマンドまたは要求を実行する。該ＮＭＳ２１２は
、標準動作リンク２２６を通してＲＣＡ２０６とＲＣＢ２０８を直接的に監視、
制御することができる。

【００４２】管理オブジェクト作成環境（「ＭＯＣＥ」）２２８は、ＩＤＮＡネットワーク
２００で実行するサービスを作成するために副構成部品（ｓｕｂ−ｃｏｍｐｏｎ
ｅｎｔｓ）を含む。サービス設計者が新規サービスを作成するために使用するサ
ービス個別ビルディングブロック（「ＳＩＢＢ」）およびＡＰＩ表記が、ＭＯＣ
Ｅの一時副構成部品であるグラフィックユーザインタフェース（「ＧＵＩ」）の
中に埋め込まれている。該ＭＯＣＥ２２８は、単一ユーザ環境またはプラットホ
ーム上でホストとして働くツールの統一集合体である。それは、管理オブジェク
トおよびサービス試験でカプセル化される、サービス文書、管理オブジェクト定
義、インタフェース定義、プロトコル定義およびデータ入力定義などのサービス
作成のプロセスを通して必要とされる動作の集合体を表す。管理オブジェクトは
所有者のネットワーク上のすべてのノードに適用できるため、該ネットワーク所
有者は、ＭＯＣＥ２２８を使用して一度サービスを開発しさえすればよい。これ
は多様な交換機製造メーカのそれぞれに、サービスの独自のバージョンを開発さ
せる、つまりサービスが複数回開発されなければならないネットワーク所有者と
は対照的である。

【００４３】ＭＯＣＥ２２８およびＮＭＳ２１２は、リポジトリ２３１を介してともに接続
される。該リポジトリ２３０は、ＮＭＳ２１２によって分散され、ＩＤＮＡノー
ド２０４で使用される管理オブジェクトを含む。リポジトリ２３０は、ＭＯＣＥ
２２８とＮＭＳ２１２の間にバッファも提供する。しかしながら、該ＭＯＣＥ２
２８は、破線２３２で示される「ライブ」ネットワーク試験を実行するためにＮ
ＭＳ２１２に直接的に接続されてよい。

【００４４】今度は図６を参照すると、本発明に従って、インテリジェント分散型ネットワ
ークアーキテクチャ２００を利用する電気通信システムの論理機能図が説明され
るだろう。該ＩＣＰ１７２は、その結果として管理オブジェクトベースクラス２
４４から引き出される多岐に渡る管理オブジェクト２４６、２４８、２５０およ
び２５２のホストとして働くＩＣＰ−ＮＭＳエージェント４０およびサービス層
実行環境（「ＳＬＥＥ」）２４２を含むように示されている。

【００４５】一般的には、管理オブジェクトとはソフトウェア機能を実装する方法であって
、そこではそれぞれの管理オブジェクトが、管理オブジェクトの機能を実現する
ために、機能インタフェースと管理インタフェースの両方を提供する。該管理イ
ンタフェースは、誰へのアクセスなのか、および何が管理オブジェクト機能にア
クセスできるのかを制御する。本発明では、インフラストラクチャソフトウェア
を除く、ＩＤＮＡノード２０４によって実行される電話アプリケーションソフト
ウェアのすべてが管理オブジェクトおよびサポートライブラリとして配備される
。これが、ＩＤＮＡノードソフトウェアを制御、管理するために均一なインタフ
ェースおよびインプリメンテーションを提供する。

【００４６】ノードによって処理されるベアラートラフィックを接続、転送、および成端す
るネットワーク要素の集合体が、集合的にリソースコンプレックス（「ＲＣ」）
１８０と呼ばれるだろう。ＳＬＥＥ上で実行中のサービス処理アプリケーション
が、ＲＣ１８０への制御インタフェースとしてリソースプロクシ（「ＲＣＰ」）
２４４を使用する。該ＲＣＰ２４４は、ＳＬＥＥ内のオブジェクトから、ＲＣ１
８０によって実行される装置に特殊なコマンドへ、装置から独立したコマンドを
適応するという点でデバイスドライバに例えられる。該ＲＣＰ２４４は、該ＲＣ
Ｐ２４４内のリソースのベンだの間で共通の基本的なコマンドを実現するインタ
フェースとして記述することができる。該ＲＣＰ２４４は、ＩＤＮＡノード２０
４上で実行中の１つまたは複数の管理オブジェクトとして示されるように実現で
きるだろう。代わりに、この機能はＲＣ１８０の一部として提供できるだろう。
該ＮＭＳ２１２、リポジトリ２３０およびＭＯＣＥ２２８は、図５の説明でのそ
れらの要素の説明に一貫している。

【００４７】動作２２６が該ＮＭＳ２１２を該ＲＣ１８０に直接的に接続することに注記す
る。これは、ネットワークハードウェアの稼動中ステータスを監視する上でネッ
トワーク管理システムのより従来的な役割に相当する。これは、（例えば、周知
のＴＭＮアプローチを使用することによって）ＩＤＮＡアーキテクチャとは無関
係に実行することができる。加えて、該ＲＣ１８０は、それ以外のリソースコン
プレックス２５４に接続されてよい。直接シグナリングリンク２１４も、ＳＳ７
のようなシグナリング２１６が、呼処理環境に直接的に入ることができるように
、該ＩＣＰ１７２に入ると示されている。ネットワーク周辺装置でシグナリング
に割り込むことによって、該ＳＳ７メッセージは、該ＲＣ１８０を通過しなくて
も該ＣＩＰ１７２に直接的に移動することができる。付随するベアラーリンク２
１８がＲＣ２１８に接続する。

【００４８】図７は、ＩＣＰ１７２内での機能インタフェースの階層化を描く。該ＭＯＣＥ
２２８は、管理オブジェクトソフトウェアおよびその従属性が発生するシステム
である。該ＭＮＳ２１２は、ＩＣＰ−ＮＭＳエージェント２４０と呼ばれている
該ＩＰＣ１７２内で提供されるエージェント機能に接続することによって、該１
７２の実行を制御する。該ＮＭＳ２１２は、ＩＣＰ１７２上でローカルオペレー
ティングシステム（「ＬＯＳ」）２６０の動作を制御する。該ＮＭＳ２１２は、
プロセスの起動および停止、プロセステーブルのコンテンツおよびプロセスのス
テータスの照会、オペレーティングシステムパラメータの構成、およびＩＣＰ１
７２のホストとして働く汎用コンピュータシステムの性能の監視を含む、ＩＣＰ
１７２の動作を制御する。

【００４９】該ＮＭＳ２１２は、広域ネットワークオペレーティングシステム（「ＷＡＮＯ
Ｓ」）２６２の動作も制御する。該ＮＭＳ２１２は、ＷＡＮＯＳサポートプロセ
スの初期化と動作、およびＷＡＮＯＳライブラリの構成を、ＬＯＳ２６０および
該ＮＭＳＳＬＥＥ制御によって提供されるそれ以外のあらゆるインタフェース
の制御を介して制御する。該ＮＭＳ２１２は、ＩＣＰ１７２上で実行中の１つま
たは複数のＳＬＥＥ２４２の具体化および動作を制御する。該ＬＯＳ２６０は、
汎用コンピュータを動作するための市販の既製オペレーティングシステムである
。該ＷＡＮＯＳ２６２は、コンピューティングノード間の円滑な通信を容易にす
る、市販されている既製のミドルウェアソフトウェアパッケージ（例えば、オブ
ジェクト要求ブローカ）である。該ＳＬＥＥ２４２は、サービス処理アーキテク
チャを実現するソフトウェアインスタンスである管理オブジェクト２４４の実行
のホストとして働く。ＳＬＥＥ２４２は、該ＩＣＰ−ＮＭＳエージェント２４０
による該管理オブジェクト２４４の実行を制御するための手段を実現する。この
ようにして、ＳＬＥＥ２４２インスタンスは、管理オブジェクトソフトウェアの
配備と削除、管理オブジェクトインスタンスの具体化と破壊、管理オブジェクト
の対話と協同のサポート、ネーティブライブラリ２６４へのアクセスの管理、お
よび必要とされている制御を実現する際のＮＭＳ−ＩＣＰエージェント２４０と
の接続を行うことのできるソフトウェアプロセスである。

【００５０】該ネーティブライブラリ２６４は、ＬＯＳ２６０またはＷＡＮＯＳ２６２、お
よびネーティブ汎用コンピュータ実行（例えば、コンパイルされたＣライブラリ
）だけに依存するためにコーディングされるライブラリである。それらは、おも
にＳＬＥＥ２４２によって提供される固有の機能性を補助するために使用される
。

【００５１】ＳＬＥＥライブラリ２６６は、ＳＬＥＥ２４２内で実行するためにコーディン
グされるライブラリである。それらは、該ＳＬＥＥ２４２およびネーティブライ
ブラリ２６４によって提供される機能にアクセスすることができる。該管理オブ
ジェクト２４４は、ソフトウェアによってロードされ、該ＳＬＥＥ２４２によっ
て実行される。それらは、該ＳＬＥＥ２４２および該ＳＬＥＥライブラリ２６６
（ならびにおそらくネーティブライブラリ２６４）によって提供される機能性に
アクセスすることができる。

【００５２】該ＩＣＰ−ＮＭＳエージェント２４０は、ＮＭＳ２１２に該ＩＣＰ１７２の動
作を制御するための能力を与える。該ＩＣＰ−ＮＭＳエージェント２４０は、該
ＬＯＳ２６０の動作と構成、ＷＡＮＯＳ２６２の動作と構成、およびＳＬＥＥ（
複数の場合がある）２４２の具体化と動作を制御するための能力を実現する。該
提案されたサービス処理アーキテクチャは、拡大する抽象化の層内で動作する。
ただし、該ＳＬＥＥ２４２の観点からは、該ＮＭＳ２１２の制御下での対話であ
るオブジェクト（ソフトウェアインスタンス）の層である管理オブジェクト層、
および管理オブジェクト２４２またはＳＬＥＥ２４２自体の動作に補助的な機能
を提供する（該ＳＬＥＥ２４２または該ＬＯＳ２６０のどちらかに固有な）ソフ
トウェアの層であるライブラリ層２６４または２６６という２つの層しかない。
しかしながら、なんらかの点で、ＮＭＳ２１２は管理オブジェクトインスタンス
の正確なロケーションの制御をあきらめてよい。例えば、管理オブジェクトイン
スタンスは、要求に応じてなど、１つまたは複数のアルゴリズムまたはイベント
に基づいてあるノードから別のノードへ移行することが許されてよい。

【００５３】図８は、該ＳＬＥＥ２４２が仮想機械２７０内で実現されるようにＩＣＰ１７
２ないでの処理コンテキストのネスト化を示す。仮想機械２７０は、ＩＣＰ１７
２のＬＯＳ２６０内でのプロセスとして起動される。それから、該ＳＬＥＥ管理
コードがロードされ、ＶＭプロセス２７０によってメインプログラム２７２とし
て実行される。該メインプログラム２７２として実行している該ＳＬＥＥ管理コ
ードは、ＩＣＰ−ＮＭＳエージェント２４０機能性に接続し、クラステーブル２
７６から管理オブジェクトインスタンスの作成および破壊を監督する。例えば、
該クラステーブル２７２に常駐する管理オブジェクトＸは、複数のインスタンス
を有してよく説明され、各管理オブジェクトＸは、それ以降、ＮＭＳ制御下また
は加入者によって要求される処理サービスの過程でのどちらかで、必要とされて
いるＸ１、Ｘ２およびＸ３おして具体化される。仮想機械２７０の使用は、サー
ビス論理実行だけではなくサービス作成のための含意も伝える（ｃａｒｒｉｅｓ
）。

【００５４】該ＩＮアーキテクチャおよびＡＩＮアーキテクチャは、状態テーブルとして符
号化されているサービスの回りを回転する。このような状態テーブルの説明は、
符号化されたサービス機能を実行する、ハードコーディングされた状態機械エン
ジンによって解釈される。その結果、ＭＯＣＥ２２８およびサービス論理インタ
プリタ（「ＳＬＩ」）は、非常に相互依存しており、機能の固定されたパレット
だけを提供する。所望の新しいサービスに新しいビルディングブロック機能の追
加が必要とされる場合、該ＭＯＣＥ２２８とＳＬＩの両方とも変更され、コンパ
イルし直され、完全に試験され、調整された様式で配備されなければならない。
ＩＮアーキテクチャまたはＡＩＮアーキテクチャにおいて、新規ＳＬＩコードの
配備は、該ネットワーク内での短いダウンタイムを必要とする。対照的に、本発
明は、新しいＳＬＩと旧いＳＬＩが共存できるようにする複数の並行アーキテク
チャを提供する。

【００５５】本発明は、これらの不利な点を克服するために、仮想機械２７０を使用する。
仮想機械２７０は、ホストとして働くプログラムが本質的に任意の考えられる論
理機能、有限状態モデルとして容易に表されないものも表現できる機能（つまり
、論理演算子、変数、条件ジャンプ等）のこのような初歩的なレベルで実行可能
なコンピュータの機能上の同等物である。仮想機械２７０の汎用性は、状態テー
ブルより好まれる可能性のある形式での子処理論理の表現を可能にするためのこ
の用途では特に有効である。これは、典型的には高レベル機能をサポートし、プ
ログラム意味論および表現の柔軟性という点で制約を受ける論理インタプリタと
は異なる。ＩＮアーキテクチャおよびＡＩＮアーキテクチャでは、ＳＬＩは制限
された構造および機能の制限されたセットをサポートする。

【００５６】仮想機械２７０ソフトウェアが汎用コンピュータ上で実行されると、該仮想機
械２７０はアダプタ層として見られてよい。該仮想機械２７０内でプログラムと
して実行するコードは、それがあたかも処理機構上に直接的に実行しているかの
ように同じ制御の粒度および入出力および記憶装置へのアクセスを持ってよいが
、まさに同じプログラムは同等な仮想機械環境（つまり、）で実行中のまったく
異なる処理機構ハードウェアにも可搬可能であってよい。

【００５７】好まれている実施態様においては、サンマイクロシステムズ（ＳｕｎＭｉｃ
ｒｏｓｙｓｔｅｍｓ）によって開発された「Ｊａｖａ」プラットホームが、すべ
ての電話用とソフトウェアを表すあめに規定されている。Ｊａｖａが広く普及し
ているため、プラットホームの移植性、開発ツールおよびスキルのセットの遍在
、およびｆｔｐとｈｔｔｐなどの既存のサポートプロトコルという点で実際的な
優位点が与えられる。ＪａｖａはＣ＋＋に類似した様式でオブジェクト指向プロ
グラミングに対処する。該ＳＬＥＥ管理コード２７２および該ＳＬＥＥ２４２に
示されているすべての管理オブジェクト２７６は、Ｊａｖａバイトコードとして
符号化される。該ＳＬＥＥ管理コード２７２は、クラスをインストール、削除、
および具体化するため、インスタンスを照会し、削除するため、およびグローバ
ル値と実行／停止ステータスを確かめるための機能を含む。

【００５８】前記の優位点にも関わらず、ＳＬＥＥ２４２としての仮想機械、特にＪａｖａ
仮想機械の使用は、ＩＮアーキテクチャおよびＡＩＮアーキテクチャによって見
過ごされてきたように思われる。おそらく対話型音声応答のようなより一般的な
電話用途によって偏らされ、ＩＮ設計者およびＡＩＮ設計者は、機能の固定パレ
ットが、その明らかな簡略さまたは従来の呼処理モデルに対する類似性のために
適切かつ好ましいと考えた。ＡＩＮアプローチは、固定呼モデルおよび機能セッ
ト内だけでサービス作成の速度を高めるが、本発明は、新しいサービス要求およ
び新しい呼処理パラダイムを満たすために全体的に暗示的なサービスフレームワ
ークを容易に展開できる。

【００５９】オブジェクト指向ＳＬＥＥ２４２の選択は、ｃｏｉｎｓｔａｎｔｉａｔｅｄさ
れたオブジェクト間での従属性管理および共用機密保護を含む多くの重要な優位
点を提供する。モジュラリティ、多相性、および再利用などのオブジェクト指向
プログラミングの推奨される優位点は、本発明に従って該ＳＬＥＥ２４２内で実
現される。管理オブジェクト継承階層のため、呼モデル、プロトコルまたはなん
らかの他の態様の幅広い変更が、例えば単一ベースクラスへの相対的に局所化さ
れたコード変更によって達成されてよい。別の重要な優位点とは、オブジェクト
が各ＳＬＥＥ２４２内で具体化されるコーディングされたクラスが、該ＳＬＥＥ
２４２をディスエーブルまたはリブートすることなく更新することができるとい
う点である。

【００６０】好まれている実施態様においては、新規クラス実現コードのＳＬＥＥ２４２へ
の配備、または物理的なロケーションまたは動作状態に基づいたそこからのオブ
ジェクトの具体化を可能にする、または制限するために、実用可能な規則の一式
を符号化することができる。これらの規則は、ＮＭＳ２１２が、該ＳＬＥＥ２４
２によって起動される実際のオブジェクトコードの中への配備のために使用する
管理オブジェクト画像の一部などのさまざまなロケーションで符号化することが
できる。どちらのケースでも、該ＮＭＳ２１２は、具体化失敗時のためのエラー
処理手続を有するだろう。ロケーションの制限は、ノード（例えば、国、州、都
市、番地、または大域座標）の物理的なロケーションを特徴付けるための任意の
手段となるだろう。

【００６１】加えて、該セット内の該実用可能な規則間の矛盾点を解決するという方法が採
用できる。例えば、ある特定のオブジェクトが、Ａ地域とＢ地域の両方の中にあ
るノードＸで具体化されなければならず、実用可能な規則の一式が、該特定のオ
ブジェクトの具体化がＡ領域では禁じられているが、Ｂ地域では許されていると
規定する場合、該特定オブジェクトがノードＸで具体化できるかどうかに関して
矛盾が生じる。しかしながら、矛盾解決規則が、オブジェクトは許可されている
場合にだけ具体化することができると単に規定する場合は、該矛盾は解決され、
該特定のオブジェクトはノードＸで具体化されない。この実用可能な規則のセッ
トは、トランク管理クラスコードの配備または具体化を、該インテリジェント呼
処理機構が実際にトランクリソースを管理している状況に制限するために使用で
きるだろう。これらの規則は、特定の状態の料金請求書作成発行規則に合うよう
に作られた料金請求書作成発行処理機構インスタンスを、その状態の境界に制限
するためにも使用できるだろう。前述されたように、これらのロケーション制限
規則は、該クラスオブジェクトにとって内部または外部となることがある。

【００６２】図９を参照すると、本発明の好まれている実施態様に従った管理オブジェクト
のクラス階層が説明されるだろう。抽象ベースクラス管理オブジェクト２４４は
、すべての導出されたクラスが、該ＳＬＥＥ２４２内のオブジェクトとして適切
にサポートできることを保証するために、共通機能性および仮想機能性を含む。
具体的には、該サービス制御クラス２５２、呼制御クラス２５０、ベアラー制御
クラス２４８、およびリソースプロクシクラス２４６という４つの別個のサブク
ラスが図示される。

【００６３】該サービス制御クラス２５２は、すべてのサービス機能オブジェクトのための
ベースクラスである。該セッションマネージャクラス２８０は、セッションに関
係する情報および活動をカプセル化する。セッションは、１つまたは複数の呼あ
るいはネットワーク機能のそれ以外の呼出しを備えてよい。該セッションマネー
ジャクラス２８０は、セッションごとに一意の識別子を提供する。呼処理がノー
ドの様式で起こっている場合には、料金請求書作成発行情報は対照されなければ
ならない。呼ごとの一意の識別子は、高価な相互関係処理を必要とする代わりに
、対照を容易にする。サービス処理においては、プロトコルは抽象の連続層によ
ってラップされる（ｗｒａｐｐｅｄ）。最終的には、該プロトコルは、セッショ
ンマネージャの割当て／具体化を保証するほど十分に抽象化される（例えば、Ｓ
Ｓ７では、ＩＡＭメッセージの受信がセッション管理を有することを保証するだ
ろう）。

【００６４】該ベアラー能力クラス２８２が、ベアラー上でのサービスの品質を変更する。
サービス制御クラス２５２は、呼のサービスの品質（「ＱｏＳ」）での変更をイ
ネーブルしたり、毎秒５６Ｋｂｉｔからさらに高い速度へ移し、それから戻すな
どのベアラー機能を変更するすることもできる。例えば、半速度サブクラス２８
４が、呼のＱｏＳを通常の８Ｋｈｚサンプル速度の代わりに、４Ｋｈｚサンプル
速度まで劣化させる。ステレオサブクラス２８６は、ユーザが、左チャネルと右
チャネルをサポートするために、呼の中で２つのコネクションを形成できるよう
にする可能性がある。

【００６５】サービスアービトレーションクラス２８８は、サービス矛盾およびサービス対
話の仲裁を体系化する。これは、サービス制御クラス２５２、特に発信サービス
および成端サービスが矛盾する可能性があるために必要とされる。多くの実際的
な理由から、各サービス制御クラス２５２内で、サービス制御クラス２５２の互
いの種別との矛盾を解決する方法に関する認識を符号化することは望ましくない
。代わりに、矛盾が特定されると、矛盾するサービスおよびその未決要求に対す
る参照がサービスアービトレーションクラス２８８に渡される。それから、該サ
ービスアービトレーションクラス２８８は、おそらくローカルコンテキスト、構
成データ、および矛盾するサービスオブジェクトに対するそれ以降の照会を考慮
に入れ、、適切な方法を決定してよい。サービスアービトレーションクラス２８
８を有することにより、ハードコーディングされた機構または更新された暗黙の
機構のどちらかとは対照的に、明示的な文書化および矛盾解決アルゴリズムの符
号化が可能になる。さらに、サービスが更新または追加されても、既存のサービ
スは、単一サービス内での複数の関係性の変更を必要とするだろう、あらゆる矛
盾変更の理由を説明するために更新される必要はない。

【００６６】フィーチャクラス２９０は、電話と関連する機能の標準セット（例えば、３者
通話、通話待機）を実現する。１つのこのような機能は、意図された受信者に到
達するために、発信が既存の呼を切断できるようにするための無効２９２である
場合がある。別の共通機能は、それによって発信オファーを発信についての基準
セットに基づいて拒絶することができる呼ブロック２９４を含むことがある。

【００６７】サービス選別クラス２９６は、呼処理中に他のサービスを選択的に呼び出すた
めに使用され、サービス自体としてサブクラス化される。該サービス選別クラス
２９６は、柔軟でコンテキストに敏感なサービス起動に備え、いつ該サービスを
起動するのかを決定するために各サービスオブジェクト内で固定コードをゆする
必要性を不要にする。起動シーケンスは、サービス自体から分離される。例えば
、加入者Ａと加入者Ｂは同じ機能セットにアクセスできる。加入者Ａは、ある特
定の信号セットを使用して、自分のサービスの１つまたは複数を選択的に呼び出
すことを選ぶ。加入者Ｂは自分のサービスを起動するために別の信号セットを使
用することを好む。加入者間の唯一の違いは、彼らがそのサービスを起動する方
法である。したがって、選択プロセスをサービス自体から分割することが望まし
い。２つの使用可能な解決策がある。加入者Ａと加入者Ｂのための該サービス選
択プロセスは、別個のサービス選別クラス２９６内で符号化できるか、あるいは
１つのサービス選別クラス２９６は適切な情報を示すために加入者ごとにプロフ
ァイルを使用することができる。これは、そのサービスセットが分離されるさら
に多くのユーザに適用するために汎用化することができる。さらに、サービス選
別クラス２９６の使用により、指定された呼のコンテキストまたは進行に基づい
てサービスへのアクセスのマッピングを改変できる。このクラスのインプリメン
テーションにより、多様な呼参加者が、おそらく異なる起動入力を使用してさま
ざまなサービスを起動することができる。従来の技術では、すべての交換機ベン
ダが、柔軟性を欠いたサービス選択方式を送達し、この能力を妨げた。

【００６８】媒体独立サービスクラス２９８は、蓄積交換３００、一斉送信、リダイレクト
、強制排除、および多数共同コネクションなどの、音声、ファックス、ｅ−メー
ル、およびその他を含むさまざまな媒体種別に適用するサービス制御クラスの１
つの種別である。各媒体種別に適用できるサービス制御クラス２５２が開発され
る場合には、サービス制御クラス２５２は再利用可能なサービス制御クラス２５
２に分けることができる。該サービス制御クラス２５２が媒体従属機能および媒
体独立機能（つまりサービスおよびセット媒体従属ラッパーＳＣを――媒体種別
ごとに１つ実現する媒体独立ＳＣ）に分ける場合媒体独立クラス２８９から導出
されるように、蓄積交換３００はある媒体種別のメッセージまたはデータストリ
ームを記憶する汎用能力およびそれから何らかのイベントに基づいてそれを後に
送達する能力を提供する。リダイレクトは、指定された条件に基づいて、ある論
理アドレスから別の論理アドレスへコネクションを移動する能力を提供する。こ
の概念が、呼転送（全種別）、ＡＣＤ／ＵＣＤ、ＷＡＴＳ（１−８００サービス
）、ｆｉｎｄ−ｍｅ／ｆｏｌｌｏｗ−ｍｅおよび移動ローミング等の基礎である
。交渉済みまたはそれ以外の場合どちらかの強制排除は、通話待機、優先順位強
制排除等のサービスを含む。ＱｏＳ変調コネクションは、音声／ファックス、ス
トリームビデオおよびファイル転送などのパケットネットワークを超えた将来の
サービスを実現する。多数共同コネクションは３者およびＮ者のテレビ電話等を
含む。ユーザ制御および入力はおもに電話上のキーを使用して実現されるが、音
声認識は、将来のユーザ制御および入力のために使用されることが予想される。

【００６９】コネクションマネージャクラス３０２は、呼に関係する多様なベアラー制御２
４８のコネクションの調整および調停を担当する。このようにして、複数の呼に
おける関係者間の結合性を管理することの複雑さはカプセル化され、他のすべて
のサービスから取り除かれる。サービスおよび呼処理は、コネクションから切り
離される。これが、１対多として呼をコネクションにマッピングすることのパラ
ダイムを壊す。これで、呼から呼へのマッピングは多対多となる。

【００７０】アーキテクチャ内の該コネクションマネージャクラス３０２は、スタンドアロ
ンで動作する、あるいはピアとして協力するように設計されている。動作中、該
サービス制御クラス２５２は、コネクションマネージャクラス３０２に呼のセグ
メントを追加、修正、および削除するという要求を提示する。これらの変更を達
成することはコネクションマネージャクラス３０２の責任である。以下を注記す
ること。コネクションはそれ自体および自発的にリソース、あるいはリソースの
属性のどちらかと見なすことができるため、コネクションマネージャクラス３０
２はプロクシとして、あるいは基本リソース管理機能の１つの態様として実現す
ることができる。

【００７１】該呼制御クラス２５０は、一般的には電話に使用される基本的な有限状態機械
などの基本的な呼処理を実現し、呼処理がどのように実行されるのかを指定する
。２つのクラスは発信（電話をかける）３０４および成端（電話を受ける）３０
６の機能区分に沿って導出されてよい。

【００７２】該ベアラー制御クラス２４８は、リソースプロクシ２４６を介して、リソース
コンプレックス１８０へおよびリソースコンプレックスから特定の信号およびイ
ベントを、呼制御オブジェクト２５０によって理解できる共通の信号およびイベ
ントに適応させることを目的としている。このクラスから導出されるオブジェク
トの１つの予想される役割とは、加入者回線番号、サービスのクラス、アクセス
の種別等の呼の発信端についての情報を収集することである。サブクラスは、回
線数またはシグナリングに関連するチャネルに基づいて区別されてよい。これら
は、ＩＳＤＮ一次インタフェース３１０内の２３のベアラーチャネルごとの単一
シグナリングチャネルに適用するように、チャネル関連クラス３０８、単一回線
を制御するためにダイヤル呼出しを使用する、アナログ電話３１４によって類型
化されるようなチャネル単一クラス３１２、およびベアラーチャネルからまった
く切り離されているＳＳ７シグナリング３１８によって表されるチャネル共通ク
ラス３１６を含んでよい。

【００７３】該リソースプロクシクラス２４６は、実行環境を、現実世界の交換機およびベ
アラーネットワークのそれ以外の要素に接続すること専用である。このレベルで
実現され、すべての後続クラスによって継承される内部状態の例は、使用中対休
止、および空き対使用中っである。意図されている導出クラスは、電話３２０（
標準２５００セット用標準プロクシ）、音声応答装置（「ＶＲＵ」）３２２（音
声応答装置用標準プロクシ）、ＩＭＴとランクコネクション３２４（デジタルト
ランク（Ｔ１／Ｅ１）回線用標準プロクシ）、およびリソースコンプレックス１
８０内のリソースの特殊な種別に対応する、モデムコネクション３２６（デジタ
ルモデム用標準プロクシ）である。

【００７４】今度は、図１０を参照すると、いくつかの具体化されたオブジェクトの動的論
理関係が示されるだろう。現実世界の電話Ａ３００は、リソースコンプレックス
プロクシ（図示されていない）を通して該ＳＬＥＥ２４２内のオブジェクトのチ
ェーンに結合される。ＲＣ＿ＰｈｏｎｅＡ３３２、ＢＣ＿ＰｈｏｎｅＡ３
３４およびＣＣ＿ＯｒｉｇＡ３３６オブジェクトは、いつでも該ＳＬＥＥ２４
２内で具体化されたままである。状態変化およびメッセージ通信はオンフックま
たはオフフックになるときにつねに、あるいはキーパッドが押されると、現実世
界の電話がこれらのオブジェクトの間で発生する。同様に、電話Ｂ３３８は該
ＳＬＥＥ２４２内でＲＣ＿ＰｈｏｎｅＢ３４０、ＢＣ＿ＰｈｏｎｅＢ３
４２、およびＣＣ＿ＴｅｒｍＢ３４４オブジェクトのチェーンによって表さ
れる。呼ブロックＢ３４６のインスタンスはＣＣ＿ＴｅｒｍＢ３４４と関
連し、加入者Ｂが過去に呼ブロック機能を電話Ｂ３３８のために実施したこと
があることを示す。

【００７５】加入者Ａがオフフックになると、ＲＣ＿ＰｈｏｎｅＡ３３２は通知を受け
取り、それを、セッションを開始するために該通知をＳｅｓｓｉｏｎ＿Ｍａｎａ
ｇｅｒＡ３４８に伝搬するＢＣ＿ＰｈｏｎｅＡ３３４に送る。該Ｓｅｓ
ｓｉｏｎ＿ＭａｎａｇｅｒＡ３４８は、セッション起動に関連するデフォル
トサービス制御クラスをアルゴリズムにより（ａｌｇｏｒｉｔｈｍｉｃａｌｌｙ
）決定する（つまり、それはＲＣ＿ＰｈｏｎｅＡ３３２用のデフォルトとして
指定される構成の中をルックアップする）。該Ｓｅｓｓｉｏｎ＿Ｍａｎａｇｅｒ
Ａ３４８は、該Ｓｅｒｖｉｃｅ＿ＤｅｓｃｒｉｍｉｎａｔｏｒＡ３５０
がデフォルトサービス制御クラスであることに気付き、それを呼び出す。

【００７６】該Ｓｅｒｖｉｃｅ＿ＤｉｓｃｒｉｍｉｎａｔｏｒＡ３５０は、ＢＣ＿Ｐｈ
ｏｎｅＡ３３４に、最終的に起動されるサービスを決定するために十分な情
報を収集するように命令する（例えば、それは、加入者Ａに対し、サービスコー
ドおよび／または宛先数字をダイヤルするようにプロンプトを出す）。この例で
は、該サービス判別子３５０が、加入者ＡがＳｔｏｒｅ＿ａｎｄ＿Ｆｏｒｗａｒ
ｄサービス３５２（例えば、音声メール機能）を起動することを意図しているの
か、それとも半速度呼３５４（ベアラーの能力を調整するサービスである。それ
は大域幅を半減する）を起動することを意図しているのか、あるいは無効３５６
（ターミネータに強制的に発信を受入れさせるサービス）を起動すること意図し
ているのかを判断する。

【００７７】加入者Ａは、電話Ｂ３３８への無効の起動を示すために該数字をダイヤルす
る。該サービス判別子３５０は、無効機能３５６を起動する。該無効サービス制
御３５６は、加入者Ａが電話をかけることを希望している場所を決定するために
十分な情報を収集する。該無効サービス制御３５６は、Ｃｏｎｎｅｃｔｉｏｎ＿
ＭａｎａｇｅｒＡ３５８を介して呼を提供するために発信呼制御（ＣＣ＿Ｏ
ｒｉｇＡ３３６）を呼び出す。該Ｃｏｎｎｅｃｔｉｏｎ＿Ｍａｎａｇｅｒ
Ａ３５８は、その上で起動されているＣａｌｌ＿ＢｌｏｃｋサービスＢ３４６
に接する成端呼制御、ＣＣ＿ＴｅｒｍＢ３３４に接する。該呼ブロックサー
ビス３４６は、該ＣＣ＿ＴｅｒｍＢ３４４ｗと押して該Ｃｏｎｎｅｃｔｉｏｎ
＿ＭａｎａｇｅｒＡ３５８に、呼が拒絶された旨を通知する。ＣＣ＿Ｏりｇ
Ａ３３６は、該コネクションマネージャＡ３５８に、無効サービス制御３
５６のために拒絶を受け入れないように指示した。該無効３５６およびＣａｌｌ
＿Ｂｌｏｃｋ３４８サービスは現在矛盾している。

【００７８】該Ｃｏｎｎｅｃｔｉｏｎ＿Ｍａｎａｇｅｒ３５８は、該矛盾を引証する該サ
ービスアービトレーションサービス３６０を呼び出す。それに提供された情報に
基づく該サービスアービトレーションサービス３６０は、アルゴリズムにより勝
者を決定する（例えば、成端側呼制御が該呼を受け入れなければならない）。Ｃ
Ｃ＿ＴｅｒｍＢ３４４は発信試みを受け入れ、それは適切なシグナリングを
該ＢＣ＿ＰｈｏｎｅＢ３４２およびＲＣ＿ＰｈｏｎｅＢ３４０に伝搬す
る。ＰｈｏｎｅＢ３３８はリンギングを開始し、加入者Ｂが応答する。結果
として生じる応答イベントは、該ＣＣ＿ＴｅｒｍＢ３３４を通ってずっと該
ＣＣ＿ＯｒｉｇＡ３３６まで渡される。この点で、該Ｃｏｎｎｅｃｔｉｏｎ
＿ＭａｎａｇｅｒＡ３５８が音声経路をセットアップし、加入者ＡとＢが話を
している。該呼は現在安定した状態にある。該サービスマネージャ３４８は、該
呼の無事完了を記録する。今度は、呼制御３３６と３４４の両方が、該呼を終了
する成端信号を待機している。加入者Ｂが電話を切る。メッセージは両方の呼制
御３３６と３４４に伝搬される。該呼制御３３６と３３４はその通話への酸化を
終了する。該コネクションマネージャＡ３５８はコネクションを切断し、該セ
ッションマネージャ３４８が該呼の成端を記録する。加入者Ａは電話を切り、該
サービスマネージャ３４８が該呼の該レコードを請求書作成発行システムに渡す
。当業者が知るように、インスタンスをそれらが必要とされる以前に具体化し、
管理することの性能利得に対して、応需でオブジェクトを具体化する柔軟性の価
値に関して妥協を図ることができる。

【００７９】図１１は、本発明に従った一般呼処理のプロセスステップのフローチャートで
あり、そこでは対話は高速環境で発生し、呼処理インテリジェンスが指定された
呼の始まりから適用されてよい。該カスタマは、ブロック３７０で受話器を取り
上げ、ダイヤルを回し始める。該回線状態およびダイヤルされた数字の各セット
は、ＲＣＰを介したＩＣＰ／ＳＬＥＥ内の増分イベントのように、あるいは代わ
りにブロック３７２内の直接ＳＳ７インク上で中央局からＩＣＰに直接的に送ら
れるシグナリングのように見える。該回線に関連するリソース制御、ベアラー制
御、および呼制御インスタンスが各イベントに応答し、ブロック３７４で必要に
応じてサービスオブジェクトを具体化する。該サービスオブジェクトは追加解釈
をそれ以降のイベントに適用してよく、その他のサービスオブジェクトを具体化
してよい。リソース制御、ベアラー制御、呼制御、およびサービス制御オブジェ
クトにあらゆるデータベースリソースを加えたものの間の対話は、高速環境内で
発生する。サービスを実現するためのリソース制御に対するコマンドはＲＣＰを
通してディスパッチされ、呼活動の包括的なレコードが記憶されるか、あるいは
ブロック３７６で料金請求書作成発行目的のために直ちに処理される。単一呼ま
たはセッション処理が、ブロック３７８で完了する。

【００８０】図１２は、本発明に従った管理オブジェクトを使用する一般サービス作成のた
めのプロセスステップを示す。管理オブジェクトを使用するサービス作成は、完
全にネットワーク所有者の管理内にあり、かなり高速であり、一貫したつ−ルの
セットを使用して統一環境内で実行される。新しい機能は、ブロック３８０で新
規サービス、新規呼状態および新規プロトコルを伴い要求される。該ネットワー
ク所有者は、ブロック３８２で、必要に応じて、管理オブジェクト（ベアラー制
御、呼制御およびサービス制御）を修正するために専用のサービス設計者または
プログラマを使用する。新規機能がブロック３８４で検証されるまで、試験ＳＬ
ＥＥで管理オブジェクトの新しいバージョンを使用する反復装置試験。それらの
他のオブジェクトおよびブロック３８６で修正されたオブジェクトと対話するシ
ステム部分とだけに関連した管理オブジェクトの新しいバージョンの統合試験。
該ＮＭＳはブロック３８８でＩＰＣに新しい管理オブジェクトを配備するために
使用される。該新規機能のインプリメンテーションは、ブロック３９０で完了す
る。

【００８１】図１３は、本発明に従った同じターゲット環境のために互換性のあるオブジェ
クトを作成するためのサービス作成中の類似したツールの使用を図解する。ＭＯ
ＣＥ２２８においては、さまざまな種類の機能性（コンテキストＡ４００、コ
ンテキストＢ４０２、およびコンテキストＣ４０４）の開発者が、同じター
ゲット環境のために互換性のあるオブジェクト（ＭＯタイプ１４１０、ＭＯ
タイプ２４１２およびＭＯタイプ３４１４）を作成するために、類似ツール
（ツールＡ４０６とツールＢ４０８）を使用する。ツール（ツールＡ４０
６およびツールＢ４０８）ごとの該パレット（パレットＡ４１６、パレット
Ｂ４１８、およびパレットＣ４２０）は、開発のタイプに関して適切に異な
る。各管理オブジェクト（ＭＯタイプ１４１０、ＭＯタイプ２４１２およ
びＭＯタイプ３４１４）は、入力データ（ＭＯタイプ１入力形式Ａ４２２、Ｍ
Ｏタイプ２入ろく形式Ａ４２４、およびＭＯタイプ３入力形式ＡＤ４２６）およ
びコンテキスト情報（コンテキスト情報Ａ４２８、コンテキスト情報Ｂ４３０、
コンテキスト情報Ｃ４３２）を、ツール（ツールＡ４０６とツールＢ４０８）
およびパレット（パレットＡ４１６、パレットＢ４１８およびパレットＣ
４２０）を使用して結合することによって作成される。該管理オブジェクト（Ｍ
Ｏタイプ１４１０、ＭＯタイプ２４１２、およびＭＯタイプ３４１４）は
、それからリポジトリ２３０に記憶される。

【００８２】図１４は、ツールごとのパレットが、本発明に従って新規機能部分に応えてど
のように変化するのかを示す。ツールごとの該パレットは、それ以外の開発者に
よって導入される新規機能部分に応えて変化してよい。

【００８３】図１５は、管理オブジェクト作成環境使用フローを図解する。該ソフトウェア
構成部品タイプはブロック４５０で選択され、構成がブロック４５２で選択され
、適切なツールがブロック４５４で起動される。該ユーザはツールＡ４５６、ツ
ールＢ４５８またはツールＣ４６０を選択してよい。次に、結果がブロック４６
２で収集され、構成がブロック４６４で更新される。

【００８４】図１６は、管理オブジェクト作成環境ソフトウェアスタックを図解する。該管
理オブジェクト作成環境ソフトウェアスタックのベースは、開発インフラストラ
クチャ４７０である。該開発インフラストラクチャ４７０は、管理オブジェクト
の作成に関連する情報を読み取り、記憶するためにソフトウェア構成データベー
ス４７２と接続する。該ユーザは、その結果ツールアダプタＡ４７４、Ｂ４７６
およびＣ４４７８を活用し開発インフラストラクチャ４７０と接続する、ソフト
ウェア作成ツールＡ４８０、Ｂ４８２、およびＣ４８４を使用して管理オブジェ
クトを作成する。

【００８５】図１７は、統一実行環境がどのようにして、開発者がそれによって該ＳＬＥＥ
のためにオブジェクトをオーサリングするツールの簡略化された作成および修正
にも対処すのかを図解する。

【００８６】いくつかの好まれている実施態様は、前記に詳細に説明されてきた。本発明の
範囲が、説明されたものとは異なるが、クレームの範囲内の実施態様も含むこと
が理解されなければならない。

【００８７】例えば、汎用コンピュータは、特に１種類の用途のために作られていないコン
ピューティングデバイスであると解釈される。該汎用コンピュータは、本発明を
実現するために必要とされる機能を実行できる任意のサイズの任意のコンピュー
ティングデバイスである場合がある。

【００８８】さらに、例えば、同様の特性を持つ他の同等なプログラミング言語と置きかえ
られ、本発明を実現するのに必要な同様の機能を果たすような、「Ｊａｖａ」プ
ログラミング言語である。

【００８９】それ以外の用語だけではなく、これらの用語のここでの使用も、本発明をこれ
らの用語だけに制限すると意図されていない。使用されている用語は同義である
、および／または同等な事柄を参照するそれ以外の用語と交換することができる
。包含の言葉は、本発明の範囲を考慮する上で非網羅的と解釈されるべきである
。また、本発明の多様な実施態様が、ハードウェア、ソフトウェアまたはマイク
ロコーディングされたファームウェアを利用できる、あるいはそれらで実現でき
ることも理解される必要がある。

【００９０】本発明は、前述された実施態様に関連して海事、説明されてきたが、本発明の
精神および範囲内の多数の変更、変形および修正が可能であることが、当業者に
明らかになるだろう。その結果、したがって、以下のクレームがこのような変形
および修正を含むものとすることが意図される。

【図面の簡単な説明】

【図１】本発明を含む多様な交換アーキテクチャの論理的な表記の図であ
る。

【図２】従来の技術に従った典型的なインテリジェントネットワーク構成
を利用する電気通信システムの図である。

【図３】従来の技術に従った汎用呼処理のためのフローチャートである。

【図４】従来の技術に従った汎用サービス作成のためのフローチャートで
ある。

【図５】本発明に従ったインテリジェント分散型ネットワークアーキテク
チャを利用する電気通信システムの図である。

【図６】本発明に従った仮想機械がインテリジェント分散型ネットワーク
アーキテクチャを利用する電気通信システムの論理図および機能図である。

【図７】本発明に従ったインテリジェント呼処理機構内の機能インタフェ
ースの階層化を図解する図である。

【図８】それにより本発明に従ったサービス論理実行環境をサポートする
、処理コンテンツの入れ子構成を示すベン図である。

【図９】本発明に従ったインテリジェント呼処理機構内で管理されたオブ
ジェクトのクラス階層を示す図である。

【図１０】本発明に従ったある呼処理機構内での管理されたオブジェクト
の対話を示す図である。

【図１１】本発明に従った汎用呼処理のためのフローチャートである。

【図１２】本発明に従って管理されたオブジェクトを使用する汎用サービ
ス作成のためのフローチャートである。

【図１３】本発明に従った同じターゲット環境のための互換性のあるオブ
ジェクトを作成するための、サービス作成中の類似するツールの使用を示す図で
ある。

【図１４】ツールごとのパレットが、本発明に従った新規機能部分に応え
てどのように変化してよいかを示す図である。

【図１５】管理オブジェクト作成環境使用フローを示す図である。

【図１６】管理オブジェクト作成環境スタックを示す図でる。

【図１７】統一された実行環境が、またどのようにして、開発者がそれに
よってＳＬＥＥ用にオブジェクトをオーサリングするツールの簡略化作成および
修正に対処するのかを示す図である。

【符号の説明】

２２……サービス処理機能２４……呼処理２６……通信設備処理１７０……通信システム１７２……インテリジェント呼処理機構１８０……リソースコンプレックス

───────────────────────────────────────────────────── フロントページの続き (72)発明者ケルヴィン・ポーターアメリカ合衆国・テキサス・75252・ダラス・カーラ・ドライブ・17319 (72)発明者ケン・ランボーアメリカ合衆国・テキサス・75002・アレン・チャンドラー・コート・9801 (72)発明者キャロル・ウォラーアメリカ合衆国・テキサス・75002・アレン・サウス・マローン・ロード・302 (72)発明者ウェンディー・ウォンアメリカ合衆国・テキサス・78287・ダラス・ケイプ・コーラル・ドライブ・4816 (72)発明者ジョージ・ヤオアメリカ合衆国・テキサス・75023・プラノ・ルガー・ドライブ・2052 Ｆターム(参考） 5K024 BB09 5K026 AA03 AA23 BB02 CC01 CC04 CC07 FF02 GG01 GG12 5K030 GA11 GA15 HB06 HC02 JT01 LD19 LE03 MC09 5K051 AA09 AA10 CC01 DD01 EE01 GG15

Claims

【特許請求の範囲】

【請求項１】通信システムで使用するためのインテリジェント呼処理機構
であって、複数の機能を有し、そこでは該機能の少なくとも１つがサービス処理機能であ
り、該機能の少なくとも１つが呼処理であり、該機能の少なくとも１つが通信設
備処理である論理プラットホームと、該複数の機能を実行するための処理機構とを備える、該インテリジェント呼処理機構。
【請求項２】論理プラットホームが仮想機械である、請求項１に記載のイ
ンテリジェント呼処理機構。
【請求項３】該複数の機能がオブジェクト指向言語で符号化される、請求
項２に記載のインテリジェント呼処理機構。
【請求項４】該複数の機能がＪａｖａ（登録商標）バイトコードとして符号化される、請求項２に記載のインテリジェント呼処理機構。
【請求項５】該論理プラットホームがオブジェクト指向プラットホームで
あり、該複数の機能が管理オブジェクトである、請求項１に記載のインテリジェ
ント呼処理機構。
【請求項６】該処理機構が、少なくとも１つの汎用コンピュータと、少なくとも１つのデータ記憶装置と、該汎用コンピュータを該データ記憶装置に接続する高速通信リンクとを含む、請求項１に記載のインテリジェント呼処理機構。
【請求項７】汎用コンピュータがマイクロプロセッサアーキテクチャに基
づく、請求項５に記載のインテリジェント呼処理機構。
【請求項８】該汎用コンピュータ、該データ記憶装置および該高速ネット
ワークが、冗長処理、データ記憶、および通信を提供するように構成される、請
求項５に記載のインテリジェント呼処理機構。
【請求項９】さらに、該処理機構を、対処（ｐｒｏｖｉｓｉｏｎｉｎｇ）
、料金請求書作成発行、およびサービス回復というグループから構成される少な
くとも１つの遺産（ｌｅｇａｃｙ）機能を提供する付加処理機構に通信可能であ
るようにリンクするための第１コネクションを含む、請求項１に記載のインテリ
ジェント呼処理機構。
【請求項１０】さらに、該プロセッサを直接シグナリングリンクに通信可
能であるようにリンクするための第２コネクションを含む、請求項１に記載のイ
ンテリジェント呼処理機構。
【請求項１１】さらに、該プロセッサを少なくとも１つのリソースコンプ
レックスに通信可能であるようにリンクするための第３コネクションを含む、請
求項１に記載のインテリジェント呼処理機構。
【請求項１２】さらに該処理機構を広域ネットワークに通信可能であるよ
うにリンクするための第４コネクションを含む、請求項１に記載のインテリジェ
ント呼処理機構。
【請求項１３】該処理機構が、新規機能と旧機能が共存できるようにする
柔軟なアーキテクチャを提供する、請求項１に記載の該インテリジェント呼処理
機構。
【請求項１４】該複数の機能が、異なるコンピュータアーキテクチャの少
なくとも２つの異なるコンピューティングデバイスに移動可能である、請求項１
に記載のインテリジェント子処理機構。
【請求項１５】通信ネットワーク内のインテリジェント交換ノードであっ
て、論理プラットホーム内で複数の機能を実行するための処理機構を有し、そこで
は該機能の少なくとも１つがサービス処理であり、該機能の少なくとも１つが呼
処理であり、該機能の少なくとも１つの通信設備処理である、インテリジェント
呼処理機構と、該インテリジェント呼処理機構に通信可能であるようにリンクされ、該インテ
リジェント呼処理機構から論理的に分離されるリソースコンプレックスとを備える、該インテリジェント交換ノード。
【請求項１６】リソースコンプレックスからインテリジェントプロセッサ
への通信リンクが、さらに冗長通信リンクを備える、請求項１４に記載のインテ
リジェント交換ノード。
【請求項１７】該リソースコンプレックスから該インテリジェント処理機
構への通信リンクが、高速データ通信リンクである、請求項１４に記載のインテ
リジェント交換ノード。
【請求項１８】リソースコンプレックスプロクシが、該インテリジェント
呼処理機構から該リソースコンプレックスへのインタフェースを含む、請求項１
４に記載の、該インテリジェント交換ノード。
【請求項１９】該リソースコンプレックスが、ベアラー、シグナリング、
およびコネクションのサービスを提供する物理的なデバイスまたはリソースの集
合体を含む、請求項１４に記載の、該インテリジェント交換ノード。
【請求項２０】該リソースコンプレックスが、標準電話コネクションを介
して複数の加入者、および交換ネットワークに接続するインタフェースを含む、
請求項１４に記載の該インテリジェント交換ノード。
【請求項２１】該リソースコンプレックスが、カスタマシステムへの複数
のインタフェースを含む、請求項１４に記載のインテリジェント交換ノード。
【請求項２２】該リソースコンプレックスが、通信設備およびネットワー
ク管理処理をサポートするために、標準化されたインタフェースを活用する、請
求項１４に記載のインテリジェント交換ノード。
【請求項２３】該リソースコンプレックスが、少なくとも１つの交換機機
構を含む、請求項１４に記載のインテリジェント交換ノード。
【請求項２４】該リソースコンプレックスが、実際の呼伝送路内で情報を
処理し、情報に作用するインテリジェント周辺装置を含む、請求項１４に記載の
インテリジェント交換ノード。
【請求項２５】該インテリジェント周辺装置が、デジタル信号処理技法を
使用してリアルタイムでデータを処理する、請求項２３に記載のインテリジェン
ト交換ノード。
【請求項２６】さらに、該リソースコンプレックスを動作リンクを介して
ネットワーク管理システムに通信可能であるようにリンクするための手段を含む
、請求項１４に記載のインテリジェント交換ノード。
【請求項２７】さらに、該リソースコンプレックスを直接リンクのベアラー部分に通信可能であるよう
にリンクするための第１コネクションと、該処理機構を該直接リンクのシグナリング部分に通信可能であるようにリンク
するための第２コネクションとを含む、請求項１４に記載のインテリジェント交換ノード。
【請求項２８】さらに、複数の処理副要素を監視し、操作するための手段
を備え、該副要素が複数の機能の一部である、請求項１４に記載のインテリジェ
ント交換ノード。
【請求項２９】さらに、該複数の機能の使用量を監視するための手段と、該複数の機能から選択された機能を排除するための手段とを含む、請求項１４に記載のインテリジェント交換ノード。
【請求項３０】該処理機構が、サービス層実行環境をロード、実行する仮
想機械プロセスを実行する、請求項１４に記載のインテリジェント交換ノード。
【請求項３１】該サービス層実行環境が、該サービス処理アーキテクチャ
を実現し、管理オブジェクトベースクラスから導出される複数のソフトウェアイ
ンスタンスのホストとして働く、請求項２９に記載のインテリジェント交換ノー
ド。
【請求項３２】該複数のソフトウェアインスタンスが、ネットワーク管理
システムによって必要に応じて、あるいは加入者によって要求されるサービスの
処理の間に具体化することができる、請求項３０に記載のインテリジェント交換
ノード。
【請求項３３】該サービス層実行環境が、複数の管理オブジェクトの実行
を管理する、請求項２９に記載のインテリジェント交換ノード。
【請求項３４】複数の管理オブジェクトが、オブジェクト指向言語で符号
化される、請求項３２に記載のインテリジェント交換ノード。
【請求項３５】該複数の管理オブジェクトがＪａｖａバイトコードとして
符号化される、請求項３２に記載のインテリジェント交換ノード。
【請求項３６】該サービス層実行環境が、管理オブジェクト層よびライブ
ラリ層を含む、請求項２９に記載のインテリジェント交換ノード。
【請求項３７】実用可能な規則一式が、ある特定の管理オブジェクトが配
備、具体化できるかどうかを判断するために使用される、請求項２９に記載のイ
ンテリジェント交換ノード。
【請求項３８】該実用可能な規則一式が該特定の管理オブジェクト内で符
号化される、請求項３５に記載のインテリジェント交換ノード。
【請求項３９】該実用可能な規則一式が、ネットワーク管理システムで符
号化される、請求項３５に記載のインテリジェント交換ノード。
【請求項４０】該実用可能な規則一式が、その間に該管理オブジェクトア
配備または具体化されることを許可されるまたは禁止される論理状態を指定する
、請求項２９に記載のインテリジェント交換ノード。
【請求項４１】該実用可能な規則一式が、該管理オブジェクトが、配備ま
たは具体化されることを許可または禁止される物理ロケーションを指定する、請
求項２９に記載のインテリジェント交換ノード。
【請求項４２】該ネットワーク管理システムが、該管理オブジェクトが配
備または具体化されるときに、該実用可能な規則一式内で発生するあらゆる矛盾
を解決する、請求項２９に記載のインテリジェント交換ノード。
【請求項４３】該サービス層実行環境が、さらに、複数の管理オブジェクトを配備、削除するための手段と、複数の管理オブジェクトインスタンスを具体化、照会および破壊するための手
段と、複数の管理オブジェクトの対話および共同をサポートするための手段と、ネーティブライブラリへのアクセスを管理するための手段と、制御信号を受信、実現するためにネットワーク管理システムへのインタフェー
スと通信するための手段と、複数のグローバル値を確かめるための手段と、複数の管理オブジェクトの起動および停止を制御するための手段とを含む、請求項２９に記載のインテリジェント交換ノード。
【請求項４４】該サービス層実行環境が、サービス制御クラス、呼制御ク
ラス、ベアラー制御クラス、およびリソースプロクシクラスを含む、管理オブジ
ェクトのベースクラスを含む、請求項２９に記載のインテリジェント交換ノード
。
【請求項４５】該サービス制御クラスが、さらに、セッションマネージャと、ベアラー機能クラスと、サービスアービトレーションクラスと、フィーチャクラスと、サービス判定子クラスと、媒体独立サービスクラスと、コネクションマネージャクラスとを含む、請求項４２に記載のインテリジェント交換ノード。
【請求項４６】呼制御クラスが、さらに、発信クラスおよび成端クラスを
含む、請求項４２に記載のインテリジェント交換ノード。
【請求項４７】該ベアラー制御クラスが、特殊な信号およびイベントを、
リソースプロクシを介して該リソースコンプレックスへ、および該リソースコン
プレックスから適応する、請求項４２に記載のインテリジェント交換ノード。
【請求項４８】該リソースプロクシクラスが、ベアラーネットワーク内の
複数の交換デバイスに実行環境をインタフェースする、請求項４２に記載のイン
テリジェント交換ノード。
【請求項４９】該リソースプロクシクラスが、さらに、電話クラスと、音声応答装置クラスと、トランク回路クラスと、モダンクラスとを含む、請求項４２に記載のインテリジェント交換ノード。
【請求項５０】各インテリジェント分散型ネットワークノードが、該機能の少なくとも１つがサービス処理であり、該機能の少なくとも１つが呼
処理であり、該機能の少なくとも１つが通信設備処理である、論理プラットホー
ム内で複数の機能を実行するための処理機構を有するインテリジェント呼処理機
構と、該インテリジェント呼処理機構に通信可能であるようにリンクされ、該インテ
リジェント呼処理機構から論理的に分離されるリソースコンプレックスと、を有する複数のインテリジェント分散型ネットワークノードと、広域ネットワークおよび複数のインテリジェント交換ノードを監視し、制御す
るためのネットワーク管理システムと、該複数のインテリジェント分散型ネットワークノードおよびネットワーク管理
システムを相互接続する広域ネットワークとを備える、インテリジェント通信ネットワーク。
【請求項５１】該広域ネットワークが同期光ネットワークである、請求項
４８に記載のインテリジェントネットワーク。
【請求項５２】該広域ネットワークが、１つの共通したオブジェクト要求
ブローカアーキテクチャを活用する、請求項４８に記載のインテリジェントネッ
トワーク。
【請求項５３】該ネットワーク管理システムが、電気通信管理ネットワー
クに準拠するフレームワーク内で動作する、請求項４８に記載のインテリジェン
トネットワーク。
【請求項５４】該ネットワーク管理システムが、サービスおよび機能が、
該複数のインテリジェント分散型ネットワークノード全体で柔軟に、かつ動的に
分散できるように、該複数のインテリジェント分散型ネットワークノードを監視
、制御する、請求項４８に記載のインテリジェントネットワーク。
【請求項５５】該ネットワーク管理システムが、サービスの配備を制御し
、それらのサービスの健康を維持し、それらのサービスについての情報を提供し
、ネットワークレベルの管理機能を提供する、請求項４８に記載のインテリジェ
ントネットワーク。
【請求項５６】ネットワーク管理システムが、さらに、エージェント機能性を通して複数のインテリジェントネットワークノードでサ
ービスおよびハードウェアにアクセス、制御および監視するための手段と、複数のプロセスの起動と停止、プロセステーブルおよび複数のプロセスのステ
ータスのコンテンツの照会を含む、各インテリジェント呼処理機構でローカルオ
ペレーティングシステムの動作を制御するための手段と、インテリジェント呼処理機構の性能を監視するための手段と、該広域ネットワークの初期化および動作を制御するための手段と、単一インテリジェント呼処理機構で実行する複数のサービス層実行環境の具体
化および動作を制御、サポートするための手段とを含む、請求項４８に記載のインテリジェントネットワーク。
【請求項５７】複数の機能が、該インテリジェント呼処理機構の動作を中
断することなく、任意のインテリジェント分散型ネットワークノード内で該イン
テリジェント呼処理機構に移動できる、請求項４８に記載のインテリジェントネ
ットワーク。
【請求項５８】さらに、該呼処理機構によって使用されるべきである機能
を作成、修正、試験および配備するためのネットワーク管理システムに通信可能
であるようにリンクされた管理オブジェクト作成環境を含む、請求項４８に記載
のインテリジェントネットワーク。
【請求項５９】該管理オブジェクト作成環境が、サービス開発作業が分割
できるようにモジュラーツールを活用する、請求項５６に記載のインテリジェン
トネットワーク。
【請求項６０】管理オブジェクトソフトウェアおよびそれぞれの従属性が
、管理オブジェクト作成環境で作成される、請求項５６に記載のインテリジェン
トネットワーク。
【請求項６１】管理オブジェクト作成環境が、さらに、サービスを作成す
るために使用できる複数の副要素を含む、請求項５６に記載のインテリジェント
ネットワーク。
【請求項６２】管理オブジェクト作成環境が、さらに、単一ユーザ環境ま
たはプラットホームでホストとして働くツールの統一集合体を含む、請求項５６
に記載のインテリジェントネットワーク。
【請求項６３】管理オブジェクト作成環境が、さらに、管理オブジェクト
の中にカプセル化されるサービス文書化、管理オブジェクト定義、インタフェー
ス定義、プロトコル定義、およびデータ入力定義などのサービス作成およびサー
ビス試験のプロセスを通して必要とされる動作の集合体を含む、請求項５６に記
載のインテリジェントネットワーク。
【請求項６４】ソフトウェア構成部品のタイプを選択するステップと、ソフトウェア構成を選択するステップと、適切なソフトウェア作成ツールを起動するステップと、ソフトウェア構成内で１つまたは複数の管理オブジェクトを修正または作成す
るために適切なソフトウェア作成ツールを使用するステップと、適切なソフトウェア作成ツールから１つまたは複数の結果を収集するステップ
と、１つまたは複数の結果に基づいた選択されたソフトウェア構成を更新するステ
ップとを備える、ソフトウェア構成を更新するために管理オブジェクト作成環境を使
用する方法。
【請求項６５】該サービス層実行環境内でイベントを受け取るステップと
、該イベントに答えるために必要とされる１つまたは複数の管理オブジェクトを
決定するステップと、１つまたは複数の管理オブジェクトを具体化するステップと、１つまたは複数の具体化された管理オブジェクトを使用してサービスを提供す
るステップとを備える、サービスを提供するために１つまたは複数の管理オブジェクトを使
用する方法。
【請求項６６】１つまたは複数の管理オブジェクトを作成するステップと
、試験サービス層実行環境で１つまたは複数の管理オブジェクトを試験するステ
ップと、該１つまたは複数の管理オブジェクトの試験が無事終了すると必ず、新しいサ
ービスを実現するために必要とされる他の管理オブジェクトおよびシステムで該
１つまたは複数の管理オブジェクトを試験することにより統合試験を実行するス
テップと、該統合試験が無事終了すると必ず、該１つまたは複数の管理オブジェクトを１
つまたは複数のインテリジェント呼処理装置に配備することによって、該新しい
サービスを実現するステップとを備える、１つまたは複数の管理オブジェクトを使用して新しいサービスを実
現する方法。