3GPP TS 24.647: Advice Of Charge (AOC) using IP Multimedia (IM) Core Network (CN) subsystem

3GPP TS 24.647 V9.2.0 (2010-09)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals; Advice Of Charge (AOC) using IP Multimedia (IM) Core Network (CN) subsystem 
(Release 9)

	 EMBED Word.Picture.8  
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.


Keywords
AOC, ISDN, PSTN, supplementary service, LTE, UMTS, GSM

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 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

Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc273437604 \h 6
1	Scope	 PAGEREF _Toc273437605 \h 7
2	References	 PAGEREF _Toc273437606 \h 7
3	Definitions and abbreviations	 PAGEREF _Toc273437607 \h 8
3.1	Definitions	 PAGEREF _Toc273437608 \h 8
3.2	Abbreviations	 PAGEREF _Toc273437609 \h 8
4	Advice Of Charge (AOC)	 PAGEREF _Toc273437610 \h 9
4.1	Introduction	 PAGEREF _Toc273437611 \h 9
4.2	Description	 PAGEREF _Toc273437612 \h 9
4.2.1	General description	 PAGEREF _Toc273437613 \h 9
4.2.2	Charging information at communication set-up time (AOC-S)	 PAGEREF _Toc273437614 \h 9
4.3	Charging information during the communication (AOC-D)	 PAGEREF _Toc273437615 \h 9
4.4	Charging information at the end of the communication (AOC-E)	 PAGEREF _Toc273437616 \h 9
4.5	Operational requirements	 PAGEREF _Toc273437617 \h 9
4.5.1	Provision/withdrawal	 PAGEREF _Toc273437618 \h 9
4.5.2	Requirements on the originating network side	 PAGEREF _Toc273437619 \h 9
4.5.3	Requirements on the terminating network side	 PAGEREF _Toc273437620 \h 10
4.6	Coding requirements	 PAGEREF _Toc273437621 \h 10
4.7	Signalling requirements	 PAGEREF _Toc273437622 \h 10
4.7.1	Activation/deactivation	 PAGEREF _Toc273437623 \h 10
4.7.1A	Registration/erasure	 PAGEREF _Toc273437624 \h 10
4.7.1B	Interrogation	 PAGEREF _Toc273437625 \h 10
4.7.2	Invocation and operation	 PAGEREF _Toc273437626 \h 10
4.7.2.0	Introduction	 PAGEREF _Toc273437627 \h 10
4.7.2.1	Actions at the served UE	 PAGEREF _Toc273437628 \h 10
4.7.2.2	Actions at the AS of the served user	 PAGEREF _Toc273437629 \h 11
4.7.2.2.0	General	 PAGEREF _Toc273437630 \h 11
4.7.2.2.1	Actions for AOC-S	 PAGEREF _Toc273437631 \h 11
4.7.2.2.1.1	Served user is the originating user	 PAGEREF _Toc273437632 \h 11
4.7.2.2.1.2	Served user is the terminating user	 PAGEREF _Toc273437633 \h 11
4.7.2.2.2	Actions for AOC-D	 PAGEREF _Toc273437634 \h 12
4.7.2.2.3	Actions for AOC-E	 PAGEREF _Toc273437635 \h 12
4.8	Interaction with other services	 PAGEREF _Toc273437636 \h 12
4.8.1	Communication Waiting (CW)	 PAGEREF _Toc273437637 \h 12
4.8.2	Communication Hold (HOLD)	 PAGEREF _Toc273437638 \h 12
4.8.3	Terminating Identification Presentation (TIP)	 PAGEREF _Toc273437639 \h 12
4.8.4	Terminating Identification Restriction (TIR)	 PAGEREF _Toc273437640 \h 12
4.8.5	Originating Identification Presentation (OIP)	 PAGEREF _Toc273437641 \h 12
4.8.6	Originating Identification Restriction (OIR)	 PAGEREF _Toc273437642 \h 13
4.8.7	CONFerence calling (CONF)	 PAGEREF _Toc273437643 \h 13
4.8.8	Communication DIVersion services (CDIV)	 PAGEREF _Toc273437644 \h 13
4.8.9	Advice Of Charge (AOC)	 PAGEREF _Toc273437645 \h 13
4.8.10	Completion of Communications to Busy Subscriber (CCBS) Completion of Communications by No Reply (CCNR)	 PAGEREF _Toc273437646 \h 13
4.8.11	Malicious Communication IDentification (MCID)	 PAGEREF _Toc273437647 \h 13
4.8.12	Anonymous Communication Rejection and Communication Barring (ACR/CB)	 PAGEREF _Toc273437648 \h 13
4.8.13	Explicit Communication Transfer (ECT)	 PAGEREF _Toc273437649 \h 13
4.9	Interactions with other networks	 PAGEREF _Toc273437650 \h 13
4.10	Parameter values (timers)	 PAGEREF _Toc273437651 \h 13
5	Extensions within the present document	 PAGEREF _Toc273437652 \h 14
5.1	AOC information XML body	 PAGEREF _Toc273437653 \h 14
5.1.1	General	 PAGEREF _Toc273437654 \h 14
5.1.2	MIME type definition	 PAGEREF _Toc273437655 \h 14
5.1.2.1	Introduction	 PAGEREF _Toc273437656 \h 14
5.1.2.2	Syntax	 PAGEREF _Toc273437657 \h 14
5.1.2.3	Operation	 PAGEREF _Toc273437658 \h 14
Annex A (informative):	Signalling flows	 PAGEREF _Toc273437659 \h 15
A.1	Introduction	 PAGEREF _Toc273437660 \h 15
A.2	User originating AOC service	 PAGEREF _Toc273437661 \h 15
A.2.1	AOC-S	 PAGEREF _Toc273437662 \h 15
A.2.1.1	AOC-S with information in reliable 1xx responses	 PAGEREF _Toc273437663 \h 15
A.2.1.2	AOC-S with AOC information in a 200 (OK) response	 PAGEREF _Toc273437664 \h 16
A.2.2	AOC-D	 PAGEREF _Toc273437665 \h 17
A.2.3	AOC-E	 PAGEREF _Toc273437666 \h 17
A.3	User terminating AOC service	 PAGEREF _Toc273437667 \h 19
A.3.1	AOC-S	 PAGEREF _Toc273437668 \h 19
A.3.2	AOC-D	 PAGEREF _Toc273437669 \h 20
A.3.3	AOC-E	 PAGEREF _Toc273437670 \h 21
Annex B (informative):	Example of Filter Criteria	 PAGEREF _Toc273437671 \h 23
Annex C (normative):	Charging Information Elements	 PAGEREF _Toc273437672 \h 24
C.1	General	 PAGEREF _Toc273437673 \h 24
C.2	AOC-S	 PAGEREF _Toc273437674 \h 24
C.2.1	Charged Items	 PAGEREF _Toc273437675 \h 24
C.2.1.1	Charged Item: basic communication	 PAGEREF _Toc273437676 \h 24
C.2.1.2	Charged Item: communication attempt	 PAGEREF _Toc273437677 \h 24
C.2.1.3	Charged Item: communication setup	 PAGEREF _Toc273437678 \h 25
C.2.1.4	Charged Item: operation of services	 PAGEREF _Toc273437679 \h 25
C.2.1.5	Special Charging Arrangement	 PAGEREF _Toc273437680 \h 25
C.2.2	Expressing Charging Rates	 PAGEREF _Toc273437681 \h 25
C.2.2.1	Duration charge: Price per time unit, and unit time	 PAGEREF _Toc273437682 \h 26
C.2.2.2	Specific: free of charge	 PAGEREF _Toc273437683 \h 26
C.2.2.3	Specific: flat rate	 PAGEREF _Toc273437684 \h 26
C.2.2.4	Specific: special charging code N.	 PAGEREF _Toc273437685 \h 26
C.2.2.5	Charging unit	 PAGEREF _Toc273437686 \h 26
C.2.2.6	Not available	 PAGEREF _Toc273437687 \h 26
C.3	AOC-D	 PAGEREF _Toc273437688 \h 26
C.3.1	Type of charging information	 PAGEREF _Toc273437689 \h 27
C.3.2	Recorded charges	 PAGEREF _Toc273437690 \h 27
C.3.3	Billing identification for AOC-D	 PAGEREF _Toc273437691 \h 27
C.4	AOC-E	 PAGEREF _Toc273437692 \h 27
C.4.1	Billing identification for AOC-E	 PAGEREF _Toc273437693 \h 27
C.5	Common types/information elements	 PAGEREF _Toc273437694 \h 28
C.5.1	Time unit	 PAGEREF _Toc273437695 \h 28
C.5.2	Decimal	 PAGEREF _Toc273437696 \h 28
C.5.3	Scale	 PAGEREF _Toc273437697 \h 28
C.5.4	Currency identifier	 PAGEREF _Toc273437698 \h 28
C.5.5	Currency amount	 PAGEREF _Toc273437699 \h 28
C.5.6	Length of time unit	 PAGEREF _Toc273437700 \h 28
C.5.7	Granularity	 PAGEREF _Toc273437701 \h 29
C.5.8	Type of charging	 PAGEREF _Toc273437702 \h 29
C.5.9	Recorded number of currency units	 PAGEREF _Toc273437703 \h 29
Annex D (normative):	AOC XML Schema, version 1.0:	 PAGEREF _Toc273437704 \h 30
Annex E (informative):	IANA Registration templates	 PAGEREF _Toc273437705 \h 33
E.1	IANA registry for Application Media Types	 PAGEREF _Toc273437706 \h 33
E.1.1	IANA Registration template for application/vnd.etsi.aoc+xml	 PAGEREF _Toc273437707 \h 33
Annex F (informative):	Change history	 PAGEREF _Toc273437708 \h 35

Foreword
This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) and originally published as ETSI TS 183 047 [6]. It was transferred to the 3rd Generation Partnership Project (3GPP) in December 2007.
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:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
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.
1	Scope
The present document specifies the stage three Protocol Description of the Advice Of Charge (AOC) service, based on stage 1 and 2 of the ISDN Supplementary Service Advice Of Charge for all calls (permanent mode). It provides the protocol details in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP).
Three AOC services exist:
a)	Charging information at communication set-up time (AOC-S)
	The AOC-S service enables a user to receive information about the charging rates at communication set-up time and also to receive further information during the communication if there is a change of charging rates.
b)	Charging information during the communication (AOC-D)
	The AOC-D service enables a user to receive information on the recorded charges for a communication during the active phase of the communication.
c)	Charging information at the end of the communication (AOC-E)
	The AOC-E service enables a user to receive information on the recorded charges for a communication when the communication is terminated.
The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to support the AOC supplementary services.
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 specific reference, subsequent revisions do not apply.
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.
[1]	3GPP TS  HYPERLINK "http://www.3gpp.org/ftp/Specs/archive/24_series/24.229" \t "_blank" 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1".
[2]	3GPP TS  HYPERLINK "http://www.3gpp.org/ftp/Specs/archive/24_series/24.229" \t "_blank" 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
[3]	ISO 4217: "International Organization for Standardization; Type Currency Code List".
[4]	IETF RFC 2976 (2000): "The SIP INFO method".
[5]	IETF RFC 3262 (2002): "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)".
[6]	ETSI TS 183 047 V2.1.1: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN IMS Supplementary Services; Advice Of Charge (AOC)".
[7]	IETF RFC 3261 (June 2002): "SIP: Session Initiation Protocol".
[8]	IETF RFC 3023 (January 2001): "XML Media Types".
[9]	IETF RFC 4288 (December 2005): "Media Type Specifications and Registration Procedures".
[10]	3GPP TS  HYPERLINK "http://www.3gpp.org/ftp/Specs/archive/24_series/24.229" \t "_blank" 32.280: "Telecommunication management; Charging management; Advice of Charge (AoC) service".
3	Definitions and abbreviations
3.1	Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] apply.
3.2	Abbreviations
For the purposes of the present document, the following abbreviations apply:
AOC	Advice Of Charge 
AOC-D	AOC During the call
AOC-E	AOC at the End of the call
AOC-S	AOC at call Set-up time
AS	Application Server
CB 	Communication Barring
CCBS	Completion of Communication to Busy Subscriber.
CD	Communication Deflection
CDIV	Call DIVersion
CFB	Communication Forwarding Busy
CFNL	Communication Forwarding on No Logged-in
CFNRd	Communication Forwarding Not Registered
CFNRy	Communication Forwarding No Reply
CFU	Communication Forwarding Unconditional
CN	Core Network
CNR	Completion of communication on No Reply
CONF	CONFerence calling
CW	Communication Waiting
ECT	Explicit Communication Transfer
HOLD	Communication HOLD
IFC	Initial Filter Criteria
IM	IP Multimedia
IMS	IP Multimedia Subsystem
IP	Internet Protocol
ISDN	Integrated Service Data Network
MCID	Malicious Communication IDentification
MIME	Multipurpose Internet Mail Extensions
OIP	Originating Identification Presentation
OIR	Originating Identification Restriction
S-CSCF	Serving-Call Session Control Function
SIP	Session Initiation Protocol
TIP	Terminating Identification Presentation 
TIR	Terminating Identification Restriction 
UE	User Equipment 
4	Advice Of Charge (AOC)
4.1	Introduction
The Advice Of Charge (AOC) service allows the served user to be informed of IP Multimedia session related charging information.
4.2	Description
4.2.1	General description
The AOC service is limited to INVITE-initiated sessions. 
The AOC service is not meant to replace the charge metering inside the network which is considered to be correct in all cases.
The charging information given shall relate to the charges incurred in the current network.
4.2.2	Charging information at communication set-up time (AOC-S)
When the AOC-S service is activated, the network shall provide the user with information about the charging rates at communication establishment. In addition, the network shall inform the served user if a change in charging rates takes place during the communication.
4.3	Charging information during the communication (AOC-D)
When the AOC-D service is activated, the network shall provide the user with charging information for a communication during the active phase of this communication. The supplied charging information shall be provided as a cumulative charge incurred so far for the communication (i.e. charges recorded from the start of the communication and until the moment the charging information is sent to the served user), or as charging units.
When the call is released, the network shall send the recorded charges for the communication to the served user.
4.4	Charging information at the end of the communication (AOC-E)
When the AOC-E service is activated, the network shall provide the served user with charging information indicating the recorded charges for a communication when this communication is released. 
4.5	Operational requirements
4.5.1	Provision/withdrawal
The AOC services shall be provided to the served user after prior arrangement with the service provider or, as a service provider option, be generally available. Withdrawal of these services shall be made on the served user's request or for service provider reasons.
When available the AOC services shall be provided for all communications (permanent mode).
4.5.2	Requirements on the originating network side
No specific requirements are needed in the network.
4.5.3	Requirements on the terminating network side
No specific requirements are needed in the network.
4.6	Coding requirements
The INFO method according to IETF RFC 2976 [4] is needed in support of AOC-D.
The AOC XML schema is defined in annex D. The AOC XML schema shall be transported as a SIP MIME body. The MIME type for the AOC information is "application/vnd.etsi.aoc+xml" (see subclause 5.1). Any SIP message that transports a body with AOC information shall identify the payload as MIME type "application/vnd.etsi.aoc+xml", the MIME type associated with AOC information (see subclause 5.1), and shall identify in the "sv" or "schemaversion" parameter's value the versions of AOC XML Schema that can be used to validate the AOC information XML body (part). If both the "sv" and "schemaversion" parameters are present, then the P-CSCF shall ignore the value of the "schemaversion" parameter. The versions – of the MIME type associated with AOC information (see subclause 5.1) –  indicated shall correspond with a value of the version attribute of the  XML element of an AOC XML Schema (see e.g. annex D).
4.7	Signalling requirements
4.7.1	Activation/deactivation
The AOC service is activated at provisioning and deactivated at withdrawal.
4.7.1A	Registration/erasure
The AOC service requires no registration. Erasure is not applicable.
4.7.1B	Interrogation
Interrogation of AOC is not applicable.
4.7.2	Invocation and operation
4.7.2.0	Introduction
Basic communication procedures according to 3GPP TS 24.229 [2] shall apply, with the additions outlined in the subclauses below.
4.7.2.1	Actions at the served UE
The served UE shall support the INFO method and the AOC XML schema defined in annex D.
If methods or responses are received which contain AOC information, this information may be rendered to the user.
In addition to the procedures according to 3GPP TS 24.229 [2], the served UE shall include the Accept header field with: 
-	"application/vnd.etsi.aoc+xml", the MIME type associated with AOC information (see subclause 5.1), and indicate the versions of the AOC XML Schema it supports. The versions –  of the MIME type associated with AOC information (see subclause 5.1) –  indicated shall correspond with a value of the version attribute of the  XML element of an AOC XML Schema (see e.g. annex D); and
-	any other MIME type the served UE is willing and capable to accept.
4.7.2.2	Actions at the AS of the served user
4.7.2.2.0	General
The AS shall assume that the served user's UE supports version 1.0 of the MIME type associated with AOC information (see subclause 5.1), if support for the MIME type associated with AOC information in the Accept header is not indicated. The versions – of the MIME type associated with AOC information (see subclause 5.1) –  indicated shall correspond with a value of the version attribute of the  XML element of an AOC XML Schema (see e.g. Annex D).
When sending AOC information, the AS shall encode this information according to the XML-schema defined in annex D. In addition, for this MIME body the AS shall: 
-	set the Content-Type header to "vnd.etsi.aoc+xml", the MIME type associated with AOC information (see subclause 5.1), and shall include in its "sv" or "schemaversion" parameter’s value the versions of AOC XML Schema that can be used to validate the AOC information XML body (part). If both the "sv" and "schemaversion" parameters are present, then the P-CSCF shall ignore the value of the "schemaversion" parameter. The versions – of the MIME type associated with AOC information (see subclause 5.1) –  indicated shall correspond with a value of the version attribute of the  XML element of an AOC XML Schema (see e.g. Annex D);  and
-	set the Content-Disposition to "render" with the "handling" parameter set to "optional".
In the case the AOC information is transported in a message that is forwarded by the AS that contains already a content body, the AS shall generate a multipart/mixed MIME body containing two sub-parts:
-	one with the AOC information; the Content-Type and Content-Disposition of this sub-part should be coded as specified for non-multipart bodies;
-	one with the received body; headers describing the content of the received SIP message (e.g. Content-type) should be moved into the headers of the this subpart.
In the case the AOC information is transported in a message that is forwarded by the AS, that contains already a content body and the served user's UE has not indicated support for multipart content, the AS shall forward the message unchanged.
NOTE:	The above subclause ensures that a communication setup is not affected in case a terminal does not support multipart content.
4.7.2.2.1	Actions for AOC-S
4.7.2.2.1.1	Served user is the originating user
When an INVITE request is received, and the served user is subscribed to AOC-S service, the AS shall either (network operator option) operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] and in IETF RFC 3262 [5] and include the AOC information in the content body of a reliable 1xx provisional responses, or operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] and include the AOC information in the content body a 200 (OK) response forwarded by the AS.
If the charging rates change during the communication, the AS shall send the AOC information to the UE of the served user in the content body of a mid-dialog request forwarded by the AS or an INFO request generated by the AS.
NOTE:	If no charging information is available, then the AS can, as a network option, stop the communication establishment before the session is confirmed by sending a 504 (Server Time-out) response to the originating user and a BYE request to the terminating side. The BYE request contains a Reason header field with a reason value with the protocol set to "SIP" and the cause set to "504" and optionally a reason value with the protocol set to "Q.850" and the cause set to "31".
4.7.2.2.1.2	Served user is the terminating user
The AS shall operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2].
When an INVITE request is received, and the served user is subscribed to the AOC-S service, the AS shall include the AOC information in the content body in the INVITE request before sending the INVITE request to the terminating UE. 
If the charging rates change during the communication, the AS shall send the AOC information to the UE of the served user in the content body of a mid-dialog request forwarded by the AS or an INFO request generated by the AS.
NOTE:	If no charging information is available, then the AS can, as a network option, not forward the communication invitation and send a 504 (Server Time-out) response to the originating side.
4.7.2.2.2	Actions for AOC-D
The AS shall operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2].
The procedures for AOC-D service at the AS are the same for the originating and the terminating user.
If the user is subscribed to AOC-D service, the AS may provide charging information to the user at any moment during the active phase of the communication. When sending the charging information, the AS shall include the AOC information in the content body of a mid-dialog request or mid-dialog response forwarded by the AS to the served user or an INFO request to the served user generated by the AS. The supplied charging information shall be provided as a cumulative charge incurred so far for the communication (i.e. charges recorded from the start of the communication until the moment the charging information is sent to the served user).
When the communication is terminated, the AS shall include the recorded AOC information for the communication in the content body of either the BYE request or the final response to the BYE request sent to the served user. If the communication is free of charge, then the AS shall indicate the charged amount as zero in the AOC information.
4.7.2.2.3	Actions for AOC-E
The AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2].
The procedures for AOC-E service at the AS are the same for the originating and the terminating user.
If the user is subscribed to AOC-E service, when the communication is terminated the AS shall include the recorded AOC information for the communication in the content body of either the BYE request or the final response to the BYE request sent to the served user. If the communication is free of charge, then the AS shall indicate the charged amount as zero in the AOC information.
4.8	Interaction with other services
4.8.1	Communication Waiting (CW)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.2	Communication Hold (HOLD)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.3	Terminating Identification Presentation (TIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.4	Terminating Identification Restriction (TIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.5	Originating Identification Presentation (OIP)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.6	Originating Identification Restriction (OIR)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.7	CONFerence calling (CONF)
No impact, i.e. neither service shall affect the operation of the other service.
NOTE:	AOC information as result of a CONF invocation is out of scope the present document.
4.8.8	Communication DIVersion services (CDIV)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.9	Advice Of Charge (AOC)
If the AOC-D and AOC-E services are activated for the same communication, at the end of the communication the network shall only send AOC-E type information.
4.8.10	Completion of Communications to Busy Subscriber (CCBS) Completion of Communications by No Reply (CCNR)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.11	Malicious Communication IDentification (MCID)
No impact, i.e. neither service shall affect the operation of the other service.
4.8.12	Anonymous Communication Rejection and Communication Barring (ACR/CB)
No impact, i.e. neither service shall affect the operation of the other service. 
4.8.13	Explicit Communication Transfer (ECT)
No impact, i.e. neither service shall affect the operation of the other service.
NOTE:	AOC information as result of an ECT invocation is out of scope of the present document.
4.9	Interactions with other networks
Not applicable. 
4.10	Parameter values (timers)
Not applicable.
5	Extensions within the present document
5.1	AOC information XML body
5.1.1	General
This subclause contains the AOC information XML body in XML format. The AOC information XML shall be valid against the AOC XML schema defined in Annex D.
See subclause 5.1.2 for the associated MIME type definition.
5.1.2	MIME type definition
5.1.2.1	Introduction
This subclause defines the MIME type for "application/vnd.etsi.aoc+xml". An AOC information XML Document can be identified with this media type.
5.1.2.2	Syntax
The following optional parameters are defined:
-	"charset": the parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in IETF RFC 3023 [8].
-	"sv" or "schemaversion": the syntax for the "sv" or "schemaversion" parameter is specified in table 2:
Table 2: Syntax of the "sv" or "schemaversion" parameter

m-parameter    =/ ("sv" / "schemaversion") EQUAL LDQUOT [ sv-value-list ] RDQUOT
sv-value-list  =  sv-value-range *( "," sv-value )
sv-value-range =  sv-value [ "-" sv-value ]
sv-value       =  number / token
number         =  1*DIGIT [ "." 1*DIGIT ]


	The BNF for m-parameter is taken from IETF RFC 3261 [7] and modified accordingly.
5.1.2.3	Operation
The encoding considerations for "application/vnd.etsi.aoc+xml" are identical to those of "application/xml" as described in IETF RFC 3023 [8].
The "sv" or "schemaversion" parameter's value is used to indicate:
-	the versions of the AOC information XML schema that can be used to validate the AOC information XML body (if the MIME type and parameter are present in the Content-Type header); or
-	the accepted versions of the AOC information XML body (if the MIME type and parameter are present in the Accept header). If the "sv" or "schemaversion" parameter’s value is empty, no versions of the of the AOC information XML schema are supported.
If the "sv" and "schemaversion" parameter are absent, it shall be assumed that version 1.0 of the XML Schema for the AOC information XML body is supported.
Annex A (informative):
Signalling flows
A.1	Introduction
The service is divided into two aspects:
Application Server gathers information: this is out of scope of the present document.
User is provided the AOC Information. 
A.2	User originating AOC service
A.2.1	AOC-S
A.2.1.1	AOC-S with information in reliable 1xx responses
 EMBED Visio.Drawing.6  
Figure A.2.1.1: Charging info during session set-up (originating side)
Figure A.2.1.1 shows one ordering of the messages. Message 3 and message 9 can be sent at the same moment. 
General 
The AOC information is provided for every communication. This is provisioned in the AS. The AOC information is sent to UE-A in a 183 (Session Progress) response.
Call flows
1 to 5 and 1 to 2 	The communication is initiated by UE-A by sending an INVITE request. The Request URI will include the URI of UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the Originating AS. The INVITE request will indicate support for 100rel extension.
3 to 8		The Originating AS sends the AOC information to UE-A in a reliable 183 (Session Progress) response.
9 to 11		The INVITE request is sent to UE-B. 
12 to 16	The UE-B answers the communication. The 200 (OK) response is generated by UE-B. 
A.2.1.2	AOC-S with AOC information in a 200 (OK) response
 EMBED Visio.Drawing.6  
Figure A.2.1.2: Charging info in 200 (OK) response during session set-up (originating side) 
Figure A.2.1.2 shows one ordering of the messages.
General
The AOC information is provided for every call. This is provisioned in the AS. The AOC information is sent to UE-A in 200 (OK) response (to INVITE request) after receiving a 200 (OK) response (to the INVITE request) from UE-B.
Call flows
1-5	The call is initiated by UE-A by sending an INVITE request. The Request URI will include the URI of UE-B. The INVITE request is routed via the Originating AS to UE-B. 
6-10	UE-B answers the call. The 200 (OK) response is generated by UE-B. The Originating AS sends the AOC information to UE-A in this 200 (OK) response. 
11-15	UE-A sends an ACK request to UE-B and the session is established. 
A.2.2	AOC-D
 EMBED Visio.Drawing.6  
Figure A.2.2.1: Charging info during the communication 
This can be a continuation of figures A.2.1.1 or A.2.1.2.
Call flow
1-4	When the charging rate is changes, an INFO request is send from the Originating AS to UE-A. The AOC information is included in the INFO request.
A.2.3	AOC-E
Calling party clears
 EMBED Visio.Drawing.6  
Figure A.2.3.1: Calling party clears
The AOC information is provided for every communication after the communication has finished. This is provisioned in the AS. The AOC information is sent to the terminal in a 200 (OK) response (to the BYE request), which is originated from UE-B. 
Call Flow
The communication has been set up as a normal communication. 
1-5 	UE-A generates a BYE request to terminate the session, which is routed to UE-B. 
6-10 	UE-B sends a 200 (OK) response (to BYE request) towards UE-A. When the Originating AS receives the 200 (OK) response, it adds the AOC information to the 200 (OK) response (to the BYE request).
Called party clears 
 EMBED Visio.Drawing.6  
Figure A.2.3.2: Called party clears
The AOC information is provided for every communication after the communication has finished. This is provisioned in the AS. The charging info is sent to the terminal in a BYE request, which is originated from UE-B. 
Call Flow
The communication has been set-up as a normal communication. 
1-5 	UE-B generates a BYE request to terminate the session, which is routed to the UE-A. When the Originating AS receives the BYE request, it adds the AOC information to the BYE request. 
6-.10 	UE-A sends a 200 (OK) response (to the BYE request) towards UE-B.
A.3	User terminating AOC service
A.3.1	AOC-S
 EMBED Visio.Drawing.6  
Figure A.3.1.1: Charging info during session set-up on the terminating side
General 
The AOC information is provided for every call. This is provisioned in the AS. The AOC information is sent to the terminal in an INVITE request. Since this is a service that is charged an acknowledgement is required to ensure that the charging info is transferred.
Call flows
1-5	The call is initiated by UE-A by sending an INVITE request. The Request URI will include the URI of UE-B. The INVITE request is routed to the Originating AS and the Terminating AS. The INVITE request will indicate that 100rel extension is supported.
6-7	The Terminating AS will include the charging info in the INVITE request sent to the UE-B. 
8-28	UE-B sends a reliable provisional response to indicate that INVITE request is being processed.
29-35	UE-B answers with a 200 (OK) response (to the INVITE request) and sends it to UE-A.
36-42	UE-A sends an ACK request to acknowledge the 200 (OK) response (to the INVITE request) and the session is established successfully.
A.3.2	AOC-D
 EMBED Visio.Drawing.6  
Figure A.3.2.1: Charging info during the call (terminating)
This can be a continuation of figures A.3.1.1 or A.3.1.2.1.
Call flows
1-4	When the charging rate is changes, an INFO request is send from the terminating AS to UE-B. The AOC information is included in the INFO request.
A.3.3	AOC-E
Calling party clears
 EMBED Visio.Drawing.6  
Figure A.3.3.1: Calling party clears
The AOC information is provided for every communication after the communication has finished. This is provisioned in the AS. The AOC information is sent to the terminating user in the BYE request which is originated from UE-A.
Call Flow
The communication has been set up as a normal communication. 
1-5 	UE-A generates a BYE request to terminate the session, which is routed to the UE-B. When the Terminating AS receives the BYE request, it adds the AOC information.
6-10 	UE-B sends a 200 (OK) response towards UE-A.
Called party clears
 EMBED Visio.Drawing.6  
Figure A.3.3.2: Called party clears
The AOC information is provided for every communication after the communication has finished. This is provisioned in the AS. The charging info is sent to the terminating user in the 200 (OK) response, which is originated from UE-A. 
Call Flow
The communication has been set-up as a normal communication. 
1-5 	UE-B generates a BYE request to terminate the session, which is routed to UE-A. 
6-.10 	UE-A sends a 200 (OK) response towards UE-B. When the Terminating AS receives the 200 (OK) response, it adds the AOC information.
Annex B (informative):
Example of Filter Criteria
This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria evaluation.
An example of an IFC when the AOC service is active at the originating S-CSCF is:
-	Method: INVITE.
Annex C (normative):
Charging Information Elements
C.1	General
This annex describes the charging information to be provided to the served user. The AoC information model and UNI protocol mapping of the information elements is defined in 3GPP TS 32.280 [10].
C.2	AOC-S
The AOC-S service provides tariff information at the start of the call or when tariff changes occur during the call.
C.2.1	Charged Items
AOC-S can provide a list of charged items or a special charging arrangement.
Following charged items are thought applicable:
-	basic communication;
-	communication attempt;
-	communication setup;
-	operation of supplementary services.
The special charging arrangement excludes all other charged items and is therefore mentioned separately. As defined in 3GPP TS 32.280 [10], special charging arrangement for AOC-S is not supported in IMS.
C.2.1.1	Charged Item: basic communication
This expresses the rate for the basic communication. 
The rate shall be expressed as:
-	price per time unit and time unit (see subclause C.2.2.1); or
-	free of charge (see subclause C.2.2.2); or
-	flat rate (see subclause C.2.2.3); or
-	special charging code (see subclause C.2.2.4); or
-	not available (see subclause C.2.2.6).
As defined in 3GPP TS 32.280 [10], the special charging code for AOC-S is not supported in IMS.
C.2.1.2	Charged Item: communication attempt
This expresses the cost of a communication attempt.
The cost shall be expressed as:
-	free of charge (see subclause C.2.2.2); or
-	flat rate (see subclause C.2.2.3); or
-	special charging code (see subclause C.2.2.4); or
-	not available (see subclause C.2.2.6).
As defined in 3GPP TS 32.280 [10], the special charging code for AOC-S is not supported in IMS.
C.2.1.3	Charged Item: communication setup
This expresses the cost of a communication setup.
The cost shall be expressed as:
-	free of charge (see subclause C.2.2.2); or
-	flat rate (see subclause C.2.2.3); or
-	special charging code (see subclause C.2.2.4); or
-	not available (see subclause C.2.2.6).
As defined in 3GPP TS 32.280 [10], the special charging code for AOC-S is not supported in IMS.
C.2.1.4	Charged Item: operation of services
This expresses the cost induced by the execution of services.
The cost shall be expressed as:
-	price per time unit and time unit (see subclause C.2.2.1); or
-	free of charge (see subclause C.2.2.2); or
-	flat rate (see subclause C.2.2.3); or
-	special charging code (see subclause C.2.2.4); or
-	not available (see subclause C.2.2.6).
As defined in 3GPP TS 32.280 [10], the special charging code for AOC-S is not supported in IMS.
C.2.1.5	Special Charging Arrangement
This expresses that a special charging arrangement exists for calculating the costs of the call.
As defined in 3GPP TS 32.280 [10], the special charging arrangement element for AOC-S is not supported in IMS.
The cost shall be expressed as:
-	special charging code (see subclause C.2.2.4).
As defined in 3GPP TS 32.280 [10], the special charging code for AOC-S is not supported in IMS.
C.2.2	Expressing Charging Rates
AOC-S can express charging rate as:
-	price per time unit and time unit (see subclause C.2.2.1); or
-	free of charge (see subclause C.2.2.2); or
-	flat rate (see subclause C.2.2.3); or
-	special charging code (see subclause C.2.2.4); 
-	charging unit (see subclause C.2.2.5); or
-	not available (see subclause C.2.2.6).
As defined in 3GPP TS 32.280 [10], the special charging code for AOC-S is not supported in IMS.
C.2.2.1	Duration charge: Price per time unit, and unit time 
Duration charge shall contain the following elements:
-	currency identifier (see subclause C.5.4); and
-	currency amount (see subclause C.5.5); and
-	length of time unit (see subclause C.5.6); and
-	type of charging (see subclause C.5.8).
and additionally it may contain the following element:
-	granularity (see subclause C.5.7).
C.2.2.2	Specific: free of charge
This rate represents a free charge.
C.2.2.3	Specific: flat rate
It shall be expressed as:
-	currency identifier (see subclause C.5.4);
-	currency amount (see subclause C.5.5).
C.2.2.4	Specific: special charging code N.
It shall be expressed as an integer between 1..10.
As defined in 3GPP TS 32.280 [10], the special charging code for AOC-S is not supported in IMS.
C.2.2.5	Charging unit
Charging unit shall contain the following elements:
-	currency identifier (see subclause C.5.4); and
-	currency amount (see subclause C.5.5).
C.2.2.6	Not available
Expresses that the charging information is not available.
C.3	AOC-D
The AOC-D service provides information about the recorded charges during the active phase of a call.
The information shall contain the following elements:
-	type of charging information (see subclause C.3.1); and
-	recorded charges (see subclause C.3.2).
and additionally it may contain the following element:
-	billing identification (see subclause C.3.3).
As defined in 3GPP TS 32.280 [10], the billing identification element for AOC-D is not supported in IMS.
C.3.1	Type of charging information
Type of charging information shall have one of the following values:
-	subtotal charges; or
-	total charges.
C.3.2	Recorded charges
Recorded charges shall be expressed as one of the following elements:
-	recorded number of currency units or charging units (see subclause C.5.9); or
-	free of charge; or
-	not available.
C.3.3	Billing identification for AOC-D
It shall be expressed as one of the following values:
-	normal charging (default); or
-	reverse charging; or
-	credit card charging.
As defined in 3GPP TS 32.280 [10], billing identification for AOC-D is not supported in IMS.
C.4	AOC-E
The AOC-E service provides information about the recorded charges for a call when it is terminated.
The information consists of:
-	recorded charges (see subclause C.3.2)
-	billing identification (see subclause C.4.1).
As defined in 3GPP TS 32.280 [10], the billing identification element for AOC-E is not supported in IMS.
C.4.1	Billing identification for AOC-E
It shall be expressed as one of the following values:
-	normal charging (default); or
-	reverse charging; or
-	credit card charging;
-	call forwarding unconditional;
-	call forwarding busy;
-	call forwarding noreply;
-	call deflection;
-	call transfer.
As defined in 3GPP TS 32.280 [10], billing identification for AOC-E is not supported in IMS.
C.5	Common types/information elements
C.5.1	Time unit
Time unit shall be an integer value.
C.5.2	Decimal
Decimal shall be a decimal value.
C.5.3	Scale
The scale of time units shall have one of the following values:
-	0,01 s; 
-	0,1 s; 
-	1 s; 
-	10 s; 
-	1 min; 
-	1 hour; or
-	24 hours.
C.5.4	Currency identifier
It shall be a string specifying the used currency or a charging unit identifier. 
C.5.5	Currency amount
It shall be expressed as the value of decimal (see subclause C.5.2).
C.5.6	Length of time unit
It shall be expressed as value of integer × scale:
-	time unit (see subclause C.5.1); and
-	scale (see subclause C.5.3).
C.5.7	Granularity
This specifies the time unit applied for calculation of charges by the network.
It shall be expressed as value of integer × scale:
-	time unit (see subclause C.5.1); and
-	scale (see subclause C.5.3).
C.5.8	Type of charging	
Type of charging shall have one of the values of "step function" or "continuous".
C.5.9	Recorded number of currency units
It shall be expressed as:
-	currency identifier (see subclause C.5.4);
-	currency amount (see subclause C.5.5).
Annex D (normative):
AOC XML Schema, version 1.0:
This annex defines the XML Schema to be used for providing the charging information described in annex C in the SIP methods to the served user. As defined in 3GPP TS 32.280 [10], the information elements "special-arrangement", "special-code" and "billing-id" are not supported in IMS.
The application/vnd.etsi.aoc+xml MIME type used to provide the charging information requested by the served user shall be coded as following described: 



	
	
		
      XML Schema Definition to the charging information related to the Advice of Charge service.
       	
	
	
	

      
      		
      			
      			
      			
			
	      	
   		
      

     
      
      	
      		
      	   	
      	    	
      	
      	
      
      
      
      	   
	          
	          
	          
      	    	   
      	   
	   
      

      
      	   
	          
	          
      	    	   
      	   
	   
    


      
      	    
      	    	   
      	    	   
      	    	   
      	    	   
      	    	   
      	    
   		
      
      
      
      		
      			
      			
      			
      			
      			
      		
      
      
      
      		
      			
      			
      			
      			
      		
      

      
      		
      			
      			
      			
      			
      		
      

      
      		
      			
      			
      			
      			
      			
      		
      
 
     
     
     	    
     	    	   
             
     	    	   
     	    	   
     	    	   
     	    	   
     	    
     

     
     	    
     	    	   
             
     	    	   
	
   

   
   
	    
		   
		   
	
   

   
	   
		  
		  
		  
		  
		  
		  
		  
	
   
   
	
    
	     
		      
     		
    

  	
  
  		
  			
  			
  		
   

   	
   
      		
      			
      			
      			
      		
      
 
  
   
		
			
			
			
			
			
			
			
			
		
	
	
     
		
			
			
		
	

	
Annex E (informative):
IANA Registration templates
E.1	IANA registry for Application Media Types
E.1.1	IANA Registration template for application/vnd.etsi.aoc+xml
NOTE:	IETF RFC 4288 [9], section 9, states the process that applies in case of changes to the registry of media types. Any future changes to the format or to annex E.1.1 would invoke this procedure.
MIME media type name: 
application
MIME subtype name: 
vnd.etsi.aoc+xml
Required parameters: 
None
Optional parameters: 
"charset"	the parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in IETF RFC 3023 [8].
"sv" or "schemaversion"	the parameter's value is used to indicate:
-	the versions of the SIP AOC information XML schema that can be used to validate the AOC information XML body (if the MIME type and parameter are present in the Content-Type header field) or
-	the accepted versions of the AOC information XML body (if the MIME type and parameter are present in the Accept header field).
If the "sv" and "schemaversion" parameter are absent, it shall be assumed that version 1.0 of the AOC information XML body is supported.
Encoding considerations: 
Same as encoding considerations of application/xml as specified in IETF RFC 3023 [8]
Security considerations: 
Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [8].
In addition, this content type provides a format for exchanging information in SIP, so the security considerations from IETF RFC 3261 [7] apply.
Interoperability considerations: 
Same as Interoperability considerations as specified in section 3.1 of IETF RFC 3023 [8].
If both "sv" and "schemaversion" are specified, then the value of "schemaversion" MUST be ignored
Published specification: 
3GPP TS 24.647: "Advice Of Charge (AOC) using IP Multimedia (IM) Core Network (CN) subsystem", as published in subclause E.1.1, version 8.2.0.
Available via .
Applications which use this media: 
Applications that use the 3GPP IP multimedia (IM) Core Network (CN) subsystem as defined by 3GPP.
Intended usage: 
COMMON
Additional information :
1. Magic number(s) : none
2. File extension(s) : none
3. Macintosh file type code : none
4. Object Identifiers: none
Annex F (informative):
Change history

Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNew2007-03Publication as ETSI TS 183 0472.1.12007-12Conversion to 3GPP TS 24.4472.1.22007-12Technically identical copy as 3GPP TS 24.647 for further development2.1.32008-02Implemented C1-0800932.2.02008-04Implemented C1-0811152.3.02008-05Implemented C1-0818362.4.02008-07Implemented C1-082297 from CT1#542.5.02008-08Implemented C1-082956 from CT1#55
Sent to CT-41 plenary for approval.2.6.02008-09CT#41CP-080512Created version 8.0.0 after approval in CT-412.6.08.0.02008-12CT#42CP-08086500011Registration of MIME type with IANA8.0.08.1.02009-09CT#45CP-09066500032Aligning IANA registration of MIME type " application/vnd.etsi.aoc+xml "8.1.08.2.02009-12CT#46CP-09092000082Correction of AOC mandatory behaviour8.2.09.0.02010-03CT#47CP-1001210010AoC: ABNF correction9.0.09.1.02010-09CT#49CP-10049900152Correction of AoC UNI Protocol Mapping9.1.09.2.0




















 STYLEREF ZA 3GPP TS 24.647 V9.2.0 (2010-09)
 PAGE 2
 STYLEREF ZGSM Release 9


3GPP