CN101483613A - 为呈现服务器提供QoS控制能力的方法和设备及其系统 - Google Patents

Abstract

本发明公开了一种用于为呈现服务器提供QoS控制能力的方法和设备以及支持QoS控制的呈现系统。所述用于为呈现服务器提供QoS控制能力的方法，包括步骤：接收SIP消息；基于QoS策略，将所述SIP消息分类；以及经过与所述QoS策略相符的预定时间后，发送分类后的所述SIP消息。本发明能够在考虑到QoS需求但不需要提高硬件的消息处理能力的情况下提高呈现服务的处理能力和服务质量保障能力。

Description

为呈现服务器提供QoS控制能力的方法和设备及其系统

技术领域

本发明涉及用于即时消息业务的呈现技术，更具体地，涉及一种用于为呈现服务器提供QoS(Quality of Service，服务质量)控制能力的方法和设备以及支持QoS控制的呈现系统。

背景技术

呈现技术对于多种应用来说是一种重要的手段。现在，呈现技术正逐步出现在除了即时消息之外的多种应用中。例如，

(注册商标)公司正在将呈现能力添加到Word、Excel、Outlook和其它应用之中。

(注册商标)公司已经将呈现能力添加到Lotus notes7.0中。可以预见呈现技术将越来越广泛地用在不同场景中。

图1中示出了传统的基于SIP(Session Initiation Protocol，会话发起协议)协议的呈现系统。图1所示的呈现系统支持3种主要操作：订阅、通知和发布。

如图1所示，基于SIP协议的呈现系统包括呈现实体103、呈现服务器101、和观察者(包括订阅者105和获取者107)。呈现服务器101是呈现技术得以实现的核心实体，是接收、存储和分发呈现信息以及分发观察者信息的功能实体，它可从多个呈现实体103获取呈现信息，并能根据信息模型确定的规则，把从一个或者多个呈现实体103接收到的呈现信息组合进一个单一文档；在系统可管理、用户隐私可保证的情况下，根据事先确定的规则，允许获取者107主动查询呈现信息或者允许订阅者105订阅呈现信息。

用户订阅呈现信息服务是指请求呈现服务器101在某种情况下自动将该用户关注的某些呈现信息发送过来。用户之间可以相互进行订阅。发出订阅请求的用户称为订阅者，被订阅的用户称为被订阅者。

图2示出了目前基于J2EE架构的呈现服务器101的实现结构。在图2中所示的Siplet是SIP服务小程序(SIP Servlet)的缩写。Siplet是一套API，它为SIP服务器定义了一套高层的扩展API。Siplet使得SIP应用可以采用servlet模型来部署和管理。它服从规范JSR116。JSR是Java community的标准化组织，有Sun、IBM、BEA等诸多厂商参加，116是规范的编号。

如图2所示，呈现服务器100的实现结构从下而上大致分为如下第一至三层：

第三层是SIP栈层250，它负责SIP协议的实现，包括网络连接的管理、SIP报文的解析、SIP事务层的基本处理。

第二层是Siplet容器层230，它是一种接口符合工业标准的代码模块，用于提供运行Java servlet所需的支持，例如创建和维护servlet的生命期。Java servlet容器的例子有，例如，Apache的Tomcat、IBM和BEA之类的公司的对应产品。

如图2所示，在第二层中包括如下单元：Siplet上下文管理单元226、Siplet管理单元227、消息Siplet关系单元228、定时器管理单元229、和会话/对话管理单元231，它们是现有典型的基于J2EE架构的呈现服务器中第二层所包括的结构单元。

图2中示出的各单元在非运行时情况下是静态的，彼此之间没有调用关系，当用户根据需要定义了其间的相互关系之后，才在运行时根据所述定义发生这些单元之间的相互调用。由于这些单元之间的实际调用关系对本发明的实现没有具体的影响，所以在此省略对其的描述。

Siplet上下文管理单元226可以实现为一个数据结构，以一定的格式存放有关SIP消息、SIP事务的信息。

Siplet管理单元227是对Siplet进行运行时管理的单元，这样的管理包括：创建，销毁等。

消息Siplet关系单元228用来管理所包含的SIP消息和Siplet之间的关系。消息Siplet关系单元228基于SIP消息中包含的目的地地址而将该消息和第一层(即，SIP应用/呈现应用层210)中支持的Siplet关联起来。

定时器管理单元229可以被叫做时钟服务单元，也有人将其称作计时器管理服务单元。可以通过该单元提供的接口来指定某一时刻或某一时间间隔产生Timer(定时器)事件，同时可以为这个事件注册事件监听器(一个被调用的方法/函数)。当Timer事件发生时，这个事件监听器就会收到通知，相应的方法/函数就会被调用。

利用定时器管理单元229提供的这种功能，开发者可以实现周期性执行的例程或者延迟特定时间段后执行的例程。J2SE(Java 2Standard Edition)和J2EE(Java 2 Enterprise Edition)的各种版本的实现(如IBM、BEA、SUN等)都在不同的层次提供了多种时钟服务，例如，基本的JDK包含的标准库中就有一个时钟服务，IBM和BEA联合推出的CommonJ规范中也包含了一个计时器管理服务。

在SIP协议中，会话和对话是有严格定义的两个概念。其中，对话代表了通信双方之间持续一段时间的对等SIP关系。一个典型对话的生命期就是从呼叫方拿起电话进行拨号开始，到双方中任何一方挂断电话为止的这段时间。对话是用SIP消息，例如对INVITE请求的2xx应答，来建立的。对话由呼叫标识符、本地tag(标签)和远程tag来标识。

在SIP协议中，会话特指多媒体会话。一个多媒体会话由一组多媒体发送者和接收者、以及从发送者到接收者的数据流构成。一个多媒体会议就是多媒体会话的一个例子。一个会话可能包含多个对话，对话只涉及到对等的两方，而会话可能涉及到多方。

从上面的定义可以看出，像呈现服务器101这样的SIP应用，它可能同时维护很多个对话，分别对应于与不同的用户交互序列，甚至对应于与同一个用户的多个交互序列。会话/对话管理单元231负责将进来和出去的SIP消息映射到会话和对话，从而能够利用会话和对话的信息完成对消息的处理。例如，对于一个进来的SIP请求消息，通过尝试匹配对话，可以判断这是一个发起对话的消息还是一个对话中的消息，从而采取不同的处理方式。例如，当负载高的时候，会把更多的资源用在完成已经开始的对话，而不是用于开启新的对话。再如，对于出去的消息，Siplet的代码可能只是要发送一个200Ok的应答消息，此时这个消息还是不完整的，通过匹配到对话，就可以利用对话中记录的路由信息来补全一些报文头部。

第一层是SIP应用/呈现应用层210，它包括一个或者一组SIPservlet，所述一个或者一组SIP servlet负责实现呈现服务器的核心功能。

这三层之间的接口都是工业标准的。Siplet接口是第一层和第二层之间的主要接口。每个SIP消息最终都要交给某个Siplet进行处理，Siplet通过对SIP消息的处理来实现一个呈现服务器的业务逻辑。第二层和第三层之间的接口是JAIN接口。这两个接口都是API接口。

在现有的呈现系统中，每个到来的呈现更新(发布)都产生将发送给所有观察者的多个通知消息。因此，对于每个呈现更新，离去的网络流量和CPU利用率都很高。目前，在具有图2所示的典型结构的呈现服务器中，进入的消息在第三层中被解析，通过第二层中提供的通道而直接到达第一层中的SIP servlet，外出的消息通过第二层提供的通道直接到达第三层，由第三层发送出去。也就是说，这种实现结构没有考虑不同消息的QoS需求以及对CPU利用率的影响。此外，现有的基于SIP的呈现服务器也不进行准入控制以防止CPU过载。因而，呈现服务器的处理能力和服务质量保障能力是非常有限的。

有时候，当具有很多观察者的呈现实体的状态改变时，由于要在短时间内处理大量的通知消息，从而将出现CPU利用峰值。这在某些情况下将导致CPU过载和重要消息丢失。事实上，不同应用总是有不同的QoS需求。例如，IP电话的响应延迟可能是几毫秒，即时消息的响应延迟可能是几秒，而基于呈现的协作应用的响应延迟可能是几分钟。

在Acharya等人的、2005年5月19日公布的、公布号为US2005/0105464A1的美国专利申请中公开了一种区别处理SIP消息以进行VoIP呼叫控制的方法和系统。在该专利申请中，公开了根据SIP消息的类型，将SIP消息分派到不同的队列，每个队列采样不同的服务速率。但是，该专利申请并非针对基于J2EE架构的呈现服务器的中间层实现的，并且其处理仅是单向的。

在Anders等人的、2006年11月2日公布的、公布号为WO06114135A1的专利申请中公开了一种在IP多媒体子系统中的消息处理方法和装置。该专利申请主要涉及一种IMS中多组件联动的机制，使得用户在进行Voice over IP和Video over IP这样的QoS要求高的IMS应用时可以不受呈现消息或即时消息这样的低QoS需求的消息的影响。为此，该专利申请提出了利用网络服务器NS记录高QoS需求的SIP会话的起始和结束，让呈现服务器这样的实体利用这一信息延迟报文的发送。因此，该专利申请要解决的技术问题在于如何保障高优先级VoIP应用的QoS，并且通过IMS系统各个单元间连动，牺牲低优先级应用来保障高优先级VoIP应用的性能，其并未涉及如何保障呈现服务器的QoS的问题。

因此，现有技术需要一种在考虑到QoS需求但不提高硬件的消息处理能力的情况下提高呈现能力的方法和系统。

发明内容

为了克服现有技术中存在的上述问题，本发明提出了一种用于为现有呈现服务器提供QoS控制能力的方法和设备以及支持QoS控制的呈现系统。

为了实现上述目的，提供了一种用于为呈现服务器提供QoS控制能力的方法，包括步骤：接收SIP消息；基于QoS策略，将所述SIP消息分类；以及经过与所述QoS策略相符的预定时间后，发送分类后的所述SIP消息。

为了实现上述目的，提供了一种用于为呈现服务器提供QoS控制能力的设备，包括步骤：QoS策略执行单元，用来获取和提供与接收的SIP消息有关的QoS策略；SIP消息分类单元，用来根据所述QoS策略执行单元提供的所述QoS策略，将所述SIP消息分类；以及SIP消息发送单元，经过与所述QoS策略相符的预定时间后，发送分类后的所述SIP消息。

为了实现上述目的，提供了一种支持QoS控制的呈现系统，包括：SIP应用/呈现应用实体，用于实现供用户使用的服务程序；Siplet容器实体，用于实现如权利要求1-8所述的方法，以为所述SIP应用/呈现应用实体提供服务；和SIP栈实体，用于实现SIP协议，以为所述Siplet容器实体提供服务。

通过使用本发明，能够在考虑到QoS需求和系统负载的情况下，提高现有呈现服务器的处理能力和服务质量保障能力。

附图说明

从下面结合附图的详细描述中，本发明将会更易于理解，其中，相同的附图标记表示相同的结构元素，并且，附图中：

图1是示出了传统的基于SIP的呈现系统的系统结构的图；

图2是示出了目前基于J2EE架构的呈现服务器的实现结构的框图；

图3是示出了根据本发明第一实施例的基于J2EE架构的呈现服务器的实现结构的框图；

图4是示出了根据本发明第一实施例的基于J2EE架构的呈现服务器的工作原理的图；

图5是示出了根据本发明第二实施例的基于J2EE架构的呈现服务器的实现结构的框图；

图6是示出了根据本发明第二实施例的基于J2EE架构的呈现服务器的工作原理的图；

图7示出了在根据本发明的Siplet容器层中处理SIP消息的最基本过程的流程图；

图8示出了在根据本发明的Siplet容器层中处理SIP消息的过程的细节的流程图；和

图9示意性地示出了可以实现本发明的实施方式的计算机系统的框图。

具体实施方式

在进行下面的详细描述之前，需要说明的是本发明意图提出一种实现QoS控制的呈现方法及使用该方法的呈现服务器的架构，而非意图将本发明限制于以下的详细描述。下面将示出的所有具体实现都是示例性的，在应用本发明时可以根据设计需求和具体用户要求等而改变实现细节。

下面参照图3描述根据本发明第一实施例的呈现服务器200。通过比较图2和图3可知，图3包括了图2中的所有单元，为了使描述更清楚，将省略对共有单元的描述。图3与图2的不同之处在于图3所示的呈现服务器200的第二层还包括QoS策略执行单元221、SIP消息分类单元222、双向SIP消息队列224、SIP消息调度单元225以及在第二层之内或之外但包括在呈现服务器200中的QoS策略数据库232。上述第二层之内的单元与图2所示的第二层之内的单元一起构成了可以实现QoS控制的Siplet容器。当所述QoS策略数据库232位于第二层之外时，其不是Siplet容器的组件之一。

下面将参照图3，仅具体描述根据本发明第一实施例的支持QoS控制的呈现服务器与现有技术不同的结构。

如图3所示，双向SIP消息队列224是存储延迟的SIP消息的单元。SIP消息可以来自于高层，即，SIP应用/呈现应用层210，也可以来自低层，即，SIP栈层250。

QoS策略执行单元221用来获得并执行存储在QoS策略数据库232中的QoS策略。QoS策略是一种管理性的策略，通常由呈现服务器200的运营者来定义和配置。

QoS策略的灵活性很大，可以只是一个简单的分级，也可以是一组复杂的规则。其规范的定量指标可能包括响应时间、吞吐率、并发用户数、资源占用率等。双向SIP消息队列224中队列的数目和划分取决于对要支持的QoS策略的建模。也就是说，该队列是实现QoS策略所用的工具。

下面我们列举了QoS策略的例子，并基于该例子对根据本发明的呈现服务器200的第二层中的各单元执行的处理进行了描述。

第一个例子是简单的分级。假设将呈现系统中的订阅用户分为金牌用户、银牌用户和铜牌用户，并且金牌用户优先于银牌和铜牌用户得到服务，而银牌用户优先于铜牌用户得到服务。这样的QoS策略可描述如下：

{

策略1：如果SIP消息来自金牌用户，则设置消息为金牌消息，且该金牌消息优先于银牌消息和铜牌消息得到处理；

策略2：如果SIP消息来自银牌用户，设置消息为银牌消息，且该银牌消息优先于铜牌消息得到处理；

策略3：如果SIP消息来自铜牌用户，则设置消息为铜牌消息；

}

显然，这是一个非常粗粒度的QoS策略。例如，在用户进行订阅注册时就确定了其为金牌用户、银牌用户或铜牌用户的身份，并且在呈现服务器中将用户的用户ID和/或地址与其身份关联起来。这样每当有来自订阅用户的SIP消息时，就可以根据用户ID和/或地址直接确定其身份。

下面给出第二个例子。在这个例子中我们用定量指标，响应时间，更为详细地定义QoS策略。假设呈现服务器的服务内容为查询实体的位置信息，按照精度要求，将SIP消息分为三类：查询高精确位置(如精度<1米)的SIP消息、查询中等精度位置(如精度<5米)的SIP消息、和查询低精度位置(如精度<10米)的SIP消息。这样的QoS策略可描述如下：

{

策略1：如果SIP消息为查询高精度位置的消息，则设置消息最长等待时间为100毫秒；

策略2：如果SIP消息为查询中精度位置的消息，则设置消息最长等待时间为500毫秒；

策略3：如果SIP消息为查询低精度位置的消息，则设置消息最长等待时间为2秒；

}

这个例子中，QoS策略是根据SIP消息的内容确定的，而不再是简单的等级，并且呈现服务也不是简单地无条件地优先服务于高级别的用户，而是要通过对SIP消息的分类、调度等操作来确保对用户请求的服务能够满足QoS策略中给出的定量指标。例如，对SIP消息为查询高精度位置的消息，该SIP消息在最长100毫秒内得到处理；对SIP消息为查询中精度位置的消息，该SIP消息在最长500毫秒内得到处理；而对SIP消息为查询低精度位置的消息，该SIP消息在最长2秒内得到处理。

虽然上面给出了QoS策略的例子，但是这些例子仅仅是示例性的，并非意欲将本发明局限于这些具体的示例。相反，用户可以根据其需求定义复杂程度不同的QoS策略，并基于该QoS策略来建立相应的队列。

SIP消息分类单元222用来分析经过Siplet容器的SIP消息，根据QoS策略执行单元221提供的策略，对这些SIP消息进行分类，并将其发送到双向SIP消息队列224以执行延迟操作。

SIP消息调度单元225根据QoS策略执行单元221提供的策略而从双向SIP消息队列224中取出延迟的SIP消息，调用如图2所示的现有Siplet容器所包括的相关单元进行处理并将处理的SIP消息发送出Siplet容器。该SIP消息被发送到高层的SIP应用/呈现应用层210或低层的SIP栈层250。

例如，针对上述第一个例子，SIP消息分类单元222将所有到来的SIP消息被分为三类。在双向SIP消息队列中，可以针对QoS策略，设置分别放置金牌消息、银牌消息、和铜牌消息的三个队列。当然，如本领域技术人员所知的那样，可以不分队列而是给SIP消息的首部添加分别对应于金牌消息、银牌消息、和铜牌消息的标签。SIP消息调度单元225每次需取出一个SIP消息进行调度处理，则依次检查三个队列。如果金牌队列不为空，则取出一个金牌SIP消息；否则如果银牌队列不为空，则取出一个银牌SIP消息；否则，如果铜牌队列不为空，则取出一个铜牌消息。通过这样的调度方法，银牌队列和铜牌队列中的SIP消息被延迟执行操作。

再例如，针对上述第二个例子，SIP消息分类单元222通过读取到来的SIP消息的内容，将所有SIP消息分为三类。在双向SIP消息队列中，可以针对QoS策略，设置分别放置最大等待时间为100毫秒，500毫秒，2秒的消息的3个队列。当然，如本领域技术人员所知的那样，可以不分队列而是给SIP消息的首部打上时间戳来指示相应的时间是否到达。SIP消息调度单元225每次需取出一个SIP消息进行调度处理。则需同时检查三个队列，检查等候的消息，找出最快要到期的消息，进行处理。其他消息继续留在队列中，按照预设的期限继续等候。

SIP消息调度单元225可以根据SIP消息类型、目标URL、和/或QoS策略等，将队列中的相关消息合并为一个消息，从而降低事务的数量，进而降低服务器的工作负载。本领域技术人员可以根据其已有的知识，设计消息合并的标准和方法。

合并消息的例子如下，通过考察等待队列中SIP消息的头部信息(诸如，源地址和目标地址)，SIP消息调度单元在同一或不同队列中找到观察者A对实体B的两次位置查询消息(源地址表明这两个查询消息是观察者A发出的，目标地址表明是对实体B的观察)，则两次查询合并为一次查询，统一处理。在此例中，可以通过如下方式进行合并：首先将两个SIP消息的消息体合并，然后将合并后的消息体作为两个查询消息中根据QoS策略最早到期的那个消息的消息体，最后将另一个查询消息从等待队列中删除。

图4是示出了根据本发明第一实施例的呈现服务器200的、实现QoS控制的Siplet容器的工作原理的框图，它是对图3的进一步细化。图4仅示出了可以实现本发明的工作原理。从图4中可以看出，QoS策略执行单元221、SIP消息分类单元222、双向SIP消息队列224、和SIP消息调度单元225是本发明引入的新单元，并且还引入了SIP消息分类单元222和SIP消息调度单元225与现有单元和本发明提供的单元之间的调用关系，以及QoS策略执行单元221与QoS策略数据库232之间的数据获取关系。

下面对本发明所引入的调用关系和数据获取关系进一步说明如下：

调用关系：

SIP消息分类单元222和SIP消息调度单元225与定时器管理单元229之间：SIP消息分类单元222和SIP消息调度单元225可以通过定时器管理单元229调度一些定时器，指定这些定时器的超时时间和超时执行的动作。例如，将某些消息传递给上层或者传送到低层，或者丢弃。但是，定时器管理单元229对于SIP消息调度单元225不是必须的。

如本领域技术人员所理解的那样，对于上述第一例子，SIP消息调度单元225可以不考虑消息的过期时间，只要队列中有SIP消息就将其取出，处理后发送出去。但是，也可以根据定时器管理单元229提供的时间服务而调度双向SIP消息队列224中延迟的SIP消息，例如，对于上述第二个例子，SIP消息进入队列时可以根据其QoS策略规定的最长等待时间来为其调度定时器，当这些定时器超时时，若该消息尚未得到处理，就直接从队列中删除该消息。

SIP消息分类单元222和SIP消息调度单元225与会话/对话管理单元231之间：会话/对话管理单元231记录并管理关于SIP会话/对话的信息。SIP消息分类单元222和SIP消息调度单元225在对消息做分类和分发的时候可以通过对会话/对话管理单元231的调用，将具体的SIP消息与针对同一Siplet的会话/对话关联起来，从而可以以更细的粒度对SIP消息进行处理，并且可以利用会话/对话信息来完成分类的操作。

SIP消息分类单元222或SIP消息调度单元225与Siplet上下文管理单元226之间：由于从上层或下层接收到的消息在进入第二层时先要存储在Siplet上下文管理单元226中，因此SIP消息分类单元222通过与Siplet上下文管理单元226的交互而获得接收的消息，然后，SIP消息分类单元222或SIP消息调度单元225再对这些消息进行进一步的处理。此外，SIP消息分类单元222可以将一些信息存储在Siplet上下文管理单元226中，以供第一和/或第二层中的应用和实现使用，所述信息如接收消息的时间，大小等。

SIP消息分类单元222和SIP消息调度单元225与消息Siplet关系单元228之间：消息分类和分发的时候会需要用到消息Siplet的映射关系(通常表现为一些规则，例如特定的URL对应于特定的Siplet)。具体说来，对于要递交给SIP应用/呈现应用层210的消息，消息Siplet关系单元228可以根据消息的目的地地址而将该SIP消息与SIP应用/呈现应用层210中的某一Siplet相关联。但是，对于来自SIP应用/呈现应用层210中的某一Siplet的要发送出去SIP消息，由于该SIP消息来自哪个Siplet发送时已知的，即，SIP消息分类单元222和SIP消息调度单元225已经知道该SIP消息与SIP应用/呈现应用层210中的哪个Siplet相关联，因此就不必调用消息Siplet关系单元228了。

SIP消息分类单元222和SIP消息调度单元225与QoS策略执行单元221：QoS策略执行单元221负责解释QoS策略，得到决策结果。SIP消息分类单元222通过调用QoS策略执行单元221得到QoS策略和决策结果，确定SIP消息的服务级别，从而完成SIP消息分类。SIP消息调度单元225通过调用QoS策略执行单元221来检索可用的QoS策略，根据相应SIP消息的服务级别来进行调度，一般说来，具有较高服务等级的消息优先于具有较低服务等级的消息而被SIP消息调度单元225从双向SIP消息队列224取出。

数据获取关系：

QoS策略执行单元221与QoS策略数据库232：前者要从后者中获取适用的策略，后者是一个类似于数据库的结构，其可能是标准的数据库，也可能是文件。

下面对图4所示出的工作原理框图的一些细节做进一步说明。

图4示出的是双向SIP消息队列224是一个多消息队列，通常每条消息队列都代表了不同的服务等级。虽然在此使用了表述“队列”，但是本领域技术人员将理解可通过给每个消息打上标签以表示不同的服务级别或其它能够实现服务级别区分的任何手段来实现将消息区分开的目的。此外，所述“队列”可以实现为存储器或者文件等。

同现有的呈现系统相比，通过引入上述组件和处理流程，根据本发明第一实施例的呈现服务器200可以提供一定的QoS控制能力(区分不同的服务优先级)，其处理能力也得到加强(通过合并SIP消息)。但是，呈现服务器200仍有一些不足，如缺乏过载保护机制，因此其QoS控制能力相对有限。

下面参照图5描述根据本发明第二实施例的呈现服务器300，该呈现服务器300将提供进一步的QoS控制能力。通过比较图5和图3可知，图5包括了图3中的所有单元，为了使描述更清楚，将省略对共有单元的描述。图5与图3的不同之处在于图5所示的呈现服务器300的第二层还包括工作负载感测单元223以及系统负载监视器233。

工作负载感测单元223用来获得系统工作负载。工作负载感测单元223与图3所示的Siplet容器中的各单元一起构成了可以实现进一步QoS控制的Siplet容器。

在现有的呈现系统中，已经具有了用于感测当前系统的负载，例如CPU利用率，的系统负载监视器233。但是在现有的呈现系统和根据本发明的第一实施例中，系统负载监视器233对当前系统负载的监视结果与呈现服务器的操作并没有联系起来。通过给Siplet容器添加工作负载感测单元223并由其获得系统负载监视器233对系统负载的监视结果，可以将Siplet容器的操作与系统负载联系起来。具体说来，通过对系统负载的感知，可以估算系统处理SIP消息的速度和容量，进而可以利用估算的结果调整准入的SIP消息的种类和数量，从而提供过载保护和更细粒度的量化的QoS控制能力。

SIP消息分类单元222可以通过与工作负载感测单元223之间的调用而获取当前的系统工作负载状况。如果工作负载感测单元223感测得知系统工作负载过高，则SIP消息分类单元222可以通过丢弃低服务级别的消息从而有效控制工作负载。

SIP消息调度单元225可以通过与工作负载感测单元223之间的调用而获取当前的系统工作负载状况。如果工作负载感测单元223感测得知系统工作负载过高，则SIP消息调度单元225可以通过丢弃低服务级别的消息以降低系统负载，为高服务级别的消息留出处理能力。

例如，针对上述第一个例子，SIP消息分类单元222除了根据QoS策略进行分类外，还通过与工作负载感测单元223之间的调用而获取当前的系统工作负载状况。如果当前系统工作负载大于95％ CPU利用率，则拒绝接收任何到来的消息。如果当前系统工作负载大于80％CPU利用率，则只接收金牌消息，如果当前系统工作负载大于60％CPU利用率，则只接收金牌消息和银牌消息，否则，接收全部消息。SIP消息调度单元225也可根据当前的系统工作负载状况进行调度。例如，如果当前系统工作负载大于85％ CPU利用率，则只检查金牌消息，而不对银牌消息和铜牌消息进行任何处理。如果当前系统工作负载大于60％ CPU利用率，则只检查金牌消息和银牌消息，而不对铜牌消息进行任何处理。否则，进行正常的调度处理。

再例如，针对第二个例子，SIP消息分类单元222除了根据QoS策略进行分类外，还通过与工作负载感测单元223之间的调用而获取当前的系统工作负载状况。如果当前系统工作负载大于95％ CPU利用率，则拒绝接收任何到来的消息。如果当前系统工作负载大于80％CPU利用率，则只接收查询高精度位置的消息，如果当前系统工作负载大于60％ CPU利用率，则只接收查询高精度位置的消息和查询中精度位置的消息，否则，接收全部消息。此外，SIP消息调度单元还可根据工作负载感测单元，按照当前系统工作负载的程度进行调度。例如，如果当前系统工作负载小于50％ CPU利用率，则按照上述例子调用；如果工作负载大于50％CPU利用率，则不检查2秒队列，而按照上述例子中的方法对100毫秒，500毫秒队列进行调度。

图6是示出了根据本发明第二实施例的呈现服务器300的，实现进一步QoS控制的Siplet容器的工作原理框图，它是对图5的进一步细化。除了图4所示的调用关系和数据获取关系之外，还存在如下调用关系和数据获取关系：

SIP消息分类单元222和SIP消息调度单元225与工作负载感测单元223之间存在的调用关系为：消息在分类和分发的时候可以通过工作负载感测单元223获得当前系统的负载情况，如CPU占用率，内存占用率等，并根据负载情况采取适当的动作，如加入队列，分发或者丢弃等。

工作负载感测单元223与系统负载监视器233之间存在的数据获取关系为：前者需要从后者那里获得像CPU占用率这样的信息，传统容器中是没有这样的信息的，一般需要从操作系统获取。

通过使用根据本发明第二实施例的呈现服务器，能够根据当前的系统工作负载和QoS策略，捕获一些SIP消息并将其延迟一定时间，然后将其发送出Siplet容器，从而在不提高硬件的消息处理能力的情况下进一步提高了呈现服务器的处理能力和细粒度的QoS控制能力。

为了说明本发明的基本概念而不使其受到不必要的细节的遮蔽，图7示出了在根据本发明的Siplet容器层中处理SIP消息的最基本过程的流程图。

在步骤702中，接收SIP消息。

在步骤704中，基于QoS策略，将所述SIP消息分类。

在步骤706中，经过与所述QoS策略相关的预定时间后，发送分类后的所述SIP消息。

图8示出了在根据本发明的Siplet容器层中处理SIP消息的过程的细节的流程图。需要说明的是，图8中尽可能地描述了在Siplet容器层230中执行的全部步骤，对于其中的一些处理，如本领域技术人员所能够设想到的那样，本领域技术人员可以根据需要选择执行，或基于不同的顺序执行，但其都是属于本申请的保护范围之内。

在步骤801中，判断是否有SIP消息进入Siplet容器层，该步骤的执行者与现有技术中的相同。如果有，则过程前进到步骤802；否则，继续执行步骤801。

在步骤802中，确定该消息是来自上层210(即，SIP应用/呈现应用层210)还是下层250(即，SIP栈层250)。该步骤的执行者与现有技术中的相同。如果来自下层250，则过程前进到步骤803；而如果来自上层210，则过程前进到步骤812。

在步骤803中，消息Siplet关系单元228确定该消息对应的Siplet，接着将该消息交给Siplet上下文管理单元226存放。而在步骤812中，将该消息交给Siplet上下文管理单元226存放。而后，过程由这两个步骤都前进到步骤804。

在步骤804中，工作负载感测单元223获取当前的系统负载并估算系统的处理容量。

在步骤805中，QoS策略执行单元221取得QoS策略，评估QoS策略，得到评估结果。可选地，在确定评估结果时还考虑了当前的系统负载并估算的系统处理容量。

在步骤806中，SIP消息分类单元222对该SIP消息进行分类并将其放入相应的双向SIP消息队列224进行延迟以等待进一步处理，或者丢弃该SIP消息。

在步骤807中，使用定时器管理单元229来调度用于相应队列的定时器，以提供用于处理相应消息的定时。

在步骤808中，工作负载感测单元223获取当前的系统负载并估算系统的处理容量。

在步骤809中，工作负载感测单元223获得QoS策略，得到评估结果。可选地，在确定评估结果时还考虑了当前的系统负载并估算的系统处理容量。并根据评估结果，SIP消息调度单元225从双向SIP消息队列224中取出相应的延迟SIP消息，确定进一步处理该消息还是丢弃该SIP消息。

在步骤810中，SIP消息调度单元225基于预定条件，例如，所述消息存放在所述双向SIP消息队列224中的一定大小的窗口范围内并去往同一目的地的通知消息，或具有相同优先级并去往同一目的地等等，合并所述消息。

在步骤811中，将最后获得的SIP消息发送出Siplet容器层230。该步骤的执行者与现有技术中的相同。

通过上述说明可知，本发明具有以下明显的技术优势：

根据QoS策略，对呈现服务器的SIP消息流进行控制。对于特定的呈现服务器SIP消息，对于特定的应用场景，特定的延迟是容许的。本发明可以为呈现服务提供细粒度的区别服务和过载保护等QoS保障功能。因此，与现有的呈现服务相比，新呈现服务向终端用户展示了更好的性能和稳定性。

SIP栈和呈现服务器应用未被修改。本发明不需要修改SIP栈和呈现服务器应用。不同的SIP栈和呈现服务器均可以用在本呈现服务器系统中，因此，本发明兼容了已有的呈现服务器的结构。

可以合并延迟的SIP消息。由于在容器中执行对一些SIP消息的延迟，所以对于特定的场景，如即时消息场景，可以将许多SIP通知消息(其被发送给同一接收者)合并在一起，从而可以节省系统中的计算资源和网络带宽资源。

图9示意性地表示了其中可以实现本发明的实施方式的计算机系统。图9中所示的计算机系统包括CPU(中央处理单元)901、RAM(随机存取存储器)902、ROM(只读存储器)903、系统总线904、HD(硬盘)控制器905、键盘控制器906、串行接口控制器907、并行接口控制器908、显示器控制器909、硬盘910、键盘911、串行外部设备912、并行外部设备913和显示器914。在这些部件中，与系统总线904相连的有CPU 901、RAM 902、ROM 903、HD控制器905、键盘控制器906，串行接口控制器907，并行接口控制器908和显示器控制器909。硬盘910与HD控制器905相连，键盘911与键盘控制器906相连，串行外部设备912与串行接口控制器907相连，并行外部设备913与并行接口控制器908相连，以及显示器914与显示器控制器909相连。

图9中每个部件的功能在本技术领域内都是众所周知的，并且图9所示的结构也是常规的。这种结构不仅用于个人计算机，而且用于任何支持用户开发其所需要的应用的开发平台。在不同的应用中，图9中所示的某些部件可以被省略。图9中所示的整个系统由通常作为软件存储在硬盘910中、或者存储在EPROM或者其它非易失性存储器中的计算机可读指令控制。软件也可从网络(图中未示出)下载。或者存储在硬盘910中，或者从网络下载的软件可被加载到RAM 902中，并由CPU 901执行，以便完成由软件确定的功能。

尽管图9中描述的计算机系统能够支持根据本发明的方法，但是该计算机系统只是计算机系统的一个例子。本领域的熟练技术人员可以理解，许多其它计算机系统设计也能实现本发明。

本发明还可以实现为一种例如由图8所示计算机系统所使用的计算机程序产品，其包含有用于本发明的方法的代码。在使用之前，可以把代码存储在其它计算机系统的存储器中，例如，存储在硬盘或诸如光盘或软盘的可移动的存储器中，或者经由因特网或其它计算机网络进行下载。

对本领域的技术人员来说将显而易见的是，可在本发明中作出各种修改，而不会背离本发明的精神和范围。由此，意图使本发明涵盖此发明的修改和变化，只要它们在所附权利要求及其等价物的范围内即可。

Claims (19)

1.一种用于为呈现服务器提供服务质量控制能力的方法，包括步骤：

接收会话发起协议消息；

基于服务质量策略，将所述会话发起协议消息分类；以及

经过与所述服务质量策略相符的预定时间后，发送分类后的所述会话发起协议消息。

2.如权利要求1所述的方法，其中，所述分类步骤包括：

将所述会话发起协议消息放入与所述服务质量策略相对应的队列中；并且，

其中，所述发送步骤包括：

从队列中取出所述会话发起协议消息。

3.如权利要求1所述的方法，还包括步骤：

根据所述会话发起协议消息的目的地地址，将所述会话发起协议消息与相应的Siplet关联起来。

4.如权利要求1所述的方法，还包括步骤：

检测系统当前的工作负载；以及

根据检测结果，丢弃所述会话发起协议消息或将其放入相应的队列中。

5.如权利要求1所述的方法，其中，所述消息是离开所述呈现服务器的消息或者到达所述呈现服务器的消息。

6.如权利要求1所述的方法，还包括步骤：

根据所述会话发起协议消息自身的属性和服务质量策略，将目的地地址相同的多个会话发起协议消息合并成一个会话发起协议消息。

7.如权利要求1所述的服务质量控制的呈现方法，还包括步骤：

响应于定时信号，从所述队列中取出所述会话发起协议消息。

8.如权利要求1所述的服务质量控制的呈现方法，还包括步骤：

以预定的时间间隔从所述队列中取出所述会话发起协议消息。

9.一种用于为呈现服务器提供服务质量控制能力的设备，包括步骤：

服务质量策略执行单元，用来获取和提供与接收的会话发起协议消息有关的服务质量策略；

会话发起协议消息分类单元，用来根据所述服务质量策略执行单元提供的所述服务质量策略，将所述会话发起协议消息分类；

以及

会话发起协议消息发送单元，经过与所述服务质量策略相符的预定时间后，发送分类后的所述会话发起协议消息。

10.如权利要求9所述的设备，所述会话发起协议消息发送单元包括：

双向会话发起协议消息队列，用于存储所述分类后的会话发起协议消息以将其延迟与所述服务质量策略相关的预定时间；和

会话发起协议消息调度单元，用于发送在所述双向会话发起协议消息队列中等待的会话发起协议消息。

11.如权利要求9或10所述的设备，还包括：

消息Siplet关系单元，用于根据所述会话发起协议消息的目的地地址，将所述会话发起协议消息与相应的Siplet关联起来。

12.如权利要求10所述的设备，还包括：

工作负载感测单元，用于检测系统当前的工作负载并将检测结果提供给所述会话发起协议消息分类单元和/或所述会话发起协议消息调度单元。

13.如权利要求12所述的设备，其中，

所述会话发起协议消息分类单元根据来自所述工作负载感测单元的检测结果，丢弃所述会话发起协议消息或将其放入相应的队列中。

14.如权利要求12所述的设备，其中，所述会话发起协议消息分类单元将所述会话发起协议消息放入与所述服务质量策略相对应的队列中；并且，

其中，所述会话发起协议消息调度单元从所述队列中取出所述会话发起协议消息，然后进行发送。

15.如权利要求14所述的设备，其中，其中，所述消息是离开所述呈现服务器的消息或者到达所述呈现服务器的消息。

16.如权利要求14所述的设备，其中，

所述会话发起协议消息调度单元以预定的时间间隔从所述队列中取出所述会话发起协议消息。

17.如权利要求10所述的设备，还包括：

定时器管理单元，用于向所述会话发起协议消息调度单元提供定时信号，并且

其中，所述会话发起协议消息调度单元响应于所述定时信号，发送所述会话发起协议消息。

18.如权利要求10所述的设备，其中，

所述会话发起协议消息调度单元根据所述会话发起协议消息自身的属性和服务质量策略，将目的地地址相同的多个会话发起协议消息合并成一个会话发起协议消息。

19.一种支持服务质量控制的呈现系统，包括：

会话发起协议应用/呈现应用实体，用于实现供用户使用的服务程序；

Siplet容器实体，用于实现如权利要求1-8所述的方法，以为所述会话发起协议应用/呈现应用实体提供服务；和

会话发起协议栈实体，用于实现会话发起协议协议，以为所述Siplet容器实体提供服务。

Images