JPWO2010092764A1 - ゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末 - Google Patents

ゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末 Download PDF

Info

Publication number
JPWO2010092764A1
JPWO2010092764A1 JP2010550437A JP2010550437A JPWO2010092764A1 JP WO2010092764 A1 JPWO2010092764 A1 JP WO2010092764A1 JP 2010550437 A JP2010550437 A JP 2010550437A JP 2010550437 A JP2010550437 A JP 2010550437A JP WO2010092764 A1 JPWO2010092764 A1 JP WO2010092764A1
Authority
JP
Japan
Prior art keywords
gateway
pgw
mobile terminal
connection
code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2010550437A
Other languages
English (en)
Inventor
隆二 杉崎
隆二 杉崎
池田　新吉
新吉 池田
啓吾 阿相
啓吾 阿相
ゲナディ ベレブ
ゲナディ ベレブ
イェンス バッハマン
イェンス バッハマン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JPWO2010092764A1 publication Critical patent/JPWO2010092764A1/ja
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/17—Selecting a data network PoA [Point of Attachment]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005—Multiple registrations, e.g. multihoming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

複数の通信インタフェースを有する移動端末がアクセスネットワークに接続する際、所望のＰＧＷとは異なるＰＧＷが割り当てられた場合であっても、移動端末が、早期かつ短時間のうちに所望のＰＧＷと接続できるようにする技術が開示され、その技術によれば移動端末（ＵＥ）１がアクセスネットワーク（Ｎ３Ｇアクセス３）でブートストラッピング（ＢＳ）処理を行う際に、所望のＰＧＷ（Ｔ−ＰＧＷ５ｂ）に既に接続されている別の通信インタフェースのアドレス（ホームプレフィクス）を接続先のＰＧＷ（Ｉ−ＰＧＷ５ａ）に通知する。Ｉ−ＰＧＷは、そのアドレスを管理していない場合には、そのアドレスを管理しているＴ−ＰＧＷから移動端末へＢＳ処理が開始されるように処理を行う。また、移動端末は、Ｎ３Ｇアクセスで所望しないＩ−ＰＧＷに接続した場合、Ｉ−ＰＧＷから所望のＴ−ＰＧＷに接続を切り替える際に、Ｉ−ＰＧＷとの間で交換した鍵の再利用を要求する。

Description

本発明は、ＩＰ（Internet Protocol：インターネットプロトコル）を用いた通信を行う通信ノードがＰＧＷ（PDN Gateway）に接続する際に、その接続先を制御するゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末に関し、特にモバイルＩＰｖ６（Mobility support for IPv6：以降、ＭＩＰｖ６と呼ぶ）における移動端末（User Equipment：以降、ＵＥと呼ぶ）が複数の通信インタフェース（Interface：以降、ＩＦと呼ぶ）を保持する環境で、ＵＥの情報を管理するＰＧＷに接続する際に適用されるゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末に関する。
従来、ＭＩＰｖ６はＩＰネットワークにおけるＵＥの移動透過性を確保する技術として知られている（例えば、下記の非特許文献３又は非特許文献４を参照）。図１には、ＭＩＰｖ６を用いた通信ネットワークの構成の一例が図示されている。図１において、ＵＥ１（ＭＩＰｖ６ではモバイルノード：Mobile Node（ＭＮ）とも呼ばれる）と、ＵＥ１の位置情報（気付けアドレス；Care-of Address（ＣｏＡ）とも呼ばれる）を管理するＰＧＷ５（ＭＩＰｖ６用語ではホームエージェント：Home Agent（ＨＡ）とも呼ばれ、後述するＩ−ＰＧＷ５ａ若しくはＴ−ＰＧＷ５ｂに相当）と、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡ（Authentication, authorization and Accounting）サーバ８ａとユーザ情報データサーバであるＨＳＳ（Home Subscriber Server）８ｂ、ＰＧＷ５のＵＲＩ（Universal Resource Identifier）とＩＰアドレスとの組を保持するＤＮＳ（Domain Name System：ドメインネームシステム）サーバ９で構成される。
なお、ＡＡＡサーバ８ａとＨＳＳ８ｂは、物理的又は論理的に同一の装置に実装されるものであってもよく、以降、ＡＡＡサーバ８ａとＨＳＳ８ｂを説明の都合上まとめてＡＡＡ／ＨＳＳ８と呼ぶこともある。また、図１には、ＤＮＳサーバ９の接続形態は明示されていないが、ＤＮＳサーバ９は、コアネットワーク４や各アクセスネットワーク（後述する３ＧＰＰアクセスネットワーク２又はＮｏｎ−３ＧＰＰアクセスネットワーク３）からアクセス可能である。
図１において、ＵＥ１は、ホームリンク上で有効なホームアドレス（Home Address：以降、ＨｏＡと呼ぶ）と、外部リンクである移動先ネットワークで取得したＣｏＡを、バインディングアップデート（Binding Update：以降、ＢＵと呼ぶ）メッセージを用いてＰＧＷ５に通知する。ＰＧＷ５は、通知された両アドレス（ＨｏＡ，ＣｏＡ）の対応関係をバインディングキャッシュ（Binding Cash：以降、ＢＣと呼ぶ）に登録して保持することで、ＵＥ１のＨｏＡ宛てに送られてきたパケットをインターセプトし、対応するＵＥ１のＣｏＡ宛てに転送することが可能になる。ＵＥ１は、定期的あるいはＣｏＡが変更されたときに、ＢＵメッセージを用いてＣｏＡをＰＧＷ５に通知する。これにより、ＵＥ１はホームリンク内外に関係なく、ＵＥ１のＨｏＡ宛てのパケットを常時受信するができるようになる。
ここで、下記の非特許文献１には、移動体通信システムの標準化プロジェクト（3rd Generation Partnership Project：以降、３ＧＰＰと呼ぶ）におけるＰＧＷ５の割り当て方法が開示されている。非特許文献１に開示されている技術によれば、例えば図１において、ＵＥ１は、新たなアクセスネットワークに接続する際、自身を収容するＰＧＷ５を示すＵＲＩを基に、新たなアクセスネットワークにおけるＵＥ１の位置情報を管理するＰＧＷ５のＩＰアドレスをＤＮＳサーバ９から取得する。
このとき、同一あるいは異なる通信インタフェースを介して既にＵＥ１が接続済みのＰＧＷ５（ＵＥ１のバインディングキャッシュエントリを保持しているＰＧＷ５）が存在する状態も起こり得るが、このような状態にもかかわらず、既にＵＥ１が接続済みのＰＧＷ５とは異なるＰＧＷ５がＤＮＳサーバ９によって提示されることがある。こうした場合、例えば、異なる通信インタフェースで受信するデータの同期を取ることが困難になるなど、様々な点において、ＵＥ１が複数のＣｏＡを用いる際に期待される利点が実現されなくなってしまうかもしれないという問題が生じる。
このような問題を解決する方法として、非特許文献１には、ＰＧＷ５の切り替え方法（PDN GW reallocation procedure）が開示されている。非特許文献１に開示されているPDN GW reallocation procedureでは、ＵＥ１は、ＤＮＳサーバ９によって提示された異なるＰＧＷ５への接続をいったん開始するが、その接続処理中にＡＡＡ／ＨＳＳ８が提供する情報に基づいて、既に接続済みのＰＧＷ５のアドレスをネットワーク側からＵＥ１に通知することで、ＵＥ１は、通知されたＰＧＷ５（既に接続済みのＰＧＷ５）に再接続できるようになる。
なお、本明細書では、ＵＥ１が新たなアクセスネットワークに接続する際に、その接続先アクセスネットワークで提示されたＰＧＷ５をＩ−ＰＧＷ（Initial PGW）５ａと呼び、一方、ＵＥ１が新たなアクセスネットワークに接続する前に既に別のアクセスネットワークを通じて接続しているＰＧＷ５をＴ−ＰＧＷ（target PGW）５ｂと呼んで区別を行うことにする。Ｔ−ＰＧＷ５ｂは、ＵＥ１が新たなアクセスネットワークに接続した際に本来ＵＥ１が接続したいＰＧＷ５である。ＵＥ１は、新たなアクセスネットワークに接続した場合においても、その接続先をＴ−ＰＧＷ５ｂとすることで、通信に複数のＣｏＡを利用する場合の利益を享受できるようになる。
非特許文献１に開示されているPDN GW reallocation procedureを使用することで、接続先アクセスネットワークで提示されたＰＧＷ５が異なる場合においても、ＡＡＡ／ＨＳＳ８がＴ−ＰＧＷ５ａを割り当てることで、ＵＥ１は接続先のアクセスネットワークによらずＰＧＷ５を統一することが可能になる。
非特許文献１に開示されているPDN GW reallocation procedureは、ＵＥ１とＰＧＷ５との間のパケット通信を保護するためのセキュリティアソシエーション（Security Association：以降、ＳＡと呼ぶ）を確立するためのブートストラッピング（Bootstrapping：以降、ＢＳと呼ぶ）手順を利用する。なお、ＢＳ手順に関しては、例えば下記の非特許文献２に記述されている。以下、図１２用いて、その詳細な動作について説明する。
図１２は、従来の技術におけるＢＳ手順を説明するためのシーケンス図である。なお、図１２には、図１に図示されているシステム構成における図示されているＢＳ手順の一例が示されている。図１２では、ＵＥ１がＤＮＳサーバ９から提示されたＰＧＷ５とＢＳを実施する。その際に、コアネットワーク４への接続許可を下すＡＡＡサーバ８ａと、存在する場合にはＵＥ１が収容されるＰＧＷ５の識別情報（以降、PGW Identityと呼ぶ）やアクセスポイント名（Access Point Name：以降、ＡＰＮと呼ぶ）などを管理するＨＳＳ８ｂとの間でインタラクションが発生する。
まずＵＥ１は、PGW discovery procedure を実行し、ＰＧＷ５（図１のＩ−ＰＧＷ５ａに相当）のアドレスを取得する（ステップＳ９００１）。この際、もしＵＥ１が既に接続済みのＰＧＷ５（図１のＴ−ＰＧＷ５ｂに相当、図１２には不図示）を介して接続確立されたＰＤＮ（Packet Domain Network、図１２には不図示）のＡＰＮを保持していた場合は、ＤＮＳサーバ９にそのＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスを問い合わせる。具体的には、ＵＥ１は、保持しているＴ−ＰＧＷ５ｂのＡＰＮを問い合わせメッセージに格納し、その問い合わせメッセージをＤＮＳサーバ９に送信する。ＤＮＳサーバ９は、ＵＥ１から送られてきたＡＰＮに基づいてＰＧＷ５を検索してＵＥ１に通知するが、ネットワークの状態（負荷状態、オペレータによる設定、またＤＮＳデータベースが現在のＵＥ１の状態に基づいたダイナミック情報を保有していない、などの様々な理由）によって、ＵＥ１が所望するＴ−ＰＧＷ５ｂのアドレスではなく、異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）のアドレスをＵＥ１に返すことがある。
ＵＥ１は、ＤＮＳサーバ９から受信したＰＧＷ５（ここではＩ−ＰＧＷ５ａに相当）のアドレスに対してＳＡ確立を開始する（IKE_SA_INITシーケンスの起動、ステップＳ９００２）。IKE_SA_INITシーケンスにより、ＵＥ１とＰＧＷ５との間で以降のＢＳ処理に使用する共有鍵を含むＩＫＥ ＳＡ（IKE Security Association）を生成する。次に、ＵＥ１は、生成したＩＫＥ ＳＡを使用して保護したIKE_AUTH RequestメッセージをＰＧＷ５に送信する（ステップＳ９００３）。IKE_AUTH Requestメッセージには、ＵＥ１の識別子（例えば、ＮＡＩ：Network Access Identifier）などが含まれている。ＰＧＷ５は、取得したIKE_AUTH Requestメッセージに記載されたパラメータを基に、ＵＥ１に対する認証要求メッセージ（Authentication-Request/Identity）を生成し、ＡＡＡサーバ８ａに送信する（ステップＳ９００４）。
ＡＡＡサーバ８ａはＨＳＳ８ｂから取得したユーザプロファイル（User Profile）や認証ベクタ（Authentication Vector：ＡＶ）などを基にＵＥ１の認証を行い（ステップＳ９００５）、ＰＧＷ５を介してコアネットワーク４への接続を許可してもよいＵＥ１であるかどうかを判断し、その結果をEAP-Request/AKA-Challengeメッセージを用いてＰＧＷ５に通知する（ステップＳ９００６）。ネットワーク接続可能なＵＥ１であると判断された場合、ステップＳ９００６で送信されるEAP-Request/AKA-Challengeメッセージには、以降ＰＧＷ５とＵＥ１との間で使用するＳＡ確立に必要なチャレンジ情報が含まれている。ＰＧＷ５は、ＡＡＡサーバ８ａから取得したEAP-Request/AKA-Challengeメッセージを含むIKE_AUTH ResponseメッセージをＵＥ１に送信する（ステップＳ９００７）。続けて、ＵＥ１からＡＡＡサーバ８ａに対して、チャレンジ情報に対応するレスポンス情報が送信され（ステップＳ９００８、Ｓ９００９）、ＳＡ確立に必要なマスターキー（ＭＳＫ、鍵又は鍵情報と呼ぶこともある）あるいはその鍵素材（keying material）がＰＧＷ５に配布される（ステップＳ９０１０、Ｓ９０１１）。このＭＳＫを使用して、ＵＥ１とＰＧＷ５との間のＳＡが確立される（ステップＳ９０１２〜１４）。そして、確立されたＳＡを使用して、以降ＵＥ１とＰＧＷ５との間で交換されるＢＵ／ＢＡ（Binding Acknowledgement）が保護される（ステップＳ９０１５〜１７）。
図１２に図示されている動作では、ステップＳ９００６において、ＵＥ１がＢＳを開始したＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）に対して、ＨＳＳ８ｂが異なるＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）をＡＡＡサーバ８ａ経由でＰＧＷ５（Ｉ−ＰＧＷ５ａ）に通知することができる。このときＰＧＷ５（Ｔ−ＰＧＷ５ｂ）は、以降のＵＥ１とのＢＳ処理を完了させ（〜ステップＳ９０１４）、続けてＵＥ１との間で実施するバインディング処理の中で（具体的には、ステップＳ９０１６で送信するＢＡメッセージによって）、ＨＳＳ８ｂから通知を受けたＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）のアドレスをＵＥ１に通知する（ステップＳ９０１６）。このようにして本来接続したいＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスを受けたＵＥ１は、ＰＧＷ５（Ｉ−ＰＧＷ５ａ）とのバインディングを解消するためにライフタイムを０にセットしたＢＵを送信し（ステップＳ９０１７）、通知されたＰＧＷ５（Ｔ−ＰＧＷ５ｂ）に接続するためのＢＳ処理並びにバインディング処理（ＢＵ／ＢＡ交換）を改めて開始する。具体的には、ＵＥ１は、Ｔ−ＰＧＷ５ｂに対して、図１２のステップＳ９００２からの処理を再度実施する。
3GPP TS 23.402 V8.4.0，December 2008 3GPP TS 33.402 V8.2.1，December 2008 Mobility Support in IPv6, RFC3775，June 2004 Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)，draft-ietf-mext-nemo-v4traversal-06，November 2008 Proxy Mobile IPv6，RFC5213，August 2008 Mobile IPv6 Bootstrapping in Split Scenario，RFC5026，October 2007 Internet Key Exchange (IKEv2) Protocol，RFC4306，December 2005 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method, RFC5106, January 2008
しかしながら、上記従来の技術においては、ＵＥ１が既に接続済みのＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）と最終的に接続を完了するまでに、多大な時間を要する。これは、暗号認証鍵の生成処理に多大な時間を要するＢＳ処理を、本来接続を意図しないＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）との間で実施しなければならないことに起因するものである。
また、従来の技術においては、多大な時間を要するほかに、ＵＥ１が既に接続済みのＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）と最終的に接続を完了するまでに、多大なメッセージ数を要する。これは、本来接続を意図しないＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）が、ＵＥ１に本来接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスを取得してから、ＵＥ１に送信するまでに多大な数のメッセージのやりとりをしていることに起因するものである。これにより、本来接続を意図しないＰＧＷ５（Ｉ−ＰＧＷ５ａ）とやりとりしたメッセージが無駄になってしまい、無駄になったメッセージ分だけネットワークに負荷をかけてしまうことになる。
上記問題に鑑み、本発明では、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）が割り当てられた場合であっても、ＵＥが、システム内のリソース消費を抑えながら、かつ短時間で所望のＰＧＷ５への接続切り替えを行えるようにするゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末を提供することを目的とする。
上記の目的を達成するため、本発明のゲートウェイ接続方法は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムにおいて、前記移動端末を所望のゲートウェイに接続させるためのゲートウェイ接続方法であって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出するステップと、
前記移動端末が、前記検出ステップの結果をうけて、前記第２のゲートウェイに前記移動端末の収容状況を問い合わせるステップと、
前記第２のゲートウェイが、前記移動端末の収容状況を確認するステップと、
前記第２のゲートウェイが、前記移動端末を収容していないと判断した場合に、前記第１のゲートウェイに接続指示を送信するステップと、
前記第２のゲートウェイが、前記移動端末に待機指示を送信するステップと、
前記第１のゲートウェイが、前記移動端末に接続処理を開始するステップとを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷ５と短い時間で接続を確立させることができるようになる。
また、上記の目的を達成するため、本発明のゲートウェイ接続制御システムは、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなるゲートウェイ接続制御システムであって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出し、
前記移動端末が、前記検出ステップの結果をうけて、前記第２のゲートウェイに前記移動端末の収容状況を問い合わせ、
前記第２のゲートウェイが、前記移動端末の収容状況を確認し、
前記第２のゲートウェイが、前記移動端末を収容していないと判断した場合に、前記第１のゲートウェイに接続指示を送信し、
前記第２のゲートウェイが、前記移動端末に待機指示を送信し、
前記第１のゲートウェイが、前記移動端末に接続処理を開始することによって、
前記移動端末を所望のゲートウェイに接続させるよう構成されている。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷ５が移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷと短い時間で接続を確立させることができるようになる。
また、上記の目的を達成するため、本発明の移動端末は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末であり、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムに接続する際に、前記複数のゲートウェイのうちの所望のゲートウェイに接続することが可能な移動端末であって、
ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイアドレスを取得したことを検出する手段と、
検出された前記第２のゲートウェイに前記移動端末の収容状況を問い合わせる手段と、
前記第２のゲートウェイによって前記移動端末の収容状況が確認され、前記第２のゲートウェイが前記移動端末を収容していないと判断された場合に、待機指示を前記第２のゲートウェイから受信する手段と、
前記第２のゲートウェイによって前記移動端末の収容状況が確認され、前記第２のゲートウェイが前記移動端末を収容していないと判断された場合に、前記第２のゲートウェイから前記第１のゲートウェイに接続指示が送信され、前記第１のゲートウェイが前記接続指示に基づいて開始した前記移動端末との間の接続処理を行う手段とを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷ５が移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷと短い時間で接続を確立させることができるようになる。
また、上記の目的を達成するため、本発明のゲートウェイ接続方法は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムにおいて、前記移動端末を所望のゲートウェイに接続させるためのゲートウェイ接続方法であって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出するステップと、
前記移動端末が、前記検出ステップの結果をうけて前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換するステップと、
前記鍵情報の交換完了後、前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知するステップと、
前記移動端末が、前記第１のゲートウェイへの接続処理を開始するステップと、
前記第１のゲートウェイが、前記相互認証によって作成された前記鍵情報を前記認証サーバから取得するステップと、
前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するステップとを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
また、上記の目的を達成するため、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなるゲートウェイ接続制御システムであって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出し、
前記移動端末が、前記検出ステップの結果をうけて前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換し、
前記鍵情報の交換完了後、前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知し、
前記移動端末が、前記第１のゲートウェイへの接続処理を開始し、
前記第１のゲートウェイが、前記相互認証によって作成された前記鍵情報を前記認証サーバから取得し、
前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するよう構成されている。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
また、上記の目的を達成するため、本発明の移動端末は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末であり、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムに接続する際に、前記複数のゲートウェイのうちの所望のゲートウェイに接続することが可能な移動端末であって、
ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイアドレスを取得したことを検出する手段と、
前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換する手段と、
前記鍵情報の交換完了後、前記第２のゲートウェイから前記第１のゲートウェイのアドレスを受信し、前記第１のゲートウェイへの接続処理を開始する手段と、
前記相互認証によって作成された前記鍵情報を再利用して、前記鍵情報を前記認証サーバから取得した前記第１のゲートウェイへ接続する手段とを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
本発明によれば、複数のＣｏＡを使用している移動端末のＣｏＡを管理するＰＧＷを確実かつ迅速に統一できるようになり、その結果、移動端末は、複数のＣｏＡを使用した通信における利益を確実かつ迅速に享受できるようになる。また、本発明によれば、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷと短い時間で接続を確立させることができるようになる。また、本発明によれば、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
本発明の第１〜第４の実施の形態並びに従来の技術に共通する通信システムの構成の一例を示す図 本発明の第１の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するためのシーケンスチャート 本発明の第１〜第４の実施の形態における移動端末（ＵＥ）の構成の一例を示す図 本発明の第１の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第１の実施の形態において、移動端末（ＵＥ）がＰＧＷ（Ｉ−ＰＧＷ）に送信するIKE_AUTH Requestメッセージのフォーマット例を示す図 本発明の第１の実施の形態において、ＰＧＷ（Ｉ−ＰＧＷ）が移動端末（ＵＥ）に送信する応答メッセージであるIKE_AUTH Responseメッセージのフォーマット例を示す図 本発明の第１の実施の形態において、ＰＧＷ（Ｉ−ＰＧＷ）がＡＡＡサーバに送信するHome Prefix確認要求メッセージの一例を示す図 本発明の第１の実施の形態において、ＡＡＡサーバがＰＧＷ（Ｔ−ＰＧＷ）に送信するHome Prefix確認要求返信メッセージの一例を示す図 本発明の第１の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）が移動端末（ＵＥ）に送信する第１のIKE_SA_INITメッセージの一例を示す図 本発明の第１の実施の形態において、移動端末（ＵＥ）がＰＧＷ（Ｔ−ＰＧＷ）に送信する第２のIKE_SA_INITメッセージの一例を示す図 本発明の第１〜第４の実施の形態におけるＰＧＷの構成の一例を示す図 本発明の第１の実施の形態におけるＰＧＷの処理フローの一例を示すフローチャート 本発明の第１〜第４の実施の形態におけるＡＡＡサーバの構成の一例を示す図 本発明の第１の実施の形態におけるＡＡＡサーバの処理フローの一例を示すフローチャート 従来の技術における動作の一例を説明するためのシーケンスチャート 本発明の第２の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するためのシーケンスチャート 本発明の第３の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第１のシーケンスチャート 本発明の第３の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第２のシーケンスチャート 本発明の第３の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第３の実施の形態において、移動端末（ＵＥ）がＰＧＷ（Ｔ−ＰＧＷ）に送信するIKE_AUTH Requestメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）が移動端末（ＵＥ）に送信するIKE_AUTH Responseメッセージのフォーマット例を示す図 本発明の第４の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）が移動端末（ＵＥ）に送信するIKE_AUTH Responseメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）がＡＡＡサーバに送信するAuthentication-Requestメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＡＡＡサーバがＰＧＷ（Ｉ−ＰＧＷ／Ｔ−ＰＧＷ）に送信するAuthentication-Answerメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＡＡＡサーバがＰＧＷ（Ｔ−ＰＧＷ）に送信するBS_Identity通知メッセージのフォーマット例を示す図 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第１のシーケンスチャート 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第２のシーケンスチャート 本発明の第４の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるＰＧＷのＩ−ＰＧＷとしての処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるＰＧＷのＴ−ＰＧＷとしての処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第３のシーケンスチャート 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第４のシーケンスチャート 本発明の第４の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるＰＧＷのＴ−ＰＧＷとしての処理フローの一例を示すフローチャート
以下、図面を参照しながら、本発明の第１〜第４の実施の形態について説明する。まず、図１を参照しながら、本発明の第１〜第４の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１〜第４の実施の形態に共通するシステム構成の一例を示す図である。図１に図示されている通信システムは、少なくとも、ＵＥ１、ＵＥ１が接続するコアネットワーク４、ＵＥ１を収容しＵＥ１のホームプレフィクスやホームアドレス、位置情報（ＣｏＡ）などを管理しているＴ−ＰＧＷ５ｂ、ＵＥ１のコアネットワーク４に対するアクセス認証を行うＡＡＡサーバ８ａ、ＵＥ１が接続しているＴ−ＰＧＷ５ａの識別子（identity）やＡＰＮを管理保存しているＨＳＳ８ｂ、ＵＥ１からの要求に応じてＰＧＷ５のアドレスを提供するＤＮＳサーバ９、３ＧＰＰアクセスネットワーク２（以下、３Ｇアクセス２とも呼ぶ）、Ｎｏｎ−３ＧＰＰ（非３ＧＰＰ）アクセスネットワーク３（以下、Ｎ３Ｇアクセス３とも呼ぶ）を有している。
ＵＥ１は、少なくとも２つ以上の通信インタフェースを持ち、一方は３Ｇアクセス２、もう一方はＮ３Ｇアクセス３に接続することが可能である。なお、複数の通信インタフェーは、同時に３Ｇアクセス２に接続したり、あるいは、Ｎ３Ｇアクセス３に接続したりするものであってもよい。ＵＥ１は、各アクセスネットワーク（３Ｇアクセス２、Ｎ３Ｇアクセス３）を介してコアネットワーク４に接続し、Ｉ−ＰＧＷ５ａ、Ｔ−ＰＧＷ５ｂのいずれにもアタッチすることができる。また、ＵＥ１は、少なくともＮ３Ｇアクセス３を介してＤＮＳサーバ９に接続可能である。ＵＥ１は、３Ｇアクセス２からＤＮＳサーバ９に接続することも可能であるが、Ｎ３Ｇアクセス３経由で接続可能なＤＮＳサーバ９とは異なるＤＮＳサーバ９が３Ｇアクセス２に配備される場合もあり、３Ｇアクセス２経由のＤＮＳ問い合わせとＮ３Ｇアクセス３経由のＤＮＳ問い合わせとでは、必ずしも同一の結果が得られるとは限らない。
また、３Ｇアクセス２には、例えば、サービングＧＷ（Serving GW）やＭＭＥ、ＳＧＳＮ、ＧＧＳＮなどの３ＧＰＰシステムに固有の装置が配備されており、ＵＥ１がＰＧＷ５に接続するための機能をサポートしているが、図１では図示省略する。また、Ｎ３Ｇアクセス３においても、ＵＥ１がＰＧＷ５に接続するために必要となる機能をサポートする通信ノード（ＵＥ１にＣｏＡを配布するアクセスルータやＭＡＧなど）が配備されているが、これらの通信ノードも図１では図示省略する。
上記の構成を有する通信システムにおいて、ＵＥ１は、３Ｇアクセス２とコアネットワーク４を介してＴ−ＰＧＷ５ｂとの接続を確立しているものとする。ここで、３Ｇアクセス２経由の接続においては、例えばＰＭＩＰ（上記の非特許文献５を参照）が使用されるため、ＵＥ１はＴ−ＰＧＷ５ｂのアドレスを知り得ない（非特許文献１を参照）。一方で、ＨＳＳ８ｂにおいては、適正なＵＥ１の接続管理とネットワークの状態管理を目的として、ＵＥ１の識別子と共にＴ−ＰＧＷ５ｂのアドレスをデータベース管理している。
＜第１の実施の形態＞
以下、本発明の第１の実施の形態におけるシステム動作の一例について、図２を用いて詳しく説明する。図２は、本発明の第１の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。図２には、少なくともＵＥ１、ＵＥ１がＮ３Ｇアクセス３にアタッチした際にＤＮＳサーバ９によって提示されるＩ−ＰＧＷ５ａ、ＵＥ１が３Ｇアクセス２経由で接続済みのＴ−ＰＧＷ５ｂ、ＵＥ１のコアネットワーク４に対するアクセス認証処理を実施するＡＡＡサーバ８ａ、ＵＥ１のサブスクリプション情報などを保持管理するＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
ＵＥ１は、新規接続あるいはハンドオーバのためにＮ３Ｇアクセス３にアタッチし、コアネットワーク４を介してＰＧＷ５とＭＩＰｖ６（又は、ＤＳＭＩＰ）により接続することを決定する。まずＵＥ１は、接続先となるＰＧＷ５のアドレスを取得するため、接続先ネットワークＰＤＮの識別子であるＡＰＮや、ＰＧＷ５を識別するためのＨＡ−ＡＰＮなどから、標準的な方法（例えば、上記の非特許文献６などに記載されている方法）により、ホームエージェント名（ＦＱＤＮ：Fully Qualified Domain Name）を構築し、ＤＮＳサーバ９に問い合わせる。ＤＮＳサーバ９は、適切なＰＧＷアドレスをＵＥ１に返信する（ステップＳ３００１：ＰＤＮ ＧＷ探索）。ＵＥ１は取得したＰＧＷアドレス宛に、ＢＳ処理を開始する。具体的には、ステップＳ３００１で取得したＰＧＷアドレスに対してIKE_SA_INIT手順を実施する（ステップＳ３００２：IKE_SA_INIT）。
なお、ここでは、ＵＥ１がステップＳ３００１において、既に接続済みのＴ−ＰＧＷ５ｂとは異なるＩ−ＰＧＷ５ａのアドレスを取得し、ＢＳ処理もＵＥ１とＩ−ＰＧＷ５ａ間で開始されるものとする。
ここでＵＥ１は、既に接続済みのＴ−ＰＧＷ５ｂとの接続を望んでいるが、ＤＮＳサーバ９によって提示されたＰＧＷアドレスがＴ−ＰＧＷ５ｂのものであるかどうかの確認を取ることができない。なぜなら、３Ｇアクセス経由の接続は例えばＰＭＩＰを用いるものであり、ＵＥ１はＴ−ＰＧＷ５ｂのアドレスを知り得ないためである。またＵＥ１は、ＤＮＳによるＰＧＷアドレス取得においては、時折所望のＰＧＷアドレスが得られない場合があることを知っている。さらには、Ｎ３Ｇアクセス３においては、それ以外にＰＧＷアドレス（Ｔ−ＰＧＷ５ｂのアドレス）を取得する手段がないことが明らかであることから、ステップＳ３００２におけるIKE_SA_INITに続けて実施するＩＫＥ認証処理の開始時に、ＢＳ処理を開始しているＰＧＷ５（ここではＩ−ＰＧＷ５ａ）が所望のＰＧＷ５（すなわちＴ−ＰＧＷ５ｂ）であるかどうかの確認を依頼する。
具体的には、ＵＥ１は、ステップＳ３００２のIKE_SA_INIT手順完了後に送信するIKE_AUTＨ Requestメッセージに、ＵＥ１が保持する（３Ｇアクセス２経由の接続時に割り当てられた）ホームプレフィクス（Home Prefix）を付加して送信する（ステップＳ３００３：IKE_AUTH Request）。Ｉ−ＰＧＷ５ａは、IKE_AUTH Requestメッセージを受信すると、そのメッセージからホームプレフィクスを抽出し、自ノード内のバインディングキャッシュに既に登録されているホームプレフィクスであるかどうか（収容状況）を確認する（ステップＳ３００４：収容状況確認）。
図５Ａは、図２のステップＳ３００３においてＵＥ１がＩ−ＰＧＷ５ａに送信するIKE_AUTH Requestメッセージのフォーマット例を示す図である。ＵＥ１は、従来の標準的なIKE_AUTH Requestメッセージ５０１に加えて、Home Prefixフィールド５０２を設け、その中にＵＥ１が保持するホームプレフィクスを挿入することでホームプレフィクスを通知することができる。また、標準的なIKE_AUTH Requestメッセージにおいて、MIP6_HOME_PREFIX属性をセットしたConfiguration Payloadにホームプレフィクスを記載することで、Ｉ−ＰＧＷ５ａにホームプレフィクスを通知してもよい。
また、IKE_AUTH Requestメッセージにホームプレフィクスを付加することが、収容状況の確認依頼を暗示しているが、さらに、IKE_AUTH Requestメッセージにホームプレフィクスを付加するとともに収容状況確認フラグ（図５Ａには不図示）も付加して、Ｉ−ＰＧＷ５ａに対して、明示的に収容状況の確認を依頼してもよい。これにより、Ｉ−ＰＧＷ５ａは確実に自ノードで管理するバインディングキャッシュにおけるＵＥ１の収容状況を確認する処理を行い、より確実な結果をＵＥ１に通知することができる。また、収容状況確認フラグを付加することにより、ＵＥ１を収容するＰＧＷ５は個別のものだが（Ｔ−ＰＧＷ５ａとＩ−ＰＧＷ５ｂ）、各ＰＧＷ５でＵＥ１に配布管理するホームプレフィクスは同一のもの、というオペレーション下においても、同一のＰＧＷ５（Ｔ−ＰＧＷ５ｂ）に接続を統合することができる。
なお、ここでは、ステップＳ３００１において、ＵＥ１が既に接続済みのＴ−ＰＧＷ５ｂとは異なるＩ−ＰＧＷ５ａのアドレスを取得することを前提としているが、ＵＥ１が既に接続済みのＴ−ＰＧＷ５のアドレスを取得する場合も考えられる。この場合には、ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されており、ＵＥ１が接続しているＰＧＷ５がＩ−ＰＧＷ５ａであることになるので（すなわちＩ−ＰＧＷ５ａとＴ−ＰＧＷ５ｂが同一）、引き続き所定のＢＳ処理を実施する。すなわち、図１２のステップＳ９００３のIKE_AUTH Requestメッセージ受信以降の処理を実施する。
ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されていない場合、Ｉ−ＰＧＷ５ａはＵＥ１が接続を所望しているＴ−ＰＧＷ５ｂではないため、Ｉ−ＰＧＷ５ａは、IKE_AUTH Requestメッセージに対する応答メッセージ（例えばIKE_AUTH Responseメッセージなど）に、収容状況結果（判定結果）、本ＢＳの実施を識別するための識別子UE_BS_Identity、動作指示を含めてＵＥ１に送信する（ステップＳ３００５：IKE_AUTH_Response）。判定結果には、ＵＥ１のホームプレフィクスが自ノードのバインディングキャッシュに存在したか否かの収容状況を記載する。UE_BS_Identityは、後述するＴ−ＰＧＷ５ｂからのＢＳ処理を正しく受信するための情報であり、例えばＩ−ＰＧＷ５ａが指定した数値などであるが、その応用については後述する。なお、UE_BS_IdentityとT-PGW_BS_Identityの両BS_Identityを使用せずに、Ｔ−ＰＧＷ５ｂからＵＥ１にIKE_SA_INIT_1メッセージを送信することも可能であり、これによって、Ｉ−ＰＧＷ５ａ、Ｔ−ＰＧＷ５ｂ、ＵＥ１間でUE_BS_IdentityやT-PGW_BS_Identityの転送が不要となり、通信リソースの有効活用を図る方法もある。動作指示には、後述するＴ−ＰＧＷ５ｂからのＢＳ処理が実施されるので本ＢＳが失敗終了しても、再接続や処理完了を行わないよう促す指示子を格納する。
ここでＩ−ＰＧＷ５ａが、３ＧＰＰ規格標準に基づくＧＴＰ（GPRS Tunneling Protocol）にも対応している場合、上記バインディングキャッシュに対する収容状況確認に加えて（あるいはバインディングキャッシュに対する確認は行わずに）、ＧＴＰに基づく管理テーブルを確認してもよい。これにより、ＵＥ１の収容状況をもれなく検出して、誤検出を防ぐことができる。
また、さらには、ＵＥ１とＴ−ＰＧＷ５ｂの３Ｇアクセス経由の接続には、ＰＭＩＰあるいはＧＴＰが用いられていると考えることができる。一方、今回のＮ３Ｇアクセス経由の接続では、ＭＩＰあるいはＤＳＭＩＰが用いられるため、Ｉ−ＰＧＷ５ａに向けてブートストラッピング処理が開始されている。コアネットワーク４の運用形態によっては、ＰＭＩＰあるいはＧＴＰで用いられるＵＥ１の位置管理を行うためのデータベース（例えばＰＭＩＰバインディングキャッシュ）と、ＤＳＭＩＰ／ＭＩＰで用いられる同ＵＥ１の位置管理を行うためのデータベース（例えばＭＩＰバインディングキャッシュ）はそれぞれ個別に管理運用されることも想定される。さらには、それぞれ（ＧＴＰ、ＰＭＩＰ、ＤＳＭＩＰ／ＭＩＰ）の位置管理機能が論理的あるいは物理的に異なる装置で実施されることも想定される。そのような場合、Ｉ−ＰＧＷ５ａは、ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されているかどうかをチェックする際に、ＤＳＭＩＰ／ＭＩＰで用いられる管理データベース（ＭＩＰバインディングキャッシュ）の確認だけではなく、Ｉ−ＰＧＷ５ａが管理する（あるいは、Ｉ−ＰＧＷ５ａの管轄対象である他ノードが管理する、さらにはＩ−ＰＧＷ５ａと同じドメインに配置された他ノードが管理する）ＰＭＩＰバインディングキャッシュや、ＧＴＰ用の位置管理データベースの確認も行うことが望ましい。
図５Ｂは、図２のステップＳ３００５においてＩ−ＰＧＷ５ａがＵＥ１に送信する応答メッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｉ−ＰＧＷ５ａは、従来の標準的なIKE_AUTH Responseメッセージ６０１に加えて、判定結果フィールド６０２、動作指示フィールド６０３、UE_BS_Identityフィールド６０４を設け、それぞれ所定の値をＵＥ１に通知することができる。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加して判定結果を記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。
なお、Ｉ−ＰＧＷ５ａは、標準的なホームプレフィクス割り当て機構に従って、ＵＥ１が要求したものと異なるホームプレフィクスを割り当てることが判明したことを条件に、上記のＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されていない場合と同等の動作を行ってもよい。
本応答メッセージを受信したＵＥ１は、判定結果フィールドを参照してＩ−ＰＧＷ５ａがＵＥ１の所望するＰＧＷ５ではない可能性が高いことを確認するとともに、動作指示フィールドを参照して引き続き所望のＴ−ＰＧＷ５ｂからＢＳ処理が開始されることを確認し、UE_BS_Identityフィールドに記載された値（UE_BS_Identity）を保存する。ここで、本ＢＳが失敗終了と判定された場合でも、後続して所望Ｔ−ＰＧＷ５ｂからのＢＳ処理が開始することが明らかとなったので、他のＰＧＷ５の探索や再接続を行ったり、ＢＳ処理を完了してスリープモードに入ったりしないよう制御する。なお、後にＴ−ＰＧＷ５ｂからのＢＳ処理要求を受信できることが明らかであれば、消費電力削減のためスリープモードに遷移してもよい。また、ＵＥ１は、判定結果からＵＥ１が所望するＰＧＷ５に接続していないことが確認できた時点で、引き続き所望のＴ−ＰＧＷ５ｂからのＢＳ処理が開始されると判断してもよく、これにより動作指示フィールドを省略して、通信帯域の有効活用を図ることができる。
さらにＩ−ＰＧＷ５ａは、Home Prefix確認要求メッセージをＡＡＡサーバ８ａに送信する（ステップＳ３００６：Home Prefix確認要求）。Home Prefix確認要求メッセージには、ＵＥ１のUser ID（ＮＡＩなど）、ホームプレフィクス（Home Prefix）、ＵＥ１に通知したものと同一のUE_BS_Identity、ＵＥアドレス（ＣｏＡ）、転送指示などの情報が少なくとも含まれる。転送指示は、本メッセージを受けてＵＥ１のホームプレフィクスを管理保持するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）が判明した際に、Ｔ−ＰＧＷ５ｂにＵＥ１宛のＢＳ処理を実施させることをＡＡＡサーバ８ａに対して指示するものであり、特にHome Prefix確認要求メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いる場合などに有効である。
なお、Ｉ−ＰＧＷ５ａは、Home Prefix確認要求メッセージをＡＡＡサーバ８ａへ送信することでＴ−ＰＧＷ５ｂにＢＳ指示を送信する以外に、Ｉ−ＰＧＷ５ａがＴ−ＰＧＷ５ｂを含む装置全てにHome Prefix確認要求メッセージをブロードキャストしてもよい。同様に、Ｉ−ＰＧＷ５ａがＴ−ＰＧＷ５ｂのアドレスを知っていた場合や、いくつかＴ−ＰＧＷ５ｂのアドレスに対して見当がついている場合には、Home Prefix確認要求メッセージをユニキャストやマルチキャスト送信してもよい。
なお、Ｉ−ＰＧＷ５ａは、本発明によるIKE_AUTH Responseメッセージ（図２のステップＳ３００５で送信）とHome Prefix確認要求メッセージ（図２のステップＳ３００６で送信）を任意の順番で送信してもよい。すなわち、上記の説明では、IKE_AUTH Responseを先に、Home Prefix確認要求メッセージを後に送信しているが、その逆であってもよく、例えば、ネットワーク遅延に鑑みて送信順序を決定してもよい。例えば、ネットワーク側装置による処理負荷が高いことに鑑みてHome Prefix確認要求を先に送信してもよく、あるいは、Ｔ−ＰＧＷ５ｂからのＢＳ処理がIKE_AUTH Responseより先行してＵＥ１に伝送されてしまわないように、IKE_AUTH Responseを先に送信して、ＵＥ１の状態遷移が正常に動作するように配慮してもよい。
図６Ａは、図２のステップＳ３００６においてＩ−ＰＧＷ５ａがＡＡＡサーバ８ａに送信するHome Prefix確認要求メッセージの一例を示す図である。Ｉ−ＰＧＷ５ａは、宛先アドレスフィールド１００１にＡＡＡサーバ８ａのアドレス、ソースアドレスフィールド１００２に自アドレス、転送指示フィールド１００３に転送を指示する値（例えば“１”やTRUEなど）、Home Prefixフィールド１００４にＵＥ１のホームプレフィクス値、UE_BS_Identityフィールド１００５にＵＥ１に通知したものと同一の UE_BS_Identity値、ＵＥアドレスフィールド１００６にＵＥ１のアドレス（ＣｏＡ）を記載してＡＡＡサーバ８ａに送信する。なお、Home Prefix確認要求メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いてもよい。また、Home Prefix確認要求メッセージに、ＵＥ１のUser IDを含めてもよく、これによりＵＥ１が接続しているＴ−ＰＧＷ５ｂの探索をより確実に行うことができるとともに、ＵＥ１に対して本発明による切り替え処理を実施することの可否をＵＥ１の認証とからめて制御することが可能となり、オペレータにおいては新たな課金対象サービスと捉えることができる。
Home Prefix確認要求メッセージを受信したＡＡＡサーバ８ａは、User ID、Home Prefixなどの識別子を基に、ＵＥ１を収容しているＴ−ＰＧＷ５ｂを検出し、検出したＴ−ＰＧＷ５ｂに対してHome Prefix確認要求返信メッセージを送信する（ステップＳ３００７：Home Prefix確認要求返信）。
Home Prefix確認要求返信メッセージには、少なくともUser ID、ＵＥアドレス、UE_BS_Identity、ＢＳ指示子を記載する。ＵＥアドレスには、Home Prefix確認要求メッセージに記載されていたものと同一のＵＥ１のアドレスを記載する。またＢＳ指示子には、ＵＥアドレスに記載したＵＥ１のアドレスに対してＢＳ処理を開始することをＴ−ＰＧＷ５ｂに指示する値を記載する（例えば“１”やTRUEなど）。
また、図６Ｂは、図２のステップＳ３００７においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するHome Prefix確認要求返信メッセージの一例を示す図である。ＡＡＡサーバ８ａは、宛先アドレスフィールド１１０１にＴ−ＰＧＷ５ｂのアドレス、ソースアドレスフィールド１１０２に自アドレス、ＢＳ指示フィールド１１０３にＢＳ処理開始を指示する値（例えば“１”やTRUEなど）、ＵＥアドレスフィールド１１０４にＵＥ１のアドレス（Home Prefix確認要求メッセージで取得した値をコピー）、UE_BS_Identityフィールド１１０５にHome Prefix確認要求メッセージで取得した値を記載してＴ−ＰＧＷ５ｂに送信する。また、Home Prefix確認要求メッセージに、ＵＥ１のUser IDを含めてもよく、これによりＴ−ＰＧＷ５ｂにおいてＵＥ１の識別をより確実に行うことができる。
なお、ＵＥアドレスには、ＵＥ１が３Ｇアクセス２で取得したアドレス、すなわちホームアドレスあるいはホームプレフィクスを記載してもよい。これは、ＵＥ１が記載するものであってもよいし、Home Prefix確認要求メッセージを受けたとき、あるいはHome Prefix確認要求返信メッセージを送信するときに、ＡＡＡサーバ８ａやＨＳＳ８ｂが記載するものであってもよい。これにより、ＵＥ１が既に接続済みの３Ｇアクセス２経由でより確実に後述するＢＳ処理を開始することができる（例えば、後述するＮＡＴ（Network Address Translation）がＮ３Ｇアクセス３に配備されているような場合に有効）。ここで、ＵＥアドレスとしてホームプレフィクスが記載されていた場合、Ｔ−ＰＧＷ５ｂは、そのホームプレフィクスの所定のアドレスに対してユニキャストやマルチキャスト、あるいはエニキャストでＢＳ処理を開始してもよく、ホームプレフィクス全体にブロードキャストを行ってＢＳ処理を開始してもよい。
なお、Ｉ−ＰＧＷ５ａは、Home Prefix確認要求メッセージをＨＳＳ８ｂに送信してもよい。この場合、ＡＡＡサーバ８ａがＵＥ１の状態をＨＳＳ８ｂから取得する必要がなくなり、処理時間の削減を図ることができる。Home Prefix確認要求メッセージをＨＳＳサーバ８ｂに送信する場合、上記の説明においてＡＡＡサーバ８ａが実施する動作はＨＳＳ８ｂにおいて実施され、Home Prefix確認要求返信メッセージもＨＳＳ８ｂからＴ−ＰＧＷ５ｂに直接あるいは間接ノードを介して転送される。
また、Ｉ−ＰＧＷ５ａは、Home Prefix確認要求メッセージを、Ｉ−ＰＧＷ５ａが送信可能な範囲に送信してもよく、あるいは、所定範囲のＰＧＷ５に対してブロードキャスト送信、マルチキャスト送信、ユニキャスト送信、エニキャスト送信（特にはＵＥ１のホームプレフィクスを基に構築したホームエージェント・エニキャストアドレス宛に送信）のいずれを行ってもよい。これにより、ＡＡＡサーバ８ａやＨＳＳ８ｂ経由のメッセージ転送を削減でき、ＡＡＡサーバ８ａ、ＨＳＳ８ｂの負荷を低減させることができるとともに、特にユニキャスト通信を行う場合は、システム全体としての処理メッセージ数を削減することができる。
Ｉ−ＰＧＷ５ａがＴ−ＰＧＷ５ｂに直接指示を送信する際は、Ｉ−ＰＧＷ５ａが事前にＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂのアドレスを取得する。このとき、ＵＥ１のためのＴ−ＰＧＷ５ｂのアドレス取得であることを理由に、ＡＡＡサーバ８ａにおいてＵＥ１に対する認証処理が実施されるかもしれない。また、直接指示のためのメッセージは、Home Prefix確認要求メッセージであっても、Home Prefix確認要求返信メッセージであってもよい。
このように、Ｉ−ＰＧＷ５ａがＡＡＡサーバ８ａやＨＳＳ８ｂ、あるいは直接Ｔ−ＰＧＷ５ｂにHome Prefix確認要求メッセージ（場合によってはHome Prefix確認要求返信メッセージ）を送信することにより、それ以降、Ｉ−ＰＧＷ５ａはＵＥ１に関する処理を行う必要がなくなる。すなわち、ＵＥ１に関する状態やリソースを開放することが可能となり、直ちに他の端末に対する処理を開始できるようになる。このように、本発明では早期に所望のＰＧＷ５への切り替えを検出、実施可能とできるので、ＰＧＷリソースの有効活用を図ることができる。ちなみに、従来技術においては、図１２のステップＳ９０１７を完了しないと、Ｉ−ＰＧＷ５ａは、Ｉ−ＰＧＷ５ａのリソース並びにＵＥ１に対する状態を解放することができなかった（正確には、ステップＳ９０１７の後で、ＵＥ１とＩ−ＰＧＷ５ａとの間で確立したＳＡを終了させ、解放する必要がある）。
Home Prefix確認要求返信メッセージを受信したＴ−ＰＧＷ５ｂは、User IDなどから自身が収容しているＵＥ１であることを確認し、さらにＢＳ指示子がＵＥ１宛のＢＳ処理を開始する指示であることを確認し、第１のIKE_SA_INITメッセージをＵＥアドレス宛に送信してＢＳ処理を開始する（ステップＳ３００８：IKE_SA_INIT_1）。第１のIKE_SA_INITメッセージには、Ｔ−ＰＧＷ５ｂが生成した本ＢＳの実施を識別するための識別子T-PGW_BS_Identityが少なくとも含まれる。
図７Ａは、図２のステップＳ３００８においてＴ−ＰＧＷ５ｂがＵＥ１に送信する第１のIKE_SA_INITメッセージの一例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_SA_INITメッセージ２００１（InitiatorがResponderに最初に送信するIKE_SA_INITメッセージ）に続けて、Ｔ−ＰＧＷ用ＢＳ識別子フィールド（T-PGW_BS_Identityフィールド）２００２を設け、その中にＴ−ＰＧＷ５ｂが取得した本ＢＳの実施を識別するためのＴ−ＰＧＷ用ＢＳ識別子T-PGW_BS_Identityを少なくとも記載して送信する。
Ｔ−ＰＧＷ５ｂからの第１のIKE_SA_INITメッセージを受信したＵＥ１は、そのメッセージのT-PGW_BS_Identityフィールドの値を確認し、先にＩ−ＰＧＷ５ａから取得したUE_BS_Identity値（ステップＳ３００５で受信したIKE_AUTH_Responseに含まれているUE_BS_Identity）を用いて後述する所定の検証を行い、検証結果が成功であった場合に要求するＴ−ＰＧＷ５ｂからのＢＳ処理要求であることを認識し、応答するIKE_SA_INITメッセージを送信する（ステップＳ３００９：IKE_SA_INIT_2）。このとき、ＵＥ１は、送信するIKE_SA_INITメッセージに、先に取得したUE_BS_Identityを記載して送信する。これにより、本ＢＳ処理のトリガを要求したＵＥ１からの応答であることをＴ−ＰＧＷ５ｂに提示して、正しいノード間でＢＳ処理が実施されていることを確認することができる。
図７Ｂは、図２のステップＳ３００９において、ＵＥ１がＴ−ＰＧＷ５ｂに送信する第２のIKE_SA_INITメッセージの一例を示す図である。ＵＥ１は、従来の標準的なIKE_SA_INIT（ResponderがInitiatorに最初に送信するIKE_SA_INITメッセージ）に続けて、先にＩ−ＰＧＷ５ａから取得した本BSの実施を識別するためのＵＥ用ＢＳ識別子UE_BS_Identityを少なくとも記載して送信する。なお、ステップＳ３００８及びＳ３００９でＵＥ１とＴ−ＰＧＷ５ｂとが交換するIKE_SA_INITメッセージは、各々が送信するBS_Identity（T-PGW_BS_Identity及びUE_BS_Identity）を正しく交換できれば、いずれのIKE_SA_INITメッセージを用いてもよい。
上記BS_Identityを用いて、正しく相互認証あるいは相互確認が取れたことにより、以降のＢＳ処理（IKE_SA_INITの残りとステップＳ３０１０以降の処理）は、従来の標準的な処理を実施することで、ＵＥ１とＴ−ＰＧＷ５ｂとの間のＳＡ確立を達成することができる。
なお、ステップＳ３００８に示すＴ−ＰＧＷ５ｂからのIKE_SA_INIT_1メッセージが受信できない場合のリカバリを容易にすることを目的として、ＵＥ１はＴ−ＰＧＷ５ｂからのIKE_SA_INIT受信待ちタイマをセットしてもよい。タイマは、例えばＵＥ１が本発明によるIKE_AUTH ResponseメッセージをステップＳ３００５において受信したときに所定の値にセットして起動する。タイマ値はＵＥ１が任意に設定してもよく、IKE_AUTH Responseメッセージなどを介してＩ−ＰＧＷ５ａなどのネットワーク装置から指定されてもよい。
次に、UE_BS_IdentityとT-PGW_BS_Identityの使用方法について、詳しく説明する。UE_BS_Identity、T-PGW_BS_Identityとして使用される情報は、例えば、ＵＥ１及びＰＧＷ５によって共有されている値を基に生成されたハッシュ値や、ランダムに生成された値やＩ−ＰＧＷ５ａのアドレスなど、ＵＥ１及びＰＧＷ５によって認識可能な値（符号）であればこれらに限定されない。
図２に図示されているシーケンスでは、UE_BS_IdentityがＩ−ＰＤＷ５ａによって生成され、ＵＥ１へ送信される（図２のステップＳ３００５）とともに、ＡＡＡサーバ８ｂを経由するか、あるいは直接Ｔ−ＰＧＷ５ｂへ送信される（図２のステップＳ３００６）。Ｔ−ＰＧＷ５ｂは、受信したUE_BS_Identityに対応するT-PGW_BS_Identityを生成し、生成されたT-PGW_BS_Identityを含むIKE_SA_INIT_1メッセージをＵＥ１へ送信する（図２のステップＳ３００８）。IKE_SA_INITメッセージを受信したＵＥ１は、あらかじめＩ−ＰＧＷ５ａから取得したUE_BS_Identity（図２のステップＳ３００５で受信したIKE_AUTH Responseに含まれるUE_BS_Identity）に対応するT-PGW_BS_Identityを導出し、Ｔ−ＰＧＷ５ｂから受信したT-PGW_BS_Identity（図２のステップＳ３００８で受信したIKE_SA_INIT_1に含まれるT-PGW_BS_Identity）と比較する。両者を比較した結果が同一であった場合には、ＵＥ１は、Home Prefixを含むIKE_SA_INITメッセージをＩ−ＰＧＷ５ａへ送信した結果行われたＴ−ＰＧＷ５ｂからのＢＳ処理要求であることを認識することが可能となる。なお、UE_BS_Identityに対応するT-PGW_BS_IdentityをＵＥ１が導出する方法としては、UE_BS_Identityから求めたハッシュ値をT-PGW_BS_Identityとして用いてもよいし、UE_BS_IdentityとT-PGW_BS_Identityとの対応関係を示すテーブル情報を用いてもよい。この場合、テーブル情報は、３Ｇネットワーク内の情報サーバなどから取得することもできるし、オペレータによってＵＥ１にあらかじめ設定されていてもよい。また、ＵＥ１は情報サーバに問い合わせることで、UE_BS_Identityに対応するT-PGW_BS_Identityを取得してもよい。ハッシュ関数を用いた場合は、UE_BS_Identity、T-PGW_BS_Identity共に高度な暗号化アルゴリズムを用いているため、セキュリティを高めることができる。
なお、上述の説明では、UE_BS_IdentityがＩ−ＰＧＷ５ａによって生成され、T-PGW_BS_IdentityがＴ−ＰＧＷ５ｂによって生成されているが、例えば、UE_BS_Identity及びT-PGW_BS_Identityが両方共、Ｉ−ＰＧＷ５ａによって生成されてもよい。この場合、Ｉ−ＰＧＷ５ａは、UE_BS_IdentityをＵＥ１へ送信するとともに、そのUE_BS_Identityに対応したT-PGW_BS_IdentityをＡＡＡサーバ８ｂ経由又はあるいは直接Ｔ−ＰＧＷ５ｂへ送信する。Ｔ−ＰＧＷ５ｂは、受信したT-PGW_BS_Identityを含むIKE_SA_INIT_1メッセージをＵＥ１へ送信することで、ＵＥ１が、Ｔ−ＰＧＷ５ｂからのＢＳ処理要求かどうかを確認できるようになる。
また、UE_BS_Identity及び／又はT-PGW_BS_IdentityをＩ−ＰＧＷ５ａ以外の装置、例えばＵＥ１やＴ−ＰＧＷ５ｂ、ＡＡＡ／ＨＳＳ８が生成してもよく、各BS_Identityが異なる装置によって生成されてよい。
また、UE_BS_IdentityとT-PGW_BS_Identityを同じ値にして、ＢＳ処理を実施することも可能である。その場合、ＵＥ１は、あらかじめＩ−ＰＧＷ５ａから取得したBS_Identity（図２のステップＳ３００５で受信したIKE_AUTH Responseに含まれるBS_Identity）を、IKE_SA_INITメッセージから取得したBS_Identity（図２のステップＳ３００８で受信したIKE_SA_INIT_1に含まれるBS_Identity）と比較し、同一であれば、Ｔ−ＰＧＷ５ｂからのＢＳ処理要求であることを認識する。Ｔ−ＰＧＷ５ｂも同様に、ＡＡＡ／ＨＳＳ８から通知されたBS_Identityと、ＵＥ１から通知されたBS_Identityを比較し、同一であれば、所望のＵＥ１からのレスポンスであることを認識する。また、UE_BS_IdentityとT-PGW_BS_Identityの両BS_IdentityをＵＥ１とＴ−ＰＧＷ５ｂに送ることで、ＵＥ１がUE_BS_Identity に対応するT-PGW_BS_Identityを知ることができるが、上述したようにＵＥ１とＰＧＷ５が任意のBS_Identityから共通のBS_Identityを取得できるテーブルを保持しているならば、両BS_Identityを送る必要はない。同様に、ＵＥ１やＰＧＷ５以外の装置が、上記テーブルを保持しており、ＵＥ１とＰＧＷ５がアクセス可能であれば、両BS_Identityを送る必要はない。なお、上記テーブルではなく、オペレータの命令やユーザによる操作によって変更不可能な固定の値を、ＵＥ１やＰＧＷ５とは関係なくＢＳの識別子として設定してもよい。
また、UE_BS_Identity及び／又はT-PGW_BS_Identityの生成方法としては、高度な暗号化アルゴリズム以外に、IKE_SA_INITメッセージで生成した共有鍵の利用や、任意の関数（例えば、ランダム関数など）を用いる方法、既存の値を利用するためにインデックスとして指定する方法が挙げられる。以下に、各使用方法について詳しく説明する。
IKE_SA_INITメッセージで生成した共有鍵の利用する方法を用いた場合、ＵＥ１とＩ−ＰＧＷ５ａとの間で既知な値を共有するため、新たにBS_Identityを生成する必要がない。また、共有鍵をUE_BS_Identityとし、T-PGW_BS_Identityは新たに生成してもよい。このように、生成済みの共有鍵を利用した場合には、新たにBS_Identityを生成する時間が短縮される。
また、任意の関数（例えば、ランダム関数など）を用いて、UE_BS_Identity及び／又はT-PGW_BS_Identityを生成する方法が採用されてもよい。ハッシュ関数などの高度な暗号化アルゴリズムを用いることにより、BS_Identity生成に要する時間が短縮される。
また、既存の値を利用するためにインデックスとして指定する方法を採用する場合には、一例として、UE_BS_Identityに‘Ｈ’を指定して送信すると、ＵＥ１やＴ−ＰＧＷ５ｂなどが、UE_BS_Identityは“HPLMN ID”であると判断できるように仕様を定義しておく。本手法は、BS_Identityを生成しているわけでないので、セキュリティ面は上記案と比べると低いが、実装の容易性、処理時間の面では優れている。
なお、上記した全使用方法はUE_BS_IdentityとT-PGW_BS_Identityの両方に適用する以外に、各BS_Identityで異なる使用方法を用いてもよい。各使用方法で共通して守らなければならないことは、ＵＥ１とＴ−ＰＧＷ５ｂが、両BS_Identityを確認できることである。
なお、ＵＥ１が接続するＮ３Ｇアクセス３において、ＮＡＴ（Network Address Translator）が配備されている場合、Ｔ−ＰＧＷ５ｂから開始されるＢＳ処理の第１のIKE_SA_INITメッセージ（図２のステップＳ３００８におけるIKE_SA_INIT_1メッセージ）がＵＥ１に到達せず、結果的にＴ−ＰＧＷ５ｂとの接続に失敗するという問題が起こり得る。しかしながら、従来のＢＳ処理方法において、ＵＥ１はＢＳ処理の初期段階でＮＡＴの有無を検出することができる（例えば、非特許文献７を参照）。また同様に、Ｉ−ＰＧＷ５ａにおいても同段階においてＮＡＴの有無を検出することができる。したがって、本問題は次の２通りの方法によって解決することができる。
１つ目の方法では、Ｎ３Ｇアクセス３にＮＡＴが配備されていることを検出したＩ−ＰＧＷ５ａは、Home Prefix確認要求メッセージに（例えば転送指示フィールドを利用するなどして）、Ｔ−ＰＧＷ５ｂからのＢＳ処理が３Ｇアクセス２経由で実施されるよう指示を含める。この指示は、Home Prefix確認要求返信メッセージに引き継がれ（例えばＢＳ指示フィールドを利用するなどして）、Ｔ−ＰＧＷ５ｂに転送される。このとき、Ｉ−ＰＧＷ５ａ、ＡＡＡサーバ８ａ、ＨＳＳ８ｂのいずれか（あるいは全てのノード）において、ＵＥアドレスにＵＥ１のホームプレフィクスを記載することにより、上記明示的な指示を不要とすることができ、処理並びにメッセージリソースの有効活用を図ることができる。また、上記明示的な指示を記載しておくことにより、ＵＥアドレスにホームプレフィクスを記載する必要がなくなり、同様にリソースの有効活用を図ることができる。
Ｔ−ＰＧＷ５ｂは、上記指示を受けてあるいはＵＥアドレスに記載されたホームプレフィクス宛にＢＳ処理を開始する。なお、上記明示的な指示を受けたときは、ＵＥアドレスに記載されたアドレスを参照することなく、自身が保持管理しているＵＥ１のホームプレフィクス宛にＢＳ処理を開始する。また、ＵＥ１のホームアドレスが明らかである場合は、ホームアドレスにＢＳ処理を開始してもよい。なお、Ｉ−ＰＧＷ５ａは、ＮＡＴを検出した際に、ＵＥ１に送信するIKE_AUTH Response（図２のステップＳ３００５で送信されるIKE_AUTH Response）の中で、Ｔ−ＰＧＷ５ｂからのＢＳ処理が３Ｇアクセス２経由で来るので待機するよう通知しておいてもよい。これにより、ＵＥ１は、３Ｇアクセス２に接続する通信インタフェースがアイドルモードに遷移している場合は自発的にアクティブモードに遷移させるなどの処理を行って、Ｔ−ＰＧＷ５ｂからのＢＳ処理開始（具体的にはIKE_SA_INITメッセージ）を即座に受信できるよう準備しておくことができ、接続のさらなる高速化を図ることができる。
２つ目の方法では、ＮＡＴが配備されていることを検出したＵＥ１は、IKE_AUTH Request（図２のステップＳ３００３）の中で、Ｉ−ＰＧＷ５ａに３Ｇアクセス２経由のＢＳ処理開始を要求する。これを受けてＩ−ＰＧＷ５ａは、上述の１つ目の方法を実施する。
次に、本発明を実施するための移動端末（ＵＥ１）の構成について説明する。以下、図３を参照しながら、本発明の第１の実施の形態におけるＵＥ１の構成について説明する。図３は、本発明の第１の実施の形態におけるＵＥ１の構成の一例を示す図である。
図３において、ＵＥ１は、アクセスネットワーク（３Ｇアクセス２又はＮ３Ｇアクセス３）とそれぞれ接続して下位レイヤにおける通信処理を行う第１無線通信部１０１及び第２無線通信部１０２、第１及び第２無線通信部１０１、１０２の上位でＩＰなどのパケット通信処理を実施するパケット処理部１０３、ＵＥ１とＰＧＷ５との間のＢＳ（ブートストラップ）処理を実施するＢＳ処理部１０４、ＤＮＳサーバ９への問い合わせメッセージを送信し、その応答として受信した結果から所定のアドレス情報を取得するＤＮＳクライアント処理部１０５、本発明における特徴的な処理を実施する接続制御部１０６、ＤＳＭＩＰやＭＩＰｖ６に基づいてＢＵ／ＢＡ交換などの移動管理処理をＰＧＷ５に対して実施するＭＩＰ処理部１０７を少なくとも有する。なお、第１及び第２無線通信部１０１、１０２は、３Ｇアクセス２、Ｎ３Ｇアクセス３のいずれに接続するものであってもよく、さらには一方の無線通信部（例えば、第１無線通信部１０１）が同時に３Ｇアクセス２とＮ３Ｇアクセス３に接続するものであってもよい。本発明の第１の実施の形態においては、一例として、ＵＥ１が２つの無線通信部を有し、一方の無線通信部（第１無線通信部１０１）が３Ｇアクセス２に、他方の無線通信部（第２無線通信部１０２）がＮ３Ｇアクセス３に接続するものとして説明する。
次に、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図４を用いて詳しく説明する。なお、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２（ホームリンク）に接続済みであり、Ｔ−ＰＧＷ５ｂに接続しているものとする。
図４は、本発明の第１の実施の形態におけるＵＥ１の処理フローの一例を示すフロー図である。本発明による接続制御部１０６は、まずＮ３Ｇアクセス３へのアタッチ（接続）処理を開始するため、第２無線通信部１０２に接続開始を指示する（ステップＳ５００２）。第２無線通信部１０２では、Ｎ３Ｇアクセス３における接続手順に従って、接続処理を実施する。Ｎ３Ｇアクセス３への接続が完了すると、Ｎ３Ｇアクセス３経由で接続するＰＧＷ５のアドレスを探索するため、ＤＮＳクライアント処理部１０５に探索開始を指示する（ステップＳ５００３）。このとき、接続制御部１０６は、接続先となるＰＧＷ５のアドレスを取得するため、接続先ネットワークＰＤＮの識別子であるＡＰＮやＰＧＷ５を識別するためのＨＡ−ＡＰＮなどから、標準的な方法により（例えば、非特許文献６に開示されている方法など）、ホームエージェント名（ＦＱＤＮ）を構築し、ＤＮＳクライアント処理部１０５に通知する。ＤＮＳクライアント処理部１０５では、通知されたホームエージェント名を記載したＤＮＳクエリをパケット処理部１０３、第２無線通信部１０２経由でＤＮＳサーバ９宛に送信する。また、その応答としてＤＮＳ応答を第２無線通信部１０２、パケット処理部１０３経由でＤＮＳサーバ９から受信し、ＤＮＳ応答から取得したＰＧＷアドレスを接続制御部１０６に転送する。
ここで、接続制御部１０６は、既に第１無線通信部１０１経由（３Ｇアクセス２経由）でホームリンクに接続済みであること、ＤＳＭＩＰあるいはＭＩＰｖ６に基づいて異なる接続リンクを確立してＰＧＷ５に接続しようとしていること、さらに接続先のＰＧＷアドレスをＤＮＳにより取得したこと、の３つの条件を満足する状況であるかを判定する（ステップＳ５００４）。いずれか１つの条件でも満たさない場合には、接続制御部１０６は、取得したＰＧＷアドレスに対して標準的なＢＳ処理を開始するようＢＳ処理部１０４に指示する。ＢＳ処理部１０４では、例えば図１２のステップＳ９００２からＳ９０１４に示すような標準的なＢＳ処理を実施し（ステップＳ５０４０）、続けてＰＧＷ５（Ｉ−ＰＧＷ５ａ）とＤＳＭＩＰあるいはＭＩＰｖ６に基づくＢＵ／ＢＡ交換を実施する（ステップＳ５０４１）。
一方、すべての条件を満足する場合、接続制御部１０６は、取得したＰＧＷアドレスに対して本発明に係るＢＳ処理を開始するようＢＳ処理部１０４に指示する。ＢＳ処理部１０４では、ＩＫＥ ＳＡを構築するための手順であるIKE_SA_INIT処理を、接続制御部１０６から通知されたＰＧＷアドレス（Ｉ−ＰＧＷ５ａのアドレス）に対して開始する（ステップＳ５００５）。IKE_SA_INIT処理が完了し、ＩＫＥ ＳＡが確立されると、ＢＳ処理部１０４は、ホームリンクに接続時に取得したホームプレフィクス（Home Prefix）をIKE_AUTH Requestメッセージに記載して送信する（ステップＳ５００６）。これにより、IKE_AUTH Requestメッセージ送信先のＰＧＷ５に対して、自ノードの収容状況を確認させることができ、これから接続しようとしているＰＧＷ５が自身を既に収容しているものであるか、すなわちホームリンク経由で接続済みのＰＧＷ５であるかの確認を取ることができる。
なお、既に従来の標準的なIKE_AUTH Requestメッセージは、ホームプレフィクスを記載するためのフィールドを有しており、本発明においてもそのフィールドを活用することができる。ただし、その場合は、ＰＧＷ５における処理の混乱（従来の標準的なＢＳ処理と本発明によるＢＳ処理を適切に区別して実施できなくなることによる混乱）を避けるため、収容状況の確認を指示するフラグや指示子を明示的に設けてもよい。なお、このようなフラグや指示子は、ホームプレフィクスを記載するフィールドを共有しない場合であっても明示的に設けることができる。
IKE_AUTH RequestメッセージはＢＳ処理部１０４からパケット処理部１０３、第２無線通信部１０２を介してＰＧＷ５宛に送信される。ＰＧＷ５は収容状況を確認した後、その応答としてIKE_AUTH ResponseメッセージをＵＥ１に送信し、IKE_AUTH Responseメッセージは、第２無線通信部１０２、パケット処理部１０３を介してＢＳ処理部１０４に転送される（ステップＳ５００７）。ＢＳ処理部１０４はIKE_AUTH Responseに記載されたパラメータ（少なくとも、判定結果、UE_BS_Identity、動作指示）を接続制御部１０６に通知し、接続制御部１０６において判定結果、動作指示について評価を行う（ステップＳ５００８）。
判定結果が少なくとも失敗を示す値（例えば “０”、FALSEなどの符号）でない場合、接続制御部１０６は、ＢＳ処理部１０４に対して残りのＢＳ処理を従来の標準的なＢＳ手順に基づいて継続実行するよう指示する。ＢＳ処理部１０４は残りのＢＳ処理、すなわち図１２に示すステップＳ９００８からＳ９０１４を実行し（ステップ５０３０）、続けてＰＧＷ５とＤＳＭＩＰあるいはＭＩＰｖ６に基づくＢＵ／ＢＡ交換を実施する（ステップＳ５０３１）。
一方、判定結果が失敗を示す値であり、動作指示が“待機”を示す値（例えば“Wait”などの状態を示す符号）である場合、接続制御部１０６はIKE_AUTH Responseで通知されたUE_BS_Identityに対応するT-PGW_BS_Identityを独自に生成（例えばUE_BS_Identityを元データとしてハッシュ計算を行う、など）するか、あるいはUE_BS_Identityに対応するT-PGW_BS_Identityをデータベースから取得する（ステップＳ５０１０）。
なお、UE_BS_Identity並びにT-PGW_BS_Identityの詳細については、本発明に係る通信システムの説明した際に記載したので、ここでは説明を割愛する。なお、ここではUE_BS_IdentityとT-PGW_BS_Identityの双方が存在し、通信システム並びに移動端末がそれらの存在を前提として動作するものとして説明するが、先述したBS_Identityの使用方法に合わせて、その一方が定義されない場合であっても、ＵＥ１は適宜その動作を選択ないし修正できるものとする。
ここで、接続制御部１０６は、動作指示が“待機”であったことを受けて、自分が接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）からのＢＳ処理が開始されることを察知し、外部からのIKE_SA_INITを受信できる状態にＢＳ処理部１０４をセットする（ステップＳ５０１１）。このとき、接続制御部１０６は、ＢＳ処理部１０４が既に開始したＰＧＷ５（Ｉ−ＰＧＷ５ａ）とのＢＳ処理に関する状態、データをクリアあるいはリセットしてもよい。これにより、今後必要とされないＩ−ＰＧＷ５ａとの接続に関する状態やデータを保持しておく必要がなくなり、リソースの有効活用を図ることができる。また、Ｔ−ＰＧＷ５ｂからのＢＳ処理が結果的に失敗（オペレータによる判断、ネットワーク側リソース欠落などを原因とする）することに備えて、Ｉ−ＰＧＷ５ａとの接続に関する状態データをあえて保持しておいてもよく、これにより結果的にＩ−ＰＧＷ５ａと接続しなければならなくなった場合に、ＢＳ処理の途中から再開することができる（少なくともＩＫＥ ＳＡは保持されており、IKE_AUTH Requestから実施することで十分である）。
やがてＴ−ＰＧＷ５ｂにおいてＵＥ１に対するＢＳ処理が開始され、IKE_SA_INITの最初のメッセージ（図２ではステップＳ３００８：IKE_SA_INIT_1として表記）がＵＥ１に配送される。Ｔ−ＰＧＷ５ｂからの最初のIKE_SA_INITメッセージは、第２無線通信部１０２、パケット処理部１０３を介してＢＳ処理部１０４に転送され、ＢＳ処理部１０４ではＴ−ＰＧＷ５ｂからのIKE_SA_INITメッセージであることを確認すると、メッセージに含まれるT-PGW_BS_Identityを接続制御部１０６に転送する。接続制御部１０６では、取得したT-PGW_BS_Identityが、先にステップＳ５００７で受信したIKE_AUTH Responseに記載されたUE_BS_Identityに基づいて生成あるいは取得したものと同じ（同じ値、同じ属性、所定の閾値内、所定の関数を経て同一性を検証、など）であるかを評価する（ステップＳ５０１２）。なお、図４に示すフローでは、IKE_SA_INITメッセージにT-PGW_BS_Identityが含まれており、IKE_AUTH Responseメッセージに記載されたUE_BS_Identityとの相関を判断することで評価を行う場合の処理について記載されているが、先述したBS_Identityの使用方法に応じた様々な方法によって、受信したIKE_SA_INITメッセージがＴ−ＰＧＷ５ｂからのＢＳ処理要求かどうかを判断することが可能である。
ステップＳ５０１２による処理で同じものである（相関を有する）と評価されなかった場合は、意図しないＰＧＷ５あるいは他ノードからのＢＳ処理であると判断し、接続制御部１０６は、受信したIKE_SA_INITメッセージを破棄あるいはリジェクトするようＢＳ処理部１０４に指示し、ＢＳ処理部１０４は指示に従ってメッセージを破棄あるいはリジェクトする（ステップＳ５０２０）。
一方、ステップＳ５０１２による処理で同じものである（相関を有する）と評価された場合は、応答として送信する第２のIKE_SA_INITメッセージ（図２のステップＳ３００９で送信されるIKE_SA_INIT_2）にUE_BS_Identityを格納して送信するようＢＳ処理部１０４に指示する（ステップＳ５０１３）。ＢＳ処理部１０４は、指示に従って、UE_BS_Identityを格納した第２のIKE_SA_INITメッセージをＴ−ＰＧＷ５ｂ宛に送信する。本IKE_SA_INITメッセージを受信したＴ−ＰＧＷ５ｂは、メッセージに格納されたUE_BS_Identityを用いて、意図したＵＥ１からの応答であるかを検証し、正しく検証が完了した場合には、以降のＢＳ処理がＴ−ＰＧＷ５ｂとの間で継続実行される（ステップＳ５０１４）。すべてのＢＳ処理が完了すると、接続制御部１０６は、ＤＳＭＩＰあるいはＭＩＰｖ６に基づくＢＵ／ＢＡ交換をＴ−ＰＧＷ５ｂと実施するようＭＩＰ処理部１０７に指示し、ＭＩＰ処理部１０７がＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（ステップＳ５０１５）。
次に、本発明を実施するためのＰＧＷ５の構成について説明する。以下、図８を参照しながら、本発明の第１の実施の形態におけるＰＧＷ５の構成について説明する。図８は、本発明の第１の実施の形態におけるＰＧＷ５の構成の一例を示す図である。
図８において、ＰＧＷ５は、コアネットワーク４と接続して下位レイヤにおける通信処理を行う通信部２０１、通信部の上位でＩＰなどのパケット通信処理を実施するパケット処理部２０２、ＵＥ１とＰＧＷ５との間のブートストラップ処理を実施するＢＳ処理部２０３、ＡＡＡサーバ８ａへの問い合わせメッセージと、ＵＥ１へのＢＳ指示を取得するＡＡＡクラインアント処理部２０４、本発明における特徴的な処理を実施する接続制御部２０５、ＤＳＭＩＰやＭＩＰｖ６に基づいてＢＵ／ＢＡ交換などの移動管理処理をＰＧＷ５に対して実施するＭＩＰ処理部２０６を少なくとも有する。
次に、図８に図示されている構成を有するＰＧＷ５の処理フローについて、本発明における特徴的な処理を実施する接続制御部２０５に係る処理を中心に、図９を用いて詳しく説明する。なお、ＰＧＷ５は、既に通信部２０１を介し、３Ｇアクセス２（ホームリンク）に接続済みであるものとする。また、ＵＥ１が最初にアタッチ（接続）処理を試みるＰＧＷ５は、Ｉ−ＰＧＷ５ａとする。
図９は、本発明の第１の実施の形態におけるＰＧＷ５の処理フローの一例を示すフロー図である。本発明によるＰＧＷ５は、ＵＥ１とＳＡを確立するためにＵＥ１からのＢＳを待つ。ＵＥ１がＩ−ＰＧＷ５ａとアタッチ（接続）処理を接続手順に従って開始すると、ＵＥ１からIKE_SA_INITメッセージが送られてくる（ステップＳ６００２）。その後、次ステップであるIKE_AUTH Requestメッセージ（ＵＥ１のHome Prefixが含まれている）をＩ−ＰＧＷ５ａが受信すると、Ｉ−ＰＧＷ５ａは、そのメッセージに格納されているHome PrefixがＩ−ＰＧＷ５ａの持つバインディングキャッシュに登録されているか確認する（ステップＳ６００３）。
なお、ＵＥ１とＴ−ＰＧＷ５ｂの３Ｇアクセス経由の接続には、ＰＭＩＰあるいはＧＴＰプロトコルが用いられるのに対し、今回のＮ３Ｇアクセス経由の接続では、ＭＩＰあるいはＤＳＭＩＰが用いられるため、Ｉ−ＰＧＷ５ａに向けてブートストラッピング処理が開始されている。コアネットワーク４の運用形態によっては、ＰＭＩＰあるいはＧＴＰで用いられるＵＥ１の位置管理を行うためのデータベース（例えばＰＭＩＰバインディングキャッシュ）と、ＤＳＭＩＰ／ＭＩＰで用いられる同ＵＥ１の位置管理を行うためのデータベース（例えばＭＩＰバインディングキャッシュ）はそれぞれ個別に管理運用されることも想定される。さらには、それぞれ（ＧＴＰ、ＰＭＩＰ、ＤＳＭＩＰ／ＭＩＰ）の位置管理機能が論理的あるいは物理的に異なる装置で実施されることも想定される。そのような場合、Ｉ−ＰＧＷ５ａは、ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されているかどうかをチェックする際に、ＤＳＭＩＰ／ＭＩＰで用いられる管理データベース（ＭＩＰバインディングキャッシュ）の確認だけではなく、Ｉ−ＰＧＷ５ａが管理する（あるいは、Ｉ−ＰＧＷ５ａの管轄対象である他ノードが管理する、さらにはＩ−ＰＧＷ５ａと同じドメインに配置された他ノードが管理する）ＰＭＩＰバインディングキャッシュや、ＧＴＰ用の位置管理データベースの確認も行うことが望ましい。
このとき、Ｉ−ＰＧＷ５ａのバインディングキャッシュに登録されていないHome Prefixであった場合、Ｉ−ＰＧＷ５ａは、UE_BS_Identityを生成（取得）する（ステップＳ６０１０）。なお、UE_BS_Identityを生成する方法は、上述のようにいくつか存在する。そして、Ｉ−ＰＧＷ５ａは、IKE_SA_INITメッセージに格納されていたHome Prefixを管理しているＴ−ＰＧＷ５ｂがＵＥ１に対してＢＳをするように指示するための動作指示を生成する（ステップＳ６０１１）。そして、IKE_SA_INITメッセージで受信したHome Prefixと、生成したUE_BS_Identityと、動作指示をＡＡＡサーバ８ａに送信する（ステップＳ６０１２）。なお、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａやＨＳＳ８ｂで検索及び特定されてもよく、あるいは、Ｉ−ＰＧＷ５ａによって検索及び特定されてもよい。
また、Ｉ−ＰＧＷ５ａは、ＡＡＡサーバ８ａ方向とは別に、ＵＥ１へ送信するためのＵＥ１への動作指示を生成する（ステップＳ６０１３）。そして、Home Prefixが異なっていたことを示すPrefix判定結果（例えば、Falseや‘１’など）と、生成したUE_BS_Identityと、ＵＥ１への動作指示をＵＥ１へ送信する（ステップＳ６０１４）。なお、ここでは、ステップＳ６０１１及びＳ６０１２における動作指示の送信処理（ＡＡＡサーバ８ｂへの送信）の後で、ステップＳ６０１３及びＳ６０１４における動作指示の送信処理（ＵＥ１への送信）が行われるように説明しているが、これらの送信処理の順序は特に限定されず、任意の順序又は並列して行われてもよい。
一方、IKE_AUTH Requestメッセージに格納されているHome PrefixがＩ−ＰＧＷ５ａの持つバインディングキャッシュに登録されている場合（ステップＳ６００３）は、標準的なＢＳ処理を実行し（ステップＳ６０３０）、ＳＡ確立後にＵＥ１から送られてくるＢＵに対し、ＢＡを交換する（ステップＳ６０３１）。
また、ＰＧＷ５がＩ−ＰＧＷ５ａではなくＴ−ＰＧＷ５ｂとして働く場合には、IKA_SA_INITメッセージではなく、Home Prefix確認要求返信メッセージを受信する（ステップＳ６００４）。この場合、Ｔ−ＰＧＷ５ｂは、受信したUE_BS_IdentityからT-PGW_BS_Identityを生成（取得）する（ステップＳ６０２０）。そして、Ｔ−ＰＧＷ５ｂは、生成したT-PGW_BS_Identityを格納したIKE_SA_INIT_1メッセージをＵＥ１に送信する（ステップＳ６０２１）。Ｔ−ＰＧＷ５ｂは、IKE_SA_INIT_1メッセージの返信と予想されるIKE_SA_INIT_2メッセージを受信すると、ＡＡＡサーバ８ａから転送されてきたUE_BS_Identity（ステップＳ６００４で受信したHome Prefix確認要求返信メッセージに含まれているUE_BS_Identity）を使用して、IKE_SA_INIT_2メッセージに格納されているBS_Identityと照合する（ステップＳ６０２２）。一致していた場合、引き続き標準的なＢＳ処理を実施し、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立する（ステップＳ６０４０）。そして、ＳＡ確立後、ＵＥ１から送られてくるＢＵに対し、ＢＡを交換する（ステップＳ６０４１）。
なお、BS_Identityの使用方法によっては、ステップＳ６００４で受信したHome Prefix確認要求返信メッセージにT-PGW_BS_Identityやその他の種類の値が含まれている場合があるが、このような場合も同様にこれらの値を用いて、IKE_SA_INIT_2メッセージに含まれているBS_Identityの照合を行うことが可能である。
次に、本発明を実施するためのＡＡＡサーバ８ａの構成について説明する。以下、図１０を参照しながら、本発明の第１の実施の形態におけるＡＡＡサーバ８ａの構成について説明する。図１０は、本発明の第１の実施の形態におけるＡＡＡサーバ８ａの構成の一例を示す図である。なお、上述のように、ＡＡＡサーバ８ａとＨＳＳ８ｂは物理的又は論理的に同一の装置に実装されるものであってもよく、例えば、図１０に示す構成がＨＳＳ８ｂに実装されてもよい。
図１０において、ＡＡＡサーバ８ａは、コアネットワーク４と接続して下位レイヤにおける通信処理を行う通信部３０１、通信部の上位でＩＰなどのパケット通信処理を実施するパケット処理部３０２、本発明における特徴的な処理を実施する接続制御部３０３、ＤＳＭＩＰやＭＩＰｖ６などのプロトコルに対応するＵＥ１の認証／承認処理を実施する認証／承認処理部３０４を少なくとも有する。
次に、図１０に図示されている構成を有するＡＡＡサーバ８ａの処理フローについて、本発明における特徴的な処理を実施する接続制御部３０３に係る処理を中心に、図１１を用いて詳しく説明する。なお、ＡＡＡサーバ８ａは、既に通信部３０１を介して、コアネットワーク４と接続済みであるものとする。また、ＵＥ１が最初にアタッチ（接続）処理を試みるＰＧＷ５はＩ−ＰＧＷ５ａとする。
図１１は、本発明の第１の実施の形態におけるＡＡＡサーバ８ａの処理フローの一例を示すフロー図である。本発明によるＡＡＡサーバ８ａは、ＰＧＷ５から送られてくるHome Prefix確認要求メッセージを待つ。ＵＥ１がＩ−ＰＧＷ５ａとアタッチ（接続）処理を接続手順に従って開始すると、Ｉ−ＰＧＷ５ａからHome Prefix確認要求メッセージが送られてくる（ステップＳ７００２）。このメッセージを受信したＡＡＡサーバ８ａは、Home Prefix確認要求メッセージに動作指示が格納されているかどうか確認し、さらにその動作指示が転送指示であるかどうかを確認する（ステップＳ７０１０）。動作指示が転送指示であった場合には、ＡＡＡサーバ８ａは、Home Prefix確認要求メッセージに格納されていたHome PrefixがＨＳＳ８ｂの持つサブスクリプションデータ（Subscription data）に登録されているかどうかをＨＳＳ８ｂへ問い合わせる。ＨＳＳ８ｂは、問い合わせメッセージを受け、Subscription dataを参照して対象のHome Prefixが登録されているか確認し、登録されていた場合には対象のHome Prefixを管理しているＴ−ＰＧＷ５ｂのアドレスをＡＡＡサーバ８ａに返信する（ステップＳ７０１１）。ＡＡＡサーバ８ａは、ＨＳＳ８ｂから返信されたメッセージにＴ−ＰＧＷ５ｂのアドレスが格納されているか確認する（ステップＳ７０１２）。Ｔ−ＰＧＷ５ｂのアドレスが格納されていた場合は、ＵＥ１にＢＳするようにＢＳ指示を生成する（ステップＳ７０１３）。そして、ＵＥ１のアドレスと、Ｉ−ＰＧＷ５ａから送られてきたUE_BS_Identityと、ステップＳ７０１３で生成したＢＳ指示とをＴ−ＰＧＷ５ｂに送信する（ステップＳ７０１４）。
また、ＨＳＳ８ｂから返信されたメッセージにＴ−ＰＧＷ５ｂのアドレスが格納されていなかった場合（ステップＳ７０１２）や、Home Prefix確認要求メッセージに転送指示が格納されていなかった場合（ステップＳ７０１０）は、Ｉ−ＰＧＷ５ａにその結果（例えば、Falseや‘１’など）を返信する（ステップＳ７０３０）。
また、ＰＧＷ５からHome Prefix確認要求メッセージではなく、Authentication-Request/Identityメッセージを受信した場合（ステップＳ７０２０）は、Authentication-Request/Identityメッセージに応じて、ＨＳＳ８ｂにUser Profile（ユーザプロファイル）とＡＶｓ（Authentication Vectors：認証ベクタ）を要求し、取得する（ステップＳ７０２１）。User ProfileとＡＶｓ取得後、ＡＡＡサーバ８ａは、EAP-Request/AKA-ChallengeメッセージをＰＧＷ５に返信する（ステップＳ７０２２）。そして、ＡＡＡサーバ８ａはEAP-Request/AKA-Challengeメッセージの返信であるEAP-Response/AKA-Challengeメッセージを受信し（ステップＳ７０２３）、その返信であるAuthentication-Answer/EAP-Success + keying material（鍵素材）メッセージをＰＧＷ５に返信する（ステップＳ７０２４）。
＜第２の実施の形態＞
次に、本発明の第２の実施の形態におけるシステム動作の一例について、図１３を用いて詳しく説明する。図１３は、本発明の第２の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。図１３は、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによって構成され、処理シーケンスの一例が図示されている。
以下、従来の技術と比較しながら、図１３に図示されている本発明の第２の実施の形態におけるシステム動作の一例について説明する。本発明の第２の実施の形態の処理フローのステップＳ９１０１〜Ｓ９１０５は、従来技術のPDN GW reallocation procedureのステップＳ９００１〜Ｓ９００５（図１２に図示）と同一である。
従来技術のPDN GW reallocation procedure（図１２に図示されている処理フロー）では、Ｉ−ＰＧＷ５ａはEAP-Request/AKA-Challengeメッセージを受信することで、Ｔ−ＰＧＷ５ｂのアドレスを取得するが（図１２のステップＳ９００６）、実際にＵＥ１へＴ−ＰＧＷ５ｂの存在（アドレス）を通知するのは、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立後に実施されるＢＵ／ＢＡ交換時である（図１２のステップ９０１６）。
一方、本発明の第２の実施の形態においては、Ｉ−ＰＧＷ５ａは、図１３に示したポイントＡ（ステップＳ９１０６でＩ−ＰＧＷ５ａがＡＡＡサーバ８ａからのEAP-Request/AKA-Challengeメッセージを受信したとき）においてＴ−ＰＧＷ５ｂのアドレスを取得した時点で、例えば、ステップＳ９１０７でＵＥ１へ送信するIKE_AUTH Responseメッセージ（あるいは、その他のメッセージを利用してもよい）にＴ−ＰＧＷ５ｂのアドレスを挿入することで、ステップＳ９１０６で取得したＴ−ＰＧＷ５ｂのアドレスをＵＥ１に通知する。
ここで、本発明の第２の実施の形態においては、ＵＥ１がＩ−ＰＧＷ５ａとの間で接続認証を行っている途中で、Ｔ−ＰＧＷ５ｂのアドレスがＵＥ１へ通知される。これは、ＵＥ１がＮ３Ｇアクセス３にアタッチ（接続）する際に、コアネットワーク４によるアクセス認証（図１３のステップＳ９１００）が既に実施されており、その認証結果を担保にＵＥ１へのＴ−ＰＧＷ５ｂのアドレスの通知許可が決定されるためである。
このように、本発明の第２の実施の形態によれば、ＵＥ１は、従来技術と比較してより早期の段階（例えば、IKE_AUTH ResponseメッセージからＴ−ＰＧＷ５ｂのアドレスを抽出した段階）で、Ｔ−ＰＧＷ５ｂのアドレスを把握することが可能となり、所望のＰＧＷ５（Ｔ−ＰＧＷ５ｂ）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）に接続を行おうとしていることを認識できるようになる。その結果、ＵＥ１は、従来技術と比較してより早期の段階で、Ｉ−ＰＧＷ５ａではなくＴ−ＰＧＷ５ｂとＢＳをやり直す処理（ステップＳ９２０２〜Ｓ９２１４：標準的なＢＳ）を開始することが可能となり、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立した後、ＵＥ１及びＴ−ＰＧＷ５ｂはＢＵ／ＢＡの交換を実施することが可能となる（ステップＳ９２１５、Ｓ９２１６））。
ただし、ステップＳ９１０７でIKE_AUTH ResponseメッセージをＵＥ１へ送信した時点では、ＡＡＡサーバ８ａは、ＵＥ１に対するチャレンジ情報を送信した後にレスポンス情報の受信を待っている状態であり、少なからずＵＥ１に関する状態を保持した状態にある。したがって、ＵＥ１は、図１３に図示されているように、ステップＳ９１０８においてIKE_AUTH Request相当のメッセージを送信するなどして、ＡＡＡサーバ８ａの状態待ちを解消し、ステップＳ９１１２においてIKE_AUTH Response相当のメッセージを受信するなどして、実施中のＢＳ処理が終了したことを確認する必要があるかもしれない（ステップＳ９１０８〜Ｓ９１１２）。
ＵＥ１は、ＡＡＡサーバ８ａの状態待ちを解消する処理によってＴ−ＰＧＷ５ｂとの接続が遅延してしまわないようにするため、ステップＳ９１０８〜Ｓ９１１２におけるＡＡＡサーバ８ａの状態待ちの解消処理と並列して、ステップＳ９２０２〜Ｓ９２１６におけるＴ−ＰＧＷ５ｂとの接続処理を行ってもよい。これにより、ＵＥ１とＴ−ＰＧＷ５ｂとの間のＳＡ確立に要する時間が、ＡＡＡサーバ８ａの状態待ちの解消の返信であるIKE_AUTH Response相当のメッセージを受信するまでの時間分だけ短縮可能となる。
＜第３の実施の形態＞
次に、本発明の第３の実施の形態におけるシステム動作の一例について、図１４から１６を用いて詳しく説明する。図１４は、本発明の第３の実施の形態におけるシステム動作の一例を説明するための第１のシーケンス図である。図１４には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
本発明の第３の実施の形態では、Ｔ−ＰＧＷ５ｂのアドレスが、IKE_AUTHメッセージ交換の完了後、すなわちＵＥ１とＡＡＡサーバ８ｂが相互認証に成功して作成されたＭＳＫがＵＥ１とＩ−ＰＧＷ５ａとの間で交換された後に通知される場合のＰＧＷ切り替え方法について説明する。以下、従来技術のPDN GW reallocation procedure（図１２に図示されている処理フロー）と比較しながら、図１４に図示されている本発明の第３の実施の形態におけるシステム動作の一例について説明する。
図１４において、本発明の第３の実施の形態の処理フローのステップＳ１０００１〜Ｓ１０００９は、従来技術のPDN GW reallocation procedureのステップＳ９００１〜Ｓ９００９（図１２に図示）と同一であるので説明を省略する。
続いて、従来技術のPDN GW reallocation procedure（図１２に図示）における次ステップＳ９０１０では、ＡＡＡサーバ８ａがＩ−ＰＧＷ５ａ経由でＵＥ１から送られてきたEAP-Responseメッセージを処理し、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立に必要である鍵（Master Session key：以降、ＭＳＫと呼ぶ）と、ＵＥ１にとっての切り替え先となるＴ−ＰＧＷ５ｂのアドレスとをＩ−ＰＧＷ５ａに送信する（図１２、ステップＳ９０１０）。一方、本発明の第３の実施の形態では、従来ではＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに送信されるＭＳＫとＴ−ＰＧＷ５ｂのアドレスに、更にUE_BS_Identityを加えたAuthentication-AnswerメッセージをＩ−ＰＧＷ５ａに送信する（図１４、ステップＳ１００１０）。
図１８Ｂは、図１４のステップＳ１００１０においてＡＡＡサーバ８ａがＩ−ＰＧＷ５ａに送信する応答メッセージの一例として、Authentication-Answerメッセージのフォーマット例を示す図である。ＡＡＡサーバ８ａは、従来の標準的なAuthentication-Answerメッセージ４１０１に加えて、ＭＳＫ（鍵）フィールド４１０２、ＢＳ識別子フィールド（UE_BS_Identity/T-PGW_BS_Identity）４１０３を設ける。ＭＳＫ（鍵）フィールド４１０２は、ＵＥ１とＩ−ＰＧＷ５ａとの間で使用する鍵をＩ−ＰＧＷ５ａへ送信するためのフィールドである。なお、ＡＡＡサーバ８ａは、ＭＳＫ（鍵）フィールド４１０２にＭＳＫを格納してもよく、あるいは、ＭＳＫ（鍵）フィールド４１０２を使用せずにAuthentication-Answerメッセージ４１０１内にＭＳＫを格納してもよい。Authentication-Answerメッセージ４１０１内にＭＳＫを格納する場合には、応答メッセージにＭＳＫ（鍵）フィールド４１０２を設けなくてもよい。
また、ＢＳ識別子フィールド４１０３は、使用用途によってUE_BS_IdentityやT-PGW_BS_IdentityをＰＧＷ５に通知することが可能である。また、標準的なAuthentication-Answerメッセージの既存のペイロードにBS_Identityを記載し、ＰＧＷ５に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続く本発明の第３の実施の形態の処理フローのステップＳ１００１１〜Ｓ１００１３は、従来技術のPDN GW reallocation procedureのステップＳ９０１１〜Ｓ９０１３（図１２に図示）と同一であるので説明を割愛する。
続いて、従来技術のPDN GW reallocation procedureにおける次ステップでは、Ｉ−ＰＧＷ５ａからＵＥ１にＴ−ＰＧＷ５ｂのアドレスなどが送信される（図１２、ステップＳ９０１４）。一方、本発明の第３の実施の形態では、ＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに従来送信されていたＭＳＫに加えて、Ｔ−ＰＧＷ５ｂのアドレスと、ＡＡＡサーバ８ａから通知されたUE_BS_IdentityとをIKE_AUTH Responseメッセージに乗せてＵＥ１に通知する（図１４、ステップＳ１００１４）。
図１７Ｂは、図１４のステップＳ１００１４においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３１０１に加えて、ＢＳ識別子（UE_BS_Identity/T-PGW_BS_Identity）フィールド３１０２を設け、それぞれの値をＵＥ１に通知することができる。ＢＳ識別子（BS_Identity）フィールド３１０２では、使用用途によってUE_BS_IdentityやT-PGW_BS_IdentityをＰＧＷ５に通知することが可能である。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してT-PGW_BS_Identityを記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよいが、IKE_AUTH Responseメッセージの送信と同時、あるいはIKE_AUTH Responseメッセージよりも後に送信されることが望ましい。
なお、ここでは、IKE_AUTHメッセージ交換（図１４、ステップＳ１００１２、Ｓ１００１３）によってＵＥ１とＩ−ＰＧＷ５ａとの間でＭＳＫが交換された後に、Ｉ−ＰＧＷ５ａからＵＥ１に対してＴ−ＰＧＷ５ｂのアドレス通知（例えば、ステップＳ１００１４のIKE_AUTH Responseメッセージによる通知）が行われているが、ＡＡＡサーバ８ａによるＵＥ１の認証が成功した時点（すなわち、ステップＳ１０００９で受信したチャレンジ情報に基づいてＡＡＡサーバ８ａがＵＥ１の認証を完了した時点）で、ネットワーク側からＵＥ１に対してＴ−ＰＧＷ５ｂのアドレスを通知することも可能である。この場合には、ステップＳ１０００９で受信したチャレンジ情報の処理が完了した後に、任意のメッセージ（例えば、ステップＳ１００１０、Ｓ１００１２におけるメッセージ）にＴ−ＰＧＷ５ｂのアドレスを格納してＵＥ１へ通知してもよい。
続いて、ＵＥ１は、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立するために、ＢＳ処理を開始する。ＵＥ１とＴ−ＰＧＷ５ｂは、ＵＥ１認証を行うIKE_AUTHメッセージを保護するために、ＵＥ１とＴ−ＰＧＷ５ｂとの間でIKE_SA_INITメッセージ交換を実施し、ＵＥ１とＴ−ＰＧＷ５ｂ間の共有鍵を生成する（図１４、ステップＳ１０１０１）。
次に、ＵＥ１はIKE_AUTH Requestメッセージを作成し、先にIKE_SA_INITメッセージ交換を通じて生成したＵＥ１とＴ−ＰＧＷ５ｂとの間の共有鍵を使用して暗号化し、Ｔ−ＰＧＷ５ｂに送信する。ここで、先にＵＥ１とＩ−ＰＧＷ５ａとの間で実施したＳＡ確立の際に生成されたＭＳＫ（鍵）を再利用するよう要求することにより、従来技術ではこの後に必要であったＵＥ１とＡＡＡサーバ８ａとの間の相互認証を省略することができる。そのため、ＵＥ１は、先に生成したＭＳＫの再利用を示すReuse IndicatorをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに送信する（図１４、ステップＳ１０１０２）。
なお、Reuse indicatorは、ＵＥ１とＩ−ＰＧＷ５ａとの間のブートストラップ処理の過程でＩ−ＰＧＷ５ａ又はＡＡＡサーバ８ａなどが生成し、ＵＥ１に通知するものであってもよい。特にＡＡＡサーバ８ａが生成してＵＥ１に通知することにより、ＡＡＡサーバ８ａあるいはＡＡＡサーバ８ａを含むネットワークシステムが、鍵の再利用をサポートあるいは許可することの表明をＵＥ１に対して行うことができ、ＵＥ１にとっては、確信を持って鍵の再利用を要求することができ、ひいては所望のＴ−ＰＧＷ５ｂとの切り替え接続をより確実に短時間で終えることができるようになる。
さらには、ＡＡＡサーバ８ａがReuse Indicatorを生成及び通知したが、そのドメインあるいはコアネットワーク４のＰＧＷ５がサポートあるいは許可しない場合（例えばローミングＵＥ１に対しては許可しないなどの理由から）は、ＰＧＷ５がReuse Indicatorを除去してＵＥ１に通知しないようにしてもよい。これにより、例えばＵＥ１のホームネットワーク（ＨＰＬＭＮ：Home Public Land Mobile Network）では鍵の再利用がサポートあるいは許可されても、ＵＥ１の在圏ネットワーク（ＶＰＬＭＮ：Visited Public Land Mobile Network）ではサポートあるいは許可されない場合に対応することができるようになる。
また、Ｉ−ＰＧＷ５ａを通じてＡＡＡサーバ８ａと既に相互認証を完了しているＵＥ１からのＢＳ処理であることを、後のＴ−ＰＧＷ５ｂ経由の相互認証処理時にＡＡＡサーバ８ａが識別可能にするために、ＵＥ１はUE_BS_IdentityをIKE_AUTH Requestメッセージに格納する（図１４、ステップＳ１０１０２）。
図１７Ａは、図１４のステップＳ１０１０２においてＵＥ１がＴ−ＰＧＷ５ｂに送信するメッセージの一例として、IKE_AUTH Requestメッセージのフォーマット例を示す図である。ＵＥ１は、従来の標準的なIKE_AUTH Requestメッセージ３００１に加えて、Reuse Indicatorフィールド３００２、ＵＥ用ＢＳ識別子（UE_BS_Identity）フィールド３００３を設け、それぞれの値をＴ−ＰＧＷ５ｂに通知することができる。また、標準的なIKE_AUTH Requestメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してReuse Indicatorを記載し、ＵＥ１に通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればIKE_AUTH Requestメッセージ以外のメッセージであってもよい。
Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてきたIKE_AUTH Requestメッセージに含まれるReuse indicatorとUE_BS_IdentityとをＡＡＡサーバ８ａに転送する（図１４、ステップＳ１０１０３）。なお、Reuse IndicatorとUE BS Identityは、ＵＥ１がIKE_SA_INITメッセージを通じてＴ−ＰＧＷ５ｂに通知し、Ｔ−ＰＧＷ５ｂはIKE SA INITメッセージの交換と並行して同パラメータをＡＡＡサーバ８ａに通知するものであってもよい。
図１８Ａは、図１４のステップＳ１０１０３においてＴ−ＰＧＷ５ｂがＡＡＡサーバ８ａに送信するメッセージの一例として、Authentication-Requestメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なAuthentication-Requestメッセージ４００１に加えて、Reuse Indicatorフィールド４００２、ＵＥ用ＢＳ識別子（UE_BS_Identity）フィールド４００３を設け、それぞれの値をＡＡＡサーバ８ａに通知することができる。また、標準的なAuthentication-Requestメッセージの既存のペイロードにReuse IndicatorとUE_BS_Identityとを記載し、ＡＡＡサーバ８ａに通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればAuthentication-Requestメッセージ以外のメッセージであってもよい。
ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから転送されてきたReuse indicatorを受けて、先にＵＥ１とＩ−ＰＧＷ５ａとの間でＳＡ確立した際のＭＳＫの再利用が要求されていると判断し、ＡＡＡサーバ８ａが保持するUE_BS_Identityに対応しているＭＳＫをＴ−ＰＧＷ５ｂに通知する。なお、UE_BS_Identityは、一度フル認証を完了しているＵＥ１であることを確認できるパラメータ（例えば、User IDなど）に代替してもよい。ＭＳＫを通知すると同時に、UE_BS_Identityに対応するT-PGW_BS_Identityも通知する（図１４、ステップＳ１０１０４）。なお、T-PGW_BS_Identityは、ＡＡＡサーバ８ａ自身が生成してもよいし、BS_Identityリストを保持しているネットワーク上のデータベースサーバ（不図示）が設置されている場合は、データベースサーバに問い合わせてUE BS Identityに対応するT-PGW BS_Identityを取得して利用してもよい。
ここで、ＭＳＫの再利用が先に指示された異なるＰＧＷ５への切り替え接続に限って許可される場合（任意のＰＧＷ５からの接続に対してＭＳＫの再利用を許可しない場合）に対応するため、Ｔ−ＰＧＷ５ｂが自身の情報（例えば、ＩＰアドレスやＰＧＷ５の識別子など）を、ステップＳ１０１０３を通じてＡＡＡサーバ８ａに通知することが考えられる。これにより、ＡＡＡサーバ８ａにおいて、本接続要求が先にＵＥ１に対して指示したＴ−ＰＧＷ５ｂへの切り替え接続要求であることを確認することができ、ＭＳＫの再利用を正しく許可することができる。
図１８Ｂは、図１４のステップＳ１０１０４においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージの一例として、Authentication-Answerメッセージのフォーマット例を示す図である。ＡＡＡサーバ８ａは、従来の標準的なAuthentication-Answerメッセージ４１０１に加えて、ＭＳＫ（鍵）フィールド４１０２、ＢＳ識別子フィールド（UE_BS_Identity/T-PGW_BS_Identity）４１０３を設ける。ステップＳ１０１０４では、ＭＳＫ（鍵）フィールド４１０２にＵＥ１とＩ−ＰＧＷ５ａとの間で生成されたＭＳＫを格納する。なお、このＭＳＫは、標準的なAuthentication-Answerメッセージ４１０１内にあるＭＳＫを格納するフィールドに格納されてもよい。その際、ＭＳＫ（鍵）フィールド４１０２を新たに設ける必要はない。また、ＢＳ識別子フィールド４１０３は、使用用途によってUE_BS_IdentityやT-PGW_BS_IdentityをＰＧＷ５に通知することが可能である。また、標準的なAuthentication-Answerメッセージの既存のペイロードにBS_Identityを記載し、Ｔ−ＰＧＷ５ｂに通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから通知されたＭＳＫ（実際にはＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立時に生成されたもの）を用いて生成したAUTHパラメータ値と、再利用を許諾したＡＡＡサーバ８ａが先にＩ−ＰＧＷ５ａとの接続時にＵＥ１をサーブしたのと同じノードであることをＵＥ１が正しく識別するためのT-PGW_BS_IdentityとをIKE AUTH Responseメッセージに格納して、ＵＥ１へ送信する（図１４、ステップＳ１０１０５）。ここで、ステップＳ１００１２〜Ｓ１００１４を通じて、既にＵＥ１はＭＳＫを生成できているので、ステップＳ１０１０５においては認証の成功のみを伝えるだけで十分である（認証の成功と同時にＭＳＫの再利用が承認されたことの通知でもあるため）。
図１７Ｂは、図１４のステップＳ１０１０５においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３１０１に加えて、ＢＳ識別子（BS_Identity）フィールド３１０２を設け、それぞれの値をＵＥ１に通知することができる。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してT-PGW_BS_Identityを記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。
IKE AUTH Responseメッセージを受信したＵＥ１は、UE_BS_IdentityとT-PGW_BS_Identityとの相関を検証し、正しく対応するものであることを確認できたら、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図１４、ステップＳ１０２０１）。
なお、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証のために有用であるが、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合は、これらのBS_Identityを省略することもできる。
また、Ｔ−ＰＧＷ５ｂへの切り替え指示後もＡＡＡサーバ８ａがＵＥ１に対する状態を保持できる場合には、ＵＥ１が通知するReuse Indicatorも省略することができる。この場合、ＡＡＡサーバ８ａは、User IDなどを基にＵＥ１の識別を行い、保持しておいたＵＥ１に対する状態に基づいて鍵データを抽出し、Ｔ−ＰＧＷ５ｂに通知することができる。ただし、一部のＡＡＡサーバ８ａにおいては、切り替え指示後はＵＥ１に対する状態を解消することも想定されるため、汎用性を確保する目的でReuse IndicatorをＵＥ１から通知することは有用である。
以上の動作によって、従来技術のPDN GW reallocation procedureでは、ＵＥ１とＡＡＡサーバとの８ａ間においてＩ−ＰＧＷ５ａとＴ−ＰＧＷ５ｂで計２回のＵＥ認証（Full Authentication）を実施する必要があったが、上述したように鍵の再利用を行うことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続する際のブートストラップ処理のメッセージ数削減と切り替え時間の短縮を図ることができるようになる。
なお、過去にＵＥ１が他のＰＧＷ５とＳＡ確立を実施した実績がある場合、ＵＥ１に対するＰＧＷ５の切り替え要求（すなわち切り替え先ＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスの通知）は、上記説明したステップＳ１００１４より前に実施することも可能である（例えば、図１４のステップＳ１０００７など）。例えば、ＵＥ１は、ステップＳ１０１０２で送信されるReuse IndicatorをステップＳ１０００３のIKE AUTH Requestメッセージに含めて送信する。このReuse Indicatorを参照したＩ−ＰＧＷ５ａは、ステップＳ１０００４〜Ｓ１０００６の処理において、ステップＳ１０１０３及びＳ１０１０４と同様の手順で、ＵＥ１に対して確立済みの鍵をＡＡＡサーバ８ａから取得する（このとき同時に切り替え先ＰＧＷ５のアドレスも取得することになる）。そして、Ｉ−ＰＧＷ５ａは、ステップＳ１０００７で切り替え先ＰＧＷ５のアドレスを含むIKE_AUTH responseメッセージ（すなわち、上記のステップＳ１０１０５で送信されるIKE_AUTH responseメッセージと同等のメッセージ）をＵＥ１へ送信することによって、切り替え先ＰＧＷ５のアドレスをＵＥ１に通知することが可能となる。これにより、ＵＥ１は過去に確立した鍵を再利用して高速に切り替え先ＰＧＷ５のアドレスを取得することができ、ひいては本来接続を希望しないＰＧＷ５が割り当てられた場合でも、所望のＰＧＷ５への切り替え接続を高速に実施することができる。
また、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂへの切り替えを指示するタイミング（図１４、ステップＳ１００１０）で、生成したＭＳＫをＴ−ＰＧＷ５ｂに通知してもよい。具体的には、図１５を用いて説明する。
図１５は、本発明の第３の実施の形態におけるシステム動作の一例を説明するための第２のシーケンス図である。図１５には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図１５の処理フローのステップＳ１１００１〜Ｓ１１０１０は、図１４の処理フローのステップＳ１０００１〜Ｓ１００１０と同一であるので説明を省略する。このステップＳ１１０１０を送信する段階で、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂにＭＳＫを通知することが可能である。ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知する手法としては、例えば、Ｉ−ＰＧＷ５ａにUE_BS_Identityを格納したAuthentication-Answerメッセージを送信する処理と同時に、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立処理の過程で生成したＭＳＫと、UE_BS_Identityに対応するT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに送信する（図１５、ステップＳ１１０１１）。
図１９は、図１５のステップＳ１１０１１においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージの一例として、BS_Identity通知メッセージのフォーマット例を示す図である。ＡＡＡサーバ８ａは、宛先アドレスフィールド５００１にＴ−ＰＧＷ５ｂのアドレス、ソースアドレスフィールド５００２に自アドレス、ＭＳＫ（鍵）フィールド５００３にＵＥ１とＩ−ＰＧＷ５ａとの間で生成されたＭＳＫ、ＵＥアドレスフィールド５００４にＭＳＫに対応するＵＥ１のアドレス（例えば、ＵＥ１のＣｏＡ）、T-PGW_BS_Identityフィールド５００５にUE_BS_Identityに対応しているT-PGW_BS_Identityを記載して、Ｔ−ＰＧＷ５ｂに送信する。なお、BS_Identity通知メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いてもよい。また、BS_Identity通知メッセージに、ＵＥ１のUser IDを含めてもよく、これによりＴ−ＰＧＷ５ｂがＵＥ１からIKE_AUTH Requestメッセージを受信したとき、そのＵＥ１に関してフル認証が完了しているＵＥ１なのかを判別しやすくなり、より確実にＵＥ１を照合することが可能となる。
続く図１５の処理フローのステップＳ１１０１２〜Ｓ１１１０２は、図１４の処理フローのステップＳ１００１１〜Ｓ１０１０２と同一であるので説明を割愛する。
Reuse indicatorとUE_BS_Identityが格納されたIKE_AUTH Requestメッセージ（図１５、ステップＳ１０１０２に対応）を受信したＴ−ＰＧＷ５ｂは、ステップＳ１１０１１でＡＡＡサーバ８ａから受信したT-PGW_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に返信する（図１５、ステップＳ１１１０３）。なお、Ｔ−ＰＧＷ５ｂは、ステップＳ１１１０２で受信したUE_BS_IdentityとステップＳ１１０１１で受信したT-PGW_BS_Identityとが正しく対応するものであるか確認してもよい（例えば、ハッシュ値の検算や、ネットワーク上のBS_Identityリストを管理しているデータベースへの問合せなど）。また、ＵＥ１は既にステップＳ１１０１３のIKE_AUTH ResponseメッセージによってＭＳＫを取得しているので、Ｔ−ＰＧＷ５ｂは、ステップＳ１１１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納して通知する必要はない。ただし、例えば、ＵＥ１が何らかの理由でＭＳＫを保持していない（例えば、既に廃棄しているなど）可能性も考えられるので、Ｔ−ＰＧＷ５ｂが、ステップＳ１１１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納してＵＥ１へ通知して、ＵＥ１がＭＳＫを確実に把握できるようにしてもよい。
図１５のステップＳ１１１０３におけるＴ−ＰＧＷ５ｂからＵＥ１に送信する応答メッセージの一例であるIKE_AUTH Responseメッセージのフォーマット例は、図１７Ｂに図示されているものであり、図１４のステップＳ１０１０５におけるIKE_AUTH Responseメッセージのフォーマット例と同一であるため、説明を割愛する。
IKE AUTH Responseメッセージを受信したＵＥ１は、UE_BS_IdentityとT-PGW_BS_Identityとの相関を検証し、正しく対応するものであることを確認できたら、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図１５、ステップＳ１１２０１）。このように、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを事前に通知しておくことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続した時に、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得する場合に比べて、高速な切り替え接続が可能となる。
なお、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知するより先に、ＵＥ１からのIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂが受信／処理してしまうと、Ｔ−ＰＧＷ５ｂは再度ＵＥ１に対するフル認証処理をＡＡＡサーバ８ａに要求してしまい、接続までに要する時間が増大することになる。これを回避するため、ＵＥ１は図１４で説明したReuse indicatorを含めたIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信し（図１５、ステップＳ１１１０２）、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得していなければ、ＡＡＡサーバ８ａに問い合わせるようにしてもよい。これにより、より確実にＭＳＫの再利用を行うことができるようとともに、切り替え接続の高速化を図ることができる。
また、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証を行うためや、ＡＡＡサーバ８ａにおいて、今回ＵＥ１からの接続要求が、先に指示されたＴ−ＰＧＷ５ｂへの切り替え接続によるものであるか、あるいは新規ＰＧＷ５への接続のためのものであるかを判別して確実にＭＳＫの再利用を実施するために有用であるが、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合、またＡＡＡ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えによりものであることの確認がとれる場合などにおいては、これらのBS_Identityを省略することもできる。
またさらには、理想状態において、Ｔ−ＰＧＷ５ｂはＵＥ１からIKE_AUTH Requestメッセージを受信する前にＡＡＡサーバ８ａからＵＥ１向けの鍵を取得することができ、この時点で鍵の再利用を認識することができるため、ＵＥ１が通知するReuse Indicatorも省略することができる。ただし、先に説明したようにＡＡＡサーバ８ａからの通知がＵＥ１からのIKE_AUTH Requestメッセージ到着より遅れることも想定し、Ｔ−ＰＧＷ５ｂに対して従来のシーケンスに基づく処理ではなく鍵を再利用するためのシーケンスに基づく処理を促す目的でReuse Indicatorを付加することは有用である。
なお、上述の第２の実施の形態で説明したように、ＵＥ１は、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５であるＴ−ＰＧＷ５ｂのアドレスを通知されるかもしれない（図１３のステップＳ９１０７）。しかしながら、第２の実施の形態では、ＵＥ１がＡＡＡサーバ８ａの状態を解消するためにステップＳ９１０８〜Ｓ９１１２を実施するものであったが、実質このステップ区間においてＡＡＡサーバ８ａによる認証処理（ＭＳＫ生成）を完了させて、Ｔ−ＰＧＷ５ｂとの切り替え接続時に認証データ（ＭＳＫなど）を再利用したほうが、総じて処理時間の短縮効果が大きいと考えられる。よって、本第３の実施の形態に対応するＵＥ１が、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５のアドレスを通知された場合は、図１３のステップＳ９１０８でＡＡＡサーバ８ａの状態解消を要求せず、引き続き認証処理を継続してもよい。すなわち、図１３のステップＳ９１０８以降の処理は、図１４のステップＳ１０００８以降に置き換えられるが、既にＴ−ＰＧＷ５ｂのアドレスはステップＳ９１０７でＵＥ１に通知されているので、図１４のステップＳ１００１４で再度通知する必要はない。
次に、本発明の第３の実施の形態における移動端末（ＵＥ１）の構成と処理フローについて説明する。本発明の第３の実施の形態における移動端末（ＵＥ１）の構成は、本発明の第１と第２の実施の形態における移動端末（ＵＥ１）の構成（図３を参照）と同様であるので説明を省略する。
以下、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図１６を用いて詳しく説明する。図１６は、本発明の第３の実施の形態におけるＵＥ１の構成の一例を示す図であり、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２（ホームリンク）に接続済みであり、Ｔ−ＰＧＷ５ｂに接続しているものとする。
本発明による接続制御部１０６は、まずＮ３Ｇアクセス３へのアタッチ（接続）処理を開始するため、第２無線通信部１０２に接続開始を指示する（ステップＳ１２００１）。第２無線通信部１０２では、Ｎ３Ｇアクセス３における接続手順に従って、接続処理を実施する。Ｎ３Ｇアクセス３への接続が完了すると、Ｎ３Ｇアクセス３経由で接続するＰＧＷ５のアドレスを探索するため、ＤＮＳクライアント処理部１０５に探索開始を指示する（ステップＳ１２００２）。このとき、接続制御部１０６は、接続先となるＰＧＷ５のアドレスを取得するため、接続先ネットワークＰＤＮの識別子であるＡＰＮやＰＧＷ５を識別するためのＨＡ−ＡＰＮなどから、標準的な方法により（例えば、非特許文献６に開示されている方法など）、ホームエージェント名（ＦＱＤＮ）を構築し、ＤＮＳクライアント処理部１０５に通知する。ＤＮＳクライアント処理部１０５では、通知されたホームエージェント名を記載したＤＮＳクエリをパケット処理部１０３、第２無線通信部１０２経由でＤＮＳサーバ９宛に送信する。また、その応答としてＤＮＳ応答を第２無線通信部１０２、パケット処理部１０３経由でＤＮＳサーバ９から受信し、ＤＮＳ応答から取得したＰＧＷアドレスを接続制御部１０６に転送する（ステップＳ１２００３）。
接続制御部１０６は、取得したＰＧＷアドレスに対して一般的なＢＳ処理を開始するようＢＳ処理部１０４に指示する。ＢＳ処理部１０４では、ＩＫＥ ＳＡを構築するための手順であるIKE_SA_INIT処理を、接続制御部１０６から通知されたＰＧＷアドレス（Ｉ−ＰＧＷ５ａのアドレス）に対して開始する（ステップＳ１２００４）。IKE_SA_INIT処理が完了し、ＩＫＥ ＳＡが確立されると、ＢＳ処理部１０４は、IKE_AUTH Requestメッセージを送信する（ステップＳ１２００５）。
IKE_AUTH Requestメッセージは、ＢＳ処理部１０４からパケット処理部１０３、第２無線通信部１０２を介してＩ−ＰＧＷ５ａ宛に送信される。Ｉ−ＰＧＷ５ａはIKE_AUTH Requestメッセージの応答としてIKE_AUTH ResponseメッセージをＵＥ１に送信し、ＵＥ１で受信したIKE_AUTH Responseメッセージは、第２無線通信部１０２、パケット処理部１０３を介してＢＳ処理部１０４に転送される（ステップＳ１２００６）。
ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡが確立すると、Ｉ−ＰＧＷ５ａからＴ−ＰＧＷ５ｂへの切り替えが必要であることがＵＥ１に伝えられる。具体的には、切り替え先ＰＧＷ５となるＴ−ＰＧＷ５ｂのアドレスと、Ｉ−ＰＧＷ５ａを介して完了したＡＡＡサーバ８ａによるＵＥ１に対する認証データをＴ−ＰＧＷ５ｂへの切り替え接続時に再利用可能とするための符合UE_BS_Identityとを受信したかを確認する（ステップＳ１２００７）。
ＵＥ１がＴ−ＰＧＷ５ｂのアドレスとUE_BS_Identityとを受信しなかった場合は、ＰＧＷ５の切り替えを要求されなかったことであることから、確立したＳＡを用いてＩ−ＰＧＷ５ａとＢＵ／ＢＡ交換を実施する（ステップＳ１２０３０）。
一方、ＵＥ１がＴ−ＰＧＷ５ｂのアドレスとUE_BS_Identityとを受信した場合、ＵＥ１はＴ−ＰＧＷ５ｂへの切り替え接続を開始する。すなわち、Ｔ−ＰＧＷ５ｂとのＳＡ確立を開始する。最初に、IKE_AUTHメッセージを保護するために必要な共有鍵をＵＥ１とＴ−ＰＧＷ５ｂとの間で生成するために、ＵＥ１はIKE_SA_INITメッセージ交換をＴ−ＰＧＷ５ｂとの間で実施する（ステップＳ１２０１０）。
続いて、ＵＥ１はＴ−ＰＧＷ５ｂとのＳＡ確立において、従来実施されていたフル認証を省略して接続時間を短縮する目的で、Ｉ−ＰＧＷ５ａとのＳＡ確立で生成されたＭＳＫを再利用することを示すReuse Indicatorを生成する（ステップ１２０１１）。なお、ステップＳ１２０１０とステップＳ１２０１１の処理の順番は逆になってもよい。ＵＥ１は、生成したReuse Indicatorと先に取得したUE_BS_IdentityとをIKE_AUTH Requestメッセージに格納して、Ｔ−ＰＧＷ５ｂに送信する（ステップＳ１２０１２）。
Ｔ−ＰＧＷ５ｂは、Reuse IndicatorとUE_BS_Identityとが格納されたIKE_AUTH Requestメッセージを受信するとＡＡＡサーバ８ａに転送する。ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから転送されたIKE_AUTH Requestメッセージを受信すると、Reuse IndicatorとUE_BS_Identityとが格納されていることを確認し、ＵＥ１がＩ−ＰＧＷ５ａを介して接続した際に生成されたＭＳＫと、UE_BS_Identityに対応するT-PGW_BS_Identityとを、例えば、Authentication-AnswerメッセージによってＴ−ＰＧＷ５ｂに通知する。なお、ＡＡＡサーバ８ａは、IKE_AUTH Requestメッセージに対する応答としてＭＳＫ及びT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに通知してもよく（図１４に図示されている第１のシーケンスに対応）、IKE_AUTH Requestメッセージに対する応答よりも先にＭＳＫ及びT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに通知してもよい（図１５に図示されている第２のシーケンスに対応）。ＭＳＫ及びT-PGW_BS_Identityの通知を受けたＴ−ＰＧＷ５ｂは、T-PGW_BS_IdentityをIKE_AUTH Responseメッセージに格納してＵＥ１に送信し、ＵＥ１がそれを受信する（ステップＳ１２０１３）。
ＵＥ１は、IKE_AUTH Responseメッセージに格納されたBS_IdentityがUE_BS_Identityに対応するものであるかを確認する（ステップＳ１２０１４）。なお、ＵＥ１はステップＳ１２００７でUE_BS_Identityを受信した後に、UE_BS_Identityに対応するT-PGW_BS_Identityを任意のタイミングで生成して保持しておいてもよいし、ステップＳ１２０１４のタイミングで生成してもよい（例えば、ハッシュ関数や、BS_Identityリストを保持しているデータベースサーバの利用など）。
ここで、Ｔ−ＰＧＷ５ｂから送られてきたT-PGW_BS_Identityと、ＵＥ１が生成したT-PGW_BS_Identityが一致した場合、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施し、終了する（ステップＳ１２０２０）。一方、一致しなかった場合には、ＵＥ１は、受信したIKE_AUTH Responseメッセージを破棄する（ステップＳ１２０２１）。
なお、図１５に示したように、ＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知するような場合においても、ＵＥ１は、Reuse IndicatorとUE_BS_Identityとを格納したIKE_AUTH_RequestメッセージをＴ−ＰＧＷ５ｂに送信することが望ましい。これにより、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図１５、ステップＳ１１０１１）が遅延したりロスしたりして、Ｔ−ＰＧＷ５ｂが鍵データ（ＭＳＫ）の再利用（フル認証の省略）を認識していない場合であっても、Ｔ−ＰＧＷ５ｂ越しにＭＳＫの再利用を実施することができ、切り替え接続のための時間短縮をより確実なものとすることができる。
また、図１５に図示されている第２のシーケンスでＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知する場合において、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図１５、ステップＳ１１０１１）が遅延したりロスしたりしないことがシステムとして保証されているような場合には、Reuse Indicatorの代わりとしてUser IdentityやＵＥ１のアドレスを使用することで、ＵＥ１はReuse Indicatorを図１６のステップＳ１２０１１で生成したり、ステップＳ１２０１２でIKE_AUTH_Requestメッセージに格納したりしなくてもよい。
またさらには、ＡＡＡサーバ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えを意図していることが確認できる場合、UE_BS_Identityは最早不要であり、図１６のステップＳ１２００７でＵＥ１への通知は行われない。このときＵＥ１は、Ｔ−ＰＧＷ５ｂに対して標準的なＢＳ処理を実行すればよく（図１６には不図示）、これにより、ＭＳＫの再利用がネットワーク側の判断によって実施され、Ｔ−ＰＧＷ５ｂへの切り替え接続を短時間に完了させることができる。
なお、本発明の第３の実施の形態で用いられているUE_BS_Identity並びにT-PGW_BS_Identityに関しても、上述の第１の実施の形態と同様に、様々な組み合わせが可能である。すなわち、本発明の第３の実施の形態において、例えば、UE_BS_Identityと、このUE_BS_Identityに対応するT-PGW_BS_Identityを用いて、UE_BS_IdentityとT-PGW_BS_Identityとの照合が行われてもよく、どちらか一方のBS_Identityが用いられてもよく、あるいは、BS_Identityが用いられなくてもよい。また、本発明の第３の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityに使用される情報として、例えば、ＵＥ１及びＰＧＷ５によって共有されている値を基に生成されたハッシュ値や、ランダムに生成された値やＩ−ＰＧＷ５ａのアドレス（これらに限定されない）など、ＵＥ１及びＰＧＷ５によって認識可能な値（符号）を用いることが可能である。また、本発明の第３の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityは、ＰＧＷ５、ＡＡＡサーバ８ａ、あるいは、その他の通信装置によって生成されてもよい。
なお、本発明の第３の実施の形態で用いたＭＳＫは、インターネットで利用される技術を標準化する組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｔ Ｆｏｒｃｅ）が、ＲＦＣで定義しているＭＳＫと同じであってもよいし、別途規定されてもよい。
＜第４の実施の形態＞
次に、本発明の第４の実施の形態におけるシステム動作の一例について、図１７Ｃ、図２０から図２５を用いて詳しく説明する。図２０は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第１のシーケンス図である。図２０には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
本発明の第４の実施の形態では、Ｔ−ＰＧＷ５ｂのアドレスが、IKE_AUTHメッセージ交換の完了後、すなわちＵＥ１とＡＡＡサーバ８ｂが相互認証（ＡＡＡサーバ８ｂによるＵＥ１の認証）の成功によってＭＳＫを生成して、そのＭＳＫを用いて作成したAUTHパラメータがＵＥ１とＩ−ＰＧＷ５ａとの間で交換されて、お互いに認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）をした後に通知される場合のＰＧＷ切り替え方法について説明する。
以下、従来技術のPDN GW reallocation procedure（図１２に図示されている処理フロー）と比較しながら、図２０に図示されている本発明の第４の実施の形態におけるシステム動作の一例について説明する。
図２０において、本発明の第４の実施の形態の処理フローのステップＳ１３００１〜Ｓ１３００９、従来技術のPDN GW reallocation procedureのステップＳ９００１〜Ｓ９００９（図１２に図示）と同一であるので説明を省略する。
続いて、従来技術のPDN GW reallocation procedure（図１２に図示）における次ステップＳ９０１０では、ＡＡＡサーバ８ａがＩ−ＰＧＷ５ａ（図１２上ではＰＧＷ５に相当）経由でＵＥ１から送られてきたEAP-Responseメッセージを処理し、ＵＥ１とＩ−ＰＧＷ５ａ（図１２上ではＰＧＷ５に相当）との間のＳＡ確立に必要である鍵（Master Session key：以降、ＭＳＫと呼ぶ）と、ＵＥ１にとっての切り替え先となるＴ−ＰＧＷ５ｂのアドレスとをＩ−ＰＧＷ５ａ（図１２上ではＰＧＷ５に相当）に送信する（図１２、ステップＳ９０１０）。一方、本発明の第４の実施の形態では、従来ではＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに送信されるＭＳＫとＴ−ＰＧＷ５ｂのアドレスに、更にUE_BS_Identityを加えたAuthentication-AnswerメッセージをＩ−ＰＧＷ５ａに送信する（図２０、ステップＳ１３０１０）。なお、このUE_BS_Identityは、ＵＥ１がＩ−ＰＧＷ５ａとフル認証を実施したことを証明（例えば、ＡＡＡサーバ８ａが持つT-PGW_BS_Identityとの関連性の有無や、UE_BS_Identityが暗号化される場合には、復号可能であるか確認）するためなどに用いるが、ＵＥ１の固有情報（例えば、ＩＭＳＩ（International Mobile Subscriber Identity）など）を用いることで識別できる場合には、省略してもよい。
図２０のステップＳ１３０１０においてＡＡＡサーバ８ａがＩ−ＰＧＷ５ａに送信する応答メッセージは、本発明の第３の実施の形態における図１４のステップＳ１００１０で用いるメッセージ（図１８Ｂに図示）と同様であるので説明を省略する。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続く本発明の第４の実施の形態の処理フローのステップＳ１３０１１〜Ｓ１３０１３は、従来技術のPDN GW reallocation procedureのステップＳ９０１１〜Ｓ９０１３（図１２に図示）と同一であるので説明を割愛する。
続いて、従来技術のPDN GW reallocation procedureにおける次ステップでは、Ｉ−ＰＧＷ５ａからＵＥ１にＴ−ＰＧＷ５ｂのアドレスなどが送信される（図１２、ステップＳ９０１４）。一方、本発明の第４の実施の形態では、ＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに従来送信されていたＴ−ＰＧＷ５ｂのアドレスに加えて、ＡＡＡサーバ８ａから通知されたUE_BS_IdentityをIKE_AUTH Responseメッセージに乗せてＵＥ１に通知する（図２０、ステップＳ１３０１４）。なお、Ｉ−ＰＧＷ５ａがステップＳ１３０１０でUE_BS_IdentityをＡＡＡサーバ８ａから受信しなかった場合は、このIKE_AUTH Responseメッセージに格納しなくてもよい。
次に、図２０のステップＳ１３０１４においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例について図１７Ｂを用いて説明する。
Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３１０１に加えて、ＢＳ識別子（BS_Identity）フィールド３１０２を設け、それぞれの値をＵＥ１に通知することができる。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してUE_BS_Identityなどを記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよいが、IKE_AUTH Responseメッセージの送信と同時、あるいはIKE_AUTH Responseメッセージよりも後に送信されることが望ましい。
なお、ここでは、IKE_AUTHメッセージ交換（図２０、ステップＳ１３０１３、Ｓ１３０１４）によってＵＥ１とＩ−ＰＧＷ５ａとの間でお互いに認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）をした後に、Ｉ−ＰＧＷ５ａからＵＥ１に対してＴ−ＰＧＷ５ｂのアドレス通知（例えば、ステップＳ１３０１４のIKE_AUTH Responseメッセージによる通知）が行われているが、ＡＡＡサーバ８ａによるＵＥ１の認証が成功した時点（すなわち、ステップＳ１３００９で受信したチャレンジ情報に基づいてＡＡＡサーバ８ａがＵＥ１の認証を完了した時点）で、ネットワーク側からＵＥ１に対してＴ−ＰＧＷ５ｂのアドレスを通知することも可能である。この場合には、ステップＳ１３００９で受信したチャレンジ情報の処理が完了した後に、任意のメッセージ（例えば、ステップＳ１３０１２におけるメッセージ）にＴ−ＰＧＷ５ｂのアドレスを格納してＵＥ１へ通知してもよい。
続いて、ＵＥ１は、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立するために、ＢＳ処理を開始する。ＵＥ１とＴ−ＰＧＷ５ｂは、ＵＥ１とＴ−ＰＧＷ５ｂ間のIKE_AUTHメッセージを保護するために、ＵＥ１とＴ−ＰＧＷ５ｂとの間でIKE_SA_INITメッセージ交換を実施し、ＵＥ１とＴ−ＰＧＷ５ｂ間の共有鍵（例えば、SKEYSEED）などを生成・取得する（図２０、ステップＳ１３１０１）（上記した非特許文献７を参照）。ＵＥ１とＴ−ＰＧＷ５ｂ間で共有鍵の生成後、ＵＥ１とＴ−ＰＧＷ５ｂは、その共有鍵などを用いてパケットの暗号化に用いる鍵（例えば、SK_ei、SK_er）などを生成する（上記した非特許文献７、非特許文献８を参照）。なお、パケットの暗号化に用いる鍵などを生成する方法として、IKE_SA_INITメッセージ交換以外の方法を用いてパケットの暗号化に用いる鍵などを生成できる場合には、他の方法を用いてもよい。
次に、ＵＥ１はIKE_AUTH Requestメッセージを作成し、先にIKE_SA_INITメッセージ交換を通じて生成したＵＥ１とＴ−ＰＧＷ５ｂとの間の鍵を使用して暗号化し、Ｔ−ＰＧＷ５ｂに送信する。ここで、先にＵＥ１とＩ−ＰＧＷ５ａとの間で実施したＳＡ確立の際に生成されたＭＳＫ（鍵）を再利用するよう要求することにより、従来技術ではこの後に必要であったＵＥ１とＡＡＡサーバ８ａ間の相互認証（図２０のステップＳ１３００５〜Ｓ１３００９）やＭＳＫの生成（図２０のステップＳ１３０１０）などを省略することができる。そのため、ＵＥ１は、先に生成したＭＳＫの再利用を示すReuse Indicatorと、Ｉ−ＰＧＷ５ａから受信したUE_BS_IdentityをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに送信する（図２０、ステップＳ１３１０２）。
なお、Reuse indicatorは、ＵＥ１とＩ−ＰＧＷ５ａとの間のブートストラップ処理の過程でＩ−ＰＧＷ５ａ又はＡＡＡサーバ８ａなどが生成し、ＵＥ１に通知するものであってもよい。特にＡＡＡサーバ８ａが生成してＵＥ１に通知することにより、ＡＡＡサーバ８ａあるいはＡＡＡサーバ８ａを含むネットワークシステムが、鍵の再利用をサポートあるいは許可することの表明をＵＥ１に対して行うことができ、ＵＥ１にとっては、確信を持って鍵の再利用を要求することができ、ひいては所望のＴ−ＰＧＷ５ｂとの切り替え接続をより確実に短時間で終えることができるようになる。
さらには、ＡＡＡサーバ８ａがReuse Indicatorを生成及び通知したが、そのドメインあるいはコアネットワーク４のＰＧＷ５がサポートしていない、あるいは許可しない場合（例えばローミングＵＥ１に対しては許可しないなどの理由から）は、ＰＧＷ５がReuse Indicatorを除去してＵＥ１に通知しないようにしてもよい。これにより、例えばＵＥ１のホームネットワーク（ＨＰＬＭＮ：Home Public Land Mobile Network）では鍵の再利用がサポートされている、あるいは許可されても、ＵＥ１の在圏ネットワーク（ＶＰＬＭＮ：Visited Public Land Mobile Network）ではサポートしていない、あるいは許可されない場合に対応することができるようになる。
また、UE_BS_Identityは、Ｉ−ＰＧＷ５ａを通じてＡＡＡサーバ８ａと既に相互認証を完了しているＵＥ１からのＢＳ処理であることを、後のＴ−ＰＧＷ５ｂ経由のＢＳ処理時にＡＡＡサーバ８ａが識別可能にするためにIKE_AUTH Requestメッセージへ格納される。UE_BS_Identityを使用することで、Reuse Indicatorの目的を達成できるのであれば、Reuse Indicatorを省略してもよい。また、その逆でReuse Indicatorを用いることで、UE_BS_Identityの目的を達成できるのであれば、UE_BS_Identityを省略してもよい。
図２０のステップＳ１３１０２においてＵＥ１がＴ−ＰＧＷ５ｂに送信するメッセージは、本発明の第３の実施の形態における図１４のステップ１０１０２で用いるメッセージ（図１７Ａに図示されているIKE_AUTH Requestメッセージのフォーマット例）と同様であるので説明を省略する。また、標準的なIKE_AUTH Requestメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadなどを付加してReuse IndicatorやUE_BS_Identityを記載し、ＵＥ１に通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればIKE_AUTH Requestメッセージ以外のメッセージであってもよい。
Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてきたIKE_AUTH Requestメッセージに含まれるReuse indicatorとUE_BS_IdentityとをＡＡＡサーバ８ａに転送する（図２０、ステップＳ１３１０３）。なお、Reuse IndicatorとUE_BS_Identityは、ＵＥ１がIKE_SA_INITメッセージを通じてＴ−ＰＧＷ５ｂに通知し、Ｔ−ＰＧＷ５ｂはIKE_SA_INITメッセージの交換と並行して同パラメータをＡＡＡサーバ８ａに通知するものであってもよい。
図２０のステップＳ１３１０３においてＴ−ＰＧＷ５ｂがＡＡＡサーバ８ａに送信するメッセージは、本発明の第３の実施の形態における図１４のステップＳ１０１０３で用いるメッセージ（図１８Ａに図示されているAuthentication-Requestメッセージのフォーマット例）と同様であるので説明を省略する。また、標準的なAuthentication-Requestメッセージの既存のペイロードにReuse IndicatorとUE_BS_Identityとを記載し、ＡＡＡサーバ８ａに通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればAuthentication-Requestメッセージ以外のメッセージであってもよい。
ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから転送されてきたReuse indicatorを受けて、先にＵＥ１とＩ−ＰＧＷ５ａとの間でＳＡ確立した際のＭＳＫの再利用が要求されていると判断し、ＡＡＡサーバ８ａが保持するUE_BS_Identityに対応しているＭＳＫをＴ−ＰＧＷ５ｂに通知する。なお、先述したように、UE_BS_Identityは、一度フル認証を完了しているＵＥ１であることを確認できるパラメータ（例えば、ＩＭＳＩなど）に代替してもよい。ＭＳＫを通知すると同時に、UE_BS_Identityに対応するT-PGW_BS_Identityも通知する（図２０、ステップＳ１３１０４）。なお、T-PGW_BS_Identityは、ＡＡＡサーバ８ａ自身が生成してもよいし、BS_Identityリストを保持しているネットワーク上のデータベースサーバ（不図示）が設置されている場合は、データベースサーバに問い合わせてUE BS Identityに対応するT-PGW BS_Identityを取得して利用してもよい。
ここで、ＭＳＫの再利用が先に指示された異なるＰＧＷ５への切り替え接続に限って許可される場合（任意のＰＧＷ５からの接続に対してＭＳＫの再利用を許可しない場合）に対応するため、Ｔ−ＰＧＷ５ｂが自身の情報（例えば、ＩＰアドレスやＰＧＷ５の識別子など）を、ステップＳ１３１０３を通じてＡＡＡサーバ８ａに通知することが考えられる。これにより、ＡＡＡサーバ８ａにおいて、本接続要求が先にＵＥ１に対して指示したＴ−ＰＧＷ５ｂへの切り替え接続要求であることを確認することができ、ＭＳＫの再利用を正しく許可することができる。
図２０のステップＳ１３１０４においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージは、本発明の第３の実施の形態における図１４のステップＳ１０１０４で用いるメッセージ（図１８Ｂに図示されているAuthentication-Answerメッセージのフォーマット例）と同様であるので説明を省略する。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから受信したT-PGW_BS_Identityと、認証の成功（ＡＡＡサーバ８ａによるＵＥ１の認証）と、ＭＳＫの再利用が承認されたことをＵＥ１に通知する（図２０、ステップＳ１３１０５）。
次に、図２０のステップＳ１３１０５においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例としてIKE_AUTH Responseメッセージのフォーマット例について図１７Ｃを用いて説明する。図１７Ｃは、図２０のステップＳ１３１０５で送信するIKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３２０１に加えて、ＢＳ識別子（UE_BS_Identity/T-PGW_BS_Identity）フィールド３２０２、Success Reuse Indicatorフィールド３２０３を設け、それぞれの値をＵＥ１に通知することができる。また、Ｔ−ＰＧＷ５ｂは、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してＭＳＫの再利用やT-PGW_BS_Identityを示してＵＥ１に通知してもよい。または、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコルのEAP Successを用いることで、ＭＳＫの再利用をＵＥ１に通知してもよい。なお、本応答メッセージは、ＵＥ１がＭＳＫの再利用を確認できるメッセージであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。
このT-PGW_BS_Identityは、ＭＳＫの再利用を許諾したＡＡＡサーバ８ａが先にＩ−ＰＧＷ５ａとの接続時にＵＥ１を認証処理したのと同じノードであることをＵＥ１が正しく識別するために用いる。また、例えば、ＡＡＡサーバ８ａにアクセスせず、ＵＥ１へ不正アクセスを試みるＴ−ＰＧＷ５ｂになりすました偽Ｔ−ＰＧＷ５ｂと区別できる効果もある。
ＵＥ１は、Ｔ−ＰＧＷ５ｂから送られてきたIKE_AUTH ResponseメッセージからＭＳＫの再利用が承認されたことを確認する（例えば、Success Reuse Indicatorフィールド３２０３に格納されている値から判断）。ＵＥ１は、図２０のステップＳ１３０１３で生成したＭＳＫを用いてAUTHパラメータを生成する。ＵＥ１は、生成したAUTHパラメータをIKE_AUTH Requestメッセージに格納して、Ｔ−ＰＧＷ５ｂへ送信する（図２０、ステップＳ１３１０６）。また、ＵＥ１が、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを保持していない、若しくは、使用できない場合は、例えばＡＡＡサーバ８ａなどに問い合わせて、ＭＳＫを取得してもよいし、ＵＥ１自身で再度同じＭＳＫを生成してもよい。
Ｔ−ＰＧＷ５ｂは、IKE_AUTH Requestメッセージを送信したＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）する。ＵＥ１（IKE_SA_INITメッセージの送信元）の認証に成功した場合、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから受信したＭＳＫを用いて作成したAUTHパラメータを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２０、ステップＳ１３１０７）。
なお、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから送られてきたＭＳＫを用いてAUTHパラメータを本ステップＳ１３１０７で作成したが、保持できるのであれば、例えばステップＳ１３１０４以降（ＭＳＫ受信以降）、任意のタイミングで作成してもよい。
ＵＥ１は、IKE_AUTH Responseメッセージを送信したＴ−ＰＧＷ５ｂを認証する（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）。なお、このＴ−ＰＧＷ５ｂ（IKE_SA_INITメッセージの送信元）の認証をするために、ステップＳ１３１０６でＵＥ１が作成したAUTHパラメータや、ステップＳ１３１０１で取得した鍵情報（例えば、共有鍵や通信相手の公開鍵など）を用いてもよい。
ＵＥ１が、Ｔ−ＰＧＷ５ｂの認証ができた場合（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）、ＵＥ１とＴ−ＰＧＷ５ｂの間でＳＡが確立される。なお、このIKE_AUTH Responseメッセージには、ＵＥ１とＴ−ＰＧＷ５ｂの間に確立されるＳＡに必要な情報が送られる。
また、Ｔ−ＰＧＷ５ｂが、ステップＳ１３１０５でＭＳＫを用いたAUTHパラメータを作成して、ＵＥ１に通知することによって、先にＵＥ１がＴ−ＰＧＷ５ｂを認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）して、続いて、ＵＥ１がAUTHパラメータをＴ−ＰＧＷ５ｂに通知してもよい。
また、ＵＥ１とＴ−ＰＧＷ５ｂのお互いの認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）は、ＵＥ１若しくはＴ−ＰＧＷ５ｂのどちらか一方が認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）することで、ＳＡが確立できる場合、又は、ＵＥ１若しくはＴ−ＰＧＷ５ｂの処理負荷軽減などのために、どちらか一方だけが認証するだけでもよい。また、AUTHパラメータ以外を用いて、ＵＥ１とＴ−ＰＧＷ５ｂの認証をすることができるのであれば、AUTHパラメータ以外を用いてもよい。
続いて、IKE_AUTH_Responseメッセージを受信したＵＥ１は、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２０、ステップＳ１３２０１）。
なお、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証のために有用であるが、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合は、これらのBS_Identityを省略することもできる。
また、Ｔ−ＰＧＷ５ｂへの切り替え指示後もＡＡＡサーバ８ａがＵＥ１に対する状態を保持できる場合には、ＵＥ１が通知するReuse Indicatorも省略することができる。この場合、ＡＡＡサーバ８ａは、ＵＥ１の固定情報（例えば、ＩＭＳＩなど）などを基にＵＥ１の識別を行い、保持しておいたＵＥ１に対する状態に基づいて鍵データ（例えば、ＭＳＫなど）を抽出し、Ｔ−ＰＧＷ５ｂに通知することができる。ただし、一部のＡＡＡサーバ８ａにおいては、切り替え指示後はＵＥ１に対する状態を解消することも想定されるため、汎用性を確保する目的でReuse IndicatorをＵＥ１から通知することは有用である。
以上の動作によって、従来技術のPDN GW reallocation procedureでは、ＵＥ１とＡＡＡサーバとの８ａ間においてＩ−ＰＧＷ５ａとＴ−ＰＧＷ５ｂで計２回のＵＥ認証（Full Authentication）を実施する必要があったが、上述したように鍵の再利用を行うことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続する際のブートストラップ処理のメッセージ数削減と切り替え時間の短縮を図ることができるようになる。
なお、過去にＵＥ１が他のＰＧＷ５とＳＡ確立を実施した実績がある場合、ＵＥ１に対するＰＧＷ５の切り替え要求（すなわち切り替え先ＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスの通知）は、上記説明したステップＳ１３０１４より前に実施することも可能である（例えば、図２０のステップＳ１３００７など）。例えば、ＵＥ１は、ステップＳ１３１０２で送信されるReuse IndicatorをステップＳ１３００３のIKE AUTH Requestメッセージに含めて送信する。このReuse Indicatorを参照したＩ−ＰＧＷ５ａは、ステップＳ１３００４〜Ｓ１３００６の処理において、ステップＳ１３１０３及びＳ１３１０４と同様の手順で、ＵＥ１に対して確立済みの鍵をＡＡＡサーバ８ａから取得する（このとき同時に切り替え先ＰＧＷ５のアドレスも取得することになる）。そして、Ｉ−ＰＧＷ５ａは、ステップＳ１３００７で切り替え先ＰＧＷ５のアドレスを含むIKE_AUTH responseメッセージ（すなわち、上記のステップＳ１３１０５で送信されるIKE_AUTH responseメッセージと同等のメッセージ）をＵＥ１へ送信することによって、切り替え先ＰＧＷ５のアドレスをＵＥ１に通知することが可能となる。これにより、ＵＥ１は過去に確立した鍵を再利用して高速に切り替え先ＰＧＷ５のアドレスを取得することができ、ひいては本来接続を希望しないＰＧＷ５が割り当てられた場合でも、所望のＰＧＷ５への切り替え接続を高速に実施することができる。
また、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂへの切り替えを指示するタイミング（図２０、ステップＳ１３０１０）で、生成したＭＳＫをＴ−ＰＧＷ５ｂに通知してもよい。具体的には、図２１を用いて説明する。
図２１は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第２のシーケンス図である。図２１には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図２１の処理フローのステップＳ１４００１〜Ｓ１４０１０は、図２０の処理フローのステップＳ１３００１〜Ｓ１３０１０と同一であるので説明を省略する。このステップＳ１４０１０を送信する段階で、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂにＭＳＫを通知することが可能である。ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知する手法としては、例えば、Ｉ−ＰＧＷ５ａにUE_BS_Identityを格納したAuthentication-Answerメッセージを送信する処理と同時に、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立処理の過程で生成したＭＳＫと、UE_BS_Identityに対応するT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに送信する（図２１、ステップＳ１４０１１）。
図２１のステップＳ１４０１１においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージは、本発明の第３の実施の形態における図１５のステップＳ１１０１１で用いるメッセージ（図１９に図示されているBS_Identity通知メッセージのフォーマット例）と同様であるので説明を省略する。なお、BS_Identity通知メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いてもよい。また、BS_Identity通知メッセージに、ＵＥ１の固定情報（例えば、ＩＭＳＩなど）を含めてもよく、これによりＴ−ＰＧＷ５ｂがＵＥ１からIKE_AUTH Requestメッセージを受信したとき、そのＵＥ１に関してフル認証が完了しているＵＥ１なのかを判別しやすくなり、より確実にＵＥ１を照合することが可能となる。このＵＥ１の固定情報のみで、フル認証済みであることが判別でき、ＵＥ１を照合することができる場合、このIKE_AUTH Responseメッセージで用いるＵＥアドレスフィールド５００４は省略してもよい。
続く図２１の処理フローのステップＳ１４０１２〜Ｓ１４１０２は、図２０の処理フローのステップＳ１３０１１〜Ｓ１３１０２と同一であるので説明を割愛する。
Reuse indicatorとUE_BS_Identityが格納されたIKE_AUTH Requestメッセージ（図２１、ステップＳ１４１０２）を受信したＴ−ＰＧＷ５ｂは、ステップＳ１４０１１でＡＡＡサーバ８ａから受信したT-PGW_BS_Identityと、ＵＥ１とＴ−ＰＧＷ５ｂ間でＭＳＫの再利用の許可を示したパラメータ（例えば、Success Reuse Indicatorフィールド３２０３の値）を格納したIKE_AUTH ResponseメッセージをＵＥ１に返信する（図２１、ステップＳ１４１０３）。なお、Ｔ−ＰＧＷ５ｂは、ステップＳ１４１０２で受信したUE_BS_IdentityとステップＳ１４０１１で受信したT-PGW_BS_Identityとが正しく対応するものであるか確認してもよい（例えば、ハッシュ値の検算や、ネットワーク上のBS_Identityリストを管理しているデータベースへの問合せなど）。また、ＵＥ１はＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを保持しているので、Ｔ−ＰＧＷ５ｂは、ステップＳ１４１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納して通知する必要はない。ただし、例えば、ＵＥ１が何らかの理由でＭＳＫを保持していない（例えば、既に廃棄しているなど）可能性も考えられるので、Ｔ−ＰＧＷ５ｂが、ステップＳ１４１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納してＵＥ１へ通知して、ＵＥ１がＭＳＫを確実に把握できるようにしてもよい。また、ＭＳＫではなく、ＭＳＫを生成するための材料を通知してもよい。
図２１のステップＳ１４１０３で送信するIKE_AUTH Responseメッセージのフォーマットとしては、図１７Ｃに図示されているフォーマット例を用いることが可能である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３２０１に加えて、ＢＳ識別子（UE_BS_Identity/T-PGW_BS_Identity）フィールド３２０２、Success Reuse Indicatorフィールド３２０３を設け、それぞれの値をＵＥ１に通知することができる。また、Ｔ−ＰＧＷ５ｂは、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してＭＳＫの再利用やT-PGW_BS_Identityを示してＵＥ１に通知してもよい。または、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコルのEAP Successを用いることで、ＭＳＫの再利用をＵＥ１に通知してもよい。なお、本応答メッセージは、ＵＥ１がＭＳＫの再利用を確認できるメッセージであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。また、Ｔ−ＰＧＷ５ｂからＵＥ１にＭＳＫを送信する場合は、このメッセージにＭＳＫフィールドを設けてもよい（不図示）。
IKE_AUTH Responseメッセージを受信したＵＥ１は、例えばIKE_AUTH ResponseメッセージのSuccess Reuse Indicatorフィールド３２０３に格納されている値から、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用をできるか判断する。ここで、ＵＥ１がＭＳＫの再利用をできると判断したとき、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いてAUTHパラメータを作成する。ＵＥ１は、この作成したAUTHパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する（図２１、ステップＳ１４１０４）。なお、ＵＥ１は、Ｉ−ＰＧＷ５ａにAUTHパラメータを以前に（ステップＳ１４０１４において）通知しているため、そのときに作成したAUTHパラメータを再利用してもよい。
IKE_AUTH Requestメッセージを受信したＴ−ＰＧＷ５ｂは、ステップＳ１４０１１でＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する。続いて、Ｔ−ＰＧＷ５ｂは、IKE_AUTH Requestメッセージを送信したＵＥ１を認証する（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）。
Ｔ−ＰＧＷ５ｂが、ＵＥ１を認証した場合（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認などができた場合）、Ｔ−ＰＧＷ５ｂは、IKE_AUTH ResponseメッセージをＵＥ１に送信する（図２１、ステップＳ１４１０５）。
また、Ｔ−ＰＧＷ５ｂは、ＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）をした後、先にＴ−ＰＧＷ５ｂが作成したAUTHパラメータをIKE_AUTH Responseメッセージに格納する。
なお、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから送られてくるＭＳＫを用いずに、ＵＥ１を認証できる場合（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認などできる場合）には、ＭＳＫを用いない認証の方法を用いてもよい。Ｔ−ＰＧＷ５ｂは、このIKE_AUTH Responseメッセージに格納するAUTHパラメータをステップＳ１４１０５で作成しているが、ステップＳ１４０１１でＡＡＡサーバ８ａからＭＳＫを受信後、どのタイミングで作成してもよい。また、Ｔ−ＰＧＷ５ｂが、ＵＥ１を認証する際（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認などをする際）に、Ｔ−ＰＧＷ５ｂが先に生成したAUTHパラメータを用いているが、このAUTHパラメータを用いずに確認できるのであれば、他の方法を用いて正確性を確認してもよい。
続いて、IKE_AUTH Responseメッセージを受信したＵＥ１は、IKE_AUTH Responseメッセージを送信したＴ−ＰＧＷ５ｂを認証する（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）。なお、ＵＥ１は、Ｔ−ＰＧＷ５ｂを認証する際にステップＳ１４１０４で使用したAUTHパラメータや、ステップＳ１４１０１で取得した鍵情報（例えば、共有鍵や通信相手の公開鍵など）を用いてもよい。
なお、ＵＥ１によるＴ−ＰＧＷ５ｂの認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）は、Ｔ−ＰＧＷ５ｂによるＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認）のみで、ＳＡが確立できる場合、又は、ＵＥ１の処理負荷軽減などのために省略してもよい。なお、ＵＥ１は、ＵＥ１が持つＭＳＫを用いずに、Ｔ−ＰＧＷ５ｂを認証できる場合（例えば、ＵＥ１が持つUE_BS_Identityと、Ｔ−ＰＧＷ５ｂが持つT-PGW_BS_Identityの関連性の有無などを使用して認証できる場合）には、ＭＳＫを用いない認証の方法を用いてもよい。
Ｔ−ＰＧＷ５ｂ（IKE_SA_INITメッセージの送信元）の認証に成功した場合、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２１、ステップＳ１４２０１）。
このように、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを事前に通知しておくことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続した時に、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得する場合に比べて、高速な切り替え接続が可能となる。
なお、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知するより先に、ＵＥ１からのIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂが受信／処理してしまうと、Ｔ−ＰＧＷ５ｂは再度ＵＥ１に対するフル認証処理をＡＡＡサーバ８ａに要求してしまい、接続までに要する時間が増大することになる。これを回避するため、ＵＥ１は図１４で説明したReuse indicatorを含めたIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信し（図２１、ステップＳ１４１０２）、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得していなければ、ＡＡＡサーバ８ａに問い合わせるようにしてもよい。これにより、より確実にＭＳＫの再利用を行うことができるとともに、切り替え接続の高速化を図ることができる。
また、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証を行うため（例えば、ＵＥ１になりすました偽ＵＥ１が、Ｔ−ＰＧＷ５ｂに不正アクセスして、ＵＥ１とＴ−ＰＧＷ５ｂ間のＳＡに関する情報の取得を回避するため）や、ＡＡＡサーバ８ａにおいて、今回ＵＥ１からの接続要求が、先に指示されたＴ−ＰＧＷ５ｂへの切り替え接続によるものであるか、あるいは新規ＰＧＷ５への接続のためのものであるかを判別して確実にＭＳＫの再利用を実施するために有用である。一方、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合、またＡＡＡ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えによるものであることの確認がとれる場合などにおいては、これらのBS_Identityを省略することもできる。
また、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、PDN GW reallocationが複数発生したときにも有用である。例えば、ＵＥ１が最初に発見したＰＧＷ（Ｉ−ＰＧＷ５ａ）とアタッチ処理をしている際にPDN GW reallocationが起こり、ＵＥ１はＩ−ＰＧＷ５ａからＰＧＷ５（Ｉ’−ＰＧＷ）のアドレスを受信する。しかし、改めてＵＥ１がＳＡを確立しようとしたＩ’−ＰＧＷが、ＵＥ１が３Ｇアクセス２で接続しているＴ−ＰＧＷ５ｂとは異なる別のＰＧＷ５の場合である。この場合、ＵＥ１は、Ｉ’−ＰＧＷとＭＳＫを再利用してＳＡを確立しようとするが、ＡＡＡサーバ８ａから再度ＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスが通知される可能性がある。このＵＥ１がＴ−ＰＧＷ５ｂとアタッチ処理を実施するとき、ＵＥ１は、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫ、若しくは、ＵＥ１とＩ’−ＰＧＷの間でＳＡを確立した際に生成したＭＳＫを再利用してもよい。このとき、ＵＥ１は、どちらのＭＳＫを再利用するか示すためにUE_BS_Identity並びにT-PGW_BS_Identityを用いてもよい。
またさらには、理想状態において、Ｔ−ＰＧＷ５ｂはＵＥ１からIKE_AUTH Requestメッセージを受信する前にＡＡＡサーバ８ａからＵＥ１向けの鍵（例えば、ＭＳＫ）を取得することができ、この時点で鍵の再利用を認識することができるため、ＵＥ１が通知するReuse Indicatorも省略することができる。ただし、先に説明したようにＡＡＡサーバ８ａからの通知がＵＥ１からのIKE_AUTH Requestメッセージ到着より遅れることも想定し、Ｔ−ＰＧＷ５ｂに対して従来のシーケンスに基づく処理ではなく鍵を再利用するためのシーケンスに基づく処理を促す目的でReuse Indicatorを付加することは有用である。
なお、上述の第２の実施の形態で説明したように、ＵＥ１は、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５であるＴ−ＰＧＷ５ｂのアドレスを通知されるかもしれない（図１３のステップＳ９１０７）。しかしながら、第２の実施の形態では、ＵＥ１がＡＡＡサーバ８ａの状態を解消するためにステップＳ９１０８〜Ｓ９１１２を実施するものであったが、実質このステップ区間においてＡＡＡサーバ８ａによる認証処理（ＭＳＫ生成）を完了させて、Ｔ−ＰＧＷ５ｂとの切り替え接続時に認証データ（ＭＳＫなど）を再利用したほうが、総じて処理時間の短縮効果が大きいと考えられる。よって、本第４の実施の形態に対応するＵＥ１が、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５のアドレスを通知された場合は、図２０のステップＳ１３００８（若しくは、図２１のステップＳ１４００８）でＡＡＡサーバ８ａの状態解消を要求せず、引き続き認証処理を継続してもよい。すなわち、図１３のステップＳ９１０８以降の処理は、図２０のステップＳ１３００８（若しくは、図２１のステップＳ１４００８）以降に置き換えられるが、既にＴ−ＰＧＷ５ｂのアドレスはステップＳ１３００７（若しくは、ステップＳ１４００７）でＵＥ１に通知されているので、図２０のステップＳ１３０１４（若しくは、図２１のステップＳ１４０１５）で再度通知する必要はない。
本発明の第４の実施の形態では、ＵＥ１とＩ−ＰＧＷ５ａ間のＳＡを確立した際に生成したＭＳＫを再利用することで、ＵＥ１とＴ−ＰＧＷ５ｂ間のＳＡを確立する際に必要であったメッセージを削減することができた。また、そのメッセージのやりとり、処理をすることに要する時間を短縮することができた。
ＵＥ１は、ＭＳＫを再利用する以外に、ＵＥ１とＰＧＷ５間で生成する共有鍵（例えば、SKEYSEEDなど）（上記した非特許文献７を参照）を再利用することで、PDN GW reallocationが起こった際、共有鍵などを生成・取得するステップ（例えば、図２０のステップＳ１３１０１に相当）などを省略することができる。例えば、PDN GW reallocationが起こり、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立して（図２０のステップＳ１３００１〜ステップＳ１３０１４）、ＵＥ１はＩ−ＰＧＷ５ａから受信したＴ−ＰＧＷ５ｂとＳＡを確立しようとする。このとき、ＵＥ１が、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成した共有鍵（例えば、SKEYSEEDなど）を再利用することで、ＵＥ１とＴ−ＰＧＷ５ｂ間の共有鍵を生成するステップなどを省略することができる。また、理想状態（Ｔ−ＰＧＷ５ｂが共有鍵の再利用を許可する状態）であれば、ＵＥ１がＴ−ＰＧＷ５ｂに共有鍵の再利用を示すメッセージを通知するだけで他のメッセージを省略することができる。
また、同様にＵＥ１とＰＧＷ５の間の共有鍵（例えば、SKEYSEEDなど）やＭＳＫは、ＰＧＷ５毎に生成するが、パケットの暗号化に用いる鍵（SK_ei、SK_erなど）を再利用することで、任意の鍵生成のステップを省略してもよい。この場合、新しく鍵を生成するか、再利用するかを切り替えることで、セキュリティレベルが上がり、ＵＥ１とＰＧＷ５間の鍵情報を傍受しようとしているノードによる情報漏洩の可能性を低減することができる。
また、ＵＥ１はＭＳＫの再利用を示したIKE_AUTH Requestメッセージ（図２０、ステップＳ１３１０２）に、Ｉ−ＰＧＷ５ａとのＳＡを確立した際に生成したＭＳＫを用いて作成するAUTHパラメータを格納して、Ｔ−ＰＧＷ５ｂに通知してもよい。具体的には、図２４を用いて説明する。
図２４は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第３のシーケンス図である。図２４には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図２４の処理フローのステップＳ１７００１〜Ｓ１７１０１は、図２０の処理フローのステップＳ１３００１〜Ｓ１３１０１と同一であるので説明を省略する。
続いて、ＵＥ１は、ＭＳＫの再利用が示されたReuse Indicatorなどを含むIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する。このとき、ＵＥ１は、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いて作成したAUTHパラメータも一緒に格納して、Ｔ−ＰＧＷ５ｂに通知する（図２４、ステップＳ１７１０２）。
Ｔ−ＰＧＷ５ｂは、IKE_AUTH RequestメッセージにAUTHパラメータが格納されていることを確認したとき、ＵＥ１がＥＡＰ（Extended Authentication Protocol）を用いず、一般的なＩＫＥｖ２プロトコルを用いたＳＡ確立方法を示していることを判断する（上記した非特許文献７を参照）。また、ＵＥ１が、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を示した値（IKE_AUTH Requestメッセージに格納されているReuse Indicatorフィールド３００２で、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を示した値、若しくはReuse Indicatorフィールド３００２以外でＭＳＫの再利用を示した値に相当するパラメータ）が格納されていると判断した場合は、Ｔ−ＰＧＷ５ｂはＡＡＡサーバ８ａにステップＳ１７１０２で受信したReuse IndicatorとUE_BS_Identityを格納したAuthentication-Requestメッセージを送信する（図２４、ステップＳ１７１０３）。なお、Reuse Indicatorを用いず、例えば、ＡＵＴＨパラメータをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに通知することで、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＭＳＫの再利用を示しているということが確認できる場合、Reuse Indicatorは省略することができる。また、ＡＡＡサーバ８ａが、ＵＥ１の固有情報（例えば、ＩＭＳIなど）を用いることで、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを取得できる場合は、UE_BS_Identityも省略することができる。
図２４の処理フローのステップＳ１７１０４は、図２０の処理フローのステップＳ１３１０４と同一であるので説明を省略する。
ステップＳ１７１０４でＡＡＡサーバ８ａからＭＳＫを受信したＴ−ＰＧＷ５ｂは、AUTHパラメータが格納されたIKE_AUTH Requestメッセージを送信してきたＵＥ１の認証を行う（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）。なお、Ｔ−ＰＧＷ５ｂが、ＡＡＡサーバ８ａから受信したＭＳＫを用いずにＵＥ１を認証できる場合、ＭＳＫを用いる必要はない。また、この場合、ＵＥ１の認証処理をステップＳ１７１０２後に行ってもよい。なお、Ｔ−ＰＧＷ５ｂはＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いてもよく、また、受信したＭＳＫを用いて計算するＡＵＴＨパラメータを用いてもよい。
Ｔ−ＰＧＷ５ｂは、ＵＥ１の認証を完了した後、ＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを計算し、IKE_AUTH Responseメッセージに格納して、ＵＥ１に送信する（図２４、ステップＳ１７１０５）。なお、ＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いて生成するAUTHパラメータを用いる場合は、ＵＥ１を認証する前にAUTHパラメータを計算してもよい。また、Ｔ−ＰＧＷ５ｂはステップＳ１７１０４でＭＳＫと一緒に受信したT-PGW_BS_IdentityもIKE_AUTH Responseメッセージに格納してＵＥ１に送信する。
AUTHパラメータとT-PGW_BS_Identityが格納されたIKE_AUTH Responseメッセージを受信したＵＥ１は、Ｔ−ＰＧＷ５ｂを認証する（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）。ＵＥ１が、Ｔ−ＰＧＷ５ｂを認証した場合、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２４、ステップＳ１７２０１）。
また、本発明の第４の実施の形態における第２のシーケンス（図２１）のようにＡＡＡサーバ８ａがＩ−ＰＧＷ５ａにＴ−ＰＧＷ５ｂのＩＰアドレスを通知する（図２１、ステップＳ１４０１０）と同時に、Ｔ−ＰＧＷ５ｂへＵＥ１とＩ−ＰＧＷ５ａ間でＳＡを確立した際に生成したＭＳＫとT-PGW_BS_Identityを通知する（図２１、ステップＳ１４０１１）場合も同様である。詳しくは、図２５を用いて説明する。
図２５は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第４のシーケンス図である。図２５には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図２５の処理フローのステップＳ１８００１〜Ｓ１８１０１は、図２１の処理フローのステップＳ１４００１〜Ｓ１４１０１と同一であるので説明を省略する。
続いて、ＵＥ１は、ＭＳＫの再利用が示されたReuse Indicatorなどを含むIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する。このとき、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いて作成したAUTHパラメータを格納して、Ｔ−ＰＧＷ５ｂに通知する（図２５、ステップＳ１８１０２）。なお、Reuse Indicatorを用いず、例えば、ＡＵＴＨパラメータをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに通知することで、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＭＳＫの再利用を示しているということが確認できる場合、Reuse Indicatorは省略することができる。また、Ｔ−ＰＧＷ５ｂが、ＵＥ１の固有情報（例えば、ＩＭＳIなど）を用いることで、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を示していることが確認できる場合は、UE_BS_Identityも省略することができる。
AUTHパラメータなどを含むIKE_AUTH Requestメッセージを受信したＴ−ＰＧＷ５ｂは、ＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）を行う。なお、Ｔ−ＰＧＷ５ｂはＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いてもよく、また、受信したＭＳＫを用いて計算するＡＵＴＨパラメータを用いてもよい。また、ＵＥ１を認証する際、ＡＡＡサーバ８ａから受信したＭＳＫ以外を用いてＵＥ１を認証できる場合は、Ｔ−ＰＧＷ５ｂはＭＳＫ以外を用いてＵＥ１を認証してもよい。
ＵＥ１の認証ができた場合、Ｔ−ＰＧＷ５ｂはＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する。なお、ＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いて生成するAUTHパラメータを用いる場合は、ＵＥ１を認証する前にAUTHパラメータを計算してもよい。そして、ＵＥ１は、作成したAUTHパラメータや、ＵＥ１とＴ−ＰＧＷ５ｂの間のＳＡ確立に必要なパラメータなどを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２５、ステップＳ１８１０３）。なお、ＵＥ１が、T-PGW_BS_IdentityパラメータなしでＴ−ＰＧＷ５ｂを認識することができる場合（例えば、IKE_AUTH Responseメッセージに格納されているＡＵＴＨパラメータを復号可能な場合）、Ｔ−ＰＧＷ５ｂは、T-PGW_BS_Identityを省略することができる。
AUTHパラメータなどが格納されたIKE_AUTH Responseメッセージを受信したＵＥ１は、Ｔ−ＰＧＷ５ｂの認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）を行う。Ｔ−ＰＧＷ５ｂの認証ができた場合、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２５、ステップＳ１８２０１）。
図２４や図２５の処理フローに示されているように、ＵＥ１が、ステップＳ１７１０２やステップＳ１８１０２で、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いて作成したAUTHパラメータをＴ−ＰＧＷ５ｂに送ることによって、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＥＡＰを用いたＢＳ処理ではなく、一般的なＩＫＥｖ２プロトコルを用いてＴ−ＰＧＷ５ｂとの間のＳＡ確立を希望していると判断できる。また、Reuse Indicator若しくはReuse Indicator相当のパラメータを受信することによって、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を希望していることを確認でき、ＡＡＡサーバ８ａから受信したＭＳＫを用いて作成したAUTHパラメータをＵＥ１に送信することが可能となる。その結果、ＵＥ１とＴ−ＰＧＷ５ｂは、図２０や図２１の処理フローにおいて必要であったメッセージ（例えば、図２０のステップＳ１３１０６〜Ｓ１３１０７や、図２１のステップＳ１４１０４〜Ｓ１４１０５）を省略してＳＡを確立することができる。
次に、本発明の第４の実施の形態における移動端末（ＵＥ１）の構成と処理フローについて説明する。本発明の第４の実施の形態における移動端末（ＵＥ１）の構成は、本発明の第１〜第３の実施の形態における移動端末（ＵＥ１）の構成（図３を参照）と同様であるので説明を省略する。
以下、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図２２と図２６を用いて詳しく説明する。図２２と図２６は、本発明の第４の実施の形態におけるＵＥ１の構成の一例を示す図であり、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２（ホームリンク）に接続済みであり、Ｔ−ＰＧＷ５ｂに接続しているものとする。
図２２のＵＥ１の処理フローのステップＳ１５００１〜Ｓ１５０１３は、図１６のＵＥ１の処理フローのステップＳ１２００１〜Ｓ１２０１３と同一であるので説明を省略する。
ＵＥ１は、Ｔ−ＰＧＷ５ｂから送られてきたT-PGW_BS_Identityと、ＵＥ１が生成・取得したT-PGW_BS_Identityが一致しているか、若しくは関連性があるか確認する（ステップＳ１５０１４）。そして、ＭＳＫの再利用の許可（例えば、IKE_AUTH Responseメッセージ（図２０のステップＳ１３１０５など）にEAP Successが格納されているかなど）が示されているか確認する（ステップS１５１０５）。T-PGW_BS_Identityが一致しているか、若しくは関連性があるうえで、ＭＳＫの再利用の許可が示されていた場合、ＵＥ１は、Ｔ−ＰＧＷ５ｂに送信するためのAUTHパラメータを、Ｉ−ＰＧＷ５ａとＳＡを確立する際に生成したＭＳＫを用いて作成する（ステップＳ１５１２０）。一方、一致しなかった場合には、ＵＥ１は、受信したIKE_AUTH Responseメッセージを破棄する（図２２、ステップＳ１５０４０）。
続いて、ＵＥ１は、ステップＳ１５１２０で作成したAUTHパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する（図２２、ステップＳ１５１２１）。そして、ＵＥ１は、Ｔ−ＰＧＷ５ｂから送られてくるIKE_AUTH Responseメッセージを受信する（図２２、ステップＳ１５１２２）。
ＵＥ１は、ステップＳ１５１２２でIKE_AUTH Responseメッセージを送信したＴ−ＰＧＷ５ｂを認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）する（図２２、ステップＳ１５１２３）。ＵＥ１が、Ｔ−ＰＧＷ５ｂを認証できた場合（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）には、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２２、ステップＳ１５１３０）。また、ＵＥ１が認証できなかった場合には、Ｔ−ＰＧＷ５ｂから受信したIKE_AUTH Responseメッセージを破棄する（図２２、ステップＳ１５０４０）。
なお、ＵＥ１が、Ｔ−ＰＧＷ５ｂを信頼することができる場合（例えば、T-PGW_BS_Identityが格納されている場合など）、あるいは、Ｔ−ＰＧＷ５ｂを認証する必要がない場合（例えば、例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認などが既知、もしくは省略できる場合）には、ステップＳ１５１２３は省略することができ、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する。また、Ｔ−ＰＧＷ５ｂによるＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）のみで相互の確認ができる場合は、ステップＳ１５１２３を省略してもよい。
なお、ＵＥ１が、ステップＳ１５００６で受信したIKE_AUTH Responseメッセージの中にＴ−ＰＧＷ５ｂのアドレスとUE_BS_Identityが格納されていなかった場合は、ＰＧＷ５の切り替えを要求されなかったことであることから、確立したＳＡを用いてＩ−ＰＧＷ５ａとＢＵ／ＢＡ交換を実施する（図２２、ステップＳ１５０３０）。
なお、本発明の第４の実施の形態における第３と第４のシーケンスにおいて、ＵＥ１がＴ−ＰＧＷ５ｂにＡＵＴＨパラメータを通知する場合（例えば、図２４のステップＳ１７１０２や図２５のステップＳ１８１０２）は、図２６に示すようにＵＥ１がＴ−ＰＧＷ５ｂとIKE_SA_INITメッセージを交換後（図２６、ステップＳ１９０１０）、Reuse Indicatorを生成するとともに、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いてＡＵＴＨパラメータを生成する。なお、ステップＳ１９０１１とステップＳ１９０１２を処理する順番は逆でも構わない。
続いて、ＵＥ１は、生成したReuse IndicatorとＡＵＴＨパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する（図２６、ステップＳ１９０１３）。
IKE_AUTH Responseメッセージを受信した後（図２６、ステップＳ１９０１４）、ＵＥ１はＴ−ＰＧＷ５ｂを認証する（図２６、ステップＳ１９０１５）。
その後、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２６、ステップＳ１９０２０）。
次に、本発明の第４の実施の形態におけるＰＧＷ５の構成と処理フローについて説明する。本発明の第４の実施の形態におけるＰＧＷ５の構成は、本発明の第１〜第３の実施の形態におけるＰＧＷ５の構成（図８を参照）と同様であるので説明を省略する。
以下、図８に図示されている構成を有するＰＧＷ５の処理フローについて、本発明における特徴的な処理を実施する接続制御部２０５に係る処理を中心に、図２３Ａと図２３Ｂと図２７を用いて詳しく説明する。なお、ＰＧＷ５は、既に通信部２０１を介し、３Ｇアクセス２（ホームリンク）に接続済みであるものとする。また、ＵＥ１が最初にアタッチ（接続）処理を試みるＰＧＷ５は、Ｉ−ＰＧＷ５ａとする。
図２３Ａは、本発明の第４の実施の形態におけるＰＧＷ５のＩ−ＰＧＷ５ａとしての処理フローの一例を示すフロー図である。本発明によるＰＧＷ５は、ＵＥ１とＳＡを確立するためにＵＥ１からのＢＳ処理（例えば、図２０のステップＳ１３００２や、ステップＳ１３００３など）を待つ。ＵＥ１はＩ−ＰＧＷ５ａとアタッチ（接続）処理を接続手順に従って開始する。
ＵＥ１が、例えばＮ３Ｇアクセス３に接続して、ＵＥ１が接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）がＤＮＳなどから割り当てられる際、ＵＥ１がＩ−ＰＧＷ５ａとアタッチ（接続）処理をしているときにネットワーク側（例えば、ＡＡＡサーバ８ａやＰＧＷ５など）の判断によってPDN GW reallocationが起こる（ＰＧＷ５を切り替える指示（例えば、Ｔ−ＰＧＷ５ｂのアドレスなど）がＵＥ１に通知される）（図２３Ａ、ステップＳ１６００１）。
従来技術のPDN GW reallocationでは、ＡＡＡサーバ８ａが図１４のステップＳ９０１０（若しくは、それ以前のステップ）でPDN GW reallocationの決定をして、Ｔ−ＰＧＷ５ｂのアドレスをＰＧＷに通知している（上記の非特許文献２を参照）。そこで、本発明の第４の実施の形態でも、説明の都合上、ＡＡＡサーバ８ａがPDN GW reallocationの決定をすることとする。
Ｉ−ＰＧＷ５ａは、ＡＡＡサーバ８ａがPDN GW reallocationの決定をした際、ＰＧＷ５の切り替え先であるＴ−ＰＧＷ５ｂのアドレスと、ＵＥ１とＩ−ＰＧＷ５ａの間で用いるＭＳＫと、ＡＡＡサーバ８ａがＵＥ１を一度フル認証したことを証明する証明書（例えば、UE_BS_Identityなど）をＡＡＡサーバ８ａから受信する（図２３Ａ、ステップＳ１６００２）。なお、ここでは、説明の都合上、ＡＡＡサーバ８ａがＵＥ１を一度フル認証したことを証明する証明書をUE_BS_Identityとする。
続いて、Ｉ−ＰＧＷ５ａは、ＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）（図２０のステップＳ１３０１３）するためや、ＵＥ１がＩ−ＰＧＷ５ａを認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）するために、ＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する（図２３Ａ、ステップＳ１６００３）。
Ｉ−ＰＧＷ５ｂは、ＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）できた場合、Ｔ−ＰＧＷ５ｂのアドレスと、UE_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２３Ａ、ステップＳ１６００４）。
一方、図２３Ｂは、本発明の第４の実施の形態におけるＰＧＷ５のＴ−ＰＧＷ５ｂとしての処理フローの一例を示すフロー図である。Ｔ−ＰＧＷ５ｂのアドレスを受信したＵＥ１は、PDN GW reallocationが起こったことを検出する。続いて、ＵＥ１は、Ｔ−ＰＧＷ５ｂとアタッチ（接続）処理を開始するために、IKE_SA_INITメッセージを送信する。
Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてきたIKE_SA_INITメッセージを受信する（図２３Ｂ、ステップＳ１６０１０）。続いて、Ｔ−ＰＧＷ５ｂは、IKE_SA_INITメッセージに格納されていたＮｏｎｃｅｓや、IKE_SA_INITメッセージ交換時に実施されるDiffie-Hellman鍵交換で生成・取得した共有鍵（例えば、SKEYSEED）を用いて、ＵＥ１とＴ−ＰＧＷ５ｂの間で用いるパケットの暗号化をするための鍵（例えば、SK_eiやSK_er）などを生成する（図２３Ｂ、ステップＳ１６０１１）。また、この時、IKE_AUTHメッセージに格納されるAUTHパラメータを認証するためのパラメータ（例えば、お互いの公開鍵など）を交換してもよい。なお、ＵＥ１とＴ−ＰＧＷ５ｂの間で用いる鍵生成は、ＮｏｎｃｅｓやDiffie-Hellman鍵交換で共有される鍵以外を用いてもよく、これらに限定されていない。
IKE_SA_INITメッセージ交換が終了した後、Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてくるIKE_AUTH Requestメッセージを受信する（図２３Ｂ、ステップＳ１６０１２）。Ｔ−ＰＧＷ５ｂは、ＵＥ１から受信したIKE_AUTH RequestメッセージのReuse Indicatorフィールド３００２に格納されているＭＳＫの再利用を示した値（例えば、Reuse keyなど）、若しくはＭＳＫの再利用を示す値に相当するものが格納されているか確認する（図２３Ｂ、ステップＳ１６０１３）。
このとき、Reuse keyなどのＭＳＫの再利用を示す値（若しくは、これに相当するもの）が格納されていなかった場合は、一般的なＢＳ処理を開始する。なお、Ｔ−ＰＧＷ５ｂが、フル認証をしたことを証明するUE_BS_Identityのみで、ＵＥ１がＭＳＫの再利用を希望していることを確認できる場合には、このReuse Indicatorフィールドは使用されない。
一方、Reuse keyなどのＭＳＫの再利用を示す値（若しくは、これに相当するもの）が格納されている場合は、ステップＳ１６０１２で受信したReuse keyとUE_BS_Identityを格納したAuthentication-Request/IdentityメッセージをＡＡＡサーバ８ａに送信する（図２３Ｂ、ステップＳ１６１００）。ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから送られてきたUE_BS_Identityと対応するＭＳＫとT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに送信する。なお、Ｉ−ＰＧＷ５ａからデータの暗号化などに用いる鍵（例えば、SK_eやSK_iなど）がＡＡＡサーバ８ａに転送され、かつ、ネットワーク側でデータの暗号化などに用いる鍵もＵＥ１とＴ−ＰＧＷ５ｂ間で再利用してよいという判断が下された場合に限り、その鍵情報（例えば、SK_eやSK_iなど）も同時にＴ−ＰＧＷ５ｂに送信してもよい。
Ｔ−ＰＧＷ５ｂは、ＭＳＫとT-PGW_BS_Identityなどが格納されたAuthentication_AnswerメッセージをＡＡＡサーバ８ａから受信する（図２３Ｂ、ステップＳ１６１０１）。続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する（図２３Ｂ、ステップＳ１６１０２）。Ｔ−ＰＧＷ５ｂは、ＭＳＫの再利用が可能であることを示すと同時にＴ−ＰＧＷ５ｂのなりすまし防止などを目的とするT-PGW_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２３Ｂ、ステップＳ１６１０３）。
ＵＥ１は、ＭＳＫの再利用が可能であることを確認した後、ＵＥ１が持つＭＳＫを用いてAUTHパラメータを作成する。続いて、ＵＥ１は、そのAUTHパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する。Ｔ−ＰＧＷ５ｂは、ＵＥ１からIKE_AUTH Responseメッセージを受信する（図２３Ｂ、ステップＳ１６１０４）。
続いて、Ｔ−ＰＧＷ５ｂは、IKE_AUTH Responseメッセージを送信したＵＥ１を認証する（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）（図２３Ｂ、ステップＳ１６１０５）。このとき、Ｔ−ＰＧＷ５ｂは、ステップＳ１６１０２で作成したAUTHパラメータを比較対象として用いてもよい。なお、Ｔ−ＰＧＷ５ｂによるAUTHパラメータの作成は、ステップＳ１６１０２で行われたが、ＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）する直前に生成してもよい。また、このＵＥ１の認証をする際に、Ｔ−ＰＧＷ５ｂが生成するAUTHパラメータを用いない場合、このAUTHパラメータの生成は、Ｔ−ＰＧＷ５ｂがAUTHパラメータをＵＥ１に送信するステップＳ１６２００の直前でもよい。
Ｔ−ＰＧＷ５ｂがＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）をできた場合、Ｔ−ＰＧＷ５ｂはステップＳ１６１０２で作成したAUTHパラメータなどを含むIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２３Ｂ、ステップＳ１６２００）。続いて、Ｔ−ＰＧＷ５ｂは、ＵＥ１とＢＵ／ＢＡ交換を実施する（図２３Ｂ、ステップＳ１６２０１）。なお、Ｔ−ＰＧＷ５ｂが、ＵＥ１の認証をできなかった場合は、ＢＳ処理を終了する。
なお、本発明の第４の実施の形態における第３と第４のシーケンスにおいて、Ｔ−ＰＧＷ５ｂが、IKE_SA_INITメッセージ交換直後にＵＥ１からIKE_AUTH RequestメッセージでＡＵＴＨパラメータを通知される場合（例えば、図２４のステップＳ１７１０２や図２５のステップＳ１８１０２）は、Ｔ−ＰＧＷ５ｂはＵＥ１から送られてきたIKE_AUTH RequestメッセージにＡＵＴＨパラメータが格納されているか確認する（図２７、ステップＳ２００１３）。
IKE_AUTH RequestメッセージにＡＵＴＨパラメータが格納されている場合、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａにＵＥ１から受信したReuse keyとUE_BS_Identityが格納されているAuthentication-Requestメッセージを送信する（図２７、ステップＳ２０１００）。
続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａからＭＳＫとT-PGW_BS_Identityが格納されたAuthentication-Responseメッセージを受信する（図２７、ステップＳ２０１０１）。
Ｔ−ＰＧＷ５ｂは、受信したＭＳＫを用いてＡＵＴＨパラメータを作成する（図２７、ステップＳ２０１０２）。
続いて、Ｔ−ＰＧＷ５ｂは、ＵＥ１を認証する（図２７、ステップＳ２０１０３）。なお、ＵＥ１を認証する際に、ステップＳ２０１０１で受信したＭＳＫや、ステップＳ２０１０２で生成したＡＵＴＨパラメータを用いてＵＥ１を認証してもよい（例えば、ＵＥ１から送られてきたＡＵＴＨパラメータとＴ−ＰＧＷ５ｂが生成したＡＵＴＨパラメータの比較など）。なお、Ｔ−ＰＧＷ５ｂが、ＵＥ１を認証する際、Ｔ−ＰＧＷ５ｂが生成するＡＵＴＨパラメータを用いない場合は、ステップＳ２０１０２とステップＳ２０１０３の処理する順番を入れ替えてもよい。
Ｔ−ＰＧＷ５ｂがＵＥ１を認証した場合、Ｔ−ＰＧＷ５ｂが生成したＡＵＴＨパラメータやT-PGW_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２７、ステップＳ２０１１０）。
続いて、Ｔ−ＰＧＷ５ｂはＵＥ１とＢＵ／ＢＡ交換を実施する（図２７、ステップＳ２０１１１）。
本発明の第４の実施の形態に基づいて処理することで、ＵＥ１が既に確立済みのＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）が割り当てられた場合であっても、従来技術のPDN GW reallocation procedureと比べて、Ｔ−ＰＧＷ５ｂへの切り替え接続を短時間に完了させることができる。つまり、ＵＥ１とＴ−ＰＧＷ５ｂが、ＵＥ１とＩ−ＰＧＷ５ａのＳＡ確立時に作成したＭＳＫを再利用して、ＵＥ１とＴ−ＰＧＷ５ｂの間のＳＡを確立することで、ＵＥ１が所望のＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）との間の接続を短い時間で確立できるようになる。
なお、本発明の第４の実施の形態で用いたＭＳＫは、インターネットで利用される技術を標準化する組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｔ Ｆｏｒｃｅ）が、ＲＦＣで定義しているＭＳＫと同じであってもよいし、別途規定されてもよい。
また、図２１に示したように、ＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知するような場合においても、ＵＥ１は、Reuse IndicatorとUE_BS_Identityとを格納したIKE_AUTH_RequestメッセージをＴ−ＰＧＷ５ｂに送信することが望ましい。これにより、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図２１、ステップＳ１４０１１）が遅延したりロスしたりして、Ｔ−ＰＧＷ５ｂが鍵データ（ＭＳＫ）の再利用（フル認証の省略）を認識していない場合であっても、Ｔ−ＰＧＷ５ｂ越しにＭＳＫの再利用を実施することができ、切り替え接続のための時間短縮をより確実なものとすることができる。
また、図２１に図示されている第２のシーケンスでＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知する場合において、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図２１、ステップＳ１４０１１）が遅延したりロスしたりしないことがシステムとして保証されているような場合には、Reuse Indicatorの代わりとしてUser IdentityやＵＥ１のアドレスを使用することで、ＵＥ１はReuse Indicatorを図２２のステップＳ１５０１１で生成したり、ステップＳ１５０１２でIKE_AUTH_Requestメッセージに格納したりしなくてもよい。
またさらには、ＡＡＡサーバ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えを意図していることが確認できる場合、UE_BS_Identityは最早不要であり、図２２のステップＳ１５００７でＵＥ１への通知は行われない。このときＵＥ１は、Ｔ−ＰＧＷ５ｂに対して標準的なＢＳ処理を実行すればよく（図２２には不図示）、これにより、ＭＳＫの再利用がネットワーク側の判断によって実施され、Ｔ−ＰＧＷ５ｂへの切り替え接続を短時間に完了させることができる。
なお、本発明の第４の実施の形態で用いられているUE_BS_Identity並びにT-PGW_BS_Identityに関しても、上述の第１の実施の形態と同様に、様々な組み合わせが可能である。すなわち、本発明の第４の実施の形態において、例えば、UE_BS_Identityと、このUE_BS_Identityに対応するT-PGW_BS_Identityを用いて、UE_BS_IdentityとT-PGW_BS_Identityとの照合が行われてもよく、どちらか一方のBS_Identityが用いられてもよく、あるいは、BS_Identityが用いられなくてもよい。また、本発明の第４の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityに使用される情報として、例えば、ＵＥ１及びＰＧＷ５によって共有されている値を基に生成されたハッシュ値や、ランダムに生成された値やＩ−ＰＧＷ５ａのアドレス（これらに限定されない）など、ＵＥ１及びＰＧＷ５によって認識可能な値（符号）を用いることが可能である。また、本発明の第４の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityは、ＰＧＷ５、ＡＡＡサーバ８ａ、あるいは、その他の通信装置によって生成されてもよい。
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明のゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末は、複数のＣｏＡを使用している移動端末のＣｏＡを管理するＰＧＷ５を確実かつ迅速に統一できるようになり、その結果、移動端末は、複数のＣｏＡを使用した通信における利益を確実かつ迅速に享受できるようになるという効果を有しており、複数の通信インタフェースを有する移動端末が、これら複数の通信インタフェースを用いて異なるアクセスネットワークを介して所定のゲートウェイにアクセスするため技術に適用可能である。
本発明は、ＩＰ（Internet Protocol：インターネットプロトコル）を用いた通信を行う通信ノードがＰＧＷ（PDN Gateway）に接続する際に、その接続先を制御するゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末に関し、特にモバイルＩＰｖ６（Mobility support for IPv6：以降、ＭＩＰｖ６と呼ぶ）における移動端末（User Equipment：以降、ＵＥと呼ぶ）が複数の通信インタフェース（Interface：以降、ＩＦと呼ぶ）を保持する環境で、ＵＥの情報を管理するＰＧＷに接続する際に適用されるゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末に関する。
従来、ＭＩＰｖ６はＩＰネットワークにおけるＵＥの移動透過性を確保する技術として知られている（例えば、下記の非特許文献３又は非特許文献４を参照）。図１には、ＭＩＰｖ６を用いた通信ネットワークの構成の一例が図示されている。図１において、ＵＥ１（ＭＩＰｖ６ではモバイルノード：Mobile Node（ＭＮ）とも呼ばれる）と、ＵＥ１の位置情報（気付けアドレス；Care-of Address（ＣｏＡ）とも呼ばれる）を管理するＰＧＷ５（ＭＩＰｖ６用語ではホームエージェント：Home Agent（ＨＡ）とも呼ばれ、後述するＩ−ＰＧＷ５ａ若しくはＴ−ＰＧＷ５ｂに相当）と、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡ（Authentication, authorization and Accounting）サーバ８ａとユーザ情報データサーバであるＨＳＳ（Home Subscriber Server）８ｂ、ＰＧＷ５のＵＲＩ（Universal Resource Identifier）とＩＰアドレスとの組を保持するＤＮＳ（Domain Name System：ドメインネームシステム）サーバ９で構成される。
なお、ＡＡＡサーバ８ａとＨＳＳ８ｂは、物理的又は論理的に同一の装置に実装されるものであってもよく、以降、ＡＡＡサーバ８ａとＨＳＳ８ｂを説明の都合上まとめてＡＡＡ／ＨＳＳ８と呼ぶこともある。また、図１には、ＤＮＳサーバ９の接続形態は明示されていないが、ＤＮＳサーバ９は、コアネットワーク４や各アクセスネットワーク（後述する３ＧＰＰアクセスネットワーク２又はＮｏｎ−３ＧＰＰアクセスネットワーク３）からアクセス可能である。
図１において、ＵＥ１は、ホームリンク上で有効なホームアドレス（Home Address：以降、ＨｏＡと呼ぶ）と、外部リンクである移動先ネットワークで取得したＣｏＡを、バインディングアップデート（Binding Update：以降、ＢＵと呼ぶ）メッセージを用いてＰＧＷ５に通知する。ＰＧＷ５は、通知された両アドレス（ＨｏＡ，ＣｏＡ）の対応関係をバインディングキャッシュ（Binding Cash：以降、ＢＣと呼ぶ）に登録して保持することで、ＵＥ１のＨｏＡ宛てに送られてきたパケットをインターセプトし、対応するＵＥ１のＣｏＡ宛てに転送することが可能になる。ＵＥ１は、定期的あるいはＣｏＡが変更されたときに、ＢＵメッセージを用いてＣｏＡをＰＧＷ５に通知する。これにより、ＵＥ１はホームリンク内外に関係なく、ＵＥ１のＨｏＡ宛てのパケットを常時受信するができるようになる。
ここで、下記の非特許文献１には、移動体通信システムの標準化プロジェクト（3rd Generation Partnership Project：以降、３ＧＰＰと呼ぶ）におけるＰＧＷ５の割り当て方法が開示されている。非特許文献１に開示されている技術によれば、例えば図１において、ＵＥ１は、新たなアクセスネットワークに接続する際、自身を収容するＰＧＷ５を示すＵＲＩを基に、新たなアクセスネットワークにおけるＵＥ１の位置情報を管理するＰＧＷ５のＩＰアドレスをＤＮＳサーバ９から取得する。
このとき、同一あるいは異なる通信インタフェースを介して既にＵＥ１が接続済みのＰＧＷ５（ＵＥ１のバインディングキャッシュエントリを保持しているＰＧＷ５）が存在する状態も起こり得るが、このような状態にもかかわらず、既にＵＥ１が接続済みのＰＧＷ５とは異なるＰＧＷ５がＤＮＳサーバ９によって提示されることがある。こうした場合、例えば、異なる通信インタフェースで受信するデータの同期を取ることが困難になるなど、様々な点において、ＵＥ１が複数のＣｏＡを用いる際に期待される利点が実現されなくなってしまうかもしれないという問題が生じる。
このような問題を解決する方法として、非特許文献１には、ＰＧＷ５の切り替え方法（PDN GW reallocation procedure）が開示されている。非特許文献１に開示されているPDN GW reallocation procedureでは、ＵＥ１は、ＤＮＳサーバ９によって提示された異なるＰＧＷ５への接続をいったん開始するが、その接続処理中にＡＡＡ／ＨＳＳ８が提供する情報に基づいて、既に接続済みのＰＧＷ５のアドレスをネットワーク側からＵＥ１に通知することで、ＵＥ１は、通知されたＰＧＷ５（既に接続済みのＰＧＷ５）に再接続できるようになる。
なお、本明細書では、ＵＥ１が新たなアクセスネットワークに接続する際に、その接続先アクセスネットワークで提示されたＰＧＷ５をＩ−ＰＧＷ（Initial PGW）５ａと呼び、一方、ＵＥ１が新たなアクセスネットワークに接続する前に既に別のアクセスネットワークを通じて接続しているＰＧＷ５をＴ−ＰＧＷ（target PGW）５ｂと呼んで区別を行うことにする。Ｔ−ＰＧＷ５ｂは、ＵＥ１が新たなアクセスネットワークに接続した際に本来ＵＥ１が接続したいＰＧＷ５である。ＵＥ１は、新たなアクセスネットワークに接続した場合においても、その接続先をＴ−ＰＧＷ５ｂとすることで、通信に複数のＣｏＡを利用する場合の利益を享受できるようになる。
非特許文献１に開示されているPDN GW reallocation procedureを使用することで、接続先アクセスネットワークで提示されたＰＧＷ５が異なる場合においても、ＡＡＡ／ＨＳＳ８がＴ−ＰＧＷ５ａを割り当てることで、ＵＥ１は接続先のアクセスネットワークによらずＰＧＷ５を統一することが可能になる。
非特許文献１に開示されているPDN GW reallocation procedureは、ＵＥ１とＰＧＷ５との間のパケット通信を保護するためのセキュリティアソシエーション（Security Association：以降、ＳＡと呼ぶ）を確立するためのブートストラッピング（Bootstrapping：以降、ＢＳと呼ぶ）手順を利用する。なお、ＢＳ手順に関しては、例えば下記の非特許文献２に記述されている。以下、図１２用いて、その詳細な動作について説明する。
図１２は、従来の技術におけるＢＳ手順を説明するためのシーケンス図である。なお、図１２には、図１に図示されているシステム構成における図示されているＢＳ手順の一例が示されている。図１２では、ＵＥ１がＤＮＳサーバ９から提示されたＰＧＷ５とＢＳを実施する。その際に、コアネットワーク４への接続許可を下すＡＡＡサーバ８ａと、存在する場合にはＵＥ１が収容されるＰＧＷ５の識別情報（以降、PGW Identityと呼ぶ）やアクセスポイント名（Access Point Name：以降、ＡＰＮと呼ぶ）などを管理するＨＳＳ８ｂとの間でインタラクションが発生する。
まずＵＥ１は、PGW discovery procedure を実行し、ＰＧＷ５（図１のＩ−ＰＧＷ５ａに相当）のアドレスを取得する（ステップＳ９００１）。この際、もしＵＥ１が既に接続済みのＰＧＷ５（図１のＴ−ＰＧＷ５ｂに相当、図１２には不図示）を介して接続確立されたＰＤＮ（Packet Domain Network、図１２には不図示）のＡＰＮを保持していた場合は、ＤＮＳサーバ９にそのＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスを問い合わせる。具体的には、ＵＥ１は、保持しているＴ−ＰＧＷ５ｂのＡＰＮを問い合わせメッセージに格納し、その問い合わせメッセージをＤＮＳサーバ９に送信する。ＤＮＳサーバ９は、ＵＥ１から送られてきたＡＰＮに基づいてＰＧＷ５を検索してＵＥ１に通知するが、ネットワークの状態（負荷状態、オペレータによる設定、またＤＮＳデータベースが現在のＵＥ１の状態に基づいたダイナミック情報を保有していない、などの様々な理由）によって、ＵＥ１が所望するＴ−ＰＧＷ５ｂのアドレスではなく、異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）のアドレスをＵＥ１に返すことがある。
ＵＥ１は、ＤＮＳサーバ９から受信したＰＧＷ５（ここではＩ−ＰＧＷ５ａに相当）のアドレスに対してＳＡ確立を開始する（IKE_SA_INITシーケンスの起動、ステップＳ９００２）。IKE_SA_INITシーケンスにより、ＵＥ１とＰＧＷ５との間で以降のＢＳ処理に使用する共有鍵を含むＩＫＥ ＳＡ（IKE Security Association）を生成する。次に、ＵＥ１は、生成したＩＫＥ ＳＡを使用して保護したIKE_AUTH RequestメッセージをＰＧＷ５に送信する（ステップＳ９００３）。IKE_AUTH Requestメッセージには、ＵＥ１の識別子（例えば、ＮＡＩ：Network Access Identifier）などが含まれている。ＰＧＷ５は、取得したIKE_AUTH Requestメッセージに記載されたパラメータを基に、ＵＥ１に対する認証要求メッセージ（Authentication-Request/Identity）を生成し、ＡＡＡサーバ８ａに送信する（ステップＳ９００４）。
ＡＡＡサーバ８ａはＨＳＳ８ｂから取得したユーザプロファイル（User Profile）や認証ベクタ（Authentication Vector：ＡＶ）などを基にＵＥ１の認証を行い（ステップＳ９００５）、ＰＧＷ５を介してコアネットワーク４への接続を許可してもよいＵＥ１であるかどうかを判断し、その結果をEAP-Request/AKA-Challengeメッセージを用いてＰＧＷ５に通知する（ステップＳ９００６）。ネットワーク接続可能なＵＥ１であると判断された場合、ステップＳ９００６で送信されるEAP-Request/AKA-Challengeメッセージには、以降ＰＧＷ５とＵＥ１との間で使用するＳＡ確立に必要なチャレンジ情報が含まれている。ＰＧＷ５は、ＡＡＡサーバ８ａから取得したEAP-Request/AKA-Challengeメッセージを含むIKE_AUTH ResponseメッセージをＵＥ１に送信する（ステップＳ９００７）。続けて、ＵＥ１からＡＡＡサーバ８ａに対して、チャレンジ情報に対応するレスポンス情報が送信され（ステップＳ９００８、Ｓ９００９）、ＳＡ確立に必要なマスターキー（ＭＳＫ、鍵又は鍵情報と呼ぶこともある）あるいはその鍵素材（keying material）がＰＧＷ５に配布される（ステップＳ９０１０、Ｓ９０１１）。このＭＳＫを使用して、ＵＥ１とＰＧＷ５との間のＳＡが確立される（ステップＳ９０１２〜１４）。そして、確立されたＳＡを使用して、以降ＵＥ１とＰＧＷ５との間で交換されるＢＵ／ＢＡ（Binding Acknowledgement）が保護される（ステップＳ９０１５〜１７）。
図１２に図示されている動作では、ステップＳ９００６において、ＵＥ１がＢＳを開始したＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）に対して、ＨＳＳ８ｂが異なるＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）をＡＡＡサーバ８ａ経由でＰＧＷ５（Ｉ−ＰＧＷ５ａ）に通知することができる。このときＰＧＷ５（Ｔ−ＰＧＷ５ｂ）は、以降のＵＥ１とのＢＳ処理を完了させ（〜ステップＳ９０１４）、続けてＵＥ１との間で実施するバインディング処理の中で（具体的には、ステップＳ９０１６で送信するＢＡメッセージによって）、ＨＳＳ８ｂから通知を受けたＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）のアドレスをＵＥ１に通知する（ステップＳ９０１６）。このようにして本来接続したいＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスを受けたＵＥ１は、ＰＧＷ５（Ｉ−ＰＧＷ５ａ）とのバインディングを解消するためにライフタイムを０にセットしたＢＵを送信し（ステップＳ９０１７）、通知されたＰＧＷ５（Ｔ−ＰＧＷ５ｂ）に接続するためのＢＳ処理並びにバインディング処理（ＢＵ／ＢＡ交換）を改めて開始する。具体的には、ＵＥ１は、Ｔ−ＰＧＷ５ｂに対して、図１２のステップＳ９００２からの処理を再度実施する。
3GPP TS 23.402 V8.4.0，December 2008 3GPP TS 33.402 V8.2.1，December 2008 Mobility Support in IPv6, RFC3775，June 2004 Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)，draft-ietf-mext-nemo-v4traversal-06，November 2008 Proxy Mobile IPv6，RFC5213，August 2008 Mobile IPv6 Bootstrapping in Split Scenario，RFC5026，October 2007 Internet Key Exchange (IKEv2) Protocol，RFC4306，December 2005 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method, RFC5106, January 2008
しかしながら、上記従来の技術においては、ＵＥ１が既に接続済みのＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）と最終的に接続を完了するまでに、多大な時間を要する。これは、暗号認証鍵の生成処理に多大な時間を要するＢＳ処理を、本来接続を意図しないＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）との間で実施しなければならないことに起因するものである。
また、従来の技術においては、多大な時間を要するほかに、ＵＥ１が既に接続済みのＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）と最終的に接続を完了するまでに、多大なメッセージ数を要する。これは、本来接続を意図しないＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）が、ＵＥ１に本来接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスを取得してから、ＵＥ１に送信するまでに多大な数のメッセージのやりとりをしていることに起因するものである。これにより、本来接続を意図しないＰＧＷ５（Ｉ−ＰＧＷ５ａ）とやりとりしたメッセージが無駄になってしまい、無駄になったメッセージ分だけネットワークに負荷をかけてしまうことになる。
上記問題に鑑み、本発明では、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）が割り当てられた場合であっても、ＵＥが、システム内のリソース消費を抑えながら、かつ短時間で所望のＰＧＷ５への接続切り替えを行えるようにするゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末を提供することを目的とする。
上記の目的を達成するため、本発明のゲートウェイ接続方法は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムにおいて、前記移動端末を所望のゲートウェイに接続させるためのゲートウェイ接続方法であって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出するステップと、
前記移動端末が、前記検出ステップの結果をうけて、前記第２のゲートウェイに前記移動端末の収容状況を問い合わせるステップと、
前記第２のゲートウェイが、前記移動端末の収容状況を確認するステップと、
前記第２のゲートウェイが、前記移動端末を収容していないと判断した場合に、前記第１のゲートウェイに接続指示を送信するステップと、
前記第２のゲートウェイが、前記移動端末に待機指示を送信するステップと、
前記第１のゲートウェイが、前記移動端末に接続処理を開始するステップとを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷ５と短い時間で接続を確立させることができるようになる。
また、上記の目的を達成するため、本発明のゲートウェイ接続制御システムは、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなるゲートウェイ接続制御システムであって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出し、
前記移動端末が、前記検出ステップの結果をうけて、前記第２のゲートウェイに前記移動端末の収容状況を問い合わせ、
前記第２のゲートウェイが、前記移動端末の収容状況を確認し、
前記第２のゲートウェイが、前記移動端末を収容していないと判断した場合に、前記第１のゲートウェイに接続指示を送信し、
前記第２のゲートウェイが、前記移動端末に待機指示を送信し、
前記第１のゲートウェイが、前記移動端末に接続処理を開始することによって、
前記移動端末を所望のゲートウェイに接続させるよう構成されている。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷ５が移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷと短い時間で接続を確立させることができるようになる。
また、上記の目的を達成するため、本発明の移動端末は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末であり、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムに接続する際に、前記複数のゲートウェイのうちの所望のゲートウェイに接続することが可能な移動端末であって、
ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイアドレスを取得したことを検出する手段と、
検出された前記第２のゲートウェイに前記移動端末の収容状況を問い合わせる手段と、
前記第２のゲートウェイによって前記移動端末の収容状況が確認され、前記第２のゲートウェイが前記移動端末を収容していないと判断された場合に、待機指示を前記第２のゲートウェイから受信する手段と、
前記第２のゲートウェイによって前記移動端末の収容状況が確認され、前記第２のゲートウェイが前記移動端末を収容していないと判断された場合に、前記第２のゲートウェイから前記第１のゲートウェイに接続指示が送信され、前記第１のゲートウェイが前記接続指示に基づいて開始した前記移動端末との間の接続処理を行う手段とを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷ５が移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷと短い時間で接続を確立させることができるようになる。
また、上記の目的を達成するため、本発明のゲートウェイ接続方法は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムにおいて、前記移動端末を所望のゲートウェイに接続させるためのゲートウェイ接続方法であって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出するステップと、
前記移動端末が、前記検出ステップの結果をうけて前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換するステップと、
前記鍵情報の交換完了後、前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知するステップと、
前記移動端末が、前記第１のゲートウェイへの接続処理を開始するステップと、
前記第１のゲートウェイが、前記相互認証によって作成された前記鍵情報を前記認証サーバから取得するステップと、
前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するステップとを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
また、上記の目的を達成するため、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなるゲートウェイ接続制御システムであって、
前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出し、
前記移動端末が、前記検出ステップの結果をうけて前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換し、
前記鍵情報の交換完了後、前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知し、
前記移動端末が、前記第１のゲートウェイへの接続処理を開始し、
前記第１のゲートウェイが、前記相互認証によって作成された前記鍵情報を前記認証サーバから取得し、
前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するよう構成されている。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
また、上記の目的を達成するため、本発明の移動端末は、複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末であり、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムに接続する際に、前記複数のゲートウェイのうちの所望のゲートウェイに接続することが可能な移動端末であって、
ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイアドレスを取得したことを検出する手段と、
前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換する手段と、
前記鍵情報の交換完了後、前記第２のゲートウェイから前記第１のゲートウェイのアドレスを受信し、前記第１のゲートウェイへの接続処理を開始する手段と、
前記相互認証によって作成された前記鍵情報を再利用して、前記鍵情報を前記認証サーバから取得した前記第１のゲートウェイへ接続する手段とを、
有している。
これにより、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
本発明によれば、複数のＣｏＡを使用している移動端末のＣｏＡを管理するＰＧＷを確実かつ迅速に統一できるようになり、その結果、移動端末は、複数のＣｏＡを使用した通信における利益を確実かつ迅速に享受できるようになる。また、本発明によれば、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、接続初期にＰＧＷにおける移動端末の収容状況を確認させることによって、移動端末が真に接続を所望するＰＧＷであるかどうかを早期に判別できるようにし、またＡＡＡサーバの状態解消を不要とし、所望のＰＧＷと短い時間で接続を確立させることができるようになる。また、本発明によれば、新規接続あるいはハンドオーバ先のアクセスネットワークにおいて、既に接続済みであり本来接続を所望するＰＧＷとは異なるＰＧＷが移動端末に割り当てられた場合であっても、所望するＰＧＷとは異なるＰＧＷとの間の接続の際に作成された鍵情報を所望のＰＧＷへの接続の際に再利用することによって、移動端末が所望のＰＧＷとの間の接続を短い時間で確立できるようになる。
本発明の第１〜第４の実施の形態並びに従来の技術に共通する通信システムの構成の一例を示す図 本発明の第１の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するためのシーケンスチャート 本発明の第１〜第４の実施の形態における移動端末（ＵＥ）の構成の一例を示す図 本発明の第１の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第１の実施の形態において、移動端末（ＵＥ）がＰＧＷ（Ｉ−ＰＧＷ）に送信するIKE_AUTH Requestメッセージのフォーマット例を示す図 本発明の第１の実施の形態において、ＰＧＷ（Ｉ−ＰＧＷ）が移動端末（ＵＥ）に送信する応答メッセージであるIKE_AUTH Responseメッセージのフォーマット例を示す図 本発明の第１の実施の形態において、ＰＧＷ（Ｉ−ＰＧＷ）がＡＡＡサーバに送信するHome Prefix確認要求メッセージの一例を示す図 本発明の第１の実施の形態において、ＡＡＡサーバがＰＧＷ（Ｔ−ＰＧＷ）に送信するHome Prefix確認要求返信メッセージの一例を示す図 本発明の第１の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）が移動端末（ＵＥ）に送信する第１のIKE_SA_INITメッセージの一例を示す図 本発明の第１の実施の形態において、移動端末（ＵＥ）がＰＧＷ（Ｔ−ＰＧＷ）に送信する第２のIKE_SA_INITメッセージの一例を示す図 本発明の第１〜第４の実施の形態におけるＰＧＷの構成の一例を示す図 本発明の第１の実施の形態におけるＰＧＷの処理フローの一例を示すフローチャート 本発明の第１〜第４の実施の形態におけるＡＡＡサーバの構成の一例を示す図 本発明の第１の実施の形態におけるＡＡＡサーバの処理フローの一例を示すフローチャート 従来の技術における動作の一例を説明するためのシーケンスチャート 本発明の第２の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するためのシーケンスチャート 本発明の第３の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第１のシーケンスチャート 本発明の第３の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第２のシーケンスチャート 本発明の第３の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第３の実施の形態において、移動端末（ＵＥ）がＰＧＷ（Ｔ−ＰＧＷ）に送信するIKE_AUTH Requestメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）が移動端末（ＵＥ）に送信するIKE_AUTH Responseメッセージのフォーマット例を示す図 本発明の第４の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）が移動端末（ＵＥ）に送信するIKE_AUTH Responseメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＰＧＷ（Ｔ−ＰＧＷ）がＡＡＡサーバに送信するAuthentication-Requestメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＡＡＡサーバがＰＧＷ（Ｉ−ＰＧＷ／Ｔ−ＰＧＷ）に送信するAuthentication-Answerメッセージのフォーマット例を示す図 本発明の第３の実施の形態において、ＡＡＡサーバがＰＧＷ（Ｔ−ＰＧＷ）に送信するBS_Identity通知メッセージのフォーマット例を示す図 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第１のシーケンスチャート 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第２のシーケンスチャート 本発明の第４の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるＰＧＷのＩ−ＰＧＷとしての処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるＰＧＷのＴ−ＰＧＷとしての処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第３のシーケンスチャート 本発明の第４の実施の形態におけるゲートウェイ接続方法の動作の一例を説明するための第４のシーケンスチャート 本発明の第４の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート 本発明の第４の実施の形態におけるＰＧＷのＴ−ＰＧＷとしての処理フローの一例を示すフローチャート
以下、図面を参照しながら、本発明の第１〜第４の実施の形態について説明する。まず、図１を参照しながら、本発明の第１〜第４の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１〜第４の実施の形態に共通するシステム構成の一例を示す図である。図１に図示されている通信システムは、少なくとも、ＵＥ１、ＵＥ１が接続するコアネットワーク４、ＵＥ１を収容しＵＥ１のホームプレフィクスやホームアドレス、位置情報（ＣｏＡ）などを管理しているＴ−ＰＧＷ５ｂ、ＵＥ１のコアネットワーク４に対するアクセス認証を行うＡＡＡサーバ８ａ、ＵＥ１が接続しているＴ−ＰＧＷ５ａの識別子（identity）やＡＰＮを管理保存しているＨＳＳ８ｂ、ＵＥ１からの要求に応じてＰＧＷ５のアドレスを提供するＤＮＳサーバ９、３ＧＰＰアクセスネットワーク２（以下、３Ｇアクセス２とも呼ぶ）、Ｎｏｎ−３ＧＰＰ（非３ＧＰＰ）アクセスネットワーク３（以下、Ｎ３Ｇアクセス３とも呼ぶ）を有している。
ＵＥ１は、少なくとも２つ以上の通信インタフェースを持ち、一方は３Ｇアクセス２、もう一方はＮ３Ｇアクセス３に接続することが可能である。なお、複数の通信インタフェーは、同時に３Ｇアクセス２に接続したり、あるいは、Ｎ３Ｇアクセス３に接続したりするものであってもよい。ＵＥ１は、各アクセスネットワーク（３Ｇアクセス２、Ｎ３Ｇアクセス３）を介してコアネットワーク４に接続し、Ｉ−ＰＧＷ５ａ、Ｔ−ＰＧＷ５ｂのいずれにもアタッチすることができる。また、ＵＥ１は、少なくともＮ３Ｇアクセス３を介してＤＮＳサーバ９に接続可能である。ＵＥ１は、３Ｇアクセス２からＤＮＳサーバ９に接続することも可能であるが、Ｎ３Ｇアクセス３経由で接続可能なＤＮＳサーバ９とは異なるＤＮＳサーバ９が３Ｇアクセス２に配備される場合もあり、３Ｇアクセス２経由のＤＮＳ問い合わせとＮ３Ｇアクセス３経由のＤＮＳ問い合わせとでは、必ずしも同一の結果が得られるとは限らない。
また、３Ｇアクセス２には、例えば、サービングＧＷ（Serving GW）やＭＭＥ、ＳＧＳＮ、ＧＧＳＮなどの３ＧＰＰシステムに固有の装置が配備されており、ＵＥ１がＰＧＷ５に接続するための機能をサポートしているが、図１では図示省略する。また、Ｎ３Ｇアクセス３においても、ＵＥ１がＰＧＷ５に接続するために必要となる機能をサポートする通信ノード（ＵＥ１にＣｏＡを配布するアクセスルータやＭＡＧなど）が配備されているが、これらの通信ノードも図１では図示省略する。
上記の構成を有する通信システムにおいて、ＵＥ１は、３Ｇアクセス２とコアネットワーク４を介してＴ−ＰＧＷ５ｂとの接続を確立しているものとする。ここで、３Ｇアクセス２経由の接続においては、例えばＰＭＩＰ（上記の非特許文献５を参照）が使用されるため、ＵＥ１はＴ−ＰＧＷ５ｂのアドレスを知り得ない（非特許文献１を参照）。一方で、ＨＳＳ８ｂにおいては、適正なＵＥ１の接続管理とネットワークの状態管理を目的として、ＵＥ１の識別子と共にＴ−ＰＧＷ５ｂのアドレスをデータベース管理している。
＜第１の実施の形態＞
以下、本発明の第１の実施の形態におけるシステム動作の一例について、図２を用いて詳しく説明する。図２は、本発明の第１の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。図２には、少なくともＵＥ１、ＵＥ１がＮ３Ｇアクセス３にアタッチした際にＤＮＳサーバ９によって提示されるＩ−ＰＧＷ５ａ、ＵＥ１が３Ｇアクセス２経由で接続済みのＴ−ＰＧＷ５ｂ、ＵＥ１のコアネットワーク４に対するアクセス認証処理を実施するＡＡＡサーバ８ａ、ＵＥ１のサブスクリプション情報などを保持管理するＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
ＵＥ１は、新規接続あるいはハンドオーバのためにＮ３Ｇアクセス３にアタッチし、コアネットワーク４を介してＰＧＷ５とＭＩＰｖ６（又は、ＤＳＭＩＰ）により接続することを決定する。まずＵＥ１は、接続先となるＰＧＷ５のアドレスを取得するため、接続先ネットワークＰＤＮの識別子であるＡＰＮや、ＰＧＷ５を識別するためのＨＡ−ＡＰＮなどから、標準的な方法（例えば、上記の非特許文献６などに記載されている方法）により、ホームエージェント名（ＦＱＤＮ：Fully Qualified Domain Name）を構築し、ＤＮＳサーバ９に問い合わせる。ＤＮＳサーバ９は、適切なＰＧＷアドレスをＵＥ１に返信する（ステップＳ３００１：ＰＤＮ ＧＷ探索）。ＵＥ１は取得したＰＧＷアドレス宛に、ＢＳ処理を開始する。具体的には、ステップＳ３００１で取得したＰＧＷアドレスに対してIKE_SA_INIT手順を実施する（ステップＳ３００２：IKE_SA_INIT）。
なお、ここでは、ＵＥ１がステップＳ３００１において、既に接続済みのＴ−ＰＧＷ５ｂとは異なるＩ−ＰＧＷ５ａのアドレスを取得し、ＢＳ処理もＵＥ１とＩ−ＰＧＷ５ａ間で開始されるものとする。
ここでＵＥ１は、既に接続済みのＴ−ＰＧＷ５ｂとの接続を望んでいるが、ＤＮＳサーバ９によって提示されたＰＧＷアドレスがＴ−ＰＧＷ５ｂのものであるかどうかの確認を取ることができない。なぜなら、３Ｇアクセス経由の接続は例えばＰＭＩＰを用いるものであり、ＵＥ１はＴ−ＰＧＷ５ｂのアドレスを知り得ないためである。またＵＥ１は、ＤＮＳによるＰＧＷアドレス取得においては、時折所望のＰＧＷアドレスが得られない場合があることを知っている。さらには、Ｎ３Ｇアクセス３においては、それ以外にＰＧＷアドレス（Ｔ−ＰＧＷ５ｂのアドレス）を取得する手段がないことが明らかであることから、ステップＳ３００２におけるIKE_SA_INITに続けて実施するＩＫＥ認証処理の開始時に、ＢＳ処理を開始しているＰＧＷ５（ここではＩ−ＰＧＷ５ａ）が所望のＰＧＷ５（すなわちＴ−ＰＧＷ５ｂ）であるかどうかの確認を依頼する。
具体的には、ＵＥ１は、ステップＳ３００２のIKE_SA_INIT手順完了後に送信するIKE_AUTＨ Requestメッセージに、ＵＥ１が保持する（３Ｇアクセス２経由の接続時に割り当てられた）ホームプレフィクス（Home Prefix）を付加して送信する（ステップＳ３００３：IKE_AUTH Request）。Ｉ−ＰＧＷ５ａは、IKE_AUTH Requestメッセージを受信すると、そのメッセージからホームプレフィクスを抽出し、自ノード内のバインディングキャッシュに既に登録されているホームプレフィクスであるかどうか（収容状況）を確認する（ステップＳ３００４：収容状況確認）。
図５Ａは、図２のステップＳ３００３においてＵＥ１がＩ−ＰＧＷ５ａに送信するIKE_AUTH Requestメッセージのフォーマット例を示す図である。ＵＥ１は、従来の標準的なIKE_AUTH Requestメッセージ５０１に加えて、Home Prefixフィールド５０２を設け、その中にＵＥ１が保持するホームプレフィクスを挿入することでホームプレフィクスを通知することができる。また、標準的なIKE_AUTH Requestメッセージにおいて、MIP6_HOME_PREFIX属性をセットしたConfiguration Payloadにホームプレフィクスを記載することで、Ｉ−ＰＧＷ５ａにホームプレフィクスを通知してもよい。
また、IKE_AUTH Requestメッセージにホームプレフィクスを付加することが、収容状況の確認依頼を暗示しているが、さらに、IKE_AUTH Requestメッセージにホームプレフィクスを付加するとともに収容状況確認フラグ（図５Ａには不図示）も付加して、Ｉ−ＰＧＷ５ａに対して、明示的に収容状況の確認を依頼してもよい。これにより、Ｉ−ＰＧＷ５ａは確実に自ノードで管理するバインディングキャッシュにおけるＵＥ１の収容状況を確認する処理を行い、より確実な結果をＵＥ１に通知することができる。また、収容状況確認フラグを付加することにより、ＵＥ１を収容するＰＧＷ５は個別のものだが（Ｔ−ＰＧＷ５ａとＩ−ＰＧＷ５ｂ）、各ＰＧＷ５でＵＥ１に配布管理するホームプレフィクスは同一のもの、というオペレーション下においても、同一のＰＧＷ５（Ｔ−ＰＧＷ５ｂ）に接続を統合することができる。
なお、ここでは、ステップＳ３００１において、ＵＥ１が既に接続済みのＴ−ＰＧＷ５ｂとは異なるＩ−ＰＧＷ５ａのアドレスを取得することを前提としているが、ＵＥ１が既に接続済みのＴ−ＰＧＷ５のアドレスを取得する場合も考えられる。この場合には、ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されており、ＵＥ１が接続しているＰＧＷ５がＩ−ＰＧＷ５ａであることになるので（すなわちＩ−ＰＧＷ５ａとＴ−ＰＧＷ５ｂが同一）、引き続き所定のＢＳ処理を実施する。すなわち、図１２のステップＳ９００３のIKE_AUTH Requestメッセージ受信以降の処理を実施する。
ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されていない場合、Ｉ−ＰＧＷ５ａはＵＥ１が接続を所望しているＴ−ＰＧＷ５ｂではないため、Ｉ−ＰＧＷ５ａは、IKE_AUTH Requestメッセージに対する応答メッセージ（例えばIKE_AUTH Responseメッセージなど）に、収容状況結果（判定結果）、本ＢＳの実施を識別するための識別子UE_BS_Identity、動作指示を含めてＵＥ１に送信する（ステップＳ３００５：IKE_AUTH_Response）。判定結果には、ＵＥ１のホームプレフィクスが自ノードのバインディングキャッシュに存在したか否かの収容状況を記載する。UE_BS_Identityは、後述するＴ−ＰＧＷ５ｂからのＢＳ処理を正しく受信するための情報であり、例えばＩ−ＰＧＷ５ａが指定した数値などであるが、その応用については後述する。なお、UE_BS_IdentityとT-PGW_BS_Identityの両BS_Identityを使用せずに、Ｔ−ＰＧＷ５ｂからＵＥ１にIKE_SA_INIT_1メッセージを送信することも可能であり、これによって、Ｉ−ＰＧＷ５ａ、Ｔ−ＰＧＷ５ｂ、ＵＥ１間でUE_BS_IdentityやT-PGW_BS_Identityの転送が不要となり、通信リソースの有効活用を図る方法もある。動作指示には、後述するＴ−ＰＧＷ５ｂからのＢＳ処理が実施されるので本ＢＳが失敗終了しても、再接続や処理完了を行わないよう促す指示子を格納する。
ここでＩ−ＰＧＷ５ａが、３ＧＰＰ規格標準に基づくＧＴＰ（GPRS Tunneling Protocol）にも対応している場合、上記バインディングキャッシュに対する収容状況確認に加えて（あるいはバインディングキャッシュに対する確認は行わずに）、ＧＴＰに基づく管理テーブルを確認してもよい。これにより、ＵＥ１の収容状況をもれなく検出して、誤検出を防ぐことができる。
また、さらには、ＵＥ１とＴ−ＰＧＷ５ｂの３Ｇアクセス経由の接続には、ＰＭＩＰあるいはＧＴＰが用いられていると考えることができる。一方、今回のＮ３Ｇアクセス経由の接続では、ＭＩＰあるいはＤＳＭＩＰが用いられるため、Ｉ−ＰＧＷ５ａに向けてブートストラッピング処理が開始されている。コアネットワーク４の運用形態によっては、ＰＭＩＰあるいはＧＴＰで用いられるＵＥ１の位置管理を行うためのデータベース（例えばＰＭＩＰバインディングキャッシュ）と、ＤＳＭＩＰ／ＭＩＰで用いられる同ＵＥ１の位置管理を行うためのデータベース（例えばＭＩＰバインディングキャッシュ）はそれぞれ個別に管理運用されることも想定される。さらには、それぞれ（ＧＴＰ、ＰＭＩＰ、ＤＳＭＩＰ／ＭＩＰ）の位置管理機能が論理的あるいは物理的に異なる装置で実施されることも想定される。そのような場合、Ｉ−ＰＧＷ５ａは、ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されているかどうかをチェックする際に、ＤＳＭＩＰ／ＭＩＰで用いられる管理データベース（ＭＩＰバインディングキャッシュ）の確認だけではなく、Ｉ−ＰＧＷ５ａが管理する（あるいは、Ｉ−ＰＧＷ５ａの管轄対象である他ノードが管理する、さらにはＩ−ＰＧＷ５ａと同じドメインに配置された他ノードが管理する）ＰＭＩＰバインディングキャッシュや、ＧＴＰ用の位置管理データベースの確認も行うことが望ましい。
図５Ｂは、図２のステップＳ３００５においてＩ−ＰＧＷ５ａがＵＥ１に送信する応答メッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｉ−ＰＧＷ５ａは、従来の標準的なIKE_AUTH Responseメッセージ６０１に加えて、判定結果フィールド６０２、動作指示フィールド６０３、UE_BS_Identityフィールド６０４を設け、それぞれ所定の値をＵＥ１に通知することができる。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加して判定結果を記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。
なお、Ｉ−ＰＧＷ５ａは、標準的なホームプレフィクス割り当て機構に従って、ＵＥ１が要求したものと異なるホームプレフィクスを割り当てることが判明したことを条件に、上記のＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されていない場合と同等の動作を行ってもよい。
本応答メッセージを受信したＵＥ１は、判定結果フィールドを参照してＩ−ＰＧＷ５ａがＵＥ１の所望するＰＧＷ５ではない可能性が高いことを確認するとともに、動作指示フィールドを参照して引き続き所望のＴ−ＰＧＷ５ｂからＢＳ処理が開始されることを確認し、UE_BS_Identityフィールドに記載された値（UE_BS_Identity）を保存する。ここで、本ＢＳが失敗終了と判定された場合でも、後続して所望Ｔ−ＰＧＷ５ｂからのＢＳ処理が開始することが明らかとなったので、他のＰＧＷ５の探索や再接続を行ったり、ＢＳ処理を完了してスリープモードに入ったりしないよう制御する。なお、後にＴ−ＰＧＷ５ｂからのＢＳ処理要求を受信できることが明らかであれば、消費電力削減のためスリープモードに遷移してもよい。また、ＵＥ１は、判定結果からＵＥ１が所望するＰＧＷ５に接続していないことが確認できた時点で、引き続き所望のＴ−ＰＧＷ５ｂからのＢＳ処理が開始されると判断してもよく、これにより動作指示フィールドを省略して、通信帯域の有効活用を図ることができる。
さらにＩ−ＰＧＷ５ａは、Home Prefix確認要求メッセージをＡＡＡサーバ８ａに送信する（ステップＳ３００６：Home Prefix確認要求）。Home Prefix確認要求メッセージには、ＵＥ１のUser ID（ＮＡＩなど）、ホームプレフィクス（Home Prefix）、ＵＥ１に通知したものと同一のUE_BS_Identity、ＵＥアドレス（ＣｏＡ）、転送指示などの情報が少なくとも含まれる。転送指示は、本メッセージを受けてＵＥ１のホームプレフィクスを管理保持するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）が判明した際に、Ｔ−ＰＧＷ５ｂにＵＥ１宛のＢＳ処理を実施させることをＡＡＡサーバ８ａに対して指示するものであり、特にHome Prefix確認要求メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いる場合などに有効である。
なお、Ｉ−ＰＧＷ５ａは、Home Prefix確認要求メッセージをＡＡＡサーバ８ａへ送信することでＴ−ＰＧＷ５ｂにＢＳ指示を送信する以外に、Ｉ−ＰＧＷ５ａがＴ−ＰＧＷ５ｂを含む装置全てにHome Prefix確認要求メッセージをブロードキャストしてもよい。同様に、Ｉ−ＰＧＷ５ａがＴ−ＰＧＷ５ｂのアドレスを知っていた場合や、いくつかＴ−ＰＧＷ５ｂのアドレスに対して見当がついている場合には、Home Prefix確認要求メッセージをユニキャストやマルチキャスト送信してもよい。
なお、Ｉ−ＰＧＷ５ａは、本発明によるIKE_AUTH Responseメッセージ（図２のステップＳ３００５で送信）とHome Prefix確認要求メッセージ（図２のステップＳ３００６で送信）を任意の順番で送信してもよい。すなわち、上記の説明では、IKE_AUTH Responseを先に、Home Prefix確認要求メッセージを後に送信しているが、その逆であってもよく、例えば、ネットワーク遅延に鑑みて送信順序を決定してもよい。例えば、ネットワーク側装置による処理負荷が高いことに鑑みてHome Prefix確認要求を先に送信してもよく、あるいは、Ｔ−ＰＧＷ５ｂからのＢＳ処理がIKE_AUTH Responseより先行してＵＥ１に伝送されてしまわないように、IKE_AUTH Responseを先に送信して、ＵＥ１の状態遷移が正常に動作するように配慮してもよい。
図６Ａは、図２のステップＳ３００６においてＩ−ＰＧＷ５ａがＡＡＡサーバ８ａに送信するHome Prefix確認要求メッセージの一例を示す図である。Ｉ−ＰＧＷ５ａは、宛先アドレスフィールド１００１にＡＡＡサーバ８ａのアドレス、ソースアドレスフィールド１００２に自アドレス、転送指示フィールド１００３に転送を指示する値（例えば“１”やTRUEなど）、Home Prefixフィールド１００４にＵＥ１のホームプレフィクス値、UE_BS_Identityフィールド１００５にＵＥ１に通知したものと同一の UE_BS_Identity値、ＵＥアドレスフィールド１００６にＵＥ１のアドレス（ＣｏＡ）を記載してＡＡＡサーバ８ａに送信する。なお、Home Prefix確認要求メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いてもよい。また、Home Prefix確認要求メッセージに、ＵＥ１のUser IDを含めてもよく、これによりＵＥ１が接続しているＴ−ＰＧＷ５ｂの探索をより確実に行うことができるとともに、ＵＥ１に対して本発明による切り替え処理を実施することの可否をＵＥ１の認証とからめて制御することが可能となり、オペレータにおいては新たな課金対象サービスと捉えることができる。
Home Prefix確認要求メッセージを受信したＡＡＡサーバ８ａは、User ID、Home Prefixなどの識別子を基に、ＵＥ１を収容しているＴ−ＰＧＷ５ｂを検出し、検出したＴ−ＰＧＷ５ｂに対してHome Prefix確認要求返信メッセージを送信する（ステップＳ３００７：Home Prefix確認要求返信）。
Home Prefix確認要求返信メッセージには、少なくともUser ID、ＵＥアドレス、UE_BS_Identity、ＢＳ指示子を記載する。ＵＥアドレスには、Home Prefix確認要求メッセージに記載されていたものと同一のＵＥ１のアドレスを記載する。またＢＳ指示子には、ＵＥアドレスに記載したＵＥ１のアドレスに対してＢＳ処理を開始することをＴ−ＰＧＷ５ｂに指示する値を記載する（例えば“１”やTRUEなど）。
また、図６Ｂは、図２のステップＳ３００７においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するHome Prefix確認要求返信メッセージの一例を示す図である。ＡＡＡサーバ８ａは、宛先アドレスフィールド１１０１にＴ−ＰＧＷ５ｂのアドレス、ソースアドレスフィールド１１０２に自アドレス、ＢＳ指示フィールド１１０３にＢＳ処理開始を指示する値（例えば“１”やTRUEなど）、ＵＥアドレスフィールド１１０４にＵＥ１のアドレス（Home Prefix確認要求メッセージで取得した値をコピー）、UE_BS_Identityフィールド１１０５にHome Prefix確認要求メッセージで取得した値を記載してＴ−ＰＧＷ５ｂに送信する。また、Home Prefix確認要求メッセージに、ＵＥ１のUser IDを含めてもよく、これによりＴ−ＰＧＷ５ｂにおいてＵＥ１の識別をより確実に行うことができる。
なお、ＵＥアドレスには、ＵＥ１が３Ｇアクセス２で取得したアドレス、すなわちホームアドレスあるいはホームプレフィクスを記載してもよい。これは、ＵＥ１が記載するものであってもよいし、Home Prefix確認要求メッセージを受けたとき、あるいはHome Prefix確認要求返信メッセージを送信するときに、ＡＡＡサーバ８ａやＨＳＳ８ｂが記載するものであってもよい。これにより、ＵＥ１が既に接続済みの３Ｇアクセス２経由でより確実に後述するＢＳ処理を開始することができる（例えば、後述するＮＡＴ（Network Address Translation）がＮ３Ｇアクセス３に配備されているような場合に有効）。ここで、ＵＥアドレスとしてホームプレフィクスが記載されていた場合、Ｔ−ＰＧＷ５ｂは、そのホームプレフィクスの所定のアドレスに対してユニキャストやマルチキャスト、あるいはエニキャストでＢＳ処理を開始してもよく、ホームプレフィクス全体にブロードキャストを行ってＢＳ処理を開始してもよい。
なお、Ｉ−ＰＧＷ５ａは、Home Prefix確認要求メッセージをＨＳＳ８ｂに送信してもよい。この場合、ＡＡＡサーバ８ａがＵＥ１の状態をＨＳＳ８ｂから取得する必要がなくなり、処理時間の削減を図ることができる。Home Prefix確認要求メッセージをＨＳＳサーバ８ｂに送信する場合、上記の説明においてＡＡＡサーバ８ａが実施する動作はＨＳＳ８ｂにおいて実施され、Home Prefix確認要求返信メッセージもＨＳＳ８ｂからＴ−ＰＧＷ５ｂに直接あるいは間接ノードを介して転送される。
また、Ｉ−ＰＧＷ５ａは、Home Prefix確認要求メッセージを、Ｉ−ＰＧＷ５ａが送信可能な範囲に送信してもよく、あるいは、所定範囲のＰＧＷ５に対してブロードキャスト送信、マルチキャスト送信、ユニキャスト送信、エニキャスト送信（特にはＵＥ１のホームプレフィクスを基に構築したホームエージェント・エニキャストアドレス宛に送信）のいずれを行ってもよい。これにより、ＡＡＡサーバ８ａやＨＳＳ８ｂ経由のメッセージ転送を削減でき、ＡＡＡサーバ８ａ、ＨＳＳ８ｂの負荷を低減させることができるとともに、特にユニキャスト通信を行う場合は、システム全体としての処理メッセージ数を削減することができる。
Ｉ−ＰＧＷ５ａがＴ−ＰＧＷ５ｂに直接指示を送信する際は、Ｉ−ＰＧＷ５ａが事前にＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂのアドレスを取得する。このとき、ＵＥ１のためのＴ−ＰＧＷ５ｂのアドレス取得であることを理由に、ＡＡＡサーバ８ａにおいてＵＥ１に対する認証処理が実施されるかもしれない。また、直接指示のためのメッセージは、Home Prefix確認要求メッセージであっても、Home Prefix確認要求返信メッセージであってもよい。
このように、Ｉ−ＰＧＷ５ａがＡＡＡサーバ８ａやＨＳＳ８ｂ、あるいは直接Ｔ−ＰＧＷ５ｂにHome Prefix確認要求メッセージ（場合によってはHome Prefix確認要求返信メッセージ）を送信することにより、それ以降、Ｉ−ＰＧＷ５ａはＵＥ１に関する処理を行う必要がなくなる。すなわち、ＵＥ１に関する状態やリソースを開放することが可能となり、直ちに他の端末に対する処理を開始できるようになる。このように、本発明では早期に所望のＰＧＷ５への切り替えを検出、実施可能とできるので、ＰＧＷリソースの有効活用を図ることができる。ちなみに、従来技術においては、図１２のステップＳ９０１７を完了しないと、Ｉ−ＰＧＷ５ａは、Ｉ−ＰＧＷ５ａのリソース並びにＵＥ１に対する状態を解放することができなかった（正確には、ステップＳ９０１７の後で、ＵＥ１とＩ−ＰＧＷ５ａとの間で確立したＳＡを終了させ、解放する必要がある）。
Home Prefix確認要求返信メッセージを受信したＴ−ＰＧＷ５ｂは、User IDなどから自身が収容しているＵＥ１であることを確認し、さらにＢＳ指示子がＵＥ１宛のＢＳ処理を開始する指示であることを確認し、第１のIKE_SA_INITメッセージをＵＥアドレス宛に送信してＢＳ処理を開始する（ステップＳ３００８：IKE_SA_INIT_1）。第１のIKE_SA_INITメッセージには、Ｔ−ＰＧＷ５ｂが生成した本ＢＳの実施を識別するための識別子T-PGW_BS_Identityが少なくとも含まれる。
図７Ａは、図２のステップＳ３００８においてＴ−ＰＧＷ５ｂがＵＥ１に送信する第１のIKE_SA_INITメッセージの一例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_SA_INITメッセージ２００１（InitiatorがResponderに最初に送信するIKE_SA_INITメッセージ）に続けて、Ｔ−ＰＧＷ用ＢＳ識別子フィールド（T-PGW_BS_Identityフィールド）２００２を設け、その中にＴ−ＰＧＷ５ｂが取得した本ＢＳの実施を識別するためのＴ−ＰＧＷ用ＢＳ識別子T-PGW_BS_Identityを少なくとも記載して送信する。
Ｔ−ＰＧＷ５ｂからの第１のIKE_SA_INITメッセージを受信したＵＥ１は、そのメッセージのT-PGW_BS_Identityフィールドの値を確認し、先にＩ−ＰＧＷ５ａから取得したUE_BS_Identity値（ステップＳ３００５で受信したIKE_AUTH_Responseに含まれているUE_BS_Identity）を用いて後述する所定の検証を行い、検証結果が成功であった場合に要求するＴ−ＰＧＷ５ｂからのＢＳ処理要求であることを認識し、応答するIKE_SA_INITメッセージを送信する（ステップＳ３００９：IKE_SA_INIT_2）。このとき、ＵＥ１は、送信するIKE_SA_INITメッセージに、先に取得したUE_BS_Identityを記載して送信する。これにより、本ＢＳ処理のトリガを要求したＵＥ１からの応答であることをＴ−ＰＧＷ５ｂに提示して、正しいノード間でＢＳ処理が実施されていることを確認することができる。
図７Ｂは、図２のステップＳ３００９において、ＵＥ１がＴ−ＰＧＷ５ｂに送信する第２のIKE_SA_INITメッセージの一例を示す図である。ＵＥ１は、従来の標準的なIKE_SA_INIT（ResponderがInitiatorに最初に送信するIKE_SA_INITメッセージ）に続けて、先にＩ−ＰＧＷ５ａから取得した本BSの実施を識別するためのＵＥ用ＢＳ識別子UE_BS_Identityを少なくとも記載して送信する。なお、ステップＳ３００８及びＳ３００９でＵＥ１とＴ−ＰＧＷ５ｂとが交換するIKE_SA_INITメッセージは、各々が送信するBS_Identity（T-PGW_BS_Identity及びUE_BS_Identity）を正しく交換できれば、いずれのIKE_SA_INITメッセージを用いてもよい。
上記BS_Identityを用いて、正しく相互認証あるいは相互確認が取れたことにより、以降のＢＳ処理（IKE_SA_INITの残りとステップＳ３０１０以降の処理）は、従来の標準的な処理を実施することで、ＵＥ１とＴ−ＰＧＷ５ｂとの間のＳＡ確立を達成することができる。
なお、ステップＳ３００８に示すＴ−ＰＧＷ５ｂからのIKE_SA_INIT_1メッセージが受信できない場合のリカバリを容易にすることを目的として、ＵＥ１はＴ−ＰＧＷ５ｂからのIKE_SA_INIT受信待ちタイマをセットしてもよい。タイマは、例えばＵＥ１が本発明によるIKE_AUTH ResponseメッセージをステップＳ３００５において受信したときに所定の値にセットして起動する。タイマ値はＵＥ１が任意に設定してもよく、IKE_AUTH Responseメッセージなどを介してＩ−ＰＧＷ５ａなどのネットワーク装置から指定されてもよい。
次に、UE_BS_IdentityとT-PGW_BS_Identityの使用方法について、詳しく説明する。UE_BS_Identity、T-PGW_BS_Identityとして使用される情報は、例えば、ＵＥ１及びＰＧＷ５によって共有されている値を基に生成されたハッシュ値や、ランダムに生成された値やＩ−ＰＧＷ５ａのアドレスなど、ＵＥ１及びＰＧＷ５によって認識可能な値（符号）であればこれらに限定されない。
図２に図示されているシーケンスでは、UE_BS_IdentityがＩ−ＰＧＷ５ａによって生成され、ＵＥ１へ送信される（図２のステップＳ３００５）とともに、ＡＡＡサーバ８ａを経由するか、あるいは直接Ｔ−ＰＧＷ５ｂへ送信される（図２のステップＳ３００６）。Ｔ−ＰＧＷ５ｂは、受信したUE_BS_Identityに対応するT-PGW_BS_Identityを生成し、生成されたT-PGW_BS_Identityを含むIKE_SA_INIT_1メッセージをＵＥ１へ送信する（図２のステップＳ３００８）。IKE_SA_INITメッセージを受信したＵＥ１は、あらかじめＩ−ＰＧＷ５ａから取得したUE_BS_Identity（図２のステップＳ３００５で受信したIKE_AUTH Responseに含まれるUE_BS_Identity）に対応するT-PGW_BS_Identityを導出し、Ｔ−ＰＧＷ５ｂから受信したT-PGW_BS_Identity（図２のステップＳ３００８で受信したIKE_SA_INIT_1に含まれるT-PGW_BS_Identity）と比較する。両者を比較した結果が同一であった場合には、ＵＥ１は、Home Prefixを含むIKE_SA_INITメッセージをＩ−ＰＧＷ５ａへ送信した結果行われたＴ−ＰＧＷ５ｂからのＢＳ処理要求であることを認識することが可能となる。なお、UE_BS_Identityに対応するT-PGW_BS_IdentityをＵＥ１が導出する方法としては、UE_BS_Identityから求めたハッシュ値をT-PGW_BS_Identityとして用いてもよいし、UE_BS_IdentityとT-PGW_BS_Identityとの対応関係を示すテーブル情報を用いてもよい。この場合、テーブル情報は、３Ｇネットワーク内の情報サーバなどから取得することもできるし、オペレータによってＵＥ１にあらかじめ設定されていてもよい。また、ＵＥ１は情報サーバに問い合わせることで、UE_BS_Identityに対応するT-PGW_BS_Identityを取得してもよい。ハッシュ関数を用いた場合は、UE_BS_Identity、T-PGW_BS_Identity共に高度な暗号化アルゴリズムを用いているため、セキュリティを高めることができる。
なお、上述の説明では、UE_BS_IdentityがＩ−ＰＧＷ５ａによって生成され、T-PGW_BS_IdentityがＴ−ＰＧＷ５ｂによって生成されているが、例えば、UE_BS_Identity及びT-PGW_BS_Identityが両方共、Ｉ−ＰＧＷ５ａによって生成されてもよい。この場合、Ｉ−ＰＧＷ５ａは、UE_BS_IdentityをＵＥ１へ送信するとともに、そのUE_BS_Identityに対応したT-PGW_BS_IdentityをＡＡＡサーバ８ａ経由又はあるいは直接Ｔ−ＰＧＷ５ｂへ送信する。Ｔ−ＰＧＷ５ｂは、受信したT-PGW_BS_Identityを含むIKE_SA_INIT_1メッセージをＵＥ１へ送信することで、ＵＥ１が、Ｔ−ＰＧＷ５ｂからのＢＳ処理要求かどうかを確認できるようになる。
また、UE_BS_Identity及び／又はT-PGW_BS_IdentityをＩ−ＰＧＷ５ａ以外の装置、例えばＵＥ１やＴ−ＰＧＷ５ｂ、ＡＡＡ／ＨＳＳ８が生成してもよく、各BS_Identityが異なる装置によって生成されてよい。
また、UE_BS_IdentityとT-PGW_BS_Identityを同じ値にして、ＢＳ処理を実施することも可能である。その場合、ＵＥ１は、あらかじめＩ−ＰＧＷ５ａから取得したBS_Identity（図２のステップＳ３００５で受信したIKE_AUTH Responseに含まれるBS_Identity）を、IKE_SA_INITメッセージから取得したBS_Identity（図２のステップＳ３００８で受信したIKE_SA_INIT_1に含まれるBS_Identity）と比較し、同一であれば、Ｔ−ＰＧＷ５ｂからのＢＳ処理要求であることを認識する。Ｔ−ＰＧＷ５ｂも同様に、ＡＡＡ／ＨＳＳ８から通知されたBS_Identityと、ＵＥ１から通知されたBS_Identityを比較し、同一であれば、所望のＵＥ１からのレスポンスであることを認識する。また、UE_BS_IdentityとT-PGW_BS_Identityの両BS_IdentityをＵＥ１とＴ−ＰＧＷ５ｂに送ることで、ＵＥ１がUE_BS_Identity に対応するT-PGW_BS_Identityを知ることができるが、上述したようにＵＥ１とＰＧＷ５が任意のBS_Identityから共通のBS_Identityを取得できるテーブルを保持しているならば、両BS_Identityを送る必要はない。同様に、ＵＥ１やＰＧＷ５以外の装置が、上記テーブルを保持しており、ＵＥ１とＰＧＷ５がアクセス可能であれば、両BS_Identityを送る必要はない。なお、上記テーブルではなく、オペレータの命令やユーザによる操作によって変更不可能な固定の値を、ＵＥ１やＰＧＷ５とは関係なくＢＳの識別子として設定してもよい。
また、UE_BS_Identity及び／又はT-PGW_BS_Identityの生成方法としては、高度な暗号化アルゴリズム以外に、IKE_SA_INITメッセージで生成した共有鍵の利用や、任意の関数（例えば、ランダム関数など）を用いる方法、既存の値を利用するためにインデックスとして指定する方法が挙げられる。以下に、各使用方法について詳しく説明する。
IKE_SA_INITメッセージで生成した共有鍵の利用する方法を用いた場合、ＵＥ１とＩ−ＰＧＷ５ａとの間で既知な値を共有するため、新たにBS_Identityを生成する必要がない。また、共有鍵をUE_BS_Identityとし、T-PGW_BS_Identityは新たに生成してもよい。このように、生成済みの共有鍵を利用した場合には、新たにBS_Identityを生成する時間が短縮される。
また、任意の関数（例えば、ランダム関数など）を用いて、UE_BS_Identity及び／又はT-PGW_BS_Identityを生成する方法が採用されてもよい。ハッシュ関数などの高度な暗号化アルゴリズムを用いることにより、BS_Identity生成に要する時間が短縮される。
また、既存の値を利用するためにインデックスとして指定する方法を採用する場合には、一例として、UE_BS_Identityに‘Ｈ’を指定して送信すると、ＵＥ１やＴ−ＰＧＷ５ｂなどが、UE_BS_Identityは“HPLMN ID”であると判断できるように仕様を定義しておく。本手法は、BS_Identityを生成しているわけでないので、セキュリティ面は上記案と比べると低いが、実装の容易性、処理時間の面では優れている。
なお、上記した全使用方法はUE_BS_IdentityとT-PGW_BS_Identityの両方に適用する以外に、各BS_Identityで異なる使用方法を用いてもよい。各使用方法で共通して守らなければならないことは、ＵＥ１とＴ−ＰＧＷ５ｂが、両BS_Identityを確認できることである。
なお、ＵＥ１が接続するＮ３Ｇアクセス３において、ＮＡＴ（Network Address Translator）が配備されている場合、Ｔ−ＰＧＷ５ｂから開始されるＢＳ処理の第１のIKE_SA_INITメッセージ（図２のステップＳ３００８におけるIKE_SA_INIT_1メッセージ）がＵＥ１に到達せず、結果的にＴ−ＰＧＷ５ｂとの接続に失敗するという問題が起こり得る。しかしながら、従来のＢＳ処理方法において、ＵＥ１はＢＳ処理の初期段階でＮＡＴの有無を検出することができる（例えば、非特許文献７を参照）。また同様に、Ｉ−ＰＧＷ５ａにおいても同段階においてＮＡＴの有無を検出することができる。したがって、本問題は次の２通りの方法によって解決することができる。
１つ目の方法では、Ｎ３Ｇアクセス３にＮＡＴが配備されていることを検出したＩ−ＰＧＷ５ａは、Home Prefix確認要求メッセージに（例えば転送指示フィールドを利用するなどして）、Ｔ−ＰＧＷ５ｂからのＢＳ処理が３Ｇアクセス２経由で実施されるよう指示を含める。この指示は、Home Prefix確認要求返信メッセージに引き継がれ（例えばＢＳ指示フィールドを利用するなどして）、Ｔ−ＰＧＷ５ｂに転送される。このとき、Ｉ−ＰＧＷ５ａ、ＡＡＡサーバ８ａ、ＨＳＳ８ｂのいずれか（あるいは全てのノード）において、ＵＥアドレスにＵＥ１のホームプレフィクスを記載することにより、上記明示的な指示を不要とすることができ、処理並びにメッセージリソースの有効活用を図ることができる。また、上記明示的な指示を記載しておくことにより、ＵＥアドレスにホームプレフィクスを記載する必要がなくなり、同様にリソースの有効活用を図ることができる。
Ｔ−ＰＧＷ５ｂは、上記指示を受けてあるいはＵＥアドレスに記載されたホームプレフィクス宛にＢＳ処理を開始する。なお、上記明示的な指示を受けたときは、ＵＥアドレスに記載されたアドレスを参照することなく、自身が保持管理しているＵＥ１のホームプレフィクス宛にＢＳ処理を開始する。また、ＵＥ１のホームアドレスが明らかである場合は、ホームアドレスにＢＳ処理を開始してもよい。なお、Ｉ−ＰＧＷ５ａは、ＮＡＴを検出した際に、ＵＥ１に送信するIKE_AUTH Response（図２のステップＳ３００５で送信されるIKE_AUTH Response）の中で、Ｔ−ＰＧＷ５ｂからのＢＳ処理が３Ｇアクセス２経由で来るので待機するよう通知しておいてもよい。これにより、ＵＥ１は、３Ｇアクセス２に接続する通信インタフェースがアイドルモードに遷移している場合は自発的にアクティブモードに遷移させるなどの処理を行って、Ｔ−ＰＧＷ５ｂからのＢＳ処理開始（具体的にはIKE_SA_INITメッセージ）を即座に受信できるよう準備しておくことができ、接続のさらなる高速化を図ることができる。
２つ目の方法では、ＮＡＴが配備されていることを検出したＵＥ１は、IKE_AUTH Request（図２のステップＳ３００３）の中で、Ｉ−ＰＧＷ５ａに３Ｇアクセス２経由のＢＳ処理開始を要求する。これを受けてＩ−ＰＧＷ５ａは、上述の１つ目の方法を実施する。
次に、本発明を実施するための移動端末（ＵＥ１）の構成について説明する。以下、図３を参照しながら、本発明の第１の実施の形態におけるＵＥ１の構成について説明する。図３は、本発明の第１の実施の形態におけるＵＥ１の構成の一例を示す図である。
図３において、ＵＥ１は、アクセスネットワーク（３Ｇアクセス２又はＮ３Ｇアクセス３）とそれぞれ接続して下位レイヤにおける通信処理を行う第１無線通信部１０１及び第２無線通信部１０２、第１及び第２無線通信部１０１、１０２の上位でＩＰなどのパケット通信処理を実施するパケット処理部１０３、ＵＥ１とＰＧＷ５との間のＢＳ（ブートストラップ）処理を実施するＢＳ処理部１０４、ＤＮＳサーバ９への問い合わせメッセージを送信し、その応答として受信した結果から所定のアドレス情報を取得するＤＮＳクライアント処理部１０５、本発明における特徴的な処理を実施する接続制御部１０６、ＤＳＭＩＰやＭＩＰｖ６に基づいてＢＵ／ＢＡ交換などの移動管理処理をＰＧＷ５に対して実施するＭＩＰ処理部１０７を少なくとも有する。なお、第１及び第２無線通信部１０１、１０２は、３Ｇアクセス２、Ｎ３Ｇアクセス３のいずれに接続するものであってもよく、さらには一方の無線通信部（例えば、第１無線通信部１０１）が同時に３Ｇアクセス２とＮ３Ｇアクセス３に接続するものであってもよい。本発明の第１の実施の形態においては、一例として、ＵＥ１が２つの無線通信部を有し、一方の無線通信部（第１無線通信部１０１）が３Ｇアクセス２に、他方の無線通信部（第２無線通信部１０２）がＮ３Ｇアクセス３に接続するものとして説明する。
次に、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図４を用いて詳しく説明する。なお、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２（ホームリンク）に接続済みであり、Ｔ−ＰＧＷ５ｂに接続しているものとする。
図４は、本発明の第１の実施の形態におけるＵＥ１の処理フローの一例を示すフロー図である。本発明による接続制御部１０６は、まずＮ３Ｇアクセス３へのアタッチ（接続）処理を開始するため、第２無線通信部１０２に接続開始を指示する（ステップＳ５００２）。第２無線通信部１０２では、Ｎ３Ｇアクセス３における接続手順に従って、接続処理を実施する。Ｎ３Ｇアクセス３への接続が完了すると、Ｎ３Ｇアクセス３経由で接続するＰＧＷ５のアドレスを探索するため、ＤＮＳクライアント処理部１０５に探索開始を指示する（ステップＳ５００３）。このとき、接続制御部１０６は、接続先となるＰＧＷ５のアドレスを取得するため、接続先ネットワークＰＤＮの識別子であるＡＰＮやＰＧＷ５を識別するためのＨＡ−ＡＰＮなどから、標準的な方法により（例えば、非特許文献６に開示されている方法など）、ホームエージェント名（ＦＱＤＮ）を構築し、ＤＮＳクライアント処理部１０５に通知する。ＤＮＳクライアント処理部１０５では、通知されたホームエージェント名を記載したＤＮＳクエリをパケット処理部１０３、第２無線通信部１０２経由でＤＮＳサーバ９宛に送信する。また、その応答としてＤＮＳ応答を第２無線通信部１０２、パケット処理部１０３経由でＤＮＳサーバ９から受信し、ＤＮＳ応答から取得したＰＧＷアドレスを接続制御部１０６に転送する。
ここで、接続制御部１０６は、既に第１無線通信部１０１経由（３Ｇアクセス２経由）でホームリンクに接続済みであること、ＤＳＭＩＰあるいはＭＩＰｖ６に基づいて異なる接続リンクを確立してＰＧＷ５に接続しようとしていること、さらに接続先のＰＧＷアドレスをＤＮＳにより取得したこと、の３つの条件を満足する状況であるかを判定する（ステップＳ５００４）。いずれか１つの条件でも満たさない場合には、接続制御部１０６は、取得したＰＧＷアドレスに対して標準的なＢＳ処理を開始するようＢＳ処理部１０４に指示する。ＢＳ処理部１０４では、例えば図１２のステップＳ９００２からＳ９０１４に示すような標準的なＢＳ処理を実施し（ステップＳ５０４０）、続けてＰＧＷ５（Ｉ−ＰＧＷ５ａ）とＤＳＭＩＰあるいはＭＩＰｖ６に基づくＢＵ／ＢＡ交換を実施する（ステップＳ５０４１）。
一方、すべての条件を満足する場合、接続制御部１０６は、取得したＰＧＷアドレスに対して本発明に係るＢＳ処理を開始するようＢＳ処理部１０４に指示する。ＢＳ処理部１０４では、ＩＫＥ ＳＡを構築するための手順であるIKE_SA_INIT処理を、接続制御部１０６から通知されたＰＧＷアドレス（Ｉ−ＰＧＷ５ａのアドレス）に対して開始する（ステップＳ５００５）。IKE_SA_INIT処理が完了し、ＩＫＥ ＳＡが確立されると、ＢＳ処理部１０４は、ホームリンクに接続時に取得したホームプレフィクス（Home Prefix）をIKE_AUTH Requestメッセージに記載して送信する（ステップＳ５００６）。これにより、IKE_AUTH Requestメッセージ送信先のＰＧＷ５に対して、自ノードの収容状況を確認させることができ、これから接続しようとしているＰＧＷ５が自身を既に収容しているものであるか、すなわちホームリンク経由で接続済みのＰＧＷ５であるかの確認を取ることができる。
なお、既に従来の標準的なIKE_AUTH Requestメッセージは、ホームプレフィクスを記載するためのフィールドを有しており、本発明においてもそのフィールドを活用することができる。ただし、その場合は、ＰＧＷ５における処理の混乱（従来の標準的なＢＳ処理と本発明によるＢＳ処理を適切に区別して実施できなくなることによる混乱）を避けるため、収容状況の確認を指示するフラグや指示子を明示的に設けてもよい。なお、このようなフラグや指示子は、ホームプレフィクスを記載するフィールドを共有しない場合であっても明示的に設けることができる。
IKE_AUTH RequestメッセージはＢＳ処理部１０４からパケット処理部１０３、第２無線通信部１０２を介してＰＧＷ５宛に送信される。ＰＧＷ５は収容状況を確認した後、その応答としてIKE_AUTH ResponseメッセージをＵＥ１に送信し、IKE_AUTH Responseメッセージは、第２無線通信部１０２、パケット処理部１０３を介してＢＳ処理部１０４に転送される（ステップＳ５００７）。ＢＳ処理部１０４はIKE_AUTH Responseに記載されたパラメータ（少なくとも、判定結果、UE_BS_Identity、動作指示）を接続制御部１０６に通知し、接続制御部１０６において判定結果、動作指示について評価を行う（ステップＳ５００８）。
判定結果が少なくとも失敗を示す値（例えば“０”、FALSEなどの符号）でない場合、接続制御部１０６は、ＢＳ処理部１０４に対して残りのＢＳ処理を従来の標準的なＢＳ手順に基づいて継続実行するよう指示する。ＢＳ処理部１０４は残りのＢＳ処理、すなわち図１２に示すステップＳ９００８からＳ９０１４を実行し（ステップ５０３０）、続けてＰＧＷ５とＤＳＭＩＰあるいはＭＩＰｖ６に基づくＢＵ／ＢＡ交換を実施する（ステップＳ５０３１）。
一方、判定結果が失敗を示す値であり、動作指示が“待機”を示す値（例えば“Wait”などの状態を示す符号）である場合、接続制御部１０６はIKE_AUTH Responseで通知されたUE_BS_Identityに対応するT-PGW_BS_Identityを独自に生成（例えばUE_BS_Identityを元データとしてハッシュ計算を行う、など）するか、あるいはUE_BS_Identityに対応するT-PGW_BS_Identityをデータベースから取得する（ステップＳ５０１０）。
なお、UE_BS_Identity並びにT-PGW_BS_Identityの詳細については、本発明に係る通信システムの説明した際に記載したので、ここでは説明を割愛する。なお、ここではUE_BS_IdentityとT-PGW_BS_Identityの双方が存在し、通信システム並びに移動端末がそれらの存在を前提として動作するものとして説明するが、先述したBS_Identityの使用方法に合わせて、その一方が定義されない場合であっても、ＵＥ１は適宜その動作を選択ないし修正できるものとする。
ここで、接続制御部１０６は、動作指示が“待機”であったことを受けて、自分が接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）からのＢＳ処理が開始されることを察知し、外部からのIKE_SA_INITを受信できる状態にＢＳ処理部１０４をセットする（ステップＳ５０１１）。このとき、接続制御部１０６は、ＢＳ処理部１０４が既に開始したＰＧＷ５（Ｉ−ＰＧＷ５ａ）とのＢＳ処理に関する状態、データをクリアあるいはリセットしてもよい。これにより、今後必要とされないＩ−ＰＧＷ５ａとの接続に関する状態やデータを保持しておく必要がなくなり、リソースの有効活用を図ることができる。また、Ｔ−ＰＧＷ５ｂからのＢＳ処理が結果的に失敗（オペレータによる判断、ネットワーク側リソース欠落などを原因とする）することに備えて、Ｉ−ＰＧＷ５ａとの接続に関する状態データをあえて保持しておいてもよく、これにより結果的にＩ−ＰＧＷ５ａと接続しなければならなくなった場合に、ＢＳ処理の途中から再開することができる（少なくともＩＫＥ ＳＡは保持されており、IKE_AUTH Requestから実施することで十分である）。
やがてＴ−ＰＧＷ５ｂにおいてＵＥ１に対するＢＳ処理が開始され、IKE_SA_INITの最初のメッセージ（図２ではステップＳ３００８：IKE_SA_INIT_1として表記）がＵＥ１に配送される。Ｔ−ＰＧＷ５ｂからの最初のIKE_SA_INITメッセージは、第２無線通信部１０２、パケット処理部１０３を介してＢＳ処理部１０４に転送され、ＢＳ処理部１０４ではＴ−ＰＧＷ５ｂからのIKE_SA_INITメッセージであることを確認すると、メッセージに含まれるT-PGW_BS_Identityを接続制御部１０６に転送する。接続制御部１０６では、取得したT-PGW_BS_Identityが、先にステップＳ５００７で受信したIKE_AUTH Responseに記載されたUE_BS_Identityに基づいて生成あるいは取得したものと同じ（同じ値、同じ属性、所定の閾値内、所定の関数を経て同一性を検証、など）であるかを評価する（ステップＳ５０１２）。なお、図４に示すフローでは、IKE_SA_INITメッセージにT-PGW_BS_Identityが含まれており、IKE_AUTH Responseメッセージに記載されたUE_BS_Identityとの相関を判断することで評価を行う場合の処理について記載されているが、先述したBS_Identityの使用方法に応じた様々な方法によって、受信したIKE_SA_INITメッセージがＴ−ＰＧＷ５ｂからのＢＳ処理要求かどうかを判断することが可能である。
ステップＳ５０１２による処理で同じものである（相関を有する）と評価されなかった場合は、意図しないＰＧＷ５あるいは他ノードからのＢＳ処理であると判断し、接続制御部１０６は、受信したIKE_SA_INITメッセージを破棄あるいはリジェクトするようＢＳ処理部１０４に指示し、ＢＳ処理部１０４は指示に従ってメッセージを破棄あるいはリジェクトする（ステップＳ５０２０）。
一方、ステップＳ５０１２による処理で同じものである（相関を有する）と評価された場合は、応答として送信する第２のIKE_SA_INITメッセージ（図２のステップＳ３００９で送信されるIKE_SA_INIT_2）にUE_BS_Identityを格納して送信するようＢＳ処理部１０４に指示する（ステップＳ５０１３）。ＢＳ処理部１０４は、指示に従って、UE_BS_Identityを格納した第２のIKE_SA_INITメッセージをＴ−ＰＧＷ５ｂ宛に送信する。本IKE_SA_INITメッセージを受信したＴ−ＰＧＷ５ｂは、メッセージに格納されたUE_BS_Identityを用いて、意図したＵＥ１からの応答であるかを検証し、正しく検証が完了した場合には、以降のＢＳ処理がＴ−ＰＧＷ５ｂとの間で継続実行される（ステップＳ５０１４）。すべてのＢＳ処理が完了すると、接続制御部１０６は、ＤＳＭＩＰあるいはＭＩＰｖ６に基づくＢＵ／ＢＡ交換をＴ−ＰＧＷ５ｂと実施するようＭＩＰ処理部１０７に指示し、ＭＩＰ処理部１０７がＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（ステップＳ５０１５）。
次に、本発明を実施するためのＰＧＷ５の構成について説明する。以下、図８を参照しながら、本発明の第１の実施の形態におけるＰＧＷ５の構成について説明する。図８は、本発明の第１の実施の形態におけるＰＧＷ５の構成の一例を示す図である。
図８において、ＰＧＷ５は、コアネットワーク４と接続して下位レイヤにおける通信処理を行う通信部２０１、通信部の上位でＩＰなどのパケット通信処理を実施するパケット処理部２０２、ＵＥ１とＰＧＷ５との間のブートストラップ処理を実施するＢＳ処理部２０３、ＡＡＡサーバ８ａへの問い合わせメッセージと、ＵＥ１へのＢＳ指示を取得するＡＡＡクラインアント処理部２０４、本発明における特徴的な処理を実施する接続制御部２０５、ＤＳＭＩＰやＭＩＰｖ６に基づいてＢＵ／ＢＡ交換などの移動管理処理をＰＧＷ５に対して実施するＭＩＰ処理部２０６を少なくとも有する。
次に、図８に図示されている構成を有するＰＧＷ５の処理フローについて、本発明における特徴的な処理を実施する接続制御部２０５に係る処理を中心に、図９を用いて詳しく説明する。なお、ＰＧＷ５は、既に通信部２０１を介し、３Ｇアクセス２（ホームリンク）に接続済みであるものとする。また、ＵＥ１が最初にアタッチ（接続）処理を試みるＰＧＷ５は、Ｉ−ＰＧＷ５ａとする。
図９は、本発明の第１の実施の形態におけるＰＧＷ５の処理フローの一例を示すフロー図である。本発明によるＰＧＷ５は、ＵＥ１とＳＡを確立するためにＵＥ１からのＢＳを待つ。ＵＥ１がＩ−ＰＧＷ５ａとアタッチ（接続）処理を接続手順に従って開始すると、ＵＥ１からIKE_SA_INITメッセージが送られてくる（ステップＳ６００２）。その後、次ステップであるIKE_AUTH Requestメッセージ（ＵＥ１のHome Prefixが含まれている）をＩ−ＰＧＷ５ａが受信すると、Ｉ−ＰＧＷ５ａは、そのメッセージに格納されているHome PrefixがＩ−ＰＧＷ５ａの持つバインディングキャッシュに登録されているか確認する（ステップＳ６００３）。
なお、ＵＥ１とＴ−ＰＧＷ５ｂの３Ｇアクセス経由の接続には、ＰＭＩＰあるいはＧＴＰプロトコルが用いられるのに対し、今回のＮ３Ｇアクセス経由の接続では、ＭＩＰあるいはＤＳＭＩＰが用いられるため、Ｉ−ＰＧＷ５ａに向けてブートストラッピング処理が開始されている。コアネットワーク４の運用形態によっては、ＰＭＩＰあるいはＧＴＰで用いられるＵＥ１の位置管理を行うためのデータベース（例えばＰＭＩＰバインディングキャッシュ）と、ＤＳＭＩＰ／ＭＩＰで用いられる同ＵＥ１の位置管理を行うためのデータベース（例えばＭＩＰバインディングキャッシュ）はそれぞれ個別に管理運用されることも想定される。さらには、それぞれ（ＧＴＰ、ＰＭＩＰ、ＤＳＭＩＰ／ＭＩＰ）の位置管理機能が論理的あるいは物理的に異なる装置で実施されることも想定される。そのような場合、Ｉ−ＰＧＷ５ａは、ＵＥ１が送付したホームプレフィクスがバインディングキャッシュに登録されているかどうかをチェックする際に、ＤＳＭＩＰ／ＭＩＰで用いられる管理データベース（ＭＩＰバインディングキャッシュ）の確認だけではなく、Ｉ−ＰＧＷ５ａが管理する（あるいは、Ｉ−ＰＧＷ５ａの管轄対象である他ノードが管理する、さらにはＩ−ＰＧＷ５ａと同じドメインに配置された他ノードが管理する）ＰＭＩＰバインディングキャッシュや、ＧＴＰ用の位置管理データベースの確認も行うことが望ましい。
このとき、Ｉ−ＰＧＷ５ａのバインディングキャッシュに登録されていないHome Prefixであった場合、Ｉ−ＰＧＷ５ａは、UE_BS_Identityを生成（取得）する（ステップＳ６０１０）。なお、UE_BS_Identityを生成する方法は、上述のようにいくつか存在する。そして、Ｉ−ＰＧＷ５ａは、IKE_SA_INITメッセージに格納されていたHome Prefixを管理しているＴ−ＰＧＷ５ｂがＵＥ１に対してＢＳをするように指示するための動作指示を生成する（ステップＳ６０１１）。そして、IKE_SA_INITメッセージで受信したHome Prefixと、生成したUE_BS_Identityと、動作指示をＡＡＡサーバ８ａに送信する（ステップＳ６０１２）。なお、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａやＨＳＳ８ｂで検索及び特定されてもよく、あるいは、Ｉ−ＰＧＷ５ａによって検索及び特定されてもよい。
また、Ｉ−ＰＧＷ５ａは、ＡＡＡサーバ８ａ方向とは別に、ＵＥ１へ送信するためのＵＥ１への動作指示を生成する（ステップＳ６０１３）。そして、Home Prefixが異なっていたことを示すPrefix判定結果（例えば、Falseや‘１’など）と、生成したUE_BS_Identityと、ＵＥ１への動作指示をＵＥ１へ送信する（ステップＳ６０１４）。なお、ここでは、ステップＳ６０１１及びＳ６０１２における動作指示の送信処理（ＡＡＡサーバ８ａへの送信）の後で、ステップＳ６０１３及びＳ６０１４における動作指示の送信処理（ＵＥ１への送信）が行われるように説明しているが、これらの送信処理の順序は特に限定されず、任意の順序又は並列して行われてもよい。
一方、IKE_AUTH Requestメッセージに格納されているHome PrefixがＩ−ＰＧＷ５ａの持つバインディングキャッシュに登録されている場合（ステップＳ６００３）は、標準的なＢＳ処理を実行し（ステップＳ６０３０）、ＳＡ確立後にＵＥ１から送られてくるＢＵに対し、ＢＡを交換する（ステップＳ６０３１）。
また、ＰＧＷ５がＩ−ＰＧＷ５ａではなくＴ−ＰＧＷ５ｂとして働く場合には、IKA_SA_INITメッセージではなく、Home Prefix確認要求返信メッセージを受信する（ステップＳ６００４）。この場合、Ｔ−ＰＧＷ５ｂは、受信したUE_BS_IdentityからT-PGW_BS_Identityを生成（取得）する（ステップＳ６０２０）。そして、Ｔ−ＰＧＷ５ｂは、生成したT-PGW_BS_Identityを格納したIKE_SA_INIT_1メッセージをＵＥ１に送信する（ステップＳ６０２１）。Ｔ−ＰＧＷ５ｂは、IKE_SA_INIT_1メッセージの返信と予想されるIKE_SA_INIT_2メッセージを受信すると、ＡＡＡサーバ８ａから転送されてきたUE_BS_Identity（ステップＳ６００４で受信したHome Prefix確認要求返信メッセージに含まれているUE_BS_Identity）を使用して、IKE_SA_INIT_2メッセージに格納されているBS_Identityと照合する（ステップＳ６０２２）。一致していた場合、引き続き標準的なＢＳ処理を実施し、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立する（ステップＳ６０４０）。そして、ＳＡ確立後、ＵＥ１から送られてくるＢＵに対し、ＢＡを交換する（ステップＳ６０４１）。
なお、BS_Identityの使用方法によっては、ステップＳ６００４で受信したHome Prefix確認要求返信メッセージにT-PGW_BS_Identityやその他の種類の値が含まれている場合があるが、このような場合も同様にこれらの値を用いて、IKE_SA_INIT_2メッセージに含まれているBS_Identityの照合を行うことが可能である。
次に、本発明を実施するためのＡＡＡサーバ８ａの構成について説明する。以下、図１０を参照しながら、本発明の第１の実施の形態におけるＡＡＡサーバ８ａの構成について説明する。図１０は、本発明の第１の実施の形態におけるＡＡＡサーバ８ａの構成の一例を示す図である。なお、上述のように、ＡＡＡサーバ８ａとＨＳＳ８ｂは物理的又は論理的に同一の装置に実装されるものであってもよく、例えば、図１０に示す構成がＨＳＳ８ｂに実装されてもよい。
図１０において、ＡＡＡサーバ８ａは、コアネットワーク４と接続して下位レイヤにおける通信処理を行う通信部３０１、通信部の上位でＩＰなどのパケット通信処理を実施するパケット処理部３０２、本発明における特徴的な処理を実施する接続制御部３０３、ＤＳＭＩＰやＭＩＰｖ６などのプロトコルに対応するＵＥ１の認証／承認処理を実施する認証／承認処理部３０４を少なくとも有する。
次に、図１０に図示されている構成を有するＡＡＡサーバ８ａの処理フローについて、本発明における特徴的な処理を実施する接続制御部３０３に係る処理を中心に、図１１を用いて詳しく説明する。なお、ＡＡＡサーバ８ａは、既に通信部３０１を介して、コアネットワーク４と接続済みであるものとする。また、ＵＥ１が最初にアタッチ（接続）処理を試みるＰＧＷ５はＩ−ＰＧＷ５ａとする。
図１１は、本発明の第１の実施の形態におけるＡＡＡサーバ８ａの処理フローの一例を示すフロー図である。本発明によるＡＡＡサーバ８ａは、ＰＧＷ５から送られてくるHome Prefix確認要求メッセージを待つ。ＵＥ１がＩ−ＰＧＷ５ａとアタッチ（接続）処理を接続手順に従って開始すると、Ｉ−ＰＧＷ５ａからHome Prefix確認要求メッセージが送られてくる（ステップＳ７００２）。このメッセージを受信したＡＡＡサーバ８ａは、Home Prefix確認要求メッセージに動作指示が格納されているかどうか確認し、さらにその動作指示が転送指示であるかどうかを確認する（ステップＳ７０１０）。動作指示が転送指示であった場合には、ＡＡＡサーバ８ａは、Home Prefix確認要求メッセージに格納されていたHome PrefixがＨＳＳ８ｂの持つサブスクリプションデータ（Subscription data）に登録されているかどうかをＨＳＳ８ｂへ問い合わせる。ＨＳＳ８ｂは、問い合わせメッセージを受け、Subscription dataを参照して対象のHome Prefixが登録されているか確認し、登録されていた場合には対象のHome Prefixを管理しているＴ−ＰＧＷ５ｂのアドレスをＡＡＡサーバ８ａに返信する（ステップＳ７０１１）。ＡＡＡサーバ８ａは、ＨＳＳ８ｂから返信されたメッセージにＴ−ＰＧＷ５ｂのアドレスが格納されているか確認する（ステップＳ７０１２）。Ｔ−ＰＧＷ５ｂのアドレスが格納されていた場合は、ＵＥ１にＢＳするようにＢＳ指示を生成する（ステップＳ７０１３）。そして、ＵＥ１のアドレスと、Ｉ−ＰＧＷ５ａから送られてきたUE_BS_Identityと、ステップＳ７０１３で生成したＢＳ指示とをＴ−ＰＧＷ５ｂに送信する（ステップＳ７０１４）。
また、ＨＳＳ８ｂから返信されたメッセージにＴ−ＰＧＷ５ｂのアドレスが格納されていなかった場合（ステップＳ７０１２）や、Home Prefix確認要求メッセージに転送指示が格納されていなかった場合（ステップＳ７０１０）は、Ｉ−ＰＧＷ５ａにその結果（例えば、Falseや‘１’など）を返信する（ステップＳ７０３０）。
また、ＰＧＷ５からHome Prefix確認要求メッセージではなく、Authentication-Request/Identityメッセージを受信した場合（ステップＳ７０２０）は、Authentication-Request/Identityメッセージに応じて、ＨＳＳ８ｂにUser Profile（ユーザプロファイル）とＡＶｓ（Authentication Vectors：認証ベクタ）を要求し、取得する（ステップＳ７０２１）。User ProfileとＡＶｓ取得後、ＡＡＡサーバ８ａは、EAP-Request/AKA-ChallengeメッセージをＰＧＷ５に返信する（ステップＳ７０２２）。そして、ＡＡＡサーバ８ａはEAP-Request/AKA-Challengeメッセージの返信であるEAP-Response/AKA-Challengeメッセージを受信し（ステップＳ７０２３）、その返信であるAuthentication-Answer/EAP-Success + keying material（鍵素材）メッセージをＰＧＷ５に返信する（ステップＳ７０２４）。
＜第２の実施の形態＞
次に、本発明の第２の実施の形態におけるシステム動作の一例について、図１３を用いて詳しく説明する。図１３は、本発明の第２の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。図１３は、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによって構成され、処理シーケンスの一例が図示されている。
以下、従来の技術と比較しながら、図１３に図示されている本発明の第２の実施の形態におけるシステム動作の一例について説明する。本発明の第２の実施の形態の処理フローのステップＳ９１０１〜Ｓ９１０５は、従来技術のPDN GW reallocation procedureのステップＳ９００１〜Ｓ９００５（図１２に図示）と同一である。
従来技術のPDN GW reallocation procedure（図１２に図示されている処理フロー）では、Ｉ−ＰＧＷ５ａはEAP-Request/AKA-Challengeメッセージを受信することで、Ｔ−ＰＧＷ５ｂのアドレスを取得するが（図１２のステップＳ９００６）、実際にＵＥ１へＴ−ＰＧＷ５ｂの存在（アドレス）を通知するのは、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立後に実施されるＢＵ／ＢＡ交換時である（図１２のステップ９０１６）。
一方、本発明の第２の実施の形態においては、Ｉ−ＰＧＷ５ａは、図１３に示したポイントＡ（ステップＳ９１０６でＩ−ＰＧＷ５ａがＡＡＡサーバ８ａからのEAP-Request/AKA-Challengeメッセージを受信したとき）においてＴ−ＰＧＷ５ｂのアドレスを取得した時点で、例えば、ステップＳ９１０７でＵＥ１へ送信するIKE_AUTH Responseメッセージ（あるいは、その他のメッセージを利用してもよい）にＴ−ＰＧＷ５ｂのアドレスを挿入することで、ステップＳ９１０６で取得したＴ−ＰＧＷ５ｂのアドレスをＵＥ１に通知する。
ここで、本発明の第２の実施の形態においては、ＵＥ１がＩ−ＰＧＷ５ａとの間で接続認証を行っている途中で、Ｔ−ＰＧＷ５ｂのアドレスがＵＥ１へ通知される。これは、ＵＥ１がＮ３Ｇアクセス３にアタッチ（接続）する際に、コアネットワーク４によるアクセス認証（図１３のステップＳ９１００）が既に実施されており、その認証結果を担保にＵＥ１へのＴ−ＰＧＷ５ｂのアドレスの通知許可が決定されるためである。
このように、本発明の第２の実施の形態によれば、ＵＥ１は、従来技術と比較してより早期の段階（例えば、IKE_AUTH ResponseメッセージからＴ−ＰＧＷ５ｂのアドレスを抽出した段階）で、Ｔ−ＰＧＷ５ｂのアドレスを把握することが可能となり、所望のＰＧＷ５（Ｔ−ＰＧＷ５ｂ）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）に接続を行おうとしていることを認識できるようになる。その結果、ＵＥ１は、従来技術と比較してより早期の段階で、Ｉ−ＰＧＷ５ａではなくＴ−ＰＧＷ５ｂとＢＳをやり直す処理（ステップＳ９２０２〜Ｓ９２１４：標準的なＢＳ）を開始することが可能となり、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立した後、ＵＥ１及びＴ−ＰＧＷ５ｂはＢＵ／ＢＡの交換を実施することが可能となる（ステップＳ９２１５、Ｓ９２１６））。
ただし、ステップＳ９１０７でIKE_AUTH ResponseメッセージをＵＥ１へ送信した時点では、ＡＡＡサーバ８ａは、ＵＥ１に対するチャレンジ情報を送信した後にレスポンス情報の受信を待っている状態であり、少なからずＵＥ１に関する状態を保持した状態にある。したがって、ＵＥ１は、図１３に図示されているように、ステップＳ９１０８においてIKE_AUTH Request相当のメッセージを送信するなどして、ＡＡＡサーバ８ａの状態待ちを解消し、ステップＳ９１１２においてIKE_AUTH Response相当のメッセージを受信するなどして、実施中のＢＳ処理が終了したことを確認する必要があるかもしれない（ステップＳ９１０８〜Ｓ９１１２）。
ＵＥ１は、ＡＡＡサーバ８ａの状態待ちを解消する処理によってＴ−ＰＧＷ５ｂとの接続が遅延してしまわないようにするため、ステップＳ９１０８〜Ｓ９１１２におけるＡＡＡサーバ８ａの状態待ちの解消処理と並列して、ステップＳ９２０２〜Ｓ９２１６におけるＴ−ＰＧＷ５ｂとの接続処理を行ってもよい。これにより、ＵＥ１とＴ−ＰＧＷ５ｂとの間のＳＡ確立に要する時間が、ＡＡＡサーバ８ａの状態待ちの解消の返信であるIKE_AUTH Response相当のメッセージを受信するまでの時間分だけ短縮可能となる。
＜第３の実施の形態＞
次に、本発明の第３の実施の形態におけるシステム動作の一例について、図１４から１６を用いて詳しく説明する。図１４は、本発明の第３の実施の形態におけるシステム動作の一例を説明するための第１のシーケンス図である。図１４には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
本発明の第３の実施の形態では、Ｔ−ＰＧＷ５ｂのアドレスが、IKE_AUTHメッセージ交換の完了後、すなわちＵＥ１とＡＡＡサーバ８ａが相互認証に成功して作成されたＭＳＫがＵＥ１とＩ−ＰＧＷ５ａとの間で交換された後に通知される場合のＰＧＷ切り替え方法について説明する。以下、従来技術のPDN GW reallocation procedure（図１２に図示されている処理フロー）と比較しながら、図１４に図示されている本発明の第３の実施の形態におけるシステム動作の一例について説明する。
図１４において、本発明の第３の実施の形態の処理フローのステップＳ１０００１〜Ｓ１０００９は、従来技術のPDN GW reallocation procedureのステップＳ９００１〜Ｓ９００９（図１２に図示）と同一であるので説明を省略する。
続いて、従来技術のPDN GW reallocation procedure（図１２に図示）における次ステップＳ９０１０では、ＡＡＡサーバ８ａがＩ−ＰＧＷ５ａ経由でＵＥ１から送られてきたEAP-Responseメッセージを処理し、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立に必要である鍵（Master Session key：以降、ＭＳＫと呼ぶ）と、ＵＥ１にとっての切り替え先となるＴ−ＰＧＷ５ｂのアドレスとをＩ−ＰＧＷ５ａに送信する（図１２、ステップＳ９０１０）。一方、本発明の第３の実施の形態では、従来ではＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに送信されるＭＳＫとＴ−ＰＧＷ５ｂのアドレスに、更にUE_BS_Identityを加えたAuthentication-AnswerメッセージをＩ−ＰＧＷ５ａに送信する（図１４、ステップＳ１００１０）。
図１８Ｂは、図１４のステップＳ１００１０においてＡＡＡサーバ８ａがＩ−ＰＧＷ５ａに送信する応答メッセージの一例として、Authentication-Answerメッセージのフォーマット例を示す図である。ＡＡＡサーバ８ａは、従来の標準的なAuthentication-Answerメッセージ４１０１に加えて、ＭＳＫ（鍵）フィールド４１０２、ＢＳ識別子フィールド（UE_BS_Identity/T-PGW_BS_Identity）４１０３を設ける。ＭＳＫ（鍵）フィールド４１０２は、ＵＥ１とＩ−ＰＧＷ５ａとの間で使用する鍵をＩ−ＰＧＷ５ａへ送信するためのフィールドである。なお、ＡＡＡサーバ８ａは、ＭＳＫ（鍵）フィールド４１０２にＭＳＫを格納してもよく、あるいは、ＭＳＫ（鍵）フィールド４１０２を使用せずにAuthentication-Answerメッセージ４１０１内にＭＳＫを格納してもよい。Authentication-Answerメッセージ４１０１内にＭＳＫを格納する場合には、応答メッセージにＭＳＫ（鍵）フィールド４１０２を設けなくてもよい。
また、ＢＳ識別子フィールド４１０３は、使用用途によってUE_BS_IdentityやT-PGW_BS_IdentityをＰＧＷ５に通知することが可能である。また、標準的なAuthentication-Answerメッセージの既存のペイロードにBS_Identityを記載し、ＰＧＷ５に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続く本発明の第３の実施の形態の処理フローのステップＳ１００１１〜Ｓ１００１３は、従来技術のPDN GW reallocation procedureのステップＳ９０１１〜Ｓ９０１３（図１２に図示）と同一であるので説明を割愛する。
続いて、従来技術のPDN GW reallocation procedureにおける次ステップでは、Ｉ−ＰＧＷ５ａからＵＥ１にＴ−ＰＧＷ５ｂのアドレスなどが送信される（図１２、ステップＳ９０１４）。一方、本発明の第３の実施の形態では、ＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに従来送信されていたＭＳＫに加えて、Ｔ−ＰＧＷ５ｂのアドレスと、ＡＡＡサーバ８ａから通知されたUE_BS_IdentityとをIKE_AUTH Responseメッセージに乗せてＵＥ１に通知する（図１４、ステップＳ１００１４）。
図１７Ｂは、図１４のステップＳ１００１４においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３１０１に加えて、ＢＳ識別子（UE_BS_Identity/T-PGW_BS_Identity）フィールド３１０２を設け、それぞれの値をＵＥ１に通知することができる。ＢＳ識別子（BS_Identity）フィールド３１０２では、使用用途によってUE_BS_IdentityやT-PGW_BS_IdentityをＰＧＷ５に通知することが可能である。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してT-PGW_BS_Identityを記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよいが、IKE_AUTH Responseメッセージの送信と同時、あるいはIKE_AUTH Responseメッセージよりも後に送信されることが望ましい。
なお、ここでは、IKE_AUTHメッセージ交換（図１４、ステップＳ１００１２、Ｓ１００１３）によってＵＥ１とＩ−ＰＧＷ５ａとの間でＭＳＫが交換された後に、Ｉ−ＰＧＷ５ａからＵＥ１に対してＴ−ＰＧＷ５ｂのアドレス通知（例えば、ステップＳ１００１４のIKE_AUTH Responseメッセージによる通知）が行われているが、ＡＡＡサーバ８ａによるＵＥ１の認証が成功した時点（すなわち、ステップＳ１０００９で受信したチャレンジ情報に基づいてＡＡＡサーバ８ａがＵＥ１の認証を完了した時点）で、ネットワーク側からＵＥ１に対してＴ−ＰＧＷ５ｂのアドレスを通知することも可能である。この場合には、ステップＳ１０００９で受信したチャレンジ情報の処理が完了した後に、任意のメッセージ（例えば、ステップＳ１００１０、Ｓ１００１２におけるメッセージ）にＴ−ＰＧＷ５ｂのアドレスを格納してＵＥ１へ通知してもよい。
続いて、ＵＥ１は、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立するために、ＢＳ処理を開始する。ＵＥ１とＴ−ＰＧＷ５ｂは、ＵＥ１認証を行うIKE_AUTHメッセージを保護するために、ＵＥ１とＴ−ＰＧＷ５ｂとの間でIKE_SA_INITメッセージ交換を実施し、ＵＥ１とＴ−ＰＧＷ５ｂ間の共有鍵を生成する（図１４、ステップＳ１０１０１）。
次に、ＵＥ１はIKE_AUTH Requestメッセージを作成し、先にIKE_SA_INITメッセージ交換を通じて生成したＵＥ１とＴ−ＰＧＷ５ｂとの間の共有鍵を使用して暗号化し、Ｔ−ＰＧＷ５ｂに送信する。ここで、先にＵＥ１とＩ−ＰＧＷ５ａとの間で実施したＳＡ確立の際に生成されたＭＳＫ（鍵）を再利用するよう要求することにより、従来技術ではこの後に必要であったＵＥ１とＡＡＡサーバ８ａとの間の相互認証を省略することができる。そのため、ＵＥ１は、先に生成したＭＳＫの再利用を示すReuse IndicatorをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに送信する（図１４、ステップＳ１０１０２）。
なお、Reuse indicatorは、ＵＥ１とＩ−ＰＧＷ５ａとの間のブートストラップ処理の過程でＩ−ＰＧＷ５ａ又はＡＡＡサーバ８ａなどが生成し、ＵＥ１に通知するものであってもよい。特にＡＡＡサーバ８ａが生成してＵＥ１に通知することにより、ＡＡＡサーバ８ａあるいはＡＡＡサーバ８ａを含むネットワークシステムが、鍵の再利用をサポートあるいは許可することの表明をＵＥ１に対して行うことができ、ＵＥ１にとっては、確信を持って鍵の再利用を要求することができ、ひいては所望のＴ−ＰＧＷ５ｂとの切り替え接続をより確実に短時間で終えることができるようになる。
さらには、ＡＡＡサーバ８ａがReuse Indicatorを生成及び通知したが、そのドメインあるいはコアネットワーク４のＰＧＷ５がサポートあるいは許可しない場合（例えばローミングＵＥ１に対しては許可しないなどの理由から）は、ＰＧＷ５がReuse Indicatorを除去してＵＥ１に通知しないようにしてもよい。これにより、例えばＵＥ１のホームネットワーク（ＨＰＬＭＮ：Home Public Land Mobile Network）では鍵の再利用がサポートあるいは許可されても、ＵＥ１の在圏ネットワーク（ＶＰＬＭＮ：Visited Public Land Mobile Network）ではサポートあるいは許可されない場合に対応することができるようになる。
また、Ｉ−ＰＧＷ５ａを通じてＡＡＡサーバ８ａと既に相互認証を完了しているＵＥ１からのＢＳ処理であることを、後のＴ−ＰＧＷ５ｂ経由の相互認証処理時にＡＡＡサーバ８ａが識別可能にするために、ＵＥ１はUE_BS_IdentityをIKE_AUTH Requestメッセージに格納する（図１４、ステップＳ１０１０２）。
図１７Ａは、図１４のステップＳ１０１０２においてＵＥ１がＴ−ＰＧＷ５ｂに送信するメッセージの一例として、IKE_AUTH Requestメッセージのフォーマット例を示す図である。ＵＥ１は、従来の標準的なIKE_AUTH Requestメッセージ３００１に加えて、Reuse Indicatorフィールド３００２、ＵＥ用ＢＳ識別子（UE_BS_Identity）フィールド３００３を設け、それぞれの値をＴ−ＰＧＷ５ｂに通知することができる。また、標準的なIKE_AUTH Requestメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してReuse Indicatorを記載し、ＵＥ１に通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればIKE_AUTH Requestメッセージ以外のメッセージであってもよい。
Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてきたIKE_AUTH Requestメッセージに含まれるReuse indicatorとUE_BS_IdentityとをＡＡＡサーバ８ａに転送する（図１４、ステップＳ１０１０３）。なお、Reuse IndicatorとUE BS Identityは、ＵＥ１がIKE_SA_INITメッセージを通じてＴ−ＰＧＷ５ｂに通知し、Ｔ−ＰＧＷ５ｂはIKE SA INITメッセージの交換と並行して同パラメータをＡＡＡサーバ８ａに通知するものであってもよい。
図１８Ａは、図１４のステップＳ１０１０３においてＴ−ＰＧＷ５ｂがＡＡＡサーバ８ａに送信するメッセージの一例として、Authentication-Requestメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なAuthentication-Requestメッセージ４００１に加えて、Reuse Indicatorフィールド４００２、ＵＥ用ＢＳ識別子（UE_BS_Identity）フィールド４００３を設け、それぞれの値をＡＡＡサーバ８ａに通知することができる。また、標準的なAuthentication-Requestメッセージの既存のペイロードにReuse IndicatorとUE_BS_Identityとを記載し、ＡＡＡサーバ８ａに通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればAuthentication-Requestメッセージ以外のメッセージであってもよい。
ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから転送されてきたReuse indicatorを受けて、先にＵＥ１とＩ−ＰＧＷ５ａとの間でＳＡ確立した際のＭＳＫの再利用が要求されていると判断し、ＡＡＡサーバ８ａが保持するUE_BS_Identityに対応しているＭＳＫをＴ−ＰＧＷ５ｂに通知する。なお、UE_BS_Identityは、一度フル認証を完了しているＵＥ１であることを確認できるパラメータ（例えば、User IDなど）に代替してもよい。ＭＳＫを通知すると同時に、UE_BS_Identityに対応するT-PGW_BS_Identityも通知する（図１４、ステップＳ１０１０４）。なお、T-PGW_BS_Identityは、ＡＡＡサーバ８ａ自身が生成してもよいし、BS_Identityリストを保持しているネットワーク上のデータベースサーバ（不図示）が設置されている場合は、データベースサーバに問い合わせてUE BS Identityに対応するT-PGW BS_Identityを取得して利用してもよい。
ここで、ＭＳＫの再利用が先に指示された異なるＰＧＷ５への切り替え接続に限って許可される場合（任意のＰＧＷ５からの接続に対してＭＳＫの再利用を許可しない場合）に対応するため、Ｔ−ＰＧＷ５ｂが自身の情報（例えば、ＩＰアドレスやＰＧＷ５の識別子など）を、ステップＳ１０１０３を通じてＡＡＡサーバ８ａに通知することが考えられる。これにより、ＡＡＡサーバ８ａにおいて、本接続要求が先にＵＥ１に対して指示したＴ−ＰＧＷ５ｂへの切り替え接続要求であることを確認することができ、ＭＳＫの再利用を正しく許可することができる。
図１８Ｂは、図１４のステップＳ１０１０４においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージの一例として、Authentication-Answerメッセージのフォーマット例を示す図である。ＡＡＡサーバ８ａは、従来の標準的なAuthentication-Answerメッセージ４１０１に加えて、ＭＳＫ（鍵）フィールド４１０２、ＢＳ識別子フィールド（UE_BS_Identity/T-PGW_BS_Identity）４１０３を設ける。ステップＳ１０１０４では、ＭＳＫ（鍵）フィールド４１０２にＵＥ１とＩ−ＰＧＷ５ａとの間で生成されたＭＳＫを格納する。なお、このＭＳＫは、標準的なAuthentication-Answerメッセージ４１０１内にあるＭＳＫを格納するフィールドに格納されてもよい。その際、ＭＳＫ（鍵）フィールド４１０２を新たに設ける必要はない。また、ＢＳ識別子フィールド４１０３は、使用用途によってUE_BS_IdentityやT-PGW_BS_IdentityをＰＧＷ５に通知することが可能である。また、標準的なAuthentication-Answerメッセージの既存のペイロードにBS_Identityを記載し、Ｔ−ＰＧＷ５ｂに通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから通知されたＭＳＫ（実際にはＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立時に生成されたもの）を用いて生成したAUTHパラメータ値と、再利用を許諾したＡＡＡサーバ８ａが先にＩ−ＰＧＷ５ａとの接続時にＵＥ１をサーブしたのと同じノードであることをＵＥ１が正しく識別するためのT-PGW_BS_IdentityとをIKE AUTH Responseメッセージに格納して、ＵＥ１へ送信する（図１４、ステップＳ１０１０５）。ここで、ステップＳ１００１２〜Ｓ１００１４を通じて、既にＵＥ１はＭＳＫを生成できているので、ステップＳ１０１０５においては認証の成功のみを伝えるだけで十分である（認証の成功と同時にＭＳＫの再利用が承認されたことの通知でもあるため）。
図１７Ｂは、図１４のステップＳ１０１０５においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３１０１に加えて、ＢＳ識別子（BS_Identity）フィールド３１０２を設け、それぞれの値をＵＥ１に通知することができる。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してT-PGW_BS_Identityを記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。
IKE AUTH Responseメッセージを受信したＵＥ１は、UE_BS_IdentityとT-PGW_BS_Identityとの相関を検証し、正しく対応するものであることを確認できたら、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図１４、ステップＳ１０２０１）。
なお、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証のために有用であるが、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合は、これらのBS_Identityを省略することもできる。
また、Ｔ−ＰＧＷ５ｂへの切り替え指示後もＡＡＡサーバ８ａがＵＥ１に対する状態を保持できる場合には、ＵＥ１が通知するReuse Indicatorも省略することができる。この場合、ＡＡＡサーバ８ａは、User IDなどを基にＵＥ１の識別を行い、保持しておいたＵＥ１に対する状態に基づいて鍵データを抽出し、Ｔ−ＰＧＷ５ｂに通知することができる。ただし、一部のＡＡＡサーバ８ａにおいては、切り替え指示後はＵＥ１に対する状態を解消することも想定されるため、汎用性を確保する目的でReuse IndicatorをＵＥ１から通知することは有用である。
以上の動作によって、従来技術のPDN GW reallocation procedureでは、ＵＥ１とＡＡＡサーバとの８ａ間においてＩ−ＰＧＷ５ａとＴ−ＰＧＷ５ｂで計２回のＵＥ認証（Full Authentication）を実施する必要があったが、上述したように鍵の再利用を行うことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続する際のブートストラップ処理のメッセージ数削減と切り替え時間の短縮を図ることができるようになる。
なお、過去にＵＥ１が他のＰＧＷ５とＳＡ確立を実施した実績がある場合、ＵＥ１に対するＰＧＷ５の切り替え要求（すなわち切り替え先ＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスの通知）は、上記説明したステップＳ１００１４より前に実施することも可能である（例えば、図１４のステップＳ１０００７など）。例えば、ＵＥ１は、ステップＳ１０１０２で送信されるReuse IndicatorをステップＳ１０００３のIKE AUTH Requestメッセージに含めて送信する。このReuse Indicatorを参照したＩ−ＰＧＷ５ａは、ステップＳ１０００４〜Ｓ１０００６の処理において、ステップＳ１０１０３及びＳ１０１０４と同様の手順で、ＵＥ１に対して確立済みの鍵をＡＡＡサーバ８ａから取得する（このとき同時に切り替え先ＰＧＷ５のアドレスも取得することになる）。そして、Ｉ−ＰＧＷ５ａは、ステップＳ１０００７で切り替え先ＰＧＷ５のアドレスを含むIKE_AUTH responseメッセージ（すなわち、上記のステップＳ１０１０５で送信されるIKE_AUTH responseメッセージと同等のメッセージ）をＵＥ１へ送信することによって、切り替え先ＰＧＷ５のアドレスをＵＥ１に通知することが可能となる。これにより、ＵＥ１は過去に確立した鍵を再利用して高速に切り替え先ＰＧＷ５のアドレスを取得することができ、ひいては本来接続を希望しないＰＧＷ５が割り当てられた場合でも、所望のＰＧＷ５への切り替え接続を高速に実施することができる。
また、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂへの切り替えを指示するタイミング（図１４、ステップＳ１００１０）で、生成したＭＳＫをＴ−ＰＧＷ５ｂに通知してもよい。具体的には、図１５を用いて説明する。
図１５は、本発明の第３の実施の形態におけるシステム動作の一例を説明するための第２のシーケンス図である。図１５には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図１５の処理フローのステップＳ１１００１〜Ｓ１１０１０は、図１４の処理フローのステップＳ１０００１〜Ｓ１００１０と同一であるので説明を省略する。ステップＳ１１０１０の段階で、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂにＭＳＫを通知することが可能である。ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知する手法としては、例えば、Ｉ−ＰＧＷ５ａにUE_BS_Identityを格納したAuthentication-Answerメッセージを送信する処理と同時に、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立処理の過程で生成したＭＳＫと、UE_BS_Identityに対応するT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに送信する（図１５、ステップＳ１１０１１）。
図１９は、図１５のステップＳ１１０１１においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージの一例として、BS_Identity通知メッセージのフォーマット例を示す図である。ＡＡＡサーバ８ａは、宛先アドレスフィールド５００１にＴ−ＰＧＷ５ｂのアドレス、ソースアドレスフィールド５００２に自アドレス、ＭＳＫ（鍵）フィールド５００３にＵＥ１とＩ−ＰＧＷ５ａとの間で生成されたＭＳＫ、ＵＥアドレスフィールド５００４にＭＳＫに対応するＵＥ１のアドレス（例えば、ＵＥ１のＣｏＡ）、T-PGW_BS_Identityフィールド５００５にUE_BS_Identityに対応しているT-PGW_BS_Identityを記載して、Ｔ−ＰＧＷ５ｂに送信する。なお、BS_Identity通知メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いてもよい。また、BS_Identity通知メッセージに、ＵＥ１のUser IDを含めてもよく、これによりＴ−ＰＧＷ５ｂがＵＥ１からIKE_AUTH Requestメッセージを受信したとき、そのＵＥ１に関してフル認証が完了しているＵＥ１なのかを判別しやすくなり、より確実にＵＥ１を照合することが可能となる。
続く図１５の処理フローのステップＳ１１０１２〜Ｓ１１１０２は、図１４の処理フローのステップＳ１００１１〜Ｓ１０１０２と同一であるので説明を割愛する。
Reuse indicatorとUE_BS_Identityが格納されたIKE_AUTH Requestメッセージ（図１５、ステップＳ１０１０２に対応）を受信したＴ−ＰＧＷ５ｂは、ステップＳ１１０１１でＡＡＡサーバ８ａから受信したT-PGW_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に返信する（図１５、ステップＳ１１１０３）。なお、Ｔ−ＰＧＷ５ｂは、ステップＳ１１１０２で受信したUE_BS_IdentityとステップＳ１１０１１で受信したT-PGW_BS_Identityとが正しく対応するものであるか確認してもよい（例えば、ハッシュ値の検算や、ネットワーク上のBS_Identityリストを管理しているデータベースへの問合せなど）。また、ＵＥ１は既にステップＳ１１０１３のIKE_AUTH ResponseメッセージによってＭＳＫを取得しているので、Ｔ−ＰＧＷ５ｂは、ステップＳ１１１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納して通知する必要はない。ただし、例えば、ＵＥ１が何らかの理由でＭＳＫを保持していない（例えば、既に廃棄しているなど）可能性も考えられるので、Ｔ−ＰＧＷ５ｂが、ステップＳ１１１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納してＵＥ１へ通知して、ＵＥ１がＭＳＫを確実に把握できるようにしてもよい。
図１５のステップＳ１１１０３におけるＴ−ＰＧＷ５ｂからＵＥ１に送信する応答メッセージの一例であるIKE_AUTH Responseメッセージのフォーマット例は、図１７Ｂに図示されているものであり、図１４のステップＳ１０１０５におけるIKE_AUTH Responseメッセージのフォーマット例と同一であるため、説明を割愛する。
IKE AUTH Responseメッセージを受信したＵＥ１は、UE_BS_IdentityとT-PGW_BS_Identityとの相関を検証し、正しく対応するものであることを確認できたら、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図１５、ステップＳ１１２０１）。このように、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを事前に通知しておくことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続した時に、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得する場合に比べて、高速な切り替え接続が可能となる。
なお、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知するより先に、ＵＥ１からのIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂが受信／処理してしまうと、Ｔ−ＰＧＷ５ｂは再度ＵＥ１に対するフル認証処理をＡＡＡサーバ８ａに要求してしまい、接続までに要する時間が増大することになる。これを回避するため、ＵＥ１は図１４で説明したReuse indicatorを含めたIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信し（図１５、ステップＳ１１１０２）、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得していなければ、ＡＡＡサーバ８ａに問い合わせるようにしてもよい。これにより、より確実にＭＳＫの再利用を行うことができるようとともに、切り替え接続の高速化を図ることができる。
また、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証を行うためや、ＡＡＡサーバ８ａにおいて、今回ＵＥ１からの接続要求が、先に指示されたＴ−ＰＧＷ５ｂへの切り替え接続によるものであるか、あるいは新規ＰＧＷ５への接続のためのものであるかを判別して確実にＭＳＫの再利用を実施するために有用であるが、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合、またＡＡＡ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えによりものであることの確認がとれる場合などにおいては、これらのBS_Identityを省略することもできる。
またさらには、理想状態において、Ｔ−ＰＧＷ５ｂはＵＥ１からIKE_AUTH Requestメッセージを受信する前にＡＡＡサーバ８ａからＵＥ１向けの鍵を取得することができ、この時点で鍵の再利用を認識することができるため、ＵＥ１が通知するReuse Indicatorも省略することができる。ただし、先に説明したようにＡＡＡサーバ８ａからの通知がＵＥ１からのIKE_AUTH Requestメッセージ到着より遅れることも想定し、Ｔ−ＰＧＷ５ｂに対して従来のシーケンスに基づく処理ではなく鍵を再利用するためのシーケンスに基づく処理を促す目的でReuse Indicatorを付加することは有用である。
なお、上述の第２の実施の形態で説明したように、ＵＥ１は、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５であるＴ−ＰＧＷ５ｂのアドレスを通知されるかもしれない（図１３のステップＳ９１０７）。しかしながら、第２の実施の形態では、ＵＥ１がＡＡＡサーバ８ａの状態を解消するためにステップＳ９１０８〜Ｓ９１１２を実施するものであったが、実質このステップ区間においてＡＡＡサーバ８ａによる認証処理（ＭＳＫ生成）を完了させて、Ｔ−ＰＧＷ５ｂとの切り替え接続時に認証データ（ＭＳＫなど）を再利用したほうが、総じて処理時間の短縮効果が大きいと考えられる。よって、本第３の実施の形態に対応するＵＥ１が、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５のアドレスを通知された場合は、図１３のステップＳ９１０８でＡＡＡサーバ８ａの状態解消を要求せず、引き続き認証処理を継続してもよい。すなわち、図１３のステップＳ９１０８以降の処理は、図１４のステップＳ１０００８以降に置き換えられるが、既にＴ−ＰＧＷ５ｂのアドレスはステップＳ９１０７でＵＥ１に通知されているので、図１４のステップＳ１００１４で再度通知する必要はない。
次に、本発明の第３の実施の形態における移動端末（ＵＥ１）の構成と処理フローについて説明する。本発明の第３の実施の形態における移動端末（ＵＥ１）の構成は、本発明の第１と第２の実施の形態における移動端末（ＵＥ１）の構成（図３を参照）と同様であるので説明を省略する。
以下、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図１６を用いて詳しく説明する。図１６は、本発明の第３の実施の形態におけるＵＥ１の処理フローの一例を示すフローチャートであり、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２（ホームリンク）に接続済みであり、Ｔ−ＰＧＷ５ｂに接続しているものとする。
本発明による接続制御部１０６は、まずＮ３Ｇアクセス３へのアタッチ（接続）処理を開始するため、第２無線通信部１０２に接続開始を指示する（ステップＳ１２００１）。第２無線通信部１０２では、Ｎ３Ｇアクセス３における接続手順に従って、接続処理を実施する。Ｎ３Ｇアクセス３への接続が完了すると、Ｎ３Ｇアクセス３経由で接続するＰＧＷ５のアドレスを探索するため、ＤＮＳクライアント処理部１０５に探索開始を指示する（ステップＳ１２００２）。このとき、接続制御部１０６は、接続先となるＰＧＷ５のアドレスを取得するため、接続先ネットワークＰＤＮの識別子であるＡＰＮやＰＧＷ５を識別するためのＨＡ−ＡＰＮなどから、標準的な方法により（例えば、非特許文献６に開示されている方法など）、ホームエージェント名（ＦＱＤＮ）を構築し、ＤＮＳクライアント処理部１０５に通知する。ＤＮＳクライアント処理部１０５では、通知されたホームエージェント名を記載したＤＮＳクエリをパケット処理部１０３、第２無線通信部１０２経由でＤＮＳサーバ９宛に送信する。また、その応答としてＤＮＳ応答を第２無線通信部１０２、パケット処理部１０３経由でＤＮＳサーバ９から受信し、ＤＮＳ応答から取得したＰＧＷアドレスを接続制御部１０６に転送する（ステップＳ１２００３）。
接続制御部１０６は、取得したＰＧＷアドレスに対して一般的なＢＳ処理を開始するようＢＳ処理部１０４に指示する。ＢＳ処理部１０４では、ＩＫＥ ＳＡを構築するための手順であるIKE_SA_INIT処理を、接続制御部１０６から通知されたＰＧＷアドレス（Ｉ−ＰＧＷ５ａのアドレス）に対して開始する（ステップＳ１２００４）。IKE_SA_INIT処理が完了し、ＩＫＥ ＳＡが確立されると、ＢＳ処理部１０４は、IKE_AUTH Requestメッセージを送信する（ステップＳ１２００５）。
IKE_AUTH Requestメッセージは、ＢＳ処理部１０４からパケット処理部１０３、第２無線通信部１０２を介してＩ−ＰＧＷ５ａ宛に送信される。Ｉ−ＰＧＷ５ａはIKE_AUTH Requestメッセージの応答としてIKE_AUTH ResponseメッセージをＵＥ１に送信し、ＵＥ１で受信したIKE_AUTH Responseメッセージは、第２無線通信部１０２、パケット処理部１０３を介してＢＳ処理部１０４に転送される（ステップＳ１２００６）。
ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡが確立すると、Ｉ−ＰＧＷ５ａからＴ−ＰＧＷ５ｂへの切り替えが必要であることがＵＥ１に伝えられる。具体的には、切り替え先ＰＧＷ５となるＴ−ＰＧＷ５ｂのアドレスと、Ｉ−ＰＧＷ５ａを介して完了したＡＡＡサーバ８ａによるＵＥ１に対する認証データをＴ−ＰＧＷ５ｂへの切り替え接続時に再利用可能とするための符合UE_BS_Identityとを受信したかを確認する（ステップＳ１２００７）。
ＵＥ１がＴ−ＰＧＷ５ｂのアドレスとUE_BS_Identityとを受信しなかった場合は、ＰＧＷ５の切り替えを要求されなかったことであることから、確立したＳＡを用いてＩ−ＰＧＷ５ａとＢＵ／ＢＡ交換を実施する（ステップＳ１２０３０）。
一方、ＵＥ１がＴ−ＰＧＷ５ｂのアドレスとUE_BS_Identityとを受信した場合、ＵＥ１はＴ−ＰＧＷ５ｂへの切り替え接続を開始する。すなわち、Ｔ−ＰＧＷ５ｂとのＳＡ確立を開始する。最初に、IKE_AUTHメッセージを保護するために必要な共有鍵をＵＥ１とＴ−ＰＧＷ５ｂとの間で生成するために、ＵＥ１はIKE_SA_INITメッセージ交換をＴ−ＰＧＷ５ｂとの間で実施する（ステップＳ１２０１０）。
続いて、ＵＥ１はＴ−ＰＧＷ５ｂとのＳＡ確立において、従来実施されていたフル認証を省略して接続時間を短縮する目的で、Ｉ−ＰＧＷ５ａとのＳＡ確立で生成されたＭＳＫを再利用することを示すReuse Indicatorを生成する（ステップ１２０１１）。なお、ステップＳ１２０１０とステップＳ１２０１１の処理の順番は逆になってもよい。ＵＥ１は、生成したReuse Indicatorと先に取得したUE_BS_IdentityとをIKE_AUTH Requestメッセージに格納して、Ｔ−ＰＧＷ５ｂに送信する（ステップＳ１２０１２）。
Ｔ−ＰＧＷ５ｂは、Reuse IndicatorとUE_BS_Identityとが格納されたIKE_AUTH Requestメッセージを受信するとＡＡＡサーバ８ａに転送する。ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから転送されたIKE_AUTH Requestメッセージを受信すると、Reuse IndicatorとUE_BS_Identityとが格納されていることを確認し、ＵＥ１がＩ−ＰＧＷ５ａを介して接続した際に生成されたＭＳＫと、UE_BS_Identityに対応するT-PGW_BS_Identityとを、例えば、Authentication-AnswerメッセージによってＴ−ＰＧＷ５ｂに通知する。なお、ＡＡＡサーバ８ａは、IKE_AUTH Requestメッセージに対する応答としてＭＳＫ及びT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに通知してもよく（図１４に図示されている第１のシーケンスに対応）、IKE_AUTH Requestメッセージに対する応答よりも先にＭＳＫ及びT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに通知してもよい（図１５に図示されている第２のシーケンスに対応）。ＭＳＫ及びT-PGW_BS_Identityの通知を受けたＴ−ＰＧＷ５ｂは、T-PGW_BS_IdentityをIKE_AUTH Responseメッセージに格納してＵＥ１に送信し、ＵＥ１がそれを受信する（ステップＳ１２０１３）。
ＵＥ１は、IKE_AUTH Responseメッセージに格納されたBS_IdentityがUE_BS_Identityに対応するものであるかを確認する（ステップＳ１２０１４）。なお、ＵＥ１はステップＳ１２００７でUE_BS_Identityを受信した後に、UE_BS_Identityに対応するT-PGW_BS_Identityを任意のタイミングで生成して保持しておいてもよいし、ステップＳ１２０１４のタイミングで生成してもよい（例えば、ハッシュ関数や、BS_Identityリストを保持しているデータベースサーバの利用など）。
ここで、Ｔ−ＰＧＷ５ｂから送られてきたT-PGW_BS_Identityと、ＵＥ１が生成したT-PGW_BS_Identityが一致した場合、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施し、終了する（ステップＳ１２０２０）。一方、一致しなかった場合には、ＵＥ１は、受信したIKE_AUTH Responseメッセージを破棄する（ステップＳ１２０２１）。
なお、図１５に示したように、ＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知するような場合においても、ＵＥ１は、Reuse IndicatorとUE_BS_Identityとを格納したIKE_AUTH_RequestメッセージをＴ−ＰＧＷ５ｂに送信することが望ましい。これにより、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図１５、ステップＳ１１０１１）が遅延したりロスしたりして、Ｔ−ＰＧＷ５ｂが鍵データ（ＭＳＫ）の再利用（フル認証の省略）を認識していない場合であっても、Ｔ−ＰＧＷ５ｂ越しにＭＳＫの再利用を実施することができ、切り替え接続のための時間短縮をより確実なものとすることができる。
また、図１５に図示されている第２のシーケンスでＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知する場合において、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図１５、ステップＳ１１０１１）が遅延したりロスしたりしないことがシステムとして保証されているような場合には、Reuse Indicatorの代わりとしてUser IdentityやＵＥ１のアドレスを使用することで、ＵＥ１はReuse Indicatorを図１６のステップＳ１２０１１で生成したり、ステップＳ１２０１２でIKE_AUTH_Requestメッセージに格納したりしなくてもよい。
またさらには、ＡＡＡサーバ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えを意図していることが確認できる場合、UE_BS_Identityは最早不要であり、図１６のステップＳ１２００７でＵＥ１への通知は行われない。このときＵＥ１は、Ｔ−ＰＧＷ５ｂに対して標準的なＢＳ処理を実行すればよく（図１６には不図示）、これにより、ＭＳＫの再利用がネットワーク側の判断によって実施され、Ｔ−ＰＧＷ５ｂへの切り替え接続を短時間に完了させることができる。
なお、本発明の第３の実施の形態で用いられているUE_BS_Identity並びにT-PGW_BS_Identityに関しても、上述の第１の実施の形態と同様に、様々な組み合わせが可能である。すなわち、本発明の第３の実施の形態において、例えば、UE_BS_Identityと、このUE_BS_Identityに対応するT-PGW_BS_Identityを用いて、UE_BS_IdentityとT-PGW_BS_Identityとの照合が行われてもよく、どちらか一方のBS_Identityが用いられてもよく、あるいは、BS_Identityが用いられなくてもよい。また、本発明の第３の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityに使用される情報として、例えば、ＵＥ１及びＰＧＷ５によって共有されている値を基に生成されたハッシュ値や、ランダムに生成された値やＩ−ＰＧＷ５ａのアドレス（これらに限定されない）など、ＵＥ１及びＰＧＷ５によって認識可能な値（符号）を用いることが可能である。また、本発明の第３の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityは、ＰＧＷ５、ＡＡＡサーバ８ａ、あるいは、その他の通信装置によって生成されてもよい。
なお、本発明の第３の実施の形態で用いたＭＳＫは、インターネットで利用される技術を標準化する組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が、ＲＦＣで定義しているＭＳＫと同じであってもよいし、別途規定されてもよい。
＜第４の実施の形態＞
次に、本発明の第４の実施の形態におけるシステム動作の一例について、図１７Ｃ、図２０から図２５を用いて詳しく説明する。図２０は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第１のシーケンス図である。図２０には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
本発明の第４の実施の形態では、Ｔ−ＰＧＷ５ｂのアドレスが、IKE_AUTHメッセージ交換の完了後、すなわちＵＥ１とＡＡＡサーバ８ａが相互認証（ＡＡＡサーバ８ａによるＵＥ１の認証）の成功によってＭＳＫを生成して、そのＭＳＫを用いて作成したAUTHパラメータがＵＥ１とＩ−ＰＧＷ５ａとの間で交換されて、お互いに認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）をした後に通知される場合のＰＧＷ切り替え方法について説明する。
以下、従来技術のPDN GW reallocation procedure（図１２に図示されている処理フロー）と比較しながら、図２０に図示されている本発明の第４の実施の形態におけるシステム動作の一例について説明する。
図２０において、本発明の第４の実施の形態の処理フローのステップＳ１３００１〜Ｓ１３００９、従来技術のPDN GW reallocation procedureのステップＳ９００１〜Ｓ９００９（図１２に図示）と同一であるので説明を省略する。
続いて、従来技術のPDN GW reallocation procedure（図１２に図示）における次ステップＳ９０１０では、ＡＡＡサーバ８ａがＩ−ＰＧＷ５ａ（図１２上ではＰＧＷ５に相当）経由でＵＥ１から送られてきたEAP-Responseメッセージを処理し、ＵＥ１とＩ−ＰＧＷ５ａ（図１２上ではＰＧＷ５に相当）との間のＳＡ確立に必要である鍵（Master Session key：以降、ＭＳＫと呼ぶ）と、ＵＥ１にとっての切り替え先となるＴ−ＰＧＷ５ｂのアドレスとをＩ−ＰＧＷ５ａ（図１２上ではＰＧＷ５に相当）に送信する（図１２、ステップＳ９０１０）。一方、本発明の第４の実施の形態では、従来ではＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに送信されるＭＳＫとＴ−ＰＧＷ５ｂのアドレスに、更にUE_BS_Identityを加えたAuthentication-AnswerメッセージをＩ−ＰＧＷ５ａに送信する（図２０、ステップＳ１３０１０）。なお、このUE_BS_Identityは、ＵＥ１がＩ−ＰＧＷ５ａとフル認証を実施したことを証明（例えば、ＡＡＡサーバ８ａが持つT-PGW_BS_Identityとの関連性の有無や、UE_BS_Identityが暗号化される場合には、復号可能であるか確認）するためなどに用いるが、ＵＥ１の固有情報（例えば、ＩＭＳＩ（International Mobile Subscriber Identity）など）を用いることで識別できる場合には、省略してもよい。
図２０のステップＳ１３０１０においてＡＡＡサーバ８ａがＩ−ＰＧＷ５ａに送信する応答メッセージは、本発明の第３の実施の形態における図１４のステップＳ１００１０で用いるメッセージ（図１８Ｂに図示）と同様であるので説明を省略する。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続く本発明の第４の実施の形態の処理フローのステップＳ１３０１１〜Ｓ１３０１３は、従来技術のPDN GW reallocation procedureのステップＳ９０１１〜Ｓ９０１３（図１２に図示）と同一であるので説明を割愛する。
続いて、従来技術のPDN GW reallocation procedureにおける次ステップでは、Ｉ−ＰＧＷ５ａからＵＥ１にＴ−ＰＧＷ５ｂのアドレスなどが送信される（図１２、ステップＳ９０１４）。一方、本発明の第４の実施の形態では、ＡＡＡサーバ８ａからＩ−ＰＧＷ５ａに従来送信されていたＴ−ＰＧＷ５ｂのアドレスに加えて、ＡＡＡサーバ８ａから通知されたUE_BS_IdentityをIKE_AUTH Responseメッセージに乗せてＵＥ１に通知する（図２０、ステップＳ１３０１４）。なお、Ｉ−ＰＧＷ５ａがステップＳ１３０１０でUE_BS_IdentityをＡＡＡサーバ８ａから受信しなかった場合は、このIKE_AUTH Responseメッセージに格納しなくてもよい。
次に、図２０のステップＳ１３０１４においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例として、IKE_AUTH Responseメッセージのフォーマット例について図１７Ｂを用いて説明する。
Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３１０１に加えて、ＢＳ識別子（BS_Identity）フィールド３１０２を設け、それぞれの値をＵＥ１に通知することができる。また、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してUE_BS_Identityなどを記載し、ＵＥ１に通知してもよい。なお、本応答メッセージは、所定の情報を転送できるものであればIKE_AUTH Responseメッセージ以外のメッセージであってもよいが、IKE_AUTH Responseメッセージの送信と同時、あるいはIKE_AUTH Responseメッセージよりも後に送信されることが望ましい。
なお、ここでは、IKE_AUTHメッセージ交換（図２０、ステップＳ１３０１３、Ｓ１３０１４）によってＵＥ１とＩ−ＰＧＷ５ａとの間でお互いに認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）をした後に、Ｉ−ＰＧＷ５ａからＵＥ１に対してＴ−ＰＧＷ５ｂのアドレス通知（例えば、ステップＳ１３０１４のIKE_AUTH Responseメッセージによる通知）が行われているが、ＡＡＡサーバ８ａによるＵＥ１の認証が成功した時点（すなわち、ステップＳ１３００９で受信したチャレンジ情報に基づいてＡＡＡサーバ８ａがＵＥ１の認証を完了した時点）で、ネットワーク側からＵＥ１に対してＴ−ＰＧＷ５ｂのアドレスを通知することも可能である。この場合には、ステップＳ１３００９で受信したチャレンジ情報の処理が完了した後に、任意のメッセージ（例えば、ステップＳ１３０１２におけるメッセージ）にＴ−ＰＧＷ５ｂのアドレスを格納してＵＥ１へ通知してもよい。
続いて、ＵＥ１は、ＵＥ１とＴ−ＰＧＷ５ｂとの間でＳＡを確立するために、ＢＳ処理を開始する。ＵＥ１とＴ−ＰＧＷ５ｂは、ＵＥ１とＴ−ＰＧＷ５ｂ間のIKE_AUTHメッセージを保護するために、ＵＥ１とＴ−ＰＧＷ５ｂとの間でIKE_SA_INITメッセージ交換を実施し、ＵＥ１とＴ−ＰＧＷ５ｂ間の共有鍵（例えば、SKEYSEED）などを生成・取得する（図２０、ステップＳ１３１０１）（上記した非特許文献７を参照）。ＵＥ１とＴ−ＰＧＷ５ｂ間で共有鍵の生成後、ＵＥ１とＴ−ＰＧＷ５ｂは、その共有鍵などを用いてパケットの暗号化に用いる鍵（例えば、SK_ei、SK_er）などを生成する（上記した非特許文献７、非特許文献８を参照）。なお、パケットの暗号化に用いる鍵などを生成する方法として、IKE_SA_INITメッセージ交換以外の方法を用いてパケットの暗号化に用いる鍵などを生成できる場合には、他の方法を用いてもよい。
次に、ＵＥ１はIKE_AUTH Requestメッセージを作成し、先にIKE_SA_INITメッセージ交換を通じて生成したＵＥ１とＴ−ＰＧＷ５ｂとの間の鍵を使用して暗号化し、Ｔ−ＰＧＷ５ｂに送信する。ここで、先にＵＥ１とＩ−ＰＧＷ５ａとの間で実施したＳＡ確立の際に生成されたＭＳＫ（鍵）を再利用するよう要求することにより、従来技術ではこの後に必要であったＵＥ１とＡＡＡサーバ８ａ間の相互認証（図２０のステップＳ１３００５〜Ｓ１３００９）やＭＳＫの生成（図２０のステップＳ１３０１０）などを省略することができる。そのため、ＵＥ１は、先に生成したＭＳＫの再利用を示すReuse Indicatorと、Ｉ−ＰＧＷ５ａから受信したUE_BS_IdentityをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに送信する（図２０、ステップＳ１３１０２）。
なお、Reuse indicatorは、ＵＥ１とＩ−ＰＧＷ５ａとの間のブートストラップ処理の過程でＩ−ＰＧＷ５ａ又はＡＡＡサーバ８ａなどが生成し、ＵＥ１に通知するものであってもよい。特にＡＡＡサーバ８ａが生成してＵＥ１に通知することにより、ＡＡＡサーバ８ａあるいはＡＡＡサーバ８ａを含むネットワークシステムが、鍵の再利用をサポートあるいは許可することの表明をＵＥ１に対して行うことができ、ＵＥ１にとっては、確信を持って鍵の再利用を要求することができ、ひいては所望のＴ−ＰＧＷ５ｂとの切り替え接続をより確実に短時間で終えることができるようになる。
さらには、ＡＡＡサーバ８ａがReuse Indicatorを生成及び通知したが、そのドメインあるいはコアネットワーク４のＰＧＷ５がサポートしていない、あるいは許可しない場合（例えばローミングＵＥ１に対しては許可しないなどの理由から）は、ＰＧＷ５がReuse Indicatorを除去してＵＥ１に通知しないようにしてもよい。これにより、例えばＵＥ１のホームネットワーク（ＨＰＬＭＮ：Home Public Land Mobile Network）では鍵の再利用がサポートされている、あるいは許可されても、ＵＥ１の在圏ネットワーク（ＶＰＬＭＮ：Visited Public Land Mobile Network）ではサポートしていない、あるいは許可されない場合に対応することができるようになる。
また、UE_BS_Identityは、Ｉ−ＰＧＷ５ａを通じてＡＡＡサーバ８ａと既に相互認証を完了しているＵＥ１からのＢＳ処理であることを、後のＴ−ＰＧＷ５ｂ経由のＢＳ処理時にＡＡＡサーバ８ａが識別可能にするためにIKE_AUTH Requestメッセージへ格納される。UE_BS_Identityを使用することで、Reuse Indicatorの目的を達成できるのであれば、Reuse Indicatorを省略してもよい。また、その逆でReuse Indicatorを用いることで、UE_BS_Identityの目的を達成できるのであれば、UE_BS_Identityを省略してもよい。
図２０のステップＳ１３１０２においてＵＥ１がＴ−ＰＧＷ５ｂに送信するメッセージは、本発明の第３の実施の形態における図１４のステップ１０１０２で用いるメッセージ（図１７Ａに図示されているIKE_AUTH Requestメッセージのフォーマット例）と同様であるので説明を省略する。また、標準的なIKE_AUTH Requestメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadなどを付加してReuse IndicatorやUE_BS_Identityを記載し、ＵＥ１に通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればIKE_AUTH Requestメッセージ以外のメッセージであってもよい。
Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてきたIKE_AUTH Requestメッセージに含まれるReuse indicatorとUE_BS_IdentityとをＡＡＡサーバ８ａに転送する（図２０、ステップＳ１３１０３）。なお、Reuse IndicatorとUE_BS_Identityは、ＵＥ１がIKE_SA_INITメッセージを通じてＴ−ＰＧＷ５ｂに通知し、Ｔ−ＰＧＷ５ｂはIKE_SA_INITメッセージの交換と並行して同パラメータをＡＡＡサーバ８ａに通知するものであってもよい。
図２０のステップＳ１３１０３においてＴ−ＰＧＷ５ｂがＡＡＡサーバ８ａに送信するメッセージは、本発明の第３の実施の形態における図１４のステップＳ１０１０３で用いるメッセージ（図１８Ａに図示されているAuthentication-Requestメッセージのフォーマット例）と同様であるので説明を省略する。また、標準的なAuthentication-Requestメッセージの既存のペイロードにReuse IndicatorとUE_BS_Identityとを記載し、ＡＡＡサーバ８ａに通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればAuthentication-Requestメッセージ以外のメッセージであってもよい。
ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから転送されてきたReuse indicatorを受けて、先にＵＥ１とＩ−ＰＧＷ５ａとの間でＳＡ確立した際のＭＳＫの再利用が要求されていると判断し、ＡＡＡサーバ８ａが保持するUE_BS_Identityに対応しているＭＳＫをＴ−ＰＧＷ５ｂに通知する。なお、先述したように、UE_BS_Identityは、一度フル認証を完了しているＵＥ１であることを確認できるパラメータ（例えば、ＩＭＳＩなど）に代替してもよい。ＭＳＫを通知すると同時に、UE_BS_Identityに対応するT-PGW_BS_Identityも通知する（図２０、ステップＳ１３１０４）。なお、T-PGW_BS_Identityは、ＡＡＡサーバ８ａ自身が生成してもよいし、BS_Identityリストを保持しているネットワーク上のデータベースサーバ（不図示）が設置されている場合は、データベースサーバに問い合わせてUE BS Identityに対応するT-PGW BS_Identityを取得して利用してもよい。
ここで、ＭＳＫの再利用が先に指示された異なるＰＧＷ５への切り替え接続に限って許可される場合（任意のＰＧＷ５からの接続に対してＭＳＫの再利用を許可しない場合）に対応するため、Ｔ−ＰＧＷ５ｂが自身の情報（例えば、ＩＰアドレスやＰＧＷ５の識別子など）を、ステップＳ１３１０３を通じてＡＡＡサーバ８ａに通知することが考えられる。これにより、ＡＡＡサーバ８ａにおいて、本接続要求が先にＵＥ１に対して指示したＴ−ＰＧＷ５ｂへの切り替え接続要求であることを確認することができ、ＭＳＫの再利用を正しく許可することができる。
図２０のステップＳ１３１０４においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージは、本発明の第３の実施の形態における図１４のステップＳ１０１０４で用いるメッセージ（図１８Ｂに図示されているAuthentication-Answerメッセージのフォーマット例）と同様であるので説明を省略する。なお、本応答メッセージは、所定の情報を転送できるものであればAuthentication-Answerメッセージ以外のメッセージであってもよい。
続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから受信したT-PGW_BS_Identityと、認証の成功（ＡＡＡサーバ８ａによるＵＥ１の認証）と、ＭＳＫの再利用が承認されたことをＵＥ１に通知する（図２０、ステップＳ１３１０５）。
次に、図２０のステップＳ１３１０５においてＴ−ＰＧＷ５ｂがＵＥ１に送信するメッセージの一例としてIKE_AUTH Responseメッセージのフォーマット例について図１７Ｃを用いて説明する。図１７Ｃは、図２０のステップＳ１３１０５で送信するIKE_AUTH Responseメッセージのフォーマット例を示す図である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３２０１に加えて、ＢＳ識別子（UE_BS_Identity/T-PGW_BS_Identity）フィールド３２０２、Success Reuse Indicatorフィールド３２０３を設け、それぞれの値をＵＥ１に通知することができる。また、Ｔ−ＰＧＷ５ｂは、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してＭＳＫの再利用やT-PGW_BS_Identityを示してＵＥ１に通知してもよい。または、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコルのEAP Successを用いることで、ＭＳＫの再利用をＵＥ１に通知してもよい。なお、本応答メッセージは、ＵＥ１がＭＳＫの再利用を確認できるメッセージであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。
このT-PGW_BS_Identityは、ＭＳＫの再利用を許諾したＡＡＡサーバ８ａが先にＩ−ＰＧＷ５ａとの接続時にＵＥ１を認証処理したのと同じノードであることをＵＥ１が正しく識別するために用いる。また、例えば、ＡＡＡサーバ８ａにアクセスせず、ＵＥ１へ不正アクセスを試みるＴ−ＰＧＷ５ｂになりすました偽Ｔ−ＰＧＷ５ｂと区別できる効果もある。
ＵＥ１は、Ｔ−ＰＧＷ５ｂから送られてきたIKE_AUTH ResponseメッセージからＭＳＫの再利用が承認されたことを確認する（例えば、Success Reuse Indicatorフィールド３２０３に格納されている値から判断）。ＵＥ１は、図２０のステップＳ１３０１３で生成したＭＳＫを用いてAUTHパラメータを生成する。ＵＥ１は、生成したAUTHパラメータをIKE_AUTH Requestメッセージに格納して、Ｔ−ＰＧＷ５ｂへ送信する（図２０、ステップＳ１３１０６）。また、ＵＥ１が、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを保持していない、若しくは、使用できない場合は、例えばＡＡＡサーバ８ａなどに問い合わせて、ＭＳＫを取得してもよいし、ＵＥ１自身で再度同じＭＳＫを生成してもよい。
Ｔ−ＰＧＷ５ｂは、IKE_AUTH Requestメッセージを送信したＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）する。ＵＥ１（IKE_SA_INITメッセージの送信元）の認証に成功した場合、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから受信したＭＳＫを用いて作成したAUTHパラメータを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２０、ステップＳ１３１０７）。
なお、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから送られてきたＭＳＫを用いてAUTHパラメータを本ステップＳ１３１０７で作成したが、保持できるのであれば、例えばステップＳ１３１０４以降（ＭＳＫ受信以降）、任意のタイミングで作成してもよい。
ＵＥ１は、IKE_AUTH Responseメッセージを送信したＴ−ＰＧＷ５ｂを認証する（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）。なお、このＴ−ＰＧＷ５ｂ（IKE_SA_INITメッセージの送信元）の認証をするために、ステップＳ１３１０６でＵＥ１が作成したAUTHパラメータや、ステップＳ１３１０１で取得した鍵情報（例えば、共有鍵や通信相手の公開鍵など）を用いてもよい。
ＵＥ１が、Ｔ−ＰＧＷ５ｂの認証ができた場合（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）、ＵＥ１とＴ−ＰＧＷ５ｂの間でＳＡが確立される。なお、このIKE_AUTH Responseメッセージには、ＵＥ１とＴ−ＰＧＷ５ｂの間に確立されるＳＡに必要な情報が送られる。
また、Ｔ−ＰＧＷ５ｂが、ステップＳ１３１０５でＭＳＫを用いたAUTHパラメータを作成して、ＵＥ１に通知することによって、先にＵＥ１がＴ−ＰＧＷ５ｂを認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）して、続いて、ＵＥ１がAUTHパラメータをＴ−ＰＧＷ５ｂに通知してもよい。
また、ＵＥ１とＴ−ＰＧＷ５ｂのお互いの認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）は、ＵＥ１若しくはＴ−ＰＧＷ５ｂのどちらか一方が認証（例えば、IKE_AUTHメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１やＰＧＷ５）の正確性を確認することによる認証方法の確認や、鍵の確認など）することで、ＳＡが確立できる場合、又は、ＵＥ１若しくはＴ−ＰＧＷ５ｂの処理負荷軽減などのために、どちらか一方だけが認証するだけでもよい。また、AUTHパラメータ以外を用いて、ＵＥ１とＴ−ＰＧＷ５ｂの認証をすることができるのであれば、AUTHパラメータ以外を用いてもよい。
続いて、IKE_AUTH_Responseメッセージを受信したＵＥ１は、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２０、ステップＳ１３２０１）。
なお、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証のために有用であるが、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合は、これらのBS_Identityを省略することもできる。
また、Ｔ−ＰＧＷ５ｂへの切り替え指示後もＡＡＡサーバ８ａがＵＥ１に対する状態を保持できる場合には、ＵＥ１が通知するReuse Indicatorも省略することができる。この場合、ＡＡＡサーバ８ａは、ＵＥ１の固定情報（例えば、ＩＭＳＩなど）などを基にＵＥ１の識別を行い、保持しておいたＵＥ１に対する状態に基づいて鍵データ（例えば、ＭＳＫなど）を抽出し、Ｔ−ＰＧＷ５ｂに通知することができる。ただし、一部のＡＡＡサーバ８ａにおいては、切り替え指示後はＵＥ１に対する状態を解消することも想定されるため、汎用性を確保する目的でReuse IndicatorをＵＥ１から通知することは有用である。
以上の動作によって、従来技術のPDN GW reallocation procedureでは、ＵＥ１とＡＡＡサーバとの８ａ間においてＩ−ＰＧＷ５ａとＴ−ＰＧＷ５ｂで計２回のＵＥ認証（Full Authentication）を実施する必要があったが、上述したように鍵の再利用を行うことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続する際のブートストラップ処理のメッセージ数削減と切り替え時間の短縮を図ることができるようになる。
なお、過去にＵＥ１が他のＰＧＷ５とＳＡ確立を実施した実績がある場合、ＵＥ１に対するＰＧＷ５の切り替え要求（すなわち切り替え先ＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスの通知）は、上記説明したステップＳ１３０１４より前に実施することも可能である（例えば、図２０のステップＳ１３００７など）。例えば、ＵＥ１は、ステップＳ１３１０２で送信されるReuse IndicatorをステップＳ１３００３のIKE AUTH Requestメッセージに含めて送信する。このReuse Indicatorを参照したＩ−ＰＧＷ５ａは、ステップＳ１３００４〜Ｓ１３００６の処理において、ステップＳ１３１０３及びＳ１３１０４と同様の手順で、ＵＥ１に対して確立済みの鍵をＡＡＡサーバ８ａから取得する（このとき同時に切り替え先ＰＧＷ５のアドレスも取得することになる）。そして、Ｉ−ＰＧＷ５ａは、ステップＳ１３００７で切り替え先ＰＧＷ５のアドレスを含むIKE_AUTH responseメッセージ（すなわち、上記のステップＳ１３１０５で送信されるIKE_AUTH responseメッセージと同等のメッセージ）をＵＥ１へ送信することによって、切り替え先ＰＧＷ５のアドレスをＵＥ１に通知することが可能となる。これにより、ＵＥ１は過去に確立した鍵を再利用して高速に切り替え先ＰＧＷ５のアドレスを取得することができ、ひいては本来接続を希望しないＰＧＷ５が割り当てられた場合でも、所望のＰＧＷ５への切り替え接続を高速に実施することができる。
また、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂへの切り替えを指示するタイミング（図２０、ステップＳ１３０１０）で、生成したＭＳＫをＴ−ＰＧＷ５ｂに通知してもよい。具体的には、図２１を用いて説明する。
図２１は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第２のシーケンス図である。図２１には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図２１の処理フローのステップＳ１４００１〜Ｓ１４０１０は、図２０の処理フローのステップＳ１３００１〜Ｓ１３０１０と同一であるので説明を省略する。このステップＳ１４０１０を送信する段階で、ＡＡＡサーバ８ａはＴ−ＰＧＷ５ｂにＭＳＫを通知することが可能である。ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知する手法としては、例えば、Ｉ−ＰＧＷ５ａにUE_BS_Identityを格納したAuthentication-Answerメッセージを送信する処理と同時に、ＵＥ１とＩ−ＰＧＷ５ａとの間のＳＡ確立処理の過程で生成したＭＳＫと、UE_BS_Identityに対応するT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに送信する（図２１、ステップＳ１４０１１）。
図２１のステップＳ１４０１１においてＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂに送信するメッセージは、本発明の第３の実施の形態における図１５のステップＳ１１０１１で用いるメッセージ（図１９に図示されているBS_Identity通知メッセージのフォーマット例）と同様であるので説明を省略する。なお、BS_Identity通知メッセージとして、従来のAuthentication-Request/Identityメッセージなどを拡張して用いてもよい。また、BS_Identity通知メッセージに、ＵＥ１の固定情報（例えば、ＩＭＳＩなど）を含めてもよく、これによりＴ−ＰＧＷ５ｂがＵＥ１からIKE_AUTH Requestメッセージを受信したとき、そのＵＥ１に関してフル認証が完了しているＵＥ１なのかを判別しやすくなり、より確実にＵＥ１を照合することが可能となる。このＵＥ１の固定情報のみで、フル認証済みであることが判別でき、ＵＥ１を照合することができる場合、このIKE_AUTH Responseメッセージで用いるＵＥアドレスフィールド５００４は省略してもよい。
続く図２１の処理フローのステップＳ１４０１２〜Ｓ１４１０２は、図２０の処理フローのステップＳ１３０１１〜Ｓ１３１０２と同一であるので説明を割愛する。
Reuse indicatorとUE_BS_Identityが格納されたIKE_AUTH Requestメッセージ（図２１、ステップＳ１４１０２）を受信したＴ−ＰＧＷ５ｂは、ステップＳ１４０１１でＡＡＡサーバ８ａから受信したT-PGW_BS_Identityと、ＵＥ１とＴ−ＰＧＷ５ｂ間でＭＳＫの再利用の許可を示したパラメータ（例えば、Success Reuse Indicatorフィールド３２０３の値）を格納したIKE_AUTH ResponseメッセージをＵＥ１に返信する（図２１、ステップＳ１４１０３）。なお、Ｔ−ＰＧＷ５ｂは、ステップＳ１４１０２で受信したUE_BS_IdentityとステップＳ１４０１１で受信したT-PGW_BS_Identityとが正しく対応するものであるか確認してもよい（例えば、ハッシュ値の検算や、ネットワーク上のBS_Identityリストを管理しているデータベースへの問合せなど）。また、ＵＥ１はＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを保持しているので、Ｔ−ＰＧＷ５ｂは、ステップＳ１４１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納して通知する必要はない。ただし、例えば、ＵＥ１が何らかの理由でＭＳＫを保持していない（例えば、既に廃棄しているなど）可能性も考えられるので、Ｔ−ＰＧＷ５ｂが、ステップＳ１４１０３で送信するIKE_AUTH ResponseメッセージにＭＳＫを格納してＵＥ１へ通知して、ＵＥ１がＭＳＫを確実に把握できるようにしてもよい。また、ＭＳＫではなく、ＭＳＫを生成するための材料を通知してもよい。
図２１のステップＳ１４１０３で送信するIKE_AUTH Responseメッセージのフォーマットとしては、図１７Ｃに図示されているフォーマット例を用いることが可能である。Ｔ−ＰＧＷ５ｂは、従来の標準的なIKE_AUTH Responseメッセージ３２０１に加えて、ＢＳ識別子（UE_BS_Identity/T-PGW_BS_Identity）フィールド３２０２、Success Reuse Indicatorフィールド３２０３を設け、それぞれの値をＵＥ１に通知することができる。また、Ｔ−ＰＧＷ５ｂは、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコル（上記の非特許文献７を参照）で規定されるNotify Payloadを付加してＭＳＫの再利用やT-PGW_BS_Identityを示してＵＥ１に通知してもよい。または、標準的なIKE_AUTH Responseメッセージに標準的なＩＫＥｖ２プロトコルのEAP Successを用いることで、ＭＳＫの再利用をＵＥ１に通知してもよい。なお、本応答メッセージは、ＵＥ１がＭＳＫの再利用を確認できるメッセージであればIKE_AUTH Responseメッセージ以外のメッセージであってもよい。また、Ｔ−ＰＧＷ５ｂからＵＥ１にＭＳＫを送信する場合は、このメッセージにＭＳＫフィールドを設けてもよい（不図示）。
IKE_AUTH Responseメッセージを受信したＵＥ１は、例えばIKE_AUTH ResponseメッセージのSuccess Reuse Indicatorフィールド３２０３に格納されている値から、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用をできるか判断する。ここで、ＵＥ１がＭＳＫの再利用をできると判断したとき、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いてAUTHパラメータを作成する。ＵＥ１は、この作成したAUTHパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する（図２１、ステップＳ１４１０４）。なお、ＵＥ１は、Ｉ−ＰＧＷ５ａにAUTHパラメータを以前に（ステップＳ１４０１４において）通知しているため、そのときに作成したAUTHパラメータを再利用してもよい。
IKE_AUTH Requestメッセージを受信したＴ−ＰＧＷ５ｂは、ステップＳ１４０１１でＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する。続いて、Ｔ−ＰＧＷ５ｂは、IKE_AUTH Requestメッセージを送信したＵＥ１を認証する（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）。
Ｔ−ＰＧＷ５ｂが、ＵＥ１を認証した場合（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認などができた場合）、Ｔ−ＰＧＷ５ｂは、IKE_AUTH ResponseメッセージをＵＥ１に送信する（図２１、ステップＳ１４１０５）。
また、Ｔ−ＰＧＷ５ｂは、ＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）をした後、先にＴ−ＰＧＷ５ｂが作成したAUTHパラメータをIKE_AUTH Responseメッセージに格納する。
なお、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから送られてくるＭＳＫを用いずに、ＵＥ１を認証できる場合（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認などできる場合）には、ＭＳＫを用いない認証の方法を用いてもよい。Ｔ−ＰＧＷ５ｂは、このIKE_AUTH Responseメッセージに格納するAUTHパラメータをステップＳ１４１０５で作成しているが、ステップＳ１４０１１でＡＡＡサーバ８ａからＭＳＫを受信後、どのタイミングで作成してもよい。また、Ｔ−ＰＧＷ５ｂが、ＵＥ１を認証する際（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認などをする際）に、Ｔ−ＰＧＷ５ｂが先に生成したAUTHパラメータを用いているが、このAUTHパラメータを用いずに確認できるのであれば、他の方法を用いて正確性を確認してもよい。
続いて、IKE_AUTH Responseメッセージを受信したＵＥ１は、IKE_AUTH Responseメッセージを送信したＴ−ＰＧＷ５ｂを認証する（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）。なお、ＵＥ１は、Ｔ−ＰＧＷ５ｂを認証する際にステップＳ１４１０４で使用したAUTHパラメータや、ステップＳ１４１０１で取得した鍵情報（例えば、共有鍵や通信相手の公開鍵など）を用いてもよい。
なお、ＵＥ１によるＴ−ＰＧＷ５ｂの認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）は、Ｔ−ＰＧＷ５ｂによるＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認）のみで、ＳＡが確立できる場合、又は、ＵＥ１の処理負荷軽減などのために省略してもよい。なお、ＵＥ１は、ＵＥ１が持つＭＳＫを用いずに、Ｔ−ＰＧＷ５ｂを認証できる場合（例えば、ＵＥ１が持つUE_BS_Identityと、Ｔ−ＰＧＷ５ｂが持つT-PGW_BS_Identityの関連性の有無などを使用して認証できる場合）には、ＭＳＫを用いない認証の方法を用いてもよい。
Ｔ−ＰＧＷ５ｂ（IKE_SA_INITメッセージの送信元）の認証に成功した場合、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２１、ステップＳ１４２０１）。
このように、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを事前に通知しておくことにより、ＵＥ１がＴ−ＰＧＷ５ｂに切り替え接続した時に、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得する場合に比べて、高速な切り替え接続が可能となる。
なお、ＡＡＡサーバ８ａがＴ−ＰＧＷ５ｂにＭＳＫを通知するより先に、ＵＥ１からのIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂが受信／処理してしまうと、Ｔ−ＰＧＷ５ｂは再度ＵＥ１に対するフル認証処理をＡＡＡサーバ８ａに要求してしまい、接続までに要する時間が増大することになる。これを回避するため、ＵＥ１は図１４で説明したReuse indicatorを含めたIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信し（図２１、ステップＳ１４１０２）、Ｔ−ＰＧＷ５ｂがＡＡＡサーバ８ａからＭＳＫを取得していなければ、ＡＡＡサーバ８ａに問い合わせるようにしてもよい。これにより、より確実にＭＳＫの再利用を行うことができるとともに、切り替え接続の高速化を図ることができる。
また、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、ＵＥ１とＡＡＡサーバ８ａとの間の簡易相互認証を行うため（例えば、ＵＥ１になりすました偽ＵＥ１が、Ｔ−ＰＧＷ５ｂに不正アクセスして、ＵＥ１とＴ−ＰＧＷ５ｂ間のＳＡに関する情報の取得を回避するため）や、ＡＡＡサーバ８ａにおいて、今回ＵＥ１からの接続要求が、先に指示されたＴ−ＰＧＷ５ｂへの切り替え接続によるものであるか、あるいは新規ＰＧＷ５への接続のためのものであるかを判別して確実にＭＳＫの再利用を実施するために有用である。一方、こうした相互認証が不要な場合、あるいは別途相互認証を実施可能である場合、またＡＡＡ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えによるものであることの確認がとれる場合などにおいては、これらのBS_Identityを省略することもできる。
また、上記説明したUE_BS_Identity並びにT-PGW_BS_Identityは、PDN GW reallocationが複数発生したときにも有用である。例えば、ＵＥ１が最初に発見したＰＧＷ（Ｉ−ＰＧＷ５ａ）とアタッチ処理をしている際にPDN GW reallocationが起こり、ＵＥ１はＩ−ＰＧＷ５ａからＰＧＷ５（Ｉ’−ＰＧＷ）のアドレスを受信する。しかし、改めてＵＥ１がＳＡを確立しようとしたＩ’−ＰＧＷが、ＵＥ１が３Ｇアクセス２で接続しているＴ−ＰＧＷ５ｂとは異なる別のＰＧＷ５の場合である。この場合、ＵＥ１は、Ｉ’−ＰＧＷとＭＳＫを再利用してＳＡを確立しようとするが、ＡＡＡサーバ８ａから再度ＰＧＷ５（Ｔ−ＰＧＷ５ｂ）のアドレスが通知される可能性がある。このＵＥ１がＴ−ＰＧＷ５ｂとアタッチ処理を実施するとき、ＵＥ１は、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫ、若しくは、ＵＥ１とＩ’−ＰＧＷの間でＳＡを確立した際に生成したＭＳＫを再利用してもよい。このとき、ＵＥ１は、どちらのＭＳＫを再利用するか示すためにUE_BS_Identity並びにT-PGW_BS_Identityを用いてもよい。
またさらには、理想状態において、Ｔ−ＰＧＷ５ｂはＵＥ１からIKE_AUTH Requestメッセージを受信する前にＡＡＡサーバ８ａからＵＥ１向けの鍵（例えば、ＭＳＫ）を取得することができ、この時点で鍵の再利用を認識することができるため、ＵＥ１が通知するReuse Indicatorも省略することができる。ただし、先に説明したようにＡＡＡサーバ８ａからの通知がＵＥ１からのIKE_AUTH Requestメッセージ到着より遅れることも想定し、Ｔ−ＰＧＷ５ｂに対して従来のシーケンスに基づく処理ではなく鍵を再利用するためのシーケンスに基づく処理を促す目的でReuse Indicatorを付加することは有用である。
なお、上述の第２の実施の形態で説明したように、ＵＥ１は、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５であるＴ−ＰＧＷ５ｂのアドレスを通知されるかもしれない（図１３のステップＳ９１０７）。しかしながら、第２の実施の形態では、ＵＥ１がＡＡＡサーバ８ａの状態を解消するためにステップＳ９１０８〜Ｓ９１１２を実施するものであったが、実質このステップ区間においてＡＡＡサーバ８ａによる認証処理（ＭＳＫ生成）を完了させて、Ｔ−ＰＧＷ５ｂとの切り替え接続時に認証データ（ＭＳＫなど）を再利用したほうが、総じて処理時間の短縮効果が大きいと考えられる。よって、本第４の実施の形態に対応するＵＥ１が、Ｉ−ＰＧＷ５ａとの接続途中で切り替え先ＰＧＷ５のアドレスを通知された場合は、図２０のステップＳ１３００８（若しくは、図２１のステップＳ１４００８）でＡＡＡサーバ８ａの状態解消を要求せず、引き続き認証処理を継続してもよい。すなわち、図１３のステップＳ９１０８以降の処理は、図２０のステップＳ１３００８（若しくは、図２１のステップＳ１４００８）以降に置き換えられるが、既にＴ−ＰＧＷ５ｂのアドレスはステップＳ１３００７（若しくは、ステップＳ１４００７）でＵＥ１に通知されているので、図２０のステップＳ１３０１４（若しくは、図２１のステップＳ１４０１５）で再度通知する必要はない。
本発明の第４の実施の形態では、ＵＥ１とＩ−ＰＧＷ５ａ間のＳＡを確立した際に生成したＭＳＫを再利用することで、ＵＥ１とＴ−ＰＧＷ５ｂ間のＳＡを確立する際に必要であったメッセージを削減することができた。また、そのメッセージのやりとり、処理をすることに要する時間を短縮することができた。
ＵＥ１は、ＭＳＫを再利用する以外に、ＵＥ１とＰＧＷ５間で生成する共有鍵（例えば、SKEYSEEDなど）（上記した非特許文献７を参照）を再利用することで、PDN GW reallocationが起こった際、共有鍵などを生成・取得するステップ（例えば、図２０のステップＳ１３１０１に相当）などを省略することができる。例えば、PDN GW reallocationが起こり、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立して（図２０のステップＳ１３００１〜ステップＳ１３０１４）、ＵＥ１はＩ−ＰＧＷ５ａから受信したＴ−ＰＧＷ５ｂとＳＡを確立しようとする。このとき、ＵＥ１が、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成した共有鍵（例えば、SKEYSEEDなど）を再利用することで、ＵＥ１とＴ−ＰＧＷ５ｂ間の共有鍵を生成するステップなどを省略することができる。また、理想状態（Ｔ−ＰＧＷ５ｂが共有鍵の再利用を許可する状態）であれば、ＵＥ１がＴ−ＰＧＷ５ｂに共有鍵の再利用を示すメッセージを通知するだけで他のメッセージを省略することができる。
また、同様にＵＥ１とＰＧＷ５の間の共有鍵（例えば、SKEYSEEDなど）やＭＳＫは、ＰＧＷ５毎に生成するが、パケットの暗号化に用いる鍵（SK_ei、SK_erなど）を再利用することで、任意の鍵生成のステップを省略してもよい。この場合、新しく鍵を生成するか、再利用するかを切り替えることで、セキュリティレベルが上がり、ＵＥ１とＰＧＷ５間の鍵情報を傍受しようとしているノードによる情報漏洩の可能性を低減することができる。
また、ＵＥ１はＭＳＫの再利用を示したIKE_AUTH Requestメッセージ（図２０、ステップＳ１３１０２）に、Ｉ−ＰＧＷ５ａとのＳＡを確立した際に生成したＭＳＫを用いて作成するAUTHパラメータを格納して、Ｔ−ＰＧＷ５ｂに通知してもよい。具体的には、図２４を用いて説明する。
図２４は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第３のシーケンス図である。図２４には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図２４の処理フローのステップＳ１７００１〜Ｓ１７１０１は、図２０の処理フローのステップＳ１３００１〜Ｓ１３１０１と同一であるので説明を省略する。
続いて、ＵＥ１は、ＭＳＫの再利用が示されたReuse Indicatorなどを含むIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する。このとき、ＵＥ１は、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いて作成したAUTHパラメータも一緒に格納して、Ｔ−ＰＧＷ５ｂに通知する（図２４、ステップＳ１７１０２）。
Ｔ−ＰＧＷ５ｂは、IKE_AUTH RequestメッセージにAUTHパラメータが格納されていることを確認したとき、ＵＥ１がＥＡＰ（Extended Authentication Protocol）を用いず、一般的なＩＫＥｖ２プロトコルを用いたＳＡ確立方法を示していることを判断する（上記した非特許文献７を参照）。また、ＵＥ１が、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を示した値（IKE_AUTH Requestメッセージに格納されているReuse Indicatorフィールド３００２で、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を示した値、若しくはReuse Indicatorフィールド３００２以外でＭＳＫの再利用を示した値に相当するパラメータ）が格納されていると判断した場合は、Ｔ−ＰＧＷ５ｂはＡＡＡサーバ８ａにステップＳ１７１０２で受信したReuse IndicatorとUE_BS_Identityを格納したAuthentication-Requestメッセージを送信する（図２４、ステップＳ１７１０３）。なお、Reuse Indicatorを用いず、例えば、ＡＵＴＨパラメータをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに通知することで、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＭＳＫの再利用を示しているということが確認できる場合、Reuse Indicatorは省略することができる。また、ＡＡＡサーバ８ａが、ＵＥ１の固有情報（例えば、ＩＭＳIなど）を用いることで、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを取得できる場合は、UE_BS_Identityも省略することができる。
図２４の処理フローのステップＳ１７１０４は、図２０の処理フローのステップＳ１３１０４と同一であるので説明を省略する。
ステップＳ１７１０４でＡＡＡサーバ８ａからＭＳＫを受信したＴ−ＰＧＷ５ｂは、AUTHパラメータが格納されたIKE_AUTH Requestメッセージを送信してきたＵＥ１の認証を行う（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）。なお、Ｔ−ＰＧＷ５ｂが、ＡＡＡサーバ８ａから受信したＭＳＫを用いずにＵＥ１を認証できる場合、ＭＳＫを用いる必要はない。また、この場合、ＵＥ１の認証処理をステップＳ１７１０２後に行ってもよい。なお、Ｔ−ＰＧＷ５ｂはＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いてもよく、また、受信したＭＳＫを用いて計算するＡＵＴＨパラメータを用いてもよい。
Ｔ−ＰＧＷ５ｂは、ＵＥ１の認証を完了した後、ＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを計算し、IKE_AUTH Responseメッセージに格納して、ＵＥ１に送信する（図２４、ステップＳ１７１０５）。なお、ＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いて生成するAUTHパラメータを用いる場合は、ＵＥ１を認証する前にAUTHパラメータを計算してもよい。また、Ｔ−ＰＧＷ５ｂはステップＳ１７１０４でＭＳＫと一緒に受信したT-PGW_BS_IdentityもIKE_AUTH Responseメッセージに格納してＵＥ１に送信する。
AUTHパラメータとT-PGW_BS_Identityが格納されたIKE_AUTH Responseメッセージを受信したＵＥ１は、Ｔ−ＰＧＷ５ｂを認証する（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）。ＵＥ１が、Ｔ−ＰＧＷ５ｂを認証した場合、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２４、ステップＳ１７２０１）。
また、本発明の第４の実施の形態における第２のシーケンス（図２１）のようにＡＡＡサーバ８ａがＩ−ＰＧＷ５ａにＴ−ＰＧＷ５ｂのＩＰアドレスを通知する（図２１、ステップＳ１４０１０）と同時に、Ｔ−ＰＧＷ５ｂへＵＥ１とＩ−ＰＧＷ５ａ間でＳＡを確立した際に生成したＭＳＫとT-PGW_BS_Identityを通知する（図２１、ステップＳ１４０１１）場合も同様である。詳しくは、図２５を用いて説明する。
図２５は、本発明の第４の実施の形態におけるシステム動作の一例を説明するための第４のシーケンス図である。図２５には、少なくともＵＥ１、ＵＥ１が本来接続を意図しないＩ−ＰＧＷ５ａ、ＵＥ１が本来接続を所望するＴ−ＰＧＷ５ｂ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡサーバ８ａとユーザ情報データサーバであるＨＳＳ８ｂによる処理シーケンスの一例が図示されている。
図２５の処理フローのステップＳ１８００１〜Ｓ１８１０１は、図２１の処理フローのステップＳ１４００１〜Ｓ１４１０１と同一であるので説明を省略する。
続いて、ＵＥ１は、ＭＳＫの再利用が示されたReuse Indicatorなどを含むIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する。このとき、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いて作成したAUTHパラメータを格納して、Ｔ−ＰＧＷ５ｂに通知する（図２５、ステップＳ１８１０２）。なお、Reuse Indicatorを用いず、例えば、ＡＵＴＨパラメータをIKE_AUTH Requestメッセージに格納してＴ−ＰＧＷ５ｂに通知することで、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＭＳＫの再利用を示しているということが確認できる場合、Reuse Indicatorは省略することができる。また、Ｔ−ＰＧＷ５ｂが、ＵＥ１の固有情報（例えば、ＩＭＳIなど）を用いることで、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を示していることが確認できる場合は、UE_BS_Identityも省略することができる。
AUTHパラメータなどを含むIKE_AUTH Requestメッセージを受信したＴ−ＰＧＷ５ｂは、ＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）を行う。なお、Ｔ−ＰＧＷ５ｂはＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いてもよく、また、受信したＭＳＫを用いて計算するＡＵＴＨパラメータを用いてもよい。また、ＵＥ１を認証する際、ＡＡＡサーバ８ａから受信したＭＳＫ以外を用いてＵＥ１を認証できる場合は、Ｔ−ＰＧＷ５ｂはＭＳＫ以外を用いてＵＥ１を認証してもよい。
ＵＥ１の認証ができた場合、Ｔ−ＰＧＷ５ｂはＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する。なお、ＵＥ１を認証する際に、ＡＡＡサーバ８ａから受信したＭＳＫを用いて生成するAUTHパラメータを用いる場合は、ＵＥ１を認証する前にAUTHパラメータを計算してもよい。そして、ＵＥ１は、作成したAUTHパラメータや、ＵＥ１とＴ−ＰＧＷ５ｂの間のＳＡ確立に必要なパラメータなどを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２５、ステップＳ１８１０３）。なお、ＵＥ１が、T-PGW_BS_IdentityパラメータなしでＴ−ＰＧＷ５ｂを認識することができる場合（例えば、IKE_AUTH Responseメッセージに格納されているＡＵＴＨパラメータを復号可能な場合）、Ｔ−ＰＧＷ５ｂは、T-PGW_BS_Identityを省略することができる。
AUTHパラメータなどが格納されたIKE_AUTH Responseメッセージを受信したＵＥ１は、Ｔ−ＰＧＷ５ｂの認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）を行う。Ｔ−ＰＧＷ５ｂの認証ができた場合、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２５、ステップＳ１８２０１）。
図２４や図２５の処理フローに示されているように、ＵＥ１が、ステップＳ１７１０２やステップＳ１８１０２で、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いて作成したAUTHパラメータをＴ−ＰＧＷ５ｂに送ることによって、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＥＡＰを用いたＢＳ処理ではなく、一般的なＩＫＥｖ２プロトコルを用いてＴ−ＰＧＷ５ｂとの間のＳＡ確立を希望していると判断できる。また、Reuse Indicator若しくはReuse Indicator相当のパラメータを受信することによって、Ｔ−ＰＧＷ５ｂは、ＵＥ１がＩ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫの再利用を希望していることを確認でき、ＡＡＡサーバ８ａから受信したＭＳＫを用いて作成したAUTHパラメータをＵＥ１に送信することが可能となる。その結果、ＵＥ１とＴ−ＰＧＷ５ｂは、図２０や図２１の処理フローにおいて必要であったメッセージ（例えば、図２０のステップＳ１３１０６〜Ｓ１３１０７や、図２１のステップＳ１４１０４〜Ｓ１４１０５）を省略してＳＡを確立することができる。
次に、本発明の第４の実施の形態における移動端末（ＵＥ１）の構成と処理フローについて説明する。本発明の第４の実施の形態における移動端末（ＵＥ１）の構成は、本発明の第１〜第３の実施の形態における移動端末（ＵＥ１）の構成（図３を参照）と同様であるので説明を省略する。
以下、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図２２と図２６を用いて詳しく説明する。図２２と図２６は、本発明の第４の実施の形態におけるＵＥ１の処理フローの一例を示すフローチャートであり、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２（ホームリンク）に接続済みであり、Ｔ−ＰＧＷ５ｂに接続しているものとする。
図２２のＵＥ１の処理フローのステップＳ１５００１〜Ｓ１５０１３は、図１６のＵＥ１の処理フローのステップＳ１２００１〜Ｓ１２０１３と同一であるので説明を省略する。
ＵＥ１は、Ｔ−ＰＧＷ５ｂから送られてきたT-PGW_BS_Identityと、ＵＥ１が生成・取得したT-PGW_BS_Identityが一致しているか、若しくは関連性があるか確認する（ステップＳ１５０１４）。そして、ＭＳＫの再利用の許可（例えば、IKE_AUTH Responseメッセージ（図２０のステップＳ１３１０５など）にEAP Successが格納されているかなど）が示されているか確認する（ステップS１５１０５）。T-PGW_BS_Identityが一致しているか、若しくは関連性があるうえで、ＭＳＫの再利用の許可が示されていた場合、ＵＥ１は、Ｔ−ＰＧＷ５ｂに送信するためのAUTHパラメータを、Ｉ−ＰＧＷ５ａとＳＡを確立する際に生成したＭＳＫを用いて作成する（ステップＳ１５１２０）。一方、一致しなかった場合には、ＵＥ１は、受信したIKE_AUTH Responseメッセージを破棄する（図２２、ステップＳ１５０４０）。
続いて、ＵＥ１は、ステップＳ１５１２０で作成したAUTHパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する（図２２、ステップＳ１５１２１）。そして、ＵＥ１は、Ｔ−ＰＧＷ５ｂから送られてくるIKE_AUTH Responseメッセージを受信する（図２２、ステップＳ１５１２２）。
ＵＥ１は、ステップＳ１５１２２でIKE_AUTH Responseメッセージを送信したＴ−ＰＧＷ５ｂを認証（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）する（図２２、ステップＳ１５１２３）。ＵＥ１が、Ｔ−ＰＧＷ５ｂを認証できた場合（例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認など）には、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２２、ステップＳ１５１３０）。また、ＵＥ１が認証できなかった場合には、Ｔ−ＰＧＷ５ｂから受信したIKE_AUTH Responseメッセージを破棄する（図２２、ステップＳ１５０４０）。
なお、ＵＥ１が、Ｔ−ＰＧＷ５ｂを信頼することができる場合（例えば、T-PGW_BS_Identityが格納されている場合など）、あるいは、Ｔ−ＰＧＷ５ｂを認証する必要がない場合（例えば、例えば、IKE_AUTH Responseメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＴ−ＰＧＷ５ｂ）の正確性を確認することによる認証方法の確認や、鍵の確認などが既知、もしくは省略できる場合）には、ステップＳ１５１２３は省略することができ、Ｔ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する。また、Ｔ−ＰＧＷ５ｂによるＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）のみで相互の確認ができる場合は、ステップＳ１５１２３を省略してもよい。
なお、ＵＥ１が、ステップＳ１５００６で受信したIKE_AUTH Responseメッセージの中にＴ−ＰＧＷ５ｂのアドレスとUE_BS_Identityが格納されていなかった場合は、ＰＧＷ５の切り替えを要求されなかったことであることから、確立したＳＡを用いてＩ−ＰＧＷ５ａとＢＵ／ＢＡ交換を実施する（図２２、ステップＳ１５０３０）。
なお、本発明の第４の実施の形態における第３と第４のシーケンスにおいて、ＵＥ１がＴ−ＰＧＷ５ｂにＡＵＴＨパラメータを通知する場合（例えば、図２４のステップＳ１７１０２や図２５のステップＳ１８１０２）は、図２６に示すようにＵＥ１がＴ−ＰＧＷ５ｂとIKE_SA_INITメッセージを交換後（図２６、ステップＳ１９０１０）、Reuse Indicatorを生成するとともに、Ｉ−ＰＧＷ５ａとＳＡを確立した際に生成したＭＳＫを用いてＡＵＴＨパラメータを生成する。なお、ステップＳ１９０１１とステップＳ１９０１２を処理する順番は逆でも構わない。
続いて、ＵＥ１は、生成したReuse IndicatorとＡＵＴＨパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する（図２６、ステップＳ１９０１３）。
IKE_AUTH Responseメッセージを受信した後（図２６、ステップＳ１９０１４）、ＵＥ１はＴ−ＰＧＷ５ｂを認証する（図２６、ステップＳ１９０１５）。
その後、ＵＥ１はＴ−ＰＧＷ５ｂとＢＵ／ＢＡ交換を実施する（図２６、ステップＳ１９０２０）。
次に、本発明の第４の実施の形態におけるＰＧＷ５の構成と処理フローについて説明する。本発明の第４の実施の形態におけるＰＧＷ５の構成は、本発明の第１〜第３の実施の形態におけるＰＧＷ５の構成（図８を参照）と同様であるので説明を省略する。
以下、図８に図示されている構成を有するＰＧＷ５の処理フローについて、本発明における特徴的な処理を実施する接続制御部２０５に係る処理を中心に、図２３Ａと図２３Ｂと図２７を用いて詳しく説明する。なお、ＰＧＷ５は、既に通信部２０１を介し、３Ｇアクセス２（ホームリンク）に接続済みであるものとする。また、ＵＥ１が最初にアタッチ（接続）処理を試みるＰＧＷ５は、Ｉ−ＰＧＷ５ａとする。
図２３Ａは、本発明の第４の実施の形態におけるＰＧＷ５のＩ−ＰＧＷ５ａとしての処理フローの一例を示すフロー図である。本発明によるＰＧＷ５は、ＵＥ１とＳＡを確立するためにＵＥ１からのＢＳ処理（例えば、図２０のステップＳ１３００２や、ステップＳ１３００３など）を待つ。ＵＥ１はＩ−ＰＧＷ５ａとアタッチ（接続）処理を接続手順に従って開始する。
ＵＥ１が、例えばＮ３Ｇアクセス３に接続して、ＵＥ１が接続を所望するＰＧＷ５（Ｔ−ＰＧＷ５ｂ）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａ）がＤＮＳなどから割り当てられる際、ＵＥ１がＩ−ＰＧＷ５ａとアタッチ（接続）処理をしているときにネットワーク側（例えば、ＡＡＡサーバ８ａやＰＧＷ５など）の判断によってPDN GW reallocationが起こる（ＰＧＷ５を切り替える指示（例えば、Ｔ−ＰＧＷ５ｂのアドレスなど）がＵＥ１に通知される）（図２３Ａ、ステップＳ１６００１）。
従来技術のPDN GW reallocationでは、ＡＡＡサーバ８ａが図１４のステップＳ９０１０（若しくは、それ以前のステップ）でPDN GW reallocationの決定をして、Ｔ−ＰＧＷ５ｂのアドレスをＰＧＷに通知している（上記の非特許文献２を参照）。そこで、本発明の第４の実施の形態でも、説明の都合上、ＡＡＡサーバ８ａがPDN GW reallocationの決定をすることとする。
Ｉ−ＰＧＷ５ａは、ＡＡＡサーバ８ａがPDN GW reallocationの決定をした際、ＰＧＷ５の切り替え先であるＴ−ＰＧＷ５ｂのアドレスと、ＵＥ１とＩ−ＰＧＷ５ａの間で用いるＭＳＫと、ＡＡＡサーバ８ａがＵＥ１を一度フル認証したことを証明する証明書（例えば、UE_BS_Identityなど）をＡＡＡサーバ８ａから受信する（図２３Ａ、ステップＳ１６００２）。なお、ここでは、説明の都合上、ＡＡＡサーバ８ａがＵＥ１を一度フル認証したことを証明する証明書をUE_BS_Identityとする。
続いて、Ｉ−ＰＧＷ５ａは、ＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）（図２０のステップＳ１３０１３）するためや、ＵＥ１がＩ−ＰＧＷ５ａを認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）するために、ＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する（図２３Ａ、ステップＳ１６００３）。
Ｉ−ＰＧＷ５ｂは、ＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）できた場合、Ｔ−ＰＧＷ５ｂのアドレスと、UE_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２３Ａ、ステップＳ１６００４）。
一方、図２３Ｂは、本発明の第４の実施の形態におけるＰＧＷ５のＴ−ＰＧＷ５ｂとしての処理フローの一例を示すフロー図である。Ｔ−ＰＧＷ５ｂのアドレスを受信したＵＥ１は、PDN GW reallocationが起こったことを検出する。続いて、ＵＥ１は、Ｔ−ＰＧＷ５ｂとアタッチ（接続）処理を開始するために、IKE_SA_INITメッセージを送信する。
Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてきたIKE_SA_INITメッセージを受信する（図２３Ｂ、ステップＳ１６０１０）。続いて、Ｔ−ＰＧＷ５ｂは、IKE_SA_INITメッセージに格納されていたＮｏｎｃｅｓや、IKE_SA_INITメッセージ交換時に実施されるDiffie-Hellman鍵交換で生成・取得した共有鍵（例えば、SKEYSEED）を用いて、ＵＥ１とＴ−ＰＧＷ５ｂの間で用いるパケットの暗号化をするための鍵（例えば、SK_eiやSK_er）などを生成する（図２３Ｂ、ステップＳ１６０１１）。また、この時、IKE_AUTHメッセージに格納されるAUTHパラメータを認証するためのパラメータ（例えば、お互いの公開鍵など）を交換してもよい。なお、ＵＥ１とＴ−ＰＧＷ５ｂの間で用いる鍵生成は、ＮｏｎｃｅｓやDiffie-Hellman鍵交換で共有される鍵以外を用いてもよく、これらに限定されていない。
IKE_SA_INITメッセージ交換が終了した後、Ｔ−ＰＧＷ５ｂは、ＵＥ１から送られてくるIKE_AUTH Requestメッセージを受信する（図２３Ｂ、ステップＳ１６０１２）。Ｔ−ＰＧＷ５ｂは、ＵＥ１から受信したIKE_AUTH RequestメッセージのReuse Indicatorフィールド３００２に格納されているＭＳＫの再利用を示した値（例えば、Reuse keyなど）、若しくはＭＳＫの再利用を示す値に相当するものが格納されているか確認する（図２３Ｂ、ステップＳ１６０１３）。
このとき、Reuse keyなどのＭＳＫの再利用を示す値（若しくは、これに相当するもの）が格納されていなかった場合は、一般的なＢＳ処理を開始する。なお、Ｔ−ＰＧＷ５ｂが、フル認証をしたことを証明するUE_BS_Identityのみで、ＵＥ１がＭＳＫの再利用を希望していることを確認できる場合には、このReuse Indicatorフィールドは使用されない。
一方、Reuse keyなどのＭＳＫの再利用を示す値（若しくは、これに相当するもの）が格納されている場合は、ステップＳ１６０１２で受信したReuse keyとUE_BS_Identityを格納したAuthentication-Request/IdentityメッセージをＡＡＡサーバ８ａに送信する（図２３Ｂ、ステップＳ１６１００）。ＡＡＡサーバ８ａは、Ｔ−ＰＧＷ５ｂから送られてきたUE_BS_Identityと対応するＭＳＫとT-PGW_BS_IdentityをＴ−ＰＧＷ５ｂに送信する。なお、Ｉ−ＰＧＷ５ａからデータの暗号化などに用いる鍵（例えば、SK_eやSK_iなど）がＡＡＡサーバ８ａに転送され、かつ、ネットワーク側でデータの暗号化などに用いる鍵もＵＥ１とＴ−ＰＧＷ５ｂ間で再利用してよいという判断が下された場合に限り、その鍵情報（例えば、SK_eやSK_iなど）も同時にＴ−ＰＧＷ５ｂに送信してもよい。
Ｔ−ＰＧＷ５ｂは、ＭＳＫとT-PGW_BS_Identityなどが格納されたAuthentication_AnswerメッセージをＡＡＡサーバ８ａから受信する（図２３Ｂ、ステップＳ１６１０１）。続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａから受信したＭＳＫを用いてAUTHパラメータを作成する（図２３Ｂ、ステップＳ１６１０２）。Ｔ−ＰＧＷ５ｂは、ＭＳＫの再利用が可能であることを示すと同時にＴ−ＰＧＷ５ｂのなりすまし防止などを目的とするT-PGW_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２３Ｂ、ステップＳ１６１０３）。
ＵＥ１は、ＭＳＫの再利用が可能であることを確認した後、ＵＥ１が持つＭＳＫを用いてAUTHパラメータを作成する。続いて、ＵＥ１は、そのAUTHパラメータを格納したIKE_AUTH RequestメッセージをＴ−ＰＧＷ５ｂに送信する。Ｔ−ＰＧＷ５ｂは、ＵＥ１からIKE_AUTH Requestメッセージを受信する（図２３Ｂ、ステップＳ１６１０４）。
続いて、Ｔ−ＰＧＷ５ｂは、IKE_AUTH Requestメッセージを送信したＵＥ１を認証する（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）（図２３Ｂ、ステップＳ１６１０５）。このとき、Ｔ−ＰＧＷ５ｂは、ステップＳ１６１０２で作成したAUTHパラメータを比較対象として用いてもよい。なお、Ｔ−ＰＧＷ５ｂによるAUTHパラメータの作成は、ステップＳ１６１０２で行われたが、ＵＥ１を認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）する直前に生成してもよい。また、このＵＥ１の認証をする際に、Ｔ−ＰＧＷ５ｂが生成するAUTHパラメータを用いない場合、このAUTHパラメータの生成は、Ｔ−ＰＧＷ５ｂがAUTHパラメータをＵＥ１に送信するステップＳ１６２００の直前でもよい。
Ｔ−ＰＧＷ５ｂがＵＥ１の認証（例えば、IKE_AUTH Requestメッセージに格納されているAUTHパラメータを用いてIKE_SA_INITメッセージ（送信元であるＵＥ１）を認証、若しくは、IKE_SA_INITメッセージ（送信元であるＵＥ１）の正確性を確認することによる認証方法の確認や、鍵の確認など）をできた場合、Ｔ−ＰＧＷ５ｂはステップＳ１６１０２で作成したAUTHパラメータなどを含むIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２３Ｂ、ステップＳ１６２００）。続いて、Ｔ−ＰＧＷ５ｂは、ＵＥ１とＢＵ／ＢＡ交換を実施する（図２３Ｂ、ステップＳ１６２０１）。なお、Ｔ−ＰＧＷ５ｂが、ＵＥ１の認証をできなかった場合は、ＢＳ処理を終了する。
なお、本発明の第４の実施の形態における第３と第４のシーケンスにおいて、Ｔ−ＰＧＷ５ｂが、IKE_SA_INITメッセージ交換直後にＵＥ１からIKE_AUTH RequestメッセージでＡＵＴＨパラメータを通知される場合（例えば、図２４のステップＳ１７１０２や図２５のステップＳ１８１０２）は、Ｔ−ＰＧＷ５ｂはＵＥ１から送られてきたIKE_AUTH RequestメッセージにＡＵＴＨパラメータが格納されているか確認する（図２７、ステップＳ２００１３）。
IKE_AUTH RequestメッセージにＡＵＴＨパラメータが格納されている場合、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａにＵＥ１から受信したReuse keyとUE_BS_Identityが格納されているAuthentication-Requestメッセージを送信する（図２７、ステップＳ２０１００）。
続いて、Ｔ−ＰＧＷ５ｂは、ＡＡＡサーバ８ａからＭＳＫとT-PGW_BS_Identityが格納されたAuthentication-Responseメッセージを受信する（図２７、ステップＳ２０１０１）。
Ｔ−ＰＧＷ５ｂは、受信したＭＳＫを用いてＡＵＴＨパラメータを作成する（図２７、ステップＳ２０１０２）。
続いて、Ｔ−ＰＧＷ５ｂは、ＵＥ１を認証する（図２７、ステップＳ２０１０３）。なお、ＵＥ１を認証する際に、ステップＳ２０１０１で受信したＭＳＫや、ステップＳ２０１０２で生成したＡＵＴＨパラメータを用いてＵＥ１を認証してもよい（例えば、ＵＥ１から送られてきたＡＵＴＨパラメータとＴ−ＰＧＷ５ｂが生成したＡＵＴＨパラメータの比較など）。なお、Ｔ−ＰＧＷ５ｂが、ＵＥ１を認証する際、Ｔ−ＰＧＷ５ｂが生成するＡＵＴＨパラメータを用いない場合は、ステップＳ２０１０２とステップＳ２０１０３の処理する順番を入れ替えてもよい。
Ｔ−ＰＧＷ５ｂがＵＥ１を認証した場合、Ｔ−ＰＧＷ５ｂが生成したＡＵＴＨパラメータやT-PGW_BS_Identityを格納したIKE_AUTH ResponseメッセージをＵＥ１に送信する（図２７、ステップＳ２０１１０）。
続いて、Ｔ−ＰＧＷ５ｂはＵＥ１とＢＵ／ＢＡ交換を実施する（図２７、ステップＳ２０１１１）。
本発明の第４の実施の形態に基づいて処理することで、ＵＥ１が既に確立済みのＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）とは異なるＰＧＷ５（Ｉ−ＰＧＷ５ａに相当）が割り当てられた場合であっても、従来技術のPDN GW reallocation procedureと比べて、Ｔ−ＰＧＷ５ｂへの切り替え接続を短時間に完了させることができる。つまり、ＵＥ１とＴ−ＰＧＷ５ｂが、ＵＥ１とＩ−ＰＧＷ５ａのＳＡ確立時に作成したＭＳＫを再利用して、ＵＥ１とＴ−ＰＧＷ５ｂの間のＳＡを確立することで、ＵＥ１が所望のＰＧＷ５（Ｔ−ＰＧＷ５ｂに相当）との間の接続を短い時間で確立できるようになる。
なお、本発明の第４の実施の形態で用いたＭＳＫは、インターネットで利用される技術を標準化する組織であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が、ＲＦＣで定義しているＭＳＫと同じであってもよいし、別途規定されてもよい。
また、図２１に示したように、ＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知するような場合においても、ＵＥ１は、Reuse IndicatorとUE_BS_Identityとを格納したIKE_AUTH_RequestメッセージをＴ−ＰＧＷ５ｂに送信することが望ましい。これにより、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図２１、ステップＳ１４０１１）が遅延したりロスしたりして、Ｔ−ＰＧＷ５ｂが鍵データ（ＭＳＫ）の再利用（フル認証の省略）を認識していない場合であっても、Ｔ−ＰＧＷ５ｂ越しにＭＳＫの再利用を実施することができ、切り替え接続のための時間短縮をより確実なものとすることができる。
また、図２１に図示されている第２のシーケンスでＡＡＡサーバ８ａが事前にＴ−ＰＧＷ５ｂに対してＭＳＫなどの情報を通知する場合において、ＡＡＡサーバ８ａからＴ−ＰＧＷ５ｂへのBS_Identity通知（図２１、ステップＳ１４０１１）が遅延したりロスしたりしないことがシステムとして保証されているような場合には、Reuse Indicatorの代わりとしてUser IdentityやＵＥ１のアドレスを使用することで、ＵＥ１はReuse Indicatorを図２２のステップＳ１５０１１で生成したり、ステップＳ１５０１２でIKE_AUTH_Requestメッセージに格納したりしなくてもよい。
またさらには、ＡＡＡサーバ８ａにおいてＵＥ１からの接続要求に含まれるＡＰＮ（Access Point Name）などを前回の接続要求（Ｉ−ＰＧＷ５ａ経由）で通知されたものと比較するなどの方法により、本接続要求がＴ−ＰＧＷ５ｂへの切り替えを意図していることが確認できる場合、UE_BS_Identityは最早不要であり、図２２のステップＳ１５００７でＵＥ１への通知は行われない。このときＵＥ１は、Ｔ−ＰＧＷ５ｂに対して標準的なＢＳ処理を実行すればよく（図２２には不図示）、これにより、ＭＳＫの再利用がネットワーク側の判断によって実施され、Ｔ−ＰＧＷ５ｂへの切り替え接続を短時間に完了させることができる。
なお、本発明の第４の実施の形態で用いられているUE_BS_Identity並びにT-PGW_BS_Identityに関しても、上述の第１の実施の形態と同様に、様々な組み合わせが可能である。すなわち、本発明の第４の実施の形態において、例えば、UE_BS_Identityと、このUE_BS_Identityに対応するT-PGW_BS_Identityを用いて、UE_BS_IdentityとT-PGW_BS_Identityとの照合が行われてもよく、どちらか一方のBS_Identityが用いられてもよく、あるいは、BS_Identityが用いられなくてもよい。また、本発明の第４の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityに使用される情報として、例えば、ＵＥ１及びＰＧＷ５によって共有されている値を基に生成されたハッシュ値や、ランダムに生成された値やＩ−ＰＧＷ５ａのアドレス（これらに限定されない）など、ＵＥ１及びＰＧＷ５によって認識可能な値（符号）を用いることが可能である。また、本発明の第４の実施の形態においても、UE_BS_IdentityやT-PGW_BS_Identityは、ＰＧＷ５、ＡＡＡサーバ８ａ、あるいは、その他の通信装置によって生成されてもよい。
なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明のゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末は、複数のＣｏＡを使用している移動端末のＣｏＡを管理するＰＧＷ５を確実かつ迅速に統一できるようになり、その結果、移動端末は、複数のＣｏＡを使用した通信における利益を確実かつ迅速に享受できるようになるという効果を有しており、複数の通信インタフェースを有する移動端末が、これら複数の通信インタフェースを用いて異なるアクセスネットワークを介して所定のゲートウェイにアクセスするため技術に適用可能である。

Claims (55)

  1. 複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムにおいて、前記移動端末を所望のゲートウェイに接続させるためのゲートウェイ接続方法であって、
    前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出するステップと、
    前記移動端末が、前記検出ステップの結果をうけて、前記第２のゲートウェイに前記移動端末の収容状況を問い合わせるステップと、
    前記第２のゲートウェイが、前記移動端末の収容状況を確認するステップと、
    前記第２のゲートウェイが、前記移動端末を収容していないと判断した場合に、前記第１のゲートウェイに接続指示を送信するステップと、
    前記第２のゲートウェイが、前記移動端末に待機指示を送信するステップと、
    前記第１のゲートウェイが、前記移動端末に接続処理を開始するステップとを、
    有するゲートウェイ接続方法。
  2. 前記移動端末が前記収容状況を問い合わせるステップにおいて、前記移動端末が、前記第１のゲートウェイへの接続時に払い出されたホームプレフィクスを通知することを特徴とする請求項１に記載のゲートウェイ接続方法。
  3. 前記移動端末が前記収容状況を問い合わせるステップにおいて、前記移動端末が、収容状況の確認を要求する明示的な指示を送信することを特徴とする請求項１に記載のゲートウェイ接続方法。
  4. 前記第２のゲートウェイが前記収容状況を確認するステップにおいて、前記第２のゲートウェイが、取得した前記移動端末のホームプレフィクスに基づいて自身が管理する移動管理テーブルを探索することを特徴とする請求項１に記載のゲートウェイ接続方法。
  5. 前記第２のゲートウェイが前記接続指示を送信するステップにおいて、前記接続指示は認証サーバを介して前記第１のゲートウェイに転送されることを特徴とする請求項１に記載のゲートウェイ接続方法。
  6. 前記第１のゲートウェイの識別子は、前記認証サーバによって導出されることを特徴とする請求項５に記載のゲートウェイ接続方法。
  7. 前記第２のゲートウェイが、前記待機指示と前記接続指示に第１の符号を含めて送信し、
    前記第１のゲートウェイが、前記移動端末に接続処理を開始する際に取得した第２の符号を通知し、
    前記移動端末は、前記待機指示から取得した前記第１の符号と、前記第１のゲートウェイとの接続開始時に取得した前記第２の符号を比較して、一致する場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１に記載のゲートウェイ接続方法。
  8. 前記第１のゲートウェイが前記移動端末に接続処理を開始する際に所定の符号を通知し、
    前記移動端末は取得した前記所定の符号が所定の値と一致する場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１に記載のゲートウェイ接続方法。
  9. 前記第２のゲートウェイが前記待機指示に第１の符号を含めて前記移動端末に送信し、
    同時に前記第２のゲートウェイが前記接続指示に前記第１の符号を含めて送信し、
    前記第１のゲートウェイが前記第１の符号に基づく第２の符号を取得して、接続処理開始時に前記移動端末に通知し、
    前記移動端末は前記第１の符号と前記第２の符号の相関を確認できた場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１に記載のゲートウェイ接続方法。
  10. 前記第２のゲートウェイが前記待機指示に第１の符号を含めて前記移動端末に送信し、
    同時に前記第２のゲートウェイが前記第１の符号に基づく第２の符号を取得して前記接続指示に前記第２の符号を含めて送信し、
    前記第２のゲートウェイが、接続処理開始時に前記移動端末に前記第２の符号を通知し、
    前記移動端末は前記第１の符号と前記第２の符号の相関を確認できた場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１に記載のゲートウェイ接続方法。
  11. 複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなるゲートウェイ接続制御システムであって、
    前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出し、
    前記移動端末が、前記検出ステップの結果をうけて、前記第２のゲートウェイに前記移動端末の収容状況を問い合わせ、
    前記第２のゲートウェイが、前記移動端末の収容状況を確認し、
    前記第２のゲートウェイが、前記移動端末を収容していないと判断した場合に、前記第１のゲートウェイに接続指示を送信し、
    前記第２のゲートウェイが、前記移動端末に待機指示を送信し、
    前記第１のゲートウェイが、前記移動端末に接続処理を開始することによって、
    前記移動端末を所望のゲートウェイに接続させるよう構成されているゲートウェイ接続制御システム。
  12. 前記移動端末が前記収容状況を問い合わせる際に、前記移動端末が、前記第１のゲートウェイへの接続時に払い出されたホームプレフィクスを通知することを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  13. 前記移動端末が前記収容状況を問い合わせる際に、前記移動端末が、収容状況の確認を要求する明示的な指示を送信することを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  14. 前記第２のゲートウェイが前記収容状況を確認する際に、前記第２のゲートウェイが、取得した前記移動端末のホームプレフィクスに基づいて自身が管理する移動管理テーブルを探索することを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  15. 前記第２のゲートウェイによって送信される前記接続指示は、認証サーバを介して前記第１のゲートウェイに転送されることを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  16. 前記第１のゲートウェイの識別子は、前記認証サーバによって導出されることを特徴とする請求項１５に記載のゲートウェイ接続制御システム。
  17. 前記第２のゲートウェイが、前記待機指示と前記接続指示に第１の符号を含めて送信し、
    前記第１のゲートウェイが、前記移動端末に接続処理を開始する際に取得した第２の符号を通知し、
    前記移動端末は、前記待機指示から取得した前記第１の符号と、前記第１のゲートウェイとの接続開始時に取得した前記第２の符号を比較して、一致する場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  18. 前記第１のゲートウェイが前記移動端末に接続処理を開始する際に所定の符号を通知し、
    前記移動端末は取得した前記所定の符号が所定の値と一致する場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  19. 前記第２のゲートウェイが前記待機指示に第１の符号を含めて前記移動端末に送信し、
    同時に前記第２のゲートウェイが前記接続指示に前記第１の符号を含めて送信し、
    前記第１のゲートウェイが前記第１の符号に基づく第２の符号を取得して、接続処理開始時に前記移動端末に通知し、
    前記移動端末は前記第１の符号と前記第２の符号の相関を確認できた場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  20. 前記第２のゲートウェイが前記待機指示に第１の符号を含めて前記移動端末に送信し、
    同時に前記第２のゲートウェイが前記第１の符号に基づく第２の符号を取得して前記接続指示に前記第２の符号を含めて送信し、
    前記第２のゲートウェイが、接続処理開始時に前記移動端末に前記第２の符号を通知し、
    前記移動端末は前記第１の符号と前記第２の符号の相関を確認できた場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項１１に記載のゲートウェイ接続制御システム。
  21. 複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末であり、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムに接続する際に、前記複数のゲートウェイのうちの所望のゲートウェイに接続することが可能な移動端末であって、
    ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイアドレスを取得したことを検出する手段と、
    検出された前記第２のゲートウェイに前記移動端末の収容状況を問い合わせる手段と、
    前記第２のゲートウェイによって前記移動端末の収容状況が確認され、前記第２のゲートウェイが前記移動端末を収容していないと判断された場合に、待機指示を前記第２のゲートウェイから受信する手段と、
    前記第２のゲートウェイによって前記移動端末の収容状況が確認され、前記第２のゲートウェイが前記移動端末を収容していないと判断された場合に、前記第２のゲートウェイから前記第１のゲートウェイに接続指示が送信され、前記第１のゲートウェイが前記接続指示に基づいて開始した前記移動端末との間の接続処理を行う手段とを、
    有する移動端末。
  22. 前記移動端末が前記収容状況を問い合わせる際に、前記第１のゲートウェイへの接続時に払い出されたホームプレフィクスを通知することを特徴とする請求項２１に記載の移動端末。
  23. 前記移動端末が前記収容状況を問い合わせる際に、収容状況の確認を要求する明示的な指示を送信することを特徴とする請求項２１に記載の移動端末。
  24. 前記待機指示と前記接続指示に第１の符号を含めて前記第２のゲートウェイから送信されるとともに、前記第１のゲートウェイが前記移動端末に接続処理を開始する際に取得した第２の符号が前記第１のゲートウェイから通知され、
    前記待機指示から取得した前記第１の符号と、前記第１ゲートウェイとの接続開始時に取得した前記第２の符号を比較して、一致する場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項２１に記載の移動端末。
  25. 前記第１のゲートウェイが前記移動端末に接続処理を開始する際に所定の符号が前記第１のゲートウェイから通知され、
    通知された前記所定の符号が所定の値と一致する場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項２１に記載の移動端末。
  26. 前記待機指示に第１の符号を含めて前記第２のゲートウェイから前記移動端末に送信され、同時に前記接続指示に前記第１の符号を含めて前記第２のゲートウェイから送信され、前記第１のゲートウェイによって前記第１の符号に基づく第２の符号が取得されて前記第１のゲートウェイが前記移動端末に接続処理を開始する際に前記第２の符号が前記第１のゲートウェイから通知され、
    前記第１の符号と前記第２の符号の相関を確認できた場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項２１に記載の移動端末。
  27. 前記待機指示に第１の符号を含めて前記第２のゲートウェイから前記移動端末に送信され、同時に前記接続指示に前記第１の符号を含めて前記第２のゲートウェイから送信され、前記第２のゲートウェイによって前記第１の符号に基づく第２の符号を取得されて前記第１のゲートウェイが前記移動端末に接続処理を開始する際に前記第２の符号が前記第１のゲートウェイから通知され、
    前記第１の符号と前記第２の符号の相関を確認できた場合に、前記第１のゲートウェイからの接続処理を受理することを特徴とする請求項２１に記載の移動端末。
  28. 複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムにおいて、前記移動端末を所望のゲートウェイに接続させるためのゲートウェイ接続方法であって、
    前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出するステップと、
    前記移動端末が、前記検出ステップの結果をうけて前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換するステップと、
    前記鍵情報の交換完了後、前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知するステップと、
    前記移動端末が、前記第１のゲートウェイへの接続処理を開始するステップと、
    前記第１のゲートウェイが、前記相互認証によって作成された前記鍵情報を前記認証サーバから取得するステップと、
    前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するステップとを、
    有するゲートウェイ接続方法。
  29. 前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するステップにおいて、前記移動端末が、前記相互認証によって作成された前記鍵情報を用いて、前記第１のゲートウェイへの接続処理を行うことを特徴とする請求項２８に記載のゲートウェイ接続方法。
  30. 前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するステップにおいて、前記移動端末と前記第１のゲートウェイの間で、前記鍵情報を用いた接続確認を行うことを特徴とする請求項２８に記載のゲートウェイ接続方法。
  31. 前記第２のゲートウェイが前記第１のゲートウェイのアドレスを前記移動端末へ通知するステップにおいて、前記移動端末が、前記第２のゲートウェイからのメッセージによって、前記第１のゲートウェイへの接続に際して前記相互認証によって作成された前記鍵情報の再利用が可能であると判断できることを特徴とする請求項２８に記載のゲートウェイ接続方法。
  32. 前記移動端末が、前記第１のゲートウェイへの接続処理を開始するステップにおいて、前記第１のゲートウェイとメッセージ交換をすることで、前記鍵情報の再利用が可能であると判断できることを特徴とする請求項２８に記載のゲートウェイ接続方法。
  33. 前記移動端末が前記第１のゲートウェイへの接続処理を開始するステップにおいて、前記鍵情報の再利用を要求することを特徴とする請求項２８に記載のゲートウェイ接続方法。
  34. 前記第１のゲートウェイが前記鍵情報を前記認証サーバから取得するステップにおいて、前記第１のゲートウェイからの要求に応じて、前記認証サーバが前記鍵情報を前記第１のゲートウェイへ通知することを特徴とする請求項２８に記載のゲートウェイ接続方法。
  35. 前記第１のゲートウェイが前記鍵情報を前記認証サーバから取得するステップにおいて、前記認証サーバが前記相互認証によって前記移動端末の認証に成功した後に、前記鍵情報を前記第１のゲートウェイへ通知することを特徴とする請求項２８に記載のゲートウェイ接続方法。
  36. 前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知する際に第１の符号を通知し、
    前記第１のゲートウェイが、前記移動端末が前記第１のゲートウェイへの接続処理を行う際に第２の符号を通知し、
    前記移動端末は、前記第２のゲートウェイから受信した前記第１の符号と、前記第１のゲートウェイから受信した前記第２の符号を比較して、一致する場合に、前記第１のゲートウェイへのアドレス登録処理を行うことを特徴とする請求項２８に記載のゲートウェイ接続方法。
  37. 前記第１のゲートウェイが、前記移動端末が前記第１のゲートウェイへの接続処理を行う際に所定の符号を通知し、
    前記移動端末は、受信した前記所定の符号が所定の値と一致する場合に、前記第１のゲートウェイへのアドレス登録処理を行うことを特徴とする請求項２８に記載のゲートウェイ接続方法。
  38. 複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末と、前記移動端末を収容して移動管理を行う複数のゲートウェイからなるゲートウェイ接続制御システムであって、
    前記移動端末が、ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイのアドレスを取得したことを検出し、
    前記移動端末が、前記検出ステップの結果をうけて前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換し、
    前記鍵情報の交換完了後、前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知し、
    前記移動端末が、前記第１のゲートウェイへの接続処理を開始し、
    前記第１のゲートウェイが、前記相互認証によって作成された前記鍵情報を前記認証サーバから取得し、
    前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続するよう構成されているゲートウェイ接続制御システム。
  39. 前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続する際に、前記移動端末が、前記相互認証によって作成された前記鍵情報を用いて、前記第１のゲートウェイへの接続処理を行うことを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  40. 前記移動端末が、前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続する際に、前記移動端末と前記第１のゲートウェイの間で、前記鍵情報を用いた接続確認を行うことを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  41. 前記第２のゲートウェイが前記第１のゲートウェイのアドレスを前記移動端末へ通知する際に、前記移動端末が、前記第２のゲートウェイからのメッセージによって、前記第１のゲートウェイへの接続に際して前記相互認証によって作成された前記鍵情報の再利用が可能であると判断できることを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  42. 前記移動端末が、前記第１のゲートウェイへの接続処理を開始する際に、前記第１のゲートウェイとメッセージ交換をすることで、前記鍵情報の再利用が可能であると判断できることを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  43. 前記移動端末が前記第１のゲートウェイへの接続処理を開始する際に、前記鍵情報の再利用を要求することを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  44. 前記第１のゲートウェイが前記鍵情報を前記認証サーバから取得する際に、前記第１のゲートウェイからの要求に応じて、前記認証サーバが前記鍵情報を前記第１のゲートウェイへ通知することを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  45. 前記第１のゲートウェイが前記鍵情報を前記認証サーバから取得する際に、前記認証サーバが前記相互認証によって前記移動端末の認証に成功した後に、前記鍵情報を前記第１のゲートウェイへ通知することを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  46. 前記第２のゲートウェイが、前記第１のゲートウェイのアドレスを前記移動端末へ通知する際に第１の符号を通知し、
    前記第１のゲートウェイが、前記移動端末が前記第１のゲートウェイへの接続処理を行う際に第２の符号を通知し、
    前記移動端末は、前記第２のゲートウェイから受信した前記第１の符号と、前記第１のゲートウェイから受信した前記第２の符号を比較して、一致する場合に、前記第１のゲートウェイへのアドレス登録処理を行うことを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  47. 前記第１のゲートウェイが、前記移動端末が前記第１のゲートウェイへの接続処理を行う際に所定の符号を通知し、
    前記移動端末は、受信した前記所定の符号が所定の値と一致する場合に、前記第１のゲートウェイへのアドレス登録処理を行うことを特徴とする請求項３８に記載のゲートウェイ接続制御システム。
  48. 複数の通信インタフェースを介して複数のアクセスネットワークに接続可能な移動端末であり、前記移動端末を収容して移動管理を行う複数のゲートウェイからなる通信システムに接続する際に、前記複数のゲートウェイのうちの所望のゲートウェイに接続することが可能な移動端末であって、
    ホームリンク経由で第１のゲートウェイと接続済みであり、異なるアクセスネットワークに接続した際にＤＮＳサーバから第２のゲートウェイアドレスを取得したことを検出する手段と、
    前記第２のゲートウェイへの接続処理を開始し、認証サーバとの間で相互認証を行って作成された鍵情報を前記第２のゲートウェイとの間で交換する手段と、
    前記鍵情報の交換完了後、前記第２のゲートウェイから前記第１のゲートウェイのアドレスを受信し、前記第１のゲートウェイへの接続処理を開始する手段と、
    前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続する手段とを、
    有する移動端末。
  49. 前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続する際に、前記相互認証によって作成された前記鍵情報を用いて、前記第１のゲートウェイへの接続処理を行うことを特徴とする請求項４８に記載の移動端末。
  50. 前記相互認証によって作成された前記鍵情報を再利用して、前記第１のゲートウェイへ接続する際に、前記移動端末と前記第１のゲートウェイの間で、前記鍵情報を用いた接続確認を行うことを特徴とする請求項４８に記載の移動端末。
  51. 前記第２のゲートウェイが前記第１のゲートウェイのアドレスを前記移動端末へ通知する際に、前記第２のゲートウェイからのメッセージによって、前記第１のゲートウェイへの接続に際して前記相互認証によって作成された前記鍵情報の再利用が可能であると判断できることを特徴とする請求項４８に記載の移動端末。
  52. 前記第１のゲートウェイへの接続処理を開始する際に、前記第１のゲートウェイとメッセージ交換をすることで、前記鍵情報の再利用が可能であると判断できることを特徴とする請求項４８に記載の移動端末。
  53. 前記第１のゲートウェイへの接続処理を開始する際に、前記鍵情報の再利用を要求することを特徴とする請求項４８に記載の移動端末。
  54. 前記第２のゲートウェイから前記第１のゲートウェイのアドレスが通知される際に第１の符号が前記移動端末へ通知され、前記第１のゲートウェイへの接続処理を行う際に前記第１のゲートウェイから第２の符号が前記移動端末へ通知され、
    前記第２のゲートウェイから受信した前記第１の符号と、前記第１のゲートウェイから受信した前記第２の符号を比較して、一致する場合に、前記第１のゲートウェイへのアドレス登録処理を行うことを特徴とする請求項４８に記載の移動端末。
  55. 前記第１のゲートウェイへの接続処理を行う際に前記第１のゲートウェイから所定の符号が前記移動端末へ通知され、
    受信した前記所定の符号が所定の値と一致する場合に、前記第１のゲートウェイへのアドレス登録処理を行うことを特徴とする請求項４８に記載の移動端末。
JP2010550437A 2009-02-13 2010-01-29 ゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末 Withdrawn JPWO2010092764A1 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
JP2009031883 2009-02-13
JP2009031883 2009-02-13
JP2009061990 2009-03-13
JP2009061990 2009-03-13
JP2009193595 2009-08-24
JP2009193595 2009-08-24
PCT/JP2010/000551 WO2010092764A1 (ja) 2009-02-13 2010-01-29 ゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末

Publications (1)

Publication Number Publication Date
JPWO2010092764A1 true JPWO2010092764A1 (ja) 2012-08-16

Family

ID=42561613

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010550437A Withdrawn JPWO2010092764A1 (ja) 2009-02-13 2010-01-29 ゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末

Country Status (3)

Country Link
US (1) US20120020343A1 (ja)
JP (1) JPWO2010092764A1 (ja)
WO (1) WO2010092764A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101718096B1 (ko) * 2009-12-01 2017-03-20 삼성전자주식회사 무선통신 시스템에서 인증방법 및 시스템
CN102196407B (zh) * 2010-03-18 2015-09-16 中兴通讯股份有限公司 锚定鉴权器重定位方法及系统
US9154487B2 (en) 2010-11-05 2015-10-06 Telefonaktiebolaget L M Ericsson (Publ) Registration server, gateway apparatus and method for providing a secret value to devices
KR101338486B1 (ko) 2010-12-21 2013-12-10 주식회사 케이티 Ｉ-ｗｌａｎ의 게이트웨이 및 그의 호 추적 방법
WO2013004905A1 (en) * 2011-07-07 2013-01-10 Nokia Corporation Trusted wireless local area network access
US20140071907A1 (en) * 2012-05-04 2014-03-13 Telefonaktiebolaget L M Ericsson (Publ) Method and Apparatus for Handling PDN Connections
EP3086599A4 (en) * 2013-12-20 2017-06-07 Kyocera Corporation Communication control method, gateway device, and user terminal
JP2015194947A (ja) * 2014-03-31 2015-11-05 ソニー株式会社 情報処理装置及びコンピュータプログラム
CN105338511B (zh) * 2014-06-25 2019-08-16 华为技术有限公司 网络拓扑隐藏方法和设备
JP6577052B2 (ja) * 2015-04-22 2019-09-18 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． アクセスポイント名許可方法、アクセスポイント名許可装置、およびアクセスポイント名許可システム
EP3709601B1 (en) * 2017-03-17 2022-02-16 Telefonaktiebolaget LM Ericsson (publ) Network node for use in a communication network, a communication device and methods of operating the same
US11223507B2 (en) * 2017-04-18 2022-01-11 Qualcomm Incorporated Payload with synchronization information
EP3831111A1 (en) * 2018-08-02 2021-06-09 Telefonaktiebolaget LM Ericsson (publ) Secured authenticated communication between an initiator and a responder
WO2020145064A1 (en) * 2019-01-11 2020-07-16 Nec Corporation A method and a device for enabling key re-usage in a communication network
US11032743B1 (en) * 2019-11-30 2021-06-08 Charter Communications Operating, Llc Methods and apparatus for supporting devices of different types using a residential gateway
WO2023226956A1 (zh) * 2022-05-25 2023-11-30 华为技术有限公司 一种网络设备和通信系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3688830B2 (ja) * 1995-11-30 2005-08-31 株式会社東芝 パケット転送方法及びパケット処理装置
JPH10178421A (ja) * 1996-10-18 1998-06-30 Toshiba Corp パケット処理装置、移動計算機装置、パケット転送方法及びパケット処理方法
US20070208864A1 (en) * 2002-10-21 2007-09-06 Flynn Lori A Mobility access gateway
US7499401B2 (en) * 2002-10-21 2009-03-03 Alcatel-Lucent Usa Inc. Integrated web cache
CN1265607C (zh) * 2003-12-08 2006-07-19 华为技术有限公司 无线局域网中业务隧道建立的方法
DE102004045147A1 (de) * 2004-09-17 2006-03-23 Fujitsu Ltd., Kawasaki Einstellungsinformations-Verteilungsvorrichtung, Verfahren, Programm und Medium, Authentifizierungseinstellungs-Transfervorrichtung, Verfahren, Programm und Medium und Einstellungsinformations-Empfangsprogramm
TWI305462B (en) * 2005-12-29 2009-01-11 Ind Tech Res Inst Method and system for secure authentication in a wireless network
US8130771B2 (en) * 2006-10-10 2012-03-06 Alcatel Lucent Packet-forwarding for proxy mobile IP
US8346268B2 (en) * 2006-11-20 2013-01-01 Alcatel Lucent Network controlled mobility route optimization for an IP base station transceiver architecture

Also Published As

Publication number Publication date
WO2010092764A1 (ja) 2010-08-19
US20120020343A1 (en) 2012-01-26

Similar Documents

Publication Publication Date Title
WO2010092764A1 (ja) ゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末
JP5166525B2 (ja) モバイルノードのためのアクセスネットワーク−コアネットワーク間信頼関係検出
KR102315881B1 (ko) 사용자 단말과 진화된 패킷 코어 간의 상호 인증
US8964695B2 (en) Optimization of handovers to untrusted non-3GPP networks
US9686669B2 (en) Method of configuring a mobile node
US9973925B2 (en) Method and apparatus for direct communication key establishment
JP5554342B2 (ja) アクセスネットワークへの接続又はハンドオーバの後のセキュアトンネルの確立
EP1875707B1 (en) Utilizing generic authentication architecture for mobile internet protocol key distribution
EP2774402B1 (en) Securing data communications in a communications network
US7636569B2 (en) Method of registering home address of a mobile node with a home agent
JP4768720B2 (ja) ネットワークにアクセスするユーザ端末に対してジェネリック認証アーキテクチャーを応用して管理する方法及びシステム
US9986431B2 (en) Method and apparatus for direct communication key establishment
US7984486B2 (en) Using GAA to derive and distribute proxy mobile node home agent keys
KR102390380B1 (ko) 비인증 사용자에 대한 3gpp 진화된 패킷 코어로의 wlan 액세스를 통한 긴급 서비스의 지원
WO2009056938A2 (en) System and method for authenticating a context transfer
TWI627870B (zh) 通訊系統中閘道器節點之選擇
RU2727160C1 (ru) Аутентификация для систем следующего поколения
CN113498060B (zh) 一种控制网络切片认证的方法、装置、设备及存储介质
KR100879986B1 (ko) 모바일 네트워크 시스템 및 그 시스템의 핸드오버 방법
US9137661B2 (en) Authentication method and apparatus for user equipment and LIPA network entities
WO2007143950A1 (fr) Appareil et procédé de mise en œuvre de l'amorce du nœud en double pile d'un réseau hétérogène
US20110107403A1 (en) Communication system, server apparatus, information communication method, and program
US20110153819A1 (en) Communication system, connection apparatus, information communication method, and program
KR20080099991A (ko) 이동통신 시스템에서 프록시 이동 인터넷 프로토콜을이용한 이동 단말의 이동성 관리 방법 및 시스템
US20110093604A1 (en) Communication system, server apparatus, information communication method, and program

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20130402