tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4006

 
 
 

Diameter Credit-Control Application

Part 2 of 5, p. 15 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
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-

Top      Up      ToC       Page 16 
   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.

Top      Up      ToC       Page 17 
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

Top      Up      ToC       Page 18 
   (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

Top      Up      ToC       Page 19 
   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

Top      Up      ToC       Page 20 
   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.

Top      Up      ToC       Page 21 
   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

Top      Up      ToC       Page 22 
   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

Top      Up      ToC       Page 23 
   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

Top      Up      ToC       Page 24 
   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

Top      Up      ToC       Page 25 
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

Top      Up      ToC       Page 26 
   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.

Top      Up      ToC       Page 27 
   The following diagram illustrates the use of
   authorization/authentication messages to perform the first
   interrogation.  The parallel accounting stream is not shown in the
   figure.

                    Service Element         Diameter
   End User          (CC Client)           AAA Server          CC Server
      | Service Request   | AA Request (CC AVPs)                    |
      |------------------>|------------------->|                    |
      |                   |                    | CCR(Initial, CC AVPs)
      |                   |                    |------------------->|
      |                   |                    |    CCA(Granted-Units)
      |                   |                    |<-------------------|
      |                   | AA Answer(Granted-Units)                |
      | Service Delivery  |<-------------------|                    |
      |<----------------->|                    |                    |
      |         :         |                    |                    |
      |         :         |                    |                    |
      |         :         |                    |                    |
      |                   |                    |                    |
      |                   | CCR(Update,Used-Units)                  |
      |                   |------------------->| CCR(Update,Used-Units)
      |                   |                    |------------------->|
      |                   |                    |  CCA(Granted-Units)|
      |                   |  CCA(Granted-Units)|<-------------------|
      |                   |<-------------------|                    |
      |         :         |                    |                    |
      |         :         |                    |                    |
      | End of Service    |                    |                    |
      |------------------>| CCR(Termination,Used-Units)             |
      |                   |------------------->| CCR(Term.,Used-Units)
      |                   |                    |------------------->|
      |                   |                    |                CCA |
      |                   |                CCA |<-------------------|
      |                   |<-------------------|                    |

                Figure 3: Protocol example with use of the
           authorization messages for the first interrogation

5.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

Top      Up      ToC       Page 28 
   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.

Top      Up      ToC       Page 29 
   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-

Top      Up      ToC       Page 30 
   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 account

5.5.  Server-Initiated Credit Re-Authorization

   The Diameter credit-control application supports server-initiated
   re-authorization.  The credit-control server MAY optionally initiate
   the credit re-authorization by issuing a Re-Auth-Request (RAR) as
   defined in the Diameter base protocol [DIAMBASE].  The Auth-
   Application-Id in the RAR message is set to 4 to indicate Diameter
   Credit Control, and the Re-Auth-Request-Type is set to
   AUTHORIZE_ONLY.

Top      Up      ToC       Page 31 
   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

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
                                            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        |                    |                    |

Top      Up      ToC       Page 35 
         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.

Top      Up      ToC       Page 36 
   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).

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
   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

Top      Up      ToC       Page 39 
   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

Top      Up      ToC       Page 40 
   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.

Top      Up      ToC       Page 41 
   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)

Next RFC Part