purebill.com

Stephen Jones writing on billing and application migration

subscribe to purebill link
. Home . About . Archive . Links . Billing . Reference . Subscribe . Search . .
. The Billing Notes Index . Collection / Mediation .

Note 31: Network Collection

Posted: 04 May 2007

A large biller (especially in the telecommunications industry) may operate multiple networks. Even billers that have operated historically with only one network (e.g. electricity, mobile phones) now find that they need to collect usage details from new or additional networks (e.g. gas, data/content). Billers may also collect transactions received from systems and networks outside the biller's company boundary.

Collection must address complications such as:

  • Geographic spread: Broadly distributed networks complicate the collection process by increasing the number of locations from which information must be read. Network transactions can be read manually by a physical visit, or electronically by remote polling. Prior notes outlined networks with different collection complexities. Tollways collect transactions details from a (relatively) small number of measurement locations. Vehicles move past those locations to register their network use. Telephone networks consist of hundreds of exchanges, but with phone lines terminating in the central exchange building, the customer usage of hundreds to thousands of phone lines can be measured from one location. In distinct contrast, a utility company must visit each property and physically examine each gas, water or electricity meter to collect the customers' usage measurements (though this approach is being replaced by the move to remote meter readings.)
  • Vendor diversity: Networks of one type (e.g. fixed line phones) can operate using equipment sourced from multiple vendors. A biller may operate a network with equipment diversity to avoid a monoculture environment (e.g. to support competitive tendering, to reduce the impact of a vendor's equipment defect), due to a transition period between vendors, or through purchasing equipment over time (e.g. the same vendor but different equipment versions). A vendor's equipment may also collect transactions across different network types (e.g. ISP data, fixed voice, mobile voice). The specific commands required to operate one vendor's systems are likely to be unique to its hardware, and change through time as its software evolves.
  • Equipment versioning: Network equipment will be modified through time by vendors' software releases. These releases are likely to be performed in stages, especially on large and complex networks, to reduce the risk to the biller's business. As a result, equipment commands from the same vendor may have modified commands on new software versions causing subtle, but important, changes in the network's operations.
  • Network type: Collection processing for different networks will vary based on what is being measured. The information required for utilities (gas, electricity, water), phone networks (mobile, fixed), and tollways will measures different parameters. For example, electricity networks are interested in the peak electrical demand and the split between peak and off-peak use. A phone network is interested in the call destination and duration. Sub-categories within one network type also present collection challenges. e.g. GSM and 3G mobile phone networks
  • Customisations: Billers customise their network implementations to address problems (real or perceived), or provide biller-specific competitive differentiation. These changes can generate additional transaction types, modify the interfaces for transaction collection, or vary the format and processing of otherwise standard protocols. Network customisations may have been performed to address location specific idiosyncrasies, or modify legacy network applications to avoid their replacement costs.

Manual network measurements (e.g. utilities) may be collected offline, transcribed and passed to collection / mediation in files, or passed directly to billing (rating) for processing. Alternatively, the meter reading may be collected using an electronic handset that makes it immediately available for downstream processing.

Collection will operate most successfully for the biller when it can collect all necessary network information whilst transparently addressing the differences in the network. The mediation function can then take the information collected from the different sources in different formats and standardise it for billing and other downstream systems.

Network Interfaces

The network interface with collection can vary depending on measures such as:

  • Speed / Latency: Relevant measures include: the speed with which the network can access the billing functions for prepaid processing, and the elapsed time between a transaction's completion and its receipt by billing. The network's infrastructure configuration can influence this measure since regular network processing must continue whilst transaction collection is performed.
  • Volume: The number of transactions that will be collected from the network will affect the engineering of the interface. Transaction workloads measured in millions per hour will have different network interface needs to workloads measured in thousands per day.
  • Availability: High volume systems require a higher availability to provide consumers with consistent service. The network and collection connection must also have high availability. A connectivity failure can compromise the network's ability to store the volume of transactions generated until the collection function is available again. If the network is overwhelmed, it may discard excess transactions, or stop processing until space can be made available. Either case causes revenue loss.
  • Control: Who controls the interface? Does the network push transactions towards a passively waiting collection function? Or does collection actively poll the network to pull transactions downstream?
  • Interface Method: The network can pass transactions individually, or batched in files.

The collection process must address these differences and isolate them from the rest of the billing process. Downstream billing processes must receive transaction records without worrying about how they were obtained. By doing this, the integrity of the billing process is preserved, even when new network equipment is installed.

Examples of different collection approaches include:

  • Manual reading: Biller staff visiting individual properties to read each utility meter
  • Remote polling: Electronic polling from a biller's van driven by a property, remote polling of individual meters using a power line or radio connection
  • Static polling: Tollways with fixed toll locations under which vehicles travel.
  • Database: Transaction details extracted from a persistent database or file. e.g. government rate / tax rates calculated based on information extracted from an administrative 'property ownership' repository.
  • Third-party sources: Batched files in defined formats from sources external to the biller's company. e.g. international roaming charges for mobile phones, tollway charges for customer 'roaming' on external roadways. These external files are more likely to be passively received rather than actively polled.

Tags: , ,

[ Share with others ]

Post this page to a social bookmarking site:

delicious logo delicious diggit logo Digg it furl logo Furl google logo Google
reddit logo reddit stumbleupon logo StumbleUpon technorati logo Technorati yahoo myweb logo Yahoo MyWeb

 

Links to other Notes

Previous - Note 30: Transaction Collection / Mediation

Next - Note 32: Collection: Operational considerations

Recent Updates

Sign up to receive a brief text email when new purebill postings are published.

JUMP TO TOP go to top of page
.
Comments welcome: stephenjones(at)purebill.com Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap .