Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: DIME

RFC 8506

Diameter Credit-Control Application

Pages: 130
Proposed STD
Obsoletes:  4006
Part 4 of 9 – Pages 34 to 49
First   Prev   Next

Top   ToC   Page 34   prevText
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 -- from
   which the user is allowed to benefit for a limited time.  The length
   of this time is usually dependent on the home service provider
   policy.

   This section defines the optional graceful service termination
   feature.  This feature MAY be supported by the credit-control server.
   Credit-control client implementations MUST support the Final-Unit-
   Indication AVP or QoS-Final-Unit-Indication AVP with at least the
   teardown of the ongoing service session once the subscriber has
   consumed all the final granted units.
Top   ToC   Page 35
   Where independent credit-control of multiple services in a single
   credit-control (sub-)session is supported, it is possible to use
   graceful service termination for each of the services/rating-groups
   independently.  Naturally, the graceful service termination process
   defined in the following subsections will apply to the specific
   service/rating-group as requested by the server.

   In some service environments (e.g., NAS), graceful service
   termination may be used to redirect the subscriber to a service
   portal for online balance refill or other services offered by the
   home service provider.  In this case, the graceful service
   termination process installs a set of packet filters to restrict the
   user's access capability only to/from the specified destinations.
   All the IP packets not matching the filters will be dropped or,
   possibly, redirected to the service portal.  The user may also be
   sent an appropriate notification as to why the access has been
   limited.  These actions may be communicated explicitly from the
   server to the client or may be configured "per service" at the
   client.  Explicitly signaled redirection or restriction instructions
   always take precedence over configured ones.

   It is also possible to use graceful service termination to connect
   the prepaid user to a top-up server that plays an announcement and
   prompts the user to replenish the account.  In this case, the
   credit-control server sends only the address of the top-up server
   where the prepaid user shall be connected after the final granted
   units have been consumed.  An example of this case is given in
   Appendix A.7.

   The credit-control server MAY initiate graceful service termination
   by including the Final-Unit-Indication AVP or the
   QoS-Final-Unit-Indication AVP in the Credit-Control-Answer to
   indicate that the message contains the final units for the service.

   When the credit-control client receives the Final-Unit-Indication AVP
   or the QoS-Final-Unit-Indication AVP in the answer from the server,
   its behavior depends on the value indicated in the Final-Unit-Action
   AVP.  The server may request the following actions: TERMINATE,
   REDIRECT, or RESTRICT_ACCESS.

   Figure 6 illustrates the graceful service termination procedure
   described in the following subsections.
Top   ToC   Page 36
                                            Diameter
   End User        Service Element          AAA Server         CC Server
                   (CC Client)
     |  Service Delivery |                     |                     |
     |<----------------->|                     |                     |
     |                   |CCR(Update, Used-Units)                    |
     |                   |-------------------->|CCR(Update, Used-Units)
     |         :         |                     |-------------------->|
     |         :         |                     |CCA(Final-Unit, Action)
     |         :         |                     |<--------------------|
     |                   |CCA(Final-Unit, Action)                    |
     |                   |<--------------------|                     |
     |                   |                     |                     |
     |         :         |                     |                     |
     |         :         |                     |                     |
     | ///////////////   |CCR(Update, Used-Units)                    |
     |/Final Units End/->|-------------------->|CCR(Update, Used-Units)
     |/Action and    //  |                     |-------------------->|
     |/Restrictions //   |                     |   CCA(Validity-Time)|
     |/Start       //    |   CCA(Validity-Time)|<--------------------|
     | /////////////     |<--------------------|                     |
     |         :         |                     |                     |
     |         :         |                     |                     |
     |                 Replenish account       |     +-------+       |
     |<--------------------------------------------->|Account|       |
     |                   |                     |     +-------+       |
     |                   |                     |                 RAR |
     |                 + |                 RAR |<====================|
     |                 | |<====================|                     |
     |                 | | RAA                 |                     |
     |  /////////////  | |====================>| RAA                 |
     | /If supported / | | CCR(Update)         |====================>|
     | /by CC Server/  | |====================>| CCR(Update)         |
     | /////////////   | |                     |====================>|
     |                 | |                     |   CCA(Granted-Units)|
     |                 | |   CCA(Granted-Units)|<====================|
     |  Restrictions ->+ |<====================|                     |
     |  removed          |                     |                     |
     |         :         |                     |                     |
     |        OR         | CCR(Update)         |                     |
     |   Validity-Time ->|-------------------->| CCR(Update)         |
     |   expires         |                     |-------------------->|
     |                   |                     |   CCA(Granted-Units)|
     |                   |   CCA(Granted-Units)|<--------------------|
     |    Restrictions ->|<--------------------|                     |
     |    removed        |                     |                     |

         Figure 6: Optional Graceful Service Termination Procedure
Top   ToC   Page 37
   In addition, the credit-control server MAY reply with the Final-Unit-
   Indication AVP or QoS-Final-Unit-Indication AVP holding a Granted-
   Service-Unit (G-S-U) with a zero grant, indicating that the service
   SHOULD be terminated immediately, and no further reporting is
   required.  Figure 7 illustrates a graceful service termination
   procedure that applies immediately after receiving a zero grant.

                                             Diameter
   End User        Service Element           AAA Server        CC Server
                   (CC Client)
     |  Service Delivery |                      |                     |
     |<----------------->|                      |                     |
     |                   |CCR(Update, Used-Units)                     |
     |                   |--------------------->|CCR(Update, Used-Units)
     |         :         |                      |-------------------->|
     |         :         |                      |CCA(Final-Unit, Action,
     |         :         |                      |            Zero G-S-U)
     |         :         |                      |<--------------------|
     |                   |CCA(Final-Unit, Action,                     |
     |                   |            Zero G-S-U)                     |
     |                   |<---------------------|                     |
     | ///////////////   |                      |                     |
     |/Action and    //  |                      |                     |
     |/Restrictions //   |                      |                     |
     |/Start       //    |                      |                     |
     | /////////////     |                      |                     |
     |         :         |                      |                     |
     |         :         |                      |                     |

    Figure 7: Optional Immediate Graceful Service Termination Procedure

5.6.1.  Terminate Action

   The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP
   with Final-Unit-Action set to TERMINATE does not include any other
   information.  When the subscriber has consumed the final granted
   units, the Service Element MUST terminate the service.  This is the
   default handling applicable whenever the credit-control client
   receives an unsupported Final-Unit-Action value and MUST be supported
   by all the Diameter Credit-Control client implementations conforming
   to this specification.  A final Credit-Control-Request message to the
   credit-control server MUST be sent if the Final-Unit-Indication AVP
   or the QoS-Final-Unit-Indication AVP indicating action TERMINATE was
   present at the command level.  The CC-Request-Type AVP in the request
   is set to the value TERMINATION_REQUEST.
Top   ToC   Page 38
5.6.2.  Redirect Action

   The Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP
   with Final-Unit-Action set to REDIRECT indicates to the Service
   Element supporting this action that, upon consumption of the final
   granted units, the user MUST be redirected to the address specified
   in the Redirect-Server AVP or Redirect-Server-Extension AVP as
   follows.

   The credit-control server sends the Redirect-Server AVP or Redirect-
   Server-Extension AVP in the Credit-Control-Answer message.  In such a
   case, the Service Element MUST redirect or connect the user to the
   destination specified in the Redirect-Server AVP or Redirect-Server-
   Extension AVP, if possible.  When the end user is redirected (by
   using protocols other than Diameter) to the specified server or
   connected to the top-up server, an additional authorization (and
   possibly authentication) may be needed before the subscriber can
   replenish the account; however, this scenario is out of scope for
   this specification.

   In addition to the Redirect-Server AVP or Redirect-Server-Extension
   AVP, the credit-control server MAY include one or more Restriction-
   Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more
   Filter-Id AVPs in the Credit-Control-Answer message to enable the
   user to access other services (for example, zero-rated services).  In
   such a case, the access device MUST treat all packets according to
   the Restriction-Filter-Rule AVPs, Filter-Rule AVPs, and the rules
   referred to by the Filter-Id AVP.  After treatment is applied
   according to these rules, all traffic that has not been dropped or
   already forwarded MUST be redirected to the destination specified in
   the Redirect-Server AVP or Redirect-Server-Extension AVP.

   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 expiration or upon mid-session service events that
   affect the rating of the current service.  Therefore, the
Top   ToC   Page 39
   credit-control client MUST NOT include any rating-related AVPs in the
   request sent once all the final granted units have been consumed, as
   an indication to the server that (1) the requested final unit action
   started and (2) rating and money reservation are not required (when
   the Multiple-Services-Credit-Control AVP is used, the Service-
   Identifier AVP or the Rating-Group AVP is included to indicate the
   services concerned).  Naturally, the Credit-Control-Answer message
   does not contain any granted service units and MUST include the
   Validity-Time AVP to indicate to the credit-control client how long
   the subscriber is allowed to use network resources before a new
   intermediate interrogation is sent to the server.

   At the expiry of Validity-Time, the credit-control client sends a
   Credit-Control-Request (UPDATE_REQUEST) as usual.  This message does
   not include the Used-Service-Unit AVP, as there is no allotted quota
   to report.  The credit-control server processes the request and MUST
   perform the credit reservation.  If during this time the subscriber
   did not replenish their account, whether they will be disconnected or
   will be granted access to services not controlled by a credit-control
   server for an unlimited time is dependent on the home service
   provider policy.  (Note: The latter option implies that the Service
   Element should not remove the restriction filters upon termination of
   the credit-control.)  The server will return the appropriate
   Result-Code (see Section 9.1) in the Credit-Control-Answer message in
   order to implement the policy-defined action.  Otherwise, a new quota
   will be returned, and the Service Element MUST remove all the
   possible restrictions activated by the graceful service termination
   process and continue the credit-control session and service session
   as usual.

   The credit-control client may not wait until the expiration of the
   Validity-Time and may send a spontaneous update (a new
   Credit-Control-Request) if the Service Element can determine, for
   instance, that communication between the end user and the top-up
   server took place.  An example of this case is given in Appendix A.8
   (Figure 18).

   Note that the credit-control server may already have initiated the
   above-described process for the first interrogation.  However, the
   user's account might be empty when this first interrogation is
   performed.  In this case, the subscriber can be offered a chance to
   replenish the account and continue the service.  When the
   credit-control client receives (at either the session level or a
   service-specific level) a Final-Unit-Indication AVP or QoS-Final-
   Unit-Indication AVP, together with Validity-Time AVPs, but without a
   Granted-Service-Unit AVP, it immediately starts the graceful service
   termination process without sending any messages to the server.  An
   example of this case is illustrated in Appendix A.8 (Figure 18).
Top   ToC   Page 40
5.6.3.  Restrict Access Action

   A Final-Unit-Indication AVP with Final-Unit-Action set to
   RESTRICT_ACCESS indicates to the device supporting this action that,
   upon consumption of the final granted units, the user's access MUST
   be restricted according to the IP packet filters given in the
   Restriction-Filter-Rule AVP(s) or according to the IP packet filters
   identified by the Filter-Id AVP(s).  The credit-control server SHOULD
   include either the Restriction-Filter-Rule AVP or the Filter-Id AVP
   in the Final-Unit-Indication group AVP of the Credit-Control-Answer
   message.

   A QoS-Final-Unit-Indication AVP with Final-Unit-Action set to
   RESTRICT_ACCESS indicates to the device supporting this action that,
   upon consumption of the final granted units, the actions specified in
   Filter-Rule AVP(s) MUST restrict the traffic according to the
   classifiers in the Filter-Rule AVP(s).  If one or more Filter-Id AVPs
   are provided in the Credit-Control-Answer message, the credit-control
   client MUST restrict the traffic according to the IP packet filters
   identified by the Filter-Id AVP(s).  The credit-control server SHOULD
   include either the Filter-Rule AVP or the Filter-Id AVP in the
   QoS-Final-Unit-Indication group AVP of the Credit-Control-Answer
   message.

   If both the Final-Unit-Indication AVP and the QoS-Final-Unit-
   Indication AVP exist in the Credit-Control-Answer message, a
   credit-control client that supports the QoS-Final-Unit-Indication AVP
   SHOULD follow the directives included in the QoS-Final-Unit-
   Indication AVP and SHOULD ignore the Final-Unit-Indication AVP.

   An entity other than the credit-control server may provision the
   access device with appropriate IP packet filters to be used in
   conjunction with the Diameter Credit-Control application.  Such an
   entity may, for instance, configure the access device with IP flows
   to be passed when the Diameter Credit-Control application indicates
   RESTRICT_ACCESS or REDIRECT.  The access device passes IP packets
   according to the filter rules that may have been received in the
   Credit-Control-Answer message, in addition to those rules that may
   have been configured by the other entity.  However, when the user's
   account cannot cover the cost of the requested service, the action
   taken is the responsibility of the credit-control server that
   controls the prepaid subscriber.

   If another entity working in conjunction with the Diameter
   Credit-Control application already provisions the access device with
   all the required filter rules for the end user, the credit-control
   server presumably need not send any additional filters.  Therefore,
   it is RECOMMENDED that credit-control server implementations
Top   ToC   Page 41
   supporting graceful service termination be configurable for sending
   the Restriction-Filter-Rule AVP, the Filter-Rule AVP, the Filter-Id
   AVP, or none of the above.

   When the final granted units have been consumed, the credit-control
   client MUST perform an intermediate interrogation.  The
   credit-control client and the credit-control server process this
   intermediate interrogation and execute subsequent procedures, as
   specified in Section 5.6.2.

   The credit-control server may initiate graceful service termination
   when replying with the action RESTRICT_ACCESS for the first
   interrogation.  This is similar to the behavior specified in
   Section 5.6.2.

5.6.4.  Usage of the Server-Initiated Credit Re-authorization

   Once the subscriber replenishes the account, they presumably expect
   all the restrictions applied by the graceful service termination
   procedure to be removed immediately and unlimited service access to
   be resumed.  For the best user experience, the credit-control server
   implementation MAY support the server-initiated credit
   re-authorization (see Section 5.5).  In such a case, upon the
   successful account top-up, the credit-control server sends the
   Re-Auth-Request (RAR) message to solicit the credit re-authorization.
   The credit-control client initiates the credit re-authorization by
   sending the Credit-Control-Request message with the CC-Request-Type
   AVP set to the value UPDATE_REQUEST.  The Used-Service-Unit AVP is
   not included in the request, as there is no allotted quota to report.
   The Requested-Service-Unit AVP MAY be included in the request.  After
   the credit-control client successfully receives the Credit-Control-
   Answer with a new Granted-Service-Unit AVP, all the possible
   restrictions activated for the purpose of graceful service
   termination MUST be removed in the Service Element.  The
   credit-control session and the service session continue as usual.

5.7.  Failure Procedures

   The CCFH, as described in this section, determines the behavior of
   the credit-control client in fault situations.  The CCFH may be
   (1) received from the Diameter home AAA server, (2) received from the
   credit-control server, or (3) configured locally.  The CCFH value
   received from the home AAA server overrides the locally configured
   value.  The CCFH value received from the credit-control server in the
   Credit-Control-Answer message always overrides any existing values.
Top   ToC   Page 42
   The authorization server MAY include the Accounting-Realtime-Required
   AVP to determine what to do if the sending of accounting records to
   the accounting server has been temporarily prevented, as defined in
   [RFC6733].  It is RECOMMENDED that the client complement the
   credit-control failure procedures with a backup accounting flow
   toward an accounting server.  By using different combinations of the
   Accounting-Realtime-Required AVP and the CCFH, different safety
   levels can be built.  For example, by choosing a CCFH equal to
   CONTINUE for the credit-control flow and an Accounting-Realtime-
   Required AVP equal to DELIVER_AND_GRANT for the accounting flow, the
   service can be granted to the end user even if the connection to the
   credit-control server is down, as long as the accounting server is
   able to collect the accounting information and information exchange
   is taking place between the accounting server and credit-control
   server.

   As the credit-control application is based on real-time bidirectional
   communication between the credit-control client and the
   credit-control server, the usage of alternative destinations and the
   buffering of messages may not be sufficient in the event of
   communication failures.  Because the credit-control server has to
   maintain session states, moving the credit-control message stream to
   a backup server requires a complex context transfer solution.
   Whether the credit-control message stream is moved to a backup
   credit-control server during an ongoing credit-control session
   depends on the value of the CC-Session-Failover AVP.  However,
   failover may occur at any point in the path between the
   credit-control client and the credit-control server if a transport
   failure is detected with a peer, as described in [RFC6733].  As a
   consequence, the credit-control server might receive duplicate
   messages.  These duplicate or out-of-sequence messages can be
   detected in the credit-control server based on the credit-control
   server session state machine (Section 7), Session-Id AVP, and
   CC-Request-Number AVP.

   If a failure occurs during an ongoing credit-control session, the
   credit-control client may move the credit-control message stream to
   an alternative server if the credit-control server indicated
   FAILOVER_SUPPORTED in the CC-Session-Failover AVP.  A secondary
   credit-control server name, either received from the home Diameter
   AAA server or configured locally, can be used as an address of the
   backup server.  If the CC-Session-Failover AVP is set to
   FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be
   moved to a backup server.
Top   ToC   Page 43
   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 [RFC3539] defines an application-layer
   watchdog algorithm that enables failover from a peer that has failed
   and is controlled by a watchdog timer (Tw) (defined in [RFC3539]).
   The recommended default initial value for Tw (Twinit) is 30 seconds.
   Twinit may be set as low as 6 seconds; however, according to
   [RFC3539], setting too low a value for Twinit is likely to result in
   an increased probability of duplicates, as well as an increase in
   spurious failover and failback attempts.  The Diameter base protocol
   [RFC6733] is common to several different types of Diameter AAA
   applications that may be run in the same Service Element.  Therefore,
   tuning the timer for Twinit to a lower value in order to satisfy the
   requirements of real-time applications, such as the Diameter
   Credit-Control application, will certainly cause the above-mentioned
   problems.  For prepaid services, however, the end user expects an
   answer from the network in a reasonable time.  Thus, the Diameter
   Credit-Control client will react more quickly than would the
   underlying base protocol.  Therefore, this specification defines the
   Tx timer (as defined in Section 13), which is used by the
   credit-control client to supervise communication with the
   credit-control server.  When the Tx timer elapses, the credit-control
   client takes action for the end user according to the CCFH.

   When the Tx timer expires, the Diameter Credit-Control client always
   terminates the service if the CCFH is set to the value TERMINATE.
   The credit-control session may be moved to an alternative server only
   if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER
   is received before the Tx timer expires.  Therefore, the value
   TERMINATE is not appropriate if proper failover behavior is desired.

   If the CCFH is set to the value CONTINUE or RETRY_AND_TERMINATE, the
   service will be granted to the end user when the Tx timer expires.
   An Answer message with granted units may arrive later if the base
   protocol transport failover occurred in the path to the
   credit-control server.  (The Twinit default value is 3 times more
   than the recommended Tx timeout value.)  The credit-control client
   SHOULD grant the service to the end user, start monitoring resource
   usage, and wait for the possible late answer until the timeout of the
   request (e.g., 120 seconds).  If the request fails and the
   CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the
Top   ToC   Page 44
   credit-control client terminates or continues the service --
   depending on the value set in the CCFH -- and MUST free all the
   reserved resources for the credit-control session.  If the protocol
   error DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or
   the request times out and the CC-Session-Failover AVP is set to
   FAILOVER_SUPPORTED, the credit-control client MAY send the request to
   a backup server, if possible.  If the credit-control client receives
   a successful answer from the backup server, it continues the
   credit-control session with such a server.  If the retransmitted
   request also fails, the credit-control client terminates or continues
   the service -- depending on the value set in the CCFH -- and MUST
   free all the reserved resources for the credit-control session.

   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 secondary
   credit-control servers.  Implementations supporting credit-control
   session failover MUST also ensure proper detection of duplicate or
   out-of-sequence messages.  Communication between the servers is
   regarded as an implementation issue and is outside the scope of this
   specification.

6.  One-Time Event

   The one-time event is used when there is no need to maintain any
   state in the Diameter Credit-Control server -- for example, inquiring
   about the price of the service.  The use of a one-time event implies
   that the user has been authenticated and authorized beforehand.
Top   ToC   Page 45
   The one-time event can be used when the credit-control client wants
   to know the cost of the service event or to check the account balance
   without any credit reservations.  It can also be used for refunding
   service units on the user's account or for direct debiting without
   any credit reservations.  The one-time event is shown in Figure 8.

                                          Diameter
   End User        Service Element        AAA Server        CC Server
                       (CC Client)
     | Service Request   |                    |                    |
     |------------------>|                    |                    |
     |                   | CCR(Event)         |                    |
     |                   |------------------->| CCR(Event)         |
     |                   |                    |------------------->|
     |                   |                    |  CCA(Granted-Units)|
     |                   |  CCA(Granted-Units)|<-------------------|
     |  Service Delivery |<-------------------|                    |
     |<----------------->|                    |                    |

                         Figure 8: One-Time Event

   In environments such as the 3GPP architecture, the one-time event can
   be sent from the Service Element directly to the credit-control
   server.

6.1.  Service Price Inquiry

   The credit-control client may need to know the price of the service
   event.  Services offered by application service providers whose
   prices are not known in the credit-control client might exist.  The
   end user might also want to get an estimate of the price of a service
   event before requesting it.

   A Diameter Credit-Control client requesting the cost information MUST
   set the CC-Request-Type AVP equal to EVENT_REQUEST, include the
   Requested-Action AVP set to PRICE_ENQUIRY, and set the requested
   service event information in the Service-Identifier AVP in the
   Credit-Control-Request message.  Additional service event information
   may be sent as service-specific AVPs or within the Service-Parameter-
   Info AVP.  The Service-Context-Id AVP indicates the service-specific
   document applicable to the request.

   The credit-control server calculates the cost of the requested
   service event, but it does not perform any account-balance checks or
   credit reservations from the account.
Top   ToC   Page 46
   The estimated cost of the requested service event is returned to the
   credit-control client in the Cost-Information AVP in the
   Credit-Control-Answer message.

6.2.  Balance Checks

   The Diameter Credit-Control client may only have to verify that the
   end user's account balance covers the cost of a certain service
   without reserving any units from the account at the time of the
   inquiry.  This method does not guarantee that credit would be left
   when the Diameter Credit-Control client requests the debiting of the
   account with a separate request.

   A Diameter Credit-Control client requesting a balance check MUST set
   the CC-Request-Type AVP equal to EVENT_REQUEST, include a Requested-
   Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP
   or Subscription-Id-Extension AVP in order to identify the end user in
   the credit-control server.  The Service-Context-Id AVP indicates the
   service-specific document applicable to the request.

   The credit-control server makes the balance check, but it does not
   make any credit reservations from the account.

   The result of the balance check (ENOUGH_CREDIT/NO_CREDIT) is returned
   to the credit-control client in the Check-Balance-Result AVP in the
   Credit-Control-Answer message.

6.3.  Direct Debiting

   There are certain service events for which service execution is
   always successful in the service environment.  The delay between the
   service invocation and the actual service delivery to the end user
   can be sufficiently long that the use of session-based credit-control
   would lead to unreasonably long credit-control sessions.  In these
   cases, the Diameter Credit-Control client can use the one-time event
   scenario for direct debiting.  The Diameter Credit-Control client
   SHOULD be sure that the requested service event execution would be
   successful when this scenario is used.

   In the Credit-Control-Request message, the CC-Request-Type AVP is set
   to the value EVENT_REQUEST and the Requested-Action AVP is set to
   DIRECT_DEBITING.  The Subscription-Id AVP or Subscription-Id-
   Extension AVP SHOULD be included to identify the end user in the
   credit-control server.  The Event-Timestamp AVP SHOULD be included in
   the request and contain the time when the service event is requested
   in the Service Element.  The Service-Context-Id AVP indicates the
   service-specific document applicable to the request.
Top   ToC   Page 47
   If it knows the cost of the service event, the Diameter
   Credit-Control client MAY include in the Requested-Service-Unit AVP
   the monetary amount to be charged.  If the Diameter Credit-Control
   client does not know the cost of the service event, the Requested-
   Service-Unit AVP MAY contain the number of requested service events.
   The Service-Identifier AVP always indicates the service concerned.
   Additional service event information to be rated MAY be sent as
   service-specific AVPs or within the Service-Parameter-Info AVP.

   The credit-control server SHOULD rate the service event and deduct
   the corresponding monetary amount from the end user's account.  If
   the type of the Requested-Service-Unit AVP is "money", no rating is
   needed, but the corresponding monetary amount is deducted from the
   end user's account.

   The credit-control server returns the Granted-Service-Unit AVP in the
   Credit-Control-Answer message to the Diameter Credit-Control client.
   The Granted-Service-Unit AVP contains the amount of service units
   that the Diameter Credit-Control client can provide to the end user.
   The type of the Granted-Service-Unit can be time, volume, service-
   specific, or money, depending on the type of service event.

   If the credit-control server determines that no credit-control is
   needed for the service, it can include the result code indicating
   that the credit-control is not applicable (e.g., the service is free
   of charge).

   For informative purposes, the Credit-Control-Answer message MAY also
   include the Cost-Information AVP containing the estimated total cost
   of the requested service.

6.4.  Refunds

   Some services may refund service units to the end user's account --
   for example, gaming services.

   The credit-control client MUST set the CC-Request-Type AVP to the
   value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in
   the Credit-Control-Request message.  The Subscription-Id AVP or
   Subscription-Id-Extension AVP SHOULD be included to identify the
   end user in the credit-control server.  The Service-Context-Id AVP
   indicates the service-specific document applicable to the request.

   The Diameter Credit-Control client MAY include the monetary amount to
   be refunded in the Requested-Service-Unit AVP.  The Service-
   Identifier AVP always indicates the service concerned.  If the
   Diameter Credit-Control client does not know the monetary amount to
Top   ToC   Page 48
   be refunded, in addition to the Service-Identifier AVP it MAY send
   service-specific AVPs or the Service-Parameter-Info AVP containing
   additional service event information to be rated.

   For informative purposes, the Credit-Control-Answer message MAY also
   include the Cost-Information AVP containing the estimated monetary
   amount of refunded units.

6.5.  Failure Procedure

   Failover to an alternative credit-control server is allowed for a
   one-time event, as the server is not maintaining session states.  For
   instance, if the credit-control client receives a protocol error
   DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can resend the
   request to an alternative server, if possible.  There MAY be
   protocol-transparent Diameter relays and redirect agents or Diameter
   Credit-Control proxies between the credit-control client and
   credit-control server.  Failover may occur at any point in the path
   between the credit-control client and the credit-control server if a
   transport failure is detected with a peer, as described in [RFC6733].
   Because there can be duplicate requests for various reasons, the
   credit-control server is responsible for real-time duplicate
   detection.  Implementation issues for duplicate detection are
   discussed in [RFC6733], Appendix C.

   When the credit-control client detects a communication failure with
   the credit-control server, its behavior depends on the requested
   action.  The Tx timer (as defined in Section 13) is used in the
   credit-control client to supervise communication with the
   credit-control server.

   If the requested action is PRICE_ENQUIRY or CHECK_BALANCE and a
   communication failure is detected, the credit-control client SHOULD
   forward the request messages to an alternative credit-control server,
   if possible.  The secondary credit-control server name, if received
   from the home Diameter AAA server, can be used as an address of the
   backup server.

   If the requested action is DIRECT_DEBITING, the DDFH controls the
   credit-control client's behavior.  The DDFH may be received from the
   home Diameter AAA server or may be locally configured.  The
   credit-control server may also send the DDFH in any CCA messages to
   be used for direct-debiting events compiled thereafter.  The DDFH
   value received from the home Diameter AAA server overrides the
   locally configured value, and the DDFH value received from the
   credit-control server in a Credit-Control-Answer message always
   overrides any existing values.
Top   ToC   Page 49
   If the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client
   SHOULD NOT grant the service if, after a possible retransmission
   attempt to an alternative credit-control server, the credit-control
   client can eventually determine from the result code or error code in
   the Answer message that units have not been debited.  Otherwise, the
   credit-control client SHOULD grant the service to the end user and
   store the request in credit-control application-level non-volatile
   storage.  (Note that resending the request at a later time is not a
   guarantee that the service will be debited, as the user's account may
   be empty when the server successfully processes the request.)  The
   credit-control client MUST mark these request messages as possible
   duplicates by setting the T flag in the command header as described
   in [RFC6733], Section 3.

   If the DDFH is set to CONTINUE, the service SHOULD be granted, even
   if credit-control messages cannot be delivered and messages are not
   buffered.

   If the Tx timer expires, the credit-control client MUST continue the
   service and wait for a possible late answer.  If the request
   times out, the credit-control client retransmits the request (marked
   with the T flag) to a backup credit-control server, if possible.  If
   the retransmitted request also times out or if a temporary error is
   received in answer, the credit-control client buffers the request if
   the value of the DDFH is set to TERMINATE_OR_BUFFER.  If a failed
   answer is received for the retransmitted request, the credit-control
   client frees all the resources reserved for the event message and
   deletes the request regardless of the value of the DDFH.

   The Credit-Control-Request with the requested action REFUND_ACCOUNT
   should always be stored in credit-control application-level
   non-volatile storage in case a temporary failure occurs.  The
   credit-control client MUST mark the retransmitted request message as
   a possible duplicate by setting the T flag in the command header as
   described in [RFC6733], Section 3.

   For stored requests, the implementation may choose to limit the
   number of retransmission attempts and to define a retransmission
   interval.

   Note that only one entity in the credit-control system SHOULD be
   responsible for duplicate detection.  If there is only one
   credit-control server within the given realm, the credit-control
   server may perform duplicate detection.  If there is more than one
   credit-control server in a given realm, only one entity in the
   credit-control system should be responsible, to ensure that the
   end user's account is not debited or credited multiple times for the
   same service event.


Next Section