首页> 中国专利> 实现自营业务QoS保障的方法、系统与PCRF设备

实现自营业务QoS保障的方法、系统与PCRF设备

摘要

本公开涉及一种实现自营业务QoS保障的方法、系统与PCRF设备。该方法包括通过开放网关接收自营业务发起的业务保障申请,保障申请中包含业务ID、业务类型和终端用户号码;利用业务ID到用户签约数据库中查询业务ID是否具有业务保障权限;如具有业务保障权限,则将业务类型与存储在用户签约数据库中的业务类型与保障等级的映射关系相匹配,以匹配出与业务类型相对应的保障等级;接收用户签约数据库返回的与保障等级相对应的QoS特征值;将QoS特征值下发到策略和计费执行功能设备,以使策略和计费执行功能设备根据接收的QoS特征值修改相应IP流的QoS。本公开可以为自营业务提供QoS保障。

著录项

  • 公开/公告号CN104168254A

    专利类型发明专利

  • 公开/公告日2014-11-26

    原文格式PDF

  • 申请/专利权人 中国电信股份有限公司;

    申请/专利号CN201310185994.4

  • 发明设计人 粟霄;

    申请日2013-05-20

  • 分类号H04L29/06(20060101);

  • 代理机构中国国际贸易促进委员会专利商标事务所;

  • 代理人张殿慧

  • 地址 100033 北京市西城区金融大街31号

  • 入库时间 2023-12-17 01:59:14

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2017-07-21

    授权

    授权

  • 2014-12-24

    实质审查的生效 IPC(主分类):H04L29/06 申请日:20130520

    实质审查的生效

  • 2014-11-26

    公开

    公开

说明书

技术领域

本公开涉及智能管道领域,特别地,涉及一种实现自营业务QoS (Quality of Service,服务质量)保障的方法、系统与PCRF(Policy and  Charging Rule Function,策略与计费规则功能)设备。

背景技术

移动互联网时代的到来,运营商既要面对支撑丰富终端/业务的高 负荷压力的网络建设和维护责任,同时又要应对增量不增收的运营压力, 运营商的运营能力遭遇前所未有的挑战。

如果运营商不对管道进行精细化管理,则三家运营商提供给用户的 都是“盲管道”,无法区分用户当前使用何种业务,并且无法对特定业务 提供QoS保障。因此无法让优质用户优先使用优质业务,故而网络效率 低,用户体验差。

为避免管道同质化、网络效率低、用户体验差、用户黏度低等多种 不利因素带来的影响,运营商进行精细化和差异化的智能网络运营已经 成为共同的战略选择,并且亟待解决。

发明内容

本公开鉴于以上问题中的至少一个提出了新的技术方案。

本公开在其一个方面提供了一种实现自营业务QoS保障的方法, 其可以为自营业务提供QoS保障。

本公开在其另一方面提供了一种PCRF设备,其可以为自营业务 提供QoS保障。

本公开在其又一方面提供了一种实现自营业务QoS保障的系统, 其可以为自营业务提供QoS保障。

根据本公开,提供一种实现自营业务QoS保障的方法,包括:

通过开放网关接收自营业务发起的业务保障申请,保障申请中包含 业务ID、业务类型和终端用户号码;

利用业务ID到用户签约数据库中查询业务ID是否具有业务保障权 限;

如具有业务保障权限,则将业务类型与存储在用户签约数据库中的 业务类型与保障等级的映射关系相匹配,以匹配出与业务类型相对应的 保障等级;

接收用户签约数据库返回的与保障等级相对应的QoS特征值;

将QoS特征值下发到策略和计费执行功能设备,以使策略和计费执 行功能设备根据接收的QoS特征值修改相应IP流的QoS。

在本公开的一些实施例中,该方法还包括:

预先在用户签约数据库中存储业务类型与保障等级的映射关系。

在本公开的一些实施例中,自营业务包括音频类业务、视频类业务、 数据类业务、应用类业务、控制类业务、文本类业务和消息类业务。

在本公开的一些实施例中,QoS特征值包括为业务类型分配的上下 行带宽、分配的时长、以及遇到网络阻塞时对无线信道使用的优先级。

在本公开的一些实施例中,该方法还包括:

策略和计费执行功能设备查询使用自营业务的用户原来的QoS签 约信息;

将接收的QoS特征值与用户原来的QoS签约信息进行比较;

如果接收的QoS特征值对应的优先级高于用户原来的QoS签约信息 对应的优先级,则基于接收的QoS特征值改变使用自营业务的用户的 QoS信息。

根据本公开,还提供了一种策略与计费规则功能设备,包括:

保障申请接收单元,用于通过开放网关接收自营业务发起的业务保 障申请,保障申请中包含业务ID、业务类型和终端用户号码;

保障权限查询单元,用于利用业务ID到用户签约数据库中查询业 务ID是否具有业务保障权限;

保障等级匹配单元,用于如具有业务保障权限,则将业务类型与存 储在用户签约数据库中的业务类型与保障等级的映射关系相匹配,以匹 配出与业务类型相对应的保障等级;

QoS特征值接收单元,用于接收用户签约数据库返回的与保障等级 相对应的QoS特征值;

QoS下发单元,用于将QoS特征值下发到策略和计费执行功能设备, 以使策略和计费执行功能设备根据接收的QoS特征值修改相应IP流的 QoS。

在本公开的一些实施例中,自营业务包括音频类业务、视频类业务、 数据类业务、应用类业务、控制类业务、文本类业务和消息类业务。

在本公开的一些实施例中,QoS特征值包括为业务类型分配的上下 行带宽、分配的时长、以及遇到网络阻塞时对无线信道使用的优先级。

根据本公开,还提出了一种实现自营业务QoS保障的系统,包括用 户签约数据库、策略和计费执行功能设备和前述实施例中的策略与计费 规则功能设备。

在本公开的一些实施例中,策略和计费执行功能设备用于根据接收 的QoS特征值修改相应IP流的QoS。

在本公开的一些实施例中,策略和计费执行功能设备包括:

签约信息查询单元,用于查询使用自营业务的用户原来的QoS签约 信息;

优先级比较单元,用于将接收的QoS特征值与用户原来的QoS签 约信息进行比较;

QoS信息修改单元,用于如果接收的QoS特征值对应的优先级高于 用户原来的QoS签约信息对应的优先级,则基于接收的QoS特征值改变 使用自营业务的用户的QoS信息。

在本公开的技术方案中,由于预先将业务类型与保障等级的映射 关系配置在用户签约数据库中,因此,在收到自营业务发起的业务保 障申请时,在判断具有保障权限的情况下,根据存储的映射关系查找 与用户所使用自营业务对应的保障等级,并将与该保障等级对应的 QoS特征值发送到策略和计费执行功能设备,以使策略和计费执行功 能设备将该QoS策略应用到相应的IP流中,进而可以为用户所使用 的自营业务提供相应的QoS保障。

附图说明

此处所说明的附图用来提供对本公开的进一步理解,构成本申请的 一部分。在附图中:

图1是本公开一个实施例的实现自营业务QoS保障的方法的流程示 意图。

图2是本公开另一实施例的实现自营业务QoS保障的方法的消息流 程示意图。

图3是本公开又一实施例的实现自营业务QoS保障的方法的流程示 意图。

图4是本公开一个实施例的策略与计费规则功能设备的结构示意图。

图5是本公开一个实施例的实现自营业务QoS保障的系统的结构示 意图。

图6是本公开另一实施例的实现自营业务QoS保障的系统的结构示 意图。

具体实施方式

下面将参照附图描述本公开。要注意的是,以下的描述在本质上 仅是解释性和示例性的,决不作为对本公开及其应用或使用的任何限 制。除非另外特别说明,否则,在实施例中阐述的部件和步骤的相对 布置以及数字表达式和数值并不限制本公开的范围。另外,本领域技 术人员已知的技术、方法和装置可能不被详细讨论,但在适当的情况 下意在成为说明书的一部分。

本公开下述实施例提出了一种通过预置业务保障等级、配合最简 化的开放接口设计来调度PCRF策略的控制能力,快速实现了自营业 务的QoS保障。

图1是本公开一个实施例的实现自营业务QoS保障的方法的流程示 意图。

其中,自营业务可以包括但不限于音频类业务、视频类业务、数据 类业务、应用类业务、控制类业务、文本类业务和消息类业务。

如图1所示,该实施例可以包括以下步骤:

S102,通过开放网关接收自营业务发起的业务保障申请,保障申请 中包含业务ID、业务类型和终端用户号码;

例如,某个用户在使用某些自营业务时,如果用户想提高下载速度, 则通过互联网向自营业务提供者发起申请,此时,自营业务提供者通过 开放网关将业务保障申请提交至PCRF。

S104,PCRF利用业务保障请求中携带的业务ID到用户签约数据 库中查询该业务ID是否具有业务保障权限。

S106,如果该业务ID具有业务保障权限,即可以为该业务ID提供 业务保障,则将业务保障申请中携带的业务类型与存储在用户签约数据 库中的业务类型与保障等级的映射关系相匹配,以匹配出与业务保障申 请中携带的业务类型相对应的保障等级,在匹配出保障等级后,查找出 与该保障等级对应的QoS特征值。

S108,接收用户签约数据库返回的与保障等级相对应的QoS特征 值;

具体地,QoS特征值可以包括但不限于为业务类型分配的上下行带 宽、分配的时长、以及遇到网络阻塞时对无线信道使用的优先级。

S110,将QoS特征值下发到策略和计费执行功能设备,以使策略和 计费执行功能设备根据接收的QoS特征值修改相应IP流的QoS。

在该实施例中,由于预先将业务类型与保障等级的映射关系配置 在用户签约数据库中,因此,在收到自营业务发起的业务保障申请时, 在判断具有保障权限的情况下,根据存储的映射关系查找与用户所使 用自营业务对应的保障等级,并将与该保障等级对应的QoS特征值发 送到策略和计费执行功能设备,以使策略和计费执行功能设备将该 QoS策略应用到相应的IP流中,进而可以为用户所使用的自营业务提 供相应的QoS保障。

进一步地,在步骤S110中,策略和计费执行功能设备查询使用自 营业务的用户原来的QoS签约信息;

将接收的QoS特征值与用户原来的QoS签约信息进行比较;

如果接收的QoS特征值对应的优先级高于用户原来的QoS签约信 息对应的优先级,则基于接收的QoS特征值改变使用自营业务的用户的 QoS信息。

此外,还需预先在用户签约数据库中存储业务类型与保障等级的映 射关系,以使PCRF可以根据该映射关系查找出与业务保障申请中携带 的业务类型相对应的保障等级。

图2是本公开另一实施例的实现自营业务QoS保障的方法的消息流 程示意图。

如图2所示,可以包括以下过程:

(1)参见图2中的①,根据业务类型进行QoS级别的预设:

依据业务类型,预先将业务保障等级配置在SPR(Subscription  Profile Repository,用户签约数据库)中,进行业务类型与保障等级的映 射,具体地,保障等级可以依据运营商策略而定,通常为金、银、铜用 户,每个级别的用户又可以进一步细分,例如,一般可以定为8级,以 供进一步扩展。

(2)参见图2中的②,自营业务发起QoS保障请求:

最简化的开放接口设计:

自营业务提供的信息可以包括但不限于:业务ID、业务类型与终端 用户MDN(Mobile Directory Number,用户号码)。举例说明,例如, 业务类型为视频类的应用,某个运营商可能会有多个视频应用,于是每 个应用都有自己的ID,用于进行多个应用的区分。

(3)参见图2中的③-⑤,保障等级的查询和执行:

PCRF首先通过业务ID查询该业务是否具有保障权限,如有保障权 限,则再利用SPR中存储的映射关系查询与保障请求中携带的业务类型 对应的保障等级,根据保障等级执行对应的控制策略,例如,上下行带 宽保障与保障时限等,为终端用户提供对应资源。其中,保障时限可以 例如为1分钟、1小时或1天等,是用户选择或应用规定的。

进一步地,除实现自营业务的业务保障申请之外,还可以通过部署 的开放网关时限业务保障的修改、门控与撤销等业务。其中,门控可以 是只允许上行或下行流量,撤销是指停止业务保障,修改是指修改当前 业务保障的参数。

图3是本公开又一实施例的实现自营业务QoS保障的方法的流程示 意图。

如图3所示,该实施例可以包括以下步骤:

前提:在PCRF使用的用户数据库SPR中进行配置,按照不同业 务类型区分不同保障等级。

当自营业务需要申请临时业务保障时,自营业务会通过开放网关向 PCRF发起申请请求。具体地:

S302,自营业务向开放网关发送一个业务保障请求,该请求中包括 了应用ID、用户标识MDN与业务类型。

S304,开放网关进行协议适配,将业务保障请求封装为AAR (Authorize and Authenticate Request,认证鉴权请求)消息,并发送给 PCRF。

S306,PCRF向开放网关发送响应AAA(Authorize and Authenticate  Answer,认证鉴权应答)。

S308,PCRF根据应用ID查询SPR该应用ID是否具有业务保障 权限,如有业务保障权限,则SPR再根据业务类型匹配出与业务类型对 应的业务保障级别。

S310,SPR将匹配出的与业务保障级别对应的QoS特征值返回给 PCRF,其中,QoS特征值可以包括但不限于对这个业务分配的上下行带 宽、分配的时长、遇到网络阻塞时对无线信道使用的优先级等。

S312,PCRF向PCEF(Policy and Charging Enforcement Function, 策略和计费执行功能)下发QoS策略,即,QoS特征值。

S314,PCEF针对请求检查签约信息,识别相关的IP流,修改其 QoS,进行QoS授权,并向PCRF反馈QoS策略执行信息。

具体地,PCEF可以根据用户的MDN从AAA查到使用自营业务的 用户原来的QoS签约信息,将接收的QoS特征值与QoS签约信息进行 比较,判断两者优先级的高低,如果接收的QoS特征值对应的优先级较 高,则利用用户的MDN识别出用户的IP流(此功能为PCEF的自有功 能),改变该IP流中用户的QoS信息(例如,调整优先级等),让用户 享有高的QoS保障(即,QoS授权),如果QoS签约信息对应的优先级 较高,则不对用户IP流中的QoS信息进行更改。

S316,PCRF向开放网关返回RAR(Re-Authentication Request, 重认证请求)消息,通知用户QoS修改已成功。

S318,开放网关向自营业务返回业务申请应答。

其中,业务保障申请的开放接口示例如下表所示:

表1

自营业务可以属于其中的任何一类型。运营商可以根据自己需要决 定与每一类型对应的保障级别。

本领域普通技术人员可以理解,实现上述方法实施例的全部和部分 步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计 算设备可读取存储介质中,该程序在执行时,执行包括上述方法实施例 的步骤,而前述的存储介质可以包括ROM、RAM、磁碟和光盘等各种 可以存储程序代码的介质。

图4是本公开一个实施例的策略与计费规则功能设备的结构示意图。

如图4所示,该实施例中的设备40可以包括保障申请接收单元402、 保障权限查询单元404、保障等级匹配单元406、QoS特征值接收单元408 和QoS下发单元410。其中,

保障申请接收单元402,用于通过开放网关接收自营业务发起的业 务保障申请,保障申请中包含业务ID、业务类型和终端用户号码;

保障权限查询单元404,用于利用业务ID到用户签约数据库中查询 业务ID是否具有业务保障权限;

保障等级匹配单元406,用于如具有业务保障权限,则将业务类型 与存储在用户签约数据库中的业务类型与保障等级的映射关系相匹配, 以匹配出与业务类型相对应的保障等级;

QoS特征值接收单元408,用于接收用户签约数据库返回的与保障 等级相对应的QoS特征值;

QoS下发单元410,用于将QoS特征值下发到策略和计费执行功能 设备,以使策略和计费执行功能设备根据接收的QoS特征值修改相应IP 流的QoS。

在该实施例中,由于预先将业务类型与保障等级的映射关系配置 在用户签约数据库中,因此,在收到自营业务发起的业务保障申请时, 在判断具有保障权限的情况下,根据存储的映射关系查找与用户所使 用自营业务对应的保障等级,并将与该保障等级对应的QoS特征值发 送到策略和计费执行功能设备,以使策略和计费执行功能设备将该 QoS策略应用到相应的IP流中,进而可以为用户所使用的自营业务提 供相应的QoS保障。

其中,自营业务可以包括但不限于音频类业务、视频类业务、数据 类业务、应用类业务、控制类业务、文本类业务和消息类业务。

进一步地,QoS特征值可以包括但不限于为业务类型分配的上下行 带宽、分配的时长、以及遇到网络阻塞时对无线信道使用的优先级。

图5是本公开一个实施例的实现自营业务QoS保障的系统的结构示 意图。

如图5所示,该实施例中的系统50可以包括SPR502、PCEF504 和PCRF506。其中,PCRF506可以通过前述实施例实现。

进一步地,策略和计费执行功能设备用于根据接收的QoS特征值修 改相应IP流的QoS。

图6是本公开另一实施例的实现自营业务QoS保障的系统的结构示 意图。

如图6所示,与图5中的实施例相比,该实施例中的策略和计费执 行功能设备602可以包括签约信息查询单元602a、优先级比较单元602b 和QoS信息修改单元602c。其中,

签约信息查询单元602a,用于查询使用自营业务的用户原来的QoS 签约信息;

优先级比较单元602b,用于将接收的QoS特征值与用户原来的QoS 签约信息进行比较;

QoS信息修改单元602c,用于如果接收的QoS特征值对应的优先级 高于用户原来的QoS签约信息对应的优先级,则基于接收的QoS特征值 改变使用自营业务的用户的QoS信息。

本说明书中各个实施例均采用递进的方式描述,每个实施例重点说 明的都是与其他实施例的不同之处,各个实施例之间相同和相似的部分 可以相互参见。对于装置实施例而言,由于其与方法实施例基本相似, 所以描述的比较简单,相关之处可以参见方法实施例部分的说明。

本公开上述实施例与现有技术相比具有以下优点:

(1)3GPP TS29.199-17:业务保障请求的QoS信息可以实时提供, 开放接口参数复杂;本公开中的业务保障等级需预先配置,一旦该业务 被用户调用,则自营业务直接通过应用ID发起QoS保障请求,PCRF 再根据应用ID查询出具体的QoS等级和具体保障需求。

(2)3GPP TS29.199-17:通过IP五元组识别用户,存在NAT穿越 问题,具体地,由于IP地址紧张,某些运营商在网络上增加NAT设备, 分配给终端的是内网IP,而应用从终端拿到的是经过NAT设备后的外 网IP地址,因此网络无法匹配寻找到终端,此问题目前在3GPP讨论, 尚无统一解决方案;而本公开则可以利用自营业务的特点(可获取MDN 号),提出通过MDN实现用户绑定,避免NAT穿越问题。,具体地, 自营业务一般都要求用户填入手机号作为账号,所以可以获得用户的 MDN。

虽然已参照示例性实施例描述了本公开,但应理解,本公开不限 于上述的示例性实施例。对于本领域技术人员显然的是,可以在不背 离本公开的范围和精神的条件下修改上述的示例性实施例。所附的权 利要求的范围应被赋予最宽的解释,以包含所有这样的修改以及等同 的结构和功能。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号