3GPP2 X.P0013.013-A v0.1 IMS Online Accounting Stage-2/3 by 1q981Zt

VIEWS: 13 PAGES: 58

									1    3GPP2 X.S0013-015-0-A

2    Version 0.12

3    Date: June 2005

4

5

6


7     All-IP Core Network Multimedia Domain
8


9    IP Multimedia Subsystem - Online Accounting
10   Information Flows and Protocol
11

12

13

14

15

16

17

18

19
     COPYRIGHT NOTICE
     3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners
     may copyright and issue documents or standards publications in individual Organizational Partner's name based on
     this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at
     secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed to
     that Organizational Partner. See www.3gpp2.org for more information.
20
21
    X.P0013-0153


1   This page intentionally left blank.
                                                                                                                                            X.P0013-0153


1                                       All-IP Core Network Multimedia Domain
2        IP Multimedia Subsystem - Online Accounting Information Flows and
3                                    Protocol
4                                                                         Contents

5    1      SCOPE ........................................................................................................................................... 1

6    2      REFERENCES............................................................................................................................... 1

7    3      DEFINITIONS, SYMBOLS AND ABBREVIATIONS..................................................................... 2

8    3.1       Definitions ................................................................................................................................................2

9    3.2       Symbols ....................................................................................................................................................2

10   3.3       Abbreviations[1] ......................................................................................................................................2

11   4      ONLINE CHARGING ..................................................................................................................... 3

12   4.1      Implementation of Online Charging......................................................................................................3
13      4.1.1     Usage of the Ro Interface ..................................................................................................................4
14      4.1.2     Usage of ISC Interfaces.....................................................................................................................4

15   4.2      Diameter Protocol Basic Principles and Use .........................................................................................4
16      4.2.1     Basic Principles .................................................................................................................................5
17      4.2.2     Application Requirement for the Base Protocol ................................................................................5

18   4.3      Functions within the OCS ......................................................................................................................5
19      4.3.1     Charging Functions ...........................................................................................................................5
20      4.3.2     Diameter Message Flows and Types .................................................................................................6
21      4.3.3     Immediate Event Charging (IEC)......................................................................................................6

22   4.4      Online Charging Basics ..........................................................................................................................7
23      4.4.1     Basic principles of online charging ...................................................................................................8
24      4.4.2     Basic Operations and Scenarios ........................................................................................................8

25   4.5      Charging Flow Scenarios ........................................................................................................................9
26      4.5.1     Immediate Event Charging................................................................................................................9
27      4.5.2     Event charging with Reservation .................................................................................................... 13

28   5      BASIC PRINCIPLES FOR DIAMETER ONLINE CHARGING ................................................... 25

29   5.1       Online Specific Credit Control Application Requirements ...............................................................25

30   5.2      Diameter Description on the Ro Interface ..........................................................................................25
31      5.2.1     Basic Principles ...............................................................................................................................25
32      5.2.2     Immediate Event Charging (IEC).................................................................................................... 26
33      5.2.3     Event Charging with Unit Reservation (ECUR) ............................................................................. 27
34      5.2.4     Session Charging with Unit Reservation (SCUR)........................................................................... 29


                                                                                       i
     X.P0013-0153


1        5.2.5         Error Cases and Scenarios .............................................................................................................. 30

2    5.3      Support of Tariff Changes During an Active User Session ............................................................... 30
3       5.3.1     Support of Tariff Changes using the Tariff Switch Mechanism ..................................................... 30
4       5.3.2     Support of Tariff Changes using Validity Time AVP .................................................................... 31

5    5.4         Support of Re-authorization ................................................................................................................ 31

6    6      MESSAGE FORMATS FOR ONLINE ......................................................................................... 31

 7   6.1      Summary of Online Charging Message Formats ............................................................................... 31
 8      6.1.1    General............................................................................................................................................ 31
 9      6.1.2    Structure for the Credit Control Message Formats ......................................................................... 32
10      6.1.3    Credit-Control-Request Message .................................................................................................... 32
11      6.1.4    Credit-Control-Answer Message .................................................................................................... 34
12      6.1.5    Re-Auth-Request Message ............................................................................................................. 36
13      6.1.6    Re-Auth-Answer Message .............................................................................................................. 37
14      6.1.7    Capabilities-Exchange-Request Message ....................................................................................... 37
15      6.1.8    Capabilities-Exchange-Answer Message........................................................................................ 37
16      6.1.9    Device-Watchdog-Request Message .............................................................................................. 37
17      6.1.10   Device-Watchdog-Answer Message ............................................................................................... 37

18   7      DATA DESCRIPTION FOR IMS ONLINE CHARGING .............................................................. 38

19   7.1      Diameter message contents .................................................................................................................. 38
20      7.1.1     Summary of Online Charging Message Formats ............................................................................ 38
21      7.1.2     Structure for the Credit Control Message Formats ......................................................................... 38

22   7.2      AVPs for IMS Online Charging on the Ro interface ......................................................................... 43
23      7.2.1    Definition of the IMS-Information AVP ........................................................................................ 44

24   8      AVPS USED FOR ONLINE CHARGING .................................................................................... 45

25   8.1      AVPs for Online Charging Credit Control......................................................................................... 45
26      8.1.1    Diameter Credit Control AVPs ....................................................................................................... 47
27      8.1.2    3GPP2 Specific Credit Control AVPs ............................................................................................ 47
28
29
30




                                                                                     ii
                                                                                                                              X.P0013-0153



1    List of Figures
2    Figure 1: Immediate Event Charging with Centralized Rating and Decentralized Unit Determination ............. 10
3    Figure 2: Immediate Event Charging with Centralized Rating and Centralized Unit Determination ................. 11
4    Figure 3: Immediate Event Charging with Decentralized Rating and Decentralized Unit Determination.......... 12
5    Figure 4: Event Charging with Reservation / Decentralized Unit Determination and Centralized Rating ......... 14
6    Figure 5: Event Charging with Reservation / Centralized Unit Determination and Centralized Rating ............. 16
7    Figure 6: Event Charging with Reservation / Centralized Unit Determination and Centralized Rating ............. 18
8    Figure 7: Session Charging with Reservation / Decentralized Unit Determination and Centralized Rating ...... 20
9    Figure 8: Session Charging with Reservation / Centralized Unit Determination and Centralized Rating .......... 22
10   Figure 9: Session Charging with Reservation / Centralized Unit Determination and Centralized Rating .......... 24
11   Figure 10: IEC Direct Debiting Operation .......................................................................................................... 26
12   Figure 11: ECUR for session based credit control ..............................................................................................27
13   Figure 12: SCUR for session based credit control ..............................................................................................29
14
15




                                                                              iii
     X.P0013-0153



1    List of Tables
2    Table 1 : Online Charging Messages Reference ................................................................................................. 32
3    Table 2 : Credit-Control-Request (CCR) Message Contents for Online Charging ............................................. 32
4    Table 3 : Credit Control Answer (CCA) Message Contents for Online Charging.............................................. 34
5    Table 4 : Re-Auth-Request (RAR) Message Contents for Online Charging ...................................................... 36
6    Table 5 : Re-Auth-Answer (RAA) Message Contents for Online Charging ...................................................... 37
7    Table 6 : Online Charging Messages Reference Table ....................................................................................... 38
8    Table 7 : Credit-Control-Request (CCR) Message Contents for MRFC ............................................................ 38
9    Table 8 : Credit-Control-Request (CCR) Message Contents for AS .................................................................. 40
10   Table 9 : Credit-Control-Request (CCR) Message Contents for IMS-GWF ...................................................... 41
11   Table 10 :Credit-Control-Answer (CCA) Message Contents for MRFC, AS and IMS-GWF ........................... 42
12   Table 11 : Structure of the IMS-Information AVP ............................................................................................. 44
13   Table 12 : Use Of Diameter Credit Control ........................................................................................................ 46
14




                                                                              iv
                                                                                          X.P0013-0153



1    Foreword
2    This document contains portions of material copied from 3GPP document number(s) TS 32.240, TS 32.298
3    and TS32.299. The copyright on the 3GPP document is owned by the Organizational Partners of 3GPP (ARIB
4    - Association of Radio Industries and Businesses, Japan; CWTS – China Wireless Telecommunications
5    Standards group, China; ETSI – European Telecommunications Standards Institute; ATIS, USA; TTA -
6    Telecommunications Technology Association, Korea; and TTC – Telecommunication Technology Committee,
7    Japan), which have granted license for reproduction and for use by 3GPP2 and its Organizational Partners.
8
9

10   Revision History
11
                                                  REVISION HISTORY
      Revision number     Content changes.                                               Date
      A, v0.1             Initial Draft                                                  April 2005
      A, v0.2             Second Draft – Changes based on the following contributions;   June 2005
                                1. X32-20050516-011                                                              Formatted: Bullets and Numbering
                                2. X32020050516-012
12
13




                                                         v
                                                                                                  X.P0013-0153




1    1 Scope
2    The present document covers online charging for the IMS. For clarity, the terms Offline Charging and Online
3    charging as applied to the IMS are defined here in clause 3. These definitions are the same as listed in [1].
4    The IMS charging architecture details, requirements, definitions and principles are listed in [1] and therefore
5    are not repeated here.
6    In the present document the charging data triggers, message content and format are specified along with the
7    transport of these messages using the Diameter protocol. Details about Online Charging scenarios, data
8    descriptions, and the definitions for Diameter AVPs are also included in the present document.


9    2 References
10   The following documents contain provisions, which through references in this text, constitute provisions of the
11   present document.
12          References are either specific (identified by date of publication, edition number, version number, etc.)
13           or non-specific.

14          For a specific reference, subsequent revisions do not apply.

15          For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP2 document
16           a non-specific reference implicitly refers to the latest version of that document in the same Release as
17           the present document.

18   [1]      3GPP2 X.S0013-007-A: “IP Multimedia Subsystem, Charging Architecture”

19            TIA-873-007-A: “IP Multimedia Subsystem, Charging Architecture”

20   [2]      3GPP2 X.S0013-002-A: IP Multimedia Subsystem (IMS); Stage 2

21            TIA 873-002-1: “IP Multimedia Subsystem (IMS); Stage 2

22            3GPP2 X.S0013-008-A “IP Multimedia Subsystem Offline Accounting Flows and Protocol-“

23            TIA-873-008-A “IP Multimedia Subsystem Offline Accounting Flows and Protocol-“Void

24   [3]      IETF RFC 3588: "Diameter Base Protocol"

25   [4]      3GPP2 S.S0086-0: “3GPP2 IMS Security Framework”

26   [5]      3GPP2 X.S0013-003-A: IP Multimedia (IM) session handling; IM call model; Stage 2”

27            TIA 873-003-1: “IP Multimedia (IM) session handling; IM call model; Stage 2”

28            3GPP2 X.S0013-003-A: "IP Multimedia (IM) session handling; IM call model; Stage 2"

29            TIA-873-003: "IP Multimedia (IM) session handling; IM call model; Stage 2"

30   [5]

31   [6]      IETF RFC 2486: "The Network Access Identifier"

32   [7]      3GPP2 X.S0011-C: “cdma2000®1 Wireless IP Network Standard”

     1
       cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the
     Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a
     registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.


                                                              1
     X.P0013-0153


1               TIA -835-C: “cdma2000 Wireless IP Network Standard”

2    [8]        ITU-T Recommendation X.690: "Information technology - ASN.1 encoding rules: Specification of
3               Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
4               (DER)"

5    [9]        ITU-T Recommendation X.691: "Information technology - ASN.1 encoding rules: Specification of
6               Packed Encoding Rules (PER)"

7    [10]       ITU-T Recommendation X.693: "Information Technology - ASN.1 encoding rules: XML encoding
8               Rules (XER)"

9    [11] 3GPP2 X.S0013-004-A: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3"

10              TIA-873-004: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3"

11   [12]       IETF RFC 3455: "Private Extensions to the Session Initiation Protocol (SIP) for the 3rd Generation
12              Partnership Projects (3GPP)"

13   [13]       IETF RFC 3261: "SIP: Session Initiation Protocol"

14   [14]       IETF RFC 2327: "SDP: Session Description Protocol"

15   [15]       IETF RFC 3266: "Support for IPv6 in Session Description Protocol"

16   [16]       3GPP2 X.S0013-002-A: "IP Multimedia Subsystem (IMS); Stage 2"

17              TIA -873-002: "IP Multimedia Subsystem (IMS); Stage 2"

18   [17]       3GPP2 X.S0013-006-A: "Cx Interface based on the Diameter protocol; Protocol Details"

19              TIA -873-006: "Cx Interface based on the Diameter protocol; Protocol Details"


20   3 Definitions, symbols and abbreviations
21   3.1        Definitions
22   For the purposes of the present document, the following terms and definitions apply:
23   offline charging: charging mechanism where charging information does not affect, in real-time, the service
24   rendered
25   online charging: charging mechanism where charging information can affect, in real-time, the service
26   rendered and therefore a direct interaction of the charging mechanism with session/service control is required

27   3.2        Symbols
28   For the purposes of the present document, the following symbols apply:
29         Rf                 Offline Charging Reference Point between an IMS Network Entity or an AS and AAA
30         Ro                 Online Charging Reference Point between an AS or MRFC and the ECF
31   3.3        Abbreviations[1]
32   For the purposes of the present document, the abbreviations defined in and the following apply:
33         AAA                Authentication, Authorization and Accounting
34         ACR                ACounting Request
35         AIR                Accounting Information Record
36         AoC                Advice of Charge
37         AS                 Application Server


                                                               2
                                                                                                 X.P0013-0153


 1      BCF               Bearer Charging Function
 2      BGCF              Breakout Gateway Control Function
 3      CCA               Credit Control Answer
 4      CCF               Call Control function
 5      CCR               Credit Control Request
 6      CDF               Charging Data Function
 7      CSCF              Call Session Control Function
 8      CTF               Charging Trigger Function
 9      ECF               Event Charging Function
10      ECUR              Event Charging with Unit Reservation
11      HTTP              HyperText Transfer Protocol
12      IEC               Immediate Event Charging
13      IMS               IP Multimedia core network Subsystem
14      IP                Internet Protocol
15      ISC               IMS Service Control
16      LCS               LoCation Services
17      MGCF              Media Gateway Control Function
18      MMS               Multimedia Messaging Service
19      MRFC              Multimedia Resource Function Controller
20      OCS               Online Charging System
21      P-CSCF            Proxy CSCF
22      PS                Packet-Switched
23      SCF               Session Charging Function
24      S-CSCF            Serving CSCF
25      SIP               Session Initiation Protocol
26      WLAN              Wireless Local Area Network
27      XML               eXtensible Markup Language

28   4 Online Charging
29   Online charging is a process where charging information for network resource usage is collected concurrently
30   with that resource usage in the same fashion as in offline charging. However, authorization for the network
31   resource usage must be obtained by the network prior to the actual resource usage to occur. This authorization
32   is granted by the Online Charging System upon request from the network.
33   When receiving a network resource usage request, the network assembles the relevant charging information
34   and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource
35   usage authorization. The resource usage authorization may be limited in its scope (e.g. volume of data or
36   duration), therefore the authorization may have to be renewed from time to time as long as the user’s network
37   resource usage persists.
38   Note that the charging information utilized in online charging is not necessarily identical to the charging
39   information employed in offline charging.
40   In conclusion, online charging is a mechanism where charging information can affect, in real-time, the service
41   rendered and therefore a direct interaction of the charging mechanism with the control of network resource
42   usage is required.

43   4.1    Implementation of Online Charging
44   Three cases for online charging are distinguished:
45       Immediate Event Charging (IEC); and

46       Event Charging with Unit Reservation (ECUR), and

47       Session Charging with Unit Reservation (SCUR)




                                                             3
     X.P0013-0153


1    In the case of Immediate Event Charging (IEC), granting units to the IMS network element is performed in a
2    single operation that also includes the deduction of the corresponding monetary units from the subscriber's
3    account. The charging process is controlled by the corresponding credit control request which is sent for a
4    given credit control event.
5    In contrast, Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving,
6    releasing and returning unused units for events. The deduction of the corresponding monetary units then occurs
7    upon conclusion of the ECUR transaction. In this case, the credit control request is used to control the credit
8    control session.
 9   Session Charging with Unit Reservation (SCUR) is used for credit control of sessions. SCUR also includes the
10   process of requesting, reserving, releasing and returning unused units for sessions, and the deduction of the
11   corresponding monetary units. During a SIP session there can be repeated execution of unit reservation and
12   debit operations as specified in TS 32.299 [50].
13   The IMS network element may apply IEC, where CCR Event messages are generated, or ECUR, using CCR
14   Initial, and Termination or SCUR. The decision whether to apply IEC, ECUR or SCUR is based on the service
15   and/or operator's policy.
16      NOTE:      To the extent possible alignment with the IETF Credit Control Application, [402], is planned.
17                 However, this can only be accomplished when the current IETF draft receives an official RFC
18                 status.

19   4.1.1 Usage of the Ro Interface
20   Online charging for both events and sessions between network element and the OCF is performed using the Ro
21   reference point. The Ro reference point supports integrity protection and authentication for the case that the
22   network element is outside the operator domain.
23   The IMS charging architecture, described in [1], specifies that for online charging the Ro interface is used by
24   the AS and MRFC towards the Event Charging Function and the ISC interface is used between the S-CSCF
25   and the Session ChargingIMS Gateway Function. The IMS Gateway Function connects to the Session
26   Charging Function via the Ro interface. The rules governing the selection of the proper interfaces are described
27   in the subclauses below.
28   The AS and MRFC are able to apply offline or online charging based on the information (AAA and/or ECF
29   address) the AS/MRFC receives in the SIP signaling and the system configuration as provisioned by the
30   operator. If the AS/MRFC only receives the AAA address and does not receive an ECF address then only the
31   offline Rf interface is used. If only the ECF address was provided then only the Ro interface is used. In cases
32   where both AAA and ECF addresses are provided it is possible to use both interfaces simultaneously.
33   However, operators may overrule the addresses received via the SIP signalling and use their own configured
34   rules instead. Operators may configure locally on the AS/MRFC an ECF and/or AAA address. The AAA
35   address may be locally configured on all other IMS nodes. The choice of whether the IMS nodes use the
36   locally configured addresses or the addresses received by SIP signalling, and the decision on which interface(s)
37   to use, is left to the operator.

38   4.1.2 Usage of ISC Interfaces
39   The S-CSCF supports online charging using the ISC interface, (i.e. if the application server addressed over ISC
40   is the Session Charging Function of the OCS), and an IMS gateway Function.

41   4.2    Diameter Protocol Basic Principles and Use
42   The present document defines an IMS charging Diameter application, which utilizes the Diameter Base
43   Protocol [3]. This application is used for both online and offline charging. The generic description of the
44   protocol is provided in the subclauses below while the portions of the protocol application associated with
45   online charging is described in clause 6. Portions of the protocol application associated with offline charging is
46   described in [2].



                                                             4
                                                                                                  X.P0013-0153


1    4.2.1 Basic Principles
2    The IMS charging Diameter application is based on the following general principles:
3        The basic functionality of Diameter, as defined by the Diameter Base Protocol [3] is re-used in IMS.

4        For offline charging IMS network elements report accounting information to the Authentication,
5         Authorization, and Accounting Entity (AAA). The AAA uses this information to construct and format
6         AIRs. Offline charging is described in [2].

7        For online charging, the AS and MRFC in the IMS network report credit control information to the
8         Event Charging Function (ECF). The ECF uses this information to support the event based charging
9         (content charging) function of the OCS.

10   4.2.2 Application Requirement for the Base Protocol

11   4.2.2.1 Online Specific Base Protocol Requirements
12   In order to support the online charging principles described in the present document, the Diameter client and
13   server must implement at least the following Diameter options listed in [3]:
14       To send/receive Abort-Session-Request.

15       To send/receive Abort-Session-Answer.

16   All other options of the Diameter Base Protocol are beyond the scope of the present document.
17    A configurable timer is supported in the CCFCDF to supervise the reception of the ACR [Interim] and/or
18   ACR [Stop]. An instance of the ‘Timer’ is started at the beginning of the accounting session, reset on the
19   receipt of an ACR [Interim] and stopped at the reception of the ACR [Stop]. Upon expiration of the timer, the
20   CCFCDF stops the accounting session with the appropriate error indication. For Online Charging, the client
21   implements the state machine described in [3]. The server (P-CSCF, I-CSCF, S-CSCF, MGCF or BGCF)
22   implements the STATELESS ACCOUNTING state machine as specified in [3], i.e. there is no order in which
23   the server expects to receive the accounting information.

24   4.2.2.2 Security Considerations
25   Diameter security is addressed in the base protocol [3]. Network security is specified in [4].

26   4.3    Functions within the OCS

27   4.3.1 Charging Functions

28   4.3.1.1 Event Charging Function (ECF)
29   The ECF performs event based charging (e.g. content charging) based on service usage requests received from
30   the network. It can grant or deny the service usage in the network. It communicates with the Rating Function in
31   order to determine the value of the requested service usage. It communicates with the Account Balance
32   Management Function to query and update the subscribers' account and counters status.

33   4.3.1.2 Session Charging Function (SCF)
34   The SCF performs charging of sessions based on session resource usage requests received from the network
35   (e.g. the IMS CSCF). It controls sessions in the network, e.g. it has the ability to grant or deny a session setup
36   request and to terminate an existing session. It communicates with the Rating Function in order to determine
37   the value of the requested session. It communicates with the Account Balance Management Function to query
38   and update the subscribers' account and counters status.
39



                                                              5
     X.P0013-0153


1    4.3.2 Diameter Message Flows and Types
2    This clause describes the message flows for the event charging procedures on the Ro interface.

3    4.3.3 Immediate Event Charging (IEC)
4    This clause provides the details of the "Debit Units" operation specified in TS 32.299 [50].


5    4.3.3.1.1 Message Flows - Successful Cases and Scenarios


6    4.3.3.1.2 IEC – Debit Units Operation

 7   The transactions that are required on the Ro interface in order to perform IEC with Debit Units operations are
 8   carried out as described in TS 32.299 [50] where “CTF” refers to IMS network element. The Debit Units
 9   operation may alternatively be carried out prior to, concurrently with or after service/content delivery. The IMS
10   network element must ensure that the requested service execution is successful, when this scenario is used.


11   4.3.3.1.3 Message Flows - Error Cases and Scenarios

12   This clause describes various error cases and how these should be handled.
13   The failure handling behaviour is locally configurable in the IMS network element. If the Direct-Debiting-
14   Failure-Handling AVP is not used, the locally configured values are used instead.


15   4.3.3.1.4 Reception of SIP Error Messages

16   If SIP errors in SIP response (4xx, 5xx or 6xx) occur during service delivery, as defined in TS 24.228 [202]
17   and TS 23.218 [203], it is up to the IMS network element to determine to what extent the service was delivered
18   before the error occurred and act appropriately with respect to charging. This may imply that no units at all (or
19   no more units) are debited.


20   4.3.3.1.5 Debit Units Operation Failure

21   This case comprises situations where either no, or an erroneous response, is received from the ECF. The “no
22   response” case is detected by the IMS network element when the connection supervision timer Tx expires
23   [40`2] before a response Credit-Control-Answer (CCA) is received. The case of receiving an erroneous
24   response implies that the IMS network element receives a Credit-Control-Answer (CCA), which it is unable to
25   process, while Tx is running. The failure handling complies with the failure procedures for "Direct Debiting"
26   scenario described in [402].


27   4.3.3.1.6 Duplicate Detection

28   The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as
29   possible the duplicate detection, the all-against-all record checking should be avoided and just those records
30   marked as potential duplicates need to be checked against other received requests (within a reasonable time
31   window) by the receiver entity. For duplicate detection only one place in the credit-control system should
32   perform duplicate detection to ensure that the end user's account is not debited or credited multiple times for
33   the same service event.
34   The IMS network element marks the request messages that are retransmitted after a link failover as possible
35   duplicates with the T-flag as described in [201]. For optimized performance, uniqueness checking against other
36   received requests is only necessary for those records marked with the T-flag received within a reasonable time
37   window. This focused check is based on the inspection of the Session-Id and CC-Request-Number AVP pairs.



                                                            6
                                                                                                 X.P0013-0153


1    4.3.3.2 Event Charging with Unit Reservation (ECUR) and Session Charging with Unit
2            Reservation (SCUR)
3    This clause provides the details of the "Reserve Units" operation specified in TS 32.299 [50].

4    4.3.3.2.1 Message Flows - Successful Cases and Scenarios


5    4.3.3.2.2 ECUR and SCUR - Reserve Units Operations

6    The transactions that are required on the Ro interface in order to perform ECUR/SCUR with Reserve Units
7    operations is carried out as described in [32.299] where “CTF” refers to an IMS network element. Multiple
8    replications of both of these operations are possible.
9    4.3.3.2.2.1 Expiration of Reservation Validity
10   This clause defines how reserved units are returned, if not used, within a reasonable time. It should be possible
11   that both the reservation and SIP sessions are cancelled or only the reservation is cancelled without removing
12   the SIP session.


13   4.3.3.2.3 Message Flows - Error Cases and Scenarios

14   This clause describes various error cases and how these should be handled.
15   The failure handling behaviour is locally configurable in the IMS network element. If Credit-Control-Failure-
16   Handling AVP is not used, the locally configured values are used instead.


17   4.3.3.2.4 Reception of SIP Error Messages

18   If SIP errors occur during service delivery, as defined in [202] and [203], it is up to the IMS network element
19   to determine to what extent the service was delivered before the error occurred and act appropriately with
20   respect to charging. This may imply that no units at all (or no more units) are reserved or debited.

21   4.3.3.2.5   Reserve Units and Debit Units Operation Failure

22   This case comprises of OCS connection failure, and/or receiving error responses from the OCS.
23   The IMS network element detects an OCS connection failure when the timer Tx expires [402] or a transport
24   failure is detected as defined in [401]. The OCS also has the capability to detect failures when the timer Ts
25   [401] expires. The OCS should indicate the cause of failure by setting the appropriate result code as defined in
26   [401] and [402]. In any case, the failure handling of IMS network element and OCS complies with the failure
27   procedures for session based credit control scenario described in [402].

28   4.3.3.2.6   Duplicate Detection

29   For credit control duplicate detection is performed only for possible duplicate event requests related to IEC as
30   mentioned in clause 5.1.2.1.2.3, as retransmission of ECUR/SCUR related credit control requests is not
31   allowed.

32   4.4    Online Charging Basics
33




                                                             7
     X.P0013-0153


1    4.4.1 Basic principles of online charging
2    There are two sub-functions for online charging that affect online charging principles and require a more
3    detailed description: rating and unit determination. Both rating and unit determination can be implemented
4    centralized, i.e. on the OCF, or decentralized, that is, on the network element.
5    Unit determination refers to the calculation of the number of non-monetary units (service units, data volume,
6    time and events) that shall be assigned prior to starting service delivery.
7       With Centralized Unit Determination, the OCF determines the number of non-monetary units that a certain
8        service user can consume based on a service identifier received from the network element.
 9      With the Decentralized Unit Determination approach, the network element determines itself how many
10       units are required to start service delivery, and requests these units from the OCF.
11   After checking the service user's account balance, the OCF returns the number of granted units to the network
12   element. The network element is then responsible for the supervision of service delivery. Particularly, the
13   network element shall limit service delivery to the corresponding number of granted units.
14   Rating refers to the calculation of a price out of the non-monetary units calculated by the unit determination
15   function.
16      With the Centralized Rating approach, the network element and the OCF exchange information about non-
17       monetary units. The OCF translates these units into monetary units.
18      With the Decentralized Rating approach, the corresponding rating control is performed within the network
19       element. Consequently, network element and OCF exchange information about monetary units.
20   Three cases for online charging can be distinguished: immediate event charging (IEC), event charging with
21   unit reservation (ECUR) and session charging with unit reservation (SCUR).

22   4.4.2 Basic Operations and Scenarios
23   Immediate event charging is performed by the use of the "Debit Units" operation:
24      "Debit Units Request"; sent from network element  OCF
25       After receiving a service request from the subscriber, the network element sends a Debit Units Request to
26       the OCF. The network element may either specify a service identifier (centralised unit determination) or
27       the number of units requested (decentralised unit determination).
28      "Debit Units Response"; sent from OCF  network element
29       The OCF replies with a Debit Units Response, which informs the network element of the number of units
30       granted as a result of the Debit Units Request. This includes the case where the number of units granted
31       indicates the permission to render the requested service.
32   In addition, the "Reserve Units" operation is used in case of charging with reservation:
33      "Reserve Units Request"; sent from network element  OCF
34       Request to reserve a number of units for the service to be provided by an network element. In case of
35       centralised unit determination, the network element specifies a service identifier in the Reserve Unit
36       Request, and the OCF determines the number of units requested. In case of decentralised unit
37       determination, the number of units requested is specified by the network element.
38      "Reserve Units Response"; sent from OCF  network element
39       Response from the OCF which informs the network element of the number of units that were reserved as a
40       result of the "Reserve Units Request".
41   The consumed units are deducted from the subscriber's account after service delivery. Thus, the reserved and
42   consumed units are not necessarily the same. Using this operation, it is also possible for the network element to
43   modify the current reservation, including the return of previously reserved units.




                                                             8
                                                                                              X.P0013-0153


1    4.5     Charging Flow Scenarios
 2   In order to perform event charging via Ro, the scenarios between the involved entities UE-A, OCF and
 3   network element need to be defined. The charging flows shown in this subclause include scenarios with
 4   immediate event charging and event charging with reservation. In particular, the following cases are shown:
 5       1) Immediate Event Charging
 6              a) Decentralized Unit Determination and Centralized Rating
 7              b) Centralized Unit Determination and Centralized Rating
 8              c) Decentralized Unit Determination and Decentralized Rating
 9
10      2)    Event charging with Reservation
11             a) Decentralized Unit Determination and Centralized Rating
12             b) Centralized Unit Determination and Centralized Rating
13             c) Decentralized Unit Determination and Decentralized Rating
14
15      3)    Session charging with Reservation – FFS
16
17   The combination of Centralized Unit Determination with Decentralized Rating is not possible.

18   4.5.1 Immediate Event Charging

19   4.5.1.1 Decentralized Unit Determination and Centralized Rating
20   In the following scenario, network element asks the OCF to assign a defined number of units.
21




                                                           9
     X.P0013-0153


       UE-A                                                 OCF                                                                   NE



                                                      1. Request for resource usage




                                      Credit Unit Control
                                                                                                                               2. Units
                                                                                                                             Determination

                                                                              3. Debit Units Request (Non-monetary Units)




                                                       4. Rating
                                                        Control


                                                      5. Account
                                                        Control
                                                                              6. Debit Units Response (Non-monetary Units)




                                                   7. Content/Service Delivery




                                                                               8. Credit Unit Control (cont.)




                                                9. Content/Service Delivery (cont.)




                                                       10. Session released



1
2

3    Figure 1: Immediate Event Charging with Centralized Rating and Decentralized Unit Determination
 4       1.   Request for resource usage: UE-A requests the desired resource from the network element.
 5       2.   Units Determination: depending on the requested service the network element determines the
 6            number of units accordingly.
 7       3.   Debit Units Request: the network element requests the OCF to assign the defined number of units.
 8       4.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that
 9            represents the price for the number of units determined in item 2.
10       5.   Account Control: provided that the user's credit balance is sufficient, the OCF triggers the deduction
11            of the calculated amount from the subscriber's account.
12       6.   Debit Units Response: the OCF informs the network element of the number of granted units.
13       7.   Content/Service Delivery: the network element delivers the content/service at once, in fractions or in
14            individually chargeable items, corresponding to the number of granted units.
15       8.   Credit Unit Control (cont.): this function block is optional and a replication of items 2 to 6.
16       9.   Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with
17            the occurrence of item 8.


                                                                  10
                                                                                                                                X.P0013-0153


1          10. Session released: Session is released.

2    4.5.1.2 Centralized Unit Determination and Centralized Rating
3    In the following scenario, network element asks the OCF to assign units based on the service identifier
4    specified by the network element.
5
            UE-A                                            OCF                                                                     NE



                                                         1. Request for resource usage




                                         Credit Service Control
                                                                                         2. Debit Units Request (Service Key)



                                                         3. Units
                                                       Determination


                                                          4. Rating
                                                           Control


                                                         5. Account
                                                           Control
                                                                                    6. Debit Units Response (Non-monetary Units)




                                                      7. Content/Service Delivery




                                                                                 8. Credit Service Control (cont.)




                                                   9. Content/Service Delivery (cont.)




                                                          10. Session released



6

7         Figure 2: Immediate Event Charging with Centralized Rating and Centralized Unit Determination
 8   1.    Request for resource usage: The UE-A requests the desired resource or content from the network
 9         element.
10   2.    Debit Units Request: depending on the service requested by the UE-A, the network element selects the
11         service identifier and forwards the Debit Units Request to the OCF.
12   3.    Units Determination: the OCF determines the number of non-monetary units needed for the
13         content/service delivery, based on the received service key.
14   4.    Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that
15         represent the price for the number of units determined in item 3.
16   5.    Account Control: provided that the user's credit balance is sufficient, the OCF triggers the deduction of
17         the calculated amount from the subscriber's account.




                                                                     11
     X.P0013-0153


1    6.  Debit Units Response: the OCF informs the network element of the number of granted units. This
2        includes the case where the number of units granted indicates the permission to render the service that was
3        identified by the received service key.
4    7. Content/Service Delivery: the network element delivers the content/service at once, in fractions or in
5        individually chargeable items, corresponding to the number of granted units.
6    8. Credit Service Control (cont.): this function block is optional and a replication of items 2 to 6.
7    9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the
8        occurrence of item 8.
9    10. Session released: the session is released.

10   4.5.1.3 Decentralized Unit Determination and Decentralized Rating
11   In the following scenario, the network element asks the OCF to assure the deduction of an amount of the
12   specified number of monetary units from the subscriber's account.
          UE-A                                             OCF                                                                        NE



                                                       1. Request for resource usage




                                       Credit Amount Control
                                                                                                                                   2. Units
                                                                                                                                 Determination


                                                                                                                                   3. Rating
                                                                                                                                    Control

                                                                               4. Debit Units Request(Monetary Units)




                                                       5. Account
                                                         Control
                                                                                       6. Debit Units Response(Monetary Units)




                                                    7. Content/Service Delivery




                                                                               8. Credit Amount Control (cont.)




                                                 9. Content/Service Delivery (cont.)




                                                        10. Session released



13

14    Figure 3: Immediate Event Charging with Decentralized Rating and Decentralized Unit Determination
15   1.   Request for resource usage: The UE-A requests the desired content from the network element.
16   2.   Units Determination: depending on the service requested by the UE-A, the network element determines
17        the number of units accordingly.


                                                                   12
                                                                                                 X.P0013-0153


 1   3.  Rating Control: the network element calculates the number of monetary units that represent the price for
 2       the number of units determined in item 2.
 3   4. Debit Units Request: the network element requests the OCF to assure the deduction of an amount
 4       corresponding to the calculated number of monetary units from the subscriber's account.
 5   5. Account Control: provided that the user's credit balance is sufficient, the OCF triggers the deduction of
 6       the calculated amount from the subscriber's account.
 7   6. Debit Units Response: the OCF indicates to the network element the number of deducted monetary units.
 8   7. Content/Service Delivery: the network element delivers the content/service at once, in fractions or in
 9       individually chargeable items, corresponding to the number of units as specified in items 2 and 3.
10   8. Credit Amount Control (cont.): this function block is optional and a replication of items 2 to 6.
11   9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the
12       occurrence of item 8.
13   10. Session released: the session is released.

14   4.5.1.4 Further Options
15   In addition to the flows that are specified in the previous subclauses, the Debit Unit operation may alternatively
16   be carried out concurrently with service delivery, or after completion of service delivery.

17   4.5.2 Event charging with Reservation

18   4.5.2.1 Decentralized Unit Determination and Centralized Rating
19   In the following scenario, the network element requests the reservation of units prior to service delivery. An
20   account debit operation is carried out following the conclusion of service delivery.




                                                            13
     X.P0013-0153



            UE-A                                        OCF                                                                          NE




                                               1. Request for resource usage




                                                                                                                                 2. Units
                                                                                                                               Determination


                                                                          3. Reserve Units Request (Non-monetary Units)


                                                     4. Rating
                                                      Control

                                                    5. Account
                                                      Control

                                                  6.Reservation
                                                     Control
                                                                            7. Reserve Units Response (Non-monetary Units)




                                                                                                                              8. Reserved Units
                                                                                                                                 Supervision


                                                 9. Content/Service Delivery



                                                                               10. Debit Units Request (Non-monetary Units)



                                                    11. Rating
                                                     Control


                                                   12. Account
                                                     Control

                                                                            13. Debit Units Response (Non-monetary Units)




                                                   14. Session released



1

2    Figure 4: Event Charging with Reservation / Decentralized Unit Determination and Centralized Rating
 3   1.   Request for resource usageThe UE-A requests the desired content/service from the NE.
 4   2.   Units Determination: depending on the requested service the network element determines the number of
 5        units accordingly.
 6   3.   Reserve Units Request: the network element requests the OCF to reserve the number of units determined
 7        in item 2.
 8   4.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that
 9        represents the price for the number of units determined in item 2.
10   5.   Account Control: the OCF checks whether the user's account balance is sufficient for the requested
11        reservation.




                                                               14
                                                                                                X.P0013-0153


 1   6.    Reservation Control: if the user's account balance is sufficient then the corresponding reservation is
 2         made.
 3   7.    Reserve Units Response: the OCF informs the network element of the reserved number of units. Items 3
 4         to 7 may be repeated several times.
 5   8.    Reserved Units Supervision: simultaneously with the service delivery, the network element monitors the
 6         consumption of the reserved units.
 7   9.    Content/Service Delivery: the network element delivers the content/service at once, in fractions or in
 8         individually chargeable items, corresponding to the reserved number of units.
 9   10.   Debit Units Request: the network element requests the OCF to assure the deduction of an amount
10         corresponding to the consumed number of units from the subscriber's account. In the case that no further
11         units are required for this service, an appropriate indication triggering the release of the remaining
12         reservation is given.
13   11.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct
14         from the subscriber's account.
15   12.   Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
16   13.   Debit Units Response: the OCF informs the network element of the actually deducted units. Items 10 to
17         13 may be repeated several times.
18   14.   Session Release: the session is released.

19   4.5.2.2 Centralized Unit Determination and Centralized Rating
20   In the following scenario, the network element requests the OCF to reserve units based on the service identifier
21   specified by the network element. An account debit operation is carried out following the conclusion of service
22   delivery.




                                                           15
     X.P0013-0153



              UEa                                          OCF                                                                           NE




                                                  1. Request for resource usage




                                                                                  2. Reserve Units Request (Service Key)



                                                       3. Units
                                                     Determination


                                                   4. Rating Control



                                                       5. Account
                                                         Control


                                                     6. Reservation
                                                         Control
                                                                                  7. Reserve Units Response (Non-monetary Units)


                                                                                                                                   8. Granted Units
                                                                                                                                      Supervision

                                                    9. Content/Service Delivery




                                                                                  10. Debit Units Request (Non-monetary Units)



                                                       11. Rating
                                                        Control



                                                       12. Account
                                                         Control
                                                                              13. Debit Units Response (Non-monetary Units)



                                                      14. Session released



1

2         Figure 5: Event Charging with Reservation / Centralized Unit Determination and Centralized Rating
 3   1.     Request for resource usage: The UE-A requests the desired content from the network element.
 4   2.     Reserve Units Request: depending on the service requested by the UE-A, the network element selects the
 5          service identifier and forwards the Reserve Units Request to the OCF.
 6   3.     Units Determination: the OCF determines the number of non-monetary units needed for the
 7          content/service delivery, based on the received service key.
 8   4.     Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that
 9          represent the price for the number of units determined in item 3.
10   5.     Account Control: the OCF checks whether the user's account balance is sufficient for the requested
11          reservation.
12   6.     Reservation Control: if the user's account balance is sufficient, then the corresponding reservation is
13          made.



                                                                  16
                                                                                                  X.P0013-0153


 1   7.    Reserve Units Response: the OCF informs the network element of the reserved number of units. This
 2         includes the case where the number of units reserved indicates the permission to render the service that
 3         was identified by the received service key. Items 2 to 7 may be repeated several times.
 4   8.    Granted Units Supervision: simultaneously with the service delivery, the network element monitors the
 5         consumption of the reserved units.
 6   9.    Content/Service Delivery: the network element delivers the content/service at once, in fractions or in
 7         individually chargeable items, corresponding to the reserved number of units.
 8   10.   Debit Units Request: the network element provides according to previous Reserve Units Response either
 9         the request to deduct of an amount corresponding to the consumed number of units from the subscriber's
10         account, or solely the indication of whether the service was successfully delivered or not. In the case that
11         no further units are required for this service, an appropriate indication triggering the release of the
12         remaining reservation is given.
13   11.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct
14         from the subscriber's account.
15   12.   Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
16   13.   Debit Units Response: the OCF informs the network element of the actually deducted units. Items 10 to
17         13 may be repeated several times.
18   14.   Session Released: the session is released.




                                                             17
     X.P0013-0153


1    4.5.2.3 Decentralized Unit Determination and Decentralized Rating
2    In the following scenario, the network element request the OCF to assure the reservation of an amount of the
3    specified number of monetary units from the subscriber's account. An account debit operation that triggers the
4    deduction the amount from the subscriber's account is carried out following the conclusion of service delivery.

              UEa                                            OCF                                                                        NE




                                                    1. Request for resource usage




                                                                                                                                    2. Units
                                                                                                                                  Determination


                                                                                                                                 3. Rating Control



                                                                                    4. Reserve Units Request (Monetary Units)



                                                         5. Account
                                                           Control


                                                       6. Reservation
                                                           Control
                                                                                    7. Reserve Units Response (Monetary Units)


                                                                                                                                     8. Budget
                                                                                                                                      Control

                                                      9. Content/Service Delivery




                                                                                    10. Debit Units Request (Monetary Units)



                                                         11. Account
                                                           Control

                                                                                    12. Debit Units Response (Monetary Units)


                                                        13. Session released



5

6         Figure 6: Event Charging with Reservation / Centralized Unit Determination and Centralized Rating
 7   1.     Request for resource usage: The UE-A requests the desired content from the network element.
 8   2.     Units Determination: depending on the service requested by the UE-A, the network element determines
 9          the number of units accordingly.
10   3.     Rating Control: the network element calculates the number of monetary units that represent the price for
11          the number of units determined in item 2.
12   4.     Reserve Units Request: the network element requests the OCF to assure the reservation of an amount
13          corresponding to the calculated number of monetary units from the subscriber's account.
14   5.     Account Control: the OCF checks whether the user's account balance is sufficient for the requested
15          reservation.
16   6.     Reservation Control: if the user's credit balance is sufficient, then the corresponding reservation is made.




                                                                    18
                                                                                                X.P0013-0153


 1   7.    Reserve Units Response: the OCF informs the network element of the reserved number of monetary
 2         units. Items 4 to 7 may be repeated several times.
 3   8.    Budget Control: simultaneously with the service delivery, the network element monitors the consumption
 4         of the granted amount.
 5   9.    Content/Service Delivery: the network element delivers the content/service at once, in fractions or in
 6         individually chargeable items, corresponding to the number of units.
 7   10.   Debit Units Request: the network element requests the OCF to assure the deduction of an amount
 8         corresponding to the consumed number of monetary units from the subscriber's account.
 9   11.   Account Control: the OCF triggers the deduction of the consumed amount from the subscriber's account.
10   12.   Debit Units Response: the OCF indicates to the network element the number of deducted monetary units.
11         Items 10 to 12 may be repeated several times.
12   13.   Session Released: the session is released.

13   4.5.2.4 Session charging with Reservation

14   4.5.2.5 Decentralized Unit Determination and Centralized Rating
15   In the following scenario, the network element requests the reservation of units prior to session supervision. An
16   account debit operation is carried out following the conclusion of session termination.




                                                           19
     X.P0013-0153



            UE-A                                         OCF                                                                          NE




                                                1. Request for resource usage




                                                                                                                                  2. Units
                                                                                                                                Determination


                                                                           3. Reserve Units Request (Non-monetary Units)


                                                      4. Rating
                                                       Control

                                                     5. Account
                                                       Control

                                                   6.Reservation
                                                      Control
                                                                             7. Reserve Units Response (Non-monetary Units)




                                                                                                                               8. Reserved Units
                                                                                                                                  Supervision


                                                       9. Session ongoing


                                                    10. Session released



                                                                                11. Debit Units Request (Non-monetary Units)


                                                      12. Rating
                                                       Control


                                                    13. Account
                                                      Control
                                                                             14. Debit Units Response (Non-monetary Units)




1

2    Figure 7: Session Charging with Reservation / Decentralized Unit Determination and Centralized Rating
 3   1.   Request for resource usageThe UE-A requests session establishment from the NE.
 4   2.   Units Determination: depending on the requested type of the session the network element determines the
 5        number of units accordingly.
 6   3.   Reserve Units Request: the network element requests the OCF to reserve the number of units determined
 7        in item 2
 8   4.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that
 9        represents the price for the number of units determined in item 2.
10   5.   Account Control: the OCF checks whether the user's account balance is sufficient for the requested
11        reservation.




                                                                20
                                                                                               X.P0013-0153


 1   6.    Reservation Control: if the user's account balance is sufficient then the corresponding reservation is
 2         made.
 3   7.    Reserve Units Response: the OCF informs the network element of the reserved number of units.
 4   8.    Reserved Units Supervision: simultaneously with the ongoing session, the network element monitors the
 5         consumption of the reserved units.
 6   9.    Session ongoing: the network element maintains the session, corresponding to the reserved number of
 7         units.
 8   10.   Session Release: the session is released
 9   11.   Debit Units Request: the network element requests the OCF to assure the deduction of an amount
10         corresponding to the consumed number of units from the subscriber's account. In the case that no further
11         units are required for this service, an appropriate indication triggering the release of the remaining
12         reservation is given.
13   12.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct
14         from the subscriber's account.
15   13.   Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
16   14.   Debit Units Response: the OCF informs the network element of the actually deducted units.

17   4.5.2.6 Centralized Unit Determination and Centralized Rating
18   In the following scenario, the network element requests the OCF to reserve units based on the session
19   identifiers specified by the network element. An account debit operation is carried out following the
20   conclusion of session.




                                                           21
     X.P0013-0153



            UEa                                           OCF                                                                           NE




                                                 1. Request for resource usage




                                                                                 2. Reserve Units Request (Service Key)



                                                      3. Units
                                                    Determination


                                                  4. Rating Control



                                                      5. Account
                                                        Control


                                                    6. Reservation
                                                        Control
                                                                                 7. Reserve Units Response (Non-monetary Units)


                                                                                                                                  8. Granted Units
                                                                                                                                     Supervision

                                                       9. Session ongoing


                                                     10. Session released




                                                                                 11. Debit Units Request (Non-monetary Units)



                                                      12. Rating
                                                       Control


                                                      13. Account
                                                        Control

                                                                             14. Debit Units Response (Non-monetary Units)




1

2     Figure 8: Session Charging with Reservation / Centralized Unit Determination and Centralized Rating
 3
 4   1.   Request for resource usage: The UE-A requests the session establishment from the network element.
 5   2.   Reserve Units Request: depending on the requested type of the session by the UE-A, the network
 6        element selects the service identifier and forwards the Reserve Units Request to the OCF.
 7   3.   Units Determination: the OCF determines the number of non-monetary units needed for the
 8        content/service delivery, based on the received service key.
 9   4.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that
10        represent the price for the number of units determined in item 3.
11   5.   Account Control: the OCF checks whether the user's account balance is sufficient for the requested
12        reservation.
13   6.   Reservation Control: if the user's account balance is sufficient, then the corresponding reservation is
14        made.


                                                                 22
                                                                                                   X.P0013-0153


 1   7.    Reserve Units Response: the OCF informs the network element of the reserved number of units. This
 2         includes the case where the number of units reserved indicates the permission to render the service that
 3         was identified by the received service key.
 4   8.    Granted Units Supervision: simultaneously with the ongoing session, the network element monitors the
 5         consumption of the reserved units.
 6   9.    Content/Service Delivery: the network element maintains the session corresponding to the reserved
 7         number of units.
 8   10.   Session ongoing: the network element provides according to previous Reserve Units Response either the
 9         request to deduct of an amount corresponding to the consumed number of units from the subscriber's
10         account, or solely the indication of whether the session was successfully established or not. In the case that
11         no further units are required for this service, an appropriate indication triggering the release of the
12         remaining reservation is given.
13   11.   Session Released: the session is released.
14   12.   Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct
15         from the subscriber's account.
16   13.   Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
17   14.   Debit Units Response: the OCF informs the network element of the actually deducted units.




                                                              23
     X.P0013-0153


1    4.5.2.7 Decentralized Unit Determination and Decentralized Rating
2    In the following scenario, the network element request the OCF to assure the reservation of an amount of the
3    specified number of monetary units from the subscriber's account. An account debit operation that triggers the
4    deduction the amount from the subscriber's account is carried out following the conclusion of session
5    establishment.

            UEa                                            OCF                                                                        NE




                                                  1. Request for resource usage




                                                                                                                                  2. Units
                                                                                                                                Determination


                                                                                                                               3. Rating Control



                                                                                  4. Reserve Units Request (Monetary Units)



                                                       5. Account
                                                         Control


                                                     6. Reservation
                                                         Control
                                                                                  7. Reserve Units Response (Monetary Units)


                                                                                                                                   8. Budget
                                                                                                                                    Control

                                                        9. Session ongoing


                                                      10. Session released




                                                                                  11. Debit Units Request (Monetary Units)




                                                       12. Account
                                                         Control
                                                                                  13. Debit Units Response (Monetary Units)



6

7     Figure 9: Session Charging with Reservation / Centralized Unit Determination and Centralized Rating
 8   1.   Request for resource usage: The UE-A requests the session establishment from the network element.
 9   2.   Units Determination: depending on the requested type of the session by the UE-A, the network element
10        determines the number of units accordingly.
11   3.   Rating Control: the network element calculates the number of monetary units that represent the price for
12        the number of units determined in item 2.
13   4.   Reserve Units Request: the network element requests the OCF to assure the reservation of an amount
14        corresponding to the calculated number of monetary units from the subscriber's account.
15   5.   Account Control: the OCF checks whether the user's account balance is sufficient for the requested
16        reservation.
17   6.   Reservation Control: if the user's credit balance is sufficient, then the corresponding reservation is made.



                                                                  24
                                                                                              X.P0013-0153


 1   7.    Reserve Units Response: the OCF informs the network element of the reserved number of monetary
 2         units.
 3   8.    Budget Control: simultaneously with the ongoing session, the network element monitors the consumption
 4         of the granted amount.
 5   9.    Session ongoing: the network element maintains the session corresponding to the number of units.
 6   10.   Session Released: the session is released.
 7   11.   Debit Units Request: the network element requests the OCF to assure the deduction of an amount
 8         corresponding to the consumed number of monetary units from the subscriber's account.
 9   12.   Account Control: the OCF triggers the deduction of the consumed amount from the subscriber's account.
10   13.   Debit Units Response: the OCF indicates to the network element the number of deducted monetary units.


11   5 Basic Principles for Diameter Online charging
12   5.1      Online Specific Credit Control Application Requirements
13   For online charging, the basic functionality as defined by the IETF Diameter Credit Control application is
14   used. The basic structure follows a mechanism where the online client (CTF) requests resource allocation and
15   reports credit control information to the Online Charging System (OCS).
16   The usage and values of Validity-Time AVP and the timer "Tcc" are under the sole control of the credit control
17   server (OCS) and determined by operator configuration of the OCS.
18   The online client implements the state machine described in Diameter Base Protocol [402] for "CLIENT,
19   EVENT BASED" and/or "CLIENT, SESSION BASED". I.e. when the client applies IEC it uses the "CLIENT,
20   EVENT BASED" state machine, and when the client applies ECUR it uses the "CLIENT, SESSION BASED"
21   state machine for the first, intermediate and final interrogations.
22   The OCS implements the state machine described in Diameter Base Protocol [402] for the "SERVER,
23   SESSION AND EVENT BASED" in order to support Immediate Event Charging and Event Charging with
24   Unit Reservation.

25   5.2      Diameter Description on the Ro Interface

26   5.2.1 Basic Principles
27   For online charging the Diameter Credit Control Application defined in [402] is used with additional AVPs
28   defined in the present document.
29   Three cases for control of user credit for online charging are distinguished:
30          Immediate Event Charging IEC; and

31          Event Charging with Unit Reservation (ECUR).

32          Session Charging with Unit Reservation (SCUR)

33   In the case of Immediate Event Charging (IEC),the credit control process for events is controlled by the
34   corresponding CC-Requested-Type EVENT_REQUEST that is sent with Credit-Control-Request (CCR) for a
35   given credit control event.
36   In the case of Event Charging with Unit Reservation (ECUR) the CC-Request-Type INITIAL /
37   TERMINATION_REQUEST are used for charging for a given credit control event, however, where a
38   reservation is made prior to service delivery and committed on execution of a successful delivery.
39   Session Charging with Unit Reservation is used for credit control of sessions and uses the CC-Request-Type
40   INITIAL / UPDATE and TERMINATION_REQUEST.




                                                            25
     X.P0013-0153


1    The network element may apply IEC, where CCR Event messages are generated, or ECUR, using CCR Initial,
2    Termination and Update. The decision whether to apply IEC or ECUR is based on the service and/or operator's
3    policy.
4       NOTE:      To the extent possible alignment with the IETF Diameter Credit Control Application, [402], is
5                  planned. However, this can only be accomplished when the current IETF draft receives an
6                  official RFC status.

7    5.2.2 Immediate Event Charging (IEC)
 8   The following figure shows the transactions that are required on the Ro interface in order to perform event
 9   based Direct Debiting operation. The Direct Debiting operation may alternatively be carried out prior to
10   service/content delivery. The Network element must ensure that the requested service execution is successful,
11   when this scenario is used.

                                                      CTF                    OCS




                         1. Service Request




                                                      Direct Debiting Operation



                                                         2. CCR (EVENT_REQUEST, RA, RSU)



                                                                       4. Perform Direct
                                        3. Timer Tx                        Debiting



                                                            5. CCA (EVENT_REQUEST, GSU, [CI])



                         6. Service Delivery



12

13                                     Figure 10: IEC Direct Debiting Operation
14      Step 1.           The network element receives a service request.
15                        The Direct Debiting Operation is performed as described in DCCA [402].
16      Step 2.           The network element performs direct debiting prior to service execution. Network
17                        element (acting as DCCA client) sends Credit-Control-Request (CCR) with CC-Request-
18                        Type AVP set to EVENT_REQUEST to indicate service specific information to the OCS
19                        (acting as DCCA server). The Requested-Action AVP (RA) is set to
20                        DIRECT_DEBITING. If known, the network element may include Requested-Service-
21                        Unit AVP (RSU) (monetary or non-monetary units) in the request message.
22      Step 3.           Having transmitted the Credit-Control-Request message the network element starts the
23                        communication supervision timer 'Tx' [402]. Upon receipt of the Credit-Control- Answer
24                        (CCA) message the network element shall stop timer Tx.
25      Step 4.           The OCS determines the relevant service charging parameters .


                                                                26
                                                                                                          X.P0013-0153


1       Step 5.             The OCS returns Credit-Control-Answer message with CC-Request-Type AVP set to
2                           EVENT_REQUEST to the network element in order to authorize the service execution
3                           (Granted-Service-Unit AVP (GSU) and possibly Cost-Information AVP (CI) indicating
4                           the cost of the service are included in the Credit-Control-Answer message). The Credit-
5                           Control-Answer message has to be checked by the network element accordingly and the
6                           requested service is controlled concurrently with service delivery.
7    Step 6. Service is being delivered.

8       NOTE:      It is possible to perform also REFUND_ACCOUNT, CHECK_BALANCE and
9                  PRICE_ENQUIRY using above described mechanism [402].

10   5.2.3 Event Charging with Unit Reservation (ECUR)
11   The following figure shows the transactions that are required on the Ro interface in order to perform the SBCC
12   or the session based reserve and debit units operation. Multiple replications of both of these operations are
13   possible.

                                              CTF                                          OCS/


                         1. Service Request


                                                Reserve Units Operation


                                                    2. CCR (INITIAL_REQUEST, RSU)

                                                                                    3. Perfor m
                                                                                    Charging Control

                                                4. CCA (INITIAL_REQUEST, GSU, [VT])




                        5. Service Delivery



                                                Reserve Units and Debit Units Operations


                                                6. CCR (UPDATE_REQUEST, RSU, USU)


                                                                            7. Perform Charging Control

                                                8. CCA (UPDATE_REQUEST, GSU, [FUI])




                        9. Service Delivery


                                                Debit Units Operation

                                                 10. CCR (TERMINATION_REQUEST, USU)


                                                                           11. Perform Charging Control


                                                12. CCA (TERMINATION_REQUEST, CI)

14

15                                   Figure 11: ECUR for session based credit control
16      Step 1.           The network element receives a service request. The service request may be initiated
17                        either by the user or the other network element.



                                                                27
     X.P0013-0153


 1      Step 2.          In order to perform Reserve Units operation for a number of units (monetary or non-
 2                       monetary units), the network element sends a Credit-Control-Request (CCR) with CC-
 3                       Request-Type AVP set to INITIAL_REQUEST to the OCS. If known, the network
 4                       element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary
 5                       units) in the request message.
 6      Step 3.          If the service cost information is not received by the OCS, the OCS determines the price
 7                       of the desired service according to the service specific information received by issuing a
 8                       rating request to the Rating Function. If the cost of the service is included in the request,
 9                       the OCS directly reserves the specified monetary amount. If the credit balance is
10                       sufficient, the OCS reserves the corresponding amount from the users account.
11      Step 4.          Once the reservation has been made, the OCS returns Credit-Control-Answer (CCA)
12                       message with CC-Request-Type set to INITIAL_REQUEST to the network element in
13                       order to authorize the service execution (Granted-Service-Unit and possibly Cost-
14                       Information indicating the cost of the service are included in the Credit-Control-Answer
15                       message). The OSC may return the Validity-Time (VT) AVP with value field set to a
16                       non-zero value.
17      Step 5.          Content/service delivery starts and the reserved units are concurrently controlled.
18      Step 6.          During content/service delivery, in order to perform Debit Units and subsequent Reserve
19                       Units operations, the network element sends a CCR with CC-Request-Type AVP set to
20                       UPDATE_REQUEST, to report the units used and request additional units, respectively.
21                       The CCR message with CC-Request-Type AVP set to UPDATE_REQUEST must be sent
22                       by the network element between the INITIAL_REQUEST and
23                       TERMINATION_REQUEST either on request of the credit control application within the
24                       validity time or if the validity time is elapsed. If known, the network element may
25                       include Requested-Service-Unit AVP (monetary or non monetary units) in the request
26                       message. The Used-Service-Unit (USU) AVP is complemented in the CCR message to
27                       deduct units from both the user's account and the reserved units, respectively.
28      Step 7.          The OCS deducts the amount used from the account. If the service cost information is not
29                       received by the OCS, the OCS determines the price of the desired service according to the
30                       service specific information received by issuing a rating request to the Rating Function. If
31                       the cost of the service is included in the request, the OCS directly reserves the specified
32                       monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding
33                       amount from the users account.
34      Step 8.          Once the deduction and reservation have been made, the OCS returns Credit-Control-
35                       Answer message with CC-Request-Type set to UPDATE_REQUEST to the network
36                       element, in order to allow the content/service delivery to continue (new Granted-Service-
37                       Unit (GSU) AVP and possibly Cost-Information (CI) AVP indicating the cumulative cost
38                       of the service are included in the Credit-Control-Answer message). The OCS may include
39                       in the CCA message the Final-Unit-Indication (FUI) AVP to indicate the final granted
40                       units.
41      Step 9.          Content/service delivery continues and the reserved units are concurrently controlled.
42      Step 10.         When content/service delivery is completed or the final granted units have been
43                       consumed, the network element sends CCR with CC-Request-Type AVP set to
44                       INTERIM_REQUEST to terminate the active credit control session and report the used
45                       units.
46      Step 11.         The OCS deducts the amount used from the account. Unused reserved units are released,
47                       if applicable.
48   Step 12. The OCS acknowledges the reception of the CCR message by sending CCA message with CC-
49          Request-Type AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating
50          the cumulative cost of the service is included in the Credit-Control-Answer message).

51      NOTE:      This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown
52                 in the figure 6.1.4.




                                                            28
                                                                                                           X.P0013-0153


1    5.2.4 Session Charging with Unit Reservation (SCUR)
2    The follwing figure shows the transactions that are required on the Ro interface in order to perform the SCUR.

                                                CTF                                       OCS/


                        1. Session Initiation


                                                  Reserve Units Operation


                                                      2. CCR (INITIAL_REQUEST, RSU)

                                                                                      3. Perfor m
                                                                                      Charging Control

                                                  4. CCA (INITIAL_REQUEST, GSU, [VT])




                       5. Session Terminagtion



                                                  Debit Units Operation
                                                  6. CCR (TERMINATION_REQUEST, USU)


                                                                             7. Perform Charging Control


                                                  8. CCA (TERMINATION_REQUEST, CI)




3

4                                    Figure 12: SCUR for session based credit control
 5      Step 1.           The network element receives a session initiation. The session initiation may be done
 6                        either by the user or the other network element.
 7      Step 2.           In order to perform Reserve Units operation for a number of units (monetary or non-
 8                        monetary units), the network element sends a Credit-Control-Request (CCR) with CC-
 9                        Request-Type AVP set to INITIAL_REQUEST to the OCS. If known, the network
10                        element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary
11                        units) in the request message.
12      Step 3.           If the service cost information is not received by the OCS, the OCS determines the price
13                        of the desired service according to the service specific information received by issuing a
14                        rating request to the Rating Function. If the cost of the service is included in the request,
15                        the OCS directly reserves the specified monetary amount. If the credit balance is
16                        sufficient, the OCS reserves the corresponding amount from the users account.




                                                                  29
     X.P0013-0153


 1      Step 4.           Once the reservation has been made, the OCS returns Credit-Control-Answer (CCA)
 2                        message with CC-Request-Type set to INITIAL_REQUEST to the network element in
 3                        order to authorize the service execution (Granted-Service-Unit and possibly Cost-
 4                        Information indicating the cost of the service are included in the Credit-Control-Answer
 5                        message). The OSC may return the Validity-Time (VT) AVP with value field set to a
 6                        non-zero value.
 7      Step 5.           Content/service delivery starts and the reserved units are concurrently controlled.
 8      Step 6.           The session is terminated at the network element.
 9      Step 7.           The network element sends CCR with CC-Request-Type AVP set to
10                        TERMINATION_REQUEST to terminate the active credit control session and report the
11                        used units.
12      Step 8.           The OCS deducts the amount used from the account. Unused reserved units are released,
13                        if applicable.
14   Step 9. The OCS acknowledges the reception of the CCR message by sending CCA message with CC-Request-
15           Type AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the
16           cumulative cost of the service is included in the Credit-Control-Answer message).

17      NOTE:      This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown
18                 in the figure 6.1.5.

19   5.2.5 Error Cases and Scenarios
20   This subclause describes various error cases and how these should be handled.
21   The failure handling behaviour is locally configurable in the network element. If the Direct-Debiting-Failure-
22   Handling or Credit-Control-Failure-Handling AVP is not used, the locally configured values are used instead.

23   5.2.5.1 Duplicate Detection
24   The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as
25   possible the duplicate detection, the all-against-all record checking should be avoided and just those records
26   marked as potential duplicates need to be checked against other received requests (in real-time ) by the receiver
27   entity.
28   The network element marks the request messages that are retransmitted after a link fail over as possible
29   duplicates with the T-flag as described in [401]. For optimized performance, uniqueness checking against other
30   received requests is only necessary for those records marked with the T-flag received within a reasonable time
31   window. This focused check is based on the inspection of the Session-Id and CC-Request-Number AVP pairs.
32   Note that for EBCC the duplicate detection is performed in the Correlation Function that is part of the OCS.
33   The OCS that receives the possible duplicate request should mark as possible duplicate the corresponding
34   request that is sent over the 'Rc' interface. However, this assumption above is for further study and needs to be
35   clarified.
36   For credit control duplicate detection, please refer to the Diameter Credit Control.

37   5.2.5.2 Reserve Units and Debit Units Operation Failure
38   In the case of an OCS connection failure, and/or receiving error responses from the OCS, please refer to
39   RFC 3588 [401] and the Diameter Credit Control for failure handling descriptions.

40   5.3    Support of Tariff Changes During an Active User Session

41   5.3.1 Support of Tariff Changes using the Tariff Switch Mechanism
42   After a tariff switch has been reached, all the active user sessions shall report their session usage by the end of
43   the validity period of the current request and receive new quota for resource usage for the new tariff period.
44   In order to avoid the need for mass simultaneous quota refresh, the traffic usage can be split into resource
45   usage before a tariff switch and resources used after a tariff switch.


                                                             30
                                                                                                  X.P0013-0153


1    The Tariff-Time-Change AVP is used to determine the tariff switch time as described by [402].
2    The Tariff-Change-Usage AVP is used within the Used-Service-Units AVP to distinguish reported usage
3    before and after the tariff time change.
4    The Tariff-Change-Usage AVP is used within the Multiple-Services-Credit-Control AVP to allow separate
5    quotas to be granted for use before and after the tariff switch. If this AVP is not present, the granted quota may
6    be consumed both before and after the tariff switch, but usage must still be reported separately.

7    5.3.2 Support of Tariff Changes using Validity Time AVP
8    Changes to the tariffs pertaining to the service during active user sessions may also be handled using the
9    Validity Time AVP as described by [402]..

10   5.4    Support of Re-authorization
11   Mid Diameter CC session re-authorizations of multiple active resource quotas within a DCC (sub-)session can
12   be achieved using a single Diameter Credit Control Request/Answer message sequence.
13   The OCS may also re-authorise multiple active resource quotas within a DCC (sub-)session by using a single
14   Diameter Re-Auth-Request/Answer message sequence.
15   New quota allocations received by the Network Element override any remaining held quota resources after
16   accounting for any resource usage while the re-authorization was in progress.


17   6 Message formats for Online Charging
18   6.1    Summary of Online Charging Message Formats

19   6.1.1 General
20   The Diameter credit control application [402] specifies an approach based on a series of "interrogations":
21       Initial interrogation.

22       Zero, one or more interim interrogations.

23       Final interrogation.

24   In addition to a series of interrogations, also a one time event (interrogation) can be used e.g. in the case when
25   service execution is always successful.
26   All of these interrogations use Credit-Control-Request and Credit-Control-Answer messages defined in the
27   Diameter Credit Control Application [402] specification. The Credit-Control-Request for the "interim
28   interrogation" and "final interrogation" reports the actual number of "units" that were used, from what was
29   previously reserved. This determines the actual amount debited from the subscriber's account.
30   The following table describes the use of these messages for online charging.
31




                                                             31
     X.P0013-0153


1

2                                   Table 1 : Online Charging Messages Reference
                     Command-Name                    Source            Destination     Abbreviation
              Credit-Control-Request             Network Element           OCS            CCR
              Credit-Control-Answer                    OCS           Network Element      CCA
              Re-Auth-Request                          OCS           Network Element      RAR
              Re-Auth-Answer                     Network Element           OCS            RAA
              Capabilities-Exchange-Request    Network Element/OCS Network Element/OCS    CER
              Capabilities Exchange Answer     Network Element/OCS Network Element/OCS    CEA
              Device-Watchdog-Request          Network Element/OCS Network Element/OCS    DWR
              Device-Watchdog-Answer           Network Element/OCS Network Element/OCS    DWA
3
4    CER/CEA and DWR/DWA are mandatory Diameter capabilities for capabilities exchange and transport failure
5    detection.

6    6.1.2 Structure for the Credit Control Message Formats
7    The following is the basic structure shared by all online charging messages. This is based directly on the
8    format of the messages defined in the Diameter Credit Control Application specification [402].
 9   Those Diameter Credit Control AVPs that are used for online charging are marked "Yes" in tables 6.2 to 6.1.
10   Those Diameter AVPs that are not used for online charging are marked "No" in tables 6.2 to 6.1. This implies
11   that their content can (Yes) or can not (No) be used by the OCS for charging purposes.
12   The following symbols are used in the tables:
13       <AVP> indicates a mandatory AVP with a fixed position in the message.

14       {AVP} indicates a mandatory AVP in the message.

15       [AVP] indicates an optional AVP in the message.

16       *AVP indicates that multiple occurrences of an AVP is possible.

17   Where the AVPs’ are marked as ‘Yes’, they are then mandatory, if marked ‘No’, they are not used, if marked
18   ‘Optional’, then their use is subject to their inclusion in the relevant domain specific charging TS, if marked
19   ‘Conditional’, then its use is subject to condition specified in this TS, if marked as ‘Out of Scope’ (OoS), then,
20   the decision on its use is defined from the specification it has been derived from and is not subject to
21   judgement within the present document.

22   6.1.3 Credit-Control-Request Message
23   The following table illustrates the basic structure of a Diameter Credit Control Credit-Control-Request
24   message as used for online charging.

25                Table 2 : Credit-Control-Request (CCR) Message Contents for Online Charging
                                       Diameter Credit Control Application AVPs
                                                  AVP                       Used in 3GPP2
                           <Diameter Header: 272, REQ, PXY>                      Yes
                           <Session-Id>                                          Yes
                           {Origin-Host}                                         Yes
                           {Origin-Realm}                                        Yes
                           {Destination-Realm }                                  Yes
                           {Auth-Application-Id}                                 Yes
                           [Destination-Host]                                    Yes
                           [Vendor-Specific-Application-Id]                      Yes
                                    [ Vendor-Id ]                                Yes



                                                            32
                                                            X.P0013-0153


             Diameter Credit Control Application AVPs
          { Auth-Application-Id }                     Yes
          { Acct-Application-Id }                     Yes
[User-Name]                                           Yes
[Acct-Multi-Session-Id]                               No
[Origin-State-Id]                                     Yes
[Event-Timestamp]                                     Yes
* [Proxy-Info]                                        No
          { Proxy-Host }                              No
          { Proxy-State }                             No
* [Route-Record]                                      No
[Termination-Cause]                                   No
*[AVP]                                                Yes
{CC-Request-Type}                                     Yes
{CC-Request-Number}                                   Yes
[CC-Subsession-Id]                                    Yes
*[Subscription-Id]                                    Yes
          {Subscription-Id-Type}                      Yes
          {Subscription-Id-Data}                      Yes
[Requested-Action]                                    Yes
[Requested-Service-Unit]                              Yes
          [CC-Time]                                   Yes
          [CC-Money]                                  Yes
                    {Unit-Value}                      Yes
                             {Value-Digits}           Yes
                             [Exponent]               Yes
                    [Currency-Code]                   Yes
          [CC-Total-Octets]                           Yes
          [CC-Input-Octets]                           Yes
          [CC-Output-Octets]                          Yes
          [CC-Service-Specific-Units]                 Yes
          *[AVP]                                      Yes
*[Used-Service-Unit]                                  Yes
          [Tariff-Change-Usage]                       Yes
          [CC-Time]                                   Yes
          [CC-Money]                                  Yes
                    {Unit-Value}                      Yes
                             {Value-Digits}           Yes
                             [Exponent]               Yes
                    [Currency-Code]                   Yes
          [CC-Total-Octets]                           Yes
          [CC-Input-Octets]                           Yes
          [CC-Output-Octets]                          Yes
          [CC-Service-Specific-Units]                 Yes
          *[AVP]                                      Yes
*[Service-Parameter-Info]                             Yes
          [Service-Parameter-Type]                    Yes
          [Service-Parameter-Value]                   Yes
[CC-Correlation-Id]                                   No
[Service-Identifier]                                  No
[Multiple-Services-Indicator]                         Yes
*[Multiple-Services-Credit Control]                   Yes
          [ Reporting-Reason ]                        Yes
          *[ Trigger-Type]                            Yes
          [Granted-Service-Unit]                      No
          [Requested-Service-Unit]                    Yes
                    [CC-Time]                         Yes
                    [CC-Money]                        Yes
                             {Unit-Value}             Yes



                              33
    X.P0013-0153


                                     Diameter Credit Control Application AVPs
                                                               {Value-Digits}    Yes
                                                               [Exponent]        Yes
                                                      [Currency-Code]            Yes
                                            [CC-Total-Octets]                    Yes
                                            [CC-Input-Octets]                    Yes
                                            [CC-Output-Octets]                   Yes
                                            [CC-Service-Specific-Units]          Yes
                                            *[AVP]                               Yes
                                  *[Used-Service-Unit]                           Yes
                                            [ Reporting-Reason ]                 Yes
                                            [Tariff-Change-Usage]                Yes
                                            [CC-Time]                            Yes
                                            [CC-Money]                           Yes
                                                      {Unit-Value}               Yes
                                                               {Value-Digits}    Yes
                                                               [Exponent]        Yes
                                                      [Currency-Code]            Yes
                                            [CC-Total-Octets]                    Yes
                                            [CC-Input-Octets]                    Yes
                                            [CC-Output-Octets]                   Yes
                                            [CC-Service-Specific-Units]          Yes
                                            *[AVP]                               Yes
                                  [Tariff-Change-Usage]                          No
                                  *[Service-Identifier]                          Yes
                                  [Rating-Group]                                 Yes
                                  *[G-S-U-Pool-Reference]                        No
                                  [Validity-Time]                                No
                                  [Result-Code]                                  No
                                  [Final-Unit-Indication]                        No
                                  *[AVP]                                         Yes
                         [User-Equipment-Info]                                   Yes
                                  {User-Equipment-Info-Type}                     Yes
                                  {User-Equipment-Info-Value}                    Yes
                                              3GPP2 Credit control AVPs
                         [ServiceInformation]                                    Yes
                                  [PS-Information]                               Yes
                                  [WLAN-Information]                             Yes
                                  [IMS-Information]                              Yes
                                  [MMS-Information]                              Yes
                                  [LCS-Information]                              Yes
1

2   6.1.4 Credit-Control-Answer Message
3   The following table illustrates the basic structure of a Diameter Credit Control Credit-Control-Answer message
4   as used for online charging. This message is always used by the OCS as specified below, independent of the
5   receiving network element and the CCR record type that is being replied to.

6                Table 3 : Credit Control Answer (CCA) Message Contents for Online Charging




                                                         34
                                                                  X.P0013-0153


                       Diameter base protocol AVPs
                            AVP                       Used in 3GPP2
<Diameter Header: 272, PXY>                                Yes
<Session-Id>                                               Yes
{Result-Code}                                              Yes
{Origin-Host}                                              Yes
{Origin-Realm}                                             Yes
{Auth-Application-Id}                                      Yes
[Vendor-Specific-Application-Id]                           Yes
          [ Vendor-Id ]                                    Yes
          { Auth-Application-Id }                          Yes
          { Acct-Application-Id }                          Yes
[User-Name]                                                Yes
[Acct-Multi-Session-Id]                                     No
*[Redirect-Host]                                            No
[Redirect-Host-Usage]                                       No
[Redirect-Max-Cache-Time]                                   No
[Origin-State-Id]                                          Yes
[Event-Timestamp]                                          Yes
*[Proxy-Info]                                               No
          { Proxy-Host }                                    No
          { Proxy-State }                                   No
*[Route-Record]                                             No
*[AVP]                                                     Yes
                       Diameter Credit Control AVPs
{CC-Request-Type}                                         Yes
{CC-Request-Number}                                       Yes
[CC-Subsession-Id]                                        Yes
[CC-Session Failover]                                     No
*[Subscription-Id]                                        Yes
[Granted-Service-Unit]                                    Yes
          [Tariff-Time-Change]                            Yes
          [CC-Time]                                       Yes
          [CC-Money]                                      Yes
                     {Unit-Value}                         Yes
                              {Value-Digits}              Yes
                              [Exponent]                  Yes
                     [Currency-Code]                      Yes
          [CC-Total-Octets]                               Yes
          [CC-Input-Octets]                               Yes
          [CC-Output-Octets]                              Yes
          [CC-Service-Specific-Units]                     Yes
    [ Time-Quota-Threshold ]                              Yes
    [ Volume-Quota-Threshold ]                            Yes
          *[AVP]                                          Yes
[Cost-Information]                                        Yes
          {Unit-Value}                                    Yes
                     {Value-Digits}                       Yes
                     [Exponent]                           Yes
          {Currency-Code}                                 Yes
          [Cost-Unit]                                     Yes
[Final-Unit-Indication]                                   Yes
          {Final-Unit-Action}                             Yes
          *[Restriction-Filter-Rule]                      Yes
          *[Filter-Id]                                    Yes
          [Redirect-Server]                               Yes
[Check-Balance-Result]                                    Yes
[Credit-Control-Failure-Handling]                         Yes
[Validity-Time]                                           Yes



                                  35
    X.P0013-0153


                       *[Trigger-Type]                                              Yes
                       [Direct-Debiting-Failure-Handling]                           Yes
                       *[Multiple-Services-Credit-Control]                          Yes
                                 [ Quota-Holding-Time ]                             Yes
                                 [Granted-Service-Unit]                             Yes
                                           [Tariff-Time-Change]                     Yes
                                           [CC-Time]                                Yes
                                           [CC-Money]                               Yes
                                                      {Unit-Value}                  Yes
                                                               {Value-Digits}       Yes
                                                               [Exponent]           Yes
                                                      [Currency-Code]               Yes
                                           [CC-Total-Octets]                        Yes
                                           [CC-Input-Octets]                        Yes
                                           [CC-Output-Octets]                       Yes
                                           [CC-Service-Specific-Units]              Yes
                                 [ Time-Quota-Threshold ]                           Yes
                                 [ Volume-Quota-Threshold ]                         Yes
                                           *[AVP]                                   Yes
                                 [Requested-Service-Unit]                           No
                                 *[Used-Service-Unit]                               No
                                 [Tariff-Change-Usage]                              Yes
                                 *[Service-Identifier]                              Yes
                                 [Rating-Group]                                     Yes
                                 *[G-S-U-Pool-Reference]                            Yes
                                           {G-S-U-Pool-Identifier}                  Yes
                                           {CC-Unit-Type}                           Yes
                                           {Unit-Value}                             Yes
                                 [Validity-Time]                                    Yes
                                 [Result-Code]                                      Yes
                                 [Final-Unit-Indication]                            Yes
                                           {Final-Unit-Action}                      Yes
                                           *[Restriction-Filter-Rule]               Yes
                                           *[Filter-Id]                             Yes
                                           [Redirect-Server]                        Yes
                                                      {Redirect-Address-Type}       Yes
                                                      {Redirect-Server-Address}     Yes
                                 *[AVP]                                             Yes
                                         3GPP2 Diameter Credit Control AVPs
                                [PS-Furnish-Charging-Information]                   Yes
                                          {GPRS-Charging-Id}                        Yes
                                          {PS-Free-Format-Data}                     Yes
                                         [PS-Append-Free-Format-Data]               Yes
1

2   6.1.5 Re-Auth-Request Message
3   The following table illustrates the basic structure of a Diameter Credit Control Re-Auth-Request message as
4   used for online charging.

5                   Table 4 : Re-Auth-Request (RAR) Message Contents for Online Charging
                                    Diameter Credit Control Application AVPs
                                              AVP                  Used in 3GPP2
                               <Diameter Header: 258, REQ, PXY>         Yes
                               <Session-Id>                             Yes
                               {Origin-Host}                            Yes
                               {Origin-Realm}                           Yes
                               {Destination-Realm}                      Yes
                               {Destination-Host}                       Yes


                                                          36
                                                                                              X.P0013-0153


                                     Diameter Credit Control Application    AVPs
                                {Auth-Application-Id}                       Yes
                                {Re-Auth-Request-Type}                      Yes
                                [User-Name]                                 Yes
                                [Origin-State-Id]                           Yes
                                [Event-Timestamp]                           Yes
                                * [Proxy-Info]                               No
                                          { Proxy-Host }                     No
                                          { Proxy-State }                    No
                                * [Route-Record]                             No
                                *[AVP]                                      Yes
                                [CC-Sub-Session-Id]                         Yes
                                [G-S-U-Pool-Identifier]                     Yes
                                [Service-Identifier]                        Yes
                                [Rating-Group]                              Yes
1

2    6.1.6 Re-Auth-Answer Message
3    The following table illustrates the basic structure of a Diameter Credit Control Re-Auth-Answer message as
4    used for online charging.

5                    Table 5 : Re-Auth-Answer (RAA) Message Contents for Online Charging
                                     Diameter Credit Control Application AVPs
                                                 AVP            Used in 3GPP2
                                   <Diameter Header: 258, PXY>         Yes
                                   <Session-Id>                        Yes
                                   {Result-Code}                       Yes
                                   {Origin-Host}                       Yes
                                   {Origin-Realm}                      Yes
                                   [User-Name]                         Yes
                                   [Origin-State-Id]                   Yes
                                   [Error-Message]                     Yes
                                   [Error-Reporting-Host]              Yes
                                   *[Failed-AVP]                       Yes
                                   *[Redirect-Host]                    Yes
                                   [Redirect-Host-Usage]               Yes
                                   [Redirect-Host-Cache-Time]          Yes
                                   * [Proxy-Info]                      No
                                             { Proxy-Host }            No
                                             { Proxy-State }           No
                                   *[AVP]                              Yes
6

7    6.1.7 Capabilities-Exchange-Request Message
8    The Capabilities-Exchange-Request message structure is described in [401].

9    6.1.8 Capabilities-Exchange-Answer Message
10   The Capabilities-Exchange-Answer message structure is described in [401].

11   6.1.9 Device-Watchdog-Request Message
12   The Device-Watchdog-Request message structure is described in [401].

13   6.1.10 Device-Watchdog-Answer Message
14   The Device-Watchdog-Answer message structure is described in [401].


                                                          37
     X.P0013-0153



1    7 Data description for IMS online charging
2    7.1    Diameter message contents

3    7.1.1 Summary of Online Charging Message Formats
4    The following table describes the use of these messages for online charging.

5                                Table 6 : Online Charging Messages Reference Table
                Command-Name                          Source               Destination             Abbreviation
     Credit-Control-Request                          MRFC, AS,                OCS                     CCR
                                                     IMS-GWF
     Credit-Control-Answer                             OCS                  MRFC, AS,                   CCA
                                                                            IMS-GWF
6

7    7.1.2 Structure for the Credit Control Message Formats
 8   IMS online charging uses the diameter credit control application with the two messages Credit-Control-
 9   Request (CCR) and Credit-Control-Answer (CCA). The request performs rating of the IMS service and
10   reserves units on the users account. The answer replies back with amount of reserved units or an error code if
11   the user is out of credit. This sub clause describes the different AVPs used in the credit control messages.
12   The CCR types in the table are listed in the following order: I (initial)/ U (update)/ T (terminate)/E (event).
13   Therefore, when all CCR types are possible it is marked as IUTE. If only some CCR types are allowed for a
14   node, only the appropriate letters are used (i.e. IUT or E) as indicated in the table heading. The omission of a
15   CCR type for a particular AVP is marked with "-" (i.e. IU-E). Also, when an entire AVP is not allowed in a
16   node the entire cell is marked as "-".
17   Note that not for all Grouped AVPs the individual AVP members are listed in the table.

18   7.1.2.1 MRFC Credit-Control-Request Message
19   The following table illustrates the basic structure of a Diameter credit control request message from MRFC as
20   used for IMS online charging.

21                     Table 7 : Credit-Control-Request (CCR) Message Contents for MRFC




                                                            38
                                                                   X.P0013-0153


                  AVP                Category Description   Type
    Session-Id                          M     Section 9.0   IUTE
    Origin-Host                         M     Section 9.0   IUTE
    Origin-Realm                        M     Section 9.0   IUTE
    Destination-Realm                   M     Section 9.0   IUTE
    Auth-Application-Id                 M     Section 9.0   IUTE
    Destination-Host                    OC    Section 9.0   IUTE
    User-Name                           OC    Section 9.0   IUTE
    Origin-State-Id                     OC    Section 9.0   IUTE
    Event-Timestamp                     OC    Section 9.0   IUTE
    CC-Request-Type                     M     Section 9.0   IUTE
    CC-Request-Number                   M     Section 9.0   IUTE
    CC-Subsession-Id                     ?    Section 9.0   -
    Subscription-Id                     OC    Section 9.0   IUTE
    Requested-Action                    OC    Section 9.0   ---E
    Requested-Service-Unit              OC    Section 9.0   IU-E
    Used-Service-Unit                   OC    Section 9.0   -UT-
    Service-Parameter-Info              OC    Section 9.0   IUTE
    CC-Correlation-Id                   OC    Section 9.0   IUTE
    Service-Identifier                   ?    Section 9.0   ????
    Service-Context                      ?    Section 9.0   ????
    Multiple-Services-Indicator          ?    Section 9.0   -
    Multiple-Services-Credit Control     ?    Section 9.0   -
    Route-Record                        C     Section 9.0   IUTE
    AVP                                 OC    Section 9.0   IUTE
    IMS-Information                     OC    Section 9.0   IUTE
1




                                39
    X.P0013-0153


1   7.1.2.2 AS Credit-Control-Request Message
2   The following table illustrates the basic structure of a Diameter credit control request message from
3   Application Server as used for IMS online charging.

4                    Table 8 : Credit-Control-Request (CCR) Message Contents for AS                         Comment [AD1]:

                                         AVP                Category Description       Type
                           Session-Id                          M     Section 9.0       IUTE
                           Origin-Host                         M     Section 9.0       IUTE
                           Origin-Realm                        M     Section 9.0       IUTE
                           Destination-Realm                   M     Section 9.0       IUTE
                           Auth-Application-Id                 M     Section 9.0       IUTE
                           Destination-Host                    OC    Section 9.0       IUTE
                           User-Name                           OC    Section 9.0       IUTE
                           Origin-State-Id                     OC    Section 9.0       IUTE
                           Event-Timestamp                     OC    Section 9.0       IUTE
                           CC-Request-Type                     M     Section 9.0       IUTE
                           CC-Request-Number                   M     Section 9.0       IUTE
                           CC-Subsession-Id                     ?    Section 9.0       -
                           Subscription-Id                     OC    Section 9.0       IUTE
                           Requested-Action                    OC    Section 9.0       ---E
                           Requested-Service-Unit              OC    Section 9.0       IU-E
                           Used-Service-Unit                   OC    Section 9.0       -UT-
                           Service-Parameter-Info              OC    Section 9.0       IUTE
                           CC-Correlation-Id                   OC    Section 9.0       IUTE
                           Service-Identifier                   ?    Section 9.0       ????
                           Multiple-Services-Indicator          ?    Section 9.0       -
                           Multiple-Services-Credit Control     ?    Section 9.0       -
                           Route-Record                        C     Section 9.0       IUTE
                           AVP                                 OC    Section 9.0       IUTE
                           IMS-Information                     OC    Section 9.0       IUTE

5
6




                                                          40
                                                                                              X.P0013-0153



1   7.1.2.3 IMS Gateway Credit-Control Message
2   The following table illustrates the basic structure of a Diameter credit control request message from IMS
3   Gateway as used for IMS online charging.

4                Table 9 : Credit-Control-Request (CCR) Message Contents for IMS-GWF

                                         AVP                Category Description      Type
                           Session-Id                          M     Section 9.0      IUTE
                           Origin-Host                         M     Section 9.0      IUTE
                           Origin-Realm                        M     Section 9.0      IUTE
                           Destination-Realm                   M     Section 9.0      IUTE
                           Auth-Application-Id                 M     Section 9.0      IUTE
                           Destination-Host                    OC    Section 9.0      IUTE
                           User-Name                           OC    Section 9.0      IUTE
                           Origin-State-Id                     OC    Section 9.0      IUTE
                           Event-Timestamp                     OC    Section 9.0      IUTE
                           CC-Request-Type                     M     Section 9.0      IUTE
                           CC-Request-Number                   M     Section 9.0      IUTE
                           CC-Subsession-Id                     ?    Section 9.0      -
                           Subscription-Id                     OC    Section 9.0      IUTE
                           Requested-Action                    OC    Section 9.0      ---E
                           Requested-Service-Unit              OC    Section 9.0      IU-E
                           Used-Service-Unit                   OC    Section 9.0      -UT-
                           Service-Parameter-Info              OC    Section 9.0      IUTE
                           CC-Correlation-Id                   OC    Section 9.0      IUTE
                           Service-Identifier                   ?    Section 9.0      ????
                           Multiple-Services-Indicator          ?    Section 9.0      -
                           Multiple-Services-Credit Control     ?    Section 9.0      -
                           Route-Record                        C     Section 9.0      IUTE
                           AVP                                 OC    Section 9.0      IUTE
                           IMS-Information                     OC    Section 9.0      IUTE
5




                                                          41
    X.P0013-0153


1   7.1.2.4 Credit-Control-Answer Message
2   The following table illustrates the basic structure of a Diameter credit control answer message as used for IMS
3   charging. This message is always used by the OCS as specified below, independent of the receiving IMS node
4   and the CCR request type that is being replied to.

5          Table 10 :Credit-Control-Answer (CCA) Message Contents for MRFC, AS and IMS-GWF
                                         AVP                Category Description      Type
                           Session-Id                          M     Section 9.0      IUTE
                           Origin-Host                         M     Section 9.0      IUTE
                           Origin-Realm                        M     Section 9.0      IUTE
                           Destination-Realm                   M     Section 9.0      IUTE
                           Auth-Application-Id                 M     Section 9.0      IUTE
                           Destination-Host                    OC    Section 9.0      IUTE
                           User-Name                           OC    Section 9.0      IUTE
                           Origin-State-Id                     OC    Section 9.0      IUTE
                           Termination-Cause                   OC    Section 9.0      IUTE
                           Event-Timestamp                     OC    Section 9.0      IUTE
                           CC-Request-Type                     M     Section 9.0      IUTE
                           CC-Request-Number                   M     Section 9.0      -
                           CC-Subsession-Id                    OC    Section 9.0      IUTE
                           Subscription-Id                     OC    Section 9.0      ---E
                           Requested-Action                    OC    Section 9.0      IU-E
                           Requested-Service-Unit              OC    Section 9.0      -UT-
                           Used-Service-Unit                   OC    Section 9.0      IUTE
                           Service-Parameter-Info              OC    Section 9.0      IUTE
                           CC-Correlation-Id                   OC    Section 9.0      IUTE
                           Service-Identifier                   ?    Section 9.0      -
                           Multiple-Services-Indicator          ?    Section 9.0      -
                           Multiple-Services-Credit Control     ?    Section 9.0      -
                           Route-Record                        C     Section 9.0      IUTE
                           AVP                                 OC    Section 9.0      IUTE
                           IMS-Information                     OC    Section 9.0      IUTE
6
7




                                                          42
                                                                                        X.P0013-0153


1

2   7.2   AVPs for IMS Online Charging on the Ro interface
3   The IMS Information AVP used for IMS online charging is provided in the Service-Information AVP.




                                                      43
    X.P0013-0153


1   7.2.1 Definition of the IMS-Information AVP
2   The detailed structure of the IMS-Information AVP can be found in the following table.
3   The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit
4   denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header.

5                                     Table 11 : Structure of the IMS-Information AVP
                                                                                                  AVP Flag rules
                      AVP Name                           AVP     Defined        Value       Must May Should      Must
                                                         Code                   Type                   not       not
    [Event-Type]                                       823      Section 9.0   Grouped
               [SIP-Method]                            824      Section 9.0   UTF8String
               [Event]                                 825      Section 9.0   UTF8String
               [Content-Type]                          826      Section 9.0   UTF8String
               [Content-Length]                        827      Section 9.0   UTF8String
               [Content-Disposition]                   828      Section 9.0   UTF8String
    [Role-of-Node]                                     829      Section 9.0   Enumerated
    [User Session Id]                                  830      Section 9.0   UTF8String
    [Calling-Party-Address]                            831      Section 9.0   UTF8String
    [Called-Party-Address]                             832      Section 9.0   UTF8String
    [Time-stamps]                                      833      Section 9.0   Grouped
               [SIP-Request-Timestamp]                 834      Section 9.0   UTF8String
               [SIP-Response-Timestamp]                835      Section 9.0   UTF8String
    [Application-server-Information]                   863      Section 9.0   Grouped
                [Application-server]                   836      Section 9.0   UTF8String
                *[Application-provided-called-party-            Section 9.0
                                                       837                    UTF8String
    address]
    *[Inter-Operator-Identifier]                       838      Section 9.0   Grouped
               [Originating-IOI]                       839      Section 9.0   UTF8String
               [Terminating-IOI]                       840      Section 9.0   UTF8String
    [IMS-Charging-Identifier]                          841      Section 9.0   UTF8String
    *[SDP-Session-Description]                         842      Section 9.0   UTF8String
    *[SDP-Media-component]                             843      Section 9.0   Grouped
               [SDP-Media-Name]                        844      Section 9.0   UTF8String
               *[SDP-Media-Description]                845      Section 9.0   UTF8String
               [GPRS-Charging-Id]                      846      Section 9.0   UTF8String
    [GGSN-Address]                                     847      Section 9.0   IPAddress
    [Served-Party-IP-Address]                          848      Section 9.0   IPAddress
    [Authorized-QoS]                                   849      Section 9.0   UTF8String
    [Server-Capabilities]                              [19]     Section 9.0
    [Trunk-Group-Id]                                   851      Section 9.0   Grouped
               [Incoming-Trunk-Group-Id]               852      Section 9.0   UTF8String
               [Outgoing-Trunk-Group-Id]               853      Section 9.0   UTF8String
    [Bearer-Service]                                   854      Section 9.0   OctetString
    [Service-Id]                                       855      Section 9.0   UTF8String
    [UUS-Data]                                         856      Section 9.0   Grouped
               [Amount-of-UUS-data]                    857      Section 9.0   UTF8String
               [Mime-type]                             858      Section 9.0   UTF8String
               [Direction]                             859      Section 9.0   Enumerated
    [Cause]                                            860      Section 9.0   Grouped
               {Cause-Code}                            861      Section 9.0   Enumerated
         {Node-Functionality}                          862      Section 9.0   Enumerated
6




                                                                44
                                                                                                X.P0013-0153



1   8 AVPs Used for Online Charging
2   8.1    AVPs for Online Charging Credit Control
3   For the purpose of online charging additional AVPs are used in CCR and CCA. The information is
4   summarized in the following table along with the AVP flag rules.
5   Detailed descriptions of AVPs that are used specifically for 3GPP2 charging are provided in the subclauses
6   below the table. 3GPP2 uses values assigned by 3GPP. However, for AVPs that are just borrowed from other
7   applications only the reference (e.g.TBD) is provided in the following table and the detailed description is not
8   repeated.




                                                           45
    X.P0013-0153


1                                                  Table 7.1:

2                                Table 12 : Use Of Diameter Credit Control
                                                                                AVP Flag rules
                                               AVP Clause        Value
                        AVP Name                                          Must May Should Must May
                                               Code Defined      Type
                                                                                    not    not Encr.
            CC-Correlation-Id                     [TBD] [TBD] OctetString
            CC-Input-Octets                       [TBD] [TBD] Unsigned64
            CC-Money                              [TBD] [TBD] Grouped
            CC-Output-Octets                      [TBD] [TBD] Unsigned64
            CC-Request-Number                     [TBD] [TBD] Unsigned32
            CC-Request-Type                       [TBD] [TBD] Enumerated
            CC-Service-Specific-Units             [TBD] [TBD] Unsigned64
            CC-Session –Failover                  [TBD] [TBD] Enumerated
            CC-Sub-Session-Id                     [TBD] [TBD] Unsigned64
            CC-Time                               [TBD] [TBD] Unsigned32
            CC-Total-Octets                       [TBD] [TBD] Unsigned64
            CC-Unit-Type                          [TBD] [TBD] Enumerated
            Check-Balance-Result                  [TBD] [TBD] Enumerated
            Cost-Information                      [TBD] [TBD] Grouped
            Cost-Unit                             [TBD] [TBD] UTF8String
            Credit-Control                        [TBD] [TBD] Enumerated
            Credit-Control-Failure-Handling       [TBD] [TBD] Enumerated
            Currency-Code                         [TBD] [TBD] Unsigned32
            Direct-Debiting-Failure-Handling      [TBD] [TBD] Enumerated
            Exponent                              [TBD] [TBD] Integer32
            Final-Unit-Action                     [TBD] [TBD] Enumerated
            Final-Unit-Indication                 [TBD] [TBD] Grouped
            Granted-Service-Unit                  [TBD] [TBD] Grouped
            Granted-Service-Unit -Pool-Identifier [TBD] [TBD] Unsigned32
            Granted-Service-Unit -Pool-Reference [TBD] [TBD] Grouped
            Multiple-Services-Credit-Control      [TBD] [TBD] Grouped
            Multiple-Services-Indicator           [TBD] [TBD] Enumerated
            Rating-Group                          [TBD] [TBD] Unsigned32
            Redirect-Address-Type                 [TBD] [TBD] Enumerated
            Redirect-Server                       [TBD] [TBD] Grouped
            Redirect-Server-Address               [TBD] [TBD] UTF8String
            Requested-Action                      [TBD] [TBD] Enumerated
            Requested-Service-Unit                [TBD] [TBD] Grouped
            Restriction -Filter-Rule              [TBD] [TBD] IPFiltrRule
            Service-Identifier                    [TBD] [TBD] UTF8String
            Service-Parameter-Info                [TBD] [TBD] Grouped
            Service-Parameter-Type                [TBD] [TBD] Unsigned32
            Service- Parameter-Value              [TBD] [TBD] OctetString
            Subscription-Id                       [TBD] [TBD] Grouped
            Subscription-Id-Data                  [TBD] [TBD] UTF8String
            Subscription-Id-Type                  [TBD] [TBD] Enumerated
            Tariff-Change-Usage                   [TBD] [TBD] Enumerated
            Tariff-Time-Change                    [TBD] [TBD] Time
            Unit-Value                            [TBD] [TBD] Grouped
            Used-Service-Unit                     [TBD] [TBD] Grouped
             User-Equipment-Info                  [TBD] [TBD] Grouped
             User-Equipment-Info-Type             [TBD] [TBD] Unsigned32
             User-Equipment-Info-Value            [TBD] [TBD] UTF8String
             Value-Digits                         [TBD] [TBD] Integer64
             Validity-Time                        [TBD] [TBD] Unsigned32
                                          3GPP2 Diameter Credit Control AVPs
            Service-Information                   TBD 7.1.2.1 Grouped
            PS-Furnish-Charging-Information       865 7.1.2.2 Grouped
            Charging-Id                           846 7.1.2.18 UTF8String
            PS-Free-Format-Data                   866 7.1.2.3 OctetString
            PS-Append-Free-Format-Data            867 7.1.2.4 Enumerated
            Time-Quota-Threshold                  868 7.1.2.5 Unsigned64
            Volume-Quota-Threshold                869 7.1.2.6 Unsigned64
            Trigger-Type                          870 7.1.2.7



                                                       46
                                                                                                   X.P0013-0153


                                                                                      AVP Flag rules
                                                     AVP Clause       Value
                             AVP Name                                           Must May Should Must May
                                                     Code Defined     Type
                                                                                          not    not Encr.
                 Quota-Holding-Time                  871   7.1.2.8
                 Reporting-Reason                    872   7.1.2.9
1

2    8.1.1 Diameter Credit Control AVPs
3    TBD.

4    8.1.2 3GPP2 Specific Credit Control AVPs

5    8.1.2.1 Service-Information AVP
6    The ServiceInformation AVP is of type Grouped. Its purpose is to allow the transmission of additional service
7    specific information elements which are not covered in this document.
8    The ServiceInformation AVP has the following format:
 9              Service-Information :: = < AVP Header: TBD>
10                                       [PS-Information]
11                                       [WLAN-Information]
12                                       [IMS-Information]
13                                       [MMS-Information]
14                                       [LCS-Information]
15   The format and the contents of the fields inside the ServiceInformation AVP are specified in the applicable
16   documents for the specific service. Note that the formats of the fields are service-specific, i.e. the format will
17   be different for the various services.
18   Further fields may be included in the ServiceInformation AVP when new services are introduced.

19   8.1.2.2 PS-Furnish-Charging-Information AVP
20   The PS-Furnish-Charging-Information AVP (AVP code 865) is of type Grouped. Its purpose is to add online
21   charging session specific information, received via the Ro interface, onto the Rf interface in order to facilitate
22   its inclusion in ACRs. The PS- Furnish-Charging-Information AVP has the following format:
23              PS-Furnish-Charging-Information :: = < AVP Header: TBD>
24                                      {Charging-Id}
25                                      {PS-Free-Format-Data}
26                                      [PS-Append-Free-Format-Data]

27   8.1.2.3 PS-Free-Format-Data AVP
28   The PS-Free-Format-Data AVP (AVP code 866) is of type OctectString and holds online charging session
29   specific data.

30   8.1.2.4 PS-Append-Free-Format-Data AVP
31   The PS-Append-Free-Format-Data AVP (AVP code 867) is of type enumerated and indicates if the
32   information sent in the PS-Free-Format-Data AVP must be appended to the PS-free-format-data stored for the
33   online-session.
34   The following values are defined:
35      0 ‘Append’: If this AVP is present and indicates ‘Append’, the GGSN shall append the received PS free
36        format data to the PS free format data stored for the online charging session.

37      1 ‘Overwrite’: If this AVP is absent or in value ‘Overwrite’, the GGSN shall overwrite all PS free format
38        data already stored for the online charging session.


                                                             47
     X.P0013-0153


1    The GGSN shall ignore this AVP if no PS free format data is stored for the online charging session.

2    8.1.2.5 Time-Quota-Threshold
3    The Time-Quota-Threshold AVP (AVP code 868) is of type Unsigned64 and contains a threshold value in
4    seconds. This AVP may be included within the Multiple-Services-Credit-Control AVP when this AVP also
5    contains a Granted-Service-Units AVP containing a CC-Time AVP (i.e. when the granted quota is a time
6    quota).
7    If received, the Credit Control client shall seek re-authorization from the server for the quota when the quota
8    contents fall below the supplied threshold. The client shall allow service to continue whilst the re-authorization
9    is progress, until the time at which the original quota would have been consumed.

10   8.1.2.6 Volume-Quota-Threshold
11   The Volume-Quota-Threshold AVP (AVP code 869) is of type Unsigned64 and contains a threshold value in
12   octets. This AVP may be included within the Multiple-Services-Credit-Control AVP when this AVP also
13   contains a Granted-Service-Units AVP containing a CC-Total-Octets, CC-Input-Octets or CC-Output-Octets
14   AVP (i.e. when the granted quota is a volume quota).
15   If received, the Credit Control client shall seek re-authorization from the server for the quota when the quota
16   contents fall below the supplied threshold. The client shall allow service to continue whilst the re-authorization
17   is progress, up to the volume indicated in the original quota.

18   8.1.2.7 Trigger-Type AVP
19   The Trigger-Type AVP (AVP code 870) is of type Enumerated and indicates a single re-authorization event
20   type. When included in the Credit Control Answer command, the Trigger-Type AVP indicates the events that
21   shall cause the credit control client to re-authorise the associated quota. The client shall not re-authorise the
22   quota when events which are not included in the Trigger AVP occur.
23   When included in the the Credit Control Request command indicates the specific event which caused the re-
24   authorization request of the Reporting-Reason with value RATING_CONDITION_CHANGE associated.
25   It has the following values:
26      CHANGE_IN_SGSN_IP_ADDRESS (1)

27              This value is used to indicate that a change in the SGSN IP address shall cause the credit control
28               client to ask for a re-authorization of the associated quota.

29      CHANGE_IN_QOS (2)

30              This value is used to indicate that a change in the end user negotiated QoS shall cause the credit
31               control client to ask for a re-authorization of the associated quota.

32      CHANGE_IN_LOCATION (3)

33              This value is used to indicate that a change in the end user location shall cause the credit control
34               client to ask for a re-authorization of the associated quota.

35      CHANGE_IN_RAT (4)

36              This value is used to indicate that a change in the radio access technology shall cause the credit
37               control client to ask for a re-authorization of the associated quota.

38   8.1.2.8 Quota-Holding-Time AVP
39   The Quota-Holding-Time AVP (AVP code 871) is of type Unsigned32 and contains the quota holding time in
40   seconds. The client shall start the quota holding timer when quota consumption ceases. This is always when



                                                            48
                                                                                                   X.P0013-0153


1    traffic ceases, i.e. the timer is re-started at the end of each packet. The Credit Control Client shall deem a quota
2    to have expired when no traffic associated with the quota is observed for the value indicated by this AVP.
3    This optional AVP may only occur in a CCA command. It is contained in the Multiple-Services-Credit-
4    Control AVP. It applies equally to the granted time quota and to the granted volume quota.
5    A Quota-Holding-Time value of zero indicates that this mechanism shall not be used. If the Quota-Holding-
6    Time AVP is not present, then a locally configurable default value in the client shall be used.

7    8.1.2.9 Reporting-Reason AVP
 8   The Reporting-Reason AVP (AVP code 872) is of type Enumerated and specifies the reason for usage
 9   reporting for one or more types of quota for a particular category. It can occur directly in the Multiple-
10   Services-Credit-Control AVP, or in the Used-Service-Units AVP within a Credit Control Request command
11   reporting credit usage. It shall not be used at command level. It shall always and shall only be sent when usage
12   is being reported.
13   The following values are defined for the Reporting-Reason AVP:
14      THRESHOLD                                  (0)

15               This value is used to indicate that the reason for usage reporting of the particular quota type
16                indicated in the Used-Service-Units AVP where it appears is that the threshold has been reached.

17      QHT                               (1)

18               This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-
19                Service-Credit-Control AVP where its appears is that the quota holding time specified in a
20                previous CCA command has been hit (i.e. the quota has been unused for that period of time).

21      FINAL                             (2)

22               This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-
23                Service-Credit-Control AVP where its appears is that a normal PDP context termination has
24                happened.

25      QUOTA_EXHAUSTED                                      (3)

26               This value is used to indicate that the reason for usage reporting of the particular quota type
27                indicated in the Used-Service-Units AVP where it appears is that the quota has been exhausted.

28      VALIDITY_TIME                                        (4)

29               This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-
30                Service-Credit-Control AVP where its appears is that the credit authorization lifetime provided in
31                the Validity-Time AVP has expired.

32      OTHER_QUOTA_TYPE                                     (5)

33               This value is used to indicate that the reason for usage reporting of the particular quota type
34                indicated in the Used-Service-Units AVP where it appears is that, for a multi-dimensional quota,
35                one reached a trigger condition and the other quota is being reported.

36      RATING_CONDITION_CHANGE                                       (6)

37               This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-
38                Service-Credit-Control AVP where its appears is that a change has happened in some of the the
39                rating contions that were previously armed (through the Trigger-Type AVP, e.g. QoS, Radio
40                Access Technology,…). The specific condition that has changed is indicated in an associated
41                Trigger-Type AVP.



                                                             49
     X.P0013-0153


1       FORCED_REAUTHORIZATION                                      (7)

2              This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-
3               Service-Credit-Control AVP where its appears is that it is there has been a Server initiated re-
4               authorization procedure, i.e. receipt of RAR command

5    The values QHT, FINAL, VALIDITY_TIME, FORCED_REAUTHORIZATION,
6    RATING_CONDITION_CHANGE apply for all quota types and are used directly in the Multiple-Services-
7    Credit-Control AVP, whereas the values THRESHOLD, QUOTA_EXHAUSTED and
8    OTHER_QUOTA_TYPE apply to one particular quota type and shall occur only in the Used-Service-Units
9    AVP.
10   When the value RATING_CONDITION_CHANGE is used, the Trigger-Type AVP shall also be included to
11   indicate the specific event which caused the re-authorization request.
12




                                                           50

								
To top