OMA AVPs
OMA Charging Data Interface (application id: -)
The OMA Charging Data Interface supports two distinct charging models—an Event-based Charging Model and a Session-based Charging Model—designed to facilitate the exchange of charging information between the Charging Enabler User and the Charging Enabler. The specific flows for charging information are defined in the Technical Specifications for Offline Charging / Online Charging [OMA-TS-Charging_3GPP_3GPP2-V1].
Purpose of the OMA Charging Data Interface
- Event-based Charging: In this model, charging is triggered by individual, discrete events (e.g., a specific service usage occurrence). Each event generates a Charging Request that is processed separately, ensuring that one-time or sporadic usage events are accurately billed.
- Session-based Charging: Here, charging occurs continuously over the duration of a session. As long as the session is active, charging data is accumulated and reported, reflecting the ongoing consumption of services. This model is particularly useful for applications where usage is measured over time.
Message Types:
The messages exchanged between the Charging Enabler User and the Charging Enabler are categorized into two primary types:
- Charging Requests: These messages initiate charging actions—whether triggered by discrete events or ongoing sessions—by conveying the necessary charging details.
- Charging Responses: These messages acknowledge the receipt of charging requests and provide confirmation or processing results.
Category: Each data element is marked as either mandatory or optional, ensuring that essential charging information is always included while allowing flexibility for additional details.
Level: The hierarchy level indicates the structure of the data elements. For example, a top-level element “A” (level n) may encapsulate subordinate elements “B” and “C” (level n+1), signifying that element A is composed of elements B and C.
Operational Workflow
Charging Initiation:
- When an event occurs or a session begins, a Charging Request message is generated by the Charging Enabler User. This message includes all necessary charging data, structured according to the defined data element hierarchy.
Processing and Acknowledgement:
- The Charging Enabler receives and processes the Charging Request. Depending on the charging model in effect, the system either immediately processes the discrete charging event (event-based) or continuously monitors the ongoing session (session-based).
- Following processing, a Charging Response message is sent back to confirm the receipt and handling of the charging information.
Billing and Accounting:
- The exchange of Charging Requests and Responses underpins accurate billing and accounting. The structured data and message flows enable effective resource management and provide a reliable audit trail for both offline and online charging scenarios.
Underlying Protocol Specifications
For complete technical details and further specifications, please refer to [OMA-TS-Charging_3GPP_3GPP2-V1], [OMA-DDS-Charging_Data-V1_0-20110201-A].
package com.mobius.software.telco.protocols.diameter.primitives.oma
|
Name |
AVP Code |
Data Type |
Vendor |
|
Application-Server-Id |
836 |
UTF8String |
3GPP |
|
Used to identify the application server responsible for providing a specific service and/or generating charging information within the Diameter protocol. |
|||
|
Application-Service-Type |
837 |
Enumerated |
3GPP |
|
Used to differentiate roles or functions performed by a node within service events. Enumerated Values 100 SENDING: Node acts as the sender in a service event. 101 RECEIVING: Node acts as the receiver in a service event. 102 RETRIEVAL: Node is responsible for retrieving data or content. 103 INVITING: Node sends an invitation to join a service session. 104 LEAVING: Node is leaving an ongoing service session. 105 JOINING: Node is joining an ongoing service session. |
|||
|
Application-Session-Id |
838 |
Unsigned32 |
3GPP |
|
Used to identify the application-level session to which the charging information relates. It is distinct from the Session-Id AVP defined in the Diameter Base Protocol [RFC 6733], which identifies the Diameter session between network entities. Instead, this AVP focuses specifically on the application-level session associated with charging events. |
|||
|
Content-ID |
845 |
UTF8String |
3GPP |
|
Serves as a unique identifier assigned by the Content Provider within the DCD (Dynamic Content Delivery) Service Provider’s domain. This AVP is particularly useful in content-based services, including streaming, downloads, on-demand media, and premium content delivery, where the identification and tracking of specific content items are required for billing, content management, and access control. |
|||
|
Content-Provider-ID |
846 |
UTF8String |
3GPP |
|
Serves as a globally unique identifier for a Content Provider within the DCD (Dynamic Content Delivery) Server Domain. This AVP is essential for authentication, authorization, and accounting purposes, enabling content providers to be uniquely identified across the network. It plays a critical role in billing, service access control, and content usage tracking. |
|||
|
DCD-Information |
2115 |
Grouped |
3GPP |
|
Designed to encapsulate service information elements used in Dynamic Content Delivery (DCD) services. It is typically used to identify content and its provider within the Diameter protocol for charging and service authorization purposes. The AVP structure is defined as follows: Content-ID (UTF8String, 846): Identifies the specific content in the request. Content-Provider-ID (UTF8String, 847): Identifies the content provider globally within the DCD domain. |
|||
|
Delivery-Status |
848 |
UTF8String |
3GPP |
|
Used to convey status information regarding the success or failure of service delivery within a Diameter-based network. It is particularly useful for tracking and reporting delivery outcomes in scenarios such as content distribution, messaging services, and charging events. |
|||
|
IM-Information |
2110 |
Grouped |
3GPP |
|
Used in Diameter-based charging applications to provide detailed statistics and usage metrics for Instant Messaging (IM) services. It facilitates monitoring, billing, and reporting of IM activities by grouping multiple related AVPs into a structured format. The AVP structure is defined as follows: Total-Number-Of-Messages-Sent (Unsigned32): Total messages sent during the IM session, including exploded (group messages) and direct. Total-Number-Of-Messages-Exploded (Unsigned32): Number of exploded messages, e.g., broadcast or group messages. Number-Of-Messages-Successfully-Sent (Unsigned32): Count of successfully delivered messages. Number-Of-Messages-Successfully-Exploded (Unsigned32): Count of successfully delivered exploded messages in group sessions. |
|||
|
Number-Of-Messages-Successfully-Exploded |
2111 |
Unsigned32 |
3GPP |
|
Used to specify the total number of messages that were successfully distributed (or exploded) to multiple recipients, particularly in broadcast or group messaging scenarios. |
|||
|
Number-Of-Messages-Successfully-Sent |
2112 |
Unsigned32 |
3GPP |
|
Specifies the number of individual messages successfully delivered to at least one recipient by the user. It is primarily used for billing, reporting, and service quality monitoring in messaging services. |
|||
|
Service-Generic-Information |
1256 |
Grouped |
3GPP |
|
Designed to transmit additional service-specific information that is common across different services and enablers. This AVP encapsulates multiple sub-AVPs to provide details about the application server, service type, session information, and delivery status. The AVP structure is defined as follows: Application-Server-ID (2100, UTF8String): Identifies the application server providing the service. Application-Service-Type (2101, Enumerated): Differentiates roles or actions (e.g., SENDING, RECEIVING) within a service. Application-Session-ID (2102, Unsigned32): Tracks the application-level session associated with the charging data. Delivery-Status (2103, UTF8String): Provides information about the delivery success status of the service. |
|||
|
Total-Number-Of-Messages-Exploded |
2062 |
Unsigned32 |
3GPP |
|
Used to indicate the total number of messages that have been distributed to recipients. It is particularly useful in scenarios involving group messaging or broadcast messages where a single message is sent to multiple recipients. |
|||
|
Total-Number-Of-Messages-Sent |
2063 |
Unsigned32 |
3GPP |
|
Records the total number of individual messages sent by a user or application. It does not guarantee delivery to recipients but reflects the total sent attempts. |
|||
Start innovating with Mobius
What's next? Let's talk!