RFC4006 日本語訳
4006 Diameter Credit-Control Application. H. Hakala, L. Mattila, J-P.Koskinen, M. Stura, J. Loughney. August 2005. (Format: TXT=288794 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Hakala
Request for Comments: 4006 L. Mattila
Category: Standards Track Ericsson
J-P. Koskinen
M. Stura
J. Loughney
Nokia
August 2005
Hakalaがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4006年のL.Mattilaカテゴリ: 規格はエリクソンJ-Pを追跡します。 Koskinen M.Stura J.Loughneyノキア2005年8月
Diameter Credit-Control Application
直径金融調整アプリケーション
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.
このドキュメントはネットワークアクセスなどのさまざまなエンドユーザサービスのためのリアルタイムの金融調整を実装するのに使用できるDiameterアプリケーションを指定します、Session Initiationプロトコル(SIP)サービス、サービス、およびダウンロードサービスを通信させて。
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
1. 序論… 4 1.1. 要件言語… 5 1.2. 用語… 5 1.3. 広告アプリケーションサポート… 7 2. アーキテクチャはモデル化されます… 7 3. 金融調整メッセージ… 9 3.1. クレジットコントロール要求(CCR)は命令します… 9 3.2. クレジットコントロール答え(CCA)は命令します… 11 4. 金融調整アプリケーション概要… 11 4.1. サービス特有の格付けの入力と相互運用性… 13 5. セッションはクレジットコントロールを基礎づけました… 15 5.1. 綱領… 15 5.2. 最初の査問… 21 5.3. 中間的査問… 27 5.4. 最終的な査問… 29
Hakala, et al. Standards Track [Page 1] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[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
5.5. サーバで開始しているクレジット再承認… 30 5.6. 優雅なサービス終了… 32 5.7. 失敗手順… 38 6. 1つの時間イベント… 41 6.1. 価格調査を修理してください… 42 6.2. チェックのバランスをとってください… 42 6.3. 借り方を指示してください… 43 6.4. 還付します。 44 6.5. 失敗手順… 44 7. 金融調整アプリケーション状態マシン… 46 8. 金融調整AVPs… 55 8.1. CC相関関係イドAVP… 58 8.2. CCリクエスト番号AVP… 58 8.3. ccがタイプを要求しているAVP… 58 8.4. CCセッションフェイルオーバーAVP… 59 8.5. CCのサブセッションのイドAVP… 59 8.6. チェックバランス結果AVP… 60 8.7. コスト情報AVP… 60 8.8. 単価AVP… 61 8.9. 解説者AVP… 61 8.10. 値ケタAVP… 61 8.11. 通貨コードAVP… 62 8.12. 費用単位AVP… 62 8.13. 金融調整AVP… 62 8.14. クレジットコントロール失敗取り扱いAVP… 62 8.15. ダイレクト借り方の失敗取り扱いAVP… 63 8.16. 複数のサービス金融調整AVP… 64 8.17. 与えられたサービスユニットAVP… 65 8.18. 要求されたサービスユニットAVP… 66 8.19. 中古のサービス単位AVP… 66 8.20. 関税時刻変更AVP… 67 8.21. CC時間AVP… 67 8.22. CCお金のAVP… 67 8.23. CCの総八重奏AVP… 68 8.24. CC入力八重奏AVP… 68 8.25. CC出力八重奏AVP… 68 8.26. CCのサービスの特定のユニットAVP… 68 8.27. 関税変化用法AVP… 68 8.28. サービス識別子AVP… 69 8.29. 格付けグループAVP… 69 8.30. G-S-Uプール参照AVP… 69 8.31. G-S-Uプール識別子AVP… 70 8.32. CCユニット型AVP… 70 8.33. 正当性時間AVP… 70 8.34. 最終的なユニット指示AVP… 71 8.35. 最終的なユニット動作AVP… 72 8.36. 制限フィルタ規則AVP… 72 8.37. 再直接のサーバAVP… 73
Hakala, et al. Standards Track [Page 2] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[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
8.38. 再直接のアドレスタイプAVP… 73 8.39. 再直接のサーバアドレスAVP… 74 8.40. 複数のサービスインディケータAVP… 74 8.41. 要求された動作AVP… 74 8.42. サービス文脈イドAVP… 75 8.43. サービスパラメタインフォメーションAVP… 76 8.44. サービスパラメータの型AVP… 76 8.45. サービスパラメタ価値のAVP… 77 8.46. 購読イドAVP… 77 8.47. 購読イドタイプAVP… 77 8.48. 購読イドデータAVP… 78 8.49. ユーザ設備インフォメーションAVP… 78 8.50. ユーザ設備インフォメーションタイプAVP… 78 8.50. ユーザ設備インフォメーション価値のAVP… 79 9. 結果コードAVP値… 79 9.1. 一時的な失敗… 79 9.2. 永久的な失敗… 80 10. AVP発生テーブル… 80 10.1. AVPが見送るクレジットコントロール… 81 10.2. Authの再要求/答えAVPテーブル… 82 11. モデルを織り込む直径半径/金融調整… 82 12. IANA問題… 85 12.1. アプリケーション識別子… 86 12.2. コマンドコード… 86 12.3. AVPコード… 86 12.4. 結果コードAVP値… 86 12.5. ccがタイプを要求しているAVP… 86 12.6. CCセッションフェイルオーバーAVP… 86 12.7. CCユニット型AVP… 87 12.8. チェックバランス結果AVP… 87 12.9. 金融調整AVP… 87 12.10. クレジットコントロール失敗取り扱いAVP… 87 12.11. ダイレクト借り方の失敗取り扱いAVP… 87 12.12. 最終的なユニット動作AVP… 87 12.13. 複数のサービスインディケータAVP… 87 12.14. 再直接のアドレスタイプAVP… 88 12.15. 要求された動作AVP… 88 12.16. 購読イドタイプAVP… 88 12.17. 関税変化用法AVP… 88 12.18. ユーザ設備インフォメーションタイプAVP… 88 13. 金融調整アプリケーションはパラメタについて話しました… 88 14. セキュリティ問題… 89 14.1. 接続を指示する、向け直します。 90 15. 参照… 91 15.1. 標準の参照… 91 15.2. 有益な参照… 92 16. 承認… 93 付録A金融調整は…を配列します… 94
Hakala, et al. Standards Track [Page 3] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[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
A.1。 流れI.… 94 A.2。 流れII… 96 A.3。 流れIII… 98 A.4。 流れIV… 99 A.5。 流れV.… 100 A.6。 流れVI… 102 A.7。 流れVII… 103 A.8。 流れVIII… 105 A.9。 流れIX… 107人の作者のアドレス… 112 完全な著作権宣言文… 114
1. Introduction
1. 序論
This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. It provides a general solution to real-time cost and credit-control.
このドキュメントはネットワークアクセスなどのさまざまなエンドユーザサービスのためのリアルタイムの金融調整を実装するのに使用できるDiameterアプリケーションを指定します、Session Initiationプロトコル(SIP)サービス、サービス、およびダウンロードサービスを通信させて。 それはリアルタイムの費用と金融調整の一般解を提供します。
The prepaid model has been shown to be very successful, for instance, in GSM networks, where network operators offering prepaid services have experienced a substantial growth of their customer base and revenues. Prepaid services are now cropping up in many other wireless and wire line based networks.
例えば、前払いのモデルは、非常にうまくいくためにGSMネットワークで見せられました。そこでは、前払いのサービスを提供するネットワーク・オペレータがそれらの顧客ベースと収入の実質成長を経験しました。 前払いのサービスは現在、ベースの他のワイヤレスとワイヤー・ラインがネットワークでつなぐ多くで現れています。
In next generation wireless networks, additional functionality is required beyond that specified in the Diameter base protocol. For example, the 3GPP Charging and Billing requirements [3GPPCHARG] state that an application must be able to rate service information in real-time. In addition, it is necessary to check that the end user's account provides coverage for the requested service prior to initiation of that service. When an account is exhausted or expired, the user must be denied the ability to compile additional chargeable events.
次世代ワイヤレス・ネットワークでは、Diameterベースプロトコルで指定されたそれを超えて追加機能性が必要です。 例えば、3GPP ChargingとBilling要件[3GPPCHARG]は、アプリケーションが、サービスがリアルタイムでの情報であると評定できなければならないと述べます。 さらに、エンドユーザのアカウントがそのサービスの開始の前に要求されたサービスに適用範囲を提供するのをチェックするのが必要です。 アカウントが消耗しているか、または吐き出されるとき、追加請求できるイベントをコンパイルする能力をユーザに対して否定しなければなりません。
A mechanism has to be provided to allow the user to be informed of the charges to be levied for a requested service. In addition, there are services such as gaming and advertising that may credit as well as debit a user account.
要求されたサービスのために徴収されるためにユーザは充電において知識があるのを許容するためにメカニズムを提供しなければなりません。 さらに、ユーザアカウントを掛けて、借り方に記入するかもしれないゲーミングや広告などのサービスがあります。
The other Diameter applications provide service specific authorization, and they do not provide credit authorization for prepaid users. The credit authorization shall be generic and applicable to all the service environments required to support prepaid services.
アプリケーションが提供するもう片方のDiameterは特定の承認を修理します、そして、それらはクレジット承認を前払いのユーザに提供しません。 クレジット承認は、前払いのサービスをサポートするのに必要であるすべてのサービス環境にジェネリックであって適切になるでしょう。
Hakala, et al. Standards Track [Page 4] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[4ページ]。
To fulfill these requirements, it is necessary to facilitate credit- control communication between the network element providing the service (e.g., Network Access Server, SIP Proxy, and Application Server) and a credit-control server.
これらの要件を実現させるために、サービス(例えば、Network Access Server、SIP Proxy、およびApplication Server)と金融調整サーバを提供するネットワーク要素のクレジットコントロールコミュニケーションを容易にするのが必要です。
The scope of this specification is the credit authorization. Service specific authorization and authentication is out of the scope.
この仕様の範囲はクレジット承認です。 範囲の外にサービスの特定の承認と認証があります。
1.1. Requirements Language
1.1. 要件言語
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[キーワード]で説明されるように解釈されることになっていてください、」であるべきです
1.2. Terminology
1.2. 用語
AAA
AAA
Authentication, Authorization, and Accounting
認証、承認、および会計
AA answer
AA答え
AA answer generically refers to a service specific authorization and authentication answer. AA answer commands are defined in service specific authorization applications, e.g., [NASREQ] and [DIAMMIP].
AA答えは一般的に、特定の承認と認証が答えるサービスについて言及します。 AA答え命令は例えば定義された使用中の特定の承認アプリケーションです。[NASREQ]と[DIAMMIP。]
AA request
AA要求
AA request generically refers to a service specific authorization and authentication request. AA request commands are defined in service specific authorization applications e.g., [NASREQ] and [DIAMMIP].
AA要求は一般的に特定の承認と認証が要求するサービスについて言及します。 AA要求コマンドはサービスの特定の承認アプリケーションの例えば、[NASREQ]と[DIAMMIP]で定義されます。
Credit-control
金融調整
Credit-control is a mechanism that directly interacts in real-time with an account and controls or monitors the charges related to the service usage. Credit-control is a process of checking whether credit is available, credit-reservation, deduction of credit from the end user account when service is completed and refunding of reserved credit that is not used.
金融調整はリアルタイムでにアカウントとコントロールで直接相互作用するか、またはサービス用法に関連する充電をモニターするメカニズムです。 金融調整はクレジットがサービスが終了しているときのエンドユーザアカウントからのクレジットの利用可能で、予約を掛けている控除と予約されたクレジットの使用されなかった還付であるかどうかチェックするプロセスです。
Diameter Credit-control Server
直径金融調整サーバ
A Diameter credit-control server acts as a prepaid server, performing real-time rating and credit-control. It is located in the home domain and is accessed by service elements or Diameter AAA servers in
リアルタイムの格付けと金融調整を実行して、Diameter金融調整サーバは前払いのサーバとして機能します。 それは、ホームドメインに位置していて、中でサービス要素かDiameter AAAサーバによってアクセスされます。
Hakala, et al. Standards Track [Page 5] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[5ページ]。
real-time for purpose of price determination and credit-control before the service event is delivered to the end-user. It may also interact with business support systems.
価格決定とサービスイベントがエンドユーザに提供される前の金融調整の目的のために、リアルタイムでです。 また、それはビジネスサポート・システムと対話するかもしれません。
Diameter Credit-control Client
直径金融調整クライアント
A Diameter credit-control client is an entity that interacts with a credit-control server. It monitors the usage of the granted quota according to instructions returned by credit-control server.
Diameter金融調整クライアントは金融調整サーバと対話する実体です。金融調整サーバによって返された指示によると、それは与えられた割当ての用法をモニターします。
Interrogation
査問
The Diameter credit-control client uses interrogation to initiate a session based credit-control process. During the credit-control process, it is used to report the used quota and request a new one. An interrogation maps to a request/answer transaction.
Diameter金融調整クライアントは、セッションに基づいている金融調整プロセスを開始するのに査問を使用します。 金融調整プロセスの間、それは、中古の割当てを報告して、新しいものを要求するのに使用されます。 要求/答えトランザクションへの査問地図。
One-time event
1回のイベント
Basically, a request/answer transaction of type event.
基本的にタイプイベントの要求/答えトランザクション。
Rating
格付け
The act of determining the cost of the service event.
サービスイベントの費用を決定する行為。
Service
サービス
A type of task performed by a service element for an end user.
サービス要素に従って、一種のタスクがエンドユーザのために働きました。
Service Element
サービス要素
A network element that provides a service to the end users. The Service Element may include the Diameter credit-control client, or another entity (e.g., RADIUS AAA server) that can act as a Credit- control client on behalf of the Service Element. In the latter case, the interface between the Service Element and the Diameter credit- control client is outside the scope of this specification. Examples of the Service Elements include Network Access Server (NAS), SIP Proxy, and Application Servers such as messaging server, content server, and gaming server.
エンドユーザに対するサービスを提供するネットワーク要素。 Service ElementはDiameter金融調整クライアント、またはCreditコントロールクライアントとしてService Elementを代表して演じられることができる別の実体(例えば、RADIUS AAAサーバ)を含むかもしれません。 後者のケース、クレジットが制御するService ElementとDiameterとのインタフェースに、クライアントはこの仕様の範囲の外にいます。 Service Elementsの例はメッセージングサーバや、満足しているサーバや、ゲーミングサーバなどのNetwork Access Server(NAS)、SIP Proxy、およびApplication Serversを含んでいます。
Service Event
サービスイベント
An event relating to a service provided to the end user.
サービスに関連するイベントはエンドユーザに提供されました。
Hakala, et al. Standards Track [Page 6] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[6ページ]。
Session based credit-control
セッションは金融調整を基礎づけました。
A credit-control process that makes use of several interrogations: the first, a possible intermediate, and the final. The first interrogation is used to reserve money from the user's account and to initiate the process. The intermediate interrogations may be needed to request new quota while the service is being rendered. The final interrogation is used to exit the process. The credit-control server is required to maintain session state for session-based credit- control.
いくつかの査問を利用する金融調整プロセス: 1番目、可能な中間介在物、および決勝。 最初の査問は、ユーザのアカウントからお金を取っておいて、処理を開始するのに使用されます。 中間的査問が、サービスがレンダリングされている間、新しい割当てを要求するのに必要であるかもしれません。 最終的な査問は、プロセスを出るのに使用されます。 金融調整サーバが、セッションベースのクレジットコントロールのためにセッション状態を維持するのに必要です。
1.3. Advertising Application Support
1.3. 広告アプリケーションサポート
Diameter nodes conforming to this specification MUST advertise support by including the value of 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE].
この仕様に従う直径ノードは、Capabilities交換要求とCapabilities交換答え命令[DIAMBASE]のAuthアプリケーションイドの4の値を含んでいることによって、サポートの広告を出さなければなりません。
2. Architecture Models
2. アーキテクチャモデル
The current accounting models specified in the Radius Accounting [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real- time credit-control, where credit-worthiness is to be determined prior to service initiation. Also, the existing Diameter authorization applications, [NASREQ] and [DIAMMIP], only provide service authorization, but do not provide credit authorization for prepaid users. In order to support real-time credit-control, a new type of server is needed in the AAA infrastructure: Diameter credit- control server. The Diameter credit-control server is the entity responsible for credit authorization for prepaid subscribers.
Radius Accounting[RFC2866]とDiameterベース[DIAMBASE]の中で指定された現在の会計モデルは実際の時間金融調整に十分ではありません、サービス開始の前に断固としているところで信用価値がことである。 また、既存のDiameter承認アプリケーション[NASREQ]と[DIAMMIP]は、サービス承認を提供するだけですが、クレジット承認は前払いのユーザに提供しません。 リアルタイムの金融調整をサポートするために、新しいタイプのサーバがAAAインフラストラクチャで必要です: 直径クレジットはサーバを制御します。Diameter金融調整サーバは前払いの加入者にとって、クレジット承認に原因となる実体です。
A service element may authenticate and authorize the end user with the AAA server by using AAA protocols; e.g., RADIUS or a Diameter base protocol with a possible Diameter application.
AAAプロトコルを使用することによって、サービス要素は、AAAサーバでエンドユーザを認証して、権限を与えるかもしれません。 例えば、RADIUSかDiameterベースが可能なDiameterアプリケーションで議定書を作ります。
Accounting protocols such as RADIUS accounting and the Diameter base accounting protocol can be used to provide accounting data to the accounting server after service is initiated, and to provide possible interim reports until service completion. However, for real-time credit-control, these authorization and accounting models are not sufficient.
サービスが開始された後に会計データを会計サーバに提供して、サービス完成まで可能な中間報告を提供するのにRADIUS会計学やDiameterベース会計プロトコルなどの会計プロトコルを使用できます。 しかしながら、リアルタイムの金融調整では、これらの承認と会計モデルは十分ではありません。
When real-time credit-control is required, the credit-control client contacts the credit-control server with information about a possible service event. The credit-control process is performed to determine potential charges and to verify whether the end user's account balance is sufficient to cover the cost of the service being rendered.
リアルタイムの金融調整が必要であるときに、金融調整クライアントは可能なサービスイベントの情報で金融調整サーバに連絡します。 金融調整プロセスは、潜在的充電を決定して、エンドユーザの勘定残高がレンダリングされるサービスの費用をまかなうように十分であるかどうか確かめるために実行されます。
Hakala, et al. Standards Track [Page 7] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[7ページ]。
Figure 1 illustrates the typical credit-control architecture, which consists of a Service Element with an embedded Diameter credit- control client, a Diameter credit-control server, and an AAA server. A Business Support System is usually deployed; it includes at least the billing functionality. The credit-control server and AAA server in this architecture model are logical entities. The real configuration can combine them into a single host. The credit- control protocol is the Diameter base protocol with the Diameter credit-control application.
図1は典型的な金融調整アーキテクチャを例証して、どれが埋め込まれたDiameterクレジットと共にService Elementから成るかがクライアント、Diameter金融調整サーバ、およびAAAサーバを監督します。通常、Business Support Systemは配布されます。 それは少なくとも支払いの機能性を含んでいます。 このアーキテクチャモデルの金融調整サーバとAAAサーバは論理的な実体です。 本当の構成は独身のホストにそれらを結合できます。 クレジット制御プロトコルはDiameter金融調整アプリケーションがあるDiameterベースプロトコルです。
When an end user requests services such as SIP or messaging, the request is typically forwarded to a service element (e.g., SIP Proxy) in the user's home domain. In some cases it might be possible that the service element in the visited domain can offer services to the end user; however, a commercial agreement must exist between the visited domain and the home domain. Network access is an example of a service offered in the visited domain where the NAS, through an AAA infrastructure, authenticates and authorizes the user with the user's home network.
エンドユーザがSIPかメッセージングなどのサービスを要求すると、ユーザのホームドメインのサービス要素(例えば、SIP Proxy)に要求を通常転送します。 いくつかの場合、訪問されたドメインのサービス要素がエンドユーザに対するサービスを提供できるのは、可能であるかもしれません。 しかしながら、商業協定は訪問されたドメインとホームドメインの間に存在しなければなりません。 ネットワークアクセスはNASが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 |
+----------+
サービス要素AAAとCC+----------+ +---------+ プロトコル+-----------+ +--------+ | 終わり| <、-、-、--、>|+-------+| <、-、-、-、-、-、-、-、-、-、-、--、>| AAA| |ビジネス| | ユーザ| +->|、| CC|| | サーバ|、-、>|サポート| | | | || クライアント| | <、-、-、-、--+ | | |システム| +----------+ | |+-------+| | +-----------+ | | | +---------+ | ^ +--------+ +----------+ | | CCプロトコル| ^ | 終わり| <--+ | +-----v----+ | | ユーザ| +------>|クレジット| | +----------+ 金融調整|コントロール|--------+ プロトコル|サーバ| +----------+
Figure 1: Typical credit-control architecture
図1: 典型的な金融調整アーキテクチャ
There can be multiple credit-control servers in the system for redundancy and load balancing. The system can also contain separate rating server(s), and accounts can be located in a centralized database. To ensure that the end user's account is not debited or credited multiple times for the same service event, only one place in the credit-control system should perform duplicate detection. System internal interfaces can exist to relay messages between servers and an account manager. However, the detailed architecture of the credit-control system and its interfaces are implementation specific and are out of scope of this specification.
冗長とロードバランシングのシステムには複数の金融調整サーバがあることができます。 また、システムは別々の格付けのサーバを含むことができます、そして、アカウントは集中データベースに位置できます。 複数の回同じサービスイベントについてエンドユーザのアカウントの借り方に記入もしませんし、貸し方に記入もしないのを保証するために、金融調整システムの1つの場所だけが写し検出を実行するべきです。 システムの内部のインタフェースは、サーバと会計主任の間のメッセージをリレーするために存在できます。 しかしながら、金融調整システムの詳細なアーキテクチャとそのインタフェースは、実装特有であり、この仕様の範囲の外にあります。
Hakala, et al. Standards Track [Page 8] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[8ページ]。
Protocol transparent Diameter relays can exist between the credit- control client and credit-control server. Also, Diameter Redirect agents that refer credit-control clients to credit-control servers and allow them to communicate directly can exist. These agents transparently support the Diameter credit-control application. The different roles of Diameter Agents are defined in Diameter base [DIAMBASE], section 2.8.
透明なDiameterがリレーするプロトコルはクレジットコントロールクライアントと金融調整サーバの間に存在できます。また、金融調整クライアントを金融調整サーバに差し向けて、直接伝達するのを許すDiameter Redirectエージェントは存在できます。 これらのエージェントは、Diameter金融調整がアプリケーションであると透過的にサポートします。 Diameterエージェントの異なる役割はDiameterベース[DIAMBASE]、セクション2.8で定義されます。
If Diameter credit-control proxies exist between the credit-control client and the credit-control server, they MUST advertise the Diameter credit-control application support.
Diameter金融調整プロキシが金融調整クライアントと金融調整サーバの間に存在しているなら、彼らはDiameter金融調整アプリケーションサポートの広告を出さなければなりません。
3. Credit-Control Messages
3. 金融調整メッセージ
This section defines new Diameter message Command-Code values that MUST be supported by all Diameter implementations that conform to this specification. The Command Codes are as follows:
このセクションはこの仕様に従うすべてのDiameter実装でサポートしなければならない新しいDiameterメッセージCommand-コード値を定義します。 Command Codesは以下の通りです:
Command-Name Abbrev. Code Reference ----------------------------------------------------------- Credit-Control-Request CCR 272 3.1 Credit-Control-Answer CCA 272 3.2
コマンド名Abbrev。 コード参照----------------------------------------------------------- クレジットコントロール要求CCR272 3.1クレジットコントロール答えCCA272 3.2
Diameter Base [DIAMBASE] defines in the section 3.2 the Command Code ABNF specification. These formats are observed in Credit-Control messages.
Diameter基地[DIAMBASE]はセクション3.2でCommand Code ABNF仕様を定義します。 これらの書式はCredit-コントロールメッセージで観測されます。
3.1. Credit-Control-Request (CCR) Command
3.1. クレジットコントロール要求(CCR)命令
The Credit-Control-Request message (CCR) is indicated by the command-code field being set to 272 and the 'R' bit being set in the Command Flags field. It is used between the Diameter credit-control client and the credit-control server to request credit authorization for a given service.
Creditコントロール要求メッセージ(CCR)は272に設定されるコマンドコード分野とCommand Flags分野に設定される'R'ビットによって示されます。 それは、与えられたサービスのためにクレジット承認を要求するのにDiameter金融調整クライアントと金融調整サーバの間で使用されます。
The Auth-Application-Id MUST be set to the value 4, indicating the Diameter credit-control application.
Diameter金融調整アプリケーションを示して、Authアプリケーションイドを値4に設定しなければなりません。
Hakala, et al. Standards Track [Page 9] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[9ページ]。
Message Format
メッセージ・フォーマット
<Credit-Control-Request> ::= < 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 ]
<クレジットコントロール要求>:、:= <直径ヘッダー: 272 REQ; PXY><セッションイド>発生源ホスト発生源分野目的地分野Authアプリケーションイドサービス文脈イドCC要求タイプCCリクエスト番号あて先ホストユーザ名CCのサブセッションのイドAcctマルチセッションイド発生源州のイドイベントタイムスタンプ; 倍数が金融調整を調整している*ユーザ設備インフォメーション*プロキシインフォメーション*ルート記録購読イドサービス識別子終了原因要求されたサービスユニット要求された動作*中古のサービス単位複数のサービスインディケータ**サービスパラメタインフォメーションCC相関関係イド*[AVP]
Hakala, et al. Standards Track [Page 10] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[10ページ]。
3.2. Credit-Control-Answer (CCA) Command
3.2. クレジットコントロール答え(CCA)命令
The Credit-Control-Answer message (CCA) is indicated by the command- code field being set to 272 and the 'R' bit being cleared in the Command Flags field. It is used between the credit-control server and the Diameter credit-control client to acknowledge a Credit- Control-Request command.
Creditコントロール答えメッセージ(CCA)は272に設定されるコマンドコード分野とCommand Flags分野できれいにされる'R'ビットによって示されます。 それは、Creditコントロール要求命令を承認するのに金融調整サーバとDiameter金融調整クライアントの間で使用されます。
Message Format
メッセージ・フォーマット
<Credit-Control-Answer> ::= < 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 ]
<クレジットコントロール答え>:、:= <直径ヘッダー: 272,; PXY><セッションイド>は発生源ホストのAcctマルチセッションイドの発生源州のイドのイベントタイムスタンプの与えられたサービス発生源分野AuthアプリケーションイドCC要求タイプCCリクエスト番号ユーザ名CCセッションフェイルオーバーCCのサブセッションのイド単位を結果でコード化します; 倍数が金融調整を調整している*プロキシインフォメーション*ルート記録*失敗したAVPコスト情報最終的なユニット指示チェックバランス結果クレジットコントロール失敗取り扱いダイレクト借り方の失敗取り扱い正当性時間*再直接のホスト再直接のホスト用法再直接のマックスキャッシュ時間**[AVP]
4. Credit-Control Application Overview
4. 金融調整アプリケーション概要
The credit authorization process takes place before and during service delivery to the end user and generally requires the user's authentication and authorization before any request is sent to the credit-control server. The credit-control application defined in this specification supports two different credit authorization models: credit authorization with money reservation and credit
クレジット承認プロセスは、配送の前とサービス配送間、エンドユーザに行われて、どんな要求も金融調整サーバに送る前に一般に、ユーザの認証と承認を必要とします。この仕様に基づき定義された金融調整アプリケーションは、2の異なったクレジット承認がモデルであるとサポートします: お金の予約とクレジットがあるクレジット承認
Hakala, et al. Standards Track [Page 11] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[11ページ]。
authorization with direct debiting. In both models, the credit- control client requests credit authorization from the credit-control server prior to allowing any service to be delivered to the end user.
ダイレクト借り方がいる承認。 両方のモデルで、クレジットコントロールクライアントは、エンドユーザに提供されるようどんなサービスも許す前の金融調整サーバからのクレジット承認に要求します。
In the first model, the credit-control server rates the request, reserves a suitable amount of money from the user's account, and returns the corresponding amount of credit resources. Note that credit resources may not imply actual monetary credit; credit resources may be granted to the credit control client in the form of units (e.g., data volume or time) to be metered.
第1代モデルでは、金融調整サーバは、要求を評定して、ユーザのアカウントから適当な金額を予約して、対応する量のクレジットリソースを返します。 クレジットリソースが実際の通貨のクレジットを含意しないかもしれないことに注意してください。 計量されるためにユニット(例えば、データボリュームか時間)の形でクレジットリソースを金融調整クライアントに与えるかもしれません。
Upon receipt of a successful credit authorization answer with a certain amount of credit resources, the credit-control client allows service delivery to the end user and starts monitoring the usage of the granted resources. When the credit resources granted to the user have been consumed or the service has been successfully delivered or terminated, the credit-control client reports back to the server the used amount. The credit-control server deducts the used amount from the end user's account; it may perform rating and make a new credit reservation if the service delivery is continuing. This process is accomplished with session based credit-control that includes the first interrogation, possible intermediate interrogations, and the final interrogation. For session based credit-control, both the credit control client and the credit-control server are required to maintain credit-control session state. Session based credit-control is described in more detail, with more variations, in section 5.
ある量のクレジットリソースがあるうまくいっているクレジット承認答えを受け取り次第、金融調整クライアントは、サービス配送をエンドユーザに許して、与えられたリソースの用法をモニターし始めます。 ユーザに与えられたクレジットリソースが消費されたか、またはサービスが首尾よく提供されるか、終えられたとき、金融調整クライアントレポートは中古の量をサーバに支持します。 金融調整サーバはエンドユーザのアカウントから中古の量を差し引きます。 それは、サービス配送が続いているなら格付けを実行して、新しいクレジットの予約をするかもしれません。 このプロセスは最初の査問、可能な中間的査問、および最終的な査問を含んでいるセッションに基づいている金融調整で達成されます。 セッションに基づいている金融調整において、金融調整クライアントと金融調整サーバの両方が、金融調整セッション状態を維持するのに必要です。 セッションに基づいている金融調整は、より多くの変化でセクション5でさらに詳細に説明されます。
In contrast, credit authorization with direct debiting is a single transaction process wherein the credit-control server directly deducts a suitable amount of money from the user's account as soon as the credit authorization request is received. Upon receipt of a successful credit authorization answer, the credit-control client allows service delivery to the end user. This process is accomplished with the one-time event. Session state is not maintained.
対照的に、ダイレクト借り方がいるクレジット承認はクレジット承認要求が受信されているとすぐに、金融調整サーバがユーザのアカウントから適当な金額を直接差し引く単一取引プロセスです。 うまくいっているクレジット承認答えを受け取り次第、金融調整クライアントはサービス配送をエンドユーザに許します。 このプロセスは1回のイベントで達成されます。 セッション状態は維持されません。
In a multi-service environment, an end user can issue an additional service request (e.g., data service) during an ongoing service (e.g., voice call) toward the same account. Alternatively, during an active multimedia session, an additional media type is added to the session, causing a new simultaneous request toward same account. Consequently, this needs to be considered when credit resources are granted to the services.
マルチサービス環境では、同じアカウントに向かった進行中のサービス(例えば、音声通話)の間、エンドユーザは追加サービスのリクエスト(例えば、データサービス)を発行できます。 あるいはまた、活発なマルチメディアセッションの間、追加メディアタイプはセッションに加えられます、同じアカウントに向かって新しい同時の要求を引き起こして。 その結果、これは、クレジットリソースをサービスに与えると考える必要があります。
The credit-control application also supports operations such as service price enquiry, user's balance check, and refund of credit on the user's account. These operations are accomplished with the one- time event. Session state is not maintained.
また、金融調整アプリケーションはユーザのアカウントでクレジットの価格調査、ユーザのバランスチェック、および還付を修理するような操作をサポートします。 これらの操作は1つの時間イベントで実行されます。 セッション状態は維持されません。
Hakala, et al. Standards Track [Page 12] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[12ページ]。
A flexible credit-control application specific failure handling is defined in which the home service provider can model the credit- control client behavior according to its own credit risk management policy.
それ自身の信用リスク経営政策によると、ホームサービスプロバイダーがクレジットコントロールクライアントの振舞いをモデル化できるフレキシブルな金融調整アプリケーション特定の失敗取り扱いは定義されます。
The Credit-Control-Failure-Handling AVP and the Direct-Debiting- Failure-Handling AVP are defined to determine what is done if the sending of credit-control messages to the credit-control server has been temporarily prevented. The usage of the Credit-Control- Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP allows flexibility, as failure handling for the credit-control session and one time event direct debiting may be different.
Creditコントロール失敗取り扱いAVPとDirectを借り方に記入している失敗を扱うAVPは、一時金融調整サーバへの金融調整メッセージの送付を防いだなら何をするかを決定するために定義されます。 失敗取り扱いを制御しているCredit AVPと失敗取り扱いを借り方に記入するDirect AVPの使用法は柔軟性を許容します、金融調整セッションと1回のイベントのダイレクト借り方のための失敗取り扱いが異なっているとき。
4.1. Service-Specific Rating Input and Interoperability
4.1. サービス特有の格付けの入力と相互運用性
The Diameter credit-control application defines the framework for credit-control; it provides generic credit-control mechanisms supporting multiple service applications. The credit-control application, therefore, does not define AVPs that could be used as input in the rating process. Listing the possible services that could use this Diameter application is out of scope for this generic mechanism.
Diameter金融調整アプリケーションは金融調整のためにフレームワークを定義します。 それは複数のサービスがアプリケーションであるとサポートするジェネリック金融調整メカニズムを提供します。 したがって、金融調整アプリケーションは格付けのプロセスで入力されるように使用できたAVPsを定義しません。 このジェネリックメカニズムのための範囲の外にこのDiameterアプリケーションを使用できた可能なサービスを記載するのがあります。
It is reasonable to expect that a service level agreement will exist between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input (i.e., AVPs), and so on.
サービスレベル協定が金融調整クライアントのプロバイダーの間に存在すると予想するのが妥当であり、充電をカバーする金融調整サーバ(協定に移動して、提供されたサービス)は、格付けが(すなわち、AVPs)などを入力したのに同意しました。
Therefore, it is assumed that a Diameter credit-control server will provide service only for Diameter credit-control clients that have agreed beforehand as to the content of credit-control messages. Naturally, it is possible that any arbitrary Diameter credit-control client can interchange credit-control messages with any Diameter credit-control server, but with a higher likelihood that unsupported services/AVPs could be present in the credit-control message, causing the server to reject the request with an appropriate result-code.
したがって、Diameter金融調整サーバがあらかじめ金融調整メッセージの内容に関して同意したDiameter金融調整クライアントだけにサービスを提供すると思われます。 当然、サポートされないサービス/AVPsが金融調整メッセージに存在しているかもしれないのは、どんな任意のDiameter金融調整クライアントもどんなDiameter金融調整サーバにもかかわらず、より高い見込みでも金融調整メッセージを交換できるのが可能です、サーバが適切な結果コードで要求を拒絶することを引き起こして。
4.1.1. Specifying Rating Input AVPs
4.1.1. 格付けの入力AVPsを指定します。
There are two ways to provide rating input to the credit-control server: either by using AVPs or by including them in the Service- Parameter-Info AVP. The general principles for sending rating parameters are as follows:
金融調整サーバに入力された格付けを提供する2つの方法があります: AVPsを使用するか、またはServiceパラメタインフォメーションAVPに彼らを含んでいることによって。 送付格付けのパラメタのための綱領は以下の通りです:
1a. The service SHOULD re-use existing AVPs if it can use AVPs defined in existing Diameter applications (e.g., NASREQ for network access services). Re-use of existing AVPs is strongly recommended in [DIAMBASE].
1a。 AVPsを使用できるなら、サービスSHOULD再使用の既存のAVPsは既存のDiameterでアプリケーション(例えば、ネットワークアクセス・サービスのためのNASREQ)を定義しました。 既存のAVPsの再使用は[DIAMBASE]で強く推薦されます。
Hakala, et al. Standards Track [Page 13] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[13ページ]。
For AVPs of type Enumerated, the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2.
タイプEnumeratedのAVPsに関しては、サービスは、新しい値が定義されるのを必要とするかもしれません。 [DIAMBASE]、セクション1.2で指定されるように新しいAVP値の配分をします。
1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In this case, the procedures defined in [DIAMBASE] for creating new AVPs MUST be followed.
1b。 既存のAVPsが十分な格付けの情報を提供しないなら、新しいAVPsを定義できます。 この場合、新しいAVPsを作成するために[DIAMBASE]で定義された手順に従わなければなりません。
1c. For services specific only to one vendor's implementation, a Vendor-Specific AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs is encouraged instead; refer to [DIAMBASE].
1c。 1つのベンダーの実装だけに特定のサービスのために、兵士の使用のためのVendor特有のAVPコードを使用できます。 Vendor特有のAVPが1つ以上のベンダーによって実装されるところでは、グローバルなAVPsの配分は代わりに奨励されます。 [DIAMBASE]を参照してください。
2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER). This method can be used to avoid unnecessary conversions from an existing data format to an AVP format. In this case, the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.43.
2. ServiceパラメタインフォメーションAVP MAY、コンテナとして使用されて、元のコード化されたフォーム(例えば、ASN.1BER)でレガシー格付けの情報を通過してください。 不要な既存のデータ形式からAVP形式までの変換を避けるのにこのメソッドを使用できます。 この場合、格付けの入力はセクション8.43で定義されるようにServiceパラメタインフォメーションAVPに埋め込まれます。
New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability.
新しいサービスアプリケーションSHOULDは相互運用性を簡素化するために項目の1aと1bで説明されるように明らかに定義されたAVPsの使用を支持します。
4.1.2. Service-Specific Documentation
4.1.2. サービス特有のドキュメンテーション
The service specific rating input AVPs, the contents of the Service- Parameter-Info AVP or Service-Context-Id AVP (defined in section 8.42) are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the Service-Context-Id be coordinated via an informational RFC or other permanent and readily available reference. The specification of another cooperative standardization body (e.g., 3GPP, OMA, and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit-control server and client. In this case, vendor specific AVPs can be used.
サービスの特定の格付けの入力AVPs、このドキュメントの範囲の中にServiceパラメタインフォメーションAVPかService文脈イドAVP(セクション8.42で、定義される)の内容がありません。 相互運用性を容易にするために、Service文脈イドの格付けの入力と値が情報のRFCか他の永久的で容易に利用可能な参照で調整されるのは、RECOMMENDEDです。 別の協力的な標準化の仕様は(例えば、3GPP、OMA、および3GPP2)SHOULDを具体化させます。使用されます。 しかしながら、金融調整サーバとクライアントのプロバイダーの間の協定を受けることがある密葬は配布されるかもしれません。 この場合、ベンダーの特定のAVPsを使用できます。
This specification, together with the above service specific documents, governs the credit-control message. Service specific documents define which existing AVPs or new AVPs are used as input to the rating process (i.e., those that do not define new credit-control applications), and thus have to be included in the Credit-Control- Request command by a Diameter credit-control client supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP.
この仕様は上記のサービス特定のドキュメントと共に金融調整メッセージを支配します。 特定のドキュメントが定義するAVPsか新しいAVPsが使用されているそれの存在が格付けのプロセス(すなわち、新しい金融調整アプリケーションを定義しないもの)に入力されて、その結果*[AVP]として与えられたサービスをサポートするCredit Diameter金融調整による要求コマンドを制御しているクライアントに含まれなければならないサービス。 Serviceパラメタインフォメーションは使用されていて、次に、サービスの特定のドキュメントがこの分類されたAVPの正確な内容を指定しなければならないということであるべきですか?
Hakala, et al. Standards Track [Page 14] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[14ページ]。
The Service-Context-Id AVP MUST be included at the command level of a Credit-Control Request to identify the service specific document that applies to the request. The specific service or rating group the request relates to is uniquely identified by the combination of Service-Context-Id and Service-Identifier or Rating-Group.
Service文脈イドAVP MUST、要求に適用されるサービスを特定するCredit-コントロールRequestの特定のドキュメントのコマンドレベルでは、含められてください。 要求が関連する特定のサービスか格付けのグループがService文脈イドとService-識別子かRating-グループの組み合わせで唯一特定されます。
4.1.3. Handling of Unsupported/Incorrect Rating Input
4.1.3. サポートされないか不正確な格付けの入力の取り扱い
Diameter credit-control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support, according to the 'M' bit rules in [DIAMBASE].
直径金融調整実装が、使用中の特定の'M'ビットに従ってそれらが[DIAMBASE]の規則をサポートするサービスのドキュメンテーションをAVPsが定義したMandatory格付けにサポートするのに必要です。
If a rating input required for the rating process is incorrect in the Credit-control request, or if the credit-control server does not support the requested service context (identified by the Service- Context-Id AVP at command level), the Credit-control answer MUST contain the error code DIAMETER_RATING_FAILED. A CCA message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit-control client that receives the error code DIAMETER_RATING_FAILED in response to a request MUST NOT send similar requests in the future.
金融調整サーバが要求されたサービス文脈(コマンドレベルでService文脈イドAVPによって特定される)をサポートしないなら格付けのプロセスに必要である格付けの入力がCredit-コントロール要求で不正確であるなら、Credit-コントロール答えはエラーコードDIAMETER_RATING_FAILEDを含まなければなりません。 この誤りがあるCCAメッセージは失敗を引き起こしたなくなったそして/または、サポートされないAVPsを含む1Failed-AVP AVPsを含まなければなりません。 要求に対応してエラーコードDIAMETER_RATING_FAILEDを受け取るDiameter金融調整クライアントは将来、同様の要求を送ってはいけません。
4.1.4. RADIUS Vendor-Specific Rating Attributes
4.1.4. 半径のベンダー特有の格付けの属性
When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed.
サービスであるときに、特定のドキュメントは格付けのプロセスで入力されるように使用されるかもしれないRADIUSのベンダーの特定の属性を含んで、Diameter AVPをフォーマットするために[NASREQ]で説明された規則に従わなければなりません。
For example, if the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
例えば、コードが使用したAVPがベンダー属性タイプコードであるなら、Vendor特有の旗を1に設定しなければなりません、そして、IANA Vendor識別価値にVendor-IDを設定しなければなりません。 Diameter AVPデータ・フィールドはRADIUS属性の属性値だけを含んでいます。
5. Session Based Credit-Control
5. セッションは金融調整を基礎づけました。
5.1. General Principles
5.1. 綱領
For a session-based credit-control, several interrogations are needed: the first, intermediate (optional) and the final interrogations. This is illustrated in Figures 2 and 3.
セッションベースの金融調整において、いくつかの査問が必要です: 1番目、中間介在物(任意の)、および最終的な査問。 これは図2と3で例証されます。
If the credit-control client performs credit-reservation before granting service to the end user, it MUST use several interrogations toward the credit-control server (i.e., session based credit-
エンドユーザに対するサービスを承諾する前に金融調整クライアントがクレジット予約を実行するなら、金融調整サーバに向かっていくつかの査問を使用しなければならない、(すなわち、セッションはクレジットを基礎づけました。
Hakala, et al. Standards Track [Page 15] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[15ページ]。
control). In this case, the credit-control server MUST maintain the credit-control session state.
コントロール) この場合、金融調整サーバは金融調整セッション状態を維持しなければなりません。
Each credit-control session MUST have a globally unique Session-Id as defined in [DIAMBASE], which MUST NOT be changed during the lifetime of a credit-control session.
それぞれの金融調整セッションには、グローバルにユニークなSession-イドが[DIAMBASE](金融調整セッションの生涯変えてはいけない)で定義されるようになければなりません。
Certain applications require multiple credit-control sub-sessions. These applications would send messages with a constant Session-Id AVP, but with a different CC-Sub-Session-Id AVP. If several credit sub-sessions will be used, all sub-sessions MUST be closed separately before the main session is closed so that units per sub-session may be reported. The absence of this AVP implies that no sub-sessions are in use.
あるアプリケーションは複数の金融調整サブセッションを必要とします。 これらのアプリケーションは一定のSession-イドAVPにもかかわらず、異なったCCのサブSessionのイドAVPがあるメッセージを送るでしょう。 いくつかのクレジットサブセッションが使用されるなら、主なセッションがサブセッションあたりのユニットを報告できるように閉じるようになる前に別々にすべてのサブセッションを終えなければなりません。 このAVPの不在は、どんなサブセッションも使用中でないことを含意します。
Note that the service element might send a service specific re- authorization message to the AAA server due to expiration of the authorization-lifetime during an ongoing credit-control session. However, the service specific re-authorization does not influence the credit authorization that is ongoing between the credit-control client and credit-control server, as credit authorization is controlled by the burning rate of the granted quota.
サービス要素が進行中の金融調整セッションの間の承認生涯の満了へのAAAサーバ支払われるべきものにサービスの特定の再承認メッセージを送るかもしれないことに注意してください。 しかしながら、サービスの特定の再承認は金融調整クライアントと金融調整サーバの間で進行中であることのクレジット承認に影響を及ぼしません、クレジット承認が与えられた割当ての燃焼率によって制御されるとき。
If service specific re-authorization fails, the user will be disconnected, and the credit-control client MUST send a final interrogation to the credit-control server.
サービスであるなら、特定の再承認は失敗します、そして、ユーザ切断されるでしょう、そして、金融調整クライアントは最終的な査問を金融調整サーバに送らなければなりません。
The Diameter credit-control server may seek to control the validity time of the granted quota and/or the production of intermediate interrogations. Thus, it MAY include the Validity-Time AVP in the answer message to the credit-control client. Upon expiration of the Validity-Time, the credit-control client MUST generate a credit- control update request and report the used quota to the credit- control server. It is up to the credit-control server to determine the value of the Validity-Time to be used for consumption of the granted service units. If the Validity-Time is used, its value SHOULD be given as input to set the session supervision timer Tcc (the session supervision timer MAY be set to two times the value of the Validity-Time, as defined in section 13). Since credit-control update requests are also produced at the expiry of granted service units and/or for mid-session service events, the omission of Validity-Time does not mean that intermediate interrogation for the purpose of credit-control is not performed.
Diameter金融調整サーバは与えられた割当ての正当性時間、そして/または、中間的査問の生産を制御しようとするかもしれません。 したがって、それは答えメッセージでValidity-時間AVPを金融調整クライアントに含めるかもしれません。 Validity-現代の満了に関して、金融調整クライアントは、クレジットコントロールが更新要求であると生成して、クレジット制御サーバに中古の割当てを報告しなければなりません。Validity-現代の値が与えられたサービスユニットの消費に使用されることを決定するのは金融調整サーバに上がっています。 Validity-時間は使用されています、値のSHOULD。セッション指揮タイマTccを設定するために入力されるように、与えてください(セッション指揮タイマはValidity-現代の値の2倍に設定されるかもしれません、セクション13で定義されるように)。 また、金融調整更新要求が与えられたサービスユニットの満期中間のセッション・サービスイベントのために作り出されるので、Validity-時間の省略は、金融調整の目的のための中間的査問が実行されないことを意味しません。
Hakala, et al. Standards Track [Page 16] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[16ページ]。
5.1.1. Basic Tariff-Time Change Support
5.1.1. 基本的な関税時刻変更サポート
The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation.
Diameter金融調整サーバとクライアントは任意に関税変化メカニズムをサポートするかもしれません。 Diameter金融調整サーバは答えメッセージにTariff時間変化AVPを含むかもしれません。 報告された総合的が今度の関税変化の場合の最悪の事態のシナリオに基づいて与えられたユニットを割り当てるべきであるのでユニットを使用したというメモはクレジットの予約を決して超えていません。
When the Diameter credit-control client reports the used units and a tariff change has occurred during the reporting period, the Diameter credit-control client MUST separately itemize the units used before and after the tariff change. If the client is unable to distinguish whether units straddling the tariff change were used before or after the tariff change, the credit-control client MUST itemize those units in a third category.
Diameter金融調整クライアントがいつ中古の単位と関税変化を報告するかは報告の期間、起こっていて、Diameter金融調整クライアントは別々に関税変化の前後に使用されたユニットを箇条書きしなければなりません。 クライアントが関税の前または後に関税変化にまたがったユニットが中古の変化であったか否かに関係なく、区別できないなら、金融調整クライアントは3番目のカテゴリでそれらのユニットを箇条書きしなければなりません。
If a client does not support the tariff change mechanism and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit-control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
クライアントが関税変化メカニズムをサポートしないで、Tariff時間変化AVPを運びながらCCAメッセージを受け取るなら、金融調整セッションを終えなければなりません、Termination-原因AVPでDIAMETER_BAD_ANSWERの理由をあげて。
For time based services, the quota is continuously consumed at the regular rate of 60 seconds per minute. At the time when credit resources are allocated, the server already knows how many units will be consumed before the tariff time change and how many units will be consumed afterward. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterward in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in the case of tariff time changes for continuous time based service. Therefore, the tariff change mechanism is not used for such services. For time- based services in which the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used.
時間に基づいているサービスにおいて、割当ては1分あたり60秒の通常時間当たり賃金で絶え間なく消費されます。 クレジットリソースを割り当てるとき、サーバは、いくつのユニットが関税時刻変更の前に消費されるだろうか、そして、いくつのユニットがその後消費されるかを既に知ります。 同様に、サーバが消費されたユニットを決定できる、エンドユーザが割り当てられた割当ての消費の前にセッションを終える場合その後レートで消費されたレートとユニット前で。 クライアントとサーバの間には、連続した時間に基づいているサービスのための関税時刻変更の場合に追加トラフィックの必要は全くありません。 したがって、関税変化メカニズムはそのようなサービスに使用されません。 時間割当てが通常時間当たり賃金で絶え間なく消費されないベースのサービスのために、ボリュームとイベントユニット説明された関税変化メカニズムは使用されるかもしれません。
5.1.2. Credit-Control for Multiple Services within a (sub-)Session
5.1.2. aの中の複数のサービスのための金融調整、(サブ、)、セッション
When multiple services are used within the same user session and each service or group of services is subject to different cost, it is necessary to perform credit-control for each service independently. Making use of credit-control sub-sessions to achieve independent credit-control will result in increased signaling load and usage of resources in both the credit-control client and the credit-control server. For instance, during one network access session the end user may use several http-services subject to different access cost. The network access specific attributes such as the quality of service
複数のサービスが同じユーザセッション中に利用されて、サービスの各サービスかグループが異なった費用を受けることがあるとき、独自に各サービスのための金融調整を実行するのが必要です。 達成するためにはサブセッションの金融調整を独立している金融調整がもたらす利用するのは、金融調整クライアントと金融調整サーバの両方でリソースの負荷と用法に合図しながら、増加しました。例えば、1つのネットワークアクセスセッションの間、エンドユーザは異なったアクセス費用を条件としていくつかのhttp-サービスを利用するかもしれません。 ネットワークはサービスの質などの特定の属性にアクセスします。
Hakala, et al. Standards Track [Page 17] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[17ページ]。
(QoS) are common to all the services carried within the access bearer, but the cost of the bearer may vary depending on its content.
(QoS)はアクセス運搬人の中で提供されたすべてのサービスに共通ですが、内容によって、運搬人の費用は異なるかもしれません。
To support these scenarios optimally, the credit-control application enables independent credit-control of multiple services in a single credit-control (sub-)session. This is achieved by including the optional Multiple-Services-Credit-Control AVP in Credit-Control- Request/Answer messages. It is possible to request and allocate resources as a credit pool shared between multiple services. The services can be grouped into rating groups in order to achieve even further aggregation of credit allocation. It is also possible to request and allocate quotas on a per service basis. Where quotas are allocated to a pool by means of the Multiple-Services-Credit-Control AVP, the quotas remain independent objects that can be re-authorized independently at any time. Quotas can also be given independent result codes, validity times, and Final-Unit-Indications.
最適に、金融調整アプリケーションが可能にするこれらのシナリオにただ一つの金融調整における、複数のサービスの独立している金融調整をサポートする、(サブ、)、セッション。 これは、Credit-コントロール要求/答えメッセージに任意のMultipleサービスクレジットが制御されたAVPを含んでいることによって、達成されます。 クレジットプールが複数のサービスを平等に割り当てたので、リソースを要求して、割り当てるのは可能です。 クレジット配分のさらなる集合さえ達成するためにサービスを格付けのグループに分類できます。 また、1調査基準価格あたりのaに関する割当てを要求して、割り当てるのも可能です。 Multipleサービスクレジットが制御されたAVPによって割当てをプールに割り当てるところでは、割当てはいつでも独自に再認可できる独立しているオブジェクトのままで残っています。 また、独立している結果コード、正当性回、およびFinalユニット指摘を割当てに与えることができます。
A Rating-Group gathers a set of services, identified by a Service- Identifier, and subject to the same cost and rating type (e.g., $0.1/minute). It is assumed that the service element is provided with Rating-Groups, Service-Identifiers, and their associated parameters that define what has to be metered by means outside the scope of this specification. (Examples of parameters associated to Service-Identifiers are IP 5-tuple and HTTP URL.) Service-Identifiers enable authorization on a per-service based credit as well as itemized reporting of service usage. It is up to the credit-control server whether to authorize credit for one or more services or for the whole rating-group. However, the client SHOULD always report used units at the finest supported level of granularity. Where quota is allocated to a rating-group, all the services belonging to that group draw from the allotted quota. The following is a graphical representation of the relationship between service-identifiers, rating-groups, credit pools, and credit-control (sub-)session.
Rating-グループは1セットのサービスを集めます、Service識別子、同じ費用およびを条件として特定されて、タイプ(例えば、0.1ドル/分)を評定して。 Rating-グループ、Service-識別子、およびこの仕様の範囲の外で手段で計量されなければならないことを定義するそれらの関連パラメタがサービス要素に提供されると思われます。 (Service-識別子に関連づけられたパラメタに関する例は、IP5-tupleとHTTP URLです。) サービス識別子は1サービスあたり1つのベースのクレジットで承認をサービス用法について報告しながら箇条書きされるのと同じくらいよく可能にします。 それは1のためにクレジットを認可するか、そして、以上がサービスを提供する金融調整サーバか全体の格付けグループのためのものです。 しかしながら、SHOULDがいつも報告するクライアントは粒状のレベルであるとサポートされる中で最もすばらしいものでユニットを使用しました。 格付けグループに割当てを割り当てるところでは、そのグループに属すすべてのサービスが割り当てられた割当てから描かれます。 ↓これがサービス識別子と、格付けグループと、クレジットプールと、金融調整との関係のaグラフ表示である、(サブ、)、セッション。
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
DCC、(サブ、)、セッション| +------------+-----------+-------------+--------------- + | | | | | サービスイドa Service-イドb Service-イドc Service-イドd.…サービスイドz\/\\/\//\/格付け//グループ1…n格付けグループ円の/| | 割当て---------------割当て割当て| / | | / | クレジットプールクレジットプール
Hakala, et al. Standards Track [Page 18] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[18ページ]。
If independent credit-control of multiple services is used, the validity-time and final-unit-indication SHOULD be present either in the Multiple-Services-Credit-Control AVP(s) or at command level as single AVPs. However, the Result-Code AVP MAY be present both on the command level and within the Multiple-Services-Credit-Control AVP. If the Result-Code on the command level indicates a value other than SUCCESS, then the Result-Code on command level takes precedence over any included in the Multiple-Services-Credit-Control AVP.
使用される、複数のサービスの独立している金融調整と、正当性時間と最終的なユニット指示SHOULDであるなら、独身のAVPsとしてMultipleサービスクレジットが制御されたAVP(s)かコマンドレベルにおいて存在してください。 しかしながら、プレゼントがコマンドレベルの上と、そして、Multipleサービスクレジットが制御されたAVPの中の両方であったならAVP MAYをResultコード化してください。 コマンドレベルのResult-コードがSUCCESS以外の値を示すなら、Multipleサービスクレジットが制御されたAVPにいずれも含んでいる上でコマンドレベルのResult-コードは優先します。
The credit-control client MUST indicate support for independent credit-control of multiple services within a (sub-)session by including the Multiple-Services-Indicator AVP in the first interrogation. A credit-control server not supporting this feature MUST treat the Multiple-Services-Indicator AVP and any received Multiple-Services-Credit-Control AVPs as invalid AVPs.
金融調整クライアントがaの中の複数のサービスの独立している金融調整のサポートを示さなければならない、(サブ、)、最初の査問にMultipleサービスインディケータAVPを含んでいるのによるセッション。 この特徴をサポートしない金融調整サーバは無効のAVPsとしてMultipleサービスインディケータAVPとどんな容認されたMultipleサービスクレジットが制御されたAVPsも扱わなければなりません。
If the client indicated support for independent credit-control of multiple services, a credit-control server that wishes to use the feature MUST return the granted units within the Multiple-Services- Credit-Control AVP associated to the corresponding service-identifier and/or rating-group.
クライアントが独立している金融調整のサポートを示したなら、複数のサービス、特徴が返さなければならない使用に願われている金融調整サーバでは、クレジットコントロールを調整しているMultiple AVPの中の与えられたユニットは対応するサービス識別子、そして/または、格付けグループと交際しました。
To avoid a situation where several parallel (and typically also small) credit reservations must be made on the same account (i.e., credit fragmentation), and also to avoid unnecessary load on the credit-control server, it is possible to provide service units as a pool that applies to multiple services or rating groups. This is achieved by providing the service units in the form of a quota for a particular service or rating group in the Multiple-Services-Credit- Control AVP, and also by including a reference to a credit pool for that unit type.
同じアカウント(すなわち、クレジット断片化)でいくつかの平行で(通常小さいも)のクレジットの予約をしなければならない状況を避けて、また、金融調整サーバで不要な負荷を避けるために、複数のサービスに適用されるプールか格付けが分類されるとき、ユニットをサービスに提供するのは可能です。 これはそのユニット型のためにクレジットプールにMultiple-サービスクレジットコントロールAVPにおける、特定のサービスか格付けのグループのための割当ての形のサービスユニットが提供することによって達成されて、また、包含するのによる参照を達成されます。
The reference includes a multiplier derived from the rating parameter, which translates from service units of a specific type to the abstract service units in the pool. For instance, if the rating parameter for service 1 is $1/MB and the rating parameter for service 2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2, respectively.
参照はプールの中で特定のタイプのサービス単位から抽象的なサービスユニットまで翻訳される格付けのパラメタから得られた乗数を含んでいます。 例えば、サービス1のための格付けのパラメタが1ドル/MBであり、サービス2のための格付けのパラメタが0.5ドル/MBであるなら、乗数は、それぞれサービス1と2のための10と5であるかもしれません。
If S is the total service units within the pool, M1, M2, ..., Mn are the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., Cn are the used resources within the session, then the pool credit is exhausted and re-authorization MUST be sought when:
Sが合計であるなら、プール、M1、M2の中でユニットを調整してください…, Mnはサービス1、2に提供された乗数です…, n、およびC1、C2…, セッション中にCnが中古のリソースであり、次に、プールクレジットが疲れ果てていて、再承認を求めなければならない、いつ:
C1*M1 + C2*M2 + ... + Cn*Mn >= S
C1*M1+C2*M2+… + Cn*Mn>=S
Hakala, et al. Standards Track [Page 19] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[19ページ]。
The total credit in the pool, S, is calculated from the quotas, which are currently allocated to the pool as follows:
プールの中の総クレジット(S)は割当てから計算されます:(割当ては現在、以下のプールに割り当てられます)。
S = Q1*M1 + Q2*M2 + ... + Qn*Mn
SはQ1*M1+Q2*M2+と等しいです… + Qn*Mn
If services or rating groups are added to or removed from the pool, then the total credit is adjusted appropriately. Note that when the total credit is adjusted because services or rating groups are removed from the pool, the value that need to be removed is the consumed one (i.e., Cx*Mx).
サービスか格付けのグループがプールから加えられるか取り除かれるなら、総クレジットは適切に調整されます。 総クレジットがサービスか格付けのグループを取り除くので調整されるとき、プール、値からのその取り除かれるべき必要性が消費されたもの(すなわち、Cx*Mx)であることに注意してください。
Re-authorizations for an individual service or rating group may be sought at any time; for example, if a 'non-pooled' quota is used up or the Validity-Time expires.
個々のサービスか格付けのグループのための再承認はいつでも、求められるかもしれません。 例えば、'非プールされた'割当てが使いきられるか、そして、Validity-時間が期限が切れます。
Where multiple G-S-U-Pool-Reference AVPs (section 8.30) with the same G-S-U-Pool-Identifier are provided within a Multiple-Services- Credit-Control AVP (section 8.16) along with the Granted-Service-Unit AVP, then these MUST have different CC-Unit-Type values, and they all draw from the credit pool separately. For instance, if one multiplier for time (M1t) and one multiplier for volume (M1v) are given, then the used resources from the pool is the sum C1t*M1t + C1v*M1v, where C1t is the time unit and C1v is the volume unit.
複数であるところに、Grantedサービスユニットに伴うクレジットコントロールAVP(セクション8.16)を調整しているMultiple AVPの中で同じG-S-Uプール識別子があるG-S-Uプール参照AVPs(セクション8.30)を提供します、これらには、次に、異なったCCユニットタイプ値がなければなりません、そして、彼らは皆、別々にクレジットプールから描きます。 例えば、時間の1つの乗数(M1t)とボリュームのための1つの乗数(M1v)を与えるなら、プールからの中古のリソースは合計C1t*M1t+C1v*M1vです、そして、C1vはボリューム単位です。そこでは、C1tがタイム・ユニットです。
Where service units are provided within a Multiple-Services-Credit- Control AVP without a corresponding G-S-U-Pool-Reference AVP, then these are handled independently from any credit pool and from any other services or rating groups within the session.
そして、クレジットコントロールを調整しているMultiple AVPの中で対応するG-S-Uプール参照AVPなしでサービスユニットを提供するところでは、これらはセッション中にどんなクレジットプールといかなる他のサービスか格付けのグループからも独自に扱われます。
The credit pool concept is an optimal tool to avoid the over- reservation effect of the basic single quota tariff time change mechanism (the mechanism described in section 5.1.1). Therefore, Diameter credit-control clients and servers implementing the independent credit-control of multiple services SHOULD leverage the credit pool concept when supporting the tariff time change. The Diameter credit-control server SHOULD include both the Tariff-Time- Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message (i.e., two instances of the Multiple-Services-Credit- Control AVP). One of the granted units is allocated to be used before the potential tariff change, while the second granted units are for use after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and/or Rating-Group. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change in a single instance of the Multiple-Services-Credit-Control AVP.
クレジットプール概念は基本的なただ一つの割当て関税時刻変更メカニズム(セクション5.1.1で説明されたメカニズム)の過剰の予約効果を避ける最適のツールです。 したがって、関税が時刻変更であるとサポートするとき、Diameter金融調整クライアントと複数のサービスSHOULDの独立している金融調整を実装するサーバがクレジットプール概念を利用します。 Diameter金融調整サーバSHOULDは答えメッセージ(すなわち、Multiple-サービスクレジットコントロールAVPの2つのインスタンス)における2つの割当て配分にTariff-時間変化とTariff変化用法AVPsの両方を含んでいます。 潜在的関税変化の前で使用されるために与えられたユニットの1つを割り当てます、関税変化の後に2番目の与えられたユニットは使用のためのものですが。 両方の与えられたユニット割当ては同じService-識別子、そして/または、Rating-グループを含まなければなりません。 この二元的な割当てメカニズムは、総合的が、使用されて、ユニットがクレジットの予約を決して超えていないと報告したのを確実にします。 Diameter金融調整クライアントは、関税の前後に両方の中古の単位がMultipleサービスクレジットが制御されたAVPのただ一つのインスタンスで変化すると報告します。
Hakala, et al. Standards Track [Page 20] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[20ページ]。
The failure handling for credit-control sessions is defined in section 5.7 and reflected in the basic credit-control state machine in section 7. Credit-control clients and servers implementing the independent credit-control of multiple services in a (sub-)session functionality MUST ensure failure handling and general behavior fully consistent with the above mentioned sections, while maintaining the ability to handle parallel ongoing credit re-authorization within a (sub-)session. Therefore, it is RECOMMENDED that Diameter credit- control clients maintain a PendingU message queue and restart the Tx timer (section 13) every time a CCR message with the value UPDATE_REQUEST is sent while they are in PendingU state. When answers to all pending messages are received, the state machine moves to OPEN state, and Tx is stopped. Naturally, the action performed when a problem for the session is detected according to section 5.7 affects all the ongoing services (e.g., failover to a backup server if possible affect all the CCR messages with the value UPDATE_REQUEST in the PendingU queue).
金融調整セッションのための失敗取り扱いは、セクション5.7で定義されていてセクション7で基本的な金融調整州のマシンで反射しています。 金融調整クライアントとaの複数のサービスの独立している金融調整を実装するサーバ、(サブ、)、セッションの機能性がaの中で平行な進行中のクレジット再承認を扱う能力を維持している間、上記のセクションと完全に一致した失敗取り扱いと一般的な振舞いを確実にしなければならない、(サブ、)、セッション。 したがって、彼らがPendingU状態にある間、値のUPDATE_REQUESTがあるCCRメッセージを送るときはいつも、DiameterクレジットコントロールクライアントがPendingUメッセージキューを維持して、Txタイマ(セクション13)を再開するのは、RECOMMENDEDです。 すべての未定のメッセージの答えが受け取られているとき、州のマシンはオープン状態に移行します、そして、Txは止められます。 当然、セクション5.7によると、セッションのための問題が検出されるとき実行された動作はすべての進行中のサービスに影響します(できれば、例えば、バックアップサーバへのフェイルオーバーは値のUPDATE_REQUESTと共にPendingU待ち行列ですべてのCCRメッセージに影響します)。
Since the client may send CCR messages with the value UPDATE_REQUEST while in PendingU (i.e., without waiting for an answer to ongoing credit re-authorization), the time space between these requests may be very short, and the server may not have received the previous request(s) yet. Therefore, in this situation the server may receive out of sequence requests and SHOULD NOT consider this an error condition. A proper answer is to be returned to each of those requests.
以来、PendingU(すなわち、返事を待たずに進行中のクレジット再承認への)では、これらの要求の間の時間スペースが非常に短いかもしれなく、サーバがまだ前の要求を受け取っていないかもしれない間、クライアントは値のUPDATE_REQUESTがあるメッセージをCCRに送るかもしれません。 したがって、サーバが順序が狂って受けるかもしれないこの状況で、要求とSHOULD NOTは、これがエラー条件であると考えます。 適切な答えはそれぞれのそれらの要求に返すことです。
5.2. First Interrogation
5.2. 最初に、査問
When session based credit-control is required (e.g., the authentication server indicated a prepaid user), the first interrogation MUST be sent before the Diameter credit-control client allows any service event to the end user. The CC-Request-Type is set to the value INITIAL_REQUEST in the request message.
セッションに基づいている金融調整を必要とするとき(例えば、認証サーバは前払いのユーザを示しました)、Diameter金融調整クライアントがどんなサービスイベントもエンドユーザに許す前に最初の査問を送らなければなりません。 CC要求タイプは要求メッセージの値のINITIAL_REQUESTに用意ができています。
If the Diameter credit-control client knows the cost of the service event (e.g., a content server delivering ringing tones may know their cost) the monetary amount to be charged is included in the Requested-Service-Unit AVP. If the Diameter credit-control client does not know the cost of the service event, the Requested-Service- Unit AVP MAY contain the number of requested service events. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP to indicate that the quota for the associated service/rating-group is requested. In the case of multiple services, the Service-Identifier AVP or the Rating-Group AVP within the Multiple-Services-Credit-Control AVP always indicates the service concerned. Additional service event information to be rated
Diameter金融調整クライアントがサービスイベントの費用を知っているなら(例えば、呼出音を提供する満足しているサーバはそれらの費用を知るかもしれません)、請求される通貨の量はRequestedサービスユニットAVPに含まれています。 Diameter金融調整クライアントがサービスイベントの費用を知らないなら、Requested-サービスユニットAVP MAYは要求されたサービスイベントの数を含んでいます。 Multipleサービスクレジットが制御されたAVPが使用されているところでは、それは関連格付けサービス/グループのための割当てが要求されているのを示すRequestedサービスユニットAVPを含まなければなりません。 複数のサービスの場合では、Multipleサービスクレジットが制御されたAVPの中のService-識別子AVPかRating-グループAVPが、いつもサービスは関係があったのを示します。 評定される追加サービスイベント情報
Hakala, et al. Standards Track [Page 21] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[21ページ]。
MAY be sent as service specific AVPs or MAY be sent within the Service-Parameter-Info AVP at command level. The Service-Context-Id AVP indicates the service specific document applicable to the request.
5月をサービスの特定のAVPsとして送るか、またはServiceパラメタインフォメーションAVPの中でコマンドレベルで送るかもしれません。 Service文脈イドAVPは要求に対する特定のドキュメント適用されるサービスを示します。
The Event-Timestamp AVP SHOULD be included in the request and contains the time when the service event is requested in the service element. The Subscription-Id AVP SHOULD be included to identify the end user in the credit-control server. The credit-control client MAY include the User-Equipment-Info AVP so that the credit-control server has some indication of the type and capabilities of the end user access device. How the credit-control server uses this information is outside the scope of this document.
Event-タイムスタンプAVP SHOULDは要求に含まれていて、サービスイベントがサービス要素で要求される時を含んでいます。 含まれています。Subscription-イドAVP SHOULD、金融調整サーバでエンドユーザを特定してください、そして、金融調整クライアントがUser設備インフォメーションAVPを入れるかもしれないので、金融調整サーバはタイプのいくつかのしるしとエンドユーザアクセスデバイスの能力を持っています。 このドキュメントの範囲の外に金融調整サーバがどうこの情報を使用するかがあります。
The credit-control server SHOULD rate the service event and make a credit-reservation from the end user's account that covers the cost of the service event. If the type of the Requested-Service-Unit AVP is money, no rating is needed, but the corresponding monetary amount is reserved from the end user's account.
金融調整サーバSHOULDはサービスイベントの費用をまかなうエンドユーザのアカウントから、サービスイベントを評定して、クレジット予約をします。 RequestedサービスユニットAVPのタイプがお金であるなら、割合でないのが必要ですが、対応する通貨の量はエンドユーザのアカウントから予約されます。
The credit-control server returns the Granted-Service-Unit AVP in the Answer message to the Diameter credit-control client. The Granted- Service-Unit AVP contains the amount of service units that the Diameter credit-control client can provide to the end user until a new Credit-Control-Request MUST be sent to the credit-control server. If several unit types are sent in the Answer message, the credit- control client MUST handle each unit type separately. The type of the Granted-Service-Unit AVP can be time, volume, service specific, or money, depending on the type of service event. The unit type(s) SHOULD NOT be changed within an ongoing credit-control session.
金融調整サーバはAnswerメッセージでGrantedサービスユニットAVPをDiameter金融調整クライアントに返します。 GrantedサービスユニットAVPは新しいCreditコントロール要求を金融調整サーバに送らなければならないまでDiameter金融調整クライアントがエンドユーザに提供できるサービスユニットの量を含んでいます。Answerメッセージで数人のユニット型を送るなら、クレジットコントロールクライアントは別々に各ユニット型を扱わなければなりません。 GrantedサービスユニットAVPのタイプは、ボリュームの、そして、サービス特有の時間、またはお金であるかもしれません、サービスイベントのタイプに頼っていて。 ユニットは(s) SHOULD NOTをタイプします。進行中の金融調整セッション以内に変えてください。
There MUST be a maximum of one instance of the same unit type in one Answer message. However, if multiple quotas are conveyed to the credit-control client in the Multiple-Services-Credit-Control AVPs, it is possible to carry two instances of the same unit type associated to a service-identifier/rating-group. This is typically the case when a tariff time change is expected and the credit-control server wants to make a distinction between the granted quota before and after tariff change.
1つのAnswerメッセージには同じユニット型の最大1つのインスタンスがあるに違いありません。 しかしながら、複数の割当てがMultipleサービスクレジットが制御されたAVPsの金融調整クライアントに伝えられるなら、格付けサービス識別子/グループに関連づけられた同じユニット型の2つのインスタンスを運ぶのは可能です。 関税時刻変更が予想されるとき、通常、これはそうです、そして、金融調整サーバは関税変化の前後に与えられた割当ての間で区別をしたがっています。
If the credit-control server determines that no further control is needed for the service, it MAY include the result code indicating that the credit-control is not applicable (e.g., if the service is free of charge). This result code at command level implies that the credit-control session is to be terminated.
金融調整サーバが、さらなるコントロールは全くサービスに必要でないことを決定するなら、それが金融調整が適用されないのを示す結果コードを含むかもしれません(例えば、サービスが無料であるなら)。 金融調整セッションはコマンドレベルにおけるこの結果コードが終えられるつもりであることです。
The Credit-Control-Answer message MAY also include the Final-Unit- Indication AVP to indicate that the answer message contains the final
また、Creditコントロール答えメッセージは、答えメッセージが決勝を含むのを示すためにFinal-ユニット指示AVPを含むかもしれません。
Hakala, et al. Standards Track [Page 22] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[22ページ]。
units for the service. After the end user has consumed these units, the Diameter credit-control-client MUST behave as described in section 5.6.
サービスのためのユニット。 エンドユーザがこれらのユニットを消費した後に、Diameterクレジットコントロールクライアントはセクション5.6で説明されるように振る舞わなければなりません。
This document defines two different approaches to perform the first interrogation to be used in different network architectures. The first approach uses credit-control messages after the user's authorization and authentication takes place. The second approach uses service specific authorization messages to perform the first interrogation during the user's authorization/authentication phase, and credit-control messages for the intermediate and final interrogations. If an implementation of the credit-control client supports both the methods, determining which method to use SHOULD be configurable.
このドキュメントは、異なったネットワークアーキテクチャに使用されるべき最初の査問を実行するために2つの異なるアプローチを定義します。 ユーザの承認と認証が行われた後に最初のアプローチは金融調整メッセージを使用します。 2番目のアプローチ用途は、ユーザの承認/認証段階の間、最初の査問を実行する特定の承認メッセージを修理して、中間的で最終的な査問のために金融調整メッセージを修理します。 金融調整クライアントの実装が、両方がメソッドであるとサポートするなら、どのメソッドを決定して、SHOULDを使用するために、構成可能であってください。
In service environments such as the Network Access Server (NAS), it is desired to perform the first interrogation as part of the authorization/authentication process for the sake of protocol efficiency. Further credit authorizations after the first interrogation are performed with credit-control commands defined in this specification. Implementations of credit-control clients operating in the mentioned environments SHOULD support this method. If the credit-control server and AAA server are separate physical entities, the service element sends the request messages to the AAA server, which then issues an appropriate request or proxies the received request forward to the credit-control server.
Network Access Server(NAS)などのサービス環境では、プロトコル効率のために承認/認証過程の一部として最初の査問を実行するのは必要です。 金融調整命令がこの仕様に基づき定義されている状態で、最初の査問の後の追加信用承認は実行されます。 言及された環境SHOULDで働いている金融調整クライアントの実装はこのメソッドをサポートします。 金融調整サーバとAAAサーバが別々の物理的実体であるなら、サービス要素はAAAサーバに要求メッセージを送ります。(次に、それは、金融調整サーバへの容認された要求フォワードを適切な要求かプロキシに発行します)。
In other service environments, such as the 3GPP network and some SIP scenarios, there is a substantial decoupling between registration/access to the network and the actual service request (i.e., the authentication/authorization is executed once at registration/access to the network and is not executed for every service event requested by the subscriber). In these environments, it is more appropriate to perform the first interrogation after the user has been authenticated and authorized. The first, the intermediate, and the final interrogations are executed with credit- control commands defined in this specification.
3GPPネットワークやいくつかのSIPシナリオなどの他のサービス環境に、ネットワークへの登録/アクセスと実際のサービスのリクエストの間には、かなりのデカップリングがあります(すなわち、認証/承認は、ネットワークへの登録/アクセスで一度実行されて、加入者によって要求されたあらゆるサービスイベントのために実行されるというわけではありません)。 これらの環境で、ユーザが認証されて、権限を与えられた後に最初の査問を実行するのは、より適切です。 クレジット制御コマンドがこの仕様に基づき定義されている状態で、1番目、中間介在物、および最終的な査問は実行されます。
Other IETF standards or standards developed by other standardization bodies may define the most suitable method in their architectures.
他のIETF規格か他の標準化本体によって開発された規格がそれらのアーキテクチャで最も適当なメソッドを定義するかもしれません。
5.2.1. First Interrogation after Authorization and Authentication
5.2.1. 最初に、承認と認証の後の査問
The Diameter credit-control client in the service element may get information from the authorization server as to whether credit- control is required, based on its knowledge of the end user. If credit-control is required the credit-control server needs to be contacted prior to initiating service delivery to the end user. The
クレジットコントロールが必要であるかどうかに関してサービス要素のDiameter金融調整クライアントは承認サーバから情報を得るかもしれません、エンドユーザに関する知識に基づいて。 金融調整が必要であるなら、金融調整サーバは、サービス配送をエンドユーザに開始する前に連絡される必要があります。 The
Hakala, et al. Standards Track [Page 23] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[23ページ]。
accounting protocol and the credit-control protocol can be used in parallel. The authorization server may also determine whether the parallel accounting stream is required.
平行で会計プロトコルと金融調整プロトコルを使用できます。 また、承認サーバは、平行な会計ストリームが必要であるかどうか決定するかもしれません。
The following diagram illustrates the case where both protocols are used in parallel and the service element sends credit-control messages directly to the credit-control server. More credit-control sequence examples are given in Annex A.
以下のダイヤグラムは両方のプロトコルが平行で使用されるケースを例証します、そして、サービス要素は直接金融調整サーバに金融調整メッセージを送ります。より多くの金融調整系列の例が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 | |
| |<-------------------| |
直径エンドユーザサービス要素AAAサーバCCサーバ(CCクライアント)| 登録| AA要求/答え(会計、ccまたは両方)| |<----------------->|<------------------>| | | : | | | | : | | | | サービスのリクエスト| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| CCR(初期の金融調整AVPs)| | +|---------------------------------------->| | CCストリーム|| | CCA(与えられたユニット)| | +|<----------------------------------------| | サービス配送| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ACR(AVPsを説明して、始まります)| | : |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|+ | | : | ACA|| 会計ストリーム| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|+ | | : | | | | : | | | | | CCR(アップデート、中古の単位)| | |---------------------------------------->| | | | CCA(与えられたユニット)| | |<----------------------------------------| | : | | | | : | | | | サービスの終わり| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CCR(終了、中古の単位)| | |---------------------------------------->| | | | CCA| | |<----------------------------------------| | | ACR(止まります)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ACA| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 2: Protocol example with first interrogation after user's
authorization/authentication
図2: 最初に、ユーザの承認/認証の後の査問があるプロトコルの例
Hakala, et al. Standards Track [Page 24] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[24ページ]。
5.2.2. Authorization Messages for First Interrogation
5.2.2. 最初に、査問への承認メッセージ
The Diameter credit-control client in the service element MUST actively co-operate with the authorization/authentication client in the construction of the AA request by adding appropriate credit- control AVPs. The credit-control client MUST add the Credit-Control AVP to indicate credit-control capabilities and MAY add other relevant credit-control specific AVPs to the proper authorization/authentication command to perform the first interrogation toward the home Diameter AAA server. The Auth- Application-Id is set to the appropriate value, as defined in the relevant service specific authorization/authentication application document (e.g., [NASREQ], [DIAMMIP]). The home Diameter AAA server authenticates/authorizes the subscriber and determines whether credit-control is required.
サービス要素のDiameter金融調整クライアントは、AA要求の構造で活発に承認/認証クライアントに適切なクレジットコントロールAVPsを加えることによって、協力しなければなりません。 金融調整クライアントは、金融調整能力を示すためにCredit-コントロールAVPを追加しなければならなくて、ホームDiameter AAAサーバに向かって最初の査問を実行するために他の関連金融調整特定のAVPsを適切な承認/認証コマンドに追加するかもしれません。Authアプリケーションイドは適切な値に設定されます、関連サービス特定の承認/認証アプリケーションドキュメント(例えば、[NASREQ]、[DIAMMIP])で定義されるように。 ホームDiameter AAAサーバは、加入者に認証するか、または権限を与えて、金融調整が必要であるかどうか決定します。
If credit-control is not required for the subscriber, the home Diameter AAA server will respond as usual, with an appropriate AA answer message. If credit-control is required for the subscriber and the Credit-Control AVP with the value set to CREDIT_AUTHORIZATION was present in the authorization request, the home AAA server MUST contact the credit-control server to perform the first interrogation. If credit-control is required for the subscriber and the Credit- Control AVP was not present in the authorization request, the home AAA server MUST send an authorization reject answer message.
金融調整は加入者に必要でないなら、ホームDiameter AAAサーバがいつものように反応するでしょう、適切なAA答えメッセージで。 金融調整が加入者に必要であり、CREDIT_AUTHORIZATIONへの選択値群があるCredit-コントロールAVPが承認要求に存在していたなら、ホームAAAサーバは、最初の査問を実行するために金融調整サーバに連絡しなければなりません。 金融調整が加入者に必要であり、CreditコントロールAVPが承認要求に存在していなかったなら、ホームAAAサーバは承認廃棄物答えメッセージを送らなければなりません。
The Diameter AAA server supporting credit-control is required to send the Credit-Control-Request command (CCR) defined in this document to the credit-control server. The Diameter AAA server populates the CCR based on service specific AVPs used for input to the rating process, and possibly on credit-control AVPs received in the AA request. The credit-control server will reserve money from the user's account, will rate the request and will send a Credit-Control-Answer message to the home Diameter AAA server. The answer message includes the Granted-Service-Unit AVP(s) and MAY include other credit-control specific AVPs, as appropriate. Additionally, the credit-control server MAY set the Validity-Time and MAY include the Credit-Control- Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to determine what to do if the sending of credit-control messages to the credit-control server has been temporarily prevented.
金融調整をサポートするDiameter AAAサーバが、本書では金融調整サーバと定義されたCreditコントロール要求命令(CCR)を送るのに必要です。Diameter AAAサーバは特定のAVPsが格付けのプロセスへの入力、およびことによると金融調整のときに利用したサービスに基づいたAA要求に受け取られたCCR AVPsに居住します。 金融調整サーバは、ユーザのアカウントからお金を取っておいて、要求を評定して、Creditコントロール答えメッセージをホームDiameter AAAサーバに送るでしょう。答えメッセージは、GrantedサービスユニットAVP(s)を含んでいて、他の金融調整の特定のAVPsを含むかもしれません、適宜。 さらに、金融調整サーバは、Validity-時間を決めて、一時金融調整サーバへの金融調整メッセージの送付を防いであるなら、何をしたらよいかを決定するために失敗取り扱いを制御しているCredit AVPと失敗取り扱いを借り方に記入するDirect AVPを含むかもしれません。
Upon receiving the Credit-Control-Answer message from the credit- control server, the home Diameter AAA server will populate the AA answer with the received credit-control AVPs and with the appropriate service attributes according to the authorization/authentication specific application (e.g., [NASREQ], [DIAMMIP]). It will then forward the packet to the credit-control client. If the home Diameter AAA server receives a credit-control reject message, it will
クレジット制御サーバからCreditコントロール答えメッセージを受け取ると、承認/認証の特定のアプリケーション(例えば、[NASREQ]、[DIAMMIP])に従って、ホームDiameter AAAサーバは容認された金融調整AVPsと適切なサービス属性でAA答えに居住するでしょう。 そして、それは金融調整クライアントにパケットを送るでしょう。 ホームDiameter AAAサーバが金融調整廃棄物メッセージを受け取ると、それは受け取るでしょう。
Hakala, et al. Standards Track [Page 25] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[25ページ]。
simply generate an appropriate authorization reject message to the credit-control client, including the credit-control specific error code.
単に金融調整の特定のエラーコードを含む金融調整クライアントに適切な承認廃棄物メッセージを生成してください。
In this model, the credit-control client sends further credit-control messages to the credit-control server via the home Diameter AAA server. Upon receiving a successful authorization answer message with the Granted-Service-Unit AVP(s), the credit-control client will grant the service to the end user and will generate an intermediate credit-control request, as required by using credit-control commands. The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 (for how to produce unique value for the CC-Request-Number AVP, see section 8.2).
このモデルでは、金融調整クライアントはホームDiameter AAAサーバでさらなる金融調整メッセージを金融調整サーバに送ります。GrantedサービスユニットAVP(s)でうまくいっている承認答えメッセージを受け取るとき、金融調整クライアントは、エンドユーザに対するサービスを承諾して、必要に応じて金融調整命令を使用することによって、中間的金融調整要求を生成するでしょう。 CCは数を要求します。最初のUPDATE_REQUEST MUSTでは、1に設定されてください(CCが数を要求しているAVPのためにどうユニークな値を生産するかには、セクション8.2を見てください)。
If service specific re-authorization is performed (i.e., authorization-lifetime expires), the credit-control client MUST add to the service specific re-authorization request the Credit-Control AVP with a value set to RE_AUTHORIZATION to indicate that the credit-control server MUST NOT be contacted. When session based credit-control is used for the subscriber, a constant credit-control message stream flows through the home Diameter AAA server. The home Diameter AAA server can make use of this credit-control message flow to deduce that the user's activity is ongoing; therefore, it is recommended to set the authorization-lifetime to a reasonably high value when credit-control is used for the subscriber.
サービスであるなら、特定の再承認は実行されます(すなわち、承認生涯は期限が切れます)、と金融調整サーバは値があるCredit-コントロールAVPがRE_AUTHORIZATIONにセットしたという示す特定の再承認要求であるに違いありませんが、連絡されて、金融調整クライアントはサービスに言い足さなければなりません。 セッションに基づいている金融調整が加入者に使用されるとき、一定の金融調整メッセージストリームはホームDiameter AAAサーバを通して流れます。ホームDiameter AAAサーバはユーザの活動が進行中であると推論するのにこの金融調整メッセージ流動を利用できます。 したがって、金融調整が加入者に使用されるときのかなり高い値への承認生涯を決めるのはお勧めです。
In this scenario, the home Diameter AAA server MUST advertise support for the credit-control application to its peers during the capability exchange process.
このシナリオでは、ホームDiameter AAAサーバは能力交換プロセスの間、金融調整アプリケーションのサポートの同輩に広告を出さなければなりません。
Hakala, et al. Standards Track [Page 26] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[26ページ]。
The following diagram illustrates the use of authorization/authentication messages to perform the first interrogation. The parallel accounting stream is not shown in the figure.
以下のダイヤグラムは最初の査問を実行する承認/認証メッセージの使用を例証します。 平行な会計ストリームは図に示されません。
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 |<-------------------|
| |<-------------------| |
サービス要素直径エンドユーザ(CCクライアント)AAAサーバCCサーバ| サービスのリクエスト| AAは(CC AVPs)を要求します。| |------------------>|------------------->| | | | | CCR(初期のCC AVPs)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| CCA(与えられたユニット)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| AA答え(与えられたユニット)| | サービス配送| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| : | | | | : | | | | : | | | | | | | | | CCR(アップデート、中古の単位)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CCR(アップデート、中古の単位)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| CCA(与えられたユニット)| | | CCA(与えられたユニット)| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| : | | | | : | | | | サービスの終わり| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CCR(終了、中古の単位)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CCR、(用語、中古の単位)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| CCA| | | CCA| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 3: Protocol example with use of the
authorization messages for the first interrogation
図3: 承認メッセージの最初の査問の使用があるプロトコルの例
5.3. Intermediate Interrogation
5.3. 中間的査問
When all the granted service units for one unit type are spent by the end user or the Validity-Time is expired, the Diameter credit-control client MUST send a new Credit-Control-Request to the credit-control server. In the event that credit-control for multiple services is applied in one credit-control session (i.e., units associated to Service-Identifier(s) or Rating-Group are granted), a new Credit- Control-Request MUST be sent to the credit-control server when the
1人のユニット型のためのすべての与えられたサービスユニットがエンドユーザによって費やされるか、またはValidity-時間が満期であるとき、Diameter金融調整クライアントは新しいCreditコントロール要求を金融調整サーバに送らなければなりません。1つの金融調整セッションのときに複数のサービスのための金融調整を適用する場合(すなわち、Service-識別子かRating-グループに関連づけられたユニットを与えます)、新しいCreditコントロール要求を金融調整サーバに送らなければならない、いつ
Hakala, et al. Standards Track [Page 27] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[27ページ]。
credit reservation has been wholly consumed, or upon expiration of the Validity-Time. It is always up to the Diameter credit-control client to send a new request well in advance of the expiration of the previous request in order to avoid interruption in the service element. Even if the granted service units reserved by the credit- control server have not been spent upon expiration of the Validity- Time, the Diameter credit-control client MUST send a new Credit- Control-Request to the credit-control server.
credit reservation has been wholly consumed, or upon expiration of the Validity-Time. It is always up to the Diameter credit-control client to send a new request well in advance of the expiration of the previous request in order to avoid interruption in the service element. Even if the granted service units reserved by the credit- control server have not been spent upon expiration of the Validity- Time, the Diameter credit-control client MUST send a new Credit- Control-Request to the credit-control server.
There can also be mid-session service events, which might affect the rating of the current service events. In this case, a spontaneous updating (a new Credit-Control-Request) SHOULD be sent including information related to the service event even if all the granted service units have not been spent or the Validity-Time has not expired.
There can also be mid-session service events, which might affect the rating of the current service events. In this case, a spontaneous updating (a new Credit-Control-Request) SHOULD be sent including information related to the service event even if all the granted service units have not been spent or the Validity-Time has not expired.
When the used units are reported to the credit-control server, the credit-control client will not have any units in its possession before new granted units are received from the credit-control server. When the new granted units are received, these units apply from the point where the measurement of the reported used units stopped. Where independent credit-control of multiple services is supported, this process may be executed for one or more services, a single rating-group, or a pool within the (sub)session.
When the used units are reported to the credit-control server, the credit-control client will not have any units in its possession before new granted units are received from the credit-control server. When the new granted units are received, these units apply from the point where the measurement of the reported used units stopped. Where independent credit-control of multiple services is supported, this process may be executed for one or more services, a single rating-group, or a pool within the (sub)session.
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message. The Subscription-Id AVP SHOULD be included in the intermediate message to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service specific document applicable to the request.
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message. The Subscription-Id AVP SHOULD be included in the intermediate message to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service specific document applicable to the request.
The Requested-Service-Unit AVP MAY contain the new amount of requested service units. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP if a new quota is requested for the associated service/rating-group. The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. The same unit types used in the previous message SHOULD be used. If several unit types were included in the previous answer message, the used service units for each unit type MUST be reported.
The Requested-Service-Unit AVP MAY contain the new amount of requested service units. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP if a new quota is requested for the associated service/rating-group. The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. The same unit types used in the previous message SHOULD be used. If several unit types were included in the previous answer message, the used service units for each unit type MUST be reported.
The Event-Timestamp AVP SHOULD be included in the request and contains the time of the event that triggered the sending of the new Credit-Control-Request.
The Event-Timestamp AVP SHOULD be included in the request and contains the time of the event that triggered the sending of the new Credit-Control-Request.
Hakala, et al. Standards Track [Page 28] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 28] RFC 4006 Diameter Credit-Control Application August 2005
The credit-control server MUST deduct the used amount from the end user's account. It MAY rate the new request and make a new credit- reservation from the end user's account that covers the cost of the requested service event.
The credit-control server MUST deduct the used amount from the end user's account. It MAY rate the new request and make a new credit- reservation from the end user's account that covers the cost of the requested service event.
A Credit-Control-Answer message with the CC-Request-Type AVP set to the value UPDATE_REQUEST MAY include the Cost-Information AVP containing the accumulated cost estimation for the session, without taking any credit-reservation into account.
A Credit-Control-Answer message with the CC-Request-Type AVP set to the value UPDATE_REQUEST MAY include the Cost-Information AVP containing the accumulated cost estimation for the session, without taking any credit-reservation into account.
The Credit-Control-Answer message MAY also include the Final-Unit- Indication AVP to indicate that the answer message contains the final units for the service. After the end user has consumed these units, the Diameter credit-control-client MUST behave as described in section 5.6.
The Credit-Control-Answer message MAY also include the Final-Unit- Indication AVP to indicate that the answer message contains the final units for the service. After the end user has consumed these units, the Diameter credit-control-client MUST behave as described in section 5.6.
There can be several intermediate interrogations within a session.
There can be several intermediate interrogations within a session.
5.4. Final Interrogation
5.4. Final Interrogation
When the end user terminates the service session, or when the graceful service termination described in section 5.6 takes place, the Diameter credit-control client MUST send a final Credit-Control- Request message to the credit-control server. The CC-Request-Type AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP indicates the service specific document applicable to the request.
When the end user terminates the service session, or when the graceful service termination described in section 5.6 takes place, the Diameter credit-control client MUST send a final Credit-Control- Request message to the credit-control server. The CC-Request-Type AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP indicates the service specific document applicable to the request.
The Event-Timestamp AVP SHOULD be included in the request and contains the time when the session was terminated.
The Event-Timestamp AVP SHOULD be included in the request and contains the time when the session was terminated.
The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. If several unit types were included in the previous answer message, the used service units for each unit type MUST be reported.
The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. If several unit types were included in the previous answer message, the used service units for each unit type MUST be reported.
After final interrogation, the credit-control server MUST refund the reserved credit amount not used to the end user's account and deduct the used monetary amount from the end user's account.
After final interrogation, the credit-control server MUST refund the reserved credit amount not used to the end user's account and deduct the used monetary amount from the end user's account.
A Credit-Control-Answer message with the CC-Request-Type set to the value TERMINATION_REQUEST MAY include the Cost-Information AVP containing the estimated total cost for the session in question.
A Credit-Control-Answer message with the CC-Request-Type set to the value TERMINATION_REQUEST MAY include the Cost-Information AVP containing the estimated total cost for the session in question.
If the user logs off during an ongoing credit-control session, or if some other reason causes the user to become logged off (e.g., final-
If the user logs off during an ongoing credit-control session, or if some other reason causes the user to become logged off (e.g., final-
Hakala, et al. Standards Track [Page 29] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 29] RFC 4006 Diameter Credit-Control Application August 2005
unit indication causes user logoff according to local policy), the service element, according to application specific policy, may send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [DIAMBASE]. Figure 4 illustrates the case when the final-unit indication causes user logoff upon consumption of the final granted units and the generation of STR.
unit indication causes user logoff according to local policy), the service element, according to application specific policy, may send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [DIAMBASE]. Figure 4 illustrates the case when the final-unit indication causes user logoff upon consumption of the final granted units and the generation of STR.
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 | |
| |<-------------------| |
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
Figure 4: User disconnected due to exhausted account
5.5. Server-Initiated Credit Re-Authorization
5.5. Server-Initiated Credit Re-Authorization
The Diameter credit-control application supports server-initiated re-authorization. The credit-control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]. The Auth- Application-Id in the RAR message is set to 4 to indicate Diameter Credit Control, and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.
The Diameter credit-control application supports server-initiated re-authorization. The credit-control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]. The Auth- Application-Id in the RAR message is set to 4 to indicate Diameter Credit Control, and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.
Hakala, et al. Standards Track [Page 30] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 30] RFC 4006 Diameter Credit-Control Application August 2005
Section 5.1.2 defines the feature to enable credit-control for multiple services within a single (sub-)session where the server can authorize credit usage at a different level of granularity. Further, the server may provide credit resources to multiple services or rating groups as a pool (see section 5.1.2 for details and definitions). Therefore, the server, based on its service logic and its knowledge of the ongoing session, can decide to request credit re-authorization for a whole (sub-)session, a single credit pool, a single service, or a single rating-group. To request credit re- authorization for a credit pool, the server includes in the RAR message the G-S-U-Pool-Identifier AVP indicating the affected pool. To request credit re-authorization for a service or a rating-group, the server includes in the RAR message the Service-Identifier AVP or the Rating-Group AVP, respectively. To request credit re- authorization for all the ongoing services within the (sub-)session, the server includes none of the above mentioned AVPs in the RAR message.
Section 5.1.2 defines the feature to enable credit-control for multiple services within a single (sub-)session where the server can authorize credit usage at a different level of granularity. Further, the server may provide credit resources to multiple services or rating groups as a pool (see section 5.1.2 for details and definitions). Therefore, the server, based on its service logic and its knowledge of the ongoing session, can decide to request credit re-authorization for a whole (sub-)session, a single credit pool, a single service, or a single rating-group. To request credit re- authorization for a credit pool, the server includes in the RAR message the G-S-U-Pool-Identifier AVP indicating the affected pool. To request credit re-authorization for a service or a rating-group, the server includes in the RAR message the Service-Identifier AVP or the Rating-Group AVP, respectively. To request credit re- authorization for all the ongoing services within the (sub-)session, the server includes none of the above mentioned AVPs in the RAR message.
If a credit re-authorization is not already ongoing (i.e., the credit-control session is in Open state), a credit control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending the Re-Auth-Answer (RAA) message and MUST initiate the credit re- authorization toward the server by sending a Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with the value UPDATE_REQUEST) is required to complete the procedure. If a quota was allocated to the service, the credit-control client MUST report the used quota in the Credit-Control-Request. Note that the end user does not need to be prompted for the credit re- authorization, since the credit re-authorization is transparent to the user (i.e., it takes place exclusively between the credit-control client and the credit-control server).
If a credit re-authorization is not already ongoing (i.e., the credit-control session is in Open state), a credit control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending the Re-Auth-Answer (RAA) message and MUST initiate the credit re- authorization toward the server by sending a Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with the value UPDATE_REQUEST) is required to complete the procedure. If a quota was allocated to the service, the credit-control client MUST report the used quota in the Credit-Control-Request. Note that the end user does not need to be prompted for the credit re- authorization, since the credit re-authorization is transparent to the user (i.e., it takes place exclusively between the credit-control client and the credit-control server).
Where multiple services in a user's session are supported, the procedure in the above paragraph will be executed at the granularity requested by the server in the RAR message.
Where multiple services in a user's session are supported, the procedure in the above paragraph will be executed at the granularity requested by the server in the RAR message.
If credit re-authorization is ongoing at the time when the RAR message is received (i.e., RAR-CCR collision), the credit-control client successfully acknowledges the request but does not initiate a new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate that a credit re- authorization procedure is already ongoing (i.e., the client was in PendingU state when the RAR was received). The credit-control server SHOULD process the Credit-Control-Request as if it was received in answer to the server initiated credit re-authorization, and should
If credit re-authorization is ongoing at the time when the RAR message is received (i.e., RAR-CCR collision), the credit-control client successfully acknowledges the request but does not initiate a new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate that a credit re- authorization procedure is already ongoing (i.e., the client was in PendingU state when the RAR was received). The credit-control server SHOULD process the Credit-Control-Request as if it was received in answer to the server initiated credit re-authorization, and should
Hakala, et al. Standards Track [Page 31] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 31] RFC 4006 Diameter Credit-Control Application August 2005
consider the server initiated credit re-authorization process successful upon reception of the Re-Auth-Answer message.
consider the server initiated credit re-authorization process successful upon reception of the Re-Auth-Answer message.
When multiple services are supported in a user's session, the server may request credit re-authorization for a credit pool (or for the (sub-)session) while a credit re-authorization is already ongoing for some of the services or rating-groups. In this case, the client acknowledges the server request with an RAA message and MUST send a new Credit-Control-Request message to perform re-authorization for the remaining services/rating-groups. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with value UPDATE_REQUEST) is required to complete the procedure. The server processes the received requests and returns an appropriate answer to both requests.
When multiple services are supported in a user's session, the server may request credit re-authorization for a credit pool (or for the (sub-)session) while a credit re-authorization is already ongoing for some of the services or rating-groups. In this case, the client acknowledges the server request with an RAA message and MUST send a new Credit-Control-Request message to perform re-authorization for the remaining services/rating-groups. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with value UPDATE_REQUEST) is required to complete the procedure. The server processes the received requests and returns an appropriate answer to both requests.
The above-defined procedures are enabled for each of the possibly active Diameter credit-control sub-sessions. The server MAY request re-authorization for an active sub-session by including the CC-Sub- Session-Id AVP in the RAR message in addition to the Session-Id AVP.
The above-defined procedures are enabled for each of the possibly active Diameter credit-control sub-sessions. The server MAY request re-authorization for an active sub-session by including the CC-Sub- Session-Id AVP in the RAR message in addition to the Session-Id AVP.
5.6. Graceful Service Termination
5.6. Graceful Service Termination
When the user's account runs out of money, the user may not be allowed to compile additional chargeable events. However, the home service provider may offer some services; for instance, access to a service portal where it is possible to refill the account, for which the user is allowed to benefit for a limited time. The length of this time is usually dependent on the home service provider policy.
When the user's account runs out of money, the user may not be allowed to compile additional chargeable events. However, the home service provider may offer some services; for instance, access to a service portal where it is possible to refill the account, for which the user is allowed to benefit for a limited time. The length of this time is usually dependent on the home service provider policy.
This section defines the optional graceful service termination feature that MAY be supported by the credit-control server. Credit- control client implementations MUST support the Final-Unit-Indication with at least the teardown of the ongoing service session once the subscriber has consumed all the final granted units.
This section defines the optional graceful service termination feature that MAY be supported by the credit-control server. Credit- control client implementations MUST support the Final-Unit-Indication with at least the teardown of the ongoing service session once the subscriber has consumed all the final granted units.
Where independent credit-control of multiple services in a single credit-control (sub-)session is supported, it is possible to use the graceful service termination for each of the services/rating-groups independently. Naturally, the graceful service termination process defined in the following sub-sections will apply to the specific service/rating-group as requested by the server.
Where independent credit-control of multiple services in a single credit-control (sub-)session is supported, it is possible to use the graceful service termination for each of the services/rating-groups independently. Naturally, the graceful service termination process defined in the following sub-sections will apply to the specific service/rating-group as requested by the server.
In some service environments (e.g., NAS), the graceful service termination may be used to redirect the subscriber to a service portal for online balance refill or other services offered by the home service provider. In this case, the graceful termination process installs a set of packet filters to restrict the user's
In some service environments (e.g., NAS), the graceful service termination may be used to redirect the subscriber to a service portal for online balance refill or other services offered by the home service provider. In this case, the graceful termination process installs a set of packet filters to restrict the user's
Hakala, et al. Standards Track [Page 32] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 32] RFC 4006 Diameter Credit-Control Application August 2005
access capability only to/from the specified destinations. All the IP packets not matching the filters will be dropped or, possibly, re-directed to the service portal. The user may also be sent an appropriate notification as to why the access has been limited. These actions may be communicated explicitly from the server to the client or may be configured per-service at the client. Explicitly signaled redirect or restrict instructions always take precedence over configured ones.
access capability only to/from the specified destinations. All the IP packets not matching the filters will be dropped or, possibly, re-directed to the service portal. The user may also be sent an appropriate notification as to why the access has been limited. These actions may be communicated explicitly from the server to the client or may be configured per-service at the client. Explicitly signaled redirect or restrict instructions always take precedence over configured ones.
It is also possible use the graceful service termination to connect the prepaid user to a top-up server that plays an announcement and prompts the user to replenish the account. In this case, the credit-control server sends only the address of the top-up server where the prepaid user shall be connected after the final granted units have been consumed. An example of this is given in Appendix A (Flow VII).
It is also possible use the graceful service termination to connect the prepaid user to a top-up server that plays an announcement and prompts the user to replenish the account. In this case, the credit-control server sends only the address of the top-up server where the prepaid user shall be connected after the final granted units have been consumed. An example of this is given in Appendix A (Flow VII).
The credit-control server MAY initiate the graceful service termination by including the Final-Unit-Indication AVP in the Credit-Control-Answer to indicate that the message contains the final units for the service.
The credit-control server MAY initiate the graceful service termination by including the Final-Unit-Indication AVP in the Credit-Control-Answer to indicate that the message contains the final units for the service.
When the credit-control client receives the Final-Unit-Indication AVP in the answer from the server, its behavior depends on the value indicated in the Final-Unit-Action AVP. The server may request the following actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS.
When the credit-control client receives the Final-Unit-Indication AVP in the answer from the server, its behavior depends on the value indicated in the Final-Unit-Action AVP. The server may request the following actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS.
A following figure illustrates the graceful service termination procedure described in the following sub-sections.
A following figure illustrates the graceful service termination procedure described in the following sub-sections.
Hakala, et al. Standards Track [Page 33] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 33] RFC 4006 Diameter Credit-Control Application August 2005
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 | | |
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
Hakala, et al. Standards Track [Page 34] RFC 4006 Diameter Credit-Control Application August 2005
Figure 5: Optional graceful service termination procedure
Figure 5: Optional graceful service termination procedure
5.6.1. Terminate Action
5.6.1. Terminate Action
The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does not include any other information. When the subscriber has consumed the final granted units, the service element MUST terminate the service. This is the default handling applicable whenever the credit-control client receives an unsupported Final-Unit-Action value and MUST be supported by all the Diameter credit-control client implementations conforming to this specification. A final Credit- Control-Request message to the credit-control server MUST be sent if the Final-Unit-Indication AVP indicating action TERMINATE was present at command level. The CC-Request-Type AVP in the request is set to the value TERMINATION_REQUEST.
The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does not include any other information. When the subscriber has consumed the final granted units, the service element MUST terminate the service. This is the default handling applicable whenever the credit-control client receives an unsupported Final-Unit-Action value and MUST be supported by all the Diameter credit-control client implementations conforming to this specification. A final Credit- Control-Request message to the credit-control server MUST be sent if the Final-Unit-Indication AVP indicating action TERMINATE was present at command level. The CC-Request-Type AVP in the request is set to the value TERMINATION_REQUEST.
5.6.2. Redirect Action
5.6.2. Redirect Action
The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT indicates to the service element supporting this action that, upon consumption of the final granted units, the user MUST be re-directed to the address specified in the Redirect-Server AVP as follows.
The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT indicates to the service element supporting this action that, upon consumption of the final granted units, the user MUST be re-directed to the address specified in the Redirect-Server AVP as follows.
The credit-control server sends the Redirect-Server AVP in the Credit-Control-Answer message. In such a case, the service element MUST redirect or connect the user to the destination specified in the Redirect-Server AVP, if possible. When the end user is redirected (by using protocols others than Diameter) to the specified server or connected to the top-up server, an additional authorization (and possibly authentication) may be needed before the subscriber can replenish the account; however, this is out of the scope of this specification.
The credit-control server sends the Redirect-Server AVP in the Credit-Control-Answer message. In such a case, the service element MUST redirect or connect the user to the destination specified in the Redirect-Server AVP, if possible. When the end user is redirected (by using protocols others than Diameter) to the specified server or connected to the top-up server, an additional authorization (and possibly authentication) may be needed before the subscriber can replenish the account; however, this is out of the scope of this specification.
In addition to the Redirect-Server AVP, the credit-control server MAY include one or more Restriction-Filter-Rule AVPs or one or more Filter-Id AVPs in the Credit-Control-Answer message to enable the user to access other services (for example, zero-rated services). In such a case, the access device MUST drop all the packets not matching the IP filters specified in the Credit-Control-Answer message and, if possible, redirect the user to the destination specified in the Redirect-Server AVP.
In addition to the Redirect-Server AVP, the credit-control server MAY include one or more Restriction-Filter-Rule AVPs or one or more Filter-Id AVPs in the Credit-Control-Answer message to enable the user to access other services (for example, zero-rated services). In such a case, the access device MUST drop all the packets not matching the IP filters specified in the Credit-Control-Answer message and, if possible, redirect the user to the destination specified in the Redirect-Server AVP.
An entity other than the credit-control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter credit-control application. This case is considered in section 5.6.3.
An entity other than the credit-control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter credit-control application. This case is considered in section 5.6.3.
Hakala, et al. Standards Track [Page 35] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 35] RFC 4006 Diameter Credit-Control Application August 2005
When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The purpose of this interrogation is to indicate to the credit-control server that the specified action started and to report the used units. The credit-control server MUST deduct the used amount from the end user's account but MUST NOT make a new credit reservation. The credit- control client, however, may send intermediate interrogations before all the final granted units have been consumed for which rating and money reservation may be needed; for instance, upon Validity-Time expires or upon mid-session service events that affect the rating of the current service. Therefore, the credit-control client MUST NOT include any rating related AVP in the request sent once all the final granted units have been consumed as an indication to the server that the requested final unit action started, rating and money reservation are not required (when the Multiple-Services-Credit-Control AVP is used, the Service-Identifier or Rating-Group AVPs is included to indicate the concerned services). Naturally, the Credit-Control- Answer message does not contain any granted service unit and MUST include the Validity-Time AVP to indicate to the credit-control client how long the subscriber is allowed to use network resources before a new intermediate interrogation is sent to the server.
When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The purpose of this interrogation is to indicate to the credit-control server that the specified action started and to report the used units. The credit-control server MUST deduct the used amount from the end user's account but MUST NOT make a new credit reservation. The credit- control client, however, may send intermediate interrogations before all the final granted units have been consumed for which rating and money reservation may be needed; for instance, upon Validity-Time expires or upon mid-session service events that affect the rating of the current service. Therefore, the credit-control client MUST NOT include any rating related AVP in the request sent once all the final granted units have been consumed as an indication to the server that the requested final unit action started, rating and money reservation are not required (when the Multiple-Services-Credit-Control AVP is used, the Service-Identifier or Rating-Group AVPs is included to indicate the concerned services). Naturally, the Credit-Control- Answer message does not contain any granted service unit and MUST include the Validity-Time AVP to indicate to the credit-control client how long the subscriber is allowed to use network resources before a new intermediate interrogation is sent to the server.
At the expiry of Validity-Time, the credit-control client sends a Credit-Control-Request (UPDATE_REQUEST) as usual. This message does not include the Used-Service-Unit AVP, as there is no allotted quota to report. The credit-control server processes the request and MUST perform the credit reservation. If during this time the subscriber did not replenish his/her account, whether he/she will be disconnected or will be granted access to services not controlled by a credit-control server for an unlimited time is dependent on the home service provider policy (note: the latter option implies that the service element should not remove the restriction filters upon termination of the credit-control). The server will return the appropriate Result-Code (see section 9.1) in the Credit-Control- Answer message in order to implement the policy-defined action. Otherwise, new quota will be returned, the service element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit-control session and service session as usual.
At the expiry of Validity-Time, the credit-control client sends a Credit-Control-Request (UPDATE_REQUEST) as usual. This message does not include the Used-Service-Unit AVP, as there is no allotted quota to report. The credit-control server processes the request and MUST perform the credit reservation. If during this time the subscriber did not replenish his/her account, whether he/she will be disconnected or will be granted access to services not controlled by a credit-control server for an unlimited time is dependent on the home service provider policy (note: the latter option implies that the service element should not remove the restriction filters upon termination of the credit-control). The server will return the appropriate Result-Code (see section 9.1) in the Credit-Control- Answer message in order to implement the policy-defined action. Otherwise, new quota will be returned, the service element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit-control session and service session as usual.
The credit-control client may not wait until the expiration of the Validity-Time and may send a spontaneous update (a new Credit- Control-Request) if the service element can determine, for instance, that communication between the end user and the top-up server took place. An example of this is given in Appendix A (Figure A.8).
例えば、サービス要素が、エンドユーザと先端上がっているサーバとのコミュニケーションが行われたことを決定できるなら、金融調整クライアントは、Validity-現代の満了まで待っていなくて、自然発生的なアップデート(新しいCreditコントロール要求)を送るかもしれません。 この例はAppendix A(図A.8)で出されます。
Hakala, et al. Standards Track [Page 36] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[36ページ]。
Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A.
金融調整サーバが最初の査問のために既に上で説明されたプロセスを開始したかもしれないことに注意してください。 しかしながら、この最初の査問が実行されるとき、ユーザのアカウントは空であるかもしれません。 この場合、アカウントを補給して、サービスを続ける機会を加入者に提供できます。 金融調整クライアントはFinalユニット指示とValidity-時間AVPsにもかかわらず、どんなGrantedサービスユニットでもCreditが答えを制御しているか、サービス特有の承認答えを受けません。 どんなメッセージもサーバに送らないで、それはすぐに、優雅なサービス終了を始めます。本件に関する例はAppendix Aで例証されます。
5.6.3. Restrict Access Action
5.6.3. アクセス動作を制限してください。
A Final-Unit-Indication AVP with the Final-Unit-Action RESTRICT_ACCESS indicates to the device supporting this action that the user's access MUST be restricted according to the IP packet filters given in the Restriction-Filter-Rule AVP(s) or according to the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Restriction-Filter- Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message.
Finalユニット動作RESTRICT_ACCESSとFinalユニット指示AVPは、Restrictionフィルタ規則AVP(s)で与えられたIPパケットフィルタかFilter-イドAVP(s)によって特定されたIPパケットフィルタに従ってユーザのアクセスを制限しなければならないのをこの動作をサポートするデバイスに示します。 金融調整サーバSHOULDはCreditコントロール答えメッセージにRestriction-フィルタ規則AVPかFilter-イドAVPのどちらかを含んでいます。
An entity other than the credit-control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter credit-control application. Such an entity may, for instance, configure the access device with IP flows to be passed when the Diameter credit-control application indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP packets according to the filter rules that may have been received in the Credit-Control-Answer message in addition to those that may have been configured by the other entity. However, when the user's account cannot cover the cost of the requested service, the action taken is the responsibility of the credit-control server that controls the prepaid subscriber.
金融調整サーバ以外の実体は適切なIPパケットがあるアクセスデバイスがDiameter金融調整アプリケーションに関連して使用されるためにフィルターにかける支給がそうするかもしれません。 例えば、そのような実体は、IPがあるアクセスデバイスがDiameter金融調整アプリケーションがRESTRICT_ACCESSかREDIRECTを示すとき、通過されるために流れるのを構成するかもしれません。 Creditコントロール答えメッセージにもう片方の実体によって構成されたかもしれないものに加えて受け取られたかもしれないフィルタ規則に従って、アクセスデバイスはIPパケットを通過します。 しかしながら、ユーザのアカウントが要求されたサービスの費用をまかなうことができないとき、取られた行動は前払いの加入者を監督する金融調整サーバの責任です。
If another entity working in conjunction with the Diameter credit- control application already provisions the access device with all the required filter rules for the end user, the credit-control server presumably need not send any additional filter. Therefore, it is RECOMMENDED that credit-control server implementations supporting the graceful service termination be configurable for sending the Restriction-Filter-Rule AVP, the Filter-Id AVP, or none of the above.
Diameterクレジットに関連して働いている別の実体がおそらく、すべての必要なフィルタがあるアクセスデバイスがエンドユーザのために統治する条項、既に金融調整サーバが制御する必要はないアプリケーションを制御するなら、あらゆる追加フィルタを送ってください。 したがって、Restrictionフィルタ規則AVP、Filter-イドAVP、または上記のいずれも送らないのに、優雅なサービス終了をサポートする金融調整サーバ実装が構成可能であることは、RECOMMENDEDです。
When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The credit- control client and the credit-control server process this intermediate interrogation and execute subsequent procedures, as specified in the previous section for the REDIRECT action.
最終的な与えられたユニットが消費されたとき、金融調整クライアントは中間的査問を実行しなければなりません。 クレジットコントロールクライアントと金融調整サーバは、この中間的査問を処理して、その後の手順を実行します、前項でREDIRECT動作に指定されるように。
Hakala, et al. Standards Track [Page 37] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[37ページ]。
The credit-control server may initiate the graceful service termination with action RESTRICT_ACCESS already for the first interrogation, as specified in the previous section for the REDIRECT action.
金融調整サーバは既に最初の査問のための動作RESTRICT_ACCESSとの優雅なサービス終了を開始するかもしれません、前項でREDIRECT動作に指定されるように。
5.6.4. Usage of the Server-Initiated Credit Re-Authorization
5.6.4. サーバで開始しているクレジット再承認の用法
Once the subscriber replenishes the account, she presumably expects all the restrictions placed by the graceful termination procedure to be removed immediately and unlimited service' access to be resumed. For the best user experience, the credit-control server implementation MAY support the server-initiated credit re- authorization (see section 5.5). In such a case, upon the successful account top-up, the credit-control server sends the Re-Auth-Request (RAR) message to solicit the credit re-authorization. The credit- control client initiates the credit re-authorization by sending the Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included in the request, as there is no allotted quota to report. The Requested-Service-Unit AVP MAY be included in the request. After the credit-control client successfully receives the Credit-Control-Answer with new Granted-Service-Unit, all the possible restrictions activated for the purpose of the graceful service termination MUST be removed in the service element. The credit-control session and the service session continue as usual.
'加入者がいったんアカウントを補給すると、おそらく、彼女は、優雅な終了手順で置かれたすべての制限がすぐに取り除かれると予想して、無制限な'サービスアクセスが再開されると予想します。 最も良いユーザー・エクスペリエンスのために、金融調整サーバ実装はサーバで開始しているクレジット再承認をサポートするかもしれません(セクション5.5を見てください)。 このような場合には、上にうまくいっているアカウント先端では、金融調整サーバはクレジット再承認に請求するRe-Auth-要求(RAR)メッセージを送ります。 クレジットコントロールクライアントは、AVPが値のUPDATE_REQUESTに設定するCC要求タイプでCreditコントロール要求メッセージを送ることによって、クレジット再承認を開始します。UsedサービスユニットAVPは要求に含まれていません、報告する割り当てられた割当てが全くないとき。 RequestedサービスユニットAVP MAY、要求で含められてください。 金融調整クライアントが新しいGrantedサービスユニットで首尾よくCreditコントロール答えを受けた後に、サービス要素で優雅なサービス終了の目的のために起動されたすべての可能な制限を取り除かなければなりません。 金融調整セッションとサービスセッションはいつものように続きます。
5.7. Failure Procedures
5.7. 失敗手順
The Credit-Control-Failure-Handling AVP (CCFH), as described in this section, determines the behavior of the credit-control client in fault situations. The CCFH may be received from the Diameter home AAA server, from the credit-control server, or may be configured locally. The CCFH value received from the home AAA server overrides the locally configured value. The CCFH value received from the credit-control server in the Credit-Control-Answer message always overrides any existing value.
このセクションで説明されるCreditコントロール失敗取り扱いAVP(CCFH)は欠点状況における、金融調整クライアントの振舞いを決定します。 CCFHをDiameterホームAAAサーバ、金融調整サーバから受け取るか、または局所的に構成するかもしれません。 ホームAAAサーバからのCCFH対価領収は局所的に構成された値をくつがえします。 Creditコントロール答えメッセージの金融調整サーバからのCCFH対価領収はいつもどんな既存の値もくつがえします。
The authorization server MAY include the Accounting-Realtime-Required AVP to determine what to do if the sending of accounting records to the accounting server has been temporarily prevented, as defined in [DIAMBASE]. It is RECOMMENDED that the client complement the credit-control failure procedures with backup accounting flow toward an accounting server. By using different combinations of Accounting-Realtime-Required and Credit-Control-Failure-Handling AVPs, different safety levels can be built. For example, by choosing a Credit-Control-Failure-Handling AVP equal to CONTINUE for the credit-control flow and a Accounting-Realtime-Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the service can be granted
一時会計サーバへの会計帳簿の送付を防いであるなら、承認サーバは何をしたらよいかを決定するためにAccountingリアルタイムが必要なAVPを含むかもしれません、[DIAMBASE]で定義されるように。 クライアントが会計サーバに向かったバックアップ会計流動に金融調整失敗手順を補うのは、RECOMMENDEDです。Accountingリアルタイムが必要でCreditが失敗取り扱いを制御しているAVPsの異なった組み合わせを使用することによって、異なった安全レベルは築き上げることができます。 例えば、金融調整流動に、CONTINUEと等しいCreditコントロール失敗取り扱いAVPと会計流動に、DELIVER_AND_グラントと等しいAccountingリアルタイムが必要なAVPを選ぶことによって、サービスを承諾できます。
Hakala, et al. Standards Track [Page 38] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[38ページ]。
to the end user even if the connection to the credit-control server is down, as long as the accounting server is able to collect the accounting information and information exchange is taking place between the accounting server and credit-control server.
エンドユーザに、金融調整サーバとの接続が下がっても、会計サーバが課金情報を集めることができて、情報交換がかかっている限り、会計サーバと金融調整サーバの間で入賞してください。
As the credit-control application is based on real-time bi- directional communication between the credit-control client and the credit-control server, the usage of alternative destinations and the buffering of messages may not be sufficient in the event of communication failures. Because the credit-control server has to maintain session states, moving the credit-control message stream to a backup server requires a complex context transfer solution. Whether the credit-control message stream is moved to a backup credit-control server during an ongoing credit-control session depends on the value of the CC-Session-Failover AVP. However, failover may occur at any point in the path between the credit- control client and the credit-control server if a transport failure is detected with a peer, as described in [DIAMBASE]. As a consequence, the credit-control server might receive duplicate messages. These duplicates or out of sequence messages can be detected in the credit-control server based on the credit-control server session state machine (section 7), Session-Id AVP, and CC- Request-Number AVP.
金融調整アプリケーションが金融調整クライアントと金融調整サーバとのリアルタイムの両性愛者の方向のコミュニケーションに基づいているとき、代替の目的地の用法とメッセージのバッファリングは通信障害の場合、十分でないかもしれません。 金融調整サーバがセッション州を維持しなければならないので、金融調整メッセージストリームをバックアップサーバに動かすのは複雑な文脈転送解決を必要とします。 金融調整メッセージ小川が進行中の金融調整セッションの間、バックアップ金融調整サーバに動かされるかどうかがCCセッションフェイルオーバーAVPの値に依存します。 しかしながら、輸送失敗が同輩と共に検出されるなら、フェイルオーバーはクレジットコントロールクライアントと金融調整サーバの間の経路の任意な点に起こるかもしれません、[DIAMBASE]で説明されるように。 結果として、金融調整サーバは写しメッセージを受け取るかもしれません。 金融調整サーバセッション州のマシン(セクション7)、Session-イドAVP、およびCC要求番号AVPに基づく金融調整サーバでこれらの写しか順序が狂ってメッセージを検出できます。
If a failure occurs during an ongoing credit-control session, the credit-control client may move the credit-control message stream to an alternative server if the CC-server indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP. A secondary credit-control server name, either received from the home Diameter AAA server or configured locally, can be used as an address of the backup server. If the CC- Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit- control message stream MUST NOT be moved to a backup server.
失敗が進行中の金融調整セッションの間、起こるなら、CCサーバがCCセッションフェイルオーバーAVPでFAILOVER_SUPPORTEDを示したなら、金融調整クライアントは金融調整メッセージストリームを代替のサーバに動かすかもしれません。 バックアップサーバのアドレスとしてホームDiameter AAAサーバから受け取るか、または局所的に構成するセカンダリ金融調整サーバー名を使用できます。CCセッションフェイルオーバーAVPが_SUPPORTED、クレジットコントロールメッセージストリームでないのがそうしなければならないFAILOVER_に用意ができているなら、バックアップサーバに動かされないでください。
For new credit-control sessions, failover to an alternative credit- control server SHOULD be performed if possible. For instance, if an implementation of the credit-control client can determine primary credit-control server unavailability, it can establish the new credit-control sessions with a possibly available secondary credit- control server.
新しい金融調整セッションのために、代替手段クレジットへのフェイルオーバーはサーバSHOULDを制御します。できれば、実行されます。 例えば、金融調整クライアントの実装がプライマリ金融調整サーバ使用不能を決定できるなら、それはことによると利用可能なセカンダリクレジット制御サーバとの新しい金融調整セッションを確立できます。
The AAA transport profile [AAATRANS] defines the application layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) defined in [AAATRANS]. The recommended default initial value for Tw (Twinit) is 30 seconds. Twinit may be set as low as 6 seconds; however, according to [AAATRANS], setting too low a value for Twinit is likely to result in an increased probability of duplicates, as well as an increase in spurious failover and failback attempts. The Diameter base protocol
AAA輸送プロフィール[AAATRANS]は、失敗した同輩からフェイルオーバーを可能にする応用層番犬アルゴリズムを定義して、[AAATRANS]で定義されたウオッチドッグタイマー(Tw)によって制御されます。 Tw(Twinit)におけるお勧めのデフォルト初期の値は30秒です。 Twinitは6秒と同じくらい低く用意ができるかもしれません。 しかしながら、[AAATRANS]に従って低過ぎる値をTwinitに設定するのは写しの増強された確率、および偽りのフェイルオーバーとfailback試みの増加をもたらしそうです。 Diameterベースプロトコル
Hakala, et al. Standards Track [Page 39] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[39ページ]。
is common to several different types of Diameter AAA applications that may be run in the same service element. Therefore, tuning the timer Twinit to a lower value in order to satisfy the requirements of real-time applications, such as the Diameter credit-control application, will certainly cause the above mentioned problems. For prepaid services, however, the end user expects an answer from the network in a reasonable time. Thus, the Diameter credit-control client will react faster than would the underlying base protocol. Therefore this specification defines the timer Tx that is used by the credit-control client (as defined in section 13) to supervise the communication with the credit-control server. When the timer Tx elapses, the credit-control client takes an action to the end user according to the Credit-Control-Failure-Handling AVP.
同じサービス要素に立候補することであるかもしれないいくつかの異なったタイプのDiameter AAAアプリケーションにはコモンがありますか? したがって、Diameter金融調整アプリケーションなどのリアルタイムの応用の要件を満たすために下側の値にタイマTwinitを調整すると、確かに、上記の問題は引き起こされるでしょう。しかしながら、前払いのサービスのために、エンドユーザは妥当な時間でネットワークから答えを予想します。 したがって、Diameter金融調整クライアントはベースが議定書の中で述べる基本的さを反応させるだろうより速く反応するでしょう。 したがって、この仕様は金融調整サーバとのコミュニケーションを監督するのに金融調整クライアント(セクション13で定義されるように)によって使用されるタイマTxを定義します。タイマTxが経過すると、Creditコントロール失敗取り扱いAVPによると、金融調整クライアントはエンドユーザに訴訟を起こします。
When Tx expires, the Diameter credit-control client always terminates the service if the Credit-Control-Failure-Handling (CCFH) AVP is set to the value TERMINATE. The credit-control session may be moved to an alternative server only if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before Tx expires. Therefore, the value TERMINATE is not appropriate if proper failover behavior is desired.
Txが期限が切れると、Creditコントロール失敗取り扱い(CCFH)AVPが値のTERMINATEに用意ができるなら、Diameter金融調整クライアントはいつもサービスを終えます。 金融調整セッションはまた、プロトコル誤りDIAMETER_である場合にだけ代替のサーバに動かされて、Txが期限が切れる前に_BUSYかDIAMETER_UNABLE_TO_DELIVERが受け取られているということであるかもしれません。 したがって、適切なフェイルオーバーの振舞いが望まれているなら、値のTERMINATEは適切ではありません。
If the Credit-Control-Failure-Handling AVP is set to the value CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the end user when the timer Tx expires. An answer message with granted- units may arrive later if the base protocol transport failover occurred in the path to the credit-control server. (The Twinit default value is 3 times more than the Tx recommended value.) The credit-control client SHOULD grant the service to the end user, start monitoring the resource usage, and wait for the possible late answer until the timeout of the request (e.g., 120 seconds). If the request fails and the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control client terminates or continues the service depending on the value set in the CCFH and MUST free all the reserved resources for the credit-control session. If the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or the request times out and the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the credit-control client MAY send the request to a backup server, if possible. If the credit-control client receives a successful answer from the backup server, it continues the credit-control session with such a server. If the re- transmitted request also fails, the credit-control client terminates or continues the service depending on the value set in the CCFH and MUST free all the reserved resources for the credit-control session.
_Creditコントロール失敗取り扱いAVPが値のCONTINUEかRETRY_に用意ができるか、そして、TERMINATE、タイマTxが期限が切れるとき、エンドユーザのサービスは承諾されるでしょう。 ベースプロトコル輸送フェイルオーバーが経路に金融調整サーバに起こったなら、与えられたユニットがある答えメッセージは後で到着するかもしれません。. (Twinitデフォルト値はTxが値を推薦したより何倍もさらに3です。) 金融調整クライアントSHOULDはエンドユーザに対するサービスを承諾して、リソース用法をモニターし始めて、要求(例えば、120秒)のタイムアウトまで可能な遅い答えを待っています。 要求が失敗して、CCセッションフェイルオーバーAVPが用意ができているなら、金融調整クライアントは、_SUPPORTEDではなく、FAILOVER_に、終わらなければならないか、CCFHで選択値群に依存するサービスを続けて、または金融調整セッションのためにすべての予約されたリソースを解放しなければなりません。 要求回のアウトとCCセッションフェイルオーバーAVPはFAILOVER_SUPPORTEDに用意ができています、そして、_プロトコル誤りDIAMETER_UNABLE_TO_DELIVERかまた、DIAMETER_であるなら、BUSYが受け取られているか、または金融調整クライアントはバックアップサーバに要求を送るかもしれません、できれば。 金融調整クライアントがバックアップサーバからうまくいっている答えを受けるなら、それはそのようなサーバとの金融調整セッションを続けています。また、再伝えられた要求が失敗するなら、金融調整クライアントは、終わらなければならないか、CCFHで選択値群に依存するサービスを続けて、または金融調整セッションのためにすべての予約されたリソースを解放しなければなりません。
If a communication failure occurs during the graceful service termination procedure, the service element SHOULD always terminate the ongoing service session.
通信障害が優雅なサービス終了手順の間、起こるなら、サービス要素SHOULDはいつも進行中のサービスセッションを終えます。
Hakala, et al. Standards Track [Page 40] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[40ページ]。
If the credit-control server detects a failure during an ongoing credit-control session, it will terminate the credit-control session and return the reserved units back to the end user's account.
金融調整サーバが進行中の金融調整セッションの間、失敗を検出すると、それは予約されたユニットがエンドユーザのアカウントに支持する金融調整セッションとリターンを終えるでしょう。
The supervision session timer Tcc (as defined in section 13) is used in the credit-control server to supervise the credit-control session.
指揮セッションタイマTcc(セクション13で定義されるように)は、金融調整セッションを監督するのに金融調整サーバに使用されます。
In order to support failover between credit-control servers, information transfer about the credit-control session and account state SHOULD take place between the primary and the secondary credit-control server. Implementations supporting the credit-control session failover MUST also ensure proper detection of duplicate or out of sequence messages. The communication between the servers is regarded as an implementation issue and is outside of the scope of this specification.
金融調整サーバの間のフェイルオーバーをサポートするために、金融調整およそセッション情報転送とアカウント州のSHOULDはプライマリサーバとセカンダリ金融調整サーバの間の場所を取ります。また、金融調整セッションフェイルオーバーをサポートする実装は写しか順序が狂ってメッセージの適切な検出を確実にしなければなりません。 サーバのコミュニケーションは、導入問題と見なされて、この仕様の範囲の外にあります。
6. One Time Event
6. 1つの時間イベント
The one-time event is used when there is no need to maintain any state in the Diameter credit-control server; for example, enquiring about the price of the service. The use of a one-time event implies that the user has been authenticated and authorized beforehand.
Diameter金融調整サーバでどんな状態も維持する必要は全くないとき、1回のイベントは使用されています。 例えば、サービスの価格について情報を得ようとすること。 1回のイベントの使用は、ユーザがあらかじめ認証されて、権限を与えられたのを含意します。
The one time event can be used when the credit-control client wants to know the cost of the service event or to check the account balance without any credit-reservation. It can also be used for refunding service units on the user's account or for direct debiting without any credit-reservation. The one time event is shown in Figure 6.
金融調整クライアントがサービスイベントの費用を知りたいか、または少しもクレジット予約なしで勘定残高をチェックしたがっているという場合に1つの時間イベントを使用できます。 また、ユーザのアカウントでサービスユニットを還付するか、少しもクレジット予約のないダイレクト借り方にそれを使用できます。 1つの時間イベントが図6に示されます。
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 |<-------------------| |
|<----------------->| | |
直径エンドユーザサービス要素AAAサーバCCサーバ(CCクライアント)| サービスのリクエスト| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| CCR(イベント)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| CCR(イベント)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| CCA(与えられたユニット)| | | CCA(与えられたユニット)| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| サービス配送| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|
Figure 6: One time event
図6: 1つの時間イベント
In environments such as the 3GPP architecture, the one time event can be sent from the service element directly to the credit-control server.
3GPPアーキテクチャ、1つの時間イベントはそうすることができる環境で、サービス要素から直接金融調整サーバに送ってください。
Hakala, et al. Standards Track [Page 41] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[41ページ]。
6.1. Service Price Enquiry
6.1. サービス価格調査
The credit-control client may need to know the price of the service event. Services offered by application service providers whose prices are not known in the credit-control client might exist. The end user might also want to get an estimation of the price of a service event before requesting it.
金融調整クライアントは、サービスイベントの価格を知る必要があるかもしれません。 価格が金融調整クライアントで知られていないアプリケーションサービスプロバイダーによって提供されたサービスは存在するかもしれません。 また、それを要求する前に、エンドユーザはサービスイベントの価格に関する見積りを得たがっているかもしれません。
A Diameter credit-control client requesting the cost information MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include the Requested-Action AVP set to PRICE_ENQUIRY, and set the requested service event information into the Service-Identifier AVP in the Credit-Control-Request message. Additional service event information may be sent as service specific AVPs or within the Service- Parameter-Info AVP. The Service-Context-Id AVP indicates the service specific document applicable to the request.
コスト情報を要求するDiameter金融調整クライアントは、EVENT_REQUESTと等しいCC要求タイプAVPを設定して、AVPがPRICE_ENQUIRYに設定するRequested-動作を入れて、Creditコントロール要求メッセージのService-識別子AVPに要求されたサービスイベント情報を設定しなければなりません。 サービスの特定のAVPsかServiceパラメタインフォメーションAVPの中で追加サービスイベント情報を送るかもしれません。 Service文脈イドAVPは要求に対する特定のドキュメント適用されるサービスを示します。
The credit-control server calculates the cost of the requested service event, but it does not perform any account balance check or credit-reservation from the account.
金融調整サーバは要求されたサービスイベントの費用について計算しますが、それはアカウントからどんなアカウントバランスチェックやクレジット予約も実行しません。
The estimated cost of the requested service event is returned to the credit-control client in the Cost-Information AVP in the Credit- Control-Answer message.
要求されたサービスイベントの予算はCreditコントロール答えメッセージのCost-情報AVPの金融調整クライアントに返されます。
6.2. Balance Check
6.2. バランスチェック
The Diameter credit-control client may only have to verify that the end user's account balance covers the cost of a certain service without reserving any units from the account at the time of the inquiry. This method does not guarantee that credit would be left when the Diameter credit-control client requests the debiting of the account with a separate request.
Diameter金融調整クライアントは、エンドユーザの勘定残高が問い合せ時点でアカウントからのどんなユニットも予約しないで、あるサービスの費用をまかなうことを確かめるだけでよいかもしれません。 このメソッドは、Diameter金融調整クライアントが別々の要求とのアカウントの借り方を要求するとクレジットが残されるのを保証しません。
A Diameter credit-control client requesting the balance check MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include a Requested-Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP in order to identify the end user in the credit- control server. The Service-Context-Id AVP indicates the service specific document applicable to the request.
バランスチェックを要求するDiameter金融調整クライアントは、クレジット制御サーバでエンドユーザを特定するためにEVENT_REQUESTと等しいCC要求タイプAVPを設定して、AVPがCHECK_BALANCEに設定するRequested-動作を入れて、Subscription-イドAVPを入れなければなりません。Service文脈イドAVPは要求に対する特定のドキュメント適用されるサービスを示します。
The credit-control server makes the balance check, but it does not make any credit-reservation from the account.
金融調整サーバはバランスチェックを作りますが、それはアカウントからどんなクレジット予約もしません。
The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to the credit-control client in the Check-Balance-Result AVP in the Credit-Control-Answer message.
バランスチェック(ENOUGH_CREDIT/いいえ、_CREDIT)の結果はCreditコントロール答えメッセージのCheckバランス結果AVPの金融調整クライアントに返されます。
Hakala, et al. Standards Track [Page 42] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[42ページ]。
6.3. Direct Debiting
6.3. ダイレクト借り方
There are certain service events for which service execution is always successful in the service environment. The delay between the service invocation and the actual service delivery to the end user can be sufficiently long that the use of the session-based credit- control would lead to unreasonably long credit-control sessions. In these cases, the Diameter credit-control client can use the one-time event scenario for direct debiting. The Diameter credit-control client SHOULD be sure that the requested service event execution would be successful when this scenario is used.
サービス実行がサービス環境にいつも成功しているあるサービスイベントがあります。 エンドユーザへのサービス実施と就航配送の間の遅れはセッションベースのクレジットコントロールの使用が無分別に長い金融調整セッションにつながるように十分切望することであるかもしれません。 これらの場合では、Diameter金融調整クライアントはダイレクト借り方に1回のイベントシナリオを使用できます。 DiameterはクライアントSHOULDをクレジットで制御します。このシナリオが使用されているとき、要求されたサービスイベント実行がうまくいっているのを確認してください。
In the Credit-Control-Request message, the CC-Request-Type is set to the value EVENT_REQUEST and the Requested-Action AVP is set to DIRECT_DEBITING. The Subscription-Id AVP SHOULD be included to identify the end user in the credit-control server. The Event- Timestamp AVP SHOULD be included in the request and contain the time when the service event is requested in the service element. The Service-Context-Id AVP indicates the service specific document applicable to the request.
Creditコントロール要求メッセージでは、CC要求タイプは値のEVENT_REQUESTに用意ができています、そして、Requested-動作AVPはDIRECT_DEBITINGに用意ができています。 Subscription-イドAVP SHOULDは含まれているコネが要求であったなら金融調整サーバのエンドユーザのために. EventタイムスタンプAVP SHOULDを特定するために含まれていて、サービスイベントがサービス要素で要求される時を含んでいます。 Service文脈イドAVPは要求に対する特定のドキュメント適用されるサービスを示します。
The Diameter credit-control client MAY include the monetary amount to be charged in the Requested-Service-Unit AVP, if it knows the cost of the service event. If the Diameter credit-control client does not know the cost of the service event, the Requested-Service-Unit AVP MAY contain the number of requested service events. The Service- Identifier AVP always indicates the service concerned. Additional service event information to be rated MAY be sent as service specific AVPs or within the Service-Parameter-Info AVP.
Diameter金融調整クライアントはRequestedサービスユニットAVPで請求される通貨の量を入れるかもしれません、サービスイベントの費用を知っているなら。 Diameter金融調整クライアントがサービスイベントの費用を知らないなら、RequestedサービスユニットAVP MAYは要求されたサービスイベントの数を含んでいます。 Service識別子AVPは、いつもサービスは関係があったのを示します。 サービスの特定のAVPsかServiceパラメタインフォメーションAVPの中で評定される追加サービスイベント情報を送るかもしれません。
The credit-control server SHOULD rate the service event and deduct the corresponding monetary amount from the end user's account. If the type of the Requested-Service-Unit AVP is money, no rating is needed, but the corresponding monetary amount is deducted from the end user's account.
金融調整サーバSHOULDはサービスイベントを評定して、エンドユーザのアカウントから対応する通貨の量を差し引きます。 RequestedサービスユニットAVPのタイプがお金であるなら、割合でないのが必要ですが、対応する通貨の量はエンドユーザのアカウントから差し引かれます。
The credit-control server returns the Granted-Service-Unit AVP in the Credit-Control-Answer message to the Diameter credit-control client. The Granted-Service-Unit AVP contains the amount of service units that the Diameter credit-control client can provide to the end user. The type of the Granted-Service-Unit can be time, volume, service specific, or money, depending on the type of service event.
金融調整サーバはCreditコントロール答えメッセージでGrantedサービスユニットAVPをDiameter金融調整クライアントに返します。 GrantedサービスユニットAVPはDiameter金融調整クライアントがエンドユーザに提供できるサービスユニットの量を含んでいます。 サービスイベントのタイプに頼っていて、Grantedサービスユニットのタイプは、ボリュームの、そして、サービス特有の時間、またはお金であるかもしれません。
If the credit-control server determines that no credit-control is needed for the service, it can include the result code indicating that the credit-control is not applicable (e.g., service is free of charge).
金融調整サーバが、金融調整は全くサービスに必要でないことを決定するなら、それが金融調整が適用されないのを示す結果コードを含むことができます(例えば、サービスは無料です)。
Hakala, et al. Standards Track [Page 43] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[43ページ]。
For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP containing the estimated total cost of the requested service.
また、有益な目的のために、Creditコントロール答えメッセージは要求されたサービスのおよそ総費用を含むCost-情報AVPを含むかもしれません。
6.4. Refund
6.4. 還付
Some services may refund service units to the end user's account; for example, gaming services.
いくつかのサービスがサービスユニットをエンドユーザのアカウントに還付するかもしれません。 例えば、ゲーミングサービス。
The credit-control client MUST set CC-Request-Type to the value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the Credit-Control-Request message. The Subscription-Id AVP SHOULD be included to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service specific document applicable to the request.
金融調整クライアントはCreditコントロール要求メッセージにREFUND_ACCOUNTへの値のEVENT_REQUESTとRequested-動作AVPにCC要求タイプを設定しなければなりません。 含められています。Subscription-イドAVP SHOULD、金融調整サーバでエンドユーザを特定してください、そして、Service文脈イドAVPは要求に対する特定のドキュメント適用されるサービスを示します。
The Diameter credit-control client MAY include the monetary amount to be refunded in the Requested-Service-Unit AVP. The Service- Identifier AVP always indicates the concerned service. If the Diameter credit-control client does not know the monetary amount to be refunded, in addition to the Service-Identifier AVP it MAY send service specific AVPs or the Service-Parameter-Info AVP containing additional service event information to be rated.
Diameter金融調整クライアントはRequestedサービスユニットAVPで還付される通貨の量を入れるかもしれません。 Service識別子AVPはいつも関係があるサービスを示します。 Diameter金融調整クライアントが、通貨の量が還付されるのを知らないなら、Service-識別子AVPに加えて、それは評定される追加サービスイベント情報を含むサービスの特定のAVPsかServiceパラメタインフォメーションAVPを送るかもしれません。
For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP containing the estimated monetary amount of refunded unit.
また、有益な目的のために、Creditコントロール答えメッセージはおよそ通貨の量の還付されたユニットを含むCost-情報AVPを含むかもしれません。
6.5. Failure Procedure
6.5. 失敗手順
Failover to an alternative credit-control server is allowed for a one time event, as the server is not maintaining session states. For instance, if the credit-control client receives a protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the request to an alternative server, if possible. There MAY be protocol transparent Diameter relays and redirect agents or Diameter credit- control proxies between the credit-control client and credit-control server. Failover may occur at any point in the path between the credit-control client and the credit-control server if a transport failure is detected with a peer, as described in [DIAMBASE]. Because there can be duplicate requests for various reasons, the credit- control server is responsible for real time duplicate detection. Implementation issues for duplicate detection are discussed in [DIAMBASE], Appendix C.
代替の金融調整サーバへのフェイルオーバーは1つの時間イベントのために許容されています、サーバがセッション州を維持していないとき。 _BUSY、例えば、金融調整クライアントがプロトコル誤りDIAMETER_UNABLE_TO_DELIVERかDIAMETER_も受け取るなら、それはそうすることができます。代替手段サーバに要求を再送してください、できれば。 透明なDiameterがリレーするプロトコルと再直接のエージェントがいるかもしれませんか、またはDiameterクレジットは金融調整クライアントと金融調整サーバの間のプロキシを監督します。輸送失敗が同輩と共に検出されるなら、フェイルオーバーは金融調整クライアントと金融調整サーバの間の経路の任意な点に起こるかもしれません、[DIAMBASE]で説明されるように。 様々な理由に関する写し要求があることができるので、クレジット制御サーバはリアルタイムの写し検出に原因となります。 Appendix C、[DIAMBASE]で写し検出のための導入問題について議論します。
When the credit-control client detects a communication failure with the credit-control server, its behavior depends on the requested action. The timer Tx (as defined in section 13) is used in the
金融調整クライアントが金融調整サーバで通信障害を検出するとき、振舞いは要求された動作によります。 タイマTx(セクション13で定義されるように)は使用されます。
Hakala, et al. Standards Track [Page 44] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[44ページ]。
credit-control client to supervise the communication with the credit-control server.
金融調整サーバとのコミュニケーションを監督する金融調整クライアント。
If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and communication failure is detected, the credit-control client SHOULD forward the request messages to an alternative credit-control server, if possible. The secondary credit-control server name, if received from the home Diameter AAA server, can be used as an address of backup server.
要求された動作がPRICE_ENQUIRYかCHECK_BALANCEであり、通信障害が検出されるなら、金融調整クライアントSHOULDは代替の金融調整サーバに要求メッセージを転送します、できれば。 ホームDiameter AAAサーバから受け取るなら、バックアップサーバのアドレスとしてセカンダリ金融調整サーバー名を使用できます。
If the requested action is DIRECT_DEBITING, the Direct-Debiting- Failure-Handling AVP (DDFH) controls the credit-control client's behavior. The DDFH may be received from the home Diameter AAA server or may be locally configured. The credit-control server may also send the DDFH in any CCA message to be used for direct debiting events compiled thereafter. The DDFH value received from the home Diameter AAA server overrides the locally configured value, and the DDFH value received from the credit-control server in a Credit- Control-Answer message always overrides any existing value.
要求された動作がDIRECT_DEBITINGであるなら、Directを借り方に記入していて失敗を扱うAVP(DDFH)は金融調整クライアントの振舞いを制御します。 DDFHをホームDiameter AAAサーバから受け取るか、または局所的に構成するかもしれません。 また、金融調整サーバはどんなその後コンパイルされたダイレクト借り方イベントに使用されるべきCCAメッセージでもDDFHを送るかもしれません。 ホームDiameter AAAサーバからのDDFH対価領収は局所的に構成された値をくつがえします、そして、Creditコントロール答えメッセージの金融調整サーバからのDDFH対価領収はいつもどんな既存の値もくつがえします。
If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT grant the service if it can determine, eventually after a possible re-transmission attempt to an alternative credit-control server, from the result code or error code in the answer message that units have not been debited. Otherwise, the credit-control client SHOULD grant the service to the end user and store the request in the credit-control application level non-volatile storage. (Note that re-sending the request at a later time is not a guarantee that the service will be debited, as the user's account may be empty when the server successfully processes the request.) The credit-control client MUST mark these request messages as possible duplicates by setting the T-flag in the command header as described in [DIAMBASE], section 3.
DDFHが_TERMINATE_OR BUFFERに用意ができているなら、答えメッセージの結果コードかエラーコードからの代替の金融調整サーバへの可能な再トランスミッション試みの後に結局ユニットが借り方に記入されていないことを決定できるなら、金融調整クライアントSHOULD NOTはサービスを承諾します。 さもなければ、金融調整クライアントSHOULDは金融調整アプリケーションレベル非揮発性記憶装置でエンドユーザに対するサービスを承諾して、要求を保存します。 (後で要求を再送するのが、サービスを借り方に記入するという保証でないことに注意してください、サーバが首尾よく要求を処理するとき、ユーザのアカウントが空であるときに。) 金融調整クライアントは、T-旗をコマンドヘッダーにはめ込むことによってこれらの要求メッセージが[DIAMBASE](セクション3)の説明されるのと同じくらい可能な写しであるとマークしなければなりません。
If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the service SHOULD be granted, even if credit-control messages cannot be delivered and messages are not buffered.
サービスSHOULDを与えて、失敗取り扱いを借り方に記入するDirect AVPがCONTINUEに用意ができる、金融調整メッセージがそうすることができないでも、提供されてください。そうすれば、メッセージはバッファリングされません。
If the timer Tx expires, the credit-control client MUST continue the service and wait for a possible late answer. If the request times out, the credit-control client re-transmits the request (marked with T-flag) to a backup credit-control server, if possible. If the re- transmitted request also times out, or if a temporary error is received in answer, the credit-control client buffers the request if the value of the Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER. If a failed answer is received for the
タイマTxが期限が切れるなら、金融調整クライアントは、サービスを続けて、可能な遅い答えを待たなければなりません。 要求回のアウトであるなら、金融調整クライアントは要求(T-旗で、マークされる)をバックアップ金融調整サーバに再送します、できれば。 再伝えることにされるのであるなら、外で回も要求してください。さもないと、答えで一時的な誤りを受けるなら、失敗取り扱いを借り方に記入するDirect AVPの値が_TERMINATE_OR BUFFERに設定されるなら、金融調整クライアントは要求をバッファリングします。 失敗した答えのために、受け取ります。
Hakala, et al. Standards Track [Page 45] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[45ページ]。
re-transmitted request, the credit-control client frees all the resources reserved for the event message and deletes the request regardless of the value of the DDFH.
再送された要求、金融調整クライアントはイベントメッセージのために予約されたすべてのリソースを解放して、DDFHの値にかかわらず要求を削除します。
The Credit-Control-Request with the requested action REFUND_ACCOUNT should always be stored in the credit-control application level non- volatile storage in case of temporary failure. The credit-control client MUST mark the re-transmitted request message as a possible duplicate by setting the T-flag in the command header as described in [DIAMBASE], section 3.
要求された動作REFUND_ACCOUNTとのCreditコントロール要求は一時障害の場合の非揮発性記憶装置の金融調整アプリケーションレベルにいつも保存されるべきです。 金融調整クライアントは、可能な写しとして[DIAMBASE](セクション3)で説明されるようにT-旗をコマンドヘッダーにはめ込むことによって、再送された要求メッセージをマークしなければなりません。
For stored requests, the implementation may choose to limit the number of re-transmission attempts and to define a re-transmission interval.
保存された要求のために、実装は、再トランスミッション試みの数を制限して、再トランスミッション間隔を定義するのを選ぶかもしれません。
Note that only one place in the credit-control system SHOULD be responsible for duplicate detection. If there is only one credit- control server within the given realm, the credit-control server may perform duplicate detection. If there is more than one credit- control server in a given realm, only one entity in the credit- control system should be responsible, to ensure that the end user's account is not debited or credited multiple times for the same service event.
金融調整システムSHOULDの1つの場所だけが写し検出に責任があることに注意してください。 与えられた分野の中に1つのクレジット制御サーバしかなければ、金融調整サーバは写し検出を実行するかもしれません。 1つ以上のクレジット制御サーバが与えられた分野にあれば、クレジット制御システムの1つの実体だけが、複数の回同じサービスイベントについてエンドユーザのアカウントの借り方に記入もしませんし、貸し方に記入もしないのを保証するために原因となるべきです。
7. Credit-Control Application State Machine
7. 金融調整アプリケーション状態マシン
This section defines the credit-control application state machine.
このセクションは金融調整アプリケーション状態マシンを定義します。
The first four state machines are to be observed by credit-control clients. The first one describes the session-based credit-control when the first interrogation is executed as part of the authorization/authentication process. The second describes the session-based credit-control when the first interrogation is executed after the authorization/authentication process. The requirements as to what state machines have to be supported are discussed in section 5.2.
最初の4台の州のマシンが金融調整クライアントによって観測されることになっています。 最初の査問が承認/認証過程の一部として実行されるとき、最初のものはセッションベースの金融調整について説明します。 最初の査問が承認/認証過程の後に実行されるとき、2番目はセッションベースの金融調整について説明します。 セクション5.2でどんな州のマシンが支えられなければならないかに関する要件について議論します。
The third state machine describes the session-based credit-control for the intermediate and final interrogations. The fourth one describes the event-based credit-control. These latter state machines are to be observed by all implementations that conform to this specification.
3番目の州のマシンは中間的で最終的な査問のためのセッションベースの金融調整について説明します。 4番目のものはイベントベースの金融調整について説明します。 これらの後者の州のマシンはこの仕様に従うすべての実装によって観測されることになっています。
The fifth state machine describes the credit-control session from a credit-control server perspective.
5番目の州のマシンは金融調整サーバ見解からの金融調整セッションについて説明します。
Hakala, et al. Standards Track [Page 46] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[46ページ]。
Any event not listed in the state machines MUST be considered an error condition, and a corresponding answer, if applicable, MUST be returned to the originator of the message.
エラー条件であると州のマシンに記載されなかったどんなイベントも考えなければなりません、そして、適切であるなら、対応する答えをメッセージの創始者に返さなければなりません。
In the state table, the event 'Failure to send' means that the Diameter credit-control client is unable to communicate with the desired destination or, if failover procedure is supported, with a possibly defined alternative destination (e.g., the request times out and the answer message is not received). This could be due to the peer being down, or due to a physical link failure in the path to or from the credit-control server.
ステートテーブル、Diameter金融調整クライアントが必要な目的地と伝えることができないイベント'発信しないこと'手段、またはフェイルオーバー手順がサポートされるときのことによると定義された代替の目的地による(例えば、要求回のアウトと受け取られなかった答えメッセージ)で。 これは、サーバか金融調整サーバからの経路での物理的なリンクの故障への同輩による存在、または支払われるべきものであるかもしれません。
The event 'Temporary error' means that the Diameter credit-control client received a protocol error notification (DIAMETER_TOO_BUSY, DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result-Code AVP of the Credit-Control-Answer command. The above protocol error notification may ultimately be received in answer to the re-transmitted request to a defined alternative destination, if failover is supported.
イベント'一時的な誤り'が、Diameter金融調整クライアントがプロトコルエラー通知を受け取ったことを意味する、(DIAMETER、もDIAMETER_LOOP_DETECTED) Creditコントロール答えのResult-コードAVPが命令する_BUSY、DIAMETER_UNABLE_TO_DELIVER、またはコネ。 結局定義された代替の目的地への再送された要求に答えて上記のプロトコルエラー通知を受け取るかもしれません、フェイルオーバーがサポートされるなら。
The event 'Failed answer' means that the Diameter credit-control client received non-transient failure (permanent failure) notification in the Credit-Control-Answer command. The above permanent failure notification may ultimately be received in answer to the re-transmitted request to a defined alternative destination, if failover is supported.
イベント'失敗した答え'は、Diameter金融調整クライアントがCreditコントロール答え命令における非一時障害(永久的な失敗)通知を受け取ったことを意味します。 結局定義された代替の目的地への再送された要求に答えて上記の永久的な失敗通知を受け取るかもしれません、フェイルオーバーがサポートされるなら。
The action 'store request' means that a request is stored in the credit-control application level non-volatile storage.
動作'店要求'は、要求が金融調整アプリケーションレベル非揮発性記憶装置で保存されることを意味します。
The event 'Not successfully processed' means that the credit-control server could not process the message; e.g., due to an unknown end user, account being empty, or errors defined in [DIAMBASE].
'首尾よく処理されなかった'イベントは、金融調整サーバがメッセージを処理できなかったことを意味します。 例えば、未知のエンドユーザのため、空であるか、または[DIAMBASE]で定義された誤りを説明してください。
The event 'User service terminated' can be triggered by various reasons, e.g., normal user termination, network failure, and ASR (Abort-Session-Request). The Termination-Cause AVP contains information about the termination reason, as specified in [DIAMBASE].
様々な理由、例えば、通常のユーザ終了、ネットワーク失敗、およびASRは'ユーザサービスは終えた'イベントを引き起こすことができます(セッション要求を中止してください)。 Termination-原因AVPは[DIAMBASE]で指定されるように退職理由の情報を含んでいます。
The Tx timer, which is used to control the waiting time in the credit-control client in the Pending state, is stopped upon exit of the Pending state. The stopping of the Tx timer is omitted in the state machine when the new state is Idle, as moving to Idle state implies the clearing of the session and all the variables associated to it.
Txタイマ(Pending状態で金融調整クライアントで待ち時間を制御するのに使用される)はPending状態の出口で止められます。 新しい状態がIdleであるときに、Txタイマの停止は州のマシンで省略されます、Idle状態に移行するのがそれに関連づけられたセッションとすべての変数の開拓地を含意するとき。
Hakala, et al. Standards Track [Page 47] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[47ページ]。
The states PendingI, PendingU, PendingT, PendingE, and PendingB stand for pending states to wait for an answer to a credit-control request related to Initial, Update, Termination, Event, or Buffered request, respectively.
州のPendingI、PendingU、PendingT、PendingE、およびPendingBは、未定の州がInitialに関連する金融調整要求の答えを待つのに耐えます、とUpdate、Termination、Event、またはBufferedがそれぞれ要求します。
The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling, respectively.
頭文字語のCCFHとDDFHはそれぞれCreditコントロール失敗取り扱いと失敗取り扱いを借り方に記入するDirectを表します。
In the following state machine table, the failover to a secondary server upon 'Temporary error' or 'Failure to send' is not explicitly described. Moving an ongoing credit-control message stream to an alternative server is, however, possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, as described in section 5.7.
以下の州の工作台では、''一時的な誤りのセカンダリサーバへのフェイルオーバー'発信しないこと'は明らかに説明されません。 しかしながら、CCセッションフェイルオーバーAVPがFAILOVER_SUPPORTEDに用意ができているなら、進行中の金融調整メッセージストリームを代替のサーバに動かすのは可能です、セクション5.7で説明されるように。
Re-sending a credit-control event to an alternative server is supported as described in section 6.5.
代替のサーバに金融調整イベントを再送するのはセクション6.5で説明されるようにサポートされます。
CLIENT, SESSION BASED for the first interrogation with AA request
CLIENT、AA要求による最初の査問のためのSESSION BASED
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send PendingI
access/service AA request
with added
CC AVPs,
start Tx
イベントの動作の新しい状態を述べてください。--------------------------------------------------------------- Send PendingIアクセス/サービスAAが加えられたCC AVPs、スタートTxと共に要求する使用されていないClientかデバイス要求
PendingI Successful AA req. Grant Open
answer received service to
end user,
stop Tx
PendingI Successful AA req。 交付金オープン答えはエンドユーザ、停止Txに対するサービスを受けました。
PendingI Tx expired Disconnect Idle
user/dev
PendingI TxはDisconnect Idleユーザ/devを吐き出しました。
PendingI Failed AA answer received Disconnect Idle
user/dev
PendingI Failed AAは容認されたDisconnect Idleユーザ/devに答えます。
PendingI AA answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingI AA答えグラントIdleはエンドユーザにとって、CREDIT_CONTROL_と等しい結果コードサービスで_どんなAPPLICABLEも受けませんでした。
PendingI User service terminated Queue PendingI
termination
event
PendingI UserサービスはQueue PendingI終了イベントを終えました。
Hakala, et al. Standards Track [Page 48] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[48ページ]。
PendingI Change in rating condition Queue PendingI
changed
rating
condition
event
格付けの状態Queue PendingIのPendingI Changeは格付けの状態イベントを変えました。
CLIENT, SESSION BASED for the first interrogation with CCR
CLIENT、CCRとの最初の査問のためのSESSION BASED
State Event Action New State
----------------------------------------------------------------
イベントの動作の新しい状態を述べてください。----------------------------------------------------------------
Idle Client or device requests Send PendingI
access/service CC initial
req.,
start Tx
使用されていないClientかデバイス要求Send PendingIアクセス/サービスが初期のreqをCCする、Txを始動してください。
PendingI Successful CC initial Stop Tx Open
answer received
初期のStop Txオープン答えが受けたPendingI Successful CC
PendingI Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
発信するPendingI Failureか、グラントIdle一時的な誤りとCONTINUEエンドユーザと等しいCCFHに対するサービス
PendingI Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
TERMINATEサービス、または、_RETRY_AND TERMINATEと等しい発信するPendingI Failure、またはTerminate Idleの一時的な誤りとエンドユーザのCCFH
PendingI Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
TERMINATEエンドユーザのサービスと等しい吐き出されたPendingI TxとCCFH Terminate Idle
PendingI Tx expired and CCFH equal Grant PendingI
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingI Txは期限が切れました、そして、CCFHはCONTINUE、または、RETRY_に対するサービスと_TERMINATEエンドユーザへのグラントPendingIと等しいです。
PendingI CC initial answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED or service
USER_UNKNOWN
結果コードエンドユーザのEND_USER_SERVICE_DENIEDと共に受け取られたPendingI CCの初期の答えTerminate IdleかサービスUSER_UNKNOWN
PendingI CC initial answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingIのCCの初期の答えグラントIdleはエンドユーザにとって、CREDIT_CONTROL_と等しい結果コードサービスで_どんなAPPLICABLEも受けませんでした。
Hakala, et al. Standards Track [Page 49] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[49ページ]。
PendingI Failed CC initial answer Grant Idle
received and CCFH equal to service to
CONTINUE end user
初期の答えグラントIdleが受けたPendingI Failed CCとCONTINUEエンドユーザに対するサービスと等しいCCFH
PendingI Failed CC initial answer Terminate Idle
received and CCFH equal end user's
to TERMINATE or to service
RETRY_AND_TERMINATE
PendingI FailedのCCの初期の答えTerminate Idleは受信しました、そして、TERMINATE、または、サービスRETRY_AND_TERMINATEにCCFHの等しいエンドユーザはいます。
PendingI User service terminated Queue PendingI
termination
event
PendingI UserサービスはQueue PendingI終了イベントを終えました。
PendingI Change in rating condition Queue PendingI
changed
rating
condition
event
格付けの状態Queue PendingIのPendingI Changeは格付けの状態イベントを変えました。
CLIENT, SESSION BASED for intermediate and final interrogations
CLIENT、中間的で最終的な査問のためのSESSION BASED
State Event Action New State
----------------------------------------------------------------
イベントの動作の新しい状態を述べてください。----------------------------------------------------------------
Open Granted unit elapses Send PendingU
and no final unit CC update
indication received req.,
start Tx
開いているGrantedユニットがreqにSend PendingUといいえ、最終的なユニットCCアップデート指示受け取られていた状態で経過する、Txを始動してください。
Open Granted unit elapses Terminate PendingT
and final unit action end user's
equal to TERMINATE service, send
received CC termination
req.
開いているGrantedユニットは経過します。Terminate PendingTと最終的なユニット動作エンドユーザはTERMINATEサービスに堪えて、容認されたCC終了reqを送ってください。
Open Change in rating condition Send PendingU
in queue CC update
req.,
Start Tx
待ち行列CCにおける格付けの状態Send PendingUの開いているChangeがreqをアップデートする、Start Tx
Open Service terminated in queue Send PendingT
CC termination
req.
開いているServiceは待ち行列Send PendingT CC終了reqで終わりました。
Open Change in rating condition Send PendingU
or Validity-Time elapses CC update
req.,
Start Tx
Send PendingUかValidity-時間が経過するという格付けの条件での開いているChangeがアップデートreqをCCする、Start Tx
Hakala, et al. Standards Track [Page 50] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[50ページ]。
Open User service terminated Send PendingT
CC termination
req.
開いているUserサービスはSend PendingT CC終了reqを終えました。
Open RAR received Send RAA PendingU
followed by
CC update req.,
start Tx
開いているRARがCCアップデートreqによって続かれたSend RAA PendingUを受けた、Txを始動してください。
PendingU Successful CC update Stop Tx Open
answer received
PendingU Successful CCアップデートStop Txオープン答えは受信されました。
PendingU Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
発信するPendingU Failureか、グラントIdle一時的な誤りとCONTINUEエンドユーザと等しいCCFHに対するサービス
PendingU Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
TERMINATEサービス、または、_RETRY_AND TERMINATEと等しい発信するPendingU Failure、またはTerminate Idleの一時的な誤りとエンドユーザのCCFH
PendingU Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
TERMINATEエンドユーザのサービスと等しい吐き出されたPendingU TxとCCFH Terminate Idle
PendingU Tx expired and CCFH equal Grant PendingU
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingU Txは期限が切れました、そして、CCFHはCONTINUE、または、RETRY_に対するサービスと_TERMINATEエンドユーザへのグラントPendingUと等しいです。
PendingU CC update answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED service
結果コードエンドユーザのEND_USER_SERVICE_DENIEDサービスで受け取られたPendingU CCアップデート答えTerminate Idle
PendingU CC update answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingU CCアップデート答えグラントIdleはエンドユーザにとって、CREDIT_CONTROL_と等しい結果コードサービスで_どんなAPPLICABLEも受けませんでした。
PendingU Failed CC update Grant Idle
answer received and service to
CCFH equal to CONTINUE end user
グラントのIdle答えが受けたPendingU Failed CCアップデートとCONTINUEエンドユーザと等しいCCFHに対するサービス
PendingU Failed CC update Terminate Idle
answer received and CCFH end user's
equal to TERMINATE or service
to RETRY_AND_TERMINATE
PendingU FailedはTerminate Idle答えが受けたアップデートとCCFHエンドユーザの同輩をTERMINATEにCCするか、またはRETRY_と_にTERMINATEを調整します。
Hakala, et al. Standards Track [Page 51] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[51ページ]。
PendingU User service terminated Queue PendingU
termination
event
PendingU UserサービスはQueue PendingU終了イベントを終えました。
PendingU Change in rating Queue PendingU
condition changed
rating
condition
event
Queue PendingUが条件とさせる格付けにおけるPendingU Changeは格付けの状態イベントを変えました。
PendingU RAR received Send RAA PendingU
PendingU RARはSend RAA PendingUを受けました。
PendingT Successful CC Idle
termination answer received
PendingT Successful CC Idle終了答えは受信されました。
PendingT Failure to send, temporary Idle
error, or failed answer
発信するPendingT Failure、一時的なIdle誤り、または失敗した答え
PendingT Change in rating condition PendingT
格付けの状態PendingTのPendingT Change
CLIENT, EVENT BASED
クライアント、基づくイベント
State Event Action New State
----------------------------------------------------------------
Idle Client or device requests Send PendingE
a one-time service CC event
req.,
Start Tx
イベントの動作の新しい状態を述べてください。---------------------------------------------------------------- 使用されていないClientかデバイスがSend PendingEのa1回のサービスCCイベントreqを要求する、Start Tx
Idle Request in storage Send PendingB
stored
request
ストレージSend PendingBにおける使用されていないRequestは要求を保存しました。
PendingE Successful CC event Grant Idle
answer received service to
end user
PendingE Successful CCイベントグラントのIdle答えはエンドユーザに対するサービスを受けました。
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 Failure(一時的なIndicate Idle誤り)はサービス答えが受けたCCイベントに失敗したか、または誤りTxは期限が切れました。 要求された動作CHECK_BALANCEか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
PendingEは、結果コードエンドユーザのEND_USER_SERVICE_DENIEDと共に受け取られたイベント答えTerminate IdleかサービスUSER_UNKNOWNとTxが稼働するのをCCします。
Hakala, et al. Standards Track [Page 52] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[52ページ]。
PendingE CC event answer Grant Idle
received with result code service
CREDIT_CONTROL_NOT_APPLICABLE; to end
requested action user
DIRECT_DEBITING
PendingE CCイベント答えグラントIdleは_APPLICABLEではなく、結果コードサービスCREDIT_CONTROL_で受信しました。 要求された動作ユーザ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 Failure、一時的なグラントIdle誤り、または失敗したCCイベントサービス答えが受信されました。 動作DIRECT_DEBITINGを終わらせるよう要求されています。 CONTINUEと等しいユーザDDFH
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 Failed CCイベントTerminate Idleは受け取られていているか一時的なエンドユーザ誤りに答えます。 動作サービスDIRECT_DEBITINGは要求しました。 _TERMINATE_OR BUFFERと等しいDDFHとTx稼働
PendingE Tx expired; requested Grant PendingE
action DIRECT_DEBITING service
to end
user
PendingE Txは期限が切れました。 エンドユーザに対する要求されたグラントのPendingE動作DIRECT_DEBITINGサービス
PendingE Failure to send; requested Store Idle
action DIRECT_DEBITING; request with
DDFH equal to T-flag
TERMINATE_OR_BUFFER
発信するPendingE Failure。 ストアIdle動作DIRECT_DEBITINGは要求しました。 T-旗のTERMINATEと等しいDDFHと共に_OR_BUFFERを要求してください。
PendingE Temporary error; requested Store Idle
action DIRECT_DEBITING; request
DDFH equal to
TERMINATE_OR_BUFFER;
Tx expired
PendingE Temporary誤り。 ストアIdle動作DIRECT_DEBITINGは要求しました。 _TERMINATE_OR BUFFERと等しいDDFHを要求してください。 Txは期限が切れました。
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は結果コードEND_USER_SERVICE DENIEDと共に受け取られたIdleかUSER_UNKNOWNに答えるか、または答えます。 動作DIRECT_DEBITINGは要求しました。 Txは期限が切れました。
PendingE Failed CC event answer Indicate Idle
received; requested service
action REFUND_ACCOUNT error and
delete request
PendingE Failed CCイベント答えIndicate Idleは受信しました。 要求されていて、動作REFUND_ACCOUNT誤りを修理してください、そして、要求を削除してください。
Hakala, et al. Standards Track [Page 53] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[53ページ]。
PendingE Failure to send or Store Idle
Tx expired; requested request
action REFUND_ACCOUNT with T-flag
発信するPendingE FailureかストアIdle Txが期限が切れました。 T-旗がある要求された要求動作REFUND_ACCOUNT
PendingE Temporary error, Store Idle
and requested action request
REFUND_ACCOUNT
PendingE Temporary誤り、ストアIdle、および要求された動作はREFUND_ACCOUNTを要求します。
PendingB Successful CC answer Delete Idle
received request
PendingB Successful CC答えDelete Idleは要求を受け取りました。
PendingB Failed CC answer Delete Idle
received request
PendingB Failed CC答えDelete Idleは要求を受け取りました。
PendingB Failure to send or Idle
temporary error
発信するPendingB FailureかIdleの一時的な誤り
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
初期の要求Sendオープンが受けたCCを空費してください、そして、首尾よく初期の処理答え、蓄えのユニットをCCしてください、そして、Tccを始動してください。
Idle CC initial request Send Idle
received but not CC initial
successfully processed answer with
Result-Code
!= SUCCESS
使用されていないCC初期の要求Send Idleは受信しますが、Result-コード!=SUCCESSとの初期の首尾よく処理された答えをCCしません。
Idle CC event request Send Idle
received and successfully CC event
processed answer
活動していないCCイベント要求Send Idleは受信して、首尾よくイベントの処理答えをCCします。
Idle CC event request Send Idle
received but not CC event
successfully processed answer with
Result-Code
!= SUCCESS
首尾よくイベントをCCしないのを除いて、Send Idleが受け取った無駄なCCイベント要求はResult-コード!=SUCCESSとの答えを処理しました。
Hakala, et al. Standards Track [Page 54] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[54ページ]。
Open CC update request Send CC Open
received and successfully update answer,
processed debit used
units,
reserve
new units,
restart Tcc
開いているCC更新要求Sendは受けられたオープンをCCして、首尾よく答えをアップデートして、処理借り方はユニットを使用して、蓄えは新しいユニットです、再開Tcc
Open CC update request Send Idle
received but not CC update
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
首尾よくアップデートをCCしないのを除いて、Send Idleが受け取った開いているCC更新要求はResult-コードとの答えを処理しました!= SUCCESS、借り方はユニットを使用しました。
Open CC termination request Send Idle
received and successfully CC termin.
processed answer,
Stop Tcc,
debit used
units
開いているCC終了要求Send Idleは受信しました、そして、首尾よく、termin処理答え、Stop Tccが借り方に記入するCCはユニットを使用しました。
Open CC termination request Send Idle
received but not CC termin.
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
開いているCC終了要求Send Idleは受信しますが、termin Result-コードとの首尾よく処理された答えをCCしません!= SUCCESS、借り方はユニットを使用しました。
Open Session supervision timer Tcc Release Idle
expired reserved
units
開いているSessionの指揮タイマTcc Release Idle満期の予約されたユニット
8. Credit-Control AVPs
8. 金融調整AVPs
This section defines the credit-control AVPs that are specific to Diameter credit-control application and that MAY be included in the Diameter credit-control messages.
このセクションはDiameter金融調整アプリケーションに特定であり、Diameter金融調整メッセージに含まれるかもしれない金融調整AVPsを定義します。
The AVPs defined in this section MAY also be included in authorization commands defined in authorization-specific applications, such as [NASREQ] and [DIAMMIP], if the first interrogation is performed as part of the authorization/authentication process, as described in section 5.2.
また、このセクションで定義されたAVPsは承認特有のアプリケーションで定義された承認コマンドに含まれるかもしれません、[NASREQ]や[DIAMMIP]のように、最初の査問が承認/認証過程の一部として実行されるなら、セクション5.2で説明されるように。
Hakala, et al. Standards Track [Page 55] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[55ページ]。
The Diameter AVP rules are defined in the Diameter Base [DIAMBASE], section 4. These AVP rules are observed in AVPs defined in this section.
Diameter AVP規則はDiameter基地[DIAMBASE]の中で定義されて、セクションは4です。 これらのAVP規則はこのセクションで定義されたAVPsで守られます。
The following table describes the Diameter AVPs defined in the credit-control application, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The Diameter base [DIAMBASE] specifies the AVP Flag rules for AVPs in section 4.5.
以下のテーブルがDiameter AVPsについて説明する、金融調整アプリケーション、彼らのAVP Code値、タイプ、可能な旗の値で定義されて、AVP MAYは暗号化されています。 Diameterベース[DIAMBASE]はセクション4.5でAVP Flag規則をAVPsに指定します。
+--------------------+
| 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 | | | | | |
+--------------------+ | AVP Flag規則| |----+-----+----+----|----+ AVP部| | |SHLD|必須| | 属性名前コードはデータ型を定義しました。|必須| 5月| NOT|NOT|Encr| -----------------------------------------|----+-----+----+----|----| CC相関関係イド411 8.1OctetString| | P、M| | V| Y| CC入力八重奏412、8.24Unsigned64| M| P| | V| Y| 8.22が分類したCCお金の413| M| P| | V| Y| CC出力八重奏414、8.25Unsigned64| M| P| | V| Y| CCリクエスト番号415 8.2Unsigned32| M| P| | V| Y| 416 8.3が数え上げたCC要求タイプ| M| P| | V| Y| CCサービス-417 8.26Unsigned64| M| P| | V| Y| 特定のユニット| | | | | | 列挙されたCCセッション-418 8.4| M| P| | V| Y| フェイルオーバー| | | | | | CCのサブセッションのイド419 8.5Unsigned64| M| P| | V| Y| 420が8.21にCCして調節する、Unsigned32| M| P| | V| Y| CCの総八重奏421、8.23Unsigned64| M| P| | V| Y| 8.32が列挙したCCユニット型454| M| P| | V| Y| -バランス-422 8.6に列挙されていた状態でチェックしてください。| M| P| | V| Y| 結果| | | | | | コスト情報423 8.7は分類されました。| M| P| | V| Y| 費用単位424、8.12UTF8String| M| P| | V| Y| 8.13が数え上げた金融調整426| M| P| | V| Y| 8.14が列挙したクレジットコントロール-427| M| P| | V| Y| 失敗取り扱い| | | | | | 通貨コード425、8.11Unsigned32| M| P| | V| Y| 8.15が列挙したダイレクト借り方-428| M| P| | V| Y| 失敗取り扱い| | | | | | 解説者429 8.9Integer32| M| P| | V| Y| 8.35が列挙した最終的なユニット動作449| M| P| | V| Y| 最終的なユニット-430 8.34は分類されました。| M| P| | V| Y| 指示| | | | | | 与えられたサービス-431 8.17は分類されました。| M| P| | V| Y| ユニット| | | | | | G-S-Uプール-453 8.31Unsigned32| M| P| | V| Y| 識別子| | | | | |
Hakala, et al. Standards Track [Page 56] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[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 |
G-S-Uプール-457 8.30は分類されました。| M| P| | V| Y| 参照| | | | | | 8.16が分類した複数のサービス456| M| P| | V| Y| -金融調整| | | | | | 8.40が列挙した複数のサービス455| M| P| | V| Y| -インディケータ| | | | | | 格付けグループ432、8.29Unsigned32| M| P| | V| Y| 8.38が列挙した再直接のアドレス433| M| P| | V| Y| -タイプ| | | | | | 8.37が分類した再直接のサーバ434| M| P| | V| Y| 再直接のサーバ435、8.39UTF8String| M| P| | V| Y| -アドレス| | | | | | 8.41が列挙した要求された動作436| M| P| | V| Y| 8.18が分類した要求されたサービス437| M| P| | V| Y| -ユニット| | | | | | 制限438 8.36IPFiltrRule| M| P| | V| Y| -フィルタ規則| | | | | | サービス文脈461、8.42UTF8String| M| P| | V| Y| -イド| | | | | | サービス439 8.28Unsigned32| M| P| | V| Y| 識別子| | | | | | 8.43が分類したサービスパラメタ440| | P、M| | V| Y| -インフォメーション| | | | | | サービス441 8.44Unsigned32| | P、M| | V| Y| パラメータの型| | | | | | サービス442 8.45OctetString| | P、M| | V| Y| パラメタ値| | | | | | 8.46が分類した購読イド443| M| P| | V| Y| 購読イド444、8.48UTF8String| M| P| | V| Y| -データ| | | | | | 8.47が列挙した購読イド450| M| P| | V| Y| -タイプ| | | | | | 8.27が列挙した関税変化452| M| P| | V| Y| -用法| | | | | | 8.20が調節する関税時間451| M| P| | V| Y| -変化| | | | | | 単価445 8.8は分類されました。| M| P| | V| Y| 8.19が分類した中古のサービス単位446| M| P| | V| Y| 8.49が分類したユーザ設備458| | P、M| | V| Y| -インフォメーション| | | | | | 8.50が列挙したユーザ設備459| | P、M| | V| Y| -インフォメーションタイプ| | | | | | ユーザ設備460、8.51OctetString| | P、M| | V| Y| -インフォメーション値| | | | | | 値ケタ447、8.10Integer64| M| P| | V| Y| 448が8.33に正当性で調節する、Unsigned32| M| P| | V| Y|
Hakala, et al. Standards Track [Page 57] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[57ページ]。
8.1. CC-Correlation-Id AVP
8.1. CC相関関係イドAVP
The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and contains information to correlate credit-control requests generated for different components of the service; e.g., transport and service level. The one who allocates the Service-Context-Id (i.e., unique identifier of a service specific document) is also responsible for defining the content and encoding of the CC-Correlation-Id AVP.
CC相関関係イドAVP(AVP Code411)は異なったサービスのコンポーネントのために発生する相関物金融調整要求に、タイプOctetStringにはあって、情報を含んでいます。 例えば、レベルを輸送して、修理してください。 また、Service文脈イド(すなわち、サービスの特定のドキュメントのユニークな識別子)を割り当てる人もCC相関関係イドAVPの内容を定義して、コード化に原因となります。
8.2. CC-Request-Number AVP
8.2. CCリクエスト番号AVP
The CC-Request-Number AVP (AVP Code 415) is of type Unsigned32 and identifies this request within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and CC-Request-Number AVPs is also globally unique and can be used in matching credit- control messages with confirmations. An easy way to produce unique numbers is to set the value to 0 for a credit-control request of type INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the first UPDATE_REQUEST, to 2 for the second, and so on until the value for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST.
CC要求番号AVP(AVP Code415)はタイプUnsigned32にはあって、1つのセッション以内にこの要求を特定します。 Session-イドAVPsがグローバルにユニークであるので、Session-イドとCC要求番号AVPsの組み合わせは、また、グローバルにユニークであり、合っているクレジットコントロールメッセージで確認で使用できます。 ユニークな数を生産する簡単な方法は、タイプINITIAL_REQUESTとEVENT_REQUESTの金融調整要求のために0に値を設定して、2番目のために最初のUPDATE_REQUESTのための1、2に値を設定して、TERMINATION_REQUESTのための値が最後のUPDATE_REQUESTよりさらに1になるまでなどに設定することです。
8.3. CC-Request-Type AVP
8.3. ccがタイプを要求しているAVP
The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and contains the reason for sending the credit-control request message. It MUST be present in all Credit-Control-Request messages. The following values are defined for the CC-Request-Type AVP:
CC要求タイプAVP(AVP Code416)はタイプEnumeratedにはあって、金融調整要求メッセージを送る理由を含んでいます。 それはすべてのCreditコントロール要求メッセージに存在していなければなりません。 以下の値はCC要求タイプAVPのために定義されます:
INITIAL_REQUEST 1
An Initial request is used to initiate a credit-control session,
and contains credit control information that is relevant to the
initiation.
REQUEST1An Initialが要求するINITIAL_は金融調整セッションを開始するのに使用されて、開始に関連しているクレジット制御情報を含んでいます。
UPDATE_REQUEST 2
An Update request contains credit-control information for an
existing credit-control session. Update credit-control requests
SHOULD be sent every time a credit-control re-authorization is
needed at the expiry of the allocated quota or validity time.
Further, additional service-specific events MAY trigger a
spontaneous Update request.
REQUEST2An Updateが要求するUPDATE_は既存の金融調整セッションのための金融調整情報を含んでいます。 アップデート金融調整は、金融調整再認可が割り当てられた割当てか正当性現代の満期に必要であるときはいつも、SHOULDが送られるよう要求します。 さらに、追加サービス特有の出来事は自然発生的なUpdate要求の引き金となるかもしれません。
TERMINATION_REQUEST 3
A Termination request is sent to terminate a credit-control
session and contains credit-control information relevant to the
existing session.
REQUEST3A Terminationが要求するTERMINATION_は金融調整セッションを終えるために送られて、既存のセッションに関連している金融調整情報を含んでいます。
Hakala, et al. Standards Track [Page 58] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[58ページ]。
EVENT_REQUEST 4
An Event request is used when there is no need to maintain any
credit-control session state in the credit-control server. This
request contains all information relevant to the service, and is
the only request of the service. The reason for the Event request
is further detailed in the Requested-Action AVP. The Requested-
Action AVP MUST be included in the Credit-Control-Request message
when CC-Request-Type is set to EVENT_REQUEST.
金融調整サーバでどんな金融調整セッション状態も維持する必要は全くないとき、REQUEST4An Eventが要求するEVENT_が使用されています。この要求は、サービスに関連しているすべての情報を含んでいて、唯一のサービスの要求です。 Event要求の理由はRequested-動作AVPでさらに詳細です。 Requested動作AVP MUST、CC要求タイプがEVENT_REQUESTに用意ができていたらCreditコントロール要求メッセージで含められてください。
8.4. CC-Session-Failover AVP
8.4. CCセッションフェイルオーバーAVP
The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and contains information as to whether moving the credit-control message stream to a backup server during an ongoing credit-control session is supported. In communication failures, the credit-control message streams can be moved to an alternative destination if the credit- control server supports failover to an alternative server. The secondary credit-control server name, if received from the home Diameter AAA server, can be used as an address of the backup server. An implementation is not required to support moving a credit-control message stream to an alternative server, as this also requires moving information related to the credit-control session to backup server.
進行中の金融調整セッションの間、金融調整メッセージストリームをバックアップサーバに動かすか否かに関係なく、AVP(AVP Code418)がEnumeratedのタイプであり、情報を含むCCセッションフェイルオーバーは支持されます。 通信障害では、クレジット制御サーバが代替のサーバにフェイルオーバーを支持するなら、金融調整メッセージ小川を代替の目的地に動かすことができます。二次はサーバー名をクレジットで制御します; 家のDiameter AAAサーバから受け取るなら、バックアップサーバのアドレスとして使用できます。実現は金融調整メッセージストリームを代替のサーバに動かすのを支持するのに必要ではありません、また、これがサーバのバックアップをとるために金融調整セッションに関連する感動的な情報を必要とするとき。
The following values are defined for the CC-Session-Failover AVP:
以下の値はCCセッションフェイルオーバーAVPのために定義されます:
FAILOVER_NOT_SUPPORTED 0
When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED,
the credit-control message stream MUST NOT to be moved to an
alternative destination in the case of communication failure.
_SUPPORTED0When CCセッションフェイルオーバーAVPではなく、FAILOVER_がSUPPORTED、金融調整メッセージストリームがそうしてはいけない_ではなく、通信障害の場合における代替の目的地に動かされるべきFAILOVER_に用意ができています。
This is the default behavior if the AVP isn't included in the
reply from the authorization or credit-control server.
AVPが回答に認可か金融調整サーバから含まれていないなら、これはデフォルトの振舞いです。
FAILOVER_SUPPORTED 1
When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the
credit-control message stream SHOULD be moved to an alternative
destination in the case of communication failure. Moving the
credit-control message stream to a backup server MAY require that
information related to the credit-control session should also be
forwarded to alternative server.
FAILOVER_SUPPORTED1When CCセッションフェイルオーバーAVPはFAILOVER_SUPPORTEDに用意ができています、金融調整メッセージ流れのSHOULD。通信障害の場合における代替手段の目的地に動かされてください。 金融調整メッセージストリームをバックアップサーバに動かすのは、また、金融調整セッションに関連する情報が代替のサーバに転送されるべきであるのを必要とするかもしれません。
8.5. CC-Sub-Session-Id AVP
8.5. CCのサブセッションのイドAVP
The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and contains the credit-control sub-session identifier. The combination of the Session-Id and this AVP MUST be unique per sub-session, and
CCのサブSessionのイドAVP(AVP Code419)はタイプUnsigned64にはあって、金融調整サブセッション識別子を含んでいます。 そして組み合わせ、Session-イドとこのAVP MUSTでは、サブセッション単位でユニークであってください。
Hakala, et al. Standards Track [Page 59] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[59ページ]。
the value of this AVP MUST be monotonically increased by one for all new sub-sessions. The absence of this AVP implies that no sub- sessions are in use.
1つ増加して、このAVP MUSTの値は単調にそうです。すべての新しいサブセッションのために。 このAVPの不在は、どんなサブセッションも使用中でないことを含意します。
8.6. Check-Balance-Result AVP
8.6. チェックバランス結果AVP
The Check Balance Result AVP (AVP Code 422) is of type Enumerated and contains the result of the balance check. This AVP is applicable only when the Requested-Action AVP indicates CHECK_BALANCE in the Credit-Control-Request command.
Check Balance Result AVP(AVP Code422)はタイプEnumeratedにはあって、バランスチェックの結果を含んでいます。 Requested-動作AVPがCreditコントロール要求命令でCHECK_BALANCEを示すときだけ、このAVPは適切です。
The following values are defined for the Check-Balance-Result AVP.
以下の値はCheckバランス結果AVPのために定義されます。
ENOUGH_CREDIT 0
There is enough credit in the account to cover the requested
service.
ENOUGH_CREDIT0Thereはアカウントで要求されたサービスをカバーできるくらいのクレジットです。
NO_CREDIT 1
There isn't enough credit in the account to cover the requested
service.
いいえ_CREDIT1Thereはアカウントで要求されたサービスをカバーできるくらいのクレジットではありません。
8.7. Cost-Information AVP
8.7. コスト情報AVP
The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is used to return the cost information of a service, which the credit- control client can transfer transparently to the end user. The included Unit-Value AVP contains the cost estimate (always type of money) of the service, in the case of price enquiry, or the accumulated cost estimation, in the case of credit-control session.
タイプGroupedにはCost-情報AVP(AVP Code423)があります、そして、それは、クレジットコントロールクライアントが透明にエンドユーザに移すことができるサービスのコスト情報を返すのに使用されます。 含まれているUnit-値のAVPはサービスの費用見積り(いつもお金のタイプ)を含んでいます、価格調査の場合、または蓄積された費用見積りで、金融調整セッションの場合で。
The Currency-Code specifies in which currency the cost was given. The Cost-Unit specifies the unit when the service cost is a cost per unit (e.g., cost for the service is $1 per minute).
Currency-コードは、費用がどの通貨で与えられたかを指定します。 ユニット(例えば、サービスのための費用は1分あたり1ドルである)あたり勤務評価額が1つの費用であるときに、Cost-ユニットはユニットを指定します。
When the Requested-Action AVP with value PRICE_ENQUIRY is included in the Credit-Control-Request command, the Cost-Information AVP sent in the succeeding Credit-Control-Answer command contains the cost estimation of the requested service, without any reservation being made.
値のPRICE_ENQUIRYとRequested-動作AVPがCreditコントロール要求命令に含まれているとき、AVPがされる少しも予約なしでコマンドが含む続くCreditコントロール答えで要求されたサービスに関する費用見積りを送ったCost-情報です。
The Cost-Information AVP included in the Credit-Control-Answer command with the CC-Request-Type set to UPDATE_REQUEST contains the accumulated cost estimation for the session, without taking any credit reservation into account.
CC要求タイプセットによるCreditコントロール答え命令でUPDATE_REQUESTにAVPを含めるCost-情報はセッションのために蓄積された費用見積りを含んでいます、どんなクレジットの予約も考慮に入れないで。
Hakala, et al. Standards Track [Page 60] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[60ページ]。
The Cost-Information AVP included in the Credit-Control-Answer command with the CC-Request-Type set to EVENT_REQUEST or TERMINATION_REQUEST contains the estimated total cost for the requested service.
CC要求タイプセットによるCreditコントロール答え命令でEVENT_REQUESTかTERMINATION_REQUESTにAVPを含めるCost-情報は要求されたサービスのためのおよそ総費用を含んでいます。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
それが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
Cost-Information ::= < AVP Header: 423 >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]
コスト情報:、:= <AVPヘッダー: 423 >単価通貨コード[費用単位]
8.8. Unit-Value AVP
8.8. 単価AVP
Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the units as decimal value. The Unit-Value is a value with an exponent; i.e., Unit-Value = Value-Digits AVP * 10^Exponent. This representation avoids unwanted rounding off. For example, the value of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The absence of the exponent part MUST be interpreted as an exponent equal to zero.
ユニット価値のAVPはタイプGrouped(AVP Code445)にはあって、デシマル値としてユニットを指定します。 Unit-値は解説者がある値です。 すなわち、Unit-値は値ケタAVP*10^Exponentと等しいです。 この表現は下に求められていない一周を避けます。 例えば、Value-ケタが23とExponent=-1と等しいときに、2、3の値は表されます。 ゼロに合わせるために等しい解説者として指数部の欠如を解釈しなければなりません。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
それが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
Unit-Value ::= < AVP Header: 445 >
{ Value-Digits }
[ Exponent ]
以下をユニット評価してください:= <AVPヘッダー: 445 >値ケタ[解説者]
8.9. Exponent AVP
8.9. 解説者AVP
Exponent AVP is of type Integer32 (AVP Code 429) and contains the exponent value to be applied for the Value-Digit AVP within the Unit-Value AVP.
解説者AVPはUnit-値のAVPの中にタイプInteger32(AVP Code429)にはあって、Value-ケタAVPのために適用されるべき解説者値を含んでいます。
8.10. Value-Digits AVP
8.10. 値ケタAVP
The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains the significant digits of the number. If decimal values are needed to present the units, the scaling MUST be indicated with the related Exponent AVP. For example, for the monetary amount $ 0.05 the value of Value-Digits AVP MUST be set to 5, and the scaling MUST be indicated with the Exponent AVP set to -2.
Value-ケタAVPはタイプInteger64(AVP Code447)にはあって、数の有効数字を含んでいます。 デシマル値がユニットを提示するのに必要であるなら、関連するExponent AVPと共にスケーリングを示さなければなりません。 例えば、通貨に関して、0.05ドル達してください、値、Value-ケタAVP MUSTでは、5に設定されてください。そうすれば、Exponent AVPセットでスケーリングを-2まで示さなければなりません。
Hakala, et al. Standards Track [Page 61] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[61ページ]。
8.11. Currency-Code AVP
8.11. 通貨コードAVP
The Currency-Code AVP (AVP Code 425) is of type Unsigned32 and contains a currency code that specifies in which currency the values of AVPs containing monetary units were given. It is specified by using the numeric values defined in the ISO 4217 standard [ISO4217].
Currency-コードAVP(AVP Code425)はタイプUnsigned32にはあって、通貨のユニットを含むAVPsの値がどの通貨で与えられたかを指定する通貨コードを含んでいます。 それは、ISO4217規格[ISO4217]で定義された数値を使用することによって、指定されます。
8.12. Cost-Unit AVP
8.12. 費用単位AVP
The Cost-Unit AVP (AVP Code 424) is of type UTF8String, and it is used to display a human readable string to the end user. It specifies the applicable unit to the Cost-Information when the service cost is a cost per unit (e.g., cost of the service is $1 per minute). The Cost-Unit can be minutes, hours, days, kilobytes, megabytes, etc.
タイプUTF8StringにはCost-ユニットAVP(AVP Code424)があります、そして、それは、人間の読み込み可能なストリングをエンドユーザに表示するのに使用されます。 ユニット(例えば、サービスの費用は1分あたり1ドルである)あたり勤務評価額が1つの費用であるときに、それはCost-情報に適切なユニットを指定します。 Cost-ユニットは数分、何時間もの、何日もの、キロバイト、メガバイトであるかもしれませんなど。
8.13. Credit-Control AVP
8.13. 金融調整AVP
The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST be included in AA requests when the service element has credit- control capabilities.
サービス要素にクレジットコントロール能力があると、Credit-コントロールAVP(AVP Code426)はタイプEnumeratedにはあって、AA要求で含めなければなりません。
CREDIT_AUTHORIZATION 0
If the home Diameter AAA server determines that the user has
prepaid subscription, this value indicates that the credit-control
server MUST be contacted to perform the first interrogation. The
value of the Credit-Control AVP MUST always be set to 0 in an AA
request sent to perform the first interrogation and to initiate a
new credit-control session.
AAAサーバが決定するこれが、ユーザが、実行するために前払いの購読を持って、金融調整サーバに連絡しなければならないのを示すのを評価するCREDIT_AUTHORIZATION0If家のDiameter、最初の査問。 値、Credit制御しているAVP MUSTでは、最初の査問を実行して、新しい金融調整セッションを開始するために送られたAA要求における0にいつも設定されてください。
RE_AUTHORIZATION 1
This value indicates to the Diameter AAA server that a credit-
control session is ongoing for the subscriber and that the
credit-control server MUST not be contacted. The Credit-Control
AVP set to the value of 1 is to be used only when the first
interrogation has been successfully performed and the credit-
control session is ongoing (i.e., re-authorization triggered by
Authorization-Lifetime). This value MUST NOT be used in an AA
request sent to perform the first interrogation.
RE_AUTHORIZATION1This価値は、加入者にとって、クレジットコントロールセッションが進行中であり、金融調整サーバが連絡されてはいけないのをDiameter AAAサーバに示します。 AVPが1の値に設定するCredit-コントロールが最初の査問が首尾よく実行されたときだけ、使用されていることであり、クレジットコントロールセッションは進行中です(すなわち、Authorization-生涯までに引き起こされた再認可)。 最初の査問を実行するために送られたAA要求でこの値を使用してはいけません。
8.14. Credit-Control-Failure-Handling AVP
8.14. クレジットコントロール失敗取り扱いAVP
The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type Enumerated. The credit-control client uses information in this AVP to decide what to do if sending credit-control messages to the credit-control server has been, for instance, temporarily prevented due to a network problem. Depending on the service logic, the credit-control server can order the client to terminate the service
タイプEnumeratedにはCreditコントロール失敗取り扱いAVP(AVP Code427)があります。 例えば、ネットワーク問題のため一時金融調整メッセージを金融調整サーバに送るのを防いであるなら、金融調整クライアントは、何をしたらよいかを決めるのにこのAVPの情報を使用します。 サービス論理によって、金融調整サーバは、サービスを終えるようクライアントに命令することができます。
Hakala, et al. Standards Track [Page 62] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[62ページ]。
immediately when there is a reason to believe that the service cannot be charged, or to try failover to an alternative server, if possible. Then the server could either terminate or grant the service, should the alternative connection also fail.
できれば、すぐに、いつに、サービスを請求できないと信じているか、または代替のサーバにフェイルオーバーを試みる理由がありますか? そして、また、代表結合が失敗するなら、サーバは、サービスを終えるか、または承諾するかもしれません。
TERMINATE 0
When the Credit-Control-Failure-Handling AVP is set to TERMINATE,
the service MUST only be granted for as long as there is a
connection to the credit-control server. If the credit-control
client does not receive any Credit-Control-Answer message within
the Tx timer (as defined in section 13), the credit-control
request is regarded as failed, and the end user's service session
is terminated.
金融調整サーバとの接続があるとき、同じくらい長い間、TERMINATE0When Creditコントロール失敗取り扱いAVPがTERMINATEに用意ができているとサービスを承諾するだけでよいです。金融調整クライアントがTxタイマの中にどんなCreditコントロール答えメッセージも受け取らないなら(セクション13で定義されるように)、金融調整要求は失敗されると見なされます、そして、エンドユーザのサービスセッションは終えられます。
This is the default behavior if the AVP isn't included in the
reply from the authorization or credit-control server.
AVPが回答に認可か金融調整サーバから含まれていないなら、これはデフォルトの振舞いです。
CONTINUE 1
When the Credit-Control-Failure-Handling AVP is set to CONTINUE,
the credit-control client SHOULD re-send the request to an
alternative server in the case of transport or temporary failures,
provided that a failover procedure is supported in the credit-
control server and the credit-control client, and that an
alternative server is available. Otherwise, the service SHOULD be
granted, even if credit-control messages can't be delivered.
CONTINUE1When Creditコントロール失敗取り扱いAVPはCONTINUEに用意ができています、そして、フェイルオーバー手順がクレジット制御サーバと金融調整クライアントで支持されれば、金融調整クライアントSHOULDは輸送か一時障害の場合における代替のサーバに要求を再送します、そして、代替のサーバは利用可能です。 金融調整メッセージがそうすることができないでも、さもなければ、サービスSHOULDを与えて、渡してください。
RETRY_AND_TERMINATE 2
When the Credit-Control-Failure-Handling AVP is set to
RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the
request to an alternative server in the case of transport or
temporary failures, provided that a failover procedure is
supported in the credit-control server and the credit-control
client, and that an alternative server is available. Otherwise,
the service SHOULD not be granted when the credit-control messages
can't be delivered.
RETRY_と_TERMINATE2When Creditコントロール失敗取り扱いAVPはRETRY_AND_TERMINATEに用意ができています、そして、フェイルオーバー手順が金融調整サーバと金融調整クライアントで支持されれば、金融調整クライアントSHOULDは輸送か一時障害の場合における代替のサーバに要求を再送します、そして、代替のサーバは利用可能です。 SHOULDを調整してください。そうでなければ、金融調整メッセージを送ることができないとき、与えられないでください。
8.15. Direct-Debiting-Failure-Handling AVP
8.15. ダイレクト借り方の失敗取り扱いAVP
The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type Enumerated. The credit-control client uses information in this AVP to decide what to do if sending credit-control messages (Requested- Action AVP set to DIRECT_DEBITING) to the credit-control server has been, for instance, temporarily prevented due to a network problem.
タイプEnumeratedには失敗取り扱いを借り方に記入するDirect AVP(AVP Code428)があります。 例えば、ネットワーク問題のため一時金融調整メッセージ(動作AVPがDIRECT_DEBITINGにセットしたよう要求する)を金融調整サーバに送るのを防いであるなら、金融調整クライアントは、何をしたらよいかを決めるのにこのAVPの情報を使用します。
TERMINATE_OR_BUFFER 0
When the Direct-Debiting-Failure-Handling AVP is set to
TERMINATE_OR_BUFFER, the service MUST be granted for as long as
there is a connection to the credit-control server. If the
金融調整サーバとの接続があるとき、同じくらい長い間、TERMINATE_OR_BUFFER0When失敗取り扱いを借り方に記入するDirect AVPが_TERMINATE_OR BUFFERに用意ができているとサービスを承諾しなければなりません。
Hakala, et al. Standards Track [Page 63] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[63ページ]。
credit-control client does not receive any Credit-Control-Answer
message within the Tx timer (as defined in section 13) the
credit-control request is regarded as failed. The client SHOULD
terminate the service if it can determine from the failed answer
that units have not been debited. Otherwise the credit-control
client SHOULD grant the service, store the request in application
level non-volatile storage, and try to re-send the request. These
requests MUST be marked as possible duplicates by setting the T-
flag in the command header as described in [DIAMBASE] section 3.
金融調整クライアントは失敗されて、金融調整要求が見なされるTxタイマ(セクション13で定義されるように)中にどんなCreditコントロール答えメッセージも受け取りません。 失敗した答えからユニットが借り方に記入されていないことを決定できるなら、クライアントSHOULDはサービスを終えます。 さもなければ、金融調整クライアントSHOULDはサービスを承諾して、アプリケーションレベル非揮発性記憶装置による要求を格納して、要求を再送しようとします。 コマンドヘッダーにT旗をはめ込むのによる[DIAMBASE]セクション3で説明されるのと同じくらい可能な写しであるとこれらの要求をマークしなければなりません。
This is the default behavior if the AVP isn't included in the
reply from the authorization server.
AVPが回答に認可サーバから含まれていないなら、これはデフォルトの振舞いです。
CONTINUE 1
When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE,
the service SHOULD be granted, even if credit-control messages
can't be delivered, and the request should be deleted.
サービスSHOULDを与えて、金融調整メッセージがそうすることができないでも提供されて、CONTINUE1When失敗取り扱いを借り方に記入するDirect AVPはCONTINUEに用意ができています、そして、要求は削除されるべきです。
8.16. Multiple-Services-Credit-Control AVP
8.16. 複数のサービス金融調整AVP
Multiple-Services-Credit-Control AVP (AVP Code 456) is of type Grouped and contains the AVPs related to the independent credit- control of multiple services feature. Note that each instance of this AVP carries units related to one or more services or related to a single rating group.
複数のサービスクレジットが制御されたAVP(AVP Code456)はタイプGroupedにはあって、複数のサービス機能の独立しているクレジットコントロールに関連するAVPsを含んでいます。 このAVPの各例が1つ以上のサービスに関連されるか、またはただ一つの格付けのグループに関連するユニットを運ぶことに注意してください。
The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group. If both the Service-Identifier and the Rating-Group AVPs are included, the target of the service units is always the service(s) indicated by the value of the Service-Identifier AVP(s). If only the Rating- Group-Id AVP is present, the Multiple-Services-Credit-Control AVP relates to all the services that belong to the specified rating group.
Service-識別子とRating-グループAVPsは与えられたサービスか格付けへの与えられたユニットが分類する仲間に使用されます。 Service-識別子とRating-グループAVPsの両方が含まれているなら、いつもサービスユニットの目標はService-識別子AVP(s)の値によって示されたサービスです。 RatingグループイドAVPだけが存在しているなら、Multipleサービスクレジットが制御されたAVPは指定された格付けのグループに属すすべてのサービスに関連します。
The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U- Pool-Identifier identifying a credit pool within which the units of the specified type are considered pooled. If a G-S-U-Pool-Reference AVP is present, then actual service units of the specified type MUST also be present. For example, if the G-S-U-Pool-Reference AVP specifies Unit-Type TIME, then the CC-Time AVP MUST be present.
G-S-Uプール参照AVPは、サーバに指定されたタイプの単位がプールされていると考えられるクレジットプールを特定しながら、G-S-Uプール識別子を指定させます。 また、G-S-Uプール参照AVPが存在しているなら、指定されたタイプの就航単位も存在していなければなりません。 例えば、AVPはG-S-Uプール参照であるならUnit-タイプタイム誌を指定して、次に、CC時間はAVP MUSTです。存在してください。
The Requested-Service-Unit AVP MAY contain the amount of requested service units or the requested monetary value. It MUST be present in the initial interrogation and within the intermediate interrogations in which new quota is requested. If the credit-control client does not include the Requested-Service-Unit AVP in a request command, because for instance, it has determined that the end-user terminated
RequestedサービスユニットAVP MAYは要求されたサービスユニットか要求された金銭価値の量を含んでいます。 それは中間的査問に初期の査問と、そして、新しい割当てが要求されている以内存在していなければなりません。 金融調整クライアントがそうしないなら、要求コマンドでRequestedサービスユニットAVPを含めてください、例えば、エンドユーザが終わったことを決定したので
Hakala, et al. Standards Track [Page 64] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[64ページ]。
the service, the server MUST debit the used amount from the user's account but MUST NOT return a new quota in the corresponding answer. The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY be present in an answer command as defined in sections 5.1.2 and 5.6 for the graceful service termination.
サービス、サーバはユーザのアカウントから中古の量を借り方に記入しなければなりませんが、対応する答えで新しい割当てを返してはいけません。 Validity-時間、Result-コード、およびFinalユニット指示AVPsはセクション5.1 優雅なサービス終了のための.2と5.6で定義されるように答え命令で存在しているかもしれません。
When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate instances of the Multiple-Services-Credit-Control AVP with the Granted-Service-Unit AVP associated to the same service-identifier and/or rating-group. Where the two quotas are associated to the same pool or to different pools, the credit pooling mechanism defined in section 5.1.2 applies. The Tariff-Change-Usage AVP MUST NOT be included in request commands to report used units before, and after tariff time change the Used- Service-Unit AVP MUST be used.
Tariff時間変化とTariff変化用法AVPsの両方が存在しているとき、サーバは同じサービス識別子、そして/または、格付けグループへのGrantedサービスユニットAVPが関連しているMultipleサービスクレジットが制御されたAVPの2つの別々の例を含まなければなりません。 2つの割当てが同じプールに関連づけられるところ、または、異なったプールに、セクション5.1.2で定義されたクレジット合同メカニズムは適用されます。 Tariff変化用法AVP MUST NOT、含まれていて、ユニット時の前と関税時の後に使用されていると報告するコマンドがUsedサービスユニットAVP MUSTを変えるという要求では、使用されてください。
A server not implementing the independent credit-control of multiple services functionality MUST treat the Multiple-Services-Credit- Control AVP as an invalid AVP.
複数のサービスの機能性の独立している金融調整を実行しないサーバは無効のAVPとしてMultiple-サービスクレジットコントロールAVPを扱わなければなりません。
The Multiple-Services-Control AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
MultipleサービスコントロールAVPが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
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 ]
複数のサービス金融調整:、:= <AVPヘッダー: 456 >[与えられたサービスユニット][要求されたサービスユニット]*[中古のサービス単位][関税変化用法]*[サービス識別子][格付けグループ]*[G-S-Uプール参照][正当性時間][結果コード][最終的なユニット指示]*[AVP]
8.17. Granted-Service-Unit AVP
8.17. 与えられたサービスユニットAVP
Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and contains the amount of units that the Diameter credit-control client can provide to the end user until the service must be released or the new Credit-Control-Request must be sent. A client is not required to implement all the unit types, and it must treat unknown or unsupported unit types in the answer message as an incorrect CCA answer. In this case, the client MUST terminate the credit-control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.
与えられたサービスユニットAVP(AVP Code431)はタイプGroupedにはあって、サービスをリリースしなければならないか、または新しいCreditコントロール要求を送らなければならないまでDiameter金融調整クライアントがエンドユーザに提供できるユニットの量を含んでいます。 クライアントはすべてのユニット型を実装するのに必要ではありません、そして、それは不正確なCCA答えとして答えメッセージで未知の、または、サポートされないユニット型を扱わなければなりません。 この場合、クライアントは、金融調整セッションを終えて、Termination-原因AVP理由DIAMETERで_BAD_ANSWERを示さなければなりません。
Hakala, et al. Standards Track [Page 65] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[65ページ]。
The Granted-Service-Unit AVP is defined as follows (per the grouped- avp-def of RFC 3588 [DIAMBASE]):
GrantedサービスユニットAVPは以下の通り(avp RFC3588[DIAMBASE]がクールな分類単位で)定義されます:
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 ]
与えられたサービスユニット:、:= <AVPヘッダー: 431 >[関税時刻変更][CC時間][CCお金][CCの総八重奏][CC入力八重奏][CC出力八重奏][CCのサービスの特定のユニット]*[AVP]
8.18. Requested-Service-Unit AVP
8.18. 要求されたサービスユニットAVP
The Requested-Service-Unit AVP (AVP Code 437) is of type Grouped and contains the amount of requested units specified by the Diameter credit-control client. A server is not required to implement all the unit types, and it must treat unknown or unsupported unit types as invalid AVPs.
RequestedサービスユニットAVP(AVP Code437)はタイプGroupedにはあって、Diameter金融調整クライアントによって指定された要求されたユニットの量を含んでいます。 サーバはすべてのユニット型を実装するのに必要ではありません、そして、それは未知の、または、サポートされないユニット型を無効のAVPsとして扱わなければなりません。
The Requested-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
RequestedサービスユニットAVPが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
Requested-Service-Unit ::= < AVP Header: 437 >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
要求されたサービスユニット:、:= <AVPヘッダー: 437 >[CC時間][CCお金][CCの総八重奏][CC入力八重奏][CC出力八重奏][CCのサービスの特定のユニット]*[AVP]
8.19. Used-Service-Unit AVP
8.19. 中古のサービス単位AVP
The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and contains the amount of used units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended.
サービスがアクティブになったとき、AVPがタイプGrouped(AVP Code446)にはあって、量を含むUsedサービスユニットがポイントから測定されたユニットを使用したか、または当座の査問がセッションの間、使用されるなら、前であることのポイントから、測定は終わりました。
Hakala, et al. Standards Track [Page 66] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[66ページ]。
The Used-Service-Unit AVP is defined as follows (per the grouped- avp-def of RFC 3588 [DIAMBASE]):
UsedサービスユニットAVPは以下の通り(avp RFC3588[DIAMBASE]がクールな分類単位で)定義されます:
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 ]
中古のサービス単位:、:= <AVPヘッダー: 446 >[関税変化用法][CC時間][CCお金][CCの総八重奏][CC入力八重奏][CC出力八重奏][CCのサービスの特定のユニット]*[AVP]
8.20. Tariff-Time-Change AVP
8.20. 関税時刻変更AVP
The Tariff-Time-Change AVP (AVP Code 451) is of type Time. It is sent from the server to the client and includes the time in seconds since January 1, 1900, 00:00 UTC, when the tariff of the service will be changed.
タイプTimeにはTariff時間変化AVP(AVP Code451)があります。 それは、サーバからクライアントに送られて、1900年1月1日以来の秒に時間を含めます、協定世界時0時0分、サービスの関税を変えるとき。
The tariff change mechanism is optional for the client and server, and it is not used for time-based services defined in section 5. If a client does not support the tariff time change mechanism, it MUST treat Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In this case, the client terminates the credit-control session and indicates in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.
クライアントとサーバに、関税変化メカニズムは任意です、そして、それはセクション5で定義された時間ベースのサービスに使用されません。 クライアントが関税時刻変更メカニズムをサポートしないなら、それは不正確なCCA答えとして答えメッセージでTariff時間変化AVPを扱わなければなりません。 この場合、クライアントは、金融調整セッションを終えて、Termination-原因AVP理由DIAMETERで_BAD_ANSWERを示します。
Omission of this AVP means that no tariff change is to be reported.
このAVPの省略は、関税変化を全く報告してはいけないことを意味します。
8.21. CC-Time AVP
8.21. CC時間AVP
The CC-Time AVP (AVP Code 420) is of type Unsigned32 and indicates the length of the requested, granted, or used time in seconds.
CC時間AVP(AVP Code420)はタイプUnsigned32にはあって、秒に要求されたか、与えられたか、中古の時間の長さを示します。
8.22. CC-Money AVP
8.22. CCお金のAVP
The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the monetary amount in the given currency. The Currency-Code AVP SHOULD be included. It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
CCお金のAVP(AVP Code413)はタイプGroupedにはあって、与えられた通貨で通貨の量を指定します。 含まれていて、AVP SHOULDをCurrencyコード化してください。 それが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
CC-Money ::= < AVP Header: 413 >
{ Unit-Value }
[ Currency-Code ]
CCお金:、:= <AVPヘッダー: 413 >単価[通貨コード]
Hakala, et al. Standards Track [Page 67] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[67ページ]。
8.23. CC-Total-Octets AVP
8.23. CCの総八重奏AVP
The CC-Total-Octets AVP (AVP Code 421) is of type Unsigned64 and contains the total number of requested, granted, or used octets regardless of the direction (sent or received).
CCの総八重奏AVP(AVP Code421)はタイプUnsigned64にはあって、方向(送るか、または受け取る)にかかわらず要求されたか、与えられたか、中古の八重奏の総数を含んでいます。
8.24. CC-Input-Octets AVP
8.24. CC入力八重奏AVP
The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and contains the number of requested, granted, or used octets that can be/have been received from the end user.
CC入力八重奏AVP(AVP Code412)がタイプUnsigned64にはあって、与えられた要求されることの数を含んでいるか、またはエンドユーザから/であることができる中古の八重奏を受けました。
8.25. CC-Output-Octets AVP
8.25. CC出力八重奏AVP
The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and contains the number of requested, granted, or used octets that can be/have been sent to the end user.
CC出力八重奏AVP(AVP Code414)がタイプUnsigned64にはあって、与えられた要求されることの数を含んでいるか、または/であることができる中古の八重奏をエンドユーザに送りました。
8.26. CC-Service-Specific-Units AVP
8.26. CCのサービスの特定のユニットAVP
The CC-Service-Specific-Units AVP (AVP Code 417) is of type Unsigned64 and specifies the number of service-specific units (e.g., number of events, points) given in a selected service. The service- specific units always refer to the service identified in the Service-Identifier AVP (or Rating-Group AVP when the Multiple- Services-Credit-Control AVP is used).
CCのサービスの特定のユニットAVP(AVP Code417)はタイプUnsigned64にはあって、選択されたサービスで与えられたサービス特有のユニット(例えば、イベントの数、ポイント)の数を指定します。 サービスの特定のユニットはいつもService-識別子AVPで特定されたサービスについて言及します(サービスクレジットが制御されたMultiple AVPであるときに、Rating-グループAVPは使用されています)。
8.27. Tariff-Change-Usage AVP
8.27. 関税変化用法AVP
The Tariff-Change-Usage AVP (AVP Code 452) is of type Enumerated and defines whether units are used before or after a tariff change, or whether the units straddled a tariff change during the reporting period. Omission of this AVP means that no tariff change has occurred.
Tariff変化用法AVP(AVP Code452)は、タイプEnumeratedにはあって、報告の期間、ユニットが関税変化の前または後に使用されたかどうか、またはユニットが関税変化にまたがったかどうかを定義します。 このAVPの省略は、関税変化が全く起こっていないことを意味します。
In addition, when present in answer messages as part of the Multiple-Services-Credit-Control AVP, this AVP defines whether units are allocated to be used before or after a tariff change event.
Multipleサービスクレジットが制御されたAVPの一部として答えメッセージに存在しているとき、さらに、このAVPは、ユニットが関税変化イベントの前または後に使用されるために割り当てられるかどうかを定義します。
When the Tariff-Time-Change AVP is present, omission of this AVP in answer messages means that the single quota mechanism applies.
Tariff時間変化AVPが存在しているとき、答えメッセージにおける、このAVPの省略は、ただ一つの割当てメカニズムが適用されることを意味します。
Tariff-Change-Usage can be one of the following:
関税変化用法は以下の1つであるかもしれません:
UNIT_BEFORE_TARIFF_CHANGE 0
When present in the Multiple-Services-Credit-Control AVP, this
value indicates the amount of the units allocated for use before a
tariff change occurs.
TARIFF_CHANGE0WhenがMultipleサービスクレジットが制御されたAVPで寄贈するUNIT_BEFORE_、この値は関税変化が起こる前に使用のために割り当てられたユニットの量を示します。
Hakala, et al. Standards Track [Page 68] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[68ページ]。
When present in the Used-Service-Unit AVP, this value indicates
the amount of resource units used before a tariff change had
occurred.
UsedサービスユニットAVPに存在しているとき、この値は関税変化が起こる前に使用されるリソースユニットの量を示します。
UNIT_AFTER_TARIFF_CHANGE 1
When present in the Multiple-Services-Credit-Control AVP, this
value indicates the amount of the units allocated for use after a
tariff change occurs.
TARIFF_CHANGE1WhenがMultipleサービスクレジットが制御されたAVPで寄贈するUNIT_AFTER_、この値は関税変化が起こった後に使用のために割り当てられたユニットの量を示します。
When present in the Used-Service-Unit AVP, this value indicates
the amount of resource units used after tariff change had
occurred.
UsedサービスユニットAVPに存在しているとき、この値は関税変化が起こった後に使用されるリソースユニットの量を示します。
UNIT_INDETERMINATE 2
The used unit contains the amount of units that straddle the
tariff change (e.g., the metering process reports to the credit-
control client in blocks of n octets, and one block straddled the
tariff change). This value is to be used only in the Used-
Service-Unit AVP.
UNIT_INDETERMINATE、2 中古の単位は関税変化にまたがるユニットの量を含んでいます(例えば計量プロセスがブロックのn八重奏でクレジットコントロールクライアントに報告しました、そして、1ブロックが関税変化にまたがりました)。 この値はUsedサービスユニットAVPだけで使用されることです。
8.28. Service-Identifier AVP
8.28. サービス識別子AVP
The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and contains the identifier of a service. The specific service the request relates to is uniquely identified by the combination of Service-Context-Id and Service-Identifier AVPs.
Service-識別子AVPはタイプUnsigned32(AVP Code439)にはあって、サービスの識別子を含んでいます。 要求が関連する特定のサービスはService文脈イドとService-識別子AVPsの組み合わせで唯一特定されます。
A usage example of this AVP is illustrated in Appendix A (Flow IX).
このAVPに関する使用例はAppendix A(流れIX)で例証されます。
8.29. Rating-Group AVP
8.29. 格付けグループAVP
The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and contains the identifier of a rating group. All the services subject to the same rating type are part of the same rating group. The specific rating group the request relates to is uniquely identified by the combination of Service-Context-Id and Rating-Group AVPs.
Rating-グループAVPはタイプUnsigned32(AVP Code432)にはあって、格付けのグループに関する識別子を含んでいます。 同じ格付けのタイプを条件としたすべてのサービスが同じ格付けのグループの一部です。 要求が関連する特定の格付けのグループはService文脈イドとRating-グループAVPsの組み合わせで唯一特定されます。
A usage example of this AVP is illustrated in Appendix A (Flow IX).
このAVPに関する使用例はAppendix A(流れIX)で例証されます。
8.30. G-S-U-Pool-Reference AVP
8.30. G-S-Uプール参照AVP
The G-S-U-Pool-Reference AVP (AVP Code 457) is of type Grouped. It is used in the Credit-Control-Answer message, and associates the Granted-Service-Unit AVP within which it appears with a credit pool within the session.
タイプGroupedにはG-S-Uプール参照AVP(AVP Code457)があります。 それは、Creditコントロール答えメッセージで使用されて、セッション中にクレジットプールと共に現れるGrantedサービスユニットAVPを関連づけます。
The G-S-U-Pool-Identifier AVP specifies the credit pool from which credit is drawn for this unit type.
G-S-Uプール識別子AVPはクレジットがこのユニット型のために引き出されるクレジットプールを指定します。
Hakala, et al. Standards Track [Page 69] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[69ページ]。
The CC-Unit-Type AVP specifies the type of units for which credit is pooled.
CCユニットタイプAVPはクレジットがプールされるユニットのタイプを指定します。
The Unit-Value AVP specifies the multiplier, which converts between service units of type CC-Unit-Type and abstract service units within the credit pool (and thus to service units of any other service or rating group associated with the same pool).
Unit-値のAVPは乗数を指定します。(それは、クレジットプールの中でサービスユニットのタイプCCユニットタイプと抽象的なサービスユニットの間で変換されます(その結果、同じプールに関連しているいかなる他のサービスか格付けのグループの部隊にもサービスを提供するために))。
The G-S-U-Pool-Reference AVP is defined as follows (per the grouped- avp-def of RFC 3588 [DIAMBASE]):
G-S-Uプール参照AVPは以下の通り(avp RFC3588[DIAMBASE]がクールな分類単位で)定義されます:
G-S-U-Pool-Reference ::= < AVP Header: 457 >
{ G-S-U-Pool-Identifier }
{ CC-Unit-Type }
{ Unit-Value }
G-S-Uは参照をプールします:、:= <AVPヘッダー: 457 >G-S-Uプール識別子CCユニット型単価
8.31. G-S-U-Pool-Identifier AVP
8.31. G-S-Uプール識別子AVP
The G-S-U-Pool-Identifier AVP (AVP Code 453) is of type Unsigned32 and identifies a credit pool within the session.
G-S-Uプール識別子AVP(AVP Code453)はタイプUnsigned32にはあって、セッション中にクレジットプールを特定します。
8.32. CC-Unit-Type AVP
8.32. CCユニット型AVP
The CC-Unit-Type AVP (AVP Code 454) is of type Enumerated and specifies the type of units considered to be pooled into a credit pool.
CCユニットタイプAVP(AVP Code454)はタイプEnumeratedにはあって、クレジットプールの中にプールされると考えられたユニットのタイプを指定します。
The following values are defined for the CC-Unit-Type AVP:
以下の値はCCユニットタイプAVPのために定義されます:
TIME 0
MONEY 1
TOTAL-OCTETS 2
INPUT-OCTETS 3
OUTPUT-OCTETS 4
SERVICE-SPECIFIC-UNITS 5
時間0のお金1の総八重奏2入力八重奏3出力八重奏4サービスの特定のユニット5
8.33. Validity-Time AVP
8.33. 正当性時間AVP
The Validity-Time AVP is of type Unsigned32 (AVP Code 448). It is sent from the credit-control server to the credit-control client. The AVP contains the validity time of the granted service units. The measurement of the Validity-Time is started upon receipt of the Credit-Control-Answer Message containing this AVP. If the granted service units have not been consumed within the validity time specified in this AVP, the credit-control client MUST send a Credit- Control-Request message to the server, with CC-Request-Type set to UPDATE_REQUEST. The value field of the Validity-Time AVP is given in seconds.
タイプUnsigned32(AVP Code448)にはValidity-時間AVPがあります。 金融調整サーバから金融調整クライアントにそれを送ります。 AVPは与えられたサービスユニットの正当性時間を含んでいます。 Validity-現代の測定はこのAVPを含むCreditコントロール答えMessageを受け取り次第始められます。 与えられたサービスユニットがこのAVPで指定された正当性時中に消費されていないなら、金融調整クライアントはCreditコントロール要求メッセージをサーバに送らなければなりません、UPDATE_REQUESTに用意ができているCC要求タイプで。秒にValidity-時間AVPの値の野原を与えます。
Hakala, et al. Standards Track [Page 70] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[70ページ]。
The Validity-Time AVP is also used for the graceful service termination (see section 5.6) to indicate to the credit-control client how long the subscriber is allowed to use network resources after the specified action (i.e., REDIRECT or RESTRICT_ACCESS) started. When the Validity-Time elapses, a new intermediate interrogation is sent to the server.
また、指定された動作(すなわち、REDIRECTかRESTRICT_ACCESS)が始まった後に優雅なサービス終了(セクション5.6を見る)が、加入者がどれくらい長い間ネットワーク資源を使用できるかを金融調整クライアントに示すのにValidity-時間AVPは使用されます。 Validity-時間が経過するとき、新しい中間的査問をサーバに送ります。
8.34. Final-Unit-Indication AVP
8.34. 最終的なユニット指示AVP
The Final-Unit-Indication AVP (AVP Code 430) is of type Grouped and indicates that the Granted-Service-Unit AVP in the Credit-Control- Answer, or in the AA answer, contains the final units for the service. After these units have expired, the Diameter credit-control client is responsible for executing the action indicated in the Final-Unit-Action AVP (see section 5.6).
Finalユニット指示AVP(AVP Code430)は、タイプGroupedにはあって、Credit-コントロール答え、またはAA答えにおけるGrantedサービスユニットAVPがサービスのための最終的なユニットを含むのを示します。 これらのユニットが期限が切れた後に、Diameter金融調整クライアントはFinalユニット動作AVPで示された動作を実行するのに責任があります(セクション5.6を見てください)。
If more than one unit type is received in the Credit-Control-Answer, the unit type that first expired SHOULD cause the credit-control client to execute the specified action.
Creditコントロール答えで1人以上のユニット型を受け取るなら、SHOULDが最初に期限が切れたユニット型は金融調整クライアントに指定された動作を実行させます。
In the first interrogation, the Final-Unit-Indication AVP with Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA answer. This indicates to the Diameter credit-control client to execute the specified action immediately. If the home service provider policy is to terminate the service, naturally, the server SHOULD return the appropriate transient failure (see section 9.1) in order to implement the policy-defined action.
また、最初の査問では、Finalユニット動作REDIRECTかRESTRICT_ACCESSとFinalユニット指示AVPもCreditコントロール答えかAA答えにおけるGrantedサービスユニットAVPなしで存在している場合があります。 これは、すぐに指定された動作を実行するためにクライアントをクレジットで監督するようにDiameterに示します。 在宅サービスプロバイダー方針がサービスを終えることであるなら、当然、サーバSHOULDは、方針で定義された動作を実装するために、適切な一時障害(セクション9.1を見る)を返します。
The Final-Unit-Action AVP defines the behavior of the service element when the user's account cannot cover the cost of the service and MUST always be present if the Final-Unit-Indication AVP is included in a command.
Finalユニット指示AVPがコマンドに含まれているなら、ユーザのアカウントがサービスの費用をまかなうことができないで、いつも存在していなければならないとき、Finalユニット動作AVPはサービス要素の動きを定義します。
If the Final-Unit-Action AVP is set to TERMINATE, no other AVPs MUST be present.
Finalユニット動作AVPがTERMINATEに用意ができているなら、他のどんなAVPsも存在しているはずがありません。
If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is also allowed to access other services that are not accessible through the address given in the Redirect-Server AVP.
Finalユニット動作AVPが少なくともREDIRECT Redirect-サーバAVP MUSTへのセットであるなら、存在してください。 Restrictionフィルタ規則AVPかFilter-イドAVP MAY、また、ユーザが他のRedirect-サーバAVPで与えられたアドレスを通ってアクセスしやすくないサービスにアクセスできるなら、Creditコントロール答えメッセージに存在してください。
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
Finalユニット動作AVPがそうなら_ACCESS(Restrictionフィルタ規則AVPかFilter-イドAVP SHOULDのどちらか)をRESTRICTに設定してください。存在してください。
Hakala, et al. Standards Track [Page 71] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[71ページ]。
The Filter-Id AVP is defined in [NASREQ]. The Filter-Id AVP can be used to reference an IP filter list installed in the access device by means other than the Diameter credit-control application, e.g., locally configured or configured by another entity.
Filter-イドAVPは[NASREQ]で定義されます。 例えば、Filter-イドAVPは別の実体で局所的にIPフィルタリストがDiameter金融調整アプリケーション以外の手段でアクセスデバイスにインストールした参照に中古であるか、構成するか、または構成できます。
The Final-Unit-Indication AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Finalユニット指示AVPが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]
最終的なユニット指示:、:= <AVPヘッダー: 430 >最終的なユニット動作*[制限フィルタ規則]*[フィルタイド][再直接のサーバ]
8.35. Final-Unit-Action AVP
8.35. 最終的なユニット動作AVP
The Final-Unit-Action AVP (AVP Code 449) is of type Enumerated and indicates to the credit-control client the action to be taken when the user's account cannot cover the service cost.
Finalユニット動作AVP(AVP Code449)は、タイプEnumeratedにはあって、ユーザのアカウントが勤務評価額をカバーできないとき、取るために金融調整クライアントに動作を示します。
The Final-Unit-Action can be one of the following:
Finalユニット動作は以下の1つであるかもしれません:
TERMINATE 0
The credit-control client MUST terminate the service session.
This is the default handling, applicable whenever the credit-
control client receives an unsupported Final-Unit-Action value,
and it MUST be supported by all the Diameter credit-control client
implementations conforming to this specification.
金融調整クライアントのTERMINATE0はサービスセッションを終えなければなりません。 クレジットコントロールクライアントがサポートされないFinalユニット動作値を受けるときはいつも、これは適切なデフォルト取り扱いです、そして、この仕様に従うすべてのDiameter金融調整クライアント実装でそれをサポートしなければなりません。
REDIRECT 1
The service element MUST redirect the user to the address
specified in the Redirect-Server-Address AVP. The redirect action
is defined in section 5.6.2.
REDIRECT、1 サービス要素はRedirectサーバアドレスAVPで指定されたアドレスにユーザを向け直さなければなりません。 再直接の動きはセクション5.6.2で定義されます。
RESTRICT_ACCESS 2
The access device MUST restrict the user access according to the
IP packet filters defined in the Restriction-Filter-Rule AVP or
according to the IP packet filters identified by the Filter-Id
AVP. All the packets not matching the filters MUST be dropped
(see section 5.6.3).
Restrictionフィルタ規則AVPかFilter-イドAVPによって特定されたIPパケットフィルタに従ってアクセスデバイスがフィルタが定義したIPパケットに従ったユーザアクセスを制限しなければならないRESTRICT_ACCESS2。 フィルタに合っていないすべてのパケットを下げなければなりません(セクション5.6.3を見てください)。
8.36. Restriction-Filter-Rule AVP
8.36. 制限フィルタ規則AVP
The Restriction-Filter-Rule AVP (AVP Code 438) is of type IPFilterRule and provides filter rules corresponding to services that are to remain accessible even if there are no more service units granted. The access device has to configure the specified filter
Restrictionフィルタ規則AVP(AVP Code438)はタイプIPFilterRuleにはあって、それ以上のサービスユニットが全くなくてもアクセスしやすいままで残ることになっているサービスに対応する規則が与えたフィルタを供給します。 アクセスデバイスは指定されたフィルタを構成しなければなりません。
Hakala, et al. Standards Track [Page 72] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[72ページ]。
rules for the subscriber and MUST drop all the packets not matching these filters. Zero, one, or more such AVPs MAY be present in a Credit-Control-Answer message or in an AA answer message.
加入者のために統治して、これらのフィルタに合っていないすべてのパケットを下げなければなりません。 ゼロ、そのようなAVPsの1つ以上はCreditコントロール答えメッセージかAA答えメッセージに存在しているかもしれません。
8.37. Redirect-Server AVP
8.37. 再直接のサーバAVP
The Redirect-Server AVP (AVP Code 434) is of type Grouped and contains the address information of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end user is to be connected when the account cannot cover the service cost. It MUST be present when the Final-Unit-Action AVP is set to REDIRECT.
Redirect-サーバAVP(AVP Code434)はタイプGroupedにはあって、アカウントが勤務評価額をカバーできないときエンドユーザが関連させていることになっている再直接のサーバ(例えば、HTTPの再直接のサーバ、SIP Server)に関するアドレス情報を含んでいます。 Finalユニット動作AVPがREDIRECTに用意ができているとき、それは存在していなければなりません。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
それが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }
再直接のサーバ:、:= <AVPヘッダー: 434 >の再直接のアドレスタイプサーバアドレスを転送してください。
8.38. Redirect-Address-Type AVP
8.38. 再直接のアドレスタイプAVP
The Redirect-Address-Type AVP (AVP Code 433) is of type Enumerated and defines the address type of the address given in the Redirect- Server-Address AVP.
RedirectアドレスタイプAVP(AVP Code433)はタイプEnumeratedにはあって、RedirectサーバアドレスAVPで与えられたアドレスのアドレスタイプを定義します。
The address type can be one of the following:
アドレスタイプは以下のひとりであることができます:
IPv4 Address 0
The address type is in the form of "dotted-decimal" IPv4 address,
as defined in [IPv4].
アドレスタイプのIPv4 Address0が[IPv4]で定義されるように「ドット付き10進法」IPv4アドレスの形にあります。
IPv6 Address 1
The address type is in the form of IPv6 address, as defined in
[IPv6Addr]. The address is a text representation of the address
in either the preferred or alternate text form [IPv6Addr].
Conformant implementations MUST support the preferred form and
SHOULD support the alternate text form for IPv6 addresses.
アドレスタイプのIPv6 Address1が[IPv6Addr]で定義されるようにIPv6アドレスの形にあります。 アドレスは都合のよいか代替テキストフォーム[IPv6Addr]で、アドレスのテキスト表現です。 Conformant実装は好まれた形をサポートしなければなりません、そして、SHOULDはIPv6アドレスのために代替テキストフォームをサポートします。
URL 2
The address type is in the form of Uniform Resource Locator, as
defined in [URL].
URL2 アドレスタイプが[URL]で定義されるようにUniform Resource Locatorの形にあります。
SIP URI 3
The address type is in the form of SIP Uniform Resource
Identifier, as defined in [SIP].
アドレスタイプのSIP URI3は[SIP]で定義されるようにSIP Uniform Resource Identifierの形にあります。
Hakala, et al. Standards Track [Page 73] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[73ページ]。
8.39. Redirect-Server-Address AVP
8.39. 再直接のサーバアドレスAVP
The Redirect-Server-Address AVP (AVP Code 435) is of type UTF8String and defines the address of the redirect server (e.g., HTTP redirect server, SIP Server) with which the end user is to be connected when the account cannot cover the service cost.
RedirectサーバアドレスAVP(AVP Code435)はタイプUTF8Stringにはあって、アカウントが勤務評価額をカバーできないときエンドユーザが関連させていることになっている再直接のサーバ(例えば、HTTPの再直接のサーバ、SIP Server)のアドレスを定義します。
8.40. Multiple-Services-Indicator AVP
8.40. 複数のサービスインディケータAVP
The Multiple-Services-Indicator AVP (AVP Code 455) is of type Enumerated and indicates whether the Diameter credit-control client is capable of handling multiple services independently within a (sub-) session. The absence of this AVP means that independent credit-control of multiple services is not supported.
MultipleサービスインディケータAVP(AVP Code455)が、タイプEnumeratedにはあって、aの中にDiameter金融調整クライアントが独自に複数のサービスを扱うことができるかどうかを示す、(サブ、)、セッション。 このAVPの不在は、複数のサービスの独立している金融調整がサポートされないことを意味します。
A server not implementing the independent credit-control of multiple services MUST treat the Multiple-Services-Indicator AVP as an invalid AVP.
複数のサービスの独立している金融調整を実装しないサーバは無効のAVPとしてMultipleサービスインディケータAVPを扱わなければなりません。
The following values are defined for the Multiple-Services-Indicator AVP:
以下の値はMultipleサービスインディケータAVPのために定義されます:
MULTIPLE_SERVICES_NOT_SUPPORTED 0
Client does not support independent credit-control of multiple
services within a (sub-)session.
MULTIPLE_SERVICES_NOT_SUPPORTED0Clientがaの中の複数のサービスの独立している金融調整をサポートしない、(サブ、)、セッション。
MULTIPLE_SERVICES_SUPPORTED 1
Client supports independent credit-control of multiple services
within a (sub-)session.
MULTIPLE_SERVICES_SUPPORTED1Clientがaの中の複数のサービスの独立している金融調整をサポートする、(サブ、)、セッション。
8.41. Requested-Action AVP
8.41. 要求された動作AVP
The Requested-Action AVP (AVP Code 436) is of type Enumerated and contains the requested action being sent by Credit-Control-Request command where the CC-Request-Type is set to EVENT_REQUEST. The following values are defined for the Requested-Action AVP:
Requested-動作AVP(AVP Code436)はタイプEnumeratedにはあって、CC要求タイプがEVENT_REQUESTに用意ができているCreditコントロール要求命令で送られる要求された動作を含んでいます。以下の値はRequested-動作AVPのために定義されます:
DIRECT_DEBITING 0
This indicates a request to decrease the end user's account
according to information specified in the Requested-Service-Unit
AVP and/or Service-Identifier AVP (additional rating information
may be included in service-specific AVPs or in the Service-
Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-
Control-Answer command contains the debited units.
DIRECT_DEBITING0Thisは、情報によると、エンドユーザのアカウントを減少させるという要求がRequestedサービスユニットAVP、そして/または、Service-識別子AVPで指定したのを(追加格付けの情報はサービス特有のAVPsかServiceパラメタインフォメーションAVPに含まれるかもしれません)示します。 Creditコントロール答え命令におけるGrantedサービスユニットAVPは借り方に記入されたユニットを含んでいます。
Hakala, et al. Standards Track [Page 74] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[74ページ]。
REFUND_ACCOUNT 1
This indicates a request to increase the end user's account
according to information specified in the Requested-Service-Unit
AVP and/or Service-Identifier AVP (additional rating information
may be included in service-specific AVPs or in the Service-
Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-
Control-Answer command contains the refunded units.
REFUND_ACCOUNT1Thisは、情報によると、エンドユーザのアカウントを増強するという要求がRequestedサービスユニットAVP、そして/または、Service-識別子AVPで指定したのを(追加格付けの情報はサービス特有のAVPsかServiceパラメタインフォメーションAVPに含まれるかもしれません)示します。 Creditコントロール答え命令におけるGrantedサービスユニットAVPは還付されたユニットを含んでいます。
CHECK_BALANCE 2
This indicates a balance check request. In this case, the
checking of the account balance is done without any credit
reservation from the account. The Check-Balance-Result AVP in the
Credit-Control-Answer command contains the result of the balance
check.
CHECK_BALANCE2Thisはバランスチェック要求を示します。 この場合、アカウントから少しもクレジットの予約なしで勘定残高の照合をします。 Creditコントロール答え命令におけるCheckバランス結果AVPはバランスチェックの結果を含んでいます。
PRICE_ENQUIRY 3
This indicates a price enquiry request. In this case, neither
checking of the account balance nor reservation from the account
will be done; only the price of the service will be returned in
the Cost-Information AVP in the Credit-Control-Answer Command.
PRICE_ENQUIRY3Thisは価格調査要求を示します。 この場合、勘定残高の照合もアカウントから予約しないだろうというのも。 サービスの価格だけがCreditコントロール答えCommandにおけるCost-情報AVPで返されるでしょう。
8.42. Service-Context-Id AVP
8.42. サービス文脈イドAVP
The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and contains a unique identifier of the Diameter credit-control service specific document that applies to the request (as defined in section 4.1.2). This is an identifier allocated by the service provider, by the service element manufacturer, or by a standardization body, and MUST uniquely identify a given Diameter credit-control service specific document. The format of the Service-Context-Id is:
Service文脈イドAVPはタイプUTF8String(AVP Code461)にはあって、要求に適用されるDiameterの金融調整のサービスの特定のドキュメントのユニークな識別子を含んでいます(セクション4.1.2で定義されるように)。 これは、サービスプロバイダー、サービス要素メーカー、または標準化本体によって割り当てられた識別子であり、唯一与えられたDiameter金融調整サービス特定のドキュメントを特定しなければなりません。 Service文脈イドの形式は以下の通りです。
"service-context" "@" "domain"
"@"「ドメイン」という「サービス文脈」
service-context = Token
サービス文脈=トークン
The Token is an arbitrary string of characters and digits.
Tokenはキャラクタとケタの任意のストリングです。
'domain' represents the entity that allocated the Service-Context-Id. It can be ietf.org, 3gpp.org, etc., if the identifier is allocated by a standardization body, or it can be the FQDN of the service provider (e.g., provider.example.com) or of the vendor (e.g., vendor.example.com) if the identifier is allocated by a private entity.
'ドメイン'はService Contextアイダホ州を割り当てた実体を表します。 それはietf.org、3gpp.orgであるかもしれませんなど、標準化本体で識別子を割り当てるか、識別子が民間会社によって割り当てられるならそれがサービスプロバイダー(例えば、provider.example.com)かベンダー(例えば、vendor.example.com)のFQDNであるかもしれないなら。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVP SHOULD、可能であるとしてのDiameterヘッダーの近くように、置かれてください。
Hakala, et al. Standards Track [Page 75] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[75ページ]。
Service-specific documents that are for private use only (i.e., to one provider's own use, where no interoperability is deemed useful) may define private identifiers without need of coordination. However, when interoperability is wanted, coordination of the identifiers via, for example, publication of an informational RFC is RECOMMENDED in order to make Service-Context-Id globally available.
私用だけのためのものであるサービス特有のドキュメントはコーディネートの必要性なしで個人的な識別子を定義するかもしれません。 しかしながら、相互運用性が欲しいときに、例えば、情報のRFCの公表を通した識別子のコーディネートは、Service文脈イドをグローバルに利用可能にするRECOMMENDEDです。
8.43. Service-Parameter-Info AVP
8.43. サービスパラメタインフォメーションAVP
The Service-Parameter-Info AVP (AVP Code 440) is of type Grouped and contains service-specific information used for price calculation or rating. The Service-Parameter-Type AVP defines the service parameter type, and the Service-Parameter-Value AVP contains the parameter value. The actual contents of these AVPs are not within the scope of this document and SHOULD be defined in another Diameter application, in standards written by other standardization bodies, or in service- specific documentation.
ServiceパラメタインフォメーションAVP(AVP Code440)はタイプGroupedにはあって、価格計算か格付けに使用されるサービス特有の情報を含んでいます。 ServiceパラメタタイプAVPはサービスパラメータの型を定義します、そして、Serviceパラメタ価値のAVPはパラメタ値を含んでいます。 別のDiameterアプリケーションで定義されて、規格で他の標準化本体、またはサービスの特定のドキュメンテーションに書かれていて、このドキュメントとSHOULDの範囲の中にこれらのAVPsの実際の内容がありません。
In the case of an unknown service request (e.g., unknown Service- Parameter-Type), the corresponding answer message MUST contain the error code DIAMETER_RATING_FAILED. A Credit-Control-Answer message with this error MUST contain one or more Failed-AVP AVPs containing the Service-Parameter-Info AVPs that caused the failure.
未知のサービスのリクエスト(例えば、未知のServiceパラメタタイプ)の場合では、対応する答えメッセージはエラーコードDIAMETER_RATING_FAILEDを含まなければなりません。 この誤りがあるCreditコントロール答えメッセージは失敗を引き起こしたServiceパラメタインフォメーションAVPsを含む1Failed-AVP AVPsを含まなければなりません。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
それが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
Service-Parameter-Info ::= < AVP Header: 440 >
{ Service-Parameter-Type }
{ Service-Parameter-Value }
サービスパラメタインフォメーション:、:= <AVPヘッダー: 440 >サービスパラメータの型サービスパラメタ価値
8.44. Service-Parameter-Type AVP
8.44. サービスパラメータの型AVP
The Service-Parameter-Type AVP is of type Unsigned32 (AVP Code 441) and defines the type of the service event specific parameter (e.g., it can be the end-user location or service name). The different parameters and their types are service specific, and the meanings of these parameters are not defined in this document. Whoever allocates the Service-Context-Id (i.e., unique identifier of a service-specific document) is also responsible for assigning Service-Parameter-Type values for the service and ensuring their uniqueness within the given service. The Service-Parameter-Value AVP contains the value associated with the service parameter type.
ServiceパラメタタイプAVPはタイプUnsigned32(AVP Code441)にはあって、サービスイベント特有のパラメタのタイプを定義します(例えば、それは、エンドユーザ位置かサービス名であるかもしれません)。 異なったパラメタと彼らのタイプはサービス特有です、そして、これらのパラメタの意味は本書では定義されません。 また、Service文脈イド(すなわち、サービス特有のドキュメントのユニークな識別子)を割り当てる人なら誰でもサービスのためにServiceパラメタタイプに値を割り当てて、与えられたサービスの中でそれらのユニークさを保証するのに責任があります。 Serviceパラメタ価値のAVPはサービスパラメータの型に関連している値を含んでいます。
Hakala, et al. Standards Track [Page 76] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[76ページ]。
8.45. Service-Parameter-Value AVP
8.45. サービスパラメタ価値のAVP
The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) and contains the value of the service parameter type.
Serviceパラメタ価値のAVPはタイプOctetString(AVP Code442)にはあって、サービスパラメータの型の値を含んでいます。
8.46. Subscription-Id AVP
8.46. 購読イドAVP
The Subscription-Id AVP (AVP Code 443) is used to identify the end user's subscription and is of type Grouped. The Subscription-Id AVP includes a Subscription-Id-Data AVP that holds the identifier and a Subscription-Id-Type AVP that defines the identifier type.
Subscription-イドAVP(AVP Code443)はエンドユーザの購読を特定するのに使用されて、タイプGroupedにはあります。 Subscription-イドAVPは識別子を保持するSubscriptionイドデータAVPと識別子タイプを定義するSubscriptionイドタイプAVPを含んでいます。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
それが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
Subscription-Id ::= < AVP Header: 443 >
{ Subscription-Id-Type }
{ Subscription-Id-Data }
購読イド:、:= <AVPヘッダー: 443 >購読イドタイプ購読イドデータ
8.47. Subscription-Id-Type AVP
8.47. 購読イドタイプAVP
The Subscription-Id-Type AVP (AVP Code 450) is of type Enumerated, and it is used to determine which type of identifier is carried by the Subscription-Id AVP.
タイプEnumeratedにはSubscriptionイドタイプAVP(AVP Code450)があります、そして、それは、どのタイプに関する識別子がSubscription-イドAVPによって運ばれるかを決定するのに使用されます。
This specification defines the following subscription identifiers. However, new Subscription-Id-Type values can be assigned by an IANA designated expert, as defined in section 12. A server MUST implement all the Subscription-Id-Types required to perform credit authorization for the services it supports, including possible future values. Unknown or unsupported Subscription-Id-Types MUST be treated according to the 'M' flag rule, as defined in [DIAMBASE].
この仕様は以下の購読識別子を定義します。 しかしながら、セクション12で定義されるように専門家に指定されたIANAは新しいSubscriptionイドタイプ値を割り当てることができます。 サーバはそれがサポートするサービスのためにクレジット承認を実行するのに必要であるすべてのSubscriptionイドタイプを実装しなければなりません、可能な将来価値を含んでいて。 'M'旗の規則に従って、[DIAMBASE]で定義されるように未知の、または、サポートされないSubscriptionイドタイプを扱わなければなりません。
END_USER_E164 0
The identifier is in international E.164 format (e.g., MSISDN),
according to the ITU-T E.164 numbering plan defined in [E164] and
[CE164].
E.164付番プランが定義したITU-Tに従った国際的なE.164形式(例えば、MSISDN)には識別子があるEND_USER_E164 0[164E]と[CE164。]
END_USER_IMSI 1
The identifier is in international IMSI format, according to the
ITU-T E.212 numbering plan as defined in [E212] and [CE212].
END、_ITU-T E.212付番計画に従った国際的なIMSI形式には識別子があるUSER_IMSI1は中で[212E]と[CE212]を定義しました。
END_USER_SIP_URI 2
The identifier is in the form of a SIP URI, as defined in [SIP].
識別子が定義されるとしてのSIP URIの形にあるEND_USER_SIP_URI2[SIP]。
END_USER_NAI 3
The identifier is in the form of a Network Access Identifier, as
defined in [NAI].
END、_識別子が定義されるとしてのa Network Access Identifierの形にあるUSER_NAI3[NAI]。
Hakala, et al. Standards Track [Page 77] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[77ページ]。
END_USER_PRIVATE 4
The Identifier is a credit-control server private identifier.
END_USER_兵士、4 Identifierは金融調整のサーバの個人的な識別子です。
8.48. Subscription-Id-Data AVP
8.48. 購読イドデータAVP
The Subscription-Id-Data AVP (AVP Code 444) is used to identify the end user and is of type UTF8String. The Subscription-Id-Type AVP defines which type of identifier is used.
SubscriptionイドデータAVP(AVP Code444)はエンドユーザを特定するのに使用されて、タイプUTF8Stringにはあります。 SubscriptionイドタイプAVPは、どのタイプの識別子が使用されているかを定義します。
8.49. User-Equipment-Info AVP
8.49. ユーザ設備インフォメーションAVP
The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and allows the credit-control client to indicate the identity and capability of the terminal the subscriber is using for the connection to network.
User設備インフォメーションAVP(AVP Code458)は、タイプGroupedにはあって、金融調整クライアントが加入者がネットワークでつなぐ接続に使用している端末のアイデンティティと能力を示すのを許容します。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
それが以下の通り定義される、(分類されたavpクールである、RFC3588[DIAMBASE)について:
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
ユーザ設備インフォメーション:、:= <AVPヘッダー: 458 >ユーザ設備インフォメーションタイプユーザ設備インフォメーション価値
8.50. User-Equipment-Info-Type AVP
8.50. ユーザ設備インフォメーションタイプAVP
The User-Equipment-Info-Type AVP is of type Enumerated (AVP Code 459) and defines the type of user equipment information contained in the User-Equipment-Info-Value AVP.
User設備インフォメーションタイプAVPはタイプEnumerated(AVP Code459)にはあって、User設備インフォメーション価値のAVPに含まれたユーザ設備情報のタイプを定義します。
This specification defines the following user equipment types. However, new User-Equipment-Info-Type values can be assigned by an IANA designated expert, as defined in section 12.
この仕様は以下のユーザ設備タイプを定義します。 しかしながら、セクション12で定義されるように専門家に指定されたIANAは新しいUser設備インフォメーションタイプ値を割り当てることができます。
IMEISV 0
The identifier contains the International Mobile Equipment
Identifier and Software Version in the international IMEISV format
according to 3GPP TS 23.003 [3GPPIMEI].
IMEISV、0 3GPP TS23.003[3GPPIMEI]によると、識別子は国際的なIMEISV形式に国際モバイルEquipment IdentifierとSoftwareバージョンを含んでいます。
MAC 1
The 48-bit MAC address is formatted as described in [RAD802.1X].
[RAD802.1X]で説明されて、48ビットのMACアドレスがフォーマットされるMAC1。
EUI64 2
The 64-bit identifier used to identify hardware instance of the
product, as defined in [EUI64].
64ビットの識別子が製品のハードウェアインスタンスを特定するのに[EUI64]で定義されるように使用したEUI64 2。
Hakala, et al. Standards Track [Page 78] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[78ページ]。
MODIFIED_EUI64 3
There are a number of types of terminals that have identifiers
other than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can
be converted to modified EUI-64 format as described in [IPv6Addr]
or by using some other methods referred to in the service-specific
documentation.
MODIFIED_EUI64 3ThereはIMEI、IEEE802MACs、またはEUI-64以外の識別子がある多くのタイプの端末です。 [IPv6Addr]かサービス特有のドキュメンテーションに示されたある他のメソッドを使用することによって説明されるように変更されたEUI-64形式にこれらの識別子を変換できます。
8.51. User-Equipment-Info-Value AVP
8.51. ユーザ設備インフォメーション価値のAVP
The User-Equipment-Info-Value AVP (AVP Code 460) is of type OctetString. The User-Equipment-Info-Type AVP defines which type of identifier is used.
タイプOctetStringにはUser設備インフォメーション価値のAVP(AVP Code460)があります。 User設備インフォメーションタイプAVPは、どのタイプの識別子が使用されているかを定義します。
9. Result Code AVP Values
9. 結果コードAVP値
This section defines new Result-Code AVP [DIAMBASE] values that must be supported by all Diameter implementations that conform to this specification.
このセクションはこの仕様に従うすべてのDiameter実装でサポートしなければならない新しいResult-コードAVP[DIAMBASE]値を定義します。
The Credit-Control-Answer message includes the Result-Code AVP, which may indicate that an error was present in the Credit-Control-Request message. A rejected Credit-Control-Request message SHOULD cause the user's session to be terminated.
Creditコントロール答えメッセージはResult-コードAVPを含んでいます。(AVPは誤りがCreditコントロール要求メッセージに存在していたのを示すかもしれません)。 SHOULDがユーザのセッションを終えさせる拒絶されたCreditコントロール要求メッセージ。
9.1. Transient Failures
9.1. 一時障害
Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but that the request MAY be able to be satisfied in the future.
一時障害カテゴリの中に下がる誤りは、それを受け取ったとき要望に応じることができませんでしたが、要求が将来満足することができるかもしれないことを同輩に知らせるのに使用されます。
DIAMETER_END_USER_SERVICE_DENIED 4010
The credit-control server denies the service request due to
service restrictions. If the CCR contained used-service-units,
they are deducted, if possible.
DIAMETER_END_USER_SERVICE_DENIED4010はサービスのため制限を要求します金融調整サーバが、サービスを否定する。 CCRが中古のサービス単位を含んだなら、できれば、それらは差し引かれます。
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011
The credit-control server determines that the service can be
granted to the end user but that no further credit-control is
needed for the service (e.g., service is free of charge).
_金融調整サーバが決定するエンドユーザのサービスを承諾できますが、より遠くにないクレジットで制御されるAPPLICABLE4011ではなくDIAMETER_CREDIT_CONTROL_がサービスに必要です(例えば、サービスは無料です)。
DIAMETER_CREDIT_LIMIT_REACHED 4012
The credit-control server denies the service request because the
end user's account could not cover the requested service. If the
CCR contained used-service-units they are deducted, if possible.
金融調整サーバは、DIAMETER_CREDIT_LIMIT_REACHED4012が、エンドユーザのアカウントがそうすることができなかったので要求されたサービスをカバーするよう要求することをサービスを否定します。 CCRが中古のサービス単位を含んだなら、それらは、差し引かれて、可能です。
Hakala, et al. Standards Track [Page 79] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[79ページ]。
9.2. Permanent Failures
9.2. 永久的な失敗
Errors that fall within the permanent failure category are used to inform the peer that the request failed and should not be attempted again.
永久的な失敗カテゴリの中に下がる誤りは、要求が失敗されて、再び試みられるべきでないことを同輩に知らせるのに使用されます。
DIAMETER_USER_UNKNOWN 5030
The specified end user is unknown in the credit-control server.
指定されたエンドユーザのDIAMETER_USER_UNKNOWN5030は金融調整サーバで未知です。
DIAMETER_RATING_FAILED 5031
This error code is used to inform the credit-control client that
the credit-control server cannot rate the service request due to
insufficient rating input, an incorrect AVP combination, or an AVP
or an AVP value that is not recognized or supported in the rating.
The Failed-AVP AVP MUST be included and contain a copy of the
entire AVP(s) that could not be processed successfully or an
example of the missing AVP complete with the Vendor-Id if
applicable. The value field of the missing AVP should be of
correct minimum length and contain zeros.
DIAMETER_RATING_FAILED5031Thisエラーコードは、金融調整サーバが、不十分な格付けによるサービスのリクエストが格付けで認識されないか、またはサポートされない入力、不正確なAVP組み合わせ、AVPまたはAVP値であると評定できないことを金融調整クライアントに知らせるのに使用されます。 Failed-AVP AVPはVendor-イドで完全ですが、適切な状態で含まれていて、首尾よく処理できなかった全体のAVP(s)のコピーかなくなったAVPに関する例を含まなければなりません。 なくなったAVPの値の分野は、適度の最小の長さがあって、ゼロを含むべきです。
10. AVP Occurrence Table
10. AVP発生テーブル
The following table presents the AVPs defined in this document and specifies in which Diameter messages they MAY or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
以下のテーブルは、本書では定義されたAVPsを寄贈して、それらがどのDiameterメッセージで存在しているかもしれないかを指定します。 Grouped AVPの中に存在するだけである場合があるAVPsがこのテーブルに表されないことに注意してください。
The table uses the following symbols:
テーブルは以下のシンボルを使用します:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0-1 Zero or one instance of the AVP MAY be present in the
message. It is considered an error if there is more
than one instance of the AVP.
1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the
message.
0、AVP MUST NOT、メッセージに存在してください。 0 ゼロか以上が現在のコネがメッセージであったならAVP MAYについて例証する+。 0-1ゼロか1 現在のコネがメッセージであったならAVP MAYについて例証します。 AVPの1つ以上のインスタンスがあれば、それは誤りであると考えられます。 ものが現在のコネがメッセージであったならAVP MUSTについて例証する1。 1 少なくともものが現在のコネがメッセージであったならAVP MUSTについて例証する+。
Hakala, et al. Standards Track [Page 80] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[80ページ]。
10.1. Credit-Control AVP Table
10.1. 金融調整AVPテーブル
The table in this section is used to represent which credit-control applications specific AVPs defined in this document are to be present in the credit-control messages.
このセクションのテーブルによる特定のAVPsが定義したどの金融調整アプリケーションを表すかに使用されているのが、金融調整メッセージに本書では存在していることであるということです。
+-----------+
| 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 |
+-----------+ | コマンド| | コード| |-----+-----+ 属性名| CCR| CCA| ------------------------------|-----+-----+ Acctマルチセッションイド| 0-1 | 0-1 | Authアプリケーションイド| 1 | 1 | CC相関関係イド| 0-1 | 0 | CCセッションフェイルオーバー| 0 | 0-1 | CCリクエスト番号| 1 | 1 | ccはタイプを要求します。| 1 | 1 | CCのサブセッションのイド| 0-1 | 0-1 | バランス結果をチェックしてください。| 0 | 0-1 | コスト情報| 0 | 0-1 | クレジットコントロール失敗、-| 0 | 0-1 | 取り扱い| | | あて先ホスト| 0-1 | 0 | 目的地分野| 1 | 0 | ダイレクトに借り方である失敗、-| 0 | 0-1 | 取り扱い| | | イベントタイムスタンプ| 0-1 | 0-1 | 失敗したAVP| 0 | 0+ | 最終的なユニット指示| 0 | 0-1 | 与えられたサービスユニット| 0 | 0-1 | 複数のサービスクレジット、-| 0+ | 0+ | コントロール| | | 複数のサービスインディケータ| 0-1 | 0 | 発生源ホスト| 1 | 1 | 発生源分野| 1 | 1 | 発生源州のイド| 0-1 | 0-1 | プロキシインフォメーション| 0+ | 0+ | 再直接のホスト| 0 | 0+ | ホスト用法を向け直してください。| 0 | 0-1 | マックスキャッシュ時間を向け直してください。| 0 | 0-1 | 要求された動作| 0-1 | 0 | 要求されたサービスユニット| 0-1 | 0 | ルート記録| 0+ | 0+ | 結果コード| 0 | 1 | サービス文脈イド| 1 | 0 | サービス識別子| 0-1 | 0 | サービスパラメタインフォメーション| 0+ | 0 |
Hakala, et al. Standards Track [Page 81] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[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 |
------------------------------|-----+-----+
セッションイド| 1 | 1 | 購読イド| 0+ | 0 | 終了原因| 0-1 | 0 | ユーザ設備インフォメーション| 0-1 | 0 | 中古のサービス単位| 0+ | 0 | ユーザ名| 0-1 | 0-1 | 正当性時間| 0 | 0-1 | ------------------------------|-----+-----+
10.2. Re-Auth-Request/Answer AVP Table
10.2. Authの再要求/答えAVPテーブル
This section defines AVPs that are specific to the Diameter credit- control application and that MAY be included in the Diameter Re- Auth-Request/Answer (RAR/RAA) message [DIAMBASE].
このセクションは含まれていて、Diameter Re- Auth-要求/答え(RAR/RAA)メッセージ[DIAMBASE]で制御アプリケーションとそれがそうするDiameterクレジットに特定のAVPsを定義します。
Re-Auth-Request/Answer command MAY include the following additional AVPs:
Authの再要求/答え命令は以下の追加AVPsを含むかもしれません:
+---------------+
| 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 |
------------------------------+-------+-------+
+---------------+ | コマンドコード| |-------+-------+ 属性名| RAR| RAA| ------------------------------+-------+-------+ CCのサブセッションのイド| 0-1 | 0-1 | G-S-Uプール識別子| 0-1 | 0-1 | サービス識別子| 0-1 | 0-1 | 格付けグループ| 0-1 | 0-1 | ------------------------------+-------+-------+
11. RADIUS/Diameter Credit-Control Interworking Model
11. モデルを織り込む直径半径/金融調整
This section defines the basic principles for the Diameter credit- control/RADIUS prepaid inter-working model; that is, a message translation between a RADIUS based prepaid solution and a Diameter credit-control application. A complete description of the protocol translations between RADIUS and the Diameter credit-control application is beyond the scope of this specification and SHOULD be addressed in another appropriate document, such as the RADIUS prepaid specification.
このセクションはDiameterクレジットコントロール/RADIUSのためにモデルを織り込みながら、前払いで基本原理を定義します。 すなわち、RADIUSの間のメッセージ翻訳は前払いの解決とDiameter金融調整アプリケーションを基礎づけました。 RADIUSの間のプロトコル変換の完全な記述とDiameter金融調整利用は扱われたコネが別の適切なドキュメントであったならこの仕様とSHOULDの範囲を超えています、RADIUSの前払いの仕様などのように。
The Diameter credit-control architecture may have a Translation Agent capable of translation between RADIUS prepaid and Diameter credit- control protocols. An AAA server (usually the home AAA server) may act as a Translation Agent and as a Diameter credit-control client for service elements that use credit-control mechanisms other than Diameter credit control for instance, RADIUS prepaid. In this case, the home AAA server contacts the Diameter credit-control server as part of the authorization process. The interworking architecture is
Diameter金融調整アーキテクチャでRADIUSの間の翻訳ができるTranslationエージェントは前払いになるかもしれません、そして、Diameterクレジットはプロトコルを制御します。 AAAサーバ(通常ホームAAAサーバ)はTranslationエージェントとして例えば、Diameter金融調整以外の金融調整メカニズムを使用するサービス要素、RADIUSのためのDiameter金融調整クライアントとして前払いに務めるかもしれません。 この場合、ホームAAAサーバは承認プロセスの一部としてDiameter金融調整サーバに連絡します。 織り込むアーキテクチャはそうです。
Hakala, et al. Standards Track [Page 82] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[82ページ]。
illustrated in Figure 7, and interworking flow in Figure 8. In a roaming situation the service element (e.g., the NAS) may be located in the visited network, and a visited AAA server is usually contacted. The visited AAA server connects then to the home AAA server.
図7で例証されて、図8で流れを織り込みます。 ローミング状況で、サービス要素(例えば、NAS)は訪問されたネットワークで位置するかもしれません、そして、通常、訪問されたAAAサーバは連絡されます。 訪問されたAAAサーバはその時、ホームAAAサーバに接続します。
RADIUS Prepaid
+--------+ +---------+ protocol +------------+ +--------+
| End |<----->| Service |<---------->| Home AAA | |Business|
| User | | Element | | Server | |Support |
+--------+ +-->| | |+----------+|->|System |
| +---------+ ||CC Client || | |
| |+----------+| | |
+--------+ | +------^-----+ +----^---+
| End |<--+ Credit-Control | |
| User | Protocol | |
+--------+ +-------V--------+ |
|Credit-Control |----+
| Server |
+----------------+
半径前払いの+--------+ +---------+ プロトコル+------------+ +--------+ | 終わり| <、-、-、-、--、>| サービス| <、-、-、-、-、-、-、-、-、--、>| ホームAAA| |ビジネス| | ユーザ| | 要素| | サーバ| |サポート| +--------+ +-->|、| |+----------+|、-、>|システム| | +---------+ ||CCクライアント|| | | | |+----------+| | | +--------+ | +------^-----+ +----^---+ | 終わり| <--+ 金融調整| | | ユーザ| プロトコル| | +--------+ +-------V--------+ | |金融調整|----+ | サーバ| +----------------+
Figure 7: Credit-control architecture with service element
containing translation agent, translating RADIUS
prepaid to Diameter credit-control protocol
図7: Diameter金融調整プロトコルへの前払いのRADIUSを翻訳して、サービス要素が翻訳エージェントを含んでいる金融調整アーキテクチャ
When the AAA server acting as a Translation Agent receives an initial RADIUS Access-Request message from service element (e.g., NAS access), it performs regular authentication and authorization. If the RADIUS Access-Request message indicates that the service element is capable of credit-control, and if the home AAA server finds that the subscriber is a prepaid subscriber, then a Diameter credit- control request SHOULD be sent toward the credit-control server to perform credit authorization and to establish a credit-control session. After the Diameter credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account, the reserved quota is returned to the home AAA server in the Diameter Credit-Control-Answer. Then the home AAA server sends the reserved quota to the service element in the RADIUS Access-Accept.
Translationエージェントとして務めるAAAサーバがサービス要素(例えば、NASアクセス)から初期のRADIUS Access-要求メッセージを受け取るとき、それは定期的な認証と承認を実行します。 RADIUS Access-要求メッセージが、サービス要素は金融調整ができるのを示して、ホームAAAサーバが、加入者が前払いの加入者であることがわかるなら、クレジットが制御するDiameterは、SHOULDがクレジット承認を実行して、金融調整セッションを証明するために金融調整サーバに向かって送られるよう要求します。 Diameter金融調整サーバがエンドユーザの勘定残高をチェックして、サービスを評定して、エンドユーザのアカウントからクレジットを予約した後に、Diameter Creditコントロール答えにおけるホームAAAサーバに予約された割当てを返します。 次に、ホームAAAサーバは中で予約された割当てをサービス要素に送ります。RADIUS Access受け入れます。
At the expiry of the allocated quota, the service element sends a new RADIUS Access-Request containing the units used this far to the home AAA server. The home AAA server shall map a RADIUS Access-Request containing the reported units to the Diameter credit-control server in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter credit-control server debits the used units from the end user's account and allocates a new quota that is returned to the home AAA server in the Diameter Credit-Control-Answer. The quota is
割り当てられた割当ての満期に、サービス要素はユニットを含んでいるとこれがホームAAAサーバに遠くに使用されたという新しいRADIUS Access-要求を送ります。Diameter Creditコントロール要求(UPDATE_REQUEST)におけるDiameter金融調整サーバに報告されたユニットを含んでいて、ホームAAAサーバはRADIUS Access-要求を写像するものとします。 Diameter金融調整サーバは、Diameter Creditコントロール答えでエンドユーザのアカウントから中古の単位を借り方に記入して、ホームAAAサーバに返される新しい割当てを割り当てます。 割当てはそうです。
Hakala, et al. Standards Track [Page 83] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[83ページ]。
transferred to the service element in the RADIUS Access-Accept. When the end user terminates the service, or when the entire quota has been used, the service element sends a RADIUS Access-Request. To debit the used units from the end user's account and to stop the credit-control session, the home AAA server sends a Diameter Credit- Control-Request (TERMINATION_REQUEST) to the credit-control server. The Diameter credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the home AAA server. The RADIUS Access-Accept is sent to the NAS.
RADIUS Access受け入れるのを中のサービス要素に移しました。 エンドユーザがサービスを終えるか、または全体の割当てが使用されたとき、サービス要素はRADIUS Access-要求を送ります。 エンドユーザのアカウントから中古の単位を借り方に記入して、金融調整セッションを中止するために、ホームAAAサーバはDiameter Creditコントロール要求(TERMINATION_REQUEST)を金融調整サーバに送ります。Diameter金融調整サーバは、Diameter Creditコントロール答えをホームAAAサーバに送ることによって、セッション終了を承諾します。RADIUS Access受け入れるのをNASに送ります。
Hakala, et al. Standards Track [Page 84] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[84ページ]。
A following diagram illustrates a RADIUS prepaid - Diameter credit- control interworking sequence.
次のダイヤグラムは前払いでRADIUSを例証します--直径クレジットは、系列を織り込みながら、制御されます。
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 | |
|<-----------------------| |
| | |
サービス要素翻訳エージェント(例えば、NAS)(CCクライアント)CCサーバ| アクセス要求| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| CCR(初期の)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| CCA(与えられたユニット)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| アクセスして受け入れてください。| | | (与えられたユニット) | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| : : : | アクセス要求| | | (中古の単位) | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| CCR(| | | アップデート、中古の単位)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| CCA(与えられたユニット)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| アクセスして受け入れてください。| | | (与えられたユニット) | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| : : : | アクセス要求| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| CCR、(終わり、| | | 中古の単位、)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| CCA| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| アクセスして受け入れてください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|
Figure 8: Message flow example with RADIUS prepaid -
Diameter credit-control interworking
エイト環: RADIUSが前払いであることでのメッセージ流れの例--直径金融調整の織り込むこと
12. IANA Considerations
12. IANA問題
This section contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA.
このセクションはこの仕様で作成された名前空間、またはIANAによって管理された既存の名前空間に割り当てられた値を含みます。
Hakala, et al. Standards Track [Page 85] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[85ページ]。
In the subsections below, when we speak about review by a Designated Expert, please note that the designated expert will be assigned by the IESG. Initially, such Expert discussions take place on the AAA WG mailing list.
以下の小区分では、私たちがDesignated Expertによるレビューについて話すとき、指定された専門家はIESGによって選任されるでしょう。 初めは、そのようなExpert議論はAAA WGメーリングリストで行われます。
12.1. Application Identifier
12.1. アプリケーション識別子
This specification assigns the value 4, 'Diameter Credit Control', to the Application Identifier namespace defined in [DIAMBASE]. See section 1.3 for more information.
この仕様は値4、'直径Credit Control'を[DIAMBASE]で定義されたApplication Identifier名前空間に割り当てます。 詳しい情報に関してセクション1.3を見てください。
12.2. Command Codes
12.2. コマンドコード
This specification uses the value 272 from the Command code namespace defined in [DIAMBASE] for the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) commands.
この仕様はCreditコントロール要求(CCR)とCreditコントロール答え(CCA)命令のために[DIAMBASE]で定義されたCommandコード名前空間から値272を使用します。
12.3. AVP Codes
12.3. AVPコード
This specification assigns the values 411 - 461 from the AVP code namespace defined in [DIAMBASE]. See section 8 for the assignment of the namespace in this specification.
この仕様はAVPコード名前空間からの411--461が[DIAMBASE]で定義した値を割り当てます。 この仕様に基づく、名前空間の課題に関してセクション8を見てください。
12.4. Result-Code AVP Values
12.4. 結果コードAVP値
This specification assigns the values 4010, 4011, 4012, 5030, 5031 from the Result-Code AVP value namespace defined in [DIAMBASE]. See section 9 for the assignment of the namespace in this specification.
この仕様は[DIAMBASE]で定義されたResult-コードAVP値の名前空間から値4010、4011、4012、5030、5031を割り当てます。 この仕様に基づく、名前空間の課題に関してセクション9を見てください。
12.5. CC-Request-Type AVP
12.5. ccがタイプを要求しているAVP
As defined in section 8.3, the CC-Request-Type AVP includes Enumerated type values 1 - 4. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.3で定義されるように、AVPが含むCC要求タイプEnumeratedタイプは1--4を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.6. CC-Session-Failover AVP
12.6. CCセッションフェイルオーバーAVP
As defined in section 8.4, the CC-Failover-Supported AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.4で定義されるように、サポートされたCCフェイルオーバーAVPはEnumeratedタイプ値0--1を含んでいます。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
Hakala, et al. Standards Track [Page 86] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[86ページ]。
12.7. CC-Unit-Type AVP
12.7. CCユニット型AVP
As defined in section 8.32, the CC-Unit-Type AVP includes Enumerated type values 0 - 5. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.32で定義されるように、AVPが含むCCユニットタイプEnumeratedタイプは0--5を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.8. Check-Balance-Result AVP
12.8. チェックバランス結果AVP
As defined in section 8.6, the Check-Balance-Result AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.6で定義されるように、AVPが含むCheckバランス結果Enumeratedタイプは0--1を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.9. Credit-Control AVP
12.9. 金融調整AVP
As defined in section 8.13, the Credit-Control AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.13で定義されるように、AVPが含むCredit-コントロールEnumeratedタイプは0--1を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.10. Credit-Control-Failure-Handling AVP
12.10. クレジットコントロール失敗取り扱いAVP
As defined in section 8.14, the Credit-Control-Failure-Handling AVP includes Enumerated type values 0 - 2. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.14で定義されるように、AVPが含むCreditコントロール失敗取り扱いEnumeratedタイプは0--2を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.11. Direct-Debiting-Failure-Handling AVP
12.11. ダイレクト借り方の失敗取り扱いAVP
As defined in section 8.15, the Direct-Debiting-Failure-Handling AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.15で定義されるように、失敗取り扱いを借り方に記入するDirect AVPはEnumeratedタイプ値0--1を含んでいます。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.12. Final-Unit-Action AVP
12.12. 最終的なユニット動作AVP
As defined in section 8.35, the Final-Unit-Action AVP includes Enumerated type values 0 - 2. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.35で定義されるように、AVPが含むFinalユニット動作Enumeratedタイプは0--2を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.13. Multiple-Services-Indicator AVP
12.13. 複数のサービスインディケータAVP
As defined in section 8.40, the Multiple-Services-Indicator AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.40で定義されるように、AVPが含むMultipleサービスインディケータEnumeratedタイプは0--1を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
Hakala, et al. Standards Track [Page 87] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[87ページ]。
12.14. Redirect-Address-Type AVP
12.14. 再直接のアドレスタイプAVP
As defined in section 8.38, the Redirect-Address-Type AVP includes Enumerated type values 0 - 3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.38で定義されるように、AVPが含むRedirectアドレスタイプEnumeratedタイプは0--3を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.15. Requested-Action AVP
12.15. 要求された動作AVP
As defined in section 8.41, the Requested-Action AVP includes Enumerated type values 0 - 3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.41で定義されるように、AVPが含むRequested-動作Enumeratedタイプは0--3を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.16. Subscription-Id-Type AVP
12.16. 購読イドタイプAVP
As defined in section 8.47, the Subscription-Id-Type AVP includes Enumerated type values 0 - 4. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.47で定義されるように、AVPが含むSubscriptionイドタイプEnumeratedタイプは0--4を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.17. Tariff-Change-Usage AVP
12.17. 関税変化用法AVP
As defined in section 8.27, the Tariff-Change-Usage AVP includes Enumerated type values 0 - 2. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.27で定義されるように、AVPが含むTariff変化用法Enumeratedタイプは0--2を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
12.18. User-Equipment-Info-Type AVP
12.18. ユーザ設備インフォメーションタイプAVP
As defined in section 8.50, the User-Equipment-Info-Type AVP includes Enumerated type values 0 - 3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.50で定義されるように、AVPが含むUser設備インフォメーションタイプEnumeratedタイプは0--3を評価します。 IANAは、作成して、このAVPのために名前空間であることを支持しています。 すべての残余価値がDesignated Expert[IANA]による課題に利用可能です。
13. Credit-Control Application Related Parameters
13. 金融調整アプリケーション関係パラメータ
Tx timer
Txタイマ
When real-time credit-control is required, the credit-control
client contacts the credit-control server before and while the
service is provided to an end user. Due to the real-time nature
of the application, the communication delays SHOULD be minimized;
e.g., to avoid an overly long service setup time experienced by
the end user. The Tx timer is introduced to control the waiting
time in the client in the Pending state. When the Tx timer
elapses, the credit-control client takes an action to the end user
according to the value of the Credit-Control-Failure-Handling AVP
リアルタイムの金融調整が以前必要であるときに、金融調整クライアントは金融調整サーバに連絡します、そして、サービスをゆったり過ごしてください。エンドユーザに提供します。 アプリケーションの瞬時性、コミュニケーション遅れSHOULDは最小にされます。 例えばエンドユーザによって経験されたひどく長いサービス準備時間を避けるために。 Txタイマは、Pending状態でクライアントで待ち時間を制御するために紹介されます。 Txタイマが経過すると、Creditコントロール失敗取り扱いAVPの値に従って、金融調整クライアントはエンドユーザに訴訟を起こします。
Hakala, et al. Standards Track [Page 88] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[88ページ]。
or Direct-Debiting-Failure-Handling AVP. The recommended value is
10 seconds.
または、ダイレクト借り方の失敗取り扱いAVP。 推奨値は10秒です。
Tcc timer
Tccタイマ
The Tcc timer supervises an ongoing credit-control session in the
credit-control server. It is RECOMMENDED to use the Validity-Time
as input to set the Tcc timer value. In case of transient
failures in the network, the Diameter credit-control server might
change to Idle state. To avoid this, the Tcc timer MAY be set so
that Tcc equals to 2 x Validity-Time.
Tccタイマは金融調整サーバにおける進行中の金融調整セッションを監督します。それはTccタイマ価値を設定するために入力されるようにValidity-時間を費やすRECOMMENDEDです。 ネットワークにおける一時障害の場合には、Diameter金融調整サーバはIdle状態に変化するかもしれません。 これを避けるために、Tccタイマが設定されるかもしれないので、Tccはx Validity-時間と2と等しいです。
Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling
クレジットコントロール失敗取り扱いとダイレクト借り方の失敗取り扱い
Client implementations may offer the possibility of locally
configuring these AVPs. In such a case their value and behavior
is defined in section 5.7 for the Credit-Control-Failure-Handling
and in section 6.5 for the Direct-Debiting-Failure-Handling.
クライアント実装は局所的にこれらのAVPsを構成する可能性を提供するかもしれません。 このような場合には彼らの値と振舞いはCreditコントロール失敗取り扱いのためのセクション5.7と失敗取り扱いを借り方に記入するDirectのためのセクション6.5で定義されます。
14. Security Considerations
14. セキュリティ問題
The Diameter base protocol [DIAMBASE] requires that each Diameter implementation use underlying security; i.e., IPsec or TLS. These mechanisms are believed to provide sufficient protection under the normal Internet threat model; that is, assuming that the authorized nodes engaging in the protocol have not been compromised, but that the attacker has complete control over the communication channels between them. This includes eavesdropping, message modification, insertion, and man-in-the-middle and replay attacks. Note also that this application includes a mechanism for application layer replay protection by means of the Session-Id from [DIAMBASE] and CC- Request-Number, which is specified in this document. The Diameter credit-control application is often used within one domain, and there may be a single hop between the peers. In these environments, the use of TLS or IPsec is sufficient. The details of TLS and IPsec related security considerations are discussed in the [DIAMBASE].
Diameterベースプロトコル[DIAMBASE]は、それぞれのDiameter実装が基本的なセキュリティを使用するのを必要とします。 すなわち、IPsecかTLS。 これらのメカニズムが普通のインターネットの脅威モデルの下に十分な保護を供給すると信じられています。 すなわち、プロトコルに従事している認可されたノードが感染されていませんが、攻撃者がそれらの間に通信チャネルの完全なコントロールを持っていると仮定すること。 これは盗聴、メッセージ変更、挿入、中央の人、および反射攻撃を含んでいます。 また、このアプリケーションが[DIAMBASE]からのSession-イドとCC要求番号によって応用層反復操作による保護のためのメカニズムを含んでいることに注意してください。番号は本書では指定されます。 Diameter金融調整アプリケーションは1つのドメインの中でしばしば使用されます、そして、同輩の間には、単一のホップがあるかもしれません。 これらの環境で、TLSかIPsecの使用は十分です。 [DIAMBASE]でTLSとIPsecの関連するセキュリティ問題の詳細について議論します。
Because this application handles monetary transactions (directly or indirectly), it increases the interest for various security attacks. Therefore, all parties communicating with each other MUST be authenticated, including, for instance, TLS client-side authentication. In addition, authorization of the client SHOULD be emphasized; i.e., that the client is allowed to perform credit- control for a certain user. The specific means of authorization are outside of the scope of this specification but can be, for instance, manual configuration.
このアプリケーションが金融取引(直接か間接的である)を処理するので、それは様々なセキュリティー攻撃に関する関心を増強します。 したがって、例えばTLSクライアントサイド認証を含んでいて、互いにコミュニケートするすべてのパーティーを認証しなければなりません。 追加、クライアントSHOULDの承認、強調されてください。 すなわち、クライアントは確信しているユーザのためにクレジットコントロールを実行できます。 承認の特定の手段は、この仕様の範囲の外にありますが、例えば、手動の構成であるかもしれません。
Hakala, et al. Standards Track [Page 89] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[89ページ]。
Another kind of threat is malicious modification, injection, or deletion of AVPs or complete credit-control messages. The credit- control messages contain sensitive billing related information (such as subscription Id, granted units, used units, cost information) whose malicious modification can have financial consequences. Sometimes simply delaying the credit-control messages can cause disturbances in the credit-control client or server.
もう1種類の脅威は、AVPsか完全な金融調整メッセージの悪意がある変更、注射、または削除です。 クレジットコントロールメッセージは悪意がある変更が財政的な結果を持つことができる機密の支払い関連情報(購読Id、与えられた中古さユニットのユニット、コスト情報などの)を含んでいます。 時々単に金融調整メッセージを遅らせると、金融調整クライアントかサーバにおける騒動は引き起こされる場合があります。
Even without any modification to the messages, an adversary can invite a security threat by eavesdropping, as the transactions contain private information about the user. Also, by monitoring the credit-control messages one can collect information about the credit-control server's billing models and business relationships.
メッセージへの少しも変更がなくても、敵は盗聴で軍事的脅威を招待できます、トランザクションがユーザに関する個人情報を含むとき。 また、金融調整をモニターすることによって、メッセージ1は金融調整サーバの支払いモデルと取引関係の情報を集めることができます。
When third-party relays or proxy are involved, the hop-by-hop security does not necessarily provide sufficient protection for Diameter user session. In some cases, it may be inappropriate to send Diameter messages, such as CCR and CCA, containing sensitive AVPs via untrusted Diameter proxy agents, as there are no assurances that third-party proxies will not modify the credit-control commands or AVP values.
第三者リレーかプロキシがかかわるとき、ホップごとのセキュリティはDiameterユーザセッションのために必ず十分な保護を提供するというわけではありません。 いくつかの場合、メッセージをDiameterに送るのは不適当であるかもしれません、CCRやCCAのように、信頼されていないDiameterプロキシエージェントを通して敏感なAVPsを含んでいて、第三者プロキシが金融調整命令かAVP値を変更しないという保証が全くないとき。
14.1. Direct Connection with Redirects
14.1. 接続を指示する、向け直す。
A Diameter credit-control agent cannot always know whether agents between it and the end user's Diameter credit-control server are reliable. In this case, the Diameter credit-control agent doesn't have a routing entry in its Diameter Routing Table (defined in [DIAMBASE], section 2.7) for the realm of the credit-control server in the end user's home domain. The Diameter credit-control agent can have a default route configured to a local Redirect agent, and it redirects the CCR message to the redirect agent. The local Redirect agent then returns a redirect notification (Result-code 3006, DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as Diameter credit-control server(s) information (Redirect-Host AVP) and information (Redirect-Host-Usage AVP) about how the routing entry resulting from the Redirect-Host is to be used. The Diameter credit-control agent then forwards the CCR message directly to one of the hosts identified by the CCA message from the redirect agent. If the value of the Redirect-Host-Usage AVP is unequal to zero, all following messages are sent to the host specified in the Redirect- Host AVP until the time specified by the Redirect-Max-Cache-Time AVP is expired.
Diameter金融調整エージェントは、それとエンドユーザのDiameter金融調整サーバの間のエージェントが頼もしいかどうかをいつも知ることができるというわけではありません。 この場合、Diameter金融調整エージェントはエンドユーザホームドメインの金融調整サーバの分野へのDiameterルート設定Table([DIAMBASE]、セクション2.7で、定義される)にルーティングエントリーを持っていません。 Diameter金融調整エージェントは地元のRedirectエージェントにデフォルトルートを構成させることができます、そして、それは再直接のエージェントにCCRメッセージを向け直します。 そして地元のRedirectエージェントは再直接の通知(3006を結果でコード化してください、DIAMETER_REDIRECT_INDICATION)を金融調整エージェントに返します、Redirect-ホストから生じるルーティングエントリーによってどう使用されていることになっているかのDiameter金融調整サーバ情報(再直接のホストAVP)と情報(再直接のホスト用法AVP)と同様に。 そして、Diameter金融調整エージェントはCCRメッセージを再直接のエージェントから直接CCAメッセージによって特定されたホストのひとりに転送します。 Redirectホスト用法AVPの値がゼロに合わせるためには不平等であるなら、Redirectマックスキャッシュ時間AVPによって指定された時間が満期であるまでRedirectホストAVPで指定されたホストにすべての次のメッセージを送ります。
There are some authorization issues even with redirects. There may be attacks toward nodes that have been properly authorized, but that abuse their authorization or have been compromised. These issues are discussed more widely in [DIAMEAP], section 8.
そこ、いくつかの承認問題が同等である、向け直します。 攻撃は適切に認可されましたが、それらの承認を乱用するか、または感染されたノードに向かっているかもしれません。 [DIAMEAP]、セクション8でこれらの問題について、より広く議論します。
Hakala, et al. Standards Track [Page 90] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[90ページ]。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[DIAMBASE] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[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.
[3GPPCHARG]第3世代パートナーシッププロジェクト。 仕様書Group ServicesとSystem Aspects、Service局面。 そして、充電、Billing、(リリース5)、3GPP TS22.115v。 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.
[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[NAI] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[NAI] AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[E164] Recommendation E.164/I.331 (05/97): The International
Public Telecommunication Numbering Plan. 1997.
[164E]の推薦E.164/I.331(05/97): 国際公共の電気通信付番プラン。 1997.
[CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List
of ITU-T Recommendation E.164 assigned country codes",
June 2000.
[CE164]は(05/1997): 「ITU-T Recommendation E.164のリストは国名略号を割り当てた」2000年6月のITU-T Recommendation E.164に補足となります。
[E212] Recommendation E.212 (11/98): The international
identification plan for mobile terminals and mobile
users. 1998.
[212E]の推薦E.212(11/98): 移動体端末とモバイルユーザのための国際的な識別プラン。 1998.
[CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List
of mobile country or geographical area codes", February
1999.
「[CE212]はITU-T推薦にE.212(11/1997)の補足となります」 1999年2月の「モバイル国か地理的な市外局番のリスト。」
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[IANA]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IPv4] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[IPv6Addr] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6Addr]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Hakala, et al. Standards Track [Page 91] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[91ページ]。
[ISO4217] Codes for the representation of currencies and funds,
International Standard ISO 4217,2001
通貨と基金の表現のための[ISO4217]コード、国際規格ISO4217、2001
[NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[NASREQ] カルフーンとP.とゾルンとG.とスペンス、D.とD.ミットン、「直径ネットワークアクセス・サーバーアプリケーション」、RFC4005、2005年8月。
[AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[AAATRANS]AbobaとB.とJ.木、「認証、承認、および会計(AAA)輸送プロフィール」、2003年6月のRFC3539。
[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[URL] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[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.
[RAD802.1X] コングドン、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.Roese、「ユーザサービス(半径)用法ガイドラインのIEEE 802.1Xのリモート認証ダイヤル」、RFC3580(2003年9月)。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html March 1997.
[EUI64]IEEE、「64ビットのグローバルな識別子(EUI-64)登録局のためのガイドライン」、1997年の http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html行進。
[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
[3GPPIMEI]第3世代パートナーシッププロジェクト。 仕様書Group Core NetworkとNumberingとアドレシングと識別、(リリース5)、3GPP TS、23.003 v。 5.8.0, 2003-12
15.2. Informative References
15.2. 有益な参照
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、「半径会計」、RFC2866、2000年6月。
[DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[DIAMMIP] カルフーンとP.とヨハンソンとT.とパーキンスとC.とヒラー、T.とP.マッキャン、「直径のモバイルIPv4アプリケーション」、RFC4004、2005年8月。
[DIAMEAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", Work in
Progress.
P.、ヒラー、T.、およびG.ゾルン、「直径拡張認証プロトコル(EAP)アプリケーション」という[DIAMEAP]Eronenは進行中で働いています。
[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.
[RFC3725] ローゼンバーグ、J.、ピーターソン、J.、Schulzrinne、H.、およびG.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。
Hakala, et al. Standards Track [Page 92] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[92ページ]。
16. Acknowledgements
16. 承認
The authors would like to thank Bernard Aboba, Jari Arkko, Robert Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, Christopher Richards, Juha Vallinen, and Mark Watson for their comments and suggestions.
作者は彼らのコメントと提案についてバーナードAboba、ヤリArkko、ロバートEkblad、パシEronen、ベニー・グスタファソン、ロバート・カールソン、アヴィLior、Pacoマリン、ユシMaki、ジェフ・マイヤー、アンNarhi、ジョンPrudhoe、クリストファー・リチャーズ、ユハVallinen、およびマーク・ワトソンに感謝したがっています。
Hakala, et al. Standards Track [Page 93] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[93ページ]。
Appendix A. Credit-Control Sequences
付録A.金融調整系列
A.1. Flow I
A.1。 流れ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 | |
| |<-------------------| |
NASエンドユーザ(CCクライアント)AAAサーバCCサーバ|(1)ユーザログオン|(2)AAは(CC AVPs)を要求します。| |------------------>|------------------->| | | | |(3)CCR(初期のCC AVPs)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (4)CCA(与えられたユニット)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(5)AA答え(与えられたユニット)| |(6)承諾されたアクセス| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、| : : : : | |(7)CCR(アップデート、中古の単位)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|(8)CCR| | | | (アップデート、中古の単位) | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(9)CCA(与えられたユニット)| |(10)CCA(与えられたユニット)<。------------------| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| : : : : | (Auth寿命は期限が切れます) | | | |(11) AAR(CC AVP)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (12) AAA| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| : : : : : : : : |(13) ユーザログオフ| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|(14)CCR、(用語、中古の単位)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|(15)CCR| | | | (用語、中古の単位) | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (16)CCA| | | (17)CCA| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(18)STR| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (19)STA| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure A.1: Flow I
A.1は計算します: 流れI
Hakala, et al. Standards Track [Page 94] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[94ページ]。
A credit-control flow for Network Access Services prepaid is shown in Figure A.1. The Diameter [NASREQ] is implemented in the Network Access Server (NAS). The focus of this flow is in the credit authorization.
Network Access Servicesにおける、前払いの金融調整流動は図A.1に示されます。 Diameter[NASREQ]はNetwork Access Server(NAS)で実装されます。 クレジット承認にはこの流れの焦点があります。
The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server. The credit-control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, as usual [NASREQ]. The home Diameter AAA server performs service- specific Authentication and Authorization, as usual. The home Diameter AAA server determines that the user is a prepaid user and notices from the Credit-Control AVP that the NAS has credit-control capabilities. It sends a Diameter Credit-Control-Request with CC- Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization (3) and to establish a credit-control session. (The home Diameter AAA server may forward service-specific AVPs received from the NAS as input for the rating process.) The Diameter credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account. The reserved quota is returned to the home Diameter AAA server in the Diameter Credit-Control-Answer (4). The home Diameter AAA server sends the reserved quota to the NAS in the Diameter AA-Answer (AAA). Upon successful AAA, the NAS starts the credit-control session and starts monitoring the granted units (5). The NAS grants access to the end user (6). At the expiry of the allocated quota, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the Home Diameter AAA server (7). This message contains the units used thus far. The home Diameter AAA server forwards the CCR to the Diameter credit-control server (8). The Diameter credit-control server debits the used units from the end user's account and allocates a new quota that is returned to the home Diameter AAA server in the Diameter Credit- Control-Answer (9). The message is forwarded to the NAS (10). During the ongoing credit-control session, the authorization lifetime expires, and the authorization/authentication client in the NAS performs service specific re-authorization to the home Diameter AAA server, as usual. The credit-control client populates the AAR with the Credit-Control AVP set to RE_AUTHORIZATION, indicating that the credit-control server shall not be contacted, as the credit authorization is controlled by the burning rate of the granted units (11). The home Diameter AAA server performs service-specific re- authorization as usual and returns the AA-Answer to the NAS (12). The end user logs off from the network (13). To debit the used units from the end user's account and to stop the credit-control session, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the home Diameter AAA server (14). The home Diameter AAA server forwards the CCR to the credit-control
ユーザはネットワーク(1)にログオンします。 Diameter NASはDiameter AA-要求(AAR)をホームDiameter AAAサーバに送ります。金融調整クライアントはAVPがCREDIT_AUTHORIZATIONに設定するCredit-コントロールでAARに居住します、そして、サービス特有のAVPsは含まれています、通常通りです[NASREQ]。 ホームDiameter AAAサーバは通常通りのサービスの特定のAuthenticationとAuthorizationを実行します。 ホームDiameter AAAサーバは、ユーザが前払いのユーザであることを決定して、Credit-コントロールAVPからNASには金融調整能力があるのに気付きます。 それは要求タイプがDiameter金融調整サーバへのINITIAL_REQUESTにクレジット承認(3)を実行して、金融調整セッションを確立するように設定するCCとのDiameter Creditコントロール要求を送ります。 (ホームDiameter AAAサーバは格付けのプロセスのために入力されるようにNASから受け取られたサービス特有のAVPsを進めるかもしれません。) Diameter金融調整サーバは、エンドユーザの勘定残高をチェックして、サービスを評定して、エンドユーザのアカウントからクレジットを予約します。 Diameter Creditコントロール答え(4)のホームDiameter AAAサーバに予約された割当てを返します。 ホームDiameter AAAサーバはDiameter AA-答え(AAA)で予約された割当てをNASに送ります。 NASはうまくいっているAAAを、金融調整セッションを始めて、与えられたユニット(5)をモニターし始めます。 NASはエンドユーザ(6)へのアクセスを承諾します。 割り当てられた割当ての満期に、NASはUPDATE_REQUESTに用意ができているCC要求タイプとのDiameter Creditコントロール要求をホームDiameter AAAサーバ(7)に送ります。 このメッセージはこれまでのところ使用されたユニットを含んでいます。 ホームDiameter AAAサーバはDiameter金融調整サーバ(8)にCCRを送ります。 Diameter金融調整サーバは、Diameter Creditコントロール答え(9)にエンドユーザのアカウントから中古の単位を借り方に記入して、ホームDiameter AAAサーバに返される新しい割当てを割り当てます。 NAS(10)にメッセージを転送します。 進行中の金融調整セッションの間、承認寿命は呼吸が絶えます、そして、NASの承認/認証クライアントはホームDiameter AAAサーバにサービスの特定の再承認を実行します、通常通りです。 金融調整クライアントはAVPがRE_AUTHORIZATIONに設定するCredit-コントロールでAARに居住します、金融調整サーバに連絡しないのを示して、クレジット承認が与えられたユニット(11)の燃焼率によって制御されるとき。 ホームDiameter AAAサーバは、通常通りのサービス特有の再承認を実行して、AA-答えをNAS(12)に返します。 エンドユーザはネットワーク(13)からログオフします。 エンドユーザのアカウントから中古の単位を借り方に記入して、金融調整セッションを中止するために、NASはTERMINATION_REQUESTに用意ができているCC要求タイプとのDiameter Creditコントロール要求をホームDiameter AAAサーバ(14)に送ります。 ホームDiameter AAAサーバはCCRを金融調整に送ります。
Hakala, et al. Standards Track [Page 95] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[95ページ]。
server (15). The Diameter credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the home Diameter AAA server (16). The home Diameter AAA server forwards the answer to the NAS (17). STR/STA takes place between the NAS and home Diameter AAA server, as usual (18-19).
サーバ(15)。 Diameter金融調整サーバは、ホームDiameter AAAサーバ(16)にDiameter Creditコントロール答えを送ることによって、セッション終了を承諾します。 ホームDiameter AAAサーバはNAS(17)の答えを進めます。 STR/STAは通常通りのNASとホームDiameter AAAサーバの間で行われます。(18-19)。
A.2. Flow II
A.2。 流れ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 () |
| |<-------------------------------------------|
| | | |
(CCクライアント)サーバBがサーバをCCする一口プロキシ/記録係AAA|(i) レジスタ| | | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|(ii) | | | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |認証| | | |承認| | | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(iii)200 OK| | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| : : : : |(1) 招待| : |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(2) CCR(初期の、そして、SIP特有のAVP)| | |------------------------------------------->| | |(3) CCA(与えられたユニット)| | |<-------------------------------------------| | |(4) 招待| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : : : : | |(5) CCR(アップデート、中古の単位)| | |------------------------------------------->| | |(6) CCA(与えられたユニット)| | |<-------------------------------------------| : : : : |(7) さようなら| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(8) さようなら| | | |---------------------------->| | | |(9) CCR(終了、中古の単位)| | |------------------------------------------->| | |(10) CCA()| | |<-------------------------------------------| | | | |
Figure A.2: Flow II
A.2は計算します: 流れII
Hakala, et al. Standards Track [Page 96] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[96ページ]。
This is an example of Diameter credit-control for SIP sessions. Although the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate, and the diagram is not by any means an attempt to define a service provider's SIP network. However, for the sake of this example, some assumptions are made below.
これはSIPセッションのためのDiameter金融調整に関する例です。 流れは、金融調整メッセージの用法を例証するのは焦点を合わせますが、SIPシグナリングは不正確です、そして、ダイヤグラムは決してサービスプロバイダーのSIPネットワークを定義する試みではありません。 しかしながら、この例のために、いくつかの仮定が以下でされます。
Typically, prepaid services based, for example, on time usage for SIP session require an entity in the service provider network to intercept all the requests within the SIP dialog in order to detect events, such as session establishment and session release, that are essential to perform credit-control operations with the credit- control server. Therefore, in this example, it is assumed that the SIP Proxy adds a Record-Route header in the initial SIP INVITE to make sure that all the future requests in the created dialog traverse through it (for the definitions of 'Record-Route' and 'dialog' please refer to [SIP]). Finally, the degree of credit-control measuring of the media by the proxy depends on the business model design used in setting up the end system and proxies in the SIP network.
通常、例えばSIPセッションのための時間用法に基づく前払いのサービスは、セッション設立やセッションリリースなどのクレジット制御サーバによる金融調整操作を実行するのに不可欠のイベントを検出するためにSIP対話の中ですべての要求を妨害するためにサービスプロバイダーネットワークで実体を必要とします; したがって、この例では、SIP Proxyが確実にそれを作成された対話における今後の要求がそれを通して横断するすべてにするように初期のSIP INVITEでRecord-ルートヘッダーを加える('記録的なルート'と'対話'の定義について、SIPを参照する)と思われます。 最終的に、プロキシによるメディアの金融調整測定の度合いはSIPネットワークでエンドシステムとプロキシをセットアップする際に使用されるビジネスモデルデザインに依存します。
The end user (SIP User Agent A) sends REGISTER with credentials (i). The SIP Proxy sends a request to the home AAA server to perform Multimedia authentication and authorization by using, for instance, Diameter Multimedia application (ii). The home AAA server checks that the credentials are correct and checks the user profile. Eventually, 200 OK response (iii) is sent to the UA. Note that the Authentication and Authorization is valid for the registration validity period duration (i.e., until re-registration is performed). Several SIP sessions may be established without re-authorization.
エンドユーザ(SIP UserエージェントA)は資格証明書(i)があるREGISTERを送ります。 SIP Proxyは、例えばDiameter Multimediaアプリケーション(ii)を使用することによってMultimedia認証と承認を実行するためにホームAAAサーバに要求を送ります。 ホームAAAサーバは、資格証明書が正しいのをチェックして、ユーザ・プロファイルをチェックします。 結局、200OK応答(iii)をUAに送ります。 登録有効期間持続時間に、AuthenticationとAuthorizationが有効であることに注意してください(すなわち、再登録が実行されるまで)。 いくつかのSIPセッションが再承認なしで確立されるかもしれません。
UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit- Control-Request (INITIAL_REQUEST) to the Diameter credit-control server (2). The Credit-Control-Request contains information obtained from the SIP signaling describing the requested service (e.g., calling party, called party, Session Description Protocol attributes). The Diameter credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account. The reserved quota is returned to the SIP Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. The media flows between them, and the SIP Proxy starts measuring the quota. At the expiry of the allocated quota, the SIP Proxy sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-control server (5). This message contains the units used thus far. The Diameter credit-control server debits the used units from the end user's account and allocates new credit that is returned to the SIP Proxy in the Diameter Credit-Control-Answer (6). The end user terminates the service by sending a BYE (7). The SIP Proxy
UA AはINVITE(1)を送ります。 SIP ProxyはDiameter Creditコントロール要求(INITIAL_REQUEST)をDiameter金融調整サーバ(2)に送ります。 Creditコントロール要求は要求されたサービス(例えばパーティー、Session記述プロトコル属性と呼ばれる起呼側)について説明しながら合図するSIPから得られた情報を含んでいます。 Diameter金融調整サーバは、エンドユーザの勘定残高をチェックして、サービスを評定して、エンドユーザのアカウントからクレジットを予約します。 Diameter Creditコントロール答え(3)のSIP Proxyに予約された割当てを返します。 SIP ProxyはUA B(4)にSIP INVITEを送ります。 ビーズはリング、およびB答えに電話をします。 それらと、割当てを測定するSIP Proxy始めの間のメディア流れ。 割り当てられた割当ての満期に、SIP ProxyはDiameter Creditコントロール要求(UPDATE_REQUEST)をDiameter金融調整サーバ(5)に送ります。 このメッセージはこれまでのところ使用されたユニットを含んでいます。 Diameter金融調整サーバは、Diameter Creditコントロール答え(6)にエンドユーザのアカウントから中古の単位を借り方に記入して、SIP Proxyに返される新しいクレジットを割り当てます。 エンドユーザは、BYE(7)を送ることによって、サービスを終えます。 一口プロキシ
Hakala, et al. Standards Track [Page 97] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[97ページ]。
forwards the BYE message to UA B (8) and sends a Diameter Credit- Control-Request (TERMINATION_REQUEST) to the credit-control server (9). The Diameter credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the SIP Proxy (10).
UA B(8)にBYEメッセージを転送して、Diameter Creditコントロール要求(TERMINATION_REQUEST)を金融調整サーバ(9)に送ります。 Diameter金融調整サーバは、Diameter Creditコントロール答えをSIP Proxy(10)に送ることによって、セッション終了を承諾します。
A.3. Flow III
A.3。 流れ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 | |
| |--------------->| |
| | | |
(CCクライアント)BがサーバをCCするMMSサーバ|(1) MMSを送ってください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(2) CCR(| | | イベント、DIRECT_DEBITING、MMSの特定のAVP)| | |-------------------------------->| | |(3) CCA(与えられたユニット)| | |<--------------------------------| |(4) MMS Ackを送ってください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(5) MMSに通知してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : : : : | |(6) MMSを検索してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(7) MMSを検索してください。| | | | Ack| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|
Figure A.3: Flow III
A.3は計算します: 流れIII
A credit-control flow for Multimedia Messaging Services is shown in Figure A.3. The sender is charged as soon as the messaging server successfully stores the message.
Multimediaメッセージサービスのための金融調整流動は図A.3に示されます。 メッセージングサーバが首尾よくメッセージを保存するとすぐに、送付者は請求されます。
The end user A sends a Multimedia Message (MMS) to the MMS server (1). The MMS server stores the message and sends a Diameter Credit- Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) to the Diameter credit-control server (2). The Credit-Control- Request contains information about the MMS message (e.g., size, recipient address, image coding type). The Diameter credit-control server checks the end user's account balance, rates the service, and debits the service from the end user's account. The granted quota is returned to the MMS server in the Diameter Credit-Control-Answer (3). The MMS server acknowledges the successful reception of the MMS message (4). The MMS Server notifies the recipient about the new MMS (5), and end user B retrieves the message from the MMS message store (6),(7).
エンドユーザAはMultimedia Message(MMS)をMMSサーバ(1)に送ります。 MMSサーバは、メッセージを保存して、Diameter Creditコントロール要求(Requested-動作DIRECT_DEBITINGとEVENT_REQUEST)をDiameter金融調整サーバ(2)に送ります。 Credit-コントロール要求はMMSメッセージ(例えば、サイズ、受取人アドレス、画像符号化タイプ)の情報を含んでいます。 Diameter金融調整サーバは、エンドユーザのアカウントからエンドユーザの勘定残高をチェックして、サービスを評定して、サービスを借り方に記入します。 Diameter Creditコントロール答え(3)のMMSサーバに与えられた割当てを返します。 MMSサーバはMMSメッセージ(4)のうまくいっているレセプションを承認します。 MMS Serverは新しいMMS(5)に関して受取人に通知します、そして、エンドユーザBはMMSメッセージ店(6)((7))からのメッセージを検索します。
Hakala, et al. Standards Track [Page 98] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[98ページ]。
A.4. Flow IV
A.4。 流れ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 | |
| |--------------->| |
| | | |
MMSサーバ内容サーバ(CCクライアント)B CCサーバ|(1) MMSを送ってください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(2) CCR(| | | イベント、CHECK_BALANCE、MMSの特定のAVP)| | |-------------------------------->| | |(3) CCA(十分な_クレジット)| | |<--------------------------------| |(4) MMS Ackを送ってください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(5) MMSに通知してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : : : : | |(6) MMSを検索してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(7) CCR(| | | イベント、DIRECT_DEBITING、MMSの特定のAVP)| | |-------------------------------->| | |(8) CCA(与えられたユニット)| | |<--------------------------------| | |(9) MMSを検索してください。| | | | Ack| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|
Figure A.4: Flow IV
A.4は計算します: 流れIV
This is an example of Diameter credit-control for direct debiting using the Multimedia Messaging Service environment. Although the flow focuses on illustrating the usage of credit-control messages, the MMS signaling is inaccurate, and the diagram is not by any means an attempt to define any service provider's MMS configuration or billing model.
これはマルチメディア・メッセージング・サービス環境を使用するダイレクト借り方のためのDiameter金融調整に関する例です。 流れは、金融調整メッセージの用法を例証するのは焦点を合わせますが、MMSシグナリングは不正確です、そして、ダイヤグラムは決してどんなサービスプロバイダーのMMS構成か支払いモデルも定義する試みではありません。
A credit-control flow for Multimedia Messaging Service is shown in Figure A.4. The recipient is charged at the message delivery.
マルチメディア・メッセージング・サービスのための金融調整流動は図A.4に示されます。 受取人はメッセージ配送のときに請求されます。
A content server sends a Multimedia Message (MMS) to the MMS server (1) that stores the message. The message recipient will be charged for the MMS message in this case. As there can be a substantially long time between the receipt of the message at the MMS server and the actual retrieval of the message, the MMS server does not establish any credit-control session to the Diameter credit-control server but performs first only a balance check (without any credit reservation) by sending a Diameter Credit-Control-Request
満足しているサーバはメッセージを保存するMMSサーバ(1)にMultimedia Message(MMS)を送ります。 メッセージ受取人はこの場合MMSメッセージのために請求されるでしょう。 MMSサーバにおけるメッセージの領収書とメッセージの実際の検索の間には、実質的に長い時間があって、MMSサーバは、どんな金融調整セッションもDiameter金融調整サーバに確立しませんが、Diameter Creditコントロール要求を送ることによって、最初に、バランスチェック(少しもクレジットの予約のない)だけを実行します。
Hakala, et al. Standards Track [Page 99] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[99ページ]。
(EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that end user B can cover the cost for the MMS (2). The Diameter credit- control server checks the end user's account balance and returns the answer to the MMS server in the Diameter Credit-Control-Answer (3). The MMS server acknowledges the successful reception of the MMS message (4). The MMS server notifies the recipient of the new MMS (5), and after some time end user B retrieves the message from the MMS message store (6). The MMS server sends a Diameter Credit- Control-Request (EVENT_REQUEST with Requested-Action: DIRECT_DEBITING) to the Diameter credit-control server (7). The Credit-Control-Request contains information about the MMS message (e.g., size, recipient address, coding type). The Diameter credit- control server checks the end user's account balance, rates the service, and debits the service from the end user's account. The granted quota is returned to the MMS server in the Diameter Credit- Control-Request (8). The MMS is transferred to end user B (9).
(Requested-動作CHECK_BALANCEとEVENT_REQUEST)そのエンドユーザBについて確かめるのはMMS(2)のために費用をまかなうことができます。 DiameterクレジットはDiameter Creditコントロール答え(3)でエンドユーザのアカウントがMMSサーバの答えのバランスをとっていて、返すサーバチェックを制御します。 MMSサーバはMMSメッセージ(4)のうまくいっているレセプションを承認します。 MMSサーバは新しいMMS(5)について受取人に通知します、そして、いつか後に、エンドユーザBはMMSメッセージ店(6)からのメッセージを検索します。 MMSサーバはDiameter Creditコントロール要求(Requested-動作があるEVENT_REQUEST: DIRECT_DEBITING)をDiameter金融調整サーバ(7)に送ります。 Creditコントロール要求はMMSメッセージ(例えば、サイズ、受取人アドレス、コード化タイプ)の情報を含んでいます。 Diameterクレジットはエンドユーザのアカウントからエンドユーザのアカウントがバランスをとるサーバチェックを制御して、サービスを評定して、サービスを借り方に記入します。 Diameter Creditコントロール要求(8)のMMSサーバに与えられた割当てを返します。 エンドユーザB(9)にMMSを移します。
Note that the transfer of the MMS message can take an extended time and can fail, in which case a recovery action is needed. The MMS server should return the already debited units to the user's account by using the REFUND action described in section 6.4.
MMSメッセージの転送が延ばされた時かかるかもしれなくて、失敗できて、その場合、回復動作が必要であることに注意してください。 MMSサーバは、セクション6.4で説明されたREFUND動作を使用することによって、既に借り方に記入されたユニットをユーザのアカウントに返すべきです。
A.5. Flow V
A.5。 流れ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 |<---------------| |
|<---------------| | |
コントローラのために(CCクライアント)B CCサーバをちびちび飲んでください。|(1)B(SDP)を招待してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(2) CCR(| | | イベント、PRICE_ENQUIRY、SIPの特定のAVPs)| | |-------------------------------->| | |(3) CCA(コスト情報)| | |<--------------------------------| | (4)メッセージ(URL)| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(5)HTTPは得られます。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(6)HTTPポスト| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|(7)(SDP)を招待してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| (8)200 OK| | | (9)200 OK| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
Figure A.5: Flow V
A.5は計算します: 流れV
Hakala, et al. Standards Track [Page 100] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[100ページ]。
This is an example of Diameter credit-control for SIP sessions. Although the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate, and the diagram is not by any means an attempt to define a service provider's SIP network.
これはSIPセッションのためのDiameter金融調整に関する例です。 流れは、金融調整メッセージの用法を例証するのは焦点を合わせますが、SIPシグナリングは不正確です、そして、ダイヤグラムは決してサービスプロバイダーのSIPネットワークを定義する試みではありません。
Figure A.5 is an example of Advice of Charge (AoC) service for SIP call. User A can be either a postpaid or prepaid subscriber using the AoC service. It is assumed that the SIP controller also has HTTP capabilities and delivers an interactive AoC web page with, for instance, the cost information, the details of the call derived from the SDP, and a button to accept/not accept the charges. (There may be many other ways to deliver AoC information; however, this flow focuses on the use of the credit-control messages.) The user has been authenticated and authorized prior to initiating the call and subscribed to AoC service.
図A.5はSIP呼び出しのためのCharge(AoC)サービスのAdviceに関する例です。 ユーザAはAoCサービスを利用している郵便前払いの、または、前払いの加入者であるかもしれません。 SIPコントローラが例えば、コスト情報でまた、HTTP能力を持って、対話的なAoCウェブページを提供すると思われます、SDPから得られた呼び出しの詳細、そして、/を受け入れるボタンは充電を受け入れません。 (情報をAoCに提供する他の多くの方法があるかもしれません; しかしながら、この流れは金融調整メッセージの使用に焦点を合わせます。) ユーザは、認証されて、呼び出しを開始する前に、権限を与えられて、AoCサービスに申し込まれました。
UA A sends an INVITE with SDP to B (1). The SIP controller determines that the user is subscribed to AoC service and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: PRICE_ENQUIRY) to the Diameter credit-control server (2). The Credit-Control-Request contains SIP specific AVPs derived from the SIP signaling, describing the requested service (e.g., calling party, called party, Session Description Protocol attributes). The Diameter credit-control server determines the cost of the service and returns the Credit-Control-Answer including the Cost-Information AVP (3). The SIP controller manufactures the AoC web page with information received in SIP signaling and with the cost information received from the credit-control server. Then it sends a SIP MESSAGE that contains a URL pointing to the AoC information web page (4). At the receipt of the SIP MESSAGE, A's UA automatically invokes the web browser that retrieves the AoC information (5). The user clicks on a proper button and accepts the charges (6). The SIP controller continues the session and sends the INVITE to the B party, which accepts the call (7,8,9).
UA AはSDPとINVITEをB(1)に送ります。 SIPコントローラは、ユーザがAoCサービスに申し込まれて、Diameter Creditコントロール要求(Requested-動作があるEVENT_REQUEST: PRICE_ENQUIRY)をDiameter金融調整サーバ(2)に送ると決心しています。 Creditコントロール要求はSIPシグナリングから得られたSIPの特定のAVPsを含んでいます、要求されたサービス(例えばパーティー、Session記述プロトコル属性と呼ばれる起呼側)について説明して。 Cost-情報AVP(3)を含んでいて、Diameter金融調整サーバは、サービスの費用を決定して、Creditコントロール答えを返します。 SIPコントローラはSIPシグナリングで情報を受け取っていて金融調整サーバからコスト情報を受け取っていてAoCウェブページを製造しています。次に、それで、URLを含むSIP MESSAGEはAoC情報ウェブページ(4)を示します。 SIP MESSAGEの領収書では、AのUAは自動的にAoC情報(5)を検索するウェブブラウザを呼び出します。 ユーザは、適切なボタンをクリックして、充電(6)を受け入れます。 SIPコントローラは、Bパーティーにセッションを続けて、INVITEを送ります。(そのパーティーは、呼び出し(7、8、9)を受け入れます)。
Hakala, et al. Standards Track [Page 101] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[101ページ]。
A.6. Flow VI
A.6。 流れ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 | |
|<-----------------------| |
ゲーミングサーバエンドユーザ(CCクライアント)CCサーバ| (1)サービス配送| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : : : : : : | |(2)CCR、(イベント(還付)は要求しました|、| サービスユニット、サービスパラメタインフォメーション)| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| (3)CCA(コスト情報)| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| (4)通知| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure A.6: Flow VI
A.6は計算します: 流れVI
Figure A.6 illustrates a credit-control flow for the REFUND case. It is assumed that there is a trusted relationship and secure connection between the Gaming server and the Diameter credit-control server. The end user may be a prepaid subscriber or a postpaid subscriber.
図A.6はREFUNDケースのために金融調整流動を例証します。 GamingサーバとDiameter金融調整サーバとの信じられた関係と安全な関係があると思われます。エンドユーザは、前払いの加入者か郵便前払いの加入者であるかもしれません。
While the end user is playing the game (1), she enters a new level that entitles her to a bonus. The Gaming server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: REFUND_ACCOUNT) to the Diameter credit-control server (2). The Credit-Control-Request Request contains the Requested-Service-Unit AVP with the CC-Service-Specific-Units containing the number of points the user just won. The Service-Parameter-Info AVP is also included in the request and specifies the service event to be rated (e.g., Tetris Bonus). From information received, the Diameter credit-control server determines the amount to be credited, refunds the user's account, and returns the Credit-Control-Answer, including the Cost-Information AVP (3). The Cost-Information indicates the credited amount. At the first opportunity, the Gaming server notifies the end user of the credited amount (4).
エンドユーザがゲーム(1)をしている間、彼女は彼女にボーナスの権利を与える新しいレベルを入れます。 GamingサーバはDiameter Creditコントロール要求(Requested-動作があるEVENT_REQUEST: REFUND_ACCOUNT)をDiameter金融調整サーバ(2)に送ります。 Creditコントロール要求RequestはCCのサービスの特定のユニットがユーザがただ勝ったポイントの数を含んでいるRequestedサービスユニットAVPを含んでいます。 ServiceパラメタインフォメーションAVPは、また、要求に含まれていて、(例えば、テトリスBonus)であると評定されるためにサービスイベントを指定します。 受け取られた情報から、Diameter金融調整サーバは、量が掛けられることを決定して、ユーザのアカウントを還付して、Creditコントロール答えを返します、Cost-情報AVP(3)を含んでいて。 Cost-情報は掛けられた量を示します。 最初の機会では、Gamingサーバは掛けられた量(4)についてエンドユーザに通知します。
Hakala, et al. Standards Track [Page 102] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[102ページ]。
A.7. Flow VII
A.7。 流れ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 | |
|<--------------|--------------------------->| |
一口コントローラは(CCクライアント)サーバB CCサーバにいっぱいに満たします。| | | | | | | (1) CCR(アップデート、中古の単位)| | | |------------------------------------------>| | | (2) CCA(最終的なユニットの、そして、再直接の)| | |<------------------------------------------| : : : : : : : : : : | | (3) CCR(アップデート、中古の単位)| | | |------------------------------------------>| | | (3a)(「保持」)を招待してください。| | | |--------------------------->| | | | | (4) CCA(正当性時間)| | |<------------------------------------------| | (5)招待| (6)招待| | | |<--------------|------------->| | | | (7)RTP| | | |..............................| | | | | (8)さようなら| | | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| (9)CCR(アップデート)| | | |------------------------------------------>| | | (10)CCA(与えられたユニットの)| | |<------------------------------------------| | (12)招待| (11)招待| | |<--------------|--------------------------->| |
Figure A.7: Flow VII
A.7は計算します: 流れVII
Figure A.7 is an example of the graceful service termination for a SIP call. It is assumed that the call is set up so that the controller is in the call as a B2BUA (Back to Back User Agent) performing third-party call control (3PCC). Note that the SIP signaling is inaccurate, as the focus of this flow is in the graceful service termination and credit-control authorization. The best practice for 3PCC is defined in [RFC3725].
図A.7はSIP呼び出しのための優雅なサービス終了に関する例です。 呼び出しがコントローラが呼び出し第三者呼び出しコントロール(3PCC)を実行しながらB2BUA(Back Userエージェントへの)として中であるようにセットアップされると思われます。 SIPシグナリングが不正確であることに注意してください、優雅なサービス終了と金融調整承認にこの流れの焦点があるとき。 3PCCに、最も良い習慣は[RFC3725]で定義されます。
The call is ongoing between users A and B; user A has a prepaid subscription. At the expiry of the allocated quota, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-control server (1). This message contains the units used thus far. The Diameter credit-control server debits the used units from the end user's account and allocates the final quota returned to the SIP controller in the Diameter Credit-Control-Answer (2). This message contains the Final-Unit-Indication AVP with the
呼び出しはユーザAとBの間で進行中です。 ユーザAには、前払いの購読があります。 割り当てられた割当ての満期に、SIPコントローラはDiameter Creditコントロール要求(UPDATE_REQUEST)をDiameter金融調整サーバ(1)に送ります。 このメッセージはこれまでのところ使用されたユニットを含んでいます。 Diameter金融調整サーバは、Diameter Creditコントロール答え(2)にエンドユーザのアカウントから中古の単位を借り方に記入して、SIPコントローラに返された最終的な割当てを割り当てます。 このメッセージはFinalユニット指示AVPを含んでいます。
Hakala, et al. Standards Track [Page 103] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[103ページ]。
Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to SIP URI, and the Redirect-Server-Address set to the Top-up server name (e.g., sip:sip-topup-server@domain.com). At the expiry of the final allocated quota, the SIP controller sends a Diameter Credit- Control-Request (UPDATE_REQUEST) to the Diameter credit-control server (3) and places the called party on "hold" by sending an INVITE with the appropriate connection address in the SDP (3a). The Credit-Control-Request message contains the units used thus far. The Diameter credit-control server debits the used units from the end user's account but does not make any credit reservation. The Credit-Control-Answer message, which contains the Validity-Time to supervise the graceful service termination, is returned to the SIP controller (4). The SIP controller establishes a SIP session between the prepaid user and the Top-up server (5, 6). The Top-up server plays an announcement and prompts the user to enter a credit card number and the amount of money to be used to replenish the account (7). The Top-up server validates the credit card number and replenishes the user's account (using some means outside the scope of this specification) and releases the SIP session (8). The SIP controller can now assume that communication between the prepaid user and the Top-up server took place. It sends a spontaneous Credit- Control-Request (UPDATE_REQUEST) to the Diameter credit-control server to check whether the account has been replenished (9). The Diameter credit-control server reserves credit from the end user's account and returns the reserved quota to the SIP controller in the Credit-Control-Answer (10). At this point, the SIP controller re- connects the caller and the called party (11,12).
最終的なユニット動作はREDIRECTにセットしました、そして、RedirectアドレスタイプはSIP URIにセットしました、そして、RedirectサーバアドレスはTop上がっているサーバー名(例えば、一口: sip-topup-server@domain.com )にセットしました。 SIPコントローラは、最終的な割り当てられた割当ての満期に、「成立」に適切な接続アドレスがSDPにある状態でINVITEを送ることによって、Diameter金融調整へのDiameter Creditコントロール要求(UPDATE_REQUEST)にサーバ(3)を行かせて、被呼者は場所に行きます。(3a)。 Creditコントロール要求メッセージはこれまでのところ使用されたユニットを含んでいます。 Diameter金融調整サーバは、エンドユーザのアカウントから中古の単位を借り方に記入しますが、どんなクレジットの予約もしません。 Creditコントロール答えメッセージ(優雅なサービス終了を監督するValidity-時間を含む)をSIPコントローラ(4)に返します。 SIPコントローラは前払いのユーザとTop上がっているサーバ(5、6)とのSIPセッションを確立します。 Top上がっているサーバは、発表をプレーして、ユーザがアカウント(7)を補給するのに使用されるためにクレジットカード番号と金額を入れるようにうながします。 Top上がっているサーバは、クレジットカード番号を有効にして、ユーザのアカウント(この仕様の範囲の外のいくつかの手段を使用する)を補給して、SIPセッション(8)をリリースします。 SIPコントローラは、現在、前払いのユーザとTop上がっているサーバとのコミュニケーションが行われたと仮定できます。 それはアカウントを補給したか否かに関係なく、チェックするDiameter金融調整サーバへの自然発生的なCreditコントロール要求(UPDATE_REQUEST)(9)を送ります。 Diameter金融調整サーバは、Creditコントロール答え(10)でエンドユーザのアカウントからクレジットを予約して、予約された割当てをSIPコントローラに返します。 ここに、SIPコントローラは訪問者と被呼者(11、12)に再接します。
Hakala, et al. Standards Track [Page 104] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[104ページ]。
A.8. Flow VIII
A.8。 流れ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)<------------------|
| |<-------------------| |
NAS先端起きていているCCエンドユーザ(CCクライアント)AAAサーバサーバサーバ|(1)ユーザログオン|(2)AAは(CC AVPs)を要求します。| | |------------------>|------------------->| | | | | |(3)CCR(初期のCC AVPs)| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(4)CCA(||||最終的なユニット、正当性時間)| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(5)AA答え(最終的なユニット、正当性時間)| |(6)株式会社アクセス| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 与えます。| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、|、| (7)TCP/HTTP| (8)TCP/HTTP| | |<----------------->|<----------------------------->| | | (9) アカウントを補給してください。| | |<------------------------------------------------->| | | | | (10)RAR| | |<-------------------|<-------------------| | | (11) RAA| | | |------------------->|------------------->| | |(12)CCR(アップデート)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|(13)CCR(アップデート)| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(14)CCA(与えられたユニット)| |(15)CCA(与えられたユニット)<。------------------| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure A.8: Flow VIII
A.8は計算します: 流れVIII
Figure A.8 is an example of the graceful service termination initiated when the first interrogation takes place because the user's account is empty. In this example, the credit-control server supports the server-initiated credit re-authorization. The Diameter [NASREQ] is implemented in the Network Access Server (NAS).
図A.8はユーザのアカウントが空であるので最初の査問が行われるとき開始された優雅なサービス終了に関する例です。 この例では、金融調整サーバはサーバで開始しているクレジット再承認をサポートします。 Diameter[NASREQ]はNetwork Access Server(NAS)で実装されます。
The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request to the home Diameter AAA server. The credit- control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service specific AVPs are included, as usual [NASREQ]. The home Diameter AAA server performs service specific Authentication and Authorization, as usual. The home Diameter AAA server determines that the user has a prepaid subscription and notices from the Credit-Control AVP that the NAS has credit-control capabilities. It sends a Diameter Credit-Control-
ユーザはネットワーク(1)にログオンします。 Diameter NASはホームDiameter AAAサーバにDiameter AA-要求を送ります。クレジットコントロールクライアントはAVPがCREDIT_AUTHORIZATIONに設定するCredit-コントロールでAARに居住します、そして、サービスの特定のAVPsは含まれています、通常通りです[NASREQ]。 ホームDiameter AAAサーバは通常通りのサービスの特定のAuthenticationとAuthorizationを実行します。 ホームDiameter AAAサーバは、ユーザには前払いの購読があることを決定して、Credit-コントロールAVPからNASに金融調整能力があるのに気付きます。 それがDiameter Credit-コントロールを送る、-
Hakala, et al. Standards Track [Page 105] RFC 4006 Diameter Credit-Control Application August 2005
Hakala、他 規格は直径金融調整アプリケーション2005年8月にRFC4006を追跡します[105ページ]。
Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization (3) and to establish a credit-control session. (The home Diameter AAA server may forward service specific AVPs received from the NAS as input for the rating process.) The Diameter credit-control server checks the end user's account balance, determines that the account cannot cover the cost of the service, and initiates the graceful service termination. The Credit-Control-Answer is returned to the home Diameter AAA server (4). This message contains the Final-Unit- Indication AVP and the Validity-Time AVP set to a reasonable amount of time to give the user a chance to replenish his/her account (e.g., 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit- Action set to REDIRECT, the Redirect-Address-Type set to URL, and the Redirect-Server-Address set to the HTTP Top-up server name. The home Diameter AAA server sends the received credit-control AVPs to the NAS in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts the credit-control session and immediately starts the graceful service termination, as instructed by the server. The NAS grants limited access to the user (6). The HTTP client software running in the user's device opens the transport connection redirected by the NAS to the Top-up server (7,8). The user is displayed an appropriate web page on which to enter the credit card number, and the amount of money to be used to replenish the account, and with a notification message that she is granted unlimited access if the replenishment operation will be successfully executed within the next, for example, 10 minutes. The Top-up server validates the credit card number and replenishes the user's account (using some means outside the scope of this specification)(9). After successful account top-up, the credit-control server sends a Re-Auth-Request message to the NAS (10). The NAS acknowledges the request by returning the Re-Auth- Answer message (11) and initiates the credit re-authorization by sending a Credit-Control-request (UPDATE_REQUEST) to the Diameter credit-control server (12,13).
Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization (3) and to establish a credit-control session. (The home Diameter AAA server may forward service specific AVPs received from the NAS as input for the rating process.) The Diameter credit-control server checks the end user's account balance, determines that the account cannot cover the cost of the service, and initiates the graceful service termination. The Credit-Control-Answer is returned to the home Diameter AAA server (4). This message contains the Final-Unit- Indication AVP and the Validity-Time AVP set to a reasonable amount of time to give the user a chance to replenish his/her account (e.g., 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit- Action set to REDIRECT, the Redirect-Address-Type set to URL, and the Redirect-Server-Address set to the HTTP Top-up server name. The home Diameter AAA server sends the received credit-control AVPs to the NAS in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts the credit-control session and immediately starts the graceful service termination, as instructed by the server. The NAS grants limited access to the user (6). The HTTP client software running in the user's device opens the transport connection redirected by the NAS to the Top-up server (7,8). The user is displayed an appropriate web page on which to enter the credit card number, and the amount of money to be used to replenish the account, and with a notification message that she is granted unlimited access if the replenishment operation will be successfully executed within the next, for example, 10 minutes. The Top-up server validates the credit card number and replenishes the user's account (using some means outside the scope of this specification)(9). After successful account top-up, the credit-control server sends a Re-Auth-Request message to the NAS (10). The NAS acknowledges the request by returning the Re-Auth- Answer message (11) and initiates the credit re-authorization by sending a Credit-Control-request (UPDATE_REQUEST) to the Diameter credit-control server (12,13).
The Diameter credit-control server reserves credit from the end user's account and returns the reserved quota to the NAS via the home Diameter AAA server in the Credit-Control-Answer (14,15). The NAS removes the restriction placed by the graceful service termination and starts monitoring the granted units.
The Diameter credit-control server reserves credit from the end user's account and returns the reserved quota to the NAS via the home Diameter AAA server in the Credit-Control-Answer (14,15). The NAS removes the restriction placed by the graceful service termination and starts monitoring the granted units.
Hakala, et al. Standards Track [Page 106] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 106] RFC 4006 Diameter Credit-Control Application August 2005
A.9. Flow IX
A.9. Flow IX
The Diameter credit-control application defines the Multiple- Services-Credit-Control AVP that can be used to support independent credit-control of multiple services in a single credit-control (sub-) session for service elements that have such capabilities. It is possible to request and allocate resources as a credit pool that is shared between services or rating groups.
The Diameter credit-control application defines the Multiple- Services-Credit-Control AVP that can be used to support independent credit-control of multiple services in a single credit-control (sub-) session for service elements that have such capabilities. It is possible to request and allocate resources as a credit pool that is shared between services or rating groups.
The flow example hereafter illustrates a usage scenario where the credit-control client and server support independent credit-control of multiple services, as defined in section 5.1.2. It is assumed that Service-Identifiers, Rating-Groups, and their associated parameters (e.g., IP 5-tuple) are locally configured in the service element or provisioned by an entity other than the credit-control server.
The flow example hereafter illustrates a usage scenario where the credit-control client and server support independent credit-control of multiple services, as defined in section 5.1.2. It is assumed that Service-Identifiers, Rating-Groups, and their associated parameters (e.g., IP 5-tuple) are locally configured in the service element or provisioned by an entity other than the credit-control server.
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) |
|------------------>| |
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) | |------------------>| |
Hakala, et al. Standards Track [Page 107] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 107] RFC 4006 Diameter Credit-Control Application August 2005
: : :
: : :
|(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))) |
| |<----------------------------------------|
: : :
: : :
: : : : : : |(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))) | | |<----------------------------------------| : : : : : :
Hakala, et al. Standards Track [Page 108] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 108] RFC 4006 Diameter Credit-Control Application August 2005
| +--------------+ | |
| |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) |
| |<----------------------------------------|
| +--------------+ | | | |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
Figure A.9: Flow example independent credit-control of multiple services in a credit-control (sub-)Session
The user logs on to the network (1). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization for the bearer service (e.g., Internet access service) and to establish a credit-control session (2). In this message, the credit-control client indicates support for independent credit-control of multiple services within the session by including the Multiple-Service-Indicator AVP. The Diameter credit-control server checks the end user's account balance, with rating information received from the client (i.e., Service-Id and access specific AVPs), rates the request, and reserves credit from the end user's account. Suppose that the server reserves $5 and determines that the cost is $1/MB. It then returns to the service element a Credit-Control- Answer message that includes the Multiple-Services-Credit-Control AVP
The user logs on to the network (1). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization for the bearer service (e.g., Internet access service) and to establish a credit-control session (2). In this message, the credit-control client indicates support for independent credit-control of multiple services within the session by including the Multiple-Service-Indicator AVP. The Diameter credit-control server checks the end user's account balance, with rating information received from the client (i.e., Service-Id and access specific AVPs), rates the request, and reserves credit from the end user's account. Suppose that the server reserves $5 and determines that the cost is $1/MB. It then returns to the service element a Credit-Control- Answer message that includes the Multiple-Services-Credit-Control AVP
Hakala, et al. Standards Track [Page 109] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 109] RFC 4006 Diameter Credit-Control Application August 2005
with a quota of 5MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (3).
with a quota of 5MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (3).
The user uses Service 1 (4). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server to perform credit authorization for service 1 (5). This message includes the Multiple-Services-Credit-Control AVP to request service units for Service 1 that belong to Rating- Group 1. The Diameter credit-control server determines that Service 1 draws credit resources from the same account as the access service (i.e., pool 1). It rates the request according to Service- Id/Rating-Group and updates the existing reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $10) and determines that the cost is $0.1/minute. The server authorizes the whole Rating-Group. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 50min. associated to the Rating-Group 1, to a multiplier value of 1, and to the Pool-Id 1 (6). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 100.
The user uses Service 1 (4). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server to perform credit authorization for service 1 (5). This message includes the Multiple-Services-Credit-Control AVP to request service units for Service 1 that belong to Rating- Group 1. The Diameter credit-control server determines that Service 1 draws credit resources from the same account as the access service (i.e., pool 1). It rates the request according to Service- Id/Rating-Group and updates the existing reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $10) and determines that the cost is $0.1/minute. The server authorizes the whole Rating-Group. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 50min. associated to the Rating-Group 1, to a multiplier value of 1, and to the Pool-Id 1 (6). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 100.
The user uses Service 2, which belongs to the authorized Rating- Group, 1 (7). Resources are then consumed from the pool 1.
The user uses Service 2, which belongs to the authorized Rating- Group, 1 (7). Resources are then consumed from the pool 1.
The user now requests Services 3 and 4 as well, which are not authorized (8). The service element sends a Diameter Credit- Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit authorization for Services 3 and 4 (9). This message includes two instances of the Multiple-Services-Credit-Control AVP to request service units for Service 3 that belong to Rating-Group 2 and for Service 4 that belong to Rating-Group 3. The Diameter credit-control server determines that Services 3 and 4 draw credit resources from another account (i.e., pool 2). It checks the end user's account balance and, according to Service-Ids/Rating-Groups information, rates the request. Then it reserves credit from pool 2.
The user now requests Services 3 and 4 as well, which are not authorized (8). The service element sends a Diameter Credit- Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit authorization for Services 3 and 4 (9). This message includes two instances of the Multiple-Services-Credit-Control AVP to request service units for Service 3 that belong to Rating-Group 2 and for Service 4 that belong to Rating-Group 3. The Diameter credit-control server determines that Services 3 and 4 draw credit resources from another account (i.e., pool 2). It checks the end user's account balance and, according to Service-Ids/Rating-Groups information, rates the request. Then it reserves credit from pool 2.
For example, the server reserves $5 and determines that Service 3 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes only Services 3 and 4. It returns to the service element a Credit- Control-Answer message that includes two instances of the Multiple- Services-Credit-Control AVP (10). One instance grants a quota of 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and to the Pool-Id 2. The other instance grants a quota of 5 MB associated to the Service-Id 4 to a multiplier value of 5 and to the Pool-Id 2.
For example, the server reserves $5 and determines that Service 3 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes only Services 3 and 4. It returns to the service element a Credit- Control-Answer message that includes two instances of the Multiple- Services-Credit-Control AVP (10). One instance grants a quota of 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and to the Pool-Id 2. The other instance grants a quota of 5 MB associated to the Service-Id 4 to a multiplier value of 5 and to the Pool-Id 2.
Hakala, et al. Standards Track [Page 110] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 110] RFC 4006 Diameter Credit-Control Application August 2005
The server also determines that pool 2 is exhausted and Service 4 is not allowed to continue after these units will be consumed. Therefore the Final-Unit-Indication AVP with action TERMINATE is associated to the Service-Id 4. The client calculates the total amount of resources that can be used for pool 2 according the received quotas and multipliers, which gives S for Pool 2 = 50.
The server also determines that pool 2 is exhausted and Service 4 is not allowed to continue after these units will be consumed. Therefore the Final-Unit-Indication AVP with action TERMINATE is associated to the Service-Id 4. The client calculates the total amount of resources that can be used for pool 2 according the received quotas and multipliers, which gives S for Pool 2 = 50.
The Validity-Time for the access service expires. The service element sends a Credit-Control-Request message to the server in order to perform credit re-authorization for Service-Id (access) (11). This message carries one instance of the Multiple-Services-Credit- Control AVP that includes the units used by this service. Suppose that the total amount of used units is 4MB. The client adjusts the total amount of resources for pool 1 accordingly, which gives S for Pool 1 = 60.
The Validity-Time for the access service expires. The service element sends a Credit-Control-Request message to the server in order to perform credit re-authorization for Service-Id (access) (11). This message carries one instance of the Multiple-Services-Credit- Control AVP that includes the units used by this service. Suppose that the total amount of used units is 4MB. The client adjusts the total amount of resources for pool 1 accordingly, which gives S for Pool 1 = 60.
The server deducts $4 from the user's account and updates the reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $11) and already knows the cost of the Service-Id (access), which is $1/MB. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5 MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (12). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 110.
The server deducts $4 from the user's account and updates the reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $11) and already knows the cost of the Service-Id (access), which is $1/MB. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5 MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (12). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 110.
Services 3 and 4 consume the total amount of pool 2 credit resources (i.e., C1*2 + C2*5 >= S). The service element immediately starts the TERMINATE action concerning Service 4 and sends a Credit-Control- Request message with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit re-authorization for Service 3 (13). This message contains two instances of the Multiple-Services-Credit-Control AVP to report the units used by Services 3 and 4. The server deducts the last $5 from the user's account (pool 2) and returns the answer with Result-Code 4011 in the Multiple-Services-Credit-Control AVP to indicate that Service 3 can continue without credit-control (14).
Services 3 and 4 consume the total amount of pool 2 credit resources (i.e., C1*2 + C2*5 >= S). The service element immediately starts the TERMINATE action concerning Service 4 and sends a Credit-Control- Request message with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit re-authorization for Service 3 (13). This message contains two instances of the Multiple-Services-Credit-Control AVP to report the units used by Services 3 and 4. The server deducts the last $5 from the user's account (pool 2) and returns the answer with Result-Code 4011 in the Multiple-Services-Credit-Control AVP to indicate that Service 3 can continue without credit-control (14).
The end user logs off from the network (15). To debit the used units from the end user's account and to stop the credit-control session, the service element sends a Diameter Credit-Control-Request with CC- Request-Type set to TERMINATION_REQUEST to the credit-control server (16). This message contains the units consumed by each of the used services in multiple instances of the Multiple-Services-Credit- Control AVP. The used units are associated with the relevant Service-Identifier and Rating-Group. The Diameter credit-control
The end user logs off from the network (15). To debit the used units from the end user's account and to stop the credit-control session, the service element sends a Diameter Credit-Control-Request with CC- Request-Type set to TERMINATION_REQUEST to the credit-control server (16). This message contains the units consumed by each of the used services in multiple instances of the Multiple-Services-Credit- Control AVP. The used units are associated with the relevant Service-Identifier and Rating-Group. The Diameter credit-control
Hakala, et al. Standards Track [Page 111] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 111] RFC 4006 Diameter Credit-Control Application August 2005
server debits the used units to the user's account (Pool 1) and acknowledges the session termination by sending a Diameter Credit- Control-Answer to the service element (17).
server debits the used units to the user's account (Pool 1) and acknowledges the session termination by sending a Diameter Credit- Control-Answer to the service element (17).
Authors' Addresses
Authors' Addresses
Harri Hakala Oy L M Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland
Harri Hakala Oy L M Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland
Phone: +358 2 265 3722 EMail: Harri.Hakala@ericsson.com
Phone: +358 2 265 3722 EMail: Harri.Hakala@ericsson.com
Leena Mattila Oy L M Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland
Leena Mattila Oy L M Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland
Phone: +358 2 265 3731 EMail: Leena.Mattila@ericsson.com
Phone: +358 2 265 3731 EMail: Leena.Mattila@ericsson.com
Juha-Pekka Koskinen Nokia Networks Hatanpaanvaltatie 30 33100 Tampere Finland
Juha-Pekka Koskinen Nokia Networks Hatanpaanvaltatie 30 33100 Tampere Finland
Phone: +358 7180 74027 EMail: juha-pekka.koskinen@nokia.com
Phone: +358 7180 74027 EMail: juha-pekka.koskinen@nokia.com
Hakala, et al. Standards Track [Page 112] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 112] RFC 4006 Diameter Credit-Control Application August 2005
Marco Stura Nokia Networks Hiomotie 32 00380 Helsinki Finland
Marco Stura Nokia Networks Hiomotie 32 00380 Helsinki Finland
Phone: +358 7180 64308 EMail: marco.stura@nokia.com
Phone: +358 7180 64308 EMail: marco.stura@nokia.com
John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland
John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland
Phone: +358 50 483 642 EMail: John.Loughney@nokia.com
Phone: +358 50 483 642 EMail: John.Loughney@nokia.com
Hakala, et al. Standards Track [Page 113] RFC 4006 Diameter Credit-Control Application August 2005
Hakala, et al. Standards Track [Page 113] RFC 4006 Diameter Credit-Control Application August 2005
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2005).
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Hakala, et al. Standards Track [Page 114]
Hakala, et al. Standards Track [Page 114]
一覧
スポンサーリンク
