Overview
On its own, each Roaming Component performs its work in the clearest and most efficient manner
possible. However, the components were deliberately made to be easy to interwork with. This
way the functionality offered by them can be blended together into far more functionality
than one usually expects from components. Wired together with a database and some orchestrating
scripts, one can really build a "mini-clearing house" just by using our components.
Build your infrastructure with the components you need
A working scenario
Let's assume that an operator called GR-XYZ has an existing rating/billing system that can create
TAP3 files up to release TAP3.9. The system can perform this only for GSM calls - the GPRS calls
are handled by another system which generates ASCII output containing the roamers' data.
In fact, the largest body of roamers comes from a neighbouring country's provider, IT-XYZ and
IT-XYZ expects TAP3.10 files. Currently, GR-XYZ sends its TAP3.9 and GPRS ASCII files to a clearing
house and pays an annual fee for the work required to send the data as TAP3.10 to IT-XYZ.
Instead of paying fees to a clearing house, the operator could use Roaming Components to
handle all roaming work on its own:
- The TAPx2TAPy component could first convert TAP3.9 files made by the legacy system to TAP3.10
- The ASCII2TAP component (with an associated module for the provider's ASCII format) can
generate TAP3.10 files from the GPRS calls
- The TAPMerger component could merge the two files and send all roamers' data in unison as
a TAP3.10 file to IT-XYZ.
- The TAPValidator component can optionally be used to verify that all work made by the
previous modules didn't cause any violations to TD57 validation rules.
The total cost of mandatory components for the versions involved (TAPx2TAPy, ASCII2TAP and
TAPMerger) can be - and in most cases indeed is - less than the total cost of annual
conversion fees.
Putting components together
Depending on what the operator wants to, there can be a database involved (for monitoring and
storing results) or not. In any case, some scripting will need to be in place to:
- Monitor incoming directories for TAP3.9 files with GSM roaming data and GPRS roaming data
- Invoke the components with the appropriate command line arguments to process the files
- Place the results in an output directory (for some daemon to collect and send to ITABC)
- Optionally, make a log in a database about the process workflow
- Raise alerts if something went amiss
We suggest scripting (Perl, Python) because its convenient and speedy enough to use for
these purposes; if no scripting is desired, any language can be used to do this (C, C++, etc).
A Python script to monitor a directory for new arrivals and act on them can be downloaded
from here.
|