Skip to main content

Online Charging (Ro Interface)

📖 Back to Main Documentation

Configuration and operational details for the Ro (Online Charging) Diameter interface.

Core Documentation​

Call Processing Integration​

  • 👥 Sh Interface - Subscriber data interface (also uses Diameter)
  • 📡 SS7 MAP - Alternative for subscriber routing

Monitoring​

Ro Configuration​

If Ro (Online Charging) is to be used it must be enabled in the config.

You will of course need a connected Diameter peer that can handle Ro or a DRA that has one.

periodic_ccr_time_seconds sets how often during a session a Credit-Control-Request type 2 (Update) is sent. This will probably need to be adjusted based on the needs of the OCS.

If the Credit-Control-Request type 1 (Intial) returns the max usage seconds for all the balance, we can set a scheduled hangup for that time. This is controlled by the schedule_hangup_auth flag which if enabled will get the seconds allocated in the CCR-I and set the call to hangup at that time.

skipped_regex (optional) allows you to specify regular expression patterns to match destination numbers that should bypass online charging. Calls to destinations matching these patterns will be authorized without contacting the OCS. This is useful for internal services, voicemail, emergency numbers, or other destinations that should not be charged. If omitted or set to an empty list, all calls will go through online charging when enabled. Patterns use Elixir regex syntax (e.g., "^2222" matches numbers starting with 2222, "^344[4-6]" matches numbers starting with 3444, 3445, or 3446).

config :tas,
  ...
  online_charging: %{
    enabled: true,
    periodic_ccr_time_seconds: 10,
    schedule_hangup_auth: true,
    skipped_regex: ["^2222", "^2223", "^8999", "^344[4-6]"]  # Optional
  },

Online Charging Operational Behavior​

How Periodic Charging Works:

When a mobile-originated (MO) call is answered:

  1. The system sends an initial CCR-I (Initial Credit Control Request) to authorize the call
  2. If credit is available, the OCS returns allocated time (e.g., 120 seconds)
  3. A background process starts that runs every periodic_ccr_time_seconds to reauthorize the call
  4. This process sends CCR-U (Update) requests to check if the subscriber still has credit
  5. Each successful CCR-U extends the call and grants additional time
  6. When the call ends, a CCR-T (Terminate) is sent for final accounting

Request Type Values:

  • 1 = Initial (CCR-I) - sent when call is first authorized
  • 2 = Update (CCR-U) - sent on answer and periodically during the call
  • 3 = Terminate (CCR-T) - sent when call ends
  • 4 = Event - used for SMS or one-time event charging

What Happens When Credit Runs Out:

If a periodic CCR-U returns zero seconds or an error:

  • The periodic charging process stops automatically
  • If schedule_hangup_auth is enabled, the call will terminate when allocated time expires
  • The subscriber's call ends and they receive appropriate notification

Tuning periodic_ccr_time_seconds:

Choose the interval based on your operational needs:

  • Lower values (5-10 seconds): More responsive to credit exhaustion, catches out-of-credit situations quickly, but creates higher load on OCS
  • Higher values (30-60 seconds): Lower OCS load and network traffic, but subscribers may consume slightly more credit than available between checks
  • Recommended: Start with 10-30 seconds based on your minimum credit increment and OCS capacity

Monitoring Periodic Charging:

Watch these metrics to ensure periodic charging is working correctly:

  • online_charging_events_total{event_type="reauth"} - tracks periodic CCR-U requests
  • online_charging_events_total{event_type="reauth",result="success"} - successful reauthorizations
  • online_charging_events_total{event_type="reauth",result="nocredit"} - subscribers running out of credit mid-call
  • High reauth failure rates indicate OCS connectivity or performance issues

Troubleshooting Periodic Charging:

If calls are not being reauthorized properly:

  1. Check logs for "Sending periodic CCR-U for <call_id>" messages - confirms the background process is running
  2. Look for "Periodic CCR failed - Stopping job" warnings - indicates credit exhaustion or OCS errors
  3. Verify ocs_authorization_duration_milliseconds metric shows reasonable response times
  4. Confirm OCS is returning valid CCA-U responses with granted time units
  5. Check that periodic_ccr_time_seconds is not set too aggressively for your OCS capacity