服务质量的更新处理方法及装置制造方法
【专利摘要】本发明提供了一种服务质量的更新处理方法及装置，其中，上述方法包括：UE获取应用提供商和运营商的协作关系；UE根据获取的协作关系请求服务质量QoS更新。采用本发明提供的上述技术方案，解决了相关技术中，对用户的多径信息进行管理耗费较多硬件内部缓存空间在第三方应用提供商和运营商不存在业务协作时，尚无使UE正确识别应用提供商和运营商的协作关系等技术问题，从而使得UE根据获取的应用提供商和运营商的协作关系对QOS进行正确处理（更新）。
【专利说明】服务质量的更新处理方法及装置
【技术领域】
[0001]本发明涉及通信领域,具体而言,涉及一种服务质量(Quality of Service,简称为QoS)的更新处理方法及装置。
【背景技术】
[0002]图1 为第三代合作伙伴计划(3rd Generation Partnership Project,简称为3GPP)演进分组系统结构示意图，如图1所示，3GPP演进分组系统(Evolved PacketSystem,简称为EPS)由演进的通用移动通信系统陆地无线接入网(Evolved UniversalTerrestrial Radio Access Network,简称为 E-UTRAN)、移动管理单兀(MobilityManagement Entity,简称为MME)、服务网关(Serving Gateway,简称为S-GW)、分组数据网络网关(Packet Data Network Gateway,简称为 F1DN GW 或 P-GW)、归属用户服务器(HomeSubscriber Server,简称为 HSS)、3GPP 的认证授权计费(Authentication、Authorizationand Accounting,简称为AAA)服务器、策略和计费规则功能实体(Policy and ChargingRules Function，简称为PCRF)及其它支撑节点组成。
[0003]其中，MME用于移动性管理、非接入层信令的处理和用户移动管理上下文的管理等控制面相关工作；S_GW是与E-UTRAN相连的接入网关设备，在E-UTRAN与P-GW之间转发数据，并且用于对寻呼等待数据进行缓存；P_GW则是EPS与PDN的边界网关，用于PDN的接入及在EPS与TON间转发数据等功能。
[0004]EPS支持与非3GPP系统的互通。与非3GPP系统的互通通过S2a、S2b、S2c接口实现，P-GW作为3GPP系统与非3GPP系统之间的锚点。其中，非3GPP系统被分为可信任非3GPP接入系统和不可信任非3GPP接入系统。可信任非3GPP接入系统可以直接通过S2a接口与P-GW连接；不可信任非3GPP接入系统需经过演进的分组数据网关(Evolved PacketData Gateway，简称为ePDG)与P-GW相连，ePDG与P-GW之间为S2b接口。S2c接口提供了用户设备(User Equipment，简称为UE)与P-GW之间用户面相关的控制和移动性支持，支持的移动性管理协议为支持双栈的移动IPv6(Moblie IPv6 support for dual stack Hostsand Routers,简称为 DSMIPv6)。
[0005]EPS系统引入策略计费控制(Policy and Charging Control,简称为PCC)功能框架对用户的业务访问进行动态的策略计费控制。图2为Rel-1l中非漫游场景下的PCC结构示意图，如图2所示,应用功能实体(Application Function,简称为AF)用于提供业务应用的接入点，这些业务应用所使用的网络资源需要进行动态的策略控制。在业务面进行参数协商时，AF将相关业务信息传递给PCRF。如果这些业务信息与PCRF的策略相一致，则PCRF接受该协商；否则，PCRF拒绝该协商，并在反馈时给出PCRF可接受的业务参数。随后，AF可将这些参数返回给用户设备(User Equipment，简称为UE)。其中，AF和PCRF之间的接口是Rx接口。
[0006]PCRF是PCC的核心，负责策略决策和计费规则的制定。PCRF提供了基于业务数据流的网络控制规则，这些网络控制包括业务数据流的检测、门控(Gating Control), QoS控制以及基于数据流的计费规则等。PCRF将其制定的策略和计费规则发送给策略和计费执行功能实体(Policy and Control Enforcement Function,简称为 PCEF)执行；同时，PCRF还需要保证这些规则和用户的签约信息一致。PCRF制定策略和计费规则的依据包括:从AF获取与业务相关的信息、从用户签约数据库(Subscription Profile Repository,简称为SPR)获取与用户策略计费控制相关的签约信息、通过Gx接口从PCEF获取的与承载相关网络的信息。
[0007]PCEF通常位于网关(Gate-Way，简称为GW)内，在承载面执行PCRF所制定的策略和计费规则。PCEF按照PCRF所发送的规则中的业务数据流过滤器对业务数据流进行检测，进而对这些业务数据流执行PCRF所制定的策略和计费规则。在承载建立时，PCEF按照PCRF发送的规则进行QoS授权，并根据AF的执行进行门控控制。同时，PCEF根据PCRF订阅的事件触发上报承载网络上发生的事件。根据PCRF发送的计费规则，PCEF执行相应的业务数据流计费操作，计费既可以是在线计费，也可以是离线计费。如果是在线计费，则PCEF需要和在线计费系统(Online Charging System,简称为0CS)—起进行信用管理。离线计费时，PCEF和离线计费系统(Offline Charging System，简称为0FCS)之间交换相关的计费信息。PCEF与PCRF之间的接口是Gx接口，与OCS之间的接口是Gy接口，与OFCS之间的接口是Gz接口。PCEF —般都位于网络的网关上，如EPS的分组数据网络网关(PDN-Gff ),通用无线分组业务(General Packet Radio Service,简称为GPRS)中的网关通用分组无线业务支持节点(Gateway General Packet Radio Service Supporting Node,简称为 GGSN)以及互联无线网局域网(Interworking WLAN,简称为1-WLAN)中的分组数据网关(Packet DataGateway,简称为 F1DGX
[0008]承载绑定和事件报告功能实体(Bearer Binding and Event ReportingFunction,简称为BBERF)通常位于接入网网关(Access Network Gateway,简称为ANG)内。如当用户设备通过E-UTRAN接入EPS、服务网关S-GW与P-GW之间采用代理移动互联网协议版本 6 (Proxy Mobile Internet Protocol version 6,简称为 PMIPv6)协议时，S-GW 中就存在BBERF。当用户设备通过可信任非3GPP接入网接入时，可信任非3GPP接入网关中也存在 BBERF。
[0009]SPR存储了与策略控制和计费相关的用户策略计费控制签约信息。SPR和PCRF之间的接口是Sp接口。
[0010]在线计费系统(Online Charging System,简称为0CS)和PCEF—起进行在线计费方式下用户信用的控制和管理。
[0011]离线计费系统(Offline Charging System,简称为0FCS)与PCEF —起完成离线计费方式下的计费操作。
[0012]OCS和PCRF之间的接口是Sy接口，该接口上的计费策略会话用于传送计费相关信息。PCRF从OCS获取计费相关信息，作为制定PCC/QoS规则的依据信息之一。OCS检测到授权配额(例如用量阈值)到达后，可向PCRF发起计费策略报告，触发PCRF发起会话修改流程，更新相关规则。
[0013]以上PCC架构通过各功能实体实现了对UE为访问一个分组数据网络(PacketData Network,简称为 PDN)所建立的 IP连接接入网(IP Connectivity Access Network,简称为IP-CAN)会话的策略计费控制。一个IP-CAN会话的策略计费控制信息只由一个PCRF决定。
[0014]移动运营商使用EPS系统和第三方数据应用提供商的交互(Interworkingbetween Mobile Operators using the Evolved Packet System and Data ApplicationProviders,简称MOSAP)的功能框架引入了基于通用引导架构(Generic BootstrappingArchitecture，简称为GBA^POpen ID的安全机制，除了图2中的PCC架构，引入了 GBA作为移动运营商对第三方应用提供商的鉴权和认证，来为UE提供相关应用业务。图3为R12中非漫游场景下的第三方拥有数据应用提供商的结构示意图。如图3所示，Non-1MS AS为第三方应用服务器，类似于AF，可和PCRF交互提供相应的业务QoS信息，和HSS交互获取相关的用户签约信息。GBA(包括 Bootstrapping Server Function-BSF,Network ApplicationFunction-NAF和SLF)旨在描述在移动的上下文环境中使用基于3GPP的AKA机制为客户端(UE)和应用服务器(non-MSAS)提供共享密钥，随后该共享秘密能用于认证客户(UE)和应用程序服务器(non-MSAS)之间的通信。这里GBA用于支持UE和RP之间的安全通信。引导服务功能(Bootstrapping Server Function,简称为BSF)为运用商的网内的功能实体，GBA所有的用户安全设置(⑶SS)都存储在HSS中，BSF通过与HSS之间的接口(Zh)获得用户安全信息和认证信息。UE和BSF之间通过认证机制在BSF和UE之间产生一个会话密钥(Ks),网络应用功能(Net Application Function,简称为NAF)负责业务控制，能从BSF获得该会话密钥，通过这种方式，NAF和UE就能拥有一个共享密钥，该共享密钥能为随后的应用提供安全保护，特别是在应用会话开始时认证UE和NAF。因此运营商可以完成相关鉴权和认证，为签约用户提供第三方应用业务。
[0015]Open ID是实现全网统一 认证的解决方案:当终端用户UE登录一个支持Open ID的网站，即依赖方(Relying Party，简称为RP)时，与在该网站进行用户登录方式不同(该终端用户也许没有在该网站注册过)，该用户选择了以Open ID的方式登录该网站。Open ID是该用户在另一个网站，即帐号提供方(OpenID Provider，简称为0P)，注册的一个统一资源定位符(Uniform Resource Locator,简称为URL)。RP就会根据用户提供的Open ID去发现0P，然后请求该OP对该用户身份进行鉴权。OP收到RP请求后，会要求用户登录OP认证页面进行鉴权，鉴权后，OP会提醒该用户是否容许外部网站对其鉴权。用户同意后，OP将鉴权结果返回给依赖方RP ;这里的OP鉴权采用了 GBA的引导模式，OP等效于GBA架构中的NAF。
[0016]现有技术中，UE建立到某个I3DN的IP-CAN会话后，网络按相应授权的QoS为其业务提供数据传输需要的网络资源，业务过程中可根据需要更改其QoS。对于MS类业务，则AF将提供新的QoS信息给PCRF，PCRF发起IP-CAN会话的修改流程。PCRF结合AF新请求的QoS以及SPR/UDC相应签约数据，底层网络承载资源信息等重新授权并下发新的PCC/QoS规则给PCEF/BBERF，PCEF/BBERF更新相应规则并修改承载资源，为该业务提供新的QoS。对于非MS类业务(例如图3中的non-MS AS提供的业务)，运营商可以根据自身需求来部署网络，自定义非MS类业务平台和数据中心，通过自定义接口来触发其PCRF发起IP-CANsession修改流程来更改QoS。若该类业务不是运营商自有的业务平台提供，则运营商可以和该类业务提供商签订私有协议，来通过自定义接口触发其PCRF发起IP-CANsession修改流程来更改QoS。
[0017]目前网络第三方应用提供商的数量和种类越来越多，运营商自有业务已经远远不能满足用户的业务需求，运营商和部分应用业务提供商之间建立合作关系(该场景下non-1MS AS和PCRF之间存在Rx接口)，为用户的应用业务提供良好的服务质量和应用体验，从中收取其应有的提供网络传输资源的应得利润。但运营商不可能做到和所有应用提供商具备商业协作关系(该场景下non-MS AS和PCRF之间没有Rx接口)。对于和运营商不具有协作关系的第三方应用提供商的业务(non-MS AS和PCRF之间没有Rx接口)，运营商提供默认的QoS，但用户可发起请求通过支付额外的费用来获取该业务的高QoS。
[0018]这种和运营商不具有协作关系的第三方应用提供商分为两类,第一类和运营商没有任何商业关系也没有任何业务协作，第二类和运营商有商业关系但没有任何业务协作。针对第一类第三方应用提供商，用户只能向运营商发起提升该业务的QoS请求，由运营商触发修改该业务的相关承载资源以满足用户的需求，并承担该高QoS的额外计费。针对第二类的第三方应用提供商，用户可向第三方应用提供商发起提升该业务的QoS请求，由第三方应用提供商触发运营商修改该业务的相关承载资源以满足用户的需求，并由第三方应用提供商提供该高QoS额外计费的话单，也可以像第一类一样直接和运营商发起提升请求。
[0019]相关技术中，对于第一类和运营商没有任何商业关系也没有任何业务协作的场景，当UE需要提升QoS时，UE可以通过承载资源修改流程通知GW，触发PCRF发起IP-CAN会话修改，对该业务的QoS重授权；也可以由UE直接通知运营商的AF相关的业务和QoS提升请求，触发PCRF发起上述流程。对于第二类和运营商有商业关系但没有任何业务协作的场景，UE可以通知DAP提升请求，由DAP和运营商的PCRF交互，触发上述流程；也可以由UE直接和运营商触发提升QoS，包括上述的承载资源修改流程触发或AF触发。但实际运营网络中会同时存在以上两类场景，UE需要根据不同场景作出相应的处理。
[0020]因此，UE如何正确区分这两类场景并根据需求作出正确的选择，成为必须解决的关键问题。
[0021]归纳以上问题可以看出，针对网络中存在第三方应用提供商提供的业务，且第三方应用提供商和运营商不存在业务协作时，如何使UE能够根据运营商或UE对于相关业务的QoS处理的需求做出正确处理，是需要解决的问题。
[0022]针对相关技术中的上述问题，目前尚未提出有效的解决方案。
【发明内容】
[0023]针对相关技术中，在第三方应用提供商和运营商不存在业务协作时，尚无使UE正确识别应用提供商和运营商的协作关系等技术问题，本发明提供了一种服务质量的更新处理方法及装置，以至少解决上述问题。
[0024]根据本发明的一个方面，提供了一种服务质量的更新处理方法，包括:用户设备(UE)获取应用提供商和运营商的协作关系;UE根据获取的协作关系请求服务质量QoS更新。
[0025]上述协作关系，包括以下之一:应用提供商和运营商存在业务协作；应用提供商和运营商不存在业务协作和商业关系；应用提供商和运营商仅存在商业关系但无业务协作。
[0026]UE根据获取的协作关系请求QoS更新，包括:在应用提供商和运营商不存在业务协作和商业关系时，UE直接向运营商发起请求,请求运营商对QoS进行更新处理。
[0027]UE根据获取的协作关系请求QoS更新，包括:在应用提供商和运营商仅存在商业关系但无业务协作时，UE根据协作关系采用以下方式之一发起对QoS的更新流程-M直接向运营商发起请求，触发运营商进行对QoS进行更新处理；UE经由应用提供商发起请求触发运营商对QoS进行更新处理。
[0028]UE获取应用提供商和运营商的协作关系，包括:UE接收来自于应用提供商发送的协作关系；或者UE接收来自于运营商发送的协作关系。
[0029]UE接收来自于运营商发送的协作关系，包括:UE从运营商的应用功能AF实体发送的应用层信令或协议中获取协作关系；或者UE从运营商的承载层信令中获取协作关系。
[0030]根据本发明的另一个方面，提供了一种服务质量的更新处理装置，位于UE中，该装置包括:获取模块，用于获取应用提供商和运营商的协作关系；请求模块，用于根据获取的协作关系请求服务质量QoS更新。
[0031]上述获取模块用于获取以下之一协作关系:应用提供商和运营商存在业务协作；应用提供商和运营商不存在业务协作和商业关系；应用提供商和运营商仅存在商业关系但无业务协作。
[0032]上述请求模块，用于在应用提供商和运营商不存在业务协作和商业关系时，直接向运营商发起请求，请求运营商进行对QoS进行更新处理。
[0033]上述请求模块，用于在应用提供商和运营商仅存在商业关系但无业务协作时，根据协作关系采用以下方式之一发起对QoS的更新流程:直接向运营商发起请求，触发运营商对QoS进行更新处理；经由应用提供商发起请求触发运营商对QoS进行更新处理。
[0034]上述获取模块，用于接收来自于应用提供商发送的协作关系；或者接收来自于运营商发送的协作关系。
[0035]通过本发明，采用UE获取应用提供商和运营商的协作关系的技术手段，解决了相关技术中，对用户的多径信息进行管理耗费较多硬件内部缓存空间在第三方应用提供商和运营商不存在业务协作时，尚无使UE正确识别应用提供商和运营商的协作关系等技术问题，从而使得UE根据获取的应用提供商和运营商的协作关系对QOS进行正确处理(更新)。
【专利附图】
【附图说明】
[0036]此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中:
[0037]图1为根据相关技术的3GPP演进分组系统结构示意图；
[0038]图2为根据相关技术的Rel-1l非漫游场景下的PCC结构示意图；
[0039]图3为根据相关技术的Rel-12非漫游场景下的MOSAP结构示意图；
[0040]图4为根据本发明实施例1的服务质量的更新处理方法的流程图；
[0041]图5为根据本发明实施例1的服务质量的更新处理装置的结构框图；
[0042]图6为根据本发明实施例2的服务质量的更新方法的第一流程图；
[0043]图7为本发明实施例2的服务质量的更新方法的第二流程图；
[0044]图8为本发明实施例2服务质量的更新方法的第三流程图；
[0045]图9为根据本发明实施例3的服务质量的更新方法的第一流程图；[0046]图10为本发明实施例3的服务质量的更新方法的第二流程图；
[0047]图11为本发明实施例3服务质量的更新方法的第三流程图。
【具体实施方式】
[0048]下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
[0049]考虑到相关技术中，应用提供商和运营商在不具有协作关系的两种场景(即第一类和运营商没有任何商业关系也没有任何业务协作,第二类和运营商有商业关系但没有任何业务协作)下，尚无使UE如何正确区分这两类场景并根据需求作出正确的选择等问题。以下结合实施例提供了相关的解决方案，现详细说明。
[0050]实施例1
[0051]图4为根据本发明实施例1的服务质量的更新处理方法的流程图。如图4所示，该方法包括:
[0052]步骤S402，UE获取应用提供商和运营商的协作关系；
[0053]步骤S404，UE根据获取的协作关系请求QoS更新。
[0054]无论对于运营商和应用提供商是否存在业务协作，均可以通过上述处理步骤使UE感知运营商和应用提供商的协作关系，尤其是在运营商和应用提供商不存在业务协作的情况下，可以使UE对两者的具体协作情况进行感知，从而UE如何正确区分这两类场景并根据需求作出正确的选择，例如，对于相关技术中的第一类场景只能由运营商触发QoS提升，对于相关技术中的第二类场景可以根据运营商策略或用户的倾向，作出相应的触发选择。
[0055]在步骤S404，对QoS进行更新处理的实现过程由于可以在相关技术中查询得知，此处不再赘述。
[0056]上述协作关系可以包括以下情况之一:应用提供商和运营商存在业务协作；应用提供商和运营商不存在业务协作和商业关系；应用提供商和运营商仅存在商业关系但无业务协作。
[0057]针对上述协作关系的几种情况，步骤S404更新处理过程也略有不同:在应用提供商和运营商不存在业务协作和商业关系时，UE直接向运营商发起请求,请求运营商进行对QoS进行更新处理。在应用提供商和运营商仅存在商业关系但无业务协作时，UE根据协作关系按照采用以下方式之一发起对QoS的更新流程:第一种方式，UE直接向运营商发起请求，触发运营商进行对QoS进行更新处理；第二种方式，UE经由应用提供商发起请求触发运营商对QoS进行更新处理。
[0058]其中，对于应用提供商和运营商存在业务协作的情况，则可以采用第一种方式或第二种方式对QoS更新处理。
[0059]可以根据预定策略选择采用哪种处理方式:运营商默认第一种方式或第二种方式；设置第一种方式和第二种方式的优先级；响应于用户的选择操作，从预先配置的所述第一种方式和所述第二种方式中选择一种方式；根据QoS的资费归属方不同确定选择所述第一种方式或所述第二种方式，例如可结合该业务的计费策略来决定，例如特殊QoS的资费归属应用提供商话单则选择第二种方式，特殊QOS的资费归属运营商话单则选择第一种方式。[0060]UE获取应用提供商和运营商的协作关系的方式有多种，例如:可以通过UE接收来自于应用提供商发送的协作关系；或者通过UE接收来自于运营商发送的协作关系获取。
[0061]对于UE通过接收来自于运营商发送的协作关系的获取方式，可以采用以下处理过程实现:UE从运营商的应用功能AF实体发送的应用层信令或协议中获取协作关系；或者UE从运营商的承载层信令中获取协作关系。上述处理过程的具体实现方式可以参见实施例2和实施例3的描述，此处不再赘述。
[0062]在本实施例中还提供了一种服务质量的更新处理装置，该装置位于UE中，用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述，下面对该装置中涉及到的模块进行说明。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图5为根据本发明实施例1的服务质量的更新处理装置的结构框图。如图5所示，该装置包括:
[0063]获取模块50，连接至请求模块52，用于获取应用提供商和运营商的协作关系；
[0064]请求模块52，根据获取的协作关系请求QoS更新。
[0065]通过上述处理模块所实现的功能，同样可以使UE感知运营商和应用提供商的协作关系，尤其是在运营商和应用提供商不存在业务协作的情况下，可以使UE对两者的具体协作情况进行感知，从而UE如何正确区分这两类场景并根据需求作出正确的选择，例如，对于相关技术中的第一类场景只能由运营商触发QoS提升，对于相关技术中的第二类场景可以根据运营商策略或用户的倾向，作出相应的触发选择。
[0066]优选地，上述获取模块50用于获取以下之一协作关系:应用提供商和运营商存在业务协作；应用提供商和运营商不存在业务协作和商业关系；应用提供商和运营商仅存在商业关系但无业务协作。
[0067]上述请求模块52，用于在应用提供商和运营商不存在业务协作和商业关系时，直接向运营商发起请求，触发运营商进行对QoS进行更新处理。
[0068]在本实施例中，请求模块52，还用于在应用提供商和运营商仅存在商业关系但无业务协作时，根据协作关系采用以下方式之一发起对QoS的更新流程:直接向运营商发起请求，请求运营商进行对QoS进行更新处理；经由应用提供商发起请求触发运营商对QoS进行更新处理。
[0069]在本实施例中，获取模块50，用于接收来自于应用提供商发送的协作关系；或者接收来自于运营商发送的协作关系。
[0070]为了更好地理解实施例1，以下结合实施例2和实施例3详细说明，以下所述实施例涉及EPS中UE感知协作关系更新QoS的方案，目的在于，UE对于运营商和第三方业务提供商的协作关系的感知和判断，以及根据需求正确触发业务QoS提升，以下实施例的主要设计思想在于，UE感知应用提供商和运营商的协作关系，并根据运营商策略或用户的选择来触发优先流处理(即QoS提升)。其中，UE可以通过第三方数据应用提供商(Dataapplication provider,简称为DAP)感知应用提供商和运营商的协作关系,还可以通过移动运营商感知应用提供商和运营商的协作关系。对于后一种情况，即UE通过移动运营商感知包括:通过运营商应用功能的应用层信令应用提供商和运营商的协作关系；通过运营商的承载层信令感知提供商和运营商的协作关系。所述运营商策略或用户的选择包括:1)UE向移动运营商发起请求，运营商进行优先流处理；2)UE向第三方应用提供商发起请求,第三方应用提供商请求运营商进行优先流处理。
[0071]实施例2
[0072]本实施例基于图3的MOSAP架构基础上提供一种UE通过第三方应用提供商DAP感知应用提供商和运营商的协作关系，并根据运营商策略或用户的选择来触发QoS提升的方法和系统，来实现用户根据其需求触发的优先流处理。
[0073]本实施例描述的UE使用和运营商不具有协作关系的第三方应用提供商的业务，该第三方应用提供商和运营商没有任何商业关系也没有任何业务协作。运营商负责为UE的第三方应用提供传输资源，UE向运营商发起优先流处理请求，由运营商处理相关QoS的更新。
[0074]IP-CAN会话创建后，第三方应用提供商根据其协作运营商的签约信息、UE ID和PLMNID等信息判断其与UE归属运营商的协作关系，并将其告知UE相应的API。UE接收并存储该第三方应用提供商发送的其与运营商的该协作关系。当用户不满意当前业务的QoS，发起优先流处理请求时，UE根据当前的DAP与移动运营商(Mobile Operators,简称为MO)的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为当DAP和MO既无商业关系也无业务协作时直接由UE请求MO发起优先流处理请求。根据运营商网络部署,UE可通过承载资源修改流程发起该QoS更新，也可以通过运营商自有的AF触发PCRF发起该QoS更新。
[0075](一)
[0076]在图6所示流程中，网络部署中运营商自有AF功能(可以为新增逻辑功能，可以独立部署，或集成在其它网元中。可以为运营商自有应用平台，也可以是和NAF或OP结合的具备AF功能的proxy网元，也可以集成在现有网元中，例如PCRF中)，支持UE和AF的接口(可以采用http协议或者其它应用层信令)，若AF在PCRF之外，则支持AF和PCRF的接口(这里为Rx接口，可采用Diameter协议通信)。如图6所示,该流程包括:
[0077]步骤S601:UE附着到归属地网络，建立无线承载和创建IP-CAN session ；
[0078]步骤S602:UE登陆并成功访问Non-MS AS,这里UE和Non-MS AS使用application level signaling 或 HTTP 协议，non-1MS AS 为 UE 提供应用业务；Non-1MS AS一并向运 UE 提供 Service ID/application ID,以及 flow information 相关信息；
[0079]步骤S603:完成该业务所需承载的创建；PCRF根据AS，SPR/UDC，PGff等client端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF;PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关event trigger,以及用量监控阈值,监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；
[0080]步骤S604:该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输;
[0081]步骤S605:non-1MS AS根据其协作运营商的签约信息，UE ID和PLMN ID等信息，判断断其与UE归属运营商或的协作关系，并将该协作关系通知给UE。UE接收并存储该non-MSAS发送的其与运营商的该协作关系。该交互信令可以为应用层信令或http等应用协议。该协作指示告知UE该应用提供商的该项业务与运营商的协作关系，例如协作、非协作(包括具备商业关系但无业务协作，既无商业关系也无业务协作这两种场景)关系。本发明旨在告知UE其双反的协作关系，其告知形式不限于以上所述方式。该协作关系通知可以为单独的信令或消息，也可以包含在UE和AS的其它信令或消息中传送，例如步骤S601。该协作关系的指示，可在non-1MS AS获取后的任何时候通知,不限于步骤S604之后；
[0082]步骤S606:业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE发起优先流处理请求。UE根据当前的应用提供商与运营商的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为:当两者既无商业关系业务协作时，直接由UE请求运营商发起优先流处理请求。根据运营商网络部署，UE可通过承载资源修改流程发起该QoS更新，也可以通过运营商自有的AF触发PCRF发起该QoS更新。这里UE通过运营商自有的AF触发。
[0083]UE发送请求消息给AF (部署中可以为类似NAF或non-MS AS或RP等应用平台或集成在现有网元中)；UE的该请求消息中携带UEIP/ID,优先流处理指示/QoS,及flowinformation,以及如果有可能还会携带Service ID/Application ID;(这里UE和AF的通信协议不作限定，http或应用层信令均可实现)；
[0084]具体实现中，除了以上显式地通知UE外，还可存在例如当两者不存在商业关系也不存在业务协作时不会发送任何指示给UE，而UE默认无通知为非协作关系等实现方式。本发明旨在UE能正确判断网络或应用提供商两者的协作关系，对于感知方式的具体实现不做限定，下同。
[0085]步骤S607:AF收到UE的请求消息后，关联UE Id/IP和所需提升QoS的service/application,发送CCR请求消息给PCRF,请求发起会话修改update QoS ;这里AF作为PCRF的diameter client端,可独立或集成于其它网元实体中部署。请求消息中携带UE ID/IP,优先流处理指不/QoS,及 flow information,以及可能还有 service ID/application ID;
[0086]步骤S608 =PCRF收到该AF的请求消息后，查询SPR/UDC该用户/业务/应用是否签约了高优先流处理，若签约允许则根据请求发起会话修改流程；制定下发更新后的PCC规则给 PCEF/BBERF，orADC 规则给 TDF。PCEF/BBERF/TDF 更新 PCC/QoS/ADC 规则，修改或新建承载，执行update后的QoS和相关承载的绑定。并发送响应消息给PCRF，反馈规则执行结果;
[0087]PCRF返回提升QoS修改响应消息CCA给该AF，告知修改是否被接受，如果被拒绝，携带相关cause ；
[0088]步骤S609:若update QoS授权成功，则AF给UE发送更新QoS确认请求消息，要求用户确认是否满意更新后的QoS，如果满意则在预览时间段内返回肯定的确认消息(确认接受更新后的QoS后，用户需要为此优先流处理提供额外资费)；如果不满意或不同意支付额外的优先流处理费用，则返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，AF上也可设置timer某人拒绝或接受流程的除服。但具体处理根据运营商网络实现处理);该处理流程，AF可在发送请求St印S607中设置QoS提升定时器Timerl，在收到PCRF的CCA确认消息且Timerl Time out之后(Timerl有效期应能保证正常的PCRF发起的IP-CANsession modification更新QoS处理完毕且已经按新的QoS为UE提供应用业务)，AF则向UE发送确认请求消息。发送该请求消息后AF可开启用户确认定时器Timer2。[0089]步骤S610:UE收到该AF的确认消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对该消息进行确认，UE将会发送给确认消息给该AF。该AF收到UE的确认响应后,可选地返回确认response消息给PCRF,运营商将对该业务继续提供update之后的QoS (例如，继续进行优先流处理，提供高优先级或高带宽资源)。PCRF将发起IP-CAN会话修改流程(同StepS608),下发新的Charigng key (对该QoS下的业务执行相应的优先流特殊计费)。
[0090]若UE对提升后的业务数据流的服务质量或用户体验不满意和或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回响应消息)或返回否定确认消息给此AF (即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给AF),执行stepS610a_c ；
[0091]步骤S610a:若AF在规定时间内(例如timer2 timeout)没有收到用户的确认接收消息，或收到了用户的确认拒绝消息，则AF将发送更新QoS请求(例如，downgrade QoS)给 PCRF ；
[0092]步骤S610b:PCRF收到AF的downgrade QoS请求消息后，结合签约信息及本地策略(例如用户确认接收UpdateQoS的Preview timer超时则需要回复原先QoS),发起IP-CAN/Gffcontrol/TDF会话修改流程，更新相关PCC/QoS/ADC规则，恢复该业务的原先QoS ；
[0093]步骤S610c:在QoS恢复处理完成后或提升QoS确认时间超时后，网络对该业务数据流的处理将恢复到UE请求提升之前的QoS (QoS回退机制不在本发明的限定范围内，可采用例如网元间的timer机制处理会话修改的回退时间，可本地存储update之前的QoS,或者Trigger node发送downgrade QoS请求消息时携带此前的QoS信息,或者请求消息中携带使用默认QoS指示等)。
[0094]以上流程中除了策略控制，还存在计费相关处理流程，例如更新QoS后，新的PCC规则中可能下发新的计费关键字(对应新的计费费率)，可能存在PCRF、PCEF/BBERF/TDF等网元与计费网元0CS/0FCS以及其它计费系统的交互；该部分处理由于可以在相关技术中查询得知，在此不再赘述。
[0095]经过图6所示流程，可实现当运营商和应用提供商既无商业关系也无业务协作时，UE通过运营商感知其协作关系,直接请求运营商发起优先流处理请求,通过运营商自有的AF触发PCRF发起该QoS更新，提升或降低服务质量/用户体验，变更运营商为该业务传送的资源所对应的业务资费费率的处理流程。
[0096]( 二 )
[0097]对于该场景UE请求QoS更新，根据运营商网络部署，UE还可以通过重用承载资源修改流程完成该QoS的更新。图6所示流程中，UE通过第三方应用提供商感知协作关系，第三方应用提供商与移动运营商不具有商业关系也没有业务协作，并且UE通过移动网络运营商(Mobile network operator,简称为MNO)来发起QoS更新(QoSupdate)流程,通过承载资源修改流程，触发” PCEF发起的会话修改流程”，更新Q0S。
[0098]如图7所示，该流程包括:
[0099]步骤S701:如图5中的步骤S501-S504，UE附着到网络建立相关承载和会话，向Non-1MSAS请求了该业务，并创建完成相关的业务承载，网络按授权QoS为UE提供该业务数据的下行传输；
[0100]步骤S702:non-1MS AS根据其协作运营商的签约信息，UE ID和PLMN ID等信息，判断断其与UE归属运营商或的协作关系，并将该协作关系通知给UE。UE接收并存储该non-MSAS发送的其与运营商的该协作关系。该交互信令可以为应用层信令或http等应用协议。该协作指示告知UE该应用提供商的该项业务与运营商的协作关系，例如协作、非协作(包括具备商业关系但无业务协作，既无商业关系也无业务协作这两种场景)关系。本发明旨在告知UE其双反的协作关系，其告知形式不限于以上所述方式。该协作关系通知可以为单独的信令或消息，也可以包含在UE和AS的其它信令或消息中传送。该协作关系的指示，可在non-MSAS获取后的任何时候通知，不限于步骤S701结束之后；
[0101]步骤S703:业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE发起优先流处理请求。UE根据当前的应用提供商与运营商的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为:当两者既无商业关系业务协作时，直接由UE请求运营商发起优先流处理请求。根据运营商网络部署，UE可通过承载资源修改流程发起该QoS更新，也可以通过运营商自有的AF触发PCRF发起该QoS更新。这里UE通过承载资源修改流程发起该QoS更新。
[0102]UE发送Request消息给MME,请求消息中携带请求的类型(更新QoS), UEIP/ID,承载ID (LBI)，flow information (例如流描述(TAD)，数据包过滤器ID (PTI)等)，QoS。若该业务/应用此前为GBR承载,则请求中可能携带packet filter identifier (s);以及如果有可能还会携带 Service ID/Application ID;
[0103]步骤S704:MME前转发送request消息给SGW，消息中包括S703中的相关参数；
[0104]步骤S705 =SGff收到该消息后前转该request消息给PGW，消息携带收到的具体参数；
[0105]步骤S706:PCEF根据收到的request消息参数,判断需要更新QoS (例如根据携带了优先流处理或承载指示，或QoS更新指示,或该业务请求的QoS高于先的QoS等)，发起IP-CANsession modification流程处理,发送会话修改请求给PCRF触发会话修改,如步骤309。消息中携带 UE IP/ID,请求的 QoS, flow information (例如 TAD,以及 SDF fileterID)等参数。
[0106]PCRF查询SPR/UDC签约信息(例如该用户/业务/应用是否签约了高优先流处理；若签约允许则根据请求提升QoS)，更新PCC策略决策，下发更新后的PCC规则给PCEF/BBERF, or ADC规则给TDF/PCEF (如果存在应用流检测功能)。这里若PCRF本地没有签约信息，则PCRF还需要向SPR/UDC/HSS等数据库获取相关签约信息。PCEF/BBERF更新PCC/QoS规则，修改或新建承载满足提升后的QoS。并反馈规则执行响应消息给PCRF，完成会话修改流程。
[0107]PGW执行QoS策略，完成承载修改和绑定，下发Update Bearer Request给SGW,SGff前传到MME ；MME构建承载修改请求消息下发给eNodeB,带上Bear ID, QoS; eNodeB映射EPS承载QoS到无线承载QoS下发RRL CR消息给UE’ UE更新存储相关QoS ;逐级返回相关response消息直至给PGW，完成承载修改流程。这里具体涉及每个网元的消息及其参数等内容的详细流程可参照3GPP TS 23.S701中的UE发起的承载资源修改描述。
[0108]步骤S707:若update QoS成功，贝U需要发送更新QoS确认请求消息给UE,要求用户确认是否满意更新后的QoS，如果满意则UE返回肯定的确认消息(确认接受更新后的QoS需要为此优先流处理提供额外资费)；如果不满意或不同意支付额外的优先流处理费用，则UE给网络返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，但具体处理根据运营商网络实现处理)；
[0109]或者可以不由UE本身触发感知，而由网络侧下发通知。在完成IP-CAN sessionmodification流程后，按更新后的QoS为该业务提供业务数据流；PGW/PCEF下发一个通知消息给UE，要求UE对更新后的QoS进行确认，该通知消息中携带确认指示，表示用户请求的QoS更新完成，请求确认；SGW收到该通知消息后，下发该通知给MME，带上UEID/IP，必要的业务流信息，以及该确认指示；MME将该消息下发给UE，UE收到该通知消息后将提供一个通知指示给上层(例如应用层)，触发用户感知；
[0110]步骤S708:用户收到UE应用层的确认消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对在预览时间段内对该消息进行确认，UE将会发送给肯定的确认消息给该网络(在请求或通知相应中携带肯定的确认信息)，运营商将根据该确认对该业务继续提供update之后的QoS (例如，继续进行优先流处理，提供高优先级或高带宽资源)。PCRF将发起IP-CAN会话修改流程(同St印309)，下发新的Charigng key(对该QoS下的业务执行相应的优先流特殊计费)。
[0111]若UE对提升后的业务数据流的服务质量或用户体验不满意和或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回确认响应消息)或返回否定确认消息给网络(即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给网络，若User不确认则应用层则需要在等待确认的timer timeout之后触发承载层构建否定确认消息发送给网络，网络将会在一定preview时间之后将QoS恢复到请求提升之前的水平；
[0112]步骤S709 =MME收到UE的请求或通知相应消息，给SGW前转该消息，携带原消息中的参数，例如UE IP/ID，QoS,肯定或否定的确认信息/指示等；
[0113]步骤S710 =SGff前传该消息到PGW，携带QoS和确认信息/指示等参数；
[0114]步骤S711:PGW根据确认信息/指示判断用户业务所需的QoS，若为肯定确认，则执行步骤S712。
[0115]若为否定确认则发送IP-CANsession modification请求给PCRF发起会话修改流程，downgrade QoS ；PCRF收到downgrade QoS请求消息后，结合签约信息及本地策略(例如用户确认接收UpdateQoS的Preview timer超时则需要回复原先QoS),发起IP-CAN/Gffcontrol/TDF会话修改流程，更新相关PCC/QoS/ADC规则，恢复该业务的原先QoS ;该IP-CAN session修改流程修改承载和会话，为该业务提供的QoS将恢复到用户提升请求之前的水平，按原有的QoS继续执行StepS7115提供下行业务数据流；(QoS回退机制不在本发明的限定范围内，可采用例如网元间的timer机制处理会话修改的回退时间，可本地存储update之前的QoS,或者UE发送downgrade QoS请求消息时携带此前的QoS信息,或者请求消息中携带使用默认QoS指示等)。
[0116]步骤S712-S714:如步骤S708 PCRF发起的IP-CAN会话修改流程下发新的Charigng key (对该QoS下的业务执行相应的优先流特殊计费),提升或恢复QoS流程处理完毕。PGW确认UE用于发送确认通知发起的资源修改流程不需要执行(即QoS不需要变更)，则发送承载资源修改失败指示来指示SGW，高QoS将继续应用于该业务，不需要重新发起QoS修改流程，执行步骤S712-S714反馈该承载资源修改失败指示。
[0117]步骤S715:若为步骤S711则在downgrade QoS完成后，按最初的QoS传送下行数据；若为update QoS成功确认步骤S714，则按提升后的QoS传送下行数据。S卩，网络按授权的QoS为该业务继续提供业务数据流。
[0118]经过上述流程，可实现当运营商和应用提供商既无商业关系也无业务协作时，UE直接请求运营商发起优先流处理请求，通过承载资源修改流程触发PCRF发起IP-CAN会话修改，更新该业务的QoS，提升或降低服务质量/用户体验，变更运营商为该业务传送的资源所对应的业务资费费率的处理流程。
[0119](三)
[0120]本实施例基于图3的MOSAP架构基础上提供一种UE通过第三方应用提供商DAP感知应用提供商和运营商的协作关系，并根据运营商策略或用户的选择来触发QoS提升的方法和系统，来实现用户根据其需求触发的优先流处理。
[0121]本实施例描述的UE使用和运营商不具有协作关系的第三方应用提供商的业务，该第三方应用提供商和运营商具有商业关系但没有任何业务协作。运营商负责为UE的第三方应用提供传输资源，UE向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求,触发运营商修改会话更新Q0S。
[0122]IP-CAN会话创建后，第三方应用提供商根据其协作运营商的签约信息、UE ID和PLMNID等信息判断其与UE归属运营商的协作关系，并将其告知UE相应的API。UE接收并存储该第三方应用提供商发送的其与运营商的该协作关系。当用户不满意当前业务的QoS，发起优先流处理请求时，UE根据当前的DAP与MO的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为当DAP和MO存在商业关系但无业务协作时，由UE向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求,触发运营商修改会话更新QOS。
[0123]在图8所示流程中，UE通过第三方应用提供商感知协作关系，第三方应用提供商和移动运营商之间具有商业关系但没有业务协作，并且，UE通过运营商MNO来发起QoS更新(QoSupdate)，non-MS AS通知PCRF，触发”PCEF发起的会话修改流程”，更新Q0S。该网络部署中运营商和第三方业务提供商具有Rx接口，可传送相关业务信息。但运营商不会替第三方业务提供商向用户进行第三方业务的资费统计和计算。如图8所示，该流程包括:
[0124]步骤S801:UE附着到归属地网络，建立无线承载和创建IP-CAN session ；
[0125]步骤S802:UE登陆并成功访问Non-MS AS,这里UE和Non-MS AS使用application level signaling 或 HTTP 协议，non-1MS AS 为 UE 提供应用业务；
[0126]步骤S803:Non_IMS AS 向运营商的PCRF提供UE ID/IP, Service ID/applicationID,以及flow information相关信息，发起Rx会话建立请求。PCRF向SPR/UDC获取UE签约信息和签约AS信息，制定并下发PCC rule给PCEF，建立相关数据承载。由于该AS与运营商只有商业关系没有业务合作，授权QoS为default bearer QoS ；
[0127]步骤S804:完成该业务所需承载的创建；PCRF根据AS，SPR/UDC，PGff等client端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF;PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关event trigger,以及用量监控阈值,监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；
[0128]步骤S805:该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输;
[0129]步骤S806:non-1MS AS根据其协作运营商的签约信息，UE ID和PLMN ID等信息，判断断其与UE归属运营商或的协作关系，并将该协作关系通知给UE。UE接收并存储该non-MSAS发送的其与运营商的该协作关系。该交互信令可以为应用层信令或http等应用协议。该协作指示告知UE该应用提供商的该项业务与运营商的协作关系，例如协作、非协作(包括具备商业关系但无业务协作，既无商业关系也无业务协作这两种场景)关系。本发明旨在告知UE其双反的协作关系，其告知形式不限于以上所述方式。该协作关系通知可以为单独的信令或消息，也可以包含在UE和AS的其它信令或消息中传送，例如步骤S801。该协作关系的指示，可在non-1MS AS获取后的任何时候通知，不限于步骤S805之后；
[0130]步骤S807:业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE发起优先流处理请求。UE根据当前的应用提供商与运营商的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为:当两者具有商业关系但无业务协作时，由UE向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求,触发运营商修改会话更新Q0S。
[0131]UE发送请求消息给non-MS AS，UE的该请求消息中携带UEIP/ID，优先流处理指不/QoS,及 flow information,以及如果有可能还会携带 Service ID/Application ID;
[0132]步骤S808:non-MS AS收到UE的请求消息后，关联UE Id/IP和所需提升QoS的service/application,发送请求消息给PCRF,请求发起会话修改update QoS ;这里non-1MS AS作为PCRF的diameter client端，请求消息中携带UE ID/IP,优先流处理指示/QoS,及 flow information,以及可倉泛还有 service ID/application ID;
[0133]步骤S809 =PCRF收到该non_MS AS的请求消息后，查询SPR/UDC该用户/业务/应用是否签约了高优先流处理(若本地没有相关签约信息则查询SPR/UDC)，若签约允许则根据请求发起会话修改流程；制定下发更新后的PCC规则给PCEF/BBERF，orADC规则给TDF0 PCEF/BBERF/TDF更新PCC/QoS/ADC规则，修改或新建承载，执行update后的QoS和相关承载的绑定。并发送响应消息给PCRF，反馈规则执行结果；
[0134]步骤S810:PCRF返回提升QoS修改响应消息给non-MS AS，告知修改是否被接受，如果被拒绝，携带相关cause ;该步骤需要AF在发送QoS更新请求时一并订阅资源分配状态等事件报告；
[0135]步骤S811:若update QoS更新成功，则non-1MS给UE发送更新QoS确认请求消息，要求用户确认是否满意更新后的QoS，如果满意则在预览时间段内返回肯定的确认消息(确认接受更新后的QoS后，用户需要为此优先流处理提供额外资费);如果不满意或不同意支付额外的优先流处理费用，则返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，non-MS AS上也可设置timer作为拒绝或接受流程的时间窗口。但具体处理根据产品实现处理)。该步骤也可以由UE检测到QoS更新成功即资源修改成功后，并且本地设置的预览定时器超时，触发API发送确认消息给用户感知；
[0136]步骤S812:用户收到non-MSAS的确认请求消息或底层UE触发的确认请求消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对该消息进行确认，UE将会发送给确认响应消息给non-MS AS。
[0137]步骤S813:该non-1MS AS收到UE的确认响应后，可选地发送确认response消息给PCRF。若为接收更新后的高QoS确认，则运营商将对该业务继续提供update之后的QoS (例如，继续进行优先流处理，提供高优先级或高带宽资源)。PCRF将发起IP-CAN会话修改流程，下发新的Charigng key (对该QoS下的业务执行相应的优先流特殊计费)。
[0138]步骤S813a_c:若UE对提升后的业务数据流的服务质量或用户体验不满意和或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回响应消息)或返回否定确认消息给non-1MS AS(即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给non-MS AS)，执行步骤 S813a-c ；
[0139]步骤S813a:若non-1MS AS在规定时间内(例如timer2 timeout)没有收到用户的确认接收消息，或收到了用户的确认拒绝消息，则将发送更新QoS请求(例如，downgradeQoS)给 PCRF ；
[0140]步骤S813b:PCRF收到non-1MS AS的downgrade QoS请求消息后，结合签约信息及本地策略(例如用户确认接收UpdateQoS的Preview timer超时则需要回复原先QoS),发起IP-CAN/GWcontrol/TDF会话修改流程，更新相关PCC/QoS/ADC规则，恢复该业务的原先QoS ；
[0141]步骤S813c:在QoS恢复处理完成后或提升QoS确认时间超时后，网络对该业务数据流的处理将恢复到UE请求提升之前的QoS (QoS回退机制不在本发明的限定范围内，可采用例如网元间的timer机制处理会话修改的回退时间，可本地存储update之前的QoS,或者AS发送downgrade QoS请求消息时携带此前的QoS信息,或者请求消息中携带使用默认QoS指不等)。
[0142]以上流程中除了策略控制，还存在计费相关处理流程，例如更新QoS后，新的PCC规则中可能下发新的计费关键字(对应新的计费费率)，可能存在PCRF、PCEF/BBERF/TDF等网元与计费网元0CS/0FCS以及其它计费系统的交互；该部分处理不在本发明的保护范围之内，因此没有本发明在此不作详述；
[0143]以上流程中，当DAP和MO存在商业关系但无业务协作时，默认UE向DAP请求进而由DAP触发MO发起优先流处理请求，但现网部署中也可支持直接由UE请求MO发起优先流处理请求，可由UE提供两种处理机制选项供用户选择并根据其选择发起流处理请求，或根据运营商策略默认其中一种处理机制，或默认两种机制的优先级处理。具体根据现网部署需求和运营商策略决定。
[0144]针对本实施例的该流程，若运营商有自有AF功能或网元(例如应用平台或集成在其它网元中的AF功能)，non-MS AS与PCRF的交互消息可能会发送给该运营商自有AF，前传给PCRF处理，相关相应消息也可能经由AF转发给第三方的non-MS AS。
[0145]经过上述流程，可实现当运营商和应用提供商存在商业关系但无业务协作时，UE向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求，触发运营商修改会话更新QOS，提升或降低服务质量/用户体验，变更运营商为该业务传送的资源所对应的业务资费费率的处理流程。
[0146]实施例3
[0147]本实施例基于图3的MOSAP架构基础上提供一种UE通过运营商感知应用提供商和运营商的协作关系，并根据运营商策略或用户的选择来触发QoS提升的方法和系统，来实现用户根据其需求触发的优先流处理。
[0148]本实施例描述的UE使用和运营商不具有协作关系的第三方应用提供商的业务(该第三方应用提供商和运营商没有任何商业关系也没有任何业务协作，或具有商业关系但没有业务协作)。运营商负责为UE的第三方应用提供传输资源，UE向运营商或第三方应用提供商发起优先流处理请求，由运营商处理相关QoS的更新。
[0149]IP-CAN会话创建后，运营商根据其签约信息中的协作运营商的签约list、第三方应用提供商的ID，业务/应用ID等信息判断其与该第三方应用提供商的协作关系，并将其告知UE相应的API。UE接收并存储运营商发送的其与应用提供商的该协作关系。当用户不满意当前业务的QoS，发起优先流处理请求时，UE根据当前的DAP与MO的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为当DAP和MO既无商业关系业务协作时直接由UE请求MO发起优先流处理请求。根据运营商网络部署,UE可通过承载资源修改流程发起该QoS更新，也可以通过运营商自有的AF触发PCRF发起该QoS更新。
[0150](一)
[0151]在图9所示流程中，UE通过运营商感知协作关系，并且UE通过MNO来发起QoSupdate，通过运营商自有AF和PCRF交互，触发会话修改更新Q0S。图9所示流程中，UE使用和运营商不具有协作关系的第三方应用提供商的业务(该第三方应用提供商和运营商没有任何商业关系也没有任何业务协作)。运营商负责为UE的第三方应用提供传输资源，UE向运营商发起优先流处理请求，由运营商处理相关QoS的更新。
[0152]该网络部署中运营商自有AF功能(可以为新增逻辑功能，可以独立部署，或集成在其它网元中。可以为运营商自有应用平台，也可以是和NAF或OP结合的具备AF功能的proxy网元，也可以集成在现有网元中，例如PCRF中)，支持UE和AF的接口(可以采用http协议或者其它应用层信令)，若AF在PCRF之外，则支持AF和PCRF的接口(这里为Rx接口，可采用Diameter协议通信)。采用自有AF功能，不但可以解决UE和PCRF没有直接接口的问题，还可以解决IMS认为的UE提供的QoS和application信息不完全可信的问题，其可以被看作non-1MS AS和运营商网络的proxy。如图9所示,该流程包括:
[0153]步骤S901:UE附着到归属地网络，建立无线承载和创建IP-CAN session ；
[0154]步骤S902:UE登陆并成功访问Non-MS AS,这里UE和Non-MS AS使用application level signaling 或 HTTP 协议，non-1MS AS 为 UE 提供应用业务；Non-1MS AS一并向运 UE 提供 Service ID/application ID,以及 flow information 相关信息；
[0155]步骤S903:完成该业务所需承载的创建；PCRF根据AS，SPR/UDC，PGff等client端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF;PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关event trigger,以及用量监控阈值,监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；[0156]步骤S904:该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输;
[0157]步骤S905:运营商根据其签约信息中的协作运营商的签约list、第三方应用提供商的ID，业务/应用ID等信息判断其与该第三方应用提供商的协作关系，并将其告知UE相应的API。UE接收并存储运营商发送的其与应用提供商的该协作关系。该交互信令可以为应用层信令或http等应用协议，该协作指示告知UE该应用提供商的该项业务与运营商的协作关系，例如协作、非协作(包括具备商业关系但无业务协作，既无商业关系也无业务协作这两种场景)关系。本发明旨在告知UE其双方的协作关系，其告知形式不限于以上所述方式。该协作关系通知可以为单独的信令或消息，也可以包含在UE和运营商的其它信令或消息中传送，例如步骤S901或S903中。该协作关系的指示，可在运营商获取后的任何时候通知，不限于步骤S904之后；
[0158]步骤S906:业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE发起优先流处理请求。UE根据当前的应用提供商与运营商的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为:当两者既无商业关系业务协作时，直接由UE请求运营商发起优先流处理请求。根据运营商网络部署，UE可通过承载资源修改流程发起该QoS更新，也可以通过运营商自有的AF触发PCRF发起该QoS更新。这里UE通过运营商自有的AF触发。
[0159]UE发送请求消息给AF (部署中可以为类似NAF或non-MS AS或RP等应用平台或集成在现有网元中)；UE的该请求消息中携带UEIP/ID,优先流处理指示/QoS,及flowinformation,以及如果有可能还会携带Service ID/Application ID;(这里UE和AF的通信协议不作限定，http或应用层信令均可实现)；
[0160]步骤S907:AF收到UE的请求消息后，关联UE Id/IP和所需提升QoS的service/application,发送CCR请求消息给PCRF,请求发起会话修改update QoS ;这里AF作为PCRF的diameter client端,可独立或集成于其它网元实体中部署。请求消息中携带UE ID/IP,优先流处理指不/QoS,及 flow information,以及可能还有 service ID/application ID;
[0161]步骤S908 =PCRF收到该AF的请求消息后，查询SPR/UDC该用户/业务/应用是否签约了高优先流处理，若签约允许则根据请求发起会话修改流程；制定下发更新后的PCC规则给 PCEF/BBERF，orADC 规则给 TDF。PCEF/BBERF/TDF 更新 PCC/QoS/ADC 规则，修改或新建承载，执行update后的QoS和相关承载的绑定。并发送响应消息给PCRF，反馈规则执行结果;
[0162]PCRF返回提升QoS修改响应消息CCA给该AF，告知修改是否被接受，如果被拒绝，携带相关cause ；
[0163]步骤S909:若update QoS授权成功，则AF给UE发送更新QoS确认请求消息，要求用户确认是否满意更新后的QoS，如果满意则在预览时间段内返回肯定的确认消息(确认接受更新后的QoS后，用户需要为此优先流处理提供额外资费)；如果不满意或不同意支付额外的优先流处理费用，则返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，AF上也可设置timer某人拒绝或接受流程的除服。但具体处理根据运营商网络实现处理);该处理流程，AF可在发送请求St印S907中设置QoS提升定时器Timerl，在收到PCRF的CCA确认消息且Timerl Time out之后(Timerl有效期应能保证正常的PCRF发起的IP-CANsession modification更新QoS处理完毕且已经按新的QoS为UE提供应用业务)，AF则向UE发送确认请求消息。发送该请求消息后AF可开启用户确认定时器Timer2。
[0164]步骤S910:UE收到该AF的确认消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对该消息进行确认，UE将会发送给确认消息给该AF。该AF收到UE的确认响应后,可选地返回确认response消息给PCRF,运营商将对该业务继续提供update之后的QoS (例如，继续进行优先流处理，提供高优先级或高带宽资源)。PCRF将发起IP-CAN会话修改流程(同StepS908),下发新的Charigng key (对该QoS下的业务执行相应的优先流特殊计费)。
[0165]若UE对提升后的业务数据流的服务质量或用户体验不满意和或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回响应消息)或返回否定确认消息给此AF (即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给AF),执行stepS910a_c ；
[0166]步骤S910a:若AF在规定时间内(例如timer2 timeout)没有收到用户的确认接收消息，或收到了用户的确认拒绝消息，则AF将发送更新QoS请求(例如，downgrade QoS)给 PCRF ；
[0167]步骤S910b:PCRF收到AF的downgrade QoS请求消息后，结合签约信息及本地策略(例如用户确认接收UpdateQoS的Preview timer超时则需要回复原先QoS),发起IP-CAN/Gffcontrol/TDF会话修改流程，更新相关PCC/QoS/ADC规则，恢复该业务的原先QoS ；
[0168]步骤S910c:在QoS恢复处理完成后或提升QoS确认时间超时后，网络对该业务数据流的处理将恢复到UE请求提升之前的QoS (QoS回退机制不在本发明的限定范围内，可采用例如网元间的timer机制处理会话修改的回退时间，可本地存储update之前的QoS,或者Trigger node发送downgrade QoS请求消息时携带此前的QoS信息,或者请求消息中携带使用默认QoS指示等)。
[0169]以上流程中除了策略控制，还存在计费相关处理流程，例如更新QoS后，新的PCC规则中可能下发新的计费关键字(对应新的计费费率)，可能存在PCRF、PCEF/BBERF/TDF等网元与计费网元0CS/0FCS以及其它计费系统的交互。
[0170]经过上述流程，可实现当运营商和应用提供商既无商业关系也无业务协作时，UE通过运营商感知其协作关系，直接请求运营商发起优先流处理请求，通过运营商自有的AF触发PCRF发起该QoS更新，提升或降低服务质量/用户体验，变更运营商为该业务传送的资源所对应的业务资费费率的处理流程。
[0171](二)
[0172]对于该场景UE请求QoS更新，根据运营商网络部署，UE还可以通过重用承载资源修改流程完成该QoS的更新。在图10所示流程中，UE通过运营商感知协作关系，运营商和第三方应用提供商不具有商业关系也没有业务协作，并且，UE通过运营商MNO来发起QoSupdate，通过承载资源修改流程，触发” PCEF发起的会话修改流程”，更新Q0S。如图10所示，该流程包括:
[0173]步骤SlOOl:如上步骤S901_S905，UE附着到网络建立相关承载和会话，向Non-MSAS请求了该业务，并创建完成相关的业务承载，网络按授权QoS为UE提供该业务数据的下行传输；
[0174]步骤S1002:运营商根据其签约信息中的协作运营商的签约list、第三方应用提供商的ID，业务/应用ID等信息判断其与该第三方应用提供商的协作关系，并将其告知UE相应的API。UE接收并存储运营商发送的其与应用提供商的该协作关系。该交互信令可以为应用层信令或http等应用协议。该协作指示告知UE该应用提供商的该项业务与运营商的协作关系，例如协作、非协作(包括具备商业关系但无业务协作，既无商业关系也无业务协作这两种场景)关系。本发明旨在告知UE其双方的协作关系，其告知形式不限于以上所述方式。该协作关系通知可以为单独的信令或消息，也可以包含在UE和运营商的其它信令或消息中传送。该协作关系的指示，可在运营商获取后的任何时候通知，不限于步骤SlOOl结束之后；
[0175]步骤S1003:业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE发起优先流处理请求。UE根据当前的应用提供商与运营商的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为:当两者既无商业关系业务协作时，直接由UE请求运营商发起优先流处理请求。根据运营商网络部署，UE可通过承载资源修改流程发起该QoS更新，也可以通过运营商自有的AF触发PCRF发起该QoS更新。这里UE通过承载资源修改流程发起该QoS更新。
[0176]UE发送Request消息给MME,请求消息中携带请求的类型(更新QoS), UEIP/ID,承载ID (LBI)，flow information (例如流描述(TAD)，数据包过滤器ID (PTI)等)，QoS。若该业务/应用此前为GBR承载,则请求中可能携带packet filter identifier (s);以及如果有可能还会携带 Service ID/Application ID;
[0177]步骤S1004:MME前转发送request消息给SGW，消息中包括图7中步骤S703中的相关参数；
[0178]步骤S1005:SGff收到该消息后前转该request消息给PGW,消息携带收到的具体
参数；
[0179]步骤S1006:PCEF根据收到的request消息参数,判断需要更新QoS (例如根据携带了优先流处理或承载指示，或QoS更新指示,或该业务请求的QoS高于先的QoS等),发起IP-CANsession modification流程处理,发送会话修改请求给PCRF触发会话修改,如图9中步骤S909。消息中携带UE IP/ID,请求的QoS, flow information (例如TAD,以及SDFfileter ID)等参数。
[0180]PCRF查询SPR/UDC签约信息(例如该用户/业务/应用是否签约了高优先流处理；若签约允许则根据请求提升QoS)，更新PCC策略决策，下发更新后的PCC规则给PCEF/BBERF, or ADC规则给TDF/PCEF (如果存在应用流检测功能)。这里若PCRF本地没有签约信息，则PCRF还需要向SPR/UDC/HSS等数据库获取相关签约信息。PCEF/BBERF更新PCC/QoS规则，修改或新建承载满足提升后的QoS。并反馈规则执行响应消息给PCRF，完成会话修改流程。
[0181]PGW执行QoS策略，完成承载修改和绑定，下发Update Bearer Request给SGW,SGff前传到MME ；MME构建承载修改请求消息下发给eNodeB,带上Bear ID, QoS; eNodeB映射EPS承载QoS到无线承载QoS下发RRL CR消息给UE’ UE更新存储相关QoS ;逐级返回相关response消息直至给PGW，完成承载修改流程。这里具体涉及每个网元的消息及其参数等内容的详细流程可参照3GPP TS 23.401中的UE发起的承载资源修改描述。
[0182]步骤S1007:若update QoS成功，则需要发送更新QoS确认请求消息给UE,要求用户确认是否满意更新后的QoS，如果满意则UE返回肯定的确认消息(确认接受更新后的QoS需要为此优先流处理提供额外资费)；如果不满意或不同意支付额外的优先流处理费用，则UE给网络返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，但具体处理根据运营商网络实现处理)；
[0183]或者可以不由UE本身触发感知，而由网络侧下发通知。在完成IP-CAN sessionmodification流程后，按更新后的QoS为该业务提供业务数据流；PGW/PCEF下发一个通知消息给UE，要求UE对更新后的QoS进行确认，该通知消息中携带确认指示，表示用户请求的QoS更新完成，请求确认；SGW收到该通知消息后，下发该通知给MME，带上UEID/IP，必要的业务流信息，以及该确认指示；MME将该消息下发给UE，UE收到该通知消息后将提供一个通知指示给上层(例如应用层)，触发用户感知；
[0184]步骤S1008:用户收到UE应用层的确认消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对在预览时间段内对该消息进行确认，UE将会发送给肯定的确认消息给该网络(在请求或通知相应中携带肯定的确认信息)，运营商将根据该确认对该业务继续提供update之后的QoS (例如，继续进行优先流处理，提供高优先级或高带宽资源)。PCRF将发起IP-CAN会话修改流程(同图9中的步骤S909)，下发新的Charigng key (对该QoS下的业务执行相应的优先流特殊计费)。
[0185]若UE对提升后的业务数据流的服务质量或用户体验不满意和或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回确认响应消息)或返回否定确认消息给网络(即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给网络，若User不确认则应用层则需要在等待确认的timer timeout之后触发承载层构建否定确认消息发送给网络，网络将会在一定preview时间之后将QoS恢复到请求提升之前的水平；
[0186]步骤S1009 =MME收到UE的请求或通知相应消息，给SGW前转该消息，携带原消息中的参数，例如UE IP/ID，QoS，肯定或否定的确认信息/指示等；
[0187]步骤SlOlO =SGff前传该消息到PGW，携带QoS和确认信息/指示等参数；
[0188]步骤SlOll:PGW根据确认信息/指示判断用户业务所需的QoS，若为肯定确认，则执行步骤S1012 ；
[0189]若为否定确认则发送IP-CANsession modification请求给PCRF发起会话修改流程，downgrade QoS ；PCRF收到downgrade QoS请求消息后，结合签约信息及本地策略(例如用户确认接收UpdateQoS的Preview timer超时则需要回复原先QoS),发起IP-CAN/Gffcontrol/TDF会话修改流程，更新相关PCC/QoS/ADC规则，恢复该业务的原先QoS ;该IP-CAN session修改流程修改承载和会话，为该业务提供的QoS将恢复到用户提升请求之前的水平，按原有的QoS继续执行StepS1015提供下行业务数据流；(QoS回退机制不在本发明的限定范围内，可采用例如网元间的timer机制处理会话修改的回退时间，可本地存储update之前的QoS,或者UE发送downgrade QoS请求消息时携带此前的QoS信息,或者请求消息中携带使用默认QoS指示等)。
[0190]步骤S1012-S1014:如步骤S1008 PCRF发起的IP-CAN会话修改流程下发新的Charigng key (对该QoS下的业务执行相应的优先流特殊计费),提升或恢复QoS流程处理完毕。PGW确认UE用于发送确认通知发起的资源修改流程不需要执行(即QoS不需要变更)，则发送承载资源修改失败指示来指示SGW，高QoS将继续应用于该业务，不需要重新发起QoS修改流程，执行步骤S1012-S1014反馈该承载资源修改失败指示。
[0191]步骤S1015:若为步骤SlOll则在downgrade QoS完成后，按最初的QoS传送下行数据；若为update QoS成功确认St印S1014，则按提升后的QoS传送下行数据。S卩，网络按授权的QoS为该业务继续提供业务数据流。
[0192]经过上述流程，可实现当运营商和应用提供商既无商业关系也无业务协作时，UE通过运营商感知其合作关系，直接请求运营商发起优先流处理请求，通过承载资源修改流程触发PCRF发起IP-CAN会话修改，更新该业务的QoS，提升或降低服务质量/用户体验，变更运营商为该业务传送的资源所对应的业务资费费率的处理流程。
[0193](三)
[0194]本实施例基于图3的MOSAP架构基础上提供一种UE通过运营商感知应用提供商和运营商的协作关系，并根据运营商策略或用户的选择来触发QoS提升的方法和系统，来实现用户根据其需求触发的优先流处理。
[0195]本实施例描述的UE使用和运营商不具有协作关系的第三方应用提供商的业务，该第三方应用提供商和运营商具有商业关系但没有任何业务协作。运营商负责为UE的第三方应用提供传输资源，UE向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求,触发运营商修改会话更新Q0S。
[0196]IP-CAN会话创建后，运营商根据其签约信息中的协作运营商的签约list、第三方应用提供商的ID，业务/应用ID等信息判断其与该第三方应用提供商的协作关系，并将其告知UE相应的API。UE接收并存储运营商发送的其与应用提供商的该协作关系。当用户不满意当前业务的QoS，发起优先流处理请求时，UE根据当前的DAP与MO的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为当DAP和MO存在商业关系但无业务协作时，由UE向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求，触发运营商修改会话更新Q0S。
[0197]在图11所示流程中，UE通过运营商MO感知协作关系，第三方应用提供商和运营商具有商业关系但没有业务协作，并且UE通过MNO来发起QoSupdate，non-MS AS通知PCRF，触发” PCEF发起的会话修改流程”，更新Q0S。该该网络部署中运营商和第三方业务提供商具有Rx接口，可传送相关业务信息。但运营商不会替第三方业务提供商向用户进行第三方业务的资费统计和计算。如图11所示，该流程包括:
[0198]步骤SllOl:UE附着到归属地网络，建立无线承载和创建IP-CAN session ；
[0199]步骤SI 102:UE登陆并成功访问Non-MS AS,这里UE和Non-MS AS使用application level signaling 或 HTTP 协议，non-1MS AS 为 UE 提供应用业务；
[0200]步骤SI 103 =Non-1MS AS 向运营商的 PCRF 提供 UE ID/IP, Service ID/application ID,以及flow information相关信息，发起Rx会话建立请求。PCRF向SPR/UDC获取UE签约信息和签约AS信息，制定并下发PCC rule给PCEF，建立相关数据承载。由于该AS与运营商只有商业关系没有业务合作,授权QoS为default bearer QoS ；[0201]步骤S1104:完成该业务所需承载的创建；PCRF根据AS，SPR/UDC，PGff等client端发送的相关信息制定PCC/QoS规则，并下发到PCEF/BBERF;PCEF/BBERF安装并执行相关规则，完成承载绑定，若没有匹配承载则下发承载建立请求，创建承载；PCRF下发规则的同时，还可能携带相关event trigger,以及用量监控阈值,监控关键字等其它信息；PCEF收到信息后设置和执行相关事件报告及用量监控功能；
[0202]步骤S1105:该业务承载创建完成，网络按授权QoS为UE提供该业务数据的下行传输；
[0203]步骤S1106:运营商根据其签约信息中的协作运营商的签约list、第三方应用提供商的ID，业务/应用ID等信息判断其与该第三方应用提供商的协作关系，并将其告知UE相应的API。UE接收并存储运营商发送的其与应用提供商的该协作关系。该协作指示告知UE该应用提供商的该项业务与运营商的协作关系，例如协作、非协作(包括具备商业关系但无业务协作，既无商业关系也无业务协作这两种场景)关系。本发明旨在告知UE其双方的协作关系，其告知形式不限于具体信令方式。该协作关系通知可以为单独的信令或消息，也可以包含在UE和运营商的其它信令或消息中传送,例如步骤SllOl和S1104的消息。该协作关系的指示，可在运营商获取后的任何时候通知，不限于步骤S1105之后；
[0204]步骤SI 107:业务过程中，UE发现服务质量QoS或用户体验不满意(例如，由于移动性或网络状况导致数据流传输不稳定或带宽太低等)，UE发起优先流处理请求。UE根据当前的应用提供商与运营商的协作关系和运营商策略做出正确的选择。例如，运营商默认策略为:当两者具有商业关系但无业务协作时，由UE向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求,触发运营商修改会话更新Q0S。
[0205]UE发送请求消息给non-MS AS，UE的该请求消息中携带UEIP/ID，优先流处理指不/QoS,及 flow information,以及如果有可能还会携带 Service ID/Application ID;
[0206]步骤SI 108:non-1MS AS收到UE的请求消息后，关联UE Id/IP和所需提升QoS的service/application,发送请求消息给PCRF,请求发起会话修改update QoS ;这里non-1MS AS作为PCRF的diameter client端，请求消息中携带UE ID/IP,优先流处理指示/QoS,,? f1winformation,以及可倉泛还有 service ID/application ID;
[0207]步骤S1109 =PCRF收到该non_MS AS的请求消息后，查询SPR/UDC该用户/业务/应用是否签约了高优先流处理(若本地没有相关签约信息则查询SPR/UDC)，若签约允许则根据请求发起会话修改流程；制定下发更新后的PCC规则给PCEF/BBERF，orADC规则给TDF0 PCEF/BBERF/TDF更新PCC/QoS/ADC规则，修改或新建承载，执行update后的QoS和相关承载的绑定。并发送响应消息给PCRF，反馈规则执行结果；
[0208]步骤SlllO =PCRF返回提升QoS修改响应消息给non_MS AS，告知修改是否被接受，如果被拒绝，携带相关cause ;该步骤需要AF在发送QoS更新请求时一并订阅资源分配状态等事件报告；
[0209]步骤Sllll:若update QoS更新成功，则non-1MS给UE发送更新QoS确认请求消息，要求用户确认是否满意更新后的QoS，如果满意则在预览时间段内返回肯定的确认消息(确认接受更新后的QoS后，用户需要为此优先流处理提供额外资费);如果不满意或不同意支付额外的优先流处理费用，则返回否定的确认或不进行确认(若用户不进行确认，则终端设备可能会构建否定确认返回给网络，便于技术实现中区分用户没有发送确认和确认消息丢失的异常情形，non-MS AS上也可设置timer作为拒绝或接受流程的时间窗口。但具体处理根据产品实现处理)。该步骤也可以由UE检测到QoS更新成功即资源修改成功后，并且本地设置的预览定时器超时，触发API发送确认消息给用户感知；
[0210]步骤S1112:用户收到non-MS AS的确认请求消息或底层UE触发的确认请求消息后，若对更新(例如提升)后的业务数据流满意且愿意支付优先流处理的费用，则对该消息进行确认，UE将会发送给确认响应消息给non-MS AS。
[0211]步骤S1113:该non-1MS AS收到UE的确认响应后,可选地发送确认response消息给PCRF。若为接收更新后的高QoS确认，则运营商将对该业务继续提供update之后的QoS (例如，继续进行优先流处理，提供高优先级或高带宽资源)。PCRF将发起IP-CAN会话修改流程，下发新的Charigng key (对该QoS下的业务执行相应的优先流特殊计费)。
[0212]步骤S1113a_c:若UE对提升后的业务数据流的服务质量或用户体验不满意和或不愿意支付额外的优先处理费用，则用户不对该确认请求进行确认(不返回响应消息)或返回否定确认消息给non-1MS AS(即如果用户不同意执行新的服务质量提供该业务但未作否定确认，则终端设备根据运营商需求可选地构建否定确认消息发送给non-MS AS)，执行步骤 513a-c ；
[0213]步骤SI 113a:若non-1MS AS在规定时间内(例如timer2 timeout)没有收到用户的确认接收消息，或收到了用户的确认拒绝消息，则将发送更新QoS请求(例如，downgradeQoS)给 PCRF ；
[0214]步骤SI 113b:PCRF收到non-1MS AS的downgrade QoS请求消息后，结合签约信息及本地策略(例如用户确认接收UpdateQoS的Preview timer超时则需要回复原先QoS),发起IP-CAN/GWcontrol/TDF会话修改流程，更新相关PCC/QoS/ADC规则，恢复该业务的原先QoS ；
[0215]步骤SI 113c:在QoS恢复处理完成后或提升QoS确认时间超时后，网络对该业务数据流的处理将恢复到UE请求提升之前的QoS (QoS回退机制不在本发明的限定范围内，可采用例如网元间的timer机制处理会话修改的回退时间，可本地存储update之前的QoS,或者AS发送downgrade QoS请求消息时携带此前的QoS信息,或者请求消息中携带使用默认QoS指示等)。
[0216]以上流程中除了策略控制，还存在计费相关处理流程，例如更新QoS后，新的PCC规则中可能下发新的计费关键字(对应新的计费费率)，可能存在PCRF、PCEF/BBERF/TDF等网元与计费网元0CS/0FCS以及其它计费系统的交互。
[0217]以上流程中，当DAP和MO存在商业关系但无业务协作时，默认UE向DAP请求进而由DAP触发MO发起优先流处理请求，但现网部署中也可支持直接由UE请求MO发起优先流处理请求，可由UE提供两种处理机制选项供用户选择并根据其选择发起流处理请求，或根据运营商策略默认其中一种处理机制，或默认两种机制的优先级处理。具体根据现网部署需求和运营商策略决定。
[0218]针对本实施例的该流程，若运营商有自有AF功能或网元(例如应用平台或集成在其它网元中的AF功能)，non-MS AS与PCRF的交互消息可能会发送给该运营商自有AF，前传给PCRF处理，相关相应消息也可能经由AF转发给第三方的non-MS AS。[0219]经过上述流程，可实现当运营商和应用提供商存在商业关系但无业务协作时，UE通过运营商感知其合作关系，向第三方业务提供商发起优先流处理请求，由DAP进而向运营商发起相关QoS的更新处理请求，触发运营商修改会话更新Q0S，提升或降低服务质量/用户体验，变更运营商为该业务传送的资源所对应的业务资费费率的处理流程。
[0220]上述实施例2和实施例3可以结合使用，主要根据具体网络部署和网元功能支持。
[0221]以上实施例描述是在运营商和第三方应用提供商非协作关系场景下的IE感知和区分，以上实施例同样适用于UE运营商自有业务和运营商与第三方存在协作关系(collaborated)场景的的感知和区分，以及运营商自有业务，与第三方存在协作，与第三方不存在协作没有商业关系，以及与第三方不存在协作但有商业关系的这几类场景在现网部署和应用中的感知和区分
[0222]在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施方式中描述的技术方案。
[0223]在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储介质包括但不限于:光盘、软盘、硬盘、可擦写存储器等。
[0224]显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
[0225]以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
【权利要求】
1.一种服务质量的更新处理方法，其特征在于，包括: 用户设备UE获取应用提供商和运营商的协作关系； 所述UE根据获取的所述协作关系请求服务质量QoS更新。
2.根据权利要求1所述的方法，其特征在于，所述协作关系，包括以下之一: 所述应用提供商和所述运营商存在业务协作；所述应用提供商和所述运营商不存在业务协作和商业关系；所述应用提供商和所述运营商仅存在商业关系但无业务协作。
3.根据权利要求2所述的方法，其特征在于，所述UE根据获取的所述协作关系请求QoS更新，包括: 在所述应用提供商和所述运营商不存在业务协作和商业关系时，所述UE直接向所述运营商发起请求，请求所述运营商对QoS进行更新处理。
4.根据权利要求2所述的方法，其特征在于，所述UE根据获取的所述协作关系请求QoS更新，包括: 在所述应用提供商和所述运营商仅存在商业关系但无业务协作时，所述UE根据所述协作关系采用以下方式之一发起对QoS的更新流程:所述UE直接向所述运营商发起请求，触发所述运营商进行对QoS进行更新处理；所述UE经由所述应用提供商发起请求触发所述运营商对QoS进行更新处理。
5.根据权利要求1至4任一项所述的方法，其特征在于，所述UE获取应用提供商和运营商的协作关系，包括: 所述UE接收来自于所述应用提供商发送的所述协作关系；或者 所述UE接收来自于所述运营商发送的所述协作关系。
6.根据权利要求5所述的方法，其特征在于，所述UE接收来自于所述运营商发送的所述协作关系，包括: 所述UE从所述运营商的应用功能AF实体发送的应用层信令或协议中获取所述协作关系；或者 所述UE从所述运营商的承载层信令中获取所述协作关系。
7.一种服务质量的更新处理装置，位于用户设备UE中，其特征在于，包括: 获取模块，用于获取应用提供商和运营商的协作关系； 请求模块，用于根据获取的所述协作关系请求服务质量QoS更新。
8.根据权利要求7所述的装置，其特征在于，所述获取模块用于获取以下之一协作关系: 所述应用提供商和所述运营商存在业务协作；所述应用提供商和所述运营商不存在业务协作和商业关系；所述应用提供商和所述运营商仅存在商业关系但无业务协作。
9.根据权利要求8所述的装置，其特征在于，所述请求模块，用于在所述应用提供商和所述运营商不存在业务协作和商业关系时，直接向所述运营商发起请求，请求所述运营商进行对QoS进行更新处理。
10.根据权利要求8所述的装置，其特征在于，所述请求模块，用于在所述应用提供商和所述运营商仅存在商业关系但无业务协作时，根据所述协作关系采用以下方式之一发起对QoS的更新流程:直接向所述运营商发起请求，触发所述运营商对QoS进行更新处理；经由所述应用提供商发起请求触发所述运营商对QoS进行更新处理。
11.根据权利要求7至10任一项所述的装置，其特征在于，所述获取模块，用于接收来自于所述应用提供商发送的所述协作关系；或者接收来自于所述运营商发送的所述协作关系ο
【文档编号】H04W28/24GK103582030SQ201210271325
【公开日】2014年2月12日 申请日期:2012年8月1日 优先权日:2012年8月1日
【发明者】吴锦花, 周晓云 申请人:中兴通讯股份有限公司