• Type your task here, using "@" to assign to a user and "//" to select a due date

User Story

Typically MVNO operating on LTE network requires to provide several alternative connections to it's online charging server (OCS) in order to gain high availability of OCS. I.e. whenever a connection to OCS fails SAE-GW tries the next available address of OCS.

PortaBilling has an intermediate component called Diameter server (diaconv) which acts as a front-end of OCS. Such architecture allows to employ VIPA approach of Diameter server for FT/HA (fault tolerance/high availability) capabilities for OCS. VIPA effectively addresses failures on MVNO side. However there still might be various situations that can't be solely addressed by using Diameter server VIPA approach. For example total data center blackout or connectivity issues between infrastructure provider and MVNO to name a few. Such issues can be handled by rolling out additional OCS instances in remote collocation (or site in terms of PortaSwitch) so that remote site gets it's own VIPA which in turn is provisioned to SAE-GW and is used as a failover address whenever a connection to primary OCS fails.

An obvious pay-off of site-redundacy solution is an expensive (in terms of system resources) billing data merge process. In case of network failures between SAE-GW and primary OCS and normal interconnection between MVNO's sites it is required to proxy all Diameter requests from secondary OCS to primary OCS in order to avoid processing on secondary site which in turn may lead to system overload caused by billing data merge process.

Use Cases

Use case #1: Process all requests by primary OCS as long as it is up and running on systems with enabled site-redundancy

Goal. Handle Diameter requests by secondary online charging server only in case when primary online charging server is unavailable in order to avoid system overload caused by an expensive merge of billing data from delta storage into primary billing database.

 

Actors:

  • OCS1 - primary online charging server
  • OCS2 - secondary online charging server
  • SAE-GW - infrastructure provider's gateway:

Preconditions:

  • PortaSwitch system was installed and site redundancy enabled;
  • Online charging server OCS1 is configured on primary site "Main" (located in Amsterdam, Netherlands) with the following parameters:
  • Online charging server OCS2 is configured on secondary site "Dublin" (Dublin, Ireland) with the following parameters
  • gateway SAE-GW has 193.10.0.1 and 207.10.0.1 addresses are provisioned and is configured to send Diameter requests to 193.10.0.1 primarily and to 207.10.0.1 otherwise.

Main flow

  1. Online charging servers OCS1 and OCS2 are up and running and there is excellent connectivity between gateway SAE-GW and OCS1 and OCS2 [AF1, EF1]
  2. SAE-GW sends Diameter request to OCS1 (193.10.0.1) according to the list of provisioned Diameter server addresses
  3. OCS1 receives Diameter request, processes it and responds back to SAE-GW
  4. SAE-GW receives Diameter response from OCS1 with realm=AMS and origin-host=ams.itsp.com

Alternative flows

AF1: Primary OCS is up and running but not unavailable from SAE-GW

  1. Online charging server OCS1 is up and running however is not reachable from gateway SAE-GW due to network connectivity issues
  2. Gateway SAE-GW attempts repeatedly to send Diameter request to OCS1 (193.10.0.1), all attempts fail
  3. SAE-GW tries the next available address and sends Diameter request to OCS2 (207.10.0.1)
  4. OCS2 receives Diameter request from SAE-GW. Since OCS2  is aware that OCS1 is up and running it doesn't process request on it's own but proxies it to OCS1.
  5. OCS1 receives Diameter request from OCS2
  6. OCS1 processes request normally, saves/updates data in the primary billing database, prepares response and sends it to OCS2
  7. OCS2 receives Diameter response from OCS1 and relays it to gateway SAE-GW.
  8. SAE-GW receives Diameter response from OCS2 with realm=DUB and origin-host=dub.itsp.com

Exception flows

EF1: Primary OCS is unavailable from secondary site

  1. Primary online charging server OCS1 goes offline due to power outage on primary site
  2. Secondary site detects that primary site is offline and switches to standalone mode
  3. Gateway SAE-GW attempts repeatedly to send Diameter request to OCS1 (193.10.0.1), all attempts fail
  4. SAE-GW tries the next available address and sends Diameter request to secondary online charging server OCS2 (207.10.0.1)
  5. OCS2 receives Diameter request from SAE-GW.
  6. Since OCS2  is aware that OCS1 is not available it processes request on it's own, saves/updates data in the interim billing delta database, prepares a response and sends it to SAE-GW
  7. SAE-GW receives Diameter response from OCS2 with realm=DUB and origin-host=dub.itsp.com
  8. Once primary site appears online again secondary site switches to normal mode and billing data from interim delta storage is merged into the primary database

 

Other requirements / constraints