RFC 4006
Diameter Credit-Control Application
5. Session Based Credit-Control
5.1. General Principles
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. 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. 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. 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 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.
5.1.1. Basic Tariff-Time Change Support
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. 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 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.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-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.
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.
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.
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.
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 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:
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).
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.
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.
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.
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). 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.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 event to the end user. The CC-Request-Type 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 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 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. 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 and after 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 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. 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. 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. 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. 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. 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. 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
5.2.2. Authorization Messages for First Interrogation
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. 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 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. 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. 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). 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. In this scenario, the home Diameter AAA server MUST advertise support for the credit-control application to its peers during the capability exchange process.
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 interrogation5.3. Intermediate Interrogation
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. 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. The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message. The Subscription-Id AVP SHOULD be included in the intermediate message to identify the end user in the credit-control server. The Service-Context-Id AVP indicates the service specific document applicable to the request. The Requested-Service-Unit AVP MAY contain the new amount of requested service units. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP if a new quota is requested for the associated service/rating-group. The Used-Service-Unit AVP contains the amount of used service units measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended. The same unit types used in the previous message SHOULD be used. If several unit types were included in the previous answer message, the used service units for each unit type MUST be reported. The 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-reservation into account. The Credit-Control-Answer message MAY also include the Final-Unit- Indication AVP to indicate that the answer message contains the final units for the service. After the end user has consumed these units, the Diameter credit-control-client MUST behave as described in section 5.6. There can be several intermediate interrogations within a session.5.4. Final Interrogation
When the end user terminates the service session, or when the graceful service termination described in section 5.6 takes place, the Diameter credit-control client MUST send a final Credit-Control- Request message to the credit-control server. The CC-Request-Type AVP is set to the value TERMINATION_REQUEST. The Service-Context-Id AVP indicates the service specific document applicable to the request. 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 set to the value TERMINATION_REQUEST MAY include the Cost-Information AVP containing the estimated total cost for the session in question. If the user logs off during an ongoing credit-control session, or if some other reason causes the user to become logged off (e.g., final-
unit indication causes user logoff according to local policy), the service element, according to application specific policy, may send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [DIAMBASE]. Figure 4 illustrates the case when the final-unit indication causes user logoff upon consumption of the final granted units and the generation of STR. Service Element AAA Server CC Server End User (CC Client) | Service Delivery | | | |<----------------->| | | | : | | | | : | | | | : | | | | | | | | | CCR(Update,Used-Units) | | |------------------->| CCR(Update,Used-Units) | | |------------------->| | | CCA(Final-Unit, Terminate) | CCA(Final-Unit, Terminate)|<-------------------| | |<-------------------| | | : | | | | : | | | | Disconnect user | | | |<------------------| CCR(Termination,Used-Units) | | |------------------->| CCR(Term.,Used-Units) | | |------------------->| | | | CCA | | | CCA |<-------------------| | |<-------------------| | | | STR | | | |------------------->| | | | STA | | | |<-------------------| | Figure 4: 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 [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.
Section 5.1.2 defines the feature to enable credit-control for multiple services within a single (sub-)session where the server can authorize credit usage at a different level of granularity. Further, the server may provide credit resources to multiple services or rating groups as a pool (see section 5.1.2 for details and definitions). Therefore, the server, based on its service logic and its knowledge of the ongoing session, can decide to request credit re-authorization for a whole (sub-)session, a single credit pool, a single service, or a single rating-group. To request credit re- authorization for a credit pool, the server includes in the RAR message the G-S-U-Pool-Identifier AVP indicating the affected pool. To request credit re-authorization for a service or a rating-group, the server includes in the RAR message the Service-Identifier AVP or the Rating-Group AVP, respectively. To request credit re- authorization for all the ongoing services within the (sub-)session, the server includes none of the above mentioned AVPs in the RAR message. If a credit re-authorization is not already ongoing (i.e., the credit-control session is in Open state), a credit control client that receives an RAR message with Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending the Re-Auth-Answer (RAA) message and MUST initiate the credit re- authorization toward the server by sending a Credit-Control-Request message with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with the value UPDATE_REQUEST) is required to complete the procedure. If a quota was allocated to the service, the credit-control client MUST report the used quota in the Credit-Control-Request. Note that the end user does not need to be prompted for the credit re- authorization, since the credit re-authorization is transparent to the user (i.e., it takes place exclusively between the credit-control client and the credit-control server). Where multiple services in a user's session are supported, the procedure in the above paragraph will be executed at the granularity requested by the server in the RAR message. If credit re-authorization is ongoing at the time when the RAR message is received (i.e., RAR-CCR collision), the credit-control client successfully acknowledges the request but does not initiate a new credit re-authorization. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA message to indicate that a credit re- authorization procedure is already ongoing (i.e., the client was in PendingU state when the RAR was received). The credit-control server SHOULD process the Credit-Control-Request as if it was received in answer to the server initiated credit re-authorization, and should
consider the server initiated credit re-authorization process successful upon reception of the Re-Auth-Answer message. When multiple services are supported in a user's session, the server may request credit re-authorization for a credit pool (or for the (sub-)session) while a credit re-authorization is already ongoing for some of the services or rating-groups. In this case, the client acknowledges the server request with an RAA message and MUST send a new Credit-Control-Request message to perform re-authorization for the remaining services/rating-groups. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to indicate that an additional message (i.e., CCR message with value UPDATE_REQUEST) is required to complete the procedure. The server processes the received requests and returns an appropriate answer to both requests. The above-defined procedures are enabled for each of the possibly active Diameter credit-control sub-sessions. The server MAY request re-authorization for an active sub-session by including the CC-Sub- Session-Id AVP in the RAR message in addition to the Session-Id AVP.5.6. Graceful Service Termination
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. It is also possible use the graceful service termination to connect the prepaid user to a top-up server that plays an announcement and prompts the user to replenish the account. In this case, the credit-control server sends only the address of the top-up server where the prepaid user shall be connected after the final granted units have been consumed. An example of this is given in Appendix A (Flow VII). The credit-control server MAY initiate the graceful service termination by including the Final-Unit-Indication AVP in the Credit-Control-Answer to indicate that the message contains the final units for the service. When the credit-control client receives the Final-Unit-Indication AVP in the answer from the server, its behavior depends on the value indicated in the Final-Unit-Action AVP. The server may request the following actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS. A following figure illustrates the graceful service termination procedure described in the following sub-sections.
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.6.1. Terminate Action
The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does
not include any other information. When the subscriber has consumed
the final granted units, the service element MUST terminate the
service. This is the default handling applicable whenever the
credit-control client receives an unsupported Final-Unit-Action value
and MUST be supported by all the Diameter credit-control client
implementations conforming to this specification. A final Credit-
Control-Request message to the credit-control server MUST be sent if
the Final-Unit-Indication AVP indicating action TERMINATE was present
at command level. The CC-Request-Type AVP in the request is set to
the value TERMINATION_REQUEST.
5.6.2. Redirect Action
The Final-Unit-Indication AVP with Final-Unit-Action REDIRECT
indicates to the service element supporting this action that, upon
consumption of the final granted units, the user MUST be re-directed
to the address specified in the Redirect-Server AVP as follows.
The credit-control server sends the Redirect-Server AVP in the
Credit-Control-Answer message. In such a case, the service element
MUST redirect or connect the user to the destination specified in the
Redirect-Server AVP, if possible. When the end user is redirected
(by using protocols others than Diameter) to the specified server or
connected to the top-up server, an additional authorization (and
possibly authentication) may be needed before the subscriber can
replenish the account; however, this is out of the scope of this
specification.
In addition to the Redirect-Server AVP, the credit-control server MAY
include one or more Restriction-Filter-Rule AVPs or one or more
Filter-Id AVPs in the Credit-Control-Answer message to enable the
user to access other services (for example, zero-rated services). In
such a case, the access device MUST drop all the packets not matching
the IP filters specified in the Credit-Control-Answer message and, if
possible, redirect the user to the destination specified in the
Redirect-Server AVP.
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.
When the final granted units have been consumed, the credit-control client MUST perform an intermediate interrogation. The purpose of this interrogation is to indicate to the credit-control server that the specified action started and to report the used units. The credit-control server MUST deduct the used amount from the end user's account but MUST NOT make a new credit reservation. The credit- control client, however, may send intermediate interrogations before all the final granted units have been consumed for which rating and money reservation may be needed; for instance, upon Validity-Time expires or upon mid-session service events that affect the rating of the current service. Therefore, the credit-control client MUST NOT include any rating related AVP in the request sent once all the final granted units have been consumed as an indication to the server that the requested final unit action started, rating and money reservation are not required (when the Multiple-Services-Credit-Control AVP is used, the Service-Identifier or Rating-Group AVPs is included to indicate the concerned services). Naturally, the Credit-Control- Answer message does not contain any granted service unit and MUST include the Validity-Time AVP to indicate to the credit-control client how long the subscriber is allowed to use network resources before a new intermediate interrogation is sent to the server. At the expiry of Validity-Time, the credit-control client sends a Credit-Control-Request (UPDATE_REQUEST) as usual. This message does not include the Used-Service-Unit AVP, as there is no allotted quota to report. The credit-control server processes the request and MUST perform the credit reservation. If during this time the subscriber did not replenish his/her account, whether he/she will be disconnected or will be granted access to services not controlled by a credit-control server for an unlimited time is dependent on the home service provider policy (note: the latter option implies that the service element should not remove the restriction filters upon termination of the credit-control). The server will return the appropriate Result-Code (see section 9.1) in the Credit-Control- Answer message in order to implement the policy-defined action. Otherwise, new quota will be returned, the service element MUST remove all the possible restrictions activated by the graceful service termination process and continue the credit-control session and service session as usual. 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).
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.5.6.3. Restrict Access Action
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. 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. 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. 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.5.6.4. Usage of the Server-Initiated Credit Re-Authorization
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.7. Failure Procedures
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. 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. 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. 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. 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. 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. 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. 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. 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.
(page 41 continued on part 3)
