减少通信服务器之间需要的存储器使用的系统和方法

摘要

一种通过控制SIP－隧道的建立来减少用于通信网络中使用会话发起协议SIP的服务器之间通信的存储器使用的布置和方法。将某事件包的单个SIP－隧道用于诸如资源列表服务器RLS(54)的请求服务器的一个实例与诸如像存在服务器(58)的应用服务器的一个实例之间的多个预订。然后使用(12)SIP－隧道在这两个实体之间发送所有的SIPNOTIFY消息以通过去除SIP所产生的开销来减少这两端的存储器使用。

说明书

相关申请的交叉引用

本申请是于2006年11月13日提交的第11/559203号美国专利申请的部分继续申请，本申请要求享有于2006年7月6日提交的第60/806656号美国临时申请的优先权，其公开内容在此引入以供参考。

技术领域

本发明涉及通信系统。更具体而言，并且不是通过限制的方式，本发明针对减少在通信网络的服务器之间进行通信的两端上的存储器使用的系统和方法。

背景技术

在诸如IP多媒体子系统(IP Multimedia Subsystem，IMS)网络之类的使用会话发起协议(Session Initiation Protocol，SIP)的通信网络中，使用SIP SUBSCRIBE消息来预订属于IMS网络中的用户的状态的改变。当用户状态(User state)改变时，从通知服务器发送SIP NOTIFY消息到预订用户。在IMS网络中，由于缩放的原因，存在多个SIP应用服务器(AS)，每个服务器服务域中的多个用户。用户到AS的某示例的分配由IMS网络来处理，且预订AS(Subscribing AS)不知道哪个通知AS(Notifying AS)包含用户状态。为了找到正确的通知AS，预订AS发送SUBSCRIBE消息到IMS核心网，该核心网又将该消息路由到正确的通知AS。

根据RFC3265，有可能使用事件标头(Event-header)的现有“id”参数，以便在一次对话中具有多个预订。但是，仍然需要大容量的存储器来存储SIP对话。一个原因是使用“id”参数意味着相同的对话中的预订必须共享相同的观察者和目标，原因在于除使用到和来自对话的标头之外没有办法标识它们。因此，这使得对于不同的观察者和目标的预订而言，不可能使用相同的对话。因此，必须在预订AS与通知AS之间建立多个SIP对话。在预订的有效期期间，这些对话被保持。对话可以在延长的时间段内存在，即使在预订的有效期期间，发送的NOTIFY消息的数目可能相当的小，。还常常存在对实时发送NOTIFY消息的需要。因此，不优选基于拉(pull-based)的解决方案。

以这种方式来处理的状态的示例是如IETF、3GPP和OMA标准所限定的Presence和XCAP文档修改。

现有的解决方案强制预订和通知AS为每用户和AS的预订对话保持一个状态。每个对话需要一些存储器使用。例如，假设在IMS域中有一百万个用户且每AS分配100000个用户，这意味着存在十个预订AS和十个通知AS。如果每个用户预订另一个用户，则将存在一百万个SIP对话。举例来说，如果每个对话需要每AS2K字节的基本存储器，则对于这些对话，将需要总共2G字节的存储器。如果假设每个用户预订十个其它用户，如资源列表服务器(Resource List Server，RLS)与存在服务器(Presence Server，PS)之间可能的情况一样，则将需要20G字节的存储器，如此类推。

因此，能够看出在RLS与存在服务器以及RLS/PS与不同XML文档管理服务器(XDMS)之间建立的会话数目可能非常高，并且使用的联系人(contact)越多，需要的会话就越多。在这种情况下，存储器使用是比每秒交易数目更大的问题，因为假设NOTIFY消息的频率将相当低。

在本领域中需要的是用于减少存储SIP对话所需的存储器量的系统和方法。本发明提供了这样的系统和方法。

发明内容

在一个实施例中，本发明提供了一种方法，通过该方法，将针对某事件包的单个SIP隧道用于资源列表服务器(RLS)的一个实例与诸如像存在服务器之类的应用服务器的一个实例之间的多个预订。于是使用SIP隧道在这两个实体之间发送所有的SIP NOTIFY消息以通过去除由SIP产生的开销来减少这两端处的存储器使用。

本发明减少所述系统中支持诸如RLS之类的SIP SUBSCRIBE探险者(exploder)的功能所需的SIP对话数目。由于每个SIP对话需要分配相当大数量的诸如存储器和磁盘空间之类的资源，本发明显著减少了所需硬件的量。本发明在大量联系人列表的情况下特别有价值，其中当使用标准化SIP信令时建立的会话的数目量非常大。本发明比现有的解决方案好得多地缩放，联系人列表的大小并不以与现有技术解决方案相同的方式显著地影响系统的尺寸确定。

一方面，本发明针对一种减少在通信网络中进行通信的第一和第二服务器中的存储器使用的方法。该方法包括在第一和第二服务器的实例之间建立对话；以及使用所建立的对话在第一和第二服务器的实例之间隧穿(tunnel)所有Notify消息。通过这种方式，减少了第一和第二服务器之间的对话数目以及相关联的存储器使用。

另一方面，本发明针对一种向多个应用服务器提供多个预订的请求服务器。该请求服务器包括从用户接收用于请求预订联系人列表中的多个资源的预订请求的装置；用于为联系人列表中的每个资源标识应用服务器的装置；用于发送预订请求到所标识的应用服务器的装置，该预订请求包括请求服务器支持隧穿的指示；以及用于从所标识的应用服务器之一接收指示所标识的应用服务器也支持隧穿的响应的装置。所述请求服务器还包括用于确定所标识的应用服务器是否已具有与第一应用服务器的现有隧道的装置；以及用于确定响应消息是否指示建立的隧道已存在于请求服务器与所标识的应用服务器之间的逻辑。如果建立的隧道尚未存在于请求服务器与所标识的应用服务器之间，则请求服务器建立新的隧道。如果建立的对话已经存在，则请求服务器使用现有已建立隧道来支持所请求的预订。

另一方面，本发明针对一种在通信网络中通过预订来提供资源给请求服务器的应用服务器。该应用服务器包括用于从请求服务器接收预订请求的装置，该预订请求包括该请求服务器支持隧穿的指示；以及用于确定应用服务器是否支持隧穿且如果支持，则确定隧道是否已存在于应用服务器与请求服务器之间的装置。该应用服务器还包括用于如果应用服务器不支持隧穿则发送第一类型的响应到请求服务器的装置；用于如果应用服务器支持隧穿且在应用服务器和请求服务器之间已经存在隧道则发送第二类型的响应到请求服务器的装置；以及用于如果应用服务器支持隧穿但是在应用服务器和请求服务器之间尚未存在隧道则发送第三类型的响应到请求服务器的装置。

附图说明

在下文中，将参考附图、通过示出优选实施例来详细地描述本发明的基本特征，在附图中：

图1是图示本发明的方法的第一示例性实施例的步骤的流程图；

图2是图示本发明的方法的第二示例性实施例的步骤的流程图，在该实施例中使用新的事件包来建立SIP隧道；

图3是图示本发明的方法的第三示例性实施例的步骤的流程图；以及

图4是本发明的系统的示例性实施例的简化框图。

具体实施方式

图1是示出了本发明的第一示例性实施例的步骤的流程图。在步骤11，在资源列表服务器(RLS)的一个实例与诸如像存在服务器之类的应用服务器的一个实例之间为某事件包(event package)建立单个SIPSUBSCRIBE对话。在步骤12，然后使用此对话来隧穿此单个对话内部的这两个实体之间的所有SIP NOTIFY消息以通过消除SIP所产生的开销来减少在这两端的存储器使用。本发明对于任何类型的SUBSCRIBE探险者和相应的NOTIFY服务器、或任何类型的具有面向另一应用服务器的多个预订的应用服务器是通用的。本实施例利用具有某些扩展的现有SIP协议，这种扩展引起一种解决方案：与现有“非隧道”服务器的向后兼容。

本发明减少在IMS网络中使用的存储器的量。每对预订AS和通知AS使用一个对话。单个对话被用来隧穿所有的NOTIFY消息。在其中IMS域中存在一百万个用户且每个用户预订另一个用户的上述实例中，当使用现有过程时，存在一百万个对话，这些对话将需要2G字节的存储器。本发明将对话的数量减少至仅100个对话，每个对话使用2K字节的基本数据。因此，总共仅需要200K字节的存储器。对于每个用户对话，需要额外的0.1K字节。因此作为如现有技术中每新预订增加2K字节的替代，本发明对于每个新的预订仅增加0.2K字节。

此外，本发明使用现有的IMS/SIP路由过程来找到通知AS。如果在这两个实例之间已经存在对话，则本发明通知预订AS：对于此特定预定，将在现有的“公共”对话中而不是在单独的对话中发送NOTIFY消息。

本发明还可以减少由于刷新过程而引起的SIP SUBSCRIBE消息的数目，原因在于在某些情况下，只有一个对话需要被刷新。因此，也节约了处理器资源。

图2是图示本发明方法的第二示例性实施例的步骤的流程图，其中，使用新的事件包来建立SIP隧道。在步骤21，用户设备(UE)发送SIPSUBSCRIBE请求到RLS实例以请求创建预订。在步骤22，RLS找到预订的目标，且在步骤23，RLS和该目标协商对SIP隧穿的支持。在步骤24，在用户代理客户端(User Agent Client，UAC)与用户代理服务器(UserAgent Server，UAS)实例之间创建SIP隧道。在步骤25，使用SIP隧道来发送与不同的预订有关的消息。

图3是图示本发明方法的第三示例性实施例的步骤的流程图。举例来说，把该应用服务器作为存在服务器，不过其它类型的应用服务器也同样可适用。在步骤31，UE发送SIP SUBSCRIBE请求到RLS实例以通过使用指向联系人列表的具体URI来请求创建到多个资源的预订。IMS核心网将该请求路由到RLS实例，在该RLS实例处将处理所述联系人列表。在步骤32，RLS解析所请求的联系人列表。在步骤33，RLS实例为联系人列表中的资源而发送SIP SUBSCRIBE请求到每个存在服务器(PS)以请求为该联系人列表中的每个资源创建一个后端预订。RLS将有关其支持SIP隧穿的能力的信息包括在请求中，并标识该请求RLS实例。此信息例如可以是诸如“x-sip-tunneling”的新标头。实际存在后端预订的协商也可以被包括在所述请求中，在这种情况下，还包括希望的预订届满时间和后端预订的唯一ID。

在步骤34，IMS核心网基于请求URI中的信息照常将每个SIPSUBSCRIBE请求路由到正确的PS实例。在步骤35，PS接收SIPSUBSCRIBE请求并通过检查“x-sip-tunneling”标头来检测RLS支持SIP隧穿的能力。在步骤36，确定PS是否也支持SIP隧穿。如果PS不支持SIP隧穿，则所述方法移到步骤37，在该步骤37PS发送指示PS不支持SIP隧穿的响应到RLS。例如，PS可以发送不包括“x-sip-tunneling”标头的响应。在步骤38，RLS照常继续并建立后端预订而不进行隧穿。应该注意到不支持SIP隧穿的外部PS将不识别SIP SUBSCRIBE请求中的“x-sip-tunneling”标头，所以在其响应中将不返回x-sip-tunneling标头。因此，RLS将建立正常的后端预订。

如果在步骤36确定PS支持SIP隧穿，则所述方法转到步骤39，在该步骤39PS确定它是否已具有与请求RLS的现有已建立隧道。这可以例如通过检查SIP SUBSCRIBE请求中的“联系人”标头值和针对客户端的现有隧道比较该联系人标头值与该客户端的地址来完成。如果PS有与该RLS的现有已建立隧道，则所述方法转到步骤41，在该步骤41PS创建并存储被请求的预订和面向RLS的现有已建立隧道之间的关系。在步骤42，PS发送响应到RLS并包括在RLS和PS之间已经存在有效预订的指示。然后RLS等待初始通知到达。在步骤43，使用现有的SIP隧道来在RLS和PS之间隧穿所有SIP NOTIFY消息。

在可替换实施例中，如果PS具有与此RLS的现有已建立隧道，则所述方法转到步骤44，在该步骤44PS用新创建的隧道来取代现有的隧道。如果能够成功地创建新的隧道，则PS还基于所包括的参数来创建存在预订并将该预定捆绑到所述隧道。PS返回200OK到RLS以指示隧道已经被创建。优选地，在预订专用标头中发送与预订相联系的任何错误以避免使不知道SIP隧穿的代理混淆。

如果在步骤39确定PS不具有与该RLS的现有已建立隧道，则如下所述PS不创建预订，原因在于RLS将创建新的SIP隧道并将预订捆绑到该隧道。该预订是临时的，并且仅仅被用于隧道协商和找到PS的实例。所述方法转到步骤45，在该步骤45PS向RLS返回指示PS支持SIP隧穿的响应。在一个实施例中，PS例如把“301永久性移动(301 MovedPermanently)”消息返回到RLS，该消息包括支持sip-tunneling的信息。例如，PS可以将标头“x-sip-tunneling”包括在到RLS的301响应消息中。PS任选地可以包括隧道当前不存在的指示。

在步骤46，RLS接收响应并识别到PS支持SIP隧穿。RLS可以利用被PS放置在301响应消息的联系人标头中的可选信息来确定隧道是否已经存在。可替换地，该响应可以不包括关于隧道存在的信息。作为替代，RLS可以针对RLS的现有隧道来检查联系人标头。如果隧道尚未存在，则所述方法转到步骤47，在该步骤47RLS创建隧道且只要任何RLS预订存在就保持该隧道，这需要面向该PS实例的后端预订(或直到系统被重新启动)。此SUBSCRIBE请求是例如使用被称为“presence.sip-tunneling”的新事件包来创建存在隧道的请求。此初始请求创建隧道并且还可以在具体标头中包括创建存在预订以避免额外信令的信息。“届满”标头包括所配置的“SIP隧道届满值”。

在这点上，RLS和PS这二者具有RLS实例与PS实例之间的预订对话关系。在该特定RLS/PS实例对之间创建的任何新预订将使用相同的建立的对话和相应的隧道。每当发送与预订相关的请求时，它都使用相应的隧道。在这种情况下标准SIP标头被用于与该隧道有关的信息，且具体标头和主体信息被用于与该预订相关的信息。

如果RLS接收到来自客户端的预订刷新请求，则RLS照常继续并刷新面向PS的预订。应该注意到如果现有对话的剩余时间短于接收到的预订的届满时间，则RLS仅刷新面向PS的SIP隧道预订。RLS可以以不同的方式来处理隧道的刷新，诸如：

1.自动刷新SIP隧道-在这种解决方案中，只要在RLS和PS之间存在任何预订，则RLS/PS通过使用可配置的届满时间(在RLS和PS这二者中是相同的)但不发送刷新消息来刷新SIP隧道。

2.当预订被刷新/创建时刷新SIP隧道-在这种情况下，当使用可配置的届满时间来创建/刷新后端预订时刷新SIP隧道。

3.明确地刷新SIP隧道-只要任何后端预订存在，则在RLS中使用单独的线程来刷新SIP隧道。当RLS希望刷新SIP隧道时，RLS不在刷新消息中包括“x-sub-data”标头。然而，当在后端预订中发生任何改变时，包括该x-sub-data标头。

RLS刷新后端预订并包括具体的后端预订的ID。如果只有SIP隧道要被刷新，则RLS不包括具体的后端预订的ID。

当XCAP的预订改变时，例如特别是如果XDMS和AS未被协同定位时，SIP隧穿功能也是非常有用的。还可以避免特定预订上的定时器的使用，仅仅在SIP隧道上使用定时器。

对于每个存在预订，具有单独的定时器是必要的，原因在于需要向客户端发送最终通知以指示预订已被终止。另外，存储器节省量将会大得多并会降低定时器复杂性。在一个实施例中，在PS中不使用定时器，原因在于当预订到时时，RLS终止所有后端预订。这种方法的缺陷在于在PS可能存在“悬挂”预订。然而，可以执行具体的清理(clean-up)线程来去除经过了届满时间的所有预订。

本发明达到的存储器节省量取决于联系人(即存在体(presentities))在不同的地址(处理器)上的分布。例如，从RLS的角度来看，如果所有联系人定位在相同的处理器上，则就达到了最大的存储器节约量。随着越来越多的联系人位于不同的处理器上，节省量越来越少。

以下部分提供了示例模式。在请求模式中，解决方案的基础是使用现有的SIP协议来找到具有少量扩展的存在服务器的正确实例，这些扩展产生了与现有的“非隧道”服务器的向后兼容的解决方案。使用被称为“x-sip-tunneling”的新标头来协商对SIP隧穿的支持。应该注意到如果它不是RFC的一部分，则不允许将所支持的标头用于专有的扩展。然而，如果将来需要，这能够作为扩展而被提出。有关发送请求的RLS实例(IP地址/端口)的信息照常被包括在预订请求的联系人标头中。

当找到存在服务器的实例时，RLS建立面向PS实例的隧道以使用RLS和PS服务器地址作为To/From(向/从)信息来创建SIP对话。由于这些消息中的信息不同于标准的存在事件包，所以优选使用例如被称为“presence.sip-tunneling”的新事件包。规定所述应用的原因在于它可以被用于若干应用(诸如从AS到XDMS的预订)并因此指出正确的应用是必要的。

有关具体预订的信息被包括在SIP SUBSCRIBE/SIP NOTIFY请求的具体标头中以及对这些请求的响应中。这意味着SIP请求包括与SIP隧道有关的信息以及与个别预订有关的信息。这样，可以在不影响任何代理的情况下，在端点应用(例如RLS与PS)之间交换信息。应该注意到代理必须能够基于请求中的IP地址/端口来处理标准路由。代理还必须能够处理新的事件包。还应该注意到请求/响应总是包括标识该具体预定的具体的“x-sub-data”。

SIP隧道预订请求。与使用隧道的预订有关的预订请求可以是刷新或终止请求，原因在于初始预订使用标准的存在预订。对于预订请求，RLS使用Request-URI和To标头中的接收到的联系人地址。RLS还在P-Asserted-Identity以及From标头中包括RLS实例(TP)的联系人地址。可替换地，在To、From、和P-Asserted-Identity中可以使用其它信息，然后通常仅在Request-URI和联系人(Contact)中使用联系人信息。预订请求还包括“presence.sip-tunneling”事件包，并优选使用具体的标头“x-sub-data”来传达有关预订的所有信息。例如，x-sub-data标头可以采取“x-sub-data：To＝a，From＝b，Expires＝x，sub-id＝y”的形式。这比对于每个参数使用一个标头提供了更加紧凑的格式。然而，作为替代，预订请求可以包括：

(1)具体的“x”标头，指示实际预订的To和From信息，即包括在第一存在预订中以把该请求路由到正确PS实例的信息。此信息例如对于故障查找是重要的。

(2)指示预订的希望届满值的“x-sub-expires”(如果预订被终止，则该值为“0”)。

(3)指示该具体预订的“x-sub-id”。

SIP隧道预订响应。除标准信息之外，SIP预订响应包括预订的具体信息。优选地，使用具体的标头“x-sub-data”来传达关于预订的所有信息。例如，x-sub-data标头可以采取“x-sub-data：To＝a，From＝b，Expires＝x，Response-code＝xxx sub-id＝y”的形式。可替换地，针对每个参数所述响应可以包括一个标头，诸如指示相关预订的“x-sub-id”、指示为预订所确定的时间的“x-sub-expires”、以及指示特定预订的响应代码的“x-sub-response”。

SIP隧道通知请求。与使用隧道的预订有关的Notify请求必须包括预订的具体标头以使得把该隧道保持为“不知道(unaware)”所述预订。Notify请求优选包括具体的标头“x-sub-data”，其中包括关于预订的所有信息。例如，x-sub-daa标头可以采取“x-sub-data：To＝a，From＝b，Sub-state＝xxx sub-id＝y”的形式。可替换地，所述响应可以对于每个参数包括一个标头，诸如指示该响应是与预订还是与隧道有关的“x-sub-id”、以及指示存在预订的状态的“x-sub-state”(等效于Subscription-State)。例如，如果x-sub-state声称“被终止”，则它向RLS指示存在服务器已经终止所述预订。

RLS和PS还必须存储为每个特定预订所独有的信息，该预订并不直接与SIP隧道(SIP对话)有关。根据多少数据与所述预订有关，所使用的存储器的量将会不同，但是与SIP隧道有关的存储器节省量仍是相同的。

图4是本发明的系统的示例性实施例的简化框图。用户设备(UE)51经由IMS核心网53发送SIP SUBSCRIBE请求消息52到RLS实例54以请求通过使用指向联系人列表的具体的URI来创建对多个资源的预订。RLS中的联系人列表解析器55解析所请求的列表。RLS中的SIPSUBSCRIBE生成器56经由IMS核心网把每个联系人的SIPSUBSCRIBE请求57发送到应用服务器。举例来说，这里图示了存在服务器(PS)58。SUBSCRIBE消息请求为联系人列表中的每个资源创建一个后端预订。RLS在请求中包括有关其支持SIP隧穿的能力的信息，并标识该请求RLS实例。此信息例如可以是诸如在“支持的”标头中的“sip-tunneling”之类的新值。

PS 58接收SIP SUBSCRIBE请求57并通过检查“支持的”的标头来检测RLS34支持SIP隧穿的能力。PS中的现有隧道确定单元59通过比较“联系人”标头值与存储在PS中的关于正在进行的预订的信息来确定它是否已具有与该请求RLS的现有已建立隧道。此信息可以存储在预订隧道关系数据库61中。如果PS不具有与此RLS的现有已建立隧道，则PS中的预订创建器62创建新的预订。关于该新预订的信息存储在预订-隧道数据库中。PS可以使用SIP SUBSCRIBE请求57中的“联系人”标头值来标识RLS实例，并存储将具体的预订捆绑到具体的RLS实例的信息。

PS 58经由IMS核心网向RLS 54返回具有标识新的或现有的预订的ID的响应。如果PS不具有与RLS 54的现有已建立隧道，则可以由SIP200 OK消息生成器64来生成200 OK响应63。如果PS具有与RLS的现有已建立隧道，则可以由SIP 301响应生成器66来生成301响应65。

RLS 54接收所述响应，且RLS中的现有的PS预订确定单元67通过检查所接收的响应来确定对此PS实例的预订是否已经存在。如果接收到了200 OK响应63，则RLS知道没有预订存在。如果接收到了“301”响应65，则RLS知道预订已经存在。如果预订不存在，则RLS中的预订-隧道关系创建器68使用200 OK响应消息的联系人标头中的信息来创建面向PS 58的特定实例的新的预订-隧道关系。RLS将该预订-对话关系本地存储在预订-隧道关系数据库69中，只要RLS预定存在的话。如果对该PS的此实例的预订已经存在，则RLS使用301响应消息的联系人标头中的信息来创建入局RLS预订与面向PS的已存在对话之间的预订-对话关系。RLS将该预订-对话关系本地存储在预订-隧道数据库69中，只要RLS预定存在的话。

RLS还返回指出此特定预订的具体预订-隧道关系的唯一ID。此信息可以被包括在额外路由标头中或在内部被包括在RLS所使用的附加标头中。

之后，在该特定RLS/PS实例对之间创建的任何新预订将使用相同的已建立的对话。

虽然已经在附图中图示并在前述详细说明中描述了本发明的优选实施例，但是应该明白本发明并不局限于所公开的实施例，而是在不背离本发明范围的情况下能够进行众多重新布置、修改和替换。本说明书意图包括落入由随附权利要求书所限定的本发明范围内的任何所有修改。