JP2002057792A

JP2002057792A - マルチメディア信号処理装置

Info

Publication number: JP2002057792A
Application number: JP2000240253A
Authority: JP
Inventors: Tadashi Takaba; 正高場; Seishi Shigyo; 聖之執行; Yukimichi Takahira; 幸理高比良; Junji Sato; 淳児佐藤; Kusuo Yonezawa; 九州男米沢; Hidetoshi Kawakami; 英利川上; Koji Kawase; 浩司河瀬; Hiroshi Ito; 寛伊藤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-08-08
Filing date: 2000-08-08
Publication date: 2002-02-22
Anticipated expiration: 2020-08-08
Also published as: JP4246356B2; US20020028695A1; US6978145B2

Abstract

(57)【要約】【課題】交換装置などのマルチメディア信号処理装置
において、呼毎に通信サービスユニットの信号処理モー
ドをその呼のサービス種別に適したモードに変更できる
ようにすることで、通信サービスユニットの実装数を大
幅に削減するとともに、呼損率を大幅に低減できるよう
にする。【解決手段】複数種類の通信サービス種別に応じた複数
種類の信号処理モードを有する通信サービスユニット４
４−１〜４４−Ｎと、上位ノード５から通知される或る
呼についての信号処理要求情報に基づいて呼の通信サー
ビス種別を識別する通信サービス種別識別手段４５ｂ
と、通信サービスユニット４４−ｉ（ｉ＝１〜Ｎ）の信
号処理モードを通信サービス種別識別部４５ｂで識別さ
れた通信サービス種別に適したモードに制御するモード
制御手段４５ｃとをそなえるように構成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチメディア信
号処理装置に関し、例えば、一般的な公衆交換網や移動
体（無線）通信網を構成するノード（上位ノード）に接
続される交換装置など、上位ノードとの間で送受される
信号（マルチメディア信号）に対して所要の信号処理を
通信サービス種別に応じて行なう必要のある一装置に用
いて好適な、マルチメディア信号処理装置に関する。

【０００２】

【従来の技術】図２３は既存の公衆交換網の一例を模式
的に示す図で、この図２３に示すように、通常、公衆交
換網（以下、単に「公衆網」という）１００は、全国の
加入者端末（電話機やパーソナルコンピュータ，ファク
シミリなど）をそれぞれ近隣地域に設置された交換装置
（交換局；ノード）に収容し、各地域の交換局を全てメ
ッシュ状に接続することで構築するのは経済的ではない
ので、「トリー型網」と呼ばれる階層構造を基本として
構築される。

【０００３】即ち、日本の場合を例にすると、全国は、
総括局（ＲＣ）１１０が１台ずつ置かれるいくつかの大
きな区域（総括局区域；ＲＡ）１０１に分割され、さら
に、各総括局区域１０１は、それぞれ、中心局（ＤＣ）
１２０が１台ずつ置かれる中心局区域（ＤＡ）１０２に
分割され、各中心局区域１０２は、それぞれ、集中局
（ＴＣ）１３０が１台ずつ置かれる集中局区域（ＴＡ）
１０３に分割され、各集中局区域１０３は、それぞれ、
端局（ＥＯ）１４０が置かれる端局区域１０４に分割さ
れる。

【０００４】そして、下位階層の局がそれぞれ上位階層
の局にスター型網で接続される（例えば、端局１４０は
集中局１３０に、集中局１３０は中心局１２０に、中心
局１２０は総括局１１０にそれぞれ収容される）ととも
に、総括局１１０同士が基幹回線を介して接続されるこ
とで、公衆網１００が構築されるのである。このような
構成を採ることで、既存の公衆網１００では、例えば、
東京−大阪間などの長距離市外通話の場合には、端局１
４０を起点として集中局１３０，中心局１２０，総括局
１１０という順に段階的に呼を集めて目的（着信先）の
端局１４０を含む総括局１１０へ伝送すること、即ち、
「トリー型網」に沿った呼の集配信が行なわれることに
より、効率的な呼の伝送が可能になっている。

【０００５】ところで、上位階層の局（上位ノード）に
接続された交換装置に対する呼接続要求などのサービス
要求（信号処理要求）には、例えば、音声通信やパケッ
ト通信，ＩＳＤＮ利用のデータ通信，ファクシミリ（Ｆ
ＡＸ）通信などの各種の通信サービス形態に応じた複数
種類のサービス種別があり、また、呼毎にそのサービス
種別も不定である。なお、「サービス種別」とは、通信
サービスに固有の通信プロトコルの種別を意味する。

【０００６】そして、このような様々なサービス種別の
信号（マルチメディア信号）を交換装置で扱う必要があ
る場合、その交換装置は、マルチメディア信号の処理が
可能な装置（マルチメディア信号処理装置）としても機
能する必要があるため、例えば図２４に示すように、サ
ービス種別（＃Ａ，＃Ｂ，＃Ｃなどと表わす）毎に各サ
ービス種別に専用のパッケージ（ＰＫＧ）２００が、各
サービス種別毎に予測される最大トラフィック（最大呼
数）をカバーできる分だけ実装されて、上位ノード４０
０からのサービス要求毎にそのサービス種別に対応する
パッケージ２００が選択され、サービス要求のあった呼
に対する呼処理（信号処理）が実施されるようになって
いる。

【０００７】即ち、例えば、上位ノード４００からサー
ビス種別＃Ａについてのサービス要求があれば、交換装
置は、主制御部３００における呼制御部３０１の制御の
下で、サービス決定部３０２によって、受信したサービ
ス要求に含まれる情報から呼のサービス種別＃Ａを判断
／決定し、パッケージ実装状態管理部３０３にて管理さ
れているパッケージ実装状態管理データ３３０に基づい
て、サービス種別＃Ａ用のパッケージ２００のうち空き
状態のパッケージ２００を、例えば、いわゆる入側トラ
ンク／出側トランクなどとして選択（捕捉）して呼処理
を行なう。

【０００８】なお、他のサービス種別＃Ｂや＃Ｃについ
てのサービス要求があった場合も同様に、対応するサー
ビス種別＃Ｂ，＃Ｃ用の空きパッケージ２００が捕捉さ
れて呼処理が実行される。

【０００９】

【発明が解決しようとする課題】しかしながら、上述し
たような構成では、上位ノード４００からのサービス要
求に対応するパッケージ２００がサービス種別毎に固定
であるため、予測される最大トラフィックをカバーでき
る分のパッケージ２００を予め実装しておかなければな
らず、交換装置の規模が増大してしまうという課題があ
る。しかも、最大トラフィックを超える量の呼（過負荷
トラフィック）が発生した場合には、上記の構成及び処
理では、呼損の発生が余儀なくされていた。

【００１０】本発明は、このような課題に鑑み創案され
たもので、呼毎にパッケージ（通信サービスユニット）
の信号処理モードをその呼のサービス種別に適したモー
ドに変更できるようにすることで、パッケージの実装数
を大幅に削減するとともに、呼損率を大幅に低減できる
ようにした、マルチメディア信号処理装置を提供するこ
とを目的とする。

【００１１】

【課題を解決するための手段】上記の目的を達成するた
めに、本発明のマルチメディア信号処理装置は、複数種
類の通信サービス種別に応じた複数種類の信号処理モー
ド（以下、単に「モード」ともいう）を有する通信サー
ビスユニットと、上位ノードから通知される或る呼につ
いての信号処理要求に基づいてその呼の通信サービス種
別を識別する通信サービス種別識別手段と、上記の通信
サービスユニットの信号処理モードを上記通信サービス
種別識別部で識別された通信サービス種別に適したモー
ドに制御するモード制御手段とをそなえて成ることを特
徴としている。

【００１２】上述のごとく構成された本発明のマルチメ
ディア信号処理装置では、通信サービスユニットの信号
処理モードが、呼のサービス種別に適したモードに制御
されるので、予め最大トラフィックをカバーできるだけ
の通信サービスユニットを実装しておく必要がない。ま
た、或るサービス種別のトラフィックに対して通信サー
ビスユニットが不足した場合でも、他のサービス種別に
適したモードで動作していた他の通信サービスユニット
のモードを不足の生じたサービス種別対応のモードに変
更することで、不足分を充足することができる（以上、
請求項１）。

【００１３】なお、上記のモード制御手段は、外部装置
からのモード設定指示に応じて上記通信サービスユニッ
トの信号処理モードを制御する外部指示型モード制御手
段をそなえていてもよい。このような構成を採れば、通
信サービスユニットのモードを外部装置から適宜に設定
・変更することができる（請求項２）。また、上記のモ
ード制御手段は、過去に行なったモード制御についての
履歴情報を管理する履歴情報管理手段と、前記の履歴情
報に基づいて上記の通信サービスユニットの信号処理モ
ードを予測制御する予測型モード制御手段とをそなえて
いてもよい。このような構成を採れば、通信サービスユ
ニットのモードを過去のモード制御についての履歴に基
づいて、或る時期のトラフィック傾向を予測して、その
予測に応じたモード制御を実施することができる（請求
項３）。

【００１４】ここで、上記の予測型モード制御手段に
は、上記の履歴情報に基づいた時刻情報とモード設定情
報とに基づいて、指定時刻に通信サービスユニットのモ
ードを上記のモード設定情報に応じたモードに制御する
時刻要因モード制御手段をそなえていてもよい。このよ
うな構成を採れば、例えば、或る特定の時間帯に特定の
サービス種別のトラフィックが増大することが事前に分
かっている場合などにおいて、その時間帯には通信サー
ビスユニットのモードをそのサービス種別に適したモー
ドに設定するといった制御が可能になる（請求項４）。

【００１５】また、上記の通信サービスユニットは、複
数種類の通信サービス種別に応じた複数種類の通信サー
ビス制御プログラムを記憶した記憶手段と、上記のモー
ド制御手段からの信号処理モード制御指示に応じて対応
する通信サービス制御プログラムを上記記憶手段から選
択的にロードすることにより、自身の信号処理モードを
制御するモード選択制御手段とをそなえて構成されてい
てもよい。

【００１６】このようにすれば、複数種類の通信サービ
ス制御回路を個別にそなえる場合に比して、最小限のハ
ードウェア規模で、複数種類の通信サービス種別に対応
可能な通信サービスユニットを実現することができる
（請求項５）。

【００１７】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態を説明する。図１は本発明の一実施形態に係る
移動体通信網の構成を示すブロック図で、この図１に示
す移動体通信網１０は、移動局（ＭＳ：Mobile Statio
n）１，複数の無線基地局（ＢＴＳ：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 Pro
tocol）／ＩＰ（Internet Protocol）通信〕ファクシミリ（ＦＡＸ）通信サービスモデム（ＭＯＤＥＭ）利用のデータ通信サービスなお、以下において、上記の音声通話サービスを「音
声」、パケット通信サービスを「パケット」、ＩＳＤＮ
利用の通信サービスを「ＩＳＤＮ」、ＰＩＡＦＳ準拠の
データ通信サービスを「ＰＩＡＦＳ」、ＰＰＰ準拠のデ
ータ通信サービスを「ＰＰＰ」、ＦＡＸ通信サービスを
「ＦＡＸ」、モデム利用のデータ通信サービスを「モデ
ム」などと略記することがある。

【００２１】次に、上記のＲＮＣ３は、複数のＢＴＳ２
を収容して、ＭＭＳ５から配信（交換）されてくる呼を
着信対象のＭＳ１が存在する在圏ゾーン担当のＢＴＳ２
に着信させたり、ＢＴＳ２からの呼を多重してＭＭＳ５
へ送信したりといった、各種無線通信制御を実施するた
めのものである。さらに、上記のＭＰＥ４は、ＲＮＣ３
に接続されて、ＲＮＣ３で受信される信号（データ）の
サービス種別に応じたプロトコル変換などの各種信号処
理を行なうためのもので、例えば図２に示すように、Ｒ
ＮＣ３をＡＴＭ（Asynchronous Transfer Mode）網７ａ
経由で収容する場合には、ＡＴＭ交換機として構成され
る。なお、その詳細については後述する。

【００２２】また、ＭＭＳ５は、ゲートウェイ局（図示
省略）などを介して図２３により前述した集中局１３０
や中心局１２０，総括局１１０などに接続されることに
よって、公衆網１００と接続されて、公衆網１００とＲ
ＮＣ３やＭＰＥ４との間の呼の交換処理を行なうための
ものである。つまり、本ＭＭＳ５は、ＭＰＥ４に対して
呼接続／解放などのサービス要求（信号処理要求）を行
なう上位ノードとして位置付けられる。なお、上記のサ
ービス要求には、呼のサービス種別を識別するための情
報が含まれているものとする。

【００２３】さらに、ＯＰＳ６は、ＬＡＮ（Local Area
Network）７ｂなどの所要の回線網を介してＭＰＥ４と
接続されて、ＭＰＥ４の保守や運用管理を行なうための
もので、例えば図３に示すように保守コンソールなどと
して構成され、この保守コンソール６からＭＰＥ４の動
作設定などの各種設定を適宜に行なえるようになってい
る。

【００２４】そして、上記のＭＰＥ４は、上述したごと
くＡＴＭ交換機として構成される場合には、例えば図２
に示すように、ＡＴＭスイッチ４１，ＡＴＭインタフェ
ース（ＡＴＭ−ＩＦ）４２，ＬＡＮインタフェース（Ｌ
ＡＮ−ＩＦ）４３，複数のサービスプロトコルユニット
（ＳＰＵ）４４−１〜４４−Ｎ（Ｎは自然数），主制御
部４５などをそなえて構成される。

【００２５】ここで、ＡＴＭスイッチ４１は、ＡＴＭ網
７ａやＬＡＮ７ｂとの間で送受される呼をＡＴＭセルベ
ースで交換（スイッチング）するためのもので、周知の
ように、受信ＡＴＭセルのヘッダ部分に設定されている
宛先情報〔ＶＰＩ（VirtualPath Identifier）／ＶＣＩ
（Virtual Channel Identifier）〕に基づく装置内経路
識別情報（タグ情報）の設定が主制御部４２から与えら
れることにより、上記宛先情報に応じた経路のコネクシ
ョンが確立されてＡＴＭセルの転送（ＡＴＭ通信）が行
なわれるようになっている。

【００２６】また、ＡＴＭインタフェース４２は、ＡＴ
Ｍ網７ａとの間のインタフェースをとるためのものであ
り、ＬＡＮインタフェース４３は、ＬＡＮ７ｂとのイン
タフェースをとるためのもので、ＬＡＮ７ｂからの信号
をＡＴＭセルに変換したり、ＡＴＭスイッチ４１でスイ
ッチングされてきたＡＴＭセルをＬＡＮ７ｂへの信号に
変換したりする機能を有している。

【００２７】さらに、各ＳＰＵ（パッケージ）４４−ｉ
は、それぞれ、呼のサービス種別に応じたプロトコル終
端処理を実施するためのもので、本実施形態では、１つ
のＳＰＵ４４−ｉで前述したような複数種類のサービス
種別に応じた（適した）属性（信号処理モード）での動
作が可能になっている。なお、その詳細については図７
及び図８により後述する。

【００２８】そして、主制御部４５は、本ＡＴＭ交換機
４の動作（コネクションの確立／解放処理など）を統括
的に制御するためのものであるが、本実施形態では、Ｓ
ＰＵ４４−ｉ（ただし、ｉ＝１〜Ｎ）をはじめとするＡ
ＴＭ交換機４内のリソース（ＡＴＭスイッチ４１や帯域
なども含まれる）を管理して、上位ノード５からのサー
ビス要求（呼接続要求や呼解放要求などの信号処理要
求）に応じて必要なリソース（ＳＰＵ４４−ｉを含む）
を捕捉したり解放したりする基本的な機能を有するほ
か、上位ノード５からのサービス要求毎に、あるいは、
保守コンソール６からの指示（外部設定）に応じて、上
記のＳＰＵ４４−ｉの属性（信号処理モード）を適宜に
変更することで、ＳＰＵ４４−ｉのサービス種別毎の割
り当て数を適宜に変更しうる機能も有している。

【００２９】このため、本主制御部４５には、その要部
に着目すると、例えば図３に示すように、呼制御部４５
ａ，サービス決定部４５ｂ及びＳＰＵ状態管理部４５ｃ
がそなえられている。なお、この図３において、図２に
示すＡＴＭスイッチ４１やＡＴＭインタフェース４２，
ＬＡＮインタフェース４３などの図示は省略している。

【００３０】ここで、上記の呼制御部４５ａは、上述し
たコネクションの確立／解放（リソースの捕捉／解放）
処理などを中心的に制御するためのものであり、サービ
ス決定部（通信サービス種別識別手段）４５ｂは、上位
ノード５から通知されるサービス要求に含まれるサービ
ス種別を識別するための情報に基づいて処理対象呼のサ
ービス種別を判別（識別）するためのもので、その識別
結果は、その呼の信号処理に必要な（要求サービスプロ
トコル属性が一致する）ＳＰＵ４４−ｉの捕捉要求（以
下、ＳＰＵ捕捉要求という）として呼制御部４５ａを通
じてＳＰＵ状態管理部４５ｃに通知されるようになって
いる。

【００３１】そして、ＳＰＵ状態管理部（モード制御手
段）４５ｃは、ＳＰＵ４４−ｉの実装数や各ＳＰＵ４４
−ｉの稼働状態（空き状態，属性）などを管理するとと
もに、呼制御部４５ａと協動して、保守コンソール６か
らの指示（ＳＰＵ属性変更指示）や呼制御部４５ａから
の上記ＳＰＵ捕捉要求に応じて、ＳＰＵ４４−ｉの属性
（信号処理モード）を要求サービス種別に適した属性に
制御（変更）する機能を有するもので、このために、例
えば、ＳＰＵ状態管理受付部４５ｄとＳＰＵサービス変
更部４５ｅとをそなえて構成されている。

【００３２】即ち、ＳＰＵ状態管理受付部４５ｄは、例
えば図５（Ａ）に示すように、各ＳＰＵ４４−ｉ毎に割
り振られた論理番号（以下、ＳＰＵ論理番号という）毎
に、それぞれ、下記〜に示すデータを含むＳＰＵ状
態管理データ４５１を管理することで、各ＳＰＵ４４−
ｉのそれぞれの稼働状態をリアルタイムに管理するため
のものである。

【００３３】ＳＰＵ状態データ４５１ａ：ＳＰＵ４４
−ｉの空き／使用中を表わすためのデータで、例えば、
“０”で「空き」状態、“１”で「使用中」状態を表わ
す。なお、ＳＰＵ４４−ｉは、通常、１枚で複数チャン
ネル分の呼を処理できる能力を有しているが、本実施形
態では、説明の便宜上、１枚のＳＰＵ４４−ｉで１チャ
ンネル分の呼を処理できるものとし、ＳＰＵ４４−ｉの
「空き」とは、呼処理を行なっていない待機状態の場合
を意味するものとする。

【００３４】外部指定属性種別データ４５１ｂ：ＳＰ
Ｕ４４−ｉが図５（Ｂ）により後述する時刻対応属性管
理データ４５２によって指定された時刻対応のものか否
かを表わすデータで、例えば、“０”で「時刻対応」、
それ以外の値で「非時刻対応」を表わす。外部指定属性データ４５１ｃ：保守コンソール６から
デフォルト属性（優先属性）として指定されたＳＰＵ４
４−ｉの属性（サービス種別）を表わすデータで、例え
ば、“０”で「指定無し」、“０”以外で「指定有り」
を表わす。一例として、“１”で「音声対応」、“２”
で「ＩＳＤＮ対応」、“３”で「パケット対応」、
“４”で「ＰＩＡＦＳ対応」、“５”で「ＦＡＸ対
応」、“６”で「モデム対応」、“７”で「ＰＰＰ対
応」をそれぞれ表わす。

【００３５】カレント属性データ４５１ｄ：現在のＳ
ＰＵ４４−ｉの属性を表わすデータで、上記の外部指定
属性データ４５１ｃと同様に、“０”で「指定無し」、
“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、
“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対
応」、“５”で「ＦＡＸ対応」、“６”で「モデム対
応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。この
カレント属性データ４５１ｄの値と上記の外部指定属性
データ４５１ｃの値とが異なる場合には、後述するよう
に、後者の外部指定属性データ４５１ｃが優先され、前
者のカレント属性データ４５１ｄが外部指定属性データ
４５１ｃと一致するよう更新される。

【００３６】なお、上記のＳＰＵ状態データ４５１ａ以
外のデータ４５１ｂ〜４５１ｄについては、保守コンソ
ール６からＳＰＵ属性変更指示（モード設定指示）をＳ
ＰＵ状態管理受付部４５ｄに対して与えることで適宜に
変更することが可能である。また、上記のＳＰＵ状態管
理データ４５１は、図示しないメモリなどの記憶装置に
記憶されて管理されているものとする。

【００３７】一方、ＳＰＵサービス変更部４５ｅは、保
守コンソール６からの指示（ＳＰＵ属性変更指示）や呼
制御部４５ａからのＳＰＵ捕捉要求〔サービス決定部４
５ｂでのサービス種別（要求プロトコル）の識別結果〕
に基づき、ＳＰＵ属性変更が必要な場合にはＳＰＵ属性
変更依頼（要求）を、呼制御部４５ａを通じ該当ＳＰＵ
４４−ｉに与えるためのもので、これにより、該当ＳＰ
Ｕ４４−ｉは、要求された属性のＳＰＵ４４−ｉとして
設定されて運用されることになる。

【００３８】なお、この属性変更指示が実施された場合
は、該当ＳＰＵ４４−ｉに対応するＳＰＵ状態管理デー
タ４５１（カレント属性データ４５１ｄ）が更新され
る。つまり、これらのＳＰＵ状態管理受付部４５ｄとＳ
ＰＵサービス変更部４５ｅは、外部装置（他制御部）と
しての保守コンソール６からのＳＰＵ属性変更指示（モ
ード設定指示）に応じてＳＰＵ４４−ｉの属性（信号処
理モード）を制御する外部指示型モード制御部としての
機能も果たしていることになる。

【００３９】ところで、上記のＳＰＵサービス変更部４
５ｅは、図４に示すように、上述したような基本機能に
加えて、例えば図６に示すような形式で、過去に行なっ
たＳＰＵ４４−ｉに対する属性変更指示（モード制御）
についての統計情報（履歴情報）４５３、つまり、前記
のカレント属性データ４５１ｄの更新履歴をとることに
より、いつ、どのＳＰＵ４４−ｉがどの属性で動作して
いたかを管理する履歴情報管理部５２としての機能も有
している。

【００４０】この履歴情報管理部５２をそなえること
で、例えば、どのサービス種別の呼（トラフィック）が
どの日付や曜日，時間帯で集中しやすいかを分析・把握
することができるようになるので、ＳＰＵ状態変更部４
５ｃは、その分析結果に応じて、特定時刻に特定のサー
ビス種別対応のＳＰＵ割り当て数を予め多めに設定した
り少なめに設定したりすることができる。

【００４１】例えば図６では、一般企業の業務時間外な
どでは音声やＩＳＤＮのトラフィックが比較的少ないと
判断できるので、その時間帯では音声対応（属性＝
“１”）やＩＳＤＮ対応（属性＝“２”）のＳＰＵ割り
当て数を少なめに設定したり、逆に、業務開始時や昼休
み終了時などトラフィックが急激に増加しやすい時間帯
ではこれらのＳＰＵ割り当て数を予め多めに設定してお
くようにすることができる。

【００４２】なお、この図６に示す例は、ＳＰＵ４４−
ｉの実装数（Ｎ）が３２枚（論理番号＝１〜３２；ただ
し、論理番号３１，３２のＳＰＵ４４−３１，４４−３
２は予備）の場合で、図２２（Ａ）により後述するよう
に、「音声」，「ＩＳＤＮ」，「パケット」，「ＰＩＡ
ＦＳ」，「ＦＡＸ」，「モデム」，「ＰＰＰ」の各サー
ビス種別対応のＳＰＵ４４−ｉの初期割り当て数を最小
限（それぞれ１枚）にした状態を表わす。

【００４３】そして、このような時刻要因による設定
は、本実施形態では、図４に示すように、ＳＰＵサービ
ス変更部４５ｅに、図５（Ｂ）に示すようなＳＰＵ４４
−ｉ毎に管理される時刻対応属性管理データ４５２に基
づいて該当ＳＰＵ４４−ｉに対して属性変更指示を与え
る時刻要因属性変更部５３をそなえることで実現され
る。

【００４４】即ち、時刻要因属性変更部５３は、図５
（Ｂ）に示すように、ＳＰＵ論理番号毎に、或る指定時
刻（時間帯）にＳＰＵ４４−ｉのどの属性に設定するか
を表わすデータ（指定時刻データ４５２ａと指定時刻対
応属性データ４５２ｂとの組）を最大でｎ（ｎは自然
数）組分、時刻対応属性管理データ４５２として管理し
ておき、この時刻対応属性管理データ４５２を、常時、
或いは、定期的に参照することで、該当ＳＰＵ４４−ｉ
の属性を指定時刻に指定された属性に自動変更（設定）
することができるのである。

【００４５】つまり、上記の履歴情報管理部５２と時刻
要因属性変更部５３は、上記の履歴情報４５３に基づい
てＳＰＵ４４−ｉの属性を予測制御する予測型モード制
御部として機能し、時刻要因属性変更部５３は、上記の
履歴情報４５３に基づいた時刻対応属性管理データ４５
２に基づいて、指定時刻にＳＰＵ４４−ｉの属性を指定
された属性に制御する時刻要因モード制御部として機能
するのである。

【００４６】なお、上記の指定時刻対応属性データ４５
２ｂには、図５（Ａ）により前述した外部指定属性デー
タ４５１ｃやカレント属性データ４５１ｄと同様に定義
された値が設定される。即ち、“０”で「指定無し」、
“１”で「音声対応」、“２”で「ＩＳＤＮ対応」、
“３”で「パケット対応」、“４”で「ＰＩＡＦＳ対
応」、“５”で「ＦＡＸ対応」、“６”で「モデム対
応」、“７”で「ＰＰＰ対応」をそれぞれ表わす。

【００４７】また、上記の時刻対応属性管理データ４５
２や履歴情報４５３についても、図示しないメモリなど
の記憶装置にて保持されて管理されているものとする。
さらに、上記の指定時刻データ４５２ａ（時間帯）は、
開始時刻と終了時刻とで規定してもよいし、開始時刻と
その後の継続時間とで規定してもよい。また、上記の時
刻対応属性管理データ４５２は、時刻要因属性変更部５
３が上記の履歴情報４５３（図６参照）に基づいて自動
作成してもよいし、後述するように保守コンソール６か
ら個別に設定してもよい。

【００４８】次に、上記の各ＳＰＵ４４−ｉの構成につ
いて説明する。図７は上記の各ＳＰＵ４４−ｉの詳細構
成を示すブロック図で、この図７に示すように、各ＳＰ
Ｕ４４−ｉは、それぞれ、通信系インタフェース（Ｉ
Ｆ）回路６１，制御系インタフェース（ＩＦ）回路６
２，通信用デュアルポートＲＡＭ（ＤＰＲＡＭ）６３，
セル組立分解（ＳＡＲ：Structure And Restructure）
部６４，ＣＰＵ６５，フラッシュメモリ６６，ＲＡＭ６
７，ＤＳＰ（Digital SignalProcessor）モジュール６
８−１〜６８−ｍ（ｍは自然数），ＩＰＬ（InitialPro
gram Load）メモリ（ＲＡＭ）６９及びプログラムメモ
リ（ＲＡＭ）７０などをそなえて構成されている。

【００４９】ここで、上記の通信系ＩＦ回路６１は、Ａ
ＴＭセルの流れる通信系ネットワーク（セルバス）６０
ｂとのインタフェースをとるためのものであり、制御系
ＩＦ回路６２は、制御バスや監視用（ＳＶ：Supervisio
n）バスなどから成る制御系ネットワーク６０ａとのイ
ンタフェースをとるためのものであり、通信用ＤＰＲＡ
Ｍ６３は、この制御系ＩＦ回路６２を介した制御系ネッ
トワーク６０ａとの通信（制御バス経由）時に送受され
る制御メッセージを記憶するためのもので、この通信用
ＤＰＲＡＭ６３にＣＰＵ６５がアクセスすることにより
その制御メッセージに応じた制御を行なえるようになっ
ている。

【００５０】また、ＳＡＲ部６４は、ＡＴＭセルの組立
（ヘッダ付加）／分解（ヘッダ除去）処理をおこなうた
めのもので、本ＳＡＲ部６４と各ＤＳＰモジュール６８
−ｊ（ｊ＝１〜ｍ）との間では、ＡＴＭセルのヘッダを
除くデータ部分のみが送受されるようになっている。さ
らに、ＣＰＵ６５は、プログラムメモリ７０に保持され
たＣＰＵ６５用のプログラム（ＣＰＵファームウェア）
に従って動作することによりＳＰＵ４４−ｉの動作（マ
ルチメディア信号処理）を統括的に制御するためのもの
であり、各ＤＳＰモジュール６８−ｊは、それぞれ、Ｒ
ＡＭ６７に保持されたＤＳＰ６８−ｊ用のプログラム
（ＤＳＰファームウェア）を内部メモリ（図示省略）に
ロードすることにより、そのＤＳＰファームウェアに従
って、ＳＡＲ部６４から受信されるセルデータ（マルチ
メディア信号）に対する信号処理（プロトコル変換な
ど）を実施するためのものである。

【００５１】ただし、本実施形態では、フラッシュメモ
リ６６内に各サービス種別に対応した複数種類のＣＰＵ
ファームウェア及びＤＳＰファームウェアが通信サービ
ス制御プログラムとして予めサービス種別毎に異なる領
域に格納されており、上述したＳＰＵサービス変更部４
５ｃからの属性変更指示に応じたファームウェア（格納
領域）を選択してＲＡＭ６７に読み出して、ＣＰＵ６５
とＤＳＰモジュール６８−ｊのいずれかとにそれぞれ必
要なＣＰＵファームウェア及びＤＳＰファームウェアを
ロードさせることで、上述したごとく１つのＳＰＵ４４
−ｉで複数種類のサービス種別に対応した信号処理を行
なえるようになっている。

【００５２】即ち、例えば図８に示すように、フラッシ
ュメモリ６６には、少なくとも、ＩＰＬ領域６６１，Ｃ
ＰＵファームウェア領域６６２，ＤＳＰファームウェア
領域６６３などが設けられており、ＣＰＵファームウェ
ア領域６６２には、パケット（属性＝“３”），音声
（属性“１”），ＩＳＤＮ（属性＝“２”），ＰＩＡＦ
Ｓ（属性＝“４”），ＰＰＰ（属性＝“７”），ＦＡＸ
（属性＝“５”），モデム（属性＝“６”）などの各サ
ービス種別対応のＣＰＵファームウェア（プログラム）
６６２−１〜６６２−７が格納され、同様にして、ＤＳ
Ｐファームウェア領域６６３に、各サービス種別対応の
ＤＳＰファームウェア（プログラム）６６３−１〜６６
３−７が格納されている。

【００５３】なお、上記のＩＰＬ領域６６１には、ＳＰ
Ｕ起動時（電源投入時）などにおいてＣＰＵ６５が最初
に読み込む（ＩＰＬメモリ６９に展開すべき）初期化プ
ログラムが格納されている。また、各ファームウェア領
域６６２，６６３には、それぞれ、ＳＰＵ４４−ｉが対
応すべきサービス種別数が増えたときのための予備のフ
ァームウェア領域６６２−８，６６３−８も設けられて
いる。

【００５４】そして、前述したＳＰＵ状態管理部４５ｃ
（ＳＰＵサービス変更部４５ｅ）からの属性変更指示
（例えば、パケット対応のものへの属性変更指示）が上
記の制御メッセージとして制御系ネットワーク６０ａを
介して通信用ＤＰＲＡＭ６３に保持されると、ＣＰＵ６
５は、上記の属性変更指示で指定されたサービス種別対
応（図８ではパケット用）のＣＰＵファームウェア６６
２−１及びＤＳＰファームウェア６６３−１をそれぞれ
運用ファームウェアとしてプログラムメモリ７０及びＲ
ＡＭ６７に読み出す（展開する）ことで、自身とＤＳＰ
モジュール６８−ｊのいずれかとに運用ファームウェア
をそれぞれロードするのである。

【００５５】つまり、上記のフラッシュメモリ６６は、
複数種類の通信サービス種別に応じた複数種類の通信サ
ービス制御プログラムを記憶した記憶部として機能し、
ＣＰＵ６５は、前述したＳＰＵ状態管理部４５ｃからの
属性変更指示に応じて対応する通信サービス制御プログ
ラムをフラッシュメモリ６６から選択的にロードするこ
とにより、自身の属性（信号処理モード）を制御するＳ
ＰＵ属性変更部（モード選択制御部）として機能するよ
うになっているのである。

【００５６】このため、ＤＳＰモジュール６８−ｊの実
装数（ｍ）は、前記のサービス種別数よりも少ない数で
よく、未使用のＤＳＰモジュール６８−ｊは、障害発生
などにより使用不能となったＤＳＰモジュール６８−ｊ
の予備として使用することができる。以下、上述のごと
く構成された本実施形態のＡＴＭ交換機（ＭＰＥ）４の
動作について詳述する。

【００５７】（１）ＳＰＵ属性設定手順（時刻要因／非
時刻要因）の説明まず、保守コンソール６からＳＰＵ４４−ｉの属性を設
定（変更）する手順（非時刻要因）について説明する。
例えば図９に示すように、保守コンソール６から或るＳ
ＰＵ４４−ｉに対するＳＰＵ属性変更指示（ＩＤ＝１）
を処理要求として投入すると（ステップＡ１）、その処
理要求（ＳＰＵ属性変更指示）は、ＳＰＵ状態管理部４
５ｃ（ＳＰＵ状態管理受付部４５ｄ）にて受け付けられ
る。

【００５８】すると、ＳＰＵ状態管理受付部４５ｄは、
受信したＳＰＵ属性変更指示に従って、該当ＳＰＵ４４
−ｉについてのＳＰＵ状態管理データ４５１を更新し、
属性変更対象のＳＰＵ４４−ｉに対する属性変更依頼を
ＳＰＵサービス変更部４５ｅに対して行なう（ステップ
Ａ２）。具体的に、この場合、ＳＰＵ状態管理受付部４
５ｄは、図１４に示すように、保守コンソール６から受
信した処理要求内容が非時刻要因のＳＰＵ属性変更指示
（ＩＤ＝１．２）であるので、ステップＳ１からステッ
プＳ１０に分岐し、さらに、図１５に示すステップＳ１
１からステップＳ１２に分岐して、図１６に示す処理手
順（ステップＡ３）を実行する。

【００５９】即ち、ＳＰＵ状態管理受付部４５ｄは、ま
ず、ＳＰＵ状態管理データ４５１を参照し（ステップＳ
１２１）、外部指定属性データ４５１ｃに“０”（＝
「指定無し」）以外の値が設定されているか否かを確認
する（ステップＳ１２２）。この結果、“０”（＝「指
定無し」）以外の値が設定されていれば（ステップＳ１
２２でＹＥＳなら）、上記のＳＰＵ属性変更指示の優先
度に従って外部指定属性データ４５１ｃをＳＰＵ属性変
更指示によって指定されたサービス種別に応じた値に更
新する。つまり、保守コンソール６からのＳＰＵ属性変
更指示の優先度の方が高ければ外部指定属性データ４５
１ｃの更新を行なう（ステップＳ１２３）。

【００６０】一方、外部指定属性データ４５１ｃに
“０”（＝「指定無し」）が設定されていた場合（ステ
ップＳ１２２でＮＯの場合）は、ＳＰＵ状態管理受付部
４５ｄは、新たに外部指定属性データ４５１ｃを指定さ
れたサービス種別に応じた値に更新する（ステップＳ１
２４）。その後、ＳＰＵ状態管理受付部４５ｄは、ＳＰ
Ｕ状態データ４５１ａを参照して属性変更対象のＳＰＵ
４４−ｉが空き状態か使用中かを確認し（ステップＳ１
２５）、空き状態（属性変更可能な状態）であれば、Ｓ
ＰＵサービス変更部４５ｅにそのＳＰＵ４４−ｉの属性
変更を依頼する。

【００６１】すると、ＳＰＵサービス変更部４５ｅは、
依頼を受けたＳＰＵ４４−ｉに対してＳＰＵ属性変更指
示を与える（ステップＳ１２５のＹＥＳルートからステ
ップＳ１２６：図９のステップＡ４）。なお、属性変更
対象のＳＰＵ４４−ｉが使用中であった場合は、外部指
定属性データ４５１ｃを更新したことを要因として、図
１９及び図２０により後述するように、ＳＰＵ４４−ｉ
を使用している呼の解放処理中に属性変更が実施される
ので、この場合、ＳＰＵサービス変更部４５ｅは、使用
中ＳＰＵ４４−ｉに対するＳＰＵ属性変更指示は出力し
ない（ステップＳ１２５のＮＯルート）。

【００６２】さて、次に、図１０に示すように、上述の
ごとくＳＰＵサービス変更部４５ｅからＳＰＵ属性変更
指示を起動（ステップＢ０）後に受けた（ステップＢ
１）ＳＰＵ４４−ｉでは、ＣＰＵ６５が、図８により前
述したように、要求されたサービス種別（プロトコル）
対応のＣＰＵファームウェア６６２−ｋ（ｋ＝１〜７）
をフラッシュメモリ６６のＣＰＵファームウェア領域６
６２から読み出してプログラムメモリ７０に書き込むこ
とで、要求サービス種別対応のＣＰＵファームウェア６
６２−ｋをＣＰＵ６５に対してロードする（ステップＢ
２）。

【００６３】同様に、ＣＰＵ６５は、要求サービス種別
対応のＤＳＰファームウェア６６３−ｋをフラッシュメ
モリ６６のＤＳＰファームウェア領域６６３から読み出
してＤＳＰモジュール６８−ｊのいずれかの内部メモリ
に書き込むことで、ＤＳＰファームウェアのロードを実
行する（ステップＢ３；図９のステップＡ５）。以上の
処理が完了すると、ＳＰＵ４４−ｉが運用可能状態とな
り、ＣＰＵ６５は、その旨を、制御系ネットワーク６０
ａを介してＳＰＵ状態管理部４５ｃに通知する（ステッ
プＢ４）。

【００６４】すると、ＳＰＵ状態管理部４５ｃは、図９
に示すように、保守コンソール６に対して、ＳＰＵ属性
変更完了通知を行なう（ステップＡ６）。以上のような
処理を属性変更対象のＳＰＵ４４−ｉ分だけ繰り返すこ
とで、任意のＳＰＵ４４−ｉを所望のサービス種別対応
のＳＰＵ４４−ｉとして設定して、サービス種別毎のＳ
ＰＵ割り当て数を設定・変更することが可能になる。

【００６５】なお、上記の例では、保守コンソール６か
らＳＰＵ属性変更指示を、属性変更対象のＳＰＵ数分だ
け繰り返すことを前提としているが、ＳＰＵ属性変更指
示に複数分のＳＰＵ属性変更のための情報を設定するこ
とで、保守コンソール６からの１回のＳＰＵ属性変更指
示の投入で、複数のＳＰＵ４４−ｉの属性を変更できる
ようにしてもよい。

【００６６】次に、保守コンソール６から時刻要因によ
るＳＰＵ属性変更を設定する場合の動作について説明す
る。まず、図１１に示すように、保守コンソール６から
或るＳＰＵ４４−ｉに対する時刻要因のＳＰＵ属性変更
指示（ＩＤ＝１．１）を処理要求として投入すると（ス
テップＣ１）、その処理要求（ＳＰＵ属性変更指示）
は、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４
５ｄ）にて受け付けられる。

【００６７】すると、ＳＰＵ状態管理受付部４５ｄは、
受信したＳＰＵ属性変更指示に従って、該当ＳＰＵ４４
−ｉについてのＳＰＵ状態管理データ４５１を更新する
（ステップＣ２）。具体的に、この場合、ＳＰＵ状態管
理受付部４５ｄは、図１４に示すように、保守コンソー
ル６から受信した処理要求内容が時刻要因のＳＰＵ属性
変更指示（ＩＤ＝１．１）であるので、ステップＳ１か
らステップＳ１０に分岐し、さらに、図１５に示すステ
ップＳ１１からステップＳ１３に分岐して、図１７に示
す処理手順（ステップＣ３）を実行する。

【００６８】即ち、ＳＰＵ状態管理受付部４５ｄは、ま
ず、ＳＰＵ状態管理データ４５１を参照し（ステップＳ
１３１）、外部指定属性データ４５１ｃに“０”（＝
「指定無し」）以外の値が設定されているか否かを確認
する（ステップＳ１３２）。この結果、“０”（＝「指
定無し」）以外の値が設定されていれば、上記のＳＰＵ
属性変更指示の優先度に従って外部指定属性種別データ
４５１ｂを「時刻対応」（＝“０”）に設定（更新）す
る。即ち、保守コンソール６から投入されたＳＰＵ属性
変更指示の優先度の方が高ければ外部指定属性データ４
５１ｂの設定（更新）を行なう（ステップＳ１３２のＹ
ＥＳルートからステップＳ１３３）。

【００６９】一方、外部指定属性データ４５１ｃに
“０”（＝「指定無し」）が設定されていた場合は、Ｓ
ＰＵ状態管理受付部４５ｄは、外部指定属性種別データ
４５１ｂに「時刻対応」（＝“０”）を設定する（ステ
ップＳ１３２のＮＯルートからステップＳ１３４）。そ
の後、ＳＰＵ状態管理受付部４５ｄは、属性変更対象の
ＳＰＵ４４−ｉに対応する時刻対応属性管理データ４５
２を参照し（ステップＳ１３５）、指定時刻データ４５
２ａと時刻対応属性データ４５２ｂとを設定したのち
（ステップＳ１３６）、保守コンソール６へＳＰＵ４４
−ｉの属性変更（設定）が完了した旨を通知する（ステ
ップＳ１３７；図１１のステップＣ４）。

【００７０】以上により、時刻要因によるＳＰＵ４４−
ｉの属性変更（設定）が完了し、以後、指定時刻になる
と、該当ＳＰＵ４４−ｉが空き状態で、且つ、カレント
属性（データ４５１ｄ）と外部指定属性（データ４５１
ｃ）とが一致していなければ、自動的に、ＳＰＵ属性サ
ービス変更部４５ｅから該当ＳＰＵ４４−ｉに対して
（空き状態であれば）ＳＰＵ属性変更指示が与えられ
て、ＳＰＵ４４−ｉの属性が変更される。これにより、
指定時刻には必要な分のサービス種別対応のＳＰＵ４４
−ｉが事前に確保されることになる。

【００７１】つまり、この場合、ＳＰＵ状態管理部４５
ｃは、トラフィックの増大が予想される時間帯において
呼毎にいちいちＳＰＵ属性変更処理を実行する必要がな
く、呼処理の高速化を図ることが可能である。なお、上
述した時刻要因によるＳＰＵ属性変更指示についても、
属性設定対象分のＳＰＵ４４−ｉ毎に繰り返し行なって
もよいし、１回のＳＰＵ属性変更（設定）指示で複数分
のＳＰＵ４４−ｉの属性変更（設定）を行なうようにし
てもよい。

【００７２】（２）運用中（呼毎）のＳＰＵ属性自動設
定処理の説明次に、以下では、サービス運用中のＡＴＭ交換機４の動
作について説明する。まず、図１２に示すように、上位
ノード５から或る呼についてのサービス要求（呼接続要
求）が主制御部４５（呼制御部４５ａ）にて受信される
と（ステップＤ１）、呼制御部４５ａが、その呼につい
ての変換対象プロトコルの決定要求メッセージをサービ
ス決定部４５ｂに出力する（ステップＤ２）。なお、上
記のメッセージには、サービス種別を識別するための情
報が含まれているものとする。

【００７３】すると、サービス決定部４５ｂは、受信し
たメッセージに基づいて要求されたサービス種別（プロ
トコル）を識別し（ステップＤ３）、呼制御部４５ａに
対してそのサービス種別に応じたＳＰＵ４４−ｉの捕捉
要求を行ない（ステップＤ４）、この捕捉要求を受けた
呼制御部４５ａは、ＳＰＵ状態管理部４５ｃ（ＳＰＵ状
態管理受付部４５ｄ）に対して同様のＳＰＵ捕捉要求
（ＩＤ＝２）を行なう（ステップＤ５）。

【００７４】すると、ＳＰＵ状態管理受付部４５ｄは、
受信した要求がＳＰＵ捕捉要求（ＩＤ＝２）なので、図
１４に示すステップＳ１からステップＳ２０へ分岐し
て、図１８に示す処理手順（ＳＰＵ検索処理）を実行す
る（ステップＤ６）。即ち、ＳＰＵ状態管理受付部４５
ｄは、ＳＰＵ状態管理データ４５１をＳＰＵ論理番号＝
“１”のＳＰＵ４４−ｉに対応するものから順番に参照
して、要求サービス種別対応のＳＰＵ４４−ｉを検索す
る。なお、このとき、保守コンソール６から外部指定属
性の設定が行なわれている場合は、外部指定属性データ
４５１ｃに基づいて、そのＳＰＵ４４−ｉの属性が判断
される。

【００７５】具体的に、ＳＰＵ状態管理受付部４５ｄ
は、まず、ＳＰＵ状態管理データ４５１を参照して（ス
テップＳ２１）、参照中のＳＰＵ状態管理データ４５１
が、ＳＰＵ論理番号が最終のデータか否かを確認する
（ステップＳ２２）。その結果、最終データでなけれ
ば、ＳＰＵ状態管理受付部４５ｄは、次に、ＳＰＵ状態
データ４５１ａ〔図５（Ａ）参照〕を参照して、ＳＰＵ
４４−ｉが空き状態であるか使用中であるかを確認し
（ステップＳ２２のＮＯルートからステップＳ２３）、
空き状態であれば、さらに、外部指定属性種別データ４
５１ｂを参照して、外部指定属性種別データ４５１ｂと
して「時刻対応」（＝“０”）が設定されているかを確
認する（ステップＳ２３のＹＥＳルートからステップＳ
２４）。

【００７６】この結果、外部指定属性種別データ４５１
ｂとして「時刻対応」（＝“０”）以外が設定されてい
れば、ＳＰＵ状態管理受付部４５ｄは、次に、外部指定
属性データ４５１ｃを参照して、既に外部指定属性デー
タ４５１ｃとして「外部指定済み」が設定されているか
否かを確認する（ステップＳ２４のＮＯルートからステ
ップＳ２５）。

【００７７】その結果、「外部指定済み」であれば、Ｓ
ＰＵ状態管理受付部４５ｄは、さらに、要求サービス種
別と外部指定属性データ４５１ｃとが一致しているか否
かを確認し（ステップＳ２５のＹＥＳルートからステッ
プＳ２６）、一致していれば、ＳＰＵ状態データ４５１
ａを「使用中」（＝“１”）に更新する（ステップＳ２
６のＹＥＳルートからステップＳ２７）。

【００７８】次いで、ＳＰＵ状態管理受付部４５ｄは、
外部指定属性データ４５１ｃとカレント属性データ４５
１ｄとを参照して、外部指定属性とカレント属性とが一
致しているか否かを確認し（ステップＳ２８）、一致し
ていれば、外部指定属性指定済みで要求サービス種別と
一致する空き状態のＳＰＵ４４−ｉが見つかったことに
なるので、そのＳＰＵ４４−ｉを上位ノード５からの上
記呼接続要求に対する割り当て対象のＳＰＵ４４−ｉと
して捕捉し、その旨を呼制御部４５ａに通知して処理を
呼制御部４５ａに移行する（ステップＳ２８のＹＥＳル
ートからステップＳ２９；図１２のステップＤ９）。

【００７９】即ち、呼制御部４５ａは、図１２に示すよ
うに、ＳＰＵ状態管理部４５ｃから上記の通知を受ける
と、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要
求元の上位ノード５との間のスイッチング設定（コネク
ション設定）を行なって（ステップＤ１０）、呼の接続
を行なったのち、呼の接続完了の旨を上位ノード５に通
知する（ステップＤ１１）。

【００８０】なお、上記のステップＳ２３においてＳＰ
Ｕ状態が空き状態でなかった場合（ステップＳ２３でＮ
Ｏと判定された場合）や、上記のステップＳ２６におい
て要求サービス種別と外部指定属性とが一致しなかった
場合（ステップＳ２６でＮＯと判定された場合）には、
次のＳＰＵ論理番号のＳＰＵ状態管理データ４５１につ
いて上記ステップＳ２２からの処理が実行される。

【００８１】ところで、上記のステップＳ２５におい
て、外部指定属性データ４５１ｃに「指定無し」（＝
“０”）が設定されていた場合（ステップＳ２５でＮＯ
と判定された場合）、ＳＰＵ状態管理受付部４５ｄは、
次に、図１８に示すように、カレント属性データ４５１
ｄを参照して、カレント属性と要求サービス種別とが一
致しているかを確認する（ステップＳ３０）。

【００８２】この結果、カレント属性と要求サービス種
別とが一致していれば（ステップＳ３０でＹＥＳと判定
されれば）、外部指定属性未指定（外部指定無し）でカ
レント属性が要求サービス種別と一致する空きＳＰＵ４
４−ｉが見つかったことになるので、ＳＰＵ状態管理受
付部４５ｄは、該当ＳＰＵ状態データ４５１ａを「使用
中」（＝“１”）に更新して（ステップＳ３１）、その
ＳＰＵ４４−ｉを上記呼接続要求に対する割り当て対象
のＳＰＵ４４−ｉとして捕捉し、その旨を呼制御部４５
ａに通知して処理を呼制御部４５ａに移行する（ステッ
プＳ２９）。

【００８３】そして、呼制御部４５ａは、この場合も、
ＳＰＵ状態管理部４５ｃから上記の通知を受けると、上
述のごとく捕捉されたＳＰＵ４４−ｉと呼接続要求元の
上位ノード５との間のスイッチング設定（コネクション
設定）を行なって（ステップＤ１０）、呼の接続を行な
ったのち、呼の接続完了の旨を上位ノード５に通知する
（ステップＤ１１）。

【００８４】次に、上記のステップＳ２８においてＳＰ
Ｕ４４−ｉの外部指定属性とカレント属性とが一致しな
い場合（ステップＳ２８でＮＯと判定された場合）や、
上記のステップＳ３０において要求サービス種別とＳＰ
Ｕ４４−ｉのカレント属性とが一致しない場合（ステッ
プＳ３０でＮＯと判定された場合）、ＳＰＵ状態管理受
付部４５ｄは、図２０に示すように、カレント属性デー
タ４５１ｄを更新してその不一致を解消し（ステップＳ
３２）、ＳＰＵ属性サービス変更部４５ｅに該当ＳＰＵ
４４−ｉの属性変更を依頼する。

【００８５】すると、ＳＰＵ属性変更部４５ｅは、該当
ＳＰＵ４４−ｉに対して属性変更要求（要求サービス種
別を含む）を行なう（ステップＳ３３；図１２のステッ
プＤ７）。これにより、当該ＳＰＵ４４−ｉは、図１０
により前述したように、フラッシュメモリ６６から要求
サービス種別に対応するＣＰＵファームウェア６６２−
ｋとＤＳＰファームウェア６６３−ｋとをそれぞれ読み
出してロードすることにより、自身の属性を要求された
サービス種別対応（プロトコル属性）に変更する（図１
２のステップＤ８）。

【００８６】これにより、上述のごとく属性変更のなさ
れたＳＰＵ４４−ｉが上記の呼接続要求に対する割り当
てＳＰＵ４４−ｉとして捕捉されて、呼制御部４５ａに
処理が移行する（ステップＳ３４）。即ち、呼制御部４
５ａは、上述のごとく捕捉されたＳＰＵ４４−ｉと呼接
続要求元の上位ノード５との間のスイッチング設定（コ
ネクション設定）を行なって（図１２のステップＤ１
０）、呼の接続を行なったのち、呼の接続完了の旨を上
位ノード５に通知する（図１２のステップＤ１１）。

【００８７】ところで、前記のステップＳ２４（図１８
参照）において外部指定属性種別データ４５１ｂとして
「時刻対応」（＝“０”）が設定されていた場合（ステ
ップＳ２４でＹＥＳと判定された場合）は、図２１に示
すように、時刻要因属性変更部５２が、それまで参照し
ていたＳＰＵ状態管理データ４５１のＳＰＵ論理番号を
キーにして対応する時刻対応属性管理データ４５２を検
索する（ステップＳ３５）。

【００８８】そして、時刻対応属性管理データ４５２の
中に現時刻の含まれる時間帯が指定時刻データ４５２ａ
によって設定されていれば、時刻要因属性変更部５２
は、その指定時刻データ４５２ａに対応する時刻対応属
性データ４５２ｂを参照して、要求サービス種別と時刻
対応属性とが一致しているか否かを確認する（ステップ
Ｓ３６）。

【００８９】この結果、要求サービス種別と時刻対応属
性とが一致していれば（ステップＳ３６でＹＥＳと判定
されれば）、時刻対応属性指定済みで要求サービス種別
と一致する空き状態のＳＰＵ４４−ｉが見つかったこと
になるので、時刻要因属性変更部５２は、そのＳＰＵ４
４−ｉに対応するＳＰＵ状態管理データ４５１のＳＰＵ
状態データ４５１ａを使用中（＝“１”）に更新する
（ステップＳ３７）。

【００９０】次に、時刻要因属性変更部５２は、外部指
定属性データ４５１ｃとカレント属性データ４５１ｄと
を比較して、ＳＰＵ４４−ｉの外部指定属性とカレント
属性とが一致しているか否かを確認し（ステップＳ３
８）、一致していれば（ステップＳ３８でＹＥＳと判定
されれば）、そのまま、対応するＳＰＵ４４−ｉを上記
の呼接続要求に対する割り当てＳＰＵ４４−ｉとして捕
捉して、処理を呼制御部４５ａに移行する（ステップＳ
３９；図１２のステップＤ９〜Ｄ１１）。

【００９１】一方、ＳＰＵ４４−ｉの外部指定属性とカ
レント属性とが一致していなければ（ステップＳ３８で
ＮＯと判定されれば）、図２０により前述したように、
カレント属性が外部指定属性と一致するよう更新され、
ＳＰＵサービス変更部４５ｅによって、該当ＳＰＵ４４
−ｉの属性がカレント属性から外部指定属性に変更され
た上で、呼制御部４５ａに処理が移行する（ステップＳ
３２〜Ｓ３４）。

【００９２】なお、上記のステップＳ３６において、要
求サービス種別と時刻対応属性とが一致していなかった
場合（ステップＳ３６でＮＯと判定された場合）は、次
のＳＰＵ論理番号のＳＰＵ状態管理データ４５１につい
て、図１８により前述したステップＳ２２以降の処理が
実行される。以上のようにして、上位ノード５からの呼
接続要求毎に、要求サービス種別に一致する属性をもつ
ＳＰＵ４４−ｉが空き状態で既に存在すれば、そのＳＰ
Ｕ４４−ｉが、順次、割り当てＳＰＵ４４−ｉとして捕
捉され、要求サービス種別に一致する属性をもつ空きＳ
ＰＵ４４−ｉが存在しなければ（要求サービス種別対応
のＳＰＵ４４−ｉが不足していれば）、空き状態のＳＰ
Ｕ４４−ｉの属性が要求サービス種別対応の属性に変更
されて、割り当てＳＰＵ４４−ｉとして捕捉されてゆ
く。

【００９３】例えば図２２（Ａ）に示すように、初期設
定として、「音声」，「ＩＳＤＮ」，「パケット」，
「ＰＩＡＦＳ」，「ＦＡＸ」，「モデム」，「ＰＰＰ」
の各サービス種別対応のＳＰＵ４４−ｉの割り当て数を
最小限〔図２２（Ａ）ではそれぞれ１枚〕にした場合
は、残り（外部指定無しのＳＰＵ４４−ｉ：ＳＰＵ論理
番号＝８〜３０）の属性を上述のごとく運用中（呼毎）
に適宜に変更してゆくことで、不足分のサービス種別対
応のＳＰＵ４４−ｉを充足することができる。

【００９４】また、例えば図２２（Ｂ）に示すように、
初期設定として、上記の各サービス種別対応のＳＰＵ４
４−ｉの割り当て数を予測されるサービス種別毎のトラ
フィックに応じた割合〔図２２（Ｂ）では音声用５枚、
ＩＳＤＮ用５枚、パケット用５枚、ＰＩＡＦＳ用２枚、
ＦＡＸ用２枚、モデム用２枚、ＰＰＰ用２枚〕に設定し
た場合も、外部指定無しのＳＰＵ４４−ｉ（ＳＰＵ論理
番号＝２４〜３０）、あるいは、初期設定（外部指定）
で他サービス種別対応に設定されているものでも空き状
態であればそのＳＰＵ４４−ｉの属性を運用中に適宜に
変更してゆくことで、不足分のサービス種別対応のＳＰ
Ｕ４４−ｉを充足することができる。

【００９５】なお、上記の図２２（Ａ）及び図２２
（Ｂ）では、ＳＰＵ数＝３２、つまり、Ｎ＝３２の場合
を例にしている。また、これらの図２２（Ａ）及び図２
２（Ｂ）において、ＳＰＵ論理番号＝３１，３２の２枚
のＳＰＵ４４−ｉ（網掛け部参照）は予備用として実装
されたＳＰＵ４４−ｉで、他のＳＰＵ４４−ｉと同一構
成を有している。従って、例えば、障害発生などにより
どのサービス種別対応のＳＰＵ４４−ｉが使用不能にな
っても、そのＳＰＵ４４−ｉの代わりとして使用するこ
とが可能である。

【００９６】次に、上記の呼接続が切断（解放）される
場合の処理について説明する。まず、図１３に示すよう
に、上位ノード５から呼解放要求が送信され呼制御部４
５ａにて受信されると（ステップＥ１）、呼制御部４５
ａは、まず、該当ＳＰＵ４４−ｉと呼接続要求元の上位
ノード５とのコネクション設定を解放し（ステップＥ
２）、解放呼のために捕捉されていたリソース（ＳＰＵ
４４−ｉ）の解放要求（ＳＰＵ解放要求：ＩＤ＝３）を
ＳＰＵ状態管理部４５ｃ（ＳＰＵ状態管理受付部４５
ｄ）に出力する（ステップＥ３）。

【００９７】すると、ＳＰＵ状態管理受付部４５ｄは、
受信した要求がＳＰＵ解放要求（ＩＤ＝３）なので、図
１４に示すステップＳ１からステップＳ４０へ分岐し
て、図１９に示す処理手順（該当ＳＰＵ状態管理データ
４５１の更新処理）を実行する（ステップＥ４）。即
ち、ＳＰＵ状態管理受付部４５ｄは、対象のＳＰＵ状態
管理データ４５１を参照し（ステップＳ４１）、ＳＰＵ
状態データ４５１ａを「空き」（＝“０”）に更新する
（ステップＳ４２）。その後、ＳＰＵ状態管理受付部４
５ｄは、同じＳＰＵ状態管理データ４５１の外部指定属
性データ４５１ｃに「指定済み」（“０”以外の値）が
設定されているか否かを確認する（ステップＳ４３）。

【００９８】その結果、「指定無し」（＝“０”）が設
定されていれば、ＳＰＵ解放処理が完了した旨を呼制御
部４５ａに通知して（図１３のステップＥ７）、処理を
呼制御部４５ａに移行する（ステップＳ４３のＮＯルー
トからステップＳ４５）。すると、呼制御部４５ａは、
呼の解放が完了した旨を呼解放要求元の上位ノード５に
通知して（図１３のステップＥ８）、呼解放処理を完了
する。

【００９９】一方、上記のステップＳ４３において外部
指定属性データ４５１ｃに“０”以外の値が設定されて
外部指定属性が「指定済み」になっていた場合、ＳＰＵ
状態管理受付部４５ｄは、さらに、同じＳＰＵ状態管理
データ４５１の外部指定属性データ４５１ｃとカレント
属性データ４５１ｄとを参照して、外部指定属性とカレ
ント属性とが一致しているか否かを確認する（ステップ
Ｓ４３のＹＥＳルートからステップＳ４４）。

【０１００】この結果、外部指定属性とカレント属性と
が一致していれば、外部指定属性が指定されていない場
合（ステップＳ４３でＮＯと判定された場合）と同様に
して、呼制御部４５ａに処理が移行し（ステップＳ４４
のＹＥＳルートからステップＳ４５）、呼制御部４５ａ
から呼解放完了通知が上位ノード５に出力される（図１
３のステップＥ７，Ｅ８）。

【０１０１】一方、外部指定属性とカレント属性とが一
致していなければ（ステップＳ４４でＮＯと判定された
場合）、ＳＰＵ状態管理受付部４５ｄは、図２０により
前述したステップＳ３２〜Ｓ３４の処理を実行すること
により、カレント属性を更新して外部指定属性と一致さ
せるとともに、ＳＰＵサービス変更部４５ｅによって、
該当ＳＰＵ４４−ｉの属性を外部指定属性に変更（図１
３のステップＥ５，Ｅ６）した上で、処理を呼制御部４
５ａに移行する。即ち、呼制御部４５ａは、呼の解放が
完了した旨を呼解放要求元の上位ノード５に通知して、
呼解放処理を完了する（図１３のステップＥ７，Ｅ
８）。

【０１０２】このようにして、上位ノード５から呼の解
放要求がある毎に、該当するＳＰＵ４４−ｉの捕捉が解
放されるとともに、自動的に、その属性が、外部指定属
性（デフォルト属性）の指定が有る場合にはその指定に
応じた属性となり、外部指定属性の指定が無い場合には
捕捉時の属性に維持される。以上説明したように、本実
施形態のＡＴＭ交換機（ＭＰＥ）４によれば、複数種類
のサービス種別に対応した複数のプログラム（ＣＰＵフ
ァームウェア及びＤＳＰファームウェア）を１枚のパッ
ケージに搭載したＳＰＵ４４−ｉに対して、上位ノード
５が要求した、つまり、ユーザ（加入者）が指定したサ
ービス種別対応のプログラムをＳＰＵ状態管理部４５ｃ
からの制御によってロードさせることで、呼毎に任意の
ＳＰＵ４４−ｉを要求サービス種別対応のものにフレキ
シブルに変更・捕捉することができる。

【０１０３】従って、従来のようにサービス種別毎に専
用のＳＰＵを実装する場合、即ち、サービス種別毎のＳ
ＰＵ割り当て数が固定である場合に比して、大幅にＳＰ
Ｕ４４−ｉの必要実装数を削減することができて、ＡＴ
Ｍ交換機４の大幅な小型化を図ることが可能である。ま
た、ＡＴＭ交換機４の製造元（メーカ）にとっては、サ
ービス種別毎に専用のＳＰＵを製造する必要がないの
で、多品種の製造及びメンテナンスから少品種の製造及
びメンテナンスに移行することができ、コストダウン及
び保守の品質向上を図ることができる。

【０１０４】さらに、或るサービス種別対応のトラフィ
ックが増加してそのサービス種別対応のＳＰＵ４４−ｉ
が不足するような場合でも、空きＳＰＵ４４−ｉを不足
分のサービス種別対応のＳＰＵ４４−ｉとして使用する
ことができる、つまり、実装されたＳＰＵ４４−ｉ全体
でサービス種別に依存せずに全トラフィックを吸収する
ことができるので、サービス種別毎に専用のＳＰＵを実
装する場合に比して、トラフィックの許容量が大きくな
り、呼損率を極めて低く抑えることができる。この結
果、ユーザにとっては、接続性が大幅に向上することに
なる。

【０１０５】また、ＡＴＭ交換機４の建局時におけるＳ
ＰＵ実装数の算出根拠について、ＡＴＭ交換機４のトラ
フィック量を推定するだけでよく、通常、実施されてい
る各サービス種別対応のＳＰＵ毎の周辺上位ノードから
の要求トラフィック量の分析は不要となる。さらに、運
用状態となった場合でも、各サービス毎のメンテナンス
は不要となり、ピーク時のトラフィックに対するＳＰＵ
４４−ｉの過不足の対応のみでよいことになる。

【０１０６】また、時刻要因によるＳＰＵ属性変更指示
により、指定時刻に、指定したサービス種別対応のＳＰ
Ｕ４４−ｉとして動作するようにＳＰＵ４４−ｉの属性
変更を実施することができるので、時間毎に特定のサー
ビス種別対応のＳＰＵ４４−ｉを事前に確保しておくこ
とができる。従って、例えば、一般企業の業務開始時や
昼休み終了時，電話やインターネットでのチケット予約
販売など、特定の日時に大量のトラフィックの発生が想
定される特異なケースでも、ＳＰＵ実装数を従来よりも
大幅に削減しながら、呼損率を最小限に抑制することが
できる。

【０１０７】（３）その他なお、上述した実施形態では、マルチメディア信号処理
装置がＡＴＭ交換機として構成されている場合を例にし
たが、本発明は、これに限定されず、他の種類の交換装
置や呼処理装置として構成されていても、上述した実施
形態と同様の作用効果が得られる。

【０１０８】また、上述した実施形態では、保守コンソ
ール６からＡＴＭ交換機４に対してＳＰＵ属性変更指示
などの各種設定を行なっているが、勿論、他の任意の制
御装置から行なうようにしてもよい。さらに、上述した
実施形態のＳＰＵ４４−ｉは、複数種類のサービス種別
に応じた複数種類のプログラム（ファームウェア）を選
択的にＣＰＵ６５及びＤＳＰモジュール６８−ｊにロー
ドする構成を採ることで、複数種類のサービス種別対応
のＳＰＵ４４−ｉを実現しているが、複数種類のサービ
ス種別対応のＳＰＵ４４−ｉが実現できれば、必ずしも
このような構成を採る必要はない。

【０１０９】例えば、予め複数種類のサービス種別に対
応したＤＳＰモジュールを用意するなど、サービス種別
に応じた複数の信号処理手段を用意しておき、要求サー
ビス種別に応じてこれらの信号処理手段のいずれかを単
純に選択するという構成を採っても良い。ただし、上述
した実施形態の構成を採った方が、前述したように、実
装すべきＤＳＰモジュール数をサービス種別数よりも少
なくすることができるので有利である。

【０１１０】また、上述した例では、便宜上、１枚のＳ
ＰＵ４４−ｉが１チャンネル分の呼を処理できる構成に
なっていることを前提にして説明したが、１枚のＳＰＵ
４４−ｉが複数チャンネル分の呼を処理できるだけの能
力を有している場合には、次のようなアルゴリズムを追
加することで対応可能である。即ち、上位ノード５から
の要求サービス種別と一致する属性のＳＰＵ４４−ｉを
検索する際、まず、要求サービス種別と一致し呼処理能
力に余裕のあるＳＰＵ４４−ｉを検索し、この条件を満
足するＳＰＵ４４−ｉが存在すれば、そのＳＰＵ４４−
ｉをサービス要求に対して割り当てるべきＳＰＵ４４−
ｉとして捕捉する。一方、上記の条件を満足するＳＰＵ
４４−ｉが存在しなければ、「空き状態」（呼が割り当
てられていない待機状態）の他のＳＰＵ４４−ｉの属性
を変更した上で、そのＳＰＵ４４−ｉサービス要求に対
して割り当てるべきＳＰＵ４４−ｉとして捕捉する。

【０１１１】このようなアルゴリズムにより、上位ノー
ド５からのサービス要求毎に、要求サービス種別と一致
し処理能力に余裕のあるＳＰＵ４４−ｉに、新たな呼が
割り当てられてゆき、要求サービス種別と一致し処理能
力に余裕のあるＳＰＵ４４−ｉが存在しなくなると、新
たに要求サービス種別対応の空きＳＰＵ４４−ｉが捕捉
されて呼が割り当てられてゆくことになる。

【０１１２】そして、本発明は、上述した実施形態に限
定されるものではなく、上記以外にも本発明の趣旨を逸
脱しない範囲で種々変形して実施することができる。

【０１１３】

【発明の効果】以上詳述したように、本発明のマルチメ
ディア信号処理装置（請求項１）によれば、通信サービ
スユニットの信号処理モードが、呼のサービス種別に適
したモードに制御されるので、予めサービス種別毎に最
大トラフィックをカバーできるだけの専用の通信サービ
スユニットを実装しておく必要がない。また、或るサー
ビス種別のトラフィックに対して通信サービスユニット
が不足した場合でも、他のサービス種別に適したモード
で動作していた他の通信サービスユニットのモードを不
足の生じたサービス種別対応のモードに変更すること
で、不足分を充足することができる。従って、次のよう
な利点（１）〜（４）が得られる。

【０１１４】（１）サービス種別毎に専用の通信サービ
スユニットを実装する場合、即ち、サービス種別毎の通
信サービスユニット割り当て数が固定である場合に比し
て、通信サービスユニットの必要実装数を大幅に削減す
ることができて、本装置の大幅な小型化を図ることが可
能である。（２）本装置の製造元にとっては、サービス種別毎に専
用の通信サービスユニットを製造する必要がないので、
多品種の製造及びメンテナンスから少品種の製造及びメ
ンテナンスに移行することができ、コストダウン及び保
守の品質向上を図ることができる。

【０１１５】（３）通信サービスユニットがサービス種
別に依存しないので、サービス種別毎に専用の通信サー
ビスユニットを実装する場合に比して、トラフィックの
許容量が大きくなり、呼損率を低く抑えることができ
る。この結果、ユーザにとっては、接続性が大幅に向上
することになる。（４）本装置の建局時における通信サービスユニット実
装数の算出根拠について、トラフィック量を推定するだ
けでよく、通常、実施されている各サービス種別毎の周
辺上位ノードからの要求トラフィック量の分析は不要と
なる。また、運用状態となった場合でも、各サービス毎
のメンテナンスは不要となり、ピーク時のトラフィック
に対する通信サービスユニットの過不足の対応のみで済
む。

【０１１６】なお、上記のモード制御は、外部装置から
のモード設定指示に応じて適宜に設定・変更することも
できるので、通信サービスユニットのフレキシブルな使
用が可能になる（請求項２）。また、上記のモード制御
は、過去のモード制御についての履歴に基づいて、或る
時期のトラフィック傾向を予測し、その予測に応じて実
施することもできるので、さらなる通信サービスユニッ
トの実装数削減および呼損率の低減に大きく寄与する
（請求項３）。

【０１１７】ここで、上記の予測型のモード制御では、
或る特定の時間帯に特定のサービス種別のトラフィック
が増大することが事前に分かっている場合などにおい
て、その時間帯には通信サービスユニットのモードをそ
のサービス種別に適したモードに設定するといった時刻
要因による制御を行なうこともできるので、時間毎に特
定のサービス種別対応の通信サービスユニットを事前に
確保しておくことができ、さらに呼損率の低減を図るこ
とができる（請求項４）。

【０１１８】ところで、上記の通信サービスユニット
は、複数種類の通信サービス種別に応じた複数種類の通
信サービス制御プログラムの中から、信号処理モード制
御指示に応じて対応するプログラムを選択的にロードす
ることにより、自身の信号処理モードを制御するように
してもよく、このようにすれば、複数種類の通信サービ
ス制御回路を個別にそなえる場合に比して、最小限のハ
ードウェア規模で、複数種類の通信サービス種別に対応
可能な通信サービスユニットを実現することができ、本
マルチメディア信号処理装置をさらに小型に実現できる
（請求項５）。

【図面の簡単な説明】

【図１】本発明の一実施形態に係る移動体通信網の構成
を示すブロック図である。

【図２】本発明の一実施形態に係るマルチメディア信号
処理装置としてのＡＴＭ交換機の構成を示すブロック図
である。

【図３】図２に示すＡＴＭ交換機の要部に着目した構成
を示すブロック図である。

【図４】図３に示すＳＰＵ状態管理部の構成を示すブロ
ック図である。

【図５】（Ａ）は本実施形態に係るＳＰＵ状態管理デー
タの一例を示す図、（Ｂ）は本実施形態に係る時刻対応
属性管理データの一例を示す図である。

【図６】本実施形態に係る履歴情報（統計情報）の一例
を示す図である。

【図７】図２及び図３に示すＳＰＵの詳細構成例を示す
ブロック図である。

【図８】図７に示すフラッシュメモリの記憶内容及びフ
ラッシュメモリからのロード動作を説明するための図で
ある。

【図９】本実施形態のＡＴＭ交換機の動作（ＳＰＵ属性
変更手順）を説明するためのシーケンス図である。

【図１０】本実施形態のＳＰＵの動作を説明するための
シーケンス図である。

【図１１】本実施形態のＡＴＭ交換機の動作（時刻要因
によるＳＰＵ属性変更手順）を説明するためのシーケン
ス図である。

【図１２】本実施形態のＡＴＭ交換機の動作（呼毎のＳ
ＰＵ属性自動設定処理手順）を説明するためのシーケン
ス図である。

【図１３】本実施形態のＡＴＭ交換機の動作（捕捉ＳＰ
Ｕの解放処理手順）を説明するためのシーケンス図であ
る。

【図１４】図２及び図３に示すＳＰＵ状態管理部の動作
を説明するためのフローチャートである。

【図１５】図２及び図３に示すＳＰＵ状態管理部の動作
を説明するためのフローチャートである。

【図１６】図２及び図３に示すＳＰＵ状態管理部の動作
（非時刻要因ＳＰＵ属性変更手順）を説明するためのフ
ローチャートである。

【図１７】図２及び図３に示すＳＰＵ状態管理部の動作
（時刻要因ＳＰＵ属性変更手順）を説明するためのフロ
ーチャートである。

【図１８】図２及び図３に示すＳＰＵ状態管理部の動作
（ＳＰＵ捕捉要求時）を説明するためのフローチャート
である。

【図１９】図２及び図３に示すＳＰＵ状態管理部の動作
（ＳＰＵ解放要求時）を説明するためのフローチャート
である。

【図２０】図２及び図３に示すＳＰＵ状態管理部の動作
（ＳＰＵ属性変更手順）を説明するためのフローチャー
トである。

【図２１】図２及び図３に示すＳＰＵ状態管理部の動作
（時刻要因指定有りの場合）を説明するためのフローチ
ャートである。

【図２２】（Ａ），（Ｂ）はいずれもＳＰＵの初期設定
（サービス種別毎のＳＰＵ割り当て割合）を説明するた
めの図である。

【図２３】既存の公衆交換網（トリー型網）の一例を模
式的に示す図である。

【図２４】マルチメディア信号処理装置（交換装置）の
一例を示すブロック図である。

【符号の説明】

１移動局（ＭＳ：Mobile Station）２無線基地局（ＢＴＳ：Base Transceiver Station）３無線ネットワーク制御装置（ＲＮＣ： Radio Netwo
rk Controller）４マルチメディア信号処理装置〔ＭＰＥ（Multimedia
signal Processing Equipment）；ＡＴＭ（Asynchrono
us Transfer Mode）交換機〕５移動マルチメディア交換システム〔ＭＭＳ（Mobile
Multimedia switching System）；上位ノード〕６オペレーションシステム〔ＯＰＳ（Operation Syst
em）；保守コンソール（外部装置）〕７ａＡＴＭ網７ｂＬＡＮ（Local Area Network）１０移動体通信網４１ＡＴＭスイッチ４２ＡＴＭインタフェース（ＡＴＭ−ＩＦ）４３ＬＡＮ（Local Area Network）インタフェース
（ＬＡＮ−ＩＦ）４４−１〜４４−ＮＳＰＵ（Service Protocol Uni
t；通信サービスユニット）４５主制御部４５ａ呼制御部４５ｂサービス決定部（通信サービス種別識別手段）４５ｃＳＰＵ状態管理部（モード制御手段）４５ｄＳＰＵ状態管理受付部４５ｅＳＰＵサービス変更部５２履歴情報管理部５３時刻要因属性変更部６０ａ制御系ネットワーク６０ｂ通信系ネットワーク（セルバス）６１通信系インタフェース（ＩＦ）回路６２制御系インタフェース（ＩＦ）回路６３通信用デュアルポートＲＡＭ６４ＳＡＲ（Structure And Restructure）部６５ＣＰＵ〔ＳＰＵ属性変更部（モード選択制御
部）〕６６フラッシュメモリ（記憶部）６７ＲＡＭ６８−１〜６８−ｍＤＳＰ（Digital Signal Process
or）モジュール６９ＩＰＬ（Initial Program Load）メモリ（ＲＡ
Ｍ）７０プログラムメモリ（ＲＡＭ）１００公衆交換網１３０集中局１４０端局４５１ＳＰＵ状態管理データ４５１ａＳＰＵ状態データ４５１ｂ外部指定属性種別データ４５１ｃ外部指定属性データ４５１ｄカレント属性データ４５２時刻対応属性管理データ４５２ａ指定時刻データ４５２ｂ時刻対応属性データ４５３統計情報（履歴情報）６６１ＩＰＬ領域６６２ＣＰＵファームウェア領域６６３ＤＳＰファームウェア領域６６２−１パケット用ＣＰＵファームウェア６６２−２音声用ＣＰＵファームウェア６６２−３ＩＳＤＮ（Integrated Services Digital
Network）用ＣＰＵファームウェア６６２−４ＰＩＡＦＳ（PHS Internet Access Forum
Standard）用ＣＰＵファームウェア６６２−５ＰＰＰ（Point to Point Protocol）用Ｃ
ＰＵファームウェア６６２−６ＦＡＸ用ＣＰＵファームウェア６６２−７モデム用ＣＰＵファームウェア６６２−８，６６３−８予備のファームウェア６６３−１パケット用ＤＳＰファームウェア６６３−２音声用ＤＳＰファームウェア６６３−３ＩＳＤＮ用ＤＳＰファームウェア６６３−４ＰＩＡＦＳ用ＤＳＰファームウェア６６３−５ＰＰＰ用ＤＳＰファームウェア６６３−６ＦＡＸ用ＤＳＰファームウェア６６３−７モデム用ＤＳＰファームウェア

───────────────────────────────────────────────────── フロントページの続き (72)発明者執行聖之福岡県福岡市早良区百道浜２丁目２番１号富士通西日本コミュニケーション・システムズ株式会社内 (72)発明者高比良幸理福岡県福岡市早良区百道浜２丁目２番１号富士通西日本コミュニケーション・システムズ株式会社内 (72)発明者佐藤淳児福岡県福岡市早良区百道浜２丁目２番１号富士通西日本コミュニケーション・システムズ株式会社内 (72)発明者米沢九州男福岡県福岡市早良区百道浜２丁目２番１号富士通西日本コミュニケーション・システムズ株式会社内 (72)発明者川上英利福岡県福岡市早良区百道浜２丁目２番１号富士通西日本コミュニケーション・システムズ株式会社内 (72)発明者河瀬浩司福岡県福岡市早良区百道浜２丁目２番１号富士通西日本コミュニケーション・システムズ株式会社内 (72)発明者伊藤寛神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内Ｆターム(参考） 5K030 HB19 HB21 LB13 LD00 LD18 LE16 LE17 5K034 AA17 CC01 CC02 CC05 HH63 JJ02 JJ24 QQ07 5K051 AA01 AA05 BB01 BB02 CC15 FF07 JJ00 5K067 AA12 EE16 FF02 GG11 HH05 HH11 HH22 HH23 JJ11 JJ31

Claims

【特許請求の範囲】

【請求項１】複数種類の通信サービス種別に応じた複
数種類の信号処理モードを有する通信サービスユニット
と、上位ノードから通知される或る呼についての信号処理要
求情報に基づいて該呼の通信サービス種別を識別する通
信サービス種別識別手段と、該通信サービスユニットの信号処理モードを該通信サー
ビス種別識別部で識別された通信サービス種別に適した
モードに制御するモード制御手段とをそなえて成ること
を特徴とする、マルチメディア信号処理装置。
【請求項２】該モード制御手段が、外部装置からのモード設定指示に応じて該通信サービス
ユニットの信号処理モードを制御する外部指示型モード
制御手段をそなえていることを特徴とする、請求項１記
載のマルチメディア信号処理装置。
【請求項３】該モード制御手段が、過去に行なったモード制御についての履歴情報を管理す
る履歴情報管理手段と、該履歴情報に基づいて該通信サービスユニットの信号処
理モードを予測制御する予測型モード制御手段とをそな
えていることを特徴とする、請求項１記載のマルチメデ
ィア信号処理装置。
【請求項４】該予測型モード制御手段が、該履歴情報に基づいた時刻情報とモード設定情報とに基
づいて、指定時刻に該通信サービスユニットのモードを
該モード設定情報に応じたモードに制御する時刻要因モ
ード制御手段をそなえていることを特徴とする、請求項
３記載のマルチメディア信号処理装置。
【請求項５】該通信サービスユニットが、該複数種類の通信サービス種別に応じた複数種類の通信
サービス制御プログラムを記憶した記憶手段と、該モード制御手段からの信号処理モード制御指示に応じ
て対応する通信サービス制御プログラムを該記憶手段か
ら選択的にロードすることにより、自身の信号処理モー
ドを制御するモード選択制御手段とをそなえて構成され
たことを特徴とする、請求項１〜４のいずれか１項に記
載のマルチメディア信号処理装置。