(57)【要約】  ノード（２０）は、ユーザ端末（１０）が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータ（２０Ａ）に対するアドレス解決結果（２０Ａ′）と、前記第１のパケットデータ（２０Ａ）の送信元を自ノードとする第２のパケットデータ（２０Ｂ）に対するアドレス解決結果（２０Ｂ′）とを比較し、その比較結果が異なる場合に、第２のアドレス解決結果（２０Ｂ′）をユーザ端末（１０）に割り当てて、ユーザ端末（１０）と第２のアドレス解決結果（２０Ｂ′）が示す第２のコンテンツサーバとの間の通信路を設定する。ユーザ端末（１０）は、前記割り当てられた第２のアドレス解決結果（２０Ｂ′）を用いて前記通信路にて前記第２のコンテンツサーバにアクセスする。
2009075033.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおいて、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送する手段と、
前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信する手段と、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する手段と、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する手段と、
をそなえたことを特徴とする、パケット通信システム。
【請求項２】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるパケット通信方法であって、
前記ノードは、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送するとともに、前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信し、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較し、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定し、
前記ユーザ端末は、
前記割り当てられた第２のアドレス解決結果を用いて前記通信路にて前記第２のコンテンツサーバにアクセスする、
ことを特徴とする、パケット通信システムにおけるパケット通信方法。
【請求項３】
前記ノードは、
前記比較結果が一致する場合、前記第１のアドレス解決結果を前記ユーザ端末に割り当て、
前記ユーザ端末は、
前記割り当てられた第１のアドレス解決結果を用いて前記第１のコンテンツサーバにアクセスする、
ことを特徴とする、請求項２記載のパケット通信システムにおけるパケット通信方法。
【請求項４】
前記ノードは、
前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで、前記割り当てを実施する、ことを特徴とする、請求項２又は３に記載のパケット通信システムにおけるパケット通信方法。
【請求項５】
前記ユーザ端末は、
前記通信路設定要求に含まれる前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、
ことを特徴とする、請求項４記載のパケット通信システムにおけるパケット通信方法。
【請求項６】
前記ユーザ端末は、
前記通信路を経由した通信が終了すると、前記通信路の解放要求を前記ノード宛に送信し、
前記ノードは、
前記解放要求を受信すると、前記通信路の設定を解放する、
ことを特徴とする、請求項２〜５のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
【請求項７】
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網のゲートウェイノードである、
ことを特徴とする、請求項２〜６のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
【請求項８】
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網以外のパケットデータ網であって前記ホームパケットデータ網と接続された網のゲートウェイノードである、
ことを特徴とする、請求項２〜６のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
【請求項９】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるノードであって、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを受信する受信手段と、
前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成する生成手段と、
前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第２のパケットデータを第２のアドレス解決サーバ宛に送信する送信手段と、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する比較手段と、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する通信路設定手段と、
をそなえたことを特徴とする、パケット通信システムにおけるノード。
【請求項１０】
前記通信路設定手段は、
前記比較結果が一致する場合、前記第１のアドレス解決結果を前記ユーザ端末に割り当てる、ことを特徴とする、請求項９記載のパケット通信システムにおけるノード。
【請求項１１】
前記通信路設定手段は、
前記割り当てを、前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで実施する、ことを特徴とする、請求項９又は１０に記載のパケット通信システムにおけるノード。
【請求項１２】
前記通信路設定手段は、
前記通信路を経由した通信の終了により前記ユーザ端末が送信した前記通信路の解放要求を受信すると、前記通信路の設定を解放する、
ことを特徴とする、請求項９〜１１のいずれか１項に記載のパケット通信システムにおけるノード。
【請求項１３】
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網のゲートウェイノードである、
ことを特徴とする、請求項９〜１２のいずれか１項に記載のパケット通信システムにおけるノード。
【請求項１４】
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網以外のパケットデータ網であって前記ホームパケットデータ網と接続された網のゲートウェイノードである、
ことを特徴とする、請求項９〜１２のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
【請求項１５】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおける前記ユーザ端末であって、
第１のコンテンツサーバにアクセスするために第１のパケットデータを送信する送信手段と、
前記第１のパケットデータを受信した前記パケット通信システムのノードが、前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信したことにより、前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから前記ノードに返信された第１及び第２のアドレス解決結果が異なる場合に、前記ノードから送信された前記第２のアドレス解決結果を受信する受信手段と、
前記第２のアドレス解決結果を用いて、前記ノードにより前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間に設定された通信路にて前記第２のコンテンツサーバに対するアクセスを行なう通信制御手段と、
をそなえたことを特徴とする、パケット通信システムにおけるユーザ端末。
【請求項１６】
前記通信制御手段は、
前記第２のアドレス解決結果が、前記ノードから受信した、前記通信路の設定手順の開始を要求する通信路設定要求に含まれている場合に、前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、ことを特徴とする、請求項１５記載のパケット通信システムにおけるユーザ端末。
【請求項１７】
前記通信制御手段は、
前記通信路を経由した通信が終了すると、前記通信路の解放要求を前記ノード宛に送信する、ことを特徴とする、請求項１５又は１６に記載のパケット通信システムにおけるユーザ端末。
【請求項１８】
前記通信制御手段は、
前記解放要求に対する応答を受信することにより、前記通信路のために確保した通信リソースを解放する、ことを特徴とする、請求項１７記載のパケット通信システムにおけるユーザ端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信システム及びパケット通信方法並びにノード及びユーザ端末に関する。本発明は、例えば、３ＧＰＰ（3rd Generation Partnership Project）のモバイル通信システムに用いると好適である。
【背景技術】
【０００２】
インターネットにおけるコンテンツ配信網（ＣＤＮ：Contents Delivery Network）に関する技術として、下記の特許文献１に記載された技術がある。【０００３】
この特許文献１には、トンネル・リダイレクション装置が、ユーザ端末とインターネット上のプロバイダセンタ〔ＷＷＷ（World Wide Web）サーバ、ＤＮＳ（Domain Name System）サーバ〕との間に構成された第１のトンネル上のパケットを交換し、また、プロバイダのコンテンツサーバとの間に第２のトンネルを構成して第１のトンネル上のユーザ端末から前記コンテンツサーバへのパケットを抽出して第２のトンネルのパケットに変換して前記コンテンツサーバに転送し、第２のトンネル上の前記コンテンツサーバからユーザ端末へのパケットを前記第１のトンネルのパケットに変換してユーザ端末へ転送する、ことが記載されている。この技術によれば、ユーザが１つのネットワークトンネルを管理するのみで複数のネットワークトンネルを介してパケットを伝送することが可能となる。【０００４】
また、下記の非特許文献１では、３ＧＰＰの次世代モバイル通信システムにおいて、移動局（ＵＥ：User Equipment）が、移動（訪問）先の在圏網（Visited網）から、ホーム網を経由せずに、直接、外部のパケットデータ網（ＰＤＮ：Packet Data Network）との通信を可能とする方式（ローカルブレークアウト方式と呼ばれる）が検討されている。
【特許文献１】国際公開第ＷＯ２００３／０４３２７６号パンフレット
【非特許文献１】3GPP TR 23.882 V1.9.0 (2007-03)，“3GPP System Architecture Evolution：Report on Technical Options and Conclusions”：Sec7.2
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の目的の一つは、ユーザ端末がコンテンツアクセスを効率良く行なえるようにすることにある。【０００６】
また、本発明の他の目的の一つは、ユーザ端末による効率の良いコンテンツアクセスを可能とする接続（通信路）を簡易に識別して、その接続を提供できるようにすることにある。【０００７】
なお、前記目的に限らず、後述する発明を実施するための最良の形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の一つとして位置付けることができる。
【課題を解決するための手段】
【０００８】
前記目的を達成するために、本明細書では、以下に示す「パケット通信システム及びパケット通信方法並びにノード及びユーザ端末」を開示する。【０００９】
（１）即ち、ここに開示するパケット通信システムは、ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおいて、前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送する手段と、前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信する手段と、前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する手段と、その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する手段と、をそなえる。【００１０】
（２）また、ここに開示するパケット通信システムにおけるパケット通信方法は、ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるパケット通信方法であって、前記ノードは、前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送するとともに、前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信し、前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較し、その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定し、前記ユーザ端末は、前記割り当てられた第２のアドレス解決結果を用いて前記通信路にて前記第２のコンテンツサーバにアクセスする。【００１１】
（３）ここで、前記ノードは、前記比較結果が一致する場合、前記第１のアドレス解決結果を前記ユーザ端末に割り当て、前記ユーザ端末は、前記割り当てられた第１のアドレス解決結果を用いて前記第１のコンテンツサーバにアクセスする、こととしてもよい。【００１２】
（４）また、前記ノードは、前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで、前記割り当てを実施する、こととしてもよい。【００１３】
（５）さらに、前記ユーザ端末は、前記通信路設定要求に含まれる前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、こととしてもよい。【００１４】
（６）また、前記ユーザ端末は、前記通信路を経由した通信が終了すると、前記通信路の解放要求を前記ノード宛に送信し、前記ノードは、前記解放要求を受信すると、前記通信路の設定を解放する、こととしてもよい。【００１５】
（７）さらに、前記ノードは、前記ユーザ端末が加入するホームパケットデータ網のゲートウェイノードであってもよい。【００１６】
（８）また、前記ノードは、前記ユーザ端末が加入するホームパケットデータ網以外のパケットデータ網であって前記ホームパケットデータ網と接続された網のゲートウェイノードであってもよい。【００１７】
（９）さらに、ここに開示するパケット通信システムにおけるノードは、ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるノードであって、前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを受信する受信手段と、前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成する生成手段と、前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第２のパケットデータを第２のアドレス解決サーバ宛に送信する送信手段と、前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する比較手段と、その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する通信路設定手段と、をそなえる。【００１８】
（１０）ここで、前記通信路設定手段は、前記比較結果が一致する場合、前記第１のアドレス解決結果を前記ユーザ端末に割り当てる、こととしてもよい。【００１９】
（１１）また、前記通信路設定手段は、前記割り当てを、前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで実施する、こととしてもよい。【００２０】
（１２）さらに、前記通信路設定手段は、前記通信路を経由した通信の終了により前記ユーザ端末が送信した前記通信路の解放要求を受信すると、前記通信路の設定を解放する、こととしてもよい。【００２１】
（１３）また、前記ノードは、前記ユーザ端末が加入するホームパケットデータ網のゲートウェイノードであってもよい。【００２２】
（１４）さらに、前記ノードは、前記ユーザ端末が加入するホームパケットデータ網以外のパケットデータ網であって前記ホームパケットデータ網と接続された網のゲートウェイノードであってもよい。【００２３】
（１５）また、ここに開示するパケット通信システムにおけるユーザ端末は、ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおける前記ユーザ端末であって、第１のコンテンツサーバにアクセスするために第１のパケットデータを送信する送信手段と、前記第１のパケットデータを受信した前記パケット通信システムのノードが、前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信したことにより、前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから前記ノードに返信された第１及び第２のアドレス解決結果が異なる場合に、前記ノードから送信された前記第２のアドレス解決結果を受信する受信手段と、前記第２のアドレス解決結果を用いて、前記ノードにより前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間に設定された通信路にて前記第２のコンテンツサーバに対するアクセスを行なう通信制御手段と、をそなえる。【００２４】
（１６）ここで、前記通信制御手段は、前記第２のアドレス解決結果が、前記ノードから受信した、前記通信路の設定手順の開始を要求する通信路設定要求に含まれている場合に、前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、こととしてもよい。【００２５】
（１７）また、前記通信制御手段は、前記通信路を経由した通信が終了すると、前記通信路の解放要求を前記ノード宛に送信する、こととしてもよい。【００２６】
（１８）さらに、前記通信制御手段は、前記解放要求に対する応答を受信することにより、前記通信路のために確保した通信リソースを解放する、こととしてもよい。
【発明の効果】
【００２７】
本発明によれば、ユーザ端末がコンテンツアクセスを効率良く行なうことが可能となる。
また、付加的あるいは代替的に、ユーザ端末による効率の良いコンテンツアクセスを可能とする接続（通信路）を簡易に識別して、その接続を提供することも可能である。
【図面の簡単な説明】
【００２８】
【図１】ＣＤＮ（コンテンツ配信網）サービスを説明する模式図である。
【図２】ローカルブレークアウトを説明すべく移動通信システムの構成を模式的に示す図である。
【図３】本発明の一実施形態に係る適用システム構成例を示す図である。
【図４】本発明の一実施形態に係る他の適用システム構成例を示す図である。
【図５】本発明の一実施形態に係る他の適用システム構成例を示す図である。
【図６】一実施形態に係るシステム動作例を説明するシーケンス図である。
【図７】一実施形態に係るシステム動作例を説明するシーケンス図である。
【図８】一実施形態に係るシステム動作例を説明するシーケンス図である。
【図９】ＤＮＳ要求パケットフォーマットの一例を示す図である。
【図１０】ＤＮＳ応答パケットフォーマットの一例を示す図である。
【図１１】一実施形態に係るコア網ノードの構成例を示すブロック図である。
【図１２】図１１に示すコア網ノードのアップリンク（ＵＬ）動作例を説明するフローチャートである。
【図１３】図１１に示すコア網ノードのダウンリンク（ＤＬ）動作例を説明するフローチャートである。
【図１４】図１１に示すコア網ノードのダウンリンク（ＤＬ）動作例を説明するフローチャートである。
【図１５】図１１に示すコア網ノードのダウンリンク（ＤＬ）動作例を説明するフローチャートである。
【図１６】図１１に示すコア網ノードのダウンリンク（ＤＬ）動作例を説明するフローチャートである。
【図１７】図１１に示すコア網ノードのダウンリンク（ＤＬ）動作例を説明するフローチャートである。
【図１８】図１１に示すＵＥの構成例を示すブロック図である。
【図１９】図１８に示すＵＥの動作例を説明するフローチャートである。
【図２０】図１８に示すＵＥの動作例を説明するフローチャートである。
【図２１】図１８に示すＵＥの動作例を説明するフローチャートである。
【符号の説明】
【００２９】
１０  移動局（ＵＥ：User Equipment）
１１  ネットワークインタフェース
１２  パケット処理エンジン
１３  プロセッサ
１４  ベアラ管理部
１５  ＰＤＮ／ＩＰアドレス管理部
１７  代替通信路設定管理部
１８  バス
２０  コア網ノード（ｖＡＧＷ）
２０Ａ，２０Ｂ  ＤＮＳ要求
２０Ａ′，２０Ｂ′  ＤＮＳ応答
２１  ネットワークインタフェース
２２  パケット処理エンジン
２３  プロセッサ
２４  ベアラ管理部
２５  ＰＤＮ／ＩＰアドレス／ＵＥ管理部
２６  制御ポリシ管理部
２７  代替通信路設定管理部
２８  バス
３０  コア網ノード（ｈＡＧＷ）
４０，４０−０，４０−１  ＤＮＳサーバ
１００  ホーム網（home NW）
２００  移動先網（visited NW）
３００  パケットデータ網（ＰＤＮ）
【発明を実施するための最良の形態】
【００３０】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。即ち、本発明は、その趣旨を逸脱しない範囲で種々変形（各実施例を組み合わせる等）して実施することができる。【００３１】
〔１〕概要
次世代モバイル通信システムは、広帯域化が進み、移動網経由でインターネット接続するケースが増えることが予想される。インターネットでは、コンテンツの高速配信のため、ＵＲＬ（Uniform Resource Locator）からユーザに近いコンテンツサーバのＩＰ（Internet Protocol）アドレス解決を行なうＤＮＳ（Domain Name System）リダイレクションを利用したＣＤＮ（コンテンツ配信網）サービスが知られている。【００３２】
例えば図１に示すように、
（１）ＤＮＳリダイレクションを利用したＣＤＮでは、クライアント（ユーザ）端末がアクセスを希望するコンテンツのオリジナルを保有するサイト（ＵＲＬ）（オリジナルコンテンツサーバ）にアクセスしようと、そのＩＰアドレスを知るために該サイトにＤＮＳ要求を送信すると、
（２）ＣＤＮ内のリダイレクション機構により、ＤＮＳ要求パケットの送信元アドレス等からクライアント端末の位置を識別し、その位置に応じ、よりユーザに近く高速配信が可能なコンテンツのコピーを有するサイト（リモートコピーコンテンツサーバ）を求め、そのサイトのＩＰアドレスをＤＮＳ応答としてクライアント端末に返し、
（３）クライアント端末は、そのＩＰアドレスを基に前記サイトとの接続を確立し、
（４）前記サイトからコンテンツをダウンロードする。【００３３】
次世代モバイル通信システムでも、ＣＤＮを有効に利用することが期待される。３ＧＰＰの次世代モバイル通信システム（例えば、前記の非特許文献１参照）では、図２に例示するように、ユーザ装置（ＵＥ：User Equipment）である移動局が、移動（訪問）先網（Visited NW）から、ホーム網（Home NW）を経由せずに、直接、外部のパケット網（ＰＤＮ：Packet Data Network）と通信可能とする「ローカルブレークアウト」方式が検討されている。【００３４】
このローカルブレークアウトによれば、ＵＥは、ホーム網を経由せずに外部のＰＤＮと直接の通信が可能となるから、通信遅延を低減することが可能となる。なお、ホーム網は、ユーザ（ＵＥ）が加入契約した通信事業者（キャリアやプロバイダ等）が運営、管理するコア網を意味し、移動先網は、それとは異なる事業者が運営、管理するコア網を意味する。【００３５】
ただし、ユーザ（ＵＥ）は、ローカルブレークアウトの利用を望まない場合もある。
なぜなら、当該サービスを利用する場合には、加入契約した通信事業者の網（ホーム網）を経由した通信（Home routed traffic）で利用する通信リソース（ＩＰアドレスや、通信路、帯域等）に加えて、別途、移動先網でのローカルブレークアウト用の通信リソースを利用（取得）する必要があるから、その分の料金が追加的に発生するからである。【００３６】
また、ローカルブレークアウトを実施しても接続先のＰＤＮにおいてＣＤＮが利用できない場合、例えば、オリジナルのコンテンツのコピーを保有するリモートサーバがそのＰＤＮで利用できない場合等には、ＣＤＮによるダウンロード経路の最適化が得られず、ホーム網経由の通信と比べて通信速度（コンテンツダウンロード速度）に大きな向上は見込めず、費用対効果が悪いと考えられるためでもある。【００３７】
さらに、網側にとっても、そのようなローカルブレークアウト用の通信リソースの確保はできるだけ削減したいと予想される。なぜなら、今後、ＱｏＳ（Quality of Service）通信の要望が本格化する中、通信リソース（ＱｏＳに応じたベアラ本数等）は、より貴重になると予想されるからである。なお、ベアラとは、通信相手、ＱｏＳ等が定義された論理的な通信路（データ転送経路）を意味する。【００３８】
したがって、ユーザ（ＵＥ）がホーム網以外の移動先網に位置（在圏）する場合、選択的、一時的に、ローカルブレークアウトによる通信を可能とすることが望ましい。例えば、ローカルブレークアウトは、ＵＥの移動先の在圏網で提供するローカルブレークアウトで接続可能なＰＤＮにつながるサイトがＣＤＮに対応している場合に実施するのが望ましい。【００３９】
このようなローカルブレークアウトを実現する手法の一つとして、例えば、ＵＥの移動先在圏網（visited NW）に、ＣＤＮのリダイレクション機構を設けて、ホーム網経由の通信におけるＤＮＳ要求を監視し、ＣＤＮの対象サイトへの要求であった場合、ＵＥの移動先在圏網に近いサイト（リモートコピーコンテンツサーバ）を求め（アドレス解決し）、ＵＥにそのサイトへの接続（ローカルブレークアウト）を促す手法が考えられる。【００４０】
しかし、この手法では、複数存在するＣＤＮ業者が個々に提供する多数のオリジナルサイトに対応する規模のリダイレクション機構を、ＵＥの移動先在圏網となり得る網のすべてに配備することになりかねないから、設備コストが大きい。【００４１】
そこで、以下に説明する実施形態では、移動先在圏網にＣＤＮ用の特別な機器（リダイレクション機構）を配備することなく、簡易な通信制御で、ＵＥの移動先在圏網でのローカルブレークアウトを可能とする。【００４２】
〔２〕適用システム例
図３及び図４は、３ＧＰＰのモバイル通信システムの構成例を示す図である。
図３は、ＵＥ（＃ａ）が、加入するホーム（コア）網（Home NW）の事業者とは異なる事業者のコア網（Visited NW）に移動（在圏）した状態を表している。【００４３】
コア網ノード（ＧＷ）は、ホーム網のエンティティであり、例えば、ＵＥとの契約情報に基づき、外部パケット網（ＰＤＮ）＃ａ，＃ｂと通信する際のゲートウェイノードとして機能し、当該ＰＤＮ＃ａ，＃ｂとの通信に必要な端末ＩＰアドレスの割り当て等を管理する。このコア網ノード（ＧＷ）は、既存３ＧＰＰシステムのＧＧＳＮ（Gateway GPRS（General Packet Radio Service）Support Node）、あるいは次世代システムのＰＤＮ−ＧＷ（Packet Data Network - Gateway）に相当する。【００４４】
在圏コア網ノードは、ＵＥの移動先網（visited NW）のエンティティであり、既存３ＧＰＰシステムのＳＧＳＮ（Serving GPRS Support Node）とＧＧＳＮとを統合したノード、あるいは、次世代システムのＳ−ＧＷ（Serving-Gateway）とＰＤＮ−ＧＷとを統合したエンティティ（ノード）に相当する。【００４５】
ＳＧＳＮ又はＳ−ＧＷは、ＵＥの移動先への通信路を提供するノードであり、ホーム網のＧＧＳＮ又はＰＤＮ−ＧＷとの間の通信路（ベアラ）設定、無線アクセス網の通信路（無線ベアラ）の設定、および、それを用いたパケットデータ転送等を行なう。【００４６】
図３に示す例では、ホーム網と同様に、在圏網にあって外部ＰＤＮ＃ｉ，＃ｊへの接続を設定可能なＧＧＳＮ（あるいは、ＰＤＮ−ＧＷ）が、それぞれ、在圏網のＳＧＳＮ（あるいは、Ｓ−ＧＷ）と統合されている構成を表している。【００４７】
そして、図３に示す例では、ＵＥは、通常、在圏コア網ノード（のＳＧＳＮ／Ｓ−ＧＷ機能部）とホーム網のコア網ノードとを経由して、外部ＰＤＮ＃ａ，＃ｂと通信を行なうが、在圏コア網ノード（のＧＧＳＮ／ＰＤＮ−ＧＷ機能部）に接続する外部ＰＤＮ＃ｉ，＃ｊに、ＵＥの利用したいコンテンツ（のコピー）がＣＤＮ機構（アーキテクチャ）で配備されていた場合に、ＵＥが、ホーム網のコア網ノードを経由せずに、当該ＰＤＮ＃ｉ，＃ｊのコンテンツ（サーバ）にアクセス（ローカルブレークアウト）することを可能とする。【００４８】
一方、図４は、ＵＥがホーム網に在圏する場合を示す。
ホーム網のコア網ノード（ＧＷ）は、ＵＥが通信する際に経由するデフォルトのゲートウェイノード（ＧＧＳＮ／ＰＤＮ−ＧＷ）であり、ＵＥがホーム網内を移動し、アクセスした地域の無線アクセス網を収容する別のコア網ノード（ＵＥアクセスノード）が、図４の場合と同様に、外部ＰＤＮ＃ｉ，＃ｊへの通信路を設定可能なノード（ＧＧＳＮとＳＧＳＮとの統合ノード、あるいは、ＰＤＮ−ＧＷとＳ−ＧＷとの統合ノード）であった場合を示している。【００４９】
この図４に示す例では、ＵＥアクセスノードからの接続設定が可能な外部ＰＤＮ＃ｉ，＃ｊに、ＵＥの利用したいコンテンツ（のコピー）が、ＣＤＮ機構で配備されていた場合に、ＵＥが、移動前の通信で経由していたデフォルトのコア網ノード（ＧＷ）を経由せずに、当該外部ＰＤＮ＃ｉ，＃ｊのコンテンツ（サーバ）にアクセスすることを可能とする。【００５０】
図５は、３ＧＰＰのモバイル通信システム以外の網構成例を示す。
ＵＥを収容するアクセス網が無線技術によらないアクセス網であっても、コア網ノードの機能配備（ＧＷとＵＥアクセスノードとの関係）、外部パケット網の収容構成が図４や図５の構成と同様ならば、本例のローカルブレークアウトの適用対象システムとなる。【００５１】
即ち、ＵＥアクセスノードから接続設定が可能な外部ＰＤＮ＃ｉ，＃ｊに、ＵＥの利用したいコンテンツ（のコピー）が、ＣＤＮ機構で配備されていた場合に、ＵＥが、移動前の通信で経由していたコア網ノード（ＧＷ）を経由せずに、当該外部ＰＤＮ＃ｉ，＃ｊのコンテンツ（サーバ）にアクセスすることを可能とする。【００５２】
〔３〕全体動作例
次に、本例のローカルブレークアウトを実現するシステム動作例について、図６〜図１０を用いて説明する。なお、図６及び図７は、適用対象システムの一例として、図３に示した３ＧＰＰのモバイル通信システム構成例を前提とする。【００５３】
図６は、ＵＥ１０が通常はホーム網（Home NW）１００経由で通信を行なう契約をホーム網１００の通信事業者と結んでおり、当該ＵＥ１０が加入するホーム網１００を運営、管理する通信事業者とは異なる事業者の網（visited NW）２００に移動（在圏）した場合を示す。【００５４】
この図６には、ホーム網１００のコア網ノード（access gateway：ＡＧＷ）としてｈＡＧＷ（home AGW）３０が存在し、移動先網２００のコア網ノード（ＡＧＷ）としてｖＡＧＷ（visited AGW）２０が存在する場合を示している。【００５５】
また、複数のＰＤＮ３００（＃０，＃１，・・・）が存在し、例えば、ＰＤＮ＃０は、ホーム網３０と接続されてｈＡＧＷ３０から通信路（ベアラ）設定が可能なＰＤＮであり、ＰＤＮ＃１は、移動先網２００と接続されてｖＡＧＷ２０から通信路（ベアラ）設定が可能なＰＤＮである。【００５６】
さらに、ＰＤＮ＃０，＃１には、ＤＮＳサーバ４０が配備されている。ＤＮＳサーバ４０は、ユーザ（ＵＥ１０）の位置（例えば、ＤＮＳ要求の送信元アドレス）に応じてユーザがアクセスするのに適切なコンテンツサーバ（例えば、ユーザの位置により近い場所に存在するサーバ）のＩＰアドレスを求め（アドレス解決をし）、その結果をＤＮＳ応答によりＵＥ１０に返すアドレス解決機能を具備する。【００５７】
コンテンツサーバ群には、オリジナルコンテンツを保有するオリジナルコンテンツサーバと、前記オリジナルコンテンツのコピーを保有する（リモート）コピーコンテンツサーバとが含まれ、地域的に分散して配備される。例えば、コピーコンテンツサーバは、オリジナルコンテンツサーバが属するＰＤＮと同じＰＤＮに属する場合もあるし、異なるＰＤＮに属する場合もある。また、コンテンツサーバが保有するコンテンツ（つまり、ＵＥ１０に提供しうるコンテンツ）には、文書データ、画像データ、動画データ、音声データ等の各種データが含まれる。【００５８】
ＤＮＳサーバ４０は、１又は複数のＰＤＮでのアドレス情報（コンテンツサーバのアドレス情報が含まれる）を保有し、そのアドレス情報を基に前記アドレス解決を行なう。ただし、ＤＮＳサーバ４０は、ＣＤＮ機構を構築するすべてのコンテンツサーバのアドレス情報を保有するわけではなく、異なる通信事業者のコア網（ＡＧＷ）に収容されたＰＤＮに属するコンテンツサーバのアドレス情報は保有しないのが一般的である。【００５９】
図６に示す例では、ホーム網１００（ｈＡＧＷ３０）に収容されたＰＤＮ＃０でのアドレス情報をＤＮＳサーバ４０−０が保有、管理し、移動先網２００（ｖＡＧＷ２０）に収容されたＰＤＮ＃１でのアドレス情報をＤＮＳサーバ４０−１が保有、管理するものとして表現している。【００６０】
なお、ＵＥ１０には、携帯電話やＰＤＡ、ノート型ＰＣ等の通信装置が含まれる。また、ＵＥ１０は、有線インタフェースにより、ｖＡＧＷ２０やｈＡＧＷ３０が収容する無線あるいは有線アクセス網に接続（アタッチ）する通信装置であってもよい。【００６１】
また、ＵＥ１０は、コア網ノードであるｖＡＧＷ２０やｈＡＧＷ３０にダイレクトに接続するのではなく、コア網ノードが収容する無線あるいは有線アクセス網を介して通信するが、図６の例では、簡略化して、ＵＥ１０とｖＡＧＷ２０との間に介在するアクセス網の図示を省略している。以降の説明においても、ＵＥ１０がｖＡＧＷ２０やｈＡＧＷ３０等のコア網ノードにダイレクトに接続するかのような表現を用いることがあるが、便宜上のものであり、無線あるいは有線アクセス網を介した接続を意味する。【００６２】
さて、３ＧＰＰで検討中の次世代システムでは、ＵＥ１０が無線アクセス網にアタッチした場合、当該ＵＥ１０には、デフォルトＩＰアクセスと呼ばれるＩＰ接続が提供される。例えば、ＵＥ１０が、移動先網２００のｖＡＧＷ２０が収容する無線アクセス網にアタッチすると、ＵＥ１０、ｖＡＧＷ２０及びｈＡＧＷ３０を経由する、デフォルトのＩＰアドレス（ホームアドレス）でのアクセス通信路（デフォルト通信路の一例としてのベアラ）が設定、確立され、契約情報等で決まっているデフォルトのＰＤＮ（例えば、ＰＤＮ＃０）との通信が可能となる。【００６３】
なお、デフォルト通信路（ベアラ）の確立に先立ち、ホーム網１００（ｈＡＧＷ３０）から移動先網２００（ｖＡＧＷ２０）へＵＥ１０にサービスを提供するために必要な加入者情報（例えば、ＵＥ１０が利用可能なサービス種別等）が伝達される。これにより、ｖＡＧＷ２０は、ＵＥ１０及びｈＡＧＷ３０との間のベアラ設定が可能となる。【００６４】
さて、図６中に示すように、ＵＥ１０は、何らかのコンテンツ（サイト（ＵＲＬ））にアクセスする場合、そのコンテンツを保有するコンテンツサーバのアドレスを知る（解決する）ために、デフォルトＰＤＮ＃０から到達可能なＤＮＳサーバ４０（４０−０）宛に、前記デフォルト通信路経由で、ＤＮＳ要求（第１のパケットデータ）２０Ａを送信する（ステップＳ１）。【００６５】
ここで、ＤＮＳサーバ４０のアドレスは、ホーム網１００が提供するサービスによって前記デフォルト通信路の確立過程でｈＡＧＷ３０から与えられたり、ＵＥ１０がデフォルトＰＤＮ＃０との通信で取得したり、あるいは、予めＵＥ１０に設定、保持されている。【００６６】
ＤＮＳ要求の宛先アドレスは、こうしたＤＮＳサーバ４０のアドレスであり、送信元アドレスは、ＵＥ１０がｈＡＧＷ３０経由で通信するためにｈＡＧＷ３０から割り当てられたデフォルトのＩＰアドレス（ホームアドレス）である。送信元アドレスがこのホームアドレスであるパケットが移動先網２００のｖＡＧＷ２０で受信されると、当該パケットはｈＡＧＷ３０へ転送されることになる。【００６７】
ＵＥ１０は、前記ＤＮＳ要求２０Ａに対して、デフォルトＰＤＮ＃０（ＤＮＳサーバ）から前記デフォルト通信路にて返信されてきたＤＮＳ応答（第１のアドレス解決結果）２０Ａ′で解決されたコンテンツ（サーバ）のＩＰアドレスを用いて、前記デフォルト通信路にて当該コンテンツへのアクセス（コンテンツダウンロード）を行なうことができる。【００６８】
ここで、前記コンテンツのコピーがｖＡＧＷ２０からの通信路設定（以下、接続設定ともいう）が可能なＰＤＮ（例えば、ＰＤＮ＃１）のサイト（リモートコピーコンテンツサーバ）に存在する場合、ＵＥ１０は、ｈＡＧＷ３０を経由する前記デフォルト通信路ではなく、ｖＡＧＷ２０経由の通信路（代替通信路）にて前記リモートコピーサーバにアクセスする（ローカルブレークアウトする）方がルート最適化の観点からより好ましい。【００６９】
そこで、本例のｖＡＧＷ２０は、ＵＥ１０からＰＤＮへの方向であるアップリンク（ＵＬ）及びその逆方向であるダウンリンク（ＤＬ）のＤＮＳトラフィック（ＤＮＳパケットフロー）を監視する。【００７０】
監視対象のＵＬのＤＮＳ要求２０Ａを検出したら、ｖＡＧＷ２０は、そのＤＮＳ要求２０Ａを宛先アドレス（ＤＮＳサーバアドレス）に従ってＤＮＳサーバ（第１のアドレス解決サーバ）４０−０宛に転送する（ステップＳ２）。【００７１】
その際、ｖＡＧＷ２０は、受信した前記ＤＮＳ要求２０Ａをコピーし、例えば図９に示すように、自ノード（ｖＡＧＷ）２０のＩＰアドレスを送信元アドレス（source IP address）、自ノード２０から通信路設定可能ないずれかのＰＤＮ（＃１）でのアドレス解決を行なうＤＮＳサーバ（第２のアドレス解決サーバ）４０−１のＩＰアドレスを宛先アドレス（destination IP address）とするＤＮＳ要求（第２のパケットデータ）２０Ｂを生成して、転送する（ステップＳ２ａ，Ｓ３ａ）。なお、図９はＤＮＳ要求パケットのフォーマット例を示し、斜線部で示す部分の情報要素がｖＡＧＷ２０での書き換え対象であることを示している。【００７２】
つまり、ｖＡＧＷ２０は、ホーム網１００のｈＡＧＷ３０からＵＥ１０との間の通信路設定が可能な外部のＰＤＮ＃０経由でアクセス可能なサイト（オリジナルコンテンツサーバ）と同じコンテンツ（コピー）を保有する別のコンテンツサーバ（リモートコピーコンテンツサーバ）に、自ノード２０からＵＥ１０との間の通信路設定が可能な外部のＰＤＮ＃１経由でアクセスできるか否かを、ＵＥ１０の代理で試行する。なお、監視対象のＵＥ１０のＤＮＳトラフィックの情報は、例えば、前記デフォルト通信路の設定時に加入者情報として取得することができる。【００７３】
そして、オリジナルのＤＮＳ要求２０Ａは、その宛先アドレスに従ってｈＡＧＷ３０を経由するデフォルト通信路を介して第１のＤＮＳサーバ４０−０へ転送され（ステップＳ３）、コピー生成されたＤＮＳ要求２０Ｂは、その宛先アドレスに従って第２のＤＮＳサーバ４０−１へ転送される。【００７４】
ＰＤＮ＃０でのアドレス解決を行なうＤＮＳサーバ４０−０、及び、移動先網２００に収容されたＰＤＮ＃１でのアドレス解決を行なうＤＮＳサーバ４０−１は、それぞれ、受信したＤＮＳ要求２０Ａ，２０Ｂの送信元アドレスに基づいてアクセス要求されているサイト（コンテンツサーバ）のアドレス解決を行ない、解決したＩＰアドレス（以下、解決アドレスともいう）を含むＤＮＳ応答（パケット）２０Ａ′，２０Ｂ′（第１及び第２のアドレス解決結果）をＤＮＳ要求２０Ａ，２０Ｂの送信元へ返信する（ステップＳ４）。【００７５】
ここで、オリジナルのＤＮＳ要求２０Ａの送信元アドレスはＵＥ１０のホームアドレスであるから、そのＤＮＳ応答２０Ａ′はホーム網１００のｈＡＧＷ３０を経由して移動先網２００のｖＡＧＷ２０へ転送される（ステップＳ４，Ｓ５）。一方、ｖＡＧＷ２０でコピーされたＤＮＳ要求２０Ｂの送信元アドレスはｖＡＧＷ２０のＩＰアドレスであるから、そのＤＮＳ応答２０Ｂ′はｖＡＧＷ２０へ転送される（ステップＳ４ａ）。【００７６】
つまり、両ＤＮＳ応答２０Ａ′及び２０Ｂ′は、ｖＡＧＷ２０にて受信される。ｖＡＧＷ２０は、ＤＬの監視対象のＤＮＳトラフィックの監視中に、両ＤＮＳ応答２０Ａ′，２０Ｂ′の受信を検出すると、各ＤＮＳ応答２０Ａ′，２０Ｂ′を抽出し、それぞれの解決アドレスを比較する。【００７７】
その結果、不一致の場合は、ｖＡＧＷ２０が代理発信したＤＳＮ要求２０Ｂに対するＤＮＳ応答２０Ｂ′に含まれる解決アドレスが示すサイト、つまりは、移動先網２００のｖＡＧＷ２０から通信路設定が可能な外部網（ＰＤＮ＃１）に、オリジナルコンテンツのコピーを保有するサイト（リモートコピーコンテンツサーバ）がＣＤＮ機構により配備されている（ローカルブレークアウトを実施できる）、とｖＡＧＷ２０は判断することができる。【００７８】
なお、オリジナルのＤＮＳ要求２０Ａに対するＤＮＳ応答２０Ａ′が何らかの理由で一定時間内にｖＡＧＷ２０で受信されなかった場合、ｖＡＧＷ２０は、例えば、受信したＤＮＳ応答２０Ｂ′に含まれる解決アドレスが自ノード２０から通信路設定可能なＰＤＮ＃１内のＩＰアドレスであることを検出することで、ＰＤＮ＃１との間の通信路（ベアラ）が利用可能（ローカルブレークアウトが実施可能）であると判断することも可能である。【００７９】
また、ＤＮＳサーバ４０−１が、ｖＡＧＷ２０から通信路設定が可能な外部網であるがＰＤＮ＃１とは異なる他のＰＤＮのＩＰアドレスをも管理している場合には、解決アドレスがＤＮＳ要求２０Ａの宛先であるＤＮＳサーバ４０−１の属するＰＤＮ＃１とは異なる他のＰＤＮ内のＩＰアドレスである場合もある。【００８０】
ｖＡＧＷ２０は、上述のごとくｖＡＧＷ２０から通信路設定が可能なＰＤＮ＃１の存在（ローカルブレークアウトが可能なこと）を認識すると、ローカルブレークアウトを起動する（ステップＳ６）。つまり、ＤＮＳ応答２０Ａ′及び２０Ｂ′の解決アドレスが異なることを検出することで、ＵＥ１０が訪問先網２００でもＣＤＮ機構が利用可能と推定し、ローカルブレークアウトのネットワーク（ｖＡＧＷ２０）側からの起動（設定）のトリガとする。【００８１】
なお、前記両解決アドレスが一致していた場合や、代理発信したＤＮＳ要求２０Ｂに対するＤＮＳ応答２０Ｂ′が受信されない場合は、ｖＡＧＷ２０は、ローカルブレークアウトを実施できないと判断して、ＵＥ１０に対し、オリジナルのＤＮＳ要求２０Ａに対するＤＮＳ応答２０Ｂを返信する。【００８２】
ｖＡＧＷ２０は、ローカルブレークアウトの起動トリガを検知したら、ローカルブレークアウトの設定処理をＵＥ１０との間で開始する。この設定処理は、ネットワーク側（ｖＡＧＷ）が起動する手順（NW-initiated手順）で行なってもよいし、ＵＥ１０が起動する手順（UE-initiated手順）で行なってもよい。【００８３】
NW-initiated手順による場合は、ｖＡＧＷ２０は、前記ＤＮＳ応答２０Ｂ′で解決されたＩＰアドレス（ＰＤＮ＃１への接続用のＩＰアドレス）のＵＥ１０への割り当てを準備し、ネットワーク側起動（NW-initiated）のベアラセットアップ手順でＵＥ１０に対するローカルブレークアウト用の通信路（ベアラ）のセットアップを実施する。【００８４】
即ち、ｖＡＧＷ２０は、ＵＥ１０宛のベアラ設定要求を生成してＵＥ１０へ送信する（図６のステップＳ７）。その際、ｖＡＧＷ２０は、好ましくは、当該ベアラ設定要求に、前記ＤＮＳ応答２０Ｂ′で解決されたＩＰアドレスを情報要素（通信フローの識別情報）として含める。【００８５】
このようにすれば、３ＧＰＰで仕様化が進められている、移動通信網側の新たな端末ＩＰアドレスの確保を含む通信用リソースの事前予約を伴うNW-initiated手順を利用して、ｖＡＧＷ２０からＵＥ１０に対するベアラ設定要求と、新ＩＰアドレス（ＰＤＮ＃１への接続用のＩＰアドレス）の割り当てとを併せて行なうことができるから、UE-initiated手順の場合に比して、ベアラ設定の遅延を削減することが可能となる。【００８６】
ＵＥ１０は、前記ベアラ設定要求を受信すると、NW-initiated手順のローカルブレークアウト（NW-initiated Local Breakout）であることを認識し、ローカルブレークアウトをアクティブな所定のアプリケーションに適用し、ベアラ設定応答をｖＡＧＷ２０宛に返信する（ステップＳ８）。【００８７】
なお、ＵＥ１０は、前記ベアラ設定要求に含まれる、ＰＤＮ＃１（リモートコピーコンテンツサーバ）への接続用のＩＰアドレスと、それまでにＵＥ１０がｈＡＧＷ３０経由のデフォルト通信路の通信に用いていたＩＰアドレスとが異なることを検出することで、ｖＡＧＷ２０経由のＰＤＮ＃１への通信路（ローカルブレークアウトサービス）が利用可能であること（その通信路の設定手順の開始）を認識することが可能である。したがって、既存のベアラ制御メッセージの種別を識別する情報の追加や改変等を不要とすることができる。【００８８】
前記ベアラ設定応答を受信したｖＡＧＷ２０は、ＵＥ１０が送信したＤＮＳ要求２０Ａに対するＤＮＳ応答２０Ａ′を、送信元アドレスをＤＮＳサーバ４０−０のアドレスとし、宛先アドレスをＵＥ１０のホームアドレスとして（例えば図１０参照）、ＵＥ１０へ送信する（ステップＳ９）。なお、図１０の斜線部で示すフィールドは、ｖＡＧＷ２０での書き換え対象のフィールドであることを示している。【００８９】
一方、UE-initiated手順による場合は、例えば、ｖＡＧＷ２０が、ＵＥ１０に対し、ＰＤＮ＃１への有効な通信路が存在する旨をＤＮＳ応答とは個別に通知するか、あるいは、ＤＮＳ応答にその通知情報を含めて通知する。前記通知情報を含める場合には、図１０に示すＤＳＮデータ部（RDATA部）に設定することができる。【００９０】
ＵＥ１０は、前記通知（情報）を受信して、ＰＤＮ＃１への有効な通信路が存在することを認識すると、ＰＤＮ＃１への通信路（ベアラ）のセットアップ手順を開始する。例えば図８に示すように、ＵＥ１０は、ローカルブレークアウトサービスの開始をｖＡＧＷ２０に要求し（ステップＳ７ａ）、ｖＡＧＷ２０は、この開始要求を受信することにより、ローカルブレークアウト用のベアラ（通信路）の設定シーケンス（ベアラ設定要求の送信、ベアラ設定応答の受信）を実施する（ステップＳ８ａ，Ｓ９ａ）。【００９１】
さて、上述のごとくNW-initiated手順あるいはUE-initiated手順によりローカルブレークアウト用のベアラセットアップが完了すると、ＵＥ１０は、確立されたベアラにてリモートコピーコンテンツサーバとの通信を行なう（ステップＳ１０）。【００９２】
その後、当該通信（セッション）が終了した場合は、ローカルブレークアウト用のベアラの解放処理を実施する。このベアラ解放処理は、必須ではないが、通信リソースの効率的な利用の観点から実施するのが好ましい。その実施タイミングについては自由であるが、例えば、NW-initiated手順及びUE-initiated手順のいずれを適用することも可能である。【００９３】
UE-initiated手順による場合、例えば図７に示すように、ローカルブレークアウト通信（セッション）が終了すると（ステップＳ１１）、ＵＥ１０が、ベアラ解放要求をｖＡＧＷ２０宛に送信する（ステップＳ１２）。ｖＡＧＷ２０は、当該ベアラ解放要求を受信すると、ローカルブレークアウト通信（ベアラ）のために確保した通信リソースの解放を行ない、ベアラ解放応答をＵＥ１０に返信する（ステップＳ１３）。ＵＥ１０は、このベアラ解放要求を受信すると、ローカルブレークアウト用のベアラのために確保した通信リソースの解放を行なう。【００９４】
一方、NW-initiated手順による場合は、例えば図８に示すように、ＵＥ１０は、ローカルブレークアウト通信（セッション）が終了すると（ステップＳ１１）、ローカルブレークアウトサービスの停止要求をｖＡＧＷ２０宛に送信し（ステップＳ１２ａ）、ｖＡＧＷ２０は、当該停止要求を受信することにより、ベアラ解放要求をＵＥ１０宛に送信する（ステップＳ１３ａ）。【００９５】
ＵＥ１０は、このベアラ解放要求を受信すると、ローカルブレークアウト通信（ベアラ）のために確保した通信リソースの解放を行ない、ベアラ解放応答をｖＡＧＷ２０に返信する（ステップＳ１４ａ）。ｖＡＧＷ２０は、このベアラ解放応答を受信すると、ローカルブレークアウト通信に確保した通信リソースの解放を行なう。【００９６】
なお、ローカルブレークアウト通信の終了は、ローカルブレークアウト用のベアラのトラフィックをネットワーク側のエンティティ（ｖＡＧＷ２０）で監視することで検出することも可能である。【００９７】
例えば、ｖＡＧＷ２０は、ローカルブレークアウト用のベアラのパケットが、一定時間、流れていない状態（無通信状態）を検出した場合に、ローカルブレークアウト通信が終了したと判断する。その場合、ｖＡＧＷ２０は、ＵＥ１０からの前記停止要求を待たずに、ベアラ解放処理を開始する（前記ステップＳ１３ａのベアラ解放要求をＵＥ１０宛に送信する）ことができる。【００９８】
ただし、その場合、無通信状態が検出されるまでの時間に応じて、無駄なベアラが維持される状況が生じる場合がある。ローカルブレークアウト用のベアラは、特定の通信セッションに特化したテンポラリな通信路といえるので、無駄に通信リソースが確保される状態を極力回避してリソース利用効率の向上を重視するのであれば、UE-initiated手順でローカルブレークアウト用のベアラの解放を実施する方が好ましい。【００９９】
以上のようにして、本例のシステムでは、ＵＥ１０が移動先網２００でアクセスするｖＡＧＷ２０にて、ＵＥ１０から第１のＰＤＮ（＃０）へアクセスするためのＤＮＳ要求２０Ａを検出（捕捉）し、そのＤＮＳ要求２０Ａを基にｖＡＧＷ２０からアクセス可能な第２のＰＤＮ（＃１）に対するＤＮＳ要求２０Ｂを生成して、ＰＤＮ＃０へのＤＮＳ要求２０Ａの送信とともに、第２のＰＤＮ＃１へＤＮＳ要求２０Ｂを送信する。【０１００】
そして、そのＤＮＳ要求２０Ｂに対するアドレス解決結果（ＤＮＳ応答２０Ｂ′）が、ＤＮＳ要求２０Ａに対するアドレス解決結果（ＤＮＳ応答２０Ａ′）と異なる場合に、ｖＡＧＷ２０は、ＤＮＳ応答２０Ｂ′が示す第２のＰＤＮ＃１とＵＥ１０との間に代替の通信路（ベアラ）を設定する処理を実行する。【０１０１】
したがって、ｖＡＧＷ２０にＣＤＮ用の特別な機器（リダイレクション機構）を配備せずに、既存のＡＧＷが有する機能の拡張程度で安価に、ローカルブレークアウトサービスを実現して、アクセス遅延の小さい通信路をＵＥ１０に提供することができる。【０１０２】
ここで、ＤＮＳトラフィックの検出機能は、ＡＧＷの標準装備程度の機能である。パケット情報の解析もＡＧＷのサポートスコープ内であり、前記のパケットコピー、送信元アドレスの変更、および、解決ＩＰアドレスの比較機能は、ＡＧＷ（ｖＡＧＷ２０）のソフトウェアグレードアップレベルで対応可能である。したがって、特別な機器（リダイレクション機構）を設ける場合に比して、安価に実現できる。【０１０３】
以下、上述したローカルブレークアウトを実現するコア網ノード（ｖＡＧＷ）及びＵＥの詳細な一例についてそれぞれ詳述する。【０１０４】
〔４〕コア網ノード
図１１はコア網ノード（ｖＡＧＷ）２０の構成例を示すブロック図である。この図１１に示すコア網ノード２０は、例えば、ネットワークインタフェース２１と、パケット処理エンジン２２と、プロセッサ２３と、ベアラ管理部２４と、ＰＤＮ／ＩＰアドレス／ＵＥ管理部２５と、制御ポリシ管理部２６と、代替通信路設定管理部２７と、をそなえる。これらの構成要素は、通信バス２８により相互に内部通信可能に接続されている。【０１０５】
ここで、ネットワークインタフェース２１は、外部（移動先網２００のエンティティ、および、ホーム網１００のエンティティ）とのデータ（パケット）の送受信（ルーティング）を行なう機能を具備する。【０１０６】
パケット処理エンジン２２は、ベアラを識別し、ベアラ設定に基づくパケットルーティング機能や、自ノード２０宛のデータを識別し、適切なノード内の処理部へ振り分ける機能、ホーム網１００のｈＡＧＷ３０との間でＱｏＳ制御情報や加入者情報等の送受信（終端処理）を行なう機能などを具備する。【０１０７】
また、このパケット処理エンジン２２は、制御ポリシ管理部２６からの制御（設定データ）に従って、監視対象のＤＮＳトラフィック（ＤＮＳ要求／応答）の検出、補足を行なう機能や、代替通信路設定管理部２７で保持、管理するデータ（代替通信路としてのローカルブレークアウト通信用のベアラに関するデータ）に基づいて、ローカルブレークアウト通信のベアラ設定に基づくパケットルーティング機能も具備する。【０１０８】
なお、パケット処理エンジン２２は、例えば、ＤＳＰ（Digital Signal Processor）やＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等の集積回路技術を用いて構成することが可能である。【０１０９】
ベアラ管理部２４は、ベアラ通信に必要な情報を保持、管理するものである。【０１１０】
ＰＤＮ／ＩＰアドレス／ＵＥ管理部２５は、自ノード２０が接続するＰＤＮ、当該ＰＤＮに接続するためのＩＰアドレス、ＵＥ１０に関するサービス契約情報等を管理するとともに、ＰＤＮ毎にＵＥ１０に割り当て可能なＩＰアドレス群（アドレスプール）、ＵＥ１０に割り当てた、あるいは、ＵＥ１０が使用中のＩＰアドレスやＰＤＮ等の、サービス状況に関する情報を保持、管理するものである。【０１１１】
制御ポリシ管理部２６は、前記監視対象のＤＮＳトラフィックの検出、補足の実行可否を、ＵＥ１０の契約情報（加入者情報）に基づいて判断し、実行する場合にパケット処理エンジン２２に対して必要な設定を行なうためのデータ（設定データ）を保持、管理するものである。【０１１２】
代替通信路設定管理部２７は、デフォルト通信路とは別に新たに設定する代替通信路（ローカルブレークアウト用のベアラ）に関する制御データを保持して管理するものである。【０１１３】
プロセッサ２３は、ベアラの設定／解放に必要なベアラ制御メッセージ（ベアラ設定／解放要求等）の生成、終端処理機能や、ベアラ管理部２４、代替通信路設定管理部２７に必要な情報を格納し、これらの管理部２４，２７が保持、管理する情報に基づいて、ベアラ通信（ローカルブレークアウト通信を含む）に必要な設定を、パケット処理エンジン２２に対して行なう機能などを具備する。【０１１４】
さて、上述のごとく構成されたコア網ノード２０において、デフォルト通信路などのベアラが設定される場合、ＵＥ１０との間や他のコア網ノードとの間で、ベアラ制御メッセージ（ベアラ設定要求／応答）が交換される。【０１１５】
ベアラ制御メッセージは、ネットワークインタフェース２１にて受信され、バス２８経由でパケット処理エンジン２２に転送され、パケット処理エンジン２２にて、ベアラ制御メッセージであることが識別され、バス２８経由でプロセッサ２３に転送される。【０１１６】
プロセッサ２３は、受信したベアラ制御メッセージを解析し、ベアラ設定要求であることを識別すると、ベアラを構成するための情報（対向ノードアドレス、ベアラ識別情報等）を当該ベアラ設定要求から抽出し、自ノード２０がベアラのパケットフローを受信するために必要な情報（自ノードアドレス、ベアラ識別情報子等）を決定する。【０１１７】
さらに、プロセッサ２３は、決定した前記情報を基に、ベアラ設定応答を生成するとともに、抽出及び決定した前記情報をベアラ管理部２４にて保持、管理させるとともに、その情報に応じたルーティング設定をパケット処理エンジン２２に対して行なう。生成した前記ベアラ設定応答は、バス２８経由でパケット処理エンジン２２へ転送され、さらにパケット処理エンジン２２からバス２８経由でネットワークインタフェース２１に転送されて、ネットワークインタフェース２１から対向ノード（例えば、ｈＡＧＷ３０）あるいはＵＥ１０宛に送信される。【０１１８】
一方、プロセッサ２３が、前記メッセージ解析により、受信したベアラ制御メッセージがベアラ設定応答であると識別した場合は、そのベアラ設定応答の内容を基に必要に応じて制御パラメータ（ベアラのＱｏＳ情報等）の設定、変更（更新）をベアラ管理部２４、および、パケット処理エンジン２２内の保持（設定）データに反映する。【０１１９】
ここで、ＵＥ１０のアタッチの手順に連動し、コア網ノード２０自身がベアラ設定要求を生成して送信する場合がある。【０１２０】
この場合、アタッチ処理をプロセッサ２３が処理し、アタッチ処理の手順の過程で取得したＵＥ１０のサービス契約情報をＰＤＮ／ＩＰアドレス／ＵＥ管理部２５に格納するとともに、この管理部２５の情報を基にＵＥ１０に割り当てるＩＰアドレスを決定する。あるいは、プロセッサ２３は、ＵＥ１０に別手順で与えられたＩＰアドレスを管理部２５に格納し、その情報を基に、ベアラとＵＥ１０のパケット識別情報（アドレス等）との対応情報（フィルタ情報）等とともにベアラ設定要求を生成する。【０１２１】
このベアラ設定要求も、バス２８経由でパケット処理エンジン２２に転送され、さらにパケット処理エンジン２２からバス２８経由でネットワークインタフェース２１へ転送されて、ネットワークインタフェース２１から対向ノードあるいはＵＥ１０へ送信される。【０１２２】
なお、ベアラ解放要求／応答を示すベアラ制御メッセージも、上記と同様のノード内処理ルートを経由する。ベアラ解放応答を受信した場合は、プロセッサ２３により、該ベアラに関する情報が、パケット処理エンジン２２、ベアラ管理部２４、および、ＰＤＮ／ＩＰアドレス／ＵＥ管理部２５から削除される。【０１２３】
ベアラ設定後に関しては、ＵＬ及びＤＬともに、パケット処理エンジン２２が、ベアラ設定に基づくパケット転送、および、必要なパケット処理（カプセル化）を行ない、所定の通信を成立させる。即ち、ノード２０内では、ネットワークインタフェース２１からパケット処理エンジン２２、パケット処理エンジン２２からネットワークインタフェース２１を経由するルートで通信が行なわれる。【０１２４】
以下、本例のローカルブレークアウトを含む、コア網ノード２０の動作例について、図１２〜図１７を用いて説明する。なお、図１２〜図１７において、処理番号に括弧付きで併記した符号は、コア網ノード２０における前記構成要素を通じてその処理番号での処理が扱われることを表している。【０１２５】
（ＵＬパケット処理）
まず、図１２を用いて、コア網ノード２０でのＵＬのパケット処理について説明する。【０１２６】
図１２に示すように、ノード２０において、ＵＥ１０が送信したＵＬのパケットがネットワークインタフェース２１にて受信されると（処理５０００）、当該受信パケットは、パケット処理エンジン２２に転送される。【０１２７】
パケット処理エンジン２２は、受信パケットが監視対象のＵＥ１０のベアラのパケットか否かをチェックし（処理５０１０）、監視対象パケットであれば（処理５０１０でＹｅｓなら）、さらに、そのパケットがＤＮＳ要求２０Ａであるか否かをチェックする（処理５０２０）。【０１２８】
その結果、監視対象のＤＮＳ要求２０Ａであれば（処理５０２０でＹｅｓなら）、制御ポリシ管理部２６が、ＰＤＮ／ＩＰアドレス／ＵＥ管理部２５と連携して、自ノード２０から通信路（ベアラ）設定が可能なＰＤＮを選出し、受信したＤＮＳ要求２０Ａを基にして（コピーして）、自ノード（ｖＡＧＷ）２０のＩＰアドレスを送信元アドレス、選出した前記ＰＤＮでのアドレス解決を行なうＤＮＳサーバ４０（４０−１）のＩＰアドレスを宛先アドレスとするＤＮＳ要求２０Ｂを生成し、ネットワークインタフェース２１経由で送信する（処理５０３０）。この処理５０３０は、図６におけるステップＳ２ａ，Ｓ３ａの処理に相当する。【０１２９】
そして、制御ポリシ管理部２６は、監視対象のベアラのＤＬのＤＮＳパケットの検出機能をＯＮにし、その情報を保持する（処理５０４０）。オリジナルのＤＮＳ要求２０Ａについては、パケット処理エンジン２２は、デフォルトのベアラ設定に従って、ネットワークインタフェース２１経由で転送する（処理５０５０）。なお、制御ポリシ管理部２６は、前記検出機能のＯＮ状態が所定時間経過したか否かを監視タイマ（図示省略）により監視する。【０１３０】
つまり、ネットワークインタフェース２１は、ＵＥ１０が（第１の）コンテンツサーバにアクセスするために送信したＤＮＳ要求（第１のパケットデータ）２０Ａを受信する受信手段としての機能を具備し、制御ポリシ管理部２６は、前記ＤＮＳ要求２０Ａの送信元（アドレス）を自ノード２０とするＤＮＳ要求（第２のパケットデータ）２０Ｂを生成する生成手段としての機能を具備し、パケット処理エンジン２２及びネットワークインタフェース２１は、ＤＮＳ要求２０ＡをＤＮＳサーバ４０−０へ、ＤＮＳ要求２０ＢをＤＮＳサーバ４０−１へそれぞれ送信する送信手段としての機能を具備する。
また、【０１３１】
その後、パケット処理エンジン２２は、ＵＬの受信パケットに関して、通常の転送（ルーティング）処理を実施する（処理５０６０）。なお、受信したＤＮＳパケットが監視対象のＵＥ１０のベアラのパケットでない場合（処理５０１０でＮｏの場合）や、監視対象パケットではあるがＤＳＮ要求２０Ａではない場合（処理５０２０でＮｏの場合）も、その受信パケットに関して通常のパケット転送処理が実施される（処理５０６０）。【０１３２】
（ＤＬパケット処理）
次に、図１３及び図１４を用いて、コア網ノード２０でのＤＬのパケット処理について説明する。【０１３３】
図１３に示すように、ノード２０において、ＤＬのパケットがネットワークインタフェース２１にて受信されると（処理６０００）、当該受信パケットは、パケット処理エンジン２２に転送される。【０１３４】
パケット処理エンジン２２は、制御ポリシ管理部２６と連携して、受信パケットが監視対象のＵＥ１０のベアラのＤＬのＤＮＳパケットの検出機能がＯＮであるか否かをチェックし（処理６０１０）、ＯＮであれば（処理６０１０でＹｅｓなら）、さらに、その受信パケットがＤＮＳ応答２０Ａ′又は２０Ｂ′であるか否かをチェックする（処理６０２０）。【０１３５】
その結果、受信パケットがＤＮＳ応答２０Ａ′又は２０Ｂ′であれば（処理６０２０でＹｅｓなら）、その内容を制御ポリシ管理部２６に通知する。制御ポリシ管理部２６は、ＵＥ１０が送信したＤＮＳ要求２０Ａに対するＤＮＳ応答２０Ａ′と、自ノード２０が送信したＤＮＳ要求２０Ｂに対するＤＮＳ応答２０Ｂ′との双方の内容が一定時間内に揃ったか否かをチェックする（処理６０３０）。【０１３６】
揃えば（処理６０３０でＹｅｓなら）、制御ポリシ管理部２６は、両方のＤＮＳ応答２０Ａ′及び２０Ｂ′のアドレス解決結果（ＩＰアドレス）を比較する（処理６０４０）。つまり、制御ポリシ管理部２６は、両ＤＮＳ応答２０Ａ′及び２０Ｂ′を比較する比較手段としての機能を具備する。【０１３７】
また、図１４に示すように、制御ポリシ管理部２６は、前記検出機能をＯＦＦに設定するとともに、その設定をパケット処理エンジン２２にも反映する（処理６０５０）。【０１３８】
そして、制御ポリシ管理部２６は、前記ＤＮＳ応答２０Ａ′，２０Ｂ′の比較の結果、アドレス解決結果が異なる（ドメインが異なる）か否かをチェックし（処理６０６０）、異なっていれば、自ノード２０で生成、発信したＤＮＳ要求２０Ｂに対するＤＮＳ応答２０Ｂ′に含まれるＩＰアドレスを確保（ＰＤＮ／ＩＰアドレス／ＵＥ管理部２５に保持）する（処理６０６０のＹｅｓルートから処理６０７０）。【０１３９】
さらに、制御ポリシ管理部２６は、プロセッサ２３及び代替通信路設定管理部２７と連携して、通常（デフォルト）のベアラの識別情報、ＱｏＳ情報に加えて前記確保したＩＰアドレスを情報要素に含む、ベアラ設定要求を示すＵＥ１０宛のベアラ制御メッセージを生成する。生成したベアラ設定要求は、パケット処理エンジン２２、ネットワークインタフェース２１を通じて、ＵＥ１０に向けて送信される（処理６０８０）。この処理６０８０は、図６のステップＳ７での処理に相当する。【０１４０】
つまり、プロセッサ２３、制御ポリシ管理部２６及び代替通信路設定管理部２７は、前記比較の結果が異なる場合に、コア網ノード２０が発信したＤＮＳ要求２０Ｂに対するＤＮＳ応答２０Ｂ′の解決アドレスをＵＥ１０に割り当てて、ＵＥ１０と解決アドレスが示すコンテンツサーバとの間の通信路を設定する通信路設定手段としての機能を果たす。【０１４１】
なお、図１３の処理６０１０で前記検出機能がＯＦＦだった場合（Ｎｏの場合）や図１３の処理６０２０で受信パケットがＤＮＳ応答２０Ａ′，２０Ｂ′でなかった場合（Ｎｏの場合）は、ネットワークインタフェース２１及びパケット処理エンジン２２経由で、通常のＤＬパケット処理が実施される（図１４の処理６０８５）。【０１４２】
また、図１３の処理６０３０でＤＮＳ応答２０Ａ′及び２０Ｂ′が揃わない場合（Ｎｏの場合）は、制御ポリシ管理部２６は、受信できたＤＮＳ応答２０Ａ′又は２０Ｂ′の内容を保存して処理を終了する（処理６０３５）。【０１４３】
さらに、図１４の処理６０６０で比較したＩＰアドレス（ドメイン）が一致した場合（Ｎｏの場合）は、ローカルブレークアウトを実施できないと判断できるから、制御ポリシ管理部２６は、パケット処理エンジン２２に対して、ＵＥ１０が発信したＤＮＳ要求２０Ａに対するＤＮＳ応答２０Ａ′をＵＥ１０に転送する（ＤＮＳ応答２０Ａ′の解決アドレスをＵＥ１０に割り当てる）よう指示する。【０１４４】
パケット処理エンジン２２は、この指示に従ってＵＥ１０発信のＤＮＳ要求２０Ａに対するＤＮＳ応答２０Ａ′をネットワークインタフェース２１経由でＵＥ１０宛に転送するとともに（処理６０６５）、自ノード２０が代理発信したＤＮＳ要求２０Ｂに対するＤＮＳ応答２０Ｂ′の情報を破棄して（処理６０７５）、ネットワークインタフェース２１経由で通常のＤＬパケット処理を実施する（処理６０８５）。【０１４５】
また、図１５に示すように、ＵＥ１０が送信したベアラ設定応答を示すベアラ制御メッセージ（例えば図６のステップＳ８参照）が、ネットワークインタフェース２１経由でパケット処理エンジン２２にて受信された場合（処理７１００）、当該ベアラ設定応答は、プロセッサ２３に転送される。【０１４６】
プロセッサ２３は、受信したベアラ設定応答の情報要素を代替通信路設定管理部２７に保持、管理させるとともに、その情報要素に応じたルーティング設定をパケット処理エンジン２２に対して行なう。【０１４７】
そして、パケット処理エンジン２２は、代替通信路設定管理部２７と連携して、自ノード２０発信でアドレス解決したＩＰアドレスで、ＵＥ１０が発信したベアラ設定要求に対する前記受信ベアラ設定応答の内容を差し替えた上で、ネットワークインタフェース２１経由でＵＥ１０宛に転送する（処理７１１０）。【０１４８】
また、図１６に示すように、ＵＥ１０が送信したベアラ解放要求を示すベアラ制御メッセージ（例えば図７のステップＳ１２参照）が、ネットワークインタフェース２１経由でパケット処理エンジン２２にて受信された場合（処理７２００）、当該ベアラ解放要求は、プロセッサ２３に転送される。【０１４９】
プロセッサ２３は、代替通信路設定管理部２７と連携して、ベアラ解放応答を生成し、ネットワークインタフェース２１経由でＵＥ１０に向けて送信し（処理７２１０）、該当ベアラのリソースを解放する（処理７２２０）。例えば、ＰＤＮ／ＩＰアドレス／ＵＥ管理部２５、制御ポリシ管理部２６及び代替通信路設定管理部２７が保持する該当データを削除するとともに、パケット処理エンジン２２に対する該当ベアラのルーティング設定を解放（解除）する。この解放処理は、例えば図７のステップＳ１３での処理及びこれに関連する処理に相当する。【０１５０】
なお、図１７に示すように、制御ポリシ管理部２６は、前記監視タイマにより、ＤＬのＤＮＳパケットの検出機能のＯＮ状態が所定時間経過したことを検出すると（処理７３００）、ＵＥ１０が発信したＤＮＳ要求２０Ａに対するＤＮＳ応答２０Ａ′が受信、保存済みか否かをチェックする（処理７３１０）。【０１５１】
保存済みでなければ（処理７３１０でＮｏなら）、制御ポリシ管理部２６は、図１３の処理６０３５で保存したＤＮＳ応答２０Ｂ′を廃棄して（処理７３１５）、前記検出機能をＯＦＦに設定する（処理７３４０）。【０１５２】
一方、保存済みであれば（処理７３１０でＹｅｓなら）、制御ポリシ管理部２６は、保存したＤＮＳ応答２０Ａ′を読み出し、パケット処理エンジン２２及びネットワークインタフェース２１経由で、ＵＥ１０に向けて送信して（処理７３２０）、前記検出機能をＯＦＦに設定する（処理７３４０）。【０１５３】
このようにして、コア網ノード２０は、ＤＮＳ応答２０Ａ′，２０Ｂ′が揃わないために受信を待機し続けて前記検出機能が無駄にＯＮ状態となり続けることを回避することが可能となる。【０１５４】
〔５〕ＵＥ
図１８はＵＥ１０の構成例を示すブロック図である。この図１８に示すＵＥ１０は、例えば、ネットワークインタフェース１１と、パケット処理エンジン１２と、プロセッサ１３と、ベアラ管理部１４と、ＰＤＮ／ＩＰアドレス管理部１５と、代替通信路設定管理部１７と、をそなえる。これらの構成要素は、通信バス１８により相互に内部通信可能に接続されている。【０１５５】
ここで、ネットワークインタフェース１１は、無線インタフェースを具備し、外部との無線データ（パケット）の送受信を行なう機能を具備する。【０１５６】
パケット処理エンジン１２は、ベアラを識別し、ベアラ設定に基づくパケットルーティング機能や、自局１０宛のデータを識別し、適切なＵＥ１０内の処理部へ振り分ける機能を具備する。【０１５７】
また、このパケット処理エンジン１２は、代替通信路設定管理部１７で保持、管理するデータ（代替通信路としてのローカルブレークアウト通信用のベアラに関するデータ）に基づいて、ローカルブレークアウト通信のベアラ設定に基づくパケットルーティング機能も具備する。このパケット処理エンジン１２も、例えば、ＤＳＰやＦＰＧＡ、ＡＳＩＣ等の集積回路技術を用いて構成することが可能である。【０１５８】
ベアラ管理部１４は、ベアラ通信に必要な情報を保持、管理するものである。【０１５９】
ＰＤＮ／ＩＰアドレス管理部１５は、自局１０が接続しているＰＤＮと当該ＰＤＮ接続に使用しているＩＰアドレスとの対応等の、サービス状況に関する情報を保持、管理するものである。【０１６０】
代替通信路設定管理部１７は、デフォルト通信路とは別に新たに設定する代替通信路（ローカルブレークアウト用のベアラ）に関する制御データを保持、管理するものである。【０１６１】
プロセッサ１３は、ベアラの設定／解放に必要なベアラ制御メッセージ（ベアラ設定／解放要求等）の生成、終端処理機能や、ベアラ管理部１４、代替通信路設定管理部１７に必要な情報を格納し、これらの管理部１４，１７が保持、管理する情報に基づいて、ベアラ通信（ローカルブレークアウト通信を含む）に必要な設定を、パケット処理エンジン１２に対して行なう機能などを具備する。【０１６２】
さて、上述のごとく構成されたＵＥ１０において、デフォルト通信路などのベアラが設定される場合、コア網ノード２０又は３０との間で、ベアラ制御メッセージ（ベアラ設定要求／応答）が交換される。【０１６３】
ベアラ制御メッセージは、ネットワークインタフェース１１にて受信され、バス１８経由でパケット処理エンジン１２に転送され、パケット処理エンジン１２にて、ベアラ制御メッセージであることが識別され、バス１８経由でプロセッサ１３に転送される。【０１６４】
プロセッサ１３は、受信したベアラ制御メッセージを解析し、ベアラ設定要求であることを識別すると、ベアラを構成するための情報（対向ノードアドレス、ベアラ識別情報等）を当該ベアラ設定要求から抽出し、自局１０がベアラのパケットフローを受信するために必要な情報（自ノードアドレス、ベアラ識別情報子等）を決定する。【０１６５】
さらに、プロセッサ１３は、決定した前記情報を基に、ベアラ設定応答を生成するとともに、抽出及び決定した前記情報をベアラ管理データメモリ１４に格納するとともに、その情報に応じたルーティング設定をパケット処理エンジン１２に対して行なう。生成した前記ベアラ設定応答は、バス１８経由でパケット処理エンジン１２へ転送され、さらにパケット処理エンジン１２からバス１８経由でネットワークインタフェース１１に転送されて、ネットワークインタフェース１１から対向ノード宛に送信される。【０１６６】
ここで、ＵＥ１０のアタッチの手順に連動し、自局１０自身がベアラ設定要求を生成して送信する場合がある。【０１６７】
この場合、アタッチ処理をプロセッサ１３が処理し、アタッチ処理の手順の過程でコア網ノード２０又は３０から割り当てられたＩＰアドレスをＰＤＮ／ＩＰアドレス管理データメモリ１５に格納する。あるいは、プロセッサ１３は、自局１０に別手順で与えられたＩＰアドレスをＰＤＮ／ＩＰアドレス管理部１５に格納し、その情報を基に、ベアラとＵＥ１０のパケット識別情報（アドレス等）との対応情報（フィルタ情報）等とともにベアラ設定要求を生成する。【０１６８】
このベアラ設定要求も、バス１８経由でパケット処理エンジン１２に転送され、さらにパケット処理エンジン１２からバス１８経由でネットワークインタフェース１１へ転送されて、ネットワークインタフェース１１から対向ノードへ送信される。【０１６９】
なお、ベアラ解放要求／応答を示すベアラ制御メッセージも、上記と同様のノード内処理ルートを経由する。ベアラ解放応答を受信した場合は、プロセッサ１３により、該ベアラに関する情報が、パケット処理エンジン１２、ベアラ管理部１４、および、ＰＤＮ／ＩＰアドレス管理部１５から削除される。【０１７０】
ベアラ設定後に関しては、ＵＬ及びＤＬともに、パケット処理エンジン１２が、ベアラ設定に基づくパケット転送、および、必要なパケット処理（カプセル化）を行ない、所定の通信を成立させる。即ち、ＵＥ１０内では、ネットワークインタフェース１１からパケット処理エンジン１２、パケット処理エンジン１２からネットワークインタフェース１１を経由するルートで通信が行なわれる。【０１７１】
以下、本例のローカルブレークアウトを含む、ＵＥ１０の動作例について、図１９〜図２１を用いて説明する。なお、図１９〜図２１においても、処理番号に括弧付きで併記した符号は、ＵＥ１０における前記構成要素を通じてその処理番号での処理が扱われることを表している。【０１７２】
ただし、以下では、デフォルト通信路は確立済みであり、ＵＥ１０は、或るサイト（コンテンツサーバ）にアクセスするためにＤＮＳ要求２０Ａを生成して、ＤＮＳサーバ４０−０宛に送信したものと仮定する。その際、ＤＮＳ要求２０Ａは、プロセッサ１３にて生成され、パケット処理エンジン１２及びネットワークインタフェース１１経由で、対向ノード２０宛に送信される。【０１７３】
つまり、パケット処理エンジン１２及びネットワークインタフェース１１は、第１のパケットデータであるＤＮＳ要求２０Ａを送信手段として機能する。【０１７４】
図１９に示すように、ＵＥ１０において、コア網ノード２０が送信したＤＬのパケットがネットワークインタフェース１１にて受信されると、当該受信パケットはバス１８経由でパケット処理エンジン１２に転送される。【０１７５】
パケット処理エンジン１２は、受信パケットが、通常（デフォルト）のベアラの識別情報、ＱｏＳ情報に加えて、コア網ノード２０が代理発信したＤＮＳ要求２０Ｂに対するＤＮＳ応答２０Ｂ′の解決アドレス（ローカルブレークアウト用のベアラに用いるＩＰアドレス）を情報要素に含む、ベアラ制御メッセージ（ベアラ設定要求）であるか否かを解析し、ベアラ設定要求（例えば、図６のステップＳ７で対向ノード２０が送信したベアラ設定要求）であれば、その情報要素をプロセッサ１３に渡す。【０１７６】
つまり、ネットワークインタフェース１１及びパケット処理エンジン１２は、前記ＤＮＳ応答２０Ｂ′の解決アドレスを受信する受信手段としても機能する。【０１７７】
プロセッサ１３は、受信したベアラ設定要求の情報要素を代替通信路設定管理部１７にて保持、管理させるとともに、その情報要素の一つである前記解決アドレスに応じたルーティング設定をパケット処理エンジン１２に対して行なう（処理８０００）。【０１７８】
そして、プロセッサ１３は、ＵＥ１０がそれまでのデフォルトＩＰアクセスで用いていたＩＰアドレスと前記解決アドレスとが異なることを検出することで、ローカルブレークアウト用の通信路が利用可能であることを認識し、代替通信路設定管理部１７及びＰＤＮ／ＩＰアドレス管理部１５と連携して、前記ベアラセットアップ手順を開始する。【０１７９】
例えば、プロセッサ１３は、代替通信路設定管理部１７及びＰＤＮ／ＩＰアドレス管理部１５と連携して、通常（デフォルト）のベアラの識別情報、ＱｏＳ情報を情報要素に含む、ベアラ制御メッセージ（ベアラ設定応答）を生成して、パケット処理エンジン１２、ネットワークインタフェース１１経由で、対向ノード２０宛に送信する（処理８０１０）。この処理８０１０は、図６のステップＳ８の処理に相当する。以上の処理により、ローカルブレークアウト用のベアラ設定が完了する。【０１８０】
その後、代替通信路設定管理部１７は、内部のベアラチェックフラグをＯＮに設定して（処理８０２０）、処理を終える。なお、ベアラチェックフラグは、ローカルブレークアウト用に設定されたベアラの存否を表す情報である。【０１８１】
一方、図２０に示すように、ネットワークインタフェース１１経由でパケット処理エンジン１２にて受信されたＤＬのパケットがＤＮＳ応答（例えば、図６のステップＳ９で対向ノード２０が送信したＤＮＳ応答）であった場合、その内容は代替通信路設定管理部１７に渡され、代替通信設定管理部１７は、ベアラチェックフラグがＯＮのベアラがあるか否かをチェックする（処理８１１０）。【０１８２】
ベアラチェックフラグがＯＮのベアラが存在する場合（処理８１１０でＹｅｓの場合）、代替通信路設定管理部１７は、ＤＮＳサーバ４０−１の解決アドレスと、当該ベアラ（ローカルブレークアウト用のベアラ）についてのＵＬのＩＰフィルタデータの宛先アドレスとが一致するか否かをチェックする（処理８１１０のＹｅｓルートから処理８１２０）。【０１８３】
その結果、一致すれば、代替通信路設定管理部１７は、プロセッサ１３、ＰＤＮ／ＩＰアドレス管理部１５と連携して、当該ベアラと対応付けられたＩＰアドレスを用いて前記宛先アドレスに対する通信（つまり、ローカルブレークアウト通信）を開始する（パケット処理エンジン１２に対して必要なルーティング設定を行なう）（処理８１２０のＹｅｓルートから処理８１３０）。【０１８４】
つまり、プロセッサ１３、代替通信路設定管理部１７及びＰＤＮ／ＩＰアドレス管理部１５は、前記ＤＮＳ応答２０Ｂ′の解決アドレスを用いて、対向ノード２０により当該解決アドレスが示すコンテンツサーバとの間に設定された通信路にて当該コンテンツサーバに対するアクセスを行なう通信制御手段としての機能を果たす。【０１８５】
その後、プロセッサ１３は、通信（ＴＣＰセッション等の通信セッション）が終了したか否かを監視し（処理８１４０のＮｏルート）、終了すれば、代替通信路設定管理部１７と連携して、通信の終了したベアラのベアラ解放要求を生成し、パケット処理エンジン１２及びネットワークインタフェース１１経由で対向ノード２０へ前記ベアラ解放要求を送信する（処理８１４０のＹｅｓルートから処理８１５０）。この処理８１５０は、図７のステップＳ１２での処理に相当する。【０１８６】
そして、図２１に示すように、このベアラ解放要求に対するベアラ解放応答がネットワークインタフェース１１、パケット処理エンジン１２、プロセッサ１３を通じて代替通信路設定管理部１７にて受信されると（処理９０００）、代替通信路設定管理部１７は、該当ベアラのリソース解放処理を実施する（処理９０１０）。例えば、代替通信路設定管理部１７は、自身及びＰＤＮ／ＩＰアドレス管理部１５が保持する該当ベアラのリソース情報（ＩＰアドレス等）を削除するとともに、パケット処理エンジン１２に対する設定を解除する。【０１８７】
なお、図２０において、前記ベアラチェックフラグがＯＮのベアラが存在しない場合（処理８１１０でＮｏの場合）や、解決ＩＰアドレスと、ベアラのＵＬのＩＰフィルタデータの宛先アドレスとが一致しない場合（処理８１２０でＮｏの場合）は、その旨がプロセッサ１３に通知され、プロセッサ１３は、ローカルブレークアウトは実施せずに、前記ＤＮＳ応答を受信したベアラでの通信を開始するようパケット処理エンジン１２に対して必要な設定を行なう（処理８１１５）。【０１８８】
〔６〕その他
上述した例においては、ローカルブレークアウトの実施ポイントがｖＡＧＷ２０である場合について示したが、例えば図４又は図５に示したＵＥアクセスノードであるコア網ノードであってもよい。
【図１】
2009075033.tif 000003
【図２】
2009075033.tif 000004
【図３】
2009075033.tif 000005
【図４】
2009075033.tif 000006
【図５】
2009075033.tif 000007
【図６】
2009075033.tif 000008
【図７】
2009075033.tif 000009
【図８】
2009075033.tif 000010
【図９】
2009075033.tif 000011
【図１０】
2009075033.tif 000012
【図１１】
2009075033.tif 000013
【図１２】
2009075033.tif 000014
【図１３】
2009075033.tif 000015
【図１４】
2009075033.tif 000016
【図１５】
2009075033.tif 000017
【図１６】
2009075033.tif 000018
【図１７】
2009075033.tif 000019
【図１８】
2009075033.tif 000020
【図１９】
2009075033.tif 000021
【図２０】
2009075033.tif 000022
【図２１】
2009075033.tif 000023
【手続補正書】
【提出日】平成22年4月21日(2010.4.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおいて、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送する手段と、
前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信する手段と、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する手段と、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する手段と、
をそなえたことを特徴とする、パケット通信システム。
【請求項２】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるパケット通信方法であって、
前記ノードは、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送するとともに、前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信し、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較し、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定し、
前記ユーザ端末は、
前記割り当てられた第２のアドレス解決結果を用いて前記通信路にて前記第２のコンテンツサーバにアクセスする、
ことを特徴とする、パケット通信システムにおけるパケット通信方法。
【請求項３】
前記ノードは、
前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで、前記割り当てを実施する、ことを特徴とする、請求項２記載のパケット通信システムにおけるパケット通信方法。
【請求項４】
前記ユーザ端末は、
前記通信路設定要求に含まれる前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、
ことを特徴とする、請求項３記載のパケット通信システムにおけるパケット通信方法。
【請求項５】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるノードであって、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを受信する受信手段と、
前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成する生成手段と、
前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第２のパケットデータを第２のアドレス解決サーバ宛に送信する送信手段と、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する比較手段と、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する通信路設定手段と、
をそなえたことを特徴とする、パケット通信システムにおけるノード。
【請求項６】
前記通信路設定手段は、
前記比較結果が一致する場合、前記第１のアドレス解決結果を前記ユーザ端末に割り当てる、ことを特徴とする、請求項５記載のパケット通信システムにおけるノード。
【請求項７】
前記通信路設定手段は、
前記割り当てを、前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで実施する、ことを特徴とする、請求項５又は６に記載のパケット通信システムにおけるノード。
【請求項８】
前記通信路設定手段は、
前記通信路を経由した通信の終了により前記ユーザ端末が送信した前記通信路の解放要求を受信すると、前記通信路の設定を解放する、
ことを特徴とする、請求項５〜７のいずれか１項に記載のパケット通信システムにおけるノード。
【請求項９】
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおける前記ユーザ端末であって、
第１のコンテンツサーバにアクセスするために第１のパケットデータを送信する送信手段と、
前記第１のパケットデータを受信した前記パケット通信システムのノードが、前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信したことにより、前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから前記ノードに返信された第１及び第２のアドレス解決結果が異なる場合に、前記ノードから送信された前記第２のアドレス解決結果を受信する受信手段と、
前記第２のアドレス解決結果を用いて、前記ノードにより前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間に設定された通信路にて前記第２のコンテンツサーバに対するアクセスを行なう通信制御手段と、
をそなえたことを特徴とする、パケット通信システムにおけるユーザ端末。
【請求項１０】
前記通信制御手段は、
前記第２のアドレス解決結果が、前記ノードから受信した、前記通信路の設定手順の開始を要求する通信路設定要求に含まれている場合に、前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、ことを特徴とする、請求項９記載のパケット通信システムにおけるユーザ端末。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１８８
【補正方法】変更
【補正の内容】
【０１８８】
〔６〕その他
上述した例においては、ローカルブレークアウトの実施ポイントがｖＡＧＷ２０である場合について示したが、例えば図４又は図５に示したＵＥアクセスノードであるコア網ノードであってもよい。
以上の実施形態に関し、さらに以下の付記を開示する。
〔７〕付記
（付記１）
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおいて、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送する手段と、
前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信する手段と、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する手段と、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する手段と、
をそなえたことを特徴とする、パケット通信システム。
（付記２）
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるパケット通信方法であって、
前記ノードは、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを第１のアドレス解決サーバ宛に転送するとともに、前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信し、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較し、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定し、
前記ユーザ端末は、
前記割り当てられた第２のアドレス解決結果を用いて前記通信路にて前記第２のコンテンツサーバにアクセスする、
ことを特徴とする、パケット通信システムにおけるパケット通信方法。
（付記３）
前記ノードは、
前記比較結果が一致する場合、前記第１のアドレス解決結果を前記ユーザ端末に割り当て、
前記ユーザ端末は、
前記割り当てられた第１のアドレス解決結果を用いて前記第１のコンテンツサーバにアクセスする、
ことを特徴とする、付記２記載のパケット通信システムにおけるパケット通信方法。
（付記４）
前記ノードは、
前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで、前記割り当てを実施する、ことを特徴とする、付記２又は３に記載のパケット通信システムにおけるパケット通信方法。
（付記５）
前記ユーザ端末は、
前記通信路設定要求に含まれる前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、
ことを特徴とする、付記４記載のパケット通信システムにおけるパケット通信方法。
（付記６）
前記ユーザ端末は、
前記通信路を経由した通信が終了すると、前記通信路の解放要求を前記ノード宛に送信し、
前記ノードは、
前記解放要求を受信すると、前記通信路の設定を解放する、
ことを特徴とする、付記２〜５のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
（付記７）
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網のゲートウェイノードである、
ことを特徴とする、付記２〜６のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
（付記８）
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網以外のパケットデータ網であって前記ホームパケットデータ網と接続された網のゲートウェイノードである、
ことを特徴とする、付記２〜６のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
（付記９）
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおけるノードであって、
前記ユーザ端末が第１のコンテンツサーバにアクセスするために送信した第１のパケットデータを受信する受信手段と、
前記第１のパケットデータの送信元を自ノードとする第２のパケットデータを生成する生成手段と、
前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第２のパケットデータを第２のアドレス解決サーバ宛に送信する送信手段と、
前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから返信された第１及び第２のアドレス解決結果を比較する比較手段と、
その比較結果が異なる場合に、前記第２のアドレス解決結果を前記ユーザ端末に割り当てて、前記ユーザ端末と前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間の通信路を設定する通信路設定手段と、
をそなえたことを特徴とする、パケット通信システムにおけるノード。
（付記１０）
前記通信路設定手段は、
前記比較結果が一致する場合、前記第１のアドレス解決結果を前記ユーザ端末に割り当てる、ことを特徴とする、付記９記載のパケット通信システムにおけるノード。
（付記１１）
前記通信路設定手段は、
前記割り当てを、前記通信路の設定手順の開始を前記ユーザ端末に要求する通信路設定要求に、前記第２のアドレス解決結果を含めることで実施する、ことを特徴とする、付記９又は１０に記載のパケット通信システムにおけるノード。
（付記１２）
前記通信路設定手段は、
前記通信路を経由した通信の終了により前記ユーザ端末が送信した前記通信路の解放要求を受信すると、前記通信路の設定を解放する、
ことを特徴とする、付記９〜１１のいずれか１項に記載のパケット通信システムにおけるノード。
（付記１３）
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網のゲートウェイノードである、
ことを特徴とする、付記９〜１２のいずれか１項に記載のパケット通信システムにおけるノード。
（付記１４）
前記ノードは、
前記ユーザ端末が加入するホームパケットデータ網以外のパケットデータ網であって前記ホームパケットデータ網と接続された網のゲートウェイノードである、
ことを特徴とする、付記９〜１２のいずれか１項に記載のパケット通信システムにおけるパケット通信方法。
（付記１５）
ユーザ端末と、ユーザ端末が送信したパケットデータを受信しうるノードと、前記ノードから通信路が設定可能な複数のコンテンツサーバと、前記ノードと通信可能に接続されて、前記コンテンツサーバのアクセスに用いるアドレスの解決を受信パケットデータの送信元に基づいて行なう複数のアドレス解決サーバと、をそなえたパケット通信システムにおける前記ユーザ端末であって、
第１のコンテンツサーバにアクセスするために第１のパケットデータを送信する送信手段と、
前記第１のパケットデータを受信した前記パケット通信システムのノードが、前記第１のパケットデータを第１のアドレス解決サーバ宛に送信するとともに、前記第１のパケットデータの送信元を前記ノードとする第２のパケットデータを生成して第２のアドレス解決サーバ宛に送信したことにより、前記第１及び第２のパケットデータに対して前記第１及び第２のアドレス解決サーバから前記ノードに返信された第１及び第２のアドレス解決結果が異なる場合に、前記ノードから送信された前記第２のアドレス解決結果を受信する受信手段と、
前記第２のアドレス解決結果を用いて、前記ノードにより前記第２のアドレス解決結果が示す第２のコンテンツサーバとの間に設定された通信路にて前記第２のコンテンツサーバに対するアクセスを行なう通信制御手段と、
をそなえたことを特徴とする、パケット通信システムにおけるユーザ端末。
（付記１６）
前記通信制御手段は、
前記第２のアドレス解決結果が、前記ノードから受信した、前記通信路の設定手順の開始を要求する通信路設定要求に含まれている場合に、前記第２のアドレス解決結果と、それまでの通信に用いていたアドレス情報とが異なることを検出することで、前記通信路が利用可能であることを認識して前記通信路の設定手順を開始する、ことを特徴とする、付記１５記載のパケット通信システムにおけるユーザ端末。
（付記１７）
前記通信制御手段は、
前記通信路を経由した通信が終了すると、前記通信路の解放要求を前記ノード宛に送信する、ことを特徴とする、付記１５又は１６に記載のパケット通信システムにおけるユーザ端末。
（付記１８）
前記通信制御手段は、
前記解放要求に対する応答を受信することにより、前記通信路のために確保した通信リソースを解放する、ことを特徴とする、付記１７記載のパケット通信システムにおけるユーザ端末。
【国際調査報告】
2009075033.tif 000024
2009075033.tif 000025