(57)【要約】異種混在ネットワークに設置された対応ノードと移動端末との間のハンドオーバをサポートする方法、システムおよびビジネスモデルが説明されている。  ハンドオーバパスが確立すると、複数のＱｏＳ特性に適応させることができる。確立されたハンドオーバパスと確立された第１予約パスとを考慮したアドミッション制御が実行される。ゲートウェイに連絡することにより、使用するハンドオーバパスが決定される。決定されたハンドオーバパスが垂直ハンドオーバに使用される。第１予約パスおよびハンドオーバパスを維持しながら、第２予約パスが確立される。
2006502658.tif 000002
【特許請求の範囲】
【請求項１】
異種ネットワーク間のハンドオーバをサポートする方法において、
第１予約パスを確立する過程と、
ＱｏＳ特性に適応させるために、ハンドオーバパスを確立する過程と、
確立されたハンドオーバパスと前記第１予約パスとを考慮してアドミッション制御する過程と、
ハンドオーバしている間に使用するハンドオーバパスを決定するために、ゲートウェイ装置に連絡する過程と、
決定されたハンドオーバパスを利用して垂直ハンドオーバをサポートする過程と、
前記第１予約パスと前記ハンドオーバパスとを維持しながら第２予約パスを確立する過程と、
を含む方法。
【請求項２】
前記ハンドオーバパスが複数のＭＰＬＳパスを有することを特徴とする請求項１に記載の方法。
【請求項３】
前記ＭＰＬＳパスが１以上のＱｏＳに適応することを特徴とする請求項２に記載の方法。
【請求項４】
アクセスルータが前記ゲートウェイ装置に連絡することを特徴とする請求項１に記載の方法。
【請求項５】
前記アクセスルータが前記ゲートウェイ装置に移動先管理ドメインを通知することを特徴とする請求項４に記載の方法。
【請求項６】
前記ハンドオーバが垂直ハンドオーバを含むことを特徴とする請求項１に記載の方法。
【請求項７】
データベースを検索して前記決定がなされることを特徴とする請求項１に記載の方法。
【請求項８】
複数のゲートウェイが１ハイパーオペレータと連絡する過程をさらに有することを特徴とする請求項１に記載の方法。
【請求項９】
前記第１予約パスおよび前記第２予約パスの少なくとも１つがＲＳＶＰパスを有することを特徴とする請求項１に記載の方法。
【請求項１０】
移動端末とこれに対応するノードとの間のハンドオーバを異種混在ネットワークにおいてサポートするシステムにおいて、
前記移動端末と前記対応ノードとを接続する第１予約パスと、
ＱｏＳ特性に適応させるための、ハンドオーバパスと、
確立されたハンドオーバパスと前記第１予約パスとを考慮するアドミッション制御アプリケーションと、
ハンドオーバしている間に使用するハンドオーバパスを決定するためのゲートウェイ装置であって、決定されるハンドオーバパスが垂直ハンドオーバをサポートするために使用されることを特徴とするゲートウェイ装置と、
前記第１予約パスと前記ハンドオーバパスとを維持しながら確立され、前記移動端末と前記対応ノードとを接続する第２予約パスと
を含むシステム。
【請求項１１】
前記ハンドオーバパスが複数のＭＰＬＳパスを有することを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記ＭＰＬＳパスが１以上のサービス品質特性に適応することを特徴とする請求項１１に記載のシステム。
【請求項１３】
アクセスルータが前記ゲートウェイ装置に連絡することを特徴とする請求項１０に記載のシステム。
【請求項１４】
前記アクセスルータが前記ゲートウェイ装置に移動先管理ドメインを通知することを特徴とする請求項１３に記載のシステム。
【請求項１５】
前記ハンドオーバが垂直ハンドオーバを含むことを特徴とする請求項１０に記載のシステム。
【請求項１６】
データベースをさらに有し、
前記ハンドオーバパスの決定がデ前記ータベースを検索することにより確立されることを特徴とする請求項１０に記載のシステム。
【請求項１７】
ハイパーオペレータをさらに有し、当該ハイパーオペレータが前記ゲートウェー装置と連絡することを特徴とする請求項１０に記載のシステム。
【請求項１８】
前記第１予約パスおよび前記第２予約パスの少なくとも１つがＲＳＶＰパスを有することを特徴とする請求項１０に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全体として通信システムに係り、詳しくは、移動無線通信システムにおいて、垂直ハンドオーバとともにＱｏＳ（Quality of Service）をサポートすることに関する。
【背景技術】
【０００２】
近年、モバイルコンピューティングの急激な進展とともに、新規無線技術の台頭が見られる。いつでもどこでもどんな形ででもネットワークに接続したいという人々の欲求に応じるように、種類の異なる通信システム、アプリケーション、通信装置、および通信事業者が多数存在している。これらの数は、現在も増加している。
当分の間、この異種混在状態は解消されそうにない。なぜなら、通信アプリケーション毎に必要とされる要件が異なり、あまねく最適な解決方法を見出すことが困難だからである。また、市場獲得に熱心なあまり、競合企業が互換性のない通信システムを発売してしまうからである。
そこで、次世代移動通信システムにおいて成功を収めるためには、このような異種混在環境において継ぎ目のないシームレスな通信サービスを提供できることが重要になり得る。
【０００３】
モバイルＩＰプロトコルは、ＩＰネットワークにおいてモビリティをサポートする、現在の標準的プロトコルである。
モバイルＩＰプロトコルでは、ホームエージェントおよびフォーリンエージェントが定義される。移動端末を宛先とするパケットは、ホームエージェントに横取りされ、フォーリンエージェントにトンネリング転送される。フォーリンエージェントは、カプセル化されたパケットからパケットを取り出して、取り出したパケットを移動端末に直接転送する。モバイルＩＰプロトコルの提供するフレームワークによれば、ユーザは、使用しているアプリケーションを中断することなく、ホームネットワークの外部に移動することができる。
しかし、モバイルＩＰプロトコルによる既存のネットワークは、端末のモビリティが頻度および空間的に制限される有線インターネットを念頭において構築されている。
また、モバイルＩＰプロトコルは、ネットワークのトポロジーについての情報を利用しない。モバイルＩＰプロトコルでは、同一の管理ドメイン内の隣接する基地局エリア間の移動のような局所移動が起きると、一斉更新が必ず行なわれる。
同様に、モバイルＩＰプロトコルは、広帯域幅や高信頼性等を要求するＱｏＳ （Quality of Services）特性もサポートしていない。
【０００４】
モバイルＩＰプロトコルはＱｏＳをサポートしない。その理由は、モバイルＩＰプロトコルがモビリティを異なる形式で統一的に扱い、ある基地局から別の基地局へのハンドオーバ全てに対して気付アドレスを新規に生成するからである。したがって、同一の管理ドメインにあり隣接する２つの基地局エリアの間等の短距離を移動するユーザは、離れたところにあるホームエージェントに煩雑に登録することになるので、信号の喪失や遅延等の重大なトラブルを経験することがある。
同様に、あらゆるハンドオーバに対して気付アドレスを新規に生成すると、ＱｏＳの新規予約あるいはパス設定が複雑となり、かつ遅延を生じるように成る。
【０００５】
このような課題を解決する既存の方式には、セルＩＰ（Cellular IP）、ハワイ（Hawaii）プロトコル、あるいはその他のマイクロモビリティ関連プロトコルがある。これらのプロトコルは、ネットワークのトポロジーに応じてフォーリンエージェントあるいはスマートフォーリンエージェントを階層的に導入することにより、局所移動に起因する一斉更新を制限しようとしている。しかし、既存の方式では、均質なネットワークおよび同一の管理ドメインを前提としている。別の言葉で表現すると、既存の方式は、水平ハンドオーバの課題を解決しようとしているが、異なる管理ドメインの下にある基地局の間のハンドオーバ等の垂直ハンドオーバを扱ってはいない。垂直ハンドオーバが起こると、既存の方式は機能しなくなる。なぜなら、異なる２つの管理ドメイン上に共通してエージェントが存在できないからである。垂直ハンドオーバが起こると、移動エージェントはモバイルＩＰプロトコルに依存して、マクロモビリティの問題を解決する。シームレスなサービスを可能とするためには、垂直ハンドオーバをしている時にＱｏＳ機能が提供されなければならない。
【０００６】
ＲＳＶＰプロトコルは、ＩＰネットワークでＩｎｔＳｅｒｖをサポートする、現在の標準的プロトコルである。保証されたサービスを提供するためには、予約あるいはアドミッション制御がエッジルータにおいて必要であることが知られている。このことは、コアネットワークで使用されているＱｏＳメカニズムの種類によらない。
ＲＳＶＰあるいはその派生プロトコルは、特定のアプリケーションのデータストリームについて、端末が具体的なＱｏＳ能力をネットワークに要求する時によく使用される信号処理プロトコルである。また、ＲＳＶＰプロトコルは、データストリームに沿った全てのノードにＱｏＳ要求を配信し、要求されたサービスを確立し、かつ維持するために、ルータに使用される。
【０００７】
次に、ＭＲＳＶＰ、ＲＳＶＰ−Ａ およびＲＳＶＰプロトコルを修正したその他の信号処理プロトコルがある。ＲＳＶＰプロトコルは、受信機から開始するアルゴリズムにより、モビリティを考慮することなく設計されているので、モビリティをサポートするために、ＭＲＳＶＰおよびその近縁のプロトコルが提案されている。しかし、これらのプロトコルは、アプリケーションが移動していきそうな基地局で事前設定される予約に基づいている。ＲＳＶＰソフトステートをリフレッシュするために多量の制御メッセージが必要となるので、事前予約をおこなうと、帯域幅が無駄になる。
【０００８】
マイクロモビリティプロトコルは、モビリティの問題を扱うのみであり、ＱｏＳをサポートする固有の機能はない。しかし、マイクロモビリティプロトコルは、ハンドオーバの前後で共通のエージェントを利用し、かつ共通するネットワークパスを再利用することで、この問題をある程度まで扱うことができる。ハンドオーバの前に予約されたパスを利用することができる上に、ＱｏＳの予約と情報の更新をローカルネットワーク内に制限することができる。しかし、ハンドオーバの間ＱｏＳがサポートされないという問題はそのまま存在する。
ＱｏＳがサポートされていない場合には、ある基地局エリアから別の基地局エリアに端末が移動すると、移動前の基地局にあるパケットは失われるか、あるいは、新しい基地局に転送される。マイクロモビリティプロトコルはパケットの喪失を減らそうとするが、帯域幅や遅延等の他のＱｏＳのパラメータを考慮してはいない。
同様に、異なるアプリケーションの扱いにおいて、扱いの区別が存在していない。異なるアプリケーションは、帯域幅、遅延、および喪失の点で異なるＱｏＳパラメータを有する。したがって、ＱｏＳクラス毎にアプリケーションは分割され、そのクラスに基づいて区別されたサービスをアプリケーションは受ける。
しかし、既存のハンドオーバ方式では、区別するという方針に反してアプリケーションを同一に扱うので、システムを不必要に酷使することになる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
以上説明したように、垂直ハンドオーバが起こると、マイクロモビリティプロトコルおよびその関連のＱｏＳを改善する派生プロトコルを使用することはできない。なぜなら、共通のエージェントおよび共通のネットワークパスが存在しないからである。
一方、ＲＳＶＰ、 ＭＲＳＶＰ、およびＲＳＶＰ−Ａプロトコル等の方式は、利用できる。しかし、一斉更新を引き起こすので、ハンドオーバにより長い期間を必要とする。そこで、ＱｏＳのサポートをハンドオーバ期間に提供する方法が問題となる。
【００１０】
また、ネットワーク層におけるＱｏＳサポートを採用するときには、上位層の適応能力も考慮することができる。適応能力は、移動機ドメインで動作する要素に必要とされる基礎要件である。アプリケーション、ミドルウェア、およびトランスポート層は、パケットの喪失および遅延に対処するために、適応メカニズムをある程度備えている。しかし、上位層の適応能力を考慮しない場合には、ＩＰ層をハンドオーバに適応させることは、メカニズムを不必要に重複させ、さらに、上位層のパフォーマンスまでも劣化させてしまうかもしれない。
【課題を解決するための手段】
【００１１】
シームレスな通信ができるように、移動端末による垂直ハンドオーバをサポートするＱｏＳサポートシステムが必要とされている。
【００１２】
異種混在ネットワークの間で垂直ハンドオーバをサポートする方法およびシステムについて説明する。ハンドオーバに適応させるために、アクセスルータは、ハンドオーバ期間にＱｏＳをサポートすることに特化したゲートウェイに連絡する。ピアハンドオーバゲートウェイの間に異なるＱｏＳ特性を有するパスが設定される。したがって、ゲートウェイは、対応する移動先ハンドオーバゲートウェイを決定し、アプリケーションの現在のハンドオーバ要求に最適なパスを選択する。このようなパスを利用できないとき、あるいは、ハンドオーバ量が過大であることによりパスが輻輳しているときには、ベストエフォート方式等の別の態様によりハンドオーバは扱われる。
【００１３】
ハンドオーバゲートウェイおよび関連して設定されるハンドオーバパスは、種々異なる方式で設定できる。まず、各通信事業者は自己の所有するゲートウェイ装置を管理し、隣接する通信事業者とハンドオーバ契約を結ぶことができる。この方式では、通信事業者数が増えるにつれ、管理がより困難になると考えられる。別の方式では、１ハイパーオペレータがハンドオーバ専用ネットワークを構築し、主要通信事業者との２者間契約を利用して専用ゲートウェイとハンドオーバパスとを運営する。ハンドオーバが起こると、各ドメインのゲートウェイはハイパーオペレータのオーバーレイネットワークに連絡してハンドオーバ処理を実現する。
【発明を実施するための最良の形態】
【００１４】
以下、ＱｏＳならびに異なる管理ドメインの間の水平および垂直ハンドオーバを扱う方法およびシステムについて説明する。具体的には、例えば通信事業者が異なる管理ドメイン間の垂直ハンドオーバを扱う。
水平ハンドオーバには、同種類の無線ネットワークインターフェースを使用する基地局間のハンドオーバも含まれる。垂直ハンドオーバには、異なる管理ドメインの下にある基地局間のハンドオーバを含むことができる。その他の垂直ハンドオーバとしては、技術が異なる無線ネットワーク間のハンドオーバ、異種混在している端末間のハンドオーバ、同一タスクをおこなう異なる種類のアプリケーション間のハンドオーバを考えることができる。
ハイパーオペレータのビジネスモデルによれば、専用のハンドオーバネットワークおよび関連するＡＡＡメカニズムを設けることができる。ハイパーオペレータは、関連する通信事業者と契約を交わし、その関連する通信事業者のためにハンドオーバを実行することができる。
【００１５】
図１は、ＱｏＳサポートシステムを実装する通信システム１００の例を説明するブロック図である。通信システム１００は通信ネットワーク１１０を含み、通信ネットワーク１１０は、セル式ネットワーク、衛星通信ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、あるいはＢｌｕｅｔｏｏｔｈ（登録商標）ネットワーク等のネットワークを含んでいる。
通信システム１００は、移動端末１２０および端末装置１３０を含んでいてもよい。移動端末１２０により、ユーザが端末装置１３０にアクセスすることができる。移動端末１２０の典型例に、ラップトップコンピュータ、セル式等の携帯電話機、個人情報端末（ＰＤＡ）、あるいは、通信ネットワーク１１０を介して端末装置１３０と通信するために使用されるその他の移動端末装置がある。端末装置１３０の典型例に、デスクトップコンピュータ、セル式携帯電話機等の電話機、ＰＤＡあるいはその他の装置がある。
【００１６】
図２は、ＱｏＳハンドオーバをサポートするネットワークアーキテクチャを説明するブロック図である。このネットワークアーキテクチャでは、通信事業者は隣接する通信事業者と契約を交わし、中間に位置するハイパー通信事業者は存在しない。
ＱｏＳサポートシステム２００は、第１ドメイン２０２、第２ドメイン２０４、およびインターネット２０６等の第３のドメイン等を含む、種々の管理ドメインを有する。
インターネット２０６にはＭＰＬＳパスが含まれる。このＭＰＬＳパスは、近隣の情報が収集された後、関連する管理ドメインにより予め設定される。管理ドメイン２０２、２０４、２０６は、隣接する管理ドメイン情報を有しているので、設定されたＭＰＬＳパスを利用することができる。ＱｏＳサポートシステム２００により、移動端末１２０のユーザは、対応ノード（図中、ＣＮと表記されている）２２２等の端末装置と通信をすることができる。
【００１７】
ＱｏＳサポートシステム２００は、管理ドメインと相互に通信し、垂直ハンドオーバおよび新規の予約処理の間、ＱｏＳの保証に役立てるために、必要な監視機能、必要な信号送出機能、および必要な維持管理機能を提供する。図２に示すＱｏＳサポートシステムは、ハイパーオペレータオーバーレイネットワークのない分散アーキテクチャを有している。
【００１８】
図２を参照して説明する。垂直ハンドオーバをしている間の転送を管理するために、ハンドオーバゲートウェイ（図中、ＨＯ−ＧＷと表記されている）２０８が管理ドメイン２０２、２０４、および２０６に導入されている。管理ドメイン２０２と２０４との間に設定されるＱｏＳパスを用意するために、マルチプロトコルラベルスイッチング（図中、ＭＰＬＳと表記されている）プロトコルが使用される。アプリケーションの要求に応じてハンドオーバ転送を種々取り扱うことができるように、ＱｏＳ特性の異なるＭＰＬＳパスを使用するようにしてもよい。
【００１９】
第１ドメイン２０２、第２ドメイン２０４およびインターネットドメイン２０６は、ルータ（図中、Ｒと表記されている）２１０、アンテナ、あるいはアクセスポイント（図中、ＡＰと表記されている）２１２等の他の通信設備も有する。インターネット２０６は、ゲートウェイ（図中、ＧＷと表記されている）ルータ２１４を有し、このゲートウェイルータは、第１管理ドメイン２０２および第２管理ドメイン２０４のフォーリンエージェント（図中、ＦＡと表記されている）のゲートウェイルータ２１６と接続している。これらのルータには、アクセスルータ（図中、ＡＲと表記されている）２１８も含まれ、このアクセスルータ２１８に、アンテナあるいはアクセスポイント２１２からアクセスすることができる。また、ホームエージェント２２０等の他の通信設備からもアクセスすることができる。移動端末の通信ピア等の対応ノード２２２は、エッジルータ（図中、ＥＲと表記されている）２２４等の他のルータを介してインターネットドメイン２０６にアクセスすることができる。
【００２０】
既存のＱｏＳ技術であるＤｉｆｆｓｅｒｖ（Differentiated services）、ＭＰＬＳ、およびＲＳＶＰプロトコル、あるいはその他の類似のアプリケーションが、ルータの間にパスを設定することができる。スケーラビリティおよびトラフィックエンジニアリング能力がＭＰＬＳ技術にはあるので、インターネット２０６において異なるＱｏＳ特性を有するハンドオーバパスの設定に、ＭＰＬＳ技術を使用することができる。
別の技術も使用することができるであろう。たとえば、第１ドメイン２０２と第２ドメイン２０４との間にＭＰＬＳパスＭ１とＭ２とを２つ確立することができるから、アプリケーションの要求に応じて、Ｍ１あるいはＭ２のいずれかを使用することができる。
ＭＰＬＳプロトコルはトラフィックエンジニアリングおよびトンネリングをサポートするので、スケーラブルかつコアネットワークへの実装に適する通信フレームワークを可能にする。トラフィックエンジニアリングは、その時点のネットワークの転送負荷に応じて異なる複数のパスに転送量を配分するために使用される。トンネリングは、パケットを別のパケットに包み込ませることによりパケットを重畳して新しい宛先に送るために使用される。
【００２１】
垂直ハンドオーバは、通常、２つのネットワークが共通にカバーしているところ（オーバーレイエリア２２６として知られている）で起こる。垂直ハンドオーバは、ユーザがその必要に応じてアクセスネットワークを主体的に選択するときに起こり得る。また、垂直ハンドオーバは、通信サービス提供者との契約に基づいても起こり得る。
ユーザの要求には、電話のためのセル式ネットワークやマルチメディアストリーミング伝送のための無線ローカルエリアネットワーク等のアプリケーションのＱｏＳ要求が含まれることもある。その他に、費用、情報の安全性等が要求されることもある。ユーザの異なる要求に合わせる様に、異種混在したネットワークが存在している。
【００２２】
垂直ハンドオーバは、アクセスネットワークの提供地域が限定されていることから起こることもある。ユーザは、アクセスネットワークの提供地域の外縁部に来ると、アクセスシステムを変更する。ユーザがオーバーレイエリア２２６にいるときに、ユーザは垂直ハンドオーバを利用して、あるアクセスネットワークから別のネットワークに切換えることができる。ユーザがオーバーレイエリア２２６にいないときは、ユーザが接続を失うこともある。接続が切断されるとセッションはリセットされる。あるいは、ソフトウェアが他の方法による補正を試みる。たとえば、異なる符号化方法を利用して受信済みのパケットから失った情報を復元することを試みる。
【００２３】
インターネットプロトコル（ＩＰ）は、異なる管理ドメイン相互とインターネット２０６とを接続するためのネットワーク層に共通するプロトコルである。インターネット２０６では、ＭＰＬＳ等のＱｏＳサポートが提供されている。
標準的モバイルＩＰプロトコルではマクロモビリティが取り扱われる。しかし、上記説明してきたフレームワークには、通信事業者間のハンドオーバパスが存在しないので、マクロモビリティを取り扱うことができない。水平ハンドオーバの間のＱｏＳおよびネットワーク内のＭＰＬＳパスの保証に役立つように、管理ドメインは、ハワイプロトコル、セルＩＰプロトコル等の種々のマイクロモビリティを備えている。
【００２４】
対応ノード２２２は、モバイルＩＰ通信プロトコルを使用して移動端末（図中、ＭＨと表記されている）１２０と通信する。ホームエージェント（図中、ＨＡと表記されている）２２０には、ソフトウェア等によるマルチパス予約機能が備わっている。この予約は、ホームエージェント２２０によるＲＳＶＰプロトコルによりおこなわれる。モバイルＩＰプロトコルは、パケットをルーティングするために使用されるが、ＱｏＳのサポートはない。ＱｏＳのサポートを設定するために、ＲＳＶＰ、Ｄｉｆｆｓｅｒｖ、あるいはＭＰＬＳ等のプロトコルが使用される。
第１ドメイン２０２と第２ドメイン２０４は、垂直ハンドオーバのＱｏＳを提供するために、ハンドオーバゲートウェイ（図中、ＨＯ−ＧＷと表記されている）を有する。ドメイン特有のＱｏＳメカニズムにより、ハンドオーバゲートウェイとアクセスルータとの間にＱｏＳが実現されている。アクセスポイント２１２は、下敷きとなる８０２．１Ｑ／ＤやＬＡＮのためのサブネット帯域幅管理（ＳＢＭ）等の異なるレイヤー２技術に応じた、レイヤー２ＱｏＳメカニズムも備えている。
【００２５】
設定されたＱｏＳ特性を備えたＭＰＬＳパスＭ１およびＭ２は、垂直ハンドオーバの間、エンドツーエンドでＱｏＳを取り扱うことができる。第１ドメイン２０２と第２ドメイン２０４のハンドオーバゲートウェイ２０８は、ＭＰＬＳパスＭ１およびＭ２を確立する。これらの管理ドメインについて、複数のハンドオーバゲートウェイ２０８を階層的に組織化することができる。具体的には、ネットワークトポロジーおよびハンドオーバ転送量のパターンに応じて、１ドメインの管理層における複数のハンドオーバゲートウェイ２０８がハンドオーバパスの設定に関わるようにすることができる。ハンドオーバゲートウェイ２０８は、複数のアクセスルータ２１８のハンドオーバ転送を取り仕切る。別の管理ドメインとのオーバーレイエリアの近くにあるアクセスルータ２１８では、ハンドオーバゲートウェイ２０８を介して、垂直ハンドオーバがより多く起こり得る。後述するハイパーオペレータ等の集中処理を行なう通信事業者がないときは、各管理ドメインのハンドオーバゲートウェイ２０８は、他の通信事業者の隣接するハンドオーバゲートウェイを識別する。ある期間クライアントの移動パターンを記録し、ハンドオーバの後にクライアントが次に通信する通信事業者を検証することにより、隣接するハンドオーバゲートウェイの情報を得ることができる。隣接するハンドオーバゲートウェイが識別されると、ＭＰＬＳパスを確立できる。
【００２６】
図３は、ハンドオーバ処理を説明するフローチャートである。
垂直ハンドオーバが起こると、アクセスルータ２１８は、管轄するハンドオーバゲートウェイ２０８に、移動先となる管理ドメイン、例えば、第１ドメイン２０２あるいは第２ドメイン２０４、の情報を通知する（ステップ３００）。移動先管理ドメインの情報が、リンクレイヤー移動管理アルゴリズムにより、アクセスルータに提供される。この情報を受信すると、ハンドオーバゲートウェイ２０８は、データベースが管理ドメインを含んでいてＭＰＬＳパスが確立しているかどうかを決定するために、隣接するデータベースに問合わせる（ステップ３１０）。管理ドメインが含まれていてＭＰＬＳパスが確立しているときは、垂直ハンドオーバが起きることができる（ステップ３４０）。それ以外のときは、更新アルゴリズムにしたがってその情報がデータベースに追加される。このようにして、次の垂直ハンドオーバのための新しいＭＰＬＳパスの初期化処理がおこなわれる（ステップ３５０）。各アクセスルータがオーバーレイできるネットワークの数は限られているので、ハンドオーバゲートウイェイ２０８が習得を完了して全機能を発揮するためには、問合せを数回繰り返すだけで充分である。
【００２７】
このようにして、ハンドオーバゲートウェイ２０８は隣接するデータベースを更新し、各隣接ネットワークに対して、異なるＱｏＳパラメータを有する複数のＭＰＬＳパスを確立する。Ｍ１とＭ２は例示として使用されているだけであり、要求に基づいて複数のパスを確立することができる。また、ハンドオーバゲートウェイ２０８は、性能とスケーラビリティにあわせるために、同一の管理ドメインにある他のハンドオーバゲートウェイと通信することができる。
ハンドオーバゲートウェイ２０８はＭＰＬＳパスを監視・維持し、新しいアドミッション制御アルゴリズムを達成するために、関連するＱｏＳパラメータをアクセスルータ２１８に報告する。ハンドオーバゲートウェイ２０８は信号処理および信号トンネリング処理を実行して、ハンドオーバ転送の開始および終了をすることもできる。
【００２８】
標準的なＭＰＬＳ手続は、ルータの設定、例えば、ＱｏＳクラス、リアルタイム／非リアルタイム等のアプリケーションのＱｏＳ要求、および区別されたハンドオーバのＱｏＳ要求を選択することに、使用することができる。ハンドオーバのＱｏＳ要求は、アプリケーションのＱｏＳ要求に影響を受けることがある。インターネットプロトコル２（ＩＰ２）にしたがって、ハンドオーバが、ファーストハンドオーバ、スムーズハンドオーバ、およびシームレスハンドオーバとに分類される。その他のハンドオーバには、広帯域ハンドオーバが含まれる。ファーストハンドオーバとは、例えば、リアルタイムサービス等の厳密な遅延制限を充足することができるハンドオーバである。スムーズハンドオーバとは、パケットの喪失を最小とすることができるハンドオーバである。シームレスハンドオーバとは、サービスの中断が認識されることを最小限にできるハンドオーバである。
【００２９】
ＭＰＬＳによれば、ＱｏＳパラメータの点で精細なグラニュアリティが可能となり、ハンドオーバの質のより精細な制御、および、性能、費用、および複雑さがバランス良く成立するように複数のパスを確立することができるようになる。遅延、喪失、および帯域幅等のＱｏＳパラメータはアプリケーションに影響を与える。これらのパラメータに適合させるように、ファーストハンドオーバ、スムーズハンドオーバ、広帯域ハンドオーバ、およびシームレスハンドオーバが組合せられる。
【００３０】
垂直ハンドオーバをサポートするために、アクセスルータ２１８は、移動端末１２０で稼動しているアプリケーションがハンドオーバの間に必要としているサービスを決定する。この決定は、種々の方法で行なうことができる。例えば、アプリケーションの要求およびＩＰ層よりも上位における適合能力、例えば、トランスポート層、アプリケーション層、あるいはＩＰ層よりも上位の他のいずれかの層における適合能力、に基づいて、アプリケーションを初期化する時に、アプリケーションがアクセスルータ２１８に情報を提供する事ができる。また、アクセスルータフローポートフィールドを検証することにより、この情報を得ることができる。ＩＰパケットのヘッダにおけるこのポートフィールドは、上位レイヤでこのパケットに使用されているプロトコルを示すために使用される。つまり、アプリケーションカテゴリ情報である。このフローポートフィールドを検証することにより、アプリケーショントランスペアレンシーが可能となるが、アプリケーションからこの情報を決定するよりも得られる情報は不正確である。
【００３１】
パスが設定され、アクセスルータが垂直ハンドオーバサービス要求を受信すると、このパスを種々の方法で利用することができる。ハンドオーバが起きると、例えば第１ドメイン２０２にある現在のアクセスポイント２１２から滞留（残留）しているパケットを、例えば第２ドメイン２０４にある新しいアクセスポイント２１２に転送するために、このパスを利用できる。このパスは、対応ノード２２２と新しいアクセスポイント２１２との間で新しく予約がおこなわれている間に、新しいパケットを現在のアクセスポイント２１２から新しいアクセスポイント２１２に転送する為にも利用できる。素早く新規予約ができないときは、新規予約が達成されるまでこのパスをパケットを転送するために利用できる。あるいは、セッションが終了する。
【００３２】
図４は、ＱｏＳサポートシステムに係る予約およびアドミッション制御の例を説明するフローチャートである。移動端末１２０は予約とアドミッション制御を実現するアプリケーションを備えることができる。
移動端末１２０とホストエージェント２２０との間のリンクおよびホストエージェント２２０と対応ノード２２２との間のリンクを介して、パスの予約をおこなうことができる。垂直ハンドオーバの前後のＱｏＳのサポートの仕方を検証することにより、アプリケーションは異なるフェーズで動作する。
【００３３】
第１フェーズは、ハンドオーバの前のアプリケーションが通常動作する時間を含んでいる。このフェーズにおけるＱｏＳサポートは、従来のＲＳＶＰプロトコルにより確立され、ＲＳＶＰパスを維持することにより達成できる。
第２フェーズは、元となる基地局によりハンドオーバが検出された時点から、新しい基地局に新しいＲＳＶＰパスが確立される時点までの期間を含んでいる。この期間に、第１フェーズのＲＳＶＰパスおよび選択の様に構成されたＭＰＬＳパスが協働し、アプリケーションに対してＱｏＳを保証する。第３のフェーズは、第１フェーズの予約パスおよびＭＰＬＳハンドオーバパスが解放され、後続する転送のために新しく確立したパスのみが利用される期間を含んでいる。第３フェーズの後、アプリケーションは第１フェーズに入ることができ、アプリケーションは再び通常動作を始める。
【００３４】
非ハンドオーバ動作フェーズの間、アクセスルータ２１８（アドミッション制御ポイントでもある）にアプリケーションのＱｏＳ要求を提供するために、ＲＳＶＰメッセージが利用される（ステップ４００）。このＲＳＶＰメッセージには、所望のＱｏＳ（ＲＳＰＥＣ）、転送特性（ＴＳＰＥＣ）、およびフロー識別子（ＦＩＬＴＥＲ＿ＳＰＥＣ）が含まれる。例えばハンドオーバの間の要求等の第２フェーズにおけるアプリケーションのＱｏＳ要求がアクセスルータ２１８に提供される（ステップ４１０）。サービスを保証するために役立つ移動計算ソフトウェアが多岐にわたることがあり得るので、サービスロスプロフィール、垂直ハンドオーバサービス要求、および起こり得るシームレス通信要因には、トランスレーションの間の適合ＱｏＳ要求を表示するための要因も含まれることがある。
【００３５】
指定されたハンドオーバのＱｏＳ要求に応じて、構成されたＭＰＬＳパスが選択される（ステップ４２０）。上述の情報要因を利用するアプリケーションに適合した、Ｍ１またはＭ２等の特定のＭＰＬＳパスを決定するために、アクセスルータ２１８が利用される。ＭＰＬＳパスＭ１およびＭ２におけるその時点の転送負荷も考慮することができる。ハンオーバゲートウェイの監視および報告機能により転送負荷の報告を受けることができる。
【００３６】
アプリケーションによる予約を受諾するか否かを決定するためにアドミッション制御が使用される（ステップ４３０）。その予約を受諾するか否かの決定に役立てるために、受信されたハンドオーバ要求が利用される。例えば、垂直ハンドオーバに利用されるか否かに関わらず、選択されたＭＰＬＳパスにおける遅延を含むアドミッション制御アルゴリズムを、エンドツーエンド遅延制限の計算に利用できる。システム利用についてのより正確な情報を生成するために、確立論モデルに基づくアルゴリズム等の少し進んだ他のアルゴリズムを使用することもできる。予約が受諾されないと予約は終了し、その後必要に応じて再び予約が提出される（ステップ４４０）。
【００３７】
予約が受諾され、移動端末１２０および対応ノード２２２との間で垂直ハンドオーバが起きると、垂直ハンドオーバは、構成されたＭＰＬＳパスによりサポートされる（ステップ４５０）。新しい対応ノード２２２から移動端末に、新しいネットワークへのパスを介して、新しいＲＳＶＰ予約がおこなわれる。この処理時間（ハンドオーバ時間）の間、新しい予約が完了するまでＱｏＳサポートが保証される。
【００３８】
ＱｏＳサポートシステムは、上記パス設定過程およびハンドオーバを利用する。
移動端末１２０は、第１度メインと第２ドメンのオーバーレイエリアに位置する。ＱｏＳサポートシステムアルゴリズムは、一方のドメイン、例えば第１ドメンにより開始される。アプリケーションは要求されたＱｏＳパラメータを第１ドメンのアクセスルータに送信する。アクセスルータは自身の管轄ハンドオーバゲートウェイにアクセスして、このアプリケーションに適合したＭＰＬＳパスを決定する。アドミッション制御にうまくいくと、移動端末と対応ノード２２２との間に第１パスが設定される。この予約過程はモバイルＩＰプロトコル上で動き、例えば、ＩＰ−ＩＰトンネリングＱｏＳサポートが利用される。
【００３９】
移動端末１２０が第２ドメインに切り換えると、垂直ハンドオーバが起きる。移動端末１２０が第２ドメインにおいて認証および認可手続を通ると、第２ドメンアクセスルータは、第２ドメインのハンドオーバゲートウェイ２０８に通知する。続いて、第２ドメインのハンドオーバゲートウェイ２０８が第１ドメインのハンドオーバゲートウェイ２０８にアクセスして、第１ドメインのアクセスルータと第２ドメインのアクセスルータとの間にトンネリングを確立する。このトンネリングでは、エンドツーエンドＱｏＳ要求を満たすように、選択されたＭＰＬＳパスが使用される。第２ドメインのアクセスルータ２１８は移動端末１２０と対応ノード２２２との間のパスを再び取り決める。設定の間、新しいパケットは第１ドメンアクセスルータに引き続き送られ、続いて第２ドメインアクセスルータ２１８にトンネリング転送される
【００４０】
新規パスの設定が完了し、アドミッション制御がうまくいくと、例えば最後にアドミッション制御を実現したルータは、そのパスを予約するために、ＲＥＳＶｃｏｎｆメッセージ等の確認メッセージを第２ドメインルータに送信することができる。ルータは、古いパスを切断するために、例えばＲＥＳＶｔｅａｒメッセージ等のメッセージを第１ドメインルータに送信することもできる。ＲＥＳＶｔｅａｒメッセージを受信すると、第１ドメインのアクセスルータはアクセスルータのバッファ内でパケットを完成させ、第１ドメインハンドオーバゲートウェイに通知する。
【００４１】
アドミッション制御に失敗すると、ＲＥＳＶｔｅａｒ情報が第２ドメインのアクセスルータに戻る。このとき、第２ドメインのアクセスルータは定義されたポリシーあるいはアプリケーションの要求にしたがって、このコールを取り扱うことができる。第２ドメインは、例えば、ある時間遅延させた後アドミッション制御を得ることを試行するなどしてこの予約を再び取り決めることができる。第２アクセスルータは第１アクセスルータ２１８とトンネリングを維持する時間について取り決めることができる。第２ドメインアクセスルータ２１８も、この適応方法について移動端末と取り決めることができる。接続が維持されるので、この過程においても、ＱｏＳサポートが利用される。
【００４２】
図５は、ＱｏＳサポートシステム５００に係るネットワークアーキテクチャを説明するブロック図である。このネットワークアーキテクチャには、ハイパーオペレータオーバーレイネットワーク（図中、ＨＯ−ＯＬと表記されている）５１０が含まれる。ハイパーオペレータオーバーレイネットワークはインターネットドメイン２０６の中に存在することができる。インターネットドメイン２０６は、第１管理ドメイン２０２や第２管理ドメイン２０４等の管理ドメイン内の関連するゲートウェイと相互に情報を交換する。ハイパーオペレータオーバーレイネットワーク５１０は、管理ドメイン内のハンドオーバゲートウェイ２０８により実行されるタスクの数を削減することができる。ハイパーオペレータオーバーレイネットワーク５１０は、ＭＰＬＳパスの確立、ＭＰＬＳパスＭ１、Ｍ２における転送の監視・維持、およびアクセスルータ２１８と協調動作してアドミッション制御をする等の複数の機能を制御できる。この場合、ハンドオーバゲートウェイ２０８は、管理ドメインにおいてＱｏＳサポートを提供する等して、局所最適化を管理する。
【００４３】
ハイパーオペレータオーバーレイネットワーク５１０は、各管理ドメインについてのグローバルな知識を有しているので、最適な垂直ハンドオーバ性能を達成できる。ハイパーオペレータオーバーレイネットワーク５１０は、コアネットワークに位置する関連するルータと相互に通信して、ＱｏＳルーティングのサポートとパスの新規予約処理を加速することができる。ハイパーオペレータオーバーレイネットワーク５１０は、セキュリティおよびＡＡＡ（認証認可説明）等の他のポリシー問題も扱うことができる。一般に、これらの問題は１通信事業者にとって容易なものではない。ハイパーオペレータオーバーレイネットワーク５１０が信号パスを提供することもできるので、このアーキテクチャは実装が容易である。
【００４４】
このように、ハイパーオペレータオーバーレイアーキテクチャあるいは分散アーキテクチャを使用するＱｏＳサポートシステムを説明してきた。このアーキテクチャには、シームレスな垂直ハンドオーバをサポートするための垂直ハンドオーバゲートウェイ２０８が含まれている。このフレームワークでは、ＭＰＬＳを選択することにより、遅延、喪失、および帯域幅の点で幅のあるハンドオーバ要求をサポートすることができる。このフレームワークでは、アプリケーションがそのメカニズムを考慮した後にＱｏＳ要求を指定することができるようにすることで、アプリケーションレイヤーの適応能力も考慮することができる。このとき、このネットワークは、必要な適応能力を提供し、機能が重複することを避けることができる。このフレームワークは異なるアプリケーションをサポートすることができる。
【００４５】
以上実施形態を参照し本発明を説明してきたが、発明の範囲を逸脱することなく、さまざまな変更と修正が可能である。したがって、以上の説明は、本発明の現在における好適実施形態を例示することを目的としているが、発明を限定するものではない。本発明の範囲は、特許請求の範囲およびその均等の範囲のみから画定される。
【図面の簡単な説明】
【００４６】
【図１】図１は、ＱｏＳサポートシステムを実装する通信システムの例を説明するブロック図である。
【図２】図２は、ＱｏＳハンドオーバをサポートするネットワークアーキテクチャを説明するブロック図である。このネットワークアーキテクチャでは、通信事業者は隣接する通信事業者と契約を交わし、中間に位置するハイパー通信事業者は存在しない。
【図３】図３は、ハンドオーバ処理を説明するフローチャートである。
【図４】図４は、アプリケーションのＱｏＳ要求に応じて、ハンドオーバパスの予約、アドミッション制御、および選択をおこなう例を説明するフローチャートである。
【図５】図５は、ハイパーオペレータオーバーレイネットワークを含むＱｏＳサポートシステムに係るネットワークアーキテクチャを説明するブロック図である。
【図１】
2006502658.tif 000003
【図２】
2006502658.tif 000004
【図３】
2006502658.tif 000005
【図４】
2006502658.tif 000006
【図５】
2006502658.tif 000007
【国際調査報告】
2006502658.tif 000008