Continuous Application Availability for Cellular Network

  • Copy link to clipboard
  • Email link
  • Print

Situation

A European cellular provider offers short message services (SMS) and unified message services (UMS) to deliver short text messages to cell phone customers, and to notify them of their voicemail or email messages.

The provider is servicing a large and growing population of cell phone customers. The provider has an active/passive backup solution, where all traffic for a given subscriber is routed to only one HPE NonStop Server at a time.

Problem

  1. The provider needed to improve cell phone services and provisioning to be more efficiently load-balanced and continuously available to avoid data collisions when running in an active/active business continuity architecture.
  2. In the old active/passive architecture, cell towers would drop the call as customers traveled from region to region. In other words, the application could not span across multiple cell towers.
  3. Improvements were required in network routing capabilities and system scale-out, as well as redundancy to survive any catastrophic system, datacenter, or regional disaster.
  4. The application needed to be distributed between two nodes—one in Milan, and one in Rome—in an active/active configuration.

Solution

Resolving Data Collisions with Relative Replication

Collision identification and resolution via relative replication are illustrated in Figure 2 (use the scroll bar to advance the figure). If the \Rome node experiences heavy traffic, update requests can be routed to the \Milan node to balance processing. In this specific example, a cellular customer is connected to the \Rome node, and a cell phone operator is connected to the \Milan node, but if a failure of one datacenter occurs, the cellular customer or cell phone operator’s requests can be routed to and fulfilled by the application on the other node.

In this example, assume Account #123 starts off with a balance of 50 minutes on it on each system, and that an operator debits 30 minutes from the account. At the same time, that cellular customer purchases 20 minutes of credit. If the new absolute values were replicated (i.e.: 20 minutes and 70 minutes, respectively), a data collision would occur and the amount in the customer’s account would be incorrect on both systems. Instead, by replicating only the amount by which the account value was changed, and applying the “deltas” (or change data): “Debit: -30” and “Credit: +20,” the value in the account remains correct and synchronized on both systems.

Additional Data Collision Note: Text and Alphanumeric Data (type) Collisions

When the values contained in text or alphanumeric fields or columns collide, generally one value or the other is used (with absolute replication). Typically, each change is time-stamped by the application and in this example, the provider architected for the most recent change to “win” the collision (the older text file change is written to a temporary reject log). As a fail-safe, text file collisions that are not automatically resolved are logged for manual resolution by an operator.

Outcomes

HPE Shadowbase Products of Interest


Contact us or your HPE Shadowbase representative, and learn how Shadowbase software will benefit you.

Further Reading

Related Case Study: Cellular Provider Achieves Continuous Availability for Prepaid Calls

Related White Papers:

Related Solution Briefs: