CN101146052A - 网络通信中处理紧急业务的方法 - Google Patents

Abstract

本发明涉及一种网络通信中处理紧急业务的方法。该方法主要包括：首先，在紧急业务发起侧将紧急业务标识随紧急业务一起向网络侧发送；之后，当网络侧根据所述紧急业务标识确认收到的业务为紧急业务时，则将优先为该紧急业务分配资源。本发明的实现，使得在具体独立承载控制层实体的网络中可以有效区分出相应的紧急业务，并可以采用专门的资源分配策略为紧急业务进行资源分配，从而可以保证在需要紧急业务时，网络能保证业务的连通性和资源，减少意外和不必要的损失。

Description

网络通信中处理紧急业务的方法

技术领域

本发明涉及网络通信技术领域，尤其涉及一种网络通信中处理紧急业务的方法。

背景技术

随着Internet(互联网)规模的不断增大，各种各样的网络服务争相涌现，先进的多媒体系统层出不穷。由于实时业务对网络传输时延、延时抖动等特性较为敏感，当网络上有突发性高的FTP(文件传输协议)或者含有图像文件的HTTP(超文本传输协议)等业务时，实时业务就会受到很大影响；另一方面，多媒体业务占去了大量的带宽，这样，现有网络要保证的关键业务就难以得到可靠的传输。

基于上述现状，各种QoS(服务质量)技术应运而生。IETF已经建议了很多服务模型和机制，以满足QoS的需求。目前业界比较认可的是在网络的接入和边缘使用综合业务模型(Int-Serv)，在网络的核心使用区分业务模型(Diff-serv)。

由于区分业务模型(Diff-serv)仅设定优先等级保障QoS措施虽然有线路利用率高的特点，但具体的效果难以预测。因此，业界开始为骨干网区分业务Diff-Serv引入一个独立的承载控制层，建立一套专门的Diff-Serv QoS信令机制，如为了推动Diff-Serv的应用，IETF和一些厂商以及研究机构共同推动的QBone试验网上，使用带宽代理器(Bandwidth Broker)模型来实现网络资源和拓扑管理，有其他一些厂商提出了类似的QoS服务器/资源管理器技术来管理拓扑资源和协调各个区分业务Diff-Serv区域的QoS能力。

上述方法均为区分服务Diff-Serv网络专门建立一个资源管理层，管理网络的拓扑资源，由于传统的Diff-Serv定义具有局限性，为了不引起混淆，我们将上述资源管理区分服务Diff-Serv模型改称为具有独立承载控制层(或集中资源控制层)的网络模型。

如图1所示，在有独立的承载控制层的网络模型中，承载网控制服务器(包括带宽代理器(Bandwidth Broker)或者QoS服务器/资源管理器)配置了管理规则和网络拓扑，为客户的业务带宽申请分配资源。每个管理域的承载网控制服务器相互之间通过信令传递客户的业务带宽申请请求和结果，以及承载网资源管理器为业务申请分配的路径信息等。

当承载控制层处理用户的业务带宽申请时，将确定用户业务的路径。承载网资源管理器会通知边缘路由器按照指定的路径转发业务流。

承载网如何根据承载控制层确定的路径实现用户业务流按指定路由转发，目前业界现有的技术主要是利用MPLS技术，使用资源预留方式沿着承载控制层指定的业务流路径建立LSP，使用RSVP-TE或CR-LDP的显式路由机制建立端到端的LSP。

上述实现方法能够严格保证业务所需求的端到端QoS。但美中不足的是：目前的方案中对所有电信业务的处理一视同仁，即资源足够时接纳呼叫，资源不足时拒绝呼叫或降低服务质量。可是，网络中的某些紧急业务却需要无论网络资源状况如何，均应当无条件接纳并且不能降低其服务质量，例如110(报警电话)、119(火警电话)、120(救护电话)等关系重大的紧急业务。对于紧急业务如果仍采用一视同仁的处理办法，则在资源不足时，紧急业务将无法得到处理，因此将造成生命财产损失或重大事故。

然而，目前还没有一种可以在独立承载控制层网络中处理紧急业务的技术方案，以满足上述紧急业务的特殊需求。

发明内容

鉴于上述现有技术所存在的问题，本发明的目的是提供一种网络通信中处理紧急业务的方法，可以为独立承载层控制网络中的紧急业务提供相应的处理方案。

本发明的目的是通过以下技术方案实现的：

本发明提供了一种网络通信中处理紧急业务的方法，包括：

A、紧急业务发起侧将紧急业务标识随紧急业务一起向网络侧发送；

B、当网络侧根据所述紧急业务标识确认收到的业务为紧急业务时，则将优先为该紧急业务分配资源。

所述的步骤A包括：

在保证服务质量的网络中，当应用功能实体根据用户发起的会话的识别信息确定其为紧急业务时，则将紧急业务标识承载于服务质量请求消息中，并发送。

所述的会话的识别信息包括：

业务标识信息和业务号码信息。

所述的步骤A还包括：

所述的服务质量请求消息需要发送给网络侧的策略决定功能PDF/承载控制功能BCF。

本发明所述的方法还包括：

在网络侧为紧急业务预留资源。

所述的步骤B包括：

网络侧收到所述的服务质量请求消息，并确定其为紧急业务的服务质量请求时，则从所述为紧急业务预留资源中分配端到端的资源。

所述的步骤B包括：

网络侧收到所述的服务质量请求消息，并确定其为紧急业务的服务质量请求时，则为其进行正常的资源分配处理；

当正常的资源分配处理过程失败时，则从所述为紧急业务预留资源中分配端到端的资源。

所述的步骤B包括：

B1、网络侧收到所述的服务质量请求消息，并确定其为紧急业务的服务质量请求时，则基于网络侧未使用的资源为所述紧急业务分配资源；

B2、当网络侧没有足够的未使用的资源时，则按照预定的规则拆除非紧急或低级别业务占用的资源；

B3、将拆除业务获得的资源分配给该紧急业务。

本发明中，步骤B2所述的预定的规则具体为：

基于业务的优先级信息和/或业务的类型信息设置。

所述的步骤B还包括：

当网络侧成功为紧急业务分配相应的资源后，则向发起服务质量请求的实体返回资源分配成功消息。

由上述本发明提供的技术方案可以看出，本发明的实现，使得在PDF/BCF上可以有效区分出相应的紧急业务，并可以采用专门的资源分配策略为紧急业务进行资源分配，从而解决了在采用独立承载控制层实体的网络中对紧急业务的处理问题，可保证在需要紧急业务时，网络能保证业务的连通性和资源，减少意外和不必要的损失。

同时，本发明的实现还可以尽可能地减少紧急业务在资源抢占过程对其他优先级较高的业务的影响。

附图说明

图1为本发明应用的网络结构示意图；

图2为本发明所述的方法的实现流程图；

图3为本发明所述方法的主要处理过程示意图。

具体实施方式

本发明的主要目的是在有独立承载控制层的网络(简称BCF网络)中实现识别并处理紧急业务的功能，从而使得网络中的紧急业务可以被可靠地处理，避免给相应的用户造成重大损失。

如图1所示，本发明就是在各PDF(策略决定功能)/BCF(承载控制功能)上需要识别紧急业务，并无条件为紧急业务分配资源并下发策略。图1中策略决定功能PDF和承载控制功能BCF可以在同一物理实体中，也可在不同物理实体中，如BCF可以通过PDF与AF(应用功能)相连，也可以在某段网络中只有一种逻辑形态存在。

为对本发明所述的方法有进一步的理解，下面将结合附科对本发明所述的方法作详细的说明。

本发明所述的方法在具体实现过程中如图2和图3所示，包括以下步骤：

步骤21：用户向AF发起紧急业务会话；

步骤22：在AF上需要将紧急业务从众多的业务中识别出来，并向PDF/BCF发送携带紧急业务标识的请求业务资源消息；

为此，应用功能AF需要通过业务分析获知本次会话是否紧急业务，具体可以通过业务标识、号码分析等手段确定本次会话是否为紧急业务；如果确定为紧急业务，则向策略决定功能PDF或承载控制功能BCF申请QoS资源时，应在接口信令中传递紧急业务标识；

例如，当接口协议采用Diameter协议时，可在Diameter的AAR(AA请求)消息的Media-Component-Description AVP(媒体部件描述属性值对)中带上QoS请求类型AVP，该AVP将请求类型标志为紧急业务；根据协议标准情况也可以采用其它AVP，在此不做限定；如果采用其它接口协议只要在相应协议中扩展相应的业务级别类型表示机制，使得可以将紧急业务标识承载传输到PDF/BCF即可。

步骤23：PDF/BCF在收到该消息后，根据紧急业务标识可以确定该业务会话为紧急业务会话，需要按紧急业务流程处理；

如图3所示，所述的会话可能需要多级PDF/BCF进行资源的分配处理，但各个PDF/BCF上针对接收的包含有紧急业务标识的消息的处理过程相同，而且，在进行端到端的QoS信令传递时，紧急业务标识应当可以在PDF/BCF间传递，从而可以针对紧急业务采用单独的资源分配策略。

下面将仅以在一个PDF/BCF上针对紧急业务的资源分配处理过程为例进行说明。

仍参见图2所示，在PDF/BCF上，针对紧急业务的资源分配处理过程具体包括以下步骤：

步骤24：当PDF/BCF收到来自AF的紧急业务的资源请求时，如果PDF/BCF中专门预留有给紧急业务的资源，则可先从紧急预留资源中给该紧急业务分配端到端资源；

步骤25：判断资源分配是否成功，如果分配资源成功，则执行步骤26，否则，执行步骤27；

步骤26：返回资源分配成功响应消息，并向承载传输功能TPF/ER下发相应的策略信息。

步骤27：如果从预留资源中无法为紧急业务分配相应的资源，则再按正常业务流程处理为该紧急业务分配资源；

即根据紧急业务的QoS要求从普通资源中分配端到端的承载资源；

步骤28：判断资源分配是否成功，如果分配资源成功，则执行步骤26，否则，执行步骤29；

当然上述步骤24和步骤27的处理过程也可以采用相反的方式实现，即首先按照正常业务流程从普通资源中为紧急业务分配资源，不足时再从预留的紧急资源中分配。

步骤29：按照预定的规则拆除相应的会话，并将拆除会话获得的资源分配给所述紧急业务，当端到端都能满足紧急业务的资源要求后，则执行步骤26；

具体为：如果上述分配过程仍然确定资源不足，无法为该紧急业务分配资源，则需要从正常呼叫业务中按照运营商预定的规则，或者随机选择占用不少于紧急业务QoS资源要求的一个正常业务会话，强行拆除该会话，然后将资源分配给紧急业务；

当然，如果没有满足紧急业务资源的一个正常业务，则可选择多个正常业务拆除，从而使获得资源可以满足紧急业务的需要；

需要注意的是：强行拆除操作只能针对正常的普通业务，不能强行拆除已有的其它紧急业务。

如果所有资源都已被紧急业务占用，则新的紧急业务仍可以采用普通尽力而为方式传送。

因此，如果采用本发明所述的方法，对于紧急业务返回给AF的总是资源分配成功结果，并且即使在设备发生拥塞时也要保证紧急业务消息的交互。

上述过程中，紧急业务的识别也可以用业务优先级来表示，在接口协议中传递业务优先级信息，这样业务级别就可以不仅仅是正常和紧急两种了，而可以有更多种。此时，PDF/BCF在分配资源的过程中，如果本级别的资源不够，就可以使用低级别的资源，如果采用所有低级别的资源仍无法满足需要，则可以通过强拆低级别的资源来满足高级别业务的需要。通常强行拆除操作总是从最低级别业务着手。低优先级业务不能强行拆除本级或更高级别业务占用的资源。

综上所述，本发明解决了在采用独立承载控制层实体的网络中对紧急业务的处理问题，可保证在需要紧急业务时，网络能保证业务的连通性和资源，减少意外和不必要的损失。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (10)

1.一种网络通信中处理紧急业务的方法，其特征在于，包括：

A、紧急业务发起侧将紧急业务标识随紧急业务一起向网络侧发送；

B、当网络侧根据所述紧急业务标识确认收到的业务为紧急业务时，则将优先为该紧急业务分配资源。

2.根据权利要求1所述的网络通信中处理紧急业务的方法，其特征在于，所述的步骤A包括：

在保证服务质量的网络中，当应用功能实体根据用户发起的会话的识别信息确定其为紧急业务时，则将紧急业务标识承载于服务质量请求消息中，并发送。

3.根据权利要求2所述的网络通信中处理紧急业务的方法，其特征在于，所述的会话的识别信息包括：

业务标识信息和业务号码信息。

4.根据权利要求2所述的网络通信中处理紧急业务的方法，其特征在于，所述的步骤A还包括：

所述的服务质量请求消息需要发送给网络侧的策略决定功能PDF/承载控制功能BCF。

5.根据权利要求1至4任一项所述的网络通信中处理紧急业务的方法，其特征在于，该方法还包括：

在网络侧为紧急业务预留资源。

6.根据权利要求5所述的网络通信中处理紧急业务的方法，其特征在于，所述的步骤B包括：

网络侧收到所述的服务质量请求消息，并确定其为紧急业务的服务质量请求时，则从所述为紧急业务预留资源中分配端到端的资源。

7.根据权利要求5所述的网络通信中处理紧急业务的方法，其特征在于，所述的步骤B包括：

网络侧收到所述的服务质量请求消息，并确定其为紧急业务的服务质量请求时，则为其进行正常的资源分配处理；

当正常的资源分配处理过程失败时，则从所述为紧急业务预留资源中分配端到端的资源。

8.根据权利要求1至4任一项所述的网络通信中处理紧急业务的方法，其特征在于，所述的步骤B包括：

B1、网络侧收到所述的服务质量请求消息，并确定其为紧急业务的服务质量请求时，则基于网络侧未使用的资源为所述紧急业务分配资源；

B2、当网络侧没有足够的未使用的资源时，则按照预定的规则拆除非紧急或低级别业务占用的资源；

B3、将拆除业务获得的资源分配给该紧急业务。

9.根据权利要求8所述的网络通信中处理紧急业务的方法，其特征在于，步骤B2所述的预定的规则具体为：

基于业务的优先级信息和/或业务的类型信息设置。

10.根据权利要求1至4任一项所述的网络通信中处理紧急业务的方法，其特征在于，所述的步骤B还包括：

当网络侧成功为紧急业务分配相应的资源后，则向发起服务质量请求的实体返回资源分配成功消息。

Images