(57)【特許請求の範囲】
【請求項１】
付加的サービス提供に係る機能を有するルータを通じて、１つのセッションに対して、それぞれが経路種別を有する付加的サービス提供用の複数の通信経路を利用して、相手端末との間で通信を行うように構成されている端末における通信方法であって、
前記端末が、前記複数の通信経路のそれぞれに係る経路変化を検出する検出ステップと、
前記検出ステップにおいて検出された経路変化後の通信経路に対して提供される前記付加的サービスを制御するためのシグナリングメッセージであって、前記経路変化後の通信経路に係る前記経路種別を識別する前記経路種別識別子を含む前記シグナリングメッセージを生成するシグナリングメッセージ生成ステップと、
前記経路変化後の通信経路に係る前記経路種別識別子を含む前記シグナリングメッセージを、前記経路変化後の通信経路上に存在する前記ルータに対して送信するシグナリングメッセージ送信ステップとを、
有する通信方法。
【請求項２】
前記端末が、前記検出ステップにおいて検出された前記経路変化後の通信経路の前記経路種別を識別する識別ステップと、
前記識別ステップで識別された前記経路種別の情報に基づいて、前記経路変化後の通信経路に係る前記経路種別を識別する前記経路種別識別子を生成する経路種別識別子生成ステップと、
を有する請求項１に記載の通信方法。
【請求項３】
複数の付加的サービス提供用の前記通信経路のそれぞれの情報を、前記通信経路のそれぞれの経路種別を識別するための前記経路種別識別子と共に格納する経路種別識別子格納ステップを有する請求項２に記載の通信方法。
【請求項４】
前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する制御方法保持ステップを有する請求項２又は３に記載の通信方法。
【請求項５】
前記制御方法保持ステップにおいて保持されている前記制御方法に係る情報を参照して、前記複数の通信経路のそれぞれの前記経路種別に対応した前記制御方法を決定する制御方法決定ステップと、
前記シグナリングメッセージ生成ステップで生成される前記シグナリングメッセージに、前記制御方法決定ステップにより決定された前記制御方法に係る情報を更に含める制御方法付加ステップとを、
有する請求項４に記載の通信方法。
【請求項６】
前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する特定のサーバとの通信を行い、前記制御方法に係る情報を取得するサーバ通信ステップと、
前記サーバ通信ステップにおいて取得された前記制御方法に係る情報を参照して、前記複数の通信経路のそれぞれの前記経路種別に対応した前記制御方法を決定する制御方法決定ステップと、
前記シグナリングメッセージ生成ステップで生成される前記シグナリングメッセージに、前記制御方法決定ステップにより決定された前記制御方法に係る情報を更に含める制御方法付加ステップとを、
有する請求項２又は３に記載の通信方法。
【請求項７】
付加的サービス提供に係る機能を有するルータを通じて、１つのセッションに対して、それぞれが経路種別を有する付加的サービス提供用の複数の通信経路を利用して、相手端末との間で通信を行うように構成されている端末における通信方法であって、
前記端末が、前記通信経路に係る経路変化を検出する検出ステップと、
前記端末が、前記検出ステップにおいて検出された経路変化後の通信経路の前記経路種別を識別する識別ステップと、
前記経路変化後の通信経路に関し、前記識別ステップで識別された前記経路種別の情報を含むメッセージを生成するメッセージ生成ステップと、
前記メッセージ内の前記経路種別の情報に基づいて、前記経路変化後の通信経路の前記経路種別を識別するための経路種別識別子を生成し、前記経路変化後の通信経路に対して提供される前記付加的サービスを制御するためのシグナリングメッセージであって、前記経路変化後の通信経路に係る前記経路種別識別子を含む前記シグナリングメッセージを生成し、前記経路変化後の通信経路に係る前記経路種別識別子を含むシグナリングメッセージを、前記経路変化後の通信経路上に存在する前記ルータに対して送信する機能を有する特定のプロキシノードに対して、前記メッセージ生成ステップで生成された前記メッセージを送信するメッセージ送信ステップとを、
有する通信方法。
【請求項８】
前記端末が、無線移動帯通信機能を有する移動端末であって、前記検出ステップにおいて、前記端末の移動に伴う前記通信経路に係る経路変化が検出される請求項７に記載の通信方法。
【請求項９】
前記端末が、現在通信中、又はハンドオーバ可能な無線アクセスポイントのリンクの状態を監視するリンク状態監視ステップを有し、前記シグナリングメッセージ生成ステップにおいて、前記リンク状態を考慮した前記付加的サービスに対する要求を含む前記シグナリングメッセージを生成する請求項８に記載の通信方法。
【請求項１０】
前記端末がモバイルＩＰの機能を有しており、前記検出ステップにおいて、前記モバイルＩＰに係る位置登録完了メッセージの受信によって、前記通信経路に係る経路変化を検出する請求項８に記載の通信方法。
【請求項１１】
前記経路種別識別子が、モバイルＩＰにおける三角経路又は最適化経路を識別するものである請求項１０に記載の通信方法。
【請求項１２】
前記端末が、複数のインタフェースを有するとともに、前記複数のインタフェースのそれぞれを利用して前記相手端末との間で通信を行うように構成されており、前記経路種別識別子が、前記複数のインタフェースのそれぞれを識別するものである請求項２又は７に記載の通信方法。
【請求項１３】
前記端末が互いに関連のあるセッションを有する場合、前記互いに関連のあるセッションに対して同一のセッション識別子が付与されるとともに、前記経路種別識別子が、前記互いに関連のあるセッションの方向を示す情報である請求項２に記載の通信方法。
【請求項１４】
前記付加的サービスがＱｏＳ保証である請求項２又は７に記載の通信方法。
【請求項１５】
請求項２又は７に記載の通信方法をコンピュータにより実行するための通信方法用プログラム。
【請求項１６】
付加的サービス提供に係る機能を有しており、端末が、１つのセッションに対して、それぞれが経路種別を有する付加的サービス提供用の複数の通信経路を利用して、相手端末との間で通信を行う際の前記複数の通信経路のうちの少なくとも１つの通信経路上に配置されるルータにおける通信メッセージ処理方法であって、
前記複数の通信経路のそれぞれに対して提供される前記付加的サービスを制御するためのシグナリングメッセージであって、前記ルータが配置されている前記通信経路の前記経路種別を識別するための経路種別識別子を含む前記シグナリングメッセージを受信するシグナリングメッセージ受信ステップと、
前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内の前記経路種別識別子を含む前記付加的サービス提供に係るステートを作成し、格納するステート格納ステップと、
前記経路種別識別子が示す前記経路種別に基づいて、前記付加的サービス提供に係るステート処理方法を決定するステート処理方法決定ステップと、
前記ステート処理決定ステップで決定された前記ステート処理方法に基づいて、前記付加的サービスが提供される前記通信経路に関するステートを処理するステート処理ステップとを、
有する通信メッセージ処理方法。
【請求項１７】
前記通信経路に対して提供される前記付加的サービスを制御するための前記シグナリングメッセージが、前記通信経路における制御方法に係る情報を含ませることが可能な領域を有する請求項１６に記載の通信メッセージ処理方法。
【請求項１８】
前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内に、前記通信経路における制御方法に係る情報が更に含まれていた場合には、前記ステート処理決定方法において、前記制御方法に係る情報に基づいて、前記付加的サービス提供に係るステート処理方法を決定する請求項１７に記載の通信メッセージ処理方法。
【請求項１９】
前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する制御方法保持ステップを有し、前記ステート処理決定方法において、前記制御方法に係る情報に基づいて、前記付加的サービス提供に係るステート処理方法を決定する請求項１６から１８のいずれか１つに記載の通信メッセージ処理方法。
【請求項２０】
前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する特定のサーバとの通信を行い、前記通信経路の制御方法に係る情報を取得するサーバ通信ステップを有し、前記ステート処理決定方法において、前記制御方法に係る情報に基づいて、前記付加的サービス提供に係るステート処理方法を決定する請求項１６から１８のいずれか１つに記載の通信メッセージ処理方法。
【請求項２１】
前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内の前記経路種別識別子を参照し、前記通信経路の前記経路種別が、モバイルＩＰにおける三角経路及び最適化経路のどちらであるかを判別する経路判別ステップを有する請求項１６から１８のいずれか１つに記載の通信メッセージ処理方法。
【請求項２２】
前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージに係るフロー識別子を参照して、前記ステート格納ステップで格納された同一フロー識別子に係るステートが存在するか否かを判断するフロー識別子比較ステップと、
前記フロー識別子比較ステップで前記同一フロー識別子に係るステートが存在する場合、前記シグナリングメッセージを受信した前ホップノード及び前記シグナリングメッセージを送信する次ホップノードと、前記ステート格納ステップで格納された同一フロー識別子に係るステートに係る前ホップノード及び次ホップノードとの比較を行うことにより、前記端末が、同一サブネット配下又はそれぞれ異なるサブネット配下で確立した前記三角経路と前記最適化経路とのクロスオーバノードであるか否かを判断するクロスオーバ判断ステップを有する請求項２１に記載の通信メッセージ処理方法。
【請求項２３】
前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内の前記経路種別識別子を参照し、前記通信経路の前記経路種別が、複数のインタフェースを有する前記端末の、どの前記インタフェースを用いた通信を示すものであるかを判別するインタフェース判別ステップを有する請求項１６から１８のいずれか１つに記載の通信メッセージ処理方法。
【請求項２４】
前記端末が互いに関連のあるセッションを有する場合、前記互いに関連のあるセッションに対して同一のセッション識別子が付与されるとともに、前記経路種別識別子が、前記互いに関連のあるセッションの方向を示す情報である請求項１６に記載の通信メッセージ処理方法。
【請求項２５】
前記シグナリングメッセージが、ＮＳＩＳ ＱｏＳメッセージにおけるＲＥＳＥＲＶＥメッセージに含まれる内容を有している請求項１６に記載の通信メッセージ処理方法。
【請求項２６】
請求項１６に記載の通信メッセージ処理方法をコンピュータにより実行するための通信メッセージ処理方法用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、互いにネットワークを介して通信を行う端末の通信方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムに関し、特に、次世代インターネットプロトコル（ＩＰ：Internet Protocol）であるモバイルＩＰを利用した無線通信を行う移動端末の通信経路に、ＮＳＩＳ（Next Step in Signaling）を用いたＱｏＳ（Quality of Service）保証を与えることに係る通信方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムに関する。
【背景技術】
【０００２】
移動端末から無線ネットワークを通じてインターネットなどの通信ネットワークにアクセスするユーザに対して、移動しながらでもシームレスに通信ネットワークの接続を提供できる技術として、次世代インターネットプロトコルであるモバイルＩＰを利用したものが普及してきている。このモバイルＩＰを利用した無線通信システムについて、図１を参照しながら説明する。なお、以下に説明するモバイルＩＰの技術に関しては、例えば、下記の非特許文献１や非特許文献２に開示されている。
【０００３】
図１に示す通信システムは、インターネットなどのネットワーク（通信ネットワーク）１７０、ネットワーク１７０に接続する複数のサブネットワーク（以下サブネットとする）１０２、１２６、これらの複数のサブネット１０２、１２６のいずれかに接続することが可能な移動端末（ＭＮ：Mobile Node）１００、ＭＮ１００とネットワーク１７０を介して通信を行う相手端末（ＣＮ：Corresponding Node）１２４を含んでいる。なお、図１では、複数のサブネットとして、２つのサブネット１０２、１２６が図示されている。また、ネットワーク１７０は、複数のネットワーク１１０、１１４、１１８、１３４、後述のＱｏＳなどの付加的サービスを提供することのできるルータ（ＱＮＥ：QoS NSIS Entity）１０８、１１２、１２０、１２２、１３２、後述のモバイルＩＰの端末位置登録機能を持ったノード（ＨＡ：Home Agent）１１６、及びこれらを接続するリンク１４０、１４２、１４４、１４６、１４８、１５０、１５２、１５６、１５８、１６０、１６２、１６４をネットワーク要素として構成されるが、ネットワーク１７０の構成はこれ以外の構成も考えられる。なお、図１では、付加的サービスを提供することのできるルータとして、後述のＮＳＩＳ ＱｏＳの機能を持ったルータであるＱＮＥが図示されている。
【０００４】
また、図１で、ＭＮ１００、ＡＰ１０４、ＡＲ１０６、リンク１４０、ＱＮＥ１０８、ネットワーク１１０、リンク１４２、ＱＮＥ１１２、リンク１４４、ネットワーク１１４、リンク１４６、ＨＡ１１６、リンク１４８、ネットワーク１１８、リンク１５０、ＱＮＥ１２０、リンク１５２、ＱＮＥ１２２、リンク１５６、ＣＮ１２４を経由する経路を、経路１８０とする。また、ＭＮ１００、ＡＰ１０４、ＡＲ１０６、リンク１４０、ＱＮＥ１０８、ネットワーク１１０、リンク１６４、ＱＮＥ１２０、リンク１５２、ＱＮＥ１２２、リンク１５６、ＣＮ１２４を経由する経路を経路１８２とする。また、ＭＮ１００、ＡＰ１２８、ＡＲ１３０、リンク１５８、ＱＮＥ１３２、ネットワーク１３４、リンク１６０、ＱＮＥ１１２、リンク１４４、ネットワーク１１４、リンク１４６、ＨＡ１１６、リンク１４８、ネットワーク１１８、リンク１５０、ＱＮＥ１２０、リンク１５２、ＱＮＥ１２２、リンク１５６、ＣＮ１２４を経由する経路を経路１８４とする。また、ＭＮ１００、ＡＰ１２８、ＡＲ１３０、リンク１５８、ＱＮＥ１３２、ネットワーク１３４、リンク１６２、ＱＮＥ１２２、リンク１５６、ＣＮ１２４を経由する経路を経路１８６とする。
【０００５】
サブネット１０２は、ＩＰパケットに対するルーティングを行うアクセスルータ（ＡＲ：Access Router）１０６、固有の無線カバーエリア（通信可能領域）を持つ複数のアクセスポイント（ＡＰ：Access Point）１０４により構成されている。このＡＰ１０４は、ＡＲ１０６に接続されており、ＡＲ１０６は、ＩＰネットワーク１７０に接続されている。なお、図１では、サブネット１０２における複数のＡＰとして、１つのＡＰ１０４が図示されている。また、サブネット１２６に関しても、ＡＲ１３０及び複数のＡＰ１２８により、上述のサブネット１０２と同一の接続態様によって構成されている。
【０００６】
また、サブネット１０２の構成要素であるＡＲ１０６と、サブネット１２６の構成要素であるＡＲ１３０とは、ＩＰネットワーク１７０を通じて通信を行うことが可能であり、すなわち、サブネット１０２とサブネット１２６とは、ＩＰネットワーク１７０を通じてつながっている。
【０００７】
図１に示す無線通信システムにおいて、ＭＮ１００が、サブネット１０２内でＡＰ１０４との無線通信を開始したとする。このとき、ＭＮ１００に割り当てられているＩＰアドレスが、サブネット１０２のＩＰアドレス体系に適さない場合、サブネット１０２内に存在するＭＮ１００は、ＡＰ１０４との間における無線通信を介して、サブネット１０２に適合したＩＰアドレス、すなわち気付アドレス（ＣｏＡ：Care of Address）を取得する。
【０００８】
モバイルＩＰでは、ＭＮの位置を管理するノードとしてホームエージェント（ＨＡ： Home Agent）が配置される。ＭＮ１００は、サブネット１０２において取得したＣｏＡを、このＨＡ１１６に登録（ＢＵ： Binding Update）する。この登録の際、ＨＡ１１６では、このＭＮ１００の、移動先サブネットワークに異存しないアドレスであるホームアドレス（ＨｏＡ： Home Address）と、ＣｏＡとの対応情報（Binding Cache）を持つ。これにより、ＭＮ１００はＣＮ１２４との間でデータパケットを送受信する際、ＭＮ１００からＣＮ１２４へは、ＭＮ１００のＨｏＡを送信元、ＣＮ１２４のＩＰアドレスを送信先としたデータパケットが、ＭＮ１００のＣｏＡを送信元、ＨＡ１１６のＩＰアドレスを送信先としたＩＰヘッダでカプセル化されて、まずＨＡ１１６へ送られ、ＨＡ１１６でこのカプセルが外されたデータパケットがＣＮ１２４へと送られる。また、ＣＮ１２４からＭＮ１００への送信に関しては、逆にＣＮ１２４のＩＰアドレスを送信元、ＭＮ１００のＨｏＡを送信先としたデータパケットがＭＮ１００あてに送られ、このデータパケットの通過ポイントであるＨＡ１１６がこれを代理受信し、このデータパケットを、ＨＡ１１６のＩＰアドレスを送信元、ＭＮ１００のＣｏＡを送信先としたＩＰヘッダでカプセル化することにより、移動先サブネットであるサブネット１０２に存在するＭＮ１００に送信する。ＭＮ１００は、ＨＡ１１６からのパケットを受信し、カプセル化されていた中身を取り出して処理する。これにより、ＭＮ１００が移動先サブネットでＣｏＡを用いてＣＮ１２４と通信しているにもかかわらず、ＣＮ１２４はあたかもＭＮ１００がホームネットワーク上でＨｏＡを用いて通信しているように見え、ＭＮ１００の移動を意識しない継続的な通信が双方向で実現する。なお、この場合にＭＮ１００〜ＣＮ１２４間で送受信されるデータパケットがＨＡ１１６を経由する経路（経路１８０）は、三角経路と呼ばれる。
【０００９】
この三角経路は、ＭＮ１００〜ＣＮ１２４間通信において、必ずＨＡ１１６を経由する経路となり、最適な経路（以下、最適化経路と呼ぶこともある）ではない。データパケットを最適な経路で送受信するため、ＭＮ１００は、ＣＮ１２４が経路最適化機能を保有している場合、ＣＮ１２４にＢＵを送り、ＣＮ１２４に対して位置登録処理を行うことにより、経路を最適化することができる。すなわち、ＣＮ１２４は、ＭＮ１００からのＢＵを受け取ることにより、ＭＮ１００のＨｏＡと、ＭＮ１００が現在使用しているＣｏＡの対応情報を知ることができるので、ＣＮ１２４からＭＮ１００あてのデータパケットは、ＣＮ１２４を送信元、ＭＮ１００のＣｏＡを送信先として、ＨＡ１１６を介さずに最適な経路で送ることができ、また逆にＭＮ１００からＣＮ１２４に送られるデータパケットに関しても、ＭＮ１００のＣｏＡを送信元とすることができ、ＨＡ１１６を介さずに最適な経路を使うことができる（経路１８２）。この最適化経路が使用できなくなった場合（例えば、ＭＮ１００がサブネット１２６に移動し、今まで使用していたＣｏＡが使用できなくなった場合）には、ＣＮ１２４からＭＮ１００に送られるデータパケットは再びＨｏＡあて（すなわちＨＡ１１６）に送られる。
【００１０】
また、モバイルＩＰの仕様（非特許文献１、及び非特許文献２）によると、ＭＮ１００が新たなサブネット配下で使用する新しいＣｏＡを取得した場合、まずＨＡ１１６にＢＵを行うことが必須とされる。すなわち、その後ＭＮ１００がＣＮ１２４にＢＵを行って最適化経路が使用できるようになるまでの間、ＭＮ１００〜ＣＮ１２４間で送受信されるデータパケットは、三角経路を通る。
【００１１】
一方、ネットワークを利用した通信においては、ＱｏＳ保証を始めとしたサービス（本明細書では、こうしたサービスを付加的サービスと呼ぶことにする）が存在しており、こうした付加的サービスを実現するための様々な通信プロトコルが存在している。このような様々な通信プロトコルのうち、ＱｏＳ保証をするためのプロトコルとして、例えば、ＲＳＶＰ（Resource Reservation Protocol）が挙げられる（例えば、下記の非特許文献３参照）。ＲＳＶＰは、データの送信を行う送信側通信端末からデータの受信を行う受信側通信端末へのデータパケットの流れ（フロー）が通過する経路上における帯域予約を行うことによって、送信側通信端末から受信側通信端末に、データがスムーズに伝送されるようにするものである。
【００１２】
また、ＲＳＶＰの持つ、端末の移動に非対応などの問題点を解決するプロトコルとして、現在、ＩＥＴＦ（Internet Engineering Task Force）におけるＮＳＩＳワーキンググループにおいて、標準化するための議論が行われている、ＮＳＩＳというプロトコルが挙げられる。このＮＳＩＳは、モバイル環境において、ＱｏＳ保証を始めとする様々な付加的サービスに特に有効であると期待されており、ＮＳＩＳにおいてＱｏＳ保証やモビリティサポートを実現するための要件や実現方法などが記載された文献も存在する（例えば、下記の非特許文献４参照）。以下に、ＮＳＩＳを用いたＱｏＳ経路確立の方法を説明する。
【００１３】
次に、従来のＱｏＳ経路確立方法の一例を、図９を用いて説明する。ＡＲ７０２配下にいるＭＮ７００は、ある目的のために、ＣＮ７１２からデータを受信する予定であるか、あるいは受信している（受信中である）ものとする。この目的に関連して、例えばＣＮ７１２から動画像の配信を受ける場合、このアプリケーションの開始から終わりまでの一連の動作はセッションと呼ばれる。ＭＮ７００は、ＱｏＳ経路の確立を行う場合、セッションを識別するためのセッション識別子（session identifier）、及びフローを識別するためのフロー識別子（flow identifier）を生成する。フロー識別子はデータパケットの送信元及び送信先のアドレス、例えばＭＮ７００のＣｏＡやＣＮ７１２のＩＰアドレスに依存するものである。なお、ＭＮ７００が他のサブネットに移動してＣｏＡが変わる場合には、ＭＮ７００のＣｏＡの変更に伴って、フロー識別子も変わる。一方、セッション識別子は、フロー識別子のように端末の移動に伴い変化するものではない。
【００１４】
次に、ＭＮ７００は、ＮＳＩＳ ＱｏＳのプロトコルスタックを持つルータ（ＱＮＥ）に、所望するＱｏＳリソースを予約するためのメッセージである、ＲＥＳＥＲＶＥメッセージをＣＮ７１２に向けて送信する。ＲＥＳＥＲＶＥメッセージには、ＣＮ７１２からのデータ受信のために所望されるＱｏＳの情報（Qspec）及び、生成されたフロー識別子、セッション識別子が含まれている。送信されたＲＥＳＥＲＶＥメッセージはＡＲ７０２、及びＱＮＥ機能を持たないルータ７０４を経由し、ＱＮＥ７０６に到着する。ＱＮＥ７０６は、ＲＥＳＥＲＶＥメッセージ中に含まれるQspecに記されているＱｏＳリソースを、このセッションのために予約する。この予約を行う際、ＱＮＥ７０６はセッション識別子やフロー識別子、更にこのＲＥＳＥＲＶＥメッセージを受け取った１つ前のＱＮＥの情報（ここではＭＮ７００）をステートとして格納する。ＱＮＥ７０６を通過したＲＥＳＥＲＶＥメッセージは、ＱＮＥ機能を持たないルータ７０８を経由し、ＱＮＥ７１０に到着する。ＱＮＥ７１０においても、ＱＮＥ７０６と同様の処理が行われ、ＱｏＳリソースの予約及びステートの格納が行われる。この操作が繰り返され、最終的にＲＥＳＥＲＶＥメッセージがＣＮ７１２に届けられることによって、ＭＮ７００とＣＮ７１２との間において、ＱｏＳ経路７１４が確立される。
【００１５】
次に、ＮＳＩＳにおけるセッションのアグリゲーション（aggregation）について説明する。下記の非特許文献６に記載されているように，ＮＳＩＳでは、セッションのアグリゲーションがサポートされている。このセッションのアグリゲーションとは、複数の経路を１つにまとめて管理、処理を行うことである。
【００１６】
以下、図１０を参照しながら、ＮＳＩＳでセッションをアグリゲート（aggregate）する場合に送信されるシグナリングメッセージについて説明する。図１０は、従来の技術におけるＮＳＩＳでサポートされているアグリゲーションの一例を模式的に示す図である。
【００１７】
図１０において、ＱＮＥ１００２及びＱＮＥ１００６はアグリゲーションドメインのエッジに位置している、また、アグリゲーションドメイン内に存在するＱＮＥを代表して、ＱＮＥ１００４が図示されている。ＱＮＥ１０００からＱＮＥ１０１０に向けて送られるエンド・ツー・エンド（Ｅ２Ｅ：End to End）シグナリングメッセージＥ２Ｅ＿Ａ（セッション識別子：Ａ）は、ＱＮＥ１００２、１００６、１００８を経由する。一方、ＱＮＥ１０１２からＱＮＥ１０１４に向けて送信されるＥ２ＥシグナリングメッセージＥ２Ｅ＿Ｂ（セッション識別子：Ｂ）は、ＱＮＥ１００２、１００６を経由する。
【００１８】
この２つのＥ２Ｅシグナリングメッセージは、ＱＮＥ１００２とＱＮＥ１００６との間でアグリゲートされる。すなわち、アグリゲーションドメイン内では、アグリゲーションドメイン用のアグリゲーションシグナリングメッセージＡｇｇ＿Ｃ（セッション識別子：Ｃ）がＱＮＥ１００２又はＱＮＥ１００６から送信され、このアグリゲーションシグナリングメッセージＡｇｇ＿ＣはＱＮＥ１００４を経由する。
【００１９】
Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＡとＥ２ＥシグナリングメッセージＥ２Ｅ＿Ｂとが、アグリゲーションシグナリングメッセージＡｇｇ＿Ｃにアグリゲーションされるという情報は、BOUND_SESSION_IDというパラメータを用いることにより、ＱＮＥ１００２及びＱＮＥ１００６に通知される。
【００２０】
例えば、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＡがＱＮＥ１０００より送信され、アグリゲーションドメインの入口であるＱＮＥ１００２に到達した際、このＥ２ＥシグナリングメッセージＥ２Ｅ＿ＡにBOUND_SESSION_IDパラメータが付加され、このBOUND_SESSION_IDパラメータの中に、どのセッション識別子がアグリゲーションドメイン内で使われているかという情報（すなわち、セッション識別子Ｃ）が格納される。このBOUND_SESSION_IDパラメータが付加されたＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａが、アグリゲーションドメインの出口であるＱＮＥ１００６に到達した際、BOUND_SESSION_IDパラメータは、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿Ａから取り外される。
【００２１】
また、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿Ｂの場合も同様であり、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＢがＱＮＥ１０１２より送信され、アグリゲーションドメインの入口であるＱＮＥ１００２に到達した際、このＥ２ＥシグナリングメッセージＥ２Ｅ＿ＢにBOUND_SESSION_IDパラメータが付加され、このBOUND_SESSION_IDパラメータの中に、上述のＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａの場合と同様に、セッション識別子Ｃが格納される。そして、このBOUND_SESSION_IDパラメータが付加されたＥ２ＥシグナリングメッセージＥ２Ｅ＿Ｂが、アグリゲーションドメインの出口であるＱＮＥ１００６に到達した際、BOUND_SESSION_IDパラメータは、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿Ｂから取り外される。なお、このBOUND_SESSION_IDパラメータにより通知される、セッション識別子のアグリゲーションの情報は、アグリゲーションドメインの入口や出口のＱＮＥであるＱＮＥ１００２やＱＮＥ１００６に格納される場合もある。
【００２２】
一方、上述のBOUND_SESSION_IDパラメータは、アグリゲーション以外の用途として、異なるセッションを関連付けるための用途にも用いられる。以下、図１１を参照しながら、ＮＳＩＳにおいて異なるセッションを関連付けるために送信されるシグナリングメッセージについて説明する。
【００２３】
図１１は、従来の技術におけるＮＳＩＳでサポートされている異なるセッションの関連付けの一例を模式的に示す図である。図１１において、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿Ａ（セッション識別子Ａ）とＥ２ＥシグナリングメッセージＥ２Ｅ＿Ｄ（セッション識別子Ｄ）とは、互いに関連のあるメッセージである。例えば、ＱＮＥ１１００とＱＮＥ１１１０とがＶｏＩＰ（Voice over Internet  Protocol）を用いて双方向通信を行っている場合において、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＡはこのＶｏＩＰセッションに対してＱＮＥ１１００からＱＮＥ１１１０に対して、ＱＮＥ１１０２、１１０６、１１０８を経由して送られるＱｏＳ管理用シグナリングメッセージであり、一方、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＤはこのＶｏＩＰセッションに対してＱＮＥ１１１０からＱＮＥ１１００（すなわち、上記のＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａとは逆方向）に対して、ＱＮＥ１１２０、１１０６、１１０２を経由して送られるＱｏＳ管理用シグナリングメッセージである。
【００２４】
この場合、例えば通話セッションが終了し、ＱＮＥ１１００からＱＮＥ１１１０に対するＱｏＳ経路が解放されたとき、セッション識別子Ａとセッション識別子Ｄの関連があらかじめ分かっているのであれば、ＱＮＥ１１１０からＱＮＥ１１００の経路も同時に解放することができる。この目的のために、BOUND_SESSION_IDパラメータが用いられる。
【００２５】
すなわち、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＡにはBOUND_SESSION_IDパラメータが付加され、このBOUND_SESSION_IDパラメータの中に、セッション識別子Ｄが格納される。また、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＡにもBOUND_SESSION_IDパラメータが付加され、このBOUND_SESSION_IDパラメータの中に、セッション識別子Ａが格納される場合もある。これにより、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＡとＥ２ＥシグナリングメッセージＥ２Ｅ＿Ｄとが、セッション識別子Ｄによって関連付けられる。なお、このBOUND_SESSION_IDパラメータより通知されるセッション識別子の関連情報は、各ＱＮＥで格納される場合もある。
【００２６】
なお、ＮＳＩＳは、モバイル環境だけでなく通常の静的なネットワークにおける様々な機能も網羅するものであるが、本明細書では、ＮＳＩＳの機能の１つであるモビリティサポートされた付加的サービスの確立を実現する機能に着目し、ＮＳＩＳの実装によって、モビリティサポートされた付加的サービスの確立が実現されるものとする。
【非特許文献１】C. Perkins, et. al., "IP Mobility Support for IPv4", IETF RFC 3220
【非特許文献２】D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", IETF RFC 3775
【非特許文献３】R. Braden, et. al. "Resource Reservation Protocol", IETF RFC 2205
【非特許文献４】S. Van Den Bosch, et. al., "NSLP for Quality-of-Service signaling", IETF Internet Draft draft-ietf-nsis-qos-nslp-04.txt
【非特許文献５】D. Durham, Ed., "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748
【非特許文献６】Sven Van den Bosch, Georgios Karagiannis and Andrew McDonald “NSLP for Quality-of-Service signaling”, draft-ietf-nsis-qos-nslp-07.txt, July 2005
【発明の開示】
【発明が解決しようとする課題】
【００２７】
モバイルＩＰにおいて、ＭＮ〜ＣＮ間でデータパケットのフローが通過する経路（データ経路）上に、ＮＳＩＳを用いたＱｏＳ経路を確立することを考える。前述の通り、ＭＮがあるサブネット配下に存在している場合において、データ経路には三角経路と最適化経路の２つが存在し、この２つの経路に対しＱｏＳ経路を確立することとなる。この場合、この２つのＱｏＳ経路が三角経路に対し確立されたものであるのか、又は最適化経路に対し確立されたものであるのかを識別する手段が必要となる。なぜならば、従来のＮＳＩＳにおいて、ある２つの端末間にＱｏＳ経路が存在し、この同じ２つの端末間に同一セッション用の別のＱｏＳ経路が更に確立された、又は更に確立されようとした場合には、基本的に以前に確立されていたＱｏＳ経路は解放されることとなる。しかしながら、三角経路は、最適化経路が何かしらの原因で使用不可になった場合に使用される経路であるので、最適化経路用のＱｏＳ経路が確立された際、三角経路用ＱｏＳ経路は解放されないことが望ましい。
【００２８】
従来のＮＳＩＳにおいて、上述のような別のＱｏＳ経路が確立された際にも、それまで確立されていたＱｏＳ経路を解放せずに残すための手段として、別のＱｏＳ経路を確立する際にＲＥＰＬＡＣＥフラグを“Ｎｏ Ｒｅｐｌａｃｅ”にセットするという手段が紹介されている。しかしながら、この手段は同じ２つの端末間に存在する同一セッション用のＱｏＳ経路をすべて残す手段であるため、例えば、ＭＮが移動して、新しいサブネット配下において新しいＱｏＳ経路をＣＮとの間に確立しようとした際、元のサブネット配下で確立した２つのＱｏＳ経路（三角経路用、及び最適化経路用）のうち、三角経路用ＱｏＳ経路のみを残し、最適化経路用ＱｏＳ経路は解放すると言った柔軟な処理には対応しない。さらに、ＱｏＳ経路に関しては、解放するか否かという処理以外にも、特定の経路に対する特定の処理を行えるようにすることが要求される。すなわち、例えば、ＭＮがあるサブネット配下に存在し、三角経路用ＱｏＳ経路を確立した後に、最適化経路用ＱｏＳ経路を確立した際、三角経路用ＱｏＳ経路は解放せずに残すものの、予約されているＱｏＳリソースは減少させるなどの処理が要求される。
【００２９】
従来のＮＳＩＳの手段を用いて、上記問題を解決しようとした場合、ＭＮが特定の処理を行うＱｏＳ経路のフロー識別子とその処理とを、シグナリングメッセージの中に含ませて指示する方法が考えられる。しかしながら、フロー識別子はデータパケットの送信元及び送信先アドレスを含むその他の情報で構成されており、大きな情報量となるため、これをシグナリングメッセージに追加して含ませて送信する方法は、ネットワークに負荷を生じさせることになる。更に別の問題として、同一セッションに対し、同じフロー識別子を持ったＱｏＳ経路が複数存在するような場合には、この方法は適用できない。例えば、ＭＮ〜ＣＮ間で確立される、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路は、同一の端末間に確立されるため、今後のＮＳＩＳワーキンググループにおける議論によって、同一のフロー識別子を持つ可能性が十分に考えられる。
【００３０】
従来のＮＳＩＳの手段を用いて、上記問題を解決しようとした場合の別の方法として、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路に対し、別のセッション識別子を用いるという方法も考えられる。この方法を用いれば、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路は互いに独立したＱｏＳ経路として扱われることが可能となる。しかしながら、例えば、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路とがオーバーラップしている部分において、二重のリソース予約を避けようとした場合などに、この２つのセッション識別子を関連づける情報が必要となり、前述の場合と同様、大きな情報量をシグナリングメッセージに含ませる結果となる。さらに、この方法はセッション識別子が「セッションを識別するもの」であるという定義に反している。
【００３１】
また、上述の図１０及び図１１に図示されている状況が同時に発生した場合においても、経路の種別に係る問題が発生する。図１２は、従来の技術において、セッションのアグリゲーション及び異なるセッションの関連付けが同時に行われた場合の課題を説明するための模式図である。
【００３２】
図１２には、ＱＮＥ１２００とＱＮＥ１２１０との間で互いに関連のあるＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａ及びＥ２ＥシグナリングメッセージＥ２Ｅ＿Ｄが使われており、かつＱＮＥ１２０２とＱＮＥ１２０６との間で、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿ＡがアグリゲーションシグナリングメッセージＡｇｇ＿Ｃにアグリゲートされていたとする。
【００３３】
すなわち、図１２において、ＱＮＥ１２００からＱＮＥ１２１０に対してＱＮＥ１２０２、１２０６、１２０８を経由して送られるＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａと、ＱＮＥ１２１０からＱＮＥ１２００に対してＱＮＥ１２２０、１２０６、１２０２を経由して送られるＥ２ＥシグナリングメッセージＥ２Ｅ＿Ｄとは互いに関連のあるメッセージであるとともに、ＱＮＥ１２０２及びＱＮＥ１２０６は、内部にＱＮＥ１２０４を有するアグリゲーションドメインのエッジに位置している。
【００３４】
この場合、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿Ａの中にはアグリゲーションシグナリングメッセージＡｇｇ＿Ｃとの関連を示すためにセッション識別子Ｃが格納されるBOUND_SESSION_IDパラメータと、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿Ｄとの関連を示すためにセッション識別子Ｄが格納されるBOUND_SESSION_IDパラメータの、２つのBOUND_SESSION_IDパラメータが付加される必要がある。
【００３５】
しかしながら、現在のＮＳＩＳの仕様では、１つのシグナリングメッセージの中に、複数のBOUND_SESSION_IDパラメータを付加することも、１つのBOUND_SESSION_IDパラメータの中に複数のセッション識別子を格納することもできない。
【００３６】
また、仮に、１つのシグナリングメッセージの中に、複数のBOUND_SESSION_IDパラメータを付加することや、１つのBOUND_SESSION_IDパラメータの中に複数のセッション識別子を格納することがＮＳＩＳの仕様でサポートされたとしても、ＱＮＥ１２０２及びＱＮＥ１２０６において、２つのBOUND_SESSION_IDパラメータや、BOUND_SESSION_IDパラメータに含まれる複数のセッション識別子を区別することができない。
【００３７】
例えば、ＱＮＥ１２０２において、Ｅ２ＥシグナリングメッセージＥ２Ｅ＿Ａに２つのBOUND_SESSION_IDパラメータが付加され、一方にはアグリゲーションを示すセッション識別子Ｃが、他方には異なるセッションとの関連付けを示すセッション識別子Ｄがそれぞれ格納される場合、ＱＮＥ１２０６で、２つのBOUND_SESSION_IDパラメータのそれぞれに格納されているセッション識別子を参照して、どちらのBOUND_SESSION_IDパラメータに格納されているセッション識別子がアグリゲーション用のものであり、どちらのBOUND_SESSION_IDパラメータに格納されているセッション識別子が関連のあるセッションを識別するためのものなのかを即座に区別することができない。
【００３８】
また、ＱＮＥ１２０６は、例えば、アグリゲーションドメイン内で使われているセッション識別子（すなわち、セッション識別子Ｃ）を確認し、このセッション識別子と、BOUND_SESSION_IDパラメータ内のセッション識別子との比較を行うことによって、アグリゲーション用のBOUND_SESSION_IDパラメータを区別することは可能であるが、ＱＮＥ１２０６は、シグナリングメッセージの処理の際に、常に上述のようなセッション識別子の確認処理及び比較処理を行う必要があり、ＱＮＥ１２０６の処理負荷が大きくなってしまうという問題がある。
【００３９】
また、BOUND_SESSION_IDパラメータの中に、アグリゲーション用のBOUND_SESSION_IDパラメータと関連のあるセッションの識別用のBOUND_SESSION_IDパラメータとを区別できるような情報を持つフィールドをあらかじめ設けることによって、BOUND_SESSION_IDパラメータに格納されるセッション識別子の区別を行うという解決方法も考えられるが、この場合には、上記フィールド分だけパラメータ長が長くなるうえ、ＱＮＥ１２０６において、このフィールドを確認してからBOUND_SESSION_IDパラメータの処理を行う必要があり、ＱＮＥ１２０６の処理負荷が大きくなってしまうという問題がある。
【課題を解決するための手段】
【００４０】
本発明は、上記の問題点に鑑み、互いにネットワークを介して通信を行う端末の間に、同一セッションに対して、付加的サービスを提供するような経路が複数存在する場合に、それぞれの付加的サービスを提供する経路の種別に応じた処理を柔軟に行うことを可能とする通信方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムを提供することを目的とする。
【００４１】
上記目的を達成するため、本発明の通信方法は、付加的サービス提供に係る機能を有するルータを通じて、１つのセッションに対して、それぞれが経路種別を有する付加的サービス提供用の複数の通信経路を利用して、相手端末との間で通信を行うように構成されている端末における通信方法であって、
前記端末が、前記複数の通信経路のそれぞれに係る経路変化を検出する検出ステップと、
前記検出ステップにおいて検出された経路変化後の通信経路に対して提供される前記付加的サービスを制御するためのシグナリングメッセージであって、前記経路変化後の通信経路に係る前記経路種別を識別する前記経路種別識別子を含む前記シグナリングメッセージを生成するシグナリングメッセージ生成ステップと、
前記経路変化後の通信経路に係る前記経路種別識別子を含む前記シグナリングメッセージを、前記経路変化後の通信経路上に存在する前記ルータに対して送信するシグナリングメッセージ送信ステップとを有している。
上記の構成により、付加的サービス提供に係る機能を有するルータに対して、通信経路の種別を通知することができる。
さらに、本発明の通信方法は、上記の構成に加えて、前記端末が、前記検出ステップにおいて検出された前記経路変化後の通信経路の前記経路種別を識別する識別ステップと、前記識別ステップで識別された前記経路種別の情報に基づいて、前記経路変化後の通信経路に係る前記経路種別を識別する前記経路種別識別子を生成する経路種別識別子生成ステップとを有している。
上記の構成により、経路変化後の通信経路の経路種別を識別することと、経路変化後の通信経路に係る経路種別を識別する経路種別識別子を生成することができる。
【００４２】
さらに、本発明の通信方法は、上記の構成に加えて、複数の付加的サービス提供用の前記通信経路のそれぞれの情報を、前記通信経路のそれぞれの経路種別を識別するための前記経路種別識別子と共に格納する経路種別識別子格納ステップを有している。
上記の構成により、端末は、現在利用している複数の通信経路のそれぞれの経路種別の情報を、経路種別識別子と共に保持することができる。
【００４３】
さらに、本発明の通信方法は、上記の構成に加えて、前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する制御方法保持ステップを有している。
上記の構成により、端末は、通信経路の経路種別ごとや、経路種別の組み合わせごとに対して規定される通信経路の制御方法に係る情報を保持することができる。
【００４４】
さらに、本発明の通信方法は、上記の構成に加えて、前記制御方法保持ステップにおいて保持されている前記制御方法に係る情報を参照して、前記複数の通信経路のそれぞれの前記経路種別に対応した前記制御方法を決定する制御方法決定ステップと、
前記シグナリングメッセージ生成ステップで生成される前記シグナリングメッセージに、前記制御方法決定ステップにより決定された前記制御方法に係る情報を更に含める制御方法付加ステップとを有している。
上記の構成により、端末は、通信経路の経路種別ごとに規定された制御方法を決定し、この制御方法に係る情報を付加的サービス提供に係る機能を有するルータに対して通知することができる。
【００４５】
さらに、本発明の通信方法は、上記の構成に加えて、前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する特定のサーバとの通信を行い、前記制御方法に係る情報を取得するサーバ通信ステップと、
前記サーバ通信ステップにおいて取得された前記制御方法に係る情報を参照して、前記複数の通信経路のそれぞれの前記経路種別に対応した前記制御方法を決定する制御方法決定ステップと、
前記シグナリングメッセージ生成ステップで生成される前記シグナリングメッセージに、前記制御方法決定ステップにより決定された前記制御方法に係る情報を更に含める制御方法付加ステップとを有している。
上記の構成により、端末は、所定のサーバと通信を行うことによって、通信経路の経路種別ごとに規定された制御方法を決定し、この制御方法に係る情報を付加的サービス提供に係る機能を有するルータに対して通知することができる。
【００４６】
また、上記目的を達成するため、本発明の通信方法は、付加的サービス提供に係る機能を有するルータを通じて、１つのセッションに対して、それぞれが経路種別を有する付加的サービス提供用の複数の通信経路を利用して、相手端末との間で通信を行うように構成されている端末における通信方法であって、
前記端末が、前記通信経路に係る経路変化を検出する検出ステップと、
前記端末が、前記検出ステップにおいて検出された経路変化後の通信経路の前記経路種別を識別する識別ステップと、
前記経路変化後の通信経路に関し、前記識別ステップで識別された前記経路種別の情報を含むメッセージを生成するメッセージ生成ステップと、
前記メッセージ内の前記経路種別の情報に基づいて、前記経路変化後の通信経路の前記経路種別を識別するための経路種別識別子を生成し、前記経路変化後の通信経路に対して提供される前記付加的サービスを制御するためのシグナリングメッセージであって、前記経路変化後の通信経路に係る前記経路種別識別子を含む前記シグナリングメッセージを生成し、前記経路変化後の通信経路に係る前記経路種別識別子を含むシグナリングメッセージを、前記経路変化後の通信経路上に存在する前記ルータに対して送信する機能を有する特定のプロキシノードに対して、前記メッセージ生成ステップで生成された前記メッセージを送信するメッセージ送信ステップとを有している。
上記の構成により、端末は、所定のプロキシノードを利用して、付加的サービス提供に係る機能を有するルータに対して、通信経路の種別を通知することができる。
【００４７】
さらに、本発明の通信方法では、上記の構成に加えて、前記端末が、無線移動帯通信機能を有する移動端末であって、前記検出ステップにおいて、前記端末の移動に伴う前記通信経路に係る経路変化が検出される。
上記の構成により、端末の移動に伴った通信経路の変化（接続先のアクセスポイントやアクセスルータの変化）の検出に応じて、付加的サービス提供に係る機能を有するルータに対して、通信経路の種別を通知することができる。
【００４８】
さらに、本発明の通信方法では、上記の構成に加えて、前記端末が、現在通信中、又はハンドオーバ可能な無線アクセスポイントのリンクの状態を監視するリンク状態監視ステップを有し、前記シグナリングメッセージ生成ステップにおいて、前記リンク状態を考慮した前記付加的サービスに対する要求を含む前記シグナリングメッセージを生成する。
上記の構成により、端末は、経路種別や制御方法だけではなく、アクセスポイントのリンクの状態を考慮して、付加的サービスに対する要求に係る情報（すなわち、Qspec）を、付加的サービスが提供される経路上のルータに対して送信することができる。
【００４９】
さらに、本発明の通信方法では、上記の構成に加えて、前記端末がモバイルＩＰの機能を有しており、前記検出ステップにおいて、前記モバイルＩＰに係る位置登録完了メッセージの受信によって、前記通信経路に係る経路変化を検出する。
上記の構成により、端末は、モバイルＩＰにおける位置登録完了後、即座に位置登録により定められた経路上のルータに対して、付加的サービス提供に係るシグナリングメッセージを送信することができる。
【００５０】
さらに、本発明の通信方法では、上記の構成に加えて、前記経路種別識別子が、モバイルＩＰにおける三角経路又は最適化経路を識別するものである。
上記の構成により、端末は、モバイルＩＰにおける三角経路及び最適化経路を識別する情報を含むシグナリングメッセージを送信することができる。
【００５１】
さらに、本発明の通信方法では、上記の構成に加えて、前記端末が、複数のインタフェースを有するとともに、前記複数のインタフェースのそれぞれを利用して前記相手端末との間で通信を行うように構成されており、前記経路種別識別子が、前記複数のインタフェースのそれぞれを識別するものである。
上記の構成により、端末は、複数のインタフェースのそれぞれを用いて相手端末との通信を行っている場合に、どのインタフェースを用いた通信であるかを識別する情報を含むシグナリングメッセージを送信することができる。
【００５２】
さらに、本発明の通信方法では、上記の構成に加えて、前記端末が互いに関連のあるセッションを有する場合、前記互いに関連のあるセッションに対して同一のセッション識別子が付与されるとともに、前記経路種別識別子が、前記互いに関連のあるセッションの方向を示す情報である。
上記の構成により、関連のあるセッション同士を同一のセッション識別子によって表すとともに、経路種別識別子によって関連のあるセッションの方向を現すことが可能となる。これによって、メッセージ長を大幅に削減することが可能となる。また、BOUND_SESSION_IDパラメータによるセッションの関連付けを不要とすることで、BOUND_SESSION_IDパラメータをアグリゲーションの対応付けの用途のみに使用できるようにし、アグリゲーションドメインのエッジに位置する付加的サービス提供に係る機能を有するルータの処理付加を軽減することが可能となる。
【００５３】
さらに、本発明の通信方法では、上記の構成に加えて、前記付加的サービスがＱｏＳ保証である。
上記の構成により、端末は、それぞれが経路種別を有する複数の経路のそれぞれに係るＱｏＳ保証を制御するためのシグナリングメッセージを送信することができる。
【００５４】
また、本発明によれば、上記の通信方法をコンピュータにより実行するための通信方法用プログラムが提供される。
【００５５】
また、上記目的を達成するため、本発明の通信メッセージ処理方法は、付加的サービス提供に係る機能を有しており、端末が、１つのセッションに対して、それぞれが経路種別を有する付加的サービス提供用の複数の通信経路を利用して、相手端末との間で通信を行う際の前記複数の通信経路のうちの少なくとも１つの通信経路上に配置されるルータにおける通信メッセージ処理方法であって、
前記複数の通信経路のそれぞれに対して提供される前記付加的サービスを制御するためのシグナリングメッセージであって、前記ルータが配置されている前記通信経路の前記経路種別を識別するための経路種別識別子を含む前記シグナリングメッセージを受信するシグナリングメッセージ受信ステップと、
前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内の前記経路種別識別子を含む前記付加的サービス提供に係るステートを作成し、格納するステート格納ステップと、
前記経路種別識別子が示す前記経路種別に基づいて、前記付加的サービス提供に係るステート処理方法を決定するステート処理方法決定ステップと、
前記ステート処理決定ステップで決定された前記ステート処理方法に基づいて、前記付加的サービスが提供される前記通信経路に関するステートを処理するステート処理ステップとを有している。
上記の構成により、付加的サービス提供に係る機能を有するルータは、付加的サービスに係るステートを、経路種別を識別する経路種別識別子と関連付けて格納することによって、経路種別に基づくステートの管理を行うことができる。
【００５６】
さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記通信経路に対して提供される前記付加的サービスを制御するための前記シグナリングメッセージが、前記通信経路における制御方法に係る情報を含ませることが可能な領域を有する。
上記の構成により、受信したシグナリングメッセージに含まれる情報によって、付加的サービスが提供される各通信経路に対する制御方法を把握することが可能となる。
【００５７】
さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内に、前記通信経路における制御方法に係る情報が更に含まれていた場合には、前記ステート処理決定方法において、前記制御方法に係る情報に基づいて、前記付加的サービス提供に係るステート処理方法を決定する。
上記の構成により、付加的サービス提供に係る機能を有するルータは、端末からの要求に従ったステート処理を行うことができる。
【００５８】
さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する制御方法保持ステップを有し、前記ステート処理決定方法において、前記制御方法に係る情報に基づいて、前記付加的サービス提供に係るステート処理方法を決定する。
上記の構成により、付加的サービス提供に係る機能を有するルータは、自身が保持している制御方法に係る情報に基づいて、ステート処理を行うことができる。
【００５９】
さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記通信経路の前記経路種別ごと、又は、前記経路種別の組み合わせに対する前記通信経路の制御方法に係る情報を保持する特定のサーバとの通信を行い、前記通信経路の制御方法に係る情報を取得するサーバ通信ステップを有し、前記ステート処理決定方法において、前記制御方法に係る情報に基づいて、前記付加的サービス提供に係るステート処理方法を決定する。
上記の構成により、付加的サービス提供に係る機能を有するルータは、所定のサーバと通信を行うことによって、通信経路の経路種別ごとに規定された制御方法を決定し、この制御方法に係る情報を付加的サービス提供に係る機能を有するルータに対して通知することができる。
【００６０】
さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内の前記経路種別識別子を参照し、前記通信経路の前記経路種別が、モバイルＩＰにおける三角経路及び最適化経路のどちらであるかを判別する経路判別ステップを有する。
上記の構成により、付加的サービス提供に係る機能を有するルータは、モバイルＩＰの三角経路及び最適化経路上にそれぞれ確立されたＱｏＳ経路を識別することができる。
【００６１】
さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージに係るフロー識別子を参照して、前記ステート格納ステップで格納された同一フロー識別子に係るステートが存在するか否かを判断するフロー識別子比較ステップと、
前記フロー識別子比較ステップで前記同一フロー識別子に係るステートが存在する場合、前記シグナリングメッセージを受信した前ホップノード及び前記シグナリングメッセージを送信する次ホップノードと、前記ステート格納ステップで格納された同一フロー識別子に係るステートに係る前ホップノード及び次ホップノードとの比較を行うことにより、前記端末が、同一サブネット配下又はそれぞれ異なるサブネット配下で確立した前記三角経路と前記最適化経路とのクロスオーバノードであるか否かを判断するクロスオーバ判断ステップを有している。
上記の構成により、移動端末が、同一サブネット配下又は異なるサブネット配下において確立した、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路のクロスオーバノードであることを特定し、それぞれのＱｏＳ経路に対して適切な処理を行うことができる。
【００６２】
さらに、本発明の通信メッセージ処理方法は、上記の構成に加えて、前記シグナリングメッセージ受信ステップで受信した前記シグナリングメッセージ内の前記経路種別識別子を参照し、前記通信経路の前記経路種別が、複数のインタフェースを有する前記端末の、どの前記インタフェースを用いた通信を示すものであるかを判別するインタフェース判別ステップを有している。
上記の構成により、付加的サービス提供に係る機能を有するルータは、このシグナリングメッセージに係る通信経路が、複数のインタフェースを用いて相手端末との通信を行っている端末のどのインタフェースを用いて行われている通信経路に関するものであるかを識別することができる。
【００６３】
さらに、本発明の通信メッセージ処理方法では、上記の構成に加えて、前記端末が互いに関連のあるセッションを有する場合、前記互いに関連のあるセッションに対して同一のセッション識別子が付与されるとともに、前記経路種別識別子が、前記互いに関連のあるセッションの方向を示す情報である。
上記の構成により、関連のあるセッション同士を同一のセッション識別子によって表すとともに、経路種別識別子によって関連のあるセッションの方向を現すことが可能となる。これによって、メッセージ長を大幅に削減することが可能となる。また、BOUND_SESSION_IDパラメータによるセッションの関連付けを不要とすることで、BOUND_SESSION_IDパラメータをアグリゲーションの対応付けの用途のみに使用できるようにし、アグリゲーションドメインのエッジに位置する付加的サービス提供に係る機能を有するルータの処理負荷を軽減することが可能となる。
【００６４】
さらに、本発明の通信メッセージ処理方法では、上記の構成に加えて、前記シグナリングメッセージが、ＮＳＩＳ ＱｏＳメッセージにおけるＲＥＳＥＲＶＥメッセージに含まれる内容を有している。
上記の構成により、従来存在するＲＥＳＥＲＶＥメッセージを利用して、付加的サービス提供用の複数の通信経路のそれぞれに対して、適切な処理を行うことができる。
【００６５】
また、本発明によれば、上記の通信メッセージ処理方法をコンピュータにより実行するための通信メッセージ処理方法用プログラムが提供される。
【発明の効果】
【００６６】
本発明は上記の構成を有しており、互いにネットワークを介して通信を行う端末の間に、同一セッションに対して、付加的サービスを提供するような経路が複数存在する場合に、それぞれの付加的サービスを提供する経路の種別に応じた処理を柔軟に行うことを可能とするという効果を有している。
【発明を実施するための最良の形態】
【００６７】
＜第１の実施の形態＞
以下、図面を参照しながら、本発明の第１の実施の形態について説明する。図１は、本発明の第１の実施の形態における通信システムの構成を示す模式図である。なお、従来の技術の説明で用いた図１の通信システムを前提として、本発明の第１の実施の形態について説明する。また、図１に示す通信システムの各構成要素に関しては、従来の技術で説明したものと同様であり、ここでは説明を省略する。
【００６８】
まず、ＭＮ１００の機能について説明する。ＭＮ１００はある１つのセッションに対して設定される付加的サービスを提供するための複数の経路に関し、それぞれ異なった種別を持つ複数の経路のそれぞれの種別について認識する機能を有し、更に各経路を制御する目的で、その経路の種別に基づいた、付加的サービスに係る適切なシグナリングメッセージを決定し、送信する機能を有する。これらの機能について図２を用いて説明する。
【００６９】
図２は、本発明の第１の実施の形態におけるＭＮ１００の構成を示すブロック図である。なお、図２では、ＭＮ１００が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図５及び図６に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。
【００７０】
図２に示すＭＮ１００は、移動検出手段２００、三角経路設定手段２０１ａ、最適化経路設定手段２０１ｂ、シグナリング制御手段２０２、ポリシー決定手段２０４を有している。
【００７１】
移動検出手段２００は、ＭＮ１００の移動を検出する手段である。例えば、このＭＮ１００がモバイルＩＰｖ６（Internet Protocol version 6）を用いた通信をしていた場合、この移動検出手段２００は、モバイルＩＰｖ６レイヤやそれに関連するリンクレイヤにおける処理と連動しており、例えば、ＭＮ１００の接続先ＡＰや接続先ＡＲが変わったことを検出する。
【００７２】
また、三角経路設定手段２０１ａは、ＭＮ１００とＨＡ１１６を経由してＣＮ１２４との間でデータパケットの送受信を行うための経路（例えば、図１に示す経路１８０）を設定する手段である。具体的には、三角経路設定手段２０１ａは、例えば、接続しているサブネットにおいて取得したＣｏＡをＨＡ１１６に登録するためのＢＵメッセージ送信処理などを行う機能を有している。
【００７３】
そして、ＭＮ１００の状態が移動により変化し、例えば、ＭＮ１００が新しいＣｏＡを取得してＨＡ１１６に対する登録処理を完了して、三角経路を用いたデータパケット通信が可能となったときに、三角経路設定手段２０１ａは、後述のシグナリング制御手段２０２に対して、イベントトリガ４００を渡す。
【００７４】
また、最適化経路設定手段２０１ｂは、ＣＮ１２４が経路最適化機能を保有している場合には、三角経路の設定後に、ＨＡ１１６を介さずに直接ＣＮ１２４との間でデータパケットの送受信を行うための最適化経路（例えば、図１に示す経路１８２）を設定する手段である。具体的には、最適化経路設定手段２０１ｂは、例えば、接続しているサブネットにおいて取得したＣｏＡをＣＮ１２４に登録するためのＢＵメッセージ送信処理などを行う機能を有している。
【００７５】
そして、ＣＮ１２４との間で三角経路が設定された後に、例えば、ＭＮ１００がＣＮ１２４に対する登録処理を完了し、最適化経路を用いたデータパケット通信が可能となったとき、最適化経路設定手段２０１ｂは、後述のシグナリング制御手段２０２に対して、イベントトリガ４００を渡す。
【００７６】
ここで、イベントトリガ４００について説明する。図４Ａには、三角経路設定手段２０１ａや最適化経路設定手段２０１ｂからシグナリング制御手段２０２に対して渡される、イベントトリガ４００に含まれる情報の一例が模式的に図示されている。イベントトリガ４００には、例えば、インタフェース・インデックス（Interface Index）４１０、イベントタイプ（Event Type）４１２、経路種別（Path Type）４１４、アドレス情報（Address Information）４１６、イベント属性（Event Attribute）４１８が含まれている。
【００７７】
インタフェース・インデックス４１０は、ＭＮ１００が持つ通信インタフェースのうち、移動が発生したインタフェースに係る情報である。この情報は、例えばＭＮ１００が複数の通信インタフェースを持つ場合に有用である。
【００７８】
また、イベントタイプ４１２は、なぜイベントトリガ４００が発生したかという理由を示す情報である。イベントトリガ４００は、例えば、図４Ａに示すように、アドレス登録処理が完了した場合、特定ノードとの通信が切断された場合、リンクレイヤの状態が変化した場合、接続先ＡＲが変わった場合などに発生し、上記のようなイベントトリガ４００の発生理由が、イベントタイプ４１２によって判別可能となる。なお、図４Ｂでは、イベントタイプ４１２に含まれる値（０ｘ０１〜０ｘ０４の値）によって上記の各発生理由が示されているが、この値は任意に設定可能である。また、イベントトリガ４００の発生理由に関しても、上記の４つの発生理由に限定されるものではなく、その他の任意の発生理由をイベントタイプ４１２によって示すことが可能である。
【００７９】
また、経路種別４１４は、このイベントトリガ４００が発生した通信に係る経路の種別を示す情報である。経路の種別には、例えば、モバイルＩＰにおける三角経路や最適化経路などが存在する。なお、図４Ｃでは、経路種別４１４に含まれる値（０ｘ０１及び０ｘ０２の値）によって、三角経路及び最適化経路が示されているが、この値は任意に設定可能である。また、経路の種別に関しても、上記の三角経路及び最適化経路に限定されるものではなく、その他の任意の経路の種別を経路種別４１４によって示すことが可能である。
【００８０】
なお、本発明の第１の実施の形態では、図２に示すＭＮ１００の三角経路設定手段２０１ａによって三角経路に係る設定が行われ、図２に示すＭＮ１００の最適化経路設定手段２０１ｂによって最適化経路に係る設定が行われる。したがって、図２に示すＭＮ１００の三角経路設定手段２０１ａから出力されるイベントトリガ４００の経路種別４１４には、三角経路を示す値（０ｘ０１）が設定され、図２に示すＭＮ１００の最適化経路設定手段２０１ｂから出力されるイベントトリガ４００の経路種別４１４には、最適化経路を示す値（０ｘ０２）が設定される。
【００８１】
また、アドレス情報４１６は、後述のシグナリング制御手段２０２が処理を行うのに必要な、各ノードのＩＰアドレスを含む情報である。例えば、イベントタイプ４１２の内容が、「アドレス登録処理完了（４２０）」で、経路種別が「最適化経路（４３０）」だった場合、アドレス情報４１６には、このイベントトリガ４００を発生した通信に対して、ＭＮ１００が使用しているＣｏＡと、ＣＮ１２４のＩＰアドレスの情報とが含まれる。また、イベントタイプ４１２が、「アドレス登録処理完了（４２０）」で、経路種別が「三角経路（４２８）」だった場合、ＭＮ１００のＣｏＡとＣＮ１２４のＩＰアドレスとに加え、ＨＡ１１６のＩＰアドレスの情報が含まれる。
【００８２】
また、イベント属性４１８は、付加情報を含む情報である。例えば、イベントタイプ４１２の内容が「リンクレイヤの状態が変化した（４２４）」だった場合、イベント属性４１８には、変化した状態の内容、例えばＱｏＳのサポート状況などが示される。これにより、後述のシグナリング制御手段２０２は、このリンクレイヤの状態変化を考慮して、ＱｏＳ経路を確立するためのシグナリングメッセージを生成することができる。
【００８３】
なお、図４Ａのイベントトリガ４００、図４Ｂのイベントタイプ４１２、図４Ｃの経路種別４１４は、それぞれ一例に過ぎず、イベントトリガ４００が、経路を特定する情報と、その経路の種別を示す情報（すなわち、図４Ｃに示す経路種別４１４と同等の情報）とを含むものであれば、他の形式を取ることも可能であり、また、他の情報を含めることも可能である。
【００８４】
また、シグナリング制御手段２０２は、シグナリングメッセージに係る処理を行う手段である。シグナリング制御手段２０２は、まず、前述の三角経路設定手段２０１ａや最適化経路設定手段２０１ｂからイベントトリガ４００を受け取った後、経路の種別を示す情報（例えば、モバイルＩＰを用いた通信の場合には、三角経路か最適化経路かを示す情報）を含む、付加的サービスを制御するためのシグナリングメッセージ（付加的サービス用シグナリングメッセージ）を生成する。ここでは、このシグナリングメッセージに含まれる経路の種別を示す情報を移動情報要素（ＭＩＥ： Mobility Information Element）と呼ぶことにする。このＭＩＥは、例えば１ビット又は数ビットを使用したフラグであってもよいし、経路の各種別に対応した数値であってもよい。また、ここで生成される付加的サービスを制御するためのシグナリングメッセージは、従来の付加的サービスを制御するためのシグナリングメッセージを拡張したものであってもよい。例えば、付加的サービスがＮＳＩＳを用いたＱｏＳであった場合には、ＮＳＩＳのシグナリングメッセージ（例えば、ＲＥＳＥＲＶＥメッセージ）にＭＩＥを含ませたメッセージが生成される。なお、このＭＩＥによれば、例えば、ＭＮ１００とＣＮ１２４の間に確立される三角経路用のＮＳＩＳ ＱｏＳ経路と、最適化経路用ＮＳＩＳ ＱｏＳ経路用のフロー識別子が同一であった場合でも、この２つを識別することが可能となる。
【００８５】
また、シグナリング制御手段２０２は、作成したシグナリングメッセージを用いてＣＮ１２４との間に確立しようとしている付加的サービス用の経路以外に、それぞれ異なる種別を持つ同一付加的サービス用経路が、同一のＣＮ１２４との間の同一セッションに対して、１つ又は複数存在していた場合に、それらの経路をどのように扱うかという制御情報（ＣＩ： Control Information）を、シグナリングメッセージの中に含めてもよい。例えばモバイルＩＰを用いた通信上で、ＮＳＩＳを用いたＱｏＳ経路を扱う場合において、ＭＮ１００とＣＮ１２４の間に三角経路用ＱｏＳ経路が存在する状態で、ＭＮ１００とＣＮ１２４との間に最適化経路用ＱｏＳ経路を確立する際、あらかじめ確立されていた三角経路用ＱｏＳ経路をどのように扱うかという情報に相当する。この情報（ＣＩ）は、例えば１ビット又は数ビットを使用したフラグであってもよいし、あらかじめ定められた、各処理に対する数値であってもよい。また、シグナリング制御手段２０２は、ＱｏＳ経路の経路種別に応じた制御方法や、あるいは、経路種別の組み合わせに応じた制御方法が記載されたデータベースなどを格納しておき、このデータベースを参照して、経路の扱いを指示するＣＩを決定することも可能である。
【００８６】
なお、それぞれ異なった種別を持つ同一付加的サービス用経路が、同一のＣＮ１２４との間の同一セッションに対して既に２つ以上存在する例として、モバイルＩＰを用いた通信上で、ＮＳＩＳを用いたＱｏＳ経路を扱う場合において、三角経路に対するＱｏＳ経路を、ＭＮ１００〜ＨＡ１１６間と、ＨＡ１１６〜ＣＮ１２４間で分け、この２つを別々の種別を持った経路として扱うような場合が考えられる。この場合、ＭＮ１００〜ＨＡ１１６間でのＱｏＳ経路と、ＨＡ１１６〜ＣＮ１２４間でのＱｏＳ経路には、別々のＭＩＥが割り当てられる。このような場合、ＣＩがどの種別を持った経路に対する処理であるのかを特定するために、ＣＩとこの経路に対するＭＩＥとが一緒に送られてもよい。なお、上述のように三角経路に対するＱｏＳ経路を、ＭＮ１００〜ＨＡ１１６間と、ＨＡ１１６〜ＣＮ１２４間で分け、この２つを別々の種別を持った経路として扱う場合は、ＨＡ１１６〜ＣＮ１２４間にＱｏＳ経路を確立する際、ＨＡ１１６において、ＭＮ１００〜ＨＡ１１６間の経路に係るＭＩＥと、ＨＡ１１６〜ＣＮ１２４間の経路に係るＭＩＥとを付け替える処理が必要であり、ＨＡ１１６はこのＭＩＥ付け替え機能を有してもよい。
【００８７】
また、ＭＮ１００は、図２に示すように、ポリシー決定手段２０４を有してもよい。シグナリング制御手段２０２は、シグナリングメッセージを生成する際に追加情報を得る場合や、また、前述のＣＩを決定する場合に、ポリシー決定手段２０４との間で情報を交換してもよい。
【００８８】
このポリシー決定手段２０４は、付加的サービスに係る情報を提供する手段であり、例えば付加的サービスがＱｏＳだった場合に、このＭＮ１００を使用して通信を利用する利用者が、どの程度のレベルのＱｏＳを所望しているのかという情報（例えば、利用者がコストの安いＱｏＳを所望している情報）などを、ＭＮ１００内のシステムが認識できる形で有している。この情報は、例えば、あらかじめＭＮ１００にインストールされていてもよいし、利用者が通信を開始する際に、ＭＮ１００のディスプレイなどを介したポップアップメニューなどから、利用者により選択されてもよい。
【００８９】
また、この追加情報は、付加的サービス提供者側の要求であってもよい。例えばモバイルＩＰを用いた通信上に、ＮＳＩＳを用いたＱｏＳを提供する場合において、ＭＮ１００とＣＮ１２４との間に三角経路用ＱｏＳ経路が存在する状態で、ＭＮ１００とＣＮ１２４との間に最適化経路用ＱｏＳ経路を確立する際、ポリシー決定手段２０４は、あらかじめ確立されていた三角経路用ＱｏＳ経路をどのように扱うかを示す情報（例えば、三角経路側には要求されているＱｏＳリソースの３０％、最適化経路側には要求されているＱｏＳリソースの７０％を割り当ててリソース予約を行うなどの情報）を、ＭＮ１００内のシステムが認識できる形で有している。この情報は、例えばあらかじめＭＮ１００にインストールされていてもよいし、利用者が通信を開始する際に、付加的サービス提供者が保有するサーバよりダウンロードしてもよい。なお、このポリシー決定手段２０４は、図２に示すようにＭＮ１００の中に保有されるのではなく、例えば付加的サービス提供者が保有するポリシーサーバなどに保有され、前述のシグナリング制御手段２０２がシグナリングメッセージを生成する際に、このポリシーサーバとの通信を行うことによって、情報を取得してもよい。
【００９０】
なお、図４Ａ〜４Ｃの例のように、イベントトリガ４００にＭＩＥを決定するのに必要な情報以外の情報が含まれていた場合、この情報を、シグナリングメッセージを生成するために用いてもよい。例えば付加的サービスがＱｏＳであり、図４Ｂに示すイベントタイプ４１２が、「リンクレイヤの状態が変化した（４２４）」であり、イベント属性（４１８）にリンクレイヤのＱｏＳサポート情報が含まれているイベントトリガ４００を受けた場合には、シグナリング制御手段２０２は、前述のように、リンクレイヤの状態、すなわちリソースの入手可能性を考慮したQSpecを持つ、ＲＥＳＥＲＶＥメッセージを生成してもよい。
【００９１】
次に、ＭＮ１００のシグナリング制御手段２０２で生成された付加的サービス用シグナリングメッセージを受け取る、ネットワーク上の、各付加的サービス用シグナリングに対応したノード（以下、シグナリングノードと記す）の機能について、図３を用いて説明する。なお、図３に示すシグナリングノード３００の機能は、図１中のＱＮＥ１０８、１１２、１２０、１２２及び１３２のすべてに設けられている。また、ＭＮ１００、ＨＡ１１６、ＣＮ１２４もＱＮＥ機能を有することが可能であり、ここでは、これらのノードもＱＮＥ機能を持っていると仮定する。
【００９２】
図３は、本発明の第１の実施の形態におけるシグナリングノードの構成を示すブロック図である。なお、図３では、シグナリングノード３００が有する各機能がブロックにより図示されているが、これらの各機能はハードウェア及び／又はソフトウェアによって実現可能である。特に、本発明の主要な処理（後述の図５、図６に示す各ステップの処理）は、コンピュータプログラムによって実行可能である。なお、このシグナリングノード３００は、ＮＳＩＳを用いたＱｏＳを提供する場合における、ＱＮＥに相当する。
【００９３】
図３に示すシグナリングノード３００は、シグナリング管理手段３０２及びポリシー制御手段３０４を有している。
【００９４】
シグナリング管理手段３０２は、前述のＭＮ１００におけるシグナリング制御手段２０２により生成された、付加的サービス用シグナリングメッセージを受け取り、このシグナリングメッセージの処理を行う。この処理では、付加的サービス用シグナリングメッセージを受け取った場合の従来の処理に加え、シグナリングメッセージ内に含まれるＭＩＥを格納するとともに、更に本発明によって付け加えられた別の情報（例えばＣＩ）に従った処理が行われる。例えば、このシグナリングメッセージがＮＳＩＳ ＱｏＳのメッセージにおけるＲＥＳＥＲＶＥメッセージを拡張したものであった場合、従来のようにセッション識別子やフロー識別子をステートとして格納すると同時にＭＩＥを格納し、これに対し要求されたリソース予約を行う。また、もし同一セッション識別子に対してリソース予約が存在した場合には、従来通り、フロー識別子やＳＩＩ（Source Identification Information）を比較するだけでなく、ＭＩＥの比較も行う。ここで例えば、受け取ったシグナリングメッセージが、最適化経路用ＱｏＳ経路を確立するためのＲＥＳＥＲＶＥメッセージであり、このシグナリングノード３００（つまりＱＮＥ）が、例えば、三角経路用ＱｏＳ経路と、新しく確立しようとしている最適化経路用ＱｏＳ経路とのクロスオーバノード（ＣＲＮ： Crossover Node）であった場合、ＣＩに基づいて三角経路の処理を行ってもよい。
【００９５】
また、シグナリングノード３００は、図３に示すように、ポリシー制御手段３０４を有してもよい。シグナリング管理手段３０２は、受け取ったシグナリングメッセージにＣＩが含まれていない場合、又は、ＣＩは含まれているが別の制御情報が必要な場合には、このポリシー制御手段３０４との間で情報を交換してもよい。
【００９６】
ポリシー制御手段３０４は、シグナリング管理手段３０２が、付加的サービス用経路の処理を行う際の処理方法を提供する手段である。このポリシー制御手段３０４は、例えば前述のＭＮ１００のポリシー決定手段２０４と同様の情報を格納してもよい。すなわち、ポリシー制御手段３０４は、例えばモバイルＩＰを用いた通信上に、ＮＳＩＳを用いたＱｏＳを提供する場合において、ＭＮ１００とＣＮ１２４との間に三角経路用ＱｏＳ経路が存在する状態で、ＭＮ１００とＣＮ１２４との間に最適化経路用ＱｏＳ経路を確立する際、あらかじめ確立されていた三角経路用ＱｏＳ経路をどのように扱うかを示す情報（例えば、三角経路側には要求されているＱｏＳリソースの３０％、最適化経路側には要求されているＱｏＳリソースの７０％を割り当ててリソース予約を行うなどの情報）を、シグナリングノード３００内のシステムが認識できる形で有している。この情報は、例えばあらかじめシグナリングノードにインストールされていてもよい。また、このポリシー制御手段３０４は、図３に示すようにシグナリングノード３００の中に保有されるのではなく、例えば付加的サービス提供者が保有するポリシーサーバなどに保有され、前述のシグナリング管理手段３０２がシグナリングメッセージを受け取った際に、このポリシーサーバとの通信を行ってもよい。このポリシーサーバとして、例えば、上記の非特許文献５に示されるＣＯＰＳ（Common Open Policy Server）などが考えられる。
【００９７】
以上のように、図１中のＭＮ１００を図２に示す構成とするとともに、図１中のＱＮＥ１０８、１１２、１２０、１２２及び１３２に図３に示すシグナリングノード３００の機能を設けることによって、従来のシグナリングメッセージの内容（バイト数）を大きくすることなく、それぞれの付加的サービスを提供する経路の種別に応じた処理をネットワーク上のノードが柔軟に行うことができる。
【００９８】
次に、モバイルＩＰｖ６を用いた通信に対して、ＮＳＩＳを用いたＱｏＳを与える場合において、特に三角経路用ＱｏＳ経路及び最適化経路用ＱｏＳ経路に対し、同一のフロー識別子が使用されていた場合の処理の一例について、図５及び図６を参照しながら説明する。なお、図５及び図６には、シグナリングノード３００のシグナリング管理手段３０２で実行される処理の一例が図示されており、図５は、シグナリングメッセージを受け取った際の処理の一例、図６にはシグナリングメッセージを送信する際の処理の一例が図示されている。
【００９９】
なお、以下に示す例では、各ＱＮＥがどのデータパケットに対してＱｏＳを与えるかを識別する、データパケット識別情報（フィルタ）が、一部のＮＳＩＳシグナリングメッセージ、例えばＲＥＳＥＲＶＥメッセージに含まれていることを仮定して、説明を行う。
【０１００】
図１に示すように、ＭＮ１００が新しいサブネット（ここではサブネット１０２）の配下に移動して新しいＣｏＡを取得した際、ＭＮ１００は、ＨＡ１１６にＢＵを行うことによって、ＣＮ１２４との間で三角経路（経路１８０）を用いた通信が可能となる。このとき、ＭＮ１００の三角経路設定手段２０１ａからシグナリング制御手段２０２に送られるイベントトリガ４００には、イベントタイプ４１２として「アドレス登録処理完了（４２０）」、経路種別４１４として「三角経路（４２８）」が含まれる。シグナリング制御手段２０２は、上記のイベントトリガ４００に含まれる情報よりＭＩＥを作成し、このＭＩＥを含むＲＥＳＥＲＶＥメッセージを生成する。なお、ここで、ＭＩＥとして三角経路を表す数値としては、例えば“００”が使われるものとする。また、このときのフロー識別子には、送信元アドレスをＭＮ１００のＣｏＡ、送信先アドレスをＣＮ１２４のＩＰアドレスとする情報が含まれる。なお、ＭＩＥはフロー識別子の中に含まれてもよい。
【０１０１】
また、モバイルＩＰｖ６の仕様（非特許文献２）によると、三角経路を通るデータパケットのヘッダ情報は、ＭＮ１００からＨＡ１１６の間、及びＨＡ１１６からＣＮ１２４の間でそれぞれ異なる。したがって、ＲＥＳＥＲＶＥメッセージによって送信され、各ＱＮＥに格納されるデータパケット識別情報（フィルタ）は、ＭＮ１００からＨＡ１１６の間、及びＨＡ１１６からＣＮ１２４の間でそれぞれ異なっている必要がある。これを実現するため、ＭＮ１００でＲＥＳＥＲＶＥメッセージを生成する際、ＭＮ１００からＨＡ１１６の間、及びＨＡ１１６からＣＮ１２４の間のそれぞれのフィルタを明示的にＲＥＳＥＲＶＥメッセージに含めてもよい。なお、フィルタの適応範囲を示す方法の一例としては、非特許文献４で提案されているScoping Objectを用いる方法が考えられる。
【０１０２】
ＭＮ１００のシグナリング制御手段２０２によって生成されたＲＥＳＥＲＶＥメッセージは、ＭＮ１００からＣＮ１２４に向けて送信されるが、モバイルＩＰの手段により、ＨＡ１１６を経由するようにカプセル化されて送信される。すなわち、このＲＥＳＥＲＶＥメッセージは三角経路（経路１８０）を経由してＣＮ１２４に向けて送信される。なお、この時点では、この経路１８０上のどのＱＮＥにも、同一セッション識別子に対する別のＮＳＩＳステート、すなわちリソースの予約などは存在していないものとする。
【０１０３】
このシグナリングメッセージ（ＲＥＳＥＲＶＥメッセージ）を受け取ったＱＮＥ１０８は、シグナリング管理手段３０２において、このシグナリングメッセージの処理を行う。以下、同一セッション識別子に対する別のＮＳＩＳステートが存在していない場合において、ＱＮＥ１０８がシグナリングメッセージを受け取った際に行う処理と、シグナリングメッセージを送信する際行う処理について説明する。
【０１０４】
図５に示すように、ＱＮＥ１０８のシグナリング管理手段３０２は、ＲＥＳＥＲＶＥメッセージを受け取ると（ステップ５００）、まず、同一セッション識別子に対するステート（リソース予約）が既に存在するかどうかを調べる（ステップ５０２）。そして、現時点では同一セッション識別子に対するステートは存在しないので、受け取ったＲＥＳＥＲＶＥメッセージに示されているステートを格納する（ステップ５３４）。なお、ここでは、従来のＮＳＩＳ ＱｏＳで格納されるステートと共に、ＲＥＳＥＲＶＥメッセージに含まれるＭＩＥも格納される。次に、このＱＮＥ１０８は、ＲＥＳＥＲＶＥメッセージを処理する最後のＱＮＥか否かを判断する（ステップ５３６）。最後のＱＮＥ（つまり、ここではＣＮ１２４）であれば、このＲＥＳＥＲＶＥメッセージに対するＲＥＳＰＯＮＳＥメッセージを生成し、ＲＥＳＥＲＶＥメッセージの送信元（つまりＭＮ１００）に、このＲＥＳＰＯＮＳＥメッセージを送信する（ステップ５３８）。なお、ここで説明しているＱＮＥ１０８は最後のＱＮＥではないので、ＲＥＳＥＲＶＥメッセージを送信する送信手続きに移る（ステップ５４０）。
【０１０５】
図６に示すように、送信手続きでは、まず、ＲＥＳＥＲＶＥメッセージを受け取る次ホップのＱＮＥ（ここではＱＮＥ１１２）を決定する（ステップ６００）。次に、同一セッション識別子に対するステートが存在しないことを確認し（ステップ６０２）、ＲＥＳＥＲＶＥメッセージを処理する次のＱＮＥの情報（すなわち、ＱＮＥ１１２の情報）を格納する（ステップ６３０）。そして、ＱＮＥ１１２に対してＲＥＳＥＲＶＥメッセージを送信する（ステップ６３２）。なお、ステップ６００における次ホップのＱＮＥを特定する処理は、非特許文献４に示されるように、ＲＥＳＥＲＶＥメッセージを受け取った次のＮＳＩＳノードからの返信によって行われてもよい。
【０１０６】
以上の処理によって、ＱＮＥ１０８は、ＲＥＳＥＲＶＥメッセージに係るステートと共にＭＩＥを格納し、次ホップのＱＮＥ１１２に対して、ＲＥＳＥＲＶＥメッセージを転送することが可能となる。また、次ホップのＱＮＥ１１２を始め、ＣＮ１２４に到達するまでのＨＡ１１６、ＱＮＥ１２０、ＱＮＥ１２２で同様の処理が繰り返し行われ、その結果、三角経路（経路１８０）上にＱｏＳ経路が確立される。また、このＲＥＳＥＲＶＥメッセージを受信したＣＮ１２４では、上述のように、ステップ５３８において、このＲＥＳＥＲＶＥメッセージに対するＲＥＳＰＯＮＳＥメッセージの送信処理が行われる。
【０１０７】
次に、ＭＮ１００は、ＣＮ１２４に対してＢＵ処理を行い、ＣＮ１２４との最適化経路を用いた通信を可能とする場合について説明する。このとき、ＭＮ１００の最適化経路設定手段２０１ｂからシグナリング制御手段２０２に送られるイベントトリガ４００には、イベントタイプ４１２として「アドレス登録処理完了（４２０）」、経路種別４１４として「最適化経路（４３０）」が含まれる。シグナリング制御手段２０２は、上記のイベントトリガ４００に含まれる情報よりＭＩＥを作成し、このＭＩＥを含むＲＥＳＥＲＶＥメッセージを作成する。ここでＭＩＥとして最適化経路を表す数値としては、例えば“０１”が使われるものとする。また、このときのフロー識別子は、送信元アドレスをＭＮ１００のＣｏＡ、送信先アドレスをＣＮ１２４のＩＰアドレスとする情報が含まれる。すなわち、このフロー識別子は、上記の三角経路（経路１８０）用ＱｏＳ経路を確立した際のフロー識別子と同一のものが使われる。シグナリング制御手段２０２で生成された、この最適化経路用のＲＥＳＥＲＶＥメッセージは、ＭＮ１００からＣＮ１２４に向けて最適化経路（ここでは経路１８２）を通って送信される。
【０１０８】
この最適化経路用のＲＥＳＥＲＶＥメッセージを受け取った経路１８２上のＱＮＥ（ＱＮＥ１０８、ＱＮＥ１２０、ＱＮＥ１２２）の各シグナリング管理手段３０２も、図５及び図６に示すフローチャートに基づいて、このＲＥＳＥＲＶＥメッセージの処理を行う。
【０１０９】
まず、経路１８２上のＱＮＥの１つであるＱＮＥ１０８における処理について説明する。このＱＮＥ１０８は、上述の動作によって三角経路用ＱｏＳ経路が確立されている経路１８０と、これから新たに最適化経路用ＱｏＳ経路が確立される経路１８２との分岐点となる。この例では、経路１８０のフロー識別子と、経路１８２のフロー識別子とが同一であるため、ネットワーク側の何らかの変化により起こる経路変更（例えば、確立されていたＱｏＳ経路上のあるルータに故障が起こった場合に、迂回経路が使用され、その迂回経路上にＱｏＳ経路が更新された場合）との区別が行われなければならない。すなわち、ここでは、経路１８０上に確立されているＱｏＳ経路と、これから経路１８２上に確立されるＱｏＳ経路とが同一のフロー識別子を有するにもかかわらず、経路１８０上のＱｏＳ経路が三角経路用ＱｏＳ経路として、経路１８２上のＱｏＳ経路が最適化経路用ＱｏＳ経路として共存するように処理が行われる。
【０１１０】
図５に示すように、ＱＮＥ１０８のシグナリング管理手段３０２は、このＲＥＳＥＲＶＥメッセージを受け取ると（ステップ５００）、まず、同一セッションに対するステート（リソース予約）が既に存在するかどうかを調べる（ステップ５０２）。ここでは、上述の三角経路用ＱｏＳ経路のステートが存在するので、次に、そのステートに対し、フロー識別子が同じか否かを調べる（ステップ５０４）。ここでは、フロー識別子は同じものが使われているので、次に、三角経路用ＱｏＳ経路のステートを参照して、ＲＥＳＥＲＶＥメッセージを受け取った元のノード（前ホップのノード）が、格納されているものと等しいか否か、また、ＲＥＳＥＲＶＥメッセージを受け取ったインタフェースが、格納されているものと等しいか否かを調べる（ステップ５０６）。ここでは、格納されている前ホップのノードのステートが経路１８２と同一（すなわち、前ホップのノードがＭＮ１００で同一）であるので、次に、ＭＩＥの内容やＣＩの内容に基づいて、元の経路のステート（経路１８０に係るステート）をどのように処理するかを判断して、適切な処理を行う（ステップ５１８）。ＱＮＥ１０８は、例えば、２つの経路１８０、１８２を独立した経路としてステート管理し、例えば、三角経路用ＱｏＳ経路には要求リソースの３０％、最適化経路には要求リソースの７０％を割り当てるなどの処理を行ってもよい。また、この２つの経路１８０、１８２を合併させて、どちらの経路１８０、１８２を通るデータパケットが送られてきた場合でも、同じリソースを使用できるようにしてもよい。また、このステップ５１８の処理判断を行う場合、ポリシー制御手段３０４から提供される情報に基づいて、処理方法を決定してもよい。
【０１１１】
次に、このセッション識別子に対し、他のフローに対するステートが存在するか否かを調べる（ステップ５３２）。ここで、もし存在する場合にはステップ５０４に戻り、他のフローのステート（フローステート）に対して同様の処理を行うが、ここでは、これ以上存在しないので、次に、このＱＮＥ１０８がＲＥＳＥＲＶＥメッセージを処理する最後のＱＮＥか否かを判断する（ステップ５３６）。ＲＥＳＥＲＶＥメッセージの最終的な送信先はＣＮ１２４であり、すなわちＱＮＥ１０８は最後のＱＮＥでないので、ＱＮＥ１０８は、続いて、ＲＥＳＥＲＶＥメッセージを送信する手続きに移る（ステップ５４０）。
【０１１２】
図６に示すように、送信手続きでは、まず、ＲＥＳＥＲＶＥメッセージを受け取る次ホップのＱＮＥ（ここではＱＮＥ１２０）を決定する（ステップ６００）。次に、同一セッション識別子に対するステートが存在することを確認し（ステップ６０２）、また、フロー識別子も同じであるということを確認する（ステップ６０４）。次に、このＲＥＳＥＲＶＥメッセージの送信先の次のＱＮＥやインタフェースが、既に存在している同一フロー識別子に係るステートにおいて格納されているものと同じであるか否かを確認する（ステップ６０６）。ここで、先に確立されている三角経路用ＱｏＳ経路の次ホップがＱＮＥ１１２である一方、今回のＲＥＳＥＲＶＥメッセージの次ホップはＱＮＥ１２０であり、メッセージ送信先が格納されているものと違うので、次に、ＭＩＥの内容が格納されているものと同じかどうかを調べる（ステップ６０８）。ここではＭＩＥの内容がそれぞれ三角経路及び最適化経路を示しており、ＭＩＥの内容が違っているので、このＱＮＥ１０８は最適化経路と三角経路との分岐点だと判断され、次ホップのＱＮＥの情報（すなわち、ＱＮＥ１２０の情報）が格納される（ステップ６１４）。
【０１１３】
また、必要であれば、経路１８０の特定区間（例えば、ＱＮＥ１０８からＨＡ１１６までの経路）に対する処理を行ってもよい（ステップ６１６）。この処理は、例えば、この経路１８０の特定区間に対し、予約されているリソースを３０％に減少させる内容のメッセージを送信するなどの処理を指す。なお、この処理に関して、ポリシー制御手段３０４から提供される情報を参照してもよい。次に、セッション識別子に対し、他のフローに対するステートが存在するか否かを調べる（ステップ６１８）。ここで、もし存在した場合はステップ６０４に戻り、他のフローステートに対して同様の処理を行うが、ここでは、これ以上存在しないので、次ホップのノード（ＱＮＥ１２０）にＲＥＳＥＲＶＥメッセージが送信される（ステップ６３２）。
【０１１４】
なお、ここでは、ステップ６０８において、２つのＭＩＥの内容が異なる場合について説明しているが、ＭＩＥの内容が同一の場合には、ＱＮＥ１０８は、ネットワーク側の変化による経路変更と判断して、従来のＮＳＩＳで規定されている処理を行う（ステップ６１０）。
【０１１５】
次に、上述の処理によってＱＮＥ１０８から送信されたＲＥＳＥＲＶＥメッセージを受信した場合のＱＮＥ１２０における処理について説明する。このＱＮＥ１２０は、上述の動作によって三角経路用ＱｏＳ経路が確立されている経路１８０と、これから新たに確立される経路１８２が交わり始めるポイントとなる。この例では、経路１８０のフロー識別子と、経路１８２のフロー識別子とが同一であるため、上述したＱＮＥ１０８の場合と同様、ネットワーク側の何らかの変化により起こる経路変更（例えば、確立されていたＱｏＳ経路上のあるルータに故障が起こった場合に、迂回経路が使用され、その迂回経路上にＱｏＳ経路が更新された場合）との区別が行われなければならない。
【０１１６】
図５に示すように、ＱＮＥ１２０のシグナリング管理手段３０２は、このＲＥＳＥＲＶＥメッセージを受け取ると（ステップ５００）、まず、同一セッションに対するステート（リソース予約）が既に存在するかどうかを調べる（ステップ５０２）。ここでは上述の三角経路（経路１８０）用ＱｏＳ経路のステートが存在するので、次に、そのステートに対し、フロー識別子が同じか否かを調べる（ステップ５０４）。ここでは、フロー識別子は同じものが使われているので、次に、三角経路用ＱｏＳ経路のステートを参照して、ＲＥＳＥＲＶＥメッセージを受け取った元のノード（前ホップのノード）が、格納されているものと等しいか否か、また、ＲＥＳＥＲＶＥメッセージを受け取ったインタフェースが、格納されているものと等しいか否かを調べる（ステップ５０６）。ここでは、格納されている前ホップのノードのステートが経路１８２と異なるので（すなわち、経路１８０の前ホップのノードがＨＡ１１６であり、経路１８２の前ホップのノードがＱＮＥ１０８）、次に、ＲＥＳＥＲＶＥメッセージ中のＭＩＥが、格納されているものと同一か否かを調べる（ステップ５０８）。ここで、ＭＩＥは同一のものではないので、ＱＮＥ１２０は、自身を三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路のＣＲＮと判断し、ＭＩＥの内容から、まず元の経路のステート（経路１８０に係るステート）をどのように処理するかを判断して、適切な処理を行う（ステップ５１４）。この処理は、ステップ５１８と同様な処理である。
【０１１７】
また、必要であれば、元の経路（経路１８０）の特定区間（例えば、ＨＡ１１６からこのＱＮＥ１２０までの経路）に対する処理を行ってもよい（ステップ５１６）。この処理は、例えば、この経路１８０の特定区間に対し、予約されているリソースを３０％に減少させる内容のメッセージを送信するなどの処理を指す。また、これらの処理（ステップ５１４及びステップ５１６）を行う場合、ポリシー制御手段３０４から提供される情報を参照してもよい。なお、ここでは、ステップ５０８において、２つのＭＩＥの内容が異なる場合について説明しているが、ＭＩＥの内容が同一の場合には、ＱＮＥ１０８は、ネットワーク側の変化による経路変更と判断して、従来のＮＳＩＳで規定されている処理を行う（ステップ５１０）。
【０１１８】
次に、このセッション識別子に対し、他のフローに対するステートが存在するかどうかを調べる（ステップ５３２）。ここで、もし存在した場合はステップ５０４に戻り、他のフローステートに対して同様の処理を行うが、ここでは、これ以上存在しないので、次に、このＱＮＥ１２０がＲＥＳＥＲＶＥメッセージを処理する最後のＱＮＥか否かを判断する（ステップ５３６）。ＲＥＳＥＲＶＥメッセージの最終的な送信先はＣＮ１２４であり、すなわちＱＮＥ１２０は最後のＱＮＥでないので、ＱＮＥ１２０は、メッセージを送信する手続きに移る（ステップ５４０）。
【０１１９】
図６に示すように、送信手続きでは、まず、ＲＥＳＥＲＶＥメッセージを受け取る次ホップのＱＮＥ（ここではＱＮＥ１２２）を決定する（ステップ６００）。次に、同一セッション識別子に対するステートが存在することを確認し（ステップ６０２）、また、フロー識別子も同じであるということを確認する（ステップ６０４）。次に、このＲＥＳＥＲＶＥメッセージの送信先の次のＱＮＥやインタフェースが既に存在している同一フロー識別子に係るステートにおいて格納されているものと同じであるか否かを確認する（ステップ６０６）。ここでは、２つの経路１８０、１８２の次ホップのＱＮＥが同一（ＱＮＥ１２２）なので、次に、セッション識別子に対し、他のフローに対するステートが存在するか否かを調べる（ステップ６１８）。ここで、もし存在した場合はステップ６０４に戻り、他のフローステートに対して同様の処理を行うが、ここでは、これ以上存在しないので、次ホップのノード（ＱＮＥ１２２）にＲＥＳＥＲＶＥメッセージが送信される（ステップ６３２）。
【０１２０】
ＱＮＥ１２０からＲＥＳＥＲＶＥメッセージを受信したＱＮＥ１２２は、上述の最適化経路用のＲＥＳＥＲＶＥメッセージを受信したＱＮＥ１０８と同一の受信手続きを行う。すなわち、ＱＮＥ１２２は、図５におけるステップ５０２、ステップ５０４、ステップ５０６、ステップ５１８、ステップ５３２、ステップ５３６、ステップ５４０の処理を行う。また、ＱＮＥ１２２の送信手続きは、上述のＱＮＥ１２０と同一となる。すなわち、ＱＮＥ１２２は、図６におけるステップ６００、ステップ６０２、ステップ６０４、ステップ６０６、ステップ６１８、ステップ６３２の処理を行う。
【０１２１】
また、図１に示すシステム構成においては不図示であるが、三角経路用ＱｏＳ経路及び最適化経路用ＱｏＳ経路の両方の経路上に存在し、さらに、三角経路用ＱｏＳ経路及び最適化経路用ＱｏＳ経路の前ホップのノードが異なるとともに、三角経路用ＱｏＳ経路及び最適化経路用ＱｏＳ経路の次ホップのノードも異なるＱＮＥが存在する可能性もある。このようなＱＮＥは、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路との交差ポイントに存在し、ＲＥＳＥＲＶＥメッセージの受け取り元のＱＮＥ、及び、送信先のＱＮＥの両方のステートが、格納されているステートと異なるものとなるこの交差ポイントに存在するＱＮＥは、図５に示す受信手続きにおいては、ステップ５０６及びステップ５０８を経てステップ５１４の処理に進むことになり、図６に示す送信手続きにおいては、ステップ６０６及びステップ６０８を経てステップ６１４の処理に進むことになる。したがって、図５に示すステップ５１６や図６に示すステップ６１６の処理において、さらに、このＱＮＥが交差ポイントか否かを判断して、その判断結果に応じた適切な処理を行うようにしてもよい。
【０１２２】
また、ＣＮ１２４は、このＲＥＳＥＲＶＥメッセージを処理する最後のノードであるので、このＲＥＳＥＲＶＥメッセージに対し、必要であればシグナリング管理手段３０２にてＲＥＳＰＯＮＳＥメッセージを作成して、ＲＥＳＥＲＶＥメッセージの送信元であるＭＮ１００に対して送信する。
【０１２３】
次に、ＭＮ１００が、別のサブネット配下（例えば、サブネット１２６）に移動して新しいＣｏＡを取得した際に、ＭＮ１００が、ＨＡ１１６に再びＢＵを行うことにより、ＣＮ１２４との間で三角経路（経路１８４）を用いた通信を可能とする場合について説明する。ここで、再び、ＭＮ１００の三角経路設定手段２０１ａがイベントトリガ４００をシグナリング制御手段２０２に送る。このイベントトリガ４００には、イベントタイプ４１２として「アドレス登録処理完了（４２０）」、経路種別４１４として「三角経路（４２８）」が含まれる。シグナリング制御手段２０２は、上記のイベントトリガ４００に含まれる情報よりＭＩＥを作成し、このＭＩＥを含むＲＥＳＥＲＶＥメッセージを生成する。ここでＭＩＥとして三角経路を表す数値としては、例えば“００”が再び使われるものとする。また、このときのフロー識別子は、ＭＮ１００の新しいＣｏＡが送信元となるので、前述の、移動前のサブネット（サブネット１０２）から確立した三角経路（経路１８０）用ＱｏＳ経路や最適化経路（経路１８２）用ＱｏＳ経路とは、異なるフロー識別子となる。シグナリング制御手段２０２で生成された、この三角経路（経路１８４）用のＲＥＳＥＲＶＥメッセージは、ＭＮ１００からＣＮ１２４に向けて送信されるが、モバイルＩＰの手段により、ＨＡ１１６を経由するようにカプセル化されて送信される。すなわち、このＲＥＳＥＲＶＥメッセージは三角経路（経路１８４）を経由して、ＭＮ１００からＣＮ１２４に向けて送信される。
【０１２４】
このＲＥＳＥＲＶＥメッセージを受け取ったＱＮＥ１３２では、シグナリング管理手段３０２において、このＲＥＳＥＲＶＥメッセージの処理が行われる。ここで、ＱＮＥ１３２には同一セッション識別子に対するステートが存在しないので、前述の、ＭＮ１００がサブネット１０２から三角経路（経路１８０）用ＱｏＳ経路を確立した際の、ＱＮＥ１０８と同一の処理が行われる。
【０１２５】
次に、このＲＥＳＥＲＶＥメッセージをＱＮＥ１３２から受け取ったＱＮＥ１１２は、旧三角経路（経路１８０）用ＱｏＳ経路に、この新しい三角経路（経路１８４）用ＱｏＳ経路が交わり始めるノードである。以下、ここでのＱＮＥ１１２における処理について、再び図５、図６を用いて説明する。
【０１２６】
図５に示すように、ＱＮＥ１１２のシグナリング管理手段３０２は、ＱＮＥ１３２からのＲＥＳＥＲＶＥメッセージを受け取ると（ステップ５００）、まず、同一セッションに対するステート（リソース予約）が既に存在するかどうかを調べる（ステップ５０２）。ここでは上述の旧三角経路（経路１８０）用ＱｏＳステートが存在するので、次に、そのステートに対し、フロー識別子が同じか否かを調べる（ステップ５０４）。ここでは、ＭＮ１００の移動に伴って、フロー識別子は違うものが使われている。そして、次に、旧三角経路（経路１８０）用ＱｏＳ経路のステートを参照して、ＲＥＳＥＲＶＥメッセージを受け取った元のノード（前ホップのノード）が、格納されているものと等しいか否か、また、ＲＥＳＥＲＶＥメッセージを受け取ったインタフェースが、格納されているものと等しいか否かを調べる（ステップ５２０）。ここでは、格納されている前ホップのノードのステートが経路１８４と異なるので（すなわち、経路１８０の前ホップのノードがＱＮＥ１０８であり、経路１８４の前ホップのノードがＱＮＥ１３２）、次に、ＲＥＳＥＲＶＥメッセージ中のＭＩＥが格納されているものと同一か否かを調べる（ステップ５２２）。ここで、格納されているステートは旧三角経路（経路１８０）用ＱｏＳのステートなので、ＭＩＥは等しいことが分かる。よって、このＱＮＥ１１２はハンドオーバによるＣＲＮであると判断され、従来の方法（例えば非特許文献４に示される方法）によりステートが更新され、必要に応じて元の経路（経路１８０）の特定区間（例えば、ＱＮＥ１１２からＡＰ１０４までの経路）に対する処理が行われてもよい（ステップ５３０）。また、ここで、従来のＮＳＩＳで規定されている、ハンドオーバによるＣＲＮでの処理方法に従う以外にも、三角経路であることを考慮した処理が行われてもよい。例えば、前述の最適化経路（経路１８２）用ＱｏＳ経路が確立された際のＱＮＥ１２０のステップ５１６における処理で、予約リソースが３０％に減少させられていた場合には、これを元の１００％に戻すなど処理を行うことが可能である。なお、こうした処理には、ポリシー制御手段３０４から提供される情報が参照されてもよい。次に、ＱＮＥ１１２のシグナリング管理手段３０２は、他のフローステートが存在するかどうかを確認する（ステップ５３２）。ここで、もし存在した場合はステップ５０４に戻り、他のフローステートに対して同様の処理を行うが、ここではこれ以上存在しないので、次に、このＱＮＥ１１２がＲＥＳＥＲＶＥメッセージを処理する最後のＱＮＥか否かを判断する（ステップ５３６）。ＲＥＳＥＲＶＥメッセージの最終的な送信先はＣＮ１２４であり、すなわちＱＮＥ１１２は最後のＱＮＥでないので、ＱＮＥ１１２は、メッセージを送信する手続きに移る（ステップ５４０）。
【０１２７】
図６に示すように、送信手続きでは、まず、ＲＥＳＲＥＶＥメッセージを受け取る次ホップのＱＮＥ（ここではＨＡ１１６）を決定する（ステップ６００）。次に、同一セッション識別子に対するステートが存在することを確認し（ステップ６０２）、また、フロー識別子が異なっていることを確認する（ステップ６０４）。次に、このＲＥＳＥＲＶＥメッセージの送信先の次のＱＮＥやインタフェースが格納されているものと同じであるか否かを確認する（ステップ６２０）。ここでは、２つの経路１８０、１８４の次ホップのＱＮＥが同一（ＨＡ１１６）なので、次に、セッション識別子に対し、他のフローに対するステートが存在するか否かを調べる（ステップ６１８）。ここで、もし存在した場合はステップ６０４に戻り、他のフローステートに対して同様の処理を行うが、ここでは、これ以上存在しないので、次ホップのノード（ＨＡ１１６）にＲＥＳＥＲＶＥメッセージが送信される（ステップ６３２）。
【０１２８】
なお、ここで、経路１８０と経路１８４のＣＲＮがＱＮＥ１１２ではなく、例えばＱＮＥ１０８であった場合、ＱＮＥ１０８には旧最適化経路（経路１８２）用ＱｏＳ経路のステートも存在する。この場合は、ステップ５２２でＭＩＥが違うことが確認された後、ステップ５２４やステップ５２６で、ＣＩの内容やポリシー制御手段３０４から提供される情報を用いることにより、旧最適化経路（経路１８２）用ＱｏＳ経路のステートが処理される。このステップ５２４やステップ５２６における処理としては、例えば、旧最適化経路（経路１８２）用ＱｏＳ経路のリソースを３０％に減少させる、あるいは旧最適化経路（経路１８２）用ＱｏＳ経路そのものを解放する処理などが考えられる。また、この旧最適化経路（経路１８２）用ＱｏＳ経路の処理を、例えば末端ノード（つまりＣＮ１２４）で行わせるために、ここでは何も処理を行わないということも考えられる。また、シグナリング管理手段３０２は、ここで各経路用ＱｏＳステートに対して行った処理を他のＱＮＥに通知するための情報を、ＲＥＳＥＲＶＥメッセージに追加してもよい。
【０１２９】
また、この新しい三角経路（経路１８４）用のＲＥＳＥＲＶＥメッセージは、さらに、ＱＮＥ１１２から、ＨＡ１１６、ＱＮＥ１２０、ＱＮＥ１２２及びＣＮ１２４にまで送信される。ＨＡ１１６、ＱＮＥ１２０、ＱＮＥ１２２及びＣＮ１２４では、このＲＥＳＥＲＶＥメッセージを受け取った際、シグナリング管理手段３０２において、旧三角経路（経路１８０）用ＱｏＳ経路のステートに対して、ステップ５２０でメッセージ受信元インタフェースや受信元ノードが同一であると判断され、ステップ５２８でＣＩの内容やポリシー制御手段３０４から提供される情報に従った処理が行われる。このステップ５２８における処理としては、例えば、旧三角経路（経路１８０）用ＱｏＳ経路のステートを新しい三角経路（経路１８４）用ＱｏＳ経路のステートに置き換える処理などが考えられる。
【０１３０】
また、ＱＮＥ１２０、ＱＮＥ１２２、ＣＮ１２４においては旧最適化経路（経路１８２）に対するステートも存在している。ＱＮＥ１２０では、この新しい三角経路（経路１８４）用のＲＥＳＥＲＶＥメッセージを受け取った際、ステップ５２０において、格納されている旧最適化経路（経路１８２）に係る受信元インタフェースや受信元ノードが、今回の経路１８４のものとは異なると判断され、続いて、ステップ５２２でＭＩＥが異なると判断される。そして、ステップ５２４で、ＣＩの内容やポリシー制御手段３０４から提供される情報を用いることにより、旧最適化経路（経路１８２）用ＱｏＳ経路のステートが処理される。この処理としては、例えば、旧最適化経路（経路１８２）用ＱｏＳ経路のリソースを３０％に減少させる、あるいは旧最適化経路（経路１８２）用ＱｏＳ経路そのものを解放する処理などが考えられる。さらに、ステップ５２６で、ＣＩの内容やポリシー制御手段３０４から提供される情報を用いることにより、旧最適化経路（経路１８２）用ＱｏＳ経路の一部の特定区間（例えば、ＱＮＥ１２０からＡＲ１０６までの経路）に対する処理が行われてもよい。この処理としては、例えば、旧最適化経路（経路１８２）用ＱｏＳ経路のリソースを３０％に減少させる、あるいは旧最適化経路（経路１８２）用ＱｏＳ経路そのものを解放するためのメッセージを作成し、送信する処理などが考えられる。また、この旧最適化経路（経路１８２）用ＱｏＳ経路の処理を、例えば末端ノード（つまりＣＮ１２４）で行わせるために、ここでは何も処理を行わないということも考えられる。また、シグナリング管理手段３０２は、ここで各経路用ＱｏＳステートに対して行った処理を他のＱＮＥに通知するための情報を、ＲＥＳＥＲＶＥメッセージに追加してもよい。
【０１３１】
一方、ＱＮＥ１２２やＣＮ１２４では、ステップ５２０において、格納されている旧最適化経路（経路１８２）に係る受信元インタフェースや受信元ノードが同一であると判断された後、ステップ５２８でＣＩの内容やポリシー制御手段３０４から提供される情報を用いることにより、旧最適化経路（経路１８２）用ＱｏＳ経路のステートが、前述のステップ５２４と同様の方法を用いて処理される。また、このＲＥＳＥＲＶＥメッセージを受け取ったＣＮ１２４は、ステップ５２８でＣＩの内容やポリシー制御手段３０４から提供される情報を用いることにより、旧最適化経路（経路１８２）用ＱｏＳ経路を処理するためのメッセージを経路１８２に沿ってサブネットワーク１０２方向に送信してもよい。この処理としては、例えば、旧最適化経路（経路１８２）用ＱｏＳ経路のリソースを３０％に減少させる、あるいは旧最適化経路（経路１８２）用ＱｏＳ経路そのものを解放する処理などが考えられる。以上の処理によって、新しい三角経路（経路１８４）用ＱｏＳ経路が確立される。
【０１３２】
また、ＭＮ１００がサブネット１２６において、ＣＮ１２４にＢＵ処理を行い、新しい最適化経路（経路１８６）用ＱｏＳ経路を確立する場合においても、経路１８６上の各ＱＮＥ（つまりＱＮＥ１３２、ＱＮＥ１２２、ＣＮ１２４）において、前述の処理と同様の処理を行うことにより、ＱｏＳ経路を確立することができる。
【０１３３】
なお、ネットワーク１７０内の任意のノードが付加的サービスを制御するための機能を有し、ＭＮ１００の代理（プロキシ）となってもよい。この場合、ＭＮ１００は、付加的サービスを制御するための機能を持たなくてもよいが、プロキシとなった任意のノードが付加的サービスを制御するために必要な情報を、プロキシとの間で交換する手段を有する。例えば、ＭＮ１００は移動検出手段２００、三角経路設定手段２０１ａ、最適化経路設定手段２０１ｂのみを有し（シグナリング制御手段２０２及びポリシー決定手段２０４は持たない）、プロキシがシグナリング制御手段２０２及びポリシー決定手段２０４を持つという方法が考えられる。この場合には、ＭＮ１００の三角経路設定手段２０１ａや最適化経路設定手段２０１ｂからプロキシに対して、ネットワーク１７０を通して、又はネットワーク１７０を通さずに、直接イベントトリガ４００が送られる。
【０１３４】
また、上述の第１の実施の形態では、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路に同一フロー識別子が使われる例を示したが、三角経路用ＱｏＳ経路と最適化経路用ＱｏＳ経路に異なるフロー識別子が用いられる場合においても適応可能である。実現方法の１つとして、例えば、ＭＮ１００がＭＩＥのほかに、又はＭＩＥの一部として位置順序番号（ＬＳＮ： Location Sequence Number）を持つ方法が考えられる。このＬＳＮは、ＭＮ１００が同一サブネット配下に居る状態では変わらず、ＭＮ１００がサブネットを移動すると変化する（例えば、１つ値が増加するなど）。これにより、図５のステップ５０４や図６のステップ６０４で、ＱＮＥが受け取ったＲＥＳＥＲＶＥメッセージが、同一サブネット配下に存在するＭＮ１００から出されたものであるか否かを判断するために、フロー識別子を用いる代わりに、ＬＳＮを用いることができる。
【０１３５】
また、上述の第１の実施の形態では、ＭＮ１００がＭＩＥやＬＳＮを生成し、これを含むシグナリングメッセージを送信する例を示したが、ＣＮ１２４がＭＩＥやＬＳＮを生成し、これを含むシグナリングメッセージを送信してもよい。ＣＮ１２４はＭＮ１００からＢＵを受け取ることにより、ＭＮ１００がサブネットを移動したこと、及び最適化経路を使用することを知ることができるので、ＭＩＥやＬＳＮを生成し、これを含む最適化経路用ＱｏＳ経路を確立するためのシグナリングメッセージを送信することができる。
【０１３６】
なお、三角経路経由のパケット送受信の際、ＭＮ１００からＣＮ１２４、又はＣＮ１２４からＭＮ１００に向けて送信されるパケットが、同じＱＮＥを２回通過する可能性がある。この状態を、図７を参照しながら説明する。
【０１３７】
図７は、モバイルＩＰの三角経路経由でのパケット送受信において、ＭＮ１００からＣＮ１２４に向けて送信されるパケットが、同じＱＮＥ（図７のＱＮＥ８０４）を２回通過する例を示す模式図である。図７に示される経路例では、ＭＮ１００からＣＮ１２４に向けて、ＨＡ１１６を経由した三角経路を用いてパケットを送信する際、ＭＮ１００からＨＡ１１６の間の経路（経路８０８）は、ＡＲ８００、ＱＮＥ８０２、ＱＮＥ８０４を経由し、ＨＡ１１６からＣＮ１２４の間の経路（経路８１０）は、ＱＮＥ８０４、ＱＮＥ８０６を経由する。すなわち、ＭＮ１００から送信されたパケットはカプセル化されて、ＡＲ８００、ＱＮＥ８０２、ＱＮＥ８０４を経由してＨＡ１１６に送られ、ＨＡ１１６においてカプセル化が解かれた後、再びＱＮＥ８０４を通過し、ＱＮＥ８０６を経由してＣＮ１２４に届けられる。
【０１３８】
この経路上にＱｏＳ経路を確立するためにＭＮ１００からＣＮ１２４に向けてＲＥＳＥＲＶＥメッセージが送信された場合、ＲＥＳＥＲＶＥメッセージは、まずＡＲ８００、ＱＮＥ８０２、ＱＮＥ８０４を経由してＨＡ１１６に送られるので、ＱＮＥ８０４には経路８０８のリソース予約に関するステートが作られる。さらに、ＨＡ１１６に届けられたＲＥＳＥＲＶＥメッセージは、再びＱＮＥ８０４を通過し、ＱＮＥ８０６を経由してＣＮ１２４に届けられるが、ＱＮＥ８０４には既に経路８０８に関するＱｏＳステート（すなわち、同一セッション識別子に関するステート）が存在する。ここで、もし経路８０８に対するＭＩＥと、経路８１０に対するＭＩＥとが同一であった場合、ＱＮＥ８０４は、図７に示す経路の状態と、移動による経路変更（経路８０８と経路８１０のフロー識別子が異なる場合）や、ネットワーク側の何らかの変化により起こる経路変更（経路８０８と経路８１０のフロー識別子が異なる場合）とを区別することができないという問題が起こり得る。
【０１３９】
なお、上述の例では、ＭＮ１００からＣＮ１２４に向けてパケットを送信する場合を示しているが、ＣＮ１２４からＭＮ１００に向けてパケットを送信する場合も同様の問題が起こり得る。
【０１４０】
上記問題を回避するため、ＲＥＳＥＲＶＥメッセージには、「三角経路における、ＭＮ−ＨＡ間の経路」、「三角経路における、ＨＡ−ＣＮ間の経路」ということが明示的に示されることが望ましい。例えば、ＭＮ１００とＨＡ１１６の間の経路と、ＨＡ１１６とＣＮ１２４の間の経路とに、それぞれ異なるＭＩＥが設定されるようにしたり、更にＭＩＥとは異なる別の情報によって、異なる経路であることを明示したりすることが可能である。
【０１４１】
＜第２の実施の形態＞
経路種別識別子は、上述の第１の実施の形態のようにモバイルＩＰにおける三角経路と最適化経路を識別する以外に、例えば、複数の通信インタフェースを持った端末が相手ノードと通信を行う場合、各通信インタフェースを使った通信経路を識別する用途にも用いることができる。以下、図８Ａ〜８Ｃを参照しながら、複数の通信インタフェースを持った端末の各通信インタフェースに係る通信を経路種別識別子によって識別する、本発明の第２の実施の形態について説明する。
【０１４２】
図８Ａ〜８Ｃは、本発明の第２の実施の形態において、ＭＮが２つのインタフェースを用いて相手端末との通信を行う構成の一例を示す模式図であり、図８Ａには、２つのインタフェースが同一サブネットに接続している場合の構成、図８Ｂには、図８Ａの状態から一方のインタフェースのみが、他のサブネットにハンドオーバした場合の構成、図８Ｃには、図８Ａの状態から他方のインタフェース（図８Ｂの場合とは異なるインタフェース）のみが、他のサブネットにハンドオーバした場合の構成がそれぞれ示されている。
【０１４３】
図８Ａには、２つの通信インタフェース９２６及びインタフェース９２８を持つ端末であるＭＮ９１４が、相手端末であるＣＮ９１６と、１つのセッションに対するデータの送受信を、２つのインタフェースを同時に使って行う構成が示されている。なお、ここでは、ＭＮ９１４がＣＮ９１６からデータを受信する場合を例に説明を行うが、ＣＮ９１６がＭＮ９１４からデータを受信する場合にも、後述する同様の問題が発生する。
【０１４４】
図８Ａでは、ＭＮ９１４のインタフェース９２６及びインタフェース９２８が接続しているアクセスポイント（不図示）は、共に同一のアクセスルータ（ＡＲ９００）配下のサブネットに所属しており、ＭＮ９１４のインタフェース９２６及びインタフェース９２８には、ＡＲ９００配下のサブネットで使用されるＩＰアドレスが割り当てられている。なお、ＭＮ９１４のインタフェース９２６及びインタフェース９２８には、それぞれ異なるＩＰアドレスが割り当てられる。
【０１４５】
ＭＮ９１４がインタフェース９２６より受信するパケットは、ＣＮ９１６から送信された後、ＱＮＥ９０８、ＱＮＥ９０４、ＱＮＥ９０２及びＡＲ９００を経由する（経路９１８）。また、ＭＮ９１４がインタフェース９２８より受信するパケットは、ＱＮＥ９０８、ＱＮＥ９０６、ＱＮＥ９０２及びＡＲ９００を経由する（経路９２０）。
【０１４６】
また、図８Ｂには、図８Ａの状態から、インタフェース９２８のみが、ＭＮ９１４の移動又はアクセスポイントのリンクの状態の変化などにより、別のアクセスルータ（ＡＲ９１０）配下のサブネットに存在するアクセスポイントに接続先が変わった構成が図示されている。この場合、インタフェース９２８にはＡＲ９１０配下のサブネットで使用されるＩＰアドレスが割り当てられる。ＭＮ９１４がインタフェース９２８より受信するパケットは、ＣＮ９１６から送信された後、ＱＮＥ９０８、ＱＮＥ９０６、ＱＮＥ９１２及びＡＲ９１０を経由する（経路９２２）。
【０１４７】
また、図８Ｃには、図８Ａの状態から、インタフェース９２６のみが、ＭＮ９１４の移動又はアクセスポイントのリンクの状態の変化などにより、別のアクセスルータ（ＡＲ９１０）配下のサブネットに存在するアクセスポイントに接続先が変わった構成が図示されている。この場合、インタフェース９２６にはＡＲ９１０配下のサブネットで使われるＩＰアドレスが割り当てられる。ＭＮ９１４がインタフェース９２６より受信するパケットは、ＣＮ９１６から送信された後、ＱＮＥ９０８、ＱＮＥ９０６、ＱＮＥ９１２及びＡＲ９１０を経由する（経路９２４）。
【０１４８】
図８Ａの経路９１８及び経路９２０上にＱｏＳ経路を確立した場合、前述の通り、ＭＮ９１４は、２つのインタフェースを用いて（すなわち２つの経路９１８及び９２０を用いて）、同一セッションのパケットを受信しているので、経路９１８及び９２０に対するセッション識別子は同一となる。しかしながら、インタフェース９２６及び９２８に割り当てられているＩＰアドレスはそれぞれ異なるので、経路９１８及び９２０に対するフロー識別子は異なる。
【０１４９】
このような図８Ａの状態から、図８Ｂの状態に変化した場合、経路９２２に対してＱｏＳ経路が確立される。この場合のセッション識別子は、経路９１８及び経路９２０のＱｏＳ経路に対するセッション識別子と同一であるが、インタフェース９２８は新しいＩＰアドレスを取得しているため、フロー識別子は経路９１８用ＱｏＳ経路のフロー識別子とも、経路９２０用ＱｏＳ経路のフロー識別子とも異なる。この場合、経路９２０用ＱｏＳ経路は使用されなくなるので、例えばＱＮＥ９０６からＡＲ９００までの経路９２０用ＱｏＳ経路は解放される必要があり、ＣＮ９１６からＱＮＥ９０６までの経路９２０用ＱｏＳ経路は更新される必要がある。
【０１５０】
また、図８Ａの状態から、図８Ｃの状態に変化した場合、同様に経路９２４に対してＱｏＳ経路が確立される。この場合のセッション識別子は、経路９１８及び経路９２０のＱｏＳ経路に対するセッション識別子と同一であるが、インタフェース９２６は新しいＩＰアドレスを取得しているため、フロー識別子は経路９１８用ＱｏＳ経路のフロー識別子とも、経路９２０用ＱｏＳ経路のフロー識別子とも異なる。この場合、経路９１８用ＱｏＳ経路は使用されなくなるので、例えばＱＮＥ９０８からＡＲ９００までの経路９１８用ＱｏＳ経路は解放される必要があり、ＣＮ９１６からＱＮＥ９０８までの経路９１８用ＱｏＳ経路は更新される必要がある。
【０１５１】
しかしながら、図８Ａの状態から図８Ｂの状態に変化した場合においても、また、図８Ａの状態から図８Ｃの状態に変化した場合においても、セッション識別子が同一のまま、フロー識別子が変化するので、この２つの識別子だけを用いた場合、ＣＮ９１６からＱＮＥ９０６の区間において、経路９１８用ＱｏＳ経路及び経路９２０用ＱｏＳ経路のどちらが不要になったのかを判断することができないという問題が起こり得る。
【０１５２】
上記問題を解決するために、経路種別識別子を用いることができる。すなわち各インタフェースを用いた通信経路用ＱｏＳ経路に対し、経路識別子を与える。例えば、ＭＮ９１４は、インタフェース９２６を用いた通信経路に対しＱｏＳ経路確立を行う際には、経路種別識別子“００”を、また、インタフェース９２８を用いた通信経路に対しＱｏＳ経路確立を行う際には、経路種別識別子“０１”を、ＱｏＳ確立のためのシグナリングメッセージ（例えば、ＮＳＩＳ ＱｏＳのメッセージであるＲＥＳＥＲＶＥメッセージ）に含めて送信する。なお、このとき、ＭＮ９１４は、上述の第１の実施の形態と同様に、経路種別識別子以外の情報（例えば、接続先ＡＰのリンクの状態を考慮したQSpecや、ローカルに格納されたポリシー又はポリシーサーバを利用したポリシーに基づいたＣＩをシグナリングメッセージに含めてもよい。
【０１５３】
上述の第１の実施の形態の場合と同様、経路種別識別子を含んだシグナリングメッセージを受け取った各ＱＮＥは、リソース予約を行う際、セッション識別子やフロー識別子と共に、経路種別識別子をステートの中に含めて保持する。これにより、例えば図８Ａの状態から図８Ｂの状態に変化して、経路９２２に対するＱｏＳ経路確立が行われた際に、例えば経路９２０と経路９２２のクロスオーバポイントであるＱＮＥ９０６は、経路９２２に対するＱｏＳ経路確立用シグナリングメッセージに含まれる経路種別識別子“０１”と、格納されている経路９２０用リソース予約ステートの中に含まれる経路種別識別子“０１”とを、セッション識別子やフロー識別子と共に比較することにより、格納されているステートと同一のインタフェース（すなわち、インタフェース９２８）のハンドオーバによるＱｏＳ経路確立であると判断することができる。なお、判断された後の処理は、上述の第１の実施の形態と同様に、ＭＮ９１４から送られたＣＩに従ってもよいし、ＱＮＥ９０６がローカルに格納しているポリシーに従ってもよい。また、ポリシーサーバに格納されている情報を用いてもよい。
【０１５４】
また、上述の第１の実施の形態と同様、ネットワーク内の任意のノードが付加的サービス（例えば、ＱｏＳ）を制御するための機能を有し、ＭＮ９１４の代理（プロキシ）となってもよい。この場合、ＭＮ９１４は、付加的サービスを制御するための機能を持たなくてもよいが、プロキシとなった任意のノードが付加的サービスを制御するために必要な情報を、プロキシとの間で交換する手段を有する。
【０１５５】
＜第３の実施の形態＞
さらに、例えば、セッションのアグリゲーション及び異なるセッションの関連付けが同時に行われた場合において発生し得る問題を解決するために、アグリゲートされたセッションと関連のあるセッションとの識別を行う用途に、経路種別識別子を用いることも可能である。以下、図１３を参照しながら、アグリゲートされたセッションと関連のあるセッションとを経路種別識別子によって識別する、本発明の第３の実施の形態について説明する。
【０１５６】
図１３は、本発明の第３の実施の形態において、セッションのアグリゲーション及び異なるセッションの関連付けが同時に行われた状態を説明するための模式図である。なお、図１３に図示されているネットワーク構成及び通信の基本的な態様は、図１２に図示されているものと同一である。すなわち、図１３において、ＱＮＥ１３００からＱＮＥ１３１０に対してＱＮＥ１３０２、１３０６、１３０８を経由して送られるＥ２Ｅシグナリングメッセージと、ＱＮＥ１３１０からＱＮＥ１３００に対してＱＮＥ１３２０、１３０６、１３０２を経由して送られるＥ２Ｅシグナリングメッセージとは互いに関連のあるメッセージである。また、ＱＮＥ１３０２及びＱＮＥ１３０６は、内部にＱＮＥ１３０４を有するアグリゲーションドメインのエッジに位置しており、ＱＮＥ１３０２とＱＮＥ１３０６との間では、シグナリングメッセージはアグリゲートされる。
【０１５７】
図１３に図示されているように、本発明の第３の実施の形態では、関連のあるセッションに関して同一のセッション識別子を用いるようにする。従来、例えば図１１、１２に図示されているＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａ及びＥ２Ｅ＿Ｄのように、同一のエンドノード間のセッションに関して、その方向が異なる場合には異なるセッション識別子が付与されていたが、本発明の第３の実施の形態では、従来は異なるセッション識別子Ａ、Ｄで表されていた２つのＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａ、Ｅ２Ｅ＿Ｄは、図１３に図示されているように、同一のセッション識別子Ａで表される。
【０１５８】
図１３に図示されているように、関連のあるセッション（例えば、同一エンドノード間において生成されるセッションであって、方向（上り方向（upstream）と下り方向が異なるセッション）同士を同一のセッション識別子を用いることによって、従来は異なるセッション識別子（図１１、１２におけるセッション識別子Ａ、Ｄ）によって表されていた２つのＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａ、Ｅ２Ｅ＿Ｄの関連が自明となり、BOUND_SESSION_IDパラメータを用いた関連付けを行う必要がなくなる。したがって、関連のあるシグナリングメッセージの把握が容易となり、同一のエンドノード間における２つの双方向のＥ２Ｅシグナリングメッセージの少なくとも一方がアグリゲーションドメインにおいてアグリゲートされた場合においても、BOUND_SESSION_IDパラメータを２つ用意したり、BOUND_SESSION_IDパラメータの中に２つのセッション識別子を格納したりする必要はない。
【０１５９】
図１３において、任意のセッションの通信経路上に存在するＱＮＥは、そのセッションに対して何らかの変化を検出した場合に、シグナリングメッセージを送信する。例えば、ＱＮＥ１３００とＱＮＥ１３１０との間においてＥ２Ｅシグナリングメッセージの送受信が行われ、ＱＮＥ１３０２とＱＮＥ１３０６との間において、アグリゲーションシグナリングメッセージの送受信が行われる。
【０１６０】
ＱＮＥ１３００とＱＮＥ１３１０との間で、異なる方向のＥ２Ｅシグナリングメッセージに同一のセッション識別子が用いられた場合には、さらに、ＱＮＥ１３００からＱＮＥ１３１０の方向に送信されるシグナリングメッセージであるか、あるいは、ＱＮＥ１３１０からＱＮＥ１３００の方向に送信されるであるかを区別できるようにする必要がある。この区別は、シグナリングメッセージに経路種別識別子を挿入することによって可能となる。すなわち、「ＱＮＥ１３００からＱＮＥ１３１０の方向」を示す経路種別識別子（例えば０ｘ００）、「ＱＮＥ１３１０からＱＮＥ１３００の方向」を示す経路種別識別子（例えば０ｘ１１）をあらかじめ定めておき、このような関連のあるセッションを互いに識別可能とする経路種別識別子を、セッション識別子やフロー識別子と共に持たせることが可能である。
【０１６１】
ＱＮＥ１３００とＱＮＥ１３１０との間の異なる２つのセッションに同一のセッション識別子を持たせ、さらに、それぞれのセッションの方向を識別するための経路種別識別子を持たせる方法は、BOUND_SESSION_IDパラメータを複数持たせる方法や、BOUND_SESSION_IDパラメータの中に複数のセッション識別子を持たせるとともに、これらを区別する情報を持つフィールドを更に付加する方法に比べ、メッセージ長を短くすることができる。
【０１６２】
従来の技術では異なる方向のＥ２Ｅシグナリングメッセージ（図１１、１２のＥ２ＥシグナリングメッセージＥ２Ｅ＿Ａ、Ｅ２Ｅ＿Ｄ）の関連付けにBOUND_SESSION_IDパラメータを用いた場合には、セッション識別子そのものを格納しなければならない。一方、本発明では、セッション識別子を同一にする一方、方向を区別するための経路種別識別子を付加する。セッション識別子のビット数は大きいのに対し、経路種別識別子はビット数を小さくすることができるので、その分、メッセージ長を短くすることが可能となる。
【０１６３】
さらに、関連のあるセッションに対して同一のセッション識別子を付与するとともに、経路種別識別子によってそれぞれの経路種別（方向）を識別できるようにすることによって、アグリゲーションのエッジに位置するＱＮＥ１３０２やＱＮＥ１３０６の負担を軽減することも可能となる。従来はセッションの関連付け及びアグリゲーションの対応の２つの用途に関して、BOUND_SESSION_IDパラメータが用いられていたが、本発明ではセッションの関連付けは経路種別識別子によって行われるので、BOUND_SESSION_IDパラメータの用途は、アグリゲーション用に限定される。したがって、アグリゲーションのエッジに位置するＱＮＥ１３０２やＱＮＥ１３０６では、BOUND_SESSION_IDパラメータ及びその中に格納されているセッション識別子をアグリゲーションで使われるセッション識別子であると限定して処理することができる。
【０１６４】
なお、ＱＮＥ１３００とＱＮＥ１３１０との間の異なる２方向のシグナリングメッセージの関連付けに経路種別識別子を用いることに伴い、アグリゲーションドメインの中で、ＱＮＥ１３０６からＱＮＥ１３０２の方向に送信されるアグリゲーションシグナリングメッセージに使われるセッション識別子と、ＱＮＥ１３０２からＱＮＥ１３０６の方向に送信されるアグリゲーションシグナリングメッセージに使われるセッション識別子とに対して同一のセッション識別子（すなわち、セッション識別子Ｃ）を使用するとともに、これらの２つの方向を識別するために経路種別識別子を使用することも可能である。この場合、アグリゲーションドメイン内で送信されるアグリゲーションシグナリングメッセージには、アグリゲーション用のBOUND_SESSION_IDパラメータの中にセッション識別子Ｃが格納されるとともに、さらに、ＱＮＥ１３０６からＱＮＥ１３０２の方向又はＱＮＥ１３０２からＱＮＥ１３０６の方向を示す経路種別識別子の情報も格納される必要がある。すなわち、アグリゲーションドメインのエッジに位置するＱＮＥ１３０２、１３０６は、必要に応じて、関連のあるアグリゲーションシグナリングメッセージに対して、同一セッション識別子を付与するとともに、経路種別識別子によってそれらの方向の識別を行うことが可能である。
【０１６５】
なお、上述の第１の実施の形態及び第２の実施の形態において、経路種別識別子を含むＮＳＩＳ ＱｏＳのシグナリングメッセージの例としてＲＥＳＥＲＶＥメッセージを例に挙げているが、その他のメッセージ（例えば、ＮＳＩＳ ＱｏＳのＱＵＥＲＹ、ＮＯＴＩＦＹ、ＲＥＳＰＯＮＳＥなどの各種メッセージ）が経路種別識別子を含んでもよい。また、上述の第３の実施の形態においても、任意のＮＳＩＳ ＱｏＳのシグナリングメッセージの使用が可能である。
【０１６６】
また、上述の第１〜第３の実施の形態のそれぞれの動作を組み合わせて用いることも可能である。すなわち、上述の第１の実施の形態では、経路種別識別子によって三角経路及び最適化経路の識別が可能となり、上述の第２の実施の形態では、経路種別識別子によって、複数のインタフェースを有する端末のどのインタフェースを利用した通信経路であるかの識別が可能となるが、これらの両方の状態を完全に識別できるように、経路種別識別子を定めることも可能である。上述の第１及び／又は第２の実施の形態に対して、さらに、上述の第３の実施の形態において説明された経路種別識別子が用いられることも可能である。
【０１６７】
なお、経路種別識別子は端末で生成される以外にも、ＱＮＥなどの中間ノードで生成される場合も考えられる。例えば、中間ノードが終端ノードに対するパケットを、ロードバランシングやバイキャスティングなどの方法で複数の経路に対して送信している場合などにおいて、この中間ノードが、各経路に対しシグナリングメッセージを送信する際に、各経路の経路種別識別子を生成し、シグナリングメッセージに含ませてもよい。
【０１６８】
また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１６９】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１７０】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１７１】
本発明に係る通信方法及び通信メッセージ処理方法並びにこれらの方法をコンピュータにより実行するためのプログラムは、互いにネットワークを介して通信を行う端末の間に、同一セッションに対して、付加的サービスを提供するような経路が複数存在する場合に、それぞれの付加的サービスを提供する経路の種別に応じた処理を柔軟に行うことを可能とするという効果を有しており、通信を行う端末及び付加的サービスを提供するネットワークノードに係る技術分野に適用され、特に、次世代インターネットプロトコルであるモバイルＩＰプロトコルを利用した無線通信を行う移動端末の通信経路に、ＮＳＩＳを用いたＱｏＳ保証を与えることに係る技術分野に適用可能である。
【図面の簡単な説明】
【０１７２】
【図１】従来の技術及び本発明の第１の実施の形態における通信システムの構成を示す模式図
【図２】本発明の第１の実施の形態におけるＭＮの構成を示すブロック図
【図３】本発明の第１の実施の形態におけるシグナリングノードの構成を示すブロック図
【図４Ａ】本発明の第１の実施の形態において、接続状況の変化を検出したＭＮ内部の機能が、シグナリングメッセージの制御を行うＭＮ内部の機能に対して送る情報及びイベントトリガの一例を示す模式図
【図４Ｂ】本発明の第１の実施の形態において、接続状況の変化を検出したＭＮ内部の機能が、シグナリングメッセージの制御を行うＭＮ内部の機能に対して送る情報及びイベントタイプの一例を示す模式図
【図４Ｃ】本発明の第１の実施の形態において、接続状況の変化を検出したＭＮ内部の機能が、シグナリングメッセージの制御を行うＭＮ内部の機能に対して送る情報及び経路種別の一例を示す模式図
【図５】本発明の第１の実施の形態において、シグナリングメッセージを受け取ったＱＮＥが、このシグナリングメッセージと、格納されているステートの内容に従って、どのようにＱＮＥ内部のステートを処理するかの一例を示すフローチャート
【図６】本発明の第１の実施の形態において、シグナリングメッセージを送信するＱＮＥが、受け取ったシグナリングメッセージと、格納されているステートの内容に従って、どのようにＱＮＥ内部のステートを処理するかの一例を示すフローチャート
【図７】本発明の第１の実施の形態において、モバイルＩＰの三角経路経由でのパケット送受信の際に、ＭＮからＣＮに向けて送信されるパケットが、同じＱＮＥを２回通過する例を示す模式図
【図８Ａ】本発明の第２の実施の形態において、ＭＮの２つのインタフェースが同一サブネットに接続している場合の構成を示す図
【図８Ｂ】本発明の第２の実施の形態において、図８Ａの状態から一方のインタフェースのみが、他のサブネットにハンドオーバした場合の構成を示す図
【図８Ｃ】本発明の第２の実施の形態において、図８Ａの状態から他方のインタフェースのみが、他のサブネットにハンドオーバした場合の構成を示す図
【図９】従来の技術におけるＮＳＩＳで、どのようにＱｏＳリソース予約が行われるかを示す模式図
【図１０】従来の技術におけるＮＳＩＳでサポートされているアグリゲーションの一例を模式的に示す図
【図１１】従来の技術におけるＮＳＩＳでサポートされている異なるセッションの関連付けの一例を模式的に示す図
【図１２】従来の技術において、セッションのアグリゲーション及び異なるセッションの関連付けが同時に行われた場合の課題を説明するための模式図
【図１３】本発明の第３の実施の形態において、セッションのアグリゲーション及び異なるセッションの関連付けが同時に行われた状態を説明するための模式図
【図１】
0004616842.tif 000002
【図２】
0004616842.tif 000003
【図３】
0004616842.tif 000004
【図４Ａ】
0004616842.tif 000005
【図４Ｂ】
0004616842.tif 000006
【図４Ｃ】
0004616842.tif 000007
【図５】
0004616842.tif 000008
【図６】
0004616842.tif 000009
【図７】
0004616842.tif 000010
【図８Ａ】
0004616842.tif 000011
【図８Ｂ】
0004616842.tif 000012
【図８Ｃ】
0004616842.tif 000013
【図９】
0004616842.tif 000014
【図１０】
0004616842.tif 000015
【図１１】
0004616842.tif 000016
【図１２】
0004616842.tif 000017
【図１３】
0004616842.tif 000018