3GPP TS 32.299
3GPP TS 32.299
3GPP TS 32.299
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this
Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 13 2 3GPP TS 32.299 V13.4.0 (2016-03)
Keywords
charging, management, protocol, Diameter
3GPP
Postal address
Internet
http://www.3gpp.org
Copyright Notification
© 20152016, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
3GPP
Release 13 3 3GPP TS 32.299 V13.4.0 (2016-03)
Contents
Foreword.................................................................................................................................................12
1 Scope............................................................................................................................................13
2 References.....................................................................................................................................14
3 Definitions, symbols and abbreviations........................................................................................16
3.1 Definitions.................................................................................................................................................16
3.2 Symbols.....................................................................................................................................................16
3.3 Abbreviations............................................................................................................................................17
4 Architecture considerations...........................................................................................................18
4.1 High level architecture..............................................................................................................................18
4.1.0 General................................................................................................................................................18
4.1.1 Charging related transfer requirements...............................................................................................19
5 3GPP charging applications requirements.....................................................................................20
5.1 Offline charging scenarios........................................................................................................................20
5.1.1 Basic principles...................................................................................................................................20
5.1.1.0 Introduction....................................................................................................................................20
5.1.1.1 Event based charging.....................................................................................................................21
5.1.1.2 Session based charging..................................................................................................................22
5.1.2 Basic operation....................................................................................................................................24
5.2 Online charging scenarios.........................................................................................................................25
5.2.0 Introduction.........................................................................................................................................25
5.2.1 Basic principles...................................................................................................................................25
5.2.2 Charging scenarios..............................................................................................................................26
5.2.2.0 Introduction....................................................................................................................................26
5.2.2.1 Immediate Event Charging (IEC)..................................................................................................27
5.2.2.1.1 Decentralized Unit Determination and Centralized Rating.....................................................27
5.2.2.1.2 Centralized Unit Determination and Centralized Rating.........................................................28
5.2.2.1.3 Decentralized Unit Determination and Decentralized Rating..................................................29
5.2.2.1.4 Further options.........................................................................................................................30
5.2.2.2 Event Charging with Unit Reservation (ECUR)............................................................................31
5.2.2.2.1 Decentralized Unit Determination and Centralized Rating.....................................................31
5.2.2.2.2 Centralized Unit Determination and Centralized Rating.........................................................33
5.2.2.2.3 Decentralized Unit Determination and Decentralized Rating..................................................35
5.2.2.3 Session charging with Reservation................................................................................................37
5.2.2.3.1 Decentralized Unit Determination and Centralized Rating.....................................................37
5.2.2.3.2 Centralized Unit Determination and Centralized Rating.........................................................39
5.2.2.3.3 Decentralized Unit Determination and Decentralized Rating..................................................41
5.2.3 Basic operations...................................................................................................................................43
5.3 Other requirements....................................................................................................................................46
5.3.1 Re-authorization..................................................................................................................................46
5.3.2 Threshold based re-authorization triggers...........................................................................................46
5.3.3 Termination action...............................................................................................................................46
5.3.4 Account expiration..............................................................................................................................46
6 3GPP charging applications – Protocol aspects.............................................................................47
6.1 Basic principles for Diameter offline charging.........................................................................................47
6.1.0 Introduction.........................................................................................................................................47
6.1.1 Event based charging...........................................................................................................................48
6.1.2 Session based charging........................................................................................................................49
6.1.3 Offline charging error cases - Diameter procedures............................................................................51
6.1.3.1 CDF connection failure..................................................................................................................51
6.1.3.2 No reply from CDF........................................................................................................................51
6.1.3.3 Duplicate detection........................................................................................................................51
6.1.3.4 CDF detected failure......................................................................................................................51
6.2 Message contents for offline charging......................................................................................................52
3GPP
Release 13 4 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 5 3GPP TS 32.299 V13.4.0 (2016-03)
7.1.2 Void.....................................................................................................................................................85
7.1.3 Accounting-Output-Octets AVP.........................................................................................................85
7.1.4 Void.....................................................................................................................................................86
7.1.5 Acct-Application-Id AVP....................................................................................................................86
7.1.6 Auth-Application-Id AVP...................................................................................................................86
7.1.7 Called-Station-Id AVP........................................................................................................................86
7.1.8 Event-Timestamp AVP.......................................................................................................................86
7.1.9 Multiple-Services-Credit-Control AVP...............................................................................................86
7.1.10 Rating-Group AVP..............................................................................................................................87
7.1.11 Result-Code AVP................................................................................................................................87
7.1.12 Service-Context-Id AVP.....................................................................................................................88
7.1.13 Service-Identifier AVP........................................................................................................................88
7.1.14 Used-Service-Unit AVP......................................................................................................................88
7.1.15 User-Name AVP..................................................................................................................................89
7.1.16 Vendor-Id AVP...................................................................................................................................89
7.1.17 User-Equipment-Info AVP..................................................................................................................89
7.2 3GPP specific AVPs.................................................................................................................................90
7.2.0 General................................................................................................................................................90
7.2.1 Access-Network-Information AVP.....................................................................................................98
7.2.1A Access-Transfer-Information AVP.....................................................................................................98
7.2.1B Access-Transfer-Type AVP................................................................................................................99
7.2.2 Account-Expiration AVP....................................................................................................................99
7.2.3 Accumulated-Cost AVP......................................................................................................................99
7.2.4 Adaptations AVP.................................................................................................................................99
7.2.5 Additional-Content-Information AVP.................................................................................................99
7.2.6 Additional-Type-Information AVP...................................................................................................100
7.2.7 Address-Data AVP............................................................................................................................100
7.2.8 Address-Domain AVP.......................................................................................................................100
7.2.9 Address-Type AVP...........................................................................................................................100
7.2.10 Addressee-Type AVP........................................................................................................................100
7.2.11 AF-Correlation-Information AVP.....................................................................................................100
7.2.12 Alternate-Charged-Party-Address AVP............................................................................................101
7.2.12aA Announcement-Identifier AVP.........................................................................................................101
7.2.12aB Announcement-Information AVP.....................................................................................................101
7.2.12aC Announcement-Order AVP...............................................................................................................101
7.2.12A Announcing-UE-HPLMN-Identifier AVP........................................................................................101
7.2.12B Announcing-UE-VPLMN-Identifier AVP........................................................................................101
7.2.13 AoC-Cost-Information AVP.............................................................................................................101
7.2.14 AoC-Format AVP..............................................................................................................................102
7.2.15 AoC-Information AVP......................................................................................................................102
7.2.16 AoC-Request-Type AVP...................................................................................................................102
7.2.17 AoC-Service AVP.............................................................................................................................102
7.2.18 AoC-Service-Obligatory-Type AVP.................................................................................................102
7.2.19 AoC-Service-Type AVP....................................................................................................................103
7.2.20 AoC-Subscription-Information AVP.................................................................................................103
7.2.21 Applic-ID AVP..................................................................................................................................103
7.2.22 Application-Provided-Called-Party-Address AVP...........................................................................103
7.2.23 Application-Server AVP...................................................................................................................103
7.2.24 Application-Server-Information AVP...............................................................................................103
7.2.24A Application-Specific-Data AVP........................................................................................................103
7.2.25 Associated-Party-Address AVP........................................................................................................104
7.2.26 Associated-URI AVP........................................................................................................................104
7.2.27 Authorised-QoS AVP........................................................................................................................104
7.2.28 Aux-Applic-Info AVP.......................................................................................................................104
7.2.29 Base-Time-Interval AVP...................................................................................................................104
7.2.29A Basic-Service-Code AVP..................................................................................................................104
7.2.29B Bearer-Capability AVP.....................................................................................................................104
7.2.30 Bearer-Service AVP..........................................................................................................................104
7.2.30A BSSID AVP.......................................................................................................................................104
7.2.31 Called-Asserted-Identity AVP...........................................................................................................105
7.2.31A Called-Identity AVP..........................................................................................................................105
3GPP
Release 13 6 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 7 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 8 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 9 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 10 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 11 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 12 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 13 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 14 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 15 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 16 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 17 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 18 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 19 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 20 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 21 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 22 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 23 3GPP TS 32.299 V13.4.0 (2016-03)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 13 24 3GPP TS 32.299 V13.4.0 (2016-03)
1 Scope
The present document is part of a series of Technical Specifications (TSs) that specify charging functionality and
charging management in GSM/UMTS networks. The GSM/UMTS core network-charging architecture and principles
are specified in TS 32.240 [1], which provides an umbrella for other charging management documents that specify.
- The content of the CDRs' per domain and subsystem (offline charging);
- The content of real-time charging messages per domain / subsystem (online charging);
- The functionality of online and offline charging for those domains and subsystems;
- The interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or
charging events).
The complete document structure for these TSs is defined in TS 32.240 [1].
The present document specifies in detail the Diameter based offline and online charging applications for 3GPP
networks. It includes all charging parameters, scenarios and message flows..
All terms, definitions and, abbreviations used in the present document, that are common across 3GPP TSs, are defined
in TR 21.905 [100]. Those that are common across charging management in GSM/UMTS domains, services or
subsystems are provided in the umbrella document TS 32.240 [1] and are copied into clause 3 of the present document
for ease of reading. Finally, those items that are specific to the present document are defined exclusively in the present
document.
Furthermore, requirements that govern the charging work are specified in TS 22.115 [101].
3GPP
Release 13 25 3GPP TS 32.299 V13.4.0 (2016-03)
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[200] 3GPP TS 23.207: "End to end quality of service concept and architecture".
[202] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3".
[204] 3GPP TS 29.229: "Cx and Dx Interfaces based on the Diameter protocol; Protocol Details".
[205] Void.
[207] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting
packet based services and Packet Data Networks (PDN)".
[208] 3GPP TS 23.140: " Multimedia Messaging Service (MMS); Functional description; Stage 2".
[212] Void.
[213] 3GPP TS 29.140: "MM10 interface based on Diameter protocol; Stage 3".
[214] 3GPP TS 29.214: "Policy and Charging Control over Rx reference point; Stage 3".
[215] 3GPP TS 29.212: "Policy and Charging Control (PCC); Reference points".
3GPP
Release 13 26 3GPP TS 32.299 V13.4.0 (2016-03)
[217] 3GPP TS 22.142: "Value Added Services (VAS) for Short Message Service (SMS) requirements".
[219] 3GPP TS 29.272: " Mobility Management Entity (MME) and Serving GPRS Support Node
(SGSN) related interfaces based on Diameter protocol".
[220] 3GPP TS 24.605: "Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem;
Protocol specification".
[221] 3GPP TS 29.329: "Sh Interface based on the Diameter protocol;Protocol details".
[225] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP)
across the Gn and Gp interface".
[226] 3GPP TS 29.274: "Evolved GPRS Tunnelling Protocol for Control Plane (GTPv2-C); Stage 3".
[229] 3GPP TS 29.173: "Location Services (LCS);Diameter-based SLh interface for Control Plane
LCS".
[230] 3GPP TS 29.272: "Evolved Packet System (EPS);Mobility Management Entity (MME) and
Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol".
[231] 3GPP TS 29.337: "Diameter-based T4 interface for communications with packet data networks
and applications ".
[233] 3GPP TS 29.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL);
CAMEL Application Part (CAP) specification".
[234] 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem
and Circuit Switched (CS) networks".
[236] 3GPP TS 24.334: "Proximity-services (ProSe) User Equipment (UE) to ProSe function protocol
aspects".
[237] 3GPP TS 29.273: "Evolved Packet System (EPS); 3GPP EPS AAA Interfaces".
[238] 3GPP TS 29.343: "Proximity-services (ProSe) function to ProSe application server aspects (PC2)".
[240] Void.
[241] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specification".
[244] 3GPP TS 29.128: "Mobility Management Entity (MME) and Serving GPRS Support Node
(SGSN) interfaces for interworking with packet data networks and applications".
[245] 3GPP TS 29.336: "Home Subscriber Server (HSS) diameter interfaces for interworking with
packet data networks and applications".
3GPP
Release 13 27 3GPP TS 32.299 V13.4.0 (2016-03)
[300] ETSI TS 283 034 v2.2.0: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e4 interface based
on the DIAMETER protocol".
[403] Void.
[404] IETF RFC 7315 (2014): "Private Extensions to the Session Initiation Protocol (SIP) for the 3rd
Generation Partnership Projects (3GPP)".
[407] IETF RFC 4005 (2005): "Diameter Network Access Server Application".
[408] IETF RFC 3264 (2002): "An Offer/Answer Model with the Session Description Protocol (SDP) ".
[409] IEEE 802.11-2012: "IEEE Standard for Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area networks - Specific
requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
[410] IETF RFC 3066 (2001): "Tags for the Identification of Languages".
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [100] and the following apply.
A term defined in the present document takes precedence over the definition of the same term, if any, in
TR 21.905 [100].
middle tier TS: term used for the 3GPP charging TSs that specify the domain / subsystem / service specific, online and
offline, charging functionality. These are all the TSs in the numbering range from TS 32.250 to TS 32.27x, e.g. TS
32.250 [10] for the CS domain, or TS 32.270 [30] for the MMS service. Currently, there is only one "tier 1" TS in
3GPP, which is the TS 32.240 that specifies the charging architecture and principles. Finally, there are a number of top
tier TSs in the 32.29x numbering range ([50] ff) that specify common charging aspects such as parameter definitions,
encoding rules, the common billing domain interface or common charging applications.
offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered
online charging: charging mechanism where charging information can affect, in real-time, the service rendered and
therefore a direct interaction of the charging mechanism with session/service control is required
3.2 Symbols
For the purposes of the present document, the following symbols apply:
Rf Offline Charging Reference Point between a 3G network element and the CDF.
Ro Online Charging Reference Point between a 3G network element and the OCS.
3GPP
Release 13 28 3GPP TS 32.299 V13.4.0 (2016-03)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACA ACcounting-Answer
ACR ACcounting-Request
ADC Application Detection and Control
AoC Advice of Charge
AS Application Server
ASA Abort-Session-Answer
ASR Abort-Session- Request
AVP Attribute Value Pair
CCA Credit-Control-Answer
CCR Credit-Control-Request
CDF Charging Data Function
CDR Charging Data Record
CEA Capabilities-Exchange-Answer
CER Capabilities-Exchange-Request
CGI Cell Global Identification
CI Cost-Information
CSG Closed Subscriber Group
CSG ID Closed Subscriber Group Identity
DBPA Diameter Base Protocol Accounting
DCD Dynamic Content Delivery
DPA Disconnect-Peer-Answer
DPR Disconnect-Peer-Request
DRM Digital Rights Management
DWA Device-Watchdog-Answer
DWR Device-Watchdog-Request
ECGI E-UTRAN Cell Global Identifier
ECUR Event Charging with Unit Reservation
FQDN Fully Qualified Domain Name
FUI Final-Unit-Indication
HSGW HRPD Serving GateWay
GSU Granted-Service-Unit
IEC Immediate Event Charging
IM Instant Messaging
IMS IP Multimedia Subsystem
IMS-AGW IMS Access Media Gateway
MSCC Multiple Services Credit-Control
NetLoc Network provided Location information
NNI Network to Network Interface
OCS Online Charging System
ProSe Proximity-based Services
RAA Re-Auth-Answer
RAI Routeing Area Identity
RAR Re-Auth-Request
RAVEL Roaming Architecture for VoicE over IMS with Local breakout
SAI Service Area Identifier
SCCP Signalling Connection Control Part
SDP Session Description Protocol
TAI Tracking Area Identity
TDF Traffic Detection Function
TrGW Transition GateWay
TWAG Trusted WLAN Access Gateway
TWAN Trusted WLAN Access Network
UWAN Untrusted Wireless Access Network
VCS Voice Call Service
3GPP
Release 13 29 3GPP TS 32.299 V13.4.0 (2016-03)
4 Architecture considerations
3GPP
Release 13 30 3GPP TS 32.299 V13.4.0 (2016-03)
Different mappings of the ubiquitous offline charging functions, CTF, CDF and CGF, onto physical implementations
are possible. Further details of the configuration refer toTS 32.240 [1]. Details of the implementation options per
domain / subsystem / service (usually a subset of the overall possible variants described above) are specified in the
respective middle tier TSs.
Within the scope of this release, each Network Element that generates charging information sends the information only
to the charging entities of the same PLMN, and not to charging entities in other PLMNs.
To implement roaming unbundling for EU roaming regulation III, an architectural solution known as the Single IMSI
architecture has been defined. In this architecture a specific Service-NE (known as a Proxy Function) uses the Ro
reference point for sending charging information to an OCF in another network. The details of this architecture are
defined in Annex B of TS 32.240 [1].
To implement PS domain online charging for roaming context, PCEF in the VPLMN uses the Gy reference point, and
TDF in the VPLMN uses the Gyn reference point, both based on Ro interface and specified in TS 32.251[11], for
sending charging information to an OCS in the HPLMN. A simplified profile is provided in Annex E of TS 32.251[11]
for deployment purposes.
Each CDF in the PLMN may know of other CDFs' network addresses (e.g., for redundancy reasons, to be able to
recommend another CDF address with the Redirection Request message). This is achieved by OAM&P configuration
facilities that enables each CDF to have a configurable list of peer CDF addresses.
3GPP
Release 13 31 3GPP TS 32.299 V13.4.0 (2016-03)
5.1.1.0 Introduction
Offline charging for both events and sessions between CTF and the CDF is performed using the Rf reference point as
defined in TS 32.240 [1].
3GPP
Release 13 32 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: UE-A requests the desired resource from the Network Element.
2. Content/Service Delivery: the Network Element delivers the content/service.
3. Charging Data Generation: the CTF generates charging data related to service delivery.
4. Record Charging Data Request: the CTF requests the CDF to store event related charging data for CDR
generation purposes.
5. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR
generation configuration.
6. Record Charging Data Response: the CDF informs the CTF that charging data was stored.
3GPP
Release 13 33 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: UE-A requests the desired session from the Network Element.
2. Session ongoing: the Network Element establish the session.
3. Charging Data Generation: the CTF generates charging data related to session.
4. Record Charging Data Request: the CTF requests the CDF to store session related charging data for CDR
generation purposes.
5. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR
generation configuration.
6. Record Charging Data Response: the CDF informs the CTF that charging data was stored.
7. Charging Data Generation: the CTF generates charging data related to session due of e.g. intermediate timer
expiry.
3GPP
Release 13 34 3GPP TS 32.299 V13.4.0 (2016-03)
8. Record Charging Data Request: the CTF requests the CDF to store session related charging data for CDR
generation purposes.
9. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR
generation configuration.
10. Record Charging Data Response: the CDF informs the CTF that charging data was stored.
11. Session release: the session is released.
12. Charging Data Generation: the CTF generates charging data related to session due of session termination.
13. Record Charging Data Request: the CTF requests the CDF to store session related charging data for CDR
generation purposes.
14. Process Request: CDF stores received information. Whether the CDR is generated or not depends on CDR
generation configuration.
15. Record Charging Data Response: the CDF informs the CTF that charging data was stored.
3GPP
Release 13 35 3GPP TS 32.299 V13.4.0 (2016-03)
Table 5.1.2.1 and table 5.1.2.2 describe the content of these operations.
3GPP
Release 13 36 3GPP TS 32.299 V13.4.0 (2016-03)
Unit determination refers to the calculation of the number of non-monetary units (service units, data volume, time and
events) that shall be assigned prior to starting service delivery.
- With Centralized Unit Determination, the OCF determines the number of non-monetary units that a certain
service user can consume based on a service key received from the CTF.
- With the Decentralized Unit Determination approach, the CTF determines itself how many units are required to
start service delivery, and requests these units from the OCF.
After checking the service user's account balance, the OCF returns the number of granted units to the CTF. The CTF is
then responsible for the supervision of service delivery. Particularly, the CTF shall limit service delivery to the
corresponding number of granted units.
Rating refers to the calculation of a price out of the non-monetary units calculated by the unit determination function.
- With the Centralized Rating approach, the CTF and the OCF exchange information about non-monetary units.
The OCF translates these units into monetary units.
- With the Decentralized Rating approach, the corresponding rating control is performed within the CTF.
Consequently, CTF and OCF exchange information about monetary units.
Three cases for online charging can be distinguished: Immediate Event Charging (IEC), Event Charging with Unit
Reservation (ECUR) and Session Charging with Unit Reservation (SCUR). These cases are further described in
TS 32.240 [1].
3GPP
Release 13 37 3GPP TS 32.299 V13.4.0 (2016-03)
5.2.2.0 Introduction
In order to perform event charging via Ro, the scenarios between the involved entities UE-A, OCF and CTF need to be
defined. The charging flows shown in this subclause include scenarios with immediate event charging and event
charging with reservation. In particular, the following cases are shown:
The combination of Centralized Unit Determination with Decentralized Rating is not possible.
3GPP
Release 13 38 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: UE-A requests the desired resource from the Network Element.
2. Units Determination: depending on the requested service the CTF determines the number of units
accordingly.
3. Debit Units Request: the CTF requests the OCF to assign the defined number of units.
4. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that represents
the price for the number of units determined in item 2.
5. Account Control: provided that the user's credit balance is sufficient, the OCF triggers the deduction of the
calculated amount from the subscriber's account.
6. Debit Units Response: the OCF informs the CTF of the number of granted units.
7. Content/Service Delivery: the CTF delivers the content/service at once, in fractions or in individually
chargeable items, corresponding to the number of granted units.
8. Credit Unit Control (cont.): this function block is optional and a replication of items 2 to 6.
9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the
occurrence of item 8.
10. Session released: Session is released.
3GPP
Release 13 39 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests the desired resource or content from the Network Element.
2. Debit Units Request: depending on the service requested by the UE-A, the CTF determines the service key and
forwards the Debit Units Request with service key to the OCF.
3. Units Determination: the OCF determines the number of non-monetary units needed for the content/service
delivery, based on the received service key.
4. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that represent the
price for the number of units determined in item 3.
5. Account Control: provided that the user's credit balance is sufficient, the OCF triggers the deduction of the
calculated amount from the subscriber's account.
6. Debit Units Response: the OCF informs the CTF of the number of granted units. This includes the case where the
number of units granted indicates the permission to render the service that was identified by the received service
key.
7. Content/Service Delivery: the CTF delivers the content/service at once, in fractions or in individually chargeable
items, corresponding to the number of granted units.
8. Credit Service Control (cont.): this function block is optional and a replication of items 2 to 6.
9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the
occurrence of item 8.
10. Session released: the session is released.
3GPP
Release 13 40 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests the desired content from the Network Element.
2. Units Determination: depending on the service requested by the UE-A, the CTF determines the number of units
accordingly.
3. Rating Control: the CTF calculates the number of monetary units that represent the price for the number of units
determined in item 2.
4. Debit Units Request: the CTF requests the OCF to assure the deduction of an amount corresponding to the
calculated number of monetary units from the subscriber's account.
5. Account Control: provided that the user's credit balance is sufficient, the OCF triggers the deduction of the
calculated amount from the subscriber's account.
6. Debit Units Response: the OCF indicates to the CTF the number of deducted monetary units.
7. Content/Service Delivery: the CTF delivers the content/service at once, in fractions or in individually chargeable
items, corresponding to the number of units as specified in items 2 and 3.
8. Credit Amount Control (cont.): this function block is optional and a replication of items 2 to 6.
9. Content/Service Delivery (cont.): the continuation of content delivery occurs in correspondence with the
occurrence of item 8.
10. Session released: the session is released.
3GPP
Release 13 41 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 42 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests the desired content/service from the NE.
2. Units Determination: depending on the requested service the CTF determines the number of units accordingly.
3. Reserve Units Request: the CTF requests the OCF to reserve the number of units determined in item 2.
4. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that represents the
price for the number of units determined in item 2.
5. Account Control: the OCF checks whether the user's account balance is sufficient for the requested reservation.
6. Reservation Control: if the user's account balance is sufficient then the corresponding reservation is made.
7. Reserve Units Response: the OCF informs the CTF of the reserved number of units.
3GPP
Release 13 43 3GPP TS 32.299 V13.4.0 (2016-03)
8. Reserved Units Supervision: simultaneously with the service delivery, the CTF monitors the consumption of the
reserved units.
9. Content/Service Delivery: the CTF delivers the content/service at once, in fractions or in individually chargeable
items, corresponding to the reserved number of units.
10. Debit Units Request: the CTF requests the OCF to assure the deduction of an amount corresponding to the
consumed number of units from the subscriber's account. In the case that no further units are required for this
service, an appropriate indication triggering the release of the remaining reservation is given.
11. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct from the
subscriber's account.
12. Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
13. Debit Units Response: the OCF informs the CTF of the actually deducted units.
14. Session Release: the session is released.
3GPP
Release 13 44 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests the desired content from the CTF.
2. Reserve Units Request: depending on the service requested by the UE-A, the CTF determines the service key and
forwards the Reserve Units Request with service key to the OCF.
3. Units Determination: the OCF determines the number of non-monetary units needed for the content/service
delivery, based on the received service key.
4. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that represent the
price for the number of units determined in item 3.
5. Account Control: the OCF checks whether the user's account balance is sufficient for the requested reservation.
6. Reservation Control: if the user's account balance is sufficient, then the corresponding reservation is made.
7. Reserve Units Response: the OCF informs the CTF of the reserved number of units. This includes the case where
the number of units reserved indicates the permission to render the service that was identified by the received
service key.
3GPP
Release 13 45 3GPP TS 32.299 V13.4.0 (2016-03)
8. Granted Units Supervision: simultaneously with the service delivery, the CTF monitors the consumption of the
reserved units.
9. Content/Service Delivery: the CTF delivers the content/service at once, in fractions or in individually chargeable
items, corresponding to the reserved number of units.
10. Debit Units Request: the CTF provides according to previous Reserve Units Response the request to deduct the
amount of units corresponding to the consumed number of units.
11. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct from the
subscriber's account.
12. Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
13. Debit Units Response: the OCF informs the CTF of the actually deducted units.
14. Session Released: the session is released.
3GPP
Release 13 46 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests the desired content from the CTF.
2. Units Determination: depending on the service requested by the UE-A, the CTF determines the number of units
accordingly.
3. Rating Control: the CTF calculates the number of monetary units that represent the price for the number of units
determined in item 2.
4. Reserve Units Request: the CTF requests the OCF to assure the reservation of an amount corresponding to the
calculated number of monetary units from the subscriber's account.
5. Account Control: the OCF checks whether the user's account balance is sufficient for the requested reservation.
6. Reservation Control: if the user's credit balance is sufficient, then the corresponding reservation is made.
7. Reserve Units Response: the OCF informs the CTF of the reserved number of monetary units.
8. Budget Control: simultaneously with the service delivery, the CTF monitors the consumption of the granted
amount.
9. Content/Service Delivery: the CTF delivers the content/service at once, in fractions or in individually chargeable
items, corresponding to the number of units.
3GPP
Release 13 47 3GPP TS 32.299 V13.4.0 (2016-03)
10. Debit Units Request: the CTF requests the OCF to assure the deduction of an amount corresponding to the
consumed number of monetary units from the subscriber's account.
11. Account Control: the OCF triggers the deduction of the consumed amount from the subscriber's account.
12. Debit Units Response: the OCF indicates to the CTF the number of deducted monetary units.
13. Session Released: the session is released.
3GPP
Release 13 48 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests session establishment from the CTF.
2. Units Determination: depending on the requested type of the session the CTF determines the number of units
accordingly.
3. Reserve Units Request: the CTF requests the OCF to reserve the number of units determined in item 2
4. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that represents the
price for the number of units determined in item 2.
5. Account Control: the OCF checks whether the user's account balance is sufficient for the requested reservation.
6. Reservation Control: if the user's account balance is sufficient then the corresponding reservation is made.
3GPP
Release 13 49 3GPP TS 32.299 V13.4.0 (2016-03)
7. Reserve Units Response: the OCF informs the CTF of the reserved number of units.
8. Reserved Units Supervision: simultaneously with the ongoing session, the CTF monitors the consumption of the
reserved units.
9. Session ongoing: the CTF maintains the session. One or more debit and reserve operations may be performed
when the session is ongoing.
10. Session Release: the session is released
11. Debit Units Request: the CTF requests the OCF to assure the deduction of an amount corresponding to the
consumed number of units from the subscriber's account.
12. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct from the
subscriber's account.
13. Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
14. Debit Units Response: the OCF informs the CTF of the actually deducted units.
3GPP
Release 13 50 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests the session establishment from the CTF.
2. Reserve Units Request: depending on the requested type of the session by the UE-A, the CTF determines the
service key identifier and forwards the Reserve Un with service key its Request to the OCF.
3. Units Determination: the OCF determines the number of non-monetary units needed for the content/service
delivery, based on the received service key.
4. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units that represent the
price for the number of units determined in item 3.
5. Account Control: the OCF checks whether the user's account balance is sufficient for the requested reservation.
6. Reservation Control: if the user's account balance is sufficient, then the corresponding reservation is made.
3GPP
Release 13 51 3GPP TS 32.299 V13.4.0 (2016-03)
7. Reserve Units Response: the OCF informs the CTF of the reserved number of units. This includes the case where
the number of units reserved indicates the permission to render the service that was identified by the received
service key.
8. Granted Units Supervision: simultaneously with the ongoing session, the CTF monitors the consumption of the
reserved units.
9. Session ongoing: the CTF maintains the session. One or more debit and reserve operations may be performed
when the session is ongoing.
10. Session Released: the session is released.
11. Debit Units Request: the CTF requests the OCF to assure the deduction of an amount corresponding to the
consumed number of units from the subscriber's account
12. Rating Control: assisted by the rating entity the OCF calculates the number of monetary units to deduct from the
subscriber's account.
13. Account Control: the OCF triggers the deduction of the calculated amount from the subscriber's account.
14. Debit Units Response: the OCF informs the CTF of the actually deducted units.
3GPP
Release 13 52 3GPP TS 32.299 V13.4.0 (2016-03)
1. Request for resource usage: The UE-A requests the session establishment from the CTF.
2. Units Determination: depending on the requested type of the session by the UE-A, the CTF determines the
number of units accordingly.
3. Rating Control: the CTF calculates the number of monetary units that represent the price for the number of units
determined in item 2.
4. Reserve Units Request: the CTF requests the OCF to assure the reservation of an amount corresponding to the
calculated number of monetary units from the subscriber's account.
5. Account Control: the OCF checks whether the user's account balance is sufficient for the requested reservation.
6. Reservation Control: if the user's credit balance is sufficient, then the corresponding reservation is made.
7. Reserve Units Response: the OCF informs the CTF of the reserved number of monetary units.
8. Budget Control: simultaneously with the ongoing session, the CTF monitors the consumption of the granted
amount.
9. Session ongoing: the CTF maintains the session. One or more debit and reserve operations may be performed
when the session is ongoing.
10. Session Released: the session is released.
3GPP
Release 13 53 3GPP TS 32.299 V13.4.0 (2016-03)
11. Debit Units Request: the CTF requests the OCF to assure the deduction of an amount corresponding to the
consumed number of monetary units from the subscriber's account.
12. Account Control: the OCF triggers the deduction of the consumed amount from the subscriber's account.
13. Debit Units Response: the OCF indicates to the CTF the number of deducted monetary units.
3GPP
Release 13 54 3GPP TS 32.299 V13.4.0 (2016-03)
IEC uses the Direct Debiting One Time Event procedure specified in RFC 4006 [402] and therefore is performed by the
use of the logical "Debit Units" operation, as specified in clause 6.3.3.
SCUR and ECUR use both the "Debit Units" and "Reserve Units" operations.
SCUR uses the Session Based Credit-Control procedure specified in RFC 4006 [402]. In session charging with unit
reservation, when the "Debit Units" and "Reserve Units" operations are both needed, they shall be combined in one
message, as specified in clause 6.3.5.
For SCUR and ECUR the consumed units are deducted from the subscriber's account after service delivery.
Thus, the reserved and consumed units are not necessarily the same. Using this operation, it is also possible for the CTF
to modify the current reservation, including the return of previously reserved units.
Table 5.2.3.1 and table 5.2.3.2 describe the content of these operations.
3GPP
Release 13 55 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 56 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 57 3GPP TS 32.299 V13.4.0 (2016-03)
Mid-session service events (re-authorization triggers) may affect the rating of the current service usage.
The server may instruct the Credit-Control client to re-authorize the quota upon a number of different session related
triggers that can affect the rating conditions.
When a re-authorization is trigger, the client shall reports quota usage. The reason for the quota being reported shall be
notified to the server.
3GPP
Release 13 58 3GPP TS 32.299 V13.4.0 (2016-03)
The charging architecture implementing Diameter adheres to the structure where all communications for offline
charging purposes between the CTF (Diameter client) and the CDF (Diameter server) are carried out on the Diameter
Rf reference point, where the CTF reports charging information to the Charging Data Function (CDF). The CDF uses
this information to construct and format CDRs. The above-mentioned reference points are defined in TS 32.240 [1].
A configurable timer is supported in the CDF to supervise the reception of the ACR[Interim] and/or ACR[Stop]. An
instance of the "Timer" is started at the beginning of the accounting session, reset on the receipt of an ACR[Interim] and
stopped at the reception of the ACR[Stop]. Upon expiration of the timer, the CDF stops the accounting session with the
appropriate error indication.
For offline charging, the CTF implements the accounting state machine described in RFC 3588 [401].
The server (CDF) implements the accounting state machine "SERVER, STATELESS ACCOUNTING" as specified in
RFC 3588 [401], i.e. there is no order in which the server expects to receive the accounting information.
The offline charging functionality is based on the Network Elements reporting accounting information upon reception
of various messages which trigger charging generation, as most of the accounting relevant information is contained in
these messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [Start, Interim, Stop and
Event] from the Network Elements to the CDF.
Following the Diameter base protocol specification, the following "types" of accounting data may be sent with regard to
offline charging:
ACR types START, INTERIM and STOP are used for accounting data related to successful sessions. In contrast,
EVENT accounting data is unrelated to sessions, and is used e.g. for a simple registration or interrogation and
successful service event triggered by a Network Element. In addition, EVENT accounting data is also used for
unsuccessful session establishment attempts.
The flows and scenarios for the above two described cases are further detailed below.
3GPP
Release 13 59 3GPP TS 32.299 V13.4.0 (2016-03)
Figure 6.1.1.1 shows the transactions that are required on the Diameter offline interface in order to perform event based
charging. The operation may alternatively be carried out prior to, concurrently with or after service/content delivery.
Step 1:The Network Element receives indication that service has been used/delivered.
Step 2:The Network Element (acting as client) sends Accounting-Request (ACR) with Accounting-Record-Type
AVP set to EVENT_RECORD to indicate service specific information to the CDF (acting as server).
Step 3:The CDF receives the relevant service charging parameters and processes accounting request.
Step 4:The CDF returns Accounting-Answer message with Accounting-Record-Type AVP set to
EVENT_RECORD to the Network Element in order to inform that charging information was received.
3GPP
Release 13 60 3GPP TS 32.299 V13.4.0 (2016-03)
Figure 6.1.2.1 shows the transactions that are required on the Diameter offline interface in order to perform session
based charging.
Step 1:The Network Element receives a service request. The service request may be initiated either by the user or
the other Network Element.
Step 2:In order to start accounting session, the Network Element sends a Accounting-Request (ACR) with
Accounting-Record-Type AVP set to START_RECORD to the CDF.
Step 4:The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to
START_RECORD to the Network Element and possibly Acct-Interim-Interval AVP (AII) set to non-zero
value indicating the desired intermediate charging interval.
Step 5:When either AII elapses or charging conditions changes are recognized at Network Element (NE), the NE
sends an Accounting-Request (ACR) with Accounting-Record-Type AVP set to INTERIM_RECORD to the
CDF.
3GPP
Release 13 61 3GPP TS 32.299 V13.4.0 (2016-03)
Step 7:The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to
INTERIM_RECORD to the Network Element.
Step 9:The Network Element sends a Accounting-Request (ACR) with Accounting-Record-Type AVP set to
STOP_RECORD to the CDF.
Step 10: The CDF updates the CDR accordingly and closes the CDR.
Step 11: The CDF returns Accounting-Answer (ACA) message with Accounting-Record-Type set to
STOP_RECORD to the Network Element.
3GPP
Release 13 62 3GPP TS 32.299 V13.4.0 (2016-03)
If no CDF is reachable the Network Element may buffer the generated accounting data in non-volatile memory. Once
the CDF connection is working again, all accounting messages stored in the buffer is sent to the CDF, in the order they
were stored in the buffer.
If retransmitted ACRs' are sent, they are marked with the T-flag as described in RFC 3588 [401], in order to allow
duplicate detection in the CDF, as specified in the next clause 6.1.3.3.
If the CDF receives a message that is marked as retransmitted and this message was already received, then it discards
the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information
in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from
duplicated message(s) is used.
3GPP
Release 13 63 3GPP TS 32.299 V13.4.0 (2016-03)
6.2.1.1 General
The corresponding Diameter accounting application messages for the Charging Data Transfer operation is Accounting-
Request (ACR) and Accounting-Answer (ACA) as specified in the Diameter Base Protocol Accounting (DBPA)
application in RFC 3588 [401].
Table 6.2.1.1.1 describes the use of these messages which are adapted for 3GPP offline charging.
Additional Diameter messages (i.e. DPR/DPA, DWR/DWA)are used according to the Diameter Base Protocol
Accounting (DBPA) specification in RFC 3588 [401].
Those Diameter Accounting AVPs that are used for 3GPP offline charging are marked in table 6.2.2.1 and table 6.2.3.1
with a category as specified in TS 32.240 [1].
An AVP in grey strikethrough in the message format (in grey in the tables) is not used by 3GPP.
3GPP
Release 13 64 3GPP TS 32.299 V13.4.0 (2016-03)
The ACR message format is defined according to the Diameter Base Protocol in RFC 3588 [401] as follows:
<ACR> ::= < Diameter Header: 271, REQ, PXY >
3GPP
Release 13 65 3GPP TS 32.299 V13.4.0 (2016-03)
Table 6.2.2.1 illustrates the basic structure of a 3GPP Diameter Accounting-Request message as used for 3GPP offline
charging.
3GPP
Release 13 66 3GPP TS 32.299 V13.4.0 (2016-03)
The ACA message format is defined according to the Diameter Base Protocol in RFC 3588 [401] as follows:
<ACA> ::= < Diameter Header: 271, PXY >
3GPP
Release 13 67 3GPP TS 32.299 V13.4.0 (2016-03)
Table 6.2.3.1 illustrates the basic structure of a 3GPP Diameter Accounting-Answer message as used for offline
charging. This message is always used by the CDF as specified below, regardless of the CTF it is received from and the
ACR record type that is being replied to.
3GPP
Release 13 68 3GPP TS 32.299 V13.4.0 (2016-03)
The usage and values of Validity-Time AVP and the timer "Tcc" are under the sole control of the Credit-Control server
(OCS) and determined by operator configuration of the OCS.
The online client implements the state machine described in RFC 4006 [402] for "CLIENT, EVENT BASED" and/or
"CLIENT, SESSION BASED". I.e. when the client applies IEC it uses the "CLIENT, EVENT BASED" state machine,
and when the client applies ECUR defined in 3GPP it uses the "CLIENT, SESSION BASED" state machine for the first
and final interrogations.
The OCS implements the state machine described in RFC 4006 [402] for the "SERVER, SESSION AND EVENT
BASED" in order to support Immediate Event Charging and Event Charging with Unit Reservation.
Three cases for control of user credit for online charging are distinguished:
In the case of Immediate Event Charging (IEC),the Credit-Control process for events is controlled by the corresponding
CC-Requested-Type EVENT_REQUEST that is sent with Credit-Control-Request (CCR) for a given Credit-Control
event.
In the case of Event Charging with Unit Reservation (ECUR) the CC-Request-Type INITIAL /
TERMINATION_REQUEST are used for charging for a given Credit-Control event, however, where a reservation is
made prior to service delivery and committed on execution of a successful delivery.
Session Charging with Unit Reservation is used for Credit-Control of sessions and uses the CC-Request-Type
INITIAL / UPDATE and TERMINATION_REQUEST.
The Network Element may apply IEC, where CCR Event messages are generated, or ECUR, using CCR Initial and
Termination. The decision whether to apply IEC or ECUR is based on the service and/or operator's policy.
3GPP
Release 13 69 3GPP TS 32.299 V13.4.0 (2016-03)
Step 2.The Network Element performs direct debiting prior to service execution. Network element (acting as DCCA
client) sends CCR with CC-Request-Type AVP set to EVENT_REQUEST to indicate service specific
information to the OCS (acting as DCCA server). The Requested-Action AVP (RA) is set to
DIRECT_DEBITING. If known, the Network Element may include Requested-Service-Unit AVP (RSU)
(monetary or non-monetary units) in the request message.
Step 3.Having transmitted the CCR message the Network Element starts the communication supervision timer 'Tx'
(RFC 4006 [402]). Upon receipt of the Credit-Control- Answer (CCA) message the Network Element shall
stop timer Tx.
Step 5.The OCS returns CCA message with CC-Request-Type AVP set to EVENT_REQUEST to the Network
Element in order to authorize the service execution
(Granted-Service-Unit AVP (GSU) and possibly Cost-Information AVP (CI) indicating the cost of the
service and Remaining-Balance AVP are included in the CCA message).
The CCA message has to be checked by the Network Element accordingly and the requested service is
controlled concurrently with service delivery. The Refund-Information AVP may be included in the CCA
message in order to be sent during the REFUND-ACCOUNT mechanism, see below scenario.
3GPP
Release 13 70 3GPP TS 32.299 V13.4.0 (2016-03)
NOTE: It is possible to perform also, CHECK_BALANCE and PRICE_ENQUIRY using above described
mechanism RFC 4006 [402].
The Direct debiting operation is performed, previously, as described in RFC 4006 [402].
Step 1.The service charged previously through Direct Debiting Operation is finally proved to be unsuccessfully
delivered.
Step 2.As a consequence, the Network Element performs direct debiting operation in order to perform the related
refund. Network element (acting as DCCA client) sends CCR with CC-Request-Type AVP set to
EVENT_REQUEST to indicate service specific information to the OCS (acting as DCCA server). The
Requested-Action AVP (RA) is set to REFUND-ACCOUNT.
The Network Element includes Refund-Information AVP if received in the previous IEC CCA.
Step 3.Having transmitted the CCR message the Network Element starts the communication supervision timer 'Tx'
(RFC 4006 [402]). Upon receipt of the Credit-Control- Answer (CCA) message the Network Element shall
stop timer Tx.
Step 4.The OCS reads the AVPs included in the CCR and performs the refund accordingly.
Step 5.The OCS returns CCA message with CC-Request-Type AVP set to EVENT_REQUEST and the related
result code.
3GPP
Release 13 71 3GPP TS 32.299 V13.4.0 (2016-03)
Step 1.The Network Element receives a service request. The service request may be initiated either by the user or
the other Network Element.
Step 2.In order to perform Reserve Units operation for a number of units (monetary or non-monetary units), the
Network Element sends a CCR with CC-Request-Type AVP set to INITIAL_REQUEST to the OCS. If
known, the Network Element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary
units) in the request message.
Step 3.If the service cost information is not received by the OCS, the OCS determines the price of the desired
service according to the service specific information received by issuing a rating request to the Rating
Function. If the cost of the service is included in the request, the OCS directly reserves the specified
monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the
users account.
Step 4.Once the reservation has been made, the OCS returns CCA message with CC-Request-Type set to
INITIAL_REQUEST to the Network Element in order to authorize the service execution (Granted-Service-
Unit and possibly Cost-Information indicating the cost of the service and Remaining-Balance AVP are
included in the CCA message). The OCS may return the Validity-Time (VT) AVP with value field set to a
non-zero value. The OCS may indicate in the Low-Balance-Indication AVP that the subscriber account
balance has fallen below a predefined treshold of this account.
Step 5.Content/service delivery starts and the reserved units are concurrently controlled.
Step 6.When content/service delivery is completed, the Network Element sends CCR with CC-Request-Type AVP
set to TERMINATION_REQUEST to terminate the active Credit-Control session and report the used units.
Step 7.The OCS deducts the amount used from the account. Unused reserved units are released, if applicable.
3GPP
Release 13 72 3GPP TS 32.299 V13.4.0 (2016-03)
Step 8.The OCS acknowledges the reception of the CCR message by sending CCA message with CC-Request-Type
AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the cumulative
cost of the service and Remaining-Balance AVP are included in the CCA message).
NOTE: This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown in the
figure 6.3.4.1.
3GPP
Release 13 73 3GPP TS 32.299 V13.4.0 (2016-03)
Step 1.The Network Element receives a session initiation. The session initiation may be done either by the user or
the other Network Element.
Step 2.In order to perform Reserve Units operation for a number of units (monetary or non-monetary units), the
Network Element sends a CCR with CC-Request-Type AVP set to INITIAL_REQUEST to the OCS. If
known, the Network Element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary
units) in the request message.
Step 3.If the service cost information is not received by the OCS, the OCS determines the price of the desired
service according to the service specific information received by issuing a rating request to the Rating
Function. If the cost of the service is included in the request, the OCS directly reserves the specified
monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the
users account.
Step 4.Once the reservation has been made, the OCS returns CCA message with CC-Request-Type set to
INITIAL_REQUEST to the Network Element in order to authorize the service execution (Granted-Service-
Unit and possibly Cost-Information indicating the cost of the service and Remaining-Balance AVP are
included in the CCA message). The OCS may return the Validity-Time (VT) AVP with value field set to a
non-zero value. The OCS may indicate in the Low-Balance-Indication AVP that the subscriber account
balance has fallen below a predefined threshold of this account.
3GPP
Release 13 74 3GPP TS 32.299 V13.4.0 (2016-03)
Step 5.Content/service delivery starts and the reserved units are concurrently controlled.
Step 6.During session delivery, in order to perform Debit Units and subsequent Reserve Units operations, the
Network Element sends a CCR with CC-Request-Type AVP set to UPDATE_REQUEST, to report the units
used and request additional units, respectively. The CCR message with CC-Request-Type AVP set to
UPDATE_REQUEST shall be sent by the Network Element between the INITIAL_REQUEST and
TERMINATION_REQUEST either on request of the Credit-Control application within the validity time or if
the validity time is elapsed. If known, the Network Element may include Requested-Service-Unit AVP
(monetary or non monetary units) in the request message. The Used-Service-Unit (USU) AVP is
complemented in the CCR message to deduct units from both the user's account and the reserved units,
respectively.
Step 7.The OCS deducts the amount used from the account. If the service cost information is not received by the
OCS, the OCS determines the price of the desired service according to the service specific information
received by issuing a rating request to the Rating Function. If the cost of the service is included in the
request, the OCS directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS
reserves the corresponding amount from the users account.
Step 8.Once the deduction and reservation have been made, the OCS returns CCA message with CC-Request-Type
set to UPDATE_REQUEST to the Network Element, in order to allow the content/service delivery to
continue (new Granted-Service-Unit (GSU) AVP and possibly Cost-Information (CI) AVP indicating the
cumulative cost of the service and Remaining-Balance AVP are included in the CCA message). The OCS
may include in the CCA message the Final-Unit-Indication (FUI) AVP to indicate the final granted units. The
OCS may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a
predefined threshold of this account.
Step 9.Session delivery continues and the reserved units are concurrently controlled.
Step 11. The Network Element sends CCR with CC-Request-Type AVP set to TERMINATION_REQUEST to
terminate the active Credit-Control session and report the used units.
Step 12. The OCS deducts the amount used from the account. Unused reserved units are released, if applicable.
Step 13. The OCS acknowledges the reception of the CCR message by sending CCA message with CC-Request-
Type AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the
cumulative cost of the service and Remaining-Balance AVP are included in the CCA message).
NOTE: This scenario is supervised by corresponding timers (e.g. validity time timer) that are not shown in figure
6.3.5.1.
3GPP
Release 13 75 3GPP TS 32.299 V13.4.0 (2016-03)
6.3.6.0 Introduction
This clause describes various error cases and how these should be handled.
The failure handling behaviour is locally configurable in the Network Element. If the Direct-Debiting-Failure-Handling
or Credit-Control-Failure-Handling AVP is not used, the locally configured values are used instead.
The Network Element marks the request messages that are retransmitted after a link fail over as possible duplicates with
the T-flag as described in RFC 3588 [401]. For optimized performance, uniqueness checking against other received
requests is only necessary for those records marked with the T-flag received within a reasonable time window. This
focused check is based on the inspection of the Session-Id and CC-Request-Number AVP pairs.
Note that for EBCC the duplicate detection is performed in the Correlation Function that is part of the OCS.
The OCS that receives the possible duplicate request should mark as possible duplicate the corresponding request that is
sent over the 'Rc' reference point. However, this assumption above is for further study and needs to be clarified.
In order to avoid the need for mass simultaneous quota refresh, the traffic usage can be split into resource usage before
a tariff switch and resources used after a tariff switch.
The Tariff-Time-Change AVP is used to determine the tariff switch time as described by RFC 4006 [402].
In addition to the scenarios described in RFC 4006 [402], the Tariff-Time-Change AVP may also be used in the context
of continuously time-based charging.
The Tariff-Change-Usage AVP is used within the Used-Service-Units AVP to distinguish reported usage before and
after the tariff time change.
The Tariff-Change-Usage AVP is not used directly within the Multiple-Services-Credit-Control AVP.
NOTE: RFC 4006 [402] does not directly describe how tariff changes are handled with validity time.
If validity time is used for tariff time changes it might overload the client and the server.
3GPP
Release 13 76 3GPP TS 32.299 V13.4.0 (2016-03)
The OCS may also re-authorize multiple active resource quotas within a DCC session by using a single Diameter Re-
Auth-Request/Answer message sequence.
New quota allocations received by the Network Element override any remaining held quota resources after accounting
for any resource usage while the re-authorization was in progress.
This AVP may be received from the OCS or may be locally configured. The value received from the OCS in the
Diameter CCA message always override any already existing value.
As defined in RFC 4006 [402], the Tx timer is introduced to limit the waiting time in the CTF for an answer to the CCR
sent to the OCS. When the Tx timer elapses the CTF takes an action to the end user according to the value of the Credit-
Control-Failure-Handling AVP.
It is possible that several concurrent CCR messages are triggered for the same online charging session. In this case, each
CCR message shall reset the Tx timer as defined in RFC 4006 [402].
For new Credit-Control sessions, failover to an alternative OCS should be performed if possible. For instance, if an
implementation of the CTF can determine primary OCS unavailability it can establish the new Credit-Control sessions
with a possibly available secondary OCS.
Since the OCS has to maintain session states, moving the credit-control message stream to a backup OCS requires a
complex charging context transfer solution. This charging context transfer mechanism by OCS is out of the scope of
the 3GPP standardization work.
NOTE: Credit pooling is not applicable to IEC since there is no quota management between CTF and OCF.
3GPP
Release 13 77 3GPP TS 32.299 V13.4.0 (2016-03)
6.4.1.1 General
The corresponding Diameter Credit-Control application messages for the Debit / Reserve Unit Request operation is
Credit-Control-Request (CCR) and for the Debit / Reserve Unit Response operation is Credit-Control-Answer (CCA) as
specified in RFC 4006 [402].
The Diameter Credit-Control Application (DCCA) specifies an approach based on a series of "interrogations":
1. Initial interrogation.
3. Final interrogation.
In addition to a series of interrogations, also a one time event (interrogation) can be used e.g. in the case when service
execution is always successful.
All of these interrogations use CCR and CCA messages. The CCR for the "interim interrogation" and "final
interrogation" reports the actual number of "units" that were used, from what was previously reserved. This determines
the actual amount debited from the subscriber's account.
Table 6.4.1.1.1 describes the use of these Diameter messages which are adapted for 3GPP online charging.
Additional Diameter messages (i.e. ASR/ASA, DPR/DPA, DWR/DWA, RAR/RAA) are used according to the
Diameter Base Protocol Accounting (DBPA) specification in RFC 3588 [401] and to the DCCA specification in RFC
4006 [402].
Those Diameter accounting AVPs that are used for 3GPP online charging are marked in the table of contents 6.4.2 and
6.4.3 with a category as specified in TS 32.240 [1].
In the definition of the Diameter commands, the AVPs that are specified in the referenced specifications but not used by
the 3GPP charging specifications are marked with strikethrough, e.g. [ Acct-Multi-Session-Id ].
3GPP
Release 13 78 3GPP TS 32.299 V13.4.0 (2016-03)
The CCR message format is defined according to RFC 4006 [402] as follows:
<CCR> ::= < Diameter Header: 272, REQ, PXY >
Table 6.4.2.1 illustrates the basic structure of a 3GPP Diameter CCR message as used for online charging.
3GPP
Release 13 79 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 80 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 81 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 82 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 83 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 84 3GPP TS 32.299 V13.4.0 (2016-03)
The CCA message format is defined according to RFC 4006 [402] as follows:
<CCA> ::= < Diameter Header: 272, PXY >
3GPP
Release 13 85 3GPP TS 32.299 V13.4.0 (2016-03)
Table 6.4.3.1 illustrates the basic structure of a 3GPP Diameter CCA message as used for online charging. This
message is always used by the OCF as specified below, independent of the receiving CTF and the CCR record type that
is being replied to.
3GPP
Release 13 86 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 87 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 88 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 89 3GPP TS 32.299 V13.4.0 (2016-03)
Table 6.4.4.1 illustrates the basic structure of a Diameter Credit-Control Re-Auth-Request message as used for online
charging.
3GPP
Release 13 90 3GPP TS 32.299 V13.4.0 (2016-03)
Table 6.4.5.1 illustrates the basic structure of a Diameter Credit-Control Re-Auth-Answer message as used for online
charging.
3GPP
Release 13 91 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 92 3GPP TS 32.299 V13.4.0 (2016-03)
Alternatively, if this AVP is not present, a locally configurable default value in the client shall be used.
A Quota-Holding-Time AVP value of zero indicates that this mechanism shall not be used.
Once the OCS has armed one or more triggers using the Trigger AVP at the Network Element, these triggers shall
remain in effect until another Trigger AVP is received for the same Rating Group, where the Network Element shall
arm all triggers present in the Trigger AVP and reset all other triggers. The presence of the Trigger AVP without any
Trigger-Type AVPs in a CCA allows OCS to disable all the triggers that were armed in a previous Trigger AVP.
NOTE: This removes the need for the OCS to send trigger information in every CCA message when they have
not changed.
When one of the armed triggers happen, a credit re-authorization shall be sent to the server including information
related to the service event even if all the granted service units have not been used. The quota is also being reported.
For example, if the Trigger AVP is used, then the client shall only re-authorize the quota for the service usage
associated with events which were included in the last received Trigger AVP.
If the server does not control the events for re-authorization using the Trigger AVP, the Network Element shall only
monitor for default events defined in the relevant service specific document (middle tier TS).
When the reason is RATING_CONDITION_CHANGE, the Trigger AVP shall also be included to indicate the specific
armed trigger events which caused the reporting and re-authorization request.
3GPP
Release 13 93 3GPP TS 32.299 V13.4.0 (2016-03)
Volume quota is considered used or consumed in the normal way, corresponding to actual traffic.
The consumption of time quota may be controlled by Quota-Consumption-Time as described in clause 6.5.4, or by
extended mechanisms as described in clause 6.5.7.
If the threshold triggers were included along with the quota granted, the Credit-Control client, then, shall seek re-
authorization from the server for the quota when the quota contents fall below the supplied threshold. The client shall
allow service to continue whilst the re-authorization is progress, until the original quota had been consumed.
- The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE does not include any other information.
When the user has consumed the final granted units or zero quota has been granted by the OCS, the Network
Element shall terminate the service. This is the default handling applicable whenever the client receives an
unsupported Final-Unit-Action value. The Network Element shall send CCR message with CC-Request-Type
AVP set to the value UPDATE_REQUEST and report the Used-Service-Unit AVP for the service that has
terminated, as defined in RFC 4006 [402].
- Another termination action consists in re-directing packets corresponding to a terminated service (consumption
of the final granted units or zero quota has been granted by the OCS) to an application server. This allows the
client to redirect user originated requests to a top-up server so that network access can be re-instated. This
functionality is achieved with the server returning a "REDIRECT" and redirect-to URL in the Final-Units-Action
AVP of the Multiple-Services-Credit-Control AVP. Upon receiving this result code, the Network Element shall
apply the redirection. The URL should be categorized so that the End-User's ability to reach it is guaranteed.
When zero quota has been granted by the OCS, the termination action shall be enforced at the reception of the CCA
message.
3GPP
Release 13 94 3GPP TS 32.299 V13.4.0 (2016-03)
If packets are allowed to flow during a CCR/CCA[Update]C exchange, and the Quota-Consumption-Time AVP value
in the provided quota is the same as in the previously provided quota, then the Quota-Consumption-Time runs normally
through this procedure. For example, if 5 seconds of a 10 second QCT timer have passed when a CCR[Update] is
triggered, and the CCA[Update] returns 2 seconds later, then the QCT timer will expire 3 seconds after the receipt of
the CCA and the remaining unaccounted 5 seconds of usage will be recorded against the new quota even though no
packets were transmitted with the new quota.
In the case of a new quota with the Quota-Consumption-Time AVP, or when packets are blocked during the
CCR[Update]/CCA procedure then the Quota-Consumption-Time stops running (if it was running) and quota
consumption begins again when the next service data flow packet matching the Charging Rule is received.
3GPP
Release 13 95 3GPP TS 32.299 V13.4.0 (2016-03)
Both DTP and CTP define time-envelopes in their own manner. The method of forming a time-envelope is controlled
by the Time-Quota-Mechanism AVP, which selects the algorithm and the length of the base time interval.
The base time interval, specified by the Base-Time-Interval AVP, is a basic unit for consuming quota. Quota
is deemed to be consumed at the start of each base time interval. The CTF shall allow traffic to pass for the duration of
the base time interval.
For DTP, the base time interval defines the length of the discrete time period. A time envelope corresponds
to exactly one DTP (and therefore to one base time interval). Quota consumption resumes only on the first traffic
following the expiry of the DTP (or the closure of the envelope).
For CTP, the mechanism constructs a time-envelope out of consecutive base time intervals in which traffic
has occurred up to and including the first base time interval which contains no traffic. Therefore quota
consumption continues within the time envelope, if there was traffic in the previous base time interval. After an
envelope has closed, then the quota consumption resumes only on the first traffic following the closure of the envelope.
The envelope for CTP includes the last base time interval, i.e. the one which contained no traffic. The end of
an envelope can only be determined "retrospectively".
If the CTF receives a Multiple-Services-Credit-Control AVP with both the Quota-Consumption-Time AVP and Time-
Quota-Mechanism AVP, then the Time-Quota-Mechanism AVP takes precedence and the CTF shall behave
accordingly.
If the server requires details of when the DTPs and CTPs occurred then it shall request the reporting of the
corresponding time envelopes, by including the Envelope-Reporting AVP when granting quota in the CCA
(INITIAL) to indicate whether the client shall report the start and end of each time envelope, in those cases in which
quota is consumed in envelopes. The CTF generates envelopes according to the rules described above and
carry each envelope in a separate instance of the Envelope AVP in the CCR.
Controls over time usage, defined in clause 6.5.6 and clause 6.5.7, are included.
3GPP
Release 13 96 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 97 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 98 3GPP TS 32.299 V13.4.0 (2016-03)
Those Diameter AVPs that are used are marked "M", "OM"or "Oc" in the following table.
This implies that their content can be used by the CDF for offline and by the OCF for online charging purposes.
Those Diameter AVPs that are not used are marked "-" in table 7.1.0.1.
3GPP
Release 13 99 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 100 3GPP TS 32.299 V13.4.0 (2016-03)
NOTE: Result-Code AVP is defined in Diameter Base Protocol in RFC 3588 [401]. However, new values are
used in offline and online charging applications. These additional values are defined below.
7.1.2 Void
7.1.4 Void
3GPP
Release 13 101 3GPP TS 32.299 V13.4.0 (2016-03)
[ Granted-Service-Unit ]
[ Requested-Service-Unit ]
* [ Used-Service-Unit ]
[ Tariff-Change-Usage ]
* [ Service-Identifier ]
[ Rating-Group ]
* [ G-S-U-Pool-Reference ]
[ Validity-Time ]
[ Result-Code ]
[ Final-Unit-Indication ]
[ Time-Quota-Threshold ]
[ Volume-Quota-Threshold ]
[ Unit-Quota-Threshold ]
[ Quota-Holding-Time ]
[ Quota-Consumption-Time ]
* [ Reporting-Reason ]
[ Trigger ]
[ PS-Furnish-Charging-Information ]
[ Refund-Information ]
* [ AF-Correlation-Information]
* [ Envelope ]
[ Envelope-Reporting ]
[ Time-Quota-Mechanism ]
* [ Service-Specific-Info ]
[ QoS-Information ]
* [ Announcement-Information ]
[ 3GPP-RAT-Type ]
[ Access-Availability-Change-Reason ]
* [ AVP ]
4010 DIAMETER_END_USER_SERVICE_DENIED
The OCF denies the service request due to service restrictions (e.g. terminate rating group) or limitations
related to the end-user, for example the end-user's account could not cover the requested service.
4011 DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE
The OCF determines that the service can be granted to the end user but no further Credit-Control
needed for the service (e.g. service is free of charge or is treated for offline charging).
4012 DIAMETER_CREDIT_LIMIT_REACHED
The OCF denies the service request since the end- user's account could not cover the requested service. If the
CCR contained used-service-units they are deducted, if possible.
3GPP
Release 13 102 3GPP TS 32.299 V13.4.0 (2016-03)
5003 DIAMETER_AUTHORIZATION_REJECTED
The OCF denies the service request in order to terminate the service for which credit is requested. For
example this error code is used to inform IP CAN bearer has to be terminated in the CCR message or to
inform blacklist the rating group in the Multiple-Service-Credit-Control AVP.
5030 DIAMETER_USER_UNKNOWN
The specified end user could not be found in the OCF.
5031 DIAMETER_RATING_FAILED
This error code is used to inform the CTF that the OCF cannot rate the service request due to insufficient
rating input, incorrect AVP combination or due to an AVP or an AVP value that is not recognized or
supported in the rating. For Flow Based Charging this error code is used if the Rating group is not
recognized. The Failed-AVP AVP MUST be included and contain a copy of the entire AVP(s) that could not
be processed successfully or an example of the missing AVP complete with the Vendor-Id if applicable. The
value field of the missing AVP should be of correct minimum length and contain zeroes.
3GPP
Release 13 103 3GPP TS 32.299 V13.4.0 (2016-03)
The "Release" indicates the 3GPP Release the service specific document is based upon e.g. 12 for Release 12.
As a minimum, "Release"."service-context" "@" "domain" shall be used. If the minimum is used all operator
provisionable parameters (Oc and Om) are optional.
The MNC.MCC identifies the operator implementing the service specific document, which is used to determine the
specific requirements for the operator configurable parameters.
The "extensions" is operator specific information to any extensions in a service specific document.
[ Reporting-Reason ]
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ Event-Charging-TimeStamp ]
*[ AVP ]
3GPP
Release 13 104 3GPP TS 32.299 V13.4.0 (2016-03)
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
When the User-Equipment-Info-Type AVP (AVP code 459) is set to IMEISV (0), the value within the User-Equipment-
Info-Value AVP (AVP code 460) is of type OctetString and shall be a UTF-8 encoded decimal.
The composition of the IMEISV follows the IMEI definition in TS 23.003 [224].
3GPP
Release 13 105 3GPP TS 32.299 V13.4.0 (2016-03)
The 3GPP Charging Application uses the value 10415 (3GPP) as Vendor-Id.
Detailed descriptions of AVPs that are used specifically for 3GPP charging are provided in the subclauses below the
table. However, for AVPs that are just borrowed from other applications only the reference (e.g. TS 29.229 [204]), is
provided in the following table and the detailed description is not repeated.
Where 3GPP RADIUS VSAs are re-used, they shall be translated to Diameter AVPs as described in RFC 4005 [407]
with the exception that the 'M' flag shall be set and the 'P' flag may be set.
3GPP
Release 13 106 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 107 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 108 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 109 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 110 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 111 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 112 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 113 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 114 3GPP TS 32.299 V13.4.0 (2016-03)
Editor's note: The code of AVPs referred from TS 29.128 [244] in the above table need to be aligned with CT4
work.
Editor's note: The definition of Monitoring-Duration AVP in TS 29.336 [245] needs to be aligned with CT4 and
SA2 specifications.
When UE is accessing IMS via untrusted WLAN access, this AVP can also include the cell information (cell-ID) for the
most recent seen cell and additional information describing when the information about the cell-ID was collected.
[ Access-Transfer-Type ]
3GPP
Release 13 115 3GPP TS 32.299 V13.4.0 (2016-03)
* [ Access-Network-Information ]
[ Inter-UE-Transfer ]
[ User-Equipment-Info ]
[ Instance-Id ]
[ Related-IMS-Charging-Identifier ]
[ Related-IMS-Charging-Identifier-Node ]
[ Change-Time ]
0 PS to CS Transfer
1 CS to PS Transfer
2 PS to PS Transfer
3 CS to CS Transfer
{ Value-Digits }
[ Exponent ]
0 Yes
1 No
[ Type-Number ]
[ Additional-Type-Information ]
[ Content-Size ]
3GPP
Release 13 116 3GPP TS 32.299 V13.4.0 (2016-03)
[ Domain-Name ]
[ 3GPP-IMSI-MCC-MNC ]
0 e-mail address
1 MSISDN
2 IPv4 Address
3 IPv6 Address
4 Numeric Shortcode
5 Alphanumeric Shortcode
6 Other
7 IMSI
0 TO
1 CC
2 BCC
When several AF sessions (refer to TS 29.214 [214]) are conveyed over the same bearer, this AVP may appear several
times per MSCC instance.
3GPP
Release 13 117 3GPP TS 32.299 V13.4.0 (2016-03)
{ AF-Charging-Identifier }
* [ Flows ]
7.2.12aAAnnouncement-Identifier AVP
The Announcement-Identifier AVP (AVP code 3905) is of type Unsigned32. It contains a code identifying an
announcement to be played.
7.2.12aBAnnouncement-Information AVP
The Announcement-Information AVP (AVP code 3904) is of type Grouped and holds the Announcement service
parameters. Each Announcement-Information AVP specifies a single announcement to be played to the specified user.
The Announcement-Order AVP contains the order in which announcements should be connected for playback when
there are multiple Announcement-Information AVPs provided in a single message with the same timing indicator.
{ Announcement-Identifier }
* [ Variable-Part ]
[ Time-Indicator ]
[ Quota-Indicator ]
[ Announcement-Order ]
[ Play-Alternative ]
[ Privacy-Indicator ]
[ Language ]
[ Accumulated-Cost ]
3GPP
Release 13 118 3GPP TS 32.299 V13.4.0 (2016-03)
* [ Incremental-Cost ]
[ Currency-Code ]
0 MONETARY
1 NON_MONETARY
2 CAI
[ AoC-Cost-Information ]
[ Tariff-Information ]
[ AoC-Subscription-Information ]
0 AoC_NOT_REQUESTED
1 AoC_FULL
2 AoC_COST_ONLY
3 AoC_TARIFF_ONLY
[ AoC-Service-Obligatory-Type ]
[ AoC-Service-Type ]
0 NON_BINDING
1 BINDING
3GPP
Release 13 119 3GPP TS 32.299 V13.4.0 (2016-03)
0 NONE
1 AOC-S
2 AOC-D
3 AOC-E
* [ AoC-Service ]
[ AoC-Format ]
[ Preferred-AoC-Currency ]
[ Application-Server ]
* [ Application-Provided-Called-Party-Address ]
[ Status- AS-Code ]
3GPP
Release 13 120 3GPP TS 32.299 V13.4.0 (2016-03)
[ Bearer-Service ]
[ Teleservice ]
3GPP
Release 13 121 3GPP TS 32.299 V13.4.0 (2016-03)
The address is obtained from the P-Asserted-Identity SIP header field of the 2xx responses corresponding to a SIP
request either initiating a dialog or a standalone transaction. This field may appear several times in the request when the
P-Asserted-Identity contains both a SIP URI and a Tel URI.
This field shall be present when the P-Asserted-Identity SIP header field is available in the SIP 2xx response.
The address is obtained from the From SIP header field of a SIP UPDATE request or SIP RE-INVITE request.
[ Called-Identity ]
[ Change-Time ]
For a registration procedure, this field holds the party (Public User ID) to be registered. In this case, the Called Party
Address field is obtained from the "To" SIP header of the SIP Request. For a subscription procedure this field holds the
address of the resource for which the originator wants to receive notifications of change of states. In this case, the
Called Party Address field is obtained from the outgoing Request-URI of the SIP Request.
For VCS charging, it holds the address (SIP URI or Tel URI) which identifies the party to which a voice call is destined
after processing by the Proxy Function. It is converted from the circuit-switched Called Party Number as per TS
29.163 [234] for the Request-URI header. For a mobile originating call, this AVP contains the Called Party Number
after processing by the Proxy Function (e.g. number normalization). It is included only when different from the contents
of the Requested-Party-Address AVP.
For VCS charging, it holds the address (SIP URI or Tel URI) which identifies the party initiating a voice call. It is
converted from the circuit-switched Calling Party Number as per TS 29.163 [234] for the P-Asserted-Identity header.
3GPP
Release 13 122 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 123 3GPP TS 32.299 V13.4.0 (2016-03)
Within the cause codes, values 0 are reserved for successful causes while values 1 are used for failure causes. In
case of errors where the session has been terminated as a result of a specific known SIP error code, then the SIP error
code is also used as the cause code.
The cause "Normal end of session" is used in Accounting-request[stop] message to indicate that an
ongoing SIP session has been normally released either by the user or by the network (SIP BYE message
initiated by the user or initiated by the network has been received by the IMS node after the reception of
the SIP ACK message).
The cause "Successful transaction" is used in Accounting-request[Event] message to indicate a successful SIP
transaction (e.g. SIP REGISTER, SIP MESSAGE, SIP NOTIFY, SIP SUBSCRIBE when 200 Final Response). It may
also be used by an Application Server to indicate successful service event execution.
The cause "End of SUBSCRIBE dialog" is used to indicate the closure of a SIP SUBSCRIBE dialog . For
instance a successful SIP SUBSCRIBE transaction terminating the dialog has been detected by the IMS
node (i.e. SIP SUBSCRIBE with expire time set to 0).
The cause-code "2xx Final Response"(except 200) is used when the SIP transaction is terminated due to
an IMS node receiving/initiating a 2xx Final response as described in RFC 3261 [405].
The cause "3xx Redirection" is used when the SIP transaction is terminated due to an IMS node
receiving/initiating a 3xx response as described in RFC 3261 [405].
The cause "End of REGISTER dialog" is used to indicate the closure of a SIP REGISTER dialog. For
instance a successful SIP REGISTER transaction terminating the dialog has been detected by the IMS
node (i.e. SIP REGISTER with expire time set to 0).
1 Unspecified error
The cause "Unspecified error" is used when the SIP transaction is terminated due to an unknown error.
The cause "4xx Request failure" is used when the SIP transaction is terminated due to an IMS node
receiving/initiating a 4xx error response as described in RFC 3261 [405].
The cause "5xx Server failure" is used when the SIP transaction is terminated due to an IMS node
receiving/initiating a 5xx error response as described in RFC 3261 [405].
The cause "6xx Global failure" is used when the SIP transaction is terminated due to an IMS node
receiving/initiating a 6xx error response as described in RFC 3261 [405].
3GPP
Release 13 124 3GPP TS 32.299 V13.4.0 (2016-03)
The cause "Unsuccessful session setup" is used in the Accounting-request[stop] when the SIP session has
not been successfully established (i.e. Timer H expires and SIP ACK is not received or SIP BYE is
received after reception of the SIP 200 OK final response and SIP ACK is not received) as described in
TS 24.229 [202] and in RFC 3261 [405].
3 Internal error
The cause "Internal error" is used when the SIP transaction is terminated due to an IMS node internal
error (e.g. error in processing a request/response).
- Record closing.
0 Normal Release
The "Normal Release" value is used to indicate IP-CAN session termination , IP-CAN bearer release or Service
Data Flow Termination.
1 Abnormal Release
2 Qos Change
3 Volume Limit
4 Time Limit
5 Serving Node Change
6 Serving Node PLMN Change
7 User Location Change
8 RAT Change
9 UE TimeZone Change
10 Tariff Time Change
11 Service Idled Out
12 ServiceSpecificUnitLimit
13 Max Number of Changes in Charging conditions
14 CGI-SAI Change
15 RAI Change
16 ECGI Change
17 TAI Change
18 Service Data Volume Limit
19 Service Data Time Limit
20 Management Intervention
21 Service Stop
22 User CSG Information Change
23 S-GW Change
24 Change of UE Presence in Presence Reporting Area
25 Proximity alerted
26 Time expired with no renewal
27 Requestor cancellation
3GPP
Release 13 125 3GPP TS 32.299 V13.4.0 (2016-03)
In EPC Charging, it holds the time in UTC format when the volume counts associated to the IP-CAN bearer/TDF
session, or the service data container, is closed and reported due to charging condition change.
For MMTel Charging, it holds the time in UTC format and it is a time stamp that defines the moment when the
conference participant has an action (e.g. creating the conference, joining in the conference, being invited into the
conference and quiting the conference) triggering the Accounting Request message to CDF.
In ProSe Charging, it holds the time in UTC format when the volume counts associated to the ProSe group
communication container, is closed and reported due to ProSe charging condition change.
0 UNKNOWN
1 USAGE
2 COMMUNICATION-ATTEMPT-CHARGE
3 SETUP-CHARGE
4 ADD-ON-CHARGE
For Monitoring Event charging, it contains a string that identifies the entity towards which accounting/charging
functionality is performed by the involved 3GPP network elements.
0 Serving-Node-Supplied
1 Subscription-specific
2 APN-specific
3 Home-Default
4 Roaming-Default
5 Visiting-Default
0 Personal
1 Advertisement
2 Informational
3GPP
Release 13 126 3GPP TS 32.299 V13.4.0 (2016-03)
3 Auto
0 text
1 image-basic
2 image-rich
3 video-basic
4 video-rich
5 megapixel
6 content-basic
7 content-rich
7.2.46aACoverage-Status AVP
The Coverage-Status AVP (AVP code 3428) is of type Enumerated and indicates whether UE is served by E-UTRAN
or not. The following values are defined:
0 Out of coverage
3GPP
Release 13 127 3GPP TS 32.299 V13.4.0 (2016-03)
1 In coverage
[ Coverage-Status ]
[ Change-Time ]
* [ Location-Info ]
0 Closed mode
1 Hybrid Mode
3GPP
Release 13 128 3GPP TS 32.299 V13.4.0 (2016-03)
[ Currency-Code ]
[ Scale-Factor ]
* [ Rate-Element ]
0 No
1 Yes
[ Interface-Id ]
[ Interface-Text ]
[ Interface-Port ]
[ Interface-Type ]
3GPP
Release 13 129 3GPP TS 32.299 V13.4.0 (2016-03)
0 No
1 Yes
0 Static
1 Dynamic
0 Static
1 Dynamic
3GPP
Release 13 130 3GPP TS 32.299 V13.4.0 (2016-03)
[ SDP-TimeStamps ]
* [ SDP-Media-Component ]
* [ SDP-Session-Description ]
Media can be considered as inactive in range of situations, such as the listed below according to RFC 3264 [408]:
In contrast, media with directionality marked as "a=recvonly", "a=sendonly", "a=sendrecv" shall be considered in state
"active" and thus, it may be exchanged in one or both directions.
[ RAN-NAS-Release-Cause ]
NOTE: The RAN-NAS-Release-Cause AVP contains a set of different causes. It is under a grouped AVP to allow
extensions to other types of release causes in the future.
{ Envelope-Start-Time }
[ Envelope-End-Time ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
If an envelope has not been closed at the time of the usage report, then the Envelope-End-Time AVP shall be absent. If
an envelope was started before the reporting interval then the Envelope-Start-Time is nevertheless present and contains
the same time as previously reported, i.e. the actual time of the start of the envelope. The client shall include the volume
reports (the CC-xxxxx-Octets AVPs) or events (CC-Service-Specific-Units AVP) if these were requested in the
corresponding Envelope-Reporting AVP. The reported volume is always the volume from the beginning of the time
envelope.
3GPP
Release 13 131 3GPP TS 32.299 V13.4.0 (2016-03)
In circumstances, in which an envelope is retrospectively deemed to have been closed, e.g. with Quota-Consumption-
Time changes in a CCA, then the client shall include the Envelope AVP for the envelope in the next usage report.
Multiple occurrences of this AVP shall be in chronological order, i.e. the first envelope is listed first in CCR.
3GPP
Release 13 132 3GPP TS 32.299 V13.4.0 (2016-03)
0 DO_NOT_REPORT_ENVELOPES
1 REPORT_ENVELOPES
2 REPORT_ENVELOPES_WITH_VOLUME
3 REPORT_ENVELOPES_WITH_EVENTS
4 REPORT_ENVELOPES_WITH_VOLUME_AND_EVENTS
If this AVP is not included in the CCA[Initial] then the client shall not report the individual envelopes.
If this AVP is included within the Offline-Charging AVP, the value shall dictate the mechanism by which offline
charging information is generated.
[ SIP-Method ]
[ Event ]
[ Expires ]
3GPP
Release 13 133 3GPP TS 32.299 V13.4.0 (2016-03)
1 SUPPORTED
The MBMS user service does support point-to-point file repair.
2 NOT_SUPPORTED
The MBMS user service does not support point-to-point file repair.
7.2.67aAForwarding-Pending AVP
The Forwarding-Pending AVP (AVP code 3415) is of type Enumerated and indicates that a forwarded-to-number has
been received and the voice call will be forwarded. When it is not present, the voice call is not expected to be
forwarded. The values are:
{ Value-Digits }
[ Exponent ]
3GPP
Release 13 134 3GPP TS 32.299 V13.4.0 (2016-03)
0 Unknown
1 MOBILE_ORIGINATING
2 MOBILE_TERMINATING
3 APPLICATION_ORIGINATING
4 APPLICATION_TERMINATION
7.2.74aAInter-UE-Transfer AVP
The Inter-UE-Transfer AVP (AVP code 3902) is of type Enumerated and contains information about type of the
transfer. If this AVP is not present, this means that the type of transfer is Intra-UE transfer. The AVP can take the
following values:
0 Intra-UE transfer
1 Inter-UE transfer
Editor's Note: The SIP parameter from which the IMS Application Reference ID (IARI) is to be extracted requires
further investigation in CT1. A mechanism to identify the IARI in use is FFS.
0 Non Emergency
1 Emergency
3GPP
Release 13 135 3GPP TS 32.299 V13.4.0 (2016-03)
[ Event-Type ]
[ Role-Of-Node ]
{ Node-Functionality }
[ User-Session-Id ]
[ Outgoing-Session-Id ]
[ Session-Priority ]
* [ Calling-Party-Address ]
[ Called-Party-Address ]
* [ Called-Asserted-Identity ]
[ Called-Identity-Change ]
[ Number-Portability-Routing-Information ]
[ Carrier-Select-Routing-Information ]
[ Alternate-Charged-Party-Address ]
* [ Requested-Party-Address ]
* [ Associated-URI ]
[ Time-Stamps ]
* [ Application-Server-Information ]
* [ Inter-Operator-Identifier ]
* [ Transit-IOI-List ]
[ IMS-Charging-Identifier ]
* [ SDP-Session-Description ]
* [ SDP-Media-Component ]
[ Served-Party-IP-Address ]
[ Server-Capabilities ]
[ Trunk-Group-ID ]
[ Bearer-Service ]
[ Service-Id ]
* [ Service-Specific-Info ]
* [ Message-Body ]
[ Cause-Code ]
* [ Reason-Header ]
* [ Access-Network-Information ]
* [ Early-Media-Description ]
[ IMS-Communication-Service-Identifier ]
[ IMS-Application-Reference-Identifier ]
[ Online-Charging-Flag ]
[ Real-Time-Tariff-Information ]
[ Account-Expiration ]
[ Initial-IMS-Charging-Identifier ]
* [ NNI-Information ]
[ From-Address ]
[ IMS-Emergency-Indicator ]
[ IMS-Visited-Network-Identifier ]
* [ Access-Transfer-Information ]
[ Related-IMS-Charging-Identifier ]
[ Related-IMS-Charging-Identifier-Node ]
[ Route-Header-Received ]
[ Route-Header-Transmitted ]
[ Instance-Id ]
[TAD-Identifier]
3GPP
Release 13 136 3GPP TS 32.299 V13.4.0 (2016-03)
0 Authenticated
1 Unauthenticated
[ Originating-IOI ]
[ Terminating-IOI ]
[ ISUP-Cause-Location ]
[ ISUP-Cause-Value ]
[ ISUP-Cause-Diagnostics ]
3GPP
Release 13 137 3GPP TS 32.299 V13.4.0 (2016-03)
[ LCS-Client-Type ]
3GPP
Release 13 138 3GPP TS 32.299 V13.4.0 (2016-03)
[ LCS-Client-External-ID ]
[ LCS-Client-Dialed-By-MS ]
[ LCS-Client-Name ]
[ LCS-APN ]
[ LCS-Requestor-ID ]
3GPP
Release 13 139 3GPP TS 32.299 V13.4.0 (2016-03)
[ LCS-Data-Coding-Scheme ]
[ LCS-Name-String ]
[ LCS-Format-Indicator ]
0 EMERGENCY_SERVICES
1 VALUE_ADDED_SERVICES
2 PLMN_OPERATOR_SERVICES
3 LAWFUL_INTERCEPT_SERVICES
0 LOGICAL_NAME
1 EMAIL_ADDRESS
2 MSISDN
3 URL
4 SIP_URL
[ LCS-Client-ID ]
[ Location-Type ]
[ Location-Estimate ]
[ Positioning-Data ]
[ 3GPP-IMSI ]
[ MSISDN ]
3GPP
Release 13 140 3GPP TS 32.299 V13.4.0 (2016-03)
[ LCS-Data-Coding-Scheme ]
[ LCS-Requestor-ID-String ]
0 CURRENT_LOCATION
1 CURRENT_LAST_KNOWN_LOCATION
2 INITIAL_LOCATION
3 ACTIVATE_DEFERRED_LOCATION
4 CANCEL_DEFERRED_LOCATION
[ 3GPP-User-Location-Info ]
[ Change-Time ]
3GPP
Release 13 141 3GPP TS 32.299 V13.4.0 (2016-03)
[ Location-Estimate-Type ]
[ Deferred-Location-Event-Type ]
0 NOT-APPLICABLE
1 YES
0 NO
1 YES
0 Content Provider
1 Subscriber
[ TMGI ]
[ MBMS-Service-Type ]
[ MBMS-User-Service-Type ]
[ File-Repair-Supported ]
[ Required-MBMS-Bearer-Capabilities ]
[ MBMS-2G-3G-Indicator ]
[ RAI ]
* [ MBMS-Service-Area ]
[ MBMS-Session-Identity ]
3GPP
Release 13 142 3GPP TS 32.299 V13.4.0 (2016-03)
[ CN-IP-Multicast-Distribution ]
[ MBMS-GW-Address ]
[ MBMS-Charged-Party ]
* [ MSISDN ]
[ MBMS-Data-Transfer-Start ]
[ MBMS-Data-Transfer-Stop ]
1 DOWNLOAD
The MBMS user service of type: download.
2 STREAMING
The MBMS user service is of type: streaming.
3GPP
Release 13 143 3GPP TS 32.299 V13.4.0 (2016-03)
0 called party
1 calling party
2 unknown
{ Content-Type }
{ Content-Length }
[ Content-Disposition ]
[ Originator ]
The message bodies shall not include the bodies' of Content-Type = "application-sdp" as these are captured in other
AVPs.
[ Class-Identifier ]
[ Token-Text ]
3GPP
Release 13 144 3GPP TS 32.299 V13.4.0 (2016-03)
1 m-send-req
2 m-send-conf
3 m-notification-ind
4 m-notifyresp-ind
5 m-retrieve-conf
6 m-acknowledge-ind
7 m-delivery-ind
8 m-read-rec-ind
9 m-read-orig-ind
10 m-forward-req
11 m-forward-conf
12 m-mbox-store-conf
13 m-mbox-view-conf
14 m-mbox-upload-conf
15 m-mbox-delete-conf
[ Type-Number ]
[ Additional-Type-Information ]
[ Content-Size ]
* [ Additional-Content-Information ]
0 No
1 Yes
3GPP
Release 13 145 3GPP TS 32.299 V13.4.0 (2016-03)
[ Originator-Address ]
* [ Recipient-Address ]
[ Submission-Time ]
[ MM-Content-Type ]
[ Priority ]
[ Message-ID ]
[ Message-Type ]
[ Message-Size ]
[ Message-Class ]
[ Delivery-Report-Requested ]
[ Read-Reply-Report-Requested ]
[ MMBox-Storage-Requested ]
[ Applic-ID ]
[ Reply-Applic-ID ]
[ Aux-Applic-Info ]
[ Content-Class ]
[ DRM-Content ]
[ Adaptations ]
[ VASP-Id ]
[ VAS-Id ]
* [ Supplementary-Service ]
3GPP
Release 13 146 3GPP TS 32.299 V13.4.0 (2016-03)
Values 1024 are reserved for specific Network/Manufacturer supplementary services variants.
0 create
1 transfer
2 update
3 delete
0 Configuration
1 Reporting
[ Monitoring-Event-Functionality ]
[ Event-Timestamp ]
[ Monitoring-Event-Configuration-Activity ]
[ SCEF-Reference-ID ]
[ SCEF-ID ]
[ Monitoring-Type ]
[ Maximum-Number-of-Reports ]
[ Monitoring-Duration ]
[ Charged-Party ]
[ Maximum-Detection-Time]
[ UE-Reachability-Configuration ]
[ MONTE-Location-Type ]
[ Accuracy ]
* [ Number-Of-UE-Per-Location-Configuration ]
* [ Monitoring-Event-Report ]
3GPP
Release 13 147 3GPP TS 32.299 V13.4.0 (2016-03)
[ Event-Timestamp ]
[ SCEF-Reference-ID ]
[ SCEF-ID ]
[ Monitoring-Event-Report-Number ]
[ Charged-Party ]
[ Subscription-Id ]
[ Monitoring-Type ]
[ Reachability-Information ]
[ EPS-Location-Information ]
[ Communication-Failure-Information ]
* [ Number-Of-UE-Per-Location-Report ]
7.2.111BMSC-Address AVP
The MSC-Address AVP (AVP code 3417) is type OctetString and contains the international E.164 address of the MSC
that generated the network call reference number. It is encoded as a TBCD-string. See TS 29.002 [232] for encoding of
TBCD-strings. This AVP does not include leading indicators for the nature of address and the numbering plan; it
contains only the TBCD-encoded digits of the address.
3GPP
Release 13 148 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.111ENetwork-Call-Reference-Number AVP
The Network-Call-Reference-Number AVP (AVP code 3418) is type OctetString and contains the reference number
generated by the GMSC/MSC for the voice call service. When combined with the identity of the MSC that allocated it
can be used to unambiguously identify the call.
[ Currency-Code ]
[ Scale-Factor ]
* [ Rate-Element ]
7.2.112ANNI-Information AVP
The NNI-Information AVP (AVP code 2703) is of type Grouped and holds information about the NNI used for
interconnection and roaming.
[ Session-Direction ]
[ NNI-Type ]
[ Relationship-Mode ]
[ Neighbour-Node-Address ]
3GPP
Release 13 149 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.112BNNI-Type AVP
The NNI-Type AVP (AVP code 2704) is of type Enumerated and indicates whether the type of used NNI is non-
roaming, roaming without loopback routing or roaming with loopback routing. It has the following values:
0 non-roaming
1 roaming without loopback
2 roaming with loopback
0 S-CSCF
1 P-CSCF
2 I-CSCF
3 MRFC
4 MGCF
5 BGCF
6 AS
7 IBCF
8 S-GW
9 P-GW
10 HSGW
11 E-CSCF
12 MME
13 TRF
14 TF
15 ATCF
16 Proxy Function
17 ePDG
18 TDF
19 TWAG
3GPP
Release 13 150 3GPP TS 32.299 V13.4.0 (2016-03)
NOTE: The information to populate this field may be obtained from the TBCP-Talk-Burst-Grant message in PoC
case. The information to populate this field may be obtained from the Diameter Accounting Request
message in MMTel CONF Charging.
[ Quota-Consumption-Time ]
[ Time-Quota-Mechanism ]
[ Envelope-Reporting ]
* [ Multiple-Services-Credit-Control ]
* [ AVP ]
The Multiple-Services-Credit-Control AVPs, if present, shall contain the Rating-Group AVP to identify the category,
optionally one of Quota-Consumption-Time AVP and Time-Quota-Mechanism AVP, and optionally the Envelope-
Reporting AVP.
Any values specified in the Offline-Charging AVP take precedence over the configured defaults. The values of the
parameters specified at Multiple-Services-Credit-Control level take precedence over the values specified directly at
Offline-Charging level. If neither Quota-Consumption-Time AVP nor Time-Quota-Mechanism AVP is included in the
Multiple-Services-Credit-Control AVP, then the general reporting requirements dictated by the Quota-Consumption-
Time AVP or Time-Quota-Mechanism AVP and Envelope-Reporting AVP directly within the Offline-Charging AVP
shall apply.
3GPP
Release 13 151 3GPP TS 32.299 V13.4.0 (2016-03)
Type 1 IOI
- IOI of the visited network where the P-CSCF is located for SIP requests directed to the S-
CSCF when initiated by the served user
- IOI of the home network where the S-CSCF is located for SIP requests directed to the TRF in
the visited network when "VPLMN routing" is applied in a Roaming Architecture for Voice
over IMS with Local breakout.
- IOI of the home network where the S-CSCF is located for SIP requests directed to the visited
network P-CSCF when terminated at the served user..
Type 2 IOI
- IOI of the home network of the originating end user where the S-CSCF is located in case a
session is initiated from the IMS. In case of redirection by the S-CSCF, Originating-IOI AVP
indicates the terminating party's network operator from which the session is redirected.
- IOI of the visited network when "VPLMN routing" is applied in a Roaming Architecture for
Voice over IMS with Local breakout.
- IOI of the originating network where the MGCF is located in case a session is initiated from
the PSTN toward the IMS.
Type 3 IOI
- IOI of the home network (originating side or terminating side) where the S-CSCF is located
when forwarding a SIP request as described in TS 24.229 [202] to an AS (proxy, terminating
UA or redirect server or B2BUA).
- IOI of the service provider network where the AS is located when an AS (originating UA or
B2BUA) initiates a SIP request as described in TS 24.229 [202].
For further details on the Type 1, Type 2 and Type 3 IOIs, please refer to TS 32.240 [1].
0 Calling Party
1 Called Party
[ Address-Type ]
[ Address-Data ]
[ Address-Domain ]
3GPP
Release 13 152 3GPP TS 32.299 V13.4.0 (2016-03)
[ Interface-Id ]
[ Interface-Text ]
[ Interface-Port ]
[ Interface-Type ]
[ Address-Type ]
[ Address-Data ]
[ Address-Domain ]
7.2.128 Originator-SCCP-Address
The Originator-SCCP-Address AVP (AVP code 2008) is of type Address. It is the "SCCP calling address" used by the
messaging node when receiving a message. This is usually the address of the MSC or SGSN/Serving Node that was
serving the UE when it submitted the message. It contains either a Point Code (ISPC) or a Global Title, where Global
Title represents an E.164 number. The Address Type discriminator in RFC 3588 [401] is set to value 8, E.164, and the
address information is UTF8 encoded.
7.2.128AOutgoing-Session-Id AVP
The Outgoing-Session-Id AVP (AVP code 2320) is of type UTF8String and holds the outgoing session identifier for an
AS acting as B2BUA. For a SIP session the Outgoing-Session-Id AVP contains the SIP Call ID of the outgoing leg, as
defined in RFC 3261 [405].
3GPP
Release 13 153 3GPP TS 32.299 V13.4.0 (2016-03)
[ Called-Party-Address ]
[ Participant-Access-Priority ]
[ User-Participating-Type ]
1 Pre-emptive priority:
The highest level priority. A request with pre-emptive priority SHALL cause the current other requests to
be revoked immediately, unless they are also with pre-emptive priority
2 High priority: Lower than Pre-emptive priority
3 Normal priority: Normal level. Lower than High priority
4 Low priority: Lowest level priority
0 CREATE_CONF
1 JOIN_CONF
2 INVITE_INTO_CONF
3 QUIT_CONF
7.2.134 Void
7.2.135 Void
7.2.135APC3-Control-Protocol-Cause AVP
The PC3-Control-Protocol-Cause AVP (AVP code 3434) is of type Integer32 and holds the particular reason why a
DISCOVERY_REQUEST or MATCH_REPORT messages from the UE have been rejected by the ProSe Function. It is
referred to as "PC3 Control Protocol cause value” in TS 24.334 [236].
7.2.135BPC3-EPC-Control-Protocol-Cause AVP
The PC3-EPC-Control-Protocol-Cause AVP (AVP code 3435) is of type Integer32 and holds the particular reason why
a proximity request messages from the UE have been rejected by the ProSe Function. It is referred to as "PC3 EPC
Control Protocol cause value” in TS 24.334 [236].
3GPP
Release 13 154 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.137APDP-Address-Prefix-Length AVP
The PDP-Address-Prefix-Length AVP (AVP code 2606) is of type Unsigned32 and contains the prefix length of an
IPv6 typed PDP-Address AVP. The omission of this AVP for an IPv6 typed IP address implicitly means prefix length
of 64 bits, as in this case the 64 bit prefix length default shall be assumed.
0 Primary
1 Secondary
7.2.138APlay-Alternative AVP
The Play-Alternative AVP (AVP code 3913) is of type Enumerated and indicates the call party toward whom an
announcement is directed.
It has the following values:
0 served party
1 remote party
0 ServiceChange
1 VolumeLimit
2 TimeLimit
3 NumberofTalkBurstLimit
4 NumberofActiveParticipants
5 TariffTime
3GPP
Release 13 155 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 156 3GPP TS 32.299 V13.4.0 (2016-03)
0 Normal;
1 Instant Ppersonal Aalert event;
2 PoC Group Advertisement event;
3 Early Ssession Setting-up event;
4 PoC Talk Burst
[ PoC-Server-Role ]
[ PoC-Session-Type ]
[ PoC-User-Role ]
[ PoC-Session-Initiation-type ]
[ PoC-Event-Type ]
[ Number-Of-Participants ]
* [ Participants-Involved ]
* [ Participant-Group ]
* [ Talk-Burst-Exchange ]
[ PoC-Controlling-Address ]
[ PoC-Group-Name ]
[ PoC-Session-Id ]
[ Charged-Party ]
NOTE: In the ABNF definition of PoC-Information AVP, the Participants-Involved AVP is kept only for
backward compatibility with Releases before the 3GPP Release 7.
NOTE: The PoC-Session-Id may not be available in the initial charging interactions for the PoC session.
3GPP
Release 13 157 3GPP TS 32.299 V13.4.0 (2016-03)
0 Pre-established
1 On-demand
0 1 to 1 PoC session
1 Chat PoC group session
2 Pre-arranged PoC group session
3 Ad-hoc PoC group session
[ PoC-User-Role-Ids ]
[ PoC-User-Role-info-Units ]
1 Moderator
2 Dispatcher
3 Session-Owner
4 Session-Participant
3GPP
Release 13 158 3GPP TS 32.299 V13.4.0 (2016-03)
0 Low
1 Normal
2 High
0 NOT_PRIVATE
1 PRIVATE
7.2.154AProSe-3rd-Party-Application-ID AVP
The ProSe-3rd-Party-Application-ID AVP (AVP code 3440) is of type UTF8String and carry A globally unique
identifier identifying a specific 3rd party application, as upper layer of ProSe. It is referred to as "Applicatoin Identity”
in TS 24.334 [236].
[ Local-Sequence-Number ]
[ Coverage-Status ]
[ 3GPP-User-Location-Info ]
[ Accounting-Input-Octets ]
[ Change-Time ]
[ Change-Condition ]
[ Visited-PLMN-Id ]
[ Usage-Information-Report-Sequence-Number ]
[ Radio-Resources-Indicator]
[ Radio-Frequency ]
7.2.154BProSe-Direct-Communication-Transmission-Data-Container AVP
The ProSe-Direct-Communication- Transmission-Data-Container AVP (AVP code 3441) is of type Grouped. Its
purpose is to allow the transmission of the container to be reported for ProSe Charging. On encountering change on
ProSe charging condition, this container identifies the volume count for transmitting within a ProSe group
communication.
[ Local-Sequence-Number ]
[ Coverage-status ]
[ 3GPP-User-Location-Info ]
[ Accounting-Output-Octets ]
3GPP
Release 13 159 3GPP TS 32.299 V13.4.0 (2016-03)
[ Change-Time ]
[ Change-Condition ]
[ Visited-PLMN-Id ]
[ Usage-Information-Report-Sequence-Number ]
[ Radio-Resources-Indicator ]
[ Radio-Frequency ]
0 Model A
1 Model B
0 Annoucing
1 Monitoring
2 Match Report
7.2.154EProSe-Function-IP-Address AVP
The ProSe-Function-IP-Address AVP (AVP code 3444) is of type Address and holds the IP-address of the ProSe
Function.
0 Direct discovery
1 EPC-level discovery
2 Direct communication
3GPP
Release 13 160 3GPP TS 32.299 V13.4.0 (2016-03)
[ Announcing-UE-HPLMN-Identifier ]
[ Announcing-UE-VPLMN-Identifier ]
[ Monitoring-UE-HPLMN-Identifier ]
[ Monitoring-UE-VPLMN-Identifier ]
[ Monitored-HPLMN-Identifier ]
[ Role-Of-ProSe-Function ]
[ ProSe-App-Id ]
[ ProSe-3rd-Party-Application-ID ]
[ Application-Specific-Data ]
[ ProSe-Event-Type ]
[ ProSe-Direct-Discovery-Model ]
[ ProSe-Function-IP-Address ]
[ ProSe-Function-ID ]
[ ProSe-Validity-Timer ]
[ ProSe-Role-Of-UE ]
[ ProSe-Request-Timestamp ]
[ PC3-Control-Protocol-Cause ]
[ Monitoring-UE-Identifier ]
[ Prose-Function-PLMN-Identifier ]
[ Requestor-PLMN-Identifier ]
[ Origin-App-Layer-User-Id ]
[ WLAN-Link-Layer-Id ]
[ Requesting-EPUID ]
[ Target-App-Layer-User-Id ]
[ Requested-PLMN-Identifier ]
[ Time-Window ]
[ ProSe-Range-Class ]
[ Proximity-Alert-Indication ]
[ Proximity-Alert-Timestamp ]
[ Proximity-Cancellation-Timestamp ]
[ ProSe-Reason-For-Cancellation ]
[ PC3-EPC-Control-Protocol-Cause ]
[ ProSe-UE-ID ]
[ ProSe-Source-IP-Address ]
[ Layer-2-Group-ID ]
[ ProSe-Group-IP-Multicast-Address ]
* [ Coverage-Info ]
* [ Radio-Parameter-Set-Info ]
* [ Transmitter-Info ]
[ Time-First-Transmission ]
[ Time-First-Reception ]
* [ ProSe-Direct-Communication-Transmission-Data-Container ]
* [ ProSe-Direct-Communication-Reception-Data-Container ]
0 Reserved
1 50 m
2 100 m
3 200 m
4 500 m
5 1000 m
3GPP
Release 13 161 3GPP TS 32.299 V13.4.0 (2016-03)
6-255 Unused
7.2.154KProSe-Reason-For-Cancellation AVP
The ProSe-Reason-For-Cancellation AVP (AVP code 3449) is of type Enumerated and indicates the reason for
cancellation of an EPC-level discovery request. The AVP may take the values as follows:
2 Requestor cancellation
0 Announcing UE
1 Monitoring UE
2 Requestor UE
3 Requested UE
7.2.154PProximity-Alert-Indication AVP
The Proximity-Alert-Indication AVP (AVP code 3454) is of type Enumerated and indicates whether proximity alert has
been sent before proximity request cancellation. The AVP may take the values as follows:
0 Alert
1 No Alert
3GPP
Release 13 162 3GPP TS 32.299 V13.4.0 (2016-03)
0 'Append'
If this AVP is present and indicates 'Append', the P-GW shall append the received PS free format data to the PS
free format data stored for the online charging session.
1 'Overwrite'
If this AVP is absent or in value 'Overwrite', the P-GW shall overwrite all PS free format data already stored for
the online charging session.
The P-GW shall ignore this AVP if no PS free format data is stored for the online charging session.
{ 3GPP-Charging-Id }
{ PS-Free-Format-Data }
[ PS-Append-Free-Format-Data ]
[ 3GPP-Charging-Id ]
[ PDN-Connection-Charging-ID ]
[ Node-Id ]
[ 3GPP-PDP-Type ]
* [ PDP-Address ]
[ PDP-Address-Prefix-Length ]
[ Dynamic-Address-Flag ]
[ Dynamic-Address-Flag-Extension ]
[ QoS-Information ]
* [ SGSN-Address ]
* [ GGSN-Address ]
* [ TDF-IP-Address ]
* [ SGW-Address ]
* [ ePDG-Address ]
* [ TWAG-Address ]
[ CG-Address ]
3GPP
Release 13 163 3GPP TS 32.299 V13.4.0 (2016-03)
[ Serving-Node-Type ]
[ SGW-Change ]
[ 3GPP-IMSI-MCC-MNC ]
[ IMSI-Unauthenticated-Flag ]
[ 3GPP-GGSN-MCC-MNC ]
[ 3GPP-NSAPI ]
[ Called-Station-Id ]
[ 3GPP-Session-Stop-Indicator ]
[ 3GPP-Selection-Mode ]
[ 3GPP-Charging-Characteristics ]
[ Charging-Characteristics-Selection-Mode ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-MS-TimeZone ]
[ Charging-Rule-Base-Name ]
[ ADC-Rule-Base-Name ]
[ 3GPP-User-Location-Info ]
[ User-Location-Info-Time ]
[ User-CSG-Information ]
[ Presence-Reporting-Area-Information ]
[ 3GPP2-BSID ]
[ TWAN-User-Location-Info ]
[ UWAN-User-Location-Info ]
[ 3GPP-RAT-Type ]
[ PS-Furnish-Charging-Information ]
[ PDP-Context-Type ]
[ Offline-Charging ]
* [ Traffic-Data-Volumes ]
* [ Service-Data-Container ]
[ User-Equipment-Info ]
[ Terminal-Information ]
[ Start-Time ]
[ Stop-Time ]
[ Change-Condition ]
[ Diagnostics ]
[ Low-Priority-Indicator ]
[ NBIFOM-Mode ]
[ NBIFOM-Support ]
[ MME-Number-for-MT-SMS ]
[ MME-Name ]
[ MME-Realm ]
[ Logical-Access-ID ]
[ Physical-Access-ID ]
[ Fixed-User-Location-Info ]
[ CN-Operator-Selection-Entity ]
[ Enhanced-Diagnostics ]
3GPP
Release 13 164 3GPP TS 32.299 V13.4.0 (2016-03)
This optional AVP may only occur in a CCA command. It is contained in the Multiple-Services-Credit-Control AVP.
It applies equally to the granted time quota and to the granted volume quota.
A Quota-Holding-Time value of zero indicates that this mechanism shall not be used. If the Quota-Holding-Time AVP
is not present, then a locally configurable default value in the client shall be used.
0 QUOTA_IS_NOT_USED_DURING_PLAYBACK
1 QUOTA_IS_USED_DURING_PLAYBACK
7.2.160ARadio-Frequency AVP
The Radio-Frequency AVP (AVP code 3462) is of type OctetString and identifies the radio frequency used for ProSe
direct communication. The format of the value is according to the ARFCN-ValueEUTRA-r9 ASN.1 data type described
in TS 36.331 [241].
7.2.160BRadio-Parameter-Set-Info AVP
The Radio-Parameter-Set-Info AVP (AVP code 3463) is of type Grouped and provides information on a radio
parameter set configured in the UE for direct communication use. Each set has an associated time stamp of when it
became active.
[ Radio-Parameter-Set-Values ]
[ Change-Time ]
1 Operator-provided
2 Configured
Example: CC-Unit-Type AVP TIME, Unit-Value AVP 6 and Unit-Cost AVP 10 with Exponent AVP 2 should read:
10 cents per 6 seconds time. The currency is context dependent.
3GPP
Release 13 165 3GPP TS 32.299 V13.4.0 (2016-03)
{ CC-Unit-Type }
[ Charge- Reason-Code ]
[ Unit-Value ]
[ Unit-Cost ]
[ Unit-Quota-Threshold ]
0 No
1 Yes
7.2.163 Void
3GPP
Release 13 166 3GPP TS 32.299 V13.4.0 (2016-03)
[ Tariff-Information ]
[ Tariff-XML ]
7.2.164AReason-Header AVP
The Reason-Header AVP (AVP code 3401) is of type UTF8String and contains the content of the Reason-header in the
SIP BYE and CANCEL. It may contain multiple entries if there are multiple Reason headers within a SIP BYE or
CANCEL.
[ Address-Type ]
[ Address-Data ]
[ Address-Domain ]
[ Addressee-Type ]
3GPP
Release 13 167 3GPP TS 32.299 V13.4.0 (2016-03)
[ Destination-Interface ]
* [ Recipient-Address ]
* [ Recipient-Received-Address ]
[ Recipient-SCCP-Address ]
[ SM-Protocol-ID ]
NOTE 1: This Recipient-Info AVP allows charging for messages with multiple recipients by repeating this AVP for
every recipient. The Recipient-Info AVP unambigiously associates the grouped information to one
specific recipient.
NOTE 2: The SM-Protocol-ID AVP only relates to the recipient when charging MT SMS messages as specified in
TS 23.040 [216].
[ Address-Type ]
[ Address-Data ]
[ Address-Domain ]
7.2.170 Recipient-SCCP-Address
The Recipient-SCCP-Address AVP (AVP code 2010) is of type Address. It is the "SCCP called address" used by the
messaging node when delivering the message. This is usually the address of the MSC or SGSN/Serving Node that is
serving the UE when it delivers the message. It contains a Global Title, where Global Title represents an E.164 number,
and possibly a Point Code (ISPC). The AddressType discriminator in RFC 3588 [401] is set to value 8, E.164, and the
address information is UTF8 encoded.
7.2.171ARelationship-Mode AVP
The Relationship-Mode AVP (AVP code 2706) is of type Enumerated and indicates whether the other functional entity
(e.g. contact point of the neighbouring network) is regarded as part of the same trust domain. It has the following
values:
0 trusted
1 non-trusted
3GPP
Release 13 168 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.171BRelated-IMS-Charging-Identifier AVP
The Related-IMS-Charging-Identifier AVP (AVP code 2711) is of type UTF8String and holds the Related IMS
Charging Identifier (ICID) as generated by the Enhanced MSC Server or the P-CSCF for the target access leg of an
SRVCC access transfer.
{ Unit-Value }
{ Currency-Code }
3GPP
Release 13 169 3GPP TS 32.299 V13.4.0 (2016-03)
0 THRESHOLD
This value is used to indicate that the reason for usage reporting of the particular quota type indicated in the
Used-Service-Units AVP where it appears is that the threshold has been reached.
1 QHT
This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-Service-
Credit-Control AVP where its appears is that the quota holding time specified in a previous CCA command has
been hit (i.e. the quota has been unused for that period of time).
2 FINAL
This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-Service-
Credit-Control AVP where its appears is that a service termination has happened, e.g. PDP context, IP CAN
bearer termination or service data flow termination.
3 QUOTA_EXHAUSTED
This value is used to indicate that the reason for usage reporting of the particular quota type indicated in the
Used-Service-Units AVP where it appears is that the quota has been exhausted.
4 VALIDITY_TIME
This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-Service-
Credit-Control AVP where its appears is that the credit authorization lifetime provided in the Validity-Time
AVP has expired.
5 OTHER_QUOTA_TYPE
This value is used to indicate that the reason for usage reporting of the particular quota type indicated in the
Used-Service-Units AVP where it appears is that, for a multi-dimensional quota, one reached a trigger condition
and the other quota is being reported.
6 RATING_CONDITION_CHANGE
This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-Service-
Credit-Control AVP where its appears is that a change has happened in some of the rating conditions that were
previously armed (through the Trigger AVP, e.g. QoS, Radio Access Technology,…). The specific conditions
that have changed are indicated in an associated Trigger AVP.
7 FORCED_REAUTHORISATION
This value is used to indicate that the reason for usage reporting of all quota types of the Multiple-Service-
Credit-Control AVP where its appears is that it is there has been a Server initiated re-authorization procedure,
i.e. receipt of RAR command
8 POOL_EXHAUSTED
This value is used to indicate that the reason for usage reporting of the particular quota type indicated in the
Used-Service-Units AVP where it appears is that granted units are still available in the pool but are not sufficient
for a rating group using the pool.
When the value RATING_CONDITION_CHANGE is used, the Trigger AVP shall also be included to indicate the
specific events which caused the re-authorization request.
3GPP
Release 13 170 3GPP TS 32.299 V13.4.0 (2016-03)
For VCS charging, it holds the address (SIP URI or Tel URI) which identifies the party to which a voice call is destined
before processing by the Proxy Function. It is converted from the circuit-switched Called Party BCD Number as per TS
29.163 [234] for the Request-URI header. This is included only for a mobile originating call.
7.2.176ARequested-PLMN-Identifier AVP
The Requested-PLMN-Identifier AVP (AVP code 3436) is of type UTF8String and contains PLMN identifier of the
user who is targeted in proximity request.
7.2.176BRequestor-PLMN-Identifier AVP
The Requestor-PLMN-Identifier AVP (AVP code 3437) is of type UTF8String and contains PLMN identifier of the
user who initiate proximity request.
0 ORIGINATING_ROLE
The node is applying an originating role, serving the calling party.
1 TERMINATING_ROLE
The node is applying a terminating role, serving the called party.
2 FORWARDING_ROLE
The node is applying a originating role, serving the forwarding party.
0 HPLMN
1 VPLMN
2 Local PLMN
7.2.177ARoute-Header-Received AVP
The Route-Header-Received AVP (AVP code 3403) is of type UTF8String and includes the information in the topmost
route header in a received initial SIP INVITE or non-session related SIP MESSAGE request.
7.2.177BRoute-Header-Transmitted AVP
The Route-Header-Transmitted AVP (AVP code 3404) is of type UTF8String and includes the information in the route
header representing the destination in a transmitted initial SIP INVITE or non-session related SIP MESSAGE request.
3GPP
Release 13 171 3GPP TS 32.299 V13.4.0 (2016-03)
{ Value-Digits }
[ Exponent ]
[ SDP-Media-Name ]
* [ SDP-Media-Description ]
[ Local-GW-Inserted-Indication ]
[ IP-Realm-Default-Indication ]
[ Transcoder-Inserted-Indication ]
[ Media-Initiator-Flag ]
[ Media-Initiator-Party ]
[ 3GPP-Charging-Id ]
[ Access-Network-Charging-Identifier-Value ]
[ SDP-Type ]
NOTE: When populating the SDP-Media-Component, either the 3GPP-Charging-ID or the Access-Network-
Charging-Identifier-Value should be present but not both. The 3GPP-Charging-ID is expected to be used
for 3GPP defined IP-CANS (e.g. GPRS) while the Access-Network-Charging-Identifier-Value is used for
non-3GPP defined IP-CANs.
3GPP
Release 13 172 3GPP TS 32.299 V13.4.0 (2016-03)
[ SDP-Offer-Timestamp ]
[ SDP-Answer-Timestamp ]
0 SDP Offer
1 SDP Answer
7.2.186ASession-Direction AVP
The Session-Direction AVP (AVP code 2707) is of type Enumerated and indicates whether the NNI is used for an
inbound or outbound service request on the control plane in case of interconnection and roaming.
It has the following values:
0 inbound
1 outbound
7.2.188 Void
[ AF-Correlation-Information ]
[ Charging-Rule-Base-Name ]
[ Accounting-Input-Octets ]
[ Accounting-Output-Octets ]
[ Local-Sequence-Number ]
[ QoS-Information ]
[ Rating-Group ]
[ Change-Time ]
[ Service-Identifier ]
[ Service-Specific-Info ]
3GPP
Release 13 173 3GPP TS 32.299 V13.4.0 (2016-03)
[ ADC-Rule-Base-Name ]
[ SGSN-Address ]
[ Time-First-Usage ]
[ Time-Last-Usage ]
[ Time-Usage ]
*[ Change-Condition]
[ 3GPP-User-Location-Info ]
[ 3GPP2-BSID ]
[ UWAN-User-Location-Info ]
[ Sponsor-Identity ]
[ Application-Service-Provider-Identity ]
[ Presence-Reporting-Area-Status ]
[ User-CSG-Information ]
[ 3GPP-RAT-Type ]
[ Access-Availability-Change-Reason ]
* [ Subscription-Id ]
[ AoC-Information ]
[ PS-Information ]
[ IMS-Information ]
[ MMS-Information ]
[ LCS-Information ]
[ PoC-Information ]
[ MBMS-Information ]
[ SMS-Information ]
[ VCS-Information ]
[ MMTel-Information ]
[ ProSe-Information ]
[ Service-Generic-Information ]
[ IM-Information ]
[ DCD-Information ]
[ M2M-Information ]
The format and the contents of the fields inside the Service-Information AVP are specified in the middle-tier documents
which are applicable for the specific service. Note that the formats of the fields are service-specific, i.e. the format will
be different for the various services.
3GPP
Release 13 174 3GPP TS 32.299 V13.4.0 (2016-03)
Further fields may be included in the Service-Information AVP when new services are introduced.
3GPP
Release 13 175 3GPP TS 32.299 V13.4.0 (2016-03)
[ Service-Specific-Data ]
[ Service-Specific-Type ]
7.2.197 Void
3GPP
Release 13 176 3GPP TS 32.299 V13.4.0 (2016-03)
0 SGSN
1 PMIPSGW
2 GTPSGW
3 ePDG
4 hSGW
5 MME
6 TWAN
7.2.199ASGW-Address AVP
The SGW-Address AVP (AVP code 2067) is of type Address and holds the IP-address of the SGW Node.
0 ACR_Start_NOT_due_to_SGW_Change
1 ACR_Start_due_to_SGW_Change
3GPP
Release 13 177 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.205ASM-Device-Trigger-Indicator AVP
The SM-Device-Trigger-Indicator AVP (AVP code 3407) is of type Enumerated, and indicates whether the Short
Message is related to Device Trigger. If this AVP is not present, this means the Short Message is not related to Device
Trigger:
0 Not DeviceTrigger
1 Device Trigger
7.2.205BSM-Device-Trigger-Information AVP
The SM-Device-Trigger-Information AVP (AVP code 3405) is of type Grouped and holds the specific device trigger
details for the Short Message.
[ MTC-IWF-Address ]
[ Reference-Number ]
[ Serving-Node ]
[ Validity-Time ]
[ Priority-Indication ]
[ Application-Port-Identifier ]
For example, if SM-Status has the value 0x00, then the SM-Discharge-Time indicates the time of the delivery of the
original Short Message.
The SMS Node shall ensure the correct encoding of this, as the other AVPs using the type Time, since the SMS
messages use different formats.
0 SUBMISSION
1 DELIVERY_REPORT
2. SM Service Request
3GPP
Release 13 178 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.208ASM-Sequence-Number AVP
The SM-Sequence-Number AVP (AVP code 3408) is of type Unsigned32 and includes the sequence number of the SM
within the concatenated short message when applicable for SMS Offline Charging.
[ SMS-Node ]
[ Client-Address ]
[ Originator-SCCP-Address ]
[ SMSC-Address ]
[ Data-Coding-Scheme ]
[ SM-Discharge-Time ]
[ SM-Message-Type ]
[ Originator-Interface ]
[ SM-Protocol-ID ]
[ Reply-Path-Requested ]
[ SM-Status ]
[ SM-User-Data-Header ]
[ Number-Of-Messages-Sent ]
[ SM-Sequence-Number ]
* [ Recipient-Info ]
[ Originator-Received-Address ]
[ SM-Service-Type ]
[ SMS-Result ]
[ SM-Device-Trigger-Indicator ]
[ SM-Device-Trigger-Information ]
0 SMS Router
1 IP-SM-GW
2 SMS Router and IP-SM-GW
3 SMS-SC
3GPP
Release 13 179 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.212ASMS-Result AVP
The SMS-Result AVP (AVP code 3409) is of type Unsigned32 and includes the result of an attempt for a Short Message
transaction (submission or delivery).
3GPP
Release 13 180 3GPP TS 32.299 V13.4.0 (2016-03)
The SM-Service-Type AVP shall be present if the SM-Message-Type AVP has value 2, SM Service Request.
7.2.214AStart-of-Charging AVP
The Start-of-Charging AVP (AVP Code 3419) is of type Time and holds the time in UTC format which represents the
time origin for charging and may be equivalent to the time call setup is initiated or the time the call is answered
depending on configuration.
7.2.215AStatus-AS-Code AVP
The Status-AS-Code AVP (AVP Code 2702) is of type Enumerated and only present to specify abnormal response
code, e.g, 4xx, 5xx or Timeout, etc for specific AS when it responds abnormally to S-CSCF.
If AS responds SIP 200 OK, this AVP isn't present in Application-Server-Information AVP.
The AVP may take the values as follows:
0 4xx;
1 5xx;
2 Timeout
3GPP
Release 13 181 3GPP TS 32.299 V13.4.0 (2016-03)
0 Originating
1 Terminating
[ MMTel-SService-Type ]
[ Service-Mode ]
[ Number-Of-Diversions ]
[ Associated-Party-Address ]
[ Service-ID ]
[ Change-Time ]
[ Number-Of-Participants ]
[ Participant-Action-Type ]
[ CUG-Information ]
[ AoC-Information ]
7.2.219ATAD-Identifier AVP
The TAD-Identifier AVP (AVP code 2717) is of type Enumerated and indicates the type of access network (CS or PS)
through which the session shall be terminated. It can be one of the following values:
0 CS
1 PS
{ PoC-Change-Time }
[ Number-Of-Talk-Bursts ]
[ Talk-Burst-Volume ]
[ Talk-Burst-Time ]
[ Number-Of-Received-Talk-Bursts ]
[ Received-Talk-Burst-Volume ]
[ Received-Talk-Burst-Time ]
3GPP
Release 13 182 3GPP TS 32.299 V13.4.0 (2016-03)
[ Number-Of-Participants ]
[ PoC-Change-Condition ]
{ Current-Tariff }
[ Tariff-Time-Change ]
[ Next-Tariff ]
7.2.224ATeleservice AVP
The Teleservice AVP (AVP code 3413) is of type OctetString and holds the used teleservice for the voice call service.
Type 1 IOI
- IOI of the home network where the S-CSCF is located for SIP responses directed to
the P-CSCF in the visited network when request was initiated by the served user
- IOI of the visited network where the TRF is located for SIP responses directed to
the S-CSCF in the home network when request was initiated by the served user and "VPLMN routing" is applied
in a Roaming Architecture for Voice over IMS with Local breakout.
- IOI of the visited network where the P-CSCF is located for SIP responses directed to
the S-CSCF in the home network when request was terminated at the served user.
Type 2 IOI
- IOI of the home network of the terminating end user where the S-CSCF is located in case a
session is initiated toward the IMS. In case of redirection by the S-CSCF, Terminating-IOI AVP indicates the
terminating party's network operator to which the session is redirected.
3GPP
Release 13 183 3GPP TS 32.299 V13.4.0 (2016-03)
- IOI of the terminating network where the MGCF is located in case a session is initiated from the IMS toward
the PSTN.
Type 3 IOI
- IOI of the service provider network (originating side or terminating side) where the AS (proxy, terminating
UA or redirect server or B2BUA) is located when receiving a SIP request as described in TS 24.229 [202].
- IOI of the home network operator contacted by an AS when an AS (originating UA or B2BUA) initiates a
SIP request as described in TS 24.229 [202].
For further details on the Type 1, Type 2 and Type 3 IOIs, please refer to TS 32.240 [1].
7.2.225ATime-First-Reception AVP
The Time-First-Reception AVP (AVP code 3456) is of type Time and holds the time in UTC format for the first IP
packet received.
7.2.225BTime-First-Transmission AVP
The Time-First-Transmission AVP (AVP code 3467) is of type Time and holds the time in UTC format for the first IP
packet transmitted.
7.2.226ATime-Indicator AVP
The Time-Indicator AVP (AVP code 3911) is of type Unsigned32 and instructs the announcement to be connected at
the specified time before granted quota is exhausted, which ranges from zero to a value smaller than the granted quota.
A value of zero means at the time quota is exhausted. Absence of this field indicates that the announcement is to be
played before the IMS session is allowed to continue.
7.2.228 Time-Quota-Mechanism
The Time-Quota-Mechanism AVP (AVP code 1270) is of type Grouped.
{ Time-Quota-Type }
{ Base-Time-Interval }
The OCS may include this AVP in a Multiple-Services-Credit-Control AVP, when granting time quota.
3GPP
Release 13 184 3GPP TS 32.299 V13.4.0 (2016-03)
If received, the Credit-Control client shall seek re-authorization from the server for the quota when the quota contents
fall below the supplied threshold. The client shall allow service to continue whilst the re-authorization is progress, until
the time at which the original quota would have been consumed.
0 DISCRETE_TIME_PERIOD
1 CONTINUOUS_TIME_PERIOD
[ SIP-Request-Timestamp ]
[ SIP-Response-Timestamp ]
[ SIP-Request-Timestamp-Fraction ]
[ SIP-Response-Timestamp-Fraction ]
[ QoS-Information ]
[ Accounting-Input-Octets ]
[ Accounting-Output-Octets ]
[ Change-condition ]
[ Change-Time ]
[ 3GPP-User-Location-Info ]
[ UWAN-User-Location-Info ]
[ 3GPP-Charging-Id ]
[ Presence-Reporting-Area-Status ]
[ User-CSG-Information ]
[ 3GPP-RAT-Type ]
[ Access-Availability-Change-Reason ]
[ Diagnostics ]
[ Enhanced-Diagnostics ]
3GPP
Release 13 185 3GPP TS 32.299 V13.4.0 (2016-03)
7.2.233ATranscoder-Inserted-Indication AVP
The Transcoder-Inserted-Indication AVP (AVP code 2605) is of type Enumerated and indicates if a transcoder is
inserted or not for the SDP media component. The following values are defined:
7.2.233BTransit-IOI-List AVP
The Transit-IOI-List AVP (AVP code 2701) is of type UTF8String and holds the Inter Operator Identifiers (IOI) for the
transit networks as generated by the IMS Network Elements which take responsibility for populating this parameter in a
SIP request and response as described in RFC 7315 [404] and TS 24.229 [202]. Multiple occurrences of this AVP shall
be in chronological order, i.e. the value in the SIP request is listed first. If only a value for the SIP response is available,
the Transit-IOI-List for the SIP request shall be included with the value "unknown".
[ ProSe-Source-IP-Address ]
[ ProSe-UE-ID ]
* [ Trigger-Type ]
When included in the CCA command, the Trigger-Type AVP indicates the events that shall cause the Credit-Control
client to re-authorize the associated quota. The client shall not re-authorize the quota when events which are not
included in the Trigger AVP occur.
When included in the CCR command indicates the specific event which caused the re-authorization request of the
Reporting-Reason with value RATING_CONDITION_CHANGE associated.
1 CHANGE_IN_SGSN_IP_ADDRESS
3GPP
Release 13 186 3GPP TS 32.299 V13.4.0 (2016-03)
This value is used to indicate that a change in the SGSN IP address shall cause the Credit-Control client to ask
for a re-authorization of the associated quota.
2 CHANGE_IN_QOS
This value is used to indicate that a change in the end user negotiated QoS shall cause the Credit-Control client
to ask for a re-authorization of the associated quota.
NOTE 1: This should not be used in conjunction with enumerated values 10 to 23.
3 CHANGE_IN_LOCATION
This value is used to indicate that a change in the end user location shall cause the Credit-Control client to ask
for a re-authorization of the associated quota.
NOTE 2: This should not be used in conjunction with enumerated values 30 to 36.
4 CHANGE_IN_RAT
This value is used to indicate that a change in the radio access technology shall cause the Credit-Control client to
ask for a re-authorization of the associated quota.
5 CHANGE_IN_UE_TIMEZONE
This value is used to indicate that a change in the TimeZone where the end user is located shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
10 CHANGEINQOS_TRAFFIC_CLASS
This value is used to indicate that a change in the end user negotiated traffic class shall cause the Credit-Control
client to ask for a re-authorization of the associated quota.
11 CHANGEINQOS_RELIABILITY_CLASS
This value is used to indicate that a change in the end user negotiated reliability class shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
12 CHANGEINQOS_DELAY_CLASS
This value is used to indicate that a change in the end user negotiated delay class shall cause the Credit-Control
client to ask for a re-authorization of the associated quota.
13 CHANGEINQOS_PEAK_THROUGHPUT
This value is used to indicate that a change in the end user negotiated peak throughput shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
14 CHANGEINQOS_PRECEDENCE_CLASS
This value is used to indicate that a change in the end user negotiated precedence class shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
15 CHANGEINQOS_MEAN_THROUGHPUT
This value is used to indicate that a change in the end user negotiated mean throughput shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
16 CHANGEINQOS_MAXIMUM_BIT_RATE_FOR_UPLINK
This value is used to indicate that a change in the end user negotiated uplink maximum bit rate shall cause the
Credit-Control client to ask for a re-authorization of the associated quota.
17 CHANGEINQOS_MAXIMUM_BIT_RATE_FOR_DOWNLINK
This value is used to indicate that a change in the end user negotiated downlink maximum bit rate shall cause the
Credit-Control client to ask for a re-authorization of the associated quota.
18 CHANGEINQOS_RESIDUAL_BER
This value is used to indicate that a change in the end user negotiated residual BER shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
19 CHANGEINQOS_SDU_ERROR_RATIO
This value is used to indicate that a change in the end user negotiated SDU error ratio shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
3GPP
Release 13 187 3GPP TS 32.299 V13.4.0 (2016-03)
20 CHANGEINQOS_TRANSFER_DELAY
This value is used to indicate that a change in the end user negotiated transfer delay shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
21 CHANGEINQOS_TRAFFIC_HANDLING_PRIORITY
This value is used to indicate that a change in the end user negotiated traffic handling priority shall cause the
Credit-Control client to ask for a re-authorization of the associated quota.
22 CHANGEINQOS_GUARANTEED_BIT_RATE_FOR_UPLINK
This value is used to indicate that a change in the end user negotiated uplink guaranteed bit rate shall cause the
Credit-Control client to ask for a re-authorization of the associated quota.
23 CHANGEINQOS_GUARANTEED_BIT_RATE_FOR_DOWNLINK
This value is used to indicate that a change in the end user negotiated downlink guaranteed bit rate shall cause
the Credit-Control client to ask for a re-authorization of the associated quota.
24 CHANGEINQOS_APN_AGGREGATE_MAXIMUM_BIT_RATE
This value is used to indicate that a change in the APN aggregate maximum bit rate for the IP-CAN session shall
cause the Credit-Control client to ask for a re-authorization of the associated quota. This value is only applicable
when charging per IP-CAN session is active.
30 CHANGEINLOCATION_MCC
This value is used to indicate that a change in the MCC of the serving network shall cause the Credit-Control
client to ask for a re-authorization of the associated quota.
31 CHANGEINLOCATION_MNC
This value is used to indicate that a change in the MNC of the serving network shall cause the Credit-Control
client to ask for a re-authorization of the associated quota.
32 CHANGEINLOCATION_RAC
This value is used to indicate that a change in the RAC where the end user is located shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
33 CHANGEINLOCATION_LAC
This value is used to indicate that a change in the LAC where the end user is located shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
34 CHANGEINLOCATION_CellId
This value is used to indicate that a change in the Cell Identity where the end user is located shall cause the
Credit-Control client to ask for a re-authorization of the associated quota.
35 CHANGEINLOCATION_TAC
This value is used to indicate that a change in the TAC where the end user is located shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
36 CHANGEINLOCATION_ECGI
This value is used to indicate that a change in the ECGI where the end user is located shall cause the Credit-
Control client to ask for a re-authorization of the associated quota.
40 CHANGE_IN_MEDIA_COMPOSITION
This value is used to indicate that a change in the media composition (as identified within SDP) for an existing
SIP session shall cause the Credit-Control client to ask for a re-authorization of the associated quota.
50 CHANGE_IN_PARTICIPANTS_NMB
This value is used specifically for multi participating session to indicate that a change in the number of active
participants within a session shall cause the Credit-Control client to ask for a re-authorization of the associated
quota.
51 CHANGE_IN_ THRSHLD_OF_PARTICIPANTS_NMB
This value is used specifically to indicate that a change in the threshold of participants number within a session
shall cause the Credit-Control client to ask for a re-authorization of the associated quota.
NOTE 3: The threshold and the granularity of threshold are operator configurable. This should not be used in
conjunction with value 50.
3GPP
Release 13 188 3GPP TS 32.299 V13.4.0 (2016-03)
52 CHANGE_IN_USER_PARTICIPATING_TYPE
This value is used specifically to indicate that a change in the user participating type within a session shall cause
the Credit-Control client to ask for a re-authorization of the associated quota.
60 CHANGE_IN_SERVICE_CONDITION
This value is used to indicate that a change in rating conditions associated with a service occurs.
The description of the conditions causing a change are service specific and may be documented in middle-tier
specifications or may be configurable.
61 CHANGE_IN_SERVING_NODE
This value is used to indicate that a change in serving node shall cause the Credit-Control client to ask for a re-
authorization of the associated quota.
70 CHANGE_IN_USER_CSG_INFORMATION
This value is used to indicate a request of reporting the event that the user enters/leaves a CSG cell. When used
in a CCR, at entry to a CSG cell, the User-CSG-Information AVP shall be provided with the event report. When
used in a CCR without any User-CSG-Information AVP, it indicates the user leaves the CSG cell.
71 CHANGE_IN_HYBRID_SUBSCRIBED_USER_CSG_INFORMATION
This value is used to indicate a request of reporting the event that the user enters/leaves a hybrid cell that the user
subscribes to. When used in a CCR, at entry to a hybrid cell where the user is a member, the User-CSG-
Information AVP shall be provided with the event report. When used in a CCR without any User-CSG-
Information AVP, it indicates the user leaves the hybrid cell he was a member of.
72 CHANGE_IN_HYBRID_UNSUBSCRIBED_USER_CSG_INFORMATION
This value is used to indicate a request of reporting the event that the user enters/leaves a hybrid cell that the user
does not subscribe to. When used in a CCR, at entry to a hybrid cell where the user is not a member, the User-
CSG-Information AVP shall be provided with the event report. When used in a CCR without any User-CSG-
Information AVP, it indicates the user leaves the hybrid cell he was not a member of.
73 CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA
This value is used to indicate a request of reporting the event that the user enters/leaves the area as indicated in
the Presence-Reporting-Area-Information AVP. This includes reporting the initial status at the time the request is
initiated. When used in a CCR, the Presence-Reporting-Area-Identifier AVP and Presence-Reporting-Area-
Status AVP shall be provided in the Presence-Reporting-Area-Information AVP with the event report.
[ Incoming-Trunk-Group-ID ]
[ Outgoing-Trunk-Group-ID ]
7.2.237AVoid
7.2.237BVoid
3GPP
Release 13 189 3GPP TS 32.299 V13.4.0 (2016-03)
{ SSID }
[ BSSID ]
{ Value-Digits }
[ Exponent ]
If received in the context of Multiple-Service-Credit-Control AVP, the Credit-Control client shall seek re-authorization
from the server for the quota when the quota contents fall below the supplied threshold.
The client shall allow service to continue whilst the re-authorization is in progress, up to the volume indicated in the
original quota.
In the context of the Rating-Element AVP it denotes the durability of a Rating Element within a Tariff. I.e. if the service
consumed Unit-Quota-Threshold number of Unit-Types, the next Rating element becomes in effect.
7.2.240AUser-CSG-Information AVP
The User-CSG-Information AVP (AVP code 2319) is of type Grouped and holds the user "Closed Subscriber Group"
information associated to CSG cell access: it comprises CSG ID within the PLMN, access mode and indication on CSG
membership for the user when hybrid access applies, as defined in TS 29.060 [225] for GPRS case, and in TS 29.274
[226] for EPC case.
{ CSG-Id }
{ CSG-Access-Mode }
[ CSG-Membership-Indication ]
3GPP
Release 13 190 3GPP TS 32.299 V13.4.0 (2016-03)
0 Normal
1 NW PoC Box
2 UE PoC Box
{ UE-Local-IP-Address }
[ UDP-Source-Port ]
[ SSID ]
[ BSSID ]
[ Variable-Part-Order ]
{ Variable-Part-Type }
{ Variable-Part-Value }
3GPP
Release 13 191 3GPP TS 32.299 V13.4.0 (2016-03)
0 Integer
1 Number
2 Time
3 Date
4 Currency
5-127 Reserved for future standardization
128-255 Reserved for operator-defined types
Type Value
Integer String of digits, which shall be announced as a single
number, up to 10 digits.
Number String of digits, which shall be announced as individual
digits, up to 24 digits.
Time A string of digits in the form HHMM.
Date A string of digits in the form of YYYYMMDD.
Currency A string of digits in the form of AAAAAABB, where
AAAAAA is the integral part and BB is the decimal part.
7.2.242AVCS-Information AVP
The VCS-Information AVP (AVP code 3410) is of type Grouped. Its purpose is to allow the transmission of additional
VCS service specific information elements.
[ Bearer-Capability ]
[ Network-Call-Reference-Number ]
[ MSC-Address ]
[ Basic-Service-Code ]
[ ISUP-Location-Number ]
[ VLR-Number ]
[ Forwarding-Pending ]
[ ISUP-Release-Cause ]
[ Start-Time ]
[ Start-of-Charging ]
[ Stop-Time ]
[ PS-Free-Format-Data ]
7.2.242BVLR-Number AVP
The VLR-Number AVP (AVP code 3420) is type OctetString and identifies the international E.164 address of the VLR
serving the user. It is encoded as a TBCD-string. See TS 29.002 [232] for encoding of TBCD-strings.
3GPP
Release 13 192 3GPP TS 32.299 V13.4.0 (2016-03)
This AVP does not include leading indicators for the nature of address and the numbering plan; it contains only the
TBCD-encoded digits of the address.
If received, the Credit-Control client shall seek re-authorization from the server for the quota when the quota contents
fall below the supplied threshold. The client shall allow service to continue whilst the re-authorization is progress, up to
the volume indicated in the original quota.
7.2.244 Void
7.2.245 Void
7.2.246 Void
7.2.247 Void
7.2.248 Void
7.2.249 Void
7.2.250 Void
3GPP
Release 13 193 3GPP TS 32.299 V13.4.0 (2016-03)
These AVPs shall be used together with value 5535 (3GPP2) as Vendor-Id.
These AVPs shall be used together with value 13019 (ETSI) as Vendor-Id.
NOTE: The Fixed-User-Location-Info AVP is a fixed access specific AVP defined by 3GPP and listed in Table
7.2.0.1. The Fixed-User-Location-Info AVP uses the Vendor-Id specified in clause 7.2.0.
These AVPs shall be used together with value 45687 (oneM2M) as Vendor-Id.
3GPP
Release 13 194 3GPP TS 32.299 V13.4.0 (2016-03)
Annex A (informative):
Bibliography
a The 3GPP charging specifications
- 3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched (CS) domain
charging".
- 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched (PS) domain
charging".
- 3GPP TS 32.274: "Telecommunication management; Charging management; Short Message Service (SMS)
charging".
- 3GPP TS 32.276: "Telecommunication management; Charging management; Voice Call Service Charging".
- 3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data Record (CDR)
encoding rules description".
- 3GPP TS 32.297: "Telecommunication management; Charging management; Charging Data Record (CDR)
file format and transfer".
- 3GPP TS 32.296: "Telecommunication management; Charging management; Online Charging System (OCS)
applications and interfaces".
- 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data Record (CDR)
transfer".
3GPP
Release 13 195 3GPP TS 32.299 V13.4.0 (2016-03)
-
e Relevant IETF RFCs
- IETF RFC 959 (1985): "File Transfer Protocol".
3GPP
Release 13 196 3GPP TS 32.299 V13.4.0 (2016-03)
Annex B (informative):
Change history
3GPP
Release 13 197 3GPP TS 32.299 V13.4.0 (2016-03)
Change history
Date TSG TSG Doc. CR Re Subject/Comment Cat Old New
# v
Dec SP-38 SP-070745 0202 -- Add new AVP codes to satisfy OMA charging requirements C 8.0.0 8.1.0
2007
Dec SP-38 SP-070745 0203 -- Add new values to PoC-User-Role-info-Units AVP - Align with OMA C 8.0.0 8.1.0
2007 PoC charging requirements
Dec SP-38 SP-070745 0204 -- Add general description to PoC-Group-Name B 8.0.0 8.1.0
2007
Dec SP-38 SP-070925 0205 1 Introduce Diameter details for SMS charging B 8.0.0 8.1.0
2007
Mar 2008 SP-39 SP-080059 0206 -- Add IBCF to Node-Functionality AVP list of NEs B 8.1.0 8.2.0
Mar 2008 SP-39 SP-080074 0207 -- Usage of CC-Correlation-Id in online charging - Align with IETF RFC C 8.1.0 8.2.0
4006
Mar 2008 SP-39 SP-080074 0208 -- Align Number-Of-Messages-Sent AVP in Diameter Binding for SMS C 8.1.0 8.2.0
charging with new R8 TS 32.274
Mar 2008 SP-39 SP-080074 0209 -- Corrections on Diameter AVP for SMS Charging F 8.1.0 8.2.0
Mar 2008 SP-39 SP-080074 0210 -- Add on Number Portability and Carrier Select routing information B 8.1.0 8.2.0
Jun 2008 SP-40 SP-080330 0211 -- Correction on SCCP-Address AVPs F 8.2.0 8.3.0
Jun 2008 SP-40 SP-080330 0212 -- Add PoC-Event-Type AVP into PoC-Information B 8.2.0 8.3.0
Jun 2008 SP-40 SP-080330 0213 -- Correction to PoC-Controlling-Address AVP and PoC-Group-Name F 8.2.0 8.3.0
AVP
Sep SP-41 SP-080466 0214 -- Correction of inconsistencies in Offline Charging and Online F 8.3.0 8.4.0
2008 Charging messages
Sep SP-41 SP-080330 0215 -- Correction on AVP codes - Alignment with TS 29.230 F 8.3.0 8.4.0
2008
Sep SP-41 SP-080330 0216 -- Multiple SMS destination - Alignment with TS 23.040 C 8.3.0 8.4.0
2008
Dec SP-42 SP-080706 0218 - Completion on message tables F 8.4.0 8.5.0
2008
Dec SP-42 SP-080707 0219 - Service Context Id for MMTEL B 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0220 - Correction on AVP code allocation F 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0221 - Clarification on AVP descriptions for EPC Charging F 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0222 - Add SMS-SC as SMS node type B 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0223 - Additional Address Info for SMS charging B 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0224 - Add charging of SMS services to 32.299 B 8.4.0 8.5.0
2008
Dec SP-42 SP-080707 0225 - TS 32.299 AVPs Introduction for MMTel charging B 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0226 - Correction on References Section F 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0227 - Addition of SDP offer and answer and clarification on media initiator B 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0228 - Additional non-3GPP access information F 8.4.0 8.5.0
2008
Dec SP-42 SP-080706 0229 - Add a new value to Trigger-Type AVP B 8.4.0 8.5.0
2008
Dec SP-42 SP-080852 0217 - TS 32.299 AVPs for offline charging - Rf interface from S-GW and P- B 8.4.0 8.5.0
2008 GW
Mar 2009 SP-43 SP-090206 0232 TS 32.299 MMTel information AVP alignment with 32.275 definition B 8.5.0 8.6.0
Mar 2009 SP-43 SP-090206 0235 Add CONF charging specific parameters B 8.5.0 8.6.0
Mar 2009 SP-43 SP-090203 1 Correction on 'Subscription Id' category used for EPS offline C 8.5.0 8.6.0
0230 Charging
Service-Type and Service-Mode in Supplementary-service AVP :
Mar 2009 SP-43 SP-090203 0231 - F 8.5.0 8.6.0
format change
Mar 2009 SP-43 SP-090206 0232 - SMS AVP structure alignment B 8.5.0 8.6.0
Mar 2009 SP-43 SP-090045 0234 Add Serving-Node-Type AVP to PS-Information in 32.299 B 8.5.0 8.6.0
Mar 2009 SP-43 SP-090206 0235 - AoC Support in Ro B 8.5.0 8.6.0
Mar 2009 SP-43 SP-090045 0236 - EPS Offline Charging - Complete PS-information AVP description B 8.5.0 8.6.0
Multiple subscription-id in service-information for EPS offline
Mar 2009 SP-43 SP-090203 0237 - B 8.5.0 8.6.0
Charging
Missing information in PS information AVP for SGW/PGW CDRs in
Mar 2009 SP-43 SP-090206 0238 - B 8.5.0 8.6.0
EPS offline charging
Jun 2009 SP-44 SP-090432 0243 - Correction of Recipient-Info AVP F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0244 - AVP code allocation for DCD Charging F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0245 - Rel-8 CR 32.299 alignment with RFC 4006 F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0246 - Rel-8 CR 32.299 clarification of ICID F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0247 - Remove generic "Non 3GPP specific information" parameter F 8.6.0 8.7.0
3GPP
Release 13 198 3GPP TS 32.299 V13.4.0 (2016-03)
Jun 2009 SP-44 SP-090432 0248 - Correction on PDP context usage F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0249 - Correction on AoC-Information AVP F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0252 - Correction on Refund Information F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0253 - LCS-information AVP not complete F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0254 - PS-information AVP description alignment with 32.251 definition F 8.6.0 8.7.0
Jun 2009 SP-44 SP-090432 0257 - Correction on EPC Charging F 8.6.0 8.7.0
Add MMTel supplementary services FA, CCBS&CCNR, MCID, CAT
Jun 2009 SP-44 SP-090294 0251 - B 8.7.0 9.0.0
for MMTel Charging
Jun 2009 SP-44 SP-090292 0255 - Rel-9 CR 32.299 addition of online charging flag B 8.7.0 9.0.0
Jun 2009 SP-44 SP-090292 0256 - Rel-9 CR 32.299 correction of timestamp granularity B 8.7.0 9.0.0
Sep
SP-45 SP-090536 9.1.0
2009 0258 - Correction on AVP definitions A 9.0.0
Sep
SP-45 SP-090536 9.1.0
2009 0260 - Correction on MMS-Information AVP A 9.0.0
Sep
SP-45 SP-090536 9.1.0
2009 0262 - Rel-9 CR 32.299 correction and alignment with TS 32.280 A 9.0.0
Sep
SP-45 SP-090536 9.1.0
2009 0264 - Error in Number-Portability-Routing-Information AVP definition A 9.0.0
Sep
SP-45 SP-090538 9.1.0
2009 0265 - Add "Closed User Group (CUG)" for MMTel Charging B 9.0.0
Sep
SP-45 SP-090538 9.1.0
2009 0266 - Add 3PTY MMTel supplementary service charging B 9.0.0
Sep R9 CR 32299 add MBMS GW address below MBMS information
SP-45 SP-090541 9.1.0
2009 0267 - AVP B 9.0.0
Sep
SP-45 SP-090538 9.1.0
2009 0268 - New AVPs for RTTI support in IMS offline charging B 9.0.0
Sep
SP-45 SP-090536 9.1.0
2009 0271 - Correction on Content Type - Alignment with OMA definition A 9.0.0
Sep
SP-45 SP-090537 9.1.0
2009 0272 - Correction of time stamp diameter types F 9.0.0
Sep
SP-45 SP-090536 9.1.0
2009 0274 - Correction of Accounting Input/Output Octets handling A 9.0.0
Sep
SP-45 SP-090537 9.1.0
2009 0275 - Emergency bearer service consideration for charging B 9.0.0
Sep Addition of IP multicast delivery indicator below MBMS information
SP-45 SP-090536 9.1.0
2009 0277 - AVP A 9.0.0
Dec
SP-46 9.2.0
2009 SP-090720 0279 - Alignment of Address-Type AVP with 32.274 A 9.1.0
Dec Alignment with TS 32.251 for "Volume Limit" and "Time Limit" in
SP-46 9.2.0
2009 SP-090720 0281 - Change-Condition AVP A 9.1.0
Dec
SP-46 9.2.0
2009 SP-090720 0283 - Multiple Change-Condition AVP for simultaneous Condition changes A 9.1.0
Dec
SP-46 9.2.0
2009 SP-090721 0284 - Editorial clean-up D 9.1.0
Dec
SP-46 9.2.0
2009 SP-090722 0285 - MMTel related AVP applicable for Online Charging B 9.1.0
Dec
SP-46 9.2.0
2009 SP-090720 0287 - Correction on priority session treatment A 9.1.0
Dec Alignment with TS 32.251 for "User location Change" Condition in
SP-46 9.2.0
2009 SP-090720 0289 - Change-Condition AVP A 9.1.0
Dec Alignment between Change-Condition AVP value with ASN1
SP-46 9.2.0
2009 SP-090720 0291 - ServiceConditionChange value "serviceStop" A 9.1.0
Dec AVP for Account Expiration Information from OCS to IMS Application
SP-46 9.2.0
2009 SP-090721 0292 - Servers B 9.1.0
Dec Aligning AoC- Information AVP with RTTI and subscription
SP-46 9.2.0
2009 SP-090721 0293 - information C 9.1.0
Dec Correction of Number Portability and Carrier Select information
SP-46 9.2.0
2009 SP-090720 0295 - AVPs A 9.1.0
Dec
SP-46 9.2.0
2009 SP-090721 0296 - Add CSG parameters for CSG based online and offline charging B 9.1.0
Mar 2010 SP-47 SP-100041 0297 - Correction on AVP code definitions F 9.2.0 9.3.0
Mar 2010 SP-47 SP-100040 0299 - Correction of Role-of-Node AVP A 9.2.0 9.3.0
Alignment with TS 32.251 for "Charging Characteristics Selection
Mar 2010 SP-47 9.3.0
SP-100040 0301 - Mode" parameter A 9.2.0
Mar 2010 SP-47 SP-100041 0302 - Add CSG parameters for CSG based online and offline charging F 9.2.0 9.3.0
Mar 2010 SP-47 SP-100044 0303 - MMTel related AVP applicable for Online Charging F 9.2.0 9.3.0
Mar 2010 SP-47 SP-100040 0305 - Correction for offline Charging from PGW - 3GPP2 User location A 9.2.0 9.3.0
Mar 2010 SP-47 SP-100041 0306 - Remove unused Service-Condition-Change AVP F 9.2.0 9.3.0
Mar 2010 SP-47 SP-100041 0307 - Correction on SDP handling in IMS Charging F 9.2.0 9.3.0
Add "Personal Network management" MMTel supplementary service
Mar 2010 SP-47 9.3.0
SP-100044 0308 - charging description B 9.2.0
Add "Customized Ringing Signal (CRS)" MMTel supplementary
Mar 2010 SP-47 9.3.0
SP-100044 0309 - service charging description B 9.2.0
3GPP
Release 13 199 3GPP TS 32.299 V13.4.0 (2016-03)
Jun 2010 SP-48 SP-100265 0312 - Correction on AVP definitions A 9.3.0 9.4.0
Oct 2010 SP-49 SP-100496 0314 - Correction for Dual IP addresses associated to one PDN connection A 9.4.0 9.5.0
Correction on Charging-Rule-Based-Name AVP - Alignment with TS
Oct 2010 SP-49 SP-100495 A 9.5.0
0317 - 23.203 9.4.0
Oct 2010 SP-49 SP-100496 0319 - Correction on Event Charging with Reservation A 9.4.0 9.5.0
Oct 2010 SP-49 SP-100497 0320 - Correction of Reason-Code AVP F 9.4.0 9.5.0
Dec
SP-50 SP-100756 A 9.6.0
2010 0328 - Correction of Inter-Operator-Identifier AVP – Align with TS 32.260 9.5.0
Dec
SP-50 SP-100757 F 9.6.0
2010 0322 - Correction of Trigger-Type AVP 9.5.0
Dec
SP-50 SP-100758 F 9.6.0
2010 0324 2 Add missing LCS-Format-Indicator AVP value for "SIP_URL" 9.5.0
Dec
SP-50 SP-100759 F 10.0.0
2010 0325 2 Replace the Authorized-QoS AVP name with Authorised-QoS AVP 9.6.0
Add E.164 harmonized address format to the current E.212 in MMS
Mar 2010 SP-51 10.1.0
SP-110109 0329 1 Charging C 10.0.0
Mar 2010 SP-51 SP-110105 0330 3 Adding CDR fields needed for Machine Type Communication B 10.0.0 10.1.0
Add missing enumeration value for E-CSCF network element in
Mar 2010 SP-51 10.1.0
SP-110108 0332 2 Node-Functionality AVP - Align with 32.298 A 10.0.0
Mar 2010 SP-51 SP-110108 0336 1 Add internal structure and encoding for the Location-Estimate AVP A 10.0.0 10.1.0
Mar 2010 SP-51 SP-110109 0340 2 Correction to charging scenarios D 10.0.0 10.1.0
Mar 2010 SP-51 SP-110108 0344 1 Correction of CSG trigger handling - Alignment with TS 29.212 A 10.0.0 10.1.0
Addition of IARI in IMS charging information, alignment with TS
Mar 2010 SP-51 10.1.0
SP-110109 0345 1 22.115 and TS 23.228 B 10.0.0
Mar 2010 SP-51 SP-110109 0347 1 R10 32299 Correction on AVP Subscriber-role F 10.0.0 10.1.0
Add 'Advice Of Charge (AoC)' MMTel supplementary service
Mar 2010 SP-51 10.1.0
SP-110112 0349 - Charging description - Align with 32.275 B 10.0.0
May
SP-52 10.2.0
2011 SP-110281 0352 1 Correction to Re-authorization Request Message F 10.1.0
May Correction of RAT-Type AVP, alignment with TS 29.212, Gx
SP-52 10.2.0
2011 SP-110281 0356 1 interface F 10.1.0
May
SP-52 10.2.0
2011 SP-110404 0359 1 Correction on essential supported fields in EPC Online Charging A 10.1.0
May
SP-52 10.2.0
2011 SP-110404 0362 1 Correction on Rf interface for missing information in SGW CDR A 10.1.0
May
SP-52 10.2.0
2011 SP-110294 0363 1 AVPs enhancement for OMR Charging introduction B 10.1.0
May
SP-52 10.2.0
2011 SP-110280 0365 1 Correction in SCC AS CDR for IMS service continuity A 10.1.0
May Correction on IMS Application Reference Identifier (IARI) in IMS
SP-52 10.2.0
2011 SP-110281 0366 1 Charging F 10.1.0
May
SP-52 11.0.0
2011 SP-110317 0350 1 Rc Context Definition for Diameter Usage B 10.2.0
Sep
SP-53 11.1.0
2011 SP-110528 0370 - Correction on PDN connection identifier for Charging A 11.0.0
Sep Correction for dynamic address flags associated to PDN connection
SP-53 11.1.0
2011 SP-110528 0375 - of PDP/PDN type IPv4v6 A 11.0.0
Sep
SP-53 11.1.0
2011 SP-110530 0377 - Correction of RAT Type, alignment with TS 29.061 A 11.0.0
Sep
SP-53 11.1.0
2011 SP-110528 0381 1 Correction on AVP definition - Align with IETF RFC 3588 A 11.0.0
Sep Addition of Sponsored Data Connectivity charging - Align with TS
SP-53 11.1.0
2011 SP-110541 0393 1 23.203 B 11.0.0
Dec Correction of Dynamic Address Flag usage for IPv4v6 PDN
SP-54 11.1.0 11.2.0
2011 SP-110708 0420 2 Connection in PS Information AVP A
Dec
SP-54 11.1.0 11.2.0
2011 SP-110711 0412 1 Correction of IPv6 PDP/PDN prefix A
Dec Correction of IETF specified AVP usage in 3GPP charging
SP-54 11.1.0 11.2.0
2011 SP-110711 0416 - applications A
Dec
SP-54 11.1.0 11.2.0
2011 SP-110712 0394 2 Add Transit IOI to IMS Offline Charging B
Mar 2012 SP-55 SP-120048 0422 1 Add missing Trigger-Type value to address change of UE Timezone A 11.2.0 11.3.0
alignment with TS 29.212
Mar 2012 SP-55 SP-120049 0425 1 Add Status in AVP "Application-Server-Information B 11.2.0 11.3.0
June- SP-56 SP-120362 0428 1 Correction of Serving Node Type, alignment with 29.274 F 11.3.0 11.4.0
2012
June- SP-56 SP-120359 0430 1 Correction of AVP usage, alignment with RFC 4006 A 11.3.0 11.4.0
2012
June- SP-56 SP-120361 0433 1 Correction on AVP definition A 11.3.0 11.4.0
2012
June- SP-56 SP-120362 0434 1 Correction of Multiple Service Credit-Control use F 11.3.0 11.4.0
2012
June- SP-56 SP-120359 0440 1 Correction of diameter AVP usages, alignment with RFC 4006 A 11.3.0 11.4.0
2012
3GPP
Release 13 200 3GPP TS 32.299 V13.4.0 (2016-03)
June- SP-56 SP-120360 0447 1 Correction on SGW and PGW Address reporting, alignment with A 11.3.0 11.4.0
2012 29.212
June- SP-56 SP-120374 0448 2 Enhancing IMS charging for RAVEL B 11.3.0 11.4.0
2012
June- SP-56 SP-120362 0449 1 Correction of Termination Action procedure F 11.3.0 11.4.0
2012
June- SP-56 SP-120397 0450 1 Add charging parameters for NetLoc B 11.3.0 11.4.0
2012
June- SP-56 SP-120361 0452 - Correction on PDP-Address-Prefix-Length A 11.3.0 11.4.0
2012
Sep- SP-57 SP-120646 0456 1 Rename Service-type AVP A 11.4.0 11.5.0
2012
Sep- SP-57 SP-120561 0460 - Remove Authorised-Qos from P-CSCF CDR A 11.4.0 11.5.0
2012
Sep- SP-57 SP-120566 0461 1 Correction on the AVP name F 11.4.0 11.5.0
2012
Sep- SP-57 SP-120566 0462 1 Supplementation for Reporting-Reason AVP C 11.4.0 11.5.0
2012
Sep- SP-57 SP-120564 0465 1 Correction of AoC-Information AVP usage A 11.4.0 11.5.0
2012
Sep- SP-57 SP-120562 0467 1 Correction of Called-Party-Address AVP A 11.4.0 11.5.0
2012
Sep- SP-57 SP-120566 0469 1 Correction of calling party handling C 11.4.0 11.5.0
2012
Sep- SP-57 SP-120646 0472 2 Correction on AoC service support A 11.4.0 11.5.0
2012
Sep- SP-57 SP-120627 0473 1 Reference list correction to align with the corrected TS 29.212 title F 11.4.0 11.5.0
2012
Dec- SP-58 SP-120789 0474 1 Correction on the figure description of Centralized Unit F 11.5.0 11.6.0
2012 Determination and Centralized Rating
Dec- SP-58 SP-120789 0476 1 Clarification of Type 1 and Type 2 IOI Usage for IMS Roaming F 11.5.0 11.6.0
2012
Dec- SP-58 SP-120785 0479 2 Emergency Indicator introduction in P-CSCF CDR A 11.5.0 11.6.0
2012
Dec- SP-58 SP-120801 0481 - Correction on NNI-Information AVP F 11.5.0 11.6.0
2012
Dec- SP-58 SP-120792 0482 1 Introduction AVPs description for SMS over MME Charging B 11.5.0 11.6.0
2012
Dec- SP-58 SP-120793 0483 1 Offline Charging description for ATCF B 11.5.0 11.6.0
2012
Dec- SP-58 SP-120789 0484 - Correction on charging for IMS transit functions F 11.5.0 11.6.0
2012
SP-130062 0488 1 Clarification of Type 1 IOI Usage and Multiple Sets of Inter Operator F
Identifiers for IMS Roaming
SP-130054 0491 1 Related ICID Corrections for SRVCC Charging Correlation F 11.6.0 11.7.0
Mar-
SP-59 SP-130050 0495 1 Re-introduce Authorized-Qos AVP specified as unused A
2013
SP-130054 0496 - Correction of LCS-Client-Type AVP definition F
0485 1 Correction on Trigger-Type AVP F
SP-130053 11.7.0 12.0.0
0489 1 Correction of Minimum Service-Context-Id AVP Content F
SP-130270 0502 1 Addition of IMS Visited Network Identifier A
SP-130270 0506 - Correction on AVP definitions A
SP-130271 0517 1 Adjustment on IMEI - alignment to TS 29.274 F
Jun-2013 SP-60 SP-130303 0528 - Correction of User-Equipment-Info-Value : encoding A 12.0.0 12.1.0
SP-130270 0530 1 Introduction of Charging for access to Trusted WLAN Access A
Network in EPC - over S2a
SP-130271 0531 1 Add Reason Header AVP B
SP-130443 0532 - Missing value for ATCF in Node-Functionality AVP F 12.1.0 12.2.0
SP-130435 0533 1 Correction on on data accounting F
Sep- SP-130443 0537 - Missing value for ATCF in Node-Functionality AVP A
SP-61
2013 SP-130435 0539 - Additional Access Network Information Field B
SP-130435 0540 - Align RAR/RAA description with other messages description and F
Correction on proxy-info AVP in RAA
Dec SP-62 SP-130677 0550 2 Correction for use of Destination-Host AVP in ACR A 12.2.0 12.3.0
2013 SP-130620 0551 1 AVP enhancement for application based charging B
SP-130619 0552 2 Addition of Instance Id for IMS Charging B
SP-130618 0554 - Correction for User Location Info Time A
SP-130671 0559 - Correction on inconsistencies for MMTel Charging A
SP-130620 0560 1 AVP definition for application based charging B
SP-130627 0565 1 Correction for Route Header for IMS Interconnection Charging A
SP-130618 0567 - Correction on Application-Server-Information AVP A
Mar- SP-63 SP-140154 0569 2 Addition of Fixed User Subscription Identifier B 12.3.0 12.4.0
2014 SP-140033 0575 1 Correction of data type for Time-Usage and applicability of Service- A
Specific-Info and AF-Charging-Identifier
3GPP
Release 13 201 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP
Release 13 202 3GPP TS 32.299 V13.4.0 (2016-03)
3GPP