3GPP CDR Specifications
3GPP CDR Specifications
3GPP CDR Specifications
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 9 2 3GPP TS 32.298 V9.5.0 (2010-10)
Keywords
UMTS, E-UTRAN, GPRS, EPS, charging, management
3GPP
Postal address
Internet
http://www.3gpp.org
Copyright Notification
© 2010, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, 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 currently being 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 9 3 3GPP TS 32.298 V9.5.0 (2010-10)
Contents
Foreword........................................................................................................................................................10
1 Scope....................................................................................................................................................11
2 References............................................................................................................................................11
3 Definitions, symbols and abbreviations................................................................................................14
3.1 Definitions.........................................................................................................................................................14
3.2 Symbols.............................................................................................................................................................15
3.3 Abbreviations.....................................................................................................................................................15
4 Architecture Considerations.................................................................................................................16
5 CDR parameters and abstract syntax....................................................................................................17
5.1 CDR parameter description...............................................................................................................................17
5.1.1 Generic CDR parameters.............................................................................................................................17
5.1.1.1 Serving Network Identity.......................................................................................................................17
5.1.1.2 Service Context Id..................................................................................................................................17
5.1.1.3 Subscription Identifier............................................................................................................................17
5.1.1.4 Service Specific Info..............................................................................................................................17
5.1.1.5 Service Specific Type.............................................................................................................................17
5.1.1.6 Service Specific Data.............................................................................................................................18
5.1.2 Bearer level CDR parameters......................................................................................................................18
5.1.2.1 CS domain CDR parameters..................................................................................................................18
5.1.2.1.1 Additional Charging Information.....................................................................................................18
5.1.2.1.2 AoC parameters/change of AoC parameters.....................................................................................18
5.1.2.1.3 Basic Service/change of service/ISDN Basic Service......................................................................18
5.1.2.1.4 Call duration.....................................................................................................................................18
5.1.2.1.5 Call reference....................................................................................................................................19
5.1.2.1.6 Calling/called/connected/translated number.....................................................................................20
5.1.2.1.7 Calling Party Number.......................................................................................................................20
5.1.2.1.8 CAMEL call leg information............................................................................................................20
5.1.2.1.9 CAMEL information.........................................................................................................................20
5.1.2.1.10 CAMEL initiated CF indicator.........................................................................................................20
5.1.2.1.11 CAMEL modified Service Centre....................................................................................................21
5.1.2.1.12 CAMEL SMS Information...............................................................................................................21
5.1.2.1.13 Cause for termination.......................................................................................................................21
5.1.2.1.14 Channel Coding Accepted/Channel Coding Used............................................................................22
5.1.2.1.15 Data volume......................................................................................................................................22
5.1.2.1.16 Default call/SMS handling...............................................................................................................22
5.1.2.1.17 Destination Subscriber Number........................................................................................................22
5.1.2.1.18 Diagnostics.......................................................................................................................................22
5.1.2.1.19 EMS-Digits.......................................................................................................................................22
5.1.2.1.20 EMS-Key..........................................................................................................................................22
5.1.2.1.21 Entity number...................................................................................................................................22
5.1.2.1.22 Equipment id.....................................................................................................................................22
5.1.2.1.23 Equipment type.................................................................................................................................22
5.1.2.1.24 Event time stamps.............................................................................................................................23
5.1.2.1.25 Fixed Network User Rate.................................................................................................................23
5.1.2.1.26 Free format data................................................................................................................................24
5.1.2.1.27 Free format data append indicator....................................................................................................24
5.1.2.1.28 GsmSCF address...............................................................................................................................24
5.1.2.1.29 Guaranteed Bit Rate..........................................................................................................................24
5.1.2.1.30 HSCSD parameters/Change of HSCSD parameters.........................................................................24
5.1.2.1.31 Incoming/outgoing trunk group........................................................................................................25
5.1.2.1.32 Interrogation result...........................................................................................................................25
5.1.2.1.33 IMEI Check Event............................................................................................................................25
5.1.2.1.34 IMEI Status.......................................................................................................................................25
5.1.2.1.35 JIP Parameter....................................................................................................................................25
3GPP
Release 9 4 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 5 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 6 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 7 3GPP TS 32.298 V9.5.0 (2010-10)
5.1.3.1.44 Retransmission..................................................................................................................................52
5.1.3.1.45 Role of Node.....................................................................................................................................52
5.1.3.1.46 SDP Answer Timestamp...................................................................................................................52
5.1.3.1.47 SDP Media Components...................................................................................................................52
5.1.3.1.48 SDP Media Description:...................................................................................................................53
5.1.3.1.49 SDP Media Name.............................................................................................................................53
5.1.3.1.50 SDP Offer Timestamp.......................................................................................................................53
5.1.3.1.51 SDP Session Description..................................................................................................................53
5.1.3.1.52 SDP Type..........................................................................................................................................53
5.1.3.1.53 Served Party IP Address...................................................................................................................53
5.1.3.1.54 Service Delivery End Time Stamp...................................................................................................53
5.1.3.1.55 Service Delivery Start Time Stamp..................................................................................................53
5.1.3.1.56 Service ID.........................................................................................................................................54
5.1.3.1.57 Service Reason Return Code............................................................................................................54
5.1.3.1.58 Service Request Timestamp..............................................................................................................54
5.1.3.1.59 Session ID.........................................................................................................................................54
5.1.3.1.60 Session Priority.................................................................................................................................54
5.1.3.1.61 SIP Method.......................................................................................................................................54
5.1.3.1.62 SIP Request Timestamp....................................................................................................................54
5.1.3.1.63 SIP Request Timestamp Fraction......................................................................................................54
5.1.3.1.64 SIP Response Timestamp..................................................................................................................54
5.1.3.1.65 SIP Response Timestamp Fraction...................................................................................................54
5.1.3.1.66 S-CSCF Information.........................................................................................................................54
5.1.3.1.67 Tariff Information.............................................................................................................................54
5.1.3.1.68 Tariff XML.......................................................................................................................................55
5.1.3.1.69 Trunk Group ID Incoming/Outgoing................................................................................................55
5.1.4 Service level CDR parameters.....................................................................................................................55
5.1.4.1 MMS CDR parameters...........................................................................................................................55
5.1.4.1.1 3GPP MMS Version..........................................................................................................................55
5.1.4.1.2 Access Correlation............................................................................................................................55
5.1.4.1.3 Acknowledgement Request..............................................................................................................55
5.1.4.1.4 Attributes List...................................................................................................................................55
5.1.4.1.5 Billing Information...........................................................................................................................55
5.1.4.1.6 Charge Information...........................................................................................................................55
5.1.4.1.7 Content Type.....................................................................................................................................56
5.1.4.1.8 Delivery Report Requested...............................................................................................................56
5.1.4.1.9 Duration of Transmission.................................................................................................................56
5.1.4.1.10 Earliest Time of Delivery.................................................................................................................56
5.1.4.1.11 Forward Counter...............................................................................................................................56
5.1.4.1.12 Forwarding Address..........................................................................................................................56
5.1.4.1.13 Forwarding MMS Relay/Server Address.........................................................................................56
5.1.4.1.14 Limit.................................................................................................................................................56
5.1.4.1.15 Linked ID..........................................................................................................................................56
5.1.4.1.16 Local Record Sequence Number......................................................................................................56
5.1.4.1.17 Managing Address............................................................................................................................57
5.1.4.1.18 Message Class...................................................................................................................................57
5.1.4.1.19 Message Distribution Indicator........................................................................................................57
5.1.4.1.20 Message ID.......................................................................................................................................57
5.1.4.1.21 Message Reference...........................................................................................................................57
5.1.4.1.22 Message selection.............................................................................................................................57
5.1.4.1.23 Message Size....................................................................................................................................57
5.1.4.1.24 MMBox Storage Information...........................................................................................................57
5.1.4.1.25 MM component list..........................................................................................................................58
5.1.4.1.26 MM Date and Time...........................................................................................................................58
5.1.4.1.27 MM Listing.......................................................................................................................................58
5.1.4.1.28 MM Status Code...............................................................................................................................58
5.1.4.1.29 MSCF Information...........................................................................................................................58
5.1.4.1.30 Originator Address............................................................................................................................58
5.1.4.1.31 Originator MMS Relay/Server Address...........................................................................................58
5.1.4.1.32 Priority..............................................................................................................................................58
5.1.4.1.33 Quotas...............................................................................................................................................58
3GPP
Release 9 8 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 9 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 10 3GPP TS 32.298 V9.5.0 (2010-10)
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 9 11 3GPP TS 32.298 V9.5.0 (2010-10)
1 Scope
The present document is part of a series of documents that specify charging functionality and charging management in
3GPP networks (GSM/UMTS/EPS). The 3GPP core network charging architecture and principles are specified in
document 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 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 the CDR parameters, the abstract syntax and encoding rules for all the CDR types that
are defined in the charging management TSs described above. Therefore, it is only applicable to offline charging. The
mechanisms used to transfer the CDRs from the generating node to the operator’s billing domain (e.g. the billing system
or a mediation device) are specified in TS 32.297 [42]. Further details with respect to the operator’s billing domain for
offline charging are out of scope of 3GPP standardisation.
Note that a generic Diameter application for online charging in 3GPP networks is specified in TS 32.299 [50].
Furthermore, 3GPP TSs are being created to standardise some technical aspects of the operator’s billing domain for
online charging, i.e. the Online Charging System (OCS).
All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in
the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across charging management in 3GPP domains 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].
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.
[12] 3GPP TS 32.252: "Telecommunication management; Charging management; Wireless Local Area
Network (WLAN) charging".
3GPP
Release 9 12 3GPP TS 32.298 V9.5.0 (2010-10)
[34] Void.
[51] Void.
[102] 3GPP TS 22.002: "Circuit Bearer Services (BS) supported by a Public Land Mobile Network
(PLMN)".
[202] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2".
[204] 3GPP TS 23.207: "End-to-end Quality of Service (QoS) concept and architecture".
[205] Void.
[206] 3GPP TS 23.140: "Multimedia Messaging Service (MMS); Functional description; Stage 2".
3GPP
Release 9 13 3GPP TS 32.298 V9.5.0 (2010-10)
[207] 3GPP TS 23.172: "Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI
fallback and service modification; Stage 2".
[208] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3".
[209] 3GPP TS 24.080: "Mobile radio Layer 3 supplementary service specification; Formats and
coding".
[210] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[211] 3GPP TS 24.604: “Communication Diversion (CDIV) using IP Multimedia (IM); Protocol
specification”
[212] 3GPP TS 25.413: "UTRAN Iu interface Radio Access Network Application Part (RANAP)
signalling".
[213] 3GPP TS 27.001: "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)".
[215] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP)
across the Gn and Gp interface".
[216] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting
packet based services and Packet Data Networks (PDN)".
[217] 3GPP TS 29.078: "Customised Applications for Mobile network Enhanced Logic (CAMEL);
CAMEL Application Part (CAP) specification".
[218] 3GPP TS 29.140: "Multimedia Messaging Service (MMS); MM10 interface Diameter based
protocol; Stage 3".
[220] 3GPP TS 29.212: "Policy and Charging control over Gx reference point".
[221] 3GPP TS 29.214: "Policy and Charging control over Rx reference point".
[222] 3GPP TS 29.272: "Mobility Management Entity (MME) and Serving GPRS Support Node
(SGSN) related interfaces based on Diameter protocol".
[223] 3GPP TS 29.274: "Evolved GPRS Tunnelling Protocol for Control Plane (GTPv2-C); Stage 3".
[224] 3GPP TS 29.275: “ Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols; Stage
[225] 3GPP TS 29.658: "SIP Transfer of IP Multimedia Service Tariff Information". 3"5.
[226] 3GPP TS 36.413 "Evolved Universal Terrestrial Radio Access (E-UTRA) ; S1 Application
Protocol (S1AP)".
[227] 3GPP TS 49.031: "Location Services (LCS); Base Station System Application Part LCS Extension
(BSSAP-LE)".
[300] ITU-T Recommendation X.680 | ISO/IEC 8824-1: "Information technology; Abstract Syntax
Notation One (ASN.1): Specification of Basic Notation".
[301] ITU-T Recommendation X.690 | ISO/IEC 8825-1: "Information technology - ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)".
3GPP
Release 9 14 3GPP TS 32.298 V9.5.0 (2010-10)
[302] ITU-T Recommendation X.691 | ISO/IEC 8825-2: "Information technology - ASN.1 encoding
rules: Specification of Packed Encoding Rules (PER)".
[303] ITU-T Recommendation X.693 | ISO/IEC 8825-4: "Information technology - ASN.1 encoding
rules: XML encoding rules (XER).
[305] ITU-T Recommendation X.721 ISO/IEC 10165-2: " Information technology - Open Systems
Interconnection - Structure of management information: Definition of management information".
[308] ITU-T Recommendation E.164: The international public telecommunication numbering plan
[309] ITU-T Recommendation Q.767: Application of the ISDN user part of CCITT signalling system
No. 7 for international ISDN interconnections
[310] ETS 300 196: "Digital Subscriber Signalling System No. one (DSS1) protocol".
[312] ETSI GSM 05.01: "Digital Cellular Telecommunications System (Phase 2+); Physical Layer on
the Radio Path; General Description".
[313] ETSI GSM 08.08: "European Digital Cellular Telecommunication System (Phase 2); Mobile-
Services Switching Centre - Base Station System (MSC - BSS) Interface Layer 3 Specification".
[400] IETF RFC 822: "Standard for the format of arpa internet text messages".
[402] IETF RFC 3966: "The tel URI for Telephone Numbers".
[403] IETF RFC 3265: "Session Initiation Protocol (SIP)-Specific Event Notification".
[404] IETF RFC 3455: "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP)
for the 3rd-Generation Partnership Project (3GPP)".
Billing Domain: part of the operator network, which is outside the core network, which receives and processes CDR
files from the core network charging functions. It includes functions that can provide billing mediation and billing or
other (e.g. statistical) end applications. It is only applicable to offline charging (see "Online Charging System" for
equivalent functionality in online charging).
Charging Data Record (CDR): formatted collection of information about a chargeable event (e.g. time of call set-up,
duration of the call, amount of data transferred, etc) for use in billing and accounting. For each party to be charged for
parts of or all charges of a chargeable event a separate CDR shall be generated, i.e. more than one CDR may be
generated for a single chargeable event, e.g. because of its long duration, or because more than one charged party is to
be charged.
3GPP
Release 9 15 3GPP TS 32.298 V9.5.0 (2010-10)
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 bearer/session/service control is required.
Editor’s Note: to be completed based on definitions in TS 32.240 [1] and 32.297 [42].
3.2 Symbols
For the purposes of the present document, the following symbols as specified in TS 32.240 [1], TS 32.297 [42],
TS 23.060 [202] and the following apply:
Bx The Interface between a Charging Gateway Function (CGF) and the Billing Domain (BD)
Ga Interface between a node transmitting CDRs (i.e. CDF) and a CDR receiving functionality (CGF)
Gn Interface between two GSNs within the same PLMN.
Gp Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS
network services across areas served by the co-operating GPRS PLMNs.
Rf Offline Charging Reference Point between a Charging Trigger Function (CTF) and the Charging
Data Function (CDF)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP
Release 9 16 3GPP TS 32.298 V9.5.0 (2010-10)
4 Architecture Considerations
The following diagram provides a high level view of the parts of the charging architecture that are relevant for the
present document. The arrows depict the direction of the charging information flow, where Rf carries charging events,
Ga carries CDRs and Bx carries CDR files.
3GPP network
CN Domain
Rf
C C
Service node Ga Bx Billing
D G
F F
Domain
Subsystem
The present document specifies the parameters, abstract syntax and encoding rules for all 3GPP defined CDR types as
applicable to the Bx interface, i.e. the CDR files.
CDF and CGF may or may not be integrated with each others, the core network or service nodes, or the BD.
The possibilities for integration or distribution of these functions are described for each domain, subsystem or service in
the respective domain/subsystem/service specific charging TS. In the distributed case, the 3GPP standardised reference
points/interfaces depicted above, shall be used.
3GPP
Release 9 17 3GPP TS 32.298 V9.5.0 (2010-10)
- the second part specifies the abstract syntax of the CDRs as seen in the CDR files transferred across the Bx
interface.
Each part is further subdivided into a number of subclauses that contain generic, bearer level, service level, and
subsystem level CDR parameters and abstract syntax definitions. Word processing features, such as formatting options,
have also been used to enhance human readability.
The complete set of all CDR syntax definitions is replicated in annex A in a machine processable format. Technically,
the contents of this clause and annex A are completely identical. In case of deviations between this clause and annex A
due to errors in the present document, the annex shall prevail.
Note that the encoding rules for the abstract syntax specified in this clause, are detailed in clause 6.
The MCC and MNC are coded as described for ‘Routing Area Identity’ in TS 29.060 [215].
3GPP
Release 9 18 3GPP TS 32.298 V9.5.0 (2010-10)
It should be noted that the Change of AoC Parms. field is optional and not required if partial records are generated on
tariff switch-over.
The change of service field is optional and may be omitted if partial records are created whenever the basic service is
changed.
In the case of the transit record the GSM basic service employed is generally not available. However, if the device on
which the call originates/terminates is connected via ISDN digital subscriber signalling then the appropriate ISDN basic
service code may be recorded in the record. One possible example includes the direct connection of an ISDN PABX to
an MSC/VLR.
It should be noted that the time stamps may be expressed in terms of tenths of seconds or even milliseconds and, as a
result, the calculation of the call duration may result in the rounding or truncation of the measured duration to a whole
number of seconds.
Whether or not rounding or truncation is to be used is considered to be outside the scope of the present document
subject to the following restrictions:
3GPP
Release 9 19 3GPP TS 32.298 V9.5.0 (2010-10)
2) The same method of truncation/rounding shall be applied to both single and partial records.
If CAMEL is invoked for the call and a control relationship is existing, the call might continue after a RELEASE or a
DISCONNECT from the called party side received by the gsmSSF. The call duration of the incoming leg is stored in the
main body of the call record. For each outgoing leg the call duration is stored in the respective 'CAMELInformation'
module. If a call leg does not reach answer status and attempt charging is enabled a 'CAMELInformation' module
containing the holding time is generated.
An example of how to use the call duration and the timestamps is given in figure 2. It shows a CAMEL controlled
mobile originated follow-on scenario. The uppermost arrow marks the over all duration of the call that is to be
measured and stored in the main body of the respective MOC record. The duration before t5 (incoming leg) or t4
(outgoing leg) needs not to be stored since the call is answered later on. The call duration in the first outgoing leg
module contains the time interval from t4 to t6 (period ). The call duration measurement of the second outleg is started
with t9 and ended with t10 (interval ).
Since the last outgoing leg is not answered, the respective module contains the holding time starting with t11 and ending
with t13 (period ).
(The timestamps t1, t2, t3, t7, t8 and t12 are mentioned for completion reasons only.)
inc. leg
outg. leg 1
outg. leg 2
outg. leg 3
time
t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13
For the avoidance of doubt, there is no global call reference defined within GSM and the call reference field cannot be
used to combine, for example, the MOC and MTC records of a mobile-to-mobile connection.
3GPP
Release 9 20 3GPP TS 32.298 V9.5.0 (2010-10)
The called number is the number received from the mobile station on mobile originated call set-up as defined in
TS 24.008 [208]. Similarly, the calling number is the number received from the network on mobile terminated call set-
up. In case of CAMEL initiated Call Forward (CF), the called (forwarded-to) number is returned by CAMEL.
The translated number is the result of any digit translation performed by the MSC on the called number received from
the mobile station on mobile originated call set-up. This parameter is not included in the CDR if no digit translation has
taken place.
The connected number is the number of the actual party reached as defined in TS 24.008 [208]. Although this is
normally identical to the called number it may differ. This parameter is not included if identical to the called number.
The following examples are intended to explain the use of these fields:
In case of routing to a PABX with Automatic Call Distribution or to an ISDN Basic Access with
several devices attached. The connected number is that of the party actually reached. N.B. The
recording of the actual number connected may be limited by the capability of intermediate
signalling connections.
EXAMPLE 3: MTC record for Call Forwarding ("A" -> "B" -> "C")
In case of call forwarding, the connected number recorded in the MTC record of the "B"
subscriber is that of the forwarded-to party or "C" subscriber. The calling party field contains the
number of the "A" subscriber.
This field is only present if digit translation is applied by the MSC to the called number received
from the mobile station. Examples include abbreviated dialling codes and service numbers.
As a network option, parameters that are identical to the corresponding values in the top level structure of the record are
not recorded again. That means whenever a value is not mentioned in this set the value provided in the basic record is
valid instead. This might lead to an empty or even absent structure, if no parameter was modified.
From the Basic Call State Model (BCSM)'s point of view this field is set to 'CF' whenever the Originating CAMEL
Subscription Information (O_CSI) was applied after terminating CAMEL call processing had been taken place changing
3GPP
Release 9 21 3GPP TS 32.298 V9.5.0 (2010-10)
the call destination. For the avoidance of doubt: this flag does not depend on other modified call parameter(s) (e.g.:
redirection information, etc.) received in the CAP_CONNECT message of the Terminating CAMEL Subscription
Information (T_CSI) service.
This flag also indicates that another record might be generated, one containing the charging information related to the
terminating CAMEL service and one containing the charging information related to the originating CAMEL service.
This field indicates whether or not a CAMEL encounters default SMS handling. This field shall be present
only if default SMS handling has been applied.
This field contains short message Destination Number modified by CAMEL service.
This field contains the SMS Reference Number assigned to the Short Message by the MSC.
- normal release;
3GPP
Release 9 22 3GPP TS 32.298 V9.5.0 (2010-10)
These parameters are only present in the CDRs for HSCSD connections.
5.1.2.1.18 Diagnostics
This field includes a more detailed technical reason for the release of the connection and may contain one of the
following:
The diagnostics may also be extended to include manufacturer and network specific information.
5.1.2.1.19 EMS-Digits
This parameter only applies to location for an emergency services call in North America and gives the North American
Emergency Services Routing Digits as defined in TS 29.002 [214].
5.1.2.1.20 EMS-Key
This parameter only applies to location for an emergency services call in North America and gives the North American
Emergency Services Routing Key as defined in TS 29.002 [214].
5.1.2.1.22 Equipment id
This field contains a local identifier used to distinguish between equipment of the same equipment type e.g. the number
of the conference circuit employed if more than one is available.
3GPP
Release 9 23 3GPP TS 32.298 V9.5.0 (2010-10)
The call records may contain three significant call handling time stamps:
- the time at which the resource in question was seized (Seizure time);
- the time at which the call was answered or at which charging commences (Answer time);
For both Mobile Originated and Mobile Terminated calls, the Seizure time is the time at which the traffic channel is
allocated i.e. the time at which the ASSIGN COMMAND message is sent to the MS.
For Mobile Originated calls the Answer time is the time at which the CONNECT message is sent to the calling party.
For Mobile Terminated calls the time at which the CONNECT message is received from the called party. However, if
the subscriber has subscribed to the advice of charge charging level service, then the answer time shall be derived from
the time at which the FACILITY message is received from the MS containing the acknowledgement of receipt of the
AOC parameters. Similarly, if the AOC parameters are changed during the call then the change time recorded for a
subscriber with AOC charging level is the receipt of the FACILITY message from the MS. For a subscriber with AOC
information level the change time recorded is the time at which the FACILITY is sent to the MS. Finally, in case of call
re-establishment the answer time is the time at which the new traffic channel is allocated by the MSC i.e. when the
ASSIGN COMMAND is sent to the MS.
The Release time is the time at which the connection is released by either party i.e. a DISCONNECT or RELEASE is
sent by the network or a DISCONNECT is received from the MS. In the case of a radio link failure, the release time is
the time at which the failure was detected by the MSC.
For unsuccessful call attempts the Seizure time is mandatory. The Release time is optional and the call duration
recorded is the call holding time i.e. the difference between the two.
For successful calls the Answer time is mandatory and both the Seizure and Release times are optional. The call
duration recorded is the chargeable duration i.e. the difference between the Answer and Release time stamps.
- Loc.Upd. time: The receipt of a MAP_UPDATE_LOCATION_AREA request by the VLR or the receipt of
a MAP_UPDATE_LOCATION request by the HLR;
- SMS-MO: The receipt of an RP_DATA message from the MS containing an SMS_SUBMIT PDU;
It should be noted that the events listed above are only examples in order to demonstrate the principles and that the list
is by no means exhaustive.
3GPP
Release 9 24 3GPP TS 32.298 V9.5.0 (2010-10)
If the FCI is received more then once during one continuing incoming/outgoing CAMEL call leg, the append indicator
defines whether the FCI information is appended to previous FCI and stored in the relevant record or the information of
the last FCI received is stored in the relevant record (the previous FCI information shall be overwritten).
In the event of partial output the currently valid 'Free format data' is stored in the partial record.
If field is missing then free format data in this CDR replaces all received free format data in previous CDRs. Append
indicator is not needed in the first partial record. In following partial records indicator shall get value true if all FCIs
received during that partial record have append indicator. If one or more of the received FCIs for that call leg during the
partial record do not have append indicator then this field shall be missing.
Operator may choose any of the possible values less or equal to wanted AIUR (Air Interface User Rate).
(If WAIUR is less or equal to 14,4 kbit/s then Guaranteed Bit Rate and Maximum Bit Rate shall be set to 14,4 kbit/s).
- the total AIUR (Air Interface User Rate) requested by the MS (for non-transparent HSCSD connections only);
- the maximum number of traffic channels accepted by the MS (this is noted in the channels requested field);
- the channel coding and the number of traffic channels actually used for the call.
In case the network or user initiated modification procedure takes place during the call, the AIUR requested, the channel
coding used and the number of traffic channel requested/used might be recorded in the Change of HSCSD parameters
field including the time at which the change occurred and which entity requested the change.
It should be noted that the Change of HSCSD Parameters field is optional and not required if partial records are
generated when a Change of HSCSD Parameters takes place.
3GPP
Release 9 25 3GPP TS 32.298 V9.5.0 (2010-10)
For 3G, this parameter may not be available. When available, this parameter shall be supplied in the CDRs.
NOTE: This field is only provided if the attempted interrogation was unsuccessful.
- Location update.
- Greylisted;
- Blacklisted;
- Non-whitelisted.
1. Number Portability Data Base (NPDB) returns LRN or NULL response (free of any error).
6. Query rejected
9. No query performed
If the JIP is equal to the LRN, then the JIP query status shall be the same as the LRN query status. If not, this field shall
be set to one of the values listed above.
3GPP
Release 9 26 3GPP TS 32.298 V9.5.0 (2010-10)
- 'Basic' means that CAMEL feature is invoked during the set-up phase (e.g. to modify the destination) of the call
only;
- 'Online charging' means that CAMEL supported AoC parameter were sent to the mobile station (the Send
Charging Information message, SCI, is received from the gsmSCF);
- The flag 'call duration supervision' is set whenever the call duration supervision is applied in the gsmSSF of the
VPLMN (apply charging message is received from the gsmSCF).
The change of location field is optional and not required if partial records are generated when the location changes.
The LAC and CI are both 2 octet quantities and coded according to TS 24.008 [208].
For SMS over SGs (defined in TS 36.413 [226]), the LAC field contains the Tracking Area Code and the Cell Identity
contains the 16 least significant bits.
3GPP
Release 9 27 3GPP TS 32.298 V9.5.0 (2010-10)
If more than 10 digits are received, the first ten digits received are recorded. If fewer than 10 digits are received, the
information is left justified in the field and padded with 0xF.
1. Number Portability Data Base (NPDB) returns LRN or NULL response (free of any error);
5. Query rejected;
9. No query performed;
It is populated if routing information for a ported subscriber is received from one of the methods listed below. It shall be
equal to one of the following enumerated values:
1. LRN NP Database;
2. SwitchingSystemData;
3. Incomingsignaling;
9. Unknown.
to limit the delivered bit-rate to applications or external networks with such limitations,
to allow maximum wanted user bit-rate to be defined for applications able to operate with different rates (e.g.
applications with adapting codecs).]
Maximum bit rate is set to the highest value WAIUR (If WAIUR is less or equal to 14.4 kbit/s then Guaranteed Bit
Rate and Maximum Bit Rate shall be set to 14.4 kbit/s)
3GPP
Release 9 28 3GPP TS 32.298 V9.5.0 (2010-10)
It should be noted that the change of classmark field is optional and not required if partial records are created when the
classmark is altered.
This indication should be used for differentiation between the validity of the record content for T-CSI in the GMSC and
VT-CSI in the VMSC.
3GPP
Release 9 29 3GPP TS 32.298 V9.5.0 (2010-10)
- full rate;
- half rate;
The radio channel used field indicates the type of traffic channel actually employed for the connection i.e. either full
rate (Bm) or half rate (Lm) as described in GSM 05.01 [312]. Any change in the type of channel used may be recorded
in the change of radio channel used field including the time at which the change occurred and the speech version used
after the change of radio channel.
3GPP
Release 9 30 3GPP TS 32.298 V9.5.0 (2010-10)
The format of this field is a single octet with the following format:
Bits 2-3: the Other Rate Adaptation field as defined in TS 24.008 [208];
- subscriber initiated;
- network initiated;
3GPP
Release 9 31 3GPP TS 32.298 V9.5.0 (2010-10)
It should be noted that the change of radio channel field is optional and not required if partial records are generated.
The supplementary services field in the MOC/MTC records contains the codes of the supplementary services invoked
as a result of, or during, a connection.
- registration;
- erasure;
- activation;
- deactivation;
3GPP
Release 9 32 3GPP TS 32.298 V9.5.0 (2010-10)
- interrogation;
- invocation.
The supplementary services field in the MOC/MTC records contains the codes of the supplementary services invoked
as a result of, or during, a connection.
The parameter is provided to the PGW during IP-CAN session establishment/modification, through PCC procedures for
non-3GPP Accesses, as defined in TS 23.203 [203].
Following TS 23.003 [200], the APN field is specified in the CDR by two variable strings. The first is the APN Network
Identifier (NI portion) and the second is the APN Operator Identifier (OI portion). The APN NI may contain one or
more label as described in TS 23.003 [200]. The APN OI is composed of three labels. The first and second labels
together shall uniquely identify the PLMN operator (e.g. "mnc<operator mnc>.mcc<operator mcc>.gprs").
3GPP
Release 9 33 3GPP TS 32.298 V9.5.0 (2010-10)
To represent the APN NI and OI in the PCN CDRs, the "dot" notation shall be used.
See TS 23.003 [200] and TS 23.060 [202] for more information about APN format and access point decision rules.
This field contains the network identifier part of APN before modification by the CSE.
This field contains the operator identifier part of APN before modification by the CSE.
This field contains the Calling Party Number modified by the CAMEL service.
This field contains the short message Destination Number modified by the CAMEL service.
This field contains the SMSC address modified by the CAMEL service.
This field identifies the CAMEL server serving the subscriber. Address is defined in HLR as part of CAMEL
subscription information.
This field identifies the CAMEL service logic applied. Service key is defined in HLR as part of CAMEL
subscription information.
This field indicates whether or not a CAMEL encountered default GPRS- or SMS-handling. This field shall be
present only if default call handling has been applied. Parameter is defined in HLR as part of CAMEL
subscription information.
This field contains charging information sent by the gsmSCF in the Furnish Charging Information GPRS
messages as defined in TS 29.078 [217]. The data can be sent either in one FCI message or several FCI
messages with append indicator. This data is transferred transparently in the CAMEL clauses of the relevant
call records.
If the FCI is received more then once during one CAMEL call, the append indicator defines whether the FCI
information is appended to previous FCI and stored in the relevant record or the information of the last FCI
received is stored in the relevant record (the previous FCI information shall be overwritten).
3GPP
Release 9 34 3GPP TS 32.298 V9.5.0 (2010-10)
In the event of partial output the currently valid "Free format data" is stored in the partial record.
This field contains an indicator whether CAMEL free format data is to be appended to free format data stored in
previous partial CDR. This field is needed in CDR post processing to sort out valid free format data for that
call leg from sequence of partial records. Creation of partial records is independent of received FCIs and thus
valid free format data may be divided to different partial records.
If field is missing then free format data in this CDR replaces all received free format data in previous CDRs.
Append indicator is not needed in the first partial record. In following partial records indicator shall get value
true if all FCIs received during that partial record have append indicator. If one or more of the received FCIs
for that call leg during the partial record do not have append indicator then this field shall be missing.
This field describes briefly the complexity of CAMEL invocation. Categories are the same as in circuit switched
services and measure of resource usage in VPLMN requested by HPLMN.
-"Basic" means that CAMEL feature is invoked during the PDP context activation phase only (e.g. to modify
APN_NI/APN_OI).
-"Call duration supervision" means that PDP context duration or volume supervision is applied in the gprsSSF of
the VPLMN (Apply Charging message is received from the gsmSCF).
This field indicates how many armed CAMEL detection points (TDP and EDP) were encountered and
complements "Level of CAMEL service" field.
This parameter contains the SMS Reference Number assigned to the Short Message by the SGSN.
- normal release: IP-CAN bearer release or detach; It corresponds to "Normal Release" in Change-Condition AVP.
- maximum number of changes in charging conditions; It corresponds to "“Max Number of Changes in Charging
conditions " in Change-Condition AVP.
- For SGSN: intra SGSN intersystem change (change of radio interface from GSM to UMTS or vice versa);
- For P-GW and S-GW: Radio Access Technology (RAT) change; It corresponds to "RAT Change" in Change-
Condition AVP.
- SGSN or S-GW PLMN change; It corresponds to "Serving Node PLMN Change" in Change-Condition AVP.
3GPP
Release 9 35 3GPP TS 32.298 V9.5.0 (2010-10)
- management intervention (request due to O&M reasons); It corresponds to " Management Intervention" in
Change-Condition AVP.
The functional requirements for the Charging Characteristics are further defined in normative Annex A of TS
32.251 [11], including an example for the definitions of the trigger profiles associated with each CDR type.
The format of charging characteristics field is depicted in Figure 4. Each Bx (x =0..15) refers to a specific behaviour
defined on a per-Operator basis, indicated as active when set to “1” value. See Annex A of TS 32.251 [11] for guidance
on how behaviours could be defined.
Bits
Octets 7 6 5 4 3 2 1 0
1 B7 B6 B5 B4 B3 B2 B1 B0
3GPP
Release 9 36 3GPP TS 32.298 V9.5.0 (2010-10)
- Home default;
- Visiting default;
- Roaming default;
- APN specific;
- Subscription specific.
- Home default;
- Visiting default;
- Roaming default;
- Serving node supplied.
NOTE: The value 'Serving Node Supplied' is used if the CC what was received from e.g. S-GW is used i.e. the one
what comes during bearer activation.
5.1.2.2.9 Charging ID
This field is a charging identifier, which can be used together with P-GW address to identify all records produced in
SGSN(s), S-GW and P-GW involved in a single IP-CAN bearer. Charging ID is generated by P-GW at IP-CAN bearer
activation and transferred to bearer requesting SGSN/S-GW. At inter-SGSN/S-GW change the charging ID is
transferred to the new SGSN/S-GW as part of each active IP-CAN bearer.
Different P-GWs allocate the charging ID independently of each other and may allocate the same numbers.
The CGF and/or BS may check the uniqueness of each charging ID together with the P-GWs address and optionally
(if still ambiguous) with the record opening time stamp.
5.1.2.2.11 Diagnostics
This field includes a more detailed technical reason for the releases of the connection refer TS 32.250 [10]. The
diagnostics may also be extended to include manufacturer and network specific information.
5.1.2.2.12 Duration
This field contains the relevant duration in seconds for IP-CAN bearer (S-CDR, SGW-CDR, PGW-CDR, and
attachment (M-CDR).
It is the duration from Record Opening Time to record closure. For partial records this is the duration of the individual
partial record and not the cumulative duration.
It should be noted that the internal time measurements may be expressed in terms of tenths of seconds or even
milliseconds and, as a result, the calculation of the duration may result in the rounding or truncation of the measured
duration to a whole number of seconds.
Whether or not rounding or truncation is to be used is considered to be outside the scope of the present document
subject to the following restrictions:
1) A duration of zero seconds shall be accepted providing that the transferred data volume is greater than zero.
2) The same method of truncation/rounding shall be applied to both single and partial records.
3GPP
Release 9 37 3GPP TS 32.298 V9.5.0 (2010-10)
When inter-working with IMS the external charging identifier is the ICID (IMS Charging IDentifier) as
received from the IMS network by the P-GW;
If required, Inter-working with other external entities will be subject of specification for further releases.
3GPP
Release 9 38 3GPP TS 32.298 V9.5.0 (2010-10)
AF-Record-Information
Charging Rule Base Name
Data Volume Downlink
Data Volume Uplink
Event Based Charging Information
Local Sequence Number
PS Furnish Charging Information
Qos Information
Rating Group
Report Time
Result Code
Service Condition Change
Service Identifier
Service Specific Info
Serving Node Address
Time of First Usage
Time of Last Usage
Time Quota Mechanism
Time Usage
user location information
3GPP2 User Location Information
Rating Group is the identifier of rating group. This field is mandatory. The parameter corresponds to the Charging Key
as specified in TS 23.203 [203].
Charging Rule Base Name is the reference to group of PCC rules predefined at the PCEF. This field is included if any
of the PCC rules, which usage is reported within this service data container, was activated by using the Charging Rule
Base Name as specified in TS 29.212 [220]. In case multiple Charging Rule Base Names activate PCC rules, which
usage is reported within this service data container, the P-GW shall include only one occurrence to the service data
container.
Result Code contains the result code after the interconnection with the OCS. This field may be added to the service
data container if online and offline charging are both used for same rating group. The result code in service data
container is the value of the Result-Code AVP received within last CCA message in corresponding MSCC AVP to
this service data container.
Local Sequence Number is a service data container sequence number. It starts from 1 and is increased by 1 for each
service date container generated within the lifetime of this IP-CAN bearer.
Time of First Usage is the time stamp for the first IP packet to be transmitted and mapped to the current service data
container. For envelope reporting controlled by the Time Quota Mechanism, this indicates the time stamp for the first IP
packet to be transmitted that causes an envelope to be opened – see TS 32.299 [50].
Time of Last Usage is the time stamp for the last IP packet to be transmitted and mapped to the current service data
container. For envelope reporting, controlled by the Time Quota Mechanism, this indicates the time stamp for an
envelope to be closed – see TS 32.299 [50] for conditions for envelope closure.
Time Usage contains the effective used time within the service data container recording interval.
Service Condition Change defines the reason for closing the service data container (see TS 32.251 [11]), such as tariff
time change, IP-CAN bearer modification(e.g. QoS change, S-GW change, user location change), service usage
thresholds, service idled out, termination or failure handling procedure. When one of the “CGI/SAI, ECGI or TAI or
RAI Change” are reported as user location change, the dedicated value in service Condition Change is set instead of the
generic “user location change” value. This field is specified as bitmask for support of multiple change trigger (e.g. S-
GW and QoS change). This field is derived from Change-Condition AVP at Service-Data-Container AVP level defined
in TS 32.299 [40] when received on Rf. Each value is mapped to the corresponding value in “ServiceConditionChange”
field. When simultaneous change triggers are met, multiple Change-Condition values are set in field bitmask.When no
3GPP
Release 9 39 3GPP TS 32.298 V9.5.0 (2010-10)
Change-Condition AVP is provided, the “recordClosure” value is set for the service data container. For envelope
reporting, the Service Condition Change value shall always take the value "envelopeClosure". The mechanism for
creating the envelope is identified within the Time Quota Mechanism field.
Qos Information in IP CAN bearer specific service data container contains the negotiated QoS applied for the IP CAN
bearer. QoS Information in service specific service data containers contains the QoS applied for the service. This is
included in the first service data container. In following container QoS information is present if previous change
condition is "QoS change". The P-GW shall include only one QoS Information occurrence to one service data container.
Serving Node Address contains the valid serving node (e.g.SGSN/S-GW) control plane IP address during the service
data container recording interval.
Data Volume Uplink and Downlink, includes the number of octets transmitted during the service data container
recording interval in the uplink and/or downlink direction, respectively.
Report Time is a time stamp, which defines the moment when the service data container is closed.
Service Identifier is an identifier for a service. The service identifier may designate an end user service, a part of an
end user service or an arbitrarily formed group thereof. This field is only included if reporting is per combination of the
rating group and service id.
PS Furnish Charging Information includes charging information per rating group in case it is sent by OCS.
User location information contains the user location (e.g. CGI/SAI, ECGI/TAI or RAI) where the UE was located
during the service data container recording interval. This is included in the service data container only if previous
container’s change condition is "user location change" or one of the “CGI/SAI, ECGI or TAI or RAI Change”. Note the
user location information in PGW-CDR main level contains the location where the UE was when PGW-CDR was
opened.
3GPP2 User Location Information contains the 3GPP2 user location (i.e. 3GPP2-BSID: Cell-Id, SID, NID) where the
UE was located during the service data container recording interval. This is included in the service data container only if
previous container’s change condition is "user location change". Note the “3GPP2 user location information” in PGW-
CDR main level contains the location where the UE was when PGW-CDR was opened.
AF-Record-Information includes the "AF Charging Identifier" (ICID for IMS) and associated flow identifiers
generated by the AF and received by the P-GW over Gx interfaces as defined in TS 29.212 [220]. In case usage of PCC
rules, which usage is reported within the container, has different AF-Record-Information then the P-GW shall include
only one occurrence to the service data container.
Event Based Charging Information includes the number of events and associated timeStamps (each event is
timestamped) during the service data container recording interval.
Time Quota Mechanism contains two further subfields and is included if envelope reporting is required:
Time Quota Type identifies the mechanism by which time based usage should be reported – as defined
in TS 32.299 [50].
Base Time Interval identifies the length of the base time interval, for controlling the reporting of time based usage,
in seconds.
Service Specific Info holds service specific data for a pre-defined PCC rule that is used for enhanced packet filtering.
In SGW-CDR containers are per QCI/ARP pair. This means that if QoS control within one IP-CAN bearer is applicable
in S-GW, there can be several containers open at same time one per each applied QCI/ARP pair.
Data Volume Uplink, Data Volume Downlink, Change Condition and Change Time.
Data Volume Uplink includes the number of octets transmitted during the use of the packet data services in the uplink
direction. In MBMS charging, this field is normally to be set to zero, because MBMS charging is based on the volume
3GPP
Release 9 40 3GPP TS 32.298 V9.5.0 (2010-10)
of the downlink data. The counting of uplink data volumes is optional. In S-CDR this field is not present when the
SGSN has successfully established Direct Tunnel between the RNC and the GGSN.
Data Volume Downlink includes the number of octets transmitted during the use of the packet data services in the
downlink direction. In S-CDR this field is not present when the SGSN has successfully established Direct Tunnel
between the RNC and the GGSN.
Change Condition defines the reason for closing the container (see TS 32.251 [11]), such as tariff time change, QoS
change or closing of the CDR. . This field is derived from Change-Condition AVP Traffic-Data-Volumes AVP level
defined in TS 32.299 [40] when received on Rf. Each value is mapped to the corresponding value in
“ChangeCondition” field. When no Change-Condition AVP is provided, the “recordClosure” value is set for the
container. For User Location Change, when one of the “CGI/SAI, ECGI or TAI or RAI Change” are reported as user
location change, the dedicated value in service Condition Change is set instead of the generic “user location change”
value.
Change Time is a time stamp, which defines the moment when the volume container is closed or the CDR is closed.
All the active IP-CAN bearers do not need to have exactly the same time stamp e.g. due to same tariff time change
(variance of the time stamps is implementation and traffic load dependent, and is out of the scope of standardisation).
User Location Information contains the location (e.g. CGI/SAI, ECGI/TAI or RAI) where the UE is located and used
during the transfer of the data volume captured by the container (applicable only to the SGW-CDR). This is included in
the Traffic data container only if previous container’s change condition is "user location change". Note the user location
information in SGW-CDR main level contains the location where the UE was when PGW-CDR was opened.
EPC QoS Information In case of IP-CAN bearer specific container this contains authorized QoS for the IP-CAN
bearer. First container for each QCI/ARP pair includes this field. In following containers this field is present if previous
change condition is "QoS change". This field is applicable only in SGW-CDR.
In S-CDR first container includes following optional fields: QoS Requested and QoS Negotiated. In following
containers QoS Negotiated is present if previous change condition is "QoS change". In addition to the QoS Negotiated
parameter the QoS Requested parameter is present in following containers if the change condition is "QoS change" and
the QoS change was initiated by the MS via a IP-CAN bearer modification procedure.
Table 5.1.2.2.23.1 illustrates an examplefor S-CDR but same principles are applicable also for SGW-CDR. There are
five containers (sets of volume counts) caused by one QoS change, one location change, one tariff time change and one
Direct Tunnel establishment (direct tunnel change applicable in S-CDR only). When CDR is opened the subscriber is in
CGI1.
First container includes initial QoS values and corresponding volume counts. Second container includes new QoS
values and corresponding volume counts before tariff time change. Third container includes the indication of location
3GPP
Release 9 41 3GPP TS 32.298 V9.5.0 (2010-10)
change and corresponding volume counts before the location change and after the tariff time change. Fourth container
includes volume counts after the location change and contains the indication of Direct Tunnel establishment. Last
container includes no volume count as it refers to Direct Tunnel establishment. The total volume counts can be itemised
as shown in Table 5.1.2.2.23.2 (tariff1 is used before and tariff2 after the tariff time change):
Table 5.1.2.2.23.2: Itemised list of total volume count corresponding to Table 5.1.2.2.23.1
Container
QoS1+Tariff1 uplink = 1, downlink = 2 1
QoS2+Tariff1 uplink = 5, downlink = 6 2
QoS2+Tariff2 uplink = 13, downlink = 7 3+4
QoS1 uplink = 1, downlink = 2 1
QoS2 uplink = 18, downlink = 13 2+3+4
Tariff1 uplink = 6, downlink = 8 1+2
Tariff2 uplink = 13, downlink = 7 3+4
CGI1 uplink = 16, downlink = 11 1+2+3
CGI2 uplink = 3, downlink = 4 4
No Direct Tunnel uplink = 19, downlink = 15 1+2+3+4
Direct Tunnel -, - 5
The amount of data counted in the S-GW shall be the payload of the user plane at the S1-U/S4/S2interface. Therefore
the data counted already includes the IP PDP bearer protocols i.e. IP or PPP.
The data volume counted in the SGSN is dependent on the system. For GSM SGSN the data volume is the payload of
the SNDCP PDUs at the Gb interface. For UMTS-SGSN it is the GTP-U PDUs at the Iu-PS interface. Therefore, in
both systems, the data counted already includes the overheads of any PDP bearer protocols.
In GSM, in order to avoid that downstream packets transmitted from the old SGSN to the new SGSN at inter SGSN RA
update induce the increase of the PDP CDR downstream volume counters in both SGSN the following rules must be
followed:
- For PDP contexts using LLC in unacknowledged mode: an SGSN shall update the PDP CDR when the packet
has been sent by the SGSN towards the MS;
For PDP contexts using LLC in acknowledged mode, a GSM-SGSN shall only update the PDP CDR at the
reception of the acknowledgement by the MS of the correct reception of a downstream packet. In other worlds,
for inter SGSN RA update, the new SGSN shall update the PDP CDR record when a downstream packet sent by
the old SGSN is received by the MS and acknowledged by the MS towards the new SGSN through the RA
update complete message.
In UMTS, the not transferred downlink data can be accounted for in the S-CDR with "RNC Unsent Downlink Volume"
field, which is the data that the RNC has either discarded or forwarded during handover. Data volumes retransmitted (by
RLC or LLC) due to poor radio link conditions shall not be counted.
The field can be used e.g. to identify missing records in post processing system.
3GPP
Release 9 42 3GPP TS 32.298 V9.5.0 (2010-10)
5.1.2.2.36 Node ID
This field contains an optional, operator configurable, identifier string for the node that had generated the CDR.
The Node ID may or may not be the DNS host name of the node.
The MCC and MNC are coded as described for “User Location Info” in TS 29.274 [223].
- TS 29.060 [215] for exact format of PDP type for GTP case,
3GPP
Release 9 43 3GPP TS 32.298 V9.5.0 (2010-10)
This field contains charging information sent by the OCS in the Diameter Credit Control Credit-Control-Answer
messages as defined in TS 32.251 [11]. The data can be sent either in one Diameter Credit Control Credit-
Control-Answer message or several Diameter Credit Control Credit-Control-Answer messages with append
indicator. This data is transferred transparently in the PS Furnish Charging Information field of the relevant call
records.
If the PS Free Format Data is received more than once during one IP-CAN bearer for which an offline session is
established, the append indicator defines whether the PS Free Format Data is appended to previous received PS
Free Format Data and stored in the relevant record or the information of the last PS Free Format Data received is
stored in the relevant record (the previous PS Free Format Data information shall be overwritten).
In the event of partial output the currently valid "PS Free format data" is stored in the partial record.
This field contains an indicator whether PS free format data is to be appended to the PS free format data stored in
previous partial CDR. This field is needed in CDR post processing to sort out valid PS free format data for that
IP-CAN bearer from sequence of partial records. Creation of partial records is independent of received PS Free
Format Data and thus valid PS free format data may be divided to different partial records.
If field is missing then the PS free format data in this CDR replaces all received PS free format data in previous
CDRs. Append indicator is not needed in the first partial record. In following partial records indicator shall get
value true if all PS Free Format Data received during that partial record have append indicator. If one or more of
the received PS Free Format Data for that PDP Context during the partial record do not have append indicator
then this field shall be missing.
If a pre-Release '99 only capable terminal is served, the applicable QoS parameters and their encoding in the CDRs are
specified in TS 32.015 [228].
In all other cases, the applicable QoS attributes are defined in the "Quality of Service profile" in TS 23.060 [202], and
their encoding in the CDR corresponds to the "Quality of Service profile" specified in TS 29.060 [215].
3GPP
Release 9 44 3GPP TS 32.298 V9.5.0 (2010-10)
The field is provided by the SGSN/MME and transferred to the S-GW/P-GW during the IP-CAN bearer
activation/modification.
Record opening reason does not have a separate field. For SGW/PGW-CDRs and M-CDR it can be derived from the
field "Sequence number"; i.e. either a missing field or a value one (1) means activation of IP-CAN bearer (SGW/PGW-
CDR) or GPRS attachment (M-CDR). For the S-CDR the field "SGSN change" also needs to be taken into account.
The location field contains a combination of the location area code (LAC), cell identity (CI) and MCC+MNC of the cell
in which the served party is currently located.
The change of location field is optional and not required if partial records are generated when the location changes.
The RAC and (optionally) CI are coded according to 3G TS 24.008 [208] and the SAC according TS 25.413 [212].
3GPP
Release 9 45 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 46 3GPP TS 32.298 V9.5.0 (2010-10)
If both an IPv4 and an IPv6 address of the SGSN/S-GW/MME/ePDG/HSGW are available, the S-GW/P-GW shall
include the IPv4 address in the CDR.
The MCC and MNC are coded as described for ‘Routing Area Identity’ in TS 29.060 [75].
The M-CDR fields only contain the address of the current SGSN.
If both an IPv4 and an IPv6 address of the SGSN are available, the SGSNs shall include the IPv4 address in the CDR.
- TS 29.274 [223] for eGTP case (e.g. CGI, SAI, RAI TAI and ECGI) and
3GPP
Release 9 47 3GPP TS 32.298 V9.5.0 (2010-10)
The field is provided by the SGSN/MME and transferred to the S-GW/P-GW during the IP-CAN bearer
activation/modification.
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.
3GPP
Release 9 48 3GPP TS 32.298 V9.5.0 (2010-10)
- partial record generation: time (duration) limit, maximum number of changes in charging conditions (e.g.
maximum number in 'List of Message Bodies' exceeded) or service change (e.g. change in media components);
- abnormal termination;
A more detailed reason may be found in the Service Reason Return Code field.
5.1.3.1.15 Event
The Event parameter holds the content of the "Event" header defined in RFC 3265 [403],
5.1.3.1.16 Expires
The Expires parameter holds the content of the "Expires" header.
For further information regarding the composition of the charging correlation vector refer to the appropriate clause in
TS 32.240 [1].
3GPP
Release 9 49 3GPP TS 32.298 V9.5.0 (2010-10)
The ICID value is globally unique across all 3GPP IMS networks for a time period of at least one month, implying that
neither the node that generated this ICID nor any other IMS node reuse this value before the uniqueness period expires.
The one month minimum uniqueness period counts from the time of release of the ICID, i.e. the ICID value no longer
being used. This can be achieved by using node specific information, e.g. high-granularity time information and/or
topology/location information. The exact method how to achieve the uniqueness requirement is an implementation
issue.
At each SIP session unrelated method, both initial and subsequent (e.g., REGISTER, NOTIFY, MESSAGE etc.), a new,
session unrelated ICID is generated at the first IMS network element that processes the method. This ICID value is
contained in the SIP request and response of that SIP transaction and must be valid for the duration of the transaction.
At each SIP session establishment a new, session specific ICID is generated at the first IMS network element that
processes the session-initiating SIP INVITE message. This ICID is then used in all subsequent SIP messages for that
session (e.g., 200 OK, (re-)INVITE, BYE etc.) until the session is terminated.
These address/addresses are 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 shall be present when the P-Asserted-Identity SIP header field is available in the SIP 2xx response.
This field applies only to SIP session related cases, but it may be present both in event CDRs (unsuccessful session
establishment) and session CDRs (successful session establishment).
3GPP
Release 9 50 3GPP TS 32.298 V9.5.0 (2010-10)
The List of Early SDP Media Components contains the following elements:
Content Type;
Content Disposition;
Content Length;
Originator.
They are described in the appropriate subclause. Message bodies with the "Content-Type" field set to application/sdp
and the "Content-Disposition" field set to session are not included in the "Message Bodies" field.
3GPP
Release 9 51 3GPP TS 32.298 V9.5.0 (2010-10)
The field can be used e.g. to identify missing records in post processing system.
5.1.3.1.35 Originator
This sub-field of the "List of Message Bodies" indicates the originating party of the message body.
The Real Time Tariff Information contains one of the following elements:
Tariff XML;
Tariff Information.
3GPP
Release 9 52 3GPP TS 32.298 V9.5.0 (2010-10)
5.1.3.1.44 Retransmission
This parameter, when present, indicates that information from retransmitted Diameter ACRs has been used in this CDR.
3GPP
Release 9 53 3GPP TS 32.298 V9.5.0 (2010-10)
This field holds the attributes of the media as available in the session related part of the SDP data tagged with "c=" and
"a=" (multiple occurrence possible). Only attribute lines relevant for charging are recorded.
The content of this field corresponds to the SDP-Session-Description AVP of the ACR message.
The content of this field corresponds to the SIP-Request-Timestamp AVP of a received ACR[Stop] message indicating a
session termination.
- a successful session set-up: this field holds the start time of a service delivery (session related service)
- a delivery of a session unrelated service: the service delivery time stamp
- an unsuccessful session set-up and an unsuccessful session unrelated request: this field holds the time the network
entity forwards the unsuccessful indication (SIP "RESPONSE" with error codes 3xx, 4xx, 5xx) towards the
requesting User direction.
The content of this field corresponds to the SIP-Response-Timestamp AVP as defined in Table 5.8.
3GPP
Release 9 54 3GPP TS 32.298 V9.5.0 (2010-10)
5.1.3.1.56 Service ID
This field identifies the service the MRFC is hosting. For conferences the conference ID is used here.
This field is present for unsuccessful service requests if the ACR message includes the SIP-Request-Timestamp AVP.
5.1.3.1.59 Session ID
The Session identification. For a SIP session the Session-ID contains the SIP Call ID as defined in the Session Initiation
Protocol RFC 3261 [401]. When the AS acts as B2BUA, the incoming Session-ID leg is covered.
3GPP
Release 9 55 3GPP TS 32.298 V9.5.0 (2010-10)
The Charged Party is an indication on which party is expected to be charged for an MM e.g. the sending, receiving, both
parties or neither. This indicator is only applicable to MM7 CDRs (for VASP-originated MMs). It may be provided by
the VASP when submitting an MM.
The Charge Type indicates the type of subscription (i.e. postpaid or prepaid). This indicator is derived from the
subscription parameters and only applicable to MM1 CDRs.
- Sender: This indicates the sending party is expected to be charged ('normal' charging model);
- Recipient: This indicates the receiving party is expected to be charged ('reverse' charging model). This model
implies there is a commercial agreement between the Recipient and the VASP;
3GPP
Release 9 56 3GPP TS 32.298 V9.5.0 (2010-10)
- Both: This indicates both the sending and the receiving parties are expected to be charged ('shared' charging
model);
- Neither: This indicates neither the sending nor the receiving parties are expected to be charged ('free of charge'
charging model).
- Postpaid;
- Prepaid.
Note that the CDRs purposely do not contain any information about the duration of storage on the MMS Relay/Server.
If such information is required it can be calculated by post-processing systems from the CDR timestamps. For instance,
the total duration of storage on the originator MMS Relay/Server could be calculated by taking the difference between
the ‘Record Time Stamp’ of the O1S-CDR and the ‘Record Time Stamp’ of the OMD-CDR.
5.1.4.1.14 Limit
This field contains a number that may be provided in the MM1_mmbox_view.REQ to specify a limit for the number of
MMs the information elements to which shall be returned in the MM1_mmbox_view.RES.
5.1.4.1.15 Linked ID
This field identifies a correspondence to a previous valid message delivered to the VASP
The field can be used e.g. to identify missing records in post processing system.
3GPP
Release 9 57 3GPP TS 32.298 V9.5.0 (2010-10)
5.1.4.1.20 Message ID
This field specifies the MM Message ID of the MM as defined in TS 23.140 [206]. The concrete syntax of this MM
Message ID is given by the body of the field introduced by the string "X-Mms-Message-ID:" in the concrete syntax of
the message MM4_Forward.REQ. All CDRs pertaining to the same MM must employ the same value of this parameter,
i.e. the value initially assigned by the originator MMS Relay/Server upon submission of the MM by the Originator
MMS User Agent.
MM State;
MM Flags:
Store Status:
This field contains an appropriate status value of the stored MM, e.g. stored, error-transient-mailbox-full,…
This field includes a more detailed technical description of the store status at the point in time when the CDR
is generated.
3GPP
Release 9 58 3GPP TS 32.298 V9.5.0 (2010-10)
5.1.4.1.27 MM Listing
This field contains a list of information elements from the MMs returned within the MM1_mmbox_view.RES. The
listing shall consist of the following information elements, separately grouped for each MM returned in the list:
Information elements corresponding to those requested in the Message Selection information element on the
MM1_mmbox_view.REQ.
Billing Information;
5.1.4.1.32 Priority
The priority (importance) of the message, see TS 23.140 [206].
5.1.4.1.33 Quotas
The quotas of the MMBox in messages and/or octets identified with Messages or Octets
3GPP
Release 9 59 3GPP TS 32.298 V9.5.0 (2010-10)
In the Originator MM1 Submission CDR (O1S-CDR) this parameter indicates whether the originator MMS User Agent
has requested reply-charging (value TRUE) or not (value FALSE).
In the Recipient MM1 Notification Request record (R1NRq -CDR) it indicates whether a reply to this particular original
MM is free of charge (value TRUE) or not (value FALSE).
In the MM7 Submission CDR (7S-CDR) this parameter indicates whether the originator MMS VASP has requested
reply-charging (value TRUE) or not (value FALSE).
In the Recipient MM1 Notification Request CDR (R1NRq-CDR), in case of reply-charging, this field indicates the
maximum size of a reply-MM granted to the recipient as specified in the MM1_notification.REQ.
In the MM7 Submission CDR (7S-CDR), in case of reply-charging, this field indicates the maximum size for reply-
MM(s) granted to the recipient(s) as specified by the originator MMS VASP.
In the Recipient MM1 Notification Request CDR (R1NRq-CDR), in case of reply-charging, this field indicates the
latest time of submission of a reply granted to the recipient as specified in the MM1_notification.REQ.
3GPP
Release 9 60 3GPP TS 32.298 V9.5.0 (2010-10)
In the MM7 Submission CDR (7S-CDR), in case of reply-charging, this field indicates the latest time of submission of
replies granted to the recipient(s) as specified by the originator MMS VASP.
5.1.4.1.54 Start
This field contains a number that may be used in the MM1_mmbox_view.REQ to index the first MM to be viewed,
relative to the selected set of MMs, allowing partial views to be requested
5.1.4.1.58 Totals
The total number of messages and/or octets for the MMBox, identified with Messages or Octets
3GPP
Release 9 61 3GPP TS 32.298 V9.5.0 (2010-10)
5.1.4.1.61 VAS ID
This field specifies the identification of the VASP as defined in TS 23.140 [206].
5.1.4.1.62 VASP ID
This field specifies the identification of the originating application as defined in TS 23.140 [206].
3GPP
Release 9 62 3GPP TS 32.298 V9.5.0 (2010-10)
In case of multi-numbering the MSISDN stored in a LCS CDR will be the primary MSISDN of the requesting party.
- System Failure;
- Data Missing;
- Unidentified Subscriber;
- Illegal Subscriber;
- Illegal Equipment;
3GPP
Release 9 63 3GPP TS 32.298 V9.5.0 (2010-10)
Change Condition
Change Time
Number of participants
Number of received talk bursts
Number of talk bursts
Received talk burst volume
Received talk bursts time
Talk burst volume
Talk bursts time
Number of talk bursts and Number of received talk bursts indicate the number of talk bursts sent and received
respectively by the charged party (for the participating PoC functions) or for the whole session (for the controlling PoC
function).
Talk burst volume and Received talk burst volume indicate the total data volume for talk bursts sent and received
respectively by the charged party (for the participating PoC functions) or for the whole session (for the controlling PoC
function).
Talk burst Time and Received talk burst time indicate the total duration of talk bursts sent and received respectively
by the charged party (for the participating PoC functions) or for the whole session (for the controlling PoC function).
Change Time is a time stamp, which defines the moment when the container is closed or the CDR is closed.
Change Condition indicates the reason for closing the container and the addition of a new container.
Number of participants indicates the number of attached participants involved in the talk burst exchange within a
container.
The field is of type grouped. It contains the participant address (Called party address), the participant access priority and
User Participating Type.
3GPP
Release 9 64 3GPP TS 32.298 V9.5.0 (2010-10)
0 Pre-established
1 On-demand
5.1.4.4.8 TMGI
The field contains the Temporary Mobile Group Identity allocated to a particular MBMS bearer service. TMGI use and
structure is specified in TS 23.003 [200].
3GPP
Release 9 65 3GPP TS 32.298 V9.5.0 (2010-10)
Service Type;
Service Mode;
Number Of Diversions;
Service ID
Change Time
Number Of Participants
Change Time is a time stamp, which defines the moment when the conference participant has an action (e.g. creating
the conference, joining in the conference, being invited into the conference or quiting the conference) triggering the
Accounting Request message to CDF in MMTel Charging.
Number Of Participants indicates the number of attached participants involved in the conference.
Participant Action Type indicates the participant’s action type during the conference. It’s just for Billing Domain’s
information in each CDR, e.g. creating the conference, joining in the conference, being invited into the conference and
quiting the conference.CUG Information indicates the “CUG interlock code” used during the “Closed User Group”
communication.
Service Mode values 1024 are reserved for specific Network/Manufacturer variants.
Service Type values 1024 are reserved for specific Network/Manufacturer variants
3GPP
Release 9 66 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 67 3GPP TS 32.298 V9.5.0 (2010-10)
BEGIN
-- EXPORTS everything
IMPORTS
CallReferenceNumber, NumberOfForwarding
FROM MAP-CH-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1)
modules (3) map-CH-DataTypes (13) version6 (6) }
-- from TS 29.002 [214]
DestinationRoutingAddress
FROM CAP-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0)
gsm-Network (1) modules (3) cap-datatypes (52) version1 (0) }
-- from TS 29.078 [217]
PositionMethodFailure-Diagnostic, UnauthorizedLCSClient-Diagnostic
FROM MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1)
modules (3) map-ER-DataTypes (17) version7 (7)}
--
-- from TS 29.002 [214]
--
BasicService
FROM Basic-Service-Elements { itu-t identified-organization (4) etsi (0)
196 basic-service-elements (8) }
--
-- from "Digital Subscriber Signalling System No. one (DSS1) protocol" ETS 300 196 [310]
--
ObjectInstance
FROM CMIP-1 {joint-iso-itu-t ms (9) cmip (1) version1 (1) protocol (3)}
--
-- from Rec. X.2ab[304] Editor’s note: clarify if this definition is still needed. It appears
that it ends in Nirvana.
ManagementExtension
FROM Attribute-ASN1Module {joint-iso-itu-t ms (9) smi (3) part2 (2) asn1Module (2) 1}
--
-- from Rec. X.721 [305] Editor’s note: clarify if this definition is still needed.
--
AE-title
FROM ACSE-1 {joint-iso-itu-t association-control (2) abstract-syntax (1) apdus (0) version (1) };
--
-- From Rec. X.2cd[306]. Note that the syntax of AE-title to be used is from
3GPP
Release 9 68 3GPP TS 32.298 V9.5.0 (2010-10)
Editor’s note: the explanation above should be removed as proper definitions are required in the
individual CDR parameter descriptions in TS 32.250[10] – TS 32.275 [35]
moCallRecord (0),
mtCallRecord (1),
roamingRecord (2),
incGatewayRecord (3),
outGatewayRecord (4),
transitCallRecord (5),
moSMSRecord (6),
mtSMSRecord (7),
moSMSIWRecord (8),
mtSMSGWRecord (9),
ssActionRecord (10),
hlrIntRecord (11),
locUpdateHLRRecord (12),
locUpdateVLRRecord (13),
commonEquipRecord (14),
moTraceRecord (15), --- used in earlier releases
mtTraceRecord (16), --- used in earlier releases
termCAMELRecord (17),
--
-- Record values 18..22 are GPRS specific.
-- The contents are defined in TS 32.251 [11]
--
sgsnPDPRecord (18),
sgsnMMRecord (20),
sgsnSMORecord (21),
sgsnSMTRecord (22),
--
-- Record values 23..25 are CS-LCS specific.
-- The contents are defined in TS 32.250 [10]
--
mtLCSRecord (23),
moLCSRecord (24),
niLCSRecord (25),
--
-- Record values 26..28 are GPRS-LCS specific.
-- The contents are defined in TS 32.251 [11]
3GPP
Release 9 69 3GPP TS 32.298 V9.5.0 (2010-10)
--
sgsnMtLCSRecord (26),
sgsnMoLCSRecord (27),
sgsnNiLCSRecord (28),
--
-- Record values 30..62 are MMS specific.
-- The contents are defined in TS 32.270 [30]
--
mMO1SRecord (30),
mMO4FRqRecord (31),
mMO4FRsRecord (32),
mMO4DRecord (33),
mMO1DRecord (34),
mMO4RRecord (35),
mMO1RRecord (36),
mMOMDRecord (37),
mMR4FRecord (38),
mMR1NRqRecord (39),
mMR1NRsRecord (40),
mMR1RtRecord (41),
mMR1AFRecord (42),
mMR4DRqRecord (43),
mMR4DRsRecord (44),
mMR1RRRecord (45),
mMR4RRqRecord (46),
mMR4RRsRecord (47),
mMRMDRecord (48),
mMFRecord (49),
mMBx1SRecord (50),
mMBx1VRecord (51),
mMBx1URecord (52),
mMBx1DRecord (53),
mM7SRecord (54),
mM7DRqRecord (55),
mM7DRsRecord (56),
mM7CRecord (57),
mM7RRecord (58),
mM7DRRqRecord (59),
mM7DRRsRecord (60),
mM7RRqRecord (61),
mM7RRsRecord (62),
--
-- Record values 63..69, 70, 82 are IMS specific.
-- The contents are defined in TS 32.260 [20]
--
sCSCFRecord (63),
pCSCFRecord (64),
iCSCFRecord (65),
mRFCRecord (66),
mGCFRecord (67),
bGCFRecord (68),
aSRecord (69),
eCSCFRecord (70),
iBCFRecord (82),
--
-- Record values 71..75 are LCS specific.
-- The contents are defined in TS 32.271 [31]
--
lCSGMORecord (71),
lCSRGMTRecord (72),
lCSHGMTRecord (73),
lCSVGMTRecord (74),
lCSGNIRecord (75),
--
-- Record values 76..79 are MBMS specific.
-- The contents are defined in TS 32.251 [11]
-- Record values 76 and 77 are MBMS bearer context specific
--
sgsnMBMSRecord (76),
ggsnMBMSRecord (77),
--
-- And TS 32.273 [33]
-- Record values 78 and 79 are MBMS service specific
-- and defined in TS 32.273 [33]
--
sUBBMSCRecord (78),
cONTENTBMSCRecord (79),
--
3GPP
Release 9 70 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 71 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 72 3GPP TS 32.298 V9.5.0 (2010-10)
{
serviceSpecificData [0] GraphicString OPTIONAL,
serviceSpecificType [1] INTEGER OPTIONAL
}
END
3GPP
Release 9 73 3GPP TS 32.298 V9.5.0 (2010-10)
BEGIN
-- EXPORTS everything
IMPORTS
BearerServiceCode
FROM MAP-BS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1)
modules (3) map-BS-Code (20) version6 (6) }
-- from TS 29.002 [214]
TeleserviceCode
FROM MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1)
modules (3) map-TS-Code (19) version2 (2) }
-- from TS 29.002 [214]
SS-Code
FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1)
modules (3) map-SS-Code (15) version6 (6) }
-- from TS 29.002 [214]
MOLR-Type
FROM SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Access (2)
modules (3) ss-DataTypes (2) version7 (7)}
-- from TS 24.080 [209]
------------------------------------------------------------------------------
--
-- CS CALL AND EVENT RECORDS
--
------------------------------------------------------------------------------
CSRecord ::= CHOICE
--
-- Record values 0..19 are circuit switch specific
--
{
moCallRecord [0] MOCallRecord,
mtCallRecord [1] MTCallRecord,
roamingRecord [2] RoamingRecord,
incGatewayRecord [3] IncGatewayRecord,
outGatewayRecord [4] OutGatewayRecord,
transitRecord [5] TransitCallRecord,
moSMSRecord [6] MOSMSRecord,
mtSMSRecord [7] MTSMSRecord,
moSMSIWRecord [8] MOSMSIWRecord,
mtSMSGWRecord [9] MTSMSGWRecord,
ssActionRecord [10] SSActionRecord,
hlrIntRecord [11] HLRIntRecord,
locUpdateHLRRecord [12] LocUpdateHLRRecord,
locUpdateVLRRecord [13] LocUpdateVLRRecord,
commonEquipRecord [14] CommonEquipRecord,
3GPP
Release 9 74 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 75 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 76 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 77 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 78 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 79 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- OBSERVED IMEI TICKETS
--
------------------------------------------------------------------------------
3GPP
Release 9 80 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- CS LOCATION SERVICE RECORDS
--
------------------------------------------------------------------------------
3GPP
Release 9 81 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- NP Fields
--
------------------------------------------------------------------------------
------------------------------------------------------------------------------
--
-- CS DATA TYPES
--
3GPP
Release 9 82 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 83 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 84 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 85 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 86 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 87 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 88 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 89 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 90 3GPP TS 32.298 V9.5.0 (2010-10)
END
3GPP
Release 9 91 3GPP TS 32.298 V9.5.0 (2010-10)
BEGIN
-- EXPORTS everything
IMPORTS
CallDuration, CalledNumber, RecordType, CallingNumber, CallReferenceNumber, CellId, DefaultSMS-
Handling, Diagnostics, Ext-GeographicalInformation, IMSI, IMEI, IPAddress, ISDN-AddressString,
LCSCause, LCSClientExternalID, LCSClientIdentity, LCSClientInternalID, LCSClientType, LCS-Priority,
LCSQoSInfo, LevelOfCAMELService, LocalSequenceNumber, LocationAreaAndCell, LocationAreaCode,
LocationType, ManagementExtensions, MessageReference, MSISDN, NotificationToMSUser, PositioningData,
RecordingEntity, ServiceKey, ServiceSpecificInfo, SMSResult, SmsTpDestinationNumber, SubscriptionID,
TimeStamp, AddressString, MSTimeZone
FROM GenericChargingDataTypes {itu-t (0) identified-organization (4) etsi(0) mobileDomain (0)
charging (5) genericChargingDataTypes (0) asn1Module (0) version1 (0)}
DefaultGPRS-Handling, RAIdentity
FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0)
gsm-Network (1) modules (3) map-MS-DataTypes (11) version6 (6)}
--
-- from TS 29.002 [214]
--
LocationMethod
FROM SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Access (2)
modules (3) ss-DataTypes (2) version7 (7)}
--
-- from TS 24.080 [209]
--
Editor’s note: consider moving the above 2 items also into the generic module in order to avoid
again copying from external sources.
;
------------------------------------------------------------------------------
--
-- GPRS RECORDS
--
------------------------------------------------------------------------------
3GPP
Release 9 92 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 93 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 94 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 95 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 96 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- PS DATA TYPES
--
------------------------------------------------------------------------------
APNSelectionMode::= ENUMERATED
--
-- See Information Elements TS 29.060 [215], TS 29.274 [223] or TS 29.275 [224]
--
{
mSorNetworkProvidedSubscriptionVerified (0),
mSProvidedSubscriptionNotVerified (1),
networkProvidedSubscriptionNotVerified (2)
}
3GPP
Release 9 97 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 98 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 99 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 100 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 101 3GPP TS 32.298 V9.5.0 (2010-10)
}
--
-- Trigger and cause values for IP flow level recording are defined for support of independent
-- online and offline charging and also for tight interworking between online and offline charging.
-- Unused bits will always be zero.
-- Some of the values are non-exclusive (e.g. bearer modification reasons).
--
3GPP
Release 9 102 3GPP TS 32.298 V9.5.0 (2010-10)
pMIPSGW (1),
gTPSGW (2),
ePDG (3),
hSGW (4),
mME (5)
}
END
BEGIN
-- EXPORTS everything
IMPORTS
…
------------------------------------------------------------------------------
--
-- WLAN RECORDS
--
------------------------------------------------------------------------------
-- …
------------------------------------------------------------------------------
--
-- WLAN DATA TYPES
--
------------------------------------------------------------------------------
-- …
3GPP
Release 9 103 3GPP TS 32.298 V9.5.0 (2010-10)
BEGIN
-- EXPORTS everything
IMPORTS
------------------------------------------------------------------------------
--
-- IMS RECORDS
--
------------------------------------------------------------------------------
3GPP
Release 9 104 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 105 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 106 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 107 3GPP TS 32.298 V9.5.0 (2010-10)
--
-- Editor’s note: The completeness of all parameters for the E-CSCF CDR is ffs.
--
3GPP
Release 9 108 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- IMS DATA TYPES
--
------------------------------------------------------------------------------
AccessCorrelationID ::= CHOICE
{
gPRS-Charging-Id [2] INTEGER,
accessNetworkChargingIdentifier [4] GraphicString
}
Editor’s note: the constructs below are imported from the generic module
3GPP
Release 9 109 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 110 3GPP TS 32.298 V9.5.0 (2010-10)
--
SessionPriority :: = ENUMERATED
{
PRIORITY-0 (0),
PRIORITY-1 (1),
PRIORITY-2 (2),
PRIORITY-3 (3),
PRIORITY-4 (4)
}
--
-- PRIORITY-4 is the highest priority and Priority-0 is the lowest priority.
--
END
3GPP
Release 9 111 3GPP TS 32.298 V9.5.0 (2010-10)
BEGIN
-- EXPORTS everything
IMPORTS
------------------------------------------------------------------------------
--
-- MMS RECORDS
--
------------------------------------------------------------------------------
3GPP
Release 9 112 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 113 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 114 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 115 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 116 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 117 3GPP TS 32.298 V9.5.0 (2010-10)
{
recordType [0] RecordType,
forwardingMmsRSAddress [1] MMSRSAddress,
messageID [2] OCTET STRING,
forwardingAddress [3] MMSAgentAddress,
recipientAddresses [4] MMSAgentAddresses,
chargeInformation [5] ChargeInformation OPTIONAL,
timeOfExpiry [6] WaitTime OPTIONAL,
earliestTimeOfDelivery [7] WaitTime OPTIONAL,
deliveryReportRequested [8] BOOLEAN OPTIONAL,
readReplyRequested [9] BOOLEAN OPTIONAL,
messageReference [10] OCTET STRING,
mmStatusCode [11] MMStatusCodeType OPTIONAL,
statusText [12] StatusTextType OPTIONAL,
recordTimeStamp [13] TimeStamp OPTIONAL,
localSequenceNumber [14] LocalSequenceNumber OPTIONAL,
recordExtensions [15] ManagementExtensions OPTIONAL,
mMBoxstorageInformation [16] MMBoxStorageInformation OPTIONAL
}
3GPP
Release 9 118 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 119 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 120 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- MMS DATA TYPES
--
------------------------------------------------------------------------------
3GPP
Release 9 121 3GPP TS 32.298 V9.5.0 (2010-10)
Editor’s note: the construct below should be aligned with other domains / generic module
Editor’s note: the construct below should be aligned with other domains / generic module
3GPP
Release 9 122 3GPP TS 32.298 V9.5.0 (2010-10)
--
-- usage of SEQUENCE instead of CHOICE allows both address types to be present at the same time
--
{
domainName [0] OCTET STRING OPTIONAL,
iPAddress [2] IPAddress OPTIONAL
}
3GPP
Release 9 123 3GPP TS 32.298 V9.5.0 (2010-10)
END
BEGIN
-- EXPORTS everything
IMPORTS
UserError
FROM MAP-ER-DataTypes {itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1)
modules (3) map-ER-DataTypes (17) version9 (9)}
--
-- from TS 29.002 [214]
--
ProviderError
FROM TCAPMessages { itu-t recommendation q 773 modules (2) messages (1) version2 (2) }
3GPP
Release 9 124 3GPP TS 32.298 V9.5.0 (2010-10)
--
-- from Q.773 [307]
--
;
------------------------------------------------------------------------------
--
-- LCS RECORDS
--
------------------------------------------------------------------------------
LCSRecord ::= CHOICE
--
-- Record values 71..75 are LCS specific
--
{
lCSGMORecord [71] LCSGMORecord,
lCSRGMTRecord [72] LCSRGMTRecord,
lCSHGMTRecord [73] LCSHGMTRecord,
lCSVGMTRecord [74] LCSVGMTRecord,
lCSGNIRecord [75] LCSGNIRecord
}
3GPP
Release 9 125 3GPP TS 32.298 V9.5.0 (2010-10)
BEGIN
-- EXPORTS everything
IMPORTS
------------------------------------------------------------------------------
--
-- POC RECORDS
--
------------------------------------------------------------------------------
3GPP
Release 9 126 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- PoC DATA TYPES
--
------------------------------------------------------------------------------
3GPP
Release 9 127 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 128 3GPP TS 32.298 V9.5.0 (2010-10)
3GPP
Release 9 129 3GPP TS 32.298 V9.5.0 (2010-10)
BEGIN
-- EXPORTS everything
IMPORTS
DefaultGPRS-Handling
FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0)
gsm-Network (1) modules (3) map-MS-DataTypes (11) version6 (6) }
--
-- from TS 29.002 [214]
--
AccessPointNameNI, ChangeCondition, ChangeOfMBMSCondition, DataVolumeGPRS, GSNAddress, NodeID,
PDPAddress, QoSInformation, RatingGroupID, RoutingAreaCode, ServiceChangeCause, SGSNPLMNIdentifier
FROM GPRSChargingDataTypes { itu-t (0) identified-organization (4) etsi (0) mobileDomain (0)
charging (5) gprsChargingDataTypes (2) asn1Module (0) version1 (0)}
------------------------------------------------------------------------------
--
-- MBMS RECORDS
--
------------------------------------------------------------------------------
3GPP
Release 9 130 3GPP TS 32.298 V9.5.0 (2010-10)
{
recordType [0] RecordType,
contentProviderId [1] GraphicString,
listofDownstreamNodes [2] SEQUENCE OF GSNAddress,
accessPointNameNI [3] AccessPointNameNI OPTIONAL,
servedPDPAddress [4] PDPAddress OPTIONAL,
listOfTrafficVolumes [5] SEQUENCE OF ChangeOfMBMSCondition OPTIONAL,
recordOpeningTime [6] TimeStamp,
duration [7] CallDuration,
causeForRecClosing [8] CauseForRecClosing,
diagnostics [9] Diagnostics OPTIONAL,
recordSequenceNumber [10] INTEGER OPTIONAL,
nodeID [11] NodeID OPTIONAL,
recordExtensions [12] ManagementExtensions OPTIONAL,
localSequenceNumber [13] LocalSequenceNumber OPTIONAL,
recipientAddressList [14] SEQUENCE OF MSISDN,
bearerServiceDescription [15] Media-Components-List OPTIONAL,
mbmsInformation [16] MBMSInformation OPTIONAL,
serviceContextID [17] ServiceContextID OPTIONAL
}
------------------------------------------------------------------------------
--
-- MBMS DATA TYPES
--
------------------------------------------------------------------------------
3GPP
Release 9 131 3GPP TS 32.298 V9.5.0 (2010-10)
--
-- This octet string
-- is a 1:1 copy of the contents (i.e. starting with octet 5) of the "Quality of
-- service Profile" information element specified in 3GPP TS 29.060 [75].
--
--
-- This octet string is a 1:1 copy of the contents of the MBMS-Session-Identity
-- AVP specified in 3GPP TS 29.061 [82]
--
END
BEGIN
-- EXPORTS everything
IMPORTS
------------------------------------------------------------------------------
--
-- MMTel RECORDS
--
------------------------------------------------------------------------------
3GPP
Release 9 132 3GPP TS 32.298 V9.5.0 (2010-10)
------------------------------------------------------------------------------
--
-- MMTel DATA TYPES
--
------------------------------------------------------------------------------
SupplService := SET
{
serviceType [0] ServiceType,
serviceMode [1] ServiceMode OPTIONAL,
numberOfDiversions [2] INTEGER OPTIONAL,
associated-Party-Address [3] InvolvedParty OPTIONAL,
serviceId [4] Service-Id OPTIONAL,
changeTime [5] TimeStamp,
numberOfParticipants [6] INTEGER OPTIONAL,
participantActionType [7] ParticipantActionType OPTIONAL,
cUGInformation [8] OCTET STRING OPTIONAL
3GPP
Release 9 133 3GPP TS 32.298 V9.5.0 (2010-10)
tIRestriction (3),
hOLD (4),
cBarring (5),
cDIVersion (6),
cDIVersionNotif (7),
cWaiting (8),
mWaitingIndic (9),
cONF (10),
fLexibleAlerting (11),
cCBS (12),
cCNR (13),
mCID (14),
cAT (15),
cUG (16) ,
pNM (17),
cRS (18)
END
3GPP
Release 9 134 3GPP TS 32.298 V9.5.0 (2010-10)
The latter two items can be used by the system(s) in the BD to easily detect the encoding version used. See
TS 32.297 [52] for a detailed description on how this information is used on the Bx interface.
The encoding applied to the CDRs is indicated by means of the "Data Record Format" parameter. The following "Data
Record Format" values are used:
- "2" signifies the use of unaligned basic Packed Encoding Rules (PER);
- "3" signifies the use of aligned basic Packed Encoding Rules (PER);
For CDRs specified in references in middle tier Charging TS 32.250 [10] to TS 32.275 [35], applying the syntax as
described in clause 5 of the present document, the version indicator "6", signifying 3GPP Rel-6, shall be applied. The
Version Identifier shall carry the value of the middle digit of the version number of the present document, i.e. "0" for the
first version under change control, and values "1" and following for any subsequent, modified version as appropriate.
3GPP
Release 9 135 3GPP TS 32.298 V9.5.0 (2010-10)
Annex A (normative):
CDR abstract syntax – machine processable
This annex replicates the contents of subclause 5.2, which is optimised for human readability, in a format that is
machine readable and –processable. Technically, the contents of clause 5 and this annex are completely identical. In
case of deviations between this annex and clause 5 due to errors in the present document, this annex shall prevail.
3GPP
Release 9 136 3GPP TS 32.298 V9.5.0 (2010-10)
Annex B (informative):
Bibliography
a) The 3GPP charging specifications
3GPP
Release 9 137 3GPP TS 32.298 V9.5.0 (2010-10)
Annex C (informative):
Change history
3GPP
Release 9 138 3GPP TS 32.298 V9.5.0 (2010-10)
Change history
Date TSG # TSG Doc. CR Rev Subject/Comment Cat Old New
Sep 2007 SP-37 SP-070605 0080 -- Correction of IMS Charging Identifier (ICID) definition - Align with 32.260 A 7.3.0 7.4.0
Sep 2007 SP-37 SP-070619 0077 -- Add Service-Specific-Info AVP to be used for extended packet C 7.4.0 8.0.0
inspection beyond 5 tuple - Align with 23.203
Mar 2008 SP-39 SP-080059 0081 1 Add CDR fields for IBCF B 8.0.0 8.1.0
Mar 2008 SP-39 SP-080074 0082 -- Add on Number Portability and Carrier Select routing information B 8.0.0 8.1.0
Jun 2008 SP-40 SP-080330 0083 -- Add PoC Event Type into PoC CDR B 8.1.0 8.2.0
Dec 2008 SP-42 SP-080841 0087 - Correction on QoS IE length A 8.2.0 8.3.0
Dec 2008 SP-42 SP-080706 0088 - Correction on ASN.1 F 8.2.0 8.3.0
Dec 2008 SP-42 SP-080852 0084 - CDR definitions for EPC Charging B 8.2.0 8.3.0
Dec 2008 SP-42 SP-080706 0089 - Addition of SDP offer and answer and clarification on media initiator B 8.2.0 8.3.0
Dec 2008 SP-42 SP-080852 0085 - CDR definitions for EPC Charging B 8.2.0 8.3.0
Dec 2008 SP-42 SP-080707 0090 - Service level CDR parameters for MMTel B 8.4.0 8.3.0
Dec 2008 SP-42 SP-080706 0091 - Clarification on EPC Charging B 8.2.0 8.3.0
Mar 2009 SP-43 SP-090206 0092 - TS 32.298 Correction on Record type values F 8.3.0 8.4.0
Mar 2009 SP-43 SP-090203 0093 - TS 32.298 MMTel CDR description B 8.3.0 8.4.0
Mar 2009 SP-43 SP-090206 0094 - Alignment of CDR fields with TS 32251 for EPC Charging C 8.3.0 8.4.0
Jun 2009 SP-44 SP-090432 0096 - Correction on Serving Node Address F 8.4.0 8.5.0
Jun 2009 SP-44 SP-090432 0099 - SGW and PGW CDRs description alignement with TS 32.251 F 8.4.0 8.5.0
Jun 2009 SP-44 SP-090432 - “Mobile Node Identifier” used for PMIP S5/S8 and S2a/S2b in PGW F 8.4.0 8.5.0
0100 CDR
Jun 2009 SP-44 SP-090432 0102 - Correction on EPC Charging F 8.4.0 8.5.0
Jun 2009 SP-44 SP-090292 0097 - Rel-8 CR 32.298 correction of timestamp granularity B 8.5.0 9.0.0
Jun 2009 SP-44 SP-090294 - Add MMTel supplementary services FA, CCBS&CCNR, MCID, CAT for B 8.5.0 9.0.0
0098 MMTel Charging
Jun 2009 SP-44 SP-090292 0101 - Rel-9 CR 32.298 addition of online charging flag B 8.5.0 9.0.0
Sep 2009 SP-45 SP-090541 0103 - Add MBMS GW address B 9.0.0 9.1.0
Sep 2009 SP-45 SP-090536 Rel-9 CR 32.298 correction of number portability and carrier select 9.1.0
0105 - information A 9.0.0
Sep 2009 SP-45 SP-090538 0106 - Add “Closed User Group (CUG)” for MMTel Charging B 9.0.0 9.1.0
Sep 2009 SP-45 SP-090538 0107 - Add 3PTY MMTel supplementary service charging B 9.0.0 9.1.0
Sep 2009 SP-45 SP-090538 0108 - CDR parameter for RTTI support in IMS offline charging B 9.0.0 9.1.0
Sep 2009 SP-45 SP-090536 0110 - Set of Corrections in ASN1 description for IMS CDRs A 9.0.0 9.1.0
Sep 2009 SP-45 SP-090536 0112 - Set of Corrections in ASN1 description for EPC CDRs A 9.0.0 9.1.0
Sep 2009 SP-45 SP-090536 0114 - Correction on Charging Characteristics Format A 9.0.0 9.1.0
Sep 2009 SP-45 SP-090537 0115 - Emergency bearer service consideration for charging B 9.0.0 9.1.0
Sep 2009 SP-45 SP-090536 0117 - Correction to MO and MT SMS CDRs for SMS over SGs A 9.0.0 9.1.0
Sep 2009 SP-45 SP-090536 0119 - Remove CAMEL Charging Information from SGW CDR A 9.0.0 9.1.0
Sep 2009 SP-45 SP-090536 0121 - Addition of IP multicast delivery related contents in MBMS information A 9.0.0 9.1.0
Dec 2009 SP-46 SP-090720 0123 - Correction of PDP/PDN Type A 9.1.0 9.2.0
Dec 2009 SP-46 SP-090720 Alignment with TS 32.251 for “Volume Limit” and “Time Limit” in 9.2.0
0125 - Change-Condition AVP A 9.1.0
Dec 2009 SP-46 SP-090720 Alignment with TS 32.251 for “User location Change” Condition in 9.2.0
0127 - ServiceConditionChange and ChangeCondition A 9.1.0
Dec 2009 SP-46 SP-090720 Correction of interOperatorIdentifiers information alignment with TS 9.2.0
0129 - 32.260 A 9.1.0
Dec 2009 SP-46 SP-090720 Clarify “Change Condition” setting for containers level and “Cause for 9.2.0
0131 - record Closing” for CDR level for P-GW and S-GW. A 9.1.0
Dec 2009 SP-46 SP-090720 0133 - Correction on priority session treatment - alignment with TS 22.153 A 9.1.0 9.2.0
Dec 2009 SP-46 SP-090721 0134 - Editorial clean-up D 9.1.0 9.2.0
Dec 2009 SP-46 SP-090721 0135 - Add CSG parameters for CSG based offline charging B 9.1.0 9.2.0
Mar 2010 SP-47 SP-100040 136 - Correction of the Role of Node charging parameter definition A 9.2.0 9.3.0
Mar 2010 SP-47 Old/New location description for Location update VLR record - 9.3.0
SP-100041 137 - Alignment with TS 32.250. F 9.2.0
Mar 2010 SP-47 SP-100041 138 - Correction on Session Id for AS acting as B2BUA F 9.2.0 9.3.0
Mar 2010 SP-47 Correction on MMTel CDR description for Early SDP- Alignment with TS 9.3.0
SP-100040 141 - 32.260 A 9.2.0
Mar 2010 SP-47 Correction in MMTel Charging for session priority - Alignment with TS 9.3.0
SP-100040 143 - 32.260 A 9.2.0
Mar 2010 SP-47 SP-100041 144 - Correction on SDP handling in IMS Charging F 9.2.0 9.3.0
Mar 2010 SP-47 Add “Personal Network management” MMTel supplementary service 9.3.0
SP-100044 145 - charging description B 9.2.0
Mar 2010 SP-47 Add “Customized Ringing Signal (CRS)” MMTel supplementary service 9.3.0
SP-100044 146 - charging description B 9.2.0
Mar 2010 SP-47 SP-100040 147 - Correction for offline Charging from PGW - 3GPP2 User location A 9.2.0 9.3.0
Jun 2010 SP-48 SP-100266 149 - Correction on ASN.1 definitions F 9.3.0 9.4.0
Jun 2010 SP-48 SP-100266 151 - Charging information for Emergency IMS Sessions F 9.3.0 9.4.0
Oct 2010 SP-49 SP-100496 154 - Correction for Dual IP addresses associated to one PDN connection A 9.4.0 9.5.0
Oct 2010 SP-49 SP-100496 157 - Correction on SDP-Type A 9.4.0 9.5.0
3GPP