[要約] RFC 4006は、Diameter Credit-Control Applicationの仕様を定義しており、クレジット制御に関連するプロトコルメッセージの交換を可能にします。このRFCの目的は、クライアントとサーバー間でのクレジット制御情報の送受信を効率的に行うことです。
Network Working Group H. Hakala
Request for Comments: 4006 L. Mattila
Category: Standards Track Ericsson
J-P. Koskinen
M. Stura
J. Loughney
Nokia
August 2005
Diameter Credit-Control Application
直径クレジット制御アプリケーション
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.
このドキュメントは、ネットワークアクセス、セッション開始プロトコル（SIP）サービス、メッセージングサービス、ダウンロードサービスなど、さまざまなエンドユーザーサービスのリアルタイムクレジット制御を実装するために使用できる直径アプリケーションを指定します。
Table of Contents
目次
1. Introduction................................................. 4
1.1. Requirements Language................................. 5
1.2. Terminology........................................... 5
1.3. Advertising Application Support....................... 7
2. Architecture Models.......................................... 7
3. Credit-Control Messages...................................... 9
3.1. Credit-Control-Request (CCR) Command.................. 9
3.2. Credit-Control-Answer (CCA) Command................... 11
4. Credit-Control Application Overview.......................... 11
4.1. Service-Specific Rating Input and Interoperability.... 13
5. Session Based Credit-Control................................. 15
5.1. General Principles.................................... 15
5.2. First Interrogation................................... 21
5.3. Intermediate Interrogation............................ 27
5.4. Final Interrogation................................... 29
5.5. Server-Initiated Credit Re-Authorization.............. 30
5.6. Graceful Service Termination.......................... 32
5.7. Failure Procedures.................................... 38
6. One Time Event............................................... 41
6.1. Service Price Enquiry................................. 42
6.2. Balance Check......................................... 42
6.3. Direct Debiting....................................... 43
6.4. Refund................................................ 44
6.5. Failure Procedure..................................... 44
7. Credit-Control Application State Machine..................... 46
8. Credit-Control AVPs.......................................... 55
8.1. CC-Correlation-Id AVP................................. 58
8.2. CC-Request-Number AVP................................. 58
8.3. CC-Request-Type AVP................................... 58
8.4. CC-Session-Failover AVP............................... 59
8.5. CC-Sub-Session-Id AVP................................. 59
8.6. Check-Balance-Result AVP.............................. 60
8.7. Cost-Information AVP.................................. 60
8.8. Unit-Value AVP........................................ 61
8.9. Exponent AVP.......................................... 61
8.10. Value-Digits AVP...................................... 61
8.11. Currency-Code AVP..................................... 62
8.12. Cost-Unit AVP......................................... 62
8.13. Credit-Control AVP.................................... 62
8.14. Credit-Control-Failure-Handling AVP................... 62
8.15. Direct-Debiting-Failure-Handling AVP.................. 63
8.16. Multiple-Services-Credit-Control AVP.................. 64
8.17. Granted-Service-Unit AVP.............................. 65
8.18. Requested-Service-Unit AVP............................ 66
8.19. Used-Service-Unit AVP................................. 66
8.20. Tariff-Time-Change AVP................................ 67
8.21. CC-Time AVP........................................... 67
8.22. CC-Money AVP.......................................... 67
8.23. CC-Total-Octets AVP................................... 68
8.24. CC-Input-Octets AVP................................... 68
8.25. CC-Output-Octets AVP.................................. 68
8.26. CC-Service-Specific-Units AVP......................... 68
8.27. Tariff-Change-Usage AVP............................... 68
8.28. Service-Identifier AVP................................ 69
8.29. Rating-Group AVP...................................... 69
8.30. G-S-U-Pool-Reference AVP.............................. 69
8.31. G-S-U-Pool-Identifier AVP............................. 70
8.32. CC-Unit-Type AVP...................................... 70
8.33. Validity-Time AVP..................................... 70
8.34. Final-Unit-Indication AVP............................. 71
8.35. Final-Unit-Action AVP................................. 72
8.36. Restriction-Filter-Rule AVP........................... 72
8.37. Redirect-Server AVP................................... 73
8.38. Redirect-Address-Type AVP............................. 73
8.39. Redirect-Server-Address AVP........................... 74
8.40. Multiple-Services-Indicator AVP....................... 74
8.41. Requested-Action AVP.................................. 74
8.42. Service-Context-Id AVP................................ 75
8.43. Service-Parameter-Info AVP............................ 76
8.44. Service-Parameter-Type AVP............................ 76
8.45. Service-Parameter-Value AVP........................... 77
8.46. Subscription-Id AVP................................... 77
8.47. Subscription-Id-Type AVP.............................. 77
8.48. Subscription-Id-Data AVP.............................. 78
8.49. User-Equipment-Info AVP............................... 78
8.50. User-Equipment-Info-Type AVP.......................... 78
8.50. User-Equipment-Info-Value AVP......................... 79
9. Result Code AVP Values....................................... 79
9.1. Transient Failures.................................... 79
9.2. Permanent Failures.................................... 80
10. AVP Occurrence Table......................................... 80
10.1. Credit-Control AVP Table.............................. 81
10.2. Re-Auth-Request/Answer AVP Table...................... 82
11. RADIUS/Diameter Credit-Control Interworking Model............ 82
12. IANA Considerations.......................................... 85
12.1. Application Identifier................................ 86
12.2. Command Codes......................................... 86
12.3. AVP Codes............................................. 86
12.4. Result-Code AVP Values................................ 86
12.5. CC-Request-Type AVP................................... 86
12.6. CC-Session-Failover AVP............................... 86
12.7. CC-Unit-Type AVP...................................... 87
12.8. Check-Balance-Result AVP.............................. 87
12.9. Credit-Control AVP.................................... 87
12.10. Credit-Control-Failure-Handling AVP................... 87
12.11. Direct-Debiting-Failure-Handling AVP.................. 87
12.12. Final-Unit-Action AVP................................. 87
12.13. Multiple-Services-Indicator AVP....................... 87
12.14. Redirect-Address-Type AVP............................. 88
12.15. Requested-Action AVP.................................. 88
12.16. Subscription-Id-Type AVP.............................. 88
12.17. Tariff-Change-Usage AVP............................... 88
12.18. User-Equipment-Info-Type AVP.......................... 88
13. Credit-Control Application Related Parameters................ 88
14. Security Considerations...................................... 89
14.1. Direct Connection with Redirects...................... 90
15. References................................................... 91
15.1. Normative References.................................. 91
15.2. Informative References................................ 92
16. Acknowledgements............................................. 93
Appendix A Credit-Control Sequences.............................. 94
A.1. Flow I................................................ 94
A.2. Flow II............................................... 96
A.3. Flow III.............................................. 98
A.4. Flow IV............................................... 99
A.5. Flow V................................................ 100
A.6. Flow VI............................................... 102
A.7. Flow VII.............................................. 103
A.8. Flow VIII............................................. 105
A.9. Flow IX............................................... 107
Authors' Addresses............................................... 112
Full Copyright Statement......................................... 114
This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. It provides a general solution to real-time cost and credit-control.
このドキュメントは、ネットワークアクセス、セッション開始プロトコル（SIP）サービス、メッセージングサービス、ダウンロードサービスなど、さまざまなエンドユーザーサービスのリアルタイムクレジット制御を実装するために使用できる直径アプリケーションを指定します。リアルタイムコストとクレジット制御に対する一般的なソリューションを提供します。
The prepaid model has been shown to be very successful, for instance, in GSM networks, where network operators offering prepaid services have experienced a substantial growth of their customer base and revenues. Prepaid services are now cropping up in many other wireless and wire line based networks.
プリペイドモデルは、たとえばGSMネットワークで非常に成功していることが示されています。GSMネットワークでは、プリペイドサービスを提供するネットワークオペレーターが顧客ベースと収益の大幅な成長を経験しています。現在、プリペイドサービスは、他の多くのワイヤレスおよびワイヤラインベースのネットワークで発生しています。
In next generation wireless networks, additional functionality is required beyond that specified in the Diameter base protocol. For example, the 3GPP Charging and Billing requirements [3GPPCHARG] state that an application must be able to rate service information in real-time. In addition, it is necessary to check that the end user's account provides coverage for the requested service prior to initiation of that service. When an account is exhausted or expired, the user must be denied the ability to compile additional chargeable events.
次世代のワイヤレスネットワークでは、直径ベースプロトコルで指定されているものを超えて追加の機能が必要です。たとえば、3GPP充電および請求要件[3GPPCharg]は、アプリケーションがサービス情報をリアルタイムで評価できる必要があると述べています。さらに、エンドユーザーのアカウントがそのサービスを開始する前に、要求されたサービスのカバレッジを提供することを確認する必要があります。アカウントが使い果たされたり期限切れになった場合、ユーザーは追加の課税可能なイベントをコンパイルする機能を拒否されなければなりません。
A mechanism has to be provided to allow the user to be informed of the charges to be levied for a requested service. In addition, there are services such as gaming and advertising that may credit as well as debit a user account.
要求されたサービスのために、ユーザーが料金を課されることをユーザーに通知できるようにするために、メカニズムを提供する必要があります。さらに、ユーザーアカウントを借方にするだけでなく、ゲームや広告などのサービスがあります。
The other Diameter applications provide service specific authorization, and they do not provide credit authorization for prepaid users. The credit authorization shall be generic and applicable to all the service environments required to support prepaid services.
他の直径アプリケーションは、サービス固有の許可を提供し、プリペイドユーザーに信用承認を提供しません。クレジット承認は一般的であり、プリペイドサービスをサポートするために必要なすべてのサービス環境に適用されるものとします。
To fulfill these requirements, it is necessary to facilitate credit-control communication between the network element providing the service (e.g., Network Access Server, SIP Proxy, and Application Server) and a credit-control server.
これらの要件を満たすには、サービス（ネットワークアクセスサーバー、SIPプロキシ、アプリケーションサーバーなど）とクレジット制御サーバーを提供するネットワーク要素間のクレジット制御通信を促進する必要があります。
The scope of this specification is the credit authorization. Service specific authorization and authentication is out of the scope.
この仕様の範囲は、信用許可です。サービス固有の承認と認証は範囲外です。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS].
このドキュメントでは、キーワードは「可能性があります」、「必要はありません」、「オプション」、「推奨」、「必要」、「必要はありません」は、[キーワード]で説明されているように解釈されます。
AAA
aaa
Authentication, Authorization, and Accounting
認証、承認、および会計
AA answer
AAの答え
AA answer generically refers to a service specific authorization and authentication answer. AA answer commands are defined in service specific authorization applications, e.g., [NASREQ] and [DIAMMIP].
AA回答は、サービス固有の承認と認証の回答を一般的に指します。AA回答コマンドは、[Nasreq]および[diammip]など、サービス固有の認証アプリケーションで定義されます。
AA request
AAリクエスト
AA request generically refers to a service specific authorization and authentication request. AA request commands are defined in service specific authorization applications e.g., [NASREQ] and [DIAMMIP].
AA要求は、サービス固有の承認と認証リクエストを一般的に指します。AA要求コマンドは、[Nasreq]および[Diammip]などのサービス固有の認証アプリケーションで定義されます。
Credit-control
信用管理
Credit-control is a mechanism that directly interacts in real-time with an account and controls or monitors the charges related to the service usage. Credit-control is a process of checking whether credit is available, credit-reservation, deduction of credit from the end user account when service is completed and refunding of reserved credit that is not used.
クレジット制御は、アカウントとリアルタイムで直接相互作用し、サービスの使用に関連する料金を制御または監視するメカニズムです。クレジット制御とは、クレジットが利用可能かどうか、クレジット予約、サービスが完了したときのエンドユーザーアカウントからのクレジットの控除、および使用されていない予約されたクレジットの返金を確認するプロセスです。
Diameter Credit-control Server
直径クレジットコントロールサーバー
A Diameter credit-control server acts as a prepaid server, performing real-time rating and credit-control. It is located in the home domain and is accessed by service elements or Diameter AAA servers in real-time for purpose of price determination and credit-control before the service event is delivered to the end-user. It may also interact with business support systems.
直径のクレジットコントロールサーバーは、リアルタイムの評価とクレジット制御を実行するプリペイドサーバーとして機能します。ホームドメインにあり、サービスイベントがエンドユーザーに配信される前に、価格決定とクレジット制御を目的として、サービス要素または直径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 credit-control server.
直径クレジットコントロールクライアントは、クレジット制御サーバーと対話するエンティティです。クレジットコントロールサーバーによって返された指示に従って、付与されたクォータの使用を監視します。
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.
直径クレジットコントロールクライアントは、尋問を使用して、セッションベースのクレジット制御プロセスを開始します。クレジット制御プロセス中に、使用済みのクォータを報告し、新しいクォータをリクエストするために使用されます。要求/回答トランザクションへの尋問マップ。
One-time event
ワンタイムイベント
Basically, a request/answer transaction of type event.
基本的に、タイプイベントのリクエスト/回答トランザクション。
Rating
評価
The act of determining the cost of the service event.
サービスイベントのコストを決定する行為。
Service
サービス
A type of task performed by a service element for an end user.
エンドユーザーのサービス要素によって実行されるタスクの種類。
Service Element
サービス要素
A network element that provides a service to the end users. The Service Element may include the Diameter credit-control client, or another entity (e.g., RADIUS AAA server) that can act as a Credit-control client on behalf of the Service Element. In the latter case, the interface between the Service Element and the Diameter credit-control client is outside the scope of this specification. Examples of the Service Elements include Network Access Server (NAS), SIP Proxy, and Application Servers such as messaging server, content server, and gaming server.
エンドユーザーにサービスを提供するネットワーク要素。サービス要素には、直径クレジットコントロールクライアント、またはサービス要素に代わってクレジット制御クライアントとして機能できる別のエンティティ（RADIUS AAAサーバーなど）が含まれる場合があります。後者の場合、サービス要素と直径のクレジットコントロールクライアントとの間のインターフェイスは、この仕様の範囲外です。サービス要素の例には、ネットワークアクセスサーバー（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. The intermediate interrogations may be needed to request new quota while the service is being rendered. The final interrogation is used to exit the process. The credit-control server is required to maintain session state for session-based credit-control.
いくつかの尋問を利用するクレジット制御プロセス：最初、可能な中間、および最終。最初の尋問は、ユーザーのアカウントからお金を予約し、プロセスを開始するために使用されます。サービスのレンダリング中に新しいクォータを要求するには、中間尋問が必要になる場合があります。最後の尋問は、プロセスを終了するために使用されます。セッションベースのクレジット制御のためにセッション状態を維持するには、クレジット制御サーバーが必要です。
Diameter nodes conforming to this specification MUST advertise support by including the value of 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE].
この仕様に準拠した直径ノードは、機能のauth-application-idに4の値を含めることにより、サポートを宣伝する必要があります。
The current accounting models specified in the Radius Accounting [RFC2866] and Diameter base [DIAMBASE] are not sufficient for real-time credit-control, where credit-worthiness is to be determined prior to service initiation. Also, the existing Diameter authorization applications, [NASREQ] and [DIAMMIP], only provide service authorization, but do not provide credit authorization for prepaid users. In order to support real-time credit-control, a new type of server is needed in the AAA infrastructure: Diameter credit-control server. The Diameter credit-control server is the entity responsible for credit authorization for prepaid subscribers.
半径会計[RFC2866]および直径ベース[Diambase]で指定された現在の会計モデルは、サービスの開始前に信用程度が決定されるリアルタイムのクレジット制御には十分ではありません。また、既存の直径認証アプリケーション[NASREQ]および[DiamMip]は、サービス認証のみを提供するだけですが、プリペイドユーザーに信用承認を提供しません。リアルタイムのクレジット制御をサポートするために、AAAインフラストラクチャである直径クレジットコントロールサーバーで新しいタイプのサーバーが必要です。直径クレジットコントロールサーバーは、プリペイド加入者のクレジット許可を担当するエンティティです。
A service element may authenticate and authorize the end user with the AAA server by using AAA protocols; e.g., RADIUS or a Diameter base protocol with a possible Diameter application.
サービス要素は、AAAプロトコルを使用して、AAAサーバーでエンドユーザーを認証および承認する場合があります。たとえば、直径アプリケーションの可能性がある半径または直径ベースプロトコル。
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アカウンティングや直径基本会計プロトコルなどの会計プロトコルを使用して、サービスが開始された後、会計データをアカウンティングサーバーに提供し、サービスが完了するまで可能な暫定レポートを提供できます。ただし、リアルタイムのクレジット制御の場合、これらの承認モデルと会計モデルは十分ではありません。
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 an AAA server. A Business Support System is usually deployed; it includes at least the billing functionality. The credit-control server and AAA server in this architecture model are logical entities. The real configuration can combine them into a single host. The credit-control protocol is the Diameter base protocol with the Diameter credit-control application.
図1は、直径のクレジット制御クライアント、直径のクレジットコントロールサーバー、およびAAAサーバーを備えたサービス要素で構成される典型的なクレジット制御アーキテクチャを示しています。通常、ビジネスサポートシステムが展開されます。少なくとも請求機能が含まれます。このアーキテクチャモデルのクレジット制御サーバーとAAAサーバーは、論理エンティティです。実際の構成は、それらを単一のホストに結合することができます。クレジット制御プロトコルは、直径クレジットコントロールアプリケーションを備えた直径ベースプロトコルです。
When an end user requests services such as SIP or messaging, the request is typically forwarded to a service element (e.g., SIP Proxy) in the user's home domain. In some cases it might be possible that the service element in the visited domain can offer services to the end user; however, a commercial agreement must exist between the visited domain and the home domain. Network access is an example of a service offered in the visited domain where the NAS, through an AAA infrastructure, authenticates and authorizes the user with the user's home network.
エンドユーザーがSIPやメッセージングなどのサービスをリクエストすると、リクエストは通常、ユーザーのホームドメインのサービス要素（SIPプロキシなど）に転送されます。場合によっては、訪問ドメインのサービス要素がエンドユーザーにサービスを提供できる可能性があります。ただし、訪問ドメインとホームドメインの間に商業契約が存在する必要があります。ネットワークアクセスは、AAAインフラストラクチャを通じてNASがユーザーのホームネットワークでユーザーを認証および承認する訪問ドメインで提供されるサービスの例です。
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 place in the credit-control system should perform duplicate detection. System internal interfaces can exist to relay messages between servers and an account manager. However, the detailed architecture of the credit-control system and its interfaces are implementation specific and are out of scope of this specification.
システムには、冗長性と負荷分散のための複数のクレジット制御サーバーがあります。システムには個別の評価サーバーを含めることもでき、アカウントは集中データベースに配置できます。エンドユーザーのアカウントが同じサービスイベントで複数回引き落とされたり、クレジットされたりしないようにするために、クレジット制御システムの1つの場所のみが重複した検出を実行する必要があります。システム内部インターフェイスは、サーバーとアカウントマネージャー間のメッセージを中継するために存在できます。ただし、クレジット制御システムとそのインターフェイスの詳細なアーキテクチャは実装固有であり、この仕様の範囲外です。
Protocol transparent Diameter relays can exist between the credit-control client and credit-control server. Also, Diameter Redirect agents that refer credit-control clients to credit-control servers and allow them to communicate directly can exist. These agents transparently support the Diameter credit-control application. The different roles of Diameter Agents are defined in Diameter base [DIAMBASE], section 2.8.
プロトコル透明な直径リレーは、クレジット制御クライアントとクレジット制御サーバーの間に存在する可能性があります。また、クレジット制御クライアントをクレジット制御サーバーに照会し、直接通信できるようにする直接的なリダイレクトエージェントが存在する可能性があります。これらのエージェントは、直径クレジットコントロールアプリケーションを透過的にサポートしています。直径エージェントのさまざまな役割は、直径ベース[Diambase]、セクション2.8で定義されています。
If Diameter credit-control proxies exist between the credit-control client and the credit-control server, they MUST advertise the Diameter credit-control application support.
クレジット制御クライアントとクレジット制御サーバーの間に直径のクレジット制御プロキシが存在する場合、Diameter Credit-Controlアプリケーションサポートを宣伝する必要があります。
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:
このセクションでは、この仕様に準拠するすべての直径の実装でサポートする必要がある新しい直径メッセージコマンドコード値を定義します。コマンドコードは次のとおりです。
Command-Name Abbrev. Code Reference
-----------------------------------------------------------
Credit-Control-Request CCR 272 3.1
Credit-Control-Answer CCA 272 3.2
Diameter Base [DIAMBASE] defines in the section 3.2 the Command Code ABNF specification. These formats are observed in Credit-Control messages.
直径ベース[Diambase]は、セクション3.2でコマンドコードABNF仕様を定義しています。これらの形式は、クレジット制御メッセージで観察されます。
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.
クレジット制御メッセージ（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は、直径のクレジット制御アプリケーションを示す値4に設定する必要があります。
Message Format
メッセージ形式
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
*[ Subscription-Id ]
[ Service-Identifier ]
[ Termination-Cause ]
[ Requested-Service-Unit ]
[ Requested-Action ]
*[ Used-Service-Unit ]
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
*[ Service-Parameter-Info ]
[ CC-Correlation-Id ]
[ User-Equipment-Info ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
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.
クレジット制御応答メッセージ（CCA）は、コマンドコードフィールドが272に設定され、「R」ビットがコマンドフラグフィールドでクリアされることによって示されます。クレジットコントロールサーバーとDiameter Credit-Controlクライアントの間で使用され、クレジット制御コマンドを確認します。
Message Format
メッセージ形式
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ User-Name ]
[ CC-Session-Failover ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
[ Granted-Service-Unit ]
*[ Multiple-Services-Credit-Control ]
[ Cost-Information]
[ Final-Unit-Indication ]
[ Check-Balance-Result ]
[ Credit-Control-Failure-Handling ]
[ Direct-Debiting-Failure-Handling ]
[ Validity-Time]
*[ Redirect-Host]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ Failed-AVP ]
*[ AVP ]
The credit authorization process takes place before and during service delivery to the end user and generally requires the user's authentication and authorization before any request is sent to the credit-control server. The credit-control application defined in this specification supports two different credit authorization models: credit authorization with money reservation and credit authorization with direct debiting. In both models, the credit-control client requests credit authorization from the credit-control server prior to allowing any service to be delivered to the end user.
クレジット承認プロセスは、エンドユーザーへのサービス提供の前後に行われ、通常、クレジット制御サーバーにリクエストが送信される前に、ユーザーの認証と承認が必要です。この仕様で定義されているクレジット制御アプリケーションは、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 corresponding amount of credit resources. Note that credit resources may not imply actual monetary credit; credit resources may be granted to the credit control client in the form of units (e.g., data volume or time) to be metered.
最初のモデルでは、クレジット制御サーバーはリクエストをレートし、ユーザーのアカウントから適切な金額を留保し、対応するクレジットリソースを返します。クレジットリソースは、実際の金銭的信用を意味するものではないことに注意してください。クレジットリソースは、メーターにされるユニット（データボリュームや時間など）の形でクレジットコントロールクライアントに付与される場合があります。
Upon receipt of a successful credit authorization answer with a certain amount of credit resources, the credit-control client allows service delivery to the end user and starts monitoring the usage of the granted resources. When the credit resources granted to the user have been consumed or the service has been successfully delivered or terminated, the credit-control client reports back to the server the used amount. The credit-control server deducts the used amount from the end user's account; it may perform rating and make a new credit reservation if the service delivery is continuing. This process is accomplished with session based credit-control that includes the first interrogation, possible intermediate interrogations, and the final interrogation. For session based credit-control, both the credit control client and the credit-control server are required to maintain credit-control session state. Session based credit-control is described in more detail, with more variations, in section 5.
クレジットコントロールクライアントは、一定量のクレジットリソースを使用して成功したクレジット承認回答を受け取ると、エンドユーザーへのサービス提供を許可し、付与されたリソースの使用の監視を開始します。ユーザーに付与されたクレジットリソースが消費されるか、サービスが正常に配信または終了された場合、クレジット制御クライアントはサーバーに使用済みの金額を報告します。クレジット制御サーバーは、エンドユーザーのアカウントから使用額を差し引きます。サービス提供が継続している場合、評価を実行し、新しいクレジット予約を行う場合があります。このプロセスは、最初の尋問、可能な中間尋問、および最終的な尋問を含むセッションベースのクレジット制御で達成されます。セッションベースのクレジットコントロールの場合、クレジットコントロールサーバーとクレジットコントロールサーバーの両方が、クレジット制御セッションの状態を維持するために必要です。セッションベースのクレジットコントロールについては、セクション5で、より多くのバリエーションを備えたより詳細に説明されています。
In contrast, credit authorization with direct debiting is a single transaction process wherein the credit-control server directly deducts a suitable amount of money from the user's account as soon as the credit authorization request is received. Upon receipt of a successful credit authorization answer, the credit-control client allows service delivery to the end user. This process is accomplished with the one-time event. Session state is not maintained.
対照的に、ストレクトデビットとのクレジット承認は単一のトランザクションプロセスであり、クレジットコントロールサーバーは、クレジット認証リクエストを受信するとすぐにユーザーのアカウントから適切な金額を直接控除します。クレジット認可の回答が成功すると、クレジット制御クライアントはエンドユーザーへのサービス提供を許可します。このプロセスは、1回限りのイベントで達成されます。セッション状態は維持されていません。
In a multi-service environment, an end user can issue an additional service request (e.g., data service) during an ongoing service (e.g., voice call) toward the same account. Alternatively, during an active multimedia session, an additional media type is added to the session, causing a new simultaneous request toward same account. Consequently, this needs to be considered when credit resources are granted to the services.
マルチサービス環境では、エンドユーザーは、同じアカウントに向けて進行中のサービス（音声通話など）中に追加のサービス要求（データサービスなど）を発行できます。または、アクティブなマルチメディアセッション中に、セッションに追加のメディアタイプが追加され、同じアカウントに対する新しい同時リクエストが発生します。したがって、これは、サービスにクレジットリソースが付与された場合に考慮する必要があります。
The credit-control application also supports operations such as service price enquiry, user's balance check, and refund of credit on the user's account. These operations are accomplished with the one-time event. Session state is not maintained.
クレジット制御アプリケーションは、サービス価格の問い合わせ、ユーザーの残高チェック、ユーザーのアカウントでのクレジットの払い戻しなどの運用もサポートしています。これらの操作は、1回限りのイベントで達成されます。セッション状態は維持されていません。
A flexible credit-control application specific failure handling is defined in which the home service provider can model the credit-control client behavior according to its own credit risk management policy.
柔軟なクレジット制御アプリケーション固有の障害処理が定義されています。この障害は、自社の信用リスク管理ポリシーに従って、ホームサービスプロバイダーがクレジット制御クライアントの動作をモデル化できることです。
The Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP are defined to determine what is done if the sending of credit-control messages to the credit-control server has been temporarily prevented. The usage of the Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP allows flexibility, as failure handling for the credit-control session and one time event direct debiting may be different.
クレジット制御対策処理AVPと直接委任対象の扱い対処AVPは、クレジット制御メッセージの送信がクレジットコントロールサーバーへの送信が一時的に防止された場合に何が行われるかを判断するために定義されています。クレジットコントロール処理AVPと直接委任の対処AVPの使用は、クレジット制御セッションの障害とワンタイムイベントディレクトデビットが異なる場合があるため、柔軟性を可能にします。
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.
直径クレジットコントロールアプリケーションは、クレジット制御のフレームワークを定義します。複数のサービスアプリケーションをサポートする一般的なクレジット制御メカニズムを提供します。したがって、クレジット制御アプリケーションは、評価プロセスで入力として使用できるAVPを定義しません。この直径アプリケーションを使用できる可能性のあるサービスをリストすることは、この一般的なメカニズムの範囲外です。
It is reasonable to expect that a service level agreement will exist between providers of the credit-control client and the credit-control server covering the charging, services offered, roaming agreements, agreed rating input (i.e., AVPs), and so on.
クレジット制御クライアントのプロバイダーと、提供されたサービス、ローミング契約、合意された評価入力（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.
したがって、直径クレジットコントロールサーバーは、クレジット制御メッセージの内容に関して事前に合意した直径のクレジットコントロールクライアントにのみサービスを提供すると想定されています。当然、任意の直径のクレジットコントロールクライアントは、任意の直径のクレジットコントロールサーバーとクレジットコントロールメッセージを交換できる可能性がありますが、サポートされていないサービス/AVPがクレジットコントロールメッセージに存在し、サーバーに原因となる可能性が高い可能性があります。適切な結果コードでリクエストを拒否します。
There are two ways to provide rating input to the credit-control server: either by using AVPs or by including them in the Service-Parameter-Info AVP. The general principles for sending rating parameters are as follows:
クレジットコントロールサーバーに評価入力を提供するには、AVPを使用するか、Service-Parameter-INFO AVPに含めることにより、2つの方法があります。評価パラメーターを送信するための一般原則は次のとおりです。
1a. The service SHOULD re-use existing AVPs if it can use AVPs defined in existing Diameter applications (e.g., NASREQ for network access services). Re-use of existing AVPs is strongly recommended in [DIAMBASE].
1a。既存の直径アプリケーション（ネットワークアクセスサービスのNASREQなど）で定義されたAVPSを使用できる場合、サービスは既存のAVPを再利用する必要があります。既存のAVPの再利用は、[Diambase]で強く推奨されます。
For AVPs of type Enumerated, the service may require a new value to be defined. Allocation of new AVP values is done as specified in [DIAMBASE], section 1.2.
列挙されたタイプのAVPの場合、サービスは定義する新しい値を必要とする場合があります。新しいAVP値の割り当ては、[Diambase]、セクション1.2で指定されているとおりに行われます。
1b. New AVPs can be defined if the existing AVPs do not provide sufficient rating information. In this case, the procedures defined in [DIAMBASE] for creating new AVPs MUST be followed.
1b。既存のAVPが十分な評価情報を提供しない場合、新しいAVPを定義できます。この場合、新しいAVPを作成するために[Diambase]で定義された手順に従う必要があります。
1c. For services specific only to one vendor's implementation, a Vendor-Specific AVP code for Private use can be used. Where a Vendor-Specific AVP is implemented by more than one vendor, allocation of global AVPs is encouraged instead; refer to [DIAMBASE].
1c。1つのベンダーの実装に固有のサービスの場合、プライベート使用のためのベンダー固有のAVPコードを使用できます。ベンダー固有のAVPが複数のベンダーによって実装されている場合、代わりにグローバルAVPの割り当てが奨励されます。[Diambase]を参照してください。
2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER). This method can be used to avoid unnecessary conversions from an existing data format to an AVP format. In this case, the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.43.
2. Service-Parameter-INFO AVPは、元のエンコードされたフォーム（ASN.1 BER）でレガシー評価情報を渡すためのコンテナとして使用できます。この方法は、既存のデータ形式から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, the contents of the Service-Parameter-Info AVP or Service-Context-Id AVP (defined in section 8.42) are not within the scope of this document. To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the Service-Context-Id be coordinated via an informational RFC or other permanent and readily available reference. The specification of another cooperative standardization body (e.g., 3GPP, OMA, and 3GPP2) SHOULD be used. However, private services may be deployed that are subject to agreements between providers of the credit-control server and client. In this case, vendor specific AVPs can be used.
サービス固有の評価入力AVP、Service-Parameter-INFO AVPまたはService-Context-ID AVP（セクション8.42で定義）の内容は、このドキュメントの範囲内ではありません。相互運用性を促進するために、サービスコンテキスト-IDの評価入力と値を、情報RFCまたはその他の永続的で容易に利用できる参照を介して調整することをお勧めします。別の協同組合標準化本体（3GPP、OMA、3GPP2など）の仕様を使用する必要があります。ただし、クレジット制御サーバーとクライアントのプロバイダー間の契約の対象となるプライベートサービスを展開する場合があります。この場合、ベンダー固有のAVPを使用できます。
This specification, together with the above service specific documents, governs the credit-control message. Service specific documents define which existing AVPs or new AVPs are used as input to the rating process (i.e., those that do not define new credit-control applications), and thus have to be included in the Credit-Control-Request command by a Diameter credit-control client supporting a given service as *[AVP]. Should Service-Parameter-Info be used, then the service specific document MUST specify the exact content of this grouped AVP.
この仕様は、上記のサービス固有のドキュメントとともに、クレジット制御メッセージを管理します。サービス固有のドキュメントは、既存のAVPまたは新しいAVPが評価プロセスへの入力（つまり、新しいクレジット制御アプリケーションを定義しないもの）として使用されるため、直径によるクレジット制御リケストコマンドに含める必要があります。特定のサービスを *[AVP]としてサポートするクレジット制御クライアント。Service-Parameter-INFOを使用する場合、サービス固有のドキュメントは、このグループ化された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は、リクエストに適用されるサービス固有のドキュメントを特定するために、クレジット制御リクエストのコマンドレベルに含める必要があります。リクエストが関連する特定のサービスまたは評価グループは、Service-Context-IDとService-IdentifierまたはRating-Groupの組み合わせによって一意に識別されます。
Diameter credit-control implementations are required to support the Mandatory rating AVPs defined in service specific documentation of the services they support, according to the 'M' bit rules in [DIAMBASE].
[Diambase]の「M」ビットルールに従って、直径クレジットコントロールの実装が必要です。
If a rating input required for the rating process is incorrect in the Credit-control request, or if the credit-control server does not support the requested service context (identified by the Service-Context-Id AVP at command level), the Credit-control answer MUST contain the error code DIAMETER_RATING_FAILED. A CCA message with this error MUST contain one or more Failed-AVP AVPs containing the missing and/or unsupported AVPs that caused the failure. A Diameter credit-control client that receives the error code DIAMETER_RATING_FAILED in response to a request MUST NOT send similar requests in the future.
格付けプロセスに必要な格付け入力がクレジット制御要求で正しくない場合、またはクレジット制御サーバーが要求されたサービスコンテキスト（コマンドレベルでのService-Context-ID AVPによって識別）をサポートしていない場合、クレジット - コントロール回答には、エラーコードDiameter_rating_failedが含まれている必要があります。このエラーを備えたCCAメッセージには、障害を引き起こした欠落および/またはサポートされていないAVPを含む1つ以上の失敗AVP AVPを含める必要があります。リクエストに応じてエラーコードDiameter_rating_failedを受信する直径クレジットコントロールクライアントは、将来同様のリクエストを送信してはなりません。
When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed.
サービス固有のドキュメントには、評価プロセスで入力として使用できるRADIUSベンダー固有の属性が含まれている場合、[NASREQ]に記載されているルールが直径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ベンダー識別値に設定する必要があります。直径AVPデータフィールドには、RADIUS属性の属性値のみが含まれます。
For a session-based credit-control, several interrogations are needed: the first, intermediate (optional) and the final interrogations. This is illustrated in Figures 2 and 3.
セッションベースのクレジット制御の場合、最初の、中間（オプション）と最終的な尋問のいくつかの尋問が必要です。これを図2および3に示します。
If the credit-control client performs credit-reservation before granting service to the end user, it MUST use several interrogations toward the credit-control server (i.e., session based credit- control). In this case, the credit-control server MUST maintain the credit-control session state.
クレジット制御クライアントがエンドユーザーにサービスを付与する前にクレジット保存を実行する場合、クレジットコントロールサーバー（つまり、セッションベースのクレジットコントロール）に向けていくつかの尋問を使用する必要があります。この場合、クレジット制御サーバーは、クレジット制御セッションの状態を維持する必要があります。
Each credit-control session MUST have a globally unique Session-Id as defined in [DIAMBASE], which MUST NOT be changed during the lifetime of a credit-control session.
各クレジット制御セッションには、[Diambase]で定義されているグローバルに一意のセッション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 this AVP implies that no sub-sessions are in use.
特定のアプリケーションでは、複数のクレジット制御サブセッションが必要です。これらのアプリケーションは、一定のセッションID AVPでメッセージを送信しますが、異なるCC-Sub-Session-ID AVPを使用します。いくつかのクレジットサブセッションが使用される場合、メインセッションが閉鎖される前にすべてのサブセッションを個別に閉じて、サブセッションごとのユニットが報告されるようにする必要があります。このAVPがないことは、サブセッションが使用されていないことを意味します。
Note that the service element might send a service specific re-authorization message to the AAA server due to expiration of the authorization-lifetime during an ongoing credit-control session. However, the service specific re-authorization does not influence the credit authorization that is ongoing between the credit-control client and credit-control server, as credit authorization is controlled by the burning rate of the granted quota.
サービス要素は、継続的なクレジット制御セッション中に認可-Lifetimeの有効期限が切れるため、AAAサーバーにサービス固有の再承認メッセージを送信する可能性があることに注意してください。ただし、サービス固有の再承認は、クレジットコントロールクライアントとクレジット制御サーバーの間で進行中のクレジット許可に影響を与えません。
If service specific re-authorization fails, the user will be disconnected, and the credit-control client MUST send a final interrogation to the credit-control server.
サービス固有の再承認が失敗した場合、ユーザーは切断され、クレジット制御クライアントはクレジットコントロールサーバーに最終的な尋問を送信する必要があります。
The Diameter credit-control server may seek to control the validity time of the granted quota and/or the production of intermediate interrogations. Thus, it MAY include the Validity-Time AVP in the answer message to the credit-control client. Upon expiration of the Validity-Time, the credit-control client MUST generate a credit-control update request and report the used quota to the credit-control server. It is up to the credit-control server to determine the value of the Validity-Time to be used for consumption of the granted service units. If the Validity-Time is used, its value SHOULD be given as input to set the session supervision timer Tcc (the session supervision timer MAY be set to two times the value of the Validity-Time, as defined in section 13). Since credit-control update requests are also produced at the expiry of granted service units and/or for mid-session service events, the omission of Validity-Time does not mean that intermediate interrogation for the purpose of credit-control is not performed.
直径クレジットコントロールサーバーは、許可されたクォータの有効期間および/または中間尋問の生産を制御しようとする場合があります。したがって、クレジットコントロールクライアントへの回答メッセージに有効時間AVPを含めることができます。有効期間が満了すると、クレジット制御クライアントはクレジット制御更新リクエストを生成し、使用済みクォータをクレジットコントロールサーバーに報告する必要があります。許可されたサービスユニットの消費に使用される有効期間の価値を決定するのは、クレジット制御サーバー次第です。有効期間が使用される場合、セッション監督タイマーTCCを設定するための入力としてその値を指定する必要があります（セッション監督タイマーは、セクション13で定義されているように、有効期間の2倍に設定できます）。クレジットコントロールの更新リクエストは、付与されたサービスユニットの有効期限および/またはセッション中のサービスイベントのためにも作成されるため、有効期間の省略は、クレジット制御の目的で中間尋問が実行されないことを意味しません。
The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. Note that the granted units should be allocated based on the worst-case scenario in case of forthcoming tariff change, so that the overall reported used units would never exceed the credit reservation.
直径クレジットコントロールサーバーとクライアントは、オプションで関税変更メカニズムをサポートする場合があります。直径クレジットコントロールサーバーには、回答メッセージに関税時間変化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.
直径クレジットコントロールクライアントが使用済みユニットと報告期間中に関税の変更が発生した場合、直径のクレジット制御クライアントは、関税の変更の前後に使用されるユニットを個別に項目化する必要があります。料金の変更にまたがるユニットが関税の変更の前または後に使用されたかどうかをクライアントが区別できない場合、クレジット制御クライアントは、3番目のカテゴリでそれらのユニットを項目化する必要があります。
If a client does not support the tariff change mechanism and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit-control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
クライアントが関税変更メカニズムをサポートせず、関税時間変化AVPを運ぶCCAメッセージを受信する場合、クレジット制御セッションを終了し、終了原因AVPでdiameter_bad_answerの理由を与えなければなりません。
For time based services, the quota is continuously consumed at the regular rate of 60 seconds per minute. At the time when credit resources are allocated, the server already knows how many units will be consumed before the tariff time change and how many units will be consumed afterward. Similarly, the server can determine the units consumed at the before rate and the units consumed at the rate afterward in the event that the end-user closes the session before the consumption of the allotted quota. There is no need for additional traffic between client and server in the case of tariff time changes for continuous time based service. Therefore, the tariff change mechanism is not used for such services. For time-based services in which the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used.
時間ベースのサービスの場合、クォータは毎分60秒の通常の速度で継続的に消費されます。クレジットリソースが割り当てられた時点で、サーバーは、関税時間が変更される前に消費されるユニットの数と、その後いくつのユニットが消費されるかをすでに知っています。同様に、サーバーは、エンドユーザーが割り当てられたクォータの消費前にセッションを閉じる場合、その後のレートで消費されたユニットとその後のレートで消費されるユニットを決定できます。継続的な時間ベースのサービスの関税時間の変更の場合、クライアントとサーバーの間に追加のトラフィックは必要ありません。したがって、関税変更メカニズムはそのようなサービスには使用されません。クォータが通常のレートで継続的に消費されない時間ベースのサービスの場合、ボリュームおよびイベントユニットについて説明されている関税変更メカニズムを使用することができます。
When multiple services are used within the same user session and each service or group of services is subject to different cost, it is necessary to perform credit-control for each service independently. Making use of credit-control sub-sessions to achieve independent credit-control will result in increased signaling load and usage of resources in both the credit-control client and the credit-control server. For instance, during one network access session the end user may use several http-services subject to different access cost. The network access specific attributes such as the quality of service (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/Answer messages. It is possible to request and allocate resources as a credit pool shared between multiple services. The services can be grouped into rating groups in order to achieve even further aggregation of credit allocation. It is also possible to request and allocate quotas on a per service basis. Where quotas are allocated to a pool by means of the Multiple-Services-Credit-Control AVP, the quotas remain independent objects that can be re-authorized independently at any time. Quotas can also be given independent result codes, validity times, and Final-Unit-Indications.
これらのシナリオを最適にサポートするために、クレジット制御アプリケーションは、単一のクレジット制御（サブ）セッションで複数のサービスの独立したクレジット制御を可能にします。これは、クレジット制御/回答メッセージにオプションの複数サービスとクレジット制御AVPを含めることによって達成されます。複数のサービス間で共有されるクレジットプールとしてリソースを要求して割り当てることができます。サービスは、信用配分のさらに集約を達成するために、評価グループにグループ化できます。また、サービスごとにクォータを要求して割り当てることもできます。クォータが複数のサービスクレジット制御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-tuple and HTTP URL.) Service-Identifiers enable authorization on a per-service based credit as well as itemized reporting of service usage. It is up to the credit-control server whether to authorize credit for one or more services or for the whole rating-group. However, the client SHOULD always report used units at the finest supported level of granularity. Where quota is allocated to a rating-group, all the services belonging to that group draw from the allotted quota. The following is a graphical representation of the relationship between service-identifiers, rating-groups, credit pools, and credit-control (sub-)session.
格付けグループは、サービスの識別子によって識別され、同じコストと格付けタイプ（たとえば0.1ドル/分）の対象となる一連のサービスを収集します。サービス要素には、この仕様の範囲外の手段で計算するものを定義する評価グループ、サービス識別子、およびそれらの関連するパラメーターが提供されていると想定されています。（サービス識別子に関連付けられたパラメーターの例は、IP 5タプルとHTTP URLです。）サービス識別子は、サービス使用率の項目別レポートと同様に、サービスごとのクレジットで認可を可能にします。1つ以上のサービスのクレジットを承認するか、格付けグループ全体のクレジットを許可するかは、クレジット制御サーバー次第です。ただし、クライアントは常に、使用済みのユニットを最もよくサポートされているレベルの粒度で報告する必要があります。クォータが評価グループに割り当てられている場合、そのグループに属するすべてのサービスが割り当てられたクォータから引き出されます。以下は、サービス識別者、評価グループ、クレジットプール、クレジット制御（サブ）セッションの関係のグラフィカルな表現です。
DCC (Sub-)Session
|
+------------+-----------+-------------+--------------- +
| | | | |
Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z
\ / \ / /
\ / \ / /
\ / Rating-Group 1.......Rating-Group n
\ / | |
Quota ---------------Quota Quota
| / |
| / |
Credit-Pool Credit-Pool
If independent credit-control of multiple services is used, the validity-time and final-unit-indication SHOULD be present either in the Multiple-Services-Credit-Control AVP(s) or at command level as single AVPs. However, the Result-Code AVP MAY be present both on the command level and within the Multiple-Services-Credit-Control AVP. If the Result-Code on the command level indicates a value other than SUCCESS, then the Result-Code on command level takes precedence over any included in the Multiple-Services-Credit-Control AVP.
複数のサービスの独立したクレジット制御が使用される場合、妥当性と最終ユニット誘導は、複数のサービス - クレジット制御AVP（S）に、または単一AVPとしてコマンドレベルで存在する必要があります。ただし、結果コードAVPは、コマンドレベルと複数のサービス - クレジット制御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.
クレジット制御クライアントは、最初の尋問に複数のサービス指示者AVPを含めることにより、（サブ）セッション内の複数のサービスの独立したクレジット制御のサポートを示す必要があります。この機能をサポートしていないクレジット制御サーバーは、複数のサービスインディケーターAVPおよび受信した複数のサービス - クレジット制御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.
クライアントが複数のサービスの独立したクレジット制御のサポートを示した場合、機能を使用したいクレジット制御サーバーは、対応するサービス識別子および/または関連付けられた複数サービス - クレジット制御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.
同じアカウント（つまり、クレジットの断片化）でいくつかの並行（および通常も小さい）クレジット予約を行う必要がある状況を回避し、クレジット制御サーバーの不必要な負荷を回避するために、サービスユニットを提供することが可能です。複数のサービスまたは評価グループに適用されるプール。これは、複数のサービス - クレジット制御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.
リファレンスには、特定のタイプのサービスユニットからプール内の抽象サービスユニットに変換される評価パラメーターから派生した乗数が含まれます。たとえば、Service 1の評価パラメーターが$ 1/MBで、Service 2の評価パラメーターが0.5ドル/MBの場合、乗数はそれぞれサービス1と2の場合は10と5になります。
If S is the total service units within the pool, M1, M2, ..., Mn are the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., Cn are the used resources within the session, then the pool credit is exhausted and re-authorization MUST be sought when:
Sがプール内の総サービスユニットの場合、M1、M2、...、MNはサービス1、2、...、N、およびC1、C2、...、CNが使用済みのリソースに提供される乗数です。セッション内では、プールクレジットが使い果たされ、次の場合の再承認を求める必要があります。
C1*M1 + C2*M2 + ... + Cn*Mn >= S
The total credit in the pool, S, is calculated from the quotas, which are currently allocated to the pool as follows:
プールの合計クレジットは、クォータから計算されます。クォータは、現在プールに割り当てられています。
S = Q1*M1 + Q2*M2 + ... + Qn*Mn
If services or rating groups are added to or removed from the pool, then the total credit is adjusted appropriately. Note that when the total credit is adjusted because services or rating groups are removed from the pool, the value that need to be removed is the consumed one (i.e., Cx*Mx).
サービスまたは格付けグループがプールに追加または削除された場合、合計クレジットは適切に調整されます。サービスまたは格付けグループがプールから削除されるために合計クレジットが調整された場合、削除する必要がある値は消費されたもの（つまり、CX*MX）であることに注意してください。
Re-authorizations for an individual service or rating group may be sought at any time; for example, if a 'non-pooled' quota is used up or the Validity-Time expires.
個々のサービスまたは格付けグループの再承認がいつでも求められる場合があります。たとえば、「非プールされた」クォータが使用されている場合、または有効期間が期限切れになる場合。
Where multiple G-S-U-Pool-Reference AVPs (section 8.30) with the same G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit-Control AVP (section 8.16) along with the Granted-Service-Unit AVP, then these MUST have different CC-Unit-Type values, and they all draw from the credit pool separately. For instance, if one multiplier for time (M1t) and one multiplier for volume (M1v) are given, then the used resources from the pool is the sum C1t*M1t + C1v*M1v, where C1t is the time unit and C1v is the volume unit.
同じG-S-U-Pool-Identifierを備えた複数のG-S-UプールリファレンスAVP（セクション8.30）が、付与されたサービスユニットAVPとともに、複数のサービス - クレジット制御AVP（セクション8.16）内で提供されている場合、これらはこれらが必要だったはずです。さまざまなCCユニットタイプの値があり、それらはすべてクレジットプールから個別に引き出します。たとえば、1つの乗数（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, then these are handled independently from any credit pool and from any other services or rating groups within the session.
対応するG-S-UプールリファレンスAVPなしで複数のサービス - クレジット制御AVP内でサービスユニットが提供されている場合、これらはセッション内のクレジットプールや他のサービスまたは格付けグループから独立して処理されます。
The credit pool concept is an optimal tool to avoid the over-reservation effect of the basic single quota tariff time change mechanism (the mechanism described in section 5.1.1). Therefore, Diameter credit-control clients and servers implementing the independent credit-control of multiple services SHOULD leverage the credit pool concept when supporting the tariff time change. The Diameter credit-control server SHOULD include both the Tariff-Time-Change and Tariff-Change-Usage AVPs in two quota allocations in the answer message (i.e., two instances of the Multiple-Services-Credit-Control AVP). One of the granted units is allocated to be used before the potential tariff change, while the second granted units are for use after a tariff change. Both granted unit quotas MUST contain the same Service-Identifier and/or Rating-Group. This dual quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter credit-control client reports both the used units before and after the tariff change in a single instance of the Multiple-Services-Credit-Control AVP.
クレジットプールの概念は、基本的な単一クォータの関税時間変更メカニズムの過剰保存効果を回避するための最適なツールです（セクション5.1.1で説明されているメカニズム）。したがって、複数のサービスの独立したクレジット制御を実装する直径のクレジット制御クライアントとサーバーは、関税時間の変更をサポートする際にクレジットプールの概念を活用する必要があります。直径クレジットコントロールサーバーには、回答メッセージの2つのクォータ割り当てに関税時間変化と関税チェンジ-USAGE AVPの両方を含める必要があります（つまり、複数のサービス - クレジット制御AVPの2つのインスタンス）。付与されたユニットの1つは、潜在的な関税変更の前に使用されるように割り当てられますが、2番目の付与ユニットは関税の変更後に使用します。付与されたユニットの両方のクォータは、同じサービス識別子および/または定格グループを含める必要があります。このデュアルクォータメカニズムにより、報告されている全体的な中古ユニットがクレジット予約を超えないことが保証されます。Diameter Credit-Controlクライアントは、Multiple-Services-Credit-Control AVPの単一のインスタンスで、関税の変更の前後に使用済みユニットの両方を報告しています。
The failure handling for credit-control sessions is defined in section 5.7 and reflected in the basic credit-control state machine in section 7. Credit-control clients and servers implementing the independent credit-control of multiple services in a (sub-)session functionality MUST ensure failure handling and general behavior fully consistent with the above mentioned sections, while maintaining the ability to handle parallel ongoing credit re-authorization within a (sub-)session. Therefore, it is RECOMMENDED that Diameter credit-control clients maintain a PendingU message queue and restart the Tx timer (section 13) every time a CCR message with the value UPDATE_REQUEST is sent while they are in PendingU state. When answers to all pending messages are received, the state machine moves to OPEN state, and Tx is stopped. Naturally, the action performed when a problem for the session is detected according to section 5.7 affects all the ongoing services (e.g., failover to a backup server if possible affect all the CCR messages with the value UPDATE_REQUEST in the PendingU queue).
クレジット制御セッションの失敗ハンドリングはセクション5.7で定義され、セクション7の基本的なクレジット制御状態マシンに反映されています。上記のセクションと完全に一致する障害処理と一般的な動作を確保する必要がありますが、（サブ）セッション内で並行して進行中のクレジットの再承認を処理する能力を維持する必要があります。したがって、直径クレジットコントロールクライアントは、Pendutimer（セクション13）を維持するメッセージキューを維持し、値更新_requestがPendu Stateの間に送信されるCCRメッセージが送信されるたびに、TXタイマー（セクション13）を再起動することをお勧めします。すべての保留中のメッセージへの回答が受信されると、状態マシンは状態を開くために移動し、TXが停止します。当然のことながら、セクション5.7に従ってセッションの問題が検出されたときに実行されたアクションは、進行中のすべてのサービスに影響を与えます（たとえば、可能であれば、バックアップサーバーへのフェイルオーバーは、Penduneキューの値update_requestを使用してすべてのCCRメッセージに影響します）。
Since the client may send CCR messages with the value UPDATE_REQUEST while in PendingU (i.e., without waiting for an answer to ongoing credit re-authorization), the time space between these requests may be very short, and the server may not have received the previous request(s) yet. Therefore, in this situation the server may receive out of sequence requests and SHOULD NOT consider this an error condition. A proper answer is to be returned to each of those requests.
クライアントは、Penduing（つまり、継続的なクレジットの再承認に対する回答を待つことなく）の間に値update_Requestを使用してCCRメッセージを送信する場合があるため、これらの要求間の時間スペースが非常に短く、サーバーが以前に受信していない場合があります。まだリクエスト。したがって、この状況では、サーバーはシーケンスリクエストを受け取ることができ、これをエラー条件と見なすべきではありません。適切な答えは、それらの各リクエストに返されることです。
When session based credit-control is required (e.g., the authentication server indicated a prepaid user), the first interrogation MUST be sent before the Diameter credit-control client allows any service event to the end user. The CC-Request-Type is set to the value INITIAL_REQUEST in the request message.
セッションベースのクレジットコントロールが必要な場合（例：認証サーバーがプリペイドユーザーを示した場合）、最初の尋問は、直径クレジットコントロールクライアントがエンドユーザーへのサービスイベントを許可する前に送信する必要があります。CC-Request-Typeは、リクエストメッセージの値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 command level. The Service-Context-Id AVP indicates the service specific document applicable to the request.
直径クレジットコントロールクライアントがサービスイベントのコストを知っている場合（例：リンギングトーンを提供するコンテンツサーバーがコストを知っている場合がある場合）、請求される金額は要求されたサービスユニットAVPに含まれています。直径クレジットコントロールクライアントがサービスイベントのコストを知らない場合、要求されたサービスユニットAVPには、要求されたサービスイベントの数が含まれる場合があります。複数のサービス - クレジット制御AVPが使用される場合、関連するサービス/評価グループのクォータが要求されていることを示すために、要求されたサービスユニットAVPを含める必要があります。複数のサービスの場合、複数のサービス - クレジット制御AVP内のサービス識別子AVPまたはレーティンググループ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 SHOULD be included to identify the end user in the credit-control server. The credit-control client MAY include the User-Equipment-Info AVP so that the credit-control server has some indication of the type and capabilities of the end user access device. How the credit-control server uses this information is outside the scope of this document.
イベント - タメスタンプAVPはリクエストに含める必要があり、サービスイベントがサービス要素でリクエストされる時間を含んでいます。サブスクリプションID 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.
クレジット制御サーバーは、サービスイベントを評価し、サービスイベントのコストをカバーするエンドユーザーのアカウントからクレジット保証を作成する必要があります。要求されたサービスユニットAVPのタイプがお金である場合、格付けは必要ありませんが、対応する金額はエンドユーザーのアカウントから予約されています。
The credit-control server returns the Granted-Service-Unit AVP in the Answer message to the Diameter credit-control client. The Granted-Service-Unit AVP contains the amount of service units that the Diameter credit-control client can provide to the end user until a new Credit-Control-Request MUST be sent to the credit-control server. If several unit types are sent in the Answer message, the credit-control client MUST handle each unit type separately. The type of the Granted-Service-Unit AVP can be time, volume, service specific, or money, depending on the type of service event. The unit type(s) SHOULD NOT be changed within an ongoing credit-control session.
クレジットコントロールサーバーは、AnswerメッセージのAVSERD-SERVICE-UNIT AVPをDiameter Credit-Controlクライアントに返します。付与されたサービスユニットAVPには、Diameter Credit-Control-Requestをクレジット制御サーバーに送信する必要があるまで、Diameter Credit-Controlクライアントがエンドユーザーに提供できるサービスユニットの量が含まれています。回答メッセージにいくつかのユニットタイプが送信される場合、クレジット制御クライアントは各ユニットタイプを個別に処理する必要があります。許可されたサービスユニットAVPのタイプは、サービスイベントの種類に応じて、時間、ボリューム、サービス固有の、またはお金です。ユニットタイプは、進行中のクレジット制御セッション内で変更しないでください。
There MUST be a maximum of one instance of the same unit type in one Answer message. However, if multiple quotas are conveyed to the credit-control client in the Multiple-Services-Credit-Control AVPs, it is possible to carry two instances of the same unit type associated to a service-identifier/rating-group. This is typically the case when a tariff time change is expected and the credit-control server wants to make a distinction between the granted quota before and after tariff change.
1つの回答メッセージに同じユニットタイプの最大1つのインスタンスが必要です。ただし、複数のクォータが複数のサービスをクレジットコントロールクライアントに伝えられた場合、複数のサービス - クレジット制御AVPSのクレジットコントロールクライアントに伝えられると、サービス識別子/評価グループに関連付けられた同じユニットタイプの2つのインスタンスを携帯することができます。これは通常、関税時間の変更が予想され、クレジット制御サーバーが関税の変更前後に付与されたクォータを区別したい場合です。
If the credit-control server determines that no further control is needed for the service, it MAY include the result code indicating that the credit-control is not applicable (e.g., if the service is free of charge). This result code at command level implies that the credit-control session is to be terminated.
クレジット制御サーバーがサービスにさらなる制御が必要ないと判断した場合、クレジット制御が適用されないことを示す結果コードが含まれる場合があります（たとえば、サービスが無料である場合）。コマンドレベルでのこの結果コードは、クレジット制御セッションが終了することを意味します。
The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP to indicate that the answer message contains the final 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.
クレジット制御応答メッセージには、回答メッセージにサービスの最終ユニットが含まれていることを示す最終ユニット誘導AVPも含まれている場合があります。エンドユーザーがこれらのユニットを消費した後、セクション5.6で説明されているように、直径のクレジット制御クライアントが動作する必要があります。
This document defines two different approaches to perform the first interrogation to be used in different network architectures. The first approach uses credit-control messages after the user's authorization and authentication takes place. The second approach uses service specific authorization messages to perform the first interrogation during the user's authorization/authentication phase, and credit-control messages for the intermediate and final interrogations. If an implementation of the credit-control client supports both the methods, determining which method to use SHOULD be configurable.
このドキュメントでは、さまざまなネットワークアーキテクチャで使用される最初の尋問を実行する2つの異なるアプローチを定義します。最初のアプローチは、ユーザーの承認と認証が行われた後、クレジット制御メッセージを使用します。2番目のアプローチでは、サービス固有の認証メッセージを使用して、ユーザーの承認/認証フェーズ中に最初の尋問を実行し、中間および最終尋問のクレジット制御メッセージを実行します。クレジット制御クライアントの実装が両方のメソッドをサポートする場合、使用する方法を決定することを決定できます。
In service environments such as the Network Access Server (NAS), it is desired to perform the first interrogation as part of the authorization/authentication process for the sake of protocol efficiency. Further credit authorizations after the first interrogation are performed with credit-control commands defined in this specification. Implementations of credit-control clients operating in the mentioned environments SHOULD support this method. If the credit-control server and AAA server are separate physical entities, the service element sends the request messages to the AAA server, which then issues an appropriate request or proxies the received request forward to the credit-control server.
Network Access Server（NAS）などのサービス環境では、プロトコル効率のために、認証/認証プロセスの一部として最初の尋問を実行することが望まれます。この仕様で定義されたクレジット制御コマンドを使用して、最初の尋問後のさらなるクレジット許可が実行されます。上記の環境で動作するクレジット制御クライアントの実装は、この方法をサポートする必要があります。クレジット制御サーバーとAAAサーバーが個別の物理エンティティである場合、サービス要素はリクエストメッセージをAAAサーバーに送信し、適切な要求を発行するか、受信したリクエストをクレジットコントロールサーバーにプロキシします。
In other service environments, such as the 3GPP network and some SIP scenarios, there is a substantial decoupling between registration/access to the network and the actual service request (i.e., the authentication/authorization is executed once at registration/access to the network and is not executed for every service event requested by the subscriber). In these environments, it is more appropriate to perform the first interrogation after the user has been authenticated and authorized. The first, the intermediate, and the final interrogations are executed with credit-control commands defined in this specification.
3GPPネットワークやいくつかのSIPシナリオなどの他のサービス環境では、ネットワークへの登録/アクセスと実際のサービス要求との間にかなりの分離があります（つまり、認証/認証はネットワークへの登録/アクセス時に1回実行されます。サブスクライバーが要求したすべてのサービスイベントについて実行されません）。これらの環境では、ユーザーが認証され、承認された後、最初の尋問を実行する方が適切です。最初、中間、および最終的な尋問は、この仕様で定義されたクレジット制御コマンドで実行されます。
Other IETF standards or standards developed by other standardization bodies may define the most suitable method in their architectures.
他の標準化機関によって開発された他のIETF標準または標準は、それらのアーキテクチャで最も適切な方法を定義する場合があります。
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.
サービス要素内の直径クレジットコントロールクライアントは、エンドユーザーの知識に基づいて、クレジット制御が必要かどうかについて、認証サーバーから情報を取得できます。クレジット制御が必要な場合、エンドユーザーへのサービス提供を開始する前に、クレジット制御サーバーに連絡する必要があります。会計プロトコルとクレジット制御プロトコルは、並行して使用できます。Authorization Serverは、並列会計ストリームが必要かどうかを判断する場合があります。
The following diagram illustrates the case where both protocols are used in parallel and the service element sends credit-control messages directly to the credit-control server. More credit-control sequence examples are given in Annex A.
次の図は、両方のプロトコルが並行して使用され、サービス要素がクレジット制御メッセージをクレジットコントロールサーバーに直接送信する場合を示しています。より多くのクレジットコントロールシーケンスの例は、付録Aに記載されています。
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Registration | AA request/answer(accounting,cc or both)|
|<----------------->|<------------------>| |
| : | | |
| : | | |
| Service Request | | |
|------------------>| | |
| | CCR(Initial,Credit-Control AVPs) |
| +|---------------------------------------->|
| CC stream|| | CCA(Granted-Units)|
| +|<----------------------------------------|
| Service Delivery | | |
|<----------------->| ACR(start,Accounting AVPs) |
| : |------------------->|+ |
| : | ACA || Accounting stream |
| |<-------------------|+ |
| : | | |
| : | | |
| | CCR(Update,Used-Units) |
| |---------------------------------------->|
| | | CCA(Granted-Units)|
| |<----------------------------------------|
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination, Used-Units) |
| |---------------------------------------->|
| | | CCA |
| |<----------------------------------------|
| | ACR(stop) | |
| |------------------->| |
| | ACA | |
| |<-------------------| |
Figure 2: Protocol example with first interrogation after user's authorization/authentication
図2：ユーザーの承認/認証後の最初の尋問によるプロトコルの例
The Diameter credit-control client in the service element MUST actively co-operate with the authorization/authentication client in the construction of the AA request by adding appropriate credit-control AVPs. The credit-control client MUST add the Credit-Control AVP to indicate credit-control capabilities and MAY add other relevant credit-control specific AVPs to the proper authorization/authentication command to perform the first interrogation toward the home Diameter AAA server. The Auth-Application-Id is set to the appropriate value, as defined in the relevant service specific authorization/authentication application document (e.g., [NASREQ], [DIAMMIP]). The home Diameter AAA server authenticates/authorizes the subscriber and determines whether credit-control is required.
サービス要素の直径クレジットコントロールクライアントは、適切なクレジット制御AVPを追加することにより、AA要求の構築において、承認/認証クライアントと積極的に協力する必要があります。クレジット制御クライアントは、クレジットコントロールAVPを追加してクレジット制御機能を示す必要があり、他の関連するクレジット制御固有のAVPを適切な承認/認証コマンドに追加して、ホーム直径AAAサーバーに向けた最初の尋問を実行することができます。Auth-Application-IDは、関連するサービス固有の承認/認証アプリケーションドキュメント（[Nasreq]、[diammip]）で定義されているように、適切な値に設定されます。ホームの直径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.
サブスクライバーにクレジット制御が必要ない場合、適切なAA回答メッセージを使用して、通常どおりAAAサーバーの直径が応答します。サブスクライバーにクレジット制御が必要であり、クレジット_Authorizationに設定された値を備えたクレジット制御AVPが承認要求に存在する場合、ホームAAAサーバーはクレジット制御サーバーに連絡して最初の尋問を実行する必要があります。サブスクライバーにクレジット制御が必要であり、クレジット制御AVPが承認要求に存在しなかった場合、Home AAAサーバーは承認拒否の回答メッセージを送信する必要があります。
The Diameter AAA server supporting credit-control is required to send the Credit-Control-Request command (CCR) defined in this document to the credit-control server. The Diameter AAA server populates the CCR based on service specific AVPs used for input to the rating process, and possibly on credit-control AVPs received in the AA request. The credit-control server will reserve money from the user's account, will rate the request and will send a Credit-Control-Answer message to the home Diameter AAA server. The answer message includes the Granted-Service-Unit AVP(s) and MAY include other credit-control specific AVPs, as appropriate. Additionally, the credit-control server MAY set the Validity-Time and MAY include the Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP to determine what to do if the sending of credit-control messages to the credit-control server has been temporarily prevented.
このドキュメントで定義されているクレジット制御コマンド（CCR）をクレジットコントロールサーバーに送信するには、クレジット制御をサポートする直径AAAサーバーが必要です。直径AAAサーバーは、評価プロセスへの入力に使用されるサービス固有のAVP、およびAA要求で受信したクレジット制御AVPに基づいてCCRに浸透します。クレジットコントロールサーバーは、ユーザーのアカウントからお金を予約し、リクエストを評価し、クレジットコントロール回答メッセージをホームダイアムAAAサーバーに送信します。回答メッセージには、付与されたサービスユニットAVPが含まれており、必要に応じて他のクレジット制御固有のAVPが含まれる場合があります。さらに、クレジット制御サーバーは有効時刻を設定する場合があり、クレジット制御対策AVPと直接委任対策対処AVPを含めることができ、クレジット制御メッセージの送信がどうするかを判断するためにクレジット制御サーバーは一時的に防止されています。
Upon receiving the Credit-Control-Answer message from the credit-control server, the home Diameter AAA server will populate the AA answer with the received credit-control AVPs and with the appropriate service attributes according to the authorization/authentication specific application (e.g., [NASREQ], [DIAMMIP]). It will then forward the packet to the credit-control client. If the home Diameter AAA server receives a credit-control reject message, it will simply generate an appropriate authorization reject message to the credit-control client, including the credit-control specific error code.
クレジット制御サーバーからクレジット制御応答メッセージを受信すると、ホームの直径AAAサーバーは、受信したクレジット制御AVPと、認可/認証固有のアプリケーションに従って適切なサービス属性（例えば、[nasreq]、[diammip]）。その後、パケットをクレジット制御クライアントに転送します。ホームの直径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, as required by using credit-control commands. The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 (for how to produce unique value for the CC-Request-Number AVP, see section 8.2).
このモデルでは、クレジット制御クライアントは、ホームダイアムAAAサーバーを介して、クレジットコントロールメッセージをクレジットコントロールサーバーに送信します。許可された承認回答メッセージを許可されたAVPで成功した承認回答メッセージを受信すると、クレジットコントロールクライアントはエンドユーザーにサービスを許可し、クレジット制御コマンドを使用することで要求される中間クレジットコントロールリクエストを生成します。。最初のupdate_requestのCC-Request-Numberは1に設定する必要があります（CC-Request-Number AVPの一意の値を作成する方法については、セクション8.2を参照）。
If service specific re-authorization is performed (i.e., authorization-lifetime expires), the credit-control client MUST add to the service specific re-authorization request the Credit-Control AVP with a value set to RE_AUTHORIZATION to indicate that the credit-control server MUST NOT be contacted. When session based credit-control is used for the subscriber, a constant credit-control message stream flows through the home Diameter AAA server. The home Diameter AAA server can make use of this credit-control message flow to deduce that the user's activity is ongoing; therefore, it is recommended to set the authorization-lifetime to a reasonably high value when credit-control is used for the subscriber.
サービス固有の再承認が実行された場合（つまり、承認系統の期限が切れる）、クレジット制御クライアントは、クレジット制御を示すためにRE_Authorizationに設定された値を持つクレジットコントロールAVPをサービス固有の再承認要求に追加する必要があります。サーバーに連絡する必要はありません。セッションベースのクレジットコントロールがサブスクライバーに使用される場合、一定のクレジットコントロールメッセージストリームがホーム直径AAAサーバーに流れます。ホームの直径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.
このシナリオでは、ホームの直径AAAサーバーは、機能交換プロセス中に同業他社へのクレジット制御アプリケーションのサポートを宣伝する必要があります。
The following diagram illustrates the use of authorization/authentication messages to perform the first interrogation. The parallel accounting stream is not shown in the figure.
次の図は、最初の尋問を実行するための承認/認証メッセージの使用を示しています。平行な会計ストリームは図には示されていません。
Service Element Diameter
End User (CC Client) AAA Server CC Server
| Service Request | AA Request (CC AVPs) |
|------------------>|------------------->| |
| | | CCR(Initial, CC AVPs)
| | |------------------->|
| | | CCA(Granted-Units)
| | |<-------------------|
| | AA Answer(Granted-Units) |
| Service Delivery |<-------------------| |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update,Used-Units) |
| |------------------->| CCR(Update,Used-Units)
| | |------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------|
| |<-------------------| |
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination,Used-Units) |
| |------------------->| CCR(Term.,Used-Units)
| | |------------------->|
| | | CCA |
| | CCA |<-------------------|
| |<-------------------| |
Figure 3: Protocol example with use of the authorization messages for the first interrogation
図3：最初の尋問に承認メッセージを使用したプロトコルの例
When all the granted service units for one unit type are spent by the end user or the Validity-Time is expired, the Diameter credit-control client MUST send a new Credit-Control-Request to the credit-control server. In the event that credit-control for multiple services is applied in one credit-control session (i.e., units associated to Service-Identifier(s) or Rating-Group are granted), a new Credit-Control-Request MUST be sent to the credit-control server when the 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つのユニットタイプの付与されたすべてのサービスユニットがエンドユーザーによって使用される場合、または有効期間が期限切れになった場合、直径のクレジット制御クライアントは、クレジット制御サーバーに新しいクレジット制御要求を送信する必要があります。複数のサービスのクレジット制御が1つのクレジット制御セッションで適用された場合（すなわち、サービス識別子または格付けグループに関連するユニットが付与されます）、新しいクレジット制御要求を送信する必要があります。クレジットコントロールサーバークレジット予約が完全に消費された場合、または有効期間の満了時に。サービス要素の中断を避けるために、以前のリクエストの有効期限のかなり前に新しいリクエストを送信するのは、常に直径クレジットコントロールクライアント次第です。クレジットコントロールサーバーによって予約された付与されたサービスユニットが有効期間の満了時に費やされていない場合でも、Diameter Credit-Controlクライアントは、クレジット制御サーバーに新しいクレジット制御要求を送信する必要があります。
There can also be mid-session service events, which might affect the rating of the current service events. In this case, a spontaneous updating (a new Credit-Control-Request) SHOULD be sent including information related to the service event even if all the granted service units have not been spent or the Validity-Time has not expired.
また、セッション中のサービスイベントがあり、現在のサービスイベントの評価に影響を与える可能性があります。この場合、すべての付与されたサービスユニットが費やされていなくても、有効期限が切れていない場合でも、サービスイベントに関連する情報を含む、自発的な更新（新しいクレジット制御要求）を送信する必要があります。
When the used units are reported to the credit-control server, the credit-control client will not have any units in its possession before new granted units are received from the credit-control server. When the new granted units are received, these units apply from the point where the measurement of the reported used units stopped. Where independent credit-control of multiple services is supported, this process may be executed for one or more services, a single rating-group, or a pool within the (sub)session.
使用済みユニットがクレジットコントロールサーバーに報告されると、クレジットコントロールクライアントは、クレジットコントロールサーバーから新しい付与ユニットが受信される前に、その所有権を所有していません。新しい付与ユニットを受信すると、これらのユニットは、報告されている中古ユニットの測定が停止するポイントから適用されます。複数のサービスの独立した信用制御がサポートされている場合、このプロセスは、1つ以上のサービス、単一の評価グループ、または（サブ）セッション内のプールで実行される場合があります。
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message. The Subscription-Id AVP SHOULD be included in the intermediate message to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service specific document applicable to the request.
CC-Request-Type AVPは、中間要求メッセージの値update_requestに設定されています。サブスクリプションID AVPは、クレジット制御サーバーでエンドユーザーを識別するための中間メッセージに含める必要があります。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.
要求されたサービスユニットAVPには、新しい量の要求されたサービスユニットが含まれる場合があります。複数のサービス - クレジット制御AVPが使用される場合、関連するサービス/評価グループの新しいクォータが要求されている場合、要求されたサービスユニットAVPを含める必要があります。中古サービスユニットAVPには、サービスがアクティブになった時点から、またはセッション中に暫定的な尋問が使用されている場合、前の測定が終了したポイントから測定された使用済みサービスユニットの量が含まれています。前のメッセージで使用した同じユニットタイプを使用する必要があります。以前の回答メッセージにいくつかのユニットタイプが含まれている場合、各ユニットタイプの使用済みサービスユニットを報告する必要があります。
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.
イベント - タメスタンプAVPはリクエストに含める必要があり、新しいクレジット制御の送信をトリガーしたイベントの時間が含まれています。
The credit-control server MUST deduct the used amount from the end user's account. It MAY rate the new request and make a new credit-reservation from the end user's account that covers the cost of the requested service event.
クレジット制御サーバーは、エンドユーザーのアカウントから使用額を差し引く必要があります。新しいリクエストを評価し、要求されたサービスイベントのコストをカバーするエンドユーザーのアカウントから新しい信用保証を作成する場合があります。
A Credit-Control-Answer message with the CC-Request-Type AVP set to the value UPDATE_REQUEST MAY include the Cost-Information AVP containing the accumulated cost estimation for the session, without taking any credit-reservation into account.
CC-Request-Type AVPを値に設定したCC-Request-Type AVPを使用したクレジット制御応答メッセージには、信用保証を考慮せずに、セッションの累積コストの見積もりを含むコスト情報AVPが含まれる場合があります。
The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP to indicate that the answer message contains the final units for the service. After the end user has consumed these units, the Diameter credit-control-client MUST behave as described in section 5.6.
クレジット制御応答メッセージには、回答メッセージにサービスの最終ユニットが含まれていることを示す最終ユニット誘導AVPも含まれている場合があります。エンドユーザーがこれらのユニットを消費した後、セクション5.6で説明されているように、直径のクレジット制御クライアントが動作する必要があります。
There can be several intermediate interrogations within a session.
セッション内にいくつかの中間尋問があります。
When the end user terminates the service session, or when the graceful service termination described in section 5.6 takes place, the Diameter credit-control client MUST send a final Credit-Control-Request message to the credit-control server. The CC-Request-Type AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP indicates the service specific document applicable to the request.
エンドユーザーがサービスセッションを終了する場合、またはセクション5.6で説明されている優雅なサービス終了が行われたとき、Diameter Credit-Controlクライアントは、クレジット制御サーバーに最終的なクレジット制御要求メッセージを送信する必要があります。CC-Request-Type AVPは、Value 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.
イベント - タメスタンプAVPはリクエストに含まれ、セッションが終了した時間を含む必要があります。
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.
中古サービスユニットAVPには、サービスがアクティブになった時点から、またはセッション中に暫定的な尋問が使用されている場合、前の測定が終了したポイントから測定された使用済みサービスユニットの量が含まれています。以前の回答メッセージにいくつかのユニットタイプが含まれている場合、各ユニットタイプの使用済みサービスユニットを報告する必要があります。
After final interrogation, the credit-control server MUST refund the reserved credit amount not used to the end user's account and deduct the used monetary amount from the end user's account.
最終的な尋問の後、クレジット制御サーバーは、エンドユーザーのアカウントに使用されていない予約されたクレジット額を返金し、エンドユーザーのアカウントから使用済みの金額を差し引く必要があります。
A Credit-Control-Answer message with the CC-Request-Type set to the value TERMINATION_REQUEST MAY include the Cost-Information AVP containing the estimated total cost for the session in question.
Value Termination_Requestに設定されたCC-Request-Typeを使用したクレジット制御応答メッセージには、問題のセッションの推定総コストを含むコスト情報AVPが含まれる場合があります。
If the user logs off during an ongoing credit-control session, or if some other reason causes the user to become logged off (e.g., final- unit indication causes user logoff according to local policy), the service element, according to application specific policy, may send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [DIAMBASE]. Figure 4 illustrates the case when the final-unit indication causes user logoff upon consumption of the final granted units and the generation of STR.
継続的なクレジット制御セッション中にユーザーがログオフする場合、または他の理由でユーザーがログオフされる場合（例えば、最終ユニットの表示はローカルポリシーに従ってユーザーのログオフを引き起こします）、アプリケーション固有のポリシーに従ってサービス要素、通常どおり[Diambase]のように、セッション終端-Request（STR）を家庭の直径AAAサーバーに送信する場合があります。図4は、最終ユニットの表示が最終付与ユニットの消費とSTRの生成時にユーザーのログオフを引き起こす場合を示しています。
Service Element AAA Server CC Server
End User (CC Client)
| Service Delivery | | |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update,Used-Units) |
| |------------------->| CCR(Update,Used-Units)
| | |------------------->|
| | CCA(Final-Unit, Terminate)
| CCA(Final-Unit, Terminate)|<-------------------|
| |<-------------------| |
| : | | |
| : | | |
| Disconnect user | | |
|<------------------| CCR(Termination,Used-Units) |
| |------------------->| CCR(Term.,Used-Units)
| | |------------------->|
| | | CCA |
| | CCA |<-------------------|
| |<-------------------| |
| | STR | |
| |------------------->| |
| | STA | |
| |<-------------------| |
Figure 4: User disconnected due to exhausted account
図4：使い果たされたアカウントのためにユーザーが切断されました
The Diameter credit-control application supports server-initiated re-authorization. The credit-control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in the RAR message is set to 4 to indicate Diameter Credit Control, and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY.
直径クレジットコントロールアプリケーションは、サーバーによって開始された再承認をサポートします。クレジットコントロールサーバーは、直径ベースプロトコル[Diambase]で定義されているように、再承認（RAR）を発行することにより、オプションでクレジットの再承認を開始する場合があります。RARメッセージのauth-application-idは、直径クレジットコントロールを示すために4に設定されており、Reauth-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プール識別子AVPを含めます。サービスまたは格付けグループのクレジットの再承認を要求するために、サーバーはそれぞれRARメッセージにサービス-Identifier AVPまたは格付けグループAVPを含めます。（サブ）セッション内のすべての進行中のサービスのクレジットの再承認を要求するために、サーバーには上記のAVPがRARメッセージに含まれていません。
If a credit re-authorization is not already ongoing (i.e., the credit-control session is in Open state), a credit control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending the Re-Auth-Answer (RAA) message and MUST initiate the credit re-authorization toward the server by sending a Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with the value UPDATE_REQUEST) is required to complete the procedure. If a quota was allocated to the service, the credit-control client MUST report the used quota in the Credit-Control-Request. Note that the end user does not need to be prompted for the credit re-authorization, since the credit re-authorization is transparent to the user (i.e., it takes place exclusively between the credit-control client and the credit-control server).
クレジットの再承認がまだ進行中でない場合（つまり、クレジット制御セッションがオープンステートにあります）、セッションIDで現在アクティブなクレジット制御セッションに等しいRARメッセージを受信するクレジットコントロールクライアントは、リクエストを確認する必要がありますReauth-Answer（RAA）メッセージを送信し、CC-Request-Type AVPセットをValue update_Requestにセットしてクレジット制御メッセージを送信することにより、サーバーに対するクレジットの再承認を開始する必要があります。Rase-Code 2002（diameter_limited_success）をRAAメッセージで使用して、手順を完了するには追加のメッセージ（つまり、値update_Requestを使用したCCRメッセージ）が必要であることを示す必要があります。クォータがサービスに割り当てられた場合、クレジット制御クライアントは、クレジット制御のリクエストで使用されたクォータを報告する必要があります。クレジットの再承認はユーザーに対して透明であるため、エンドユーザーはクレジットの再承認を求める必要はないことに注意してください（つまり、クレジット制御クライアントとクレジット制御サーバーの間でのみ行われます）。
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., 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 Re-Auth-Answer message.
RARメッセージが受信された時点でクレジットの再承認が進行している場合（つまり、RAR-CCR衝突）、クレジット制御クライアントはリクエストを正常に認めますが、新しいクレジットの再承認を開始しません。Rase-Code 2001（diameter_success）をRAAメッセージで使用して、クレジットの再承認手順が既に進行中であることを示す必要があります（つまり、RARが受信されたときにクライアントがPendu状態にあった）。クレジット制御サーバーは、サーバーが開始されたクレジットの再承認に応じて受信されたかのようにクレジット制御を処理する必要があり、再発生を受信するとサーバーが開始されたクレジットの再承認プロセスが成功したことを考慮する必要がありますメッセージ。
When multiple services are supported in a user's session, the server may request credit re-authorization for a credit pool (or for the (sub-)session) while a credit re-authorization is already ongoing for some of the services or rating-groups. In this case, the client acknowledges the server request with an RAA message and MUST send a new Credit-Control-Request message to perform re-authorization for the remaining services/rating-groups. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with value UPDATE_REQUEST) is required to complete the procedure. The server processes the received requests and returns an appropriate answer to both requests.
ユーザーのセッションで複数のサービスがサポートされている場合、サーバーはクレジットプール（または（またはサブ）セッションのためにクレジットの再承認を要求することができますが、クレジットの再承認は、一部のサービスまたは格付けグループですでに進行中です。この場合、クライアントはRAAメッセージを使用してサーバー要求を確認し、残りのサービス/評価グループの再承認を実行するために新しいクレジット制御要求メッセージを送信する必要があります。Rase-Code 2002（diameter_limited_success）をRAAメッセージで使用して、手順を完了するには追加のメッセージ（つまり、値update_requestを使用したCCRメッセージ）が必要であることを示す必要があります。サーバーは、受信した要求を処理し、両方のリクエストに適切な回答を返します。
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.
上記の手順は、おそらくアクティブな直径のクレジットコントロールサブセッションのそれぞれに対して有効になります。サーバーは、セッションID AVPに加えて、CC-Sub-Session-ID AVPをRARメッセージに含めることにより、アクティブなサブセッションの再承認を要求する場合があります。
When the user's account runs out of money, the user may not be allowed to compile additional chargeable events. However, the home service provider may offer some services; for instance, access to a service portal where it is possible to refill the account, for which the user is allowed to benefit for a limited time. The length of this time is usually dependent on the home service provider policy.
ユーザーのアカウントがお金がなくなった場合、ユーザーは追加の課税可能なイベントをコンパイルすることを許可されない場合があります。ただし、ホームサービスプロバイダーは一部のサービスを提供する場合があります。たとえば、ユーザーが限られた時間の利益を許可されているアカウントを補充することができるサービスポータルへのアクセス。この時間の長さは通常、ホームサービスプロバイダーポリシーに依存します。
This section defines the optional graceful service termination feature that MAY be supported by the credit-control server. Credit-control client implementations MUST support the Final-Unit-Indication with at least the teardown of the ongoing service session once the subscriber has consumed all the final granted units.
このセクションでは、クレジット制御サーバーによってサポートされる可能性のあるオプションの優雅なサービス終了機能を定義します。クレジット制御クライアントの実装は、サブスクライバーがすべての最終許可ユニットを消費した後、少なくとも進行中のサービスセッションの断倒を伴う最終ユニットの指定をサポートする必要があります。
Where independent credit-control of multiple services in a single credit-control (sub-)session is supported, it is possible to use the graceful service termination for each of the services/rating-groups independently. Naturally, the graceful service termination process defined in the following sub-sections will apply to the specific service/rating-group as requested by the server.
単一のクレジット制御（サブ）セッションで複数のサービスの独立したクレジット制御がサポートされている場合、各サービス/格付けグループの優雅なサービス終了を個別に使用することができます。当然のことながら、次のサブセクションで定義されている優雅なサービス終了プロセスは、サーバーが要求する特定のサービス/評価グループに適用されます。
In some service environments (e.g., NAS), the graceful service termination may be used to redirect the subscriber to a service portal for online balance refill or other services offered by the home service provider. In this case, the graceful termination process installs a set of packet filters to restrict the user's access capability only to/from the specified destinations. All the IP packets not matching the filters will be dropped or, possibly, re-directed to the service portal. The user may also be sent an appropriate notification as to why the access has been limited. These actions may be communicated explicitly from the server to the client or may be configured per-service at the client. Explicitly signaled redirect or restrict instructions always take precedence over configured ones.
一部のサービス環境（NASなど）では、優雅なサービス終了を使用して、サブスクライバーをオンラインバランスリフィルまたはホームサービスプロバイダーが提供するその他のサービスのサービスポータルにリダイレクトできます。この場合、優雅な終端プロセスは、指定された宛先とのみとのみでユーザーのアクセス機能を制限するために、パケットフィルターのセットをインストールします。フィルターを一致させないすべてのIPパケットは、サービスポータルにドロップされるか、場合によってはリダイレクトされます。また、ユーザーは、アクセスが制限された理由について適切な通知を送信することもできます。これらのアクションは、サーバーからクライアントに明示的に伝達されるか、クライアントでサービスごとに構成されている場合があります。明示的に合図されたリダイレクトまたは制限命令は、構成されたものよりも常に優先されます。
It is also possible use the graceful service termination to connect the prepaid user to a top-up server that plays an announcement and prompts the user to replenish the account. In this case, the credit-control server sends only the address of the top-up server where the prepaid user shall be connected after the final granted units have been consumed. An example of this is given in Appendix A (Flow VII).
また、優雅なサービス終了を使用して、プリペイドユーザーをアナウンスを再生し、ユーザーにアカウントを補充するように促すトップアップサーバーに接続する可能性があります。この場合、クレジットコントロールサーバーは、最終許可ユニットが消費された後にプリペイドユーザーが接続されるトップアップサーバーのアドレスのみを送信します。この例は、付録A（フローVII）に示されています。
The credit-control server MAY initiate the graceful service termination by including the Final-Unit-Indication AVP in the Credit-Control-Answer to indicate that the message contains the final units for the service.
クレジット制御サーバーは、最終ユニット誘導AVPをクレジット制御に含めることにより、メッセージにサービスの最終ユニットが含まれていることを示すことにより、優雅なサービス終了を開始する場合があります。
When the credit-control client receives the Final-Unit-Indication AVP in the answer from the server, its behavior depends on the value indicated in the Final-Unit-Action AVP. The server may request the following actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS.
クレジットコントロールクライアントがサーバーからの回答で最終ユニット誘導AVPを受信すると、その動作は最終ユニットアクションAVPに示されている値に依存します。サーバーは、次のアクションを要求できます。
A following figure illustrates the graceful service termination procedure described in the following sub-sections.
次の図は、次のサブセクションで説明されている優雅なサービス終了手順を示しています。
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Delivery | | |
|<----------------->| | |
| |CCR(Update,Used-Units) |
| |------------------->|CCR(Update,Used-Units)
| : | |------------------->|
| : | |CCA(Final-Unit,Action)
| : | |<-------------------|
| |CCA(Final-Unit,Action) |
| |<-------------------| |
| | | |
| : | | |
| : | | |
| : | | |
| /////////////// |CCR(Update,Used-Units) |
|/Final Units End/->|------------------->|CCR(Update,Used-Units)
|/Action and // | |------------------->|
|/Restrictions // | | CCA(Validity-Time)|
|/Start // | CCA(Validity-Time)|<-------------------|
| ///////////// |<-------------------| |
| : | | |
| : | | |
| Replenish Account +-------+ |
|<-------------------------------------------->|Account| |
| | | +-------+ |
| | | RAR |
| + | RAR |<===================|
| | |<===================| |
| | | RAA | |
| ///////////// | |===================>| RAA |
| /If supported / | | CCR(Update) |===================>|
| /by CC Server/ | |===================>| CCR(Update) |
| ///////////// | | |===================>|
| | | | CCA(Granted-Unit)|
| | | CCA(Granted-Unit)|<===================|
| Restrictions ->+ |<===================| |
| removed | | |
| : | | |
| OR | CCR(Update) | |
| Validity-Time ->|------------------->| CCR(Update) |
| expires | |------------------->|
| | | CCA(Granted-Unit)|
| | CCA(Granted-Unit)|<-------------------|
| Restrictions ->|<-------------------| |
| removed | | |
Figure 5: Optional graceful service termination procedure
図5：オプションの優雅なサービス終了手順
The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does not include any other information. When the subscriber has consumed the final granted units, the service element MUST terminate the service. This is the default handling applicable whenever the credit-control client receives an unsupported Final-Unit-Action value and MUST be supported by all the Diameter credit-control client implementations conforming to this specification. A final Credit-Control-Request message to the credit-control server MUST be sent if the Final-Unit-Indication AVP indicating action TERMINATE was present at command level. The CC-Request-Type AVP in the request is set to the value TERMINATION_REQUEST.
最終ユニットアクション終了を伴う最終ユニット誘導AVPには、他の情報は含まれません。サブスクライバーが最終付与ユニットを消費した場合、サービス要素はサービスを終了する必要があります。これは、クレジットコントロールクライアントがサポートされていない最終ユニットアクション値を受信した場合はいつでも適用されるデフォルトの処理であり、この仕様に準拠したすべての直径クレジットコントロールクライアントの実装によってサポートされる必要があります。クレジットコントロールサーバーへの最終的なクレジット制御要求メッセージは、最終的なユニット指示AVPが終了することを示すAVPがコマンドレベルで存在する場合、送信する必要があります。リクエストのCC-Request-Type AVPは、Value Termination_Requestに設定されています。
The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT indicates to the service element supporting this action that, upon consumption of the final granted units, the user MUST be re-directed to the address specified in the Redirect-Server AVP as follows.
ファイナルユニットアクションリダイレクトを使用した最終ユニット誘導AVPは、このアクションをサポートするサービス要素に、最終付与ユニットの消費時に、ユーザーはリダイレクトサーバーAVPで指定されたアドレスに再監督する必要があることを示しています。続きます。
The credit-control server sends the Redirect-Server AVP in the Credit-Control-Answer message. In such a case, the service element MUST redirect or connect the user to the destination specified in the Redirect-Server AVP, if possible. When the end user is redirected (by using protocols others than Diameter) to the specified server or connected to the top-up server, an additional authorization (and possibly authentication) may be needed before the subscriber can replenish the account; however, this is out of the scope of this specification.
クレジットコントロールサーバーは、クレジット制御応答メッセージにリダイレクトサーバーAVPを送信します。このような場合、サービス要素は、可能であれば、リダイレクトサーバーAVPで指定された宛先にユーザーをリダイレクトまたは接続する必要があります。エンドユーザーが指定されたサーバーに（直径以外のプロトコルを使用することにより）またはトップアップサーバーに接続される場合、サブスクライバーがアカウントを補充する前に追加の承認（およびおそらく認証）が必要になる場合があります。ただし、これはこの仕様の範囲外です。
In addition to the Redirect-Server AVP, the credit-control server MAY include one or more Restriction-Filter-Rule AVPs or one or more Filter-Id AVPs in the Credit-Control-Answer message to enable the user to access other services (for example, zero-rated services). In such a case, the access device MUST drop all the packets not matching the IP filters specified in the Credit-Control-Answer message and, if possible, redirect the user to the destination specified in the Redirect-Server AVP.
リダイレクトサーバーAVPに加えて、クレジットコントロールサーバーには、クレジット制御応答メッセージに1つ以上の制限フィルタールールAVPまたは1つ以上のフィルターID AVPが含まれる場合があります。たとえば、ゼロ定格サービス）。このような場合、アクセスデバイスは、クレジット制御応答メッセージで指定されたIPフィルターと一致しないすべてのパケットをドロップし、可能であれば、リダイレクトサーバー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.
クレジットコントロールサーバー以外のエンティティは、Accessデバイスに、Diameter Credit-Controlアプリケーションと組み合わせて使用する適切な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 expires or upon mid-session service events that affect the rating of the current service. Therefore, the credit-control client MUST NOT include any rating related AVP in the request sent once all the final granted units have been consumed as an indication to the server that the requested final unit action started, rating and money reservation are not required (when the Multiple-Services-Credit-Control AVP is used, the Service-Identifier or Rating-Group AVPs is included to indicate the concerned services). Naturally, the Credit-Control-Answer message does not contain any granted service unit and MUST include the Validity-Time AVP to indicate to the credit-control client how long the subscriber is allowed to use network resources before a new intermediate interrogation is sent to the server.
最終的な付与ユニットが消費された場合、クレジット制御クライアントは中間尋問を実行する必要があります。この尋問の目的は、指定されたアクションが開始されたことをクレジット制御サーバーに示すことであり、使用済みユニットを報告することです。クレジット制御サーバーは、エンドユーザーのアカウントから使用額を差し引く必要がありますが、新しいクレジット予約をしてはなりません。ただし、クレジット制御クライアントは、すべての最終付与ユニットが消費される前に、格付けと金銭の予約が必要になる前に、中間尋問を送信する場合があります。たとえば、有効期間時には、または現在のサービスの評価に影響するセッション中間サービスイベントが期限切れになります。したがって、クレジット制御クライアントは、要求された最終ユニットアクションが開始されるサーバーへのすべての最終許可ユニットが消費された後、リクエストに送信されたリクエストに格付け関連のAVPを含めるべきではありません。複数のサービス - クレジット制御AVPが使用され、サービスを示すサービスを示すために、サービス - Identifierまたは評価グループAVPが含まれています）。当然のことながら、クレジット制御応答メッセージには付与されたサービスユニットが含まれておらず、クレジットコントロールクライアントに、サブスクライバーが新しい中間尋問が送信される前にサブスクライバーがネットワークリソースを使用できる期間を示すために有効期間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 his/her account, whether he/she will be disconnected or will be granted access to services not controlled by a credit-control server for an unlimited time is dependent on the home service provider policy (note: the latter option implies that the service element should not remove the restriction filters upon termination of the credit-control). The server will return the appropriate Result-Code (see section 9.1) in the Credit-Control-Answer message in order to implement the policy-defined action. Otherwise, new quota will be returned, the service element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit-control session and service session as usual.
有効期間の満了時に、クレジット制御クライアントは、通常どおりクレジット制御（update_request）を送信します。このメッセージには、報告する割り当てされた割り当てがないため、使用済みのサービスユニットAVPは含まれていません。クレジット制御サーバーはリクエストを処理し、クレジット予約を実行する必要があります。この期間中にサブスクライバーがアカウントを補充しなかった場合、彼/彼女が切断されるか、無制限の時間のためにクレジット制御サーバーによって制御されていないサービスへのアクセスが許可されます。：後者のオプションは、サービス要素がクレジット制御の終了時に制限フィルターを削除しないことを意味します）。サーバーは、ポリシー定義のアクションを実装するために、適切な結果コード（セクション9.1を参照）をクレジット制御応答メッセージに返します。それ以外の場合、新しいクォータが返されます。サービス要素は、優雅なサービス終了プロセスによってアクティブ化されたすべての可能な制限を削除し、通常どおりクレジット制御セッションとサービスセッションを継続する必要があります。
The credit-control client may not wait until the expiration of the Validity-Time and may send a spontaneous update (a new Credit-Control-Request) if the service element can determine, for instance, that communication between the end user and the top-up server took place. An example of this is given in Appendix A (Figure A.8).
クレジット制御クライアントは、有効時刻の有効期限まで待つことができず、たとえばサービス要素がエンドユーザーとトップの間の通信を決定できる場合、自発的な更新（新しいクレジットコントロール要求）を送信する場合があります。-upサーバーが行われました。この例は、付録A（図A.8）に示されています。
Note that the credit-control server may already have initiated the above-described process for the first interrogation. However, the user's account might be empty when this first interrogation is performed. In this case, the subscriber can be offered a chance to replenish the account and continue the service. The credit-control client receives a Credit-Control-Answer or service specific authorization answer with the Final-Unit-Indication and Validity-Time AVPs but no Granted-Service-Unit. It immediately starts the graceful service termination without sending any message to the server. An example of this case is illustrated in Appendix A.
クレジット制御サーバーは、最初の尋問のために上記のプロセスをすでに開始している可能性があることに注意してください。ただし、この最初の尋問が実行されると、ユーザーのアカウントが空になる可能性があります。この場合、サブスクライバーはアカウントを補充してサービスを継続する機会を提供できます。クレジット制御クライアントは、最終ユニットの指定および有効期間AVPを使用して、クレジットコントロール回答またはサービス固有の認可回答を受け取りますが、許可されたサービスユニットはありません。サーバーにメッセージを送信することなく、すぐに優雅なサービス終了を開始します。このケースの例は、付録Aに示されています。
A Final-Unit-Indication AVP with the Final-Unit-Action RESTRICT_ACCESS indicates to the device supporting this action that the user's access MUST be restricted according to the IP packet filters given in the Restriction-Filter-Rule AVP(s) or according to the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Restriction-Filter-Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message.
ファイナルユニットアクション制限_Accessを使用した最終ユニット誘導AVPは、このアクションをサポートするデバイスに、制限-Filter-Rule AVP（s）で与えられたIPパケットフィルターに従って、またはそれに従って、ユーザーのアクセスを制限する必要があることをデバイスに示します。Filter-ID AVPによって識別されたIPパケットフィルター。クレジット制御サーバーには、クレジット制御応答メッセージに制限フィルタールールAVPまたはフィルターID AVPを含める必要があります。
An entity other than the credit-control server may provision the access device with appropriate IP packet filters to be used in conjunction with the Diameter credit-control application. Such an entity may, for instance, configure the access device with IP flows to be passed when the Diameter credit-control application indicates RESTRICT_ACCESS or REDIRECT. The access device passes IP packets according to the filter rules that may have been received in the Credit-Control-Answer message in addition to those that may have been configured by the other entity. However, when the user's account cannot cover the cost of the requested service, the action taken is the responsibility of the credit-control server that controls the prepaid subscriber.
クレジットコントロールサーバー以外のエンティティは、Accessデバイスに、Diameter Credit-Controlアプリケーションと組み合わせて使用する適切なIPパケットフィルターを提供することができます。たとえば、このようなエンティティは、直径クレジットコントロールアプリケーションがristict_accessまたはリダイレクトを示しているときに、IPフローを備えたアクセスデバイスを渡すように構成する場合があります。アクセスデバイスは、他のエンティティによって構成されている可能性のあるものに加えて、クレジット制御応答メッセージで受信された可能性のあるフィルタールールに従ってIPパケットを渡します。ただし、ユーザーのアカウントが要求されたサービスのコストをカバーできない場合、実行されたアクションは、プリペイドサブスクライバーを制御するクレジット制御サーバーの責任です。
If another entity working in conjunction with the Diameter credit-control application already provisions the access device with all the required filter rules for the end user, the credit-control server presumably need not send any additional filter. Therefore, it is RECOMMENDED that credit-control server implementations supporting the graceful service termination be configurable for sending the Restriction-Filter-Rule AVP, the Filter-Id AVP, or none of the above.
Diameter Credit-Controlアプリケーションと連携して作業する別のエンティティが、エンドユーザーに必要なすべてのフィルタールールを備えたアクセスデバイスにすでに提供されている場合、クレジット制御サーバーはおそらく追加のフィルターを送信する必要はありません。したがって、優雅なサービス終了をサポートするクレジットコントロールサーバーの実装を、制限フィルタールールAVP、フィルター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 the previous section for the REDIRECT action.
最終的な付与ユニットが消費された場合、クレジット制御クライアントは中間尋問を実行する必要があります。クレジット制御クライアントとクレジット制御サーバーは、リダイレクトアクションの前のセクションで指定されているように、この中間の尋問とその後の手順を実行します。
The credit-control server may initiate the graceful service termination with action RESTRICT_ACCESS already for the first interrogation, as specified in the previous section for the REDIRECT action.
クレジットコントロールサーバーは、リダイレクトアクションの前のセクションで指定されているように、最初の尋問のために既にアクション制限_Accessを使用して優雅なサービス終了を開始する場合があります。
Once the subscriber replenishes the account, she presumably expects all the restrictions placed by the graceful termination procedure to be removed immediately and unlimited service' access to be resumed. For the best user experience, the credit-control server implementation MAY support the server-initiated credit re-authorization (see section 5.5). In such a case, upon the successful account top-up, the credit-control server sends the Re-Auth-Request (RAR) message to solicit the credit re-authorization. The credit-control client initiates the credit re-authorization by sending the Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Used-Service-Unit AVP is not included in the request, as there is no allotted quota to report. The Requested-Service-Unit AVP MAY be included in the request. After the credit-control client successfully receives the Credit-Control-Answer with new Granted-Service-Unit, all the possible restrictions activated for the purpose of the graceful service termination MUST be removed in the service element. The credit-control session and the service session continue as usual.
加入者がアカウントを補充すると、彼女はおそらく、優雅な終了手順によって配置されたすべての制限がすぐに削除され、無制限のサービスが再開されると予想しています。最高のユーザーエクスペリエンスのために、クレジット制御サーバーの実装は、サーバーが開始したクレジットの再承認をサポートする場合があります（セクション5.5を参照）。そのような場合、成功したアカウントのトップアップにより、クレジットコントロールサーバーは、クレジットの再承認を求めるために、再承認（RAR）メッセージを送信します。クレジット制御クライアントは、CC-Request-Type AVPをValue update_Requestに設定してクレジット制御メッセージを送信することにより、クレジットの再承認を開始します。使用されているサービスユニットAVPは、報告する割り当てされた割り当てがないため、リクエストには含まれていません。要求されたサービスユニットAVPは、リクエストに含まれる場合があります。クレジット制御クライアントが新しい付与されたサービスユニットを使用してクレジット制御を正常に受信した後、優雅なサービス終了の目的でアクティブ化されたすべての制限をサービス要素で削除する必要があります。クレジット制御セッションとサービスセッションは通常どおり続きます。
The Credit-Control-Failure-Handling AVP (CCFH), as described in this section, determines the behavior of the credit-control client in fault situations. The CCFH may be received from the Diameter home AAA server, from the credit-control server, or may be configured locally. The CCFH value received from the home AAA server overrides the locally configured value. The CCFH value received from the credit-control server in the Credit-Control-Answer message always overrides any existing value.
このセクションで説明されているように、クレジット制御対策対処AVP（CCFH）は、障害状況でのクレジット制御クライアントの動作を決定します。CCFHは、Diameter Home AAAサーバー、クレジット制御サーバーから受信されるか、ローカルで構成されている場合があります。Home AAAサーバーから受信したCCFH値は、ローカルで構成された値をオーバーライドします。クレジットコントロール回答メッセージのクレジット制御サーバーから受信したCCFH値は、常に既存の値をオーバーライドします。
The authorization server MAY include the Accounting-Realtime-Required AVP to determine what to do if the sending of accounting records to the accounting server has been temporarily prevented, as defined in [DIAMBASE]. It is RECOMMENDED that the client complement the credit-control failure procedures with backup accounting flow toward an accounting server. By using different combinations of Accounting-Realtime-Required and Credit-Control-Failure-Handling AVPs, different safety levels can be built. For example, by choosing a Credit-Control-Failure-Handling AVP equal to CONTINUE for the credit-control flow and a Accounting-Realtime-Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the service can be granted 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.
Authorization Serverには、[Diambase]で定義されているように、アカウンティングサーバーへの会計記録の送信が一時的に防止された場合に何をすべきかを判断するために、Accounting-RealTime Required AVPを含めることができます。クライアントは、会計サーバーへのバックアップ会計フローでクレジット制御障害手順を補完することをお勧めします。アカウンティングリアルタイムリクエアとクレジットコントロール処理AVPのさまざまな組み合わせを使用することにより、さまざまな安全レベルを構築できます。たとえば、クレジット制御フローの継続に等しいクレジット制御対策処理AVPを選択し、会計フローの納品_and_grantに等しい会計Realtimeが要求するAVPを選択することにより、サービスをエンドユーザーに許可することができます。アカウンティングサーバーが会計情報と情報交換が会計サーバーとクレジットコントロールサーバーの間で行われている限り、クレジットコントロールサーバーへの接続はダウンしています。
As the credit-control application is based on real-time bi-directional communication between the credit-control client and the credit-control server, the usage of alternative destinations and the buffering of messages may not be sufficient in the event of communication failures. Because the credit-control server has to maintain session states, moving the credit-control message stream to a backup server requires a complex context transfer solution. Whether the credit-control message stream is moved to a backup credit-control server during an ongoing credit-control session depends on the value of the CC-Session-Failover AVP. However, failover may occur at any point in the path between the credit-control client and the credit-control server if a transport failure is detected with a peer, as described in [DIAMBASE]. As a consequence, the credit-control server might receive duplicate messages. These duplicates or out of sequence messages can be detected in the credit-control server based on the credit-control server session state machine (section 7), Session-Id AVP, and CC-Request-Number AVP.
クレジット制御アプリケーションは、クレジット制御クライアントとクレジット制御サーバー間のリアルタイムの双方向通信に基づいているため、通信障害が発生した場合、代替目的地とメッセージのバッファリングは十分ではない場合があります。クレジット制御サーバーはセッション状態を維持する必要があるため、クレジットコントロールメッセージストリームをバックアップサーバーに移動するには、複雑なコンテキスト転送ソリューションが必要です。継続的なクレジットコントロールセッション中にクレジットコントロールメッセージストリームがバックアップクレジットコントロールサーバーに移動されるかどうかは、CC-Session-Failover AVPの値に依存します。ただし、[Diambase]で説明されているように、輸送の障害がピアで検出された場合、クレジット制御クライアントとクレジット制御サーバーの間のパスの任意の時点でフェールオーバーが発生する場合があります。結果として、クレジット制御サーバーは重複したメッセージを受信する可能性があります。これらの複製またはシーケンス外のメッセージは、クレジット制御サーバーセッションステートマシン（セクション7）、セッション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 CC-server indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP. A secondary credit-control server name, either received from the home Diameter AAA server or configured locally, can be used as an address of the backup server. If the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be moved to a backup server.
継続的なクレジット制御セッション中に失敗が発生した場合、CC-ServerがCC-Session-Failover AVPでFailover_supportedを示した場合、クレジット制御クライアントはクレジット制御メッセージストリームを代替サーバーに移動する場合があります。自宅の直径AAAサーバーから受信するか、ローカルで構成されている二次クレジット制御サーバー名は、バックアップサーバーのアドレスとして使用できます。CC-Session-Failover AVPがfailover_not_supportedに設定されている場合、クレジット制御メッセージストリームをバックアップサーバーに移動してはなりません。
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.
新しいクレジット制御セッションの場合、可能であれば、代替のクレジット制御サーバーへのフェイルオーバーを実行する必要があります。たとえば、クレジット制御クライアントの実装がプライマリクレジット制御サーバーの利用不能を決定できる場合、利用可能なセカンダリクレジット制御サーバーで新しいクレジット制御セッションを確立できます。
The AAA transport profile [AAATRANS] defines the application layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) defined in [AAATRANS]. The recommended default initial value for Tw (Twinit) is 30 seconds. Twinit may be set as low as 6 seconds; however, according to [AAATRANS], setting too low a value for Twinit is likely to result in an increased probability of duplicates, as well as an increase in spurious failover and failback attempts. The Diameter base protocol is common to several different types of Diameter AAA applications that may be run in the same service element. Therefore, tuning the timer Twinit to a lower value in order to satisfy the requirements of real-time applications, such as the Diameter credit-control application, will certainly cause the above mentioned problems. For prepaid services, however, the end user expects an answer from the network in a reasonable time. Thus, the Diameter credit-control client will react faster than would the underlying base protocol. Therefore this specification defines the timer Tx that is used by the credit-control client (as defined in section 13) to supervise the communication with the credit-control server. When the timer Tx elapses, the credit-control client takes an action to the end user according to the Credit-Control-Failure-Handling AVP.
AAAトランスポートプロファイル[AAATRANS]は、[AAATRANS]で定義されたウォッチドッグタイマー（TW）によって失敗し、制御されるピアからのフェイルオーバーを有効にするアプリケーションレイヤーウォッチドッグアルゴリズムを定義します。TW（Twinit）の推奨デフォルトの初期値は30秒です。Twinitは、6秒の低さに設定される場合があります。ただし、[aaatrans]によれば、Twinitの値が低く設定すると、重複の可能性が増加する可能性が高くなり、偽のフェールオーバーとフェイルバックの試みが増加する可能性があります。直径ベースプロトコルは、同じサービス要素で実行できるいくつかの異なるタイプの直径AAAアプリケーションに共通しています。したがって、直径クレジットコントロールアプリケーションなどのリアルタイムアプリケーションの要件を満たすために、タイマートゥイインをより低い値に調整すると、上記の問題が確実に引き起こされます。ただし、プリペイドサービスの場合、エンドユーザーは合理的な時間内にネットワークからの回答を期待しています。したがって、直径のクレジットコントロールクライアントは、基礎となるベースプロトコルよりも速く反応します。したがって、この仕様は、クレジット制御サーバーとの通信を監督するためにクレジット制御クライアント（セクション13で定義されているように）が使用するタイマーTXを定義します。タイマーTXが経過すると、クレジット制御クライアントは、クレジット制御対策AVPに従ってエンドユーザーにアクションを実行します。
When Tx expires, the Diameter credit-control client always terminates the service if the Credit-Control-Failure-Handling (CCFH) AVP is set to the value TERMINATE. The credit-control session may be moved to an alternative server only if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before Tx expires. Therefore, the value TERMINATE is not appropriate if proper failover behavior is desired.
TXが有効になると、クレジット制御対策（CCFH）AVPが値に設定されている場合、Diameter Credit-Controlクライアントは常にサービスを終了します。クレジットコントロールセッションは、TXが期限切れになる前にプロトコルエラーdiameter_too_busyまたはdiameter_unable_to_deliverを受信した場合にのみ、代替サーバーに移動できます。したがって、適切なフェイルオーバー動作が必要な場合、値は適切ではありません。
If the Credit-Control-Failure-Handling AVP is set to the value CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the end user when the timer Tx expires. An answer message with granted-units may arrive later if the base protocol transport failover occurred in the path to the credit-control server. (The Twinit default value is 3 times more than the Tx recommended value.) The credit-control client SHOULD grant the service to the end user, start monitoring the resource usage, and wait for the possible late answer until the timeout of the request (e.g., 120 seconds). If the request fails and the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control client terminates or continues the service depending on the value set in the CCFH and MUST free all the reserved resources for the credit-control session. If the protocol error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or the request times out and the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the credit-control client MAY send the request to a backup server, if possible. If the credit-control client receives a successful answer from the backup server, it continues the credit-control session with such a server. If the re-transmitted request also fails, the credit-control client terminates or continues the service depending on the value set in the CCFH and MUST free all the reserved resources for the credit-control session.
クレジット制御対策処理AVPが値に設定されている場合、または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に設定されている場合、クレジット制御クライアントは、可能であればバックアップサーバーにリクエストを送信できます。クレジット制御クライアントがバックアップサーバーから成功した回答を受け取った場合、そのようなサーバーとのクレジット制御セッションを継続します。再送信された要求も失敗した場合、クレジット制御クライアントは、CCFHに設定された値に応じてサービスを終了または継続し、クレジット制御セッションのために予約されたリソースをすべて解放する必要があります。
If a communication failure occurs during the graceful service termination procedure, the service element SHOULD always terminate the ongoing service session.
優雅なサービス終了手順中に通信障害が発生した場合、サービス要素は常に進行中のサービスセッションを終了する必要があります。
If the credit-control server detects a failure during an ongoing credit-control session, it will terminate the credit-control session and return the reserved units back to the end user's account.
クレジット制御サーバーが進行中のクレジット制御セッション中に失敗を検出した場合、クレジット制御セッションを終了し、予約済みユニットをエンドユーザーのアカウントに戻します。
The supervision session timer Tcc (as defined in section 13) is used in the credit-control server to supervise the credit-control session.
監督セッションタイマーTCC（セクション13で定義）は、クレジット制御サーバーでクレジット制御セッションを監督するために使用されます。
In order to support failover between credit-control servers, information transfer about the credit-control session and account state SHOULD take place between the primary and the secondary credit-control server. Implementations supporting the credit-control session failover MUST also ensure proper detection of duplicate or out of sequence messages. The communication between the servers is regarded as an implementation issue and is outside of the scope of this specification.
クレジット制御サーバー間のフェールオーバーをサポートするために、プライマリとセカンダリクレジットコントロールサーバーの間でクレジット制御セッションとアカウント状態に関する情報転送が行われるべきです。クレジット制御セッションのフェールオーバーをサポートする実装は、重複または順序外のメッセージの適切な検出を確保する必要があります。サーバー間の通信は、実装の問題と見なされており、この仕様の範囲外です。
The one-time event is used when there is no need to maintain any state in the Diameter credit-control server; for example, enquiring about the price of the service. The use of a one-time event implies that the user has been authenticated and authorized beforehand.
直径のクレジットコントロールサーバーに状態を維持する必要がない場合、1回限りのイベントが使用されます。たとえば、サービスの価格について問い合わせる。1回限りのイベントの使用は、ユーザーが事前に認証および承認されたことを意味します。
The one time event can be used when the credit-control client wants to know the cost of the service event or to check the account balance without any credit-reservation. It can also be used for refunding service units on the user's account or for direct debiting without any credit-reservation. The one time event is shown in Figure 6.
クレジットコントロールクライアントがサービスイベントのコストを知りたい場合、またはクレジット保証なしでアカウントの残高を確認したい場合、ワンタイムイベントを使用できます。また、ユーザーのアカウントでサービスユニットの払い戻しや、信用保証なしでの直接デビットにも使用できます。ワンタイムイベントを図6に示します。
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Request | | |
|------------------>| | |
| | CCR(Event) | |
| |------------------->| CCR(Event) |
| | |------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------|
| Service Delivery |<-------------------| |
|<----------------->| | |
Figure 6: One time event
図6：ワンタイムイベント
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アーキテクチャなどの環境では、ワンタイムイベントをサービス要素から直接クレジットコントロールサーバーに送信できます。
The credit-control client may need to know the price of the service event. Services offered by application service providers whose prices are not known in the credit-control client might exist. The end user might also want to get an estimation of the price of a service event before requesting it.
クレジット制御クライアントは、サービスイベントの価格を知る必要がある場合があります。クレジット制御クライアントで価格が不明なアプリケーションサービスプロバイダーが提供するサービスが存在する可能性があります。エンドユーザーは、リクエストする前にサービスイベントの価格の見積もりを取得したい場合もあります。
A Diameter credit-control client requesting the cost information MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include the Requested-Action AVP set to PRICE_ENQUIRY, and set the requested service event information into the Service-Identifier AVP in the Credit-Control-Request message. Additional service event information may be sent as service specific AVPs or within the Service-Parameter-Info AVP. The Service-Context-Id AVP indicates the service specific document applicable to the request.
コスト情報を要求する直径クレジットコントロールクライアントは、CC-Request-Type AVPをevent_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 check or credit-reservation from the account.
クレジットコントロールサーバーは、要求されたサービスイベントのコストを計算しますが、アカウントの残高チェックやアカウントからの信用保証は実行されません。
The estimated cost of the requested service event is returned to the credit-control client in the Cost-Information AVP in the Credit-Control-Answer message.
要求されたサービスイベントの推定コストは、クレジットコントロール回答メッセージのコスト情報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 the balance check MUST set the CC-Request-Type AVP equal to EVENT_REQUEST, include a Requested-Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP in order to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service specific document applicable to the request.
バランスチェックを要求する直径のクレジットコントロールクライアントは、CC-Request-Type AVPをevent_Requestに等しく設定する必要があります。 - コントロールサーバー。Service-Context-ID AVPは、リクエストに適用されるサービス固有のドキュメントを示します。
The credit-control server makes the balance check, but it does not make any credit-reservation from the account.
クレジット制御サーバーは残高をチェックしますが、アカウントからの信用保証はありません。
The result of balance check (ENOUGH_CREDIT/NO_CREDIT) is returned to the credit-control client in the Check-Balance-Result AVP in the Credit-Control-Answer message.
バランスチェックの結果（SOON_CREDIT/NO_CREDIT）は、クレジットコントロール回答メッセージのチェックバランス応答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 the session-based credit-control would lead to unreasonably long credit-control sessions. In these cases, the Diameter credit-control client can use the one-time event scenario for direct debiting. The Diameter credit-control client SHOULD be sure that the requested service event execution would be successful when this scenario is used.
サービス環境で常にサービスの実行が成功する特定のサービスイベントがあります。サービスの呼び出しとエンドユーザーへの実際のサービス提供との間の遅延は、セッションベースのクレジット制御の使用が不当に長いクレジットコントロールセッションにつながるほど十分に長くなる可能性があります。これらの場合、Diameter Credit-Controlクライアントは、口頭での1回限りのイベントシナリオを使用できます。このシナリオが使用されると、直径のクレジットコントロールクライアントは、要求されたサービスイベントの実行が成功することを確認する必要があります。
In the Credit-Control-Request message, the CC-Request-Type is set to the value EVENT_REQUEST and the Requested-Action AVP is set to DIRECT_DEBITING. The Subscription-Id AVP SHOULD be included to identify the end user in the credit-control server. The Event-Timestamp AVP SHOULD be included in the request and contain the time when the service event is requested in the service element. The Service-Context-Id AVP indicates the service specific document applicable to the request.
クレジットコントロールレクエストメッセージでは、CC-Request-TypeがValue Event_Requestに設定され、要求されたアクションAVPはDirect_Debitingに設定されます。サブスクリプションID AVPを含めて、クレジット制御サーバーでエンドユーザーを識別する必要があります。イベント - タメスタンプAVPは、リクエストに含まれ、サービスイベントがサービス要素でリクエストされる時間を含める必要があります。Service-Context-ID AVPは、リクエストに適用されるサービス固有のドキュメントを示します。
The Diameter credit-control client MAY include the monetary amount to be charged in the Requested-Service-Unit AVP, if it knows the cost of the service event. If the Diameter credit-control client does not know the cost of the service event, the Requested-Service-Unit AVP MAY contain the number of requested service events. The Service-Identifier AVP always indicates the service concerned. Additional service event information to be rated MAY be sent as service specific AVPs or within the Service-Parameter-Info AVP.
直径のクレジットコントロールクライアントには、サービスイベントのコストを知っている場合、要求されたサービスユニットAVPで請求される金額を含めることができます。直径クレジットコントロールクライアントがサービスイベントのコストを知らない場合、要求されたサービスユニット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.
クレジット制御サーバーは、サービスイベントを評価し、対応する金額をエンドユーザーのアカウントから差し引く必要があります。要求されたサービスユニットAVPのタイプがお金である場合、格付けは必要ありませんが、対応する金額はエンドユーザーのアカウントから控除されます。
The credit-control server returns the Granted-Service-Unit AVP in the Credit-Control-Answer message to the Diameter credit-control client. The Granted-Service-Unit AVP contains the amount of service units that the Diameter credit-control client can provide to the end user. The type of the Granted-Service-Unit can be time, volume, service specific, or money, depending on the type of service event.
クレジットコントロールサーバーは、クレジット制御応答メッセージの付与されたサービスユニットAVPをDiameter Credit-Controlクライアントに返します。付与されたサービスユニットAVPには、Diameter Credit-Controlクライアントがエンドユーザーに提供できるサービスユニットの量が含まれています。許可されたサービスユニットのタイプは、サービスイベントの種類に応じて、時間、ボリューム、サービス固有の、またはお金です。
If the credit-control server determines that no credit-control is needed for the service, it can include the result code indicating that the credit-control is not applicable (e.g., service is free of charge).
クレジット制御サーバーがサービスにクレジット制御が必要ないと判断した場合、クレジット制御が適用されないことを示す結果コードを含めることができます（たとえば、サービスは無料です）。
For informative purposes, the Credit-Control-Answer message MAY also include the Cost-Information AVP containing the estimated total cost of the requested service.
有益な目的のために、クレジット制御応答メッセージには、要求されたサービスの推定総コストを含むコスト情報AVPも含まれる場合があります。
Some services may refund service units to the end user's account; for example, gaming services.
一部のサービスは、サービスユニットをエンドユーザーのアカウントに返金する場合があります。たとえば、ゲームサービス。
The credit-control client MUST set CC-Request-Type to the value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the Credit-Control-Request message. The Subscription-Id AVP SHOULD be included to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service specific document applicable to the request.
クレジット制御クライアントは、CC-Request-TypeをValue event_Requestおよび要求されたアクションAVPに、クレジット制御リケストメッセージでrexund_Accountに設定する必要があります。サブスクリプションID 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 concerned service. If the Diameter credit-control client does not know the monetary amount to be refunded, in addition to the Service-Identifier AVP it MAY send service specific AVPs or the Service-Parameter-Info AVP containing additional service event information to be rated.
直径クレジットコントロールクライアントには、要求されたサービスユニットAVPで返金される金額を含めることができます。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 unit.
有益な目的のために、クレジット制御応答メッセージには、推定金額の返金されたユニットを含むコスト情報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 re-send the request to an alternative server, if possible. There MAY be protocol transparent Diameter relays and redirect agents or Diameter credit-control proxies between the credit-control client and credit-control server. Failover may occur at any point in the path between the credit-control client and the credit-control server if a transport failure is detected with a peer, as described in [DIAMBASE]. Because there can be duplicate requests for various reasons, the credit-control server is responsible for real time duplicate detection. Implementation issues for duplicate detection are discussed in [DIAMBASE], Appendix C.
サーバーがセッションの状態を維持していないため、代替クレジット制御サーバーへのフェールオーバーは1回限りのイベントに許可されています。たとえば、クレジットコントロールクライアントがプロトコルエラーdiameter_unable_to_deliverまたはdiameter_too_busyを受信した場合、可能であれば、代替サーバーにリクエストを再センドできます。プロトコル透明な直径リレーとリダイレクトエージェントまたはクレジット制御クライアントとクレジット制御サーバーの間に直径のクレジット制御プロキシが存在する場合があります。[Diambase]で説明されているように、ピアで輸送の障害が検出された場合、クレジット制御クライアントとクレジット制御サーバーの間のパスの任意の時点でフェールオーバーが発生する場合があります。さまざまな理由で重複するリクエストがある可能性があるため、クレジット制御サーバーはリアルタイムの複製検出を担当します。重複検出のための実装の問題は、[Diambase]、付録Cで説明されています。
When the credit-control client detects a communication failure with the credit-control server, its behavior depends on the requested action. The timer Tx (as defined in section 13) is used in the credit-control client to supervise the communication with the credit-control server.
クレジット制御クライアントがクレジット制御サーバーとの通信障害を検出すると、その動作は要求されたアクションに依存します。タイマーTX（セクション13で定義）は、クレジット制御クライアントで使用され、クレジット制御サーバーとの通信を監督します。
If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and communication failure is detected, the credit-control client SHOULD forward the request messages to an alternative credit-control server, if possible. The secondary credit-control server name, if received from the home Diameter AAA server, can be used as an address of backup server.
要求されたアクションがrice_enquiryまたはcheck_balanceと通信の失敗が検出された場合、クレジット制御クライアントは、可能であれば、リクエストメッセージを代替クレジットコントロールサーバーに転送する必要があります。セカンダリクレジットコントロールサーバー名は、自宅の直径AAAサーバーから受信した場合、バックアップサーバーのアドレスとして使用できます。
If the requested action is DIRECT_DEBITING, the Direct-Debiting-Failure-Handling AVP (DDFH) controls the credit-control client's behavior. The DDFH may be received from the home Diameter AAA server or may be locally configured. The credit-control server may also send the DDFH in any CCA message to be used for direct debiting events compiled thereafter. The DDFH value received from the home Diameter AAA server overrides the locally configured value, and the DDFH value received from the credit-control server in a Credit-Control-Answer message always overrides any existing value.
要求されたアクションがDirect_Debitingである場合、直接免除対策AVP（DDFH）がクレジットコントロールクライアントの動作を制御します。DDFHは、自宅の直径AAAサーバーから受信されるか、ローカルで構成されている場合があります。クレジットコントロールサーバーは、CCAメッセージにDDFHを送信して、その後コンパイルされた口頭でのデビットイベントに使用する場合もあります。ホーム直径AAAサーバーから受信したDDFH値は、ローカルで構成された値をオーバーライドし、クレジット制御サーバーから受信したDDFH値は、クレジット制御応答メッセージで常に既存の値をオーバーライドします。
If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT grant the service if it can determine, eventually after a possible re-transmission attempt to an alternative credit-control server, from the result code or error code in the answer message that units have not been debited. Otherwise, the credit-control client SHOULD grant the service to the end user and store the request in the credit-control application level non-volatile storage. (Note that re-sending the request at a later time is not a guarantee that the service will be debited, as the user's account may be empty when the server successfully processes the request.) The credit-control client MUST mark these request messages as possible duplicates by setting the T-flag in the command header as described in [DIAMBASE], section 3.
ddfhがexterminate_or_bufferに設定されている場合、クレジットコントロールクライアントが、最終的には、結果コードまたは回答メッセージのエラーコードから代替クレジットコントロールサーバーへの再送信の試みの後に、最終的に決定できる場合、サービスを許可するべきではありません。そのユニットは引き落とされていません。それ以外の場合、クレジット制御クライアントは、エンドユーザーにサービスを許可し、クレジット制御アプリケーションレベルの不揮発性ストレージにリクエストを保存する必要があります。（後の時間にリクエストを再配置することは、サーバーがリクエストを正常に処理するときにユーザーのアカウントが空になる可能性があるため、サービスが引き落とされることを保証するものではありません。）クレジット制御クライアントは、これらの要求メッセージをマークする必要があります。[Diambase]、セクション3に記載されているように、コマンドヘッダーにT-FLAGを設定することにより、可能な複製があります。
If the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the service SHOULD be granted, even if credit-control messages cannot be delivered and messages are not buffered.
クレジット制御メッセージを配信できず、メッセージがバッファリングされない場合でも、直接免除対処のAVPが継続するように設定されている場合、サービスを許可する必要があります。
If the timer Tx expires, the credit-control client MUST continue the service and wait for a possible late answer. If the request times out, the credit-control client re-transmits the request (marked with T-flag) to a backup credit-control server, if possible. If the re-transmitted request also times out, or if a temporary error is received in answer, the credit-control client buffers the request if the value of the Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER. If a failed answer is received for the re-transmitted request, the credit-control client frees all the resources reserved for the event message and deletes the request regardless of the value of the DDFH.
タイマーTXの有効期限が切れた場合、クレジット制御クライアントはサービスを継続し、可能な遅い回答を待つ必要があります。リクエストがタイムアウトする場合、クレジット制御クライアントは、可能であれば、バックアップクレジットコントロールサーバーにリクエスト（T-Flagでマークされた）を再トランスミスします。再送信されたリクエストも時間がかかる場合、または回答で一時的なエラーが受信された場合、クレジット制御クライアントは、直接免除対策AVPの値がTerminate_or_bufferに設定されている場合、リクエストをバッファーします。再送信された要求に対して失敗した回答が受信された場合、クレジット制御クライアントは、イベントメッセージのために予約されたすべてのリソースを解放し、DDFHの値に関係なくリクエストを削除します。
The Credit-Control-Request with the requested action REFUND_ACCOUNT should always be stored in the credit-control application level non-volatile storage in case of temporary failure. The credit-control client MUST mark the re-transmitted request message as a possible duplicate by setting the T-flag in the command header as described in [DIAMBASE], section 3.
要求された訴訟の払い戻し_Accountを使用したクレジット制御要求は、一時的な失敗の場合に常にクレジット制御アプリケーションレベルの不揮発性ストレージに保存する必要があります。クレジット制御クライアントは、[Diambase]、セクション3で説明されているように、コマンドヘッダーにT-FLAGを設定することにより、再移行されたリクエストメッセージを複製の可能性としてマークする必要があります。
For stored requests, the implementation may choose to limit the number of re-transmission attempts and to define a re-transmission interval.
保存されたリクエストの場合、実装は再送信試行の数を制限し、再送信間隔を定義することを選択する場合があります。
Note that only one place in the credit-control system SHOULD be responsible for duplicate detection. If there is only one credit-control server within the given realm, the credit-control server may perform duplicate detection. If there is more than one credit-control server in a given realm, only one entity in the credit-control system should be responsible, to ensure that the end user's account is not debited or credited multiple times for the same service event.
クレジット制御システムの1つの場所のみが重複検出を担当する必要があることに注意してください。指定された領域内にクレジット制御サーバーが1つしかない場合、クレジット制御サーバーは重複検出を実行できます。特定の領域に複数のクレジットコントロールサーバーがある場合、エンドユーザーのアカウントが同じサービスイベントで複数回引き落とされたり、クレジットされたりしないことを確認するために、クレジット制御システムの1つのエンティティのみが責任を負う必要があります。
This section defines the credit-control application state machine.
このセクションでは、クレジット制御アプリケーションの状態マシンを定義します。
The first four state machines are to be observed by credit-control clients. The first one describes the session-based credit-control when the first interrogation is executed as part of the authorization/authentication process. The second describes the session-based credit-control when the first interrogation is executed after the authorization/authentication process. The requirements as to what state machines have to be supported are discussed in section 5.2.
最初の4つの州のマシンは、クレジット制御クライアントによって観察されます。最初のものは、最初の尋問が承認/認証プロセスの一部として実行される場合のセッションベースのクレジット制御について説明します。2番目は、最初の尋問が承認/認証プロセスの後に実行される場合のセッションベースのクレジット制御について説明します。州のマシンをサポートする必要があるものに関する要件については、セクション5.2で説明します。
The third state machine describes the session-based credit-control for the intermediate and final interrogations. The fourth one describes the event-based credit-control. These latter state machines are to be observed by all implementations that conform to this specification.
3番目の状態マシンは、中間および最終尋問のセッションベースのクレジット制御について説明しています。4番目のものは、イベントベースのクレジット制御について説明しています。これらの後者の状態マシンは、この仕様に準拠するすべての実装によって観察される必要があります。
The fifth state machine describes the credit-control session from a credit-control server perspective.
5番目の州のマシンは、クレジット制御サーバーの観点からのクレジット制御セッションについて説明しています。
Any event not listed in the state machines MUST be considered an error condition, and a corresponding answer, if applicable, MUST be returned to the originator of the message.
状態マシンにリストされていないイベントは、エラー条件と見なされ、対応する回答は、該当する場合はメッセージの発信者に返品する必要があります。
In the state table, the event 'Failure to send' means that the Diameter credit-control client is unable to communicate with the desired destination or, if failover procedure is supported, with a possibly defined alternative destination (e.g., the request times out and the answer message is not received). This could be due to the peer being down, or due to a physical link failure in the path to or from the credit-control server.
州の表では、イベント「送信の失敗」とは、直径のクレジットコントロールクライアントが目的の宛先と通信できないことを意味します。回答メッセージは受信されません）。これは、ピアがダウンしていること、またはクレジット制御サーバーとの間でのパスでの物理的なリンクの故障による可能性があります。
The event 'Temporary error' means that the Diameter credit-control client received a protocol error notification (DIAMETER_TOO_BUSY, DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) in the Result-Code AVP of the Credit-Control-Answer command. The above protocol error notification may ultimately be received in answer to the re-transmitted request to a defined alternative destination, if failover is supported.
イベント「一時的なエラー」とは、Diameter Credit-Controlクライアントが、Credit-Control-AnswerコマンドのResult-Code AVPでプロトコルエラー通知（diametor_too_busy、diame_unable_to_deliver、またはdiame_loop_detected）を受け取ったことを意味します。上記のプロトコルエラー通知は、フェイルオーバーがサポートされている場合、定義された代替宛先への再送信要求に応答して、最終的に受信することができます。
The event 'Failed answer' means that the Diameter credit-control client received non-transient failure (permanent failure) notification in the Credit-Control-Answer command. The above permanent failure notification may ultimately be received in answer to the re-transmitted request to a defined alternative destination, if failover is supported.
イベント「失敗した回答」とは、直径のクレジット制御クライアントが、クレジットコントロール回答コマンドで非転換障害（永久障害）通知を受け取ったことを意味します。上記の恒久的な障害通知は、フェイルオーバーがサポートされている場合、定義された代替宛先への再送信要求に応答して、最終的に受信することができます。
The action 'store request' means that a request is stored in the credit-control application level non-volatile storage.
アクション「ストアリクエスト」とは、リクエストがクレジット制御アプリケーションレベルの不揮発性ストレージに保存されることを意味します。
The event 'Not successfully processed' means that the credit-control server could not process the message; e.g., due to an unknown end user, account being empty, or errors defined in [DIAMBASE].
「正常に処理されていない」イベントは、クレジット制御サーバーがメッセージを処理できなかったことを意味します。たとえば、未知のエンドユーザーのため、アカウントが空であるか、[Diambase]で定義されているエラー。
The event 'User service terminated' can be triggered by various reasons, e.g., normal user termination, network failure, and ASR (Abort-Session-Request). The Termination-Cause AVP contains information about the termination reason, as specified in [DIAMBASE].
イベント「ユーザーサービス終了」は、通常のユーザー終了、ネットワーク障害、ASR（Abort-Session-Requestなど）、さまざまな理由でトリガーできます。終了原因AVPには、[Diambase]で指定されているように、終端理由に関する情報が含まれています。
The Tx timer, which is used to control the waiting time in the credit-control client in the Pending state, is stopped upon exit of the Pending state. The stopping of the Tx timer is omitted in the state machine when the new state is Idle, as moving to Idle state implies the clearing of the session and all the variables associated to it.
保留中の状態のクレジット制御クライアントの待ち時間を制御するために使用されるTXタイマーは、保留中の状態の出口時に停止されます。TXタイマーの停止は、新しい状態がアイドル状態である場合、状態マシンで省略されます。これは、アイドル状態に移動するとセッションのクリアとそれに関連するすべての変数を暗示しているためです。
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.
州は、それぞれ保留中、留置、保留中、保留中の、保留中、保留中の州は、それぞれ初期、更新、終了、イベント、またはバッファリクエストに関連するクレジット制御リクエストへの回答を待つ保留中の州を支持しています。
The acronyms CCFH and DDFH stand for Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling, respectively.
頭字語CCFHとDDFHは、それぞれクレジット制御対策処理と直接免除の扱いを行うための略です。
In the following state machine table, the failover to a secondary server upon 'Temporary error' or 'Failure to send' is not explicitly described. Moving an ongoing credit-control message stream to an alternative server is, however, possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, as described in section 5.7.
次のステートマシンテーブルでは、「一時的なエラー」または「送信の失敗」時のセカンダリサーバーへのフェールオーバーは明示的に説明されていません。ただし、セクション5.7で説明されているように、CC-Session-Failover AVPがFailover_Supportedに設定されている場合、継続的なクレジットコントロールメッセージストリームを代替サーバーに移動することは可能です。
Re-sending a credit-control event to an alternative server is supported as described in section 6.5.
セクション6.5で説明されているように、クレジット制御イベントを代替サーバーに再担保することがサポートされています。
CLIENT, SESSION BASED for the first interrogation with AA request
クライアント、AAリクエストとの最初の尋問に基づくセッション
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send PendingI
access/service AA request
with added
CC AVPs,
start Tx
PendingI Successful AA req. Grant Open answer received service to end user, stop Tx
保留中の成功aa req。オープンな回答を許可するサービスを受け取ったサービスをエンドユーザーに、テキサスを停止します
PendingI Tx expired Disconnect Idle user/dev
保留中のTXの期限切れの切断アイドルユーザー/開発
PendingI Failed AA answer received Disconnect Idle user/dev
保留中の失敗AA回答は、アイドルユーザー/devを切断したことを受け取りました
PendingI AA answer Grant Idle received with result code service equal to CREDIT_CONTROL_ to end user NOT_APPLICABLE
PRIDESI AA ANSWER GRANT IDLE IDLE IDLE IDERESPREST CODE CODE SERVICEでENDユーザーに等しいCredit_Control_に等しい
PendingI User service terminated Queue PendingI termination event
保留中のユーザーサービス終了キュー保留中のキューイベント
PendingI Change in rating condition Queue PendingI changed rating condition event
評価条件の変化条件のQueue Pendingi変更条件イベント
CLIENT, SESSION BASED for the first interrogation with CCR
クライアント、CCRとの最初の尋問に基づくセッション
State Event Action New State
----------------------------------------------------------------
Idle Client or device requests Send PendingI access/service CC initial req., start Tx
アイドルクライアントまたはデバイスリクエストは保留中のアクセス/サービスCC初期reqを送信し、テキサスを開始します
PendingI Successful CC initial Stop Tx Open answer received
保留中のCC初期停止txオープン回答を受け取った
PendingI Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
PendingI Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
PendingI Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
PendingI Tx expired and CCFH equal Grant PendingI
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingI CC initial answer Terminate Idle received with result code end user's END_USER_SERVICE_DENIED or service USER_UNKNOWN
保留中のCC初期回答結果コードで受信したアイドルを終了しますエンドユーザーのend_user_service_deniedまたはservice user_unknown
PendingI CC initial answer Grant Idle received with result code service equal to CREDIT_CONTROL_ to end user NOT_APPLICABLE
保留中のCC初期回答creding_control_に等しい結果コードサービスで受け取った初期回答not_applable
PendingI Failed CC initial answer Grant Idle received and CCFH equal to service to CONTINUE end user
保留中のCCの最初の回答の失敗
PendingI Failed CC initial answer Terminate Idle received and CCFH equal end user's to TERMINATE or to service RETRY_AND_TERMINATE
保留中のCC初期回答が失敗しました
PendingI User service terminated Queue PendingI termination event
保留中のユーザーサービス終了キュー保留中のキューイベント
PendingI Change in rating condition Queue PendingI changed rating condition event
評価条件の変化条件のQueue Pendingi変更条件イベント
CLIENT, SESSION BASED for intermediate and final interrogations
クライアント、中間および最終的な尋問に基づくセッション
State Event Action New State
----------------------------------------------------------------
Open Granted unit elapses Send PendingU
and no final unit CC update
indication received req.,
start Tx
Open Granted unit elapses Terminate PendingT
and final unit action end user's
equal to TERMINATE service, send
received CC termination
req.
Open Change in rating condition Send PendingU in queue CC update req., Start Tx
定格条件のオープンな変更キューCCアップデートReq。、TXを開始する
Open Service terminated in queue Send PendingT CC termination req.
キューで終了したオープンサービスは、保留中のCC終端を送信します。
Open Change in rating condition Send PendingU or Validity-Time elapses CC update req., Start Tx
評価条件のオープンな変更Penduingまたは有効期間ELAPSES CC UPDATE REQ。、START TX
Open User service terminated Send PendingT CC termination req.
オープンユーザーサービス終了保留中のCC終了REQを送信します。
Open RAR received Send RAA PendingU followed by CC update req., start Tx
Open RARは、raa penduenduを送信した後、CCアップデートReq。、Txを開始します
PendingU Successful CC update Stop Tx Open answer received
Penduの成功CCアップデートSTOP TX Open Answerを受信しました
PendingU Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
PendingU Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
PendingU Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
PendingU Tx expired and CCFH equal Grant PendingU
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingU CC update answer Terminate Idle received with result code end user's END_USER_SERVICE_DENIED service
Penduentu CCアップデート回答結果コードで受信したアイドルENDLE END_USER_SERVICE_DENIEDサービス
PendingU CC update answer Grant Idle received with result code service equal to CREDIT_CONTROL_ to end user NOT_APPLICABLE
PendingU CCアップデート応答 - 結果コードサービスで受信したIDLEは、edd not_applableでcredit_control_に等しい結果コードサービスでcredit_control_に等しい
PendingU Failed CC update Grant Idle
answer received and service to
CCFH equal to CONTINUE end user
PendingU Failed CC update Terminate Idle
answer received and CCFH end user's
equal to TERMINATE or service
to RETRY_AND_TERMINATE
PendingU User service terminated Queue PendingU termination event
Penduneduユーザーサービス終了キューPenduentu終了イベント
PendingU Change in rating Queue PendingU
condition changed
rating
condition
event
PendingU RAR received Send RAA PendingU
ペンディュラーは、raa penduを送信しました
PendingT Successful CC Idle termination answer received
保留中のCCアイドル終了回答が受け取られました
PendingT Failure to send, temporary Idle error, or failed answer
送信の失敗、一時的なアイドルエラー、または回答の失敗
PendingT Change in rating condition PendingT
保留中の評価条件の変化が保留されています
CLIENT, EVENT BASED
クライアント、イベントベース
State Event Action New State
----------------------------------------------------------------
Idle Client or device requests Send PendingE
a one-time service CC event
req.,
Start Tx
Idle Request in storage Send PendingB
stored
request
PendingE Successful CC event Grant Idle
answer received service to
end user
PendingE Failure to send, temporary Indicate Idle error, failed CC event service answer received, or error Tx expired; requested action CHECK_BALANCE or PRICE_ENQUIRY
送信の失敗は、一時的なアイドルエラーを示し、CCイベントサービスの回答に失敗したこと、またはエラーTXの有効期限が切れました。要求されたアクションCheck_balanceまたはprice_enquiry
PendingE CC event answer Terminate Idle received with result code end user's END_USER_SERVICE_DENIED or service USER_UNKNOWN and Tx running
CCCイベントの回答は、結果コードエンドで受信したアイドルを終了しますEND_USER_SERVICE_DENIEDまたはSERVICE USER_UNKNOUNTおよびTX RUNNING
PendingE CC event answer Grant Idle
received with result code service
CREDIT_CONTROL_NOT_APPLICABLE; to end
requested action user
DIRECT_DEBITING
PendingE Failure to send, temporary Grant Idle error, or failed CC event service answer received; requested to end action DIRECT_DEBITING; user DDFH equal to CONTINUE
送信の失敗、一時的な助成金アイドルエラー、またはCCイベントサービスの回答の失敗を受け取ったこと。direct_debitingを終了するように要求されました。ユーザーDDFHは続行するのと等しい
PendingE Failed CC event Terminate Idle answer received or temporary end user's error; requested action service DIRECT_DEBITING; DDFH equal to TERMINATE_OR_BUFFER and Tx running
保留中のCCイベントの失敗は、受け取ったアイドル回答または一時的なエンドユーザーのエラーを終了します。要求されたアクションサービスdirect_debiting;ddfhはターミネートに等しい_or_bufferおよびtx runningに等しくなります
PendingE Tx expired; requested Grant PendingE action DIRECT_DEBITING service to end user
保留中のTXの有効期限が切れました。エンドユーザーへの留置訴訟direct_debitingサービスを要求しました
PendingE Failure to send; requested Store Idle action DIRECT_DEBITING; request with DDFH equal to T-flag TERMINATE_OR_BUFFER
送信の失敗が保留中;要求されたストアアイドルアクションdirect_debiting;DDFHを使用してT-FLAGターミネート_or_bufferに等しくなります
PendingE Temporary error; requested Store Idle action DIRECT_DEBITING; request DDFH equal to TERMINATE_OR_BUFFER; Tx expired
一時的なエラーが保留中。要求されたストアアイドルアクションdirect_debiting;ddfhがterminate_or_bufferに等しく等しくなります。TXの有効期限が切れました
PendingE Failed answer or answer Idle received with result code END_USER_SERVICE DENIED or USER_UNKNOWN; requested action DIRECT_DEBITING; Tx expired
保留中の回答が失敗した場合、または結果コードEND_USER_SERVICEを使用して受信したIDLEの回答が拒否またはuser_unknown;要求されたアクションdirect_debiting;TXの有効期限が切れました
PendingE Failed CC event answer Indicate Idle
received; requested service
action REFUND_ACCOUNT error and
delete request
PendingE Failure to send or Store Idle
Tx expired; requested request
action REFUND_ACCOUNT with T-flag
PendingE Temporary error, Store Idle and requested action request REFUND_ACCOUNT
一時的なエラーを保留し、アイドルを保存し、要求したアクションリクエストrequund_account
PendingB Successful CC answer Delete Idle
received request
PendingB Failed CC answer Delete Idle
received request
PendingB Failure to send or Idle temporary error
一時的なエラーを送信またはアイドル状態に保留中
SERVER, SESSION AND EVENT BASED
サーバー、セッション、イベントベース
State Event Action New State
----------------------------------------------------------------
Idle CC initial request Send Open
received and successfully CC initial
processed answer,
reserve units,
start Tcc
Idle CC initial request Send Idle
received but not CC initial
successfully processed answer with
Result-Code
!= SUCCESS
Idle CC event request Send Idle
received and successfully CC event
processed answer
Idle CC event request Send Idle
received but not CC event
successfully processed answer with
Result-Code
!= SUCCESS
Open CC update request Send CC Open
received and successfully update answer,
processed debit used
units,
reserve
new units,
restart Tcc
Open CC update request Send Idle
received but not CC update
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
Open CC termination request Send Idle
received and successfully CC termin.
processed answer,
Stop Tcc,
debit used
units
Open CC termination request Send Idle
received but not CC termin.
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
Open Session supervision timer Tcc Release Idle expired reserved units
オープンセッション監督タイマーTCCリリースアイドル期限切れ予約ユニット
This section defines the credit-control AVPs that are specific to Diameter credit-control application and that MAY be included in the Diameter credit-control messages.
このセクションでは、直径のクレジット制御アプリケーションに固有のクレジット制御AVPを定義し、直径クレジットコントロールメッセージに含まれる場合があります。
The AVPs defined in this section MAY also be included in authorization commands defined in authorization-specific applications, such as [NASREQ] and [DIAMMIP], if the first interrogation is performed as part of the authorization/authentication process, as described in section 5.2.
このセクションで定義されているAVPは、セクション5.2で説明されているように、最初の尋問が承認/認証プロセスの一部として実行される場合、[Nasreq]や[diammip]などの認証固有のアプリケーションで定義された承認コマンドにも含まれる場合があります。。
The Diameter AVP rules are defined in the Diameter Base [DIAMBASE], section 4. These AVP rules are observed in AVPs defined in this section.
直径AVPルールは、直径ベース[Diambase]、セクション4で定義されています。これらのAVPルールは、このセクションで定義されているAVPで観察されます。
The following table describes the Diameter AVPs defined in the credit-control application, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The Diameter base [DIAMBASE] specifies the AVP Flag rules for AVPs in section 4.5.
次の表は、クレジット制御アプリケーションで定義されている直径AVP、AVPコード値、タイプ、可能なフラグ値、およびAVPが暗号化されるかどうかを示しています。直径ベース[Diambase]は、セクション4.5のAVPのAVPフラグルールを指定します。
+--------------------+
| AVP Flag rules |
|----+-----+----+----|----+
AVP Section | | |SHLD|MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr|
-----------------------------------------|----+-----+----+----|----|
CC-Correlation-Id 411 8.1 OctetString| | P,M | | V | Y |
CC-Input-Octets 412 8.24 Unsigned64 | M | P | | V | Y |
CC-Money 413 8.22 Grouped | M | P | | V | Y |
CC-Output-Octets 414 8.25 Unsigned64 | M | P | | V | Y |
CC-Request-Number 415 8.2 Unsigned32 | M | P | | V | Y |
CC-Request-Type 416 8.3 Enumerated | M | P | | V | Y |
CC-Service- 417 8.26 Unsigned64 | M | P | | V | Y |
Specific-Units | | | | | |
CC-Session- 418 8.4 Enumerated | M | P | | V | Y |
Failover | | | | | |
CC-Sub-Session-Id 419 8.5 Unsigned64 | M | P | | V | Y |
CC-Time 420 8.21 Unsigned32 | M | P | | V | Y |
CC-Total-Octets 421 8.23 Unsigned64 | M | P | | V | Y |
CC-Unit-Type 454 8.32 Enumerated | M | P | | V | Y |
Check-Balance- 422 8.6 Enumerated | M | P | | V | Y |
Result | | | | | |
Cost-Information 423 8.7 Grouped | M | P | | V | Y |
Cost-Unit 424 8.12 UTF8String | M | P | | V | Y |
Credit-Control 426 8.13 Enumerated | M | P | | V | Y |
Credit-Control- 427 8.14 Enumerated | M | P | | V | Y |
Failure-Handling | | | | | |
Currency-Code 425 8.11 Unsigned32 | M | P | | V | Y |
Direct-Debiting- 428 8.15 Enumerated | M | P | | V | Y |
Failure-Handling | | | | | |
Exponent 429 8.9 Integer32 | M | P | | V | Y |
Final-Unit-Action 449 8.35 Enumerated | M | P | | V | Y |
Final-Unit- 430 8.34 Grouped | M | P | | V | Y |
Indication | | | | | |
Granted-Service- 431 8.17 Grouped | M | P | | V | Y |
Unit | | | | | |
G-S-U-Pool- 453 8.31 Unsigned32 | M | P | | V | Y |
Identifier | | | | | |
G-S-U-Pool- 457 8.30 Grouped | M | P | | V | Y |
Reference | | | | | |
Multiple-Services 456 8.16 Grouped | M | P | | V | Y |
-Credit-Control | | | | | |
Multiple-Services 455 8.40 Enumerated | M | P | | V | Y |
-Indicator | | | | | |
Rating-Group 432 8.29 Unsigned32 | M | P | | V | Y |
Redirect-Address 433 8.38 Enumerated | M | P | | V | Y |
-Type | | | | | |
Redirect-Server 434 8.37 Grouped | M | P | | V | Y |
Redirect-Server 435 8.39 UTF8String | M | P | | V | Y |
-Address | | | | | |
Requested-Action 436 8.41 Enumerated | M | P | | V | Y |
Requested-Service 437 8.18 Grouped | M | P | | V | Y |
-Unit | | | | | |
Restriction 438 8.36 IPFiltrRule| M | P | | V | Y |
-Filter-Rule | | | | | |
Service-Context 461 8.42 UTF8String | M | P | | V | Y |
-Id | | | | | |
Service- 439 8.28 Unsigned32 | M | P | | V | Y |
Identifier | | | | | |
Service-Parameter 440 8.43 Grouped | | P,M | | V | Y |
-Info | | | | | |
Service- 441 8.44 Unsigned32 | | P,M | | V | Y |
Parameter-Type | | | | | |
Service- 442 8.45 OctetString| | P,M | | V | Y |
Parameter-Value | | | | | |
Subscription-Id 443 8.46 Grouped | M | P | | V | Y |
Subscription-Id 444 8.48 UTF8String | M | P | | V | Y |
-Data | | | | | |
Subscription-Id 450 8.47 Enumerated | M | P | | V | Y |
-Type | | | | | |
Tariff-Change 452 8.27 Enumerated | M | P | | V | Y |
-Usage | | | | | |
Tariff-Time 451 8.20 Time | M | P | | V | Y |
-Change | | | | | |
Unit-Value 445 8.8 Grouped | M | P | | V | Y |
Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y |
User-Equipment 458 8.49 Grouped | | P,M | | V | Y |
-Info | | | | | |
User-Equipment 459 8.50 Enumerated | | P,M | | V | Y |
-Info-Type | | | | | |
User-Equipment 460 8.51 OctetString| | P,M | | V | Y |
-Info-Value | | | | | |
Value-Digits 447 8.10 Integer64 | M | P | | V | Y |
Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y |
The CC-Correlation-Id AVP (AVP Code 411) is of type OctetString and contains information to correlate credit-control requests generated for different components of the service; e.g., transport and service level. The one who allocates the Service-Context-Id (i.e., unique identifier of a service specific document) is also responsible for defining the content and encoding of the CC-Correlation-Id AVP.
cc-correlation-id avp（AVPコード411）はタイプのオクテットストリングであり、サービスのさまざまなコンポーネントに対して生成されたクレジット制御要求を相関させるための情報を含んでいます。たとえば、輸送およびサービスレベル。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 Session-Id and CC-Request-Number AVPs is also globally unique and can be used in matching credit-control messages with confirmations. An easy way to produce unique numbers is to set the value to 0 for a credit-control request of type INITIAL_REQUEST and EVENT_REQUEST and to set the value to 1 for the first UPDATE_REQUEST, to 2 for the second, and so on until the value for TERMINATION_REQUEST is one more than for the last UPDATE_REQUEST.
CC-Request-Number AVP（AVPコード415）はsonsigned32であり、1つのセッション内でこのリクエストを識別します。Session-ID AVPはグローバルにユニークであるため、Session-IDとCC-Request-Number AVPの組み合わせもグローバルに一意であり、クレジットコントロールメッセージのマッチングで確認とともに使用できます。一意の数字を作成する簡単な方法は、タイプinitial_requestおよびevent_requestのクレジット制御要求に対して値を0に設定し、最初のupdate_requestの値を1に1に、2番目の場合は2に設定することです。Termination_Requestは、最後のupdate_requestの1つ以上のものです。
The CC-Request-Type AVP (AVP Code 416) is of type Enumerated and contains the reason for sending the credit-control request message. It MUST be present in all Credit-Control-Request messages. The following values are defined for the CC-Request-Type AVP:
CC-Request-Type AVP（AVPコード416）は列挙されたタイプで、クレジット制御要求メッセージを送信する理由が含まれています。それはすべてのクレジット制御要求メッセージに存在する必要があります。次の値は、CC-RequestタイプのAVPに対して定義されています。
INITIAL_REQUEST 1 An Initial request is used to initiate a credit-control session, and contains credit control information that is relevant to the initiation.
Initial_Request 1初期リクエストは、クレジット制御セッションを開始するために使用され、開始に関連するクレジット管理情報が含まれています。
UPDATE_REQUEST 2 An Update request contains credit-control information for an existing credit-control session. Update credit-control requests SHOULD be sent every time a credit-control re-authorization is needed at the expiry of the allocated quota or validity time. Further, additional service-specific events MAY trigger a spontaneous Update request.
update_request 2更新リクエストには、既存のクレジット制御セッションのクレジット制御情報が含まれています。割り当てられたクォータまたは有効性の期限の満了時にクレジット制御の再承認が必要になるたびに、クレジット制御リクエストを更新する必要があります。さらに、追加のサービス固有のイベントは、自発的な更新リクエストをトリガーする場合があります。
TERMINATION_REQUEST 3 A Termination request is sent to terminate a credit-control session and contains credit-control information relevant to the existing session.
Termination_Request 3クレジット制御セッションを終了するために終了要求が送信され、既存のセッションに関連するクレジット制御情報が含まれています。
EVENT_REQUEST 4 An Event request is used when there is no need to maintain any credit-control session state in the credit-control server. This request contains all information relevant to the service, and is the only request of the service. The reason for the Event request is further detailed in the Requested-Action AVP. The Requested-Action AVP MUST be included in the Credit-Control-Request message when CC-Request-Type is set to EVENT_REQUEST.
event_request 4クレジット制御サーバーでクレジット制御セッションの状態を維持する必要がない場合に、イベントリクエストが使用されます。このリクエストには、サービスに関連するすべての情報が含まれており、サービスの唯一のリクエストです。イベントリクエストの理由は、要求されたアクションAVPでさらに詳しく説明されています。CC-Request-Typeがevent_requestに設定されている場合、要求されたアクションAVPはクレジット制御再クエストメッセージに含める必要があります。
The CC-Session-Failover AVP (AVP Code 418) is type of Enumerated and contains information as to whether moving the credit-control message stream to a backup server during an ongoing credit-control session is supported. In communication failures, the credit-control message streams can be moved to an alternative destination if the credit-control server supports failover to an alternative server. The secondary credit-control server name, if received from the home Diameter AAA server, can be used as an address of the backup server. An implementation is not required to support moving a credit-control message stream to an alternative server, as this also requires moving information related to the credit-control session to backup server.
CC-Session-Failover AVP（AVPコード418）は列挙されたタイプであり、進行中のクレジット制御セッション中にクレジット制御メッセージストリームをバックアップサーバーに移動するかどうかについての情報が含まれています。通信の失敗では、クレジット制御サーバーがフェイルオーバーを代替サーバーにサポートする場合、クレジット制御メッセージストリームを代替宛先に移動できます。セカンダリクレジットコントロールサーバー名は、自宅の直径AAAサーバーから受信した場合、バックアップサーバーのアドレスとして使用できます。クレジットコントロールメッセージストリームの移動を代替サーバーに移動することもサポートする必要はありません。これには、クレジット制御セッションに関連する情報をバックアップサーバーに移動する必要があるためです。
The following values are defined for the CC-Session-Failover AVP:
次の値は、CC-Session-FailoverAVPに対して定義されています。
FAILOVER_NOT_SUPPORTED 0 When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT to be moved to an alternative destination in the case of communication failure.
failover_not_supported cc-session-failover avpがfailover_not_supportedに設定されている場合、通信障害の場合にクレジット制御メッセージストリームを代替宛先に移動する必要はありません。
This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server.
これは、AVPが承認またはクレジットコントロールサーバーからの返信に含まれていない場合のデフォルトの動作です。
FAILOVER_SUPPORTED 1 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the credit-control message stream SHOULD be moved to an alternative destination in the case of communication failure. Moving the credit-control message stream to a backup server MAY require that information related to the credit-control session should also be forwarded to alternative server.
failover_supported 1 CC-Session-FailoverAVPがFailover_supportedに設定されている場合、通信障害の場合はクレジット制御メッセージストリームを代替宛先に移動する必要があります。クレジット制御メッセージストリームをバックアップサーバーに移動すると、クレジット制御セッションに関連する情報も代替サーバーに転送する必要がある場合があります。
The CC-Sub-Session-Id AVP (AVP Code 419) is of type Unsigned64 and contains the credit-control sub-session identifier. The combination of the Session-Id and this AVP MUST be unique per sub-session, and 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）は、符号なし64であり、クレジット制御サブセッション識別子が含まれています。セッションIDとこのAVPの組み合わせは、サブセッションごとに一意でなければならず、このAVPの価値は、すべての新しいサブセッションに対して単調に増加する必要があります。この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.
チェックバランス結果AVP（AVPコード422）は列挙されており、残高チェックの結果が含まれています。このAVPは、要求されたアクションAVPがクレジット制御コマンドのcheck_balanceを示す場合にのみ適用されます。
The following values are defined for the Check-Balance-Result AVP.
次の値は、チェックバランスと結果のAVPに対して定義されています。
ENOUGH_CREDIT 0 There is enough credit in the account to cover the requested service.
SOON_CREDIT 0アカウントには、要求されたサービスをカバーするのに十分なクレジットがあります。
NO_CREDIT 1 There isn't enough credit in the account to cover the requested service.
NO_CREDIT 1要求されたサービスをカバーするのに十分なクレジットがアカウントにありません。
The Cost-Information AVP (AVP Code 423) is of type Grouped, and it is used to return the cost information of a service, which the credit-control client can transfer transparently to the end user. The included Unit-Value AVP contains the cost estimate (always type of money) of the service, in the case of price enquiry, or the accumulated cost estimation, in the case of credit-control session.
コスト情報AVP（AVPコード423）はグループ化されたタイプであり、クレジット制御クライアントがエンドユーザーに透過的に転送できるサービスのコスト情報を返すために使用されます。含まれているユニット値AVPには、クレジット制御セッションの場合、価格調査の場合、または価格調査の場合、サービスのコスト見積もり（常にお金のタイプ）が含まれています。
The Currency-Code specifies in which currency the cost was given. The Cost-Unit specifies the unit when the service cost is a cost per unit (e.g., cost for the service is $1 per minute).
通貨コードは、通貨のコストが与えられたものを指定します。コストユニットは、サービスコストがユニットあたりのコストである場合にユニットを指定します（たとえば、サービスのコストは1分あたり1ドルです）。
When the Requested-Action AVP with value PRICE_ENQUIRY is included in the Credit-Control-Request command, the Cost-Information AVP sent in the succeeding Credit-Control-Answer command contains the cost estimation of the requested service, without any reservation being made.
Value Price_Enquiryを持つ要求されたアクションAVPがクレジットコントロールRequestコマンドに含まれている場合、後続のクレジットコントロール回答コマンドに送信されたコスト情報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 reservation into account.
CC-Request-Typeセットを備えたCC-Request-Typeセットを備えたクレジットコントロールアンスワークコマンドに含まれるコスト情報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を使用したクレジットコントロールアンスワークコマンドに含まれるコスト情報AVPは、event_RequestまたはTermination_Requestに設定されており、要求されたサービスの推定総コストが含まれています。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
次のように定義されています（RFC 3588 [Diambase]のグループ化されたAVP-DEFごと）：
Cost-Information ::= < AVP Header: 423 >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]
Unit-Value AVP is of type Grouped (AVP Code 445) and specifies the units as decimal value. The Unit-Value is a value with an exponent; i.e., Unit-Value = Value-Digits AVP * 10^Exponent. This representation avoids unwanted rounding off. For example, the value of 2,3 is represented as Value-Digits = 23 and Exponent = -1. The absence of the exponent part MUST be interpreted as an exponent equal to zero.
Unit-Value AVPはグループ化されたタイプ（AVPコード445）であり、ユニットを小数値として指定します。ユニット値は、指数を持つ値です。つまり、unit-value = value-digits avp * 10^exponent。この表現は、望ましくない丸めを避けます。たとえば、2,3の値は、値桁= 23および指数= -1として表されます。指数部分の欠如は、ゼロに等しい指数として解釈する必要があります。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
次のように定義されています（RFC 3588 [Diambase]のグループ化されたAVP-DEFごと）：
Unit-Value ::= < AVP Header: 445 >
{ Value-Digits }
[ Exponent ]
Exponent AVP is of type Integer32 (AVP Code 429) and contains the exponent value to be applied for the Value-Digit AVP within the Unit-Value AVP.
指数AVPはinteger32型（AVPコード429）であり、ユニット値AVP内のバリュー桁のAVPに適用される指数値が含まれています。
The Value-Digits AVP is of type Integer64 (AVP Code 447) and contains the significant digits of the number. If decimal values are needed to present the units, the scaling MUST be indicated with the related Exponent AVP. For example, for the monetary amount $ 0.05 the value of Value-Digits AVP MUST be set to 5, and the scaling MUST be indicated with the Exponent AVP set to -2.
Value-Digits AVPは、integer64（AVPコード447）のタイプで、数のかなりの数字が含まれています。ユニットを提示するために小数値が必要な場合は、関連する指数AVPでスケーリングを示す必要があります。たとえば、金銭的な金額$ 0.05の場合、Value -Digits AVPの値は5に設定する必要があり、スケーリングはExponent 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であり、通貨を含む通貨を含む通貨を指定する通貨コードが含まれています。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 when the service cost is a cost per unit (e.g., cost of the service is $1 per minute). The Cost-Unit can be minutes, hours, days, kilobytes, megabytes, etc.
コストユニットAVP（AVPコード424）はタイプのUTF8STRINGであり、エンドユーザーに人間の読み取り可能な文字列を表示するために使用されます。サービスコストがユニットあたりのコストである場合、コスト情報に該当するユニットを指定します（たとえば、サービスのコストは1分あたり1ドルです）。コストユニットは、数分、時間、日、キロバイト、メガバイトなどです。
The Credit-Control AVP (AVP Code 426) is of type Enumerated and MUST be included in AA requests when the service element has credit-control capabilities.
クレジット制御AVP（AVPコード426）は列挙されており、サービス要素にクレジット制御機能がある場合はAA要求に含める必要があります。
CREDIT_AUTHORIZATION 0 If the home Diameter AAA server determines that the user has prepaid subscription, this value indicates that the credit-control server MUST be contacted to perform the first interrogation. The value of the Credit-Control AVP MUST always be set to 0 in an AA request sent to perform the first interrogation and to initiate a new credit-control session.
Credit_Authorization 0ホーム直径AAAサーバーがユーザーにプリペイドサブスクリプションを持っていると判断した場合、この値は、最初の尋問を実行するためにクレジット制御サーバーに連絡する必要があることを示します。クレジット制御AVPの値は、最初の尋問を実行し、新しいクレジット制御セッションを開始するために送信されたAA要求で常に0に設定する必要があります。
RE_AUTHORIZATION 1 This value indicates to the Diameter AAA server that a credit-control session is ongoing for the subscriber and that the credit-control server MUST not be contacted. The Credit-Control AVP set to the value of 1 is to be used only when the first interrogation has been successfully performed and the credit-control session is ongoing (i.e., re-authorization triggered by Authorization-Lifetime). This value MUST NOT be used in an AA request sent to perform the first interrogation.
re_authorization 1この値は、AAAサーバーに、サブスクライバーがクレジット制御セッションが進行中であり、クレジット制御サーバーに連絡してはならないことを示します。1の値に設定されたクレジット制御AVPは、最初の尋問が正常に実行され、クレジット制御セッションが継続されている場合にのみ使用されます（つまり、承認系列ごとにトリガーされる再承認）。この値は、最初の尋問を実行するために送信されたAAリクエストで使用してはなりません。
The Credit-Control-Failure-Handling AVP (AVP Code 427) is of type Enumerated. The credit-control client uses information in this AVP to decide what to do if sending credit-control messages to the credit-control server has been, for instance, temporarily prevented due to a network problem. Depending on the service logic, the credit-control server can order the client to terminate the service immediately when there is a reason to believe that the service cannot be charged, or to try failover to an alternative server, if possible. Then the server could either terminate or grant the service, should the alternative connection also fail.
クレジット制御対策AVP（AVPコード427）は、列挙されています。クレジットコントロールクライアントは、このAVPの情報を使用して、クレジット制御メッセージをクレジット制御サーバーに送信した場合に何をすべきかを決定します。たとえば、ネットワークの問題により一時的に防止されています。サービスロジックに応じて、クレジットコントロールサーバーは、サービスを請求できないと信じる理由がある場合、または可能であれば代替サーバーにフェイルオーバーを試みる理由がある場合に、クライアントにサービスをすぐに終了するように命じます。代替接続も失敗した場合、サーバーはサービスを終了または許可することができます。
TERMINATE 0 When the Credit-Control-Failure-Handling AVP is set to TERMINATE, the service MUST only be granted for as long as there is a connection to the credit-control server. If the credit-control client does not receive any Credit-Control-Answer message within the Tx timer (as defined in section 13), the credit-control request is regarded as failed, and the end user's service session is terminated.
0を終了します。クレジット制御対処扱いのAVPが終了するように設定されている場合、クレジット制御サーバーへの接続がある限り、サービスは許可する必要があります。クレジット制御クライアントがTXタイマー内のクレジット制御応答メッセージを受け取らない場合（セクション13で定義）、クレジット制御要求は失敗と見なされ、エンドユーザーのサービスセッションは終了します。
This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server.
これは、AVPが承認またはクレジットコントロールサーバーからの返信に含まれていない場合のデフォルトの動作です。
CONTINUE 1 When the Credit-Control-Failure-Handling AVP is set to CONTINUE, the credit-control client SHOULD re-send the request to an alternative server in the case of transport or temporary failures, provided that a failover procedure is supported in the credit-control server and the credit-control client, and that an alternative server is available. Otherwise, the service SHOULD be granted, even if credit-control messages can't be delivered.
続行1クレジット制御対策AVPが継続するように設定されている場合、クレジット制御クライアントは、輸送または一時的な障害の場合に代替サーバーにリクエストを再送信する必要があります。クレジット制御サーバーとクレジット制御クライアント、および代替サーバーが利用可能であること。それ以外の場合は、クレジット制御メッセージを配信できなくても、サービスを許可する必要があります。
RETRY_AND_TERMINATE 2 When the Credit-Control-Failure-Handling AVP is set to RETRY_AND_TERMINATE, the credit-control client SHOULD re-send the request to an alternative server in the case of transport or temporary failures, provided that a failover procedure is supported in the credit-control server and the credit-control client, and that an alternative server is available. Otherwise, the service SHOULD not be granted when the credit-control messages can't be delivered.
retry_and_terminate 2クレジット制御対策処理AVPがretry_and_terminateに設定されている場合、クレジットコントロールクライアントは、輸送または一時的な障害の場合に代替サーバーにリクエストを再送信する必要があります。クレジット制御サーバーとクレジット制御クライアント、および代替サーバーが利用可能であること。それ以外の場合、クレジット制御メッセージを配信できない場合、サービスは許可されないでください。
The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is of type Enumerated. The credit-control client uses information in this AVP to decide what to do if sending credit-control messages (Requested-Action AVP set to DIRECT_DEBITING) to the credit-control server has been, for instance, temporarily prevented due to a network problem.
直接脱biting-failure処理AVP（AVPコード428）は列挙されています。クレジット制御クライアントは、このAVPの情報を使用して、クレジットコントロールメッセージ（requested-action avpがdirect_debitingに設定されている要求-アクションAVP）をクレジット制御サーバーに送信した場合に何をすべきかを決定します。たとえば、ネットワークの問題により一時的に防止されています。
TERMINATE_OR_BUFFER 0 When the Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER, the service MUST be granted for as long as there is a connection to the credit-control server. If the credit-control client does not receive any Credit-Control-Answer message within the Tx timer (as defined in section 13) the credit-control request is regarded as failed. The client SHOULD terminate the service if it can determine from the failed answer that units have not been debited. Otherwise the credit-control client SHOULD grant the service, store the request in application level non-volatile storage, and try to re-send the request. These requests MUST be marked as possible duplicates by setting the T-flag in the command header as described in [DIAMBASE] section 3.
terminate_or_buffer 0ダイレクトdebition-failure処理AVPがterminate_or_bufferに設定されている場合、クレジット制御サーバーへの接続がある限り、サービスは許可されなければなりません。クレジット制御クライアントがTXタイマー内のクレジット制御応答メッセージを受け取らない場合（セクション13で定義されているように）、クレジット制御要求は失敗と見なされます。クライアントは、ユニットが引き落とされていないという失敗した答えから決定できる場合、サービスを終了する必要があります。それ以外の場合、クレジット制御クライアントは、サービスを許可し、リクエストをアプリケーションレベルの不揮発性ストレージに保存し、リクエストを再送信しようとする必要があります。これらの要求は、[Diambase]セクション3で説明されているように、コマンドヘッダーにT-FLAGを設定することにより、可能な限り重複するものとしてマークする必要があります。
This is the default behavior if the AVP isn't included in the reply from the authorization server.
これは、AVPがAuthorization Serverからの返信に含まれていない場合のデフォルトの動作です。
CONTINUE 1 When the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the service SHOULD be granted, even if credit-control messages can't be delivered, and the request should be deleted.
続行1クレジット制御メッセージを配信できなくても、直接避妊対策AVPが継続するように設定され、サービスを許可する必要があり、リクエストを削除する必要があります。
Multiple-Services-Credit-Control AVP (AVP Code 456) is of type Grouped and contains the AVPs related to the independent credit-control of multiple services feature. Note that each instance of this AVP carries units related to one or more services or related to a single rating group.
複数のサービス - クレジット制御AVP（AVPコード456）はグループ化されたタイプで、複数のサービス機能の独立したクレジット制御に関連するAVPが含まれています。このAVPの各インスタンスは、1つ以上のサービスに関連するユニットまたは単一の評価グループに関連するユニットを搭載していることに注意してください。
The Service-Identifier and the Rating-Group AVPs are used to associate the granted units to a given service or rating group. If both the Service-Identifier and the Rating-Group AVPs are included, the target of the service units is always the service(s) indicated by the value of the Service-Identifier AVP(s). If only the Rating-Group-Id AVP is present, the Multiple-Services-Credit-Control AVP relates to all the services that belong to the specified rating group.
Service-IdentifierとRating-Group AVPは、付与されたユニットを特定のサービスまたは評価グループに関連付けるために使用されます。サービス - Identifierと評価グループAVPの両方が含まれている場合、サービスユニットのターゲットは、常にサービス識別子AVPの値によって示されるサービスです。評価-Group-ID AVPのみが存在する場合、複数のサービス - クレジット制御AVPは、指定された評価グループに属するすべてのサービスに関連しています。
The G-S-U-Pool-Reference AVP allows the server to specify a G-S-U-Pool-Identifier identifying a credit pool within which the units of the specified type are considered pooled. If a G-S-U-Pool-Reference AVP is present, then actual service units of the specified type MUST also be present. For example, if the G-S-U-Pool-Reference AVP specifies Unit-Type TIME, then the CC-Time AVP MUST be present.
G-S-U-Pool-Reference AVPを使用すると、サーバーは、指定されたタイプの単位がプールされていると見なされるクレジットプールを識別するG-S-U-Pool-Identifierを指定できます。G-S-U-Pool-Reference AVPが存在する場合、指定されたタイプの実際のサービスユニットも存在する必要があります。たとえば、G-S-U-Pool-Reference AVPがユニットタイプの時間を指定する場合、CC-TIME AVPが存在する必要があります。
The Requested-Service-Unit AVP MAY contain the amount of requested service units or the requested monetary value. It MUST be present in the initial interrogation and within the intermediate interrogations in which new quota is requested. If the credit-control client does not include the Requested-Service-Unit AVP in a request command, because for instance, it has determined that the end-user terminated the service, the server MUST debit the used amount from the user's account but MUST NOT return a new quota in the corresponding answer. The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY be present in an answer command as defined in sections 5.1.2 and 5.6 for the graceful service termination.
要求されたサービスユニットAVPには、要求されたサービスユニットの量または要求された金銭的価値が含まれる場合があります。それは、最初の尋問に存在し、新しいクォータが要求される中間尋問内に存在する必要があります。クレジット制御クライアントがリクエストコマンドに要求されたサービスユニットAVPを含めていない場合、たとえばエンドユーザーがサービスを終了したと判断したため、サーバーはユーザーのアカウントから使用額を借方にする必要がありますが、対応する回答で新しいクォータを返さないでください。優雅なサービス終了のために、セクション5.1.2および5.6で定義されているように、有効時刻、結果コード、および最終ユニット誘導AVPは、回答コマンドに存在する場合があります。
When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate instances of the Multiple-Services-Credit-Control AVP with the Granted-Service-Unit AVP associated to the same service-identifier and/or rating-group. Where the two quotas are associated to the same pool or to different pools, the credit pooling mechanism defined in section 5.1.2 applies. The Tariff-Change-Usage AVP MUST NOT be included in request commands to report used units before, and after tariff time change the Used-Service-Unit AVP MUST be used.
関税時間変化と関税の変更AVPの両方が存在する場合、サーバーには、同じサービス-Identifierに関連付けられた付与されたサービスユニットAVPを備えた複数サービス - クレジット制御AVPの2つの別々のインスタンスを含める必要がありますおよび/または評価グループ。2つのクォータが同じプールまたは異なるプールに関連付けられている場合、セクション5.1.2で定義されているクレジットプールメカニズムが適用されます。関税チェンジ - 使用されたAVPをリクエストコマンドに含めて、前に使用済みユニットを報告する必要はありません。また、関税時間変更後、使用済みのサービスユニットAVPを使用する必要があります。
A server not implementing the independent credit-control of multiple services functionality MUST treat the Multiple-Services-Credit-Control AVP as an invalid AVP.
複数のサービス機能の独立したクレジット制御を実装していないサーバーは、複数のサービスとクレジット制御AVPを無効なAVPとして扱う必要があります。
The Multiple-Services-Control AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
マルチサービスコントロールAVPは、次のように定義されています（RFC 3588のグループ化されたAVP-DEF [Diambase]）：
Multiple-Services-Credit-Control ::= < AVP Header: 456 >
[ Granted-Service-Unit ]
[ Requested-Service-Unit ]
*[ Used-Service-Unit ]
[ Tariff-Change-Usage ]
*[ Service-Identifier ]
[ Rating-Group ]
*[ G-S-U-Pool-Reference ]
[ Validity-Time ]
[ Result-Code ]
[ Final-Unit-Indication ]
*[ AVP ]
Granted-Service-Unit AVP (AVP Code 431) is of type Grouped and contains the amount of units that the Diameter credit-control client can provide to the end user until the service must be released or the new Credit-Control-Request must be sent. A client is not required to implement all the unit types, and it must treat unknown or unsupported unit types in the answer message as an incorrect CCA answer. In this case, the client MUST terminate the credit-control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.
付与されたサービスユニットAVP（AVPコード431）はグループ化されたタイプであり、サービスをリリースするか、新しいクレジット制御要求をリリースする必要があるまで、直径クレジットコントロールクライアントがエンドユーザーに提供できるユニットの量が含まれています。送信済み。クライアントはすべてのユニットタイプを実装する必要はなく、回答メッセージの不明またはサポートされていないユニットタイプを誤ったCCA回答として扱う必要があります。この場合、クライアントはクレジット制御セッションを終了し、AVP理由diameter_bad_answerを終了する原因で示す必要があります。
The Granted-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
付与されたサービスユニットAVPは、次のように定義されています（RFC 3588のグループ化されたAVP-DEF [Diambase]）：
Granted-Service-Unit ::= < AVP Header: 431 >
[ Tariff-Time-Change ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
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.
要求されたサービスユニットAVP（AVPコード437）はグループ化されたタイプで、直径クレジットコントロールクライアントによって指定された要求ユニットの量が含まれています。サーバーはすべてのユニットタイプを実装する必要はなく、不明またはサポートされていないユニットタイプを無効なAVPとして扱う必要があります。
The Requested-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
要求されたサービスユニットAVPは、次のように定義されます（RFC 3588のグループ化されたAVP-DEF [Diambase]）：
Requested-Service-Unit ::= < AVP Header: 437 >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
The Used-Service-Unit AVP is of type Grouped (AVP Code 446) and contains the amount of used units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended.
使用済みのサービスユニットAVPはグループ化されたタイプ（AVPコード446）であり、サービスがアクティブになった時点から、またはセッション中に暫定的な尋問が使用されている場合、前の測定ポイントから測定された使用ユニットの量が含まれています。終了しました。
The Used-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
使用済みサービスユニットAVPは、次のように定義されます（RFC 3588のグループ化されたAVP-DEF [Diambase]）：
Used-Service-Unit ::= < AVP Header: 446 >
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
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 defined in section 5. If a client does not support the tariff time change mechanism, it MUST treat Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In this case, the client terminates the credit-control session and indicates in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER.
関税変更メカニズムはクライアントとサーバーにとってオプションであり、セクション5で定義されている時間ベースのサービスには使用されません。誤ったCCA回答としての応答メッセージ。この場合、クライアントはクレジットコントロールセッションを終了し、終了原因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）は型signed32であり、要求、付与、または使用時間の長さを秒単位で示します。
The CC-Money AVP (AVP Code 413) is of type Grouped and specifies the monetary amount in the given currency. The Currency-Code AVP SHOULD be included. It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
CC-Money AVP（AVPコード413）はグループ化されたタイプで、指定された通貨の金額を指定します。通貨コードAVPを含める必要があります。次のように定義されています（RFC 3588 [Diambase]のグループ化された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）は、符号なし64であり、方向（送信または受信）に関係なく、要求、付与、または使用されたオクテットの総数が含まれています。
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）は、符号なし64であり、エンドユーザーから受信できる/受信できる要求、付与、または使用済みのオクテットの数が含まれています。
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）はsigned64のタイプで、エンドユーザーに送信される可能性のある要求、付与、または使用済みのオクテットの数が含まれています。
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固有のユニットAVP（AVPコード417）はタイプunsigned64であり、選択したサービスで指定されたサービス固有のユニット（例：イベント、ポイントの数、ポイント）の数を指定します。サービス固有のユニットは、常にサービス識別子AVPで識別されたサービスを指します（または、複数のサービス - クレジット制御AVPが使用されている場合の評価グループ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.
関税チェンジ - 使用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.
さらに、複数のサービス - クレジット制御AVPの一部として回答メッセージに存在する場合、このAVPは、関税変更イベントの前または後にユニットが使用されるように割り当てられるかどうかを定義します。
When the Tariff-Time-Change AVP is present, omission of this AVP in answer messages means that the single quota mechanism applies.
関税時間変化AVPが存在する場合、回答メッセージでこのAVPを省略することは、単一のクォータメカニズムが適用されることを意味します。
Tariff-Change-Usage can be one of the following:
関税チェンジ使用量は、次のいずれかです。
UNIT_BEFORE_TARIFF_CHANGE 0 When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of the units allocated for use before a tariff change occurs.
Unit_before_tariff_change 0複数のサービス - クレジット制御AVPに存在する場合、この値は、関税の変更が発生する前に使用するために割り当てられたユニットの量を示します。
When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used before a tariff change had occurred.
中古サービスユニットAVPに存在する場合、この値は、関税の変更が発生する前に使用されるリソースユニットの量を示します。
UNIT_AFTER_TARIFF_CHANGE 1 When present in the Multiple-Services-Credit-Control AVP, this value indicates the amount of the units allocated for use after a tariff change occurs.
unt_after_tariff_change 1複数のサービス - クレジット制御AVPに存在する場合、この値は、関税の変更が発生した後に使用するために割り当てられたユニットの量を示します。
When present in the Used-Service-Unit AVP, this value indicates the amount of resource units used after tariff change had occurred.
中古サービスユニットAVPに存在する場合、この値は、関税の変更が発生した後に使用されるリソースユニットの量を示します。
UNIT_INDETERMINATE 2 The used unit contains the amount of units that straddle the tariff change (e.g., the metering process reports to the credit-control client in blocks of n octets, and one block straddled the tariff change). This value is to be used only in the Used-Service-Unit AVP.
Unit_Indeterminate 2使用ユニットには、関税の変更にまたがるユニットの量が含まれています（たとえば、計量プロセスがNオクテットのブロックにあるクレジット制御クライアントに報告し、1つのブロックが関税の変更にまたがっていました）。この値は、使用されているサービスユニットAVPでのみ使用されます。
The Service-Identifier AVP is of type Unsigned32 (AVP Code 439) and contains the identifier of a service. The specific service the request relates to is uniquely identified by the combination of Service-Context-Id and Service-Identifier AVPs.
Service-Identifier AVPは、符号なし32（AVPコード439）のタイプで、サービスの識別子が含まれています。リクエストが関連する特定のサービスは、Service-Context-IDとService-Identifier AVPの組み合わせによって一意に識別されます。
A usage example of this AVP is illustrated in Appendix A (Flow IX).
このAVPの使用例は、付録A（フローIX）に示されています。
The Rating-Group AVP is of type Unsigned32 (AVP Code 432) and contains the identifier of a rating group. All the services subject to the same rating type are part of the same rating group. The specific rating group the request relates to is uniquely identified by the combination of Service-Context-Id and Rating-Group AVPs.
評価グループAVPは、sutsigned32（AVPコード432）タイプで、評価グループの識別子が含まれています。同じ評価タイプの対象となるすべてのサービスは、同じ評価グループの一部です。リクエストが関連する特定の評価グループは、Service-Context-IDと評価グループAVPの組み合わせによって一意に識別されます。
A usage example of this AVP is illustrated in Appendix A (Flow IX).
このAVPの使用例は、付録A（フローIX）に示されています。
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）は、グループ化されたタイプです。これは、クレジット制御応答メッセージで使用され、セッション内のクレジットプールに表示される付与されたサービスユニット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タイプのAVPは、クレジットがプールされるユニットのタイプを指定します。
The Unit-Value AVP specifies the multiplier, which converts between service units of type CC-Unit-Type and abstract service units within the credit pool (and thus to service units of any other service or rating group associated with the same pool).
Unit-Value AVPは、クレジットプール内のタイプCCユニットタイプのサービスユニットと抽象サービスユニットのサービスユニット（したがって、同じプールに関連付けられている他のサービスまたは格付けグループのサービスユニット）を変換する乗数を指定します。
The G-S-U-Pool-Reference AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
G-S-U-Pool-Reference AVPは、次のように定義されます（RFC 3588のグループ化されたAVP-DEF [Diambase]）：
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）は、符号なし32であり、セッション内のクレジットプールを識別します。
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タイプのAVPに対して定義されています。
TIME 0
MONEY 1
TOTAL-OCTETS 2
INPUT-OCTETS 3
OUTPUT-OCTETS 4
SERVICE-SPECIFIC-UNITS 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 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.
有効期間AVPは、sotined32（AVPコード448）のタイプです。クレジット制御サーバーからクレジット制御クライアントに送信されます。AVPには、付与されたサービスユニットの有効期間が含まれています。有効期間の測定は、このAVPを含むクレジット制御応答メッセージの受信時に開始されます。このAVPで指定された有効期間内に付与されたサービスユニットが消費されていない場合、クレジット制御クライアントは、CC-Request-Typeがupdate_requestに設定されているため、クレジット制御メッセージをサーバーに送信する必要があります。有効期間AVPの値フィールドは数秒で与えられます。
The Validity-Time AVP is also used for the graceful service termination (see section 5.6) to indicate to the credit-control client how long the subscriber is allowed to use network resources after the specified action (i.e., REDIRECT or RESTRICT_ACCESS) started. When the Validity-Time elapses, a new intermediate interrogation is sent to the server.
有効期間AVPは、優雅なサービス終了にも使用され（セクション5.6を参照）、クレジットコントロールクライアントに、指定されたアクション（つまり、リダイレクトまたは制限_Access）が開始された後、サブスクライバーがネットワークリソースを使用できる期間を示します。有効期間が経過すると、新しい中間尋問がサーバーに送信されます。
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).
最終ユニット誘導AVP（AVPコード430）はグループ化されたタイプで、クレジット制御またはAAの回答に付与されたサービスユニットAVPがサービスの最終ユニットを含むことを示しています。これらのユニットが期限切れになった後、直径クレジットコントロールクライアントは、最終ユニットアクション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.
クレジットコントロール回答で複数のユニットタイプが受信された場合、最初に有効期限が切れたユニットタイプにより、クレジット制御クライアントが指定されたアクションを実行するようになります。
In the first interrogation, the Final-Unit-Indication AVP with Final-Unit-Action REDIRECT or RESTRICT_ACCESS can also be present with no Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA answer. This indicates to the Diameter credit-control client to execute the specified action immediately. If the home service provider policy is to terminate the service, naturally, the server SHOULD return the appropriate transient failure (see section 9.1) in order to implement the policy-defined action.
最初の尋問では、最終ユニットアクションリダイレクトまたは制限_Accessを備えた最終ユニット指定AVPは、クレジット制御またはAAの回答で許可されたサービスユニットAVPなしで存在することもできます。これは、指定されたアクションをすぐに実行するために、直径クレジットコントロールクライアントに示されます。ホームサービスプロバイダーのポリシーがサービスを終了することである場合、当然、サーバーはポリシー定義のアクションを実装するために適切な過渡障害（セクション9.1を参照）を返す必要があります。
The Final-Unit-Action AVP defines the behavior of the service element when the user's account cannot cover the cost of the service and MUST always be present if the Final-Unit-Indication AVP is included in a command.
ファイナルユニットアクションAVPは、ユーザーのアカウントがサービスのコストをカバーできない場合にサービス要素の動作を定義し、最終ユニット指定AVPがコマンドに含まれている場合は常に存在する必要があります。
If the Final-Unit-Action AVP is set to TERMINATE, no other AVPs MUST be present.
最終ユニットアクションAVPが終了するように設定されている場合、他のAVPを存在する必要はありません。
If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server AVP MUST be present. The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is also allowed to access other services that are not accessible through the address given in the Redirect-Server AVP.
最終ユニットアクションAVPが少なくともリダイレクトをリダイレクトするように設定されている場合、リダイレクトサーバーAVPが存在する必要があります。Redirect-Server AVPで指定されたアドレスからアクセスできない他のサービスにもアクセスできる場合、制限フィルタールールAVPまたはフィルターID AVPは、クレジット制御応答メッセージに存在する場合があります。
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.
最終ユニットアクションAVPが制限_Accessに設定されている場合、制限フィルタールールAVPまたはフィルターID AVPのいずれかが存在するはずです。
The Filter-Id AVP is defined in [NASREQ]. The Filter-Id AVP can be used to reference an IP filter list installed in the access device by means other than the Diameter credit-control application, e.g., locally configured or configured by another entity.
Filter-ID AVPは[Nasreq]で定義されています。Filter-ID AVPを使用して、他のエンティティによってローカルで構成または構成された直径クレジットコントロールアプリケーション以外の手段でアクセスデバイスにインストールされているIPフィルターリストを参照できます。
The Final-Unit-Indication AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
最終ユニット誘導AVPは、次のように定義されます（RFC 3588のグループ化されたAVP-DEF [Diambase]）：
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.
最終ユニットアクションAVP（AVPコード449）は列挙されており、ユーザーのアカウントがサービスコストをカバーできない場合にアクションを取得するアクションをクレジット制御クライアントに示します。
The Final-Unit-Action can be one of the following:
最終ユニットアクションは、次のいずれかです。
TERMINATE 0 The credit-control client MUST terminate the service session. This is the default handling, applicable whenever the credit-control client receives an unsupported Final-Unit-Action value, and it MUST be supported by all the Diameter credit-control client implementations conforming to this specification.
0を終了するクレジット制御クライアントは、サービスセッションを終了する必要があります。これは、クレジットコントロールクライアントがサポートされていない最終ユニットアクション値を受信したときはいつでも適用されるデフォルトの処理であり、この仕様に準拠したすべての直径クレジット制御クライアントの実装によってサポートする必要があります。
REDIRECT 1 The service element MUST redirect the user to the address specified in the Redirect-Server-Address AVP. The redirect action is defined in section 5.6.2.
リダイレクト1サービス要素は、リダイレクトサーバーアドレスAVPで指定されたアドレスにユーザーをリダイレクトする必要があります。リダイレクトアクションは、セクション5.6.2で定義されています。
RESTRICT_ACCESS 2 The access device MUST restrict the user access according to the IP packet filters defined in the Restriction-Filter-Rule AVP or according to the IP packet filters identified by the Filter-Id AVP. All the packets not matching the filters MUST be dropped (see section 5.6.3).
Restrict_Access 2アクセスデバイスは、制限フィルタールールAVPで定義されたIPパケットフィルター、またはFilter-ID AVPによって識別されたIPパケットフィルターに従って、ユーザーアクセスを制限する必要があります。フィルターを一致させないすべてのパケットをドロップする必要があります（セクション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.
制限フィルタールールAVP（AVPコード438）はタイプIPFilterruleであり、許可されたサービスユニットがなくてもアクセスしやすいサービスに対応するフィルタールールを提供します。アクセスデバイスは、サブスクライバーの指定されたフィルタールールを構成する必要があり、これらのフィルターと一致しないすべてのパケットをドロップする必要があります。ゼロ、1つ、またはそれ以上のAVPは、クレジット制御応答メッセージまたはAA回答メッセージに存在する場合があります。
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サーバー）が含まれています。。最終ユニットアクションAVPがリダイレクトに設定されている場合、存在する必要があります。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
次のように定義されています（RFC 3588 [Diambase]のグループ化された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に与えられたアドレスのアドレスタイプを定義します。
The address type can be one of the following:
アドレスタイプは、次のいずれかです。
IPv4 Address 0 The address type is in the form of "dotted-decimal" IPv4 address, as defined in [IPv4].
IPv4アドレス0アドレスタイプは、[IPv4]で定義されているように、「点線式」IPv4アドレスの形式です。
IPv6 Address 1 The address type is in the form of IPv6 address, as defined in [IPv6Addr]. The address is a text representation of the address in either the preferred or alternate text form [IPv6Addr]. Conformant implementations MUST support the preferred form and SHOULD support the alternate text form for IPv6 addresses.
IPv6アドレス1アドレスタイプは、[IPv6Addr]で定義されているIPv6アドレスの形式です。アドレスは、優先または代替のテキストフォーム[IPv6Addr]のいずれかのアドレスのテキスト表現です。コンフォーマントの実装は、優先フォームをサポートする必要があり、IPv6アドレスの代替テキストフォームをサポートする必要があります。
URL 2 The address type is in the form of Uniform Resource Locator, as defined in [URL].
URL 2アドレスタイプは、[URL]で定義されているように、均一なリソースロケーターの形式です。
SIP URI 3 The address type is in the form of SIP Uniform Resource Identifier, as defined in [SIP].
SIP URI 3アドレスタイプは、[SIP]で定義されているように、SIPユニフォームリソース識別子の形式です。
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）は列挙されており、直径クレジットコントロールクライアントが（サブ）セッション内で複数のサービスを独立して処理できるかどうかを示します。このAVPがないことは、複数のサービスの独立した信用制御がサポートされていないことを意味します。
A server not implementing the independent credit-control of multiple services MUST treat the Multiple-Services-Indicator AVP as an invalid AVP.
複数のサービスの独立したクレジット制御を実装していないサーバーは、複数のサービスインディケーターAVPを無効なAVPとして扱う必要があります。
The following values are defined for the Multiple-Services-Indicator AVP:
以下の値は、複数のサービス指示者AVPに対して定義されています。
MULTIPLE_SERVICES_NOT_SUPPORTED 0 Client does not support independent credit-control of multiple services within a (sub-)session.
Multhip_services_not_supported 0クライアントは、（サブ）セッション内で複数のサービスの独立したクレジット制御をサポートしていません。
MULTIPLE_SERVICES_SUPPORTED 1 Client supports independent credit-control of multiple services within a (sub-)session.
Multiple_Services_Supported 1クライアントは、（サブ）セッション内で複数のサービスの独立したクレジット制御をサポートします。
The Requested-Action AVP (AVP Code 436) is of type Enumerated and contains the requested action being sent by Credit-Control-Request command where the CC-Request-Type is set to EVENT_REQUEST. The following values are defined for the Requested-Action AVP:
要求されたアクションAVP（AVPコード436）は列挙されており、CC-Request-Typeがevent_Requestに設定されているクレジット制御コマンドによって送信される要求されたアクションが含まれています。次の値は、要求されたアクションAVPに対して定義されています。
DIRECT_DEBITING 0 This indicates a request to decrease the end user's account according to information specified in the Requested-Service-Unit AVP and/or Service-Identifier AVP (additional rating information may be included in service-specific AVPs or in the Service-Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-Control-Answer command contains the debited units.
direct_debiting 0これは、要求されたサービスユニットAVPおよび/またはサービス識別子AVPで指定された情報に従ってエンドユーザーのアカウントを減らすリクエストを示します（追加の評価情報は、サービス固有のAVPまたはサービスパラメーター - に含まれる場合があります。情報avp）。クレジットコントロール回答コマンドの付与されたサービスユニットAVPには、引き落とされたユニットが含まれています。
REFUND_ACCOUNT 1 This indicates a request to increase the end user's account according to information specified in the Requested-Service-Unit AVP and/or Service-Identifier AVP (additional rating information may be included in service-specific AVPs or in the Service-Parameter-Info AVP). The Granted-Service-Unit AVP in the Credit-Control-Answer command contains the refunded units.
Refund_Account 1これは、要求されたサービスユニットAVPおよび/またはService-Identifier AVPで指定された情報に従って、エンドユーザーのアカウントを増やすリクエストを示しています（追加の評価情報は、サービス固有のAVPまたはサービスパラメーター - に含まれる場合があります。情報avp）。クレジットコントロール回答コマンドの付与されたサービスユニットAVPには、返金されたユニットが含まれています。
CHECK_BALANCE 2 This indicates a balance check request. In this case, the checking of the account balance is done without any credit reservation from the account. The Check-Balance-Result AVP in the Credit-Control-Answer command contains the result of the balance check.
check_balance 2これは、残高チェックリクエストを示します。この場合、口座残高のチェックは、アカウントからのクレジット留保なしに行われます。クレジットコントロール回答コマンドのチェックバランス応答AVPには、残高チェックの結果が含まれています。
PRICE_ENQUIRY 3 This indicates a price enquiry request. In this case, neither checking of the account balance nor reservation from the account will be done; only the price of the service will be returned in the Cost-Information AVP in the Credit-Control-Answer Command.
Price_enquiry 3これは、価格照会リクエストを示しています。この場合、口座残高のチェックも口座からの予約も行われません。クレジット制御コマンドのコスト情報AVPで、サービスの価格のみが返品されます。
The Service-Context-Id AVP is of type UTF8String (AVP Code 461) and contains a unique identifier of the Diameter credit-control service specific document that applies to the request (as defined in section 4.1.2). This is an identifier allocated by the service provider, by the service element manufacturer, or by a standardization body, and MUST uniquely identify a given Diameter credit-control service specific document. The format of the Service-Context-Id is:
Service-Context-ID AVPは型UTF8STRING（AVPコード461）であり、リクエストに適用される直径クレジットコントロールサービス固有のドキュメントの一意の識別子（セクション4.1.2で定義）が含まれています。これは、サービスプロバイダー、サービス要素メーカー、または標準化機関によって割り当てられた識別子であり、特定の直径のクレジットコントロールサービス固有のドキュメントを一意に識別する必要があります。service-context-idの形式は次のとおりです。
"service-context" "@" "domain"
「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 FQDN of the service provider (e.g., provider.example.com) or of the vendor (e.g., vendor.example.com) if the identifier is allocated by a private entity.
「ドメイン」は、Service-Context-IDを割り当てたエンティティを表します。識別子が標準化本体によって割り当てられている場合、またはサービスプロバイダー（Provider.example.comなど）またはベンダー（例：vendor.example.com）識別子が民間エンティティによって割り当てられている場合。
This AVP SHOULD be placed as close to the Diameter header as possible.
このAVPは、可能な限り直径ヘッダーに近づける必要があります。
Service-specific documents that are for private use only (i.e., to one provider's own use, where no interoperability is deemed useful) may define private identifiers without need of coordination. However, when interoperability is wanted, coordination of the identifiers via, for example, publication of an informational RFC is RECOMMENDED in order to make Service-Context-Id globally available.
プライベート使用のみを対象としたサービス固有のドキュメント（つまり、1つのプロバイダー自身の使用、相互運用性が有用であるとみなされない場合）は、調整を必要とせずにプライベート識別子を定義する場合があります。ただし、相互運用性が必要な場合、たとえば、情報コンテキストIDをグローバルに利用できるようにするために、情報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）はグループ化されたタイプで、価格の計算または評価に使用されるサービス固有の情報が含まれています。Service-Parameter-Type AVPはサービスパラメータータイプを定義し、Service-Parameter-Value AVPにはパラメーター値が含まれます。これらのAVPの実際の内容は、このドキュメントの範囲内ではなく、別の直径アプリケーション、他の標準化機関によって書かれた標準、またはサービス固有のドキュメントで定義する必要があります。
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.
不明なサービス要求（例：不明なサービスパラメータータイプなど）の場合、対応する回答メッセージには、エラーコードDiameter_rating_failedが含まれている必要があります。このエラーを使用したクレジット制御応答メッセージには、障害を引き起こすサービスパラメーターINFO AVPを含む1つまたは複数の失敗AVP AVPを含める必要があります。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
次のように定義されています（RFC 3588 [Diambase]のグループ化された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., 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は、sutsigned32（AVPコード441）タイプで、サービスイベント固有のパラメーターのタイプを定義します（たとえば、エンドユーザーの場所またはサービス名になります）。異なるパラメーターとそのタイプはサービス固有であり、これらのパラメーターの意味はこのドキュメントでは定義されていません。Service-Context-ID（つまり、サービス固有のドキュメントの一意の識別子）を割り当てる人は、サービスのサービスパラメーター型値を割り当て、特定のサービス内でのユニーク性を確保することも責任を負います。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は、タイプのオクテットストリング（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.
サブスクリプションID AVP（AVPコード443）は、エンドユーザーのサブスクリプションを識別するために使用され、グループ化されたタイプです。サブスクリプションID AVPには、識別子を保持するサブスクリプションID-DATA AVPと、識別子タイプを定義するサブスクリプションIDタイプAVPが含まれています。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
次のように定義されています（RFC 3588 [Diambase]のグループ化された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.
サブスクリプションIDタイプAVP（AVPコード450）は列挙されており、サブスクリプションID AVPによってどのタイプの識別子が運ばれるかを決定するために使用されます。
This specification defines the following subscription identifiers. However, new Subscription-Id-Type values can be assigned by an IANA designated expert, as defined in section 12. A server MUST implement all the Subscription-Id-Types required to perform credit authorization for the services it supports, including possible future values. Unknown or unsupported Subscription-Id-Types MUST be treated according to the 'M' flag rule, as defined in [DIAMBASE].
この仕様は、次のサブスクリプション識別子を定義します。ただし、セクション12で定義されているように、新しいサブスクリプションIDタイプの値は、IANA指定の専門家によって割り当てることができます。サーバーは、可能な将来の値を含む、サポートするサービスの信用承認を実行するために必要なすべてのサブスクリプションIDタイプを実装する必要があります。。[Diambase]で定義されているように、未知のまたはサポートされていないサブスクリプションIDタイプは、「M」フラグルールに従って処理する必要があります。
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].
end_user_e164 0識別子は、[e164]および[ce164]で定義されているITU-T E.164番号付け計画に従って、国際的なE.164形式（例：MSISDN）にあります。
END_USER_IMSI 1 The identifier is in international IMSI format, according to the ITU-T E.212 numbering plan as defined in [E212] and [CE212].
end_user_imsi 1識別子は、[E212]および[CE212]で定義されているITU-T E.212番号付け計画に従って、国際的なIMSI形式です。
END_USER_SIP_URI 2 The identifier is in the form of a SIP URI, as defined in [SIP].
end_user_sip_uri 2識別子は、[sip]で定義されているように、sip uriの形式です。
END_USER_NAI 3 The identifier is in the form of a Network Access Identifier, as defined in [NAI].
end_user_nai 3識別子は、[nai]で定義されているように、ネットワークアクセス識別子の形式です。
END_USER_PRIVATE 4 The Identifier is a credit-control server private identifier.
end_user_private 4識別子はクレジット制御サーバーのプライベート識別子です。
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.
サブスクリプションID-DATA AVP（AVPコード444）は、エンドユーザーを識別するために使用され、UTF8STRINGのタイプです。サブスクリプションIDタイプのAVPは、使用される識別子のタイプを定義します。
The User-Equipment-Info AVP (AVP Code 458) is of type Grouped and allows the credit-control client to indicate the identity and capability of the terminal the subscriber is using for the connection to network.
User-Equipment-INFO AVP（AVPコード458）はグループ化されたタイプであり、クレジット制御クライアントがサブスクライバーがネットワークへの接続に使用している端末のIDと機能を示すことができます。
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
次のように定義されています（RFC 3588 [Diambase]のグループ化された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）、ユーザーエクイペメントInfo-Value AVPに含まれるユーザー機器情報のタイプを定義します。
This specification defines the following user equipment types. However, new User-Equipment-Info-Type values can be assigned by an IANA designated expert, as defined in section 12.
この仕様では、次のユーザー機器の種類を定義します。ただし、セクション12で定義されているように、IANA指定の専門家によって、新しいユーザーEquipment-INFO-Type値が割り当てることができます。
IMEISV 0 The identifier contains the International Mobile Equipment Identifier and Software Version in the international IMEISV format according to 3GPP TS 23.003 [3GPPIMEI].
IMEISV 0識別子には、3GPP TS 23.003 [3GPPIMEI]に従って、国際IMEISV形式の国際モバイル機器識別子識別子とソフトウェアバージョンが含まれています。
MAC 1 The 48-bit MAC address is formatted as described in [RAD802.1X].
MAC 1 [RAD802.1x]で説明されているように、48ビットMACアドレスがフォーマットされています。
EUI64 2 The 64-bit identifier used to identify hardware instance of the product, as defined in [EUI64].
EUI64 2 [EUI64]で定義されているように、製品のハードウェアインスタンスを識別するために使用される64ビット識別子。
MODIFIED_EUI64 3 There are a number of types of terminals that have identifiers other than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can be converted to modified EUI-64 format as described in [IPv6Addr] or by using some other methods referred to in the service-specific documentation.
Modified_eui64 3 IMEI、IEEE 802 Mac、またはEUI-64以外の識別子を持つ端子の種類が多数あります。これらの識別子は、[IPV6ADDR]で説明されているように、またはサービス固有のドキュメントで言及されている他の方法を使用して、変更された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）は、タイプのオクテットストリングです。ユーザーEquipment-INFO-Type AVPは、使用される識別子のタイプを定義します。
This section defines new Result-Code AVP [DIAMBASE] values that must be supported by all Diameter implementations that conform to this specification.
このセクションでは、この仕様に準拠するすべての直径の実装でサポートする必要がある新しい結果コードAVP [Diambase]値を定義します。
The Credit-Control-Answer message includes the Result-Code AVP, which may indicate that an error was present in the Credit-Control-Request message. A rejected Credit-Control-Request message SHOULD cause the user's session to be terminated.
クレジット制御応答メッセージには、結果コードAVPが含まれています。これは、クレジット制御要求メッセージにエラーが存在していることを示している場合があります。拒否されたクレジット制御要求メッセージは、ユーザーのセッションを終了させるはずです。
Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but that the request MAY be able to be satisfied in the future.
過渡障害カテゴリに該当するエラーは、受け取った時点でリクエストが満たされなかったが、リクエストが将来満たされる可能性があることをピアに通知するために使用されます。
DIAMETER_END_USER_SERVICE_DENIED 4010 The credit-control server denies the service request due to service restrictions. If the CCR contained used-service-units, they are deducted, if possible.
diameter_end_user_service_denied 4010クレジット制御サーバーは、サービスの制限によりサービス要求を拒否します。CCRに中古サービスユニットが含まれている場合、可能であれば控除されます。
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011 The credit-control server determines that the service can be granted to the end user but that no further credit-control is needed for the service (e.g., service is free of charge).
diameter_credit_control_not_applible 4011クレジット制御サーバーは、サービスをエンドユーザーに付与できるが、サービスにはそれ以上のクレジット制御は必要ないと判断します（たとえば、サービスは無料です）。
DIAMETER_CREDIT_LIMIT_REACHED 4012 The credit-control server denies the service request because the end user's account could not cover the requested service. If the CCR contained used-service-units they are deducted, if possible.
diameter_credit_limit_reached 4012エンドユーザーのアカウントが要求されたサービスをカバーできなかったため、クレジット制御サーバーはサービス要求を拒否します。CCRに使用済みサービスユニットが含まれている場合、可能であれば控除されます。
Errors that fall within the permanent failure category are used to inform the peer that the request failed and should not be attempted again.
永続的な障害カテゴリ内にあるエラーは、リクエストが失敗し、再度試行すべきではないことをピアに通知するために使用されます。
DIAMETER_USER_UNKNOWN 5030 The specified end user is unknown in the credit-control server.
diameter_user_unknown 5030指定されたエンドユーザーは、クレジット制御サーバーでは不明です。
DIAMETER_RATING_FAILED 5031 This error code is used to inform the credit-control client that the credit-control server cannot rate the service request due to insufficient rating input, an incorrect AVP combination, or an AVP or an AVP value that is not recognized or supported in the rating. The Failed-AVP AVP MUST be included and contain a copy of the entire AVP(s) that could not be processed successfully or an example of the missing AVP complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeros.
diameter_rating_failed 5031このエラーコードは、クレジットコントロールサーバーが、評価入力不足、誤ったAVPの組み合わせ、またはAVPまたはAVP値が認識またはサポートされていないAVPまたはAVP値のためにサービス要求を評価できないことをクレジット制御クライアントに通知するために使用されます。評価。故障したAVP AVPを含めて、正常に処理できなかったAVP全体のコピーを含める必要があります。欠落しているAVPの値フィールドは、正しい最小長であり、ゼロを含む必要があります。
The following table presents the AVPs defined in this document and specifies in which Diameter messages they MAY or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
次の表は、このドキュメントで定義されているAVPを示し、存在する場合と存在しない直径メッセージを指定します。グループ化された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. 1+ At least one instance of the AVP MUST be present in the message.
0 AVPがメッセージに存在してはなりません。AVPの0ゼロ以上のインスタンスがメッセージに存在する場合があります。AVPの0-1インスタンスまたは1つのインスタンスがメッセージに存在する場合があります。AVPに複数のインスタンスがある場合、これはエラーと見なされます。1 AVPの1つのインスタンスがメッセージに存在する必要があります。1 AVPの少なくとも1つのインスタンスがメッセージに存在する必要があります。
The table in this section is used to represent which credit-control applications specific AVPs defined in this document are to be present in the credit-control messages.
このセクションの表は、このドキュメントで定義されているクレジット制御アプリケーション固有のAVPがクレジット制御メッセージに存在するかを表すために使用されます。
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | CCR | CCA |
------------------------------|-----+-----+
Acct-Multi-Session-Id | 0-1 | 0-1 |
Auth-Application-Id | 1 | 1 |
CC-Correlation-Id | 0-1 | 0 |
CC-Session-Failover | 0 | 0-1 |
CC-Request-Number | 1 | 1 |
CC-Request-Type | 1 | 1 |
CC-Sub-Session-Id | 0-1 | 0-1 |
Check-Balance-Result | 0 | 0-1 |
Cost-Information | 0 | 0-1 |
Credit-Control-Failure- | 0 | 0-1 |
Handling | | |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Direct-Debiting-Failure- | 0 | 0-1 |
Handling | | |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0+ |
Final-Unit-Indication | 0 | 0-1 |
Granted-Service-Unit | 0 | 0-1 |
Multiple-Services-Credit- | 0+ | 0+ |
Control | | |
Multiple-Services-Indicator | 0-1 | 0 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ |
Redirect-Host | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 |
Requested-Action | 0-1 | 0 |
Requested-Service-Unit | 0-1 | 0 |
Route-Record | 0+ | 0+ |
Result-Code | 0 | 1 |
Service-Context-Id | 1 | 0 |
Service-Identifier | 0-1 | 0 |
Service-Parameter-Info | 0+ | 0 |
Session-Id | 1 | 1 |
Subscription-Id | 0+ | 0 |
Termination-Cause | 0-1 | 0 |
User-Equipment-Info | 0-1 | 0 |
Used-Service-Unit | 0+ | 0 |
User-Name | 0-1 | 0-1 |
Validity-Time | 0 | 0-1 |
------------------------------|-----+-----+
This section defines AVPs that are specific to the Diameter credit-control application and that MAY be included in the Diameter Re-Auth-Request/Answer (RAR/RAA) message [DIAMBASE].
このセクションでは、直径クレジットコントロールアプリケーションに固有のAVPを定義し、直径Reauth-Request/Answer（RAR/RAA）メッセージ[Diambase]に含まれる場合があります。
Re-Auth-Request/Answer command MAY include the following additional AVPs:
Reauth-Request/Answerコマンドには、以下の追加の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 inter-working model; that is, a message translation between a RADIUS based prepaid solution and a Diameter credit-control application. A complete description of the protocol translations between RADIUS and the Diameter credit-control application is beyond the scope of this specification and SHOULD be addressed in another appropriate document, such as the RADIUS prepaid specification.
このセクションでは、直径クレジットコントロール/RADIUSプリペイドインターワーキングモデルの基本原則を定義します。つまり、半径ベースのプリペイドソリューションと直径のクレジット制御アプリケーションとの間のメッセージ変換です。RADIUSと直径のクレジットコントロールアプリケーション間のプロトコル翻訳の完全な説明は、この仕様の範囲を超えており、RADIUSプリペイド仕様などの別の適切なドキュメントで説明する必要があります。
The Diameter credit-control architecture may have a Translation Agent capable of translation between RADIUS prepaid and Diameter credit-control protocols. An AAA server (usually the home AAA server) may act as a Translation Agent and as a Diameter credit-control client for service elements that use credit-control mechanisms other than Diameter credit control for instance, RADIUS prepaid. In this case, the home AAA server contacts the Diameter credit-control server as part of the authorization process. The interworking architecture is illustrated in Figure 7, and interworking flow in Figure 8. In a roaming situation the service element (e.g., the NAS) may be located in the visited network, and a visited AAA server is usually contacted. The visited AAA server connects then to the home AAA server.
直径のクレジットコントロールアーキテクチャには、Radius PrepaidとDiameter Credit-Controlプロトコルの間に翻訳できる翻訳エージェントがある場合があります。AAAサーバー（通常はHome AAAサーバー）は、翻訳エージェントとして、およびたとえば直径クレジットコントロール以外のクレジット制御メカニズムを使用するサービス要素の直径クレジットコントロールクライアントとして機能する場合があります。この場合、Home AAAサーバーは、認証プロセスの一部として直径クレジットコントロールサーバーに連絡します。インターワーキングアーキテクチャを図7に示し、図8のインターワーキングフローを示します。ローミングの状況では、サービス要素（NASなど）が訪問されたネットワークに配置され、訪問されたAAAサーバーに通常接触します。訪問したAAAサーバーは、ホームAAAサーバーに接続します。
RADIUS Prepaid
+--------+ +---------+ protocol +------------+ +--------+
| End |<----->| Service |<---------->| Home AAA | |Business|
| User | | Element | | Server | |Support |
+--------+ +-->| | |+----------+|->|System |
| +---------+ ||CC Client || | |
| |+----------+| | |
+--------+ | +------^-----+ +----^---+
| End |<--+ Credit-Control | |
| User | Protocol | |
+--------+ +-------V--------+ |
|Credit-Control |----+
| Server |
+----------------+
Figure 7: Credit-control architecture with service element containing translation agent, translating RADIUS prepaid to Diameter credit-control protocol
図7：翻訳エージェントを含むサービス要素を備えたクレジットコントロールアーキテクチャ、Radius Prepaidを直径クレジットコントロールプロトコルに翻訳する
When the AAA server acting as a Translation Agent receives an initial RADIUS Access-Request message from service element (e.g., NAS access), it performs regular authentication and authorization. If the RADIUS Access-Request message indicates that the service element is capable of credit-control, and if the home AAA server finds that the subscriber is a prepaid subscriber, then a Diameter credit-control request SHOULD be sent toward the credit-control server to perform credit authorization and to establish a credit-control session. After the Diameter credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account, the reserved quota is returned to the home AAA server in the Diameter Credit-Control-Answer. Then the home AAA server sends the reserved quota to the service element in the RADIUS Access-Accept.
翻訳エージェントとして機能するAAAサーバーが、サービス要素（NASアクセスなど）から初期RADIUSアクセスリケストメッセージを受信すると、定期的な認証と承認を実行します。RADIUS Access-Requestメッセージは、サービス要素がクレジット制御できることを示し、Home AAAサーバーがサブスクライバーがプリペイドサブスクライバーであることを発見した場合、直径のクレジットコントロール要求はクレジットコントロールサーバーに送信する必要があります信用承認を実施し、クレジット制御セッションを確立する。直径クレジットコントロールサーバーがエンドユーザーのアカウントの残高をチェックし、サービスを評価し、クレジットをエンドユーザーのアカウントから留保した後、予約されたクォータは、直径クレジットコントロール回答のホームAAAサーバーに返送されます。次に、Home AAAサーバーは、RADIUS Access-Acceptのサービス要素に予約されたクォータを送信します。
At the expiry of the allocated quota, the service element sends a new RADIUS Access-Request containing the units used this far to the home AAA server. The home AAA server shall map a RADIUS Access-Request containing the reported units to the Diameter credit-control server in a Diameter Credit-Control-Request (UPDATE_REQUEST). The Diameter credit-control server debits the used units from the end user's account and allocates a new quota that is returned to the home AAA server in the Diameter Credit-Control-Answer. The quota is 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.
割り当てられたクォータの有効期限が切れ、サービス要素は、Home AAAサーバーに使用されるユニットを含む新しいRADIUS ACCESS-REQUESTを送信します。ホームAAAサーバーは、直径クレジットコントロールレクエスト（update_request）の直径クレジットコントロールサーバーに報告されたユニットを含むRADIUSアクセスリケストをマッピングするものとします。直径のクレジットコントロールサーバーは、エンドユーザーのアカウントから使用済みユニットを借方化し、直径のクレジットコントロール回答のホームAAAサーバーに返される新しいクォータを割り当てます。クォータは、RADIUS Access-Acceptのサービス要素に転送されます。エンドユーザーがサービスを終了するとき、またはクォータ全体が使用されたときに、サービス要素がRADIUSアクセスリケストを送信します。使用済みのユニットをエンドユーザーのアカウントから引き落とし、クレジット制御セッションを停止するために、Home AAAサーバーは直径クレジットコントロールRequest（Termination_Request）をクレジットコントロールサーバーに送信します。Diameter Credit-Control Serverは、Home AAAサーバーに直径クレジットコントロールを送信することにより、セッション終了を認めます。RADIUS ACCESS-ACCEPTはNASに送信されます。
A following diagram illustrates a RADIUS prepaid - Diameter credit-control interworking sequence.
次の図は、半径のプリペイド - 直径クレジットコントロールインターワーキングシーケンスを示しています。
Service Element Translation Agent
(e.g., NAS) (CC Client) CC Server
| Access-Request | |
|----------------------->| |
| | CCR (initial) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
| (Used-Units) | |
|----------------------->| |
| | CCR (update, |
| | Used-Units) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
|----------------------->| |
| | CCR (terminate, |
| | Used-Units) |
| |----------------------->|
| | CCA |
| |<-----------------------|
| Access-Accept | |
|<-----------------------| |
| | |
Figure 8: Message flow example with RADIUS prepaid - Diameter credit-control interworking
図8：Radius Prepaidのメッセージフローの例 - 直径クレジットコントロールインターワーキング
This section contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA.
このセクションには、この仕様で作成された名前空間、またはIANAが管理する既存の名前空間に割り当てられた値が含まれています。
In the subsections below, when we speak about review by a Designated Expert, please note that the designated expert will be assigned by the IESG. Initially, such Expert discussions take place on the AAA WG mailing list.
以下のサブセクションでは、指定された専門家によるレビューについて話すときは、指定された専門家がIESGによって割り当てられることに注意してください。当初、このような専門家の議論はAAA WGメーリングリストで行われます。
This specification assigns the value 4, 'Diameter Credit Control', to the Application Identifier namespace defined in [DIAMBASE]. See section 1.3 for more information.
この仕様は、[Diambase]で定義されているアプリケーション識別子名空間に値4「直径クレジットコントロール」を割り当てます。詳細については、セクション1.3を参照してください。
This specification uses the value 272 from the Command code namespace defined in [DIAMBASE] for the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) commands.
この仕様では、[Diambase]で定義されたクレジット制御（CCR）およびクレジット制御（CCA）コマンドの[Diambase]で定義されたコマンドコード名空間の値272を使用します。
This specification assigns the values 411 - 461 from the AVP code namespace defined in [DIAMBASE]. See section 8 for the assignment of the namespace in this specification.
この仕様は、[Diambase]で定義されているAVPコード名空間から値411-461を割り当てます。この仕様の名前空間の割り当てについては、セクション8を参照してください。
This specification assigns the values 4010, 4011, 4012, 5030, 5031 from the Result-Code AVP value namespace defined in [DIAMBASE]. See section 9 for the assignment of the namespace in this specification.
この仕様は、[Diambase]で定義された結果コードAVP値名空間から値4010、4011、4012、5030、5031を割り当てます。この仕様の名前空間の割り当てについては、セクション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. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.3で定義されているように、CC-RequestタイプAVPには列挙されたタイプ値1-4が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.4, the CC-Failover-Supported AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.4で定義されているように、CC-FailoverがサポートしたAVPには、列挙されたタイプ値0-1が含まれます。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.32, the CC-Unit-Type AVP includes Enumerated type values 0 - 5. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.32で定義されているように、CC-UNITタイプのAVPには列挙されたタイプ値0-5が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.6, the Check-Balance-Result AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.6で定義されているように、チェックバランスと結果のAVPには列挙されたタイプ値0-1が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.13, the Credit-Control AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.13で定義されているように、クレジット制御AVPには列挙されたタイプ値0-1が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.14, the Credit-Control-Failure-Handling AVP includes Enumerated type values 0 - 2. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.14で定義されているように、クレジット制御対策処理AVPには、列挙されたタイプ値0-2が含まれています。IANAは、このAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.15, the Direct-Debiting-Failure-Handling AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.15で定義されているように、直接避妊対策処理AVPには、列挙されたタイプ値0-1が含まれます。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.35, the Final-Unit-Action AVP includes Enumerated type values 0 - 2. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.35で定義されているように、最終ユニットアクションAVPには列挙されたタイプ値0-2が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.40, the Multiple-Services-Indicator AVP includes Enumerated type values 0 - 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.40で定義されているように、Multiple-Services-Indicator AVPには列挙されたタイプ値0-1が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.38, the Redirect-Address-Type AVP includes Enumerated type values 0 - 3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.38で定義されているように、Redirect-Address-Type AVPには列挙されたタイプ値0-3が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.41, the Requested-Action AVP includes Enumerated type values 0 - 3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.41で定義されているように、要求されたアクションAVPには列挙されたタイプ値0-3が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.47, the Subscription-Id-Type AVP includes Enumerated type values 0 - 4. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.47で定義されているように、サブスクリプションIDタイプのAVPには、列挙されたタイプ値0-4が含まれています。IANAは、このAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.27, the Tariff-Change-Usage AVP includes Enumerated type values 0 - 2. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.27で定義されているように、関税変化のAVPには列挙されたタイプ値0-2が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
As defined in section 8.50, the User-Equipment-Info-Type AVP includes Enumerated type values 0 - 3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [IANA].
セクション8.50で定義されているように、User-Equipment-INFO-Type AVPには列挙されたタイプ値0-3が含まれています。IANAはこのAVPの名前空間を作成し、維持しています。すべての残りの値は、指定された専門家[IANA]によって割り当てられます。
Tx timer
TXタイマー
When real-time credit-control is required, the credit-control client contacts the credit-control server before and while the service is provided to an end user. Due to the real-time nature of the application, the communication delays SHOULD be minimized; e.g., to avoid an overly long service setup time experienced by the end user. The Tx timer is introduced to control the waiting time in the client in the Pending state. When the Tx timer elapses, the credit-control client takes an action to the end user according to the value of the Credit-Control-Failure-Handling AVP or Direct-Debiting-Failure-Handling AVP. The recommended value is 10 seconds.
リアルタイムのクレジット制御が必要な場合、クレジット制御クライアントは、サービスがエンドユーザーに提供されている間、クレジット制御サーバーに連絡します。アプリケーションのリアルタイムの性質により、通信の遅延を最小限に抑える必要があります。たとえば、エンドユーザーが経験する過度に長いサービスのセットアップ時間を回避するため。TXタイマーは、保留中の状態のクライアントの待ち時間を制御するために導入されています。TXタイマーが経過すると、クレジット制御クライアントは、クレジットコントロールデールハンドリングAVPまたは直接免除の対処AVPの価値に応じて、エンドユーザーにアクションを行います。推奨値は10秒です。
Tcc timer
TCCタイマー
The Tcc timer supervises an ongoing credit-control session in the credit-control server. It is RECOMMENDED to use the Validity-Time as input to set the Tcc timer value. In case of transient failures in the network, the Diameter credit-control server might change to Idle state. To avoid this, the Tcc timer MAY be set so that Tcc equals to 2 x Validity-Time.
TCCタイマーは、クレジット制御サーバーで継続的なクレジット制御セッションを監督します。有効性時間を入力として使用して、TCCタイマー値を設定することをお勧めします。ネットワーク内の一時的な障害が発生した場合、直径のクレジットコントロールサーバーはアイドル状態に変わる可能性があります。これを避けるために、TCCタイマーを設定して、TCCが2 x有効時刻に等しくなるようにします。
Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling
クレジット制御対策処理と直接免除の対処
Client implementations may offer the possibility of locally configuring these AVPs. In such a case their value and behavior is defined in section 5.7 for the Credit-Control-Failure-Handling and in section 6.5 for the Direct-Debiting-Failure-Handling.
クライアントの実装は、これらのAVPをローカルに構成する可能性を提供する場合があります。そのような場合、それらの価値と行動は、クレジット制御対策処理のセクション5.7と、直接免除の対処のためのセクション6.5で定義されています。
The Diameter base protocol [DIAMBASE] requires that each Diameter implementation use underlying security; i.e., IPsec or TLS. These mechanisms are believed to provide sufficient protection under the normal Internet threat model; that is, assuming that the authorized nodes engaging in the protocol have not been compromised, but that the attacker has complete control over the communication channels between them. This includes eavesdropping, message modification, insertion, and man-in-the-middle and replay attacks. Note also that this application includes a mechanism for application layer replay protection by means of the Session-Id from [DIAMBASE] and CC-Request-Number, which is specified in this document. The Diameter credit-control application is often used within one domain, and there may be a single hop between the peers. In these environments, the use of TLS or IPsec is sufficient. The details of TLS and IPsec related security considerations are discussed in the [DIAMBASE].
直径ベースプロトコル[Diambase]では、各直径の実装が根底にあるセキュリティを使用する必要があります。つまり、IPSECまたはTLS。これらのメカニズムは、通常のインターネット脅威モデルの下で十分な保護を提供すると考えられています。つまり、プロトコルに関与する許可されたノードが侵害されていないが、攻撃者はそれらの間の通信チャネルを完全に制御していると仮定します。これには、盗聴、メッセージの変更、挿入、および中間の攻撃とリプレイ攻撃が含まれます。また、このアプリケーションには、[Diambase]およびCC-Request-NumberからのセッションIDによるアプリケーションレイヤーリプレイ保護のメカニズムが含まれており、このドキュメントで指定されています。直径のクレジットコントロールアプリケーションは、1つのドメイン内でよく使用され、ピア間に1つのホップがある場合があります。これらの環境では、TLSまたはIPSECの使用で十分です。TLSおよびIPSEC関連のセキュリティに関する考慮事項の詳細については、[Diambase]で説明します。
Because this application handles monetary transactions (directly or indirectly), it increases the interest for various security attacks. Therefore, all parties communicating with each other MUST be authenticated, including, for instance, TLS client-side authentication. In addition, authorization of the client SHOULD be emphasized; i.e., that the client is allowed to perform credit-control for a certain user. The specific means of authorization are outside of the scope of this specification but can be, for instance, manual configuration.
このアプリケーションは（直接的または間接的に）金融取引を処理するため、さまざまなセキュリティ攻撃の関心を高めます。したがって、たとえばTLSクライアント側の認証を含む、互いに通信するすべての関係者は認証されなければなりません。さらに、クライアントの承認を強調する必要があります。つまり、クライアントが特定のユーザーに対してクレジット制御を実行することを許可されていること。承認の具体的な手段は、この仕様の範囲外ですが、たとえば手動構成です。
Another kind of threat is malicious modification, injection, or deletion of AVPs or complete credit-control messages. The credit-control messages contain sensitive billing related information (such as subscription Id, granted units, used units, cost information) whose malicious modification can have financial consequences. Sometimes simply delaying the credit-control messages can cause disturbances in the credit-control client or server.
別の種類の脅威は、AVPの悪意のある変更、注入、または削除または完全なクレジット制御メッセージです。クレジット制御メッセージには、悪意のある変更が財政的に影響を与える可能性のある、敏感な請求関連情報（サブスクリプションID、付与ユニット、使用済みユニット、コスト情報など）が含まれています。単にクレジット制御メッセージを遅らせると、クレジット制御クライアントまたはサーバーに乱れを引き起こす可能性があります。
Even without any modification to the messages, an adversary can invite a security threat by eavesdropping, as the transactions contain private information about the user. Also, by monitoring the credit-control messages one can collect information about the credit-control server's billing models and business relationships.
メッセージが変更されていなくても、敵はユーザーに関する個人情報が含まれているため、盗聴によるセキュリティの脅威を招くことができます。また、クレジット制御メッセージを監視することにより、クレジットコントロールサーバーの請求モデルとビジネス関係に関する情報を収集できます。
When third-party relays or proxy are involved, the hop-by-hop security does not necessarily provide sufficient protection for Diameter user session. In some cases, it may be inappropriate to send Diameter messages, such as CCR and CCA, containing sensitive AVPs via untrusted Diameter proxy agents, as there are no assurances that third-party proxies will not modify the credit-control commands or AVP values.
サードパーティのリレーまたはプロキシが関与している場合、ホップバイホップセキュリティは、必ずしも直径ユーザーセッションに十分な保護を提供するわけではありません。場合によっては、サードパーティのプロキシがクレジット制御コマンドまたはAVP値を変更しないという保証がないため、信頼されていない直径プロキシエージェントを介して敏感なAVPを含むCCRやCCAなどの直径メッセージを送信することは不適切かもしれません。
A Diameter credit-control agent cannot always know whether agents between it and the end user's Diameter credit-control server are reliable. In this case, the Diameter credit-control agent doesn't have a routing entry in its Diameter Routing Table (defined in [DIAMBASE], section 2.7) for the realm of the credit-control server in the end user's home domain. The Diameter credit-control agent can have a default route configured to a local Redirect agent, and it redirects the CCR message to the redirect agent. The local Redirect agent then returns a redirect notification (Result-code 3006, DIAMETER_REDIRECT_INDICATION) to the credit-control agent, as well as Diameter credit-control server(s) information (Redirect-Host AVP) and information (Redirect-Host-Usage AVP) about how the routing entry resulting from the Redirect-Host is to be used. The Diameter credit-control agent then forwards the CCR message directly to one of the hosts identified by the CCA message from the redirect agent. If the value of the Redirect-Host-Usage AVP is unequal to zero, all following messages are sent to the host specified in the Redirect-Host AVP until the time specified by the Redirect-Max-Cache-Time AVP is expired.
直径クレジットコントロールエージェントは、それとエンドユーザーの直径のクレジットコントロールサーバーの間のエージェントが信頼できるかどうかを常に知ることはできません。この場合、直径クレジットコントロールエージェントには、エンドユーザーのホームドメインのクレジット制御サーバーの領域の直径ルーティングテーブル（[Diambase]、セクション2.7で定義されている）にルーティングエントリがありません。直径クレジットコントロールエージェントは、ローカルリダイレクトエージェントに設定されたデフォルトルートを持つことができ、CCRメッセージをリダイレクトエージェントにリダイレクトします。次に、ローカルリダイレクトエージェントは、リダイレクト通知（Result-Code 3006、Diameter_redirect_indication）をクレジットコントロールエージェントに返し、Diameter Credit-Control Server（Redirect-Host AVP）および情報（Redirect-Host-UsageAVP）リダイレクトホストから生じるルーティングエントリを使用する方法について。次に、直径クレジットコントロールエージェントは、CCRメッセージをリダイレクトエージェントからのCCAメッセージによって識別されたホストの1つに直接転送します。Redirect-Host-Usage AVPの値がゼロに対して不平等である場合、Redirect-Max-Cache-Time AVPで指定された時間が期限切れになるまで、リダイレクトホストAVPで指定されたホストにすべての次のメッセージが送信されます。
There are some authorization issues even with redirects. There may be attacks toward nodes that have been properly authorized, but that abuse their authorization or have been compromised. These issues are discussed more widely in [DIAMEAP], section 8.
リダイレクトがある場合でも、いくつかの承認の問題があります。適切に承認されたノードに向けて攻撃があるかもしれませんが、許可を乱用したり、妥協したりしています。これらの問題は、[Diameap]、セクション8でより広く議論されています。
[DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[Diambase] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[3GPPCHARG] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Service aspects; Charging and Billing, (release 5), 3GPP TS 22.115 v. 5.2.1, 2002-03.
[3GPPCHARG]第3世代パートナーシッププロジェクト。技術仕様グループサービスとシステムの側面、サービスの側面。充電と請求、（リリース5）、3GPP TS 22.115 v。5.2.1、2002-03。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIATION Protocol」、RFC 3261、2002年6月。
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[Nai] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[E164] Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997.
[E164]推奨事項E.164/i.331（05/97）：国際的な電気通信番号計画。1997年。
[CE164] Complement to ITU-T Recommendation E.164 (05/1997):"List of ITU-T Recommendation E.164 assigned country codes", June 2000.
[CE164] ITU-Tの推奨事項E.164（05/1997）の補完：「ITU-T推奨のリストe.164の割り当てられた国コード」、2000年6月。
[E212] Recommendation E.212 (11/98): The international identification plan for mobile terminals and mobile users. 1998.
[E212]推奨事項E.212（11/98）：モバイルターミナルとモバイルユーザー向けの国際識別計画。1998年。
[CE212] Complement to ITU-T Recommendation E.212 (11/1997):" List of mobile country or geographical area codes", February 1999.
[CE212] ITU-Tの推奨事項E.212（11/1997）の補完：「モバイルカントリーまたは地理的エリアコードのリスト」、1999年2月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[IPv6Addr] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6Addr] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ISO4217] Codes for the representation of currencies and funds, International Standard ISO 4217,2001
[ISO4217]通貨と資金の表現のためのコード、国際標準ISO 4217,2001
[NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[Nasreq] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[aaatrans] Aboba、B。and J. Wood、「認証、承認、会計（AAA）輸送プロファイル」、RFC 3539、2003年6月。
[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[Rad802.1x] Congdon、P.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」、RFC 3580、2003年9月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html March 1997.
[EUI64] IEEE、「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、http：//standards.ieee.org/regauth/oui/tutorials/ eui64.html 1997年3月。
[3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12
[3GPPIMEI]第3世代パートナーシッププロジェクト。技術仕様グループコアネットワーク、番号付け、アドレス指定と識別、（リリース5）、3GPP TS 23.003 v。5.8.0、2003-12
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[Diammip] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T.、およびP. McCann、「直径モバイルIPv4アプリケーション」、RFC 4004、2005年8月。
[DIAMEAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", Work in Progress.
[Diameap] Eronen、P.、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（EAP）アプリケーション」、進行中の作業。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
The authors would like to thank Bernard Aboba, Jari Arkko, Robert Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, Christopher Richards, Juha Vallinen, and Mark Watson for their comments and suggestions.
著者は、バーナード・アボバ、ジャリ・アークコ、ロバート・エクブラッド、パシ・エロネン、ベニー・グスタフソン、ロバート・カールソン、アヴィ・リオール、パコ・マリン、ジュッシ・マキ、ジェフ・マイヤー、アン・ナリ、ジョン・プラドー、クリストファー・リチャーズ、ジュハ・リチャーズ、ジュハ・リチャーズに感謝したいと思います。彼らのコメントと提案についてワトソン。
NAS
End User (CC Client) AAA Server CC Server
|(1)User Logon |(2)AA Request (CC AVPs) |
|------------------>|------------------->| |
| | |(3)CCR(initial, CC AVPs)
| | |------------------->|
| | | (4)CCA(Granted-Units)
| | |<-------------------|
| |(5)AA Answer(Granted-Units) |
|(6)Access granted |<-------------------| |
|<----------------->| | |
| | | |
: : : :
| |(7)CCR(update,Used-Units) |
| |------------------->|(8)CCR |
| | | (update,Used-Units)
| | |------------------->|
| | |(9)CCA(Granted-Units)
| |(10)CCA(Granted-Units)<------------------|
| |<-------------------| |
: : : :
| (Auth. lifetime expires) | |
| |(11) AAR (CC AVP) | |
| |------------------->| |
| | (12) AAA | |
| |<-------------------| |
: : : :
: : : :
|(13) User logoff | | |
|------------------>|(14)CCR(term.,Used-Units) |
| |------------------->|(15)CCR |
| | | (term.,Used-Units)
| | |------------------->|
| | | (16)CCA |
| | (17)CCA |<-------------------|
| |<-------------------| |
| |(18)STR | |
| |------------------->| |
| | (19)STA | |
| |<-------------------| |
Figure A.1: Flow I
図A.1：フローi
A credit-control flow for Network Access Services prepaid is shown in Figure A.1. The Diameter [NASREQ] is implemented in the Network Access Server (NAS). The focus of this flow is in the credit authorization.
ネットワークアクセスサービスのプリペイドのクレジット制御フローを図A.1に示します。直径[NASREQ]は、ネットワークアクセスサーバー（NAS）に実装されています。このフローの焦点は、信用承認にあります。
The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server. The credit-control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service-specific AVPs are included, as usual [NASREQ]. The home Diameter AAA server performs service-specific Authentication and Authorization, as usual. The home Diameter AAA server determines that the user is a prepaid user and notices from the Credit-Control AVP that the NAS has credit-control capabilities. It sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization (3) and to establish a credit-control session. (The home Diameter AAA server may forward service-specific AVPs received from the NAS as input for the rating process.) The Diameter credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account. The reserved quota is returned to the home Diameter AAA server in the Diameter Credit-Control-Answer (4). The home Diameter AAA server sends the reserved quota to the NAS in the Diameter AA-Answer (AAA). Upon successful AAA, the NAS starts the credit-control session and starts monitoring the granted units (5). The NAS grants access to the end user (6). At the expiry of the allocated quota, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the Home Diameter AAA server (7). This message contains the units used thus far. The home Diameter AAA server forwards the CCR to the Diameter credit-control server (8). The Diameter credit-control server debits the used units from the end user's account and allocates a new quota that is returned to the home Diameter AAA server in the Diameter Credit-Control-Answer (9). The message is forwarded to the NAS (10). During the ongoing credit-control session, the authorization lifetime expires, and the authorization/authentication client in the NAS performs service specific re-authorization to the home Diameter AAA server, as usual. The credit-control client populates the AAR with the Credit-Control AVP set to RE_AUTHORIZATION, indicating that the credit-control server shall not be contacted, as the credit authorization is controlled by the burning rate of the granted units (11). The home Diameter AAA server performs service-specific re-authorization as usual and returns the AA-Answer to the NAS (12). The end user logs off from the network (13). To debit the used units from the end user's account and to stop the credit-control session, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the home Diameter AAA server (14). The home Diameter AAA server forwards the CCR to the credit-control server (15). The Diameter credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the home Diameter AAA server (16). The home Diameter AAA server forwards the answer to the NAS (17). STR/STA takes place between the NAS and home Diameter AAA server, as usual (18-19).
ユーザーはネットワークにログオンします（1）。直径NASは、直径AA-Request（AAR）をホーム直径AAAサーバーに送信します。クレジットコントロールクライアントは、CREDY_AUTHORIZITIONに設定されたクレジット制御AVPをAARに浸透させ、通常のようにサービス固有のAVPが含まれています[NASREQ]。ホームの直径AAAサーバーは、通常どおり、サービス固有の認証と承認を実行します。ホームの直径のAAAサーバーは、ユーザーがプリペイドユーザーであると判断し、NASにクレジット制御機能があることにクレジット制御AVPから気付きます。CC-Request-Typeセットを使用して直径クレジットコントロールリケストをInitial_Requestに直径のクレジットコントロールサーバーに送信して、クレジット認証を実行し（3）、クレジット制御セッションを確立します。（Home Diameter AAA Serverは、NASから受信したサービス固有のAVPを評価プロセスの入力として転送できます。）Diameter Credit-Control Serverは、エンドユーザーのアカウント残高をチェックし、サービスを評価し、エンドユーザーのアカウントからクレジットを留保します。予約されたクォータは、直径のクレジットコントロール回答（4）のホーム直径AAAサーバーに返されます。Home Diameter AAAサーバーは、AA-Answer（AAA）の直径のNASに予約されたクォータを送信します。AAAが成功すると、NASはクレジット制御セッションを開始し、付与ユニットの監視を開始します（5）。NASはエンドユーザーにアクセスを許可します（6）。割り当てられた割り当ての有効期限が切れているとき、NASは、CC-Request-Typeを使用して直径クレジットコントロールリクエストを送信し、Home Diameter AAAサーバー（7）にupdate_Requestに設定します。このメッセージには、これまでに使用されているユニットが含まれています。ホーム直径AAAサーバーは、CCRを直径クレジットコントロールサーバー（8）に転送します。直径のクレジットコントロールサーバーは、エンドユーザーのアカウントから使用済みユニットを借方化し、直径のクレジットコントロール回答（9）のホーム直径AAAサーバーに返される新しいクォータを割り当てます。メッセージはNASに転送されます（10）。継続的なクレジット制御セッション中に、認可の寿命が切れ、NASの承認/認証クライアントは、通常どおり、自宅の直径AAAサーバーにサービス固有の再承認を行います。クレジット制御クライアントは、クレジットコントロールAVPがRE_Authorizationに設定されていることをAARに入力し、クレジットコントロールサーバーに連絡してはならないことを示します。ホーム直径AAAサーバーは、通常どおりサービス固有の再承認を実行し、AA回答をNASに返します（12）。エンドユーザーはネットワークからログオフします（13）。使用済みのユニットをエンドユーザーのアカウントから引き落とし、クレジット制御セッションを停止するために、NASは、CC-Request-TypeセットをホームダイアメーターAAAサーバーにTermination_Requestに設定して直径クレジットコントロールリケストを送信します（14）。ホームの直径AAAサーバーは、CCRをクレジットコントロールサーバーに転送します（15）。直径クレジットコントロールサーバーは、直径のクレジットコントロール回答をホームダイアムAAAサーバーに送信することにより、セッション終了を認めます（16）。ホームの直径AAAサーバーは、NAS（17）に答えを転送します。STR/STAは、通常のように、NASと自宅の直径AAAサーバーの間で行われます（18-19）。
SIP Proxy/Registrar AAA
A (CC Client) Server B CC Server
|(i) REGISTER | | | |
|------------->|(ii) | | |
| |------------->| | |
| |authentication & | |
| |authorization | | |
| |<-------------| | |
|(iii)200 OK | | |
|<-------------| | |
: : : :
|(1) INVITE | :
|------------->|
| |(2) CCR (Initial, SIP specific AVP) |
| |------------------------------------------->|
| |(3) CCA (Granted-Units) |
| |<-------------------------------------------|
| |(4) INVITE | |
| |---------------------------->| |
: : : :
| |(5) CCR (update, Used-Units) |
| |------------------------------------------->|
| |(6) CCA (Granted-Units) |
| |<-------------------------------------------|
: : : :
|(7) BYE | | |
|------------->| | |
| |(8) BYE | |
| |---------------------------->| |
| |(9) CCR (termination, Used-Units) |
| |------------------------------------------->|
| |(10) CCA () |
| |<-------------------------------------------|
| | | |
Figure A.2: Flow II
図A.2：フローII
This is an example of Diameter credit-control for SIP sessions. Although the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate, and the diagram is not by any means an attempt to define a service provider's SIP network. However, for the sake of this example, some assumptions are made below.
これは、SIPセッションの直径のクレジット制御の例です。フローはクレジット制御メッセージの使用の説明に焦点を当てていますが、SIPシグナル伝達は不正確であり、図は決してサービスプロバイダーのSIPネットワークを定義する試みではありません。ただし、この例のために、いくつかの仮定を以下に示します。
Typically, prepaid services based, for example, on time usage for SIP session require an entity in the service provider network to intercept all the requests within the SIP dialog in order to detect events, such as session establishment and session release, that are essential to perform credit-control operations with the credit-control server. Therefore, in this example, it is assumed that the SIP Proxy adds a Record-Route header in the initial SIP INVITE to make sure that all the future requests in the created dialog traverse through it (for the definitions of 'Record-Route' and 'dialog' please refer to [SIP]). Finally, the degree of credit-control measuring of the media by the proxy depends on the business model design used in setting up the end system and proxies in the SIP network.
通常、たとえば、SIPセッションの時間を使用してプリペイドサービスを使用して、セッションの確立やセッションリリースなどのイベントを検出するために、SIPダイアログ内のすべてのリクエストをインターセプトするサービスプロバイダーネットワークのエンティティが必要です。クレジット制御サーバーでクレジット制御操作を実行します。したがって、この例では、SIPプロキシが最初のSIP招待状にレコードルートヘッダーを追加して、作成されたダイアログ内のすべての将来の要求がそれを通過することを確認すると想定されています（「レコードルーテ」の定義のために「ダイアログ」は[SIP]を参照してください）。最後に、プロキシによるメディアのクレジット制御の測定の程度は、SIPネットワークでエンドシステムとプロキシのセットアップに使用されるビジネスモデルの設計に依存します。
The end user (SIP User Agent A) sends REGISTER with credentials (i). The SIP Proxy sends a request to the home AAA server to perform Multimedia authentication and authorization by using, for instance, Diameter Multimedia application (ii). The home AAA server checks that the credentials are correct and checks the user profile. Eventually, 200 OK response (iii) is sent to the UA. Note that the Authentication and Authorization is valid for the registration validity period duration (i.e., until re-registration is performed). Several SIP sessions may be established without re-authorization.
エンドユーザー（SIPユーザーエージェントA）は、登録簿を資格情報（i）で送信します。SIPプロキシは、たとえば直径マルチメディアアプリケーション（II）を使用して、マルチメディア認証と承認を実行するためにホームAAAサーバーにリクエストを送信します。Home AAAサーバーは、資格情報が正しいことをチェックし、ユーザープロファイルをチェックします。最終的に、200 OK応答（III）がUAに送信されます。認証と承認は、登録の有効期間期間（つまり、再登録が実行されるまで）に有効であることに注意してください。再承認なしにいくつかのSIPセッションを確立することができます。
UA A sends an INVITE (1). The SIP Proxy sends a Diameter Credit-Control-Request (INITIAL_REQUEST) to the Diameter credit-control server (2). The Credit-Control-Request contains information obtained from the SIP signaling describing the requested service (e.g., calling party, called party, Session Description Protocol attributes). The Diameter credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account. The reserved quota is returned to the SIP Proxy in the Diameter Credit-Control-Answer (3). The SIP Proxy forwards the SIP INVITE to UA B (4). B's phone rings, and B answers. The media flows between them, and the SIP Proxy starts measuring the quota. At the expiry of the allocated quota, the SIP Proxy sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-control server (5). This message contains the units used thus far. The Diameter credit-control server debits the used units from the end user's account and allocates new credit that is returned to the SIP Proxy in the Diameter Credit-Control-Answer (6). The end user terminates the service by sending a BYE (7). The SIP Proxy forwards the BYE message to UA B (8) and sends a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server (9). The Diameter credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the SIP Proxy (10).
ua aは招待状（1）を送信します。SIPプロキシは、直径クレジットコントロールレクエスト（initial_request）を直径クレジットコントロールサーバー（2）に送信します。クレジットコントロールレクエストには、要求されたサービスを説明するSIP信号から取得した情報が含まれています（例：Calling Party、Calk Party、Session Description Protocol属性）。Diameter Credit-Control Serverは、エンドユーザーのアカウント残高をチェックし、サービスを評価し、エンドユーザーのアカウントからクレジットを予約します。予約されたクォータは、直径のクレジットコントロール回答（3）のSIPプロキシに返されます。SIPプロキシは、SIP招待状をUA B（4）に転送します。Bの電話が鳴り、Bは答えます。メディアはそれらの間に流れ、SIPプロキシはクォータの測定を開始します。割り当てられたクォータの有効期限が切れたとき、SIPプロキシは、直径クレジットコントロールレクエスト（update_request）を直径クレジットコントロールサーバー（5）に送信します。このメッセージには、これまでに使用されているユニットが含まれています。直径クレジットコントロールサーバーは、エンドユーザーのアカウントから使用済みユニットを引き落とし、直径のクレジットコントロール回答（6）のSIPプロキシに返される新しいクレジットを割り当てます。エンドユーザーは、さようなら（7）を送信してサービスを終了します。SIPプロキシは、ByeメッセージをUA B（8）に転送し、直径クレジットコントロールRequest（Termination_Request）をクレジットコントロールサーバー（9）に送信します。直径のクレジットコントロールサーバーは、直径のクレジットコントロール回答をSIPプロキシに送信することにより、セッション終了を認めます（10）。
MMS Server
A (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (event, DIRECT_DEBITING,|
| | MMS specific AVP) |
| |-------------------------------->|
| |(3) CCA (Granted-Units) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure A.3: Flow III
図A.3：フローIII
A credit-control flow for Multimedia Messaging Services is shown in Figure A.3. The sender is charged as soon as the messaging server successfully stores the message.
マルチメディアメッセージングサービスのクレジット制御フローを図A.3に示します。メッセージを正常に保存するとすぐに、送信者は請求されます。
The end user A sends a Multimedia Message (MMS) to the MMS server (1). The MMS server stores the message and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) to the Diameter credit-control server (2). The Credit-Control-Request contains information about the MMS message (e.g., size, recipient address, image coding type). The Diameter credit-control server checks the end user's account balance, rates the service, and debits the service from the end user's account. The granted quota is returned to the MMS server in the Diameter Credit-Control-Answer (3). The MMS server acknowledges the successful reception of the MMS message (4). The MMS Server notifies the recipient about the new MMS (5), and end user B retrieves the message from the MMS message store (6),(7).
エンドユーザーAは、マルチメディアメッセージ（MMS）をMMSサーバー（1）に送信します。MMSサーバーはメッセージを保存し、直径のクレジットコントロールRequest（event_requestを要求されたDirect_Debiting）を直径クレジットコントロールサーバーに送信します（2）。クレジットコントロールレクエストには、MMSメッセージに関する情報（サイズ、受信者アドレス、画像コーディングタイプなど）が含まれています。Diameter Credit-Control Serverは、エンドユーザーのアカウント残高をチェックし、サービスを評価し、エンドユーザーのアカウントからサービスを引き落とします。付与されたクォータは、直径のクレジットコントロール回答（3）のMMSサーバーに返されます。MMSサーバーは、MMSメッセージの成功した受信を認めています（4）。MMSサーバーは、新しいMMS（5）について受信者に通知し、エンドユーザーBはMMSメッセージストア（6）、（7）からメッセージを取得します。
MMS Server
Content Server (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (event, CHECK_BALANCE, |
| | MMS specific AVP) |
| |-------------------------------->|
| |(3) CCA (ENOUGH_CREDIT) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) CCR (event, DIRECT_DEBITING,|
| | MMS specific AVP) |
| |-------------------------------->|
| |(8) CCA (Granted-Units) |
| |<--------------------------------|
| |(9) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure A.4: Flow IV
図A.4：フローIV
This is an example of Diameter credit-control for direct debiting using the Multimedia Messaging Service environment. Although the flow focuses on illustrating the usage of credit-control messages, the MMS signaling is inaccurate, and the diagram is not by any means an attempt to define any service provider's MMS configuration or billing model.
これは、マルチメディアメッセージングサービス環境を使用して、直径のクレジット制御の例です。フローはクレジット制御メッセージの使用の説明に焦点を当てていますが、MMSシグナル伝達は不正確であり、図はいかなる手段でもありません。
A credit-control flow for Multimedia Messaging Service is shown in Figure A.4. The recipient is charged at the message delivery.
マルチメディアメッセージングサービスのクレジット制御フローを図A.4に示します。受信者はメッセージ配信で請求されます。
A content server sends a Multimedia Message (MMS) to the MMS server (1) that stores the message. The message recipient will be charged for the MMS message in this case. As there can be a substantially long time between the receipt of the message at the MMS server and the actual retrieval of the message, the MMS server does not establish any credit-control session to the Diameter credit-control server but performs first only a balance check (without any credit reservation) by sending a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to verify that end user B can cover the cost for the MMS (2). The Diameter credit-control server checks the end user's account balance and returns the answer to the MMS server in the Diameter Credit-Control-Answer (3). The MMS server acknowledges the successful reception of the MMS message (4). The MMS server notifies the recipient of the new MMS (5), and after some time end user B retrieves the message from the MMS message store (6). The MMS server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: DIRECT_DEBITING) to the Diameter credit-control server (7). The Credit-Control-Request contains information about the MMS message (e.g., size, recipient address, coding type). The Diameter credit-control server checks the end user's account balance, rates the service, and debits the service from the end user's account. The granted quota is returned to the MMS server in the Diameter Credit-Control-Request (8). The MMS is transferred to end user B (9).
コンテンツサーバーは、メッセージを保存するMMSサーバー（1）にマルチメディアメッセージ（MMS）を送信します。この場合、メッセージ受信者はMMSメッセージに対して請求されます。MMSサーバーでのメッセージの受信とメッセージの実際の取得の間にかなり長い時間がある可能性があるため、MMSサーバーはDiameter Credit-Control Serverにクレジット制御セッションを確立しませんが、最初にバランスのみを実行します。エンドユーザーBがMMSのコストをカバーできることを確認するために、Diameter Credit-Control-Request（Requested-check_balanceを使用したevent_request）を送信して（クレジット予約なしで）確認してください（2）。Diameter Credit-Control Serverは、エンドユーザーのアカウント残高をチェックし、Diameter Credit-Control-Answer（3）のMMSサーバーへの回答を返します。MMSサーバーは、MMSメッセージの成功した受信を認めています（4）。MMSサーバーは、新しいMMS（5）の受信者に通知し、しばらくするとエンドユーザーBがMMSメッセージストア（6）からメッセージを取得します。MMSサーバーは、直径のクレジットコントロールRequest（event_requestを備えたevent_request：direct_debiting）を直径クレジットコントロールサーバーに送信します（7）。クレジットコントロールレクエストには、MMSメッセージに関する情報（サイズ、受信者アドレス、コーディングタイプなど）が含まれています。Diameter Credit-Control Serverは、エンドユーザーのアカウント残高をチェックし、サービスを評価し、エンドユーザーのアカウントからサービスを引き落とします。付与されたクォータは、直径クレジットコントロールレクエスト（8）のMMSサーバーに返されます。MMSはエンドユーザーB（9）に転送されます。
Note that the transfer of the MMS message can take an extended time and can fail, in which case a recovery action is needed. The MMS server should return the already debited units to the user's account by using the REFUND action described in section 6.4.
MMSメッセージの転送には長時間かかり、失敗する可能性があることに注意してください。その場合、回復アクションが必要です。MMSサーバーは、セクション6.4で説明されている払い戻しアクションを使用して、既に引き落とされたユニットをユーザーアカウントに返す必要があります。
SIP Controller
A (CC Client) B CC Server
|(1)INVITE B(SDP)| | |
|--------------->| | |
| |(2) CCR (event, PRICE_ENQUIRY, |
| | SIP specific AVPs) |
| |-------------------------------->|
| |(3) CCA (Cost-Information) |
| |<--------------------------------|
| (4)MESSAGE(URL)| | |
|<---------------| | |
|(5)HTTP GET | | |
|--------------->| | |
|(6)HTTP POST | | |
|--------------->|(7)INVITE(SDP) | |
| |--------------->| |
| | (8)200 OK | |
| (9)200 OK |<---------------| |
|<---------------| | |
Figure A.5: Flow V
図A.5：フロー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セッションの直径のクレジット制御の例です。フローはクレジット制御メッセージの使用の説明に焦点を当てていますが、SIPシグナル伝達は不正確であり、図は決してサービスプロバイダーのSIPネットワークを定義する試みではありません。
Figure A.5 is an example of Advice of Charge (AoC) service for SIP call. User A can be either a postpaid or prepaid subscriber using the AoC service. It is assumed that the SIP controller also has HTTP capabilities and delivers an interactive AoC web page with, for instance, the cost information, the details of the call derived from the SDP, and a button to accept/not accept the charges. (There may be many other ways to deliver AoC information; however, this flow focuses on the use of the credit-control messages.) The user has been authenticated and authorized prior to initiating the call and subscribed to AoC service.
図A.5は、SIPコール用のアドバイス（AOC）サービスの例です。ユーザーAは、AOCサービスを使用して、ポストペイドまたはプリペイドサブスクライバーのいずれかにすることができます。SIPコントローラーにはHTTP機能もあり、たとえばコスト情報、SDPから派生したコールの詳細、および料金を受け入れる/受け入れないボタンを含むインタラクティブなAOC Webページを提供していると想定されています。（AOC情報を提供する他の多くの方法があるかもしれませんが、このフローはクレジット制御メッセージの使用に焦点を当てています。）ユーザーは、通話を開始する前に認証および承認され、AOCサービスに購読されています。
UA A sends an INVITE with SDP to B (1). The SIP controller determines that the user is subscribed to AoC service and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: PRICE_ENQUIRY) to the Diameter credit-control server (2). The Credit-Control-Request contains SIP specific AVPs derived from the SIP signaling, describing the requested service (e.g., calling party, called party, Session Description Protocol attributes). The Diameter credit-control server determines the cost of the service and returns the Credit-Control-Answer including the Cost-Information AVP (3). The SIP controller manufactures the AoC web page with information received in SIP signaling and with the cost information received from the credit-control server. Then it sends a SIP MESSAGE that contains a URL pointing to the AoC information web page (4). At the receipt of the SIP MESSAGE, A's UA automatically invokes the web browser that retrieves the AoC information (5). The user clicks on a proper button and accepts the charges (6). The SIP controller continues the session and sends the INVITE to the B party, which accepts the call (7,8,9).
UA Aは、SDPをby b（1）に招待します。SIPコントローラーは、ユーザーがAOCサービスにサブスクライブされていると判断し、直径クレジットコントロールRequest（requested-action：price_enquiry）を直径クレジットコントロールサーバーに送信します（2）。クレジットコントロールレクエストには、要求されたサービス（たとえば、パーティーと呼ばれる、セッション説明プロトコル属性など）を説明するSIP信号から派生したSIP固有のAVPが含まれています。直径クレジットコントロールサーバーは、サービスのコストを決定し、コスト情報AVP（3）を含むクレジットコントロール回答を返します。SIPコントローラーは、AOC Webページを製造しており、SIPシグナリングで受け取った情報と、クレジット制御サーバーから受け取ったコスト情報を使用しています。次に、AOC情報Webページ（4）を指すURLを含むSIPメッセージを送信します。SIPメッセージの受信時に、AのUAはAOC情報を取得するWebブラウザを自動的に呼び出します（5）。ユーザーは適切なボタンをクリックして、料金を受け入れます（6）。SIPコントローラーはセッションを継続し、招待状をBパーティに送信します。これは、コール（7,8,9）を受け入れます。
Gaming Server
End User (CC Client) CC Server
| (1)Service Delivery | |
|<---------------------->| |
: : :
: : :
| |(2)CCR(event,REFUND,Requested-
| |Service-Unit,Service-Parameter-Info)
| |----------------------->|
| | (3)CCA(Cost-Information)
| |<-----------------------|
| (4)Notification | |
|<-----------------------| |
Figure A.6: Flow VI
図A.6：フローVI
Figure A.6 illustrates a credit-control flow for the REFUND case. It is assumed that there is a trusted relationship and secure connection between the Gaming server and the Diameter credit-control server. The end user may be a prepaid subscriber or a postpaid subscriber.
図A.6は、払い戻しケースのクレジット制御フローを示しています。ゲーミングサーバーと直径クレジットコントロールサーバーの間には、信頼できる関係と安全な接続があると想定されています。エンドユーザーは、プリペイドサブスクライバーまたはポストペイドサブスクライバーである場合があります。
While the end user is playing the game (1), she enters a new level that entitles her to a bonus. The Gaming server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action: REFUND_ACCOUNT) to the Diameter credit-control server (2). The Credit-Control-Request Request contains the Requested-Service-Unit AVP with the CC-Service-Specific-Units containing the number of points the user just won. The Service-Parameter-Info AVP is also included in the request and specifies the service event to be rated (e.g., Tetris Bonus). From information received, the Diameter credit-control server determines the amount to be credited, refunds the user's account, and returns the Credit-Control-Answer, including the Cost-Information AVP (3). The Cost-Information indicates the credited amount. At the first opportunity, the Gaming server notifies the end user of the credited amount (4).
エンドユーザーがゲームをプレイしている間（1）、彼女はボーナスを受ける資格を得る新しいレベルに入ります。ゲームサーバーは、直径のクレジットコントロールレクエスト（event_requestを備えたevent_request：required-action：refund_account）を直径クレジットコントロールサーバーに送信します（2）。クレジット制御要求には、ユーザーが獲得したポイントの数を含むCCサービス固有のユニットを備えた要求されたサービスユニットAVPが含まれています。Service-Parameter-INFO AVPもリクエストに含まれており、評価されるサービスイベント（テトリスボーナスなど）を指定しています。受け取った情報から、Diameter Credit-Control Serverは、クレジットされる金額を決定し、ユーザーのアカウントを払い戻し、コスト情報AVPを含むクレジット制御を返します（3）。コスト情報は、クレジット額を示します。最初の機会に、ゲームサーバーはエンドユーザーにクレジット額を通知します（4）。
SIP Controller Top-Up
A (CC Client) Server B CC Server
| | | | |
| | (1) CCR(Update,Used-Unit) | |
| |------------------------------------------>|
| | (2) CCA(Final-Unit, Redirect)|
| |<------------------------------------------|
: : : : :
: : : : :
| | (3) CCR(Update, Used-Units)| |
| |------------------------------------------>|
| | (3a)INVITE("hold") | |
| |--------------------------->| |
| | | (4) CCA(Validity-Time)|
| |<------------------------------------------|
| (5)INVITE | (6)INVITE | | |
|<--------------|------------->| | |
| (7)RTP | | |
|..............................| | |
| | (8)BYE | | |
| |<-------------| | |
| | (9)CCR(Update) | |
| |------------------------------------------>|
| | (10)CCA(Granted-Unit) |
| |<------------------------------------------|
| (12)INVITE | (11)INVITE | |
|<--------------|--------------------------->| |
Figure A.7: Flow VII
図A.7：フローVII
Figure A.7 is an example of the graceful service termination for a SIP call. It is assumed that the call is set up so that the controller is in the call as a B2BUA (Back to Back User Agent) performing third-party call control (3PCC). Note that the SIP signaling is inaccurate, as the focus of this flow is in the graceful service termination and credit-control authorization. The best practice for 3PCC is defined in [RFC3725].
図A.7は、SIPコールの優雅なサービス終了の例です。コントローラーがサードパーティのコールコントロール（3PCC）を実行するB2BUA（バックツーバックユーザーエージェント）として呼び出し中にコールが設定されると想定されています。このフローの焦点は優雅なサービス終了とクレジット制御承認にあるため、SIPシグナルは不正確であることに注意してください。3PCCのベストプラクティスは[RFC3725]で定義されています。
The call is ongoing between users A and B; user A has a prepaid subscription. At the expiry of the allocated quota, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-control server (1). This message contains the units used thus far. The Diameter credit-control server debits the used units from the end user's account and allocates the final quota returned to the SIP controller in the Diameter Credit-Control-Answer (2). This message contains the Final-Unit-Indication AVP with the Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to SIP URI, and the Redirect-Server-Address set to the Top-up server name (e.g., sip:sip-topup-server@domain.com). At the expiry of the final allocated quota, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-control server (3) and places the called party on "hold" by sending an INVITE with the appropriate connection address in the SDP (3a). The Credit-Control-Request message contains the units used thus far. The Diameter credit-control server debits the used units from the end user's account but does not make any credit reservation. The Credit-Control-Answer message, which contains the Validity-Time to supervise the graceful service termination, is returned to the SIP controller (4). The SIP controller establishes a SIP session between the prepaid user and the Top-up server (5, 6). The Top-up server plays an announcement and prompts the user to enter a credit card number and the amount of money to be used to replenish the account (7). The Top-up server validates the credit card number and replenishes the user's account (using some means outside the scope of this specification) and releases the SIP session (8). The SIP controller can now assume that communication between the prepaid user and the Top-up server took place. It sends a spontaneous Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-control server to check whether the account has been replenished (9). The Diameter credit-control server reserves credit from the end user's account and returns the reserved quota to the SIP controller in the Credit-Control-Answer (10). At this point, the SIP controller re-connects the caller and the called party (11,12).
ユーザーAとBの間で呼び出しが進行中です。ユーザーAにはプリペイドサブスクリプションがあります。割り当てられたクォータの有効期限が切れたとき、SIPコントローラーは、直径クレジットコントロールレクエスト（update_request）を直径クレジットコントロールサーバー（1）に送信します。このメッセージには、これまでに使用されているユニットが含まれています。直径クレジットコントロールサーバーは、エンドユーザーのアカウントから使用済みユニットを借方化し、直径のクレジットコントロール回答（2）のSIPコントローラーに返された最終的なクォータを割り当てます。このメッセージには、リダイレクトに設定された最終ユニットアクションセット、リダイレクトアドレスタイプのSIP URI、およびリダイレクトサーバーアドレスセットをトップアップサーバー名（例えば、SIP：sip-topup-server@domain.com）。最終割り当てされたクォータの有効期限が切れたとき、SIPコントローラーは、適切な接続で招待を送信することにより、直径クレジットコントロールレクエスト（update_request）を直径クレジットコントロールサーバー（3）に送信し、「ホールド」を「保留」に配置します。SDPのアドレス（3a）。クレジットコントロールリクエストメッセージには、これまでに使用されていたユニットが含まれています。Diameter Credit-Control Serverは、エンドユーザーのアカウントから使用済みユニットを借方化しますが、クレジット予約はありません。優雅なサービス終了を監督する有効時刻を含むクレジット制御応答メッセージは、SIPコントローラーに返されます（4）。SIPコントローラーは、プリペイドユーザーとトップアップサーバーの間のSIPセッションを確立します（5、6）。トップアップサーバーはアナウンスを再生し、ユーザーにクレジットカード番号とアカウントを補充するために使用する金額を入力するように促します（7）。トップアップサーバーはクレジットカード番号を検証し、ユーザーのアカウントを補充し（この仕様の範囲外の何らかの手段を使用）、SIPセッション（8）をリリースします。SIPコントローラーは、プリペイドユーザーとトップアップサーバー間の通信が行われたと想定できるようになりました。自発的なクレジットコントロールRequest（update_request）を直径クレジットコントロールサーバーに送信して、アカウントが補充されているかどうかを確認します（9）。Diameter Credit-Control Serverは、エンドユーザーのアカウントからクレジットを留保し、クレジットコントロール回答（10）のSIPコントローラーに予約されたクォータを返します。この時点で、SIPコントローラーは発信者と呼び出されたパーティー（11,12）を再接続します。
NAS Top-up CC
End-User (CC Client) AAA Server Server Server
|(1)User Logon |(2)AA Request (CC AVPs) | |
|------------------>|------------------->| | |
| | |(3)CCR(initial, CC AVPs)
| | |------------------->|
| | |(4)CCA(Final-Unit, |
| | | Validity-Time)|
| | |<-------------------|
| |(5)AA Answer(Final-Unit,Validity-Time) |
|(6)Limited Access |<-------------------| | |
| granted | | | |
|<----------------->| | | |
| | | | |
| (7)TCP/HTTP | (8)TCP/HTTP | |
|<----------------->|<----------------------------->| |
| (9) Replenish account | |
|<------------------------------------------------->| |
| | | (10)RAR |
| |<-------------------|<-------------------|
| | (11) RAA | |
| |------------------->|------------------->|
| |(12)CCR(update) | |
| |------------------->|(13)CCR(Update) |
| | |------------------->|
| | |(14)CCA(Granted-Units)
| |(15)CCA(Granted-Units)<------------------|
| |<-------------------| |
Figure A.8: Flow VIII
図A.8：フローVIII
Figure A.8 is an example of the graceful service termination initiated when the first interrogation takes place because the user's account is empty. In this example, the credit-control server supports the server-initiated credit re-authorization. The Diameter [NASREQ] is implemented in the Network Access Server (NAS).
図A.8は、ユーザーのアカウントが空であるために最初の尋問が行われるときに開始された優雅なサービス終了の例です。この例では、クレジット制御サーバーは、サーバーが開始したクレジットの再承認をサポートしています。直径[NASREQ]は、ネットワークアクセスサーバー（NAS）に実装されています。
The user logs on to the network (1). The Diameter NAS sends a Diameter AA-Request to the home Diameter AAA server. The credit-control client populates the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and service specific AVPs are included, as usual [NASREQ]. The home Diameter AAA server performs service specific Authentication and Authorization, as usual. The home Diameter AAA server determines that the user has a prepaid subscription and notices from the Credit-Control AVP that the NAS has credit-control capabilities. It sends a Diameter Credit-Control- Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization (3) and to establish a credit-control session. (The home Diameter AAA server may forward service specific AVPs received from the NAS as input for the rating process.) The Diameter credit-control server checks the end user's account balance, determines that the account cannot cover the cost of the service, and initiates the graceful service termination. The Credit-Control-Answer is returned to the home Diameter AAA server (4). This message contains the Final-Unit-Indication AVP and the Validity-Time AVP set to a reasonable amount of time to give the user a chance to replenish his/her account (e.g., 10 minutes). The Final-Unit-Indication AVP includes the Final-Unit-Action set to REDIRECT, the Redirect-Address-Type set to URL, and the Redirect-Server-Address set to the HTTP Top-up server name. The home Diameter AAA server sends the received credit-control AVPs to the NAS in the Diameter AA-Answer (5). Upon successful AAA, the NAS starts the credit-control session and immediately starts the graceful service termination, as instructed by the server. The NAS grants limited access to the user (6). The HTTP client software running in the user's device opens the transport connection redirected by the NAS to the Top-up server (7,8). The user is displayed an appropriate web page on which to enter the credit card number, and the amount of money to be used to replenish the account, and with a notification message that she is granted unlimited access if the replenishment operation will be successfully executed within the next, for example, 10 minutes. The Top-up server validates the credit card number and replenishes the user's account (using some means outside the scope of this specification)(9). After successful account top-up, the credit-control server sends a Re-Auth-Request message to the NAS (10). The NAS acknowledges the request by returning the Re-Auth-Answer message (11) and initiates the credit re-authorization by sending a Credit-Control-request (UPDATE_REQUEST) to the Diameter credit-control server (12,13).
ユーザーはネットワークにログオンします（1）。直径NASは、家庭の直径AAAサーバーに直径AA-Requestを送信します。クレジットコントロールクライアントは、AARにCredit_Authorizationに設定されたCredit-Control AVPを使用し、通常のようにサービス固有のAVPが含まれています[Nasreq]。ホームの直径AAAサーバーは、通常どおり、サービス固有の認証と承認を実行します。ホームの直径AAAサーバーは、ユーザーがプリペイドサブスクリプションを持っていることと、NASがクレジット制御機能を持っていることをクレジット制御AVPから通知していると判断します。CC-Request-Typeセットを使用して直径クレジットコントロール要求をInitial_Requestに直径クレジットコントロールサーバーに送信して、クレジット認可を実行し（3）、クレジット制御セッションを確立します。（Home Diameter AAA Serverは、NASから受信した特定のAVPを評価プロセスの入力として転送することができます。）直径のクレジットコントロールサーバーは、エンドユーザーのアカウント残高をチェックし、アカウントがサービスのコストをカバーできないと判断し、開始優雅なサービス終了。クレジットコントロール回答は、家庭の直径AAAサーバーに返されます（4）。このメッセージには、最終ユニット誘導AVPと有効時間AVPが合理的な時間に設定されており、ユーザーがアカウントを補充する機会を与えます（たとえば、10分）。最終ユニット誘導AVPには、リダイレクトする最終ユニットアクションセット、Redirect-Address-Type Set set yuRL、およびRedirect-Server-AddressセットがHTTPトップアップサーバー名に設定されています。ホームの直径AAAサーバーは、受信したクレジット制御AVPを直径AA-Answer（5）のNASに送信します。AAAが成功すると、NASはクレジット制御セッションを開始し、サーバーが指示するように、すぐに優雅なサービス終了を開始します。NASは、ユーザーへのアクセスが制限されています（6）。ユーザーのデバイスで実行されているHTTPクライアントソフトウェアは、NASによってリダイレクトされたトランスポート接続をトップアップサーバー（7,8）に開きます。ユーザーは、クレジットカード番号を入力するための適切なWebページと、アカウントの補充に使用する金額を表示し、補充操作が正常に実行される場合、無制限のアクセスが許可されているという通知メッセージが表示されます。次に、たとえば10分。トップアップサーバーは、クレジットカード番号を検証し、ユーザーのアカウントを補充します（この仕様の範囲外の何らかの手段を使用）（9）。アカウントのトップアップが成功した後、クレジットコントロールサーバーはNAS（10）に再オーストリクエストメッセージを送信します。NASは、ReAuth-Answerメッセージ（11）を返すことによる要求を認め、クレジット制御（update_request）を直径クレジットコントロールサーバー（12,13）に送信することにより、クレジットの再承認を開始します。
The Diameter credit-control server reserves credit from the end user's account and returns the reserved quota to the NAS via the home Diameter AAA server in the Credit-Control-Answer (14,15). The NAS removes the restriction placed by the graceful service termination and starts monitoring the granted units.
Diameter Credit-Control Serverは、エンドユーザーのアカウントからクレジットを留保し、クレジットコントロール回答（14,15）のホーム直径AAAサーバーを介してNASに予約されたクォータを返します。NASは、優雅なサービス終了によって置かれた制限を削除し、付与されたユニットの監視を開始します。
The Diameter credit-control application defines the Multiple-Services-Credit-Control AVP that can be used to support independent credit-control of multiple services in a single credit-control (sub-) session for service elements that have such capabilities. It is possible to request and allocate resources as a credit pool that is shared between services or rating groups.
Diameter Credit-Controlアプリケーションは、そのような機能を持つサービス要素の単一のクレジット制御（サブ）セッションで、複数のサービスの独立したクレジット制御をサポートするために使用できるマルチサービス - クレジット制御AVPを定義します。リソースを要求し、リソースをサービスまたは格付けグループ間で共有するクレジットプールとして割り当てることができます。
The flow example hereafter illustrates a usage scenario where the credit-control client and server support independent credit-control of multiple services, as defined in section 5.1.2. It is assumed that Service-Identifiers, Rating-Groups, and their associated parameters (e.g., IP 5-tuple) are locally configured in the service element or provisioned by an entity other than the credit-control server.
Flowの例は、セクション5.1.2で定義されているように、クレジット制御クライアントとサーバーが複数のサービスの独立したクレジット制御をサポートする使用法シナリオを示しています。サービス - IDENTIFIER、評価グループ、および関連するパラメーター（IP 5タプルなど）は、サービス要素でローカルに構成されているか、クレジット制御サーバー以外のエンティティによってプロビジョニングされていると想定されています。
End User Service Element CC Server
(CC client)
|(1)User logon | |
|------------------>|(2)CCR(initial, Service-Id access, |
| | Access specific AVPs, |
| | Multiple-Service-Indicator) |
| |---------------------------------------->|
| |(3)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<----------------------------------------|
: : :
|(4)Service-Request (Service 1) |
|------------------>|(5)CCR(update, Multiple-Services-CC( |
| | Requested-Units(), Service-Id 1, |
| | Rating-Group 1)) |
| |---------------------------------------->|
| |(6)CCA(Multiple-Services-CC ( |
| | Granted-Units(Time), |
| | Rating-Group 1, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 1))) |
| |<----------------------------------------|
: : :
|(7)Service-Request (Service 2) |
|------------------>| |
: : :
: : :
|(8)Service-Request (Service 3&4) |
|------------------>|(9)CCR(update, Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 3, |
| | Rating-Group 2), |
| | Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 4, |
| | Rating-Group 3)) |
| |---------------------------------------->|
| |(10)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 3, Rating-Group 2, |
| | Validity-time, |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 2)), |
| | Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 4, Rating-Group 3 |
| | Validity-Time, |
| | Final-Unit-Ind.(Terminate), |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 5))) |
| |<----------------------------------------|
: : :
: : :
| +--------------+ | |
| |Validity time | |(11)CCR(update, |
| |expires for | | Multiple-Services-CC ( |
| |Service-Id | | Requested-Unit(), |
| | access | | Used-Units(In-Octets,Out-Octets),|
| +--------------+ | Service-Id access)) |
| |---------------------------------------->|
| |(12)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<----------------------------------------|
: : :
: : :
| +--------------+ | |
| |Total Quota | |(13)CCR(update, |
| |elapses for | | Multiple-Services-CC ( |
| |pool 2: | | Requested-Unit(), |
| |service 4 not | | Used-Units(In-Octets,Out-Octets),|
| |allowed, | | Service-Id 3, Rating-group 2), |
| |service 3 cont| | Multiple-Services-CC ( |
| +--------------+ | Used-Units(In-Octets,Out-Octets),|
| | Service-Id 4, Rating-Group 3)) |
| |---------------------------------------->|
| |(14)CCA(Multiple-Services-CC ( |
| | Result-Code 4011, |
| | Service-Id 3)) |
| |<----------------------------------------|
: : :
: : :
|(15) User logoff | |
|------------------>|(16)CCR(term, |
| | Multiple-Services-CC ( |
| | Used-Units(In-Octets,Out-Octets),|
| | Service-Id access), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 1, Rating-Group 1), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 2, Rating-Group 1)) |
| |---------------------------------------->|
| |(17)CCA(term) |
| |<----------------------------------------|
Figure A.9: Flow example independent credit-control of multiple services in a credit-control (sub-)Session
図A.9：クレジット制御（サブ）セッションでの複数のサービスのフロー例独立クレジット制御
The user logs on to the network (1). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the Diameter credit-control server to perform credit authorization for the bearer service (e.g., Internet access service) and to establish a credit-control session (2). In this message, the credit-control client indicates support for independent credit-control of multiple services within the session by including the Multiple-Service-Indicator AVP. The Diameter credit-control server checks the end user's account balance, with rating information received from the client (i.e., Service-Id and access specific AVPs), rates the request, and reserves credit from the end user's account. Suppose that the server reserves $5 and determines that the cost is $1/MB. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (3).
ユーザーはネットワークにログオンします（1）。サービス要素は、CC-Request-Typeをinitial_requestに直径のクレジットコントロールリクエストを直径クレジットコントロールサーバーに送信し、Bearerサービス（例：インターネットアクセスサービス）のクレジット認証を実行し、クレジット制御セッションを確立する（2）。このメッセージでは、クレジットコントロールクライアントは、複数のサービスインディケーターAVPを含めることにより、セッション内の複数のサービスの独立したクレジット制御のサポートを示しています。Diameter Credit-Control Serverは、クライアントから受け取った評価情報（つまり、Service-IDおよびアクセス固有のAVP）を使用して、エンドユーザーのアカウント残高をチェックし、リクエストを評価し、エンドユーザーのアカウントからクレジットを埋めます。サーバーが5ドルを留保し、コストが1/MBであると判断したとします。次に、Service-ID（アクセス）に関連付けられた5MBのクォータを備えた複数のサービス - クレジット制御AVPを含むクレジット制御応答メッセージ、10の乗数値、および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 50min. associated to the Rating-Group 1, to a multiplier value of 1, and to the Pool-Id 1 (6). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 100.
ユーザーはサービス1（4）を使用します。サービス要素は、CC-Request-Typeを使用して直径のクレジットコントロールリケストを送信し、UPDATE_REQUESTをクレジットコントロールサーバーに更新して、サービス1のクレジット認証を実行します（5）。このメッセージには、格付けグループ1に属するサービス1のサービスユニットを要求する複数サービス - クレジット制御AVPが含まれます。直径クレジットコントロールサーバーは、サービス1がアクセスサービスと同じアカウントからクレジットリソースを描画すると決定します（つまり、、プール1）。Service-ID/Rating-Groupに従ってリクエストを評価し、より多くのクレジットを要求することで既存の予約を更新します。サーバーがさらに5ドル（現在は予約が10ドル）を留保し、コストが0.1/分であると判断したとします。サーバーは、定格グループ全体を承認します。次に、50分のクォータを備えた複数のサービス - クレジット制御AVPを含むクレジット制御応答メッセージをサービス要素に戻します。評価グループ1に関連付けられ、乗数1の値、プールID 1（6）に関連付けられます。クライアントは、プール1 = 100のSを提供するクォータに従って、プール1のリソースの合計量を調整します。
The user uses Service 2, which belongs to the authorized Rating-Group, 1 (7). Resources are then consumed from the pool 1.
ユーザーは、承認された評価グループ1（7）に属するサービス2を使用します。その後、リソースはプール1から消費されます。
The user now requests Services 3 and 4 as well, which are not authorized (8). The service element sends a Diameter Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit authorization for Services 3 and 4 (9). This message includes two instances of the Multiple-Services-Credit-Control AVP to request service units for Service 3 that belong to Rating-Group 2 and for Service 4 that belong to Rating-Group 3. The Diameter credit-control server determines that Services 3 and 4 draw credit resources from another account (i.e., pool 2). It checks the end user's account balance and, according to Service-Ids/Rating-Groups information, rates the request. Then it reserves credit from pool 2.
ユーザーは現在、サービス3と4も要求しますが、これは許可されていません（8）。サービス要素は、サービス3および4（9）のクレジット承認を実行するために、CC-Request-Typeセットを使用してCC-Request-Typeを使用してCC-Request-Typeセットを使用して、CC-Request-Typeを使用して[クレジットコントロールサーバー]に送信します。このメッセージには、レーティンググループ2に属するサービス3と評価グループ3に属するサービス4のサービスユニットを要求する複数サービス - クレジット制御AVPの2つのインスタンスが含まれています。3および4は、別のアカウント（つまり、プール2）からクレジットリソースを描きます。エンドユーザーのアカウント残高をチェックし、Service-ID/Rating-Groupsの情報によると、リクエストを評価します。その後、プール2からクレジットを予約します。
For example, the server reserves $5 and determines that Service 3 costs $0.2/MB and Service 4 costs $0.5/MB. The server authorizes only Services 3 and 4. It returns to the service element a Credit-Control-Answer message that includes two instances of the Multiple-Services-Credit-Control AVP (10). One instance grants a quota of 12.5MB associated to the Service-Id 3 to a multiplier value of 2 and to the Pool-Id 2. The other instance grants a quota of 5 MB associated to the Service-Id 4 to a multiplier value of 5 and to the Pool-Id 2.
たとえば、サーバーは5ドルを留保し、サービス3の費用は0.2/MB、サービス4の価格は0.5ドル/MBであると判断します。サーバーは、サービス3と4のみを承認します。サービス要素に、複数のサービスクレジット制御AVP（10）の2つのインスタンスを含むクレジット制御応答メッセージを返します。1つのインスタンスは、Service-ID 3に関連付けられた12.5MBのクォータを2の2およびPool-ID 2に付与します。他のインスタンスは、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 the Service-Id 4. The client calculates the total amount of resources that can be used for pool 2 according the received quotas and multipliers, which gives S for Pool 2 = 50.
また、サーバーは、これらのユニットが消費された後、プール2が使い果たされ、サービス4が継続することを許可されていないと判断します。したがって、アクション終了を伴う最終ユニット誘導AVPは、サービスIDに関連付けられています。クライアントは、プール2 = 50にSを提供する、受け取ったクォータとマルチプライヤーに従ってプール2に使用できるリソースの合計量を計算します。。
The Validity-Time for the access service expires. The service element sends a Credit-Control-Request message to the server in order to perform credit re-authorization for Service-Id (access) (11). This message carries one instance of the Multiple-Services-Credit-Control AVP that includes the units used by this service. Suppose that the total amount of used units is 4MB. The client adjusts the total amount of resources for pool 1 accordingly, which gives S for Pool 1 = 60.
アクセスサービスの有効期間は期限切れです。Service要素は、Service-ID（アクセス）のクレジット再承認を実行するために、クレジットコントロールリクエストメッセージをサーバーに送信します（11）。このメッセージには、このサービスで使用されているユニットを含む複数のサービス - クレジット制御AVPの1つのインスタンスが含まれています。使用済みユニットの合計量が4MBであると仮定します。クライアントは、それに応じてプール1のリソースの合計量を調整します。これにより、プール1 = 60のSが得られます。
The server deducts $4 from the user's account and updates the reservation by requesting more credit. Suppose that the server reserves $5 more (now the reservation is $11) and already knows the cost of the Service-Id (access), which is $1/MB. It then returns to the service element a Credit-Control-Answer message that includes the Multiple-Services-Credit-Control AVP with a quota of 5 MB associated to the Service-Id (access), to a multiplier value of 10, and to the Pool-Id 1 (12). The client adjusts the total amount of resources for pool 1 according the received quota, which gives S for Pool 1 = 110.
サーバーは、ユーザーのアカウントから4ドルを差し引き、より多くのクレジットを要求することで予約を更新します。サーバーがさらに5ドル（現在は予約が11ドル）を留保し、既にService-ID（アクセス）のコスト（1/MB）のコストを知っていると仮定します。次に、Service-ID（Access）に関連付けられた5 MBのクォータを含む複数のサービス - クレジット制御AVPを含むクレジット制御応答メッセージをサービス要素に戻します。Pool-ID 1（12）。クライアントは、プール1 = 110のSを提供するクォータに従って、プール1のリソースの合計量を調整します。
Services 3 and 4 consume the total amount of pool 2 credit resources (i.e., C1*2 + C2*5 >= S). The service element immediately starts the TERMINATE action concerning Service 4 and sends a Credit-Control-Request message with CC-Request-Type set to UPDATE_REQUEST to the credit-control server in order to perform credit re-authorization for Service 3 (13). This message contains two instances of the Multiple-Services-Credit-Control AVP to report the units used by Services 3 and 4. The server deducts the last $5 from the user's account (pool 2) and returns the answer with Result-Code 4011 in the Multiple-Services-Credit-Control AVP to indicate that Service 3 can continue without credit-control (14).
サービス3と4は、プール2クレジットリソースの総額を消費します（つまり、C1*2 C2*5> = s）。Service要素はすぐにService 4に関するEXTERINETアクションを開始し、CC-Request-Typeを使用してクレジットコントロールリクエストメッセージを送信します。サービス3（13）のクレジット再承認を実行するために、クレジットコントロールサーバーにupdate_Requestに設定します。このメッセージには、複数サービス3および4で使用されているユニットを報告する複数サービス - クレジット制御AVPの2つのインスタンスが含まれています。サーバーは、ユーザーのアカウント（プール2）から最後の5ドルを差し引き、結果コード4011で回答を返します。Service 3がクレジット制御なしで継続できることを示すための複数のサービス - クレジット制御AVP（14）。
The end user logs off from the network (15). To debit the used units from the end user's account and to stop the credit-control session, the service element sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the credit-control server (16). This message contains the units consumed by each of the used services in multiple instances of the Multiple-Services-Credit-Control AVP. The used units are associated with the relevant Service-Identifier and Rating-Group. The Diameter credit-control 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セットを使用して直径クレジットコントロールリケストを送信し、クレジットコントロールサーバーに終了します（16）。このメッセージには、複数のサービス - クレジット制御AVPの複数のインスタンスで使用される各サービスによって消費されるユニットが含まれています。使用済みユニットは、関連するサービス識別子と評価グループに関連付けられています。直径のクレジットコントロールサーバーは、使用済みユニットをユーザーのアカウントに引き落とし（プール1）、直径のクレジットコントロール回答をサービス要素に送信することでセッション終了を認めます（17）。
Authors' Addresses
著者のアドレス
Harri Hakala Oy L M Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland
Harri Hakala Oy L M Ericsson AB Joukahaisenkatu 1 20520 Turku Finland
Phone: +358 2 265 3722
EMail: Harri.Hakala@ericsson.com
Leena Mattila Oy L M Ericsson Ab Joukahaisenkatu 1 20520 Turku Finland
Leena Mattila Oy L M Ericsson AB Joukahaisenkatu 1 20520 Turku Finland
Phone: +358 2 265 3731
EMail: Leena.Mattila@ericsson.com
Juha-Pekka Koskinen Nokia Networks Hatanpaanvaltatie 30 33100 Tampere Finland
Juha-Pekka Koskinen Nokia Networks Hatanpaanvaltatie 30 33100 Tampere Finland
Phone: +358 7180 74027 EMail: juha-pekka.koskinen@nokia.com Marco Stura Nokia Networks Hiomotie 32 00380 Helsinki Finland
電話：358 7180 74027メール：juha-pekka.koskinen@nokia.com Marco Stura Nokia Networks Hiomotie 32 00380 Helsinki Finland
Phone: +358 7180 64308
EMail: marco.stura@nokia.com
John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland
ジョン・ラフニー・ノキア研究センターitamerenkatu 11-13 00180ヘルシンキフィンランド
Phone: +358 50 483 642
EMail: John.Loughney@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。