rfc4006 Diameter Credit-Control Application
最新推荐文章于 2021-07-02 23:54:54 发布
3144
评论 1
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
添加红包
Table of Contents
1. Introduction................................................. 4
1.1. Requirements Language................................. 5
1.2. Terminology........................................... 5
1.3. Advertising Application Support....................... 7
2. Architecture Models.......................................... 7
3. Credit-Control Messages...................................... 9
3.1. Credit-Control-Request (CCR) Command.................. 9
3.2. Credit-Control-Answer (CCA) Command................... 11
4. Credit-Control Application Overview.......................... 11
4.1. Service-Specific Rating Input and Interoperability.... 13
5. Session Based Credit-Control................................. 15
5.1. General Principles.................................... 15
5.2. First Interrogation................................... 21
5.3. Intermediate Interrogation............................ 27
5.4. Final Interrogation................................... 29
[Page 1]
5.5. Server-Initiated Credit Re-Authorization.............. 30
5.6. Graceful Service Termination.......................... 32
5.7. Failure Procedures.................................... 38
6. One Time Event............................................... 41
6.1. Service Price Enquiry................................. 42
6.2. Balance Check......................................... 42
6.3. Direct Debiting....................................... 43
6.4. Refund................................................ 44
6.5. Failure Procedure..................................... 44
7. Credit-Control Application State Machine..................... 46
8. Credit-Control AVPs.......................................... 55
8.1. CC-Correlation-Id AVP................................. 58
8.2. CC-Request-Number AVP................................. 58
8.3. CC-Request-Type AVP................................... 58
8.4. CC-Session-Failover AVP............................... 59
8.5. CC-Sub-Session-Id AVP................................. 59
8.6. Check-Balance-Result AVP.............................. 60
8.7. Cost-Information AVP.................................. 60
8.8. Unit-Value AVP........................................ 61
8.9. Exponent AVP.......................................... 61
8.10. Value-Digits AVP...................................... 61
8.11. Currency-Code AVP..................................... 62
8.12. Cost-Unit AVP......................................... 62
8.13. Credit-Control AVP.................................... 62
8.14. Credit-Control-Failure-Handling AVP................... 62
8.15. Direct-Debiting-Failure-Handling AVP.................. 63
8.16. Multiple-Services-Credit-Control AVP.................. 64
8.17. Granted-Service-Unit AVP.............................. 65
8.18. Requested-Service-Unit AVP............................ 66
8.19. Used-Service-Unit AVP................................. 66
8.20. Tariff-Time-Change AVP................................ 67
8.21. CC-Time AVP........................................... 67
8.22. CC-Money AVP.......................................... 67
8.23. CC-Total-Octets AVP................................... 68
8.24. CC-Input-Octets AVP................................... 68
8.25. CC-Output-Octets AVP.................................. 68
8.26. CC-Service-Specific-Units AVP......................... 68
8.27. Tariff-Change-Usage AVP............................... 68
8.28. Service-Identifier AVP................................ 69
8.29. Rating-Group AVP...................................... 69
8.30. G-S-U-Pool-Reference AVP.............................. 69
8.31. G-S-U-Pool-Identifier AVP............................. 70
8.32. CC-Unit-Type AVP...................................... 70
8.33. Validity-Time AVP..................................... 70
8.34. Final-Unit-Indication AVP............................. 71
8.35. Final-Unit-Action AVP................................. 72
8.36. Restriction-Filter-Rule AVP........................... 72
8.37. Redirect-Server AVP................................... 73
[Page 2]
8.38. Redirect-Address-Type AVP............................. 73
8.39. Redirect-Server-Address AVP........................... 74
8.40. Multiple-Services-Indicator AVP....................... 74
8.41. Requested-Action AVP.................................. 74
8.42. Service-Context-Id AVP................................ 75
8.43. Service-Parameter-Info AVP............................ 76
8.44. Service-Parameter-Type AVP............................ 76
8.45. Service-Parameter-Value AVP........................... 77
8.46. Subscription-Id AVP................................... 77
8.47. Subscription-Id-Type AVP.............................. 77
8.48. Subscription-Id-Data AVP.............................. 78
8.49. User-Equipment-Info AVP............................... 78
8.50. User-Equipment-Info-Type AVP.......................... 78
8.50. User-Equipment-Info-Value AVP......................... 79
9. Result Code AVP Values....................................... 79
9.1. Transient Failures.................................... 79
9.2. Permanent Failures.................................... 80
10. AVP Occurrence Table......................................... 80
10.1. Credit-Control AVP Table.............................. 81
10.2. Re-Auth-Request/Answer AVP Table...................... 82
11. RADIUS/Diameter Credit-Control Interworking Model............ 82
12. IANA Considerations.......................................... 85
12.1. Application Identifier................................ 86
12.2. Command Codes......................................... 86
12.3. AVP Codes............................................. 86
12.4. Result-Code AVP Values................................ 86
12.5. CC-Request-Type AVP................................... 86
12.6. CC-Session-Failover AVP............................... 86
12.7. CC-Unit-Type AVP...................................... 87
12.8. Check-Balance-Result AVP.............................. 87
12.9. Credit-Control AVP.................................... 87
12.10. Credit-Control-Failure-Handling AVP................... 87
12.11. Direct-Debiting-Failure-Handling AVP.................. 87
12.12. Final-Unit-Action AVP................................. 87
12.13. Multiple-Services-Indicator AVP....................... 87
12.14. Redirect-Address-Type AVP............................. 88
12.15. Requested-Action AVP.................................. 88
12.16. Subscription-Id-Type AVP.............................. 88
12.17. Tariff-Change-Usage AVP............................... 88
12.18. User-Equipment-Info-Type AVP.......................... 88
13. Credit-Control Application Related Parameters................ 88
14. Security Considerations...................................... 89
14.1. Direct Connection with Redirects...................... 90
15. References................................................... 91
15.1. Normative References.................................. 91
15.2. Informative References................................ 92
16. Acknowledgements............................................. 93
Appendix A Credit-Control Sequences.............................. 94
[Page 3]
A.1. Flow I................................................ 94
A.2. Flow II............................................... 96
A.3. Flow III.............................................. 98
A.4. Flow IV............................................... 99
A.5. Flow V................................................ 100
A.6. Flow VI............................................... 102
A.7. Flow VII.............................................. 103
A.8. Flow VIII............................................. 105
A.9. Flow IX............................................... 107
Authors' Addresses............................................... 112
Full Copyright Statement......................................... 114
1. Introduction
这个文档描述了针对为用户提供实时信用控制的,基于Diameter协议的应用,例如上网业务,会话初始化(SIP)服务,信息服务,下载服务等.该文档提供了一个针对的实时计费和信用控制的大体解决方案.
预付费模式在GSM网络中应用的很成功了.在GSM网络中,预付费用户有了很大量的增长,同时运用商的收入也有了很大的提高.预付费模式现在已经开始应用到其他服务商了,如无线上网和宽带业务.
在下一代的无线网络中,补充的功能是要求超越Diameter协议中定义的.比如3GPP计费与账单必要条件规定,应用程序必须能实时的估算服务信息. 另外,重要的一点是,在提供服务之前检查账户的余额,并且根据余额给出服务的范围(如流量配额,时间的配额).当一个账户的余额已经消耗尽,或者账户服务期满,这个用户的任何需要付费的事件,都应该被拒绝.
必须提供一个扣税充值请求的通知给用户.另外,例如游戏或者广告应该作为一个信任的用户借款账户.
另外有一些Diameter应用提供对预付费用户的鉴权服务,但不提供信用鉴权服务.信用鉴权应该是不区分服务的,应该在所有支持的预付费的服务中进行信用鉴权.
[Page 4]
为了满足这些需求,必须促进提供服务的网元和信用控制服务器之间的通信.
这份文档主要是对信用鉴权的阐述.不涉及服务等鉴权.
1.1. Requirements Language
在这个文档中,关键词"可能","必须","必须不","可选","建议","应该"还有"不应该"将在[KEYWORDS]中阐述.
1.2. Terminology 术语
AAA Authentication, Authorization, and Accounting 认证,授权,计费
AA 应答
"AA 应答" 主要涉及的是服务的授权和认证的应答."AA 应答"命令被定义在服务指定的用于授权的应用中.
AA 请求
"AA 请求" 通常涉及到一个服务指定的认证和授权的请求. "AA 请求"命令被定义在服务指定的用于授权的应用中.
Credit-control
信用-控制
"信用控制"是一种机制,该机制实时的影响服务使用的账户,控制,或者监控服务使用相关的付费."信用控制"是检查信用是否可用的一个过程. "信用-预留",当完成一个服务后,从一个用户的账户上扣减信用,同时把预留中为使用完的信用归还到用户的账户上.
Diameter Credit-control Server
dcc服务器
一个dcc服务器作为一个预付费的服务器,实施实时计费(计算费用)和信用扣减.dcc服务器必须在一个可以被服务对象或者是"AAA"服务器能访问到的域中,dcc服务器在实时计费中主要负责在服务事件发送给对端用户之前进行"计算价格"和"信用控制".也许还要和商用服务系统交互.
[Page 5]
Diameter Credit-control Client
DCC客户端
DCC客户端是一个和dcc服务器通信的实体.dcc客户端根据DCC服务器给的授权量,监控这些授权的使用情况.
询问
DCC客户端,通过询问的方式初始化一个基于"信用控制"的会话.在"信用控制"过程中,客户端把使用量报告给服务器,同时请求一个新的授权量(配额).每次的询问是一次 请求/应答的交易.
"一次性"事件
总的来说,一次事件类型的请求/应答的交易,就是"一次性"事件.
Rating 费用计算(计费)
The act of determining the cost of the service event.
计算服务事件的费用.
Service(服务)
一个终端用户执行的一次有服务要素的任务.
Service Element(服务节点)
一个对用户提供服务的网元.服务可能包含DCC客户端,或者其他的"信用控制"客户端的实体.后一种情况不在本文档中描述(例如,Netw Access server,SIP Proxy和应用服务器,还有一些信息服务器,内容服务器,和游戏服务器)
Service Event(服务事件)
提供给用户的一个和服务相关的事件.
[Page 6]
Session based credit-control(信用控制的会话)
一个信用控制的过程,包含多次"询问",第一次,第二次 ... 最后一次.第一次"询问"通常是从用户的账户上预留一些钱,同时初始化"信用控制".当服务提供服务的时候,通过中间过程的"询问"申请新的配额(授权量).最后一次"询问"通常是用于退出服务."信用控制"服务器需要维护"信用控制"服务的会话.
1.3. Advertising Application Support(告知应用)
遵循该文档的Diameter协议必须通过CER和CEA命令中的Auth-Application-Id提供告知功能.
2. Architecture Models(结构模式)
在RFC2866中详细阐述了当今的记账模式,但这种模式在Diameter的实时"信用控制"中已经不适用了,在"信用控制"中,在服务初始化之前,信用价值先被确定.还有,目前已有的Diameter授权应用[NASREQ]和[DIAMMIP],仅仅提供服务授权,不提供对预付费用户的信用授权.为了支持实时"信用控制",在AAA基础设施中需要一个新型的服务器:Dcc服务器.Dcc服务器是一个负责预付费用户授权的服务器.
服务通过AAA协议鉴定和批准AAA服务器上的用户;比如 RADIUS或者基于Diameter协议的一些应用.
记账协议主要有RADIUS和基于Diameter协议的,支持在服务建立以后把记账数据发送给记账服务器,同时可能提供服务介绍之前的临时报告.然而,对应实时"信用控制",这些授权和记账模式并不能满足.
当需要实时"信用控制"时,"信用控制"客户端连接"信用控制"客户端,并且把服务事件信息发送给服务端.执行"信用控制"程序确定付费部分并且检查在提供服务时,用户账户余额是否足够扣清所有费用.
[Page 7]
图 1 解释了典型的"信用控制"结构,"信用控制"的结构由植入Dcc客户端的服务单元,Dcc服务器和一个AAA服务器组成.通常会使用一个商业支撑系统,它包含了至少有账单功能.在"信用控制"结构中,"信用控制"服务器和AAA服务器是逻辑实体,实际上可以把他们同时放到一个主机上."信用控制"协议是"信用控制"应用程序的Diameter基础协议.
当一个用户请求(SIP或信息)服务时,请求向前传递到一个用户所注册域的服务单元.在某些情况下这个服务单元也可能是能为用户提供服务的拜访域的服务单元,但,拜访域和用户注册域之间必须有商业协议.网络接入是一个提供拜访域服务的实例,通过AAA基础设施,鉴定和批准拜访用户.
Service Element AAA and CC
+----------+ +---------+ Protocols+-----------+ +--------+
| End |<---->|+-------+|<------------>| AAA | |Business|
| User | +->|| CC || | Server |->|Support |
| | | || Client||<-----+ | | |System |
+----------+ | |+-------+| | +-----------+ | |
| +---------+ | ^ +--------+
+----------+ | | CC Protocol | ^
| End |<--+ | +-----v----+ |
| User | +------>|Credit- | |
+----------+ Credit-Control |Control |--------+
Protocol |Server |
+----------+
图 1: Typical credit-control architecture
在一个负载均衡的系统中可以有多个"信用服务"器,系统中还可以包含分布式计费服务器,账户保存在中心数据库中.为了确保用户的账户在同一次服务事件不被多次借贷,"信用控制"系统应该有查重功能.系统内部的接口可以在账户管理者和服务器之间传递信息.具体的消息结构不在文档范围之内,需要实时者自己定义.
[Page 8]
在"信用控制"服务器和客户端,Diameter是透传的.相关的"信用控制"客户端和服务器的Diameter 重定向代理,允许客户端和服务端直接通信.这些代理很明显是支持Diameter"信用控制"应用程序.在Diameter基础中定义了,Diameter代理不同的作用.具体请查阅section 2.8
如果在Diameter"信用控制"服务器和客户端直接有Diameter"信用控制"代理,他们就通知Diameter"信用控制"应用程序支持.
3. Credit-Control Messages(信用控制消息)
这一章定义了新的Diameter消息(Command-Code)命令码,如果是根据本文给出的Diameter协议编写的应用,必须支持这些命令码,请看下面的命令码列表:
Command-Name Abbrev. Code Reference
-----------------------------------------------------------
Credit-Control-Request CCR 272 3.1
Credit-Control-Answer CCA 272 3.2
在3.2中Diameter基础协议定义了ABNF文档的命令码.
3.1. Credit-Control-Request (CCR) Command(信用控制请求命令)
消息头的command-code字段设置为272,同时command-flag字段的R bit位设置为1,这样的Diameter消息是CCR消息.CCR消息主要用于在一个服务中"信用控制"客户端向服务器申请授权.
Auth-Application-Id必须设置为4,表示是Diameter信用控制应用.
[Page 9]
Message Format(消息格式)
::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
*[ Subscription-Id ]
[ Service-Identifier ]
[ Termination-Cause ]
[ Requested-Service-Unit ]
[ Requested-Action ]
*[ Used-Service-Unit ]
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
*[ Service-Parameter-Info ]
[ CC-Correlation-Id ]
[ User-Equipment-Info ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
[Page 10]
3.2. Credit-Control-Answer (CCA) Command(信用控制应答命令)
消息头中command-code字段设置为272,同时R bit位设置成0,说明是CCA消息.主要用于"信用控制"服务器对"信用控制"客户端发送过来的CCR消息的应答.
Message Format
::= < Diameter Header: 272, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ User-Name ]
[ CC-Session-Failover ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
[ Granted-Service-Unit ]
*[ Multiple-Services-Credit-Control ]
[ Cost-Information]
[ Final-Unit-Indication ]
[ Check-Balance-Result ]
[ Credit-Control-Failure-Handling ]
[ Direct-Debiting-Failure-Handling ]
[ Validity-Time]
*[ Redirect-Host]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ Failed-AVP ]
*[ AVP ]
4. Credit-Control Application Overview(信用控制应用的概述)
信用授权程序需要在为用户提供服务之前和提供服务的过程中被执行,在向服务器发送请求之前,通常要求用户的认证和授权."信用控制"应用支持两种不同的信用授权模式:预留账户上的金额授权和直接借贷授权.在这两种模式中,客户端需要先向"信用控制"服务器发送请求,申请"信用授权",然后才能允许用户使用服务.
[Page 11]
在第一种模式中,"信用控制"服务器计算"请求"的费用,从用户的货币账户上预留适当的金额,并且返回信用资源对应的数量.注意:信用资源不一定是实际的货币信用,信用资源可能是被批准给信用控制客户端度量单元,如流量,时间.
一个成功的信用授权应答的中可能包含了一些信用资源,根据这个应答,信用控制客户端允许用户使用服务,同时会监控授权资源的使用情况,当授权资源已经被消耗,或者是服务已经结束,信用控制客户端把使用量报告给服务器,服务器从用户的账户上扣除本次服务的使用量,如果本次服务还没有结束的话,服务器会计算费用,并在做一次信用预留.这个处理会在基于"信用控制"的会话上的第一次"询问",第二次 ... 最后一次"询问"中完成."信用控制"客户端和服务端都需要维护"信用控制"的状态,在section 5中有对会话的详细描述.
对比,直接借贷的信用授权是单独的交易处理,在这种处理中当"信用控制"服务器接收到信用授权请求时直接从用户的账户上扣除适量的钱,根据一个信用授权成功的应答收据,"信用控制"客户端允许用户使用服务.以上的处理完成了一次事件类型的扣费,但不会维护会话状态.
在一个多服务环境中,一个用户可以在一个服务中,发布一个附加的服务请求.或者在一个激活的多媒体会话中,增加一个额外的媒体类型的到以激活的会话中,这样会向用户的同一个账户同时发送请求.因此,这就需要了解信用资源授权给了哪个服务.
信用控制应用还支持一些可选项,如服务价格查询,用户余额查询,账户充值.以上说的这些都属于"一次性"事件,不维护会话状态.
[Page 12]
灵活的信用控制引用程序对失败情况控制的细节需要定义,主服务提供者可以根据信用风险管理策略规范信用控制客户端的行为.
Credit-Control-Failure-handling AVP 和 Direct-Debiting-Failure-Handling AVP 决定发送给服务器的请求是否被拒绝了.这两个AVP允许灵活的组合,对于事件类型的"直接借贷"可能值是不同的.
4.1. Service-Specific Rating Input and Interoperability(服务特性费用计算输入和合作能力)
Dcc应用,定义了"信用控制"框架,同时提供了常用的支持多种服务的"信用控制"机制.因此"信用控制"不定义专用的作为费用计算使用的Avp.本文中不会列举出某些服务特有使用的Avp.
在"信用控制客户端的提供者和提供扣费,服务提供,漫游合同和计算费用输入,等等的服务器之间需要有一份合同.
因此,Dcc服务器仅仅提供服务给预先同意的Dcc客户端,如"信用控制"消息的内容.自然地,任何一个Dcc客户端都可以和Dcc服务器通交换"信用控制"信息,这样就有可能在CC(Credit-Control)消息中有不支持的Avp,导致服务器拒绝请求,并给一个适合的result-code.
4.1.1. Specifying Rating Input AVPs(指定的计费-费用计算 参数)
有两种方法提供计费参数给CC(Credit-Control)服务器,一是通过多个Avp,二是通过服务参数信息Avp.一般的发送的计费参数原理如下:
[Page 13]
1a. 在Avp符合条件的情况下,服务应该尽可能的使用已存在的基本的Avp.
1b. 如果已存在的Avp不能提供足够的计费信息,可以定义新的Avp.在这种情况下,必须准守[DIABASE]中定义的生成新Avp的步骤.
1c. 对应仅有一个产商履行的服务特性,应该使用Vendor-Specific Avp code(Vendor-Id)标明为私有Avp.而如果一个私有Avp被多个厂商使用,就应该分配一个公开的Avp代替这个私有的Avp,请参考[DIAMBASE].
2. Service-Parameter-Info Avp 可能用于存放从其他编码提取出来的计费信息.如ASN.1 BER.这种方法用于避免对已经存在的数据格式进行不必要的Avp格式转换.这种情况下计费参数被保存到Service-Parameter-Info Avp中.详情参考 section 8.43.
4.1.2. Service-Specific Documentation (服务特性)
服务特性计费参数Avp是指Service-Parameter-Info Avp或者是Service-Context-Id Avp的内容,具体情况不在本文档中描述.为了促进相互协作的能力,建议计费参数和Service-Context-Id遵守RFC或者其他固定的方便的,可查阅的文档.比如,3GPP,OMA和3GPP2.而私有的服务是cc服务器和客户端协商好的内容.在这种情况下,会使用厂商特性Avp.
这份文档和服务特性文档,管理cc消息.服务特性文档定义了现有的和新增的计费参数Avp,所有必须在Dcc客户端发送的Ccr中包含这些Avp,如*[Avp].应该使用 Service-Parameter-Info,把服务特性的内容编码到这个grouped Avp下面.
[Page 14]
Avp标明适用于请求的服务特性文档.具体的服务或者是计费组成的请求是由Service-Context-Id和Service-Identifier作者Rating-Group定义的唯一的标识.
4.1.3. Handling of Unsupported/Incorrect Rating Input(不支持和不正确的计费参数掌控)
Dcc的实施需要必须支持在服务特性文档中定义的计费Avp,[DIAMBASE]中有'M'bit位的必须支持.
如果计费程序需要的计费参数(Ccr中提供的)是不正确的,或者是cc服务器不支持的服务内容(Service-Context-Id中给出的),Cca中必须包含DIAMETER_RATING_FAILED错误码.在Cca中必须把不支持的Avp填到Failed-AVP中(可以是多个).DCC客户端接收到有错误码DIAMETER_RATING_FAILED的应答后,不能再次发送同样的请求给服务端.
4.1.4. RADIUS Vendor-Specific Rating Attributes (RADIUS 厂商特性和计费属性)
当服务特性文档中包含RADIUS 厂商特性属性时(这些属性通常是作为计费参数传递给计费程序),必须遵守在[NASREQ]中描述的Diameter Avp格式的规则.
例如,如果是厂商私有的属性,Avp中的Vendor-Specific必须设置成1,同时Vendor-ID必须设置为IANA厂商的标识.Diameter Avp数据域,仅仅存储RADIUS的属性.
5. Session Based Credit-Control (基于会话的CC(信用控制)
5.1. General Principles (原理概述)
对应一个会话类型的CC,需要多次询问(协商,发多次Ccr):第一次,中间N次和最后一次.在图表2和3中有详细的解释.
如果CC客户端在批准为用户提供服务前,实行"信用预留",就必须多次向服务器"询问".这种情况下,服务器必须维护保持这个CCS(Credit-Control Session)状态.
[Page 15]
每个CCS必须有一个唯一的Session-Id,Session-Id在CCS没有结束之前不能改变.
也许某些应用会要求支持多个CC子会话,这些应用会通过一个固定的Session-Id发送信息,但是会给不同的CC-Sub-Session-Id Avp.如果有多个子会话,每个子会话都必须在主会话结束之前分别的结束.如果没有CC-Sub-Session-Id Avp,说明不存在子会话.
注意,在一个已经建立的会话中,服务节点可能会在授权时间到期之前,发送一个重新授权的信息给AAA服务器.重授权不会影响CC服务器和客户端之间正在进行的授权,信用授权只被授权配额的消耗率控制.
如果服务的重授权失败,用户会被停止服务,同时CC客户端必须发送一个最后的询问给CC服务器.
Dcc服务器可能想要控制授权量或者是中间询问的产品的有效时长,因此Dcc服务器会在发送给客户端的Cca消息中给出一个Validity-Time Avp,Validity-Time的期限,CC客户端必须生成一个CC的更新请求,同时报告使用量给CC服务器,服务器觉得用于消耗授权量的Validity-Time.如果使用Validity-Time Avp,该Avp的值应该作为会话监管定时器(Tcc)的输入值.(详情请参考section 13).因此CC的更新请求是在授权量被耗尽时产生的,或者是在会话中间出现了新的服务事件时产生的,没有提供Validity-Time时,并不是说不需要执行"中间询问".
[Page 16]
5.1.1. Basic Tariff-Time Change Support (费率改变时间)
Dcc服务器和客户端可以选择支持费用标准改变的机制,Dcc服务可以在Cca中给一个Tariff-time-Change Avp.注意,授权量应该分配在马上就要发生费用标准改变的时候,因此报告的所有的使用量可能不会超过信用预留的量.
当Dcc客户端报告使用量和费用标准的变化时,Dcc客户端必须分开列出发生变化之前和变化之后的使用量,如果客户端不能区分正在发生变化时的使用量,必须把这些使用量列到第三个科目下.
如果一个客户端不支持标准费用切换机制,当接收到有Tariff-Time-change Avp的Cca消息时,应该立刻结束cc会话,并发送一个Termination-Cause值为DIAMETER_BAD_ANSWER的Ccr.
基于时长的服务,使用量会以正常的每分钟60s的速度消耗.同时当资源被分配以后,服务器已经知道标准费用变化前后的使用量了,就不需要额外的"费用变化时间"Avp了,因此这个Avp主要是在基于"流量"的服务事件中使用.
5.1.2. Credit-Control for Multiple Services within a (sub-)Session
当多个服务在同一个用户会话中,并且每个服务或者一组服务有不同的费用,就有必要对每个服务提供单独的cc(信用控制),可以使用cc子会话完成对cc的单独控制,但会增加客户端和服务端的资源的使用(cpu,内存 ...).例如,在一个网络接入的会话中,用户可能会使用多个http服务,每个http可能有不同的接入费用.网络接入属性Qos(Quality Of Service)对所有服务的接入承载者都是一样执行的,但可能根据内容不同承载者的费用不同.
[Page 17]
为了更好的支持这些场景,cc应用允许在一个会话中对多个服务进行单独的cc,多个服务保存到Ccr/Cca的Multiple-Services-Credit-Control Avp中,对应多个服务的,分配和资源的时候可能会从一个多服务共享的信用池中分配.为了更好的集中信用分配,服务可以按计费编组.也可以按每个服务分配资源.每个服务都可以有自己的result-code, validity times, 和Final-Unit-Indications.
Rating-Group通过Service-Identifier Avp把一系列的服务集合起来,并且提供同样费用的计费类型(例如$0.1/minute).假设服务网元提供Rating-Group,Service-Identifier和他们的联合参数(这些参数不属于文档的范围),Service-Identifier能为每一个属于信用的服务授权,这取决于cc服务器是对一个还是多个还是整个Rating-Group信用授权.然而,无论是哪种授权客户端应该在最好颗粒度级别报告分配额度的使用情况.而配额是属于一个Rating-Group的时候,所有的属于这个Rating-Group的服务,都从这个配额中取信用授权.下面是对Service-Identifier,Rating-Group,Credit pools和CCS之间的关系的物理上的展示.
DCC (Sub-)Session
|
+------------+-----------+-------------+--------------- +
| | | | |
Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z
\ / \ / /
\ / \ / /
\ / Rating-Group 1.......Rating-Group n
\ / | |
Quota ---------------Quota Quota
| / |
| / |
Credit-Pool Credit-Pool
[Page 18]
如果对多个服务实行独立cc,Validity-Time和Final-Unit-indication 应该包含在Multiple-Services-Credit-Control Avp中,或者是作为命令级别的单独的Avp.然而,Result-Code Avp可以同时在命令级别和Multiple-Services-Credit-Control Avp中.
CC客户端在第一次"询问"的时候就必须通过包含Multiple-Services-Credit-Control指明在一个会话中支持多个服务,每个服务独立处理.CC服务器不支持这种情况的时候,必须把Multiple-Services-Credit-Control当做非法的Avp处理.
如果客户端标明支持对多个服务中的每个服务独立处理,支持这种处理的cc服务器会在Multiple-Services-Credit-Control中把授权量关联到service-identifier或者是Rating-Group上.
要避免多个服务同时对一个账户做信用预留,还要避免使cc服务器承受不必要的压力,提供一个授权量的池更合适一点.通过Multiple-Services-Credit-Control Avp中对特殊服务或者是计费组给出的表,提供的授权量可以实现.或者可以通过引用授权量池的类型来实现.
上面提及的包含来自计费参数的乘数,该参数是从池中的抽象的授权量的指定类型的授权量解析得到的.
如果S是池中总的授权量,M1,M2, ...,Mn是服务1,2,..., n 提供的乘数,C1,C2, ..., Cn 是在会话中使用了的资源,当信用池的消耗满足下面公式的时候,就必须重授权.
C1*M1 + C2*M2 + ... + Cn*Mn >= S
[Page 19]
S是池中所有的信用额度,S从分配给池的授权量计算出来的,计算公式如下:
S = Q1*M1 + Q2*M2 + ... + Qn*Mn
如果服务或者计费组被添加到池中,或者是被从池中移除,信用总量要做适当的调整.注意,移除服务的时候,需要移除对应的Cx*Mx.
可以在任何时间对单独的服务或者是计费组重授权,例如,如果一个"非授权池"的授权量被消耗完或者是Validity-time期满.
当在有Granted-Service-Unit Avp的Mutiple-Service-Credit-Control(section 8.16)中支持拥有相同G-S-U-Pool-Identifier(section 8.30)的多个G-S-U-Pool-Reference Avp时,G-S-U-Pool-Reference必须有不同的CC-Unit-type,同时他们会分别的从信用池中消耗信用量.例如,如果一个乘数是时间(M1t),另一个乘数是流量(M1v),从信用池中消耗的资源就是C1t*M1t + C1v*M1v的总和,这里的C1t是时间的单位,C1v是流量单位.
没有G-S-U-Pool-Reference Avp的,提供的授权量都是从信用池和任何服务或者计费组中单独控制的.
信用池的概念是为了避免单个费率切换机制中过多的预留配额.因此,实施多个服务独立cc的Dcc客户端和服务端,支持费率切换的时候应该使用信用池.服务器应该在CCa的2个配额中包含Tariff-Time-Change和Tariff-Change-Usage Avp.(例如,2个Multiple-Services-Credit-Control).一个授权量是费率切换之前使用的,一个是费率切换之后使用的.这两个授权量必须拥有相同的Service-Identifier或者是Rating-Group.用两个授权量的机制确保客户端报告的使用量不会超出信用预留的量.Dcc客户端会在一个Multiple-Services-Credit-Control Avp中报告费率切换前后的使用量.
[Page 20]
在Section 5.7和7中定义了对CCS(Credit-Control session)的失败的处理.在会话中cc客户端和服务端,必须确保对失败的处理是和5.7和7中提及到的是完全一致的,同时要处理会话的重授权.因此建议Dcc客户端增加一个"未处理的U消息"队列,当每次发送UPDATE_REQUEST Ccr消息时就重新启动Tx定时器(section 13.当所有的未处理消息都收到了应答后,状态改为OPEN,同时停止Tx定时器.很显然,根据section 5.7中的定义检查出问题的会话会影响所有的正在使用的业务.
由于客户端可能发送当处于"未处理"状态的UPDATE_REQUEST Ccr消息,这些请求直接的时间间隔可能会非常短,也许服务器可能还没有收到之前的请求,因此,在这钟情况下服务器没有收到不连续的请求,这是正常的,不能认为是错误.服务器会对每一个请求做出合适的应答.
5.2. First Interrogation(第一次询问)
CCS(Credit-Control session),当Dcc客户端运行为任何用户提供服务时,要求Dcc客户端发送第一次询问,Ccr中的CC-Request-Type 设置为INITIAL_REQUESET.
如果Dcc客户端服务的费用,应该把费用填到 Requested-Service-Unit Avp中,如果Dcc客户端不知道服务的费用,应该把服务的次数,填到Requested-Service-Unit Avp中,在使用Mutiple-Services-Credit-Control Avp时,必须包含Requested-Service-Unit Avp,指出服务或者是Rating-Group请求的授权量. 在多个服务的情况下,在Mutiple-Service-Credit-Control Avp中的Service-Identifier Avp或者是Rating-Group Avp 是和服务相关联的.额外计费的服务信息可能会在和command 同级别的Service-Parameter-Info Avp中.Service-Context-Id Avp指出服务请求中使用的服务特性文档.
[Page 21]
在Ccr中应该包含Event-Timestamp Avp, 这个Avp中填写的是Dcc客户端发送服务事件请求的时间,Ccr中还应该有Subscription-Id Avp, 这个Avp指出了需要服务的用户.CC客户端可能还会提供User-Equipment-Info Avp,cc服务器可以根据这个Avp提供用户接入设备的类型和能力.至于cc服务器是如何使用这个Avp的,不在本文档的范围.
cc服务器应该计算服务事件的费用,在用户的付费的账户上做一个信用预留.如果Requested-Service-Unit Avp给的是钱,就不需要计算费用,但要根据钱在用户的账户上预留服务使用的费用.
CC服务器在Cca消息中返回Granted-Service-Unit Avp给Dcc客户端.Granted-Service-Unit Avp中填的是服务的授权量或者叫配额,这个配额是客户端可以提供给用户的使用量,消耗完以后,必须再次发送一个新的Ccr给服务器.如果在Cca消息中有多重类型的配额,cc客户端必须分别处理每一个类型的配额.Granted-Service-Unit Avp的类型可以是时间,流量,服务特性,或者是钱,具体的类型要看服务事件.配额类型在CCS中是不能改变的.
在一个Cca消息中必须有一个同样的配额类型的实例的最大值.如果在Mutiple-Services-Credit-Control中有多个配额被发送给cc客户端,可能会有2个同类型的配额关联到一个Service-Identifier或Rating-Group上,由于CC服务器想区分切换前后的使用量,这在费率切换上是很典型的例子.
如果CC服务器确定不需要对服务做更多的控制,会使用result-Code指出不适合的CC,(这个Result-Code是和命令码同级别的),同时暗示CCS即将结束.
Cca消息中可能有Fianal-Unit-Indication Avp,这个Avp表示当前的Cca消息中给出的是能够提供服务的最后的授权量.当用户消耗完此次的配额(分配的额度)后,Dcc客户端必须执行Section 5.6中给出的动作.
[Page 22]
在不同的网络结构中实施"第一次询问",这个文档定义了2中不同的方法.第一种方法在用户得到授权和鉴权之后,发送"第一次询问",第二种方法是,在对用户授权和鉴权阶段,使用服务特性的授权信息进行"第一次询问".如果一个CC客户端同时支持这两张方法,应该通过配置确定使用哪种方法.
在服务环境中,如网络接入服务器(Network Access server--NAS),更喜欢第一种方法.在"第一次询问"后实施更多的信用授权.在提到的环境中操作的cc客户端应该支持这种方法,如果cc服务器和AAA服务器是物流上分开的实体,当cc客户端发送请求消息给AAA服务器时,AAA服务器会发送一个请求给cc服务器,或者是转发接收到的请求给cc服务器.
在其他的服务环境中,如3GPP网络和一下SIP场景中,在注册/接入到的网络和实际服务请求之间只有少量的消息.(例如,授权和认证在注册/接入到网络时只执行一次,同时也不是对用户的每个业务都执行授权和认证的操作).在这些环境中,更适合在用户被授权和认证之后执行"第一次询问". 第一次, 第二次, ... 最后一次询问.
其他的IETF标准或者是其他的标准给出的结构中可能定义出了更适合的方法.
5.2.1. First Interrogation after Authorization and Authentication(在授权和认证之后的第一次询问)
对制动的用户是否做信用控制,Dcc客户端可以从授权服务器上获取到信息.如果cc被要求,需要先练级cc服务器,然后在给用户提供服务.记账协议和cc协议可以并行的使用.授权服务器可以决定是否需要并行的账单流.
[Page 23]
下面的图表阐述了两种协议并行和cc客户端直接发送cc消息给cc服务端的情况.更多的cc顺序实例请参考Annex A.
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Registration | AA request/answer(accounting,cc or both)|
|<----------------->|<------------------>| |
| : | | |
| : | | |
| Service Request | | |
|------------------>| | |
| | CCR(Initial,Credit-Control AVPs) |
| +|---------------------------------------->|
| CC stream|| | CCA(Granted-Units)|
| +|<----------------------------------------|
| Service Delivery | | |
|<----------------->| ACR(start,Accounting AVPs) |
| : |------------------->|+ |
| : | ACA || Accounting stream |
| |<-------------------|+ |
| : | | |
| : | | |
| | CCR(Update,Used-Units) |
| |---------------------------------------->|
| | | CCA(Granted-Units)|
| |<----------------------------------------|
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination, Used-Units) |
| |---------------------------------------->|
| | | CCA |
| |<----------------------------------------|
| | ACR(stop) | |
| |------------------->| |
| | ACA | |
| |<-------------------| |
Figure 2: Protocol example with first interrogation after user's
authorization/authentication
[Page 24]
5.2.2. Authorization Messages for First Interrogation(第一次询问的授权信息)
在AA请求结构中,Dcc客户端必须和授权/认证的客户端通过增加适当的cc Avp配合操作.cc客户端增加cc Avp 指出cc能力,同时可能增加其他的适用于授权/认证命令的cc特性相关的Avp,来向Diameter AAA服务器"第一次询问".Auth-Application-Id被设置一个适当的值,值得定义在授权/认证相关的应用文档中(如[NASREQ],[DIAMMIP]).主Diameter AAA服务器对用户授权/认证,并决定是否需要cc.
如果对于用户需要cc,主Diameter AAA服务器会回复一个适合的AA应答消息.如果用户需要cc并且在授权请求中的cc的Avp中设置了CREDIT_AUTHORIZATION,主AAA服务器必须联系CC服务器执行"第一次询问".如果需要CC的时候,在授权请求时没有CC的Avp,AAA服务器必须发送一个拒绝授权的应答信息.
支持cc的Diameter AAA 服务器被要求发送Ccr给cc服务器,使用Ccr中的服务特性Avp作为计费的参数,同时在AA请求中可能收到cc Avp.cc服务器将从用户的账户上预留资金,计算费用并且发送一个Cca信息给主Diameter AAA服务器,在Cca中包含有Granted-Service-Unit Avp.另外,cc服务器可以设置Validity-Time 和Credit-Control-Failure-Handling Avp 和Direct-Debit-Failure-Handling Avp 决定如果向cc服务器发送cc信息的动作被暂时阻止需要要做什么.
[Page 25]
根据从cc服务器接收的Cca消息,主Diameter AAA 服务器将会使用cc Avp和根据授权/认证文档中指出的服务特性 Avp 生成一个AA 应答.并把这个应答发送给cc客户端.如果主Diameter AAA服务器接收了一个cc拒绝消息,服务器会简单的生成一个适合的授权拒绝消息,发送给cc客户端,消息中有cc指定的错误码.
在这种模式下,cc客户端发送很多的cc信息到主Diameter AAA服务器,再有AAA服务器转发给,给cc服务器.根据接收包含有Granted-Service-Unit Avp的成功的授权应答信息,cc会话端将批准为用户提供服务,并会生成中间的Ccr.第一次的UPDATE_REQUEST的CC-Request-Number必须设置为1(对应如何生成唯一的CC-Request-Number Avp的值,参考Section 8.2).
如果实施重授权服务特性,cc客户端必须增加设置为RE_AUTHORIZATION的Credit-Control Avp到重授权请求的服务特性中,指出不需要联系cc服务器.当对用户使用CCS时,会有一个不断的消息流从主Diameter AAA服务器穿过,AAA服务器可以使用cc消息流推算服务中的用户的活跃性,因此,建议设置authorization-lifetime为一个合理的值.
在这个场景中,主Diameter AAA服务器在兼容性互换处理过程中,必须告知对cc应用的支持.
[Page 26]
下面的图表阐述了实施"第一次询问"时,授权/认证消息的使用.
Service Element Diameter
End User (CC Client) AAA Server CC Server
| Service Request | AA Request (CC AVPs) |
|------------------>|------------------->| |
| | | CCR(Initial, CC AVPs)
| | |------------------->|
| | | CCA(Granted-Units)
| | |<-------------------|
| | AA Answer(Granted-Units) |
| Service Delivery |<-------------------| |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update,Used-Units) |
| |------------------->| CCR(Update,Used-Units)
| | |------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------|
| |<-------------------| |
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination,Used-Units) |
| |------------------->| CCR(Term.,Used-Units)
| | |------------------->|
| | | CCA |
| | CCA |<-------------------|
| |<-------------------| |
Figure 3: Protocol example with use of the
authorization messages for the first interrogation
5.3. Intermediate Interrogation(中间询问)
当所有的服务授权量耗尽或者是Validity-Time期满,Dcc客户端必须发送一个新的Ccr给CC服务器.在ccs中使用多个服务cc(Credit-Control)的,(授权量关联到Service-Identifier或者是Rating-Group),当所有预留的信用已经被消耗完或者是Validity-Time期满时,必须发送一个新的Ccr给cc服务器.在网元(Service element) 中,为了避免服务被中断,在发送新Ccr的cc客户端准备好之前,应该对之前的请求设置更大的期限.即使被cc服务器预留的授权量在Validity-Time期满的时候没有被消耗,Dcc客户端也必须发送一个新的Ccr给cc服务器.
[Page 27]
在会话中间可以有服务事件,这些服务事件可能影响对当前正在使用的服务事件的计费.在这种情况下,会自然的发送一个Ccr,即使当前的服务的配额没有耗尽或者是Validity-Time没有期满,也会把服务的使用情况包含在这个Ccr中.
当服务的使用量被报告给cc服务器后,cc客户端在接收到新的授权量之前,没有任何可以使用的授权量,当接收到新的授权量时,新的授权量的应用点是之前报告时停止使用的点.在支持多服务独立cc的情况中,在一个会话中这样的处理可能被一个或多个服(一个Rating-Group或者是服务池)务执行.
在中间的请求中 CC-Request-Type Avp 设置为UPDATE_REQUEST,同时包含Subscription-Id Avp指出在cc服务器中的用户,Service-Context-Id指出适合请求的服务特性文档.
Requested-Service-Unit Avp中填写服务申请的授权量.在使用Mutiple-Services-Credit-Control申请服务授权量时,必须填写对应服务或Rating-Group的Requested-Service-Unit Avp.Used-Service-Unit Avp中给出值的是从服务开始或者是会话中的询问的时间点测量的值.应该使用和之前的消息相同的单位,如果之前的使用量有多种类型的话,必须报告每个类型的Used-Service-Unit .
在请求消息中应该有Event-Timestamp Avp,该Avp给出的是发送Ccr的时间点.
[Page 28]
cc服务器必须从用户的账户上扣减使用量,服务器可能计算新的请求的费用,并从用户的服务扣费账户上做一个新的信用预留.
一个CC-Request-Type Avp的值是UPDATE_REQUEST的Cca,可能包含Cost-Information Avp,在这个Avp中包含已经计算好的费用,但不包含对账户的信用预留量.
Cca 消息通过Final-Unit-Indication Avp指出,当前的Cca中给出的是服务的最后一个配额.当用户消耗完这个配额后,Dcc客户端需要执行Section 5.6中定义的动作.
在一个会话中,可以有多个"中间询问".(中间请求)
5.4. Final Interrogation (最后的询问)
当用户结束服务会话,或者当服务像在Section 5.6中描述中一样优雅的结束服务时,Dcc客户端最后的Ccr消息给cc 服务器.在这个Ccr中CC-Request-Type被设置为TERMINATION_REQUEST.Service-Context-Id为请求指出适合服务特性的文档.
Ccr中应该包含Event-Timestamp Avp,用于指出服务结束的时间点.
Used-Service-Unit Avp 给出了最后一次服务的使用量,如果在之前的应答消息中有多重类型的使用量,需要分别报告每种类型的Used-Service-Unit.
在"最后一次询问"后,cc服务器必须把使用掉的费用扣除,并把没有使用的费用还回用户的账户上.
CC-Request-Type设置为TERMINATION_REQUEST的Cca消息,可能通过Cost-Information Avp包含有整个会话中所使用的费用.
[Page 29]
如果用户在使用服务中退出服务,或者是有其他原因使用后退出服务(例如,Final-unit的出现,引起用户根据本地策略退出),服务节点(网元),根据应用特性策略,可能会发一个Session-Termination-Request(STR)给主Diameter AAA 服务器. Figure 4 阐述了当消耗完最后一个配额后,由Final-Unit引起的用户退出的例子.
Service Element AAA Server CC Server
End User (CC Client)
| Service Delivery | | |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update,Used-Units) |
| |------------------->| CCR(Update,Used-Units)
| | |------------------->|
| | CCA(Final-Unit, Terminate)
| CCA(Final-Unit, Terminate)|<-------------------|
| |<-------------------| |
| : | | |
| : | | |
| Disconnect user | | |
|<------------------| CCR(Termination,Used-Units) |
| |------------------->| CCR(Term.,Used-Units)
| | |------------------->|
| | | CCA |
| | CCA |<-------------------|
| |<-------------------| |
| | STR | |
| |------------------->| |
| | STA | |
| |<-------------------| |
Figure 4: User disconnected due to exhausted account
5.5. Server-Initiated Credit Re-Authorization
Dcc应用支持服务器初始化,再授权.服务器使用[DIAMBASE]中定义的Re-Auth-Request (RAR)初始化信用再授权是可选的.Rar中的Auth-Application-Id 要设置成4,说明是Dcc,Re-Auth-Request-Type设置成AUTHORIZE_ONLY.
[Page 30]
Section 5.1.2中定义了服务器可以在一个会话中对多个服务给予不同颗粒度级别的信用使用量授权.还有,服务器可以对服务或者是计费组提供信用资源池(Section 5.1.2中有详细的介绍和定义).因此,服务器基于服务的逻辑和对存在的会话的了解,可以选择对会话请求再次信用授权,(包括,单个的信用池,单个服务,或者是Rating-group).服务器对信用池请求再次信用授权时在Rar中使用G-S-U-Pool-Identifier Avp标出受影响的池,对服务或者是计费组(Rating-Group)请求再次授权时,服务器会在Rar信息中包含Service-Identifier Avp或者是Rating-Group Avp,标明请求的服务或是计费组.如果对会话中的所有服务请求再次授权,在Rar中不包含上面提及到的任何Avp.
如果信用再授权还没有发出(比如,会话已经存在了),cc客户端收到一个session-id属于这个会话的Rar消息,cc客户端必须了对这个Rar做出Raa(Re-Auth-Answer)应答,同时通过CC-Request-Type是UPDATE_REQUEST的Ccr初始化一个信用再授权,发送个cc服务器.在RAA消息中设置Result-Code为2002,支持完成这个处理的额外的信息.如果一个授权量已经分配给了一个服务,cc客户端必须在Ccr报告授权量的使用情况. 注意,由于信用再授权对于用户来说是不可见的,因此不需要提醒用户信用再授权.(信用在授权是cc客户端和cc服务器之间的工作)
在一个用户的会话中指出多个业务时,在收到服务器的RAR消息时,上一段提到的步骤会被执行.
如果在接收大Rar消息时,信用在授权正在处理中,cc客户端解析请求后并不需要初始化一个新的信用再授权.cc客户端应该发送一个Result-code是2001的Raa消息,告诉服务器,信用再授权已经在运行了.(比如,客户端处于未处理的U包状态),cc服务器就向已经被初始化过的信用再授权一样处理这个Ccr,并且应该知道根据Raa的信息成功的初始化信用再授权/
当在一个用户的会话中指出多个服务时,服务器可能会对一个信用池请求信用再授权,这个信用再授权已经在使用了.在这种情况下,解析服务端的请求,并发送一个Raa消息,同时发送一个新的Ccr消息,请求对保持的服务或计费组的再授权.在Raa中Result-Code的值被设置为2002,指出完成步骤需要的附加的信息.服务器处理收到的信息,对两个请求做出适当的应答.
上面定义的步骤可以使用于每一个激活的Dcc子会话.服务器可能通过在Rar中包含CC-Sub-Session-Id Avp为一个激活的子会话请求再授权.
5.6. Graceful Service Termination(得体的结束服务).
当用户的账户欠费或者是没有足够的余额时,用户可能不能使用额外付费的服务.不过,主服务提供者可能会提供一些其他的服务,如,充值服务,对这种服务给一个用户允许使用的期限是有好处的.
本章中定义了选择性的结束服务的特征(这些特征是服务器支持的).cc客户端必须支持Final-Unit-Indication Avp,当用户消耗完最后配额后,立刻停止服务.
在支持一个ccs中对多个服务单独信用控制时,可能分别结束每一个服务或是Rating-Group.在下面的子章节中会详细的阐述服务器要求的结束服务特性.
[Page 32]
在一些服务环境中,服务的结束可能被用于从定向用户到一个在线充值的服务上,或者是服务提供者提供的其他服务上.在这种情况下,结束程序会安装一个过滤器,限制用户的接入能力,只能接入到指定的服务上.所有符合过滤条件的信息都会被丢掉,或者是从定向到指定的服务上,还可能向用户发送一个适合的通知,告诉用户为什么接入被限制.这些动作在服务器和客户端被明确的传递,或者这些动作被设置在客户端的每个服务上.显然,重定向或者是限制指令信号比所有的配置都优先.
也可能使用"结束服务",让预付费用户连接充值服务器,起到通知用户对账户充值的作用.这种情况下,cc客户端发送一个充值服务器的地址.告诉用户最后一个配额耗尽后,应该连接的充值服务器.在Appendix A中给出了一个例子(Flow VII).
CC服务器可能通过在Cca中包含Fianl-Unit-Indication Avp初始化"结束服务".
当cc客户端接收到Final-Unit-Indication Avp时,客户端要根据Final-Unit-Action Avp给出的内容采取行动.服务器可能要求戏码的动作:TERMINATE, REDIRECT.
下面的图表阐述了之后子章节中描述的"结束服务"步骤.
[Page 33]
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Delivery | | |
|<----------------->| | |
| |CCR(Update,Used-Units) |
| |------------------->|CCR(Update,Used-Units)
| : | |------------------->|
| : | |CCA(Final-Unit,Action)
| : | |<-------------------|
| |CCA(Final-Unit,Action) |
| |<-------------------| |
| | | |
| : | | |
| : | | |
| : | | |
| /// |CCR(Update,Used-Units) |
|/Final Units End/->|------------------->|CCR(Update,Used-Units)
|/Action and // | |------------------->|
|/Restrictions // | | CCA(Validity-Time)|
|/Start // | CCA(Validity-Time)|<-------------------|
| / |<-------------------| |
| : | | |
| : | | |
| Replenish Account +-------+ |
|<-------------------------------------------->|Account| |
| | | +-------+ |
| | | RAR |
| + | RAR |<===================|
| | |<===================| |
| | | RAA | |
| / | |===================>| RAA |
| /If supported / | | CCR(Update) |===================>|
| /by CC Server/ | |===================>| CCR(Update) |
| / | | |===================>|
| | | | CCA(Granted-Unit)|
| | | CCA(Granted-Unit)|<===================|
| Restrictions ->+ |<===================| |
| removed | | |
| : | | |
| OR | CCR(Update) | |
| Validity-Time ->|------------------->| CCR(Update) |
| expires | |------------------->|
| | | CCA(Granted-Unit)|
| | CCA(Granted-Unit)|<-------------------|
| Restrictions ->|<-------------------| |
| removed | | |
Hakala, et al. Standards Track [Page 34]
RFC 4006 Diameter Credit-Control Application August 2005
Figure 5: Optional graceful service termination procedure
5.6.1. Terminate Action
在Final-Unit-Indication Avp中的Final-Unit-Action的值是TERMINATE时,Final-Unit-Indication中就不会包含其他信息.当用户消耗完最后一个配额后,网元(service element)必须结束提供服务,这个是个默认的处理,就算是Dcc客户端接收到一个不支持的Final-Unit-Action值,只要是按照本文档描述的Dcc客户端都必须这样做.在命令级的Final-Unit-Indication Avp的动作是TERMINATE,cc客户端就必须向cc服务器发送一个CC-Request-Type为TERMINATION_REQUEST的Ccr,这个ccr为本次会话的最后一次请求包.
5.6.2. Redirect Action
如果Final-Unit-Indication Avp的Final-Unit-Action的值是REDIRECT,当用户消耗完最后的配额后,用户必须被重定向到Redirect-Server Avp指向的地址.
cc服务器发出的Cca中有Redirect-Server Avp时,网元必须把用户重定向或者链接到Redirect-Server Avp中给出的地址.当用户被重定向到给出的地址或者服务器,或者是充值服务器,在用户充值之前,可能需要额外的授权;但这些不是本文讨论的范围.
除了Redirect-Server Avp,cc服务器在Cca中可能还会添加一个或多个Restriction-Filter-Rule Avp,还有Filter-Id Avp,这样做的目的是为了使用户能够接入到其他的服务上.在一些例子中,接入设备必须丢弃所有和在Cca中指定的IP 过滤器不匹配的消息,同时如果可以的话,重定向用户到Redirect-Server 中给出的服务器上.
在实例中,不止CC服务器支持IP过滤器,Dcc的很多应用都支持IP包过滤器.详情请看Section 5.6.3.
[Page 35]
当最后一个配额被消耗完以后,cc客户端必须执行"结束询问".这样做是为了告诉服务器指定的动作已经开始执行,并且告诉服务器配额的使用情况.cc服务器必须重用户的账户上扣减使用量,但不能重新做信用预留.由于计费和信用预留需要,cc客户端可能在用户还没有消耗完最后一个配额的时候就会执行"结束询问";例如,Validity-Time期满,或者是会话中的服务事件影响当前的服务.因此, cc客户端必须一次性的把计费相关的Avp和所有配额的使用情况都发给服务,表示最后配额的动作已经开始执行,并且不需要再做信用预留. 自然在Cca信息中不会包含有任何的配额和Validity-Time Avp.
当Validity-Time期满时,cc客户端会发送一个Ccr(UPDATE_REQUEST). 如果这个消息中不包含Used-Service-Unit Avp,说明没有配额消耗. cc服务器必须处理这个消息,并做信用预留, 如果在这期间用户没用对账户充值,用户被断开,还是可以不限时的接入到服务,这个要看服务提供者的策略.(注意,后面一个选择暗示不应该根据cc控制结束移除"限制过滤器".为了执行policy-defined动作,服务器会在Cca中给出一个对应的Result-Code(section 9.1).否则,应该返回新的配额,网元必须移除所有被服务结束程序激活的限制,并且继续保持CCS(Credit-Control Session)和服务会话.
如果网元可以决定的话,CC客户端可能不会等到Validity-Time期满就发送一个CC-Request-Type为 UPDATE_REQUEST的Ccr,例如,用户和充值服务器(top-up server)之间的交互.在Appendix A中有对这个例子的详细描述(Figure A.8).
[Page 36]
注意,cc服务器对"第一次询问",已经初始化了上面描述的处理.当"第一次询问"时,用户的账户可能是空账户,在这种情况下,可以给用户提供一个充值的机会,并且继续提供服务.网元接受到一个没有Granted-Service-Unit Avp,但有Final-Unit-Indication Avp和Validity-Time Avp的Cca或者是服务特性的应答,cc客户端应该立刻结束服务,并且不需要发送任何消息给服务器.在Appendix A中有阐述这个过程的例子.
5.6.3. Restrict Access Action
Final-Unit-Indication Avp中的Final-Unit-Action的值是RESTRICT_ACCESS指出支持动作的设备要根据Restriction-Filter-Rule Avp或者是Filter-Id Avp中定义的Ip包过滤规则限制用户接入. cc服务器应该在Cca消息中包含Restriction-Filter-Rule Avp或者是Filter-Id Avp.
不是只有CC服务器可能提供有IP包过滤器的接入设备.很多设备都可以,例如,IP流的接入设备.当用户账户不足时,执行过滤功能是控制预付费用户的cc服务器的职责.
如果集合了Dcc应用的一个实体已经提供了接入设备所有需要的过滤规则,cc服务器可能发送一些其他的过滤规则.因此,建议cc服务器可以通过配置支持Restriction-Filter-Rule Avp和Filter-Id Avp或者还有其他的.
当最后一个配额被消耗光了,cc客户端必须进行"中间询问".cc客户端和服务器处理这个"中间询问",并且执行之后的处理步骤,根据之前章节中对REDIRECT动作的描述.
[Page 37]
服务器可能对"第一次询问"时,根据之前章节中对REDIRECT动作的描述,就对异常结束服务做了RESTRICT_ACCESS初始化.
5.6.4. Usage of the Server-Initiated Credit Re-Authorization
一旦用户对账户充值,用户可能期望移除被异常结束程序设置的所有约束,和恢复接入服务.为了更好的用户体验,cc服务器可以支持服务器初始化的信用授权(Section 5.5).在这个例子中,根据充值成功,cc服务器发送一个Rar信息恳求信息用授权.cc客户端会通过发送一个CC-Request-Type为UPDATE_REQUEST的Ccr,请求信用授权.由于没有使用量要报告,Ccr中不会有Used-Service-Unit Avp,但可能有Requested-Service-Unit Avp.在cc客户端接收到一个有Granted-Service-Unit Avp 的Cca后,所有由于异常结束引起的限制都会被移除.CCS和服务会话都回复正常.
5.7. Failure Procedures
Credit-Control-Failure-Handling Avp(CCFH),决定在异常情况下cc客户的表现.CCFH可能来自于Diameter的主AAA服务器,也可能是来自于cc服务器或者是本地配置的. 从AAA服务传递过来的CCFH会覆盖本地配置的,Cca信息中的FFCH会覆盖所有的FFCH.
[Page 38]
授权服务器可能包含Accounting-Realtime-Required Avp决定如果把记账记录发送给记账服务时被阻止了,需要做些什么.建议,客户端使用一个指向记账服务器的备用记账流完成CC异常步骤, 通过使用Accounting-Realtime-Required和Credit-Control-Failure-Handling Avp的不同组合,建立不同的安全等级.例如,只要记账服务器可以采集记账信息还有记账服务器和cc服务器之间的信息,通过设置Credit-Control-Failure-Handling Avp为CONTINUE和设置Accounting-Realtime-Required Avp为DELIVER_AND_GRANT,即使cc客户端和服务端断开,也可以为用户继续提供服务.
当一个cc应用是基于cc客户端和服务端实时交互时,可供选择的目的的使用和消息的缓存可能不能满足交互异常的事件.由于CC服务器必须维护会话状态,把cc消息流转移到一个备用服务器上,需要一个复杂的内容传输方案.在cc会话期间cc消息流是否要转移到备用服务器上,要看CC-Session-Failover Avp.然而,failover可能发生在cc客户端和服务器路径上的任何一个点上,结果,cc服务器可能收到重复的消息,cc服务器可以根据会话状态引擎(Section 7),使用Session-Id Avp和CC-Request-Number Avp检查这些重复的消息或者是不按顺序的消息.
如果cc服务器设置CC-Session-Failover Avp的值为FAILOVER_SUPPORTED,在会话期间发生异常的时候,cc客户端可能把cc消息流转移到一个可选择的服务器上.备用的CC服务器名既可以从主Diameter AAA服务器获取到也可以通过本地配置获取,名字可以是备用服务器的地址.如果CC-Session-Failover Avp被设置成FAILOVER_NOT_SUPPORTED, cc消息流不能被转移到备用服务器上.
对于新的cc会话,如果可以的话,应该给出一个failover时,可供选择的cc服务器.例如,如果cc客户端确定主cc服务器不可用,cc客户端可以把新会话建立在备用服务器上.
AAA传输概要[AAATRANS]定义了应用层的"心跳算法"(watchdog),可以监控failover.建议监控的定时器时间为30s,这个时间可能被设置为6s,然而,根据[AAATRANS]的说明,这个时间越短,重复的消息就会越多,还好增加假的failover和故障恢复的尝试.Diameter基础协议对多种类型Diameter AAA应用是通用的.这些AAA服务器可能运行在用一个网元上.因此,为了实时应用的安全,把定时器的值设置的比较低,会引起上面提及到的问题,对预付费服务来说,尽管客户端期望在合理的时间内从网元获取到一个响应.因此,Dcc客户端会尽快的做出反应.因此,这份文档定义了定时器 Tx,被客户端用于监督和cc服务器直接的交互(详情请见Section 13).当Tx被触发,cc客户端根据Credit-Control-Failure-Handling Avp进行处理.
[Page 39]
如果Credit-Control-Failure-Handling设置为TERMINATE时,当Tx逾期,Dcc客户端结束服务.仅仅在协议错误(DIAMETER_TOO_BUSY或者是DIAMETER_UNABLE_TO_DELIVER时,在Tx逾期之前,cc会话可能被转移到一个可供选择的服务器上.因此, 如果期望适合failover的处理,应该给出一个比TERMINATE更适合的值.
如果CCFH被设置为CONTINUE或者是RETRY_AND_TERMINATE, 当Tx逾期后,用户还可以使用服务.可能稍后cc服务器会收到一条含有granted-units信息的消息.(默认可以授权3次,比Tx间的多).cc客户端应该授权用户的服务,并且开始监控资源的使用情况,并且等待接收应答,直到请求超时.(一般是120s).如果请求失败,并且CC-Session-Failover Avp的值是FAILOVER_NOT_SUPPOTED, cc客户端尽可能向备用服务器发送请求.如果cc客户端成功的从备用服务器上接收到了应答消息,要把这个会话的消息继续发送给备用服务器.如果第二次发送也失败了,cc客户端结束或者是继续服务,要根据CCFH的值,同时要释放所有为cc会话预留的资源.
如果在异常结束服务期间,交互失败,网元应该结束当前的会话.
[Page 40]
如果cc服务器在会话进行中,发现了一个错误,服务器会结束cc会话,同时把预留的资源返回给用户的账户.
在cc服务器中使用监控会话定时器Tcc,监控cc会话.
为了支持cc服务器直接的failover, 在主备cc服务器直接,应该有一个cc会话和账户状态的信息传送者.支持cc会话failover的实例,必须还要确保监测重复的消息和乱序的消息.服务器之间的交互不属于本文档的范围.
6. One Time Event
"一次事件"通常用于不需要在Dcc服务骑上保持任何状态的时候.例如,服务价格的查询."一次事件"的使用,暗示用户在使用之前已经被认证和授权.
当cc客户端想要知道服务的费用或者是想检查账户余额,并且不需要信用预留的时候可以使用"一次事件"(one time event)."一次事件"还可以用于充值,或者是不需要信用预留的直接扣费.下面是"一次事件"的展示.
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Request | | |
|------------------>| | |
| | CCR(Event) | |
| |------------------->| CCR(Event) |
| | |------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------|
| Service Delivery |<-------------------| |
|<----------------->| | |
Figure 6: One time event
在3GPP结构中,"一次事件"可以被网元直接发送给cc服务器.
[Page 41]
6.1. Service Price Enquiry
cc客户端可能需要知道服务事件的价格. 在cc客户端中,可能有不知道应用服务提供者提供的服务的价格的情况. 在请求服务之前,用户可能仍然想要获得一个服务事件的价格的估值.
请求费用信息的Dcc客户端必须设置CC-Request-Type Avp为EVENT_REQUEST, Requested-Action Avp为PRICE_ENQUIRY, 同时在Service-Identifier Avp中设置请求的服务事件的信息. 额外的服务事件信息可以设置在服务特性Avp中或者是Service-Parameter-Info Avp中. Service-Context-Id Avp指出适合"请求"的服务特性文档.
cc服务器计算出请求的服务事件的费用,但是,不检查账户余额,也不不对账户做信用预留.
请求的服务事件的费用的估值保存到Cca中的Cost-Information Avp中返回给cc客户端.
6.2. Balance Check
只有在查询的时候,dcc客户端必须检查用户的余额是否可以付清服务的费用,这时并不需要信用预留. 这种方法不能保证在dcc客户端通过另外的请求扣费的时候账户上有足够的余额.
请求查询余额的Dcc客户端必须设置CC-Request-Type Avp 为EVENT_REQUEST,Requested-Action为CHECK_BALANCE,还需要设置Subscription-Id Avp标明cc服务器上的用户.Service-Context-Id Avp指出适合"请求"的服务特性文档.
cc服务器检查余额,但不对账户做信用预留.
在Cca信息中使用Check-Balance-Result Avp把查询结果返回给cc客户端.
[Page 42]
6.3. Direct Debiting
有一些服务总是可以被成功的提供. 在服务调用和实施服务传输给用户之间的延迟可以是非常长,使用会话的cc时,可能导致一个很长的cc会话.在这个例子中,Dcc客户端可以使用"一次事件"场景直接扣费.Dcc客户端应该确请求的保服务事件能成功执行.
在Ccr消息中,CC-Request-Type设置为EVENT_REQUEST, Requested-Action Avp设置为DIRECT_DEBITING, Subscription-Id Avp中填写的是在cc服务器中的用户的信息. Event-Timestamp Avp设置为服务请求的时间,Service-Context-Id Avp标明适合"请求"的服务特性文档.
Dcc客户端如果知道服务的费用时,可能使用Requested-Service-Unit Avp填写收取的费用, 如果Dcc客户端不知道服务的费用, 可能使用Requested-Service-Unit Avp填写请求的服务事件的数量, Service-Identifier Avp总是用了指明服务. 为了计算费用使用到的额外的服务信息可能会包含到服务特性Avp中,或者是在Service-Parameter-Info Avp中.
cc服务器应该计算服务事件的费用,并从账户上扣掉对应的钱.如果Requested-Service-Unit Avp中指出是钱,就不需要计算费用,可以直接从用户账户上扣掉对应的钱数.
cc服务器返回给客户端的Cca消息中会有Granted-Service-Unit Avp.Granted-Service-Unit Avp包含了Dcc可以提供给用户的服务量,或者叫配额. Granted-Service-Unit的单位可以是时间,流量,服务特性,或者是钱,具体的要看服务事件来定.
如果cc服务器确定服务不需要cc,服务器可以通过Result-Code说明服务不适合cc.(例如免费的服务)为了信息化的目的,Cca消息中可能会使用Cost-Infomation Avp指明对服务的费用估值.
[Page 43]
6.4. Refund
一些服务可能退款给用户账户,例如游戏服务.
cc客户端必须在Ccr中设置CC-Request-Type 为EVENT_REQUEST,设置Requested-Action Avp为REFUND_ACCOUNT,Subscription-Id Avp设置为cc服务器能识别的用户标识.
Dcc客户端会把退款放在Requested-Service-Unit Avp中, 使用Servce-Indentifier指明服务. 如果Dcc客户端不知道退款的金额, 除了Service-Identifier Avp还可能会有服务特性Avp或者是Service-Parameter-Info Avp.
6.5. Failure Procedure
由于服务器不维护会话状态,可以对"一次事件"的Failover,提供一个可选择的cc服务器.例如,如果cc客户端接收到了一个协议错误,如DIAMETER_UNABLE_TO_DELIVER或DIAMETER_TOO_BUSY,客户端可以重新发送"请求"给一个可选择的服务器. 在cc客户端和服务器之间可能有对Diameter协议透传和重定向的代理,或者是Dcc的Proxy(路由),Failover可能发生在这个路径上的任何一个点上,由于很多原因能引起重复请求, cc服务器有责任实时的做重复监察. 在[DIAMBASE]中有对实时重复请求监察的实例, Appendix C(附录C).
当cc客户端监视到一个和cc服务器通信的错误时, 会执行请求的动作. 定时器Tx(Section 13)用于监督和cc客户端和服务器之间的通信.
[Page 44]
如果在发现通信失败时,请求的动作是PRICE_ENQUIRY或CHECK_BALANCE,cc客户端应该把请求消息发送给一个可选择的服务器上, 备用的cc服务的名字是从Diameter AAA服务器上获取的,也可能是备用服务器的地址.
如果请求的动作是DIRECT_DEBITING, Direct-Debiting-Failure-Handling(DDFH) Avp控制用cc客户端的行为, DDFH是从Diameter AAA服务器上获取的,或者是本地配置的.cc服务器可以在任何一个用于直接扣费的Cca中发送DDFH.从Diameter服务器获取到的DDFH会覆盖掉本地配置的,从cc服务获取的DDFH会覆盖掉所有现有的DDFH.
如果DDFH设置为TERMINATE_OR_BUFFER, cc客户端应该不批准服务,最后在对可选择服务器再次发送后,通过在Cca中Result-Code或者是Error-Code,不做扣费处理.否则, cc客户端应该批准服务,并把"请求"保存到永久的存储上.(注意,由于用户的账户可能是空的,再次发送的请求不一定会被扣费).CC客户端必须设置请求的T-flag标明重复的请求,这个在[DIAMBASE]的Section 3中有定义.
如果DDFH Avp设置为CONTINUE, 服务应该被批准,即使cc消息不能被传递和缓存.
如果定时器Tx期满,cc客户端必须继续提供服务同时等待之前的应答.如果超出请求的次数,cc客户端要把请求重新传递 给备用的cc服务器上,如果重传的请求也超出了重传的次数,或者在接收到的应答中发生了一个临时的错误,如果DDFH Avp设置为TERMINATE_OR_BUFFER,cc客户端要保存这个请求消息.如果接收到一个重传请求的异常应答,cc客户端要释放所有的对事件消息预留的资源,并且删除所有和请求相关的DDFH的值.
[Page 45]
动作为REFUND_ACCOUNT的Ccr应该总是被保存到cc应用的固定存储上,这样做是防止临时的异常.
为了保存请求消息,cc客户端实例应该限制重传的次数,并且定义重传的时间间隔.
注意,在cc系统中应该只有一个地方检查重复消息, 为了确保用户的账户不被重复扣费,如果给定的范围内只有一个cc服务器,这个cc服务器就应该担当重包检查.如果有多个cc服务器,应该只有一个服务器对重包进行检查.
7. Credit-Control Application State Machine
本章定义了cc应用的状态引擎.
首先cc客户端有4个状态引擎, 第一个描述了当作为授权/认证的"第一个询问"被执行时的基于会话的cc.第二个描述了,在授权/认证之后执行的"第一次询问". 状态引擎需要支持什么东西,在Section 5.2中描述过.
第三个状态引擎描述了基于会话的cc的"最后一次的询问". 第四个描述了基于事件的cc.这些状态引擎会被按本文档开发的实例观察.
第无个状态引擎描述了从cc服务器角度上的cc会话.
[Page 46]
任何在状态引擎中没有的事件,都被认为是错误条件,并且给消息的发起者发送一个适合的应答.
在状态表中,'Failure to send"意思是Dcc客户端不能和期望的目标通信,如果支持failover的处理,可以提供一个可选择的目标服务器, 这种情况可归咎于对端不在服务状态,或者归咎于在路径上的或者cc服务器的物理连接错误.
'Temporary error'意思是Dcc客户端接收到一个基于协议的错误通知(DIAMETER_TOO_BUSY,DIAMETER_UNABLE_TO_DELIVER或DIAMETER_LOOP_DETECTED),这些错误会体现在Cca的Result-Code Avp中,上面提到的错误通知,可能最后再次发送请求给备用服务器时,从备用服务器上接收到的.
'Failed answer' 意思是Dcc客户端接收到的Cca中是永久性的错误通知(非暂时的),这个永久的错误通知,可能最后再次发送请求给备用服务器时,从备用服务器上接收到的.
动作'store request'的意思是,请求消息被存储到应用级的固定存储中.
'Not successfully Processed'意思是cc服务器不能处理消息,例如,由于一个未知的用户,或空账户,或者是在[DIMABASE]中定义的错误引起的.
'User service terminated'能被很多原因触发,例如,正常的用户结束,网络异常,和ASR(Abort-Session-Request). 在[DIAMBASE]文档中定义了Termination-Cause Avp,这个Avp中包含了结束的原因和信息.
定时器Tx被用来控制cc客户端在未决状态时等待的时间,当cc客户端不在未决状态后定时器会被停止.当新的状态时"Idle"时,定时器的停止过程会被忽略,当状态转移到"Idle"时,暗示清理会话,和会话相关的多有变量.
[Page 47]
PendingI,PendingU, PendingT, PendingE, 和PendingB状态代表等待一个队Ccr消息应答的未决状态,分别表示Initial,Update, Termination, Event, 或者是Buffered 请求.
首字母缩写CCFH和DDFH分别代表Credit-Control-Failure-Handling和Direct-Debiting-Failure-Handling.
在下面的状态引擎表中,没有对备用服务器的'Temporary error', 'Failure to send'的failover做明确的描述.向Section 5.7中描述的一样,要尽可能的把发生Failover错误的并把CC-Session-Failover设置为FAILOVER_SERPPORTED的cc消息流发送个备用服务器.
在Section 6.5中描述了,向备用服务器重发一个cc事件.
CLIENT, SESSION BASED for the first interrogation with AA request
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send PendingI
access/service AA request
with added
CC AVPs,
start Tx
PendingI Successful AA req. Grant Open
answer received service to
end user,
stop Tx
PendingI Tx expired Disconnect Idle
user/dev
PendingI Failed AA answer received Disconnect Idle
user/dev
PendingI AA answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingI User service terminated Queue PendingI
termination
event
[Page 48]
PendingI Change in rating condition Queue PendingI
changed
rating
condition
event
CLIENT, SESSION BASED for the first interrogation with CCR
State Event Action New State
----------------------------------------------------------------
Idle Client or device requests Send PendingI
access/service CC initial
req.,
start Tx
PendingI Successful CC initial Stop Tx Open
answer received
PendingI Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
PendingI Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
PendingI Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
PendingI Tx expired and CCFH equal Grant PendingI
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingI CC initial answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED or service
USER_UNKNOWN
PendingI CC initial answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
[Page 49]
PendingI Failed CC initial answer Grant Idle
received and CCFH equal to service to
CONTINUE end user
PendingI Failed CC initial answer Terminate Idle
received and CCFH equal end user's
to TERMINATE or to service
RETRY_AND_TERMINATE
PendingI User service terminated Queue PendingI
termination
event
PendingI Change in rating condition Queue PendingI
changed
rating
condition
event
CLIENT, SESSION BASED for intermediate and final interrogations
State Event Action New State
----------------------------------------------------------------
Open Granted unit elapses Send PendingU
and no final unit CC update
indication received req.,
start Tx
Open Granted unit elapses Terminate PendingT
and final unit action end user's
equal to TERMINATE service, send
received CC termination
req.
Open Change in rating condition Send PendingU
in queue CC update
req.,
Start Tx
Open Service terminated in queue Send PendingT
CC termination
req.
Open Change in rating condition Send PendingU
or Validity-Time elapses CC update
req.,
Start Tx
[Page 50]
Open User service terminated Send PendingT
CC termination
req.
Open RAR received Send RAA PendingU
followed by
CC update req.,
start Tx
PendingU Successful CC update Stop Tx Open
answer received
PendingU Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
PendingU Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
PendingU Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
PendingU Tx expired and CCFH equal Grant PendingU
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingU CC update answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED service
PendingU CC update answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingU Failed CC update Grant Idle
answer received and service to
CCFH equal to CONTINUE end user
PendingU Failed CC update Terminate Idle
answer received and CCFH end user's
equal to TERMINATE or service
to RETRY_AND_TERMINATE
[Page 51]
PendingU User service terminated Queue PendingU
termination
event
PendingU Change in rating Queue PendingU
condition changed
rating
condition
event
PendingU RAR received Send RAA PendingU
PendingT Successful CC Idle
termination answer received
PendingT Failure to send, temporary Idle
error, or failed answer
PendingT Change in rating condition PendingT
CLIENT, EVENT BASED
State Event Action New State
----------------------------------------------------------------
Idle Client or device requests Send PendingE
a one-time service CC event
req.,
Start Tx
Idle Request in storage Send PendingB
stored
request
PendingE Successful CC event Grant Idle
answer received service to
end user
PendingE Failure to send, temporary Indicate Idle
error, failed CC event service
answer received, or error
Tx expired; requested
action CHECK_BALANCE or
PRICE_ENQUIRY
PendingE CC event answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED or service
USER_UNKNOWN and Tx running
[Page 52]
PendingE CC event answer Grant Idle
received with result code service
CREDIT_CONTROL_NOT_APPLICABLE; to end
requested action user
DIRECT_DEBITING
PendingE Failure to send, temporary Grant Idle
error, or failed CC event service
answer received; requested to end
action DIRECT_DEBITING; user
DDFH equal to CONTINUE
PendingE Failed CC event Terminate Idle
answer received or temporary end user's
error; requested action service
DIRECT_DEBITING;
DDFH equal to
TERMINATE_OR_BUFFER and
Tx running
PendingE Tx expired; requested Grant PendingE
action DIRECT_DEBITING service
to end
user
PendingE Failure to send; requested Store Idle
action DIRECT_DEBITING; request with
DDFH equal to T-flag
TERMINATE_OR_BUFFER
PendingE Temporary error; requested Store Idle
action DIRECT_DEBITING; request
DDFH equal to
TERMINATE_OR_BUFFER;
Tx expired
PendingE Failed answer or answer Idle
received with result code
END_USER_SERVICE DENIED or
USER_UNKNOWN; requested action
DIRECT_DEBITING; Tx expired
PendingE Failed CC event answer Indicate Idle
received; requested service
action REFUND_ACCOUNT error and
delete request
[Page 53]
PendingE Failure to send or Store Idle
Tx expired; requested request
action REFUND_ACCOUNT with T-flag
PendingE Temporary error, Store Idle
and requested action request
REFUND_ACCOUNT
PendingB Successful CC answer Delete Idle
received request
PendingB Failed CC answer Delete Idle
received request
PendingB Failure to send or Idle
temporary error
SERVER, SESSION AND EVENT BASED
State Event Action New State
----------------------------------------------------------------
Idle CC initial request Send Open
received and successfully CC initial
processed answer,
reserve units,
start Tcc
Idle CC initial request Send Idle
received but not CC initial
successfully processed answer with
Result-Code
!= SUCCESS
Idle CC event request Send Idle
received and successfully CC event
processed answer
Idle CC event request Send Idle
received but not CC event
successfully processed answer with
Result-Code
!= SUCCESS
Hakala, et al. Standards Track [Page 54]
RFC 4006 Diameter Credit-Control Application August 2005
Open CC update request Send CC Open
received and successfully update answer,
processed debit used
units,
reserve
new units,
restart Tcc
Open CC update request Send Idle
received but not CC update
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
Open CC termination request Send Idle
received and successfully CC termin.
processed answer,
Stop Tcc,
debit used
units
Open CC termination request Send Idle
received but not CC termin.
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
Open Session supervision timer Tcc Release Idle
expired reserved
units
8. Credit-Control AVPs
本章中定义了Dcc应用特性和可能在Dcc消息中使用的cc Avp.
如果像Section 5.2中描述的,"第一次询问"作为授权/认证处理的一部分,定义在本章中的Avp还可能在授权特性应用中使用,如[NASREQ]和[DIAMMIP].
[Page 55]
Diameter Avp规则定义在[DIAMBASE]的Section 4中,本章也会准守这些规则.
下面的表描述了在cc应用中定义的Diameter Avp,和Avp的Code值,类型,可能还有标志值,还有是否需要被编码.[DIAMBASE]在Section 4.5中指出了Avp标志的规则.
+--------------------+
| AVP Flag rules |
|----+-----+----+----|----+
AVP Section | | |SHLD|MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr|
-----------------------------------------|----+-----+----+----|----|
CC-Correlation-Id 411 8.1 OctetString| | P,M | | V | Y |
CC-Input-Octets 412 8.24 Unsigned64 | M | P | | V | Y |
CC-Money 413 8.22 Grouped | M | P | | V | Y |
CC-Output-Octets 414 8.25 Unsigned64 | M | P | | V | Y |
CC-Request-Number 415 8.2 Unsigned32 | M | P | | V | Y |
CC-Request-Type 416 8.3 Enumerated | M | P | | V | Y |
CC-Service- 417 8.26 Unsigned64 | M | P | | V | Y |
Specific-Units | | | | | |
CC-Session- 418 8.4 Enumerated | M | P | | V | Y |
Failover | | | | | |
CC-Sub-Session-Id 419 8.5 Unsigned64 | M | P | | V | Y |
CC-Time 420 8.21 Unsigned32 | M | P | | V | Y |
CC-Total-Octets 421 8.23 Unsigned64 | M | P | | V | Y |
CC-Unit-Type 454 8.32 Enumerated | M | P | | V | Y |
Check-Balance- 422 8.6 Enumerated | M | P | | V | Y |
Result | | | | | |
Cost-Information 423 8.7 Grouped | M | P | | V | Y |
Cost-Unit 424 8.12 UTF8String | M | P | | V | Y |
Credit-Control 426 8.13 Enumerated | M | P | | V | Y |
Credit-Control- 427 8.14 Enumerated | M | P | | V | Y |
Failure-Handling | | | | | |
Currency-Code 425 8.11 Unsigned32 | M | P | | V | Y |
Direct-Debiting- 428 8.15 Enumerated | M | P | | V | Y |
Failure-Handling | | | | | |
Exponent 429 8.9 Integer32 | M | P | | V | Y |
Final-Unit-Action 449 8.35 Enumerated | M | P | | V | Y |
Final-Unit- 430 8.34 Grouped | M | P | | V | Y |
Indication | | | | | |
Granted-Service- 431 8.17 Grouped | M | P | | V | Y |
Unit | | | | | |
G-S-U-Pool- 453 8.31 Unsigned32 | M | P | | V | Y |
Identifier | | | | | |
[Page 56]
G-S-U-Pool- 457 8.30 Grouped | M | P | | V | Y |
Reference | | | | | |
Multiple-Services 456 8.16 Grouped | M | P | | V | Y |
-Credit-Control | | | | | |
Multiple-Services 455 8.40 Enumerated | M | P | | V | Y |
-Indicator | | | | | |
Rating-Group 432 8.29 Unsigned32 | M | P | | V | Y |
Redirect-Address 433 8.38 Enumerated | M | P | | V | Y |
-Type | | | | | |
Redirect-Server 434 8.37 Grouped | M | P | | V | Y |
Redirect-Server 435 8.39 UTF8String | M | P | | V | Y |
-Address | | | | | |
Requested-Action 436 8.41 Enumerated | M | P | | V | Y |
Requested-Service 437 8.18 Grouped | M | P | | V | Y |
-Unit | | | | | |
Restriction 438 8.36 IPFiltrRule| M | P | | V | Y |
-Filter-Rule | | | | | |
Service-Context 461 8.42 UTF8String | M | P | | V | Y |
-Id | | | | | |
Service- 439 8.28 Unsigned32 | M | P | | V | Y |
Identifier | | | | | |
Service-Parameter 440 8.43 Grouped | | P,M | | V | Y |
-Info | | | | | |
Service- 441 8.44 Unsigned32 | | P,M | | V | Y |
Parameter-Type | | | | | |
Service- 442 8.45 OctetString| | P,M | | V | Y |
Parameter-Value | | | | | |
Subscription-Id 443 8.46 Grouped | M | P | | V | Y |
Subscription-Id 444 8.48 UTF8String | M | P | | V | Y |
-Data | | | | | |
Subscription-Id 450 8.47 Enumerated | M | P | | V | Y |
-Type | | | | | |
Tariff-Change 452 8.27 Enumerated | M | P | | V | Y |
-Usage | | | | | |
Tariff-Time 451 8.20 Time | M | P | | V | Y |
-Change | | | | | |
Unit-Value 445 8.8 Grouped | M | P | | V | Y |
Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y |
User-Equipment 458 8.49 Grouped | | P,M | | V | Y |
-Info | | | | | |
User-Equipment 459 8.50 Enumerated | | P,M | | V | Y |
-Info-Type | | | | | |
User-Equipment 460 8.51 OctetString| | P,M | | V | Y |
-Info-Value | | | | | |
Value-Digits 447 8.10 Integer64 | M | P | | V | Y |
Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y |
[Page 57]
8.1. CC-Correlation-Id AVP
CC-Correlation-Id Avp (Avp Code 411)类型是OctectString,该Avp包含了对不同的服务组件授权的cc"请求"相关的信息.例如,传输层和服务层.分配Service-Context-Id的组件需要定义CC-Correlation-Id的内容,并且对其编码.
8.2. CC-Request-Number AVP
CC-Request-Number Avp(Avp Code 415)的类型是Unsigned32,代表一个会话中的"请求".像Session-Id Avp为全局唯一的一样,CC-Request-Number和Session-Id组合到一起也是全局唯一的,并且可以用来确认匹配的cc消息.一个生成唯一数组的简单方法是,对INITIAL_REQUEST和EVENT_REQUEST的Ccr设置该Avp为0,对第一个UPDATE_REQUEST设置为1,第二个UPDATE_REQUEST设置为2,以此类推,直到TERMINATION_REQUEST的Ccr.
8.3. CC-Request-Type AVP
CC-Request-Type Avp (Avp Code 416)类型为Enumerated,该Avp中的内容为发送Ccr消息的原因.在所有的Ccr消息中必须有CC-Request-Type.下面是对该Avp的值的定义.
INITIAL_REQUEST 1
表明消息是一个初始化的请求,用于初始化cc会话,在这个请求中包含了初始化相关的cc信息.
UPDATE_REQUEST 2
表示消息是一个更新请求,该请求中包含了一个已经存在的cc会话的cc信息.当配额耗尽或者是Validity-Time超期时,需要cc重授权的时候,应该发送更新的Ccr. 除此之外,附加的service-specific事件也可能触发一个自发的"更新请求".
TERMINATION_REQUEST 3
表明请求为一个"结束的请求",用于结束一个cc会话,在这个请求中有会话相关的cc信息.
[Page 58]
EVENT_REQUEST 4
表明请求时一个"事件类型的请求",当在cc服务器中,不需要维护cc会话状态时使用这种类型的"请求".该请求中会包含所有和服务相关的信息,而且是这个服务的唯一的"请求消息"."事件类型的请求"的原因的更详细信息会在Requested-Action Avp中描述.当CC-Request-Type Avp的值是EVENT_REQUEST时,必须包含Requested-Action Avp.
8.4. CC-Session-Failover AVP
CC-Session-Failover (Avp Code 418)Avp的类型是Enumerated,包含了的信息,指明在一个会话进行期间是否支持转移cc消息流到一个备用服用器上.在通信异常时,如果cc服务器支持failover到一个可选择的服务器上,cc消息流可以转移到一个可选择的目标上.从Diameter AAA服务器获得的备用cc服务器的名字,可被作为备用服务器的地址来使用.支持cc消息流转移到备用服务器上的功能不是必须要支持的.
下面定义了CC-Session-Failover Avp的值:
FAILOVER_NOT_SUPPORTED 0
当CC-Session-Failover的值是FAILOVER_NOT_SUPPORTED时,在通信异常时,cc消息流不能转移到备用的服务器上.
当在应答的消息中没有这个Avp时,默认为这个值.
FAILOVER_SUPPORTED 1
当CC-Session-Failover Avp的值为FAILOVER_SUPPORTED时,在通信异常时,应该把cc消息流转移到可选目标上.转移cc消息流到备用服务器上后,之后这个cc会话的信息应该都发送到备用的服务器上.
8.5. CC-Sub-Session-Id AVP
CC-Sub-Session-Id (Avp Code 419)Avp的类型是Unsigned64,包含了cc子会话的标识符.和Session-Id组合在一起,每个子会话这个Avp的值必须是唯一的,并且这个值对于所有新的子会话都是递增的,每次增加1. 没有这个Avp时,说明没有子会话.
[Page 59]
8.6. Check-Balance-Result AVP
(Avp Code 422)类型为Enumerated,包含了余额检查的结果.这个Avp仅仅在Ccr的Requested-Action Avp的值是CHECK_BALANCE时适用.
下面定义了Check-Balance-Result Avp的值:
ENOUGH_CREDIT 0
账户中的余额足够付清当前所请求的服务的费用
NO_CREDIT 1
账户中的余额不足,不能付清服务的费用
8.7. Cost-Information AVP
(Avp Code 423)类型是Grouped,用于返回服务的费用信息,cc客户端可以直接把服务传递给用户.该Avp中的Unit-Value Avp包含了对服务的费用估值.
Currency-Code指明已给出的费用的货币类型,Cost-Unit 指出费用的单位.(如,每分钟$1)
当在Ccr中的Requested-Action Avp的值是PRICE_ENQUIRY,不需要做信用预留,在发送的Cca中的Cost-Information Avp中会有被请求的服务的费用的估值.
在CC-Request-Type为UPDATE_REQUEST的Cca中的Cost-Information Avp包含了对会话的估值的计算.并且不需要对账户信用预留.
[Page 60]
在CC-Request-Type为EVENT_REQUEST或是TERMINATION_REQUEST的Cca中的Cost-Information Avp 包含了对请求的服务的费用的估值.
定义如下:(每个RFC 3588 [DIAMBASE]的grouped-avp-def)
Cost-Information ::= < AVP Header: 423 >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]
8.8. Unit-Value AVP
Unit-Value Avp(Avp Code 445),类型为Grouped,以10进制指出了单元数. Unit-Value是一个指数值.例如,Unit-Value = Value-Digits Avp * 10^Exponent. 这样的表示避免不想要的四舍五入.例如,值2.3被展现为Value-Digits = 23, Exponent = -1. 没有Exponent的情况下,认为Exponent的值是0.
定义如下:
Unit-Value ::= < AVP Header: 445 >
{ Value-Digits }
[ Exponent ]
8.9. Exponent AVP
Exponent Avp(Avp Code 429)类型Integer32, 在Unit-Value Avp中为Value-Digits Avp提供指数值.
8.10. Value-Digits AVP
Value-Digits Avp(Avp Code 447)类型为Interger64, 包含了一个重要的数字. 如果需要使用十进制表示单元数, 必须使用Exponent Avp指出指数.例如, 钱$0.05的Value-Digits Avp的值是5, 指数值Exponent Avp为-2.
[Page 61]
8.11. Currency-Code AVP
Currency-Code Avp(Avp Code 425),类型为Unsigned32,包含了一个货币代码,指出了在ISO 4217中定义的数字值.
8.12. Cost-Unit AVP
Cost-Unit Avp (Avp Code 424),类型为UTF8String,用于展示一个用户可读的字符串.当服务的费用是每个单位的费用时,指出了适合的单位(例如,服务的费用是$1每分钟). Cost-Unit可以是分,小时,天,kb,mb,等等.
8.13. Credit-Control AVP
Credit-Control Avp(Avp Code 426),类型为Enumerated,当网元有cc能力的时候在AA的请求中必须有这个Avp.
CREDIT_AUTHORIZATION 0
如果主Diameter AAA服务器确定用户有预付费订购,这个值指出了必须连接cc服务器,执行"第一次询问". 在发送执行"第一次询问"和初始化一个新cc会话的AA请求中Credit-Control Avp的值必须设置成0.
RE_AUTHORIZATION 1
这个值暗示Diameter AAA服务器一个用户的cc会话正在运行,并且不能连接cc服务器.Credit-Control Avp设置为1时,仅在"第一次询问被成功执行并且cc会话正在运行时.在AA发送的"第一次询问"的请求中不能使用这个值.
8.14. Credit-Control-Failure-Handling AVP
Credit-Control-Failure-Handling Avp (Avp Code 427),缩写为CCFH,类型是Enumerated. cc客户端使用这个Avp中的信息决定当发送cc消息给cc服务器发生临时的异常时(这个异常时由网络引起的)要做些什么.根据服务逻辑,当有一个原因可以确信服务没有被付费时,cc服务器可以命令客户端立即结束服务,或者是把failover发送给一个备选服务器. 然后服务器会结束服务或者批准服务, 备用服务器的连接也可能失败.
[Page 62]
TERMINATE 0
当CCFH的值是TERMINATE时,服务的时间必须被批准为和cc服务器的链接一样长.如果cc客户端在定时器Tx超期之前,没有收到任何的Cca消息,Ccr被认为失败,并且用户的服务会话被结束.
如果在授权或者是cc服务器的应答中没有CCFH Avp,TERMINATE是默认的行为.
CONTINUE 1
当CCFH Avp被设置为CONTINUE时,在提供了一个failover处理步骤,在cc服务器和客户端都支持并且备用服务器可用的情况下, 当出现传输临时异常时,cc客户端应该重新发送"请求"给备用服务器. 否则即使cc消息不能被传递,服务也应该被批准.
RETRY_AND_TERMINATE 2
当CCFH Avp 被设置为RETRY_AND_TERMINATE,在提供了一个failover处理步骤,在cc服务器和客户端都支持并且备用服务器可用的情况下, 当出现传输临时异常时,cc客户端应该重新发送"请求"给备用服务器.否则,当cc消息不能被传递的情况下,不应该批准服务.
8.15. Direct-Debiting-Failure-Handling AVP
Direct-Debiting-Failure-Handling Avp(Avp Code 428)缩写为DDFH,类型是Enumerated. cc客户端使用DDFH中的信息来决定当发送的Requested-Action Avp设置为DIRECT_DEBITING的cc消息发生网络异常时要做些什么.
TERMINATE_OR_BUFFER 0
当DDFH Avp的值设置为TERMINATE_OR_BUFFER时,服务的时间必须被批准为和cc服务器的链接一样长. 如果cc客户端在给定的定时器Tx时间内,没有收到任何Cca消息,本次的Ccr消息被认为失败.如果能从失败的应答中确定没有任何资源被扣减的话,客户端应该结束服务. 否则cc客户端应该批准服务,把"请求"保存到本地固定存储上,并且应该尝试再次发送"请求". 再次发送的"请求"必须使用T-flag表示是一个重复的"请求".
[Page 63]
如果在授权服务器的响应中没有这个Avp时,上面提到的作为默认的处理.
CONTINUE 1
当DDFH Avp设置为CONTINUE时,即使cc消息不能被传递,服务也应该被批准,同时应该不保存"请求".
8.16. Multiple-Services-Credit-Control AVP
Mutiple-Services-Credit-Control Avp(Avp Code 456),缩写MSCC,类型是Grouped,包含了依靠cc的多服务特性的相关的Avp.注意,每个Avp的实例中都承载了一个或多个服务的用量或者是一个计费组的用量.
Service-Identifier 和Rating-Group Avp用于协助对一个给定的服务或者是计费组的授权量. 如果包含了这两个Avp,服务单元的数量是属于Service-Identifier Avp指定的服务的. 如果只给了Rating-Group-Id, MSCC Avp把所有属于指定Rating-Group的服务关联在一起.
G-S-U-Pool-Reference Avp允许服务器指定一个G-S-U-Pool-Identifier标示一个在指定类型的单元数被认为形成池的信用池.如果有G-S-U-Pool-Reference AVP,那么就必须有指定类型的服务单元数.例如,如果G-S-U-Pool-Reference Avp指定了Unit-Type为TIME,那么,必须有CC-Time Avp.
[Page 64]
Requested-Service-Unit Avp可能包含请求的服务单元的数量,或者是请求的钱的数量, 在"初始化的询问"中必须有这个Avp,并且在有新配额的请求中也必须有这个Avp. 如果cc客户端在一个"请求"中没有这个Avp,那就是客户端已经确定用户结束服务,服务器必须从用户账户上扣减使用量,并在对应的应答中不能返回一个新的配额. Validity-Time, Result-Code, 和Final-Unit-Indication Avp可能会在一个应答中出现,具体的请参考Section 5.1.2和5.6
当Tariff-Time-Change 和 Tariff-Change-Usage Avp都出现时,服务器必须包含两个分开的MSCC Avp,MSCC Avp中有同一个Service-Identifier 或者是Rating-Group的Granted-Service-Unit Avp. 这两个配额可以是关联到同一个池,或者是不同的池, 在Section 5.1.2中定义了信用池机制. Tariff-Change-Usage Avp必须不能被包含在用于报告之前使用量的"请求"中,在费率改变后必须使用Used-Service-Unit Avp.
一个不实施多服务cc的服务器,必须把MSCC Avp作为不可用Avp处理.
Avp结构定义:
Multiple-Services-Credit-Control ::= < AVP Header: 456 >
[ Granted-Service-Unit ]
[ Requested-Service-Unit ]
*[ Used-Service-Unit ]
[ Tariff-Change-Usage ]
*[ Service-Identifier ]
[ Rating-Group ]
*[ G-S-U-Pool-Reference ]
[ Validity-Time ]
[ Result-Code ]
[ Final-Unit-Indication ]
*[ AVP ]
8.17. Granted-Service-Unit AVP
Granted-Service-Unit Avp (Avp Code 431),类型是Grouped,包含了直到服务结束或者是发送新的Ccr之前Dcc客户端可以提供给用户的单元数量.不要求客户端支持所有的单位类型,当在应答消息中有不支持或者不知道的单位类型时,要把这个应答消息作为错误的Cca应答. 在这种情况下,客户端必须结束cc会话,并且在Termination-Cause Avp中设置DIAMETER_BAD_ANSWER指出原因.
[Page 65]
Avp定义:
Granted-Service-Unit ::= < AVP Header: 431 >
[ Tariff-Time-Change ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
8.18. Requested-Service-Unit AVP
Requested-Service-Unit ::= < AVP Header: 437 >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
Requested-Service-Unit Avp(Avp Code 437),类型是Grouped,包含了Dcc客户端请求的单元数.不要求服务器支持所有的单位类型,服务器必须对不支持的单位类型作为不可用Avp.
8.19. Used-Service-Unit AVP
Used-Service-Unit Avp(Avp Code 446), 类型是Grouped,包含了从服务被激活或者是在会话中的"临时询问"起,使用了的单元数.
[Page 66]
Used-Service-Unit ::= < AVP Header: 446 >
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
8.20. Tariff-Time-Change AVP
Tariff-Time-Change Avp(Avp Code 451),类型是Time. 这个Avp是服务器发给客户端的,Avp的值是从1900年的1月1日00:00起开始计算,到费率变化时的秒数.
对于客户端和服务端来说,费率变化机制是可选的, 并且对在Section 5中定义的time-based服务不使用费率变化机制.如果客户端不支持费率时间改变机制, 客户端必须把Tariff-Time-Change Avp作为错误的Cca应答. 在这种情况下, 客户端要结束cc会话,并设置Termination-Cause Avp为DIAMETER_BAD_ANSWER说明原因.
没有这个Avp代表没有费率改变要报告.
8.21. CC-Time AVP
CC-Time Avp(Avp Code 420),类型是Unsigned32, Avp的值是请求的,授权的或者是使用的以秒为单位的时长.
8.22. CC-Money AVP
CC-Money Avp(Avp Code 413), 类型是Grouped, 指出了给定货币的钱数. 这个Avp中应该包含Currency-Code Avp.
CC-Money ::= < AVP Header: 413 >
{ Unit-Value }
[ Currency-Code ]
[Page 67]
8.23. CC-Total-Octets AVP
CC-Total-Octets Avp (Avp Code 421),类型是Unsigned64,包含了(发送的和接收的)请求的,授权的,或者是使用的字节总数.
8.24. CC-Input-Octets AVP
CC-Input -octets AVP (Avp Code 412), 类型是Unsigned64, 包含了从用户那里接收到的字节数(请求的,授权的,或者是使用的).
8.25. CC-Output-Octets AVP
CC-Output-Octests Avp(Avp Code 414),类型是Unsigned64, 包含了发送给用户的字节数(请求的,授权的,或者是使用的).
8.26. CC-Service-Specific-Units AVP
CC-Service-Specific-Units Avp (Avp Code 417),类型是Unsigned64, 指出了在一个被选择的服务给出的Service-Specific单元数. service-specific 单元数属于Service-Identifier Avp指定的服务.(或者是属于Mutiple-Services-Credit-Control Avp中的Rating-Group Avp指定的服务).
8.27. Tariff-Change-Usage AVP
Tariff-Change-Usage Avp (Avp Code 452),类型是Enumerated, 定义了单元数是费率变化之前还是之后使用的单元数,或者是在报告费率改变期间的不明确的使用单元数.如果没有该Avp的意识是指没有费率变化发生.
另外, 当在应答的消息中Multiple-Services-Credit-Control Avp中有这个Avp, 那么Tariff-Change-Usage Avp定义了单元数是分配给费率变化前或者变化后的.
当在请求中有Tariff-Time-Change Avp,在应答的消息中没有这个Avp,表示只提供单独的配额机制.
Tariff-Change-Usage 可以是下面的值:
UNIT_BEFORE_TARIFF_CHANGE 0
当在Multiple-Services-Credit-Control Avp中的Tariff-Change-Usage Avp值是UNIT_BEFORE_TARIFF_CHANGE, 指出在费率改变发生之前使用的配额数.
当在Used-Service-Unit Avp中的Tariff-Change-Usage Avp的值是UNIT_BEFORE_TARIFF_CHANGE, 指出在费率改变前使用的的资源数.
[Page 68]
UNIT_AFTER_TARIFF_CHANGE 1
当Multiple-Services-Credit-Control Avp中有这个值,表示费率改变后可以使用的配额.
当Used-Service-Unit Avp中有这个值时,表示费率改变后使用了的资源数.
UNIT_INDETERMINATE 2
表示使用了的单元数是发送在费率改变这个点上的, 这个值仅在Used-Service-Unit Avp中使用.
8.28. Service-Identifier AVP
Service-Identifier Avp (Avp Code 439),类型是Unsigned32, 包含了服务的标识符. 请求关联到的特定服务是由Service-Identifier 和 Service-Identifier Avp组合成的唯一的标识.
在Appendix A(Flow IX)中有一个详细的例子.
8.29. Rating-Group AVP
Rating-Group Avp (Avp Code 432),类型是Unsigned32, 包含了计费组的标识符. 所有计费类型相同的服务科目都是同一个计费组的一部分. 请求关联的指定的计费组是由Service-Context-Id和Rating-Group Aap 组合成的唯一的标识.
在Appendix A(Flow IX)中有一个详细的例子.
8.30. G-S-U-Pool-Reference AVP
G-S-U-Pool-Reference Avp (Avp Code 457),类型是Grouped. 被用于Cca消息中, 在会话中的联合Granted-Service-Unit Avp,用来表示信用池.
G-S-U-Pool-Identifier Avp指出对这个单位类型所抽取信用的信用池.
[Page 69]
CC-Unit-Type Avp 指出信用池的单位类型.
Unit-Value Avp 指出了在信用池内,抽象的服务单元数和CC-Unit-Type类型的服务单元数直接的乘数.
G-S-U-Pool-Reference ::= < AVP Header: 457 >
{ G-S-U-Pool-Identifier }
{ CC-Unit-Type }
{ Unit-Value }
8.31. G-S-U-Pool-Identifier AVP
G-S-U-Pool-Identifier Avp(Avp Code 453),类型是Unsigned32, 标识会话中的一个信用池.
8.32. CC-Unit-Type AVP
CC-Unit-Type Avp(Avp Code 454) 类型是Enumerated, 指出了被认为聚集在一个信用池中的服务单元的类型.
CC-Unit-Type AVP的值如下:
TIME 0
MONEY 1
TOTAL-OCTETS 2
INPUT-OCTETS 3
OUTPUT-OCTETS 4
SERVICE-SPECIFIC-UNITS 5
8.33. Validity-Time AVP
Validity-Time Avp(Avp Code 448),类型是Unsigned32, 这个Avp是有cc服务器发送给客户端的. 该Avp包含了授权的服务单元数的有效时间. 对Validity-Time的计算,是从收到有这个Avp的Cca开始, 如果配额在这个Avp指定的有效时间内没有被消耗, cc客户端必须发送一个CC-Request-Type是UPDATE_REQUEST的Ccr给服务器. Validity-Time 中的值是秒.
Validity-Time Avp 也会被用在结束服务上,用来指出当发生REDIRECT或者是RESTRICT_ACCESS时, cc客户端允许用户接入的时长. 当Validity-Time期满时,cc客户端发送一个"中间询问"给服务器.
[Page 70]
8.34. Final-Unit-Indication AVP
Final-Unit-Indication Avp(Avp Code 430),类型是Grouped, 指出了Cca或者AA应答中的Granted-Service-Unit Avp中的是最后的服务量. 在这些服务量被耗尽后,Dcc客户端要执行Final-Unit-Indication Avp中给出的动作.
如果在接收到的Cca中有不只一个单位类型, 当第一个耗尽时,cc客户端要执行指定的动作.
在"第一次询问"中, 在Cca或者AA 应答中没有Granted-Service-Unit时也可以包含值为REDIRECT或者RESTRICT_ACCESS的Final-Unit-Action的Final-Unit-Indication Avp. 这指明Dcc客户端要立即执行指定的动作. 如果主服务提供者的策略是结束服务, 自然地, 为了执行policy-defined 中给的动作,服务器返回适当的临时异常.
当用户的账户不能付清服务费用时, Final-Unit-Action Avp 定义了网元的处理动作,如果有Final-Unit-Indication Avp时,必须有Final-Unit-Action avp.
如果Final-Unit-Action Avp设置为TERMINATE时,就不能有其他的Avp.
如果Final-Unit-Action Avp的值是REDIRECT, 在Final-Unit-Indication Avp中至少有一个Redirect-Server Avp. 如果运行用户可以接入到通过Redirect-Server Avp指定的地址不能被接入的服务中,在Cca消息中可能有Restriction-Filter-Rule Avp或者是Filter-Id Avp.
[Page 71]
如果Final-Unit-Action Avp被设置为RESTRICT_ACCESS, 就应该有Restriction-Filter-Rule Avp或者Filter-Id Avp.
Filter-Id Avp定义在[NASREQ]. Filter-Id Avp可以被用来查询一个接入设备上装载的Ip过滤队列,不仅限于Dcc应用.例如, 本地配置的,或者是其他实例配置的.
Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]
8.35. Final-Unit-Action AVP
Final-Unit-Action Avp (Avp Code 449),类型是Enumerated, 指明当用户的账户不能付清费用时cc客户端执行的动作.
Final-Unit-Action 的值定义如下:
TERMINATE 0
cc客户端必须结束服务会话.当无论什么时候cc客户端收到一个不支持的Final-Unit-Action值时,这个是默认的处理.所有遵循本文档的Dcc客户端都必须支持这个动作.
REDIRECT 1
网元必须把用户重定向到Redirect-Server-Address Avp指定的地址. 在Section 5.6.2定义了重定向.
RESTRICT_ACCESS 2
接入设备必须根据Restriction-Filter-Rule Avp中定义的Ip过滤器或者是Filter-Id中定义的Ip过滤器限制用户的接入. 所有和过滤器不匹配的消息包,必须被丢弃.(Section 5.6.3)
8.36. Restriction-Filter-Rule AVP
Restriction-Filter-Rule Avp (Avp Code 438) 类型是IPFilterRule, 提供了相应的服务过滤规则, 这些服务即使没有配额也可以接入. 接入设备没有对用户配置指定的过滤规则, 必须丢弃所有不符合这些过滤规则的消息包. 在Cca和AA应答消息中可以包含1个或多个Restriction-Filter-Rule Avp.
[Page 72]
8.37. Redirect-Server AVP
Redirect-Server Avp (Avp Code 434) 类型是Grouped, 包含了重定向服务器的地址信息, 当用户账户余额不足的时候,用户将被连接到这个服务器上. 当Final-Unit-Acion Avp的值是REDIRECT时,就必须有这个地址.
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }
8.38. Redirect-Address-Type AVP
Redirect-Address-Type Avp (Avp Code 433) 类型是Enumerated, 定义了Redirect-Server-Address给出的地址的类型.
下面定义了Avp的值:
IPv4 Address 0
定义了地址类型是"点-十进制"的IPv4地址.和[IPv4]中定义的一样.
IPv6 Address 1
定义了地址类型是和[IPv6Addr]中定义的一样的IPv6的地址, 这个地址是用文本描述的地址. 实例必须支持推荐的形式,并且应该支持可选择的文本的IPv6地址.
URL 2
定义了地址类型是[URL]中定义的Uniform Resource Locator.
SIP URI 3
定义了地址类型是[SIP]中定义的SIP Uniform Resource Identifier.
[Page 73]
8.39. Redirect-Server-Address AVP
Redirect-Server-Address Avp (Avp Code 435), 类型是UTF8String, 定义了重定向服务器的地址, 当用户的账户余额不足时,用户将被连接到这个地址上.
8.40. Multiple-Services-Indicator AVP
Multiple-Services-Indicator Avp (Avp Code 455), 类型是Enumerated, 指出了在一个会话中Dcc客户端对多服务的处理能力. 没有这个Avp, 暗示不支持多cc服务.
不实施多cc服务的服务器,必须把Multiple-Services-Indicatore Avp作为一个不可用的Avp.
Multiple-Services-Indicatoer Avp的值如下:
MULTIPLE_SERVICES_NOT_SUPPORTED 0
客户端在一个会话内不支持多服务的独立cc.
MULTIPLE_SERVICES_SUPPORTED 1
客户端在一个会话内支持多服务的独立cc.
8.41. Requested-Action AVP
Requested-Action Avp (Avp Code 436), 类型是Enumerated, 包含了被CC-Request-Type是EVENT_REQUEST的Ccr发送的请求的动作. 下面定义了Requested-Action的值:
DIRECT_DEBITING 0
这个值指出一个请求是按照Requested-Service-Unit Avp或者是service-Identifier给出的信息扣减用户账户的请求. Cca中的Granted-Service-Unit Avp包含了扣减数量.
[Page 74]
REFUND_ACCOUNT 1
这个值指出请求是一个增加用户账户的请求,按照Requested-Service-Unit Avp和Service-Identifier Avp给出的信息,增加用户的账户. Cca中的Granted-Service-Unit 包含了退款的费用.
CHECK_BALANCE 2
这个值指出了请求是余额检查请求. 在这中情况下, 只对账户的余额做检查,并不做信用预留. 在Cca中Check-Balance-Result Avp给出了检查的结果.
PRICE_ENQUIRY 3
这个值指出了请求是一个询问价格的请求.在这种情况下, 即不检查账户余额,也不对账户做信用预留, 在Cca中仅仅把服务价格包含到Cost-Information Avp中返回.
8.42. Service-Context-Id AVP
Service-Context-Id Avp (Avp Code 461), 类型是UTF8String, 包含了应用于请求的Dcc服务特性文档的唯一标识符(定义在Section 4.1.2). 这个标识符是服务提供者分配的.Service-Context-Id的格式如下:
"service-context" "@" "domain"
service-context = Token
Token是任何字符和数字的字符串.
'domain' 表现的是被分配的Service-Context-Id的实例. 可一是ietf.org, 3gpp.org等等.
这个Avp应该尽可能放置在靠近Diameter消息头.
[Page 75]
服务特性文档被私自使用,第一个一个私有的标识符, 这种情况是不需要任何协作.然而, 当需要互通性时, 通过标识符的写作, 例如, 为了使Service-Context-Id全局可用, 建议使用一个发布的RFC.
8.43. Service-Parameter-Info AVP
Service-Parameter-Info Avp(Avp Code 440), 类型是Grouped, 包含了计算价格使用的service-specific 信息. Service-Parameter-Type Avp定义了服务参数类型, Service-Parameter-Value Avp包含了参数值. 这些Avp的时间内容不输入本文档的范围,应该定义在其他的Diameter应用中.
在未知的服务的请求的情况下,(例如, 未知的Service-Parameter-Type), 对应的应答消息必须包含DIAMETER_RATING_FAILED错误码. 有这个错误码的Cca消息必须包含一个或是多个Failed-AVP, 这个Avp中包含了引起异常的Service-Parameter-Info AVP.
Service-Parameter-Info ::= < AVP Header: 440 >
{ Service-Parameter-Type }
{ Service-Parameter-Value }
8.44. Service-Parameter-Type AVP
Service-Parameter-Type Avp (Avp Code 441), 类型是Unsigned32, 定义了服务事件特性参数的类型(如, 可以是用户的位置或是服务名). 不同的参数,它们的类型是服务特性, 这些参数没有定义在这个文档中. 无论是谁分配了Service-Context-Id(如, 一个服务特性文档的唯一标识符), 就有责任对分配服务的Service-Parameter-Type值, 并且保证它们在给出的服务中是唯一的. Service-Parameter-Value Avp包含了服务参数类型相关的值.
Hakala, et al. Standards Track [Page 76]
RFC 4006 Diameter Credit-Control Application August 2005
8.45. Service-Parameter-Value AVP
Service-Parameter-Value Avp (Avp Code 442), 类型是OctectString, 包含了服务参数类型的值.
8.46. Subscription-Id AVP
Subscription-Id Avp (Avp Code 443),类型是Grouped, 被用来标识用户, Subscription-Id Avp包含了Subscription-Id-Data Avp和Subscription-Id-Type Avp, Subscription-Id-Data给出标识符, Subscription-Id-Type给出了标识符的类型.
Subscription-Id ::= < AVP Header: 443 >
{ Subscription-Id-Type }
{ Subscription-Id-Data }
8.47. Subscription-Id-Type AVP
Subscription-Id-Type Avp (Avp Code 450),类型是Enumerated, 被用来确定Subscription-Id中携带的标识符的类型.
这个文档定义了下面的用户标识符, 在Section 12中定义了被IANA的专家分配的新的Subscription-Id-Type.服务器必须实施所有的要求的Subscription-Id-Types, 用于执行对他支持的服务的信用授权, 可能还会有更多的值. 必须根据[DIAMBASE]中定义的'M'标识符规则,处理未知的或者是不支持的Subscription-Id-Types.
END_USER_E164 0
标识符是国际E.164格式(如, MSISDN), 依照[E164]和[CE164]中定义的ITU-T E.164数字计划.
END_USER_IMSI 1
标识符是国际的IMSI格式, 依照[E212]和[CE212]中定义的 ITU-T E.212数字计划.
END_USER_SIP_URI 2
标识符是[SIP]中定义的SIP URI格式.
END_USER_NAI 3
标识符是定义在[NAI]中的网络接入标识符的格式.
[Page 77]
END_USER_PRIVATE 4
标识符是cc服务器的是有标识符.
8.48. Subscription-Id-Data AVP
Subscription-Id-Data Avp (Avp Code 444), 类型是UTF8String, 用于标识用户. Subscription-Id-Type Avp定义了标识符的类型.
8.49. User-Equipment-Info AVP
User-Equipment-Info Avp (Avp Code 458), 类型是Grouped, 允许cc客户端指出正在连接网络的,使用中的终端用户的标识和能力.
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
8.50. User-Equipment-Info-Type AVP
User-Equipment-Info-Type Avp (Avp Code 459), 类型是Enumerated, 定义了包含在User-Equipment-Info-Value Avp中的用户设备的类型.
这个文档定义了一些设备类型.被IANA分配的新的User-Equipment-Info-Type 值在Section 12.
IMEISV 0
标识符包含了国际移动设备标识符和3GPP TS 23.003[3GPPIMEI]中国际IMEISV的软件版本.
MAC 1
48-bit MAC地址,格式定义在[RAD802.1X]中.
EUI64 2
64-bit 标识符, 用于标识产品实例的硬件.详细的定义在[EUI64]中.
[Page 78]
MODIFIED_EUI64 3
有很多终端类型, 不止有IMEI, IEEE 802 MAC和EUI-64. 这些标识符可以被转换成[IPv6Addr]中被修改的EUI-64格式,或者是通过服务特性文档中使用的一些其他方法转换成的EUI-64.
8.51. User-Equipment-Info-Value AVP
User-Equipment-Info-Value Avp (Avp Code 460), 类型是OctetString.
9. Result Code AVP Values
本章定义了新的Result-Code Avp [DIAMBASE]的值,所有按照本文档实现的实例都必须支持这些值.
在Cca中会有Result-Code Avp, Ccr中也可以有Result-Code,用于表示错误. 收到错误的Ccr消息后应该结束用户的会话.
9.1. Transient Failures (传输错误)
属于传输失败类型的错误, 这些错误用于告知对端可能不能接收请求,但将来可能可以接收请求.
DIAMETER_END_USER_SERVICE_DENIED 4010
CC服务器根据服务限制定义了"服务请求". 如果在Ccr中包含Used-Service-Units Avp, 要从账户上扣减Used-Service-Units中的使用量或费用.
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011
Cca决定是否授权用户的服务,但是不能决定服务需要的更多的cc.(例如, 免费的服务).
DIAMETER_CREDIT_LIMIT_REACHED 4012
cc服务器定义了"服务请求"是用户余额不足的服务请求. 如果Ccr包含Used-Service-Units,要从用户账户上扣掉Used-Service-Units中给出的使用量或者费用.
[Page 79]
9.2. Permanent Failures (永久的错误)
"永久的错误"用于通知对端"请求失败"并且不应该再发送.
DIAMETER_USER_UNKNOWN 5030
cc服务器不能识别指定的用户.
DIAMETER_RATING_FAILED 5031
这个错误码用于告知cc客户端:"由于计费参数不足(包括错误的Avp组合,或者是计费不支持和不认识的Avp),cc服务器不能计算'服务请求'的费用.必须包含Failed-Avp,在这个Avp中包含了引起错误的Avp的全部信息,如果缺少Avp时,应该不要写到Failed-Avp中.
10. AVP Occurrence Table
下面的表格定义了在Diameter消息中Avp的情况,注意表格中没有体现出只有在Grouped中才有的Avp,
标识符:
0 消息中必须有这个Avp.
0+ 消息中可以有0个活多个Avp
0-1 消息中可以有0个或者1个Avp, 如果出现更多的,被认为是错误.
1 消息中必须有有,并且只能有一个Avp.
1+ 消息中必须至少有一个Avp.
[Page 80]
10.1. Credit-Control AVP Table
本章中的表定义了cc应用中cc消息包含的文档中指定的Avp.
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | CCR | CCA |
------------------------------|-----+-----+
Acct-Multi-Session-Id | 0-1 | 0-1 |
Auth-Application-Id | 1 | 1 |
CC-Correlation-Id | 0-1 | 0 |
CC-Session-Failover | 0 | 0-1 |
CC-Request-Number | 1 | 1 |
CC-Request-Type | 1 | 1 |
CC-Sub-Session-Id | 0-1 | 0-1 |
Check-Balance-Result | 0 | 0-1 |
Cost-Information | 0 | 0-1 |
Credit-Control-Failure- | 0 | 0-1 |
Handling | | |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Direct-Debiting-Failure- | 0 | 0-1 |
Handling | | |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0+ |
Final-Unit-Indication | 0 | 0-1 |
Granted-Service-Unit | 0 | 0-1 |
Multiple-Services-Credit- | 0+ | 0+ |
Control | | |
Multiple-Services-Indicator | 0-1 | 0 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ |
Redirect-Host | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 |
Requested-Action | 0-1 | 0 |
Requested-Service-Unit | 0-1 | 0 |
Route-Record | 0+ | 0+ |
Result-Code | 0 | 1 |
Service-Context-Id | 1 | 0 |
Service-Identifier | 0-1 | 0 |
Service-Parameter-Info | 0+ | 0 |
[Page 81]
Session-Id | 1 | 1 |
Subscription-Id | 0+ | 0 |
Termination-Cause | 0-1 | 0 |
User-Equipment-Info | 0-1 | 0 |
Used-Service-Unit | 0+ | 0 |
User-Name | 0-1 | 0-1 |
Validity-Time | 0 | 0-1 |
------------------------------|-----+-----+
10.2. Re-Auth-Request/Answer AVP Table
本章定义了Dcc应用中指定的Avp, 这些Avp可能会在Diameter (Rar/Raa)消息中.
Rar/Raa 可能包含下面附加的Avp:
+---------------+
| Command Code |
|-------+-------+
Attribute Name | RAR | RAA |
------------------------------+-------+-------+
CC-Sub-Session-Id | 0-1 | 0-1 |
G-S-U-Pool-Identifier | 0-1 | 0-1 |
Service-Identifier | 0-1 | 0-1 |
Rating-Group | 0-1 | 0-1 |
------------------------------+-------+-------+
11. RADIUS/Diameter Credit-Control Interworking Model
本章定义了预付费 inter-working 模式的Dcc/RADIUS的基本原理; 定义了基于预付费解决方案的RADIUS和Dcc应用之间的消息传输.阐述了RADIUS和Dcc应用之间的传输协议.
Dcc框架中可以使用有和RADIUS通信能力的传输代理, AAA服务器对于使用cc机制的服务节点(网元),可以表现为传输代理和Dcc客户端.在这种情况下,在授权处理时需要主AAA服务器连接Dcc服务器. Figure 7阐述了交互结构, Figure 8中描述了交互流.在漫游的情况下,服务节点可以被放置在被访问的网络中,并且连接拜访的AAA服务器,之后拜访的AAA服务器连接主AAA服务器.
[Page 82]
RADIUS Prepaid
+--------+ +---------+ protocol +------------+ +--------+
| End |<----->| Service |<---------->| Home AAA | |Business|
| User | | Element | | Server | |Support |
+--------+ +-->| | |+----------+|->|System |
| +---------+ ||CC Client || | |
| |+----------+| | |
+--------+ | +------^-----+ +----^---+
| End |<--+ Credit-Control | |
| User | Protocol | |
+--------+ +-------V--------+ |
|Credit-Control |----+
| Server |
+----------------+
Figure 7: Credit-control architecture with service element
containing translation agent, translating RADIUS
prepaid to Diameter credit-control protocol
当AAA服务器作为一个传输代理时,从服务节点接收一个RADIUS Access-Request消息, 并且执行普遍的认证和授权. 如果RADIUS Access-Request 消息中是cc服务节点, 如果主AAA服务器中发现用户是预付费用户, Dcc请求应该发送给cc服务器,执行信用授权并且建立一个cc会话. 在Dcc服务器检查用户余额后,计算服务费用,并且从用户账户上做信用预留, 把预留的额度包含在Diameter的Cca消息中返回给主AAA服务器, 之后主AAA服务器把预留的额度包含在RADIUS Access-Accept发送给服务节点.
在分配的额度耗尽时, 服务节点发送一个新的包含使用量的RADIUS Access-Request给主AAA服务器. 主AAA服务器应该映射一个包含使用量报告的RADIUS Access-Request到一个Diameter Ccr(UPDATE_REQUEST)发送给Dcc服务器.Dcc服务器从用户的账户上扣减费用,并且从用户的账户上分配一个新的配额,并且把配额包含在Cca中返回给主AAA服务器.配额被包含在RADIUS Access-Accept传输给服务节点.当用户结束服务,或者配额被耗尽,服务节点需要发送一个RADIUS Access-Request, 为了从用户账户上扣减使用量和停止cc会话, 主AAA服务器发送一个Diameter Ccr(TERMINATION_REQUEST)给cc服务器.Diameter cc服务器结束会话后,发送一个Diameter Cca给主AAA服务器.这个RADIUS Access-Accept被发送给NAS.
[Page 83]
[Page 84]
下面的图标阐述了预付费的RADIUS和Dcc的交互序列.
Service Element Translation Agent
(e.g., NAS) (CC Client) CC Server
| Access-Request | |
|----------------------->| |
| | CCR (initial) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
| (Used-Units) | |
|----------------------->| |
| | CCR (update, |
| | Used-Units) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
|----------------------->| |
| | CCR (terminate, |
| | Used-Units) |
| |----------------------->|
| | CCA |
| |<-----------------------|
| Access-Accept | |
|<-----------------------| |
| | |
Figure 8: Message flow example with RADIUS prepaid -
Diameter credit-control interworking
12. IANA Considerations
本章包含了文档中新建的和IANA中已经分配了的命名空间.
[Page 85]
之后的子章节中,当提及到指定的专家,意思是说'IESG',
12.1. Application Identifier
这个文档分配了值为4'Diameter Credit Control', 这个值定义在[DIAMBASE]. 更多信息请看Section 1.3.
12.2. Command Codes
本文档使用的是272命令码,标志Ccr和Cca.
12.3. AVP Codes
文档分配了411 到 461的值作为Avp Code. 详情请看Section 8.
12.4. Result-Code AVP Values
文档分配了4010, 4011, 4012, 5030, 5031. 详情请看Section 9.
12.5. CC-Request-Type AVP
详情请看Section 8.3
12.6. CC-Session-Failover AVP
详情请看Section 8.4.
[Page 86]
12.7. CC-Unit-Type AVP
详情请看Section 8.32.
12.8. Check-Balance-Result AVP
详情请看Section 8.6.
12.9. Credit-Control AVP
详情请看Section 8.13.
12.10. Credit-Control-Failure-Handling AVP
详情请看Section 8.14.
12.11. Direct-Debiting-Failure-Handling AVP
详情请看Section 8.15.
12.12. Final-Unit-Action AVP
详情请看Section 8.35.
12.13. Multiple-Services-Indicator AVP
详情请看Section 8.40.
[Page 87]
12.14. Redirect-Address-Type AVP
详情请看Section 8.38.
12.15. Requested-Action AVP
详情请看Section 8.41.
12.16. Subscription-Id-Type AVP
详情请看Section 8.47.
12.17. Tariff-Change-Usage AVP
详情请看Section 8.27.
12.18. User-Equipment-Info-Type AVP
详情请看Section 8.50.
13. Credit-Control Application Related Parameters (cc应用计费参数)
Tx timer
当要求实施cc时, cc客户端要在为用户提供服务之前就链接cc服务器. 由于应用的实施性, 要尽可能减小通信的延迟;例如, 为了避免服务建立的时间超长. 引入Tx定时器,用于控制在客户端的未决状态的等待的时间.当Tx 定时器耗尽, cc客户端根据Credit-Control-Failure-Handling和Direct-Debiting-Failure-Handing Avp的内容执行响应的操作. 建议Tx设置为10s.
[Page 88]
Tcc timer
Tcc定时器监督一个在信息服务器中处于进行中的cc会话, 建议使用Validity-Time作为Tcc定时器的值. 如果在网络中传输失败, Dcc服务器可以改变为Idle状态. 为了避免这种情况, Tcc定时器可以设置为 2 x Validity-Time.
Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling
客户端实例可能提供本地配置这些Avp. 在Section 5.7中定义了Credit-Control-Failure-Handling, 在6.5中定义了Direct-Debiting-Failure-Handling.
14. Security Considerations (安全注意事项)
Diameter基础协议[DIAMBASE]要求每个Diameter实例使用基本的安全;例如IPsec或者TLS. 这些机制提供了普通的网络威胁模式下的足够的保护; 假设授权的节点在协议级别没有被攻击, 但在通信渠道上遭受到攻击, 这包含了窃听, 消息修改和插入, 和man-in-the-middle和重播攻击. 还要注意应用包含一个通过Session-Id和CC-Request-Number对应用层的重播保护.Dcc应用通常被用在一个域中,并且可能有一个在节点间的单独跳跃. 在这些环境中, 使用TLS或者是IPsec,可以满足. 关于TLS和IPsec的安全在[DIAMBASE]中定义.
由于这个文档(直接或间接的)处理交易货币, 这就增加了对各种安全攻击的考虑.因此, 所有和其他应用通信的部分必须被认证, 包含实例, TLS client-side 认证. 另外, 客户端的授权应该被增强; 例如, 允许对某个用户执行cc. 详细的授权不属于文档的范围.
[Page 89]
另外一种威胁是怀有恶意的修改, 注入或者是删除Avp或是全部的cc信息. cc消息包含敏感的计费信息(例如用户的Id,授权量,使用量, 费用信息), 这些信息被恶意修改可以有金钱的结果. 有时简单的延迟cc消息,可以引起cc服务器和客户端的骚乱.
即使没有任何修改的消息, 一个对手可以邀请一个窃听的安全威胁, 窃取交易中包含的用户私人信息. 还有, 通过监控cc信息, 其中一端可以收集cc服务器账单模式和交易相关的信息.
当引入第三方的中继设备或者路由, hop-by-hop安全不是必须对Diameter用户会话提供足够的保护. 在一些例子中, 当不能保证第三方的路由没有修改cc命令或者是Avp值时, 发送Diameter消息可能是不适合的, 例如Ccr和Cca, 包含的敏感的Avp通过不信任的Diameter 路由代理.
14.1. Direct Connection with Redirects
Dcc代理不知道用户的Dcc服务器之间的代理是否可信, 这种情况下, Dcc代理在Diameter Routing Table中没有路由入口, 这个Table是一个用户所在域的cc服务器的范围表. Dcc代理可以有一个默认的路由配置, 配置一个本地的重定向代理, 同时dcc代理重定向Ccr消息到重定向代理上, 重定向代理之后返回一个重定向通知给cc代理, 就像Dcc服务器的Redirect-Host Avp和Redirect-Host-Usage Avp路由消息一样. Dcc代理之后直接向前传递Ccr消息给从重定向代理返回的Cca消息中给出的主机. 如果Redirect-Host-Usage Avp 的值是0, 之后所有消息都被发送给Redirect-Host Avp指出的主机, 知道Redirect-Max-Cache-Time Avp超期.
重定向也有一些认证的问题, 由于乱用认证或者是妥协,受认证的节点也可能被攻击, 在DIAMEAP的Section 8中,对这些问题有更多更广的讨论.
[Page 90]
15. References
15.1. Normative References
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[3GPPCHARG] 3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects, Service
aspects; Charging and Billing, (release 5), 3GPP TS
22.115 v. 5.2.1, 2002-03.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[NAI] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[E164] Recommendation E.164/I.331 (05/97): The International
Public Telecommunication Numbering Plan. 1997.
[CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List
of ITU-T Recommendation E.164 assigned country codes",
June 2000.
[E212] Recommendation E.212 (11/98): The international
identification plan for mobile terminals and mobile
users. 1998.
[CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List
of mobile country or geographical area codes", February
1999.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IPv6Addr] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Page 91]
[ISO4217] Codes for the representation of currencies and funds,
International Standard ISO 4217,2001
[NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
Roese, "IEEE 802.1X Remote Authentication Dial In User
Service (RADIUS) Usage Guidelines", RFC 3580, September
2003.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html March 1997.
[3GPPIMEI] 3rd Generation Partnership Project; Technical
Specification Group Core Network, Numbering, addressing
and identification, (release 5), 3GPP TS 23.003 v. 5.8.0,
2003-12
15.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[DIAMEAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Work in
Progress.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[Page 92]
16. Acknowledgements
[Page 93]
Appendix A. Credit-Control Sequences
A.1. Flow I
NAS
End User (CC Client) AAA Server CC Server
|(1)User Logon |(2)AA Request (CC AVPs) |
|------------------>|------------------->| |
| | |(3)CCR(initial, CC AVPs)
| | |------------------->|
| | | (4)CCA(Granted-Units)
| | |<-------------------|
| |(5)AA Answer(Granted-Units) |
|(6)Access granted |<-------------------| |
|<----------------->| | |
| | | |
: : : :
| |(7)CCR(update,Used-Units) |
| |------------------->|(8)CCR |
| | | (update,Used-Units)
| | |------------------->|
| | |(9)CCA(Granted-Units)
| |(10)CCA(Granted-Units)<------------------|
| |<-------------------| |
: : : :
| (Auth. lifetime expires) | |
| |(11) AAR (CC AVP) | |
| |------------------->| |
| | (12) AAA | |
| |<-------------------| |
: : : :
: : : :
|(13) User logoff | | |
|------------------>|(14)CCR(term.,Used-Units) |
| |------------------->|(15)CCR |
| | | (term.,Used-Units)
| | |------------------->|
| | | (16)CCA |
| | (17)CCA |<-------------------|
| |<-------------------| |
| |(18)STR | |
| |------------------->| |
| | (19)STA | |
| |<-------------------| |
Figure A.1: Flow I
[Page 94]
在Figure A.1中是NAS(Network Access Services)预付费cc流程, NAS使用的是Diameter [NASREQ]. 这个流程的主要描述了信用授权的流程.
(1)用户登录到网络上. Diameter NAS 发送一个Diameter AA-Request(AAR)给用户所在Diameter AAA服务器, cc客户端使用cc Avp填充AAR, 设置AAR为CREDIT_AUTHORIZATION, 同时在AAR中还有"服务特性"Avp, 像[NASREQ]的使用一样. 用户所在的Diameter AAA服务执行"服务特性"的认证和授权. 用户所在Diameter AAA服务器确定用户是否为预付费用户并且通过cc Avp通知. Diameter AAA 服务器发送一个CC-Request-Type为INITIAL_REQUEST的Diameter Ccr给Dcc服务器,用于信用授权(3), 同时建立一个cc会话.(用户所在Diameter AAA 服务器可能把从NAS接收到的作为计费处理输入的"服务特性"向前传递). Dcc服务器检查用户账户余额,计算服务费用, 同时从用户账户上预留信用. 预留的额度被填到Diameter的Cca中返回给用户所在的Diameter AAA服务器(4). 用户所在Diameter AAA 服务器把预留余额填到Diameter AA-应答中,发送给NAS. 接收到成功的AA-应答,NAS开始cc会话,同时监控授权的配额(5). NAS批准用户接入(6). 当配额耗尽时, NAS发送一个CC-Request-Type为UPDATE_REQUEST的Diameter Ccr给用户所在Diameter AAA服务器(7). 这个信息包含了到发送消息时,服务的使用量. 用户所在的Diameter AAA 服务器把Ccr消息向前传递给Dcc服务器(8). Dcc服务器从用户的账户上扣减使用量,同时分配一个新的配额并把信息填到Cca中返回个用户所在Diameter AAA 服务器(9). 消息继续呗向前传递给NAS(10). 在会话进行期间, 授权的生命期满, 同时在NAS中授权/认证客户端, 这个NAS执行"服务特性"重授权给Diameter AAA 服务器.cc客户端把设置为RE_AUTHORIZATION的cc avp填充到Aar中, 这个Ccr消息指出当授权量耗尽时, cc服务器将不被能被连接(11). 主Diameter AAA服务器执行"服务特性"在授权,并且返回一个AA-应答给NAS(12).用户登出网络(13).从用户账户上扣减使用量,停止cc会话, 同时NAS发送一个CC-Request-Type为TERMINATION_REQUEST的Diameter Ccr给用户所在Diameter AAA服务器(14). 用户所在的Diameter AAA 服务器把这个Ccr向前发送给cc服务器(15).Dcc服务器通过发送一个Diameter Cca给Diameter AAA 服务器,告知会话结束(16). 用户所在的Diameter AAA 服务器把应答向前发送给NAS(17), 在NAS和Diameter AAA 服务器之间传递的是STR/STA消息.
[Page 95]
A.2. Flow II
SIP Proxy/Registrar AAA
A (CC Client) Server B CC Server
|(i) REGISTER | | | |
|------------->|(ii) | | |
| |------------->| | |
| |authentication & | |
| |authorization | | |
| |<-------------| | |
|(iii)200 OK | | |
|<-------------| | |
: : : :
|(1) INVITE | :
|------------->|
| |(2) CCR (Initial, SIP specific AVP) |
| |------------------------------------------->|
| |(3) CCA (Granted-Units) |
| |<-------------------------------------------|
| |(4) INVITE | |
| |---------------------------->| |
: : : :
| |(5) CCR (update, Used-Units) |
| |------------------------------------------->|
| |(6) CCA (Granted-Units) |
| |<-------------------------------------------|
: : : :
|(7) BYE | | |
|------------->| | |
| |(8) BYE | |
| |---------------------------->| |
| |(9) CCR (termination, Used-Units) |
| |------------------------------------------->|
| |(10) CCA () |
| |<-------------------------------------------|
| | | |
Figure A.2: Flow II
[Page 96]
这是一个SIP会话的Dcc的例子. 不过这个流程主要阐述cc消息的使用, SIP信号是有误的同时图标并没有想要定义一个服务提供者的SIP网络, 然而, 为了这个例子的原因,做了以下的假设. 典型的, 基于预付费的服务, 例如, 使用时间的SIP会话,要求一个在服务提供者网络中的实例,用了监听SIP会话中的所有请求, 例如会话的建立会会话的释放, 这个对cc服务器执行cc操作很重要. 因此, 在这个例子中, 假设SIP Proxy 在SIP INVITE中添加一个Record-Route头, 用于确保建立的会话之后的所有"请求"都遍历它(关于Record-Route和"会话"请查阅[SIP]). 最后,proxy对媒体的cc度的测量, 要看在SIP网络中的Proxy和系统的配置中使用的商业模式.
用户(SIP用户代理A)发送有证书的REGISTER(i). SIP Proxy发送一个"请求"给用户所在AAA服务器,执行多媒体认证和授权, 例如,Diameter多媒体应用(ii). 用户所在AAA服务器检查证书的正确性,同时检查用户资料. 最后 发送一个200 OK的应答给UA(iii). 注意, 认证和授权在有效的登记期间是有效的.(例如, 知道重注册).没有再授权时,可能建立多个SIP会话.
UA A发送一个INVITE(1). SIP Proxy发送一个Diameter Ccr(INITIAL_REQUEST)给Dcc服务器(2).Ccr中包含了SIP中描述服务的信息(例如, calling party, called party, SDP属性-会话描述协议). Dcc服务器检查用户账户余额,计算服务费用,同时从用户账户上预留信用. 通过Cca把预留的额度返回给SIP Proxy(3). SIP Proxy把SIP INVITE 发送给UA B(4). B的电话响铃并且B接电话, 在A和B之间建立了媒体流, 同时SIP Proxy开始测量使用量. 当配额耗尽时, SIP Proxy 发送一个Diameter Ccr(UPDATE_REQUEST)给Dcc服务器(5), 在这个Ccr中包含了到发送Ccr时的使用量, Dcc从用户的账户上扣减使用量, 并且分配新的配额, 把配额包含在Diameter的Cca中返回给SIP Proxy(6). 用户通过发送一个BYE,结束服务(7).SIP Proxy 发送BYE消息给UA B,同时发送一个Diameter Ccr(TERMINATION_REQUEST)给cc服务器(9).Dcc服务器通过发送Diameter Cca消息告知SIP Proxy结束会话(10).
[Page 97]
A.3. Flow III
MMS Server
A (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (event, DIRECT_DEBITING,|
| | MMS specific AVP) |
| |-------------------------------->|
| |(3) CCA (Granted-Units) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure A.3: Flow III
Figure A.3中是一个多媒体的消息服务的cc流程. 当消息服务器成功保存消息后,发送者被扣费.
用户A发送一个多媒体消息(Multimedia Message--MMS)给MMS服务器(1). MMS服务器存储这个消息, 同时发送一个Diameter Ccr(EVENT_REQUEST, Requested-Action为DIRECT_DEBITING)给Dcc服务器(2). Ccr中包含了MMS消息相关的信息(例如, 大小, 接收方的地址, 图片编码类型). Dcc服务器,检查用户的账户余额, 计算服务费用, 并且从用户的账户上扣减费用. 通过包批准额度包含在Diameter Cca消息中返回给MMS服务器(3). MMS服务器告知MMS消息接收成功(4). MMS服务器通知接收者,有新的MMS消息(5), 用户B从MMS消息存储中取回消息(6),(7).
[Page 98]
A.4. Flow IV
MMS Server
Content Server (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (event, CHECK_BALANCE, |
| | MMS specific AVP) |
| |-------------------------------->|
| |(3) CCA (ENOUGH_CREDIT) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) CCR (event, DIRECT_DEBITING,|
| | MMS specific AVP) |
| |-------------------------------->|
| |(8) CCA (Granted-Units) |
| |<--------------------------------|
| |(9) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure A.4: Flow IV
图中是一个Dcc直接扣减使用多媒体服务费用的例子. 流程主要阐述了cc消息的使用, MMS信号可能有误, 并且图表并不是想要定义任何服务提供者的MMS配置或者是计费模式.
Figure A.4展示了MMS(Multimedia Messaging Service)的cc流程. 在消息传递过程中接收端为付费方.
内容服务器发送一个MMS给MMS服务器(1). 在这个例子中消息接收方对MMS付费. 一般情况下从接收到消息和实际取回消息之间会是很长时间, MMS服务器不会对Dcc服务器建立任何cc会话, 通过发送一个Diameter Ccr(EVENT_REQUEST, Requested-Action为CHECK_BALANCE)消息,执行"第一次询问"来检查余额(不预留任何信用) , 检查用户B是否可以付清MMS的费用(2). Dcc服务器检查用户账户余额, 并返回Diameter Cca给MMS服务器(3). MMS服务器告知成功的接收MMS消息(4). MMS服务器通知接收方,有新的MMS消息(5). 之后用户B从MMS消息存储上取回消息(6). MMS服务器发送一个Diameter Ccr(EVENT_REQUEST, Requested-Action为DIRECT_DEBITING)给Dcc服务器(7). Ccr中包含MMS消息相关的信息(如, 大小, 接收方地址, 编码类型). Dcc服务器检查用户账户余额, 计算服务费用, 同时从用户账户上扣减费用. 批准的额度是通过Diameter Cca消息返回给MMS服务器(8). MMS消息传输给用户B(9).
[Page 99]
注意, MMS消息的传递可以延长时间,也可以不成功, 在这个例子中, 需要一个回复的动作. MMS服务器应该使用在Section 6.4中描述的REFUND把已经扣减的量返回给用户的账户上.
A.5. Flow V
SIP Controller
A (CC Client) B CC Server
|(1)INVITE B(SDP)| | |
|--------------->| | |
| |(2) CCR (event, PRICE_ENQUIRY, |
| | SIP specific AVPs) |
| |-------------------------------->|
| |(3) CCA (Cost-Information) |
| |<--------------------------------|
| (4)MESSAGE(URL)| | |
|<---------------| | |
|(5)HTTP GET | | |
|--------------->| | |
|(6)HTTP POST | | |
|--------------->|(7)INVITE(SDP) | |
| |--------------->| |
| | (8)200 OK | |
| (9)200 OK |<---------------| |
|<---------------| | |
Figure A.5: Flow V
[Page 100]
这是一个SIP的Dcc的例子. 注意阐述了cc消息的使用, SIP信号是有误的, 图标并没有试图定义一个服务提供者的SIP网络.
Figure A.5 是一个对SIP 呼叫服务的AoC(Advice of Charge 计费通知). 用户A可以是使用Aoc服务的后付费用户, 也可以是预付费用户. 假设SIP控制者还有HTTP能力并传递一个交互式AoC网页, 例如, 费用信息, 从SDP中导出的呼叫的详细信息, 还有接收/不接受付费的按钮. (可能有很多其他的方法来传递AoC信息; 不管咋样, 这个流程主要是cc消息的使用) 用户在初始化呼叫和订阅AoC服务之前已经被认证和授权.
UA A发送一个有SDP的INVITE给B(1). SIP 控制器确定用户是否订阅了AoC服务,并且发送Diameter Ccr(EVENT_REQUEST, Requested-Action为PRICE_ENQUIRY)给Dcc服务器(2). Ccr中包含了SIP特性Avp, 这些Avp是从描述请求的服务的SIP信号中导出的(如, calling party-主叫, called party-被叫, SDP属性). Dcc服务器确定服务的费用, 并返回一个包含Cost-Information Avp的Cca(3). SIP控制器生成一个包含有从SIP信号中接收到的信息和包含有从cc服务器接收到的费用信息的AoC的web页面. 然后Dcc服务器发送一个SIP MESSAGE, 这个信息中包含一个指向AoC信息web页面的URL(5). 用户点击一个适当的按钮接收付费(6). SIP控制器继续会话, 并发送INVITE给B(7, 8, 9).
[Page 101]
A.6. Flow VI
Gaming Server
End User (CC Client) CC Server
| (1)Service Delivery | |
|<---------------------->| |
: : :
: : :
| |(2)CCR(event,REFUND,Requested-
| |Service-Unit,Service-Parameter-Info)
| |----------------------->|
| | (3)CCA(Cost-Information)
| |<-----------------------|
| (4)Notification | |
|<-----------------------| |
Figure A.6: Flow VI
Fugure A.6 阐述了一个REFUND的cc流程. A.6假设有一个被新人的关系, 并且在游戏服务器和Dcc服务器之间有安全的连接. 用户可以是预付费用户,也可以是后付费用户.
当用户正在玩游戏时(1), 用户升到了一个新的级别, 使用户有资格得到一些奖励. 游戏服务器发送一个Diameter Ccr(EVENT_REQUEST , Requested-Action为REFUND_ACCOUNT)给Dcc服务器(2). Ccr"请求"中包含了Requested-Service-Unit Avp, 在这个Avp中有一个CC-Service-Specific-Units的Avp, CC-Service-Specific-Units中用户赢得的奖励. Service-Parameter-Info Avp也被包含在"请求"中, 同时指出将被计算费用的服务事件(如, Tetris Bonus). Dcc服务器从接收到的消息中确定被借贷的的和对账户退款的量, 同时返回一个包含有Cost-Infomation Avp的Cca(3). Cost-Information 指出了借贷的量. 游戏服务器尽可能快的通知用户借贷量(4).
[Page 102]
A.7. Flow VII
SIP Controller Top-Up
A (CC Client) Server B CC Server
| | | | |
| | (1) CCR(Update,Used-Unit) | |
| |------------------------------------------>|
| | (2) CCA(Final-Unit, Redirect)|
| |<------------------------------------------|
: : : : :
: : : : :
| | (3) CCR(Update, Used-Units)| |
| |------------------------------------------>|
| | (3a)INVITE("hold") | |
| |--------------------------->| |
| | | (4) CCA(Validity-Time)|
| |<------------------------------------------|
| (5)INVITE | (6)INVITE | | |
|<--------------|------------->| | |
| (7)RTP | | |
|..............................| | |
| | (8)BYE | | |
| |<-------------| | |
| | (9)CCR(Update) | |
| |------------------------------------------>|
| | (10)CCA(Granted-Unit) |
| |<------------------------------------------|
| (12)INVITE | (11)INVITE | |
|<--------------|--------------------------->| |
Figure A.7: Flow VII
Figure A.7 是一个SIP呼叫服务结束的例子.假设呼叫被建立, 因此控制器在呼叫中就像是一个B2BUA(Back to Back User Agent), 执行第三方(third-party)的呼叫控制(3PCC). 注意, 由于主要聚焦在服务结束和cc授权, 因此SIP信号可能有误. 3PCC的实现定义在[RFC3725]中.
呼叫正在用户A和B之间进行着; 用户A是一个预付费用户, 当配额耗尽时, SIP控制器发送一个Diameter Ccr(UPDATE_REQUEST)给Dcc服务器(1). 这个消息中包含了到消息发起时的使用量. Dcc服务器从用户账户上扣减使用量, 并且分配最后的额度, 把最后的额度包含在Diameter Cca中返回给SIP控制器(2). 这个消息中包含有Final-Unit-Indication Avp, 在这个Avp中包含有值为REDIRECT的Final-Unit-Action Avp, 值为SIP URI的Redirect-Address-Type Avp, 还包含值为充值服务器名的Redirect-Server-Address Avp(如, sip:sip-topup-server@domain.com). 在最后分配的额度耗尽时, SIP控制器方一个Diameter Ccr(UPDATE_REQUEST)给Dcc服务器(3),
[Page 103]
并且通过发送一个包含适当的连接地址的SDP的INVITE让被叫方等待(3a). Ccr消息中包含了到发送Ccr时的使用量, Dcc从用户的账户上扣减使用量, 但是不做任何信用预留, 返回一个包含有Validity-Time Avp的Cca消息给SIP 控制器,监督结束服务(4). 之后SIP 控制器建立一个预付费用户和充值服务器之间的SIP会话(5, 6). 充值服务器播放一个声明, 并提示用户输入信用卡号同时对账户充值(7). 充值服务器鉴定信用卡的有效性, 并补充用户的账户, 然后释放SIP会话(8). SIP 控制器可以假设预付费用户和充值服务器之间的通信在进行中. 控制器发送一个Ccr(UPDATE_REQUEST)给Dcc服务器, 检查账户是否已经被充值(9). Dcc服务器把保留额度放入Cca中返回给SIP 控制器(10). 这时, SIP控制器再次连接呼叫方和被呼叫方(11, 12).
[Page 104]
A.8. Flow VIII
NAS Top-up CC
End-User (CC Client) AAA Server Server Server
|(1)User Logon |(2)AA Request (CC AVPs) | |
|------------------>|------------------->| | |
| | |(3)CCR(initial, CC AVPs)
| | |------------------->|
| | |(4)CCA(Final-Unit, |
| | | Validity-Time)|
| | |<-------------------|
| |(5)AA Answer(Final-Unit,Validity-Time) |
|(6)Limited Access |<-------------------| | |
| granted | | | |
|<----------------->| | | |
| | | | |
| (7)TCP/HTTP | (8)TCP/HTTP | |
|<----------------->|<----------------------------->| |
| (9) Replenish account | |
|<------------------------------------------------->| |
| | | (10)RAR |
| |<-------------------|<-------------------|
| | (11) RAA | |
| |------------------->|------------------->|
| |(12)CCR(update) | |
| |------------------->|(13)CCR(Update) |
| | |------------------->|
| | |(14)CCA(Granted-Units)
| |(15)CCA(Granted-Units)<------------------|
| |<-------------------| |
Figure A.8: Flow VIII
Figure A.8 是一个当用户账户为空的时候结束服务的例子. 在这个例子中cc服务器支持server-initiated credit re-authorization. 在NAS中执行的是Diameter [NASREQ].
用户登录到网络中(1). Diameter NAS发送一个Diameter AA-Request给用户所在Diameter AAA服务器. cc客户端把设置为CREDIT_AUTHORIZATION的Credit-Control Avp放入到AAR中, cc Avp中还包含了服务特性Avp. 用户所在Diameter AAA服务器对服务特性进行认证和授权. AAA服务器确定用户是为预付费用户后, 通过cc Avp通知AAA服务器NAS有cc能力. NAS发送一个CC-Request-Type为INITIAL_REQUEST的Ccr给Dcc服务器, 用于执行信用授权(3)并且建立一个cc会话.
[Page 105]
(Diameter AAA 服务器可能把从NAS接收到的作为计算费用输入的服务特性向前传递). Dcc服务器检查用户账户余额, 确性用户账户不能付清服务费用后, 引发结束服务. AAA 服务器返回一个Cca消息给NAS(4). 这个Cca消息包含了Final-Unit-Indication Avp和设置为合理的值的Validity-Time Avp, 这样设置Validity-Time的目的是为了给用户一个充值的机会(如, 10 minutes). Final-Unit-Indication Avp包含了值为REDIRECT的Final-Unit-Action, 设置为URL的Redirect-Address-Type和设置为HTTP充值服务器名字的Redirect-Server-Address Avp. 用户所在Diameter AAA服务把接收到的cc Avp包含在AA-Answer中发送给NAS(5). 根据成功的AAA, NAS按照服务器的命令开始cc会话, 并且立即开始结束会话. NAS批准限制用户接入(6). 运行在用户设备上的HTTP客户端软件打开被NAS重定向的充值服务器的连接(7, 8). 向用户展示一个适当的web页面, 在这个页面上可以输入信用卡号, 对账户充值, 并且如果在下一10种内中充值成功,会有一个通知消息, 告知用户可以接入服务. 充值服务器检查信用卡的有效性, 并对用户账户充值(9). 成功充值之后, cc服务器发送一个Re-Auth-Request(Rar)消息给NAS(10). NAS通过返回一个Re-Auth-Answer(Raa)消息,告知接收到了Rar(11), 同时引起信用授权并发送一个Ccr(UPDATE_REQUEST)给Dcc服务器.(12, 13).
Dcc服务器从用户账户上预留信用, 并把预留额度放到Cca中, 通过Diameter AAA服务器返回给NAS(14, 15). NAS通过结束服务移除约束, 并开始监控授权量.
[Page 106]
A.9. Flow IX
Dcc应用定义了Multiple-Services-Credit-Control Avp(MSCC), 这个Avp可以被用来支撑在一个多服务的cc会话中独立的cc. Dcc应用可能请求分配一个信用池, 这个信用池在服务或者是计费组之间是公用的.
下面的例子茶树了一个cc客户端和服务器都支持多服务独立cc的使用场景, 向Section 5.1.2中定义的一样. 这个例子假设Service-Identifier, Rating-Groups和他们相关联的参数都是本地的服务节点配置好的, 或者是被其他的cc服务器实例提供的.
End User Service Element CC Server
(CC client)
|(1)User logon | |
|------------------>|(2)CCR(initial, Service-Id access, |
| | Access specific AVPs, |
| | Multiple-Service-Indicator) |
| |---------------------------------------->|
| |(3)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<----------------------------------------|
: : :
|(4)Service-Request (Service 1) |
|------------------>|(5)CCR(update, Multiple-Services-CC( |
| | Requested-Units(), Service-Id 1, |
| | Rating-Group 1)) |
| |---------------------------------------->|
| |(6)CCA(Multiple-Services-CC ( |
| | Granted-Units(Time), |
| | Rating-Group 1, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 1))) |
| |<----------------------------------------|
: : :
|(7)Service-Request (Service 2) |
|------------------>| |
[Page 107]
: : :
: : :
|(8)Service-Request (Service 3&4) |
|------------------>|(9)CCR(update, Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 3, |
| | Rating-Group 2), |
| | Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 4, |
| | Rating-Group 3)) |
| |---------------------------------------->|
| |(10)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 3, Rating-Group 2, |
| | Validity-time, |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 2)), |
| | Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 4, Rating-Group 3 |
| | Validity-Time, |
| | Final-Unit-Ind.(Terminate), |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 5))) |
| |<----------------------------------------|
: : :
: : :
| +--------------+ | |
| |Validity time | |(11)CCR(update, |
| |expires for | | Multiple-Services-CC ( |
| |Service-Id | | Requested-Unit(), |
| | access | | Used-Units(In-Octets,Out-Octets),|
| +--------------+ | Service-Id access)) |
| |---------------------------------------->|
| |(12)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<----------------------------------------|
: : :
: : :
[Page 108]
| +--------------+ | |
| |Total Quota | |(13)CCR(update, |
| |elapses for | | Multiple-Services-CC ( |
| |pool 2: | | Requested-Unit(), |
| |service 4 not | | Used-Units(In-Octets,Out-Octets),|
| |allowed, | | Service-Id 3, Rating-group 2), |
| |service 3 cont| | Multiple-Services-CC ( |
| +--------------+ | Used-Units(In-Octets,Out-Octets),|
| | Service-Id 4, Rating-Group 3)) |
| |---------------------------------------->|
| |(14)CCA(Multiple-Services-CC ( |
| | Result-Code 4011, |
| | Service-Id 3)) |
| |<----------------------------------------|
: : :
: : :
|(15) User logoff | |
|------------------>|(16)CCR(term, |
| | Multiple-Services-CC ( |
| | Used-Units(In-Octets,Out-Octets),|
| | Service-Id access), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 1, Rating-Group 1), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 2, Rating-Group 1)) |
| |---------------------------------------->|
| |(17)CCA(term) |
| |<----------------------------------------|
Figure A.9: Flow example independent credit-control of multiple
services in a credit-control (sub-)Session
用户登录网络(1). 服务节点发送一个Diameter Ccr给Dcc服务器, Ccr的CC-Request-Type是INITIAL_REQUEST, 执行对承载的服务的信用授权(如, 网络接入服务), 同时建立一个cc会话(2). 在这个消息中cc客户端通过在Cca中包含Multiple-Service-Indicator Avp指出对会话中的多服务的独立cc的支持. Dcc服务器根据从客户端接受到的计费信息, 检查用户账户余额(如, Service-Id和接入特性Avp), 计算请求的费用,并且从账户上预留信用. 假设, 服务器预留$5, 并且确定每MB为$1. Dcc服务器之后返回一个包含对Service-Id有5MB配额, 乘数是10并且Pool-Id为1的MSCC的Cca给服务节点(1).
[Page 109]
用户使用服务 1(4). 服务节点发送一个CC-Request-Type为UPDATE_REQUEST的Ccr给cc服务器,用了执行对服务1的信用授权(5).这个消息中包含了对属于Rating-Group 1的Service 1的"请求的服务量"的MSCC Avp. Dcc服务器确定Service 1消耗作为接入的同一个账户的资源(如, Pool 1). Dcc服务器根据Service-Id/Rating-Group计算请求的费用,同时通过请求更多的信用更新已存在的预留. 假设服务器预留了比$5更多(现在预留是$10), 并确定费用为$0.1/minute, 服务器对所有的Rating-Group授权, 服务器返回一个包含的Cca给服务节点,在MSCC中包含了关联在Rating-Group 1上的50min的配额, 乘数是1,还包含了Pool-Id 1(6). 客户端根据接收到的额度调整pool 1的资源总数, pool 1的值变为100.
用户使用Service 2, 这个服务属于授权了的Rating-Group 1(7). 之后这个服务从pool 1中消耗资源.
用户现在还发起了Services 3和4, 3和4并没有被授权(8). 服务节点发送一个CC-Request-Type为UPDATE_REQUEST的Ccr给cc服务器, 发送这个Ccr是为了执行对Service 3和4信用授权(9). Ccr中包含了两个MSCC的实例, 用于请求属于Rating-Group 2的Service 3和属于Rating-Group 3的Service 4的服务授权量, Dcc服务器确定Service 3和4可以消耗其他账号上的资源(如, Pool 2). Dcc服务器检查用户账户的余额, 并根据Service-Id/Rating-Group信息, 计算"请求"的费用. 然后从Pool 2中预留信用额度.
例如, 服务器保留了$5, 并确定Service 3的费用为$0.2/MB, Service 4的费用为$0.5/MB. 服务器对Service 3和4授权, 服务器把一个包含有两个MSCC实例的Cca消息返回给服务节点(10). 一个MSCC实例中包含了对Service-Id 3的12.5MB的配额, 乘数是2, 指定了信用池为Pool-Id 2. 另一个MSCC中包含了对Service-Id 4的5MB的配额, 乘数是5, 还有指定了信用池是Pool-Id 2.
[Page 110]
服务器还确定了消耗Pool 2, 并且当Pool 2 中的资源耗尽时, 不允许继续提供Service 4服务.因此 在Fianl-Unit-Indication Avp中包含一个关联在Service-Id 4上的TERMINATE的动作. 客户端根据接收到的配额和乘数计算Pool 2中可以使用的资源的总数, 计算出Pool 2 = 50.
Validity-Time为接入服务的期限, 服务节点为了对Service-Id(已接入的)信用再授权, 发送一个Ccr给服务器(11). 这个消息中有一个包含了MSCC, MSCC中有服务对资源的使用量. 假设, 使用的总量是4MB, 客户端适当的调整Pool 1的资源总数,调整后Pool 1的资源为60.
服务器从用户账户上扣除$4, 并通过申请更多的信用更新保留量. 假设, 服务器预留了比$5更多的(现在的预留量是$11), 还有一件知道Service-Id(已接入的)的费用是$1/MB. 服务器返回一个包含有MSCC的Cca给服务节点,在MSCC中包含了对Service-Id的配额是5MB, 乘数是10, 并且资源属于Pool-Id 1(12). 客户端根据收到的配额调整Pool 1的资源量为110.
Service 3和4消耗Pool 2中的信用资源(如, C1*2 _ C2*5 >= S; S为Pool 2的总量), 服务节点立即开始执行结束Service 4的动作, 并发送一个CC-Request-Type为UPDATE_REQUEST的Ccr给cc服务器,发送这个Ccr的目的是为了对Service 3信用再授权(13). Ccr中包含两个MSCC实例,分别报告了Service 3和4对资源的使用量. 服务器从Pool 2中扣减最后$5, 并回复一个MSCC的Result-Code为4011的Cca给客户端, 指出Service 3可以不用cc,继续使用(14).
[Page 111]
用户登出网络(15). 为了从用户账户上扣掉使用量, 并且停止cc会话, 服务节点发送一个CC-Request-Type为TERMINATION_REQUEST的Ccr给cc服务器(16). 这个Ccr中包含了多个MSCC中的服务的每个服务的资源使用量, 使用量都关联到对应的Service-Identifier和Rating-Group上, Dcc服务器从用户账户上扣减使用量, 并且通过发送一个Cca给服务节点,告知会话已结束.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
