CN101296094A - 检测承载事件的方法、***和装置 - Google Patents
检测承载事件的方法、***和装置 Download PDFInfo
- Publication number
- CN101296094A CN101296094A CNA200710102006XA CN200710102006A CN101296094A CN 101296094 A CN101296094 A CN 101296094A CN A200710102006X A CNA200710102006X A CN A200710102006XA CN 200710102006 A CN200710102006 A CN 200710102006A CN 101296094 A CN101296094 A CN 101296094A
- Authority
- CN
- China
- Prior art keywords
- event
- detection
- type
- incident
- function entity
- 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
- 238000000034 method Methods 0.000 title claims abstract description 39
- 238000001514 detection method Methods 0.000 claims abstract description 233
- 230000011664 signaling Effects 0.000 claims abstract description 21
- 230000004044 response Effects 0.000 claims description 17
- 238000013475 authorization Methods 0.000 claims description 11
- 230000004048 modification Effects 0.000 claims description 11
- 238000012986 modification Methods 0.000 claims description 11
- 238000012360 testing method Methods 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 9
- 238000012217 deletion Methods 0.000 description 5
- 230000037430 deletion Effects 0.000 description 5
- 238000011144 upstream manufacturing Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000009472 formulation Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例公开了一种检测承载事件的方法，该方法包括：应用层功能实体(AF)向策略控制和计费规则功能实体(PCRF)发送承载事件检测请求，承载事件检测请求中包含事件检测类型范围以及对应于事件检测类型范围中每一事件类型的事件检测范围；PCRF在每一事件类型的事件检测范围内检测该种类型的事件，并向AF返回所检测到事件的事件类型及该检测到事件的影响范围。本发明还公开了一种检测承载事件的***和装置。应用本发明以后，解决了因事件检测粒度过大导致的不必要消息交互，降低了冗余消息交互，还解决了现有事件检测上报机制使用不灵活的问题，还可以将本发明应用到信令路径状态检测中，无需建立单独的Diameter会话。
Description
技术领域
本发明涉及通信技术领域，更具体地说，本发明涉及检测承载事件的方法、***和装置。
背景技术
在通信网络向全网际协议(Internet Protocol，IP)演进的过程中，为了提供满意的业务，需要解决端到端服务质量(Quality Of Service，QoS)问题。IP网络可以提供各种各样的业务，比如多媒体呼叫、文件下载、网页浏览等，其中不同的业务对QoS(包括带宽、时延、丢包率等)有不同的要求，而且计费方面的要求也不同。比如：可以采用在线计费或者离线计费，还可以根据流量计费或者根据时间计费等。
为了解决上述QoS和计费等相关问题，第三代合作伙伴计划(The ThirdGeneration Partnership Project，3GPP)定义了策略和计费控制(Policy andCharging Control，PCC)架构，通过该架构可以满足不同的QoS控制和计费需求。
图1为现有技术中PCC结构的示意图，其中各个功能实体作用如下描述：
策略控制和计费规则功能实体(Policy Control and Charging RulesFunction，PCRF)，主要完成策略的决策和基于流的计费控制等功能。PCRF实体根据运营商策略、用户签约数据以及用户当前正在进行的业务信息等决定相应的策略，并将该策略提供给策略和计费执行实体(Policy and ChargingEnforcement Function，PCEF)，由PCEF执行这些策略。用户签约数据可以从用户签约数据数据库(Subscription Profile Repository，SPR)功能实体中获取。策略包括业务数据流(完成某业务如语音通信的IP流的集合)的检测规则、是否门控、QoS、基于流的计费规则等。
PCEF，主要用于完成业务数据流的检测、策略的执行、基于流的计费等功能。该实体执行PCRF下发或者指定的策略，具体来说就是执行业务数据流的检测和测量、保证业务数据流的QoS、用户面流量处理和触发控制面的会话管理等。
SPR，该功能实体用于向PCRF提供用户签约数据。
应用层功能实体(Application Function，AF)，该功能实体用于向PCRF动态提供应用层业务的会话信息，供PCRF制定相应的策略，AF可以从PCRF获取IP连接性接入网络(IP-Connectivity Access Network，IP-CAN)相关的信息以及IP-CAN承载相关的事件等。
AF和PCRF之间的接口为Rx参考点。该参考点用于AF下发应用层相关信息，包括用于识别业务数据流的IP过滤器(如源IP地址、目的IP地址、协议类型、源端口号、目的端口号等)、应用或者媒体所需的带宽信息。PCRF也可以通过该参考点向AF提供IP-CAN相关的信息、上报承载事件等。该参考点使用(Internet Engineering Task Force，IETF)定义的Diameter协议。Diameter 系列协议是新一代的鉴权授权应答(Auth-Authorization-Request，AAA)技术，其目的是创建一个能够充分满足目前乃至今后IP网络(包括NGN以及3G等)用户访问控制要求的AAA协议。Diameter协议是远程鉴权拨号用户业务(Remote Authentication Dial-InUser Service，RADIUS)协议的升级，包含基础协议、传送协议、以及针对不同应用场景的扩展协议(Diameter中将针对不同应用场景的扩展称为应用，比如PCC架构中Rx、Gx参考点就是两个不同的Diameter应用)。各种应用共用的基本功能在基础协议中实现，而不同应用场景特定的功能在各应用中定义。
和传统的客户端/服务器模式的协议(如RADIUS)不同，Diameter客户端与Diameter服务器都可以主动向对端发送请求消息。Diameter客户端与Diameter服务器进行一系列的信息交换，而这样一个从发起到中止的一系列信息交互，称为一个Diameter会话。Diameter会话的建立，一般是由客户端发起。Diameter会话的结束，完全由客户端决定，不过服务器也可以先行发出中止会话请求，在客户端同意中止请求的情况下，会响应中止会话应答，然后客户端再发出会话结束请求，通知服务器结束用户会话，否则会话仍然得以保持。
Diameter消息由消息头和消息体组成，消息头中包括协议版本号、应用标识(标识不同的Diameter应用)、命令代码(Command Code，表示消息类型)、消息长度等信息，消息体由属性值对(Attribute-Value-Pair，AVP)组成。不同类型的Diameter消息可以包含不同的AVP，各个应用可以定义该应用特有的AVP，通过定义新的AVP从而实现新的功能正是Diameter的一种扩展机制。
当用户在接入网络内漫游(位置改变时)仍能保存IP业务连续性(即不中断业务)，具有这样性质的接入网络称为IP-CAN，比如(General PacketRadio Service，GPRS)网络，互通无线局域(Inter working-WLAN，I-WLAN)网络等。IP-CAN会话，指的是UE和PDN之间的关联关系，通过用户设备(User Equipment，UE)的IP地址和UE的标识(如IMSI)来识别。只要UE分配了IP地址并且能被IP网络识别，则IP-CAN存在。一个IP-CAN会话可以包含一个或者多个IP-CAN承载。IP-CAN承载的建立可以由用户侧或网络侧发起。将PCRF制定的策略和具体的IP-CAN承载绑定也有两种方式，可以分别由PCRF或者PCEF实现。通过IP-CAN会话建立过程，IP-CAN承载建立过程，在PCEF上实际形成了如图2所示的IP-CAN会话、IP-CAN承载、PCC规则和IP流之间的绑定关系。
图2为IP流、PCC规则、IP-CAN承载、IP-CAN会话之间的对应关系示意图。从图2中可以看出，一个IP-CAN会话中可以建立多个IP-CAN承载，而一个IP-CAN承载可以用于传输一个或者多个IP流(要求这些IP流对QoS的要求一致)，一个PCC规则只能针对一个IP-CAN承载，可以包含一个或者多个IP流，一个IP-CAN承载上可以有一条或者多条PCC规则。
当UE在PDN分配了可寻址的IP地址后，UE就建立了IP-CAN会话，为了满足不同的QoS要求，在同一个IP-CAN会话里可以建立不同QoS要求的IP-CAN承载，假设图2中IP-CAN承载1比IP-CAN承载2有更高的QoS，这样对于QoS要求较高的业务(如VOIP，多媒体呼叫等)可以使用IP-CAN承载1，对于QoS要求较低业务(比如文件下载等、网页浏览等)可以使用IP-CAN承载2。PCEF根据PCC规则中流描述信息(如源IP地址、目的IP地址、协议类型、源端口号、目的端口号等)来识别IP流。
在Rx参考点上，每个媒体流通过一个Media-Component-DescriptionAVP描述。同一个会话中的多个媒体流通过Media-Component-Number AVP标识。如果AF采用会话描述协议(SDP)对媒体进行描述，那么一个媒体流就对应SDP中的m行(媒体描述行)，这个媒体流对应的Media-Component-Number就是该m行在SDP中出现的顺序号。媒体子流是对媒体流进一步细分，比如一个音频媒体流采用实时传输协议(RTP)方式传输时，相应的RTP流和RTCP流分别对应一个媒体子流。在Rx参考点上，每个媒体子流通过一个Media-Sub-Component AVP描述。同一个媒体流中的多个媒体子流通过Flow-Number AVP标识，Flow-Number可以根据各媒体子流对应的端口号等排序。媒体子流可以对应一个双向流(包含两个Flow-Description AVP，描述两个IP流)，也可以对应一个单向流(只包含一个Flow-Description AVP，描述一个IP流)。
IP流是由具有相同源IP地址、目的IP地址、传输层协议、源端口号和目的端口号(合称IP五元组，如果对应的传输层协议没有端口号的概念，源端口号和目的端口号可以省略)的IP报文所组成的单向流。在Rx参考点上，每个IP Flow通过一个Flow-Description AVP描述。
综上所述，用户激活一个业务，业务中可以包含一个或者多个媒体流(音频流、视频流、数据流等)，每个媒体流可以包含一个或者多个媒体子流，而每个媒体子流可以包含一个或者两个IP流。
由此可见，在现有技术中，具有如下缺点：
首先，AF请求事件上报只能针对AF与PCRF之间的整个Diameter会话，会话中可以有很多IP流，而且这些IP流QoS的要求可以不同，从而承载在多个IP-CAN承载上。然而，AF需要关注的不一定是整个会话中的所有IP流，可能仅仅是某些IP流，比如AF仅关注如图2所示IP流1的中断情况(这将导致业务中止)，而不关注如图2所示的其他IP流。使用现有的机制，PCRF必须指示PCEF上报该会话中所有IP-CAN承载中断情况。如果IP-CAN承载2中断，PCEF上报给PCRF后，PCRF也需要向AF上报。实际上AF不需要这些信息，这就导致PCEF和PCRF之间、PCRF和AF之间出现冗余的消息交互，增加了三个设备之间不必要的负载。
其次，由于PCRF向AF上报时使用Flows AVP描述影响的IP流，从Flows AVP的定义可以看出最多只能定位到媒体子流，对于媒体子流中包含双向IP流的情况，无法区分上报的事件针对的是上行流、下行流还是针对两者。
还有，AF只能在建立与PCRF之间的Diameter会话的第一个请求消息中请求PCRF上报事件，之后便无法改变，导致AF不能根据会话过程中业务的变更情况(比如增加删除媒体流等等)增加删除检测事件，或者修改事件的检测范围。
另外，由于事件检测只能针对一个会话，所以当AF只需要检测信令流相关的事件时，为避免在非信令流上检测上报事件，只能与PCRF建立一个单独的Diameter会话用于信令流相关的事件检测上报，这样导致AF与PCRF之间需要维护多个Diameter会话，造成AF和PCRF资源浪费。PCRF需要重复地将Rx参考点的Diameter会话与IP-CAN会话关联，同时也造成AF和PCRF之间Diameter消息量增加(比如结束Diameter会话的消息变为两倍)。
发明内容
有鉴于此，本发明实施例的主要目的是提出一种检测承载事件的方法，以降低冗余的消息交互。
本发明实施例的另一目的是提出一种检测承载事件的***，以降低冗余的消息交互。
本发明实施例的再一目的是提出一种AF，以降低冗余的消息交互。
本发明实施例的另一目的是提出一种PCRF，以降低冗余的消息交互。
为达到上述目的，本发明实施例的技术方案是这样实现的：
一种检测承载事件的方法，该方法包括：
应用层功能实体AF向策略控制和计费规则功能实体PCRF发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
PCRF在每一事件类型的事件检测范围内检测该种类型的事件，并向AF返回所检测到事件的事件类型及该检测到事件的影响范围。
一种检测承载事件的***，该***包括AF和PCRF，其中：
AF，用于向PCRF发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
PCRF，用于在每一事件类型的事件检测范围内检测该种类型的事件，并向AF返回所检测到事件的事件类型及该检测到事件的影响范围。
一种AF，该AF包括承载事件检测请求发送单元和事件处理单元，其中：
承载事件检测请求发送单元，用于向PCRF发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
事件处理单元，用于在收到由PCRF所检测到事件的事件类型及该检测到事件的影响范围后，根据应用层策略对事件进行处理。
一种PCRF，该PCRF包括事件检测单元和检测结果返回单元，其中：
事件检测单元，用于接收由AF发送的承载事件检测请求，并在每一事件类型的事件检测范围内检测该种类型的事件，其中所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
检测结果返回单元，用于向AF返回所检测到事件的事件类型及该检测到事件的影响范围。
从上述技术方案中可以看出，在本发明实施例中，AF请求PCRF检测上报事件时，指明检测的事件类型范围和检测范围，检测范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合，不同事件的检测范围可以不同。PCRF根据AF的请求，和PCEF配合在AF指定的范围内检测AF指定的事件，检测到相应事件后，PCRF向AF上报事件的类型和事件的影响范围，其中影响范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合。由此可见，应用本发明以后，解决了现有机制中由事件检测粒度过大(只能是整个Diameter会话)所导致的不必要消息交互、事件影响范围指示不明确(最小只能到媒体子流，不能指示IP流)的问题，因此能够显著地降低冗余的消息交互。同时，还解决了现有的事件检测上报机制使用不灵活的问题(只能在AF发送给PCRF的第一个请求消息中指定，后续不能修改)的问题。
另外，在本发明实施例中，在AF与PCRF之间的Diameter会话的整个生命周期内，AF都可以请求PCRF检测上报事件，可以请求增加、删除、修改上报事件，可以在AF发送给PCRF的请求消息，例如鉴权授权请求消息(Auth-Authorization-Request，AAR)中指示，也可以在AF应答PCRF的响应消息，例如重新鉴权授权应答消息(Re-Auth-Answer，RAA)中指示，因此实际操作起来更加灵活。
此外，还可以将本发明实施例应用到信令路径状态检测中，无需建立单独的Diameter会话，从而还可以节省AF和PCRF的资源。
附图说明
图1为现有技术中PCC结构的示意图；
图2为IP流、PCC规则、IP-CAN承载、IP-CAN会话之间的对应关系示意图；
图3为根据本发明实施例的检测承载事件的方法流程示意图；
图4为根据本发明第一实施例的检测承载事件的方法流程示意图；
图5为根据本发明第二实施例的检测承载事件的方法流程示意图；
图6为根据本发明实施例的检测承载事件的***结构示意图；
图7为根据本发明实施例的AF结构示意图；
图8为根据本发明实施例的PCRF结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点表达得更加清楚明白，下面结合附图及具体实施例对本发明再作进一步详细的说明。
图3为根据本发明实施例的检测承载事件的方法流程示意图。如图3所示，该方法包括：
步骤301：AF向PCRF发送承载事件检测请求，承载事件检测请求中包含事件检测类型范围以及对应于事件检测类型范围中每一事件类型的事件检测范围。
其中，所述事件检测范围可以为整个Diameter会话，或者媒体流、媒体子流和IP流的任意组合。并且，事件检测类型范围可以包括所有事件类型，或者包括至少一个特定的事件类型。
在这里，AF请求PCRF检测上报事件时，指明需要检测的事件类型和检测范围，其中不同类型事件的检测范围可以不同。
步骤302：PCRF在每一事件类型的事件检测范围内检测该种类型的事件，并向AF返回所检测到事件的事件类型及该检测到事件的影响范围。
在这里，PCRF根据AF的请求，和PCEF配合在AF指定的范围内检测AF指定的事件，检测到相应事件后，PCRF向AF上报事件的类型和事件的影响范围，影响范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合。
其中，事件检测类型范围中各事件检测类型的事件检测范围并不相同，并且各检测到事件的影响范围也并不相同；或所述事件检测类型范围中各事件检测类型的事件检测范围相同，并且各检测到事件的影响范围也相同；或所述事件检测类型范围中各事件检测类型的事件检测范围并不相同，并且各检测到事件的影响范围相同；或所述事件检测类型范围中各事件检测类型的事件检测范围相同，并且各检测到事件的影响范围并不相同。
另外，在AF与PCRF之间的Diameter会话的整个生命周期内，AF都可以请求PCRF检测上报事件，可以请求增加、删除、修改上报事件，可以在AF发送给PCRF的请求消息(比如AAR)中指示，也可以在AF应答PCRF的响应消息(比如RAA)中指示。
具体地：比如，当需要增加取消检测上报的事件类型时，AF可以进一步向PCRF发送取消承载事件检测请求，所述取消承载事件检测请求中包含取消检测事件类型范围以及对应于所述取消检测事件类型范围中每一事件类型的事件检测范围；PCRF在每一取消检测事件类型的事件检测范围内，取消检测该种类型的事件。
可选地，当需要增加检测上报的事件类型时，AF可以还可以向PCRF发送增加承载事件检测请求，所述增加承载事件检测请求中包含增加检测事件类型范围以及对应于所述增加检测事件类型范围中每一事件类型的事件检测范围；PCRF在每一增加检测事件类型的事件检测范围内，检测该种类型的事件，并向AF返回所检测到事件的事件类型及该检测到事件的影响范围。
当需要修改检测上报的事件类型和检测范围时，AF可以向PCRF发送修改承载事件检测请求，所述修改承载事件检测请求中包含待修改的检测事件类型范围以及对应于所述待修改检测事件类型范围中每一事件类型的待修改事件检测范围；PCRF在每一待修改检测事件类型的待修改事件检测范围内，检测该种类型的事件，并向AF返回所检测到事件的事件类型及该检测到事件的影响范围。
还可以将本发明用于信令路径状态检测。为避免和媒体流的Media-Component-Number冲突，信令流的Media-Component-Number可以为0或者特殊的数字(比如0xFFFFFFFF)。Flow-Number AVP由AF指定，信令流由Flow-Description AVP描述，这样信令流的事件检测上报和媒体流的事件检测上报一致，无需为信令路径状态检测建立新的Diameter会话。
AF可以在请求消息中请求PCRF检测上报事件。图4为根据本发明第一实施例的检测承载事件的方法流程示意图。
如图4所示，该方法包括：
步骤401：AF向PCRF发送请求消息(比如可以为AAR消息)，请求PCRF检测上报事件，在该请求消息中指明检测的事件类型范围和检测范围，检测范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合，不同事件的检测范围可以相同或者不同。其中，事件类型可以采用通配的方式一次请求检测上报所有事件类型，也可以请求检测上报某个或者某些事件。
步骤402：PCRF向AF返回应答消息(比如为AAA消息)。
步骤403：PCRF根据AF指示和PCEF配合，在AF指定的范围内检测AF指定的事件。
步骤404：PCRF检测到相应事件后，PCRF向AF发送请求消息(如如RAR消息)，上报事件类型和事件的影响范围，影响范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合。PCRF上报时指示的事件影响范围必须在AF请求时指明的检测范围之内。AF指定的检测范围之外发生的事件不上报，AF没有指定的事件类型也不上报。PCRF可以一次上报多个事件，这些事件的影响范围可以相同或者不同。
步骤405：AF向PCRF发送应答消息(比如RAA消息)；
步骤406：AF根据应用层的策略和上报的事件，采取相应的措施(比如拆除业务、通过信令修改业务等)。
AF还可以在应答消息中请求PCRF检测上报事件。图5为根据本发明第二实施例的检测承载事件的方法流程示意图。
如图5所示，该方法包括：
步骤501：PCRF向AF发送请求消息(比如RAR消息)。
步骤502：AF向PCRF返回应答消息(比如RAA消息)，请求PCRF检测上报事件，消息中指明检测的事件类型范围和检测范围，检测范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合，不同事件的检测范围可以不同。其中事件类型可以采用通配的方式一次请求检测上报所有事件类型，也可以请求检测上报某个或者某些事件。
步骤503：PCRF根据AF指示，和PCEF配合，在AF指定的范围内检测AF指定的事件。
步骤504：PCRF检测到相应事件后，PCRF向AF发送请求消息(比如RAR消息)，上报事件类型和事件的影响范围，影响范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合。PCRF上报时指示的事件影响范围必须在AF请求时指明的检测范围之内。AF指定的检测范围之外发生的事件不上报，AF没有指定的事件类型也不上报。PCRF可以一次上报多个事件，这些事件的影响范围可以相同或者不同；
步骤505：AF向PCRF发送应答消息(比如RAA消息)；
步骤506：AF根据应用层的策略和上报的事件，采取相应的措施(比如拆除业务、通过信令修改业务等)。
目前，AF和PCRF之间的协议通常为Diameter协议。下面以Diameter协议为例，对本发明进行详细阐述。然而，本领域技术人员可以意识到，本发明并不局限于Diameter协议。
方式一：
首先对现有的AVP进行扩展(包括定义几个新的AVP和为现有的AVP定义新的值)：
1.IP-Flows AVP
IP-Flows::＝<AVP Header:x>
{Media-Component-Number}
*[Flow-Number]
[Direction]
IP-Flows AVP是新定义的AVP。这个AVP用于定位一个或者多个IP流，其中Direction为枚举类型，取值可以为UPLINK(0，上行)、DOWNLINK(1，下行)、BOTH(2，双向)。{...}表示比选参数，[...]表示可选参数，*表示可以有多个(后续采用相同的规则)。Flow-Number不出现表示针对Media-Component-Number对应的媒体流中的所有媒体子流，Direction不出现表示包含上行流和下行流。
2.Specific-Action AVP
Specific-Action AVP是现有的AVP，不过不再直接用于AF请求PCRF检测上报事件，也不直接用于PCRF向AF上报事件，只用于定义各种事件类型，在原有取值基础上定义一个新的枚举值：ALL，表示通配所有事件类型，ALL只能用于AF发送给PCRF的消息中。
3.IP-Flows-Specific-Action AVP
IP-Flows-Specific-Action::＝<AVP Header:x>
*{Specific-Action}
*[IP-Flows]
IP-Flows-Specific-Action AVP是新定义的AVP，将事件和IP流绑定在一起，IP-Flows不出现表示事件是针对整个Diameter。
4.Operation-Type AVP
IP-Flows-Specific-Action AVP是新定义的AVP，枚举类型，取值为ADD(0，增加)、REMOVE(1，删除)、UPDATE(2，更新)，用于AF指示PCRF对IP-Flows-Specific-Action的操作方式。其中ADD可用于增加新的事件类型或者增大已经请求上报的事件的检测范围，REMOVE用于删除已经请求上报的事件类型或者减小已经请求上报的事件的检测范围，UPDATE用于删除原来所有请求上报的事件，用新消息中的事件替换。
5.IP-Flows-Specific-Action-Operation AVP
IP-Flows-Specific-Action-Operation::＝<AVP Header:x>
{Operation-Type}
*[IP-Flows-Specific-Action}
IP-Flows-Specific-Action-Operation AVP是新定义的AVP，用于AF向PCRF增加、删除、更新上报检测事件。
AF请求上报PCRF检测上报事件时，只需在发送给PCRF的请求消息(如AAR)或者应答消息(如RAA)中包含一个或者多个IP-Flows-Specific-Action-Operation AVP，多个检测范围相同的事件可以包含在同一个IP-Flows-Specific-Action-Operation AVP中。如果某个或者某些事件的检测范围是整个Diameter会话，则对应的IP-Flows-Specific-Action AVP不包含IP-Flows AVP，否则对应的IP-Flows-Specific-Action AVP可以包含一个或者多个IP-Flows AVP以指示事件检测范围(媒体流、媒体子流和IP流的任意组合)。AF采用不同的Operation-Type可以灵活地增加、删除、修改、更新上报事件。
PCRF向AF上报事件时，只需在发送给AF的请求消息(如RAR)或者应答消息(如AAA)中包含一个或者多个IP-Flows-Specific-Action AVP就可以灵活地向AF上报事件，多个影响范围相同的事件可以包含在同一个IP-Flows-Specific-Action-Operation AVP中。如果某个或者某些事件的影响范围是整个Diameter会话，则对应的IP-Flows-Specific-Action AVP不包含IP-Flows AVP，否则对应的IP-Flows-Specific-Action AVP可以包含一个或者多个IP-Flows AVP以指示事件的影响范围(媒体流、媒体子流和IP流的任意组合)。
这种方案对现有机制改动较大，好处是十分灵活方便，
方式二：
首先对现有的AVP进行扩展(包括定义几个新的AVP和为现有的AVP定义新的值)：
1.Flows AVP
Flows::＝<AVP Header:x>
{Media-Component-Number}
*[Flow-Number]
[Direction]
Flows AVP是现有的AVP，在原来的基础上增加了Direction AVP，以便可以定位到一个IP流。Direction为枚举类型，取值可以为UPLINK(0，上行)、DOWNLINK(1，下行)、BOTH(2，双向)。Flow-Number不出现表示针对Media-Component-Number对应的媒体流中的所有媒体子流，Direction不出现表示包含上行流和下行流。
2.Specific-Action AVP
Specific-Action AVP是现有的AVP，仍可用于AF向PCRF请求上报事件以及PCRF向AF上报事件，定义两个新的枚举值：DETECT_ALL和REMOVE_ALL，其中DETECT_ALL表示AF请求PCRF检测上报所有事件，REMOVE_ALL表示AF请求PCRF取消检测上报所有事件，这两个新定义的值都只能用于AF发送给PCRF的消息中。
AF请求上报PCRF检测上报事件时，只需在发送给PCRF的请求消息(如AAR)或者应答消息(如RAA)中包含一个或者多个Specific-ActionAVP，事件检测范围是整个Diameter会话时Diameter消息中不携带FlowsAVP，否则可以携带一个或者多个Flows AVP以指示影响范围(媒体流、媒体子流和IP流的任意组合)。新下发的Specific-Action AVP在原有基础上叠加，需要删除某个或者某些事件上报时，可以在消息中包含多个Specific-Action AVP，其中第一个的值为REMOVE_ALL，取消之前请求上报的事件，后续的Specific-Action指示需要保留的上报事件。需要全部取消时，只需在Diameter消息中携带一个Specific-Action AVP，值为REMOVE_ALL。
PCRF向AF上报事件时，只需在发送给AF的请求消息(如RAR)或者应答消息(如AAA)中包含一个或者多个Specific-Action AVP，事件影响范围是整个Diameter会话时消息中不携带Flows AVP，否则可以携带一个或者多个Flows AVP以指示影响范围(媒体流、媒体子流和IP流的任意组合)。
这种方案的优点是对现有机制改动较小。
方式三：
首先对现有的AVP进行扩展(包括定义几个新的AVP和为现有的AVP定义新的值)：
1.Flows AVP
Flows::＝<AVP Header:x>
{Media-Component-Number}
*[Flow-Number]
[Direction]
Flows AVP是现有的AVP，在原来的基础上增加了Direction AVP，以便可以定位到一个IP流。Direction为枚举类型，取值可以为UPLINK(0，上行)、DOWNLINK(1，下行)、BOTH(2，双向)。Flow-Number不出现表示针对Media-Component-Number对应的媒体流中的所有媒体子流，Direction不出现表示包含上行流和下行流。
2.Specific-Action AVP
Specific-Action AVP是现有的AVP，仍可用于AF向PCRF请求上报事件以及PCRF向AF上报事件，定义两个新的枚举值：DETECT_ALL和REMOVE_ALL，其中DETECT_ALL表示AF请求PCRF检测上报所有事件，REMOVE_ALL表示AF请求PCRF取消检测上报所有事件，这两个新定义的值都只能用于AF发送给PCRF的消息中。
3.Media-Component-Description AVP
Media-Component-Description AVP是现有的AVP，增加参数Specific-Action AVP，用于AF向PCRF请求检测上报事件时指示检测范围是媒体流的事件。
4.Media-Sub-Component AVP
Media-Sub-Component AVP是现有的AVP，增加参数Specific-ActionAVP，用于AF向PCRF请求检测上报事件时指示检测范围是媒体子流的事件。
方式三中，AF向PCRF请求检测上报事件时，可以在同一个Diameter消息中通过在Media-Component-Description AVP和/或Media-Sub-Component AVP中包含不同的Specific-Action AVP请求PCRF上报检测范围不同的事件，其他方面和方式二相同。
方式四：
首先对现有的AVP进行扩展(包括定义几个新的AVP和为现有的AVP定义新的值)：
1.Flows AVP
Flows::＝<AVP Header:x>
{Media-Component-Number}
*[Flow-Number]
[Direction]
Flows AVP是现有的AVP，在原来的基础上增加了Direction AVP，以便可以定位到一个IP流。Direction为枚举类型，取值可以为UPLINK(0，上行)、DOWNLINK(1，下行)、BOTH(2，双向)。Flow-Number不出现表示针对Media-Component-Number对应的媒体流中的所有媒体子流，Direction不出现表示包含上行流和下行流。
2.Specific-Action AVP
Specific-Action AVP是现有的AVP，不过不再直接用于AF请求PCRF上报事件，也不直接用于PCRF向AF上报事件，只用于定义各种事件类型。定义两个新的枚举值：DETECT_ALL和REMOVE_ALL，其中DETECT_ALL表示AF请求PCRF检测上报所有事件，REMOVE_ALL表示AF请求PCRF取消检测上报所有事件，这两个新定义的值都只能用于AF发送给PCRF的消息中。
3.IP-Flows-Specific-Action AVP
IP-Flows-Specific-Action::＝<AVP Header:x>
*{Specific-Action}
*[IP-Flows]
IP-Flows-Specific-Action AVP是新定义的AVP，将事件和IP流绑定在一起，IP-Flows不出现表示事件是针对整个Diameter。
AF请求上报PCRF检测上报事件时，只需在发送给PCRF的请求消息(如AAR)或者应答消息(如RAA)中包含一个或者多个IP-Flows-Specific-Action AVP，如果其中某个事件的检测范围是整个Diameter会话，则对应的IP-Flows-Specific-Action AVP不包含Flows AVP，否则对应的IP-Flows-Specific-Action AVP可以包含一个或者多个Flows AVP以指示事件检测范围(媒体流、媒体子流和IP流的任意组合)。新下发的Specific-Action AVP在原有基础上叠加，需要删除某个或者某些事件上报时，可以在消息中包含多个IP-Flows-Specific-Action AVP，其中第一个IP-Flows-Specific-Action中Specific-Action的值为REMOVE_ALL，取消之前请求上报的事件，后续的IP-Flows-Specific-Action指示需要保留的事件上报。需要全部取消时，只需在Diameter消息中携带一个IP-Flows-Specific-Action AVP，其Specific-Action的值为REMOVE ALL。
PCRF向AF上报事件时，只需在发送给AF的请求消息(如RAA)或者应答消息(如AAA)中包含一个或者多个IP-Flows-Specific-Action AVP就可以灵活地向AF上报事件，如果其中某个事件的影响范围是整个Diameter会话，则对应的IP-Flows-Specific-Action AVP不包含Flows AVP，否则对应的IP-Flows-Specific-Action AVP可以包含一个或者多个Flows AVP以指示事件的影响范围(媒体流、媒体子流和IP流的任意组合)。
图6为根据本发明实施例的检测承载事件的***结构示意图。如图6所示，该***包括AF 601和PCRF 602，其中：
AF 601，用于向PCRF 602发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
PCRF 602，用于在每一事件类型的事件检测范围内检测该种类型的事件，并向AF 601返回所检测到事件的事件类型及该检测到事件的影响范围。
其中，AF 601，可以进一步用于向PCRF 602发送取消承载事件检测请求，所述取消承载事件检测请求中包含取消检测事件类型范围以及对应于所述取消检测事件类型范围中每一事件类型的取消事件检测范围；
PCRF 602，进一步用于在每一取消检测事件类型的取消事件检测范围内，取消检测该种类型的事件。
AF 601，可以进一步用于向PCRF 602发送增加承载事件检测请求，所述增加承载事件检测请求中包含增加检测事件类型范围以及对应于所述增加检测事件类型范围中每一事件类型的事件检测范围；
PCRF 602，可以进一步用于在每一增加检测事件类型的事件检测范围内，检测该种类型的事件，并向AF 601返回所检测到事件的事件类型及该检测到事件的影响范围。
AF 601，可以进一步用于向PCRF 602发送修改承载事件检测请求。所述修改承载事件检测请求中包含待修改的检测事件类型范围以及对应于所述待修改检测事件类型范围中每一事件类型的待修改事件检测范围；
PCRF 602，进一步用于在每一待修改检测事件类型的待修改事件检测范围内，检测该种类型的事件，并向AF 601返回所检测到事件的事件类型及该检测到事件的影响范围。
AF 601，可以通过AAR消息或者RAA消息向PCRF 602发送承载事件检测请求。PCRF 602，可以通过RAR消息或AAA消息向AF 601返回所检测到事件的事件类型及该检测到事件的影响范围。AF 601，还可以进一步用于在收到检测到事件的事件类型及该检测到事件的影响范围后，根据应用层策略对事件进行处理。
图7为根据本发明实施例的AF结构示意图。
如图7所示，该AF包括承载事件检测请求发送单元701和事件处理单元702，其中：
承载事件检测请求发送单元701，用于向PCRF发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围。
事件处理单元702，用于在收到由PCRF所检测到事件的事件类型及该检测到事件的影响范围后，根据应用层策略对事件进行处理。
图8为根据本发明实施例的PCRF结构示意图。
如图8所示，该PCRF包括事件检测单元801和检测结果返回单元802。
事件检测单元801，用于接收由AF发送的承载事件检测请求，并在每一事件类型的事件检测范围内检测该种类型的事件，其中所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围。
检测结果返回单元802，用于向AF返回所检测到事件的事件类型及该检测到事件的影响范围。
综上所述，本发明实施例首先提供一种AF检测承载事件的方法。
在这种AF检测承载事件的方法中，AF请求PCRF检测上报事件时，指明检测的事件类型和检测范围，检测范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合，不同事件的检测范围可以相同或者不同，其中事件类型可以采用通配的方式一次请求检测上报所有事件类型，也可以请求检测上报某个或者某些事件；PCRF再根据AF的请求，和PCEF配合在AF指定的范围内检测AF指定的事件。检测到相应事件后，PCRF向AF上报事件类型和影响范围，影响范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合，其中PCRF上报时指示的事件影响范围必须在AF请求时指明的检测范围之内，AF指定的检测范围之外发生的事件不上报，AF没有指定的事件类型也不上报。
PCRF可以一次上报多个事件，这些事件的影响范围可以相同或者不同。
AF还可以根据应用层的策略和上报的事件，采取相应的措施(比如拆除业务、通过信令修改业务等)。
AF请求PCRF检测上报事件之后，可以请求PCRF取消上报承载事件，指明取消检测的事件类型和检测范围，检测范围可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合。其中事件类型可以采用通配的方式一次取消检测上报所有事件类型，也可以取消检测上报某个或者某些事件。AF取消上报事件时的检测范围可以比之前请求上报事件时指示的检测范围更大(比如请求在某个媒体流上上报某个事件后，请求在整个会话上取消上报该事件，在该媒体流上当然也取消了)、更小(比如请求在整个Diameter会话上报某个事件后，请求在某个媒体流上取消上报该事件，表示在其他媒体流上继续检测上报该事件)，也可以相等。
AF请求PCRF检测上报事件之后，可以请求PCRF增加检测上报承载事件，对于已经请求PCRF检测上报的事件AF可以请求修改检测承载事件的范围(增大、缩小)。
AF请求PCRF检测上报事件之后，可以请求PCRF更新检测上报的事件类型和检测范围，即直接用新消息中携带的上报事件类型和检测范围替换之前的请求。
在AF与PCRF之间的Diameter会话的整个生命周期内，AF都可以请求PCRF上报事件，也可以请求增加、取消、修改上报事件，可以在AF发送给PCRF的请求消息(比如AAR)中指示，也可以在AF应答PCRF的响应消息(比如RAA)中指示。
PCRF向AF上报事件时，可以在PCRF发送给AF的请求消息(比如RAR)中指示，也可以在PCRF应答AF的响应消息(比如AAA)中指示。
通过本发明实施例的方法，AF可以随时请求PCRF上报某些事件，也可以取消检测上报某些事件、增加检测上报其他事件、或者修改事件的检测范围。事件的检测粒度可以是整个Diameter会话或者媒体流、媒体子流和IP流的任意组合。从而解决了现有机制事件检测粒度过大(只能是整个Diameter会话)导致的不必要的消息交互、事件影响范围指示不明确(最小只能到媒体子流，不能指示IP流)的问题，同时也解决了现有的事件检测上报机制使用不灵活的问题(只能在AF发送给PCRF的第一个请求消息中指定，后续不能修改)。
同时本发明实施中描述的机制也可以用于信令路径状态检测，为避免和媒体流的Media-Component-Number冲突，信令流的Media-Component-Number可以为0或者特殊的数字(比如0xFFFFFFFF)，Flow-Number AVP由AF指定(可以根据端口号等的大小排序)，信令流也可以由Flow-Description AVP描述，这样信令流的事件检测上报和媒体流的事件检测上报一致，不需要为信令路径状态检测建立新的Diameter会话。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (20)
1、一种检测承载事件的方法，其特征在于，该方法包括：
应用层功能实体向策略控制和计费规则功能实体发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
策略控制和计费规则功能实体在每一事件类型的事件检测范围内检测该种类型的事件，并向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围。
2、根据权利要求1所述的检测承载事件的方法，其特征在于，所述事件检测范围为整个Diameter会话，或者媒体流、媒体子流和IP流的任意组合。
3、根据权利要求1所述的检测承载事件的方法，其特征在于，所述影响范围为整个Diameter会话，或者媒体流、媒体子流和IP流的任意组合。
4、根据权利要求1所述的检测承载事件的方法，其特征在于，所述事件检测类型范围包括所有事件类型，或者包括至少一个特定的事件类型。
5、根据权利要求1所述的检测承载事件的方法，其特征在于，该方法进一步包括：
应用层功能实体向策略控制和计费规则功能实体发送取消承载事件检测请求，所述取消承载事件检测请求中包含取消检测事件类型范围以及对应于所述取消检测事件类型范围中每一事件类型的事件检测范围；
策略控制和计费规则功能实体在每一取消检测事件类型的事件检测范围内，取消检测该种类型的事件。
6、根据权利要求1所述的检测承载事件的方法，其特征在于，该方法进一步包括：
应用层功能实体向策略控制和计费规则功能实体发送增加承载事件检测请求，所述增加承载事件检测请求中包含增加检测事件类型范围以及对应于所述增加检测事件类型范围中每一事件类型的事件检测范围；
策略控制和计费规则功能实体在每一增加检测事件类型的事件检测范围内，检测该种类型的事件，并向应用层功能实体返回所增加检测到事件的事件类型及该增加检测到事件的影响范围。
7、根据权利要求1所述的检测承载事件的方法，其特征在于，该方法进一步包括：
应用层功能实体向策略控制和计费规则功能实体发送修改承载事件检测请求，所述修改承载事件检测请求中包含待修改的检测事件类型范围以及对应于所述待修改检测事件类型范围中每一事件类型的待修改事件检测范围；
策略控制和计费规则功能实体在每一待修改检测事件类型的待修改事件检测范围内，检测该种类型的事件，并向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围。
8、根据权利要求1-7中任一项所述的检测承载事件的方法，其特征在于，所述事件检测范围为信令流，其中信令流的Media-Component-Number为0或者特殊的数字，Flow-Number AVP由应用层功能实体指定，信令流由Flow-Description AVP描述。
9、根据权利要求1所述的检测承载事件的方法，其特征在于，应用层功能实体通过鉴权授权请求消息向策略控制和计费规则功能实体发送承载事件检测请求，或者应用层功能实体通过重新鉴权授权应答消息向策略控制和计费规则功能实体发送承载事件检测请求。
10、根据权利要求1所述的检测承载事件的方法，其特征在于，策略控制和计费规则功能实体通过重新鉴权授权请求消息向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围，或者策略控制和计费规则功能实体通过鉴权授权请求消息向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围。
11、根据权利要求1所述的检测承载事件的方法，其特征在于，所述事件检测类型范围中各事件检测类型的事件检测范围并不相同，并且各检测到事件的影响范围也并不相同；或
所述事件检测类型范围中各事件检测类型的事件检测范围相同，并且各检测到事件的影响范围也相同；或
所述事件检测类型范围中各事件检测类型的事件检测范围并不相同，并且各检测到事件的影响范围相同；或
所述事件检测类型范围中各事件检测类型的事件检测范围相同，并且各检测到事件的影响范围并不相同。
12、一种检测承载事件的***，其特征在于，该***包括应用层功能实体和策略控制和计费规则功能实体，其中：
应用层功能实体，用于向策略控制和计费规则功能实体发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
策略控制和计费规则功能实体，用于在每一事件类型的事件检测范围内检测该种类型的事件，并向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围。
13、根据权利要求12所述的检测承载事件的***，其特征在于，
应用层功能实体，进一步用于向策略控制和计费规则功能实体发送取消承载事件检测请求，所述取消承载事件检测请求中包含取消检测事件类型范围以及对应于所述取消检测事件类型范围中每一事件类型的取消事件检测范围；
策略控制和计费规则功能实体，进一步用于在每一取消检测事件类型的取消事件检测范围内，取消检测该种类型的事件。
14、根据权利要求12所述的检测承载事件的***，其特征在于，
应用层功能实体，进一步用于向策略控制和计费规则功能实体发送增加承载事件检测请求，所述增加承载事件检测请求中包含增加检测事件类型范围以及对应于所述增加检测事件类型范围中每一事件类型的事件检测范围；
策略控制和计费规则功能实体，进一步用于在每一增加检测事件类型的事件检测范围内，检测该种类型的事件，并向应用层功能实体返回所增加检测到事件的事件类型及该增加检测到事件的影响范围。
15、根据权利要求12所述的检测承载事件的***，其特征在于
应用层功能实体，进一步用于向策略控制和计费规则功能实体发送修改承载事件检测请求，所述修改承载事件检测请求中包含待修改的检测事件类型范围以及对应于所述待修改检测事件类型范围中每一事件类型的待修改事件检测范围；
策略控制和计费规则功能实体，进一步用于在每一待修改检测事件类型的待修改事件检测范围内，检测该种类型的事件，并向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围。
16、根据权利要求12所述的检测承载事件的***，其特征在于，
应用层功能实体，用于通过鉴权授权请求消息或者重新鉴权授权应答消息向策略控制和计费规则功能实体发送承载事件检测请求。
17、根据权利要求12所述的检测承载事件的***，其特征在于，
策略控制和计费规则功能实体，用于通过重新鉴权授权请求消息或鉴权授权请求消息向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围。
18、根据权利要求12所述的检测承载事件的***，其特征在于，
应用层功能实体，进一步用于在收到检测到事件的事件类型及该检测到事件的影响范围后，根据应用层策略对事件进行处理。
19、一种应用层功能实体，其特征在于，该应用层功能实体包括承载事件检测请求发送单元和事件处理单元，其中：
承载事件检测请求发送单元，用于向策略控制和计费规则功能实体发送承载事件检测请求，所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
事件处理单元，用于在收到由策略控制和计费规则功能实体所检测到事件的事件类型及该检测到事件的影响范围后，根据应用层策略对事件进行处理。
20、一种策略控制和计费规则功能实体，其特征在于，该策略控制和计费规则功能实体包括事件检测单元和检测结果返回单元，其中：
事件检测单元，用于接收由应用层功能实体发送的承载事件检测请求，并在每一事件类型的事件检测范围内检测该种类型的事件，其中所述承载事件检测请求中包含事件检测类型范围以及对应于所述事件检测类型范围中每一事件类型的事件检测范围；
检测结果返回单元，用于向应用层功能实体返回所检测到事件的事件类型及该检测到事件的影响范围。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710102006XA CN101296094B (zh) | 2007-04-26 | 2007-04-26 | 检测承载事件的方法、***和装置 |
| PCT/CN2008/070762 WO2008131674A1 (fr) | 2007-04-26 | 2008-04-22 | Procédé, système et dispositif servant à examiner un événement de transport |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710102006XA CN101296094B (zh) | 2007-04-26 | 2007-04-26 | 检测承载事件的方法、***和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101296094A true CN101296094A (zh) | 2008-10-29 |
| CN101296094B CN101296094B (zh) | 2011-02-16 |
Family
ID=39925205
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200710102006XA Expired - Fee Related CN101296094B (zh) | 2007-04-26 | 2007-04-26 | 检测承载事件的方法、***和装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101296094B (zh) |
| WO (1) | WO2008131674A1 (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009067918A1 (fr) * | 2007-11-28 | 2009-06-04 | Huawei Technologies Co., Ltd. | Procede, systeme et entite fonctionnelle d'optimisation de flux de paquets permettant la detection d'evenements d'application |
| WO2017133611A1 (zh) * | 2016-02-02 | 2017-08-10 | 上海交通大学 | 多媒体***信息交互机制及网络传输方法 |
| CN107135184A (zh) * | 2016-02-26 | 2017-09-05 | 上海交通大学 | 一种多媒体***中信息交互机制及网络传输方法 |
| CN107800544A (zh) * | 2016-08-30 | 2018-03-13 | 中兴通讯股份有限公司 | 用户位置信息处理方法和装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8032792B2 (en) * | 2003-07-11 | 2011-10-04 | Avicode, Inc. | Dynamic discovery algorithm |
| CN1260910C (zh) * | 2004-08-11 | 2006-06-21 | 华为技术有限公司 | 基于分组数据流计费触发事件和重授权事件的处理方法 |
| CN100440890C (zh) * | 2005-12-26 | 2008-12-03 | 华为技术有限公司 | 媒体网关上报终端统计参数值的方法 |
-
2007
- 2007-04-26 CN CN200710102006XA patent/CN101296094B/zh not_active Expired - Fee Related
-
2008
- 2008-04-22 WO PCT/CN2008/070762 patent/WO2008131674A1/zh active Application Filing
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009067918A1 (fr) * | 2007-11-28 | 2009-06-04 | Huawei Technologies Co., Ltd. | Procede, systeme et entite fonctionnelle d'optimisation de flux de paquets permettant la detection d'evenements d'application |
| WO2017133611A1 (zh) * | 2016-02-02 | 2017-08-10 | 上海交通大学 | 多媒体***信息交互机制及网络传输方法 |
| CN107135184A (zh) * | 2016-02-26 | 2017-09-05 | 上海交通大学 | 一种多媒体***中信息交互机制及网络传输方法 |
| CN107135184B (zh) * | 2016-02-26 | 2020-06-12 | 上海交通大学 | 一种多媒体***中信息交互***及网络传输方法 |
| CN111726347A (zh) * | 2016-02-26 | 2020-09-29 | 上海交通大学 | 一种多媒体***中信息交互机制及网络传输方法 |
| CN111726347B (zh) * | 2016-02-26 | 2022-04-15 | 上海交通大学 | 一种多媒体***中信息交互机制及网络传输方法 |
| CN107800544A (zh) * | 2016-08-30 | 2018-03-13 | 中兴通讯股份有限公司 | 用户位置信息处理方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2008131674A1 (fr) | 2008-11-06 |
| CN101296094B (zh) | 2011-02-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2682979C (en) | Method, system and entity of realizing event detection | |
| US9503483B2 (en) | Method and apparatuses for identifying and reporting quality of service rules applicable to a communication session | |
| CN100586071C (zh) | 获取策略和计费执行功能实体能力的方法及设备 | |
| CN101374260B (zh) | Pcc规则和承载关联的实现方法、装置和*** | |
| US8429268B2 (en) | Mechanism for detecting and reporting traffic/service to a PCRF | |
| EP2025106B9 (en) | Devices and method for guaranteeing quality of service per service data flow through the bearer layer | |
| CN101801038B (zh) | 用户会话策略控制方法、装置及*** | |
| US9787850B2 (en) | Method for allowing control of the quality of service and/or of the service fees for telecommunication services | |
| CN102714599A (zh) | 用于动态地控制服务质量的方法和*** | |
| US20150222634A1 (en) | Handling of Authorization Requests For a Packet-Based Service in a Mobile Network | |
| WO2010051853A1 (en) | Policy control apparatus and method for handing over policy control information | |
| CN101959164A (zh) | 删除家乡策略和计费规则功能冗余信息的方法及*** | |
| CN103119981B (zh) | 服务质量控制方法和设备 | |
| CN101141266A (zh) | 策略规则下发方法以及在线计费方法和离线计费方法 | |
| CN105163345A (zh) | 一种区域上报的方法及*** | |
| CN101374338B (zh) | 一种实现用户策略自助服务的方法、实体和*** | |
| CN101296094B (zh) | 检测承载事件的方法、***和装置 | |
| CN101420361A (zh) | 一种会话终止的方法、***及服务器、客户端 | |
| CN101350728A (zh) | 会话绑定的方法及网络设备 | |
| CN101378328A (zh) | 一种应用控制策略的方法、装置及*** | |
| CN101572954B (zh) | 释放会话的方法、装置和*** | |
| CN103024714B (zh) | 一种PCC***中Gx接口会话稽核的方法及装置 | |
| CN102057622A (zh) | 核心网络中改进的信用授权 | |
| CN101378522B (zh) | 分发策略的方法、***和策略分发实体 | |
| CN102123370B (zh) | 一种对用户的访问进行重定向的***及方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110216 |