JP2012161078A - サービス要求に応ずるサーバを決定する方法及び装置 - Google Patents

Abstract

【課題】サービス要求に応ずるサーバを決定する。
【解決手段】本方法は、ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を生成するステップ（１）と、前記サービスＤＮＳ要求をサービス移行に対応したサービスであるものとして特定するキーワードを前記ＤＮＳ要求内に挿入するステップ（１）と、前記ＤＮＳ要求をＤＮＳサーバに転送するステップ（２）と、前記ＵＲＩに追加された前記ロケーションの情報が示す前記移動デバイスのロケーションに基づいて、前記ＤＮＳサーバが、前記サービス要求に応ずる最適なサーバを決定するステップ（３）と、前記ロケーションに基づいて決定されたサーバのアドレスを前記移動デバイスに返すステップ（４）とを含む。
【選択図】図１

Description

本発明は、サービス要求に応ずるサーバを決定する方法に関する。本方法は、ユーザのロケーションに基づいた、名前解決（name resolution）及びサービスへの動的なアクセスに適用することができる。

ユーザの移動デバイスがあるサービスに接続しようとする場合には、その移動デバイスは、まず、当該サービスを提供するノードのアドレスを見いだす必要がある。これは、インターネットを介してアクセスされるサービスの場合には、ＤＮＳ（ドメインネームシステム）によって通常は行われる。ＤＮＳは、人間にとって意味のあるドメイン名を、世界中のネットワーク機器又はネットワークサービスを検索してアドレス指定するためにこれらの機器又はサービスに関連付けられている数値識別子へと変換するものである。ＤＮＳ要求に対応する、ネットワークエンティティの数値アドレス（ＩＰアドレス）を特定するプロセスは、ＤＮＳ解決と呼ばれている。ＩＭＳ（ＩＰマルチメディアサブシステム）も、多くの場合にＤＮＳを用いてサーバのアドレスを見いだす。

サービスを要求する移動デバイスが、訪問先ネットワークに接続されていて、ホームネットワークには接続されていない場合には、通常、ホームネットワークにおいて実行されているサービスへの接続が行われる。これは、ローミングに起因してコストが増加し、そのサービスを訪問先ネットワーク内で実行できる場合に必要となるネットワークサービスよりも多くのネットワークサービスが必要となるという点において不利である。したがって、このような場合、訪問先ネットワークへのサービスの移行が可能であるか、又はサービス移行がサポートされていない場合であっても、少なくとも、ローミングしているユーザにより近い場所でサービスを提供することが望ましい。

あるサービスを複数のロケーションが提供できる場合には、特定のユーザに最も適したサービスのアドレスを提供できる方法が望ましい。これは、ユーザのロケーション及びサーバ負荷等の要因によるものである。そのため、ＤＮＳによりサーバのアドレスを提供する際に、ＤＮＳは、ユーザを導く（direct）べきサーバを決めるために、ユーザのロケーションに関する情報を必要とする。ＤＮＳサーバに対してロケーションに関する情報を提供することができる場合には、最も良いサーバを決定して当該サーバのアドレスを提供する手順を用いてこのＤＮＳサーバを改良することもできる。厳密に言えば、このＤＮＳサーバは標準的なＤＮＳサーバではない。標準的なＤＮＳサーバはユーザのロケーションに基づいて最良のサーバを選択する機能を有していないため、本ＤＮＳサーバは、むしろ、異なったＤＤＤＳ（Dynamic Delegation Discovery System、動的委任発見システム）アプリケーションとみなすことができる。

ＥＰＣの３ＧＰＰ標準規格では、Ｓ−ＧＷ及びＰ−ＧＷの選択メカニズムはＤＮＳに基づいている（非特許文献１を参照されたい）。これらの選択メカニズムは、ＤＮＳ要求に対してＵＥのロケーションに関する情報、例えばＴＡＩ又はセルＩＤを利用する、ＭＭＥ内のＤＮＳサーバを用いる。これらのメカニズムは、動的委任発見システム（ＤＤＤＳ）（非特許文献２を参照されたい）に基づいている。ＤＤＤＳは、ＤＮＳのための大まかなバインディング（lazy binding）を可能とするものである。これは、これら特定のサーバの選択に限定され、これらのメカニズムがＭＭＥ内で行われることを要求するものである。他方、任意のＳＰＭ（service program mobility、サービスプログラムモビリティ）に対応したサービスを、移動体ネットワークの外部に存在している可能性のある任意のサーバへと導くためにＤＮＳが用いられることを可能にすることが望ましい。さらに、訪問先ネットワークからの特別なサポートを必要とせずに、これによってＳＰＭの展開（deployment）を簡単にすることが望ましい。

Ａｋａｍａｉ等のコンテンツ配信ネットワークは、ＤＮＳを用いて、ユーザのロケーションに基づき最良のロケーションにあるサーバにユーザを導く（非特許文献３を参照されたい）。しかし、Ａｋａｍａｉシステムは、多くのＤＮＳサーバを用いて、ユーザと様々なサーバとの間の遅延を推定することによってユーザのロケーションを求めることに基づくものである。より単純で実施が容易な手法が望ましい。

3GPP Technical Specification 29.303, Domain Name System Procedures, Stage 3 (Release 9) M. Mealling「Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS」（IETF RFC 3401, October 2002） Mukaddim Pathan及びRajkumar Buyya「A Taxonomy of CDNs」（Content Delivery Networks, R. Buyya, M. Pathan, and A. Vakali (Eds.), Springer-Verlag, Germany, 2008）

一実施形態によれば、移動デバイスからのサービス要求に応ずるサーバを決定する方法が提供される。本方法は、ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を生成するステップと、前記ＤＮＳ要求をＤＮＳサーバに転送するステップと、前記ＵＲＩに追加された前記ロケーションの情報が示す前記移動デバイスのロケーションに基づいて、前記ＤＮＳサーバが、前記サービス要求に応ずる最適なサーバを決定するステップと、前記ロケーションに基づいて決定されたサーバのアドレスを前記移動デバイスに返すステップとを含む。

これによって、サービスを要求した移動デバイスのロケーションに応じて最適なサーバを選択することができる。

また、前記ロケーションの情報は、当該移動体ネットワークの無線インターフェースによりブロードキャストされる情報に基づくものであるか、又は、前記移動デバイスのロケーションの情報は、移動体国コードＭＣＣと、当該ネットワークの移動体ネットワークコードＭＮＣと、前記移動デバイスが現在接続しているセルのＩＤとのうちの少なくともいずれかを含むかのいずれか又は両方の形態をとることもできる。

これによって、移動デバイスがロケーション情報を得ることができるようになり、その後、その移動デバイスはそのロケーション情報をサービス要求内に挿入することができる。

また、前記ロケーションの情報に基づいて、前記サービスを実行している複数のサーバの中で他のサーバよりも前記移動デバイスに近いサーバが選択されるか、又は、前記ロケーションの情報に基づいて、前記サービスを実行しているか又は実行することのできる複数のサーバの中から、前記移動デバイスが接続している訪問先ネットワーク内に位置し、かつ当該移動デバイスのホームネットワーク内には位置していないサーバが選択されるかのいずれか又は両方の形態をとることもできる。

近いサーバを選択することにより、接続の品質が向上し、コストを削減することができる。後者は、訪問先ネットワークからホームネットワークへのローミングを回避することができる場合にもあてはまる。

他の形態によれば、前記移動デバイスのロケーションの情報は、当該移動デバイスによって取得されて前記ＤＮＳ要求内に挿入されるか、又は、前記移動デバイスのロケーションの情報は、当該移動デバイスのロケーションの情報を認識しているネットワーク内のあるエンティティにより、又はそのエンティティから取得されるようにすることもできる。

移動デバイスがロケーションを取得することは好都合である。なぜならば、このとき、要求元がロケーション情報を直接入力することができるためである。あるいは、これが何らかの理由で可能ではない場合であっても、別のエンティティからロケーション情報を取得することによって後の段階でその情報を入力することもできる。

他の形態によれば、前記ロケーションの情報は、前記移動デバイスが直接接続しているネットワーク内のＤＮＳサーバが、当該情報を認識しているあるネットワークエンティティ、好ましくは３ＧＰＰのＳＡＥネットワーク内のＭＭＥ若しくはＨＳＳのいずれか又は両方、又は、これに相当する別の規格のエンティティ、例えばＨＬＲ若しくはＶＬＲのいずれか又は両方を参照することにより取得することができる。

これは、後の段階において、好ましくは移動デバイスが接続しているネットワーク内の第１のＤＮＳサーバがロケーション情報を取得する方法である。

他の形態によれば、前記移動デバイスのロケーションの情報は、要求されたサービスを特定するＵＲＩ内の１つ以上のサブドメインとして前記ＤＮＳ要求に含めることができる。

これは、ロケーションの情報に基づくリダイレクション（redirection、誘導）を可能にしつつ、当該情報が標準的なＤＮＳの動作を妨げないようにこの情報を含める特に効率的で好都合な方法である。

他の形態によれば、前記方法は、前記ＤＮＳ要求内にキーワードを挿入するステップを更に含むことができる。このキーワードは、前記サービスＤＮＳ要求をサービス移行に対応したサービスであるものとして特定するか、又は、前記ＤＮＳサービス要求を、前記移動デバイスのロケーションに基づいて、あるサーバへの前記ＤＮＳサービス要求のダイレクション（direction、誘導）を試みるべきサービスであるものとして特定するものである。

これによって、「標準的」又は従来のＤＮＳ要求と、ロケーション情報に基づくリダイレクションを試みるべきＤＮＳ要求との区別が可能となる。

他の形態によれば、前記方法は、前記移動デバイスのロケーションに応じて利用すべきサーバに関する情報を保存するサーバデータベースを用いるステップか、又は、前記最適なサーバを決定する際に、利用可能なサーバのロケーションに加えて、当該サーバの負荷をも考慮するステップかのいずれか又は両方を更に含む。

このようにして、ロケーション情報に基づいてデータベースを検索することにより最適なサーバを決定することができる。

他の形態によれば、前記方法は、前記ＤＮＳサービス要求が、前記移動デバイスのロケーションに基づいてダイレクションを試みるべきＤＮＳサービス要求として当該ＤＮＳサービス要求を特定するためのキーワード又はコードを含むか否かをＤＮＳサーバがチェックするステップと、前記移動デバイスのロケーションに基づくダイレクションを試みるべきと判断された場合には、前記移動デバイスのロケーションに基づいて選択される適切なサーバを決定するステップと、決定されたサーバのアドレスを前記移動デバイスに返すステップとを更に含む。

これによって、従来のＤＮＳサービス要求との下位互換性を確保しつつ、（キーワードに基づいて）要求された場合のリダイレクション処理が可能になる。

他の形態によれば、前記方法は、前記移動デバイスが訪問先ネットワーク内にある場合には、前記ＤＮＳ要求を前記移動デバイスのホームネットワークに転送するステップと、前記ホームネットワークと前記訪問先ネットワークとの間で、ホームネットワークサーバからのサービス移行を可能にして前記訪問先ネットワーク内のあるサーバ上で前記サービスを実行できるように交渉するステップと、前記交渉に成功した場合には、要求されたサービスを実行している前記訪問先ネットワーク内のサーバのアドレスを前記移動デバイスに返すステップとを更に含む。

このようにして、ロケーション情報を含むＤＮＳ要求をサービス移行のきっかけとすることができる。

他の形態によれば、前記方法は、前記移動デバイスが訪問先ネットワーク内にある場合には、当該訪問先ネットワークのＤＮＳサーバが、前記サービスを当該訪問先ネットワーク内のサーバ上で実行できるか否かを判断するステップと、必要に応じて、前記訪問先ネットワークと前記移動デバイスのホームネットワークとの間で、前記訪問先ネットワークにおいて前記サービスを実行する条件について交渉するステップと、前記訪問先ネットワーク内のサーバ上で前記サービスを実行できる場合には、当該サーバのアドレスを前記移動デバイスに返すステップとを更に含む。

このようにして、訪問先ネットワーク内のＤＮＳサーバがＤＮＳ要求を「インターセプト」して、当該訪問先ネットワーク内でサービスを実行しようとすることによって、標準的なＤＮＳ処理を回避することができる。

一実施形態によれば、移動デバイスからのサービス要求に応ずるサーバを決定する装置が提供される。本装置は、ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を生成するモジュールと、前記ＤＮＳ要求をＤＮＳサーバに転送するモジュールと、前記ＵＲＩに追加された前記ロケーションの情報が示す前記移動デバイスのロケーションに基づいて、前記ＤＮＳサーバが、前記サービス要求に応ずる最適なサーバを決定するためのモジュールと、前記ロケーションに基づいて決定されたサーバのアドレスを前記移動デバイスに返すモジュールとを備えている。

このようにして、本発明の一実施形態の装置（又はシステム）を提供することができる。

一実施形態によれば、本発明の一実施形態による装置とともに動作する移動デバイスを有する装置が提供される。本装置は、前記移動デバイスのロケーションの情報を、好ましくは前記移動デバイスが接続しているネットワークからブロードキャストされる情報に基づいて決定するモジュールと、前記移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を生成するモジュールとを備えている。

このようにして、本発明の一実施形態による移動デバイスを実施することができる。

一実施形態によれば、本発明の一実施形態による装置とともに動作するネットワーク内のＤＮＳサーバを有する装置が提供される。本装置は、ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を前記移動デバイスから受信するモジュールと、前記移動デバイスのロケーションに基づいてサーバを決定するモジュールと、前記ロケーションに基づいて決定されたサーバのアドレスを前記移動デバイスに返すモジュールとを備えている。

このようにして、本発明の一実施形態によるＤＮＳサーバを実施することができる。

上記装置は、本発明の実施形態による方法のうちの１つにおけるステップ又は特徴を実行する１つ以上のモジュールを更に備えていてもよい。

本発明の一実施形態によるリダイレクションの方法を概略的に示す説明図である。 本発明の他の実施形態によるリダイレクションの方法を概略的に示す説明図である。 本発明の他の実施形態によるリダイレクションの方法の一部を概略的に示す説明図である。 本発明の他の実施形態によるデータベースサーバを概略的に示す説明図である。 本発明の他の実施形態によるリダイレクションの方法を概略的に示す説明図である。 本発明の他の実施形態によるリダイレクションの方法を概略的に示す説明図である。 本発明の他の実施形態によるリダイレクションの方法の一部を概略的に示す説明図である。

まず始めに、以下の説明において用いられるいくつかの用語を説明する。
・ＣＳＣＦ：呼セッション制御機能（Call Session Control Function）
・ＤＤＤＳ：動的委任発見システム（Dynamic Delegation Discovery System）
・ＤＮＳ：ドメインネームシステム（Domain Name System）
・ＨＬＲ：ホームロケーションレジスタ（Home Location Register）
・ＩＭＳ：ＩＰマルチメディアシステム（IP Multimedia System）
・ＮＡＰＴＲ：名前付け権限ポインタ（Name Authority Pointer）（ＤＮＳリソースレコード）
・Ｐ−ＣＳＣＦ：プロキシＣＳＣＦ（Proxy CSCF）
・Ｓ−ＣＳＣＦ：サービスＣＳＣＦ（Serving CSCF）
・ＳＰＭ：サービスプログラムモビリティ（Service Program Mobility）
・ＵＥ：ユーザ機器（User Equipment）
・ＶＬＲ：ビジターロケーションレジスタ（Visitor Location Register）

１つの実施形態によれば、現在のネットワークにおいてＳＰＭ（サービスプログラムモビリティ）対応のアプリケーションを実施するための高速な移行パスを可能にする解決法が提案される。サービスプログラムモビリティは、大域的なサービス提供のための新しいパラダイムである。１つの実施形態によるシステムアーキテクチャは、事業者（operator）ドメインをまたがる動的なサービスコンポーネントの移行と、ローミングしているユーザに対してホームネットワークにいるときと同様の使用感（experience）をもたらすプラットフォームとを実現する。

ＤＮＳサーバにユーザのロケーションを通知するメカニズムと、この情報を用いてクライアントに返すサーバアドレスを判断するためのＤＮＳサーバの改良とがもたらされる。

このようなメカニズムは、スマートフォン用のアプリケーションとして実施することができ、ＳＰＭのサポートを有しない訪問先ネットワークにおいて機能しうる。

ＤＮＳサーバがユーザのロケーションを推定する最も簡単な方法は、要求の発信元のＩＰアドレスを用いることである。しかし、この手法にはいくつかの不利な点がある。ＤＮＳ要求が仲介ＤＮＳサーバから到着した場合、見えるのは仲介サーバのアドレスである。

ＩＰアドレスを用いることと比較した本発明の実施形態の１つの利点は、訪問先ネットワークにおけるＩＰアドレスの構成に対する依存が回避できることである。これは、例えば移動体ネットワークコードに基づいて移動デバイスのロケーションの情報（indication）を追加することによってなされる。移動体ネットワークコードはより不変であり、そのため必要な動作上の負担も低減する。第２の利点は、一実施形態において提案される手法によって、ＤＮＳサーバが、訪問先ネットワークから来る直接のクエリとは別のパスを通る要求もサポートできることである。これは特に、要求がホームネットワーク内のＳ−ＣＳＣＦから到着するＩＭＳに有用である。

１つの実施形態によれば、ＤＮＳが、ユーザのロケーションに関する情報に基づいてユーザ要求を利用可能な最良のサーバに導くことができるように、ＤＮＳを改良する方法が提供される。

この目的のために、ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、当該移動デバイスのロケーションの情報をも含むＤＮＳ要求が生成される。このＤＮＳ要求はＤＮＳサーバへと転送され、続いて、上記サービス要求に応じた最適なサーバがＤＮＳサーバにより決定される。この決定は、上記ＵＲＩに追加されているロケーションの情報が示すロケーションに基づいている。このように決定されたサーバのアドレスが当該移動デバイスへ返される。

一実施形態における移動デバイスのロケーションの情報には、移動体国コードＭＣＣ（mobile country code）と、そのネットワークの移動体ネットワークコードＭＮＣ（mobile network code）と、当該移動デバイスが現在接続しているセルのＩＤとのうちの少なくとも一つが含まれる。ロケーション情報に基づいて、次に、上記サービスが稼働している複数のサーバの中から、それら複数のサーバの中で他のサーバよりも上記移動デバイスに近いサーバが選択される。

一実施形態では、システムは主要かつ新たな２つの構成要素を有している。１つは、移動体ネットワークの無線インターフェースからブロードキャストされた情報（移動体国コードＭＣＣと、そのネットワークの移動体ネットワークコードＭＮＣと、セルＩＤとのうちの少なくとも一つなど）を取得し、この情報をＤＮＳによる解決の前にＵＲＩに追加する、ＵＥ（移動デバイス）内のソフトウェアコンポーネントである。もう一つは、ユーザのロケーションに基づいてどのサーバアドレスを返すかを決定する改良されたＤＮＳ（又はＤＤＤＳ）サーバである。特定の実施形態におけるＤＮＳサーバは、サーバにおけるソフトウェアコンポーネントの利用可能性、候補となる様々なサーバの現在の負荷、外部のサービスプロバイダとの通信結果といった追加の情報も用いることができる。利用可能なサーバの負荷を考慮する一実施形態によれば、例えばロケーションの観点で最も好ましいサーバの負荷がある閾値を超えている場合には、ロケーションの観点で次に好ましいサーバを、そのサーバの負荷が許容可能な場合に選択することができる。

提案の手法は、訪問先ネットワーク事業者によるサポートを必要とせずに機能するため、すべての事業者がＳＰＭを展開するのを待つ必要なく、ＳＰＭの高速な展開が可能となる。実際に、任意の他のエンティティ、例えばクラウドコンピューティングプロバイダ、ベンダー、海外データセンターの事業者によりサービスイネーブラ（service enabler）がもたらされうる。これによって、様々なベンダーからのサービスイネーブラとの不適合の問題を回避するための手法も可能となる。なぜならば、イネーブラを、ベンダー自体等の外部機関が提供することができるためである。

ユーザのロケーションを導き出すために要求元のクライアント又はＤＮＳサーバのＩＰアドレスのみを用いる場合と比較して、以下の利点がある。
・より正確なロケーション情報により、ホームネットワークにおける配置（placement）の最適化が可能になる。
・他のＤＮＳサーバ（例えば、グーグル社のＤＮＳサーバ 8.8.8.8）を使用するユーザに対してロバストになる。

以下、更なる実施形態をより詳細に説明する。そのためにまず、ＤＮＳの技術も更に説明する。

インターネットにおいてサーバアドレスを提供するためにＤＮＳが広く用いられている。そのため、ＤＮＳは例えばコンテンツ配信ネットワークにおいてサービスのルーティングを最適化するためのツールとしても用いられる。移動体ネットワーク事業者は通常、クライアントを最も適したサーバに導くために用いることのできる事業者自身のＤＮＳサーバを設けている。このサーバは、サービスを見いだすためにＤＮＳが用いられる多くの異なるシナリオにおいて利用することができる。例えば、Ｓ−ＣＳＣＦは、ＤＮＳを用いて特定のサービスコンポーネントのロケーションを要求することができる。しかし、ＤＮＳサーバは、クライアント毎に応答を提供するために、十分な情報の提供を受けなくてはならない。基本的なＤＮＳ要求は、要求元のクライアント又はプロキシのＩＰアドレスのみを含んでいるため、要求それ自体の中に追加情報を含めることが必要となるか、さもなければ、サーバのロケーションに基づくことになる。さらに、ＭＣＣ及びＭＮＣは非常に安定している一方で、ＩＰアドレスは割当てし直される場合があり、それにより、ＭＣＣあるいはＭＮＣを用いる場合と比較して、ＩＰアドレスをネットワーク又はロケーションへとマッピングできるようにするための更なる動作上の処理が必要となる。

したがって、一実施形態による解決法は、ＵＥのロケーション及び好ましくはサービスの詳細に関する情報を、ＤＮＳサーバに対して十分な情報を提供するためにＤＮＳ要求の中に含めることである。これは、例えば、無線インターフェースを介してブロードキャストされるセル情報及びネットワーク情報を用いることによって可能となる。このように情報を提供することの欠点は、この情報を追加するためにＤＮＳ要求に変更を施すことが必要となることである。しかし、ほとんどのスマートフォンのオペレーティングシステム及びデバイスは必要なインターフェースを提供するものであり、それによって、これをＳＰＭ対応アプリケーションにより実施することができる。したがって、スマートフォン用のＳＰＭサービスのための展開モデルは、アプリケーション開発者が用いることのできるＳＰＭ特有の機能を実施するライブラリを提供することとすることができる。しかし、既存のアプリケーション及びより制限されたオペレーティングシステムの場合には、このリダイレクション方法をサポートするのは容易ではない場合がある。そのため、この場合に解決法をどのように適用することができるかの一実施形態も以下に説明する。

クライアントがサーバに対して直接的に新たなサービスを要求する場合には、ＤＮＳによって（又は担当のＤＮＳサーバによって）リダイレクションを処理することができる。このセクションにおいて、ＤＮＳサーバというときは、リダイレクション機能としての役割を果たすか又はリダイレクション機能を提供する改良されたサーバを意味する。まず、ＤＮＳ要求が、ドメイン名に追加されたＵＥのロケーション情報を含む場合を説明する。この場合、ＤＤＤＳ法を用いるＤＮＳサーバは、ロケーション情報を直接用いて、ユーザを導くサーバを、サーバデータベースからの追加情報を用いて選択することができる。次に、ＤＮＳサーバは適切なＩＰアドレスを用いて応答し、クライアントはサーバに接続することができる。このことを図１に示している。次に、図１に示す動作を簡単に説明する。

図１は、訪問先ネットワークからのサポートを必要とせずにリダイレクションが行なわれる一実施形態を示している。

ＵＥは、アプリケーションの開始時に訪問先ネットワークに接続されている。ステップ１では、移動体国コード（ＭＣＣ）と移動体ネットワークコード（ＭＮＣ）とからなるＰＬＭＮ−ＩＤが、移動電話機のＯＳ（例えば、Ｓｙｍｂｉａｎ、Ａｎｄｒｏｉｄ等）のＡＰＩを通じて読み取られる。これは移動デバイスのロケーションの情報であり、「SPM.MCC.MNC.Servicename.DocomoDomain」という形式に変更されたＤＮＳ要求を生成するために用いられる。ここで、「ServiceName」というサービスは、移動体事業者であるドコモ社のドメイン（つまり、「Docomodomain」のサブドメインであるドメイン「ServiceName」）の下で提供されるものである。また、「MNC」及び「MCC」は２つのサブドメインによりＵＥのロケーションの情報を構成している。（最下位の）サブドメイン「SPM」は、サービス要求がＳＰＭ対応ネットワークによりサポートされうる（この実施形態にはあてはまらない）ことを示している。

ステップ２では、ＤＮＳによる解決が行われ、要求が訪問先ネットワークから（ドコモ社の）ホームネットワーク内のＤＮＳサーバへと転送される。

ステップ３では、「ＭＣＣ」、「ＭＮＣ」及びサービスの名称（「ＳｅｒｖｉｃｅＮａｍｅ」）に基づいて解決が行われる。そのために、ＵＥのロケーションに応じた適切な（外部）サーバのリストが保存されているサーバデータベースを参照することができる。（データベースを検索することにより、）適した（ホームネットワークから見て外部の）外部サーバが存在することが判明した場合、かつ当該サーバがサービスに必要な機能を有している場合には、ステップ４にてこのサーバのアドレスを含むＤＮＳ応答が返送される。このようにして、ホームネットワーク（ここではドコモ社のネットワーク）内のサーバよりもＵＥに近いか、又はローミングの必要がないかのいずれか又は両方である外部サーバのアドレスを決定し、ＵＥに返すことができる。

次に、ステップ５において、ＵＥはインターネットを通じてこの外部サーバへの接続を確立することができる。

サービスが、クライアントが接続する必要のあるサーバを複数有している場合には、複数のＤＮＳ要求が行われることになる。アプリケーションサーバは、追加のサーバに接続する必要がある場合には、その接続のために適切なサーバを見つけるべくＤＮＳ要求を行う。この第２のサーバを、クライアント識別情報又はＵＥのロケーションに基づいて選択する必要がある場合には、この情報はサーバに提供されなければならない。これは通常、アプリケーションの中で発生する。あるいは、移動体ネットワーク内のエンティティを用いて、必要な情報を提供することもできる。

ＤＮＳリダイレクションのために考慮すべき別の側面は、ドメイン名に関して権限のあるＤＮＳサーバ（authoritative DNS server）を誰が制御するかである。通常、これはサービスプロバイダである。サービスプロバイダはホームネットワークプロバイダとすることができるが、そうではなくてもよい。最も重要なケースは、ホームネットワークプロバイダがサービスプロバイダでもあるときである。ＳＰＭ対応サービスが、（少なくとも仲介である）ホームネットワーク事業者により提供されていないサービスについてもサポートされている場合には、ＤＮＳ解決要求は、ホームネットワーク事業者のＤＮＳサーバに導くことができる。

クライアントがローミングしている場合には、訪問先ネットワーク内のＤＮＳサーバが要求を受信するものと想定される（全てのデータトラフィックがホームネットワークを通じてルーティングされる場合には、そうとも限らない。しかし、その場合にはＳＰＭを展開することによる利得がない）。ＤＮＳクエリは、サービスを配置（place）する場所を決める、権限のあるＤＮＳサーバへと転送される。ここで、生じる可能性がある１つの厄介な問題（complication）は、訪問先ネットワーク内のＤＮＳサーバがＤＮＳ要求に対する応答をキャッシュし、以前の要求と同じサーバ内に同一の要求を配置することである。これは、ホームネットワークに対し、サービスの要求回数に基づいて配置を変更する機会が与えられないため問題である。したがって、ＤＮＳ応答のキャッシングは最小限にするのが好ましく、これは応答に関して優先度を設けることによって実現できる。

ＤＮＳに基づくリダイレクションの１つの側面は、訪問先ネットワークの協力を受けることなく展開できるということである。このことは、サービスを訪問先ネットワーク内に配置することができないものの、ユーザに近い、適切なロケーションに配置できることを意味する。図１はそのようなシナリオを示したものである。訪問先ネットワークはＳＰＭに特有の処理を一切行う必要がなく、標準的なＤＮＳ解決を行いささえすればよい。当業者には明らかなように、このシナリオが機能するには、ネットワークは、データトラフィックをホームネットワークに戻すようにルーティングするのではなく、当該トラフィックのローカルブレイクアウト（local breakout）をサポートする必要がある。

図２は、訪問先ネットワークもＳＰＭをサポートする一実施形態を示している。本実施形態は、訪問先ネットワークもＳＰＭをサポートしている場合の、図１の手順の変更形態とみなすことができる。本実施形態は、複数のシナリオにおいて手順をどのように用いることができるか、及びその手順がＳＰＭの段階的な展開をどのようにサポートするかを示すものである。

この場合、サービスを訪問先ネットワークに移動させるか又はホームネットワークにおいて実行するかと、サービスを訪問先ネットワークに移行させる追加の手順を開始するかとを判断する必要がある。したがって、ホームネットワーク及び訪問先ネットワークは、配置コントローラと呼ばれる追加機能を有している。これらのコントローラは、サービスを訪問先ネットワーク内に配置することに関して交渉することができる。これらの機能の必要性は、ＳＰＭが具体的にどのように実装されているかの詳細、例えばサービスを訪問先ネットワークにおいて常に実行することができるか否か、そして、訪問先ネットワークにおいてサービスコンポーネントが既に利用可能であるか否かに依存する。

次に、図２に示すプロセスを、特に図１に示したプロセスとの違いを説明しながら簡単に説明する。

ステップ１においてＤＮＳ要求にロケーション情報を追加した後に、訪問先ネットワークのＤＮＳサーバによりＤＮＳ解決が行われる。ＤＮＳ要求はホームネットワークへと転送される。要求されたサービスが既に移行されている場合（ネットワーク及び実施態様に依存する）、その要求は訪問先ネットワーク内で直接処理することができる。この事例については後に別の実施形態との関連で説明する。

ステップ３では、ＤＮＳ要求が解決され、訪問先ネットワークにおいてサービスを実行できる可能性を、場合によってはサーバデータベースを参照することによってチェックする。

ステップ３’では、ホームネットワーク内の配置コントローラが、訪問先ネットワーク内でサーバを実行できる可能性について訪問先ネットワーク内の配置コントローラと交渉する。これには、訪問先ネットワーク内でサービスを実行するための料金に関する交渉をも含めることができる。ここでも、サービスが訪問先ネットワーク内で利用可能である場合には、本ステップは必要ではない場合がある。

次に、ステップ４では、サーバアドレスがＤＮＳ応答として返される。次に、ステップ５では、ＵＥとこのサーバ（訪問先ネットワークサーバ）との間の接続が確立される。

改良されたＤＮＳサーバは、ＤＮＳ要求に含まれている文字列（ＵＲＩ）に基づいた検索手順を行うことができる。この手順を図３に示している。ＤＮＳサーバは、これがＳＰＭ対応サービスであることを検出した後に（この検出は、例えば図３の第１のチェックボックスに示しているように、ＤＮＳ要求の文字列内のキーワード（ｓｐｍ）に基づいて行うことができる）、サービス及びＭＣＣ、ＭＮＣに基づいて対象となるサーバの集合を絞り込む。これらの２つのステップの順序は、展開のシナリオに依存する。原則として、第１のステップにおいて可能な限りサーバの集合を絞り込むことが好ましい。そのため、サーバが通常、少ない一部のサービスしか提供できない場合には、まず図３に示すようにサービスに基づいて選択を行うことが好ましい。これは例えば、特定のベンダーのサービスイネーブラを選択しなくてはならないような場合である。あるいは、ほとんどのサーバがたいていのサービスを提供できる場合には、最初にＭＣＣ、ＭＮＣを用いて対象となるサーバの集合を絞り込むことが好ましい。

図３において、ＤＮＳサーバがサーバデータベースと通信することも見て取れる。このサーバデータベースの構造の一例を図４に（部分的に）示している。サーバの能力は、まず、ネットワークによって提供される一組のサービスに対応した長さを有するビットマスクで表すことができる。ここで、各ビットはある１つのサービスを表している。ネットワーク内で提供されるサービスが多いほど、例えばサポートされているＡＰＩ及びハードウェアリソースの観点からサービスに特化しない形式でサーバの能力を定めることが好ましい場合がある。したがって、データベースは、これらの特定のための方法の双方の列を含むように拡張することができる。ＭＣＣ、ＭＮＣの情報は、ロケーション、及びそのロケーションを所与として、どのサーバを要求されたサービスに用いることができるかに関する情報を提供する。サーバ事業者が該事業者のネットワークの部分ごとに異なるサーバを用いることを優先する場合には、いくつかのサーバに関してセルＩＤ、ロケーションの情報を設けることができる。サーバを制御するエンティティも含まれる（ここでは、サーバ利用の交渉のための制御装置に到達する方法に関する情報も含まれるべきである）。また、サーバアドレスも含まれるが、これは、サーバが異なる装置によって制御されている場合に交渉中に提供することができる。原則として、これによって、訪問先ネットワーク事業者は、ＵＥのロケーションがわかるので、プライベートＩＰアドレスを提供することも可能になる。

一実施形態によれば、ＵＥのロケーションがＤＮＳ要求に含まれていない場合、ネットワーク、すなわちＭＭＥ（Mobility Management Entity、移動性制御エンティティ）又はＨＳＳ（Home Subscriber Server、ホーム加入者サーバ）からの情報を用いてなおもロケーションを推定することができる。ＤＮＳクエリが第１のＤＮＳサーバにおいて（該サーバが接続されているネットワーク内で）この情報を用いて改良されている場合には、クエリは、ロケーション情報を有する端末から到来したのと同じに見え、ホームネットワークにおいて上記の実施形態において説明したのと同じＤＮＳ手順を行うことが可能となる。クエリは、この情報で、ホームネットワーク内のＤＮＳサーバによって、ＵＥがどのネットワークに接続されているかに関するＨＳＳからの情報を用いて改良することもできる。

ロケーション情報は、改良されたＤＮＳサーバによって、図３において説明した手順に入る前の処理段階としてネットワークに要求することができる。ローミングの場合には、ＭＭＥからロケーション情報を得ることは、それにより、権限のあるＤＮＳサーバがホームネットワークの制御下にない場合（すなわち外部サービスプロバイダ）であっても、その権限のあるＤＮＳサーバに全ての必要な情報が提供されるため、利点がある。あるいは、配置コントローラがロケーション情報を要求することもできる。配置コントローラにロケーション情報を要求させる動機づけは、配置コントローラがこの情報を必要とする機能であることにある。

図５は、ロケーションの情報がＤＮＳリゾルバ（DNS resolver）に加えられる、ＳＰＭ対応アプリケーションのない一実施形態を示している。

ステップ１では、ロケーション情報のないサービス要求が発行される。次に、ＤＮＳサーバは、当該サービスに関してＳＰＭが可能であるか否かをチェックする。ステップ２’では、ＭＭＥ又はＨＳＳの少なくとも一方からＵＥのロケーションの情報が得られる。

次に、サービスロケーションクエリが配置コントローラへ転送され（ステップ３）、この配置コントローラはそれに対応する応答を発行する（ステップ４）。このとき、これはサーバアドレス又はサービスのアドレスに相当し、ステップ５ではＤＮＳサーバが返す。次に、ステップ６では、返されたアドレスを有するサーバへの接続が確立される。

以下、ＩＭＳの場合のＤＮＳリダイレクションの適用について説明する。ＩＭＳにおいては、ＵＥからサービス要求が発行されると、Ｐ−ＣＳＣＦはユーザのホームネットワーク内のＳ−ＣＳＣＦ（サービスＣＳＣＦ）と通信する。次に、Ｓ−ＣＳＣＦは、セッションをアプリケーションサーバ（ＡＳ）へ導く。ＡＳを見つけるためには、Ｓ−ＣＳＣＦはＤＮＳを用いることができる。これにより、ＤＮＳリダイレクションがこの場合にも有用となる。しかし、これには、ＵＥのロケーションに関する情報がＤＮＳ要求の中に含まれることが必要であり、さもなければ、Ｓ−ＣＳＣＦのＩＰアドレスに基づいてサーバの選択を最適化する。呼（call）を確立するときに、発信元の端末は、ＩＭＳ信号の中にアクセスネットワーク技術及びセルＩＤを含めることができる。この情報は、ロケーションに応じた応答を得るためにＭＣＣとＭＮＣとセルＩＤとをＵＲＩに加えることによりＤＮＳ検索の際に用いることができる。そのため、ＤＮＳサーバの変更もＩＭＳが利用できる。

続いて、複合的な（composed）サービスへのアプローチの適用について説明する。多くのサービスが複数のコンポーネントにより構成されている。コンポーネントのそれぞれがＵＥにのみ接続されている場合には、これまでに説明した方法は各コンポーネントに対して個々に適用できる。しかし、サービスコンポーネントが互いに内部的に接続されている場合もある。この場合には、ＵＥに直接接続されているコンポーネントのみがＵＥのロケーションを考慮する必要がある。その他のコンポーネントは、相互に接続されているコンポーネントのロケーションを考慮しさえすればよい。後者の問題は、様々なサーバの静的なロケーションに関する情報しか必要とせず、そのため、ＵＥの（動的な）ロケーションをどのように考慮するかという問題とは無関係である。

以下、訪問先ネットワーク事業者がＳＰＭをサポートしている場合の、オプションの拡張を伴う一実施形態を説明する。この実施形態では、訪問先ネットワークのＤＮＳサーバは、自己のネットワーク内で実行することができるＳＰＭ対応サービスを検出するように構成されている。次に、ＤＮＳサーバは、ホームネットワークとの交渉を開始し、自己のネットワーク内でサービスを実行することを提案する。これは、サービスプロバイダが移動体ネットワーク事業者ではない場合にも機能するものである。そのため、移動体事業者は、外部のサービスプロバイダに対して、例えば追加収入を生み出すために、自己のサービス配信プラットフォームを動的に提供することができる。

図６は、要求をどのようにインターセプトすることができるか、及びサービスの配置に関する交渉を訪問先ネットワークからどのように開始することができるかに関する一実施形態を示している。

ステップ１は、これまでの実施形態に関して説明したものと同じである。次に、ステップ２では、ＤＮＳ解決要求を、ＮＤＳサーバが訪問先ネットワークにおいてインターセプトする。訪問先ネットワーク内のＤＮＳサーバが行う手順を図７に示している。インターセプトは、例えば図７に示しているように、要求内の最初の要素がｓｐｍであるということをそのきっかけとすることができる。これにより、ＤＮＳサーバは、要求をホームネットワークに転送するのではなく、その要求をインターセプトすることを認識する。次に、ステップ３では、例えば図７に示しているようにサーバデータベースを参照することにより、又は場合によってはデータベースに関連して、図６に示しているような配置コントローラを用いることにより、訪問先ネットワークにおいてサービスを実行できる可能性を調べる。

そのような可能性が存在しない場合には、要求がホームネットワークへと転送される（図７）。これに対し、訪問先ネットワークにおいてサービスを実行できる可能性がある場合には、図６のステップ３’と図７に示しているように、（例えば価格などの）条件についてホームネットワークとの間で（例えば各ネットワークの２つの配置コントローラの間で）交渉がなされる。

交渉に成功した場合には、訪問先ネットワークにおいてサービスが実行されることになるサーバのアドレスを含むＤＮＳ応答が送信され（ステップ４）、次にステップ５では接続が確立される。交渉が成功しなかった場合には、要求がホームネットワークに転送される。

本発明の実施形態に関連して説明した方法、要素、ユニット、及び装置は、ハードウェア、ソフトウェア、又は両者の組合せとして実施できることが当業者には容易に明らかとなろう。特に、本発明の実施形態及びそれに関連して説明したモジュールの要素は、コンピューター上で実行されているか又はマイクロプロセッサによって実行されている１つ以上のコンピュータープログラムによって実施できることが理解されよう。本発明を実施する任意の装置は、特に、ネットワーク内で動作するルーター、サーバ（特にＤＮＳサーバ）、モジュール等のネットワークエンティティ、又は移動電話機、スマートフォン、ＰＤＡ、ＵＥ、若しくは任意の同様のもの等の移動デバイスの形態をとることができる。

Claims (14)

1. ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を生成するステップと、
   前記サービスＤＮＳ要求をサービス移行に対応したサービスであるものとして特定するキーワードを前記ＤＮＳ要求内に挿入するステップと、
   前記ＤＮＳ要求をＤＮＳサーバに転送するステップと、
   前記ＵＲＩに追加された前記ロケーションの情報が示す前記移動デバイスのロケーションに基づいて、前記ＤＮＳサーバが、前記サービス要求に応ずる最適なサーバを決定するステップと、
   前記ロケーションに基づいて決定されたサーバのアドレスを前記移動デバイスに返すステップと
   を含む、移動デバイスからのサービス要求に応ずるサーバを決定する方法。
2. 前記ロケーションの情報は、当該移動体ネットワークの無線インターフェースによりブロードキャストされる情報に基づくものであるか、又は、
   前記移動デバイスのロケーションの情報は、移動体国コードＭＣＣと、当該ネットワークの移動体ネットワークコードＭＮＣと、前記移動デバイスが現在接続しているセルのＩＤとのうちの少なくともいずれかを含むか
   のいずれか又は両方である、請求項１に記載の方法。
3. 前記ロケーションの情報に基づいて、前記サービスを実行している複数のサーバの中で他のサーバよりも前記移動デバイスに近いサーバが選択されるか、又は、
   前記ロケーションの情報に基づいて、前記サービスを実行しているか又は実行することのできる複数のサーバの中から、前記移動デバイスが接続している訪問先ネットワーク内に位置し、かつ当該移動デバイスのホームネットワーク内には位置していないサーバが選択されるか
   のいずれか又は両方である、請求項１又は２に記載の方法。
4. 前記移動デバイスのロケーションの情報は、当該移動デバイスによって取得されて前記ＤＮＳ要求内に挿入されるか、又は、
   前記移動デバイスのロケーションの情報は、当該移動デバイスのロケーションの情報を認識しているネットワーク内のあるエンティティにより、又はそのエンティティから取得される、
   請求項１〜３のいずれか１項に記載の方法。
5. 前記ロケーションの情報は、前記移動デバイスが直接接続しているネットワーク内のＤＮＳサーバが、当該情報を認識しているあるネットワークエンティティ、好ましくは前記ネットワーク内のＭＭＥ若しくはＨＳＳのいずれか又は両方、又はＨＬＲ若しくはＶＬＲのいずれか又は両方を参照することにより取得するものである、請求項４に記載の方法。
6. 前記移動デバイスのロケーションの情報は、要求されたサービスを特定するＵＲＩ内の１つ以上のサブドメインとして前記ＤＮＳ要求に含まれるものである、請求項１〜５のいずれか１項に記載の方法。
7. 前記移動デバイスのロケーションに応じて利用すべきサーバに関する情報を保存するサーバデータベースを用いるステップか、又は、
   前記最適なサーバを決定する際に、利用可能なサーバのロケーションに加えて、当該サーバの負荷をも考慮するステップか
   のいずれか又は両方を更に含む請求項１〜６のいずれか１項に記載の方法。
8. 前記ＤＮＳサービス要求が、前記移動デバイスのロケーションに基づいたダイレクションを試みるべきＤＮＳサービス要求として当該ＤＮＳサービス要求を特定するためのキーワード又はコードを含むか否かをＤＮＳサーバがチェックするステップと、
   前記移動デバイスのロケーションに基づいたダイレクションを試みるべきと判断された場合には、前記移動デバイスのロケーションに基づいて選択される適切なサーバを決定するステップと、
   決定されたサーバのアドレスを前記移動デバイスに返すステップと
   を更に含む請求項１〜７のいずれか１項に記載の方法。
9. 前記移動デバイスが訪問先ネットワーク内にある場合には、前記ＤＮＳ要求を前記移動デバイスのホームネットワークに転送するステップと、
   前記ホームネットワークと前記訪問先ネットワークとの間で、ホームネットワークサーバからのサービス移行を可能にして前記訪問先ネットワーク内のあるサーバ上で前記サービスを実行できるように交渉するステップと、
   前記交渉に成功した場合には、要求されたサービスを実行している前記訪問先ネットワーク内のサーバのアドレスを前記移動デバイスに返すステップと
   を更に含む請求項１〜８のいずれか１項に記載の方法。
10. 前記移動デバイスが訪問先ネットワーク内にある場合には、当該訪問先ネットワーク内のＤＮＳサーバが、前記サービスを当該訪問先ネットワーク内のサーバ上で実行できるか否かを判断するステップと、
    必要に応じて、前記訪問先ネットワークと前記移動デバイスのホームネットワークとの間で、前記訪問先ネットワークにおいて前記サービスを実行する条件について交渉するステップと、
    前記訪問先ネットワーク内のサーバ上で前記サービスを実行できる場合には、当該サーバのアドレスを前記移動デバイスに返すステップと
    を更に含む請求項１〜９のいずれか１項に記載の方法。
11. ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を生成するモジュールと、
    前記サービスＤＮＳ要求をサービス移行に対応したサービスであるものとして特定するキーワードを前記ＤＮＳ要求内に挿入するモジュールと、
    前記ＤＮＳ要求をＤＮＳサーバに転送するモジュールと、
    前記ＵＲＩに追加された前記ロケーションの情報が示す前記移動デバイスのロケーションに基づいて、前記ＤＮＳサーバが、前記サービス要求に応ずる最適なサーバを決定するためのモジュールと、
    前記ロケーションに基づいて決定されたサーバのアドレスを前記移動デバイスに返すモジュールと
    を備えた、移動デバイスからのサービス要求に応ずるサーバを決定する装置。
12. 前記移動デバイスのロケーションの情報を、好ましくは前記移動デバイスが接続しているネットワークからブロードキャストされる情報に基づいて決定するモジュールと、
    前記移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を生成するモジュールと
    を備えた、請求項１１に記載の装置とともに動作する移動デバイスを有する装置。
13. ある移動デバイスから要求されたサービスを特定するＵＲＩに加えて、前記移動デバイスのロケーションの情報をも含むＤＮＳ要求を前記移動デバイスから受信することと、
    前記移動デバイスのロケーションに基づいてサーバを決定するモジュールと、
    前記ロケーションに基づいて決定されたサーバのアドレスを前記移動デバイスに返すモジュールと
    を備えた、請求項１１又は１２に記載の装置とともに動作するネットワーク内のＤＮＳサーバを有する装置。
14. 請求項２〜１０のいずれか１項に記載のステップ又は特徴を実行するモジュールを更に備えた請求項１１〜１３のいずれか１項に記載の装置。