Transferred Account Procedure is the mechanism by which wireless operators exchange roaming billing information. The GSM Association in 1995 released the very first TAP specification, i.e., TAP version 1. From then onward, the specifications have continuously evolved to support new services and associated operational aspects. For example, in the earlier versions, the usage was recorded in terms of call detailed records (CDRs). This was changed to call event detail (CED) to reflect the nature of services in current and future generations of networks. TAP2 and TAP2+ were introduced later; they allowed the operators to bill for new services and provide the additional information required by satellite and U.S. operators. TAP3 is the latest version released by the GSM Association. It includes all the features supported by earlier versions of TAP. In addition, it supports billing for new-generation services, including mobile multimedia and prepaid roaming. It also supports interoper-ator tariff (IOT) charging principles and key information for marketing and customer service functions.
TAP3 and earlier versions
The latest version, TAP3, is designed to cater to the needs of the next-generation services. It uses an industry-standard coding scheme, i.e., ASN.1. This enables use of commercially available tools rather than proprietary toolkits. Many of the earlier version constraints, e.g., file size limitation, have been also removed.
TAP3 can handle all the features and services supported by earlier versions of TAP. In addition, the new supported services are:
■ High-speed circuit-switched (HSCSD) and packet-switched (GPRS) data services
■ Prepaid roaming using CAMEL
■ USSD charging
■ Mobile directory number to support mobile number portability for interstandard roaming
■ Support of private numbering plans (SPNP)
■ Enhanced full rate (EFR) for enhanced voice quality
■ Fraud information gathering system (FIGS), including fraud monitoring indicator and third-party number
■ Support for UMTS QoS
The additional interoperator tariff features that TAP3 is able to handle are:
■ HPLMN repricing—enables HPLMN to reprice each call according to its own tariff plan
■ Call-level discounts
TAP3 also allows for the specific requirements of satellite networks and of large countries where no single operator covers the entire geographic area. This includes support for the following additional parameters.
■ Additional charging parameters, e.g., separation of airtime and toll charges
■ Additional time zones
Unlike earlier versions, TAP3 also contains valuable information about roamer and also services used by a roamer. Wireless service providers can use this information for marketing (e.g., targeted campaigns) and customer care. This information could also be used to build roamer profiles and ad hoc studies as and when required. This enables various stakeholders within a roaming organization to make informed business decisions.
TAP-in and TAP-out processes
In the GSM world, the usage records are generated in mobile switching centers (MSCs), short message service centers (SMSCs), and voice mail service centers (VMSCs). Several different types of records are generated, depending on the usage. For example, call detailed records (CDRs) for mobile-originated (MO) and mobile-terminating (MT) calls, transaction detailed records for MO-SMS, MT-SMS, and other nonvoice usage. In GPRS and 3G, usage records are generated at the SGSNs, GGSNs, MMSCs, and a host of other gateway elements. The usage records are generated for packet-switched data calls, MMS, and access of contents.
The TAP-out process enables an HPMN (the PLMN where TAP-out processing is performed) to send rated records for the calls made by inbound roamers (visitors from foreign networks) to their respective home networks (VPMNs).
As shown in Figure 11-2, the serving MSC in the visited network creates detailed records every time a roamer successfully accesses a service. These records are then transferred to the billing system for rating and pricing. The billing system segregates and group calls/records created for the roamers and converts those in the ASN.1 TAP file format. The MCC and MNC codes in IMSIs are used to validate and group the calls. The TAP files contain rated call information. The rating is done in accordance with the bilateral agreement between operators. These TAP files are then sent to roaming partners on a regular basis. This transfer takes place either directly or via a clearinghouse. The frequency of transfer is subject to the bilateral roaming agreement and generally decided up-front. In general, the TAP file exchange should take place as frequently as possible to enable monitoring of high usage and possible fraud.
Electronic data interchange (EDI) is the standard mechanism of TAP file transfer to ensure that charging records are made available to the HPLMN without delay. In case of EDI failure, magnetic tapes or some other suitable mechanism can be used as a fallback and are subject to a bilateral agreement. Magnetic tape technology is fast becoming obsolete.
The TAP-in process at the receiving network accepts the files generated by its partner networks. The TAP-in process involves parsing, validation, conversion of usage data into internal format, and prerating in accordance with the roaming tariff plan. The reject and return process is used in the cases where the validation of TAP files results in errors.
Reject and return process
A new procedure called reject and return was introduced recently as part of the TAP3 specification in order to handle errors in TAP files efficiently. Before the implementation of this process, an error concerning one single call in a TAP file resulted in rejection of the entire file. This was the cause of unnecessary delays in the billing and settlement process.
Figure 11-2 Transferred account procedure.
The reject and return process allows processing of validated CEDs to proceed and return of errored CEDs back to the concerned VPMN. An automated mechanism can be built to handle the fatal errors and missing files or data. Having fewer call event details at the end of the month in the reclaims process allows an early interoperator settlement.
Having the capability to reject individual call event details also benefits the retail billing process and early realization of dues from subscribers. Figure 11-3 describes a simplified view of TAP file transfer using the rejects and returns process.
At the HPLMN, this process enables the return of call event detail records containing severe errors to a concerned VPLMN, while correct CEDs can be processed as usual. The typical subprocesses at the HPLMN are:
■ TAP file validation
■ Missing file detection
■ Fatal error detection
■ Severe error detection
■ Creation of a RAP file
■ Transmission of RAP files to the concerned VPLMN
The VPLMN, if possible, corrects the files and/or call event details and resubmits them to the HPLMN. This process allows for the VPLMN to recoup roaming revenues from the HPLMN for resubmitted call event details/files. The typical subprocesses at the HPLMN are:
■ RAP file decoding
■ Submit missing file/files
■ Correct fatal errors
■ Correct severe errors
■ Create TAP files and resubmit to the HPLMN
Figure 11-3 Reject and return process simplified.
