JP2013172273A

JP2013172273A - ハンドオーバ処理システム、及びゲートウェイルータ

Info

Publication number: JP2013172273A
Application number: JP2012034529A
Authority: JP
Inventors: Kenichi Kawamura; 憲一河村; Hisashi Kojima; 久史小島; Ichiro Inoue; 一郎井上
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-02-20
Filing date: 2012-02-20
Publication date: 2013-09-02
Anticipated expiration: 2032-02-20
Also published as: JP5655018B2

Abstract

【課題】ＬＩＳＰを利用して、ユーザ端末が異種ＮＷ間やＩＳＰ間を跨ぐハンドオーバを実現する。
【解決手段】ＬＩＳＰによるデータ転送機能を備えたゲートウェイルータと、端末ＩＤとサイト情報とを対応付けたマッピング情報を格納するマップサーバとを備えるハンドオーバ処理システムにおいて、前記ゲートウェイルータに、ユーザ端末が、当該ゲートウェイルータに接続されるネットワークに接続したときに、当該ユーザ端末の端末ＩＤを取得し、当該端末ＩＤを前記マップサーバに送信することにより問い合わせを行い、前記マップサーバからＩＰアドレスを受信し、当該ＩＰアドレスを前記ユーザ端末に通知する手段と、前記マップサーバにおいてマッピング情報の更新がなされたときに、更新されたマッピング情報を前記マップサーバから受信する手段と、前記マッピング情報における転送先のサイト情報に基づいて、データ転送を行う手段とを備える。
【選択図】図１

Description

本発明は、異なるＩＳＰ間、ネットワーク間で、ユーザ端末が通信を維持しつつハンドオーバを行う技術に関するものである。

将来のネットワークを考える上で、ユーザが、端末をどのようなネットワークに接続しても通信が継続する、シームレスなハンドオーバの実現が重要である。無線通信のリソース逼迫等により、今後のネットワークは異種ネットワークを切り替えて使用するヘテロジニアスな環境となることが予想されるからである。この場合、ＩＳＰ（インターネットサービスプロバイダ）の枠組みや、キャリアの枠組みを超えて、シームレスなハンドオーバが望ましい。例えば、移動通信事業者の３Ｇを使いながら、ＷｉＭＡＸにハンドオーバし、ホテルが提供している無料ＷｉＦｉにハンドオーバするなどである。

ＩＳＰを跨いだシームレスハンドオーバの実現には、ＭｏｂｉｌｅＩＰ等でＩＳＰ跨ぎのモビリティを与える必要がある。モビリティの技術として、従来の技術の代表的なものとしては、ＭｏｂｉｌｅＩＰｖ６（非特許文献１）、ＰＭＩＰｖ６（非特許文献２）がある。ＭｏｂｉｌｅＩＰｖ６は、ＨｏｍｅＡｇｅｎｔ（ＨＡ）がアンカーポイントとなり、ホームアドレスと、気付けアドレスとの変換を行うことで、モビリティを実現する。ＨＡへの気付けアドレスの更新処理は端末主導で行う考え方である。また、ＰＭＩＰｖ６はＭｏｂｉｌｅＩＰｖ６が端末主導の制御を行うのに対して、ネットワーク側にモビリティ機能を持たせたものである。アンカーポイントとしてＬＭＡを定義し、ＭＡＧとの間でトンネルを張る。端末の移動に合わせて、ＭＡＧは変わるが、ＬＭＡへのトンネルを張り替えることで、ＮＷでのモビリティ管理を実現している。ＰＭＩＰｖ６においてもアンカーポイントとなるＬＭＡへトンネルを張る必要があるため、トラフィックが集中し、また、多数のユーザの収容にはトンネルの管理が必要であり、スケーラビリティに問題がある。

このような状況の中、最近では、Ｌｏｃａｔｏｒ／ＩＤを分離したＬＩＳＰ（Ｌｏｃａｔｏｒ／ＩＤＳｅｐａｒａｔｉｏｎＰｒｏｔｏｃｏｌ）（非特許文献３）が注目されている。現在のＩＰアドレスによるルーティングは、端末のＩＤと存在する場所の２つの意味を一つのＩＰアドレスが示すが、ＬＩＳＰは、端末に付与されたＩＤと、その端末が存在する場所（サイト）を示すＬｏｃａｔｏｒを分離し、両者の対応関係を適切に設定することで、端末とサイト間のシームレスな通信を実現する技術である。ＬＩＳＰは当初は現行ネットワークでのルーティングテーブルの増大に対しての対処方法として考案されたが、ＬＩＳＰの可能性に着目して、モビリティに活用することが検討されている。ＩＥＴＦでは、ＬＩＳＰ−ＭＮ（ＭｏｂｉｌｅＮｏｄｅ）（非特許文献４）において、ドラフトを作成中であり、ＬＩＳＰを用いたハンドオーバについて規定を進めている。このＬＩＳＰをＩＳＰ間のハンドオーバに活用することを考えると、トンネルを張る方式に比べて、ステートレスで、アンカーポイントにトラフィックが集中せず、モビリティ機能を与えることができる可能性がある。

このように、ＬＩＳＰ−ＭＮではＬＩＳＰをモビリティに使用する検討がなされているが、ＬＩＳＰ−ＭＮの課題としては、Ｌｏｃａｔｏｒの更新に、端末側からマップサーバへの更新を行うことがある。端末はあらかじめＬＩＳＰネットワーク中のマップサーバの宛先を知っている必要があり、マップサーバへの登録、削除手順など、端末側にモビリティ機能のための実装が必要となる。端末側にモビリティ機能の制御を持たせると、ネットワーク側の実装に拡張、仕様変更が生じた際に、端末側の変更が必要となり不便であり、また、それまでモビリティ機能を持っていなかった新規ＮＷを収容する場合にも、そのＮＷの既存端末にすべて制御を実装する必要がある。このため、モビリティ機能を可能な限りネットワーク側で与えるようにすることが課題である。

ＬＩＰＳを用いたネットワークベースのモビリティ管理については、ＭｏｂｉｌｅＩＤという独自ＩＤを定義して、モビリティを管理することが提案されている。（非特許文献５）

"Mobility Support in IPv6," RFC 3775, http://tools.ietf.org/html/rfc3775（２０１１年１１月３０日検索） "Proxy Mobile IP v6," RFC 5213, http://tools.ietf.org/html/rfc5213（２０１１年１１月３０日検索） "Locator/ID Separation Protocol (LISP)," IETF draft, http://tools.ietf.org/html/draft-ietf-lisp-16（２０１１年１１月３０日検索） "LISP Mobile Node," IETF draft, http://tools.ietf.org/html/draft-meyer-lisp-mn-06（２０１１年１１月３０日検索） Ping Dong, Jia Chen, and Hongke Zhang, "A network-based localized mobility approach for Locator/ID separation protocol", IEICE TANS. COMMUN., Vol.E94-B, No.6, June 2011

非特許文献５によりＬＩＳＰをネットワーク側で制御する概念は示されているが、実際のインターネットにおいて、ＩＳＰ間でのハンドオーバを実現するための実装方法については明確な手法はなく、課題である。

特に非特許文献５の方式では、独自のＭｏｂｉｌｅＩＤの端末への実装が必要であるという課題がある。また、ＩＳＰ間でのハンドオーバに適用する場合、実際のＩＳＰではモビリティを使用する端末と使用しない端末が混在しその共存が課題である。ＭｏｂｉｌｅＩＤを用いた場合、従来のＩＰによる接続方法の端末との共存が問題となる。また、端末の視点からも、ＭｏｂｉｌｅＩＤを用いた接続方法と従来の接続方法の両方のＩＳＰが存在し、方式を意識して接続を切り換える必要があり、課題である。

本発明は上記の課題に鑑みてなされたものであり、ＬＩＳＰを利用して、ユーザ端末が異種ＮＷ間やＩＳＰ間を跨ぐハンドオーバを実現する技術を提供することを目的とする。

上記の課題を解決するために、本発明は、端末IDとサイト情報を分離して、サイト情報に基づいてルーティングを行うデータ転送機能を備えた第１及び第２のゲートウェイルータを含む複数のゲートウェイルータと、
端末ＩＤとサイト情報とを対応付けたマッピング情報を格納するマップサーバと、を備えるハンドオーバ処理システムであって、
ユーザ端末が、第１の通信インタフェースにより、前記第１のゲートウェイルータに接続される第１のネットワークに接続したときに、前記第１のゲートウェイルータが、当該ユーザ端末の端末ＩＤを取得し、当該端末ＩＤを前記マップサーバに送信することにより問い合わせを行い、
前記マップサーバが、前記端末ＩＤに対するＩＰアドレスを前記第１のゲートウェイルータに通知するとともに、当該端末ＩＤと、転送先サイト情報としての前記第１のゲートウェイルータとを対応付けたマッピング情報を前記複数のゲートウェイルータに通知し、
前記第１のゲートウェイルータは、前記ＩＰアドレスを前記ユーザ端末に通知することにより、当該ユーザ端末の前記第１の通信インタフェースによるＩＰ通信を可能とし、
前記ユーザ端末が、第２の通信インタフェースにより、前記第２のゲートウェイルータに接続される第２のネットワークに接続したときに、前記第２のゲートウェイルータが、当該ユーザ端末の端末ＩＤを取得し、当該端末ＩＤを前記マップサーバに送信することにより問い合わせを行い、
前記マップサーバが、前記ＩＰアドレスを前記第２のゲートウェイルータに通知するとともに、前記端末ＩＤと、転送先サイト情報としての前記第２のゲートウェイルータとを対応付けた更新マッピング情報を前記複数のゲートウェイルータに通知し、
前記第２のゲートウェイルータは、前記ＩＰアドレスを前記ユーザ端末に通知することにより、当該ユーザ端末の前記第２の通信インタフェースによるＩＰ通信を可能とすることを特徴とするハンドオーバ処理システムとして構成される。

前記マップサーバに格納されるマッピング情報は、各端末ＩＤについてのサイト毎の契約情報を含み、前記ユーザ端末の接続時に、前記第１のゲートウェイルータは、既に保持しているマッピング情報を参照することにより、当該ユーザ端末がモビリティ機能を使用するか否かを判断し、使用すると判断した場合に、前記マップサーバへの問い合わせを行い、使用しないと判断した場合に、前記ユーザ端末に対し、前記データ転送機能を用いないインターネット接続を行わせるようにしてもよい。

前記マップサーバは、前記第２のゲートウェイルータから問い合わせを受けた際に、前記第２のゲートウェイルータを転送先とするか否かを、前記ユーザ端末の通信インタフェース間の所定の優先順位に基づいて決定するようにしてもよい。

また、本発明は、端末IDとサイト情報を分離して、サイト情報に基づいてルーティングを行うデータ転送機能を備えたゲートウェイルータと、端末ＩＤとサイト情報とを対応付けたマッピング情報を格納するマップサーバとを備えるハンドオーバ処理システムにおける前記ゲートウェイルータであって、
ユーザ端末が、当該ゲートウェイルータに接続されるネットワークに接続したときに、当該ユーザ端末の端末ＩＤを取得し、当該端末ＩＤを前記マップサーバに送信することにより問い合わせを行い、前記マップサーバからＩＰアドレスを受信し、当該ＩＰアドレスを前記ユーザ端末に通知する手段と、
前記マップサーバにおいてマッピング情報の更新がなされたときに、更新されたマッピング情報を前記マップサーバから受信する手段と、
前記マッピング情報における転送先のサイト情報に基づいて、データ転送を行う手段とを備えることを特徴とするゲートウェイルータとして構成してもよい。

本発明によれば、ＬＩＳＰを利用して、ユーザ端末が異種ＮＷ間やＩＳＰ間を跨ぐハンドオーバを実現する技術を提供することが可能となる。

すなわち、本発明により、ＬＩＳＰの特徴である特定のアンカーポイントでの集中的なルーティング管理ではないメリットを生かしつつ、端末の移動に伴うモビリティの更新を、ネットワーク側装置により処理することを実現し、異種ＮＷやＩＳＰを跨いだ際にシームレスにユーザの通信が継続する仕組みを実現できる。また、端末に特別なＭｏｂｉｌｅＩＤのようなものを使用せず、ＩＰアドレスベースで実現できる。

本発明の実施の形態におけるシステム構成図である。ゲートウェイルータの機能構成図である。マップサーバの機能構成図である。マップサーバにおける管理テーブルを示す図である。ハンドオーバ時のシステムの動作を示すシーケンス図である。ゲートウェイルータの接続時動作を示すフローチャートである。ゲートウェイルータの切断時動作を示すフローチャートである。ハンドオーバ時のトラフィックの流れの例を示す図である。単一ＩＳＰへの適用例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

＜実施の形態の概要＞
本実施の形態に係る技術は、ＬＩＳＰにおけるネットワーク側からのＩＳＰ間ハンドオーバの具体的な実現方法である。

すなわち、各ＩＳＰに設置されたゲートウェイルータ等の装置において、通常のＬＩＳＰのＴＲ（Tunnel Router）の機能以外に、次の機能を具備する：（１）端末がモビリティ機能を利用するかの判断；（２）マップサーバへの登録／削除；（３）端末へのＩＰアドレスの通知。

端末は、例えば各ＩＳＰへの接続時、認証を行うことが想定される。その認証時にゲートウェイルータは、端末（もしくはユーザ契約）のＩＤを特定する。ゲートウェイルータはあらかじめ保持している端末ＩＤ、契約情報のデータベースから、該当する端末がモビリティ機能を利用するかどうかを判断する。モビリティ機能を利用しない端末である場合、そのままインターネット接続を提供する。モビリティ機能を利用する端末であった場合、必要ならＩＰアドレスの割り当てを行い、この端末に関する送受信のパケットについては、ＴＲを利用してのルーティングを行う。

端末に対してＩＰアドレスを割り当てる場合は、ゲートウェイルータは、ＬＩＳＰで構成されたＬｏｃａｔｏｒ／ＩＤ分離方式のネットワークの中で、マップサーバとの間で端末ＩＤと、端末のＩＰアドレスの対応をとり、端末にＩＰアドレスの通知を行う。このＩＰアドレスは端末ＩＤと結びつけられたアドレスであり、同一の端末ＩＤの異なるインタフェースであっても同じＩＰアドレスとなる。マップサーバは端末ＩＤとＩＰアドレスの対応を管理し、ＩＰアドレスの払い出しを行い、また、複数あるアクティブなゲートウェイルータとの接続のうち、どれを優先的に使用するかを判断し、各ゲートウェイルータにマッピング情報を通知する。端末に払い出すＩＰアドレスは、各ＩＳＰで管理されているＩＰアドレス空間から、ＩＳＰを跨いだハンドオーバに使用するアドレスをあらかじめＩＳＰとの協議により決定し、格納、管理するものである。

端末からは各インタフェースでネットワークに接続した際に、自動的に同一ＩＰアドレスが振られ、ハンドオーバ後もそのＩＰアドレス宛てにネットワーク側が通信データを転送するため、通信を継続しつつハンドオーバを実現できる。また、端末は接続しているＩＳＰがモビリティを提供できないものであった場合はＩＰアドレスが変わるが、通常の接続手順で実現されており、動作の切り換えを意識する必要がない。

＜システム構成＞
以下、本実施の形態をより詳細に説明する。まず、本実施の形態のシステム構成例を図１に示す。

図１に示すように、本実施の形態に係るシステムでは、インターネット１１７への接続を提供するＩＳＰ１（１１４）、ＩＳＰ２（１１５）に、それぞれゲートウェイルータ１０１（ＧＷ１とも称する）、１１８（ＧＷ２とも称する）が設置されている。ゲートウェイルータ１０１、１１８はそれぞれ通常のＬＩＳＰのＴＲ（Tunnel Router）機能を備える。また、ゲートウェイルータ１０１、１１８は後述する本発明に係る機能を備えている。

ＩＳＰ１（１１４）、ＩＳＰ２（１１５）はそれぞれネットワーク１０４（ＮＷ１）、ネットワーク（ＮＷ２）に接続され、ユーザ端末１０６（図では"ＵＥ"と表記）はそれぞれのＩＳＰ／ＮＷに対応した複数のインタフェース１０５（ＩＦ１）、１０７（ＩＦ２）を備える。ここでは２つの場合を例にとって説明するが、この数に制限はない。ユーザ端末１０６は、該当するインタフェースからＮＷ１、２のゲートウェイ１０８、１１２を介してＩＳＰ１、２と通信を行う。

ＩＳＰ１（１１４）とＩＳＰ２（１１５）間の接続としては、ＩＸ１１６（Internet eXchange）などを利用し、ゲートウェイルータ１０１とゲートウェイルータ１１８間はＬＩＳＰネットワーク１０３を構築し、そのネットワーク内にマップサーバ１０２を設置する。本実施の形態はこのようなネットワーク構成の中で、ユーザ端末１０６が例えばＩＳＰ１（１１４）からＩＳＰ２（１１５）に、それぞれの通信ＩＦ１、ＩＦ２（１０５、１０７）を使用してハンドオーバする状況を想定するものである。

本発明に係る機能を有する装置は、各ＩＳＰに置かれたゲートウェイルータ１０１、１１８、及び、マップサーバ１０２である。以下、これらの装置の機能構成を説明する。

図２にゲートウェイルータ１０１の機能構成を示す。ゲートウェイルータ１１８も同様の構成を有することから、ここでは代表としてゲートウェイルータ１０１について説明する。

図２に示すように、ゲートウェイルータ１０１は、端末ＩＤ判断機能部２０１、マッピング情報格納機能部２０３、ＩＰアドレス取得機能部２０４、ＩＰアドレス通知機能部２０５、ＬＩＳＰ−ＴＲ機能部２０６、インターネット接続機能部２０２を備える。なお、図２に示す機能構成は、本実施の形態に関わる主な機能を示すものであり、実際には、ルータとしての動作を実現するための図示しない既存の機能を含む。マッピング情報格納機能部２０３は、マップサーバ１０２から送信されるマッピングテーブルを記憶する記憶手段を備える。上記各機能部の動作については後の動作説明のところで説明される。

ゲートウェイルータ１０１は、ＣＰＵ、メモリ等から構成されるコンピュータを含むルータに、本実施の形態で説明する処理に対応したプログラムを実行させることにより実現可能である。すなわち、ゲートウェイルータ１０１の各部が有する機能は、当該ゲートウェイルータ１０１を構成するコンピュータに内蔵されるＣＰＵやメモリなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。また、本実施の形態で説明する処理はハードウェア回路で実現することもできる。

図３にマップサーバ１０２の機能構成を示す。マップサーバ１０２は、端末ＩＤ判断機能部３０１、マッピング情報格納機能部３０３、優先順位計算機能部３０４、ＩＰアドレス通知機能部３０２、マッピング情報通知機能部３０５を備える。なお、図３に示す機能構成は、本実施の形態に関わる主な機能を示すものであり、実際には、サーバとしての動作を実現するための図示しない既存の機能も含む。

マッピング情報格納機能部３０３は、マッピングテーブルを記憶する記憶手段を備える。マッピングテーブルの例を図４に示す。上記各機能部の動作及びマッピングテーブルの内容については以下の動作説明のところで説明される。

マップサーバ１０２は、ＣＰＵ、メモリ、通信インタフェース等から構成されるコンピュータに、本実施の形態で説明する処理に対応したプログラムを実行させることにより実現可能である。すなわち、マップサーバ１０２の各部が有する機能は、当該マップサーバ１０２を構成するコンピュータに内蔵されるＣＰＵやメモリなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

＜システムの動作＞
次に、本実施の形態に係るハンドオーバの動作手順を図５のシーケンス図を参照しながら説明する。

ユーザ端末１０６は２つの異なる通信インターフェース（ＩＦ１、ＩＦ２）を持ち、それぞれの通信インターフェースでの各ＩＳＰとのインターネット接続の通信を契約しているものとする。

まず、ユーザ端末１０６はＩＦ１（１０５）を用いて、ＮＷ１（１０４）に接続する（ステップＳ１１）。ＮＷ１との物理的な経路確立後、インターネット疎通を行うためにＩＳＰ１（１１４）に接続し、認証およびＩＰアドレスの払い出しを受ける（ステップＳ１２〜ステップＳ１５）。以下では、ステップＳ１２〜ステップＳ１５の動作をより詳細に説明する。ここで、図６は、ゲートウェイルータ１０１における端末接続時の処理動作を示すフローチャートであり、以下での処理動作のうちゲートウェイルータ１０１の動作については、図６のフローチャートにおけるステップ番号を適宜参照する。

ゲートウェイルータ１０１がユーザ端末１０６から接続を受ける（図６のステップＳ５０１）。このとき、ユーザ端末１０６からＮＷ１（１０４）のＧＷ１０８を経由して当該ユーザ端末１０６の端末ＩＤが通知され（図５でのステップＳ１２）、ゲートウェイルータ１０１は認証を行う（図６のステップＳ５０２）。

ステップＳ５０２において、端末ＩＤ判断機能部２０１が、ユーザ端末１０６の端末ＩＤを取得し、マッピング情報格納機能部２０３に既に保持しているマッピングテーブルを参照し、取得した端末ＩＤと、マッピングテーブルに登録されている端末ＩＤとを照合する。このマッピングテーブルは、マップサーバ１０２から受信したものであり、契約情報を含む。

なお、端末ＩＤは、端末を一意に区別できるＩＤであり、例えば３Ｇ携帯電話で使用されているＳＩＭカード中のＩＭＳＩや、ハードウェアのＩＭＥＩ、製造番号、ＭＡＣアドレスなどが利用できる。または、固定的に割り当てられているＩＰアドレスを用いてもよい。端末ＩＤを通知するための手段としては、例えば、ＩＰアドレスを取得するためのＤＨＣＰのフレームを拡張するなどの手段がある。

端末ＩＤ判断機能部２０１が、マッピングテーブル上に端末ＩＤのエントリがない、もしくは、契約情報によりモビリティが必要ないと判断した場合（図６のステップＳ５０３でのＮｏ）、インターネット接続機能部２０２により、そのまま、該当ＩＳＰの手続きに基づき、インターネット接続のためのＩＰアドレスの通知を行い、ユーザ端末１０６にインターネットアクセスを許可する（図６のステップＳ５０６）。

端末ＩＤとマッピングテーブル上のエントリとを照合することで、ユーザ端末１０６がモビリティが必要な端末であると判明した場合は（ステップＳ５０３でのＹｅｓ）、ＩＰアドレス取得機能部２０４により、予め知っているマップサーバ１０２に対して、端末ＩＤを通知して、問い合わせ、登録を行う（図６でのステップＳ５０４、図５でのステップＳ１３）。

端末ＩＤを含む問い合わせを受信したマップサーバ１０２において、端末ＩＤ判断機能部３０１は、マッピング情報格納機能部３０３に格納されているマッピングテーブルを参照し、端末ＩＤに対するＩＰアドレスを確定する。

本実施の形態に係るマッピングテーブルの例が図４に示される。図４に示すように、マッピングテーブルには、端末ＩＤ４０１、ＩＰアドレス４０２、現在のルーティング先のＩＳＰを示す現在のＧＷ４０３、端末の各ＩＳＰの状態４０４が格納される。

本実施の形態において、ＩＳＰの状態４０４の値としては、active、disable、N/Aの３種類がある。activeは、該当ＩＳＰにおいてモビリティ機能を利用する契約があり、現時点で通信可能であることを示し、disableは、契約があるが、現時点で通信不可であることを示し、N/Aは契約がないことを示す。例えば、あるユーザ端末があるＩＳＰとモビリティ契約を行った際に、当該ユーザ端末についての当該ＩＳＰの欄の値にdisableが記録され、ＩＰアドレスが払い出されたときにactiveが記録される。現在のルーティング先であるＧＷ４０３については、問い合わせ元から判別でき、記録される。

上記のＩＰアドレスは端末ＩＤに対して、一意に対応するものである。マップサーバ１０２におけるＩＰアドレスの割り当ては、端末が最初のＩＦで接続した場合に、あらかじめ用意され記憶手段に格納されたＩＰアドレスのストックから一つを選択して割り当てる。端末のハンドオーバ時には同じＩＰアドレスを割り当てるが、一定期間どのＩＦでも接続がなかった場合、再度接続時には別のＩＰアドレスを選択し直すこととしてもよい。また、同一端末ＩＤの端末に対しては常に同一ＩＰアドレスを選択するようにしてもよい。

マップサーバ１０２のＩＰアドレス通知機能部３０２は、決定されたＩＰアドレスをゲートウェイルータ１０１に回答する（図５のステップＳ１４）とともに、マッピング情報格納機能部３０３のマッピングテーブルを更新する。ここで更新される情報は、例えば、該当端末ＩＤについてのＩＰアドレス、現在のＧＷ、状態（disable→able)である。更新したマッピングテーブルは、マッピング情報通知機能部３０５から、各ＩＳＰのすべてのゲートウェイルータに通知される（図５のステップＳ１６、ステップＳ１７）。

通知を受けたゲートウェイルータ１０１では、マッピング情報格納機能部２０３によりマッピングテーブルが更新される。ここで、各ＩＳＰのゲートウェイルータに通知される情報には、少なくとも、図４に示した端末ＩＤ４０１、ＩＰアドレス４０２、転送先となる現在のＧＷ４０３が含まれる。

また、ゲートウェイルータ１０１は、ＩＰアドレス通知機能部２０５により、取得したＩＰアドレスを、該当するユーザ端末１０６のＩＦ１を通じて通知する（ステップＳ１５）。
以上の処理により、ゲートウェイルータ１０１は、ＬＩＳＰＴＲ機能部２０６により、ＴＲ機能によるルーティングを開始し（図６のステップＳ５０５）、ユーザ端末１０６は該当ＩＳＰ１を通じてインターネットアクセスが可能となる（図５のステップＳ１８、Ｓ１９、Ｓ２０、Ｓ２１）。

次に、ユーザ端末１０６は移動や環境の変化などにより、ＩＦ１（１０５）での通信以外に、ＩＦ２（１０７）での接続を行うものとする。すなわち、ＩＦ１（１０５）での接続と同様に、ユーザ端末１０６は、ＩＦ２（１０７）により、ＩＳＰ２（１０７）と接続を行う（ステップＳ２２、Ｓ２３）。

ゲートウェイルータ１１８は、マップサーバ１０２に端末ＩＤを通知して問い合わせを行い（ステップＳ２４）、ＩＰアドレスの払い出しを受ける（ステップＳ２５）。マップサーバ１０２はユーザ端末１０６のＩＦ２（１０７）が接続され有効になったことについて、マッピングテーブル（図４）を更新する。ＩＰアドレスはゲートウェイルータ１１８からユーザ端末１０６に通知される（ステップＳ２６）。これにより、ユーザ端末１０６は、ＩＦ２で上記ＩＰアドレスを用いた通信を行うことができる。

現在の転送先を示すＧＷ４０３について、ＧＷ１（１０１）からＧＷ２（１１８）にするかどうかの判断はマップサーバ１０２の優先順位計算機能部３０４が行う。この優先順位の付け方としては、例えば端末の通信速度や、料金から優先順位付けを行うことができる。ただし、限定的に規定するものではない。

例えば、優先順位計算機能部３０４は、端末の複数あるアクティブなインタフェースのうち、使用するインタフェースの優先順位付けを行う機能として、（１）端末のインタフェースの規格上の最高速度を把握し、最も高速なインタフェース／インタフェース群を優先する機能、（２）端末のインタフェースの通信料金を比較し、最も安価なインタフェース／インタフェース群を優先する機能、（３）端末のインタフェースの消費電力を比較し、最も省電力なインタフェース／インタフェース群を選択する機能、（４）端末のインタフェースの実効速度を比較し、最も高速なインタフェース／インタフェース群を選択する機能、のうちの１つ又は複数を備える。

また、各ゲートウェイルータが、現在のゲートウェイルータの負荷状況（ＣＰＵ負荷）を測定し、マップサーバ１０２に通知し、マップサーバ１０２が、通知された負荷状況に基づいて転送先の切り替え判断を行う機能を備えてもよい。また、各ゲートウェイルータがその下位のネットワークの負荷状況を測定もしくは収集し、マップサーバ１０２に通知し、マップサーバ１０２はその負荷状況に基づいて転送先の切り替え判断を行う機能を備えてもよい。

優先順位計算機能部３０４の判断として、ＧＷ２に転送先を切り替える場合は、マッピングテーブルの現在のＧＷ４０３をＧＷ２に更新し、更新後のマッピングテーブルを各ゲートウェイルータに通知する（ステップＳ２７、Ｓ２８）。

その後、ＩＳＰ１のゲートウェイルータ１０１（ＧＷ１）は、インターネット１１７から該当するユーザ端末１０６のＩＰアドレス宛てのパケットを受信した場合（図５のステップＳ２９）、更新された転送先情報（現在のＧＷ：ＧＷ２）に基づいて、通常のＬＩＳＰのＴＲの機能を使用して、宛先ＩＳＰ２のＴＲ（ＧＷ２）まで転送を行う（ステップＳ３０）。宛先ＩＳＰ２のゲートウェイルータ１１８は、該当するユーザ端末１０６のＩＦ２までパケットをＮＷ２を通じて届ける（ステップＳ３１）。また、ユーザ端末１０６のＩＦ２から送出されたインターネット１１７向けのパケットは、ＩＳＰ２のゲートウェイルータ１１８により、インターネット１１７に送信される（ステップＳ３２、Ｓ３３）。

上記の手順で、ＮＷ１（１０４）からＮＷ２（１１１）へ、異なるＩＳＰ間においてもハンドオーバが実現される。

図７は、ユーザ端末１０６がネットワークから切断される際のゲートウェイルータの動作を示す。図７に示すように、ユーザ端末１０６の転送先となっているゲートウェイルータは、端末切断を検知（ステップＳ６０１）すると、マップサーバ１０２に対して登録削除を要求する（ステップＳ６０２）。これにより、マップサーバ１０２において、当該ユーザ端末１０６に割り当てられていたＩＰアドレスがマップサーバから削除されるとともに、activeがdisable にされる。

＜トラフィックの流れについて＞
ハンドオーバ前後のトラフィックの流れを図８に示す。図８に示すように、ハンドオーバ前はＦ１１に示すフローのようにユーザ端末１０６からＩＦ１を通じてＮＷ１を通り、インターネット１１７と送受信を行う。ＮＷ２へのハンドオーバ後は、Ｆ１３に示すようにＮＷ２を利用し、インターネット１１７との送受信を行う。ハンドオーバ前にＩＳＰ１を使用していたことからそちらに届くパケットについては、ＬＩＳＰの手続きに基づき、ＮＷ２側に転送される。つまり、ゲートウェイルータ１０１が持つマッピングテーブルに記述された転送先の情報であるＧＷ２に基づいて転送が行われる。この転送先の情報は、ロケータ（Locator)であり、ＩＰ網上の場所であるサイトを示す情報であるから、サイト情報と称することができる。

上記の転送経路はＦ１２に示されている。このように、各ＩＳＰでそれぞれ受信したパケットを同一のユーザ端末に届けることが可能である点が、ＬＩＳＰによるネットワーク構築の利点である。

また、本実施の形態に係る技術は、上記の例のように複数のＩＳＰにまたがる場合以外に、一つのＩＳＰ内で、複数のインターネットへの疎通ポイントがある場合においても、同様に使用できる。その場合の構成図を図９に示す。１１４がＩＳＰを示すが、その中に本実施の形態に係るゲートウェイルータ１０１、マップサーバ１０２を配置して、同様の処理を行うことで、同一ＩＳＰ内で異なるＮＷを跨いだシームレスハンドオーバを実現可能である。

＜実施の形態のまとめ、効果について＞
本実施の形態では、各ＩＳＰのゲートウェイルータが、端末ＩＤの認識と、ＬＩＳＰＮＷにおけるマップサーバへの登録、削除を行うとともに、マップサーバが端末ＩＤとＩＰアドレス、端末が接続しているゲートウェイルータを管理し、マッピングテーブルを更新することで、ネットワーク側でのモビリティ制御を実現することを可能とした。

従来、ＬＩＳＰにおいて、通信を継続しつつＩＳＰ間でのハンドオーバを実現しようとすると、ＬＩＳＰ端末からマップサーバのマッピングの更新を行うが、端末主導のハンドオーバとなり、端末側で切替処理を行うための実装が必要であったところ、本実施の形態の技術によれば、モビリティの制御機能をネットワーク側に持たせ、端末実装を軽減することができる。

すなわち、本実施の形態により、ＬＩＳＰの特徴である特定のアンカーポイントでの集中的なルーティング管理ではないメリットを生かしつつ、端末の移動に伴うモビリティの更新を、ネットワーク側装置により処理することを実現し、異種ＮＷやＩＳＰを跨いだ際にシームレスにユーザの通信が継続する仕組みを実現できる。また、端末に特別なＭｏｂｉｌｅＩＤのようなものを使用せず、ＩＰアドレスベースで実現できる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１０１、１１８ゲートウェイルータ
１０２マップサーバ
１０３ＬＩＳＰネットワーク
１０４、１１１ネットワーク
１０５、１０７インタフェース
１０６ユーザ端末
１１７インターネット

Claims

端末IDとサイト情報を分離して、サイト情報に基づいてルーティングを行うデータ転送機能を備えた第１及び第２のゲートウェイルータを含む複数のゲートウェイルータと、
端末ＩＤとサイト情報とを対応付けたマッピング情報を格納するマップサーバと、を備えるハンドオーバ処理システムであって、
ユーザ端末が、第１の通信インタフェースにより、前記第１のゲートウェイルータに接続される第１のネットワークに接続したときに、前記第１のゲートウェイルータが、当該ユーザ端末の端末ＩＤを取得し、当該端末ＩＤを前記マップサーバに送信することにより問い合わせを行い、
前記マップサーバが、前記端末ＩＤに対するＩＰアドレスを前記第１のゲートウェイルータに通知するとともに、当該端末ＩＤと、転送先サイト情報としての前記第１のゲートウェイルータとを対応付けたマッピング情報を前記複数のゲートウェイルータに通知し、
前記第１のゲートウェイルータは、前記ＩＰアドレスを前記ユーザ端末に通知することにより、当該ユーザ端末の前記第１の通信インタフェースによるＩＰ通信を可能とし、
前記ユーザ端末が、第２の通信インタフェースにより、前記第２のゲートウェイルータに接続される第２のネットワークに接続したときに、前記第２のゲートウェイルータが、当該ユーザ端末の端末ＩＤを取得し、当該端末ＩＤを前記マップサーバに送信することにより問い合わせを行い、
前記マップサーバが、前記ＩＰアドレスを前記第２のゲートウェイルータに通知するとともに、前記端末ＩＤと、転送先サイト情報としての前記第２のゲートウェイルータとを対応付けた更新マッピング情報を前記複数のゲートウェイルータに通知し、
前記第２のゲートウェイルータは、前記ＩＰアドレスを前記ユーザ端末に通知することにより、当該ユーザ端末の前記第２の通信インタフェースによるＩＰ通信を可能とする
ことを特徴とするハンドオーバ処理システム。
前記マップサーバに格納されるマッピング情報は、各端末ＩＤについてのサイト毎の契約情報を含み、
前記ユーザ端末の接続時に、前記第１のゲートウェイルータは、既に保持しているマッピング情報を参照することにより、当該ユーザ端末がモビリティ機能を使用するか否かを判断し、使用すると判断した場合に、前記マップサーバへの問い合わせを行い、使用しないと判断した場合に、前記ユーザ端末に対し、前記データ転送機能を用いないインターネット接続を行わせる
ことを特徴とする請求項１に記載のハンドオーバ処理システム。
前記マップサーバは、前記第２のゲートウェイルータから問い合わせを受けた際に、前記第２のゲートウェイルータを転送先とするか否かを、前記ユーザ端末の通信インタフェース間の所定の優先順位に基づいて決定する
ことを特徴とする請求項１又は２に記載のハンドオーバ処理システム。
端末IDとサイト情報を分離して、サイト情報に基づいてルーティングを行うデータ転送機能を備えたゲートウェイルータと、端末ＩＤとサイト情報とを対応付けたマッピング情報を格納するマップサーバとを備えるハンドオーバ処理システムにおける前記ゲートウェイルータであって、
ユーザ端末が、当該ゲートウェイルータに接続されるネットワークに接続したときに、当該ユーザ端末の端末ＩＤを取得し、当該端末ＩＤを前記マップサーバに送信することにより問い合わせを行い、前記マップサーバからＩＰアドレスを受信し、当該ＩＰアドレスを前記ユーザ端末に通知する手段と、
前記マップサーバにおいてマッピング情報の更新がなされたときに、更新されたマッピング情報を前記マップサーバから受信する手段と、
前記マッピング情報における転送先のサイト情報に基づいて、データ転送を行う手段と
を備えることを特徴とするゲートウェイルータ。