OCS DCC Description

OCSR002C02LG0207

DCC Description

Issue 01

Date 2011-09-20

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior writtenconsent of Huawei Technologies Co., Ltd. Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respective holders. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,and recommendations in this document are provided "AS IS" without warranties, guarantees or representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 01 (2011-09-20) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

About This Document

Intended AudienceThis document is intended for:

l Development engineersl Debugging engineersl Maintenance engineers

Change HistoryUpdates between document issues are cumulative. Therefore, the latest document issue containsall updates made in previous issues.

Updates in Issue 01 (2011-09-20)Release for the first time.

OCSDCC Description About This Document


iii

Contents

About This Document...................................................................................................................iii

1 Protocol Overview......................................................................................................................1-11.1 Definition of the DCC Protocol......................................................................................................................1-21.2 Format of the DCC Protocol...........................................................................................................................1-3

1.2.1 Format of the Message Header...............................................................................................................1-31.2.2 Message List...........................................................................................................................................1-41.2.3 Format of the AVP Header.....................................................................................................................1-51.2.4 Format of the AVP Data.........................................................................................................................1-6

1.3 Terms...............................................................................................................................................................1-81.4 Specifications................................................................................................................................................1-11

2 Interface Overview.....................................................................................................................2-12.1 DCC Application in the OCS..........................................................................................................................2-22.2 Diameter Client and Diameter Server.............................................................................................................2-22.3 Logical Structure of the OCS Interface...........................................................................................................2-2

2.3.1 Interface Relation Between the DCC and the SCP................................................................................2-32.3.2 Interface Relation Between the DCC and the MDSP.............................................................................2-3

2.4 Process of Connection Establishment.............................................................................................................2-32.4.1 End-to-End Connection Diagram...........................................................................................................2-32.4.2 Routing Process: Routing a Request Message.......................................................................................2-42.4.3 Routing Process: Routing a Response Message.....................................................................................2-52.4.4 Routing Process: Error Handling...........................................................................................................2-5

3 Interface Definition...................................................................................................................3-13.1 Messages Definition........................................................................................................................................3-2

3.1.1 CCR........................................................................................................................................................3-23.1.2 CCA........................................................................................................................................................3-33.1.3 CER........................................................................................................................................................3-33.1.4 CEA........................................................................................................................................................3-33.1.5 DWR.......................................................................................................................................................3-43.1.6 DWA......................................................................................................................................................3-4

3.2 AVPs Definition..............................................................................................................................................3-43.3 Result Codes Definition..................................................................................................................................3-4

3.3.1 Error Types of Result Codes..................................................................................................................3-5

OCSDCC Description Contents


v

3.3.2 Result Codes...........................................................................................................................................3-5

ContentsOCS

DCC Description

vi Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 01 (2011-09-20)

Figures

Figure 1-1 Format of the message header............................................................................................................1-3Figure 1-2 Format of the AVP header..................................................................................................................1-5Figure 2-1 Logical structure between the OCS interface and the external NEs...................................................2-2Figure 2-2 End-to-end connection: CER and CEA..............................................................................................2-3Figure 2-3 End-to-end connection: DWR and DWA...........................................................................................2-4Figure 2-4 End-to-end connection: CCR and CCA..............................................................................................2-4

OCSDCC Description Figures


vii

Tables

Table 1-1 Message list..........................................................................................................................................1-5Table 1-2 Data types of the AVP data format......................................................................................................1-6Table 1-3 Specifications that the DCC interface reference of the OCS complies with......................................1-11Table 3-1 Lifecycle state...................................................................................................................................... 3-5Table 3-2 Management state.................................................................................................................................3-6Table 3-3 Result codes......................................................................................................................................... 3-6

OCSDCC Description Tables


ix

1 Protocol Overview

About This Chapter

The Diameter Credit Control (DCC) protocol is adopted between the OCS and the external real-time charging network elements (NEs) to process real-time charging requests. The external real-time charging NEs include the Service Control Point (SCP), mobile data service platform(MDSP), and other NEs that can trigger charging requests.

1.1 Definition of the DCC ProtocolThe DCC protocol is an application protocol developed from the Diameter protocol. The DCCprotocol provides a general solution to real-time cost and credit control. A protocol is a carrierof services, and services are entities of a certain protocol.

1.2 Format of the DCC ProtocolThis section describes the structure of the DCC protocol. A DCC message consists of the messageheader and message body.

1.3 TermsThis section describes the terms used in this document.

1.4 SpecificationsThis section describes the specifications that the DCC interface reference complies with.

OCSDCC Description 1 Protocol Overview


1-1

1.1 Definition of the DCC ProtocolThe DCC protocol is an application protocol developed from the Diameter protocol. The DCCprotocol provides a general solution to real-time cost and credit control. A protocol is a carrierof services, and services are entities of a certain protocol.

The Diameter protocol provides a frame that is secure, reliable, and easy to extend for all kindsof authentication, authorization, and accounting services. You need to define only the followinginformation about the DCC protocol to implement certain access or application services:

l Application ID of the application protocol

l Network entities that are involved in communications

l Contents of the messages that are sent between entities communicating with each other

l Protocol process

Background

The Diameter protocol is developed as an improvement or a replacement of the RemoteAuthentication Dial-In User Service (Radius) protocol. The purpose is to support the IP-basedAuthentication, Authorization, and Accounting (AAA) protocol.

The following section describes the background of the Diameter protocol briefly:

l Who raises the idea of DiameterWhen Diameter does not share a common protocol data unit (PDU) with Radius,considerable effort is expended in enabling backward compatibility with Radius. Thepurpose is to deploy the two protocols in the same network. Initially, people expect thatDiameter is deployed within new network devices, and within gateways enablingcommunication between legacy Radius devices and Diameter agents. This capability,described in [NASREQ], enables Diameter support to be added to legacy networks, byaddition of a gateway or server speaking both Radius and Diameter.

l Why Diameter is used by 3GPPThe Third Generation (3G) network is evolving into the IP network. The core network usesthe network entities that support the IP protocol, and the access network uses the IP-basedtechnologies. In addition, mobile terminals become IP clients that can be activated.Therefore, the Diameter protocol, which is a new-generation AAA protocol, is introducedby The Third Generation Partner Plan (3GPP).

l What is the relation between Huawei and DiameterDiameter has outstanding feature advantages and is becoming a mainstream specification.With extendable Diameter, Huawei can provide more secure products for users.

Features

The Diameter protocol has the following features:

l Owning excellent failure processing mechanism, and supporting failover and failback.

l Owning the ability of quickly finding that the opposite end is unreachable.

l Owning excellent mechanism for processing packet loss by confirming every message.

l Ensuring the completeness and confidentiality of data.

1 Protocol OverviewOCS

DCC Description

1-2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 01 (2011-09-20)

l Supporting end-to-end security, Transport Layer Security (TLS), and IP Security Protocol(IPSec).

l Authenticating and authorizing every session to ensure the security.

1.2 Format of the DCC ProtocolThis section describes the structure of the DCC protocol. A DCC message consists of the messageheader and message body.

1.2.1 Format of the Message HeaderFigure 1-1 shows the format of the DCC message header. The fields in Figure 1-1 are sent inthe network byte sequence.

Figure 1-1 Format of the message header

The fields in Figure 1-1 are described as follows:

l Version: indicates the version of the Diameter protocol. The value of this field must be 1,indicating the Diameter version is 1. The length of the Version field is 1 byte.

l Message Length: indicates the length of the entire message including the message header.The length of the Massage Length field is 3 bytes.

l Command Flags: indicates the message type. The length of the Command Flags field is 1byte.

The command flags are described as follows:

– R(equest): indicates that the message is a request message or respond message. If themessage is a request message, set the value to 1. If the message is a response message,set the value to 0. The length of this command flag is 1 bit.



1-3

– P(roxiable): indicates whether the message can be forwarded. The value 1 indicates thatthe message can provide proxy, relay, or redirection. The value 0 indicates that themessage is processed locally. The length of this command flag is 1 bit.

– E(rror): indicates whether the message is an error message. The value 1 indicates thatthe message contains a protocol error, and the message is not consistent with thecommand that is described in the Augmented Backus Naur Form (ABNF). The messagethat is set on this bit is often an error message. This command flag cannot be set inrequest messages. The length of this command flag is 1 bit.

– T(Potentially re-transmitted message): indicates whether the message is a resentmessage. This command flag is set after a link failure. This helps to remove repeatedrequests. Do not set this command flag in response messages. The length of thiscommand flag is 1 bit.

– R(eserved): indicates a reserved bit. The value must be 0. The recipient must ignore thiscommand flag. The length of this command flag is 4 bits.

l Command-Code: indicates the command code that is related to the message. The commandcode of a response message is the same as the command code of the matching requestmessage. The length of the Command-Code field is 3 bytes.

l Application-Id: indicates the application ID that is involved in a message. The applicationID identifies the application where the message can be applied. The application can be anauthentication application. The application ID in a message header must be the same asany other related attribute-value-pairs (AVP) that is contained in the message. The lengthof the Application-Id field is 4 bytes.

For example, the application ID that is defined in the Diameter protocol can be one of thefollowing:

– 0: Indicates Diameter common messages.

– 1: Indicates NASREQ.

– 2: Indicates Mobile-IP, that is, the IP address used for the mobile phone to connect tothe internet.

– 3: Indicates Diameter base accounting.

– 0xffffffff: Indicates the relay.

– 4: Indicates the DCCA.

l Hop-by-Hop Identifier: indicates the identifier that helps to match requests or responses.The Hop-by-Hop identifier is unique in a certain link and at a certain time. The length ofthe Hop-by-Hop Identifier field is 4 bytes.

l End-to-End Identifier: indicates the identifier that is used to detect repeated messages. Thelength of the End-to-End Identifier field is 4 bytes.

l AVPs: indicates the attribute value of the Diameter protocol. AVP is used as the unit of theDiameter message body. An AVP contains a header, the data (for example, routeinformation) that is used to encapsulate certain protocols, and the information aboutauthentication, authorization, and accounting.

For more information about the AVP, see sections 1.2.3 Format of the AVP Header and1.2.4 Format of the AVP Data.

1.2.2 Message ListTable 1-1 lists the DCC messages that are involved in the document.


DCC Description


Issue 01 (2011-09-20)

Table 1-1 Message list

Command Acronym CommandCode

Reference

Credit-Control-Request

CCR 272 3.1.1 CCR

Credit-Control-Answer

CCA 272 3.1.2 CCA

Capabilities-Exchange-Request

CER 257 3.1.3 CER

Capabilities-Exchange-Answer

CEA 257 3.1.4 CEA

Device-Watchdog-Request

DWR 280 3.1.5 DWR

Device-Watchdog-Answer

DWA 280 3.1.6 DWA

1.2.3 Format of the AVP HeaderAVP is used as the unit of the Diameter message body. An AVP message consists of the AVPheader and AVP data. Figure 1-2 shows the format of the AVP header. The fields in Figure1-2 are sent in the network byte sequence.

Figure 1-2 Format of the AVP header

The fields in Figure 1-2 are described as follows:



1-5

l AVP Code: indicates the code of the AVP. For example, the value of the AVP Code fieldof Original-Host AVP is 264. An AVP code and a vendor ID are used together to identifyan attribute uniquely. The length of the AVP Code field is 4 bytes.

l VMPrrrrr: indicates the AVP flag that notifies the message recipient of the methods forprocessing each attribute. The length of the VMPrrrrr field is 1 byte.– V: indicates whether the AVP header contains the Vendor-ID field. The value 1

indicates that the Vendor-ID field is contained and 0 indicates the Vendor-ID field isnot contained. The length of the V field is 1 bit.

– M: indicates whether the AVP is necessary. The value 1 indicates that the AVP isnecessary and 0 indicates that the AVP is not necessary. The length of the M field is 1bit.

– P: indicates whether the AVP data is encrypted. The value 1 indicates that the AVP datais encrypted and 0 indicates that the AVP data is not encrypted. The length of the P fieldis 1 bit.

– r: indicates the reserved bit that is not in use. Set the value to 0. The length of the r fieldis 5 bits.

l AVP Length: indicates the length of the AVP data. The length of the AVP data must be aninteger multiple of four. If the length is not an integer multiple of four, fill \0. The lengthof the AVP Length field is 3 bytes.

l Vendor-ID (opt): indicates the vendor of the device that generates the AVP. The vendorID of Huawei is 2011. The length of the Vendor-ID (opt) field is 4 bytes. In this field,opt indicates that Vendor-ID is optional.

l Data: indicates the specific data that is recorded. The type of the data is determined byAVP Code.

1.2.4 Format of the AVP DataAVP is used as the unit of the Diameter message body. An AVP message consists of the AVPheader and AVP data. The length of the AVP data field is greater than or equal to 0 bytes,including the length of the information defined by attributes. The format and length of the AVPdata field depend on the values of the AVP Code and AVP Length fields. The format of theAVP data field must be one of the data types listed in Table 1-2.

Table 1-2 Data types of the AVP data format

Data Type Description

OctetString Indicates a string of variable length.Unless otherwise specified, the value of the AVP Length field mustbe set to 8 bits or greater. If the V bit is valid, the value is 12 bits. Ifthe value of the AVP Length field of this type is not an integermultiple of four, fill a required character string.

Integer32 Indicates a 32-bit signed integer that is sent in the network bytesequence.The value of the AVP Length field must be set to 12 bits. If the V bitis valid, the value is 16 bits.


DCC Description


Issue 01 (2011-09-20)


Integer64 Indicates a 64-bit signed integer that is sent in the network bytesequence.The value of the AVP Length field must be set to 16 bits. If the V bitis valid, the value is 20 bits.

Unsigned32 Indicates a 32-bit unsigned integer that is sent in the network bytesequence.The value of the AVP Length field must be set to 12 bits. If the V bitis valid, the value is 16 bits.

Unsigned64 Indicates a 64-bit unsigned integer that is sent in the network bytesequence.The value of the AVP Length field must be set to 16 bits. If the V bitis valid, the value is 20 bits.

Float32 Indicates a 32-bit floating point number that is sent in the networkbyte sequence.The value of the AVP Length field must be set to 12 bits. If the V bitis valid, the value is 16 bits.

Float64 Indicates a 64-bit floating point number that is sent in the networkbyte sequence.The value of the AVP Length field must be set to 16 bits. If the V bitis valid, the value is 20 bits.

Grouped Indicates a set of AVPs.The sequence of the AVPs is arranged according to the definedsequence. Each AVP contains the AVP header and filler. The valueof the AVP Length field must be set to 8 bits (or 12 bits if the V bitis valid) plus the total length of the set of AVPs. The total length ofthe AVPs of this type is always an integer multiple of four.

Address Indicates the address that is presented in numeric string.The first two bytes indicate the address type. The following bytesindicate the address.For example, to differentiate the 32-bit (IPV4) address from the 128-bit (IPV6) address, the first two bytes indicate the address type.

Time Indicates the time that is presented in numeric string, consisting of atleast 4 bytes.The format of the first 4 bytes is the same as the format of the NTPtime stamp. The Time data type indicates the seconds from1900-01-01 00:00:00 to 2036-02-07 06:28:16.

UTF8String Indicates the UTF-8 transmission format.

DiameterIdentity Indicates the unique identifier of the DCC node that is used to detectrepeated connections and routing loops.DiameterIdentity = FQDN of the DCC node



1-7


Enumerated Indicates the enumerated type.This data type contains a list of valid values and related description,and is described in the DCC where the AVP involves.

NOTEl FQDN: Fully Qualified Domain Name

l NTP: Network Time Protocol

1.3 TermsThis section describes the terms used in this document.

AAA

Authentication, Authorization and Accounting (AAA) are protocols that are implemented tosecurely determine the identities and privileges of users and to track the activities of the users.

AAA ensures the lawful rights and interests of users and the secure and reliable running of thenetwork system.

l Authentication

The authentication network system validates the user identity when a user uses the resourcesin the network system.

l Authorization

The authorization network system authorizes users to use resources in certain ways.

l Accounting

The accounting network system collects and records the information about the resourceusage. The purpose is to collect the fee for using the resources from users or to audit data.

AVP

The Diameter protocol consists of a header followed by one or more AVPs. An AVP includesa header and is used to encapsulate protocol-specific data (such as routing information) andauthentication, authorization, and accounting information.

Diameter Agent

A Diameter agent is a diameter node that provides relay, proxy, redirection, or translationservices.

Diameter Client

A diameter client is a device at the edge of the network that performs access control. An exampleof a Diameter client is a network access server (NAS) or a foreign agent (FA).


DCC Description


Issue 01 (2011-09-20)

Diameter Node

A diameter node is a host process that implements the diameter protocol and serves as a client,an agent, or a server.

Diameter Peer

A diameter peer is a diameter node to which a specific diameter node has a direct transportconnection.

Diameter Server

A diameter server is the server that handles authentication, authorization, and accountingrequests for a particular realm. With this nature, a diameter server must support Diameterapplications in addition to the basic protocol.

Home Realm

A home realm is the administrative domain with which the user maintains an accountrelationship.

Home Server

A home server is a Diameter server that is located in the home area.

Local Realm

A local realm is the administrative domain providing services to certain users. An administrativedomain can serve as a local realm for certain users. At the same time, the administrative domaincan serve as a home realm for others.

Upstream

Upstream is used to identify the direction of a particular Diameter message from the accessdevice to the home server.

Downstream

Downstream is used to identify the direction of a particular Diameter message from the homeserver to the access device.

End-to-End Security

TLS and IPsec provide hop-by-hop security or security across a transport connection. When arelay or proxy is involved, the hop-by-hop security does not protect the entire Diameter usersession.

End-to-end security is the security between Diameter nodes, possibly communicating throughDiameter Agents. The security protects the entire Diameter communications path from theoriginating Diameter node to the terminating Diameter node.



1-9

Interim AccountingAn interim accounting message provides a snapshot of usage during a user session. If a devicerestart or any other network problem prevents the reception of a session summary message orsession record, an interim accounting message is used for partial accounting on the user session.

Proxy AgentProxy is short for proxy agent. In addition to forwarding requests and responses, proxy agentsmake policy decisions that are related to resource usage and provisioning. This job is completedthrough the track of the statuses of NAS devices.

Proxy agents do not respond to client requests before receiving responses from the server. If therequests and responses that are to be forwarded violate policies, proxy agents can originate Rejectmessages. Therefore, proxy agents must understand the semantics of the messages passingthrough them. Proxy agents may not support all the Diameter applications.

Network Access IdentifierIn the Diameter protocol, the network access identifier (NAI) is used to extract the identity andrealm of a user. The identity is used to identify the user during authentication or authorization,whereas the realm is used for message routing.

RealmA realm is a character string in the NAI that follows the character @. NAI realm names must beunique and obey the administration of the domain name server (DNS) namespace.

Diameter uses the realm (loosely referred to as domain) to determine whether messages can beprocessed locally, or whether they must be routed or redirected.

Session StateA stateful agent is an agent that maintains session state information by tracking all the authorizedactive sessions. Each authorized session is bound to a particular service. The state of eachauthorized session is active unless one of the following cases occurs:l The authorized session is notified to change the state.l The authorized session expires.

Transport ConnectionA transport connection is a Transfer Control Protocol (TCP) or a Stream Control TransmissionProtocol (SCTP) connection existing directly between Diameter peers. Transport connection isalso called peer-to-peer connection.

WordA word is a grouping length unit and equal to 2 bytes.

Packet LossThe packet loss is the discarding of data packets in a network when a device is overloaded orcannot accept any incoming data during a specified period.


DCC Description


Issue 01 (2011-09-20)

1.4 SpecificationsThis section describes the specifications that the DCC interface reference complies with.

Table 1-3 lists the specifications that the DCC interface reference of the OCS complies with.

Table 1-3 Specifications that the DCC interface reference of the OCS complies with

Specification Description

3GPP 32105-004 3G Charging and Billing Stage 2 description

3GPP 32815-600 OCS architecture study

OCP interface specification of the OCSof China Telecommunication V1.03

OCP interface specification of the OCS of ChinaTelecommunication V1.03

IETF RFC 4006 Diameter Credit-Control Application

IETF RFC 3588 Diameter Base Protocol

3GPP TS 32.299 V6.6.0 Telecommunication management; Chargingmanagement; Diameter charging application

3GPP TS 32.215 Telecommunication management; Chargingmanagement; Charging data description for thePacket Switched (PS) domain

3GPP TS 32.251 Telecommunication management; Chargingmanagement; Packet Switched (PS) domaincharging

NOTEOCP: Online Charging Protocol



1-11

2 Interface Overview

About This Chapter

2.1 DCC Application in the OCSThis section describes the DCC Application in the OCS and the external network elements.

2.2 Diameter Client and Diameter ServerThis section describes the two key concepts in the DCC protocol: Diameter client and Diameterserver.

2.3 Logical Structure of the OCS InterfaceThis section describes the logical structure between the DCC interface and the SCP, and betweenthe DCC interface and the MDSP in the OCS service.

2.4 Process of Connection EstablishmentThis section describes the routing process based on the end-to-end connection of the DCC.

OCSDCC Description 2 Interface Overview


2-1

2.1 DCC Application in the OCSThis section describes the DCC Application in the OCS and the external network elements.

The DCC is applied in the OCS to meet the charge requirements.

External network elements (NEs) such as Service Control Point (SCP) or Online ChargingGateway (OCG) can send charging request to OCS to carry out real time billing process.

In order to meet various service requirements, AVPs described in this document have beenextended by Huawei from the code 20338, and by the carrier from the code 60000. In ourdocuments, the carrier is one role of the third party.

2.2 Diameter Client and Diameter ServerThis section describes the two key concepts in the DCC protocol: Diameter client and Diameterserver.

The network nodes that support the DCC protocol function as the application layers of theDiameter client and Diameter server. The party that sends a request is called Diameter client,whereas the party that receives and handles the request is called Diameter server.

The client and the server are logical concepts but not physical concepts. The functional entityof the SCP sends a charging request, that is, Credit-Control-Request (CCR), to the OCS. TheOCS then returns a charging response message, that is, Credit-Control-Answer (CCA). In thisspecific Diameter charging session, the SCP is the client and the OCS is the server logically.

2.3 Logical Structure of the OCS InterfaceThis section describes the logical structure between the DCC interface and the SCP, and betweenthe DCC interface and the MDSP in the OCS service.

The DCC protocol is adopted between the OCS and the external real-time charging NEs toprocess real-time charging requests. The external real-time charging NEs that can triggercharging requests. The OCS is the server of the DCC, and the external real-time charging NEsare clients of the DCC.

Figure 2-1 shows the logical structure between the OCS interface and the external NEs.

Figure 2-1 Logical structure between the OCS interface and the external NEs

SCP Other NEs

DCC interface

DCC interface

OCS

2 Interface OverviewOCS

DCC Description


Issue 01 (2011-09-20)

2.3.1 Interface Relation Between the DCC and the SCP

The online charging process of the intelligent network (IN) service is as follows:

1. The SCP sends an online charging request to the OCS through the DCC protocol withrelevant charging parameters.

2. The OCS performs the charging logic and returns the charging logic to the SCP throughthe DCC protocol.

2.3.2 Interface Relation Between the DCC and the MDSP

The online charging process of the value-added data service that is managed by the MDSP is asfollows:

1. The MDSP sends an online charging request to the OCS through the DCC protocol withrelevant charging parameters.

2. The OCS performs the charging logic and returns the charging logic to the MDSP throughthe DCC protocol.

2.4 Process of Connection EstablishmentThis section describes the routing process based on the end-to-end connection of the DCC.

The Diameter client and the Diameter server are Diameter peers. In the OCS charging services,the OCS functions as the server and other external entities, such as the SCP, function as theclients.

2.4.1 End-to-End Connection DiagramThe Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA)messages are used for capability negotiation during call establishment. Figure 2-2 shows theend-to-end connection.

Figure 2-2 End-to-end connection: CER and CEA

Connection establishment

Server

CER

CEA

Client

The Device-Watchdog-Request (DWR) and Device-Watchdog-Answer (DWA) messages areused for handshake, namely, watching the status, during call establishment. Figure 2-3 showsthe end-to-end connection.



2-3

Figure 2-3 End-to-end connection: DWR and DWA

Client Server

DWR

DWA

The Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) messages are used forcredit control during call establishment. Figure 2-4 shows the end-to-end connection.

Figure 2-4 End-to-end connection: CCR and CCA

Client Server

CCR

CCA

2.4.2 Routing Process: Routing a Request Message

Routing Process of a Request MessageThe routing process of a request message is as follows:

1. After receiving a request message, a Diameter peer checks whether the message is a CER,DWR, or CCR message. If the message is a CER, DWR, or CCR message, establish aconnection according to the peer state machine. If the message is not a CER, DWR, or CCRmessage, go to Step 2.

2. Check whether the message contains the Destination-Host or Destination-Realm AVP.If the message does not contain the mentioned AVPs, the message is forwarded to the upper-level application, such as the SCP service, of the receiving peer for processing.l In the case that the Destination-Host AVP exists

– If the value of this field equals the receiving peer identifier, the request message isforwarded to the upper-level application of the receiving peer for processing.

– If the value of this field equals one of the peer identifiers which directly connectwith the receiving peer, the request message is forwarded to the peer for processing.

l In the case that the Destination-Realm AVP exists– If the value of this field is in the realm range that the receiving peer supports, and

the receiving peer can process the requests of the application, the request messageis forwarded to the upper-level application of the receiving peer for processing.


DCC Description


Issue 01 (2011-09-20)

– If the value of this field is not in the realm range that the receiving peer supports,query the routing table for a specific route to forward the request message to a peerthat directly connects with the receiving peer.

Routing TableA routing table is used to route request messages.

A routing table contains the following basic information:l Realm Name and Application Identifier: These two fields are key fields for querying the

routing table.l Peer identifier of the forwarded next hop: This field indicates the wanted result of querying

the routing table. This peer ID must exist in the peer table that is configured on the sendingpeer previously.

Request Queue to Be RespondedA request queue to be responded is used to route response messages.

The request queue to be responded records the information about the nodes of the request queueto be responded. Each request queue to be responded must contain the following information:l Request message body (optional)l Current value of Hop-by-Hop in this request messagel Value of Hop-by-Hop of the preceding hop in this request messagel Peer information about the preceding hop in this request message

2.4.3 Routing Process: Routing a Response Message

Routing a response message through the Diameter protocol is different from routing a requestmessage. The routing process is based on the value of Hop-by-Hop. The path where the responsemessage is returned is the same as the path where the request message is received.

The routing process of a response message is as follows:

1. After receiving a response message, a Diameter peer checks whether the message is a CEA,DWA or CCA message.If the message is a CEA, DWA or CCA message, establish a connection according to thepeer state machine. If the message is not a CEA, DWA or CCA message, go to Step 2.

2. If the preceding requests are not involved, query the request queue to be responded for thevalue of the Hop-by-Hop field of this request message.l If the value can be found, enter the value of the Hop-by-Hop field of the preceding hop

that is recorded in the request queue to be responded of the receiving peer in the Hop-by-Hop field of this message. Then, send the response message to the peer of thepreceding hop that is recorded in the request queue to be responded of the receivingpeer, and delete the node of this request queue to be responded.

l If the value is not found, discard this message.

2.4.4 Routing Process: Error Handling

Error handling is performed in one of the following cases:



2-5

l The relay agent cannot receive the response message matching the node of a response queueto be responded for a long period.

l The relay agent receives a response message containing error information, for example, theserver is too busy to process request messages.

The error handling principles are as follows:l If the relay agent already saves the original request message, find an alternative route to

send the request message.l If the relay agent does not save the original request message, send the response message to

the preceding hop of the matching request message.


DCC Description


Issue 01 (2011-09-20)

3 Interface Definition

About This Chapter

3.1 Messages DefinitionThis section describes the definition of DCC messages, including CCR/CCA, CER /CEA, DWR/DWA.

3.2 AVPs DefinitionThis section describes the common AVPs in the CCR and CCA messages.

3.3 Result Codes DefinitionThis section describes the result codes of DCC messages.

OCSDCC Description 3 Interface Definition


3-1

3.1 Messages DefinitionThis section describes the definition of DCC messages, including CCR/CCA, CER /CEA, DWR/DWA.

Diameter is an extendable protocol. In this document, the AVP code (from digits 1 to 255) isthe reserved code of the Radius with forward compatibility. The code (from digits 256 to 20337)is applied to the Diameter. The code (from digit 20338 on) is extended by Huawei.

In message definition, the description of the special symbols in the AVP name is as follows:l <>: indicates that the AVP is mandatory and the AVP with this symbol is at the beginning

of a message.l {}: indicates that this AVP is mandatory.l []: indicates that this AVP is optional.l *[]: indicates that the AVP is optional and is repeated.

In the OCS charging service, the DCC protocol message contains CCR and CCA, CER andCEA, and DWR and DWA. The command code of the answer message is the same as thecommand code of the matching request message. For example, the command code of the CCRand CCA are 272. The command code is one of the components of the DCC message headerand AVPs compose the DCC message body.

3.1.1 CCRCCR is a basic message of the DCC. The command code of the CCR is 272. The CCR is a requestmessage that is applied to credit control, and is sent to the OCS from the SCP, MDSP and theother network elements.

The format of a CCR is as follows:<Credit-Control-Request> ::= <Diameter Header: 272, REQ, PXY> <Session-Id> {Origin-Host} {Origin-Realm} [Destination-Host] {Destination-Realm} {Auth-Application-Id} {Service-Context-Id} {CC-Request-Type} {CC-Request-Number} [CC-Subsession-Id] [User-Name] [Origin-State-Id] [Event-Timestamp] *[Subscription-Id] [Service-Identifier] [Termination-Cause] *[Route-Record] [Requested-Action] [Requested-Service-Unit] *[Used-Service-Unit] [Multiple-Services-Indicator] *[Multiple-Services-Credit-Control] [CC-Correlation-Id] [Service-Information]

3 Interface DefinitionOCS

DCC Description


Issue 01 (2011-09-20)

3.1.2 CCACCA is a basic message of the DCC. The command code of the CCA is 272. The CCA is aresponse message that is applied to credit control, and is sent to the SCP, MDSP and other NEsfrom the OCS.

The format of a CCA is as follows:<Credit-Control-Answer> ::= <Diameter Header: 272, PXY> <Session-Id> {Result-Code} {Origin-Host} {Origin-Realm} {Auth-Application-Id} {CC-Request-Type} {CC-Request-Number} [CC-Subsession-Id] [User-Name] [CC-Session-Failover] [Origin-State-Id] [Event-Timestamp] [Granted-Service-Unit] [Cost-Information] [Final-Unit-Indication] *[Multiple-Services-Credit-Control] [Check-Balance-Result] [Credit-Control-Failure-Handling] [Direct-Debiting-Failure-Handling] [Validity-Time] [Service-Information]

3.1.3 CERCER is a basic message of the DCC. The command code of CER is 257. The CER is applied tothe capability exchange request in the connection establishment process.

The format of a CER is as follows:<Capabilities-Exchange-Request> ::= <Diameter Header: 257, REQ> {Origin-Host} {Origin-Realm} 1*{Host-IP-Address} {Vendor-Id} {Product-Name} [Origin-State-Id] *[Supported-Vendor-Id] *[Auth-Application-Id] *[Inband-Security-Id] *[Acct-Application-Id] *[Vendor-Specific-Application-Id] [Firmware-Revision] *[AVP]

3.1.4 CEACEA is a basic message of the DCC. The command code of the CEA is 257. The CEA is appliedto the capability exchange response in the connection establishment process.

The format of a CEA is as follows:<Capabilities-Exchange-Answer> ::= <Diameter Header: 257> {Result-Code} {Origin-Host} {Origin-Realm} 1*{Host-IP-Address} {Vendor-Id} {Product-Name} [Origin-State-Id]



3-3

[Error-Message] *[Failed-AVP] *[Supported-Vendor-Id] *[Auth-Application-Id] *[Inband-Security-Id] *[Acct-Application-Id] *[Vendor-Specific-Application-Id] [Firmware-Revision] *[AVP]

3.1.5 DWRDWR is a basic message of the DCC. The command code of the DWR is 280. The DWR isapplied to the device monitor request in the connection establishment process. A DWR messageis also called a heartbeat message or a handshake message.

The format of a DWR is as follows:<Device-Watchdog-Request> ::= <Diameter Header: 280, REQ> {Origin-Host} {Origin-Realm} [Origin-State-Id]

3.1.6 DWADWA is a basic message of the DCC. The command code of the DWA is 280. The DWA isapplied to the device monitor response in the connection establishment process. A DWAmessage is also called a heartbeat message or a handshake message.

The format of a DWA is as follows:<Device-Watchdog-Answer> ::= <Diameter Header: 280> {Result-Code} {Origin-Host} {Origin-Realm} [Error-Message] *[Failed-AVP] [Original-State-Id]

3.2 AVPs DefinitionThis section describes the common AVPs in the CCR and CCA messages.

AVP is used as the unit of the Diameter message body. Each AVP has a specific messageparameter value. An AVP contains the header, the data (for example, route information) that isused to encapsulate certain protocols, and the information about the authentication,authorization, and accounting.

An AVP group which can be considered as an AVP is a set of several AVPs. An AVP groupcan contain several AVP groups.

This section describes the common AVPs in the CCR and CCA messages.

3.3 Result Codes DefinitionThis section describes the result codes of DCC messages.

A result code indicates whether a particular request was completed successfully or an erroroccurred. All Diameter answer messages defined in IETF applications must include one Result-Code AVP.


DCC Description


Issue 01 (2011-09-20)

A unsuccessful Result-Code AVP must include the Error-Reporting-Host AVP if the host settingthe Result-Code AVP is different from the identity encoded in the Origin-Host AVP.

3.3.1 Error Types of Result CodesThe Result-Code data field contains an IANA-managed 32-bit address space that representserrors. The Diameter protocol provides the following types of error codes, which can be extendedbased on the actual situation. The error type is identified by the first digit in the decimal notation:

l 1xxx: information

l 2xxx: success

l 3xxx: protocol error

l 4xxx: transient failure

l 5xxx: permanent failure

A non-recognized type, the one whose first digit is not defined in the preceding page, is handledas a permanent failure.

3.3.2 Result CodesThis section describes the definition of the user state and the result codes.

User State Introduction

The user state consists of the lifecycle state and the management state.

Seven digits form the Auth-userstate AVP as CCMMMMM, the first C indicates the life cyclestate of the prepaid subscriber, the second digit C indicates the life cycle state of the postpaidsubscriber, and the followed five digits MMMMM indicates the management state of thesubscriber.

The detailed values are as follows.

Table 3-1 shows the lifecycle state of the account.

Table 3-1 Lifecycle state

Value State Description

0 Idle Not activated state

1 Active In active state

2 Suspend In suspend state

3 Disable In disabled state

4 Pool In pool state

Table 3-2 shows the management state of the d account.



3-5

Table 3-2 Management state

Sequence Number State Description

The third digit Loss/ClaimMissing Indicates whether to report the loss.l 0: Nol 1: Yes

The fourth digit Freeze Indicates whether to disable the account bythe customer.l 0: Nol 1: Yes

The fifth digit DP Indicates whether to disable the account bythe operator.l 0: Nol 1: Yes

The sixth digit Lock Indicates whether to use force to disable theaccount by the carrier.l 0: Nol 1: Yes

The seventh digit FraudLock Indicates whether to set the subscriber in theblacklist.l 0: Nol 1: Yes

Result Codes IntroductionThe result codes which consist of the lifecycle state and management state of the account referto the result codes in special service flows.

Table 3-3 shows a part of the other result codes.

Table 3-3 Result codes

Result code Description

2001 The short message is sent successfully and refund does notneed to be performed.

4527 The maximum recharge amount is exceeded.

4528 The recharge amount exceeds the maximum amount.

4999 A system error occurred during authentication.

4999 Refund does not need to be performed.


DCC Description


Issue 01 (2011-09-20)


4545 When the fee for the short message is refunded, the historyfee deduction record cannot be found.

4546 The service has not been subscribed or the call is barredaccording to the age of the calling party.

4547 or 4012 The balance is insufficient.

4548 The international gateway function is forbidden for aninternational roaming subscriber.

4560 The balance of the transfer-out party is smaller than theamount to be transferred.

4561 The maximum transfer times of the current month isexceeded.

4562 The minimum transfer amount at a time is not reached.

4563 The maximum transfer amount at a time is exceeded.

4564 The minimum balance before balance transfer is not reached.

4565 The minimum balance after balance transfer is not reached.

4566 The maximum transfer amount of the current day isexceeded.

4567 The maximum transfer amount of the current month isexceeded.

4568 The maximum transfer times of the current day is exceeded.

4569 The maximum account balance is exceeded.

4571 The short message notification is sent, indicating themaximum number of short messages that can be sent in acycle.

4570 The latest activation time is over or the maximum validityperiod expires.

5042 The transfer amount is not a multiple of the specified amount.

5045 The account type specified by the transfer-out party does notexist.

5043 When the transfer-in and transfer-out functions are enabledfor brands, authentication fails.

5029 During the three-level authentication for enabling thetransfer function, the authentication at the brand level fails.

4730 During the three-level authentication for enabling thetransfer function, the authentication at the sub-brand levelfails.



3-7


5031 During the three-level authentication for enabling thetransfer function, the authentication at the subscriber levelfails.

5050 The transfer function is not subscribed according to sub-brands. Therefore, transfer-out authentication fails.

5044 The transfer function is not subscribed according to sub-brands. Therefore, transfer-in authentication fails.

5046 The account type specified by the transfer-in party does notexist.

4999 The site does not support off-net MMS.

5000 The CUG function is completely disabled, so services areinterrupted.

5001 The group customer is locked.

5002 The group member is locked.

4600 The balance is insufficient to repay the loan.

5007 The recharge package type does not match the rechargeamount.

5041 The service duration of the transfer-in party does not reachthe minimum limit.

5040 The service duration of the transfer-out party does not reachthe minimum limit.

4552 The recharge record does not exist.

4553 Rollback is performed.

4555 The account balance to be adjusted or transferred isinsufficient.

4559 Initial request message for recharge. The recharge card hasbeen used.

4602 Event query message for recharge. The recharge card hasbeen used.

4999 The session times out.

4583 The maximum transfer amount of the current week isexceeded.

4584 The maximum transfer times of the current week is exceeded.

5047 During the three-level authentication for enabling thetransfer function, the authentication at the transfer-insubscriber level fails.


DCC Description


Issue 01 (2011-09-20)


5048 During the three-level authentication for enabling thetransfer function, the brand of the transfer-in subscriber doesnot support the account transfer function.

5049 During the three-level authentication for enabling thetransfer function, the sub-brand of the transfer-in subscriberdoes not support the account transfer function.

4998 Authentication failed.

4999 System error.

4998 Forbid triggering service through normal child card.

5080 The number of licnces is insufficient for activation.

4530 Transfer is not allowed because the accumulatedconsumption amount does not reach the threshold.

4533 The subscriber is in the Disable state.

4630 Failed to authenticate a subscriber for calling permission. Forexample, when a subscriber without the correspondingpermission makes international toll calls, the subscribercannot be authenticated.

4631 Failed to authenticate a subscriber for roaming permission.For example, when a subscriber without the correspondingpermission makes international roaming calls, the subscribercannot be authenticated.

4632 The number of accounts reaches the upper limit.

4642 The transfer-in and transfer-out accounts cannot be the same.

4648 Voice Unlimit.



3-9

OCS DCC Description

Documents

Transcript of OCS DCC Description