(57)【要約】  ローカルアドレスを使用するドメイン内からモバイルノードが外に移動した場合に、スタンサーバのような特別な手段を用いることなくドメイン内のモバイルノードの古いパスを破棄する技術が開示される。その技術によればＭＮ１０１とＳＡＮＥ１０３がそれぞれグループ登録要求メッセージ３００１、グループ参加要求メッセージ３００７でグループをグループサーバ２０１に登録し、ＭＮ１０１がＮＡＴドメイン１００外の新しい位置（ＭＮ１１０）に移動した場合、ＭＮ１１０はグループサーバ２０１あてのＭＮトリガメッセージ３０１１を送信し、グループサーバ２０１はＭＮ１１０からＭＮトリガメッセージ３０１１を受信すると、グループのメンバリスト内の全てのＳＡＮＥ１０３にグループトリガメッセージ３０１３を送信し、ＳＡＮＥ１０３はグループトリガメッセージ３０１３を受信して、移動前のＭＮ１０１の古いパスのステートを破棄し、また、そのリソースを解放する。
2009001553.tif 000002
【特許請求の範囲】
【請求項１】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信方法であって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録ステップと、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知するステップと、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリングステップと、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄するステップとを、
備えた通信方法。
【請求項２】
前記シグナリングステップは、
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記グループ登録ステップは、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知するステップと、
前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知するステップとを含むことを特徴とする請求項１に記載の通信方法。
【請求項４】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードとの属するグループを代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段と、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリング手段と、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えた通信システム。
【請求項５】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、
前記シグナリング手段は、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項４に記載の通信システム。
【請求項６】
前記グループ登録手段は、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知する手段と、
前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知する手段とを、
含むことを特徴とする請求項４に記載の通信システム。
【請求項７】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記モバイルノードであって、
前記モバイルノードと前記ドメイン内で前記モバイルノードのパスを確立しているノードが属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄するための前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段とを備えたモバイルノード。
【請求項８】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項７に記載のモバイルノード。
【請求項９】
前記グループ登録手段は、前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知する手段を含み、
前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知するようにしたことを特徴とする請求項７に記載のモバイルノード。
【請求項１０】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける代表サーバであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を前記代表サーバあてに送信した場合に、そのグループの情報を登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知した場合に、前記グループに属するノードあてに前記ドメイン内で確立している前記モバイルノードのパスを破棄させるシグナリングを送信するシグナリング手段とを備えた代表サーバ。
【請求項１１】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、
前記シグナリング手段は、前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項１０に記載の代表サーバ。
【請求項１２】
前記グループ登録手段は、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知し、前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知した場合に、そのグループの情報を登録することを特徴とする請求項１０に記載の代表サーバ。
【請求項１３】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記ノードであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信し、前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングした場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えたノード。
【請求項１４】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであることを特徴とする請求項１３に記載のノード。
【請求項１５】
前記グループ登録手段は、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知した場合に、前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知することを特徴とする請求項１３に記載のノード。
【請求項１６】
請求項１に記載の通信方法において、
前記グループ登録ステップは、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバに登録し、
前記シグナリングステップは、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングし、
さらに前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄するステップを、
含むことを特徴とする通信方法。
【請求項１７】
請求項４に記載の通信システムにおいて、
前記グループ登録手段は、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバに登録し、
前記シグナリング手段は、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングし、
さらに前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄する手段を、
含むことを特徴とする通信システム。
【請求項１８】
請求項１０に記載の代表サーバにおいて、
前記グループ登録手段は、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバあてに送信した場合に、そのグループの情報を登録し、
前記シグナリング手段は、前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知した場合に、前記第１及び第２の代表ノードあてのみにシグナリングして、前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄させることを特徴とする代表サーバ。
【請求項１９】
請求項１３に記載のノードにおいて、
前記グループ登録手段は、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノード、又は前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードとして前記グループの情報を前記代表サーバに登録し、
さらに、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングした場合に、前記第１又は第２の代表ノードとして、または前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードとして前記モバイルノードのパスを破棄する手段を、
含むことを特徴とするノード。
【請求項２０】
請求項１９に記載のノードにおいて、
前記第１の代表ノードは、前記モバイルノードに最も近いホップのノードであることを特徴とするノード。
【請求項２１】
請求項１９に記載のノードにおいて、
前記第１の代表ノードは、前記ドメインのエッジに設けられたネットワークアドレス変換器に最も近いホップのノードであることを特徴とするノード。
【請求項２２】
請求項１９に記載のノードにおいて、
前記第２の代表ノードは、前記ドメインのエッジに設けられたネットワークアドレス変換器に最も近いホップのノードであることを特徴とするノード。
【請求項２３】
請求項１９に記載のノードにおいて、
前記第２の代表ノードは、前記モバイルノードの通信相手のノードであることを特徴とするノード。
【請求項２４】
請求項１９に記載のノードにおいて、
前記第１及び第２の代表ノードは、前記ドメインのエッジに設けられたネットワークアドレス変換器であることを特徴とするノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ローカルアドレスを使用するドメインの境界をモバイルノードが横切る（cross）場合の通信方法、通信システム及び前記モバイルノードに関する。
また本発明は、ローカルアドレスを使用するドメイン内でモバイルノードのパスのステートを保持し、リソースを確保するノード、及び前記ノードを管理するサーバに関する。
【背景技術】
【０００２】
通信ネットワークは通常、アドレススペースが異なる複数のサブドメインに分割される。このサブドメインのローカルアドレスは、アドレス境界を跨ぐと有効ではなくなる。このため、一例として、アドレス境界にはネットワークアドレス変換器（Network Address Translator：ＮＡＴ）が設けられる。ＮＡＴの背後のノードが使用するローカルアドレスは、ＮＡＴドメインの外部のノードには見えない。ＮＡＴは、ドメイン内のノードがドメイン外のノードとの間でパケットを交換可能なようにアドレスマッピングを実行する。ここで、他の従来技術としては、下記の非特許文献１、２、３、４、５、７、８、９が開示されている。
【非特許文献１】STUN  Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy, RFC3489 HYPERLINK "http://www.ietf.org/rfc/rfc3489.txt" http://www.ietf.org/rfc/rfc3489.txt
【非特許文献２】Next Steps in Signaling (NSIS): Framework. R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. RFC4080 HYPERLINK "http://www.ietf.org/rfc/rfc4080.txt" http://www.ietf.org/rfc/rfc4080.txt
【非特許文献３】Resource ReSerVation Protocol (RSVP)  Version 1 Functional Specification. R. Braden, Ed. RFC2205 HYPERLINK "http://www.ietf.org/rfc/rfc2205.txt" http://www.ietf.org/rfc/rfc2205.txt
【非特許文献４】Multicast Address Dynamic Client Allocation Protocol (MADCAP), S. Hanna, B. Patel, M. Shah, RFC2730 HYPERLINK "http://www.ietf.org/rfc/rfc2730.txt" http://www.ietf.org/rfc/rfc2730.txt
【非特許文献５】Protocol Independent Multicast  Sparse Mode (PIM-SM): Protocol Specification (Revised), B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, RFC4601, HYPERLINK "http://www.ietf.org/rfc/rfc4601.txt" http://www.ietf.org/rfc/rfc4601.txt
【非特許文献６】NSLP for Quality-of-Service Signaling. J. Manner, G. Karagiannis, A. McDonald. Internet-Draft draft-ietf-nsis-qos-nslp-14.txt, work in progress.
【非特許文献７】Remote Authentication Dial In User Service (RADIUS): C. Rigney, A. Rubens, W. Simpson, S. Willens, RFC2138  HYPERLINK "http://www.ietf.org/rfc/rfc2138.txt" http://www.ietf.org/rfc/rfc2138.txt
【非特許文献８】Diameter Base Protocol: P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, RFC3588  HYPERLINK "http://www.ietf.org/rfc/rfc3588.txt" http://www.ietf.org/rfc/rfc3588.txt
【非特許文献９】3GPP System Architecture Evolution: Report on Technical Options and Conclusions(Release 7): 3GPP TR 23.882 V1.10.0 (2007-05)  HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/23882.htm" http://www.3gpp.org/ftp/Specs/html-info/23882.htm
【０００３】
ところで、モバイルノード（Mobile Node：ＭＮ）が移動して、接続するサブドメインが変化することがあり得る。図７はそのケースの一例を示し、ＭＮ１０１とＭＮ１１０は同じであって、ＭＮ１０１はＮＡＴドメイン１００内に位置し、ＭＮ１１０はＮＡＴドメイン１００外に移動したことを示す。ＮＡＴドメイン１００内のＭＮ１０１とＮＡＴドメイン１００外の通信相手（Correspondent Node：ＣＮ）１０７は、ＮＡＴドメイン１００内のリンク１２１、ノード（Signaling Aware Network Entity：ＳＡＮＥ）１０３、リンク１２３及びＮＡＴ１０５と、ＮＡＴドメイン１００外のリンク１２５を経由して通信セッションを有する。【０００４】
ここで、ＭＮ１０１がＮＡＴドメイン１００外の新しい位置（図のＭＮ１１０）に移動してネットワーク１１２に接続したものとする（リンク１２７、１２９）。この新しい位置では、移動後のＭＮ１１０は新しいアドレスが割り当てられ、ＮＡＴドメイン１００内のノードにはアクセスすることはできない。例えばＳＡＮＥ１０３がＮＡＴ１０５を経由してネットワーク１１２に接続していても、移動後のＭＮ１１０はＳＡＮＥ１０３にはアクセスすることはできない。この理由は、移動前のＭＮ１０１の位置では知られているＳＡＮＥ１０３のローカルアドレスは、移動後のＭＮ１１０の位置からのパケットには使用できないからである。【０００５】
ところで、移動前のＭＮ１０１の位置における通信セッションのためのシグナリングステートとリソースは、ＳＡＮＥ１０３上に割り付けられが、移動後のＭＮ１１０の位置では解放されるべきである。ここで、ソフトステート手法を用いてシグナリングステートをタイムアウトすることによりリソースを解放することができるが、それはリソースの有効利用を損なうことになる。したがって、シグナリングステートを破棄する明確なシグナリングが望ましい。しかし、前述したように、移動後の新しい位置におけるＭＮ１１０は、ＳＡＮＥ１０３にシグナリングすることができないという問題がある。【０００６】
ここで、上記問題点を解決する手法として、非特許文献１におけるスタンサーバを用いて、移動後のＭＮ１１０がＳＡＮＥ１０３にパケットを直接送ってＳＡＮＥ１０３のパブリックアドレスを得ることが考えられる。しかしながら、この解決策では、以下の要件を付加することを必要とする。第１に、ＳＡＮＥ１０３がスタンサーバをサポートすることを必要とし、また、スタンサーバはネットワーク１１２下に必要とする。また、移動前のＭＮ１０１がＳＡＮＥ１０３の新たなアドレス情報を蓄積する必要がある。さらに、移動前のＭＮ１０１が複数のセッション、すなわち複数のＳＡＮＥを有する場合には、この新たなアドレス情報のデータ量が大きくなる。さらに、この新たなアドレス情報を移動前のＭＮ１０１とＳＡＮＥ１０３の間で交換するための特別なプロトコルを必要とする。最後に、スタンサーバのようなプロトコルは、ＮＡＴのタイプによっては機能しない場合がある。例えば対称ＮＡＴ（Symmetric ＮＡＴ）のタイプがあげられる。
【発明の開示】
【０００７】
本発明は上記従来技術の問題点に鑑み、アドレス変換器によりローカルアドレスを使用するドメイン内からモバイルノードが外に移動した場合に、スタンサーバのような特別な手段を用いることなくドメイン内のモバイルノードの古いパスを破棄することができる通信方法、通信システム、モバイルノード、サーバ及びノードを提供することを目的とする。
【０００８】
本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信方法であって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録ステップと、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知するステップと、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリングステップと、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄するステップとを、
備えた構成とした。
【０００９】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードとの属するグループを代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段と、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリング手段と、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えた構成とした。
【００１０】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記モバイルノードであって、
前記モバイルノードと前記ドメイン内で前記モバイルノードのパスを確立しているノードが属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄するための前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段とを、
備えた構成とした。
【００１１】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける代表サーバであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を前記代表サーバあてに送信した場合に、そのグループの情報を登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知した場合に、前記グループに属するノードあてに前記ドメイン内で確立している前記モバイルノードのパスを破棄させるシグナリングを送信するシグナリング手段とを、
備えた構成とした。
【００１２】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記ノードであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信し、前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングした場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えた構成とした。
【００１３】
また、前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする。
さらに、前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知し、前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知することを特徴とする。
また、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバに登録し、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングし、さらに前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄することを特徴とする。
【００１４】
この構成により、ローカルアドレスを使用するドメイン内にモバイルノードが位置する場合にドメイン内のノードがモバイルノードのパスのステートを保持してリソースを確保し、モバイルノードが前記ドメインの外に移動した場合にドメイン内のノードにシグナリングして、シグナリングされたノードがドメイン内のモバイルノードの古いパスを破棄することができる。
【００１５】
本発明によれば、アドレス変換器によりローカルアドレスを使用するドメイン内からモバイルノードが外に移動した場合に、スタンサーバのような特別な手段を用いることなくドメイン内のモバイルノードの古いパスを破棄することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明に係る通信システムの第１の実施の形態を示すブロック図
【図２】図１の通信システムの動作シーケンスを示す説明図
【図３】図１のモバイルノードを詳しく示すブロック図
【図４】図１のＳＡＮＥを詳しく示すブロック図
【図５】図１のグループサーバを詳しく示すブロック図
【図６】本発明に係る通信システムの第３の実施の形態を示すブロック図
【図７】従来の通信システムを示すブロック図
【図８】図２のグループ登録（Group_Register）要求メッセージのフォーマットを示す説明図
【図９】図２のグループ登録確認（Group_Confirm）メッセージのフォーマットを示す説明図
【図１０】図８、図９のグループ情報[Group Info]のフォーマットを詳しく示す説明図
【図１１】図２のＭＮトリガ（MN_Trigger）メッセージのフォーマットを示す説明図
【図１２】図２のグループ参加（Group_Join）要求メッセージのフォーマットを示す説明図
【図１３】図２のグループ参加応答（Group Response）メッセージのフォーマットを示す説明図
【図１４】図２のグループトリガ（Group_Trigger）メッセージのフォーマットを示す説明図
【図１５】データエントリ（Srv_Group）のフォーマットを示す説明図
【図１６】図１５のメンバリスト[Member List]のフォーマットを詳しく示す説明図
【図１７】第６、第７、第８、第９の実施の形態のネットワーク構成を示すブロック図
【図１８】第６の実施の形態の動作シーケンスを示す説明図
【図１９】図１８のグループ参加（Group_Join）要求メッセージのフォーマットを示す説明図
【図２０】図１８のグループトリガ（Group_Trigger）メッセージのフォーマットを示す説明図
【図２１】第７の実施の形態の動作シーケンスを示す説明図
【図２２】図２１のＮＡＴ通知（NAT_NOTIFY）メッセージのフォーマットを示す説明図
【図２３】第８の実施の形態の動作シーケンスを示す説明図
【図２４】第９の実施の形態の動作シーケンスを示す説明図
【図２５】図２４のグループ参加（Group_Join）要求メッセージのフォーマットを示す説明図
【図２６】第１０の実施の形態のネットワーク構成を示すブロック図
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照して本発明の実施の形態について説明する。
＜第１の実施の形態＞
図１は本発明に係る通信システムの第１の実施の形態を示すブロック図である。図１において、ＮＡＴ（Network Address Translator）ドメイン１００内のＭＮ１０１とＮＡＴドメイン１００外の通信相手（Correspondent Node：ＣＮ）１０７は、ＮＡＴドメイン１００内のリンク１２１、ノード（Signaling Aware Network Entity：ＳＡＮＥ）１０３、リンク１２３及びＮＡＴ１０５と、ＮＡＴドメイン１００外のリンク１２５を経由して通信セッションを有し、通信パスが形成されている。ＳＡＮＥ１０３は、例えば非特許文献２におけるＮＳＩＳ（Next Steps In Signaling）エンティティや、非特許文献３におけるＲＳＶＰ（Resource ReSerVation Protocol）をサポートするルータである。また、当業者であれば、ＳＡＮＥ１０３は、通信セッションに関連する他のシグナリングアプリケーションをサポートするノードでもよいことは明らかである。さらに、ＭＮ１０１とＣＮ１０７がＳＡＮＥ１０３の機能を有するように構成することも可能である。また、図面の都合上、限られた数のノードしか図示されていないが、当業者であれば、より多くのノードが存在することは明らかであり、例えばＮＡＴ１０５の前後のパス上に複数のＳＡＮＥが存在する。【００１８】
ＭＮ１０１とＳＡＮＥ１０３は、ＣＮ１０７から見てＮＡＴ１０５の背後に位置してＮＡＴドメイン１００内に位置するので、ＮＡＴドメイン１００内のローカルアドレス（Addr_MN_NAT）、（Addr_SANE_NAT）がそれぞれ割り当てられている。ＭＮ１０１はローカルアドレス（Addr_MN_NAT）をＣＮ１０７あてのパケットの送信元アドレスとして使用する。ここで、ＮＡＴ１０５はＭＮ１０１のローカルアドレス（Addr_MN_NAT）を、ＮＡＴドメイン１００外でルーティング可能なパブリックアドレス（Addr_MN_Pub）にマッピングしている。【００１９】
したがって、ＮＡＴ１０５はＭＮ１０１からＣＮ１０７あてのパケットの送信元アドレスをパブリックアドレス（Addr_MN_Pub）に置き換える。ＣＮ１０７はこのパケットを受信すると、パブリックアドレス（Addr_MN_Pub）をＭＮ１０１のアドレスとする。したがって、ＣＮ１０７はこのパブリックアドレス（Addr_MN_Pub）を、ＭＮ１０１あてのパケットのあて先アドレスとして使用する。このＣＮ１０７からＭＮ１０１あてのパケットがＮＡＴ１０５に到着すると、ＮＡＴドメイン１００内のＭＮ１０１に到着するように逆のマッピングが行われて、パブリックアドレス（Addr_MN_Pub）がローカルアドレス（Addr_MN_NAT）に変換される。なお、本発明を逸脱しない限り、ＮＡＴ１０５は他のアドレスマッピングを使用してもよい。【００２０】
ＭＮ１０１とＣＮ１０７の間の通信パスが確立すると、その通信セッションに必要なサポートを提供するためのネットワーク制御シグナリングが必要となる。そのシグナリング例としては、特許文献２に示すようなサービス品質（Quality of Service：ＱｏＳ）シグナリングや特許文献３に示すようなＲＳＶＰシグナリングがある。ここで、当業者であれば、本発明を逸脱しない限り、他のシグナリングを用いることができることは明らかである。このようなシグナリングにより、ＳＡＮＥ１０３上にシグナリングステートが生成され、対応する通信セッションにネットワークリソースが割り当てられる。【００２１】
ある時点でＭＮ１０１がＮＡＴドメイン１００外の新しい位置（ＭＮ１１０）に移動して、ネットワーク１１２にリンク１２７を介して接続されたものとする。この新しい位置におけるＭＮ１１０は、新しいアドレス（Addr_MN_Nw）が割り当てられる。ネットワーク１１２はＮＡＴドメイン１００とは異なるアドレス空間（address spaces）を有するので、ＭＮ１１０はもはや、ＳＡＮＥ１０３に対してはローカルアドレス（Addr_SANE_NAT）では直接、アドレシングできない。ここで、当業者であれば、ネットワーク１１２が本実施の形態と異なる構成であっても、本発明に影響しないことは明らかである。例えば、ネットワーク１１２がＮＡＴドメイン１００と異なる他のＮＡＴドメインである場合も同様に適用可能である。【００２２】
図１では、グループサーバ２０１がネットワーク１１２に設けられている。グループサーバ２０１はグローバルなアドレシングが可能であり、したがって、移動前の位置のＭＮ１０１、ＳＡＮＥ１０３、移動後の新しい位置のＭＮ１１０は、グループサーバ２０１に対してあるアドレス又は識別子を用いて通信することができる。これは、グループサーバ２０１にグローバルＩＰアドレスやＦＱＤＮ（Fully Qualified Domain Name）を割り当てることにより実現することができる。ここで、図１ではグループサーバ２０１はＮＡＴドメイン１００外のネットワーク１１２に接続されているが、他の接続形態を用いることができる。例えばグループサーバ２０１をＮＡＴ１０５、ＳＡＮＥ１０３及び前の位置のＭＮ１０１が位置するＮＡＴドメイン１００内に配置することもできる。この構成は、本発明に影響を与えるものではない。さらに、グループサーバ２０１を分散型サーバのグループで構成することも可能である。グループサーバの例として、ＡＡＡサーバ（非特許文献７のＲＡＤＩＵＳサーバや、非特許文献８のＤＩＡＭＥＴＥＲサーバ）や非特許文献９のＰＣＲＦ（Policy and Charging Rules Function）、後述のマルチキャストサーバなどがある。【００２３】
＜動作シーケンス＞
図２は本発明の動作シーケンスの一例を示す。
（１）まず、移動前の位置のＭＮ１０１は、ＣＮ１０７と通信セッションを開始すると、グループサーバ２０１にグループ（グループＡとする）を登録する。この登録は、グループサーバ２０１に対して送信するグループ登録（Group_Register）要求メッセージ３００１で行うことができ、グループ登録要求メッセージ３００１はグループサーバ２０１のグローバルアドレスあてに送信される。ＭＮ１０１はグループサーバ２０１のグローバルアドレスをいろいろな方法で入手することができ、例えばＭＮ１０１はグループサーバ２０１のグローバルアドレスをあらかじめ持っていてもよく、また、ローカルＤＮＳ（Domain Name System）サーバに問い合わせてもよく、さらにグループサーバ２０１のプロキシを前もって知っていてそれにメッセージを送信してもよい。当業者であれば、本発明を逸脱しない限り、ＭＮ１０１が他の方法でグループサーバ２０１のグローバルアドレスを入手することができることは明らかである。【００２４】
（２）グループサーバ２０１は、ＭＮ１０１からのグループ登録要求メッセージ３００１を受信すると、この要求メッセージを認証し、成功すると、このＭＮに対し必要な情報エントリを生成する。この情報エントリは、例えばＭＮ１０１のＩＤ、グループＩＤ、セキュリティ・アソシエーション（ＳＡ）、グループのメンバリストなどを含むことができる。また、オプションとして、このプロトコルが要求する場合には、グループサーバ２０１は処理結果をグループ登録確認（Group_Confirm）メッセージ３００３でＭＮ１０１に確認する。グループ登録確認メッセージ３００３は、グループ登録がＯＫか、及びそのループを使用するための付加情報、例えばセキュリティ・アソシエーション情報などを含むようにしてもよい。【００２５】
（３）ＭＮ１０１はグループＡをグループサーバ２０１に登録すると、ＳＡＮＥ１０３あてのシグナリングメッセージ内に関連情報を埋め込む。例えばＭＮ１０１はＳＡＮＥ１０３あてのリソース予約（Reserve）メッセージ３００５内に、グループサーバ２０１のアドレス、グループＡの情報、セキュリティ・アソシエーション情報などを提供する「グループ情報要素」を含ませる。【００２６】
（４）ＳＡＮＥ１０３はＭＮ１０１からのシグナリングメッセージ、例えば予約メッセージ３００５を受信すると、そのメッセージ３００５から「グループ情報要素」を入手し、「グループ情報要素」を用いて、シグナリングされたセッションに関連するグループに参加する。この参加は、グループ参加（Group_Join）要求メッセージ３００７をグループサーバ２０１あてに送信することにより実現することができる。グループ参加要求メッセージ３００７は、受信した予約メッセージ３００５の「グループ情報要素」が指示するサーバアドレスに送信される。ＳＡＮＥ１０３はまた、グループ参加要求メッセージ３００７内に、グループ動作に必要な情報、例えばグループＡの情報、セキュリティ・アソシエーション情報などを含ませる。ここで、当業者であれば、グループ参加要求メッセージ３００７のあて先は、ＳＡＮＥ１０３から直接グループサーバ２０１あてである必要はないことを明白であり、例えば幾つかの中間手段、例えばプロキシを経由してもよい。【００２７】
（５）グループサーバ２０１はグループ参加要求メッセージ３００７を受信すると、そのメッセージ３００７をベリファイし、例えばグループＡの存在のチェック、付属のセキュリティ・アソシエーション情報のベリファイ（verification）を行う。ベリファイがＯＫの場合、グループサーバ２０１はＳＡＮＥ１０３をグループＡのメンバリストにセットする。これは、例えばグループ参加要求メッセージ３００７の送信元アドレスをグループＡのメンバリストにコピーしたり、グループ参加要求メッセージ３００７内に特別なＳＡＮＥ−ＩＤが存在したりする場合にはそのＳＡＮＥ−ＩＤを取り出すことにより実現することもできる。次にオプションとして、グループサーバ２０１はグループ参加応答（Group Response）メッセージ３００９をＳＡＮＥ１０３あてに送信して、グループ参加要求の結果を知らせる。【００２８】
（６）次に、ＭＮ１０１がＮＡＴドメイン１００外の新しい位置（ＭＮ１１０）に移動した場合、ＭＮ１１０はＳＡＮＥ１０３に到達する代わりに、グループサーバ２０１あてのＭＮトリガ（MN_Trigger）メッセージ３０１１を送信する。ＭＮ１１０はこの処理を、異なるドメイン名や新しいプリフィックスなどにより、自分の新しい位置が異なるアドレスのドメインに属することを検知して実行する。ＭＮトリガメッセージ３０１１は、グループＡの識別子、必要なセキュリティ・アソシエーション情報、ＳＡＮＥ１０３あてに送信されたシグナリングメッセージ内容などを含む。例えばＮＳＩＳ  ＱｏＳシグナリングアプリケーションがＳＡＮＥ１０３にサポートされている場合、このシグナリングメッセージは非特許文献６に記載の、予約(Reserve)メッセージ内に「破棄(tear)フラグ」がセットされたものである。【００２９】
（７）グループサーバ２０１はＭＮ１１０からＭＮトリガメッセージ３０１１を受信すると、メッセージ３０１１内に付属するセキュリティ・アソシエーション情報を用いてＭＮトリガメッセージ３０１１をベリファイする。ベリファイがＯＫの場合、グループサーバ２０１はグループＡに関連する全てのメンバリスト内のメンバ（ノード）に対して、ＭＮトリガメッセージ３０１１のシグナリングメッセージ内容を送信する。これは、メンバリスト内の全てのＳＡＮＥ１０３にグループトリガ（Group_Trigger）メッセージ３０１３を送信することにより実現することができる。ＳＡＮＥ１０３はグループトリガメッセージ３０１３内のシグナリングメッセージ内容（ＭＮトリガメッセージ３０１１）を回収して、シグナリングアプリケーション規則が定める動作を実行する。例えば移動前のＭＮ１０１の古いパスのステートを破棄し、また、そのリソースを解放する処理を実行する。【００３０】
ここで、当業者であれば、本発明を逸脱しないかぎり、さらに多くのノードを含めてもよいことは明らかである。例えば複数のＳＡＮＥがネットワーク内に存在する場合、移動前のＭＮ１０１が予約メッセージ３００５をその全てのＳＡＮＥに送信し、その全てのＳＡＮＥがグループ参加要求メッセージ３００７をグループサーバ２０１あてに送信してもよい。また、グループサーバ２０１は、これらのグループ参加要求メッセージ３００７を受信した場合に、グループトリガメッセージ３０１３を複数のＳＡＮＥに送信するようにしてもよい。【００３１】
また、当業者であれば、上記（１）のグループ登録要求メッセージ３００１、及び（２）のグループ登録確認メッセージ３００３のステップは、ＭＮ１０１が１つの場所に位置するときに１回のみでもよいことは明らかである。例えば同じＭＮ１０１が異なる経路を通る複数のセッションを用いて通信していた場合、これら複数経路上に存在するＳＡＮＥは同じグループに参加してもよい。これは、ＭＮ１０１が前の位置に関しても同じ破棄トリガを全てのＳＡＮＥに送信できるので合理的である。オプションとして、ＭＮ１０１が位置変化を検出したとき、グループ登録要求メッセージ３００１は、ＭＮトリガメッセージ３０１１の後に連結して送信してもよい。【００３２】
＜ＭＮ１０１の構成＞
図３を参照してＭＮ１０１の構成を説明する。なお、図３は本発明のＭＮ１０１の機能を実現する構成のみを示す。ＭＮ１０１は概略的には、シグナリング制御部４１１と、トランスポート機能部４１３とシグナリンググループ制御部４１５の３つの構成要素を有する。シグナリング制御部４１１は例えば前述した非特許文献２におけるＮＳＩＳ（Next Steps In Signaling）や、非特許文献３におけるＲＳＶＰ（Resource ReSerVation Protocol）のようなシグナリングアプリケーションに要求される機能を実行する。シグナリンググループ制御部４１５は前述したＭＮ１０１とグループサーバ２０１の間のグループ管理を実行する。トランスポート機能部４１３は、シグナリング制御部４１１とシグナリンググループ制御部４１５が生成するメッセージを送信する。トランスポート機能部４１３は単に、例えばＩＰ、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）を実行するものでもよい。【００３３】
インタフェース４２１はシグナリング制御部４１１とトランスポート機能部４１３を接続し、例えばＮＳＩＳなどのシグナリングアプリケーションに要求される機能を実行する。インタフェース４２３はシグナリンググループ制御部４１５とトランスポート機能部４１３を接続し、ＭＮ１０１とグループサーバ２０１の間のメッセージ交換をサポートする機能を実行する。インタフェース４２３は例えば図２（１）（６）（３）に示すように、ＭＮ１０１からのグループ登録要求メッセージ３００１とＭＮトリガメッセージ３０１１の送信と、グループサーバ２０１からのグループ登録確認メッセージ３００３の受信をサポートする。なお、これは単にＵＤＰソケットでもよく、また、より複雑なプロトコルがＭＮ１０１とグループサーバ２０１の間に必要な場合には、インタフェース４２３はそれに必要な機能を実行する。【００３４】
シグナリング制御部４１１とシグナリンググループ制御部４１５を接続するインタフェース４２５は、主要な機能として「ＭＧ生成」（MG_Create）、「ＭＧ確認」（MG_Confirm）「ＭＧトリガ」（MG_Trigger）を提供する。「ＭＧ生成」と「ＭＧトリガ」は、シグナリング制御部４１１からシグナリンググループ制御部４１５に向かい、「ＭＧ確認」はシグナリンググループ制御部４１５からシグナリング制御部４１１に向かう。【００３５】
ここでは、シグナリング制御部４１１がシグナリングセッションを開始する必要があるときにこれを「ＭＧ生成」と言い、グループがセッションに割り当てられることを要求される。シグナリンググループ制御部４１５は、「ＭＧ生成」の機能をトリガとして、自身が有効なグループを登録しているかをチェックする。グループ情報を登録していない場合、シグナリンググループ制御部４１５は、グループ登録要求メッセージ３００１を生成し、これをインタフェース４２３を介してトランスポート機能部４１３に渡す。グループ登録（Group_Register）要求メッセージ３００１のフォーマットは、例えば図８及び以下のように構成される。
Group_Register：
・グループサーバＩＤ１４０１[Group Server ID]
・ＭＮ−ＩＤ１４０３[MN ID]
・セッションＩＤ１４０５[Session ID]
・グループ情報１４０７[Group Info]
・セキュリティ・トークン１４０９[Security Token]【００３６】
グループサーバＩＤ１４０１はグループサーバ２０１のグローバルにユニークな識別子であり、例えばＦＱＤＮ（Fully Qualified Domain Name）である。ＭＮ１０１はこのグループサーバＩＤ１４０１をあらかじめ取得しているか、また、ローカルな構成、例えばＤＨＣＰ（Dynamic Host Configuration Protocol）により取得することができる。ＭＮ−ＩＤ１４０３は、グループ登録要求メッセージ３００１を送信するＭＮ１０１の識別子であり、例えばＭＮ１０１のローカルなＩＰアドレス、すなわちユーザのアドレス情報である。グループ情報１４０７は、ＭＮ１０１が希望するグループ割り当て情報を含む。例としてグループ情報１４０７[Group Info]は、図１０に示すように以下の情報を含むようにしてもよい。
Group Info：
・グループサーバＩＤ１６０１[Group Server ID]
・グループ識別子１６０３[Group Identifier]
・グループリフレッシュタイマ１６０５ [Group Refresh Timer]
・グループ参加トークン１６０７ [Group Join Token]
なお、ＭＮ１０１がグループサーバ２０１に対してグループ割り当てを依頼する場合には、グループ情報１４０７は除くことができる。セキュリティ・トークン１４０９は、グループサーバ２０１がＭＮ１０１の認証を必要とする場合にオプションとして含まれる。【００３７】
図３に戻り、トランスポート機能部４１３はグループサーバＩＤを例えばＤＮＳ queryで経由して解析してグループ登録要求メッセージ３００１の実際の送信方法を決定し、例えばグループサーバ２０１のＩＰアドレスに直接送信するか、又はプロキシ経由で送信するかを決定する。グループ登録要求メッセージ３００１がグループサーバ２０１に正常に到達すると、グループ登録確認メッセージ３００３がＭＮ１０１により受信される。トランスポート機能部４１３はグループ登録確認メッセージ３００３を受信すると、これをシグナリンググループ制御部４１５にインタフェース４２３経由で渡す。グループ登録確認（Group_Confirm）メッセージ３００３は、一例として図９及び以下のように構成される。
Group_Confirm：
・セッションＩＤ１５０１[Session ID]
・グループ情報１５０３[Group Info]
・セキュリティ・トークン１５０５[Security Token]【００３８】
セッションＩＤ１５０１はグループ登録要求メッセージ３００１と同じ構成である。ただし、グループ登録要求メッセージ３００１でＭＮ１０１が所望したグループ割り当てが提供できない場合、グループサーバ２０１は別のグループ割り当てをグループ情報１５０３に含めている。グループ情報１５０３はグループサーバ２０１により割り当てられるグループの情報を含む。【００３９】
グループ登録確認（Group_Confirm）メッセージ３００３のグループサーバＩＤ１６０１は、グループ登録要求メッセージ３００１と同様、割り当てられたグループにサービスを提供するグループサーバ２０１の識別子である。なお、プロキシ又はサーバ・バランシングが用いられる場合には、グループサーバＩＤ１６０１は、グループ登録要求メッセージ３００１が送信されたグループサーバ２０１とは異なるものでもよい。グループ識別子１６０３は、シグナリングセッションに用いられるグループに関する情報であるが、そのフォーマットはグループサーバ２０１が選択するものでよい。グループリフレッシュタイマ１６０５は、グループサーバ２０１がそのグループにサービスを提供するタイムリミットである。ここで、ＭＮ１０１はグループサーバ２０１に対してグループリフレッシュタイマ１６０５を更新する必要がある。この更新は、グループリフレッシュタイマ１６０５が満了する前にグループ登録要求メッセージ３００１をグループサーバ２０１に再送することにより実現することができる。グループ参加トークン１６０７は、ＳＡＮＥ１０３が参加したグループをグループサーバ２０１が認証するのに役立つベリファイ（verification）用のコードを提供する。【００４０】
シグナリンググループ制御部４１５はグループ情報１５０３とセキュリティ・トークン１５０５を保持して「ＭＧ確認」の機能をコールし、「ＭＧ確認」を受け取るシグナリング制御部４１１にグループ情報１５０３を渡す。シグナリング制御部４１１はグループ情報１５０３を予約メッセージ３００５に埋め込み、シグナリングセッションに送る。【００４１】
ＭＮ１０１が移動を検出すると、シグナリング制御部４１１は前のシグナリングステートを破棄することを決定し、シグナリング制御部４１１はまた、前のパスを介してＳＡＮＥ１０３にシグナリングする必要がある。そこで、シグナリング制御部４１１は「ＭＧトリガ」の機能をコールし、破棄フラグ付きの予約メッセージ３００５をシグナリンググループ制御部４１５に渡す。シグナリンググループ制御部４１５はＭＮトリガメッセージ３０１１を生成して、ＭＮトリガメッセージ３０１１内にその予約メッセージ３００５を埋め込む。このＭＮトリガメッセージ３０１１はトランスポート機能部４１３に渡され、次いでグループサーバ２０１に送信される。ＭＮトリガ（MN_Trigger）メッセージ３０１１の構成例を図１１及び以下に示す。
MN_Trigger：
・グループサーバＩＤ１７０１ [Group Server ID]
・グループ情報１７０３[Group Info]
・シグナリングメッセージ内容１７０５[Signaling Message Content]
・セキュリティ・トークン１７０７[Security Token]【００４２】
グループサーバＩＤ１７０１とグループ情報１７０３は、グループ登録確認メッセージ３００３内のグループ情報１５０３から得ることができる。シグナリングメッセージ内容１７０５は、ＳＡＮＥ１０３に渡されたシグナリングメッセージであり、例えば破棄フラグ付きの予約メッセージ３００５である。セキュリティ・トークン１７０７は、最後のグループ登録確認メッセージ３００３から取得される。【００４３】
＜ＳＡＮＥ１０３の構成＞
次に図４を参照してＳＡＮＥ１０３の構成を説明する。なお、図４は本発明のＳＡＮＥ１０３の機能を実現する構成のみを示す。ＳＡＮＥ１０３は概略的には、シグナリング制御部５１１と、トランスポート機能部５１３とシグナリンググループ制御部５１５の３つの構成要素を有する。シグナリング制御部５１１とトランスポート機能部５１３は、ＭＮ１０１のシグナリング制御部４１１とトランスポート機能部４１３と同様な機能を有する。ただし、シグナリング制御部４１１はシグナリング・イニシエータ（ＳＩ）として動作するのに対し、シグナリング制御部５１１はシグナリング転送部又はシグナリング・レスポンダ（ＳＲ）として動作する。【００４４】
シグナリング制御部５１１とシグナリンググループ制御部５１５の間のインタフェース５２５は、ＳＧ参加（SG_Join）、ＳＧ確認（SG_Confirm）、ＳＧ通知（SG_Notify）の３つの機能を実行する。「ＳＧ参加」はシグナリング制御部５１１からシグナリンググループ制御部５１５に対して行われ、「ＳＧ確認」と「ＳＧ通知」はシグナリンググループ制御部５１５からシグナリング制御部５１１に対して行われる。ただし、「ＳＧ確認」はオプションである。【００４５】
ＭＮ１０１からの例えば予約メッセージ３００５を受信すると、シグナリング制御部５１１は、シグナリングアプリケーションにより定義されている処理を実行し、さらに予約メッセージ３００５内に「グループ情報」があるかをチェックする。もし「グループ情報」がある場合、シグナリング制御部５１１は「ＳＧ参加」の機能をコールし、また、「グループ情報」をシグナリンググループ制御部５１５に渡す。「グループ情報」に基づいて、グループ参加要求メッセージ３００７がシグナリンググループ制御部５１５により生成されてトランスポート機能部５１３に渡され、グループサーバ２０１に送信される。グループ参加（Group_Join）要求メッセージ３００７は、例えば図１２及び以下のように構成される。
Group_Join：
・グループサーバＩＤ１８０１ [Group Server ID]
・ＳＡＮＥ−ＩＤ１８０３ [SANE ID]
・グループ参加トークン１８０５[Group Join Token]【００４６】
グループサーバＩＤ１８０１とグループ参加トークン１８０５は「グループ情報」から得られる。ＳＡＮＥ−ＩＤ１８０３はオプションである。例えばＳＡＮＥ１０３はＮＡＴ１０５のマッピングの後に自身のパブリックアドレスを知得している場合には、それをＳＡＮＥ−ＩＤ１８０３に挿入することができる。【００４７】
グループサーバ２０１が、オプションの応答であるグループ参加応答メッセージ３００９をＳＡＮＥ１０３に送り返す場合には、トランスポート機能部５１３はグループ参加応答メッセージ３００９をシグナリンググループ制御部５１５に渡す。グループ参加応答（Group Response）メッセージ３００９は例えば図１３及び以下のように構成される。
Group Response：
・ＳＡＮＥ−ＩＤ１９０１[SANE ID]
・グループ情報１９０３[Group Info]【００４８】
ＳＡＮＥ−ＩＤ１９０１はグループサーバ２０１により、グループ参加要求メッセージ３００７内のＳＡＮＥ−ＩＤ１８０１又はグループ参加要求メッセージ３００７の送信元アドレスをコピーすることにより挿入される。グループ情報１９０３はメッセージ３００１からコピーされる。グループ情報１９０３はまた、グループサーバ２０１が例えばグループリフレッシュタイマ１６０５などを調整するのに用いてもよいオプションである。【００４９】
グループサーバ２０１はＭＮトリガメッセージ３０１１を受信すると、グループトリガメッセージ３０１３をＳＡＮＥ１０３あてに送信する。グループトリガ（Group_Trigger）メッセージ３０１３のフォーマットは例えば図１４及び以下のように構成される。
Group_Trigger：
・ＳＡＮＥ−ＩＤ２０００１ [SANE ID]
・グループ情報２０００３[Group Info]
・シグナリングメッセージ内容２０００５[Signaling Message Content]
ＳＡＮＥ−ＩＤ２０００１はグループサーバ２０１に登録されているＳＡＮＥ１０３のアドレスであり、グループ情報２０００３とシグナリングメッセージ内容２０００５はＭＮトリガメッセージ３０１１から得られる。【００５０】
シグナリンググループ制御部５１５は、グループトリガメッセージ３０１３を受信すると、「ＳＧ通知」の機能をコールしてシグナリングメッセージ内容２０００５をシグナリング制御部５１１に渡すことにより、ＭＮ１０１の古いパスのステートの除去及びリソースの解放などの動作につなげる。【００５１】
＜グループサーバ２０１の構成＞
次に図５を参照してグループサーバ２０１の構成を説明する。なお、図５は本発明のグループサーバ２０１の機能を実現する構成のみを示す。グループサーバ２０１は概略的には、シグナリンググループ管理部６１３とトランスポート機能部６１１の２つの構成要素を有し、また、インタフェース６２１はシグナリンググループ管理部６１３とトランスポート機能部６１１の間を接続している。トランスポート機能部６１１は、グループ登録要求メッセージ３００１と、グループ参加要求メッセージ３００７とＭＮトリガメッセージ３０１１を受信すると、これらをシグナリンググループ管理部６１３に渡す。【００５２】
シグナリンググループ管理部６１３はグループ登録要求メッセージ３００１を取得すると、ＭＮ１０１のグループを生成し、また、メッセージ３００１内にグループ情報１４０７がない場合にはローカル情報ベースとしてデータエントリ２１０００（Srv_Group）を生成する。データエントリ２１０００（Srv_Group）のフォーマットは、例えば図１５及び以下のように構成される。
Srv_Group：
・グループＩＤ２１００１[Group ID]
・ＭＮ−ＩＤ２１００３[MN ID]
・セキュリティ・トークン２１００５[Security Token]
・グループリフレッシュタイマ２１００７[Group Refresh Timer]
・グループ参加トークン２１００９[Group Join Token]
・メンバリスト２１０１１[Member List]
メンバリスト２１０１１は図１６に示すように、複数のＳＡＮＥ−ＩＤ２２００１〜２２００３（ＳＡＮＥ−ＩＤ１〜ＳＡＮＥ−ＩＤｎ）により構成される。【００５３】
シグナリンググループ管理部６１３は、この後、グループ登録確認メッセージ３００３を生成してトランスポート機能部６１１に渡し、ＭＮ１０１に送信する。メッセージ３００１内にグループ情報１４０７がある場合には、シグナリンググループ管理部６１３は、メッセージ３００１内のセキュリティ・トークン１４０９のベリファイがＯＫの場合にデータエントリ２１０００（Srv_Group）をリフレッシュする。【００５４】
シグナリンググループ管理部６１３はグループ参加要求メッセージ３００７を取得すると、メッセージ３００７内にＳＡＮＥ−ＩＤ１８０３があるかをチェックする。ＳＡＮＥ−ＩＤ１８０３がある場合、シグナリンググループ管理部６１３は、対応するデータエントリ２１０００（Srv_Group）のメンバリスト２１０１１にそのＳＡＮＥ−ＩＤ１８０３を追加する。メッセージ３００７内にＳＡＮＥ−ＩＤ１８０３がない場合、シグナリンググループ管理部６１３はメッセージ３００７の送信元アドレスをメンバリスト２１０１１に追加する。シグナリンググループ管理部６１３は、この後、グループ参加応答メッセージ３００９を生成してトランスポート機能部６１１に渡し、ＳＡＮＥ１０３に送信する。【００５５】
シグナリンググループ管理部６１３はＭＮトリガメッセージ３０１１を取得すると、メッセージ３０１１からグループ情報１７０３を引き出す。シグナリンググループ管理部６１３はまた、データエントリ２１０００（Srv_Group）を同じグループＩＤ２１００１及びＭＮ−ＩＤ２１００３に配置し、次いでメンバリスト２１０１１を引き出す。メンバリスト２１０１１がある場合には、シグナリンググループ管理部６１３はグループトリガ（Group_Trigger）メッセージ３０１３を生成して、メンバリスト２１０１１内の全てのＳＡＮＥ−ＩＤ２２００１〜２２００３あてに送信する。ここで、シグナリンググループ管理部６１３は、この後、ＭＮトリガメッセージ３０１１内のローカルポリシー又は指示に基づいて、データエントリ２１０００（Srv_Group）を削除することもできる。【００５６】
ここで、当業者であれば、ＭＮ１０１がＳＡＮＥ１０３及び／又はグループサーバ２０１の機能を実行するようにしてもよいことは明らかである。また、当業者であれば、グループ参加要求メッセージ３００７は、ＳＡＮＥ１０３がグループから出るために使用してもよいことは明らかである。この場合には、例えばＳＡＮＥ１０３がグループ参加要求メッセージ３００７内のグループ参加トークン１８０５としてエラーとなる値をセットすることにより、グループサーバ２０１の記録からＳＡＮＥ１０３の情報を除去することができる。【００５７】
＜第２の実施の形態＞
第１の実施の形態では、グループサーバ２０１について説明したが、当業者であれば、本発明は仮想の分散型グループサーバについても適用することができることは明らかである。第２の実施の形態は、マルチキャスト手法を用いることにより実現することができる。第２の実施の形態では、ＭＮ１０１には、グループの代わりに、ＩＰマルチキャストグループアドレスが割り当てられる。ＭＮ１０１はこのアドレスをアウトオブバンド手法(Out of Band Methods)から使用する権利を取得する。例えばＭＮ１０１は非特許文献４に示すＭＡＤＣＡＰ（Multicast Address Dynamic Client Allocation Protocol）を用いて、マルチキャストアドレスをサーバに要求する。ＭＮ１０１が送信する予約メッセージ３００５は、ＩＰマルチキャストグループアドレスと、非特許文献５に示すＲＰ（Rendezvous Point）の２つの情報要素を有する。ＩＰマルチキャストグループアドレスは、本実施の形態においては、第１の実施の形態における「グループＩＤ」と等価であり、ＲＰは「グループサーバＩＤ」と等価である。【００５８】
ＳＡＮＥ１０３は予約メッセージ３００５を受信すると、ＰＩＭ（Protocol Independent Multicast）参加メッセージをＲＰに送信してＩＰマルチキャストグループアドレスに参加する。ＰＩＭ参加メッセージは、第１の実施の形態におけるグループ参加要求メッセージ３００７と同様な情報を含み、ＰＩＭ参加メッセージによりマルチキャスト分散ツリーを構築する。このため、ＳＡＮＥのメンバリストは中央のサーバにより維持されず、代わりに、ＲＰに対してマルチキャストをサポートする全てのルータ上にツリー情報の一部として保持される。【００５９】
したがって、新しい位置に到着したＭＮ１１０は、ＭＮトリガメッセージ３０１１をＲＰあてに送信する。ＲＰはＭＮトリガメッセージ３０１１をグループトリガメッセージ３０１３のフォーマットに変換してこれをＩＰマルチキャストグループアドレスあてに送信する。グループトリガメッセージ３０１３はマルチキャストツリーに沿って転送され、結果としてＳＡＮＥ１０３に到達する。【００６０】
＜第３の実施の形態＞
本発明はまた、マルチキャストユーザプレーンのシグナリングをサポートするために用いることができる。図６は第３の実施の形態のネットワークの構成例を示し、ＭＮ７０１、７２１は同じであってそれぞれ移動前、移動後を示す。図６において、送信元ノード７０９はＩＰトラフィックをマルチキャストグループ（M_G）あてに送信する。マルチキャストグループ（M_G）には、受信側ノード７１１（Receiver-1）、７１５（Receiver-2）及び移動前のＭＮ７０１の３つの受信側ノードが存在する。受信側ノード７１１はＳＡＮＥ７１３（ＳＡＮＥ−３）、７０７（ＳＡＮＥ−２）を経由して送信元ノード（Source）７０９に接続され、受信側ノード７１５はネットワーク・エンティティ（ＮＥ）７０３、ＳＡＮＥ７０５（ＳＡＮＥ−１）、７０７を経由して送信元ノード７０９に接続され、移動前のＭＮ７０１はＮＥ７０３、ＳＡＮＥ７０５、７０７を経由して送信元ノード７０９に接続される。【００６１】
非特許文献３のＲＳＶＰにより、ＱｏＳのためのシグナリングが３つの受信側ノード７１１、７１５、７０１から送信元ノード７０９あてにそれぞれ行われる。ここで、受信側ノード７１１がＱｏＳレベルＱ１を要求して、ＱｏＳレベルＱ１はＭＮ７０１が要求するＱｏＳレベルＱ２より高く、ＳＡＮＥ７１３、７０７がＱｏＳレベルＱ１のＱｏＳ予約ステートをインストールするものとする。ＭＮ７０１からのＱｏＳレベルＱ２のＱｏＳ予約メッセージがＳＡＮＥ７０７に到達すると、ＳＡＮＥ７０７には既にそれより高いＱｏＳ予約ステートが存在するので、ＭＮ７０１からのＱｏＳレベルＱ２のＱｏＳ予約メッセージは無視される。同様に、もし、受信側ノード７１５のＱｏＳ要求レベルＱ３がＱｏＳレベルＱ２より低い場合は、ＳＡＮＥ７０５におけるＱｏＳステートは、ＱｏＳレベルＱ２のみとなる。【００６２】
したがって、第１の実施の形態で説明した構成はこの接続例にも適用することができる。「グループ情報」を有する予約メッセージ３００５はＳＡＮＥ７０５のみにより処理される。この場合、ＳＡＮＥ７０５のみがグループ参加要求メッセージ３００７をグループサーバ７２５あてに送信する。ＭＮ７０１が新しい位置に移動してネットワーク７２３に接続した場合（図のＭＮ７２１）、ＳＡＮＥ７０５における古いパス上のＱｏＳ予約ステートは破棄されるべきである。第１の実施の形態では、グループサーバ７２５あてに送信されたＭＮトリガメッセージ３０１１は、グループトリガメッセージ３０１３に変換され、グループサーバ７２５に登録されているＳＡＮＥ７０５に送信される。これが望ましい動作である。【００６３】
この場合、第３の実施の形態では、マルチキャスト予約ステートが変化する。例えば受信側ノード７１１が移動前のＭＮ７０１の後に予約シグナリングを開始し、この場合には、ＳＡＮＥ７０７上の予約ステートが、レベルＱ２からレベルＱ１に切り替えられる。予約ステートの切り替え中は、ＳＡＮＥ７０７はグループサーバ７２５あてにメッセージを発行して登録を削除すべきである。これは、「グループ参加トークン」をエラー値にセットしたグループ参加要求メッセージ３００７をグループサーバ７２５あてに送信することにより実現することができる。【００６４】
＜第４の実施の形態＞
第４の実施の形態では、大きなネットワーク環境に適用するためには、グループ管理を最適化してグループ識別子のスペースがなくなることを防止する。これは、移動前の同じＭＮ１０１からの異なるセッションにグループを分担することにより実現することができる。例えば送信元アドレスでグループを多重化して、送信元が固有のマルチキャストグループに多重化することができる。これをサポートするには、グループサーバ２０１におけるデータエントリ（Srv_Group）に送信元アドレスの情報を追加する必要がある。さらに、「グループ情報」は送信元情報を含むべきである。この場合には、対応するＳＡＮＥは特定の送信元アドレスでグループに参加する。ＭＮ１０１は、メッセージをグループサーバ２０１に送信する際、送信元情報をそのメッセージに記述するか、又はグループサーバ２０１が、対応するＳＡＮＥに送信可能なようにワイルドカードの送信元情報を使用する。【００６５】
＜第５の実施の形態＞
第５の実施の形態では、グループサーバ２０１がユニキャストアドレスに依存する方法でメッセージを送信する必要がある場合、グループサーバ２０１はＮＡＴトラバース機能を実行することができる。例えばグループサーバ２０１が非特許文献１におけるスタンサーバの機能を実行して、ＮＡＴドメインにおけるＳＡＮＥに、ＮＡＴによって割り当てられるパブリックアドレスを通知する。グループサーバ２０１自身がＮＡＴドメイン１００内に位置する際、スタンサーバの機能を使用して、ＭＮ１０１あてのグループ登録確認メッセージ３００３を送信するのに使用するパブリックアドレスを取得する。【００６６】
＜第６の実施の形態＞
ここで、上記の第１〜第５の実施の形態では、移動前のＭＮ１０１の古いパスを確立している全てのＳＡＮＥ１０３がグループ参加（Group_Join）要求メッセージ３００７をグループサーバ２０１あてに送信し、また、グループサーバ２０１が全てのＳＡＮＥ１０３にグループトリガ（Group_Trigger）メッセージ３０１３を送信するので、メッセージ数が多い。そこで、以下に示す第６〜第９の実施の形態では、メッセージ数を減少するために、移動前のＭＮ１０１の古いパスを確立している、アドレスドメイン内外それぞれ１つのＳＡＮＥが代表ノードとしてグループ参加（Group_Join）要求メッセージをグループサーバあてに送信し、また、グループサーバがそのＳＡＮＥにのみグループトリガ（Group_Trigger）メッセージを送信するようにしている。さらに、グループトリガ（Group_Trigger）メッセージを受信した代表ノードの各ＳＡＮＥは、それぞれアドレスドメイン内外の他のノードあてに破棄メッセージを送信する。【００６７】
図１７は第６（及び第７、第８、第９）の実施の形態のネットワーク構成を示す。移動前のＭＮ８０１とＣＮ８１１との間の通信セッションは、リンク８３１、ＳＡＮＥ８０３、リンク８３３、ＳＡＮＥ８０５、リンク８３５、ＮＡＴ８０７、リンク８３７、ＳＡＮＥ８０９、リンク８３９を介して確立されている。そして、これらのノードのうち、ＭＮ８０１、ＳＡＮＥ８０３、ＳＡＮＥ８０５は、アドレスドメイン８００内、すなわちＮＡＴ８０７のプライベート側に位置し、また、ＳＡＮＥ８０９、ＣＮ８１１は、アドレスドメイン８００外、すなわちＮＡＴ８０７のパブリック側に位置している。さらに、全てのノード（ＭＮ８０１、ＳＡＮＥ８０３、ＳＡＮＥ８０５、ＳＡＮＥ８０９、ＣＮ８１１）は、ネットワーク８３０を経由してグループサーバ８２１とコネクションを有する。ここで、当業者であれば、グループサーバ８２１に対するコネクションは、図１７と異なってもよいことは明らかであり、本発明を限定しない。【００６８】
次にある時点で、ＭＮ８０１がアドレスドメイン８００の外側の位置（図のＭＮ８２３）に移動したものとする。移動先のＭＮ８２３は、ドメイン８００内で確立している移動前のＭＮ８０１のパスを破棄するためのシグナリングメッセージを全てのＳＡＮＥ８０３、８０５、８０９及びＣＮ８１１に送るために、グループサーバ８２１を使用してそのメッセージをリレーさせる。【００６９】
＜動作シーケンス＞
図１８は第６の実施の形態の動作シーケンスの一例を示す。第６の実施の形態では、移動前のＭＮ８０１から最初のホップのＳＡＮＥ８０３と、ＮＡＴ８０７から最初のホップのＳＡＮＥ８０９が代表ノードとなってグループ登録を行う。
（１）まず、移動前の位置のＭＮ８０１は、グループサーバ情報（第１の実施の形態のグループ情報[Group Info]）を取得する。このグループ情報の取得は、第１の実施の形態（図２参照）におけるグループ登録（Group_Register）要求メッセージ３００１とグループ登録確認（Group_Confirm）メッセージ３００３をやり取りすることにより実現することができる。また、他の方法として、ネットワークを介したブロードキャストアクセス制御機能や、ＩＥＥＥ８０２．２１ function [6] の情報サービスを使用してＭＮ８０１がグループ情報を取得することもできる。【００７０】
（２）次に、ＭＮ８０１はこの取得したグループ情報を、ＣＮ８１１に対するセッション確立用のシグナリングメッセージ、例えばＭＮシグナリング（MN_SIG）メッセージ９００３内に埋め込んで送信する。なお、ＭＮシグナリング（MN_SIG）メッセージ９００３は、ＭＮ８０１が発行するリソース予約メッセージ３１０５（図２）や、ＣＮ８１１がこのリソース予約メッセージを受信して送り返すリソース応答メッセージでもよい。ＭＮシグナリング（MN_SIG）メッセージ９００３はシグナリング・ホップカウンタを含む。このホップカウンタは、ＭＮシグナリング（MN_SIG）メッセージ９００３が通過するＳＡＮＥ毎にインクリメントされる。例えばＭＮ８０１でホップカウンタが「０」にセットされたＭＮシグナリング（MN_SIG）メッセージ９００３が送信され、ＳＡＮＥ８０３がこのメッセージ９００３を受信すると、メッセージ９００３内のホップカウンタを「１」にインクリメントして、次のＳＡＮＥ８０５あてのＭＮシグナリング（MN_SIG）メッセージ９００９内にセットして送信し、以下同様にしてホップカウンタがＳＡＮＥ毎にインクリメントされる。また、ＳＡＮＥ８０３はこのインクリメントしたホップカウンタ値をストアする。【００７１】
（３）ＳＡＮＥ８０３はメッセージ９００３を受信するとホップカウンタ値（＝０）をチェックして、自身がＭＮ８０１からの第１ホップのＳＡＮＥであると認識し、グループ情報[Group Info]が示すグループサーバ８２１にこれを登録する。図１８では、ＳＡＮＥ８０３はこの登録を、グループサーバ８２１に送信するグループ参加（Group_Join）要求メッセージ９００５で行う。グループ参加（Group_Join）要求メッセージ９００５は、第１の実施の形態で説明した各情報（図１２参照）により構成されるが、オプションとして、ＭＮシグナリング（MN_SIG）メッセージ９００３で用いられているメッセージルーティング情報、例えば非特許文献２で定義されているフロー識別子を含んでもよい。
（４）また、オプションとして、グループサーバ８２１は、上記の登録を確認するグループ参加応答（Group Response）メッセージ９００７を返信する。【００７２】
（５）次に、ＳＡＮＥ８０３はメッセージルーティング情報に基づいて、ＭＮシグナリング（MN_SIG）メッセージ９００９を次のホップのＳＡＮＥ８０５に送信する。このとき、送信前に必要な更新、例えばホップカウンタ値のインクリメントを行っておく。
（６）ＳＡＮＥ８０５はメッセージ９００９内のホップカウンタ値（＝１）により最初のホップのノードでないことを認識し、上記の（３）におけるグループサーバ８２１への登録を行う必要はない。このため、ＳＡＮＥ８０５は必要な更新、例えばホップカウンタ値をインクリメントした後、ＭＮシグナリング（MN_SIG）メッセージ９０１１を次のホップのＳＡＮＥ８０９に送信する。【００７３】
（７）ＳＡＮＥ８０９はメッセージ９０１１を受信すると、ＮＡＴ８０７の存在を検知する。このＮＡＴ８０７検知は単に、メッセージ９０１１のパケット内のＩＰヘッダと、メッセージ９０１１内に埋め込まれているメッセージルーティング情報を比較することにより実現することができる。例えばＩＰヘッダの送信元アドレスがメッセージルーティング情報の送信元アドレスが異なる場合、メッセージ９０１１はＮＡＴ８０７を通過したことを示すからである。なお、ＮＡＴ８０７はメッセージ９０１１をインタセプトできる場合、アドレス境界を横切った（cross）ことを示す特別な情報をメッセージ９０１１内に挿入してもよい。【００７４】
ＳＡＮＥ８０９は、受信したメッセージ９０１１内の「グループ情報」を用いて、自身をグループサーバ８２１に登録する。図１８では、ＳＡＮＥ８０９はこの登録を、グループサーバ８２１に送信するグループ参加（Group_Join）要求メッセージ９０１３で行う。このメッセージ９０１３のフォーマットは、例えば図１９及び以下のように構成される。
Group_Join：
・グループサーバＩＤ２３００１ [Group Server ID]
・ＳＡＮＥ−ＩＤ２３００３ [SANE ID]
・グループ参加トークン２３００５[Group Join Token]
・ホップカウンタ値２３００７[Hop Counter]
・メッセージルーティング情報２３００９[(Optional)Message Routing Information]【００７５】
すなわち、このメッセージ９０１３は、第１の実施の形態（図１２）のグループ参加（Group_Join）要求メッセージ３００７内の情報の他に、受信したＭＮシグナリング（MN_SIG）メッセージ９０１１内に埋め込まれているホップカウンタ値２３００７を含む。また、オプションとしてＳＡＮＥ８０９は、ステートなし（stateless）モードで動作する場合、メッセージ９０１３内にメッセージルーティング情報２３００９を含ませてもよい。【００７６】
（８）グループサーバ８２１はオプションとして、上記の登録を確認するグループ参加応答（Group Response）メッセージ９０１５を返信する。
（９）ＳＡＮＥ８０９は、ＭＮシグナリング（MN_SIG）メッセージ９０１７をＣＮ８１１あてに送信する。このとき、送信前にメッセージ９０１７内の必要な更新を行っておく。この更新は、ホップカウンタ値２３００７のインクリメントと、メッセージルーティング情報２３００９を新しいアドレスにマッチさせる処理を含む。ＣＮ８１１は受信したメッセージ９０１７を終端する。【００７７】
（１０）ＭＮ８０１が新しい位置（ＭＮ８２３）に移動すると、ＭＮ８２３は元のパス上のＳＡＮＥにシグナリングするために、グループサーバ８２１あてにＭＮトリガ（MN_Trigger）メッセージ９０１９を送信する。このメッセージ９０１９は第１の実施の形態におけるＭＮトリガ（MN_Trigger）メッセージ３０１１と同じ内容を含む。【００７８】
（１１）（１２）グループサーバ８２１はＭＮトリガ（MN_Trigger）メッセージ９０１９を受信すると、自身が登録しているＳＡＮＥをチェックする。この例では、ＳＡＮＥ８０３、８０９が登録されている。グループサーバ８２１は、受信したメッセージ９０１９をグループトリガ（Group_Trigger）メッセージ９０２１、９０２３に変換し、登録されているＳＡＮＥ８０３、８０９にそれぞれ送信する。このメッセージ９０２１、９０２３のフォーマットは、例えば図２０及び以下のように構成される。
Group_Trigger：
・ＳＡＮＥ−ＩＤ２４００１ [SANE ID]
・グループ情報２４００３[Group Info]
・シグナリングメッセージ内容２４００５[Signaling Message Content]
・ホップカウンタ２４００７[Hop Counter]
・メッセージルーティング情報２４００９[(Optional)Message Routing Information]【００７９】
すなわち、このメッセージ９０２１、９０２３は、第１の実施の形態におけるグループトリガ（Group_Trigger）メッセージ３０１３内に含まれる情報（図１４）の他に、ＳＡＮＥ８０９により送信されたホップカウンタ値２４００７を含む。さらに、もし、ＳＡＮＥ８０３、８０９がそれぞれグループ参加（Group_Join）要求メッセージ９００５、９０１３内にメッセージルーティング情報２３００９を含ませた場合には、メッセージルーティング情報２４００９として、ホップカウンタ値２４００７とともにグループトリガ（Group_Trigger）メッセージ９０２１、９０２３内に含まれなければならない。【００８０】
（１３）（１４）ＳＡＮＥ８０３、８０９はそれぞれ、メッセージ９０２１、９０２３を受信すると、メッセージ９０２１、９０２３からシグナリングメッセージ内容２４００５を取り出す。そして、ＳＡＮＥ８０３、８０９は、移動前のＭＮ１０１の古いパスのステートを破棄し、また、そのリソースを解放する処理を実行する。また、ＳＡＮＥ８０３、８０９はそれぞれ、ＳＡＮＥ８０５、ＣＮ８１１に移動前のＭＮ１０１の古いパスのステートを破棄させ、また、そのリソースを解放させるために、ストアしているメッセージルーティング情報を用いて、オンパス（on-path）シグナリングメッセージであるＭＮメッセージ（MN_MSG）９０２５、９０２７をＣＮ８１１の方向に送信する。【００８１】
また、ＳＡＮＥ８０３、８０９はＭＮメッセージ（MN_MSG）９０２５、９０２７を送信する際に、受信したグループトリガ（Group_Trigger）メッセージ９０２１、９０２３内のホップカウンタ値２４００７と、ストアしているホップカウンタ値を比較する。ここでは、ＳＡＮＥ８０３は、受信したメッセージ９０２１内のホップカウンタ値２４００７の方が大きいので、ＭＮメッセージ（MN_MSG）９０２５を送信する際に、メッセージ９０２５の転送範囲であるホップリミット数をセットする。このホップリミット数は、受信した方とストアしている方のホップカウンタ値の差分から計算される。例えば受信した方のホップカウンタ値２４００７が３、ストアしている方のホップカウンタ値が１の場合には、ホップリミット数＝２にセットされ、ＭＮメッセージ（MN_MSG）９０２５は２回のホップで終了する。【００８２】
他の方法として、ＳＡＮＥ８０３は単に、受信したグループトリガ（Group_Trigger）メッセージ９０２１内のホップカウンタ値２４００７を「ホップカウンタリミット数」としてＭＮメッセージ（MN_MSG）９０２５内に埋め込むとともに、ＭＮメッセージ（MN_MSG）９０２５内のホップカウンタ値を、ストアしているホップカウンタ値にセットする。そして、ＳＡＮＥ８０５は、受信したＭＮメッセージ（MN_MSG）９０２５内のホップカウンタ値を更新し、その更新した値と「ホップカウンタリミット数」が等しい場合にＭＮメッセージ（MN_MSG）９０２５の上流への転送を停止する。ここで、当業者であれば、ＭＮメッセージ（MN_MSG）９０２５のホップリミット数は他の方法を用いてもよく、本発明を限定しないことは明らかである。【００８３】
グループサーバ８２１からグループトリガ（Group_Trigger）メッセージ９０２３を受信したＳＡＮＥ８０９は、受信したホップカウンタ値２４００７が、ストアしているホップカウンタ値より小さい場合、ＭＮメッセージ（MN_MSG）９０２７のホップリミット数を処理する必要はなく、このメッセージ９０２７はＣＮ８１１により終端される。【００８４】
ここで、ＳＡＮＥ８０３、８０９は、ステートなし（stateless）の場合、すなわちいかなるシグナリングステートも維持しない場合、ＳＡＮＥ８０３、８０９の識別子と各メッセージルーティング情報２３００９をグループ参加（Group_Join）要求メッセージ９００５、９０１３内に含ませる必要がある。この情報２３００９は、グループサーバ８２１がグループトリガ（Group_Trigger）メッセージ９０２１、９０２３を送信するときに含まれる。ＳＡＮＥ８０３、８０９は、グループトリガ（Group_Trigger）メッセージ９０２１、９０２３を受信すると、ＭＮメッセージ（MN_MSG）９０２５、９０２７を構成する際に、この識別子をチェックして各メッセージルーティング情報２３００９を使用する。ＳＡＮＥ８０３、８０９の識別子は、識別可能なユニークな値でよく、例えばＭＡＣアドレスや十分に大きくランダムな値でよい。【００８５】
＜第７の実施の形態＞
図２１は第７の実施の形態として、図１７に示したネットワーク構成における他の動作シーケンスの一例を示す。第７の実施の形態では、ＮＡＴ８０７から最初のホップのＳＡＮＥ８０９、８０５が代表ノードとなってグループ登録を行う。
（１）まず、移動前の位置のＭＮ８０１は、図１８（１）と同様にグループサーバ情報（第１の実施の形態のグループ情報[Group Info]）を取得する。
（２）次に、ＭＮ８０１は、この取得したグループ情報を、ＣＮ８１１に対するセッション確立用のシグナリングメッセージ、例えばＭＮシグナリング（MN_SIG）メッセージ１０００３内に埋め込んで送信する。ここで、このＭＮシグナリング（MN_SIG）メッセージ１０００３は、図１８（２）のメッセージ９００３と同様であるが、ホップカウンタは不要である。【００８６】
（３）ＳＡＮＥ８０３はこのメッセージ１０００３を受信すると、通常の対応処理を実行し、必要な更新を行った後、ＭＮシグナリング（MN_SIG）メッセージ１０００５を次のホップのＳＡＮＥ８０５に転送する。もし、このメッセージ１０００５がリソース予約メッセージの場合には、ＳＡＮＥ８０３は、要求されたリソースをこの予約メッセージのセッションに割り当てる。
（４）ＳＡＮＥ８０５においても同じ処理が行われ、また、ＭＮシグナリング（MN_SIG）メッセージ１０００７がＮＡＴ８０７を経由してＳＡＮＥ８０９に送信される。【００８７】
（５）ＳＡＮＥ８０９はこのメッセージ１０００７を受信すると、ＮＡＴ８０７の存在を知得する。これは、受信したパケットのＩＰヘッダと、メッセージ１０００７内に埋め込まれているメッセージルーティング情報をチェックすることにより実現することができる。例えば、このＩＰヘッダとメッセージルーティング情報が異なる送信元アドレスを示している場合、ＳＡＮＥ８０９と前のホップのＳＡＮＥ８０５の間にＮＡＴが存在することを意味する。ＳＡＮＥ８０９はこれにより、グループ参加（Group_Join）要求メッセージ１０００９をグループサーバ８２１に送信することでグループ登録を行う。
（６）ＳＡＮＥ８０９はグループサーバ８２１から、オプションであるグループ参加応答（Group Response）メッセージ１００１１を受信する。【００８８】
グループ参加（Group_Join）要求メッセージ１０００９とグループ参加応答（Group Response）メッセージ１００１１は、第１の実施の形態（図１２、図１３）と同じ構成でよいが、ＳＡＮＥ８０９がステートレスの場合には、グループ参加（Group_Join）要求メッセージ１０００９はさらに、ＳＡＮＥ識別子と、ＮＡＴ外フラグと、更新されたメッセージルーティング情報を含むようにしてもよい。これらの特別な情報はグループサーバ８２１にストアされる。【００８９】
（７）次に、ＳＡＮＥ８０９は必要な更新を行った後、例えばメッセージルーティング情報を適合化した後、ＭＮシグナリング（MN_SIG）メッセージ１００１３をＣＮ８１１あてに送信する。このメッセージ１００１３はＣＮ８１１により終端される。
（８）ＳＡＮＥ８０９はまた、ＮＡＴ通知（NAT_NOTIFY）メッセージ１００１５をＳＡＮＥ８０５に送り返す。このメッセージ１００１５はＳＡＮＥ８０５に対し、ＳＡＮＥ８０５とＳＡＮＥ８０９の間にＮＡＴが存在することを通知するためのメッセージであり、そのフォーマットを図２２及び以下に示す。
NAT_NOTIFY：
・グループ情報２５００１[Group Info]
・ＮＡＴフラグ２５００３[NAT Flag]
・メッセージルーティング情報２５００５[Message Routing Information]【００９０】
グループ情報２５００１は第１の実施の形態と同じである。ＮＡＴフラグ２５００３はＮＡＴ８０９の存在を示し、メッセージルーティング情報２５００５は、ＳＡＮＥ８０５がステートレスで動作する場合のためのオプションである。メッセージルーティング情報２５００５は、ＮＡＴドメイン８００内で使用されている情報、すなわちＳＡＮＥ８０５から受信したＭＮシグナリング（MN_SIG）メッセージ１０００７の情報である。【００９１】
（９）（１０）ＳＡＮＥ８０５はＮＡＴ通知（NAT_NOTIFY）メッセージ１００１５を受信すると、グループ情報２５００１が示すグループサーバ８２１に登録を行う。この登録は、第１の実施の形態と同様にグループ参加（Group_Join）要求メッセージ１００１７とグループ参加応答（Group Response）メッセージ１００１９により行われる。ＳＡＮＥ８０５がステートレスで動作する場合、グループ参加（Group_Join）要求メッセージ１００１７はＳＡＮＥ識別子と、ＮＡＴ内フラグと、メッセージルーティング情報を含む。【００９２】
（１１）ＭＮ８０１が新しい位置（ＭＮ８２３）に移動すると、ＭＮ８２３は元のパス上のＳＡＮＥにシグナリングするために、グループサーバ８２１あてにＭＮトリガ（MN_Trigger）メッセージ１００２１を送信する。このメッセージ１００２１は第１の実施の形態におけるＭＮトリガ（MN_Trigger）メッセージ３０１１と同じ内容を含む。【００９３】
（１２）（１３）グループサーバ８２１はＭＮトリガ（MN_Trigger）メッセージ１００２１を受信すると、受信したメッセージ１００２１をグループトリガ（Group_Trigger）メッセージ１００２３、１００２５に変換し、登録されているＳＡＮＥ８０５、８０９にそれぞれ送信する。このメッセージ１００２３、１００２５のフォーマットは第１の実施の形態と同じであるが、オプションとしてＳＡＮＥ識別子と、ＮＡＴ内フラグ又はＮＡＴ外フラグと、メッセージルーティング情報を含むようにしてもよい。【００９４】
（１４）（１５）ＳＡＮＥ８０５、８０９はグループトリガ（Group_Trigger）メッセージ１００２３、１００２５をそれぞれ受信すると、第６の実施の形態と同様にメッセージ１００２３、１００２５をそれぞれオンパス（on-path）シグナリングメッセージであるＭＮメッセージ（MN_MSG）１００２７、１００２９に変換する。そして、ＮＡＴドメイン８００内のノードであるＳＡＮＥ８０５は、このメッセージ１００２７を移動前のＭＮ８０１の方向に転送し、また、ＮＡＴドメイン８００外のノードであるＳＡＮＥ８０９は、このメッセージ１００２９をＣＮ８１１の方向に転送する。このとき、ＳＡＮＥ８０５、８０９はメッセージ１００２７、１００２９の転送方向を、ストアしているシグナリングステータスに基づいて決定する。【００９５】
ＳＡＮＥ８０５、８０９は、ステートレスモードで動作する場合、グループ参加（Group_Join）要求メッセージ１００１７、１０００９内に必要な情報、例えばＮＡＴ内フラグ又はＮＡＴ外フラグと、メッセージルーティング情報と、ＳＡＮＥ識別子などを含ませる。グループサーバ８２１は、この情報をグループトリガ（Group_Trigger）メッセージ１００２３、１００２５内に含ませる。したがって、ステートレスモードのＳＡＮＥ８０５、８０９は、このメッセージ１００２３、１００２５をそれぞれ受信すると、この情報を用いて、ＭＮメッセージ（MN_MSG）１００２７、１００２９をルーティングさせるためのメッセージルーティング情報を生成する。この動作では、ＭＮメッセージ（MN_MSG）１００２７、１００２９は、自然に終端されるので、ホップリミット数を設ける必要はない。【００９６】
＜第８の実施の形態＞
図２３は第８の実施の形態として、第６、第７の実施の形態の変形例の動作シーケンスの一例を示す。第８の実施の形態では、移動前のＭＮ８０１から最初のホップのＳＡＮＥ８０３が、また、ドメイン８００外ではＣＮ８１１（またはＳＡＮＥ８０９）が代表ノードとなる。
（１）まず、移動前の位置のＭＮ８０１は、図１８、図２１の（１）と同様にグループサーバ情報（第１の実施の形態のグループ情報[Group Info]）を取得する。【００９７】
（２）次に、ＭＮ８０１は、この取得したグループ情報を、ＣＮ８１１に対して例えばＭＮシグナリング（MN_SIG）メッセージ１１００３を送信する。ここで、このＭＮシグナリング（MN_SIG）メッセージ１１００３内には、第６の実施の形態のホップカウンタの他に以下の情報が埋め込まれる。
・ＮＡＴが検出されたか否かを示すＮＡＴフラグ
・ＮＡＴドメイン８００内のＳＡＮＥ８０３、８０５がグループサーバ８２１に登録しているか否かを示すインサイドフラグ
・ＮＡＴドメイン８００外のＳＡＮＥ８０９がグループサーバ８２１に登録しているか否かを示すアウトサイドフラグ【００９８】
なお、ＭＮ８０１は、どのＳＡＮＥがグループサーバ８２１に登録するかを示す判断基準を示すポリシーをメッセージ１１００３内に含めてもよい。また、ＭＮ８０１は、メッセージ１１００３を送信するときに、これらのＮＡＴフラグと、インサイドフラグとアウトサイドフラグをリセットする。この場合、メッセージ１１００３を受信したＳＡＮＥは、自身のローカル情報とメッセージ１１００３内の上記のポリシーに基づいて、自身をグループサーバ８２１に登録するか否かを決定することができる。ＮＡＴフラグと、インサイドフラグとアウトサイドフラグがセットされていない場合、そのＳＡＮＥは、自身のローカル情報と上記のポリシーが許可するときに自身をグループサーバ８２１に登録する。また、インサイドフラグとＮＡＴフラグがセットされ、かつアウトサイドフラグがセットされていない場合、そのＳＡＮＥは、自身をグループサーバ８２１に登録する。それ以外のＳＡＮＥは、自身をグループサーバ８２１に登録してはならない。【００９９】
（３）例えばＳＡＮＥ８０３は、メッセージ１１００３内の上記の３つのフラグが全てセットされていないので、自身のローカル情報と上記のポリシーが許可するときに自身をグループサーバ８２１に登録すると決定する。そして、登録を決定したＳＡＮＥ８０３は、グループ参加（Group_Join）要求メッセージ１１００５をグループサーバ８２１に送信する。
（４）次に、ＳＡＮＥ８０３は、グループサーバ８２１から、オプションであるグループ参加応答（Group Response）メッセージ１１００７を受信する。要求メッセージ１１００５と応答メッセージ１１００７は第６、第７の実施の形態と同様なメッセージである。【０１００】
（５）次に、ＳＡＮＥ８０３は、必要な更新を行った後、ＭＮシグナリング（MN_SIG）メッセージ１１００９を次のホップのＳＡＮＥ８０５に転送する。この更新とは、ＳＡＮＥ８０３がグループサーバ８２１に登録したので、インサイドフラグのセットを含む。
（６）ＳＡＮＥ８０５は、必要な更新を行った後、ＭＮシグナリング（MN_SIG）メッセージ１１０１１を次のホップに転送する。ここで、ＳＡＮＥ８０５は、ＳＡＮＥ８０３からのメッセージ１１００９内のインサイドフラグがセットされているので、グループサーバ８２１には登録を行わない。【０１０１】
（７）ＳＡＮＥ８０９は、ＳＡＮＥ８０５からのメッセージ１１０１１を受信すると、第６、第７の実施の形態と同様にＮＡＴ８０７の存在を検出する。これにより、ＳＡＮＥ８０９は、次のホップに転送するＭＮシグナリング（MN_SIG）メッセージ１１０１３内のＮＡＴフラグをセットする。さらに、ＳＡＮＥ８０９は、ＳＡＮＥ８０５から受信したメッセージ１１０１１内のホップカウンタ値を、次のホップに転送するメッセージ１１０１３内にＮＡＴカウンタとして挿入する。ここで、ＳＡＮＥ８０９は、自身のローカル条件と、ＳＡＮＥ８０５から受信したメッセージ１１０１１内のポリシーが許可する場合にグループサーバ８２１に登録することができる。しかし、この例では、ポリシーでは「ＣＮ８１１が登録する」と示されているので、ＳＡＮＥ８０９は登録を行わないものとする。【０１０２】
（８）ＣＮ８１１は、ＳＡＮＥ８０９からのメッセージ１１０１３を受信すると、メッセージ１１０１３内のＮＡＴフラグとインサイドフラグはセットされているが、アウトサイドフラグがセットされていないことを知得し、グループサーバ８２１に登録を行う。ＣＮ８１１は、この登録をグループ参加（Group_Join）要求メッセージ１１０１５をグループサーバ８２１に送信することにより行う。ＣＮ８１１は、要求メッセージ１１０１５内にＮＡＴカウンタを含ませる。ＣＮ８１１はさらに、ホップカウンタ値をインクリメントし、また、それをストアする。
（９）次に、ＣＮ８１１は、グループサーバ８２１から、オプションであるグループ参加応答（Group Response）メッセージ１１０１７を受信する。要求メッセージ１１０１５と応答メッセージ１１０１７は第６、第７の実施の形態と同様なメッセージである。【０１０３】
（１０）ＭＮ８０１が新しい位置（ＭＮ８２３）に移動すると、ＭＮ８２３は第６、第７の実施の形態と同様に、元のパス上のＳＡＮＥにシグナリングするために、グループサーバ８２１あてにＭＮトリガ（MN_Trigger）メッセージ１１０１９を送信する。
（１１）（１２）グループサーバ８２１は、受信したメッセージ１１０１９をグループトリガ（Group_Trigger）メッセージ１１０２１、１１０２３に変換し、登録されているＳＡＮＥ８０３、ＣＮ８１１にそれぞれ送信する。このメッセージ１１０２１、１１０２３は、第６、第７の実施の形態と同じ情報の他に、ＮＡＴカウンタを含む。【０１０４】
（１３）ＳＡＮＥ８０３は、グループトリガ（Group_Trigger）メッセージ１１０２１を受信すると、第６、第７の実施の形態と同様に、このメッセージ１１０２１をＭＮメッセージ（MN_MSG）１１０２５に変換する。但し、ＳＡＮＥ８０３は、このＭＮメッセージ（MN_MSG）１１０２５をＣＮ８１１の方向と、元の位置のＭＮ８０１の方向の両方に送信する。また、ＳＡＮＥ８０３は、ＮＡＴドメイン８００内に位置するので、第６の実施の形態と同様に、ＣＮ８１１の方向のメッセージ１１０２５にはホップリミットを行う。このホップリミット数の計算は、グループトリガ（Group_Trigger）メッセージ１１０２１内のＮＡＴカウンタに基づいて行う。【０１０５】
（１４）ＣＮ８１１は、グループトリガ（Group_Trigger）メッセージ１１０２３を受信すると、ＮＡＴドメイン８００外に位置するので、このメッセージ１１０２３をＭＮメッセージ（MN_MSG）１１０２７に変換し、元の位置のＭＮ８０１の方向に送信する。このメッセージ１１０２７を送信する際、ＣＮ８１１は、ホップリミットをかける。このホップリミット数の計算は、グループトリガ（Group_Trigger）メッセージ１１０２３内のＮＡＴカウンタと、ストアしていたホップカウンタ値に基づいて行う。例えばＭＮメッセージ（MN_MSG）１１０２７内のホップリミット数はホップカウンタ値−ＮＡＴカウンタ−１で計算する。【０１０６】
ＭＮメッセージ（MN_MSG）１１０２７を受信した各ＳＡＮＥ、例えばＳＡＮＥ８０９はこのホップリミット数をデクリメントし、この更新したホップリミット数を次のホップあてのＭＮメッセージにセットしてこのＭＮメッセージを元の位置のＭＮ８０１の方向に転送する。ＳＡＮＥ８０９は、上記のデクリメント後のホップリミット数が０であることを知得すると、次のホップのノードにはＭＮメッセージを送信しない。【０１０７】
ここで、当業者であれば、ＮＡＴドメイン８００の外側で登録されるＳＡＮＥはＣＮ８１１でない場合もあり得ることは明らかである。もし、ＳＡＮＥ８０９が登録されている場合には、ＳＡＮＥ８０９は、グループトリガ（Group_Trigger）メッセージ１１０２３を受信すると、このメッセージ１１０２３をＭＮメッセージ（MN_MSG）に変換し、ＣＮ８１１の方向にも送信しなければならない。また、ＮＡＴドメイン８００の外側のＳＡＮＥ８０９は、このＣＮ８１１の方向に送信するＭＮメッセージ（MN_MSG）には、ホップリミットを設ける必要はない。【０１０８】
上記の第８の実施の形態では例外がある。例えばＮＡＴドメイン８００内のいずれのＳＡＮＥもグループサーバ８２１に登録しなかった場合、移動前のＭＮ８０１が送信したＭＮシグナリング（MN_SIG）メッセージ１１００３は、インサイドフラグがセットされないままでＣＮ８１１により受信される。この場合には、ＣＮ８１１が同じパスの逆方向にシグナリングメッセージを送信して、どのＳＡＮＥが登録すべきかを指示する必要がある。この指示は、ホップカウンタ値を用いることにより実現することができる。また、他の方法として、ＣＮ８１１は、ＮＡＴドメイン８００内の同じパスの逆方向における最初のＳＡＮＥが登録すべきであることをポリシー内に記述することにより指示することができる。【０１０９】
上記の第８の実施の形態では、移動前のＭＮ８０１の古いパスのステートを破棄し、また、そのリソースを解放するためのＭＮメッセージ（MN_MSG）１１０２５、１１０２７の転送範囲は、ホップカウンタ値を用いることにより実現している。ここで、不安定なネットワーク環境では、セッション期間中に再ルーティングが発生するので、ホップカウンタ値は再ルーティング後には各ＳＡＮＥで変化する。したがって、ネットワークが不安定であるとＭＮ８０１、８２３、ＳＡＮＥ８０３、８０５、８０９が決定した場合、何かの安全対策が必要である。安全対策の例として、移動前のＭＮ８０１はＭＮシグナリング（MN_SIG）メッセージ１１００３で、ＳＡＮＥ８０３に特別な対策が必要であること、例えばＭＮメッセージ（MN_MSG）１１０２５を作成する際に「ＮＡＴドロップフラグ」を含むように指示することができる。ＳＡＮＥ８０５は、ＭＮメッセージ（MN_MSG）１１０２５内の「ＮＡＴドロップフラグ」を知得して、メッセージ１１０２５がＮＡＴ８０７まで届いたことを検出すると、メッセージ１１０２５をドロップする。また、他の方法として、ＮＡＴ８０７自身がメッセージ１１０２５をインタセプトして、「ＮＡＴドロップフラグ」を知得した場合にはメッセージ１１０２５をドロップしてもよい。【０１１０】
＜第９の実施の形態＞
図２４は第９の実施の形態の動作シーケンスの一例を示す。ここで、ＮＡＴ８０７自身がＳＡＮＥであり、代表ノードとなる（なお、ＳＡＮＥ８０３は登録を行うが、取り消される。）。すなわち、ＮＡＴ８０７は全てのシグナリングメッセージをインタセプトして処理することができる。第９の実施の形態における動作は、第６、第７、第８の実施の形態の全てに適用することができるので、以下の説明では、重複する動作について説明を省略する。但し、ＮＡＴ８０７はシグナリングメッセージを処理するために特別な機能が必要である。【０１１１】
（１）〜（４）第６、第７、第８の実施の形態と同様に、ＮＡＴドメイン８００内のＳＡＮ８０３は、グループ参加（Group_Join）要求メッセージ１２００５を用いてグループサーバ８２１に登録する。これにより、グループサーバ８２１においてエントリが生成される。
（５）〜（８）ＭＮシグナリング（MN_SIG）メッセージ１２０１１がＮＡＴ８０７に到達すると、ＮＡＴ８０７は、グループ参加（Group_Join）要求メッセージ１２０１３を用いてグループサーバ８２１に登録する。この要求メッセージ１２０１３は図２５に示すように、特別なフラグとして、この登録を、グループサーバ８２１において作成された同じパスの他のＳＡＮＥからのエントリと置き換えるよう要求する「ＮＡＴ置き換え（NAT-Replace）フラグ２６０１１を含む。要求メッセージ１２０１３内の他の情報２６００１、２６００３、２６００５、２６００７、２６００９は図１９と同じである。【０１１２】
（９）（１０）次いで、ＮＡＴ８０７は、第６、第７、第８の実施の形態において必要な処理を行った後、ＭＮシグナリング（MN_SIG）メッセージ１２０１７をＣＮ８１１の方向に転送する。ここで、ＮＡＴ８０７はこのメッセージ１２０１７で、他のＳＡＮＥはグループサーバ８２１に登録しないように指示する。また、例として、第８の実施の形態に適用する場合には、ＮＡＴフラグと、インサイドフラグとアウトサイドフラグの３つのフラグをセットする。この動作により、グループサーバ８２１には、１つのＳＡＮＥすなわちＮＡＴ８０７が登録される。【０１１３】
（１１）（１２）したがって、ＭＮ８０１が新しい位置（ＭＮ８２３）に移動して、グループサーバ８２１は、ＭＮ８２３からＭＮトリガ（MN_Trigger）メッセージ１２０２１を受信すると、グループトリガ（Group_Trigger）メッセージ１２０２３をＮＡＴ８０７のみに送信する。
（１３）（１４）ＮＡＴ８０７はこのメッセージ１２０２３を受信すると、第６、第７、第８の実施の形態と同様に、このメッセージ１２０２３をＭＮメッセージ（MN_MSG）１２０２５、１２０２９に変換する。ＮＡＴ８０７はメッセージ１２０２５を元の位置のＭＮ８０１の方向に向かってＮＡＴドメイン８００内に送信し、メッセージ１２０２９をＣＮ８１１の方向に向かってＮＡＴドメイン８００外に送信する。ここで、この２つのメッセージ１２０２５、１２０２９は、異なるメッセージルーティング情報を用いて転送される。また、この２つのメッセージ１２０２５、１２０２９は、それぞれＳＡＮＥ８０３、ＣＮ８１１により自然にストップされるので、ホップリミットを設ける必要はない。【０１１４】
＜第１０の実施の形態＞
図２６は、第１０の実施の形態のネットワーク構成を示す。グループサーバ１３１３は、移動前のＭＮ１３０１が接続するネットワーク（移動元ＮＡＴドメイン）１３００に付属する。移動元ＮＡＴドメイン１３００内のＳＡＮＥ１３０１、１３０３、１３０５と、移動元ＮＡＴドメイン１３００外のＳＡＮＥ１３０９、ＣＮ１３１１とを含む全てのノードは、グループサーバ１３１３にアクセスする。当業者であれば、グループサーバ１３１３は物理的に移動元ＮＡＴドメイン１３００内に位置する必要はなく、移動元ＮＡＴドメイン１３００に接続する遠隔地に配置してもよいことは明らかである。ＭＮ１３０１は、移動元ＮＡＴドメイン１３００に接続するグループサーバ１３１３の情報をあらかじめ有するか、又はＤＮＳにより知得することができる。【０１１５】
ＭＮ１３０１が新しい位置（ＭＮ１３２１）に移動して、ＭＮ１３２１が新しいネットワーク（移動先ＮＡＴドメイン）１３２０に接続したものとする。移動先ＮＡＴドメイン１３２０には同様なグループサーバ１３２５が接続している。ＭＮ１３２１はこの新しいグループサーバ１３２５の情報を他の手段で知得する。グループサーバ１３２５はグループサーバ１３１３に対してネットワーク１３３０を介して接続されている。【０１１６】
第６、第７、第８、第９の実施の形態をこのネットワーク構成に適用した場合、移動先のＭＮ１３２１は、移動元のグループサーバ１３１３の情報を含むＭＮトリガ（MN_Trigger）メッセージを移動先のグループサーバ１３２５に送信する。グループサーバ１３２５はこのＭＮトリガ（MN_Trigger）メッセージを受信すると、このメッセージ内に埋め込まれている情報に基づいて元のグループサーバ１３１３にこのメッセージ転送を試みる。そして、このメッセージが元のグループサーバ１３１３に到達すると、第６、第７、第８、第９の実施の形態を適用することができる。【０１１７】
上記のＭＮトリガ（MN_Trigger）メッセージ内に埋め込まれている移動元のグループサーバ１３１３の情報としては、グループサーバ１３１３自身のユニークなＩＤや、移動元ＮＡＴドメイン１３００のＩＤでよい。当業者であれば、ＭＮトリガ（MN_Trigger）メッセージは、移動先のグループサーバ１３２５から他のグループサーバを経由して移動元のグループサーバ１３１３に転送されてもよいことは明らかである。【０１１８】
また、移動先のＭＮ１３２１が他の手段を介して、ＭＮトリガ（MN_Trigger）メッセージをローカルな移動先グループサーバ１３２５に送信してもよく、例えば移動先グループサーバ１３２５のアドレスにユニキャストしたり、移動先グループサーバ１３２５にエニキャスト又はマルチキャストしたり、特別なリンク層の手法を用いてもよい。特別なリンク層の手法としては、ＩＥＥＥ８０２．１x uncontrolled port すなわちＥＡＰメッセージを使用することができる。【０１１９】
また、当業者であれば、移動先グループサーバ１３２５は、全ての機能を有する必要がないことは明らかであり、ＭＮトリガ（MN_Trigger）メッセージを受信して単に中継するプロキシでもよい。移動先グループサーバ１３２５の実際の機能は、いずれの位置に配置すればよく、また、実際のネットワークでは、グループサーバ１３１３、１３２５はＡＡＡ（Authentification, Authorization and Accounting）エージェントであるか、又はローカルポリシー機能であるか、又は単にローカルなＤＮＳサーバである。【０１２０】
なお上記実施の形態はＮＡＴに限らず、他のドメイン、例えば非特許文献９におけるＧＧＳＮ(Gateway GPRS Support Node)やＰＤＮ(Packet Data Network)ゲートウェィが存在する場合に用いてもよい。【０１２１】
なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ ル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。
【産業上の利用可能性】
【０１２２】
本発明は、ローカルアドレスを使用するドメイン内からモバイルノードが外に移動した場合に、スタンサーバのような特別な手段を用いることなくドメイン内のモバイルノードの古いパスを破棄することができるという効果を有し、ＮＳＩＳ（Next Steps In Signaling）プロトコルを実行するシステムなどに利用することができる。
【図１】
2009001553.tif 000003
【図２】
2009001553.tif 000004
【図３】
2009001553.tif 000005
【図４】
2009001553.tif 000006
【図５】
2009001553.tif 000007
【図６】
2009001553.tif 000008
【図７】
2009001553.tif 000009
【図８】
2009001553.tif 000010
【図９】
2009001553.tif 000011
【図１０】
2009001553.tif 000012
【図１１】
2009001553.tif 000013
【図１２】
2009001553.tif 000014
【図１３】
2009001553.tif 000015
【図１４】
2009001553.tif 000016
【図１５】
2009001553.tif 000017
【図１６】
2009001553.tif 000018
【図１７】
2009001553.tif 000019
【図１８】
2009001553.tif 000020
【図１９】
2009001553.tif 000021
【図２０】
2009001553.tif 000022
【図２１】
2009001553.tif 000023
【図２２】
2009001553.tif 000024
【図２３】
2009001553.tif 000025
【図２４】
2009001553.tif 000026
【図２５】
2009001553.tif 000027
【図２６】
2009001553.tif 000028
【手続補正書】
【提出日】平成21年12月8日(2009.12.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信方法であって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録ステップと、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知するステップと、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリングステップと、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄するステップとを、
備えた通信方法。
【請求項２】
前記シグナリングステップは、
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記グループ登録ステップは、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知するステップと、
前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知するステップとを含むことを特徴とする請求項１に記載の通信方法。
【請求項４】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードとの属するグループを代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段と、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリング手段と、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えた通信システム。
【請求項５】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、
前記シグナリング手段は、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項４に記載の通信システム。
【請求項６】
前記グループ登録手段は、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知する手段と、
前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知する手段とを、
含むことを特徴とする請求項４に記載の通信システム。
【請求項７】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記モバイルノードであって、
前記モバイルノードと前記ドメイン内で前記モバイルノードのパスを確立しているノードが属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄するための前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段とを備えたモバイルノード。
【請求項８】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項７に記載のモバイルノード。
【請求項９】
前記グループ登録手段は、前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知する手段を含み、
前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知するようにしたことを特徴とする請求項７に記載のモバイルノード。
【請求項１０】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける代表サーバであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を前記代表サーバあてに送信した場合に、そのグループの情報を登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知した場合に、前記グループに属するノードあてに前記ドメイン内で確立している前記モバイルノードのパスを破棄させるシグナリングを送信するシグナリング手段とを備えた代表サーバ。
【請求項１１】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、
前記シグナリング手段は、前記マルチキャストアドレスあてにシグナリングすることを特徴とする請求項１０に記載の代表サーバ。
【請求項１２】
前記グループ登録手段は、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知し、前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知した場合に、そのグループの情報を登録することを特徴とする請求項１０に記載の代表サーバ。
【請求項１３】
ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記ノードであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信し、前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングした場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えたノード。
【請求項１４】
前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであることを特徴とする請求項１３に記載のノード。
【請求項１５】
前記グループ登録手段は、
前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知した場合に、前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知することを特徴とする請求項１３に記載のノード。
【請求項１６】
請求項１に記載の通信方法において、
前記グループ登録ステップは、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバに登録し、
前記シグナリングステップは、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングし、
さらに前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄するステップを、
含むことを特徴とする通信方法。
【請求項１７】
請求項４に記載の通信システムにおいて、
前記グループ登録手段は、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバに登録し、
前記シグナリング手段は、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングし、
さらに前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄する手段を、
含むことを特徴とする通信システム。
【請求項１８】
請求項１０に記載の代表サーバにおいて、
前記グループ登録手段は、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバあてに送信した場合に、そのグループの情報を登録し、
前記シグナリング手段は、前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知した場合に、前記第１及び第２の代表ノードあてのみにシグナリングして、前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄させることを特徴とする代表サーバ。
【請求項１９】
請求項１３に記載のノードにおいて、
前記グループ登録手段は、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノード、又は前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードとして前記グループの情報を前記代表サーバに登録し、
さらに、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングした場合に、前記第１又は第２の代表ノードとして、または前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードとして前記モバイルノードのパスを破棄する手段を、
含むことを特徴とするノード。
【請求項２０】
請求項１９に記載のノードにおいて、
前記第１の代表ノードは、前記モバイルノードに最も近いホップのノードであることを特徴とするノード。
【請求項２１】
請求項１９に記載のノードにおいて、
前記第１の代表ノードは、前記ドメインのエッジに設けられたネットワークアドレス変換器に最も近いホップのノードであることを特徴とするノード。
【請求項２２】
請求項１９に記載のノードにおいて、
前記第２の代表ノードは、前記ドメインのエッジに設けられたネットワークアドレス変換器に最も近いホップのノードであることを特徴とするノード。
【請求項２３】
請求項１９に記載のノードにおいて、
前記第２の代表ノードは、前記モバイルノードの通信相手のノードであることを特徴とするノード。
【請求項２４】
請求項１９に記載のノードにおいて、
前記第１及び第２の代表ノードは、前記ドメインのエッジに設けられたネットワークアドレス変換器であることを特徴とするノード。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ローカルアドレスを使用するドメインの境界をモバイルノードが横切る（cross）場合の通信方法、通信システム及び前記モバイルノードに関する。
また本発明は、ローカルアドレスを使用するドメイン内でモバイルノードのパスのステートを保持し、リソースを確保するノード、及び前記ノードを管理するサーバに関する。
【背景技術】
【０００２】
通信ネットワークは通常、アドレススペースが異なる複数のサブドメインに分割される。このサブドメインのローカルアドレスは、アドレス境界を跨ぐと有効ではなくなる。このため、一例として、アドレス境界にはネットワークアドレス変換器（Network Address Translator：ＮＡＴ）が設けられる。ＮＡＴの背後のノードが使用するローカルアドレスは、ＮＡＴドメインの外部のノードには見えない。ＮＡＴは、ドメイン内のノードがドメイン外のノードとの間でパケットを交換可能なようにアドレスマッピングを実行する。ここで、他の従来技術としては、下記の非特許文献１、２、３、４、５、７、８、９が開示されている。
【非特許文献１】STUN  Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy, RFC3489 HYPERLINK "http://www.ietf.org/rfc/rfc3489.txt" http://www.ietf.org/rfc/rfc3489.txt
【非特許文献２】Next Steps in Signaling (NSIS): Framework. R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. RFC4080 HYPERLINK "http://www.ietf.org/rfc/rfc4080.txt" http://www.ietf.org/rfc/rfc4080.txt
【非特許文献３】Resource ReSerVation Protocol (RSVP)  Version 1 Functional Specification. R. Braden, Ed. RFC2205 HYPERLINK "http://www.ietf.org/rfc/rfc2205.txt" http://www.ietf.org/rfc/rfc2205.txt
【非特許文献４】Multicast Address Dynamic Client Allocation Protocol (MADCAP), S. Hanna, B. Patel, M. Shah, RFC2730 HYPERLINK "http://www.ietf.org/rfc/rfc2730.txt" http://www.ietf.org/rfc/rfc2730.txt
【非特許文献５】Protocol Independent Multicast  Sparse Mode (PIM-SM): Protocol Specification (Revised), B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, RFC4601, HYPERLINK "http://www.ietf.org/rfc/rfc4601.txt" http://www.ietf.org/rfc/rfc4601.txt
【非特許文献６】NSLP for Quality-of-Service Signaling. J. Manner, G. Karagiannis, A. McDonald. Internet-Draft draft-ietf-nsis-qos-nslp-14.txt, work in progress.
【非特許文献７】Remote Authentication Dial In User Service (RADIUS): C. Rigney, A. Rubens, W. Simpson, S. Willens, RFC2138  HYPERLINK "http://www.ietf.org/rfc/rfc2138.txt" http://www.ietf.org/rfc/rfc2138.txt
【非特許文献８】Diameter Base Protocol: P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, RFC3588  HYPERLINK "http://www.ietf.org/rfc/rfc3588.txt" http://www.ietf.org/rfc/rfc3588.txt
【非特許文献９】3GPP System Architecture Evolution: Report on Technical Options and Conclusions(Release 7): 3GPP TR 23.882 V1.10.0 (2007-05)  HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/23882.htm" http://www.3gpp.org/ftp/Specs/html-info/23882.htm
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、モバイルノード（Mobile Node：ＭＮ）が移動して、接続するサブドメインが変化することがあり得る。図７はそのケースの一例を示し、ＭＮ１０１とＭＮ１１０は同じであって、ＭＮ１０１はＮＡＴドメイン１００内に位置し、ＭＮ１１０はＮＡＴドメイン１００外に移動したことを示す。ＮＡＴドメイン１００内のＭＮ１０１とＮＡＴドメイン１００外の通信相手（Correspondent Node：ＣＮ）１０７は、ＮＡＴドメイン１００内のリンク１２１、ノード（Signaling Aware Network Entity：ＳＡＮＥ）１０３、リンク１２３及びＮＡＴ１０５と、ＮＡＴドメイン１００外のリンク１２５を経由して通信セッションを有する。
【０００４】
ここで、ＭＮ１０１がＮＡＴドメイン１００外の新しい位置（図のＭＮ１１０）に移動してネットワーク１１２に接続したものとする（リンク１２７、１２９）。この新しい位置では、移動後のＭＮ１１０は新しいアドレスが割り当てられ、ＮＡＴドメイン１００内のノードにはアクセスすることはできない。例えばＳＡＮＥ１０３がＮＡＴ１０５を経由してネットワーク１１２に接続していても、移動後のＭＮ１１０はＳＡＮＥ１０３にはアクセスすることはできない。この理由は、移動前のＭＮ１０１の位置では知られているＳＡＮＥ１０３のローカルアドレスは、移動後のＭＮ１１０の位置からのパケットには使用できないからである。
【０００５】
ところで、移動前のＭＮ１０１の位置における通信セッションのためのシグナリングステートとリソースは、ＳＡＮＥ１０３上に割り付けられが、移動後のＭＮ１１０の位置では解放されるべきである。ここで、ソフトステート手法を用いてシグナリングステートをタイムアウトすることによりリソースを解放することができるが、それはリソースの有効利用を損なうことになる。したがって、シグナリングステートを破棄する明確なシグナリングが望ましい。しかし、前述したように、移動後の新しい位置におけるＭＮ１１０は、ＳＡＮＥ１０３にシグナリングすることができないという問題がある。
【０００６】
ここで、上記問題点を解決する手法として、非特許文献１におけるスタンサーバを用いて、移動後のＭＮ１１０がＳＡＮＥ１０３にパケットを直接送ってＳＡＮＥ１０３のパブリックアドレスを得ることが考えられる。しかしながら、この解決策では、以下の要件を付加することを必要とする。第１に、ＳＡＮＥ１０３がスタンサーバをサポートすることを必要とし、また、スタンサーバはネットワーク１１２下に必要とする。また、移動前のＭＮ１０１がＳＡＮＥ１０３の新たなアドレス情報を蓄積する必要がある。さらに、移動前のＭＮ１０１が複数のセッション、すなわち複数のＳＡＮＥを有する場合には、この新たなアドレス情報のデータ量が大きくなる。さらに、この新たなアドレス情報を移動前のＭＮ１０１とＳＡＮＥ１０３の間で交換するための特別なプロトコルを必要とする。最後に、スタンサーバのようなプロトコルは、ＮＡＴのタイプによっては機能しない場合がある。例えば対称ＮＡＴ（Symmetric ＮＡＴ）のタイプがあげられる。
【０００７】
本発明は上記従来技術の問題点に鑑み、アドレス変換器によりローカルアドレスを使用するドメイン内からモバイルノードが外に移動した場合に、スタンサーバのような特別な手段を用いることなくドメイン内のモバイルノードの古いパスを破棄することができる通信方法、通信システム、モバイルノード、サーバ及びノードを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信方法であって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録ステップと、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知するステップと、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリングステップと、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄するステップとを、
備えた構成とした。
【０００９】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードとの属するグループを代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段と、
前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングするシグナリング手段と、
前記シグナリングされたノードが、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えた構成とした。
【００１０】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記モバイルノードであって、
前記モバイルノードと前記ドメイン内で前記モバイルノードのパスを確立しているノードが属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄するための前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知する手段とを、
備えた構成とした。
【００１１】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける代表サーバであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を前記代表サーバあてに送信した場合に、そのグループの情報を登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信して前記代表サーバに通知した場合に、前記グループに属するノードあてに前記ドメイン内で確立している前記モバイルノードのパスを破棄させるシグナリングを送信するシグナリング手段とを、
備えた構成とした。
【００１２】
また本発明は上記目的を達成するために、ローカルアドレスを使用するドメイン内に位置するモバイルノードが前記ドメインの外に移動した場合に前記ドメイン内のノードにシグナリングする通信システムにおける前記ノードであって、
前記モバイルノードと、前記ドメイン内で前記モバイルノードのパスを確立しているノードの属するグループの情報を代表サーバあてに送信して前記代表サーバに登録するグループ登録手段と、
前記ドメインの外に移動した前記モバイルノードから、前記グループの情報を前記代表サーバあてに送信し、前記グループの情報を通知された前記代表サーバから、前記グループに属するノードあてにシグナリングした場合に、前記ドメイン内で確立している前記モバイルノードのパスを破棄する手段とを、
備えた構成とした。
【００１３】
また、前記グループの情報が、前記モバイルノード及びノードのマルチキャストアドレスであり、前記代表サーバから前記マルチキャストアドレスあてにシグナリングすることを特徴とする。
さらに、前記モバイルノードから前記ドメイン内の前記ノードに対して、前記グループの情報を含むリソース予約メッセージで前記グループの情報を通知し、前記グループの情報を通知された前記ノードから前記代表サーバに対して、前記グループの情報を含むグループ参加メッセージで前記グループへの参加を通知することを特徴とする。
また、前記ドメイン内で前記モバイルノードのパスを確立している複数のノードのうちの１つの第１の代表ノードと、前記ドメイン外で前記モバイルノードのパスを確立している複数のノードのうちの１つの第２の代表ノードが前記グループの情報を前記代表サーバに登録し、前記代表サーバから前記第１及び第２の代表ノードあてのみにシグナリングし、さらに前記第１及び第２の代表ノードからそれぞれ、前記ドメイン内及び前記ドメイン外で前記モバイルノードのパスを確立している他のノードにシグナリングして前記モバイルノードのパスを破棄することを特徴とする。
【００１４】
この構成により、ローカルアドレスを使用するドメイン内にモバイルノードが位置する場合にドメイン内のノードがモバイルノードのパスのステートを保持してリソースを確保し、モバイルノードが前記ドメインの外に移動した場合にドメイン内のノードにシグナリングして、シグナリングされたノードがドメイン内のモバイルノードの古いパスを破棄することができる。
【発明の効果】
【００１５】
本発明によれば、アドレス変換器によりローカルアドレスを使用するドメイン内からモバイルノードが外に移動した場合に、スタンサーバのような特別な手段を用いることなくドメイン内のモバイルノードの古いパスを破棄することができる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照して本発明の実施の形態について説明する。
＜第１の実施の形態＞
図１は本発明に係る通信システムの第１の実施の形態を示すブロック図である。図１において、ＮＡＴ（Network Address Translator）ドメイン１００内のＭＮ１０１とＮＡＴドメイン１００外の通信相手（Correspondent Node：ＣＮ）１０７は、ＮＡＴドメイン１００内のリンク１２１、ノード（Signaling Aware Network Entity：ＳＡＮＥ）１０３、リンク１２３及びＮＡＴ１０５と、ＮＡＴドメイン１００外のリンク１２５を経由して通信セッションを有し、通信パスが形成されている。ＳＡＮＥ１０３は、例えば非特許文献２におけるＮＳＩＳ（Next Steps In Signaling）エンティティや、非特許文献３におけるＲＳＶＰ（Resource ReSerVation Protocol）をサポートするルータである。また、当業者であれば、ＳＡＮＥ１０３は、通信セッションに関連する他のシグナリングアプリケーションをサポートするノードでもよいことは明らかである。さらに、ＭＮ１０１とＣＮ１０７がＳＡＮＥ１０３の機能を有するように構成することも可能である。また、図面の都合上、限られた数のノードしか図示されていないが、当業者であれば、より多くのノードが存在することは明らかであり、例えばＮＡＴ１０５の前後のパス上に複数のＳＡＮＥが存在する。
【００１７】
ＭＮ１０１とＳＡＮＥ１０３は、ＣＮ１０７から見てＮＡＴ１０５の背後に位置してＮＡＴドメイン１００内に位置するので、ＮＡＴドメイン１００内のローカルアドレス（Addr_MN_NAT）、（Addr_SANE_NAT）がそれぞれ割り当てられている。ＭＮ１０１はローカルアドレス（Addr_MN_NAT）をＣＮ１０７あてのパケットの送信元アドレスとして使用する。ここで、ＮＡＴ１０５はＭＮ１０１のローカルアドレス（Addr_MN_NAT）を、ＮＡＴドメイン１００外でルーティング可能なパブリックアドレス（Addr_MN_Pub）にマッピングしている。
【００１８】
したがって、ＮＡＴ１０５はＭＮ１０１からＣＮ１０７あてのパケットの送信元アドレスをパブリックアドレス（Addr_MN_Pub）に置き換える。ＣＮ１０７はこのパケットを受信すると、パブリックアドレス（Addr_MN_Pub）をＭＮ１０１のアドレスとする。したがって、ＣＮ１０７はこのパブリックアドレス（Addr_MN_Pub）を、ＭＮ１０１あてのパケットのあて先アドレスとして使用する。このＣＮ１０７からＭＮ１０１あてのパケットがＮＡＴ１０５に到着すると、ＮＡＴドメイン１００内のＭＮ１０１に到着するように逆のマッピングが行われて、パブリックアドレス（Addr_MN_Pub）がローカルアドレス（Addr_MN_NAT）に変換される。なお、本発明を逸脱しない限り、ＮＡＴ１０５は他のアドレスマッピングを使用してもよい。
【００１９】
ＭＮ１０１とＣＮ１０７の間の通信パスが確立すると、その通信セッションに必要なサポートを提供するためのネットワーク制御シグナリングが必要となる。そのシグナリング例としては、特許文献２に示すようなサービス品質（Quality of Service：ＱｏＳ）シグナリングや特許文献３に示すようなＲＳＶＰシグナリングがある。ここで、当業者であれば、本発明を逸脱しない限り、他のシグナリングを用いることができることは明らかである。このようなシグナリングにより、ＳＡＮＥ１０３上にシグナリングステートが生成され、対応する通信セッションにネットワークリソースが割り当てられる。
【００２０】
ある時点でＭＮ１０１がＮＡＴドメイン１００外の新しい位置（ＭＮ１１０）に移動して、ネットワーク１１２にリンク１２７を介して接続されたものとする。この新しい位置におけるＭＮ１１０は、新しいアドレス（Addr_MN_Nw）が割り当てられる。ネットワーク１１２はＮＡＴドメイン１００とは異なるアドレス空間（address spaces）を有するので、ＭＮ１１０はもはや、ＳＡＮＥ１０３に対してはローカルアドレス（Addr_SANE_NAT）では直接、アドレシングできない。ここで、当業者であれば、ネットワーク１１２が本実施の形態と異なる構成であっても、本発明に影響しないことは明らかである。例えば、ネットワーク１１２がＮＡＴドメイン１００と異なる他のＮＡＴドメインである場合も同様に適用可能である。
【００２１】
図１では、グループサーバ２０１がネットワーク１１２に設けられている。グループサーバ２０１はグローバルなアドレシングが可能であり、したがって、移動前の位置のＭＮ１０１、ＳＡＮＥ１０３、移動後の新しい位置のＭＮ１１０は、グループサーバ２０１に対してあるアドレス又は識別子を用いて通信することができる。これは、グループサーバ２０１にグローバルＩＰアドレスやＦＱＤＮ（Fully Qualified Domain Name）を割り当てることにより実現することができる。ここで、図１ではグループサーバ２０１はＮＡＴドメイン１００外のネットワーク１１２に接続されているが、他の接続形態を用いることができる。例えばグループサーバ２０１をＮＡＴ１０５、ＳＡＮＥ１０３及び前の位置のＭＮ１０１が位置するＮＡＴドメイン１００内に配置することもできる。この構成は、本発明に影響を与えるものではない。さらに、グループサーバ２０１を分散型サーバのグループで構成することも可能である。グループサーバの例として、ＡＡＡサーバ（非特許文献７のＲＡＤＩＵＳサーバや、非特許文献８のＤＩＡＭＥＴＥＲサーバ）や非特許文献９のＰＣＲＦ（Policy and Charging Rules Function）、後述のマルチキャストサーバなどがある。
【００２２】
＜動作シーケンス＞
図２は本発明の動作シーケンスの一例を示す。
（１）まず、移動前の位置のＭＮ１０１は、ＣＮ１０７と通信セッションを開始すると、グループサーバ２０１にグループ（グループＡとする）を登録する。この登録は、グループサーバ２０１に対して送信するグループ登録（Group_Register）要求メッセージ３００１で行うことができ、グループ登録要求メッセージ３００１はグループサーバ２０１のグローバルアドレスあてに送信される。ＭＮ１０１はグループサーバ２０１のグローバルアドレスをいろいろな方法で入手することができ、例えばＭＮ１０１はグループサーバ２０１のグローバルアドレスをあらかじめ持っていてもよく、また、ローカルＤＮＳ（Domain Name System）サーバに問い合わせてもよく、さらにグループサーバ２０１のプロキシを前もって知っていてそれにメッセージを送信してもよい。当業者であれば、本発明を逸脱しない限り、ＭＮ１０１が他の方法でグループサーバ２０１のグローバルアドレスを入手することができることは明らかである。
【００２３】
（２）グループサーバ２０１は、ＭＮ１０１からのグループ登録要求メッセージ３００１を受信すると、この要求メッセージを認証し、成功すると、このＭＮに対し必要な情報エントリを生成する。この情報エントリは、例えばＭＮ１０１のＩＤ、グループＩＤ、セキュリティ・アソシエーション（ＳＡ）、グループのメンバリストなどを含むことができる。また、オプションとして、このプロトコルが要求する場合には、グループサーバ２０１は処理結果をグループ登録確認（Group_Confirm）メッセージ３００３でＭＮ１０１に確認する。グループ登録確認メッセージ３００３は、グループ登録がＯＫか、及びそのループを使用するための付加情報、例えばセキュリティ・アソシエーション情報などを含むようにしてもよい。
【００２４】
（３）ＭＮ１０１はグループＡをグループサーバ２０１に登録すると、ＳＡＮＥ１０３あてのシグナリングメッセージ内に関連情報を埋め込む。例えばＭＮ１０１はＳＡＮＥ１０３あてのリソース予約（Reserve）メッセージ３００５内に、グループサーバ２０１のアドレス、グループＡの情報、セキュリティ・アソシエーション情報などを提供する「グループ情報要素」を含ませる。
【００２５】
（４）ＳＡＮＥ１０３はＭＮ１０１からのシグナリングメッセージ、例えば予約メッセージ３００５を受信すると、そのメッセージ３００５から「グループ情報要素」を入手し、「グループ情報要素」を用いて、シグナリングされたセッションに関連するグループに参加する。この参加は、グループ参加（Group_Join）要求メッセージ３００７をグループサーバ２０１あてに送信することにより実現することができる。グループ参加要求メッセージ３００７は、受信した予約メッセージ３００５の「グループ情報要素」が指示するサーバアドレスに送信される。ＳＡＮＥ１０３はまた、グループ参加要求メッセージ３００７内に、グループ動作に必要な情報、例えばグループＡの情報、セキュリティ・アソシエーション情報などを含ませる。ここで、当業者であれば、グループ参加要求メッセージ３００７のあて先は、ＳＡＮＥ１０３から直接グループサーバ２０１あてである必要はないことを明白であり、例えば幾つかの中間手段、例えばプロキシを経由してもよい。
【００２６】
（５）グループサーバ２０１はグループ参加要求メッセージ３００７を受信すると、そのメッセージ３００７をベリファイし、例えばグループＡの存在のチェック、付属のセキュリティ・アソシエーション情報のベリファイ（verification）を行う。ベリファイがＯＫの場合、グループサーバ２０１はＳＡＮＥ１０３をグループＡのメンバリストにセットする。これは、例えばグループ参加要求メッセージ３００７の送信元アドレスをグループＡのメンバリストにコピーしたり、グループ参加要求メッセージ３００７内に特別なＳＡＮＥ−ＩＤが存在したりする場合にはそのＳＡＮＥ−ＩＤを取り出すことにより実現することもできる。次にオプションとして、グループサーバ２０１はグループ参加応答（Group Response）メッセージ３００９をＳＡＮＥ１０３あてに送信して、グループ参加要求の結果を知らせる。
【００２７】
（６）次に、ＭＮ１０１がＮＡＴドメイン１００外の新しい位置（ＭＮ１１０）に移動した場合、ＭＮ１１０はＳＡＮＥ１０３に到達する代わりに、グループサーバ２０１あてのＭＮトリガ（MN_Trigger）メッセージ３０１１を送信する。ＭＮ１１０はこの処理を、異なるドメイン名や新しいプリフィックスなどにより、自分の新しい位置が異なるアドレスのドメインに属することを検知して実行する。ＭＮトリガメッセージ３０１１は、グループＡの識別子、必要なセキュリティ・アソシエーション情報、ＳＡＮＥ１０３あてに送信されたシグナリングメッセージ内容などを含む。例えばＮＳＩＳ  ＱｏＳシグナリングアプリケーションがＳＡＮＥ１０３にサポートされている場合、このシグナリングメッセージは非特許文献６に記載の、予約(Reserve)メッセージ内に「破棄(tear)フラグ」がセットされたものである。
【００２８】
（７）グループサーバ２０１はＭＮ１１０からＭＮトリガメッセージ３０１１を受信すると、メッセージ３０１１内に付属するセキュリティ・アソシエーション情報を用いてＭＮトリガメッセージ３０１１をベリファイする。ベリファイがＯＫの場合、グループサーバ２０１はグループＡに関連する全てのメンバリスト内のメンバ（ノード）に対して、ＭＮトリガメッセージ３０１１のシグナリングメッセージ内容を送信する。これは、メンバリスト内の全てのＳＡＮＥ１０３にグループトリガ（Group_Trigger）メッセージ３０１３を送信することにより実現することができる。ＳＡＮＥ１０３はグループトリガメッセージ３０１３内のシグナリングメッセージ内容（ＭＮトリガメッセージ３０１１）を回収して、シグナリングアプリケーション規則が定める動作を実行する。例えば移動前のＭＮ１０１の古いパスのステートを破棄し、また、そのリソースを解放する処理を実行する。
【００２９】
ここで、当業者であれば、本発明を逸脱しないかぎり、さらに多くのノードを含めてもよいことは明らかである。例えば複数のＳＡＮＥがネットワーク内に存在する場合、移動前のＭＮ１０１が予約メッセージ３００５をその全てのＳＡＮＥに送信し、その全てのＳＡＮＥがグループ参加要求メッセージ３００７をグループサーバ２０１あてに送信してもよい。また、グループサーバ２０１は、これらのグループ参加要求メッセージ３００７を受信した場合に、グループトリガメッセージ３０１３を複数のＳＡＮＥに送信するようにしてもよい。
【００３０】
また、当業者であれば、上記（１）のグループ登録要求メッセージ３００１、及び（２）のグループ登録確認メッセージ３００３のステップは、ＭＮ１０１が１つの場所に位置するときに１回のみでもよいことは明らかである。例えば同じＭＮ１０１が異なる経路を通る複数のセッションを用いて通信していた場合、これら複数経路上に存在するＳＡＮＥは同じグループに参加してもよい。これは、ＭＮ１０１が前の位置に関しても同じ破棄トリガを全てのＳＡＮＥに送信できるので合理的である。オプションとして、ＭＮ１０１が位置変化を検出したとき、グループ登録要求メッセージ３００１は、ＭＮトリガメッセージ３０１１の後に連結して送信してもよい。
【００３１】
＜ＭＮ１０１の構成＞
図３を参照してＭＮ１０１の構成を説明する。なお、図３は本発明のＭＮ１０１の機能を実現する構成のみを示す。ＭＮ１０１は概略的には、シグナリング制御部４１１と、トランスポート機能部４１３とシグナリンググループ制御部４１５の３つの構成要素を有する。シグナリング制御部４１１は例えば前述した非特許文献２におけるＮＳＩＳ（Next Steps In Signaling）や、非特許文献３におけるＲＳＶＰ（Resource ReSerVation Protocol）のようなシグナリングアプリケーションに要求される機能を実行する。シグナリンググループ制御部４１５は前述したＭＮ１０１とグループサーバ２０１の間のグループ管理を実行する。トランスポート機能部４１３は、シグナリング制御部４１１とシグナリンググループ制御部４１５が生成するメッセージを送信する。トランスポート機能部４１３は単に、例えばＩＰ、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）を実行するものでもよい。
【００３２】
インタフェース４２１はシグナリング制御部４１１とトランスポート機能部４１３を接続し、例えばＮＳＩＳなどのシグナリングアプリケーションに要求される機能を実行する。インタフェース４２３はシグナリンググループ制御部４１５とトランスポート機能部４１３を接続し、ＭＮ１０１とグループサーバ２０１の間のメッセージ交換をサポートする機能を実行する。インタフェース４２３は例えば図２（１）（６）（３）に示すように、ＭＮ１０１からのグループ登録要求メッセージ３００１とＭＮトリガメッセージ３０１１の送信と、グループサーバ２０１からのグループ登録確認メッセージ３００３の受信をサポートする。なお、これは単にＵＤＰソケットでもよく、また、より複雑なプロトコルがＭＮ１０１とグループサーバ２０１の間に必要な場合には、インタフェース４２３はそれに必要な機能を実行する。
【００３３】
シグナリング制御部４１１とシグナリンググループ制御部４１５を接続するインタフェース４２５は、主要な機能として「ＭＧ生成」（MG_Create）、「ＭＧ確認」（MG_Confirm）「ＭＧトリガ」（MG_Trigger）を提供する。「ＭＧ生成」と「ＭＧトリガ」は、シグナリング制御部４１１からシグナリンググループ制御部４１５に向かい、「ＭＧ確認」はシグナリンググループ制御部４１５からシグナリング制御部４１１に向かう。
【００３４】
ここでは、シグナリング制御部４１１がシグナリングセッションを開始する必要があるときにこれを「ＭＧ生成」と言い、グループがセッションに割り当てられることを要求される。シグナリンググループ制御部４１５は、「ＭＧ生成」の機能をトリガとして、自身が有効なグループを登録しているかをチェックする。グループ情報を登録していない場合、シグナリンググループ制御部４１５は、グループ登録要求メッセージ３００１を生成し、これをインタフェース４２３を介してトランスポート機能部４１３に渡す。グループ登録（Group_Register）要求メッセージ３００１のフォーマットは、例えば図８及び以下のように構成される。
Group_Register：
・グループサーバＩＤ１４０１[Group Server ID]
・ＭＮ−ＩＤ１４０３[MN ID]
・セッションＩＤ１４０５[Session ID]
・グループ情報１４０７[Group Info]
・セキュリティ・トークン１４０９[Security Token]
【００３５】
グループサーバＩＤ１４０１はグループサーバ２０１のグローバルにユニークな識別子であり、例えばＦＱＤＮ（Fully Qualified Domain Name）である。ＭＮ１０１はこのグループサーバＩＤ１４０１をあらかじめ取得しているか、また、ローカルな構成、例えばＤＨＣＰ（Dynamic Host Configuration Protocol）により取得することができる。ＭＮ−ＩＤ１４０３は、グループ登録要求メッセージ３００１を送信するＭＮ１０１の識別子であり、例えばＭＮ１０１のローカルなＩＰアドレス、すなわちユーザのアドレス情報である。グループ情報１４０７は、ＭＮ１０１が希望するグループ割り当て情報を含む。例としてグループ情報１４０７[Group Info]は、図１０に示すように以下の情報を含むようにしてもよい。
Group Info：
・グループサーバＩＤ１６０１[Group Server ID]
・グループ識別子１６０３[Group Identifier]
・グループリフレッシュタイマ１６０５ [Group Refresh Timer]
・グループ参加トークン１６０７ [Group Join Token]
なお、ＭＮ１０１がグループサーバ２０１に対してグループ割り当てを依頼する場合には、グループ情報１４０７は除くことができる。セキュリティ・トークン１４０９は、グループサーバ２０１がＭＮ１０１の認証を必要とする場合にオプションとして含まれる。
【００３６】
図３に戻り、トランスポート機能部４１３はグループサーバＩＤを例えばＤＮＳ queryで経由して解析してグループ登録要求メッセージ３００１の実際の送信方法を決定し、例えばグループサーバ２０１のＩＰアドレスに直接送信するか、又はプロキシ経由で送信するかを決定する。グループ登録要求メッセージ３００１がグループサーバ２０１に正常に到達すると、グループ登録確認メッセージ３００３がＭＮ１０１により受信される。トランスポート機能部４１３はグループ登録確認メッセージ３００３を受信すると、これをシグナリンググループ制御部４１５にインタフェース４２３経由で渡す。グループ登録確認（Group_Confirm）メッセージ３００３は、一例として図９及び以下のように構成される。
Group_Confirm：
・セッションＩＤ１５０１[Session ID]
・グループ情報１５０３[Group Info]
・セキュリティ・トークン１５０５[Security Token]
【００３７】
セッションＩＤ１５０１はグループ登録要求メッセージ３００１と同じ構成である。ただし、グループ登録要求メッセージ３００１でＭＮ１０１が所望したグループ割り当てが提供できない場合、グループサーバ２０１は別のグループ割り当てをグループ情報１５０３に含めている。グループ情報１５０３はグループサーバ２０１により割り当てられるグループの情報を含む。
【００３８】
グループ登録確認（Group_Confirm）メッセージ３００３のグループサーバＩＤ１６０１は、グループ登録要求メッセージ３００１と同様、割り当てられたグループにサービスを提供するグループサーバ２０１の識別子である。なお、プロキシ又はサーバ・バランシングが用いられる場合には、グループサーバＩＤ１６０１は、グループ登録要求メッセージ３００１が送信されたグループサーバ２０１とは異なるものでもよい。グループ識別子１６０３は、シグナリングセッションに用いられるグループに関する情報であるが、そのフォーマットはグループサーバ２０１が選択するものでよい。グループリフレッシュタイマ１６０５は、グループサーバ２０１がそのグループにサービスを提供するタイムリミットである。ここで、ＭＮ１０１はグループサーバ２０１に対してグループリフレッシュタイマ１６０５を更新する必要がある。この更新は、グループリフレッシュタイマ１６０５が満了する前にグループ登録要求メッセージ３００１をグループサーバ２０１に再送することにより実現することができる。グループ参加トークン１６０７は、ＳＡＮＥ１０３が参加したグループをグループサーバ２０１が認証するのに役立つベリファイ（verification）用のコードを提供する。
【００３９】
シグナリンググループ制御部４１５はグループ情報１５０３とセキュリティ・トークン１５０５を保持して「ＭＧ確認」の機能をコールし、「ＭＧ確認」を受け取るシグナリング制御部４１１にグループ情報１５０３を渡す。シグナリング制御部４１１はグループ情報１５０３を予約メッセージ３００５に埋め込み、シグナリングセッションに送る。
【００４０】
ＭＮ１０１が移動を検出すると、シグナリング制御部４１１は前のシグナリングステートを破棄することを決定し、シグナリング制御部４１１はまた、前のパスを介してＳＡＮＥ１０３にシグナリングする必要がある。そこで、シグナリング制御部４１１は「ＭＧトリガ」の機能をコールし、破棄フラグ付きの予約メッセージ３００５をシグナリンググループ制御部４１５に渡す。シグナリンググループ制御部４１５はＭＮトリガメッセージ３０１１を生成して、ＭＮトリガメッセージ３０１１内にその予約メッセージ３００５を埋め込む。このＭＮトリガメッセージ３０１１はトランスポート機能部４１３に渡され、次いでグループサーバ２０１に送信される。ＭＮトリガ（MN_Trigger）メッセージ３０１１の構成例を図１１及び以下に示す。
MN_Trigger：
・グループサーバＩＤ１７０１ [Group Server ID]
・グループ情報１７０３[Group Info]
・シグナリングメッセージ内容１７０５[Signaling Message Content]
・セキュリティ・トークン１７０７[Security Token]
【００４１】
グループサーバＩＤ１７０１とグループ情報１７０３は、グループ登録確認メッセージ３００３内のグループ情報１５０３から得ることができる。シグナリングメッセージ内容１７０５は、ＳＡＮＥ１０３に渡されたシグナリングメッセージであり、例えば破棄フラグ付きの予約メッセージ３００５である。セキュリティ・トークン１７０７は、最後のグループ登録確認メッセージ３００３から取得される。
【００４２】
＜ＳＡＮＥ１０３の構成＞
次に図４を参照してＳＡＮＥ１０３の構成を説明する。なお、図４は本発明のＳＡＮＥ１０３の機能を実現する構成のみを示す。ＳＡＮＥ１０３は概略的には、シグナリング制御部５１１と、トランスポート機能部５１３とシグナリンググループ制御部５１５の３つの構成要素を有する。シグナリング制御部５１１とトランスポート機能部５１３は、ＭＮ１０１のシグナリング制御部４１１とトランスポート機能部４１３と同様な機能を有する。ただし、シグナリング制御部４１１はシグナリング・イニシエータ（ＳＩ）として動作するのに対し、シグナリング制御部５１１はシグナリング転送部又はシグナリング・レスポンダ（ＳＲ）として動作する。
【００４３】
シグナリング制御部５１１とシグナリンググループ制御部５１５の間のインタフェース５２５は、ＳＧ参加（SG_Join）、ＳＧ確認（SG_Confirm）、ＳＧ通知（SG_Notify）の３つの機能を実行する。「ＳＧ参加」はシグナリング制御部５１１からシグナリンググループ制御部５１５に対して行われ、「ＳＧ確認」と「ＳＧ通知」はシグナリンググループ制御部５１５からシグナリング制御部５１１に対して行われる。ただし、「ＳＧ確認」はオプションである。
【００４４】
ＭＮ１０１からの例えば予約メッセージ３００５を受信すると、シグナリング制御部５１１は、シグナリングアプリケーションにより定義されている処理を実行し、さらに予約メッセージ３００５内に「グループ情報」があるかをチェックする。もし「グループ情報」がある場合、シグナリング制御部５１１は「ＳＧ参加」の機能をコールし、また、「グループ情報」をシグナリンググループ制御部５１５に渡す。「グループ情報」に基づいて、グループ参加要求メッセージ３００７がシグナリンググループ制御部５１５により生成されてトランスポート機能部５１３に渡され、グループサーバ２０１に送信される。グループ参加（Group_Join）要求メッセージ３００７は、例えば図１２及び以下のように構成される。
Group_Join：
・グループサーバＩＤ１８０１ [Group Server ID]
・ＳＡＮＥ−ＩＤ１８０３ [SANE ID]
・グループ参加トークン１８０５[Group Join Token]
【００４５】
グループサーバＩＤ１８０１とグループ参加トークン１８０５は「グループ情報」から得られる。ＳＡＮＥ−ＩＤ１８０３はオプションである。例えばＳＡＮＥ１０３はＮＡＴ１０５のマッピングの後に自身のパブリックアドレスを知得している場合には、それをＳＡＮＥ−ＩＤ１８０３に挿入することができる。
【００４６】
グループサーバ２０１が、オプションの応答であるグループ参加応答メッセージ３００９をＳＡＮＥ１０３に送り返す場合には、トランスポート機能部５１３はグループ参加応答メッセージ３００９をシグナリンググループ制御部５１５に渡す。グループ参加応答（Group Response）メッセージ３００９は例えば図１３及び以下のように構成される。
Group Response：
・ＳＡＮＥ−ＩＤ１９０１[SANE ID]
・グループ情報１９０３[Group Info]
【００４７】
ＳＡＮＥ−ＩＤ１９０１はグループサーバ２０１により、グループ参加要求メッセージ３００７内のＳＡＮＥ−ＩＤ１８０１又はグループ参加要求メッセージ３００７の送信元アドレスをコピーすることにより挿入される。グループ情報１９０３はメッセージ３００１からコピーされる。グループ情報１９０３はまた、グループサーバ２０１が例えばグループリフレッシュタイマ１６０５などを調整するのに用いてもよいオプションである。
【００４８】
グループサーバ２０１はＭＮトリガメッセージ３０１１を受信すると、グループトリガメッセージ３０１３をＳＡＮＥ１０３あてに送信する。グループトリガ（Group_Trigger）メッセージ３０１３のフォーマットは例えば図１４及び以下のように構成される。
Group_Trigger：
・ＳＡＮＥ−ＩＤ２０００１ [SANE ID]
・グループ情報２０００３[Group Info]
・シグナリングメッセージ内容２０００５[Signaling Message Content]
ＳＡＮＥ−ＩＤ２０００１はグループサーバ２０１に登録されているＳＡＮＥ１０３のアドレスであり、グループ情報２０００３とシグナリングメッセージ内容２０００５はＭＮトリガメッセージ３０１１から得られる。
【００４９】
シグナリンググループ制御部５１５は、グループトリガメッセージ３０１３を受信すると、「ＳＧ通知」の機能をコールしてシグナリングメッセージ内容２０００５をシグナリング制御部５１１に渡すことにより、ＭＮ１０１の古いパスのステートの除去及びリソースの解放などの動作につなげる。
【００５０】
＜グループサーバ２０１の構成＞
次に図５を参照してグループサーバ２０１の構成を説明する。なお、図５は本発明のグループサーバ２０１の機能を実現する構成のみを示す。グループサーバ２０１は概略的には、シグナリンググループ管理部６１３とトランスポート機能部６１１の２つの構成要素を有し、また、インタフェース６２１はシグナリンググループ管理部６１３とトランスポート機能部６１１の間を接続している。トランスポート機能部６１１は、グループ登録要求メッセージ３００１と、グループ参加要求メッセージ３００７とＭＮトリガメッセージ３０１１を受信すると、これらをシグナリンググループ管理部６１３に渡す。
【００５１】
シグナリンググループ管理部６１３はグループ登録要求メッセージ３００１を取得すると、ＭＮ１０１のグループを生成し、また、メッセージ３００１内にグループ情報１４０７がない場合にはローカル情報ベースとしてデータエントリ２１０００（Srv_Group）を生成する。データエントリ２１０００（Srv_Group）のフォーマットは、例えば図１５及び以下のように構成される。
Srv_Group：
・グループＩＤ２１００１[Group ID]
・ＭＮ−ＩＤ２１００３[MN ID]
・セキュリティ・トークン２１００５[Security Token]
・グループリフレッシュタイマ２１００７[Group Refresh Timer]
・グループ参加トークン２１００９[Group Join Token]
・メンバリスト２１０１１[Member List]
メンバリスト２１０１１は図１６に示すように、複数のＳＡＮＥ−ＩＤ２２００１〜２２００３（ＳＡＮＥ−ＩＤ１〜ＳＡＮＥ−ＩＤｎ）により構成される。
【００５２】
シグナリンググループ管理部６１３は、この後、グループ登録確認メッセージ３００３を生成してトランスポート機能部６１１に渡し、ＭＮ１０１に送信する。メッセージ３００１内にグループ情報１４０７がある場合には、シグナリンググループ管理部６１３は、メッセージ３００１内のセキュリティ・トークン１４０９のベリファイがＯＫの場合にデータエントリ２１０００（Srv_Group）をリフレッシュする。
【００５３】
シグナリンググループ管理部６１３はグループ参加要求メッセージ３００７を取得すると、メッセージ３００７内にＳＡＮＥ−ＩＤ１８０３があるかをチェックする。ＳＡＮＥ−ＩＤ１８０３がある場合、シグナリンググループ管理部６１３は、対応するデータエントリ２１０００（Srv_Group）のメンバリスト２１０１１にそのＳＡＮＥ−ＩＤ１８０３を追加する。メッセージ３００７内にＳＡＮＥ−ＩＤ１８０３がない場合、シグナリンググループ管理部６１３はメッセージ３００７の送信元アドレスをメンバリスト２１０１１に追加する。シグナリンググループ管理部６１３は、この後、グループ参加応答メッセージ３００９を生成してトランスポート機能部６１１に渡し、ＳＡＮＥ１０３に送信する。
【００５４】
シグナリンググループ管理部６１３はＭＮトリガメッセージ３０１１を取得すると、メッセージ３０１１からグループ情報１７０３を引き出す。シグナリンググループ管理部６１３はまた、データエントリ２１０００（Srv_Group）を同じグループＩＤ２１００１及びＭＮ−ＩＤ２１００３に配置し、次いでメンバリスト２１０１１を引き出す。メンバリスト２１０１１がある場合には、シグナリンググループ管理部６１３はグループトリガ（Group_Trigger）メッセージ３０１３を生成して、メンバリスト２１０１１内の全てのＳＡＮＥ−ＩＤ２２００１〜２２００３あてに送信する。ここで、シグナリンググループ管理部６１３は、この後、ＭＮトリガメッセージ３０１１内のローカルポリシー又は指示に基づいて、データエントリ２１０００（Srv_Group）を削除することもできる。
【００５５】
ここで、当業者であれば、ＭＮ１０１がＳＡＮＥ１０３及び／又はグループサーバ２０１の機能を実行するようにしてもよいことは明らかである。また、当業者であれば、グループ参加要求メッセージ３００７は、ＳＡＮＥ１０３がグループから出るために使用してもよいことは明らかである。この場合には、例えばＳＡＮＥ１０３がグループ参加要求メッセージ３００７内のグループ参加トークン１８０５としてエラーとなる値をセットすることにより、グループサーバ２０１の記録からＳＡＮＥ１０３の情報を除去することができる。
【００５６】
＜第２の実施の形態＞
第１の実施の形態では、グループサーバ２０１について説明したが、当業者であれば、本発明は仮想の分散型グループサーバについても適用することができることは明らかである。第２の実施の形態は、マルチキャスト手法を用いることにより実現することができる。第２の実施の形態では、ＭＮ１０１には、グループの代わりに、ＩＰマルチキャストグループアドレスが割り当てられる。ＭＮ１０１はこのアドレスをアウトオブバンド手法(Out of Band Methods)から使用する権利を取得する。例えばＭＮ１０１は非特許文献４に示すＭＡＤＣＡＰ（Multicast Address Dynamic Client Allocation Protocol）を用いて、マルチキャストアドレスをサーバに要求する。ＭＮ１０１が送信する予約メッセージ３００５は、ＩＰマルチキャストグループアドレスと、非特許文献５に示すＲＰ（Rendezvous Point）の２つの情報要素を有する。ＩＰマルチキャストグループアドレスは、本実施の形態においては、第１の実施の形態における「グループＩＤ」と等価であり、ＲＰは「グループサーバＩＤ」と等価である。
【００５７】
ＳＡＮＥ１０３は予約メッセージ３００５を受信すると、ＰＩＭ（Protocol Independent Multicast）参加メッセージをＲＰに送信してＩＰマルチキャストグループアドレスに参加する。ＰＩＭ参加メッセージは、第１の実施の形態におけるグループ参加要求メッセージ３００７と同様な情報を含み、ＰＩＭ参加メッセージによりマルチキャスト分散ツリーを構築する。このため、ＳＡＮＥのメンバリストは中央のサーバにより維持されず、代わりに、ＲＰに対してマルチキャストをサポートする全てのルータ上にツリー情報の一部として保持される。
【００５８】
したがって、新しい位置に到着したＭＮ１１０は、ＭＮトリガメッセージ３０１１をＲＰあてに送信する。ＲＰはＭＮトリガメッセージ３０１１をグループトリガメッセージ３０１３のフォーマットに変換してこれをＩＰマルチキャストグループアドレスあてに送信する。グループトリガメッセージ３０１３はマルチキャストツリーに沿って転送され、結果としてＳＡＮＥ１０３に到達する。
【００５９】
＜第３の実施の形態＞
本発明はまた、マルチキャストユーザプレーンのシグナリングをサポートするために用いることができる。図６は第３の実施の形態のネットワークの構成例を示し、ＭＮ７０１、７２１は同じであってそれぞれ移動前、移動後を示す。図６において、送信元ノード７０９はＩＰトラフィックをマルチキャストグループ（M_G）あてに送信する。マルチキャストグループ（M_G）には、受信側ノード７１１（Receiver-1）、７１５（Receiver-2）及び移動前のＭＮ７０１の３つの受信側ノードが存在する。受信側ノード７１１はＳＡＮＥ７１３（ＳＡＮＥ−３）、７０７（ＳＡＮＥ−２）を経由して送信元ノード（Source）７０９に接続され、受信側ノード７１５はネットワーク・エンティティ（ＮＥ）７０３、ＳＡＮＥ７０５（ＳＡＮＥ−１）、７０７を経由して送信元ノード７０９に接続され、移動前のＭＮ７０１はＮＥ７０３、ＳＡＮＥ７０５、７０７を経由して送信元ノード７０９に接続される。
【００６０】
非特許文献３のＲＳＶＰにより、ＱｏＳのためのシグナリングが３つの受信側ノード７１１、７１５、７０１から送信元ノード７０９あてにそれぞれ行われる。ここで、受信側ノード７１１がＱｏＳレベルＱ１を要求して、ＱｏＳレベルＱ１はＭＮ７０１が要求するＱｏＳレベルＱ２より高く、ＳＡＮＥ７１３、７０７がＱｏＳレベルＱ１のＱｏＳ予約ステートをインストールするものとする。ＭＮ７０１からのＱｏＳレベルＱ２のＱｏＳ予約メッセージがＳＡＮＥ７０７に到達すると、ＳＡＮＥ７０７には既にそれより高いＱｏＳ予約ステートが存在するので、ＭＮ７０１からのＱｏＳレベルＱ２のＱｏＳ予約メッセージは無視される。同様に、もし、受信側ノード７１５のＱｏＳ要求レベルＱ３がＱｏＳレベルＱ２より低い場合は、ＳＡＮＥ７０５におけるＱｏＳステートは、ＱｏＳレベルＱ２のみとなる。
【００６１】
したがって、第１の実施の形態で説明した構成はこの接続例にも適用することができる。「グループ情報」を有する予約メッセージ３００５はＳＡＮＥ７０５のみにより処理される。この場合、ＳＡＮＥ７０５のみがグループ参加要求メッセージ３００７をグループサーバ７２５あてに送信する。ＭＮ７０１が新しい位置に移動してネットワーク７２３に接続した場合（図のＭＮ７２１）、ＳＡＮＥ７０５における古いパス上のＱｏＳ予約ステートは破棄されるべきである。第１の実施の形態では、グループサーバ７２５あてに送信されたＭＮトリガメッセージ３０１１は、グループトリガメッセージ３０１３に変換され、グループサーバ７２５に登録されているＳＡＮＥ７０５に送信される。これが望ましい動作である。
【００６２】
この場合、第３の実施の形態では、マルチキャスト予約ステートが変化する。例えば受信側ノード７１１が移動前のＭＮ７０１の後に予約シグナリングを開始し、この場合には、ＳＡＮＥ７０７上の予約ステートが、レベルＱ２からレベルＱ１に切り替えられる。予約ステートの切り替え中は、ＳＡＮＥ７０７はグループサーバ７２５あてにメッセージを発行して登録を削除すべきである。これは、「グループ参加トークン」をエラー値にセットしたグループ参加要求メッセージ３００７をグループサーバ７２５あてに送信することにより実現することができる。
【００６３】
＜第４の実施の形態＞
第４の実施の形態では、大きなネットワーク環境に適用するためには、グループ管理を最適化してグループ識別子のスペースがなくなることを防止する。これは、移動前の同じＭＮ１０１からの異なるセッションにグループを分担することにより実現することができる。例えば送信元アドレスでグループを多重化して、送信元が固有のマルチキャストグループに多重化することができる。これをサポートするには、グループサーバ２０１におけるデータエントリ（Srv_Group）に送信元アドレスの情報を追加する必要がある。さらに、「グループ情報」は送信元情報を含むべきである。この場合には、対応するＳＡＮＥは特定の送信元アドレスでグループに参加する。ＭＮ１０１は、メッセージをグループサーバ２０１に送信する際、送信元情報をそのメッセージに記述するか、又はグループサーバ２０１が、対応するＳＡＮＥに送信可能なようにワイルドカードの送信元情報を使用する。
【００６４】
＜第５の実施の形態＞
第５の実施の形態では、グループサーバ２０１がユニキャストアドレスに依存する方法でメッセージを送信する必要がある場合、グループサーバ２０１はＮＡＴトラバース機能を実行することができる。例えばグループサーバ２０１が非特許文献１におけるスタンサーバの機能を実行して、ＮＡＴドメインにおけるＳＡＮＥに、ＮＡＴによって割り当てられるパブリックアドレスを通知する。グループサーバ２０１自身がＮＡＴドメイン１００内に位置する際、スタンサーバの機能を使用して、ＭＮ１０１あてのグループ登録確認メッセージ３００３を送信するのに使用するパブリックアドレスを取得する。
【００６５】
＜第６の実施の形態＞
ここで、上記の第１〜第５の実施の形態では、移動前のＭＮ１０１の古いパスを確立している全てのＳＡＮＥ１０３がグループ参加（Group_Join）要求メッセージ３００７をグループサーバ２０１あてに送信し、また、グループサーバ２０１が全てのＳＡＮＥ１０３にグループトリガ（Group_Trigger）メッセージ３０１３を送信するので、メッセージ数が多い。そこで、以下に示す第６〜第９の実施の形態では、メッセージ数を減少するために、移動前のＭＮ１０１の古いパスを確立している、アドレスドメイン内外それぞれ１つのＳＡＮＥが代表ノードとしてグループ参加（Group_Join）要求メッセージをグループサーバあてに送信し、また、グループサーバがそのＳＡＮＥにのみグループトリガ（Group_Trigger）メッセージを送信するようにしている。さらに、グループトリガ（Group_Trigger）メッセージを受信した代表ノードの各ＳＡＮＥは、それぞれアドレスドメイン内外の他のノードあてに破棄メッセージを送信する。
【００６６】
図１７は第６（及び第７、第８、第９）の実施の形態のネットワーク構成を示す。移動前のＭＮ８０１とＣＮ８１１との間の通信セッションは、リンク８３１、ＳＡＮＥ８０３、リンク８３３、ＳＡＮＥ８０５、リンク８３５、ＮＡＴ８０７、リンク８３７、ＳＡＮＥ８０９、リンク８３９を介して確立されている。そして、これらのノードのうち、ＭＮ８０１、ＳＡＮＥ８０３、ＳＡＮＥ８０５は、アドレスドメイン８００内、すなわちＮＡＴ８０７のプライベート側に位置し、また、ＳＡＮＥ８０９、ＣＮ８１１は、アドレスドメイン８００外、すなわちＮＡＴ８０７のパブリック側に位置している。さらに、全てのノード（ＭＮ８０１、ＳＡＮＥ８０３、ＳＡＮＥ８０５、ＳＡＮＥ８０９、ＣＮ８１１）は、ネットワーク８３０を経由してグループサーバ８２１とコネクションを有する。ここで、当業者であれば、グループサーバ８２１に対するコネクションは、図１７と異なってもよいことは明らかであり、本発明を限定しない。
【００６７】
次にある時点で、ＭＮ８０１がアドレスドメイン８００の外側の位置（図のＭＮ８２３）に移動したものとする。移動先のＭＮ８２３は、ドメイン８００内で確立している移動前のＭＮ８０１のパスを破棄するためのシグナリングメッセージを全てのＳＡＮＥ８０３、８０５、８０９及びＣＮ８１１に送るために、グループサーバ８２１を使用してそのメッセージをリレーさせる。
【００６８】
＜動作シーケンス＞
図１８は第６の実施の形態の動作シーケンスの一例を示す。第６の実施の形態では、移動前のＭＮ８０１から最初のホップのＳＡＮＥ８０３と、ＮＡＴ８０７から最初のホップのＳＡＮＥ８０９が代表ノードとなってグループ登録を行う。
（１）まず、移動前の位置のＭＮ８０１は、グループサーバ情報（第１の実施の形態のグループ情報[Group Info]）を取得する。このグループ情報の取得は、第１の実施の形態（図２参照）におけるグループ登録（Group_Register）要求メッセージ３００１とグループ登録確認（Group_Confirm）メッセージ３００３をやり取りすることにより実現することができる。また、他の方法として、ネットワークを介したブロードキャストアクセス制御機能や、ＩＥＥＥ８０２．２１ function [6] の情報サービスを使用してＭＮ８０１がグループ情報を取得することもできる。
【００６９】
（２）次に、ＭＮ８０１はこの取得したグループ情報を、ＣＮ８１１に対するセッション確立用のシグナリングメッセージ、例えばＭＮシグナリング（MN_SIG）メッセージ９００３内に埋め込んで送信する。なお、ＭＮシグナリング（MN_SIG）メッセージ９００３は、ＭＮ８０１が発行するリソース予約メッセージ３１０５（図２）や、ＣＮ８１１がこのリソース予約メッセージを受信して送り返すリソース応答メッセージでもよい。ＭＮシグナリング（MN_SIG）メッセージ９００３はシグナリング・ホップカウンタを含む。このホップカウンタは、ＭＮシグナリング（MN_SIG）メッセージ９００３が通過するＳＡＮＥ毎にインクリメントされる。例えばＭＮ８０１でホップカウンタが「０」にセットされたＭＮシグナリング（MN_SIG）メッセージ９００３が送信され、ＳＡＮＥ８０３がこのメッセージ９００３を受信すると、メッセージ９００３内のホップカウンタを「１」にインクリメントして、次のＳＡＮＥ８０５あてのＭＮシグナリング（MN_SIG）メッセージ９００９内にセットして送信し、以下同様にしてホップカウンタがＳＡＮＥ毎にインクリメントされる。また、ＳＡＮＥ８０３はこのインクリメントしたホップカウンタ値をストアする。
【００７０】
（３）ＳＡＮＥ８０３はメッセージ９００３を受信するとホップカウンタ値（＝０）をチェックして、自身がＭＮ８０１からの第１ホップのＳＡＮＥであると認識し、グループ情報[Group Info]が示すグループサーバ８２１にこれを登録する。図１８では、ＳＡＮＥ８０３はこの登録を、グループサーバ８２１に送信するグループ参加（Group_Join）要求メッセージ９００５で行う。グループ参加（Group_Join）要求メッセージ９００５は、第１の実施の形態で説明した各情報（図１２参照）により構成されるが、オプションとして、ＭＮシグナリング（MN_SIG）メッセージ９００３で用いられているメッセージルーティング情報、例えば非特許文献２で定義されているフロー識別子を含んでもよい。
（４）また、オプションとして、グループサーバ８２１は、上記の登録を確認するグループ参加応答（Group Response）メッセージ９００７を返信する。
【００７１】
（５）次に、ＳＡＮＥ８０３はメッセージルーティング情報に基づいて、ＭＮシグナリング（MN_SIG）メッセージ９００９を次のホップのＳＡＮＥ８０５に送信する。このとき、送信前に必要な更新、例えばホップカウンタ値のインクリメントを行っておく。
（６）ＳＡＮＥ８０５はメッセージ９００９内のホップカウンタ値（＝１）により最初のホップのノードでないことを認識し、上記の（３）におけるグループサーバ８２１への登録を行う必要はない。このため、ＳＡＮＥ８０５は必要な更新、例えばホップカウンタ値をインクリメントした後、ＭＮシグナリング（MN_SIG）メッセージ９０１１を次のホップのＳＡＮＥ８０９に送信する。
【００７２】
（７）ＳＡＮＥ８０９はメッセージ９０１１を受信すると、ＮＡＴ８０７の存在を検知する。このＮＡＴ８０７検知は単に、メッセージ９０１１のパケット内のＩＰヘッダと、メッセージ９０１１内に埋め込まれているメッセージルーティング情報を比較することにより実現することができる。例えばＩＰヘッダの送信元アドレスがメッセージルーティング情報の送信元アドレスが異なる場合、メッセージ９０１１はＮＡＴ８０７を通過したことを示すからである。なお、ＮＡＴ８０７はメッセージ９０１１をインタセプトできる場合、アドレス境界を横切った（cross）ことを示す特別な情報をメッセージ９０１１内に挿入してもよい。
【００７３】
ＳＡＮＥ８０９は、受信したメッセージ９０１１内の「グループ情報」を用いて、自身をグループサーバ８２１に登録する。図１８では、ＳＡＮＥ８０９はこの登録を、グループサーバ８２１に送信するグループ参加（Group_Join）要求メッセージ９０１３で行う。このメッセージ９０１３のフォーマットは、例えば図１９及び以下のように構成される。
Group_Join：
・グループサーバＩＤ２３００１ [Group Server ID]
・ＳＡＮＥ−ＩＤ２３００３ [SANE ID]
・グループ参加トークン２３００５[Group Join Token]
・ホップカウンタ値２３００７[Hop Counter]
・メッセージルーティング情報２３００９[(Optional)Message Routing Information]
【００７４】
すなわち、このメッセージ９０１３は、第１の実施の形態（図１２）のグループ参加（Group_Join）要求メッセージ３００７内の情報の他に、受信したＭＮシグナリング（MN_SIG）メッセージ９０１１内に埋め込まれているホップカウンタ値２３００７を含む。また、オプションとしてＳＡＮＥ８０９は、ステートなし（stateless）モードで動作する場合、メッセージ９０１３内にメッセージルーティング情報２３００９を含ませてもよい。
【００７５】
（８）グループサーバ８２１はオプションとして、上記の登録を確認するグループ参加応答（Group Response）メッセージ９０１５を返信する。
（９）ＳＡＮＥ８０９は、ＭＮシグナリング（MN_SIG）メッセージ９０１７をＣＮ８１１あてに送信する。このとき、送信前にメッセージ９０１７内の必要な更新を行っておく。この更新は、ホップカウンタ値２３００７のインクリメントと、メッセージルーティング情報２３００９を新しいアドレスにマッチさせる処理を含む。ＣＮ８１１は受信したメッセージ９０１７を終端する。
【００７６】
（１０）ＭＮ８０１が新しい位置（ＭＮ８２３）に移動すると、ＭＮ８２３は元のパス上のＳＡＮＥにシグナリングするために、グループサーバ８２１あてにＭＮトリガ（MN_Trigger）メッセージ９０１９を送信する。このメッセージ９０１９は第１の実施の形態におけるＭＮトリガ（MN_Trigger）メッセージ３０１１と同じ内容を含む。
【００７７】
（１１）（１２）グループサーバ８２１はＭＮトリガ（MN_Trigger）メッセージ９０１９を受信すると、自身が登録しているＳＡＮＥをチェックする。この例では、ＳＡＮＥ８０３、８０９が登録されている。グループサーバ８２１は、受信したメッセージ９０１９をグループトリガ（Group_Trigger）メッセージ９０２１、９０２３に変換し、登録されているＳＡＮＥ８０３、８０９にそれぞれ送信する。このメッセージ９０２１、９０２３のフォーマットは、例えば図２０及び以下のように構成される。
Group_Trigger：
・ＳＡＮＥ−ＩＤ２４００１ [SANE ID]
・グループ情報２４００３[Group Info]
・シグナリングメッセージ内容２４００５[Signaling Message Content]
・ホップカウンタ２４００７[Hop Counter]
・メッセージルーティング情報２４００９[(Optional)Message Routing Information]
【００７８】
すなわち、このメッセージ９０２１、９０２３は、第１の実施の形態におけるグループトリガ（Group_Trigger）メッセージ３０１３内に含まれる情報（図１４）の他に、ＳＡＮＥ８０９により送信されたホップカウンタ値２４００７を含む。さらに、もし、ＳＡＮＥ８０３、８０９がそれぞれグループ参加（Group_Join）要求メッセージ９００５、９０１３内にメッセージルーティング情報２３００９を含ませた場合には、メッセージルーティング情報２４００９として、ホップカウンタ値２４００７とともにグループトリガ（Group_Trigger）メッセージ９０２１、９０２３内に含まれなければならない。
【００７９】
（１３）（１４）ＳＡＮＥ８０３、８０９はそれぞれ、メッセージ９０２１、９０２３を受信すると、メッセージ９０２１、９０２３からシグナリングメッセージ内容２４００５を取り出す。そして、ＳＡＮＥ８０３、８０９は、移動前のＭＮ１０１の古いパスのステートを破棄し、また、そのリソースを解放する処理を実行する。また、ＳＡＮＥ８０３、８０９はそれぞれ、ＳＡＮＥ８０５、ＣＮ８１１に移動前のＭＮ１０１の古いパスのステートを破棄させ、また、そのリソースを解放させるために、ストアしているメッセージルーティング情報を用いて、オンパス（on-path）シグナリングメッセージであるＭＮメッセージ（MN_MSG）９０２５、９０２７をＣＮ８１１の方向に送信する。
【００８０】
また、ＳＡＮＥ８０３、８０９はＭＮメッセージ（MN_MSG）９０２５、９０２７を送信する際に、受信したグループトリガ（Group_Trigger）メッセージ９０２１、９０２３内のホップカウンタ値２４００７と、ストアしているホップカウンタ値を比較する。ここでは、ＳＡＮＥ８０３は、受信したメッセージ９０２１内のホップカウンタ値２４００７の方が大きいので、ＭＮメッセージ（MN_MSG）９０２５を送信する際に、メッセージ９０２５の転送範囲であるホップリミット数をセットする。このホップリミット数は、受信した方とストアしている方のホップカウンタ値の差分から計算される。例えば受信した方のホップカウンタ値２４００７が３、ストアしている方のホップカウンタ値が１の場合には、ホップリミット数＝２にセットされ、ＭＮメッセージ（MN_MSG）９０２５は２回のホップで終了する。
【００８１】
他の方法として、ＳＡＮＥ８０３は単に、受信したグループトリガ（Group_Trigger）メッセージ９０２１内のホップカウンタ値２４００７を「ホップカウンタリミット数」としてＭＮメッセージ（MN_MSG）９０２５内に埋め込むとともに、ＭＮメッセージ（MN_MSG）９０２５内のホップカウンタ値を、ストアしているホップカウンタ値にセットする。そして、ＳＡＮＥ８０５は、受信したＭＮメッセージ（MN_MSG）９０２５内のホップカウンタ値を更新し、その更新した値と「ホップカウンタリミット数」が等しい場合にＭＮメッセージ（MN_MSG）９０２５の上流への転送を停止する。ここで、当業者であれば、ＭＮメッセージ（MN_MSG）９０２５のホップリミット数は他の方法を用いてもよく、本発明を限定しないことは明らかである。
【００８２】
グループサーバ８２１からグループトリガ（Group_Trigger）メッセージ９０２３を受信したＳＡＮＥ８０９は、受信したホップカウンタ値２４００７が、ストアしているホップカウンタ値より小さい場合、ＭＮメッセージ（MN_MSG）９０２７のホップリミット数を処理する必要はなく、このメッセージ９０２７はＣＮ８１１により終端される。
【００８３】
ここで、ＳＡＮＥ８０３、８０９は、ステートなし（stateless）の場合、すなわちいかなるシグナリングステートも維持しない場合、ＳＡＮＥ８０３、８０９の識別子と各メッセージルーティング情報２３００９をグループ参加（Group_Join）要求メッセージ９００５、９０１３内に含ませる必要がある。この情報２３００９は、グループサーバ８２１がグループトリガ（Group_Trigger）メッセージ９０２１、９０２３を送信するときに含まれる。ＳＡＮＥ８０３、８０９は、グループトリガ（Group_Trigger）メッセージ９０２１、９０２３を受信すると、ＭＮメッセージ（MN_MSG）９０２５、９０２７を構成する際に、この識別子をチェックして各メッセージルーティング情報２３００９を使用する。ＳＡＮＥ８０３、８０９の識別子は、識別可能なユニークな値でよく、例えばＭＡＣアドレスや十分に大きくランダムな値でよい。
【００８４】
＜第７の実施の形態＞
図２１は第７の実施の形態として、図１７に示したネットワーク構成における他の動作シーケンスの一例を示す。第７の実施の形態では、ＮＡＴ８０７から最初のホップのＳＡＮＥ８０９、８０５が代表ノードとなってグループ登録を行う。
（１）まず、移動前の位置のＭＮ８０１は、図１８（１）と同様にグループサーバ情報（第１の実施の形態のグループ情報[Group Info]）を取得する。
（２）次に、ＭＮ８０１は、この取得したグループ情報を、ＣＮ８１１に対するセッション確立用のシグナリングメッセージ、例えばＭＮシグナリング（MN_SIG）メッセージ１０００３内に埋め込んで送信する。ここで、このＭＮシグナリング（MN_SIG）メッセージ１０００３は、図１８（２）のメッセージ９００３と同様であるが、ホップカウンタは不要である。
【００８５】
（３）ＳＡＮＥ８０３はこのメッセージ１０００３を受信すると、通常の対応処理を実行し、必要な更新を行った後、ＭＮシグナリング（MN_SIG）メッセージ１０００５を次のホップのＳＡＮＥ８０５に転送する。もし、このメッセージ１０００５がリソース予約メッセージの場合には、ＳＡＮＥ８０３は、要求されたリソースをこの予約メッセージのセッションに割り当てる。
（４）ＳＡＮＥ８０５においても同じ処理が行われ、また、ＭＮシグナリング（MN_SIG）メッセージ１０００７がＮＡＴ８０７を経由してＳＡＮＥ８０９に送信される。
【００８６】
（５）ＳＡＮＥ８０９はこのメッセージ１０００７を受信すると、ＮＡＴ８０７の存在を知得する。これは、受信したパケットのＩＰヘッダと、メッセージ１０００７内に埋め込まれているメッセージルーティング情報をチェックすることにより実現することができる。例えば、このＩＰヘッダとメッセージルーティング情報が異なる送信元アドレスを示している場合、ＳＡＮＥ８０９と前のホップのＳＡＮＥ８０５の間にＮＡＴが存在することを意味する。ＳＡＮＥ８０９はこれにより、グループ参加（Group_Join）要求メッセージ１０００９をグループサーバ８２１に送信することでグループ登録を行う。
（６）ＳＡＮＥ８０９はグループサーバ８２１から、オプションであるグループ参加応答（Group Response）メッセージ１００１１を受信する。
【００８７】
グループ参加（Group_Join）要求メッセージ１０００９とグループ参加応答（Group Response）メッセージ１００１１は、第１の実施の形態（図１２、図１３）と同じ構成でよいが、ＳＡＮＥ８０９がステートレスの場合には、グループ参加（Group_Join）要求メッセージ１０００９はさらに、ＳＡＮＥ識別子と、ＮＡＴ外フラグと、更新されたメッセージルーティング情報を含むようにしてもよい。これらの特別な情報はグループサーバ８２１にストアされる。
【００８８】
（７）次に、ＳＡＮＥ８０９は必要な更新を行った後、例えばメッセージルーティング情報を適合化した後、ＭＮシグナリング（MN_SIG）メッセージ１００１３をＣＮ８１１あてに送信する。このメッセージ１００１３はＣＮ８１１により終端される。
（８）ＳＡＮＥ８０９はまた、ＮＡＴ通知（NAT_NOTIFY）メッセージ１００１５をＳＡＮＥ８０５に送り返す。このメッセージ１００１５はＳＡＮＥ８０５に対し、ＳＡＮＥ８０５とＳＡＮＥ８０９の間にＮＡＴが存在することを通知するためのメッセージであり、そのフォーマットを図２２及び以下に示す。
NAT_NOTIFY：
・グループ情報２５００１[Group Info]
・ＮＡＴフラグ２５００３[NAT Flag]
・メッセージルーティング情報２５００５[Message Routing Information]
【００８９】
グループ情報２５００１は第１の実施の形態と同じである。ＮＡＴフラグ２５００３はＮＡＴ８０９の存在を示し、メッセージルーティング情報２５００５は、ＳＡＮＥ８０５がステートレスで動作する場合のためのオプションである。メッセージルーティング情報２５００５は、ＮＡＴドメイン８００内で使用されている情報、すなわちＳＡＮＥ８０５から受信したＭＮシグナリング（MN_SIG）メッセージ１０００７の情報である。
【００９０】
（９）（１０）ＳＡＮＥ８０５はＮＡＴ通知（NAT_NOTIFY）メッセージ１００１５を受信すると、グループ情報２５００１が示すグループサーバ８２１に登録を行う。この登録は、第１の実施の形態と同様にグループ参加（Group_Join）要求メッセージ１００１７とグループ参加応答（Group Response）メッセージ１００１９により行われる。ＳＡＮＥ８０５がステートレスで動作する場合、グループ参加（Group_Join）要求メッセージ１００１７はＳＡＮＥ識別子と、ＮＡＴ内フラグと、メッセージルーティング情報を含む。
【００９１】
（１１）ＭＮ８０１が新しい位置（ＭＮ８２３）に移動すると、ＭＮ８２３は元のパス上のＳＡＮＥにシグナリングするために、グループサーバ８２１あてにＭＮトリガ（MN_Trigger）メッセージ１００２１を送信する。このメッセージ１００２１は第１の実施の形態におけるＭＮトリガ（MN_Trigger）メッセージ３０１１と同じ内容を含む。
【００９２】
（１２）（１３）グループサーバ８２１はＭＮトリガ（MN_Trigger）メッセージ１００２１を受信すると、受信したメッセージ１００２１をグループトリガ（Group_Trigger）メッセージ１００２３、１００２５に変換し、登録されているＳＡＮＥ８０５、８０９にそれぞれ送信する。このメッセージ１００２３、１００２５のフォーマットは第１の実施の形態と同じであるが、オプションとしてＳＡＮＥ識別子と、ＮＡＴ内フラグ又はＮＡＴ外フラグと、メッセージルーティング情報を含むようにしてもよい。
【００９３】
（１４）（１５）ＳＡＮＥ８０５、８０９はグループトリガ（Group_Trigger）メッセージ１００２３、１００２５をそれぞれ受信すると、第６の実施の形態と同様にメッセージ１００２３、１００２５をそれぞれオンパス（on-path）シグナリングメッセージであるＭＮメッセージ（MN_MSG）１００２７、１００２９に変換する。そして、ＮＡＴドメイン８００内のノードであるＳＡＮＥ８０５は、このメッセージ１００２７を移動前のＭＮ８０１の方向に転送し、また、ＮＡＴドメイン８００外のノードであるＳＡＮＥ８０９は、このメッセージ１００２９をＣＮ８１１の方向に転送する。このとき、ＳＡＮＥ８０５、８０９はメッセージ１００２７、１００２９の転送方向を、ストアしているシグナリングステータスに基づいて決定する。
【００９４】
ＳＡＮＥ８０５、８０９は、ステートレスモードで動作する場合、グループ参加（Group_Join）要求メッセージ１００１７、１０００９内に必要な情報、例えばＮＡＴ内フラグ又はＮＡＴ外フラグと、メッセージルーティング情報と、ＳＡＮＥ識別子などを含ませる。グループサーバ８２１は、この情報をグループトリガ（Group_Trigger）メッセージ１００２３、１００２５内に含ませる。したがって、ステートレスモードのＳＡＮＥ８０５、８０９は、このメッセージ１００２３、１００２５をそれぞれ受信すると、この情報を用いて、ＭＮメッセージ（MN_MSG）１００２７、１００２９をルーティングさせるためのメッセージルーティング情報を生成する。この動作では、ＭＮメッセージ（MN_MSG）１００２７、１００２９は、自然に終端されるので、ホップリミット数を設ける必要はない。
【００９５】
＜第８の実施の形態＞
図２３は第８の実施の形態として、第６、第７の実施の形態の変形例の動作シーケンスの一例を示す。第８の実施の形態では、移動前のＭＮ８０１から最初のホップのＳＡＮＥ８０３が、また、ドメイン８００外ではＣＮ８１１（またはＳＡＮＥ８０９）が代表ノードとなる。
（１）まず、移動前の位置のＭＮ８０１は、図１８、図２１の（１）と同様にグループサーバ情報（第１の実施の形態のグループ情報[Group Info]）を取得する。
【００９６】
（２）次に、ＭＮ８０１は、この取得したグループ情報を、ＣＮ８１１に対して例えばＭＮシグナリング（MN_SIG）メッセージ１１００３を送信する。ここで、このＭＮシグナリング（MN_SIG）メッセージ１１００３内には、第６の実施の形態のホップカウンタの他に以下の情報が埋め込まれる。
・ＮＡＴが検出されたか否かを示すＮＡＴフラグ
・ＮＡＴドメイン８００内のＳＡＮＥ８０３、８０５がグループサーバ８２１に登録しているか否かを示すインサイドフラグ
・ＮＡＴドメイン８００外のＳＡＮＥ８０９がグループサーバ８２１に登録しているか否かを示すアウトサイドフラグ
【００９７】
なお、ＭＮ８０１は、どのＳＡＮＥがグループサーバ８２１に登録するかを示す判断基準を示すポリシーをメッセージ１１００３内に含めてもよい。また、ＭＮ８０１は、メッセージ１１００３を送信するときに、これらのＮＡＴフラグと、インサイドフラグとアウトサイドフラグをリセットする。この場合、メッセージ１１００３を受信したＳＡＮＥは、自身のローカル情報とメッセージ１１００３内の上記のポリシーに基づいて、自身をグループサーバ８２１に登録するか否かを決定することができる。ＮＡＴフラグと、インサイドフラグとアウトサイドフラグがセットされていない場合、そのＳＡＮＥは、自身のローカル情報と上記のポリシーが許可するときに自身をグループサーバ８２１に登録する。また、インサイドフラグとＮＡＴフラグがセットされ、かつアウトサイドフラグがセットされていない場合、そのＳＡＮＥは、自身をグループサーバ８２１に登録する。それ以外のＳＡＮＥは、自身をグループサーバ８２１に登録してはならない。
【００９８】
（３）例えばＳＡＮＥ８０３は、メッセージ１１００３内の上記の３つのフラグが全てセットされていないので、自身のローカル情報と上記のポリシーが許可するときに自身をグループサーバ８２１に登録すると決定する。そして、登録を決定したＳＡＮＥ８０３は、グループ参加（Group_Join）要求メッセージ１１００５をグループサーバ８２１に送信する。
（４）次に、ＳＡＮＥ８０３は、グループサーバ８２１から、オプションであるグループ参加応答（Group Response）メッセージ１１００７を受信する。要求メッセージ１１００５と応答メッセージ１１００７は第６、第７の実施の形態と同様なメッセージである。
【００９９】
（５）次に、ＳＡＮＥ８０３は、必要な更新を行った後、ＭＮシグナリング（MN_SIG）メッセージ１１００９を次のホップのＳＡＮＥ８０５に転送する。この更新とは、ＳＡＮＥ８０３がグループサーバ８２１に登録したので、インサイドフラグのセットを含む。
（６）ＳＡＮＥ８０５は、必要な更新を行った後、ＭＮシグナリング（MN_SIG）メッセージ１１０１１を次のホップに転送する。ここで、ＳＡＮＥ８０５は、ＳＡＮＥ８０３からのメッセージ１１００９内のインサイドフラグがセットされているので、グループサーバ８２１には登録を行わない。
【０１００】
（７）ＳＡＮＥ８０９は、ＳＡＮＥ８０５からのメッセージ１１０１１を受信すると、第６、第７の実施の形態と同様にＮＡＴ８０７の存在を検出する。これにより、ＳＡＮＥ８０９は、次のホップに転送するＭＮシグナリング（MN_SIG）メッセージ１１０１３内のＮＡＴフラグをセットする。さらに、ＳＡＮＥ８０９は、ＳＡＮＥ８０５から受信したメッセージ１１０１１内のホップカウンタ値を、次のホップに転送するメッセージ１１０１３内にＮＡＴカウンタとして挿入する。ここで、ＳＡＮＥ８０９は、自身のローカル条件と、ＳＡＮＥ８０５から受信したメッセージ１１０１１内のポリシーが許可する場合にグループサーバ８２１に登録することができる。しかし、この例では、ポリシーでは「ＣＮ８１１が登録する」と示されているので、ＳＡＮＥ８０９は登録を行わないものとする。
【０１０１】
（８）ＣＮ８１１は、ＳＡＮＥ８０９からのメッセージ１１０１３を受信すると、メッセージ１１０１３内のＮＡＴフラグとインサイドフラグはセットされているが、アウトサイドフラグがセットされていないことを知得し、グループサーバ８２１に登録を行う。ＣＮ８１１は、この登録をグループ参加（Group_Join）要求メッセージ１１０１５をグループサーバ８２１に送信することにより行う。ＣＮ８１１は、要求メッセージ１１０１５内にＮＡＴカウンタを含ませる。ＣＮ８１１はさらに、ホップカウンタ値をインクリメントし、また、それをストアする。
（９）次に、ＣＮ８１１は、グループサーバ８２１から、オプションであるグループ参加応答（Group Response）メッセージ１１０１７を受信する。要求メッセージ１１０１５と応答メッセージ１１０１７は第６、第７の実施の形態と同様なメッセージである。
【０１０２】
（１０）ＭＮ８０１が新しい位置（ＭＮ８２３）に移動すると、ＭＮ８２３は第６、第７の実施の形態と同様に、元のパス上のＳＡＮＥにシグナリングするために、グループサーバ８２１あてにＭＮトリガ（MN_Trigger）メッセージ１１０１９を送信する。
（１１）（１２）グループサーバ８２１は、受信したメッセージ１１０１９をグループトリガ（Group_Trigger）メッセージ１１０２１、１１０２３に変換し、登録されているＳＡＮＥ８０３、ＣＮ８１１にそれぞれ送信する。このメッセージ１１０２１、１１０２３は、第６、第７の実施の形態と同じ情報の他に、ＮＡＴカウンタを含む。
【０１０３】
（１３）ＳＡＮＥ８０３は、グループトリガ（Group_Trigger）メッセージ１１０２１を受信すると、第６、第７の実施の形態と同様に、このメッセージ１１０２１をＭＮメッセージ（MN_MSG）１１０２５に変換する。但し、ＳＡＮＥ８０３は、このＭＮメッセージ（MN_MSG）１１０２５をＣＮ８１１の方向と、元の位置のＭＮ８０１の方向の両方に送信する。また、ＳＡＮＥ８０３は、ＮＡＴドメイン８００内に位置するので、第６の実施の形態と同様に、ＣＮ８１１の方向のメッセージ１１０２５にはホップリミットを行う。このホップリミット数の計算は、グループトリガ（Group_Trigger）メッセージ１１０２１内のＮＡＴカウンタに基づいて行う。
【０１０４】
（１４）ＣＮ８１１は、グループトリガ（Group_Trigger）メッセージ１１０２３を受信すると、ＮＡＴドメイン８００外に位置するので、このメッセージ１１０２３をＭＮメッセージ（MN_MSG）１１０２７に変換し、元の位置のＭＮ８０１の方向に送信する。このメッセージ１１０２７を送信する際、ＣＮ８１１は、ホップリミットをかける。このホップリミット数の計算は、グループトリガ（Group_Trigger）メッセージ１１０２３内のＮＡＴカウンタと、ストアしていたホップカウンタ値に基づいて行う。例えばＭＮメッセージ（MN_MSG）１１０２７内のホップリミット数はホップカウンタ値−ＮＡＴカウンタ−１で計算する。
【０１０５】
ＭＮメッセージ（MN_MSG）１１０２７を受信した各ＳＡＮＥ、例えばＳＡＮＥ８０９はこのホップリミット数をデクリメントし、この更新したホップリミット数を次のホップあてのＭＮメッセージにセットしてこのＭＮメッセージを元の位置のＭＮ８０１の方向に転送する。ＳＡＮＥ８０９は、上記のデクリメント後のホップリミット数が０であることを知得すると、次のホップのノードにはＭＮメッセージを送信しない。
【０１０６】
ここで、当業者であれば、ＮＡＴドメイン８００の外側で登録されるＳＡＮＥはＣＮ８１１でない場合もあり得ることは明らかである。もし、ＳＡＮＥ８０９が登録されている場合には、ＳＡＮＥ８０９は、グループトリガ（Group_Trigger）メッセージ１１０２３を受信すると、このメッセージ１１０２３をＭＮメッセージ（MN_MSG）に変換し、ＣＮ８１１の方向にも送信しなければならない。また、ＮＡＴドメイン８００の外側のＳＡＮＥ８０９は、このＣＮ８１１の方向に送信するＭＮメッセージ（MN_MSG）には、ホップリミットを設ける必要はない。
【０１０７】
上記の第８の実施の形態では例外がある。例えばＮＡＴドメイン８００内のいずれのＳＡＮＥもグループサーバ８２１に登録しなかった場合、移動前のＭＮ８０１が送信したＭＮシグナリング（MN_SIG）メッセージ１１００３は、インサイドフラグがセットされないままでＣＮ８１１により受信される。この場合には、ＣＮ８１１が同じパスの逆方向にシグナリングメッセージを送信して、どのＳＡＮＥが登録すべきかを指示する必要がある。この指示は、ホップカウンタ値を用いることにより実現することができる。また、他の方法として、ＣＮ８１１は、ＮＡＴドメイン８００内の同じパスの逆方向における最初のＳＡＮＥが登録すべきであることをポリシー内に記述することにより指示することができる。
【０１０８】
上記の第８の実施の形態では、移動前のＭＮ８０１の古いパスのステートを破棄し、また、そのリソースを解放するためのＭＮメッセージ（MN_MSG）１１０２５、１１０２７の転送範囲は、ホップカウンタ値を用いることにより実現している。ここで、不安定なネットワーク環境では、セッション期間中に再ルーティングが発生するので、ホップカウンタ値は再ルーティング後には各ＳＡＮＥで変化する。したがって、ネットワークが不安定であるとＭＮ８０１、８２３、ＳＡＮＥ８０３、８０５、８０９が決定した場合、何かの安全対策が必要である。安全対策の例として、移動前のＭＮ８０１はＭＮシグナリング（MN_SIG）メッセージ１１００３で、ＳＡＮＥ８０３に特別な対策が必要であること、例えばＭＮメッセージ（MN_MSG）１１０２５を作成する際に「ＮＡＴドロップフラグ」を含むように指示することができる。ＳＡＮＥ８０５は、ＭＮメッセージ（MN_MSG）１１０２５内の「ＮＡＴドロップフラグ」を知得して、メッセージ１１０２５がＮＡＴ８０７まで届いたことを検出すると、メッセージ１１０２５をドロップする。また、他の方法として、ＮＡＴ８０７自身がメッセージ１１０２５をインタセプトして、「ＮＡＴドロップフラグ」を知得した場合にはメッセージ１１０２５をドロップしてもよい。
【０１０９】
＜第９の実施の形態＞
図２４は第９の実施の形態の動作シーケンスの一例を示す。ここで、ＮＡＴ８０７自身がＳＡＮＥであり、代表ノードとなる（なお、ＳＡＮＥ８０３は登録を行うが、取り消される。）。すなわち、ＮＡＴ８０７は全てのシグナリングメッセージをインタセプトして処理することができる。第９の実施の形態における動作は、第６、第７、第８の実施の形態の全てに適用することができるので、以下の説明では、重複する動作について説明を省略する。但し、ＮＡＴ８０７はシグナリングメッセージを処理するために特別な機能が必要である。
【０１１０】
（１）〜（４）第６、第７、第８の実施の形態と同様に、ＮＡＴドメイン８００内のＳＡＮ８０３は、グループ参加（Group_Join）要求メッセージ１２００５を用いてグループサーバ８２１に登録する。これにより、グループサーバ８２１においてエントリが生成される。
（５）〜（８）ＭＮシグナリング（MN_SIG）メッセージ１２０１１がＮＡＴ８０７に到達すると、ＮＡＴ８０７は、グループ参加（Group_Join）要求メッセージ１２０１３を用いてグループサーバ８２１に登録する。この要求メッセージ１２０１３は図２５に示すように、特別なフラグとして、この登録を、グループサーバ８２１において作成された同じパスの他のＳＡＮＥからのエントリと置き換えるよう要求する「ＮＡＴ置き換え（NAT-Replace）フラグ２６０１１を含む。要求メッセージ１２０１３内の他の情報２６００１、２６００３、２６００５、２６００７、２６００９は図１９と同じである。
【０１１１】
（９）（１０）次いで、ＮＡＴ８０７は、第６、第７、第８の実施の形態において必要な処理を行った後、ＭＮシグナリング（MN_SIG）メッセージ１２０１７をＣＮ８１１の方向に転送する。ここで、ＮＡＴ８０７はこのメッセージ１２０１７で、他のＳＡＮＥはグループサーバ８２１に登録しないように指示する。また、例として、第８の実施の形態に適用する場合には、ＮＡＴフラグと、インサイドフラグとアウトサイドフラグの３つのフラグをセットする。この動作により、グループサーバ８２１には、１つのＳＡＮＥすなわちＮＡＴ８０７が登録される。
【０１１２】
（１１）（１２）したがって、ＭＮ８０１が新しい位置（ＭＮ８２３）に移動して、グループサーバ８２１は、ＭＮ８２３からＭＮトリガ（MN_Trigger）メッセージ１２０２１を受信すると、グループトリガ（Group_Trigger）メッセージ１２０２３をＮＡＴ８０７のみに送信する。
（１３）（１４）ＮＡＴ８０７はこのメッセージ１２０２３を受信すると、第６、第７、第８の実施の形態と同様に、このメッセージ１２０２３をＭＮメッセージ（MN_MSG）１２０２５、１２０２９に変換する。ＮＡＴ８０７はメッセージ１２０２５を元の位置のＭＮ８０１の方向に向かってＮＡＴドメイン８００内に送信し、メッセージ１２０２９をＣＮ８１１の方向に向かってＮＡＴドメイン８００外に送信する。ここで、この２つのメッセージ１２０２５、１２０２９は、異なるメッセージルーティング情報を用いて転送される。また、この２つのメッセージ１２０２５、１２０２９は、それぞれＳＡＮＥ８０３、ＣＮ８１１により自然にストップされるので、ホップリミットを設ける必要はない。
【０１１３】
＜第１０の実施の形態＞
図２６は、第１０の実施の形態のネットワーク構成を示す。グループサーバ１３１３は、移動前のＭＮ１３０１が接続するネットワーク（移動元ＮＡＴドメイン）１３００に付属する。移動元ＮＡＴドメイン１３００内のＳＡＮＥ１３０１、１３０３、１３０５と、移動元ＮＡＴドメイン１３００外のＳＡＮＥ１３０９、ＣＮ１３１１とを含む全てのノードは、グループサーバ１３１３にアクセスする。当業者であれば、グループサーバ１３１３は物理的に移動元ＮＡＴドメイン１３００内に位置する必要はなく、移動元ＮＡＴドメイン１３００に接続する遠隔地に配置してもよいことは明らかである。ＭＮ１３０１は、移動元ＮＡＴドメイン１３００に接続するグループサーバ１３１３の情報をあらかじめ有するか、又はＤＮＳにより知得することができる。
【０１１４】
ＭＮ１３０１が新しい位置（ＭＮ１３２１）に移動して、ＭＮ１３２１が新しいネットワーク（移動先ＮＡＴドメイン）１３２０に接続したものとする。移動先ＮＡＴドメイン１３２０には同様なグループサーバ１３２５が接続している。ＭＮ１３２１はこの新しいグループサーバ１３２５の情報を他の手段で知得する。グループサーバ１３２５はグループサーバ１３１３に対してネットワーク１３３０を介して接続されている。
【０１１５】
第６、第７、第８、第９の実施の形態をこのネットワーク構成に適用した場合、移動先のＭＮ１３２１は、移動元のグループサーバ１３１３の情報を含むＭＮトリガ（MN_Trigger）メッセージを移動先のグループサーバ１３２５に送信する。グループサーバ１３２５はこのＭＮトリガ（MN_Trigger）メッセージを受信すると、このメッセージ内に埋め込まれている情報に基づいて元のグループサーバ１３１３にこのメッセージ転送を試みる。そして、このメッセージが元のグループサーバ１３１３に到達すると、第６、第７、第８、第９の実施の形態を適用することができる。
【０１１６】
上記のＭＮトリガ（MN_Trigger）メッセージ内に埋め込まれている移動元のグループサーバ１３１３の情報としては、グループサーバ１３１３自身のユニークなＩＤや、移動元ＮＡＴドメイン１３００のＩＤでよい。当業者であれば、ＭＮトリガ（MN_Trigger）メッセージは、移動先のグループサーバ１３２５から他のグループサーバを経由して移動元のグループサーバ１３１３に転送されてもよいことは明らかである。
【０１１７】
また、移動先のＭＮ１３２１が他の手段を介して、ＭＮトリガ（MN_Trigger）メッセージをローカルな移動先グループサーバ１３２５に送信してもよく、例えば移動先グループサーバ１３２５のアドレスにユニキャストしたり、移動先グループサーバ１３２５にエニキャスト又はマルチキャストしたり、特別なリンク層の手法を用いてもよい。特別なリンク層の手法としては、ＩＥＥＥ８０２．１x uncontrolled port すなわちＥＡＰメッセージを使用することができる。
【０１１８】
また、当業者であれば、移動先グループサーバ１３２５は、全ての機能を有する必要がないことは明らかであり、ＭＮトリガ（MN_Trigger）メッセージを受信して単に中継するプロキシでもよい。移動先グループサーバ１３２５の実際の機能は、いずれの位置に配置すればよく、また、実際のネットワークでは、グループサーバ１３１３、１３２５はＡＡＡ（Authentification, Authorization and Accounting）エージェントであるか、又はローカルポリシー機能であるか、又は単にローカルなＤＮＳサーバである。
【０１１９】
なお上記実施の形態はＮＡＴに限らず、他のドメイン、例えば非特許文献９におけるＧＧＳＮ(Gateway GPRS Support Node)やＰＤＮ(Packet Data Network)ゲートウェィが存在する場合に用いてもよい。
【０１２０】
なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブ ル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。
【産業上の利用可能性】
【０１２１】
本発明は、ローカルアドレスを使用するドメイン内からモバイルノードが外に移動した場合に、スタンサーバのような特別な手段を用いることなくドメイン内のモバイルノードの古いパスを破棄することができるという効果を有し、ＮＳＩＳ（Next Steps In Signaling）プロトコルを実行するシステムなどに利用することができる。
【図面の簡単な説明】
【０１２２】
【図１】本発明に係る通信システムの第１の実施の形態を示すブロック図
【図２】図１の通信システムの動作シーケンスを示す説明図
【図３】図１のモバイルノードを詳しく示すブロック図
【図４】図１のＳＡＮＥを詳しく示すブロック図
【図５】図１のグループサーバを詳しく示すブロック図
【図６】本発明に係る通信システムの第３の実施の形態を示すブロック図
【図７】従来の通信システムを示すブロック図
【図８】図２のグループ登録（Group_Register）要求メッセージのフォーマットを示す説明図
【図９】図２のグループ登録確認（Group_Confirm）メッセージのフォーマットを示す説明図
【図１０】図８、図９のグループ情報[Group Info]のフォーマットを詳しく示す説明図
【図１１】図２のＭＮトリガ（MN_Trigger）メッセージのフォーマットを示す説明図
【図１２】図２のグループ参加（Group_Join）要求メッセージのフォーマットを示す説明図
【図１３】図２のグループ参加応答（Group Response）メッセージのフォーマットを示す説明図
【図１４】図２のグループトリガ（Group_Trigger）メッセージのフォーマットを示す説明図
【図１５】データエントリ（Srv_Group）のフォーマットを示す説明図
【図１６】図１５のメンバリスト[Member List]のフォーマットを詳しく示す説明図
【図１７】第６、第７、第８、第９の実施の形態のネットワーク構成を示すブロック図
【図１８】第６の実施の形態の動作シーケンスを示す説明図
【図１９】図１８のグループ参加（Group_Join）要求メッセージのフォーマットを示す説明図
【図２０】図１８のグループトリガ（Group_Trigger）メッセージのフォーマットを示す説明図
【図２１】第７の実施の形態の動作シーケンスを示す説明図
【図２２】図２１のＮＡＴ通知（NAT_NOTIFY）メッセージのフォーマットを示す説明図
【図２３】第８の実施の形態の動作シーケンスを示す説明図
【図２４】第９の実施の形態の動作シーケンスを示す説明図
【図２５】図２４のグループ参加（Group_Join）要求メッセージのフォーマットを示す説明図
【図２６】第１０の実施の形態のネットワーク構成を示すブロック図
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2009001553.tif 000029
【図２】
2009001553.tif 000030
【図３】
2009001553.tif 000031
【図４】
2009001553.tif 000032
【図５】
2009001553.tif 000033
【図６】
2009001553.tif 000034
【図７】
2009001553.tif 000035
【図８】
2009001553.tif 000036
【図９】
2009001553.tif 000037
【図１０】
2009001553.tif 000038
【図１１】
2009001553.tif 000039
【図１２】
2009001553.tif 000040
【図１３】
2009001553.tif 000041
【図１４】
2009001553.tif 000042
【図１５】
2009001553.tif 000043
【図１６】
2009001553.tif 000044
【図１７】
2009001553.tif 000045
【図１８】
2009001553.tif 000046
【図１９】
2009001553.tif 000047
【図２０】
2009001553.tif 000048
【図２１】
2009001553.tif 000049
【図２２】
2009001553.tif 000050
【図２３】
2009001553.tif 000051
【図２４】
2009001553.tif 000052
【図２５】
2009001553.tif 000053
【図２６】
2009001553.tif 000054
【国際調査報告】
2009001553.tif 000055
2009001553.tif 000056
2009001553.tif 000057
2009001553.tif 000058