m
Our Mission Statement
This is Photoshop's version of Loremer Ipsn gravida nibh vel velit auctoregorie sam alquet.Aenean sollicitudin, lorem quis bibendum auci elit consequat ipsutis sem nibh id elit.
Follow Us
Top
Case Study: Openet - VoltDB
7807
file-template-default,single,single-file,postid-7807,mkd-core-1.0,highrise-ver-1.0,,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-slide-from-bottom,mkd-dark-header,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,mkd-search-dropdown,mkd-side-menu-slide-from-right,wpb-js-composer js-comp-ver-5.4.4,vc_responsive
VoltDB / Case Study: Openet

Case Study: Openet

Case Study: Openet

Who is Openet?

Openet is a telecommunications service provider, providing solutions for large mobile communications companies including T-Mobile, Sprint, Bell, Vodophone & More.

What Problems Did They Have?

Openet handles call authorization and billing for mobile networks all over the world. Their existing database technology was too expensive to license and operate and was neither cloud nor virtualization friendly.

Their replacement had to operate at scale, with telco-grade high availability, and had to achieve the target latency profile. Each call must be authorized in tens of milliseconds or money is lost, so Openet has a laser focus on long tail predictable latency.

Why Did They Choose VoltDB?

VoltDB had all of the features they needed inlcuding:

  • Fully ACID, Multi-Statement Transactions
  • High Throughput
  • Operational Robustness
  • Low Long Tail Latency Profile
  • Low Operational Cost
  • Cloud and Virtualization Friendly

At the end of the day, VoltDB stood alone.

  • Traditional RDBMS offered more complex operations, much higher TCO, and struggled to meet latency goals at peak throughput.
  • NoSQL and other NewSQL systems couldn’t offer consistency at scale and didn’t meet long-tail latency goals.

What Does Their VoltDB Solution Look Like?

Openet has developed many applications on top of VoltDB. Let’s look specifically at call authorization.

When you dial a number on your mobile phone, there is a slight pause before the phone on the other end starts ringing. A number of things happen during that pause, but for mobile networks powered by Openet, a decision is being made using VoltDB whether to authorize or reject your call.

Openet uses the “One event, One procedure call” pattern and they make extensive use of analytics inside the transaction. Information about you and the phone number you are trying to call is sent to a stored procedure in VoltDB. A single procedure call is a single transaction, and this one will return “yes” or “no” and record that action. This procedure can be broken down into steps:

  1. Analytics and information gathering:
    VoltDB will perform queries to answer some questions.
    – Is your account in good standing?
    – Is the number you are trying to call blocked for some reason for your account?
    – Is your account prepaid or postpaid?
    – If prepaid, do you have enough balance to make this call?
    – Is your account or the account you are trying to call on a blacklist?
    – Is recent activity for either account suspicious?
  2. Decision making and recording:
    Based on data gathered during the analytics phase, the call will be permitted or not. Record in the database information about the start of the call.
  3. Returning the response:
    Return to the calling application whether the call was authorized.

Download the Case Study

VoltDB OpenNet Case Study