(57)【要約】【課題】集中リソース管理機能を持つことなく、システムを容易に構築し、呼制御プロセッサの増設によるシステムの拡張性を確保し、ユーザデータ処理部それぞれの能力を呼制御部から隠蔽可能なネットワーク機器を提供する。【解決手段】ユーザデータ処理部３１〜３３各々は自回路のリソースを自身で管理し、セッション確立のために送信されるＣプレーン２からの呼設定要求に応答する際、セッション解放のために送信されるＣプレーン２からの呼解放要求に応答する際、Ｃプレーン２からのヘルスチェック信号に応答する際、自回路の使用可能なリソース率をその応答メッセージに付加してＣプレーン２へ通知する。Ｃプレーン２は入手した各ユーザデータ処理部３１〜３３の使用可能なリソース率を保持し、余剰のあるユーザデータ処理部３１〜３３を選択し、セッション確立のための呼設定要求を送信する。【選択図】      図１
2004241948.tif 000002
【特許請求の範囲】
【請求項１】
呼制御手段にて発着呼を制御し、ユーザデータ処理手段にてユーザデータのカプセリング・デカプセリングを行ってパケット通信を行うパケット通信システムであって、
前記ユーザデータ処理手段に設けられかつ前記ユーザデータ処理手段のリソースを管理するリソース管理手段を有することを特徴とするパケット通信システム。
【請求項２】
前記リソース管理手段は、少なくとも前記ユーザデータ処理手段の帯域リソース及びセッション数リソースにおいて余剰な帯域及びセッション数の割合を示す使用可能なリソース率を管理することを特徴とする請求項１記載のパケット通信システム。
【請求項３】
前記リソース管理手段から通知される前記ユーザデータ処理手段の前記使用可能なリソース率を記憶する記憶手段を前記呼制御手段に含むことを特徴とする請求項２記載のパケット通信システム。
【請求項４】
前記ユーザデータ処理手段は、前記使用可能なリソース率を前記呼制御手段への応答信号に付加して送信することを特徴とする請求項２または請求項３記載のパケット通信システム。
【請求項５】
前記ユーザデータ処理手段は、前記呼制御手段からセッション確立のために送信されてくる呼設定要求に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項４記載のパケット通信システム。
【請求項６】
前記ユーザデータ処理手段は、前記呼制御手段からセッション解放のために送信されてくる呼解放要求に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項４または請求項５記載のパケット通信システム。
【請求項７】
前記ユーザデータ処理手段は、前記呼制御手段から前記ユーザデータ処理手段の状態確認のために送信されてくるヘルスチェック信号に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項４から請求項６のいずれか記載のパケット通信システム。
【請求項８】
前記呼制御手段は、前記使用可能なリソース率を基に余剰のあるユーザデータ処理手段を選択してセッション確立のための呼設定要求を送信することを特徴とする請求項２から請求項６のいずれか記載のパケット通信システム。
【請求項９】
呼制御手段にて発着呼を制御し、ユーザデータ処理手段にてユーザデータのカプセリング・デカプセリングを行ってパケット通信を行うネットワーク機器であって、
前記ユーザデータ処理手段に設けられかつ前記ユーザデータ処理手段のリソースを管理するリソース管理手段を有することを特徴とするネットワーク機器。
【請求項１０】
前記リソース管理手段は、少なくとも前記ユーザデータ処理手段の帯域リソース及びセッション数リソースにおいて余剰な帯域及びセッション数の割合を示す使用可能なリソース率を管理することを特徴とする請求項９記載のネットワーク機器。
【請求項１１】
前記リソース管理手段から通知される前記ユーザデータ処理手段の使用可能なリソース率を記憶する記憶手段を前記呼制御手段に含むことを特徴とする請求項９または請求項１０記載のネットワーク機器。
【請求項１２】
前記ユーザデータ処理手段は、前記使用可能なリソース率を前記呼制御手段への応答信号に付加して送信することを特徴とする請求項１０または請求項１１記載のネットワーク機器。
【請求項１３】
前記ユーザデータ処理手段は、前記呼制御手段からセッション確立のために送信されてくる呼設定要求に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項１２記載のネットワーク機器。
【請求項１４】
前記ユーザデータ処理手段は、前記呼制御手段からセッション解放のために送信されてくる呼解放要求に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項１２または請求項１３記載のネットワーク機器。
【請求項１５】
前記ユーザデータ処理手段は、前記呼制御手段から前記ユーザデータ処理手段の状態確認のために送信されてくるヘルスチェック信号に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項１２から請求項１４のいずれか記載のネットワーク機器。
【請求項１６】
前記呼制御手段は、前記使用可能なリソース率を基に余剰のあるユーザデータ処理手段を選択してセッション確立のための呼設定要求を送信することを特徴とする請求項１０から請求項１５のいずれか記載のネットワーク機器。
【請求項１７】
呼制御手段にて発着呼を制御し、ユーザデータ処理手段にてユーザデータのカプセリング・デカプセリングを行ってパケット通信を行うネットワーク機器のリソース管理方法であって、前記ユーザデータ処理手段側に、前記ユーザデータ処理手段のリソースを管理する処理を有することを特徴とするリソース管理方法。
【請求項１８】
前記リソースを管理する処理は、少なくとも前記ユーザデータ処理手段の帯域リソース及びセッション数リソースにおいて余剰な帯域及びセッション数の割合を示す使用可能なリソース率を管理することを特徴とする請求項１７記載のリソース管理方法。
【請求項１９】
前記リソースを管理する処理から通知される前記ユーザデータ処理手段の前記使用可能なリソース率を前記呼制御手段の記憶手段に記憶することを特徴とする請求項１８記載のリソース管理方法。
【請求項２０】
前記ユーザデータ処理手段が、前記使用可能なリソース率を前記呼制御手段への応答信号に付加して送信することを特徴とする請求項１８または請求項１９記載のリソース管理方法。
【請求項２１】
前記ユーザデータ処理手段が、前記呼制御手段からセッション確立のために送信されてくる呼設定要求に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項２０記載のリソース管理方法。
【請求項２２】
前記ユーザデータ処理手段が、前記呼制御手段からセッション解放のために送信されてくる呼解放要求に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項２０または請求項２１記載のリソース管理方法。
【請求項２３】
前記ユーザデータ処理手段が、前記呼制御手段から前記ユーザデータ処理手段の状態確認のために送信されてくるヘルスチェック信号に対する応答メッセージに前記使用可能なリソース率を付加して送信することを特徴とする請求項２０から請求項２２のいずれか記載のリソース管理方法。
【請求項２４】
前記呼制御手段が、前記使用可能なリソース率を基に余剰のあるユーザデータ処理手段を選択してセッション確立のための呼設定要求を送信することを特徴とする請求項１８から請求項２３のいずれか記載のリソース管理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はパケット通信システム、ネットワーク機器及びそれに用いるリソース管理方法に関し、特にパケット通信システムにおけるリソースの管理方法に関する。
【０００２】
【従来の技術】
従来、パケット通信システムにおいては、図７に示すように、移動機３と、Ｎｏｄｅ−Ｂ（無線基地局）４と、ＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）５と、ＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  ＳｕｐｐｏｒｔＮｏｄｅ）７と、Ｗｅｂサーバ８と、ＳＧＳＮ［Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ］９と、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網１００と、ＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）や企業ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）２００とから構成されている（例えば、非特許文献１参照）。
【０００３】
ＳＧＳＮ９はＲＮＣ５とＧＧＳＮ７との間に位置し、移動ユーザとＩＳＰや企業ＬＡＮ２００内に存在するＷｅｂサーバ８等との間で行われるパケット通信において、ユーザデータをカプセリングして中継している。カプセリングにはＧＴＰ（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）が用いられている。
【０００４】
ＳＧＳＮ９は上記のパケット通信システムにおけるコアネットワークノードであり、そのＣプレーン（呼制御部）は複数の呼処理プロセッサ９２，９３と、それらへの信号を分配する負荷分散装置９１と、リソース管理プロセッサ９４と、保守機能を提供する保守運用部９５とから構成され、Ｕプレーンはユーザデータ処理部９６〜９８から構成されている。ここで、Ｃプレーンはシグナリングを制御するためのものであり、Ｕプレーンはユーザデータを転送するためのものである（例えば、非特許文献２参照）。
【０００５】
リソース管理プロセッサ９４は各ユーザデータ処理部９２，９３のリソースの有無を記憶するメモリ９４１を備えている。ユーザデータ処理部９６〜９８はユーザデータのカプセリング・デカプセリングを行うＧＴＰプロトコル部９６１，９７１，９８１を備えている。
【０００６】
システムの再開時に、リソース管理プロセッサ部９４はシステム内部に存在するすべてのユーザデータ処理部９６〜９８の存在を認識する。これにはユーザデータ処理部９６〜９８からリソース管理プロセッサ９４へのメッセージ送信による通知方式、またはリソース管理プロセッサ９４の管理するデータベースにてシステム内部に存在する全てのユーザデータ処理部９６〜９８の存在を記憶し、それを読出す方式のいずれかが利用される。
【０００７】
リソース管理プロセッサ部９４はシステム内部に存在する全てのユーザデータ処理部９６〜９８に関して、メモリ９４１にリソースを記憶するための領域を確保する。
【０００８】
呼設定信号の受信時に、呼処理プロセッサ９２はリソース管理プロセッサ９４に対してユーザデータ処理部の決定と帯域・セッションの確保とを要求する。リソース管理プロセッサ９４はメモリ９４１上のユーザデータ処理部９６〜９８のリソース情報を確認し、要求された帯域・セッションを確保することができるかどうかを判断する。
【０００９】
リソース管理プロセッサ９４は帯域・セッションが確保可能であれば、ユーザデータ処理部９６を選択し、確保したリソースをメモリ９４１上に記憶し、確保したリソースの情報を呼処理プロセッサ９２に返送する。呼処理プロセッサ９２は確保したリソースの情報を受信すると、そのユーザデータ処理部９６内のＧＴＰプロトコル部９６１に対して呼設定要求を送信する。
【００１０】
呼解放信号の受信時に、呼処理プロセッサ９２は保持している呼制御情報によって利用しているユーザデータ処理部９６を特定する。そして、そのユーザデータ処理部９６及びＧＴＰプロトコル部９６１に対して解放要求を送信する。そして、呼処理プロセッサ９２は該当ユーザデータ処理部９６の帯域・セッションを解放するために、リソース管理プロセッサ９４にリソース解放を要求する。リソース管理プロセッサ９４は解放要求を受信すると、メモリ９４１上に記憶している該当呼の帯域・セッションを解放する。
【００１１】
一方、パケット通信としてはＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｔｒａｎｓｆｅｒ  Ｍｏｄｅ：非同期通信モード）による通信方式があるが、この通信方式においても、上記と同様に、呼処理制御機能の下に帯域管理記憶装置を備え、帯域管理を行っている（例えば、特許文献１参照）。
【００１２】
【特許文献】
特開２０００−４２３４号公報（第５，６頁、図１）
【非特許文献１】
３ＧＰＰ  ＴＳ２３．０６０  Ｖ３．１４．０（２００２−１２），５．４章“Ｌｏｇｉｃａｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ”
【非特許文献２】
３ＧＰＰ  ＴＳ２３．０６０  Ｖ３．１４．０（２００２−１２），５．６章“Ｕｓｅｒ  ａｎｄ  Ｃｏｎｔｒｏｌ  Ｐｌａｎｅｓ”
【００１３】
【発明が解決しようとする課題】
しかしながら、上述した従来のリソース管理方法では、リソース管理プロセッサを持つため、複数の呼処理プロセッサからの信号がそこに集中し、呼処理プロセッサを増設していくと、リソース管理プロセッサの処理能力が追いつかなくなって、システムの拡張性に限界が生じてしまう。
【００１４】
また、従来のリソース管理方法では、リソース管理プロセッサにて全てのユーザデータ処理部の処理帯域・処理セッション数を集中管理するため、能力の異なるユーザデータ処理部をシステムに搭載する際に、呼制御部とユーザデータ処理部との間で、情報の一致化・連携が必要になるという問題がある。上記の特許文献１に記載の技術でも、この点は同様である。
【００１５】
そこで、本発明の目的は上記の問題点を解消し、集中リソース管理機能を持つことなく、システムを構築することができ、呼制御プロセッサの増設によるシステムの拡張性を確保し、ユーザデータ処理部それぞれの能力を呼制御部から隠蔽することができるパケット通信システム、ネットワーク機器及びそれに用いるリソース管理方法を提供することにある。
【００１６】
【課題を解決するための手段】
本発明によるパケット通信システムは、呼制御手段にて発着呼を制御し、ユーザデータ処理手段にてユーザデータのカプセリング・デカプセリングを行ってパケット通信を行うパケット通信システムであって、
前記ユーザデータ処理手段に設けられかつ前記ユーザデータ処理手段のリソースを管理するリソース管理手段を備えている。
【００１７】
本発明によるネットワーク機器は、呼制御手段にて発着呼を制御し、ユーザデータ処理手段にてユーザデータのカプセリング・デカプセリングを行ってパケット通信を行うネットワーク機器であって、
前記ユーザデータ処理手段に設けられかつ前記ユーザデータ処理手段のリソースを管理するリソース管理手段を備えている。
【００１８】
本発明によるリソース管理方法は、呼制御手段にて発着呼を制御し、ユーザデータ処理手段にてユーザデータのカプセリング・デカプセリングを行ってパケット通信を行うネットワーク機器のリソース管理方法であって、前記ユーザデータ処理手段側に、前記ユーザデータ処理手段のリソースを管理する処理を備えている。
【００１９】
すなわち、本発明のパケット通信システムは、システム内のネットワーク機器において、複数のプロセッサからなる呼制御部（Ｃプレーン）と、複数のユーザデータ処理部とを論理的・物理的に分離し、ユーザデータ処理部の帯域リソース・セッション数によるリソースの管理（捕捉、解放）を呼制御部で行わないようにしている。
【００２０】
また、本発明のパケット通信システムでは、ユーザデータ処理部各々の帯域リソース・セッション数リソースを、それぞれのユーザデータ処理部自身が管理（捕捉、解放）している。
【００２１】
さらに、本発明のパケット通信システムでは、セッション確立のために送信される呼制御部からユーザデータ処理部への呼設定要求に対して、ユーザデータ処理部が応答する際に、ユーザデータ処理部の余剰帯域・余剰セッション数の状況（リソースに対する余剰な帯域及びセッション数の割合を示す使用可能なリソース率等を示し、以下、使用可能なリソース率とする）をこの応答メッセージに付加して呼制御部へ通知している。
【００２２】
さらにまた、本発明のパケット通信システムでは、セッション解放のために送信される呼制御部からユーザデータ処理部への呼解放要求に対して、ユーザデータ処理部が応答する際に、ユーザデータ処理部の使用可能なリソース率をこの応答メッセージに付加して呼制御部へ通知している。
【００２３】
呼制御部はユーザデータ処理部の状態（動作可能な状態かどうか）を確認するために、ヘルスチェック信号を送信し、ユーザデータ処理部がこの信号に応答する際に、ユーザデータ処理部の使用可能なリソース率をこの応答メッセージに付加して呼制御部へ通知している。
【００２４】
また、呼制御部は上記の処理にて入手した各ユーザデータ処理部の使用可能なリソース率を保持し、余剰のあるユーザデータ処理部を選択して、セッション確立のための呼設定要求を送信している。
【００２５】
従来、ユーザデータ処理部の能力については、呼制御部側において集中リソース管理機能を設け、そこで厳密に管理しており、さらにユーザデータ処理部内部のリソースに関する捕捉・解放についても、集中リソース管理機能にて実施している。
【００２６】
これに対し、本発明のパケット通信システムでは、ユーザデータ処理部の厳密な帯域・セッション数を呼制御部側で把握する必要がなくなり、従来、この管理機能を提供している集中リソース管理機能が不要となる。
【００２７】
従来、集中リソース管理機能はその性格上、複数の呼制御部からの信号を処理していたため、システム能力拡張の際のネックとなっているが、本発明のパケット通信システムでは、この集中リソース管理機能が不要となるため、システムの拡張性をより高めることが可能となる。
【００２８】
複数のユーザデータ処理部については、処理可能帯域・処理可能セッション数に関する能力が統一されていない場合、従来、呼制御部側では集中リソース管理機能によって、それぞれのユーザデータ処理部について、その能力を把握している必要がある。
【００２９】
これに対し、本発明のパケット通信システムでは、各呼制御部が各ユーザデータ処理部の余剰を把握しているだけなので、個別のユーザデータ処理部の能力を把握する必要はない。これによって、本発明のパケット通信システムでは、能力の違うユーザデータ処理部を組み合わせて容易にシステムを構築することが可能となる。
【００３０】
上述したように、本発明のパケット通信システムでは、リソースの厳密な管理機能を、呼制御部から追い出しているので、集中リソース管理機能を持つ必要がなく、より少ないプロセッサ台数によってシステムを構成することが可能となる。
【００３１】
また、本発明のパケット通信システムでは、集中リソース管理機能を持たないので、呼処理プロセッサの増設によるシステムの能力拡大を行っても、特定のプロセッサによって処理ネックが生じるのを避けることが可能となる。
【００３２】
さらに、本発明のパケット通信システムでは、リソースの厳密な管理機能を、ユーザデータ処理部が行っているので、呼制御部が個々のユーザデータ処理部の能力を明示的に意識する必要がなく、異なる能力を持つユーザデータ処理部を容易に混載することが可能となる。
【００３３】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。図１は本発明の実施の形態によるネットワーク機器の構成を示すブロック図である。図１において、ネットワーク機器１は複数のプロセッサ２１〜２３からなるＣプレーン（呼制御部）２と、複数のユーザデータ処理部３１〜３３からなるＵプレーン３０とから構成されている。ここで、Ｃプレーン２はシグナリングを制御するためのものであり、Ｕプレーン３０はユーザデータを転送するためのものである（例えば、非特許文献２参照）。
【００３４】
ネットワーク機器１においてはＣプレーン２と複数のユーザデータ処理部３１〜３３とを論理的・物理的に分離し、ユーザデータ処理部３１〜３３の帯域リソース・セッション数リソースの管理（捕捉、解放）をＣプレーン２で行わないようにしている。
【００３５】
すなわち、ユーザデータ処理部３１〜３３各々は、自回路の帯域リソース・セッション数リソースを自身で管理（捕捉、解放）している。また、ユーザデータ処理部３１〜３３各々はセッション確立のために送信されるＣプレーン２からの呼設定要求に応答する際、自回路の余剰帯域・余剰セッション数の状況（リソースに対する余剰な帯域及びセッション数の割合を示す使用可能なリソース率等を示し、以下、使用可能なリソース率とする）をその応答メッセージに付加してＣプレーン２へ通知している。
【００３６】
さらに、ユーザデータ処理部３１〜３３各々はセッション解放のために送信されるＣプレーン２からの呼解放要求に応答する際、自回路の使用可能なリソース率をその応答メッセージに付加してＣプレーン２へ通知している。
【００３７】
さらにまた、ユーザデータ処理部３１〜３３各々はＣプレーン２が自回路の状態（動作可能な状態かどうか）を確認するために送信するヘルスチェック信号に応答する際、自回路の使用可能なリソース率をその応答メッセージに付加してＣプレーン２へ通知している。
【００３８】
Ｃプレーン２は上記の処理によって入手した各ユーザデータ処理部３１〜３３の使用可能なリソース率を保持し、余剰のあるユーザデータ処理部３１〜３３を選択し、セッション確立のための呼設定要求を送信する。
【００３９】
図１においては、Ｃプレーン２の各プロセッサ２１〜２３と、ユーザデータ処理部３１〜３３とをバス形式で接続しているが、他にスイッチ形式で接続することも可能であり、その場合、Ｃプレーン２はスイッチを介して全てのユーザデータ処理部３１〜３３とコネクションを持つ。
【００４０】
従来、ユーザデータ処理部３１〜３３の能力については、Ｃプレーン２側において集中リソース管理機能を設け、そこで厳密に管理しており、さらにユーザデータ処理部３１〜３３内部のリソースに関する捕捉・解放についても、集中リソース管理機能にて実施している。
【００４１】
本実施の形態では、ユーザデータ処理部３１〜３３の厳密な帯域・セッション数をＣプレーン２側で把握する必要がなくなり、従来、この管理機能を提供していた集中リソース管理機能が不要となる。
【００４２】
従来、集中リソース管理機能は、その性格上、複数の呼制御部からの信号を処理しているため、システム能力拡張の際のネックとなっている。本実施の形態では、この集中リソース管理機能が不要となるため、システムの拡張性をより高めることができる。
【００４３】
複数のユーザデータ処理部３１〜３３については、処理可能帯域・処理可能セッション数に関する能力が統一されていない場合、従来、呼制御部側では、集中リソース管理機能によって、それぞれのユーザデータ処理部について、その能力を把握している必要がある。
【００４４】
本実施の形態では、Ｃプレーン２が各ユーザデータ処理部３１〜３３の余剰を把握しているだけなので、個別のユーザデータ処理部３１〜３３の能力を把握する必要はない。これによって、本実施の形態では、能力の違うユーザデータ処理部３１〜３３を組み合わせてシステムを容易に構築することができる。
【００４５】
このように、本実施の形態では、リソースの厳密な管理機能を、Ｃプレーン２から追い出しているので、従来のようなリソース管理プロセッサを持つ必要がなく、より少ない台数のプロセッサによってシステムを構成することができる。
【００４６】
また、本実施の形態では、従来のようなリソース管理プロセッサを持たないので、呼処理プロセッサの増設によるシステムの能力拡大を行っても、特定のプロセッサによって処理ネックが生じるのを避けることができる。
【００４７】
さらに、本実施の形態では、リソースの厳密な管理機能を、ユーザデータ処理部３１〜３３自身が行っているので、Ｃプレーン２が個々のユーザデータ処理部３１〜３３の能力を明示的に意識する必要がなく、異なる能力を持つユーザデータ処理部３１〜３３を容易に混載することができる。
【００４８】
図２は本発明の一実施例によるパケット通信システムの構成を示すブロック図である。図２においては、本発明の一実施例としての移動通信ネットワークのパケット通信システムにおけるＳＧＳＮ［Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ］６の構成を示している。
【００４９】
ＳＧＳＮ６はＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）５とＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）７との間に位置し、移動ユーザ（移動機３）とＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）や企業ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）２００内に存在するＷｅｂサーバ８等との間で行われるパケット通信において、ユーザデータをカプセリングして中継している。カプセリングにはＧＴＰ（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）が用いられている。
【００５０】
ＳＧＳＮ６とＧＧＳＮ７との間は直接接続することも可能であるが、一般的に、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網１００によって構成されるバックボーン網を介して接続される。
【００５１】
上記のパケット通信システムの構成及びそれに利用するプロトコルについては、第三世代移動通信の国際規格である３ＧＰＰ（３ｒｄ  ＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）  ＴＳ２３．０６０  Ｖ３．１４．０（２００２−１２），ＴＳ２９．０６０  Ｖ３．１５．０（２００２−１２）によって定義されている。ＲＮＣ５、ＧＧＳＮ７、Ｎｏｄｅ−Ｂ（無線基地局）４については、３ＧＰＰにて機能が定義されているため、その説明については省略する。
【００５２】
ＳＧＳＮ６は移動機３とＷｅｂサーバ８との間でのパケット通信を可能にするために、ＲＮＣ５／ＧＧＳＮ７との通信を行うＣプレーン（呼制御部）と、ユーザデータ処理部６６〜６８からなるＵプレーンとを持つ。
【００５３】
ユーザデータ処理部６６〜６８はＲＮＣ５から送信され、ＧＴＰにてカプセリングされたユーザデータのカプセリングを解き、新たにＧＧＳＮ７へ送信するためのカプセリングを行う。また逆に、ユーザデータ処理部６６〜６８はＧＧＳＮ７から送信され、ＧＴＰにてカプセリングされたユーザデータのカプセリングを解き（デカプセリング）、新たにＲＮＣ５へ送信するためのカプセリングを行う。
【００５４】
Ｃプレーンは複数の呼処理プロセッサ６２〜６４と、それらへ信号を分配する負荷分散装置６１と、保守機能を提供する保守運用部６５とからなる。呼処理プロセッサ６２〜６４は各ユーザデータ処理部６６〜６８の使用可能なリソース率の有無を記憶するメモリ６２１，６３１，６４１を持つ。
【００５５】
ユーザデータ処理部６６〜６８は自回路自身の帯域リソース・セッション数リソースの利用状況を管理し、Ｃプレーンからの要求にしたがってそれらリソースを捕捉・解放するリソース管理部６６１，６７１，６８１と、ユーザデータのカプセリング・デカプセリングを行うＧＴＰプロトコル部６６２，６７２，６８２とからなる。
【００５６】
図３〜図６は本発明の一実施例によるパケット通信システムの動作を示すシーケンスチャートである。これら図２〜図６を参照して本発明の一実施例によるパケット通信システムの動作について説明する。
【００５７】
呼処理プロセッサ部６２はシステム再開時に（図３のａ１）、ユーザデータ処理部６６〜６８からの同報通信（図３のａ２１〜ａ２４）にて、システム内部に存在するすべてのユーザデータ処理部６６〜６８の存在を認識する（図３のａ２）。
【００５８】
または、呼処理プロセッサ部６２はユーザデータ処理部６６〜６８から保守運用部６５に通知された信号（図３のａ３１，ａ３２）を保守運用部６５がシステム内部の全ての呼処理プロセッサ部６２〜６４へ通知することで（図３のａ３３〜ａ３５）、システム内部に存在するすべてのユーザデータ処理部６６〜６８の存在を認識する（図３のａ３）。
【００５９】
あるいは、呼処理プロセッサ部６２は保守運用部６５の管理するデータベース（図示せず）に記憶されている、システム内部に存在する全てのユーザデータ処理部６６〜６８の存在を読出し（図３のａ４１）、全ての呼処理プロセッサ部６２〜６４へ通知することで（図３のａ４２，ａ４３）、システム内部に存在するすべてのユーザデータ処理部６６〜６８の存在を認識する（図３のａ４）。
【００６０】
呼処理プロセッサ部６２はシステム内部に存在する全てのユーザデータ処理部６６〜６８に関して、使用可能なリソース率（以下、余剰リソース情報とする）を記憶するための領域をメモリ６２１に確保する。尚、図示していないが、他の呼処理プロセッサ部６３，６４も、上述した呼処理プロセッサ部６２の処理と同様の処理で、システム内部に存在する全てのユーザデータ処理部６６〜６８に関して、余剰リソース情報を記憶するための領域をメモリ６３１，６４１に確保する。
【００６１】
次に、呼処理プロセッサ部６２は呼設定信号を受信すると（図４のｂ０，ｂ１１）、メモリ６２１に保持しているユーザデータ処理部６６〜６８毎の余剰リソース情報を確認し、余剰の多いユーザデータ処理部（ここではユーザデータ処理部６６の余剰が多いものとする）を選択し（図４のｂ１２）、呼設定要求をユーザデータ処理部６６に送信する（図４のｂ２１）。
【００６２】
ユーザデータ処理部６６はその呼設定要求を受信すると、リソース管理部６６１において、要求された帯域・セッションが確保できるかどうかを判断する（図４のｂ２２）。リソース管理部６６１は要求された帯域・セッションが確保可能であれば、呼設定要求をＧＴＰプロトコル部６６２に送信する（図４のｂ２３）。
【００６３】
ユーザデータ処理部６６はリソース管理部６６１から呼設定応答が返ってくると（図４のｂ２４）、リソース管理部６６１から最新の余剰リソース情報を読出し（図４のｂ２５）、呼処理プロセッサ部６２への応答信号に設定し、自回路の余剰リソース情報をその応答メッセージに付加して呼処理プロセッサ部６２へ通知する（図４のｂ２６）。
【００６４】
呼処理プロセッサ部６２は呼設定要求に対する応答信号を受信した際、付加されているそのユーザデータ処理部６６の余剰リソース情報を取込み、メモリ６２１に保持しているユーザデータ処理部６６〜６８毎の余剰リソース情報を更新する（図４のｂ３１）。
【００６５】
また、呼処理プロセッサ部６２は呼設定要求に対して肯定応答を受信していた場合、そのユーザデータ処理部６２の識別情報を呼制御情報としてメモリ６２１に記憶する。尚、図示していないが、他の呼処理プロセッサ部６３，６４においても、上述した呼処理プロセッサ部６２の処理と同様の処理が行われる。
【００６６】
続いて、呼処理プロセッサ部６２は呼解放信号を受信すると（図５のｃ０，ｃ１１）、メモリ６２１に保持している呼制御情報によって、利用しているユーザデータ処理部６６を特定し（図５のｃ１２）、そのユーザデータ処理部６６に対して呼解放要求を送信する（図５のｃ２１）。
【００６７】
ユーザデータ処理部６６はその呼解放要求を受信すると、ＧＴＰプロトコル部６６２へ呼解放要求を送信する（図５のｃ２２）。ユーザデータ処理部６６はＧＴＰプロトコル部６６２から呼解放応答が返ってくると（図５のｃ２３）、リソース管理部６２１にて帯域・セッション数を解放する（図５のｃ２４）。
【００６８】
また、ユーザデータ処理部６６はリソース管理部６６１から最新の余剰リソース情報を読出し（図５のｃ２５）、呼処理プロセッサ部６２への応答信号に設定し、自回路の余剰リソース情報をその応答メッセージに付加して呼処理プロセッサ部６２へ通知する（図５のｃ２６）。
【００６９】
呼処理プロセッサ部６２は呼解放要求に対する応答信号を受信した際、付加されているそのユーザデータ処理部６６の余剰リソース情報を取込み、メモリ６２１に保持しているユーザデータ処理部６６〜６８毎の余剰リソース情報を更新する（図５のｃ３１）。
【００７０】
一方、呼処理プロセッサ６２はユーザデータ処理部６６〜６８のリソース管理部６６１，６７１，６８１からそれぞれ読出されたヘルスチェック情報を直接受信すると（図６のｄ１１〜ｄ１６）（図６のｄ１）、相乗りされているそのユーザデータ処理部６６〜６８の余剰リソース情報を取込み、メモリ６２１に保持しているユーザデータ処理部６６〜６８毎の余剰リソース情報を更新する（図６のｄ３１）（図６のｄ３）。
【００７１】
あるいは、呼処理プロセッサ６２は保守運用部６５がユーザデータ処理部６６〜６８にヘルスチェックを行って（図６のｄ２１，ｄ２２）、ユーザデータ処理部６６〜６８のリソース管理部６６１，６７１，６８１からそれぞれ読出されたヘルスチェック情報が保守運用部６５から送られてくると（図６のｄ２３〜ｄ２８）（図６のｄ２）、付加されているそのユーザデータ処理部６６〜６８の余剰リソース情報を取込み、メモリ６２１に保持しているユーザデータ処理部６６〜６８毎の余剰リソース情報を更新する（図６のｄ３１）（図６のｄ３）。
【００７２】
このように、本実施例では、リソースの管理機能をユーザデータ処理部６６〜６８各々に配置し、呼処理プロセッサ６２〜６４がその余剰帯域のみをメモリ６２１，６３１，６４１に記憶することで、集中リソース管理機能を持つことなく、システムを容易に構築することができ、呼処理プロセッサの増設によるシステムの拡張性を確保することができるとともに、ユーザデータ処理部６６〜６８それぞれの能力を呼処理プロセッサ６２〜６４から隠蔽することができる。
【００７３】
尚、本実施例では、呼処理プロセッサ６２〜６４のメモリ６２１，６３１，６４１にユーザデータ処理部６６〜６８の余剰リソース情報を記憶しているが、余剰リソース情報を記憶させないことも可能である。この場合、呼設定処理シーケンスにおいて、呼処理プロセッサ６２〜６４では複数あるユーザデータ処理部６６〜６８を単純に順番に選択することで、余剰リソース情報を記憶させないことが実現可能となる。
【００７４】
これによって、呼処理プロセッサ６２〜６４では呼の設定・解放やヘルスチェック処理の際に、ユーザデータ処理部６６〜６８から最新の余剰リソース情報を入手する必要がない。
【００７５】
また、本実施例では上記の処理手順をＳＧＳＮ６に適用した例について述べたが移動通信パケットネットワークにおける別のパケット交換ノードであるＧＧＳＮ７、移動通信ネットワークにおける別のノードであるＲＮＣ５、あるいは移動通信回線交換ネットワークにおけるノードであるＭＳＣ（Ｍｏｂｉｌｅ  Ｓｗｉｔｃｈｉｎｇ  Ｃｅｎｔｅｒ）に適用することも可能である。
【００７６】
【発明の効果】
以上説明したように本発明は、上記のような構成及び動作とすることで、集中リソース管理機能を持つことなく、システムを構築することができ、呼制御プロセッサの増設によるシステムの拡張性を確保し、ユーザデータ処理部それぞれの能力を呼制御部（Ｃプレーン）から隠蔽することができるという効果が得られる。
【図面の簡単な説明】
【図１】本発明の実施の形態によるネットワーク機器の構成を示すブロック図である。
【図２】本発明の一実施例によるパケット通信システムの構成を示すブロック図である。
【図３】本発明の一実施例によるパケット通信システムの動作を示すシーケンスチャートである。
【図４】本発明の一実施例によるパケット通信システムの動作を示すシーケンスチャートである。
【図５】本発明の一実施例によるパケット通信システムの動作を示すシーケンスチャートである。
【図６】本発明の一実施例によるパケット通信システムの動作を示すシーケンスチャートである。
【図７】従来例のパケット通信システムの構成を示すブロック図である。
【符号の説明】
１  ネットワーク機器
２  Ｃプレーン
３  移動機
４  Ｎｏｄｅ−Ｂ
５  ＲＮＣ
６  ＳＧＳＮ
７  ＧＧＳＮ
８  Ｗｅｂサーバ
２１〜２３  プロセッサ
３０  Ｕプレーン
３１〜３３，６６〜６８  ユーザデータ処理部
６１  負荷分散装置
６２〜６４  呼処理プロセッサ
６５  保守運用部
１００  ＩＰ網
２００  ＩＳＰや企業ＬＡＮ
６２１，６３１，６４１  メモリ
６６１，６７１，６８１  リソース管理部
６６２，６７２，６８２  ＧＴＰプロトコル部
【図１】
2004241948.tif 000003
【図２】
2004241948.tif 000004
【図３】
2004241948.tif 000005
【図４】
2004241948.tif 000006
【図５】
2004241948.tif 000007
【図６】
2004241948.tif 000008
【図７】
2004241948.tif 000009