RFC 8506
Diameter Credit-Control Application
5. Session-Based Credit-Control
5.1. General Principles
For session-based credit-control, several interrogations are needed: the first, the intermediate (optional), and the final. This is illustrated in Figures 3 and 4 (Sections 5.2.1 and 5.2.2). If the credit-control client performs credit reservation before granting service to the end user, it MUST use several interrogations toward the credit-control server (i.e., session-based credit-control). In this case, the credit-control server MUST maintain the credit-control session state. Each credit-control session MUST have a globally unique Session-Id as defined in [RFC6733]; this Session-Id MUST NOT be changed during the lifetime of a credit-control session. Certain applications require multiple credit-control sub-sessions. These applications would send messages with a constant Session-Id AVP but with a different CC-Sub-Session-Id AVP. If several credit sub-sessions will be used, all sub-sessions MUST be closed separately before the main session is closed so that units per sub-session may be reported. The absence of the CC-Sub-Session-Id AVP implies that no sub-sessions are in use.
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. If service-specific re-authorization fails, the user will be disconnected, and the credit-control client MUST send a final interrogation to the credit-control server. The Diameter Credit-Control server may seek to control the validity time of the granted quota and/or the production of intermediate interrogations. Thus, it MAY include the Validity-Time AVP in the Answer message to the credit-control client. Upon expiration of the Validity-Time, the credit-control client MUST generate a credit-control update request and report the used quota to the credit-control server. It is up to the credit-control server to determine the value of the Validity-Time to be used for consumption of the granted service unit(s) (G-S-U). If the Validity-Time is used, its value SHOULD be given as input to set the session supervision timer Tcc (the session supervision timer MAY be set to two times the value of the Validity-Time, as defined in Section 13). Since credit-control update requests are also produced at the expiry of granted service units and/or for mid-session service events, the omission of Validity-Time does not mean that intermediate interrogation for the purpose of credit-control is not performed.5.1.1. Basic Support for Tariff Time Change
The Diameter Credit-Control server and client MAY optionally support a tariff change mechanism. The Diameter Credit-Control server may include a Tariff-Time-Change AVP in the Answer message. Note that the granted units should be allocated based on the worst-case scenario, so that the overall reported used units would never exceed the credit reservation. For example, in the case of a forthcoming tariff change, in which the new rate is higher, the allocation should be given so it does not exceed the credit, assuming that all of it is used after the tariff changed. 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.
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. For time-based services, the quota is consumed at the rate of the passage of real time (ignoring leap seconds). That is, precisely 1 second of quota is consumed per second of real time. At the time when credit resources are allocated, the server already knows how many units will be consumed before the tariff time change and how many units will be consumed afterward. Similarly, the server can determine the units consumed at the "before" rate and the units consumed at the "afterward" rate in the event that the end user closes the session before the consumption of the allotted quota. There is no need for additional traffic between the client and server in the case of tariff time changes for continuous time-based service. Therefore, the tariff change mechanism is not used for such services. For time-based services in which the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used.5.1.2. Credit-Control for Multiple Services within a (Sub-)Session
When multiple services are used within the same user session and each service or group of services is subject to different cost, it is necessary to perform credit-control for each service independently. Making use of credit-control sub-sessions to achieve independent credit-control will result in increased signaling load and usage of resources in both the credit-control client and the credit-control server. For instance, during one network access session, the end user may use several HTTP-based services that could be charged with different costs. The network-access-specific attributes, such as Quality of Service (QoS), are common to all the services carried within the access bearer, but the cost of the bearer may vary, depending on its content. To support these scenarios optimally, the credit-control application enables independent credit-control of multiple services in a single credit-control (sub-)session. This is achieved by including the optional Multiple-Services-Credit-Control AVP in Credit-Control- Request/Credit-Control-Answer messages. It is possible to request and allocate resources as a credit pool shared between multiple services. The services can be grouped into rating-groups in order to achieve even further aggregation of credit allocation. It is also possible to request and allocate quotas on a per-service basis. Where quotas are allocated to a pool by means of the Multiple- Services-Credit-Control AVP, the quotas remain independent objects
that can be re-authorized independently at any time. Quotas can also be given independent result codes, validity times, and Final-Unit- Indication AVP values or QoS-Final-Unit-Indication AVP values. A rating-group gathers a set of services, identified by a Service- Identifier and subject to the same cost and rating type (e.g., $0.1/minute). It is assumed that the Service Element is provided with rating-groups, service-identifiers, and their associated parameters that define what has to be metered by means outside the scope of this specification. (Examples of parameters associated to service-identifiers are IP 5-tuples and HTTP URLs.) Service- identifiers enable authorization on a per-service-based credit as well as itemized reporting of service usage. It is up to the credit-control server whether to authorize credit for one or more services or for the whole rating-group. However, the client SHOULD always report used units at the finest supported level of granularity. Where a quota is allocated to a rating-group, all the services belonging to that group draw from the allotted quota. Figure 2 provides a graphical representation of the relationship between service-identifiers, rating-groups, credit pools, and credit-control (sub-)sessions. Diameter Credit-Control (Sub-)Session | +------------+-----------+-------------+--------------- + | | | | | Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z \ / \ / / \ / \ / / \ / Rating-Group 1.......Rating-Group n \ / | | Quota ---------------Quota Quota | / | | / | Credit Pool Credit Pool Figure 2: Multiple-Service (Sub-)Session Example If independent credit-control of multiple services is used, the Validity-Time AVP, and the Final-Unit-Indication AVP or QoS-Final-Unit-Indication AVP, SHOULD be present either in the Multiple-Services-Credit-Control AVP(s) or at the command level as single AVPs. However, the Result-Code AVP MAY be present both at the command level and within the Multiple-Services-Credit-Control AVP. If the Result-Code AVP at the command level indicates a value other than SUCCESS, then the Result-Code AVP at the command level takes precedence over any other AVPs included in the Multiple-Services- Credit-Control AVP.
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.
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.
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.
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.
If (1) S is the total service units within the pool, (2) M1, M2, ...,
Mn are the multipliers provided for services 1, 2, ..., n, and
(3) C1, C2, ..., Cn are the used resources within the session, then
the pool's credit is exhausted and re-authorization MUST be sought
when:
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 needs to be removed is the
consumed one (i.e., Cx*Mx).
Re-authorizations for an individual service or rating-group may be sought at any time -- for example, if a "non-pooled" quota is used up or the Validity-Time expires. Where multiple G-S-U-Pool-Reference AVPs (Section 8.30) with the same G-S-U-Pool-Identifier are provided within a Multiple-Services-Credit- Control AVP (Section 8.16) along with the Granted-Service-Unit AVP, these AVPs MUST have different CC-Unit-Type values, and they all draw from the credit pool separately. For instance, if one multiplier for time (M1t) and one multiplier for volume (M1v) are given, then the used resources from the pool yield the sum of C1t*M1t + C1v*M1v, where C1t is the time unit and C1v is the volume unit. Where service units are provided within a Multiple-Services-Credit- Control AVP without a corresponding G-S-U-Pool-Reference AVP, these units are handled independently from any credit pools and from any other services or rating-groups within the session. The "credit pool" concept is an optimal tool to avoid the over-reservation effect of the basic single-quota tariff time change mechanism (Section 5.1.1). Therefore, Diameter Credit-Control clients and servers implementing the independent credit-control of multiple services SHOULD leverage the credit pool concept when supporting the tariff time change. The Diameter Credit-Control server SHOULD include both the Tariff-Time-Change AVP and the Tariff-Change-Usage AVP in two quota allocations in the Answer message (i.e., two instances of the Multiple-Services-Credit-Control AVP). One of the grants is allocated to be used before the potential tariff change, while the second grant is for use after a tariff change. Both granted unit quotas MUST contain the same Service- Identifier and/or rating-group. This dual-quota mechanism ensures that the overall reported used units would never exceed the credit reservation. The Diameter Credit-Control client reports the used units both before and after the tariff change in a single instance of the Multiple-Services-Credit-Control AVP. Failure handling for credit-control sessions is defined in Section 5.7 and reflected in the basic credit-control state machines defined in Section 7. Credit-control clients and servers implementing the functionality of independent credit-control of multiple services in a (sub-)session MUST ensure failure handling and general behavior fully consistent with Sections 5.7 and 7 while maintaining the ability to handle parallel ongoing credit re-authorization within a (sub-)session. Therefore, it is RECOMMENDED that Diameter Credit-Control clients maintain a PendingU message queue (Section 7) and restart the Tx timer (Section 13) every time a CCR message with the value UPDATE_REQUEST is sent while they are in PendingU state. When answers to all pending messages are
received, the state machine moves to Open state, and the Tx timer is stopped. Naturally, when a problem is detected and acted upon per Section 5.7, all of the ongoing services are affected (e.g., failover to a backup server affects all of the CCR messages in the PendingU queue). Since the client may send CCR messages with the value UPDATE_REQUEST while in PendingU state (i.e., without waiting for an answer to ongoing credit re-authorization), the time space between these requests may be very short, and the server may not have received the previous request(s) yet. Therefore, in this situation the server may receive out-of-sequence requests and SHOULD NOT consider this an error condition. A proper answer is to be returned to each of those requests.5.2. First Interrogation
When session-based credit-control is required (e.g., the authentication server indicated a prepaid user), the first interrogation MUST be sent before the Diameter Credit-Control client allows any service events for the end user. The CC-Request-Type AVP is set to the value INITIAL_REQUEST in the request message. If the Diameter Credit-Control client knows the cost of the service event (e.g., a content server delivering ringing tones may know their cost) the monetary amount to be charged is included in the Requested- Service-Unit AVP. If the Diameter Credit-Control client does not know the cost of the service event, the Requested-Service-Unit AVP MAY contain the number of requested service events. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP to indicate that the quota for the associated service/rating-group is requested. In the case of multiple services, the Service-Identifier AVP or the Rating-Group AVP within the Multiple-Services-Credit-Control AVP always indicates the service concerned. Additional service event information to be rated MAY be sent as service-specific AVPs or MAY be sent within the Service-Parameter-Info AVP at the command level. The Service-Context-Id AVP indicates the service-specific document applicable to the request. The Event-Timestamp AVP SHOULD be included in the request and contains the time when the service event is requested in the Service Element. The Subscription-Id AVP or the Subscription-Id-Extension AVP SHOULD be included to identify the end user in the credit-control server. The credit-control client MAY include the User-Equipment- Info AVP or User-Equipment-Info-Extension AVP so that the
credit-control server has some indication of the type and capabilities of the end-user access device. How the credit-control server uses this information is outside the scope of this document. 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. 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. There MUST be a maximum of one instance of the same unit type in one Answer message. However, if multiple quotas are conveyed to the credit-control client in the Multiple-Services-Credit-Control AVPs, it is possible to carry two instances of the same unit type associated to a service-identifier/rating-group. This is typically the case when a tariff time change is expected and the credit-control server wants to make a distinction between the granted quota before the tariff change and the granted quota after the tariff change. If the credit-control server determines that no further control is needed for the service, it MAY include the result code indicating that the credit-control is not applicable (e.g., if the service is free of charge). This result code, at the command level, implies that the credit-control session is to be terminated. The Credit-Control-Answer message MAY also include the Final-Unit- Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that the Answer message contains the final units for the service. After the end user has consumed these units, the Diameter Credit-Control client MUST behave as described in Section 5.6. This document defines two different approaches for performing the first interrogation to be used in different network architectures. The first approach uses credit-control messages after the user's authorization and authentication take place. The second approach uses (1) service-specific authorization messages to perform the first
interrogation during the user's authorization/authentication phase and (2) credit-control messages for the intermediate and final interrogations. If an implementation of the credit-control client supports both methods, determining which method to use SHOULD be configurable. In service environments such as NAS environments, it is desired to perform the first interrogation as part of the authorization/ authentication process for the sake of protocol efficiency. Further credit authorizations after the first interrogation are performed with credit-control commands defined in this specification. Implementations of credit-control clients operating in the environments mentioned in this document SHOULD support this method. If the credit-control server and AAA server are separate physical entities, the Service Element sends the request messages to the AAA server, which then issues an appropriate request or proxies the received request forward to the credit-control server. In other service environments, such as the 3GPP network and some SIP scenarios, there is a substantial decoupling between registration/ access to the network and the actual service request (i.e., the authentication/authorization is executed once during registration/ access to the network and is not executed for every service event requested by the subscriber). In these environments, it is more appropriate to perform the first interrogation after the user has been authenticated and authorized. The first, intermediate, and final interrogations are executed with credit-control commands defined in this specification. Other IETF standards or standards developed by other standardization bodies may define the most suitable method in their architectures.5.2.1. First Interrogation after Authorization and Authentication
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.
Figure 3 illustrates the case where both protocols are used in parallel and the Service Element sends credit-control messages directly to the credit-control server. More credit-control sequence examples are given in Appendix A. Diameter End User Service Element AAA Server CC Server (CC Client) | Registration | AA-Request/Answer(accounting, CC, or both)| |<----------------->|<------------------>| | | : | | | | : | | | | Service Request | | | |------------------>| | | | | CCR(Initial, Credit-Control AVPs) | | +|------------------------------------------>| | CC stream|| | CCA(Granted-Units)| | +|<------------------------------------------| | Service Delivery | | | |<----------------->| ACR(start, Accounting AVPs) | | : |------------------->|+ | | : | ACA || Accounting stream | | |<-------------------|+ | | : | | | | : | | | | | CCR(Update, Used-Units) | | |------------------------------------------>| | | | CCA(Granted-Units)| | |<------------------------------------------| | : | | | | : | | | | End of Service | | | |------------------>| CCR(Termination, Used-Units) | | |------------------------------------------>| | | | CCA | | |<------------------------------------------| | | ACR(stop) | | | |------------------->| | | | ACA | | | |<-------------------| | ACR: Accounting-Request ACA: Accounting-Answer Figure 3: Protocol Example with First Interrogation after User's Authorization/Authentication
5.2.2. First Interrogation Included with Authorization Messages
The Diameter Credit-Control client in the Service Element MUST actively co-operate with the authorization/authentication client in the construction of the AA-Request by adding appropriate Credit-Control AVPs. The credit-control client MUST add the Credit-Control AVP to indicate credit-control capabilities and MAY add other relevant credit-control-specific AVPs to the proper authorization/authentication command to perform the first interrogation toward the home Diameter AAA server. The Auth-Application-Id is set to the appropriate value, as defined in service-specific authorization/authentication application document (e.g., [RFC7155] [RFC4004]). The home Diameter AAA server authenticates/authorizes the subscriber and determines whether credit-control is required. 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. The Diameter AAA server supporting credit-control is required to send the Credit-Control-Request command (CCR) defined in this document to the credit-control server. The Diameter AAA server populates the CCR based on service-specific AVPs used for input to the rating process, and possibly on Credit-Control AVPs received in the AA-Request. The credit-control server will reserve money from the user's account, will rate the request, and will send a Credit-Control-Answer message to the home Diameter AAA server. The Answer message includes the Granted-Service-Unit AVP(s) and MAY include other credit-control- specific AVPs, as appropriate. Additionally, the credit-control server MAY set the Validity-Time and MAY include the CCFH and the DDFH to determine what to do if the sending of credit-control messages to the credit-control server has been temporarily prevented. Upon receiving the Credit-Control-Answer message from the credit-control server, the home Diameter AAA server will populate the AA-Answer with the received Credit-Control AVPs and with the appropriate service attributes according to the authorization/ authentication-specific application (e.g., [RFC7155] [RFC4004]). It will then forward the packet to the credit-control client. If the home Diameter AAA server receives a credit-control reject message, it
will simply generate an appropriate authorization reject message to the credit-control client, including the credit-control-specific error code. In this model, the credit-control client sends further credit-control messages to the credit-control server via the home Diameter AAA server. Upon receiving a successful authorization Answer message with the Granted-Service-Unit AVP(s), the credit-control client will grant the service to the end user and will generate an intermediate Credit-Control-Request, if required, by using credit-control commands. The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1 (for details regarding how to produce a unique value for the CC-Request-Number AVP, see Section 8.2). If service-specific re-authorization is performed (i.e., the authorization lifetime expires), the credit-control client MUST add to the service-specific re-authorization request the Credit-Control AVP with a value set to RE_AUTHORIZATION to indicate that the credit-control server MUST NOT be contacted. When session-based credit-control is used for the subscriber, a constant credit-control message stream flows through the home Diameter AAA server. The home Diameter AAA server can make use of this credit-control message flow to deduce that the user's activity is ongoing; therefore, it is recommended to set the authorization lifetime to a reasonably high value when credit-control is used for the subscriber. In this scenario, the home Diameter AAA server MUST advertise support for the credit-control application to its peers during the capability exchange process.
Figure 4 illustrates the use of authorization/authentication messages to perform the first interrogation. The parallel accounting stream is not shown in the figure. Diameter Service Element AAA Server CC Server End User (CC Client) | Service Request | AA-Request (CC AVPs) | | |------------------>|--------------------->| | | | | CCR(Initial, CC AVPs) | | |-------------------->| | | | CCA(Granted-Units)| | | |<--------------------| | | AA-Answer(Granted-Units) | | Service Delivery |<---------------------| | |<----------------->| | | | : | | | | : | | | | : | | | | | | | | | CCR(Update, Used-Units) | | |--------------------->| CCR(Update, Used-Units) | | |-------------------->| | | | CCA(Granted-Units)| | | CCA(Granted-Units)|<--------------------| | |<---------------------| | | : | | | | : | | | | End of Service | | | |------------------>| CCR(Termination, Used-Units) | | |--------------------->| CCR(Term., Used-Units) | | |-------------------->| | | | CCA | | | CCA |<--------------------| | |<---------------------| | Figure 4: Protocol Example with Use of Authorization Messages for the First Interrogation5.3. Intermediate Interrogation
When all the granted service units for one unit type are spent by the end user or the Validity-Time has expired, the Diameter Credit-Control client MUST send a new Credit-Control-Request to the credit-control server. In the event that credit-control for multiple services is applied in one credit-control session (i.e., units associated to Service-Identifier(s) or the rating-group are granted), a new Credit-Control-Request MUST be sent to the credit-control
server when the credit reservation has been wholly consumed or upon expiration of the Validity-Time. It is always up to the Diameter Credit-Control client to send a new request well in advance of the expiration of the previous request in order to avoid interruption in the Service Element. Even if the granted service units reserved by the credit-control server have not been spent upon expiration of the Validity-Time, the Diameter Credit-Control client MUST send a new Credit-Control-Request to the credit-control server. There can also be mid-session service events, which might affect the rating of the current service events. In this case, a spontaneous update (a new Credit-Control-Request) SHOULD be sent, including information related to the service event, even if all the granted service units have not been spent or the Validity-Time has not expired. When the used units are reported to the credit-control server, the credit-control client will not have any units in its possession before new granted units are received from the credit-control server. When the new granted units are received, these units apply from the point where the measurement of the reported used units stopped. Where independent credit-control of multiple services is supported, this process may be executed for one or more services, a single rating-group, or a pool within the (sub-)session. The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message. The Subscription-Id AVP or Subscription-Id-Extension AVP SHOULD be included in the intermediate message to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service-specific document applicable to the request. The Requested-Service-Unit AVP MAY contain the new amount of requested service units. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP if a new quota is requested for the associated service/rating-group. The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. The same unit types used in the previous message SHOULD be used. If several unit types were included in the previous Answer message, the used service units for each unit type MUST be reported. The Event-Timestamp AVP SHOULD be included in the request and contains the time of the event that triggered the sending of the new Credit-Control-Request.
The credit-control server MUST deduct the used amount from the end user's account. It MAY rate the new request and make a new credit reservation from the end user's account that covers the cost of the requested service event. A Credit-Control-Answer message with the CC-Request-Type AVP set to the value UPDATE_REQUEST MAY include the Cost-Information AVP containing the accumulated cost estimation for the session, without taking any credit reservations into account. The Credit-Control-Answer message MAY also include the Final-Unit- Indication AVP or the QoS-Final-Unit-Indication AVP to indicate that the Answer message contains the final units for the service. After the end user has consumed these units, the Diameter Credit-Control client MUST behave as described in Section 5.6. There can be several intermediate interrogations within a session.5.4. Final Interrogation
When the end user terminates the service session or when graceful service termination (described in Section 5.6) takes place, the Diameter Credit-Control client MUST send a final Credit-Control- Request message to the credit-control server. The CC-Request-Type AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP indicates the service-specific document applicable to the request. The Event-Timestamp AVP SHOULD be included in the request and contains the time when the session was terminated. The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. If several unit types were included in the previous Answer message, the used service units for each unit type MUST be reported. After final interrogation, the credit-control server MUST refund the reserved credit amount not used to the end user's account and deduct the used monetary amount from the end user's account. A Credit-Control-Answer message with the CC-Request-Type AVP set to the value TERMINATION_REQUEST MAY include the Cost-Information AVP containing the estimated total cost for the session in question.
If the user logs off during an ongoing credit-control session or if the user becomes logged off for some other reason (e.g., a final-unit indication causes user logoff according to local policy), the Service Element, according to application-specific policy, may send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [RFC6733]. Figure 5 illustrates the case when the final-unit indication causes user logoff upon consumption of the final granted units and the generation of an STR. The Diameter AAA server responds with a Session-Termination-Answer (STA). Service Element AAA Server CC Server End User (CC Client) | Service Delivery | | | |<----------------->| | | | : | | | | : | | | | : | | | | | | | | | CCR(Update, Used-Units) | | |-------------------->| CCR(Update, Used-Units) | | |-------------------->| | | CCA(Final-Unit, Terminate) | CCA(Final-Unit, Terminate)|<--------------------| | |<--------------------| | | : | | | | : | | | | Disconnect user | | | |<------------------| CCR(Termination, Used-Units) | | |-------------------->| CCR(Term., Used-Units) | | |-------------------->| | | | CCA | | | CCA |<--------------------| | |<--------------------| | | | STR | | | |-------------------->| | | | STA | | | |<--------------------| | Figure 5: User Disconnected Due to Exhausted Account5.5. Server-Initiated Credit Re-authorization
The Diameter Credit-Control application supports server-initiated re-authorization. The credit-control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [RFC6733]. The
Auth-Application-Id in the RAR message is set to 4 to indicate "Diameter Credit Control", and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY. Section 5.1.2 defines the feature to enable credit-control for multiple services within a single (sub-)session where the server can authorize credit usage at a different level of granularity. Further, the server may provide credit resources to multiple services or rating-groups as a pool (see Section 5.1.2 for details and definitions). Therefore, the server, based on its service logic and its knowledge of the ongoing session, can decide to request credit re-authorization for a whole (sub-)session, a single credit pool, a single service, or a single rating-group. To request credit re-authorization for a credit pool, the server includes in the RAR message the G-S-U-Pool-Identifier AVP indicating the affected pool. To request credit re-authorization for a service or a rating-group, the server includes in the RAR message the Service-Identifier AVP or the Rating-Group AVP, respectively. To request credit re-authorization for all the ongoing services within the (sub-)session, the server includes none of the above-mentioned AVPs in the RAR message. If a credit re-authorization is not already ongoing (i.e., the credit-control session is in Open state), a credit-control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending the Re-Auth-Answer (RAA) message and MUST initiate the credit re-authorization toward the server by sending a Credit-Control- Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., a CCR message with the value UPDATE_REQUEST) is required to complete the procedure. If a quota was allocated to the service, the credit-control client MUST report the used quota in the Credit-Control-Request. Note that the end user does not need to be prompted for the credit re-authorization, since the credit re-authorization is transparent to the user (i.e., it takes place exclusively between the credit-control client and the credit-control server). Where multiple services in a user's session are supported, the procedure in the above paragraph will be executed at the granularity requested by the server in the RAR message. If credit re-authorization is ongoing at the time when the RAR message is received (i.e., an RAR-CCR collision), the credit-control client successfully acknowledges the request but does not initiate a new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS)
SHOULD be used in the RAA message to indicate that a credit re-authorization procedure is already ongoing (i.e., the client was in PendingU state when the RAR was received). The credit-control server SHOULD process the Credit-Control-Request as if it was received in answer to the server-initiated credit re-authorization and should consider the server-initiated credit re-authorization process successful upon reception of the RAA message. When multiple services are supported in a user's session, the server may request credit re-authorization for a credit pool (or for the (sub-)session) while a credit re-authorization is already ongoing for some of the services or rating-groups. In this case, the client acknowledges the server request with an RAA message and MUST send a new Credit-Control-Request message to perform re-authorization for the remaining services/rating-groups. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., a CCR message with the value UPDATE_REQUEST) is required to complete the procedure. The server processes the received requests and returns an appropriate answer to both requests. 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.
(page 34 continued on part 4)
