CN102624939A - 用于确定应当响应服务请求的服务器的方法与装置 - Google Patents

Abstract

本发明涉及用于确定应当响应服务请求的服务器的方法与装置。一种用于确定应当响应来自移动设备的服务请求的服务器的方法包括：生成DNS请求，该DNS请求包括标识所述移动设备所请求的服务的URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示；在所述DNS请求中插入关键字，该关键字把所述服务标识成能够进行服务迁移的服务；把所述DNS请求转发到DNS服务器；由所述DNS服务器确定响应所述服务请求的最适合的服务器，所述确定是基于由添加到所述URI的所述位置的指示所指示的移动设备的位置的；把基于所述位置而确定的所述服务器的地址返回给所述移动设备。

Description

用于确定应当响应服务请求的服务器的方法与装置

技术领域

本发明涉及用于确定应当响应服务请求的服务器的方法与装置。它可以用于基于用户的位置的名称解析和对服务的动态访问。

背景技术

当用户的移动设备连接到一种服务时，它首先需要找到提供该服务的节点的地址。对于在因特网上访问的服务，这一般是通过DNS(域名系统)解决的，该DNS把对人有意义的域名转换成与联网设备或服务关联的数字标识符，以便在全球范围内定位和寻址这些设备或者服务。标识对应于一个DNS请求的网络实体的数字地址(IP地址)的过程称为DNS解析。而且，IMS(IP多媒体子系统)也常常使用DNS来找服务器地址。

当请求服务的移动设备连接到受访网络而没有连接到归属网络时，通常要连接到在该归属网络中运行的服务。这有缺点：由于漫游增加了成本，而且需要比如果服务在受访网络中运行的话所需的更多网络服务。因此，期望在这种情况下允许服务迁移到受访网络，或者即使不支持服务迁移也至少提供更靠近漫游用户的服务。

如果服务可以从多个位置提供，则可以为具体用户提供最适当服务的地址的方法将是期望的。这依赖于例如用户位置和服务器负荷的因素。由此，当DNS用于提供服务器的地址时，它需要关于用户位置的信息来确定它应当把用户指向哪个服务器。如果可以为DNS服务器提供关于位置的信息，则它还可以利用确定最佳服务器并提供那个服务器的地址的过程来增强。严格地说，这将不是常规DNS服务器；更恰当地说它可以被看作不同的DDDS(动态授权发现系统)应用，因为常规DNS服务器不具有基于用户位置选择最佳服务器的智能。

在用于EPC的3GPP标准中，用于S-GW(网关)和P-GW的选择机制基于DNS(见3GPP技术规范29.303，域名系统过程，阶段3(版本9))。这些机制使用MME中的DNS服务器，该DNS服务器对于DNS请求使用关于UE位置的信息，例如TAI或者小区标识符(ID)。这些机制是基于动态授权发现系统(DDDS)(见M.Mealling，“Dynamic Delegation Discovery System(DDDS)Part One：TheComprehensive DDDS”，IETF RFC 3401，2002年10月)，这允许为DNS实现迟缓绑定。这限于对这些具体服务器的选择而且需要在MME中实现这些机制。但是，期望允许DNS用来把任何SPM(服务程序移动性)使能的服务指向可能位于移动网络外部的任意服务器。而且，期望不需要来自受访网络的特殊支持，这简化了SPM的部署。

例如Akamai的内容交付网络使用DNS基于用户的位置把该用户指向最佳定位的服务器(见Mukaddim Pathan与Rajkumar Buyya的“A Taxonomy of CDNs”，Content Delivery Networks，R.Buyya，M.Pathan与A.Vakali(Eds.)，Springer-Verlag，Germany，2008)。但是，Akamai系统是基于使用大量的DNS服务器和通过估计用户与不同服务器之间的延迟来测量用户的位置。期望更简单和容易实现的方法。

发明内容

根据一种实施例，提供了一种用于确定应当响应来自移动设备的服务请求的服务器的方法，所述方法包括：

生成DNS请求，该DNS请求包括标识所述移动设备所请求的服务的URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示；

把所述DNS请求转发到DNS服务器；

由所述DNS服务器确定响应所述服务请求的最适合的服务器，所述确定是基于由添加到所述URI的所述位置的指示所指示的移动设备的位置的；

把基于所述位置而确定的所述服务器的地址返回给所述移动设备。

这使得可以依赖请求服务的移动设备的位置选择最适合的服务器。

根据一种实施例，所述位置的指示是基于由移动网络的无线电接口所广播的信息，和/或

移动设备的所述位置的指示包括移动台国家代码MCC和/或网络的移动网络代码MNC和/或所述移动设备当前连接到的小区的ID。

这使得移动设备可以获得其随后可以插入服务请求中的位置信息。

根据一种实施例，基于所述位置的指示，在正在运行所述服务的多个可能的服务器中选择比所述多个服务器中的其它服务器更靠近所述移动设备的一个服务器，和/或其中

基于所述位置的指示，在正在运行或者能够运行所述服务的多个可能的服务器中选择位于所述移动设备连接到的受访网络中并且不在所述移动设备的归属网络中的一个服务器。

选择靠近的服务器增强了连接质量并且可以降低成本。如果从受访网络到归属网络的漫游可以避免的话，也可以降低成本。

根据一种实施例，移动设备的所述位置的指示由所述移动设备获得并插入到所述DNS请求中，或者

移动设备的所述位置的指示由或者从知道所述移动设备的位置的指示的某个网络实体获得。

由移动设备获得该位置是方便的，因为请求的源可以直接输入位置信息。作为替代，如果由于某种原因这不可能，则可以在后期阶段通过从不同的实体获得位置信息来输入该信息。

根据一种实施例，所述位置信息是由所述移动设备直接连接到的网络中的DNS服务器通过参考知道该信息的网络实体，优选地是3GPP SAE网络的MME和/或HSS，或者其它网络标准中的对应实体例如HLR和/或VLR，而获得的。

这是一种在后期阶段获得位置信息的途径，优选地是由移动设备连接到的网络中的第一DNS服务器来获得。

根据一种实施例，所述移动设备的所述位置的指示被包含到所述DNS请求中，作为标识所请求的服务的所述URI的一个或多个子域。

这是一种包含这种信息以使得其不干扰正常DNS操作同时使得可以基于位置信息重定向的特别有效和方便的途径。

根据一种实施例，所述方法还包括：

把一个关键字插入到所述DNS请求中，该关键字把所述服务标识成能够进行服务迁移的服务，或者

该关键字把所述服务标识成应当为其执行基于移动设备的位置把服务的DNS请求指向服务器的服务。

这使得“常规”或传统DNS请求与应当为其尝试基于位置信息的重定向的DNS请求之间能有区别。

根据一种实施例，该方法还包括：

利用服务器数据，该数据库存储关于依赖于所述移动设备的位置要使用哪个服务器的信息；和/或

在确定最适合的服务器时，除了可用服务器的位置之外，还考虑其负荷。

以这种方式，可以通过基于位置信息查找数据库来确定最适合的服务器。

根据一种实施例，该方法还包括：

由DNS服务器检验所述DNS请求是否包括把它标识为应当尝试基于移动设备的位置的指向的DNS服务请求的关键字或代码；

如果确定应当尝试基于移动设备的位置的指向，就确定基于所述移动设备的位置选择的适合服务器；

把所确定的服务器的地址返回给所述移动设备。

这使得如果被请求(基于关键字)的话能够进行重定向处理，同时确保与传统DNS服务请求的向后兼容性。

根据一种实施例，该方法还包括：

如果所述移动设备在受访网络中，则把所述DNS请求转发到所述移动设备的归属网络；

在所述归属网络与所述受访网络之间协商，以允许从归属网络服务器的服务迁移，在所述受访网络中的服务器上运行所述服务；

如果所述协商成功，则把所述受访网络中正在运行所请求的服务的服务器地址返回给所述移动设备。

以这种方式，包含位置信息的DNS请求可以触发服务迁移。

根据一种实施例，该方法还包括：

如果所述移动设备在受访网络中，则由所述受访网络的DNS服务器确定所述服务是否可以在所述受访网络中的服务器上运行；

如果必要的话，就在所述受访网络与所述移动设备的归属网络之间协商在所述受访网络中运行所述服务的条件；

如果所述服务可以在所述受访网络中的服务器上运行，则把所述服务器的地址返回给所述移动设备。

以这种方式，可以通过由所述受访网络中的DNS服务器“截接”所述DNS请求并尝试在所述受访网络中运行该服务来绕过常规的DNS处理。

根据一种实施例，提供了一种用于确定应当响应来自移动设备的服务请求的服务器的装置，所述装置包括：

用于生成DNS请求的模块，该DNS请求包括标识所述移动设备所请求的服务的URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示；

用于把所述DNS请求转发到DNS服务器的模块；

用于由所述DNS服务器确定响应所述服务请求的最适合的服务器的模块，所述确定是基于由添加到所述URI的所述位置的指示所指示的移动设备的位置的；

用于把基于所述位置而确定的所述服务器的地址返回给所述移动设备的模块。

以这种方式，可以提供实现本发明一种实施例的装置(或系统)。

根据一种实施例，提供了一种包括移动设备的用于与根据本发明一种实施例的装置一起操作的装置，包括：

用于确定所述移动设备的位置的指示的模块，优选地是基于由该移动设备所连接到的网络广播的信息；

用于生成DNS请求的模块，其中所述DNS请求包括标识所述移动设备要请求的服务的URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示。

以这种方式，可以实现根据本发明一种实施例的移动设备。

根据一种实施例，提供了一种包括网络中的DNS服务器的用于与根据本发明一种实施例的装置一起操作的装置，包括：

用于从移动设备接收DNS请求的模块，所述DNS请求包括标识所述移动设备要请求的服务的URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示；

用于基于所述移动设备的位置而确定服务器的模块；以及

用于把基于所述位置而确定的所述服务器的地址返回给所述移动设备的模块。

以这种方式，可以实现根据本发明一种实施例的DNS服务器。

相应地，所述装置还可以包括用于执行如在根据本发明实施例的任一种方法中限定的步骤或者实现在其中限定的特征的一个或多个模块。

附图说明

图1示意性地例示了根据本发明一种实施例的重定向方法。

图2示意性地例示了根据本发明另一种实施例的重定向方法。

图3示意性地例示了根据本发明另一种实施例的重定向方法的部分。

图4示意性地例示了根据本发明另一种实施例的服务器数据库。

图5示意性地例示了根据本发明另一种实施例的重定向方法。

图6示意性地例示了根据本发明另一种实施例的重定向方法。

图7示意性地例示了根据本发明另一种实施例的重定向方法的部分。

具体实施方式

首先，解释以下描述中要用到的一些术语。

CSCF-呼叫会话控制功能

DDDS-动态授权发现系统

DNS-域名系统

HLR-归属位置寄存器

IMS-IP多媒体系统

NAPTR-命名主管指针(DNS资源记录)

P-CSCF-代理CSCF

S-CSCF-服务CSCF

SPM-服务程序移动性

UE-用户设备

VLR-来访位置寄存器

eNB-演化节点B

根据一种实施例，提出了一种允许快速迁移路径在当前网络中实现SPM(服务程序移动性)使能应用的解决方案。服务程序移动性是用于全球服务供应的新范例。根据一种实施例的系统体系结构实现了跨运营商域和平台的动态服务部件迁移，以便为漫游用户提供与其在归属网络中所拥有的相同体验。

提供了一种通知DNS服务器关于用户的位置和DNS服务器增强的机制，以便使用这种信息决定把哪个服务器地址返回给客户。

这种机制可以实现为用于智能电话的应用并工作在不具有对SPM的任何支持的受访网络中。

DNS服务器估计用户位置最直接的途径是使用请求所来自的IP地址。但是，这种方法有一些缺点。如果DNS请求来自中间DNS服务器，则可见的是该中间服务器的地址。

与使用IP地址相比，本发明实施例的一个优点是它们避免了对受访网络中IP地址配置的依赖性。这可以通过，例如基于移动网络代码，添加移动设备的位置的指示来实现。移动网络代码更加稳定并因为减少了所需的操作努力。第二个优点是在一种实施例中所提出的方法令DNS服务器除来自受访网络的直接查询之外还支持通过其它路径的请求。这对于IMS特别有用，其中请求将来自归属网络中的S-CSCF。

根据一种实施例，提供了用于增强DNS的方法，使得其可以基于关于用户位置的信息把用户请求指向最佳可用服务器。

为此，生成DNS请求，所述DNS请求包括标识所述移动设备所请求的服务的URI(统一资源标识符)并且除了所请求的服务的URI之外还包括该移动设备的位置的指示。然后，该DNS请求转发到DNS服务器，并且随后由该DNS服务器确定响应所述服务请求的最适合服务器，所述确定是基于由添加到所述URI的所述位置的指示所指示的位置的。然后，所述所确定服务器的地址返回给移动设备。

在一种实施例中，移动设备的位置的指示包括移动台国家代码MCC和/或网络的移动网络代码MNC和/或所述移动设备当前连接到的小区的ID。基于所述位置的指示，在正在运行所述服务的多个可能的服务器中选择比所述多个服务器中其它服务器更靠近所述移动设备的一个服务器。

在一种实施例中，该系统包括两个主要的新部件：UE(移动设备)中的一个软件部件，该部件从移动网络的无线电接口取广播信息(例如移动台国家代码MCC和/或网络的移动网络代码MNC和/或小区ID)并在DNS解析之前把该信息添加到URI，还有一个新部件是修改后的DNS(或者说DDDS)服务器，该DDDS服务器基于用户的位置确定要返回哪个服务器地址。具体实施例中的DNS服务器还可以使用附加的信息，例如服务器上软件部件的可用性、不同候选服务器的当前负荷和来自外部服务提供商的协商结果。根据一种考虑可用服务器负荷的实施例，如果，例如，就位置而言最优选的服务器具有超过某个阈值的负荷，则可以选择就位置而言下一个优选的服务器，如果这个服务器具有可以接受的负荷的话。

所提出的方法不需要来自受访网络的运营商的支持就可以工作，由此允许SPM的快速部署，而不需要等待所有的运营商来部署。事实上，可以由任何其它实体，例如云端计算提供商、卖方或者运营商的海外数据中心，提供服务使能器。这还使得可以有一种可能的方法来避免与来自不同卖方的服务使能器的不兼容问题，因为使能器可以由例如卖方自己的外方来提供。

与只利用发出请求的客户或DNS服务器的IP地址来导出用户位置相比，实现了以下优点：

●更准确的位置信息允许归属网络中的放置优化

●针对使用其它DNS服务器的用户稳健(例如Google DNS服务器8.8.8.8)。

以下将稍微更详细地描述更多实施例。为此，首先也要稍微进一步解释一下DNS技术。

DNS广泛地用于在因特网中提供服务器地址。因此，它还用作用于在例如内容交付网络中优化服务路由的工具。移动网络运营商通常提供它们自己的DNS服务器，该DNS服务器可以用于把客户指向最适当的服务器。这可以在DNS用于服务发现的许多不同情况中使用。例如，S-CSCF可以使用DNS来请求特殊服务部件的位置。但是，为了提供特定于客户的应答，DNS服务器必须具有足够的信息。由于基本的DNS请求只包括发出请求的客户或代理服务器的IP地址，因此需要在请求本身当中提供附加的信息，否则它将基于服务器的位置。而且，MCC和MNC非常稳定，而IP地址却可以重新分配，与使用MCC/MNC相比，这将需要更多的操作努力来把IP地址映射到网络或者位置。

因此，根据一种实施例的解决方案是关于UE位置的信息及优选地还有服务细节都包括在DNS请求中，以便为DNS服务器提供足够的信息。例如，通过使用在空中接口上广播的小区和网络信息，这是可能的。这种提供信息的途径的缺陷是它需要DNS请求中的变化，以便添加这种信息。但是，大多数智能电话操作系统和设备都提供了所需的接口，因此这可以由SPM使能的应用来实现。因此，用于智能电话的SPM服务的部署模型可以是提供实现应用开发人员可以使用的、特定于SPM的功能性的库。但是，对于现有的应用和更有限的操作系统，支持这种重定向方法可能不是直接的，因此以下将描述对于这种情况如何应用该解决方案的一种实施例。

当客户直接从服务器请求新的服务时，重定向可以由DNS(或者由负责的DNS服务器)处理。在这部分中，当提到DNS服务器时，这意味这充当或者提供重定向功能的增强服务器。首先，考虑DNS请求包括添加到域名的UE位置信息的情况。在这种情况下，DNS服务器利用DDDS方法可以直接使用该位置信息来选择指引用户使用来自服务器数据库的附加信息的服务器。然后，所述DNS服务器将利用正确的IP地址响应，而且客户可以连接到该服务器。这在图1中进行了说明。现在简要解释图1中所示的操作。

图1示出了不需要来自受访网络的支持就可以执行重定向的一种实施例。

当应用开始时，UE连接到受访网络。在步骤1)中，由移动台国家代码成分(MCC)和移动网络代码成分(MNC)构成的PLMN(公用陆地移动网)-ID通过移动电话OS(例如，Symbian、Android，等等)的API(应用程序接口)被读取。这是移动设备的位置的指示而且用于生成修改后的DNS请求，其形式为SPM.MCC.MNC.ServiceName.DocomoDomain。在这里，服务“ServiceName”是在移动运营商Docomo的域下提供的(因此，域“ServiceName”作为DocomoDomain的子域)，MNC和MCC通过两个子域构成了UE位置的指示，而(最低级的)子域SPM指示服务请求可能被SPM使能的网络支持(在这种实施例中，情况不是这样)。

在步骤2)中，执行DNS解析，而且该请求被从受访网络转发到(Docomo)归属网络DNS服务器。

在步骤3)中，基于MCC/MNC和服务名称(ServiceName)执行解析。为此，可以参考服务器数据库，其中存储了依赖UE位置适合的(外部)服务器的列表。如果(通过查找该数据库)发现存在适合的外部服务器(在归属网络的外部)，而且如果该服务器具有服务必需的能力，则在步骤4)中发送回包含这个服务器地址的DNS应答。以这种方式，可以确定比归属网络(在这里是Docomo网络)中服务器更靠近该UE和/或使得不必漫游的外部服务器的地址并返回到该UE。

然后，在步骤5)中，UE可以建立通过因特网到这个外部服务器的连接。

如果服务包括多个客户需要连接到的服务器，则将构成多个DNS请求。如果应用服务器需要连接到附加的服务器，则它将构成找出要连到的正确服务器的DNS请求。如果这第二个服务器需要基于客户标识或者UE位置来选择，则这种信息必须提供给服务器。这将一般在应用内部发生。一种替代方案将是使用移动网络实体来提供所需的信息。

应当为DNS重定向考虑的另一方面是谁控制用于该域名的主管DNS服务器。一般来说，这将是服务提供商，可以是或者可以不是归属网络提供商。最重要的情况是当归属网络提供商也是服务提供商的时候。如果对于不被该归属网络运营商(至少作为中介)也应当支持SPM使能的服务，则DNS解析请求可以指向该归属网络运营商的DNS服务器。

如果客户在漫游，则可以假定受访网络的DNS服务器将接收该请求(如果所有的数据通信都路由通过归属网络时，这种假定可能不是真的。但是，在那种情况下，没有来自部署SPM的收益)。DNS查询将转发到主管DNS服务器，该DNS服务器将确定把所述服务放到什么地方。一种可能发生的复杂化是所述受访网络中的DNS服务器高速缓存对DNS请求的应答并在相同的服务器中放置与前一请求完全相同的请求。由于它将不会给予归属网络基于对所述服务的请求计数来改变放置的机会，因此这将是有问题的。因此，DNS应答的高速缓存优选地应当最小化，这可以通过在应答中提供偏好来实现。

基于DNS的重定向的一个方面是它不需要受访网络的合作就可以部署。这意味着服务不能放在该受访网络中，但是可以在靠近用户的一个适合位置。图1示出了这样一种情况。受访网络不必执行任何特定于SPM的操作，它仅需要执行标准的DNS解析。如对本领域技术人员显而易见的，对于要工作的情况，网络必须支持数据通信的局部中断，而不是把它路由回归属网络。

图2示出了一种实施例，其中受访网络也支持SPM。对于受访网络也支持SPM的情况，它可以被看作是图1过程的修改。它示出了该过程可以如何用在多种情况下并支持SPM的渐进部署。

在这种情况下，可能需要决定是把服务移动到受访网络还是在归属网络中运行它，并且启动把服务迁移到受访网络的附加过程。因此，在归属和受访网络中包括了一个称为放置控制器的附加功能。这些控制器可以协商在受访网络中放置所述服务。对这些功能性的需要依赖于SPM如何具体实现的细节，例如服务是否可以总是在受访网络中执行，还有服务部件是否总是可以在那里获得。

现在将简要解释图2中所例示的过程，尤其是通过解释与图1中所示过程的区别。

在步骤1)中的DNS请求中包括位置指示之后，由受访网络的DNS服务器执行DNS解析。DNS请求转发到归属网络。如果所请求的服务已经迁移了(这可以依赖于网络与实现)，则请求可以直接在该受访网络中处理。这种情况将随后结合另一种实施例解释。

在步骤3)中，可能通过参考服务器数据库，DNS请求将被解析，而且将检验在受访网络中运行所述服务的可能性。

在步骤3’中，归属网络的放置控制器与该受访网络的放置控制器协商在受访网络中运行所述服务的可能性。这可以包括协商在受访网络中运行所述服务的价格。同样，如果服务可以在受访网络中获得，则可能不需要这个步骤。

在步骤4)中，该服务器的地址作为DNS应答返回，而且在步骤5)中，建立UE与这个服务器(受访的网络服务器)之间的连接。

增强的DNS服务器可以使用基于在DNS请求中所提供的串(URI)的查找过程。这个过程在图3中例示。在DNS服务器已经检测到它是SPM使能的服务之后(这种检测可以例如从DNS请求串中的关键字(spm)进行，如图3中第一检验框所示)，它将基于服务和MCC/MNC缩小目标服务器的集合。这两个步骤之间的次序依赖于部署情况。原则上，在第一步中尽可能多地缩小服务器集合将是有吸引力的。由此，如果服务器典型地只能够提供所服务的小的子集，则首先基于该服务进行选择将是优选的，如图3中所例示的。这可能是例如如果例如必须选择来自特定卖方的服务使能器的情况。如果大多数服务器将能够提供大部分服务，则首先使用MCC/MNC缩小目标服务器的集合是优选的。

在图3中，还可以看到DNS服务器与服务器数据库交互。用于这种服务器数据库的建议结构在图4中(部分地)示出。服务器能力最初可能是位掩码，其长度对应于由网络提供的服务集的长度，每一位指示一个服务。当网络中提供更多服务时，以非特定于服务的方式定义该服务器能力可能是优选的，例如关于所支持的API和硬件资源。因此，对于这两种规范方法，数据库都可以扩展成包括列。MCC/MNC信息提供了关于位置及在给定该位置的情况下哪个服务器可以用于所请求的服务的信息。如果服务器运营商具有对于其网络的不同部分使用不同服务器的偏好，则小区ID/位置信息可以为有些服务器提供。还包括了控制服务器的实体(在这里还应当有关于为了服务器使用情况的协商如何获得控制组织的信息)。而且还包括服务器地址，尽管在服务器被不同组织控制的情况下这可以在协商的过程中提供。原则上，这还允许受访网络的运营商提供私有IP地址，因为它知道UE的位置。

根据一种实施例，如果对于DNS请求没有提供UE的位置，则仍然可以利用来自网络的信息，即，MME(移动性管理实体)或者HSS(归属用户服务器)，推断该位置。如果在(其所连接的网络中的)第一DNS服务器利用这种信息增强了该DNS查询，则该查询看起来将好像来自具有位置信息的终端一样，而且将有可能使用与在以上实施例中所描述过的归属网络中的相同的DNS过程。利用来自关于所述UE连接到哪个网络的HSS的信息，这还可以由归属网络DNS服务器利用这种信息来增强。

在进入图3所述的过程之前，可以作为预处理阶段由增强的DNS服务器从网络请求位置信息。在漫游情况下，对于从MME获得位置信息可能是有利的，因为那将向主管DNS服务器提供所有必要的信息，即使其不在归属网络(即，外部服务提供商)的控制之下。作为替代，放置控制器可以请求位置信息。令放置控制器请求位置信息的动机将是它是需要该信息的功能。

图5例示了这样一种没有SPM使能的应用的实施例，其中在DNS解析器中添加位置信息。

在步骤1)中，发出无位置信息的服务请求。然后，在DNS服务器中检验SPM对于所述服务是否可能。在步骤2’中，从MME和/或HSS获得UE位置信息。

然后，服务位置查询转发到放置控制器(步骤3)，该放置控制器又发出对应的响应(步骤4)。然后，这对应于在步骤5)中由DNS服务器返回的服务器地址/服务地址。然后，在步骤6)中，建立到具有所返回地址的服务器的连接。

以下将讨论在IMS的情况下DNS重定向的适用性。在IMS中，当服务请求从UE生成时，P-CSCF接触用户归属网络中的S-CSCF(服务CSCF)。然后，S-CSCF把该会话指向应用服务器(AS)。为了找到AS，S-CSCF可以使用DNS，这将使得DNS重定向对于这种情况也是有用的。但是，这将需要关于UE位置的信息包括在DNS请求中，否则它将基于S-CSCF的IP地址来优化服务器选择。在呼叫建立的时候，发源终端可以在IMS信令中包括接入网技术和小区ID。通过把MCC、MNC和小区ID添加到URI，以便得到依赖位置的响应，这种信息可以用在DNS查找中。由此，DNS服务器的修改也可以被IMS使用。

以下将讨论访问所构成的服务的适用性。许多服务是由多个部分构成的。如果每个部分都只连接到UE，则所描述的解决方案分别适用于每个部分。但是，服务部分还可以在内部彼此连接。在这种情况下，只有直接连接到UE的部分才需要考虑UE位置。其它部分只需要考虑它们与其互连的部分的位置。后一个问题只需要关于不同服务器的静态位置的信息，因此独立于如何考虑UE的(动态)位置的问题。

以下将描述一种在受访网络运营商支持SPM的情况下具有可选扩展的实施例。在这种实施例中，受访网络的DNS服务器配置成检测可以在其自己的网络中运行的SPM使能服务。然后，它可以启动与归属网络的协商，提供在其网络中运行该服务的机会。如果服务提供商不是移动网络运营商，这也将工作。由此，例如，为了生成附加的收入，移动运营商可以动态地向外部服务提供商提供其服务交付平台。

图6例示了这样一种实施例，如何截接请求以及协商从受访网络启动的服务放置。

步骤1与联系之前实施例所描述的相同。在步骤2)，DNS解析请求在受访网络中被DNS服务器截接。由该受访网络的DNS服务器实现的过程在图7中示出。截接可以被例如请求中的第一元素是spm的事实触发，如图7中所示。这使得DNS服务器认识到它不应当把该请求转发到归属网络，而是应当截接它。在步骤3)中，例如，通过参考图7中所示的服务器数据库或者通过使用如图6中所示的放置控制器，有可能联系数据库，调查在受访网络中运行该服务的可能性。

如果没有这种可能性，则请求被转发到归属网络(见图7)。但是，如果存在在所述受访网络中运行该服务的可能性，则(例如，在网络的两个放置控制器之间)与归属网络协商条件(例如，价格)，如图6的步骤3’中所示和图7中也示出的。

如果协商成功，则发送包含受访网络中可以在其上运行所述服务的服务器地址的DNS应答(步骤4)，然后在步骤5)中建立连接。否则，如果协商不成功，则将请求转发到归属网络。

对本领域技术人员来说，很显然，联系本发明实施例所描述的方法、元素、单元和装置可以在硬件中、在软件中或者作为二者的组合来实现。尤其将理解，本发明的实施例与联系其所描述的模块的元素可以由运行在计算机上或者被微处理器执行的计算机程序实现。实现本发明的任何装置可以具体采取网络实体的形式，例如路由器、服务器(尤其是DNS服务器)、在网络中作用的模块、或者诸如移动电话机、智能电话机、PDA、UE或任何类似的东西的移动设备。

Claims (14)

1.一种用于确定应当响应来自移动设备的服务请求的服务器的方法，所述方法包括：

生成域名系统DNS请求，该DNS请求包括标识所述移动设备所请求的服务的统一资源标识符URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示；

在所述DNS请求中插入关键字，该关键字把所述服务标识成能够进行服务迁移的服务；

把所述DNS请求转发到DNS服务器；

由所述DNS服务器确定响应所述服务请求的最适合的服务器，所述确定是基于由添加到所述URI的所述位置的指示所指示的移动设备的位置的；

把基于所述位置而确定的所述服务器的地址返回给所述移动设备。

2.根据权利要求1所述的方法，其中：

所述位置的指示是基于由移动网络的无线电接口广播的信息的，和/或

移动设备的所述位置的指示包括移动台国家代码MCC和/或网络的移动网络代码MNC和/或所述移动设备当前连接到的小区的标识符。

3.根据权利要求1或2所述的方法，其中：

基于所述位置的指示，在正在运行所述服务的多个可能的服务器中选择比所述多个服务器中其它服务器更靠近所述移动设备的一个服务器，和/或其中：

基于所述位置的指示，在正在运行或者能够运行所述服务的多个可能的服务器中选择位于所述移动设备连接到的受访网络中并且不在所述移动设备的归属网络中的一个服务器。

4.根据权利要求1或2所述的方法，其中：

移动设备的所述位置的指示是由所述移动设备获得的并且被插入到所述DNS请求中，或者

移动设备的所述位置的指示是由或者从网络的知道所述移动设备的位置的指示的某个实体获得的。

5.根据权利要求4所述的方法，其中，所述位置的信息是由所述移动设备直接连接到的网络中的DNS服务器通过参考知道该信息的网络实体，优选地是移动性管理实体MME和/或归属用户服务器HSS或者网络的归属位置寄存器HLR和/或来访位置寄存器VLR，而获得的。

6.根据权利要求1或2所述的方法，其中：

所述移动设备的所述位置的指示被包含到所述DNS请求中，作为标识所请求的服务的所述URI的一个或多个子域。

7.根据权利要求1或2所述的方法，还包括：

使用服务器数据库，该服务器数据库存储关于根据所述移动设备的位置要使用哪个服务器的信息；和/或

在确定最适合的服务器时，除了可用服务器的位置，还考虑可用服务器的负荷。

8.根据权利要求1或2所述的方法，还包括：

由DNS服务器检验所述DNS请求是否包括把它标识为应当尝试基于所述移动设备的位置的指向的DNS服务请求的关键字或者代码；

如果确定应当尝试基于移动设备的位置的指向，则确定基于移动设备的位置而选择的适合服务器；

把所确定的服务器的地址返回给所述移动设备。

9.根据权利要求1或2所述的方法，还包括：

如果所述移动设备在受访网络中，则把所述DNS请求转发到所述移动设备的归属网络；

在所述归属网络和所述受访网络之间协商，以允许从归属网络服务器的服务迁移，在所述受访网络中的服务器上运行所述服务；

如果所述协商成功，则把所述受访网络中运行所述所请求的服务的服务器的地址返回给所述移动设备。

10.根据权利要求1或2所述的方法，还包括：

如果所述移动设备在受访网络中，则由所述受访网络中的DNS服务器确定是否能够在所述受访网络中的服务器上运行所述服务；

如果必要，则在所述受访网络与所述移动设备的归属网络之间协商在所述受访网络中运行所述服务的条件；

如果能够在所述受访网络中的服务器上运行所述服务，则把该服务器的地址返回给所述移动设备。

11.一种用于确定应当响应来自移动设备的服务请求的服务器的装置，所述装置包括：

用于生成域名系统DNS请求的模块，该DNS请求包括标识所述移动设备所请求的服务的统一资源标识符URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示；

用于在所述DNS请求中插入关键字的模块，该关键字把所述服务标识成能够进行服务迁移的服务；

用于把所述DNS请求转发到DNS服务器的模块；

用于由所述DNS服务器确定响应所述服务请求的最适合的服务器的模块，所述确定是基于由添加到所述URI的所述位置的指示所指示的移动设备的位置的；

用于把基于所述位置而确定的所述服务器的地址返回给所述移动设备的模块。

12.一种包括移动设备的用于与根据权利要求11所述的装置一起操作的装置，包括：

用于确定所述移动设备的位置的指示的模块，该确定优选地是基于由该移动设备连接到的网络所广播的信息的；

用于生成域名系统DNS请求的模块，该DNS请求包括标识所述移动设备要请求的服务的统一资源标识符URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示。

13.一种包括网络中的域名系统DNS服务器的用于与根据权利要求11或12所述的装置一起操作的装置，包括：

用于从移动设备接收DNS请求的模块，该DNS请求包括标识所述移动设备要请求的服务的统一资源标识符URI并且除了所请求的服务的URI之外还包括该移动设备的位置的指示；

用于基于所述移动设备的位置而确定服务器的模块；以及

用于把基于所述位置而确定的所述服务器的地址返回给所述移动设备的模块。

14.根据权利要求11至13中任一项所述的装置，还包括：

用于执行如在权利要求2至10中任一项中限定的步骤或者实现如在权利要求2至10中任一项中限定的特征的模块。

Images