CCN Programmer's Guide - DAACSCAPv2
CCN Programmer's Guide - DAACSCAPv2
Version 1.0
CCN 5
Disclaimer
The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.
Trademark List
All trademarks mentioned herein are the property of their respective owners.
These are shown in the document Trademark Information.
Contents
1 Introduction 1
1.1 Service Definition / Purpose 1
1.2 Notation 1
2 Service Contract 3
2.1 Overview 3
2.2 Supported Service Operations 6
5 Limitations 33
5.1 Range Limitations 33
Glossary 45
Reference List 47
1 Introduction
The service context defines how the DAAC Service is used for a specific
application, including exact usage of interface parameters, charging models
and configuration of the DAAC Service.
The SCAP service context provides online charging support based on Diameter
Credit Control. The service context is used for real-time cost and credit control
of content and service charging between the Charging System and application
servers.
1.2 Notation
Table 1 Notation
Icon Description
Operation() Message Operation
{Parameter} Mandatory parameter
[Parameter] Optional parameter
<Parameter> Mandatory fixed parameter (defines the fixed
position of a parameter in a message)
*Parameter Multiple instances of the parameter is possible
{[Parameter]} Optional parameter on the protocol but mandatory
for the specific scenario
= ‘data’ Data for a parameter, for example constants used
to distinguish different processing requested using
the same message
2 Service Contract
2.1 Overview
The actual value used to identify a charged service has to be configured both in
the serving element and the Service.
The Diameter Credit Control specification, Reference [3], allows a DCC client
to omit the Service-Identifier AVP for a service context with only one defined
service. This is not allowed for the SCAP service context – even if only one
service is to be charged for. That is, the Service-Identifier is mandatory in the
SCAP service context.
The serving element should not report more used units than have been granted
in order to not risk that there is not enough credit on the account. If this
occurs, the Service will deduct the account with the cost of the reported usage,
including the over usage.
The Service can request, report and be granted the following unit types:
• CC-Time
• CC-Money
• CC-Service-Specific-Units
• CC-Total-Octets
• CC-Uplink-Octets
• CC-Downlink-Octets
It is not allowed to request, report and get multiple unit types for a service in
a request. Only the unit type that has been granted is allowed to be reported
as used.
The SCAP service context will not make use of Continuous Time tariff
handling. That is, the serving element must always be prepared to handle
the Tariff-Time-Change AVP.
2.1.7 Toll-free
It is possible to configure the Service so that a particular service is defined to
be toll-free. A toll-free service is also Out-of-credit-control, meaning that when
credits for the service are sought, the response from the Service will be 4011 -
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE.
When the Service has responded with 4011 it necessarily does not mean that
the rendered service will be toll-free. The serving element is still expected to
produce CDR’s in order to be able to perform off-line charging.
The exact behavior of the serving element and how to handle toll-free and
off-line charging is out-of-scope of this service contract.
2.1.8 Free-of-charge
It is possible to configure the Service so that a particular service is
free-of-charge. A free-of-charge service is no different than any other service,
from the serving element point of view, except that Cost-Information indicates
no cost. The units sought will be granted and the client is expected to report
usage as normal.
The value of the request number in EVENT and INITIAL requests must
be zero. The value of the request number in UPDATE and FINAL
requests must be received consecutively. The result code 5004 -
DIAMETER_INVALID_AVP_VALUE will be returned to the serving element if
an incorrect value of the request number is received.
The serving element is not allowed to use asynchronous signaling towards the
service, even when using MSCC. That is, the serving element must wait for and
answer to a CCR before issuing a new.
If the service detects a violation to this rule, the result code 5012 -
DIAMETER_UNABLE_TO_COMPLY is returned to the serving element.
If the service has decided that the serving element has reached the allowed
credit limit for the last service, the service will send Result-Code 4012
(DIAMETER_CREDIT_LIMIT_REACHED) on the command line to the serving
element and will not expect a CCR (FINAL_INTERROGATION) from the
serving element.
• Direct Debit
• Refund
Note: Service Operations Balance Check and Price Enquiry are not
supported by this service context. The result code 5003 -
DIAMETER_AUTHORIZATION_REJECTED will be returned to the
serving element if a not supported operation is received.
The Service Operation Refund is only possible with the unit type is CC-Money.
The result code 5012 - DIAMETER_UNABLE_TO_COMPLY will be returned to
the serving element if any other unit type is used for Refund.
The Other-Party-Id AVP (AVP code 1075) holds an identifier of the other party
involved in a session in addition to the Subscription-Id. The other party is
related to the session but not charged for the session. The other party could
be for example a calling party, a called party, a redirecting party, a sender or a
receiver; depending on service. The Other-Party-Id AVP is a grouped AVP as
specified below.
Other-Party-Id ::= < AVP Header: 1075, Vendor Id: 193 >
{ Other-Party-Id-Type }
{ Other-Party-Id-Data }
[ Other-Party-Id-Nature ]
*[ AVP ]
The Other-Party-Id AVP is in this service context defined as ‘static’ and ‘cached’.
The serving element is not allowed to use the *[AVP] part of the Other-Party-Id
since it’s reserved for internal use within the Service.
• UNKNOWN 0
• INTERNATIONAL 1 (default)
• NATIONAL (SIGNIFICANT) 2
END_USER_E164 0
END_USER_IMSI 1
END_USER_SIP_URI
2
END_USER_NAI 3
The Traffic-Case AVP (AVP code 1082) is of type Unsigned32 and holds the
traffic case for the charged event.
The use of the AVP is operator specific, and configured in the Service. The
Service will not relate the value of the AVP to the time given in Validity-Time
or vice versa.
If the Service has been incorrectly configured, there is a risk that the serving
element receives a value in the AVP larger than provided Validity-Time.
The use of the AVP is operator specific, and configured in the Service.
The use of the AVP is operator specific, and configured in the Service.
400–599 OctetString
600–MAXRANGE Reserved for future use. MAXRANGE
is defined as the maximum range of
the unit type.
3.3.1 Description
The serving element contacts the Service in order to verify that the requested
service/services are allowed. The possible results of the session establishment
are:
• Allowed, the session will continue (for multiple services, at least one service
is allowed).
The Service reports the result of the establishment request back to the serving
element.
{[Subscription-Id]} Subscription-Id
[Service-Identifier] Service-Identifier Mandatory when
MSCC is not used.
[Requested-Service-Unit] Requested-Service-Unit Mandatory when
MSCC is not used.
[CC-Time]
[CC-Money]
[CC-Total-Octets]
[CC-Input- Octets]
[CC-Output- Octets]
[CC-Service-Specific-Units]
[Multiple-Services-Indicator] Multiple-Services-Indicator
*[Multiple-Services-Credit-C Multiple-Services-Credit-C See Table 5.
ontrol] ontrol
*[Service-Parameter-Info] Service-Parameter-Info Cached parameters
A value of the Servic
e-Parameter-Type is
only allowed once in a
request per service.
[Proxy-Info]
[Route-Record]
[Account-Location] Application-Specific-Inform The value of the
ation parameter will be used
in the authorization and
accounting analysis in
this and all following
requests in the session.
[Subscription-Id-Location] Application-Specific-Inform The value of the
ation parameter will be used
in the authorization and
accounting analysis in
this and all following
requests in the session.
[Other-Party-Id] Application-Specific-Inform The value of the
ation parameter will be used
in the authorization and
accounting analysis in
this and all following
requests in the session.
Table 5 Protocol Bindings for Credit Control Session, Initial Request, MSCC
Credit Control Session, Initial Request, MSCC Group Parameter
DCC AVP Semantic Parameter Service Operation
Specific Handling
{[Requested-Service-Unit]}
[CC-Time]
[CC-Money]
[CC-Total-Octets]
[CC-Input- Octets]
[CC-Output- Octets]
[CC-Service-Specific-Units]
{[Service-Identifier]} Service-Identifier
[Other-Party-Id] Application-Specific-Inform The value of the
ation parameter will be used
in the authorization and
accounting analysis in
this and all following
requests in the session.
[Service-Provider-Id] Application-Specific-Inform The value of the
ation parameter will be used
in the authorization and
accounting analysis in
this and all following
requests in the session.
*[Failed-AVP] Failed-AVP
[Result-Code-Extension] Application-Specific-Inform
ation
[Time-Quota-Threshold] Application-Specific-Inform
ation
[Volume-Quota-Threshold] Application-Specific-Inform
ation
[Unit-Quota-Threshold] Application-Specific-Inform
ation
Table 7 Protocol Bindings for Credit Control Session, Initial Answer, MSCC
Credit Control Session, Initial Answer, MSCC Group Parameter
DCC AVP Semantic Parameter Service Operation
Specific Handling
[Granted-Service-Unit] Granted-Service-Unit
[Tariff-Time-Change ]
[CC-Time]
[CC-Money]
[CC-Total-Octets]
[CC-Input- Octets]
[CC-Output- Octets]
[CC-Service-Specific-Units]
{[Service-Identifier]} Service-Identifier
[Validity-Time] Validity-Time
{[Result-Code]} Result-Code
[Final-Unit-Indication] Final-Unit-Indication
[Result-Code-Extension] Application-Specific-Inform
ation
*[Failed-AVP] Application-Specific-Inform
ation
[Time-Quota-Threshold] Application-Specific-Inform
ation
[Volume-Quota-Threshold] Application-Specific-Inform
ation
[Unit-Quota-Threshold] Application-Specific-Inform
ation
3.4.1 Description
An Update will prolong an ongoing charging session in-between the serving
element and the Service. The serving element contacts the Service, in order to
verify that the requested Service Operation is allowed.
Table 9 Protocol Bindings for Credit Control Session, Update Request, MSCC
Credit Control Session, Update Request, MSCC Group Parameter
DCC AVP Semantic Parameter Service Operation
Specific Handling
[Requested-Service-Unit] Requested-Service-Unit
[CC-Time]
[CC-Money]
[CC-Total-Octets]
[CC-Input- Octets]
[CC-Output- Octets]
[CC-Service-Specific-Units]
*[Used-Service-Unit] Used-Service-Unit
[Tariff-Change-Usage]
[CC-Time]
[CC-Money]
[CC-Total-Octets]
[CC-Input- Octets]
[CC-Output- Octets]
[CC-Service-Specific-Units]
{[Service-Identifier]} Service-Identifier
[Other-Party-Id] Application-Specific-Inform The parameter must,
ation if sent, have the same
value as in the initial
request.
[Service-Provider-Id] Application-Specific-Inform The parameter must,
ation if sent, have the same
value as in the initial
request.
[Route-Record]
*[Failed-AVP] Failed-AVP
[Result-Code-Extension] Application-Specific-Inform
ation
[Time-Quota-Threshold] Application-Specific-Inform
ation
[Volume-Quota-Threshold] Application-Specific-Inform
ation
[Unit-Quota-Threshold] Application-Specific-Inform
ation
3.5.1 Description
A Terminate related to a charging session will end the session. The serving
element contacts the Service in order to adjust the account’s balance with the
used value.
3.6.1 Description
A Direct Debit request for a service will be initiated. The Service will calculate
the cost based on the received charging input and adjust the account. The
response will include the granted units and as an option cost information, that
is, the total cost for the service.
[Account-Location] Application-Specific-Inform
ation
[Subscription-Id-Location] Application-Specific-Inform
ation
[Other-Party-Id] Application-Specific-Inform
ation
[Service-Provider-Id] Application-Specific-Inform
ation
{[3GPP-MS-TimeZone]} Application-Specific-Inform
ation
[Traffic-Case] Application-Specific-Inform
ation
*[Failed-AVP] Failed-AVP
[Result-Code-Extension] Application-Specific-Inform
ation
3.7 Refund
3.7.1 Description
A Refund request related to a service with unit type set to money will be
initiated. The Service executes a cost calculation based on the received
charging input for the service and makes a Refund to the account.
*[Failed-AVP] Failed-AVP
[Result-Code-Extension] Application-Specific-Inform
ation
The SCAP service context is functionally backward compatible with the Service
Charging Application Protocol as described in Programmer's Guide - Service
Charging Based on Diameter, Reference [1].
This means that the charging functionality that was possible to build using
Reference [1] shall also be possible with this service context.
Some limitations/changes have been notices and are explained in the following
sub-chapters.
4.3 Service-Parameter-Info
The use of the Service-Parameter-Info has changed a lot between SCAP
and the SCAPv2 service context. Table 20 defines the differences between
the two protocols.
5 Limitations
The serving element cannot handle the full range of this parameter and will treat
these parameters as signed 64 bit instead, that is, Integer64 (-263 – 263-1).
6.1 Definitions
A Grouped [AVP] that is defined to be static must provide the same information
in all upcoming request, but the order of the included parameters may change.
Another example is the Subcription-Id AVP where the key to the data is
Subcription-Id-Data AVP.
[Destination-Host] No N/A No No
[User-Name] No N/A Yes N/A
[Acct-Multi-Session- No N/A Yes N/A
Id]
[Origin-State-Id] No N/A No No
[Event-Timestamp] No N/A No No
*[Subscription-Id] Yes Subscription Yes N/A Static group
-Id-Data ed *AVP; All
‘sub-AVP’ are
static.
[Service-Identifier] No N/A No N/A
[Termination-Cause] No N/A No N/A
[Requested-Service- Yes Table 24 N/A N/A
Unit]
[Requested-Action] No N/A No No
*[Used-Service-Unit] Yes Table 25 No No
[Multiple-Services-In No N/A Yes N/A
dicator]
[Multiple-Services-In No N/A Yes N/A
dicator]
*[Multiple-Services-C Yes Table 23 N/A N/A
redit-Control]
*[Service-Parameter- Yes Service-Para No Yes Cached
Info] meter-Info-T grouped
ype *AVP; Each
instance,
identified
by Key,
is cached
individually
[CC-Correlation-Id] No N/A No No Not used
in SCAPv2
service
context
[User-Equipment-Inf Yes N/A Yes N/A Static group
o] ed AVP; All
‘sub-AVP’ are
static
*[Proxy-Info] Yes Proxy-Host No No Grouped
*AVP
*[Route-Record] Yes None No No *AVP
Table 27 defines the AVP Flag Rules for the SCAPv2 service context as well
as the Vendor-Id used for Vendor Specific AVPs. Vendor Specific AVPs from
Ericsson (193) and 3GPP (10415) are used.
Glossary
AVP
Attribute Value Pair
CC
Country Code
CCN
Charging Control Node
CDR
Charging Data Record
DAAC
Diameter Accounting and Authorization
Control
DCC
Diameter Credit Control
LSP
Locally Significant Part
MNP
Mobile Number Portability
NDC
National Destination Code
RSU
Requested Service Unit
SCAP
Service Charging Application Protocol
Reference List