JPH10507885A

JPH10507885A - 電気通信システム内の内部通信法

Info

Publication number: JPH10507885A
Application number: JP8513848A
Authority: JP
Inventors: メインウォリング，ケイス; ハガルド，ゴラン; トルンストロム，ヨハン; スンドクイスト，マルテン; オールマン，ボルイエ; ラグナルスベンソン，マッツ; バックストロム，スベン; マルティンソン，ハンス; レンナルトヒルボルグ，ミカエル; グラーフ，レスリー
Original assignee: テレフオンアクチーボラゲツトエルエムエリクソン
Priority date: 1994-10-24
Filing date: 1995-10-24
Publication date: 1998-07-28
Also published as: WO1996013112A1; SE9403641L; AU3821895A; AU699880B2; US6282202B1; FI971736A; EP0788701A1; SE515179C2; FI971736A0; CN1168753A; SE9403641D0; CA2203391A1

Abstract

(57)【要約】電気通信システムのトラヒック過程内に、同じまたは異なるアプリケーション（６、８、１０）に属するサービス制御エンティティ間の内部通信がある。このようなサービス制御エンティティは、たとえば呼の一方の当事者のサービスを制御するサービス過程である。サービス制御エンティティ間の通信は、総称プロトコル内に与えられる規則により制御する。これらの規則は、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用を含む。それぞれそのサービスに対応して指定される総称アプリケーションサービスプロトコル（ＡＳＰ）に基づいて、アプリケーション内のプロトコル管理エンティティ（ＡＳＰＥ）はサービスプロトコル（ＡＳＰ）に従って或るサービスのプロトコル管理を行う。プロトコル管理エンティティ（ＡＳＰＥ）間にデータを伝送することにより、前記パラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により、情報要素は分散される。

Description

【発明の詳細な説明】電気通信システム内の内部通信法発明の分野この発明は一般に電気通信システムに関し、詳しくは特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアシステムに関する。またこの発明は、上述の電気通信システムのソフトウエアを構築する方法に関する。より特定すると、この発明は電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信に関する。前記サービス制御エンティティは同じまたは異なる電気通信サービス網内の論理ノードに属する。ここでサービス制御エンティティとは、たとえば呼の一部のサービスを制御するサービス過程（サービスプロセス）をいう。通信網で起こり得るサービス過程の中の、ユーザアクセスおよび網アクセス用のトラヒック制御過程について述べる。ここでサービス制御エンティティが論理ノードに属するというのは、論理ノードで指定しなければならない、という意味である。これをソフトウエアで実現することは、論理ノードで機能を実行することである。論理ノード内のサービス制御エンティティのソフトウエアは、分散されたオペレーティングシステムにより制御される異なるプロセッサに分散させてもよい。ここで論理ノードという概念は、システム内に一緒にインストールする機能のグループをいう。論理ノードは論理網の基準モデルの中で定義され、ノード機能モデルの中で指定される。代表的な論理ノードは、Ｎ−ＩＳＤＮ（狭帯域ＩＳＤＮ）網アクセス、Ｎ−ＩＳＤＮユーザアクセス、Ｂ−ＩＳＤＮ（広帯域ＩＳＤＮ）網アクセス、Ｂ−ＩＳＤＮユーザアクセスなどである。さらにここで通信サービス網、または以下簡単にサービス網という概念は、電気通信サービスの論理網を指す。サービス網の例としては、ＰＳＴＮ、Ｎ−ＩＳＤＮ、Ｂ−ＩＳＤＮ、ＰＬＭＮ−ＧＳＭ、ＶＰＮなどがある。関連技術の説明米国特許出願第０７／７２３，１６６号は、電気通信交換機を制御するソフトウエアシステムについて述べている。このシステムは交換機内にあって、交換機に接続するユーザに電気通信サービスを提供する、複数のアプリケーションモジュールを備える。各アプリケーションモジュールは特定の電気通信アプリケーションを実現するための制御命令とデータを含む。資源モジュールはアプリケーションモジュールが用いる共通の機能要素を与える。資源モジュールは、特定の機能活動を実行するのに必要な交換機のハードウエア要素にアクセスして制御する。交換機内の各アプリケーションモジュールと他の各アプリケーションモジュールと各資源モジュール間に通信を確立して、他のアプリケーションモジュールからの制御命令やデータを用いることなく各アプリケーションモジュールの電気通信サービスをユーザに提供する。網プロトコルは、交換機内のアプリケーションモジュール間の通信を制御する。資源モジュール間や、交換機内のアプリケーションモジュールと資源モジュールの間の通信は、インターフェースを通して行う。ＥＰ０４３２９２４は、中央コンピュータ用の高レベル通信サービスが、並列に管理される独立した水平機能に配置されるデータ通信構造について述べている。水平機能間の条件付き依存性は、水平機能と中央コンピュータのアプリケーション層の間にインターフェースを確立することにより解決する。高レベルのサービスを提供する構造内で用いる高レベルのプロトコルを適応的に指定することにより、通信を改善する。この適応的な指定は、変化するユーザの需要や変動する網パラメータに応じて開始する。プロトコルの仕様では、水平機能のパラメータの適当な値を選択する。パラメータはプログラムが可能である。ＥＰ０５１３７９９は、プロトコルデータユニットの要素を構成するデータ値すなわち構造値の入力または参照を支援するシステムについて述べている。このユニットの構文はＩＳＯ８８２４により規定されており、ＩＳＯ８８２５のＡＳＮ．１規則に従って符号化／復号する。米国特許第４９６７１９３号は、通信モジュールを通して複数のディジタルインターフェースユニットに接続する少なくとも１台の中央コンピュータを備える、通信システムで用いるプロトコルを持つ通信の方法について述べている。各インターフェースユニットは複数のチャンネルユニットに接続する。コンピュータから通信モジュールへ、少なくとも、選択されたインターフェースユニットの第１アドレスと、選択されたチャンネルユニットのアドレスと、実質的に第１インターフェースユニットアドレスと同じ第２アドレスと、第１情報部分をもつ命令メッセージを送る。通信モジュールから命令メッセージを、命令メッセージを受ける選択されたインターフェースユニットであるディジタルインターフェースユニットに送る。選択されたインターフェースユニットでは、命令メッセージから第１アドレスを削除して、修正されたメッセージを作る。修正されたメッセージを、選択されたインターフェースユニットから、修正されたメッセージを受ける選択されたチャンネルユニットであるチャンネルユニットに送る。選択されたモジュールはコンピュータに応答メッセージを与える。プロトコルは、応答モジュールと、応答の種類と、誤りがある場合は誤りを検出した場所と誤りの種類を識別する応答書式を与える。米国特許明細書第５２７６８１６号は、入出力ユニットからオブジェクト指向環境内のアプリケーションオブジェクトに解釈メッセージを送って、その生成に用いた入出力ユニットに関わらずこれらのメッセージの解釈が一定になるようにするシステムについて述べている。発生する全てのオブジェクト・オブジェクト相互作用を解釈するのに動的な結合を用いる。これにより、中の全てのアプリケーションオブジェクトを更新することなくオブジェクト指向環境内で入出力ユニットをさらに用いることができる。欧州特許出願第０５０５０９２号は、複数のエンティティに複数のサービスを与える装置を制御するコンピュータが用いるシステムについて述べている。各エンティティはサービスの１つに正しく対応し、各サービスはサービスを規定するコードの複写を持つ。このシステムは、サービスを実行する過程を各サービスと関連させる。サービスのコードは、サービス過程が継続的に実行する有限状態機械を定義する。別個の状態では、状態機械は、その過程に直接アクセスできる決定図に沿って動く。決定図内のノードを通過するときにとる処置は状態機械内で定義する。サービス過程は、過程間のメッセージを通して他の過程や自分自身と通信する。状態機械の各状態は、サービス過程が受けたメッセージに応答する事象ハンドラーを備える。ＥＰ５５５９９７は、分散コンピュータシステム内のエンティティ間の、プロトコル制御の通信に関する。これは、アプリケーションから独立した言語によりプロトコル記述を送ることができる総称プロトコルを用いる。各エンティティは、どのプロトコルがアプリケーションから独立した言語を用いた総称プロトコルに書かれているかを解釈することができる。または、受信エンティティ内のプロトコル解釈プログラムはプロトコル記述をメモリ内に備えているので、総称プロトコル内のプロトコル識別子を送るだけでよい。ＷＯ９４／６２５１ｉ．ａ．は、電気通信網用の信号プロトコルを開示している。網のノードは接続網により相互に接続される。ノード間の通信は２つの異なるプロトコルで行い、１つの基本プロトコルを用いて、サービスに関係するソフトウエアグループと１つ以上の特定のプロトコルの間の信号路を与える。ＥＰ３５０８４４は、交換機から端末へプログラムパラメータを伝送する方法について述べている。伝送は、これらのユニット間の情報の伝送に送信チャンネルを用いるメッセージ指向プロトコルにより行う。プログラムパラメータは異なるサービスの手続きを管理するのに端末で用いるもので、パラメータメッセージ内に埋め込んで端末に送る。米国５２３９５４２は、伝送書式と送信プロトコルを変換して、異なる網のシステム内の回路の間で通信できるようにする通信システムを開示している。このシステムの特徴は、共通の、プロトコルから独立したメッセージに通信を変換するプロセッサである。この技術に関しては、さらに次の文献もある。米国５００７０８０、「遠隔操作を支援する通信システム(Communicati on system supporting remote operations)」。米国５０７３８９０、「自動呼ディストリビュータ用の遠隔装置操作(R emote agent operation for automatic call distributors)」。ＥＰ０５０４０８７、「階層化通信網の異なるモードにおける同等階層間の非同期プロトコル相互作用の同期化(Synchronizing asynchronous protocol interactions between peer layers in different modes of a layered communication network)」。米国５２５１２５５、「電気通信の呼の機能間における相互作用の処理 (Processing interactions among telecommunications call features)」。米国５１８４３４６、「交換システム(Switching system)」。「コンピュータプロトコルの設計と確認(Design and validation of computer protocols)」、Gerard J．Holzmann、AT&Tベル研究所、PRENTICE HALL。発明の概要この発明の第１の目的は、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信に用いる、アプリケーションに依存しない一般的な通信方法を提供し、同じまたは異なる電気通信サービス網に属する新しいサービスを追加しやすくすることである。この発明の第２の目的は、アプリケーション論理（アプリケーションロジック）を含まないサービスプロトコルを作成し、多数の異なる電気通信サービス網に属するサービス制御エンティティ間の通信に用いることができる、一般的な通信法を提供することである。この発明の第３の目的は、単一ではなく分散されたプロトコルモデルを用いて、アプリケーション特有の部分を自分の環境内に置くことのできる、一般的な通信法を提供することである。この発明の第４の目的は、順方向および逆方向の互換性を持つサービスプロトコルを作成し使用できるようにする、すなわち既存の部分を誤りにしたり無意味にしたりすることなくプロトコルを拡張することができる、一般的な通信法を提供することである。この発明の第５の目的は、サービス制御エンティティ間の通信における従来の概念を、等価のエンティティ間で情報を簡単に動かす伝送サービスに置き換えて、管理を減らすことにより容量を向上させることである。この発明の第６の目的は、ＩＴＵ−Ｔ（以前のＣＣＩＴＴ）Ｑ．２７６４に従う基本的な情報交換に関して、理解できない受信情報をサービス制御エンティティがどのように処理したらよいかを示す機構を持つ、すなわちサービス制御エンティティに要求される相互作用論理を簡単化する、一般的な通信法を提供することである。別の目的は、電気通信システムの一部だけを更新し、他の部分は改善する必要のないようにする通信法を提供することである。この発明の主態様では、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を、総称プロトコルモデルに示す規則により制御する。特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システム用の、ソフトウエアシステムに関する別の主態様では、総称プロトコルモデル内に示す規則を用いて、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御する。特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システム用の、ソフトウエアの構築に関する別の主態様では、総称プロトコルモデル内に示す規則に基づくソフトウエア要素をシステム内に記憶し、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御する。第１の副態様において、上述の主態様に共通しているのは、総称プロトコルモデルの規則は、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用を規定することである。これらの情報要素は、前記パラメータのパラメータ分散機能を持つ通信サービスにより分散される。第２の副態様において、総称プロトコルモデルに基づく３つの主態様に共通しているのは、各サービスに対応するサービスプロトコルが指定されることである。第３の副態様において、３つの主態様に共通しているのは、総称プロトコルモデルの規則は分割できない情報伝送要素の形のプロトコルパラメータの使用を規定することである。第４の副態様において、３つの主態様に共通しているのは、総称プロトコルモデルの規則はパラメータのパラメータ分散機能を持つ通信サービスにより分散されるプロトコルパラメータの使用を規定することである。第５の副態様において、３つの主態様に共通しているのは、総称プロトコルモデルの規則は、メッセージがないことと、プロトコルパラメータだけの使用を規定することである。この発明の本質的な実施態様では、各サービスに対応するサービスプロトコルは総称プロトコルモデルに基づいて指定される。好ましくは、サービスプロトコルで伝送することができる最小のデータユニットを構成する多数の定義されたプロトコルパラメータを、総称プロトコルモデルに関連させる。サービスプロトコルを指定するときは、サービスに適した多数のパラメータを随意に選択し、必要なときは新しいプロトコルパラメータを定義する。各サービスプロトコル毎にプロトコルの仕様があり、授受するパラメータのリストを含む。この発明の本質的な実施態様では、サービスプロトコルはアプリケーション論理を含まない。アプリケーション内のプロトコル処理エンティティは、サービスプロトコルに従って或るサービスのプロトコル処理を行うことが好ましい。２つのサービス制御エンティティ間の通信の場合は、通信サービスはプロトコル処理エンティティ間にデータを伝送し、通信サービス内のパラメータ分散機能は各プロトコルパラメータをどのプロトコル処理エンティティに送るかを指定し、また２つのパラメータ分散リストを用いる、すなわち１つの機能は発信サービス制御エンティティに用い、１つは着信サービス制御エンティティに用いる。システムを更新する場合は、新しいまたは修正されたプロトコル処理エンティティをロードする。これは実行中にパラメータ分散機能に影響を与える。アプリケーション論理は、いろいろの方法でパラメータを通信サービスに送るようプロトコル処理エンティティに指示し、またアプリケーション論理はメッセージを送るよう通信サービスに命令する。プロトコル処理エンティティの構成は、その構造が他の論理ノードに実質的に知られないようにして、アプリケーション設計のときに決定する。各プロトコル処理エンティティ毎に、アプリケーション設計者はサービスの事象を発生させるのに必要なパラメータを指定し、そのサービス用の状態機械をアプリケーション論理内に置く。アプリケーション論理とプロトコル処理エンティティの間のサービス毎に１つのインターフェースがあり、プロトコル処理エンティティからアプリケーション論理に送る事象の仕様と、アプリケーション論理からプロトコル処理エンティティに送る方法を含む。通信サービスからパラメータまたはパラメータの特定の組を受信すると、プロトコル処理エンティティはアプリケーション論理に事象を出す。アプリケーション論理は、トラヒック処理や、補足サービスの処理や、サービス間の相互作用のための全ての論理を含む。各プロトコルパラメータは、受信したプロトコル処理エンティティが、理解できないパラメータをどうするかを示す命令標識に関連する。通信サービスは、１組のメッセージと、対応する状態機械を用いる。前記メッセージはサービスプロトコルにとって意味がなく、アプリケーション設計者は知る必要がない。この発明により、変化するアプリケーションの環境の中で生き残れるサービスプロトコルを設計することができる。そのために、通信の基本原理は考慮するが、プロトコルモデルの基本概念にアプリケーション依存性を組み込まないようにする。この発明の基本は、アプリケーション論理とプロトコルは分離しなければならないということである。これは実際には、サービス用の状態機械や時間測定機能などを、サービスプロトコルを形成する機能ユニット内に置かないことを意味する。アプリケーション論理とサービスプロトコルを分離することによって初めてプロトコルはアプリケーションから独立し、多数の変化する電気通信サービス網内で相互作用することができるよう指定されるサービス間の通信を支援することができる。プロトコルの基になるモデルは単一ではなく分散されている。これにより、アプリケーション特有の部分を自分の環境内に置くことができる。アプリケーション論理内の特定のサービスにそれぞれ関係するプロトコル処理エンティティを用いることが可能である。この分散方式と、順方向互換性すなわち新しいサービスプロトコルを追加できることと、逆方向互換性すなわち設計されたサービス制御エンティティを更新せずにサービスプロトコルを開発できることにより、異なる論理ノード内のサービス間の通信の要求を満たすことができる。サービス間の相互作用を成功させるには論理的決定が必要である。すなわち、各サービス制御エンティティ内のサービス論理は、相互作用できるサービスを理解しなければならない。基本的な情報交換の重要な機構は、各プロトコルパラメータと共に送られかつ理解できない情報を受信機がどうするかを示す、命令標識である。これにより各パラメータを１つのプロトコルユニットから別のプロトコルユニットに送ることができ、必要な相互作用論理を簡単にすることができる。パラメータの拒絶や、呼のリリースや、送信者への通知などの基本機能が可能である。これは、ほとんどの場合の必要な機能をカバーする。特に強調したいのは、この機構が順方向互換性があることすなわち開発可能であることと、逆方向互換性があることである。命令標識機構により、情報に関係のない相互に作用するサービスを乱すことなく各時点でパラメータを追加することができる。またこれは、システム内の他のサービスを乱すことなくサービスを開発できることを意味する。これにより、またシステムの他の部分を乱すことなく、サービスを開発しまたシステムの一部に新しいサービスを逐次導入するのが簡単になる。言及しなければならないもう１つの態様は、各サービス内で動作する状態機械はデータだけで動作することである。この意味は、同じまたは異なる電気通信サービス網に属するいくつかのサービス全体の状態や事象を定義する必要がないということである。サービスプロトコルは、各サービスが自分の状態の遷移を生成するに用いるデータを運ぶ。この意味は、サービスプロトコル自身にアプリケーションの状態への依存性がないので、サービスプロトコル自身はアプリケーションから独立している、ということである。市場に適応する必要性は個々のサービスと同様にして処理する。すなわち、市場パラメータを作成して市場情報を運び、市場機能性により論理が変化したときはプロトコルではなくアプリケーション論理で処理する。したがって市場機能は、機能的に支援する必要のあるサービスに影響を与えるだけである。サービスプロトコルはサービス毎に指定し実現するので、サービスの追加や削除が容易である。要約すると、サービスの開発や、新しいサービスの追加や、サービス毎のサービスプロトコルの仕様および実現や、プロトコルの総括的なメッセージおよび状態がないことなどが自由なので、プロトコルは最高の柔軟性を持つことができる。図面の簡単な説明この発明の実施態様を、添付の図面を参照して以下に詳細に説明する。第１図は、最近のプログラム制御の電気通信システムの略図を示す。第２図は、最近の電気通信システムが備える電話交換機の構造の略図を示す。第３図と第４図は、この発明に用いるいくつかの用語を示す略図である。第５図は、この発明の総称プロトコルモデルを示す。第６図は、第５図のプロトコルモデルのプロトコル構造の例を簡単な状態機械により示す。第７図は、ＡＸＥＮ−ＩＳＤＮユーザアクセスがＡＸＥＮ−ＩＳＤＮ網アクセスと相互作用する場合のプロトコル構造の例を詳細に示す。第８図は、アプリケーション論理とプロトコル処理エンティティと通信サービスの間の相互作用を示す論理ノードの詳細である。第９ａ図と第９ｂ図は、命令標識ビットマップの２つの方式の例を示す。第１０図は、この発明のプロトコルに含まれるパラメータの構造を示す。第１１図は、広帯域ＩＳＤＮユーザアクセスノードが自分自身と、広帯域ＩＳＤＮ網アクセスノードと、狭帯域ＩＳＤＮユーザアクセスノードと通信できるための網の例を示す。第１２図は、通信サービス伝送パラメータが送信するメッセージをこの発明のプロトコルに含める方法を示す。第１３図は、半呼過程の立ち上げ相を示す。第１４図は、半呼過程の活動相を示す。実施態様の詳細な説明以下により詳しく説明するように、この発明は電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信に関する。ここでサービス制御エンティティとは、たとえば呼の一方の当事者のためのサービスを制御するサービス過程をいう。通信網で起こり得るサービス過程の中の、ユーザアクセスおよび網アクセス用のトラヒック制御過程について述べる。サービス制御エンティティが論理ノードに属するというのは、論理ノードで指定しなければならない、という意味である。これをソフトウエアで実現するとは、論理ノードで機能を実行することである。論理ノード内のサービス制御エンティティのソフトウエアは、分散されたオペレーティングシステムにより制御される異なるプロセッサに分散させてもよい。ここで論理ノードとは、システム内に一緒にインストールする機能のグループをいう。以下の詳細な説明で別途に述べない限り、この発明はたとえば上に述べた米国特許出願第０７／７２３，１６６号や、スエーデン特許出願第９２０２４８９− ２号に提示された種類の環境に適用できるものである。これらの文献を引例としてここに示す。第１図は、米国特許出願第０７／７２３，１６６号に開示されたソフトウエアシステムを示す。これはたとえばＡＸＥシステムの一部であってよい。図の上部に、複数のノードを備える電気通信網の一部１１２を示す。これらの各ノードが他のノードといくつかの定義されたプロトコルにより通信する方法は、ソフトウエア構成に反映されている。このソフトウエア構成はプログラムメモリ制御の電話交換機１１４に含まれており、これについては後で詳細に説明する。より詳しく言うと、ＰＳＴＮ網に含まれるノード１１５は図の電気通信部１１２内でたとえばＩＳＤＮ網に含まれるノード１１６と相互接続し、両ノードは構内網に含まれるノード１１８に接続する。構内ノード１１８は構内網の中の他のノード１２０に接続する。ノード１１５はノード１１８とＭＦＣ（多周波コード）プロトコル１２２により通信し、ノード１１６はノード１１５およびノード１１８とＣＣＩＴＴ−ＴＵＰプロトコル１２４および１２６により通信する。ＩＳＤＮノード１１６は他のＩＳＤＮノードとＩＳＵＰプロトコル１２８により通信し、構内網に含まれるノード１２０と１１８は互いにＤＰＮＳＳプロトコル１３０により通信する。電話加入者１３２は各ノード１１５−１２０に接続し、またノード１２０とＩＳＤＮノード１１６にはデータ通信加入者１３４が接続してよい。電気通信網１１２内の機能性は電話交換機１１４に含まれる。論理ノード１１５−１２０の共通の機能性は共通資源１３５に含まれる。電話交換機１１４はノード１１５の特定の機能性をＰＳＴＮアプリケーションモジュール１３６内に含む。同様に、ＩＳＤＮノード１１６の特定の機能性はＩＳＤＮアプリケーションモジュール１３８内に含まれ、構内ノード１１８の特定の機能性はアプリケーションモジュール１４０内に含まれる。アプリケーションモジュール１３６−１４０はサービス処理データプログラムを備え、電話交換機１１４に接続するユーザに電気通信サービスを提供する。各アプリケーションモジュールは或る種類のノードの特定の機能性を実現する制御命令とデータを含む。図のアプリケーションモジュール１３６−１４０は、内部ＴＵＰプロトコル１４２や、内部ＭＦＣプロトコル１４３や、内部ＤＰＮＳＳプロトコル１４４などのプロトコルにより互いに通信する。共通資源１３４はインターフェース１４６を通して用いる。第２図に、プログラムメモリ制御の電話交換機２１２を示す。これはたとえば前記スエーデン特許出願に示されている種類のもので、同様にたとえばＡＸＥシステムの一部を形成してよく、また上記の米国特許出願の通信システムに用いてもよい。電話交換機２１２はこの例では市内交換局で、接続装置を制御するコンピュータ２１４を備える。接続装置は加入者インターフェース２１６と、交換装置２１８と、中継接続インターフェース２２０を備える。交換装置２１８は加入者インターフェース２１６と中継接続インターフェース２２０の間に電話用の電話チャンネルを接続することができる。コンピュータ２１４は、加入者２２２から加入者線２２４と加入者インターフェース２１６を通して市内交換機２１２への送信を制御する。コンピュータ２１４は同様に中継回路２２６から中継接続インターフェース２２０を通して交換装置２１８への中継側の接続を制御する。さらにコンピュータ２１４は、信号接続２３０を通して信号網に接続するインターフェース２２８を持つ。コンピュータ２１４は多数のコンピュータプログラムを実行する。これらのプログラムは、対話やたとえば課金情報を得るための保守機能の回路への接続を制御するなどの、電話交換機内の異なる機能を持つ。信号端子２２８を通して、これらのプログラムは他の電話交換機内のプログラムと信号を交換する。より詳しく言うと、コンピュータプログラムは２つのグループのプログラムを含む。すなわち通信処理グループ２３２とサービス処理グループ２３４である。２つのグループは異なるプロトコルを持つ。すなわちグループ２３２用はプロトコル２３６であり、グループ２３４用はプロトコル２３８である。上に説明したような多数の交換機を備える電話網では、各加入者を処理する２つの交換機内のサービス処理プログラム２３４は、それらの間に直接プロトコル２３８を確立する。同様に、通信処理プログラム２３２はプロトコル２３６により交換機の間で通信する。この発明を適用できる通信システムに関する詳細は、たとえば上述の米国特許出願かスエーデン特許出願から得られるので、ここではこれ以上説明しない。この発明では、論理ノードに含まれるサービス制御エンティティ間の内部通信を、以下にＴＳＰＭ（電気通信サービスプロトコルモデル）と呼ぶ総称プロトコルモデルに示す規則により制御する。これらの規則は、メッセージがないことと、以下にＴＳＰＭ定義のパラメータと呼ぶ分割できない情報伝送要素の形のプロトコルパラメータだけの使用を規定する。ＴＳＰＭ定義のパラメータは、ＴＳＰＭにより伝送することのできる最小データユニットである。ＴＳＰＭ定義のパラメータを、これらのパラメータのパラメータ分散機能を持つ通信サービス（以下にＩＴＳ（情報伝送サービス）と呼ぶ）により分散する。総称プロトコルモデルに基づいて、サービスにそれぞれ対応するＴＳＰＭサービスプロトコルを指定する。これを以下にＡＳＰ（アプリケーションサービスプロトコル）と呼ぶ。第１図の環境にこの発明を適用する場合は、いくつかのサービスプロトコルＡＳＰを、１つの内部プロトコル、たとえばアプリケーションモジュール１３６、１３８、１４０に含まれるサービス管理プログラム間の通信に関する内部ＴＵＰプロトコル１４２、に置き換える。第２図の環境では、サービス処理コンピュータプログラム２３４間の内部通信も、通信処理コンピュータプログラム２３２間の内部通信も、この発明のサービスプロトコルＡＳＰにより同じ方法で行う。以下にＡＳＰＥ（アプリケーションサービスプロトコルエンティティ）と呼ぶプロトコル処理エンティティは、サービスプロトコルＡＳＰに従って特定のサービスのプロトコル処理を行う。サービスプロトコルＡＳＰはＡＳＰＥ間の相互作用に用い、これによりどのＴＳＰＭ定義のパラメータを伝送するかが分かる。この発明の実施態様についての以下の詳細な説明は、繰り返しもあるが、この発明の考え方の異なる態様間の違いをはっきりさせるように、段階的に行う。この発明を説明するのに特にＡＸＥシステムに適用した例を用いるが、他の環境でも一般に適用できる。ＡＸＥシステムの特定の概念については確認して用いる。まず、上述の概念であるＴＳＰＭ、ＡＳＰ、ＡＳＰＥ、ＩＴＳを、第３図と第４図を参照してさらに詳細に示す。第３図と第４図に示す例示のプロトコルモデルＴＳＰＭは、ＡＸＥ用の内部通信の種類を示すものとする。ＴＳＰＭに示す規則により、半呼過程の間の通信に用いるＡＳＰを定義する。半呼過程は、同じまたは異なる電気通信網に属する。ＡＳＰＥは半呼過程内のプロトコルオブジェクトとして実現する。第３図に２組のＡＳＰＥ３０２と３０４を示し、ＡＳＰＥ３０２は論理ノード３０６に含まれる。ＡＸＥシステムでのプロトコルオブジェクトという概念は、サブシステム間の通信用の通信プロトコルの行動を保つオブジェクトタイプのことである。プロトコルオブジェクトは、たとえばＴＵＰ（電話ユーザ部）またはＳＣＣＰ（送信接続制御部）などの外部プロトコルを表すオブジェクトタイプである。プロトコルオブジェクトは、システムに含まれるオブジェクトタイプの一部である。これにより境界が明らかになりまたサブシステムのインターフェースがはっきり示されるので、サブシステムが理解しやすくなる。またＡＸＥシステム内の半呼過程という概念は、呼の一方の当事者を制御する実時間環境と定義される。ヒープ、スタック、実行機能から成る半呼過程環境は、特定のプロセッサに限定される。第３図では、論理ノード３０６内のＡＬ（アプリケーション論理…アプリケーションロジック）機能性の形の１組のサービス制御エンティティを３０８で示し、他の１組を３１０で示す。この発明でＡＬとは、サービス用のアプリケーション論理、すなわちこの場合はサービス制御エンティティの論理をいう。対応するサービスについて、ＡＬ機能性はトラヒック管理や、補足サービスの処理や、サービス間の相互作用などのアプリケーション論理を含む。ＡＬは半呼過程内の多数のスレッドとして実現する。スレッドとは、プログラムポインタとスタックを備える、半呼過程内の実行経路である。半呼過程内にはいくつかのスレッドがあってよい。これらは全て同じヒープおよびスタティックデータを共有する。スレッドは１つ以上の半呼過程事象の間待つよう自己設定して、他のスレッドの実行を開始または再開させることができる。通信サービスＩＴＳを第３図のブロック３１２で示す。ＩＴＳはＡＳＰＥの組３０２と３０４の間にデータを伝送する。通信サービスＩＴＳは、各パラメータの送り先のＡＳＰＥを示すパラメータ分散機能を備える。パラメータ分散機能は、以下の例のＰＤＬ（パラメータ分散リスト）と呼ぶリストの形でよい。各パラメータは１つ以上のＡＳＰＥに送られる。第３図の異なる機能性の間の矢印は通信経路を示す。第４図に示すように、ＴＳＰＭは論理ノード間の通信用のＡＳＰＥを設計するのに用いられている。この図では、１つのＮ−ＩＳＤＮサービス網を４０２で、別のサービス網を４０４で示す。代表的な論理ノードはＮ−ＩＳＤＮ網アクセス４０６と、Ｎ−ＩＳＤＮユーザアクセス４０８である。サービス網４０４内の論理ノードを４１０で示す。ＴＳＰＭにより定義されるサービスプロトコルを、異なるサービス網に属する論理ノード間にも同じサービス網に属する論理ノード間にも設定してよい。第４図では、サービス網４０４に含まれる論理ノード４１０と、サービス網４０２内の論理ノード４０８および４０６との間にＴＳＰＭ接続４１２と４１４がある。論理ノード４０６と４０８の間にはＴＳＰＭ定義の通信４１６がある。実時間では、論理ノード内のサービス制御エンティティは相互作用するサービス間の多数のＡＳＰにより通信する。ＴＳＰＭ定義のパラメータは各ＡＳＰと共に伝送される。仕様と実現はアプリケーション設計者が行う。ＴＳＰＭにより、既存のＡＳＰに適応することなく１つ以上の新しいＡＳＰを各論理ノードに追加することができる。ここでは、「半呼過程（プロセス）」(half-call process) という概念を用いて実行を説明する。そうでない場合は、より一般的な概念である論理ノードを用いて、サービスの分散とそのＡＳＰによる通信を説明する。第５図を参照して、この発明を適用した総称プロトコル処理モデルを説明する。これは次の機能性を備える。ＡＰ機能性（アプリケーション過程（プロセス））は別個の論理サービスノードに関する全てのサービス論理（すなわちいくつかのＡＬ機能性）を含む。第５図に、例として２つのＡＰ機能性５０２と５０４を示す。ＡＬ機能性はＡＰ機能性に含まれ、特定のサービス、たとえば呼制御や閉域ユーザグループ（ＣＵＧ）に関する論理を含む。ＡＬ機能性は、ＡＰ機能性５０２と５０４にそれぞれ含まれるサービス制御エンティティ５０６、５０８と５１０、５１２を形成する。２つのアプリケーションプロトコル部５１４と５１６は、たとえば２組のＡＳＰＥ機能性５１８と５２０と、１つのＡＣＳＰＥ機能性５２２と５２４をそれぞれ含む。各ＡＳＰＥは特定のアプリケーション論理ＡＬの送信支援を含む。前記送信支援は、たとえばＡＳＰＥの組５１８と５２０については５２６、５２８と５３０、５３２でそれぞれ示す。機能性ＡＣＳＰＥ（アプリケーション共通のサービスプロトコルエンティティ）はプロトコル状態機械を備え、特定のプロトコルのパラメータのアンパッキング／パッキング、すなわち関連するＡＳＰＥへまたはＡＳＰＥからのタグ付きデータの分散と収集、を行う。これを、ＡＳＰＥの組５１８と５２０についてそれぞれ５３４と５３６で示す。タグが認識されない場合は、パラメータは別のＡＳＰＥに送られる。追加のＡＳＰＥを接続するときはＡＣＳＰＥを再開発するのではなく、ＡＣＳＰＥ内の分散／収集表を単に更新すればよい。低階層プロトコル（ＬＬＰ）エンティティ５３８と５４０はＱ．９２１、ＭＴＰ、ＳＣＣＰなどの非アプリケーション依存のプロトコルと、対応するＡＸＥ内部低階層プロトコルを含む。サービスプロトコルＡＳＰは、パラメータから成る情報の流れ（２つのＡＳＰＥの間の５４２と５４４で示す）を記述する。プロトコルＡＣＳＰ（アプリケーション共通のサービスプロトコル）（５４６で示す）は、ＡＣＳＰＥの間の構文と情報の流れを記述する。第６図は、第５図のプロトコル処理モデルの説明に基づいて、ＴＳＰＭ内のプロトコル構造の簡単な例を示す。図に示すように、プロトコル状態機械が含むのは１つの状態すなわち「活動的」だけなので、ＡＳＰＥ用のサービスプロトコルは非常に簡単であって、プロトコルは授受するパラメータのリストだけから成る。アプリケーション論理ＡＬ用のプロトコル状態機械は一層完全な状態機械で、プロトコル上で起こるトラヒックコースを反映する。簡単のために、第５図の右半分のＡＰ機能性５０４に対応するＡＰ機能性を第６図では省略する。第６図の左半分に、第５図の２つのアプリケーション論理機能性５０６と５０８を、ブロック６０２と６０３で表す。さらに、アプリケーション論理機能性６０２と６０３への従属関係接続６０８と６１０を持つ２つのＡＳＰＥ機能性６０４と６０６を示す。ＡＳＰＥ６０４と６０６は、基本サービス「CallControl」と補足サービス「CallingLineIdentificationPresentation」のプロトコル処理をそれぞれ行うとする。各サービスのこれらの例示の名称と第６図に用いたパラメータの名称はＩＳＤＮ内のパラメータに対応するものであり、電気通信技術たとえばＣＣＩＴＴに関わる技術者にはよく知られているので、ここでこれ以上は説明しない。第６図の上部の矢印６０１は、第５図のアプリケーション論理ＡＬ５０８と５１０の間の通信をさらに一般的に表す。この矢印の上に、アプリケーション論理ＡＬの状態機械の例を示す。状態「アイドル」をＩで示し、状態「コールアテンプト」をＣで、状態「終了状態」をＥで、状態「活動的」をＡで示す。矢印６１２と６１４の上の、それぞれ１状態の状態機械用の記号の側に、ＡＳＰＥ６０４と６０６の各プロトコルを示す。第１の場合のプロトコルは授受するパラメータのリストを示し、第２の場合のプロトコルは送る唯一のパラメータを示す。またそれ自体よく知られている方法で３つのプロトコルの例として示した記号については、電気通信分野の技術者はその意味を理解できるので、詳細な説明は必要ない。第７図はプロトコル構造を示す。これはＡＸＥ実現の例であって、第５図と同じ構造を持つ。ここでＮ−ＩＳＤＮユーザアクセス７３０はＮ−ＩＳＤＮ網アクセス７３２と相互に作用する。２つのＡＰ機能性を７０２と７０４で示す。７０６、７０８と７１０、７１２は、各ＡＰ機能性７０２と７０４に含まれる２つのＡＬ機能性の例である。２つのＡＰ機能性は、ＴＳＰＭ規定のＡＳＰプロトコル７３３に従って相互に作用する。基礎プロトコル階層を７３４で示す。各アプリケーションプロトコル内のＡＣＳＰＥを７１８と７２２で示す。ＴＳＰＭの場合はＡＣＳＰＥをＩＴＳと呼び、７２０と７２４で示す。低階層プロトコルは、Ｎ−ＩＳＤＮユーザアクセスの場合はＱ．９２１であり、Ｎ−ＩＳＤＮ網アクセスの場合はＭＴＰであって、それぞれ７２６と７２８で示す。低階層プロトコルエンティティ７２６と７２８は、非アプリケーション依存のプロトコルＱ．９２１とＭＴＰをそれぞれ含む。第８図において、実現されたＴＳＰＭは論理ノード８１０に含まれる１組のＡＳＰＥ８０２、８０４、８０６、８０８から成り、ＡＬアプリケーション論理８１２、８１４、８１６、８１８で制御される特定のサービス用のプロトコルをそれぞれ処理する。ＡＳＰＥのグループ化は、ＡＬアプリケーション設計のときに決定する。その構造は他の論理ノードには知られないので、設計のモジュール化が容易になる。ＡＬアプリケーションの設計者は、対象とするサービスのプロトコル状態を記述し、ＡＳＰＥとＡＬを設計する。ＩＴＳは一般的である。サービス用の状態機械はＡＬアプリケーション論理８１２、８１４、８１６、８１８内にそれぞれある。実時間では、必要のときはＡＳＰＥはＩＴＳ通信サービスにより具体化される(instantiated)。ＡＳＰＥは簡単なパラメータ分配機器と考えてよく、類別依存性はない。半呼過程を作成するときはＩＴＳ事例８２０を作成する。実際のＩＴＳは、半呼過程内の２つのパラメータ分散機能を持つ。すなわち１つの機能は半呼の発信に用い、１つは半呼の着信に用いる。ＩＴＳ事例８２０はパラメータ分散機能８２２を用いて、受信したパラメータを正しいＡＳＰＥに分散する。第８図に示すように、この目的のために、機能８２２は、パラメータと、対応するＡＳＰＥをそれぞれ含む２つのリスト列８２４と８２６から成る。論理ノード８１０は８２８で示す多数のＡＳＰを通して通信し、それぞれ４つのＡＳＰＥ８０２−８０８の１つに着信する。メッセージを受信すると、ＩＴＳ事例８２０はＰＤＬ８２６に従ってパラメータをＡＳＰＥに分散する。メッセージを送るときはＰＤＬを用いない。より詳しく言うと、ＡＳＰＥはパラメータをＩＴＳ事例にダウンロードし、またＡＬアプリケーション論理８１２−８１８はＩＴＳ事例に、多数のパラメータを含むメッセージを送るよう指示する。一例として、ＡＳＰを通して通信する論理ノード８１０の機能性を４つのサービス（ＡＳＰ８０２−８０８毎に１つ）に分割して示す。すなわち、呼制御ＣＣ，呼送りＣＦ（呼送りに関連する全ての異なる補足サービスを含む）、ＵＵＳ（ユーザからユーザへの送信）、ＣＵＧ（閉域ユーザグループ）である。各サービス毎に１つのＡＳＰＥがあり、それぞれ送信部と着信部を持つ。論理ノード８１０内の８３０に、外部プロトコルを処理するエンティティを示す。ＴＳＰＭはプロトコル構造を示すもので、これについて詳細に説明する。前に述べたように、ＴＳＰＭ規則は、メッセージがないことを規定する。すなわち、ＴＳＰＭに基づくＡＳＰプロトコルにはメッセージがない。情報を伝送する唯一の方法はＴＳＰＭ定義のパラメータによるだけである。被呼者番号などの呼情報も、「応答」や「切断」などの事象も、パラメータにより送らなければならない。決まった(mandatory)パラメータはない。ＴＳＰＭに従って伝送できるデータを分割して、１組の分割できないパラメータにする。ＴＳＰＭの各リリースは、アプリケーション設計者用の基準マニュアルに定義され記述されている多数の包括的なパラメータを含んでいなければならない。これらの包括的なＴＳＰＭ定義のパラメータは全てのアプリケーションで用いてよく、またできるだけ用いなければならない。基本システムを新しくリリースする度に、必要であれば基準マニュアルを更新する。ＴＳＰＭ基準マニュアル内のパラメータの組が十分でない場合は、局所的なＴＳＰＭ定義のパラメータを作ることができる。新しいＴＳＰＭ定義のパラメータが必要となるのは、新しい型のデータを伝送する必要のある新しいアプリケーションのときである。また１つの市場は市場特有のパラメータを必要とする場合がある。局所的なＴＳＰＭ定義のパラメータは、アプリケーション設計者用の局所的な基準マニュアルに定義し記述しなければならない。局所的なＴＳＰＭ定義のパラメータを作成したアプリケーション／市場だけがそれを使ってよい。他のアプリケーションが局所的なＴＳＰＭ定義のパラメータを使う可能性がある場合は、できるだけ早くこれを包括的なＴＳＰＭ定義のパラメータにしなければならない。古いパラメータに基づいて新しいパラメータを作成する場合は、新と旧のパラメータの関係をＴＳＰＭ基準マニュアルに（または局所的なＴＳＰＭマニュアルに）示さなければならない。パラメータが理解できないときに受信した論理ノードがどうするかを指定する命令標識を、ＡＳＰによって送る各パラメータに含める。命令標識は、たとえば、・報告を返す・パラメータを捨てる・呼を消すなどである。アプリケーションは自分の命令標識を作成しなくてもよい。新しいＴＳＰＭのリリースのときに命令標識の組を拡張するだけでもよい。一般に、命令標識は未知の情報を処理する互換性手続きのときに用いる機構である。ＢＩＳＵＰなどのプロトコルでは、この情報はメッセージであり、メッセージの中のパラメータであり、パラメータの中の値である。ＴＳＰＭでは、半呼過程間の相互作用の問題の場合は、未知情報は１パラメータだけの形でよい。正しい行動を決定するには、ノードは命令標識を解釈する前に、自分が通過ノードとして動作するか終端ノードとして動作するかを知らなければならない。認識されない情報は１つの網アクセスプロトコルから別の網アクセスプロトコルに（たとえば各プロトコルが同じ機能的可能性を持つ場合に限ればＮ−ＩＳＵＰに）さらに送らなければならない。しかし認識されない情報をユーザアクセスプロトコル（たとえばＤＳＳ１）にさらに送ってはならない。したがって、少なくとも１つの外部プロトコルがユーザアクセスプロトコルの場合は、呼は終端ノードと解釈し、通過ノードとは解釈しない。広帯域および狭帯域の網アクセスプロトコルのどちらにも用いる命令標識を定義した。Ｂ−ＩＳＤＮ用のユーザアクセスプロトコルは、プロトコルとそれが動作する通信部の性質のために、これらの標識の一部分を支援するだけである。命令標識は、絶対的な値ではなく機能毎の別々のフィールドと定義されるので、新しいフィールドを追加したときに、互換性の問題なく古いノードと相互に作用することができる。古いノードは自分が知っているフィールドだけ見る。したがって新しいフィールドを定義するときは、新しいフィールドを見ない古いノードが使用可能な機能を得ることができるように、既存のフィールドを設定しなければならない。たとえば第９ａ図で、命令標識のビットマップの長さが６ビットとする。第４ビットだけを１にすると、命令標識は、パラメータが認識されない場合は通知を送り返す、という意味になる。次の改訂で、パラメータが認識されない場合は通知を送り返すが呼が切断状態にあるときはそうしない、という新しい命令標識値が必要になると仮定する。第９ｂ図に示すように、ビットマップ組み合わせを６ビットから８ビットに拡張してこの値を符号化することができる。新しい値は第７ビットと第４ビットを１にしたビットマップ組み合わせで示される。このように、６ビットマップでも８ビットマップでも満足な結果が得られる。ＴＳＰＭに従って指定したＡＳＰプロトコルにはメッセージがないので、必要なのはパラメータに関係する命令標識だけである。またＴＳＰＭは、外部プロトコルに用いる命令標識が命じる機能を支援する規則を含む。すなわち、ａ．認識されないパラメータを２つの外部プロトコル間で透明に伝送することができる。ｂ．認識されないメッセージを２つの外部プロトコル間で透明に伝送することができる。ｃ．発信(originating)／入(incoming)半呼は、ごく早い時期に（他の半呼に情報を送る前に）関連する着信(terminating)／出(outgoing)半呼過程の種類を知って、通過ノードとして動作するか終端ノードとして動作するか、また終端ノードの場合は「転送(pass on)」が可能かどうか、を知るようにしなければならない。ｄ．着信／出半呼は、（他の半呼に情報を送る前に）関連する発信／入半呼過程の種類を知って、通過ノードとして動作するか終端ノードとして動作するか、また終端ノードの場合は「転送」が可能かどうか、を知るようにしなければならない。これらの要件を満たすために、ＴＳＰＭ用に多数のパラメータを定義する。すなわち、ａ．発信半呼過程の種類。このパラメータをＩＴＳ開始メッセージに含めて送り、着信半呼に発信半呼の種類、たとえばＮ−ＩＳＤＮユーザアクセス、Ｂ− ＩＳＤＮ網アクセス、を示す。着信半呼はこの情報を用いて、発信半呼がその認識されないメッセージやパラメータを「転送」してよいかどうか知る。ｂ．認識されない外部メッセージ。認識されないメッセージを半呼過程が外部プロトコルから受け、これを関連する半呼に転送すべきだと決定した場合は、このパラメータをＩＴＳメッセージに含めて送ることができる。「転送」するという決定は、外部プロトコルの命令標識を調べて、関連する半呼が自分の半呼の外部プロトコルからのメッセージを転送できることを知った上で行う。命令標識と名称と長さを含む外部メッセージは、このパラメータの一部として含まれる。ｃ．認識されない外部パラメータ。未知のパラメータを半呼過程が外部プロトコルから受け、これを関連する半呼に転送すべきだと決定した場合は、このパラメータをＩＴＳメッセージに含めて送ることができる。「転送」するという決定は、外部プロトコルの命令標識を調べて、関連する半呼が自分の半呼の外部プロトコルからのメッセージを転送できることを知った上で行う。命令標識と名称と長さを含む外部パラメータは、このパラメータの一部として含まれる。発信／入半呼で行った分析は、出／着信半呼過程の種類を示す結果を生じる。これにより発信／入半呼は、着信／出半呼がその認識されないメッセージとパラメータを転送できるかどうか決定することができる。各半呼過程は、未知のメッセージやパラメータを転送できる他の半呼の種類を示す表を持たなければならない。この表は、他の半呼が分かったときにチェックする。新しい半呼過程をシステムに追加した場合は、これらの表の更新が可能でなければならない。第１０図はＴＳＰＭ定義のパラメータの構造を示す図で、パラメータは多数のフィールドを含んでよい。図の例では、これらのフィールドはパラメータ名を含むフィールド１００２と、パラメータの長さ標識を含むフィールド１００４と、命令標識を含むフィールド１００６から成る。図示の１００８や１０１０のような、それぞれ特定の意味の値領域を持つ１つ以上の他のフィールドをさらに含んでよい。一例を挙げると、フィールド「番号の種類」を持つパラメータ「アドレス情報」である。値領域は次のいずれかでよい。・０＝未知・１＝局所・２＝国内そのサービスは他の論理ノードの同じ種類のサービスと相互作用が可能でなければならない、というような特定の要求がサービスを開発するときにあるはずである。しかし他の論理ノードのサービスが更新されたり、新しい論理ノードが現れたりする可能性があるので、未知のパラメータを処理するための支援が必要である。予期しないパラメータの処理を支援するために、前に説明した命令指標を各パラメータに関連して用いる。送信論理ノードが設定する命令指標は、受信論理ノードがパラメータを理解しない場合に行う対策を示す。どのＡＳＰＥも予期していないパラメータを受信した場合は、ＩＴＳはこのパラメータをＵＰＡＳＰＥに送る。ＵＰは「認識されないパラメータ」の略で、ＵＰＡＳＰＥは理解しないことを知らせるＡＳＰＥである。次のような相互作用の例を挙げる。・着信半呼過程が発信半呼過程にＡ番号を要求し、この要求が理解されないと分かった場合は、Ａ番号を示さずに継続することが可能でなければならない。・他の論理ノードが「余りにも互換性を持たない」ことが分かった場合は、呼をリリースしなければならない。これはたとえば、相手側が「接続」や「Ｂ番号」などの重要なパラメータを理解しない場合である。・広帯域接続を設定するようにと狭帯域論理ノードが要求された場合は、このコールアテンプトを拒絶しなければならない。第１１図に示す例示のＡＸＥ電気通信システムは、狭帯域ＩＳＤＮ網アクセスノード１１０２と、広帯域ＩＳＤＮ網アクセスノード１１０４と、広帯域ＩＳＤＮユーザアクセスノード１１０６から成る。ユーザアクセスノード１１０６の加入者が発呼すると、半呼過程を開始する。この半呼過程は、多数のＡＳＰを通して網内の他の半呼過程に向かって通信する。この例では、ノード１１０６自身（１１０８で示す）を含む３ノードのいずれかと通信する。他の論理ノードと通信するときは、ユーザアクセスノード１１０６の同じＡＳＰＥの組を用いる。論理ノードで相互作用を確立すること自体が、アプリケーションにとって追加の作業である。しかし、全ての種類の相互作用を処理したり、論理ノードを更新したときは必ず更新しなければならないような、中央の複雑なエンティティを必要としないことは大きな利点である。第１１図の網の例では、３つの論理ノードそれぞれの設計は、他のノードの設計とは独立に行うことが可能でなければならない。また１つの論理ノードの更新／再設計を、他の論理ノードの内部構造を調査したり更新したりせずに行うことが可能でなければならない。第１２図は、対応するＡＳＰＥの組１２０２と１２０４で示す２つの論理ノードが、それぞれＩＴＳ事例１２０６と１２０８を通して、ＩＴＳメッセージ１２１８と１２２０で運ばれるＴＳＰＭ定義のパラメータ１２１０、１２１２、１２１４、１２１６を交換する方法を示す。ＩＴＳはメッセージの小さな組と、対応する簡単な状態機械を用いる。ＩＴＳメッセージはＡＳＰプロトコルにとって意味がなく、アプリケーション設計者は知る必要がない。ＩＴＳは基礎対話サービスを用いる。第１３図は、半呼過程の立ち上げ相を示す。ＡＳＰＥと制御論理はインターフェースを通してＩＴＳの方法を呼び出す。全てのＡＳＰＥは、たとえばＡＳＰＥプロトコルオブジェクト用のＣ＋＋基本クラスから得られる。これによりＩＴＳは他のインターフェースを通してＡＳＰＥ内に方法を呼び出し、相手側から得たパラメータを分散させる。コールアテンプトがあると、立ち上げ機能は発信半呼用の動的過程１３０２を確立する。まず実行スレッドは発信呼制御論理１３０６を作成する。具体化のときに発信呼制御論理は流れを結合し（矢印１３０８と１３１０）、どの拡張流れ（たとえば補足サービスＣＬＩＰ（発信番号表示）１３１２やＳＵＢアドレシング１３１４）を呼制御論理１３０６の基本的流れに追加することができるかを決定する。アドレス情報分析を行ってコールアテンプトの宛先のシステムを識別すると、呼制御論理１３０６はＩＴＳ１３１８を具体化する（矢印１３１６）。ＩＴＳ１３１８が開始すると、呼制御論理１３０６はそのＡＳＰＥ１３２２を具体化する（矢印１３２０）。ＡＳＰＥ１３２２は、その制御論理１３０６から、または半呼特有のデータベースを読んで、ＩＴＳ１３１８へのポインタを得る。ＡＳＰＥ１３２２が具体化すると、ＡＳＰＥ１３２２は自分をＩＴＳ１３１８に連結し（矢印１３２４）、同時にパラメータのリストを、メッセージを終端側から受信したときに加入する(subscribe to)ことを決定したところに送る。ＩＴＳへの連結は、方法「subscribeParameters」により行う。終端側に送るパラメータは、方法「prepareParameters」によりＡＳＰＥ１３２２からＩＴＳ１３１８に送る。拡張流れ１３１２と１３１４が実行を引き継ぐと、自分のＡＳＰＥ１３３０と１３３２をそれぞれ作成し（矢印１３２６と１３２８）、同様にＩＴＳ１３１８に連結し（矢印１３３４と１３３６）、ＩＴＳからパラメータに加入し、ＩＴＳにパラメータを送る。第１３図の各流れの矢印の近くに示す数字１−１０は、呼の割り当ての順序を示す。もちろん、第１メッセージ内のＴＳＰＭ定義のパラメータを着信側に伝送する必要のある全てのサービスは、半呼過程の第１作業の間にＡＳＰＥを作成してＩＴＳに連結する必要がある。ＣＯＬＰ（接続番号表示）などの他のサービスは、後でそのＡＳＰＥを設定してよい。着信側の立ち上げ機能が着信側の半呼過程を作成すると、制御論理は呼制御用に具体化される。次にＩＴＳ事例とＡＬ事例を、発信側と同じ方法で作成する。着信側への第１メッセージ内でパラメータを受信するサービスは、半呼過程の開始のときにそのＡＳＰＥと共に具体化しなければならない。その後で、残りの制御論理とＡＳＰＥを発信側と同様に確立する。具体化するとき、ＩＴＳは自分が作成された半呼過程について何も知らない。ＩＴＳは呼制御論理から経路情報と、パラメータを分散する全てのＡＳＰＥのオブジェクトポインタを受信する。ＩＴＳはパラメータ分散についての情報を受信すると、そのパラメータ分散リストＰＤＬを動的に逐次作成する。第１４図では、半呼過程の活動相の例を説明する。半呼過程１４０２では、ＡＬをスレッド１４０４として、ＡＳＰＥ１４０６と１４０８をプロトコルオブジェクトとして実現する。ＩＴＳ１４１０がメッセージを受けるときは、パラメータリストＰＤＬに示されるＡＳＰＥ１４０６と１４０８への一般的方法１４１２と１４１４を呼び出す。ＡＳＰＥはパラメータを識別し、それに含まれるデータを解釈する。パラメータまたは特定のパラメータの組をＩＴＳから受信すると、ＡＳＰＥ１４０６または１４０８は事象１４１６と１４１８をそれぞれＡＬ１４０４に与える。メッセージを送るときは、スレッド１４０４はそれぞれ方法１４２０と１４２２により、ＩＴＳ１４１０にパラメータを送るようＡＳＰＥに命令する。その他に、スレッド１４０４はＩＴＳメッセージを送るようＩＴＳ１４１０に命令する（１４２４）。ＩＴＳ事例１４１０はポートとしてアドレス点を用いて（１４２６で示す）ＩＴＳメッセージを交換する。結論として、内部通信にこの発明の方法を用いる実際の例を以下に示す。例としてサービスＣＯＬＰを用いる。このサービスにより、発呼者は被呼者を識別することができる。呼を設定するときにいろいろ異なる呼転送サービスを呼び出すことができるので、呼を受ける加入者は呼を送った相手と必ずしも同じではない。アプリケーションがサービスＣＯＬＰを用いるとき、２つのＴＳＰＭ定義のパラメータ、すなわちＣＯＬＰ質問とＣＯＬＰ番号、を用いる。これらがＴＳＰＭライブラリに存在しない場合は作成しなければならない。サービスを行うためには、呼の各トラヒック側毎にサービス制御エンティティがなければならない。呼の初めに、パラメータＣＯＬＰ質問が発呼側から相手側に送られる。呼が受け付けられると、ＴＳＰＭ定義のパラメータＣＯＬＰ番号が発呼者に送られる。上の例に関して、次のことが分かる。・上記の２つのＴＳＰＭ定義のパラメータを追加したことによりプロトコルが拡張された。・プロトコルは全てのアプリケーション設計者に利用可能である。・プロトコルはアプリケーション論理を全く含まない。すなわち、パラメータがそのサービスに必要かとか、どの順序またはグループ化によりそれらを送るかについては、プロトコル文書に書かれていない。このようなサービスを行うのに必要な論理は、アプリケーション論理（ＡＬ）に指定され実現されている。・呼を終端に運ぶのに上記のサービスが必要でないときは、パラメータに関連する命令標識を「パラメータを拒絶」に設定しなければならない。・上記に従って命令標識を設定することにより、サービスを網に逐次導入することができる。発呼者のサービス論理を実行するノードにも被呼者のサービス論理を実行するノードにもサービスが導入される場合だけ、サービスは行われる。サービスが行われるかどうかに関わらず、設定された呼は動く。・サービス機能性をいつか増やさなければならない場合は、既存のパラメータの１つの値の範囲を増やす必要があるので、新しいＴＳＰＭ定義のパラメータを作成しなければならない。このサービスの更新は、網に逐次導入することができる。全てのノードを更新し終わるまでは、旧パラメータも新パラメータも送らなければならない。上記の例を実現するため、発信ノードにはたとえばコード（論理）を実行するコードがある。加入者がサービスＣＯＬＰを活動化した場合は、ＴＳＰＭ定義のパラメータＣＯＬＰ質問を着信側に送る。次にＴＳＰＭ定義のパラメータＣＯＬＰ番号が受信されてその呼が失敗でなかった場合は、対象とする番号を外部プロトコルで加入者に送る。当業者は状態機械や流れ図やコードにこの論理を移す方法を理解できるので、詳細な説明は不要である。しかし重ねて強調したいのは、これが存在するのはアプリケーション内であって、プロトコルやその文書内ではないことである。

【手続補正書】特許法第１８４条の８第１項【提出日】１９９６年１２月１０日【補正内容】請求の範囲１．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システム内の、内部通信の方法であって、分割できない情報伝送要素の形のプロトコルパラメータを交換することにより、総称プロトコルモデル（ＴＳＰＭ）に従って異なるノードのサービス制御エンティティ間の通信を行うステップを含み、前記プロトコルパラメータはそのパラメータ分散機能を持つ通信サービス（ＩＴＳ）内で、サービス制御エンティティにとって意味のないメッセージ内に分散される、電気通信システム内の内部通信の方法。２．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアを構築する方法であって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、分割できない情報伝送要素の形のプロトコルパラメータの交換を規定する、総称プロトコルモデル（ＴＳＰＭ）に基づくソフトウエア要素をシステム内に記憶するステップを含み、前記プロトコルパラメータはそのパラメータ分散機能を持つ通信サービス（ＩＴＳ）内で、サービス制御エンティティにとって意味のないメッセージに分散される、電気通信システム内のソフトウエアを構築する方法。３．前記総称プロトコルモデルに基づいて、各サービスに対応するサービスプロトコル（ＡＳＰ）を指定するステップを含む、請求項１または２に記載の方法。４．前記サービスプロトコル内の伝送できる最小データユニットを構成する多数の定義された制御パラメータを、前記総称プロトコルモデル（ＴＳＰＭ）に関連させるステップを含む、請求項１−３のいずれかに記載の方法。５．サービス用の適当な数のプロトコルパラメータを随意に選択し、また必要なときは新しいプロトコルパラメータを定義することにより、サービスプロトコルを指定するステップを含む、請求項３または４に記載の方法。６．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様を与えるステップを含む、請求項３または５に記載の方法。７．前記サービスプロトコルはアプリケーション論理を含まない、請求項３ −６のいずれかに記載の方法。８．アプリケーション内にプロトコル処理エンティティ（ＡＳＰＥ）を設けて、サービスプロトコル（ＡＳＰ）に従って或るサービスのプロトコル処理を管理するステップを含む、請求項３−７のいずれかに記載の方法。９．相互に作用するプロトコル処理エンティティ（ＡＳＰＥ）を更新する必要なしに或るプロトコル処理エンティティを更新するステップを含む、請求項８に記載の方法。１０．通信サービス（ＩＴＳ）によりプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送することによって、またどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを通信サービス（ＩＴＳ）内にあるパラメータ分散機能により指示することによって、また１つのパラメータ分散リストを発信サービス制御エンティティに用い、１つのパラメータリストを着信サービス制御エンティティに用いることによって、２つのサービス制御エンティティ間の通信を行うステップを含む、請求項８または９に記載の方法。１１．新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードすることによりシステムを更新して、実行中にパラメータ分散機能に影響を与えるステップを含む、請求項１０に記載の方法。１２．アプリケーション論理を用いて、通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またメッセージを送るよう通信サービス（ＩＴＳ）に指示するステップを含む、請求項１０または１１に記載の方法。１３．アプリケーション設計に関連してプロトコル処理エンティティ（ＡＳＰＥ）を構成して、その構造を他の論理ノードに実質的に知られないようにする、請求項８−１２のいずれかに記載の方法。１４．各プロトコル処理エンティティ（ＡＳＰＥ）毎にサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置くステップを含む、請求項１３に記載の方法。１５．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項８−１４のいずれかに記載の方法。１６．通信サービス（ＩＴＳ）から１つのパラメータまたはパラメータの特定の組を受信した場合は、プロトコル処理エンティティ（ＡＳＰＥ）からアプリケーション論理に或る事象を出すステップを含む、請求項８−１５のいずれかに記載の方法。１７．トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理をアプリケーション論理（ＡＬ）内に導入するステップを含む、前記請求項のいずれかに記載の方法。１８．パラメータが理解できないときにどうするかを受信プロトコル処理エンティティに指示する命令標識を各プロトコルパラメータに関連させるステップを含む、前記請求項のいずれかに記載の方法。１９．１組のメッセージと、対応する状態機械を通信サービス（ＩＴＳ）が用いるステップを含む、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなくまたアプリケーション設計者は知る必要がない、請求項３− １８のいずれかに記載の方法。２０．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアシステムであって、分割できない情報伝送要素の形のプロトコルパラメータの交換を規定する総称プロトコルモデル（ＴＳＰＭ）に示す規則を用いることにより、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御する、ただし前記プロトコルパラメータはそのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により、サービス制御エンティティにとって意味のないメッセージに分散される、電気通信システム用のソフトウエアシステム。２１．各サービスに対応し、総称プロトコルモデル（ＴＳＰＭ）に基づいて指定されるサービスプロトコル（ＡＳＰ）を備える、請求項２０に記載の電気通信システム用のソフトウエアシステム。２２．総称プロトコルモデル（ＴＳＰＭ）は、前記サービスプロトコル内で伝送できる最小データユニットを構成する多数の定義されたプロトコルパラメータに関連する、請求項２１に記載の電気通信システム用のソフトウエアシステム。２３．サービスプロトコルの仕様は、随意に選択されたサービスの適当な数のプロトコルパラメータと、必要なときは新しいプロトコルパラメータを含む、請求項２１または２２に記載の電気通信システム用のソフトウエアシステム。２４．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項２１−２３のいずれかに記載の電気通信システム用のソフトウエアシステム。２５．前記サービスプロトコルはアプリケーション論理を含まない、請求項２１−２４のいずれかに記載の電気通信システム用のソフトウエアシステム。２６．アプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）は、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行う、請求項２１−２５のいずれかに記載の電気通信システム用のソフトウエアシステム。２７．プロトコル処理エンティティ（ＡＳＰＥ）の更新は、これと相互に作用するプロトコル処理エンティティの更新を必要としない、請求項２６に記載の電気通信システム用のソフトウエアシステム。２８．２つのサービス制御エンティティ間の通信の場合は、通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、通信サービス（ＩＴＳ）内にあるパラメータ分散機能はどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、また２つのパラメータ分散リストを用いる、すなわち、１つは発信サービス制御エンティティが用い、１つは着信サービス制御エンティティが用いる、請求項２６または２７に記載の電気通信システム用のソフトウエアシステム。２９．システムの更新の場合は、新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードし、実行中にパラメータ分散機能に影響を与える、請求項２８に記載の電気通信システム用のソフトウエアシステム。３０．前記アプリケーション論理は通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またアプリケーション論理はメッセージを送るよう通信サービス（ＩＴＳ）に指示する、請求項２８または２９に記載の電気通信システム用のソフトウエアシステム。３１．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を他の論理ノードに実質的に知られないようにしてアプリケーション設計において決定する、請求項２６−３０のいずれかに記載の電気通信システム用のソフトウエアシステム。３２．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置く、請求項３１に記載の電気通信システム用のソフトウエアシステム。３３．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースは、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を含む、請求項２６−３２のいずれかに記載の電気通信システム用のソフトウエアシステム。３４．通信サービス（ＩＴＳ）から１つのパラメータまたはパラメータの特定の組を受信した場合は、プロトコル処理エンティティ（ＡＳＰＥ）は前記アプリケーション論理に或る事象を出す、請求項２６−３３のいずれかに記載の電気通信システム用のソフトウエアシステム。３５．アプリケーション論理（ＡＬ）はトラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項２０−２４のいずれかに記載の電気通信システム用のソフトウエアシステム。３６．各プロトコルパラメータは、パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に関連する、請求項２０−３５のいずれかに記載の電気通信システム用のソフトウエアシステム。３７．通信サービス（ＩＴＳ）は、１組のメッセージと、対応する状態機械を用いる、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなくまたアプリケーション設計者は知る必要がない、請求項２１−３６のいずれかに記載の電気通信システム用のソフトウエアシステム。３８．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエア内で実現されるサービス制御エンティティとを備える電気通信システム内の、内部通信の方法であって、分割できない情報伝送要素の形でプロトコルパラメータを交換することにより、総称プロトコルモデルに従って異なるノードのサービス制御エンティティ間の通信を行うステップ、を含む、電気通信システム内の内部通信の方法。３９．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエア内で実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアを構築する方法であって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、分割できない情報伝送要素の形のプロトコルパラメータの交換を規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則に基づくソフトウエア要素をシステム内に記憶するステップを含む、電気通信システム内のソフトウエアを構築する方法。４０．前記サービスプロトコル内の伝送できる最小データユニットを構成する多数の定義されたプロトコルパラメータを、前記総称プロトコルモデルに関連させるステップを含む、請求項３８または３９に記載の方法。４１．サービスプロトコルを指定するときに、サービスに適した多数の定義された制御パラメータと、必要なときは新しいパラメータを、随意に選択するステップを含む、請求項３８−４０のいずれかに記載の方法。４２．総称プロトコルモデルに基づいて、各サービスに対応するサービスプロトコルを指定するステップを含む、請求項３８−４１のいずれかに記載の方法。４３．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様を与えるステップを含む、請求項３８−４２のいずれかに記載の方法。４４．前記サービスプロトコルはアプリケーション論理を含まない、請求項４０−４２のいずれかに記載の方法。４５．アプリケーション内にプロトコル処理エンティティ（ＡＳＰＥ）を設けて、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を管理するステップを含む、請求項４０−４３のいずれかに記載の方法。４６．相互に作用するプロトコル処理エンティティ（ＡＳＰＥ）を更新する必要なしに或るプロトコル処理エンティティを更新するステップを含む、請求項４５に記載の方法。４７．２つのサービス制御エンティティ間の通信のために、通信サービスはプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、またどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを通信サービス（ＩＴＳ）内にあるパラメータ分散機能により指示し、また１つのパラメータ分散リストを発信サービス制御エンティティに用い、１つのパラメータ分散リストを着信制御サービス制御エンティティに用いるように構築することを含む、請求項３８−４６のいずれかに記載の方法。４８．アプリケーション設計に関連してプロトコル処理エンティティ（ＡＳＰＥ）の構成を決定して、その構造を他の論理ノードに実質的に知られないようにすることを含む、請求項４５−４７のいずれかに記載の方法。４９．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、サービスの事象を生成するのに必要なパラメータをアプリケーション設計者は指定し、またサービス用の状態機械をアプリケーション論理内に置く、ステップを含む、請求項４８に記載の方法。５０．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項３８−４９のいずれかに記載の方法。５１．トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理をアプリケーション論理（ＡＬ）内に導入するステップを含む、請求項３８−５０のいずれかに記載の方法。５２．パラメータが理解できないときにどうするかを受信プロトコル処理エンティティに指示する命令標識を各プロトコルパラメータに関連させるステップを含む、請求項３８−５１のいずれかに記載の方法。５３．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアシステムであって、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用とを規定する総称プロトコルモデル（ＴＳＰＭ）に示す規則を用いて、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御する、電気通信システム用のソフトウエアシステム。５４．総称プロトコルモデル（ＴＳＰＭ）は、前記サービスプロトコル内で伝送できる最小データユニットを構成する多数の定義されたプロトコルパラメータに関連する、請求項５３に記載の電気通信システム用のソフトウエアシステム。５５．サービスプロトコルの仕様は、随意に選択されたサービスの適当な数のプロトコルパラメータと、必要なときは新しいプロトコルパラメータを含む、請求項５３または５４に記載の電気通信システム用のソフトウエアシステム。５６．各サービスに対応し、総称プロトコルモデル（ＴＳＰＭ）に基づいて指定される、サービスプロトコル（ＡＳＰ）を含む、請求項５３−５５のいずれかに記載の電気通信システム用のソフトウエアシステム。５７．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項５３−５６のいずれかに記載の電気通信システム用のソフトウエアシステム。５８．前記サービスプロトコルはアプリケーション論理を含まない、請求項５３−５７のいずれかに記載の電気通信システム用のソフトウエアシステム。５９．アプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）は、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行う、請求項５４−５８のいずれかに記載の電気通信システム用のソフトウエアシステム。６０．プロトコル処理エンティティ（ＡＳＰＥ）の更新は、これと相互に作用するプロトコル処理エンティティの更新を必要としない、請求項５９に記載の電気通信システム用のソフトウエアシステム。６１．２つのサービス制御エンティティ間の通信の場合は、通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、通信サービス（ＩＴＳ）内にあるパラメータ分散機能はどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、また２つのパラメータ分散リストを用いる、すなわち、１つは発信サービス制御エンティティが用い、１つは着信サービス制御エンティティが用いる、請求項５３−６０のいずれかに記載の電気通信システム用のソフトウエアシステム。６２．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を他の論理ノードに知られないようにしてアプリケーション設計者が決定する、請求項５９−６１のいずれかに記載の電気通信システム用のソフトウエアシステム。６３．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械をアプリケーション論理内に置く、請求項６２に記載の電気通信システム用のソフトウエアシステム。６４．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースは、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記ブロトコル処理エンティティに送る方法を含む、請求項５９−６３のいずれかに記載の電気通信システム用のソフトウエアシステム。６５．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項５３−６４のいずれかに記載の電気通信システム用のソフトウエアシステム。６６．各プロトコルパラメータは、パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に関連する、請求項５３−６５のいずれかに記載の電気通信システム用のソフトウエアシステム。６７．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システム内の、内部通信の方法であって、それぞれ或るサービスに対応する指定されたサービスプロトコル（ＡＳＰ）があることに基づいて、総称プロトコルモデル（ＴＳＰＭ）によりサービス制御エンティティ間の通信を行うステップを含む、電気通信システム内の内部通信の方法。６８．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアを構築する方法であって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、それぞれ或るサービスに対応する指定されたサービスプロトコル（ＡＳＰ）があることに基づいて、総称プロトコルモデル（ＴＳＰＭ）に基づくソフトウエア要素をシステム内に記憶するステップを含む、電気通信システム内のソフトウエアを構築する方法。６９．サービスプロトコルを指定するときに、サービスの適当な数のプロトコルパラメータを随意に選択し、また必要なときは新しいパラメータを定義するステップを含む、請求項６７または６８に記載の方法。７０．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項６７−６９のいずれかに記載の方法。７１．前記サービスプロトコルはアプリケーション論理を含まない、請求項６７−７０のいずれかに記載の方法。７２．アプリケーション内にプロトコル処理エンティティ（ＡＳＰＥ）を設けて、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行うステップを含む、請求項６７−７１のいずれかに記載の方法。７３．相互に作用するプロトコル処理エンティティ（ＡＳＰＥ）を更新する必要なしに或るプロトコル処理エンティティを更新するステップを含む、請求項７２に記載の方法。７４．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造が他の論理ノードに実質的に知られないようにしてアプリケーション設計において決定する、請求項７２か７３に記載の方法。７５．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、サービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械をアプリケーション論理内に置くステップを含む、請求項７４に記載の方法。７６．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項７２−７５のいずれかに記載の方法。７７．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項６７−７６のいずれかに記載の方法。７８．パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に各プロトコルパラメータを関連させるステップを含む、請求項６７−７７のいずれかに記載の方法。７９．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、各サービスに対応してどのサービスプロトコル（ＡＳＰ）を指定するかに基づいて、総称プロトコルモデル（ＴＳＰＭ）に示す規則をシステム内で用いる、ステップを含む、電気通信システム用のソフトウエアシステム。８０．サービスプロトコルを指定するときに、サービスの適当な数のプロトコルパラメータを随意に選択し、また必要なときは新しいパラメータを定義するステップを含む、請求項７９に記載の電気通信システムのソフトウエアシステム。８１．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項７９または８０に記載の電気通信システム用のソフトウエアシステム。８２．前記サービスプロトコルはアプリケーション論理を含まない、請求項７９−８１のいずれかに記載の電気通信システム用のソフトウエアシステム。８３．アプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）は、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行う、請求項７９−８２のいずれかに記載の通信システム用のソフトウエアシステム。８４．プロトコル処理エンティティ（ＡＳＰＥ）の更新は相互に作用するプロトコル処理エンティティの更新必要としない、請求項８３に記載の通信システム用のソフトウエアシステム。８５．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造が他の論理ノードに実質的に知られないようにしてアプリケーション設計において決定する、請求項８３か８４に記載の電気通信システム用のソフトウエアシステム。８６．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械をアプリケーション論理内に置く、請求項８５に記載の電気通信システム用のソフトウエアシステム。８７．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースは、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を含む、請求項７９−８６のいずれかに記載の電気通信システム用のソフトウエアシステム。８８．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項７９−８７のいずれかに記載の電気通信システムのソフトウエアシステム。８９．各プロトコルパラメータを、パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に関連させることを含む、請求項７９−８８のいずれかに記載の電気通信システムのソフトウエアシステム。９０．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システム内の、内部通信の方法であって、プロトコルパラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により分散される前記パラメータを交換することにより、異なるノードのサービス制御エンティティ間の通信を総称プロトコルモデル（ＴＳＰＭ）に従って行う、ステップを含む、電気通信システム内の内部通信の方法。９１．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアを構築する方法であって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、プロトコルパラメータの交換を規定する総称プロトコルモデル（ＴＳＰＭ）に基づくソフトウエア要素をシステム内に記憶するステップを含み、前記プロトコルパラメータはそのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により分散される、電気通信システム内のソフトウエアを構築する方法。９２．総称プロトコルモデル（ＴＳＰＭ）に基づいて各サービスに対応するサービスプロトコル（ＡＳＰ）を指定し、サービスプロトコル（ＡＳＰ）に従って或るサービスのプロトコル処理を行うアプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）を提供し、通信サービス（ＩＴＳ）はプロトコル管理エンティティ間にデータを伝送するステップを含む、請求項９０または９１に記載の方法。９３．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様を与えるステップを含む、請求項９０−９２のいずれかに記載の方法。９４．２つのサービス制御エンティティ間の通信を行うときは、通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、また通信サービス（ＩＴＳ）内にあるパラメータ分散機能はどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、またこれに関して用いる２つのパラメータ分散リストを与える、すなわち、１つのパラメータ分散リストを発信サービス制御エンティティに、１つのパラメータリストを着信サービス制御エンティティに与える、ようにソフトウエアを構築することを含む、請求項９０−９３のいずれかに記載の方法。９５．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を他の論理ノードに実質的に知られないようにしてアプリケーション設計において決定する、請求項９２−９４のいずれかに記載の方法。９６．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、サービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置くステップを含む、請求項９５に記載の方法。９７．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項９０−９６のいずれかに記載の方法。９８．新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードしてシステムを更新し、実行中にパラメータ分散機能に影響を与えるステップを含む、請求項９２−９７のいずれかに記載の方法。９９．前記アプリケーション論理は通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またアプリケーション論理はメッセージを送るよう通信サービス（ＩＴＳ）に指示することを含む、請求項９２−９８のいずれかに記載の方法。１００．前記通信サービスから１つのパラメータまたはパラメータの或る組を受信したとき、プロトコル処理エンティティ（ＡＳＰＥ）は前記アプリケーションに或る事象を出すことを含む、請求項９２−９９のいずれかに記載の方法。１０１．総称プロトコルモデル（ＴＳＰＭ）に基づいて各サービスに対応するサービスプロトコル（ＡＳＰ）を指定し、また通信サービス（ＩＴＳ）は１組のメッセージと、対応する状態機械を用いることを含む、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなくまたアプリケーション設計者は知る必要がない、請求項９０−１０１のいずれかに記載の方法。１０２．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、総称プロトコルモデル（ＴＳＰＭ）に基づく規則をシステムに与えるステップを含み、前記規則はプロトコルパラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により分散される前記パラメータの交換を規定する、電気通信システムのソフトウエアシステム。１０３．総称プロトコルモデル（ＴＳＰＭ）に基づいて各サービスに対応するサービスプロトコル（ＡＳＰ）を指定し、サービスプロトコル（ＡＳＰ）に従って或るサービスのプロトコル処理を行うアプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）を提供し、通信サービス（ＩＴＳ）はプロトコル管理エンティティ間にデータを伝送するステップを含む、請求項１０２に記載の方法。１０４．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様を与えるステップを含む、請求項１０２または１０３に記載の方法。１０５．２つのサービス制御エンティティ間の通信を行うときは、通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、通信サービス（ＩＴＳ）内にあるパラメータ分散機能はどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、またこれに関して用いる２つのパラメータ分散リストを与える、すなわち、１つのパラメータ分散リストを発信サービス制御エンティティに、１つのパラメータリストを着信サービス制御エンティティに与える、ようにソフトウエアを構築することを含む、請求項１０２−１０４のいずれかに記載の方法。１０６．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を他の論理ノードに実質的に知られないようにしてアプリケーション設計において決定する、請求項１０２−１０５のいずれかに記載の方法。１０７．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置く、ステップを含む請求項１０６に記載の方法。１０８．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項１０２−１０７のいずれかに記載の方法。１０９．新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードしてシステムを更新し、実行中にパラメータ分散機能に影響を与えるステップを含む、請求項１０３−１０８のいずれかに記載の方法。１１０．前記アプリケーション論理は通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またアプリケーション論理はメッセージを送るよう通信サービス（ＩＴＳ）に指示することを含む、請求項１０２−１０９のいずれかに記載の方法。１１１．前記通信サービスから１つのパラメータまたはパラメータの或る組を受信したとき、プロトコル処理エンティティ（ＡＳＰＥ）は前記アプリケーションに或る事象を出すことを含む、請求項１０３−１１０のいずれかに記載の方法。１１２．総称プロトコルモデル（ＴＳＰＭ）に基づいて各サービスに対応するサービスプロトコル（ＡＳＰ）を指定し、また通信サービス（ＩＴＳ）は１組のメッセージと、対応する状態機械を用いることを含む、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなくまたアプリケーション設計者は知る必要がない、請求項１０２−１１１のいずれかに記載の方法。１１３．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システム内の、内部通信の方法であって、前記サービス制御エンティティにとって意味のないメッセージ内に分散されているプロトコルパラメータを交換することにより、異なるノードのサービス制御エンティティ間の通信を総称プロトコルモデル（ＴＳＰＭ）に従って行うステップを含む、電気通信システム内の内部通信の方法。１１４．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアを構築する方法であって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、プロトコルパラメータの交換を規定する総称プロトコルモデル（ＴＳＰＭ）に基づくソフトウエア要素をシステム内に記憶するステップを含み、前記プロトコルパラメータはメッセージ内に分散されていて前記サービス制御エンティティにとって意味がない、電気通信システム内のソフトウエアを構築する方法。１１５．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項１１３または１１４に記載の方法。１１６．２つのパラメータ分散機能、すなわち発信サービス制御エンティティに用いる１つの機能と着信サービス制御エンティティに用いる１つの機能、を持つ総称プロトコルモデルに従ってインターフェースを実現するステップを含む、請求項１１３−１１５のいずれかに記載の方法。１１７．パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に各プロトコルパラメータを関連させるステップを含む、請求項１１３−１１６のいずれかに記載の方法。１１８．電気通信サービス用の論理網と、前記論理網内の論理ノードと、呼の一部のサービスを制御し前記論理ノード内で指定されかつこれらの機能を実行する形のソフトウエアで実現されるサービス制御エンティティとを備える電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内のサービス制御エンティティ間の内部通信を制御するため、プロトコルパラメータの交換を規定する総称プロトコルモデル（ＴＳＰＭ）に基づく規則をシステム内で用いることを含み、前記プロトコルメッセージはメッセージ内に分散されていて前記サービス制御エンティティにとって意味がない、電気通信システム用のソフトウエアシステム。１１９．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項１１８に記載の電気通信システム用のソフトウエアシステム。１２０．前記総称プロトコルモデルに従って作成され、２つのパラメータ分散機能、すなわち発信サービス制御エンティティに用いる１つの機能と、着信サービス制御エンティティに用いる１つの機能を持つ、インターフェースを実現するステップを含む、請求項１１８または１１９に記載の電気通信システム用のソフトウエアシステム。１２１．パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に各プロトコルパラメータを関連させるステップを含む、請求項１１８−１２０のいずれかに記載の電気通信システム用のソフトウエアシステム。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ (72)発明者トルンストロム，ヨハンスウェーデン国エス − 136 41 ハニンゲ，バラベーゲン 374 (72)発明者スンドクイスト，マルテンスウェーデン国エス − 129 42 ハゲルステン，バックビンデルン 126 (72)発明者オールマン，ボルイエスウェーデン国エス − 118 25 ストックホルム，バスツガタン 31 (72)発明者スベンソン，マッツラグナルスウェーデン国エス − 117 65 ストックホルム，グレンルユスバッケン 15 (72)発明者バックストロム，スベンスウェーデン国エス − 131 31 ナッカ，オストラヘンリクスボルグスベーゲン 68 (72)発明者マルティンソン，ハンススウェーデン国エス − 134 37 グスタブスベルグ，コルスバルススチゲン 26 (72)発明者ヒルボルグ，ミカエルレンナルトスウェーデン国エス − 752 28 ウップサラ，セミナリエガタン 17 (72)発明者グラーフ，レスリーオーストラリア国 3103 ビクトリア，メルボルン，バルウィン，ロチェスターロード 85

Claims

【特許請求の範囲】１．電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信の方法であって、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用とを規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則により、サービス制御エンティティ間の電気通信を制御するステップと、前記パラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により前記伝送要素を分散させるステップと、を含む、電気通信システム内の内部通信の方法。２．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアを構築する方法であって、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用を規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則に基づいてシステム内にソフトウエア要素を記憶し、また前記パラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により前記伝送要素を分散させることにより、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御するステップを含む、電気通信システム内のソフトウエアを構築する方法。３．総称プロトコルモデル（ＴＳＰＭ）に基づいて、各サービスに対応するサービスプロトコル（ＡＳＰ）を指定するステップを含む、請求項１または２に記載の方法。４．前記サービスプロトコル内の伝送できる最小データユニットを構成する多数の定義された制御パラメータを、前記総称プロトコルモデル（ＴＳＰＭ）に関連させるステップを含む、請求項３に記載の方法。５．サービス用の適当な数のプロトコルパラメータを随意に選択し、また必要なときは新しいプロトコルパラメータを定義することにより、サービスプロトコルを指定するステップを含む、請求項３または４に記載の方法。６．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様を与えるステップを含む、請求項３、４または５に記載の方法。７．前記サービスプロトコルはアプリケーション論理を含まない、請求項３ −６のいずれかに記載の方法。８．アプリケーション内にプロトコル処理エンティティ（ＡＳＰＥ）を設けて、サービスプロトコル（ＡＳＰ）に従って或るサービスのプロトコル処理を管理するステップを含む、請求項３−７のいずれかに記載の方法またはシステム。９．相互に作用するプロトコル処理エンティティ（ＡＳＰＥ）を更新する必要なしに或るプロトコル処理エンティティを更新するステップを含む、請求項８に記載の方法。１０．通信サービス（ＩＴＳ）によりプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送することによって、またどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを通信サービス（ＩＴＳ）内にあるパラメータ分散機能により指示することによって、また１つのパラメータ分散リストを発信サービス制御エンティティに用い、１つのパラメータリストを着信サービス制御エンティティに用いることによって、２つのサービス制御エンティティ間の通信を行うステップを含む、請求項８または９に記載の方法。１１．新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードすることによりシステムを更新して、実行中にパラメータ分散機能に影響を与えるステップを含む、請求項８−１０のいずれかに記載の方法。１２．アプリケーション論理を用いて、通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またメッセージを送るよう通信サービス（ＩＴＳ）に指示するステップを含む、請求項１０または１１に記載の方法。１３．アプリケーション設計に関連してプロトコル処理エンティティ（ＡＳＰＥ）を構成して、その構造を他の論理ノードに実質的に知られないようにする、請求項８−１２のいずれかに記載の方法。１４．各プロトコル処理エンティティ（ＡＳＰＥ）毎にサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置くステップを含む、請求項１３に記載の方法。１５．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項８−１４のいずれかに記載の方法。１６．通信サービス（ＩＴＳ）から１つのパラメータまたはパラメータの特定の組を受信した場合は、プロトコル処理エンティティ（ＡＳＰＥ）からアプリケーション論理に或る事象を出すステップを含む、請求項８−１５のいずれかに記載の方法。１７．トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理をアプリケーション論理（ＡＬ）内に導入するステップを含む、前記請求項のいずれかに記載の方法。１８．パラメータが理解できないときにどうするかを受信プロトコル処理エンティティに指示する命令標識を各プロトコルパラメータに関連させるステップを含む、前記請求項のいずれかに記載の方法。１９．１組のメッセージと、対応する状態機械を通信サービス（ＩＴＳ）が用いるステップを含む、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなくまたアプリケーション設計者は知る必要がない、請求項３− １８のいずれかに記載の方法。２０．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御するために、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用とが総称プロトコルモデル（ＴＳＰＭ）の規則に規定され、前記情報伝送要素は前記パラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により分散されるようになっている、前記規則を備える、電気通信システム用のソフトウエアシステム。２１．各サービスに対応し、総称プロトコルモデル（ＴＳＰＭ）に基づいて指定されるサービスプロトコル（ＡＳＰ）を備える、請求項２０に記載の電気通信システム用のソフトウエアシステム。２２．総称プロトコルモデル（ＴＳＰＭ）は、前記サービスプロトコル内で伝送できる最小データユニットを構成する多数の定義されたプロトコルパラメータに関連する、請求項２１に記載の電気通信システム用のソフトウエアシステム。２３．サービスプロトコルの仕様は、随意に選択されたサービスの適当な数のプロトコルパラメータと、必要なときは新しいプロトコルパラメータを含む、請求項２１または２２に記載の電気通信システム用のソフトウエアシステム。２４．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項２１−２３のいずれかに記載の電気通信システム用のソフトウエアシステム。２５．前記サービスプロトコルはアプリケーション論理を含まない、請求項２１−２４のいずれかに記載の電気通信システム用のソフトウエアシステム。２６．アプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）は、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行う、請求項２１−２５のいずれかに記載の電気通信システム用のソフトウエアシステム。２７．プロトコル処理エンティティ（ＡＳＰＥ）の更新は、これと相互に作用するプロトコル処理エンティティの更新を必要としない、請求項２６に記載の電気通信システム用のソフトウエアシステム。２８．２つのサービス制御エンティティ間の通信の場合は、通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、通信サービス（ＩＴＳ）内にあるパラメータ分散機能はどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、また２つのパラメータ分散リストを用いる、すなわち、１つは発信サービス制御エンティティが用い、１つは着信サービス制御エンティティが用いる、請求項２６または２７に記載の電気通信システム用のソフトウエアシステム。２９．システムの更新の場合は、新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードし、実行中にパラメータ分散機能に影響を与える、請求項２６−２８のいずれかに記載の電気通信システム用のソフトウエアシステム。３０．前記アプリケーション論理は通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またアプリケーション論理はメッセージを送るよう通信サービス（ＩＴＳ）に指示する、請求項２８または２９に記載の電気通信システム用のソフトウエアシステム。３１．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を他の論理ノードに主として知られないようにしてアプリケーション設計において決定する、請求項２６−３０のいずれかに記載の電気通信システム用のソフトウエアシステム。３２．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置く、請求項３１に記載の電気通信システム用のソフトウエアシステム。３３．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースは、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を含む、請求項２６−３２のいずれかに記載の電気通信システム用のソフトウエアシステム。３４．通信サービス（ＩＴＳ）から１つのパラメータまたはパラメータの特定の組を受信した場合は、プロトコル処理エンティティ（ＡＳＰＥ）は前記アプリケーション論理に或る事象を出す、請求項２６−３３のいずれかに記載の電気通信システム用のソフトウエアシステム。３５．アプリケーション論理（ＡＬ）はトラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項２０−２４のいずれかに記載の電気通信システム用のソフトウエアシステム。３６．各プロトコルパラメータは、パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に関連する、請求項２０−３５のいずれかに記載の電気通信システム用のソフトウエアシステム。３７．通信サービス（ＩＴＳ）は、１組のメッセージと、対応する状態機械を用いる、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなく、またアプリケーション設計者は知る必要がない、請求項２１−３６のいずれかに記載の電気通信システム用のソフトウエアシステム。３８．電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信の方法であって、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用とを規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則により、サービス制御エンティティ間の通信を制御する、ステップを含む、電気通信システム内の内部通信の方法。３９．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアを構築する方法であって、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用とを規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則に基づいてシステム内にソフトウエア要素を記憶することにより、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御する、ステップを含む、電気通信システム内のソフトウエアを構築する方法。４０．総称プロトコルモデル（ＴＳＰＭ）に基づいて、各サービスに対応するサービスプロトコル（ＡＳＰ）を指定するステップを含む、請求項３８または３９に記載の方法。４１．前記サービスプロトコル内の伝送できる最小データユニットを構成する多数の定義されたプロトコルパラメータを、前記総称プロトコルモデル（ＴＳＰＭ）に関連させるステップを含む、請求項４０に記載の方法。４２．サービス用の適当な数のプロトコルパラメータを随意に選択することによりサービスプロトコルを指定し、また必要なときは新しいパラメータを定義する、ステップを含む、請求項４０または４１に記載の方法。４３．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様を与えるステップを含む、請求項４０−４２のいずれかに記載の方法。４４．前記サービスプロトコルはアプリケーション論理を含まない、請求項４０−４３のいずれかに記載の方法。４５．アプリケーション内にプロトコル処理エンティティ（ＡＳＰＥ）を設けて、サービスプロトコル（ＡＳＰ）に従って或るサービスのプロトコル処理を管理するステップを含む、請求項４０−４４のいずれかに記載の方法。４６．相互に作用するプロトコル処理エンティティ（ＡＳＰＥ）を更新する必要なしに或るプロトコル処理エンティティを更新するステップを含む、請求項４５に記載の方法。４７．通信サービス（ＩＴＳ）によってプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送することにより２つのサービス制御エンティティ間の通信を行い、どのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを通信サービス（ＩＴＳ）内にあるパラメータ分散機能により指示し、また１つのパラメータ分散リストを発信サービス制御エンティティに用い、１つのパラメータ分散リストを着信制御サービス制御エンティティに用いることを含む、請求項４５または４６に記載の方法。４８．アプリケーション設計に関連してプロトコル処理エンティティ（ＡＳＰＥ）を構成して、その構造を他の論理ノードに実質的に知られないようにすることを含む、請求項４５−４７のいずれかに記載の方法。４９．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、サービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械をアプリケーション論理内に置く、ステップを含む、請求項４８に記載の方法。５０．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項４５−４９のいずれかに記載の方法。５１．トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理をアプリケーション論理（ＡＬ）内に導入するステップを含む、請求項３８−５０のいずれかに記載の方法。５２．パラメータが理解できないときにどうするかを受信プロトコル処理エンティティに指示する命令標識を各プロトコルパラメータに関連させるステップを含む、請求項３８−５１のいずれかに記載の方法。５３．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御するために、メッセージがないことと、分割できない情報伝送要素の形のプロトコルパラメータだけの使用とを規定する総称プロトコルモデル（ＴＳＰＭ）に示す規則、を備える、電気通信システム用のソフトウエアシステム。５４．各サービスに対応しかつ総称プロトコルモデル（ＴＳＰＭ）に基づいて指定されるサービスプロトコル（ＡＳＰ）を備える、請求項５３に記載の電気通信システム用のソフトウエアシステム。５５．総称プロトコルモデル（ＴＳＰＭ）は、前記サービスプロトコル内で伝送できる最小データユニットを構成する多数の定義されたプロトコルパラメータに関連する、請求項５４に記載の電気通信システム用のソフトウエアシステム。５６．サービスプロトコルの仕様は、随意に選択されたサービスの適当な数のプロトコルパラメータと、必要なときは新しいプロトコルパラメータを含む、請求項５４または５５に記載の電気通信システム用のソフトウエアシステム。５７．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項５４−５６のいずれかに記載の電気通信システム用のソフトウエアシステム。５８．前記サービスプロトコルはアプリケーション論理を含まない、請求項５４−５７のいずれかに記載の電気通信システム用のソフトウエアシステム。５９．アプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）は、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行う、請求項５４−５８のいずれかに記載の電気通信システム用のソフトウエアシステム。６０．プロトコル処理エンティティ（ＡＳＰＥ）の更新は、これと相互に作用するプロトコル処理エンティティの更新を必要としない、請求項５９に記載の電気通信システム用のソフトウエアシステム。６１．２つのサービス制御エンティティ間の通信の場合は、通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、通信サービス（ＩＴＳ）内にあるパラメータ分散機能はどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、また２つのパラメータ分散リストを用いる、すなわち、１つは発信サービス制御エンティティが用い、１つは着信サービス制御エンティティが用いる、請求項５９または６０に記載の電気通信システム用のソフトウエアシステム。６２．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を主として他の論理ノードに知られないようにしてアプリケーション設計のときに決定する、請求項５９−６１のいずれかに記載の電気通信システム用のソフトウエアシステム。６３．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械をアプリケーション論理内に置く、請求項６２に記載の電気通信システム用のソフトウエアシステム。６４．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースは、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を含む、請求項５９−６３のいずれかに記載の電気通信システム用のソフトウエアシステム。６５．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項５３−６４のいずれかに記載の電気通信システム用のソフトウエアシステム。６６．各プロトコルパラメータは、パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に関連する、請求項５３−６５のいずれかに記載の電気通信システム用のソフトウエアシステム。６７．電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信の方法であって、それぞれ１つのサービスに対応するどのサービスプロトコル（ＡＳＰ）を指定するかに基づいて、総称プロトコルモデル（ＴＳＰＭ）に示す規則によってサービス制御エンティティ間の通信を制御するステップを含む、電気通信システム内の内部通信の方法。６８．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアを構築する方法であって、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御するために、それぞれ１つのサービスに対応するどのサービスプロトコル（ＡＳＰ）を指定するかに基づいて、総称プロトコルモデル（ＴＳＰＭ）に示す規則に基づいてシステム内にソフトウエア要素を記憶するステップ、を含む、電気通信システム内のソフトウエアを構築する方法。６９．サービス用の適当な数のプロトコルパラメータを随意に選択し、また必要なときは新しいパラメータを定義する、ステップを含む、請求項６７または６８に記載の方法。７０．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項６７−６９のいずれかに記載の方法。７１．前記サービスプロトコルはアプリケーション論理を含まない、請求項６７−７０のいずれかに記載の方法。７２．アプリケーション内にプロトコル処理エンティティ（ＡＳＰＥ）を持ち、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行うステップを含む、請求項６７−７１のいずれかに記載の方法。７３．相互に作用するプロトコル処理エンティティ（ＡＳＰＥ）を更新する必要なしに或るプロトコル処理エンティティを更新するステップを含む、請求項７２に記載の方法。７４．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造が主として他の論理ノードに知られないようにしてアプリケーション設計において決定する、請求項７２か７３に記載の方法。７５．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、サービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械をアプリケーション論理内に置くステップを含む、請求項７４に記載の方法。７６．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項７２−７５のいずれかに記載の方法。７７．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項６７−７６のいずれかに記載の方法。７８．パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に各プロトコルパラメータを関連させるステップを含む、請求項６７−７７のいずれかに記載の方法。７９．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御するために、総称プロトコルモデル（ＴＳＰＭ）に示す規則と、各サービスに対応し総称プロトコルモデル（ＴＳＰＭ）に基づいて指定するサービスプロトコル（ＡＳＰ）、を含む、電気通信システム用のソフトウエアシステム。８０．サービスプロトコルの仕様は、随意に選択された、サービスの適当な数のプロトコルパラメータと、必要なときは新しいパラメータを含む、請求項７９に記載の電気通信システムのソフトウエアシステム。８１．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項７９または８０に記載の電気通信システム用のソフトウエアシステム。８２．前記サービスプロトコルはアプリケーション論理を含まない、請求項７９−８１のいずれかに記載の電気通信システム用のソフトウエアシステム。８３．アプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）は、サービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を行う、請求項７９−８２のいずれかに記載の通信システム用のソフトウエアシステム。８４．プロトコル処理エンティティ（ＡＳＰＥ）の更新は相互に作用するプロトコル処理エンティティの更新必要としない、請求項８３に記載の通信システム用のソフトウエアシステム。８５．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造が主として他の論理ノードに知られないようにしてアプリケーション設計において決定する、請求項８３か８４に記載の電気通信システム用のソフトウエアシステム。８６．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械をアプリケーション論理内に置く、請求項８５に記載の電気通信システム用のソフトウエアシステム。８７．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースは、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を含む、請求項８３−８６のいずれかに記載の電気通信システム用のソフトウエアシステム。８８．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項７９−８７のいずれかに記載の電気通信システムのソフトウエアシステム。８９．各プロトコルパラメータを、パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に関連させることを含む、請求項７９−８８のいずれかに記載の電気通信システムのソフトウエアシステム。９０．電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信の方法であって、プロトコルパラメータの使用を規定する総称プロトコルモデル（ＴＳＰＭ）に示す規則によってサービス制御エンティティ間の電気通信を制御するステップと、前記プロトコルパラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により前記パラメータを分散させるステップと、を含む、電気通信システム内の内部通信の方法。９１．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアを構築する方法であって、プロトコルパラメータの使用を規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則に基づいてシステム内にソフトウエア要素を記憶し、また前記プロトコパラメータのパラメータ分散機能を持つ通信サービス（ＩＴＳ）により前記パラメータを分散させることにより、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御する、ステップを含む、電気通信システム内のソフトウエアを構築する方法。９２．総称プロトコルモデル（ＴＳＰＭ）に基づいて各サービスに対応するサービスプロトコル（ＡＳＰ）を指定し、サービスプロトコル（ＡＳＰ）に従って或るサービスを処理するアプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）により管理し、前記通信サービス（ＩＴＳ）によりプロトコル管理エンティティ間にデータを伝送するステップを含む、請求項９０または９１に記載の方法。９３．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様を与えるステップを含む、請求項９２に記載の方法。９４．２つのサービス制御エンティティ間の通信を、通信サービス（ＩＴＳ）によってプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送することにより行い、また通信サービス（ＩＴＳ）内にあるパラメータ分散機能により、どのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、また１つのパラメータ分散リストを発信サービス制御エンティティに、１つのパラメータリストを着信サービス制御エンティティに用いる、ステップを含む、請求項９２または９３に記載の方法。９５．アプリケーション設計におけるプロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を他の論理ノードに実質的に知られないようにするステップを含む、請求項９２−９４のいずれかに記載の方法。９６．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、サービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置くステップを含む、請求項９５に記載の方法。９７．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースに、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を与えるステップを含む、請求項９２−９６のいずれかに記載の方法。９８．新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードしてシステムを更新し、実行中にパラメータ分散機能に影響を与えるステップを含む、請求項９２−９７のいずれかに記載の方法。９９．前記アプリケーション論理を用いて、通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またメッセージを送るよう通信サービス（ＩＴＳ）に指示することを含む、請求項９２ −９８のいずれかに記載の方法。１００．前記通信サービス（ＩＴＳ）から１つのパラメータまたはパラメータの或る組を受信したとき、プロトコル処理エンティティ（ＡＳＰＥ）から前記アプリケーション論理に或る事象を出すステップを含む、請求項９２−９９のいずれかに記載の方法。１０１．総称プロトコルモデル（ＴＳＰＭ）に基づいて各サービスに対応するサービスプロトコル（ＡＳＰ）を指定し、また通信サービス（ＩＴＳ）を通して１組のメッセージと、対応する状態機械を用いることを含む、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなくまたアプリケーション設計者は知る必要がない、請求項９０に記載の方法。１０２．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御するために、パラメータ分散機能を持つ通信サービス（ＩＴＳ）により分散するプロトコルパラメータの使用を規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則、を含む、電気通信システム用のソフトウエアシステム。１０３．各サービスに対応し、総称プロトコルモデル（ＴＳＰＭ）に基づいて指定されるサービスプロトコル（ＡＳＰ）を備え、アプリケーション内のプロトコル処理エンティティ（ＡＳＰＥ）はサービスプロトコル（ＡＳＰ）に従って特定のサービスのプロトコル処理を扱い、また通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送する、請求項２０に記載の電気通信システム用のソフトウエアシステム。１０４．各サービスプロトコル（ＡＳＰ）毎に、授受するパラメータのリストを含むプロトコル仕様がある、請求項１０３に記載の電気通信システム用のソフトウエアシステム。１０５．２つのサービス制御エンティティ間の通信を行う場合は、通信サービス（ＩＴＳ）はプロトコル処理エンティティ（ＡＳＰＥ）間にデータを伝送し、通信サービス（ＩＴＳ）内にあるパラメータ分散機能はどのプロトコル処理エンティティ（ＡＳＰＥ）に各プロトコルパラメータを送るかを指示し、また２つのパラメータ分散リストを用いる、すなわち、１つを発信サービス制御エンティティが、１つを着信サービス制御エンティティが用いる、請求項１０３または１０４に記載の電気通信システム用のソフトウエアシステム。１０６．プロトコル処理エンティティ（ＡＳＰＥ）の構成は、その構造を主として他の論理ノードに知られないようにしてアプリケーション設計において決定する、請求項１０３−１０５のいずれかに記載の電気通信システム用のソフトウエアシステム。１０７．各プロトコル処理エンティティ（ＡＳＰＥ）毎に、アプリケーション設計者はサービスの事象を生成するのに必要なパラメータを指定し、またサービス用の状態機械を前記アプリケーション論理内に置く、ステップを含む請求項１０６に記載の電気通信システム用のソフトウエアシステム。１０８．前記アプリケーション論理とプロトコル処理エンティティ（ＡＳＰＥ）間のサービス毎に１つあるインターフェースは、前記プロトコル処理エンティティから前記アプリケーション論理に送る事象の仕様と、前記アプリケーション論理から前記プロトコル処理エンティティに送る方法を含む、請求項１０３− １０７のいずれかに記載の電気通信システム用のソフトウエアシステム。１０９．システムを更新する場合は新しいまたは修正されたプロトコル処理エンティティ（ＡＳＰＥ）をロードして、実行中にパラメータ分散機能に影響を与える、請求項１０３−１０８のいずれかに記載の電気通信システム用のソフトウエアシステム。１１０．前記アプリケーション論理は通信サービス（ＩＴＳ）にパラメータを送る方法をプロトコル処理エンティティ（ＡＳＰＥ）に指示し、またアプリケーション論理はメッセージを送るよう通信サービス（ＩＴＳ）に指示することを含む、請求項１０３−１０９のいずれかに記載の電気通信システム用のソフトウエアシステム。１１１．前記通信サービス（ＩＴＳ）から１つのパラメータまたはパラメータの特定の組を受信したとき、プロトコル処理エンティティ（ＡＳＰＥ）は前記アプリケーション論理に或る事象を出す、請求項１０３−１１０のいずれかに記載の電気通信システム用のソフトウエアシステム。１１２．総称プロトコルモデル（ＴＳＰＭ）に基づいて各サービスに対応するサービスプロトコル（ＡＳＰ）を指定し、また通信サービス（ＩＴＳ）を通して１組のメッセージと、対応する状態機械を用いることを含む、ただし前記メッセージはサービスプロトコル（ＡＳＰ）にとって意味がなくまたアプリケーション設計者は知る必要がない、請求項１０２に記載の電気通信システム用のソフトウエアシステム。１１３．電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信の方法であって、メッセージがないこととプロトコルパラメータだけの使用を規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則によって、サービス制御エンティティ間の電気通信を制御するステップを含む、電気通信システム内の内部通信の方法。１１４．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアを構築する方法であって、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の内部通信を制御するステップと、メッセージがないこととプロトコルパラメータだけの使用とを規定する、総称プロトコルモデル（ＴＳＰＭ）に示す規則に基づいてシステム内にソフトウエア要素を記憶するステップ、を含む、電気通信システム内のソフトウエアを構築する方法。１１５．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項１１３または１１４に記載の方法。１１６．２つのパラメータ分散機能、すなわち発信サービス制御エンティティに用いる１つの機能と着信サービス制御エンティティに用いる１つの機能、を持つ総称プロトコルモデルに従ってインターフェースを実現するステップを含む、請求項１１３−１１５のいずれかに記載の方法。１１７．パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に各プロトコルパラメータを関連させるステップを含む、請求項１１３−１１６のいずれかに記載の方法。１１８．特定の機能を持つハードウエアおよびソフトウエア要素を備えまた複数のユーザが接続する電気通信システムの、ソフトウエアシステムであって、電気通信システムのトラヒックコース内の、同じまたは異なる電気通信サービス網内の論理ノードに属するサービス制御エンティティ間の、内部通信を制御するために、メッセージがないこととプロトコルパラメータだけの使用を規定する総称プロトコルモデル（ＴＳＰＭ）に示す規則を用いる、電気通信システム内のソフトウエアシステム。１１９．アプリケーション論理（ＡＬ）は、トラヒック処理、補足サービスの処理、サービス間の相互作用の全ての論理を含む、請求項１１８に記載の電気通信システム用のソフトウエアシステム。１２０．前記総称プロトコルモデルに従って作成され、２つのパラメータ分散機能、すなわち発信サービス制御エンティティに用いる１つの機能と、着信サービス制御エンティティに用いる１つの機能を持つ、インターフェースを実現するステップを含む、請求項１１８または１１９に記載の電気通信システム用のソフトウエアシステム。１２１．パラメータが理解できないときに受信プロトコル処理エンティティがどうするかを指示する命令標識に各プロトコルパラメータを関連させるステップを含む、請求項１１８−１２０のいずれかに記載の電気通信システム用のソフトウエアシステム。