Ericsson CIP AVPs
Ericsson CIP (application id: 16777232)
Description:
The Charging Interrogation Protocol (CIP) is an application built on top of the Diameter protocol, primarily designed for handling charging-related functions in telecommunications networks. CIP enables communication between a CIP/IP Client (e.g., part of a Charging Control Node or Online Charging System) and a Service Data Point (SDP), facilitating session-based and event-based charging.
The main objective of CIP is to manage charging sessions by providing mechanisms for clients to query and interact with a charging system. This interaction ensures that services are billed accurately and promptly, either based on sessions (e.g., ongoing calls or data usage) or events (e.g., one-time balance checks or refunds). CIP plays a pivotal role in ensuring proper authorization, charging, and billing within the network, including support for multiple services within a single session.
Key Features
- Session-Based Charging: CIP manages multiple services within a single charging session, allowing for simultaneous charging of ongoing services like voice, SMS, and data.
- Event-Based Charging: Supports one-time transactions, such as balance inquiries, refunds, or direct debit operations.
- Multi-Service Credit Control (MSCC): CIP uses Multi-Service Credit Control AVPs to handle the charging of multiple services in parallel. Each service is identified using specific parameters like the Service-Identifier or Rating-Group.
- Re-Authorization: Supports server-initiated re-authorization using Re-Auth-Request (RAR) and Re-Auth-Answer (RAA) messages, enabling the charging system to reassess and update the ongoing service authorization during the session.
- CIR/CIA Commands: The protocol extends the Diameter Credit-Control Request (CCR) and Answer (CCA) commands into Charging Interrogation Request (CIR) and Charging Interrogation Answer (CIA) for the purpose of exchanging charging-related information between the CIP/IP Client and the SDP.
- Capability Exchange and Watchdog Support: Integrates Capability Exchange Request (CER) and Device Watchdog Request (DWR) messages for establishing peer-to-peer communication and ensuring system health.
Workflow
- Session Initiation: A charging session begins when the CIP/IP Client sends a Charging Interrogation Request (CIR) to the Service Data Point (SDP). The request contains details about the services that need to be charged.
- Service Management: Multi-Service Credit Control (MSCC) AVPs are used to define the individual services within the session. These AVPs include service-specific parameters such as the Service-Identifier or Rating-Group.
- Session Updates: As the session progresses, the CIP/IP Client may send update requests to modify the session parameters (e.g., adding a new service or modifying an ongoing service).
- Re-Authorization: During the session, the SDP can trigger a Re-Auth-Request (RAR) if additional authorization is required (e.g., for ongoing services or due to changing balance or service rules). The client responds with a Re-Auth-Answer (RAA).
- Session Termination: When all services are completed, or the session is no longer needed, the client sends a termination request, signaling the end of the charging session.
- Final Interrogation: After the session is terminated, the system performs a final interrogation to confirm the charges applied for the services rendered during the session.
Ericsson CIP interface operates in compliance with the Diameter Credit-Control Application [RFC 4006] and Diameter Base Protocol [RFC 3588].
AVPs in Ericsson CIP interface
package com.mobius.software.telco.protocols.diameter.primitives.cip
|
Name |
AVP Code |
Data Type |
Vendor |
|
Access-Information |
1063 |
Grouped |
Ericsson |
|
Used to provide details about the incoming access information to the Charging System. It encapsulates various attributes such as application identifiers, originating host and realm, request details, and timestamps. The AVP structure is defined as follows: Auth-Application-Id: Identifies the Diameter application in use. Origin-Host: Specifies the host from which the request originated. CC-Request-Number: Indicates the sequence number of the credit-control request. CC-Request-Type: Specifies the type of request (e.g., INITIAL, UPDATE, TERMINATION). Event-Timestamp: Represents the time the event occurred. Origin-Realm: Indicates the realm of the originating host. AVP: Allows additional AVPs to be included, providing flexibility for extensibility. |
|||
|
CDR-Information |
1064 |
OctetString |
Ericsson |
|
Used to transmit Call Detail Record (CDR) data from the Service Delivery Platform (SDP) to the Charging Information Processing (CIP) or IP Client. This AVP contains service-specific CDR information and is included in the Credit-Control Answer (CIA) command. |
|||
|
Charging-Context-Id |
1065 |
UTF8String |
Ericsson |
|
Uniquely identifies the service specification applicable to a specific request. This AVP ensures consistency during an ongoing charging interrogation session, as the Charging-Context-Id cannot be modified once the session has started. |
|||
|
Charging-State-Information |
1066 |
OctetString |
Ericsson |
|
Used to store SDP service and session state information within the CIP/IP Client. The content of this AVP is treated as opaque to the CIP/IP Client, meaning it must not be modified. The AVP is received in a Charging Interrogation Answer (CIA) and returned unaltered to the SDP in a Charging Interrogation Request (CIR). This AVP is not forwarded to external DCC Clients and may appear at both the command level and within an MSCC (Multiple Service Credit Control). |
|||
|
CIP-IP-Version |
1083 |
UTF8String |
Ericsson |
|
Specifies the version of the CIP-IP protocol in use. If this AVP is omitted, it defaults to the protocol's first version, "R1A". The receiver of this AVP must validate that the version provided is supported. If the receiver is a CIP-IP server (such as the SDP), the same version must be used in its response. |
|||
|
Multiple-Services-Credit-Control |
456 |
Grouped |
Ericsson |
|
Contains AVPs for the independent credit-control of multiple services within a charging session. It plays a critical role in identifying specific service sessions and associating them with service identifiers or rating groups. The AVP also manages requested, granted, and used service units, along with various other charging-related data. The AVP structure is defined as follows: Service-Session-Id: Identifies a specific service session within an ongoing charging interrogation session. Granted-Service-Unit: Contains the granted service unit details. Requested-Service-Unit: Contains the amount of requested service units or monetary value. Used-Service-Unit: Contains the list of used service units for the service. Service-Identifier: Associates granted units with a specific service. Rating-Group: Associates granted units with a specific rating group. Validity-Time: Specifies the validity time of the granted quota. Result-Code: Indicates the result of the credit-control operation. Result-Code-Extension: Provides an extension to the standard result code. Cost-Information: Contains the cost information of the service. Final-Unit-Indication: Indicates the actions to be taken when the final unit is consumed. Charging-State-Information: Stores session state information. CDR-Information: Contains CDR-related information. Service-Setup-Result: Specifies the result of the service setup. Service-Setup-Result-Requested: Indicates whether the service setup result is requested. Subscriber-Information: Contains subscriber-related information. |
|||
|
Service-Session-Id |
1068 |
UTF8String |
Ericsson |
|
Local identifier that uniquely identifies a specific service session within an ongoing charging interrogation session. It is always included in the Multiple-Services-Credit-Control (MSCC) AVP for session-based charging. The Service-Session-Id is unique within the scope of a charging interrogation session identified by a Session-Id. The lifetime of a Service-Session-Id spans from the start of a service until the service is terminated. If the same service is utilized again within the same charging interrogation session, a new Service-Session-Id is issued. Not applicable for One-Time Events. |
|||
|
Service-Setup-Result |
1135 |
Unsigned32 |
Ericsson |
|
Indicates the outcome of the service setup for session-based services. It provides a result code that specifies whether the service setup was successful or non-successful and includes details about the reason for the result. Values: 0 Successful - Released by service 1 Successful - Disconnected by calling party 2 Successful - Disconnected by called party 3 Successful - Ongoing (toll-free) 4 Non-Successful - Called party route select failure 5 Non-Successful - Called party busy 6 Non-Successful - Called party not reachable 7 Non-Successful - Called party no answer 8 Non-Successful - Calling party abandoned the call 14 Non-Successful - Other reason 15 Call Forwarding invoked - Charging cancelled |
|||
|
Service-Setup-Result-Requested |
1136 |
Enumerated |
Ericsson |
|
Specifies whether the result of the service setup should be reported for all services, including those not under credit control or those with failed setups. This AVP is included in Diameter messages when explicit reporting is required. Values: 0: RESULT_NOT_NEEDED 1: RESULT_REQUESTED |
|||
|
Subscriber-Information |
1189 |
Grouped |
Ericsson |
|
Serves as a container to carry internal subscriber or account-related information derived from the Service Delivery Platform (SDP). It is a grouped AVP that can hold multiple AVPs to encapsulate detailed subscriber data. This AVP is primarily used for handling account-level details within Diameter transactions involving the Charging Interrogation Protocol (CIP). The Subscriber-Information AVP may include, but is not limited to, the following AVPs: Subscriber ID: To uniquely identify the subscriber. Account Balance: For prepaid or postpaid billing. Service Subscriptions: To detail active service plans. Usage Limits: To indicate usage quotas or restrictions. Billing Preferences: To store billing-related settings. The exact AVPs depend on the specific application and system implementation. |
|||
Start innovating with Mobius
What's next? Let's talk!