OCS DCC Description

OCS
R002C02LG0207
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 written
consent 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.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase 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 representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2011-09-20) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
About This Document
Intended Audience
This document is intended for:
l Development engineers
l Debugging engineers
l Maintenance engineers
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Updates in Issue 01 (2011-09-20)
Release for the first time.
OCS
DCC Description About This Document
iii
Contents
About This Document...................................................................................................................iii
1 Protocol Overview......................................................................................................................1-1
1.1 Definition of the DCC Protocol......................................................................................................................1-2
1.2 Format of the DCC Protocol...........................................................................................................................1-3
1.2.1 Format of the Message Header...............................................................................................................1-3
1.2.2 Message List...........................................................................................................................................1-4
1.2.3 Format of the AVP Header.....................................................................................................................1-5
1.2.4 Format of the AVP Data.........................................................................................................................1-6
1.3 Terms...............................................................................................................................................................1-8
1.4 Specifications................................................................................................................................................1-11
2 Interface Overview.....................................................................................................................2-1
2.1 DCC Application in the OCS..........................................................................................................................2-2
2.2 Diameter Client and Diameter Server.............................................................................................................2-2
2.3 Logical Structure of the OCS Interface...........................................................................................................2-2
2.3.1 Interface Relation Between the DCC and the SCP................................................................................2-3
2.3.2 Interface Relation Between the DCC and the MDSP.............................................................................2-3
2.4 Process of Connection Establishment.............................................................................................................2-3
2.4.1 End-to-End Connection Diagram...........................................................................................................2-3
2.4.2 Routing Process: Routing a Request Message.......................................................................................2-4
2.4.3 Routing Process: Routing a Response Message.....................................................................................2-5
2.4.4 Routing Process: Error Handling...........................................................................................................2-5
3 Interface Definition................................................................................................................... 3-1
3.1 Messages Definition........................................................................................................................................3-2
3.1.1 CCR........................................................................................................................................................3-2
3.1.2 CCA........................................................................................................................................................3-3
3.1.3 CER........................................................................................................................................................3-3
3.1.4 CEA........................................................................................................................................................3-3
3.1.5 DWR.......................................................................................................................................................3-4
3.1.6 DWA......................................................................................................................................................3-4
3.2 AVPs Definition..............................................................................................................................................3-4
3.3 Result Codes Definition..................................................................................................................................3-4
3.3.1 Error Types of Result Codes..................................................................................................................3-5
OCS
DCC Description Contents
v
3.3.2 Result Codes...........................................................................................................................................3-5
Contents
OCS
DCC Description
vi Huawei Proprietary and Confidential
Issue 01 (2011-09-20)
Figures
Figure 1-1 Format of the message header............................................................................................................1-3
Figure 1-2 Format of the AVP header..................................................................................................................1-5
Figure 2-1 Logical structure between the OCS interface and the external NEs...................................................2-2
Figure 2-2 End-to-end connection: CER and CEA..............................................................................................2-3
Figure 2-3 End-to-end connection: DWR and DWA...........................................................................................2-4
Figure 2-4 End-to-end connection: CCR and CCA..............................................................................................2-4
OCS
DCC Description Figures
vii
Tables
Table 1-1 Message list..........................................................................................................................................1-5
Table 1-2 Data types of the AVP data format......................................................................................................1-6
Table 1-3 Specifications that the DCC interface reference of the OCS complies with......................................1-11
Table 3-1 Lifecycle state...................................................................................................................................... 3-5
Table 3-2 Management state.................................................................................................................................3-6
Table 3-3 Result codes......................................................................................................................................... 3-6
OCS
DCC 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 Protocol
The DCC protocol is an application protocol developed from the Diameter protocol. The DCC
protocol provides a general solution to real-time cost and credit control. A protocol is a carrier
of services, and services are entities of a certain protocol.
1.2 Format of the DCC Protocol
This section describes the structure of the DCC protocol. A DCC message consists of the message
header and message body.
1.3 Terms
This section describes the terms used in this document.
1.4 Specifications
This section describes the specifications that the DCC interface reference complies with.
OCS
DCC Description 1 Protocol Overview
1-1
1.1 Definition of the DCC Protocol
The DCC protocol is an application protocol developed from the Diameter protocol. The DCC
protocol provides a general solution to real-time cost and credit control. A protocol is a carrier
of 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 kinds
of authentication, authorization, and accounting services. You need to define only the following
information 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 Remote
Authentication Dial-In User Service (Radius) protocol. The purpose is to support the IP-based
Authentication, Authorization, and Accounting (AAA) protocol.
The following section describes the background of the Diameter protocol briefly:
l Who raises the idea of Diameter
When Diameter does not share a common protocol data unit (PDU) with Radius,
considerable effort is expended in enabling backward compatibility with Radius. The
purpose is to deploy the two protocols in the same network. Initially, people expect that
Diameter is deployed within new network devices, and within gateways enabling
communication between legacy Radius devices and Diameter agents. This capability,
described in [NASREQ], enables Diameter support to be added to legacy networks, by
addition of a gateway or server speaking both Radius and Diameter.
l Why Diameter is used by 3GPP
The Third Generation (3G) network is evolving into the IP network. The core network uses
the network entities that support the IP protocol, and the access network uses the IP-based
technologies. In addition, mobile terminals become IP clients that can be activated.
Therefore, the Diameter protocol, which is a new-generation AAA protocol, is introduced
by The Third Generation Partner Plan (3GPP).
l What is the relation between Huawei and Diameter
Diameter 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 Overview
OCS
DCC Description
1-2 Huawei Proprietary and Confidential
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 Protocol
This section describes the structure of the DCC protocol. A DCC message consists of the message
header and message body.
1.2.1 Format of the Message Header
Figure 1-1 shows the format of the DCC message header. The fields in Figure 1-1 are sent in
the 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 1
byte.
The command flags are described as follows:
R(equest): indicates that the message is a request message or respond message. If the
message 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.
OCS
1-3
P(roxiable): indicates whether the message can be forwarded. The value 1 indicates that
the message can provide proxy, relay, or redirection. The value 0 indicates that the
message 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 that
the message contains a protocol error, and the message is not consistent with the
command that is described in the Augmented Backus Naur Form (ABNF). The message
that is set on this bit is often an error message. This command flag cannot be set in
request messages. The length of this command flag is 1 bit.
T(Potentially re-transmitted message): indicates whether the message is a resent
message. This command flag is set after a link failure. This helps to remove repeated
requests. Do not set this command flag in response messages. The length of this
command flag is 1 bit.
R(eserved): indicates a reserved bit. The value must be 0. The recipient must ignore this
command flag. The length of this command flag is 4 bits.
l Command-Code: indicates the command code that is related to the message. The command
code of a response message is the same as the command code of the matching request
message. The length of the Command-Code field is 3 bytes.
l Application-Id: indicates the application ID that is involved in a message. The application
ID identifies the application where the message can be applied. The application can be an
authentication application. The application ID in a message header must be the same as
any other related attribute-value-pairs (AVP) that is contained in the message. The length
of the Application-Id field is 4 bytes.
For example, the application ID that is defined in the Diameter protocol can be one of the
following:
0: Indicates Diameter common messages.
1: Indicates NASREQ.
2: Indicates Mobile-IP, that is, the IP address used for the mobile phone to connect to
the 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 of
the Hop-by-Hop Identifier field is 4 bytes.
l End-to-End Identifier: indicates the identifier that is used to detect repeated messages. The
length 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 the
Diameter message body. An AVP contains a header, the data (for example, route
information) that is used to encapsulate certain protocols, and the information about
authentication, authorization, and accounting.
For more information about the AVP, see sections 1.2.3 Format of the AVP Header and
1.2.4 Format of the AVP Data.
1.2.2 Message List
Table 1-1 lists the DCC messages that are involved in the document.
1 Protocol Overview
OCS
DCC Description
Issue 01 (2011-09-20)
Table 1-1 Message list
Command Acronym Command
Code
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 Header
AVP is used as the unit of the Diameter message body. An AVP message consists of the AVP
header and AVP data. Figure 1-2 shows the format of the AVP header. The fields in Figure
1-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:
OCS
1-5
l AVP Code: indicates the code of the AVP. For example, the value of the AVP Code field
of Original-Host AVP is 264. An AVP code and a vendor ID are used together to identify
an 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 for
processing 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 is
not contained. The length of the V field is 1 bit.
M: indicates whether the AVP is necessary. The value 1 indicates that the AVP is
necessary and 0 indicates that the AVP is not necessary. The length of the M field is 1
bit.
P: indicates whether the AVP data is encrypted. The value 1 indicates that the AVP data
is encrypted and 0 indicates that the AVP data is not encrypted. The length of the P field
is 1 bit.
r: indicates the reserved bit that is not in use. Set the value to 0. The length of the r field
is 5 bits.
l AVP Length: indicates the length of the AVP data. The length of the AVP data must be an
integer multiple of four. If the length is not an integer multiple of four, fill \0. The length
of the AVP Length field is 3 bytes.
l Vendor-ID (opt): indicates the vendor of the device that generates the AVP. The vendor
ID 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 by
AVP Code.
1.2.4 Format of the AVP Data
AVP is used as the unit of the Diameter message body. An AVP message consists of the AVP
header 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 AVP
data field depend on the values of the AVP Code and AVP Length fields. The format of the
AVP 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 must
be set to 8 bits or greater. If the V bit is valid, the value is 12 bits. If
the value of the AVP Length field of this type is not an integer
multiple of four, fill a required character string.
Integer32 Indicates a 32-bit signed integer that is sent in the network byte
sequence.
The value of the AVP Length field must be set to 12 bits. If the V bit
is valid, the value is 16 bits.
1 Protocol Overview
OCS
DCC Description
Issue 01 (2011-09-20)
Integer64 Indicates a 64-bit signed integer that is sent in the network byte
sequence.
Unsigned32 Indicates a 32-bit unsigned integer that is sent in the network byte
sequence.
Unsigned64 Indicates a 64-bit unsigned integer that is sent in the network byte
sequence.
Float32 Indicates a 32-bit floating point number that is sent in the network
byte sequence.
Float64 Indicates a 64-bit floating point number that is sent in the network
byte sequence.
Grouped Indicates a set of AVPs.
The sequence of the AVPs is arranged according to the defined
sequence. Each AVP contains the AVP header and filler. The value
of the AVP Length field must be set to 8 bits (or 12 bits if the V bit
is valid) plus the total length of the set of AVPs. The total length of
the 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 bytes
indicate 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 at
least 4 bytes.
The format of the first 4 bytes is the same as the format of the NTP
time stamp. The Time data type indicates the seconds from
1900-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 detect
repeated connections and routing loops.
DiameterIdentity = FQDN of the DCC node
OCS
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.
NOTE
l FQDN: Fully Qualified Domain Name
l NTP: Network Time Protocol

1.3 Terms
This section describes the terms used in this document.
AAA
Authentication, Authorization and Accounting (AAA) are protocols that are implemented to
securely 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 the
network system.
l Authentication
The authentication network system validates the user identity when a user uses the resources
in 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 resource
usage. 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 includes
a header and is used to encapsulate protocol-specific data (such as routing information) and
authentication, authorization, and accounting information.
Diameter Agent
A Diameter agent is a diameter node that provides relay, proxy, redirection, or translation
services.
Diameter Client
A diameter client is a device at the edge of the network that performs access control. An example
of a Diameter client is a network access server (NAS) or a foreign agent (FA).
1 Protocol Overview
OCS
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 transport
connection.
Diameter Server
A diameter server is the server that handles authentication, authorization, and accounting
requests for a particular realm. With this nature, a diameter server must support Diameter
applications in addition to the basic protocol.
Home Realm
A home realm is the administrative domain with which the user maintains an account
relationship.
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 administrative
domain can serve as a local realm for certain users. At the same time, the administrative domain
can serve as a home realm for others.
Upstream
Upstream is used to identify the direction of a particular Diameter message from the access
device to the home server.
Downstream
Downstream is used to identify the direction of a particular Diameter message from the home
server to the access device.
End-to-End Security
TLS and IPsec provide hop-by-hop security or security across a transport connection. When a
relay or proxy is involved, the hop-by-hop security does not protect the entire Diameter user
session.
End-to-end security is the security between Diameter nodes, possibly communicating through
Diameter Agents. The security protects the entire Diameter communications path from the
originating Diameter node to the terminating Diameter node.
OCS
1-9
Interim Accounting
An interim accounting message provides a snapshot of usage during a user session. If a device
restart or any other network problem prevents the reception of a session summary message or
session record, an interim accounting message is used for partial accounting on the user session.
Proxy Agent
Proxy is short for proxy agent. In addition to forwarding requests and responses, proxy agents
make policy decisions that are related to resource usage and provisioning. This job is completed
through the track of the statuses of NAS devices.
Proxy agents do not respond to client requests before receiving responses from the server. If the
requests and responses that are to be forwarded violate policies, proxy agents can originate Reject
messages. Therefore, proxy agents must understand the semantics of the messages passing
through them. Proxy agents may not support all the Diameter applications.
Network Access Identifier
In the Diameter protocol, the network access identifier (NAI) is used to extract the identity and
realm of a user. The identity is used to identify the user during authentication or authorization,
whereas the realm is used for message routing.
Realm
A realm is a character string in the NAI that follows the character @. NAI realm names must be
unique 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 be
processed locally, or whether they must be routed or redirected.
Session State
A stateful agent is an agent that maintains session state information by tracking all the authorized
active sessions. Each authorized session is bound to a particular service. The state of each
authorized 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 Connection
A transport connection is a Transfer Control Protocol (TCP) or a Stream Control Transmission
Protocol (SCTP) connection existing directly between Diameter peers. Transport connection is
also called peer-to-peer connection.
Word
A word is a grouping length unit and equal to 2 bytes.
Packet Loss
The packet loss is the discarding of data packets in a network when a device is overloaded or
cannot accept any incoming data during a specified period.
1 Protocol Overview
OCS
DCC Description
Issue 01 (2011-09-20)
1.4 Specifications
This 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 OCS
of China Telecommunication V1.03
OCP interface specification of the OCS of China
Telecommunication V1.03
IETF RFC 4006 Diameter Credit-Control Application
IETF RFC 3588 Diameter Base Protocol
3GPP TS 32.299 V6.6.0 Telecommunication management; Charging
management; Diameter charging application
3GPP TS 32.215 Telecommunication management; Charging
management; Charging data description for the
Packet Switched (PS) domain
3GPP TS 32.251 Telecommunication management; Charging
management; Packet Switched (PS) domain
charging
NOTE
OCP: Online Charging Protocol
OCS
1-11
2 Interface Overview
About This Chapter
2.1 DCC Application in the OCS
This section describes the DCC Application in the OCS and the external network elements.
2.2 Diameter Client and Diameter Server
This section describes the two key concepts in the DCC protocol: Diameter client and Diameter
server.
2.3 Logical Structure of the OCS Interface
This section describes the logical structure between the DCC interface and the SCP, and between
the DCC interface and the MDSP in the OCS service.
2.4 Process of Connection Establishment
This section describes the routing process based on the end-to-end connection of the DCC.
OCS
DCC Description 2 Interface Overview
2-1
2.1 DCC Application in the OCS
This 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 Charging
Gateway (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 been
extended by Huawei from the code 20338, and by the carrier from the code 60000. In our
documents, the carrier is one role of the third party.
2.2 Diameter Client and Diameter Server
This section describes the two key concepts in the DCC protocol: Diameter client and Diameter
server.
The network nodes that support the DCC protocol function as the application layers of the
Diameter 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 entity
of the SCP sends a charging request, that is, Credit-Control-Request (CCR), to the OCS. The
OCS then returns a charging response message, that is, Credit-Control-Answer (CCA). In this
specific Diameter charging session, the SCP is the client and the OCS is the server logically.
2.3 Logical Structure of the OCS Interface
This section describes the logical structure between the DCC interface and the SCP, and between
the DCC interface and the MDSP in the OCS service.
The DCC protocol is adopted between the OCS and the external real-time charging NEs to
process real-time charging requests. The external real-time charging NEs that can trigger
charging requests. The OCS is the server of the DCC, and the external real-time charging NEs
are 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

OCS
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 with
relevant charging parameters.
2. The OCS performs the charging logic and returns the charging logic to the SCP through
the 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 as
follows:
1. The MDSP sends an online charging request to the OCS through the DCC protocol with
relevant charging parameters.
2. The OCS performs the charging logic and returns the charging logic to the MDSP through
the DCC protocol.
2.4 Process of Connection Establishment
This 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 the
clients.
2.4.1 End-to-End Connection Diagram
The Capabilities-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA)
messages are used for capability negotiation during call establishment. Figure 2-2 shows the
end-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 are
used for handshake, namely, watching the status, during call establishment. Figure 2-3 shows
the end-to-end connection.
OCS
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 for
credit 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 Message
The 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 a
connection according to the peer state machine. If the message is not a CER, DWR, or CCR
message, 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 is
forwarded 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 connect
with 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 message
is forwarded to the upper-level application of the receiving peer for processing.
OCS
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 peer
that directly connects with the receiving peer.
Routing Table
A 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 sending
peer previously.
Request Queue to Be Responded
A 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 queue
to 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 message
l Value of Hop-by-Hop of the preceding hop in this request message
l 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 request
message. The routing process is based on the value of Hop-by-Hop. The path where the response
message 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 the
peer 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 the
value 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 the
preceding hop that is recorded in the request queue to be responded of the receiving
peer, 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:
OCS
2-5
l The relay agent cannot receive the response message matching the node of a response queue
to be responded for a long period.
l The relay agent receives a response message containing error information, for example, the
server 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.
OCS
DCC Description
Issue 01 (2011-09-20)
3 Interface Definition
About This Chapter
3.1 Messages Definition
This section describes the definition of DCC messages, including CCR/CCA, CER /CEA, DWR/
DWA.
3.2 AVPs Definition
This section describes the common AVPs in the CCR and CCA messages.
3.3 Result Codes Definition
This section describes the result codes of DCC messages.
OCS
DCC Description 3 Interface Definition
3-1
3.1 Messages Definition
This 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) is
the 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 and
CEA, and DWR and DWA. The command code of the answer message is the same as the
command code of the matching request message. For example, the command code of the CCR
and CCA are 272. The command code is one of the components of the DCC message header
and AVPs compose the DCC message body.
3.1.1 CCR
CCR is a basic message of the DCC. The command code of the CCR is 272. The CCR is a request
message that is applied to credit control, and is sent to the OCS from the SCP, MDSP and the
other 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]
OCS
DCC Description
Issue 01 (2011-09-20)
3.1.2 CCA
CCA is a basic message of the DCC. The command code of the CCA is 272. The CCA is a
response message that is applied to credit control, and is sent to the SCP, MDSP and other NEs
from 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 CER
CER is a basic message of the DCC. The command code of CER is 257. The CER is applied to
the 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 CEA
CEA is a basic message of the DCC. The command code of the CEA is 257. The CEA is applied
to 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]
OCS
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 DWR
DWR is a basic message of the DCC. The command code of the DWR is 280. The DWR is
applied to the device monitor request in the connection establishment process. A DWR message
is 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 DWA
DWA is a basic message of the DCC. The command code of the DWA is 280. The DWA is
applied to the device monitor response in the connection establishment process. A DWA
message 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 Definition
AVP is used as the unit of the Diameter message body. Each AVP has a specific message
parameter value. An AVP contains the header, the data (for example, route information) that is
used 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 group
can contain several AVP groups.
3.3 Result Codes Definition
This section describes the result codes of DCC messages.
A result code indicates whether a particular request was completed successfully or an error
occurred. All Diameter answer messages defined in IETF applications must include one Result-
Code AVP.
OCS
DCC Description
Issue 01 (2011-09-20)
A unsuccessful Result-Code AVP must include the Error-Reporting-Host AVP if the host setting
the Result-Code AVP is different from the identity encoded in the Origin-Host AVP.
3.3.1 Error Types of Result Codes
The Result-Code data field contains an IANA-managed 32-bit address space that represents
errors. The Diameter protocol provides the following types of error codes, which can be extended
based 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 handled
as a permanent failure.
3.3.2 Result Codes
This 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 cycle
state of the prepaid subscriber, the second digit C indicates the life cycle state of the postpaid
subscriber, and the followed five digits MMMMM indicates the management state of the
subscriber.
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.
OCS
3-5
Table 3-2 Management state
Sequence Number State Description
The third digit Loss/ClaimMissing Indicates whether to report the loss.
l 0: No
l 1: Yes
The fourth digit Freeze Indicates whether to disable the account by
the customer.
l 0: No
l 1: Yes
The fifth digit DP Indicates whether to disable the account by
the operator.
l 0: No
l 1: Yes
The sixth digit Lock Indicates whether to use force to disable the
account by the carrier.
l 0: No
l 1: Yes
The seventh digit FraudLock Indicates whether to set the subscriber in the
blacklist.
l 0: No
l 1: Yes

Result Codes Introduction
The result codes which consist of the lifecycle state and management state of the account refer
to 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 not
need 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.
OCS
DCC Description
Issue 01 (2011-09-20)
4545 When the fee for the short message is refunded, the history
fee deduction record cannot be found.
4546 The service has not been subscribed or the call is barred
according to the age of the calling party.
4547 or 4012 The balance is insufficient.
4548 The international gateway function is forbidden for an
international roaming subscriber.
4560 The balance of the transfer-out party is smaller than the
amount to be transferred.
4561 The maximum transfer times of the current month is
exceeded.
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 is
exceeded.
4567 The maximum transfer amount of the current month is
exceeded.
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 the
maximum number of short messages that can be sent in a
cycle.
4570 The latest activation time is over or the maximum validity
period expires.
5042 The transfer amount is not a multiple of the specified amount.
5045 The account type specified by the transfer-out party does not
exist.
5043 When the transfer-in and transfer-out functions are enabled
for brands, authentication fails.
5029 During the three-level authentication for enabling the
transfer function, the authentication at the brand level fails.
transfer function, the authentication at the sub-brand level
fails.
OCS
3-7
transfer function, the authentication at the subscriber level
fails.
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 not
exist.
4999 The site does not support off-net MMS.
5000 The CUG function is completely disabled, so services are
interrupted.
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 recharge
amount.
5041 The service duration of the transfer-in party does not reach
the minimum limit.
5040 The service duration of the transfer-out party does not reach
the minimum limit.
4552 The recharge record does not exist.
4553 Rollback is performed.
4555 The account balance to be adjusted or transferred is
insufficient.
4559 Initial request message for recharge. The recharge card has
been used.
4602 Event query message for recharge. The recharge card has
been used.
4999 The session times out.
4583 The maximum transfer amount of the current week is
exceeded.
4584 The maximum transfer times of the current week is exceeded.
transfer function, the authentication at the transfer-in
subscriber level fails.
OCS
DCC Description
Issue 01 (2011-09-20)
transfer function, the brand of the transfer-in subscriber does
not support the account transfer function.
transfer function, the sub-brand of the transfer-in subscriber
does 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 accumulated
consumption amount does not reach the threshold.
4533 The subscriber is in the Disable state.
4630 Failed to authenticate a subscriber for calling permission. For
example, when a subscriber without the corresponding
permission makes international toll calls, the subscriber
cannot be authenticated.
4631 Failed to authenticate a subscriber for roaming permission.
For example, when a subscriber without the corresponding
permission makes international roaming calls, the subscriber
cannot 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.
OCS
3-9

OCS DCC Description

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OCS DCC Description

Uploaded by

Copyright:

Available Formats

OCS

You might also like