专利名称：在3g网络中的rsvp处理的利记博彩app
技术领域：
本申请总地涉及互联网协议(“IP”)网络并且更特别是涉及IP网中的服务质量(“QoS”)提供机制。
背景技术：
最初，IP网是被设计传送“尽力而为”业务量。那就是说，网络不保证一个用户分组将到达目的地。因为IP网在市场上的成功，今天对于允许IP网支持多种类型应用的机制有很清楚的需求。这些应用中的一些有QoS要求。这种应用的例子包括各种实时应用(IP电话、视频会议)、流业务(音频或视频)、或高质量数据业务(具有有限下载延迟的浏览)。考虑到这些需求，互联网工程任务组(“IETF”)(它是IP组网的主要标准主体)最近标准化了一组协议和机制，使得IP网运营商能够构建QoS使能的IP网。
图-1描绘了一个IP网的简化高层模型，它有助于解释QoS的提供。正如所理解的，虽然该模型包括两个用户，但可以很容易地扩展为包括多个用户而不改变网络的基本功能。
在图-1中，用户-A 101可以与用户-B 102通信或者与一个应用服务器103通信。例如，在一个IP电话的会话情况下，用户-A 101可以与用户-B 102通信。同样，在流业务的情况下，用户-A 101可以与应用服务器103通信，该服务器可能被配置为一个视频服务器。在任一种情况下，用户-A 101经一个本地接入网105(例如一个电话网、GSM网或UMTS网)接入一个IP骨干网104。用户-B 102同样经本地接入网106连接到IP网104。然而，应理解用户-A和用户-B不要求使用相同类型的接入网。
正如一般所了解的，IP网104可以由多个IP路由器和互连链路组成，它们共同提供IP网入口点和出口点之间的连接，从而使得双方通信成为可能。
就用户而言，则感觉的QoS既依赖于接入网105、106内的机制又依赖于IP骨干网104上的机制。其中特别关心的是至少其中一个接入网是一个UMTS网的特殊情况。
当用户接入基于IP的业务时，他们典型地使用一个运行应用程序的设备，所述应用程序给用户提供接口以便接入特定业务。例如，在图-1中用户-A可能使用一台运行一个会议应用程序的膝上型电脑以便参加一个基于IP网的会议，其中会议的参加者使用多个程序来合作。这种程序在本领域中是众所周知的。
各种应用可以经一个应用编程接口(“API”)接入网络业务。一个API提供给应用编程人员一个统一的接口以便接入到底层的系统资源。例如，一个API可以被用于配置网络资源管理器，来要求一个发源于给定应用的特定IP分组接受来自网络的某种处理，例如一个特定的QoS。例如，如果IP网是一个区别服务IP网，那么一个应用程序可以请求它的所有IP分组接受“加速转发”处理。
注意用户(以及在用户设备中的API)可能不知道多个接入网和IP骨干网为了提供端到端QoS而使用的不同技术。例如用户可能使用一个基于RSVP/IntSerV的API并且用户涉及的端到端的实施方案可能包括一个UMTS接入网和一个非-RSYP使能的IP网。在这种情况下，需要不同技术之间的一些互通机制来确保QoS被端到端地提供。
综合业务(“IntSerV”)给应用提供在多重、受控的传送业务级别中选择以便用于它们的数据分组的能力。要支持这种能力，需要两样事情。第一，一个应用的数据分组遵循的路径途中的各个网元，例如子网和IP路由器，必须支持控制传送给那些分组的服务质量的机制。第二，必须提供一种方式来传达应用对路径途中的网元的要求以及传送网元和应用之间的QoS管理信息。
IntSerV定义了多个业务例如受控负载业务(在IETF RFC 2211中被定义)和有保证业务(在IETF RFC 2212中被定义)。业务定义规定了网络设备为传送该业务而需要的特征。例如，有保证业务对端到端数据报排队延迟提供了稳定的、数学上可证明的界限并使得有可能提供一项保证延迟和带宽的业务。受控负载业务给客户数据流提供的服务质量非常接近于同一流从一个无载网元中接收到的QoS，但使用能力(接纳)控制来确保甚至当网元过载时这项业务也可以被接收到。支持所述业务的各个网元(子网和IP路由器)必须遵守对于所述业务规定的定义。
业务定义还规定了必须被提供的跨越网络的信息以便建立业务。这个功能可以以多种方式来提供，但通常由一个资源预留建立协议例如RSVP(在IETF RFC 2205中被定义)来实现。
RSVP(资源预留协议)是一个资源预留建立协议，被设计用于一个IntSerV互联网(在IETF RFC 1633、2205和2210中被定义)。RSVP协议被一个主机用来从网络请求特殊的服务质量，用于特定的应用数据流或信息流。RSVP还被路由器用于将服务质量(“QoS”)请求传送给沿信息流的路径途中所有的节点，并建立和维护状态从而提供被请求的业务。RSVP请求通常会导致在沿数据路径途中的每一个节点内预留资源。
图-2示出主机之间端到端的综合业务。该业务通过使用支持为所需业务规定的业务定义的路由器和主机并通过节点之间相关信息的信令来提供。
因为RSVP是被主要设计用于端到端的一个协议，所以在一种情况下需要一些额外的功能，该情况为发送方只在端到端路径上的某些部分才希望使用RSVP进行资源预留。如果RSVP在一个接入网中被使用并且在骨干网中使用过度供给时，这就可能会出现。在这种情况下，RSVP代理的概念是有用的。
RSVP代理是由一个网络设备(例如一个路由器或一个交换机)提供的功能性，其中该网络设备响应于一个进入PATH消息，而代表由该PATH消息标识的一个或多个接收方来发起RESV消息。换句话说，RSVP代理代表远程主机动作，从而帮助发端主机和RSVP代理之间的资源预留。这在图-3中被示出。RSVP代理可以使用RSVP代理和非RSVP主机之间知道的网络条件。
对互联网协议的区别服务(“DiffServ”)增强被规定来使得在互联网中能够进行可缩放的业务鉴别，而不需要在每一跳处的每一个流的状态和信令。多种业务可以根据在网络节点中部署的一组明确定义的构建块来构建。该业务或者是端到端的或者是域内的；该业务包括能够满足定量性能要求(例如，峰值带宽)的那些业务以及基于有关性能(例如，“类别”区分)的那些业务。该业务可以通过在网络边界(自治系统边界、内部管理的边界、或主机)处的一个IP头标字段中设置比特，使用那些比特来确定分组怎样被网络中的节点前向传输，并且在网络边界处按照每个业务的要求和规则来调整被标记的分组的组合来构造。
区别服务定义了在网络边界处的边缘路由器，和网络内的核心路由器。边缘路由器和核心路由器完成不同的任务。边缘路由器必须调整业务量以确保业务量符合业务协定。边缘路由器还要用适当的区别服务代码点(“DSCP”)来标记分组业务量并且之后按照定义给那个DSCP的业务行为来转发分组。被称为每跳行为(“PHB”)的业务行为定义了那种类型业务量的优先化或权重以便给该业务量比不同类型的其它业务量更好的服务。核心节点检查DSCP并应用适于那个业务的业务行为。
图-4示出了端到端的业务。DS边缘路由器实现业务量调整，而DS核心路由器只是简单地应用了PHB。
IntSerV体系结构提供一种用于通过异种网络向应用传递端到端的QoS的装置。要支持这个端到端的模型，IntSerV体系结构必须通过大量不同类型的网元支持。在这个上下文中，一个支持区别服务的网络可以被看作是在整个端到端路径上的一个网元。
从IntSerV的角度看，网络的DiffServ区域被当作连接IntSerV使能的路由器或主机的虚拟链路对待(差不多就象一个以太网LAN可以被当作一条虚拟链路对待一样)。在网络的DiffServ区域内，路由器实现特定的PHB(聚集业务量控制)。被允许进入DiffServ区域的全部业务量通过在边缘路由器处的调整来被控制，所述DiffServ区域要接收某一个PHB。经一个DiffServ域的一个IntSerV业务可以通过在边缘路由器处应用接纳控制和业务量调整并且使用RSVP跨越DiffServ域进行信号通知，来提供。在RSVP信令中提供的信息适合于跨越DiffServ域的业务。这在图-5中被示出。
要实现一个有清楚定义的特征和功能的QoS承载业务，承载一定要从业务的源建立到目的地。一个承载业务包括所有方面以便使得能够提供一个被约定的QoS。这些方面尤其是控制信令、用户平面传输、以及QoS管理功能。
包括通用分组无线电业务(“GRPS”)和通用移动通信系统(“UMTS”)的移动接入数据网可以构成整个网络的一部分并在与之相连的用户的端到端的承载业务中扮演一个重要的角色。因此，经GRPS/UMTS网提供的业务必须在上面提到的控制信令和用户平面传输方面中是适合的，以便提供所需的端到端的承载业务。
GRPS/UMTS网由主机(被称为移动台(“MS”))和与用户相连的外部分组交换网之间的一组网元组成。这些节点在图-6中被示出。
网关GRPS支持节点(“GGSN”)提供与外部分组交换网的互通。
为了发送和接收分组交换(“PS”)数据，MS会激活MS想使用的分组数据协议上下文。这个操作使得相应的GGSN知道MS并且与外部数据网的互通就可以开始了。
用户数据在MS和外部数据网之间被透明传送，使用了称为封装和隧道化的一种方法；数据分组用特定PS协议信息来装配并在MS和GGSN之间被传送。
服务质量(“QoS”)同样在3G移动网中起到一个极端重要和中心的作用。QoS是一种给终端用户提供满意业务的手段并且对于根据已知情况进行网络管理来说它是必须的。QoS具备网络中业务量的知识，这样QoS还使得能够有效地使用频谱资源。
本发明将按照一个UMTS QoS体系结构来描述。因此，为了提供一个一致水平的理解，提供了一个UMTS中QoS的最新概述。3GPP UMTS QoS结构被描述，它包括一个分组数据协议上下文(“PDP上下文”)的解释、业务流模板(“TFT”)、以及用于被激活的UMTS承载的QoS维护程序。
可以预期与无线电有关的带宽在端到端链中是最昂贵并且是最宝贵的资源。在UMTS接入网内，无线网络资源基于对应于一个用户流和某一个QoS级别的每PDP上下文间隔尺寸而被管理。
用于R99 3G网络的QoS框架在TS23.107 V.3.4.0中被详细说明。主要的焦点在于在UMTS级中要使用的QoS体系结构，其中可应用于UMTS承载业务和无线接入承载业务的QoS属性列表连同适当的映射规则被详细说明。
TS23.060 V.3.4.0指定了R99 3G网络使用的、用于在UMTS级中的PS连接业务的常用机制。它定义了用于3G网络的分组域的业务描述，包括在GSM和UMTS中的通用分组无线电业务(“GRPS”)。
在一个UMTS QoS体系结构中，网络业务被认为是端到端的，从一个终端设备(“TE”)到另一个TE。一个端到端业务可以具有某一个服务质量，所述服务质量被提供给一个网络业务的用户。
要实现某一个网络的QoS，具有被清楚定义特征和功能的一个承载业务从一个业务的源建立到目的地。所述承载业务包括所有方面以便允许提供一个被约定的QoS，例如控制信令、用户平面传输、QoS管理功能等等。
一个UMTS承载业务分层的体系结构在图-7中被描绘。在一个特定层上的每一个承载业务通过使用下层提供的业务来提供各自的业务。承载被分解成底层承载，每一个承载通过一个独立于其它承载的实现来提供一个QoS。在网络组成部分之间达成业务协定，这在图-7中被水平安排。业务协定可以通过一层或多层业务来执行。
例如，UMTS承载业务由一个无线电接入承载(“RAB”)业务和一个核心网(“CN”)承载业务组成。RAB业务接着被划分成无线电承载业务和Iu承载业务。Iu接口是无线电接入网和核心网之间的接口。
下面就是在图-7中示出的实体的例子。终端设备(“TE”)可以是一个膝上型电脑并且移动终端(“MT”)可以是一个手机。UTRAN可以由节点B和一个无线电网络控制器(“RNC”)的一个组合来组成。CN Iu边缘节点可以是一个正服务GPRS支持节点(“SGSN”)并且CN网关可以是一个网关GPRS支持节点(“GGSN”)。
在UMTS中的QoS管理功能被用于建立、修改和维护具有一个特定QoS的UMTS承载业务，如特定QoS属性定义的那样。所有组合的UMTS实体的QoS管理功能保证提供协商的UMTS承载业务。
UMTS体系结构包括在控制平面上的四个管理功能和在用户平面上的四个管理功能。控制平面的管理功能是承载业务(“BS”)管理器，它建立、控制、并且终止相应的承载业务。每一个BS管理器还在业务请求期间将它的级别属性翻译成下层承载业务的属性。
翻译功能在外部业务信令和内部业务原语之间转换，包括业务属性的翻译，并且它位于MT和GW中。
接纳/能力控制，它确定网络实体是否支持特定请求的业务，并且确定被请求的资源是否是可用的。
预约控制，它确定用户是否已预约了请求的承载。
用户平面的管理功能是映射功能，它用与承载业务相关的特定QoS指示来标记每一个数据单元，所述承载业务实现数据单元的传送。例如，映射功能在把分组放到Iu-或CN承载上之前将DiffServ代码点加到分组上。
分类功能，它驻留于GGSN和MT中，将接收自外部承载业务(或本地承载业务)的用户数据单元(例如，IP分组)按照每一个用户数据单元的QoS要求指定给适当的UMTS承载业务。如下面所描述的，这是业务流模板(“TFT”)和分组过滤器所处的位置。
资源管理器，它在所有承载业务之间分布它的资源，所述承载业务正在请求使用这些资源。资源管理器试图给每一个单独的承载业务提供所需要的QoS属性。资源管理器的一个例子是分组调度器。
业务量调整器，它是一个整形和策略功能，提供用户数据业务量与相关的UMTS承载业务的QoS属性的一致性。它驻留于GGSN和MT中，还存在于UTRAN中。
用于控制UMTS承载业务的QoS管理功能示于图-8。这些控制功能的目的是通过与TE中本地业务控制、以及外部网中外部业务控制的交互作用来支持UMTS承载业务的建立和修改，在用户平面上的UMTS承载业务的QoS管理功能示于图-9。这些功能共同按照由承载业务属性表达的、并且由UMTS承载业务控制功能建立起来的约定来维护数据传输特征。用户平面使用QoS属性。相关的属性由QoS管理控制功能提供给用户平面管理功能。
四个不同的QoS类在UMTS中被标准化并示于图-32。数据传输可以对于相应类别的应用数据或某一类的承载业务被最优化。这些类之间的主要区别因素是业务对延迟的敏感程度；会话类意味着业务量对延迟非常敏感(对于实时业务)，而后台类是对延迟最不敏感的业务类(对于非实时业务)。
为了详细表征一个承载业务，在UMTS中标准化了一组承载业务属性，并示于下表中。某一个QoS通过选择一组描述承载要求的属性值来被请求。参数根据被请求的承载业务类型而有所不同。
图-33示出哪些属性适合于哪个业务类。图-34提供不同QoS属性的作用的一个概述。QoS属性的精确定义可以在TS23.107中找到，它的当前版本为3.4.0。图中的*)表示参数根据其是UMTS BS描述符还是RAB服务描述符而有所不同。
一个预约与一个或多个分组数据协议(“PDP”)地址相关，即，在IP业务量的情况下是IP地址。每一个PDP地址由存储在MS、SGSN、和GGSN中的一个或多个PDP上下文来描述。默认值在保存预约信息的HLR中也是可用的。每一个PDP上下文可以与一个业务流模板(“TFT”)相关。在任何时候最多存在一个没有被指定给TFT的PDP上下文(与同一PDP地址相关)。PDP地址、PDP上下文、和TFT之间的关系在图-10中被提出。
一个PDP上下文是一个动态数据条目表，包括所有在MS和GGSN之间传送PDP PDU需要的信息，例如寻址信息、流控变量、QoS简档、收费信息，等等。UMTS承载业务和PDP上下文之间的关系是一对一映射，即，如果对于一个PDP地址有两个UMTS承载业务被建立，那么就有两个PDP上下文被定义。
PDP上下文程序在TS23.060中被标准化，它的当前版本为3.4.0，关于QoS简档和业务流模板(“TFT”)的概念从QoS的角度看是有关的。
UMTS QoS属性已经被选择并被定义，主要用于支持有效的无线电实现。一个QoS简档由一组UMTS QoS属性来定义。在PDP上下文激活期间RNC从SGSN处获得适当的RAB QoS。一个PDP上下文激活涉及三个不同的QoS简档-被请求的QoS简档、被协商的QoS简档、以及被预约的QoS简档(或默认的QoS简档)。
依据所需信息的类型，被存储的PDP上下文信息在MS、RNC、SGSN、GGSN和HLR中是不同的。至于QoS简档，应用如下GGSN被协商的QoS简档MS被协商的QoS简档、被请求的QoS简档、以及被预约的QoS简档SGSN被协商的QoS简档、被请求的QoS简档以及被预约的QoS简档RNC被协商的RAB QoS简档HLR被预约的QoS简档一个TFT是一个分组过滤器(或过滤器组)，用于将分组和正确的PDP上下文联系起来，以确保分组在适当的GTP隧道中被前向传输。TFT使得一个单个PDP地址关联几个PDP上下文成为可能，所述PDP上下文拥有不同的QoS简档。不论对于上行链路流还是下行链路流TFT都由MT管理并启动。上行链路TFT存在于MT中，而下行链路TFT存在于GGSN中。在PDP上下文激活/修改期间下行链路TFT被从MT发送给GGSN。下行链路TFT可以被加到一个生成时没有下行链路TFT的PDP上下文上，并且内容也可以被修改。
图-35示出TFT分组过滤器属性和有效组合。每一个TFT有一个标识符和一个评估优先顺序索引，所述索引在与共享同一PDP地址的PDP上下文相联系的所有TFT内是唯一的。MS管理TFT的标识符和评估优先顺序索引，以及分组过滤内容。
在图-3 5中的一些属性可以共存于一个分组过滤器内而其它属性彼此之间相互排斥。只有那些用“X”标记的属性才可以被指定用于单个分组过滤器。所有被标记的属性都可以被指定，但是必须指定至少一个。
PDP上下文信令是用于携带UMTS网中节点之间被请求的和被协商的QoS简档的手段。PDP上下文信令在接纳控制、协商和在QoS级上修改承载方面对于QoS处理有中心的作用。PDP上下文信令消息的交换通过参考图-11中的数字在下面被描述。
在步骤1中，一个RRC连接被建立起来。这个过程需要在MS和UTRAN之间建立一个连接。然而，从一个QoS的角度看，典型地建立阶段所做的只不过是指示所使用的无线电信道类型。
在步骤2中，MS将一个PDP消息发送给SGSN以便激活PDP上下文。被请求的QoS简档包括在这个消息中。在这个阶段，SGSN进行一个接纳检查并且如果系统超载的话，就可能限制被请求的QoS。
在步骤3中，SGSN将一个RANAP消息，“RAB分配请求”发送给RNC。RANAP或者无线接入网应用部分是一个应用协议，它用于支持无线接入网(“RAN”)和外部CN之间的信令和控制传输。RANAP允许RAN和电路交换或分组交换网之间的通信。这个建立无线电接入承载业务的请求携带RAB QoS属性，所述属性可能已被SGSN修改。
在步骤4中，RNC使用RAB QoS属性来确定对应QoS简档的无线电相关参数。这些参数可能包括传输格式的集合以及传输格式组合的集合。除此之外，UTRAN在这个承载上实现一个接纳控制。
在步骤5中，RNC将一个RRC消息，“无线电承载建立”发送给MS。所述RRC消息包括在步骤4中确定的无线电相关参数。
在步骤6中，UTRAN和MS应用无线电参数并且准备发送业务量。为了用信号通知这个情况，MS将一个“无线电承载建立完成”RRC消息发送给RNC。
在步骤7中，UTRAN将一个“RAB分配完成”RANAP消息发送给SGSN。
在步骤8中，一个跟踪过程可以被启动。这是用于调查用户的一个运行和维护功能。
在步骤9中，SGSN将一个携带QoS简档的“生成PDP上下文请求”发送给GGSN。然而，所述QoS简档可能有与在步骤2中MS请求的那些参数不同的参数。基于这个简档，在GGSN级别处一个接纳控制被实现并且如果，例如，系统过载的话，GGSN会限制QoS。GGSN将PDP上下文存储在它的数据库中。
在步骤10中，在一个“创建PDP上下文响应”消息中GGSN将被协商的QoS返回给SGSN并且SGSN将PDP上下文存储在它的数据库中。
在步骤11中，在一个“激活PDP上下文接受”消息中被协商的QoS简档从SGSN发送给MS。如果SGSN或GGSN已经修改了QoS简档，那么MS就必须或者接受或者拒绝这个简档。
在该过程中发生几个本地接纳控制。然而，因为与无线电相联系的带宽是最昂贵的资源，所以在确定无线电资源在PDP上下文激活或修改期间是否可用时UTRAN被考虑在内。这样，在UMTS中的接纳控制以一种无线电为中心的方式被实现。
要提供端到端IP QoS，需要在每一个域内管理QoS。在网关中的一个IP BS管理器被用于控制外部IP承载业务。由于IP网内使用不同的技术，所以这将通过翻译功能被传送到UMTS BS管理器。
同样需要在UE中提供一个IP承载业务管理器功能，其中承载业务管理器将应用的QoS要求映射成适当的QoS机制。
图-12示出在UE和网关节点这两个可能的位置中使用IP BS管理器来控制一个IP业务的实施方案。该图还指示在UE和网关节点中的IP BS管理器之间可选的通信路径。
IP BS管理器使用标准的IP机制来管理IP承载业务。这些机制不同于UMTS内使用的机制，并且具有控制业务的不同的参数。翻译/映射功能提供UMTS承载业务内使用的机制和参数与IP承载业务内使用的机制和参数之间的互通，并且它与IP BS管理器交互。
如果一个IP BS管理器既存在于UE中也存在于网关节点中，那么有可能这些IP BS管理器通过使用相关的信令协议彼此之间直接通信。
尽管IP级信令，例如RSVP可用于提供来自终端用户的一个QoS使能请求的端到端的有效性，但是它有大量缺陷。尤其是无线电资源利用的低效率、业务定义不适合异种网络、以及该过程不适合双向流。因此，需要在无线电网络中提供IP级别信令而避免这些不足。
发明内容
本发明通过在一个无线电网络(例如UMTS)中使用一个代理的方法来克服先前技术的多个缺点。对于RSVP支持和互通的一个解决方案被提出。
在本发明的上下文中，互通包括将一个协议中的信息映射成另一个协议中的信息。该信息可以包括一个业务量描述符或一个QoS定义。互通还包括通过使用互通一侧的状态机中的事件来触发该互通中另一侧的功能中的动作。此外互通还涉及通过使用互通的入口侧接收到的信息来配置互通的出口侧的整形/标记。
按照本发明，在一个移动终端中一种方法用于提供对IP信令的支持，其中所述移动终端与一个本地用户的终端设备相通信并且还与一个无线电网络相通信。所述方法包括的步骤有终止由用户终端设备发送的一个PATH消息；基于包含在该PATH消息中的RSVP参数来确定是创建一个新的PDP上下文还是修改一个现存的PDP上下文；以及通过无线电网络发送一个创建或修改PDP上下文的请求。
按照本发明的另一个方面，在一个移动终端中有一种方法用于提供对IP信令的支持，其中，所述移动终端与一个本地用户的终端设备相通信并且还与一个无线电网络相通信。所述方法包括的步骤有接收来自无线电网络的一个消息；从该消息中确定在终端设备中的一个应用是否需要RSVP信令；生成一个PATH消息；将该PATH消息发送给终端设备；接收来自终端设备的一个RESV消息；确定对一个PDP上下文的要求；以及通过无线电网络发送一个创建或修改PDP上下文的请求。
按照本发明的另一个方面，在一个移动终端中有一种方法用于提供对IP信令的支持，其中所述移动终端与一个本地用户的终端设备相通信并且还与一个无线电网络相通信。所述方法包括的步骤有接收一个由用户终端设备发送的PATH消息；按照一个本地配置修改该PATH消息；将被修改的PATH消息发送给无线电网络；接收一个来自无线电网络响应所述PATH消息的一个RESV消息；基于包含在RESV消息中的RSVP参数来确定是创建一个新的PDP上下文还是修改一个现存的PDP上下文；通过无线电网络发送一个创建或修改PDP上下文的请求；接收一个来自无线电网络的对创建或修改一个PDP上下文请求的响应；以及将所述RESV消息发送给终端设备。
按照本发明的另一个方面，在一个移动终端中有一种方法用于提供对IP信令的支持，其中所述移动终端与一个本地用户的终端设备相通信并且还与一个无线电网络相通信。所述方法包括的步骤有接收一个来自无线电网络的PATH消息；将该PATH消息发送给终端设备；接收一个来自终端设备的RESV消息；从该RESV消息中确定对一个PDP上下文的要求；通过无线电网络发送一个创建或修改PDP上下文的请求；接收一个来自无线电网络的、对创建或修改PDP上下文请求的响应；以及将RESV消息发送给终端设备。
按照本发明的另一个方面，有一种在一个PDP上下文中包括IP QoS信息以及通过一个UMTS网络携带QoS信息的方法。所述方法包括的步骤有在PDP上下文中包括QoS信息；以及在一个GGSN中进行QoS信息和RSVP之间的互通。
应强调术语“包括”在此申请文件中使用时，被用于指定存在陈述的特征、整体、步骤、或组件，但是不排除一个或多个其它特征、整体、步骤、组件、或其中组的存在或补充。
图-1是一个高级IP网络的方框图；图-2是一个方框图用于描绘一个使用端到端综合业务的网络的例子；图-3是一个方框图用于描绘一个使用RSVP代理的网络的例子；图-4是一个方框图用于描绘一个使用端到端区别服务的网络的例子；图-5是一个方框图用于描绘一个使用与区别服务互通的RSVP信令的网络的例子；
图-6是一个方框图用于描绘以一个DiffServ为模型的移动接入数据网；图-7是一个UMTS QoS体系结构的方框图；图-8是一个方框图用于描绘用于控制平面上UMTS承载业务的QoS管理功能；图-9是一个方框图用于描绘用于用户平面上UMTS承载业务的QoS管理功能；图-10是PDP地址、PDP上下文、以及TFT之间关系的方框图；图-11是一个PDP上下文消息交换的图；图-12是一个用于控制平面上UMTS承载业务的QoS管理功能和用于端到端IP QoS的QoS管理功能的方框图；图-13是一个描绘对于UMTS网络是透明的IP信令的图；图-14是一个描绘在GGSN中被解释的IP信令的图；图-15是一个本发明第一个实施方案的功能方框图；图-16是一个本发明第一个实施方案的消息流程图，其中MT接收来自TE的一个PATH消息；图-17是一个本发明第一个实施方案的消息流程图，其中MT接收来自网络的数据；图-18是一个本发明第二个实施方案的功能方框图；图-19是一个本发明第二个实施方案的消息流程图，其中MT接收来自TE的一个PATH消息；图-20是一个本发明第二个实施方案的消息流程图，其中MT接收来自网络的一个PATH消息；图-21是一个本发明第三个实施方案的功能方框图；图-22是一个本发明第三个实施方案的消息流程图，其中MT接收来自TE的一个PATH消息；图-23是一个本发明第三个实施方案的消息流程图，其中MT接收来自网络的一个PATH消息；图-24是一个本发明第三个实施方案的、定义建立阶段和数据阶段的消息流程图；图-25是一个信号流程图，其中UE支持PDP上下文消息中的IP特定单元并且GGSN提供与RSVP的互通；
图-26是一个本发明第四个实施方案的功能方框图；图-27是一个结合本发明第四个实施方案的一个网络模型的示意图；图-28是一个本发明第四个实施方案的消息流程图，其中GGSN调用RSVP消息用于上行链路流；图-29是一个本发明第四个实施方案的消息流程图，其中GGSN终止并调用RSVP消息用于下行链路流；图-30是一个示出承载建立阶段的消息流程图；以及图-31是一个信令流程图，其中UE支持PDP上下文消息中的IP特定单元并且GGSN提供与DiffServ的互通。
图-32示出在UMTS中被标准化的四个不同QoS类。
图-33示出哪些属性适合于哪个业务类。
图-34提供不同QoS属性的作用的一个概述。
图-35示出TFT分组过滤器属性和有效组合。
具体实施例方式
尽管IP级别信令，例如RSVP，可以被用于提供来自终端用户的一个QoS使能请求的端到端的有效性，但是它显示出大量缺点。
本发明通过使用一个代理的方法来克服在无线电网络上与IP级别信令相关的多个缺点。因此，IP级别信令的方法(例如RSVP)可以在一个无线电网络(例如UMTS)上使用，而不会浪费宝贵的无线电带宽。可以理解，IP级别信令对UMTS网是透明的或者IP级别信令在GGSN中可以被解释。在依据实施方案来讨论本发明之前，先讨论在这两种IP信令情况中涉及的互通原则是有用的。
图-15描绘了一个在用户终端设备(“TE”)和外部网络之间的一个网络配置的功能方框图。如图中所示，用户的TE与移动终端(“MT”)相连。TE可以是多个已知的计算设备中的任何一个，例如一个便携式计算机或一个个人数据助理。MT处理到通信网(例如一个UMTS或其它无线电网络)的接口。应该理解，MT可以在物理上被集成进TE或可以通过使用电缆、红外链路、或其它方法与TE相连。
UTRAN、或UMTS无线接入网，终止来自MT的无线电链路。UTRAN处理关联维护到MT的物理链路的任务并且不知道运行于TE或MT上的应用。同样，UTRAN不知道网络用户。
UMTS/GPRS核心网节点提供到外部互联网的路由选择和接入。这样，经UMTS发送的数据被接收到并被适当地格式化用于在IP网上传输。同样，接收自IP网的数据被适当地格式化用于经UMTS的传输。
图-15还示出关联每一个节点的多个功能。应用功能通常包括需要一个通信路径并可以由TE或MT执行的任何应用。常用应用功能的例子有万维网浏览器、多媒体客户机、以及音频工具。
同样在TE和MT内有IP信令功能。这些功能处理IP级别信令，例如RSVP。
UMTS功能处理关联在一个UMTS网上的通信的任务。这些任务包括PDP移动性管理、链路管理、无线电资源管理、以及移交过程。
IP功能包括可能需要的IP路由选择以便在一个IP网络中前向传输IP分组。
而图-15只示出从TE到外部网络的网络节点，应理解用户可能希望连接到另一个用户的TE或某个应用服务器。这第二个TE或服务器可以以与图-15所示相同的或相似的方式与外部网络相连。
在本发明的一个实施方案中，IP信令在MT中被终止。图-16是一个消息流程图，其中TE启动一个PATH消息并且MT终止RSVP信令。当PATH消息被接收到时，MT就接收到所有RSVP参数并确定是创建一个新的第二个PDP上下文还是修改一个现存的PDP上下文来携带业务量。之后第二个PDP上下文以一种本领域已知的且按标准定义的方式被创建或修改。
一旦第二个PDP上下文被成功地建立起来，MT就例示一个RSVP代理。RSVP代理可以处于一种RSVP代理终止信令的模式。在这个模式中，RSVP代理可以接收一个PATH消息并且生成一个RESV响应。MT还可以用一个RESV消息来响应初始的PATH消息。
图-17是一个相应的消息流程图，其中MT终止RSVP信令并且有来自外部网络的进入数据。在这种情况下，MT启动PATH消息。为了MT能启动RSVP PATH，必须要发生某个动作来触发它。触发可以由在现存的第二个PDP上下文中接收到匹配于某个过滤器规范的数据来导致，该过滤器规范标识出这个业务量应被提供一个不同的QoS。另一个可能性是用户是否(直接或者通过一个API从TE)配置MT以便为一个预期的数据流做准备。
如果MT确定应用需要RSVP信令，那么MT就启动一个PATH消息。一旦接收到来自TE的RESV消息，对PDP上下文的要求就可以被确定，并且第二个PDP上下文可以被创建/修改。
MT必须还要运行适合于RSVP过程的定时器。例如，对定时器周期性的满期进行响应，MT都将一个PATH消息发送给TE。MT必须被配置以确定如果没有接收到来自TE的RESV消息，那么要采取什么行动。例如，MT可能确定应用不再运行于TE上并且不再需要由PDP上下文定义的通信路径。
应理解，这个实施方案考虑到两个不同协议的互通。图-13示出在IP信令(RSVP)对UMTS网来说是透明的这种情况下的互通原则。在这种情况下，UE可能包括TE和MT，它提供一个IP承载业务(“BS”)功能，通过使用到远程的IP层信令来使能端到端QoS。在UE和GGSN中的IP BS管理器之间没有IP层信令。然而，GGSN可以利用与PDP上下文有关的信息，所述PDP上下文在UMTS BS管理器之间被用信号通知并且通过翻译/映射功能来提供。
在图-13中，假定UE和GGSN提供DiffServ边缘功能并且骨干IP网是DiffServ使能的。除此之外，UE可以支持RSVP信令，该信令在UE内互通以便控制DiffServ。
在UMTS接入网(从UE到GGSN)上的QoS控制可以通过使用PDP上下文信令从终端来实现。可替换地，SGSN访问的预约数据可能优先于通过信令从UE请求的QoS。
终端经RSVP协议可以支持信令以便控制在本地接入和在远程接入的QoS。终端还可以支持DiffServ以便控制通过骨干IP网的IP QoS。RSVP信令协议可被用于不同业务。但是希望只有使用综合业务(“IntServ”)语义的RSVP才被支持，尽管在将来，新的业务定义和语义可能被引入。同样支持RSVP信令的实体可以完全支持用于IntServ和IntServ/DiffServ互通的规范。如果不支持，它们被希望设置中断比特。
用于无线接入的QoS由PDP上下文来提供。UE可以通过用于PDP上下文的信令来控制无线QoS。用于PDP上下文的特征可以派生自RSVP信令信息，或可以使用其它的信息。
IP层的QoS在两个级别上实现。端到端QoS由RSVP信令控制。尽管在QoS模型中RSVP信令可以被端到端使用，但是它不必被所有的中间节点支持。相反，DiffServ被用于提供贯穿整个骨干IP网的QoS。
在UE处，数据还被分类用于DiffServ。按照或者是RSVP信令信息或者是DiffSefv机制，中间的QoS域可以应用QoS。在这个实施方案中，UE提供RSVP和DiffServ域之间的互通。GGSN可以覆盖来自UE的DiffServ设置。这个GGSN可以使用与PDP上下文有关的信息以便选择合适的DiffServ设置来应用，如图-13所示。
端到端QoS由UE中的一个本地机制、在UMTS接入网上的PDP上下文、贯穿骨干IP网的DiffServ、以及在远程接入网的DiffServ提供，它们也在图-13中被示出。RSVP信令可以在本地和远程接入处控制QoS。这个功能可以被用于确定用于PDP上下文的特征，这样UE就可以实现RSVP信令和PDP上下文之间的互通。
UE可以提供DiffServ的控制，尽管这可能被GGSN覆盖。事实上，UE确定PDP上下文和DiffServ之间合适的互通。
在这个实施方案中，互通可以通过将在一个协议中的信息映射成另一个协议中的信息来实现。例如，在TE始发PATH消息的情况下，在RSVPPATH中的业务量描述符被映射成不同的UMTS属性并且在UMTS属性中的QoS定义被映射成RSVP RESV响应。同样，在MT始发PATH消息的情况下，业务量描述符可以在MT中被配置或MT中应用功能生成的信息可以被映射成RSVP PATH。在RSVP RESV中的QoS定义可以被映射成UMTS属性。
互通还可以通过使用在一个协议的状态机中的事件来触发实现其它协议的功能中的动作而实现。例如，在TE始发PATH消息的情况下，PATH消息的接收可以触发第二个PDP上下文的创建或修改。创建/修改PDP上下文响应的接收会触发RSVP RESV的生成并且它还是一个生成带有流被接收到的指示的RSVP RESV的条件。同样，在MT始发PATH消息的情况下，MT中应用功能生成的一个触发激活RSVP PATH。创建/修改PDP上下文响应的接收会触发RSVP软状态消息生成的开始。
这个实施方案允许在一个TE，例如一个带有网络使能操作系统(例如微软Windows)的膝上型电脑中运行的标准应用使用一个标准IP信令机制，例如RSVP。通常，这种类型的机制会需要额外的开销，这会过度地增加无线网络的负担。在这个实施方案中，IP信令不必经无线网络被发送，这会使得无线资源被优化。当使用RSVP信令时，这特别重要，因为RSVP信令必须定期地生成软状态信息用于保活及其它目的。
图-18描绘了一个在用户终端设备(“TE”)和外部网络之间的一个网络配置的功能方框图。该图包括先前结合图-15描述的许多组件。在图-18中，IP信令可以被端到端使用。因此，IP信令功能已经被加到UMTS/GPRS核心网节点和外部网上。如前所述，远端可以是另一个用户或一个外部应用服务器，它可以类似地连到外部网络上。
在图-18中示出的网络配置可以由本发明一个可替换的实施方案来适应。在这个实施方案中，IP信令被发送给远方。图-19是一个消息流程图，其中MT截取来自TE的进入PATH消息。当MT接收到PATH消息，MT就可以修改PATH参数以符合一个本地配置。之后PATH消息被前向传输给网络。当RESV响应被MT接收到时，MT就使用RESV响应中的信息，连同相关的本地配置一起，最终确定PDP上下文需要的参数。之后MT创建或修改一个PDP上下文以反映这些网络参数并且被调整的RESV消息被发送给TE。用这种方式，不同的网络组件可以基于可用的资源来修改业务参数。
图-20是一个对应的消息流程图，其中MT放过来自外部网的PATH消息，但是截取来自TE的RESV响应。当PATH消息经无线接口被接收到时，PATH消息被传递给TE。当TE用RESV消息响应时，MT截取并且可以修改RESV参数以符合一个本地配置。MT还可以创建或修改一个PDP上下文以反映这些希望的网络参数。对创建或修改一个PDP上下文的请求被前向传输给网络从而建立PDP上下文。一旦PDP上下文被建立起来，那么被修改的RESV消息就被向下传。
正如所理解的，这个实施方案考虑到两个不同的IntServ业务或带有不同参数的同一业务的两个实例之间的互通。这种互通可以通过将在一个协议中的信息映射成另一个协议中的信息来实现。例如，在TE始发PATH消息的情况下，最后得到的RESV消息包含其中使用的不同的UMTS属性以便创建或修改PDP上下文。在接收到的创建/修改PDP上下文响应中的UMTS属性被映射成RESV消息中对应的参数并且被发送给TE。类似地，在MT接收到来自网络的PATH消息的情况下，从TE接收到的对应的RESV消息包含被映射成不同UMTS属性并且被用于生成一个创建或修改PDP上下文消息的参数。从网络接收到的、在创建/修改PDP上下文响应中的UMTS属性被映射成RESV消息中的参数，它经网络被发送。在这种方式下，业务量描述符和QoS参数可以被从一个协议映射成另一个协议。
互通还可以通过使用在一个协议的状态机中的事件来触发实现其它协议的功能中的动作来完成。例如，在TE始发PATH消息的情况下，在MT接收到RESV消息会触发一个创建或修改PDP上下文消息的生成。成功接收RESV消息还是一个生成创建/修改PDP上下文消息的条件。类似地，在MT中一个创建或修改PDP上下文响应的接收会触发发送给TE的RESV消息的生成并且它还是一个生成带有一个流被接收到的指示的RESV消息的条件。同样，对于PATH消息经网络被接收的情况，在MT处一个RESV消息的接收触发一个创建或修改PDP上下文消息的生成。当MT接收到一个创建/修改PDP上下文响应时，这个事件触发被发送给远方的一个RESV消息。成功地接收创建/修改PDP上下文响应还是一个生成带有流被接收到的指示的RESV消息的条件。PATH消息的接收可以触发一个第二个PDP上下文的创建或修改。一个创建/修改PDP上下文响应的接收触发RSVP RESV的生成并且它还是一个生成带有流被接收到的指示的RSVP RESV的条件。
这个实施方案允许在一个TE，例如一个带有网络使能操作系统(例如微软Windows)的膝上型电脑中运行的标准应用使用一个标准IP信令机制，例如RSVP。RSVP信令被允许与在MT中的UMTS信令互通并被端到端发送以便允许远程设备与UMTS系统和终端交互。因此，这个实施方案提供端到端的处理用于控制端到端用户流。
这个实施方案一个潜在的缺点是在PDP上下文已经被建立起来之后需要继续支持端到端的RSVP信令。正如前面解释的，对RSVP信令的支持需要周期性的传送PATH消息和RESV响应。这会导致无线带宽的低效使用。
图-21描绘了一个在用户终端设备(“TE”)和外部网络之间的一个网络配置的功能方框图。该图包括先前结合图-15和17描述的许多组件。在图-21中，MT和UMTS/GPRS核心网节点之间的IP信令路径只在PDP上下文建立期间才被使用。因为在数据阶段MT和GGSN使用的是分离程序。如前所述，远端可以是另一个用户或一个外部应用服务器，它可以类似地连到外部网络上。
在图-21中示出的网络配置可以由本发明一个可替换的实施方案来提供。在这个实施方案中，RSVP会话被端到端使用。然而，在一个性能增强模式下的一个RSVP代理在MT和网关处被插入。在这个模式下代理的目的是通过使用第二个PDP上下文在两个代理之间将RSVP会话特性从一个软状态变成硬状态。这改进了RSVP会话的可靠性，同时减少了经无线接口的信令量。
图-22是一个消息流程图，反映了响应于一个来自TE的进入PATH消息，MT利用RSVP代理以便前向传输RSVP信令的情况。正如在前述实施方案中，当MT接收到PATH消息时，MT可以修改PATH参数以符合一个本地配置。之后PATH消息被前向传输给网络。当RESV响应被MT接收到时，MT使用在RESV响应中的信息，连同相关的本地配置，以最终确定PDP上下文需要的参数。之后MT创建或修改一个PDP上下文以反映这些网络参数并且被调整的RESV消息被发送给TE。
在接收到第二个PDP上下文请求时，一个RSVP代理业务被例示。这个RSVP代理业务的实例按照通常的RSVP信令与到外部网络的RSVP会话关联。一旦第二个PDP上下文和代理业务被建立起来，RESV就如前所述被传送给TE。这一点之后，在MT处接收到的PATH消息被本地响应，并且在网关处PATH消息被周期性地生成。只有当RSVP会话中有变化时，被更新的PATH或RESV消息才被发送给其它代理。
对于来自外部网络的RSVP会话，该序列类似于端到端，例外是本地代理是用PDP上下文来安装的。这在图-23中被示出。
图-14示出IP信令(RSVP)在GGSN中被解释并用于与骨干网互通的情况下的互通原则。在这个情况下，UE实现一个IP BS功能，该功能通过使用到远端的IP层信令来使能端到端QoS。然而，UE依赖这个至少由接入点(GGSN)使用的端到端的通信以便提供端到端QoS。
在图-14中，假定UE和GGSN支持RSVP信令，该信令可以直接控制QoS，或者与DiffServ互通。骨干IP网可以支持RSVP，DiffServ，或者两者。
终端经RSVP协议可以支持信令以便经端到端路径来控制QoS。GGSN还支持RSVP信令，并且使用这个信息而不是PDP上下文来控制通过骨干IP网的QoS。尽管通过核心的QoS控制可以可选地通过每流资源预留来被支持，但是它被希望通过在GGSN处与DiffServ互通来支持。RSVP信令协议可以被用于不同业务。但是希望只有使用综合业务(IntServ)语义的RSVP才被支持，尽管在将来，新的业务定义和语义可能会被引入。支持RSVP信令的实体完全支持用于IntServ和IntServ/DiffServ互通的规范。如果不支持，它们被希望设置中断比特。
在UMTS接入网(从UE到GGSN)上的QoS控制还可以通过使用PDP上下文信令从终端来实现。可替换地，SGSN访问的预约数据可能优先于通过信令从UE请求的QoS。
IP层的QoS在两个级别上实现。端到端QoS由RSVP信令控制。尽管RSVP信令可以在QoS模型中端到端出现，但是它不必被所有的中间节点支持。DiffServ被用于贯穿整个骨干IP网提供QoS，尽管可选地每一个节点可以支持RSVP信令及每流的资源分配。
GGSN支持RSVP信令并且扮演RSVP和DiffServ之间的互通点。按照RSVP或DiffServ机制，中间的QoS域可以应用QoS。
端到端QoS可以由在下图中示出的实施方案中UE中的一个本地机制、在UMTS接入网上的PDP上下文、贯穿骨干IP网的DiffServ、以及在远程接入网的RSVP提供。RSVP信令可以在本地接入处控制QoS。这个功能可以被用于确定用于PDP上下文的特征，这样UE就可以实现RSVP和PDP上下文之间的互通。
如图-24所示，这个实施方案提供了GGSN中的一个网关功能，它在用户流进入数据阶段时仿真一个RSVP代理。这个实施方案允许在一个TE(例如一个带有网络使能操作系统，例如微软Windows的膝上型电脑)中的标准应用使用一个标准IP信令机制，例如RSVP。在建立阶段，RSVP信令被如前述实施方案中所描述的那样允许在MT中互通并被端到端地用信号通知以便允许远程设备与UMTS系统/终端交互。在数据阶段，软状态处理(即定期地生成软状态信息用于保活及其它目的)在MT和GGSN中被本地进行。这个实施方案优化了无线资源，因为IP信令不必在数据阶段期间经无线发送。这种优化的实现不损害在建立阶段的端到端处理。
基于前述实施方案，功能可以被加到GGSN和MT上以便在GGSN和MT中提供互通的能力。例如，MT可以被提供一个IP BS管理器以及在IP BS管理器和UMTS功能之间的一个互通功能。这允许在PDP上下文激活/修改消息中捎带确认在IP BS管理器中生成的业务量描述符和QoS信息。除此之外，GGSN可以被提供IP BS管理器功能，该功能可以实现呼叫接纳控制以及与其它网络管理组件(例如带宽经纪者)之间的互通。在GGSN中的IP BS管理器还可以与网络中的策略判决功能互通。GGSN可以被提供在UMTS功能和IP BS管理器之间的一个互通功能。图-25示出当GGSN支持和模仿到外部网络的IP信令时应用的互通原则。
在这个实施方案中，UE实现一个IP BS功能，该功能允许端到端QoS而没有到GGSN中IP BS功能、或者是远程主机的IP层信令和协商。UE通过使用上下文激活/修改消息中的IP特定单元，向GGSN提供IP级别端到端QoS信息，以便使GGSN中的一个RSVP功能增强互通的选项。到远程主机的端到端IP QoS承载业务从GGSN处控制。
实施方案假定GGSN支持DiffServ边缘功能，并且骨干IP网是DiffServ使能的。这个实施方案不阻止骨干IP网具有RSVP非透明路由器。
GGSN可以使用在PDP上下文激活/修改消息中的IP特定单元来调用RSVP消息以便在骨干IP网中建立到远程主机的上行链路和下行链路流。例如，在上行链路方向，GGSN可以使用在PDP上下文激活/修改消息中的IP特定单元以便生成带有希望的QoS和业务量规范的RSVP PATH消息，去往指定的目的IP地址。同样，GGSN DiffServ边缘功能可以使用在PDP上下文激活/修改消息中的IP特定单元以便选择适当的DiffServ设置来应用。PDP上下文激活/修改消息中的IP特定单元可以是从UE到GGSN的。
在这个实施方案中，在UMTS接入网(从UE到GGSN)上的QoS控制还可以通过使用PDP上下文信令从终端来实现。可替换地，SGSN访问的预约数据可能优先于通过信令从UE请求的QoS。
用于下行链路方向的QoS可以由UE和GGSN之间的PDP上下文来控制。GGSN终止接收到的来自远程主机的RSVP信令，并且当处理RSVP时可以使用在PDP上下文激活/修改消息中的IP特定单元内的信息。在上行链路方向上的QoS由PDP上下文控制，一直到GGSN。GGSN可以使用在PDP上下文激活/修改消息中的IP特定单元来提供与到远程主机的RSVP的互通。在PDP上下文激活/修改消息中的IP特定单元可以考虑RSVP会话的建立。
端到端QoS可以由UE中的一个本地机制、在UMTS接入网上的PDP上下文、贯穿骨干IP网的DiffServ、以及在远程接入网的RSVP来提供。
当设计一个UMTS系统时，要标识两个要求。第一、用于提供端到端QoS的UMTS QoS协商机制不应该对应用层信令协议作任何假定。第二、UMTS网应能够协商还用于移动终端和应用的端到端QoS，所述移动终端和应用不能够使用除了UMTS提供的QoS协商机制之外的QoS协商机制。
端到端QoS提供暗示外部IP网中的资源需要由GGSN中的IP BS管理器来管理。对于IP BS管理器有不同的IP资源管理技术来管理IP资源，并且其中一些技术包含GGSN中的呼叫接纳控制(“CAC”)功能。为了使GGSN能够行使CAC，可能需要关于IP业务量(例如，平均和峰值速率、要求的QoS和目的地)的信息。
上面的第一个要求暗示初始终端不能依靠应用级信令来检验资源是否是贯穿网络及在远程接入处是可利用的。应遵循这样一个资源检验必须在承载级别上实现。如果UE没有实现这个承载级别请求，那么GGSN可能需要实现这个功能，并且要求关于目的IP地址的信息以便实现一个CAC判决。
上面列出的第二个要求隐含端到端QoS必须被提供给甚至没有实现IP BS管理器功能并且只使用UMTS BS管理器(例如，PDP上下文信令)的终端以便请求UMTS网内的资源。
图-26描绘了一个网络方框图，其中互通的功能在GGSN中被支持。除了在前述实施方案中讨论的功能之外，已加上额外的功能。例如，外部功能是UMTS之外的服务器或节点中的任何功能。带宽经纪者是一个处理传输资源的网络管理的节点内的一种功能。它掌握网络中当前资源的情况。IP BS管理器可以发布一个资源请求并且带宽经纪者基于网络中当前资源的情况或者拒绝该请求或者确认它。策略判决功能有与带宽经纪者对应的作用。策略判决功能引入除单纯的资源可利用性之外的其它因素。例如，策略判决功能可以使用时刻、使用的应用、以及目的IP地址作为分配带宽中的因素。
从上面描述的要求和讨论中，遵循UE可能需要用信号通知GGSN与端到端QoS有关的信息。在这个实施方案中，与端到端QoS有关的信息可以作为一个新的信息属性被加到现存的PDP上下文上。这个端到端QoS属性对UMTS网可以是透明的并且可以在现存的PDP上下文信令里捎带确认。
图-27是将被用于描述这个实施方案的网络模型的一个示意图。PDP上下文适当的扩展依靠实际上是在GGSN中实现的IP BS功能。依靠GGSN中的呼叫接纳控制范围，我们区分下面两种情况。
在第一种情况下，CAC基于资源的可利用性，GGSN对该资源可控制。在这种情况下，需要的QoS信息可以通过在UMTS BS管理器和IP BS管理器之间的翻译功能从现存的PDP上下文中提取出来。为了便于有效利用IP资源并且考虑到基于RSVP参数的策略判决，PDP上下文可以携带对IP承载来说是特定的额外QoS相关信息。例如，这样一个额外的参数可以规定业务量描述符和QoS描述符。这种描述符可以基于与标准IP机制有关的业务，例如区别业务或综合业务。可替换地，这些描述符可以基于一般的IP承载的概念。
在第二种情况下，CAC额外地基于在出口SLA处的资源情况。在这种情况下，目的IP地址需要被携带在PDP上下文中(除第一种情况下的描述符之外)。
互通、策略控制、以及接纳控制是具有不同目的的不同概念。然而，这些可以在实际实现(因为在实现过程中一个实现可能是依赖于另一个实现的一部分)中重叠并且基本上涉及相同的或相似的RSVP/DS参数集合。在GGSN处实现哪些功能是一个运营商选择的问题。设想通过使用涉及在PDP上下文激活和修改消息中IP特定单元的单一机制来为轻型移动装置同时针对这三个功能是可能的。为了便于描述，这个机制将被称作“UMTS特定的IP QoS机制”。
尽管有好的设计的核心原则，但是用于实现上述功能的精确性或完整性的固有要求连同用于解决方案的净度(确保层的分离和独立)，以及用于将来解决方案的牢固性的一般原则，都有一个使UMTS特定的IPQoS机制更加复杂的趋势，并且可能使主要目标受挫，而所述主要目标是允许简单的轻型移动设备的实现。
这样就提出了当使用UMTS特定的IP QoS机制时，某些假定和限制要被应用。这些假定和限制包括1.一个PDP上下文在每个方向应携带最多仅一个IP级别流(即，在一个PDP上下文中没有单一方向上的IP级别流的复用)。
2.如果UE希望在GGSN处支持UMTS特定的IP QoS机制，那么下面的信息应从UE传送给GGSN。然而，UMTS特定的IP QoS机制只携带在UMTS级别机制中不可用的信息的最小子集。
·一个对UMTS特定的IP QoS机制支持的请求的指示，以便使它与端到端IP级别QoS机制互通·流方向的一个指示·指定希望的QoS级别的一个业务量规范·明确定义IP级别上的数据分组集合或“流”的一个过滤器规范，其将接收在业务量规范中定义的QoS3.对UMTS特定的IP QoS机制支持的请求的指示，以与端到端IP级别QoS机制互通。UE应指示它对在GGSN处互通的请求从而获得端到端QoS。这个指示应通过UMTS特定的IP QoS机制从UE发送给GGSN。然而，这个指示不阻止GGSN可能会覆盖或者忽略UE请求，并且它是一个运营商选择是否实现互通、策略控制、或接纳控制、或这些功能的组合的问题。同样，如果UE不需要端到端QoS或者不关心，那么这可通过完全没有UMTS特定的IP QoS属性来隐含地指示给GGSN。
4.流方向的指示。UE应提供与流的方向有关的信息。这个指示可以从UMTS特定的IP QoS机制指示参数中派生出来，所述参数应可以被单独设置以用于上行链路或下行链路。这样，UMTS特定的IP QoS机制不必携带明确的流方向的指示。
5.业务量规范。要简化轻型UE中的实现，IP级别QoS参数应按照示于图-16中的翻译功能在GGSN处从UMTS承载业务属性中派生出来。如果在PDP上下文激活/修改消息中对应的UMTS级别QoS参数是不可用的，那么UE只需要提供IP级别QoS参数。还有，UE提供的QoS参数集合应被指定为一个最小的。所述参数有峰值数据速率[p]、令牌桶速率[r]、最大分组尺寸[M]、以及令牌桶尺寸[b]。参数的定义符合Token_Bucket_Tspec参数(如在IETF RFC2215中定义的业务号1、参数127)。依靠GGSN选择的用于互通、策略控制、或接纳控制的IP级别机制(RSVP或DS)，GGSN作如下工作·RSVP情况GGSN应使用由UE提供的峰值数据速率[p]、令牌桶速率[r]、最大分组尺寸[M]、以及令牌桶尺寸[b]参数。GGSN应提供下面的参数，其中必须的-最小策略单元[m](派生自应用层信息，例如，派生自IP MM CN SS，或是一个默认值)、QoS控制业务类型(派生自GGSN中的RSVP主机能力或是一个默认值)、速率[R]和备用项(slackterm)[S](派生自进入RSVP Path消息或是一个默认值)。在GGSN中主机RSVP的实现被希望提供默认的ADSPEC，所述ADSPEC依靠对主机来说已知的QoS控制业务。在PATH/RESV消息中其它有关的初始值也由GGSN来提供(例如，完整性参数、策略数据、刷新周期、样式参数等等)。
·DS情况GGSN应使用由UE提供的令牌桶速率[r]、以及令牌桶尺寸[b]参数来设置/配置业务量简档(用于确定一个特定的分组是在简档中或是在简档外的规则)。
6.过滤器规范。UE应只需维护一个过滤器规范，它明确地定义IP级别上的数据分组集合或者“流”，它们将接收在业务量规范中定义的QoS。过滤器规范应被用于在UMTS级别上的TFT，以及在IP级别上的过滤器规范。过滤器参数有源地址、目的地址、协议号(IPv4)或下一个头标(IPv6)、目的端口、源端口、IPSec安全参数索引(SPI)、流标签(IPv6)。与TS23.060中TFT的使用相比较，将有额外被规定的限制，所述限制与可能的依靠IP流的类型或特性的过滤器参数的组合有关(例如只允许有一个过滤器、单个端口号对端口范围、不包括TOS/业务量类别等等)。限制应在一个单独的文档中被规定，因为它超出TS23.107的范围之外。
·下行链路情况下行链路的TFT应符合用于下行链路方向的IP级别过滤器规范。这可能涉及额外的与下行链路TFT中的参数有关的限制。这样，UMTS特定的IP QoS机制不必携带下行链路的TFT。
·上行链路情况上行链路的TFT应符合用于上行链路方向的IP级别过滤器规范。这可能涉及额外的与上行链路TFT中的参数有关的限制。既然当前的UMTS GPRS规范限制了UE中的上行链路的TFT，那么UMTS特定的IP QoS机制应从UE携带上行链路的TFT到GGSN。涉及的过滤器参数将使用与在TS23.060中定义的TFT相同的定义/用法。
注意位于轻型UE中的一个应用实例不会自己参与端到端QoS控制过程并且不会规定使用哪一种QoS控制业务类型(对于RSVP)或PHB(对于DS)。所述应用将给UE提供一个基本的业务量规范和一个过滤器规范。将由GGSN来选择适当的IP级别机制以使用。GGSN怎样做选择(UE是否指示优先、或者是否APN相关、或者来自上层的策略、或者就是默认的)将在以后研究。
UE通过使用在PDP激活/修改消息中的IP特定单元将IP级别的端到端QoS信息提供给GGSN，并且GGSN使用这个信息来调用RSVP消息从而建立上行链路以及下行链路流。RSVP信令如图-28和29所示由GGSN生成并终止。在这些图中，RSVP PATH消息和PDP上下文之间的关联在GGSN中被实现。
图-30示出一个承载建立阶段。不同的互通方面在下面通过参考所述阶段来被讨论。
如在前述实施方案中，互通的一个方面是将一个协议中的信息映射成另一个协议中的信息。例如，业务量描述符和QoS定义可以被如下映射。
当UE启动建立阶段时，在UE中IP BS管理器的PATH或RESV过程中被接收到或被生成的业务量描述符被映射成IP特定单元中对应的属性并且在PDP上下文激活或修改消息中被发送。当UE终止建立阶段时，UE接收到一个创建或修改第二个PDP上下文响应并且与业务量描述符相关的属性可以被映射成对应的RSVP单元。RSVP单元可以在UE的RESV处理中由IP BS管理器来使用。
如图-28所示，当GGSN接收到在IP特定单元中的业务量描述符时，所述业务量描述符被映射成RSVP业务量描述符并在到外部网络的RSVPPATH消息中被使用。它还可以被映射成用于呼叫接纳控制和策略的属性。
在到GGSN中IP BS管理器的RESV消息中接收到的业务量描述符可以被映射成PDP上下文激活/修改响应消息中的一个UMTS属性。它还可以被映射成用于呼叫接纳控制和策略的属性。
在图-29中，当GGSN接收到在PDP上下文激活/修改消息的IP特定单元中的业务量描述符时，所述业务量描述符被映射成RSVP业务量描述符并在被发送到外部设备的RSVP RESV消息中被使用。它还可以被映射成用于呼叫接纳控制和策略的属性。
一个接收到的RSVP PATH消息的业务量描述符可以被映射成PDP上下文激活/修改响应消息中对应的属性。它还可以被映射成用于呼叫接纳控制和策略的属性。
同样，当UE启动建立阶段时，在UE中IP BS管理器的RESV过程中被接收到或被生成的QoS属性被映射成IP特定单元中对应的属性并且在一个PDP上下文激活或修改消息中被发送。当UE终止建立阶段时，UE接收到一个创建或修改第二个PDP上下文响应并且UMTS QoS属性可以被映射成对应的RSVP单元并且在UE的RSVP RESV处理中由IP BS管理器来使用。
如图-28所示，在到GGSN中IP BS管理器的RSVP RESV消息中接收到的RSVP QoS属性可以被映射成PDP上下文激活/修改响应消息中的一个UMTS QoS属性。它还可以被映射成用于呼叫接纳控制和策略的属性。
在图-29中，当GGSN接收到PDP上下文激活或修改消息的QoS属性时，它被映射成RSVP QoS并在被发送到外部设备的RSVP RESV消息中使用。它还可以被映射成用于呼叫接纳控制和策略的属性。
互通的另一个方面涉及使用互通中一侧的状态机中的事件来触发互通中另一侧的功能中的动作。例如，当UE启动建立阶段时，在UE中的IP BS管理器的RSVP启动过程(RSVP PATH过程)触发一个要在上行链路发送的PDP上下文激活/修改消息。一个创建或修改第二个PDP上下文响应的接收触发UE中的一个RSVP RESV处理并结束建立阶段。
如图-28所示，当GGSN接收到带有一个开始RSVP互通的IP特定单元的PDP上下文激活或修改消息时，就触发在GGSN的IP BS管理器中的一个RSVP主机的启动并且一个RSVP PATH消息向外部网络发送。在这种方式下，一个呼叫接纳控制可以被实现以便决定承载是否可以被接受。呼叫接纳控制过程可能涉及与一个带宽经纪者或一个策略判决服务器之间的互通。
GGSN中IP BS管理器中的RSVP RESV消息的接收会触发一个要发送的PDP上下文激活或修改响应消息并且结束建立阶段。在这种方式下，一个呼叫接纳控制可以被实现以便决定承载是否可以被接受。呼叫接纳控制过程可能涉及与一个带宽经纪者或一个策略判决服务器之间的互通。
在图-29中，接收到带有一个开始RSVP互通的IP特定单元的PDP上下文激活或修改消息会触发在GGSN的IP BS管理器中的一个RSVP主机的启动。在这种方式下，一个呼叫接纳控制可以被实现以便决定承载是否可以被接受。呼叫接纳控制过程可能涉及与一个带宽经纪者或一个策略判决服务器之间的互通。
一个RSVP PATH消息的接收触发从空闲到建立阶段的一个状态转移。依靠消息序列，它还可以触发一个要发送的PDP上下文激活或修改响应消息。
当RSVP主机被启动或GGSN的一个IP BS管理器已经进入建立阶段时，一个RSVP PATH消息被发往外部设备。在这种方式下，一个呼叫接纳控制可以被实现以便决定承载是否可以被接受。呼叫接纳控制过程可能涉及与一个带宽经纪者或一个策略判决服务器之间的互通。
互通还可以涉及使用在互通的入口侧接收到的信息以便配置互通的出口侧的整形或标记。例如，在涉及GGSN上行链路业务量的IP BS管理器的互通情况下，按照一个PDP上下文业务量合同和业务量描述符被接收到的业务量可以被标记并被整形以便符合外部网络的配置和装置。负责整形和标记的算法还可以考虑PDP上下文流的特征。
当处理在GGSN下行链路业务量的IP BS管理器中的互通时，下行链路分组在被作为一个PDP上下文流传送之前可以按照IP分组可能的标记被过滤及整形。IP BS管理器实现在接收到的分组的特定标记和一个特定PDP上下文流的QoS特征之间的互通。
特别是对于不能支持到GGSN中IPBS功能的IP层信令和协商的轻型UE，需要从UE传送IP级别QoS信息到GGSN用于多个目的，包括增强对GGSN中的DS和RSVP的互通的选项并且便于在GGSN处实现策略控制和接纳控制(“AC”)。
这个实施方案还将前两个实施方案的某些优点组合起来。特别是，无线资源被保留而不违背IP级别信令的端到端的概念。除此之外，这个实施方案卸下UE中的两个承载级别QoS处理的复杂性负担，从而便于发展高度优化和低功耗的移动终端。
与前述实施方案相比，这个实施方案具有完全符合被建立用于IP信令的原则的优点，而不会引入对在GGSN或TE/MT中的两个不同级别处对信令QoS的需要。
在一些应用中，希望提供IP BS管理器功能和DiffServ功能之间的互通。这可以通过修改前述实施方案来实现，这样GGSN就不提供一个IP信令主机功能。IP BS管理器将只提供到用于业务量聚合例如DiffServ的装置的互通。
如图-31所示，UE实现一个IP BS功能，该功能允许端到端QoS而没有到GGSN、或者是远程主机中IP BS功能的IP层信令和协商。UE通过使用上下文激活或修改消息中的IP特定单元，向GGSN提供IP特定信息，以便给GGSN的DiffServ边缘功能增强互通的选项。这个实施方案假定GGSN支持DiffServ边缘功能，并且骨干IP网是DiffServ使能的。
GGSN DiffServ边缘功能可以使用用于DiffServ分类器功能的IP特定信息，例如源和目的IP地址的一个组合、源和目的端口号、以及协议标识符。所述信息还可以用于DiffServ类接纳控制，例如来自UE用于一个特定流的被请求的端到端带宽可以被预先通知给GGSN，由GGSNDiffServ边缘来确定流是否被允许到某一个DiffServ类或一个入口点。结果是，GGSN可以选择适当的DiffSefv设置来应用。从UE传送给GGSN的PDP上下文激活或修改消息的IP特定单元(这结合前述实施方案已被讨论)也可以存在用于这个实施方案。
在这个实施方案中，在UMTS接入网(从UE到GGSN)上的QoS控制可以通过使用PDP上下文信令从终端来实现。可替换地，SGSN访问的预约数据可能优先于通过信令从UE请求的QoS。
由远程主机从远程网络到GGSN来控制用于下行链路方向的QoS。PDP上下文控制GGSN和UE之间的UMTS级别QoS。在上行链路方向上的QoS由PDP上下文控制，一直到GGSN。GGSN使用UMTS信令的IP特定单元与骨干IP网的DiffServ互通并控制到远程主机的IP QoS承载业务。
端到端QoS由UE中的一个本地机制、在UMTS接入网上的PDP上下文、贯穿骨干IP网的DiffServ、以及在远程接入网的DiffServ提供。注意在远程主机处的DiffServ控制在这个例子中被示出。然而，其它机制可以在远端使用，正如在其它实施方案中论证的那样。
IP级别信令，例如RSVP还没有被广泛使用。所以使用最频繁使用的DiffServ范例的一个轻型解决方案是有益的。
本发明已经就几个实施方案进行描述。根据这个公开内容，那些本领域的技术人员很可能使用本发明可替换的实施方案，例如包括额外的任务或使用可替换的组网设备。这些以及其它可替换的实施方案要在随后的权利要求的范围之内。
权利要求
1.用于一个网关通用分组无线电业务支持节点(GGSN)的方法，其中互联网协议的服务质量信息包括在分组数据协议上下文中，并且该网关通用分组无线电业务支持节点将按照一个互联网协议的服务质量相关的信令转换成按照一个资源预留协议的信令，并且进行相反转换。
2.通过到一个本地用户终端设备(UT)的第一个接口和到一个无线电网络(UTRAN)的第二个接口与一个无线电网络(UMTS)通信的移动终端(MT)，其特征在于一个用于终止资源预留协议(IP信令功能)的终端单元，一个用于将资源预留协议消息转换成分组数据协议消息并且进行相反转换的翻译单元(UMTS功能)。
全文摘要
在一个无线电网络中，IP信令的实现可以被用于提供端到端的服务质量。这可以通过在IP协议和无线电网络协议之间映射对应的参数以便达到希望的延迟和带宽要求来实现。在协议的状态机中的不同事件还可以被用于触发互通功能。
文档编号H04L12/56GK1592304SQ20041004841
公开日2005年3月9日 申请日期2001年1月25日 优先权日2000年1月25日
发明者G·福多尔, J·奥雅马, I·维德格伦, B·威廉斯 申请人:艾利森电话股份有限公司