Going Realtime and Convergent at Tusmobil Using Billing and Revenue Management

Tusmobil, a new mobile operator, the third one in Slovenia, has decided to go fully real-time and
convergent by implementing Oracle’s Billing and Revenue Management Release 7.3 (Oracle BRM).
Breaking away from conventional designs, Tusmobil has accomplished this change by eliminating
the traditional prepaid/postpaid customer philosophy and technology barrier. The resulting advantages
are manifold and include increased customer experience, faster time to market, product and
offering agility, online customer credit control, reduced solution complexity, and cost
reduction. All these, achieved thanks to more integrated systems and the elimination of traditional IN
black boxed solutions, bring to the company multiple competitive advantages over the outdated
approaches more commonly used.

To implement this innovative service, we’ve used Open Source technologies such as Android SDK, Google Web Toolkit (AJAX, JavaScript,CSS, DHTML, GWT-RPC), Goole Protocol Buffers, JBoss, JBoss RESTEasy, Hibernate, PostgreeSQL, and Junit.

Click on the pictures below to explore some of the virtually infinite possibilities.

The use of the cloud provides a number of opportunities:

• It enables services to be used without an understanding of their infrastructure.
• Cloud computing works using economies of scale. It lowers the outlay expense for start up companies as they would no longer need to buy their own software or servers. Cost would be by on-demand pricing.
• Data and services are stored remotely but are accessible from anywhere.
• Maintenance and change management cloud computing applications are easier to maintain since they don’t have to be installed on each user’s computer. They are easier to support and to improve since the changes reach the clients instantly.
• Agility improves with users’ ability to rapidly and inexpensively reprovision technological infrastructure resources.
• Cost is reported to be greatly reduced and capital expenditure is converted to operational expenditure. This ostensibly lowers barriers to entry as infrastructure is typically provided by a third-party and does not need to be purchased for one-time or infrequent intensive computing tasks.
• Scalability via dynamic provisioning of resources on a fine-grained, self-service basis near real-time is provided, without users having to engineer for peak loads.

As with any other technology, companies/organizations must address a wide range of cloud computing risks:

• The use of cloud computung creates dependence on third party companies and that could possibly limit flexibility, control, and innovation. The biggest players could monopolise the market. Some argue that the use of supercomputers is a return to the time of mainframe computing that the personal computer (PC) was a reaction against.
• Security could be a big issue. Software-as-a-service (SAAS) vendors may store data in data-centers all over the world. Those data-centers may hold information from many different businesses, even competitors. The organization should determine if it is appropriate to store such types of information as client lists, pricing, intellectual property, etc. on external servers.
• There are risks related to having a critical software application developed and managed by an outside entity. If a vendor’s software application ceases to function, the organization may experience financial losses as well as damage to its image and reputation.
• There are also issues relating to policy and access. If data are stored abroad, whose Freedom of Information Policy ( FOI) should be adhered to? What happens if the remote server goes down? How will files and data then be accessed?
• Employee productivity will drop if internet connectivity is down for an extended period of time. Redundant high speed Internet lines may be needed to help counteract this possibility.

At Tridens we prefer using private cloud, which is used exclusively by your company/organization. With private cloud,  your company/organization takes control of security, lock-in, and reliability. A private platform-as-a-service (PaaS) is a development and deployment platform that typically includes middleware, database, and development tools. A private infrastructure-as-a-service (IaaS) delivers computer infrastructure that is based on virtualization, server, and storage.

For middleware, you can chose from the following products:

• Oracle Fusion
• RedHat JBoss
• IBM Websphere
• Tibco ActiveMatrix
• GlassFish

You can use the following databases:

• Oracle DB
• MySQL
• PostgreSQL
• H2
• IBM DB2
• Microsoft SQL Server

Virtualization products are listed below:

• Vmware
• Oracle VirtualBox
• Microsoft Virtual PC

We prefer to run applications on linux/unix based servers. To provide monitoring and managing of your cloud, we prefer employing Enterprise Service Manager (ESM). ESM is capable of monitoring and managing all mission-critical infrastructure components such as applications, services, operating systems, network protocols, systems metrics, and network infrastructure.

1. Compiles the total amount of balance impacts that have occurred in the past month. This can include usage fees and subscription fees.
2. Changes the status of all the bill items associated with the bill from pending to open so that they stop accumulating charges, and payments can be applied to them. In addition, a payment due date is added to the bill.
3. Automatically requests payments from a credit card processor or requests payments by sending invoices.
4. Automatically updates a customer’s account balance when a payment is recorded in the BRM database.

Picture 1: Oracle BRM billing process

So, how is all this done in practice?

Before running a billing on production, it is necessary that all the prerequisite steps be executed. The first step is to prepare a copy of the production environment – this can either be a preproduction or some testing environment. This step includes the installation of the latest production release onto this environment and the copying of the production database. Next, the environment configurations have to reflect those of production. Here are the main configurations, which should be set appropriately:

• cm configuration ($HOME/pin/sys/cm/pin.conf),

o Verify loglevel entry is set to 1

o Change the entry for agent_return parameter to 0

o Change the entry for simulate_agent parameter to 1

These two last changes are done so as not to involve any provisioning action during the bill-run.

• dm_oracle configuration ($HOME/pin/sys/dm_oracle/pin.conf),

o Set dm_bigsize parameter to 8388608 or higher

o Set dm_shmsize parameter to 33554432 or higher

o Set dm_n_fe to 8

o Set dm_max_per_fe to 16

o Set dm_n_be to 24

o Set dm_trans_be_max to 22

• pin_bill_accts configuration ($HOME/pin/apps/pin_billd/pin.conf),

o Verify loglevel. Change it to the appropriate value depending on what needs to be checked during the bill test, either 1 or 3.

o Change children parameter for pin_billd and pin_mta to 5

o Change per_batch parameter for pin_billd and pin_mta to 20000

o Change fetch_size parameter for pin_billd and pin_mta to 150000

• pin_inv_accts configuration ($HOME/pin/apps/pin_inv/pin.conf),

o Verify loglevel. Change it to the appropriate value depending on what needs to be checked during the bill test, either 1 or 3.

o Change children parameter for pin_billd and pin_mta to 5

o Change per_batch parameter for pin_billd and pin_mta to 2000

o Change fetch_size parameter for pin_billd and pin_mta to 15000

To get the best possible simulation of production, the billrun pin_virtual_time has to be set to the date when the real billrun on production will be executed. Once that’s done, the billrun can be started.

We run billing monthly with pin_bill_day script which creates about 100.000 bills per hour. The script creates bills for accounts where the billing date is any day before midnight of the day we run billing. So what does pin_billd_day script actually do? It runs the following billing utilities:

• pin_deferred_act: Executes deferred actions; for example if an account should become inactive, this utility performs the status change on the scheduled date.
• pin_bill_accts: Calculates the balance due for accounts and creates a bill for the balance due.
• pin_collect: Collects the balance due for accounts that use credit cards and directs debit payment methods.
• pin_refund: Finds accounts that have refund items and makes online refund transactions.
• pin_inv_accts: Creates an invoice for each account that is billed.
• pin_cycle_fees: Applies the cycle forward fee balance impact to the customer’s account and cancels products that have an expired pending cancellation date.

To verify the progress and performance of the pin_bill_day script, we run queries against the database to get information on how many bills are done, how many are yet to be done, if there are any bills with errors, etc.

After the billing part is over and all the bills are created, invoicing starts. After the invoices are created, they are exported to XML documents, which are then converted into PDF format.

Besides the queries mentioned earlier, there are also other queries that need to be executed once billing and invoicing has finished, in order to verify the accuracy of the data generated by this process. We execute batch of queries; here are some of them:

• Has billing failed?

select * from billinfo_t where billing_state = 4 and bill_info_id<>’Bill Unit(1)’;

–Expected results: No rows found

• Are there any unbilled accounts?

select poid_id0, first_name,last_name,a.status from account_t a, account_nameinfo_t an where

a.poid_id0=an.obj_id0 and

created_t<<bill_cycle_end_date> and

not exists (select b.account_obj_id0 from bill_t b

where end_t=<bill_cycle_end_date> and

b.account_obj_id0=a.poid_id0);

–Expected results: No rows found

• Are there any bills without a bill number?

select * from bill_t where end_t=<bill_cycle_end_date> and bill_no is null;

– Expected: No rows found

Any problems found are then investigated and fixed through the versioning control system, where fixes are later included in the next release version.

• Decide which business processes must be available on mobile devices
• Redefine needed business processes in such way that most tasks can be done in off-line mode
• Decide which functionalities should be available on mobile devices
• Design a GUI for mobile devices

To prepare business processes to work in a mobile environment, close cooperation between SOA experts/consultants and mobile device experts is needed. This is necessary in order to overcome all the limitations of both systems and to accomplish a successful integration. It is desirable that only needed functionalities be available on mobile devices and that the number of interactions to the main SOA system and the amount of data transferred be limited to a minimum. On the other hand, business process analysts should be very careful not to limit functionality too much; otherwise defined business processes would become useless.

The main objectives for mobile devices experts will be such tasks as deciding which mobile platforms should be supported, helping you redefine business processes, designing the GUI, etc. They should take into consideration the size of the mobile device display, the limited functionalities, as compared to computers, and, of course, the limitations associated with data transfer. In some remote locations, network signals could be very low, so data transfer would be very slow or impossible. Even when a network signal is strong, the data transfer speed on mobile devices can not be compared to that of a local area network. And this is the main reason why mobile applications should be designed for work in the off-line mode; only when data are needed to be transferred should the necessary connection to the SOA environment be established .

For the GUI ,two main approaches can be considered:

• Web Interface
• Custom application

For Web Interface, only appropriate web pages should be created. This is the simpler approach and less complex web pages are compatible with most browsers on mobile devices. So, while this method would work on a wide number of different mobile devices, functionality would be limited, rendering it acceptable for only very simple tasks.

For complex tasks, implementing the custom application in order to exploit the rich functionality of the Android platform and the very popular IPhone and IPad devices is recommended. This will bring to mobile devices the full functionality of your SOA environment with a very rich GUI. Using this approach, your employees will be far more efficient in the field.

With this relatively simple change in your SOA environment, and with custom applications for mobile devices, your employees would get real-time access to vital business information, even while they are in the field. In today’s highly competitive business environment, such an advantage can mean the difference between success and failure.

The introduction of rating differentiation for specific accounts can be configured using Promotions. Promotions in Oracle BRM provide a way to give customers special rates or discounts based on a specific attribute of a service or account, such as a telephone number. Promotions are called extended rating attributes (ERAs) in the Pricing Center and elsewhere in Oracle BRM. Adding a closed user group promotion is achieved by opening the Customer Center and selecting the Promotion tab. There, select Closed User Group from the account-level Promotion Type list, enter the phone number or account login ID in the Name column, enter the name of the closed user group in the Value column, and optionally select Valid From and Valid To dates. Note that while you can assign multiple closed user groups to an account, each number can be assigned to only one closed user group at any time.

For our customers, however, we have designed and implemented CUG functionality in a different way. In the first phase, the idea was to allow cheaper outgoing voice calls among accounts in the same hierarchy. For the hierarchy to be CUG-compliant, the parent has to have an account-level product called CUG1. Now, when a voice call is made between child accounts in this hierarchy, a pre-rating opcode checks whether or not both A subscriber and B subscriber belong to the same hierarchy. If they do, a flag is set for the rating engine to charge this event at a lower rate.

Picture 1: Calls between any two accounts in this hierarchy are discounted

The second phase introduces an extension to the original functionality by allowing subscribers to belong to the same CUG group without being in the same hierarchy. As long as A subscriber and B subscriber belong to the same CUG2 group (having a corresponding CUG2 product with the same description – group name) and do not belong to CUG1 hierarchy, the call is rated according to the CUG2 product rate. Note, CUG1 always has the higher priority, so if it exists for both A and B subscribers, only the CUG1 charge can be applied.

Picture 2: Calls between accounts having CUG 2 products with the same description are discounted (regardless of hierarchy membership)