用于控制访客用户的QOS和/或策略和计费控制的方法和设备与流程

文档序号:11991167阅读:398来源:国知局
用于控制访客用户的QOS和/或策略和计费控制的方法和设备与流程
本发明涉及通信领域并且更具体而言涉及用于控制访客用户的QOS和/或策略和计费控制的方法和设备。

背景技术:
随着OMA规范中定义的应用使能器的出现,移动网络将允许来自第三方应用服务的订户(又被称为访客用户)作为访客用户经由移动网络基础设施注册并且做出语音和/或数据呼叫,但是当前不存在用于访客用户的策略和计费控制(PCC),这需要尽快解决。并且随着第三代合作伙伴计划长期演进(3GPPLTE)移动宽带技术变得成熟,其使得终端用户能够随时随地经由移动手持机方便地访问并且/或者下载应用。在网络运营商与第三方应用提供商之间出现了新的担保(sponsored)数据和计费账户连接商业模型。在该新的商业模型中,第三方应用提供商将拥有用户以及他们的账户,并且终端用户将向第三方应用提供商(例如AppStore提供商)支付服务费,而不是直接向移动运营商支付服务费。第三方应用提供商将与网络运营商进一步利益共享以经由移动运营商的宽带网络保证它的应用的服务质量(QoS)。然而,3GPP架构没有很好地处理网络运营商(例如移动运营商)与第三方应用提供商(例如AppStore)之间新出现的担保商业模型(参见3GPPTS23.203和23.913)。3GPPPCC架构仅为网络运营商提供了用于控制它自己的订户的数据服务连接的技术方案,而没有建议如何对第三方应用提供商所拥有的终端用户进行策略和计费控制,因为第三方终端用户支付与在PCC结构中的订户的在线计费独立的连接。

技术实现要素:
本发明提出了用于控制访客用户的QoS和/或策略和计费控制的方法。本发明提出一种用于将现有PCC架构和在线计费系统(OCS)扩展为动态地控制网络运营商的网络上的第三方应用服务的数据连接的创新的技术方案。其使得网络运营商和第三方应用提供商能够基于终端用户服务使用限制来联合地提供QoS控制服务。根据本发明的第一个方面,提供了一种在通信网络的在线计费系统中辅助控制订阅第三方应用服务的用户的服务质量和/或策略和计费控制的方法,该方法包括:向提供该第三方应用服务的第三方应用提供商发送用户订阅请求,该请求用于从该第三方应用提供商请求用户订阅信息;根据来自该第三方应用提供商的反馈,获得用户订阅响应,该用户订阅响应包括响应于该用户订阅请求的信息;并且向第一模块提供该用户订阅响应。根据本发明的第二个方面,在第一模块中提供了一种用于与通信网络中的在线计费系统交互的方法,包括:确定用户是否订阅了第三方应用服务;如果该用户订阅了第三方应用服务,则向该在线计费系统发送用户配置文件请求,该用户配置文件请求用于请求该在线计费系统提供该用户的用户配置文件信息;并且从该在线计费系统获得用户订阅响应,该用户订阅响应包括响应于该用户订阅请求的信息。根据本发明的第三个方面,提供了一种在通信网络的在线计费系统中辅助控制订阅第三方应用服务的用户的服务质量和/或策略和计费控制的第一设备,该第一设备包括:用于向提供该第三方应用服务的第三方应用提供商发送用户订阅请求的装置,该请求用于从该第三方应用提供商请求用户订阅信息;用于根据来自该第三方应用提供商的反馈获得用户订阅响应的装置,该用户订阅响应包括响应于该用户订阅请求的信息;以及用于向第一模块提供该用户订阅响应的装置。根据本发明的第四个方面,在第一模块中提供了一种用于与通信网络中的在线计费系统交互的第二设备,包括:用于确定用户是否订阅了第三方应用服务的装置;用于向该在线计费系统发送用户配置文件请求的装置,该用户配置文件请求用于如果该用户订阅了第三方应用服务则请求该在线计费系统提供该用户的用户配置文件信息;以及用于从该在线计费系统获得用户订阅响应的装置,该用户订阅响应包括响应于该用户订阅请求的信息。本发明提出一种更加通用的技术方案来增强现有3GPPPCC架构以具有对网络运营商网络上的第三方应用担保数据服务和/或应用的策略和计费控制。此外,本发明与现有3GPP标准计费架构良好地兼容,并且无需用于特殊工作来增强Gx和Gy接口就可以应用本发明。另外,本发明将使得应用层对于网络承载层是透明的,并且网络承载不需要具有用于担保数据服务连接的特殊增强。附图说明通过参考附图来阅读非限制性实施方式的以下描述,本发明的其他特征、方案和优点将变得显而易见。图1显示了用于根据本发明的一个实施方式的第三方应用担保数据连接的实时策略和计费控制的网络架构图;图2示出了用于根据本发明的一个实施方式的第三方应用担保数据连接会话建立过程的呼叫流程。图3示出了用于根据本发明的一个实施方式的第三方应用担保数据连接扩展过程的呼叫流程。图4示出了本发明的一个实施方式的另一个可替换的架构。其中,相同的或相似的附图标记涉及相同的或相似的步骤或装置。具体实施方式现在将结合附图详细给出本发明的实施方式的说明性的描述。图1显示了用于根据本发明的一个实施方式的第三方应用担保数据连接的实时策略和计费控制的网络架构图。在图1中,显示了多个LTE逻辑实体。下面是与本发明相关的逻辑实体的简要描述。SPR表示订户配置文件库(SubscriberProfileRepository)。SPR逻辑实体包含策略和计费规则功能体(PolicyandChargingRuleFunction,PCRF)对于基于订阅的策略和因特网协议连接接入网(IPCAN)承载级PCC规则所需要的所有与订户/订阅相关的信息。SPR可以提供以下订阅配置文件信息:-用户的用户设备(UE)的订户被允许的服务;-对于每个被允许的服务的优先认购(pre-emption)优先级;-关于订户被允许的QoS的信息,包括订阅保证带宽QoS;-与订户的计费相关的信息(例如与计费相关的地址信息);-订户类别。PCRF包括策略控制判决和基于流的计费控制功能。PCRF向策略和计费实施功能体(PolicyAndChargingEnforcementFunction,PCEF)提供网络控制,该网络控制关于服务数据流检测、门控、QoS和基于流的计费(除了信用管理之外)。PCEF包括服务数据流检测、策略实施和基于流的计费控制功能。该功能实体位于网关(例如GPRS情况中的GGSN和WLAN情况中的PDG)。其提供服务数据流检测、用户平面业务处理、触发控制平面会话管理(在IPCAN允许的情况下)、QoS处理和服务数据流测量以及在线和离线计费交互。应用功能体(ApplicationFunction,AF)是用于提供需要对IPCAN用户平面行为的动态策略和/或计费控制的应用的元素。AF应该与PCRF通信,以传递PCRF判决所需要的动态会话信息并且接收IPCAN专用信息和关于IPCAN承载级事件的通知。BBERF表示承载绑定和事件报告功能体(BearerBindingandEventReportingFunction)。BBERF包括以下功能:承载绑定;上行链路承载绑定验证;向PCRF报告事件以及向PCRF发送或从PCRF接收IPCAN专用参数。由图1中的虚线将网络运营商的网络中的网络实体(如AF、SPR、OCS、BBERF和PCEF)与第三方应用提供商的网络中的网络实体(如第三方服务账户管理系统和应用商店)分离。在图1中,在SPR与OCS之间建议了增强型Sy接口(在3GPP标准中接口又被称为参考点)。对于由第三方应用向网络运营商付费的第三方应用担保服务,SPR将进一步查询OCS以验证终端用户的访客状态和担保的有效性;SPR还将查询终端用户的数据使用和额度(allowance),并且向PCRF传递所查询的信息以应用动态QoS控制策略规则。OCS将具有新的接口Sx,以从第三方应用提供商查询终端用户的订阅。OCS将从外部第三方应用提供商预留该计费,并且第三方应用提供商将真实地维护用户的账户结余信息和服务订阅。当OCS检测到它的终端用户对于特定应用的使用超过特定花费限制门限时,它将通知SPR更新QoS策略规则,因而将在PCEF中经由PCRF更新操作实施第三方终端用户的QoS。将结合下文的图2详细解释SPR、OCS的详细增强。图2示出了用于根据本发明的一个实施方式的第三方应用担保数据连接会话建立的呼叫流程。首先,在步骤S201中,UE向PCEF发送IP-CAN请求,以开始IP-CAN建立过程。步骤S201遵循正常过程并且为了简洁起见省略其细节。UE可以是第三方应用提供商担保用户或非担保用户。然后,在步骤S202中,PCEF向PCRF发送IP-CAN会话建立请求,以建立去往PCRF的IP-CAN会话。UE的IP连接可能具有有限数量的数据使用。UE可以例如仅使用有限的带宽资源。然后,在步骤S203中,PCRF向SPR发送用户配置文件请求,以查询订户配置文件信息。然后,在步骤S204中,SPR基于内部策略规则,确定该数据连接是否受第三方应用提供商担保。具体而言,SPR可以从数据库获得或者从SPR的配置本地地获得以下信息:-该用户的用户设备(UE)的设备类型;-该用户的UE的移动MDN/MSIDSN前缀或号码范围;-该用户的UE的IMSI前缀;-该用户的UE的接入点号码(APN);-该用户的UE的接入技术类型;-该用户的UE的服务流标识符;-该用户的UE的服务类型;-该用户的UE的应用类型;-该用户的UE的位置;-该用户的UE的漫游;等等。网络运营商可以例如对于第三方应用提供商分配特定的号码范围作为第三方应用提供商的UE号码。因此,UE的号码范围可用于识别UE是否是第三方应用提供商的订户。如果UE的号码属于分配给第三方应用提供商的特定的号码范围,则确定该UE是第三方应用提供商的订户,反之亦然。在另一个实例中,当确定用户是否是第三方应用提供商的订户时还需要考虑漫游状态。网络可以例如配置内部策略规则,即如果用户处于漫游状态则不允许访问由第三方应用提供商提供的服务以节约网络带宽。因此,当用户处于漫游状态时,SPR可以确定该用户不被允许作为第三方应用提供商的订户。除了以上实例之外,其他特定字段也可以类似地用于识别用户是否是第三方应用提供商的订户。然后,在步骤S205中,SPR将进一步向OCS发送请求,以验证终端用户访客状态和担保数据服务连接。SPR将经由增强的Sy接口发送该请求。对于该终端用户访客状态和担保数据服务连接,SPR查询OCS以获得如下信息,如该用户订阅了哪个第三方应用提供商、该用户订阅了第三方应用提供商的什么种类的服务以及对应于该用户的带宽限额(quota)等等。本领域的熟练技术人员可以理解:SPR可以在OCS中查询第三方应用提供商担保数据连接信息和非担保数据连接信息;然而,后者不在本发明的范围中并且因此为了简洁起见被省略。下文将主要关注用户是第三方应用提供商担保订户的情况。因此,当在步骤S204中SPR确定用户订阅了第三方应用服务之后,然后在步骤S205中SPR向OCS发送用户配置文件请求,该用户配置文件请求用于请求OCS向SPR提供该用户的用户配置文件信息,使得SPR可以验证终端用户的状态和担保数据服务连接。然后,在步骤S206中,OCS将向第三方应用提供商发送用户订阅请求,以得到以下信息:-用户在第三方应用提供商中的订阅数据服务信息;-数据使用/花费额度信息。与SPR和OCS之间的用户配置文件请求可能包括用于非担保服务和担保服务的计费和QoS信息不同,OCS和第三方应用提供商之间的用户订阅请求仅用于担保数据服务。此外,来自OCS的查询基于移动运营商与第三方应用提供商之间的服务协定。然后,在步骤S207中,第三方应用提供商将向OCS确认该信息,即,第三方应用提供商向OCS发送反馈。具体而言,从第三方应用提供商发送的反馈可以包括用户在第三方应用提供商中的订阅数据服务信息,以及数据使用/花费额度信息,例如允许用户使用由第三方应用提供商以特定的QoS提供的服务的时长或带宽。然后,在步骤S208中,OCS在OCS中代表第三方应用提供商存储用户账户数据和第三方应用提供商担保服务信息。然后,在步骤S209中,在由OCS验证了服务之后,将经由Sy接口向SPR返回用户订阅响应。该用户订阅响应包括担保服务类型、最大允许数据额度、担保数据使用量和/或已用计数值。基于已用计数值,SPR可以动态地确定用于担保数据服务的新的QoS。然后,在步骤S210中,SPR将内部地存储第三方应用担保数据服务信息。然后,在步骤S211中,SPR也将向PCRF确认该用户配置文件请求,即,SPR向PCRF发送用户配置文件响应,并且该用户配置文件请求包括担保服务数据信息。由SPR向PCRF发送的用户配置文件响应与由OCS向SPR发送的用户配置文件响应相同。由SPR向PCRF发送的用户配置文件响应的内容与由OCS向SPR发送的用户配置文件响应不同。然后,在步骤S212中,PCRF将具有策略规则推导。PCRF根据用户配置文件请求中所包括的已用计数值来确定第三方应用提供商担保数据服务信息的网络QoS信息。然后,在步骤S213中,PCRF将确认IP-CAN会话建立,并且指示PCEF安装该策略规则。然后,在步骤S214中,PCEF安装从PCRF推导出的该策略规则。然后,在步骤S215中,PCEF向OCS发送计费请求以向第三方应用担保数据服务应用使用量/信用控制。然后,在步骤S216中,OCS向PCEF返回已允许数据使用量,并且OCS还将监视第三方应用担保数据服务的数据服务使用量。然后,在步骤S217中,PCEF确认UEIP-CAN建立,并且UE成功地附接到移动数据网络。然后,在步骤S218中,UE将成功地连接到由第三方应用提供商提供的应用商店。图3示出了用于根据本发明的另一个实施方式的第三方应用担保数据连接扩展过程的呼叫流程。图3显示了在第三方应用管理和使用控制系统(简称第三方应用提供商)、SPR与PCRF之间的用户数据交换的示例性呼叫流程。因此PCRF可以良好地管理关于由第三方应用提供商授予的时长和/或数量的信息。首先,在步骤S301中,PCEF向OCS报告数据服务报告,该数据服务报告指示由用户使用的第三方应用服务的当前数据服务使用量。PCEF还应用新限额。然后,在步骤S302中,在OCS从PCEF接收数据服务报告之后,OCS根据第一预定门限,确定该已允许数据使用量是否被用尽。OCS可以从第三方应用提供商中的响应或者从OCS针对第三方应用服务所本地地维护的门限值,获得该第一预定门限。如果OCS确定已允许数据使用量被用户用尽,则OCS向第三方应用提供商发送请求以得到更多数据额度。否则,如果OCS确定已允许数据使用量未被用户用尽,则OCS优选地将不向第三方应用提供商发送信令。然后,在步骤S303中,第三方应用提供商针对该订户将总剩余额度授予OCS。如果第三方应用提供商可以授予更多数据额度,则该方法可以进入步骤S304,在步骤S304中OCS向PCEF确认数据服务访问,并且连续地监视服务数据连接。当然,如果第三方应用提供商可以授予更多数据额度,则该方法可以进入或不进入步骤S305,也就是说,可以改变或不改变QoS策略,因为存在多个门限并且不同门限具有不同QoS的情况。这依赖于具体的QoS策略。OCS可以例如设置标准,即当订阅了第三方应用服务的订户仅剩5M带宽时改变QoS策略,例如降低该订户的优先级,例如调整订户的以下项中的至少一个:需要的比特率、延迟、抖动、分组丢弃概率或误比特率。然后,在步骤S305中,OCS检测是否达到使用花费限制;如果OCS检测到达到使用花费限制,即第三方应用提供商不能再向用户授予更多额度,则应该应用新的计费策略。然后,OCS触发到SPR的Sy接口,以更新服务使用和额度信息。然后,在步骤S306中,SPR向OCS确认Sy请求。然后,在步骤S307中,SPR将经由Sp接口进一步更新PCRF中的信息。该信息包括该用户被允许使用的第三方应用服务的使用量和/或花费和额度限制。然后,在步骤S308中,PCRF将向SPR确认Sp请求。然后,在步骤S309中,PCRF将基于新的数据信息,推导出新的QoS策略控制规则。然后,在步骤S310中,PCRF将向PCEF更新新的策略规则。然后,在步骤S311中,PCEF将向PCRF确认该更新请求。然后,在步骤S312中,PCEF将进一步向UE发送请求以更新IP-CAN会话连接。然后,在步骤S313中,PCEF将向PCEF确认UEIP-CAN更新请求。然后,在步骤S314中,UE以新的QoS信息连接到移动网络,即UE以已更新的QoS策略连接到第三方应用服务。图4示出了本发明的实施方式的另一个可替换的架构。在该情况中,SPR被集成到OCS计费系统中。除了由3GPP标准定义的现有OCS功能之外,OCS还代表第三方应用维护第三方用户的订阅信息并且监视第三方应用担保数据服务的网络使用量,即以上实施方式中所述的SPR的功能被集成到OCS中。参考图4,在PCRF与OCS之间(代替如图1中所示的在SPR与OCS之间)直接建议增强的Sp参考点。对于第三方应用担保服务,PCRF将进一步查询OCS,以验证终端用户的访客状态和担保的有效性;PCRF还将查询终端用户的数据使用量和额度,以应用动态QoS控制策略规则。至于OCS,OCS将具有新的Sx接口以从第三方应用提供商查询终端用户的订阅。第三方应用提供商维护服务订阅和用户账户结余。OCS从外部的第三方应用提供商预留该计费。当OCS接收到授予的信用时,OCS将在高速缓冲存储器或临时账户中维持第三方终端用户的服务订阅和结余信息。当OCS检测到它的终端用户对于特定应用的使用量超过特定花费限制门限时,它将通知PCRF更新QoS策略规则,因而将经由PCRF更新操作在PCEF中实施第三方终端用户的QoS。以上情况中的呼叫流程类似于图2和3中所示,但是在SPR与OCS之间不存在Sy接口。由于SPR被集成在OCS中,所以在SPR与OCS之间不存在明确的接口交互。PCRF将利用Sp接口与OCS直接交互。具体而言,OCS和SPR集成的该实施方式的第三方应用担保数据连接会话建立过程的流程图与图2中所示的类似,差异仅在于与后者相比前者省略了步骤S205和S209并且由SPR或OCS而不是SPR实现步骤S204和S210,在步骤S203中的配置文件请求的接收方是OCS而不是SPR,并且步骤S211的配置文件响应的发送方是OCS而不是SPR。但是在该实施方式中,PCRF可以具有它自己的本地配置,如设备类型、移动MDN/MSIDSN等等,以用于确定用户是否订阅了第三方应用服务。此外,OCS和SPR集成的实施方式的第三方应用担保数据连接扩展过程的流程图与图3中所示的类似,差异仅在于与后者相比前者省略了步骤S305和S306,在步骤S308中的确认的接收方是OCS而不是SPR,并且已更新的使用量/花费和额度限制的发送方是OCS而不是SPR。上文已经描述了本发明的实施方式。本领域的熟练技术人员可以理解本发明不限于具体的系统、设备或协议,并且在不脱离所附权利要求的范围和精神的前提下可以做出各种改进或修改。本领域的熟练技术人员可以理解上述实施方式仅用于说明的目的并且不被解释为作为本发明的限制。本发明不限于这些实施方式。意图将不脱离本发明的精神的所有技术方案都包括在所附权利要求的范围中。此外,在权利要求中,不应该将括号中包括的任何附图标记解释为限制该权利要求。词语“包括”不排除权利要求中或说明书中未罗列的元素或步骤。元素前面的词语“一”或“一个”不排除多个该元素的出现。在包括多个装置的设备中,可以由一个硬件或软件模块实现多个装置的一个或多个功能;词语“第一”、“第二”和“第三”仅表示名称并且不意味着具体的次序。
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1