4G LTE Key concepts(Why industry is going behind 4g services across the globe)

Key concepts of 4G LTE(Long term Evolution)!
Now Why industry is going behind 4g services across the globe?
LTE encompasses the pillars of next genaration networks,The Key concepts LTE architecture behind Long term evolutions are:-
>Broadband wireless
High throughthroughput, low latency mobile access based on OFDM/MIMO and efficiently deliveringunicast, multicast and broadcast media.
>Convergence technology
A single applications domain serving customers across multiple networks and multiple devices.
> Technology Intelligence at the services edge
Implementing policy enforcementand decisions at the network edge while in an access-agnostic but access-aware across the different technology framework.
> Technology shifted to all-IP
Simplifying and streamlining the network, improving scalability and flexibility of the deployment and enabling consistent access-aware policy for enforcement and billing.
> Embedded security
A multi-layer and multi-vendor approach to network security is critical to ensure that network security is endemic to the network and have to be focused on point solutions.
Read more...

Fraud Management System Part4(Different patterns in Fraud Detection)

Different Fraud Patterns-Sequence – eg
The system will detect a sequence of patterns as:
->In a 2 h time window or depends on the business scenario given by the customer ( Time window)
->The user failed 3 logins or depends on the business scenario given by the customer (Accumulation Pattern)
->Downloaded > 300M Bytes or depends on the business scenario given by the customer (Accumulation Pattern)
->Made an access to a blacklisted IP or depends on the business scenario given by the customer (Single Event Pattern)

Sequence Pattern:
Subscriber Checks
->Unknown Entity (e.g. Subscriber/Service)
− Generate an alarm, when a call is received for an unknown service or subscriber

Suspension checks
-Generate an alarm, when call data indicates a call type for which the customer is suspended or barred

Authorization Checks
− Generate an alarm, when call data indicates a call type for which the customer is not explicitly authorized
This logics also applies to the prepaid or postpaid mismatch
Entity Pattern Detection
• User-defined patterns matched against service or subscriber information fed from billing or other customer database:
− Customer Document is Blacklisted
− Dealer Code is 123.*
− Customer name is ~Bartow
New Subscription Checks
• Contact number analysis
• Inactive new subscriber
• Change of installation-defined fields soon after activation
− e.g., change of billing address for identity theft
• Immediate roaming
• Roaming calls not to home country/carrier
High-risk destinations
• Operators can specify high fraud destinations
− Country Code
− Area Code
• Calls to countries or area codes on the high-fraud lists will generate alarms
− “Severe” alarm or “Unusual” alarm
− unless calls to that country or area code are in the service’s profile
• Examples:
− Country Code = 234 Nigeria (Severe)
− Area Code = 305 Miami (Unusual)
Black list checking
• FMS provides unlimited types of Black Lists
• Examples are:
− Service # (subscriber ID)
− Access Point
− From # (A#)
− To # (B#)
− Originating IP address
− Terminating IP address
− Equipment # (wireless)
• Alarm generated when call matches any entry on a black list
− Example: B# = 9785551234
• Partial blacklists match is supported in patterns, with regular expression
Smart thresholds
• Time Intervals tracked
− Time-of day usage
− Daily basis
• Peak and off-peak days, calendar based
• Ability to define free or reduced rate periods (e.g., nights, weekends)
− Weekly basis
− Monthly basis
− Per Call basis
• Seven ways to track usage
− duration, charge, number of calls, data volumes
Read more...

Fraud Management System Part3(Fraud Detection Techniques..)

Fraud Detection Techniques:
• Velocity/Collision
• Stuffing / High Count
− IMSI - Country
− IMSI - CFDW Destination
− IMSI - IMEI
− Subscription document - IMSI
− IMEI - IMSI
• Patterns (Classic, Accumulation, Sequence)
• Unknown / Unauthorized Subscriber checks
• New Subscriber checks
• Thresholds
• Blacklists
Detection Techniques
• Cross Rate
• Credit Limit
• Split Packages
• SIM Gateway
• Prepaid
− Balance Monitor
− Odd recharges
Detection techniquesBreadth of Coverage
Types of Detection -- Technical checks
High Destination Counts
Event Pattern Detection
• Allows operator to look for specific situations
• Detect any call that matches operator-defined patterns
• Allows customer data conditions as well:
− Event is GSM CDR
− Event starts between 00:30 and 05:30, and
− Event duration > 60 minutes and,
− Event category is (International or Premium), and
− Entity activated less than 120 days ago, and
− Entity payment is cash
− Entity age is < 25
Pattern Detection (Event and Entity)
• Blacklisted fields declaration
− If dealer-Id is blacklisted then
• Regular expressions
− If dealer-id = 123.*.* then
• Approximate name matches
− If Family-Name ~ Argento then
• Applied on event fields or on entity information feed
Classic Pattern
New Pattern Model - Examples
• Accumulation Pattern in a time window:
− Pattern-1
• More than 3 recharges@5$
• within a 12 hour period
− Pattern-2
• Three calls duration > 60 min
• Days since activation < 30
• In a 6 hour period
Read more...

Fraud Management System Part2(FMS System Overview)

FMS System Overview:
Event Representation
• Extend current support beyond CDR-like events:
Support for any kind of
• 3G data event
• any revenue related events
New event types added dynamically
• Familiar CDR records become a specific event type
Each event separately represented in the database
• New event types will be defined by a:
− Event type
Set of user-defined associated fields
Set of base modules acting on it (e.g. threshold, pattern)
Optional/custom modules acting on those new events
Support for 3G
• 3G carriers implement services, which allow non-voice data to be transmitted across mobile and fixed line networks.
• FMS features include Event/Transaction data record formats, including fields as:
• Access Point Name (GPRS)
• Destination and Origin IP (IPv4 and IPv6)
• Level of Service
• Etc.
• All fields are useable in pattern matching
• Four user-defined volume tracking types to measure different data volumes

Example of Supported Events
Entity Hierarchy
• Implements a multi level hierarchy of billing entity:
e.g. Company à Account à Subscriber à Service
Service Providers
Internal Operators
Public Phone
etc.
• Better models the hierarchy present in a 3G carrier’s environment

• Addresses the need to perform different detections at each level

• Each level will have a separate threshold configuration and different patterns
Read more...

Different status of Telecom Billing Life cycle

Telecom Billing Life cycle Status:
Billing solution provides a service lifecycle model and the management of subscriptions (MSISDNs) within that life cycle
The following lifecycle states used in the solution and a MSISDN will always be in one of these states:
•Pre-Active – The subscription state where the MSISDN is provisioned through provisioning system but is not yet “Active”
•Active – The MSISDN state while the account balance is greater than the “active balance threshold” and neither the Active or Life Time timers have expired. Switch will allow subscribers to originate events (voice calls, send SMS-MO, MMS, receive SMS-MT etc) in this state (assuming sufficient balance etc to rate the event). A recharge will typically move the subscriber to this state from the Pre-Active, Insufficient Funds or Deactive states. The “active balance threshold” is normally set to zero.balance’ to make calls.
•Inactive – The subscription state when the account balance is less than or equal to zero (due to subscriber or customer care activity) but neither the Active nor Life time timers have expired. The subscriber can only originate calls to the IVR, or CSRs. For example the subscriber has not used all of their active time since the last recharge (e.g. still 20 days left) but they have zero balance.
•Deactive – The subscription state when the Active timer but not the Lifetime timer has expired. The subscriber can only originate calls to the IVR, or CSRs. For example, the subscriber has used all of their active time (e.g. more than 186 days). Once the subscriber performs a recharge they will move back to the Active state and the active time will start again.
•Expired – The subscription state when the Lifetime timer has expired. Subscribers will exist indefinitely in this state on the network switch until a request is received from the csr to erase the subscriber or Reactivate the account (which will change the state from “disconnected” to “Deactive”). For example, more than 372 days have passed since the subscriber’s last successful recharge.
Read more...

Why Convergent billing?

Why Convergent Billing?
Convergent billing is the combination of all service charges into a single invoice.That means creating a unified view of the customer and all services being provided to that customer from the customer care.convergent billing involves gathering data in various formats, originating from different systems, and mediating it into a common format.
Read more...

Fraud Management System Part1

Fraud Management System(FMS)
• A system which can
− Prevent, Detect, and Deter fraudulent activity
− Understand the sources and reasons for threats
− Build processes which can quickly identify and resolve fraud to reduce losses
• FMS uses the following analysis technologies:
− Rule Based
− Neural Networks/Data Mining
− Profiling
Integrated suite of applications for
− Revenue assurance
− Fraud management
− Credit management
FMS Designed for Adaptive Enterprises
• Classic Fraud Detection Rules
− Subscription/Call Selling/PRS/Roaming fraud
− Pre-paid fraud
− Internal/Dealer fraud
• Configurable Detection Pipeline
− Add-On Options for specific needs on an “when needed basis”, targeting specific fraud types
• Built-in Rating Engine
− for revenue assurance and real business value tracking
Multiple Analysis Engines
• Multiple Styles
− Rule Based, based on an expert system technology
− On-Line Scoring (e.g. N-N), based on past cases with a self-learning capability
− Profiling, based on the current behavior (usage and destinations)
• Multi Stream Analysis
− Revenue Assurance for analysis of revenue Integrity
• Data Mining Analysis
− Based on SPSS/Clementine
− Off-line analysis of past cases for
• fraud patterns’ discovery
• analysis of the outliers
Different Types of Fraud targeted by FMS on both wireless and wireline networks
• Network/Technical
− Cloning, home and roaming
− Tumbling, Magic Phones
− Pay phone or Prepaid
− PBX feature abuse
• Subscription
− Identity theft
− Roaming
− Call Forward
• Insider/Dealer
− Security breach of systems
− Unauthorized provisioning of services
− Stolen or counterfeit handsets
− Clip-on
− Stolen credit cards or numbers
− SIM Card Cloning
− SIM Gateway
− Content Fraud
− “Friendly” Fraud
− “Bad debt”
− IT data theft, ghosting
− Commissions on fraudulent sales

Read more...

Singl.eView Rating processes in detail

Rating processes in Singl.eView in Detail:
Basically there are five billing components that execute the rating functions in Singl.eView mentioned as below:

Event Rating Broker (BKR) process
Event Normalisation (ENM) process
Event Rating (ERT) process
Event Rating Output (ERO) process
TRE Rating Server (trerate)

The combination of the BKR, ENM, ERT, and ERO processes is called as Rating engine. The trerate server assists in real-time rating by providing EPM functions for the calculation of real-time rating charges and account balances.
Event Rating Broker (BKR)
The BKR process manages the rating engine by controlling the ENM,
ERT, and ERO child processes, and creates in shared memory the interprocess
communication queues, service cache, customer cache, account
cache, and rating subtotal cache. Additionally, an event cache is created for each BKR process.
Depending upon configuration, the BKR process creates upon startup the
inter-process communication mechanisms for the ENM, ERT, and ERO
processes. The BKR process then starts all ENM, ERT, and ERO
processes that are configured in that way.
All ENM, ERT and ERO processes associated with a given BKR must
run on the same node or Convergent Billing instance as the BKR.
Inter-process mechanisms created by the BKR are used to transmit:
· Normalized events from ENM processes to ERT processes for rating.
· Normalised events, erred events, charges, and details of normalized event files to an ERO process for output. Multiple BKR processes can exist for each Convergent Billing instance.
Event Normalisation (ENM)
The ENM process is responsible for converting incoming events (which
may include usage records or events that represent either recurring time
periods or changes in product sets) into a standard, or normalised, format.
Depending on the ENM configuration, it either waits for a command to
start normalising events from a binary file on disk containing events of a
specified type, or listens on a socket or a named pipe for one or more realtime
rating events from the TRE Rating Server. Regardless of the input
method, the source is represented by a normalised event file and is a
collection of raw events.
The ENM uses both a DIL specification and decoding expressions to
parse, clean, validate, and build normalised events
Raw events are parsed and cleaned into fields based on the DIL (Data
Interface Language) specification. Parsed field values are
assigned to event direct variables.
A sequence of decoding expressions, written in the EPM language, allows
additional validation to be performed on event direct variables, and
allowing new information to be derived from the information in the raw
event and assigned to event direct variables.
For example, a table lookup can be used to map a Cell ID from the raw event into a Region Code, and store the Region Code in an event direct variable.
The normalised event is built by ordering the event direct variables
according to the record layout. The ENM allocates each new event a
unique ID that spans reprocessing.
Event Rating (ERT)
The ERT process is responsible for applying tariffs to the normalised
events to generate charges. The ERT uses data stored in the service cache
to determine all services associated with each normalised event.
The service cache data also includes products associated with each
service. Using the associated products, the ERT process determines the
associated tariffs and applies prioritization rules to arrive at a final set of
product tariffs.
Each tariff, if eligible, is evaluated and can:
Generate a number of charges.
Update the unbilled account balance of an account.
Update ratings subtotals and clear reservations.

The ERT process writes its updates to the account and rating subtotal
caches and writes the generated charges to the event cache. Updates are
committed to the database when the ENM process is synchronized with
the ERO process.
Charges generated by the ERT process are transferred to an ERO process
using inter-process communication queues.
Event Rating Output (ERO)
The ERO process takes normalised events from the ENM and charges
from the ERT, and sends them to the database. Database updating can be
done directly.
During rating, each ENM establishes a link with one ERO (if there are
multiple, running ENM or ERO processes), and maintains the link only
for the current event file. The ENM selects an ERO that is not currently
processing records, based on the ERO’s priority (set up in the process
configuration).
The ENM-ERO pair communicates with each other (using the interprocess
communication shared memory segments) to ensure that events
pass successfully through the ENM and one or more ERTs, and that the
ERO remains synchronised with the ENM.
Additionally, the ERO is responsible for ensuring that the account and
rating subtotal caches are kept in synchronisation with the database. The
ERO commits account and rating subtotal cache updates to the database
when synchronising with an ENM process.
Events that are successfully normalised and rated are passed to the
database normalised event and charge tables, either immediately or by
loader file. Normalisation or rating error events (collectively referred to
as error events) are stored in the database.
Rating Server (trerate)
The TRE rating server (trerate) provides a single bi-directional
interface between a remote host and the rating engine.
The rating server provides an interface to callback functions that can be
used to query charge calculations and manage customer accounts
(biEventRateAndReturn). The reservation interface and external
access to subtotals, unbilled amounts, and all read-only information are
provided by trerate-registered functions.
trerate also handles asynchronous functions executed for the
replication of cache changes (in a high availability configuration) and
provides functions that send completed raw events to the rating process
(biEventRateAndStore).
Conclusion
Event rating is the process in which input events are converted into rated
events, using tariffs that have been defined for each product. Events can
be rated either in batches or in real time. This document helps the reader to understand the flow of the process involved in the rating. Please note that the Real-time rating with authorisations is made possible by the Commerce Engine using the TRE Rating Server (trerate), thus giving excellent billing solutions to the Telecom companies using Singl.eView.
Read more...

Intec Singl.eView Billing Fundamentals

Intec Singl.eView Billing Fundamentals:

Singl.eview three tier Architecture:

Tier1
• Tier 1 is the interface of the ’outside’ world with Convergent Billing.
Clients, remote hosts, and external applications enter, inspect, modify
data, and initiate processes in Convergent Billing.
Tier2

• Tier 2 consists of Convergent Billing’s expression-driven configuration,
the Transaction Engine (TRE), and non-TRE Convergent Billing
processes. Tier 2 manages transactions initiated from, and returns results
to, the first tier, as well as managing all database access.
Supported platforms for Convergent Billing are AIX, Solaris, and HP-UX
(PA-RISC and IA64).
Tier3
• The database tier in Convergent Billing consists of the Oracle database,
which stores business, administrative, and configuration data used in
Convergent Billing.
Singl.eView Configuration Layers:
Configuration elements are:
• Convergent Billing core software, consisting of key functionality for customer care, rating, billing, and workflow.
• Common framework processes, interfaces, and subsystems, consisting of a set of predefined solutions for common configuration requirements.
• Market-specific solutions and preconfigured product sets, consisting of configuration that is common to a specific set of products or solution.
• Client-specific business rules, consisting of a collection of billing rules that the service provider configures to align customer care and billing processing to reflect their own business requirements.
Rating and Billing Overview:
Rating and billing is divided into seven operations:
• Balance management, which provides event authorization, advice of charge information, and customer credit reservations.
• Event normalization, in which input event and transaction data is converted into a standard format for storage in the Convergent Billing database.
• Event rating, in which the normalized event records are aggregated and rated (costed) by applying the appropriate tariffs.
• Event output, in which the costed event records are stored in the Convergent Billing database.
• Billing, in which the costed event records are aggregated, and additional charges and discounts can be applied (for example, for recurring events).
• Invoicing, in which billing data is combined with customer detail records and incorporated into an invoice or statement image.
• Invoice output, in which invoice and statement images are printed or converted for electronic distribution.
The seven operations are carried out by the following three major components:
• The trerate TRE server, which authorizes real-time events, handles credit checking, and passes completed events on to the rating engine to be stored in the database.
• The rating engine, which combines normalization and rating. The rating engine is a series of pipelined processes, which primarily communicate using shared memory. Rating input is raw call (or ’event’) records; output is database records containing normalized events and charges rated against the events (costed events).
• The billing engine, which passes information back to the rating engine for the generation of recurring charges and adjustments, calculates billing charges, generates invoice data, and creates the invoice images for printing. Billing operations include the selection, sorting, and output of invoices or statements to printers or other output devices.
TRE Overview and Functionality:
The Transaction Engine (TRE) forms the core of the application tier of the open, three-tier architecture of Convergent Billing that is based on Tuxedo middleware. The TRE provides:

• Transaction management
• Cache management
• Connection authentication
• Multiple client access
• Asynchronous alerts
• Comprehensive set of business services and functions (exposed using APIs).
Convergent Billing Interfaces :
Convergent Billing is able to interface in multiple ways with multiple
external systems, including the following:
• Siebel
• Oracle Financials
• SAP
• Clarify
• PeopleSoft
• Various network switches in batch and real-time modes.
Convergent Billing Data Model :
The Convergent Billing data model has the following points:
• Entity relationships are determined dynamically through the configured business rules.
• Historical information is maintained for all entities (through the use of date ranging).
• Interpretation of data in generic table columns is dependent upon configuration.
The main database entities in the Convergent Billing data model are:
• Accounts
• Contacts
• Customers
• Payments
• Products
• Queries.
Customizing Convergent Billing :
• Reference Types
Reference types are defined lists of items, and are referenced throughout Convergent Billing; many of the drop-down lists available on the customer care forms are defined as reference types. Reference types are associated with attribute types to include drop-down lists in new and customized fields.
• Attribute Types
Attribute types are the major building blocks for entity validation and define the attributes of a field. It overrides the field’s existing attributes, allowing the field to be customised.
• Entity Validation
Entity validation is the key to extensively configuring the customer care environment. Entity validation is used to customize and add fields to customer care forms, and add validation. Both attribute types and reference types are used in the definition of entity validation.
• Derived Attributes
Derived attribute variables return one or more values based either on an
expression or a lookup of a table defined within the derived attribute.
Derived attribute variables and derived attribute tables allow service
providers to capture and store their business rules in a tabular format.
Derived attributes are variables derived from one or more other variables, by using:
• Simple expressions
• Conditional evaluation (similar to functions)
• Lists (tables)
• Table look-ups.
Product Data Model :
Product Model Entities
Entities that comprise the product data model are described in the following sections.
• Equipment
A product may have one or more pieces of equipment. Equipment can be a physical piece of equipment (for example, a telephone) or conceptual (for example, a telephone number). Equipment can be reused for allocation to multiple services.
• Service
A product must have at least one service. For example, a wire line or wireless telephony product might offer one or more different service types including voice or fax.
• Facility Groups
A facility group is a collection of one or more service options (also referred to as facilities, features, supplementary services, or value-add services). The group is associated with a specified service and defined as part of a product.
• Product Groups
Products can be grouped to allow an operator to locate related products more easily when assigning products to customers.
• Tariffs
Tariffs specify the charges and benefits applied to events, and the rules for applying them, to calculate cost information for inclusion on an invoice or statement.
Tariffs can be used to determine:
• Whether to apply a charge
• Amount of the charge
• Allocation of the charge to the appropriate accounts and GL
• codes.
Charge Categories :
• A charge category identifies the default account type and general ledger (GL) code to which a calculated tariff charge or benefit is allocated. For services, the charge category also identifies a specific account number. The association between a tariff and a charge category is specified when the tariff is defined, and is referred to as the tariff/charge category pair.
• Charge categories allow guiding to a ’To’ account, ’From’ account, ’To’ GL code, and ’From’ GL code. The account type specified in a charge category definition is translated to the actual account number and stored in the charge category instance (which is created when the product instance is created).
Batch Rating Engine :
Steps Used by Rating Engine
The basic steps of input, normalizing, rating, and output are used by the rating engine and outlined in the following steps.
• Normalising
Before Convergent Billing can rate events, incoming events must first be normalised. Normalising converts an event to the Convergent Billing native event format and is executed by the Event Normalisation (ENM) process. The normalisation process validates the record, verifies its accuracy, and formats it for rating. Convergent Billing provides a mapping language called DIL (Data Interface Language) that allows event data in any incoming format to be mapped and converted into Convergent Billing normalised events. DIL can handle the mapping of events in both ASCII and binary formats.
• Rating
During rating, chargeable elements are used by the Event Rating (ERT) process to determine the tariff to be applied and calculated to derive an event charge.
Output
• After charges are generated by the ERT, the Event Rating (ERO) process takes and outputs the charges and associated normalised events from the event cache.
Rating Processes
There are basically five billing components that execute the rating functions in Singl.eView. They are as below:

• Event Rating Broker (BKR) process

• Event Normalisation (ENM) process

• Event Rating (ERT) process

• Event Rating Output (ERO) process

• TRE Rating Server (trerate).

Read more...

Roaming

What is Roaming ?
Roaming is used for a customer of mobile communications to automatically to make and receive phone calls, send and receive data, or access other services while customer travelling outside the geographical coverage area of the home network, while using a network of another operator.
Roaming can be both either national roaming or international roaming. National roaming means that mobile subscribers make use of another operator network in geographical areas where there own operator does not have network coverage. This is used by operators who do not have complete coverage in a country. International roaming is used when mobile subscribers travel outside the country and make use of the different operator network of an operator in the foreign country.
Read more...