专利名称：网络通信中处理紧急业务的方法
技术领域：
本发明涉及网络通信技术领域，尤其涉及一种网络通信中处理紧急业务 的方法。
背景技术：
随着lnternet (互联网)规模的不断增大，各种各样的网络服务争相涌 现，先进的多媒体系统层出不穷。由于实时业务对网络传输时延、延时抖动 等特性较为敏感，当网络上有突发性高的FTP (文件传输协议)或者含有图 像文件的HTTP (超文本传输协议)等业务肘，实时业务就会受到很大影 响；另一方面，多媒体业务占去了大量的带宽，这样，现有网络要保证的关 键业务就难以得到可靠的传输。基于上述现状，各种QoS (服务质量)技术应运而生。IETF已经建议了 很多服务模型和机制，以满足QoS的需求。目前业界比较认可的是在网络的 接入和边缘使用综合业务模型(Int-Serv),在网络的核心使用区分业务模型 (Diff-serv)。由于区分业务模型(Diff-serv)仅设定优先等级保障QoS措施虽然有线 路利用率高的特点，但具体的效果难以预测。因此，业界开始为骨干网区分 业务Diff-Serv引入一个独立的承载控制层，建立一套专门的Diff-Serv QoS信 令机制，如为了推动Diff-Serv的应用，IETF和一些厂商以及研究^/L构共同推 动的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 (应用功能)相连，也可以在某段 网络中只有 一种逻辑形态存在。为对本发明所述的方法有进一步的理解，下面将结合附科对本发明所述 的方法作详细的iJL明。本发明所述的方法在具体实现过程中如图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资源要求的一个正常业务会话，强行拆除该会话，然后 将资源分配给紧急业务；当然，如果没有满足紧急业务资源的一个正常业务，则可选择多个正常 业务拆除，从而使获得资源可以满足紧急业务的需要；需要注意的是强行拆除操作只能针对正常的普通业务，不能强行拆除 已有的其它紧急业务。如果所有资源都已被紧急业务占用，则新的紧急业务仍可以采用普通尽 力而为方式4专送。因此，如果采用本发明所述的方法，对于紧急业务返回给AF的总是资源 分配成功结果，并且即使在设备发生拥塞时也要保证紧急业务消息的交互。上述过程中，紧急业务的识别也可以用业务优先级来表示，在接口协议 中传递业务优先级信息，这样业务级别就可以不仅仅是正常和紧急两种了 ， 而可以有更多种。此时，PDF/BCF在分配资源的过程中，如果本级别的资源 不够，就可以使用低级别的资源，如果采用所有低级别的资源仍无法满足需 要，则可以通过强拆低级别的资源来满足高级别业务的需要。通常强行拆除 操作总是从最低级别业务着手。低优先级业务不能强行拆除本级或更高级别
业务占用的资源。综上所述，本发明解决了在采用独立承载控制层实体的网络中对紧急业 务的处理问题，可保证在需要紧急业务时，网络能保证业务的连通性和资 源，减少意外和不必要的损失。以上所述，仅为本发明较佳的具体实施方式
，但本发明的保护范围并不 局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可 轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明 的保护范围应该以权利要求的保护范围为准。
权利要求
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还包括当网络侧成功为紧急业务分配相应的资源后，则向发起服务质量请求的 实体返回资源分配成功消息。
全文摘要
本发明涉及一种网络通信中处理紧急业务的方法。该方法主要包括首先，在紧急业务发起侧将紧急业务标识随紧急业务一起向网络侧发送；之后，当网络侧根据所述紧急业务标识确认收到的业务为紧急业务时，则将优先为该紧急业务分配资源。本发明的实现，使得在具体独立承载控制层实体的网络中可以有效区分出相应的紧急业务，并可以采用专门的资源分配策略为紧急业务进行资源分配，从而可以保证在需要紧急业务时，网络能保证业务的连通性和资源，减少意外和不必要的损失。
文档编号H04L12/56GK101146052SQ20071018149
公开日2008年3月19日 申请日期2005年4月25日 优先权日2005年4月25日
发明者何芸谷 申请人:华为技术有限公司