(57)【要約】  コアネットワークに顕著な複雑さを付加することなく、ネットワーク構造内のトラフィックを確実かつフレキシブルに制御することを可能にするため、ネットワーク構造内でトラフィックを制御する方法が提供される。前記構造は、ＰＤＮ（Packet Data Network）、ＤＮＳ（Domain Name System）サーバを備えた事業者コアネットワーク、ＨｅＮＢ（Home evolved Node B）もしくはＮＨＢ（Home Node B）および／またはｅＮＢ（Evolved Node B）もしくはＮＢ（Node B）、ならびに前記ＨｅＮＢもしくはＮＨＢおよび／またはｅＮＢもしくはＮＢに関連づけられたＵＥ（User Equipment）を有する。所定のルーティングポリシーに基づいて、前記ＤＮＳサーバは、ＵＥからＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢに関連づけられたローカルネットワーク内またはＰＤＮ内の宛先アドレスへのトラフィックおよび／またはその逆のトラフィックが、コアネットワーク経由でルーティングされるか、それとも、ローカルネットワークプロトコルアクセスまたは選択ネットワークプロトコルトラフィック負荷軽減をサポートしたローカルネットワーク経由で直接にルーティングされるかを制御することを特徴とする。また、好ましくは上記方法を実行するネットワーク構造が提供される。
2013502190.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク構造内でトラフィックを制御する方法において、前記構造は、ＰＤＮ（Packet Data Network）、ＤＮＳ（Domain Name System）サーバを備えた事業者コアネットワーク、ＨｅＮＢ（Home evolved Node B）もしくはＮＨＢ（Home Node B）および／またはｅＮＢ（Evolved Node B）もしくはＮＢ（Node B）、ならびに前記ＨｅＮＢもしくはＮＨＢおよび／またはｅＮＢもしくはＮＢに関連づけられたＵＥ（User Equipment）を有し、
所定のルーティングポリシーに基づいて、前記ＤＮＳサーバは、ＵＥからＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢに関連づけられたローカルネットワーク内またはＰＤＮ内の宛先アドレスへのトラフィックおよび／またはその逆のトラフィックが、コアネットワーク経由でルーティングされるか、それとも、ローカルネットワークプロトコルアクセスまたは選択ネットワークプロトコルトラフィック負荷軽減をサポートしたローカルネットワーク経由で直接にルーティングされるかを制御することを特徴とする、ネットワーク構造内でトラフィックを制御する方法。
【請求項２】
ＰＤＮがインターネットであり、ネットワークプロトコルがＩＰであり、ローカルネットワークプロトコルアクセスがＬＩＰＡ（Local IP (Internet Protocol) Access）であり、選択ネットワークプロトコルトラフィック負荷軽減がＳＩＰＴＯ（Selected IP Traffic Offload）であることを特徴とする請求項１に記載の方法。
【請求項３】
前記ＤＮＳサーバが、ＵＥによるＤＮＳ要求後に、ＤＮＳ応答において、コアネットワーク経由での、または、ローカルネットワークプロトコルアクセスのためのローカルネットワーク経由もしくは選択ネットワークプロトコルトラフィック負荷軽減のための無線アクセスネットワーク（ＲＡＮ）付近のローカルトラフィック負荷軽減ノード経由での直接のトラフィックルーティングに関して、ルーティング情報を指示することを特徴とする請求項１または２に記載の方法。
【請求項４】
ＬＰ−ＧＷ（ローカルＰＤＮゲートウェイまたはＬ−ＧＷ）が、ＨｅＮＢもしくはＮＨＢまたはｅＮＢもしくはＮＢに関連づけられ、または共同配置されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
前記ＬＰ−ＧＷがＬＧＧＳＮ（ローカルＧＧＳＮ）であり、ＨＮＢまたはＮＢに関連づけられ、または共同配置されることを特徴とする請求項４に記載の方法。
【請求項６】
ＤＮＳプロキシ機能が、ＬＰ−ＧＷに、または、ＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢに実現されることを特徴とする請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
ルーティング情報が、ＤＮＳ応答内のフラグによって提供され、該フラグは、ＨｅＮＢもしくはｅＮＢもしくはＮＢに対して、またはＬＰ−ＧＷに対して、後続のトラフィックルーティングを指示することを特徴とする請求項３ないし６のいずれか１項に記載の方法。
【請求項８】
ＤＮＳプロキシ機能が、ＨｅＮＢもしくはＨＮＢもしくはｅＮＢもしくはＮＢに、またはＬＰ−ＧＷに実現され、ＤｅｓｔＮＡＴ（Destination Network Address Translation）ネットワークプロトコルアドレスをＤＮＳ応答の一部としてＵＥに提供し、ＤｅｓｔＮＡＴと、ローカルネットワーク内またはＰＤＮ内の宛先アドレスとの間のバインディング／アソシエーションを確立することを特徴とする請求項３ないし７のいずれか１項に記載の方法。
【請求項９】
ＤＮＳサーバは、ＬＰ−ＧＷにＤＮＳプロキシ機能がない場合に、ローカルネットワーク内またはＰＤＮ内の宛先アドレスに対するＮＡＴをＬＰ−ＧＷに要求することを特徴とする請求項４に記載の方法。
【請求項１０】
ＨｅＮＢもしくはｅＮＢまたはＬＰ−ＧＷが、ソースおよび宛先の両方のアドレスを２つの異なるアドレス、すなわちそれぞれＳｒｃＮＡＴ（Source Network Address Translation）アドレスおよびＤｅｓｔＮＡＴアドレス、に変換するＴｗｉｃｅ−ＮＡＴ機能を有することを特徴とする請求項１ないし９のいずれか１項に記載の方法。
【請求項１１】
ＤｅｓｔＮＡＴアドレスがローカルネットワーク内またはＰＤＮ内の宛先アドレスを有する場合に、ステートレスＴｗｉｃｅ−ＮＡＴが実行されることを特徴とする請求項８ないし１０のいずれか１項に記載の方法。
【請求項１２】
ＬＰ−ＧＷまたはＨｅＮＢもしくはＨＮＢもしくはｅＮＢもしくはＮＢの関与なしに、ＤＮＳサーバが、他の手段によってＬＰ−ＧＷまたはＨｅＮＢもしくはＨＮＢもしくはｅＮＢもしくはＮＢからＤＮＳサーバによって取得された、ＬＰ−ＧＷまたはＨｅＮＢもしくはＨＮＢもしくはｅＮＢもしくはＮＢのＤｅｓｔＮＡＴアドレスを直接提供することを特徴とする請求項１ないし８のいずれか１項に記載の方法。
【請求項１３】
ＨｅＮＢもしくはＨＮＢもしくはｅＮＢもしくはＮＢまたはＬＰ−ＧＷが、コアネットワークのＰ−ＧＷ（PDN-Gateway）またはＳ−ＧＷ（Serving Gateway）へのトンネリングメカニズムをサポートすることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
【請求項１４】
Ｐ−ＧＷがＧＧＳＮであり、Ｓ−ＧＷがＳＧＳＮであることを特徴とする請求項１３に記載の方法。
【請求項１５】
ＨｅＮＢもしくはＨＮＢもしくはｅＮＢもしくはＮＢまたはＬＰ−ＧＷが、ＵＥへのトンネリングメカニズムをサポートすることを特徴とする請求項１ないし１４のいずれか１項に記載の方法。
【請求項１６】
ＵＥのネットワーク層が、トラフィックがトンネリングされるべきか否かを判定するために、コネクションまたはフローごとの状態を維持することを特徴とする請求項１３ないし１５のいずれか１項に記載の方法。
【請求項１７】
ＵＥが、ソースルーティングメカニズムをサポートすることを特徴とする請求項１３ないし１６のいずれか１項に記載の方法。
【請求項１８】
２つのアドレス、すなわち、コアネットワーク内でルーティング可能なＬＰ−ＧＷまたはローカルＧＷのアドレス、および、ローカルネットワーク内またはＰＤＮ内の宛先アドレス、がＤＮＳ応答内で指示されることを特徴とする請求項１３ないし１７のいずれか１項に記載の方法。
【請求項１９】
ＵＥが相異なるＡＰＮを有する複数のＰＤＰ（Packet Data Protocol）コンテキスト／ＰＤＮコネクションを有する場合またはサポートする場合に、前記ＤＮＳサーバが、ＵＥによるＤＮＳ要求後に、ＵＥへのＤＮＳ応答において、特定のトラフィックまたはフローまたはコネクションに対してどのＡＰＮを使用すべきかを選択し指示することを特徴とする請求項１または２に記載の方法。
【請求項２０】
少なくとも１つのＰＤＰコンテキスト／ＰＤＮコネクションが、ＬＩＰＡおよび／またはＳＩＰＴＯ専用であることを特徴とする請求項１９に記載の方法。
【請求項２１】
ＤＮＳサーバが、利用可能なＡＰＮまたはＰＤＰコンテキスト／ＰＤＮコネクションに関する事前知識を有することを特徴とする請求項１９または２０に記載の方法。
【請求項２２】
ＵＥは、前のＤＮＳ要求において、ＵＥが現在利用可能なＡＰＮを通知することを特徴とする請求項１９ないし２１のいずれか１項に記載の方法。
【請求項２３】
ＤＮＳサーバが、利用可能なＡＰＮを優先するパラメータまたはメトリックに基づいてＡＰＮを選択することを特徴とする請求項２２に記載の方法。
【請求項２４】
ＵＥが、好ましくはＤＮＳ応答内の指示またはフラグにより、ローカルネットワークプロトコルアクセスおよび／または選択ネットワークプロトコルトラフィック負荷軽減に従うＤＮＳ要求の結果をキャッシュせず、好ましくは、それぞれのＡＰＮに対するＤＮＳキャッシングを完全に無効化することを特徴とする請求項１９ないし２３のいずれか１項に記載の方法。
【請求項２５】
ＵＥが、トラフィックルーティングのために使用されるべきＡＰＮまたはＰＤＰコンテキスト／ＰＤＮコネクションの最終的な選択プロセスに関与することを特徴とする請求項１９ないし２３のいずれか１項に記載の方法。
【請求項２６】
ネットワーク構造、好ましくは請求項１ないし２５のいずれか１項に記載の方法を実行するネットワーク構造において、該構造は、ＰＤＮ（Packet Data Network）、ＤＮＳ（Domain Name System）サーバを備えた事業者コアネットワーク、ＨｅＮＢ（Home evolved Node B）もしくはＮＨＢ（Home Node B）および／またはｅＮＢ（Evolved Node B）もしくはＮＢ（Node B）、ならびに前記ＨｅＮＢもしくはＨＮＢおよび／またはｅＮＢもしくはＮＢに関連づけられたＵＥ（User Equipment）を有し、
所定のルーティングポリシーに基づいて、ＵＥからＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢに関連づけられたローカルネットワーク内またはＰＤＮ内の宛先アドレスへのトラフィックおよび／またはその逆のトラフィックが、コアネットワーク経由でルーティングされるか、それとも、ローカルアクセスプロトコルアクセスまたは選択ネットワークプロトコルトラフィック負荷軽減をサポートしたローカルネットワーク経由で直接にルーティングされるかを前記ＤＮＳサーバが制御するように、前記ＤＮＳサーバが構成されることを特徴とするネットワーク構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク構造内でトラフィックを制御する方法に関する。前記構造は、ＰＤＮ（Packet Data Network）、ＤＮＳ（Domain Name System）サーバを備えた事業者コアネットワーク、ＨｅＮＢ（Home evolved Node B）もしくはＮＨＢ（Home Node B）および／またはｅＮＢ（Evolved Node B）もしくはＮＢ（Node B）、ならびに前記Ｈ（ｅ）ＮＢおよび／または（ｅ）ＮＢに関連づけられたＵＥ（User Equipment, ユーザ機器）を有する。
【０００２】
また、本発明は、好ましくは上記方法を実行するネットワーク構造に関する。該構造は、ＰＤＮ（Packet Data Network）、ＤＮＳ（Domain Name System）サーバを備えた事業者コアネットワーク、ＨｅＮＢ（Home evolved Node B）もしくはＮＨＢ（Home Node B）および／またはｅＮＢ（Evolved Node B）もしくはＮＢ（Node B）、ならびに前記Ｈ（ｅ）ＮＢおよび／または（ｅ）ＮＢに関連づけられたＵＥ（User Equipment, ユーザ機器）を有する。
【背景技術】
【０００３】
３ＧＰＰにおいて、ローカルＩＰ接続性を効率的にサポートするために、アーキテクチャの高度化の探求が集中的に進められている。現在、このようなローカルＩＰ接続性は、トラフィックがローカルネットワーク（例えばホームネットワークや企業ネットワーク）向けである場合にはＬＩＰＡ（Local IP Access, ローカルＩＰアクセス）と略称され、あるいはトラフィックがインターネット向けである場合にはＳＩＰＴＯ（Selected IP Traffic Offload, 選択ＩＰトラフィック負荷軽減）と略称されている。３ＧＰＰの取り組みは、ホームセル（すなわちＨ（ｅ）ＮＢ）およびマクロセル（すなわち（ｅ）ＮＢ）の両方の場合に向けられ、ＥＰＳ（非特許文献１参照）およびＧＰＲＳ（非特許文献２参照）を対象としている。３ＧＰＰ  ＳＡ２は、S2-094867, "New WID for Local IP Access & Internet Offload" に従って、すでに標準化作業を開始している。本発明は、以下でさらに詳細に説明するように、これらの仕様および文書ならびに関連仕様に規定された仮定および原理に基づいている。
【０００４】
最新のモバイルネットワーク技術において、ＵＥから外部（ターゲット）ＰＤＮ（Packet Data Network, パケットデータネットワーク）向けのＩＰ接続性は、モバイルネットワーク事業者のコアネットワーク内のＰＤＮゲートウェイ（PDN Gateway, Ｐ−ＧＷ）によって提供される。モビリティトンネルが、（ｅ）ＮｏｄｅＢおよびサービングゲートウェイ（Serving-Gateway）経由でトラフィックを伝送する。同様に、ＧＰＲＳの場合、ＩＰ接続性は、ＥＰＳの場合におけるＰＤＮゲートウェイに対応するＧＧＳＮ（Gateway GPRS Support Node, ゲートウェイＧＰＲＳサポートノード）によって提供される。また、ＵＴＲＡＮ無線アクセス（３Ｇ）では、モビリティトンネルが、ＮｏｄｅＢ、ＲＮＣ（Radio Network Controller, 無線ネットワークコントローラ）およびＳＧＳＮ（Serving GPRS Support Node, サービングＧＰＲＳサポートノード）経由でトラフィックを伝送する。
【０００５】
一般的な問題は、単純（plain, "dumb"）なインターネットトラフィック、すなわちローカルサーバへの（例えばホームネットワークあるいは企業ネットワーク内の）トラフィックの量が、今後かなり増大すると予想されることである。この種のトラフィックは、モバイル事業者ネットワークにおいて高価なリソースを消費すべきではないので、できる限り事業者のネットワークから負荷軽減すべきである。ＩＰトラフィック分離（breakout）の可能な位置の１つはＨ（ｅ）ＮＢまたは（ｅ）ＮＢにある。
【０００６】
最新技術には、ＡＰＮ（Access Point Name, アクセスポイント名）の概念がある。これにより、トラフィックを分離することが可能となる。ＡＰＮは、ＦＱＤＮ（Fully Qualified Domain Name, 完全修飾ドメイン名）の形をとり、最終的には、それぞれのＰＤＮへのアクセスを提供するＰ−ＧＷまたはＧＧＳＮのＩＰアドレスへと解決される。標準化における現在の議論では、ＬＩＰＡ／ＳＩＰＴＯトラフィックに対して、別個のＡＰＮが使用されるとほとんど仮定されている。また、１つの共通のＡＰＮをＬＩＰＡ／ＳＩＰＴＯ型および非ＬＩＰＡ／ＳＩＰＴＯ型のトラフィックに対して使用するという要求もなされている。異なるＨ（ｅ）ＮＢまたは（ｅ）ＮＢへのＵＥのハンドオーバー時にサービス連続性を実現するための解決法は与えられていない。
【０００７】
また、ＬＩＰＡおよびＳＩＰＴＯに関してさらに詳細には、非特許文献３から入手可能である。
【０００８】
いくつかの目的のために、事業者は、特定のユーザおよびＩＰコネクション／フローに関連するトラフィックがどのようにルーティングされるべきか（コアネットワーク経由で、あるいは、ローカルネットワークプロトコルアクセスまたは選択的ネットワークプロトコルトラフィック負荷軽減をサポートしたローカルネットワーク経由で直接に）を完全に制御することに関心がある。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】3GPP TS 23.401 V8.6.0 (2009-06), "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"
【非特許文献２】3GPP TS 23.060 V8.5.1 (2009-06), "General Packet Radio Service (GPRS); Service description"
【非特許文献３】TS Group Services and System Aspects; Local IP Access and Selected IP Traffic offload (Rel. 10), 3GPP TR 23.829
【発明の概要】
【発明が解決しようとする課題】
【００１０】
したがって、本発明の目的は、ネットワーク構造内でトラフィックを制御する方法および対応するネットワーク構造において、コアネットワークに顕著な複雑さを付加することなく、ネットワーク構造内のトラフィックを確実かつフレキシブルに制御することが可能となるような改良およびさらなる展開を行うことである。
【課題を解決するための手段】
【００１１】
本発明によれば、上記の目的は、請求項１に記載の方法によって達成される。この請求項に記載の通り、本方法は、以下のことを特徴とする。すなわち、所定のルーティングポリシーに基づいて、前記ＤＮＳサーバは、ＵＥからＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢに関連づけられたローカルネットワーク内またはＰＤＮ内の宛先アドレスへのトラフィックおよび／またはその逆のトラフィックが、コアネットワーク経由でルーティングされるか、それとも、ローカルネットワークプロトコルアクセスまたは選択的ネットワークプロトコルトラフィック負荷軽減をサポートしたローカルネットワーク経由で直接にルーティングされるかを制御する。
【００１２】
また、上記の目的は、請求項２５に記載のネットワーク構造によって達成される。この請求項に記載の通り、本ネットワーク構造は、ＤＮＳサーバが以下のように構成されることを特徴とする。すなわち、所定のルーティングポリシーに基づいて、前記ＤＮＳサーバは、ＵＥからＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢに関連づけられたローカルネットワーク内またはＰＤＮ内の宛先アドレスへのトラフィックおよび／またはその逆のトラフィックが、コアネットワーク経由でルーティングされるか、それとも、ローカルネットワークプロトコルアクセスまたは選択的ネットワークプロトコルトラフィック負荷軽減をサポートしたローカルネットワーク経由で直接にルーティングされるかを制御する。
【００１３】
本発明によって認識されたこととして、ネットワーク構造内のトラフィックの制御は、ＤＮＳサーバによって非常に容易かつ確実な形で可能となる。また、認識されたこととして、制御手順は、ＤＮＳサーバに提供可能な所定のルーティングポリシーに基づくことが可能である。このため、ＵＥから宛先アドレスへのトラフィック（例えばＩＰフロー）および／またはその逆のトラフィックが、コアネットワーク経由で、または、ローカルネットワーク（もしくは無線アクセスネットワーク（Radio Access Network, ＲＡＮ）付近のローカルトラフィック負荷軽減ノード）経由で直接に、ルーティング可能である。上記のルーティング手順は、ＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢに関連づけられたローカルネットワーク内またはＰＤＮ内の宛先アドレスの位置に応じて選択可能である。
【００１４】
このような制御により、事業者は、ある種のトラフィックおよび／またはユーザ（ＩＰフロー）に対して、ローカルネットワーク（またはＲＡＮ付近のローカルトラフィック負荷軽減ノード）経由でのルーティングをフレキシブルかつ動的に有効化することができる。これにより、トラフィックを監視し、法律上の目的でトラフィック検査を行い、特定のネットワークサービスへのアクセスを最適化することができる。例えば、高速アクセス、モビリティおよびＱｏＳ（サービス品質）を保証し、例えば特定のサイトへのアクセスを遮断するといった付加価値をネットワークサービスに付けることができる。
【００１５】
好ましくは、ＰＤＮはインターネットであり、ネットワークプロトコルはＩＰであり、ローカルネットワークプロトコルアクセスはＬＩＰＡ（Local IP (Internet Protocol) Access）であり、選択ネットワークプロトコルトラフィック負荷軽減はＳＩＰＴＯ（Selected IP Traffic Offload）である。この場合、事業者は、上記の目的に関して、ある種のトラフィックおよび／またはユーザ（ＩＰフロー）に対して、ＬＩＰＡ／ＳＩＰＴＯをフレキシブルかつ／または動的に無効化することができる。
【００１６】
好ましい実施形態によれば、前記ＤＮＳサーバは、ＵＥによるＤＮＳ要求後に、ＤＮＳ応答において、コアネットワーク経由またはローカルネットワーク（もしくは無線アクセスネットワーク（ＲＡＮ）付近のローカルトラフィック負荷軽減ノード）経由でのトラフィックルーティングに関して、ルーティング情報を指示してもよい。これにより、制御手順は、ＵＥのＤＮＳ要求によって非常に容易に開始されることが可能となる。このＤＮＳベースの動的ルーティングポリシー設定／管理は、ＤＮＳサーバで集中化された形で行うことができるため、コアネットワーク経由またはローカルネットワーク（もしくは無線アクセスネットワーク（ＲＡＮ）付近のローカルトラフィック負荷軽減ノード）経由のいずれかのトラフィックを制御することに伴う管理および運用が容易になる。
【００１７】
非常にフレキシブルなトラフィックルーティングに関して、ＬＰ−ＧＷ（Local PDN Gateway, ローカルＰＤＮゲートウェイ、これはまた、Ｌ−ＧＷあるいはトラフィック負荷軽減機能（traffic offload function, ＴＯＦ）ともいう）が、ＨｅＮＢもしくはＮＨＢまたはｅＮＢもしくはＮＢに関連づけられ、または共同配置されてもよい。好ましくは、ＤＮＳプロキシ機能がＬＰ−ＧＷに実現されてもよい。この機能は、ＤＮＳ要求をインターセプトし、それを事業者ＤＮＳサーバへ転送してもよい。ＤＮＳ要求に応答して、ＤＮＳサーバは、宛先アドレス、および好ましくはトラフィックがどのように処理されるべきかを指示する追加情報を含むＤＮＳ応答を送信してもよい。
【００１８】
非常に簡単な形でルーティング情報を提供するため、ルーティング情報は、ＤＮＳ応答内のフラグによって提供されてもよい。フラグは、ＨｅＮＢもしくはｅＮＢに対して、またはＬＰ−ＧＷに対して、後続のトラフィックルーティングを指示する。
【００１９】
非常に確実なトラフィック制御およびトラフィックのサービス連続性のサポートに関して、ＤＮＳプロキシ機能は、ＨｅＮＢもしくはｅＮＢに、またはＬＰ−ＧＷに実現されて、ローカルＤｅｓｔＮＡＴ（Destination Network Address Translation）ネットワークプロトコルアドレスをＤＮＳ応答の一部としてＵＥに提供し、ローカルＤｅｓｔＮＡＴと、ローカルネットワーク内またはＰＤＮ内の宛先アドレスとの間のバインディング／アソシエーションを確立してもよい。好ましくは、ＤＮＳサーバは、ＬＰ−ＧＷにＤＮＳプロキシ機能がない場合には、ローカルネットワーク内またはＰＤＮ内の宛先アドレスに対するＤｅｓｔＮＡＴアドレスをＬＰ−ＧＷに要求してもよい。その場合、ＤＮＳサーバは、要求側ＵＥに直接にＤｅｓｔＮＡＴを提供することになる。
【００２０】
好ましい実施形態によれば、Ｈ（ｅ）ＮＢもしくは（ｅ）ＮＢ（ＨｅＮＢもしくはＮＨＢもしくはｅＮＢもしくはＮＢ）またはＬＰ−ＧＷは、ソースおよび宛先の両方のアドレスを２つの異なるアドレス、すなわちそれぞれＳｒｃＮＡＴ（Source Network Address Translation）アドレスおよびＤｅｓｔＮＡＴアドレス、に変換するＴｗｉｃｅ−ＮＡＴ機能を有してもよい。また、ＤｅｓｔＮＡＴアドレスがローカルネットワーク内またはＰＤＮ内の宛先アドレスを有する場合には、ステートレスＴｗｉｃｅ−ＮＡＴを実行してもよい。例えば、ＵＥとＬＰ−ＧＷとの間でＩＰｖ６が使用され、宛先の実ＩＰアドレスがＩＰｖ４アドレスである場合、ＤｅｓｔＮＡＴは、例えば、「２００１：３００１：２５２１：５３２３：ＦＦＦＦ：ＦＦＦＦ：ＦＦＦＦ：宛先のＩＰｖ４アドレス」のようなフォーマットをとることができる。
【００２１】
ＬＰ−ＧＷまたはＨｅＮＢもしくはｅＮＢがＤＮＳプロキシ機能に関与することなしに、ＤＮＳサーバは、ＤｅｓｔＮＡＴアドレスをＵＥに直接提供してもよい。このようなＤｅｓｔＮＡＴアドレスは、前段落に記載したのと同じフォーマットで提供されてもよい。
【００２２】
上記で説明したＴｗｉｃｅ−ＮＡＴに基づいて、ローカルＩＰアクセストラフィックまたは選択ＩＰトラフィック負荷軽減（例えばＳＩＰＴＯ）トラフィックに対するサービス連続性が、異なるＨ（ｅ）ＮＢまたは（ｅ）ＮＢへのＵＥのハンドオーバー時に実現されてもよい。
【００２３】
別の好ましい実施形態によれば、異なるＨ（ｅ）ＮＢまたは（ｅ）ＮＢへのＵＥのハンドオーバー時に、ローカルＩＰアクセストラフィックまたは選択ＩＰトラフィック負荷軽減トラフィックに対するサービス連続性が、単純トンネリングまたはソースルーティングを用いて実現されてもよい。具体的実施形態において、ＵＥは、Ｈ（ｅ）ＮＢまたは（ｅ）ＮＢへのトンネリングメカニズムをサポートしてもよい。
【００２４】
好ましくは、ＵＥのネットワーク層は、ＩＰフロー／トラフィックがトンネリングされるべきか否かを判定するために、コネクションまたはフローごとの状態を維持してもよい。
【００２５】
別法として、ＵＥは、上記のサービス連続性を維持するためのソースルーティングメカニズムをサポートしてもよい。
【００２６】
別の好ましい実施形態において、２つのアドレスがＤＮＳ応答内で指示されてもよい。一方のアドレスは、ローカルネットワーク内またはＰＤＮ内の宛先アドレスを指示し、他方のアドレスはトンネリングのために使用される。
【００２７】
別法として、ＰＤＮ内でルーティング可能なＬＰ−ＧＷのアドレスと、ローカルネットワーク内またはＰＤＮ内の宛先アドレスとの２つのアドレスがＤＮＳ応答内で指示されてもよい。
【００２８】
上記の実施形態は、ＵＥが単一のＰＤＰ（Packet Data Protocol, パケットデータプロトコル）コンテキスト／ＰＤＮコネクションのみをサポートする場合の解決法に関するものである。しかし、ＵＥが複数のＰＤＰコンテキスト／ＰＤＮコネクションをサポートする場合もあり得る。この場合、前記ＤＮＳサーバは、ＵＥによるＤＮＳ要求後に、ＵＥへのＤＮＳ応答において、特定のトラフィックフローまたはコネクションに対してどのＡＰＮを使用すべきかを選択し指示してもよい。この解決法において、ローカルネットワークプロトコルアクセストラフィックまたは「選択ネットワークプロトコルトラフィック負荷軽減」トラフィックに関するサービス連続性は、コアネットワークによってサポートされる。
【００２９】
好ましい実施形態によれば、少なくとも１つのＰＤＰコンテキスト／ＰＤＮコネクションを、ＬＩＰＡおよび／またはＳＩＰＴＯ専用としてもよい。ＤＮＳサーバは、関連するＰＤＰコンテキスト／ＰＤＮコネクションを選択することができる。
【００３０】
好ましくは、ＤＮＳサーバは、利用可能なＡＰＮまたはＰＤＰコンテキスト／ＰＤＮコネクションに関する事前知識を有してもよい。
【００３１】
別の好ましい実施形態において、ＵＥは、前のＤＮＳ要求において、ＵＥが現在利用可能なＡＰＮを通知してもよい。こうして、ＤＮＳサーバは、ＰＤＰコンテキスト／ＰＤＮコネクションの利用可能なＡＰＮに関して実際に通知されてもよい。
【００３２】
好ましくは、ＤＮＳサーバは、利用可能なＡＰＮを優先するパラメータまたはメトリックに基づいてＡＰＮを選択してもよい。
【００３３】
こうして、ＵＥは、ＤＮＳ応答から推奨されるＡＰＮを識別することが可能であり、それに応じてトラフィックをルーティングしてもよい。
【００３４】
好ましい実施形態によれば、ＤＮＳサーバは、応答内のフラグを用いることのみによって、ＵＥが特定のトラフィックフローまたはコネクションに対して所定のＡＰＮを使用すべきことを指示することも可能である。
【００３５】
好ましい実施形態によれば、ＵＥは、ＤＮＳ応答内の指示またはフラグにより、ローカルネットワークプロトコルアクセスおよび／または選択ネットワークプロトコルトラフィック負荷軽減に対するＤＮＳ要求の結果をキャッシュしなくてもよく、それぞれのＡＰＮに対するＤＮＳキャッシングを完全に無効化してもよい。
【００３６】
別の好ましい実施形態において、ＵＥは、ＤＮＳサーバの選択プロセスに関与してもよい。
【００３７】
本発明は、事業者がＵＥのトラフィック処理を制御しそれをどのようにルーティングするか（ローカルネットワークプロトコルアクセスまたは選択ネットワークプロトコルトラフィック負荷軽減（例えばＬＩＰＡまたはＳＩＰＴＯ）経由か、それともコアネットワーク経由か）を決定することを可能にする一連のメカニズムを提示する。決定は、ドメイン名、宛先アドレスの種類またはタイプ、アプリケーションの種類またはタイプに依存してもよい。ＬＰ−ＧＷをＮ（ｅ）ＮＢ／（ｅ）ＮＢ、ＤＮＳサーバ、および／またはＵＥに実現する技術的効果が、それぞれの実施形態に応じて期待される。
【００３８】
本発明において、特定のＵＥのトラフィックフローがローカルネットワーク（もしくは無線アクセスネットワーク（ＲＡＮ）付近のローカルトラフィック負荷軽減ノード）経由で直接にルーティングされるべきか、それともコアネットワーク経由でルーティングされるべきかを事業者が動的に制御することを可能にするさまざまな解決法が与えられる。
【００３９】
本発明は、好ましくはＬＩＰＡ／ＳＩＰＴＯトラフィックのサービス連続性にも関する。本明細書では、Ｈ（ｅ）ＮＢにおけるＬＩＰＡ／ＳＩＰＴＯを考えるが、本発明の同様のアプローチは、（ｅ）ＮＢにおけるマクロＳＩＰＴＯの場合にも容易に適用可能である。
【００４０】
本発明によれば、事業者は、特定のＵＥとの間の特定のトラフィックがＬＩＰＡ／ＳＩＰＴＯ経由でルーティングされるべきか、それとも事業者コアネットワーク経由でルーティングされるべきかを動的／フレキシブルに制御することができる。また、さまざまな課金方式を適用する目的で、ＬＩＰＡ／ＳＩＰＴＯトラフィックのサービス連続性をサポートする解決法およびサポートしない解決法が考えられる。また、事業者が完全な制御を行うために、ＵＥにとって完全に透過的な解決法が考えられる。
【００４１】
上記の目的は、コアネットワークへの複雑さの付加はわずかであるかまたは全くない状態で達成される。ＵＥにおける変更は最小限であり、本解決法が要求する変更は、あるとしても、単一の層、すなわちアプリケーション層またはネットワーク層における単純な変更だけである。
【００４２】
本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。
【図面の簡単な説明】
【００４３】
【図１】ネットワークアーキテクチャ全体を例示する模式図である。
【図２】事業者ＤＮＳによって処理されるＬＩＰＡ／ＳＩＰＴＯトラフィックを例示する模式図である。
【図３】新たなＨｅＮＢまたはｅＮＢへのハンドオフ後のダウンリンクトラフィックに対する可能なパスを例示する模式図である。
【図４】新たなＨｅＮＢまたはｅＮＢへのハンドオフ後のアップリンクトラフィックに対する可能なパスを例示する模式図である。
【図５】ＵＥとＤＮＳサーバとの間の直接通信を例示する模式図である。
【発明を実施するための形態】
【００４４】
以下の説明では、ＰＤＮとしてインターネットの場合を考える。このため、ネットワークプロトコルはＩＰとなり、ローカルネットワークプロトコルアクセスはＬＩＰＡとなり、選択ネットワークプロトコルトラフィック負荷軽減はＳＩＰＴＯとなる。しかし、以下の説明は、インターネットの場合への限定とみなしてはならない。提供される解決法は、他のＰＤＮに対しても有効である。その限りにおいて、他のＰＤＮも同様の考慮範囲に含まれる。
【００４５】
以下の実施形態は、ＤＮＳルーティングポリシーに基づく。まず、「Ｔｗｉｃｅ−ＮＡＴ」および「単純トンネリング」に基づく２つの解決法を説明する。両方の解決法とも、ＵＥがＬＩＰＡ／ＳＩＰＴＯおよび非ＬＩＰＡ／ＳＩＰＴＯのトラフィックに対して単一のＰＤＰコンテキスト／ＰＤＮコネクションのみを有するかまたはサポートする場合を考える（すなわち、これらの解決法は、複数のＰＤＰコンテキスト／ＰＤＮコネクションをサポートするＵＥをサポートすることもできることに注意すべきである）。もう１つの解決法では、ＵＥが複数のＰＤＰコンテキスト／ＰＤＮコネクションを有するかまたはサポートする場合を考える。この解決法では、事業者は、ＵＥからのＤＮＳクエリに対するＤＮＳリプライを通じて、特定のトラフィックに対してどのＡＰＮを使用すべきかをＵＥに明示的に指示する。
【００４６】
概要を示すため、これらの３つの解決法を以下に簡単にまとめる。
−  単一のＰＤＰコンテキスト／ＰＤＮコネクションに基づく解決法（複数のＡＰＮをサポートするＵＥにも適用可能）：
○  事業者ＤＮＳにおけるＤＮＳベースのルーティングポリシー：
・  事業者はＤＮＳ解決に基づいてトラフィック処理を制御する。ＬＩＰＡトラフィックに対するサービス連続性は、コアネットワークにおける複雑さの追加なしに（トラフィックがＰ−ＧＷへトンネリングされてから通常のＩＰルーティングに基づいてＬＰ−ＧＷへルーティングされる場合）、または、Ｓ−ＧＷにおけるわずかな複雑さの追加で（トラフィックがＳ−ＧＷによってＬＰ−ＧＷへ直接ルーティングされる場合）、以下のいずれかによりサポート可能である。
・  Ｔｗｉｃｅ−ＮＡＴ：
○  ＤＮＳ解決が、宛先ＩＰアドレス（ＤｅｓｔＮＡＴ）をＵＥに与え、事業者ネットワークにおけるそのアドレスへのトラフィックが（設定に基づいて）ＬＰ−ＧＷへルーティングされ、ＬＰ−ＧＷがＴｗｉｃｅ−ＮＡＴを実行する。ここで、トラフィック処理はＵＥにとって透過的である。
・  単純トンネリング：
○  ＤＮＳ解決が、要求側ＵＥにＬＰ−ＧＷアドレスを通知し、ＵＥは、ＬＩＰＡ／ＳＩＰＴＯ経由で送信すべきフローの単純ＩＰ−ｉｎ−ＩＰトンネリングのためにそのアドレスを使用することができる。ＵＥは、単純な追加機能を必要とするが、その決定に関与してもよい。単純トンネリングの代わりに、ＩＰｖ６におけるソースルーティングおよびルーティングヘッダも使用可能である。
−  複数のＰＤＰコンテキスト／ＰＤＮコネクションに基づく解決法（ＤＮＳベース）：
・  事業者はＤＮＳリプライに基づいてトラフィック処理を制御する。ＤＮＳリプライは、特定のＩＰフロー／コネクションに対してどのＡＰＮを使用すべきかをＵＥに指示する。ＵＥは、わずかな追加機能を必要とするが、決定プロセスに関与してもよい。ＬＩＰＡ／ＳＩＰＴＯトラフィックに対するサービス連続性は、この解決法でサポートされる。
【００４７】
以下の説明は、主にＨ（ｅ）ＮＢにおけるＳＩＰＴＯを対象とするが、同じ解決法は、マクロ（ｅ）ＮＢにおけるＳＩＰＴＯの場合にも適用可能である。
【００４８】
１．ネットワークアーキテクチャ
図１は、想定されるアーキテクチャの主要構成要素、すなわち、ＳＩＰＴＯ対応ドメインまたはＰＤＮ（例えばインターネット）、コアＤＮＳサーバ、ＭＭＥ（Mobility Management Entity, モビリティ管理エンティティ）、（Ｈ）ｅＮＢ（あるいは３Ｇでは（Ｈ）ＮＢ）、ＵＥ、コアＰ／Ｓ−ＧＷ（あるいはＧＰＲＳではＧＧＳＮ／ＳＧＳＮ）、および（Ｈ）ｅＮＢ／（Ｈ）ＮＢと共同配置されるローカルゲートウェイ（ＬＰ−ＧＷという）を示している。
【００４９】
説明を簡単にするため、明細書および図面ではＥＰＳアーキテクチャ（すなわち（Ｈ）ｅＮＢ、Ｓ−ＧＷ、Ｐ−ＧＷ）のみを示す。考え方は、ＧＲＰＳアーキテクチャ（すなわち、（Ｈ）ＮＢ、ＲＮＣ、ＳＧＳＮ、ＧＧＳＮ）にも等しく当てはまる。ローカルゲートウェイは、（Ｈ）ｅＮＢ／（Ｈ）ＮＢと共同配置されなくてもよい。
【００５０】
本明細書において、２つのタイプのＵＥが考慮される。ＬＩＰＡ／ＳＩＰＴＯおよび非ＬＩＰＡ／ＳＩＰＴＯの両方のトラフィックに対して単一のＰＤＮコネクション（１つのＩＰアドレスを有する）を使用するＵＥと、複数のＰＤＮコネクション（例えば、ＬＩＰＡ／ＳＩＰＴＯ専用に少なくとも１つ）を使用するＵＥである。
【００５１】
（Ｈ）ｅＮＢと共同配置されるローカルゲートウェイ（ＬＰ−ＧＷまたはＬ−ＧＷまたはＴＯＦ）は、Ｐ−ＧＷの機能を有するローカルＰ−ＧＷ（例えば、ＵＥが複数のＡＰＮを使用する場合）または単純なＬ−ＧＷ（すなわち、必要なＰ−ＧＷ機能のみを有する）のいずれでもよい。
【００５２】
２．ＬＩＰＡ／ＳＩＰＴＯトラフィック制御
想定されるメカニズムにおいて、どのトラフィックがマクロネットワーク経由で処理され、どのトラフィックがＬＩＰＡ／ＳＩＰＴＯ経由で負荷軽減されるべきかに関する決定は、コアＤＮＳ解決を通じて事業者によって行われる。
【００５３】
図２は、ＤＮＳがＳＩＰＴＯ／ＬＩＰＡトラフィック処理にどのように関与するかを示す。ここでは、ＵＥが自宅で（すなわち、ローカルＧＷが共同配置されたＨｅＮＢ経由で）ＹｏｕＴｕｂｅサーバに接続しようとしている場合を考える。ＤＮＳプロキシはローカルＧＷにあると仮定する。
【００５４】
最初に、ＵＥは、コアＤＮＳサーバへ、ＹｏｕＴｕｂｅサーバのＩＰアドレスを要求するＤＮＳ要求を発行する。ローカルＧＷにあるローカルＤＮＳプロキシは、ＤＮＳ要求をインターセプトし、それを事業者ＤＮＳサーバへ転送する。ＤＮＳ要求に応答して、事業者ＤＮＳサーバは、相手側（ＹｏｕＴｕｂｅ）のＩＰアドレスと、トラフィックがどのように処理されるべきかを指示する追加情報（例えば図２の情報１）とを含むＤＮＳリプライを送信する。コアＤＮＳからのＤＮＳリプライに従い、ローカルＧＷは、リプライがＬＩＰＡ／ＳＩＰＴＯトラフィックを指示している場合のアクション１を行い、特定の情報２を含むＤＮＳリプライを送信する。
【００５５】
単純な「ＤＮＳベースのＬＩＰＡ／ＳＩＰＴＯ制御」の解決法（単純ソースＮＡＴと呼ぶ）は、以下の特徴を有する図２のステップに従って作用する。
【００５６】
・情報１：トラフィックが（ＬＩＰＡ／ＳＩＰＴＯまたはマクロ経由で）どのように処理されるべきかを指示するＬＩＰＡ／ＳＩＰＴＯフラグ。
・情報２：相手側（ＹｏｕＴｕｂｅ）のグローバルＩＰアドレス
・アクション１：このトラフィックはＬＩＰＡ／ＳＩＰＴＯに従うべきなので、相手側（ＹｏｕＴｕｂｅ）の外部ＩＰアドレスをローカルＧＷ（またはＨ（ｅ）ＮＢ）に保存する。
・アクション２：単純ソースＮＡＴを適用する。ローカルＧＷは、ＵＥのＩＰアドレスをローカルＧＷのアドレスに変換するエントリを自己のＮＡＴテーブルに追加する。
【００５７】
なお、重視されるべき点であるが、ここではＤＮＳ解決においてローカルＧＷにあるＤＮＳプロキシを考えているが、上記の簡単な変更により、ＤＮＳ解決はＥ２Ｅ（End-to-End, エンドツーエンド）方式でも実行可能である。
【００５８】
３．ＳＩＰＴＯトラフィックに対するサービス連続性のサポート
図３および図４は、ターゲット（Ｈ）ｅＮＢへのＵＥのハンドオフあるいはハンドオーバー時における、アップリンクおよびダウンリンクの両方のトラフィックに対するすべての可能なパスを示している。
【００５９】
最初に、ＵＥが単一のＡＰＮのみを使用する場合を考える。ダウンリンクトラフィックに対して２つの可能なパス、すなわち１Ｄおよび２Ｄがあり、アップリンクトラフィックに対して５つの可能なパス、すなわち１Ｕ〜５Ｕがある。ＬＩＰＡ／ＳＩＰＴＯがＩＰフローフィルタ（これは、ターゲット（Ｈ）ｅＮＢに対して、（ＰＣＲＦにより）動的に提供されても、（ＨＭＳ（HeNB Management System, ＨｅＮＢ管理システム）により）積極的に提供済みであってもよい）経由で処理される場合、アップリンクトラフィックはターゲット（Ｈ）ｅＮＢで分離することができる（すなわち、図４のパス１Ｕ）。
【００６０】
ＤＮＳベースのＬＩＰＡ／ＳＩＰＴＯ制御の解決法において、ターゲット（Ｈ）ｅＮＢは、ソース（Ｈ）ｅＮＢにおけるＤＮＳ解決中に行われた決定に関する情報を有していない。その結果、アップリンクトラフィックは、Ｐ−ＧＷで分離する（すなわち、図４のパス４Ｕ）。結果として、サービス連続性をサポートすることができない。というのは、相手側ノード（ＹｏｕＴｕｂｅサーバ）からは、ＵＥの異なるソースＩＰアドレス（すなわち、ＵＥのグローバル事業者ＩＰアドレス）が見えることになるからである。これはもちろん、モビリティアウェアアプリケーションの場合や、追加的なＩＰモビリティの解決法（例えばモバイルＩＰ）が、モバイルコアによって提供される機能の「上位で」使用される場合を除く。
【００６１】
進行中のＳＩＰＴＯ／ＬＩＰＡトラフィックに対するサービス連続性は、進行中のコネクションに対する分離ポイントが同一（すなわち、ソース（Ｈ）ｅＮＢのローカルＧＷ）のままである場合にのみサポート可能である。すなわち、ＵＥから（Ｈ）ｅＮＢにあるアンカーＬ−ＧＷへＵＬ（Uplink, アップリンク）トラフィックをルーティングし、（Ｈ）ｅＮＢにあるアンカーＬ−ＧＷからＵＥへＤＬ（Downlink, ダウンリンク）トラフィックをルーティングするためのメカニズムが必要とされる。これは、ダウンリンクおよびアップリンクのトラフィックが、パス１Ｄまたは２Ｄ、および２Ｕ、３Ｕまたは５Ｕをそれぞれ通るときに可能である。パス３Ｕは、Ｌ−ＧＷにおける追加的な実装レベルの機能（後述）により確立可能であり、Ｐ／Ｓ−ＧＷに複雑さを付加することはない。アップリンクにおいて、パス２Ｕおよび５Ｕは、リソース節減およびＥ２Ｅ遅延に関して、パス３Ｕよりも明らかに最適化されている。しかし、それぞれＳ−ＧＷまたはｅＮＢにおいて、Ｓ−ＧＷまたはｅＮＢがＳＩＰＴＯトラフィックを非ＳＩＰＴＯトラフィックから区別し、分離し、ソース（Ｈ）ｅＮＢへルーティングすることができるようにする追加機能を必要とする。ダウンリンクでは、パス２Ｄもより適正であるが、これは、ソースおよびターゲット（Ｈ）ｅＮＢにあるローカルＧＷ間の直接トンネルの確立、または、ソース・ターゲット（Ｈ）ｅＮＢ間のＸ２インタフェースを通じてのデータ転送に対するサポートのいずれかを必要とする。
【００６２】
以下、進行中のＳＩＰＴＯ／ＬＩＰＡトラフィックに対するサービス連続性を可能にするために必要なメカニズム／方法を説明する。
【００６３】
・Ｔｗｉｃｅ−ＮＡＴに基づくＳＩＰＴＯサービス連続性サポート：
この解決法では、ＳＩＰＴＯトラフィック処理は、以下の特徴を有する図２のステップに従う。
【００６４】
−  情報１：トラフィックが、ＳＩＰＴＯまたはマクロネットワーク経由でどのように処理されるべきかを指示するＳＩＰＴＯフラグ。
−  情報２：非ＳＩＰＴＯトラフィックの場合の相手側のグローバルＩＰアドレス。そうでない場合、ローカルＧＷのローカルＩＰアドレス（宛先ＮＡＴアドレス）。これは、マクロネットワーク内でルーティング可能であり、ＤｅｓｔＮＡＴと呼ばれる。
−  アクション１：ローカル宛先ＮＡＴアドレス（ＤｅｓｔＮＡＴ）を割り当て、それを相手側（ＹｏｕＴｕｂｅ）のグローバルＩＰアドレスと関連づける。
−  アクション２：Ｔｗｉｃｅ−ＮＡＴを実行する：ＤｅｓｔＮＡＴを相手側（ＹｏｕＴｕｂｅ）のグローバルＩＰアドレスに変換し、ＵＥのＩＰアドレス（ソースＩＰ）を外部ＮＡＴアドレスに変換する（ソースＮＡＴ）。
【００６５】
ＤｅｓｔＮＡＴ（これは、この解決法では、事業者ネットワーク内でソース（Ｈ）ｅＮＢへルーティング可能であると仮定される）およびソースＮＡＴを用いて、図３および図４にそれぞれ示すように、ダウンリンクおよびアップリンクのトラフィックがパス１Ｄまたは２Ｄ、および２Ｕ、３Ｕまたは５Ｕをたどることを強制することによって、ターゲットｅＮＢへのＵＥのハンドオフ時にＳＩＰＴＯトラフィックのサービス連続性を保証することができる。
【００６６】
アップリンクにおいて、パス３Ｕは容易に確立することができる。というのは、これは、Ｌ−ＧＷにおけるＴｗｉｃｅ−ＮＡＴ機能を必要とするだけであり、Ｌ−ＧＷは、ＤｅｓｔＮＡＴアドレスへ送信されたパケットをインターセプトしてＴｗｉｃｅ−ＮＡＴ動作を実行すればよいからである。パス２Ｕおよび５Ｕは、それぞれＳ−ＧＷまたはｅＮＢにおいて、ＳＩＰＴＯ／ＬＩＰＡに従う可能性のあるＰＤＮコネクションに対して、ＤｅｓｔＮＡＴアドレス範囲に基づいて、Ｌ−ＧＷ宛のトラフィックを検出するための追加機能を必要とする。そしてこのトラフィックは、ルーティング可能なＤｅｓｔＮＡＴアドレスに基づいて、ＰＤＮコネクションから分離され、Ｌ−ＧＷへ直接ルーティングされる。
【００６７】
ダウンリンクにおいて、パス１Ｄは、通常／標準準拠のパスをたどる。２Ｄの最適化は、Ｌ−ＧＷおよび／またはソース／ターゲット（Ｈ）ｅＮＢにおける追加機能に依拠する。これは、ソースおよびターゲット（Ｈ）ｅＮＢにあるＬ−ＧＷ間の直接トンネルの確立、または、ソース・ターゲット（Ｈ）ｅＮＢ間のＸ２インタフェースを通じてのデータ転送に対するサポートを行う。
【００６８】
インターネットサーバのＤｅｓｔＮＡＴアドレスは事業者ネットワーク内でルーティング可能なので、（Ｈ）ｅＮＢ、Ｓ−ＧＷまたはＰ−ＧＷは、進行中のコネクションのアンカーとなっているＬＰ−ＧＷへトラフィックをルーティングすることができる。Ｓ−ＧＷとＬＰ−ＧＷとの間のトンネルは、Ｓ−ＧＷによるハンドオーバーの直後に解放されてもよく、ある一定のアイドル時間後（すなわち、ある時間の間にトンネルを通るトラフィックがない場合）にＳ−ＧＷまたはＬ−ＧＷのいずれかによって解放されてもよい。これは、ＵＥとＬＰ−ＧＷとの間のＥ２Ｅ通信に影響を及ぼさない。Ｓ−ＧＷにおけるアップリンクトラフィックのルーティングは、ＬＰ−ＧＷのＩＰアドレス、すなわちＤｅｓｔＮＡＴに基づくからである。
【００６９】
ｅＮＢ／ＬＰ−ＧＷにＤＮＳプロキシを有する代わりに、ＤＮＳ解決は、ＵＥとＤＮＳサーバとの間で「エンドツーエンドで」行われてもよい。これに関して、ＤＮＳサーバは、実／グローバルＩＰｖ４アドレスをＤｅｓｔＮＡＴの一部として直接提供してもよい。図５を参照。
【００７０】
この解決法において、ＬＰ−ＧＷにおける宛先ＮＡＴ  ＩＰアドレスに対するアドレス空間が制限されてもよい。というのは、ＤｅｓｔＮＡＴは事業者ネットワーク全体でルーティング可能でなければならないからである。この制限は、ＩＰｖ４・ＩＰｖ６サポートの場合に、または、ＵＥのＩＰアドレスとともにＵＥのソース／宛先ポート番号を用いてＤｅｓｔＮＡＴを実行することにより、克服することができる。
【００７１】
ＳＩＰＴＯトラフィックに対するＤＮＳ結果のキャッシングを避けるため、ＤＮＳ応答は、適当な指示（例えばＳＩＰＴＯフラグ）を含むことが可能であり、これに基づいてＵＥはＤＮＳクエリの結果をキャッシュしないようにすることができる。別法として、ＳＩＰＴＯ対応ＡＰＮに対するＤＮＳキャッシングを完全に無効化してもよい。
【００７２】
・単純トンネリングに基づくＳＩＰＴＯサービス連続性サポート：
この解決法では、ＳＩＰＴＯトラフィック処理は、以下の特徴を有する図２のステップに従う。
【００７３】
−  情報１：トラフィックが、ＬＩＰＡ／ＳＩＰＴＯまたはマクロネットワーク経由でどのように処理されるべきかを指示するＬＩＰＡ／ＳＩＰＴＯフラグ。
−  情報２：非ＬＩＰＡ／ＳＩＰＴＯトラフィックの場合の相手側（ＹｏｕＴｕｂｅ）のグローバルＩＰアドレス。そうでない場合、次の２つのアドレス：マクロネットワーク内でルーティング可能なローカルＧＷのローカルＩＰアドレス、および、相手側（ＹｏｕＴｕｂｅ）のグローバルＩＰアドレス。
−  アクション１：新しいＤＮＳレコードにより、ローカルＧＷのＩＰ−ｉｎ−ＩＰトンネリングアドレスを含める。
−  アクション２：単純ソースＮＡＴ、すなわち、ＵＥがソース。
【００７４】
この解決法では、２つのアドレス（すなわち情報２）を指示するＤＮＳリプライから、ＵＥは、このＩＰコネクションがローカルＧＷ経由でＬＩＰＡ／ＳＩＰＴＯに従っていることを知り、単純ＩＰ−ｉｎ−ＩＰトンネルを用いてローカルＧＷアドレスへアップリンクトラフィックをトンネリングする。別法として、単純トンネリングメカニズムは、（例えばＩＰｖ６ルーティングヘッダに基づいて）ソースルーティングにより実現してもよい。この場合、ＵＥおよびローカルＧＷは、必要な機能を有していなければならない。ＵＥは、フローがトンネリングされるべきか否かを判定するために、コネクション／フローごとの状態を維持する。この情報は、ネットワーク層で保持することができるので、アプリケーション層にとって完全に透過的であることが可能である。新しい（Ｈ）ｅＮＢの再選択後、ＵＥは、次のＤＮＳ解決で新しいＬＰ−ＧＷアドレスを取得するために、自己のＤＮＳキャッシュをフラッシュする。
【００７５】
この解決法では、ＬＰ−ＧＷまたはローカルＧＷ（これは単純トンネリングのために使用される）のＩＰアドレスは事業者ネットワーク内でルーティング可能なので、ＳＩＰＴＯトラフィックのサービス連続性をサポート可能である。
【００７６】
この解決法では、ローカルＧＷのＩＰアドレスが事業者ネットワーク内でソース（Ｈ）ｅＮＢへルーティング可能であると仮定している。図３および図４にそれぞれ示すように、ダウンリンクおよびアップリンクのトラフィックがパス１Ｄまたは２Ｄ、および２Ｕ、３Ｕまたは５Ｕをたどることを強制することによって、ターゲットｅＮＢへのＵＥのハンドオフ時にＳＩＰＴＯ／ＬＩＰＡトラフィックのサービス連続性を保証することができる。
【００７７】
アップリンクにおいて、パス３Ｕは容易に確立することができる。というのは、これは、Ｌ−ＧＷにおける単純トンネリング機能を必要とするだけであり、Ｌ−ＧＷは、トンネルを終端し、ローカルネットワークまたはＰＤＮ内の最終宛先へトラフィックをルーティングすればよいからである。パス２Ｕおよび５Ｕは、それぞれＳ−ＧＷまたはｅＮＢにおいて、ＳＩＰＴＯ／ＬＩＰＡに従う可能性のあるＰＤＮコネクションに対して（Ｌ−ＧＷアドレス範囲に基づいて）Ｌ−ＧＷ宛のトラフィックを検出するための追加機能を必要とする。そしてこのトラフィックは、ＰＤＮコネクションから分離され、Ｌ−ＧＷへ直接ルーティングされる。
【００７８】
ダウンリンクにおいて、パス１Ｄは、（例えばＰ−ＧＷ経由の）通常／標準準拠のパスをたどる。２Ｄの最適化は、Ｌ−ＧＷおよび／またはソース／ターゲット（Ｈ）ｅＮＢにおける追加機能に依拠する。これは、ソースおよびターゲット（Ｈ）ｅＮＢにあるＬ−ＧＷ間の直接トンネルの確立、または、ソース・ターゲット（Ｈ）ｅＮＢ間のデータ転送に対するサポートを行う。
【００７９】
・複数のＡＰＮ（少なくとも１つはＬＩＰＡ／ＳＩＰＴＯ専用）を使用するＵＥに対するＬＩＰＡ／ＳＩＰＴＯサービス連続性サポート：
この解決法では、ＵＥは、相異なるＡＰＮで複数の確立されたＰＤＰコンテキスト／ＰＤＮコネクションを有し、少なくとも１つのＡＰＮがＬＩＰＡ／ＳＩＰＴＯ専用であると仮定される。事業者ＤＮＳは、ＵＥからＤＮＳクエリを受信すると、与えられたフローに対してどのＡＰＮを使用すべきか（下記のオプションを参照）を、好ましくはＥ２Ｅ方式でＵＥに指示する。結果として、ＵＥは、それに応じて、ＤＮＳクエリ内で、事業者によって指示されたＡＰＮが割り当てられたＰＤＮコネクションを使用する。ＬＩＰＡ／ＳＩＰＴＯトラフィックに対するサービス連続性もサポートされる。というのは、標準的なモビリティ手順により、ハンドオーバー中にＰＤＮコネクションが維持されることが保証されるからである。ダウンリンクおよびアップリンクのトラフィックは、それぞれ図３および図４に示すようなパス１Ｄおよび２Ｕをたどる。
【００８０】
この解決法では、ＤＮＳサーバは、設定されたＡＰＮを知っていなければならない。ＵＥは、（ＵＥが現在利用可能な）アクティブなＡＰＮをＤＮＳ要求の一部としてＤＮＳサーバに通知してもよい。ＤＮＳサーバは、さまざまなパラメータ／メトリックに基づいて規定される優先度順にＡＰＮのリストを推奨してもよい。ＤＮＳサーバは、ＬＩＰＡ／ＳＩＰＴＯが使用されるべきかどうかを指示するフラグを単に設定するだけでもよい。この場合、ＵＥは、事業者が設定可能な規約に基づいて、ＬＩＰＡ／ＳＩＰＴＯに対する適当なＡＰＮを自律的に識別することができなければならない。
【００８１】
ＤＮＳリプライに応答して、ＵＥは、推奨されたＰＤＮコネクション／ＡＰＮに関連づけられたＵＥのＩＰアドレスに、新しいＩＰフロー／コネクション（ソケット）をバインドする。ＵＥは、推奨されたＡＰＮに新しいＩＰフロー／コネクションを（アプリケーション層とは独立に）バインディングするプロセスに対して、単純なネットワークレベルの機能を必要とする。ＵＥは、決定プロセスに関与してもよい。
【００８２】
本明細書では、ＬＩＰＡ／ＳＩＰＴＯトラフィック制御を処理するための解決法を提案している。これらの解決法は、２つのタイプのＵＥ、すなわち、単一のＡＰＮ／ＰＤＮコネクションのみをサポートするＵＥと、少なくとも１つのＡＰＮをＬＩＰＡ／ＳＩＰＴＯ専用として複数のＡＰＮを（同時のＰＤＮコネクションとともに）サポートするＵＥとを考慮している。
【００８３】
すべての解決法は事業者のコアＤＮＳに基づいており、一部は、ダウンリンクおよびアップリンクのトラフィックの両方が、ＩＰフロー／コネクションをアンカーしている（Ｈ）ｅＮＢにあるローカルＧＷを通るように強制することによって、ＬＩＰＡ／ＳＩＰＴＯトラフィックのサービス連続性をサポートする。
【００８４】
上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。
【図１】
2013502190.tif 000003
【図２】
2013502190.tif 000004
【図３】
2013502190.tif 000005
【図４】
2013502190.tif 000006
【図５】
2013502190.tif 000007
【国際調査報告】
2013502190.tif 000008
2013502190.tif 000009
2013502190.tif 000010
2013502190.tif 000011
2013502190.tif 000012