[要約] RFC 8506は、Diameter Credit-Control Applicationの仕様を定義しています。この仕様の目的は、Diameterプロトコルを使用してクレジット制御を行うための標準化された方法を提供することです。
Internet Engineering Task Force (IETF) L. Bertz, Ed.
Request for Comments: 8506 Sprint
Obsoletes: 4006 D. Dolson, Ed.
Category: Standards Track Y. Lifshitz, Ed.
ISSN: 2070-1721 Sandvine
March 2019
Diameter Credit-Control Application
Diameterクレジットコントロールアプリケーション
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. The Diameter Credit-Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations.
このドキュメントでは、ネットワークアクセス、Session Initiation Protocol（SIP）サービス、メッセージングサービス、ダウンロードサービスなどのさまざまなエンドユーザーサービスのリアルタイムクレジット制御を実装するために使用できるDiameterアプリケーションを指定します。このドキュメントで定義されているDiameter Credit-ControlアプリケーションはRFC 4006を廃止し、すべての新しいDiameter Credit-Controlアプリケーション実装でサポートされる必要があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8506.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8506で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................6
1.1. Requirements Language ......................................7
1.2. Terminology ................................................7
1.3. Advertising Application Support ............................9
2. Architecture Models .............................................9
3. Credit-Control Messages ........................................11
3.1. Credit-Control-Request (CCR) Command ......................11
3.2. Credit-Control-Answer (CCA) Command .......................12
4. Credit-Control Application Overview ............................13
4.1. Service-Specific Rating Input and Interoperability ........14
4.1.1. Specifying Rating Input AVPs .......................15
4.1.2. Service-Specific Documentation .....................16
4.1.3. Handling of Unsupported/Incorrect Rating Input .....16
4.1.4. RADIUS Vendor-Specific Rating Attributes ...........17
5. Session-Based Credit-Control ...................................17
5.1. General Principles ........................................17
5.1.1. Basic Support for Tariff Time Change ...............18
5.1.2. Credit-Control for Multiple Services within
a (Sub-)Session ....................................19
5.2. First Interrogation .......................................23
5.2.1. First Interrogation after Authorization and
Authentication .....................................25
5.2.2. First Interrogation Included with
Authorization Messages .............................27
5.3. Intermediate Interrogation ................................29
5.4. Final Interrogation .......................................31
5.5. Server-Initiated Credit Re-authorization ..................32
5.6. Graceful Service Termination ..............................34
5.6.1. Terminate Action ...................................37
5.6.2. Redirect Action ....................................38
5.6.3. Restrict Access Action .............................40
5.6.4. Usage of the Server-Initiated Credit
Re-authorization ...................................41
5.7. Failure Procedures ........................................41
6. One-Time Event .................................................44
6.1. Service Price Inquiry .....................................45
6.2. Balance Checks ............................................46
6.3. Direct Debiting ...........................................46
6.4. Refunds ...................................................47
6.5. Failure Procedure .........................................48
7. Credit-Control Application State Machines ......................50
8. Credit-Control AVPs ............................................59
8.1. CC-Correlation-Id AVP .....................................61
8.2. CC-Request-Number AVP .....................................62
8.3. CC-Request-Type AVP .......................................62
8.4. CC-Session-Failover AVP ...................................63
8.5. CC-Sub-Session-Id AVP .....................................64
8.6. Check-Balance-Result AVP ..................................64
8.7. Cost-Information AVP ......................................64
8.8. Unit-Value AVP ............................................65
8.9. Exponent AVP ..............................................65
8.10. Value-Digits AVP .........................................66
8.11. Currency-Code AVP ........................................66
8.12. Cost-Unit AVP ............................................66
8.13. Credit-Control AVP .......................................66
8.14. Credit-Control-Failure-Handling AVP (CCFH) ...............67
8.15. Direct-Debiting-Failure-Handling AVP (DDFH) ..............68
8.16. Multiple-Services-Credit-Control AVP .....................68
8.17. Granted-Service-Unit AVP .................................70
8.18. Requested-Service-Unit AVP ...............................71
8.19. Used-Service-Unit AVP ....................................71
8.20. Tariff-Time-Change AVP ...................................72
8.21. CC-Time AVP ..............................................72
8.22. CC-Money AVP .............................................72
8.23. CC-Total-Octets AVP ......................................72
8.24. CC-Input-Octets AVP ......................................72
8.25. CC-Output-Octets AVP .....................................73
8.26. CC-Service-Specific-Units AVP ............................73
8.27. Tariff-Change-Usage AVP ..................................73
8.28. Service-Identifier AVP ...................................74
8.29. Rating-Group AVP .........................................74
8.30. G-S-U-Pool-Reference AVP .................................74
8.31. G-S-U-Pool-Identifier AVP ................................75
8.32. CC-Unit-Type AVP .........................................75
8.33. Validity-Time AVP ........................................75
8.34. Final-Unit-Indication AVP ................................76
8.35. Final-Unit-Action AVP ....................................77
8.36. Restriction-Filter-Rule AVP ..............................78
8.37. Redirect-Server AVP ......................................78
8.38. Redirect-Address-Type AVP ................................79
8.39. Redirect-Server-Address AVP ..............................79
8.40. Multiple-Services-Indicator AVP ..........................80
8.41. Requested-Action AVP .....................................80
8.42. Service-Context-Id AVP ...................................81
8.43. Service-Parameter-Info AVP ...............................82
8.44. Service-Parameter-Type AVP ...............................82
8.45. Service-Parameter-Value AVP ..............................83
8.46. Subscription-Id AVP ......................................83
8.47. Subscription-Id-Type AVP .................................83
8.48. Subscription-Id-Data AVP .................................84
8.49. User-Equipment-Info AVP ..................................84
8.50. User-Equipment-Info-Type AVP .............................84
8.51. User-Equipment-Info-Value AVP ............................85
8.52. User-Equipment-Info-Extension AVP ........................85
8.53. User-Equipment-Info-IMEISV AVP ...........................86
8.54. User-Equipment-Info-MAC AVP ..............................86
8.55. User-Equipment-Info-EUI64 AVP ............................86
8.56. User-Equipment-Info-ModifiedEUI64 AVP ....................86
8.57. User-Equipment-Info-IMEI AVP .............................86
8.58. Subscription-Id-Extension AVP ............................87
8.59. Subscription-Id-E164 AVP .................................87
8.60. Subscription-Id-IMSI AVP .................................87
8.61. Subscription-Id-SIP-URI AVP ..............................88
8.62. Subscription-Id-NAI AVP ..................................88
8.63. Subscription-Id-Private AVP ..............................88
8.64. Redirect-Server-Extension AVP ............................88
8.65. Redirect-Address-IPAddress AVP ...........................89
8.66. Redirect-Address-URL AVP .................................89
8.67. Redirect-Address-SIP-URI AVP .............................89
8.68. QoS-Final-Unit-Indication AVP ............................89
9. Result-Code AVP Values .........................................91
9.1. Transient Failures ........................................91
9.2. Permanent Failures ........................................92
10. AVP Occurrence Table ..........................................92
10.1. Credit-Control AVP Table .................................93
10.2. Re-Auth-Request/Re-Auth-Answer AVP Table .................94
11. RADIUS/Diameter Credit-Control Interworking Model .............94
12. IANA Considerations ...........................................97
12.1. Application Identifier ...................................97
12.2. Command Codes ............................................97
12.3. AVP Codes ................................................97
12.4. Result-Code AVP Values ...................................98
12.5. CC-Request-Type AVP ......................................98
12.6. CC-Session-Failover AVP ..................................98
12.7. CC-Unit-Type AVP .........................................99
12.8. Check-Balance-Result AVP .................................99
12.9. Credit-Control AVP .......................................99
12.10. Credit-Control-Failure-Handling AVP .....................99
12.11. Direct-Debiting-Failure-Handling AVP ....................99
12.12. Final-Unit-Action AVP ...................................99
12.13. Multiple-Services-Indicator AVP ........................100
12.14. Redirect-Address-Type AVP ..............................100
12.15. Requested-Action AVP ...................................100
12.16. Subscription-Id-Type AVP ...............................100
12.17. Tariff-Change-Usage AVP ................................100
12.18. User-Equipment-Info-Type AVP ...........................100
13. Parameters Related to the Credit-Control Application .........101
14. Security Considerations ......................................101
14.1. Direct Connection with Redirects ........................102
14.2. Application-Level Redirects .............................103
15. Privacy Considerations .......................................104
15.1. Privacy-Sensitive AVPs ..................................104
15.2. Data Minimization .......................................106
15.3. Diameter Agents .........................................107
16. References ...................................................107
16.1. Normative References ....................................107
16.2. Informative References ..................................110
Appendix A. Credit-Control Sequences .............................111
A.1. Flow I ....................................................111
A.2. Flow II ...................................................113
A.3. Flow III ..................................................116
A.4. Flow IV ...................................................117
A.5. Flow V ....................................................119
A.6. Flow VI ...................................................120
A.7. Flow VII ..................................................121
A.8. Flow VIII .................................................123
A.9. Flow IX ...................................................124
Acknowledgements .................................................130
Authors' Addresses ...............................................130
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. ("Credit-control" is sometimes abbreviated as "CC" in figures and tables throughout this document.) The Diameter Credit-Control application as defined in this document obsoletes [RFC4006], and it must be supported by all new Diameter Credit-Control application implementations. This document provides a general solution to real-time cost and credit-control.
このドキュメントでは、ネットワークアクセス、Session Initiation Protocol（SIP）サービス、メッセージングサービス、ダウンロードサービスなどのさまざまなエンドユーザーサービスのリアルタイムクレジット制御を実装するために使用できるDiameterアプリケーションを指定します。 （「クレジットコントロール」は、このドキュメント全体の図と表では「CC」と略される場合があります。）このドキュメントで定義されているDiameterクレジットコントロールアプリケーションは廃止され[RFC4006]、すべての新しいDiameterクレジットコントロールでサポートされている必要があります。アプリケーションの実装。このドキュメントは、リアルタイムのコストと信用管理に対する一般的なソリューションを提供します。
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 mobile networks, additional functionality is required beyond that specified in the Diameter base protocol [RFC6733]. For example, the 3GPP charging and billing requirements document [TGPPCHARG] states 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基本プロトコル[RFC6733]で指定されている以上の追加機能が必要です。たとえば、3GPPの課金と請求の要件に関するドキュメント[TGPPCHARG]には、アプリケーションがサービス情報をリアルタイムで評価できる必要があると記載されています。さらに、要求されたサービスを開始する前に、エンドユーザーのアカウントがサービスのカバレッジを提供していることを確認する必要があります。アカウントが使い果たされるか期限切れになると、ユーザーは追加の課金対象イベントをコンパイルする機能を拒否される必要があります。
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アプリケーションはサービス固有の認証を提供し、プリペイドユーザーのクレジット認証は提供しません。クレジット認証は一般的であり、プリペイドサービスをサポートするために必要なすべてのサービス環境に適用されます。
To fulfill these requirements, it is necessary to facilitate credit-control communication between the network element providing the service (e.g., Network Access Server (NAS), SIP Proxy, Application Server) and a credit-control server.
これらの要件を満たすには、サービスを提供するネットワーク要素（ネットワークアクセスサーバー（NAS）、SIPプロキシ、アプリケーションサーバーなど）とクレジット制御サーバーの間のクレジット制御通信を促進する必要があります。
The scope of this specification is credit authorization. Service-specific authorization and authentication are out of scope.
この仕様の範囲はクレジット認証です。サービス固有の承認と認証は範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
AAA: Authentication, Authorization, and Accounting.
AAA：認証、承認、およびアカウンティング。
AA-Answer: "AA-Answer" generically refers to a service-specific authorization and authentication answer. AA-Answer commands are defined in service-specific authorization applications, e.g., [RFC7155] [RFC4004].
AA-Answer：「AA-Answer」は、一般にサービス固有の承認と認証の回答を指します。 AA-Answerコマンドは、サービス固有の承認アプリケーションで定義されています（例：[RFC7155] [RFC4004]）。
AA-Request: "AA-Request" generically refers to a service-specific authorization and authentication request. AA-Request commands are defined in service-specific authorization applications, e.g., [RFC7155] [RFC4004].
AA-Request：「AA-Request」は一般的に、サービス固有の許可および認証要求を指します。 AA-Requestコマンドは、サービス固有の承認アプリケーションで定義されています（例：[RFC7155] [RFC4004]）。
Credit-control: "Credit-control" is a mechanism that directly interacts in real time with an account and controls or monitors the charges related to service usage. Credit-control is a process of (1) checking whether or not credit is available, (2) credit reservation, (3) deduction of credit from the end-user account when service is completed, and (4) refunding of reserved credit that is not used.
クレジットコントロール：「クレジットコントロール」は、アカウントとリアルタイムで直接対話し、サービスの使用に関連する料金を制御または監視するメカニズムです。クレジット管理とは、（1）クレジットが利用可能かどうかを確認するプロセス、（2）クレジットの予約、（3）サービスの完了時にエンドユーザーアカウントからクレジットを差し引く、（4）予約されたクレジットの払い戻しのプロセスです。使用されていません。
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 real time, for the 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サーバー：Diameter Credit-Controlサーバーは、プリペイドサーバーとして機能し、リアルタイムの評価とクレジット管理を実行します。これはホームドメインにあり、サービスイベントがエンドユーザーに配信される前の価格決定とクレジット管理のために、Service ElementsまたはDiameter AAAサーバーによってリアルタイムでアクセスされます。また、ビジネスサポートシステムと相互作用する場合もあります。
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 the credit-control server.
Diameterクレジットコントロールクライアント：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 Credit-Controlクライアントは問い合わせを使用して、セッションベースのクレジット制御プロセスを開始します。与信管理プロセス中に、使用された割り当て量を報告し、新しい割り当て量を要求するために使用されます。問い合わせは、要求/応答トランザクションにマッピングされます。
One-time event: A charging transaction session comprising a single request and single response.
ワンタイムイベント：単一の要求と単一の応答で構成される課金トランザクションセッション。
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., a 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 Service Elements include NASs, SIP Proxies, and Application Servers such as messaging servers, content servers, and gaming servers.
サービス要素：エンドユーザーにサービスを提供するネットワーク要素。サービス要素には、Diameterクレジット制御クライアント、またはサービス要素に代わってクレジット制御クライアントとして機能できる別のエンティティ（RADIUS AAAサーバーなど）を含めることができます。後者の場合、サービス要素とDiameter Credit-Controlクライアント間のインターフェースは、この仕様の範囲外です。サービス要素の例には、NAS、SIPプロキシ、およびメッセージングサーバー、コンテンツサーバー、ゲームサーバーなどのアプリケーションサーバーが含まれます。
Service event: An event relating to a service provided to the end user.
サービスイベント：エンドユーザーに提供されるサービスに関連するイベント。
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. Intermediate interrogations (if any) may be needed to request a 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.
セッションベースの信用管理：最初の質問、可能性のある中間者、最終的な質問など、いくつかの質問を利用する信用管理プロセス。最初の問い合わせは、ユーザーのアカウントからお金を予約し、プロセスを開始するために使用されます。サービスが提供されている間に新しいクォータを要求するには、中間の問い合わせ（存在する場合）が必要になる場合があります。最後の問い合わせは、プロセスを終了するために使用されます。クレジット管理サーバーは、セッションベースのクレジット管理のためにセッション状態を維持するために必要です。
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 commands [RFC6733].
この仕様に準拠するDiameterノードは、Capabilities-Exchange-RequestおよびCapabilities-Exchange-AnswerコマンドのAuth-Application-Idに値4を含めることでサポートをアドバタイズする必要があります[RFC6733]。
The current accounting models specified in the RADIUS accounting and Diameter base specifications [RFC2866] [RFC6733] are not sufficient for real-time credit-control, where creditworthiness is to be determined prior to service initiation. Also, the existing Diameter authorization applications [RFC7155] [RFC4004] only provide service authorization; they 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: the Diameter Credit-Control server. The Diameter Credit-Control server is the entity responsible for credit authorization for prepaid subscribers.
RADIUSアカウンティングおよびDiameter基本仕様[RFC2866] [RFC6733]で指定されている現在のアカウンティングモデルは、サービスの開始前に信用力を決定する必要があるリアルタイムの信用管理には不十分です。また、既存のDiameter認可アプリケーション[RFC7155] [RFC4004]はサービス認可のみを提供します。彼らはプリペイドユーザーにクレジット認証を提供しません。リアルタイムのクレジットコントロールをサポートするには、AAAインフラストラクチャに新しいタイプのサーバー、Diameter Credit-Controlサーバーが必要です。 Diameter Credit-Controlサーバーは、プリペイドサブスクライバーのクレジット認証を担当するエンティティです。
A Service Element may authenticate and authorize the end user with the AAA server by using AAA protocols, e.g., RADIUS or the Diameter base protocol (possibly extended via a Diameter application).
サービスエレメントは、AAAプロトコル（RADIUSなど）またはDiameterベースプロトコル（Diameterアプリケーションを介して拡張される可能性がある）を使用して、AAAサーバーでエンドユーザーを認証および承認します。
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.
リアルタイムのクレジットコントロールが必要な場合、クレジットコントロールクライアントは、考えられるサービスイベントに関する情報をクレジットコントロールサーバーに連絡します。クレジット制御プロセスは、潜在的な料金を決定し、エンドユーザーのアカウントの残高が、提供されるサービスのコストをカバーするのに十分であるかどうかを確認するために実行されます。
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 a AAA server. A Business Support System is usually deployed; at a minimum, it includes 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 [RFC6733] with the Diameter Credit-Control application.
図1は、Diameter Credit-Controlクライアント、Diameter Credit-Controlサーバー、およびAAAサーバーが組み込まれたサービス要素で構成される典型的なクレジット制御アーキテクチャーを示しています。通常、ビジネスサポートシステムが展開されます。少なくとも、請求機能が含まれています。このアーキテクチャモデルのクレジットコントロールサーバーとAAAサーバーは論理エンティティです。実際の構成では、それらを単一のホストに組み合わせることができます。クレジット制御プロトコルは、Diameterクレジット制御アプリケーションを備えたDiameter基本プロトコル[RFC6733]です。
When an end user requests services such as SIP or messaging, the request is typically forwarded to a Service Element (e.g., a SIP Proxy) in the user's home realm as defined in [RFC6733]. In some cases, it might be possible that the Service Element in the local realm [RFC6733] can offer services to the end user; however, a commercial agreement must exist between the local realm and the home realm. Network access is an example of a service offered in the local realm where the NAS, through a AAA infrastructure, authenticates and authorizes the user with the user's home network.
エンドユーザーがSIPやメッセージングなどのサービスを要求すると、その要求は通常、[RFC6733]で定義されているユーザーのホームレルムのサービス要素（SIPプロキシなど）に転送されます。場合によっては、ローカルレルムのサービス要素[RFC6733]がエンドユーザーにサービスを提供できる可能性があります。ただし、ローカルレルムとホームレルムの間に商業協定が存在する必要があります。ネットワークアクセスは、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 |
+----------+
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 entity 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 is implementation specific and is out of scope for this specification.
冗長性とロードバランシングのために、システムに複数のクレジットコントロールサーバーを配置できます。システムには個別の評価サーバーを含めることもでき、アカウントは中央データベースに配置できます。エンドユーザーのアカウントが同じサービスイベントに対して複数回引き落とされたりクレジットされたりしないようにするために、信用管理システムの1つのエンティティのみが重複検出を実行する必要があります。サーバーとアカウントマネージャーの間でメッセージを中継するためのシステム内部インターフェイスが存在する場合があります。ただし、与信管理システムとそのインターフェースの詳細なアーキテクチャーは実装固有であり、この仕様の範囲外です。
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 [RFC6733], Section 2.8.
プロトコル透過型のDiameterリレーは、クレジット制御クライアントとクレジット制御サーバーの間に存在できます。また、信用管理クライアントを信用管理サーバーに照会し、直接通信できるようにするDiameterリダイレクトエージェントが存在する場合もあります。これらのエージェントは、Diameter Credit-Controlアプリケーションを透過的にサポートします。 Diameterエージェントのさまざまな役割は、Diameterベース[RFC6733]、セクション2.8で定義されています。
If Diameter Credit-Control proxies exist between the credit-control client and the credit-control server, they MUST advertise support for the Diameter Credit-Control application.
Diameterクレジット制御プロキシがクレジット制御クライアントとクレジット制御サーバーの間に存在する場合、それらはDiameterクレジット制御アプリケーションのサポートを通知する必要があります。
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 Name | Abbrev. | Code | Reference |
+------------------------+---------+------+-------------+
| Credit-Control-Request | CCR | 272 | Section 3.1 |
| Credit-Control-Answer | CCA | 272 | Section 3.2 |
+------------------------+---------+------+-------------+
Table 1: Credit-Control Commands
表1：クレジット制御コマンド
Section 3.2 of [RFC6733] (Diameter base) defines the Command Code Format specification. These formats are observed in credit-control messages.
[RFC6733]のセクション3.2（直径ベース）は、コマンドコード形式の仕様を定義しています。これらの形式は、クレジット制御メッセージで確認されます。
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-Control-Requestメッセージ（CCR）は、コマンドコードフィールドが272に設定され、「R」ビットがコマンドフラグフィールドに設定されていることで示されます。これは、Diameter Credit-Controlクライアントとクレジット制御サーバーの間で使用され、特定のサービスのクレジット認証を要求します。
The Auth-Application-Id MUST be set to the value 4, indicating the Diameter Credit-Control application.
Auth-Application-Idは、Diameter Credit-Controlアプリケーションを示す値4に設定する必要があります。
The CCR is extensible via the inclusion of one or more Attribute-Value Pairs (AVPs).
CCRは、1つ以上の属性値ペア（AVP）を含めることで拡張できます。
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 ]
*[ Subscription-Id-Extension ]
[ 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 ]
[ User-Equipment-Info-Extension ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
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-Control-Answerメッセージ（CCA）は、コマンドコードフィールドが272に設定され、「R」ビットがコマンドフラグフィールドでクリアされることで示されます。これは、クレジット制御サーバーと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 ]
[ QoS-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 ]
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 requests are 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 authorization with direct debiting. In both models, the credit-control client requests credit authorization from the credit-control server prior to allowing any services to be delivered to the end user.
クレジット承認プロセスは、エンドユーザーへのサービス提供の前と最中に行われ、通常、要求がクレジット管理サーバーに送信される前にユーザーの認証と承認が必要です。この仕様で定義されている与信管理アプリケーションは、2つの異なる与信承認モデルをサポートしています。それは、マネーリザベーションによる与信承認と、口座引き落としによる与信承認です。どちらのモデルでも、クレジット制御クライアントは、サービスをエンドユーザーに提供する前に、クレジット制御サーバーにクレジット認証を要求します。
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 amount of credit reserved. 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.
最初のモデルでは、信用管理サーバーが要求を評価し、ユーザーのアカウントから適切な金額を予約し、予約された信用金額を返します。信用リソースは実際の金銭的信用を意味しない場合があることに注意してください。クレジットリソースは、計測される単位（たとえば、データ量または時間）の形でクレジットコントロールクライアントに付与されます。
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 the 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 inquiries, user's balance checks, and refunds of credit on the user's account. These operations are accomplished with the one-time event. Session state is not maintained.
与信管理アプリケーションは、サービス価格照会、ユーザーの残高チェック、ユーザーのアカウントのクレジットの払い戻しなどの操作もサポートします。これらの操作は、1回限りのイベントで実行されます。セッション状態は維持されません。
Flexible failure handling, specific to the credit-control application, is defined in the application. This allows the service provider to control the credit-control client's behavior according to its own risk management policy.
与信管理アプリケーションに固有の柔軟な障害処理は、アプリケーションで定義されます。これにより、サービスプロバイダーは、独自のリスク管理ポリシーに従ってクレジットコントロールクライアントの動作を制御できます。
The Credit-Control-Failure-Handling AVP (also referred to as the CCFH) and the Direct-Debiting-Failure-Handling AVP (also referred to as the DDFH) 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 CCFH and the DDFH allows flexibility, as failure handling for the credit-control session and one-time event direct debiting may be different.
Credit-Control-Failure-Handling AVP（CCFHとも呼ばれる）およびDirect-Debiting-Failure-Handling AVP（DDFHとも呼ばれる）は、クレジット制御メッセージの送信が行われた場合の処理を決定するために定義されています。与信管理サーバーへのアクセスは一時的に禁止されています。 CCFHとDDFHを使用すると、クレジット制御セッションの障害処理と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 Credit-Controlアプリケーションは、クレジット制御のフレームワークを定義します。複数のサービスアプリケーションをサポートする一般的なクレジットコントロールメカニズムを提供します。したがって、与信管理アプリケーションは、格付けプロセスの入力として使用できるAVPを定義しません。この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-upon rating input (i.e., AVPs), and so on.
クレジットコントロールクライアントのプロバイダーとクレジットコントロールサーバーの間に、課金、提供されるサービス、ローミング契約、合意されたレーティング入力（AVPなど）をカバーするサービスレベル契約が存在することを期待するのは妥当です。 。
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 Credit-Controlサーバーは、与信制御メッセージの内容に関して事前に合意したDiameter Credit-Controlクライアントにのみサービスを提供すると想定されています。当然、任意のDiameter Credit-Controlクライアントが任意のDiameter Credit-Controlサーバーとクレジット制御メッセージを交換できる可能性がありますが、サポートされていないサービス/ AVPがクレジット制御メッセージに存在し、サーバーを引き起こしている可能性が高くなります適切なResult-Codeでリクエストを拒否します。
There are two ways to provide rating input to the credit-control server: by either using AVPs or including the rating input in the Service-Parameter-Info AVP. The general principles for sending rating parameters are as follows:
信用管理サーバーに評価入力を提供する方法は2つあります。AVPを使用するか、Service-Parameter-Info AVPに評価入力を含める方法です。評価パラメータを送信するための一般的な原則は次のとおりです。
1. Using AVPs:
1. AVPの使用：
A. The service SHOULD reuse existing AVPs if it can use AVPs defined in existing Diameter applications (e.g., [RFC7155] for network access services). [RFC6733] strongly recommends the reuse of existing AVPs.
A.サービスは、既存のDiameterアプリケーションで定義されたAVPを使用できる場合は、既存のAVPを再利用する必要があります（たとえば、ネットワークアクセスサービスの[RFC7155]）。 [RFC6733]は、既存のAVPの再利用を強く推奨しています。
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 [RFC6733], Section 1.3.
EnumeratedタイプのAVPの場合、サービスで新しい値を定義する必要がある場合があります。新しいAVP値の割り当ては、[RFC6733]のセクション1.3の指定に従って行われます。
B. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In this case, the procedures defined in [RFC6733] for creating new AVPs MUST be followed.
B.既存のAVPが十分な評価情報を提供しない場合、新しいAVPを定義できます。この場合、[RFC6733]で定義された新しいAVPを作成するための手順に従う必要があります。
C. 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 [RFC6733].
C. 1つのベンダーの実装にのみ固有のサービスの場合は、プライベートに使用するためのベンダー固有のAVPコードを使用できます。ベンダー固有のAVPが複数のベンダーによって実装されている場合は、代わりにグローバルAVPの割り当てが推奨されます。 [RFC6733]を参照してください。
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-Parameter-Info AVPは、元のエンコードされた形式（ASN.1 BERなど）でレガシー評価情報を渡すためのコンテナーとして使用できます（MAY）。このメソッドは、既存のデータ形式からAVP形式への不要な変換を回避するために使用できます。この場合、評価入力は、セクション8.43で定義されているService-Parameter-Info AVPに埋め込まれます。
New service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, to simplify interoperability.
新しいサービスアプリケーションは、相互運用性を簡素化するために、項目1aおよび1bで説明されているように、明示的に定義されたAVPの使用を推奨する必要があります。
The service-specific rating input AVPs, and 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 (preferably that of another cooperative standardization body, e.g., 3GPP, the Open Mobile Alliance (OMA), or 3GPP2). 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.
サービス固有の評価入力AVP、およびService-Parameter-Info AVPまたはService-Context-Id AVP（セクション8.42で定義）の内容は、このドキュメントの範囲外です。相互運用性を促進するために、Service-Context-Idの評価入力と値は、情報RFCまたはその他の永続的で容易に利用可能な参照（好ましくは、3GPP、Open Mobileなどの別の共同標準化団体の参照）を介して調整することをお勧めします。アライアンス（OMA）、または3GPP2）。ただし、与信管理サーバーのプロバイダーとクライアントの間の契約の対象となるプライベートサービスが展開される場合があります。この場合、ベンダー固有のAVPを使用できます。
This specification, together with the above-mentioned service-specific documents, governs the credit-control message. Service-specific documents (i.e., those documents that do not define new credit-control applications) define which existing AVPs or new AVPs are used as input to the rating process; thus, the AVPs in question have to be included in the Credit-Control-Request command by a Diameter Credit-Control client supporting a given service as "* [AVP]". Should the Service-Parameter-Info AVP be used, the service-specific document MUST specify the exact content of this Grouped AVP.
この仕様は、前述のサービス固有のドキュメントとともに、クレジット制御メッセージを管理します。サービス固有のドキュメント（つまり、新しい与信管理アプリケーションを定義しないドキュメント）は、既存のAVPまたは新しいAVPが評価プロセスへの入力として使用されることを定義します。したがって、問題のAVPは、所定のサービスを「* [AVP]」としてサポートするDiameter Credit-ControlクライアントによるCredit-Control-Requestコマンドに含める必要があります。 Service-Parameter-Info AVPを使用する場合は、サービス固有のドキュメントで、このグループ化されたAVPの正確なコンテンツを指定する必要があります。
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-Context-Id AVPをCredit-Control-Requestのコマンドレベルに含める必要があります。要求が関連する特定のサービスまたは評価グループは、Service-Context-IdとService-Identifierまたは評価グループの組み合わせによって一意に識別されます。
Diameter Credit-Control implementations are required to support mandatory rating-related AVPs defined in service-specific documents for the services they support, according to the 'M' bit rules in [RFC6733].
Diameter Credit-Control実装は、[RFC6733]の「M」ビットルールに従って、サポートするサービスのサービス固有のドキュメントで定義された必須のレーティング関連AVPをサポートする必要があります。
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 the 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.
評価プロセスに必要な評価入力がCredit-Control-Requestで正しくない場合、または信用管理サーバーが要求されたサービスコンテキストをサポートしていない場合（コマンドレベルのService-Context-Id AVPで識別）、信用-Control-Answerには、エラーコードDIAMETER_RATING_FAILEDが含まれている必要があります。このエラーのあるCCAメッセージには、失敗の原因となった欠落またはサポートされていないAVPを含む1つ以上のFailed-AVP AVPが含まれている必要があります。リクエストへの応答としてエラーコードDIAMETER_RATING_FAILEDを受け取るDiameterクレジット制御クライアントは、今後同様のリクエストを送信してはなりません（MUST NOT）。
When service-specific documents include RADIUS vendor-specific attributes that could be used as input in the rating process, the rules described in [RFC7155] for formatting the Diameter AVP MUST be followed.
サービス固有のドキュメントに、評価プロセスの入力として使用できるRADIUSベンダー固有の属性が含まれている場合は、[RFC7155]で説明されているDiameter AVPのフォーマットに関するルールに従う必要があります。
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コードがベンダー属性タイプコードである場合、ベンダー固有フラグは1に設定する必要があり、ベンダーIDはIANAベンダー識別値に設定する必要があります。 Diameter AVPデータフィールドには、RADIUS属性の属性値のみが含まれます。
For session-based credit-control, several interrogations are needed: the first, the intermediate (optional), and the final. This is illustrated in Figures 3 and 4 (Sections 5.2.1 and 5.2.2).
セッションベースの与信管理では、いくつかの調査が必要です。最初の調査、中間調査（オプション）、および最終調査です。これを図3および4に示します（セクション5.2.1および5.2.2）。
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-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 [RFC6733]; this Session-Id MUST NOT be changed during the lifetime of a credit-control session.
各クレジット制御セッションは、[RFC6733]で定義されているように、グローバルに一意のセッションIDを持つ必要があります。このセッションIDは、信用管理セッションの存続期間中に変更してはなりません。
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 the CC-Sub-Session-Id AVP implies that no sub-sessions are in use.
特定のアプリケーションでは、複数の与信管理サブセッションが必要です。これらのアプリケーションは、一定のSession-Id AVPを使用してメッセージを送信しますが、異なるCC-Sub-Session-Id AVPを使用します。複数のクレジットサブセッションを使用する場合は、メインセッションを閉じる前にすべてのサブセッションを個別に閉じて、サブセッションごとのユニット数を報告する必要があります。 CC-Sub-Session-Id 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 unit(s) (G-S-U). 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 Credit-Controlサーバーは、付与された割り当ての有効期間や中間の問い合わせの生成を制御しようとする場合があります。したがって、クレジット制御クライアントへの応答メッセージにValidity-Time AVPを含めることができます。 Validity-Timeの期限が切れると、クレジット制御クライアントは、クレジット制御更新要求を生成し、使用された割り当て量をクレジット制御サーバーに報告する必要があります。付与されたサービスユニット（G-S-U）の消費に使用されるValidity-Timeの値を決定するのは、クレジットコントロールサーバー次第です。 Validity-Timeを使用する場合、その値をセッション監視タイマーTccを設定するための入力として指定する必要があります（セッション監視タイマーは、セクション13で定義されているように、Validity-Timeの値の2倍に設定できます）。与信管理更新要求は、付与されたサービス単位の満了時および/または中間セッションサービスイベントでも生成されるため、Validity-Timeの省略は、与信管理を目的とした中間の問い合わせが実行されないことを意味しません。
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, so that the overall reported used units would never exceed the credit reservation. For example, in the case of a forthcoming tariff change, in which the new rate is higher, the allocation should be given so it does not exceed the credit, assuming that all of it is used after the tariff changed.
Diameter Credit-Controlサーバーとクライアントは、オプションで料金変更メカニズムをサポートする場合があります。 Diameter Credit-Controlサーバーは、AnswerメッセージにTariff-Time-Change 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 Credit-Controlクライアントが使用されたユニットを報告し、レポート期間中に料金変更が発生した場合、Diameter Credit-Controlクライアントは、料金変更の前後に使用されたユニットを個別に項目化する必要があります。クライアントが関税変更にまたがるユニットが関税変更の前または後に使用されたかどうかを区別できない場合、信用管理クライアントはそれらのユニットを第3のカテゴリーに分類しなければなりません（MUST）。
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.
クライアントが関税変更メカニズムをサポートせず、関税時間変更AVPを伝送するCCAメッセージを受信した場合、クライアントは信用管理セッションを終了しなければならず、Termination-Cause AVPにDIAMETER_BAD_ANSWERの理由を与えます。
For time-based services, the quota is consumed at the rate of the passage of real time (ignoring leap seconds). That is, precisely 1 second of quota is consumed per second of real time. 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 "afterward" rate 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 the 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秒あたり正確に1秒の割り当てが消費されます。クレジットリソースが割り当てられた時点で、サーバーは、関税時間の変更前に消費されるユニット数と、後で消費されるユニット数を認識しています。同様に、サーバーは、エンドユーザーが割り当てられた割り当て量を消費する前にセッションを閉じた場合に、「前」のレートで消費されるユニットと「後」のレートで消費されるユニットを決定できます。継続的な時間ベースのサービスの関税時間の変更の場合、クライアントとサーバー間の追加のトラフィックは必要ありません。したがって、このようなサービスには関税変更メカニズムは使用されません。クォータが通常のレートで継続的に消費されない時間ベースのサービスの場合、ボリュームおよびイベントユニットについて説明されている料金変更メカニズムを使用できます。
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-based services that could be charged with different costs. The network-access-specific attributes, such as Quality of Service (QoS), are common to all the services carried within the access bearer, but the cost of the bearer may vary, depending on its content.
同じユーザーセッション内で複数のサービスが使用され、各サービスまたはサービスのグループに異なるコストがかかる場合、各サービスに対して独立してクレジット制御を実行する必要があります。独立した信用管理を実現するために信用管理サブセッションを利用すると、信用管理クライアントと信用管理サーバーの両方でシグナリング負荷とリソースの使用量が増加します。たとえば、1つのネットワークアクセスセッション中に、エンドユーザーはさまざまなコストで課金される可能性がある複数のHTTPベースのサービスを使用する場合があります。サービスの品質（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/Credit-Control-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-Indication AVP values or QoS-Final-Unit-Indication AVP values.
これらのシナリオを最適にサポートするために、信用管理アプリケーションは、単一の信用管理（サブ）セッションで複数のサービスの独立した信用管理を可能にします。これは、オプションのMultiple-Services-Credit-Control AVPをCredit-Control-Request / Credit-Control-Answerメッセージに含めることで実現されます。複数のサービス間で共有されるクレジットプールとしてリソースをリクエストして割り当てることができます。サービスを格付けグループにグループ化して、クレジットの割り当てをさらに集約することができます。サービスごとに割り当てをリクエストして割り当てることもできます。 Multiple-Services-Credit-Control AVPを使用してクォータがプールに割り当てられる場合、クォータは独立したオブジェクトのままで、いつでも個別に再承認できます。クォータには、独立した結果コード、有効期間、およびFinal-Unit-Indication AVP値またはQoS-Final-Unit-Indication AVP値を指定することもできます。
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-tuples and HTTP URLs.) 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 a quota is allocated to a rating-group, all the services belonging to that group draw from the allotted quota. Figure 2 provides a graphical representation of the relationship between service-identifiers, rating-groups, credit pools, and credit-control (sub-)sessions.
格付けグループは、サービスIDによって識別され、同じコストと格付けタイプ（例：$ 0.1 /分）の対象となる一連のサービスを収集します。サービス要素には、評価グループ、サービス識別子、およびこの仕様の範囲外の手段で測定する必要があるものを定義するそれらの関連パラメーターが提供されていると想定されています。 （サービスIDに関連付けられているパラメーターの例は、IP 5タプルとHTTP URLです。）サービスIDは、サービスごとのクレジットの承認と、サービス使用状況の項目別レポートを可能にします。 1つ以上のサービスのクレジットを承認するか、レーティンググループ全体のクレジットを承認するかは、クレジット管理サーバー次第です。ただし、クライアントは常に、サポートされている最も細かいレベルで使用済みユニットを報告する必要があります（SHOULD）。クォータが評価グループに割り当てられている場合、そのグループに属するすべてのサービスは、割り当てられたクォータから取得されます。図2は、サービスID、評価グループ、クレジットプール、およびクレジット制御（サブ）セッション間の関係をグラフで表したものです。
Diameter Credit-Control (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
Figure 2: Multiple-Service (Sub-)Session Example
図2：マルチサービス（サブ）セッションの例
If independent credit-control of multiple services is used, the Validity-Time AVP, and the Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP, SHOULD be present either in the Multiple-Services-Credit-Control AVP(s) or at the command level as single AVPs. However, the Result-Code AVP MAY be present both at the command level and within the Multiple-Services-Credit-Control AVP. If the Result-Code AVP at the command level indicates a value other than SUCCESS, then the Result-Code AVP at the command level takes precedence over any other AVPs included in the Multiple-Services-Credit-Control AVP.
複数のサービスの独立したクレジットコントロールが使用されている場合、Validity-Time AVP、およびFinal-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPは、Multiple-Services-Credit-Control AVP（ s）または単一のAVPとしてコマンドレベルで。ただし、結果コードAVPは、コマンドレベルとMultiple-Services-Credit-Control AVPの両方に存在する場合があります。コマンドレベルのResult-Code AVPがSUCCESS以外の値を示す場合、コマンドレベルのResult-Code AVPは、Multiple-Services-Credit-Control AVPに含まれる他のAVPよりも優先されます。
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.
信用管理クライアントは、最初の問い合わせにMultiple-Services-Indicator AVPを含めることにより、（サブ）セッション内の複数のサービスの独立した信用管理のサポートを示さなければなりません（MUST）。この機能をサポートしないクレジットコントロールサーバーは、Multiple-Services-Indicator AVPおよび受信したすべてのMultiple-Services-Credit-Control AVPを無効なAVPとして処理する必要があります。
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.
クライアントが複数のサービスの独立したクレジットコントロールのサポートを示した場合、機能を使用することを望むクレジットコントロールサーバーは、対応するサービスIDに関連付けられたMultiple-Services-Credit-Control 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-Services-Credit-Control 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 (1) S is the total service units within the pool, (2) M1, M2, ..., Mn are the multipliers provided for services 1, 2, ..., n, and (3) C1, C2, ..., Cn are the used resources within the session, then the pool's credit is exhausted and re-authorization MUST be sought when:
（1）Sがプール内の合計サービス単位である場合、（2）M1、M2、...、Mnはサービス1、2、...、nに提供される乗数であり、（3）C1、C2、 ...、Cnはセッション内で使用されたリソースであり、プールのクレジットが使い果たされ、次の場合に再認証を求める必要があります。
C1*M1 + C2*M2 + ... + Cn*Mn >= S
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
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 needs 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.
個々のサービスまたは評価グループの再承認は、いつでも要求される可能性があります。たとえば、「プールされていない」割り当てが使い果たされた場合や、有効期間が期限切れになった場合などです。
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, these AVPs 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 yield the sum of C1t*M1t + C1v*M1v, where C1t is the time unit and C1v is the volume unit.
同じGSU-Pool-Identifierを持つ複数のGSU-Pool-Reference AVP（セクション8.30）がGranted-Service-Unit AVPとともにMultiple-Services-Credit-Control AVP（セクション8.16）内で提供される場合、これらのAVPはCC-Unit-Typeの値が異なり、それらはすべてクレジットプールから個別に引き出されます。たとえば、時間の乗数（M1t）とボリュームの乗数（M1v）の1つが指定されている場合、プールの使用済みリソースはC1t * M1t + C1v * M1vの合計を生成します。ここで、C1tは時間単位で、C1vは体積単位。
Where service units are provided within a Multiple-Services-Credit-Control AVP without a corresponding G-S-U-Pool-Reference AVP, these units are handled independently from any credit pools and from any other services or rating-groups within the session.
サービスユニットが対応するG-S-U-Pool-Reference AVPなしでMultiple-Services-Credit-Control AVP内で提供される場合、これらのユニットは、クレジットプールやセッション内の他のサービスや評価グループから独立して処理されます。
The "credit pool" concept is an optimal tool to avoid the over-reservation effect of the basic single-quota tariff time change mechanism (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 AVP and the Tariff-Change-Usage AVP in two quota allocations in the Answer message (i.e., two instances of the Multiple-Services-Credit-Control AVP). One of the grants is allocated to be used before the potential tariff change, while the second grant is 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 the used units both before and after the tariff change in a single instance of the Multiple-Services-Credit-Control AVP.
「クレジットプール」の概念は、基本的なシングルクォータの関税時間変更メカニズム（セクション5.1.1）の過剰予約効果を回避するための最適なツールです。したがって、複数のサービスの独立したクレジットコントロールを実装するDiameterクレジットコントロールクライアントおよびサーバーは、関税時間の変更をサポートするときに、クレジットプールの概念を活用する必要があります。 Diameter Credit-Controlサーバーは、Answerメッセージの2つの割り当て割り当てに、Tariff-Time-Change AVPとTariff-Change-Usage AVPの両方を含める必要があります（つまり、Multiple-Services-Credit-Control AVPの2つのインスタンス）。許可の1つは、料金が変更される前に使用されるように割り当てられ、2番目の許可は、料金が変更された後に使用されます。付与された両方のユニットクォータには、同じService-Identifierおよび/またはrating-groupが含まれている必要があります。この二重割り当てメカニズムにより、報告された使用済みユニット全体がクレジット予約を超えないことが保証されます。 Diameter Credit-Controlクライアントは、Multiple-Services-Credit-Control AVPの単一インスタンスでの料金変更の前と後の両方で、使用されたユニットを報告します。
Failure handling for credit-control sessions is defined in Section 5.7 and reflected in the basic credit-control state machines defined in Section 7. Credit-control clients and servers implementing the functionality of independent credit-control of multiple services in a (sub-)session MUST ensure failure handling and general behavior fully consistent with Sections 5.7 and 7 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 (Section 7) 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 the Tx timer is stopped. Naturally, when a problem is detected and acted upon per Section 5.7, all of the ongoing services are affected (e.g., failover to a backup server affects all of the CCR messages in the PendingU queue).
クレジット制御セッションの障害処理は、セクション5.7で定義され、セクション7で定義された基本的なクレジット制御状態マシンに反映されます。（サブ）内の複数のサービスの独立したクレジット制御の機能を実装するクレジット制御クライアントおよびサーバー（サブ）セッション内で進行中のクレジットの再承認を並行して処理する機能を維持しながら、セッションはセクション5.7および7と完全に一致する障害処理と一般的な動作を保証する必要があります。したがって、Diameter Credit-ControlクライアントはPendingUメッセージキューを維持し（セクション7）、値がUPDATE_REQUESTのCCRメッセージがPendingU状態のときに送信されるたびにTxタイマーを再起動する（セクション13）ことをお勧めします。保留中のすべてのメッセージに対する応答が受信されると、状態マシンはOpen状態に移行し、Txタイマーが停止します。当然、問題が検出され、セクション5.7に従って対処されると、進行中のすべてのサービスが影響を受けます（たとえば、バックアップサーバーへのフェイルオーバーは、PendingUキュー内のすべてのCCRメッセージに影響します）。
Since the client may send CCR messages with the value UPDATE_REQUEST while in PendingU state (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）。これらの各要求に対して適切な答えが返されます。
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 events for the end user. The CC-Request-Type AVP is set to the value INITIAL_REQUEST in the request message.
セッションベースのクレジットコントロールが必要な場合（認証サーバーがプリペイドユーザーを示した場合など）、Diameterクレジットコントロールクライアントがエンドユーザーのサービスイベントを許可する前に、最初の問い合わせを送信する必要があります。 CC-Request-Type AVPは、要求メッセージで値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 MAY be sent as service-specific AVPs or MAY be sent within the Service-Parameter-Info AVP at the command level. The Service-Context-Id AVP indicates the service-specific document applicable to the request.
Diameter Credit-Controlクライアントがサービスイベントのコストを知っている場合（たとえば、着信音を配信するコンテンツサーバーがそのコストを知っている場合があります）、請求される金額はRequested-Service-Unit AVPに含まれています。 Diameter Credit-Controlクライアントがサービスイベントのコストを知らない場合、Requested-Service-Unit AVPには、リクエストされたサービスイベントの数が含まれる場合があります。 Multiple-Services-Credit-Control AVPを使用する場合は、Requested-Service-Unit AVPを含めて、関連するサービス/評価グループの割り当てが要求されていることを示す必要があります。複数のサービスの場合、Multiple-Services-Credit-Control AVP内のService-Identifier AVPまたはRating-Group AVPは常に関連するサービスを示します。評価される追加のサービスイベント情報は、サービス固有のAVPとして送信される場合と、コマンドレベルのService-Parameter-Info AVP内で送信される場合があります。 Service-Context-Id 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 or the Subscription-Id-Extension 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 or User-Equipment-Info-Extension 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-Timestamp AVPはリクエストに含める必要があり（SHOULD）、サービス要素でサービスイベントがリクエストされた時間を含みます。 Subscription-Id AVPまたはSubscription-Id-Extension AVPは、信用管理サーバーでエンドユーザーを識別するために含める必要があります。クレジット制御クライアントは、ユーザー機器情報AVPまたはユーザー機器情報拡張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-Service-Unit AVPのタイプが「money」の場合、評価は不要ですが、対応する金額はエンドユーザーのアカウントから予約されます。
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.
クレジット制御サーバーは、応答メッセージでGranted-Service-Unit AVPをDiameterクレジット制御クライアントに返します。 Granted-Service-Unit AVPには、Diameter Credit-Controlクライアントが新しいCredit-Control-RequestをCredit-Controlサーバーに送信する必要があるまでエンドユーザーに提供できるサービスユニットの量が含まれています。複数のユニットタイプがAnswerメッセージで送信される場合、クレジット制御クライアントは各ユニットタイプを個別に処理する必要があります。 Granted-Service-Unit AVPのタイプは、サービスイベントのタイプに応じて、時間、量、サービス固有、または金額になります。ユニットタイプは、進行中の与信管理セッション内で変更してはなりません（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 the tariff change and the granted quota after the tariff change.
1つのAnswerメッセージには、同じユニットタイプのインスタンスを最大1つ含める必要があります。ただし、Multiple-Services-Credit-Control AVPで複数のクォータがクレジット制御クライアントに伝達される場合、サービス識別子/評価グループに関連付けられた同じユニットタイプの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 the 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 or the QoS-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.
Credit-Control-Answerメッセージには、Final-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPも含まれて、応答メッセージにサービスの最終ユニットが含まれていることを示す場合があります。エンドユーザーがこれらのユニットを消費した後、Diameter Credit-Controlクライアントはセクション5.6で説明されているように動作する必要があります。
This document defines two different approaches for performing the first interrogation to be used in different network architectures. The first approach uses credit-control messages after the user's authorization and authentication take place. The second approach uses (1) service-specific authorization messages to perform the first interrogation during the user's authorization/authentication phase and (2) credit-control messages for the intermediate and final interrogations. If an implementation of the credit-control client supports both methods, determining which method to use SHOULD be configurable.
このドキュメントでは、異なるネットワークアーキテクチャで使用される最初の問い合わせを実行するための2つの異なるアプローチを定義します。最初のアプローチは、ユーザーの承認と認証が行われた後にクレジット制御メッセージを使用します。 2番目のアプローチは、（1）サービス固有の許可メッセージを使用して、ユーザーの許可/認証フェーズ中に最初の照会を実行し、（2）中間および最終の照会のためのクレジット制御メッセージを使用します。クレジット制御クライアントの実装が両方の方法をサポートしている場合、どの方法を使用するかを決定することは構成可能である必要があります。
In service environments such as NAS environments, 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 environments mentioned in this document 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.
NAS環境などのサービス環境では、プロトコル効率を上げるために、承認/認証プロセスの一部として最初の問い合わせを実行することが望まれます。最初の問い合わせ後の追加のクレジット認証は、この仕様で定義されているクレジット制御コマンドで実行されます。このドキュメントで言及されている環境で動作するクレジットコントロールクライアントの実装は、この方法をサポートする必要があります（SHOULD）。クレジットコントロールサーバーとAAAサーバーが別の物理エンティティである場合、サービスエレメントはリクエストメッセージを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 during 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, intermediate, and final interrogations are executed with credit-control commands defined in this specification.
3GPPネットワークや一部のSIPシナリオなどの他のサービス環境では、ネットワークへの登録/アクセスと実際のサービス要求との間に実質的な分離があります（つまり、認証/承認は、ネットワークへの登録/アクセス中に一度実行されます。サブスクライバーによって要求されたすべてのサービスイベントに対して実行されるわけではありません）。これらの環境では、ユーザーが認証および承認された後に最初の問い合わせを実行する方が適切です。最初、中間、および最後の問い合わせは、この仕様で定義されているクレジット制御コマンドで実行されます。
Other IETF standards or standards developed by other standardization bodies may define the most suitable method in their architectures.
他のIETF標準または他の標準化団体によって開発された標準は、それらのアーキテクチャーで最も適切な方法を定義する場合があります。
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 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.
サービス要素のDiameterクレジット制御クライアントは、エンドユーザーの知識に基づいて、クレジット制御が必要かどうかについて、認証サーバーから情報を取得できます。与信管理が必要な場合、エンドユーザーへのサービス提供を開始する前に与信管理サーバーに連絡する必要があります。会計プロトコルと与信管理プロトコルは並行して使用できます。承認サーバーは、並列アカウンティングストリームが必要かどうかも決定します。
Figure 3 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 Appendix A.
図3は、両方のプロトコルが並行して使用され、サービス要素がクレジット制御サーバーに直接クレジット制御メッセージを送信する場合を示しています。その他の与信管理シーケンスの例は、付録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 | |
| |<-------------------| |
ACR: Accounting-Request ACA: Accounting-Answer
ACR：Accounting-Request ACA：Accounting-Answer
Figure 3: Protocol Example with First Interrogation after User's Authorization/Authentication
図3：ユーザーの承認/認証後の最初の問い合わせがあるプロトコルの例
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 service-specific authorization/authentication application document (e.g., [RFC7155] [RFC4004]). The home Diameter AAA server authenticates/authorizes the subscriber and determines whether credit-control is required.
サービス要素のDiameterクレジット制御クライアントは、適切なクレジット制御AVPを追加することにより、AAリクエストの構築において認証/認証クライアントと積極的に協力しなければなりません（MUST）。クレジット制御クライアントは、クレジット制御機能を示すためにクレジット制御AVPを追加する必要があり、他の関連するクレジット制御固有のAVPを適切な承認/認証コマンドに追加して、ホームDiameter AAAサーバーへの最初の問い合わせを実行する必要があります。 Auth-Application-Idは、サービス固有の承認/認証アプリケーションドキュメント（[RFC7155] [RFC4004]など）で定義されているように、適切な値に設定されます。ホーム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-Answerメッセージで応答します。サブスクライバーにクレジット制御が必要であり、CREDIT_AUTHORIZATIONに設定された値を持つCredit-Control AVPが許可要求に存在した場合、ホームAAAサーバーはクレジット制御サーバーに連絡して最初の問い合わせを実行する必要があります。サブスクライバーにクレジット制御が必要であり、クレジット要求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 CCFH and the DDFH to determine what to do if the sending of credit-control messages to the credit-control server has been temporarily prevented.
このドキュメントで定義されているCredit-Control-Requestコマンド（CCR）をcredit-controlサーバーに送信するには、credit-controlをサポートするDiameter AAAサーバーが必要です。 Diameter AAAサーバーは、評価プロセスへの入力に使用されるサービス固有のAVPに基づいて、そしておそらくAA-Requestで受信されたCredit-Control AVPに基づいてCCRを生成します。クレジットコントロールサーバーは、ユーザーのアカウントからお金を予約し、リクエストを評価し、Credit-Control-AnswerメッセージをホームDiameter AAAサーバーに送信します。 Answerメッセージには、Granted-Service-Unit AVPが含まれており、必要に応じて、他のクレジットコントロール固有のAVPを含めることができます。さらに、クレジット制御サーバーはValidity-Timeを設定し、CCFHとDDFHを含めて、クレジット制御サーバーへのクレジット制御メッセージの送信が一時的に阻止された場合の対処法を決定してもよい（MAY）。
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., [RFC7155] [RFC4004]). 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 simply generate an appropriate authorization reject message to the credit-control client, including the credit-control-specific error code.
クレジット制御サーバーからCredit-Control-Answerメッセージを受信すると、ホームDiameter AAAサーバーは、受信したCredit-Control AVPと、認証/認証固有のアプリケーションに応じて適切なサービス属性をAA-Answerに入力します（例：[RFC7155] [RFC4004]）。次に、パケットをクレジット制御クライアントに転送します。ホームDiameter AAAサーバーがクレジットコントロール拒否メッセージを受信すると、クレジットコントロール固有のエラーコードを含む、適切な承認拒否メッセージをクレジットコントロールクライアントに生成します。
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, if required, by using credit-control commands. The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 (for details regarding how to produce a unique value for the CC-Request-Number AVP, see Section 8.2).
このモデルでは、クレジット制御クライアントは、ホームDiameter AAAサーバー経由でクレジット制御サーバーにさらにクレジット制御メッセージを送信します。 Granted-Service-Unit AVP（s）で承認応答メッセージを受信すると、クレジットコントロールクライアントはエンドユーザーにサービスを許可し、必要に応じてcredit-を使用して中間のCredit-Control-Requestを生成します。制御コマンド。最初のUPDATE_REQUESTのCC-Request-Numberを1に設定する必要があります（CC-Request-Number AVPの一意の値を生成する方法の詳細については、セクション8.2を参照してください）。
If service-specific re-authorization is performed (i.e., the 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.
サービス固有の再認証が実行された場合（つまり、認証の有効期限が切れた場合）、クレジット制御クライアントは、RE_AUTHORIZATIONに設定された値を持つCredit-Control AVPをサービス固有の再認証要求に追加しなければなりません。 -制御サーバーに接続してはなりません。サブスクライバーにセッションベースのクレジット制御が使用されている場合、一定のクレジット制御メッセージストリームがホーム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サーバーは、機能交換プロセス中に、クレジット制御アプリケーションのサポートをピアに通知する必要があります。
Figure 4 illustrates the use of authorization/authentication messages to perform the first interrogation. The parallel accounting stream is not shown in the figure.
図4は、最初の問い合わせを実行するための承認/認証メッセージの使用を示しています。パラレルアカウンティングストリームは図には示されていません。
Diameter
Service Element AAA Server CC Server
End User (CC Client)
| Service Request | AA-Request (CC AVPs) | |
|------------------>|--------------------->| |
| | | CCR(Initial, CC AVPs)
| | |-------------------->|
| | | CCA(Granted-Units)|
| | |<--------------------|
| | AA-Answer(Granted-Units) |
| Service Delivery |<---------------------| |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update, Used-Units) |
| |--------------------->| CCR(Update, Used-Units)
| | |-------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<--------------------|
| |<---------------------| |
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination, Used-Units) |
| |--------------------->| CCR(Term., Used-Units)
| | |-------------------->|
| | | CCA |
| | CCA |<--------------------|
| |<---------------------| |
Figure 4: Protocol Example with Use of Authorization Messages for the First Interrogation
図4：最初の問い合わせに承認メッセージを使用したプロトコルの例
When all the granted service units for one unit type are spent by the end user or the Validity-Time has 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 the rating-group are granted), a new Credit-Control-Request MUST be sent to the credit-control server when the 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.
1つのユニットタイプに付与されたすべてのサービスユニットがエンドユーザーによって使用された場合、またはValidity-Timeが期限切れになった場合、Diameterクレジットコントロールクライアントは、新しいクレジットコントロール要求をクレジットコントロールサーバーに送信する必要があります。複数のサービスの信用管理が1つの信用管理セッションで適用される場合（つまり、Service-Identifier（s）または評価グループに関連付けられたユニットが許可される場合）、新しいCredit-Control-Requestを送信する必要があります。クレジット予約が完全に消費されたとき、またはValidity-Timeの期限が切れたときのクレジット制御サーバー。サービス要素の中断を回避するために、前の要求の期限が切れるかなり前に新しい要求を送信するのは、Diameter Credit-Controlクライアント次第です。クレジットコントロールサーバーによって予約された許可されたサービスユニットがValidity-Timeの期限切れに費やされていない場合でも、Diameterクレジットコントロールクライアントは、新しいクレジットコントロール要求をクレジットコントロールサーバーに送信する必要があります。
There can also be mid-session service events, which might affect the rating of the current service events. In this case, a spontaneous update (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.
現在のサービスイベントの評価に影響を与える可能性のあるセッション中のサービスイベントが存在する場合もあります。この場合、付与されたすべてのサービスユニットが使用されていないか、Validity-Timeの有効期限が切れていない場合でも、サービスイベントに関連する情報を含む、自発的な更新（新しいCredit-Control-Request）を送信する必要があります。
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.
使用されたユニットが信用管理サーバーに報告されると、信用管理サーバーから信用供与された新しいユニットを受け取るまで、信用管理クライアントはユニットを所有しません。新たに付与されたユニットが受信されると、これらのユニットは、報告された使用済みユニットの測定が停止した時点から適用されます。複数のサービスの独立した与信管理がサポートされている場合、このプロセスは、1つ以上のサービス、単一の評価グループ、または（サブ）セッション内のプールに対して実行できます。
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message. The Subscription-Id AVP or Subscription-Id-Extension 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.
CC-Request-Type AVPは、中間要求メッセージで値UPDATE_REQUESTに設定されます。 Subscription-Id AVPまたはSubscription-Id-Extension AVPは、クレジットコントロールサーバーでエンドユーザーを識別するために中間メッセージに含める必要があります（SHOULD）。 Service-Context-Id AVPは、リクエストに適用可能なサービス固有のドキュメントを示します。
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.
Requested-Service-Unit AVPには、要求されたサービスユニットの新しい量が含まれる場合があります。 Multiple-Services-Credit-Control AVPが使用されている場合、関連するサービス/評価グループに対して新しい割り当てが要求されている場合は、Requested-Service-Unit AVPを含める必要があります。 Used-Service-Unit AVPには、サービスがアクティブになった時点から測定された使用済みサービスユニットの量が含まれます。セッション中に暫定照会が使用された場合は、前の測定が終了した時点から測定されます。前のメッセージで使用されたものと同じユニットタイプを使用する必要があります。複数のユニットタイプが前のAnswerメッセージに含まれていた場合、各ユニットタイプの使用されたサービスユニットを報告する必要があります。
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.
Event-Timestamp AVPはリクエストに含める必要があり（SHOULD）、新しいCredit-Control-Requestの送信をトリガーしたイベントの時間を含みます。
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 reservations into account.
CC-Request-Type AVPが値UPDATE_REQUESTに設定されたCredit-Control-Answerメッセージには、クレジット予約を考慮せずに、セッションの累積コスト見積もりを含むCost-Information AVPが含まれる場合があります。
The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP or the QoS-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.
Credit-Control-Answerメッセージには、Final-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPも含まれて、応答メッセージにサービスの最終ユニットが含まれていることを示す場合があります。エンドユーザーがこれらのユニットを消費した後、Diameter Credit-Controlクライアントはセクション5.6で説明されているように動作する必要があります。
There can be several intermediate interrogations within a session.
セッション内には、いくつかの中間問い合わせが存在する可能性があります。
When the end user terminates the service session or when 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.
エンドユーザーがサービスセッションを終了するとき、またはサービスの正常な終了（5.6項で説明）が行われるとき、Diameterクレジット制御クライアントは、最後のクレジット制御要求メッセージをクレジット制御サーバーに送信する必要があります。 CC-Request-Type AVPは、値TERMINATION_REQUESTに設定されます。 Service-Context-Id AVPは、リクエストに適用可能なサービス固有のドキュメントを示します。
The Event-Timestamp AVP SHOULD be included in the request and contains the time when the session was terminated.
Event-Timestamp AVPはリクエストに含める必要があり（SHOULD）、セッションが終了した時刻を含みます。
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.
Used-Service-Unit AVPには、サービスがアクティブになった時点から測定された使用済みサービスユニットの量が含まれます。セッション中に暫定照会が使用された場合は、前の測定が終了した時点から測定されます。複数のユニットタイプが前のAnswerメッセージに含まれていた場合、各ユニットタイプの使用されたサービスユニットを報告する必要があります。
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 AVP set to the value TERMINATION_REQUEST MAY include the Cost-Information AVP containing the estimated total cost for the session in question.
CC-Request-Type AVPが値TERMINATION_REQUESTに設定されたCredit-Control-Answerメッセージには、問題のセッションの推定合計コストを含むCost-Information AVPが含まれる場合があります。
If the user logs off during an ongoing credit-control session or if the user becomes logged off for some other reason (e.g., a final-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 [RFC6733]. Figure 5 illustrates the case when the final-unit indication causes user logoff upon consumption of the final granted units and the generation of an STR.
進行中のクレジット制御セッション中にユーザーがログオフした場合、またはユーザーが他の何らかの理由でログオフした場合（たとえば、最終ユニットの指示により、ローカルポリシーに従ってユーザーがログオフする）、アプリケーション固有のポリシーに従ってサービス要素は、通常どおり[Session-Termination-Request（STR）]をホームDiameter AAAサーバーに送信します[RFC6733]。図5は、最終的に許可されたユニットの消費とSTRの生成時に、最終ユニットの指示によってユーザーがログオフする場合を示しています。
The Diameter AAA server responds with a Session-Termination-Answer (STA).
Diameter AAAサーバーは、Session-Termination-Answer（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 5: User Disconnected Due to Exhausted Account
図5：アカウントが使い果たされたために切断されたユーザー
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 [RFC6733]. 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.
Diameter Credit-Controlアプリケーションは、サーバーが開始する再認証をサポートしています。クレジット制御サーバーは、Diameter基本プロトコル[RFC6733]で定義されているように、再認証要求（RAR）を発行することにより、オプションでクレジットの再認証を開始できます（MAY）。 RARメッセージのAuth-Application-Idは「Diameter Credit Control」を示すために4に設定され、Re-Auth-Request-TypeはAUTHORIZE_ONLYに設定されます。
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.
セクション5.1.2は、単一の（サブ）セッション内で複数のサービスのクレジット制御を可能にする機能を定義しています。サーバーは、異なるレベルの粒度でクレジットの使用を承認できます。さらに、サーバーは、複数のサービスまたは評価グループにクレジットリソースをプールとして提供する場合があります（詳細と定義については、セクション5.1.2を参照してください）。したがって、サーバーは、サービスロジックと進行中のセッションに関する知識に基づいて、（サブ）セッション全体、単一のクレジットプール、単一のサービス、または単一の評価グループに対してクレジットの再承認を要求することを決定できます。 。クレジットプールのクレジット再承認をリクエストするために、サーバーはRARメッセージに、影響を受けるプールを示すG-S-U-Pool-Identifier AVPを含めます。サービスまたは評価グループのクレジットの再承認を要求するために、サーバーはRARメッセージにそれぞれサービス識別子AVPまたは評価グループAVPを含めます。 （サブ）セッション内で進行中のすべてのサービスのクレジット再承認を要求するために、サーバーはRARメッセージに上記のAVPを含めません。
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., a 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).
クレジット再認証がまだ進行中でない場合（つまり、クレジット制御セッションがオープン状態である場合）、現在アクティブなクレジット制御セッションと等しいセッションIDを持つRARメッセージを受信するクレジット制御クライアントは、 Re-Auth-Answer（RAA）メッセージを送信してリクエストを送信し、CC-Request-Type AVPの値をUPDATE_REQUESTに設定したCredit-Control-Requestメッセージを送信して、サーバーに向けてクレジットの再承認を開始する必要があります。 Result-Code 2002（DIAMETER_LIMITED_SUCCESS）をRAAメッセージで使用して、手順を完了するために追加のメッセージ（つまり、値がUPDATE_REQUESTのCCRメッセージ）が必要であることを示す必要があります（SHOULD）。サービスに割り当てが割り当てられている場合、クレジット制御クライアントは、使用された割り当てをCredit-Control-Requestで報告する必要があります。クレジットの再承認はユーザーに対して透過的であるため（つまり、クレジット制御クライアントとクレジット制御サーバーの間でのみ行われるため）、エンドユーザーはクレジットの再承認を求められる必要はありません。
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.
ユーザーのセッションで複数のサービスがサポートされている場合、上記の手順は、RARメッセージでサーバーから要求された粒度で実行されます。
If credit re-authorization is ongoing at the time when the RAR message is received (i.e., an 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 consider the server-initiated credit re-authorization process successful upon reception of the RAA message.
RARメッセージが受信された時点でクレジットの再承認が進行中の場合（RAR-CCRの衝突など）、クレジット制御クライアントは要求を正常に確認しますが、新しいクレジットの再承認は開始しません。 Result-Code 2001（DIAMETER_SUCCESS）をRAAメッセージで使用して、クレジットの再認証手順がすでに進行中である（つまり、RARの受信時にクライアントがPendingU状態だった）ことを示す必要があります（SHOULD）。クレジット制御サーバーは、サーバーが開始したクレジット再承認への応答として受信されたかのようにCredit-Control-Requestを処理する必要があり（SHOULD）、RAAメッセージの受信時にサーバー開始のクレジット再承認プロセスが成功したと見なす必要があります。
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., a CCR message with the value UPDATE_REQUEST) is required to complete the procedure. The server processes the received requests and returns an appropriate answer to both requests.
ユーザーのセッションで複数のサービスがサポートされている場合、一部のサービスまたは評価グループに対してクレジットの再承認が既に実行されている間、サーバーはクレジットプール（または（サブ）セッション）のクレジットの再承認を要求する場合があります。この場合、クライアントはRAAメッセージでサーバー要求を確認し、新しいCredit-Control-Requestメッセージを送信して、残りのサービス/評価グループの再認証を実行する必要があります。 Result-Code 2002（DIAMETER_LIMITED_SUCCESS）は、手順を完了するために追加のメッセージ（つまり、値がUPDATE_REQUESTのCCRメッセージ）が必要であることを示すために、RAAメッセージで使用する必要があります（SHOULD）。サーバーは受信した要求を処理し、両方の要求に適切な応答を返します。
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.
上記で定義した手順は、アクティブになる可能性のあるDiameter Credit-Controlサブセッションのそれぞれに対して有効になります。サーバーは、Session-Id AVPに加えてRARメッセージにCC-Sub-Session-Id AVPを含めることにより、アクティブなサブセッションの再承認を要求できます（MAY）。
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 -- from 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. This feature MAY be supported by the credit-control server. Credit-control client implementations MUST support the Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP with at least the teardown of the ongoing service session once the subscriber has consumed all the final granted units.
このセクションでは、オプションの適切なサービス終了機能を定義します。この機能は、クレジット制御サーバーによってサポートされる場合があります。クレジットコントロールクライアントの実装は、サブスクライバーが最後に許可されたすべてのユニットを消費した後、少なくとも進行中のサービスセッションのティアダウンで、Final-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPをサポートする必要があります。
Where independent credit-control of multiple services in a single credit-control (sub-)session is supported, it is possible to use graceful service termination for each of the services/rating-groups independently. Naturally, the graceful service termination process defined in the following subsections will apply to the specific service/rating-group as requested by the server.
単一のクレジット制御（サブ）セッションで複数のサービスの独立したクレジット制御がサポートされている場合、サービス/評価グループごとに個別に適切なサービス終了を使用できます。当然、以下のサブセクションで定義されているサービスの正常終了プロセスは、サーバーから要求された特定のサービス/評価グループに適用されます。
In some service environments (e.g., NAS), 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 service termination process installs a set of packet filters to restrict the user's access capability only to/from the specified destinations. All the IP packets not matching the filters will be dropped or, possibly, redirected 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 redirection or restriction instructions always take precedence over configured ones.
一部のサービス環境（NASなど）では、適切なサービス終了を使用して、加入者をサービスポータルにリダイレクトし、オンライン残高補充またはホームサービスプロバイダーが提供するその他のサービスを利用できます。この場合、正常なサービス終了プロセスにより、一連のパケットフィルターがインストールされ、ユーザーのアクセス機能が指定された宛先との間でのみ制限されます。フィルターに一致しないすべてのIPパケットはドロップされるか、サービスポータルにリダイレクトされる可能性があります。また、アクセスが制限された理由に関する適切な通知がユーザーに送信される場合もあります。これらのアクションは、サーバーからクライアントに明示的に通信されるか、クライアントで「サービスごと」に構成されます。明示的に通知されたリダイレクトまたは制限の指示は、常に構成された指示よりも優先されます。
It is also possible to use 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 case is given in Appendix A.7.
正常なサービス終了を使用して、プリペイドユーザーを、アナウンスを再生し、アカウントを補充するように求めるトップアップサーバーに接続することもできます。この場合、クレジット制御サーバーは、最後に付与されたユニットが消費された後、プリペイドユーザーが接続されるトップアップサーバーのアドレスのみを送信します。このケースの例を付録A.7に示します。
The credit-control server MAY initiate graceful service termination by including the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP in the Credit-Control-Answer to indicate that the message contains the final units for the service.
クレジット制御サーバーは、Final-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPをCredit-Control-Answerに含めることにより、サービスの正常な終了を開始して、メッセージにサービスの最終ユニットが含まれていることを示すことができます。
When the credit-control client receives the Final-Unit-Indication AVP or the QoS-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.
クレジットコントロールクライアントがサーバーからの応答でFinal-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPを受信した場合、その動作はFinal-Unit-Action AVPに示されている値によって異なります。サーバーは、TERMINATE、REDIRECT、またはRESTRICT_ACCESSのアクションを要求できます。
Figure 6 illustrates the graceful service termination procedure described in the following subsections.
図6は、以下のサブセクションで説明する適切なサービス終了手順を示しています。
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-Units)|
| | | CCA(Granted-Units)|<====================|
| Restrictions ->+ |<====================| |
| removed | | |
| : | | |
| OR | CCR(Update) | |
| Validity-Time ->|-------------------->| CCR(Update) |
| expires | |-------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<--------------------|
| Restrictions ->|<--------------------| |
| removed | | |
Figure 6: Optional Graceful Service Termination Procedure
図6：オプションのグレースフルサービス終了手順
In addition, the credit-control server MAY reply with the Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP holding a Granted-Service-Unit (G-S-U) with a zero grant, indicating that the service SHOULD be terminated immediately, and no further reporting is required. Figure 7 illustrates a graceful service termination procedure that applies immediately after receiving a zero grant.
さらに、クレジット制御サーバーは、サービスがすぐに終了する必要があることを示す、Granted-Service-Unit（GSU）がゼロの許可を保持しているFinal-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPで応答してもよい（MAY） 、さらに報告する必要はありません。図7は、ゼロ許可を受け取った直後に適用される適切なサービス終了手順を示しています。
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,
| : | | Zero G-S-U)
| : | |<--------------------|
| |CCA(Final-Unit, Action, |
| | Zero G-S-U) |
| |<---------------------| |
| /////////////// | | |
|/Action and // | | |
|/Restrictions // | | |
|/Start // | | |
| ///////////// | | |
| : | | |
| : | | |
Figure 7: Optional Immediate Graceful Service Termination Procedure
図7：オプションの即時のグレースフルサービス終了手順
The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP with Final-Unit-Action set to 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 or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was present at the command level. The CC-Request-Type AVP in the request is set to the value TERMINATION_REQUEST.
Final-Unit-ActionがTERMINATEに設定されたFinal-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPには、他の情報は含まれません。加入者が最後に許可されたユニットを消費すると、サービス要素はサービスを終了しなければなりません（MUST）。これは、クレジット制御クライアントがサポートされていないFinal-Unit-Action値を受け取ったときに適用されるデフォルトの処理であり、この仕様に準拠するすべてのDiameterクレジット制御クライアント実装によってサポートされなければなりません（MUST）。 Final-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPがアクションTERMINATEをコマンドレベルで示している場合、クレジット制御サーバーへの最後のCredit-Control-Requestメッセージを送信する必要があります。リクエストのCC-Request-Type AVPは、値TERMINATION_REQUESTに設定されます。
The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT indicates to the Service Element supporting this action that, upon consumption of the final granted units, the user MUST be redirected to the address specified in the Redirect-Server AVP or Redirect-Server-Extension AVP as follows.
Final-Unit-ActionがREDIRECTに設定されたFinal-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPは、このアクションをサポートするサービスエレメントに対して、最終的に許可されたユニットの消費時に、ユーザーをリダイレクトする必要があることを示します。 Redirect-Server AVPまたはRedirect-Server-Extension AVPで次のように指定されたアドレス。
The credit-control server sends the Redirect-Server AVP or Redirect-Server-Extension 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 or Redirect-Server-Extension AVP, if possible. When the end user is redirected (by using protocols other 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 scenario is out of scope for this specification.
クレジット制御サーバーは、Redirect-Server AVPまたはRedirect-Server-Extension AVPをCredit-Control-Answerメッセージで送信します。そのような場合、可能であれば、サービス要素はRedirect-Server AVPまたはRedirect-Server-Extension AVPで指定された宛先にユーザーをリダイレクトまたは接続する必要があります。エンドユーザーが（Diameter以外のプロトコルを使用して）指定されたサーバーにリダイレクトされるか、またはトップアップサーバーに接続されると、サブスクライバーがアカウントを補充する前に、追加の承認（およびおそらく認証）が必要になる場合があります。ただし、このシナリオはこの仕様の範囲外です。
In addition to the Redirect-Server AVP or Redirect-Server-Extension AVP, the credit-control server MAY include one or more Restriction-Filter-Rule AVPs, one or more 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 treat all packets according to the Restriction-Filter-Rule AVPs, Filter-Rule AVPs, and the rules referred to by the Filter-Id AVP. After treatment is applied according to these rules, all traffic that has not been dropped or already forwarded MUST be redirected to the destination specified in the Redirect-Server AVP or Redirect-Server-Extension AVP.
Redirect-Server AVPまたはRedirect-Server-Extension AVPに加えて、クレジット制御サーバーには、1つ以上のRestriction-Filter-Rule AVP、1つ以上のFilter-Rule AVP、または1つ以上のFilter-Id AVPを含めることができます（MAY）。ユーザーが他のサービス（たとえば、ゼロレートサービス）にアクセスできるようにするCredit-Control-Answerメッセージ。このような場合、アクセスデバイスは、Restriction-Filter-Rule AVPs、Filter-Rule AVPs、およびFilter-Id AVPによって参照されるルールに従って、すべてのパケットを処理する必要があります。これらのルールに従って処理が適用された後、ドロップされていないか、まだ転送されていないすべてのトラフィックは、Redirect-Server AVPまたはRedirect-Server-Extension 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.
クレジット制御サーバー以外のエンティティは、Diameterクレジット制御アプリケーションと組み合わせて使用される適切なIPパケットフィルターでアクセスデバイスをプロビジョニングできます。このケースはセクション5.6.3で検討されています。
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 expiration 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 AVPs in the request sent once all the final granted units have been consumed, as an indication to the server that (1) the requested final unit action started and (2) rating and money reservation are not required (when the Multiple-Services-Credit-Control AVP is used, the Service-Identifier AVP or the Rating-Group AVP is included to indicate the services concerned). Naturally, the Credit-Control-Answer message does not contain any granted service units 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.
最後に許可されたユニットが消費されると、信用管理クライアントは中間の問い合わせを実行しなければなりません（MUST）。この問い合わせの目的は、指定されたアクションが開始されたことをクレジット制御サーバーに示し、使用されたユニットを報告することです。信用管理サーバーは、エンドユーザーのアカウントから使用量を差し引く必要がありますが、新しい信用予約をしてはなりません。ただし、与信管理クライアントは、有効期限の満了時や、セッションに影響するセッション中のサービスイベントなどで、レーティングとマネーリザベーションが必要になる可能性のある、最後に許可されたすべてのユニットが消費される前に、中間の問い合わせを送信できます。現在のサービスの評価。したがって、信用管理クライアントは、（1）要求された最終ユニットアクションが開始されたこと、および（2）レーティングがサーバーに示されるように、最後に許可されたすべてのユニットが消費されたときに送信されるリクエストに、レーティング関連のAVPを含めてはなりません（MUST NOT）。およびお金の予約は必要ありません（Multiple-Services-Credit-Control AVPを使用する場合、サービス識別子AVPまたはRating-Group AVPが含まれ、関連するサービスを示します）。当然、Credit-Control-Answerメッセージには付与されたサービスユニットが含まれておらず、新しい中間の問い合わせが送信される前にサブスクライバーがネットワークリソースの使用を許可される期間をクレジット制御クライアントに示すValidity-Time AVPを含める必要があります。サーバー。
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 their account, whether they 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, a new quota will be returned, and 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.
Validity-Timeの期限が切れると、クレジットコントロールクライアントは通常どおりCredit-Control-Request（UPDATE_REQUEST）を送信します。レポートする割り当て量が割り当てられていないため、このメッセージには、Used-Service-Unit AVPは含まれていません。クレジット管理サーバーはリクエストを処理し、クレジット予約を実行しなければなりません。この期間中に加入者がアカウントを補充しなかった場合、接続が切断されるか、無期限にクレジット制御サーバーによって制御されないサービスへのアクセスが許可されるかは、ホームサービスプロバイダーのポリシーによって異なります。 （注：後者のオプションは、クレジットコントロールの終了時にサービス要素が制限フィルターを削除しないことを意味します。）サーバーは、適切なResult-Code（セクション9.1を参照）をCredit-Control-Answerメッセージで順に返します。ポリシー定義のアクションを実装します。それ以外の場合は、新しいクォータが返され、サービス要素は通常のサービス終了プロセスによってアクティブ化される可能性のあるすべての制限を削除し、通常どおりクレジット制御セッションとサービスセッションを継続する必要があります。
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 case is given in Appendix A.8 (Figure 18).
クレジットコントロールクライアントは、Validity-Timeの期限が切れるまで待機せず、サービスエレメントが、たとえばエンドユーザーとトップの間の通信を判別できる場合、自発的な更新（新しいCredit-Control-Request）を送信することがあります。アップサーバーが行われた。このケースの例を付録A.8に示します（図18）。
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. When the credit-control client receives (at either the session level or a service-specific level) a Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP, together with Validity-Time AVPs, but without a Granted-Service-Unit AVP, it immediately starts the graceful service termination process without sending any messages to the server. An example of this case is illustrated in Appendix A.8 (Figure 18).
クレジット制御サーバーは、最初の問い合わせのために上記のプロセスをすでに開始している場合があることに注意してください。ただし、この最初の問い合わせが実行されるとき、ユーザーのアカウントは空である可能性があります。この場合、加入者はアカウントを補充してサービスを継続する機会を提供されます。信用管理クライアントが（セッションレベルまたはサービス固有レベルのいずれかで）Final-Unit-Indication AVPまたはQoS-Final-Unit-Indication AVPをValidity-Time AVPと一緒に、ただしGranted-Serviceなしで受信したとき-Unit AVPは、サーバーにメッセージを送信せずに、すぐに正常なサービス終了プロセスを開始します。このケースの例を付録A.8に示します（図18）。
A Final-Unit-Indication AVP with Final-Unit-Action set to RESTRICT_ACCESS indicates to the device supporting this action that, upon consumption of the final granted units, 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 Final-Unit-Indication group AVP of the Credit-Control-Answer message.
Final-Unit-ActionがRESTRICT_ACCESSに設定されたFinal-Unit-Indication AVPは、このアクションをサポートするデバイスに、最終的に許可されたユニットの消費時に、Restriction-で指定されたIPパケットフィルターに従ってユーザーのアクセスを制限する必要があることを示します。 Filter-Rule AVP（s）、またはFilter-Id AVP（s）によって識別されたIPパケットフィルターに従って。クレジットコントロールサーバーは、Credit-Control-AnswerメッセージのFinal-Unit-IndicationグループAVPにRestriction-Filter-Rule AVPまたはFilter-Id AVPを含める必要があります（SHOULD）。
A QoS-Final-Unit-Indication AVP with Final-Unit-Action set to RESTRICT_ACCESS indicates to the device supporting this action that, upon consumption of the final granted units, the actions specified in Filter-Rule AVP(s) MUST restrict the traffic according to the classifiers in the Filter-Rule AVP(s). If one or more Filter-Id AVPs are provided in the Credit-Control-Answer message, the credit-control client MUST restrict the traffic according to the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Filter-Rule AVP or the Filter-Id AVP in the QoS-Final-Unit-Indication group AVP of the Credit-Control-Answer message.
Final-Unit-ActionがRESTRICT_ACCESSに設定されたQoS-Final-Unit-Indication AVPは、このアクションをサポートするデバイスに、最終的に許可されたユニットの消費時に、フィルタールールAVPで指定されたアクションがトラフィックを制限する必要があることを示します。 Filter-Rule AVPの分類子に従って。 1つ以上のFilter-Id AVPがCredit-Control-Answerメッセージで提供されている場合、クレジット制御クライアントは、Filter-Id AVPによって識別されたIPパケットフィルターに従ってトラフィックを制限する必要があります。クレジットコントロールサーバーは、クレジットコントロールアンサーメッセージのQoS-Final-Unit-IndicationグループAVPにFilter-Rule AVPまたはFilter-Id AVPを含める必要があります（SHOULD）。
If both the Final-Unit-Indication AVP and the QoS-Final-Unit-Indication AVP exist in the Credit-Control-Answer message, a credit-control client that supports the QoS-Final-Unit-Indication AVP SHOULD follow the directives included in the QoS-Final-Unit-Indication AVP and SHOULD ignore the Final-Unit-Indication AVP.
Final-Unit-Indication AVPとQoS-Final-Unit-Indication AVPの両方がCredit-Control-Answerメッセージに存在する場合、QoS-Final-Unit-Indication AVPをサポートするクレジット制御クライアントは、含まれているディレクティブに従う必要があります（SHOULD）。 QoS-Final-Unit-Indication AVPでは、Final-Unit-Indication 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 rules 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.
クレジット制御サーバー以外のエンティティは、Diameterクレジット制御アプリケーションと組み合わせて使用される適切なIPパケットフィルターでアクセスデバイスをプロビジョニングできます。このようなエンティティは、たとえば、Diameter Credit-ControlアプリケーションがRESTRICT_ACCESSまたはREDIRECTを示すときに渡されるIPフローを使用してアクセスデバイスを構成できます。アクセスデバイスは、他のエンティティによって構成された可能性があるルールに加えて、Credit-Control-Answerメッセージで受信された可能性があるフィルタールールに従って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 filters. Therefore, it is RECOMMENDED that credit-control server implementations supporting graceful service termination be configurable for sending the Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id AVP, or none of the above.
Diameter Credit-Controlアプリケーションと連携して動作する別のエンティティが、エンドユーザーに必要なすべてのフィルタールールを使用してアクセスデバイスをすでにプロビジョニングしている場合、クレジット制御サーバーは追加のフィルターを送信する必要がないと考えられます。したがって、適切なサービスの終了をサポートするクレジット制御サーバーの実装は、Restriction-Filter-Rule AVP、Filter-Rule AVP、Filter-Id AVPを送信するように構成できるか、または上記のいずれも構成できないようにすることをお勧めします。
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 Section 5.6.2.
最後に許可されたユニットが消費されると、信用管理クライアントは中間の問い合わせを実行しなければなりません（MUST）。クレジット制御クライアントとクレジット制御サーバーは、この中間問い合わせを処理し、セクション5.6.2で指定されている後続の手順を実行します。
The credit-control server may initiate graceful service termination when replying with the action RESTRICT_ACCESS for the first interrogation. This is similar to the behavior specified in Section 5.6.2.
クレジット制御サーバーは、最初の問い合わせに対してアクションRESTRICT_ACCESSで応答すると、正常なサービス終了を開始できます。これは、5.6.2項で指定された動作に似ています。
Once the subscriber replenishes the account, they presumably expect all the restrictions applied by the graceful service 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 a new Granted-Service-Unit AVP, all the possible restrictions activated for the purpose of graceful service termination MUST be removed in the Service Element. The credit-control session and the service session continue as usual.
サブスクライバーがアカウントを補充すると、おそらく、サービスの正常終了手順によって適用されるすべての制限がすぐに削除され、無制限のサービスアクセスが再開されることを期待しています。最高のユーザーエクスペリエンスのために、クレジットコントロールサーバーの実装は、サーバーが開始するクレジットの再承認をサポートしてもよい（セクション5.5を参照）。このような場合、アカウントが正常にチャージされると、クレジット制御サーバーは再認証リクエスト（RAR）メッセージを送信して、クレジットの再承認を要求します。クレジット制御クライアントは、CC-Request-Type AVPを値UPDATE_REQUESTに設定してCredit-Control-Requestメッセージを送信することにより、クレジットの再認証を開始します。レポートする割り当て量が割り当てられていないため、Used-Service-Unit AVPはリクエストに含まれていません。 Requested-Service-Unit AVPがリクエストに含まれる場合があります。クレジットコントロールクライアントが新しいGranted-Service-Unit AVPを使用してCredit-Control-Answerを正常に受信した後、サービスの正常な終了のためにアクティブ化されたすべての可能な制限をサービス要素から削除する必要があります。与信管理セッションとサービスセッションは通常どおり続行されます。
The CCFH, as described in this section, determines the behavior of the credit-control client in fault situations. The CCFH may be (1) received from the Diameter home AAA server, (2) received from the credit-control server, or (3) 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 values.
このセクションで説明するように、CCFHは、障害が発生した場合のクレジット制御クライアントの動作を決定します。 CCFHは、（1）DiameterホームAAAサーバーから受信される、（2）クレジット制御サーバーから受信される、または（3）ローカルで構成されます。ホームAAAサーバーから受信したCCFH値は、ローカルに構成された値をオーバーライドします。 Credit-Control-AnswerメッセージでCredit-Controlサーバーから受信した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 [RFC6733]. It is RECOMMENDED that the client complement the credit-control failure procedures with a backup accounting flow toward an accounting server. By using different combinations of the Accounting-Realtime-Required AVP and the CCFH, different safety levels can be built. For example, by choosing a CCFH equal to CONTINUE for the credit-control flow and an Accounting-Realtime-Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the service can be granted 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.
[RFC6733]で定義されているように、認可サーバーは、アカウンティングサーバーへのアカウンティングレコードの送信が一時的に阻止された場合にどうするかを決定するために、Accounting-Realtime-Required AVPを含めることができます。クライアントがクレジット制御の失敗の手順を、アカウンティングサーバーへのバックアップアカウンティングフローで補完することをお勧めします。 Accounting-Realtime-Required AVPとCCFHのさまざまな組み合わせを使用することで、さまざまな安全レベルを構築できます。たとえば、クレジット制御フローのCONTINUEに等しいCCFHと、アカウンティングフローのDELIVER_AND_GRANTに等しいAccounting-Realtime-Required AVPを選択することにより、クレジット制御への接続であっても、サービスをエンドユーザーに付与できます。アカウンティングサーバーがアカウンティング情報を収集でき、アカウンティングサーバーとクレジットコントロールサーバー間で情報交換が行われている限り、サーバーはダウンしています。
As the credit-control application is based on real-time bidirectional 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 [RFC6733]. As a consequence, the credit-control server might receive duplicate messages. These duplicate 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-Session-Failover AVPの値によって異なります。ただし、[RFC6733]で説明されているように、ピアでトランスポート障害が検出された場合、クレジット制御クライアントとクレジット制御サーバー間のパスの任意の時点でフェイルオーバーが発生する可能性があります。結果として、信用管理サーバーは重複したメッセージを受信する可能性があります。これらの重複したメッセージまたはシーケンス外のメッセージは、クレジット制御サーバーのセッションステートマシン（セクション7）、Session-Id AVP、およびCC-Request-Number 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 credit-control 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-Session-Failover AVPでFAILOVER_SUPPORTEDを示していれば、クレジット制御クライアントはクレジット制御メッセージストリームを代替サーバーに移動できます。ホームDiameter AAAサーバーから受信した、またはローカルで構成されたセカンダリクレジットコントロールサーバー名を、バックアップサーバーのアドレスとして使用できます。 CC-Session-Failover AVPがFAILOVER_NOT_SUPPORTEDに設定されている場合、クレジット制御メッセージストリームをバックアップサーバーに移動してはなりません（MUST NOT）。
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 [RFC3539] defines an application-layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) (defined in [RFC3539]). The recommended default initial value for Tw (Twinit) is 30 seconds. Twinit may be set as low as 6 seconds; however, according to [RFC3539], 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 [RFC6733] is common to several different types of Diameter AAA applications that may be run in the same Service Element. Therefore, tuning the timer for 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 more quickly than would the underlying base protocol. Therefore, this specification defines the Tx timer (as defined in Section 13), which is used by the credit-control client to supervise communication with the credit-control server. When the Tx timer elapses, the credit-control client takes action for the end user according to the CCFH.
AAAトランスポートプロファイル[RFC3539]は、失敗したピアからのフェイルオーバーを可能にし、ウォッチドッグタイマー（Tw）（[RFC3539]で定義）によって制御されるアプリケーション層ウォッチドッグアルゴリズムを定義します。 Tw（Twinit）の推奨されるデフォルトの初期値は30秒です。 Twinitは6秒まで設定できます。ただし、[RFC3539]によると、Twinitの値を低く設定しすぎると、重複の可能性が高まり、偽のフェイルオーバーとフェイルバックの試行が増える可能性があります。 Diameterベースプロトコル[RFC6733]は、同じサービスエレメントで実行されるいくつかの異なるタイプのDiameter AAAアプリケーションに共通です。したがって、Diameter Credit-Controlアプリケーションなどのリアルタイムアプリケーションの要件を満たすために、Twinitのタイマーを低い値に調整すると、必ず上記の問題が発生します。ただし、プリペイドサービスの場合、エンドユーザーは妥当な時間内にネットワークからの応答を期待します。したがって、Diameter Credit-Controlクライアントは、基礎となる基本プロトコルよりも迅速に反応します。したがって、この仕様は、Txタイマーを定義します（セクション13で定義）。これは、クレジット制御クライアントがクレジット制御サーバーとの通信を監視するために使用します。 Txタイマーが経過すると、クレジット制御クライアントはCCFHに従ってエンドユーザーのアクションを実行します。
When the Tx timer expires, the Diameter Credit-Control client always terminates the service if the CCFH 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 the Tx timer expires. Therefore, the value TERMINATE is not appropriate if proper failover behavior is desired.
Txタイマーが期限切れになると、CCFHの値がTERMINATEに設定されている場合、Diameter Credit-Controlクライアントは常にサービスを終了します。 Txタイマーが期限切れになる前にプロトコルエラーDIAMETER_TOO_BUSYまたはDIAMETER_UNABLE_TO_DELIVERを受信した場合にのみ、クレジット制御セッションを代替サーバーに移動できます。したがって、適切なフェイルオーバー動作が必要な場合、値TERMINATEは適切ではありません。
If the CCFH is set to the value CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the end user when the Tx timer 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 recommended Tx timeout value.) The credit-control client SHOULD grant the service to the end user, start monitoring 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 retransmitted 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.
CCFHの値がCONTINUEまたはRETRY_AND_TERMINATEに設定されている場合、Txタイマーの期限が切れると、サービスがエンドユーザーに許可されます。与信管理サーバーへのパスでベースプロトコルトランスポートフェイルオーバーが発生した場合、許可されたユニットを含む応答メッセージが後で到着することがあります。 （Twinitのデフォルト値は、推奨されるTxタイムアウト値の3倍です。）クレジット制御クライアントは、エンドユーザーにサービスを許可し、リソース使用状況の監視を開始し、リクエストのタイムアウトまで遅延応答が発生するのを待ちます（例：120秒）。リクエストが失敗し、CC-Session-Failover AVPがFAILOVER_NOT_SUPPORTEDに設定されている場合、クレジット制御クライアントは、CCFHに設定された値に応じて、サービスを終了または続行し、クレジット用に予約されたすべてのリソースを解放する必要があります。制御セッション。プロトコルエラーDIAMETER_UNABLE_TO_DELIVERまたはDIAMETER_TOO_BUSYが受信されるか、要求がタイムアウトし、CC-Session-Failover AVPがFAILOVER_SUPPORTEDに設定されている場合、可能であれば、クレジット制御クライアントは要求をバックアップサーバーに送信できます（MAY）。信用管理クライアントは、バックアップサーバーから成功した応答を受信すると、そのようなサーバーとの信用管理セッションを続行します。再送信された要求も失敗した場合、クレジット制御クライアントは（CCFHで設定された値に応じて）サービスを終了または続行し、クレジット制御セッション用に予約されたすべてのリソースを解放する必要があります。
If a communication failure occurs during the graceful service termination procedure, the Service Element SHOULD always terminate the ongoing service session.
正常なサービス終了手順中に通信障害が発生した場合、サービス要素は常に進行中のサービスセッションを終了する必要があります（SHOULD）。
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 secondary credit-control servers. Implementations supporting credit-control session failover MUST also ensure proper detection of duplicate or out-of-sequence messages. Communication between the servers is regarded as an implementation issue and is outside the scope of this specification.
クレジット制御サーバー間のフェイルオーバーをサポートするために、クレジット制御セッションとアカウント状態に関する情報転送は、プライマリとセカンダリのクレジット制御サーバー間で行われる必要があります。クレジット制御セッションのフェイルオーバーをサポートする実装は、重複したメッセージまたは順序が正しくないメッセージの適切な検出も保証する必要があります。サーバー間の通信は実装の問題と見なされ、この仕様の範囲外です。
The one-time event is used when there is no need to maintain any state in the Diameter Credit-Control server -- for example, inquiring about the price of the service. The use of a one-time event implies that the user has been authenticated and authorized beforehand.
1回限りのイベントは、Diameter Credit-Controlサーバーで状態を維持する必要がない場合（たとえば、サービスの価格について問い合わせる場合）に使用されます。ワンタイムイベントの使用は、ユーザーが事前に認証および承認されていることを意味します。
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 reservations. It can also be used for refunding service units on the user's account or for direct debiting without any credit reservations. The one-time event is shown in Figure 8.
ワンタイムイベントは、クレジットコントロールクライアントがサービスイベントのコストを知りたい場合、またはクレジット予約なしでアカウントの残高を確認したい場合に使用できます。また、ユーザーアカウントのサービスユニットの払い戻しや、クレジット予約なしの口座引き落としにも使用できます。ワンタイムイベントを図8に示します。
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Request | | |
|------------------>| | |
| | CCR(Event) | |
| |------------------->| CCR(Event) |
| | |------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------|
| Service Delivery |<-------------------| |
|<----------------->| | |
Figure 8: One-Time Event
図8：ワンタイムイベント
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回限りのイベントをサービス要素から直接クレジット制御サーバーに送信できます。
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 estimate 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 in 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 Credit-Controlクライアントは、CC-Request-Type AVPをEVENT_REQUESTに設定し、Requested-Action AVPをPRICE_ENQUIRYに設定し、要求されたサービスイベント情報をCredit-のService-Identifier AVPに設定する必要があります。 Control-Requestメッセージ。追加のサービスイベント情報は、サービス固有のAVPとして、またはService-Parameter-Info AVP内で送信できます。 Service-Context-Id AVPは、リクエストに適用可能なサービス固有のドキュメントを示します。
The credit-control server calculates the cost of the requested service event, but it does not perform any account-balance checks or credit reservations 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-Control-AnswerメッセージのCost-Information AVPでクレジット制御クライアントに返されます。
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 Credit-Controlクライアントは、エンドユーザーのアカウント残高が特定のサービスのコストをカバーしていることを確認するだけでよく、照会時にアカウントのユニットを予約する必要はありません。このメソッドは、Diameter Credit-Controlクライアントが別のリクエストでアカウントの借方記入をリクエストしたときにクレジットが残ることを保証しません。
A Diameter Credit-Control client requesting a 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 or Subscription-Id-Extension 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クレジットコントロールクライアントは、CC-Request-Type AVPをEVENT_REQUESTに設定し、Requested-Action AVPをCHECK_BALANCEに設定し、Subscription-Id AVPまたはSubscription-Id-Extension AVPを含める必要があります。与信管理サーバーでエンドユーザーを識別します。 Service-Context-Id AVPは、リクエストに適用可能なサービス固有のドキュメントを示します。
The credit-control server makes the balance check, but it does not make any credit reservations from the account.
与信管理サーバーは残高チェックを行いますが、口座からの与信予約は行いません。
The result of the 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 / NO_CREDIT）は、Credit-Control-AnswerメッセージのCheck-Balance-Result AVPでクレジット制御クライアントに返されます。
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 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 Credit-Controlクライアントは、口座引き落としに1回限りのイベントシナリオを使用できます。 Diameter Credit-Controlクライアントは、このシナリオが使用されている場合、要求されたサービスイベントの実行が成功することを確認してください。
In the Credit-Control-Request message, the CC-Request-Type AVP is set to the value EVENT_REQUEST and the Requested-Action AVP is set to DIRECT_DEBITING. The Subscription-Id AVP or Subscription-Id-Extension 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-Control-Requestメッセージでは、CC-Request-Type AVPは値EVENT_REQUESTに設定され、Requested-Action AVPはDIRECT_DEBITINGに設定されています。 Subscription-Id AVPまたはSubscription-Id-Extension AVPは、クレジットコントロールサーバーでエンドユーザーを識別するために含める必要があります。 Event-Timestamp AVPはリクエストに含まれる必要があり、サービス要素でサービスイベントがリクエストされた時間を含む必要があります。 Service-Context-Id AVPは、リクエストに適用可能なサービス固有のドキュメントを示します。
If it knows the cost of the service event, the Diameter Credit-Control client MAY include in the Requested-Service-Unit AVP the monetary amount to be charged. 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 Credit-Controlクライアントは、請求される金額をRequested-Service-Unit AVPに含めることができます（MAY）。 Diameter Credit-Controlクライアントがサービスイベントのコストを知らない場合、Requested-Service-Unit AVPには、リクエストされたサービスイベントの数が含まれる場合があります。 Service-Identifier AVPは常に関連するサービスを示します。評価される追加のサービスイベント情報は、サービス固有のAVPとして、またはService-Parameter-Info 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-Service-Unit AVPのタイプが「money」の場合、レーティングは不要ですが、対応する金額がエンドユーザーのアカウントから差し引かれます。
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.
クレジットコントロールサーバーは、DiameterクレジットコントロールクライアントへのCredit-Control-AnswerメッセージでGranted-Service-Unit AVPを返します。 Granted-Service-Unit AVPには、Diameter Credit-Controlクライアントがエンドユーザーに提供できるサービスユニットの量が含まれています。 Granted-Service-Unitのタイプは、サービスイベントのタイプに応じて、時間、量、サービス固有、または金額になります。
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., the service is free of charge).
信用管理サーバーがサービスに信用管理が必要ではないと判断した場合、信用管理が適用されない（サービスは無料など）ことを示す結果コードを含めることができます。
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-Control-Answerメッセージには、要求されたサービスの推定総コストを含むCost-Information AVPも含まれる場合があります。
Some services may refund service units to the end user's account -- for example, gaming services.
ゲームサービスなど、一部のサービスではサービスユニットがエンドユーザーのアカウントに払い戻される場合があります。
The credit-control client MUST set the CC-Request-Type AVP to the value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the Credit-Control-Request message. The Subscription-Id AVP or Subscription-Id-Extension 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-Control-Requestメッセージで、クレジット制御クライアントはCC-Request-Type AVPを値EVENT_REQUESTに設定し、Requested-Action AVPをREFUND_ACCOUNTに設定する必要があります。 Subscription-Id AVPまたはSubscription-Id-Extension AVPは、クレジットコントロールサーバーでエンドユーザーを識別するために含める必要があります。 Service-Context-Id 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 service concerned. 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 Credit-Controlクライアントは、Requested-Service-Unit AVPに返金される金額を含めることができます（MAY）。 Service-Identifier AVPは常に関連するサービスを示します。 Diameter Credit-Controlクライアントが払い戻される金額を知らない場合は、Service-Identifier AVPに加えて、サービス固有のAVPまたは評価される追加のサービスイベント情報を含むService-Parameter-Info AVPを送信する場合があります。
For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP containing the estimated monetary amount of refunded units.
情報提供の目的で、Credit-Control-Answerメッセージには、返金されたユニットの推定金額が含まれるCost-Information AVPが含まれる場合があります。
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 resend 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 [RFC6733]. 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 [RFC6733], Appendix C.
サーバーがセッション状態を維持していないため、1回限りのイベントでは、代替のクレジット管理サーバーへのフェイルオーバーが許可されます。たとえば、クレジット制御クライアントがプロトコルエラーDIAMETER_UNABLE_TO_DELIVERまたはDIAMETER_TOO_BUSYを受信した場合、可能であれば、要求を代替サーバーに再送信できます。クレジット制御クライアントとクレジット制御サーバーの間に、プロトコル透過のDiameterリレーとリダイレクトエージェント、またはDiameterクレジット制御プロキシが存在する場合があります。 [RFC6733]で説明されているように、ピアでトランスポート障害が検出された場合、クレジット制御クライアントとクレジット制御サーバー間のパスの任意の時点でフェイルオーバーが発生する可能性があります。さまざまな理由で要求が重複する可能性があるため、クレジット制御サーバーは、リアルタイムの重複検出を担当します。重複検出の実装の問題は、[RFC6733]の付録Cで説明されています。
When the credit-control client detects a communication failure with the credit-control server, its behavior depends on the requested action. The Tx timer (as defined in Section 13) is used in the credit-control client to supervise communication with the credit-control server.
クレジット制御クライアントがクレジット制御サーバーとの通信障害を検出した場合、その動作は要求されたアクションによって異なります。 Txタイマー（セクション13で定義）は、クレジット制御クライアントで使用され、クレジット制御サーバーとの通信を監視します。
If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and a 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 the backup server.
要求されたアクションがPRICE_ENQUIRYまたはCHECK_BALANCEであり、通信障害が検出された場合、クレジット制御クライアントは、可能であれば、要求メッセージを代替のクレジット制御サーバーに転送する必要があります（SHOULD）。セカンダリクレジットコントロールサーバー名は、ホームDiameter AAAサーバーから受信した場合、バックアップサーバーのアドレスとして使用できます。
If the requested action is DIRECT_DEBITING, the 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 messages 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 values.
要求されたアクションがDIRECT_DEBITINGの場合、DDFHはクレジット制御クライアントの動作を制御します。 DDFHは、ホームDiameter AAAサーバーから受信するか、ローカルに構成できます。与信管理サーバーは、CCFメッセージでDDFHを送信して、その後コンパイルされた口座引き落としイベントに使用することもできます。ホームDiameter AAAサーバーから受信したDDFH値はローカルに構成された値を上書きし、Credit-Control-Answerメッセージでクレジット制御サーバーから受信したDDFH値は常に既存の値を上書きします。
If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT grant the service if, after a possible retransmission attempt to an alternative credit-control server, the credit-control client can eventually determine 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 credit-control application-level non-volatile storage. (Note that resending 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 [RFC6733], Section 3.
DDFHがTERMINATE_OR_BUFFERに設定されている場合、クレジット制御クライアントは、別のクレジット制御サーバーへの再送信の可能性がある試行の後に、クレジット制御クライアントが最終的に結果コードまたはユニットから引き落とされていないという応答メッセージ。それ以外の場合、信用管理クライアントは、エンドユーザーにサービスを許可し、信用管理アプリケーションレベルの不揮発性ストレージにリクエストを保存する必要があります（SHOULD）。 （後でリクエストを再送信しても、サーバーがリクエストを正常に処理したときにユーザーのアカウントが空になる可能性があるため、サービスから引き落とされる保証はありません。）クレジット制御クライアントは、これらのリクエストメッセージを重複の可能性があるものとしてマークする必要があります。 [RFC6733]のセクション3で説明されているように、コマンドヘッダーにTフラグを設定します。
If the DDFH is set to CONTINUE, the service SHOULD be granted, even if credit-control messages cannot be delivered and messages are not buffered.
DDFHがCONTINUEに設定されている場合、クレジット制御メッセージを配信できず、メッセージがバッファリングされていなくても、サービスを許可する必要があります（SHOULD）。
If the Tx timer 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 retransmits the request (marked with the T flag) to a backup credit-control server, if possible. If the retransmitted 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 DDFH is set to TERMINATE_OR_BUFFER. If a failed answer is received for the retransmitted 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.
Txタイマーの期限が切れた場合、クレジット制御クライアントはサービスを続行し、応答の遅延を待つ必要があります。要求がタイムアウトした場合、クレジット制御クライアントは、可能であれば、要求（Tフラグが付いている）をバックアップのクレジット制御サーバーに再送信します。再送信された要求もタイムアウトになった場合、または応答で一時的なエラーが受信された場合、DDFHの値がTERMINATE_OR_BUFFERに設定されていると、クレジット制御クライアントは要求をバッファリングします。再送信された要求に対して失敗した応答を受信した場合、クレジット制御クライアントは、イベントメッセージ用に予約されているすべてのリソースを解放し、DDFHの値に関係なく要求を削除します。
The Credit-Control-Request with the requested action REFUND_ACCOUNT should always be stored in credit-control application-level non-volatile storage in case a temporary failure occurs. The credit-control client MUST mark the retransmitted request message as a possible duplicate by setting the T flag in the command header as described in [RFC6733], Section 3.
一時的な障害が発生した場合に備えて、要求されたアクションREFUND_ACCOUNTを含むCredit-Control-Requestは、常にクレジット制御アプリケーションレベルの不揮発性ストレージに保存する必要があります。クレジットコントロールクライアントは、[RFC6733]のセクション3で説明されているように、コマンドヘッダーにTフラグを設定することにより、再送信されたリクエストメッセージを重複の可能性があるものとしてマークする必要があります。
For stored requests, the implementation may choose to limit the number of retransmission attempts and to define a retransmission interval.
格納された要求の場合、実装は再送信の試行回数を制限し、再送信間隔を定義することを選択できます。
Note that only one entity 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.
与信管理システム内の1つのエンティティのみが重複検出を担当する必要があることに注意してください。特定のレルム内にクレジット制御サーバーが1つしかない場合、クレジット制御サーバーは重複検出を実行する可能性があります。特定のレルムに複数の信用管理サーバーがある場合、責任を負うのは信用管理システムの1つのエンティティのみであり、エンドユーザーのアカウントが同じサービスイベントで複数回引き落とされたり入金されたりしないようにします。
This section defines five credit-control application state machines. The first four state machines are to be observed by credit-control clients.
このセクションでは、5つのクレジット制御アプリケーションステートマシンを定義します。最初の4つのステートマシンは、クレジットコントロールクライアントによって監視されます。
The first state machine describes session-based credit-control where the first interrogation is executed as part of the authorization/ authentication process. The second state machine describes session-based credit-control where the first interrogation is executed after the authorization/authentication process. The requirements regarding what has to be supported for these two state machines are discussed in Section 5.2.
最初のステートマシンは、セッションベースのクレジット制御を記述し、最初の問い合わせは、承認/認証プロセスの一部として実行されます。 2番目のステートマシンは、最初の問い合わせが承認/認証プロセスの後に実行されるセッションベースのクレジット制御を記述します。これら2つのステートマシンで何をサポートする必要があるかに関する要件については、セクション5.2で説明します。
The third state machine describes session-based credit-control for the intermediate and final interrogations. The fourth state machine describes event-based credit-control. These two state machines are to be observed by all implementations that conform to this specification.
3番目のステートマシンは、中間および最終の問い合わせのためのセッションベースのクレジットコントロールを記述します。 4番目のステートマシンは、イベントベースのクレジットコントロールを記述します。これらの2つの状態マシンは、この仕様に準拠するすべての実装で監視されます。
The fifth state machine describes the credit-control session from a credit-control server's perspective.
5番目の状態マシンは、クレジット制御サーバーの観点からクレジット制御セッションを記述します。
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.
状態マシンにリストされていないイベントはエラー状態と見なされなければならず、該当する場合、対応する応答がメッセージの発信者に返されなければなりません（MUST）。
In Tables 3, 4, and 5, the event "failure to send" means that the Diameter Credit-Control client is unable to communicate with the desired destination or, if a 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 (1) the peer being down or (2) a physical link failure in the path to or from the credit-control server.
表3、4、および5で、イベント「送信に失敗」は、Diameter Credit-Controlクライアントが目的の宛先と通信できないこと、またはフェイルオーバー手順がサポートされている場合は、定義済みの代替宛先（例：リクエストがタイムアウトし、応答メッセージが受信されません）。これは、（1）ピアのダウン、または（2）クレジット制御サーバーへの、またはクレジット制御サーバーからのパスでの物理リンク障害が原因である可能性があります。
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. This type of notification may ultimately be received in answer to the retransmitted request to a defined alternative destination, if failover is supported.
イベント「一時的なエラー」は、Diameter Credit-ControlクライアントがCredit-Control-AnswerコマンドのResult-Code AVPでプロトコルエラー通知（DIAMETER_TOO_BUSY、DIAMETER_UNABLE_TO_DELIVER、またはDIAMETER_LOOP_DETECTED）を受け取ったことを意味します。このタイプの通知は、フェイルオーバーがサポートされている場合、定義された代替宛先への再送信された要求に応答して最終的に受信されます。
The event "failed answer" means that the Diameter Credit-Control client received a non-transient failure (permanent failure) notification in the Credit-Control-Answer command. This type of notification may ultimately be received in answer to the retransmitted request to a defined alternative destination, if failover is supported.
「失敗した回答」というイベントは、Diameter Credit-ControlクライアントがCredit-Control-Answerコマンドで非一時的な障害（永続的な障害）の通知を受け取ったことを意味します。このタイプの通知は、フェイルオーバーがサポートされている場合、定義された代替宛先への再送信された要求に応答して最終的に受信されます。
The action "store request" means that a request is stored in 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, an account being empty, or errors defined in [RFC6733].
「正常に処理されませんでした」というイベントは、不明なエンドユーザー、アカウントが空、または[RFC6733]で定義されているエラーなどが原因で、信用管理サーバーがメッセージを処理できなかったことを意味します。
The event "user service terminated" can be triggered for various reasons, e.g., normal user termination, network failure, and ASR (Abort-Session-Request). The Termination-Cause AVP contains information about the reason for termination, as specified in [RFC6733].
イベント「ユーザーサービスの終了」は、通常のユーザー終了、ネットワーク障害、ASR（Abort-Session-Request）などのさまざまな理由でトリガーされます。終了原因AVPには、[RFC6733]で指定されている終了の理由に関する情報が含まれています。
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.
Pending状態のクレジット制御クライアントでの待機時間を制御するために使用されるTxタイマーは、Pending状態の終了時に停止されます。新しい状態がIdleの場合、Txタイマーの停止はステートマシンでは省略されます。Idle状態に移行すると、セッションとそれに関連付けられているすべての変数がクリアされるためです。
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は、それぞれ、初期要求、更新要求、終了要求、イベント要求、またはバッファー要求に関連するクレジット制御要求への応答を待つ保留状態を表します。
In Table 2, failover to a secondary server upon "temporary error" or "failure to send" is not explicitly described. However, moving an ongoing credit-control message stream to an alternative server is possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, as described in Section 5.7.
表2では、「一時的なエラー」または「送信に失敗」した場合のセカンダリサーバーへのフェイルオーバーは明示的に説明されていません。ただし、セクション5.7で説明されているように、CC-Session-Failover AVPがFAILOVER_SUPPORTEDに設定されている場合は、進行中のクレジット制御メッセージストリームを代替サーバーに移動できます。
Resending a credit-control event to an alternative server is supported as described in Section 6.5.
セクション6.5で説明されているように、代替サーバーへのクレジット制御イベントの再送信がサポートされています。
+----------+-------------------------------+-------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send | PendingI |
| | access/service | AA-Request | |
| | | with added | |
| | | CC AVPs, | |
| | | start Tx | |
| | | timer | |
| | | | |
| PendingI | Successful answer to | Grant | Open |
| | AA-Request received | service to | |
| | | end user, | |
| | | stop Tx | |
| | | timer | |
| | | | |
| PendingI | Tx timer expired | Disconnect | Idle |
| | | user/dev | |
| | | | |
| PendingI | Failed AA-Answer received | Disconnect | Idle |
| | | user/dev | |
| | | | |
| PendingI | AA-Answer received with | Grant | Idle |
| | Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingI | User service terminated | Queue | PendingI |
| | | termination | |
| | | event | |
| | | | |
| PendingI | Change in rating condition | Queue | PendingI |
| | | changed | |
| | | rating | |
| | | condition | |
| | | event | |
+----------+-------------------------------+-------------+----------+
Table 2: Session-Based Client State Machine for the First Interrogation with AA-Request
表2：AAリクエストによる最初の問い合わせのためのセッションベースのクライアントステートマシン
+----------+-------------------------------+-------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+-------------------------------+-------------+----------+
| Idle | Client or device requests | Send CC | PendingI |
| | access/service | initial | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| PendingI | Successful CC initial answer | Stop Tx | Open |
| | received | timer | |
| | | | |
| PendingI | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | |
| | CONTINUE | end user | |
| | | | |
| PendingI | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | |
| | | | |
| PendingI | Tx timer expired and CCFH | Terminate | Idle |
| | equal to TERMINATE | end user's | |
| | | service | |
| | | | |
| PendingI | Tx timer expired and CCFH | Grant | PendingI |
| | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | |
| | | | |
| PendingI | CC initial answer received | Terminate | Idle |
| | with Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED or to | service | |
| | USER_UNKNOWN | | |
| | | | |
| PendingI | CC initial answer received | Grant | Idle |
| | with Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingI | Failed CC initial answer | Grant | Idle |
| | received and CCFH equal to | service to | |
| | CONTINUE | end user | |
| | | | |
| PendingI | Failed CC initial answer | Terminate | Idle |
| | received and CCFH equal to | end user's | |
| | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | |
| | | | |
| PendingI | User service terminated | Queue | PendingI |
| | | termination | |
| | | event | |
| | | | |
| PendingI | Change in rating condition | Queue | PendingI |
| | | changed | |
| | | rating | |
| | | condition | |
| | | event | |
+----------+-------------------------------+-------------+----------+
Table 3: Session-Based Client State Machine for the First Interrogation with CCR
表3：CCRによる最初の問い合わせのためのセッションベースのクライアントステートマシン
+----------+-------------------------------+-------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+-------------------------------+-------------+----------+
| Open | Granted unit elapses and no | Send CC | PendingU |
| | final-unit indication | update | |
| | received | req., start | |
| | | Tx timer | |
| | | | |
| Open | Granted unit elapses and | Terminate | PendingT |
| | final unit action equal to | end user's | |
| | TERMINATE received | service, | |
| | | send CC | |
| | | termination | |
| | | req. | |
| | | | |
| Open | Change in rating condition in | Send CC | PendingU |
| | queue | update | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| Open | Service terminated in queue | Send CC | PendingT |
| | | termination | |
| | | req. | |
| | | | |
| Open | Change in rating condition or | Send CC | PendingU |
| | Validity-Time elapses | update | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| Open | User service terminated | Send CC | PendingT |
| | | termination | |
| | | req. | |
| | | | |
| Open | RAR received | Send RAA | PendingU |
| | | followed by | |
| | | CC update | |
| | | req., start | |
| | | Tx timer | |
| | | | |
| PendingU | Successful CC update answer | Stop Tx | Open |
| | received | timer | |
| | | | |
| PendingU | Failure to send, or temporary | Grant | Idle |
| | error and CCFH equal to | service to | |
| | CONTINUE | end user | |
| | | | |
| PendingU | Failure to send, or temporary | Terminate | Idle |
| | error and CCFH equal to | end user's | |
| | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | |
| | | | |
| PendingU | Tx timer expired and CCFH | Terminate | Idle |
| | equal to TERMINATE | end user's | |
| | | service | |
| | | | |
| PendingU | Tx timer expired and CCFH | Grant | PendingU |
| | equal to CONTINUE or to | service to | |
| | RETRY_AND_TERMINATE | end user | |
| | | | |
| PendingU | CC update answer received | Terminate | Idle |
| | with Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED | service | |
| | | | |
| PendingU | CC update answer received | Grant | Idle |
| | with Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE | end user | |
| | | | |
| PendingU | Failed CC update answer | Grant | Idle |
| | received and CCFH equal to | service to | |
| | CONTINUE | end user | |
| | | | |
| PendingU | Failed CC update answer | Terminate | Idle |
| | received and CCFH equal to | end user's | |
| | TERMINATE or to | service | |
| | RETRY_AND_TERMINATE | | |
| | | | |
| PendingU | User service terminated | Queue | PendingU |
| | | termination | |
| | | event | |
| | | | |
| PendingU | Change in rating condition | Queue | PendingU |
| | | changed | |
| | | rating | |
| | | condition | |
| | | event | |
| | | | |
| PendingU | RAR received | Send RAA | PendingU |
| | | | |
| PendingT | Successful CC termination | | Idle |
| | answer received | | |
| | | | |
| PendingT | Failure to send, temporary | | Idle |
| | error, or failed answer | | |
| | | | |
| PendingT | Change in rating condition | | PendingT |
+----------+-------------------------------+-------------+----------+
Table 4: Session-Based Client State Machine for Intermediate and Final Interrogations
表4：中間および最終の問い合わせのためのセッションベースのクライアントステートマシン
+----------+--------------------------------+------------+----------+
| State | Event | Action | New |
| | | | State |
+----------+--------------------------------+------------+----------+
| Idle | Client or device requests a | Send CC | PendingE |
| | one-time service | event | |
| | | req., | |
| | | start Tx | |
| | | timer | |
| | | | |
| Idle | Request in storage | Send | PendingB |
| | | stored | |
| | | request | |
| | | | |
| PendingE | Successful CC event answer | Grant | Idle |
| | received | service to | |
| | | end user | |
| | | | |
| PendingE | Failure to send, temporary | Indicate | Idle |
| | error, failed CC event answer | service | |
| | received, or Tx timer expired; | error | |
| | requested action CHECK_BALANCE | | |
| | or PRICE_ENQUIRY | | |
| | | | |
| PendingE | CC event answer received with | Terminate | Idle |
| | Result-Code equal to | end user's | |
| | END_USER_SERVICE_DENIED or to | service | |
| | USER_UNKNOWN and Tx timer | | |
| | running | | |
| | | | |
| PendingE | CC event answer received with | Grant | Idle |
| | Result-Code equal to | service to | |
| | CREDIT_CONTROL_NOT_APPLICABLE; | end user | |
| | requested action | | |
| | DIRECT_DEBITING | | |
| | | | |
| PendingE | Failure to send, temporary | Grant | Idle |
| | error, or failed CC event | service to | |
| | answer received; requested | end user | |
| | action DIRECT_DEBITING; DDFH | | |
| | equal to CONTINUE | | |
| | | | |
| PendingE | Failed CC event answer | Terminate | Idle |
| | received or temporary error; | end user's | |
| | requested action | service | |
| | DIRECT_DEBITING; DDFH equal to | | |
| | TERMINATE_OR_BUFFER and Tx | | |
| | timer running | | |
| | | | |
| PendingE | Tx timer expired; requested | Grant | PendingE |
| | action DIRECT_DEBITING | service to | |
| | | end user | |
| | | | |
| PendingE | Failure to send; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER | with | |
| | | T flag | |
| | | | |
| PendingE | Temporary error; requested | Store | Idle |
| | action DIRECT_DEBITING; DDFH | request | |
| | equal to TERMINATE_OR_BUFFER; | | |
| | Tx timer expired | | |
| | | | |
| PendingE | Failed answer or answer | | Idle |
| | received with Result-Code | | |
| | equal to END_USER_SERVICE | | |
| | DENIED or to USER_UNKNOWN; | | |
| | requested action | | |
| | DIRECT_DEBITING; Tx timer | | |
| | expired | | |
| | | | |
| PendingE | Failed CC event answer | Indicate | Idle |
| | received; requested action | service | |
| | REFUND_ACCOUNT | error and | |
| | | delete | |
| | | request | |
| | | | |
| PendingE | Failure to send or Tx timer | Store | Idle |
| | expired; requested action | request | |
| | REFUND_ACCOUNT | with | |
| | | T flag | |
| | | | |
| PendingE | Temporary error; requested | Store | Idle |
| | action REFUND_ACCOUNT | request | |
| | | | |
| PendingB | Successful CC answer received | Delete | Idle |
| | | request | |
| | | | |
| PendingB | Failed CC answer received | Delete | Idle |
| | | request | |
| | | | |
| PendingB | Failure to send or temporary | | Idle |
| | error | | |
+----------+--------------------------------+------------+----------+
Table 5: One-Time Event Client State Machine
表5：ワンタイムイベントクライアントステートマシン
+-------+------------------------+--------------------------+-------+
| State | Event | Action | New |
| | | | State |
+-------+------------------------+--------------------------+-------+
| Idle | CC initial request | Send CC initial answer, | Open |
| | received and | reserve units, start Tcc | |
| | successfully processed | | |
| | | | |
| Idle | CC initial request | Send CC initial answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS | |
| | | | |
| Idle | CC event request | Send CC event answer | Idle |
| | received and | | |
| | successfully processed | | |
| | | | |
| Idle | CC event request | Send CC event answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS | |
| | | | |
| Open | CC update request | Send CC update answer, | Open |
| | received and | debit used units, | |
| | successfully processed | reserve new units, | |
| | | restart Tcc | |
| | | | |
| Open | CC update request | Send CC update answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS, debit used | |
| | | units | |
| | | | |
| Open | CC termination request | Send CC termin. answer, | Idle |
| | received and | stop Tcc, debit used | |
| | successfully processed | units | |
| | | | |
| Open | CC termination request | Send CC termin. answer | Idle |
| | received but not | with Result-Code != | |
| | successfully processed | SUCCESS, debit used | |
| | | units | |
| | | | |
| Open | Session supervision | Release reserved units | Idle |
| | timer Tcc expired | | |
+-------+------------------------+--------------------------+-------+
Table 6: Session-Based and Event-Based Server State Machine
表6：セッションベースおよびイベントベースのサーバーステートマシン
This section defines the Credit-Control AVPs that are specific to the Diameter Credit-Control application and that MAY be included in the Diameter Credit-Control messages.
このセクションでは、Diameter Credit-Controlアプリケーションに固有であり、Diameter Credit-Controlメッセージに含めることができるCredit-Control AVPを定義します。
The AVPs defined in this section MAY also be included in authorization commands defined in authorization-specific applications, such as [RFC7155] and [RFC4004], if the first interrogation is performed as part of the authorization/ authentication process, as described in Section 5.2.
このセクションで定義されているAVPは、セクション5.2で説明されているように、最初の問い合わせが許可/認証プロセスの一部として実行される場合、[RFC7155]や[RFC4004]などの許可固有のアプリケーションで定義された許可コマンドにも含まれる場合があります。 。
The Diameter AVP rules are defined in [RFC6733], Section 4. These AVP rules are observed in AVPs defined in this section.
Diameter AVPルールは、[RFC6733]のセクション4で定義されています。これらのAVPルールは、このセクションで定義されたAVPで確認されています。
The following table describes the Diameter AVPs defined in the credit-control application, their AVP Code values, types, and possible flag values. The AVP Flag rules ('M', 'V') are explained in [RFC6733], Section 4.1.
次の表は、信用管理アプリケーションで定義されたDiameter AVP、それらのAVPコード値、タイプ、および可能なフラグ値について説明しています。 AVPフラグルール（「M」、「V」）については、[RFC6733]のセクション4.1で説明しています。
+---------------+
|AVP Flag Rules |
Defined |----+-----+----|
AVP in | | |MUST|
Attribute Name Code Section Data Type |MUST| MAY |NOT |
----------------------------------------------------|----+-----+----|
CC-Correlation-Id 411 8.1 OctetString | | M | V |
CC-Input-Octets 412 8.24 Unsigned64 | M | | V |
CC-Money 413 8.22 Grouped | M | | V |
CC-Output-Octets 414 8.25 Unsigned64 | M | | V |
CC-Request-Number 415 8.2 Unsigned32 | M | | V |
CC-Request-Type 416 8.3 Enumerated | M | | V |
CC-Service-Specific- 417 8.26 Unsigned64 | M | | V |
Units | | | |
CC-Session-Failover 418 8.4 Enumerated | M | | V |
CC-Sub-Session-Id 419 8.5 Unsigned64 | M | | V |
CC-Time 420 8.21 Unsigned32 | M | | V |
CC-Total-Octets 421 8.23 Unsigned64 | M | | V |
CC-Unit-Type 454 8.32 Enumerated | M | | V |
Check-Balance-Result 422 8.6 Enumerated | M | | V |
Cost-Information 423 8.7 Grouped | M | | V |
Cost-Unit 424 8.12 UTF8String | M | | V |
Credit-Control 426 8.13 Enumerated | M | | V |
Credit-Control- 427 8.14 Enumerated | M | | V |
Failure-Handling | | | |
Currency-Code 425 8.11 Unsigned32 | M | | V |
Direct-Debiting- 428 8.15 Enumerated | M | | V |
Failure-Handling | | | |
Exponent 429 8.9 Integer32 | M | | V |
Final-Unit-Action 449 8.35 Enumerated | M | | V |
Final-Unit-Indication 430 8.34 Grouped | M | | V |
QoS-Final-Unit-Indication 669 8.68 Grouped | | M | V |
Granted-Service-Unit 431 8.17 Grouped | M | | V |
G-S-U-Pool-Identifier 453 8.31 Unsigned32 | M | | V |
G-S-U-Pool-Reference 457 8.30 Grouped | M | | V |
Multiple-Services- 456 8.16 Grouped | M | | V |
Credit-Control | | | |
Multiple-Services- 455 8.40 Enumerated | M | | V |
Indicator | | | |
Rating-Group 432 8.29 Unsigned32 | M | | V |
Redirect-Address-Type 433 8.38 Enumerated | M | | V |
Redirect-Server 434 8.37 Grouped | M | | V |
Redirect-Server-Address 435 8.39 UTF8String | M | | V |
Redirect-Server-Extension 665 8.64 Grouped | | M | V |
Redirect-Address- 666 8.65 Address | | M | V |
IPAddress | | | |
Redirect-Address-URL 667 8.66 UTF8String | | M | V |
Redirect-Address-SIP-URI 668 8.67 UTF8String | | M | V |
Requested-Action 436 8.41 Enumerated | M | | V |
Requested-Service-Unit 437 8.18 Grouped | M | | V |
Restriction-Filter-Rule 438 8.36 IPFilterRule| M | | V |
Service-Context-Id 461 8.42 UTF8String | M | | V |
Service-Identifier 439 8.28 Unsigned32 | M | | V |
Service-Parameter-Info 440 8.43 Grouped | | M | V |
Service-Parameter-Type 441 8.44 Unsigned32 | | M | V |
Service-Parameter-Value 442 8.45 OctetString | | M | V |
Subscription-Id 443 8.46 Grouped | M | | V |
Subscription-Id-Data 444 8.48 UTF8String | M | | V |
Subscription-Id-Type 450 8.47 Enumerated | M | | V |
Subscription-Id-Extension 659 8.58 Grouped | | M | V |
Subscription-Id-E164 660 8.59 UTF8String | | M | V |
Subscription-Id-IMSI 661 8.60 UTF8String | | M | V |
Subscription-Id-SIP-URI 662 8.61 UTF8String | | M | V |
Subscription-Id-NAI 663 8.62 UTF8String | | M | V |
Subscription-Id-Private 664 8.63 UTF8String | | M | V |
Tariff-Change-Usage 452 8.27 Enumerated | M | | V |
Tariff-Time-Change 451 8.20 Time | M | | V |
Unit-Value 445 8.8 Grouped | M | | V |
Used-Service-Unit 446 8.19 Grouped | M | | V |
User-Equipment-Info 458 8.49 Grouped | | M | V |
User-Equipment-Info-Type 459 8.50 Enumerated | | M | V |
User-Equipment-Info-Value 460 8.51 OctetString | | M | V |
User-Equipment-Info- 653 8.52 Grouped | | M | V |
Extension | | | |
User-Equipment-Info- 654 8.53 OctetString | | M | V |
IMEISV | | | |
User-Equipment-Info-MAC 655 8.54 OctetString | | M | V |
User-Equipment-Info-EUI64 656 8.55 OctetString | | M | V |
User-Equipment-Info- 657 8.56 OctetString | | M | V |
ModifiedEUI64 | | | |
User-Equipment-Info-IMEI 658 8.57 OctetString | | M | V |
Value-Digits 447 8.10 Integer64 | M | | V |
Validity-Time 448 8.33 Unsigned32 | M | | V |
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. Whoever allocates the Service-Context-Id (i.e., a unique identifier of a service-specific document) is also responsible for defining the content and encoding of the CC-Correlation-Id AVP.
CC-Correlation-Id AVP（AVPコード411）のタイプはOctetStringであり、サービスのさまざまなコンポーネント（トランスポートやサービスレベルなど）に対して生成されたクレジット制御要求を相互に関連付けるための情報が含まれています。 Service-Context-Id（つまり、サービス固有のドキュメントの一意の識別子）を割り当てる人は、CC-Correlation-Id 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 the Session-Id AVP and the CC-Request-Number AVP 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 of the CC-Request-Number AVP to 0 for a credit-control request with a CC-Request-Type AVP of INITIAL_REQUEST (the initial request in a session). The value of the CC-Request-Number AVP should be set 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 the value for the last UPDATE_REQUEST. In the case of event charging (when the CC-Request-Type AVP has the value EVENT_REQUEST), the CC-Request-Number AVP should be set to 0 for a credit-control request.
CC-Request-Number AVP（AVPコード415）はUnsigned32タイプであり、1つのセッション内でこの要求を識別します。 Session-Id AVPはグローバルに一意であるため、Session-Id AVPとCC-Request-Number AVPの組み合わせもグローバルに一意であり、クレジットコントロールメッセージと確認の照合に使用できます。一意の番号を生成する簡単な方法は、CC-Request-Type AVPがINITIAL_REQUEST（セッションの最初の要求）であるクレジット制御要求のCC-Request-Number AVPの値を0に設定することです。 CC-Request-Number AVPの値は、最初のUPDATE_REQUESTの場合は1に、2番目の場合は2に、というように設定する必要があります。TERMINATION_REQUESTの値が最後のUPDATE_REQUESTの値よりも1大きくなるまで続けます。イベント課金の場合（CC-Request-Type AVPの値がEVENT_REQUESTの場合）、クレジット制御要求のCC-Request-Number AVPを0に設定する必要があります。
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 (the value of 0 (zero) is reserved):
CC-Request-Type AVP（AVPコード416）は列挙型であり、Credit-Control-Requestメッセージを送信する理由が含まれています。すべてのCredit-Control-Requestメッセージに存在する必要があります。 CC-Request-Type AVPには次の値が定義されています（値0（ゼロ）は予約されています）。
INITIAL_REQUEST 1
INITIAL_REQUEST 1
This request is used to initiate a credit-control session. It contains credit-control information that is relevant to the initiation.
この要求は、クレジット制御セッションを開始するために使用されます。これには、開始に関連する信用管理情報が含まれています。
UPDATE_REQUEST 2
UPDATE_REQUEST 2
This request contains credit-control information for an existing credit-control session. Credit-control requests of this type 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.
このリクエストには、既存のクレジットコントロールセッションのクレジットコントロール情報が含まれています。このタイプの信用管理リクエストは、割り当てられた割り当てまたは有効期限の満了時に信用管理の再承認が必要になるたびに送信される必要があります。さらに、追加のサービス固有のイベントが自発的なUPDATE_REQUESTをトリガーする場合があります。
TERMINATION_REQUEST 3
TERMINATION_REQUEST 3
This request is sent to terminate a credit-control session. It contains credit-control information relevant to the existing session.
この要求は、クレジット制御セッションを終了するために送信されます。これには、既存のセッションに関連する与信管理情報が含まれています。
EVENT_REQUEST 4
EVENT_REQUEST 4
This request is used when there is no need to maintain any credit-control session state in the credit-control server. It contains all information relevant to the service and is the only request of the service. The reason for this 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.
この要求は、信用管理サーバーで信用管理セッションの状態を維持する必要がない場合に使用されます。これは、サービスに関連するすべての情報を含み、サービスの唯一の要求です。このリクエストの理由については、リクエストアクションAVPで詳しく説明しています。 CC-Request-TypeがEVENT_REQUESTに設定されている場合は、Requested-Action AVPをCredit-Control-Requestメッセージに含める必要があります。
The CC-Session-Failover AVP (AVP Code 418) is of type 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 the case of 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 the backup server.
CC-Session-Failover AVP（AVPコード418）はEnumeratedタイプであり、進行中のクレジット制御セッション中にクレジット制御メッセージストリームをバックアップサーバーに移動することがサポートされているかどうかに関する情報が含まれています。通信障害が発生した場合、クレジット制御サーバーが代替サーバーへのフェイルオーバーをサポートしていれば、クレジット制御メッセージストリームを別の宛先に移動できます。セカンダリクレジットコントロールサーバー名は、ホームDiameter AAAサーバーから受信した場合、バックアップサーバーのアドレスとして使用できます。クレジット制御メッセージストリームの代替サーバーへの移動をサポートするための実装は必要ありません。これには、クレジット制御セッションに関連する情報をバックアップサーバーに移動する必要があるためです。
The following values are defined for the CC-Session-Failover AVP:
CC-Session-Failover AVPには次の値が定義されています。
FAILOVER_NOT_SUPPORTED 0
FAILOVER_NOT_SUPPORTED 0
When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be moved to an alternative destination in the case of a communication failure. This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server.
CC-Session-Failover AVPがFAILOVER_NOT_SUPPORTEDに設定されている場合、通信障害が発生した場合に、クレジット制御メッセージストリームを別の宛先に移動してはなりません（MUST NOT）。これは、AVPが承認サーバーまたはクレジットコントロールサーバーからの応答に含まれていない場合のデフォルトの動作です。
FAILOVER_SUPPORTED 1
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 a 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 an alternative server.
CC-Session-Failover AVPがFAILOVER_SUPPORTEDに設定されている場合、通信障害が発生した場合に、クレジット制御メッセージストリームを別の宛先に移動する必要があります（SHOULD）。クレジット制御メッセージストリームをバックアップサーバーに移動するには、クレジット制御セッションに関連する情報も代替サーバーに転送する必要がある場合があります。
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 AVP and this AVP MUST be unique per sub-session, and 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.
CC-Sub-Session-Id AVP（AVPコード419）はUnsigned64タイプであり、クレジット制御サブセッション識別子が含まれています。 Session-Id AVPとこのAVPの組み合わせはサブセッションごとに一意である必要があり、このAVPの値はすべての新しいサブセッションで1ずつ単調に増加する必要があります。この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. The following values are defined for the Check-Balance-Result AVP:
Check-Balance-Result AVP（AVPコード422）は列挙型で、バランスチェックの結果が含まれます。このAVPは、Requested-Action AVPがCredit-Control-RequestコマンドでCHECK_BALANCEを示している場合にのみ適用されます。 Check-Balance-Result AVPには次の値が定義されています。
ENOUGH_CREDIT 0
ENOUGH_CREDIT 0
There is enough credit in the account to cover the requested service.
アカウントには、要求されたサービスをカバーするのに十分なクレジットがあります。
NO_CREDIT 1
NO_CREDIT 1
There isn't enough credit in the account to cover the requested service.
リクエストされたサービスをカバーするのに十分なクレジットがアカウントにありません。
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 of type "money") of the service in the case of price inquiries, or the accumulated cost estimation in the case of a credit-control session.
コスト情報AVP（AVPコード423）はグループ化されたタイプであり、クレジット制御クライアントがエンドユーザーに透過的に転送できるサービスのコスト情報を返すために使用されます。含まれているUnit-Value AVPには、価格照会の場合のサービスのコスト見積もり（常に「金銭」タイプ）、またはクレジット管理セッションの場合の累積コスト見積もりが含まれます。
The Currency-Code AVP specifies in which currency the cost was given. The Cost-Unit AVP specifies the unit when the service cost is a cost per unit (e.g., cost for the service is $1 per minute).
Currency-Code AVPは、コストが与えられた通貨を指定します。 Cost-Unit AVPは、サービスコストがユニットあたりのコストである場合にユニットを指定します（たとえば、サービスのコストは1分あたり1ドルです）。
When the Requested-Action AVP with the 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 for the requested service, without any reservations being made.
値がPRICE_ENQUIRYのRequested-Action AVPがCredit-Control-Requestコマンドに含まれている場合、後続のCredit-Control-Answerコマンドで送信されたCost-Information AVPには、要求されたサービスのコスト見積もりが含まれ、予約は行われません。 。
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 reservations into account.
CC-Request-TypeがUPDATE_REQUESTに設定されたCredit-Control-Answerコマンドに含まれるコスト情報AVPには、クレジット予約を考慮せずに、セッションの累積コスト見積もりが含まれます。
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-Request-TypeがEVENT_REQUESTまたはTERMINATION_REQUESTに設定されたCredit-Control-Answerコマンドに含まれるCost-Information AVPには、要求されたサービスの推定合計コストが含まれています。
The Cost-Information AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
コスト情報AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Cost-Information ::= < AVP Header: 423 >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]
The Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the cost as a floating-point value. The Unit-Value is a significand 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.
Unit-Value AVPはGroupedタイプ（AVPコード445）であり、コストを浮動小数点値として指定します。 Unit-Valueは指数をもつ仮数です。つまり、Unit-Value = Value-Digits AVP * 10 ^ Exponentです。この表現により、不要な丸めが回避されます。たとえば、2,3の値は、Value-Digits = 23およびExponent = -1として表されます。指数部がないことは、ゼロに等しい指数として解釈されなければなりません。
The Unit-Value AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Unit-Value AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Unit-Value ::= < AVP Header: 445 >
{ Value-Digits }
[ Exponent ]
The Exponent AVP is of type Integer32 (AVP Code 429) and contains the exponent value to be applied for the Value-Digits AVP within the Unit-Value AVP.
指数AVPのタイプはInteger32（AVPコード429）であり、Unit-Value AVP内のValue-Digits 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 the Value-Digits AVP MUST be set to 5, and the scaling MUST be indicated with the Exponent AVP set to -2.
Value-Digits AVPのタイプはInteger64（AVPコード447）で、数値の有効数字が含まれています。単位を示すために10進値が必要な場合は、スケーリングを関連する指数AVPで示す必要があります。たとえば、金額が$ 0.05の場合、Value-Digits AVPの値は5に設定する必要があり、スケーリングは、指数AVPを-2に設定して示す必要があります。
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].
通貨コードAVP（AVPコード425）はUnsigned32タイプであり、通貨単位を含むAVPの値が与えられた通貨を指定する通貨コードが含まれています。 ISO 4217標準[ISO4217]で定義されている数値を使用して指定されます。
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 AVP when the service cost is a cost per unit (e.g., cost of the service is $1 per minute). The Cost-Unit setting can be minutes, hours, days, kilobytes, megabytes, etc.
Cost-Unit AVP（AVPコード424）はUTF8Stringタイプであり、人間が読める文字列をエンドユーザーに表示するために使用されます。サービスコストがユニットあたりのコストである場合（たとえば、サービスのコストが1分あたり1ドルである場合）は、コスト情報AVPに適用可能なユニットを指定します。コスト単位の設定は、分、時間、日、キロバイト、メガバイトなどにすることができます。
The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST be included in AA-Request messages when the Service Element has credit-control capabilities. The following values are defined for the Credit-Control AVP:
クレジット制御AVP（AVPコード426）は列挙型であり、サービス要素にクレジット制御機能がある場合、AA要求メッセージに含める必要があります。 Credit-Control AVPには次の値が定義されています。
CREDIT_AUTHORIZATION 0
CREDIT_AUTHORIZATION 0
If the home Diameter AAA server determines that the user has a 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.
ホームDiameter AAAサーバーがユーザーにプリペイドサブスクリプションがあると判断した場合、この値は、最初の問い合わせを実行するためにクレジットコントロールサーバーに接続する必要があることを示します。最初の問い合わせを実行し、新しいクレジット制御セッションを開始するために送信されるAA要求では、クレジット制御AVPの値を常に0に設定する必要があります。
RE_AUTHORIZATION 1
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.
この値は、サブスクライバーのクレジット制御セッションが進行中であり、クレジット制御サーバーに接続してはならないことをDiameter AAAサーバーに示します。値1に設定されたCredit-Control AVPは、最初の問い合わせが正常に実行され、クレジット制御セッションが進行中の場合にのみ使用されます（つまり、承認の有効期間によってトリガーされる再承認）。この値は、最初の問い合わせを実行するために送信されるAA-Requestで使用してはなりません（MUST NOT）。
The CCFH (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 immediately when there is a reason to believe that the service cannot be charged, or to try failover to an alternative server, if possible. The server could then either terminate or grant the service, should the alternative connection also fail.
CCFH（AVPコード427）は列挙型です。信用管理クライアントは、このAVPの情報を使用して、信用管理サーバーへの信用管理メッセージの送信が、たとえばネットワークの問題により一時的に阻止された場合の対処法を決定します。サービスロジックに応じて、クレジット制御サーバーは、サービスに課金できないと思われる理由がある場合、または可能であれば代替サーバーへのフェイルオーバーを試行する理由がある場合、クライアントにサービスを直ちに終了するように命令できます。代替接続も失敗した場合、サーバーはサービスを終了または許可します。
The following values are defined for the CCFH:
CCFHには次の値が定義されています。
TERMINATE 0
終了0
When the CCFH 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 messages before the Tx timer (as defined in Section 13) expires, the credit-control request is regarded as failed, and the end user's service session is terminated.
CCFHがTERMINATEに設定されている場合、クレジット制御サーバーへの接続がある限り、サービスは許可されなければなりません（MUST）。 Txタイマー（セクション13で定義）が期限切れになる前にクレジット制御クライアントがCredit-Control-Answerメッセージを受信しない場合、クレジット制御要求は失敗したと見なされ、エンドユーザーのサービスセッションが終了します。
This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server.
これは、AVPが承認サーバーまたはクレジットコントロールサーバーからの応答に含まれていない場合のデフォルトの動作です。
CONTINUE 1
続き1
When the CCFH is set to CONTINUE, the credit-control client SHOULD resend the request to an alternative server in the case of transport or temporary failures, provided that (1) a failover procedure is supported in the credit-control server and the credit-control client and (2) an alternative server is available. Otherwise, the service SHOULD be granted, even if credit-control messages can't be delivered.
CCFHがCONTINUEに設定されている場合、トランスポートまたは一時的な障害が発生した場合、クレジット制御クライアントは要求を代替サーバーに再送信する必要があります（SHOULD）（1）フェイルオーバー手順がクレジット制御サーバーとクレジットでサポートされている場合。コントロールクライアントと（2）代替サーバーが利用可能です。それ以外の場合は、信用管理メッセージを配信できない場合でも、サービスを許可する必要があります。
RETRY_AND_TERMINATE 2
RETRY_AND_TERMINATE 2
When the CCFH is set to RETRY_AND_TERMINATE, the credit-control client SHOULD resend the request to an alternative server in the case of transport or temporary failures, provided that (1) a failover procedure is supported in the credit-control server and the credit-control client and (2) an alternative server is available.
CCFHがRETRY_AND_TERMINATEに設定されている場合、トランスポートまたは一時的な障害が発生した場合、クレジット制御クライアントはリクエストを代替サーバーに再送信する必要があります（SHOULD）（1）フェイルオーバー手順がクレジット制御サーバーとクレジットでサポートされている場合。コントロールクライアントと（2）代替サーバーが利用可能です。
Otherwise, the service SHOULD NOT be granted when the credit-control messages can't be delivered.
それ以外の場合、信用管理メッセージを配信できない場合はサービスを許可しないでください。
The DDFH (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.
DDFH（AVPコード428）は列挙型です。クレジット制御クライアントは、このAVPの情報を使用して、たとえば、ネットワーク制御の問題により、クレジット制御サーバーへのクレジット制御メッセージ（Requested-Action AVPがDIRECT_DEBITINGに設定されている）の送信が一時的に阻止された場合の対処法を決定します。
The following values are defined for the DDFH:
DDFHには次の値が定義されています。
TERMINATE_OR_BUFFER 0
TERMINATE_OR_BUFFER 0
When the DDFH 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 credit-control client does not receive any Credit-Control-Answer messages before the Tx timer (as defined in Section 13) expires, 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 resend the request. These requests MUST be marked as possible duplicates by setting the T flag in the command header as described in [RFC6733], Section 3. This is the default behavior if the AVP isn't included in the reply from the authorization server.
DDFHがTERMINATE_OR_BUFFERに設定されている場合、クレジット制御サーバーへの接続がある限り、サービスを許可する必要があります。 Txタイマー（セクション13で定義）が期限切れになる前にクレジット制御クライアントがCredit-Control-Answerメッセージを受信しない場合、クレジット制御要求は失敗したと見なされます。失敗した回答からユニットが引き落とされていないと判断できる場合、クライアントはサービスを終了する必要があります（SHOULD）。それ以外の場合、信用管理クライアントはサービスを許可し、リクエストをアプリケーションレベルの不揮発性ストレージに保存して、リクエストの再送信を試みる必要があります（SHOULD）。 [RFC6733]のセクション3で説明されているように、コマンドヘッダーでTフラグを設定して、これらのリクエストを重複の可能性があるものとしてマークする必要があります。これは、AVPが認証サーバーからの応答に含まれていない場合のデフォルトの動作です。
CONTINUE 1
続き1
When the DDFH is set to CONTINUE, the service SHOULD be granted, even if credit-control messages can't be delivered, and the request should be deleted.
DDFHがCONTINUEに設定されている場合、クレジット制御メッセージを配信できない場合でもサービスを許可する必要があるため（SHOULD）、リクエストを削除する必要があります。
The 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. Note that each instance of this AVP carries units related to one or more services or related to a single rating-group.
Multiple-Services-Credit-Control AVP（AVPコード456）はグループ化されたタイプであり、複数のサービスの独立した信用管理に関連するAVPが含まれています。このAVPの各インスタンスは、1つ以上のサービスに関連する、または単一の評価グループに関連するユニットを運ぶことに注意してください。
The Service-Identifier AVP and the Rating-Group AVP are used to associate the granted units to a given service or rating-group. If both the Service-Identifier AVP and the Rating-Group AVP 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 AVP is present, the Multiple-Services-Credit-Control AVP relates to all the services that belong to the specified rating-group.
Service-Identifier AVPとRating-Group AVPは、付与されたユニットを特定のサービスまたはレーティンググループに関連付けるために使用されます。 Service-Identifier AVPとRating-Group AVPの両方が含まれている場合、サービスユニットのターゲットは常にService-Identifier AVPの値によって示されるサービスです。 Rating-Group AVPのみが存在する場合、Multiple-Services-Credit-Control AVPは、指定されたRating-groupに属するすべてのサービスに関連します。
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 a CC-Unit-Type value of TIME (Section 8.32), then the CC-Time AVP MUST be present.
G-S-U-Pool-Reference AVPにより、サーバーは、指定されたタイプのユニットがプールされていると見なされるクレジットプールを識別するG-S-U-Pool-Identifierを指定できます。 G-S-U-Pool-Reference AVPが存在する場合、指定されたタイプの実際のサービスユニットも存在する必要があります。たとえば、G-S-U-Pool-Reference AVPがCC-Unit-Type値としてTIME（セクション8.32）を指定する場合、CC-Time 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 a 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 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 or QoS-Final-Unit-Indication AVPs MAY be present in a Credit-Control-Answer command as defined in Sections 5.1.2 and 5.6 for graceful service termination.
Requested-Service-Unit AVPには、要求されたサービスユニットの量または要求された金額が含まれる場合があります。これは、最初の問い合わせと、新しい割り当てが要求される中間の問い合わせ内に存在する必要があります。クレジットコントロールクライアントがRequested-Service-Unit AVPをリクエストコマンドに含めない場合（たとえば、エンドユーザーがサービスを終了したと判断したため）、サーバーはユーザーのアカウントから使用量を引き落とす必要がありますただし、対応する回答で新しいクォータを返してはなりません。 Validity-Time、Result-Code、およびFinal-Unit-IndicationまたはQoS-Final-Unit-Indication AVPは、サービスの正常な終了のためにセクション5.1.2および5.6で定義されているように、Credit-Control-Answerコマンドに存在する場合があります。
When both the Tariff-Time-Change AVP and the Tariff-Change-Usage AVP 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. When the client is reporting used units before and after the tariff time change, it MUST use the Tariff-Change-Usage AVP inside the Used-Service-Unit AVP.
Tariff-Time-Change AVPとTariff-Change-Usage AVPの両方が存在する場合、サーバーは同じサービスに関連付けられたGranted-Service-Unit AVPを持つMultiple-Services-Credit-Control AVPの2つの個別のインスタンスを含める必要があります-識別子および/または評価グループ。 2つのクォータが同じプールまたは異なるプールに関連付けられている場合、セクション5.1.2で定義されているクレジットプーリングメカニズムが適用されます。クライアントが関税時間変更の前後に使用済みユニットを報告している場合、Used-Service-Unit AVP内のTariff-Change-Usage AVPを使用する必要があります。
A server not implementing the independent credit-control of multiple services MUST treat the Multiple-Services-Credit-Control AVP as an invalid AVP.
複数のサービスの独立したクレジットコントロールを実装していないサーバーは、Multiple-Services-Credit-Control AVPを無効なAVPとして扱う必要があります。
The Multiple-Services-Credit-Control AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Multiple-Services-Credit-Control AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
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 ]
[ QoS-Final-Unit-Indication ]
*[ AVP ]
The 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. In this case, the client MUST terminate the credit-control session and indicate the reason as DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
Granted-Service-Unit AVP（AVPコード431）はグループ化されたタイプであり、Diameter Credit-Controlクライアントがサービスをリリースするか、新しいCredit-Control-Requestを実行する必要があるまでエンドユーザーに提供できるユニット数が含まれています送信されます。クライアントはすべてのユニットタイプを実装する必要はありません。また、アンサーメッセージ内の不明またはサポートされていないユニットタイプを不正なCCAとして扱う必要があります。この場合、クライアントは信用管理セッションを終了し、Termination-Cause AVPで理由をDIAMETER_BAD_ANSWERとして示す必要があります。
The Granted-Service-Unit AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Granted-Service-Unit AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
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 ]
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-Service-Unit AVP（AVPコード437）はGroupedタイプであり、Diameter Credit-Controlクライアントによって指定された要求されたユニットの量が含まれています。サーバーはすべてのユニットタイプを実装する必要はなく、不明またはサポートされていないユニットタイプを無効なAVPとして扱う必要があります。
The Requested-Service-Unit AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Requested-Service-Unit AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Requested-Service-Unit ::= < AVP Header: 437 >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ 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. Note: The value reported in a Used-Service-Unit AVP is not necessarily related to the grant provided in a Granted-Service-Unit AVP, e.g., the value in this AVP may exceed the value in the grant.
Used-Service-Unit AVPはグループ化されたタイプ（AVPコード446）であり、サービスがアクティブになった時点から、またはセッション中に暫定調査が使用されている場合は、前回の測定が行われた時点から測定された使用単位の量が含まれます。終了しました。注：Used-Service-Unit AVPで報告される値は、Granted-Service-Unit AVPで提供される許可に必ずしも関連しているわけではありません。たとえば、このAVPの値が許可の値を超える場合があります。
The Used-Service-Unit AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Used-Service-Unit AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）。
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 ]
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.
関税時間変更AVP（AVPコード451）のタイプは時間です。これはサーバーからクライアントに送信され、1900年1月1日00:00 UTCからの秒単位の時間を含みます。この時間には、サービスの料金が変更されます。
The tariff change mechanism is optional for the client and server, and it is not used for time-based services (Section 5). If a client does not support the tariff time change mechanism, it MUST treat the Tariff-Time-Change AVP in the Answer message as an incorrect CCA. In this case, the client terminates the credit-control session and indicates the reason as DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
料金変更メカニズムは、クライアントとサーバーではオプションであり、時間ベースのサービスには使用されません（セクション5）。クライアントが関税時間変更メカニズムをサポートしていない場合、クライアントは応答メッセージ内の関税時間変更AVPを誤ったCCAとして扱う必要があります。この場合、クライアントはクレジット制御セッションを終了し、Termination-Cause AVPで理由をDIAMETER_BAD_ANSWERとして示します。
Omission of this AVP means that no tariff change is to be reported.
この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-Time AVP（AVPコード420）のタイプはUnsigned32であり、要求、許可、または使用された時間の長さを秒単位で示します。
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. The CC-Money AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
CC-Money AVP（AVPコード413）はグループ化されたタイプであり、所定の通貨で金額を指定します。通貨コードAVPを含める必要があります。 CC-Money AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
CC-Money ::= < AVP Header: 413 >
{ Unit-Value }
[ Currency-Code ]
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-Total-Octets AVP（AVPコード421）のタイプはUnsigned64であり、方向（送信または受信）に関係なく、要求、許可、または使用されたオクテットの総数が含まれます。
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-Input-Octets AVP（AVPコード412）のタイプはUnsigned64であり、エンドユーザーから受信できる、またはエンドユーザーから受信した、要求、許可、または使用されたオクテットの数が含まれます。
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-Output-Octets AVP（AVPコード414）のタイプはUnsigned64であり、エンドユーザーに送信/送信された、要求、許可、または使用されたオクテットの数が含まれます。
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-Service-Specific-Units AVP（AVPコード417）はタイプUnsigned64で、選択したサービスで提供されるサービス固有のユニットの数（たとえば、イベント、ポイントの数）を指定します。サービス固有のユニットは、常にサービスID AVP（または、Multiple-Services-Credit-Control AVPが使用されている場合は、Rating-Group 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-Change-Usage AVP（AVPコード452）は列挙型であり、ユニットが関税変更の前または後に使用されるか、またはレポート期間中にユニットが関税変更にまたがったかを定義します。この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-Services-Credit-Control AVPの一部としてAnswerメッセージに存在する場合、このAVPは、料金変更イベントの前または後に使用されるユニットが割り当てられるかどうかを定義します。
When the Tariff-Time-Change AVP is present, omission of this AVP in Answer messages means that the single-quota mechanism applies.
Tariff-Time-Change AVPが存在する場合、AnswerメッセージでこのAVPが省略されると、シングルクォータメカニズムが適用されます。
Tariff-Change-Usage can be set to one of the following values:
Tariff-Change-Usageは、次のいずれかの値に設定できます。
UNIT_BEFORE_TARIFF_CHANGE 0
UNIT_BEFORE_TARIFF_CHANGE 0
When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of units allocated for use before a tariff change occurs.
Multiple-Services-Credit-Control AVPに存在する場合、この値は、料金変更が発生する前に使用するために割り当てられたユニットの量を示します。
When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used before a tariff change had occurred.
Used-Service-Unit AVPに存在する場合、この値は、料金変更が発生する前に使用されたリソースユニットの量を示します。
UNIT_AFTER_TARIFF_CHANGE 1
UNIT_AFTER_TARIFF_CHANGE 1
When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of units allocated for use after a tariff change occurs.
Multiple-Services-Credit-Control AVPに存在する場合、この値は、料金変更後に使用するために割り当てられたユニットの量を示します。
When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used after a tariff change had occurred.
Used-Service-Unit AVPに存在する場合、この値は、料金変更後に発生したリソースユニットの量を示します。
UNIT_INDETERMINATE 2
UNIT_INDETERMINATE 2
This value is to be used only in the Used-Service-Unit AVP and indicates the amount of resource 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).
この値は、Used-Service-Unit AVPでのみ使用され、料金変更にまたがるリソースユニットの量を示します（たとえば、メータリングプロセスは、nオクテットのブロックでクレジット制御クライアントに報告し、1つのブロックがまたがります関税の変更）。
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 the Service-Context-Id AVP and the Service-Identifier AVP.
Service-Identifier AVPのタイプはUnsigned32（AVPコード439）で、サービスの識別子が含まれています。要求が関連する特定のサービスは、Service-Context-Id AVPとService-Identifier AVPの組み合わせによって一意に識別されます。
A usage example of this AVP is illustrated in Appendix A.9.
このAVPの使用例を付録A.9に示します。
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 the Service-Context-Id AVP and the Rating-Group AVP.
格付けグループAVPのタイプはUnsigned32（AVPコード432）であり、格付けグループの識別子が含まれています。同じ評価タイプの対象となるすべてのサービスは、同じ評価グループの一部です。リクエストが関連する特定の評価グループは、Service-Context-Id AVPと評価グループAVPの組み合わせによって一意に識別されます。
A usage example of this AVP is illustrated in Appendix A.9.
このAVPの使用例を付録A.9に示します。
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.
G-S-U-Pool-Reference AVP（AVPコード457）はグループ化タイプです。これはCredit-Control-Answerメッセージで使用され、セッション内のクレジットプールに表示されるGranted-Service-Unit AVPを関連付けます。
The G-S-U-Pool-Identifier AVP specifies the credit pool from which credit is drawn for this unit type.
G-S-U-Pool-Identifier AVPは、このユニットタイプのクレジットが引き出されるクレジットプールを指定します。
The CC-Unit-Type AVP specifies the type of units for which credit is pooled.
CC-Unit-Type 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 services or rating-groups associated with the same pool).
Unit-Value AVPは、クレジットプール内のタイプCC-Unit-Typeのサービスユニットと抽象サービスユニット間で（したがって、同じプールに関連付けられている他のサービスまたはレーティンググループのサービスユニットに）変換する乗数を指定します。
The G-S-U-Pool-Reference AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
G-S-U-Pool-Reference AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
G-S-U-Pool-Reference ::= < AVP Header: 457 >
{ G-S-U-Pool-Identifier }
{ CC-Unit-Type }
{ Unit-Value }
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-Pool-Identifier AVP（AVPコード453）はUnsigned32タイプであり、セッション内のクレジットプールを識別します。
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-Unit-Type AVP（AVPコード454）は列挙型であり、クレジットプールにプールされると見なされるユニットのタイプを指定します。
The following values are defined for the CC-Unit-Type AVP:
CC-Unit-Type AVPには次の値が定義されています。
TIME 0 MONEY 1 TOTAL-OCTETS 2 INPUT-OCTETS 3 OUTPUT-OCTETS 4 SERVICE-SPECIFIC-UNITS 5
時間0お金1合計オクテット2入力オクテット3出力オクテット4サービス固有の単位5
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 Validity-Time 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.
Validity-Time AVPのタイプは、Unsigned32（AVPコード448）です。クレジット制御サーバーからクレジット制御クライアントに送信されます。 Validity-Time AVPには、付与されたサービスユニットの有効期間が含まれます。 Validity-Timeの測定は、このAVPを含むCredit-Control-Answerメッセージを受信すると開始されます。付与されたサービスユニットがこのAVPで指定された有効期間内に消費されなかった場合、クレジット制御クライアントは、CC-Request-TypeをUPDATE_REQUESTに設定して、Credit-Control-Requestメッセージをサーバーに送信する必要があります。 Validity-Time AVPの値フィールドは秒単位で指定されます。
The Validity-Time AVP is also used for 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.
Validity-Time AVPは、適切なサービス終了（セクション5.6を参照）にも使用され、指定されたアクション（REDIRECTまたはRESTRICT_ACCESSなど）の開始後にサブスクライバーがネットワークリソースを使用できる期間をクレジット制御クライアントに示します。 Validity-Timeが経過すると、新しい中間問い合わせがサーバーに送信されます。
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-Unit-Indication AVP（AVPコード430）のタイプはGroupedであり、Credit-Control-AnswerまたはAA-AnswerのGranted-Service-Unit AVPにサービスの最終ユニットが含まれていることを示します。これらのユニットの有効期限が切れた後、Diameter Credit-Controlクライアントは、Final-Unit-Action 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-Control-Answerで複数のユニットタイプが受信された場合、最初に期限切れになったユニットタイプにより、クレジットコントロールクライアントは指定されたアクションを実行する必要があります（SHOULD）。
In the first interrogation, the Final-Unit-Indication AVP with Final-Unit-Action set to 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 that the client is 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-Unit-ActionがREDIRECTまたはRESTRICT_ACCESSに設定されたFinal-Unit-Indication AVPが、Granted-Service-Unit AVPなしでCredit-Control-AnswerまたはAA-Answerに存在する場合もあります。これは、クライアントが指定されたアクションをすぐに実行することをDiameter Credit-Controlクライアントに示します。ホームサービスプロバイダーのポリシーがサービスを終了することである場合、当然、サーバーはポリシーで定義されたアクションを実装するために、適切な一時的な障害（セクション9.1を参照）を返す必要があります（SHOULD）。
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-Unit-Action AVPは、ユーザーのアカウントがサービスのコストをカバーできない場合のサービス要素の動作を定義し、Final-Unit-Indication AVPがコマンドに含まれている場合は常に存在する必要があります。
If the Final-Unit-Action AVP is set to TERMINATE, the Final-Unit-Indication group AVP MUST NOT contain any other AVPs.
Final-Unit-Action AVPがTERMINATEに設定されている場合、Final-Unit-IndicationグループAVPに他のAVPを含めることはできません。
If the Final-Unit-Action AVP is set to REDIRECT, the Redirect-Server AVP or the Redirect-Server-Extension AVP (at least one) 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-Unit-Action AVPがREDIRECTに設定されている場合、Redirect-Server AVPまたはRedirect-Server-Extension AVP（少なくとも1つ）が存在する必要があります。 Redirect-Server AVPで指定されたアドレスを介してアクセスできない他のサービスへのアクセスもユーザーに許可されている場合、Restriction-Filter-Rule AVPまたはFilter-Id AVPがCredit-Control-Answerメッセージに存在する場合があります。
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-Unit-Action AVPがRESTRICT_ACCESSに設定されている場合、Restriction-Filter-Rule AVPまたはFilter-Id AVPのいずれかが存在する必要があります（SHOULD）。
The Filter-Id AVP is defined in [RFC7155]. 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-Id AVPは[RFC7155]で定義されています。 Filter-Id AVPを使用して、Diameter Credit-Controlアプリケーション以外の手段（たとえば、ローカルで構成された、または別のエンティティーによって構成された）によって、アクセスデバイスにインストールされたIPフィルターリストを参照できます。
If the Final-Unit-Action AVP is set to REDIRECT and the type of server is not one of the enumerations in the Redirect-Address-Type AVP, then the QoS-Final-Unit-Indication AVP SHOULD be used together with the Redirect-Server-Extension AVP instead of the Final-Unit-Indication AVP.
Final-Unit-Action AVPがREDIRECTに設定されていて、サーバーのタイプがRedirect-Address-Type AVPの列挙の1つでない場合、QoS-Final-Unit-Indication AVPはRedirect- Final-Unit-Indication AVPの代わりにServer-Extension AVP。
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT and the classification of the restricted traffic cannot be expressed using an IPFilterRule, or if actions (e.g., QoS) other than just allowing traffic need to be enforced, then the QoS-Final-Unit-Indication AVP SHOULD be used instead of the Final-Unit-Indication AVP. However, if the credit-control server wants to preserve backward compatibility with credit-control clients that support only [RFC4006], the Final-Unit-Indication AVP SHOULD be used together with the Filter-Id AVP.
Final-Unit-Action AVPがRESTRICT_ACCESSまたはREDIRECTに設定されていて、制限されたトラフィックの分類をIPFilterRuleを使用して表現できない場合、またはトラフィックを許可する以外のアクション（QoSなど）を実施する必要がある場合、QoS- Final-Unit-Indication AVPの代わりに、Final-Unit-Indication AVPを使用する必要があります。ただし、クレジットコントロールサーバーが[RFC4006]のみをサポートするクレジットコントロールクライアントとの下位互換性を維持したい場合は、Final-Unit-Indication AVPをFilter-Id AVPと共に使用する必要があります（SHOULD）。
The Final-Unit-Indication AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Final-Unit-Indication AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]
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-Unit-Action AVP（AVPコード449）は列挙型であり、ユーザーのアカウントがサービスコストをカバーできない場合に実行するアクションをクレジットコントロールクライアントに示します。
Final-Unit-Action can be set to one of the following values:
Final-Unit-Actionは、次のいずれかの値に設定できます。
TERMINATE 0
終了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.
信用管理クライアントは、サービスセッションを終了する必要があります。これはデフォルトの処理であり、クレジット制御クライアントがサポートされていないFinal-Unit-Action値を受け取った場合は常に適用可能であり、この仕様に準拠するすべてのDiameterクレジット制御クライアント実装でサポートされている必要があります。
REDIRECT 1
リダイレクト1
The Service Element MUST redirect the user to the address specified in the Redirect-Server-Address AVP or one of the AVPs included in the Redirect-Server-Extension AVP. The redirect action is defined in Section 5.6.2.
サービス要素は、Redirect-Server-Address AVPまたはRedirect-Server-Extension AVPに含まれるAVPの1つで指定されたアドレスにユーザーをリダイレクトする必要があります。リダイレクトアクションはセクション5.6.2で定義されています。
RESTRICT_ACCESS 2
RESTRICT_ACCESS 2
The access device MUST restrict the user's access according to the filter AVPs contained in the applied Grouped AVP: according to IP packet filters defined in the Restriction-Filter-Rule AVP, according to the packet classifier filters defined in the Filter-Rule AVP, or according to the packet filters identified by the Filter-Id AVP. All of the packets not matching any restriction filters (see Section 5.6.3) MUST be dropped.
アクセスデバイスは、適用されたグループ化されたAVPに含まれているフィルターAVPに従ってユーザーのアクセスを制限する必要があります：Restriction-Filter-Rule AVPで定義されたIPパケットフィルターに従って、Filter-Rule AVPで定義されたパケット分類子フィルターに従って、またはFilter-Id AVPによって識別されたパケットフィルターに従って。制限フィルターに一致しないパケット（セクション5.6.3を参照）はすべてドロップする必要があります。
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 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.
Restriction-Filter-Rule AVP（AVPコード438）のタイプはIPFilterRuleであり、付与されたサービスユニットがなくてもアクセス可能なままであるサービスに対応するフィルタールールを提供します。アクセスデバイスは、サブスクライバーに対して指定されたフィルター規則を構成する必要があり、これらのフィルターに一致しないすべてのパケットをドロップする必要があります。ゼロ、1つ、またはそれ以上のそのようなAVPがCredit-Control-AnswerメッセージまたはAA-Answerメッセージに存在する場合があります。
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.
リダイレクトサーバーAVP（AVPコード434）はグループ化されたタイプであり、アカウントがサービスコストをカバーできない場合にエンドユーザーが接続されるリダイレクトサーバー（HTTPリダイレクトサーバー、SIPサーバーなど）のアドレス情報を含みます。 。 Final-Unit-Action AVPがREDIRECTに設定されている場合に存在する必要があります。
The Redirect-Server AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Redirect-Server AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }
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-Address-Type AVP（AVPコード433）は列挙型であり、Redirect-Server-Address AVPで指定されたアドレスのアドレスタイプを定義します。
Redirect-Address-Type can be set to one of the following values:
Redirect-Address-Typeは、次のいずれかの値に設定できます。
IPv4 Address 0
IPv4アドレス0
The address type is in the form of a "dotted-decimal" IPv4 address, as defined in [RFC791].
[RFC791]で定義されているように、アドレスタイプは「ドット付き10進数」のIPv4アドレスの形式です。
IPv6 Address 1
IPv6アドレス1
The address type is in the form of an IPv6 address, as defined in [RFC4291]. The address MUST conform to the textual representation of the address according to [RFC5952].
[RFC4291]で定義されているように、アドレスタイプはIPv6アドレスの形式です。アドレスは、[RFC5952]によるアドレスのテキスト表現に準拠する必要があります。
Because [RFC5952] is more restrictive than the "RFC 3513" format required by [RFC4006], some legacy implementations may not be compliant with the new requirements. Accordingly, implementations receiving this AVP MAY be liberal in the textual IPv6 representations that are accepted, without raising an error.
[RFC5952]は[RFC4006]で要求される「RFC 3513」形式よりも制限が厳しいため、一部のレガシー実装は新しい要件に準拠していない場合があります。したがって、このAVPを受け取る実装は、エラーを発生させることなく、受け入れられるテキストのIPv6表現で自由になる場合があります。
URL 2
URL 2
The address type is in the form of a Uniform Resource Locator, as defined in [RFC3986].
アドレスタイプは、[RFC3986]で定義されているUniform Resource Locatorの形式です。
SIP URI 3
しＰ うり ３
The address type is in the form of a SIP Uniform Resource Identifier, as defined in [RFC3261].
[RFC3261]で定義されているように、アドレスタイプはSIP Uniform Resource Identifierの形式です。
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-Server-Address AVP（AVPコード435）はUTF8Stringタイプであり、アカウントがサービスをカバーできない場合にエンドユーザーが接続されるリダイレクトサーバー（HTTPリダイレクトサーバー、SIPサーバーなど）のアドレスを定義します。費用。
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-Services-Indicator AVP（AVPコード455）は列挙型であり、Diameter Credit-Controlクライアントが（サブ）セッション内で独立して複数のサービスを処理できるかどうかを示します。このAVPがないことは、複数のサービスの独立した与信管理がサポートされていないことを意味します。
A server not implementing the independent credit-control of multiple services MUST treat the Multiple-Services-Indicator AVP as an invalid AVP.
複数のサービスの独立したクレジットコントロールを実装していないサーバーは、Multiple-Services-Indicator AVPを無効なAVPとして処理する必要があります。
The following values are defined for the Multiple-Services-Indicator AVP:
Multiple-Services-Indicator AVPには次の値が定義されています。
MULTIPLE_SERVICES_NOT_SUPPORTED 0
MULTIPLE_SERVICES_NOT_SUPPORTED 0
The client does not support independent credit-control of multiple services within a (sub-)session.
クライアントは、（サブ）セッション内の複数のサービスの独立したクレジット制御をサポートしていません。
MULTIPLE_SERVICES_SUPPORTED 1
MULTIPLE_SERVICES_SUPPORTED 1
The client supports independent credit-control of multiple services within a (sub-)session.
クライアントは、（サブ）セッション内の複数のサービスの独立したクレジットコントロールをサポートします。
The Requested-Action AVP (AVP Code 436) is of type Enumerated and contains the requested action being sent in a 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-Action AVP（AVPコード436）は列挙型であり、CC-Request-TypeがEVENT_REQUESTに設定されているCredit-Control-Requestコマンドで送信される要求アクションが含まれています。 Requested-Action AVPには次の値が定義されています。
DIRECT_DEBITING 0
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.
これは、Requested-Service-Unit AVPおよび/またはService-Identifier AVPで指定された情報に従ってエンドユーザーのアカウントを減らす要求を示します（追加のレーティング情報がサービス固有のAVPまたはService-Parameter-Info AVPに含まれている場合があります） ）。 Credit-Control-AnswerコマンドのGranted-Service-Unit AVPには、借方単位が含まれています。
REFUND_ACCOUNT 1
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.
これは、Requested-Service-Unit AVPおよび/またはService-Identifier AVPで指定された情報に従ってエンドユーザーのアカウントを増やす要求を示します（追加のレーティング情報がサービス固有のAVPまたはService-Parameter-Info AVPに含まれている場合があります） ）。 Credit-Control-AnswerコマンドのGranted-Service-Unit AVPには、払い戻されたユニットが含まれています。
CHECK_BALANCE 2
CHECK_BALANCE 2
This indicates a balance-check request. In this case, the checking of the account balance is done without any credit reservations from the account. The Check-Balance-Result AVP in the Credit-Control-Answer command contains the result of the balance check.
これは、バランスチェック要求を示します。この場合、口座残高のチェックは、口座からのクレジット予約なしで行われます。 Credit-Control-AnswerコマンドのCheck-Balance-Result AVPには、残高チェックの結果が含まれています。
PRICE_ENQUIRY 3
PRICE_ENQUIRY 3
This indicates a price-inquiry 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.
これは、価格照会リクエストを示します。この場合、口座残高の確認も口座からの予約も行われません。 Credit-Control-AnswerコマンドのCost-Information 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 (as defined in Section 4.1.2) that applies to the request. This is an identifier allocated by the service provider, the Service Element manufacturer, or a standardization body, and MUST uniquely identify a given Diameter Credit-Control service-specific document. The format of the Service-Context-Id is:
Service-Context-Id AVPはUTF8Stringタイプ（AVPコード461）であり、リクエストに適用される（セクション4.1.2で定義されている）Diameter Credit-Controlサービス固有のドキュメントの一意の識別子を含みます。これは、サービスプロバイダー、サービス要素の製造元、または標準化団体によって割り当てられた識別子であり、特定のDiameter Credit-Controlサービス固有のドキュメントを一意に識別しなければなりません（MUST）。 Service-Context-Idの形式は次のとおりです。
"service-context" "@" "domain"
「サービスコンテキスト」「@」「ドメイン」
service-context = Token
The Token is an arbitrary string of characters and digits.
トークンは、文字と数字の任意の文字列です。
"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 Fully Qualified Domain Name (FQDN) of the service provider (e.g., provider.example.com) or the vendor (e.g., vendor.example.com) if the identifier is allocated by a private entity.
「ドメイン」は、Service-Context-Idを割り当てたエンティティを表します。識別子が標準化団体によって割り当てられている場合は、ietf.org、3gpp.orgなどになります。または、サービスプロバイダー（例：provider.example.com）の完全修飾ドメイン名（FQDN）または識別子がプライベートエンティティによって割り当てられている場合は、ベンダー（vendor.example.comなど）。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、Diameterヘッダーのできるだけ近くに配置する必要があります（SHOULD）。
Service-specific documents that are for private use only (i.e., for one provider's own use, where no interoperability is deemed useful) may define private identifiers without a need for coordination. However, when interoperability is desired, coordination of the identifiers via, for example, publication of an informational RFC is RECOMMENDED in order to make the Service-Context-Id AVP globally available.
私的使用のみのサービス固有のドキュメント（つまり、相互運用性が役に立たないと見なされる1つのプロバイダー自身の使用）は、調整を必要とせずに私的識別子を定義できます。ただし、相互運用性が必要な場合は、Service-Context-Id AVPをグローバルに利用できるようにするために、たとえば情報RFCの公開による識別子の調整をお勧めします。
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-Parameter-Info AVP（AVPコード440）はGroupedタイプであり、価格計算または評価に使用されるサービス固有の情報が含まれています。 Service-Parameter-Type AVPはサービスパラメータタイプを定義し、Service-Parameter-Value AVPはパラメータ値を含みます。これらのAVPの実際の内容はこのドキュメントの範囲外であり、別のDiameterアプリケーション、他の標準化団体が作成した標準、またはサービス固有のドキュメントで定義する必要があります。
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-Parameter-Type）の場合、対応する応答メッセージにはエラーコードDIAMETER_RATING_FAILEDが含まれている必要があります。このエラーが発生したCredit-Control-Answerメッセージには、失敗の原因となったService-Parameter-Info AVPを含むFailed-AVP AVPが1つ以上含まれている必要があります。
The Service-Parameter-Info AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Service-Parameter-Info AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Service-Parameter-Info ::= < AVP Header: 440 >
{ Service-Parameter-Type }
{ Service-Parameter-Value }
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., a 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-Parameter-Type AVPはタイプUnsigned32（AVPコード441）であり、サービスイベント固有のパラメーターのタイプを定義します（たとえば、エンドユーザーの場所やサービス名にすることができます）。さまざまなパラメータとそのタイプはサービス固有であり、これらのパラメータの意味はこのドキュメントでは定義されていません。 Service-Context-Id（つまり、サービス固有のドキュメントの一意の識別子）を割り当てる人は、サービスにService-Parameter-Type値を割り当て、特定のサービス内で一意であることも保証します。 Service-Parameter-Value AVPには、サービスパラメータタイプに関連付けられた値が含まれています。
The Service-Parameter-Value AVP is of type OctetString (AVP Code 442) and contains the value of the service parameter type.
Service-Parameter-Value AVPのタイプはOctetString（AVPコード442）で、サービスパラメータタイプの値が含まれています。
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-Id AVP（AVPコード443）は、エンドユーザーのサブスクリプションを識別するために使用され、グループ化されたタイプです。 Subscription-Id AVPには、識別子を保持するSubscription-Id-Data AVPと、識別子タイプを定義するSubscription-Id-Type AVPが含まれます。
The Subscription-Id AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Subscription-Id AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Subscription-Id ::= < AVP Header: 443 >
{ Subscription-Id-Type }
{ Subscription-Id-Data }
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.
Subscription-Id-Type AVP（AVPコード450）は列挙型であり、Subscription-Id AVPが運ぶ識別子のタイプを決定するために使用されます。
This specification defines the following subscription identifiers. However, new Subscription-Id-Type values can be assigned by IANA as defined in Section 12. A server MUST implement all the Subscription-Id-Type values required to perform credit authorization for the services it supports, including possible future values. Unknown or unsupported Subscription-Id-Type values MUST be treated according to the 'M' flag rule, as defined in [RFC6733].
この仕様では、次のサブスクリプション識別子を定義しています。ただし、セクション12で定義されているように、IANAによって新しいSubscription-Id-Type値を割り当てることができます。サーバーは、サポートされるサービスのクレジット認証を実行するために必要なすべてのSubscription-Id-Type値を実装する必要があります。不明またはサポートされていないSubscription-Id-Type値は、[RFC6733]で定義されている「M」フラグルールに従って処理する必要があります。
END_USER_E164 0
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].
[E164]と[CE164]で定義されているITU-T E.164番号計画に従って、識別子は国際的なE.164形式（MSISDNなど）です。
END_USER_IMSI 1
END_USER_IMSI 1
The identifier is in IMSI format, according to the ITU-T E.212 identification plan as defined in [E212] and [CE212].
[E212]および[CE212]で定義されているITU-T E.212識別計画に従って、識別子はIMSI形式です。
END_USER_SIP_URI 2
END_USER_SIP_URI 2
The identifier is in the form of a SIP URI, as defined in [RFC3261].
[RFC3261]で定義されているように、識別子はSIP URIの形式です。
END_USER_NAI 3
End_user_no3
The identifier is in the form of a Network Access Identifier, as defined in [RFC7542].
識別子は、[RFC7542]で定義されているネットワークアクセス識別子の形式です。
END_USER_PRIVATE 4
END_USER_PRIVATE 4
The identifier is a credit-control server private identifier.
識別子は、信用管理サーバーのプライベート識別子です。
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-Id-Data AVP（AVPコード444）はエンドユーザーの識別に使用され、タイプはUTF8Stringです。 Subscription-Id-Type 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 the network.
User-Equipment-Info AVP（AVPコード458）はグループ化されたタイプであり、クレジット制御クライアントは、加入者がネットワークへの接続に使用している端末のIDと機能を示すことができます。
The User-Equipment-Info AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
User-Equipment-Info AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
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-Equipment-Info-Type AVPは列挙型（AVPコード459）で、User-Equipment-Info-Value AVPに含まれるユーザー機器情報のタイプを定義します。
This specification defines the following user equipment types. However, new User-Equipment-Info-Type values can be assigned by IANA as defined in Section 12.
この仕様では、次のユーザー機器タイプを定義しています。ただし、セクション12で定義されているように、IANAによって新しいUser-Equipment-Info-Type値を割り当てることができます。
IMEISV 0
IMEISV 0
The identifier contains the International Mobile Equipment Identifier and Software Version (IMEISV) in the IMEISV format according to 3GPP TS 23.003 [TGPPIMEI].
識別子には、3GPP TS 23.003 [TGPPIMEI]に準拠したIMEISV形式の国際モバイル機器識別子およびソフトウェアバージョン（IMEISV）が含まれています。
MAC 1
MAC 1
The 48-bit Media Access Control (MAC) address is formatted as described in Section 3.21 of [RFC3580].
48ビットのメディアアクセス制御（MAC）アドレスは、[RFC3580]のセクション3.21で説明されているようにフォーマットされます。
EUI64 2
EUI64 2
The 64-bit identifier used to identify the hardware instance of the product, as defined in [EUI64].
[EUI64]で定義されている、製品のハードウェアインスタンスを識別するために使用される64ビットの識別子。
MODIFIED_EUI64 3
MODIFIED_EUI64 3
There are a number of types of terminals that have identifiers other than the International Mobile Equipment Identifier (IMEI), IEEE 802 MACs, or EUI-64. These identifiers can be converted to modified EUI-64 format as described in [RFC4291] or by using some other methods referred to in the service-specific documentation.
International Mobile Equipment Identifier（IMEI）、IEEE 802 MAC、またはEUI-64以外の識別子を持つ端末にはいくつかのタイプがあります。これらの識別子は、[RFC4291]で説明されているように、またはサービス固有のドキュメントで参照されている他の方法を使用して、変更されたEUI-64形式に変換できます。
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.
User-Equipment-Info-Value AVP（AVPコード460）のタイプはOctetStringです。 User-Equipment-Info-Type AVPは、使用される識別子のタイプを定義します。
The User-Equipment-Info-Extension AVP (AVP Code 653) 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 the network. If the type of the equipment is one of the enumerated User-Equipment-Info-Type AVP values, then the credit-control client SHOULD send the information in the User-Equipment-Info AVP, in addition to or instead of the User-Equipment-Info-Extension AVP. This is done in order to preserve backward compatibility with credit-control servers that support only [RFC4006]. Exactly one AVP MUST be included inside the User-Equipment-Info-Extension AVP.
User-Equipment-Info-Extension AVP（AVPコード653）のタイプはGroupedであり、クレジットコントロールクライアントは、加入者がネットワークへの接続に使用している端末のIDと機能を示すことができます。機器のタイプが列挙されたUser-Equipment-Info-Type AVP値の1つである場合、信用管理クライアントは、User-Equipment-Info AVPに加えて、またはUser-Equipmentの代わりに情報を送信する必要があります（SHOULD）。 -Info-Extension AVP。これは、[RFC4006]のみをサポートするクレジット制御サーバーとの下位互換性を維持するために行われます。正確に1つのAVPをUser-Equipment-Info-Extension AVP内に含める必要があります。
The User-Equipment-Info-Extension AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
User-Equipment-Info-Extension AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
User-Equipment-Info-Extension ::= < AVP Header: 653 >
[ User-Equipment-Info-IMEISV ]
[ User-Equipment-Info-MAC ]
[ User-Equipment-Info-EUI64 ]
[ User-Equipment-Info-ModifiedEUI64 ]
[ User-Equipment-Info-IMEI ]
[ AVP ]
The User-Equipment-Info-IMEISV AVP (AVP Code 654) is of type OctetString. The User-Equipment-Info-IMEISV AVP contains the International Mobile Equipment Identifier and Software Version in the IMEISV format according to 3GPP TS 23.003 [TGPPIMEI].
User-Equipment-Info-IMEISV AVP（AVPコード654）のタイプはOctetStringです。 User-Equipment-Info-IMEISV AVPには、3GPP TS 23.003 [TGPPIMEI]に準拠したIMEISV形式の国際モバイル機器識別子とソフトウェアバージョンが含まれています。
The User-Equipment-Info-MAC AVP (AVP Code 655) is of type OctetString. The User-Equipment-Info-MAC AVP contains the 48-bit MAC address; the MAC address is formatted as described in Section 4.1.7.8 of [RFC5777].
User-Equipment-Info-MAC AVP（AVPコード655）のタイプはOctetStringです。 User-Equipment-Info-MAC AVPには、48ビットのMACアドレスが含まれています。 MACアドレスは、[RFC5777]のセクション4.1.7.8の説明に従ってフォーマットされています。
The User-Equipment-Info-EUI64 AVP (AVP Code 656) is of type OctetString. The User-Equipment-Info-EUI64 AVP contains the 64-bit identifier used to identify the hardware instance of the product, as defined in [EUI64].
User-Equipment-Info-EUI64 AVP（AVPコード656）のタイプはOctetStringです。 User-Equipment-Info-EUI64 AVPには、[EUI64]で定義されている、製品のハードウェアインスタンスを識別するために使用される64ビットの識別子が含まれています。
The User-Equipment-Info-ModifiedEUI64 AVP (AVP Code 657) is of type OctetString. 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 [RFC4291] or by using some other methods referred to in the service-specific documentation. The User-Equipment-Info-ModifiedEUI64 AVP contains such identifiers.
User-Equipment-Info-ModifiedEUI64 AVP（AVPコード657）のタイプはOctetStringです。 IMEI、IEEE 802 MAC、またはEUI-64以外の識別子を持つ端末にはいくつかのタイプがあります。これらの識別子は、[RFC4291]で説明されているように、またはサービス固有のドキュメントで参照されている他の方法を使用して、変更されたEUI-64形式に変換できます。 User-Equipment-Info-ModifiedEUI64 AVPには、このような識別子が含まれています。
The User-Equipment-Info-IMEI AVP (AVP Code 658) is of type OctetString. The User-Equipment-Info-IMEI AVP contains the International Mobile Equipment Identifier in the IMEI format according to 3GPP TS 23.003 [TGPPIMEI].
User-Equipment-Info-IMEI AVP（AVPコード658）のタイプはOctetStringです。 User-Equipment-Info-IMEI AVPには、3GPP TS 23.003 [TGPPIMEI]に準拠したIMEI形式のInternational Mobile Equipment Identifierが含まれています。
The Subscription-Id-Extension AVP (AVP Code 659) is used to identify the end user's subscription and is of type Grouped. The Subscription-Id-Extension group AVP MUST include an AVP holding the subscription identifier. The type of this included AVP indicates the type of the subscription identifier. For each of the enumerated values of the Subscription-Id-Type AVP, there is a corresponding sub-AVP for use within the Subscription-Id-Extension group AVP. If a new identifier type is required, a corresponding new sub-AVP SHOULD be defined for use within the Subscription-Id-Extension group AVP.
Subscription-Id-Extension AVP（AVPコード659）は、エンドユーザーのサブスクリプションを識別するために使用され、タイプはGroupedです。 Subscription-Id-ExtensionグループAVPには、サブスクリプション識別子を保持するAVPを含める必要があります。この含まれるAVPのタイプは、サブスクリプションIDのタイプを示します。 Subscription-Id-Type AVPの列挙値ごとに、Subscription-Id-ExtensionグループAVP内で使用するための対応するサブAVPがあります。新しい識別子タイプが必要な場合は、対応する新しいサブAVPをSubscription-Id-ExtensionグループAVP内で使用するために定義する必要があります（SHOULD）。
If full backward compatibility with [RFC4006] is required, then the Subscription-Id AVP MUST be used to indicate identifier types enumerated in the Subscription-Id-Type AVP, whereas the Subscription-Id-Extension AVP MUST be used only for newly defined identifier types. If full backward compatibility with [RFC4006] is not required, then the Subscription-Id-Extension AVP MAY be used to carry the existing identifier types. In this case, the Subscription-Id-Extension AVP MAY be sent together with the Subscription-Id AVP.
[RFC4006]との完全な下位互換性が必要な場合、Subscription-Id-Type AVPで列挙された識別子タイプを示すためにSubscription-Id AVPを使用する必要がありますが、Subscription-Id-Extension AVPは新しく定義された識別子に対してのみ使用する必要がありますタイプ。 [RFC4006]との完全な下位互換性が必要ない場合は、Subscription-Id-Extension AVPを使用して既存の識別子タイプを運ぶことができます（MAY）。この場合、Subscription-Id-Extension AVPはSubscription-Id AVPと一緒に送信される場合があります。
Exactly one sub-AVP MUST be included inside the Subscription-Id-Extension AVP.
正確に1つのサブAVPをSubscription-Id-Extension AVP内に含める必要があります。
The Subscription-Id-Extension AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Subscription-Id-Extension AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Subscription-Id-Extension ::= < AVP Header: 659 >
[ Subscription-Id-E164 ]
[ Subscription-Id-IMSI ]
[ Subscription-Id-SIP-URI ]
[ Subscription-Id-NAI ]
[ Subscription-Id-Private ]
[ AVP ]
The Subscription-Id-E164 AVP (AVP Code 660) is of type UTF8String. The Subscription-Id-E164 AVP contains the international E.164 format (e.g., MSISDN), according to the ITU-T E.164 numbering plan defined in [E164] and [CE164].
Subscription-Id-E164 AVP（AVPコード660）のタイプはUTF8Stringです。 [E164]および[CE164]で定義されているITU-T E.164番号計画に従って、Subscription-Id-E164 AVPには国際E.164形式（MSISDNなど）が含まれています。
The Subscription-Id-IMSI AVP (AVP Code 661) is of type UTF8String. The Subscription-Id-IMSI AVP contains the IMSI format, according to the ITU-T E.212 identification plan as defined in [E212] and [CE212].
Subscription-Id-IMSI AVP（AVPコード661）のタイプはUTF8Stringです。 [E212]および[CE212]で定義されているITU-T E.212識別計画に従って、Subscription-Id-IMSI AVPにはIMSI形式が含まれています。
The Subscription-Id-SIP-URI AVP (AVP Code 662) is of type UTF8String. The Subscription-Id-SIP-URI AVP contains the identifier in the form of a SIP URI, as defined in [RFC3261].
Subscription-Id-SIP-URI AVP（AVPコード662）のタイプはUTF8Stringです。 [RFC3261]で定義されているように、Subscription-Id-SIP-URI AVPにはSIP URIの形式の識別子が含まれています。
The Subscription-Id-NAI AVP (AVP Code 663) is of type UTF8String. The Subscription-Id-NAI AVP contains the identifier in the form of a Network Access Identifier, as defined in [RFC7542].
Subscription-Id-NAI AVP（AVPコード663）のタイプはUTF8Stringです。 [RFC7542]で定義されているように、Subscription-Id-NAI AVPにはネットワークアクセス識別子の形式の識別子が含まれています。
The Subscription-Id-Private AVP (AVP Code 664) is of type UTF8String. The Subscription-Id-Private AVP contains a credit-control server private identifier.
Subscription-Id-Private AVP（AVPコード664）は、UTF8Stringタイプです。 Subscription-Id-Private AVPには、クレジットコントロールサーバーのプライベート識別子が含まれています。
The Redirect-Server-Extension AVP (AVP Code 665) 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 inside the QoS-Final-Unit-Indication AVP when the Final-Unit-Action AVP is set to REDIRECT. If the type of the redirect server is one of the enumerated values of the Redirect-Address-Type AVP, then the credit-control server SHOULD send the information in the Redirect-Server AVP, in addition to or instead of the Redirect-Server-Extension AVP. This is done in order to preserve backward compatibility with credit-control clients that support only [RFC4006]. Exactly one AVP MUST be included inside the Redirect-Server-Extension AVP.
Redirect-Server-Extension AVP（AVPコード665）はタイプGroupedであり、アカウントがアカウントをカバーできない場合にエンドユーザーが接続されるリダイレクトサーバー（HTTPリダイレクトサーバー、SIPサーバーなど）のアドレス情報を含みます。サービス費用。 Final-Unit-Action AVPがREDIRECTに設定されている場合、QoS-Final-Unit-Indication AVP内に存在する必要があります。リダイレクトサーバーのタイプがRedirect-Address-Type AVPの列挙値の1つである場合、クレジット制御サーバーは、Redirect-Server-に加えて、またはRedirect-Server-の代わりに、Redirect-Server AVPで情報を送信する必要があります（SHOULD）。拡張AVP。これは、[RFC4006]のみをサポートするクレジット制御クライアントとの下位互換性を維持するために行われます。 Redirect-Server-Extension AVP内に正確に1つのAVPを含める必要があります。
The Redirect-Server-Extension AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
Redirect-Server-Extension AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
Redirect-Server-Extension ::= < AVP Header: 665 >
[ Redirect-Address-IPAddress ]
[ Redirect-Address-URL ]
[ Redirect-Address-SIP-URI ]
[ AVP ]
The Redirect-Address-IPAddress AVP (AVP Code 666) is of type Address and defines the IPv4 or IPv6 address of the redirect server with which the end user is to be connected when the account cannot cover the service cost.
Redirect-Address-IPAddress AVP（AVPコード666）はアドレスタイプであり、アカウントがサービスコストをカバーできない場合にエンドユーザーが接続されるリダイレクトサーバーのIPv4またはIPv6アドレスを定義します。
When encoded as an IPv6 address in 16 bytes, the IPv4-mapped IPv6 format [RFC4291] MAY be used to indicate an IPv4 address.
16バイトのIPv6アドレスとしてエンコードする場合、IPv4にマップされたIPv6形式[RFC4291]を使用してIPv4アドレスを示すことができます（MAY）。
The interpretation of Redirect-Address-IPAddress by the Diameter Credit-Control client is a matter of local policy.
Diameter Credit-ControlクライアントによるRedirect-Address-IPAddressの解釈は、ローカルポリシーの問題です。
The Redirect-Address-URL AVP (AVP Code 667) is of type UTF8String and defines the address of the redirect server with which the end user is to be connected when the account cannot cover the service cost. The address type is in the form of a Uniform Resource Locator, as defined in [RFC3986]. Note that individual URL schemes may restrict the contents of the UTF8String.
Redirect-Address-URL AVP（AVPコード667）はUTF8Stringタイプであり、アカウントがサービスコストをカバーできない場合にエンドユーザーが接続されるリダイレクトサーバーのアドレスを定義します。アドレスタイプは、[RFC3986]で定義されているUniform Resource Locatorの形式です。個々のURLスキームがUTF8Stringのコンテンツを制限する場合があることに注意してください。
The Redirect-Address-SIP-URI AVP (AVP Code 668) is of type UTF8String and defines the address of the redirect server with which the end user is to be connected when the account cannot cover the service cost. The address type is in the form of a SIP Uniform Resource Identifier, as defined in [RFC3261].
Redirect-Address-SIP-URI AVP（AVPコード668）はUTF8Stringタイプであり、アカウントがサービスコストをカバーできない場合にエンドユーザーが接続されるリダイレクトサーバーのアドレスを定義します。 [RFC3261]で定義されているように、アドレスタイプはSIP Uniform Resource Identifierの形式です。
The QoS-Final-Unit-Indication AVP (AVP Code 669) 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).
QoS-Final-Unit-Indication AVP（AVPコード669）はグループ化されたタイプであり、Credit-Control-AnswerまたはAA-AnswerのGranted-Service-Unit AVPにサービスの最終ユニットが含まれていることを示します。これらのユニットの有効期限が切れた後、Diameter Credit-Controlクライアントは、Final-Unit-Action 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-Control-Answerで複数のユニットタイプが受信された場合、最初に期限切れになったユニットタイプにより、クレジットコントロールクライアントは指定されたアクションを実行する必要があります（SHOULD）。
In the first interrogation, the QoS-Final-Unit-Indication AVP with Final-Unit-Action set to 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 that the client is 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-Unit-ActionがREDIRECTまたはRESTRICT_ACCESSに設定されたQoS-Final-Unit-Indication AVPが、Granted-Service-Unit AVPなしでCredit-Control-AnswerまたはAA-Answerに存在する場合もあります。 。これは、クライアントが指定されたアクションをすぐに実行することをDiameter Credit-Controlクライアントに示します。ホームサービスプロバイダーのポリシーがサービスを終了することである場合、当然、サーバーはポリシーで定義されたアクションを実装するために、適切な一時的な障害（セクション9.1を参照）を返す必要があります（SHOULD）。
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 QoS-Final-Unit-Indication AVP is included in a command.
Final-Unit-Action AVPは、ユーザーのアカウントがサービスのコストをカバーできない場合のサービス要素の動作を定義し、QoS-Final-Unit-Indication AVPがコマンドに含まれている場合は常に存在する必要があります。
If the Final-Unit-Action AVP is set to TERMINATE, the QoS-Final-Unit-Indication group AVP MUST NOT contain any other AVPs.
Final-Unit-Action AVPがTERMINATEに設定されている場合、QoS-Final-Unit-IndicationグループAVPに他のAVPを含めることはできません。
If the Final-Unit-Action AVP is set to REDIRECT, then the Redirect-Server-Extension AVP MUST be present. The 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-Extension AVP or if access to these services needs to be limited in some way (e.g., QoS).
Final-Unit-Action AVPがREDIRECTに設定されている場合、Redirect-Server-Extension AVPが存在する必要があります。 Filter-Rule AVPまたはFilter-Id AVPは、Redirect-Server-Extension AVPで指定されたアドレスを介してアクセスできない他のサービスへのアクセスもユーザーに許可されている場合、またはこれらのサービスへのアクセスは、何らかの方法（QoSなど）で制限する必要があります。
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the Filter-Rule AVP or the Filter-Id AVP SHOULD be present.
Final-Unit-Action AVPがRESTRICT_ACCESSに設定されている場合、Filter-Rule AVPまたはFilter-Id AVPのいずれかが存在する必要があります（SHOULD）。
The Filter-Rule AVP is defined in [RFC5777]. The Filter-Rule AVP can be used to define a specific combination of a condition and an action. If used only with traffic conditions, it should define which traffic should be allowed when no more service units are granted. However, if QoS or treatment information exists in the AVP, these actions should be executed, e.g., limiting the allowed traffic with certain QoS information. When multiple Filter-Rule AVPs exist, precedence should be determined as defined in [RFC5777].
Filter-Rule AVPは[RFC5777]で定義されています。 Filter-Rule AVPを使用して、条件とアクションの特定の組み合わせを定義できます。トラフィック条件でのみ使用する場合は、サービスユニットが許可されなくなったときに許可するトラフィックを定義する必要があります。ただし、QoSまたは処理情報がAVPに存在する場合、これらのアクションを実行する必要があります。たとえば、許可されたトラフィックを特定のQoS情報で制限します。複数のFilter-Rule AVPが存在する場合、[RFC5777]で定義されているように優先順位を決定する必要があります。
The Filter-Id AVP is defined in [RFC7155]. 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-Id AVPは[RFC7155]で定義されています。 Filter-Id AVPを使用して、Diameter Credit-Controlアプリケーション以外の手段（たとえば、ローカルで構成された、または別のエンティティーによって構成された）によって、アクセスデバイスにインストールされたIPフィルターリストを参照できます。
If the Final-Unit-Action AVP is (1) set to TERMINATE, (2) set to RESTRICT_ACCESS and the action required is to allow only traffic that could be classified using an IPFilterRule, or (3) set to REDIRECT using a type that is one of the types in the Redirect-Address-Type AVP, then the credit-control server SHOULD send the information in the Final-Unit-Indication AVP, in addition to or instead of the QoS-Final-Unit-Indication AVP. This is done in order to preserve backward compatibility with credit-control clients that support only [RFC4006].
Final-Unit-Action AVPが（1）TERMINATEに設定されている、（2）RESTRICT_ACCESSに設定されている、そして必要なアクションがIPFilterRuleを使用して分類できるトラフィックのみを許可する、または（3）次のタイプを使用してREDIRECTに設定されている場合： Redirect-Address-Type AVPのタイプの1つである場合、クレジット制御サーバーは、QoS-Final-Unit-Indication AVPに加えて、またはその代わりに、Final-Unit-Indication AVPで情報を送信する必要があります（SHOULD）。これは、[RFC4006]のみをサポートするクレジット制御クライアントとの下位互換性を維持するために行われます。
The QoS-Final-Unit-Indication AVP is defined as follows (per grouped-avp-def as defined in [RFC6733]):
QoS-Final-Unit-Indication AVPは次のように定義されます（[RFC6733]で定義されているgrouped-avp-defごとに）：
QoS-Final-Unit-Indication ::= < AVP Header: 669 >
{ Final-Unit-Action }
*[ Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server-Extension ]
*[ AVP ]
This section defines new Result-Code AVP [RFC6733] values that must be supported by all Diameter implementations that conform to this specification.
このセクションでは、この仕様に準拠するすべてのDiameter実装でサポートする必要がある新しいResult-Code AVP [RFC6733]値を定義します。
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-Control-Answerメッセージには、Result-Code AVPが含まれています。これは、Credit-Control-Requestメッセージにエラーが存在したことを示す場合があります。拒否されたCredit-Control-Requestメッセージにより、ユーザーのセッションが終了する必要があります（SHOULD）。
Errors that fall within the category of transient failures are used to inform the 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
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.
クレジット制御サーバーは、サービス制限のためにサービス要求を拒否します。 CCRに使用済みのサービスユニットが含まれている場合、可能であれば控除されます。
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011
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., the service is free of charge).
クレジット制御サーバーは、サービスをエンドユーザーに付与できるが、サービスに追加のクレジット制御は必要ない（たとえば、サービスは無料）と判断します。
DIAMETER_CREDIT_LIMIT_REACHED 4012
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.
エンドユーザーのアカウントが要求されたサービスをカバーできなかったため、信用管理サーバーはサービス要求を拒否します。 CCRに使用済みのサービスユニットが含まれている場合、可能であれば控除されます。
Errors that fall within the category of permanent failures are used to inform the peer that the request failed and should not be attempted again.
永続的な障害のカテゴリに含まれるエラーは、要求が失敗したため、再試行しないことをピアに通知するために使用されます。
DIAMETER_USER_UNKNOWN 5030
DIAMETER_USER_UNKNOWN 5030
The specified end user is unknown in the credit-control server.
指定されたエンドユーザーは、信用管理サーバーでは不明です。
DIAMETER_RATING_FAILED 5031
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 AVP value that is not recognized or supported in the rating. The Failed-AVP AVP MUST be included and contain (1) a copy of the entire AVP or AVPs that could not be processed successfully or (2) 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.
このエラーコードは、不十分な評価入力、不適切なAVPの組み合わせ、または評価で認識またはサポートされていないAVPまたはAVP値のために、信用管理サーバーがサービス要求を評価できないことを信用管理クライアントに通知するために使用されます。 Failed-AVP AVPが含まれている必要があり、（1）正常に処理できなかった1つまたは複数のAVPのコピー、または（2）欠落しているAVPの例。該当する場合はVendor-Idを記入します。欠落しているAVPの値フィールドは、正しい最小長で、ゼロが含まれている必要があります。
The table in Section 10.1 presents the AVPs defined in this document and specifies in which Diameter messages they MAY or MUST NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in the table.
セクション10.1の表は、このドキュメントで定義されているAVPを示し、それらが存在する場合と存在してはならないDiameterメッセージを示しています。グループ化されたAVP内にのみ存在できるAVPは、表には表示されないことに注意してください。
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.
0 AVPはメッセージに存在してはなりません。 0+ AVPのゼロ個以上のインスタンスがメッセージに存在する場合があります。 0-1 AVPのゼロまたは1つのインスタンスがメッセージに存在する場合があります。 AVPのインスタンスが複数ある場合は、エラーと見なされます。 1 AVPの1つのインスタンスがメッセージに存在する必要があります。
The table in this section is used to represent which credit-control application-specific AVPs defined in this document are to be present in the credit-control messages.
このセクションの表は、このドキュメントで定義されているどのクレジット制御アプリケーション固有のAVPがクレジット制御メッセージに含まれるかを表すために使用されます。
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | CCR | CCA |
----------------------------------|-----+-----+
Acct-Multi-Session-Id | 0-1 | 0-1 |
Auth-Application-Id | 1 | 1 |
CC-Correlation-Id | 0-1 | 0 |
CC-Session-Failover | 0 | 0-1 |
CC-Request-Number | 1 | 1 |
CC-Request-Type | 1 | 1 |
CC-Sub-Session-Id | 0-1 | 0-1 |
Check-Balance-Result | 0 | 0-1 |
Cost-Information | 0 | 0-1 |
Credit-Control-Failure-Handling | 0 | 0-1 |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Direct-Debiting-Failure-Handling | 0 | 0-1 |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0+ |
Final-Unit-Indication | 0 | 0-1 |
QoS-Final-Unit-Indication | 0 | 0-1 |
Granted-Service-Unit | 0 | 0-1 |
Multiple-Services-Credit-Control | 0+ | 0+ |
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 |
Session-Id | 1 | 1 |
Subscription-Id | 0+ | 0 |
Subscription-Id-Extension | 0+ | 0 |
Termination-Cause | 0-1 | 0 |
User-Equipment-Info | 0-1 | 0 |
User-Equipment-Info-Extension | 0-1 | 0 |
Used-Service-Unit | 0+ | 0 |
User-Name | 0-1 | 0-1 |
Validity-Time | 0 | 0-1 |
----------------------------------|-----+-----+
This section defines AVPs that are specific to the Diameter Credit-Control application and that MAY be included in the Diameter Re-Auth-Request/Re-Auth-Answer (RAR/RAA) message [RFC6733].
このセクションでは、Diameter Credit-Controlアプリケーションに固有のAVPを定義し、Diameter Re-Auth-Request / Re-Auth-Answer（RAR / RAA）メッセージ[RFC6733]に含めることができます。
The RAR/RAA command MAY include the following additional AVPs:
RAR / RAAコマンドには、次の追加のAVPが含まれる場合があります。
+---------------+
| Command Code |
|-------+-------+
Attribute Name | RAR | RAA |
------------------------------+-------+-------+
CC-Sub-Session-Id | 0-1 | 0-1 |
G-S-U-Pool-Identifier | 0-1 | 0-1 |
Service-Identifier | 0-1 | 0-1 |
Rating-Group | 0-1 | 0-1 |
------------------------------+-------+-------+
This section defines the basic principles for the Diameter Credit-Control / RADIUS prepaid interworking 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.
このセクションでは、Diameter Credit-Control / RADIUSプリペイドインターワーキングモデルの基本原則を定義します。つまり、RADIUSベースのプリペイドソリューションとDiameterクレジットコントロールアプリケーション間のメッセージ変換です。 RADIUSとDiameter Credit-Controlアプリケーション間のプロトコル変換の完全な説明は、この仕様の範囲外であり、別の適切なドキュメントで扱う必要があります。
The Diameter Credit-Control architecture may have a Translation Agent capable of translation between RADIUS prepaid and Diameter Credit-Control protocols. A 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 illustrated in Figure 9, and an interworking flow is illustrated in Figure 10. 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 then connects to the home AAA server.
Diameter Credit-Controlアーキテクチャには、RADIUSプリペイドプロトコルとDiameter Credit-Controlプロトコル間の変換が可能な変換エージェントが含まれる場合があります。 AAAサーバー（通常はホームAAAサーバー）は、Diameter Credit-Control以外のクレジット制御メカニズム（RADIUSプリペイドなど）を使用するサービス要素の翻訳エージェントおよびDiameterクレジット制御クライアントとして機能します。この場合、ホームAAAサーバーは、承認プロセスの一部としてDiameter Credit-Controlサーバーに接続します。インターワーキングアーキテクチャを図9に示し、インターワーキングフローを図10に示します。ローミングの状況では、サービスエレメント（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 |
+----------------+
Figure 9: Credit-Control Architecture with Service Element Containing Translation Agent, Translating RADIUS Prepaid to Diameter Credit-Control Protocol
図9：RADIUSプリペイドをDiameterクレジット制御プロトコルに変換する、変換エージェントを含むサービス要素を含むクレジット制御アーキテクチャ
When the AAA server acting as a Translation Agent receives an initial RADIUS Access-Request message from a 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. The home AAA server then sends the reserved quota to the Service Element in the RADIUS Access-Accept.
トランスレーションエージェントとして機能するAAAサーバーは、サービスエレメント（NASアクセスなど）から最初のRADIUSアクセス要求メッセージを受信すると、定期的な認証と承認を実行します。 RADIUSアクセス要求メッセージがサービス要素がクレジット制御が可能であることを示し、加入者が前払い加入者であるとホームAAAサーバーが検出した場合、Diameterクレジット制御要求をクレジット制御サーバーに送信する必要があります（SHOULD）。与信承認を実行し、与信管理セッションを確立します。 Diameter Credit-Controlサーバーがエンドユーザーのアカウント残高を確認し、サービスを評価し、エンドユーザーのアカウントからクレジットを予約すると、予約されたクォータがDiameter Credit-Control-AnswerのホームAAAサーバーに返されます。次に、ホームAAAサーバーは、予約済みのクォータをRADIUS Access-Acceptのサービス要素に送信します。
At the expiry of the allocated quota, the Service Element sends a new RADIUS Access-Request containing the units used thus 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 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アクセス要求をホームAAAサーバーに送信します。ホームAAAサーバーは、Diameter Credit-Control-Request（UPDATE_REQUEST）で、報告されたユニットを含むRADIUS Access-RequestをDiameter Credit-Controlサーバーにマップします。 Diameter Credit-Control-Answerは、Diameter Credit-Control-Serverがエンドユーザーのアカウントから使用済みのユニットを引き落とし、ホームAAAサーバーに返される新しい割り当てを割り当てます。クォータは、RADIUS Access-Acceptのサービス要素に転送されます。エンドユーザーがサービスを終了するか、クォータ全体が使用されると、サービスエレメントはRADIUSアクセス要求を送信します。エンドユーザーのアカウントから使用済みのユニットを引き落とし、クレジット制御セッションを停止するために、ホームAAAサーバーはDiameterクレジット制御要求（TERMINATION_REQUEST）をクレジット制御サーバーに送信します。 Diameterクレジット制御サーバーは、Diameterクレジット制御応答をホームAAAサーバーに送信することにより、セッションの終了を確認します。 RADIUS Access-AcceptがNASに送信されます。
Figure 10 illustrates a Diameter Credit-Control / RADIUS prepaid interworking sequence.
図10は、Diameter Credit-Control / 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 | |
|<-----------------------| |
| | |
Figure 10: Message Flow Example with Diameter Credit-Control / RADIUS Prepaid Interworking
図10：Diameter Credit-Control / RADIUS Prepaid Interworkingを使用したメッセージフローの例
This document uses several registries that were originally created in [RFC4006] or the values assigned to existing namespaces managed by IANA. IANA has updated these registries to reference this document. The registries and their allocation policies are specified below.
このドキュメントでは、[RFC4006]で最初に作成されたいくつかのレジストリ、またはIANAが管理する既存の名前空間に割り当てられた値を使用します。 IANAは、このドキュメントを参照するようにこれらのレジストリを更新しました。レジストリとその割り当てポリシーを以下に示します。
This specification assigns the value 4, "Diameter Credit Control", to the "Application IDs" namespace defined in [RFC6733]. See Section 1.3 for more information.
この仕様は、値4「Diameter Credit Control」を、[RFC6733]で定義されている「アプリケーションID」名前空間に割り当てます。詳細については、セクション1.3を参照してください。
This specification uses the value 272 from the "Command Codes" namespace defined in [RFC6733] for the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) commands.
この仕様は、Credit-Control-Request（CCR）およびCredit-Control-Answer（CCA）コマンドに対して、[RFC6733]で定義された「コマンドコード」名前空間の値272を使用します。
See Section 8 for the assignments in this specification.
この仕様の割り当てについては、セクション8を参照してください。
This document describes new AVP codes beyond those described in [RFC4006]. IANA has allocated codes for the AVPs listed in Table 7.
このドキュメントでは、[RFC4006]で説明されているものを超える新しいAVPコードについて説明します。 IANAは、表7にリストされているAVPにコードを割り当てました。
+-----------------------------------+------+--------------+
| Attribute Name | Code | Defined in |
+-----------------------------------+------+--------------+
| User-Equipment-Info-Extension | 653 | Section 8.52 |
| User-Equipment-Info-IMEISV | 654 | Section 8.53 |
| User-Equipment-Info-MAC | 655 | Section 8.54 |
| User-Equipment-Info-EUI64 | 656 | Section 8.55 |
| User-Equipment-Info-ModifiedEUI64 | 657 | Section 8.56 |
| User-Equipment-Info-IMEI | 658 | Section 8.57 |
| Subscription-Id-Extension | 659 | Section 8.58 |
| Subscription-Id-E164 | 660 | Section 8.59 |
| Subscription-Id-IMSI | 661 | Section 8.60 |
| Subscription-Id-SIP-URI | 662 | Section 8.61 |
| Subscription-Id-NAI | 663 | Section 8.62 |
| Subscription-Id-Private | 664 | Section 8.63 |
| Redirect-Server-Extension | 665 | Section 8.64 |
| Redirect-Address-IPAddress | 666 | Section 8.65 |
| Redirect-Address-URL | 667 | Section 8.66 |
| Redirect-Address-SIP-URI | 668 | Section 8.67 |
| QoS-Final-Unit-Indication | 669 | Section 8.68 |
+-----------------------------------+------+--------------+
Table 7: Requested AVP Assignments
表7：要求されたAVP割り当て
This specification assigns the values 4010, 4011, and 4012 in the "Result-Code AVP Values (code 268) - Transient Failures" namespace and values 5030 and 5031 in the "Result-Code AVP Values (code 268) - Permanent Failure" namespace, both of which were defined by [RFC6733]. See Section 9 for the assignments in this specification.
この仕様は、「結果コードAVP値（コード268）-一時的な障害」名前空間の値4010、4011、および4012と、「結果コードAVP値（コード268）-永続的障害」名前空間の値5030および5031を割り当てます。 、どちらも[RFC6733]によって定義されました。この仕様の割り当てについては、セクション9を参照してください。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.3で定義されているように、CC-Request-Type AVPには、列挙型の値1〜4が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
As defined in Section 8.4, the CC-Session-Failover AVP includes Enumerated type values 0-1. IANA has created and is maintaining a namespace for this AVP. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.4で定義されているように、CC-Session-Failover AVPには列挙型の値0〜1が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.32で定義されているように、CC-Unit-Type AVPには、列挙型の値0〜5が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.6で定義されているように、Check-Balance-Result AVPには列挙型の値0〜1が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.13で定義されているように、Credit-Control AVPには列挙型の値0〜1が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.14で定義されているように、Credit-Control-Failure-Handling AVPには列挙型の値0〜2が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.15で定義されているように、Direct-Debiting-Failure-Handling AVPには、列挙型の値0〜1が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.35で定義されているように、Final-Unit-Action AVPには列挙型の値0〜2が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.40で定義されているように、Multiple-Services-Indicator AVPには列挙型の値0〜1が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.38で定義されているように、Redirect-Address-Type AVPには列挙型の値0〜3が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.41で定義されているように、Requested-Action AVPには列挙型の値0〜3が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.47で定義されているように、Subscription-Id-Type AVPには、列挙型の値0〜4が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.27で定義されているように、Tariff-Change-Usage AVPには列挙型の値0〜2が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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. The definition of new values is subject to the Specification Required policy [RFC8126] and conditions for enumerated values described in [RFC7423], Section 5.6.
セクション8.50で定義されているように、User-Equipment-Info-Type AVPには、列挙型の値0〜3が含まれています。 IANAはこのAVPの名前空間を作成し、維持しています。新しい値の定義は、Specification Requiredポリシー[RFC8126]と、[RFC7423]のセクション5.6に記載されている列挙値の条件に従います。
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, 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 action for the end user according to the value of the CCFH or the DDFH. The recommended value is 10 seconds.
リアルタイムの与信管理が必要な場合、サービスがエンドユーザーに提供される前とその間に、与信管理クライアントは与信管理サーバーに接続します。アプリケーションのリアルタイム性により、通信遅延は最小限に抑えられる必要があります。たとえば、エンドユーザーが経験する過度に長いサービスセットアップ時間を回避する必要があります。 Txタイマーは、Pending状態のクライアントでの待機時間を制御するために導入されています。 Txタイマーが経過すると、クレジット制御クライアントは、CCFHまたはDDFHの値に従ってエンドユーザーのアクションを実行します。推奨値は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 the 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 is equal to 2 x Validity-Time.
Tccタイマーは、クレジット制御サーバーで進行中のクレジット制御セッションを監視します。 Validity-Timeを入力として使用してTccタイマー値を設定することをお勧めします。ネットワークで一時的な障害が発生した場合、Diameter Credit-Controlサーバーがアイドル状態に変わることがあります。これを回避するために、Tccが2 x Validity-Timeに等しくなるようにTccタイマーを設定できます（MAY）。
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 values and behavior are defined in Sections 5.7 and 6.5, respectively.
クライアントの実装により、これらのAVPをローカルで構成できる可能性があります。このような場合、それらの値と動作は、それぞれセクション5.7とセクション6.5で定義されています。
Security considerations regarding the Diameter protocol itself are discussed in [RFC6733]. The use of this application of Diameter MUST take into consideration the security issues and requirements of the base protocol.
Diameterプロトコル自体に関するセキュリティの考慮事項は、[RFC6733]で説明されています。 Diameterのこのアプリケーションを使用する場合は、基本プロトコルのセキュリティの問題と要件を考慮する必要があります。
This application includes a mechanism for application-layer replay protection by means of (1) the Session-Id AVP as specified in [RFC6733] and (2) the CC-Request-Number AVP, 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/TCP, DTLS/SCTP (Datagram Transport Layer Security / Stream Control Transmission Protocol), or IPsec is sufficient. The details of security considerations related to TLS/TCP, DTLS/SCTP, and IPsec are discussed in [RFC6733].
このアプリケーションには、（1）[RFC6733]で指定されているSession-Id AVPと、（2）このドキュメントで指定されているCC-Request-Number AVPによる、アプリケーション層の再生保護のメカニズムが含まれています。 Diameter Credit-Controlアプリケーションは1つのドメイン内で使用されることが多く、ピア間に単一のホップが存在する場合があります。これらの環境では、TLS / TCP、DTLS / SCTP（データグラムトランスポート層セキュリティ/ストリーム制御伝送プロトコル）、またはIPsecの使用で十分です。 TLS / TCP、DTLS / SCTP、およびIPsecに関連するセキュリティの考慮事項の詳細は、[RFC6733]で説明されています。
Because this application handles monetary transactions (directly or indirectly), it increases interest in 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 the scope of this specification but can be, for instance, manual configuration.
このアプリケーションは金銭取引を（直接的または間接的に）処理するため、さまざまなセキュリティ攻撃への関心が高まります。したがって、たとえばTLSクライアント側の認証を含め、相互に通信するすべての当事者を認証する必要があります。さらに、クライアントの承認は強調されるべきです（SHOULD）。つまり、クライアントは特定のユーザーの信用管理を実行することが許可されます。承認の具体的な手段は、この仕様の範囲外ですが、たとえば、手動構成にすることができます。
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 identifiers, granted units, used units, or 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.
別の種類の脅威は、AVPまたは完全な信用管理メッセージの悪意のある変更、挿入、または削除です。与信管理メッセージには、悪意のある変更が金銭的影響を与える可能性のある機密の請求関連情報（サブスクリプション識別子、付与されたユニット、使用済みユニット、コスト情報など）が含まれています。場合によっては、単にクレジット制御メッセージを遅延させるだけで、クレジット制御クライアントまたはサーバーに障害を引き起こす可能性があります。
Even without any modifications to the messages, an adversary that can eavesdrop on transactions can obtain privacy-sensitive information. Also, by monitoring the credit-control messages, one can collect information about the credit-control server's billing models and business relationships.
メッセージに変更を加えなくても、トランザクションを盗聴できる攻撃者はプライバシーに敏感な情報を入手できます。また、信用管理メッセージを監視することにより、信用管理サーバーの請求モデルとビジネス関係に関する情報を収集できます。
When third-party relays or proxies are involved, hop-by-hop security does not necessarily provide sufficient protection for Diameter user sessions. In some cases, it may be inappropriate to send Diameter messages, such as CCR messages and CCA messages, 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ユーザーセッションに十分な保護を提供するとは限りません。サードパーティのプロキシがクレジット制御コマンドやAVPを変更しないという保証がないため、CCRメッセージやCCAメッセージなどのDiameterメッセージを信頼できないDiameterプロキシエージェント経由で送信することは不適切な場合があります。値。
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 [RFC6733], Section 2.7) for the realm of the credit-control server in the end user's home realm. 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 information about the Diameter Credit-Control server(s) (Redirect-Host AVP) and information about how the routing entry resulting from the Redirect-Host is to be used (Redirect-Host-Usage AVP). 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 does not equal zero, all subsequent messages are sent to the host specified in the Redirect-Host AVP until the time specified by the Redirect-Max-Cache-Time AVP has expired.
Diameter Credit-Controlエージェントは、それとエンドユーザーのDiameter Credit-Controlサーバーの間のエージェントが信頼できるかどうかを常に認識できるわけではありません。この場合、Diameter Credit-ControlエージェントのDiameterルーティングテーブル（[RFC6733]のセクション2.7で定義）には、エンドユーザーのホームレルムのクレジット制御サーバーのレルムのルーティングエントリがありません。 Diameter Credit-Controlエージェントは、ローカルリダイレクトエージェントに設定されたデフォルトルートを持つことができ、CCRメッセージをリダイレクトエージェントにリダイレクトします。ローカルリダイレクトエージェントは、リダイレクト通知（Result-Code 3006、DIAMETER_REDIRECT_INDICATION）をクレジットコントロールエージェントに返します。また、Diameterクレジットコントロールサーバー（リダイレクトホストAVP）に関する情報とルーティング方法に関する情報も返します。 Redirect-Hostに起因するエントリが使用されます（Redirect-Host-Usage AVP）。次に、Diameter Credit-Controlエージェントは、リダイレクトエージェントからのCCAメッセージによって識別されるホストの1つにCCRメッセージを直接転送します。 Redirect-Host-Usage AVPの値がゼロでない場合、Redirect-Max-Cache-Time AVPで指定された時間が経過するまで、後続のすべてのメッセージはRedirect-Host AVPで指定されたホストに送信されます。
Even with redirects, there are some authorization issues. 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 [RFC4072], Section 8.
リダイレクトがあっても、いくつかの認証の問題があります。適切に許可されているが、それらの許可を乱用する、または侵害されたノードに対する攻撃がある可能性があります。これらの問題については、[RFC4072]のセクション8でより広く議論されています。
This document includes a redirection feature (Section 5.6.2) whereby the service provider can redirect (in an application-specific way) the end user to an alternate location when their credits have expired. This technique is useful in that it allows the user to return to normal service quickly, but it also exposes additional risks and attack surface. In particular, this redirection can potentially occur at an arbitrary point in a user's session, potentially without any additional contextual confirmation available to the user that the redirection is driven by the network. This lack of confirmation matters because, in many application protocols, the communication peer is also capable of inducing redirection. When the peer is an attacker, the redirection can be to an attacker-controlled site. In particular, such sites may be "phishing" sites designed to appear similar to legitimate payment sites in an attempt to obtain users' payment information for fraudulent purposes. When users become accustomed to such redirections, they may have difficulty distinguishing such attacks from legitimate redirections.
このドキュメントには、サービスプロバイダーがクレジットの期限が切れたときにエンドユーザーを（アプリケーション固有の方法で）別の場所にリダイレクトできるリダイレクト機能（セクション5.6.2）が含まれています。この手法は、ユーザーが通常のサービスにすばやく戻ることができるという点で役立ちますが、追加のリスクと攻撃対象領域も公開します。特に、このリダイレクトはユーザーのセッションの任意の時点で発生する可能性があり、リダイレクトがネットワークによって駆動されていることをユーザーが利用できる追加のコンテキスト確認がない可能性があります。多くのアプリケーションプロトコルでは、通信ピアもリダイレクトを誘導できるため、この確認の欠如は重要です。ピアが攻撃者である場合、攻撃者が制御するサイトにリダイレクトすることができます。特に、このようなサイトは、不正な目的でユーザーの支払い情報を取得しようとする正当な支払いサイトに類似するように設計された「フィッシング」サイトである場合があります。ユーザーがそのようなリダイレクトに慣れると、そのような攻撃を正当なリダイレクトと区別することが困難になる可能性があります。
Because of the potentially harmful consequences of arbitrary redirection by an attacker (such as to phishing sites), it is important for service providers to be aware of that risk and ensure that their users are aware of it as well. Service providers should follow industry best practices for the specific application-layer protocol to reduce the chances that such attacks could be mistaken for legitimate redirections. The details of such a practice are out of scope for this document.
攻撃者による任意のリダイレクト（フィッシングサイトへのリダイレクトなど）の潜在的に有害な結果のため、サービスプロバイダーはそのリスクを認識し、ユーザーもそれを確実に認識することが重要です。サービスプロバイダーは、特定のアプリケーション層プロトコルに関する業界のベストプラクティスに従って、そのような攻撃が正当なリダイレクトと間違えられる可能性を減らす必要があります。そのような慣行の詳細は、このドキュメントの範囲外です。
As the Diameter protocol, and especially the credit-control application, deal with subscribers and their actions, extra care should be taken regarding the privacy of the subscribers. Per terminology used in [RFC6973], both the credit-control client and the credit-control server are intermediary entities, wherein the subscribers' privacy may be compromised even if no security issues exist, and only authorized entities have access to the privacy-sensitive information.
Diameterプロトコル、特にクレジットコントロールアプリケーションはサブスクライバーとそのアクションを処理するため、サブスクライバーのプライバシーについては特に注意が必要です。 [RFC6973]で使用されている用語では、信用管理クライアントと信用管理サーバーの両方が仲介エンティティであり、セキュリティ上の問題がなくても、サブスクライバーのプライバシーが侵害される可能性があり、承認されたエンティティのみがプライバシーに敏感なアクセス権を持っています情報。
The privacy-sensitive AVPs listed in this section MUST NOT be sent across non-trusted networks or Diameter agents without end-to-end authentication and confidentiality protection, as described in [RFC6733], Section 13.3.
[RFC6733]のセクション13.3で説明されているように、このセクションに記載されているプライバシーに配慮したAVPは、エンドツーエンドの認証と機密保護なしで信頼できないネットワークまたはDiameterエージェントを介して送信してはなりません。
The following AVPs contain privacy-sensitive information at different levels:
次のAVPには、さまざまなレベルでプライバシーに関わる情報が含まれています。
1. CC-Correlation-Id AVP: may contain privacy-sensitive information, as the service provider may encode personal information that helps it correlate different subscriptions and access technologies.
1. CC-Correlation-Id AVP：プライバシーに敏感な情報が含まれる場合があります。サービスプロバイダーは、さまざまなサブスクリプションとアクセステクノロジーの関連付けに役立つ個人情報をエンコードする場合があるためです。
2. Check-Balance-Result AVP: contains information on the balance status of the subscriber.
2. Check-Balance-Result AVP：サブスクライバーのバランスステータスに関する情報が含まれます。
3. Currency-Code AVP: contains information on the subscriber's locale.
3. Currency-Code AVP：サブスクライバーのロケールに関する情報が含まれています。
4. Cost-Unit AVP: contains privacy-sensitive information for the Cost-Information AVP, in human-readable format.
4. コスト単位AVP：コスト情報AVPのプライバシーに配慮した情報が人間が読める形式で含まれています。
5. Service-Identifier AVP: may contain privacy-sensitive information about the subscriber's Internet activity.
5. Service-Identifier AVP：加入者のインターネット活動に関するプライバシーに配慮した情報が含まれる場合があります。
6. Rating-Group AVP: may contain privacy-sensitive information about the subscriber's Internet activity.
6. Rating-Group AVP：加入者のインターネット活動に関するプライバシーに配慮した情報が含まれる場合があります。
7. Restriction-Filter-Rule AVP: the information inside IPFilterRule may be used to infer services used by the subscriber.
7. Restriction-Filter-Rule AVP：IPFilterRule内の情報を使用して、サブスクライバーが使用するサービスを推測できます。
8. Redirect-Server-Address AVP: the service provider might embed personal information on the subscriber in the URL/URI (e.g., to create a personalized message). However, the service provider may instead anonymize the subscriber's identity in the URL/URI and let the redirect server query the information directly. Such anonymized information must not allow personal information or the subscriber's identity to be easily guessed. Furthermore, the service provider should treat the URL/URI schema itself as confidential and make sure it cannot be inferred (1) from observation of the traffic or (2) due to its trivial structure. A trivial structure could allow an adversary to query/modify personal information even without knowing the subscriber's identity. Similar AVPs are Redirect-Address-URL and Redirect-Address-SIP-URI.
8. Redirect-Server-Address AVP：サービスプロバイダーは、サブスクライバーの個人情報をURL / URIに埋め込むことがあります（たとえば、個人用メッセージを作成するため）。ただし、サービスプロバイダーは、代わりにURL / URIでサブスクライバーのIDを匿名化し、リダイレクトサーバーに直接情報を照会させることができます。このような匿名化された情報は、個人情報や加入者の身元を簡単に推測できないようにする必要があります。さらに、サービスプロバイダーは、URL / URIスキーマ自体を機密情報として扱い、（1）トラフィックの監視から、または（2）単純な構造のために推測できないことを確認する必要があります。単純な構造では、加入者の身元を知らなくても、攻撃者が個人情報を照会/変更できる可能性があります。同様のAVPは、Redirect-Address-URLおよびRedirect-Address-SIP-URIです。
9. Service-Context-Id AVP: depending on how the service provider uses it, it may contain privacy-sensitive information about the service (e.g., in a 3GPP network Service-Context-Id AVP, it has a different value for packet switching, SMS, Multimedia Messages (MMSs), etc.).
9. Service-Context-Id AVP：サービスプロバイダーがそれを使用する方法に応じて、サービスに関するプライバシーに敏感な情報が含まれる場合があります（たとえば、3GPPネットワークService-Context-Id AVPでは、パケットスイッチング、SMSの値が異なります） 、マルチメディアメッセージ（MMS）など）。
10. Service-Parameter-Info AVP: depending on how the service provider uses it, it may contain privacy-sensitive information about the subscriber (e.g., location).
10. Service-Parameter-Info AVP：サービスプロバイダーがそれを使用する方法に応じて、サブスクライバーに関するプライバシーに敏感な情報（場所など）が含まれる場合があります。
11. Subscription-Id-Data AVP: contains the identity of the subscriber. Similar AVPs are Subscription-Id-E164, Subscription-Id-IMSI, Subscription-Id-SIP-URI, Subscription-Id-NAI, and Subscription-Id-Private.
11. Subscription-Id-Data AVP：サブスクライバーのIDが含まれています。同様のAVPは、Subscription-Id-E164、Subscription-Id-IMSI、Subscription-Id-SIP-URI、Subscription-Id-NAI、およびSubscription-Id-Privateです。
12. User-Equipment-Info-Value AVP: contains the identity of the device of the subscriber. Similar AVPs are User-Equipment-Info-IMEISV, User-Equipment-Info-MAC, User-Equipment-Info-EUI64, User-Equipment-Info-ModifiedEUI64, and User-Equipment-Info-IMEI.
12. User-Equipment-Info-Value AVP：サブスクライバーのデバイスのIDが含まれます。同様のAVPは、User-Equipment-Info-IMEISV、User-Equipment-Info-MAC、User-Equipment-Info-EUI64、User-Equipment-Info-ModifiedEUI64、およびUser-Equipment-Info-IMEIです。
13. QoS-Final-Unit-Indication AVP: Grouped AVP that may contain privacy-sensitive information in its sub-AVPs (e.g., IPFilterRule, redirect address).
13. QoS-Final-Unit-Indication AVP：サブAVP（IPFilterRule、リダイレクトアドレスなど）にプライバシーに敏感な情報を含めることができるグループ化されたAVP。
Note that some AVPs that are used in this document are defined in [RFC6733] and may contain privacy-sensitive information. These AVPs are not listed above.
このドキュメントで使用されている一部のAVPは[RFC6733]で定義されており、プライバシーに敏感な情報が含まれている場合があります。これらのAVPは上記にリストされていません。
Due to the nature of the credit-control application, some personal data and identity information must be stored in both the credit-control client and the credit-control server. However, this could be minimized by following these guidelines:
与信管理アプリケーションの性質上、一部の個人データとID情報は、与信管理クライアントと与信管理サーバーの両方に保存する必要があります。ただし、次のガイドラインに従うことでこれを最小限に抑えることができます。
1. Data stored in the credit-control client does not need to persist across sessions. All data could be deleted once the session ends and could be reconstructed once a new session is initialized. Note that while the credit-control server is usually owned by the service provider with which the subscriber already has some direct legal or business relationship (where the privacy level could be agreed upon), this is not always true for a credit-control client that may be owned by a third party.
1. 与信管理クライアントに保存されたデータは、セッション間で持続する必要はありません。セッションが終了するとすべてのデータが削除され、新しいセッションが初期化されると再構築されます。クレジットコントロールサーバーは通常、サブスクライバーが既に何らかの法的またはビジネス上の関係（プライバシーレベルが合意される可能性がある）を持っているサービスプロバイダーによって所有されますが、これは必ずしもクレジットコントロールクライアントに当てはまるわけではありません。第三者が所有している可能性があります。
2. Some information about the subscriber has to be stored in persistent storage in the credit-control server (e.g., identity, balance); however, per-transaction information does not have to be stored in persistent storage, and per-session information may be deleted from persistent storage once the session ends.
2. サブスクライバーに関するいくつかの情報は、クレジットコントロールサーバーの永続ストレージに保存する必要があります（ID、残高など）。ただし、トランザクションごとの情報は永続ストレージに保存する必要はなく、セッションが終了すると、セッションごとの情報が永続ストレージから削除される場合があります。
3. In some cases, per-transaction information has to be stored on the credit-control server, client, or both, for regulatory, auditability, or debugging reasons. However, this could be minimized by following these guidelines:
3. 場合によっては、規制、監査、またはデバッグの理由から、トランザクションごとの情報を信用管理サーバー、クライアント、またはその両方に保存する必要があります。ただし、次のガイドラインに従うことでこれを最小限に抑えることができます。
A. Data retention does not need to exceed the required duration.
A.データ保持は、必要な期間を超える必要はありません。
B. Transaction information could be aggregated in some cases (e.g., prefer information per session over information per rating-group; prefer hourly byte summary over per-transaction byte counts).
B.トランザクション情報は、場合によっては集計できます（たとえば、評価グループごとの情報よりもセッションごとの情報を優先する、トランザクションごとのバイトカウントよりも時間ごとのバイトサマリーを優先する）。
C. If not strictly needed, information that is more sensitive (e.g., location, equipment type) could be filtered out of such logs. This information is often used to make rating decisions, and in this case, the rating decisions should be logged instead of the data used to make them.
C.厳密に必要とされない場合は、より機密性の高い情報（場所、機器の種類など）をそのようなログから除外できます。この情報は、評価の決定によく使用されます。この場合、評価の決定に使用したデータの代わりに、評価の決定をログに記録する必要があります。
D. Due to the reasons explained in the first guideline, the credit-control server, rather than the credit-control client, would be the preferred location for storing such transaction information.
D.最初のガイドラインで説明されている理由により、このようなトランザクション情報を格納する場所としては、クレジットコントロールクライアントではなく、クレジットコントロールサーバーが推奨されます。
Diameter agents, as described in [RFC6733], may be owned by third parties. If end-to-end security is supported between the credit-control client and the credit-control server, the operator can use it to encrypt privacy-sensitive AVPs (as listed in Section 15.1) and prevent such information from leaking into the agent.
[RFC6733]で説明されているように、Diameterエージェントはサードパーティが所有する場合があります。エンドツーエンドのセキュリティがクレジットコントロールクライアントとクレジットコントロールサーバー間でサポートされている場合、オペレーターはそれを使用してプライバシーに配慮したAVP（セクション15.1に記載）を暗号化し、そのような情報がエージェントに漏洩するのを防ぐことができます。
In some cases, the Diameter agent needs access to privacy-sensitive AVPs, in order to make correct routing decisions or even to modify the content of these AVPs. For example, a proxy agent may need to look at the Subscription-Id-IMSI AVP, in order to extract the mobile country and network codes of the user and use them to look up the destination to which the request should be routed (see Section 2.8.2 in [RFC6733]). In such a case, the credit-control client and credit-control server may use a mechanism that anonymizes the identity of the subscriber, as well as a mechanism to encrypt other AVPs not used by the agent.
場合によっては、正しいルーティングを決定したり、これらのAVPのコンテンツを変更したりするために、Diameterエージェントがプライバシーの影響を受けやすいAVPにアクセスする必要があります。たとえば、プロキシエージェントは、ユーザーのモバイル国コードとネットワークコードを抽出し、それらを使用してリクエストのルーティング先を検索するために、Subscription-Id-IMSI AVPを確認する必要がある場合があります（セクションを参照）。 [RFC6733]の2.8.2）。このような場合、クレジット制御クライアントとクレジット制御サーバーは、サブスクライバーのIDを匿名化するメカニズムと、エージェントが使用しない他のAVPを暗号化するメカニズムを使用できます。
[CE164] International Telecommunication Union, "COMPLEMENT TO ITU-T RECOMMENDATION E.164 (11/2010): LIST OF ITU-T RECOMMENDATION E.164 ASSIGNED COUNTRY CODES", November 2011, <https://www.itu.int/dms_pub/itu-t/opb/sp/ T-SP-E.164D-11-2011-PDF-E.pdf>.
[CE164]国際電気通信連合、「ITU-T勧告E.164への補足（11/2010）：ITU-T勧告E.164割り当て国コードのリスト」、2011年11月、<https://www.itu.int / dms_pub / itu-t / opb / sp / T-SP-E.164D-11-2011-PDF-E.pdf>。
[CE212] International Telecommunication Union, "COMPLEMENT TO RECOMMENDATION ITU-T E.212 (09/2016): LIST OF MOBILE COUNTRY OR GEOGRAPHICAL AREA CODES", February 2017, <https://www.itu.int/dms_pub/itu-t/opb/sp/ T-SP-E.212A-2017-PDF-E.pdf>.
[CE212] International Telecommunication Union、「COMPLEMENT TO RECOMMENDATION ITU-T E.212（09/2016）：LIST of MOBILE COUNTRY or GEOGRAPHICAL AREA CODES」、2017年2月、<https://www.itu.int/dms_pub/itu -t / opb / sp / T-SP-E.212A-2017-PDF-E.pdf>。
[E164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164/>.
[E164]国際電気通信連合、「国際公衆電気通信番号計画」、ITU-T勧告E.164、2010年11月、<https://www.itu.int/rec/T-REC-E.164/>。
[E212] International Telecommunication Union, "The international identification plan for public networks and subscriptions", ITU-T Recommendation E.212, September 2016, <https://www.itu.int/rec/T-REC-E.212/en>.
[E212]国際電気通信連合、「公共ネットワークとサブスクリプションの国際識別計画」、ITU-T勧告E.212、2016年9月、<https://www.itu.int/rec/T-REC-E.212 / en>。
[EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)", August 2017, <https://standards.ieee.org/content/dam/ ieee-standards/standards/web/documents/tutorials/eui.pdf>.
[EUI64] IEEE、「Extended Unique Identifier（EUI）、Organizationally Unique Identifier（OUI）、およびCompany ID（CID）の使用に関するガイドライン」、2017年8月、<https://standards.ieee.org/content/dam/ ieee-standards / standards / web / documents / tutorials / eui.pdf>。
[ISO4217] ISO, "Codes for the representation of currencies", ISO 4217:2015, 2015, <https://www.iso.org/ iso-4217-currency-codes.html>.
[ISO4217] ISO、「通貨を表すためのコード」、ISO 4217：2015、2015、<https://www.iso.org/ iso-4217-currency-codes.html>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, DOI 10.17487/RFC3539, June 2003, <https://www.rfc-editor.org/info/rfc3539>.
[RFC3539] Aboba、B。およびJ. Wood、「Authentication、Authorization and Accounting（AAA）Transport Profile」、RFC 3539、DOI 10.17487 / RFC3539、2003年6月、<https://www.rfc-editor.org/info / rfc3539>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005, <https://www.rfc-editor.org/info/rfc4006>.
[RFC4006] Hakala、H.、Mattila、L.、Koskinen、JP。、Stura、M。、およびJ. Loughney、「Diameter Credit-Control Application」、RFC 4006、DOI 10.17487 / RFC4006、2005年8月、<https： //www.rfc-editor.org/info/rfc4006>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, <https://www.rfc-editor.org/info/rfc5777>.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M.、Ed。、and A. Lior、 "Traffic Classification and Quality of Service（QoS）Attributes for Diameter"、RFC 5777、DOI 10.17487 / RFC5777、2010年2月、<https://www.rfc-editor.org/info/rfc5777>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、DOI 10.17487 / RFC5952、August 2010、<https://www.rfc-editor.org/info/rfc5952> 。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.
[RFC6733] Fajardo、V。、編、Arkko、J.、Loughney、J。、およびG. Zorn、編、「Diameter Base Protocol」、RFC 6733、DOI 10.17487 / RFC6733、2012年10月、<https：/ /www.rfc-editor.org/info/rfc6733>。
[RFC7155] Zorn, G., Ed., "Diameter Network Access Server Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, <https://www.rfc-editor.org/info/rfc7155>.
[RFC7155] Zorn、G。、編、「Diameterネットワークアクセスサーバーアプリケーション」、RFC 7155、DOI 10.17487 / RFC7155、2014年4月、<https://www.rfc-editor.org/info/rfc7155>。
[RFC7423] Morand, L., Ed., Fajardo, V., and H. Tschofenig, "Diameter Applications Design Guidelines", BCP 193, RFC 7423, DOI 10.17487/RFC7423, November 2014, <https://www.rfc-editor.org/info/rfc7423>.
[RFC7423] Morand、L.、Ed。、Fajardo、V。、およびH. Tschofenig、「直径アプリケーション設計ガイドライン」、BCP 193、RFC 7423、DOI 10.17487 / RFC7423、2014年11月、<https：//www.rfc -editor.org/info/rfc7423>。
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>.
[RFC7542] DeKok、A。、「The Network Access Identifier」、RFC 7542、DOI 10.17487 / RFC7542、2015年5月、<https://www.rfc-editor.org/info/rfc7542>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[TGPPIMEI] 3rd Generation Partnership Project, Technical Specification Group Core Network, "Numbering, addressing and identification (release 15)", 3GPP TS 23.003 version 15.6.0, December 2018.
[TGPPIMEI]第3世代パートナーシッププロジェクト、技術仕様グループコアネットワーク、「番号付け、アドレス指定、および識別（リリース15）」、3GPP TS 23.003バージョン15.6.0、2018年12月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>.
[RFC2866] Rigney、C。、「RADIUS Accounting」、RFC 2866、DOI 10.17487 / RFC2866、2000年6月、<https://www.rfc-editor.org/info/rfc2866>。
[RFC3580] 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, DOI 10.17487/RFC3580, September 2003, <https://www.rfc-editor.org/info/rfc3580>.
[RFC3580] Congdon、P.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1Xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、DOI 10.17487 / RFC3580、2003年9月、<https://www.rfc-editor.org/info/rfc3580>。
[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, DOI 10.17487/RFC3725, April 2004, <https://www.rfc-editor.org/info/rfc3725>.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「Session Initiation Protocol（SIP）でのサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、DOI 10.17487 / RFC3725、2004年4月、<https://www.rfc-editor.org/info/rfc3725>。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., Ed., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, DOI 10.17487/RFC4004, August 2005, <https://www.rfc-editor.org/info/rfc4004>.
[RFC4004] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T.、Ed。、およびP. McCann、「Diameter Mobile IPv4 Application」、RFC 4004、DOI 10.17487 / RFC4004、2005年8月、< https://www.rfc-editor.org/info/rfc4004>。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005, <https://www.rfc-editor.org/info/rfc4072>.
[RFC4072] Eronen、P.、Ed。、Hiller、T。、およびG. Zorn、「Diameter Extensible Authentication Protocol（EAP）Application」、RFC 4072、DOI 10.17487 / RFC4072、2005年8月、<https：// www。 rfc-editor.org/info/rfc4072>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[TGPPCHARG] 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, "Service aspects; Charging and Billing", 3GPP TS 22.115 version 15.5.0, September 2018.
[TGPPCHARG]第3世代パートナーシッププロジェクト、技術仕様グループのサービスとシステムの側面、「サービスの側面、課金と請求」、3GPP TS 22.115バージョン15.5.0、2018年9月。
A credit-control flow for Network Access Services prepaid is shown in Figure 11. The Diameter protocol application is implemented in the Network Access Server (NAS) per [RFC7155]. The focus of this flow is on credit authorization.
プリペイドネットワークアクセスサービスのクレジット制御フローを図11に示します。Diameterプロトコルアプリケーションは、[RFC7155]に従ってネットワークアクセスサーバー（NAS）に実装されています。このフローの焦点は、クレジット認証です。
NAS
End User (CC Client) AAA Server CC Server
|(1)User Logon |(2)AA-Request (CC AVPs) |
|------------------>|-------------------->| |
| | |(3)CCR(Initial, CC AVPs)
| | |-------------------->|
| | |(4)CCA(Granted-Units)|
| | |<--------------------|
| |(5)AA-Answer(Granted-Units) |
|(6)Access granted |<--------------------| |
|<----------------->| | |
| | | |
: : : :
| |(7)CCR(Update, Used-Units) |
| |-------------------->|(8)CCR |
| | | (Update, Used-Units)
| | |-------------------->|
| | |(9)CCA(Granted-Units)|
| |(10)CCA(Granted-Units)<--------------------|
| |<--------------------| |
: : : :
| (Auth. lifetime expires) | |
| |(11)AAR (CC AVP) | |
| |-------------------->| |
| | (12)AAA | |
| |<--------------------| |
: : : :
: : : :
|(13)User logoff | | |
|------------------>|(14)CCR(Term., Used-Units) |
| |-------------------->|(15)CCR |
| | | (Term., Used-Units)
| | |-------------------->|
| | | (16)CCA |
| | (17)CCA |<--------------------|
| |<--------------------| |
| |(18)STR | |
| |-------------------->| |
| | (19)STA | |
| |<--------------------| |
Figure 11: Flow I
図11：フローI
The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server (2). The credit-control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, as usual [RFC7155]. 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 receiving the AA-Answer, 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 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). The STR/STA takes place between the NAS and home Diameter AAA server, as usual (18), (19).
ユーザーがネットワークにログオンします（1）。 Diameter NASは、Diameter AA-Request（AAR）をホームDiameter AAAサーバーに送信します（2）。 credit-controlクライアントは、CREDIT_AUTHORIZATIONに設定されたCredit-Control AVPをAARに入力し、通常どおり、サービス固有のAVPが含まれます[RFC7155]。ホームDiameter AAAサーバーは、通常どおり、サービス固有の認証と承認を実行します。ホームDiameter AAAサーバーは、ユーザーがプリペイドユーザーであると判断し、NASにクレジット制御機能があることをCredit-Control AVPから通知します。 CC-Request-TypeがINITIAL_REQUESTに設定されたDiameter Credit-Control-RequestをDiameter Credit-Controlサーバーに送信して、与信認証（3）を実行し、与信制御セッションを確立します。 （ホームDiameter AAAサーバーは、NASから受信したサービス固有のAVPを評価プロセスの入力として転送する場合があります。）Diameter Credit-Controlサーバーは、エンドユーザーのアカウント残高を確認し、サービスを評価し、エンドユーザーのアカウントからクレジットを予約します。予約されたクォータは、Diameter Credit-Control-Answer（4）のホームDiameter AAAサーバーに返されます。ホームDiameter AAAサーバーは、Diameter AA-Answer（AAA）で予約済みクォータをNASに送信します。 NASはAA-Answerを受信すると、クレジット制御セッションを開始し、許可されたユニットの監視を開始します（5）。 NASはエンドユーザーにアクセスを許可します（6）。割り当てられたクォータの期限が切れると、NASはCC-Request-TypeをUPDATE_REQUESTに設定したDiameter Credit-Control-RequestをホームDiameter AAAサーバーに送信します（7）。このメッセージには、これまでに使用された単位が含まれています。ホームDiameter AAAサーバーは、CCRをDiameter Credit-Controlサーバーに転送します（8）。 Diameter Credit-Control-Answerは、エンドユーザーのアカウントから使用済みの単位を引き落とし、Diameter Credit-Control-AnswerのホームDiameter AAAサーバーに返される新しい割り当てを割り当てます（9）。メッセージはNASに転送されます（10）。進行中のクレジット制御セッション中に、認証の有効期限が切れ、NASの認証/認証クライアントが通常どおり、ホームDiameter AAAサーバーに対してサービス固有の再認証を実行します。クレジット制御クライアントは、AARにCredit-Control AVPをRE_AUTHORIZATIONに設定して設定します。これは、クレジット認証が付与されたユニットの燃焼率によって制御されるため、クレジット制御サーバーに接続しないことを示します（11）。ホームDiameter AAAサーバーは、通常どおりサービス固有の再認証を実行し、AA-AnswerをNASに返します（12）。エンドユーザーがネットワークからログオフします（13）。エンドユーザーのアカウントから使用済みのユニットを引き落とし、クレジット制御セッションを停止するために、NASは、CC-Request-TypeがTERMINATION_REQUESTに設定されたDiameter Credit-Control-RequestをホームDiameter AAAサーバーに送信します（14）。ホームDiameter AAAサーバーは、CCRをクレジット制御サーバー（15）に転送します。 Diameter Credit-Control-Serverは、Diameter Credit-Control-AnswerをホームDiameter AAAサーバーに送信することにより、セッションの終了を確認します（16）。ホームDiameter AAAサーバーは回答をNASに転送します（17）。 STR / STAは、通常どおり、NASとホームDiameter AAAサーバーの間で行われます（18）、（19）。
Figure 12 provides 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.
図12に、SIPセッションのDiameterクレジット制御の例を示します。フローはクレジット制御メッセージの使用法の説明に重点を置いていますが、SIPシグナリングは不正確であり、この図は決してサービスプロバイダーのSIPネットワークを定義する試みではありません。ただし、この例では、いくつかの前提を以下に示します。
SIP Proxy/Registrar AAA
A (CC Client) Server B CC Server
| (i) REGISTER | | | |
|------------->|(ii) | | |
| |------------->| | |
| |authentication & | |
| |authorization | | |
| |<-------------| | |
|(iii) 200 OK | | |
|<-------------| | |
: : : :
|(1) INVITE | :
|------------->|
| |(2) CCR (Initial, SIP-specific AVP) |
| |------------------------------------------->|
| |(3) CCA (Granted-Units) |
| |<-------------------------------------------|
| |(4) INVITE | |
| |---------------------------->| |
: : : :
| |(5) CCR (Update, Used-Units) |
| |------------------------------------------->|
| |(6) CCA (Granted-Units) |
| |<-------------------------------------------|
: : : :
|(7) BYE | | |
|------------->| | |
| |(8) BYE | |
| |---------------------------->| |
| |(9) CCR (Termination, Used-Units) |
| |------------------------------------------->|
| |(10) CCA () |
| |<-------------------------------------------|
| | | |
Figure 12: Flow II
図12：フローII
Typically, prepaid services based, for example, on time usage for SIP sessions 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 for performing 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 [RFC3261]). 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プロキシが最初のSIP INVITEにRecord-Routeヘッダーを追加して、作成されたダイアログ内の今後のすべての要求がそれを通過することを確認します（「Record-Route」の定義と「ダイアログ」、[RFC3261]を参照してください）。最後に、プロキシによるメディアの信用管理の測定の程度は、SIPネットワークでのエンドシステムとプロキシのセットアップに使用されるビジネスモデル設計に依存します。
The end user (SIP User Agent A) sends a 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, a Diameter multimedia application (ii). The home AAA server checks that the credentials are correct and checks the user profile. Eventually, a 200 OK response (iii) is sent to the User Agent. Note that the authentication and authorization are valid for the registration validity period duration (i.e., until re-registration is performed). Several SIP sessions may be established without re-authorization.
エンドユーザー（SIPユーザーエージェントA）は、資格情報を使用してREGISTERを送信します（i）。 SIPプロキシは、たとえばDiameterマルチメディアアプリケーション（ii）を使用して、マルチメディアの認証と承認を実行する要求をホームAAAサーバーに送信します。ホームAAAサーバーは、資格情報が正しいことを確認し、ユーザープロファイルを確認します。最終的に、200 OK応答（iii）がユーザーエージェントに送信されます。認証と承認は、登録の有効期間中（つまり、再登録が実行されるまで）有効です。再認証なしで、いくつかのSIPセッションが確立される場合があります。
User Agent 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 (SDP) 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 User Agent 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 message (7). The SIP Proxy forwards the BYE message to User Agent 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).
ユーザーエージェントAがINVITE（1）を送信します。 SIPプロキシは、Diameter Credit-Control-Request（INITIAL_REQUEST）をDiameter Credit-Controlサーバーに送信します（2）。 Credit-Control-Requestには、要求されたサービスを説明するSIPシグナリングから取得された情報が含まれます（たとえば、発呼者、被呼者、Session Description Protocol（SDP）属性）。 Diameter Credit-Controlサーバーは、エンドユーザーのアカウントの残高を確認し、サービスを評価し、エンドユーザーのアカウントからクレジットを予約します。予約されたクォータは、Diameter Credit-Control-Answer（3）のSIPプロキシに返されます。 SIPプロキシは、SIP INVITEをユーザーエージェントB（4）に転送します。 Bの電話が鳴り、Bが応答します。メディアはそれらの間を流れ、SIPプロキシはクォータの測定を開始します。割り当てられた割り当ての期限が切れると、SIPプロキシはDiameter Credit-Control-Request（UPDATE_REQUEST）をDiameter Credit-Controlサーバーに送信します（5）。このメッセージには、これまでに使用された単位が含まれています。 Diameter Credit-Controlサーバーは、エンドユーザーのアカウントから使用済みのユニットを引き落とし、Diameter Credit-Control-Answer（6）のSIPプロキシに返される新しいクレジットを割り当てます。エンドユーザーはBYEメッセージを送信してサービスを終了します（7）。 SIPプロキシはBYEメッセージをユーザーエージェントBに転送し（8）、Diameterクレジット制御要求（TERMINATION_REQUEST）をクレジット制御サーバーに送信します（9）。 Diameter Credit-Control-AnswerをSIPプロキシに送信することにより、Diameter Credit-Controlサーバーはセッションの終了を確認します（10）。
A credit-control flow for Multimedia Messaging Service is shown in Figure 13. The sender is charged as soon as the messaging server successfully stores the message.
マルチメディアメッセージングサービスのクレジット制御フローを図13に示します。メッセージングサーバーがメッセージを正常に格納するとすぐに、送信者に課金されます。
MMS Server
A (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (Event, DIRECT_DEBITING, |
| | MMS-specific AVP) |
| |-------------------------------->|
| |(3) CCA (Granted-Units) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure 13: Flow III
図13：フローIII
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 a service provider's MMS configuration or billing model.
これは、マルチメディアメッセージングサービス環境を使用した口座引き落としのDiameter Credit-Controlの例です。フローはクレジット制御メッセージの使用法の説明に重点を置いていますが、MMSシグナリングは不正確であり、この図は決してサービスプロバイダーのMMS構成または請求モデルを定義する試みではありません。
End user A sends an MMS to the MMS server (1). The MMS server stores the message and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to 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).
エンドユーザーAがMMSをMMSサーバーに送信します（1）。 MMSサーバーはメッセージを保存し、Diameter Credit-Control-Request（Requested-ActionをDIRECT_DEBITINGに設定したEVENT_REQUEST）をDiameter Credit-Controlサーバーに送信します（2）。 Credit-Control-Requestには、MMSメッセージに関する情報（サイズ、受信者アドレス、画像コーディングタイプなど）が含まれています。 Diameter Credit-Controlサーバーは、エンドユーザーのアカウントの残高を確認し、サービスを評価し、エンドユーザーのアカウントからサービスの料金を引き落とします。付与されたクォータは、Diameter Credit-Control-Answer（3）でMMSサーバーに返されます。
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).
MMSサーバーは、MMSメッセージの正常な受信を確認します（4）。 MMSサーバーは新しいMMSについて受信者に通知し（5）、エンドユーザーBはMMSメッセージストアからメッセージを取得します（6）、（7）。
Note that the transfer of the MMS message can take an extended period of 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アクションを使用して、借方記入済みのユニットをユーザーのアカウントに返す必要があります。
Another credit-control flow for Multimedia Messaging Service is shown in Figure 14. The recipient is charged at the time of message delivery.
マルチメディアメッセージングサービスの別のクレジット制御フローを図14に示します。受信者は、メッセージの配信時に課金されます。
MMS Server
Content Server (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (Event, CHECK_BALANCE, |
| | MMS-specific AVP) |
| |-------------------------------->|
| |(3) CCA (ENOUGH_CREDIT) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) CCR (Event, DIRECT_DEBITING, |
| | MMS-specific AVP) |
| |-------------------------------->|
| |(8) CCA (Granted-Units) |
| |<--------------------------------|
| |(9) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure 14: Flow IV
図14：フロー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 a service provider's MMS configuration or billing model.
これは、マルチメディアメッセージングサービス環境を使用した口座引き落としのDiameter Credit-Controlの例です。フローはクレジット制御メッセージの使用法の説明に重点を置いていますが、MMSシグナリングは不正確であり、この図は決してサービスプロバイダーのMMS構成または請求モデルを定義する試みではありません。
A content server sends an MMS to the MMS server (1), which 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 sessions to the Diameter Credit-Control server; rather, it first performs only a balance check (without any credit reservations) by sending a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to 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 set to 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-Answer (8). The MMS is transferred to end user B (9).
コンテンツサーバーはMMSをMMSサーバーに送信し（1）、メッセージを保存します。この場合、メッセージの受信者はMMSメッセージに対して課金されます。 MMSサーバーでのメッセージの受信とメッセージの実際の取得との間にはかなり長い時間がかかる可能性があるため、MMSサーバーはDiameterクレジット制御サーバーへのクレジット制御セッションを確立しません。むしろ、Diameter Credit-Control-Request（Requested-ActionがCHECK_BALANCEに設定されたEVENT_REQUEST）を送信して、最初に残高チェックのみを実行し（クレジット予約なし）、エンドユーザーBがMMSのコストをカバーできることを確認します（2） 。 Diameter Credit-Control-serverは、エンドユーザーのアカウント残高を確認し、Diameter Credit-Control-Answer（3）でMMSサーバーに応答を返します。 MMSサーバーは、MMSメッセージの正常な受信を確認します（4）。 MMSサーバーは受信者に新しいMMSを通知し（5）、しばらくしてエンドユーザーBがMMSメッセージストアからメッセージを取得します（6）。 MMSサーバーは、Diameter Credit-Control-Request（Requested-ActionをDIRECT_DEBITINGに設定したEVENT_REQUEST）をDiameter Credit-Controlサーバーに送信します（7）。 Credit-Control-Requestには、MMSメッセージに関する情報（サイズ、受信者アドレス、コーディングタイプなど）が含まれています。 Diameter Credit-Controlサーバーは、エンドユーザーのアカウントの残高を確認し、サービスを評価し、エンドユーザーのアカウントからサービスの料金を引き落とします。付与されたクォータは、Diameter Credit-Control-Answer（8）でMMSサーバーに返されます。 MMSはエンドユーザーBに転送されます（9）。
Note that the transfer of the MMS message can take an extended period of 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アクションを使用して、借方記入済みのユニットをユーザーのアカウントに返す必要があります。
Figure 15 provides an example of an Advice of Charge (AoC) service for a SIP call.
図15は、SIP通話の料金通知（AoC）サービスの例を示しています。
SIP Controller
User Agent A (CC Client) User Agent B CC Server
|(1)INVITE | | |
| User Agent B(SDP)| | |
|------------------>| | |
| |(2)CCR (Event, PRICE_ENQUIRY, |
| | SIP-specific AVPs) |
| |------------------------------->|
| |(3)CCA (Cost-Information) |
| |<-------------------------------|
|(4)MESSAGE(URL) | | |
|<------------------| | |
|(5)HTTP GET | | |
|------------------>| | |
|(6)HTTP POST | | |
|------------------>|(7)INVITE(SDP) | |
| |--------------->| |
| | (8)200 OK | |
| (9)200 OK |<---------------| |
|<------------------| | |
Figure 15: Flow V
図15：フローV
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ネットワークを定義する試みではありません。
User Agent 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 has been subscribed to the AoC service.
ユーザーエージェントAは、AoCサービスを使用する後払いまたは前払いの加入者になります。 SIPコントローラーはHTTP機能も備えており、たとえば、コスト情報、SDPから派生した通話の詳細、料金を受け入れる/受け入れないボタンなどのインタラクティブなAoC Webページを配信すると想定されています。 （AoC情報を配信する方法は他にも多数ある可能性がありますが、このフローはクレジット制御メッセージの使用に重点を置いています。）ユーザーは、呼び出しを開始する前に認証および承認され、AoCサービスに登録されています。
User Agent A sends an INVITE with the SDP to User Agent B via the SIP controller (1). The SIP controller determines that the user is subscribed to an AoC service and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to 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, SDP 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. It then sends a SIP MESSAGE that contains a URL pointing to the AoC information web page (4). Upon receipt of the SIP MESSAGE, User Agent A automatically invokes the web browser that retrieves the AoC information (5). The user clicks on the appropriate button to accept the charges (6). The SIP controller continues the session and sends the INVITE to User Agent B, which accepts the call (7), (8), (9).
ユーザーエージェントAは、SDPを含むINVITEをSIPコントローラーを介してユーザーエージェントBに送信します（1）。 SIPコントローラーは、ユーザーがAoCサービスにサブスクライブしていると判断し、Diameterクレジット制御要求（Requested-ActionがPRICE_ENQUIRYに設定されたEVENT_REQUEST）をDiameterクレジット制御サーバーに送信します（2）。 Credit-Control-Requestには、SIPシグナリングから派生したSIP固有のAVPが含まれ、要求されたサービス（たとえば、発呼者、被呼者、SDP属性）を記述します。 Diameter Credit-Controlサーバーはサービスのコストを決定し、Cost-Information AVPを含むCredit-Control-Answerを返します（3）。 SIPコントローラーは、SIPシグナリングで受信した情報とクレジットコントロールサーバーから受信したコスト情報を含むAoC Webページを製造します。次に、AoC情報Webページを指すURLを含むSIPメッセージを送信します（4）。 SIPメッセージを受信すると、ユーザーエージェントAは、AoC情報を取得するWebブラウザーを自動的に呼び出します（5）。ユーザーは適切なボタンをクリックして料金を受け入れます（6）。 SIPコントローラーはセッションを続行し、呼び出しを受け入れるユーザーエージェントBにINVITEを送信します（7）、（8）、（9）。
Figure 16 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.
図16は、REFUNDケースのクレジット制御フローを示しています。ゲームサーバーとDiameter Credit-Controlサーバーの間に信頼関係と安全な接続があると想定されています。エンドユーザーは、前払いの加入者または後払いの加入者であり得る。
Gaming Server
End User (CC Client) CC Server
| (1)Service Delivery | |
|<---------------------->| |
: : :
: : :
| |(2)CCR(Event, REFUND,Requested-
| |Service-Unit, Service-Parameter-Info)
| |----------------------->|
| | (3)CCA(Cost-Information)
| |<-----------------------|
| (4)Notification | |
|<-----------------------| |
Figure 16: Flow VI
図16：フローVI
While the end user is playing the game (1), they enter a new level that entitles them to a bonus. The gaming server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action set to REFUND_ACCOUNT) to the Diameter Credit-Control server (2). The Credit-Control-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 AVP indicates the credited amount. At the first opportunity, the gaming server notifies the end user of the credited amount (4).
エンドユーザーがゲームをプレイしている間（1）、ボーナスを獲得できる新しいレベルに入ります。ゲームサーバーは、Diameter Credit-Control-Request（Requested-ActionをREFUND_ACCOUNTに設定したEVENT_REQUEST）をDiameter Credit-Controlサーバーに送信します（2）。 Credit-Control-RequestにはRequested-Service-Unit AVPが含まれ、CC-Service-Specific-Unitsにはユーザーがたった今獲得したポイント数が含まれます。 Service-Parameter-Info AVPもリクエストに含まれ、評価するサービスイベントを指定します（例：Tetris Bonus）。受け取った情報から、Diameter Credit-Controlサーバーはクレジットされる金額を決定し、ユーザーのアカウントに返金し、Cost-Information AVPを含むCredit-Control-Answerを返します（3）。コスト情報AVPはクレジットされた金額を示します。最初の機会に、ゲームサーバーはクレジットされた金額をエンドユーザーに通知します（4）。
Figure 17 provides an example of 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 on graceful service termination and credit-control authorization. Best practices for 3PCC are defined in [RFC3725].
図17は、SIPコールの適切なサービス終了の例を示しています。コントローラがB2BUA（Back-to-Back User Agent）としてサードパーティの通話制御（3PCC）を実行するように通話が設定されていることを前提としています。このフローの焦点は、適切なサービスの終了とクレジット制御の承認にあるため、SIPシグナリングは不正確であることに注意してください。 3PCCのベストプラクティスは[RFC3725]で定義されています。
SIP Controller Top-Up
User Agent A (CC Client) Server User Agent B CC Server
| | | | |
| | (1)CCR(Update, Used-Units) | |
| |------------------------------------------>|
| | (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-Units)|
| |<------------------------------------------|
| (12)INVITE | (11)INVITE | |
|<---------------|--------------------------->| |
Figure 17: Flow VII
図17：フローVII
The call is ongoing between User Agents A and B; User Agent 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 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 reservations. The Credit-Control-Answer message, which contains the Validity-Time to supervise the graceful service termination process, 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, 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 reconnects the caller and the called party (11), (12).
通話はユーザーエージェントAとBの間で進行中です。ユーザーエージェントAは前払いのサブスクリプションを持っています。割り当てられた割り当ての期限が切れると、SIPコントローラーはDiameter Credit-Control-Request（UPDATE_REQUEST）をDiameter Credit-Controlサーバーに送信します（1）。このメッセージには、これまでに使用された単位が含まれています。 Diameterクレジットコントロールサーバーは、エンドユーザーのアカウントから使用済みのユニットを引き落とし、Diameterクレジットコントロールアンサー（2）のSIPコントローラーに返される最終的な割り当てを割り当てます。このメッセージには、Final-Unit-ActionがREDIRECTに設定されたFinal-Unit-Indication AVP、SIP URIに設定されたRedirect-Address-Type、およびトップアップサーバー名（たとえば、sipに設定されたRedirect-Server-Addressが含まれます。 ：sip-topup-server@domain.com）。最終的に割り当てられた割り当ての期限が切れると、SIPコントローラーはDiameter Credit-Control-Request（UPDATE_REQUEST）をDiameter Credit-Controlサーバー（3）に送信し、適切な接続でINVITEを送信することにより、着信側を「保留」にします。 SDPのアドレス（3a）。 Credit-Control-Requestメッセージには、これまでに使用された単位が含まれています。 Diameter Credit-Controlサーバーは、使用済みのユニットをエンドユーザーのアカウントから引き落としますが、クレジットの予約は行いません。正常なサービス終了プロセスを監視するためのValidity-Timeを含むCredit-Control-Answerメッセージは、SIPコントローラーに返されます（4）。 SIPコントローラは、プリペイドユーザーとトップアップサーバーの間にSIPセッションを確立します（5）、（6）。トップアップサーバーはアナウンスを再生し、ユーザーにクレジットカード番号とアカウントの補充に使用する金額の入力を求めます（7）。トップアップサーバーは、クレジットカード番号を検証し、ユーザーのアカウントに（この仕様の範囲外の手段を使用して）補充し、SIPセッションを解放します（8）。これで、SIPコントローラーは、プリペイドユーザーとトップアップサーバー間の通信が行われたと見なすことができます。自発的なCredit-Control-Request（UPDATE_REQUEST）をDiameter Credit-Controlサーバーに送信して、アカウントが補充されているかどうかを確認します（9）。 Diameter Credit-Controlサーバーは、エンドユーザーのアカウントからクレジットを予約し、予約された割り当て量をCredit-Control-Answer（10）のSIPコントローラに返します。この時点で、SIPコントローラーは発信者と着信者を再接続します（11）、（12）。
Figure 18 provides an example of 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 protocol application is implemented in the NAS per [RFC7155].
図18は、ユーザーのアカウントが空であるために最初の問い合わせが行われたときに開始されるサービスの正常終了の例を示しています。この例では、クレジット制御サーバーは、サーバーが開始するクレジットの再承認をサポートしています。 Diameterプロトコルアプリケーションは、[RFC7155]に従ってNASに実装されています。
NAS Top-Up CC
End User (CC Client) AAA Server Server Server
|(1)User Logon |(2)AA-Request (CC AVPs) | |
|------------------>|------------------->| | |
| | |(3)CCR(Initial, CC AVPs)
| | |------------------->|
| | |(4)CCA(Final-Unit, |
| | | Validity-Time)|
| | |<-------------------|
| |(5)AA-Answer(Final-Unit, Validity-Time) |
|(6)Limited access |<-------------------| | |
| granted | | | |
|<----------------->| | | |
| | | | |
| (7)TCP/HTTP | (8)TCP/HTTP | |
|<----------------->|<----------------------------->| |
| (9)Replenish account | |
|<------------------------------------------------->| |
| | | (10)RAR |
| |<-------------------|<-------------------|
| |(11)RAA | |
| |------------------->|------------------->|
| |(12)CCR(Update) | |
| |------------------->|(13)CCR(Update) |
| | |------------------->|
| | |(14)CCA(Granted-Units)
| |(15)CCA(Granted-Units)<------------------|
| |<-------------------| |
Figure 18: Flow VIII
図18：フローVIII
The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server (2). The credit-control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, as usual [RFC7155]. 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- 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 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 their 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 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). An appropriate web page is provided for the user where the user can enter the credit card number and the amount of money to be used to replenish the account, along with a notification message that they are granted unlimited access if the replenishment operation will be successfully executed within, for example, the next 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).
ユーザーがネットワークにログオンします（1）。 Diameter NASは、Diameter AA-Request（AAR）をホームDiameter AAAサーバーに送信します（2）。 credit-controlクライアントは、CREDIT_AUTHORIZATIONに設定されたCredit-Control AVPをAARに入力し、通常どおり、サービス固有のAVPが含まれます[RFC7155]。ホームDiameter AAAサーバーは、通常どおり、サービス固有の認証と承認を実行します。ホームDiameter AAAサーバーは、ユーザーがプリペイドサブスクリプションを持っていると判断し、NASにクレジット制御機能があることをCredit-Control AVPから通知します。これは、CC-Request-TypeがINITIAL_REQUESTに設定されたDiameter Credit-Control-RequestをDiameter Credit-Controlサーバーに送信して、クレジット認証（3）を実行し、クレジット制御セッションを確立します。 （ホームDiameter AAAサーバーは、NASから受信したサービス固有のAVPを評価プロセスの入力として転送する場合があります。）Diameter Credit-Controlサーバーは、エンドユーザーのアカウント残高を確認し、アカウントがサービスのコストをカバーできないと判断します。正常なサービス終了を開始します。 Credit-Control-AnswerがホームDiameter AAAサーバーに返されます（4）。このメッセージには、Final-Unit-Indication AVPと妥当な時間に設定されたValidity-Time AVPが含まれており、ユーザーにアカウントを補充する機会を与えます（例：10分）。 Final-Unit-Indication AVPには、REDIRECTに設定されたFinal-Unit-Action、URLに設定されたRedirect-Address-Type、およびHTTPトップアップサーバー名に設定されたRedirect-Server-Addressが含まれます。ホームDiameter AAAサーバーは、受信したCredit-Control AVPをDiameter AA-AnswerのNASに送信します（5）。 AAAが成功すると、NASはクレジット制御セッションを開始し、サーバーの指示に従ってすぐに適切なサービス終了を開始します。 NASはユーザーに制限付きアクセスを許可します（6）。ユーザーのデバイスで実行されているHTTPクライアントソフトウェアは、NASによってトップアップサーバーにリダイレクトされたトランスポート接続を開きます（7）、（8）。ユーザーがクレジットカード番号とアカウントの補充に使用する金額を入力できる適切なWebページが提供され、補充操作が正常に実行された場合に無制限のアクセスが許可されるという通知メッセージが表示されます。たとえば、次の10分以内。トップアップサーバーはクレジットカード番号を検証し、ユーザーのアカウントに補充します（この仕様の範囲外の手段を使用します）（9）。アカウントの追加に成功すると、クレジット制御サーバーは再認証リクエストメッセージをNASに送信します（10）。 NASは、再認証応答メッセージ（11）を返すことによって要求を確認し、Diameterクレジット制御サーバー（12）、（13）にクレジット制御要求（UPDATE_REQUEST）を送信することによって、クレジット再認証を開始します。
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 applied by graceful service termination and starts monitoring the granted units.
Diameter Credit-Controlサーバーは、エンドユーザーのアカウントからクレジットを予約し、予約されたクォータをCredit-Control-AnswerのホームDiameter AAAサーバー経由でNASに返します（14）、（15）。 NASは、サービスの正常終了によって適用された制限を削除し、許可されたユニットの監視を開始します。
The Diameter Credit-Control application defines the Multiple-Services-Credit-Control AVP, which 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.
Diameter Credit-Controlアプリケーションは、Multiple-Services-Credit-Control AVPを定義します。これは、そのような機能を持つサービス要素の単一のクレジット制御（サブ）セッションで複数のサービスの独立したクレジット制御をサポートするために使用できます。サービスまたは評価グループ間で共有されるクレジットプールとしてリソースを要求および割り当てることができます。
Figure 19 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-tuples) are locally configured in the Service Element or provisioned by an entity other than the credit-control server.
図19は、セクション5.1.2で定義されているように、クレジット制御クライアントとサーバーが複数のサービスの独立したクレジット制御をサポートする使用シナリオを示しています。サービス識別子、評価グループ、およびそれらに関連するパラメーター（IP 5タプルなど）は、サービス要素でローカルに構成されているか、またはクレジット制御サーバー以外のエンティティーによってプロビジョニングされていると想定されています。
End User Service Element CC Server
(CC Client)
|(1)User logon | |
|------------------>|(2)CCR(Initial, Service-Id access, |
| | Access-specific AVPs, |
| | Multiple-Services-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) |
|------------------>| |
: : :
: : :
|(8)Service-Request (Services 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))) |
| |<-------------------------------------------|
: : :
: : :
| +--------------+ | |
| |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 | | Multiple-Services-CC ( |
| |continues | | 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 19: Flow IX: Example of Independent Credit-Control of Multiple Services in a Credit-Control (Sub-)Session
図19：フローIX：クレジット制御（サブ）セッションでの複数のサービスの独立したクレジット制御の例
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-Services-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 with a quota of 5 MB associated to the Service-Id (access), to a multiplier value of 10, and to Pool-Id 1 (3).
ユーザーがネットワークにログオンします（1）。サービスエレメントはDiameter Credit-Control-RequestをCC-Request-TypeにINITIAL_REQUESTに設定してDiameter Credit-Controlサーバーに送信し、ベアラサービス（インターネットアクセスサービスなど）のクレジット認証を実行し、クレジット制御セッションを確立します。 （2）。このメッセージでは、クレジット制御クライアントは、Multiple-Services-Indicator AVPを含めることにより、セッション内の複数のサービスの独立したクレジット制御のサポートを示しています。 Diameter Credit-Controlサーバーは、クライアントから受信した評価情報（つまり、サービスIDとアクセス固有のAVP）を使用して、エンドユーザーのアカウント残高をチェックします。リクエストを評価します。エンドユーザーのアカウントからクレジットを予約します。サーバーが$ 5を予約し、コストが$ 1 / MBであると決定するとします。次に、サービス要素に、サービスID（アクセス）に関連付けられた割り当てが5 MBのMultiple-Services-Credit-Control AVPを含むCredit-Control-Answerメッセージ、乗数値10、およびプール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 50 minutes associated to Rating-Group 1, to a multiplier value of 1, and to Pool-Id 1 (6). The client adjusts the total amount of resources for pool 1 according to the received quota, which gives S for pool 1 = 100.
ユーザーはサービス1（4）を使用します。サービス要素は、CC-Request-TypeがUPDATE_REQUESTに設定されたDiameter Credit-Control-Requestをクレジットコントロールサーバーに送信して、サービス1（5）のクレジット認証を実行します。このメッセージには、Multiple-Services-Credit-Control AVPが含まれており、Rating-Group 1に属するサービス1のサービスユニットをリクエストします。DiameterCredit-Controlサーバーは、サービス1がアクセスサービスと同じアカウントからクレジットリソースを取得することを決定します（つまり、 、プール1）。 Service-Id / rating-groupに従ってリクエストを評価し、追加のクレジットをリクエストして既存の予約を更新します。サーバーがさらに$ 5（予約は$ 10）を予約し、コストが$ 0.1 /分であると判断したとします。サーバーは、評価グループ全体を承認します。次に、サービス要素にCredit-Control-Answerメッセージを返します。このメッセージには、Rating-Group 1、乗数の値1、およびPool-Idに関連付けられた50分の割り当てを持つMultiple-Services-Credit-Control AVPが含まれています。 1（6）。クライアントは、受信した割り当てに従ってプール1のリソースの総量を調整します。これにより、プール1のS = 100になります。
The user uses service 2, which belongs to the authorized rating-group (Rating-Group 1) (7). Resources are then consumed from pool 1.
ユーザーは、承認された評価グループ（評価グループ1）に属するサービス2を使用します（7）。その後、リソースはプール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 service units 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-Id/rating-group information, rates the request. It then reserves credit from pool 2.
ユーザーはサービス3と4もリクエストしますが、これらは許可されていません（8）。サービス要素は、CC-Request-TypeがUPDATE_REQUESTに設定されたDiameter Credit-Control-Requestをクレジットコントロールサーバーに送信して、サービス3および4のクレジット認証を実行します（9）。このメッセージには、Multiple-Services-Credit-Control AVPの2つのインスタンスが含まれており、Rating-Group 2に属するサービス3のサービスユニットと、Rating-Group 3に属するサービス4のサービスユニットをリクエストします。DiameterCredit-Controlサーバーは、そのサービス3と4は、別のアカウント（つまり、プール2）からクレジットリソースを引き出します。エンドユーザーのアカウント残高をチェックし、Service-Id / rating-group情報に従ってリクエストを評価します。次に、プール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.5 MB associated to Service-Id 3 to a multiplier value of 2 and to Pool-Id 2. The other instance grants a quota of 5 MB associated to Service-Id 4 to a multiplier value of 5 and to Pool-Id 2.
たとえば、サーバーは5ドルを予約し、サービス3は$ 0.2 / MB、サービス4は$ 0.5 / MBと決定します。サーバーはサービス3と4のみを承認します。Multiple-Services-Credit-ControlAVP（10）の2つのインスタンスを含むCredit-Control-Answerメッセージをサービス要素に返します。 1つのインスタンスは、Service-Id 3に関連付けられた12.5 MBのクォータを乗数2とPool-Id 2に付与します。もう1つのインスタンスは、Service-Id 4に関連付けられた5 MBのクォータを乗数5とプールID 2。
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 Service-Id 4. The client calculates the total amount of resources that can be used for pool 2 according to the received quotas and multipliers, which gives S for pool 2 = 50.
サーバーは、プール2が使い果たされ、これらのユニットが消費された後はサービス4を続行できないと判断します。したがって、アクションTERMINATEを持つFinal-Unit-Indication AVPはService-Id 4に関連付けられています。クライアントは、受信した割り当てと乗数に従ってプール2に使用できるリソースの総量を計算します。これにより、プール2のSは= 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 the 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 4 MB. The client adjusts the total amount of resources for pool 1 accordingly, which gives S for pool 1 = 60.
アクセスサービスのValidity-Timeが期限切れになります。サービス要素は、サービスID（アクセス）のクレジット再承認を実行するために、Credit-Control-Requestメッセージをサーバーに送信します（11）。このメッセージは、このサービスで使用されるユニットを含むMultiple-Services-Credit-Control AVPの1つのインスタンスを伝達します。使用済みユニットの合計が4 MBであるとします。クライアントはそれに応じてプール1のリソースの総量を調整します。これにより、プール1のS = 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 Pool-Id 1 (12). The client adjusts the total amount of resources for pool 1 according to the received quota, which gives S for pool 1 = 110.
サーバーはユーザーのアカウントから4ドルを差し引き、追加のクレジットを要求して予約を更新します。サーバーがさらに$ 5（現在の予約は$ 11）を予約し、Service-Id（アクセス）のコスト（$ 1 / MB）をすでに知っているとします。次に、サービス要素に、サービスID（アクセス）に関連付けられた割り当てが5 MBのMultiple-Services-Credit-Control AVPを含むCredit-Control-Answerメッセージ、乗数値10、およびプールID 1（12）。クライアントは、受け取った割り当てに従ってプール1のリソースの総量を調整します。これにより、プール1のSは110になります。
Services 3 and 4 consume the total amount of pool 2's credit resources (i.e., C1*2 + C2*5 >= S). The Service Element immediately starts the TERMINATE action for 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).
サービス3と4は、プール2のクレジットリソースの総量を消費します（つまり、C1 * 2 + C2 * 5> = S）。サービス要素はすぐにサービス4のTERMINATEアクションを開始し、サービス3のクレジット再承認を実行するために、CC-Request-TypeがUPDATE_REQUESTに設定されたCredit-Control-Requestメッセージをクレジット制御サーバーに送信します（13）。このメッセージには、Multiple-Services-Credit-Control AVPの2つのインスタンスが含まれており、サービス3と4で使用されるユニットを報告します。サーバーは、ユーザーのアカウント（プール2）から最後の$ 5を差し引き、結果コード4011の応答を返します。 Multiple-Services-Credit-Control AVPは、サービス3がクレジットコントロールなしで続行できることを示します（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 used by each service 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 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).
エンドユーザーがネットワークからログオフします（15）。エンドユーザーのアカウントから使用済みのユニットを引き落とし、クレジット制御セッションを停止するために、サービス要素は、CC-Request-TypeがTERMINATION_REQUESTに設定されたDiameter Credit-Control-Requestをクレジット制御サーバーに送信します（16）。このメッセージには、Multiple-Services-Credit-Control AVPの複数のインスタンスで各サービスによって使用されるユニットが含まれています。使用される単位は、関連するサービスIDと評価グループに関連付けられています。 Diameter Credit-Control-Serverは、使用されたユニットをユーザーのアカウント（プール1）から引き落とし、Diameter Credit-Control-Answerをサービス要素（17）に送信してセッションの終了を確認します。
Acknowledgements
謝辞
The original authors of RFC 4006 are Harri Hakala, Leena Mattila, Juha-Pekka Koskinen, Marco Stura, and John Loughney.
RFC 4006の原作者は、ハリハカラ、リーナマティラ、ジュハペッカコスキネン、マルコスチュラ、ジョンラフニーです。
The authors would like to thank Bernard Aboba, Jari Arkko, Robert Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, Jussi Maki, Paco Marin, Jeff Meyer, Anne Narhi, John Prudhoe, Christopher Richards, Juha Vallinen, and Mark Watson for their comments and suggestions.
著者は、Bernard Aboba、Jari Arkko、Robert Ekblad、Pasi Eronen、Benny Gustafsson、Robert Karlsson、Avi Lior、Jussi Maki、Paco Marin、Jeff Meyer、Anne Narhi、John Prudhoe、Christopher Richards、Juha Vallinen、およびMarkに感謝します。 Watsonのコメントと提案。
Authors' Addresses
著者のアドレス
Lyle Bertz (editor) Sprint 6220 Sprint Parkway Overland Park, KS 66251 United States of America
ライルバーツ（編集者）スプリント6220スプリントパークウェイオーバーランドパーク、KS 66251アメリカ合衆国
Email: lyleb551144@gmail.com
David Dolson (editor) Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada
David Dolson（編集者）Sandvine 408 Albert Street Waterloo、ON N2L 3V3 Canada
Email: ddolson@acm.org
Yuval Lifshitz (editor) Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada
Yuval Lifshitz（編集者）Sandvine 408 Albert Street Waterloo、ON N2L 3V3 Canada
Email: yuvalif@yahoo.com