JP3880451B2 - Ｒｓｖｐを用いた移動通信システム - Google Patents
Ｒｓｖｐを用いた移動通信システム Download PDFInfo
- Publication number
- JP3880451B2 JP3880451B2 JP2002144883A JP2002144883A JP3880451B2 JP 3880451 B2 JP3880451 B2 JP 3880451B2 JP 2002144883 A JP2002144883 A JP 2002144883A JP 2002144883 A JP2002144883 A JP 2002144883A JP 3880451 B2 JP3880451 B2 JP 3880451B2
- Authority
- JP
- Japan
- Prior art keywords
- state
- rsvp
- node
- message
- mobile communication
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
- H04W28/12—Flow control between communication endpoints using signalling between network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/826—Involving periods of time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/26—Resource reservation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、リソース予約プロトコル(Resource Reservation Protocol：RSVP)を用いた移動通信システムにおける、リソース制御方法に関する。
【０００２】
【従来の技術】
近年、移動通信技術の急速な発展によって、無線区間におけるデータ転送レートは飛躍的な向上を遂げている。このため、音声や低レートのパケット通信といった従来のサービスに加えて、ビデオ又は音楽のような大容量のリアルタイムデータの配信が可能になろうとしている。今後、大容量通信技術を用いた多彩なサービスが提供されると考えられる。大容量サービスをその品質を確保しつつ実現するためには、無線区間だけでなくネットワーク内の全てのノードにおいて、要求される品質(ＱｏＳ)を確保することが要求される。
【０００３】
リソース予約プロトコル(ＲＳＶＰ)は、通信時のＱｏＳを確保するためのプロトコルの一つであり、ＩＥＴＦ(Internet Engineering Task Force)がＲＦＣ２２０５により規定したものである。
【０００４】
ＲＳＶＰは、あるエンド−エンド間における通信の単位をセッション、各セッションにおけるデータストリームをフローと定義し、フローが通過するネットワーク内の全てのノードにおいて、帯域等のネットワークリソースを予め確保するためのプロトコルである。
【０００５】
フローの受信システムは送信システムとの間でＲＳＶＰメッセージの交換を行い、この過程において、受信システムと送信システムの間に存在する全てのノード（ＩＰネットワークにおけるルータなど）上のリソースが予約される。さらに、ＲＳＶＰでは、ＩＰネットワークのような動的なネットワークに柔軟に対応できるように、各ノードにおける予約状態を「ＲＳＶＰソフト状態」により管理しており、このＲＳＶＰソフト状態は定期的に発行されるリフレッシュメッセージにより常に最新の状態に更新される。
【０００６】
ＲＳＶＰは主にＩＰネットワークで使用されている。移動通信システムにおける使用例は未だなく、具体的な実施方法や問題点などはまだ明らかになっていない点が多い。
【０００７】
現在の移動通信システムにＲＳＶＰを適用することを仮定した場合のシステム例の概略を図１に示す。移動端末１０６は、コアネットワーク(Core Network:CN)１０１、無線ネットワークノード１０３〜１０５から構成される無線アクセスネットワーク(Radio Access Network:RAN)１０２を経由してサーバ１００にアクセスし、データのダウンロード等を行う。
【０００８】
コアネットワーク１０１内の各ノードにはＲＳＶＰが実装されているものとし、無線ネットワークノード１０３〜１０５のそれぞれにもＲＳＶＰが実装されている。このようなシステムにおいて、移動端末１０６がサーバ１００からデータのダウンロードを開始し、終了するまでの動作を簡単に説明する。
【０００９】
図２は、ＲＳＶＰの処理シーケンスを簡単に示したものである。図２は、移動端末がサーバから配信されるデータをダウンロードする様子を示したものであり、ＲＳＶＰに関する処理としては、大別して以下の３つに分けることができる。(１) セッション開始時におけるダウンロードパス上のリソース予約処理
(２) ダウンロード中における、ソフト状態のリフレッシュ
(３) セッション終了時のリソース開放処理
セッションを開始する際には、移動端末は適切なプロトコルを用いてデータ配信グループに参加するための処理を行う。サーバは、この処理を受け付けると、フローに関する経路情報(パスの予約内容)等を格納した“ＰＡＴＨ”と呼ばれるＲＳＶＰメッセージを移動端末に対して送信する。ＰＡＴＨメッセージは、移動端末へ到達する途中の全てのＲＳＶＰノード(コアネットワーク１０１内におけるＲＳＶＰを実装したノード，及び図１におけるＲＳＶＰが実装された無線ネットワークノード)上で解読され、そのＲＳＶＰノード上にＲＳＶＰソフト状態の一つであるＰＡＴＨ状態(パスの予約状態)を確立してゆく。
【００１０】
移動端末は、ＰＡＴＨメッセージを受信すると、リソース予約に関する情報(リソースの予約内容)を格納した“ＲＥＳＶ”と呼ばれるＲＳＶＰメッセージをサーバに対して送信する。ＰＡＴＨメッセージのときと同様に、ＲＥＳＶメッセージはサーバへ到達する途中の全てのＲＳＶＰノード上で解読され、そのノード上にＲＳＶＰソフト状態の一つであるＲＥＳＶ状態(リソースの予約状態)を確立してゆく。
【００１１】
このように、移動端末とサーバ間でＰＡＴＨメッセージとＲＥＳＶメッセージとの交換を行うことにより、移動端末とサーバとの間のパス上に存在する全ノードにおけるリソース予約が完了する。
【００１２】
リソースの予約が完了すると、サーバは移動端末に対してデータの送信を開始する。この間、各ノード上のＲＳＶＰのリソース予約状態(ＲＳＶＰソフト状態)は、常に最新の情報に更新(リフレッシュ)される。このため、ＲＳＶＰが定めるタイマ(リフレッシュタイマ)に基づき、サーバはＰＡＴＨメッセージを移動端末へ定期的に送信し、移動端末はＲＥＳＶメッセージをサーバへ定期的に送信する。
【００１３】
これによって、移動端末の移動あるいはネットワークノードの故障等によりフローの経路が動的に変化したり、移動端末によるリソース獲得要求(リソースの予約内容)が変更された場合でも、リソースの予約状態は常にそれに追随することができる。
【００１４】
セッションを終了する場合には、移動端末はサーバに対して“ＲＳＶＰ ＴＥＡＲ”と呼ばれるＲＳＶＰメッセージを、サーバは移動端末に対して“ＰＡＴＨＴＥＡＲ”と呼ばれるＲＳＶＰメッセージを送出する。セッション上の各ノードは、ＲＳＶＰ ＴＥＡＲメッセージ、ＰＡＴＨ ＴＥＡＲメッセージを受信すると、ノード上のリソース予約状態、パス状態の開放処理を行う。
【００１５】
なお、図２には記載していないが、セッション終了時には、必ずしもＲＳＶＰＴＥＡＲメッセージ、ＰＡＴＨ ＴＥＡＲメッセージを送信する必要はない。各ノードの予約状態は、所定時間内にリフレッシュメッセージを受信しない場合には、自律で状態を開放するからである。
【００１６】
【発明が解決しようとする課題】
上述した通り、動的に変化するネットワーク環境の中で、データフローに対して常に最適なＱｏＳを確保するためには、パス(フロー)上の各ノードにおけるリソースの予約状態を常に最新に更新する必要がある。このため、サーバ及び移動端末は、一定時間毎に及び予約状態が変化する毎に、リフレッシュ用のＰＡＴＨメッセージ又はＲＥＳＶメッセージ(これらをまとめて指す場合には「リフレッシュメッセージ」と表記することもある)を送信しなければならない。移動通信システムにおいては、特に、このリフレッシュ動作が問題となってくる。
【００１７】
移動通信システムが通常の通信システムとその性質を異にする要因は、端末装置(移動端末)の位置が頻繁に変更される点にある。即ち、移動端末がその位置を変えると、パスの経路の変化や無線状態の変化が起こる。このため、移動端末とサーバとの間でネットワーク内に必要なリソースを予約した後も、移動端末の移動による状態の変化に応じて頻繁に予約状態をリフレッシュする必要がある。さらに、上述したように、予約状態が変化しない場合でも、定常的にリフレッシュメッセージの交換を行う必要がある。
【００１８】
このように頻繁に通信経路や無線状態が変化することが予想される移動通信システムにおいては、これらの状態の変化に対してリソースの予約状態が追随するためにリフレッシュメッセージの送信間隔はごく短いものでなくてはならない。
【００１９】
これらの理由から、図１に示した移動端末とサーバとの間では非常に多くのリフレッシュメッセージが交換されることになる。すると、このリフレッシュ動作がコアネットワーク及び移動通信ネットワークのリソースを圧迫するという問題を引き起こす可能性があった。
【００２０】
また、サーバ等のデータ配信ノード(データ送信／受信ノード)は、コアネットワーク内に存在するのが一般的である。このような場合において、サーバと移動端末との間で頻繁にリフレッシュメッセージのやりとりを行ったとしても、実際に予約状態が変更されるのは移動端末に近い部分だけであるということが有り得る。この場合、コアネットワーク内の各ノードにおける予約状態にはなんらの変更がなく、同じ予約状態が単に更新されるだけとなる。コアネットワーク内のトポロジーは無線アクセスネットワークに比べて頻繁に変化するものではないと考えられるからである。従って、コアネットワーク内の各ノードが頻繁にリフレッシュメッセージを受信しても、それらは無駄にネットワークリソースを消費するだけで実効的には意味のないものとなってしまう。
【００２１】
言い換えると、図１に示した移動通信システムでは、リソースの予約状態のリフレッシュ周期が無線アクセスネットワークに合わせて短く設定された場合には、予約状態は無線アクセスネットワークの状態変化に適正に追随することができるが、無駄なリフレッシュメッセージがコアネットワークに流れ込み、ネットワークリソースを浪費する(図３(Ａ)参照)。一方、リフレッシュ周期がコアネットワークに合わせて長く設定された場合には、コアネットワークにおいて無駄なリフレッシュメッセージが減少するが、予約状態が無線アクセスネットワークの状態変化に追随できなくなる(図３(Ｂ)参照)。
【００２２】
以上のように、移動通信システムにＲＳＶＰの実装を試みた場合、２つの矛盾した要求を同時に実現する必要がある。すなわち、同一パス上であるにもかかわらず、移動端末に近い側では、移動端末の移動性に伴い、頻繁にリフレッシュメッセージを交換する必要があり、サーバに近い側では、逆にリフレッシュメッセージは最小限に抑え、ネットワークリソースを節約する必要がある。
【００２３】
本発明の目的は、ネットワークリソースの予約状態をネットワークの状態変化に柔軟に追随させることができる一方で、ネットワークリソースの有効利用を図ることができるＲＳＶＰを用いた移動通信システムを提供することである。
【００２４】
【課題を解決するための手段】
本発明は、上記目的を達成するために以下の構成を採用する。
【００２５】
本発明は、ＲＳＶＰを用いた移動通信システムであり、リソース予約プロトコルを実装したコアネットワークに接続される移動通信ネットワークと、
前記移動通信ネットワークに含まれる複数の無線ネットワークノードと、
前記コアネットワーク及び前記移動通信ネットワークを通過するデータ送信ノードとデータ受信ノードとの間のデータのフローに対するネットワークリソースをリソース予約プロトコルに基づいて予約する手段と、
前記フローに係るネットワークリソースの予約状態をリフレッシュする領域を前記フローが通過する所定の無線ネットワークノードを境としてコアネットワーク側と移動通信ネットワーク側とに分割し、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの頻度よりも高い頻度で行うリフレッシュ制御手段と、
を含む。
【００２６】
本発明によれば、リフレッシュ制御手段が移動通信ネットワーク側のリフレッシュをコアネットワーク側よりも高い頻度で行う。これによって、移動通信ネットワーク側の予約状態を移動通信ネットワークの状態の変化に追随させることができる。一方、コアネットワーク側のリフレッシュの頻度が移動通信ネットワーク側よりも抑えられることにより、無駄なリフレッシュメッセージの転送によるネットワークリソースの浪費を抑えることができる。
【００２７】
本発明のリフレッシュ制御手段は、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの周期よりも短い周期で行う、ように構成するのが好ましい。
【００２８】
また、本発明は、前記フローに対する前記移動通信ネットワークの状態の変化に応じて、前記境界となる無線ネットワークノードとしての境界ノードを変更する境界ノード変更手段をさらに含む、ように構成するのが好ましい。
【００２９】
このようにすれば、移動通信ネットワークの状態の変化に応じてリフレッシュが頻繁に行われる移動通信ネットワーク側の大きさを制御できる。これによって、リフレッシュメッセージの交換を頻繁に行う必要のある領域を可能な限り小さくすることができるので、移動通信ネットワークにおけるネットワークリソースの有効利用を図ることができる。
【００３０】
本発明における境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が上限値を上回った場合に、現在の境界ノードよりもコアネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、ように構成するのが好ましい。
【００３１】
また、本発明における境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が下限値を下回った場合に、現在の境界ノードよりも移動通信ネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、ように構成するのが好ましい。
【００３２】
【発明の実施の形態】
以下、図面を用いて本発明の実施形態を説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００３３】
〔概要〕
図４は、本発明による移動通信システムの例を示す図である。図４において、移動通信システムは、コアネットワーク(ＣＮ)１０と、無線アクセスネットワーク(ＲＡＮ)２０とを備える。ＣＮ１０は複数のノード(図示せず)を含んでおり、ＲＡＮ２０は複数の無線ネットワークノード２１(ＣＮ１０と移動端末４０との間に位置する無線ネットワークノード群)を含んでいる。
【００３４】
ＣＮ１０はデータ送受信ノード３０(例えば、データを配信するサーバ；以下、単に「ノード３０」という)を収容(接続)している。ノード３０がＲＡＮ２０に接続される移動端末４０との間でＣＮ１０及びＲＡＮ２０を介してデータ通信を行う場合、例えば、ノード３０から送信されるデータ(パケット)は、ＣＮ１０及びＲＡＮ２０において、ＩＰ宛先アドレスのような宛先情報に基づいて決定される転送経路(パス又はフロー)を通って移動端末４０に伝達される。
【００３５】
データのパス(フロー)は、ＣＮ１０において少なくとも１つのノードを通過し、ＲＡＮ２０において少なくとも１つの無線ネットワークノード２１を通過する。パスが通過する(パス上に位置する)ＣＮ１０内のノード及び無線ネットワークノード２１は、ノード３０からのデータを受信すると、そのデータに付加された宛先情報(ＩＰ宛先アドレス)に基づいて、そのデータを次ホップに相当するノード(次ノード)に転送する。このような転送処理がパス上の各ノードにて行われることにより、ノード３０からのデータが移動端末４０に到達する。移動端末４０からノード３０へデータを伝達する場合も、同様である。
【００３６】
上述したデータ通信(データの送受信)に対し、所望のＱｏＳを確保するため、パス(フロー)が通過する各ノードは、ＲＳＶＰを用いてパスに係るネットワークリソースを予約する。また、リソースの予約状態のリフレッシュを行う。このため、ＣＮ１０の各ノード及びＲＡＮ２０の各無線ネットワークノード２１は、ＲＳＶＰに基づいてフローに対するネットワークリソースを予約する手段としての機能を実装している。
【００３７】
ノード３０から移動端末４０へデータを伝送するためのフローについてリソースの予約処理が行われる場合には、ＰＡＴＨメッセージがノード３０から移動端末４０へ向けて送信され、ＲＥＳＶメッセージが移動端末４０からノード３０へ向けて送信される。また、ノード３０は、予約状態(ＰＡＴＨ状態)をリフレッシュするためのＰＡＴＨメッセージを周期的に移動端末４０へ向けて送信し、移動端末４０は、予約状態(ＲＥＳＶ状態)をリフレッシュするためのＲＥＳＶメッセージを周期的にノード３０へ向けて送信する。
【００３８】
これに対し、移動端末４０からノード３０へデータを伝達するためのフローについてリソースの予約処理が行われる場合には、ＰＡＴＨメッセージが移動端末４０からノード３０へ向けて送信され、ＲＥＳＶメッセージがノード３０から移動端末４０へ向けて送信される。また、移動端末４０は予約状態(ＰＡＴＨ状態)をリフレッシュするためのＰＡＴＨメッセージを周期的にノード３０へ向けて送信し、ノード３０は予約状態(ＲＥＳＶ状態)をリフレッシュするためのＲＥＳＶメッセージを周期的に移動端末４０へ向けて送信する。
【００３９】
即ち、フローの上流側のエンドに相当するノードはＰＡＴＨメッセージを下流側のエンドに相当するノードへ向けて送信し、フローの下流側のエンドに相当するノードはＲＥＳＶメッセージをフローの上流側のエンドに相当するノードへ向けて送信する。
【００４０】
従って、フローが通過するＣＮ１０及びＲＡＮ２０内の各ノードは、フローの上流側からＰＡＴＨメッセージを受信し、フローの下流側からＲＥＳＶメッセージを受信する。以降の説明は、ノード３０(データ送信ノード)から移動端末４０(データ受信ノード)へ向けてデータを伝送するためのフローを想定して説明する。但し、本発明は、移動端末４０(データ送信ノード)からノード３０(データ受信ノード)へデータを伝送するためのフローについてのリソース予約処理についても適用することができる。
【００４１】
即ち、本発明は、データ送信ノードとデータ受信ノードとの間でのコアネットワーク及び移動通信ネットワークを介したデータフローに対して適用されるものであり、このときのデータフローのデータの伝送方向を問わない。
【００４２】
ＣＮ１０の各ノード及びＲＡＮ２０の各無線ネットワークノード２１は、予約状態のリフレッシュ動作として、次の動作を行う。即ち、各ノードは、ノード３０及び／又は移動端末４０からのリフレッシュ用のＲＳＶＰメッセージ(ＰＡＴＨメッセージ，ＲＥＳＶメッセージ；以下、これらをまとめて指す場合には、「リフレッシュメッセージ」と表記する)を受信すると、そのリフレッシュメッセージを次ホップに相当するノードに転送する。このとき、メッセージに含まれた予約状態に変化(ネットワークのトポロジ(パスのルート)変更，リソース獲得要求(内容)の変更等)がある場合には、その予約状態を確保するためのネットワークリソースの予約処理を実行する。
【００４３】
本発明による移動通信システムでは、ノード３０と移動端末４０との間のデータのパス(フロー)のような、ＣＮ１０及びＲＡＮ２０を通過するパスについてリソースの予約処理を行う領域が、そのパス上の所定の無線ネットワークノード２１を境としてノード３０側(ＣＮ側)とその逆側としての移動端末４０側(ＲＡＮ側)とに分割され、各領域毎に独立したリソースの予約処理を行う。
【００４４】
即ち、パス上の所定の無線ネットワークノード２１が、ノード３０との間でＣＮ側のリソースの予約処理(リフレッシュを含む)を行い、移動端末４０との間でＲＡＮ側のリソースの予約処理(リフレッシュを含む)を行う。以下、二つの領域の境となる無線ネットワークノード２１を、必要に応じて「境界ノード」と呼ぶ。
【００４５】
そして、境界ノードは、ＲＡＮ側のリソースの予約状態のリフレッシュを、ＣＮ側のリソースの予約状態のリフレッシュよりも高い頻度で行う。このように、移動通信システムは、リフレッシュ制御手段を有している。これによって、ＣＮ側とＲＡＮ側とでリフレッシュメッセージの送信間隔を変えることができ、ＣＮ１０及びＲＡＮ２０に応じた頻度で予約状態のリフレッシュを行うことができる。
【００４６】
従って、ＣＮ側では、無駄なリフレッシュメッセージの送受信が抑えられるので、ネットワークリソースの有効利用及びノードに対する処理負荷の軽減を図ることができる。一方、ＲＡＮ側では、頻繁にリフレッシュメッセージの送受信(交換)が行われるようにすることで、移動端末４０の移動等に伴うＲＡＮ２０の状態変化や予約内容の変化等にリソースの予約状態を追随させることができる。
【００４７】
このようにして、ノード３０と移動端末４０との間の通信のＱｏＳを確保することができ、安定した品質の通信サービスを提供することができる。
【００４８】
さらに、本発明では、ノード３０と移動端末４０との間のパス(フロー)が複数の無線ネットワークノード２１を通過する場合において、境界ノードとなる無線ネットワークノード２１が、ＣＮ１０又はＲＡＮ２０の状態に応じて変更される。
【００４９】
上記を実現するため、ＲＡＮ２０内の少なくとも１つの無線ネットワークノード２１は二重化されたＲＳＶＰ処理部２２を備える。ＲＳＶＰ処理部２２は、例えば、ＣＮ側ＲＳＶＰ処理部６０４と、ＲＡＮ側ＲＳＶＰ処理部６０５とからなる。
【００５０】
二重化されたＲＳＶＰ処理部２２を持つ無線ネットワークノード２１(以下、「無線ネットワークノード２１Ａ」と表記する)は、ＣＮ１０及び／又はＲＡＮ２０の状態に応じて、単一のＲＳＶＰ処理部を持つ無線ネットワークノードとして動作する場合(シングルＲＳＶＰ状態)と、２つの独立した動作を行うＲＳＶＰ処理部を持つ無線ネットワークノードとして動作する場合(マルチＲＳＶＰ状態)との２通りの状態をとる。
【００５１】
シングルＲＳＶＰ状態では、ＲＳＶＰ処理部２２は、ＲＳＶＰメッセージに対して単一のＲＳＶＰ処理部として振る舞う。このため、無線ネットワークノード２１Ａの振る舞いは、単一のＲＳＶＰ処理部を持つノード(例えば、ＣＮ１０内のノード)と同様となる。
【００５２】
マルチＲＳＶＰ状態では、二重化されたＲＳＶＰ処理部２２のうち、一方(ＣＮ側ＲＳＶＰ処理部６０４)はノード３０からのＲＳＶＰメッセージを終端し、もう一方(ＲＡＮ側ＲＳＶＰ処理部６０５)は移動端末４０からのＲＳＶＰメッセージを終端する。また、マルチＲＳＶＰ状態では、ＣＮ側ＲＳＶＰ処理部６０４は、ノード３０(ＲＡＮ側)へリフレッシュメッセージを周期的に送信し、ＲＡＮ側ＲＳＶＰ処理部６０５は、移動端末４０(ＣＮ側)へリフレッシュメッセージを周期的に送信する。ＲＡＮ側へのリフレッシュメッセージの送信周期は、ＣＮ側よりも短くなっている。
【００５３】
このように、無線ネットワークノード２１Ａは、マルチＲＳＶＰ状態となることによって、上記した境界ノードとして機能する。このため、境界ノードは「マルチＲＳＶＰノード」とも呼ばれる。
【００５４】
また、ＲＳＶＰ処理部２２を構成する２つのＲＳＶＰ処理部(ＣＮ側ＲＳＶＰ処理部６０４及びＲＡＮ側ＲＳＶＰ処理部６０５)は、ＲＳＶＰによるリソース予約処理に関する情報を共有し、互いに必要な情報をやりとりする。これによって、ＲＳＶＰ処理部２２は、無線ネットワークノード２１があたかも単一のＲＳＶＰ処理部を実装しているかのように振る舞う。
【００５５】
さらに、複数の無線ネットワークノード２１Ａのうち、マルチＲＳＶＰ状態となる無線ネットワークノード(マルチＲＳＶＰノード)は、ＣＮ１０又はＲＡＮ２０の状態に応じてフロー単位で動的に移行することができる。
【００５６】
上述したように、本発明による移動通信システムは、マルチＲＳＶＰ状態の無線ネットワークノード２１Ａ(マルチＲＳＶＰノード)を境にして、ＣＮ側とＲＡＮ側のＲＳＶＰ処理、特にリフレッシュメッセージの送信間隔を相互に独立に設定する。
【００５７】
これによって、状態変化の小さいＣＮ１０と状態変化(特に経路変化)の非常に大きいＲＡＮ２０とが、それぞれのシステムに応じた適切な周期でリフレッシュメッセージの交換を行うことができる。従って、リフレッシュメッセージによるネットワークリソースの浪費を抑えながら、適切なリソースの予約状態の管理及び更新を行うことができる(図５参照)。
【００５８】
さらに、本発明による移動通信システムは、以下を含む。
(１)無線ネットワークノード２１がマルチＲＳＶＰノードとして動作する際の、２つのＲＳＶＰ処理部(ＣＮ側ＲＳＶＰ処理部６０４とＲＡＮ側ＲＳＶＰ処理部６０５)間のマッピング制御を行うための構成および方法。
(２)システム(ＣＮ１０及び／又はＲＡＮ２０)の状態に応じて、フロー毎にマルチＲＳＶＰノードを遷移させるための構成および方法。
【００５９】
〔無線ネットワークノードの状態遷移〕
無線ネットワークノード２１Ａがフロー毎にシングルＲＳＶＰ状態とマルチＲＳＶＰ状態との間を遷移する概念について説明する。図６は、無線ネットワークノード２１Ａの状態遷移を示す図である。
【００６０】
無線ネットワークノード２１Ａは、ＣＮ１０及び／又はＲＡＮ２０の状態に応じて、ＲＡＮ側ＲＳＶＰ状態５００と、マルチＲＳＶＰ状態５０１と、ＣＮ側ＲＳＶＰ状態５０２との間で遷移する。図６中の各状態５００〜５０２は、以下の機能を有する。
【００６１】
[マルチＲＳＶＰ状態５０１]
無線ネットワークノード２１Ａは、フローのリソース予約処理についてマルチＲＳＶＰノードとなる場合には、マルチＲＳＶＰ状態５０１になる。マルチＲＳＶＰ状態５０１では、無線ネットワークノード２１Ａは、ＲＳＶＰに基づくリソースの予約処理の対象となるフローに対して、移動端末４０側(ＲＡＮ側)とノード３０側(ＣＮ側)とのＲＳＶＰ(セッション)を独立に終端する。
【００６２】
即ち、マルチＲＳＶＰノードは、ノード３０と移動端末４０との間のフローについて、ノード３０とマルチＲＳＶＰノードとの間でのＲＳＶＰセッションと、マルチＲＳＶＰノードと移動端末４０との間でのＲＳＶＰセッションとを確立し、セッション毎に独立したリソース予約処理及びリフレッシュ動作を行う。
【００６３】
但し、無線ネットワークノード２１Ａ内のＲＳＶＰ処理部２２を構成するＲＡＮ側ＲＳＶＰ処理部６０５とＣＮ側ＲＳＶＰ処理部６０４とは、ＲＳＶＰに関する情報管理手段を共有する。
【００６４】
即ち、ＲＡＮ側ＲＳＶＰ処理部６０５とＣＮ側ＲＳＶＰ処理部６０４とは、１つのフローに対するＣＮ側のセッションとＲＡＮ側のセッションと同じセッション識別子(セッションＩＤ)で管理し、各セッションにおける予約状態(ソフト状態；ＰＡＴＨ状態及びＲＥＳＶ状態)を相互に交換し、一方のセッションにおける予約状態を他方のセッションにおける予約状態にマッピングする。
【００６５】
これによって、ＲＡＮ側ＲＳＶＰ処理部６０５及びＣＮ側ＲＳＶＰ処理部６０４は、無線ネットワークノード２１Ａがあたかも１つのＲＳＶＰ処理部を備えているかのように動作する。即ち、ＲＳＶＰ処理部２２は、フローに対して、見かけ上(ノード３０又は移動端末４０からの観点(ビュー)において)、一つのＲＳＶＰセッションによるリソースの予約処理が行われているように処理を行う。
【００６６】
このようなマルチＲＳＶＰ状態５０１の無線ネットワークノード２１Ａ，即ちマルチＲＳＶＰノードは、唯一、無線ネットワークノード２１Ａの状態遷移を行うかどうかの決定権を持つ。
【００６７】
このため、マルチＲＳＶＰノードは、常にリソース予約処理の対象のフローに対する予約状態の変化を監視し、既定の条件が満たされる場合には、近隣の無線ネットワークノード２１Ａに対して適切な状態遷移指示を発行することができる。
【００６８】
また、マルチＲＳＶＰノードは、ＲＥＳＶメッセージ及びＰＡＴＨメッセージに対して以下の処理を行う。
〈１〉ＲＡＮ側からＲＥＳＶメッセージを受信し終端する。
〈２〉ＲＥＳＶメッセージを生成しＣＮ側に送信する。
〈３〉ＣＮ側からＰＡＴＨメッセージを受信し終端する。
〈４〉ＰＡＴＨメッセージを生成しＲＡＮ側に送信する。
【００６９】
但し、上記した〈１〉〜〈４〉の処理は、ノード３０から移動端末４０へデータを伝送するためのフローに対する処理であり、この場合には、マルチＲＳＶＰノードは、移動端末４０(ＲＡＮ側)からＲＥＳＶメッセージのみを受信し、ノード３０(ＣＮ側)からはＰＡＴＨメッセージのみを受信する。また、リソース予約処理の対象のフローのデータ伝送方向が上記フローと逆方向の場合には、上記した〈１〉〜〈４〉の処理における「ＲＡＮ側」と「ＣＮ側」とが入れ替わる。
【００７０】
[ＲＡＮ側ＲＳＶＰ状態５００]
無線ネットワークノード２１Ａは、リソース予約処理の対象のフロー上において、マルチＲＳＶＰ状態５０１の無線ネットワークノード２１Ａ(マルチＲＳＶＰノード)よりも下流側(ＲＡＮ側)に位置する場合には、シングルＲＳＶＰ状態の一つとしてのＲＡＮ側ＲＳＶＰ状態５００となる。ＲＡＮ側ＲＳＶＰ状態５００では、無線ネットワークノード２１Ａは、単一のＲＳＶＰ処理部を持つノードとして動作する。即ち、フローの上流側及び下流側から夫々受信するＲＳＶＰメッセージを逆側へ転送する。
【００７１】
ＲＡＮ側のリソースの予約状態(ソフト状態；「ＲＳＶＰ状態」とも呼ぶ)のリフレッシュ周期(リフレッシュメッセージの送信間隔)はＣＮ側に比べて短く、頻繁に予約状態のリフレッシュが行われる。
【００７２】
ＲＡＮ側ＲＳＶＰ状態５００の無線ネットワークノード２１Ａは、ＲＥＳＶメッセージとＰＡＴＨメッセージについては、以下の処理を行う。但し、データがノード３０から移動端末４０へ伝送される場合(ノード３０→移動端末４０のフロー)であるものとする。
〈１〉ＲＡＮ側からＲＥＳＶメッセージを受信しＣＮ側に転送する。
〈２〉ＣＮ側からＰＡＴＨメッセージを受信しＲＡＮ側に転送する。
【００７３】
[ＣＮ側ＲＳＶＰ状態５０２]
無線ネットワークノード２１Ａは、リソース予約処理の対象のフロー上において、マルチＲＳＶＰ状態５０１の無線ネットワークノード２１Ａ(マルチＲＳＶＰノード)よりも上流側(ＣＮ側)に位置する場合には、シングルＲＳＶＰ状態の一つとしてのＣＮ側ＲＳＶＰ状態５０２となる。ＣＮ側ＲＳＶＰ状態５０２では、無線ネットワークノード２１Ａは、単一のＲＳＶＰ処理部を持つノードとして動作する。即ち、フローの上流側及び下流側から夫々受信するＲＳＶＰメッセージを逆側へ転送する。
【００７４】
ＣＮ側のリソースの予約状態(ソフト状態又はＲＳＶＰ状態)のリフレッシュ周期(リフレッシュメッセージの送信間隔)はＲＡＮ側に比べて長く、予約状態は頻繁にリフレッシュされない。
【００７５】
ＣＮ側ＲＳＶＰ状態５０２の無線ネットワークノード２１Ａは、ＲＥＳＶメッセージとＰＡＴＨメッセージについては、以下の処理を行う。但し、データがノード３０から移動端末４０へ伝送される場合(ノード３０→移動端末４０のフロー)であるものとする。
〈１〉ＲＡＮ側からＲＥＳＶメッセージを受信しＣＮ側に転送する。
〈２〉ＣＮ側からＰＡＴＨメッセージを受信し移動端末側に転送する。
【００７６】
ところで、マルチＲＳＶＰノードは、以下のように動作する。即ち、マルチＲＳＶＰノードは、リソースの予約処理対象のフローに対する予約状態の変化を常に監視する。ＲＡＮ側で予約状態の変化が多く発生しない場合には、ＲＡＮ側(移動端末４０)から送信されてくるリフレッシュメッセージは、マルチＲＳＶＰノードで管理しているＲＡＮ側の予約状態を頻繁に変化させない。
【００７７】
このように、マルチＲＳＶＰノードがＲＡＮ側から受信したリフレッシュメッセージで示される予約状態に変化がない場合(リフレッシュメッセージに含まれた予約状態と現在マルチＲＳＶＰノードで管理している予約状態とが同じである場合)には、マルチＲＳＶＰノードは、ＲＡＮ側からのリフレッシュメッセージをここで終端し、ＣＮ側へ転送しない。
【００７８】
従って、ＲＡＮ側での移動端末４０の移動性に起因する膨大なリフレッシュメッセージがＣＮ側に流れ込み、ＣＮ側のネットワークリソースを圧迫することを防止することができる。
【００７９】
一方、マルチＲＳＶＰノードは、ＲＡＮ側から受信した(終端した)リフレッシュメッセージで示される予約状態に変化がある場合(リフレッシュメッセージに含まれた予約状態と現在マルチＲＳＶＰノードで管理している予約状態とが異なる場合)には、上記受信したリフレッシュメッセージと同内容のリフレッシュメッセージを生成しＣＮ側へ送信する。なぜなら、処理対象のフローに対するＲＡＮ側の予約状態の変化をＣＮ側に反映させる必要があるからである。
【００８０】
従って、マルチＲＳＶＰノードは、予約状態の変化を示すリフレッシュメッセージをＲＡＮ側から頻繁に受信する場合には、リフレッシュメッセージを受信する毎に、この予約状態の変化を示すリフレッシュメッセージを生成しＣＮ側に送信しなければならない。このような場合には、マルチＲＳＶＰノードがＣＮ側で不要なリフレッシュメッセージを終端するという機能を殆ど果たさなくなる。
【００８１】
このため、マルチＲＳＶＰノードは、所定時間内におけるＲＡＮ側からの予約状態の変化を示すリフレッシュメッセージの受信数が所定の上限値を上回る場合には、フローの上流(ＣＮ側)に位置する近隣の他の無線ネットワークノード２１Ａ(以下、「上流ノード」と表記)に状態遷移指示メッセージを与えてその上流ノードの状態をマルチＲＳＶＰ状態５０１に遷移させ、自らはＲＡＮ側ＲＳＶＰ状態５００に遷移する。
【００８２】
その後、ＲＡＮ側ＲＳＶＰ状態５００となった無線ネットワークノード２１Ａは、ＲＡＮ側からのリフレッシュメッセージを上流ノードへ単に転送するのみで済む(リフレッシュメッセージの終端及び生成を行わなくて済む)ようになる。
【００８３】
また、マルチＲＳＶＰノードは、ＲＡＮ側から受信するリフレッシュメッセージが予約状態の変化を示さない場合には、そのリフレッシュメッセージを終端する(転送を停止する)。このようなリフレッシュメッセージは、マルチＲＳＶＰノードがＲＡＮ側から受信する意味を持たないものであり、マルチＲＳＶＰノード及びその下流近傍(例えば、リフレッシュメッセージをマルチＲＳＶＰノードへ転送する無線ネットワークノード)のネットワークリソースを浪費するだけである。
【００８４】
そこで、マルチＲＳＶＰノードで管理するＲＡＮ側の予約状態がＲＡＮ側からのリフレッシュメッセージで殆ど変化しない場合，即ち、所定時間内におけるＲＡＮ側からの予約状態の変化を示すリフレッシュメッセージの受信数が所定の下限値を下回る場合には、マルチＲＳＶＰノードは、フローの下流(ＲＡＮ側)に位置する近隣の他の無線ネットワークノード２１Ａ(以下、「下流ノード」と表記)に状態遷移指示メッセージを与えてその下流ノードの状態をマルチＲＳＶＰ状態５０１に遷移させ、自らはＣＮ側ＲＳＶＰ状態５０２に遷移する。
【００８５】
このように、移動通信システムは、移動通信ネットワークの状態の変化に応じて境界ノードを変更する境界ノード変更手段を備える。これによって、無用のリフレッシュメッセージの転送処理が抑えられ、この処理に使用されていたネットワークリソースを他の用途に有効に利用することが可能になる。
【００８６】
上記のように、ノードの状態遷移を行う否かの判断は、全てマルチＲＳＶＰノードが行う。従って、ＲＡＮ側ＲＳＶＰ状態５００又はＣＮ側ＲＳＶＰ状態５０２の無線ネットワークノード２１Ａは、マルチＲＳＶＰノードからの状態遷移指示を受け取ることにより、マルチＲＳＶＰ状態５０１に遷移し、新たなマルチＲＳＶＰノードとして動作する。
【００８７】
〔無線ネットワークノード２１Ａ〕
次に、上記したような動作を可能にするための無線ネットワークノード２１Ａの一実施形態について説明する。図７は、無線ネットワークノード２１Ａの一実施形態を示す図である。
【００８８】
無線ネットワークノード２１Ａは、ＣＮ側のＲＳＶＰセッションを終端するＣＮ側ＲＳＶＰ処理部６０４と、ＲＡＮ側のＲＳＶＰセッションを終端するＲＡＮ側ＲＳＶＰ処理部６０５と、図６で述べたような状態遷移に関する処理を行う状態遷移制御部６０６と、他の無線ネットワークノード２１又は２１Ａとのインターフェースである外線インターフェース部６０３と、従来の無線信号処理及びＲＳＶＰメッセージに基づくリソースの予約処理を行う信号処理部６０２と、主制御部６００とを有し、これらは互いに装置内バス６０１により接続されている。ＣＮ側ＲＳＶＰ処理部６０４とＲＡＮ側ＲＳＶＰ処理部６０５とが、二重化されたＲＳＶＰ処理部２２を構成する。
【００８９】
また、無線ネットワークノード２１Ａは、状態記憶部としての状態管理共通テーブル６０７を有する。状態管理共通テーブル６０７はＲＳＶＰソフト状態や、これに関連する情報をフロー単位で格納する。状態管理共通テーブル６０７は、ＣＮ側ＲＳＶＰ処理部６０４，ＲＡＮ側ＲＳＶＰ処理部６０５，及び状態遷移制御部６０６により共通に参照される情報格納手段である。
【００９０】
また、無線ネットワークノード２１Ａは、システムデータ格納テーブル６０８を有する。システムデータ格納テーブル６０８は、無線ネットワークノード２１Ａに固有のパラメータを格納している。主制御部６００は、無線ネットワークノード２１Ａの再起動時等に必要なパラメータを取得し、必要な部位に設定する。
【００９１】
〈状態管理共通テーブル〉
状態管理共通テーブル６０７は、フロー毎に生成される１以上のエントリ(レコード)を格納するようになっており、エントリは、フローに対するセッションＩＤ、ノード状態、状態変化回数、第１のタイマとしてのＰＡＴＨリフレッシュタイマ、第２のタイマとしてのＲＥＳＶリフレッシュタイマ、ＲＳＶＰソフト状態を設定するための複数の領域を持つ。夫々の情報の説明は次の通りである。
【００９２】
なお、図７に示す状態管理共通テーブル６０７は、ノード３０を上流とし移動端末４０を下流とするフローについて、移動端末４０から送信されてくるリフレッシュメッセージ(ＲＥＳＶメッセージ)に基づいて無線ネットワークノード２１Ａが状態遷移を行うための情報を格納している。
【００９３】
[セッションＩＤ]
セッションＩＤは、フロー毎に付与される識別子であり、無線ネットワークノード２１Ａ(装置)の内部でフローを識別するために使用される。本実施形態では、１つのフローに対するＲＡＮ側のＲＳＶＰセッションとＣＮ側のＲＳＶＰセッションとについて、同じセッションＩＤが使用される。
【００９４】
[ノード状態]
ノード状態は、セッションＩＤで特定されるフローに対する無線ネットワークノード２１Ａの状態を示す。ノード状態として、“マルチＲＳＶＰ状態”，“ＲＡＮ側ＲＳＶＰ状態”，及び“ＣＮ側ＲＳＶＰ状態”の何れかが格納される。
【００９５】
[状態遷移監視タイマ]
状態遷移監視タイマは、フローに対するＲＡＮ側のセッションに対するＲＳＶＰソフト状態が変化した回数(状態変化回数)を定期的に監視するためのタイマである。このタイマは定期的に所定の時間を計時し、所定の時間が計時される毎に、その所定の時間内における状態変化回数が参照される。
【００９６】
[状態変化回数]
状態変化回数は、ＲＡＮ側のセッションに対するＲＳＶＰ状態が変化した回数である。状態変化回数として格納された値に基づいて、無線ネットワークノード２１Ａが状態遷移を行うか否かの制御が行われる。状態変化回数は、状態遷移監視タイマがタイムアウトになる毎にリセットされ、クリアされる(“０”にされる)。
【００９７】
[ＰＡＴＨリフレッシュタイマ]
ＰＡＴＨリフレッシュタイマは、リフレッシュメッセージとしてのＰＡＴＨメッセージをＲＡＮ側(移動端末４０)へ周期的に送信するための時間を計時するタイマである。ＰＡＴＨリフレッシュタイマは、セッションに対応するノード状態がマルチＲＳＶＰ状態である場合にのみ使用される。ＰＡＴＨリフレッシュタイマにより計時される時間(タイマ値)として、ＰＡＴＨリフレッシュ周期が用いられる。ＰＡＴＨリフレッシュタイマの満了(タイムアウト)は、ＲＡＮ側ＲＳＶＰ処理部６０５で検出され、このとき、ＰＡＴＨメッセージがＲＡＮ側へ送信される。
【００９８】
[ＲＥＳＶリフレッシュタイマ]
ＲＥＳＶリフレッシュタイマは、リフレッシュメッセージとしてのＲＥＳＶメッセージをＣＮ側(ノード３０)へ周期的に送信するための時間を計時するタイマである。ＲＥＳＶリフレッシュタイマは、ＰＡＴＨリフレッシュタイマと同様に、セッションに対応するノード状態がマルチＲＳＶＰ状態である場合にのみ使用される。ＲＥＳＶリフレッシュタイマにより計時される時間(タイマ値)として、ＲＥＳＶリフレッシュ周期が用いられる。ＲＥＳＶリフレッシュタイマの満了(タイムアウト)は、ＣＮ側ＲＳＶＰ処理部６０４で検出され、このとき、ＲＥＳＶメッセージがＣＮ側へ送信される。
【００９９】
[ＲＳＶＰソフト状態]
ＲＳＶＰソフト状態は、ＲＥＳＶメッセージやＰＡＴＨメッセージ内に格納されたリソースの予約処理に係る情報であり、少なくともリソースの予約状態を示す情報がＲＳＶＰソフト状態として格納される。
【０１００】
〈システムデータ格納テーブル〉
システムデータ格納テーブル６０８は、ノード種別、状態変化回数上限閾値、状態変化回数下限閾値、ＰＡＴＨリフレッシュ周期、ＲＥＳＶリフレッシュ周期を格納するための領域を持つ。それぞれの情報の説明は以下の通りである。
【０１０１】
[ノード種別]
ノード種別は、無線ネットワークノード２１Ａがゲートウェイノードか否かを示す情報である。ゲートウェイノードは、フローに対するセッションが新規に追加された際にマルチＲＳＶＰ状態となる無線ネットワークノード２１Ａとして定義される。
【０１０２】
[状態変化回数上限閾値]
状態変化回数上限閾値は、ノード状態がマルチＲＳＶＰ状態であるセッションに対する無線ネットワークノード２１Ａの状態遷移のトリガとなる閾値である。状態変化回数が状態変化上限閾値を上回った場合には、無線ネットワークノード２１Ａは、自身の上流の近隣に位置する他の無線ネットワークノード２１Ａに対し、当該セッションについてマルチＲＳＶＰ状態へ遷移することを指示するための状態遷移指示メッセージを送信し、自らはＲＡＮ側ＲＳＶＰ状態に遷移する。
【０１０３】
[状態変化回数下限閾値]
状態変化回数下限閾値は、ノード状態がマルチＲＳＶＰ状態であるセッションに対する無線ネットワークノード２１Ａの状態遷移のトリガとなる閾値である。状態変化回数が状態変化下限閾値を下まわった場合には、無線ネットワークノード２１Ａは、自身の下流の近隣に位置する他の無線ネットワークノード２１Ａに対し、当該セッションについてマルチＲＳＶＰ状態へ遷移することを指示するための状態遷移指示メッセージを送信し、自らはＣＮ側ＲＳＶＰ状態に遷移する。
【０１０４】
[ＰＡＴＨリフレッシュ周期]
ＰＡＴＨリフレッシュ周期は、ＰＡＴＨリフレッシュタイマ値として使用されるタイマ値を示す情報である。通常、ＰＡＴＨリフレッシュ周期として、ＲＥＳＶリフレッシュ周期よりも小さな値が設定される。ＲＡＮ側でのリフレッシュをＣＮ側よりも頻繁に行うためである。
【０１０５】
[ＲＥＳＶリフレッシュ周期]
ＲＥＳＶリフレッシュ周期は、ＲＥＳＶリフレッシュタイマ値として使用されるタイマ値を示す情報である。通常、ＲＥＳＶリフレッシュ周期として、ＰＡＴＨリフレッシュ周期よりも大きな値が設定される。ＣＮ側に送信されるリフレッシュメッセージ(ＲＥＳＶメッセージ)の送信間隔を長くしてＣＮ側のリソースの浪費を抑えるためである。
【０１０６】
[状態遷移監視周期]
状態遷移監視周期は、状態遷移監視タイマ値として使用されるタイマ値を示す情報である。
【０１０７】
〈状態遷移制御部〉
次に状態遷移制御部６０６について説明する。状態遷移制御部６０６は、状態管理共通テーブル６０７を参照することにより、セッション毎にＲＳＶＰソフト状態を識別し、ＲＳＶＰソフト状態に応じて主に以下の処理を行う。
【０１０８】
状態遷移制御部６０６は、状態管理共通テーブル６０７内においてノード状態がマルチＲＳＶＰ状態であるセッションの全てに対し、状態遷移監視タイマで計時される一定時間(状態遷移監視タイマ値)毎に状態変化回数を０クリアする。これは、ある単位時間(状態遷移監視タイマ値)内に発生する状態変化の回数を測定するためである。０クリアのタイミングはセッション毎に共通となっていても、異なっていても良い。
【０１０９】
また、状態遷移制御部６０６は、マルチＲＳＶＰ状態のセッションに関して、ＲＡＮ側ＲＳＶＰ処理部６０５又はＣＮ側ＲＳＶＰ処理部６０４からＲＳＶＰ状態変化通知を受け取ると、状態変化回数に１を加算する。続いて、状態遷移制御部６０６は、加算後の値を状態変化回数上限閾値及び状態変化回数下限閾値と夫々比較する。このとき、状態遷移制御部６０６は、加算後の値が上限閾値を上まわる、又は下限閾値を下まわった場合には、そのセッションに対するノード状態を遷移させる。
【０１１０】
さらに、状態遷移制御部６０６は、近隣のマルチＲＳＶＰノードから或るセッションについてノード状態を遷移するための状態遷移指示メッセージを受け取った場合に、そのセッションに対するノード状態をマルチＲＳＶＰ状態に設定する。 また、状態遷移制御部６０６は、セッションが新規に追加される場合にも、ノード状態を設定する。
【０１１１】
〈ＲＳＶＰメッセージに対する処理〉
次に、無線ネットワークノード２１ＡにおけるＲＳＶＰメッセージに対する処理について説明する。図７において、無線ネットワークノード２１Ａは、ＲＡＮ側(移動端末側)及びＣＮ側から送信されてくる全てのＲＳＶＰメッセージを外線インターフェイス部６０３で受信する。ＲＳＶＰメッセージは、上述したように、ＰＡＴＨメッセージ，ＲＥＳＶメッセージ，ＰＡＴＨ ＴＥＡＲメッセージ，ＲＥＳＶ ＴＥＡＲメッセージの何れかである。
【０１１２】
ＣＮ側ＲＳＶＰ処理部６０４は、ＣＮ側からのＲＳＶＰメッセージの全てを外線インターフェイス部６０３から受け取り、受け取ったＲＳＶＰメッセージに対する処理を行う。一方、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＡＮ側からのＲＳＶＰメッセージの全てを受け取り、受け取ったＲＳＶＰメッセージに対する処理を行う。
【０１１３】
《ＲＥＳＶメッセージに対する動作例》
以下、リフレッシュメッセージであるＲＥＳＶメッセージに対する無線ネットワークノード２１Ａの動作について説明する。図８は、無線ネットワークノード２１Ａにおいて、ＲＥＳＶメッセージの処理が行われる際の動作の流れを示す図である。なお、本実施形態では、ＲＥＳＶメッセージは移動端末側(ＲＡＮ側)からのみ送信されてくるものとする。
【０１１４】
ＲＡＮ側ＲＳＶＰ処理部６０５は、ステップＳ７００でＲＥＳＶメッセージを受信すると、このＲＥＳＶメッセージからセッションＩＤを抽出し、このセッションＩＤが状態管理共通テーブル６０７内に格納されているか否かをチェックする(ステップＳ７０１,Ｓ７０２)。
【０１１５】
ステップＳ７０２において、抽出されたセッションＩＤと同一のセッションＩＤが状態管理共通テーブル６０７内に存在する場合(Ｓ７０２；ＹＥＳ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージに格納されているＲＳＶＰソフト状態と、セッションＩＤに対応する状態管理共通テーブル６０７内のＲＳＶＰソフト状態とを比較し(ステップＳ７０３)、ＲＳＶＰソフト状態として示されるリソースの予約状態が変化したかどうかを判定する(ステップＳ７０４)。
【０１１６】
このとき、予約状態が変化していない場合(Ｓ７０４；ＮＯ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、セッションＩＤに対応するノード状態を参照し、ノード状態がマルチＲＳＶＰ状態か否かを判定する(ステップＳ７０４ａ)。ノード状態がマルチＲＳＶＰ状態であれば(Ｓ７０４ａ；ＹＥＳ)、ＲＡＮ側ＲＳＶＰ処理部６０５は、このＲＥＳＶメッセージに対する処理を終了する。
【０１１７】
即ち、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージを終端し、この転送を停止する。これによって、予約状態の変化を示さないリフレッシュメッセージがＣＮ側へ転送されることが防止される。
【０１１８】
一方、ステップＳ７０４ａにおいて、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７０４ａ；ＮＯ)、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージをＣＮ側へ転送し(ステップＳ７１３)、このＲＥＳＶメッセージに対する処理を終了する。
【０１１９】
一方、ステップＳ７０４で予約状態が変化したと判定された場合(Ｓ７０４；ＹＥＳ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、状態管理共通テーブル６０７内の当該セッションＩＤに対応するＲＳＶＰソフト状態(リソースの予約状態)を更新する(ステップＳ７０５)。
【０１２０】
続いて、ＲＡＮ側ＲＳＶＰ処理部６０５は、そのセッションＩＤに対応するノード状態を参照し、ノード状態がマルチＲＳＶＰ状態かどうかを調べる(ステップＳ７１２)。このとき、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７１２；ＮＯ)、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージをＣＮ側へ転送し(ステップＳ７１３)、このＲＥＳＶメッセージに対する処理を終了する。このステップＳ７１３の処理は、シングルＲＳＶＰ状態(ＲＡＮ側ＲＳＶＰ状態５００又はＣＮ側ＲＳＶＰ状態５０２)としての処理である。
【０１２１】
一方、ステップＳ７１２でセッションＩＤに対応するノード状態がマルチＲＳＶＰ状態であると判定された場合(Ｓ７１２；ＹＥＳ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、以下の２つの処理を並列に行う。
【０１２２】
第１に、ＲＡＮ側ＲＳＶＰ処理部６０５は、状態遷移制御部６０６に対してセッションＩＤを渡し、セッションＩＤに対するＲＳＶＰソフト状態が変化したことを通知する(ステップＳ７１４)。この通知を受けた状態遷移制御部６０６は、状態管理共通テーブル６０７内の、通知されたセッションＩＤに対応する状態変化回数に１を加算する(ステップＳ７１５)。
【０１２３】
第２に、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＣＮ側ＲＳＶＰ処理部６０４にセッションＩＤを渡し、セッションのＲＳＶＰソフト状態が変化したことを通知する(ステップＳ７１６)。
【０１２４】
ＲＡＮ側ＲＳＶＰ処理部６０５からの通知を受けとったＣＮ側ＲＳＶＰ処理部６０４は、状態管理共通テーブル６０７内の、通知されたセッションＩＤに対応するＲＳＶＰソフト状態(リソースの予約状態)を取得し、これを含むＲＥＳＶメッセージを生成し、ＣＮ側へ送信する(ステップＳ７１７)。その後、ＣＮ側ＲＳＶＰ処理部６０４は、通知されたセッションＩＤに対応するＲＥＳＶリフレッシュタイマをリセットする(ステップＳ７１８)。
【０１２５】
なお、ＲＡＮ側ＲＳＶＰ処理部６０５は、ステップＳ７１５及びＳ７１６の処理が終了すると、このＲＥＳＶメッセージに対する処理を終了し、次のＲＥＳＶメッセージを受け付ける状態になる。
【０１２６】
ところで、ステップＳ７０２において、ＲＥＳＶメッセージから抽出されたセッションＩＤが状態管理共通テーブル６０７内で管理されているセッションＩＤのいずれとも一致しない場合(Ｓ７０２；ＮＯ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、抽出したセッションＩＤと、ＲＥＳＶメッセージに格納されているＲＳＶＰ情報(ＲＳＶＰソフト状態；リソースの予約状態)を状態管理共通テーブル６０７に追加する(ステップＳ７０６)。その後、ＲＡＮ側ＲＳＶＰ処理部６０５は、新規セッションを追加したことを状態遷移制御部６０６に通知する(ステップＳ７０７)。
【０１２７】
状態遷移制御部６０６は、新規セッション追加の通知をＲＡＮ側ＲＳＶＰ処理部６０５から受け取ると、システムデータ格納テーブル６０８に格納されているノード種別を参照し(ステップＳ７０８)、この無線ネットワークノード２１Ａがゲートウェイノードかどうかをチェックする(ステップＳ７０９)。
【０１２８】
このとき、ノード種別がゲートウェイノードであれば(Ｓ７０９；ＹＥＳ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をマルチＲＳＶＰ状態に設定する(ステップＳ７１０)。これによって、無線ネットワークノード２１Ａは、追加されたセッションに対してマルチＲＳＶＰノードとして振る舞う。
【０１２９】
一方、ノード種別がゲートウェイノードでなければ(Ｓ７０９；ＮＯ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をＲＡＮ側ＲＳＶＰ状態に設定する(ステップＳ７１１)。その後、上述したステップＳ７１２以降の処理が行われる。
【０１３０】
ところで、ノード状態がマルチＲＳＶＰ状態であるセッションについては、上述したステップＳ７００〜Ｓ７１８までの一連の処理から独立して、ＣＮ側ＲＳＶＰ処理部６０４が周期的にＲＥＳＶメッセージを生成しＣＮ側へ送信する処理が行われる。
【０１３１】
すなわち、ステップＳ７１９において、あるマルチＲＳＶＰ状態のセッションに対応するＲＥＳＶリフレッシュタイマ(第１のタイマ)がタイムアウトになると(Ｓ７１９；ＹＥＳ)、ＣＮ側ＲＳＶＰ処理部６０４は、第１の処理部として、このセッションに対応するＲＳＶＰソフト状態(リソースの予約状態)を状態管理共通テーブル６０７から取得し、これを含むＲＥＳＶメッセージを生成しＣＮ側へ送信する(ステップＳ７２０)。
【０１３２】
その後、ステップＳ７２１にて、ＣＮ側ＲＳＶＰ処理部６０４は、タイムアウトになったＲＥＳＶリフレッシュタイマをリセットする。これによって、ＣＮ側には、リソースの予約状態をリフレッシュするためのＲＥＳＶメッセージが周期的に送信される。
【０１３３】
《ＰＡＴＨメッセージに対する動作例》
無線ネットワークノード２１ＡにおけるＰＡＴＨメッセージに対する処理は、以下に示すように、ＲＥＳＶメッセージに対する処理と同様に行われる。図９は、無線ネットワークノード２１Ａにおいて、ＰＡＴＨメッセージの処理が行われる際の動作の流れを示す図である。なお、ＰＡＴＨメッセージはノード３０側(ＣＮ側)からのみ送信されてくるものとする。
【０１３４】
ＣＮ側ＲＳＶＰ処理部６０４は、ステップＳ７３０でＰＡＴＨメッセージを受信すると、このＰＡＴＨメッセージからセッションＩＤを抽出し、このセッションＩＤが状態管理共通テーブル６０７内に格納されているか否かをチェックする(ステップＳ７３１,Ｓ７３２)。
【０１３５】
ステップＳ７３２において、抽出されたセッションＩＤと同一のセッションＩＤが状態管理共通テーブル６０７内に存在する場合(Ｓ７３２；ＹＥＳ)には、ＣＮ側ＲＳＶＰ処理部６０４は、ＰＡＴＨメッセージに格納されているＲＳＶＰソフト状態と、セッションＩＤに対応する状態管理共通テーブル６０７内のＲＳＶＰソフト状態とを比較する(ステップＳ７３３)。
【０１３６】
続いて、ＣＮ側ＲＳＶＰ処理部６０４は、比較結果に基づいてＲＳＶＰソフト状態，即ち予約状態が変化したかどうかを判定する(ステップＳ７３４)。このとき、予約状態が変化していない場合(Ｓ７３４；ＮＯ)には、このセッションＩＤに対応するノード状態がマルチＲＳＶＰ状態か否かを判定する(ステップＳ７３４ａ)。このとき、ノード状態がマルチＲＳＶＰ状態であれば(Ｓ７３４ａ；ＹＥＳ)、ＣＮ側ＲＳＶＰ処理部６０４は、このＰＡＴＨメッセージに対する処理を終了し、無駄なＰＡＴＨメッセージがＲＡＮ側へ流れるのを防止する。
【０１３７】
一方、ステップＳ７３４ａにおいて、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７３４ａ；ＮＯ)、ＣＮ側ＲＳＶＰ処理部６０４は、ＰＡＴＨメッセージをＣＮ側へ転送し(ステップＳ７４３)、このＰＡＴＨメッセージに対する処理を終了する。ステップＳ７４３の処理は、シングルＲＳＶＰ状態(ＲＡＮ側ＲＳＶＰ状態５００又はＣＮ側ＲＳＶＰ状態５０２)としての処理である。
【０１３８】
一方、ＣＮ側ＲＳＶＰ処理部６０４は、ステップＳ７３４において予約状態が変化したと判定した場合(Ｓ７３４；ＹＥＳ)には、状態管理共通テーブル６０７内の当該セッションのＲＳＶＰソフト状態を更新する(ステップＳ７３５)。
【０１３９】
その後、ＣＮ側ＲＳＶＰ処理部６０４は、そのセッションＩＤに対応するノード状態を参照し、マルチＲＳＶＰ状態かどうかを調べる(ステップＳ７４２)。このとき、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７４２；ＮＯ)、ＣＮ側ＲＳＶＰ処理部６０４は、ＰＡＴＨメッセージをＲＡＮ側へ転送する(Ｓ７４３)。
【０１４０】
一方、ステップＳ７４２で当該セッションのノード状態がマルチＲＳＶＰ状態であったと判定された場合(Ｓ７４２；ＹＥＳ)には、ＣＮ側ＲＳＶＰ処理部６０４は、ステップＳ７４６において、ＲＡＮ側ＲＳＶＰ処理部６０５にセッションＩＤを渡し、セッションのＲＳＶＰソフト状態が変化したことを通知する。なお、ＣＮ側ＲＳＶＰ処理部６０４は、Ｓ７４６の処理が終了すると、このＰＡＴＨメッセージに対する処理を終了し、次のＰＡＴＨメッセージを受け付ける状態になる。
【０１４１】
ＣＮ側ＲＳＶＰ処理部６０４からの通知を受けたＲＡＮ側ＲＳＶＰ処理部６０５は、状態管理共通テーブル６０７内の、通知されたセッションＩＤに対応するＲＳＶＰソフト状態を取得し、これを含むＰＡＴＨメッセージを生成し、ＣＮ側へ送信する(ステップＳ７４７)。その後、ステップＳ７４８において、ＣＮ側ＲＳＶＰ処理部６０４は、通知されたセッションＩＤに対応するＰＡＴＨリフレッシュタイマをリセットする。
【０１４２】
ところで、ステップＳ７３２において、ＰＡＴＨメッセージから抽出したセッションＩＤが状態管理共通テーブル６０７内に格納されているセッションＩＤのいずれとも一致しない場合(Ｓ７３２；ＮＯ)には、ＣＮ側ＲＳＶＰ処理部６０４は、抽出したセッションＩＤと、ＰＡＴＨメッセージに含まれている情報(ＲＳＶＰソフト状態に相当する情報)とを、状態管理共通テーブル６０７内に追加する(ステップＳ７３６)。その後、ＣＮ側ＲＳＶＰ処理部６０４は、新規セッションを追加したことを状態遷移制御部６０６に通知する(ステップＳ７３７)。
【０１４３】
新規セッション追加の通知を受けとった状態遷移制御部６０６は、システムデータ格納テーブル６０８に格納されているノード種別を参照し(ステップＳ７３８)、この無線ネットワークノード２１Ａがゲートウェイノードかどうかをチェックする(ステップＳ７３９)。
【０１４４】
このとき、ノード種別がゲートウェイノードであれば(Ｓ７３９；ＹＥＳ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をマルチＲＳＶＰ状態に設定する(ステップＳ７４０)。
【０１４５】
一方、ノード種別がゲートウェイノードでなければ(Ｓ７３９；ＮＯ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をＲＡＮ側ＲＳＶＰ状態５００に設定する(ステップＳ７４１)。ステップＳ７４０又はＳ７４１の処理が終了すると、処理がステップＳ７４２に進む。
【０１４６】
ノード状態がマルチＲＳＶＰ状態であるセッションについては、上述したステップＳ７３０〜Ｓ７４３，Ｓ７４６〜Ｓ７４８までの処理から独立して、周期的にＰＡＴＨメッセージを生成しＲＡＮ側へ送信する処理が行われる。
【０１４７】
すなわち、ステップＳ７４９において、あるマルチＲＳＶＰ状態のセッションのＰＡＴＨリフレッシュタイマ(第２のタイマ)がタイムアウトになると(Ｓ７４９；ＹＥＳ)、ＣＮ側ＲＳＶＰ処理部６０４は、第２の処理部として、このセッションに対応するＲＳＶＰソフト状態を状態管理共通テーブル６０７から取得し、これを含むＰＡＴＨメッセージを生成しＲＡＮ側へ送信する(ステップＳ７５０)。その後、ステップＳ７５１にて、ＣＮ側ＲＳＶＰ処理部６０４は、タイムアウトになったＰＡＴＨリフレッシュタイマをリセットする。
【０１４８】
本実施形態では、データ送信ノード(例えばサーバ３０)からデータ受信ノード(例えば移動端末４０)へのデータフローに対する新たなセッションが追加される場合には、各無線ネットワークノード２１Ａが新規のＰＡＴＨメッセージを受信することによって、そのノードの状態の設定が行われる(Ｓ７３６〜Ｓ７４１)。このとき、ＣＮ１０からＲＡＮ２０への入口に相当する無線ネットワークノード２１Ａがゲートウェイノードに決定されるようになっている。
【０１４９】
従って、新規なセッションが追加された時点では、フロー上の複数の無線ネットワークノード２１Ａの状態は、マルチＲＳＶＰ状態５０１かＲＡＮ側ＲＳＶＰ状態５００との一方になる。その後、当該セッションの状態変化回数が少ない(例えば、移動端末４０の移動範囲が小さい等)場合に、マルチＲＳＶＰ状態５０１が下流側(移動端末４０側)へ移動する。このとき、ＣＮ側ＲＳＶＰ状態５０２の無線ネットワークノード２１Ａが出現する。
【０１５０】
なお、図８及び図９に示したように、無線ネットワークノード２１Ａが状態遷移を行うか否かの判断は、ＲＡＮ側からのリフレッシュメッセージ(ＲＥＳＶメッセージ)による予約状態の変化の回数に基づいて行われる。このため、状態管理共通テーブル６０７は、ＰＡＴＨメッセージに関する状態変化回数及び状態遷移監視タイマを持たず、ステップＳ７１４及びＳ７１５に相当する処理が行われないようになっている。ＣＮ１０の経路変化は頻繁には起こらず、ＣＮ側からの状態変化を示すＰＡＴＨメッセージが頻繁に送信されることはないものと考えられるからである。但し、状態管理共通テーブル６０７がＰＡＴＨメッセージに関する状態変化回数及び状態遷移監視タイマをさらに格納し、ＣＮ側からのＰＡＴＨメッセージについてステップＳ７１４及びＳ７１５に相当する処理が行われるようにしても良い。
【０１５１】
なお、ＣＮ側ＲＳＶＰ処理部６０４及びＲＡＮ側ＲＳＶＰ処理部６０５は、受信したリフレッシュメッセージ(ＲＥＳＶメッセージ又はＰＡＴＨメッセージ)により予約状態が変化した場合には、その予約状態に応じたリソースの予約処理を行う。また、ＲＳＶＰ処理部２２の代わりに単一のＲＳＶＰ処理部を持つノードでも、リフレッシュメッセージにより予約状態が変化した場合には、その予約状態に応じたリソースの予約処理を行う。
【０１５２】
また、図８及び図９に示す動作によると、マルチＲＳＶＰノードから送信されるＲＥＳＶメッセージは、ＣＮ側における１以上のノード(中継ノード)を介してノード３０に受信される。一方、マルチＲＳＶＰノードから送信されるＰＡＴＨメッセージは、ＲＡＮ側における１以上の無線ネットワークノード(中継ノード)を介して移動端末４０に受信される。
【０１５３】
〈状態遷移制御における動作例〉
次に、無線ネットワークノード２１Ａにおいて、ノード状態の遷移に関する処理が行われる際の処理の流れについて説明する。
【０１５４】
図７に示す状態遷移制御部６０６は、状態管理共通テーブル６０７内で管理されているセッションのうち、ノード状態がマルチＲＳＶＰ状態であるセッションについて、図１０に示すような処理を行う。図１０は、無線ネットワークノード２１Ａにおける状態遷移制御の例を示すフローチャートである。
【０１５５】
図１０において、状態遷移制御部６０６は、周期的にマルチＲＳＶＰ状態にあるセッションについて、状態変化回数を、状態変化回数上限閾値及び状態変化回数下限閾値と比較する(ステップＳ８００〜Ｓ８０３)。
【０１５６】
即ち、状態遷移制御部６０６は、状態管理共通テーブル６０７で管理しているセッションの状態遷移監視タイマがタイムアウトになると(Ｓ８００)、そのセッションＩＤに対応するノード状態を参照し、ノード状態がマルチＲＳＶＰ状態か否かを参照し、マルチＲＳＶＰ状態であれば、このセッションの状態変化回数を状態変化回数上限閾値及び状態変化回数下限閾値と夫々比較する(Ｓ８０１)。そして、状態遷移制御部６０６は、状態変化回数が上限閾値以上か否かを判定し(Ｓ８０２)、上限閾値以上でなければ(Ｓ８０２；ＮＯ)、状態変化回数が下限閾値以下か否かを判定する(Ｓ８０３)。なお、状態遷移監視タイマがタイムアウトになったセッションのノード状態がマルチＲＳＶＰ状態でない場合には、図１０に示す処理は終了する。
【０１５７】
状態変化回数が上限閾値以上でもなく(Ｓ８０２；ＮＯ)、下限閾値以下でもない場合(Ｓ８０３；ＮＯ)には、状態遷移制御部６０６は、ステップＳ８１１にて、状態管理共通テーブル６０７内の該当セッションＩＤに対応する状態変化回数を初期化する。その後、処理がステップＳ８００に戻る。
【０１５８】
状態変化回数が下限閾値以下であった場合(Ｓ８０３；ＹＥＳ)には、状態遷移制御部６０６は、状態遷移指示メッセージを生成し、このメッセージの宛先に相当する下流ノードへ送信する(ステップＳ８０４)。その後、状態遷移制御部６０６は、下流ノードからの状態遷移完了通知を所定時間待つ(ステップＳ８０５)。
【０１５９】
一方、状態変化回数が上限閾値以上であった場合には、状態遷移制御部６０６は状態遷移指示メッセージを生成し、このメッセージの宛先に相当する上流ノードへ送信する(ステップＳ８０７)。その後、状態遷移制御部６０６は、上流ノードからの状態遷移完了通知を所定時間待つ(ステップＳ８０８)。
【０１６０】
状態遷移制御部６０６は、ステップＳ８０５において下流ノードからの状態遷移完了通知を所定時間内に受信しなかった場合(Ｓ８０５；ＮＯ)、および、ステップＳ８０８において上流ノードからの状態遷移完了通知を受信しなかった場合(Ｓ８０８；ＮＯ)には、状態管理テーブル６０７内の該当セッションＩＤに対する状態変化回数を初期化し(ステップＳ８１１)、処理をステップＳ８００に戻す。
【０１６１】
一方、状態遷移制御部６０６は、状態遷移完了通知を所定時間内に下流ノードから受信した場合(Ｓ８０５；ＹＥＳ)には、状態管理共通テーブル６０７内の該当セッションＩＤに対するノード状態をＣＮ側ＲＳＶＰ状態に更新する(ステップＳ８０６)。これによって、当該セッションに対する無線ネットワークノード２１Ａの状態がマルチＲＳＶＰ状態からＣＮ側ＲＳＶＰ状態に遷移する。
【０１６２】
同様に、状態遷移制御部６０６は、状態遷移完了通知を所定時間内に上流ノードから受信した場合(Ｓ８０８；ＹＥＳ)には、状態管理共通テーブル６０７内の該当セッションＩＤに対するノード状態をＲＡＮ側ＲＳＶＰ状態に更新する(ステップＳ８０９)。これによって、当該セッションに対する無線ネットワークノード２１Ａの状態がマルチＲＳＶＰ状態からＲＡＮ側ＲＳＶＰ状態に遷移する。
【０１６３】
その後、状態遷移制御部６０６は、状態管理共通テーブル６０７内の該当セッションＩＤに対するＰＡＴＨリフレッシュタイマ及びＲＥＳＶリフレッシュタイマを初期化(リセット)する(ステップＳ８１０)。続いて、状態遷移制御部６０６は、状態管理共通テーブル６０７内の該当セッションＩＤに対応する状態変化回数を初期化(リセット)する(ステップＳ８１１)。
【０１６４】
なお、上述した動作では、状態遷移制御部６０６は、状態遷移監視タイマ値を単位時間とし、この単位時間内における予約状態の変化回数(状態変化回数)に基づいて無線ネットワークノード２１Ａの状態遷移についての判定を行っている。これに代えて、無線ネットワークノード２１Ａの状態遷移についての判定が、通信(フロー)確立時からのＲＡＮ側の状態変化の積算回数を用いて行われるようにしてもよい。
【０１６５】
〈状態遷移メッセージ受信による動作例〉
次に、無線ネットワークノード２１Ａが、ステップＳ８０４又はＳ８０７で送信された状態遷移指示メッセージを受信した際の動作について説明する。状態遷移指示メッセージは、ＲＳＶＰメッセージの一つとして送信され、宛先に相当する無線ネットワークノード２１Ａの外線インターフェイス部６０３で受信され、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５に渡される。
【０１６６】
図１１は、無線ネットワークノード２１Ａによる状態遷移指示メッセージ受信時の処理フローの例を示す図である。ステップＳ９００において、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＳＶＰメッセージを受信すると、このＲＳＶＰメッセージが状態遷移指示メッセージかどうかを判定する(ステップＳ９０１)。
【０１６７】
このとき、ＲＳＶＰメッセージが状態遷移指示メッセージでない場合(Ｓ９０１；ＮＯ)には、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５は、図７又は図８に示したような通常のＲＳＶＰメッセージに対する処理を行う(ステップＳ９０２)。
【０１６８】
これに対し、ＲＳＶＰメッセージが状態遷移指示メッセージであった場合(Ｓ９０１；ＹＥＳ)には、ＲＳＶＰ処理部は、状態遷移制御部６０６に状態遷移指示メッセージを転送する(ステップＳ９０３)。
【０１６９】
状態遷移制御部６０６は、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５から転送された状態遷移指示メッセージを受け取ると、この状態遷移指示メッセージから送信元ＩＰアドレスとセッションＩＤを抽出する(ステップＳ９０４)。
【０１７０】
次に、状態遷移制御部６０６は、状態管理共通テーブル６０７から抽出したセッションＩＤと同じセッションＩＤを持つエントリを検出し、このエントリのセッションＩＤに対応するノード状態をマルチＲＳＶＰ状態に設定する(ステップＳ９０５)。
【０１７１】
次に、状態遷移制御部６０６は検出したエントリの状態遷移監視タイマ，状態変化回数，ＰＡＴＨリフレッシュタイマ及びＲＥＳＶリフレッシュタイマを初期化(リセット)する(ステップＳ９０６)。
【０１７２】
そして、状態遷移制御部６０６は、ステップＳ９０４で抽出したＩＰアドレスを宛先として、状態遷移完了通知メッセージを返信する(ステップＳ９０７)。
【０１７３】
〈状態遷移指示／完了通知メッセージ〉
次に、図１０及び１１に示した動作において送受信される状態遷移指示メッセージ及び状態遷移完了通知メッセージ(状態遷移指示／完了通知メッセージ)について説明する。これらのメッセージは、本発明において導入されるものであるため、新しく定義する必要がある。この際、送信元アドレス、送信先(宛先)アドレス、メッセージ識別子、制御対象となるフロー（セッション）の４つの情報が最低でも必要となる。
【０１７４】
図１２に、ＩＰｖ６パケットを使用した状態遷移指示／完了通知メッセージの一例を示す。図１２では、状態遷移指示／完了通知メッセージのフォーマットとしてＲＳＶＰメッセージに準じたものを使用している。すなわち、状態遷移指示／完了通知メッセージは、ＩＰｖ６ヘッダ、ＲＳＶＰ共通ヘッダ、ＲＳＶＰオブジェクトから構成される。
【０１７５】
状態遷移指示メッセージにおいて、ＩＰｖ６ヘッダ内の送信元アドレスには、状態遷移指示メッセ−ジを生成・送信する無線ネットワークノード２１ＡのＩＰアドレスが格納される。
【０１７６】
また、送信先アドレスには、下流ノード又は上流ノードに相当する無線ネットワークノード２１ＡのＩＰアドレスが格納される。ＩＰアドレスとして、状態管理共通テーブル６０７の該当するセッションに対応するＲＳＶＰソフト状態に格納されているネクスト・ホップ・アドレス(Next Hop Address)又はプレビアス・ホップ・アドレス(Previous Hop Address)が用いられる。
【０１７７】
具体的には、状態遷移制御部６０６は、上流ノードへ状態遷移指示メッセージを送信する場合には、プレビアス・ホップ・アドレスを送信先アドレスとして用いる。一方、状態遷移制御部６０６は、下流ノードへ状態遷移指示メッセージを送信する場合には、ネクスト・ホップ・アドレスを送信先アドレスとして用いる。
【０１７８】
また、状態遷移指示メッセージ又は状態遷移応答メッセージであることを識別するため、ＲＳＶＰ共通ヘッダ内のＲＳＶＰタイプが使用される。具体的には、ＲＳＶＰタイプ領域に対応する状態遷移指示メッセージ及び状態遷移完了通知メッセージの２つ分のメッセージタイプが定義され、送信対象のメッセージに応じたメッセージタイプがＲＳＶＰタイプ領域に格納される。
【０１７９】
そして、状態遷移の対象となるセッションを指定するため、ＲＳＶＰオブジェクトとしてセッションオブジェクトが利用される。
【０１８０】
〔実施形態の作用〕
本発明の実施形態によると、ＲＳＶＰに基づくリソースの予約状態のリフレッシュ動作が、所定の無線ネットワークノード２１Ａを境とするコアネットワーク側(ＣＮ側)と移動通信ネットワーク側(ＲＡＮ側)とで独立して行われる。
【０１８１】
これによって、トポロジーの変更すなわち状態変化の少ないＣＮ側では、リフレッシュ周期をＲＡＮ側よりも長く設定することによって、ネットワークリソースの浪費を最小限に抑えることができる。一方、移動端末４０の移動に伴う状態変化が頻繁に起こることが想定されるＲＡＮ側では、リフレッシュ周期をＣＮ側よりも短くすることで、リソースの予約状態を常に移動端末４０の動きに追随させることができ、所望の通信品質(ＱｏＳ)を確保することが可能となる。
【０１８２】
さらに、本発明の実施形態によると、フローに対するＲＳＶＰ処理を二重化させるポイント(境界ノード；マルチＲＳＶＰノード)を移動端末４０の状態によってダイナミックに(動的に)変更することができる。
【０１８３】
即ち、移動端末４０の移動範囲が広範囲に渡る場合(マルチＲＳＶＰノードが頻繁に予約状態の変化を示すＲＥＳＶメッセージを受信する場合)には、フローに対するＲＳＶＰの二重化ポイント(マルチＲＳＶＰノード)をＣＮ１０近い側へ移行させる。一方、移動端末４０の移動範囲がそれほど広くない場合(マルチＲＳＶＰノードが予約状態の変化を示すＲＥＳＶメッセージを殆ど受信しない場合)には、移動端末４０に近い側にＲＳＶＰの二重化ポイント(マルチＲＳＶＰノード)を移行させる。
【０１８４】
即ち、移動通信網(ＲＡＮ)は、移動端末４０の状態(位置変化等)に応じて、最も適切な二重化ポイント(マルチＲＳＶＰノード)を自動的に判別し、無線ネットワークノード２１Ａの状態を遷移させていくのである。これにより、通信の品質を最大限確保しながらも、ネットワークリソースの消費量を最小限に抑えることができる。
【０１８５】
以上の機能により、移動端末４０のユーザは常に最適に予約されたリソースを使用することで品質の高い大容量通信サービスの提供を受けることができる。一方、ネットワークリソースの浪費を抑えることにより、このような大容量通信サービスを実現するためのインフラ設備も最低限の規模及びコストで構築可能となる。
【０１８６】
〔その他〕
上述した実施形態は、以下の発明を開示する。
（付記１）リソース予約プロトコルを実装したコアネットワークに接続される移動通信ネットワークと、
前記移動通信ネットワークに含まれる複数の無線ネットワークノードと、
前記コアネットワーク及び前記移動通信ネットワークを通過するデータ送信ノードとデータ受信ノードとの間のデータのフローに対するネットワークリソースをリソース予約プロトコルに基づいて予約する手段と、
前記フローに係るネットワークリソースの予約状態をリフレッシュする領域を前記フローが通過する所定の無線ネットワークノードを境としてコアネットワーク側と移動通信ネットワーク側とに分割し、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの頻度よりも高い頻度で行うリフレッシュ制御手段と、
を含むＲＳＶＰを用いた移動通信システム。（１）
（付記２）前記リフレッシュ制御手段は、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの周期よりも短い周期で行う、付記１記載のＲＳＶＰを用いた移動通信システム。（２）
（付記３）前記フローに対する前記移動通信ネットワークの状態の変化に応じて、前記境界となる無線ネットワークノードとしての境界ノードを変更する境界ノード変更手段をさらに含む、付記１記載のＲＳＶＰを用いた移動通信システム。（３）
（付記４）前記境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が上限値を上回った場合に、現在の境界ノードよりもコアネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、付記３記載のＲＳＶＰを用いた移動通信システム。（４）
（付記５）前記境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が下限値を下回った場合に、現在の境界ノードよりも移動通信ネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、付記３記載のＲＳＶＰを用いた移動通信システム。（５）
（付記６）前記リフレッシュ制御手段は、前記コアネットワーク側と前記移動通信ネットワーク側との境となる無線ネットワークノードに設けられた状態記憶部とＲＳＶＰ処理部とを含み、
前記状態記憶部は、少なくとも前記フローに対する前記移動通信ネットワーク側のネットワークリソースの予約状態を格納し、
前記ＲＳＶＰ処理部は、前記移動通信ネットワーク側からネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを受信し、このリフレッシュメッセージに含まれたネットワークリソースの予約状態が前記状態記憶部に格納されている予約状態からの変化を示さない場合には、このリフレッシュメッセージの転送を停止する、付記１記載のＲＳＶＰを用いた移動通信システム。
（付記７）前記ＲＳＶＰ処理部は、前記移動通信ネットワーク側から受信したリフレッシュメッセージに含まれたネットワークリソースの予約状態が前記状態記憶部に格納されている予約状態からの変化を示す場合には、この予約状態で前記状態記憶部に格納された予約状態を更新し、この予約状態を含む前記コアネットワーク側のネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを生成し、前記コアネットワーク側へ送信する、付記６記載のＲＳＶＰを用いた移動通信システム。
（付記８）前記リフレッシュ制御手段は、
第１の時間を計時する第１のタイマと、
第１の時間よりも短い第２の時間を計時する第２のタイマと、
前記第１のタイマが第１の時間を計時する毎に、前記コアネットワーク側のネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを生成して前記コアネットワーク側へ送信する第１の処理部と、
前記第１の処理部から独立して、前記第２のタイマが第２の時間を計時する毎に、前記移動通信ネットワーク側のネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを生成して前記移動通信ネットワーク側へ送信する第２の処理部とを含む、付記１記載のＲＳＶＰを用いた移動通信システム。
（付記９）前記コアネットワーク側と前記移動通信ネットワーク側との境となる無線ネットワークノードは、状態監視部と、所定の時間を計時する状態監視タイマと、前記状態監視タイマが所定の時間を計時する間に前記移動通信ネットワーク側から受信された複数のリフレッシュメッセージによる予約状態の変化回数を記憶する状態変化回数記憶部と、変化回数の閾値を記憶する閾値記憶部とをさらに含み、
前記状態監視部は、前記状態監視タイマが所定の時間を計時する毎に、前記状態変化回数記憶部に記憶された変化回数が前記閾値記憶部に記憶された閾値を上回っているか否かを判定し、変化回数が閾値を上回っている場合には、この無線ネットワークノードのコアネットワーク側に存する他の無線ネットワークノードに、この無線ネットワークノードの代わりに前記境となることを指示するメッセージを発行し送信する、付記７記載のＲＳＶＰを用いた移動通信システム。
（付記１０）前記コアネットワーク側と前記移動通信ネットワーク側との境となる無線ネットワークノードは、状態監視部と、所定の時間を計時する状態監視タイマと、前記状態監視タイマが所定の時間を計時する間に前記移動通信ネットワーク側から受信された複数のリフレッシュメッセージによる予約状態の変化回数を記憶する状態変化回数記憶部と、変化回数の閾値を記憶する閾値記憶部とをさらに含み、
前記状態監視部は、前記状態監視タイマが所定の時間を計時する毎に、前記状態変化回数記憶部に記憶された変化回数が前記閾値記憶部に記憶された閾値を下回っているか否かを判定し、変化回数が閾値を下回っている場合には、この無線ネットワークノードの移動通信ネットワーク側に存する他の無線ネットワークノードに、この無線ネットワークノードの代わりに前記境となることを指示するメッセージを発行し送信する、付記７記載のＲＳＶＰを用いた移動通信システム。
【０１８７】
【本発明の効果】
本発明によれば、ネットワークリソースの予約状態をネットワークの状態変化に柔軟に追随させることができる一方で、ネットワークリソースの有効利用を図ることができる。
【図面の簡単な説明】
【図１】図１は、移動通信システムにＲＳＶＰを用いることを想定した場合の例を示す図である。
【図２】図２は、図１に示したようなシステムにおけるＲＳＶＰ処理イメージを示す図である。
【図３】図３は、従来の方式に基づいたＲＳＶＰネットワークを示す図である。
【図４】図４は、本発明による移動通信システムの実施形態を示す図である。
【図５】図５は、移動通信システムに適したＲＳＶＰネットワークを示す図である。
【図６】図６は、無線ネットワークノードの状態遷移を示す図である。
【図７】図７は、無線ネットワークノードの一実施形態を示す図である。
【図８】図８は、無線ネットワークノードによるＲＥＳＶメッセージの処理フローの例を示す図である。
【図９】図９は、無線ネットワークノードによるＰＡＴＨメッセージの処理フローの例を示す図である。
【図１０】図１０は、無線ネットワークノードにおける状態遷移制御の処理フローの例を示す図である。
【図１１】図１１は、無線ネットワークノードによる状態遷移指示メッセージ受信時の処理フローの例を示す図である。
【図１２】図１２は、ＩＰｖ６パケットを使用した状態遷移指示／応答メッセージフォーマットの一例を示す図である。
【符号の説明】
１０ コアネットワーク(ＣＮ)
２０ 無線アクセスネットワーク(ＲＡＮ)
２１，２１Ａ 無線ネットワークノード
３０ データ送信／受信ノード
４０ 移動端末
２２ 二重化ＲＳＶＰ処理部
６０４ ＣＮ側ＲＳＶＰ処理部
６０５ ＲＡＮ側ＲＳＶＰ処理部
６０６ 状態遷移制御部
６０７ 状態管理共通テーブル
６０８ システムデータ格納テーブル
【発明の属する技術分野】
本発明は、リソース予約プロトコル(Resource Reservation Protocol：RSVP)を用いた移動通信システムにおける、リソース制御方法に関する。
【０００２】
【従来の技術】
近年、移動通信技術の急速な発展によって、無線区間におけるデータ転送レートは飛躍的な向上を遂げている。このため、音声や低レートのパケット通信といった従来のサービスに加えて、ビデオ又は音楽のような大容量のリアルタイムデータの配信が可能になろうとしている。今後、大容量通信技術を用いた多彩なサービスが提供されると考えられる。大容量サービスをその品質を確保しつつ実現するためには、無線区間だけでなくネットワーク内の全てのノードにおいて、要求される品質(ＱｏＳ)を確保することが要求される。
【０００３】
リソース予約プロトコル(ＲＳＶＰ)は、通信時のＱｏＳを確保するためのプロトコルの一つであり、ＩＥＴＦ(Internet Engineering Task Force)がＲＦＣ２２０５により規定したものである。
【０００４】
ＲＳＶＰは、あるエンド−エンド間における通信の単位をセッション、各セッションにおけるデータストリームをフローと定義し、フローが通過するネットワーク内の全てのノードにおいて、帯域等のネットワークリソースを予め確保するためのプロトコルである。
【０００５】
フローの受信システムは送信システムとの間でＲＳＶＰメッセージの交換を行い、この過程において、受信システムと送信システムの間に存在する全てのノード（ＩＰネットワークにおけるルータなど）上のリソースが予約される。さらに、ＲＳＶＰでは、ＩＰネットワークのような動的なネットワークに柔軟に対応できるように、各ノードにおける予約状態を「ＲＳＶＰソフト状態」により管理しており、このＲＳＶＰソフト状態は定期的に発行されるリフレッシュメッセージにより常に最新の状態に更新される。
【０００６】
ＲＳＶＰは主にＩＰネットワークで使用されている。移動通信システムにおける使用例は未だなく、具体的な実施方法や問題点などはまだ明らかになっていない点が多い。
【０００７】
現在の移動通信システムにＲＳＶＰを適用することを仮定した場合のシステム例の概略を図１に示す。移動端末１０６は、コアネットワーク(Core Network:CN)１０１、無線ネットワークノード１０３〜１０５から構成される無線アクセスネットワーク(Radio Access Network:RAN)１０２を経由してサーバ１００にアクセスし、データのダウンロード等を行う。
【０００８】
コアネットワーク１０１内の各ノードにはＲＳＶＰが実装されているものとし、無線ネットワークノード１０３〜１０５のそれぞれにもＲＳＶＰが実装されている。このようなシステムにおいて、移動端末１０６がサーバ１００からデータのダウンロードを開始し、終了するまでの動作を簡単に説明する。
【０００９】
図２は、ＲＳＶＰの処理シーケンスを簡単に示したものである。図２は、移動端末がサーバから配信されるデータをダウンロードする様子を示したものであり、ＲＳＶＰに関する処理としては、大別して以下の３つに分けることができる。(１) セッション開始時におけるダウンロードパス上のリソース予約処理
(２) ダウンロード中における、ソフト状態のリフレッシュ
(３) セッション終了時のリソース開放処理
セッションを開始する際には、移動端末は適切なプロトコルを用いてデータ配信グループに参加するための処理を行う。サーバは、この処理を受け付けると、フローに関する経路情報(パスの予約内容)等を格納した“ＰＡＴＨ”と呼ばれるＲＳＶＰメッセージを移動端末に対して送信する。ＰＡＴＨメッセージは、移動端末へ到達する途中の全てのＲＳＶＰノード(コアネットワーク１０１内におけるＲＳＶＰを実装したノード，及び図１におけるＲＳＶＰが実装された無線ネットワークノード)上で解読され、そのＲＳＶＰノード上にＲＳＶＰソフト状態の一つであるＰＡＴＨ状態(パスの予約状態)を確立してゆく。
【００１０】
移動端末は、ＰＡＴＨメッセージを受信すると、リソース予約に関する情報(リソースの予約内容)を格納した“ＲＥＳＶ”と呼ばれるＲＳＶＰメッセージをサーバに対して送信する。ＰＡＴＨメッセージのときと同様に、ＲＥＳＶメッセージはサーバへ到達する途中の全てのＲＳＶＰノード上で解読され、そのノード上にＲＳＶＰソフト状態の一つであるＲＥＳＶ状態(リソースの予約状態)を確立してゆく。
【００１１】
このように、移動端末とサーバ間でＰＡＴＨメッセージとＲＥＳＶメッセージとの交換を行うことにより、移動端末とサーバとの間のパス上に存在する全ノードにおけるリソース予約が完了する。
【００１２】
リソースの予約が完了すると、サーバは移動端末に対してデータの送信を開始する。この間、各ノード上のＲＳＶＰのリソース予約状態(ＲＳＶＰソフト状態)は、常に最新の情報に更新(リフレッシュ)される。このため、ＲＳＶＰが定めるタイマ(リフレッシュタイマ)に基づき、サーバはＰＡＴＨメッセージを移動端末へ定期的に送信し、移動端末はＲＥＳＶメッセージをサーバへ定期的に送信する。
【００１３】
これによって、移動端末の移動あるいはネットワークノードの故障等によりフローの経路が動的に変化したり、移動端末によるリソース獲得要求(リソースの予約内容)が変更された場合でも、リソースの予約状態は常にそれに追随することができる。
【００１４】
セッションを終了する場合には、移動端末はサーバに対して“ＲＳＶＰ ＴＥＡＲ”と呼ばれるＲＳＶＰメッセージを、サーバは移動端末に対して“ＰＡＴＨＴＥＡＲ”と呼ばれるＲＳＶＰメッセージを送出する。セッション上の各ノードは、ＲＳＶＰ ＴＥＡＲメッセージ、ＰＡＴＨ ＴＥＡＲメッセージを受信すると、ノード上のリソース予約状態、パス状態の開放処理を行う。
【００１５】
なお、図２には記載していないが、セッション終了時には、必ずしもＲＳＶＰＴＥＡＲメッセージ、ＰＡＴＨ ＴＥＡＲメッセージを送信する必要はない。各ノードの予約状態は、所定時間内にリフレッシュメッセージを受信しない場合には、自律で状態を開放するからである。
【００１６】
【発明が解決しようとする課題】
上述した通り、動的に変化するネットワーク環境の中で、データフローに対して常に最適なＱｏＳを確保するためには、パス(フロー)上の各ノードにおけるリソースの予約状態を常に最新に更新する必要がある。このため、サーバ及び移動端末は、一定時間毎に及び予約状態が変化する毎に、リフレッシュ用のＰＡＴＨメッセージ又はＲＥＳＶメッセージ(これらをまとめて指す場合には「リフレッシュメッセージ」と表記することもある)を送信しなければならない。移動通信システムにおいては、特に、このリフレッシュ動作が問題となってくる。
【００１７】
移動通信システムが通常の通信システムとその性質を異にする要因は、端末装置(移動端末)の位置が頻繁に変更される点にある。即ち、移動端末がその位置を変えると、パスの経路の変化や無線状態の変化が起こる。このため、移動端末とサーバとの間でネットワーク内に必要なリソースを予約した後も、移動端末の移動による状態の変化に応じて頻繁に予約状態をリフレッシュする必要がある。さらに、上述したように、予約状態が変化しない場合でも、定常的にリフレッシュメッセージの交換を行う必要がある。
【００１８】
このように頻繁に通信経路や無線状態が変化することが予想される移動通信システムにおいては、これらの状態の変化に対してリソースの予約状態が追随するためにリフレッシュメッセージの送信間隔はごく短いものでなくてはならない。
【００１９】
これらの理由から、図１に示した移動端末とサーバとの間では非常に多くのリフレッシュメッセージが交換されることになる。すると、このリフレッシュ動作がコアネットワーク及び移動通信ネットワークのリソースを圧迫するという問題を引き起こす可能性があった。
【００２０】
また、サーバ等のデータ配信ノード(データ送信／受信ノード)は、コアネットワーク内に存在するのが一般的である。このような場合において、サーバと移動端末との間で頻繁にリフレッシュメッセージのやりとりを行ったとしても、実際に予約状態が変更されるのは移動端末に近い部分だけであるということが有り得る。この場合、コアネットワーク内の各ノードにおける予約状態にはなんらの変更がなく、同じ予約状態が単に更新されるだけとなる。コアネットワーク内のトポロジーは無線アクセスネットワークに比べて頻繁に変化するものではないと考えられるからである。従って、コアネットワーク内の各ノードが頻繁にリフレッシュメッセージを受信しても、それらは無駄にネットワークリソースを消費するだけで実効的には意味のないものとなってしまう。
【００２１】
言い換えると、図１に示した移動通信システムでは、リソースの予約状態のリフレッシュ周期が無線アクセスネットワークに合わせて短く設定された場合には、予約状態は無線アクセスネットワークの状態変化に適正に追随することができるが、無駄なリフレッシュメッセージがコアネットワークに流れ込み、ネットワークリソースを浪費する(図３(Ａ)参照)。一方、リフレッシュ周期がコアネットワークに合わせて長く設定された場合には、コアネットワークにおいて無駄なリフレッシュメッセージが減少するが、予約状態が無線アクセスネットワークの状態変化に追随できなくなる(図３(Ｂ)参照)。
【００２２】
以上のように、移動通信システムにＲＳＶＰの実装を試みた場合、２つの矛盾した要求を同時に実現する必要がある。すなわち、同一パス上であるにもかかわらず、移動端末に近い側では、移動端末の移動性に伴い、頻繁にリフレッシュメッセージを交換する必要があり、サーバに近い側では、逆にリフレッシュメッセージは最小限に抑え、ネットワークリソースを節約する必要がある。
【００２３】
本発明の目的は、ネットワークリソースの予約状態をネットワークの状態変化に柔軟に追随させることができる一方で、ネットワークリソースの有効利用を図ることができるＲＳＶＰを用いた移動通信システムを提供することである。
【００２４】
【課題を解決するための手段】
本発明は、上記目的を達成するために以下の構成を採用する。
【００２５】
本発明は、ＲＳＶＰを用いた移動通信システムであり、リソース予約プロトコルを実装したコアネットワークに接続される移動通信ネットワークと、
前記移動通信ネットワークに含まれる複数の無線ネットワークノードと、
前記コアネットワーク及び前記移動通信ネットワークを通過するデータ送信ノードとデータ受信ノードとの間のデータのフローに対するネットワークリソースをリソース予約プロトコルに基づいて予約する手段と、
前記フローに係るネットワークリソースの予約状態をリフレッシュする領域を前記フローが通過する所定の無線ネットワークノードを境としてコアネットワーク側と移動通信ネットワーク側とに分割し、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの頻度よりも高い頻度で行うリフレッシュ制御手段と、
を含む。
【００２６】
本発明によれば、リフレッシュ制御手段が移動通信ネットワーク側のリフレッシュをコアネットワーク側よりも高い頻度で行う。これによって、移動通信ネットワーク側の予約状態を移動通信ネットワークの状態の変化に追随させることができる。一方、コアネットワーク側のリフレッシュの頻度が移動通信ネットワーク側よりも抑えられることにより、無駄なリフレッシュメッセージの転送によるネットワークリソースの浪費を抑えることができる。
【００２７】
本発明のリフレッシュ制御手段は、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの周期よりも短い周期で行う、ように構成するのが好ましい。
【００２８】
また、本発明は、前記フローに対する前記移動通信ネットワークの状態の変化に応じて、前記境界となる無線ネットワークノードとしての境界ノードを変更する境界ノード変更手段をさらに含む、ように構成するのが好ましい。
【００２９】
このようにすれば、移動通信ネットワークの状態の変化に応じてリフレッシュが頻繁に行われる移動通信ネットワーク側の大きさを制御できる。これによって、リフレッシュメッセージの交換を頻繁に行う必要のある領域を可能な限り小さくすることができるので、移動通信ネットワークにおけるネットワークリソースの有効利用を図ることができる。
【００３０】
本発明における境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が上限値を上回った場合に、現在の境界ノードよりもコアネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、ように構成するのが好ましい。
【００３１】
また、本発明における境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が下限値を下回った場合に、現在の境界ノードよりも移動通信ネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、ように構成するのが好ましい。
【００３２】
【発明の実施の形態】
以下、図面を用いて本発明の実施形態を説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００３３】
〔概要〕
図４は、本発明による移動通信システムの例を示す図である。図４において、移動通信システムは、コアネットワーク(ＣＮ)１０と、無線アクセスネットワーク(ＲＡＮ)２０とを備える。ＣＮ１０は複数のノード(図示せず)を含んでおり、ＲＡＮ２０は複数の無線ネットワークノード２１(ＣＮ１０と移動端末４０との間に位置する無線ネットワークノード群)を含んでいる。
【００３４】
ＣＮ１０はデータ送受信ノード３０(例えば、データを配信するサーバ；以下、単に「ノード３０」という)を収容(接続)している。ノード３０がＲＡＮ２０に接続される移動端末４０との間でＣＮ１０及びＲＡＮ２０を介してデータ通信を行う場合、例えば、ノード３０から送信されるデータ(パケット)は、ＣＮ１０及びＲＡＮ２０において、ＩＰ宛先アドレスのような宛先情報に基づいて決定される転送経路(パス又はフロー)を通って移動端末４０に伝達される。
【００３５】
データのパス(フロー)は、ＣＮ１０において少なくとも１つのノードを通過し、ＲＡＮ２０において少なくとも１つの無線ネットワークノード２１を通過する。パスが通過する(パス上に位置する)ＣＮ１０内のノード及び無線ネットワークノード２１は、ノード３０からのデータを受信すると、そのデータに付加された宛先情報(ＩＰ宛先アドレス)に基づいて、そのデータを次ホップに相当するノード(次ノード)に転送する。このような転送処理がパス上の各ノードにて行われることにより、ノード３０からのデータが移動端末４０に到達する。移動端末４０からノード３０へデータを伝達する場合も、同様である。
【００３６】
上述したデータ通信(データの送受信)に対し、所望のＱｏＳを確保するため、パス(フロー)が通過する各ノードは、ＲＳＶＰを用いてパスに係るネットワークリソースを予約する。また、リソースの予約状態のリフレッシュを行う。このため、ＣＮ１０の各ノード及びＲＡＮ２０の各無線ネットワークノード２１は、ＲＳＶＰに基づいてフローに対するネットワークリソースを予約する手段としての機能を実装している。
【００３７】
ノード３０から移動端末４０へデータを伝送するためのフローについてリソースの予約処理が行われる場合には、ＰＡＴＨメッセージがノード３０から移動端末４０へ向けて送信され、ＲＥＳＶメッセージが移動端末４０からノード３０へ向けて送信される。また、ノード３０は、予約状態(ＰＡＴＨ状態)をリフレッシュするためのＰＡＴＨメッセージを周期的に移動端末４０へ向けて送信し、移動端末４０は、予約状態(ＲＥＳＶ状態)をリフレッシュするためのＲＥＳＶメッセージを周期的にノード３０へ向けて送信する。
【００３８】
これに対し、移動端末４０からノード３０へデータを伝達するためのフローについてリソースの予約処理が行われる場合には、ＰＡＴＨメッセージが移動端末４０からノード３０へ向けて送信され、ＲＥＳＶメッセージがノード３０から移動端末４０へ向けて送信される。また、移動端末４０は予約状態(ＰＡＴＨ状態)をリフレッシュするためのＰＡＴＨメッセージを周期的にノード３０へ向けて送信し、ノード３０は予約状態(ＲＥＳＶ状態)をリフレッシュするためのＲＥＳＶメッセージを周期的に移動端末４０へ向けて送信する。
【００３９】
即ち、フローの上流側のエンドに相当するノードはＰＡＴＨメッセージを下流側のエンドに相当するノードへ向けて送信し、フローの下流側のエンドに相当するノードはＲＥＳＶメッセージをフローの上流側のエンドに相当するノードへ向けて送信する。
【００４０】
従って、フローが通過するＣＮ１０及びＲＡＮ２０内の各ノードは、フローの上流側からＰＡＴＨメッセージを受信し、フローの下流側からＲＥＳＶメッセージを受信する。以降の説明は、ノード３０(データ送信ノード)から移動端末４０(データ受信ノード)へ向けてデータを伝送するためのフローを想定して説明する。但し、本発明は、移動端末４０(データ送信ノード)からノード３０(データ受信ノード)へデータを伝送するためのフローについてのリソース予約処理についても適用することができる。
【００４１】
即ち、本発明は、データ送信ノードとデータ受信ノードとの間でのコアネットワーク及び移動通信ネットワークを介したデータフローに対して適用されるものであり、このときのデータフローのデータの伝送方向を問わない。
【００４２】
ＣＮ１０の各ノード及びＲＡＮ２０の各無線ネットワークノード２１は、予約状態のリフレッシュ動作として、次の動作を行う。即ち、各ノードは、ノード３０及び／又は移動端末４０からのリフレッシュ用のＲＳＶＰメッセージ(ＰＡＴＨメッセージ，ＲＥＳＶメッセージ；以下、これらをまとめて指す場合には、「リフレッシュメッセージ」と表記する)を受信すると、そのリフレッシュメッセージを次ホップに相当するノードに転送する。このとき、メッセージに含まれた予約状態に変化(ネットワークのトポロジ(パスのルート)変更，リソース獲得要求(内容)の変更等)がある場合には、その予約状態を確保するためのネットワークリソースの予約処理を実行する。
【００４３】
本発明による移動通信システムでは、ノード３０と移動端末４０との間のデータのパス(フロー)のような、ＣＮ１０及びＲＡＮ２０を通過するパスについてリソースの予約処理を行う領域が、そのパス上の所定の無線ネットワークノード２１を境としてノード３０側(ＣＮ側)とその逆側としての移動端末４０側(ＲＡＮ側)とに分割され、各領域毎に独立したリソースの予約処理を行う。
【００４４】
即ち、パス上の所定の無線ネットワークノード２１が、ノード３０との間でＣＮ側のリソースの予約処理(リフレッシュを含む)を行い、移動端末４０との間でＲＡＮ側のリソースの予約処理(リフレッシュを含む)を行う。以下、二つの領域の境となる無線ネットワークノード２１を、必要に応じて「境界ノード」と呼ぶ。
【００４５】
そして、境界ノードは、ＲＡＮ側のリソースの予約状態のリフレッシュを、ＣＮ側のリソースの予約状態のリフレッシュよりも高い頻度で行う。このように、移動通信システムは、リフレッシュ制御手段を有している。これによって、ＣＮ側とＲＡＮ側とでリフレッシュメッセージの送信間隔を変えることができ、ＣＮ１０及びＲＡＮ２０に応じた頻度で予約状態のリフレッシュを行うことができる。
【００４６】
従って、ＣＮ側では、無駄なリフレッシュメッセージの送受信が抑えられるので、ネットワークリソースの有効利用及びノードに対する処理負荷の軽減を図ることができる。一方、ＲＡＮ側では、頻繁にリフレッシュメッセージの送受信(交換)が行われるようにすることで、移動端末４０の移動等に伴うＲＡＮ２０の状態変化や予約内容の変化等にリソースの予約状態を追随させることができる。
【００４７】
このようにして、ノード３０と移動端末４０との間の通信のＱｏＳを確保することができ、安定した品質の通信サービスを提供することができる。
【００４８】
さらに、本発明では、ノード３０と移動端末４０との間のパス(フロー)が複数の無線ネットワークノード２１を通過する場合において、境界ノードとなる無線ネットワークノード２１が、ＣＮ１０又はＲＡＮ２０の状態に応じて変更される。
【００４９】
上記を実現するため、ＲＡＮ２０内の少なくとも１つの無線ネットワークノード２１は二重化されたＲＳＶＰ処理部２２を備える。ＲＳＶＰ処理部２２は、例えば、ＣＮ側ＲＳＶＰ処理部６０４と、ＲＡＮ側ＲＳＶＰ処理部６０５とからなる。
【００５０】
二重化されたＲＳＶＰ処理部２２を持つ無線ネットワークノード２１(以下、「無線ネットワークノード２１Ａ」と表記する)は、ＣＮ１０及び／又はＲＡＮ２０の状態に応じて、単一のＲＳＶＰ処理部を持つ無線ネットワークノードとして動作する場合(シングルＲＳＶＰ状態)と、２つの独立した動作を行うＲＳＶＰ処理部を持つ無線ネットワークノードとして動作する場合(マルチＲＳＶＰ状態)との２通りの状態をとる。
【００５１】
シングルＲＳＶＰ状態では、ＲＳＶＰ処理部２２は、ＲＳＶＰメッセージに対して単一のＲＳＶＰ処理部として振る舞う。このため、無線ネットワークノード２１Ａの振る舞いは、単一のＲＳＶＰ処理部を持つノード(例えば、ＣＮ１０内のノード)と同様となる。
【００５２】
マルチＲＳＶＰ状態では、二重化されたＲＳＶＰ処理部２２のうち、一方(ＣＮ側ＲＳＶＰ処理部６０４)はノード３０からのＲＳＶＰメッセージを終端し、もう一方(ＲＡＮ側ＲＳＶＰ処理部６０５)は移動端末４０からのＲＳＶＰメッセージを終端する。また、マルチＲＳＶＰ状態では、ＣＮ側ＲＳＶＰ処理部６０４は、ノード３０(ＲＡＮ側)へリフレッシュメッセージを周期的に送信し、ＲＡＮ側ＲＳＶＰ処理部６０５は、移動端末４０(ＣＮ側)へリフレッシュメッセージを周期的に送信する。ＲＡＮ側へのリフレッシュメッセージの送信周期は、ＣＮ側よりも短くなっている。
【００５３】
このように、無線ネットワークノード２１Ａは、マルチＲＳＶＰ状態となることによって、上記した境界ノードとして機能する。このため、境界ノードは「マルチＲＳＶＰノード」とも呼ばれる。
【００５４】
また、ＲＳＶＰ処理部２２を構成する２つのＲＳＶＰ処理部(ＣＮ側ＲＳＶＰ処理部６０４及びＲＡＮ側ＲＳＶＰ処理部６０５)は、ＲＳＶＰによるリソース予約処理に関する情報を共有し、互いに必要な情報をやりとりする。これによって、ＲＳＶＰ処理部２２は、無線ネットワークノード２１があたかも単一のＲＳＶＰ処理部を実装しているかのように振る舞う。
【００５５】
さらに、複数の無線ネットワークノード２１Ａのうち、マルチＲＳＶＰ状態となる無線ネットワークノード(マルチＲＳＶＰノード)は、ＣＮ１０又はＲＡＮ２０の状態に応じてフロー単位で動的に移行することができる。
【００５６】
上述したように、本発明による移動通信システムは、マルチＲＳＶＰ状態の無線ネットワークノード２１Ａ(マルチＲＳＶＰノード)を境にして、ＣＮ側とＲＡＮ側のＲＳＶＰ処理、特にリフレッシュメッセージの送信間隔を相互に独立に設定する。
【００５７】
これによって、状態変化の小さいＣＮ１０と状態変化(特に経路変化)の非常に大きいＲＡＮ２０とが、それぞれのシステムに応じた適切な周期でリフレッシュメッセージの交換を行うことができる。従って、リフレッシュメッセージによるネットワークリソースの浪費を抑えながら、適切なリソースの予約状態の管理及び更新を行うことができる(図５参照)。
【００５８】
さらに、本発明による移動通信システムは、以下を含む。
(１)無線ネットワークノード２１がマルチＲＳＶＰノードとして動作する際の、２つのＲＳＶＰ処理部(ＣＮ側ＲＳＶＰ処理部６０４とＲＡＮ側ＲＳＶＰ処理部６０５)間のマッピング制御を行うための構成および方法。
(２)システム(ＣＮ１０及び／又はＲＡＮ２０)の状態に応じて、フロー毎にマルチＲＳＶＰノードを遷移させるための構成および方法。
【００５９】
〔無線ネットワークノードの状態遷移〕
無線ネットワークノード２１Ａがフロー毎にシングルＲＳＶＰ状態とマルチＲＳＶＰ状態との間を遷移する概念について説明する。図６は、無線ネットワークノード２１Ａの状態遷移を示す図である。
【００６０】
無線ネットワークノード２１Ａは、ＣＮ１０及び／又はＲＡＮ２０の状態に応じて、ＲＡＮ側ＲＳＶＰ状態５００と、マルチＲＳＶＰ状態５０１と、ＣＮ側ＲＳＶＰ状態５０２との間で遷移する。図６中の各状態５００〜５０２は、以下の機能を有する。
【００６１】
[マルチＲＳＶＰ状態５０１]
無線ネットワークノード２１Ａは、フローのリソース予約処理についてマルチＲＳＶＰノードとなる場合には、マルチＲＳＶＰ状態５０１になる。マルチＲＳＶＰ状態５０１では、無線ネットワークノード２１Ａは、ＲＳＶＰに基づくリソースの予約処理の対象となるフローに対して、移動端末４０側(ＲＡＮ側)とノード３０側(ＣＮ側)とのＲＳＶＰ(セッション)を独立に終端する。
【００６２】
即ち、マルチＲＳＶＰノードは、ノード３０と移動端末４０との間のフローについて、ノード３０とマルチＲＳＶＰノードとの間でのＲＳＶＰセッションと、マルチＲＳＶＰノードと移動端末４０との間でのＲＳＶＰセッションとを確立し、セッション毎に独立したリソース予約処理及びリフレッシュ動作を行う。
【００６３】
但し、無線ネットワークノード２１Ａ内のＲＳＶＰ処理部２２を構成するＲＡＮ側ＲＳＶＰ処理部６０５とＣＮ側ＲＳＶＰ処理部６０４とは、ＲＳＶＰに関する情報管理手段を共有する。
【００６４】
即ち、ＲＡＮ側ＲＳＶＰ処理部６０５とＣＮ側ＲＳＶＰ処理部６０４とは、１つのフローに対するＣＮ側のセッションとＲＡＮ側のセッションと同じセッション識別子(セッションＩＤ)で管理し、各セッションにおける予約状態(ソフト状態；ＰＡＴＨ状態及びＲＥＳＶ状態)を相互に交換し、一方のセッションにおける予約状態を他方のセッションにおける予約状態にマッピングする。
【００６５】
これによって、ＲＡＮ側ＲＳＶＰ処理部６０５及びＣＮ側ＲＳＶＰ処理部６０４は、無線ネットワークノード２１Ａがあたかも１つのＲＳＶＰ処理部を備えているかのように動作する。即ち、ＲＳＶＰ処理部２２は、フローに対して、見かけ上(ノード３０又は移動端末４０からの観点(ビュー)において)、一つのＲＳＶＰセッションによるリソースの予約処理が行われているように処理を行う。
【００６６】
このようなマルチＲＳＶＰ状態５０１の無線ネットワークノード２１Ａ，即ちマルチＲＳＶＰノードは、唯一、無線ネットワークノード２１Ａの状態遷移を行うかどうかの決定権を持つ。
【００６７】
このため、マルチＲＳＶＰノードは、常にリソース予約処理の対象のフローに対する予約状態の変化を監視し、既定の条件が満たされる場合には、近隣の無線ネットワークノード２１Ａに対して適切な状態遷移指示を発行することができる。
【００６８】
また、マルチＲＳＶＰノードは、ＲＥＳＶメッセージ及びＰＡＴＨメッセージに対して以下の処理を行う。
〈１〉ＲＡＮ側からＲＥＳＶメッセージを受信し終端する。
〈２〉ＲＥＳＶメッセージを生成しＣＮ側に送信する。
〈３〉ＣＮ側からＰＡＴＨメッセージを受信し終端する。
〈４〉ＰＡＴＨメッセージを生成しＲＡＮ側に送信する。
【００６９】
但し、上記した〈１〉〜〈４〉の処理は、ノード３０から移動端末４０へデータを伝送するためのフローに対する処理であり、この場合には、マルチＲＳＶＰノードは、移動端末４０(ＲＡＮ側)からＲＥＳＶメッセージのみを受信し、ノード３０(ＣＮ側)からはＰＡＴＨメッセージのみを受信する。また、リソース予約処理の対象のフローのデータ伝送方向が上記フローと逆方向の場合には、上記した〈１〉〜〈４〉の処理における「ＲＡＮ側」と「ＣＮ側」とが入れ替わる。
【００７０】
[ＲＡＮ側ＲＳＶＰ状態５００]
無線ネットワークノード２１Ａは、リソース予約処理の対象のフロー上において、マルチＲＳＶＰ状態５０１の無線ネットワークノード２１Ａ(マルチＲＳＶＰノード)よりも下流側(ＲＡＮ側)に位置する場合には、シングルＲＳＶＰ状態の一つとしてのＲＡＮ側ＲＳＶＰ状態５００となる。ＲＡＮ側ＲＳＶＰ状態５００では、無線ネットワークノード２１Ａは、単一のＲＳＶＰ処理部を持つノードとして動作する。即ち、フローの上流側及び下流側から夫々受信するＲＳＶＰメッセージを逆側へ転送する。
【００７１】
ＲＡＮ側のリソースの予約状態(ソフト状態；「ＲＳＶＰ状態」とも呼ぶ)のリフレッシュ周期(リフレッシュメッセージの送信間隔)はＣＮ側に比べて短く、頻繁に予約状態のリフレッシュが行われる。
【００７２】
ＲＡＮ側ＲＳＶＰ状態５００の無線ネットワークノード２１Ａは、ＲＥＳＶメッセージとＰＡＴＨメッセージについては、以下の処理を行う。但し、データがノード３０から移動端末４０へ伝送される場合(ノード３０→移動端末４０のフロー)であるものとする。
〈１〉ＲＡＮ側からＲＥＳＶメッセージを受信しＣＮ側に転送する。
〈２〉ＣＮ側からＰＡＴＨメッセージを受信しＲＡＮ側に転送する。
【００７３】
[ＣＮ側ＲＳＶＰ状態５０２]
無線ネットワークノード２１Ａは、リソース予約処理の対象のフロー上において、マルチＲＳＶＰ状態５０１の無線ネットワークノード２１Ａ(マルチＲＳＶＰノード)よりも上流側(ＣＮ側)に位置する場合には、シングルＲＳＶＰ状態の一つとしてのＣＮ側ＲＳＶＰ状態５０２となる。ＣＮ側ＲＳＶＰ状態５０２では、無線ネットワークノード２１Ａは、単一のＲＳＶＰ処理部を持つノードとして動作する。即ち、フローの上流側及び下流側から夫々受信するＲＳＶＰメッセージを逆側へ転送する。
【００７４】
ＣＮ側のリソースの予約状態(ソフト状態又はＲＳＶＰ状態)のリフレッシュ周期(リフレッシュメッセージの送信間隔)はＲＡＮ側に比べて長く、予約状態は頻繁にリフレッシュされない。
【００７５】
ＣＮ側ＲＳＶＰ状態５０２の無線ネットワークノード２１Ａは、ＲＥＳＶメッセージとＰＡＴＨメッセージについては、以下の処理を行う。但し、データがノード３０から移動端末４０へ伝送される場合(ノード３０→移動端末４０のフロー)であるものとする。
〈１〉ＲＡＮ側からＲＥＳＶメッセージを受信しＣＮ側に転送する。
〈２〉ＣＮ側からＰＡＴＨメッセージを受信し移動端末側に転送する。
【００７６】
ところで、マルチＲＳＶＰノードは、以下のように動作する。即ち、マルチＲＳＶＰノードは、リソースの予約処理対象のフローに対する予約状態の変化を常に監視する。ＲＡＮ側で予約状態の変化が多く発生しない場合には、ＲＡＮ側(移動端末４０)から送信されてくるリフレッシュメッセージは、マルチＲＳＶＰノードで管理しているＲＡＮ側の予約状態を頻繁に変化させない。
【００７７】
このように、マルチＲＳＶＰノードがＲＡＮ側から受信したリフレッシュメッセージで示される予約状態に変化がない場合(リフレッシュメッセージに含まれた予約状態と現在マルチＲＳＶＰノードで管理している予約状態とが同じである場合)には、マルチＲＳＶＰノードは、ＲＡＮ側からのリフレッシュメッセージをここで終端し、ＣＮ側へ転送しない。
【００７８】
従って、ＲＡＮ側での移動端末４０の移動性に起因する膨大なリフレッシュメッセージがＣＮ側に流れ込み、ＣＮ側のネットワークリソースを圧迫することを防止することができる。
【００７９】
一方、マルチＲＳＶＰノードは、ＲＡＮ側から受信した(終端した)リフレッシュメッセージで示される予約状態に変化がある場合(リフレッシュメッセージに含まれた予約状態と現在マルチＲＳＶＰノードで管理している予約状態とが異なる場合)には、上記受信したリフレッシュメッセージと同内容のリフレッシュメッセージを生成しＣＮ側へ送信する。なぜなら、処理対象のフローに対するＲＡＮ側の予約状態の変化をＣＮ側に反映させる必要があるからである。
【００８０】
従って、マルチＲＳＶＰノードは、予約状態の変化を示すリフレッシュメッセージをＲＡＮ側から頻繁に受信する場合には、リフレッシュメッセージを受信する毎に、この予約状態の変化を示すリフレッシュメッセージを生成しＣＮ側に送信しなければならない。このような場合には、マルチＲＳＶＰノードがＣＮ側で不要なリフレッシュメッセージを終端するという機能を殆ど果たさなくなる。
【００８１】
このため、マルチＲＳＶＰノードは、所定時間内におけるＲＡＮ側からの予約状態の変化を示すリフレッシュメッセージの受信数が所定の上限値を上回る場合には、フローの上流(ＣＮ側)に位置する近隣の他の無線ネットワークノード２１Ａ(以下、「上流ノード」と表記)に状態遷移指示メッセージを与えてその上流ノードの状態をマルチＲＳＶＰ状態５０１に遷移させ、自らはＲＡＮ側ＲＳＶＰ状態５００に遷移する。
【００８２】
その後、ＲＡＮ側ＲＳＶＰ状態５００となった無線ネットワークノード２１Ａは、ＲＡＮ側からのリフレッシュメッセージを上流ノードへ単に転送するのみで済む(リフレッシュメッセージの終端及び生成を行わなくて済む)ようになる。
【００８３】
また、マルチＲＳＶＰノードは、ＲＡＮ側から受信するリフレッシュメッセージが予約状態の変化を示さない場合には、そのリフレッシュメッセージを終端する(転送を停止する)。このようなリフレッシュメッセージは、マルチＲＳＶＰノードがＲＡＮ側から受信する意味を持たないものであり、マルチＲＳＶＰノード及びその下流近傍(例えば、リフレッシュメッセージをマルチＲＳＶＰノードへ転送する無線ネットワークノード)のネットワークリソースを浪費するだけである。
【００８４】
そこで、マルチＲＳＶＰノードで管理するＲＡＮ側の予約状態がＲＡＮ側からのリフレッシュメッセージで殆ど変化しない場合，即ち、所定時間内におけるＲＡＮ側からの予約状態の変化を示すリフレッシュメッセージの受信数が所定の下限値を下回る場合には、マルチＲＳＶＰノードは、フローの下流(ＲＡＮ側)に位置する近隣の他の無線ネットワークノード２１Ａ(以下、「下流ノード」と表記)に状態遷移指示メッセージを与えてその下流ノードの状態をマルチＲＳＶＰ状態５０１に遷移させ、自らはＣＮ側ＲＳＶＰ状態５０２に遷移する。
【００８５】
このように、移動通信システムは、移動通信ネットワークの状態の変化に応じて境界ノードを変更する境界ノード変更手段を備える。これによって、無用のリフレッシュメッセージの転送処理が抑えられ、この処理に使用されていたネットワークリソースを他の用途に有効に利用することが可能になる。
【００８６】
上記のように、ノードの状態遷移を行う否かの判断は、全てマルチＲＳＶＰノードが行う。従って、ＲＡＮ側ＲＳＶＰ状態５００又はＣＮ側ＲＳＶＰ状態５０２の無線ネットワークノード２１Ａは、マルチＲＳＶＰノードからの状態遷移指示を受け取ることにより、マルチＲＳＶＰ状態５０１に遷移し、新たなマルチＲＳＶＰノードとして動作する。
【００８７】
〔無線ネットワークノード２１Ａ〕
次に、上記したような動作を可能にするための無線ネットワークノード２１Ａの一実施形態について説明する。図７は、無線ネットワークノード２１Ａの一実施形態を示す図である。
【００８８】
無線ネットワークノード２１Ａは、ＣＮ側のＲＳＶＰセッションを終端するＣＮ側ＲＳＶＰ処理部６０４と、ＲＡＮ側のＲＳＶＰセッションを終端するＲＡＮ側ＲＳＶＰ処理部６０５と、図６で述べたような状態遷移に関する処理を行う状態遷移制御部６０６と、他の無線ネットワークノード２１又は２１Ａとのインターフェースである外線インターフェース部６０３と、従来の無線信号処理及びＲＳＶＰメッセージに基づくリソースの予約処理を行う信号処理部６０２と、主制御部６００とを有し、これらは互いに装置内バス６０１により接続されている。ＣＮ側ＲＳＶＰ処理部６０４とＲＡＮ側ＲＳＶＰ処理部６０５とが、二重化されたＲＳＶＰ処理部２２を構成する。
【００８９】
また、無線ネットワークノード２１Ａは、状態記憶部としての状態管理共通テーブル６０７を有する。状態管理共通テーブル６０７はＲＳＶＰソフト状態や、これに関連する情報をフロー単位で格納する。状態管理共通テーブル６０７は、ＣＮ側ＲＳＶＰ処理部６０４，ＲＡＮ側ＲＳＶＰ処理部６０５，及び状態遷移制御部６０６により共通に参照される情報格納手段である。
【００９０】
また、無線ネットワークノード２１Ａは、システムデータ格納テーブル６０８を有する。システムデータ格納テーブル６０８は、無線ネットワークノード２１Ａに固有のパラメータを格納している。主制御部６００は、無線ネットワークノード２１Ａの再起動時等に必要なパラメータを取得し、必要な部位に設定する。
【００９１】
〈状態管理共通テーブル〉
状態管理共通テーブル６０７は、フロー毎に生成される１以上のエントリ(レコード)を格納するようになっており、エントリは、フローに対するセッションＩＤ、ノード状態、状態変化回数、第１のタイマとしてのＰＡＴＨリフレッシュタイマ、第２のタイマとしてのＲＥＳＶリフレッシュタイマ、ＲＳＶＰソフト状態を設定するための複数の領域を持つ。夫々の情報の説明は次の通りである。
【００９２】
なお、図７に示す状態管理共通テーブル６０７は、ノード３０を上流とし移動端末４０を下流とするフローについて、移動端末４０から送信されてくるリフレッシュメッセージ(ＲＥＳＶメッセージ)に基づいて無線ネットワークノード２１Ａが状態遷移を行うための情報を格納している。
【００９３】
[セッションＩＤ]
セッションＩＤは、フロー毎に付与される識別子であり、無線ネットワークノード２１Ａ(装置)の内部でフローを識別するために使用される。本実施形態では、１つのフローに対するＲＡＮ側のＲＳＶＰセッションとＣＮ側のＲＳＶＰセッションとについて、同じセッションＩＤが使用される。
【００９４】
[ノード状態]
ノード状態は、セッションＩＤで特定されるフローに対する無線ネットワークノード２１Ａの状態を示す。ノード状態として、“マルチＲＳＶＰ状態”，“ＲＡＮ側ＲＳＶＰ状態”，及び“ＣＮ側ＲＳＶＰ状態”の何れかが格納される。
【００９５】
[状態遷移監視タイマ]
状態遷移監視タイマは、フローに対するＲＡＮ側のセッションに対するＲＳＶＰソフト状態が変化した回数(状態変化回数)を定期的に監視するためのタイマである。このタイマは定期的に所定の時間を計時し、所定の時間が計時される毎に、その所定の時間内における状態変化回数が参照される。
【００９６】
[状態変化回数]
状態変化回数は、ＲＡＮ側のセッションに対するＲＳＶＰ状態が変化した回数である。状態変化回数として格納された値に基づいて、無線ネットワークノード２１Ａが状態遷移を行うか否かの制御が行われる。状態変化回数は、状態遷移監視タイマがタイムアウトになる毎にリセットされ、クリアされる(“０”にされる)。
【００９７】
[ＰＡＴＨリフレッシュタイマ]
ＰＡＴＨリフレッシュタイマは、リフレッシュメッセージとしてのＰＡＴＨメッセージをＲＡＮ側(移動端末４０)へ周期的に送信するための時間を計時するタイマである。ＰＡＴＨリフレッシュタイマは、セッションに対応するノード状態がマルチＲＳＶＰ状態である場合にのみ使用される。ＰＡＴＨリフレッシュタイマにより計時される時間(タイマ値)として、ＰＡＴＨリフレッシュ周期が用いられる。ＰＡＴＨリフレッシュタイマの満了(タイムアウト)は、ＲＡＮ側ＲＳＶＰ処理部６０５で検出され、このとき、ＰＡＴＨメッセージがＲＡＮ側へ送信される。
【００９８】
[ＲＥＳＶリフレッシュタイマ]
ＲＥＳＶリフレッシュタイマは、リフレッシュメッセージとしてのＲＥＳＶメッセージをＣＮ側(ノード３０)へ周期的に送信するための時間を計時するタイマである。ＲＥＳＶリフレッシュタイマは、ＰＡＴＨリフレッシュタイマと同様に、セッションに対応するノード状態がマルチＲＳＶＰ状態である場合にのみ使用される。ＲＥＳＶリフレッシュタイマにより計時される時間(タイマ値)として、ＲＥＳＶリフレッシュ周期が用いられる。ＲＥＳＶリフレッシュタイマの満了(タイムアウト)は、ＣＮ側ＲＳＶＰ処理部６０４で検出され、このとき、ＲＥＳＶメッセージがＣＮ側へ送信される。
【００９９】
[ＲＳＶＰソフト状態]
ＲＳＶＰソフト状態は、ＲＥＳＶメッセージやＰＡＴＨメッセージ内に格納されたリソースの予約処理に係る情報であり、少なくともリソースの予約状態を示す情報がＲＳＶＰソフト状態として格納される。
【０１００】
〈システムデータ格納テーブル〉
システムデータ格納テーブル６０８は、ノード種別、状態変化回数上限閾値、状態変化回数下限閾値、ＰＡＴＨリフレッシュ周期、ＲＥＳＶリフレッシュ周期を格納するための領域を持つ。それぞれの情報の説明は以下の通りである。
【０１０１】
[ノード種別]
ノード種別は、無線ネットワークノード２１Ａがゲートウェイノードか否かを示す情報である。ゲートウェイノードは、フローに対するセッションが新規に追加された際にマルチＲＳＶＰ状態となる無線ネットワークノード２１Ａとして定義される。
【０１０２】
[状態変化回数上限閾値]
状態変化回数上限閾値は、ノード状態がマルチＲＳＶＰ状態であるセッションに対する無線ネットワークノード２１Ａの状態遷移のトリガとなる閾値である。状態変化回数が状態変化上限閾値を上回った場合には、無線ネットワークノード２１Ａは、自身の上流の近隣に位置する他の無線ネットワークノード２１Ａに対し、当該セッションについてマルチＲＳＶＰ状態へ遷移することを指示するための状態遷移指示メッセージを送信し、自らはＲＡＮ側ＲＳＶＰ状態に遷移する。
【０１０３】
[状態変化回数下限閾値]
状態変化回数下限閾値は、ノード状態がマルチＲＳＶＰ状態であるセッションに対する無線ネットワークノード２１Ａの状態遷移のトリガとなる閾値である。状態変化回数が状態変化下限閾値を下まわった場合には、無線ネットワークノード２１Ａは、自身の下流の近隣に位置する他の無線ネットワークノード２１Ａに対し、当該セッションについてマルチＲＳＶＰ状態へ遷移することを指示するための状態遷移指示メッセージを送信し、自らはＣＮ側ＲＳＶＰ状態に遷移する。
【０１０４】
[ＰＡＴＨリフレッシュ周期]
ＰＡＴＨリフレッシュ周期は、ＰＡＴＨリフレッシュタイマ値として使用されるタイマ値を示す情報である。通常、ＰＡＴＨリフレッシュ周期として、ＲＥＳＶリフレッシュ周期よりも小さな値が設定される。ＲＡＮ側でのリフレッシュをＣＮ側よりも頻繁に行うためである。
【０１０５】
[ＲＥＳＶリフレッシュ周期]
ＲＥＳＶリフレッシュ周期は、ＲＥＳＶリフレッシュタイマ値として使用されるタイマ値を示す情報である。通常、ＲＥＳＶリフレッシュ周期として、ＰＡＴＨリフレッシュ周期よりも大きな値が設定される。ＣＮ側に送信されるリフレッシュメッセージ(ＲＥＳＶメッセージ)の送信間隔を長くしてＣＮ側のリソースの浪費を抑えるためである。
【０１０６】
[状態遷移監視周期]
状態遷移監視周期は、状態遷移監視タイマ値として使用されるタイマ値を示す情報である。
【０１０７】
〈状態遷移制御部〉
次に状態遷移制御部６０６について説明する。状態遷移制御部６０６は、状態管理共通テーブル６０７を参照することにより、セッション毎にＲＳＶＰソフト状態を識別し、ＲＳＶＰソフト状態に応じて主に以下の処理を行う。
【０１０８】
状態遷移制御部６０６は、状態管理共通テーブル６０７内においてノード状態がマルチＲＳＶＰ状態であるセッションの全てに対し、状態遷移監視タイマで計時される一定時間(状態遷移監視タイマ値)毎に状態変化回数を０クリアする。これは、ある単位時間(状態遷移監視タイマ値)内に発生する状態変化の回数を測定するためである。０クリアのタイミングはセッション毎に共通となっていても、異なっていても良い。
【０１０９】
また、状態遷移制御部６０６は、マルチＲＳＶＰ状態のセッションに関して、ＲＡＮ側ＲＳＶＰ処理部６０５又はＣＮ側ＲＳＶＰ処理部６０４からＲＳＶＰ状態変化通知を受け取ると、状態変化回数に１を加算する。続いて、状態遷移制御部６０６は、加算後の値を状態変化回数上限閾値及び状態変化回数下限閾値と夫々比較する。このとき、状態遷移制御部６０６は、加算後の値が上限閾値を上まわる、又は下限閾値を下まわった場合には、そのセッションに対するノード状態を遷移させる。
【０１１０】
さらに、状態遷移制御部６０６は、近隣のマルチＲＳＶＰノードから或るセッションについてノード状態を遷移するための状態遷移指示メッセージを受け取った場合に、そのセッションに対するノード状態をマルチＲＳＶＰ状態に設定する。 また、状態遷移制御部６０６は、セッションが新規に追加される場合にも、ノード状態を設定する。
【０１１１】
〈ＲＳＶＰメッセージに対する処理〉
次に、無線ネットワークノード２１ＡにおけるＲＳＶＰメッセージに対する処理について説明する。図７において、無線ネットワークノード２１Ａは、ＲＡＮ側(移動端末側)及びＣＮ側から送信されてくる全てのＲＳＶＰメッセージを外線インターフェイス部６０３で受信する。ＲＳＶＰメッセージは、上述したように、ＰＡＴＨメッセージ，ＲＥＳＶメッセージ，ＰＡＴＨ ＴＥＡＲメッセージ，ＲＥＳＶ ＴＥＡＲメッセージの何れかである。
【０１１２】
ＣＮ側ＲＳＶＰ処理部６０４は、ＣＮ側からのＲＳＶＰメッセージの全てを外線インターフェイス部６０３から受け取り、受け取ったＲＳＶＰメッセージに対する処理を行う。一方、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＡＮ側からのＲＳＶＰメッセージの全てを受け取り、受け取ったＲＳＶＰメッセージに対する処理を行う。
【０１１３】
《ＲＥＳＶメッセージに対する動作例》
以下、リフレッシュメッセージであるＲＥＳＶメッセージに対する無線ネットワークノード２１Ａの動作について説明する。図８は、無線ネットワークノード２１Ａにおいて、ＲＥＳＶメッセージの処理が行われる際の動作の流れを示す図である。なお、本実施形態では、ＲＥＳＶメッセージは移動端末側(ＲＡＮ側)からのみ送信されてくるものとする。
【０１１４】
ＲＡＮ側ＲＳＶＰ処理部６０５は、ステップＳ７００でＲＥＳＶメッセージを受信すると、このＲＥＳＶメッセージからセッションＩＤを抽出し、このセッションＩＤが状態管理共通テーブル６０７内に格納されているか否かをチェックする(ステップＳ７０１,Ｓ７０２)。
【０１１５】
ステップＳ７０２において、抽出されたセッションＩＤと同一のセッションＩＤが状態管理共通テーブル６０７内に存在する場合(Ｓ７０２；ＹＥＳ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージに格納されているＲＳＶＰソフト状態と、セッションＩＤに対応する状態管理共通テーブル６０７内のＲＳＶＰソフト状態とを比較し(ステップＳ７０３)、ＲＳＶＰソフト状態として示されるリソースの予約状態が変化したかどうかを判定する(ステップＳ７０４)。
【０１１６】
このとき、予約状態が変化していない場合(Ｓ７０４；ＮＯ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、セッションＩＤに対応するノード状態を参照し、ノード状態がマルチＲＳＶＰ状態か否かを判定する(ステップＳ７０４ａ)。ノード状態がマルチＲＳＶＰ状態であれば(Ｓ７０４ａ；ＹＥＳ)、ＲＡＮ側ＲＳＶＰ処理部６０５は、このＲＥＳＶメッセージに対する処理を終了する。
【０１１７】
即ち、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージを終端し、この転送を停止する。これによって、予約状態の変化を示さないリフレッシュメッセージがＣＮ側へ転送されることが防止される。
【０１１８】
一方、ステップＳ７０４ａにおいて、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７０４ａ；ＮＯ)、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージをＣＮ側へ転送し(ステップＳ７１３)、このＲＥＳＶメッセージに対する処理を終了する。
【０１１９】
一方、ステップＳ７０４で予約状態が変化したと判定された場合(Ｓ７０４；ＹＥＳ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、状態管理共通テーブル６０７内の当該セッションＩＤに対応するＲＳＶＰソフト状態(リソースの予約状態)を更新する(ステップＳ７０５)。
【０１２０】
続いて、ＲＡＮ側ＲＳＶＰ処理部６０５は、そのセッションＩＤに対応するノード状態を参照し、ノード状態がマルチＲＳＶＰ状態かどうかを調べる(ステップＳ７１２)。このとき、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７１２；ＮＯ)、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＥＳＶメッセージをＣＮ側へ転送し(ステップＳ７１３)、このＲＥＳＶメッセージに対する処理を終了する。このステップＳ７１３の処理は、シングルＲＳＶＰ状態(ＲＡＮ側ＲＳＶＰ状態５００又はＣＮ側ＲＳＶＰ状態５０２)としての処理である。
【０１２１】
一方、ステップＳ７１２でセッションＩＤに対応するノード状態がマルチＲＳＶＰ状態であると判定された場合(Ｓ７１２；ＹＥＳ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、以下の２つの処理を並列に行う。
【０１２２】
第１に、ＲＡＮ側ＲＳＶＰ処理部６０５は、状態遷移制御部６０６に対してセッションＩＤを渡し、セッションＩＤに対するＲＳＶＰソフト状態が変化したことを通知する(ステップＳ７１４)。この通知を受けた状態遷移制御部６０６は、状態管理共通テーブル６０７内の、通知されたセッションＩＤに対応する状態変化回数に１を加算する(ステップＳ７１５)。
【０１２３】
第２に、ＲＡＮ側ＲＳＶＰ処理部６０５は、ＣＮ側ＲＳＶＰ処理部６０４にセッションＩＤを渡し、セッションのＲＳＶＰソフト状態が変化したことを通知する(ステップＳ７１６)。
【０１２４】
ＲＡＮ側ＲＳＶＰ処理部６０５からの通知を受けとったＣＮ側ＲＳＶＰ処理部６０４は、状態管理共通テーブル６０７内の、通知されたセッションＩＤに対応するＲＳＶＰソフト状態(リソースの予約状態)を取得し、これを含むＲＥＳＶメッセージを生成し、ＣＮ側へ送信する(ステップＳ７１７)。その後、ＣＮ側ＲＳＶＰ処理部６０４は、通知されたセッションＩＤに対応するＲＥＳＶリフレッシュタイマをリセットする(ステップＳ７１８)。
【０１２５】
なお、ＲＡＮ側ＲＳＶＰ処理部６０５は、ステップＳ７１５及びＳ７１６の処理が終了すると、このＲＥＳＶメッセージに対する処理を終了し、次のＲＥＳＶメッセージを受け付ける状態になる。
【０１２６】
ところで、ステップＳ７０２において、ＲＥＳＶメッセージから抽出されたセッションＩＤが状態管理共通テーブル６０７内で管理されているセッションＩＤのいずれとも一致しない場合(Ｓ７０２；ＮＯ)には、ＲＡＮ側ＲＳＶＰ処理部６０５は、抽出したセッションＩＤと、ＲＥＳＶメッセージに格納されているＲＳＶＰ情報(ＲＳＶＰソフト状態；リソースの予約状態)を状態管理共通テーブル６０７に追加する(ステップＳ７０６)。その後、ＲＡＮ側ＲＳＶＰ処理部６０５は、新規セッションを追加したことを状態遷移制御部６０６に通知する(ステップＳ７０７)。
【０１２７】
状態遷移制御部６０６は、新規セッション追加の通知をＲＡＮ側ＲＳＶＰ処理部６０５から受け取ると、システムデータ格納テーブル６０８に格納されているノード種別を参照し(ステップＳ７０８)、この無線ネットワークノード２１Ａがゲートウェイノードかどうかをチェックする(ステップＳ７０９)。
【０１２８】
このとき、ノード種別がゲートウェイノードであれば(Ｓ７０９；ＹＥＳ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をマルチＲＳＶＰ状態に設定する(ステップＳ７１０)。これによって、無線ネットワークノード２１Ａは、追加されたセッションに対してマルチＲＳＶＰノードとして振る舞う。
【０１２９】
一方、ノード種別がゲートウェイノードでなければ(Ｓ７０９；ＮＯ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をＲＡＮ側ＲＳＶＰ状態に設定する(ステップＳ７１１)。その後、上述したステップＳ７１２以降の処理が行われる。
【０１３０】
ところで、ノード状態がマルチＲＳＶＰ状態であるセッションについては、上述したステップＳ７００〜Ｓ７１８までの一連の処理から独立して、ＣＮ側ＲＳＶＰ処理部６０４が周期的にＲＥＳＶメッセージを生成しＣＮ側へ送信する処理が行われる。
【０１３１】
すなわち、ステップＳ７１９において、あるマルチＲＳＶＰ状態のセッションに対応するＲＥＳＶリフレッシュタイマ(第１のタイマ)がタイムアウトになると(Ｓ７１９；ＹＥＳ)、ＣＮ側ＲＳＶＰ処理部６０４は、第１の処理部として、このセッションに対応するＲＳＶＰソフト状態(リソースの予約状態)を状態管理共通テーブル６０７から取得し、これを含むＲＥＳＶメッセージを生成しＣＮ側へ送信する(ステップＳ７２０)。
【０１３２】
その後、ステップＳ７２１にて、ＣＮ側ＲＳＶＰ処理部６０４は、タイムアウトになったＲＥＳＶリフレッシュタイマをリセットする。これによって、ＣＮ側には、リソースの予約状態をリフレッシュするためのＲＥＳＶメッセージが周期的に送信される。
【０１３３】
《ＰＡＴＨメッセージに対する動作例》
無線ネットワークノード２１ＡにおけるＰＡＴＨメッセージに対する処理は、以下に示すように、ＲＥＳＶメッセージに対する処理と同様に行われる。図９は、無線ネットワークノード２１Ａにおいて、ＰＡＴＨメッセージの処理が行われる際の動作の流れを示す図である。なお、ＰＡＴＨメッセージはノード３０側(ＣＮ側)からのみ送信されてくるものとする。
【０１３４】
ＣＮ側ＲＳＶＰ処理部６０４は、ステップＳ７３０でＰＡＴＨメッセージを受信すると、このＰＡＴＨメッセージからセッションＩＤを抽出し、このセッションＩＤが状態管理共通テーブル６０７内に格納されているか否かをチェックする(ステップＳ７３１,Ｓ７３２)。
【０１３５】
ステップＳ７３２において、抽出されたセッションＩＤと同一のセッションＩＤが状態管理共通テーブル６０７内に存在する場合(Ｓ７３２；ＹＥＳ)には、ＣＮ側ＲＳＶＰ処理部６０４は、ＰＡＴＨメッセージに格納されているＲＳＶＰソフト状態と、セッションＩＤに対応する状態管理共通テーブル６０７内のＲＳＶＰソフト状態とを比較する(ステップＳ７３３)。
【０１３６】
続いて、ＣＮ側ＲＳＶＰ処理部６０４は、比較結果に基づいてＲＳＶＰソフト状態，即ち予約状態が変化したかどうかを判定する(ステップＳ７３４)。このとき、予約状態が変化していない場合(Ｓ７３４；ＮＯ)には、このセッションＩＤに対応するノード状態がマルチＲＳＶＰ状態か否かを判定する(ステップＳ７３４ａ)。このとき、ノード状態がマルチＲＳＶＰ状態であれば(Ｓ７３４ａ；ＹＥＳ)、ＣＮ側ＲＳＶＰ処理部６０４は、このＰＡＴＨメッセージに対する処理を終了し、無駄なＰＡＴＨメッセージがＲＡＮ側へ流れるのを防止する。
【０１３７】
一方、ステップＳ７３４ａにおいて、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７３４ａ；ＮＯ)、ＣＮ側ＲＳＶＰ処理部６０４は、ＰＡＴＨメッセージをＣＮ側へ転送し(ステップＳ７４３)、このＰＡＴＨメッセージに対する処理を終了する。ステップＳ７４３の処理は、シングルＲＳＶＰ状態(ＲＡＮ側ＲＳＶＰ状態５００又はＣＮ側ＲＳＶＰ状態５０２)としての処理である。
【０１３８】
一方、ＣＮ側ＲＳＶＰ処理部６０４は、ステップＳ７３４において予約状態が変化したと判定した場合(Ｓ７３４；ＹＥＳ)には、状態管理共通テーブル６０７内の当該セッションのＲＳＶＰソフト状態を更新する(ステップＳ７３５)。
【０１３９】
その後、ＣＮ側ＲＳＶＰ処理部６０４は、そのセッションＩＤに対応するノード状態を参照し、マルチＲＳＶＰ状態かどうかを調べる(ステップＳ７４２)。このとき、ノード状態がマルチＲＳＶＰ状態でなければ(Ｓ７４２；ＮＯ)、ＣＮ側ＲＳＶＰ処理部６０４は、ＰＡＴＨメッセージをＲＡＮ側へ転送する(Ｓ７４３)。
【０１４０】
一方、ステップＳ７４２で当該セッションのノード状態がマルチＲＳＶＰ状態であったと判定された場合(Ｓ７４２；ＹＥＳ)には、ＣＮ側ＲＳＶＰ処理部６０４は、ステップＳ７４６において、ＲＡＮ側ＲＳＶＰ処理部６０５にセッションＩＤを渡し、セッションのＲＳＶＰソフト状態が変化したことを通知する。なお、ＣＮ側ＲＳＶＰ処理部６０４は、Ｓ７４６の処理が終了すると、このＰＡＴＨメッセージに対する処理を終了し、次のＰＡＴＨメッセージを受け付ける状態になる。
【０１４１】
ＣＮ側ＲＳＶＰ処理部６０４からの通知を受けたＲＡＮ側ＲＳＶＰ処理部６０５は、状態管理共通テーブル６０７内の、通知されたセッションＩＤに対応するＲＳＶＰソフト状態を取得し、これを含むＰＡＴＨメッセージを生成し、ＣＮ側へ送信する(ステップＳ７４７)。その後、ステップＳ７４８において、ＣＮ側ＲＳＶＰ処理部６０４は、通知されたセッションＩＤに対応するＰＡＴＨリフレッシュタイマをリセットする。
【０１４２】
ところで、ステップＳ７３２において、ＰＡＴＨメッセージから抽出したセッションＩＤが状態管理共通テーブル６０７内に格納されているセッションＩＤのいずれとも一致しない場合(Ｓ７３２；ＮＯ)には、ＣＮ側ＲＳＶＰ処理部６０４は、抽出したセッションＩＤと、ＰＡＴＨメッセージに含まれている情報(ＲＳＶＰソフト状態に相当する情報)とを、状態管理共通テーブル６０７内に追加する(ステップＳ７３６)。その後、ＣＮ側ＲＳＶＰ処理部６０４は、新規セッションを追加したことを状態遷移制御部６０６に通知する(ステップＳ７３７)。
【０１４３】
新規セッション追加の通知を受けとった状態遷移制御部６０６は、システムデータ格納テーブル６０８に格納されているノード種別を参照し(ステップＳ７３８)、この無線ネットワークノード２１Ａがゲートウェイノードかどうかをチェックする(ステップＳ７３９)。
【０１４４】
このとき、ノード種別がゲートウェイノードであれば(Ｓ７３９；ＹＥＳ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をマルチＲＳＶＰ状態に設定する(ステップＳ７４０)。
【０１４５】
一方、ノード種別がゲートウェイノードでなければ(Ｓ７３９；ＮＯ)、状態遷移制御部６０６は、追加されたセッションに対するノード状態をＲＡＮ側ＲＳＶＰ状態５００に設定する(ステップＳ７４１)。ステップＳ７４０又はＳ７４１の処理が終了すると、処理がステップＳ７４２に進む。
【０１４６】
ノード状態がマルチＲＳＶＰ状態であるセッションについては、上述したステップＳ７３０〜Ｓ７４３，Ｓ７４６〜Ｓ７４８までの処理から独立して、周期的にＰＡＴＨメッセージを生成しＲＡＮ側へ送信する処理が行われる。
【０１４７】
すなわち、ステップＳ７４９において、あるマルチＲＳＶＰ状態のセッションのＰＡＴＨリフレッシュタイマ(第２のタイマ)がタイムアウトになると(Ｓ７４９；ＹＥＳ)、ＣＮ側ＲＳＶＰ処理部６０４は、第２の処理部として、このセッションに対応するＲＳＶＰソフト状態を状態管理共通テーブル６０７から取得し、これを含むＰＡＴＨメッセージを生成しＲＡＮ側へ送信する(ステップＳ７５０)。その後、ステップＳ７５１にて、ＣＮ側ＲＳＶＰ処理部６０４は、タイムアウトになったＰＡＴＨリフレッシュタイマをリセットする。
【０１４８】
本実施形態では、データ送信ノード(例えばサーバ３０)からデータ受信ノード(例えば移動端末４０)へのデータフローに対する新たなセッションが追加される場合には、各無線ネットワークノード２１Ａが新規のＰＡＴＨメッセージを受信することによって、そのノードの状態の設定が行われる(Ｓ７３６〜Ｓ７４１)。このとき、ＣＮ１０からＲＡＮ２０への入口に相当する無線ネットワークノード２１Ａがゲートウェイノードに決定されるようになっている。
【０１４９】
従って、新規なセッションが追加された時点では、フロー上の複数の無線ネットワークノード２１Ａの状態は、マルチＲＳＶＰ状態５０１かＲＡＮ側ＲＳＶＰ状態５００との一方になる。その後、当該セッションの状態変化回数が少ない(例えば、移動端末４０の移動範囲が小さい等)場合に、マルチＲＳＶＰ状態５０１が下流側(移動端末４０側)へ移動する。このとき、ＣＮ側ＲＳＶＰ状態５０２の無線ネットワークノード２１Ａが出現する。
【０１５０】
なお、図８及び図９に示したように、無線ネットワークノード２１Ａが状態遷移を行うか否かの判断は、ＲＡＮ側からのリフレッシュメッセージ(ＲＥＳＶメッセージ)による予約状態の変化の回数に基づいて行われる。このため、状態管理共通テーブル６０７は、ＰＡＴＨメッセージに関する状態変化回数及び状態遷移監視タイマを持たず、ステップＳ７１４及びＳ７１５に相当する処理が行われないようになっている。ＣＮ１０の経路変化は頻繁には起こらず、ＣＮ側からの状態変化を示すＰＡＴＨメッセージが頻繁に送信されることはないものと考えられるからである。但し、状態管理共通テーブル６０７がＰＡＴＨメッセージに関する状態変化回数及び状態遷移監視タイマをさらに格納し、ＣＮ側からのＰＡＴＨメッセージについてステップＳ７１４及びＳ７１５に相当する処理が行われるようにしても良い。
【０１５１】
なお、ＣＮ側ＲＳＶＰ処理部６０４及びＲＡＮ側ＲＳＶＰ処理部６０５は、受信したリフレッシュメッセージ(ＲＥＳＶメッセージ又はＰＡＴＨメッセージ)により予約状態が変化した場合には、その予約状態に応じたリソースの予約処理を行う。また、ＲＳＶＰ処理部２２の代わりに単一のＲＳＶＰ処理部を持つノードでも、リフレッシュメッセージにより予約状態が変化した場合には、その予約状態に応じたリソースの予約処理を行う。
【０１５２】
また、図８及び図９に示す動作によると、マルチＲＳＶＰノードから送信されるＲＥＳＶメッセージは、ＣＮ側における１以上のノード(中継ノード)を介してノード３０に受信される。一方、マルチＲＳＶＰノードから送信されるＰＡＴＨメッセージは、ＲＡＮ側における１以上の無線ネットワークノード(中継ノード)を介して移動端末４０に受信される。
【０１５３】
〈状態遷移制御における動作例〉
次に、無線ネットワークノード２１Ａにおいて、ノード状態の遷移に関する処理が行われる際の処理の流れについて説明する。
【０１５４】
図７に示す状態遷移制御部６０６は、状態管理共通テーブル６０７内で管理されているセッションのうち、ノード状態がマルチＲＳＶＰ状態であるセッションについて、図１０に示すような処理を行う。図１０は、無線ネットワークノード２１Ａにおける状態遷移制御の例を示すフローチャートである。
【０１５５】
図１０において、状態遷移制御部６０６は、周期的にマルチＲＳＶＰ状態にあるセッションについて、状態変化回数を、状態変化回数上限閾値及び状態変化回数下限閾値と比較する(ステップＳ８００〜Ｓ８０３)。
【０１５６】
即ち、状態遷移制御部６０６は、状態管理共通テーブル６０７で管理しているセッションの状態遷移監視タイマがタイムアウトになると(Ｓ８００)、そのセッションＩＤに対応するノード状態を参照し、ノード状態がマルチＲＳＶＰ状態か否かを参照し、マルチＲＳＶＰ状態であれば、このセッションの状態変化回数を状態変化回数上限閾値及び状態変化回数下限閾値と夫々比較する(Ｓ８０１)。そして、状態遷移制御部６０６は、状態変化回数が上限閾値以上か否かを判定し(Ｓ８０２)、上限閾値以上でなければ(Ｓ８０２；ＮＯ)、状態変化回数が下限閾値以下か否かを判定する(Ｓ８０３)。なお、状態遷移監視タイマがタイムアウトになったセッションのノード状態がマルチＲＳＶＰ状態でない場合には、図１０に示す処理は終了する。
【０１５７】
状態変化回数が上限閾値以上でもなく(Ｓ８０２；ＮＯ)、下限閾値以下でもない場合(Ｓ８０３；ＮＯ)には、状態遷移制御部６０６は、ステップＳ８１１にて、状態管理共通テーブル６０７内の該当セッションＩＤに対応する状態変化回数を初期化する。その後、処理がステップＳ８００に戻る。
【０１５８】
状態変化回数が下限閾値以下であった場合(Ｓ８０３；ＹＥＳ)には、状態遷移制御部６０６は、状態遷移指示メッセージを生成し、このメッセージの宛先に相当する下流ノードへ送信する(ステップＳ８０４)。その後、状態遷移制御部６０６は、下流ノードからの状態遷移完了通知を所定時間待つ(ステップＳ８０５)。
【０１５９】
一方、状態変化回数が上限閾値以上であった場合には、状態遷移制御部６０６は状態遷移指示メッセージを生成し、このメッセージの宛先に相当する上流ノードへ送信する(ステップＳ８０７)。その後、状態遷移制御部６０６は、上流ノードからの状態遷移完了通知を所定時間待つ(ステップＳ８０８)。
【０１６０】
状態遷移制御部６０６は、ステップＳ８０５において下流ノードからの状態遷移完了通知を所定時間内に受信しなかった場合(Ｓ８０５；ＮＯ)、および、ステップＳ８０８において上流ノードからの状態遷移完了通知を受信しなかった場合(Ｓ８０８；ＮＯ)には、状態管理テーブル６０７内の該当セッションＩＤに対する状態変化回数を初期化し(ステップＳ８１１)、処理をステップＳ８００に戻す。
【０１６１】
一方、状態遷移制御部６０６は、状態遷移完了通知を所定時間内に下流ノードから受信した場合(Ｓ８０５；ＹＥＳ)には、状態管理共通テーブル６０７内の該当セッションＩＤに対するノード状態をＣＮ側ＲＳＶＰ状態に更新する(ステップＳ８０６)。これによって、当該セッションに対する無線ネットワークノード２１Ａの状態がマルチＲＳＶＰ状態からＣＮ側ＲＳＶＰ状態に遷移する。
【０１６２】
同様に、状態遷移制御部６０６は、状態遷移完了通知を所定時間内に上流ノードから受信した場合(Ｓ８０８；ＹＥＳ)には、状態管理共通テーブル６０７内の該当セッションＩＤに対するノード状態をＲＡＮ側ＲＳＶＰ状態に更新する(ステップＳ８０９)。これによって、当該セッションに対する無線ネットワークノード２１Ａの状態がマルチＲＳＶＰ状態からＲＡＮ側ＲＳＶＰ状態に遷移する。
【０１６３】
その後、状態遷移制御部６０６は、状態管理共通テーブル６０７内の該当セッションＩＤに対するＰＡＴＨリフレッシュタイマ及びＲＥＳＶリフレッシュタイマを初期化(リセット)する(ステップＳ８１０)。続いて、状態遷移制御部６０６は、状態管理共通テーブル６０７内の該当セッションＩＤに対応する状態変化回数を初期化(リセット)する(ステップＳ８１１)。
【０１６４】
なお、上述した動作では、状態遷移制御部６０６は、状態遷移監視タイマ値を単位時間とし、この単位時間内における予約状態の変化回数(状態変化回数)に基づいて無線ネットワークノード２１Ａの状態遷移についての判定を行っている。これに代えて、無線ネットワークノード２１Ａの状態遷移についての判定が、通信(フロー)確立時からのＲＡＮ側の状態変化の積算回数を用いて行われるようにしてもよい。
【０１６５】
〈状態遷移メッセージ受信による動作例〉
次に、無線ネットワークノード２１Ａが、ステップＳ８０４又はＳ８０７で送信された状態遷移指示メッセージを受信した際の動作について説明する。状態遷移指示メッセージは、ＲＳＶＰメッセージの一つとして送信され、宛先に相当する無線ネットワークノード２１Ａの外線インターフェイス部６０３で受信され、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５に渡される。
【０１６６】
図１１は、無線ネットワークノード２１Ａによる状態遷移指示メッセージ受信時の処理フローの例を示す図である。ステップＳ９００において、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５は、ＲＳＶＰメッセージを受信すると、このＲＳＶＰメッセージが状態遷移指示メッセージかどうかを判定する(ステップＳ９０１)。
【０１６７】
このとき、ＲＳＶＰメッセージが状態遷移指示メッセージでない場合(Ｓ９０１；ＮＯ)には、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５は、図７又は図８に示したような通常のＲＳＶＰメッセージに対する処理を行う(ステップＳ９０２)。
【０１６８】
これに対し、ＲＳＶＰメッセージが状態遷移指示メッセージであった場合(Ｓ９０１；ＹＥＳ)には、ＲＳＶＰ処理部は、状態遷移制御部６０６に状態遷移指示メッセージを転送する(ステップＳ９０３)。
【０１６９】
状態遷移制御部６０６は、ＣＮ側ＲＳＶＰ処理部６０４又はＲＡＮ側ＲＳＶＰ処理部６０５から転送された状態遷移指示メッセージを受け取ると、この状態遷移指示メッセージから送信元ＩＰアドレスとセッションＩＤを抽出する(ステップＳ９０４)。
【０１７０】
次に、状態遷移制御部６０６は、状態管理共通テーブル６０７から抽出したセッションＩＤと同じセッションＩＤを持つエントリを検出し、このエントリのセッションＩＤに対応するノード状態をマルチＲＳＶＰ状態に設定する(ステップＳ９０５)。
【０１７１】
次に、状態遷移制御部６０６は検出したエントリの状態遷移監視タイマ，状態変化回数，ＰＡＴＨリフレッシュタイマ及びＲＥＳＶリフレッシュタイマを初期化(リセット)する(ステップＳ９０６)。
【０１７２】
そして、状態遷移制御部６０６は、ステップＳ９０４で抽出したＩＰアドレスを宛先として、状態遷移完了通知メッセージを返信する(ステップＳ９０７)。
【０１７３】
〈状態遷移指示／完了通知メッセージ〉
次に、図１０及び１１に示した動作において送受信される状態遷移指示メッセージ及び状態遷移完了通知メッセージ(状態遷移指示／完了通知メッセージ)について説明する。これらのメッセージは、本発明において導入されるものであるため、新しく定義する必要がある。この際、送信元アドレス、送信先(宛先)アドレス、メッセージ識別子、制御対象となるフロー（セッション）の４つの情報が最低でも必要となる。
【０１７４】
図１２に、ＩＰｖ６パケットを使用した状態遷移指示／完了通知メッセージの一例を示す。図１２では、状態遷移指示／完了通知メッセージのフォーマットとしてＲＳＶＰメッセージに準じたものを使用している。すなわち、状態遷移指示／完了通知メッセージは、ＩＰｖ６ヘッダ、ＲＳＶＰ共通ヘッダ、ＲＳＶＰオブジェクトから構成される。
【０１７５】
状態遷移指示メッセージにおいて、ＩＰｖ６ヘッダ内の送信元アドレスには、状態遷移指示メッセ−ジを生成・送信する無線ネットワークノード２１ＡのＩＰアドレスが格納される。
【０１７６】
また、送信先アドレスには、下流ノード又は上流ノードに相当する無線ネットワークノード２１ＡのＩＰアドレスが格納される。ＩＰアドレスとして、状態管理共通テーブル６０７の該当するセッションに対応するＲＳＶＰソフト状態に格納されているネクスト・ホップ・アドレス(Next Hop Address)又はプレビアス・ホップ・アドレス(Previous Hop Address)が用いられる。
【０１７７】
具体的には、状態遷移制御部６０６は、上流ノードへ状態遷移指示メッセージを送信する場合には、プレビアス・ホップ・アドレスを送信先アドレスとして用いる。一方、状態遷移制御部６０６は、下流ノードへ状態遷移指示メッセージを送信する場合には、ネクスト・ホップ・アドレスを送信先アドレスとして用いる。
【０１７８】
また、状態遷移指示メッセージ又は状態遷移応答メッセージであることを識別するため、ＲＳＶＰ共通ヘッダ内のＲＳＶＰタイプが使用される。具体的には、ＲＳＶＰタイプ領域に対応する状態遷移指示メッセージ及び状態遷移完了通知メッセージの２つ分のメッセージタイプが定義され、送信対象のメッセージに応じたメッセージタイプがＲＳＶＰタイプ領域に格納される。
【０１７９】
そして、状態遷移の対象となるセッションを指定するため、ＲＳＶＰオブジェクトとしてセッションオブジェクトが利用される。
【０１８０】
〔実施形態の作用〕
本発明の実施形態によると、ＲＳＶＰに基づくリソースの予約状態のリフレッシュ動作が、所定の無線ネットワークノード２１Ａを境とするコアネットワーク側(ＣＮ側)と移動通信ネットワーク側(ＲＡＮ側)とで独立して行われる。
【０１８１】
これによって、トポロジーの変更すなわち状態変化の少ないＣＮ側では、リフレッシュ周期をＲＡＮ側よりも長く設定することによって、ネットワークリソースの浪費を最小限に抑えることができる。一方、移動端末４０の移動に伴う状態変化が頻繁に起こることが想定されるＲＡＮ側では、リフレッシュ周期をＣＮ側よりも短くすることで、リソースの予約状態を常に移動端末４０の動きに追随させることができ、所望の通信品質(ＱｏＳ)を確保することが可能となる。
【０１８２】
さらに、本発明の実施形態によると、フローに対するＲＳＶＰ処理を二重化させるポイント(境界ノード；マルチＲＳＶＰノード)を移動端末４０の状態によってダイナミックに(動的に)変更することができる。
【０１８３】
即ち、移動端末４０の移動範囲が広範囲に渡る場合(マルチＲＳＶＰノードが頻繁に予約状態の変化を示すＲＥＳＶメッセージを受信する場合)には、フローに対するＲＳＶＰの二重化ポイント(マルチＲＳＶＰノード)をＣＮ１０近い側へ移行させる。一方、移動端末４０の移動範囲がそれほど広くない場合(マルチＲＳＶＰノードが予約状態の変化を示すＲＥＳＶメッセージを殆ど受信しない場合)には、移動端末４０に近い側にＲＳＶＰの二重化ポイント(マルチＲＳＶＰノード)を移行させる。
【０１８４】
即ち、移動通信網(ＲＡＮ)は、移動端末４０の状態(位置変化等)に応じて、最も適切な二重化ポイント(マルチＲＳＶＰノード)を自動的に判別し、無線ネットワークノード２１Ａの状態を遷移させていくのである。これにより、通信の品質を最大限確保しながらも、ネットワークリソースの消費量を最小限に抑えることができる。
【０１８５】
以上の機能により、移動端末４０のユーザは常に最適に予約されたリソースを使用することで品質の高い大容量通信サービスの提供を受けることができる。一方、ネットワークリソースの浪費を抑えることにより、このような大容量通信サービスを実現するためのインフラ設備も最低限の規模及びコストで構築可能となる。
【０１８６】
〔その他〕
上述した実施形態は、以下の発明を開示する。
（付記１）リソース予約プロトコルを実装したコアネットワークに接続される移動通信ネットワークと、
前記移動通信ネットワークに含まれる複数の無線ネットワークノードと、
前記コアネットワーク及び前記移動通信ネットワークを通過するデータ送信ノードとデータ受信ノードとの間のデータのフローに対するネットワークリソースをリソース予約プロトコルに基づいて予約する手段と、
前記フローに係るネットワークリソースの予約状態をリフレッシュする領域を前記フローが通過する所定の無線ネットワークノードを境としてコアネットワーク側と移動通信ネットワーク側とに分割し、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの頻度よりも高い頻度で行うリフレッシュ制御手段と、
を含むＲＳＶＰを用いた移動通信システム。（１）
（付記２）前記リフレッシュ制御手段は、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの周期よりも短い周期で行う、付記１記載のＲＳＶＰを用いた移動通信システム。（２）
（付記３）前記フローに対する前記移動通信ネットワークの状態の変化に応じて、前記境界となる無線ネットワークノードとしての境界ノードを変更する境界ノード変更手段をさらに含む、付記１記載のＲＳＶＰを用いた移動通信システム。（３）
（付記４）前記境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が上限値を上回った場合に、現在の境界ノードよりもコアネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、付記３記載のＲＳＶＰを用いた移動通信システム。（４）
（付記５）前記境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が下限値を下回った場合に、現在の境界ノードよりも移動通信ネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、付記３記載のＲＳＶＰを用いた移動通信システム。（５）
（付記６）前記リフレッシュ制御手段は、前記コアネットワーク側と前記移動通信ネットワーク側との境となる無線ネットワークノードに設けられた状態記憶部とＲＳＶＰ処理部とを含み、
前記状態記憶部は、少なくとも前記フローに対する前記移動通信ネットワーク側のネットワークリソースの予約状態を格納し、
前記ＲＳＶＰ処理部は、前記移動通信ネットワーク側からネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを受信し、このリフレッシュメッセージに含まれたネットワークリソースの予約状態が前記状態記憶部に格納されている予約状態からの変化を示さない場合には、このリフレッシュメッセージの転送を停止する、付記１記載のＲＳＶＰを用いた移動通信システム。
（付記７）前記ＲＳＶＰ処理部は、前記移動通信ネットワーク側から受信したリフレッシュメッセージに含まれたネットワークリソースの予約状態が前記状態記憶部に格納されている予約状態からの変化を示す場合には、この予約状態で前記状態記憶部に格納された予約状態を更新し、この予約状態を含む前記コアネットワーク側のネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを生成し、前記コアネットワーク側へ送信する、付記６記載のＲＳＶＰを用いた移動通信システム。
（付記８）前記リフレッシュ制御手段は、
第１の時間を計時する第１のタイマと、
第１の時間よりも短い第２の時間を計時する第２のタイマと、
前記第１のタイマが第１の時間を計時する毎に、前記コアネットワーク側のネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを生成して前記コアネットワーク側へ送信する第１の処理部と、
前記第１の処理部から独立して、前記第２のタイマが第２の時間を計時する毎に、前記移動通信ネットワーク側のネットワークリソースの予約状態をリフレッシュするためのリフレッシュメッセージを生成して前記移動通信ネットワーク側へ送信する第２の処理部とを含む、付記１記載のＲＳＶＰを用いた移動通信システム。
（付記９）前記コアネットワーク側と前記移動通信ネットワーク側との境となる無線ネットワークノードは、状態監視部と、所定の時間を計時する状態監視タイマと、前記状態監視タイマが所定の時間を計時する間に前記移動通信ネットワーク側から受信された複数のリフレッシュメッセージによる予約状態の変化回数を記憶する状態変化回数記憶部と、変化回数の閾値を記憶する閾値記憶部とをさらに含み、
前記状態監視部は、前記状態監視タイマが所定の時間を計時する毎に、前記状態変化回数記憶部に記憶された変化回数が前記閾値記憶部に記憶された閾値を上回っているか否かを判定し、変化回数が閾値を上回っている場合には、この無線ネットワークノードのコアネットワーク側に存する他の無線ネットワークノードに、この無線ネットワークノードの代わりに前記境となることを指示するメッセージを発行し送信する、付記７記載のＲＳＶＰを用いた移動通信システム。
（付記１０）前記コアネットワーク側と前記移動通信ネットワーク側との境となる無線ネットワークノードは、状態監視部と、所定の時間を計時する状態監視タイマと、前記状態監視タイマが所定の時間を計時する間に前記移動通信ネットワーク側から受信された複数のリフレッシュメッセージによる予約状態の変化回数を記憶する状態変化回数記憶部と、変化回数の閾値を記憶する閾値記憶部とをさらに含み、
前記状態監視部は、前記状態監視タイマが所定の時間を計時する毎に、前記状態変化回数記憶部に記憶された変化回数が前記閾値記憶部に記憶された閾値を下回っているか否かを判定し、変化回数が閾値を下回っている場合には、この無線ネットワークノードの移動通信ネットワーク側に存する他の無線ネットワークノードに、この無線ネットワークノードの代わりに前記境となることを指示するメッセージを発行し送信する、付記７記載のＲＳＶＰを用いた移動通信システム。
【０１８７】
【本発明の効果】
本発明によれば、ネットワークリソースの予約状態をネットワークの状態変化に柔軟に追随させることができる一方で、ネットワークリソースの有効利用を図ることができる。
【図面の簡単な説明】
【図１】図１は、移動通信システムにＲＳＶＰを用いることを想定した場合の例を示す図である。
【図２】図２は、図１に示したようなシステムにおけるＲＳＶＰ処理イメージを示す図である。
【図３】図３は、従来の方式に基づいたＲＳＶＰネットワークを示す図である。
【図４】図４は、本発明による移動通信システムの実施形態を示す図である。
【図５】図５は、移動通信システムに適したＲＳＶＰネットワークを示す図である。
【図６】図６は、無線ネットワークノードの状態遷移を示す図である。
【図７】図７は、無線ネットワークノードの一実施形態を示す図である。
【図８】図８は、無線ネットワークノードによるＲＥＳＶメッセージの処理フローの例を示す図である。
【図９】図９は、無線ネットワークノードによるＰＡＴＨメッセージの処理フローの例を示す図である。
【図１０】図１０は、無線ネットワークノードにおける状態遷移制御の処理フローの例を示す図である。
【図１１】図１１は、無線ネットワークノードによる状態遷移指示メッセージ受信時の処理フローの例を示す図である。
【図１２】図１２は、ＩＰｖ６パケットを使用した状態遷移指示／応答メッセージフォーマットの一例を示す図である。
【符号の説明】
１０ コアネットワーク(ＣＮ)
２０ 無線アクセスネットワーク(ＲＡＮ)
２１，２１Ａ 無線ネットワークノード
３０ データ送信／受信ノード
４０ 移動端末
２２ 二重化ＲＳＶＰ処理部
６０４ ＣＮ側ＲＳＶＰ処理部
６０５ ＲＡＮ側ＲＳＶＰ処理部
６０６ 状態遷移制御部
６０７ 状態管理共通テーブル
６０８ システムデータ格納テーブル
Claims (5)
- リソース予約プロトコルを実装したコアネットワークに接続される移動通信ネットワークと、
前記移動通信ネットワークに含まれる複数の無線ネットワークノードと、
前記コアネットワーク及び前記移動通信ネットワークを通過するデータ送信ノードとデータ受信ノードとの間のデータのフローに対するネットワークリソースをリソース予約プロトコルに基づいて予約する手段と、
前記フローに係るネットワークリソースの予約状態をリフレッシュする領域を前記フローが通過する所定の無線ネットワークノードを境としてコアネットワーク側と移動通信ネットワーク側とに分割し、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの頻度よりも高い頻度で行うリフレッシュ制御手段と、
を含むＲＳＶＰを用いた移動通信システム。 - 前記リフレッシュ制御手段は、前記移動通信ネットワーク側に対するリフレッシュを前記コアネットワーク側に対するリフレッシュの周期よりも短い周期で行う、請求項１記載のＲＳＶＰを用いた移動通信システム。
- 前記フローに対する前記移動通信ネットワークの状態の変化に応じて、前記境界となる無線ネットワークノードとしての境界ノードを変更する境界ノード変更手段をさらに含む、請求項１記載のＲＳＶＰを用いた移動通信システム。
- 前記境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が上限値を上回った場合に、現在の境界ノードよりもコアネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、請求項３記載のＲＳＶＰを用いた移動通信システム。
- 前記境界ノード変更手段は、現在の境界ノードが所定時間内に得た前記移動通信ネットワーク側におけるネットワークリソースの予約状態の変化の回数が下限値を下回った場合に、現在の境界ノードよりも移動通信ネットワーク側に存する他の無線ネットワークノードを境界ノードに変更する、請求項３記載のＲＳＶＰを用いた移動通信システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002144883A JP3880451B2 (ja) | 2002-05-20 | 2002-05-20 | Ｒｓｖｐを用いた移動通信システム |
| US10/301,054 US7499436B2 (en) | 2002-05-20 | 2002-11-21 | Mobile communication system using resource reservation protocol |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002144883A JP3880451B2 (ja) | 2002-05-20 | 2002-05-20 | Ｒｓｖｐを用いた移動通信システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003338839A JP2003338839A (ja) | 2003-11-28 |
| JP3880451B2 true JP3880451B2 (ja) | 2007-02-14 |
Family
ID=29417088
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002144883A Expired - Fee Related JP3880451B2 (ja) | 2002-05-20 | 2002-05-20 | Ｒｓｖｐを用いた移動通信システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7499436B2 (ja) |
| JP (1) | JP3880451B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7792119B2 (en) * | 2000-05-22 | 2010-09-07 | Telefonaktiebolaget L M Ericsson (Publ) | Method for a connection through a core network |
| US20050180426A1 (en) * | 2004-02-18 | 2005-08-18 | Yoshifumi Sakata | Network resource-reserving apparatus and method |
| US8000248B2 (en) * | 2004-10-14 | 2011-08-16 | Telefonaktiebolaget L M Ericsson (Publ) | Router and method for refreshing quality of service reservation |
| KR101265954B1 (ko) * | 2005-07-11 | 2013-05-23 | 더 트러스티이스 오브 콜롬비아 유니버시티 인 더 시티 오브 뉴욕 | 아이피 터널링 경로 상의 터널 시그널링을 수행하는 방법및 장치 |
| US20080161941A1 (en) * | 2006-12-29 | 2008-07-03 | Motorola, Inc. | Graph-theoretic technique of analyzing and optimizing policy deployment |
| TW201002003A (en) * | 2008-05-05 | 2010-01-01 | Koninkl Philips Electronics Nv | Methods and devices for managing a network |
| JP2010028777A (ja) * | 2008-07-24 | 2010-02-04 | Fujitsu Ltd | リソース予約方法およびリソース予約装置 |
| US8675371B2 (en) * | 2009-08-07 | 2014-03-18 | Advanced Processor Architectures, Llc | Distributed computing |
| US11042211B2 (en) | 2009-08-07 | 2021-06-22 | Advanced Processor Architectures, Llc | Serially connected computing nodes in a distributed computing system |
| US9645603B1 (en) | 2013-09-12 | 2017-05-09 | Advanced Processor Architectures, Llc | System clock distribution in a distributed computing environment |
| US9429983B1 (en) | 2013-09-12 | 2016-08-30 | Advanced Processor Architectures, Llc | System clock distribution in a distributed computing environment |
| US9432321B2 (en) * | 2011-12-19 | 2016-08-30 | Alcatel Lucent | Method and apparatus for messaging in the cloud |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH11103303A (ja) | 1997-09-26 | 1999-04-13 | Sony Corp | ネットワーク資源予約制御方法および装置、受信端末、送信端末、並びに中継装置 |
| NL1008767C2 (nl) * | 1998-03-31 | 1999-10-01 | Regiplan B V | Simulatie-inrichting voor het simuleren van beelden van ten minste één bouwwerk. |
| GB2341059A (en) * | 1998-08-28 | 2000-03-01 | Nokia Oy Ab | Internet protocol flow detection |
| FI108389B (fi) * | 1999-04-15 | 2002-01-15 | Sonera Smarttrust Oy | Tilaajaidentiteettimoduulin hallinta |
| US6570851B1 (en) * | 1999-07-01 | 2003-05-27 | Nokia Telecommunications Oy | Receiver driven differentiated service marking for unicast and multicast applications |
| JP3636948B2 (ja) | 1999-10-05 | 2005-04-06 | 株式会社日立製作所 | ネットワークシステム |
| US6714987B1 (en) * | 1999-11-05 | 2004-03-30 | Nortel Networks Limited | Architecture for an IP centric distributed network |
| US20010027490A1 (en) * | 2000-01-25 | 2001-10-04 | Gabor Fodor | RSVP handling in 3G networks |
| JP2001224070A (ja) | 2000-02-09 | 2001-08-17 | Fujitsu Ltd | モバイル通信システム及びその方法 |
| US6654610B1 (en) * | 2000-05-05 | 2003-11-25 | Lucent Technologies Inc. | Two-way packet data protocol methods and apparatus for a mobile telecommunication system |
| US20020087699A1 (en) * | 2000-07-31 | 2002-07-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic QoS management in differentiated services using bandwidth brokers, RSVP aggregation and load control protocols |
| US7870196B2 (en) * | 2000-11-08 | 2011-01-11 | Nokia Corporation | System and methods for using an application layer control protocol transporting spatial location information pertaining to devices connected to wired and wireless internet protocol networks |
| GB0028029D0 (en) * | 2000-11-17 | 2001-01-03 | Koninkl Philips Electronics Nv | Method and related system and appartus for providing travel-related information to a mobile communications device |
| US7082116B2 (en) * | 2000-12-28 | 2006-07-25 | Nortel Networks Limited | Methods and systems implementing mobility support in a packet-based wireless access network |
| US20020147717A1 (en) * | 2001-01-26 | 2002-10-10 | Barros Mark Alexander | Communication device, system, method, and computer program product for sorting data based on proximity |
| US20020162106A1 (en) * | 2001-04-30 | 2002-10-31 | Pickover Clifford Alan | Method and system for information insertion |
| US7287070B2 (en) * | 2001-05-25 | 2007-10-23 | Interdigital Technology Corporation | Determining control of an internet communication between a sender and receiver |
| US7027400B2 (en) * | 2001-06-26 | 2006-04-11 | Flarion Technologies, Inc. | Messages and control methods for controlling resource allocation and flow admission control in a mobile communications system |
| US20030074443A1 (en) * | 2001-10-15 | 2003-04-17 | Makonnen Melaku | Last mile quality of service broker (LMQB) for multiple access networks |
| AU2003217301A1 (en) * | 2002-02-04 | 2003-09-02 | Flarion Technologies, Inc. | A method for extending mobile ip and aaa to enable integrated support for local access and roaming access connectivity |
| US7277455B2 (en) * | 2002-06-10 | 2007-10-02 | Qualcomm Incorporated | Packet flow processing in a communication system |
-
2002
- 2002-05-20 JP JP2002144883A patent/JP3880451B2/ja not_active Expired - Fee Related
- 2002-11-21 US US10/301,054 patent/US7499436B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003338839A (ja) | 2003-11-28 |
| US20030214910A1 (en) | 2003-11-20 |
| US7499436B2 (en) | 2009-03-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3743521B2 (ja) | パケット通信網 | |
| Lee et al. | INSIGNIA: An IP-based quality of service framework for mobile ad hoc networks | |
| US7693093B2 (en) | QoS-aware handover procedure for IP-based mobile ad-hoc network environments | |
| JP5053390B2 (ja) | 無線通信システムにおけるストリーミングメディアサービスのためのプロキシベースのシグナリングアーキテクチャ | |
| US7289453B2 (en) | Adaptive quality-of-service reservation and pre-allocation for mobile systems | |
| Koodli et al. | Fast handovers and context transfers in mobile networks | |
| JP3202928B2 (ja) | 通信ネットワークにおいて呼びを確立するシステム | |
| US8711818B2 (en) | High performance data transport system and method | |
| AU2004307494B2 (en) | Bidirectional QoS reservation within an in-band signaling mechanism | |
| US7430609B2 (en) | Managing access to streams hosted on duplicating switches | |
| JP3880451B2 (ja) | Ｒｓｖｐを用いた移動通信システム | |
| US20030067941A1 (en) | Precedence-based routing/re-routing | |
| EP2395700B1 (en) | Managing access to stream hosted on duplicating switches | |
| JP4880775B2 (ja) | 通信ベアラに関する装置及び方法 | |
| WO2005079024A1 (ja) | データ通信ネットワークにおけるシグナリング管理 | |
| WO2015070383A1 (zh) | 一种链路聚合的方法、装置和系统 | |
| JPWO2003009533A1 (ja) | インタフェース装置及びその制御方法 | |
| EP1780973A1 (en) | Method and apparatus for session setup in dynamic networks | |
| JP3614744B2 (ja) | ＩＰ通信をサポートする異なるネットワーク内の端末間にＱｏＳセッションを構築する方法 | |
| JP4630298B2 (ja) | 機能分散型通信装置、構成要素結合制御方法、およびプログラム | |
| Curran et al. | A framework for the transmission of streaming media to mobile devices | |
| Pei et al. | Distributed flow admission control for multimedia services over wireless ad hoc networks | |
| KR100484495B1 (ko) | 모바일 ｉｐ망에서의 자원 예약 기능을 구비한 단말장치,자원 예약 장치 및 방법 | |
| JP2004164494A (ja) | プログラム配置方法およびその方法を利用可能なパケット転送装置ならびに端末装置 | |
| Curran | Minimizing the Handoff Latency in Ad-Hoc Networks When Streaming Media to Mobile Devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050512 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061013 |
|
| 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: 20061024 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061107 |
|
| 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: 20101117 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101117 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111117 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111117 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121117 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121117 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131117 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |