通信システム、リソース管理装置、リソース管理方法、通信管理装置並び に通信管理方法
技術分野
[0001] 本発明は、通信システム、リソース管理装置、リソース管理方法、通信管理装置並 びに通信管理方法に関し、特に、パケット伝送が行われる通信ネットワークにおける 通信システム、リソース管理装置、リソース管理方法、通信管理装置並びに通信管理 方法に関する。
背景技術
[0002] 移動端末力 無線ネットワークを通じてインターネットなどの通信ネットワークにァク セスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提 供できる技術として、次世代インターネットプロトコルであるモパイル IP (Internet Prot ocol)を利用したものが普及してきている。
[0003] 一方、ネットワークを利用した通信にぉ 、ては、 QoS (Quality of Service)保証を始 めとしたサービス (本明細書では、こうしたサービスを付カ卩的サービスと呼ぶことにす る)が存在しており、こうした付カ卩的サービスを実現するための様々な通信プロトコル が存在している。このような様々な通信プロトコルのうち、 QoS保証をするためのプロ トコルとして、例えば、 RSVP (Resource Reservation Protocol)が挙げられる(例えば 、下記の非特許文献 1参照)。 RSVPは、データの送信を行う送信側通信端末からデ ータの受信を行う受信側通信端末への経路 (フロー)上における帯域予約を行うこと によって、送信側通信端末から受信側通信端末に、データ力スムーズに伝送される ようにするものである。
[0004] サブネット(サブネットワーク)間のハンドオーバを行う MN (Mobile Node:モバイルノ ード)に関しては、ハンドオーバ前に受けていた QoS保証を始めとする付カ卩的サービ スを、ハンドオーバ後においても継続して受けられるべきであるという要請があるが、 上述した RSVPは、 MNの移動に対して十分には対応して!/、な!/、と!/、う問題がある。
[0005] この問題を解決するために、現在、 IETF (Internet Engineering Task Force)にお
いて、 NSIS (Next Step in Signaling)と呼ばれる新しいプロトコルを標準化するための 議論が行われている(下記の非特許文献 2参照)。この NSISは、モパイル環境にお Vヽて、 QoS保証を始めとする様々な付カ卩的サービスに特に有効であると期待されて おり、 NSISにおいて QoS保証やモビリティサポートを実現するための要件や実現方 法などが記載された文献も存在する(例えば、下記の非特許文献 3〜7参照)。以下 に、現在 IETFの NSISワーキンググループでドラフト仕様となって!/、る NSISの概要 と、 QoS経路確立の方法を説明する (非特許文献 4及び非特許文献 7参照)。
[0006] 図 10には、従来の技術における NSISのプロトコル構成を説明するために、 NSIS 及びその下位層のプロトコルスタックが図示されている。 NSISプロトコル層は IP及び 下位層のすぐ上に位置する。さらに NSISプロトコル層は、それぞれの付加的サービ スを提供するためのシグナリングメッセージ生成、及びその処理を行うプロトコルであ る NSLP (NSIS Signaling Layer Protocol)と、 NSLPのシグナリングメッセージのルー ティングを行う NTLP (NSIS Transport Layer Protocol)の 2層からなる。 NSLP〖こは、 QoSのための NSLP (QoS NSLP)や、その他のある付カ卩的サービス(サービス A やサービス B)のための NSLP (サービス Aの NSLP、サービス Bの NSLP)など、様々 な NSLPが存在している。
[0007] また、図 11は、従来の技術における NSISのノードである NEや QNE力 ^隣り合う」と いう概念を説明するための模式図である。図 11に示すように、 NSIS機能を持ったす ベてのノード(NE : NSIS Entity)には、少なくとも NTLPが実装されている。この NTL Pの上には、 NSLPが必ずしも存在しなくてもよぐまた、 1つ以上の NSLPが存在し てもよい。なお、ここでは、特に、 QoSのための NSLPを持った NEを QNE (QoS NSI S Entity)と呼ぶことにする。なお、 NEになり得るのは端末やルータである。また、隣り 合う NEの間には、 NEではない複数のルータが存在することもあり得るし、隣り合う Q NEの間には、 NEではないルータ及び QoS NSLPを持たない NEが複数存在する ことちあり得る。
[0008] なお、 NSISは、モパイル環境だけでなく通常の静的なネットワークにおける様々な 機能も網羅するものである力 本明細書では、 NSISの機能の 1つであるモビリティサ ポートされた付カ卩的サービスの確立を実現する機能に着目し、 NSISの実装によって
、モビリティサポートされた付カ卩的サービスの確立が実現されるものとする。
[0009] また、 MNが新たなサブネットワーク(以下、サブネットと呼ぶ)に移動する場合、新 たな QoS経路力 MNと CN (Correspondent Node:通信相手ノード)との間で確立さ れる必要がある。新たな QoS経路が確立されるまでは、データパケットは必要な QoS 処理を受けられず、 QoSの中断が起こることになる。この QoSの中断は、スムーズか つシームレスなモビリティが実現されるように、最低限に抑えられる必要がある。
[0010] こうした問題を扱う 1つの方法として、下記の非特許文献 8には、 MRSVPが提示さ れている。この非特許文献 8では、 RSVPに変更をカ卩えることによって、モパイル IPの 三角ルート用の QoS経路をあら力じめ確立する方法が提案されている。ここでは、「口 一カルプロキシエージェント(HA (Home Agent:ホームエージェント)に相当する)」及 び「リモートプロキシエージェント(FA (Foreign Agent :フォーリンエージェント)に相当 する)」力 MNのための QoS経路を確立することが可能である。
[0011] リモートプロキシエージェントは、 MNの NCoA(New Care- of Address:新たな気付 アドレス)取得した後に、自身と CNとの間に QoS経路のセットアップを行う。続いて、 リモートプロキシエージェントとローカルプロキシエージェントとの間(すなわち、 FAと HAとの間)の経路が新たに確立されて、この経路と、ローカルプロキシエージェントと CNとの間(すなわち、 FAと CNとの間)の経路とが併合される。なお、経路の併合の 具体的な方法に関しては説明されていない。
[0012] また、 MNがサブネット間においてハンドオーバを行う場合、ハンドオーバ前の古い 経路の一部とハンドオーバ後の新 、経路の一部とが重複する場合がある。このよう な場合には、重複経路における 2重予約の問題や、経路の変更が困難であることな ど、様々な問題が起こり得る。こうした問題を解く方法の 1つとして、古い経路と新しい 経路とが分岐 (クロスオーバ)する位置を特定する方法が挙げられる。この分岐点上 に存在する通信ノードは CRN (Crossover Node :クロスオーバノード)と呼ばれ、この CRNを特定する方法としては、例えば、下記の非特許文献 9、 10などに記載されて いる方法が知られている。
[0013] なお、本明細書に記載されて 、る QoS経路の確立とは、 QoSが保証されるデータ パケットが通る経路であって、 NTLP層にお!/ヽてシダナリングメッセージをルーティン
グするためのステートが確立されており、かつ NSLP層によって QoS保証のためのリ ソース予約手続きが完了した状態のことを指す。なお、 QoS保証のためのリソース予 約と、 NTLP層のルーティングのためのステートの確立は、同時に行われる場合もあ るし、また、ルーティングのためのステートの確立の後に、 QoS保証のためのリソース 予約が行われる場合もある。
[0014] また、下記の非特許文献 11Aによれば、シグナリングメッセージのルーティングのた めのステートは、 NSISの最初のメッセージが、 downstream方向(データパケットが送 られる方向)に対して送られる際に確立される。すなわち、あるセッションに対するデ ータパケットに対して QoS保証が行われる場合、データパケットが通過する最初の Q NEは、 QoS予約のためのシグナリングメッセージ、又はその準備のためのシグナリン グメッセージを、データパケットの受信者に向けて送信する。このとき、このシグナリン グメッセージの NTLP層に、セッションを識別するセッション IDやフローを識別するフ ロー IDなどの情報が付けられるほかに、 IP層には RAO(Router Alert Option)が付け られる。そして、このシグナリングメッセージが通過しょうとする QNEの IP層において 、 RAOの存在によりこのシグナリングメッセージはインタセプトされて、 NSIS層(NTL P層及び NSLP層)に渡され、 NSIS層によって、シグナリングメッセージの中身が確 認されるようになる。
[0015] シグナリングメッセージをインタセプトした QNEの NTLP層では、まず、ルーティン グのためのステートとして、フロー IDやセッション IDの情報、及び、このシグナリングメ ッセージが送信されてきた 1つ前の隣り合う QNEの IPアドレスの情報を格納する。そ して、 1つ前の隣り合う QNEに対して、 NTLPレベルでの返信メッセージを返す。これ により、 1つ前の QNEの NTLP層は、 1つ後ろの QNEの IPアドレスを知ることができ 、この IPアドレスをルーティングのためのステートに書き込むことによって保持する。ま た、シグナリングメッセージの送受信をセキュアに行いたい場合などには、このほかに 、メッセージアソシエーションなどの手順を行い、セキュリティに関するネゴシエーショ ンなどを行う。
[0016] 一方、 NSLP側では、 NSLPメッセージの中身に応じた処理を行い、この処理が済 むと再び NTLPにより、シグナリングメッセージがあて先(ここでは、データパケットの
受信者)に向けて転送される。
[0017] こうして、このシグナリングメッセージが所定のあて先に到達することにより、 NTLP 層にはメッセージのルーティングのためのステートに係る情報が確立される。特に、メ ッセージアソシエーションが確立された場合には、以後の該当セッション ID、フロー I Dを持つシグナリングメッセージに関しては、 RAOを用いることなぐ上述のように確 立されたルーティングのためのステートを用いて送受信される。
[0018] また、 NAT (Network Address Translation:ネットワークアドレス変換)や FW (Firewa 11:ファイアウォール)におけるポリシールールを動的に作成するため、 NSISでは NS LP層の機能の 1つとして、 NATFW NSLP (下記の非特許文献 13参照)が提案さ れている。
[0019] なお、 NATとは、 LAN (Local Area Network)内のみで使われるプライベートァドレ ス情報と、インターネット上で使われるグローバルアドレス情報の変換を行う技術であ る。なお、アドレス情報には IPアドレスのほかに、 IPアドレスとポート番号の組み合わ せなども用いられる。どのプライベートアドレス情報と、どのグローバルアドレス情報と を対応させるかという変換情報は、ポリシールールという形で NAT対応ノード内に保 有される。また、 FWとは、 LAN内に通すパケット、又は LAN内力も LAN外(例えば 、インターネット)に送出するパケットをフィルタリングする技術である。なお、フィルタリ ングには、 IPアドレスやポート番号などが用いられる。このフィルタリング情報は、ポリ シールールという形で FW対応ノード内に保有される。また、 NAT及び FWの両方の 機能が 1つのノードに実装される場合も多い。本明細書では、 NAT及び FWの両方 の機能を NATFWと呼び、 NAT及び FWの両方の機能を有するノードを NATFWノ ードと呼ぶ。
[0020] NATFW NSLPの基本動作は、以下の通りである。
(1)データ送信者である NATFW NSLP対応ノードが,データ受信者である NATF W NSLP対応ノードに対して、 CREATEメッセージを送信する。
(2)経路上に存在する NATFW NSLP対応ノードが、この CREATEメッセージをィ ンタセブトする。
(3)このノードが NATFW機能を持つものであった場合、この CREATEメッセージに
含まれるパラメータに基づ!/、て、ポリシールールを作成する。
[0021] なお、 CREATEメッセージに含まれるパラメータとは、対象となるデータパケットの アドレス情報、アクション (例えば、パケットを通す Z通さないという処理など)及びァク シヨンに対する補足情報 (ライフタイムなど)である。このデータパケットのアドレス情報 は、フロー IDより引用される。
[0022] なお、 QoS NSLPの場合と同様〖こ、データ送信者及びデータ受信者が NATFW NSLP対応ノードではない場合には、データ経路上に存在する NATFW NSLP対 応ノードで、データ送信者 (又はデータ受信者)に一番近いノードが、シグナリングメ ッセージの送信者 (又は受信者)となる。また、 CREATEメッセージを送信する前提 として、 NATFWノードには、 NSISメッセージを通すためのポリシールールがあらか じめ作成されて ヽることが定められて 、る。
[0023] また、 NTLPにはフロー IDが含まれており、このフロー IDが、 NSLPレイヤにおい てデータパケットのフィルタリング情報 (例えば、 QoS保証におけるパケットクラシファ ィァ(packet classifier:パケット分類情報)として使用される。データパケットのフィルタ リング情報が NATに対応できるようにするため、非特許文献 11Bでは、 NATが NTL P対応であり、かつ、 NATにおいて、パケットヘッダのアドレス情報の変換と同時にフ ロー IDの中身も変換されることが要請されて!、る。
非特干文献 1 : R. Braden, L. Zhang, b. Berson, S. Herzog and S. Jamin, Resource R eSerVation Protocol - Version 1 Functional Specification , RFC 2205, September 1 997.
非特許文献 2 : NSIS WG (http://www.ietf.org/html.charters/nsis-charter.html) 非特許文献 3 : H. Chaskar, Ed, "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC3583, September 2003
非特許文献 4: Sven Van den Bosch, Georgios Karagiannis and Andrew McDonald "N SLP for Quality— of— Service signalling , draft-ietf-nsis-qos-nslp-05.txt, October 20 04
特許文献 5 : X. Fu, H. Schulzrinne, H. Tschofenig, "Mobility issues in Next Step s ignaling", draft— fu—nsis— mobility— 01. txt, October 2003
非特許文献 6 : S. Lee, et. AL, "Applicability Statement of NSIS Protocols in Mobile Environments", draft— ietf— nsis— applicability— mobility— signaling— 00. txt, October 18, 2004
非特許文献 7 : R. Hancock (editor), 'Next Steps in Signaling: Framewor , draft- ietf -nsis-lw-07.txt, November 1, 2003
非特許文献 8 : MRSVP: A. K. TALUKDAR, B.R. BADRINATH and A. ACHARYA, " A Resource Reservation Protocol for an Integrated Service Network with Mobile Ho sts", Wireless Network 7 pp5- 19, 2001
非特許文献 9 : T. Sanda, T. Ue, "Pre CRN discovery from proxy on candidate new p ath", draft— sanda— nsis— mobility— qos— proxy— 01.txt, Feruary 2004
非特許文献 10 :三田貴子,上豊榭,荒牧隆, "モピリティをサポートしたシームレスな QoS経路確立方法に関する提案",電子情報通信学会モパイルマルチメディア通信 (MoMuC)研究会, Vol.104 No.38, pp59- 64, 2004年 5月
非特干文献 11A : H. Schulznnne, R. Hancock, GIMPS: General Internet Messaging
Protocol for Signaling", draft- ietf- nsis- ntlp-05.txt, February 2005
非特許文献 1 IB : H. Schulzrinne, R. Hancock, "GIMPS: General Internet Messaging
Protocol for Signaling", draft- ietf- nsis- ntlp-07.txt, July 18, 2005
非特許文献 12 :三田貴子他, "モパイル IPを用いた通信における QoSステート管理方 法に関する提案",電子情報通信学会情報ネットワーク (IN)研究会, vol. 104, no. 5
64, IN2004-144, pp. 1-6, 2005年 1月
非特許文献 13 : M. Stiemerling, H. Tschofenig and C. Aoun "NAT/Firewall NSIS Sig naling Layer Protocol (NSLP)", draft- ietf- nsis- nslp-nat! - 07.txt, July 18, 2005 [0024] 従来の技術には、主に、下記の 2つの課題 (第 1及び第 2の課題)が存在する。
[0025] まず、従来の技術に係る第 1の課題について説明する。例えば、上記の非特許文 献 8に記載されている方法では、 MNのための QoS経路をあら力じめ確立するため に、新たなサブネットワークにおけるプロキシが用いられる。しかしながら、 MNの NC oAを取得した後にのみ、プロキシによって QoS経路が確立される力 プロキシは、 M Nが実際に移動する前に MNの NCoAを取得できない可能性があり、事前に NCoA
を取得する処理によって、スムーズな経路の確立が妨げられてしまう可能性がある。
[0026] また、 QoS経路を確立するための試み力 いくつもの経路にわたって実行される必 要があり、 MNは、こうした QoS経路の確立結果に基づいて、新たな接続ポイントへ の移動を決定する場合がある。したがって、 MNの NCoAは、 QoS経路の確立後に 生成される場合もあり、この場合には、プロキシが、 MNの新たな接続ポイントとなり得 る各接続ポイントにおける MNの NCoAを取得することは困難である。
[0027] 次に、従来の技術に係る第 2の課題について説明する。 NSISの現仕様では、フロ 一 IDがそのままパケットクラシファイア(packet classifier:パケット分類情報)として用 いられるため、フロー IDにデータパケットのヘッダ情報が含まれていなければならず 、この制限が、 MNのハンドオーバ時におけるスムーズな QoS経路変更を困難にして いる。さらに、端末が 1つのセッションに対し、複数の IPアドレスや複数のポート番号 を用いて通信を行っている場合 (例えば、端末がマルチホーム状態の場合)や、セッ シヨンの途中で IPアドレスやポート番号に変更が生じる場合に、 QoS経路の管理は 非常に困難なものとなってしまう場合がある。
発明の開示
[0028] 上記問題に鑑み、本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後 における経路の再設定をより迅速に行って、パケット通信の中断時間(特に、 QoS経 路の中断時間)を低減させることを第 1の目的とする。
[0029] また、本発明では、端末が 1つのセッションに対し、複数の IPアドレスや複数のポー ト番号を用いて通信を行っている場合や、セッションの途中で IPアドレスやポート番 号に変更が生じる場合において、経路 (特に、 QoS経路)の管理を容易にすることを 第 2の目的とする。
[0030] 上記目的を達成するため、本発明の通信システムは、それぞれがサブネットを構成 する複数のアクセスルータが通信ネットワークを介して接続されており、前記通信ネッ トワークを経由する任意の通信端末間における通信に対して、付加的サービスを提 供するための経路を確立することが可能な通信システムであって、
前記複数のアクセスルータのうちの 1つである第 1アクセスルータに接続し、前記第 1アクセスルータが構成する第 1サブネットで取得する第 1アドレスを使用して通信を
行う移動可能な移動端末と、
前記通信ネットワークに接続されており、前記移動端末の通信相手となる通信相手 端末と、
前記移動端末力 前記複数のアクセスルータのうちの 1つである第 2アクセスルータ に接続した場合に前記第 2アクセスルータが構成する第 2サブネットで取得する第 2 アドレスを使用せずに、前記第 1アクセスルータに接続している前記移動端末と前記 通信相手端末との間の通信に対して前記付加的サービスを提供するための第 1経路 が確立された状態で、前記第 2アクセスルータに接続した状態における前記移動端 末と前記通信相手端末との間の通信に対して前記付加的サービスを提供するため の第 2経路を確立する処理を開始することが可能な前記通信ネットワーク内に存在す る通信ノードとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信 ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の 中断時間(特に、 QoS経路の中断時間)を低減させることが可能となる。
[0031] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード 力 前記第 2アクセスルータの近隣に存在している。
この構成により、移動端末がハンドオーバ後に第 2アクセスルータに接続した場合 に、この第 2アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可 能となる。
[0032] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード 力 前記第 1経路を識別するための情報、及び前記第 1経路における前記通信相手 端末のアドレスを少なくとも含むトリガ情報を受信し、前記トリガ情報に基づいて前記 第 2経路を確立する処理を開始するように構成されて ヽる。
この構成により、プロキシとして機能する通信ノードは、この第 2経路の確立処理に 必要な情報や、その開始タイミングなどを把握することが可能となる。
[0033] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記移動端末が 、前記トリガ情報を前記通信ノードに送信するように構成されて ヽる。
この構成により、移動端末が、第 2経路の確立開始処理を開始させる指示を行うとと
もに、第 2経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信す ることが可能となる。
[0034] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード 力 自ノードを一方の終端とする前記第 2経路を確立するように構成されて 、る。 この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノー ドのアドレスを使用して、第 2経路を確立することが可能となる。
[0035] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード は、前記移動端末が前記第 2サブネットに移動して割り当てられた第 2アドレスを取得 し、前記移動端末の前記第 2アドレスを一方の終端とする第 3経路を確立する処理を 開始するように構成されて 、る。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレス を取得した場合には、そのアドレスに基づく第 3経路の確立が開始されるようになる。
[0036] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード 力 前記移動端末から前記通信相手端末へのパケットを転送する際に自ノードのァ ドレスを送信元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル 化手段を有し、前記第 3経路の確立が完了するまでは、前記移動端末から前記通信 相手端末への前記パケットを前記カプセルィ匕手段によってカプセルィ匕することで、前 記パケットが、前記第 2経路に対して提供される前記付加的サービスを受けられるよう に構成されている。
この構成により、プロキシとして機能する通信ノード力 QoS保証などの付力卩的サ一 ビスが提供されないヘッダを有するパケットに対して、カプセルィ匕を行うことで、付カロ 的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセルィ匕 が行われることによって、適切なあて先にパケットが到達可能となる。
[0037] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記第 2経路の 終端が前記通信ノード及び前記通信相手端末であり、前記通信相手端末が、前記 移動端末にパケットを送信する際に前記通信ノードのアドレスをあて先アドレスとする ヘッダを用いて前記パケットをカプセルィ匕するカプセルィ匕手段を有し、前記第 3経路 の確立が完了するまでは、前記通信相手端末から前記移動端末への前記パケットを
前記カプセルィ匕手段によってカプセルィ匕することで、前記パケットが、前記第 2経路 に対して提供される前記付加的サービスを受けられるように構成されている。
この構成により、通信相手端末 (CN)が、 QoS保証などの付加的サービスが提供さ れないヘッダを有するパケットに対して、カプセルィ匕を行うことで、付加的サービスを 受けたパケット伝送が行われるようになるとともに、適切に脱カプセルィ匕が行われるこ とによって、適切なあて先にパケットが到達可能となる。
[0038] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記第 2経路の 終端が前記第 2アクセスルータの近隣に存在する前記通信ノード及び前記通信相手 端末の近隣に存在する相手側近隣通信ノードであり、前記相手側近隣通信ノードが 、前記通信相手端末から前記移動端末へのパケットを転送する際に前記通信ノード のアドレスをあて先アドレスとするヘッダを用いて前記パケットをカプセル化するカプ セル化手段を有し、前記第 3経路の確立が完了するまでは、前記通信相手端末から 前記移動端末への前記パケットを前記カプセルィ匕手段によってカプセルィ匕すること で、前記パケットが、前記第 2経路に対して提供される前記付加的サービスを受けら れるように構成されている。
この構成により、通信相手端末 (CN)の近隣に存在する相手側近隣通信ノードが、 QoS保証などの付カ卩的サービスが提供されな 、ヘッダを有するパケットに対して、力 プセルイ匕を行うことで、付カ卩的サービスを受けたパケット伝送が行われるようになると ともに、適切に脱カプセルィ匕が行われることによって、適切なあて先にパケットが到達 可能となる。また、通信相手端末 (CN)が、付加的サービス機能やカプセル化機能を 実装していない場合でも、伝送されるパケットは付加的サービスを受けることが可能と なる。
[0039] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記移動端末が 前記第 2サブネットに移動して前記第 3経路の確立が完了した場合に、前記第 1サブ ネットに接続している状態で使用されていた前記第 1経路、及び前記通信ノードによ つて確立された前記第 2経路が削除されるように構成されて 、る。
この構成により、ハンドオーバ前の状態力 ハンドオーバ後の状態に移行する際に 、余分な情報 (無駄なリソース予約など)が残らな 、ようにすることが可能となる。
[0040] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード 力 自ノードと前記通信相手端末との間の経路上の中間通信ノードに、前記第 2経路 を確立する処理を行う際に送受信されるシグナリングメッセージのルーティングのた めのステートを導入する処理を開始するように構成されて 、る。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信 ノード力 ハンドオーバ後における経路の再設定のうち、シグナリングメッセージのル 一ティングのためのステート確立処理を経路の一部に対して迅速に行って、パケット 通信の中断時間(特に、 QoS経路の中断時間)を低減させることが可能となる。
[0041] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード 力 前記中間通信ノードに対して、自ノードのアドレス及び前記通信相手端末のアド レスにより構成された識別情報を送信し、前記中間通信ノードが、前記識別情報を保 持して、前記識別情報を有するシグナリングメッセージを特定するように構成されて ヽ る。
この構成により、移動端末に対してハンドオーバ後に割り当てられるアドレスを取得 する前に、プロキシとして機能する通信ノードは、通信相手端末との間におけるシグ ナリングメッセージのルーティングのためのステート確立処理を開始することが可能と なる。
[0042] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記通信ノード は、前記移動端末が前記第 2サブネットに移動して割り当てられた第 2アドレスを取得 した場合に、前記第 2経路に係る付加的サービスを提供するための情報を含むシグ ナリングメッセージを送信し、前記中間通信ノードが、前記シグナリングメッセージの ルーティングのためのステートを使用して、前記シグナリングメッセージの伝送を行う ように構成されている。
この構成により、移動端末のハンドオーバ後に割り当てられるアドレスを取得する前 に確立されたシグナリングメッセージのルーティングのためのステートを利用して、付 加的サービスを提供するための情報を含むシグナリングメッセージを伝送することが 可能となり、新たな経路 (特に、 QoS経路)を迅速に確立することが可能となる。
[0043] さらに、本発明の通信システムは、上記の通信システムにカ卩えて、前記付加的サー
ビスが QoS保証である場合に適用される。
[0044] また、上記目的を達成するため、本発明のリソース管理装置によれば、それぞれが サブネットを構成する複数のアクセスルータが通信ネットワークを介して接続されてお り、前記通信ネットワークを経由する任意の通信端末間における通信に対して、付カロ 的サービスを提供するための経路を確立することが可能な前記通信ネットワークに存 在する通信ノード内のリソース管理装置であって、
前記経路において、付カ卩的サービスを提供するためのリソースを確保するためのリ ソース確保手段と、
前記複数のアクセスルータのうちの 1つである第 1アクセスルータに接続している前 記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手とな る通信相手端末との間の通信に対して前記付加的サービスを提供するための第 1経 路を識別するための情報、及び前記第 1経路における前記通信相手端末のアドレス を少なくとも含むトリガ情報を受信するトリガ受信手段と、
前記トリガ受信手段で前記トリガ情報を受信した場合、前記トリガ情報に基づ!、て、 前記第 1アクセスルータとは異なる第 2アクセスルータに接続した状態における前記 移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供す るための第 2経路を確立する処理を開始するメッセージを生成するメッセージ生成手 段とを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信 ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の 中断時間(特に、 QoS経路の中断時間)を低減させることが可能となる。
[0045] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記メッ セージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されて いる。
この構成により、上記のメッセージに係るリソース予約力 プロキシによるものである ことを、経路上の各 QNEに対して明示することが可能となる。
[0046] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記第 2 アクセスルータの近隣に存在する前記通信ノード内に配置されて 、る。
この構成により、移動端末がハンドオーバ後に第 2アクセスルータに接続した場合 に、この第 2アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可 能となる。
[0047] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記トリ ガ情報に、前記第 1経路を識別するための情報、及び前記第 1経路における前記通 信相手端末のアドレスが少なくとも含まれて 、る。
この構成により、プロキシとして機能する通信ノードは、この第 2経路の確立処理に 必要な情報や、その開始タイミングなどを把握することが可能となる。
[0048] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移 動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第 2経路の確立開始処理を開始させる指示を行うとと もに、第 2経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信す ることが可能となる。
[0049] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記通 信ノードを一方の終端とする前記第 2経路を確立するように構成されている。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノー ドのアドレスを使用して、第 2経路を確立することが可能となる。
[0050] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移 動端末が前記第 2サブネットに移動して割り当てられた前記第 2アドレスを取得し、前 記移動端末の前記第 2アドレスを一方の終端とする第 3経路を確立する処理を開始 するように構成されている。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレス を取得した場合には、そのアドレスに基づく第 3経路の確立が開始されるようになる。
[0051] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移 動端末力 前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信 元アドレスとするヘッダを用いて前記パケットをカプセルィ匕するカプセルィ匕手段を有 し、前記第 3経路の確立が完了するまでは、前記移動端末から前記通信相手端末へ の前記パケットを前記カプセルィ匕手段によってカプセルィ匕することで、前記パケットが
、前記第 2経路に対して提供される前記付加的サービスを受けられるように構成され ている。
この構成により、プロキシとして機能する通信ノード力 QoS保証などの付力卩的サ一 ビスが提供されないヘッダを有するパケットに対して、カプセルィ匕を行うことで、付カロ 的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセルィ匕 が行われることによって、適切なあて先にパケットが到達可能となる。
[0052] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記移 動端末が前記第 2サブネットに移動して前記第 3経路の確立が完了した場合に、前 記第 2経路を削除するためのメッセージを送信するように構成されている。
この構成により、ハンドオーバ前の状態力 ハンドオーバ後の状態に移行する際に 、余分な情報 (無駄なリソース予約など)が残らな 、ようにすることが可能となる。
[0053] さらに、本発明のリソース管理装置は、上記のリソース管理装置に加えて、前記付 加的サービス力 QoS保証である場合に適用可能である。
[0054] また、上記目的を達成するため、本発明のリソース管理方法は、それぞれがサブネ ットを構成する複数のアクセスルータが通信ネットワークを介して接続されており、前 記通信ネットワークを経由する任意の通信端末間における通信に対して、付加的サ 一ビスを提供するための経路を確立することが可能な前記通信ネットワークに存在す る通信ノードで行われるリソース管理方法であって、
前記経路において、付カ卩的サービスを提供するためのリソースを確保するためのリ ソース確保ステップと、
前記複数のアクセスルータのうちの 1つである第 1アクセスルータに接続している前 記移動端末と、前記通信ネットワークに接続されており前記移動端末の通信相手とな る通信相手端末との間の通信に対して前記付加的サービスを提供するための第 1経 路を識別するための情報、及び前記第 1経路における前記通信相手端末のアドレス を少なくとも含むトリガ情報を受信するトリガ受信ステップと、
前記トリガ受信ステップで前記トリガ情報を受信した場合、前記トリガ情報に基づ 、 て、前記第 1アクセスルータとは異なる第 2アクセスルータに接続した状態における前 記移動端末と前記通信相手端末との間の通信に対して前記付加的サービスを提供
するための第 2経路を確立する処理を開始するメッセージを生成するメッセージ生成 ステップとを有している。
この構成により、移動端末がハンドオーバを行う際に、プロキシとして機能する通信 ノードが、ハンドオーバ後における経路の再設定をより迅速に行って、パケット通信の 中断時間(特に、 QoS経路の中断時間)を低減させることが可能となる。
[0055] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記メッ セージには、前記移動端末の代理として経路設定を行う旨を示す情報が付加されて いる。
この構成により、上記のメッセージに係るリソース予約力 プロキシによるものである ことを、経路上の各 QNEに対して明示することが可能となる。
[0056] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記第 2 アクセスルータの近隣に存在する前記通信ノード内に配置されて 、る。
この構成により、移動端末がハンドオーバ後に第 2アクセスルータに接続した場合 に、この第 2アクセスルータの近隣に存在する通信ノードを経由した経路の設定が可 能となる。
[0057] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記トリ ガ情報に、前記第 1経路を識別するための情報、及び前記第 1経路における前記通 信相手端末のアドレスが少なくとも含まれて 、る。
この構成により、プロキシとして機能する通信ノードは、この第 2経路の確立処理に 必要な情報や、その開始タイミングなどを把握することが可能となる。
[0058] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移 動端末から前記トリガ情報を受信する。
この構成により、移動端末が、第 2経路の確立開始処理を開始させる指示を行うとと もに、第 2経路の確立に必要な情報を、プロキシとして機能する通信ノードに送信す ることが可能となる。
[0059] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記通 信ノードを一方の終端とする前記第 2経路を確立する。
この構成により、移動端末のアドレスを用いずに、プロキシとして機能する通信ノー
ドのアドレスを使用して、第 2経路を確立することが可能となる。
[0060] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移 動端末が前記第 2サブネットに移動して割り当てられた前記第 2アドレスを取得し、前 記移動端末の前記第 2アドレスを一方の終端とする第 3経路を確立する処理を開始 する。
この構成により、プロキシとして機能する通信ノードが、移動端末の新たなアドレス を取得した場合には、そのアドレスに基づく第 3経路の確立が開始されるようになる。
[0061] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移 動端末力 前記通信相手端末へのパケットを転送する際に自ノードのアドレスを送信 元アドレスとするヘッダを用いて前記パケットをカプセル化するカプセル化ステップを 有し、前記第 3経路の確立が完了するまでは、前記移動端末から前記通信相手端末 への前記パケットを前記カプセル化ステップにお 、てカプセルィヒすることで、前記パ ケットが、前記第 2経路に対して提供される前記付加的サービスを受けられるようにし ている。
この構成により、プロキシとして機能する通信ノード力 QoS保証などの付力卩的サ一 ビスが提供されないヘッダを有するパケットに対して、カプセルィ匕を行うことで、付カロ 的サービスを受けたパケット伝送が行われるようになるとともに、適切に脱カプセルィ匕 が行われることによって、適切なあて先にパケットが到達可能となる。
[0062] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記移 動端末が前記第 2サブネットに移動して前記第 3経路の確立が完了した場合に、前 記第 2経路を削除するためのメッセージを送信する。
この構成により、ハンドオーバ前の状態力 ハンドオーバ後の状態に移行する際に 、余分な情報 (無駄なリソース予約など)が残らな 、ようにすることが可能となる。
[0063] さらに、本発明のリソース管理方法は、上記のリソース管理方法に加えて、前記付 加的サービス力 QoS保証である場合に適用される。
[0064] また、上記目的を達成するため、本発明の通信管理装置は、シグナリングメッセ一 ジをルーティングする機能を有する第 1ユニットと、提供する付加的サービスに関する 情報を管理するための機能を有する第 2ユニットとにより構成された通信プロトコルを
使用して 2つの通信ノード間で行われる通信において、前記 2つの通信ノード間の経 路上に存在し、前記 2つの通信ノード間で伝送されるデータパケットに対して前記付 加的サービスを提供する通信ノード内の通信管理装置であって、
前記第 1ユニットが、前記 2つの通信ノード間の経路の一部であって、自ノードを含 んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメ ッセージのルーティングのためのステートを管理するステート管理手段を有し、 前記第 2ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報で あって、前記付加的サービスを提供する対象となるデータパケットを特定するための 前記フィルタ情報を管理するフィルタ情報管理手段を有している。
この構成により、付カ卩的サービス (特に QoS)に係る経路の確立の際に行われるシ グナリングメッセージのルーティングのためのステート確立機構と、データパケットに 対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩 和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。
[0065] さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記ステート 力 前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記 2つの通信ノード のアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的 サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異な るアドレスが設定できるようになり、付カ卩的サービス (特に QoS)に係る経路の確立の 際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、デ ータパケットに対して付カ卩的サービスを提供するためのリソース予約機構との間の相 互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処 理を柔軟に行えるようにすることが可能となる。
[0066] さらに、本発明の通信管理装置は、上記の通信管理装置に加えて、前記第 1ュ-ッ トカ NSISにおける NTLP層に配置されており、前記第 2ユニットが、 NSISにおける NSLP層に配置されて!、る。
この構成により、フロー IDとフィルタ情報とを分けて別々に管理し、シグナリングメッ セージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存
性を緩和することが可能となる。また、 NSISにおいて、付カ卩的サービス (特に QoS) に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのス テート確立機構と、データパケットに対して付カ卩的サービスを提供するためのリソース 予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのた めのステートの確立処理を柔軟に行えるようにすることが可能となる。
[0067] また、上記目的を達成するため、本発明の通信管理方法は、シグナリングメッセ一 ジをルーティングする機能を有する第 1ユニットと、提供する付加的サービスに関する 情報を管理するための機能を有する第 2ユニットとにより構成された通信プロトコルを 使用して 2つの通信ノード間で行われる通信において、前記 2つの通信ノード間の経 路上に存在し、前記 2つの通信ノード間で伝送されるデータパケットに対して前記付 加的サービスを提供する通信ノードで行われる通信管理方法であって、
前記第 1ユニットが、前記 2つの通信ノード間の経路の一部であって、自ノードを含 んだ任意の両端点を有する前記経路の一部において伝送される前記シグナリングメ ッセージのルーティングのためのステートを管理するステート管理ステップと、 前記第 2ユニットが、前記シグナリングメッセージによって伝送されるフィルタ情報で あって、前記付加的サービスを提供する対象となるデータパケットを特定するための 前記フィルタ情報を管理するフィルタ情報管理ステップとを有している。
この構成により、付カ卩的サービス (特に QoS)に係る経路の確立の際に行われるシ グナリングメッセージのルーティングのためのステート確立機構と、データパケットに 対して付加的サービスを提供するためのリソース予約機構との間の相互依存性を緩 和することが可能となり、経路の管理を容易に行えるようにすることが可能となる。
[0068] さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記ステート 力 前記任意の両端点のアドレスを有し、前記フィルタ情報が、前記 2つの通信ノード のアドレスを有している。
この構成により、シグナリングメッセージのルーティングのための情報、及び付加的 サービスを提供するデータパケットを特定するための情報のそれぞれに関して、異な るアドレスが設定できるようになり、付カ卩的サービス (特に QoS)に係る経路の確立の 際に行われるシグナリングメッセージのルーティングのためのステート確立機構と、デ
ータパケットに対して付カ卩的サービスを提供するためのリソース予約機構との間の相 互依存性を緩和することが可能となり、特に、ルーティングのためのステートの確立処 理を柔軟に行えるようにすることが可能となる。
[0069] さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第 1ュ-ッ トカ NSISにおける NTLP層に配置されており、前記第 2ユニットが、 NSISにおける NSLP層に配置されて!、る。
この構成により、フロー IDとフィルタ情報とを分けて別々に管理し、シグナリングメッ セージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存 性を緩和することが可能となる。また、 NSISにおいて、付カ卩的サービス (特に QoS) に係る経路の確立の際に行われるシグナリングメッセージのルーティングのためのス テート確立機構と、データパケットに対して付カ卩的サービスを提供するためのリソース 予約機構との間の相互依存性を緩和することが可能となり、特に、ルーティングのた めのステートの確立処理を柔軟に行えるようにすることが可能となる。
[0070] さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第 1及び 第 2ユニットが、 NSISにおける NTLP層に配置されて!、る。
この構成により、フロー IDとフィルタ情報とを分けて別々に管理し、シグナリングメッ セージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存 性を緩和することが可能となる。
[0071] さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第 1ュ-ッ トカ NSISにおける NTLP層に配置されており、前記第 2ユニットが、 NSISにおける NSLP層の任意の機能が参照可能な NSLP共通部に配置されている。
この構成により、フロー IDとフィルタ情報とを分けて別々に管理し、シグナリングメッ セージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存 性を緩和することが可能となる。
[0072] さらに、本発明の通信管理方法は、上記の通信管理方法に加えて、前記第 1ュ-ッ トカ NSISにおける NTLP層に配置されており、前記第 2ユニットが、 NSISにおける NSLP層の特定の機能部に配置されていて、前記特定の機能部から前記 NSLP層 の任意の機能部に、前記フィルタ情報の一部又は全部が渡されるように構成されて
いる。
この構成により、フロー IDとフィルタ情報とを分けて別々に管理し、シグナリングメッ セージの通る経路に係る処理と、データパケットの通る経路に係る処理との相互依存 性を緩和することが可能となる。
[0073] 本発明は、上記の構成を有しており、移動端末がハンドオーバ後に接続するサブ ネットにおいて使用するアドレス (NCoA)を用いずに、ハンドオーバ後の移動端末が 送信元又はあて先に設定されたパケットに対して、付加的サービス (特に、 QoS)を 提供することによって、移動端末の NCoAの生成タイミングや取得機構などに影響さ れない、スムーズな経路 (特に、 QoS経路)の確立が実現可能となる。
[0074] また、本発明は、上記の構成を有しており、付加的サービス (特に QoS)に係る経路 の確立の際に行われるシグナリングメッセージのルーティングのためのステート確立 機構と、データパケットに対して付加的サービスを提供するためのリソース予約機構と の間の相互依存性を緩和することにより、移動端末の NCoAの生成タイミングや取得 機構などに影響されない、スムーズな経路 (特に、 QoS経路)の確立が実現可能とな るとともに、さらには、複数の IPアドレスや複数のポート番号を用いて通信を行ってい る場合や、セッションの途中で IPアドレスやポート番号に変更が生じる場合において も、経路 (特に、 QoS経路)の管理を容易にすることを可能にする。
図面の簡単な説明
[0075] [図 1]本発明の第 1の実施の形態における通信システムで、 MNが接続するサブセッ トを変更する前の QoS経路の状態を模式的に示す図
[図 2]本発明の第 1の実施の形態における通信システムで、 MNのプロキシとなる QN Eが MN用に予測経路を確立した状態を模式的に示す図
[図 3]本発明の第 1の実施の形態における通信システムで、 MNがサブセットを移動し
、 MNと CNとの間で新たな QoS経路が確立された状態を模式的に示す図
[図 4]本発明の第 1の実施の形態における QNEの一構成例を示す図
[図 5]本発明の第 1の実施の形態における動作例を示すシーケンスチャート
[図 6]本発明の第 2の実施の形態における通信システムで、 MNが接続するサブセッ トを変更する前の QoS経路の状態を模式的に示す図
[図 7]本発明の第 2の実施の形態における通信システムで、 MNのプロキシとなる QN Eが MN用に予測経路を確立した状態を模式的に示す図
[図 8]本発明の第 2の実施の形態における通信システムで、 MNがサブセットを移動し
、 MNと CNとの間で新たな QoS経路が確立された状態を模式的に示す図
[図 9]本発明の第 2の実施の形態における動作例を示すシーケンスチャート
[図 10]従来の技術における NSISのプロトコル構成を説明するための模式図
[図 11]従来の技術における NSISのノードである NEや QNEが「隣り合う」という概念 を説明するための模式図
[図 12]本発明の第 3の実施の形態における通信システムで、 MNが接続するサブセ ットを変更する前の QoS予約の状態及びルーティングのためのステート内に含まれる フロー IDの状態を模式的に示す図
[図 13]本発明の第 3の実施の形態における通信システムで、 MNのプロキシとなる Q NEが MN用に予測経路上にルーティングのためのステートを確立した状態を、この 中に含まれるフロー IDを示すことにより模式的に示す図
[図 14]本発明の第 3の実施の形態における通信システムで、 MNがサブセットを移動 し、 MNと CNとの間で新たな QoS経路が確立された状態を模式的に示す図
[図 15]本発明の第 3の実施の形態において、データパケットの送信方向が uplink方向 の場合の動作例を示すシーケンスチャート
[図 16]本発明の第 3の実施の形態において、データパケットの送信方向が downlink 方向の場合の動作例を示すシーケンスチャート
[図 17]本発明の第 3の実施の形態において、 QNE内でフィルタ情報及びフロー IDを 管理する主体を模式的に示す図
[図 18]本発明の第 3の実施の形態において、データ経路上に NATFWが存在して おり、データパケットの送信方向が uplink方向の場合の動作例を示すシーケンスチヤ ート
発明を実施するための最良の形態
以下、図面を参照しながら、本発明の第 1〜第 3の実施の形態について説明する。 なお、まず、本発明の第 1の実施の形態では、データの流れ方向が、移動を行う MN
から、その通信相手である CNに向力う方向(以下、 uplink方向と呼ぶ)の場合につい て説明を行い、続いて、本発明の第 2の実施の形態では、データの流れ方向が、 CN から MNに向かう方向(以下、 downlink方向と呼ぶ)の場合について説明を行う。
[0077] <第 1の実施の形態 >
以下、本発明の第 1の実施の形態について説明する。まず、図 1〜3を参照しなが ら、本発明の第 1の実施の形態に係る概要について説明する。図 1は、本発明の第 1 の実施の形態における通信システムで、 MNが接続するサブセットを変更する前の Q oS経路の状態を模式的に示す図である。また、図 2は、本発明の第 1の実施の形態 における通信システムで、 MNのプロキシとなる QNEが MN用に予測経路を確立し た状態を模式的に示す図である。また、図 3は、本発明の第 1の実施の形態における 通信システムで、 MNがサブセットを移動し、 MNと CNとの間で新たな QoS経路が確 立された状態を模式的に示す図である。
[0078] 図 1〜3には、無線通信により AR (Access Router)に接続して CN121との通信を 行う MN101と、 MN101の通信相手となる CN121と、サブネット 103を形成する AR 105と、サブネット 107を形成する AR109と、 MN101と CN121との間における経路 上に存在し、 MN 101と CN 121との間で伝送されるバケツトに関して QoS保証を行う QoS認識機能(QoS- aware)を有する QNE111、 113、 115、 117、 119、 123、 125 とが図示されている。
[0079] なお、 MN101がサブネット 103に存在している場合(すなわち、 MN101が AR10 5に接続している場合)、 MN101から CN121への uplink方向の経路 127上には、 A R105、 QNE111、 QNE113、 QNE115、 QNE117、 QNE119力存在しており、 MN101がサブネット 107に存在している場合(すなわち、 MN101が AR109に接続 している場合)、 MN101から CN121への uplink方向の経路 129上には、 AR109、 QNE123, QNE125, QNE115, QNE 117, QNE119力存在して!/、るものとする 。なお、経路 127と経路 129とは一部が重複しており、経路 127と経路 129との CRN (Crossover Node:クロスオーバノード)を QNE115とする。
[0080] 図 1において、 MN101から CN121に送信されるデータパケットは、経路 127を経 由して伝送される。このとき、経路 127上のすべての QNE111、 113、 115、 117、 1
19は、 MN101から CN121に送信されるデータパケットに関する QoSステートを有 して ヽる。すなわち、各 QNE111、 113、 115、 117、 119は、少なくとも送信元ァドレ ス(source address)及びあて先アドレス(destination address)の情報を含む識別情報 (この情報をフィルタ情報 (filter)と呼ぶ)と、このフィルタ情報に対応するリソース予約 情報(resource)とが関連付けている QoSステートを保持しており、 MN101から CN1 21に送信されるデータパケットのヘッダ (特に、送信元アドレス及びあて先アドレス) を参照してフィルタ情報を特定し、対応するリソース予約情報に基づく QoS保証を行 うように構成されている。なお、上述した非特許文献 4、 6、 7などの現在のフロー IDは 、データパケットの送信元アドレス及びあて先アドレスを含む情報により構成されて ヽ ると記載されており、このフロー IDを上記のフィルタ情報として利用することも可能で ある。また、フィルタ情報は、フロー IDとは異なる情報であってもよい。
[0081] なお、図 1に図示されているように、経路 127のフィルタ情報(MN101がサブネット 103から割り当てられている IPアドレス(cCoA: current Care- of Address)が送信元 アドレスとして含まれているとともに、 CN121の IPアドレスがあて先アドレスとして含ま れているフィルタ情報)を filterAとし、 filterAに対応するリソース予約情報を resourceA とする。
[0082] MN101は、サブネット 107に移動する可能性があり、プロキシ 123に対して予測経 路 (経路 129)、又は予測経路の一部の確立を所望している。なお、 MN101がサブ ネット 107に移動する前に、プロキシ 123によって予測経路、又は予測経路の一部が 確立されることで、 MN101が実際にサブネット 107に移動した後に、より迅速に MN 101から CN121への QoS経路が確立され、ハンドオーバによる QoS保証の中断時 間を短縮することが可能となる。
[0083] QNE (プロキシ) 123が予測経路を確立するための何らかのトリガを受けた場合に は、 QNE (プロキシ) 123と CRN (ここでは QNE115)との間で QoS経路が確立され る。この新たな経路が確立された場合には、 QNE (プロキシ) 123や、 QNE (プロキ シ) 123と QNE115との間の各中間 QNE (例えば、 QNE125)は、新たな QoSステ ートを有することになる。すなわち、図 2に図示されているように、 QNE (プロキシ) 12 3や QNE125では、 QNE (プロキシ) 123の IPアドレスが送信元アドレスとして含まれ
ているとともに、 CN121の IPアドレスがあて先アドレスとして含まれているフィルタ情 報 (filterB)に対して、 filterAと同一のリソース予約情報である resourceAが設定される
[0084] 一方、 QNE115と CN121との間の経路上の QNEに関しては、新たなフィルタ情 報(上記の filterB)力 現在のフィルタ情報 (filterA)に追加される。これにより、図 2に 図示されているように、 QNE115や、 QNE115と CN121との間の各中間 QNE (例 えば、 QNE117、 119)は、 filterA及び filterBに対して resourceAが設定された QoS ステートを有することになり、 filterBによって定義されるデータトラフィックには、 filterA によって定義されるデータトラフィックのために予約された resourceAが使用可能とな る。なお、例えば、同一セッション IDを有する 2つのフィルタ情報(filterA及び filterB) によりどちらか一方が削除されてしまうなど、従来行われている処理によって本発明 に係る動作に不具合が生じる可能性があるため、例えば、 filterBに係る RESERVEメ ッセージには、プロキシによる QoS経路の確立であることを示す特別なフラグ(「プロ キシフラグ」 )が付加されることが望ま 、。
[0085] 以上のように、 MN101がサブネット 107への移動を行う前に(あるいは、 MN101 のサブネット 107への移動とは無関係に)、 QNE (プロキシ) 123は、 MN101の NCo A (MN 101がサブネット 107に移動した後に割り当てられる新たな Co A)を用いるこ となく、 MN 101がサブネット 107に接続した後に使用される経路の一部(QNE (プロ キシ) 123から CN121までの経路)に係るリソース予約を行うことが可能となる(図 2に 図示されている状態)。
[0086] そして、 MN101が NCoAを取得した場合(実際にサブネット 107に移動して NCo Aを取得する力、あるいはサブネット 103に接続した状態で NCoAを取得した場合) 【こ ίま、図 3【こ図示されて!ヽるよう【こ、経路 129上の各中 f¾QNE (QNE123、 125、 11 5、 117、 119)において、 MN101の NCoAが送信元アドレスとして含まれているとと もに、 CN121の IPアドレスがあて先アドレスとして含まれている新たなフィルタ情報 (f ilterC)が filterA又は filterBに追加されることによって、 QoS経路の更新が行われる。 なお、 MN101がサブネット 107に移動した場合には、 filterAに関しては、能動的(削 除を指示するメッセージの送信などによる)又は受動的(タイムアウトなどによる)に削
除されることが望ましい。また、フロー IDとは異なる情報としてフィルタ情報が存在す る場合には、フロー IDは、データパケットの送信元アドレス Zあて先アドレスに依存す るものでなくてもよい。例えば、図 3でプロキシ 123が filterCに関するリソース予約を行 う際、経路 129全体に使われるフロー IDは「送信元 = QNE (プロキシ) 123、あて先 = CN121」を含んでいてもよぐまた MN101から QNE (プロキシ) 123までの経路 に関しては「送信元 = QNE (プロキシ) 123、あて先 = MN101」を含むフロー ID、 Q NE (プロキシ) 123から CN121までの経路に関しては「送信元 = QNE (プロキシ) 1 23、あて先 = CN121」を含むフロー IDをそれぞれ用いて、 2つの経路として扱って ちょい。
[0087] 例えば、 MN101がサブネット 107に移動して NCoAを取得した後に、 NCoAに関 する QoS経路の更新が完了(filterCに関するリソース予約が完了)する前までは、 M N101から CN121あてに送信されるデータパケットは、 QNE (プロキシ) 123によつ て、 filterBの情報を含むァウタヘッダ(送信元アドレスを QNE (プロキシ) 123の IPァ ドレスとし、あて先アドレスを CN121の IPアドレスとするヘッダ)が付カ卩されて、カプセ ル化される。このカプセル化されたデータパケットは filterBによって識別され、各中間 QNEにおいて、 resourceAに基づく QoS保証が行われて伝送され、 filterBによって 識別される経路の最終 QNEによって脱カプセルィ匕される。なお、この最終 QNEは C N121であることが望ましいが、 CN121が QNEではない場合には、その他の QNE ( 例えば、経路上において、 CN121の最も近くに存在する QNE119)であってもよい
[0088] 最終 QNEは、 filterBで特定されるヘッダを持つパケットが到達した際には、脱力プ セル化を行ってインナパケットを取り出す。 CN121が最終 QNEの場合にはそのイン ナパケットを取得し、 QNE119が最終 QNEの場合にはそのインナパケットを CN121 に向けて転送する。なお、経路全体にわたって QoS予約が行われるようにするため の方法としては、例えば IPv4最小カプセル化など、上述のパケットのカプセル化方 法以外にも存在することは、当業者にとって明白であり、任意のパケットのカプセルィ匕 方法を本発明に適用することが可能である。また、本発明は、他の種類のカプセル化 やトンネリング機構においても良好に動作する。
[0089] このように、 MN101の NCoAが設定されている filterCに関するリソース予約が完了 するまでは、データパケットのカプセル化が行われ、 QNE (プロキシ) 123の IPァドレ スが送信元アドレスとして設定されて 、る filterBによって、カプセル化されたデータパ ケットの QoS保証が行われるように構成されており、 MN101の NCoAを用いてリソー ス予約が行われるまでの QoS保証の中断時間を低減することが可能となる。
[0090] また、 filterCの QoSの更新に成功した後(すなわち、 filterCが経路 129上のすべて の QNEに導入された後)は、 QNE (プロキシ) 123は、 filterBのデータパケットの生成 (filterAのデータパケットのカプセルィ匕)を終了する。そして、 filter Aや filterBは能動的 又は受動的に削除され、最終的に filterCに関する QoSステートのみが残り、サブネッ ト 107に接続している MN101から CN121への経路 129において、 MN101から C N121へのデータバケツトに対する QoS保証が行われる。
[0091] 次に、図 4を参照しながら、本発明の第 1の実施の形態における QNEの構成につ いて説明する。図 4は、本発明の第 1の実施の形態における QNEの一構成例を示す 図である。図 4に示す QNEは、受信手段 11、送信手段 13、トリガ検出手段 15、メッ セージ生成'処理手段 17、フィルタリング手段 19、カプセルィ匕 Z脱カプセルィ匕手段 2 1、 QoS情報格納手段 23を有している。
[0092] 受信手段 11及び送信手段 13は、パケットの受信及びパケットの送信を行うための 手段である。また、トリガ検出手段 15は、例えば MN101から受信する、予測経路を 確立するための何らかのトリガに係る処理を行うための手段である。なお、受信したト リガ情報は、例えば、フィルタ情報ごとに関連付けられて QoS情報格納手段 23に格 納される。また、トリガ検出手段 15からメッセージ生成 ·処理手段 17に対して、トリガ 情報の受信イベントが発生した旨を示す情報や、トリガ情報自体が供給される。
[0093] また、メッセージ生成.処理手段 17は、トリガ情報に含まれる MN101と CN121との 間の QoS経路で用いられているセッション IDや、 QSpec情報や、 CN121の IPァドレ スなどの情報に基づいて、データ経路上の各通信ノードの調査や、実際のリソース予 約などを行うためのメッセージを生成するための手段である。また、他の通信ノードか ら受信したメッセージに関しても、このメッセージ生成'処理手段 17において処理が 行われ、リソース予約などを行うための情報(セッション IDやフィルタ情報、 QSpecなど
の情報)は、 QoS情報格納手段 23に格納される。
[0094] また、フィルタリング手段 19は、受信パケットのヘッダ (特に、フィルタ情報に対応す るパケットの送信元アドレス及びあて先アドレス)を参照して、受信パケットに対して、 QoS情報格納手段 23に格納されている QoS情報(QoSステート)に基づくパケットの フィルタリングを行う手段であり、このフィルタリングによって、各パケットに対するリソ ースが確保されるように構成されている。また、カプセルィ匕 Z脱カプセルィ匕手段 21は 、必要に応じて、送信パケットのカプセルィ匕や、受信パケットの脱カプセルィ匕を行う手 段である。
[0095] なお、後述の具体例(図 5のシーケンスチャートを参照)から分かるように、トリガ検 出手段 15は QNE123においてのみ必要であり、その他の QNEには実装されている 必要はない。また、カプセルィ匕 Z脱カプセルィ匕手段 21は、例えば、 QNE123にカプ セル化手段、 CN121に脱カプセルィ匕手段がそれぞれ実装されていればよぐその 他の QNEには、カプセルィ匕 Z脱カプセルィ匕手段 21が特に実装される必要はない。
[0096] 次に、図 5を参照しながら、本発明の第 1の実施の形態における動作について説明 する。図 5は、本発明の第 1の実施の形態における動作例を示すシーケンスチャート である。なお、ここでは具体例として、 NSISの QoS NSLPで定義されているメッセ一 ジである QUERYメッセージや RESERVEメッセージに、さらに本発明の動作に必要 な情報を付加した場合につ!、て説明する。
[0097] 図 5において、まず、 QNE (プロキシ) 123は、予測経路を確立するためのトリガを 受け取る(ステップ S201)。なお、このトリガには、例えば、 MN101と CN121との間 の QoS経路で用いられているセッション ID、 QSpec情報、 CN121 (又は経路の最終 QNEである QNR(QoS NSIS Responder) )の IPアドレスなど、予測経路を確立するた めに必要な情報が含まれている。また、 QNE (プロキシ) 123が受信するトリガの送信 元は任意の QNEであってよいが、移動を行う可能性のある MN101や、その通信相 手ノードである CN121、 MN101や CN121からの要求に応じて、 MN101や CN12 1の代理として機能する QNEが送信元となることが好適である。なお、この場合、 MN 101や CN121、代理となる QNEは、トリガのあて先に使用する QNE (プロキシ) 123 の IPアドレスを把握する必要がある力 この把握方法は、特に限定されるものではな
い。
[0098] トリガを受け取った QNE (プロキシ) 123は、即座に、このトリガに対応した QUERY メッセージを CN121に向かって送信する(ステップ S203)。この QUERYメッセージ には、例えば、セッション IDと QSpec情報とが含まれている。 QUERYメッセージは、 経路 129上において QNE (プロキシ) 123に隣接する QNE 125に到達する。 QNE1 25は、この QUERYメッセージに基づいて通常の QUERY処理(例えば、 QUERY メッセージに含まれて 、るセッション IDのリソース予約状況の確認処理など)を行うと ともに、次の隣接する QNE (QNE115)に QUERYメッセージを送信する(ステップ S 205)。 QNE115は、 QUERYメッセージを受信すると、 QUERYメッセージ内のセッ シヨン IDや、隣接する QNEの変化を検出するための情報として使われる SII (Source Identification Information)を比較することによって、自身が CRNであることを認識す る(ステップ S 207)。
[0099] QNE115は、新たな予約を行うために、「プロキシフラグ」が付加された受信者始動 RESERVEメッセージ(receiver— initiated RESERVE message)を QNE123に送信す る(ステップ S209)。この予約におけるフィルタ情報には、送信元アドレスとして QNE (プロキシ) 123の IPアドレスが含まれている(図 2の filterBに対応)。なお、ステップ S 209において QNE115から送信された RESERVEメッセージは、 QNE123まで伝 送され (ステップ S211)、各 QNE (QNE123、 125)において、 RESERVEメッセ一 ジに含まれて 、るフィルタ情報や QSpecに基づ!/、て、フィルタ/リソースの組が生成さ れて予約が行われる。なお、 QNE115においても同様に、フィルタ Zリソース(図 2の filterB/resourceA)の組が生成されて予約が行われる。
[0100] また、ステップ S209における受信者始動 RESERVEメッセージの送信と同時に、
QNE115は「プロキシフラグ」が付カ卩された送信者主導の RESERVEメッセージ(sen der- initiated RESERVE message :図 5では RESERVE(add)と記載)を CN121に送信 する(ステップ S213)。この予約におけるフィルタ情報には、送信元アドレスとして QN E (プロキシ) 123の IPアドレスが含まれている(図 2の filterBに対応)。ステップ S213 において QNE115から送信された RESERVEメッセージは、 CN121まで伝送され( ステップ S213、 S215、 S217)、各 QNE (QNE117、 119)【こお!/、て、このフイノレタ
情報が、 MN101から CN121へのデータパケットに現在使用されている現在のフィ ルタ Zリソース(図 1の filterA/resourceA)の組に追加される。
[0101] ここで、 MN101がサブネット 107に移動したとする(ステップ S219)。 QNE (プロキ シ) 123は MN101の移動を検出し、 MN101の NCoAを取得した場合 (ステップ S2 21)には、受信者始動 RESERVEメッセージを MN101に送信する(ステップ S223) 。この RESERVEメッセージに関するフィルタ情報には、送信元アドレスとして MN1 01の NCo Aが含まれて!/、る。
[0102] また、 QNE (プロキシ) 123は、 CN121あてのデータパケットを MN101から受信し た場合には、送信元アドレスが QNE (プロキシ) 123のアドレスに設定されたァウタへ ッダ(あて先アドレスは、 CN121のアドレス)を付カ卩することによって、 MN101からの データパケットのカプセル化を開始する(ステップ S225)。カプセル化されたデータ パケットは、その送信元アドレスが QNE (プロキシ) 123であり、経路 129上の各 QN Eでは、 filterBのフィルタ情報に係る QoS処理が行われ、その結果、 QoS保証を受け ることになる。
[0103] 一方、 QNE (プロキシ) 123は、サブネット 107への移動後の MN101 (すなわち、 MN101の NCoA)に関する予約を行うために、送信者主導の RESERVEメッセ一 ジ(図 5では RESERVE(add)と記載)を CN121に送信する(ステップ S227)。この予約 におけるフィルタ情報には、送信元アドレスとして MN 101の IPアドレスが含まれて!/ヽ る。そして、各 QNE (QNE125、 115、 117、 119)を経由して RESERVEメッセージ は伝送されるとともに(ステップ S229、 S231、 S233、 S235)、各 QNEにお!/、て、こ の RESERVEメッセージに含まれるフィルタ情報(図 3の filterC)力 以前に付加又は 生成されたフィルタ情報(図 2の filterB)に付加される。
[0104] RESERVEメッセージを受けた CN121は、即座に RESPONSEメッセージを QN E123に向けて送信する(ステップ S237)。この RESPONSEメッセージは、各 QNE (119、 117、 115、 125)を経由して QNE (プロキシ) 123に到達する(ステップ S239 、 241、 243、 245)。この RESPONSEメッセージの受信によって、 QNE (プロキシ) 123は MN 101の NCoAに係る QoS経路が確立された旨を認識し、 QNE (プロキシ ) 123は、データパケットのカプセル化を終了する(ステップ S247)。
[0105] さらに、 QNE123は、ステップ S209〜S217で導入された QNE (プロキシ) 123を 送信元アドレスとするフィルタ情報(図 2の filterB)を削除するために、送信者主導の R ESERVEメッセージ(図 5では RESERVE(remove)と記載)を CN121に送信する(ステ ップ S249、 S251、 S253、 S255、 S257)。なお、必ずしも RESERVEメッセージに よるフィルタ情報の削除を行う必要はなぐこのフィルタ情報は、タイマのタイムアウト によって削除されてもよい。
[0106] 以上、説明したように、本発明の第 1の実施の形態によれば、 QNE (プロキシ) 123 力 MN101のサブネット 107において割り当てられる NCoAを用いることなぐ MN1 01がサブネット 107に接続した後に使用される経路(MN101から CN121までの経 路)の一部(QNE (プロキシ) 123から CN121までの経路)に係るリソース予約を行い 、 MN101から CN121までの完全な経路が確立されるまでは、 QNE (プロキシ) 123 が確立した経路及び QoSステートによってデータパケットが行われることで、 MN101 がサブネット 103からサブネット 107に接続を変更した場合において、 MN101から C N121に送られるデータパケットの QoS保証の中断時間を低減することが可能となる
[0107] <第 2の実施の形態 >
次に、本発明の第 2の実施の形態について説明する。まず、図 6〜8を参照しなが ら、本発明の第 1の実施の形態に係る概要について説明する。図 6は、本発明の第 2 の実施の形態における通信システムで、 MNが接続するサブセットを変更する前の Q oS経路の状態を模式的に示す図である。また、図 7は、本発明の第 2の実施の形態 における通信システムで、 MNのプロキシとなる QNEが MN用に予測経路を確立し た状態を模式的に示す図である。また、図 8は、本発明の第 2の実施の形態における 通信システムで、 MNがサブセットを移動し、 MNと CNとの間で新たな QoS経路が確 立された状態を模式的に示す図である。
[0108] 図 6〜8には、図 1〜3と同様に、無線通信により ARに接続して CN121との通信を 行う MN101と、 MN101の通信相手となる CN121と、サブネット 103を形成する AR 105と、サブネット 107を形成する AR109と、 MN101と CN121との間における経路 上に存在し、 MN 101と CN 121との間で伝送されるバケツトに関して QoS保証を行う
QoS認識機能(QoS- aware)を有する QNE111、 113、 115、 117、 119、 123、 125 とが図示されている。
[0109] なお、 MN101がサブネット 103に存在している場合(すなわち、 MN101が AR10 5に接続している場合)、 CN121から MN101への downlink方向の経路 137上には、 QNE119、 QNE117、 QNE115、 QNE113、 QNE111、 AR105力存在しており、 MN101がサブネット 107に存在している場合(すなわち、 MN101が AR109に接続 している場合)、 CN121から MN101への downlink方向の経路 139上には、 QNE1 19、 QNE117, QNE115, QNE125, QNE123, AR109力存在して!/ヽるものとす る。なお、経路 137と経路 139とは一部が重複しており、経路 137と経路 139との CR Nを QNE115とする。
[0110] 図 6において、 CN121から MN101に送信されるデータパケットは、経路 137を経 由して伝送される。このとき、経路 137上のすべての QNE111、 113、 115、 117、 1 19は、 CN121から MN101に送信されるデータパケットに関する QoSステートを有 している。すなわち、各 QNE111、 113、 115、 117、 119は、経路 137のフィルタ情 報(CN121の IPアドレスがあて先アドレスとして含まれているとともに、 MN101がサ ブネット 103から割り当てられている IPアドレス(cCoA)があて先アドレスとして含まれ て!、るフィルタ情報)である filterDと、この filterDに対応するリソース予約情報である re sourceDとが関連付けられている QoSステートを保持しており、 CN121力ら MN101 に送信されるデータパケットのヘッダ (特に、送信元アドレス及びあて先アドレス)を参 照してフィルタ情報 (filterD)を特定し、対応するリソース予約情報 (resourceD)に基 づく QoS保証を行うように構成されて!ヽる。
[0111] MN101は、サブネット 107に移動する可能性があり、プロキシ 123に対して予測経 路 (経路 139)、又は予測経路の一部の確立を所望している。なお、 MN101がサブ ネット 107に移動する前に、プロキシ 123によって予測経路、又は予測経路の一部が 確立されることで、 MN101が実際にサブネット 107に移動した後に、より迅速に CN 121から MN101への QoS経路が確立され、ハンドオーバによる QoS保証の中断時 間を短縮することが可能となる。
[0112] QNE (プロキシ) 123が予測経路を確立するための何らかのトリガを受けた場合に
は、 QNE (プロキシ) 123と CRN (ここでは QNE115)との間で QoS経路が確立され る。この新たな経路が確立された場合には、 QNE (プロキシ) 123や、 QNE (プロキ シ) 123と QNE115との間の各中間 QNE (例えば、 QNE125)は、新たな QoSステ ートを有することになる。すなわち、図 7に図示されているように、 QNE (プロキシ) 12 3や QNE125では、 CNの IPアドレスが送信元アドレスとして含まれているとともに、 Q NE (プロキシ) 123の IPアドレスがあて先アドレスとして含まれて!/、るフィルタ情報 (filt erE)に対して、 filterDと同一のリソース予約情報である resourceDが設定される。
[0113] 一方、 QNE115と CN121との間の経路上の QNEに関しては、新たなフィルタ情 報(上記の filterE)が現在のフィルタ情報 (filterD)に追加される。これ〖こより、図 7に図 示されているように、 QNE115や、 QNE115と CN121との間の各中間 QNE (例え ば、 QNE117、 119)は、 filterD及び filterEに対して resourceDが設定された QoSス テートを有することになり、 filterEによって定義されるデータトラフィックには、 filterDに よって定義されるデータトラフィックのために予約された resourceDが使用可能となる。
[0114] 以上のように、 MN101がサブネット 107への移動を行う前に(あるいは、 MN101 のサブネット 107への移動とは無関係に)、 QNE (プロキシ) 123は、 MN101の NCo A (MN 101がサブネット 107に移動した後に割り当てられる新たな Co A)を用いるこ となぐ MN101がサブネット 107に接続した後に使用される経路の一部(CN121か ら QNE (プロキシ) 123までの経路)に係るリソース予約を行うことが可能となる(図 7 に図示されている状態)。
[0115] そして、 MN101が NCoAを取得した場合(実際にサブネット 107に移動して NCo Aを取得する力、あるいはサブネット 103に接続した状態で NCoAを取得した場合) 【こ ίま、図 8【こ図示されて!ヽるよう【こ、経路 139上の各中 f¾QNE (QNE123、 125、 11 5、 117、 119)において、 MN101の NCoAが送信元アドレスとして含まれているとと もに、 CN121の IPアドレスがあて先アドレスとして含まれている新たなフィルタ情報 (f ilterF)力 ¾lterD又は filterEに追加されることによって、 QoS経路の更新が行われる。 なお、 MN101がサブネット 107に移動した場合には、 filterDに関しては、能動的又 は受動的に削除されることが望ましい。また、フロー IDとは異なる情報としてフィルタ 情報が存在する場合には、フロー IDは、データパケットの送信元アドレス/あて先ァ
ドレスに依存するものでなくてもよい。
[0116] 例えば、 MN101がサブネット 107に移動して NCoAを取得した後に、 NCoAに関 する QoS経路の更新が完了(filterFに関するリソース予約が完了)する前までは、 C N121から MN101あてに送信されるデータパケットは、 filterEの情報を含むァウタへ ッダ(送信元アドレスを CN121の IPアドレスとし、あて先アドレスを QNE (プロキシ) 1 23の IPアドレスとするヘッダ)が付カ卩されて、カプセル化される。このカプセル化され たデータパケットは filterEによって識別され、各中間 QNEにおいて、 resourceDに基 づく QoS保証が行われて伝送され、 QNE (プロキシ) 123によって脱カプセル化され る。なお、 CN121が QNEの場合には、 CN121から MN101あてに送信されるデー タパケットのカプセル化は CN121で行われることが望ましいが、その他の QNE (例え ば、経路上において、 CN121の最も近くに存在する QNE119)でカプセル化が行 われてもよい。
[0117] QNE (プロキシ) 123は、 filterEで特定されるヘッダを持つパケットが到達した際に は、脱カプセル化を行ってインナパケットを取り出し、そのインナパケットを MN101に 転送する。なお、経路全体にわたって QoS予約が行われるようにするための方法とし ては、例えば IPv4最小カプセルィ匕など、上述のパケットのカプセルィ匕方法以外にも 存在することは、当業者にとって明白であり、任意のパケットのカプセルィ匕方法を本 発明に適用することが可能である。また、本発明は、他の種類のカプセル化やトンネ リング機構においても良好に動作する。
[0118] このように、 MN101の NCoAが設定されている filterFに関するリソース予約が完了 するまでは、データパケットのカプセル化が行われ、 QNE (プロキシ) 123の IPァドレ スがあて先アドレスとして設定されて 、る filterEによって、カプセル化されたデータパ ケットの QoS保証が行われるように構成されており、 MN101の NCoAを用いてリソー ス予約が行われるまでの QoS保証の中断時間を低減することが可能となる。
[0119] また、 filterFの QoSの更新に成功した後(すなわち、 filterFが経路 139上のすべて の QNEに導入された後)は、 CN121は、 filterEのデータパケットの生成(filterDのデ ータパケットのカプセル化)を終了する。そして、 filterDや filterEは能動的又は受動的 に削除され、最終的に filterFに関する QoSステートのみが残り、 CN121からサブネッ
ト 107に接続している MN101への経路 139において、 CN121から MN101へのデ ータパケットに対する QoS保証が行われる。
[0120] 次に、本発明の第 2の実施の形態における動作について説明する。図 9は、本発明 の第 2の実施の形態における動作例を示すシーケンスチャートである。なお、ここで は具体例として、上述の本発明の第 1の実施の形態と同様に、 NSISの QoS NSLP で定義されているメッセージである RESERVEメッセージに、さらに本発明の動作に 必要な情報を付加した場合について説明する。また、本発明の第 2の実施の形態に おける QNEの構成は、上述の本発明の第 1の実施の形態における QNEの構成(図 4参照)と同一であり、ここでは説明を省略する。
[0121] 図 9において、 QNE (プロキシ) 123は、 CN121力ら、サブネット 103に接続してい る MN101のデータ経路情報 (例えば、リソース稼働率など)を取得するとともに、 dow nlink方向の CRN (ここでは、 QNE115)をあらかじめ特定する(ステップ S301)。な お、例えば、 QNE (プロキシ) 123は、上述の非特許文献 9、 10などに記載されてい る方法を使用することによって、これらの情報を取得することが可能である。
[0122] そして、 QNE (プロキシ) 123は、上述の本発明の第 1の実施の形態と同様に、予 測経路を確立するための何らかのトリガを受け取る (ステップ S303)。なお、このトリガ には、上述の本発明の第 1の実施の形態と同様に、例えば、 MN101と CN121との 間の QoS経路で用いられているセッション ID、 QSpec情報、 CN121 (又は経路の最 終 QNEである QNR)の IPアドレスなど、予測経路を確立するために必要な情報が 含まれている。
[0123] トリガを受け取った QNE (プロキシ) 123は、このトリガに応じて、即座に「プロキシフ ラグ」が付加された受信者始動 RESERVEメッセージを CN121に向かって送信する (ステップ S305)。なお、この予約におけるフィルタ情報には、送信元アドレスとして C N121の IPアドレス、あて先アドレスとして QNE (プロキシ) 123の IPアドレスが含まれ ている(図 7の filterE)。また、 QNE (プロキシ) 123は、このフィルタ情報に対応したフ ィルタ Zリソース(図 7の filterE/resourceD)の組を生成して新たな予約を行う。また、 ステップ S307で QNE123から RESERVEメッセージを受けた QNE125も同様に、 このフィルタ情報に対応したフィルタ Zリソース(図 7の filterE/resourceD)の組を生成
して新たな予約を行う。
[0124] 一方、 QNE117、 QNE119、 CN121 (CN121が QNEの場合)では、 RESERV Eメッセージ(図 9では、 RESERVE(add)と記載)の伝送が行われる(ステップ S309、 S 311、 S313)とともに、この RESERVEメッセージに含まれているフィルタ情報(図 7 の filterE)力 CN121から MN101へのデータパケットに現在使用されている現在の フィルタ Zリソース(図 6の filterD/resourceD)の組に追加される。以上の動作により、 各 QNEには、図 7に図示されて 、るリソース予約情報が設定される。
[0125] なお、この QNE (プロキシ) 123から送信される RESERVEメッセージには、 CRN ( QNE 115)以降の経路において上記のようなフィルタ情報の追加処理を行う旨を示 す情報が含まれており、 QNE115が、この情報を参照して上流の QNE (QNE117) に対して追加処理を指示する RESERVEメッセージを送信してもよい。また、 QNE1 15は、 RESERVEメッセージを受信した下流の QNE (QNE125)が、同一セッション に属する経路 137とは異なる方向に存在していることから、自らが CRNであることを 把握してもよい。また、各 QNEは、リソース予約情報に、受信した RESERVEメッセ ージのフィルタ情報が属するセッションと同一セッションの他の経路(他のフィルタ情 報)を保持している場合には、元々保持しているフィルタ情報に、 RESERVEメッセ ージのフィルタ情報を追加するように構成されて 、てもよ 、。
[0126] ここで、 MN101がサブネット 107に移動したとする(ステップ S315)。 QNE (プロキ シ) 123は MN101の移動を検出し、 MN101の NCoAを取得した場合 (ステップ S3 21)には、送信者主導の RESERVEメッセージを MN 101に送信する(ステップ S32 3)。この RESERVEメッセージに関するフィルタ情報には、送信元アドレスとして CN 121のアドレスが含まれており、あて先アドレスとして MN 101の NCoAが含まれて!/ヽ る。
[0127] 一方、 CN121も、例えば MN101からの BUによって、 MN101の移動を検出して 、 MN101の NCoAを取得する(ステップ S317)。そして、 CN121は、 MN101への データパケットのカプセル化を開始する(ステップ S319)。このカプセル化では、 CN 121は、 MN101の NCoAをあて先アドレスとするパケットに、あて先アドレスが QNE (プロキシ) 123のアドレスに設定されたァウタヘッダを付カロしたパケットを生成して送
信する。カプセル化されたデータパケットは、そのあて先アドレスが QNE (プロキシ) 1 23であり、経路 129上の各 QNEでは、 filterEのフィルタ情報に係る QoS処理が行わ れ、その結果、 QoS保証を受けることになる。
[0128] ステップ S323で RESERVEメッセージを送信した後、 QNE (プロキシ) 123は、受 信者始動 RESERVEメッセージ(図 9では、 RESERVE(add)と記載)を CN121に送信 する(ステップ S325)。この予約におけるフィルタ情報には、あて先アドレスとして MN 101の IPアドレスが含まれている。そして、各 QNE (QNE125、 115、 117、 119)を 経由して RESERVEメッセージは伝送されるとともに(ステップ S327、 S329、 S331 、 S333)、各 QNEにおいて、この RESERVEメッセージに含まれるフィルタ情報(図 8の filterF)力 以前に付加又は生成されたフィルタ情報(図 7の filterE)に付加される 。以上の動作により、各 QNEには、図 8に図示されているリソース予約情報が設定さ れる。そして、 CN121は、この RESERVEメッセージを受信した場合に、データパケ ットのカプセル化を終了する(ステップ S335)。
[0129] そして、 CN121は、ステップ S305〜S313で導入された QNE (プロキシ) 123をあ て先アドレスとするフィルタ情報(図 7の filterE)を削除するために、送信者主導の RE SERVEメッセージ(図 9では RESERVE(remove)と記載)を QNE (プロキシ) 123に送 信する(ステップ S337、 S339, S341, S343, S345)。なお、必ずしも RESERVE メッセージによるフィルタ情報の削除を行う必要はなぐこのフィルタ情報は、タイマの タイムアウトによって削除されてもよい。
[0130] 以上、説明したように、本発明の第 2の実施の形態によれば、 QNE (プロキシ) 123 力 MN101のサブネット 107において割り当てられる NCoAを用いることなぐ MN1 01がサブネット 107に接続した後に使用される経路(CN121から MN101までの経 路)の一部(CN121から QNE (プロキシ) 123までの経路)に係るリソース予約を行い 、 CN121から MN101までの完全な経路が確立されるまでは、 QNE (プロキシ) 123 が確立した経路及び QoSステートによってデータパケットが行われることで、 MN101 がサブネット 103からサブネット 107に接続を変更した場合において、 CN121から M N101に送られるデータパケットの QoS保証の中断時間を低減することが可能となる
[0131] <第 3の実施の形態 >
次に、本発明の第 3の実施の形態について説明する。上述の説明ではフィルタ情 報 (filter)及びフロー IDに明確な違いがなされていないが、以下、それぞれを明確に 定義した場合の各 QNEの機能や、シグナリングメッセージの処理などにっ 、て説明 する。
[0132] まず、本発明の第 3の実施の形態におけるフィルタ情報について説明する。本発明 の第 3の実施の形態では、フィルタ情報を、各 QNEがパケットクラシファイア (packet classifier)として使用する情報として定義する。フィルタ情報は、 RSVPにおけるフィ ルタスペック(filter spec)と同様に、 QoS予約を行うためのシグナリングメッセージの パラメータとして各 QNEに運ばれる。すなわち、 NSISでは、フィルタ情報は、主に N SLPにて生成され、管理される情報となる。各 QNEは、このフィルタ情報を、要求さ れている QoSリソースの情報と共に格納することにより、どのデータパケットに対して 予約された QoSリソースを与えるかの区別を行う。そのため、フィルタ情報には、予約 された QoSの保証を受けるデータパケットのヘッダ情報が含まれる。すなわち、フィル タ情報に含まれる情報の例としては、 RSVPにおけるフィルタスペックと同様に、送信 元 ·あて先 IPアドレスや、プロトコル識別子、ポート番号、フローラベル(IPv6の場合) 、 SPI (Security Parameters Index) (IPSecでカプセル化されている場合)、 DSCPZ TO¾ (Differentiated services Code Point/Type of Service)フィ ~~ルドなどである。
[0133] また、フィルタ情報は、 1つの QoS予約に対してフィルタリスト(filter-list)の形を取つ てもよい。この場合、 1つの QoS予約に対して、 QNEは、フィルタリスト内のどのフィル タ情報と同じ内容のヘッダを持つデータパケットを受けた場合でも、予約されているリ ソースを与えることが可能となる。
[0134] フィルタリストは、このリストがどのフローやセッションに属するものかを表す識別子( 例えば、フロー IDや、セッション IDなど)と共に管理されてもよい。また、同一セッショ ンに属するデータパケットが異なる性質を持つ複数の経路 (例えば、モパイル IPにお ける三角経路と最適化経路や、マルチホーム端末を使った通信における複数の経路 など)を用いて送受信される場合には、フロー IDやセッション IDのほかに、これらの 複数の経路の種別を識別する識別子 (例えば、 Path Type ID (非特許文献 12参照)
など)と共に管理されてもょ 、。
[0135] 以下に、フィルタリストの管理方法の一例について説明する。 QoS予約を行うため のシグナリングメッセージ(例えば、 NSISの RESERVEメッセージなど)により運ばれ るフィルタリストの与え方の例として、
Filter— List ::=く List Length) <Action> <Filter> <Filter> · · · ;
などが考えられる。ここで、フィルタリストは、く List Length), < Action),及び複数の フィルタ情報(く Filter を有している。なお、く List Length〉では、フィルタリストに含ま れるフィルタ情報の個数(すなわち、く Filter〉の個数)が示される。また、く Action〉では 、各 QNEでこのフィルタリストをどのように扱うかを指定する情報が示される。例えば、 く Action〉に含まれる情報としては、「追加(add)」、「削除 (sub)」、「置き換え(Replace) 」などが考えられる。例えば、く Action〉が「追加(Add)」の場合には、その QNE上に同 一セッション ID及び Path Type ID (存在する場合)に対応する既存のフィルタリストが 存在する場合には、そのリストに後続のフィルタ情報く Filter〉が追加され、存在しない 場合には、新たにフィルタリストが作られ、それに対応するリソースが予約される。また 、例えば、く Action〉が「削除(sub)」の場合には、同一セッション ID及び Path Type ID (存在する場合)に対応する既存のフィルタリストから、後続のフィルタ情報く Filter〉だ けが削除される。また、例えば、く Action〉が「置き換え(Replace)」の場合には、 QNE 上の同一セッション ID及び Path Type ID (存在する場合)に対応する既存のフィルタ リストそのものが置き換えられる。
[0136] また、例えば、
Filter-List ::=く List Length) <Action> <Filter> <Filter> · · ·く List Length) <A ction> < Filter) < Filter) · · · ;
という形式を取ることにより、 1つのフィルタリストによって、フィルタ情報に係る複数 の変更動作を一度に行えるようにすることも可能である。例えば、ある QNEが、セッシ ヨン ID"300"、 Path Type ID"0x00"に対し、 3つのフィルタ情報(く filterl〉、〈filter2〉、 <f ilter3»を含むフィルタリスト
Filter-list := <filterl> <filter2> <filter3>;
を格納していた場合、同一セッション ID及び Path Type IDを持つ RESERVEメッセ
ージを受信し、その中に含まれるフィルタ情報が
Filter-List ::= <2> <add> <filter4> <filter5>〈1〉 <sub> <filterl>; であった場合には、この QNEに格納されるフィルタリストは、
Filter-list := <filter2> <filter3> <filter4> <filter5>;
に更新される。なお、上記のフィルタリストの形式は一例であり、 QoS予約を行うた めのシグナリングメッセージにお 、て、フィルタ情報及びそのフィルタ情報に対して行 う処理 (action)の情報が明確にできるのであれば、他の形式を取ることや、他の情報 を持つことも可能である。
[0137] 次に、本発明の第 3の実施の形態におけるフロー IDについて説明する。本発明の 第 3の実施の形態では、フロー IDは、主に NSISの下位層である NTLPで管理され、 NTLPにおいて、シグナリングメッセージがどのフローに属するかを識別するために 使われる。フロー IDとセッション IDとの違いは、セッション IDはセッションの開始から 終了まで変化しない IDであるのに対し、フロー IDは、例えば端末の移動などによる 経路変更により、変化してもよいという点にある。また、 1つのセッションに対し、複数 のフロー IDが存在してもよい。なお、本発明の第 3の実施の形態におけるフロー ID は、非特許文献 11Aでは、 MRI(Message Routing Information)として位置付けられて いるものであるが、含まれる情報はこの通りではない。本発明の第 3の実施の形態に おけるフロー IDの一例としては、シグナリングメッセージの送信元とあて先の IPァドレ スを含む情報が考えられる。なお、この場合、本発明の第 3の実施の形態におけるフ ロー IDには、非特許文献 11 Aで記されているフロー IDのように必ずしもプロトコル識 別子、ポート番号などのフィルタ情報が持つ情報が含まれる必要はない。また、デー タの送信元'あて先と、シグナリングメッセージの送信元'あて先が異なる場合や、送 信元'あて先が同じであっても、ポート番号など他のフィルタ情報が異なる場合で、シ ダナリングメッセージもデータパケットと同様に QoS保証を必要とする場合は、シグナ リングメッセージのフィルタ情報を、フィルタリストに追加すればょ 、。
[0138] また、図 17は、本発明の第 3の実施の形態において、 QNE内でフィルタ情報及び フロー IDを管理する主体を模式的に示す図である。上述のように、 NSISプロトコル 層では、フィルタ情報及びフロー IDの 2つの情報が管理される力 フィルタ情報 (フィ
ルタリスト)は、主に NSISの上位層である NSLP層において管理され、フロー IDは、 主に NSISの下位層である NTLP層において管理される。なお、フィルタ情報ゃフロ 一 IDの管理や生成に関しては、必ずしも、図 17に示されているように NSLP層や NT LP層が単独で行う必要はなく、 NSLP層と NTLP層の間で情報の交換を行ったり、 他の層と情報を交換したりすることにより管理 '生成が行われてもよい。
[0139] このように、 NSISプロトコル層において管理される情報を、フィルタ情報及びフロー IDに明確に分けて定義を行うことにより、各 QNEはデータパケットの送受信を行う端 末の情報 (例えば、データの送信元'あて先に設定される IPアドレス)を必要とするこ となぐシグナリングメッセージを送信することが可能になる。この特性を用いた QoS 経路の早期確立方法を以下に説明する。
[0140] なお、ここでは、データパケットの送信される方向が uplink方向であった場合を例に 挙げて説明を行うが、データパケットの送信される方向が downlink方向であった場合 にも同様の手順を用いることができる。
[0141] まず、図 12〜14を参照しながら、本発明の第 3の実施の形態に係る概要について 説明する。図 12は、本発明の第 3の実施の形態における通信システムで、 MNが接 続するサブセットを変更する前の QoS予約の状態及びルーティングのためのステート 内に含まれるフロー IDの状態を模式的に示す図である。また、図 13は、本発明の第 3の実施の形態における通信システムで、 MNのプロキシとなる QNEが MN用に予 測経路上にルーティングのためのステートを確立した状態を、この中に含まれるフロ 一 IDを示すことにより模式的に示す図である。また、図 14は、本発明の第 3の実施の 形態における通信システムで、 MNがサブセットを移動し、 MNと CNとの間で新たな QoS経路が確立された状態を模式的に示す図である。
[0142] 図 12〜14には、図 1〜3と同様に、無線通信により ARに接続して CN121との通信 を行う MN101と、 MN101の通信相手となる CN121と、サブネット 103を形成する A R105と、サブネット 107を形成する AR109と、 MN101と CN121との間における経 路上に存在し、 MN 101と CN 121との間で伝送されるバケツトに関して QoS保証を 行う QoS認識機能(QoS- aware)を有する QNE111、 113、 115、 117、 119、 123、 125とが図示されている。
[0143] なお、 MNIOIがサブネット 103に存在している場合(すなわち、 MN101が AR10 5に接続している場合)、 MN101から CN121への uplink方向の経路 147上には、 A R105、 QNE111、 QNE113、 QNE115、 QNE117、 QNE119力存在しており、 MNIOIがサブネット 107に存在している場合(すなわち、 MN101が AR109に接続 している場合)、 MN101から CN121への uplink方向の経路 149上には、 AR109、 QNE123, QNE125, QNE115, QNE117, QNE119力存在して!/、るものとする 。なお、経路 147と経路 149とは一部が重複しており、経路 147と経路 149との CRN を QNE115とする。
[0144] 図 12において、 MN101から CN121に送信されるデータパケットは、経路 147を 経由して伝送される。このとき、経路 147上のすべての QNE111、 113、 115、 117、 119は、 MN101から CN121に送信されるデータパケットに関する QoS予約に係る ステートを有している。すなわち、各 QNE111、 113、 115、 117、 119は、経路 147 を通して送られるデータパケットに関するフィルタ情報(CN121の IPアドレスがあて 先アドレスとして含まれているとともに、 MN101がサブネット 103から割り当てられて V、る IPアドレス(cCoA)が送信元アドレスとして含まれて 、るフィルタ情報)である filte rGを含むフィルタリストと、このフィルタリストに対応するリソース予約情報である resour ceGとが関連付けられている QoS予約に係るステートを保持しており、 CN121から M N101に送信されるデータパケットのヘッダを参照してフィルタ情報 (filterG)を特定し 、対応するリソース予約情報 (resourceG)に基づく QoS保証を行うように構成されて いる。
[0145] また同時に、各 QNE111、 113、 115、 117、 119の NTLP層では、シグナリングメ ッセージの識別とルーティングのためのステート(ルーティングステートやメッセージァ ソシエーシヨン(非特許文献 11A参照) )を保持して!/ヽる。このルーティングのための ステート内には、経路 147におけるシグナリングメッセージの送信元及びあて先を含 む情報力も作られるフロー IDが含まれる。今、シグナリングメッセージの送信元を MN 101 (cCoAを Xとする)、シグナリングメッセージのあて先を CN121 (IPアドレスを Yと する)であるとし、各 QNE111、 113、 115、 117、 119の NTLP層力 レーティングの ためのステートの中に持つフロー IDを、 flowXYとする。
[0146] MN101は、サブネット 107に移動する可能性があり、 QNE (プロキシ) 123に対し て予測経路 (経路 149)の一部の確立の準備 (すなわち、 QNE (プロキシ) 123から C N121の確立の準備)を所望している。すなわち、 MN101は、この経路上の各 QNE に対して、サブネット 107に移動した後のルーティングのためのステートをあらかじめ 保有しておくことを所望している。なお、 MN101がサブネット 107に移動する前に、 QNE (プロキシ) 123によって予測経路の一部が準備されることで、 MN101が実際 にサブネット 107に移動した後に、より迅速に CN121から MN101への QoS経路が 確立され、ハンドオーバによる QoS保証の中断時間を短縮することが可能となる。そ の理由は、ルーティングのためのステートの新規確立には複雑な処理が必要になる 力 このルーティングのためのステートはいつたん確立されてしまえば、このステート を用いてシグナリングメッセージをルーティングすることができる力 である。
[0147] QNE (プロキシ) 123が予測経路の確立を準備するための何らかのトリガを受けた 場合には、 QNE (プロキシ) 123は、 QNE (プロキシ) 123と CN121との間の QNEに おけるルーティングのためのステートの新規確立処理を始動し、その結果、 QNE (プ 口キシ) 123と CN121との間の QNEにルーティングのためのステートが保有される。 すなわち、図 13【こ図示されて!ヽるよう【こ、 QNE (プロキシ) 123、 QNE125, 115、 1 17、 119の NTLP層では、 QNE (プロキシ) 123の IPアドレス(Zとする)が送信元アド レスとして含まれて 、るとともに、 CN 121の IPアドレス(すなわち Y)があて先アドレス として含まれて 、るフロー ID (flowZY)を含むルーティングのためのステートが設定さ れる。なお、経路 147に関するルーティングのためのステートはそのまま残される。
[0148] 以上のように、 MN101がサブネット 107への移動を行う前に(あるいは、 MN101 のサブネット 107への移動とは無関係に)、 QNE (プロキシ) 123は、 MN101の NCo A (MN 101がサブネット 107に移動した後に割り当てられる新たな Co A)を用いるこ となく、 MN 101がサブネット 107に接続した後に使用される経路の一部(QNE (プロ キシ) 123から CN121までの経路)に係るルーティングのためのステートを確立する ことが可能である(図 13に図示されている状態)。
[0149] そして、 MN101が NCoAを取得した場合(実際にサブネット 107に移動して NCo Aを取得する力、あるいはサブネット 103に接続した状態で NCoAを取得した場合)
には、この MN101の NCoAをデータパケットの送信元、 CN121の IPアドレスをデー タパケットのあて先としたフィルタ情報(filterH)が作成される。そして、図 14に図示さ れているように、経路 149上の QNE (プロキシ) 123、 QNE125においては filterHを 含むフィノレタリスト力新規で格糸内されるとともに、 QNE115、 117、 119にお!/、ては、 fi IterHが既存の(同一セッション用の)フィルタリストに追加される。
[0150] また、 MN101がサブネット 107に移動した場合には、 MN101から QNE (プロキシ ) 123の間のルーティングのためのステートを確立することにより、 MN101から CN1 21までのエンド ·ツ^ ~ ·エンドのルーティングのためのステートが確立される。 MN 10 1から QNE (プロキシ) 123の間のルーティングのためのステートで使われるフロー ID は、 QNE (プロキシ) 123から CN121で使われているもの(flowZY)とは異なり、 MN1 01がサブネット 107で取得した NCoA (Wとする)をシグナリングメッセージの送信元 したフロー ID (flowWZ)であってよい。また、エンド'ツ^ ~ ·エンドのフロー IDを統一す るため、 MN101から QNE (プロキシ) 123の間のルーティングのためのステートで使 われるフロー IDは、 QNE (プロキシ) 123から CN121で使われているもの(flowZY) であってもよい。
[0151] なお、 MN101から QNE (プロキシ) 123の間のフロー ID力 QNE (プロキシ 123) 力も CN121で使われているものと異なる場合、 QNE (プロキシ) 123において、サブ ネット 107上の MN101から送信されるシグナリングメッセージに付カ卩されているフロ 一 ID (flowWZ) ¾HowZYに付け替えて、 CN 121に向けて送信するなどの動作が必要 である。また、上述のように、経路 149上に既にシグナリングメッセージのルーティン グのためのステートが存在するため、 QoSリソース予約のための動作は、 QNE (プロ キシ) 123より先では、経路 149上に新規で QoS予約のためのシグナリングメッセ一 ジを送る場合に比べて迅速に行われ、その結果、 MN101の NCoAを用いて QoSリ ソース予約が行われるまでの QoS保証の中断時間を低減することが可能となる。また 、 MN101がサブネット 107に移動した後に、移動前に使用されていたフィルタ情報( filterG)や、経路 147のルーティングのためのステートに関しては、能動的又は受動 的に削除されることが望ましい。
[0152] 次に、本発明の第 3の実施の形態における第 1動作例について説明する。図 15は 、本発明の第 3の実施の形態において、データパケットの送信方向が uplink方向の場 合の動作例を示すシーケンスチャートである。なお、ここでは具体例として、各 QNE においてルーティングのためのステートを作るために送信される、フィルタ情報を必要 としないメッセージとして、 NSISの QoS NSLPで定義されているメッセージである Q UERYメッセージに、さらに本発明の動作に必要な情報を付加した場合にっ ヽて説 明する。また、 QoSリソースを予約するためのメッセージとして、 NSISの QoS NSLP で定義されているメッセージである RESERVEメッセージに、さらに本発明の動作に 必要な情報を付加した場合について説明する。なお、本発明の第 3の実施の形態で 使用される「RESERVEメッセージ」や「QUERYメッセージ」、「RESPONSEメッセ ージ」と 、う用語は、 NSLP層で生成される情報 (メッセージのペイロード部と呼ぶ)、 NTLP層で生成される情報 (ヘッダ部と呼ぶ)及び IPヘッダ (オプション部分を含む) を含んでいる。
[0153] 図 15において、まず、 QNE (プロキシ) 123は、予測経路を準備するためのトリガを 受ける(ステップ S401)。なお、このトリガには、例えば、 MN101と CN121との間の QoS経路で用いられているセッション ID、 CN121 (又は経路の最終 QNEである QN R)の IPアドレスなど、予測経路を確立するために必要な情報が含まれて 、る。
[0154] トリガを受け取った QNE (プロキシ) 123は、このトリガに応じて、即座に、 NSLP層 において QUERYメッセージのペイロード部を生成し、 NTLP層に受け渡す。 NTLP 層ではこれを受けて、 自身をシグナリングメッセージの送信元、 CN121をあて先とし たフロー IDを生成し (ステップ S403)、このフロー IDをヘッダ部に含む QUERYメッ セージを、下位層を経由して CN121に向けて送信する(ステップ S405)。なお、この QUERYメッセージは、経路 149における新規の downstream方向(データ送信方向 と同じ方向)へのメッセージであるので、この QUERYメッセージの IPヘッダには QN E用の RAOが付けられる。
[0155] QNE (プロキシ) 123から CN121までの経路上のすべての QNE (QNE125、 115 、 117、 119)は、 QUERYメッセージを受信して IPヘッダに RAOを発見すると、 NSI S層(NSLP層及び NTLP層)において QUERYメッセージの中身を確認して、必要
な処理を行う。すなわち、 QUERYメッセージを受信した QNE 125、 115、 117、 11 9は、 QoS NSLP層における QUERY処理以外に、 NTLP層においてルーティング のためのステートの確立処理 (ルーティングステートや、メッセージアソシエーション( 要求されている場合)の確立のための処理)を行う(ステップ S407、 S411、 S415、 S 419、 S423)。その後、各 QNEは QUERYメッセージを CN121に向けて送信する( ステップ S409、 S413、 S417、 S421)。そして、 QUERYメッセージ力 SCN121に lj 達すると、この QUERYメッセージに対する RESPONSEメッセージが CN121から Q NE123に返される(ステップ S425、 S427、 S429、 S431、 S433)。
[0156] ここで、 MN101がサブネット 107に移動したとする(ステップ S435)。 MN101は、 サブネット 107より NCoAを取得すると、 NTLP層において、この NCoAをシグナリン グメッセージの送信元、 QNE (プロキシ) 123をシグナリングメッセージのあて先とした フロー IDを生成する(ステップ S437)。また、 MN101の NSLP層では、 自身の NCo Aをデータパケットの送信元、 CN121の IPアドレスをデータパケットのあて先とした情 報を含むフィルタ情報を生成し、このフィルタ情報を追カ卩 (add)して QoSリソースを予 約するような送信者主導の RESERVEメッセージ(図 15では RESERVE(add)と記載) を QNE (プロキシ) 123に向けて送信する(ステップ S439)。この RESERVEメッセ一 ジは、経路 149における MN101から QNE (プロキシ) 123に対する新規の downstre am方向(データ送信方向と同じ方向)へのメッセージであるので、この RESERVEメッ セージの IPヘッダには QNE用の RAOが付けられる。
[0157] この RESERVEメッセージを受け取った QNE (プロキシ) 123は、 NTLPにおいて ルーティングのためのステートの確立処理を行う(ステップ S441)とともに、 NSLPに おいてリソース予約のための処理を行う。また、 NTLP層ではセッション IDなどの情 報から、この RESERVEメッセージを CN121に送信する必要があることを認識し、こ の RESERVEメッセージに含まれるフロー IDの情報を、ステップ S403で生成された フロー IDに変更し、 CN121に向けて送信する(ステップ S443)。この際、 NTLPは、 メッセージを CN121に向けて送信する必要があるということを、 NSLPに伝えてもよ い。なお、この場合、ルーティングのためのステー卜は、 QNE123、 125、 115、 117 、 119に既に確立されているので、 RESERVEメッセージに RAOが付カ卩される必要
はなく、 QNE123、 125、 115、 117、 119は、受信した RESERVEメッセージを参 照してリソース予約のための処理を行 、、迅速に RESERVEメッセージを送信するこ と力 Sできる(ステップ S445、 S447、 S449、 S451)。なお、 MNIOIと、 QNE (プロキ シ) 123との間で使われるフロー IDは、 QNE (プロキシ) 123と CN121の間で使われ るフロー IDと同じであってもよい。
[0158] 次に、本発明の第 3の実施の形態の第 2動作例について説明する。上述の本発明 の第 3の実施の形態における第 1動作例では、データパケットの送信方向が uplink方 向の場合について説明した力 データパケットの送信方向が downlink方向であった 場合においても、同様の手順を採ることができる。これについて、図 16を参照しなが ら説明する。図 16は、本発明の第 3の実施の形態において、データパケットの送信方 向が downlink方向の場合の動作例を示すシーケンスチャートである。
[0159] QNE (プロキシ) 123は、予測経路を準備するためのトリガを受け取ると (ステップ S 501)、 CN121に対して、予測経路準備を依頼する依頼メッセージを送信する (ステ ップ S503)。なお、予測経路を準備するためのトリガは、 QNE (プロキシ) 123ではな く、 CN121に直接送られてもよい。この場合、トリガには、 QNE (プロキシ) 123の IP アドレスなどの情報も含まれて 、る必要がある。
[0160] 依頼メッセージ又はトリガを受信した CN121は、この依頼メッセージ又はトリガに応 じて、即座に、 NSLP層において QUERYメッセージのペイロード部を生成し、 NTL P層に受け渡す。 NTLP層ではこれを受けて、 自身をシグナリングメッセージの送信 元、 QNE (プロキシ) 123をあて先としたフロー IDを生成し (ステップ S505)、このフロ 一 IDをヘッダ部に含む QUERYメッセージを、下位層を経由して QNE (プロキシ) 1 23に向けて送信する(ステップ S507)。なお、この QUERYメッセージは、経路 149 における新規の downstream方向(データ送信方向と同じ方向)へのメッセージである ので、この QUERYメッセージの IPヘッダには QNE用の RAOが付けられる。
[0161] CN121から QNE (プロキシ) 123までの経路上のすべての QNE (QNE119、 117 、 115、 125)は、 QUERYメッセージを受信して IPヘッダに RAOを発見すると、 NSI S層(NSLP層及び NTLP層)において QUERYメッセージの中身を確認して、必要 な処理を行う。すなわち、 QUERYメッセージを受信した QNE 119、 117、 115、 12
5は、 QoS NSLP層における QUERY処理以外に、 NTLP層においてルーティング ステートのためのステート確立処理を行う(ステップ S509、 S513、 S517、 S521、 S5 25)。その後、各 QNEは、 QUERYメッセージを QNE (プロキシ) 123に向けて送信 する(ステップ S511、 S515, S519, S523)。
[0162] ここで、 MN101がサブネット 107に移動したとする(ステップ S527)。 QNE (プロキ シ) 123は、 MN101の移動を検出し、 MN101がサブネット 107より取得した NCoA 情報を取得すると、 NTLP層にお 、て自身の IPアドレスをシグナリングメッセージの 送信元、 MN101の NCoAをシグナリングメッセージのあて先としたフロー IDを生成 する(ステップ S529)。また、 QNE (プロキシ) 123の NSLP層は、 CN121の IPァドレ スをデータパケットの送信元、 MN101の NCoAをデータパケットのあて先とした情報 を含むフィルタ情報を生成し、このフィルタ情報を追カ卩 (add)して QoSリソースを予約 するような送信者主導の RESERVEメッセージ(図 16では RESERVE(add)と記載)を MN 101に向けて送信する(ステップ S 531 )とともに、 NTLP層では MN 101に転送 するデータパケットに対するルーティングのためのステートの確立処理を行う(ステツ プ S533)。
[0163] また、 QNE (プロキシ) 123は、受信者主導の RESERVEメッセージ(図 16では RE SERVE(add)と記載)を CN121に向けて送信する(ステップ S535)。なお、 MN101に 送信される RESERVEメッセージは、経路 149における QNE (プロキシ) 123力ら M N 101に対する新規の downstream方向(データ送信方向と同じ方向)へのメッセージ であるので、この RESERVEメッセージには QNE用の RAOが付けられる。しかしな がら、 CN121に送信される RESERVEメッセージに関しては、ルーティングのための ステート力 SQNE123、 125、 115、 117、 119に既に確立されて!ヽるので、この RES ERVEメッセージに RAO力 S付カロされる必要 ίまなく、 QNE125、 115、 117、 119ίま、 受信した RESERVEメッセージを参照してリソース予約のための処理を行 、、迅速に RESERVEメッセージを送信することができる(ステップ S537、 S539、 S541、 S54 3、 S545)。なお、 QNE (プロキシ) 123と MN101の間で使われるフロー IDは、 QN E (プロキシ) 123と CN121の間で使われるフロー IDと同じであってもよい。
[0164] 以上、説明したように、本発明の第 3の実施の形態における第 1及び第 2動作例に
よれば、 QNE (プロキシ) 123力 MN101のサブネット 107において割り当てられる NCo Aを用いることなぐ MN 101がサブネット 107に接続した後に使用される経路( MN101から CN121までの経路)の一部(例えば、 QNE (プロキシ) 123と CN121と の間の経路)に係る QoS予約の準備(特に、ルーティングのためのステートの確立処 理)を行うことにより、 MN101がサブネット 103から 107に接続を変更した場合にお いて、 CN121から MN101に送られるデータパケットの QoS保証の中断時間を低減 することができる。
[0165] また、上述のように、フロー ID及びフィルタリストを定義することにより、 MNのハンド オーバのケースに限らず、 QoS経路を容易に管理することができるようになる。
[0166] 例えば、 MNが、 1つのセッションに対し複数の IPアドレスを用いて CNと通信してい る場合(MNがマルチホーム状態の場合)で、どの IPアドレスも同一のサブネット配下 のものであった場合を考える。この場合、どの IPアドレスが設定されたデータパケット であっても、データパケットが通過する経路は 1つなので、各 QNEにおける NTLP層 では、 MNが持つ複数の IPアドレスのうちの 1つをフロー IDのあて先(又は送信元)ァ ドレスとして採用すればよい。なお、パケットクラシファイアとして利用されるフィルタリ ストは、上述のように複数のフィルタ情報に対応しているので、 MNが有する複数の I Pアドレスのすべてを容易に保持することが可能である。
[0167] また、 FTP (File Transfer Protocol)を用いたデータのダウンロードなどでは、ダウン ロードのスピードを上げるために、クライアントは一度に複数のポートを用いることがあ る。この場合でも、上述の MNが複数の IPアドレスを持つ場合と同様に、複数のポー ト番号のうちの 1つをフロー IDに採用すればよい。なお、フロー IDが完全に IPァドレ スの情報のみで作られるような場合には、 NTLPにおいて、ポート番号を管理する必 要はなくなる。また、上述の MNが複数の IPアドレスを持つ場合と同様に、パケットク ラシファイアとして利用されるフィルタリストは、複数のフィルタ情報に対応しているの で、複数のポート番号を容易に保持することが可能である。
[0168] また、さらに、 H. 323を用いて VoIP (Voice over IP)用のセッションを張る場合には 、この途中のプロセスにおいて、使用されるポート番号が変化する。し力しながら、こ の場合でも、上述のように、フロー ID及びフィルタリストを定義することによって、 NTL
P側ではポート番号の変化に合わせてフロー IDの情報を変える必要はなくなり、一方 、パケットクラシファイアとして利用されるフィルタリストでは、フィルタ情報の追加'削 除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる。
[0169] 次に、本発明の第 3の実施の形態の第 3動作例について説明する。データ経路 (M N101と CN121とを結ぶ経路)上に NATFWが存在する場合においても、 MN101 のハンドオーバ時に QoS保証の中断時間を低減させるシームレスな QoS保証を提 供することが望ましい。このとき、シームレスな QoS保証を提供するため、上述の本発 明の第 3の実施の形態の第 1動作例(図 15を参照)や第 2動作例(図 16を参照)と同 様に、プロキシを利用して、 NTLP層においてルーティングのためのステートの確立 処理を先に行い、端末のハンドオーバ後に QoSリソース予約を行うとともに、 NATF Wのポリシールールの追加や書き換えを行うことが望ましい。
[0170] 以下、データ経路上の QNE 117が NATFWであることを想定して、上述の本発明 の第 3の実施の形態の第 1動作例と同様に、 MN101がサブネット 103からサブネット 107にハンドオーバを行う際に、 QNE (プロキシ) 123が、 MN101のサブネット 107 において割り当てられる NCoAを用いることなぐ MN101のハンドオーバ後に使用さ れる経路の一部に係る QoS予約の準備 (特に、ルーティングのためのステートの確立 処理)を行う動作について説明する。
[0171] 図 18は、本発明の第 3の実施の形態において、データ経路上に NATFWが存在し ており、データパケットの送信方向が uplink方向の場合の動作例を示すシーケンスチ ヤートである。なお、ここでは、 QNE117が NATFW機能を持つものとし、 QNE119 及び CN121がプライベートアドレスを用いる LAN内に存在するものとする。また、 M N101、 QNE117及び CN121には NATFW NSLPが実装されているものとする。 さらに、 NATFW (QNE117)には、 NSISシグナリングメッセージがこの NATFWを 通過できるためのポリシールールが既に設定されているものとする。また、図 15に図 示されている第 1動作例と同様に、図 18に図示されているシーケンスにおいても、各 QNEにおいてルーティングのためのステートを作るために送信されるメッセージの一 例として、 NSISの QoS NSLPで定義されている QUERYメッセージを用いた場合を 例に挙げて説明する。
[0172] 図 18において、まず、 QNE (プロキシ) 123は、予測経路を準備するためのトリガを 受ける(ステップ S601)。なお、このトリガには、例えば、 MN101と CN121との間の QoS経路で用いられているセッション ID、 CN121 (又は経路の最終 QNEである QN R)の IPアドレスなど、予測経路を確立するために必要な情報が含まれて 、る。
[0173] トリガを受け取った QNE (プロキシ) 123は、このトリガに応じて、即座に、 NSLP層 において QUERYメッセージのペイロード部を生成し、 NTLP層に受け渡す。 NTLP 層ではこれを受けて、 自身をシグナリングメッセージの送信元、 CN121をあて先とし たフロー IDを生成し (ステップ S603)、このフロー IDをヘッダ部に含む QUERYメッ セージを、下位層を経由して CN121に向けて送信する(ステップ S605)。なお、この QUERYメッセージは、経路 149における新規の downstream方向(データ送信方向 と同じ方向)へのメッセージであるので、この QUERYメッセージの IPヘッダには QN E用の RAOが付けられる。
[0174] QNE (プロキシ) 123から CN121までの経路上のすべての QNE (QNE125、 115 、 117、 119)は、 QUERYメッセージを受信して IPヘッダに RAOを発見すると、 NSI S層(NSLP層及び NTLP層)において QUERYメッセージの中身を確認して、必要 な処理を行う。すなわち、 QUERYメッセージを受信した QNE 125、 115、 117、 11 9は、 QoS NSLP層における QUERY処理以外に、 NTLP層においてルーティング のためのステートの確立処理 (ルーティングステートや、メッセージアソシエーション( 要求されている場合)の確立のための処理)を行う(ステップ S607、 S611、 S615、 S 619、 S623)。その後、各 QNEは QUERYメッセージを CN121に向けて送信する( ステップ S609、 S613、 S617、 S621)。そして、 QUERYメッセージ力 SCN121に lj 達すると、この QUERYメッセージに対する RESPONSEメッセージが CN121から Q NE123に返される(ステップ S625、 S627、 S629、 S631、 S633)。
[0175] ここで、 MN101がサブネット 107に移動したとする(ステップ S635)。 MN101は、 サブネット 107より NCoAを取得すると、 NTLP層において、この NCoAをシグナリン グメッセージの送信元、 QNE (プロキシ) 123をシグナリングメッセージのあて先とした フロー IDを生成する(ステップ S637)。また、 MN101の NSLP層では、 自身の NCo Aをデータパケットの送信元、 CN121の IPアドレスをデータパケットのあて先とした情
報を含むフィルタ情報を生成する。また、 NATFW NSLP層では、このフィルタ情報 を持ったデータパケットが NATFWを通過するためのポリシールールを、 NATFW ( QNE 117)で作成できるようにするパラメータを持った CREATEメッセージ(図 18で は、 CREATEと記載)を作成する。また、 QoS NSLP層では、このフィルタ情報を追 加(add)して QoSリソースを予約するような送信者主導の RESERVEメッセージ(図 1 8では RESERVE(add)と記載)を作成する。そして、 MN10は、上記の CREATEメッ セージと RESERVEメッセージとを 1つのメッセージ(CREATE及び RESERVEメッ セージ)にして、 QNE (プロキシ) 123に向けて送信する(ステップ S639)。なお、上 記の CREATE及び RESERVEメッセージは、経路 149における MN101から QNE (プロキシ) 123に対する新規の downstream方向(データ送信方向と同じ方向)へのメ ッセージであるので、 CREATE及び RESERVEメッセージの IPヘッダには QNE用 の RAOが付けられる。
この CREATE及び RESERVEメッセージを受け取った QNE (プロキシ) 123は、 N TLPにおいてルーティングのためのステートの確立処理を行う(ステップ S641)ととも に、 NSLPにおいてリソース予約のための処理を行う。また、 NTLP層ではセッション IDなどの情報から、この CREATE及び RESERVEメッセージを CN121に送信する 必要があることを認識し、この CREATE及び RESERVEメッセージに含まれるフロ 一 IDの情報を、ステップ S603で生成されたフロー IDに変更し、 CN121に向けて送 信する(ステップ S643)。この際、 NTLPは、メッセージを CN121に向けて送信する 必要があるということを、 NSLPに伝えてもよい。なお、この場合、ルーティングのため のステート ίま、 QNE123, 125、 115、 117、 119【こ既【こ確立されて!ヽるので、 CRE ATE及び RESERVEメッセージに RAOが付カ卩される必要はなぐ QNE123、 125、 115、 117、 119は、受信した CREATE及び RESERVEメッセージの RESERVE 部分を参照してリソース予約のための処理を行 、、迅速に CREATE及び RESERV Eメッセージを送信すること力 Sできる(ステップ S645、 S647、 S651、 S653)。また、 NATFW (QNE 117)においては、この CREATE及び RESERVEメッセージの CR EATE部分を参照し、ポリシールールに変更を加える(ステップ S649)。このとき、ポ リシ一ルールにデータパケットに対するアドレス変換が含まれていた場合には、フィ
ルタリストに含まれる該当フィルタ情報の内容をプライベートアドレスに対応したもの に変更するか、又はプライベートアドレス用のフィルタ情報をリストに追加する。これに より、 QNE117と QNE119の間や、 QNE119と CN121の間における RESERVE 処理では、プライベートアドレス用に QoSリソースが予約されることとなる。なお、 MN 101と、 QNE (プロキシ) 123との間で使われるフロー IDは、 QNE (プロキシ) 123と CN121の間で使われるフロー IDと同じであってもよい。また、シグナリングメッセージ 送信側で、あら力じめプライベートアドレスの情報が分力つていた場合には、このアド レス情報をあらかじめフィルタリスト内に存在させてもよい。この場合、 NATFW(QN E 117)では、ステップ S649にお!/、てフィルタリストの内容を変換する必要はな!/、。
[0177] また、ここでは CREATEと RESERVEを同時に、 QoSシグナリング用のルーティン グのためのステートを用いて送信する例を挙げた力 このためには、複数の NSLPメ ッセージを同時に(1つのパケットとして)送信することをサポートするよう、 NSISの仕 様を変更する必要がある。また、 RESERVEメッセージと CREATEメッセージは別 々に送信されてもよいが、この場合には、 CREATEメッセージ力 RESERVEメッセ ージよりも前に送信されることが必要であり(ステップ S649で RESERVEメッセージ 内のフィルタ情報の書き換えが必要な場合があるため)、また、 NATFWシグナリング 用のルーティングのためのステートが、 QoSの場合と同様に、 QNE (プロキシ) 123を 用いてあら力じめ確立されて 、ることが望まし!/、。
[0178] また、ここでは、データパケットの送信方向が uplink方向の場合について説明したが 、データパケットの送信方向が downlink方向であった場合においても、図 16に図示さ れて 、る第 2動作例にお!、て、 RESERVEメッセージと同時に CREATEメッセージ を送信することによって同様の手順を採ることができる。
[0179] 上述の本発明の第 3の実施の形態における第 3動作例では、 NATFW(QNE117 )が、 QoS NSLPと NATFW NSLPの両方の NSLPを持っている場合について説 明を行った。この場合、フィルタリストは NSLP共通部分に存在し、各 NSLP力 フィ ルタリストを参照できるように構成してもよい。また、各 NSLPで使用されるフィルタ情 報の組み合わせが異なることも考えられるので、この場合にはフィルタリスト内の各フ ィルタ情報に対し、どの NSLPで使用されるのかを示す情報 (例えばフラグを立てる
など)を与えてもよい。
[0180] また、 NSLPごとにフィルタリストが分けられていてもよい。すなわち、 QoS NSLP るフィルタリストが用意され、各 NSLP用フィルタリストが NSLP共通部分に置かれる。
[0181] また、フィルタリストは各 NSLPに存在してもよい。この場合、各 NSLP間で、直接又 は NTLPを通じて、フィルタリストに関する情報をやり取りすることによって、フィルタリ ストの内容に整合性を持たせてもよい。例えば、 NATFWノードで〈filterA〉をく filterB 〉に書き換える指示を出す内容が NATFW NSLPに存在した場合、この情報が直接 又は NTLPを通じて QoS NSLPに送られ、これに従って、 NATFWノードの QoS N SLP内のフィルタリストに含まれるく filterA〉がく filterB〉に書き換えられる。ただし、 Qo S NSLP内のフィルタリストにあらかじめく filterB〉が存在している場合には、フィルタ 情報を書き換える必要ない。
[0182] さらに、図 17に図示されているフィルタリストの定義とは異なる力 フィルタリストを N TLPに存在させるようにしてもよい。フィルタリストが NTLPに存在する場合は、フィル タリストが NSLP共通部分に存在する場合と同様に、フィルタリスト内の各フィルタ情 報に対し、どの NSLPで使用されるのかを示す情報 (例えばフラグを立てるなど)が与 えられていてもよぐまた、 NSLPごとにフィルタリストが分けられていてもよい。
[0183] また、 NATFWノードは、 NATFW機能を実装して ヽるが、 QoS機能の実装は必 須ではないため、 NATFW NSLPのみが存在し、 QoS NSLPが存在しない NATF Wノードが存在する場合も考えられる。このような NATFWノードにおいても、 NSLP 共通部分や NTLPにフィルタリストが存在すれば、フィルタ情報の変換(図 18におけ るステップ S649の処理)を容易に行うことができる。
[0184] また、各 NSLPにフィルタリストが存在する場合でも、 NATFWノードにおける特別 な機能として、 QoS NSLPが存在しない場合であっても QoS NSLP内のフィルタリ ストの内容をチェックすることができる機能を持たせれば、フィルタ情報の変換は可能 となる。また、この場合、 QoS NSLPメッセージが NATFWノードでインタセプトされ るようにする必要がある。 QoS NSLPメッセージが NATFWノードでインタセプトされ るようにするため、ルーティングのためのステート確立以前に送信される QoS NSLP
メッセージには、例えば、 NATFW NSLP用の RAO、又は QoS NSLP及び NATF W NSLP共通(又は NSLP共通)の RAO、又は NTLPを有する NEに対する RAO ( すなわち、 NTLP用 RAO)が付加される。
[0185] さらに、 NATFWノード力 NTLPのみを実装している場合も考えられる。この場合 、 NTLPにフィルタリストが存在すれば、 NATFWノードは、フィルタ情報の変換(図 1 8におけるステップ S649の処理)を容易に行うことができる。 NSLP共通部分や各 N SLPにフィルタリストが存在する場合でも、 NATFWノードにおける特別な機能として 、 NSLP共通部分や各 NSLPに存在するフィルタリストの内容をチェックすることがで きる機能を持たせれば、フィルタ情報の変換は可能となる。また、この場合、 QoS NS LPメッセージが NATFWノードでインタセプトされるようにする必要がある。 QoS NS LPメッセージが NATFWノードでインタセプトされるようにするため、ルーティングの ためのステート確立以前に送信される QoS NSLPメッセージには、例えば、 NTLP を有する NEに対する RAO (すなわち、 NTLP用 RAO)が付加される。
[0186] また、上述のようにフロー ID及びフィルタリストを定義することにより、 MNのハンドォ ーバのケースに限らず、 NATFWノードを経由するデータ経路を容易に管理すること が可能となる。
[0187] 例えば、 MNが、 1つのセッションに対し複数の IPアドレスを用いて CNと通信してい る場合(MNがマルチホーム状態の場合)で、どの IPアドレスも同一のサブネット配下 のものであった場合を考える。この場合、どの IPアドレスが設定されたデータパケット であっても、データパケットが通過する経路は 1つなので、各 NATFW NSLPを持つ NEにおける NTLP層では、 MNが持つ複数の IPアドレスのうちの 1つをフロー IDの あて先(又は送信元)アドレスとして採用すればよい。なお、 NATFWにおいてポリシ 一ルール作成のために利用されるフィルタリストは、上述のように複数のフィルタ情報 に対応して 、るので、 MNが有する複数の IPアドレスのすべてを容易に保持すること が可能である。
[0188] また、 FTPを用いたデータのダウンロードなどでは、ダウンロードのスピードを上げ るために、クライアントは一度に複数のポートを用いることがある。この場合でも、上述 の MNが複数の IPアドレスを持つ場合と同様に、複数のポート番号のうちの 1っをフ
ロー IDに採用すればよい。なお、フロー IDが完全に IPアドレスの情報のみで作られ るような場合には、 NTLPにおいて、ポート番号を管理する必要はなくなる。また、上 述の MNが複数の IPアドレスを持つ場合と同様に、 NATFWにお!/、てポリシールー ル作成のために利用されるフィルタリストは、複数のフィルタ情報に対応しているので 、複数のポート番号を容易に保持することが可能である。
[0189] また、さらに、 H. 323を用いて VoIP用のセッションを張る場合には、この途中のプ ロセスにおいて、使用されるポート番号が変化する。し力しながら、この場合でも、上 述のように、フロー ID及びフィルタリストを定義することによって、 NTLP側ではポート 番号の変化に合わせてフロー IDの情報を変える必要はなくなり、一方、 NATFWに おいてポリシールール作成のために利用されるフィルタリストでは、フィルタ情報の追 カロ'削除が容易に行えるため、ポート番号の変化に柔軟に対応することが可能となる
[0190] また、上述の本発明の第 3の実施の形態では、フロー IDとフィルタ情報とを分けて、 別々に管理できるようにすることによって、シグナリングメッセージの通る経路に係る 処理を、データパケットの通る経路に係る処理より前に行えるようにしている力 さらに 、これを応用して、データパケットの通る経路と、シグナリングメッセージの通る経路と が異なる off-pathシグナリング(Path Decoupledシグナリングとも呼ばれる)を行うことも 可能となる。例えば、あるドメインのプロキシや、ポリシー決定ポイント(データ経路上 に存在する必要は無い)に直接シグナリングメッセージを送信し、このノードに、フィ ルタリストの内容を使用した処理 (例えば、ポリシールールの作成)を行わせることも 可能である。
[0191] なお、上述の本発明の第 1〜第 3の実施の形態では、付加的サービスが QoS保証 である場合について説明したが、その他の付加的サービスに関しても本発明は適用 可能である。また、特に、 QoS保証に関しては、 NSISに対して本発明を適用した場 合の具体例について説明した力 本発明は、その適用対象が NSISに限定されるも のではなぐさらに、本発明の機能を持たせる NSISのメッセージは、上述の一例に 限定されるものではない。
[0192] また、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的に
は集積回路である LSI (Large Scale Integration)として実現される。これらは個別に 1 チップ化されてもよいし、一部又はすベてを含むように 1チップ化されてもよい。なお、 ここでは、 LSIとした力 集積度の違いにより、 IC (Integrated Circuit)、システム LSI、 スーパー LSI、ウノレ卜ラ LSIと呼称されることもある。
[0193] また、集積回路化の手法は LSIに限るものではなぐ専用回路又は汎用プロセッサ で実現してもよい。 LSI製造後に、プログラムすることが可能な FPGA (Field Program mable Gate Array)や、 LSI内部の回路セルの接続や設定を再構成可能なリコンフィ ギュラブノレ ·プロセッサを利用してもよ 、。
[0194] さらには、半導体技術の進歩又は派生する別技術により LSIに置き換わる集積回 路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積ィ匕を行って もよい。例えば、バイオ技術の適応などが可能性としてあり得る。
産業上の利用可能性
[0195] 本発明は、移動端末がハンドオーバを行う際に、ハンドオーバ後における経路の再 設定をより迅速に行って、パケット通信の中断時間(特に、 QoS経路の中断時間)を 低減させることが可能であり、通信ネットワーク技術や、パケット伝送に係るリソース管 理の技術に適用可能である。さらに、本発明は、移動端末がハンドオーバを行う場合 に限らず、端末が 1つのセッションに対し、複数の IPアドレスや複数のポート番号を用 いて通信を行っている場合や、セッションの途中で IPアドレスやポート番号に変更が 生じる場合においても、経路 (特に、 QoS経路)の管理を容易にすることが可能であり 、通信ネットワーク技術や、パケット伝送に係るリソース予約に係るシグナリングメッセ ージのルーティング管理技術に適用可能である。