JP4246356B2 - マルチメディア信号処理装置 - Google Patents
マルチメディア信号処理装置 Download PDFInfo
- Publication number
- JP4246356B2 JP4246356B2 JP2000240253A JP2000240253A JP4246356B2 JP 4246356 B2 JP4246356 B2 JP 4246356B2 JP 2000240253 A JP2000240253 A JP 2000240253A JP 2000240253 A JP2000240253 A JP 2000240253A JP 4246356 B2 JP4246356 B2 JP 4246356B2
- Authority
- JP
- Japan
- Prior art keywords
- spu
- attribute
- mode
- signal processing
- service type
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000012545 processing Methods 0.000 title claims description 90
- 238000004891 communication Methods 0.000 claims description 99
- 230000004044 response Effects 0.000 claims description 4
- 230000008859 change Effects 0.000 description 58
- 238000000034 method Methods 0.000 description 33
- 238000012423 maintenance Methods 0.000 description 32
- 238000010586 diagram Methods 0.000 description 20
- 230000008569 process Effects 0.000 description 20
- 230000006870 function Effects 0.000 description 9
- 238000004519 manufacturing process Methods 0.000 description 6
- 238000010295 mobile communication Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000012508 change request Methods 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000010276 construction Methods 0.000 description 2
- 230000007812 deficiency Effects 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 229960001948 caffeine Drugs 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000036962 time dependent Effects 0.000 description 1
- RYYVLZVUVIJVGH-UHFFFAOYSA-N trimethylxanthine Natural products CN1C(=O)N(C)C(=O)C2=C1N=CN2C RYYVLZVUVIJVGH-UHFFFAOYSA-N 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/147—Network analysis or design for predicting network behaviour
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/149—Network analysis or design for prediction of maintenance
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、マルチメディア信号処理装置に関し、例えば、一般的な公衆交換網や移動体（無線）通信網を構成するノード（上位ノード）に接続される交換装置など、上位ノードとの間で送受される信号（マルチメディア信号）に対して所要の信号処理を通信サービス種別に応じて行なう必要のある一装置に用いて好適な、マルチメディア信号処理装置に関する。
【０００２】
【従来の技術】
図２３は既存の公衆交換網の一例を模式的に示す図で、この図２３に示すように、通常、公衆交換網（以下、単に「公衆網」という）１００は、全国の加入者端末（電話機やパーソナルコンピュータ，ファクシミリなど）をそれぞれ近隣地域に設置された交換装置（交換局；ノード）に収容し、各地域の交換局を全てメッシュ状に接続することで構築するのは経済的ではないので、「トリー型網」と呼ばれる階層構造を基本として構築される。
【０００３】
即ち、日本の場合を例にすると、全国は、総括局（ＲＣ）１１０が１台ずつ置かれるいくつかの大きな区域（総括局区域；ＲＡ）１０１に分割され、さらに、各総括局区域１０１は、それぞれ、中心局（ＤＣ）１２０が１台ずつ置かれる中心局区域（ＤＡ）１０２に分割され、各中心局区域１０２は、それぞれ、集中局（ＴＣ）１３０が１台ずつ置かれる集中局区域（ＴＡ）１０３に分割され、各集中局区域１０３は、それぞれ、端局（ＥＯ）１４０が置かれる端局区域１０４に分割される。
【０００４】
そして、下位階層の局がそれぞれ上位階層の局にスター型網で接続される（例えば、端局１４０は集中局１３０に、集中局１３０は中心局１２０に、中心局１２０は総括局１１０にそれぞれ収容される）とともに、総括局１１０同士が基幹回線を介して接続されることで、公衆網１００が構築されるのである。
このような構成を採ることで、既存の公衆網１００では、例えば、東京−大阪間などの長距離市外通話の場合には、端局１４０を起点として集中局１３０，中心局１２０，総括局１１０という順に段階的に呼を集めて目的（着信先）の端局１４０を含む総括局１１０へ伝送すること、即ち、「トリー型網」に沿った呼の集配信が行なわれることにより、効率的な呼の伝送が可能になっている。
【０００５】
ところで、上位階層の局（上位ノード）に接続された交換装置に対する呼接続要求などのサービス要求（信号処理要求）には、例えば、音声通信やパケット通信，ＩＳＤＮ利用のデータ通信，ファクシミリ（ＦＡＸ）通信などの各種の通信サービス形態に応じた複数種類のサービス種別があり、また、呼毎にそのサービス種別も不定である。なお、「サービス種別」とは、通信サービスに固有の通信プロトコルの種別を意味する。
【０００６】
そして、このような様々なサービス種別の信号（マルチメディア信号）を交換装置で扱う必要がある場合、その交換装置は、マルチメディア信号の処理が可能な装置（マルチメディア信号処理装置）としても機能する必要があるため、例えば図２４に示すように、サービス種別（＃Ａ，＃Ｂ，＃Ｃなどと表わす）毎に各サービス種別に専用のパッケージ（ＰＫＧ）２００が、各サービス種別毎に予測される最大トラフィック（最大呼数）をカバーできる分だけ実装されて、上位ノード４００からのサービス要求毎にそのサービス種別に対応するパッケージ２００が選択され、サービス要求のあった呼に対する呼処理（信号処理）が実施されるようになっている。
【０００７】
即ち、例えば、上位ノード４００からサービス種別＃Ａについてのサービス要求があれば、交換装置は、主制御部３００における呼制御部３０１の制御の下で、サービス決定部３０２によって、受信したサービス要求に含まれる情報から呼のサービス種別＃Ａを判断／決定し、パッケージ実装状態管理部３０３にて管理されているパッケージ実装状態管理データ３３０に基づいて、サービス種別＃Ａ用のパッケージ２００のうち空き状態のパッケージ２００を、例えば、いわゆる入側トランク／出側トランクなどとして選択（捕捉）して呼処理を行なう。
【０００８】
なお、他のサービス種別＃Ｂや＃Ｃについてのサービス要求があった場合も同様に、対応するサービス種別＃Ｂ，＃Ｃ用の空きパッケージ２００が捕捉されて呼処理が実行される。
【０００９】
【発明が解決しようとする課題】
しかしながら、上述したような構成では、上位ノード４００からのサービス要求に対応するパッケージ２００がサービス種別毎に固定であるため、予測される最大トラフィックをカバーできる分のパッケージ２００を予め実装しておかなければならず、交換装置の規模が増大してしまうという課題がある。しかも、最大トラフィックを超える量の呼（過負荷トラフィック）が発生した場合には、上記の構成及び処理では、呼損の発生が余儀なくされていた。
【００１０】
本発明は、このような課題に鑑み創案されたもので、呼毎にパッケージ（通信サービスユニット）の信号処理モードをその呼のサービス種別に適したモードに変更できるようにすることで、パッケージの実装数を大幅に削減するとともに、呼損率を大幅に低減できるようにした、マルチメディア信号処理装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
複数種類のサービス種別に応じた複数種類の信号処理モードを有するサービスユニットと、上位ノードから通知される或る呼についての信号処理要求情報に基づいて該呼のサービス種別を識別するサービス種別識別手段と、前記呼のサービス種別のトラフィックに対してサービスユニットが不足した場合でも、他のサービス種別に適したモードで動作していた他のサービスユニットのモードを不足の生じたサービス種別対応のモードに変更する制御手段と、を有するマルチメディア信号処理装置を用いることができる。
さらに、複数種類の通信サービス種別に応じた複数種類の信号処理モードを有する通信サービスユニットと、上位ノードから通知される或る呼についての信号処理要求情報に基づいて該呼の通信サービス種別を識別する通信サービス種別識別手段と、該通信サービスユニットの信号処理モードを該通信サービス種別識別手段で識別された通信サービス種別に適したモードに制御するモード制御手段と、をそなえ、上記のモード制御手段は、過去に行なったモード制御についての履歴情報を管理する履歴情報管理手段と、前記の履歴情報に基づいて上記の通信サービスユニットの信号処理モードを予測制御する予測型モード制御手段とをそなえていてもよい。このような構成を採れば、通信サービスユニットのモードを過去のモード制御についての履歴に基づいて、或る時期のトラフィック傾向を予測して、その予測に応じたモード制御を実施することができる。
【００１４】
ここで、上記の予測型モード制御手段には、上記の履歴情報に基づいた時刻情報とモード設定情報とに基づいて、指定時刻に通信サービスユニットのモードを上記のモード設定情報に応じたモードに制御する時刻要因モード制御手段をそなえていてもよい。このような構成を採れば、例えば、或る特定の時間帯に特定のサービス種別のトラフィックが増大することが事前に分かっている場合などにおいて、その時間帯には通信サービスユニットのモードをそのサービス種別に適したモードに設定するといった制御が可能になる。
【００１５】
また、上記の通信サービスユニットは、複数種類の通信サービス種別に応じた複数種類の通信サービス制御プログラムを記憶した記憶手段と、上記のモード制御手段からの信号処理モード制御指示に応じて対応する通信サービス制御プログラムを上記記憶手段から選択的にロードすることにより、自身の信号処理モードを制御するモード選択制御手段とをそなえて構成されていてもよい。
【００１６】
このようにすれば、複数種類の通信サービス制御回路を個別にそなえる場合に比して、最小限のハードウェア規模で、複数種類の通信サービス種別に対応可能な通信サービスユニットを実現することができる。
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
図１は本発明の一実施形態に係る移動体通信網の構成を示すブロック図で、この図１に示す移動体通信網１０は、移動局（ＭＳ：Mobile Station）１，複数の無線基地局（ＢＴＳ：Base Transceiver Station）２，複数の無線ネットワーク制御装置（ＲＮＣ： Radio Network Controller）３，マルチメディア信号処理装置（ＭＰＥ：Multimedia signal Processing Equipment）４，移動マルチメディア交換システム（ＭＭＳ：Mobile Multimedia switching System）５，オペレーションシステム（ＯＰＳ：Operation System）６などをそなえて構成されている。
【００１８】
ここで、まず、上記のＭＳ１は、いわゆる携帯電話やＰＨＳ（Personal Handy-phone System）端末、これらを利用してデータ通信を行ないうるＰＤＡ（Personal Digital Assistance）やノート型のパーソナルコンピュータなどを含む携帯情報端末である。なお、この図１では、ＭＳ１を１台しか図示していないが、勿論、複数台存在していてもよい。
【００１９】
次に、ＢＴＳ２は、それぞれ、自身が形成する無線通信範囲（在圏ゾーン）内のＭＳ１と無線通信を行なって、ＭＳ１との間で各種通信サービス種別（プロトコル種別）に応じた呼（データ）の送受を行なうためのものである。ここで、上記の通信サービス種別（以下、単に「サービス種別」といったり「プロトコル属性」といったりすることがある）としては、例えば、次のような各種サービスが挙げられる。
【００２０】
▲１▼一般の音声通話サービス
▲２▼パケット通信サービス
▲３▼ＩＳＤＮ（Integrated Services Digital Ne twork）利用の通信サービス
▲４▼ＰＨＳを利用してインターネットにアクセスする場合のＰＩＡＦＳ（PHS Internet Access Forum Standard）準拠のデータ通信サービス
▲５▼ポイントツーポイントプロトコル（ＰＰＰ）準拠のデータ通信サービス〔ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）通信〕
▲６▼ファクシミリ（ＦＡＸ）通信サービス
▲７▼モデム（ＭＯＤＥＭ）利用のデータ通信サービス
なお、以下において、上記の音声通話サービスを「音声」、パケット通信サービスを「パケット」、ＩＳＤＮ利用の通信サービスを「ＩＳＤＮ」、ＰＩＡＦＳ準拠のデータ通信サービスを「ＰＩＡＦＳ」、ＰＰＰ準拠のデータ通信サービスを「ＰＰＰ」、ＦＡＸ通信サービスを「ＦＡＸ」、モデム利用のデータ通信サービスを「モデム」などと略記することがある。
【００２１】
次に、上記のＲＮＣ３は、複数のＢＴＳ２を収容して、ＭＭＳ５から配信（交換）されてくる呼を着信対象のＭＳ１が存在する在圏ゾーン担当のＢＴＳ２に着信させたり、ＢＴＳ２からの呼を多重してＭＭＳ５へ送信したりといった、各種無線通信制御を実施するためのものである。
さらに、上記のＭＰＥ４は、ＲＮＣ３に接続されて、ＲＮＣ３で受信される信号（データ）のサービス種別に応じたプロトコル変換などの各種信号処理を行なうためのもので、例えば図２に示すように、ＲＮＣ３をＡＴＭ（Asynchronous Transfer Mode）網７ａ経由で収容する場合には、ＡＴＭ交換機として構成される。なお、その詳細については後述する。
【００２２】
また、ＭＭＳ５は、ゲートウェイ局（図示省略）などを介して図２３により前述した集中局１３０や中心局１２０，総括局１１０などに接続されることによって、公衆網１００と接続されて、公衆網１００とＲＮＣ３やＭＰＥ４との間の呼の交換処理を行なうためのものである。つまり、本ＭＭＳ５は、ＭＰＥ４に対して呼接続／解放などのサービス要求（信号処理要求）を行なう上位ノードとして位置付けられる。なお、上記のサービス要求には、呼のサービス種別を識別するための情報が含まれているものとする。
【００２３】
さらに、ＯＰＳ６は、ＬＡＮ（Local Area Network）７ｂなどの所要の回線網を介してＭＰＥ４と接続されて、ＭＰＥ４の保守や運用管理を行なうためのもので、例えば図３に示すように保守コンソールなどとして構成され、この保守コンソール６からＭＰＥ４の動作設定などの各種設定を適宜に行なえるようになっている。
【００２４】
そして、上記のＭＰＥ４は、上述したごとくＡＴＭ交換機として構成される場合には、例えば図２に示すように、ＡＴＭスイッチ４１，ＡＴＭインタフェース（ＡＴＭ−ＩＦ）４２，ＬＡＮインタフェース（ＬＡＮ−ＩＦ）４３，複数のサービスプロトコルユニット（ＳＰＵ）４４−１〜４４−Ｎ（Ｎは自然数），主制御部４５などをそなえて構成される。
【００２５】
ここで、ＡＴＭスイッチ４１は、ＡＴＭ網７ａやＬＡＮ７ｂとの間で送受される呼をＡＴＭセルベースで交換（スイッチング）するためのもので、周知のように、受信ＡＴＭセルのヘッダ部分に設定されている宛先情報〔ＶＰＩ（Virtual Path Identifier）／ＶＣＩ（Virtual Channel Identifier）〕に基づく装置内経路識別情報（タグ情報）の設定が主制御部４２から与えられることにより、上記宛先情報に応じた経路のコネクションが確立されてＡＴＭセルの転送（ＡＴＭ通信）が行なわれるようになっている。
【００２６】
また、ＡＴＭインタフェース４２は、ＡＴＭ網７ａとの間のインタフェースをとるためのものであり、ＬＡＮインタフェース４３は、ＬＡＮ７ｂとのインタフェースをとるためのもので、ＬＡＮ７ｂからの信号をＡＴＭセルに変換したり、ＡＴＭスイッチ４１でスイッチングされてきたＡＴＭセルをＬＡＮ７ｂへの信号に変換したりする機能を有している。
【００２７】
さらに、各ＳＰＵ（パッケージ）４４−ｉは、それぞれ、呼のサービス種別に応じたプロトコル終端処理を実施するためのもので、本実施形態では、１つのＳＰＵ４４−ｉで前述したような複数種類のサービス種別に応じた（適した）属性（信号処理モード）での動作が可能になっている。なお、その詳細については図７及び図８により後述する。
【００２８】
そして、主制御部４５は、本ＡＴＭ交換機４の動作（コネクションの確立／解放処理など）を統括的に制御するためのものであるが、本実施形態では、ＳＰＵ４４−ｉ（ただし、ｉ＝１〜Ｎ）をはじめとするＡＴＭ交換機４内のリソース（ＡＴＭスイッチ４１や帯域なども含まれる）を管理して、上位ノード５からのサービス要求（呼接続要求や呼解放要求などの信号処理要求）に応じて必要なリソース（ＳＰＵ４４−ｉを含む）を捕捉したり解放したりする基本的な機能を有するほか、上位ノード５からのサービス要求毎に、あるいは、保守コンソール６からの指示（外部設定）に応じて、上記のＳＰＵ４４−ｉの属性（信号処理モード）を適宜に変更することで、ＳＰＵ４４−ｉのサービス種別毎の割り当て数を適宜に変更しうる機能も有している。
【００２９】
このため、本主制御部４５には、その要部に着目すると、例えば図３に示すように、呼制御部４５ａ，サービス決定部４５ｂ及びＳＰＵ状態管理部４５ｃがそなえられている。なお、この図３において、図２に示すＡＴＭスイッチ４１やＡＴＭインタフェース４２，ＬＡＮインタフェース４３などの図示は省略している。
【００３０】
ここで、上記の呼制御部４５ａは、上述したコネクションの確立／解放（リソースの捕捉／解放）処理などを中心的に制御するためのものであり、サービス決定部（通信サービス種別識別手段）４５ｂは、上位ノード５から通知されるサービス要求に含まれるサービス種別を識別するための情報に基づいて処理対象呼のサービス種別を判別（識別）するためのもので、その識別結果は、その呼の信号処理に必要な（要求サービスプロトコル属性が一致する）ＳＰＵ４４−ｉの捕捉要求（以下、ＳＰＵ捕捉要求という）として呼制御部４５ａを通じてＳＰＵ状態管理部４５ｃに通知されるようになっている。
【００３１】
そして、ＳＰＵ状態管理部（モード制御手段）４５ｃは、ＳＰＵ４４−ｉの実装数や各ＳＰＵ４４−ｉの稼働状態（空き状態，属性）などを管理するとともに、呼制御部４５ａと協動して、保守コンソール６からの指示（ＳＰＵ属性変更指示）や呼制御部４５ａからの上記ＳＰＵ捕捉要求に応じて、ＳＰＵ４４−ｉの属性（信号処理モード）を要求サービス種別に適した属性に制御（変更）する機能を有するもので、このために、例えば、ＳＰＵ状態管理受付部４５ｄとＳＰＵサービス変更部４５ｅとをそなえて構成されている。
【００３２】
即ち、ＳＰＵ状態管理受付部４５ｄは、例えば図５（Ａ）に示すように、各ＳＰＵ４４−ｉ毎に割り振られた論理番号（以下、ＳＰＵ論理番号という）毎に、それぞれ、下記▲１▼〜▲４▼に示すデータを含むＳＰＵ状態管理データ４５１を管理することで、各ＳＰＵ４４−ｉのそれぞれの稼働状態をリアルタイムに管理するためのものである。
【００３３】
▲１▼ＳＰＵ状態データ４５１ａ：ＳＰＵ４４−ｉの空き／使用中を表わすためのデータで、例えば、“０”で「空き」状態、“１”で「使用中」状態を表わす。なお、ＳＰＵ４４−ｉは、通常、１枚で複数チャンネル分の呼を処理できる能力を有しているが、本実施形態では、説明の便宜上、１枚のＳＰＵ４４−ｉで１チャンネル分の呼を処理できるものとし、ＳＰＵ４４−ｉの「空き」とは、呼処理を行なっていない待機状態の場合を意味するものとする。
【００３４】
▲２▼外部指定属性種別データ４５１ｂ：ＳＰＵ４４−ｉが図５（Ｂ）により後述する時刻対応属性管理データ４５２によって指定された時刻対応のものか否かを表わすデータで、例えば、“０”で「時刻対応」、それ以外の値で「非時刻対応」を表わす。
▲３▼外部指定属性データ４５１ｃ：保守コンソール６からデフォルト属性（優先属性）として指定されたＳＰＵ４４−ｉの属性（サービス種別）を表わすデータで、例えば、“０”で「指定無し」、“０”以外で「指定有り」を表わす。一例として、“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対応」、“５”で「ＦＡＸ対応」、“６”で「モデム対応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。
【００３５】
▲４▼カレント属性データ４５１ｄ：現在のＳＰＵ４４−ｉの属性を表わすデータで、上記の外部指定属性データ４５１ｃと同様に、“０”で「指定無し」、“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対応」、“５”で「ＦＡＸ対応」、“６”で「モデム対応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。このカレント属性データ４５１ｄの値と上記の外部指定属性データ４５１ｃの値とが異なる場合には、後述するように、後者の外部指定属性データ４５１ｃが優先され、前者のカレント属性データ４５１ｄが外部指定属性データ４５１ｃと一致するよう更新される。
【００３６】
なお、上記のＳＰＵ状態データ４５１ａ以外のデータ４５１ｂ〜４５１ｄについては、保守コンソール６からＳＰＵ属性変更指示（モード設定指示）をＳＰＵ状態管理受付部４５ｄに対して与えることで適宜に変更することが可能である。また、上記のＳＰＵ状態管理データ４５１は、図示しないメモリなどの記憶装置に記憶されて管理されているものとする。
【００３７】
一方、ＳＰＵサービス変更部４５ｅは、保守コンソール６からの指示（ＳＰＵ属性変更指示）や呼制御部４５ａからのＳＰＵ捕捉要求〔サービス決定部４５ｂでのサービス種別（要求プロトコル）の識別結果〕に基づき、ＳＰＵ属性変更が必要な場合にはＳＰＵ属性変更依頼（要求）を、呼制御部４５ａを通じ該当ＳＰＵ４４−ｉに与えるためのもので、これにより、該当ＳＰＵ４４−ｉは、要求された属性のＳＰＵ４４−ｉとして設定されて運用されることになる。
【００３８】
なお、この属性変更指示が実施された場合は、該当ＳＰＵ４４−ｉに対応するＳＰＵ状態管理データ４５１（カレント属性データ４５１ｄ）が更新される。
つまり、これらのＳＰＵ状態管理受付部４５ｄとＳＰＵサービス変更部４５ｅは、外部装置（他制御部）としての保守コンソール６からのＳＰＵ属性変更指示（モード設定指示）に応じてＳＰＵ４４−ｉの属性（信号処理モード）を制御する外部指示型モード制御部としての機能も果たしていることになる。
【００３９】
ところで、上記のＳＰＵサービス変更部４５ｅは、図４に示すように、上述したような基本機能に加えて、例えば図６に示すような形式で、過去に行なったＳＰＵ４４−ｉに対する属性変更指示（モード制御）についての統計情報（履歴情報）４５３、つまり、前記のカレント属性データ４５１ｄの更新履歴をとることにより、いつ、どのＳＰＵ４４−ｉがどの属性で動作していたかを管理する履歴情報管理部５２としての機能も有している。
【００４０】
この履歴情報管理部５２をそなえることで、例えば、どのサービス種別の呼（トラフィック）がどの日付や曜日，時間帯で集中しやすいかを分析・把握することができるようになるので、ＳＰＵ状態変更部４５ｃは、その分析結果に応じて、特定時刻に特定のサービス種別対応のＳＰＵ割り当て数を予め多めに設定したり少なめに設定したりすることができる。
【００４１】
例えば図６では、一般企業の業務時間外などでは音声やＩＳＤＮのトラフィックが比較的少ないと判断できるので、その時間帯では音声対応（属性＝“１”）やＩＳＤＮ対応（属性＝“２”）のＳＰＵ割り当て数を少なめに設定したり、逆に、業務開始時や昼休み終了時などトラフィックが急激に増加しやすい時間帯ではこれらのＳＰＵ割り当て数を予め多めに設定しておくようにすることができる。
【００４２】
なお、この図６に示す例は、ＳＰＵ４４−ｉの実装数（Ｎ）が３２枚（論理番号＝１〜３２；ただし、論理番号３１，３２のＳＰＵ４４−３１，４４−３２は予備）の場合で、図２２（Ａ）により後述するように、「音声」，「ＩＳＤＮ」，「パケット」，「ＰＩＡＦＳ」，「ＦＡＸ」，「モデム」，「ＰＰＰ」の各サービス種別対応のＳＰＵ４４−ｉの初期割り当て数を最小限（それぞれ１枚）にした状態を表わす。
【００４３】
そして、このような時刻要因による設定は、本実施形態では、図４に示すように、ＳＰＵサービス変更部４５ｅに、図５（Ｂ）に示すようなＳＰＵ４４−ｉ毎に管理される時刻対応属性管理データ４５２に基づいて該当ＳＰＵ４４−ｉに対して属性変更指示を与える時刻要因属性変更部５３をそなえることで実現される。
【００４４】
即ち、時刻要因属性変更部５３は、図５（Ｂ）に示すように、ＳＰＵ論理番号毎に、或る指定時刻（時間帯）にＳＰＵ４４−ｉのどの属性に設定するかを表わすデータ（指定時刻データ４５２ａと指定時刻対応属性データ４５２ｂとの組）を最大でｎ（ｎは自然数）組分、時刻対応属性管理データ４５２として管理しておき、この時刻対応属性管理データ４５２を、常時、或いは、定期的に参照することで、該当ＳＰＵ４４−ｉの属性を指定時刻に指定された属性に自動変更（設定）することができるのである。
【００４５】
つまり、上記の履歴情報管理部５２と時刻要因属性変更部５３は、上記の履歴情報４５３に基づいてＳＰＵ４４−ｉの属性を予測制御する予測型モード制御部として機能し、時刻要因属性変更部５３は、上記の履歴情報４５３に基づいた時刻対応属性管理データ４５２に基づいて、指定時刻にＳＰＵ４４−ｉの属性を指定された属性に制御する時刻要因モード制御部として機能するのである。
【００４６】
なお、上記の指定時刻対応属性データ４５２ｂには、図５（Ａ）により前述した外部指定属性データ４５１ｃやカレント属性データ４５１ｄと同様に定義された値が設定される。即ち、“０”で「指定無し」、“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対応」、“５”で「ＦＡＸ対応」、“６”で「モデム対応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。
【００４７】
また、上記の時刻対応属性管理データ４５２や履歴情報４５３についても、図示しないメモリなどの記憶装置にて保持されて管理されているものとする。さらに、上記の指定時刻データ４５２ａ（時間帯）は、開始時刻と終了時刻とで規定してもよいし、開始時刻とその後の継続時間とで規定してもよい。また、上記の時刻対応属性管理データ４５２は、時刻要因属性変更部５３が上記の履歴情報４５３（図６参照）に基づいて自動作成してもよいし、後述するように保守コンソール６から個別に設定してもよい。
【００４８】
次に、上記の各ＳＰＵ４４−ｉの構成について説明する。
図７は上記の各ＳＰＵ４４−ｉの詳細構成を示すブロック図で、この図７に示すように、各ＳＰＵ４４−ｉは、それぞれ、通信系インタフェース（ＩＦ）回路６１，制御系インタフェース（ＩＦ）回路６２，通信用デュアルポートＲＡＭ（ＤＰＲＡＭ）６３，セル組立分解（ＳＡＲ：Structure And Restructure）部６４，ＣＰＵ６５，フラッシュメモリ６６，ＲＡＭ６７，ＤＳＰ（Digital Signal Processor）モジュール６８−１〜６８−ｍ（ｍは自然数），ＩＰＬ（Initial Program Load）メモリ（ＲＡＭ）６９及びプログラムメモリ（ＲＡＭ）７０などをそなえて構成されている。
【００４９】
ここで、上記の通信系ＩＦ回路６１は、ＡＴＭセルの流れる通信系ネットワーク（セルバス）６０ｂとのインタフェースをとるためのものであり、制御系ＩＦ回路６２は、制御バスや監視用（ＳＶ：Supervision）バスなどから成る制御系ネットワーク６０ａとのインタフェースをとるためのものであり、通信用ＤＰＲＡＭ６３は、この制御系ＩＦ回路６２を介した制御系ネットワーク６０ａとの通信（制御バス経由）時に送受される制御メッセージを記憶するためのもので、この通信用ＤＰＲＡＭ６３にＣＰＵ６５がアクセスすることによりその制御メッセージに応じた制御を行なえるようになっている。
【００５０】
また、ＳＡＲ部６４は、ＡＴＭセルの組立（ヘッダ付加）／分解（ヘッダ除去）処理をおこなうためのもので、本ＳＡＲ部６４と各ＤＳＰモジュール６８−ｊ（ｊ＝１〜ｍ）との間では、ＡＴＭセルのヘッダを除くデータ部分のみが送受されるようになっている。
さらに、ＣＰＵ６５は、プログラムメモリ７０に保持されたＣＰＵ６５用のプログラム（ＣＰＵファームウェア）に従って動作することによりＳＰＵ４４−ｉの動作（マルチメディア信号処理）を統括的に制御するためのものであり、各ＤＳＰモジュール６８−ｊは、それぞれ、ＲＡＭ６７に保持されたＤＳＰ６８−ｊ用のプログラム（ＤＳＰファームウェア）を内部メモリ（図示省略）にロードすることにより、そのＤＳＰファームウェアに従って、ＳＡＲ部６４から受信されるセルデータ（マルチメディア信号）に対する信号処理（プロトコル変換など）を実施するためのものである。
【００５１】
ただし、本実施形態では、フラッシュメモリ６６内に各サービス種別に対応した複数種類のＣＰＵファームウェア及びＤＳＰファームウェアが通信サービス制御プログラムとして予めサービス種別毎に異なる領域に格納されており、上述したＳＰＵサービス変更部４５ｃからの属性変更指示に応じたファームウェア（格納領域）を選択してＲＡＭ６７に読み出して、ＣＰＵ６５とＤＳＰモジュール６８−ｊのいずれかとにそれぞれ必要なＣＰＵファームウェア及びＤＳＰファームウェアをロードさせることで、上述したごとく１つのＳＰＵ４４−ｉで複数種類のサービス種別に対応した信号処理を行なえるようになっている。
【００５２】
即ち、例えば図８に示すように、フラッシュメモリ６６には、少なくとも、ＩＰＬ領域６６１，ＣＰＵファームウェア領域６６２，ＤＳＰファームウェア領域６６３などが設けられており、ＣＰＵファームウェア領域６６２には、パケット（属性＝“３”），音声（属性“１”），ＩＳＤＮ（属性＝“２”），ＰＩＡＦＳ（属性＝“４”），ＰＰＰ（属性＝“７”），ＦＡＸ（属性＝“５”），モデム（属性＝“６”）などの各サービス種別対応のＣＰＵファームウェア（プログラム）６６２−１〜６６２−７が格納され、同様にして、ＤＳＰファームウェア領域６６３に、各サービス種別対応のＤＳＰファームウェア（プログラム）６６３−１〜６６３−７が格納されている。
【００５３】
なお、上記のＩＰＬ領域６６１には、ＳＰＵ起動時（電源投入時）などにおいてＣＰＵ６５が最初に読み込む（ＩＰＬメモリ６９に展開すべき）初期化プログラムが格納されている。また、各ファームウェア領域６６２，６６３には、それぞれ、ＳＰＵ４４−ｉが対応すべきサービス種別数が増えたときのための予備のファームウェア領域６６２−８，６６３−８も設けられている。
【００５４】
そして、前述したＳＰＵ状態管理部４５ｃ（ＳＰＵサービス変更部４５ｅ）からの属性変更指示（例えば、パケット対応のものへの属性変更指示）が上記の制御メッセージとして制御系ネットワーク６０ａを介して通信用ＤＰＲＡＭ６３に保持されると、ＣＰＵ６５は、上記の属性変更指示で指定されたサービス種別対応（図８ではパケット用）のＣＰＵファームウェア６６２−１及びＤＳＰファームウェア６６３−１をそれぞれ運用ファームウェアとしてプログラムメモリ７０及びＲＡＭ６７に読み出す（展開する）ことで、自身とＤＳＰモジュール６８−ｊのいずれかとに運用ファームウェアをそれぞれロードするのである。
【００５５】
つまり、上記のフラッシュメモリ６６は、複数種類の通信サービス種別に応じた複数種類の通信サービス制御プログラムを記憶した記憶部として機能し、ＣＰＵ６５は、前述したＳＰＵ状態管理部４５ｃからの属性変更指示に応じて対応する通信サービス制御プログラムをフラッシュメモリ６６から選択的にロードすることにより、自身の属性（信号処理モード）を制御するＳＰＵ属性変更部（モード選択制御部）として機能するようになっているのである。
【００５６】
このため、ＤＳＰモジュール６８−ｊの実装数（ｍ）は、前記のサービス種別数よりも少ない数でよく、未使用のＤＳＰモジュール６８−ｊは、障害発生などにより使用不能となったＤＳＰモジュール６８−ｊの予備として使用することができる。
以下、上述のごとく構成された本実施形態のＡＴＭ交換機（ＭＰＥ）４の動作について詳述する。
【００５７】
（１）ＳＰＵ属性設定手順（時刻要因／非時刻要因）の説明
まず、保守コンソール６からＳＰＵ４４−ｉの属性を設定（変更）する手順（非時刻要因）について説明する。
例えば図９に示すように、保守コンソール６から或るＳＰＵ４４−ｉに対するＳＰＵ属性変更指示（ＩＤ＝１）を処理要求として投入すると（ステップＡ１）、その処理要求（ＳＰＵ属性変更指示）は、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）にて受け付けられる。
【００５８】
すると、ＳＰＵ状態管理受付部４５ｄは、受信したＳＰＵ属性変更指示に従って、該当ＳＰＵ４４−ｉについてのＳＰＵ状態管理データ４５１を更新し、属性変更対象のＳＰＵ４４−ｉに対する属性変更依頼をＳＰＵサービス変更部４５ｅに対して行なう（ステップＡ２）。
具体的に、この場合、ＳＰＵ状態管理受付部４５ｄは、図１４に示すように、保守コンソール６から受信した処理要求内容が非時刻要因のＳＰＵ属性変更指示（ＩＤ＝１．２）であるので、ステップＳ１からステップＳ１０に分岐し、さらに、図１５に示すステップＳ１１からステップＳ１２に分岐して、図１６に示す処理手順（ステップＡ３）を実行する。
【００５９】
即ち、ＳＰＵ状態管理受付部４５ｄは、まず、ＳＰＵ状態管理データ４５１を参照し（ステップＳ１２１）、外部指定属性データ４５１ｃに“０”（＝「指定無し」）以外の値が設定されているか否かを確認する（ステップＳ１２２）。
この結果、“０”（＝「指定無し」）以外の値が設定されていれば（ステップＳ１２２でＹＥＳなら）、上記のＳＰＵ属性変更指示の優先度に従って外部指定属性データ４５１ｃをＳＰＵ属性変更指示によって指定されたサービス種別に応じた値に更新する。つまり、保守コンソール６からのＳＰＵ属性変更指示の優先度の方が高ければ外部指定属性データ４５１ｃの更新を行なう（ステップＳ１２３）。
【００６０】
一方、外部指定属性データ４５１ｃに“０”（＝「指定無し」）が設定されていた場合（ステップＳ１２２でＮＯの場合）は、ＳＰＵ状態管理受付部４５ｄは、新たに外部指定属性データ４５１ｃを指定されたサービス種別に応じた値に更新する（ステップＳ１２４）。
その後、ＳＰＵ状態管理受付部４５ｄは、ＳＰＵ状態データ４５１ａを参照して属性変更対象のＳＰＵ４４−ｉが空き状態か使用中かを確認し（ステップＳ１２５）、空き状態（属性変更可能な状態）であれば、ＳＰＵサービス変更部４５ｅにそのＳＰＵ４４−ｉの属性変更を依頼する。
【００６１】
すると、ＳＰＵサービス変更部４５ｅは、依頼を受けたＳＰＵ４４−ｉに対してＳＰＵ属性変更指示を与える（ステップＳ１２５のＹＥＳルートからステップＳ１２６：図９のステップＡ４）。
なお、属性変更対象のＳＰＵ４４−ｉが使用中であった場合は、外部指定属性データ４５１ｃを更新したことを要因として、図１９及び図２０により後述するように、ＳＰＵ４４−ｉを使用している呼の解放処理中に属性変更が実施されるので、この場合、ＳＰＵサービス変更部４５ｅは、使用中ＳＰＵ４４−ｉに対するＳＰＵ属性変更指示は出力しない（ステップＳ１２５のＮＯルート）。
【００６２】
さて、次に、図１０に示すように、上述のごとくＳＰＵサービス変更部４５ｅからＳＰＵ属性変更指示を起動（ステップＢ０）後に受けた（ステップＢ１）ＳＰＵ４４−ｉでは、ＣＰＵ６５が、図８により前述したように、要求されたサービス種別（プロトコル）対応のＣＰＵファームウェア６６２−ｋ（ｋ＝１〜７）をフラッシュメモリ６６のＣＰＵファームウェア領域６６２から読み出してプログラムメモリ７０に書き込むことで、要求サービス種別対応のＣＰＵファームウェア６６２−ｋをＣＰＵ６５に対してロードする（ステップＢ２）。
【００６３】
同様に、ＣＰＵ６５は、要求サービス種別対応のＤＳＰファームウェア６６３−ｋをフラッシュメモリ６６のＤＳＰファームウェア領域６６３から読み出してＤＳＰモジュール６８−ｊのいずれかの内部メモリに書き込むことで、ＤＳＰファームウェアのロードを実行する（ステップＢ３；図９のステップＡ５）。以上の処理が完了すると、ＳＰＵ４４−ｉが運用可能状態となり、ＣＰＵ６５は、その旨を、制御系ネットワーク６０ａを介してＳＰＵ状態管理部４５ｃに通知する（ステップＢ４）。
【００６４】
すると、ＳＰＵ状態管理部４５ｃは、図９に示すように、保守コンソール６に対して、ＳＰＵ属性変更完了通知を行なう（ステップＡ６）。以上のような処理を属性変更対象のＳＰＵ４４−ｉ分だけ繰り返すことで、任意のＳＰＵ４４−ｉを所望のサービス種別対応のＳＰＵ４４−ｉとして設定して、サービス種別毎のＳＰＵ割り当て数を設定・変更することが可能になる。
【００６５】
なお、上記の例では、保守コンソール６からＳＰＵ属性変更指示を、属性変更対象のＳＰＵ数分だけ繰り返すことを前提としているが、ＳＰＵ属性変更指示に複数分のＳＰＵ属性変更のための情報を設定することで、保守コンソール６からの１回のＳＰＵ属性変更指示の投入で、複数のＳＰＵ４４−ｉの属性を変更できるようにしてもよい。
【００６６】
次に、保守コンソール６から時刻要因によるＳＰＵ属性変更を設定する場合の動作について説明する。
まず、図１１に示すように、保守コンソール６から或るＳＰＵ４４−ｉに対する時刻要因のＳＰＵ属性変更指示（ＩＤ＝１．１）を処理要求として投入すると（ステップＣ１）、その処理要求（ＳＰＵ属性変更指示）は、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）にて受け付けられる。
【００６７】
すると、ＳＰＵ状態管理受付部４５ｄは、受信したＳＰＵ属性変更指示に従って、該当ＳＰＵ４４−ｉについてのＳＰＵ状態管理データ４５１を更新する（ステップＣ２）。
具体的に、この場合、ＳＰＵ状態管理受付部４５ｄは、図１４に示すように、保守コンソール６から受信した処理要求内容が時刻要因のＳＰＵ属性変更指示（ＩＤ＝１．１）であるので、ステップＳ１からステップＳ１０に分岐し、さらに、図１５に示すステップＳ１１からステップＳ１３に分岐して、図１７に示す処理手順（ステップＣ３）を実行する。
【００６８】
即ち、ＳＰＵ状態管理受付部４５ｄは、まず、ＳＰＵ状態管理データ４５１を参照し（ステップＳ１３１）、外部指定属性データ４５１ｃに“０”（＝「指定無し」）以外の値が設定されているか否かを確認する（ステップＳ１３２）。
この結果、“０”（＝「指定無し」）以外の値が設定されていれば、上記のＳＰＵ属性変更指示の優先度に従って外部指定属性種別データ４５１ｂを「時刻対応」（＝“０”）に設定（更新）する。即ち、保守コンソール６から投入されたＳＰＵ属性変更指示の優先度の方が高ければ外部指定属性データ４５１ｂの設定（更新）を行なう（ステップＳ１３２のＹＥＳルートからステップＳ１３３）。
【００６９】
一方、外部指定属性データ４５１ｃに“０”（＝「指定無し」）が設定されていた場合は、ＳＰＵ状態管理受付部４５ｄは、外部指定属性種別データ４５１ｂに「時刻対応」（＝“０”）を設定する（ステップＳ１３２のＮＯルートからステップＳ１３４）。
その後、ＳＰＵ状態管理受付部４５ｄは、属性変更対象のＳＰＵ４４−ｉに対応する時刻対応属性管理データ４５２を参照し（ステップＳ１３５）、指定時刻データ４５２ａと時刻対応属性データ４５２ｂとを設定したのち（ステップＳ１３６）、保守コンソール６へＳＰＵ４４−ｉの属性変更（設定）が完了した旨を通知する（ステップＳ１３７；図１１のステップＣ４）。
【００７０】
以上により、時刻要因によるＳＰＵ４４−ｉの属性変更（設定）が完了し、以後、指定時刻になると、該当ＳＰＵ４４−ｉが空き状態で、且つ、カレント属性（データ４５１ｄ）と外部指定属性（データ４５１ｃ）とが一致していなければ、自動的に、ＳＰＵ属性サービス変更部４５ｅから該当ＳＰＵ４４−ｉに対して（空き状態であれば）ＳＰＵ属性変更指示が与えられて、ＳＰＵ４４−ｉの属性が変更される。これにより、指定時刻には必要な分のサービス種別対応のＳＰＵ４４−ｉが事前に確保されることになる。
【００７１】
つまり、この場合、ＳＰＵ状態管理部４５ｃは、トラフィックの増大が予想される時間帯において呼毎にいちいちＳＰＵ属性変更処理を実行する必要がなく、呼処理の高速化を図ることが可能である。
なお、上述した時刻要因によるＳＰＵ属性変更指示についても、属性設定対象分のＳＰＵ４４−ｉ毎に繰り返し行なってもよいし、１回のＳＰＵ属性変更（設定）指示で複数分のＳＰＵ４４−ｉの属性変更（設定）を行なうようにしてもよい。
【００７２】
（２）運用中（呼毎）のＳＰＵ属性自動設定処理の説明
次に、以下では、サービス運用中のＡＴＭ交換機４の動作について説明する。まず、図１２に示すように、上位ノード５から或る呼についてのサービス要求（呼接続要求）が主制御部４５（呼制御部４５ａ）にて受信されると（ステップＤ１）、呼制御部４５ａが、その呼についての変換対象プロトコルの決定要求メッセージをサービス決定部４５ｂに出力する（ステップＤ２）。なお、上記のメッセージには、サービス種別を識別するための情報が含まれているものとする。
【００７３】
すると、サービス決定部４５ｂは、受信したメッセージに基づいて要求されたサービス種別（プロトコル）を識別し（ステップＤ３）、呼制御部４５ａに対してそのサービス種別に応じたＳＰＵ４４−ｉの捕捉要求を行ない（ステップＤ４）、この捕捉要求を受けた呼制御部４５ａは、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）に対して同様のＳＰＵ捕捉要求（ＩＤ＝２）を行なう（ステップＤ５）。
【００７４】
すると、ＳＰＵ状態管理受付部４５ｄは、受信した要求がＳＰＵ捕捉要求（ＩＤ＝２）なので、図１４に示すステップＳ１からステップＳ２０へ分岐して、図１８に示す処理手順（ＳＰＵ検索処理）を実行する（ステップＤ６）。
即ち、ＳＰＵ状態管理受付部４５ｄは、ＳＰＵ状態管理データ４５１をＳＰＵ論理番号＝“１”のＳＰＵ４４−ｉに対応するものから順番に参照して、要求サービス種別対応のＳＰＵ４４−ｉを検索する。なお、このとき、保守コンソール６から外部指定属性の設定が行なわれている場合は、外部指定属性データ４５１ｃに基づいて、そのＳＰＵ４４−ｉの属性が判断される。
【００７５】
具体的に、ＳＰＵ状態管理受付部４５ｄは、まず、ＳＰＵ状態管理データ４５１を参照して（ステップＳ２１）、参照中のＳＰＵ状態管理データ４５１が、ＳＰＵ論理番号が最終のデータか否かを確認する（ステップＳ２２）。
その結果、最終データでなければ、ＳＰＵ状態管理受付部４５ｄは、次に、ＳＰＵ状態データ４５１ａ〔図５（Ａ）参照〕を参照して、ＳＰＵ４４−ｉが空き状態であるか使用中であるかを確認し（ステップＳ２２のＮＯルートからステップＳ２３）、空き状態であれば、さらに、外部指定属性種別データ４５１ｂを参照して、外部指定属性種別データ４５１ｂとして「時刻対応」（＝“０”）が設定されているかを確認する（ステップＳ２３のＹＥＳルートからステップＳ２４）。
【００７６】
この結果、外部指定属性種別データ４５１ｂとして「時刻対応」（＝“０”）以外が設定されていれば、ＳＰＵ状態管理受付部４５ｄは、次に、外部指定属性データ４５１ｃを参照して、既に外部指定属性データ４５１ｃとして「外部指定済み」が設定されているか否かを確認する（ステップＳ２４のＮＯルートからステップＳ２５）。
【００７７】
その結果、「外部指定済み」であれば、ＳＰＵ状態管理受付部４５ｄは、さらに、要求サービス種別と外部指定属性データ４５１ｃとが一致しているか否かを確認し（ステップＳ２５のＹＥＳルートからステップＳ２６）、一致していれば、ＳＰＵ状態データ４５１ａを「使用中」（＝“１”）に更新する（ステップＳ２６のＹＥＳルートからステップＳ２７）。
【００７８】
次いで、ＳＰＵ状態管理受付部４５ｄは、外部指定属性データ４５１ｃとカレント属性データ４５１ｄとを参照して、外部指定属性とカレント属性とが一致しているか否かを確認し（ステップＳ２８）、一致していれば、外部指定属性指定済みで要求サービス種別と一致する空き状態のＳＰＵ４４−ｉが見つかったことになるので、そのＳＰＵ４４−ｉを上位ノード５からの上記呼接続要求に対する割り当て対象のＳＰＵ４４−ｉとして捕捉し、その旨を呼制御部４５ａに通知して処理を呼制御部４５ａに移行する（ステップＳ２８のＹＥＳルートからステップＳ２９；図１２のステップＤ９）。
【００７９】
即ち、呼制御部４５ａは、図１２に示すように、ＳＰＵ状態管理部４５ｃから上記の通知を受けると、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要求元の上位ノード５との間のスイッチング設定（コネクション設定）を行なって（ステップＤ１０）、呼の接続を行なったのち、呼の接続完了の旨を上位ノード５に通知する（ステップＤ１１）。
【００８０】
なお、上記のステップＳ２３においてＳＰＵ状態が空き状態でなかった場合（ステップＳ２３でＮＯと判定された場合）や、上記のステップＳ２６において要求サービス種別と外部指定属性とが一致しなかった場合（ステップＳ２６でＮＯと判定された場合）には、次のＳＰＵ論理番号のＳＰＵ状態管理データ４５１について上記ステップＳ２２からの処理が実行される。
【００８１】
ところで、上記のステップＳ２５において、外部指定属性データ４５１ｃに「指定無し」（＝“０”）が設定されていた場合（ステップＳ２５でＮＯと判定された場合）、ＳＰＵ状態管理受付部４５ｄは、次に、図１８に示すように、カレント属性データ４５１ｄを参照して、カレント属性と要求サービス種別とが一致しているかを確認する（ステップＳ３０）。
【００８２】
この結果、カレント属性と要求サービス種別とが一致していれば（ステップＳ３０でＹＥＳと判定されれば）、外部指定属性未指定（外部指定無し）でカレント属性が要求サービス種別と一致する空きＳＰＵ４４−ｉが見つかったことになるので、ＳＰＵ状態管理受付部４５ｄは、該当ＳＰＵ状態データ４５１ａを「使用中」（＝“１”）に更新して（ステップＳ３１）、そのＳＰＵ４４−ｉを上記呼接続要求に対する割り当て対象のＳＰＵ４４−ｉとして捕捉し、その旨を呼制御部４５ａに通知して処理を呼制御部４５ａに移行する（ステップＳ２９）。
【００８３】
そして、呼制御部４５ａは、この場合も、ＳＰＵ状態管理部４５ｃから上記の通知を受けると、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要求元の上位ノード５との間のスイッチング設定（コネクション設定）を行なって（ステップＤ１０）、呼の接続を行なったのち、呼の接続完了の旨を上位ノード５に通知する（ステップＤ１１）。
【００８４】
次に、上記のステップＳ２８においてＳＰＵ４４−ｉの外部指定属性とカレント属性とが一致しない場合（ステップＳ２８でＮＯと判定された場合）や、上記のステップＳ３０において要求サービス種別とＳＰＵ４４−ｉのカレント属性とが一致しない場合（ステップＳ３０でＮＯと判定された場合）、ＳＰＵ状態管理受付部４５ｄは、図２０に示すように、カレント属性データ４５１ｄを更新してその不一致を解消し（ステップＳ３２）、ＳＰＵ属性サービス変更部４５ｅに該当ＳＰＵ４４−ｉの属性変更を依頼する。
【００８５】
すると、ＳＰＵ属性変更部４５ｅは、該当ＳＰＵ４４−ｉに対して属性変更要求（要求サービス種別を含む）を行なう（ステップＳ３３；図１２のステップＤ７）。これにより、当該ＳＰＵ４４−ｉは、図１０により前述したように、フラッシュメモリ６６から要求サービス種別に対応するＣＰＵファームウェア６６２−ｋとＤＳＰファームウェア６６３−ｋとをそれぞれ読み出してロードすることにより、自身の属性を要求されたサービス種別対応（プロトコル属性）に変更する（図１２のステップＤ８）。
【００８６】
これにより、上述のごとく属性変更のなされたＳＰＵ４４−ｉが上記の呼接続要求に対する割り当てＳＰＵ４４−ｉとして捕捉されて、呼制御部４５ａに処理が移行する（ステップＳ３４）。即ち、呼制御部４５ａは、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要求元の上位ノード５との間のスイッチング設定（コネクション設定）を行なって（図１２のステップＤ１０）、呼の接続を行なったのち、呼の接続完了の旨を上位ノード５に通知する（図１２のステップＤ１１）。
【００８７】
ところで、前記のステップＳ２４（図１８参照）において外部指定属性種別データ４５１ｂとして「時刻対応」（＝“０”）が設定されていた場合（ステップＳ２４でＹＥＳと判定された場合）は、図２１に示すように、時刻要因属性変更部５２が、それまで参照していたＳＰＵ状態管理データ４５１のＳＰＵ論理番号をキーにして対応する時刻対応属性管理データ４５２を検索する（ステップＳ３５）。
【００８８】
そして、時刻対応属性管理データ４５２の中に現時刻の含まれる時間帯が指定時刻データ４５２ａによって設定されていれば、時刻要因属性変更部５２は、その指定時刻データ４５２ａに対応する時刻対応属性データ４５２ｂを参照して、要求サービス種別と時刻対応属性とが一致しているか否かを確認する（ステップＳ３６）。
【００８９】
この結果、要求サービス種別と時刻対応属性とが一致していれば（ステップＳ３６でＹＥＳと判定されれば）、時刻対応属性指定済みで要求サービス種別と一致する空き状態のＳＰＵ４４−ｉが見つかったことになるので、時刻要因属性変更部５２は、そのＳＰＵ４４−ｉに対応するＳＰＵ状態管理データ４５１のＳＰＵ状態データ４５１ａを使用中（＝“１”）に更新する（ステップＳ３７）。
【００９０】
次に、時刻要因属性変更部５２は、外部指定属性データ４５１ｃとカレント属性データ４５１ｄとを比較して、ＳＰＵ４４−ｉの外部指定属性とカレント属性とが一致しているか否かを確認し（ステップＳ３８）、一致していれば（ステップＳ３８でＹＥＳと判定されれば）、そのまま、対応するＳＰＵ４４−ｉを上記の呼接続要求に対する割り当てＳＰＵ４４−ｉとして捕捉して、処理を呼制御部４５ａに移行する（ステップＳ３９；図１２のステップＤ９〜Ｄ１１）。
【００９１】
一方、ＳＰＵ４４−ｉの外部指定属性とカレント属性とが一致していなければ（ステップＳ３８でＮＯと判定されれば）、図２０により前述したように、カレント属性が外部指定属性と一致するよう更新され、ＳＰＵサービス変更部４５ｅによって、該当ＳＰＵ４４−ｉの属性がカレント属性から外部指定属性に変更された上で、呼制御部４５ａに処理が移行する（ステップＳ３２〜Ｓ３４）。
【００９２】
なお、上記のステップＳ３６において、要求サービス種別と時刻対応属性とが一致していなかった場合（ステップＳ３６でＮＯと判定された場合）は、次のＳＰＵ論理番号のＳＰＵ状態管理データ４５１について、図１８により前述したステップＳ２２以降の処理が実行される。
以上のようにして、上位ノード５からの呼接続要求毎に、要求サービス種別に一致する属性をもつＳＰＵ４４−ｉが空き状態で既に存在すれば、そのＳＰＵ４４−ｉが、順次、割り当てＳＰＵ４４−ｉとして捕捉され、要求サービス種別に一致する属性をもつ空きＳＰＵ４４−ｉが存在しなければ（要求サービス種別対応のＳＰＵ４４−ｉが不足していれば）、空き状態のＳＰＵ４４−ｉの属性が要求サービス種別対応の属性に変更されて、割り当てＳＰＵ４４−ｉとして捕捉されてゆく。
【００９３】
例えば図２２（Ａ）に示すように、初期設定として、「音声」，「ＩＳＤＮ」，「パケット」，「ＰＩＡＦＳ」，「ＦＡＸ」，「モデム」，「ＰＰＰ」の各サービス種別対応のＳＰＵ４４−ｉの割り当て数を最小限〔図２２（Ａ）ではそれぞれ１枚〕にした場合は、残り（外部指定無しのＳＰＵ４４−ｉ：ＳＰＵ論理番号＝８〜３０）の属性を上述のごとく運用中（呼毎）に適宜に変更してゆくことで、不足分のサービス種別対応のＳＰＵ４４−ｉを充足することができる。
【００９４】
また、例えば図２２（Ｂ）に示すように、初期設定として、上記の各サービス種別対応のＳＰＵ４４−ｉの割り当て数を予測されるサービス種別毎のトラフィックに応じた割合〔図２２（Ｂ）では音声用５枚、ＩＳＤＮ用５枚、パケット用５枚、ＰＩＡＦＳ用２枚、ＦＡＸ用２枚、モデム用２枚、ＰＰＰ用２枚〕に設定した場合も、外部指定無しのＳＰＵ４４−ｉ（ＳＰＵ論理番号＝２４〜３０）、あるいは、初期設定（外部指定）で他サービス種別対応に設定されているものでも空き状態であればそのＳＰＵ４４−ｉの属性を運用中に適宜に変更してゆくことで、不足分のサービス種別対応のＳＰＵ４４−ｉを充足することができる。
【００９５】
なお、上記の図２２（Ａ）及び図２２（Ｂ）では、ＳＰＵ数＝３２、つまり、Ｎ＝３２の場合を例にしている。また、これらの図２２（Ａ）及び図２２（Ｂ）において、ＳＰＵ論理番号＝３１，３２の２枚のＳＰＵ４４−ｉ（網掛け部参照）は予備用として実装されたＳＰＵ４４−ｉで、他のＳＰＵ４４−ｉと同一構成を有している。従って、例えば、障害発生などによりどのサービス種別対応のＳＰＵ４４−ｉが使用不能になっても、そのＳＰＵ４４−ｉの代わりとして使用することが可能である。
【００９６】
次に、上記の呼接続が切断（解放）される場合の処理について説明する。
まず、図１３に示すように、上位ノード５から呼解放要求が送信され呼制御部４５ａにて受信されると（ステップＥ１）、呼制御部４５ａは、まず、該当ＳＰＵ４４−ｉと呼接続要求元の上位ノード５とのコネクション設定を解放し（ステップＥ２）、解放呼のために捕捉されていたリソース（ＳＰＵ４４−ｉ）の解放要求（ＳＰＵ解放要求：ＩＤ＝３）をＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）に出力する（ステップＥ３）。
【００９７】
すると、ＳＰＵ状態管理受付部４５ｄは、受信した要求がＳＰＵ解放要求（ＩＤ＝３）なので、図１４に示すステップＳ１からステップＳ４０へ分岐して、図１９に示す処理手順（該当ＳＰＵ状態管理データ４５１の更新処理）を実行する（ステップＥ４）。
即ち、ＳＰＵ状態管理受付部４５ｄは、対象のＳＰＵ状態管理データ４５１を参照し（ステップＳ４１）、ＳＰＵ状態データ４５１ａを「空き」（＝“０”）に更新する（ステップＳ４２）。その後、ＳＰＵ状態管理受付部４５ｄは、同じＳＰＵ状態管理データ４５１の外部指定属性データ４５１ｃに「指定済み」（“０”以外の値）が設定されているか否かを確認する（ステップＳ４３）。
【００９８】
その結果、「指定無し」（＝“０”）が設定されていれば、ＳＰＵ解放処理が完了した旨を呼制御部４５ａに通知して（図１３のステップＥ７）、処理を呼制御部４５ａに移行する（ステップＳ４３のＮＯルートからステップＳ４５）。すると、呼制御部４５ａは、呼の解放が完了した旨を呼解放要求元の上位ノード５に通知して（図１３のステップＥ８）、呼解放処理を完了する。
【００９９】
一方、上記のステップＳ４３において外部指定属性データ４５１ｃに“０”以外の値が設定されて外部指定属性が「指定済み」になっていた場合、ＳＰＵ状態管理受付部４５ｄは、さらに、同じＳＰＵ状態管理データ４５１の外部指定属性データ４５１ｃとカレント属性データ４５１ｄとを参照して、外部指定属性とカレント属性とが一致しているか否かを確認する（ステップＳ４３のＹＥＳルートからステップＳ４４）。
【０１００】
この結果、外部指定属性とカレント属性とが一致していれば、外部指定属性が指定されていない場合（ステップＳ４３でＮＯと判定された場合）と同様にして、呼制御部４５ａに処理が移行し（ステップＳ４４のＹＥＳルートからステップＳ４５）、呼制御部４５ａから呼解放完了通知が上位ノード５に出力される（図１３のステップＥ７，Ｅ８）。
【０１０１】
一方、外部指定属性とカレント属性とが一致していなければ（ステップＳ４４でＮＯと判定された場合）、ＳＰＵ状態管理受付部４５ｄは、図２０により前述したステップＳ３２〜Ｓ３４の処理を実行することにより、カレント属性を更新して外部指定属性と一致させるとともに、ＳＰＵサービス変更部４５ｅによって、該当ＳＰＵ４４−ｉの属性を外部指定属性に変更（図１３のステップＥ５，Ｅ６）した上で、処理を呼制御部４５ａに移行する。即ち、呼制御部４５ａは、呼の解放が完了した旨を呼解放要求元の上位ノード５に通知して、呼解放処理を完了する（図１３のステップＥ７，Ｅ８）。
【０１０２】
このようにして、上位ノード５から呼の解放要求がある毎に、該当するＳＰＵ４４−ｉの捕捉が解放されるとともに、自動的に、その属性が、外部指定属性（デフォルト属性）の指定が有る場合にはその指定に応じた属性となり、外部指定属性の指定が無い場合には捕捉時の属性に維持される。
以上説明したように、本実施形態のＡＴＭ交換機（ＭＰＥ）４によれば、複数種類のサービス種別に対応した複数のプログラム（ＣＰＵファームウェア及びＤＳＰファームウェア）を１枚のパッケージに搭載したＳＰＵ４４−ｉに対して、上位ノード５が要求した、つまり、ユーザ（加入者）が指定したサービス種別対応のプログラムをＳＰＵ状態管理部４５ｃからの制御によってロードさせることで、呼毎に任意のＳＰＵ４４−ｉを要求サービス種別対応のものにフレキシブルに変更・捕捉することができる。
【０１０３】
従って、従来のようにサービス種別毎に専用のＳＰＵを実装する場合、即ち、サービス種別毎のＳＰＵ割り当て数が固定である場合に比して、大幅にＳＰＵ４４−ｉの必要実装数を削減することができて、ＡＴＭ交換機４の大幅な小型化を図ることが可能である。
また、ＡＴＭ交換機４の製造元（メーカ）にとっては、サービス種別毎に専用のＳＰＵを製造する必要がないので、多品種の製造及びメンテナンスから少品種の製造及びメンテナンスに移行することができ、コストダウン及び保守の品質向上を図ることができる。
【０１０４】
さらに、或るサービス種別対応のトラフィックが増加してそのサービス種別対応のＳＰＵ４４−ｉが不足するような場合でも、空きＳＰＵ４４−ｉを不足分のサービス種別対応のＳＰＵ４４−ｉとして使用することができる、つまり、実装されたＳＰＵ４４−ｉ全体でサービス種別に依存せずに全トラフィックを吸収することができるので、サービス種別毎に専用のＳＰＵを実装する場合に比して、トラフィックの許容量が大きくなり、呼損率を極めて低く抑えることができる。この結果、ユーザにとっては、接続性が大幅に向上することになる。
【０１０５】
また、ＡＴＭ交換機４の建局時におけるＳＰＵ実装数の算出根拠について、ＡＴＭ交換機４のトラフィック量を推定するだけでよく、通常、実施されている各サービス種別対応のＳＰＵ毎の周辺上位ノードからの要求トラフィック量の分析は不要となる。さらに、運用状態となった場合でも、各サービス毎のメンテナンスは不要となり、ピーク時のトラフィックに対するＳＰＵ４４−ｉの過不足の対応のみでよいことになる。
【０１０６】
また、時刻要因によるＳＰＵ属性変更指示により、指定時刻に、指定したサービス種別対応のＳＰＵ４４−ｉとして動作するようにＳＰＵ４４−ｉの属性変更を実施することができるので、時間毎に特定のサービス種別対応のＳＰＵ４４−ｉを事前に確保しておくことができる。
従って、例えば、一般企業の業務開始時や昼休み終了時，電話やインターネットでのチケット予約販売など、特定の日時に大量のトラフィックの発生が想定される特異なケースでも、ＳＰＵ実装数を従来よりも大幅に削減しながら、呼損率を最小限に抑制することができる。
【０１０７】
（３）その他
なお、上述した実施形態では、マルチメディア信号処理装置がＡＴＭ交換機として構成されている場合を例にしたが、本発明は、これに限定されず、他の種類の交換装置や呼処理装置として構成されていても、上述した実施形態と同様の作用効果が得られる。
【０１０８】
また、上述した実施形態では、保守コンソール６からＡＴＭ交換機４に対してＳＰＵ属性変更指示などの各種設定を行なっているが、勿論、他の任意の制御装置から行なうようにしてもよい。
さらに、上述した実施形態のＳＰＵ４４−ｉは、複数種類のサービス種別に応じた複数種類のプログラム（ファームウェア）を選択的にＣＰＵ６５及びＤＳＰモジュール６８−ｊにロードする構成を採ることで、複数種類のサービス種別対応のＳＰＵ４４−ｉを実現しているが、複数種類のサービス種別対応のＳＰＵ４４−ｉが実現できれば、必ずしもこのような構成を採る必要はない。
【０１０９】
例えば、予め複数種類のサービス種別に対応したＤＳＰモジュールを用意するなど、サービス種別に応じた複数の信号処理手段を用意しておき、要求サービス種別に応じてこれらの信号処理手段のいずれかを単純に選択するという構成を採っても良い。ただし、上述した実施形態の構成を採った方が、前述したように、実装すべきＤＳＰモジュール数をサービス種別数よりも少なくすることができるので有利である。
【０１１０】
また、上述した例では、便宜上、１枚のＳＰＵ４４−ｉが１チャンネル分の呼を処理できる構成になっていることを前提にして説明したが、１枚のＳＰＵ４４−ｉが複数チャンネル分の呼を処理できるだけの能力を有している場合には、次のようなアルゴリズムを追加することで対応可能である。
即ち、上位ノード５からの要求サービス種別と一致する属性のＳＰＵ４４−ｉを検索する際、まず、要求サービス種別と一致し呼処理能力に余裕のあるＳＰＵ４４−ｉを検索し、この条件を満足するＳＰＵ４４−ｉが存在すれば、そのＳＰＵ４４−ｉをサービス要求に対して割り当てるべきＳＰＵ４４−ｉとして捕捉する。一方、上記の条件を満足するＳＰＵ４４−ｉが存在しなければ、「空き状態」（呼が割り当てられていない待機状態）の他のＳＰＵ４４−ｉの属性を変更した上で、そのＳＰＵ４４−ｉサービス要求に対して割り当てるべきＳＰＵ４４−ｉとして捕捉する。
【０１１１】
このようなアルゴリズムにより、上位ノード５からのサービス要求毎に、要求サービス種別と一致し処理能力に余裕のあるＳＰＵ４４−ｉに、新たな呼が割り当てられてゆき、要求サービス種別と一致し処理能力に余裕のあるＳＰＵ４４−ｉが存在しなくなると、新たに要求サービス種別対応の空きＳＰＵ４４−ｉが捕捉されて呼が割り当てられてゆくことになる。
【０１１２】
そして、本発明は、上述した実施形態に限定されるものではなく、上記以外にも本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。
【０１１３】
【発明の効果】
以上詳述したように、本発明のマルチメディア信号処理装置によれば、通信サービスユニットの信号処理モードが、呼のサービス種別に適したモードに制御されるので、予めサービス種別毎に最大トラフィックをカバーできるだけの専用の通信サービスユニットを実装しておく必要がない。また、或るサービス種別のトラフィックに対して通信サービスユニットが不足した場合でも、他のサービス種別に適したモードで動作していた他の通信サービスユニットのモードを不足の生じたサービス種別対応のモードに変更することで、不足分を充足することができる。従って、次のような利点（１）〜（４）が得られる。
【０１１４】
（１）サービス種別毎に専用の通信サービスユニットを実装する場合、即ち、サービス種別毎の通信サービスユニット割り当て数が固定である場合に比して、通信サービスユニットの必要実装数を大幅に削減することができて、本装置の大幅な小型化を図ることが可能である。
（２）本装置の製造元にとっては、サービス種別毎に専用の通信サービスユニットを製造する必要がないので、多品種の製造及びメンテナンスから少品種の製造及びメンテナンスに移行することができ、コストダウン及び保守の品質向上を図ることができる。
【０１１５】
（３）通信サービスユニットがサービス種別に依存しないので、サービス種別毎に専用の通信サービスユニットを実装する場合に比して、トラフィックの許容量が大きくなり、呼損率を低く抑えることができる。この結果、ユーザにとっては、接続性が大幅に向上することになる。
（４）本装置の建局時における通信サービスユニット実装数の算出根拠について、トラフィック量を推定するだけでよく、通常、実施されている各サービス種別毎の周辺上位ノードからの要求トラフィック量の分析は不要となる。また、運用状態となった場合でも、各サービス毎のメンテナンスは不要となり、ピーク時のトラフィックに対する通信サービスユニットの過不足の対応のみで済む。
【０１１６】
なお、上記のモード制御は、外部装置からのモード設定指示に応じて適宜に設定・変更することもできるので、通信サービスユニットのフレキシブルな使用が可能になる。また、上記のモード制御は、過去のモード制御についての履歴に基づいて、或る時期のトラフィック傾向を予測し、その予測に応じて実施することもできるので、さらなる通信サービスユニットの実装数削減および呼損率の低減に大きく寄与する。
【０１１７】
ここで、上記の予測型のモード制御では、或る特定の時間帯に特定のサービス種別のトラフィックが増大することが事前に分かっている場合などにおいて、その時間帯には通信サービスユニットのモードをそのサービス種別に適したモードに設定するといった時刻要因による制御を行なうこともできるので、時間毎に特定のサービス種別対応の通信サービスユニットを事前に確保しておくことができ、さらに呼損率の低減を図ることができる。
【０１１８】
ところで、上記の通信サービスユニットは、複数種類の通信サービス種別に応じた複数種類の通信サービス制御プログラムの中から、信号処理モード制御指示に応じて対応するプログラムを選択的にロードすることにより、自身の信号処理モードを制御するようにしてもよく、このようにすれば、複数種類の通信サービス制御回路を個別にそなえる場合に比して、最小限のハードウェア規模で、複数種類の通信サービス種別に対応可能な通信サービスユニットを実現することができ、本マルチメディア信号処理装置をさらに小型に実現できる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る移動体通信網の構成を示すブロック図である。
【図２】本発明の一実施形態に係るマルチメディア信号処理装置としてのＡＴＭ交換機の構成を示すブロック図である。
【図３】図２に示すＡＴＭ交換機の要部に着目した構成を示すブロック図である。
【図４】図３に示すＳＰＵ状態管理部の構成を示すブロック図である。
【図５】（Ａ）は本実施形態に係るＳＰＵ状態管理データの一例を示す図、（Ｂ）は本実施形態に係る時刻対応属性管理データの一例を示す図である。
【図６】本実施形態に係る履歴情報（統計情報）の一例を示す図である。
【図７】図２及び図３に示すＳＰＵの詳細構成例を示すブロック図である。
【図８】図７に示すフラッシュメモリの記憶内容及びフラッシュメモリからのロード動作を説明するための図である。
【図９】本実施形態のＡＴＭ交換機の動作（ＳＰＵ属性変更手順）を説明するためのシーケンス図である。
【図１０】本実施形態のＳＰＵの動作を説明するためのシーケンス図である。
【図１１】本実施形態のＡＴＭ交換機の動作（時刻要因によるＳＰＵ属性変更手順）を説明するためのシーケンス図である。
【図１２】本実施形態のＡＴＭ交換機の動作（呼毎のＳＰＵ属性自動設定処理手順）を説明するためのシーケンス図である。
【図１３】本実施形態のＡＴＭ交換機の動作（捕捉ＳＰＵの解放処理手順）を説明するためのシーケンス図である。
【図１４】図２及び図３に示すＳＰＵ状態管理部の動作を説明するためのフローチャートである。
【図１５】図２及び図３に示すＳＰＵ状態管理部の動作を説明するためのフローチャートである。
【図１６】図２及び図３に示すＳＰＵ状態管理部の動作（非時刻要因ＳＰＵ属性変更手順）を説明するためのフローチャートである。
【図１７】図２及び図３に示すＳＰＵ状態管理部の動作（時刻要因ＳＰＵ属性変更手順）を説明するためのフローチャートである。
【図１８】図２及び図３に示すＳＰＵ状態管理部の動作（ＳＰＵ捕捉要求時）を説明するためのフローチャートである。
【図１９】図２及び図３に示すＳＰＵ状態管理部の動作（ＳＰＵ解放要求時）を説明するためのフローチャートである。
【図２０】図２及び図３に示すＳＰＵ状態管理部の動作（ＳＰＵ属性変更手順）を説明するためのフローチャートである。
【図２１】図２及び図３に示すＳＰＵ状態管理部の動作（時刻要因指定有りの場合）を説明するためのフローチャートである。
【図２２】（Ａ），（Ｂ）はいずれもＳＰＵの初期設定（サービス種別毎のＳＰＵ割り当て割合）を説明するための図である。
【図２３】既存の公衆交換網（トリー型網）の一例を模式的に示す図である。
【図２４】マルチメディア信号処理装置（交換装置）の一例を示すブロック図である。
【符号の説明】
１ 移動局（ＭＳ：Mobile Station）
２ 無線基地局（ＢＴＳ：Base Transceiver Station）
３ 無線ネットワーク制御装置（ＲＮＣ： Radio Network Controller）
４ マルチメディア信号処理装置〔ＭＰＥ（Multimedia signal Processing Equipment）；ＡＴＭ（Asynchronous Transfer Mode）交換機〕
５ 移動マルチメディア交換システム〔ＭＭＳ（Mobile Multimedia switching System）；上位ノード〕
６ オペレーションシステム〔ＯＰＳ（Operation System）；保守コンソール（外部装置）〕
７ａ ＡＴＭ網
７ｂ ＬＡＮ（Local Area Network）
１０ 移動体通信網
４１ ＡＴＭスイッチ
４２ ＡＴＭインタフェース（ＡＴＭ−ＩＦ）
４３ ＬＡＮ（Local Area Network）インタフェース（ＬＡＮ−ＩＦ）
４４−１〜４４−Ｎ ＳＰＵ（Service Protocol Unit；通信サービスユニット）
４５ 主制御部
４５ａ 呼制御部
４５ｂ サービス決定部（通信サービス種別識別手段）
４５ｃ ＳＰＵ状態管理部（モード制御手段）
４５ｄ ＳＰＵ状態管理受付部
４５ｅ ＳＰＵサービス変更部
５２ 履歴情報管理部
５３ 時刻要因属性変更部
６０ａ 制御系ネットワーク
６０ｂ 通信系ネットワーク（セルバス）
６１ 通信系インタフェース（ＩＦ）回路
６２ 制御系インタフェース（ＩＦ）回路
６３ 通信用デュアルポートＲＡＭ
６４ ＳＡＲ（Structure And Restructure）部
６５ ＣＰＵ〔ＳＰＵ属性変更部（モード選択制御部）〕
６６ フラッシュメモリ（記憶部）
６７ ＲＡＭ
６８−１〜６８−ｍ ＤＳＰ（Digital Signal Processor）モジュール
６９ ＩＰＬ（Initial Program Load）メモリ（ＲＡＭ）
７０ プログラムメモリ（ＲＡＭ）
１００ 公衆交換網
１３０ 集中局
１４０ 端局
４５１ ＳＰＵ状態管理データ
４５１ａ ＳＰＵ状態データ
４５１ｂ 外部指定属性種別データ
４５１ｃ 外部指定属性データ
４５１ｄ カレント属性データ
４５２ 時刻対応属性管理データ
４５２ａ 指定時刻データ
４５２ｂ 時刻対応属性データ
４５３ 統計情報（履歴情報）
６６１ ＩＰＬ領域
６６２ ＣＰＵファームウェア領域
６６３ ＤＳＰファームウェア領域
６６２−１ パケット用ＣＰＵファームウェア
６６２−２ 音声用ＣＰＵファームウェア
６６２−３ ＩＳＤＮ（Integrated Services Digital Network）用ＣＰＵファームウェア
６６２−４ ＰＩＡＦＳ（PHS Internet Access Forum Standard）用ＣＰＵファームウェア
６６２−５ ＰＰＰ（Point to Point Protocol）用ＣＰＵファームウェア
６６２−６ ＦＡＸ用ＣＰＵファームウェア
６６２−７ モデム用ＣＰＵファームウェア
６６２−８，６６３−８ 予備のファームウェア
６６３−１ パケット用ＤＳＰファームウェア
６６３−２ 音声用ＤＳＰファームウェア
６６３−３ ＩＳＤＮ用ＤＳＰファームウェア
６６３−４ ＰＩＡＦＳ用ＤＳＰファームウェア
６６３−５ ＰＰＰ用ＤＳＰファームウェア
６６３−６ ＦＡＸ用ＤＳＰファームウェア
６６３−７ モデム用ＤＳＰファームウェア
【発明の属する技術分野】
本発明は、マルチメディア信号処理装置に関し、例えば、一般的な公衆交換網や移動体（無線）通信網を構成するノード（上位ノード）に接続される交換装置など、上位ノードとの間で送受される信号（マルチメディア信号）に対して所要の信号処理を通信サービス種別に応じて行なう必要のある一装置に用いて好適な、マルチメディア信号処理装置に関する。
【０００２】
【従来の技術】
図２３は既存の公衆交換網の一例を模式的に示す図で、この図２３に示すように、通常、公衆交換網（以下、単に「公衆網」という）１００は、全国の加入者端末（電話機やパーソナルコンピュータ，ファクシミリなど）をそれぞれ近隣地域に設置された交換装置（交換局；ノード）に収容し、各地域の交換局を全てメッシュ状に接続することで構築するのは経済的ではないので、「トリー型網」と呼ばれる階層構造を基本として構築される。
【０００３】
即ち、日本の場合を例にすると、全国は、総括局（ＲＣ）１１０が１台ずつ置かれるいくつかの大きな区域（総括局区域；ＲＡ）１０１に分割され、さらに、各総括局区域１０１は、それぞれ、中心局（ＤＣ）１２０が１台ずつ置かれる中心局区域（ＤＡ）１０２に分割され、各中心局区域１０２は、それぞれ、集中局（ＴＣ）１３０が１台ずつ置かれる集中局区域（ＴＡ）１０３に分割され、各集中局区域１０３は、それぞれ、端局（ＥＯ）１４０が置かれる端局区域１０４に分割される。
【０００４】
そして、下位階層の局がそれぞれ上位階層の局にスター型網で接続される（例えば、端局１４０は集中局１３０に、集中局１３０は中心局１２０に、中心局１２０は総括局１１０にそれぞれ収容される）とともに、総括局１１０同士が基幹回線を介して接続されることで、公衆網１００が構築されるのである。
このような構成を採ることで、既存の公衆網１００では、例えば、東京−大阪間などの長距離市外通話の場合には、端局１４０を起点として集中局１３０，中心局１２０，総括局１１０という順に段階的に呼を集めて目的（着信先）の端局１４０を含む総括局１１０へ伝送すること、即ち、「トリー型網」に沿った呼の集配信が行なわれることにより、効率的な呼の伝送が可能になっている。
【０００５】
ところで、上位階層の局（上位ノード）に接続された交換装置に対する呼接続要求などのサービス要求（信号処理要求）には、例えば、音声通信やパケット通信，ＩＳＤＮ利用のデータ通信，ファクシミリ（ＦＡＸ）通信などの各種の通信サービス形態に応じた複数種類のサービス種別があり、また、呼毎にそのサービス種別も不定である。なお、「サービス種別」とは、通信サービスに固有の通信プロトコルの種別を意味する。
【０００６】
そして、このような様々なサービス種別の信号（マルチメディア信号）を交換装置で扱う必要がある場合、その交換装置は、マルチメディア信号の処理が可能な装置（マルチメディア信号処理装置）としても機能する必要があるため、例えば図２４に示すように、サービス種別（＃Ａ，＃Ｂ，＃Ｃなどと表わす）毎に各サービス種別に専用のパッケージ（ＰＫＧ）２００が、各サービス種別毎に予測される最大トラフィック（最大呼数）をカバーできる分だけ実装されて、上位ノード４００からのサービス要求毎にそのサービス種別に対応するパッケージ２００が選択され、サービス要求のあった呼に対する呼処理（信号処理）が実施されるようになっている。
【０００７】
即ち、例えば、上位ノード４００からサービス種別＃Ａについてのサービス要求があれば、交換装置は、主制御部３００における呼制御部３０１の制御の下で、サービス決定部３０２によって、受信したサービス要求に含まれる情報から呼のサービス種別＃Ａを判断／決定し、パッケージ実装状態管理部３０３にて管理されているパッケージ実装状態管理データ３３０に基づいて、サービス種別＃Ａ用のパッケージ２００のうち空き状態のパッケージ２００を、例えば、いわゆる入側トランク／出側トランクなどとして選択（捕捉）して呼処理を行なう。
【０００８】
なお、他のサービス種別＃Ｂや＃Ｃについてのサービス要求があった場合も同様に、対応するサービス種別＃Ｂ，＃Ｃ用の空きパッケージ２００が捕捉されて呼処理が実行される。
【０００９】
【発明が解決しようとする課題】
しかしながら、上述したような構成では、上位ノード４００からのサービス要求に対応するパッケージ２００がサービス種別毎に固定であるため、予測される最大トラフィックをカバーできる分のパッケージ２００を予め実装しておかなければならず、交換装置の規模が増大してしまうという課題がある。しかも、最大トラフィックを超える量の呼（過負荷トラフィック）が発生した場合には、上記の構成及び処理では、呼損の発生が余儀なくされていた。
【００１０】
本発明は、このような課題に鑑み創案されたもので、呼毎にパッケージ（通信サービスユニット）の信号処理モードをその呼のサービス種別に適したモードに変更できるようにすることで、パッケージの実装数を大幅に削減するとともに、呼損率を大幅に低減できるようにした、マルチメディア信号処理装置を提供することを目的とする。
【００１３】
【課題を解決するための手段】
複数種類のサービス種別に応じた複数種類の信号処理モードを有するサービスユニットと、上位ノードから通知される或る呼についての信号処理要求情報に基づいて該呼のサービス種別を識別するサービス種別識別手段と、前記呼のサービス種別のトラフィックに対してサービスユニットが不足した場合でも、他のサービス種別に適したモードで動作していた他のサービスユニットのモードを不足の生じたサービス種別対応のモードに変更する制御手段と、を有するマルチメディア信号処理装置を用いることができる。
さらに、複数種類の通信サービス種別に応じた複数種類の信号処理モードを有する通信サービスユニットと、上位ノードから通知される或る呼についての信号処理要求情報に基づいて該呼の通信サービス種別を識別する通信サービス種別識別手段と、該通信サービスユニットの信号処理モードを該通信サービス種別識別手段で識別された通信サービス種別に適したモードに制御するモード制御手段と、をそなえ、上記のモード制御手段は、過去に行なったモード制御についての履歴情報を管理する履歴情報管理手段と、前記の履歴情報に基づいて上記の通信サービスユニットの信号処理モードを予測制御する予測型モード制御手段とをそなえていてもよい。このような構成を採れば、通信サービスユニットのモードを過去のモード制御についての履歴に基づいて、或る時期のトラフィック傾向を予測して、その予測に応じたモード制御を実施することができる。
【００１４】
ここで、上記の予測型モード制御手段には、上記の履歴情報に基づいた時刻情報とモード設定情報とに基づいて、指定時刻に通信サービスユニットのモードを上記のモード設定情報に応じたモードに制御する時刻要因モード制御手段をそなえていてもよい。このような構成を採れば、例えば、或る特定の時間帯に特定のサービス種別のトラフィックが増大することが事前に分かっている場合などにおいて、その時間帯には通信サービスユニットのモードをそのサービス種別に適したモードに設定するといった制御が可能になる。
【００１５】
また、上記の通信サービスユニットは、複数種類の通信サービス種別に応じた複数種類の通信サービス制御プログラムを記憶した記憶手段と、上記のモード制御手段からの信号処理モード制御指示に応じて対応する通信サービス制御プログラムを上記記憶手段から選択的にロードすることにより、自身の信号処理モードを制御するモード選択制御手段とをそなえて構成されていてもよい。
【００１６】
このようにすれば、複数種類の通信サービス制御回路を個別にそなえる場合に比して、最小限のハードウェア規模で、複数種類の通信サービス種別に対応可能な通信サービスユニットを実現することができる。
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
図１は本発明の一実施形態に係る移動体通信網の構成を示すブロック図で、この図１に示す移動体通信網１０は、移動局（ＭＳ：Mobile Station）１，複数の無線基地局（ＢＴＳ：Base Transceiver Station）２，複数の無線ネットワーク制御装置（ＲＮＣ： Radio Network Controller）３，マルチメディア信号処理装置（ＭＰＥ：Multimedia signal Processing Equipment）４，移動マルチメディア交換システム（ＭＭＳ：Mobile Multimedia switching System）５，オペレーションシステム（ＯＰＳ：Operation System）６などをそなえて構成されている。
【００１８】
ここで、まず、上記のＭＳ１は、いわゆる携帯電話やＰＨＳ（Personal Handy-phone System）端末、これらを利用してデータ通信を行ないうるＰＤＡ（Personal Digital Assistance）やノート型のパーソナルコンピュータなどを含む携帯情報端末である。なお、この図１では、ＭＳ１を１台しか図示していないが、勿論、複数台存在していてもよい。
【００１９】
次に、ＢＴＳ２は、それぞれ、自身が形成する無線通信範囲（在圏ゾーン）内のＭＳ１と無線通信を行なって、ＭＳ１との間で各種通信サービス種別（プロトコル種別）に応じた呼（データ）の送受を行なうためのものである。ここで、上記の通信サービス種別（以下、単に「サービス種別」といったり「プロトコル属性」といったりすることがある）としては、例えば、次のような各種サービスが挙げられる。
【００２０】
▲１▼一般の音声通話サービス
▲２▼パケット通信サービス
▲３▼ＩＳＤＮ（Integrated Services Digital Ne twork）利用の通信サービス
▲４▼ＰＨＳを利用してインターネットにアクセスする場合のＰＩＡＦＳ（PHS Internet Access Forum Standard）準拠のデータ通信サービス
▲５▼ポイントツーポイントプロトコル（ＰＰＰ）準拠のデータ通信サービス〔ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）通信〕
▲６▼ファクシミリ（ＦＡＸ）通信サービス
▲７▼モデム（ＭＯＤＥＭ）利用のデータ通信サービス
なお、以下において、上記の音声通話サービスを「音声」、パケット通信サービスを「パケット」、ＩＳＤＮ利用の通信サービスを「ＩＳＤＮ」、ＰＩＡＦＳ準拠のデータ通信サービスを「ＰＩＡＦＳ」、ＰＰＰ準拠のデータ通信サービスを「ＰＰＰ」、ＦＡＸ通信サービスを「ＦＡＸ」、モデム利用のデータ通信サービスを「モデム」などと略記することがある。
【００２１】
次に、上記のＲＮＣ３は、複数のＢＴＳ２を収容して、ＭＭＳ５から配信（交換）されてくる呼を着信対象のＭＳ１が存在する在圏ゾーン担当のＢＴＳ２に着信させたり、ＢＴＳ２からの呼を多重してＭＭＳ５へ送信したりといった、各種無線通信制御を実施するためのものである。
さらに、上記のＭＰＥ４は、ＲＮＣ３に接続されて、ＲＮＣ３で受信される信号（データ）のサービス種別に応じたプロトコル変換などの各種信号処理を行なうためのもので、例えば図２に示すように、ＲＮＣ３をＡＴＭ（Asynchronous Transfer Mode）網７ａ経由で収容する場合には、ＡＴＭ交換機として構成される。なお、その詳細については後述する。
【００２２】
また、ＭＭＳ５は、ゲートウェイ局（図示省略）などを介して図２３により前述した集中局１３０や中心局１２０，総括局１１０などに接続されることによって、公衆網１００と接続されて、公衆網１００とＲＮＣ３やＭＰＥ４との間の呼の交換処理を行なうためのものである。つまり、本ＭＭＳ５は、ＭＰＥ４に対して呼接続／解放などのサービス要求（信号処理要求）を行なう上位ノードとして位置付けられる。なお、上記のサービス要求には、呼のサービス種別を識別するための情報が含まれているものとする。
【００２３】
さらに、ＯＰＳ６は、ＬＡＮ（Local Area Network）７ｂなどの所要の回線網を介してＭＰＥ４と接続されて、ＭＰＥ４の保守や運用管理を行なうためのもので、例えば図３に示すように保守コンソールなどとして構成され、この保守コンソール６からＭＰＥ４の動作設定などの各種設定を適宜に行なえるようになっている。
【００２４】
そして、上記のＭＰＥ４は、上述したごとくＡＴＭ交換機として構成される場合には、例えば図２に示すように、ＡＴＭスイッチ４１，ＡＴＭインタフェース（ＡＴＭ−ＩＦ）４２，ＬＡＮインタフェース（ＬＡＮ−ＩＦ）４３，複数のサービスプロトコルユニット（ＳＰＵ）４４−１〜４４−Ｎ（Ｎは自然数），主制御部４５などをそなえて構成される。
【００２５】
ここで、ＡＴＭスイッチ４１は、ＡＴＭ網７ａやＬＡＮ７ｂとの間で送受される呼をＡＴＭセルベースで交換（スイッチング）するためのもので、周知のように、受信ＡＴＭセルのヘッダ部分に設定されている宛先情報〔ＶＰＩ（Virtual Path Identifier）／ＶＣＩ（Virtual Channel Identifier）〕に基づく装置内経路識別情報（タグ情報）の設定が主制御部４２から与えられることにより、上記宛先情報に応じた経路のコネクションが確立されてＡＴＭセルの転送（ＡＴＭ通信）が行なわれるようになっている。
【００２６】
また、ＡＴＭインタフェース４２は、ＡＴＭ網７ａとの間のインタフェースをとるためのものであり、ＬＡＮインタフェース４３は、ＬＡＮ７ｂとのインタフェースをとるためのもので、ＬＡＮ７ｂからの信号をＡＴＭセルに変換したり、ＡＴＭスイッチ４１でスイッチングされてきたＡＴＭセルをＬＡＮ７ｂへの信号に変換したりする機能を有している。
【００２７】
さらに、各ＳＰＵ（パッケージ）４４−ｉは、それぞれ、呼のサービス種別に応じたプロトコル終端処理を実施するためのもので、本実施形態では、１つのＳＰＵ４４−ｉで前述したような複数種類のサービス種別に応じた（適した）属性（信号処理モード）での動作が可能になっている。なお、その詳細については図７及び図８により後述する。
【００２８】
そして、主制御部４５は、本ＡＴＭ交換機４の動作（コネクションの確立／解放処理など）を統括的に制御するためのものであるが、本実施形態では、ＳＰＵ４４−ｉ（ただし、ｉ＝１〜Ｎ）をはじめとするＡＴＭ交換機４内のリソース（ＡＴＭスイッチ４１や帯域なども含まれる）を管理して、上位ノード５からのサービス要求（呼接続要求や呼解放要求などの信号処理要求）に応じて必要なリソース（ＳＰＵ４４−ｉを含む）を捕捉したり解放したりする基本的な機能を有するほか、上位ノード５からのサービス要求毎に、あるいは、保守コンソール６からの指示（外部設定）に応じて、上記のＳＰＵ４４−ｉの属性（信号処理モード）を適宜に変更することで、ＳＰＵ４４−ｉのサービス種別毎の割り当て数を適宜に変更しうる機能も有している。
【００２９】
このため、本主制御部４５には、その要部に着目すると、例えば図３に示すように、呼制御部４５ａ，サービス決定部４５ｂ及びＳＰＵ状態管理部４５ｃがそなえられている。なお、この図３において、図２に示すＡＴＭスイッチ４１やＡＴＭインタフェース４２，ＬＡＮインタフェース４３などの図示は省略している。
【００３０】
ここで、上記の呼制御部４５ａは、上述したコネクションの確立／解放（リソースの捕捉／解放）処理などを中心的に制御するためのものであり、サービス決定部（通信サービス種別識別手段）４５ｂは、上位ノード５から通知されるサービス要求に含まれるサービス種別を識別するための情報に基づいて処理対象呼のサービス種別を判別（識別）するためのもので、その識別結果は、その呼の信号処理に必要な（要求サービスプロトコル属性が一致する）ＳＰＵ４４−ｉの捕捉要求（以下、ＳＰＵ捕捉要求という）として呼制御部４５ａを通じてＳＰＵ状態管理部４５ｃに通知されるようになっている。
【００３１】
そして、ＳＰＵ状態管理部（モード制御手段）４５ｃは、ＳＰＵ４４−ｉの実装数や各ＳＰＵ４４−ｉの稼働状態（空き状態，属性）などを管理するとともに、呼制御部４５ａと協動して、保守コンソール６からの指示（ＳＰＵ属性変更指示）や呼制御部４５ａからの上記ＳＰＵ捕捉要求に応じて、ＳＰＵ４４−ｉの属性（信号処理モード）を要求サービス種別に適した属性に制御（変更）する機能を有するもので、このために、例えば、ＳＰＵ状態管理受付部４５ｄとＳＰＵサービス変更部４５ｅとをそなえて構成されている。
【００３２】
即ち、ＳＰＵ状態管理受付部４５ｄは、例えば図５（Ａ）に示すように、各ＳＰＵ４４−ｉ毎に割り振られた論理番号（以下、ＳＰＵ論理番号という）毎に、それぞれ、下記▲１▼〜▲４▼に示すデータを含むＳＰＵ状態管理データ４５１を管理することで、各ＳＰＵ４４−ｉのそれぞれの稼働状態をリアルタイムに管理するためのものである。
【００３３】
▲１▼ＳＰＵ状態データ４５１ａ：ＳＰＵ４４−ｉの空き／使用中を表わすためのデータで、例えば、“０”で「空き」状態、“１”で「使用中」状態を表わす。なお、ＳＰＵ４４−ｉは、通常、１枚で複数チャンネル分の呼を処理できる能力を有しているが、本実施形態では、説明の便宜上、１枚のＳＰＵ４４−ｉで１チャンネル分の呼を処理できるものとし、ＳＰＵ４４−ｉの「空き」とは、呼処理を行なっていない待機状態の場合を意味するものとする。
【００３４】
▲２▼外部指定属性種別データ４５１ｂ：ＳＰＵ４４−ｉが図５（Ｂ）により後述する時刻対応属性管理データ４５２によって指定された時刻対応のものか否かを表わすデータで、例えば、“０”で「時刻対応」、それ以外の値で「非時刻対応」を表わす。
▲３▼外部指定属性データ４５１ｃ：保守コンソール６からデフォルト属性（優先属性）として指定されたＳＰＵ４４−ｉの属性（サービス種別）を表わすデータで、例えば、“０”で「指定無し」、“０”以外で「指定有り」を表わす。一例として、“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対応」、“５”で「ＦＡＸ対応」、“６”で「モデム対応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。
【００３５】
▲４▼カレント属性データ４５１ｄ：現在のＳＰＵ４４−ｉの属性を表わすデータで、上記の外部指定属性データ４５１ｃと同様に、“０”で「指定無し」、“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対応」、“５”で「ＦＡＸ対応」、“６”で「モデム対応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。このカレント属性データ４５１ｄの値と上記の外部指定属性データ４５１ｃの値とが異なる場合には、後述するように、後者の外部指定属性データ４５１ｃが優先され、前者のカレント属性データ４５１ｄが外部指定属性データ４５１ｃと一致するよう更新される。
【００３６】
なお、上記のＳＰＵ状態データ４５１ａ以外のデータ４５１ｂ〜４５１ｄについては、保守コンソール６からＳＰＵ属性変更指示（モード設定指示）をＳＰＵ状態管理受付部４５ｄに対して与えることで適宜に変更することが可能である。また、上記のＳＰＵ状態管理データ４５１は、図示しないメモリなどの記憶装置に記憶されて管理されているものとする。
【００３７】
一方、ＳＰＵサービス変更部４５ｅは、保守コンソール６からの指示（ＳＰＵ属性変更指示）や呼制御部４５ａからのＳＰＵ捕捉要求〔サービス決定部４５ｂでのサービス種別（要求プロトコル）の識別結果〕に基づき、ＳＰＵ属性変更が必要な場合にはＳＰＵ属性変更依頼（要求）を、呼制御部４５ａを通じ該当ＳＰＵ４４−ｉに与えるためのもので、これにより、該当ＳＰＵ４４−ｉは、要求された属性のＳＰＵ４４−ｉとして設定されて運用されることになる。
【００３８】
なお、この属性変更指示が実施された場合は、該当ＳＰＵ４４−ｉに対応するＳＰＵ状態管理データ４５１（カレント属性データ４５１ｄ）が更新される。
つまり、これらのＳＰＵ状態管理受付部４５ｄとＳＰＵサービス変更部４５ｅは、外部装置（他制御部）としての保守コンソール６からのＳＰＵ属性変更指示（モード設定指示）に応じてＳＰＵ４４−ｉの属性（信号処理モード）を制御する外部指示型モード制御部としての機能も果たしていることになる。
【００３９】
ところで、上記のＳＰＵサービス変更部４５ｅは、図４に示すように、上述したような基本機能に加えて、例えば図６に示すような形式で、過去に行なったＳＰＵ４４−ｉに対する属性変更指示（モード制御）についての統計情報（履歴情報）４５３、つまり、前記のカレント属性データ４５１ｄの更新履歴をとることにより、いつ、どのＳＰＵ４４−ｉがどの属性で動作していたかを管理する履歴情報管理部５２としての機能も有している。
【００４０】
この履歴情報管理部５２をそなえることで、例えば、どのサービス種別の呼（トラフィック）がどの日付や曜日，時間帯で集中しやすいかを分析・把握することができるようになるので、ＳＰＵ状態変更部４５ｃは、その分析結果に応じて、特定時刻に特定のサービス種別対応のＳＰＵ割り当て数を予め多めに設定したり少なめに設定したりすることができる。
【００４１】
例えば図６では、一般企業の業務時間外などでは音声やＩＳＤＮのトラフィックが比較的少ないと判断できるので、その時間帯では音声対応（属性＝“１”）やＩＳＤＮ対応（属性＝“２”）のＳＰＵ割り当て数を少なめに設定したり、逆に、業務開始時や昼休み終了時などトラフィックが急激に増加しやすい時間帯ではこれらのＳＰＵ割り当て数を予め多めに設定しておくようにすることができる。
【００４２】
なお、この図６に示す例は、ＳＰＵ４４−ｉの実装数（Ｎ）が３２枚（論理番号＝１〜３２；ただし、論理番号３１，３２のＳＰＵ４４−３１，４４−３２は予備）の場合で、図２２（Ａ）により後述するように、「音声」，「ＩＳＤＮ」，「パケット」，「ＰＩＡＦＳ」，「ＦＡＸ」，「モデム」，「ＰＰＰ」の各サービス種別対応のＳＰＵ４４−ｉの初期割り当て数を最小限（それぞれ１枚）にした状態を表わす。
【００４３】
そして、このような時刻要因による設定は、本実施形態では、図４に示すように、ＳＰＵサービス変更部４５ｅに、図５（Ｂ）に示すようなＳＰＵ４４−ｉ毎に管理される時刻対応属性管理データ４５２に基づいて該当ＳＰＵ４４−ｉに対して属性変更指示を与える時刻要因属性変更部５３をそなえることで実現される。
【００４４】
即ち、時刻要因属性変更部５３は、図５（Ｂ）に示すように、ＳＰＵ論理番号毎に、或る指定時刻（時間帯）にＳＰＵ４４−ｉのどの属性に設定するかを表わすデータ（指定時刻データ４５２ａと指定時刻対応属性データ４５２ｂとの組）を最大でｎ（ｎは自然数）組分、時刻対応属性管理データ４５２として管理しておき、この時刻対応属性管理データ４５２を、常時、或いは、定期的に参照することで、該当ＳＰＵ４４−ｉの属性を指定時刻に指定された属性に自動変更（設定）することができるのである。
【００４５】
つまり、上記の履歴情報管理部５２と時刻要因属性変更部５３は、上記の履歴情報４５３に基づいてＳＰＵ４４−ｉの属性を予測制御する予測型モード制御部として機能し、時刻要因属性変更部５３は、上記の履歴情報４５３に基づいた時刻対応属性管理データ４５２に基づいて、指定時刻にＳＰＵ４４−ｉの属性を指定された属性に制御する時刻要因モード制御部として機能するのである。
【００４６】
なお、上記の指定時刻対応属性データ４５２ｂには、図５（Ａ）により前述した外部指定属性データ４５１ｃやカレント属性データ４５１ｄと同様に定義された値が設定される。即ち、“０”で「指定無し」、“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対応」、“５”で「ＦＡＸ対応」、“６”で「モデム対応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。
【００４７】
また、上記の時刻対応属性管理データ４５２や履歴情報４５３についても、図示しないメモリなどの記憶装置にて保持されて管理されているものとする。さらに、上記の指定時刻データ４５２ａ（時間帯）は、開始時刻と終了時刻とで規定してもよいし、開始時刻とその後の継続時間とで規定してもよい。また、上記の時刻対応属性管理データ４５２は、時刻要因属性変更部５３が上記の履歴情報４５３（図６参照）に基づいて自動作成してもよいし、後述するように保守コンソール６から個別に設定してもよい。
【００４８】
次に、上記の各ＳＰＵ４４−ｉの構成について説明する。
図７は上記の各ＳＰＵ４４−ｉの詳細構成を示すブロック図で、この図７に示すように、各ＳＰＵ４４−ｉは、それぞれ、通信系インタフェース（ＩＦ）回路６１，制御系インタフェース（ＩＦ）回路６２，通信用デュアルポートＲＡＭ（ＤＰＲＡＭ）６３，セル組立分解（ＳＡＲ：Structure And Restructure）部６４，ＣＰＵ６５，フラッシュメモリ６６，ＲＡＭ６７，ＤＳＰ（Digital Signal Processor）モジュール６８−１〜６８−ｍ（ｍは自然数），ＩＰＬ（Initial Program Load）メモリ（ＲＡＭ）６９及びプログラムメモリ（ＲＡＭ）７０などをそなえて構成されている。
【００４９】
ここで、上記の通信系ＩＦ回路６１は、ＡＴＭセルの流れる通信系ネットワーク（セルバス）６０ｂとのインタフェースをとるためのものであり、制御系ＩＦ回路６２は、制御バスや監視用（ＳＶ：Supervision）バスなどから成る制御系ネットワーク６０ａとのインタフェースをとるためのものであり、通信用ＤＰＲＡＭ６３は、この制御系ＩＦ回路６２を介した制御系ネットワーク６０ａとの通信（制御バス経由）時に送受される制御メッセージを記憶するためのもので、この通信用ＤＰＲＡＭ６３にＣＰＵ６５がアクセスすることによりその制御メッセージに応じた制御を行なえるようになっている。
【００５０】
また、ＳＡＲ部６４は、ＡＴＭセルの組立（ヘッダ付加）／分解（ヘッダ除去）処理をおこなうためのもので、本ＳＡＲ部６４と各ＤＳＰモジュール６８−ｊ（ｊ＝１〜ｍ）との間では、ＡＴＭセルのヘッダを除くデータ部分のみが送受されるようになっている。
さらに、ＣＰＵ６５は、プログラムメモリ７０に保持されたＣＰＵ６５用のプログラム（ＣＰＵファームウェア）に従って動作することによりＳＰＵ４４−ｉの動作（マルチメディア信号処理）を統括的に制御するためのものであり、各ＤＳＰモジュール６８−ｊは、それぞれ、ＲＡＭ６７に保持されたＤＳＰ６８−ｊ用のプログラム（ＤＳＰファームウェア）を内部メモリ（図示省略）にロードすることにより、そのＤＳＰファームウェアに従って、ＳＡＲ部６４から受信されるセルデータ（マルチメディア信号）に対する信号処理（プロトコル変換など）を実施するためのものである。
【００５１】
ただし、本実施形態では、フラッシュメモリ６６内に各サービス種別に対応した複数種類のＣＰＵファームウェア及びＤＳＰファームウェアが通信サービス制御プログラムとして予めサービス種別毎に異なる領域に格納されており、上述したＳＰＵサービス変更部４５ｃからの属性変更指示に応じたファームウェア（格納領域）を選択してＲＡＭ６７に読み出して、ＣＰＵ６５とＤＳＰモジュール６８−ｊのいずれかとにそれぞれ必要なＣＰＵファームウェア及びＤＳＰファームウェアをロードさせることで、上述したごとく１つのＳＰＵ４４−ｉで複数種類のサービス種別に対応した信号処理を行なえるようになっている。
【００５２】
即ち、例えば図８に示すように、フラッシュメモリ６６には、少なくとも、ＩＰＬ領域６６１，ＣＰＵファームウェア領域６６２，ＤＳＰファームウェア領域６６３などが設けられており、ＣＰＵファームウェア領域６６２には、パケット（属性＝“３”），音声（属性“１”），ＩＳＤＮ（属性＝“２”），ＰＩＡＦＳ（属性＝“４”），ＰＰＰ（属性＝“７”），ＦＡＸ（属性＝“５”），モデム（属性＝“６”）などの各サービス種別対応のＣＰＵファームウェア（プログラム）６６２−１〜６６２−７が格納され、同様にして、ＤＳＰファームウェア領域６６３に、各サービス種別対応のＤＳＰファームウェア（プログラム）６６３−１〜６６３−７が格納されている。
【００５３】
なお、上記のＩＰＬ領域６６１には、ＳＰＵ起動時（電源投入時）などにおいてＣＰＵ６５が最初に読み込む（ＩＰＬメモリ６９に展開すべき）初期化プログラムが格納されている。また、各ファームウェア領域６６２，６６３には、それぞれ、ＳＰＵ４４−ｉが対応すべきサービス種別数が増えたときのための予備のファームウェア領域６６２−８，６６３−８も設けられている。
【００５４】
そして、前述したＳＰＵ状態管理部４５ｃ（ＳＰＵサービス変更部４５ｅ）からの属性変更指示（例えば、パケット対応のものへの属性変更指示）が上記の制御メッセージとして制御系ネットワーク６０ａを介して通信用ＤＰＲＡＭ６３に保持されると、ＣＰＵ６５は、上記の属性変更指示で指定されたサービス種別対応（図８ではパケット用）のＣＰＵファームウェア６６２−１及びＤＳＰファームウェア６６３−１をそれぞれ運用ファームウェアとしてプログラムメモリ７０及びＲＡＭ６７に読み出す（展開する）ことで、自身とＤＳＰモジュール６８−ｊのいずれかとに運用ファームウェアをそれぞれロードするのである。
【００５５】
つまり、上記のフラッシュメモリ６６は、複数種類の通信サービス種別に応じた複数種類の通信サービス制御プログラムを記憶した記憶部として機能し、ＣＰＵ６５は、前述したＳＰＵ状態管理部４５ｃからの属性変更指示に応じて対応する通信サービス制御プログラムをフラッシュメモリ６６から選択的にロードすることにより、自身の属性（信号処理モード）を制御するＳＰＵ属性変更部（モード選択制御部）として機能するようになっているのである。
【００５６】
このため、ＤＳＰモジュール６８−ｊの実装数（ｍ）は、前記のサービス種別数よりも少ない数でよく、未使用のＤＳＰモジュール６８−ｊは、障害発生などにより使用不能となったＤＳＰモジュール６８−ｊの予備として使用することができる。
以下、上述のごとく構成された本実施形態のＡＴＭ交換機（ＭＰＥ）４の動作について詳述する。
【００５７】
（１）ＳＰＵ属性設定手順（時刻要因／非時刻要因）の説明
まず、保守コンソール６からＳＰＵ４４−ｉの属性を設定（変更）する手順（非時刻要因）について説明する。
例えば図９に示すように、保守コンソール６から或るＳＰＵ４４−ｉに対するＳＰＵ属性変更指示（ＩＤ＝１）を処理要求として投入すると（ステップＡ１）、その処理要求（ＳＰＵ属性変更指示）は、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）にて受け付けられる。
【００５８】
すると、ＳＰＵ状態管理受付部４５ｄは、受信したＳＰＵ属性変更指示に従って、該当ＳＰＵ４４−ｉについてのＳＰＵ状態管理データ４５１を更新し、属性変更対象のＳＰＵ４４−ｉに対する属性変更依頼をＳＰＵサービス変更部４５ｅに対して行なう（ステップＡ２）。
具体的に、この場合、ＳＰＵ状態管理受付部４５ｄは、図１４に示すように、保守コンソール６から受信した処理要求内容が非時刻要因のＳＰＵ属性変更指示（ＩＤ＝１．２）であるので、ステップＳ１からステップＳ１０に分岐し、さらに、図１５に示すステップＳ１１からステップＳ１２に分岐して、図１６に示す処理手順（ステップＡ３）を実行する。
【００５９】
即ち、ＳＰＵ状態管理受付部４５ｄは、まず、ＳＰＵ状態管理データ４５１を参照し（ステップＳ１２１）、外部指定属性データ４５１ｃに“０”（＝「指定無し」）以外の値が設定されているか否かを確認する（ステップＳ１２２）。
この結果、“０”（＝「指定無し」）以外の値が設定されていれば（ステップＳ１２２でＹＥＳなら）、上記のＳＰＵ属性変更指示の優先度に従って外部指定属性データ４５１ｃをＳＰＵ属性変更指示によって指定されたサービス種別に応じた値に更新する。つまり、保守コンソール６からのＳＰＵ属性変更指示の優先度の方が高ければ外部指定属性データ４５１ｃの更新を行なう（ステップＳ１２３）。
【００６０】
一方、外部指定属性データ４５１ｃに“０”（＝「指定無し」）が設定されていた場合（ステップＳ１２２でＮＯの場合）は、ＳＰＵ状態管理受付部４５ｄは、新たに外部指定属性データ４５１ｃを指定されたサービス種別に応じた値に更新する（ステップＳ１２４）。
その後、ＳＰＵ状態管理受付部４５ｄは、ＳＰＵ状態データ４５１ａを参照して属性変更対象のＳＰＵ４４−ｉが空き状態か使用中かを確認し（ステップＳ１２５）、空き状態（属性変更可能な状態）であれば、ＳＰＵサービス変更部４５ｅにそのＳＰＵ４４−ｉの属性変更を依頼する。
【００６１】
すると、ＳＰＵサービス変更部４５ｅは、依頼を受けたＳＰＵ４４−ｉに対してＳＰＵ属性変更指示を与える（ステップＳ１２５のＹＥＳルートからステップＳ１２６：図９のステップＡ４）。
なお、属性変更対象のＳＰＵ４４−ｉが使用中であった場合は、外部指定属性データ４５１ｃを更新したことを要因として、図１９及び図２０により後述するように、ＳＰＵ４４−ｉを使用している呼の解放処理中に属性変更が実施されるので、この場合、ＳＰＵサービス変更部４５ｅは、使用中ＳＰＵ４４−ｉに対するＳＰＵ属性変更指示は出力しない（ステップＳ１２５のＮＯルート）。
【００６２】
さて、次に、図１０に示すように、上述のごとくＳＰＵサービス変更部４５ｅからＳＰＵ属性変更指示を起動（ステップＢ０）後に受けた（ステップＢ１）ＳＰＵ４４−ｉでは、ＣＰＵ６５が、図８により前述したように、要求されたサービス種別（プロトコル）対応のＣＰＵファームウェア６６２−ｋ（ｋ＝１〜７）をフラッシュメモリ６６のＣＰＵファームウェア領域６６２から読み出してプログラムメモリ７０に書き込むことで、要求サービス種別対応のＣＰＵファームウェア６６２−ｋをＣＰＵ６５に対してロードする（ステップＢ２）。
【００６３】
同様に、ＣＰＵ６５は、要求サービス種別対応のＤＳＰファームウェア６６３−ｋをフラッシュメモリ６６のＤＳＰファームウェア領域６６３から読み出してＤＳＰモジュール６８−ｊのいずれかの内部メモリに書き込むことで、ＤＳＰファームウェアのロードを実行する（ステップＢ３；図９のステップＡ５）。以上の処理が完了すると、ＳＰＵ４４−ｉが運用可能状態となり、ＣＰＵ６５は、その旨を、制御系ネットワーク６０ａを介してＳＰＵ状態管理部４５ｃに通知する（ステップＢ４）。
【００６４】
すると、ＳＰＵ状態管理部４５ｃは、図９に示すように、保守コンソール６に対して、ＳＰＵ属性変更完了通知を行なう（ステップＡ６）。以上のような処理を属性変更対象のＳＰＵ４４−ｉ分だけ繰り返すことで、任意のＳＰＵ４４−ｉを所望のサービス種別対応のＳＰＵ４４−ｉとして設定して、サービス種別毎のＳＰＵ割り当て数を設定・変更することが可能になる。
【００６５】
なお、上記の例では、保守コンソール６からＳＰＵ属性変更指示を、属性変更対象のＳＰＵ数分だけ繰り返すことを前提としているが、ＳＰＵ属性変更指示に複数分のＳＰＵ属性変更のための情報を設定することで、保守コンソール６からの１回のＳＰＵ属性変更指示の投入で、複数のＳＰＵ４４−ｉの属性を変更できるようにしてもよい。
【００６６】
次に、保守コンソール６から時刻要因によるＳＰＵ属性変更を設定する場合の動作について説明する。
まず、図１１に示すように、保守コンソール６から或るＳＰＵ４４−ｉに対する時刻要因のＳＰＵ属性変更指示（ＩＤ＝１．１）を処理要求として投入すると（ステップＣ１）、その処理要求（ＳＰＵ属性変更指示）は、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）にて受け付けられる。
【００６７】
すると、ＳＰＵ状態管理受付部４５ｄは、受信したＳＰＵ属性変更指示に従って、該当ＳＰＵ４４−ｉについてのＳＰＵ状態管理データ４５１を更新する（ステップＣ２）。
具体的に、この場合、ＳＰＵ状態管理受付部４５ｄは、図１４に示すように、保守コンソール６から受信した処理要求内容が時刻要因のＳＰＵ属性変更指示（ＩＤ＝１．１）であるので、ステップＳ１からステップＳ１０に分岐し、さらに、図１５に示すステップＳ１１からステップＳ１３に分岐して、図１７に示す処理手順（ステップＣ３）を実行する。
【００６８】
即ち、ＳＰＵ状態管理受付部４５ｄは、まず、ＳＰＵ状態管理データ４５１を参照し（ステップＳ１３１）、外部指定属性データ４５１ｃに“０”（＝「指定無し」）以外の値が設定されているか否かを確認する（ステップＳ１３２）。
この結果、“０”（＝「指定無し」）以外の値が設定されていれば、上記のＳＰＵ属性変更指示の優先度に従って外部指定属性種別データ４５１ｂを「時刻対応」（＝“０”）に設定（更新）する。即ち、保守コンソール６から投入されたＳＰＵ属性変更指示の優先度の方が高ければ外部指定属性データ４５１ｂの設定（更新）を行なう（ステップＳ１３２のＹＥＳルートからステップＳ１３３）。
【００６９】
一方、外部指定属性データ４５１ｃに“０”（＝「指定無し」）が設定されていた場合は、ＳＰＵ状態管理受付部４５ｄは、外部指定属性種別データ４５１ｂに「時刻対応」（＝“０”）を設定する（ステップＳ１３２のＮＯルートからステップＳ１３４）。
その後、ＳＰＵ状態管理受付部４５ｄは、属性変更対象のＳＰＵ４４−ｉに対応する時刻対応属性管理データ４５２を参照し（ステップＳ１３５）、指定時刻データ４５２ａと時刻対応属性データ４５２ｂとを設定したのち（ステップＳ１３６）、保守コンソール６へＳＰＵ４４−ｉの属性変更（設定）が完了した旨を通知する（ステップＳ１３７；図１１のステップＣ４）。
【００７０】
以上により、時刻要因によるＳＰＵ４４−ｉの属性変更（設定）が完了し、以後、指定時刻になると、該当ＳＰＵ４４−ｉが空き状態で、且つ、カレント属性（データ４５１ｄ）と外部指定属性（データ４５１ｃ）とが一致していなければ、自動的に、ＳＰＵ属性サービス変更部４５ｅから該当ＳＰＵ４４−ｉに対して（空き状態であれば）ＳＰＵ属性変更指示が与えられて、ＳＰＵ４４−ｉの属性が変更される。これにより、指定時刻には必要な分のサービス種別対応のＳＰＵ４４−ｉが事前に確保されることになる。
【００７１】
つまり、この場合、ＳＰＵ状態管理部４５ｃは、トラフィックの増大が予想される時間帯において呼毎にいちいちＳＰＵ属性変更処理を実行する必要がなく、呼処理の高速化を図ることが可能である。
なお、上述した時刻要因によるＳＰＵ属性変更指示についても、属性設定対象分のＳＰＵ４４−ｉ毎に繰り返し行なってもよいし、１回のＳＰＵ属性変更（設定）指示で複数分のＳＰＵ４４−ｉの属性変更（設定）を行なうようにしてもよい。
【００７２】
（２）運用中（呼毎）のＳＰＵ属性自動設定処理の説明
次に、以下では、サービス運用中のＡＴＭ交換機４の動作について説明する。まず、図１２に示すように、上位ノード５から或る呼についてのサービス要求（呼接続要求）が主制御部４５（呼制御部４５ａ）にて受信されると（ステップＤ１）、呼制御部４５ａが、その呼についての変換対象プロトコルの決定要求メッセージをサービス決定部４５ｂに出力する（ステップＤ２）。なお、上記のメッセージには、サービス種別を識別するための情報が含まれているものとする。
【００７３】
すると、サービス決定部４５ｂは、受信したメッセージに基づいて要求されたサービス種別（プロトコル）を識別し（ステップＤ３）、呼制御部４５ａに対してそのサービス種別に応じたＳＰＵ４４−ｉの捕捉要求を行ない（ステップＤ４）、この捕捉要求を受けた呼制御部４５ａは、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）に対して同様のＳＰＵ捕捉要求（ＩＤ＝２）を行なう（ステップＤ５）。
【００７４】
すると、ＳＰＵ状態管理受付部４５ｄは、受信した要求がＳＰＵ捕捉要求（ＩＤ＝２）なので、図１４に示すステップＳ１からステップＳ２０へ分岐して、図１８に示す処理手順（ＳＰＵ検索処理）を実行する（ステップＤ６）。
即ち、ＳＰＵ状態管理受付部４５ｄは、ＳＰＵ状態管理データ４５１をＳＰＵ論理番号＝“１”のＳＰＵ４４−ｉに対応するものから順番に参照して、要求サービス種別対応のＳＰＵ４４−ｉを検索する。なお、このとき、保守コンソール６から外部指定属性の設定が行なわれている場合は、外部指定属性データ４５１ｃに基づいて、そのＳＰＵ４４−ｉの属性が判断される。
【００７５】
具体的に、ＳＰＵ状態管理受付部４５ｄは、まず、ＳＰＵ状態管理データ４５１を参照して（ステップＳ２１）、参照中のＳＰＵ状態管理データ４５１が、ＳＰＵ論理番号が最終のデータか否かを確認する（ステップＳ２２）。
その結果、最終データでなければ、ＳＰＵ状態管理受付部４５ｄは、次に、ＳＰＵ状態データ４５１ａ〔図５（Ａ）参照〕を参照して、ＳＰＵ４４−ｉが空き状態であるか使用中であるかを確認し（ステップＳ２２のＮＯルートからステップＳ２３）、空き状態であれば、さらに、外部指定属性種別データ４５１ｂを参照して、外部指定属性種別データ４５１ｂとして「時刻対応」（＝“０”）が設定されているかを確認する（ステップＳ２３のＹＥＳルートからステップＳ２４）。
【００７６】
この結果、外部指定属性種別データ４５１ｂとして「時刻対応」（＝“０”）以外が設定されていれば、ＳＰＵ状態管理受付部４５ｄは、次に、外部指定属性データ４５１ｃを参照して、既に外部指定属性データ４５１ｃとして「外部指定済み」が設定されているか否かを確認する（ステップＳ２４のＮＯルートからステップＳ２５）。
【００７７】
その結果、「外部指定済み」であれば、ＳＰＵ状態管理受付部４５ｄは、さらに、要求サービス種別と外部指定属性データ４５１ｃとが一致しているか否かを確認し（ステップＳ２５のＹＥＳルートからステップＳ２６）、一致していれば、ＳＰＵ状態データ４５１ａを「使用中」（＝“１”）に更新する（ステップＳ２６のＹＥＳルートからステップＳ２７）。
【００７８】
次いで、ＳＰＵ状態管理受付部４５ｄは、外部指定属性データ４５１ｃとカレント属性データ４５１ｄとを参照して、外部指定属性とカレント属性とが一致しているか否かを確認し（ステップＳ２８）、一致していれば、外部指定属性指定済みで要求サービス種別と一致する空き状態のＳＰＵ４４−ｉが見つかったことになるので、そのＳＰＵ４４−ｉを上位ノード５からの上記呼接続要求に対する割り当て対象のＳＰＵ４４−ｉとして捕捉し、その旨を呼制御部４５ａに通知して処理を呼制御部４５ａに移行する（ステップＳ２８のＹＥＳルートからステップＳ２９；図１２のステップＤ９）。
【００７９】
即ち、呼制御部４５ａは、図１２に示すように、ＳＰＵ状態管理部４５ｃから上記の通知を受けると、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要求元の上位ノード５との間のスイッチング設定（コネクション設定）を行なって（ステップＤ１０）、呼の接続を行なったのち、呼の接続完了の旨を上位ノード５に通知する（ステップＤ１１）。
【００８０】
なお、上記のステップＳ２３においてＳＰＵ状態が空き状態でなかった場合（ステップＳ２３でＮＯと判定された場合）や、上記のステップＳ２６において要求サービス種別と外部指定属性とが一致しなかった場合（ステップＳ２６でＮＯと判定された場合）には、次のＳＰＵ論理番号のＳＰＵ状態管理データ４５１について上記ステップＳ２２からの処理が実行される。
【００８１】
ところで、上記のステップＳ２５において、外部指定属性データ４５１ｃに「指定無し」（＝“０”）が設定されていた場合（ステップＳ２５でＮＯと判定された場合）、ＳＰＵ状態管理受付部４５ｄは、次に、図１８に示すように、カレント属性データ４５１ｄを参照して、カレント属性と要求サービス種別とが一致しているかを確認する（ステップＳ３０）。
【００８２】
この結果、カレント属性と要求サービス種別とが一致していれば（ステップＳ３０でＹＥＳと判定されれば）、外部指定属性未指定（外部指定無し）でカレント属性が要求サービス種別と一致する空きＳＰＵ４４−ｉが見つかったことになるので、ＳＰＵ状態管理受付部４５ｄは、該当ＳＰＵ状態データ４５１ａを「使用中」（＝“１”）に更新して（ステップＳ３１）、そのＳＰＵ４４−ｉを上記呼接続要求に対する割り当て対象のＳＰＵ４４−ｉとして捕捉し、その旨を呼制御部４５ａに通知して処理を呼制御部４５ａに移行する（ステップＳ２９）。
【００８３】
そして、呼制御部４５ａは、この場合も、ＳＰＵ状態管理部４５ｃから上記の通知を受けると、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要求元の上位ノード５との間のスイッチング設定（コネクション設定）を行なって（ステップＤ１０）、呼の接続を行なったのち、呼の接続完了の旨を上位ノード５に通知する（ステップＤ１１）。
【００８４】
次に、上記のステップＳ２８においてＳＰＵ４４−ｉの外部指定属性とカレント属性とが一致しない場合（ステップＳ２８でＮＯと判定された場合）や、上記のステップＳ３０において要求サービス種別とＳＰＵ４４−ｉのカレント属性とが一致しない場合（ステップＳ３０でＮＯと判定された場合）、ＳＰＵ状態管理受付部４５ｄは、図２０に示すように、カレント属性データ４５１ｄを更新してその不一致を解消し（ステップＳ３２）、ＳＰＵ属性サービス変更部４５ｅに該当ＳＰＵ４４−ｉの属性変更を依頼する。
【００８５】
すると、ＳＰＵ属性変更部４５ｅは、該当ＳＰＵ４４−ｉに対して属性変更要求（要求サービス種別を含む）を行なう（ステップＳ３３；図１２のステップＤ７）。これにより、当該ＳＰＵ４４−ｉは、図１０により前述したように、フラッシュメモリ６６から要求サービス種別に対応するＣＰＵファームウェア６６２−ｋとＤＳＰファームウェア６６３−ｋとをそれぞれ読み出してロードすることにより、自身の属性を要求されたサービス種別対応（プロトコル属性）に変更する（図１２のステップＤ８）。
【００８６】
これにより、上述のごとく属性変更のなされたＳＰＵ４４−ｉが上記の呼接続要求に対する割り当てＳＰＵ４４−ｉとして捕捉されて、呼制御部４５ａに処理が移行する（ステップＳ３４）。即ち、呼制御部４５ａは、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要求元の上位ノード５との間のスイッチング設定（コネクション設定）を行なって（図１２のステップＤ１０）、呼の接続を行なったのち、呼の接続完了の旨を上位ノード５に通知する（図１２のステップＤ１１）。
【００８７】
ところで、前記のステップＳ２４（図１８参照）において外部指定属性種別データ４５１ｂとして「時刻対応」（＝“０”）が設定されていた場合（ステップＳ２４でＹＥＳと判定された場合）は、図２１に示すように、時刻要因属性変更部５２が、それまで参照していたＳＰＵ状態管理データ４５１のＳＰＵ論理番号をキーにして対応する時刻対応属性管理データ４５２を検索する（ステップＳ３５）。
【００８８】
そして、時刻対応属性管理データ４５２の中に現時刻の含まれる時間帯が指定時刻データ４５２ａによって設定されていれば、時刻要因属性変更部５２は、その指定時刻データ４５２ａに対応する時刻対応属性データ４５２ｂを参照して、要求サービス種別と時刻対応属性とが一致しているか否かを確認する（ステップＳ３６）。
【００８９】
この結果、要求サービス種別と時刻対応属性とが一致していれば（ステップＳ３６でＹＥＳと判定されれば）、時刻対応属性指定済みで要求サービス種別と一致する空き状態のＳＰＵ４４−ｉが見つかったことになるので、時刻要因属性変更部５２は、そのＳＰＵ４４−ｉに対応するＳＰＵ状態管理データ４５１のＳＰＵ状態データ４５１ａを使用中（＝“１”）に更新する（ステップＳ３７）。
【００９０】
次に、時刻要因属性変更部５２は、外部指定属性データ４５１ｃとカレント属性データ４５１ｄとを比較して、ＳＰＵ４４−ｉの外部指定属性とカレント属性とが一致しているか否かを確認し（ステップＳ３８）、一致していれば（ステップＳ３８でＹＥＳと判定されれば）、そのまま、対応するＳＰＵ４４−ｉを上記の呼接続要求に対する割り当てＳＰＵ４４−ｉとして捕捉して、処理を呼制御部４５ａに移行する（ステップＳ３９；図１２のステップＤ９〜Ｄ１１）。
【００９１】
一方、ＳＰＵ４４−ｉの外部指定属性とカレント属性とが一致していなければ（ステップＳ３８でＮＯと判定されれば）、図２０により前述したように、カレント属性が外部指定属性と一致するよう更新され、ＳＰＵサービス変更部４５ｅによって、該当ＳＰＵ４４−ｉの属性がカレント属性から外部指定属性に変更された上で、呼制御部４５ａに処理が移行する（ステップＳ３２〜Ｓ３４）。
【００９２】
なお、上記のステップＳ３６において、要求サービス種別と時刻対応属性とが一致していなかった場合（ステップＳ３６でＮＯと判定された場合）は、次のＳＰＵ論理番号のＳＰＵ状態管理データ４５１について、図１８により前述したステップＳ２２以降の処理が実行される。
以上のようにして、上位ノード５からの呼接続要求毎に、要求サービス種別に一致する属性をもつＳＰＵ４４−ｉが空き状態で既に存在すれば、そのＳＰＵ４４−ｉが、順次、割り当てＳＰＵ４４−ｉとして捕捉され、要求サービス種別に一致する属性をもつ空きＳＰＵ４４−ｉが存在しなければ（要求サービス種別対応のＳＰＵ４４−ｉが不足していれば）、空き状態のＳＰＵ４４−ｉの属性が要求サービス種別対応の属性に変更されて、割り当てＳＰＵ４４−ｉとして捕捉されてゆく。
【００９３】
例えば図２２（Ａ）に示すように、初期設定として、「音声」，「ＩＳＤＮ」，「パケット」，「ＰＩＡＦＳ」，「ＦＡＸ」，「モデム」，「ＰＰＰ」の各サービス種別対応のＳＰＵ４４−ｉの割り当て数を最小限〔図２２（Ａ）ではそれぞれ１枚〕にした場合は、残り（外部指定無しのＳＰＵ４４−ｉ：ＳＰＵ論理番号＝８〜３０）の属性を上述のごとく運用中（呼毎）に適宜に変更してゆくことで、不足分のサービス種別対応のＳＰＵ４４−ｉを充足することができる。
【００９４】
また、例えば図２２（Ｂ）に示すように、初期設定として、上記の各サービス種別対応のＳＰＵ４４−ｉの割り当て数を予測されるサービス種別毎のトラフィックに応じた割合〔図２２（Ｂ）では音声用５枚、ＩＳＤＮ用５枚、パケット用５枚、ＰＩＡＦＳ用２枚、ＦＡＸ用２枚、モデム用２枚、ＰＰＰ用２枚〕に設定した場合も、外部指定無しのＳＰＵ４４−ｉ（ＳＰＵ論理番号＝２４〜３０）、あるいは、初期設定（外部指定）で他サービス種別対応に設定されているものでも空き状態であればそのＳＰＵ４４−ｉの属性を運用中に適宜に変更してゆくことで、不足分のサービス種別対応のＳＰＵ４４−ｉを充足することができる。
【００９５】
なお、上記の図２２（Ａ）及び図２２（Ｂ）では、ＳＰＵ数＝３２、つまり、Ｎ＝３２の場合を例にしている。また、これらの図２２（Ａ）及び図２２（Ｂ）において、ＳＰＵ論理番号＝３１，３２の２枚のＳＰＵ４４−ｉ（網掛け部参照）は予備用として実装されたＳＰＵ４４−ｉで、他のＳＰＵ４４−ｉと同一構成を有している。従って、例えば、障害発生などによりどのサービス種別対応のＳＰＵ４４−ｉが使用不能になっても、そのＳＰＵ４４−ｉの代わりとして使用することが可能である。
【００９６】
次に、上記の呼接続が切断（解放）される場合の処理について説明する。
まず、図１３に示すように、上位ノード５から呼解放要求が送信され呼制御部４５ａにて受信されると（ステップＥ１）、呼制御部４５ａは、まず、該当ＳＰＵ４４−ｉと呼接続要求元の上位ノード５とのコネクション設定を解放し（ステップＥ２）、解放呼のために捕捉されていたリソース（ＳＰＵ４４−ｉ）の解放要求（ＳＰＵ解放要求：ＩＤ＝３）をＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５ｄ）に出力する（ステップＥ３）。
【００９７】
すると、ＳＰＵ状態管理受付部４５ｄは、受信した要求がＳＰＵ解放要求（ＩＤ＝３）なので、図１４に示すステップＳ１からステップＳ４０へ分岐して、図１９に示す処理手順（該当ＳＰＵ状態管理データ４５１の更新処理）を実行する（ステップＥ４）。
即ち、ＳＰＵ状態管理受付部４５ｄは、対象のＳＰＵ状態管理データ４５１を参照し（ステップＳ４１）、ＳＰＵ状態データ４５１ａを「空き」（＝“０”）に更新する（ステップＳ４２）。その後、ＳＰＵ状態管理受付部４５ｄは、同じＳＰＵ状態管理データ４５１の外部指定属性データ４５１ｃに「指定済み」（“０”以外の値）が設定されているか否かを確認する（ステップＳ４３）。
【００９８】
その結果、「指定無し」（＝“０”）が設定されていれば、ＳＰＵ解放処理が完了した旨を呼制御部４５ａに通知して（図１３のステップＥ７）、処理を呼制御部４５ａに移行する（ステップＳ４３のＮＯルートからステップＳ４５）。すると、呼制御部４５ａは、呼の解放が完了した旨を呼解放要求元の上位ノード５に通知して（図１３のステップＥ８）、呼解放処理を完了する。
【００９９】
一方、上記のステップＳ４３において外部指定属性データ４５１ｃに“０”以外の値が設定されて外部指定属性が「指定済み」になっていた場合、ＳＰＵ状態管理受付部４５ｄは、さらに、同じＳＰＵ状態管理データ４５１の外部指定属性データ４５１ｃとカレント属性データ４５１ｄとを参照して、外部指定属性とカレント属性とが一致しているか否かを確認する（ステップＳ４３のＹＥＳルートからステップＳ４４）。
【０１００】
この結果、外部指定属性とカレント属性とが一致していれば、外部指定属性が指定されていない場合（ステップＳ４３でＮＯと判定された場合）と同様にして、呼制御部４５ａに処理が移行し（ステップＳ４４のＹＥＳルートからステップＳ４５）、呼制御部４５ａから呼解放完了通知が上位ノード５に出力される（図１３のステップＥ７，Ｅ８）。
【０１０１】
一方、外部指定属性とカレント属性とが一致していなければ（ステップＳ４４でＮＯと判定された場合）、ＳＰＵ状態管理受付部４５ｄは、図２０により前述したステップＳ３２〜Ｓ３４の処理を実行することにより、カレント属性を更新して外部指定属性と一致させるとともに、ＳＰＵサービス変更部４５ｅによって、該当ＳＰＵ４４−ｉの属性を外部指定属性に変更（図１３のステップＥ５，Ｅ６）した上で、処理を呼制御部４５ａに移行する。即ち、呼制御部４５ａは、呼の解放が完了した旨を呼解放要求元の上位ノード５に通知して、呼解放処理を完了する（図１３のステップＥ７，Ｅ８）。
【０１０２】
このようにして、上位ノード５から呼の解放要求がある毎に、該当するＳＰＵ４４−ｉの捕捉が解放されるとともに、自動的に、その属性が、外部指定属性（デフォルト属性）の指定が有る場合にはその指定に応じた属性となり、外部指定属性の指定が無い場合には捕捉時の属性に維持される。
以上説明したように、本実施形態のＡＴＭ交換機（ＭＰＥ）４によれば、複数種類のサービス種別に対応した複数のプログラム（ＣＰＵファームウェア及びＤＳＰファームウェア）を１枚のパッケージに搭載したＳＰＵ４４−ｉに対して、上位ノード５が要求した、つまり、ユーザ（加入者）が指定したサービス種別対応のプログラムをＳＰＵ状態管理部４５ｃからの制御によってロードさせることで、呼毎に任意のＳＰＵ４４−ｉを要求サービス種別対応のものにフレキシブルに変更・捕捉することができる。
【０１０３】
従って、従来のようにサービス種別毎に専用のＳＰＵを実装する場合、即ち、サービス種別毎のＳＰＵ割り当て数が固定である場合に比して、大幅にＳＰＵ４４−ｉの必要実装数を削減することができて、ＡＴＭ交換機４の大幅な小型化を図ることが可能である。
また、ＡＴＭ交換機４の製造元（メーカ）にとっては、サービス種別毎に専用のＳＰＵを製造する必要がないので、多品種の製造及びメンテナンスから少品種の製造及びメンテナンスに移行することができ、コストダウン及び保守の品質向上を図ることができる。
【０１０４】
さらに、或るサービス種別対応のトラフィックが増加してそのサービス種別対応のＳＰＵ４４−ｉが不足するような場合でも、空きＳＰＵ４４−ｉを不足分のサービス種別対応のＳＰＵ４４−ｉとして使用することができる、つまり、実装されたＳＰＵ４４−ｉ全体でサービス種別に依存せずに全トラフィックを吸収することができるので、サービス種別毎に専用のＳＰＵを実装する場合に比して、トラフィックの許容量が大きくなり、呼損率を極めて低く抑えることができる。この結果、ユーザにとっては、接続性が大幅に向上することになる。
【０１０５】
また、ＡＴＭ交換機４の建局時におけるＳＰＵ実装数の算出根拠について、ＡＴＭ交換機４のトラフィック量を推定するだけでよく、通常、実施されている各サービス種別対応のＳＰＵ毎の周辺上位ノードからの要求トラフィック量の分析は不要となる。さらに、運用状態となった場合でも、各サービス毎のメンテナンスは不要となり、ピーク時のトラフィックに対するＳＰＵ４４−ｉの過不足の対応のみでよいことになる。
【０１０６】
また、時刻要因によるＳＰＵ属性変更指示により、指定時刻に、指定したサービス種別対応のＳＰＵ４４−ｉとして動作するようにＳＰＵ４４−ｉの属性変更を実施することができるので、時間毎に特定のサービス種別対応のＳＰＵ４４−ｉを事前に確保しておくことができる。
従って、例えば、一般企業の業務開始時や昼休み終了時，電話やインターネットでのチケット予約販売など、特定の日時に大量のトラフィックの発生が想定される特異なケースでも、ＳＰＵ実装数を従来よりも大幅に削減しながら、呼損率を最小限に抑制することができる。
【０１０７】
（３）その他
なお、上述した実施形態では、マルチメディア信号処理装置がＡＴＭ交換機として構成されている場合を例にしたが、本発明は、これに限定されず、他の種類の交換装置や呼処理装置として構成されていても、上述した実施形態と同様の作用効果が得られる。
【０１０８】
また、上述した実施形態では、保守コンソール６からＡＴＭ交換機４に対してＳＰＵ属性変更指示などの各種設定を行なっているが、勿論、他の任意の制御装置から行なうようにしてもよい。
さらに、上述した実施形態のＳＰＵ４４−ｉは、複数種類のサービス種別に応じた複数種類のプログラム（ファームウェア）を選択的にＣＰＵ６５及びＤＳＰモジュール６８−ｊにロードする構成を採ることで、複数種類のサービス種別対応のＳＰＵ４４−ｉを実現しているが、複数種類のサービス種別対応のＳＰＵ４４−ｉが実現できれば、必ずしもこのような構成を採る必要はない。
【０１０９】
例えば、予め複数種類のサービス種別に対応したＤＳＰモジュールを用意するなど、サービス種別に応じた複数の信号処理手段を用意しておき、要求サービス種別に応じてこれらの信号処理手段のいずれかを単純に選択するという構成を採っても良い。ただし、上述した実施形態の構成を採った方が、前述したように、実装すべきＤＳＰモジュール数をサービス種別数よりも少なくすることができるので有利である。
【０１１０】
また、上述した例では、便宜上、１枚のＳＰＵ４４−ｉが１チャンネル分の呼を処理できる構成になっていることを前提にして説明したが、１枚のＳＰＵ４４−ｉが複数チャンネル分の呼を処理できるだけの能力を有している場合には、次のようなアルゴリズムを追加することで対応可能である。
即ち、上位ノード５からの要求サービス種別と一致する属性のＳＰＵ４４−ｉを検索する際、まず、要求サービス種別と一致し呼処理能力に余裕のあるＳＰＵ４４−ｉを検索し、この条件を満足するＳＰＵ４４−ｉが存在すれば、そのＳＰＵ４４−ｉをサービス要求に対して割り当てるべきＳＰＵ４４−ｉとして捕捉する。一方、上記の条件を満足するＳＰＵ４４−ｉが存在しなければ、「空き状態」（呼が割り当てられていない待機状態）の他のＳＰＵ４４−ｉの属性を変更した上で、そのＳＰＵ４４−ｉサービス要求に対して割り当てるべきＳＰＵ４４−ｉとして捕捉する。
【０１１１】
このようなアルゴリズムにより、上位ノード５からのサービス要求毎に、要求サービス種別と一致し処理能力に余裕のあるＳＰＵ４４−ｉに、新たな呼が割り当てられてゆき、要求サービス種別と一致し処理能力に余裕のあるＳＰＵ４４−ｉが存在しなくなると、新たに要求サービス種別対応の空きＳＰＵ４４−ｉが捕捉されて呼が割り当てられてゆくことになる。
【０１１２】
そして、本発明は、上述した実施形態に限定されるものではなく、上記以外にも本発明の趣旨を逸脱しない範囲で種々変形して実施することができる。
【０１１３】
【発明の効果】
以上詳述したように、本発明のマルチメディア信号処理装置によれば、通信サービスユニットの信号処理モードが、呼のサービス種別に適したモードに制御されるので、予めサービス種別毎に最大トラフィックをカバーできるだけの専用の通信サービスユニットを実装しておく必要がない。また、或るサービス種別のトラフィックに対して通信サービスユニットが不足した場合でも、他のサービス種別に適したモードで動作していた他の通信サービスユニットのモードを不足の生じたサービス種別対応のモードに変更することで、不足分を充足することができる。従って、次のような利点（１）〜（４）が得られる。
【０１１４】
（１）サービス種別毎に専用の通信サービスユニットを実装する場合、即ち、サービス種別毎の通信サービスユニット割り当て数が固定である場合に比して、通信サービスユニットの必要実装数を大幅に削減することができて、本装置の大幅な小型化を図ることが可能である。
（２）本装置の製造元にとっては、サービス種別毎に専用の通信サービスユニットを製造する必要がないので、多品種の製造及びメンテナンスから少品種の製造及びメンテナンスに移行することができ、コストダウン及び保守の品質向上を図ることができる。
【０１１５】
（３）通信サービスユニットがサービス種別に依存しないので、サービス種別毎に専用の通信サービスユニットを実装する場合に比して、トラフィックの許容量が大きくなり、呼損率を低く抑えることができる。この結果、ユーザにとっては、接続性が大幅に向上することになる。
（４）本装置の建局時における通信サービスユニット実装数の算出根拠について、トラフィック量を推定するだけでよく、通常、実施されている各サービス種別毎の周辺上位ノードからの要求トラフィック量の分析は不要となる。また、運用状態となった場合でも、各サービス毎のメンテナンスは不要となり、ピーク時のトラフィックに対する通信サービスユニットの過不足の対応のみで済む。
【０１１６】
なお、上記のモード制御は、外部装置からのモード設定指示に応じて適宜に設定・変更することもできるので、通信サービスユニットのフレキシブルな使用が可能になる。また、上記のモード制御は、過去のモード制御についての履歴に基づいて、或る時期のトラフィック傾向を予測し、その予測に応じて実施することもできるので、さらなる通信サービスユニットの実装数削減および呼損率の低減に大きく寄与する。
【０１１７】
ここで、上記の予測型のモード制御では、或る特定の時間帯に特定のサービス種別のトラフィックが増大することが事前に分かっている場合などにおいて、その時間帯には通信サービスユニットのモードをそのサービス種別に適したモードに設定するといった時刻要因による制御を行なうこともできるので、時間毎に特定のサービス種別対応の通信サービスユニットを事前に確保しておくことができ、さらに呼損率の低減を図ることができる。
【０１１８】
ところで、上記の通信サービスユニットは、複数種類の通信サービス種別に応じた複数種類の通信サービス制御プログラムの中から、信号処理モード制御指示に応じて対応するプログラムを選択的にロードすることにより、自身の信号処理モードを制御するようにしてもよく、このようにすれば、複数種類の通信サービス制御回路を個別にそなえる場合に比して、最小限のハードウェア規模で、複数種類の通信サービス種別に対応可能な通信サービスユニットを実現することができ、本マルチメディア信号処理装置をさらに小型に実現できる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る移動体通信網の構成を示すブロック図である。
【図２】本発明の一実施形態に係るマルチメディア信号処理装置としてのＡＴＭ交換機の構成を示すブロック図である。
【図３】図２に示すＡＴＭ交換機の要部に着目した構成を示すブロック図である。
【図４】図３に示すＳＰＵ状態管理部の構成を示すブロック図である。
【図５】（Ａ）は本実施形態に係るＳＰＵ状態管理データの一例を示す図、（Ｂ）は本実施形態に係る時刻対応属性管理データの一例を示す図である。
【図６】本実施形態に係る履歴情報（統計情報）の一例を示す図である。
【図７】図２及び図３に示すＳＰＵの詳細構成例を示すブロック図である。
【図８】図７に示すフラッシュメモリの記憶内容及びフラッシュメモリからのロード動作を説明するための図である。
【図９】本実施形態のＡＴＭ交換機の動作（ＳＰＵ属性変更手順）を説明するためのシーケンス図である。
【図１０】本実施形態のＳＰＵの動作を説明するためのシーケンス図である。
【図１１】本実施形態のＡＴＭ交換機の動作（時刻要因によるＳＰＵ属性変更手順）を説明するためのシーケンス図である。
【図１２】本実施形態のＡＴＭ交換機の動作（呼毎のＳＰＵ属性自動設定処理手順）を説明するためのシーケンス図である。
【図１３】本実施形態のＡＴＭ交換機の動作（捕捉ＳＰＵの解放処理手順）を説明するためのシーケンス図である。
【図１４】図２及び図３に示すＳＰＵ状態管理部の動作を説明するためのフローチャートである。
【図１５】図２及び図３に示すＳＰＵ状態管理部の動作を説明するためのフローチャートである。
【図１６】図２及び図３に示すＳＰＵ状態管理部の動作（非時刻要因ＳＰＵ属性変更手順）を説明するためのフローチャートである。
【図１７】図２及び図３に示すＳＰＵ状態管理部の動作（時刻要因ＳＰＵ属性変更手順）を説明するためのフローチャートである。
【図１８】図２及び図３に示すＳＰＵ状態管理部の動作（ＳＰＵ捕捉要求時）を説明するためのフローチャートである。
【図１９】図２及び図３に示すＳＰＵ状態管理部の動作（ＳＰＵ解放要求時）を説明するためのフローチャートである。
【図２０】図２及び図３に示すＳＰＵ状態管理部の動作（ＳＰＵ属性変更手順）を説明するためのフローチャートである。
【図２１】図２及び図３に示すＳＰＵ状態管理部の動作（時刻要因指定有りの場合）を説明するためのフローチャートである。
【図２２】（Ａ），（Ｂ）はいずれもＳＰＵの初期設定（サービス種別毎のＳＰＵ割り当て割合）を説明するための図である。
【図２３】既存の公衆交換網（トリー型網）の一例を模式的に示す図である。
【図２４】マルチメディア信号処理装置（交換装置）の一例を示すブロック図である。
【符号の説明】
１ 移動局（ＭＳ：Mobile Station）
２ 無線基地局（ＢＴＳ：Base Transceiver Station）
３ 無線ネットワーク制御装置（ＲＮＣ： Radio Network Controller）
４ マルチメディア信号処理装置〔ＭＰＥ（Multimedia signal Processing Equipment）；ＡＴＭ（Asynchronous Transfer Mode）交換機〕
５ 移動マルチメディア交換システム〔ＭＭＳ（Mobile Multimedia switching System）；上位ノード〕
６ オペレーションシステム〔ＯＰＳ（Operation System）；保守コンソール（外部装置）〕
７ａ ＡＴＭ網
７ｂ ＬＡＮ（Local Area Network）
１０ 移動体通信網
４１ ＡＴＭスイッチ
４２ ＡＴＭインタフェース（ＡＴＭ−ＩＦ）
４３ ＬＡＮ（Local Area Network）インタフェース（ＬＡＮ−ＩＦ）
４４−１〜４４−Ｎ ＳＰＵ（Service Protocol Unit；通信サービスユニット）
４５ 主制御部
４５ａ 呼制御部
４５ｂ サービス決定部（通信サービス種別識別手段）
４５ｃ ＳＰＵ状態管理部（モード制御手段）
４５ｄ ＳＰＵ状態管理受付部
４５ｅ ＳＰＵサービス変更部
５２ 履歴情報管理部
５３ 時刻要因属性変更部
６０ａ 制御系ネットワーク
６０ｂ 通信系ネットワーク（セルバス）
６１ 通信系インタフェース（ＩＦ）回路
６２ 制御系インタフェース（ＩＦ）回路
６３ 通信用デュアルポートＲＡＭ
６４ ＳＡＲ（Structure And Restructure）部
６５ ＣＰＵ〔ＳＰＵ属性変更部（モード選択制御部）〕
６６ フラッシュメモリ（記憶部）
６７ ＲＡＭ
６８−１〜６８−ｍ ＤＳＰ（Digital Signal Processor）モジュール
６９ ＩＰＬ（Initial Program Load）メモリ（ＲＡＭ）
７０ プログラムメモリ（ＲＡＭ）
１００ 公衆交換網
１３０ 集中局
１４０ 端局
４５１ ＳＰＵ状態管理データ
４５１ａ ＳＰＵ状態データ
４５１ｂ 外部指定属性種別データ
４５１ｃ 外部指定属性データ
４５１ｄ カレント属性データ
４５２ 時刻対応属性管理データ
４５２ａ 指定時刻データ
４５２ｂ 時刻対応属性データ
４５３ 統計情報（履歴情報）
６６１ ＩＰＬ領域
６６２ ＣＰＵファームウェア領域
６６３ ＤＳＰファームウェア領域
６６２−１ パケット用ＣＰＵファームウェア
６６２−２ 音声用ＣＰＵファームウェア
６６２−３ ＩＳＤＮ（Integrated Services Digital Network）用ＣＰＵファームウェア
６６２−４ ＰＩＡＦＳ（PHS Internet Access Forum Standard）用ＣＰＵファームウェア
６６２−５ ＰＰＰ（Point to Point Protocol）用ＣＰＵファームウェア
６６２−６ ＦＡＸ用ＣＰＵファームウェア
６６２−７ モデム用ＣＰＵファームウェア
６６２−８，６６３−８ 予備のファームウェア
６６３−１ パケット用ＤＳＰファームウェア
６６３−２ 音声用ＤＳＰファームウェア
６６３−３ ＩＳＤＮ用ＤＳＰファームウェア
６６３−４ ＰＩＡＦＳ用ＤＳＰファームウェア
６６３−５ ＰＰＰ用ＤＳＰファームウェア
６６３−６ ＦＡＸ用ＤＳＰファームウェア
６６３−７ モデム用ＤＳＰファームウェア
Claims (4)
- 複数種類のサービス種別に応じた複数種類の信号処理モードを有するサービスユニットと、
上位ノードから通知される或る呼についての信号処理要求情報に基づいて該呼のサービス種別を識別するサービス種別識別手段と、
前記呼のサービス種別のトラフィックに対してサービスユニットが不足した場合でも、他のサービス種別に適したモードで動作していた他のサービスユニットのモードを不足の生じたサービス種別対応のモードに変更する制御手段と、を有する、
ことを特徴とする、マルチメディア信号処理装置。 - 複数種類の通信サービス種別に応じた複数種類の信号処理モードを有する通信サービスユニットと、
上位ノードから通知される或る呼についての信号処理要求情報に基づいて該呼の通信サービス種別を識別する通信サービス種別識別手段と、
該通信サービスユニットの信号処理モードを該通信サービス種別識別手段で識別された通信サービス種別に適したモードに制御するモード制御手段と、をそなえ、
該モード制御手段が、
過去に行なったモード制御についての履歴情報を管理する履歴情報管理手段と、
該履歴情報に基づいて該通信サービスユニットの信号処理モードを予測制御する予測型モード制御手段と、を有する、
ことを特徴とする、マルチメディア信号処理装置。 - 該予測型モード制御手段が、
該履歴情報に基づいた時刻情報とモード設定情報とに基づいて、指定時刻に該通信サービスユニットのモードを該モード設定情報に応じたモードに制御する時刻要因モード制御手段をそなえていることを特徴とする、請求項２記載のマルチメディア信号処理装置。 - 該通信サービスユニットが、
該複数種類の通信サービス種別に応じた複数種類の通信サービス制御プログラムを記憶した記憶手段と、
該モード制御手段からの信号処理モード制御指示に応じて対応する通信サービス制御プログラムを該記憶手段から選択的にロードすることにより、自身の信号処理モードを制御するモード選択制御手段とをそなえて構成されたことを特徴とする、請求項１〜３のいずれか１項に記載のマルチメディア信号処理装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000240253A JP4246356B2 (ja) | 2000-08-08 | 2000-08-08 | マルチメディア信号処理装置 |
| US09/801,548 US6978145B2 (en) | 2000-08-08 | 2001-03-08 | Multimedia signal processing apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000240253A JP4246356B2 (ja) | 2000-08-08 | 2000-08-08 | マルチメディア信号処理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002057792A JP2002057792A (ja) | 2002-02-22 |
| JP4246356B2 true JP4246356B2 (ja) | 2009-04-02 |
Family
ID=18731645
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000240253A Expired - Fee Related JP4246356B2 (ja) | 2000-08-08 | 2000-08-08 | マルチメディア信号処理装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6978145B2 (ja) |
| JP (1) | JP4246356B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2365681A1 (en) * | 2001-12-19 | 2003-06-19 | Alcatel Canada Inc. | System and method for managing information for elements in a communication network |
| US20030167345A1 (en) * | 2002-02-25 | 2003-09-04 | Knight Alexander N. | Communications bridge between a vehicle information network and a remote system |
| US7116943B2 (en) * | 2002-04-22 | 2006-10-03 | Cognio, Inc. | System and method for classifying signals occuring in a frequency band |
| FI20021314A0 (fi) | 2002-07-03 | 2002-07-03 | Nokia Corp | Tiedonsiirtomenetelmä ja järjestely |
| US7171161B2 (en) * | 2002-07-30 | 2007-01-30 | Cognio, Inc. | System and method for classifying signals using timing templates, power templates and other techniques |
| JP3987460B2 (ja) | 2003-04-22 | 2007-10-10 | 株式会社日立コミュニケーションテクノロジー | 無線通信装置及び無線通信網 |
| US7310519B2 (en) | 2003-04-22 | 2007-12-18 | Hitachi Communication Technologies, Ltd. | Wireless communication apparatus, wireless communication network and software upgrading method |
| US7406310B2 (en) | 2003-04-22 | 2008-07-29 | Hitachi Communication Technologies, Ltd. | Network management apparatus and method of selecting base station for software update |
| JP4805622B2 (ja) * | 2005-07-12 | 2011-11-02 | 株式会社日立製作所 | 網管理装置 |
| WO2007134108A2 (en) * | 2006-05-09 | 2007-11-22 | Cognio, Inc. | System and method for identifying wireless devices using pulse fingerprinting and sequence analysis |
| JP4805969B2 (ja) * | 2008-04-09 | 2011-11-02 | 株式会社日立製作所 | ソフトウェア更新日時決定方法 |
| JP2015149578A (ja) * | 2014-02-06 | 2015-08-20 | 株式会社日立製作所 | 運用管理装置 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5555444A (en) * | 1994-03-11 | 1996-09-10 | Motorola, Inc. | Method and apparatus for predictive operation of a communication system |
| US5664006A (en) * | 1995-06-07 | 1997-09-02 | Globalstar L.P. | Method for accounting for user terminal connection to a satellite communications system |
| US6119006A (en) * | 1997-01-03 | 2000-09-12 | Siemens Information And Communication Systems, Inc. | System and method for calendar-based cellular smart switching |
| US5974328A (en) * | 1997-01-13 | 1999-10-26 | Airtouch Communications, Inc. | Rapid system access and registration in mobile phone systems |
| US6223042B1 (en) * | 1997-06-26 | 2001-04-24 | At&T Wireless Services Inc | Method of intelligent roaming using network information |
| JP3893696B2 (ja) * | 1997-10-24 | 2007-03-14 | カシオ計算機株式会社 | 通信端末装置 |
| US6256487B1 (en) * | 1998-09-01 | 2001-07-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Multiple mode transmitter using multiple speech/channel coding modes wherein the coding mode is conveyed to the receiver with the transmitted signal |
| US6603755B1 (en) * | 1999-05-14 | 2003-08-05 | Ericsson Inc. | Mobile terminals, methods, and computer program products that can facilitate the selection of a communication service provider in a multiple communications mode environment |
-
2000
- 2000-08-08 JP JP2000240253A patent/JP4246356B2/ja not_active Expired - Fee Related
-
2001
- 2001-03-08 US US09/801,548 patent/US6978145B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002057792A (ja) | 2002-02-22 |
| US20020028695A1 (en) | 2002-03-07 |
| US6978145B2 (en) | 2005-12-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7593321B2 (en) | Method and system for a local and fast non-disruptive path switching in high speed packet switching networks | |
| CN102084705B (zh) | 通信网络中的动态负载平衡 | |
| US8565070B2 (en) | System and method for active geographic redundancy | |
| JP4246356B2 (ja) | マルチメディア信号処理装置 | |
| US6608831B1 (en) | Breakout/break-in hybrid network system | |
| EP0471379A2 (en) | Packet switching method and system with self-routing switch | |
| CN101529825A (zh) | 用于结合的用户管理和呼叫控制的***和方法 | |
| CN101444122B (zh) | 用于活动地理冗余的***和方法 | |
| JP2000312226A (ja) | 通信品質を保証する方法 | |
| US20020194316A1 (en) | Methods and systems to generate and implement a changeover sequence to reconfigure a connection-oriented network | |
| US20240049102A1 (en) | State pooling for stateful re-homing in a disaggregated radio access network | |
| JP3658704B2 (ja) | 遠隔通信接続に関連したアプリケーションを処理装置により実行する方法および装置 | |
| JP2000253072A (ja) | 交換システム及び交換制御方法 | |
| CN100576863C (zh) | 动态资源管理方法及其媒体网关和媒体网关控制器 | |
| US6674722B1 (en) | Processes in a distributed multiprocessor system | |
| JP4090738B2 (ja) | スイッチング方法及びネットワーク要素 | |
| JP3252831B2 (ja) | Ａｔｍにおけるｉｐパケットルーティングプロセッサの分散処理方法及びその装置 | |
| JP3049301B2 (ja) | コネクション型通信網での障害回復方式および輻輳回復方式 | |
| JP2002314578A (ja) | 無線基地局、無線通信システム、ユーザプロファイル格納装置。 | |
| KR100436433B1 (ko) | 이동통신 시스템에서 제어국내 개방형 구조의비동기전송모드 스위치 제어 방법 | |
| KR100309382B1 (ko) | 멀티 프로토콜 라벨 스위칭 시스템 및 그의 초기화 방법 | |
| JP3633479B2 (ja) | 高速通信システム及び通信帯域の時間貸し方法 | |
| EP1678874A1 (en) | Method and apparatus for performing routing operations in communications network | |
| KR100248414B1 (ko) | 이기종망상의정보제공자접속을위한다단계호접속방법 | |
| JP2000244582A (ja) | 通信制御方法及び通信制御装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060222 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080225 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080603 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080724 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081014 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081112 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081224 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090108 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120116 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130116 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130116 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140116 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |