PICS - DCA (1.0.3-04.00)

8/12/2019 PICS - DCA (1.0.3-04.00)

1/59

Oracle Communications Network Charging and Control

Product: OCNCC 4.3

Component: Diameter Control Agent

Protocol Implementation ConformanceStatement

Sware version: Release 1.0.3

Guide version: 04.00

Release date: December 2010

Status: Approved

8/12/2019 PICS - DCA (1.0.3-04.00)

2/59

Commercial In Confidence

Copyright

Diameter Control Agent Protocol Implementation Conformance Statement,Release 1.0.3

04.00

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreementcontaining restrictions on use and disclosure and are protected by intellectualproperty laws. Except as expressly permitted in your license agreement or allowedby law, you may not use, copy, reproduce, translate, broadcast, modify, license,transmit, distribute, exhibit, perform, publish, or display any part, in any form, or byany means. Reverse engineering, disassembly, or decompilation of this software,unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is notwarranted to be error-free. If you find any errors, please report them to us inwriting.

If this software or related documentation is delivered to the U.S. Government oranyone licensing it on behalf of the U.S. Government, the following notice isapplicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and relateddocumentation and technical data delivered to U.S. Government customers are"commercial computer software" or "commercial technical data" pursuant to theapplicable Federal Acquisition Regulation and agency-specific supplementalregulations. As such, the use, duplication, disclosure, modification, and adaptationshall be subject to the restrictions and license terms set forth in the applicableGovernment contract, and, to the extent applicable by the terms of theGovernment contract, the additional rights set forth in FAR 52.227-19, CommercialComputer Software License (December 2007). Oracle USA, Inc., 500 Oracle

Parkway, Redwood City, CA 94065.This software is developed for general use in a variety of information managementapplications. It is not developed or intended for use in any inherently dangerousapplications, including applications which may create a risk of personal injury. Ifyou use this software in dangerous applications, then you shall be responsible totake all appropriate fail-safe, backup, redundancy, and other measures to ensurethe safe use of this software. Oracle Corporation and its affiliates disclaim anyliability for any damages caused by use of this software in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Othernames may be trademarks of their respective owners.

This software and documentation may provide access to or information on content,products, and services from third parties. Oracle Corporation and its affiliates arenot responsible for and expressly disclaim all warranties of any kind with respect tothird-party content, products, and services. Oracle Corporation and its affiliates willnot be responsible for any loss, costs, or damages incurred due to your access toor use of third-party content, products, or services.

Page ii Diameter Control AgentProtocol Implementation Conformance Statement

8/12/2019 PICS - DCA (1.0.3-04.00)

3/59


Contents

Copyright .............................................................................Error! Bookmark not defined.About this Document ........................................................................................................... vDocument Conventions ...................................................................................................... vi

Chapter 1

Compliance StatementOverview .............................................................................................................................. 1DCA Overview ..................................................................................................................... 2

Chapter 2Diameter Message Encoding

Overview .............................................................................................................................. 3Diameter Message Encoding .............................................................................................. 4

Chapter 3Connection Management

Overview .............................................................................................................................. 7Introduction .......................................................................................................................... 8Capabilities Exchange Messages........................................................................................ 9Disconnect Peer Messages ............................................................................................... 10Device Watchdog Messages ............................................................................................. 11Message Retransmission and Duplicate Detection ........................................................... 12

Chapter 4Credit Control Requests

Overview ............................................................................................................................ 15Credit Control Request AVPs ............................................................................................ 16INAP Extension Mappings ................................................................................................. 20Example Control Plans ...................................................................................................... 21Abort Session Request (ASR) ........................................................................................... 23Scenarios ........................................................................................................................... 24

Chapter 5Compliance Tables

Overview ............................................................................................................................ 29Compliance to RFC 3588 .................................................................................................. 30

Compliance to RFC 4006 .................................................................................................. 363GPP TS 32.299 V6.3.0 .................................................................................................... 43

AppendixOverview ............................................................................................................................ 45Glossary of Terms ............................................................................................................. 47Index .................................................................................................................................. 51

Diameter Control Agent Page iiiProtocol Implementation Conformance Statement

8/12/2019 PICS - DCA (1.0.3-04.00)

4/59

8/12/2019 PICS - DCA (1.0.3-04.00)

5/59


Diameter Control Agent Page v

About this Document

The purpose of this document is to describe the Oracle implementation of theDiameter protocol for the purposes of real-time charging, from a Diameter Credit-Control Server perspective.

Scope

This guide is intended for use by software engineers and testers that need adescription of the UAS Credit-Control messages used by the DCA.

Audience

It is in addition to the functional details provided by the Diameter Control AgentUser and Technical Guide. It is assumed that readers are familiar with PrePaidCharging and the Diameter RFCs.

The following documents are related to this document:Relateddocuments

RFC 3588 Diameter Base Protocol

RFC 4006 Diameter Credit Control Application

Diameter Control Agent User and Technical Guide

Diameter and Diameter Control Agent SRS 3GPP TS 32.299 V6.3.0 (2005-06) - 3rd Generation Partnership Project;

Technical Specification Group Service and System Aspects;Telecommunication management; Charging management; Diameter chargingapplications (Release 6)

Here are the changes to the document since the last release.Changes in thisdocument

Versionno.

Revision DateDescription

01.00 2009-07-24 Initial version for DCA 1.0.1

02.00 2010-07-06 Updates for 1.0.3, mostly for multiple sessions.03.00 2010-07-26 Added Abort-Session-Request information.

04.00 2010-10-06 Re-branded to Oracle.

Protocol Implementation Conformance Statement

8/12/2019 PICS - DCA (1.0.3-04.00)

6/59


Document Conventions

Before you start using this guide, it is important to understand the terms andtypographical conventions used in the documentation.

Typographicalconventions

Specialised terms and acronyms are defined in the Glossary at the end of this

guide.

Formatting convention Type of information

Special Bold Items you must select such as menu options,or names of tabs.

Emphasis within text.

Names of database tables and fields.

Italics Name of a document, chapter, topic or otherpublication.

Button The name of a button to click or a key to

press.Example: To close the window, either clickClose or press Esc.

Key+Key Key combinations for which the user mustpress and hold down one key and then pressanother.

Example: Ctrl+P, or Alt+F4.

Monospace Text that you must type and examples of codeor standard output.

variable Used to indicate variables or text that should

be replaced.

menu option > menu option > Used to indicate the cascading menu option tobe selected, or the location path of a file.

Example: Operator Functions > Report Functions

Example: /IN/html/SMS/Helptext/

hypertext link Used to indicate a hypertext link on an HTMLpage.

The following icons are used as visual cues to draw attention to importantinformation.

Icons

Note: Indicates useful and complementary information. Explanation, comment, or

short expansion of the text object that is intended to catch your attention.

Tip: Indicates practical but non-essential information that makes the solutioneasier to use or operate (e.g. keyboard shortcut, alternative way to perform a stepin a procedure, etc).

Warning: Indicates a caution. If this information is ignored, it could cause possibleand irreversible damage to the equipment, data or software.

Page vi Diameter Control AgentProtocol Implementation Conformance Statement

8/12/2019 PICS - DCA (1.0.3-04.00)

7/59


Chapter 1

Compliance Statement

Overview

This chapter introduces the Diameter Control Agent (DCA) compliance limitations.Introduction

This chapter contains the following topics.

DCA Overview.................................................................................................2

In this chapter

Diameter Control Agent Page 1Protocol Implementation Conformance Statement

8/12/2019 PICS - DCA (1.0.3-04.00)

8/59

Chapter 1 Commercial In Confidence

DCA Overview

The Diameter Control Agent (DCA) is an interface used by PrePaid Charging toallow processing of Diameter based billing requests utilising existing Oracle UASand Charging infrastructure.

Introduction

The Diameter base protocol is defined by RFC 3588, and extended to include real-time credit-control messages by RFC 4006.

In addition, the Diameter protocol defined by RFC 4006 is further extended byGPP TS 32.299 V6.3.0 Diameter charging applications.

The DCA (and thus this document) only covers the use of PrePaid Charging as aDiameter Credit Control server. For information about PrePaid Charging acting asa Diameter Credit Control Client, see the Diameter Control Driver (DCD)documentation.

DCA Coverage

The DCA server runs on the UAS SLEE, taking inbound requests from DiameterCredit-Control clients and passing them to PrePaid Charging for further

processing. This may involve passing the request on to an existing billing engineusing a different protocol such as FOX, OSA or Diameter.

DCA Server

The DCA server maintains the connections to the Diameter Credit-Control client(or, if configured, intermediate Diameter peer, such as a proxy).

Specific adherence to the RFCs is described in a later section, but there are somegeneral properties of Diameter that are not handled by the DCA.

Generalrestrictions

These are:

TLS (RFC 2246) is not supported.

Authentication and Authorisation messages are not supported

Tariff Time Change is not supported

Dynamic peer discovery is not performed.

SNMP client alarm generation (USMS alarm mechanism is used instead)

There is no expectation to provide Network Access Services (NAS) serverfunctionality as part of the Oracle Diameter implementation. Note that thisdoes not prohibit existing Diameter based NAS servers acting as DiameterCredit Control clients, for the purposes of billing a service.

Page 2 Diameter Control AgentProtocol Implementation Conformance Statement

8/12/2019 PICS - DCA (1.0.3-04.00)

9/59


Chapter 2

Diameter Message Encoding

Overview

This chapter details the Diameter Control Agent (DCA) compliances.Introduction


Diameter Message Encoding..........................................................................4

In this chapter


8/12/2019 PICS - DCA (1.0.3-04.00)

10/59


Diameter Message Encoding

The DCA client will send (and expect to receive) Diameter messages that have abasic encoding in compliance with RFC 3588.

Introduction

The header of Diameter messages sent by DCA are fully compliant with RFC3588.Diameter Headers

The individual parameters are:

Field Type/Length Comment

Version 1 byte Always set to 1

Message Length 3 bytes Length includes header fields.

Command Flags 1 byte Format: RPETrrrr

All set as per RFC 3588.

Command Code 3 bytes Will be one of:

257 (CER/A)

280 (DWR/A) 282 (DPR/A)

272 (CCR/A)

Application ID 4 bytes Set to 4 for CCRs, 0 for all other message types.

Hop-by-hopidentifier

Unsigned32; 4 bytes as per RFC 3588

End-to-endidentifier

Unsigned32; 4 bytes as per RFC 3588

The header on an AVP consists of the following fields:Attribute-ValuePairs (AVPs)

Field Type/Length CommentAVP Code 4 bytes

AVP Flags 1 byte Format: VMPrrrrr:

V = vendor bit. Will be set only if a vendor-ID isused.

M = mandatory bit: If the AVPCode is from RFC3588 or 4006, the bit is set. Otherwise (eg avendor specific AVP code), the bit is not set.

P = encryption indicator. Set to 0.

AVP Length 3 bytes AVP length in bytes, including these headerfields.

Vendor-ID 4 bytes Will be 0 for RFC 3588 and 4006 AVPs, or 16247for Oracle specific AVPs.

Data As specified by the AVP code and length.

The DCA can send and receive the all basic and derived data types mentioned inRFC 3588. Where the data types are used, they are encoded in completecompliance with RFC 3588 and RFC 2279.

AVP Data Types

Continued on next page


8/12/2019 PICS - DCA (1.0.3-04.00)

11/59

Commercial In Confidence Chapter 2

Diameter Message Encoding, Continued

AVP Data Types (continued)

INAP extensions

The following may be mapped to INAP extensions:

OctetString

Integer32

Integer64

Unsigned32

Unsigned64

Float32

Float64

Address

Time

UTF8String

DiameterIdentity

Enumerated

Note: The OctetString type can have number values as an array of either ASCIIcharacters or integers.

Extension formats

Supported INAP extension formats are:

inapnumber

inapaddressstring

inaptbcdstring

inapgenericnumber octets


8/12/2019 PICS - DCA (1.0.3-04.00)

12/59

8/12/2019 PICS - DCA (1.0.3-04.00)

13/59


Diameter Control Agent Page 7

Chapter 3

Connection Management

Overview

This chapter covers the connection management compliances.Introduction


Introduction......................................................................................................8Capabilities Exchange Messages...................................................................9Disconnect Peer Messages...........................................................................10Device Watchdog Messages.........................................................................11Message Retransmission and Duplicate Detection......................................12

In this chapter


8/12/2019 PICS - DCA (1.0.3-04.00)

14/59


Introduction

The DCA server will accept inbound connections initiated by Diameter Credit-Control clients as per RFC 3588. However, the DCA will only allow connectionsfrom peers that are in its configured list. CERs from unknown peers will have a

CEA message sent before the client closes the connection. DCA will not initiateconnections to unconnected peers. Connections can be over either TCP or SCTP.

Introduction

To manage the connections, the following messages from RFC 3588 are used:

Capabilities Exchange Request (CER)

Capabilities Exchange Answer (CEA)

Device Watchdog Request (DWR)

Device Watchdog Answer (DWA)

Disconnect Peer Request (DPR)

Disconnect Peer Answer (DPA)


8/12/2019 PICS - DCA (1.0.3-04.00)

15/59


Capabilities Exchange Messages

The DCA will receive CER messages and respond with CEA messages, as performats specified in RFC 3588. The content of the individual fields is as follows:

CapabilitiesExchangeMessages

Field AVPCode

Data Type Comment

Origin-Host 264 DiameterIdentity Set from configuration. Default ishostname.

Origin-Realm 296 DiameterIdentity Set from configuration. Default ishostname.

Host-IP-Address 257 Address Set from configuration. Default isINADDR_ANY.

Vendor-ID 266 Unsigned32 Set from configuration (Oracle vendor IDis 16247)

Product-Name 269 UTF8String Set from configuration

Origin-State-Id 278 Unsigned32 Used to detect a re-booting peer andwipe sessions for the host if it hasrebooted.

Supported-Vendor-Id 265 Unsigned32 Not included.

Auth-Application-Id 258 Unsigned32 Must be as specified in configuration.Default is 4 (Credit-Control). InboundCER messages will be rejected.

Inband-Security-Id 299 Unsigned32 Set to 0 (NO_INBAND_SECURITY)

Acct-Application-Id 259 Unsigned32 Not included.

Vendor-Specific-Application-Id

260 Grouped Not included.

Firmware-Revision 267 Unsigned32 Not included.Result-Code 268 Unsigned32 set as per RFC 3588.

Error-Message 281 UTF8String human readable string, as per RFC3588.

Failed-AVP 279 Grouped set as per RFC3588.


8/12/2019 PICS - DCA (1.0.3-04.00)

16/59


Disconnect Peer Messages

A literal interpretation of RFC 3588 could assume that after either side sends aDPR message, the receiving peer should never again attempt to reconnect theconnection. On shutdown DCA will send a DPR message. It is worth noting that

the client might take this literal interpretation and never try to reconnect, in thiscase the client may need to be reinitialised / restarted.

Disconnect PeerMessages

The possible fields are as follows:

Field AVPCode

Data Type Comment

Origin-Host 264 DiameterIdentity Set from configuration. Default ishostname.

Origin-Realm 296 DiameterIdentity Set from configuration. Default ishostname

Disconnect-Cause 273 Enumerated The only cause sent by the DCA is 2,DO_NOT_WANT_TO_TALK_TO_YOU

Result-Code 268 Unsigned32 set as per RFC 3588.




8/12/2019 PICS - DCA (1.0.3-04.00)

17/59


Device Watchdog Messages

Provision is to be made for determining if there has been a transport failure bysupporting the Device Watchdog Request (DWR) and Device Watchdog Answer(DWA) messages. This necessitates the ability to receive DWR messages and

send an appropriate DWA message as a response. The purpose of this is that if aclient detects a connection failure to the server then it should make a periodicattempt to reconnect.

Device WatchdogMessages

The length of the silent interval that must preceed a DWR message isconfigurable. The possible fields are as follows:

Field AVPCode

Data Type Comment

Origin-Host 264 DiameterIdentity Set from configuration. Default ishostname

Origin-Realm 296 DiameterIdentity Set from configuration. Default ishostname.

Origin-State-Id 278 Unsigned32 Used to detect a re-booting peer andwipe sessions for the host if it hasrebooted.

Result-Code 268 Unsigned32 set as per RFC 3588.




8/12/2019 PICS - DCA (1.0.3-04.00)

18/59


Message Retransmission and Duplicate Detection

In Diameter clients (and agents) may retransmit messages, where an unexpectedfailure has occurred. This may occur when a client has sent a request, but has notreceived a reply, within a specified period. This retransmission behaviour can

potentially lead to duplicates being sent. In such cases clients which sendmessages, which may be duplicates, may indicate the possibility that asubsequent message is a duplicate by setting the T command flag / bit (refer toChapter 3 Diameter Header of RFC 3588).

RFC 3588 andEvent BasedCredit-ControlDuplicate

Detection

Note: The T-flag not being set is not necessarily a definitive indicator that noduplicate is present.

End to end identifier

The DCA uses the End-to-End Identifier for detecting duplicate messages (inconjunction with the Origin-Host AVP). The DCA also ensures that answers musthave the same identifier as in the original request. In addition duplicate requestsresult in essentially the same response, but should not affect state (i.e. in Credit-Control duplicate billing must not occur).

Non-volatile storage

Non-volatile storage of End-to-End identifier or recently sent responses is notsupported, due to the significant processing overhead this can introduce.

Duplicate message

The case where a duplicate arrives at a different UAS is also not supported. Forreal-life deployments each UAS should be treated as a separate realm in order toavoid double processing of duplicates. This means that the realm name andhostname may effectively be the same for each DCA UAS.

Note: Duplicate detection is not applied to Device Watchdog messages.

General duplicate detection

The following generalised approach is utilised for the detection of duplicates.

When the server receives a message which is a candidate for duplicate detection:

1 The code searches a map of recently received messages for a matching End-to-End Identifier.

2 If a duplicate message was encountered:

Resend the original response (which should have been remembered).

3 If NO duplicates were detected in either backwards time frame or the originalmessage was late:

Process the message like normal (i.e. assume the message was never dealtwith in the first place).

For Session-based CCR messages (i.e. those with Requested-Action AVP of:Session BasedCredit-ControlDuplicateDetection

INITIAL_REQUEST

TERMINATION_REQUEST, or

UPDATE_REQUEST)

duplicate detection is based on the mechanism described in RFC 4006. That is,duplicate detection for session based messages is performed using the Session-IdAVP, and CC-Request-Number AVP, in conjunction with the Credit-Control serversown internal state, for non Multiple-Services-Credit-Control cases.



8/12/2019 PICS - DCA (1.0.3-04.00)

19/59


Message Retransmission and Duplicate Detection, Continued


Session Based Credit-Control Duplicate Detection (continued)

The CC-Request-Number is used to detect out of sequence messages, and isexpected to be sequential (as suggested by RFC 4006).

However this does not hold for Multiple-Services-Credit-Control, due to the factthat CC-Request-Number will not necessarily be sequential. This is becauseclients are not required to wait for a CCA before sending a new Credit-Control-Request (CCR) message. This might happen if a client sends a new CCR for adifferent service (than those currently pending response), when that servicerequires further authorisation to use more units.

For Multiple-Services-Credit-Control, a lookup is performed based on the inboundCC-Request-Number. If one is found, it can be assumed to be a duplicate and thesame answer returned.

8/12/2019 PICS - DCA (1.0.3-04.00)

20/59

8/12/2019 PICS - DCA (1.0.3-04.00)

21/59



Chapter 4

Credit Control Requests

Overview

This chapter describes the mappings between INAP parameters and DiameterAVPs

Introduction


Credit Control Request AVPs........................................................................16INAP Extension Mappings.............................................................................20Example Control Plans..................................................................................21Abort Session Request (ASR).......................................................................23Scenarios......................................................................................................24

In this chapter


8/12/2019 PICS - DCA (1.0.3-04.00)

22/59


Credit Control Request AVPs

This table describes the function of each AVP.AVP Listdescriptions

AVP Name Action

Session-Id Used to identify the relevant session.

Origin-Host Used to identify sender.

Origin-Realm Used to identify sender.

Destination-Realm Used to identify the realm of the target Credit Control Server(normally expected to be the machine DCA is running on)

Auth-Application-Id Disregarded if not 4 (Diameter Credit-Control)

Service-Context-Id Used as part of the key to look up the service.

CC-Request-Type Used as part of the key to look up the service.

Also used to determine the next state.

CC-Request-Number Used in duplicate detection.

Destination-Host Used to identify the host of the target Credit Control Server(normally expected to be the machine DCA is running on)

User-Name Ignored unless mapped to an IDP extension by the AVPmappings in eserv.config.

CC-Sub-Session-Id Ignored.

We do not support multiple session IDs but some clients may setthis anyway. If so this will be ignored.

Acct-Multi-Session-Id Ignored.

We do not support multiple session IDs but some clients may setthis anyway. If so this will be ignored.

Origin-State-Id Used to detect a client re-booting and wipe sessions for the host

if it has rebooted.

Event-Timestamp For EVENT_REQUEST messages, this gets copied into IDPextension type 504

Subscription-Id Gets copied to IDP extension type 505. If this is an E 164number, it also gets copied to CallingPartyNumber, afterapplying the configured normalisation rules.

Service-Identifier Used as part of the key to look up the service.

Termination-Cause May be traced if tracing is enabled.

Otherwise, ignored.

Requested-Service-Unit The type of the service unit (derived from which sub-AVP iscontained within this one) is placed in IDP extension type 502.

The value of the sub-AVP is placed in IDP extension type 501.

Multiple unit type is not supported and, if present, a Credit-Control-Answer message of the following form will be returned:CCA(Result-Code=DIAMETER_AVP_UNSUPPORTED,FAILED-AVPS=these AVP, maybe others)

Requested-Action Used as part of the key to look up the service.

Also used to determine the next state.



8/12/2019 PICS - DCA (1.0.3-04.00)

23/59


Credit Control Request AVPs, Continued

AVP List descriptions (continued)

AVP Name Action

Used-Service-Unit The cumulative total of all the Used-Service-Unit AVPs ismultiplied by 10 (to create deci-seconds) and used to identify thetotal used units for the call.

Multiple-Services-Indicator If Multiple Services Emulation is enabled in DCA and thereceived Multiple-Services-Indicator is set toMULTIPLE_SERVICES_SUPPORTED, DCA will accept theincoming message and subsequent Multiple-Services-Credit-Control AVPs if received in CCR/CCA update and CCR/CCAfinal request messages.

Multiple-Services-Credit-Control

Requires that Multiple-Services-Indicator AVP has beenreceived, with value set toMULTIPLE_SERVICES_SUPPORTED.

If more than one unit type is received within this AVP, DCA willrecognise the used-service-unit AVP in update and terminationrequest messages and extract the relevant unit used. If norelevant unit is found, DCA will return CCA (Multiple-Services-Credit-Control( Result-Code =DIAMETER_INVALID_AVP_VALUE ) )

Note: The relevant unit is typically the unit previously specified inthe granted service unit.

Service-Parameter-Info Ignored unless mapped to an IDP extension by the AVPmappings in eserv.config.

CC-Correlation-Id Ignored unless mapped to an IDP extension by the AVPmappings in eserv.config.

User-Equipment-Info Ignored unless mapped to an IDP extension by the AVPmappings in eserv.config.

Proxy-Info Returned unmodified in CCA.

Route-Record Ignored at present.

This table describes how each AVP content is set.AVP Data source

AVP Name Set From

Session-Id The Session-Id AVP of the first message in this transaction.

Result-Code Set to DIAMETER_SUCCESS unless otherwise stated.

Note: If quiescing and this is an INITIAL_REQUEST or an

EVENT_REQUEST then return CCA(Result-Code=DIAMETER_TOO_BUSY)

Origin-Host Set according to configuration. Normally defaults to host name.

Origin-Realm Set according to configuration. Normally defaults to host name.

Auth-Application-Id Always set to 4 (Diameter Credit-Control)

CC-Request-Type The value of CC-Request-Type from the correspondingrequest.

CC-Request-Number The value of CC-Request-Number from the correspondingrequest.

User-Name Not set



8/12/2019 PICS - DCA (1.0.3-04.00)

24/59




AVP Data source (continued)

AVP Name Set From

CC-Session-Failover Not set (which should be treated as FAILOVER-NOT-SUPPORTED according to RFC 4006)

CC-Sub-Session-Id Set to the value from the corresponding request message.

Acct-Multi-Session-Id Set to the value from the corresponding request message, ofpresent.

Origin-State-Id Set to current system time, at time of last DCA restart.

Event-Timestamp Set to the value of the Event-Timestamp AVP from thecorresponding request.

Granted-Service-Unit For session based services, this is ApplyCharging.maxDuration(divided by 10 if the unit type is Time).

For Requested-Action type DIRECT_DEBIT, in the success

case, this is the same as the Requested-Service-Unit AVP inthe corresponding request. Otherwise, not present.

Multiple-Services-Credit-Control

If Multiple Services Emulation is enabled in DCA, DCA willpopulate the MSCC AVP's in CCA messages with the followingsub-AVP's where applicable:

Granted-Units

Rating-Group or Service-Identifier (set by DCAconfiguration)

Result-Code

Time-Quota-Threshold (if applicable)

Volume-Quota-Threshold (if applicable)

Validity-Time (if applicable)

Final-Unit-Indication (if applicable)

Cost-Information For Request-Action type PRICE_ENQUIRY, success case, thiscomes from the value of extension 603 in the INAP Connect.Otherwise, not set.

Final-Unit-Indication Final-Unit-Action is set to REDIRECT or TERMINATEdepending on the INAP operations received (fromACS/). Redirect-Server is set to the numbermatched in the redirectNumbers config list or TEL:@.

Check-Balance-Result This is derived from the type of INAP operation received:

Continue ENOUGH_CREDIT

ReleaseCall (Reason = 31) NO_CREDITCredit-Control-Failure-Handling

Set to TERMINATE

Direct-Debiting-Failure-Handling

Not set. (According to RFC 4006, it will default toTERMINATE_OR_BUFFER).

Validity-Time Set to the configured validity-time for the service in the gracefultermination scenarios only.

Redirect-Host Not set.

Redirect-Host-Usage Not set.

Redirect-Max-Cache-Time Not set.


8/12/2019 PICS - DCA (1.0.3-04.00)

25/59




AVP Data source (continued)

AVP Name Set From

Proxy-Info Returned as per CCR.Route-Record Not set.

Failed-AVP Set in some cases when Result-Code != success i.e.:

If the incoming message contains unsupported AVPs thenreturn CCA(Result-Code=DIAMETER_AVP_UNSUPPORTED,Failed-AVPs)

8/12/2019 PICS - DCA (1.0.3-04.00)

26/59


INAP Extension Mappings

As INAP is not designed to contain Diameter AVPs, these will be carried, wherenecessary, in INAP extensions in the InitialDP or the Connect. The following pre-defined INAP extension types will be used, where appropriate.

Intoduction

It is impossible to predict in advance which AVPs will be relevant for rating orwhich vendor specific AVPs will be used. So, for each service, a mapping of AVPsto IDP extensions is allowed in the configuration.

The IDP extensions are used to modify the /ACS call context.Also the control plans may access these functions by means of suitable acs.confconfiguration and by use the ExtensionDigits[0-9] call context fields.

In addition it is possible to identify inbound AVPs, within inbound INITIAL orEVENT based Credit-Control-Request messages, for mapping into the IDP passedto ACS. The AVP to pass is identified according to AVP code. Multiple AVPs maybe identified and passed to target profile tags, available within the inboundextensions block.

501 = Requested-Service-UnitsExtensions in theIDP

502 = Requested service unit type

1 = CC-Time

2 = CC-Money

3 = CC-Total-Octets

4 = CC-Input-Octets

5 = CC-Output-Octets

6 = CC-Service-Specific-Units

503 = Requested-action

DIRECT_DEBITING 0

REFUND_ACCOUNT 1

CHECK_BALANCE 2

PRICE_ENQUIRY 3

504 = Event-Timestamp (passed as seconds since the Unix Epoch)

505 = Subscription-Id (E.164 based number representing subscriber)

701 = Multiple Encoded AVPs, mapped to Inbound Extension profile block (as perconfiguration)

601 = Granted service unitsExtensions in theConnectoperation 602 = Granted service unit type

1 = CC-Time

2 = CC-Money

3 = CC-Total-Octets

4 = CC-Input-Octets

5 = CC-Output-Octets

6 = CC-Service-Specific-Units

603 = Cost information (in system currency)


8/12/2019 PICS - DCA (1.0.3-04.00)

27/59


Example Control Plans

Six example control plans are shipped with the DCA packages. These aresufficient to run simple Diameter services.

Introduction

There are two control plans for session based services:

no redirect to top-up-server functionality, and

redirect to top-up-server functionality

There are four control plans for event based services

DIRECT_DEBITING

REFUND_ACCOUNT

CHECK_BALANCE, and

PRICE_ENQUIRY

This consists of a Start node connected to a UATB node.No redirect totop-up server

functionalityThe exits of the UAB node will be connected to an End node (Success cases) andto Disconnect nodes with various release causes.

The release causes in the Disconnect nodes will cause diameterControlAgent touse the appropriate Result-Code.

This will be the same as the no redirect to top-up server functionality control planwith the following differences.

Redirect to top-upserverfunctionality

The NSF (Disconnected) branch of the UATB node will be connected to anunconditional termination node which will contain a number mapped to theaddress of the top-up-server.

The following must be set in the ChargingMax and acsCharging sections ofthe eserv.config file if this is to be used:

ChargingMax = {oracleUserAndPassword="xxxx/xxxx"

ChargingMaxMacroNodes = {

UseDisconnectLeg = true

}

}

acsCharging = {

switchConfiguration = [

{

switchType = "cap3"

addDisconnectOrRelease = true

}

]

}

This control plan determines if this is a time or volume based direct debit (viaextension 502) with an Event-Timestamp AVP (extension 504) in which case aDUCR node is used to debit the account.

DIRECT_DEBITING

Otherwise, a Billable Event node with "Direct Event" ticked is used.

The billable event node will read its number of events from extension 501 i.e. theRequested-Service-Units.

Failure branches will be connected to Disconnect nodes with appropriate causevalues to produce the correct Diameter Result-Code values.



8/12/2019 PICS - DCA (1.0.3-04.00)

28/59


Example Control Plans, Continued

This control plan determines if this is a time or volume based account refund (viaextension 502) with an Event-Timestamp AVP (extension 504) in which case aDUCR node is used to credit the account.

REFUND_ACCOUNT

Otherwise, a Billable Event node with "Direct Event" ticked is used, (the cost of theselected event will be negative).

The billable event node will read its number of events from extension 501 i.e. theRequested-Service-Units.

Failure branches are connected to Disconnect nodes with appropriate causevalues to produce the correct Diameter Result-Code values.

This control plan uses two Billable Event nodes in conjunction with other ACSnodes to determine if there are sufficient funds available to complete therequested event.

CHECK_BALANCE

The first billable event node reserves an event type appropriate for this service.

If it fails to reserve the event, it will go to a Disconnect node (reason = theconfigured no funds cause).

If it succeeds then the second billable event node will be used to cancel thereservation.

A terminate unchanged node is used to send an INAP Continue which signals toDCA that there are sufficient funds.

This control plan uses a billable event node connected to Disconnect nodes (forfailures) and an unconditional terminate node (dummy number) for the successcase.

PRICE_ENQUIRY

The Billable Event node has "Cost of event" ticked.

The result is placed in extension 603 in the Connect, for use in the Cost-Information AVP.


8/12/2019 PICS - DCA (1.0.3-04.00)

29/59


Abort Session Request (ASR)

DCA can be configured to send an Abort-Session-Request (ASR) to the diameterclient when the Session Supervision Timer (Tcc timer) expires while waiting for thediameter client to send a request to DCA. If a timeout occurs while waiting for a

server process (e.g. ACS, UBE) an ASR will not be sent. In this scenario, we areprocessing a CCR, so we manage the error condition in the CCA response.

Abort SessionRequest

DCA supports Multiple Services Credit Control, which means that the diameterclient can request charging for many services in a single session, which results inDCA managing many charging sessions with ACS per single session with theclient.

The ASR message (defined in RFC 3588) does not support the notion of servicesin MSCC (defined in RFC 4006), so when the Tcc timer expires for any service fora given GGSN session, all ACS charging sessions associated with the GGSNsession must be terminated.

Note: Diameter provides the client with the capacity to decline aborting a session,by returning DIAMETER_UNABLE_TO_COMPLY, however DCA does not attempt

to keep a session open in this case: it acts the same in all cases, simply loggingthe response.The possible fields are as follows:

Field AVPCode

Data Type Comment

Session-Id 263 UTF8String The Session-Id AVP of the first messagein this transaction.

Origin-Host 264 DiameterIdentity Set according to configuration. Normallydefaults to host name.

Origin-Realm 296 DiameterIdentity Set according to configuration. Normallydefaults to host name.

Destination-Host 293 DiameterIdentity The Origin-Host of the first message inthis transaction.

Destination-Realm 283 DiameterIdentity The Origin-Realm of the first message inthis transaction.

Auth-Application-Id 258 Unsigned32 Always set to 1 (NASREQ)


8/12/2019 PICS - DCA (1.0.3-04.00)

30/59


Scenarios

This topic explains how the flow through the software achieves Diameter serverservices and also gives more details on the mapping between INAPoperations/parameters and Diameter messages/AVPs.

Introduction

The following scenarios are based on (and named after) the relevant appendixesin RFC 4006.

For each scenario, a message sequence chart is given.

Here is an example successful session-based charging, client terminates session.Successfulsession-basedcharging, clientterminatessession CCR (INITIAL_REQUEST,

Requested-Service-Unit not present

or CC-Time present

SubscriptionId = 12345678

DCAClient Slee_acs

InitialDp(

CallingPartyId = 12345678BearerCapability.ITC = 0 = speech)

RRBCSME (busy, no answer, RSF,

abandon, disconnect leg 1 (notify),disconnect leg 2 (interrupted)

ApplyCharging (maxDuration = 5990)

Continue

CCA (Granted-Service-Unit.CC-Time = 599)

CCR (UPDATE_REQUEST,Used-Service-Unit.CC-Time = 589)

start Tcc

ApplyChargingReport (

timeNoTariffSwitch = 5890callActive = true)



restart Tcc

CCR (TERMINATION_REQUEST,

Used-Service-Unit.CC-Time = 311)

ERBCSM (oDisconnect,leg1)

ApplyChargingReport (timeNoTarrifSwitch = 900callActive = false)

CCA

Stop Tcc



8/12/2019 PICS - DCA (1.0.3-04.00)

31/59


Scenarios, Continued

Here is an example multimedia messaging direct debit scenario.Multimediamessaging directdebit scenario

CCR (Event_REQUEST,

Requested-Action=DIRECT_DEBITINGRequested-Service-Unit.CC-Service-Specific-Units = 5,

Event-Timestamp=15:30:05"

SubscriptionId = 12345678)

DCAClient Slee_acs

InitialDp(

CallingPartyId = 12345678

BearerCapability.ITC = 17 = unrestricted digital with tones)Extension 501 = 5

Extension 502 = 6

Extension 503 = 0Extension 504 = 15:30:05

Continue

CCA (Granted-Service-Unit.CC-Service-Specific-Units = 5)

Here is an example check balance, with a result of enough credit.Check balance,with a result ofenough credit

CCR (Event_REQUEST,Requested-Action=CHECK_BALANCE

SubscriptionId = 12345678)

DCAClient Slee_acs

InitialDp(

CallingPartyId = 12345678BearerCapability.ITC = 17 = unrestricted digital with tones)

Continue

CCA (Check-Balance-Result = ENOUGH_CREDIT)

Here is an example price enquiry.Price enquiry

CCR (Event_REQUEST,

Requested-Action=PRICE_ENQUIRYSubscriptionId = 12345678)

DCAClient Slee_acs

InitialDp(

CallingPartyId = 12345678BearerCapability.ITC = 17 = unrestricted digital with tones)

Connect (destRoutingAddr = 0000Extension 603 = 123456)

CCA (Cost-Information =

(Unit-Value=(Value-Digits=123456,Exponent=-2),Currency-Code = 978))



8/12/2019 PICS - DCA (1.0.3-04.00)

32/59



Here is an example funds expiry, redirect, top-up and reconnect.Funds expiry,redirect, top-upand reconnect

CCR (INITIAL_REQUEST,Requested-Service-Unit not present

or CC-Time presentSubscriptionId = 12345678

DCAClient Slee_acs

InitialDp(

CallingPartyId = 12345678

BearerCapability.ITC = 0 = speech)

RRBCSME (busy, no answer, RSF,

abandon, disconnect leg 1 (notify),

disconnect leg 2 (interrupted)


Continue


CCR (UPDATE_REQUEST,


start Tcc

ApplyChargingReport (

timeNoTariffSwitch = 5900callActive = true)



restart Tcc

CCR (TERMINATION_REQUEST,


ApplyChargingReport (timeNoTarrifSwitch = 11900

callActive = true)

DisconnectLeg

Connect (22221111)

CCA (Granted-Service-Unit.CC-Time = 10,

Final-Unit-Indication = (Final-Unit-Action = REDIRECT, Redirect-Server = a.b.c.com))

restart Tcc

CCR (UPDATE_REQUEST,


CCA (Validity-Time=300)

restart Tcc



8/12/2019 PICS - DCA (1.0.3-04.00)

33/59



Funds expiry, redirect, top-up and reconnect (continued)

CCR (UPDATE_REQUEST)

InitialDp(

CallingPartyId = 12345678BearerCapability.ITC = 0 = speech)

RRBCSME (busy, no answer, RSF,abandon, disconnect leg 1 (notify),

disconnect leg 2 (interrupted)


Continue


restart Tcc

DCAClient Slee_acs

Here is an example multiple services credit control scenario.Multiple servicescredit controlscenario

CCR (INITIAL_REQUEST)

Multiple-Service-Credit-Control->Rating-Group=111


UAS

(DCA)GGSN UBE

CCA (INITIAL_REQUEST)

CCR (UPDATE_REQUEST)

Multiple-Service-Credit-Control->Rating-Group=nnn

CCA (UPDATE_REQUEST)

CCR (TERMINATION_REQUEST)



Multiple-Service-Credit-Control->Rating-Group=nnn

Close charging event or session (Service=nnn)

CCA (TERMINATE_REQUEST)

Open new charging event or session (Service=nnn)

Close charging event or session (Service=222)

Close charging event or session (Service=111)

Open new charging event or session (Service=222)

Open new charging event or session (Service=111)



8/12/2019 PICS - DCA (1.0.3-04.00)

34/59



Here is an example of an abort session request scenario.Abort SessionRequest Scenario

CCR

CCA

Start Tcc timer

DCAClient

Abort-Session-Answer

Abort-Session-Request Tcc timer timeout


8/12/2019 PICS - DCA (1.0.3-04.00)

35/59


Chapter 5

Compliance Tables

Overview

This chapter identifies the level of compliance to RFC 3588 and RFC 4006.Introduction


Compliance to RFC 3588 ..............................................................................30Compliance to RFC 4006 ..............................................................................363GPP TS 32.299 V6.3.0................................................................................43

In this chapter


8/12/2019 PICS - DCA (1.0.3-04.00)

36/59


Compliance to RFC 3588

This table lists the compliances for section 1.Introduction -Section 1

Section Section Heading Compliance Level Comment

1 Introduction N/A

This table lists the compliances for section 2.ProtocolOverview -Section 2


2 Protocol Overview N/A

2.1 Transport Fully Compliant TCP+ SCTP supported

TCP is selected by default

2.2 Security Partially CompliantIPSec via g/wfunction

2.3 Application Compliance Fully Compliant

2.4 Application Identification Fully Compliant

2.5 ConnectionManagement

Partially Compliant Credit-Control clients (or next hoppeers) must establish connection toDCA. DCA does not establishoutbound connections. Inboundconnections are established andadded to pool for use by Diametersessions. Number of connections perrealm is configurable.

2.6 Peers N/A A static list of permissible peers isconfigurable.

2.7 Realm Based Routing Compliant Responses will be returned to thesame realm via the Peer from whichthe request was received.

2.8 Role of agents N/A

2.9 End-to-end security Partial Compliance Only Never use end-to-end securityis supported

2.10 Path Authentication N/A

This table lists the compliances for section 3.Headers - Section3


3 Headers N/A

3.1 Command Codes Partially Compliant CER, CEA, DWR, DWA, DPR, DPA,ASR, ASA supported.

3.2 ABNF Specification Fully Compliant

3.3 Naming Conventions Fully Compliant



8/12/2019 PICS - DCA (1.0.3-04.00)

37/59


Compliance to RFC 3588, Continued

This table lists the compliances for section 4.Diameter AVPs -Section 4


4 Diameter AVPs N/A

4.1 AVP Header Fully Compliant

4.2 Basic AVP DataFormats

Fully Compliant

4.3 Derived AVP DataFormats

Fully Compliant No specific AVPs are defined bydefault.

4.4 Grouped AVP Values Fully Compliant

4.5 Diameter BaseProtocol AVPs

Fully Compliant Support for all AVPs needed forcompliance to section 3.1

This table lists the compliances for section 5.Diameter AVPs -Section 4


5 Diameter Peers N/A

5.1 Peer Connections Fully Compliant

5.2 Peer discovery Non Compliant

5.3 Capability Exchange Fully Compliant

5.4 Disconnecting PeerConnections

Fully Compliant

5.5 Transport Failure Fully Compliant

5.6 Peer State Machine Partially Compliant

This table lists the compliances for section 6.DiameterMessageProcessing -Section 6


6 Diameter MessageProcessing

6.1 Request Routing Fully Compliant Please note that proxy and forward arenot supported

6.2 Diameter Answer

Processing

Fully Compliant

6.3 Origin-Host AVP Fully Compliant

6.4 Origin- Realm AVP Fully Compliant

6.5 Destination-Host AVP Fully Compliant

6.6 Destination- RealmAVP

Fully Compliant

6.7 Routing AVPs Fully Compliant

6.8 Auth-Application-IdAVP

Fully Compliant Will be 4 for Credit-Control



8/12/2019 PICS - DCA (1.0.3-04.00)

38/59



Diameter Message Processing - Section 6 (continued)


6.9 Acct-Application-IdAVP Fully Compliant Not used for Credit-Control

6.10 Inband-Security IDAVP

Fully Compliant

6.11 Vendor SpecificApplication-Id AVP

Fully Compliant No variable specific AVPs are definedtoday.

See Section 9 for additional details.

6.12 Redirect-Host AVP Non Compliant No explicit routing supported.

6.13 Redirect-Host-UsageAVP

Non Compliant

6.14 Redirect-Max-Cache-

Time AVP

Non Compliant

6.15 E2E-Sequence AVP Fully Compliant This AVP may be turned off to supportpeers which do not support this AVP

This table lists the compliances for section 7.Error Handling -Section 7


7 Error Handling

7.1 Result-Code AVP Fully Compliant

7.2 Error Bit Fully Compliant

7.3 Error-Message ACP Fully Compliant

7.4 Error-Reporting-HostAVP

Fully Compliant

7.5 Failed-AVP AVP Fully Compliant

7.6 Experimental ResultACP

Fully Compliant

7.7 Experimental ResultCode AVP

Fully Compliant

This table lists the compliances for section 8.Diameter UserSessions -Section 8


8 Diameter UserSessions

8.1 Authorization SessionState Machine

Non Complaint

8.2 Accounting SessionState Machine

Partially Compliant Implements only the server side of thestate machine

8.3 Server-Initiated Re-Auth

Non Complaint



8/12/2019 PICS - DCA (1.0.3-04.00)

39/59



Diameter User Sessions - Section 8 (continued)


8.4 Session Termination Not Applicable Not used by DCA for server-side Credit-Control

8.5 Abort Session Fully Compliant

8.6 Inferring SessionTermination fromOrigin-State-Id

Non Compliant

8.7 Auth-Request-TypeAVP

Non Compliant

8.8 Session-Id AVP Fully Compliant

8.9 Authorization-LifetimeAVP

Non Compliant

8.10 Auth-Grace-PeriodAVP Non Compliant

8.11 Auth-Session-StateAVP

Non Compliant

8.12 Re-Auth-RequestAVP

Non Compliant

8.13 Session Timeout AVP Fully Compliant

8.14 User Name AVP Fully Compliant

8.15 Termination Cause Fully Compliant

8.16 Origin State ID AVP Fully Compliant `

8.17 Session Binding AVP Non Compliant

8.18 Session-Server-Failover AVP

Non Compliant

8.19 Multi-Round-Time-Out AVP

Non Compliant

8.20 Class AVP Non Compliant

8.21 Event TimestampAVP

Fully Compliant

This table lists the compliances for section 9.Accounting -Section 9


9 Accounting

9.1 Server DirectedModel

Fully Compliant

9.2 Protocol Messages Partially Compliant No IP compression is supported at thistime. Support for negotiation is howeverprovided.

9.3 Application documentrequirements

Fully Compliant See Credit Control Application defined inRFC 4006

9.4 Fault Resilience Fully Compliant Please note that only the server side isimplemented.



8/12/2019 PICS - DCA (1.0.3-04.00)

40/59



Accounting - Section 9 (continued)


9.5 Accounting Records Fully Compliant Not applicable for Credit-Control9.6 Correlation of

Accounting RecordsFully Compliant Not applicable for Credit-Control

9.7 AccountingCommand-Codes

Fully Compliant Not applicable for Credit-Control

9.8 Accounting AVPs Fully Compliant Not applicable for Credit-Control

This table lists the compliances for section 10.AVP OccurrenceTable - Section 10


10 AVP Occurrence

Table

Partial Compliant As detailed elsewhere in this document

and as needed for CER, CEA, DWR,DWA, DPR, DPA

This table lists the compliances for section 11.IANAConsiderations -Section 11


11 IANA Considerations

11.1 AVP Header Fully Compliant

11.2 AVP Codes Fully Compliant

11.3 Application Identifiers Fully Compliant

11.4 AVP Values Fully Compliant As detailed elsewhere in this documentand as needed for CER, CEA, DWR,DWA, DPR, DPA.

Please note that unused AVPs areignored by the client implementation.

11.5 Diameter TCP/SCTPPort Numbers

Fully Compliant

11.6 NAPR Service Fields Fully Compliant This information is updated when theclient package is installed

This table lists the compliances for section 12.Diameter ProtocolRelatedConfigurableParameters -Section 12


12 Diameter ProtocolRelated ConfigurableParameters

Partial Compliant Statically configured peers aresupported.



8/12/2019 PICS - DCA (1.0.3-04.00)

41/59



This table lists the compliances for section 13.SecurityConsiderations -Section 13


13 SecurityConsiderations

Partially Compliant Note: Use of network provided IPSecmay be used in deployments. TLS is notsupported. End-to-End security is notsupported.


8/12/2019 PICS - DCA (1.0.3-04.00)

42/59


Compliance to RFC 4006

This table lists the compliances for sections 4.2 and 4.3 of the "ProgrammersGuide - Service Charging Based on Diameter Charging Control Node 5.

Introduction -Section 1


4.2.1 Messages Fully Compliant

4.2.2 Diameter Base ProtocolAVPs

Partially Compliant Refer to Draft 8 Compliance above.

4.2.3 Defined ApplicationSpecific AVPs

Fully Compliant Values are either supported usingDCD in SCAP mode, or may be setaccording to configuration

4.2.4 Description ofApplication SepcificAVPs

Fully Compliant Values are either supported usingDCD in SCAP mode, or may be setaccording to configuration.

4.3.1 Service Charging Types Fully Compliant

4.3.2 Service Charging

Methods

Fully Compliant

4.3.3 List of ServiceOperations withScenarios

Fully Compliant

This table lists the compliances for section 2.ArchitectureModel - Section 2


2 Architecture Model Partial Compliant Authentication and Authorizationmessages are not used

This table lists the compliances for section 3.Credit-ControlMessages -Section 3


3 Credit-Control Messages Fully Compliant

This table lists the compliances for section 4.Credit-ControlApplicationOverview -Section 4


4 Credit-ControlApplication Overview

4.1 Service-Specific RatingInput and Interoperability

Fully Compliant Details of specific AVPimplementation is given later in thisdocument



8/12/2019 PICS - DCA (1.0.3-04.00)

43/59



This table lists the compliances for section 5.Session BasedCredit-Control -Section 5


5 Session Based Credit-Control

5.1.1 Basic Tariff-TimeChange Support

Non Compliant

5.1.2 Credit Control forMultiple Services withina Sub Session

Partially Compliant Tariff-Change-Usage and G-S-UPool-Reference are not supported.

See also notes on Service-IdentifierAVP.

5.2 First Interrogation Fully Compliant

5.3 Intermediate

Interrogation

Fully Compliant

5.4 Final Interrogation Fully Compliant

5.5 Server-Initiated CreditRe-Authorization

Non Compliant

5.6 Graceful ServiceTermination

Partially Compliant Graceful service termination with"Redirect Action" is supported.

5.7 Failure Procedures Fully Compliant Managed via BFT in control plans.

This table lists the compliances for section 6.One Time Event -Section 6


6 One Time Event

6.1 Service Price Enquiry Fully Compliant

6.2 Balance Check Fully Compliant

6.3 Direct Debit Fully Compliant

6.4 Refund Fully Compliant

6.5 Failure Procedure Fully Compliant

This table lists the compliances for section 7.Credit-ControlState Machine -Section 7


7 Credit-Control StateMachine

Fully Compliant Server side only is implemented



8/12/2019 PICS - DCA (1.0.3-04.00)

44/59



This table lists the compliances for section 8.Credit-ControlAVPs - Section 8


8 Credit-Control AVPs

8.1 CC-Correlation-ID AVP Fully Compliant Ignored unless mapped to an IDPextension by the AVP mappings ineserv.config.

8.2 CC-Request-NumberAVP

Fully Compliant Implemented as per suggestion inRFC 4006

8.3 CC-Request-Type AVP Fully Compliant

8.4 CC-Session-FailoverAVP

Fully Compliant Not set, which according to RFC isequivalent to AVP set to FAILOVER-NOT-SUPPORTED

8.5 CC-Sub-Session-Id AVP Non Compliant

8.6 Check-Balance-ResultAVP

Fully Compliant

8.7 Cost-Information AVP Fully Compliant For Request-Action typePRICE_ENQUIRY, success case, thiscomes from the value of extension603 in the INAP Connect. Otherwise,not set.

8.8 Unit Value Fully Compliant

8.9 Exponent AVP Fully Compliant

8.10 Value Digits AVP Fully Compliant

8.11 Currency-Code AVP Fully Compliant

8.12 Cost-Unit AVP Fully Compliant

8.13 Credit-Control AVP Fully Compliant

8.14 Credit-Control-Failure-Handling AVP

Fully Compliant

8.15 Direct-Debit-Failure-Handling

Fully Compliant

8.16 Multiple-Services-Credit-Control AVP

Partially Compliant Tariff-Change-Usage and G-S-UPool-Reference are not supported.

8.17 Granted-Service-UnitAVP

Fully Compliant Multiple unit types are not supported,for a single service. In the case ofMultiple Services Credit Control, a

single unit type is permitted perMultiple-Services-Credit-Control AVP.

8.18 Requested-Service-UnitAVP

Fully Compliant Multiple unit types are not supported,for a single service. In the case ofMultiple Services Credit Control, asingle unit type is permitted perMultiple-Services-Credit-Control AVP.



8/12/2019 PICS - DCA (1.0.3-04.00)

45/59




Credit-Control AVPs - Section 8 (continued)


8.19 Used-Service-Unit ACP Fully Compliant Multiple unit types are not supported,for a single service. In the case ofMultiple Services Credit Control, asingle unit type is permitted perMultiple-Services-Credit-Control AVP.

8.20 Tariff-Time-Change AVP Non Compliant

8.21 CC-Time AVP Fully Compliant

8.22 CC-Money AVP Fully Compliant

8.23 CC-Total-Octets AVP Fully Compliant

8.24 CC-Input-Octets ACP Fully Compliant

8.25 CC-Output-Octets ACP Fully Compliant

8.26 CC-Service-Specific-Units AVP

Fully Compliant

8.27 Tariff-Change-UsageAVP

Non Compliant

8.28 Service-Identifier AVP Fully Compliant For multiple services, normally only asingle service-identifier is expected,per Multiple-Services-Credit-ControlAVP.

Where both Service-Identifier andRating-Group have been specified,the Service-Identifier will takeprecedence.

If multiple Service-Identifier AVPs areprovided per Multiple-Services-Credit-Control AVP, then DCA may beconfigured to either:

Only charge for the first Service-Identifier encountered.This is based on the followingstatement in RFC 4006: "Notethat each instance of this AVPcarries units related to one ormore services or related to asingle rating group."

Or create a separate chargingsub-session, for each sessionidentifier supplied. In this caseeach charging sub-session will bereported back in a separateMultiple-Services-Credit-ControlAVP.

8.29 Rating-Group AVP Non Compliant

8.30 G-S-U Pool ReferenceAVP

Non Compliant


8/12/2019 PICS - DCA (1.0.3-04.00)

46/59




Credit-Control AVPs - Section 8 (continued)


8.31 G-S-U Pool IdentifierAVP Non Compliant

8.32 CC-Unit-Type AVP Fully Compliant

8.33 Validity-Time AVP Fully Compliant

8.34 Final-Unit-IndicationAVP

Fully Compliant

8.35 Final-Unit-Action AVP Fully Compliant

8.36 Restriction-Filter-RuleAVP

Non Compliant These rules are defined using theOracle Control Plan Editor.

8.37 Redirect-Server AVP Fully Compliant Please note that SIP E.164 addressesmust be used for voice and SMS

sessions8.38 Redirect-Address-Type

AVPFully Compliant

8.39 Redirect-Server-AddressAVP

Fully Compliant

8.40 Multiple-Services-Indicator AVP

Fully Compliant

8.41 Requested-Action AVP Fully Compliant

8.42 Service-Context-Id AVP Fully Compliant

8.43 Service-Parameter-InfoAVP

Fully Compliant May be mapped in configuration toindicate supplementary ratinginformation.

8.44 Service-Parameter-TypeAVP


8.45 Service-Parameter-Value AVP


8.46 Subscription-Id AVP Fully Compliant

8.47 Subscription-Id-TypeAVP

Fully Compliant E164 and SIP URI are used today

8.48 Subscription-Id-DataAVP

Fully Compliant

8.49 User-Equipment-InfoAVP

Non Compliant

8.50 User-Equipment-Info-Type AVP

Non Compliant Ignored unless mapped to an IDPextension by the AVP mappings ineserv.config.

8.51 User-Equipment-Info-Data AVP

Non Compliant


8/12/2019 PICS - DCA (1.0.3-04.00)

47/59



This table lists the compliances for section 9.Result Code AVPValues - Section 9


9 Result Code AVPValues

9.1 Transient Failures Fully Compliant

9.2 Permanent Failures Fully Compliant

This table lists the compliances for section 10.AVP OccurrenceTable - Section 10


10 AVP Occurrence Table

10.1 Credit-Control AVP

Table

Fully Compliant

10.2 Re-Auth-Request/Answer TableAVP

Fully Compliant

This table lists the compliances for section 11.RADIUS/DiameterCredit-ControlInterworkingModel - Section11


11 RADIUS/Diameter

Credit-ControlInterworking Model

Fully Compliant

This table lists the compliances for section 12.IANAConsiderations -Section 12


12 IANA Considerations Fully Compliant

This table lists the compliances for section 13.Credit-ControlApplicationRelatedParameters -Section 13


13 Credit-ControlApplication RelatedParameters

Fully Compliant Tcc session supervision timer issupported timers are supported



8/12/2019 PICS - DCA (1.0.3-04.00)

48/59



This table lists the compliances for section 14.SecurityConsiderations -Section 14


14 Security Considerations Partially Compliant Use of network provided IPSec maybe used in deployments.

14.1 Direct Connection withRedirect

Non Compliant Statically configured peers aresupported.


8/12/2019 PICS - DCA (1.0.3-04.00)

49/59


3GPP TS 32.299 V6.3.0

If Multiple Services Support Emulation is enabled in DCA, DCA will include thefollowing additional AVP's in CCA messages within the Multiple-Services-Credit-Control AVP:

3GPP TS 32.299V6.3.0

Time-Quota-Threshold AVP (AVP code 868) 3GPP TS 32.299 V6.3.0(Section 7.2.2.5).

Volume-Quota-Threshold AVP (AVP code 869) 3GPP TS 32.299 V6.3.0(Section 7.2.2.6).

Both of the above AVP's, will be sent with:

Vendor-ID 10415 (3GPP) Ref http://www.iana.org/assignments/enterprise-numbers

Quota-Threshold value 0


8/12/2019 PICS - DCA (1.0.3-04.00)

50/59

8/12/2019 PICS - DCA (1.0.3-04.00)

51/59



Appendix

Overview

This appendix contains the following topics.In this appendix

Glossary of Terms ......................................................................................... 47Index .............................................................................................................. 51


8/12/2019 PICS - DCA (1.0.3-04.00)

52/59

8/12/2019 PICS - DCA (1.0.3-04.00)

53/59


Glossary of Terms

Authentication, Authorisation, and Accounting. Specified in Diameter RFC 3588.AAA

Advanced Control Services configuration platform.ACS

Application Programming InterfaceAPI

Session message: Abort Session AnswerASA

Session message: Abort Session RequestASR

Attribute Value Pair, used in Diameter to represent properties of a particularrequest or answer.

AVP

Billing Failure Treatment - the process that is applied if the system has lost allconnections to a billing engine. It allows for limited continuation of call processing

functions, if configured.

BFT

Country Code. Prefix identifying the country for a numeric international address.CC

Credit-Control-Answer, used in Diameter by the credit-control server toacknowledge a Credit-Control-Request (CCR) from the credit-control client.

CCA

Credit-Control-Request, used in Diameter by the credit-control client to requestcredit authorization from the credit-control server.

CCR

Peer message: Capabilities Exchange AnswerCEA

Peer message: Capabilities Exchange RequestCER

Transport level ink between two peers, providing for multiple sessions.Connection

Common Object Request Broker Architecture. It is a framework that providesinteroperability between objects built in different programming languages, runningon different physical machines perhaps on different networks. It specifies anInterface Definition Language, and API that allows client / server interaction withthe ORB.

CORBA

A feature rich AAA protocol. Utilises SCTP and TCP transports.Diameter

Detection PointDP

Peer message: Disconnect Peer AnswerDPA

Peer message: Disconnect Peer RequestDPR

Peer message: Device Watchdog AnswerDWA

Peer message: Device Watchdog RequestDWR

Fast OSA eXtensions. A TCP/IP billing protocol intended for use with externalvendors. Based on OSA, it fills in functional gaps missing in OSA, and definescombined OSA operations to increase platform throughput. Uses a non-CORBAtransport layer in order to provide enhanced fail-over and connection redundancy.

FOX


8/12/2019 PICS - DCA (1.0.3-04.00)

54/59


HyperText Markup Language, a small application of SGML used on the WorldWide Web.

HTML

It defines a very simple class of report-style documents, with section headings,paragraphs, lists, tables, and illustrations, with a few informational andpresentational items, and some hypertext and multimedia.

INAP message: Initial DP (Initial Detection Point)IDP

Intelligent NetworkIN

Intelligent Network Application Part - a protocol offering real time communicationbetween IN elements.

INAP

Initial Detection Point - INAP Operation. This is the operation that is sent when theswitch reaches a trigger detection point.

Initial DP

1) Internet ProtocolIP

2) Intelligent Peripheral - a box that is able to play announcements

IP Security. Security protocol implemented at the IP layer.IPSec

Network Access Services. Control point for authorising (and restricting) access toa network. Normally located on the network fringe.

NAS

Oracle CorporationOracle

Object Request Broker. Within an Object based communication system, an ORBkeeps track of the actual addresses of all defined objects and thus is used to routetraffic to the correct destination. The CORBA defines the ORB in a series ofstandards enabling different platforms to share common information.

ORB

Open Service Access provides a standard interface through which developers candesign services that may interact with functions within the network.

OSA

Remote machine, which for our purposes is capable of acting as a Diameteragent.

Peer

Provisioning Interface - used for bulk database updates/configuration instead ofGUI based configuration.

PI

Remote Authentication Dial-In User Service - a system of distributed security thatsecures remote access to networks and network services against unauthorised

access.

RADIUS

Stream Control Transmission Protocol. A transport-layer protocol analogous to theTCP or User Datagram Protocol (UDP). SCTP provides some similar services asTCP (reliable, in-sequence transport of messages with congestion control) butadds high availability.

SCTP

Diameter exchange relating to a particular user or subscriber access to a providedservice (i.e. a phone call).

Session

Standard Generalized Markup Language. The international standard for definingdescriptions of the structure of different types of electronic document.

SGML


8/12/2019 PICS - DCA (1.0.3-04.00)

55/59



Session Initiation Protocol - a signalling protocol for Internet conferencing,telephony, event notification and instant messaging. (IETF)

SIP

Service Logic Execution EnvironmentSLEE

Short Message Service.SMS

Simple Network Management Protocol. Usually responsible for notifying faults on anetwork.

SNMP

Transmission Control Protocol. This is a reliable octet streaming protocol used bythe majority of applications on the Internet. It provides a connection-oriented, full-duplex, point to point service between hosts.

TCP

Transport Layer Security. Cryptographic protocol used to provide securecommunications. Evolved from SSL.

TLS

Universal Application Server - hardware on which applications run.UAS

Universal Billing Engine for Oracle Communications Network Control andCharginOracle Communications Network Control and Oracle CommunicationsNetwork Control and Charging.

UBE

Uniform Resource Identifier.URI

Universal Service Management System hardware platform.USMS


8/12/2019 PICS - DCA (1.0.3-04.00)

56/59

8/12/2019 PICS - DCA (1.0.3-04.00)

57/59


Index

33GPP TS 32.299 V6.3.0

3GPP TS 32.299 V6.3.0 43

AAbort Session Request

Abort Session Request (ASR) 23Abort Session Request (ASR)

Abort Session Request 23Abort Session Request Scenario

Scenarios 28About this Document

Audience vChanges in this document vRelated documents v

Scope vAccounting - Section 9

Compliance to RFC 3588 33ACS 18API 47Architecture Model - Section 2

Compliance to RFC 4006 36ASA 30ASR 23Attribute-Value Pairs (AVPs)

Diameter Message Encoding 4Audience

About this Document v

AVP 4AVP Data source

Credit Control Request AVPs 17AVP Data Types

Diameter Message Encoding 4AVP List descriptions

Credit Control Request AVPs 16AVP Occurrence Table - Section 10

Compliance to RFC 3588 34Compliance to RFC 4006 41

BBFT 37

CCapabilities Exchange Messages

Capabilities Exchange Messages 9CC 12CCA 13CCR 4CEA 8CER 4Changes in this document

About this Document vCheck balance, with a result of enough credit

Scenarios 25CHECK_BALANCE

Example Control Plans 22Compliance to RFC 3588

Accounting - Section 9 33AVP Occurrence Table - Section 10 34Diameter AVPs - Section 4 31Diameter Message Processing - Section 6

31Diameter Protocol Related Configurable

Parameters - Section 12 34Diameter User Sessions - Section 8 32Error Handling - Section 7 32Headers - Section 3 30IANA Considerations - Section 11 34Introduction - Section 1 30

Protocol Overview - Section 2 30Security Considerations - Section 13 35Compliance to RFC 4006

Architecture Model - Section 2 36AVP Occurrence Table - Section 10 41Credit-Control Application Overview -

Section 4 36Credit-Control Application Related

Parameters - Section 13 41Credit-Control AVPs - Section 8 38Credit-Control Messages - Section 3 36Credit-Control State Machine - Section 7

37

IANA Considerations - Section 12 41Introduction - Section 1 36One Time Event - Section 6 37RADIUS/Diameter Credit-Control

Interworking Model - Section 11 41Result Code AVP Values - Section 9 41Security Considerations - Section 14 42Session Based Credit-Control - Section 5

37Connection 30CORBA 47Credit Control Request AVPs

AVP Data source 17

AVP List descriptions 16Credit-Control Application Overview - Section

4Compliance to RFC 4006 36

Credit-Control Application Related Parameters- Section 13Compliance to RFC 4006 41

Credit-Control AVPs - Section 8Compliance to RFC 4006 38

Credit-Control Messages - Section 3Compliance to RFC 4006 36

Credit-Control State Machine - Section 7Compliance to RFC 4006 37


8/12/2019 PICS - DCA (1.0.3-04.00)

58/59


DDCA Coverage

DCA Overview 2DCA Overview

DCA Coverage 2

DCA Server 2General restrictions 2Introduction 2

DCA ServerDCA Overview 2

Device Watchdog MessagesDevice Watchdog Messages 11

Diameter iiDiameter AVPs - Section 4

Compliance to RFC 3588 31Diameter Headers

Diameter Message Encoding 4Diameter Message Encoding

Attribute-Value Pairs (AVPs) 4AVP Data Types 4Diameter Headers 4Introduction 4

Diameter Message Processing - Section 6Compliance to RFC 3588 31

Diameter Protocol Related ConfigurableParameters - Section 12Compliance to RFC 3588 34

Diameter User Sessions - Section 8Compliance to RFC 3588 32

DIRECT_DEBITINGExample Control Plans 21

Disconnect Peer MessagesDisconnect Peer Messages 10Document Conventions

Icons viTypographical conventions vi

DP 48DPA 8DPR 4Duplicate message 12DWA 8DWR 4

EEnd to end identifier 12Error Handling - Section 7

Compliance to RFC 3588 32Example Control Plans

CHECK_BALANCE 22DIRECT_DEBITING 21Introduction 21No redirect to top-up server functionality

21PRICE_ENQUIRY 22Redirect to top-up server functionality 21REFUND_ACCOUNT 22

Extension formats 5

Extensions in the Connect operationINAP Extension Mappings 20

Extensions in the IDPINAP Extension Mappings 20

FFOX 2Funds expiry, redirect, top-up and reconnect

Scenarios 26

GGeneral duplicate detection 12General restrictions

DCA Overview 2GUI 48

HHeaders - Section 3

Compliance to RFC 3588 30HTML vi

IIANA Considerations - Section 11

Compliance to RFC 3588 34IANA Considerations - Section 12

Compliance to RFC 4006 41Icons

Document Conventions viIDP 16IN viINAP 5

INAP Extension MappingsExtensions in the Connect operation 20Extensions in the IDP 20Intoduction 20

INAP extensions 5Initial DP 48Intoduction

INAP Extension Mappings 20Introduction

DCA Overview 2Diameter Message Encoding 4Example Control Plans 21Introduction 8

Scenarios 24Introduction - Section 1

Compliance to RFC 3588 30Compliance to RFC 4006 36

IP 9IPSec 30

MMessage Retransmission and Duplicate

DetectionRFC 3588 and Event Based Credit-Control

Duplicate Detection 12


8/12/2019 PICS - DCA (1.0.3-04.00)

59/59


Session Based Credit-Control DuplicateDetection 12

Multimedia messaging direct debit scenarioScenarios 25

Multiple services credit control scenarioScenarios 27

NNAS 2No redirect to top-up server functionality

Example Control Plans 21Non-volatile storage 12

OOne Time Event - Section 6

Compliance to RFC 4006 37Oracle iiORB 47OSA 2

PPeer 8Price enquiry

Scenarios 25PRICE_ENQUIRY

Example Control Plans 22Protocol Overview - Section 2

Compliance to RFC 3588 30

RRADIUS 41

RADIUS/Diameter Credit-Control InterworkingModel - Section 11Compliance to RFC 4006 41

Redirect to top-up server functionalityExample Control Plans 21

REFUND_ACCOUNTExample Control Plans 22

Related documentsAbout this Document v

Result Code AVP Values - Section 9Compliance to RFC 4006 41

RFC 3588 and Event Based Credit-ControlDuplicate Detection

Message Retransmission and DuplicateDetection 12

SScenarios

Abort Session Request Scenario 28Check balance, with a result of enough

credit 25Funds expiry redirect top up and

Multimedia messaging direct debit scenario 25

Multiple services credit control scenario 27

Price enquiry 25Successful session-based charging, client

terminates session 24Scope

About this Document vSCTP 8Security Considerations - Section 13

Compliance to RFC 3588 35Security Considerations - Section 14

Compliance to RFC 4006 42Session vSession Based Credit-Control - Section 5

Compliance to RFC 4006 37Session Based Credit-Control Duplicate

Detection

Message Retransmission and DuplicateDetection 12

SGML 48SIP 18SLEE 2SMS viSNMP 2Successful session-based charging, client

terminates sessionScenarios 24

TTCP 8

TLS 2Typographical conventions

Document Conventions vi

UUAS vUBE 23URI 40USMS 2

PICS - DCA (1.0.3-04.00)

Documents