CN103037449A - 一种更新服务质量的方法及系统 - Google Patents
一种更新服务质量的方法及系统 Download PDFInfo
- Publication number
- CN103037449A CN103037449A CN2011103048776A CN201110304877A CN103037449A CN 103037449 A CN103037449 A CN 103037449A CN 2011103048776 A CN2011103048776 A CN 2011103048776A CN 201110304877 A CN201110304877 A CN 201110304877A CN 103037449 A CN103037449 A CN 103037449A
- Authority
- CN
- China
- Prior art keywords
- qos
- pgw
- message
- request
- sends
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
Abstract
本发明公开了一种更新服务质量的方法和系统，能够保证用户使用和运营商没有合作关系的第三方应用提供商的业务时，能根据用户要求来提供业务服务质量。所述方法包括：在业务过程中，终端(UE)将更新服务质量(QoS)请求或QoS确认指示发送给PGW；所述PGW接收到所述更新QoS请求或QoS确认指示后，发起IP连接接入网(IP-CAN)会话修改流程，更新QoS。采用本发明实施例方法，通过让用户先感受提高的QoS再决策是否接受该QoS，从而实现根据用户的要求来提供业务服务质量。
Description
技术领域
本发明涉及无线通信系统中策略和计费控制技术，尤其涉及一种演进的分组系统(EPS，Evolved Packet System)中更新服务质量(QoS，Quality ofService)的方法及系统。
背景技术
图1为3GPP演进分组系统结构示意图，如图1所示，3GPP演进分组系统(EPS，Evolved Packet System)由演进的通用移动通信系统陆地无线接入网(E-UTRAN，Evolved Universal Terrestrial Radio Access Network)、移动管理单元(MME，Mobility Management Entity)、服务网关(S-GW，ServingGateway)、分组数据网络网关(PDN GW或P-GW，Packet Data NetworkGateway)、归属用户服务器(HSS，Home Subscriber Server)、3GPP的认证授权计费(AAA，Authentication、Authorization and Accounting)服务器、策略和计费规则功能实体(PCRF，Policy and Charging Rules Function)及其它支撑节点组成。
其中，MME用于移动性管理、非接入层信令的处理和用户移动管理上下文的管理等控制面相关工作；S-GW是与E-UTRAN相连的接入网关设备，在E-UTRAN与P-GW之间转发数据，并且用于对寻呼等待数据进行缓存；P-GW则是EPS与PDN的边界网关，用于PDN的接入及在EPS与PDN间转发数据等功能。
EPS支持与非3GPP系统的互通。与非3GPP系统的互通通过S2a、S2b、S2c接口实现，P-GW作为3GPP系统与非3GPP系统之间的锚点。其中，非3GPP系统被分为可信任非3GPP接入系统和不可信任非3GPP接入系统。可信任非3GPP接入系统可以直接通过S2a接口与P-GW连接；不可信任非3GPP接入系统需经过演进的分组数据网关(ePDG，Evolved Packet DataGateway)与P-GW相连，ePDG与P-GW之间为S2b接口。S2c接口提供了用户设备(UE，User Equipment)与P-GW之间用户面相关的控制和移动性支持，支持的移动性管理协议为支持双栈的移动IPv6(DSMIPv6，Moblie IPv6support for dual stack Hosts and Routers)。
EPS系统引入策略计费控制(PCC，Policy and Charging Control)功能框架对用户的业务访问进行动态的策略计费控制。图2为Rel-8中非漫游场景下的PCC结构示意图，如图2所示，应用功能实体(AF，Application Function)用于提供业务应用的接入点，这些业务应用所使用的网络资源需要进行动态的策略控制。在业务面进行参数协商时，AF将相关业务信息传递给PCRF。如果这些业务信息与PCRF的策略相一致，则PCRF接受该协商；否则，PCRF拒绝该协商，并在反馈时给出PCRF可接受的业务参数。随后，AF可将这些参数返回给用户设备(UE，User Equipment)。其中，AF和PCRF之间的接口是Rx接口。
PCRF是PCC的核心，负责策略决策和计费规则的制定。PCRF提供了基于业务数据流的网络控制规则，这些网络控制包括业务数据流的检测、门控(Gating Control)、服务质量(QoS，Quality of Service)控制以及基于数据流的计费规则等。PCRF将其制定的策略和计费规则发送给策略和计费执行功能实体(PCEF，Policy and Control Enforcement Function)执行；同时，PCRF还需要保证这些规则和用户的签约信息一致。PCRF制定策略和计费规则的依据包括：从AF获取与业务相关的信息、从用户签约数据库(SPR，Subscription Profile Repository)获取与用户策略计费控制相关的签约信息、通过Gx接口从PCEF获取的与承载相关网络的信息。
PCEF通常位于网关(GW，Gate-Way)内，在承载面执行PCRF所制定的策略和计费规则。PCEF按照PCRF所发送的规则中的业务数据流过滤器对业务数据流进行检测，进而对这些业务数据流执行PCRF所制定的策略和计费规则。在承载建立时，PCEF按照PCRF发送的规则进行QoS授权，并根据AF的执行进行门控控制。同时，PCEF根据PCRF订阅的事件触发上报承载网络上发生的事件。根据PCRF发送的计费规则，PCEF执行相应的业务数据流计费操作，计费既可以是在线计费，也可以是离线计费。如果是在线计费，则PCEF需要和在线计费系统(OCS，Online Charging System)一起进行信用管理。离线计费时，PCEF和离线计费系统(OFCS，Offline ChargingSystem)之间交换相关的计费信息。PCEF与PCRF之间的接口是Gx接口，与OCS之间的接口是Gy接口，与OFCS之间的接口是Gz接口。PCEF一般都位于网络的网关上，如EPS的分组数据网络网关(PDN-GW)、通用无线分组业务(GPRS，General Packet Radio Service，)中的GPRS网关支持节点(GGSN)以及互联无线网局域网(I-WLAN，Interworking WLAN)中的分组数据网关(PDG，Packet Data Gateway)。
承载绑定和事件报告功能实体(BBERF，Bearer Binding and EventReporting Function)通常位于接入网网关(Access Network Gateway)内。如当用户设备通过E-UTRAN接入EPS、服务网关S-GW与P-GW之间采用代理移动互联网协议版本6(PMIPv6，Proxy Mobile Internet Protocol version 6)协议时，S-GW中就存在BBERF。当用户设备通过可信任非3GPP接入网接入时，可信任非3GPP接入网关中也存在BBERF。
SPR存储了与策略控制和计费相关的用户策略计费控制签约信息。SPR和PCRF之间的接口是Sp接口。
在线计费系统(OCS，Online Charging System)和PCEF一起进行在线计费方式下用户信用的控制和管理。
离线计费系统(OFCS，Offline Charging System)与PCEF一起完成离线计费方式下的计费操作。
以上PCC架构通过各功能实体实现了对UE为访问一个分组数据网络(Packet Data Network，简称为PDN)所建立的IP连接接入网(IP ConnectivityAccess Network，简称为IP-CAN)会话的策略计费控制。一个IP-CAN会话的策略计费控制信息只由一个PCRF决定。
现有技术中，UE建立到某个PDN的IP-CAN会话后，网络按相应授权的QoS为其业务提供数据传输需要的网络资源，业务过程中可根据需要更改其QoS。对于IMS类业务，则AF将提供新的QoS信息给PCRF，PCRF发起IP-CAN会话的修改流程。PCRF结合AF新请求的QoS以及SPR/UDC相应签约数据，底层网络承载资源信息等重新授权并下发新的PCC/QoS规则给PCEF/BBERF，PCEF/BBERF更新相应规则并修改承载资源，为该业务提供新的QoS。对于非IMS类业务，运营商可以根据自身需求来部署网络，自定义非IMS类业务平台和数据中心，通过自定义接口来触发其PCRF发起IP-CAN会话修改流程来更改QoS。若该类业务不是运营商自有的业务平台提供，则运营商可以和该类业务提供商签订私有协议，来通过自定义接口触发其PCRF发起IP-CAN会话修改流程来更改QoS。
同时目前移动运营商需要为不同的设备提供日益增长的各种业务处理，这些业务可能来自于运营商自有的数据中心，也可能为运营商domain之外的第三方数据应用提供商(如图3)。图3为存在第三方应用业务提供商的PCC架构，该应用提供商与PCRF之间通过Rx接口互通，如果该业务提供商与运营商没有合作协议则该接口只传送必要的业务和数据流信息。因此目前运营商单独与第三方数据应用提供商达成私有协议来支持私有功能和non-3GPP接口的方式带来运营商网络的频繁升级及复杂混乱的策略管理机制。因此，实现移动运营商为不同的数据应用提供商互通使用统一的3GPP接口，支持这类interworking scenarios在认证、授权、策略、计费、移动性和会话连续性等方面的功能成为当前必要解决的问题。
图4为存在第三方应用提供商的漫游归属地路由PCC结构示意图，图中HPLMN为归属地PLMN(Public Land Mobile Network，公共陆地移动网络)，VPLMN为拜访地PLMN。
如图5所示，为当前解决移动运营商和第三方应用提供商的interworking的一种引入通用引导架构(Generic Bootstrapping Architecture，简称为GBA)方案；除了图1和2中的EPS网络以及PCC架构，引入了GBA作为移动运营商对第三方应用提供商的鉴权和认证，来为UE提供相关应用业务。图中引导服务功能(Bootstrapping Server Function，简称为BSF)为运用商的网内的功能实体，GBA所有的用户安全设置(GUSS)都存储在HSS中，BSF通过与HSS之间的接口(Zh)获得用户安全信息和认证信息。UE和BSF之间通过认证机制在BSF和UE之间产生一个会话密钥(Ks)，网络应用功能(NetApplication Function，简称为NAF)负责业务控制，能从BSF获得该会话密钥，通过这种方式，NAF和UE就能拥有一个共享密钥，该共享密钥能为随后的应用提供安全保护，特别是在应用会话开始时认证UE和NAF。因此运营商可以完成相关鉴权和认证，为签约用户提供第三方应用业务。但第三方应用提供商与运营商的策略协商与资源管理尚没有完善的解决方案。
如图6所示，为当前解决移动运营商和第三方应用提供商的interworking的另一种引入GBA和OpenID架构的方案；Open ID是实现全网统一认证的解决方案：当终端用户UE登录一个支持Open ID的网站，即依赖方(RelyingParty，简称为RP)时，与在该网站进行用户登录方式不同(该终端用户也许没有在该网站注册过)，该用户选择了以Open ID的方式登录该网站。OpenID是该用户在另一个网站，即账号提供方(OpenID Provider，简称为OP)，注册的一个统一资源定位符(Uniform Resource Locator，简称为URL)。RP就会根据用户提供的Open ID去发现OP，然后请求该OP对该用户身份进行鉴权。OP收到RP请求后，会要求用户登录OP认证页面进行鉴权，鉴权后，OP会提醒该用户是否容许外部网站对其鉴权。用户同意后，OP将鉴权结果返回给依赖方RP；这里的OP鉴权采用了GBA的引导模式，OP等效于GBA架构中的NAF。
运营商可以和部分应用业务提供商之间建立合作关系，为用户的应用业务提供良好的服务质量和应用体验，但是，目前网络第三方应用提供商的数量和种类越来越多，运营商不可能做到和所有应用提供商具备商业协作关系。因此，针对用户使用和运营商没有合作关系的第三方应用提供商的业务时，如何保证根据用户的要求来提供业务服务质量并确认使用是需要研究和解决的问题。
发明内容
本发明要解决的问题是提供一种更新服务质量的方法和系统，能够保证用户使用和运营商没有合作关系的第三方应用提供商的业务时，能根据用户要求来提供业务服务质量。
为解决上述技术问题，本发明提供了一种更新服务质量的方法，包括：
在业务过程中，终端(UE)将更新服务质量(QoS)请求或QoS确认指示发送给PGW；
所述PGW接收到所述更新QoS请求或QoS确认指示后，发起IP连接接入网(IP-CAN)会话修改流程，更新QoS。
进一步地，网络有PCC部署时，所述PGW接收到所述更新QoS请求或QoS确认指示后，发起IP-CAN会话修改流程，包括：PGW接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，所述PGW触发PCRF发起IP-CAN会话修改流程。
进一步地，更新QoS后，所述方法还包括：所述UE向PGW发送QoS信息和/或QoS确认消息，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；所述PGW根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
进一步地，更新QoS后，所述方法还包括：所述UE向PCRF发送QoS信息和/或QoS确认消息，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；所述PCRF根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
进一步地，所述UE将更新QoS请求或QoS确认指示发送给PGW，包括：所述UE通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW。
进一步地，所述UE将更新QoS请求或QoS确认指示发送给PGW，PGW接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，包括：所述UE通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW，所述PGW通过IP-CAN会话修改请求消息请求PCRF进行会话修改决策，所述IP-CAN会话修改请求消息中携带更新的QoS信息。
进一步地，所述UE通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW，包括：
所述UE向MME发送承载资源修改请求消息，消息中携带更新QoS请求信息或QoS确认指示，所述MME收到承载资源修改请求后向S-GW发送承载资源命令，命令中携带所述更新QoS请求信息或QoS确认指示，所述S-GW向PGW前转所述承载资源命令；或者
UE向MME发送携带更新QoS请求信息或QoS确认指示的请求消息，所述MME将所述请求消息转发给S-GW，S-GW将所述请求消息转发至PGW。
进一步地，所述更新QoS请求信息或QoS确认指示通过协议配置选项(PCO)字段携带，或PCO外的其它字段携带。
进一步地，所述UE向PGW发送QoS信息和/或QoS确认消息，包括：所述UE通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW。
进一步地，所述UE向PCRF发送QoS信息和/或QoS确认消息，包括：所述UE通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，PGW通过信用控制请求消息将QoS信息和/或QoS确认消息发送给PCRF。
进一步地，所述UE通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，包括：
所述UE向MME发送承载资源修改请求消息，消息中携带QoS信息和/或QoS确认消息，所述MME收到承载资源修改请求后向S-GW发送承载资源命令，命令中携带所述QoS信息和/或QoS确认消息，所述S-GW向PGW前转所述承载资源命令；或者
UE向MME发送携带QoS信息和/或QoS确认消息的请求消息，所述MME将所述请求消息转发给S-GW，S-GW将所述请求消息转发至PGW。
进一步地，所述PGW根据所述QoS信息和/或QoS确认消息决策维持当前QoS后，所述方法还包括：所述PGW向S-GW发送携带确认响应的承载资源失败指示，所述S-GW向MME前转所述承载资源失败指示，所述MME向所述UE发送承载资源修改拒绝消息作为确认响应。
进一步地，所述承载资源失败指示中的私有扩展字段携带用于携带所述确认响应。
进一步地，所述PCRF根据所述QoS信息和/或QoS确认消息决策维持当前QoS后，所述方法还包括：所述PCRF向所述PGW发送携带确认响应的IP-CAN会话修改指示消息，所述PGW向S-GW发送携带确认响应的承载资源失败指示，所述S-GW向MME前转所述承载资源失败指示，所述MME向所述UE发送承载资源修改拒绝消息作为确认响应。
进一步地，所述PGW根据所述QoS信息和/或QoS确认消息决策将QoS修改为更新前的QoS，包括：所述PGW发起IP-CAN会话修改流程，将QoS修改为更新前的QoS。
进一步地，所述PCRF根据所述QoS信息和/或QoS确认消息决策将QoS修改为更新前的QoS，包括：所述PCRF发起IP-CAN会话修改流程，将QoS修改为更新前的QoS。
进一步地，更新QoS后，所述方法还包括：
所述UE主动向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应；或者
所述UE在接收到所述PGW通过S-GW、MME向UE发送的携带有确认指示的通知消息后，向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应。
为解决上述技术问题，本发明还提供了一种更新服务质量的系统，包括位于终端的第一发送模块，以及位于PGW的第一QoS更新模块，其中：
所述第一发送模块，用于在业务过程中将更新服务质量(QoS)请求或QoS确认指示发送给PGW；
所述第一QoS更新模块，用于接收到所述更新QoS请求或QoS确认指示后，发起IP连接接入网(IP-CAN)会话修改流程，更新QoS。
进一步地，网络有PCC部署时，所述第一QoS更新模块是用于采用以下方式接收到所述更新QoS请求或QoS确认指示后，发起IP-CAN会话修改流程：
所述第一QoS更新模块接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，触发PCRF发起IP-CAN会话修改流程。
进一步地，所述第一发送模块，还用于在更新QoS后，通过承载资源修改流程或新增消息流程向PGW发送QoS信息和/或QoS确认消息，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；
所述第一QoS更新模块，还用于根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
进一步地，所述第一发送模块，还用于在更新QoS后，通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；
所述系统还包括位于PGW的第二发送模块，其用于通过信用控制请求消息将QoS信息和/或QoS确认消息发送给PCRF；
所述系统还包括位于PCRF的第二QoS更新模块，其用于根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
进一步地，所述第一发送模块是用于采用以下方式将更新QoS请求或QoS确认指示发送给PGW：所述第一发送模块通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW。
进一步地，所述第一QoS更新模块是用于采用以下方式请求PCRF进行会话修改决策：所述第一QoS更新模块通过IP-CAN会话修改请求消息请求PCRF进行会话修改决策，所述IP-CAN会话修改请求消息中携带更新的QoS信息。
进一步地，所述第一QoS更新模块还用于在决策维持当前QoS后，向S-GW发送携带确认响应的承载资源失败指示，通过S-GW和MME向所述UE发送确认响应。
进一步地，所述第二QoS更新模块还用于在决策维持当前QoS后，向所述PGW发送携带确认响应的IP-CAN会话修改指示消息，通过所述PGW、S-GW和MME向所述UE发送确认响应。
进一步地，第一发送模块还用于在更新QoS后，主动向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应；或者，在接收到所述PGW通过S-GW、MME向UE发送的携带有确认指示的通知消息后，向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应。
采用本发明实施例方法，通过让用户先感受提高的QoS再决策是否接受该QoS，从而实现根据用户的要求来提供业务服务质量。
附图说明
图1为3GPP演进分组系统结构示意图；
图2为Rel-10中非漫游场景下的PCC结构示意图；
图3为存在第三方应用提供商的PCC结构示意图；
图4为存在第三方应用提供商的漫游归属地路由PCC结构示意图；
图5为引入GBA的非漫游网络结构示意图；
图6为引入OpenID和GBA的非漫游网络结构示意图；
图7为本发明实施例流程图；
图8为实现图7方法的系统示意图；
图9为本发明实施例一的非漫游流程图；
图10为本发明实施例一的漫游流程图；
图11为本发明实施例二的流程图；
图12为本发明实施例三的流程图；
图13为本发明实施例四的流程图。
具体实施方式
在用户使用和运营商没有合作关系的第三方应用提供商的业务时，运营商需要能够具备独立为该网络的签约用户提供应用业务所需要的服务质量的能力，能够根据用户要求提升和降低服务质量，并能够按用户意愿来决策是否对该高服务质量进行额外收费。例如，某运营商MNO Y的签约用户A，在使用某第三方应用提供商X提供的业务(例如在线电影)，因为MNO Y和X没有合作关系，因此该业务使用默认承载提供的非保证带宽的服务质量；在业务使用过程中，用户A感觉到用户体验较差向运营商Y发起请求，要求提升该业务的服务质量，则运营商Y需要修改当前的该UE的IP-CAN会话，提升相应QOS；同时由于高服务质量需要额外收费，有必要通知用户是否满意该提升后的服务质量并愿意为此付费，在得到用户确认允许后，运营商才能为这种服务质量的提升额外收取费用。在现有网络技术中，由于UE和运营商的服务质量决策网元PCRF之间没有应用接口与通信协议，且现有UE和网络流程中也没有支持对该类服务质量的提升和确认的处理方案，从而导致现有技术无法实现上述需求。
本文提供以下方案解决上述问题，如图7所示，包括以下步骤：
步骤一，在业务过程中，终端(UE)将更新服务质量(QoS)请求或QoS确认指示发送给PGW；
具体地，UE可通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW。例如：UE向MME发送承载资源修改请求消息，消息中携带更新QoS请求信息或QoS确认指示，MME收到承载资源修改请求后向S-GW发送承载资源命令，命令中携带所述更新QoS请求信息或QoS确认指示(例如通过PCO(协议配置选项)字段携带，或通过PCO外的其它字段携带)，S-GW向PGW前转所述承载资源命令；或者，UE向MME发送携带更新QoS请求信息或QoS确认指示的请求消息，MME将该请求消息转发给S-GW，S-GW将该请求消息转发至PGW。
该QoS确认指示又可称为更新QoS指示，该更新QoS请求又可称为QoS确认请求。
步骤二，所述PGW接收到所述更新QoS请求或QoS确认指示后，发起IP连接接入网(IP-CAN)会话修改流程，更新QoS。
●当网络中没有PCC部署时，P-GW中没有PCEF，P-GW收到更新QoS请求或QoS确认指示后，发起会话修改。
更新QoS后，上述方法还包括：
UE向PGW发送QoS信息和/或QoS确认消息，该QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；PGW根据QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
UE可通过承载资源修改流程或新增消息流程向PGW发送QoS信息和/或QoS确认消息。具体地：UE向MME发送承载资源修改请求消息，消息中携带QoS信息和/或QoS确认消息，MME收到承载资源修改请求后向S-GW发送承载资源命令，命令中携带所述QoS信息和/或QoS确认消息，S-GW向PGW前转所述承载资源命令；或者，UE向MME发送携带QoS信息和/或QoS确认消息的请求消息，MME将请求消息转发给S-GW，S-GW将请求消息转发至PGW。
PGW根据QoS信息和/或QoS确认消息决策维持当前QoS后，上述方法还可包括以下步骤：PGW向S-GW发送携带确认响应的承载资源失败指示(该确认响应可置于承载资源失败指示中的私有扩展字段中)，S-GW向MME前转所述承载资源失败指示，MME向UE发送承载资源修改拒绝消息作为确认响应。
如果PGW根据QoS信息和/或QoS确认消息决策将QoS修改为更新前的QoS，则：PGW发起IP-CAN会话修改流程，将QoS修改为更新前的QoS。
●当网络中有PCC部署时，PCRF为决策体，PCEF是执行体，PCEF位于PGW内，上述PGW接收到所述更新QoS请求或QoS确认指示后，发起IP-CAN会话修改流程，包括：
PGW接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，所述PGW触发PCRF发起IP-CAN会话修改流程。
具体地：PGW通过以下方式请求PCRF进行会话修改决策：P-GW通过IP-CAN会话修改请求消息请求PCRF进行会话修改决策，所述IP-CAN会话修改请求消息中携带更新的QoS信息。
更新QoS后，上述方法还包括：
UE向PCRF发送QoS信息和/或QoS确认消息(例如：UE通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，PGW通过信用控制请求消息将QoS信息和/或QoS确认消息发送给PCRF)，QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；PCRF根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
PCRF根据QoS信息和/或QoS确认消息决策维持当前QoS后，上述方法还可包括以下步骤：PCRF向所述PGW发送携带确认响应的IP-CAN会话修改指示消息，PGW向S-GW发送携带确认响应的承载资源失败指示，S-GW向MME前转所述承载资源失败指示，MME向UE发送承载资源修改拒绝消息作为确认响应。
如果PCRF根据QoS信息和/或QoS确认消息决策将QoS修改为更新前的QoS，则：PCRF发起IP-CAN会话修改流程，将QoS修改为更新前的QoS。
更新QoS后，上述方法还包括：UE主动向PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应；或者，UE在接收到PGW通过S-GW、MME向UE发送的携带有确认指示的通知消息后，向PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应。
上述QoS的更新包括QoS的升高或降低。
实现上述方法的系统，包括位于终端的第一发送模块，以及位于PGW的第一QoS更新模块，其中：
所述第一发送模块，用于在业务过程中将更新服务质量(QoS)请求或QoS确认指示发送给PGW；
所述第一QoS更新模块，用于接收到所述更新QoS请求或QoS确认指示后，发起IP连接接入网(IP-CAN)会话修改流程，更新QoS。
优选地，第一发送模块，还用于在更新QoS后，通过承载资源修改流程或新增消息流程向PGW发送QoS信息和/或QoS确认消息，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；第一QoS更新模块，还用于根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
所述第一QoS更新模块还用于在决策维持当前QoS后，向S-GW发送携带确认响应的承载资源失败指示，通过S-GW和MME向所述UE发送确认响应。
优选地，网络有PCC部署时，第一QoS更新模块是用于采用以下方式接收到所述更新QoS请求或QoS确认指示后，发起IP-CAN会话修改流程：第一QoS更新模块接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，触发PCRF发起IP-CAN会话修改流程。
当网络有PCC部署时，优选地，第一发送模块还用于在更新QoS后，通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；上述系统还包括位于PGW的第二发送模块，其用于通过信用控制请求消息将QoS信息和/或QoS确认消息发送给PCRF；所述系统还包括位于PCRF的第二QoS更新模块，其用于根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
优选地，第一QoS更新模块是用于采用以下方式请求PCRF进行会话修改决策：通过IP-CAN会话修改请求消息请求PCRF进行会话修改决策，所述IP-CAN会话修改请求消息中携带更新的QoS信息。
优选地，第二QoS更新模块还用于在决策维持当前QoS后，向所述PGW发送携带确认响应的IP-CAN会话修改指示消息，通过所述PGW、S-GW和MME向所述UE发送确认响应。
优选地，第一发送模块还用于在更新QoS后，主动向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应；或者，在接收到所述PGW通过S-GW、MME向UE发送的携带有确认指示的通知消息后，向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应。
上述第一发送模块是用于采用以下方式将更新QoS请求或QoS确认指示发送给PGW：第一发送模块通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW。
为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
实施例一
本实施例为UE在非漫游场景下，接入3GPP网络，使用与运营商没有合作关系的第三方应用服务提供商的业务。运营商负责为UE的第三方应用提供传输资源，并能根据UE的需求扩展现有资源修改流程调整服务质量及通知UE确认，如图9所示，本实施例的服务质量更新和确认的方法具体包括如下步骤：
步骤101：UE附着到归属地网络，建立RRC(Radio Resource Control，无线资源控制协议)连接，建立无线承载，发起业务请求，并创建IP-CAN会话；
步骤102：UE成功访问Non-IMS AS(非IMS应用服务器)业务，这里UE和Non-IMS AS使用application level signaling或HTTP协议，non-IMS AS为UE提供应用业务；
步骤103：Non-IMS AS向PCRF发起Rx会话建立请求，携带UE ID/IP，Service ID/application ID，以及flow information相关信息给PCRF，PCRF向SPR/UDC获取签约AS信息，制定并下发PCC rule建立相关数据承载。由于该AS与运营商没有合作，授权QoS为default bearer QoS；
步骤104：完成该业务所需承载的创建；PCRF根据AS，SPR/UDC，PGW等client端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF；PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关eventtrigger(事件触发器)，以及用量监控阈值，监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；
步骤105：该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输；
步骤106：业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE向运营商发起更新QoS请求，触发QoS更新流程；
步骤107：UE发送承载资源修改请求(Request bearer resourcemodification)消息给MME，该请求消息中携带更新QoS指示信息；
该应用层相关参数——更新QoS指示信息可携带在PCO(协议配置选项)中或其它AVP中。除了更新QoS指示外，还可设置bear usage(承载使用)为优先承载，效果相同。此外，该请求消息中还可携带：UEIP/ID，承载ID(LBI)，流描述(TAD)，数据包过滤器ID(PTI)，QoS，消息中TAD指示请求为modify类型；若原先该应用为GBR承载，则修改请求中需要携带packet filter identifier(s)关联，如果有可能还会携带Service ID/Application ID。
步骤108：MME发送承载资源命令(bear resource command)消息给SGW，消息中包括更新QoS指示信息，以及其他相关参数；
步骤109：SGW收到该消息后前转该承载资源命令消息给PGW，消息携带收到的具体参数；
步骤110：PCEF(位于P-GW)根据收到的承载资源命令消息，判断需要更新QoS(例如根据携带了优先承载指示或更新QoS指示，或该业务请求的QoS高于先的QoS等)，发起IP-CAN会话修改流程处理，发送会话修改(session modification)请求给PCRF，消息中携带UE IP/ID，请求的QoS(即更新的QoS信息)，TAD，以及SDF fileter ID等参数。
本实施例为部署PCC的场景，如果在其他实施例中，网络中没有部署PCC，则步骤110-115不执行，策略决策由PGW完成。
步骤111-113：PCRF比较相关规则(correlate application)和业务信息(service inform)，如果AS签约了资源状态或修改事件，则向AS报告相关修改；
步骤114：PCRF查询SPR/UDC签约信息(例如该用户/业务/应用是否签约了高优先流处理；若签约允许则根据请求更新QoS)，更新PCC策略决策(policy decision)，下发更新后的PCC规则给PCEF/BBERF，or ADC规则给TDF/PCEF(如果存在应用流检测功能)。这里若PCRF本地没有签约信息，则PCRF还需要向SPR/UDC/HSS等数据库获取相关签约信息。
步骤115：PCRF下发更新后的PCC/QoS规则给PCEF，PCEF/BBERF更新PCC/QoS规则，修改或新建承载满足提升后的QoS。并反馈规则执行响应消息给PCRF(可选)，完成会话修改流程；
步骤116-123：PGW执行QoS策略，完成承载修改和绑定，下发更新承载请求(Update Bearer Request)给SGW，SGW前传到MME；MME构建承载修改请求(Bearer modify Request)消息下发给eNodeB，带上Bear ID，QoS；eNodeB映射EPS承载QoS到无线承载QoS下发RRC CR(connectionreconfiguration，连接重配置)消息给UE，UE更新存储相关QoS；逐级返回相关响应(response)消息直至给PGW，完成承载修改流程。
步骤124：若更新QoS成功，则需要发送更新QoS确认请求消息给UE，要求用户确认是否满意更新后的QoS，如果满意则UE返回肯定的确认消息(确认接受更新后的QoS可能需要为此优先流处理提供额外资费)；如果不满意或不同意支付额外的优先流处理费用，则UE给网络返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会默认构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，但具体处理根据运营商网络实现处理)；优选地，UE可在收到步骤119的消息后设置启动timer1(QoS提升定时器)，在Timer1时间超时(Time out)之后(Timer1有效期应能保证正常的PCRF发起的IP-CAN会话修改更新QoS处理完毕，即步骤123结束，且已经按新的QoS为UE提供应用业务)，UE承载向应用层发送确认请求消息，让用户感知。发送该请求消息后UE可开启用户确认定时器Timer2。
或者可以不由UE本身触发感知，而由网络侧下发通知，如实施例二中步骤424a-c。
步骤125：用户收到UE应用层的确认消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对该消息进行确认，UE将会发送给肯定的确认消息给该网络(在请求承载资源修改中PCO中携带肯定的确认信息)，运营商将根据该确认对该业务继续提供更新之后的QoS(例如，继续进行优先流处理，提供高优先级或高带宽资源)。若UE对提升后的业务数据流的服务质量或用户体验不满意或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回响应消息)或返回否定确认消息给网络，即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可构建否定确认消息发送给网络(在请求承载资源修改中PCO中携带否定的确认信息)，若User不确认则应用层则需要在等待确认的timer2时间超时之后触发承载层构建否定确认消息发送给网络，网络将会在一定preview(预览)时间之后将QoS恢复到请求提升之前的水平；
步骤126：MME收到UE的承载资源请求消息，给SGW发送承载资源命令，携带原消息中的参数，例如QoS，PCO(其中携带肯定或否定的确认信息或指示)；
在其他实施例中，也可以采用PCO以外的其他字段携带该肯定或否定的确认信息或指示。
步骤127：SGW前传该消息到PGW，携带QoS和PCO等参数；
步骤128：PCEF发起IP-CAN会话修改过程，PGW根据PCO中的确认信息/指示判断用户业务所需的QoS，若为肯定确认，则执行步骤129；若为否定确认则发送IP-CAN会话修改请求(如果PCEF和PCRF之间采用diameter协议，则可使用信用控制请求消息承载该IP-CAN会话修改请求消息以及其他IP会话相关消息)给PCRF发起会话修改流程，降级(downgrade)QoS；PCRF收到降级QoS请求消息后，结合签约信息及本地策略(例如用户确认接收更新QoS的Preview timer(预览定时器)超时则需要回复原先QoS)，发起IP-CAN会话修改流程，或还可能发起GWcontrol或TDF会话修改流程，相应地，更新相关PCC规则，或还可能QoS规则或ADC规则，恢复该业务原来的QoS；该IP-CAN会话修改流程参见步骤110-123，修改承载和会话，为该业务提供的QoS将恢复到用户提升请求之前的水平，按原有的QoS继续执行步骤132提供下行业务数据流；
需要说明的是，QoS回退机制不在本文讨论范围内，可采用例如网元间的定时器机制处理会话修改的回退时间，可本地存储更新之前的QoS，或者UE发送降级QoS请求消息时携带此前的QoS信息，或者请求消息中携带使用默认QoS指示等。
步骤129：PGW收到肯定的确认消息后下发承载资源失败指示(bearrecourse failure indication)给SGW，消息中携带承载ID，PTI，失败原因，以及私有扩展(private extension)字段(指示该消息为确认的响应)；对资源不做任何修改，仅仅作为ACK消息；
步骤130：SGW前转该消息到MME，在私有扩展字段中带上确认响应(confirm response)，对资源不做任何修改，仅仅作为ACK消息；
步骤131：MME下发承载资源修改拒绝(bear recourse modification reject)消息给UE，带上PTI和ESM原因(cause)；UE判断该消息为确认响应，则不会再次触发用户确认(User confirm)流程；该提升QoS请求及确认的处理过程执行完毕；
步骤132：提升或恢复QoS流程处理完毕，若为步骤128则在降级QoS完成后，按最初的QoS传送下行数据；若为更新QoS成功确认步骤131，则按提升后的QoS传送下行数据。即网络按授权的QoS为该业务继续提供业务数据流。
以上流程描述中，更新QoS指示在PCO中携带给网络，除此之外还可能在PCO外新增AVP字段携带该指示；具体消息流程同上面描述，这里不作重复说明；
以上流程中除了策略控制，还存在计费相关处理流程，例如更新QoS后，新的PCC规则中可能下发新的计费关键字(对应新的计费费率)，可能存在PCRF、PCEF/BBERF/TDF等网元与计费网元OCS/OFCS以及其它计费系统的交互；该部分处理不在本文讨论范围之内，故在此不作详述；
以上步骤101-132为非漫游场景的处理流程，业务使用过程中，若UE漫游到拜访地(参见图4，为漫游归属地路由(roaming home routed)场景)，则需要通知UE发生漫游，若此前为提升了QoS则还需UE再次确认是否需要保持高QoS/高优先级流处理(若用户确认该业务的高QoS处理，则可能需要支付额外的高优先级流处理费用)，若用户确认则拜访地依然为该UE提供高QoS，若用户不确认或否定确认则拜访地将采用默认QoS提供该业务；具体步骤如图10所示：
步骤133：HPCRF获知UE发生了漫游，发送QoS确认指示给UE，通知UE漫游，并发送优先流处理的确认消息(confirm inform)给UE，请求UE确认是否在拜访地将继续使用QoS业务流处理；消息中携带确认指示(confirm indication)，以及其他相关信息例如UEID/IP和QoS，以及可能存在其它业务信息，例如流信息，业务ID/应用ID等；
这里HPCRF通过中间逻辑功能或网元间接通知UE或直接发送给UE确认通知不在本文讨论范围之内(例如可通过PCRF的某个客户(client)端以信令发送下发通知，或通过其它应用功能网元以HTTP通知UE)。发送优先流处理高QoS的确认请求消息给UE，要求用户确认是否保留高QoS流处理，如果同意则返回肯定的确认消息(确认保留高QoS可能需要为此优先流处理提供额外资费)；如果不同意支付额外的优先流处理费用，则返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，但具体处理根据运营商网络实现处理)；
步骤134：UE收到该确认消息后，若想保留高QoS且愿意支付优先流处理的费用，则对该消息进行确认，UE将会发送该确认响应消息给网络，进一步反馈给归属地PCRF，运营商将对该业务继续提供高QoS(例如，继续进行优先流处理，提供高优先级或高带宽资源)。
若UE不愿意支付额外的优先处理费用而不想使用高优先流处理或高QoS，则用户不对该确认请求进行确认(不返回响应消息)或返回否定确认消息(确认响应消息，或者降级QoS请求消息)给网络。如果用户不同意提供该业务高QoS但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给网络，执行步骤134a；
步骤134a：若网络在规定时间内没有收到用户的确认接收消息，或收到了用户的确认拒绝消息或更新QoS请求消息，则PCRF将可能发起IP-CAN会话修改流程，更新QoS请求(例如，降级QoS)；
HPCRF结合签约信息及本地策略(例如用户确认保留高QoS的Previewtimer超时则需要降低QoS)，发起IP-CAN或GWcontrol或TDF会话修改流程，更新相关PCC或QoS或ADC规则，恢复该业务的默认QoS；若UE发送的降QoS请求消息给PGW则该IP-CAN会话修改流程还有可能由PCEF发起。
网络对该业务数据流的处理恢复到默认QoS，按默认承载QoS下发该业务数据流。
以上实施例的描述中，漫游确认通知的默认处理为默认QoS处理，即用户不确认或否定确认则降QoS(默认承载提供该业务)；用户返回肯定确认则继续保持高优先级处理。实际处理的默认处理方式还可以是默认为高优先级流处理(即漫游后用户不确认或肯定确认采用高优先级提供该业务)，如果用户提供否定确认则降QoS(用默认承载为该业务提供QoS)。具体漫游后的默认处理方式本发明不作限定。
以上流程中具体归属地和漫游地的S9会话遵从现有技术实现；此外，漫游本地接入本地疏导(local brakeout)的场景，通知确认和QoS修改流程处理同上，本文不作重复描述。
经过上述流程，可实现运营商为用户UE提供非合作第三方应用提供商的业务时的资源分配与更新等策略控制处理；用户可以根据自身需求提升或降低服务质量/用户体验，变更运营商为该业务传送的消耗资源所对应的业务资费费率；
实施例二
本实施例为UE接入3GPP网络，使用与运营商没有合作关系的第三方应用服务提供商的业务。运营商负责为UE的第三方应用提供传输资源，并能根据UE的需求扩展现有资源修改流程调整服务质量及通知UE确认，如图11所示，本发明的服务质量更新和确认的方法具体包括如下步骤：
步骤201：UE附着到归属地网络，建立无线承载和创建IP-CAN会话；
步骤202：UE成功访问Non-IMS AS业务，这里UE和Non-IMS AS使用application level signaling或HTTP协议，non-IMS AS为UE提供应用业务；
步骤203：Non-IMS AS向PCRF发起Rx会话建立请求，携带UE ID/IP，Service ID/application ID，以及flow information相关信息给PCRF。PCRF向SPR/UDC获取签约AS信息，制定并下发PCC rule给PCEF，建立相关数据承载。由于该AS与运营商没有合作，授权QoS为默认承载(default bearer)QoS；
步骤204：完成该业务所需承载的创建；PCRF根据AS，SPR/UDC，PGW等client端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF；PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关eventtrigger，以及用量监控阈值，监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；
步骤205：该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输；
步骤206：业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE向运营商发起提升QoS请求，触发UE请求流程；
步骤207：UE发送请求(Request)消息给MME，该请求消息中携带更新QoS指示信息，此外请求消息中还携带请求的类型(更新QoS)，UEIP/ID，承载ID(LBI)，flow information(例如流描述(TAD)，数据包过滤器ID(PTI)等)，QoS。若原先该业务/应用为GBR承载，则请求中可能携带packet filteridentifier(s)；以及如果有可能还会携带Service ID/Application ID；
步骤208：MME前转发送request消息给SGW，消息中包括步骤207中的相关参数；
步骤209：SGW收到该消息后前转该request消息给PGW，消息携带收到的具体参数；
步骤210：PCEF根据收到的request消息参数，判断需要更新QoS(例如根据携带了优先流处理或承载指示，或QoS更新指示，或该业务请求的QoS高于先的QoS等)，发起IP-CAN会话修改流程处理，发送会话修改请求给PCRF。消息中携带UE IP/ID，请求的QoS，flow information(例如TAD，以及SDF fileter ID)等参数。
步骤211-213：PCRF比较相关规则和业务信息，如果AS签约了资源状态或修改事件，则向AS报告相关修改；
步骤214：PCRF查询SPR/UDC签约信息(例如该用户/业务/应用是否签约了高优先流处理；若签约允许则根据请求提升QoS)，更新PCC策略决策，下发更新后的PCC规则给PCEF/BBERF，or ADC规则给TDF/PCEF(如果存在应用流检测功能)。这里若PCRF本地没有签约信息，则PCRF还需要向SPR/UDC/HSS等数据库获取相关签约信息。
步骤215：PCEF/BBERF更新PCC/QoS规则，修改或新建承载满足提升后的QoS。并反馈规则执行响应消息给PCRF，完成会话修改流程。
步骤216-223：PGW执行QoS策略，完成承载修改和绑定，下发更新承载请求(Update Bearer Request)给SGW，SGW前传到MME；MME构建承载修改请求消息下发给eNodeB，带上Bear ID，QoS；eNodeB映射EPS承载QoS到无线承载QoS下发RRL CR消息给UE，UE更新存储相关QoS；逐级返回相关response消息直至给PGW，完成承载修改流程。
步骤224：若更新QoS成功，则需要发送更新QoS确认请求消息给UE，要求用户确认是否满意更新后的QoS，如果满意则UE返回肯定的确认消息(确认接受更新后的QoS可能需要为此优先流处理提供额外资费)；如果不满意或不同意支付额外的优先流处理费用，则UE给网络返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，但具体处理根据运营商网络实现处理)；该处理流程，UE可在收到步骤219的消息后设置启动timer1(QoS提升定时器)，在Timer1定时时间超时之后(Timer1有效期应能保证正常的PCRF发起的IP-CAN会话修改更新QoS处理完毕，即步骤223结束，且已经按新的QoS为UE提供应用业务)，UE承载向应用层发送确认请求消息，让用户感知。发送该请求消息后UE可开启用户确认定时器Timer2。
或者可以不由UE本身触发感知，而由网络侧下发通知，则步骤224a-c替代步骤224执行：
步骤224a：在完成IP-CAN会话修改流程后，按更新后的QoS为该业务提供业务数据流；PGW/PCEF下发一个通知消息给UE，要求UE对更新后的QoS进行确认，该通知消息中携带确认指示，表示用户请求的QoS更新完成，请求确认；
步骤224b：SGW收到该通知消息后，下发该通知给MME，如224a中带上UEID/IP，必要的业务流信息，以及该确认指示；
步骤224c：MME将该消息下发给UE；UE收到该通知消息后将提供一个通知指示给上层(例如应用层)，触发用户感知；
可选地，若不作为后续步骤225的请求消息，224a-c步骤存在上行的响应消息。
步骤225：用户收到UE应用层的确认消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对该消息进行确认，UE将会发送给肯定的确认消息给该网络(在请求或通知响应中携带肯定的确认信息)，运营商将根据该确认对该业务继续提供更新之后的QoS(例如，继续进行优先流处理，提供高优先级或高带宽资源)。若UE对提升后的业务数据流的服务质量或用户体验不满意和或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回确认响应消息)或返回否定确认消息给网络(即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给网络，若User不确认则应用层则需要在等待确认的timer2时间超时之后触发承载层构建否定确认消息发送给网络，网络将会在一定preview时间之后将QoS恢复到请求提升之前的水平；
在其他实施例中，除了在请求或通知响应中携带确认信息，也可以在请求或通知响应中携带更新QoS指示。
步骤226：MME收到UE的请求或通知响应消息，给SGW前转该消息，携带原消息中的参数，例如UE IP/ID，QoS，肯定或否定的确认信息/指示等；
步骤227：SGW前传该消息到PGW，携带QoS和确认信息/指示等参数；
步骤228：PGW根据确认信息/指示判断用户业务所需的QoS，若为肯定确认，则执行步骤229。
若为否定确认则发送IP-CAN会话修改请求给PCRF发起会话修改流程，降级QoS；PCRF收到降级QoS请求消息后，结合签约信息及本地策略(例如用户确认接收更新QoS的Preview timer超时则需要回复原先QoS)，发起IP-CAN或GWcontrol或TDF会话修改流程，更新相关PCC或QoS或ADC规则，恢复该业务的原先QoS；该IP-CAN会话修改流程参见步骤210-223，修改承载和会话，为该业务提供的QoS将恢复到用户提升请求之前的水平，按原有的QoS继续执行步骤229提供下行业务数据流；(QoS回退机制不在本文讨论范围内，可采用例如网元间的定时器机制处理会话修改的回退时间，可本地存储更新之前的QoS，或者UE发送降级QoS请求消息时携带此前的QoS信息，或者请求消息中携带使用默认QoS指示等)。
优选地，若步骤225-227为UE请求消息，则存在下行的响应消息，从PGW到UE。
步骤229：提升或恢复QoS流程处理完毕。若为步骤228则在降级QoS完成后，按最初的QoS传送下行数据；若为更新QoS成功确认步骤227，则按提升后的QoS传送下行数据。即，网络按授权的QoS为该业务继续提供业务数据流。
在其他实施例中，步骤224a-224c可能会存在相应的响应消息。步骤225-227也可能会存在相应的响应消息。优选地，步骤225-227可以是224a-224c的响应消息。
以上流程中除了策略控制，还存在计费相关处理流程，例如更新QoS后，新的PCC规则中可能下发新的计费关键字(对应新的计费费率)，可能存在PCRF、PCEF/BBERF/TDF等网元与计费网元OCS/OFCS以及其它计费系统的交互；该部分处理不在本文讨论范围之内，故本实施例在此不作详述；
以上步骤201-229为非漫游场景的处理流程，业务使用过程中，若UE漫游到拜访地(参见图4，为漫游归属地路由场景)，则需要通知UE发生漫游，若此前为提升了QoS则还需UE再次确认是否需要保持高QoS/高优先级流处理(若用户确认该业务的高QoS处理，则可能需要支付额外的高优先级流处理费用)，若用户确认则拜访地依然为该UE提供高QoS，若用户不确认或否定确认则拜访地将采用默认QoS提供该业务；具体步骤同步骤133-135所示。这里不作重复描述。网络侧通知UE确认的消息可采用步骤224a-224c的消息，也可以重用其它现有消息，这里不做限定。
以实施例的描述中，漫游确认通知的默认处理为默认QoS处理，即用户不确认或否定确认则降QoS(默认承载提供该业务)；用户返回肯定确认则继续保持高优先级处理。实际处理的默认处理方式还可以是默认为高优先级流处理(即漫游后用户不确认或肯定确认采用高优先级提供该业务)，如果用户提供否定确认则降QoS(用默认承载为该业务提供QoS)。具体漫游后的默认处理方式本发明不作限定。
以上流程中具体归属地和漫游地的S9会话遵从现有技术实现；此外，漫游本地接入本地疏导的场景，通知确认和QoS修改流程处理同上，本说明书不作重复描述。
经过上述流程，可实现运营商为用户UE提供非合作第三方应用提供商的业务时的资源分配与更新等策略控制处理；用户可以根据自身需求提升或降低服务质量/用户体验，变更运营商为该业务传送的消耗资源所对应的业务资费费率；
实施例三
本实施例基于图5，图5为基于GBA的非漫游网络结构图，本实施例描述的UE在非漫游场景下，接入3GPP网络，使用与运营商没有合作关系的第三方应用服务提供商的业务。运营商负责对UE和第三方应用提供商进行鉴权和传输资源分配，根据UE的需求调整服务质量，并需通知UE确认，如图12所示，本发明的服务质量更新和确认的方法具体包括如下步骤：
步骤301：UE附着到归属地网络，建立无线承载和创建IP-CAN会话；
步骤302：UE访问Non-IMS AS/NAF，采用GBA的引导(bootstrapping)方式，UE向BSF发送注册请求，带上UEID；BSF向HSS获取签约信息以及鉴权向量，BSF完成对UE的鉴权，生成Ks和B-TID，并将B-TID返回给UE，UE向NAF/Non-IMS AS发送应用请求，携带B-TID；NAFNon-IMSAS利用该BTID向BSF发起鉴权请求，成功后向UE返回响应。UE和Non-IMS AS建立安全会话；
步骤303：NAF/Non-IMS AS向PCRF发起Rx会话建立请求，携带UEID/IP，Service ID/application ID，以及流信息(flow information)相关信息给PCRF。PCRF向SPR/UDC获取签约AS信息，制定并下发PCC rule给PCEF，建立相关数据承载。由于该AS与运营商没有合作，授权QoS为默认承载QoS；
步骤304：完成该业务所需承载的创建；PCRF根据Non-IMS AS，SPR/UDC，PGW等客户端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF；PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关event trigger，以及用量监控阈值，监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；
步骤305：该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输；
步骤306-332：业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE向运营商发起提升QoS请求；该请求过程和运营商根据用户请求更新QoS并发送确认消息给用户、根据用户确认继续或调整QoS的相关处理同步骤106-132；
以上描述以重用资源修改过程为基础，同时也可遵从实施例二中的请求和通知处理消息；具体实施同实施例二中的描述，这里不作重复描述。
实施例四
本实施例基于图6，图6基于OpenID和GBA网络结构本实施例描述的UE在非漫游场景下，接入3GPP网络，使用与运营商没有合作关系的第三方应用服务提供商的业务。运营商负责对UE和第三方应用提供商进行鉴权和传输资源分配，根据UE的需求调整服务质量，并需通知UE确认。如图13所示，本发明的服务质量更新和确认的方法具体包括如下步骤：
步骤401：UE附着到归属地网络，建立无线承载和创建IP-CAN会话；
步骤402：UE请求登录RP网站(第三方应用提供商)，选择了以OpenID方式来登录；RP通过对用户的Open ID的标准化发现OP，跟OP建立安全通道用于传输信息(例如RP请求OP对用户身份进行鉴权)；RP将OpenId的登录界面返回给终端用户，或重定向用户到OP；用户登录OP，OP对用户鉴权，请求用户进行登录认证(这里采用了GBA认证方式)；则UE向BSF发送注册请求，带上UEID；BSF向HSS获取签约信息以及鉴权向量，BSF完成对UE的鉴权，生成Ks和B-TID，并将B-TID返回给UE，UE向NAF/OP发送应用请求，携带B-TID；NAF/OP利用该BTID向BSF发起鉴权请求，成功后向UE返回响应。UE和NAF/OP建立安全会话；OP将鉴权结果返回给RP，RP对OP的结果进行分析，如用户合法则返回用户鉴权成功，可以使用RP服务；由此完成UE和RP的鉴权和认证；
步骤403：RP/Non-IMS AS向PCRF发起Rx会话建立请求，携带UE ID/IP，Service ID/application ID，以及flow information相关信息给PCRF。PCRF向SPR/UDC获取签约AS信息，制定并下发PCC rule给PCEF，建立相关数据承载。由于该AS与运营商没有合作，授权QoS为默认承载QoS；
步骤404：完成该业务所需承载的创建；PCRF根据Non-IMS AS，SPR/UDC，PGW等客户端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF；PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关event trigger，以及用量监控阈值，监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；
步骤405：该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输；
步骤406-432：业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE向运营商发起提升QoS请求。该请求过程和运营商根据用户请求更新QoS并发送确认消息给用户，根据用户确认继续或调整QoS的相关处理同步骤106-132；
以上描述以重用资源修改过程为基础，同时也可遵从实施例二中的请求和通知处理消息；具体实施同实施例二中的描述，这里不作重复描述。
以上IP-CAN会话修改流程，PCC为可选特征(feature)。若存在PCC，则所有的修改请求PGW都需要发送到PCRF决策，由PCRF下发规则到PGW，执行流程修改。若不存在PCC部署，则相关修改请求发送到PGW即可。相关实施例中不再一一描述。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。
当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
Claims (26)
1.一种更新服务质量的方法，包括：
在业务过程中，终端(UE)将更新服务质量(QoS)请求或QoS确认指示发送给PGW；
所述PGW接收到所述更新QoS请求或QoS确认指示后，发起IP连接接入网(IP-CAN)会话修改流程，更新QoS。
2.如权利要求1的方法，其特征在于：
网络有PCC部署时，所述PGW接收到所述更新QoS请求或QoS确认指示后，发起IP-CAN会话修改流程，包括：
PGW接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，所述PGW触发PCRF发起IP-CAN会话修改流程。
3.如权利要求1的方法，其特征在于：
更新QoS后，所述方法还包括：
所述UE向PGW发送QoS信息和/或QoS确认消息，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；所述PGW根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
4.如权利要求2的方法，其特征在于：
更新QoS后，所述方法还包括：
所述UE向PCRF发送QoS信息和/或QoS确认消息，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；所述PCRF根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
5.如权利要求1的方法，其特征在于：
所述UE将更新QoS请求或QoS确认指示发送给PGW，包括：
所述UE通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW。
6.如权利要求2的方法，其特征在于：
所述UE将更新QoS请求或QoS确认指示发送给PGW，PGW接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，包括：
所述UE通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW，所述PGW通过IP-CAN会话修改请求消息请求PCRF进行会话修改决策，所述IP-CAN会话修改请求消息中携带更新的QoS信息。
7.如权利要求5或6的方法，其特征在于：
所述UE通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW，包括：
所述UE向MME发送承载资源修改请求消息，消息中携带更新QoS请求信息或QoS确认指示，所述MME收到承载资源修改请求后向S-GW发送承载资源命令，命令中携带所述更新QoS请求信息或QoS确认指示，所述S-GW向PGW前转所述承载资源命令；或者
UE向MME发送携带更新QoS请求信息或QoS确认指示的请求消息，所述MME将所述请求消息转发给S-GW，S-GW将所述请求消息转发至PGW。
8.如权利要求7的方法，其特征在于：
所述更新QoS请求信息或QoS确认指示通过协议配置选项(PCO)字段携带，或PCO外的其它字段携带。
9.如权利要求3的方法，其特征在于：
所述UE向PGW发送QoS信息和/或QoS确认消息，包括：
所述UE通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW。
10.如权利要求4的方法，其特征在于：
所述UE向PCRF发送QoS信息和/或QoS确认消息，包括：
所述UE通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，PGW通过信用控制请求消息将QoS信息和/或QoS确认消息发送给PCRF。
11.如权利要求9或10的方法，其特征在于：
所述UE通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，包括：
所述UE向MME发送承载资源修改请求消息，消息中携带QoS信息和/或QoS确认消息，所述MME收到承载资源修改请求后向S-GW发送承载资源命令，命令中携带所述QoS信息和/或QoS确认消息，所述S-GW向PGW前转所述承载资源命令；或者
UE向MME发送携带QoS信息和/或QoS确认消息的请求消息，所述MME将所述请求消息转发给S-GW，S-GW将所述请求消息转发至PGW。
12.如权利要求3的方法，其特征在于：
所述PGW根据所述QoS信息和/或QoS确认消息决策维持当前QoS后，所述方法还包括：
所述PGW向S-GW发送携带确认响应的承载资源失败指示，所述S-GW向MME前转所述承载资源失败指示，所述MME向所述UE发送承载资源修改拒绝消息作为确认响应。
13.如权利要求12的方法，其特征在于：
所述承载资源失败指示中的私有扩展字段携带用于携带所述确认响应。
14.如权利要求4的方法，其特征在于：
所述PCRF根据所述QoS信息和/或QoS确认消息决策维持当前QoS后，所述方法还包括：
所述PCRF向所述PGW发送携带确认响应的IP-CAN会话修改指示消息，所述PGW向S-GW发送携带确认响应的承载资源失败指示，所述S-GW向MME前转所述承载资源失败指示，所述MME向所述UE发送承载资源修改拒绝消息作为确认响应。
15.如权利要求3所述的方法，其特征在于：
所述PGW根据所述QoS信息和/或QoS确认消息决策将QoS修改为更新前的QoS，包括：
所述PGW发起IP-CAN会话修改流程，将QoS修改为更新前的QoS。
16.如权利要求4所述的方法，其特征在于：
所述PCRF根据所述QoS信息和/或QoS确认消息决策将QoS修改为更新前的QoS，包括：
所述PCRF发起IP-CAN会话修改流程，将QoS修改为更新前的QoS。
17.如权利要求1或2的方法，其特征在于：
更新QoS后，所述方法还包括：
所述UE主动向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应；或者
所述UE在接收到所述PGW通过S-GW、MME向UE发送的携带有确认指示的通知消息后，向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应。
18.一种更新服务质量的系统，包括位于终端的第一发送模块，以及位于PGW的第一QoS更新模块，其中：
所述第一发送模块，用于在业务过程中将更新服务质量(QoS)请求或QoS确认指示发送给PGW；
所述第一QoS更新模块，用于接收到所述更新QoS请求或QoS确认指示后，发起IP连接接入网(IP-CAN)会话修改流程，更新QoS。
19.如权利要求18的系统，其特征在于：
网络有PCC部署时，所述第一QoS更新模块是用于采用以下方式接收到所述更新QoS请求或QoS确认指示后，发起IP-CAN会话修改流程：
所述第一QoS更新模块接收到所述更新QoS请求或QoS确认指示后请求PCRF进行会话修改决策，触发PCRF发起IP-CAN会话修改流程。
20.如权利要求18的系统，其特征在于：
所述第一发送模块，还用于在更新QoS后，通过承载资源修改流程或新增消息流程向PGW发送QoS信息和/或QoS确认消息，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；
所述第一QoS更新模块，还用于根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
21.如权利要求19的系统，其特征在于：
所述第一发送模块，还用于在更新QoS后，通过承载资源修改流程或新增消息流程将QoS信息和/或QoS确认消息发送给PGW，所述QoS信息和/或QoS确认消息用于指示接受当前QoS或不接受当前QoS；
所述系统还包括位于PGW的第二发送模块，其用于通过信用控制请求消息将QoS信息和/或QoS确认消息发送给PCRF；
所述系统还包括位于PCRF的第二QoS更新模块，其用于根据所述QoS信息和/或QoS确认消息决策维持当前QoS或将QoS修改为更新前的QoS。
22.如权利要求18或19的系统，其特征在于：
所述第一发送模块是用于采用以下方式将更新QoS请求或QoS确认指示发送给PGW：
所述第一发送模块通过承载资源修改流程或新增消息流程将更新QoS请求或QoS确认指示发送给PGW。
23.如权利要求19的系统，其特征在于：
所述第一QoS更新模块是用于采用以下方式请求PCRF进行会话修改决策：
所述第一QoS更新模块通过IP-CAN会话修改请求消息请求PCRF进行会话修改决策，所述IP-CAN会话修改请求消息中携带更新的QoS信息。
24.如权利要求20的系统，其特征在于：
所述第一QoS更新模块还用于在决策维持当前QoS后，向S-GW发送携带确认响应的承载资源失败指示，通过S-GW和MME向所述UE发送确认响应。
25.如权利要求21的系统，其特征在于：
所述第二QoS更新模块还用于在决策维持当前QoS后，向所述PGW发送携带确认响应的IP-CAN会话修改指示消息，通过所述PGW、S-GW和MME向所述UE发送确认响应。
26.如权利要求18或19的系统，其特征在于：
第一发送模块还用于在更新QoS后，主动向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应；或者，在接收到所述PGW通过S-GW、MME向UE发送的携带有确认指示的通知消息后，向所述PGW发送携带更新QoS指示的请求消息或者发送携带确认信息的通知响应。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110304877.6A CN103037449B (zh) | 2011-10-10 | 2011-10-10 | 一种更新服务质量的方法及系统 |
| PCT/CN2012/082588 WO2013064004A1 (zh) | 2011-10-10 | 2012-10-08 | 一种更新服务质量的方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110304877.6A CN103037449B (zh) | 2011-10-10 | 2011-10-10 | 一种更新服务质量的方法及系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103037449A true CN103037449A (zh) | 2013-04-10 |
| CN103037449B CN103037449B (zh) | 2018-01-19 |
Family
ID=48023818
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201110304877.6A Expired - Fee Related CN103037449B (zh) | 2011-10-10 | 2011-10-10 | 一种更新服务质量的方法及系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN103037449B (zh) |
| WO (1) | WO2013064004A1 (zh) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015085531A1 (zh) * | 2013-12-12 | 2015-06-18 | 华为技术有限公司 | Qos提升方法、装置及系统 |
| CN105827415A (zh) * | 2015-01-07 | 2016-08-03 | 中国移动通信集团上海有限公司 | 用于加速业务专有承载恢复的pcc系统、设备及方法 |
| EP3076703A4 (en) * | 2013-12-26 | 2016-11-23 | Huawei Tech Co Ltd | METHOD, DEVICE AND SYSTEM FOR NETWORK VIDEO OUTPUT |
| WO2017084603A1 (zh) * | 2015-11-19 | 2017-05-26 | 中兴通讯股份有限公司 | Pcc规则的处理方法及装置 |
| WO2018006306A1 (zh) * | 2016-07-06 | 2018-01-11 | 华为技术有限公司 | 一种网络连接配置方法及装置 |
| WO2018082559A1 (en) * | 2016-11-07 | 2018-05-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Service differentiation for devices connected to a ue as a router |
| CN108353245A (zh) * | 2015-11-27 | 2018-07-31 | 华为技术有限公司 | 一种信息内容传输方法和装置 |
| CN109804660A (zh) * | 2018-02-06 | 2019-05-24 | Oppo广东移动通信有限公司 | 服务质量流重映射实现方法、装置、设备及存储介质 |
| US10516783B2 (en) | 2015-11-19 | 2019-12-24 | Zte Corporation | Method and device for processing PCC rule |
| WO2021139696A1 (zh) * | 2020-01-06 | 2021-07-15 | 华为技术有限公司 | 一种报告信息的发送方法、装置及系统 |
| CN114866530A (zh) * | 2022-03-28 | 2022-08-05 | 深圳优地科技有限公司 | 升级数据包的下载方法、设备以及计算机存储介质 |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110035018B (zh) * | 2018-01-12 | 2021-08-13 | 华为技术有限公司 | 确定网络服务质量流的方法、网元和系统 |
| US11438802B2 (en) * | 2019-11-27 | 2022-09-06 | Aeris Communications, Inc. | Method and system for quality-of-service authorization based on type of radio access technology and other data session attributes |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1859400A (zh) * | 2006-01-05 | 2006-11-08 | 华为技术有限公司 | 对修改服务质量信息进行处理的方法 |
| CN1863145A (zh) * | 2005-05-15 | 2006-11-15 | 华为技术有限公司 | 互通无线局域网中服务质量修改方法 |
| CN101932034A (zh) * | 2009-06-26 | 2010-12-29 | 华为技术有限公司 | 提高服务质量的方法及系统和应用网网元 |
| CN102026303A (zh) * | 2009-09-21 | 2011-04-20 | 中兴通讯股份有限公司 | 一种实现家用基站上QoS控制的方法和系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8768295B2 (en) * | 2010-02-18 | 2014-07-01 | Alcatel Lucent | Method of handling a change to bearer control mode |
-
2011
- 2011-10-10 CN CN201110304877.6A patent/CN103037449B/zh not_active Expired - Fee Related
-
2012
- 2012-10-08 WO PCT/CN2012/082588 patent/WO2013064004A1/zh active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1863145A (zh) * | 2005-05-15 | 2006-11-15 | 华为技术有限公司 | 互通无线局域网中服务质量修改方法 |
| CN1859400A (zh) * | 2006-01-05 | 2006-11-08 | 华为技术有限公司 | 对修改服务质量信息进行处理的方法 |
| CN101932034A (zh) * | 2009-06-26 | 2010-12-29 | 华为技术有限公司 | 提高服务质量的方法及系统和应用网网元 |
| CN102026303A (zh) * | 2009-09-21 | 2011-04-20 | 中兴通讯股份有限公司 | 一种实现家用基站上QoS控制的方法和系统 |
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015085531A1 (zh) * | 2013-12-12 | 2015-06-18 | 华为技术有限公司 | Qos提升方法、装置及系统 |
| CN105814853A (zh) * | 2013-12-12 | 2016-07-27 | 华为技术有限公司 | Qos提升方法、装置及系统 |
| CN105814853B (zh) * | 2013-12-12 | 2019-10-25 | 华为技术有限公司 | Qos提升方法、装置及系统 |
| US10129320B2 (en) | 2013-12-12 | 2018-11-13 | Huawei Technologies Co., Ltd. | QoS improvement method, apparatus, and system |
| EP3076703A4 (en) * | 2013-12-26 | 2016-11-23 | Huawei Tech Co Ltd | METHOD, DEVICE AND SYSTEM FOR NETWORK VIDEO OUTPUT |
| CN105827415A (zh) * | 2015-01-07 | 2016-08-03 | 中国移动通信集团上海有限公司 | 用于加速业务专有承载恢复的pcc系统、设备及方法 |
| CN105827415B (zh) * | 2015-01-07 | 2018-12-04 | 中国移动通信集团上海有限公司 | 用于加速业务专有承载恢复的pcc系统、设备及方法 |
| WO2017084603A1 (zh) * | 2015-11-19 | 2017-05-26 | 中兴通讯股份有限公司 | Pcc规则的处理方法及装置 |
| US10516783B2 (en) | 2015-11-19 | 2019-12-24 | Zte Corporation | Method and device for processing PCC rule |
| CN108353245A (zh) * | 2015-11-27 | 2018-07-31 | 华为技术有限公司 | 一种信息内容传输方法和装置 |
| CN109196893A (zh) * | 2016-07-06 | 2019-01-11 | 华为技术有限公司 | 一种网络连接配置方法及装置 |
| WO2018006306A1 (zh) * | 2016-07-06 | 2018-01-11 | 华为技术有限公司 | 一种网络连接配置方法及装置 |
| US10849135B2 (en) | 2016-07-06 | 2020-11-24 | Huawei Technologies Co., Ltd. | Network connection configuration method and apparatus |
| CN109196893B (zh) * | 2016-07-06 | 2021-11-19 | 华为技术有限公司 | 一种网络连接配置方法及装置 |
| US11533730B2 (en) | 2016-07-06 | 2022-12-20 | Huawei Technologies Co., Ltd. | Network connection configuration method and apparatus |
| WO2018082559A1 (en) * | 2016-11-07 | 2018-05-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Service differentiation for devices connected to a ue as a router |
| RU2719421C1 (ru) * | 2016-11-07 | 2020-04-17 | Телефонактиеболагет Лм Эрикссон (Пабл) | Разграничение услуг для устройств, подключенных к ue, действующему в качестве маршрутизатора |
| US10873669B2 (en) | 2016-11-07 | 2020-12-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Service differentiation for devices connected to a UE as a router |
| CN109804660A (zh) * | 2018-02-06 | 2019-05-24 | Oppo广东移动通信有限公司 | 服务质量流重映射实现方法、装置、设备及存储介质 |
| CN109804660B (zh) * | 2018-02-06 | 2020-09-04 | Oppo广东移动通信有限公司 | 服务质量流重映射实现方法、装置、设备及存储介质 |
| WO2021139696A1 (zh) * | 2020-01-06 | 2021-07-15 | 华为技术有限公司 | 一种报告信息的发送方法、装置及系统 |
| CN114866530A (zh) * | 2022-03-28 | 2022-08-05 | 深圳优地科技有限公司 | 升级数据包的下载方法、设备以及计算机存储介质 |
| CN114866530B (zh) * | 2022-03-28 | 2024-04-19 | 深圳优地科技有限公司 | 升级数据包的下载方法、设备以及计算机存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103037449B (zh) | 2018-01-19 |
| WO2013064004A1 (zh) | 2013-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103037449A (zh) | 一种更新服务质量的方法及系统 | |
| KR101546220B1 (ko) | 다중-액세스 통신 시스템에서 사용자 장비에 의한 IP 트래픽의 라우팅을 위해 액세스 네트워크/액세스 기술 선택의 제어, 및 QoS 지원 | |
| CN103024824B (zh) | 一种策略与计费规则的服务质量更新方法及系统 | |
| CN102547640B (zh) | 一种消费限制业务的签约和执行方法及系统 | |
| JP6117802B2 (ja) | Ｍｍｅ／ｓ４−ｓｇｓｎとｐｃｒｆとの間の通信 | |
| CN101867909B (zh) | 一种实现有限策略计费控制的方法及系统 | |
| US8943165B2 (en) | Method for reselecting bearer binding and event report function | |
| EP2472918B1 (en) | Method, apparatus and system for transmitting a bearer control mode in roaming scenarios | |
| WO2013155942A1 (zh) | 策略和计费控制方法、v-pcrf及v-ocs | |
| CN106304195B (zh) | 第三方应用的策略控制方法、scef和pcrf | |
| JP2012509041A (ja) | 制限付きポリシー及び課金制御ケイパビリティの検出及び報告 | |
| CN101272534A (zh) | 一种隐藏拜访地网络拓扑结构的策略计费控制的方法 | |
| CN102316444A (zh) | 一种对用户设备进行服务质量控制的系统及方法 | |
| CN101720079A (zh) | 网元策略融合网络中的业务接入方法及策略融合系统 | |
| WO2014173340A1 (zh) | 一种网间签约授权的计费策略方法及装置 | |
| CN102238511B (zh) | 一种策略和计费规则功能实体的选择方法及系统 | |
| WO2011026385A1 (zh) | 一种本地疏导漫游场景在线计费的方法和系统 | |
| CN102547854B (zh) | 策略控制方法及装置 | |
| CN102111740B (zh) | 一种支持多接入的策略计费控制方法和系统 | |
| WO2012071956A1 (zh) | 漫游场景支持被赞助数据连接的方法、系统和装置 | |
| WO2012129992A1 (zh) | 被赞助数据连接的处理方法及策略与计费规则功能实体 | |
| CN102791042B (zh) | S9子会话建立方法、系统及pcrf | |
| CN103227981B (zh) | 一种应用检测控制功能模式的识别方法及系统 | |
| WO2013178183A1 (zh) | 服务质量的更新处理方法及装置 | |
| CN102761932A (zh) | 一种ip流迁移的策略控制方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20180119 Termination date: 20201010 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |