This section presents the mobile charging protocol that used for credit control of online IMS services. The Diameter protocol was derived from Remote Access Dial In User Service (RADIUS) protocol with more flexibility, and is generally believed to be the next genera-tion Authenticagenera-tion, Authorizagenera-tion, and Accounting (AAA) protocol [21, 45, 46]. Diameter is an extensible protocol enabling AAA within and across IP multimedia networks that relies on secure and reliable transports. Its modular architecture offers a flexible base protocol which allows application-specific extensions. Diameter has proven successful in overcoming the limitations of RADIUS. Development of new IP- and telephony-based ser-vices is gaining momentum, and every service requires charging. Therefore, rapid growth in the usage of Diameter-based charging can be expected. The 3GPP has chosen the Diameter protocol to enable IMS network AAA capabilities [18, 39, 42].
Like RADIUS, Diameter follows the client-server architecture, where a client and a server interact through the Diameter request and answer message exchange. Several Diameter applications defined by Internet Engineering Task Force (IETF) are utilized in IMS, including the Diameter Credit Control (DCC) application for IP-based online charging control [30]. All-IP mobile network utilizes the DCC application to communicate with the OCS [10, 15]. In IMS online charging, the IMS network node (e.g., CSCF) acts
as a DCC client and the OCS acts as a DCC server. In this section, we describe the Diameter credit control messages and the Diameter message flow.
1.4.1 Diameter Credit Control Message
The DCC messages are described as follows: The Credit Control Request (CCR) message is sent from the DCC client to the DCC server to request an amount of credit for an online service. The CCR message contains the following Attribute Value Pairs (AVPs) [15, 30]:
• The Session-Id AVP identifies the credit control session.
• The Origin-Host and the Origin-Realm AVPs contain the address and the realm of the DCC client.
• The Destination-Host and the Destination-Realm AVPs contain the address and the realm of the DCC server.
• The Auth-Application-Id AVP contains value 4 as defined in RFC 4006 [30]. This value indicates the Diameter Credit Control Application.
• The Service-Context-Id AVP contains the identifier allocated by the service provider or by the standardization body.
• The CC-Request-Type AVP indicates the credit control request type for the on-line service. It can be one of the following types: INITIAL REQUEST (value 1) initiates a credit control session. UPDATE REQUEST (value 2) contains update credit control information for an in-progress session. This request is sent when the credit units currently allocated for the session are completely consumed. TER-MINATION REQUEST (value 3) terminates an in-progress credit control session.
EVENT REQUEST (value 4) is used in one-time credit control for event-based service.
• The CC-Request-Number AVP contains the sequence number of the message.
• The Subscription-Id AVP contains the identification of the user, which can be a SIP Uniform Resource Identifier (URI), an International Mobile Subscriber Identity (IMSI) or a Mobile Station ISDN Number (MSISDN).
• The Termination-Cause AVP is presented if the CC-Request-Type is set to TERMI-NATION REQUEST. This AVP provides the reason why the credit control session is terminated. For example, DIAMETER LOGOUT (value 1) indicates that the user terminates the credit control session.
• The Requested-Action AVP is only presented in the EVENT REQUEST message.
This AVP specifies the action for the event, such as DIRECT DEBITING, RE-FUND ACCOUNT, CHECK BALANCE or PRICE ENQUIRY.
• The Multiple-Services-Credit-Control AVP contains the parameters for quota man-agement, including the amount of request credit, the amount of used credit, the reporting reason, the identity of the used service, and the identifier of the rating group.
• The User-Name AVP contains the user name in the Network Access Identifier (NAI) format according to RFC 3588 [21].
• The Event-Timestamp AVP specifies the time when the accounting message is cre-ated.
• The Service-Information AVP contains the service specific parameters.
The Credit Control Answer (CCA) message is sent from the DCC server to the DCC client to grant an amount of credit for the online service. The CCA message contains the following AVPs:
• The Result-Code AVP contains the result of the credit control request.
• The CC-Session Failover AVP contains an indication to the DCC client whether or not a failover handling is used.
• The Credit-Control-Failure-Handling AVP determines the action in the Diameter client when the Diameter server is temporarily prevented, e.g., because of network failure. The action may be TERMINATE (with value 0), CONTINUE (with value 1) and RETRY AND TERMINATE (with value 2).
• The Multiple-Services-Credit-Control AVP contains the parameters for the quota management, including the amount of granted credit, the identifier of the requested service, the identifier for the rating group, the validity time for the usage of granted
1. CCR (INITIAL_REQUEST)
2. CCA (INITIAL_REQUEST)
3. CCR (UPDATE_REQUEST)
4. CCA (UPDATE_REQUEST)
5. CCR (TERMINATE_REQUEST)
6. CCA (TERMINATE_REQUEST) Reserve Units Operation
Reserve Units and Debit Units Operation
Debit Units Operation
Performs charging control
Performs charging control
Performs charging control
OCS (DCC Server) Network Node
(DCC Client)
Figure 1.3: Diameter Message Flow for Online Session.
credit units (i.e., the time when the DCC client should perform another credit control request), and the events (such as QoS changes or SGSN changes) that will trigger credit re-authorization procedure.
• The Cost-Information AVP contains the cost information of the requested service.
• The Session-Id, the Origin-Host, the Origin-Realm, the Auth-Application-Id, the CC-Request-Type, the CC-Request-Number, the Service-Information AVPs are sim-ilar to those in the CCR message.
1.4.2 Diameter Message Flow
The Diameter message flow for session-based online charging includes three types of credit control operations: Reserve Units operation (Steps 1 and 2 in Fig. 1.3), Reserve Units and Debit Units operation (Steps 3 and 4 in Fig. 1.3) and Debit Units operation (Steps 5 and 6 in Fig. 1.3). The following operations are executed for session-based service.