IN services in Multi Operator Multi service

environment
Background:
TRAI has issued draft notification on 2nd Dec 2005 called IN services in
Multi Operator, Multi Network Scenario regulation 2005.

In the draft, TRAI mandated that, IN services offered by one Service

provider should be accessible to all other Service Providers.

TRAI has sent another letter on 29th Aug as reminder, requested all
Service providers to attend meeting on 8th Sep to discuss the final
architecture.

The Objective of this document is to describe

• Requirements stipulated by TRAI
• IN features
• Describe the options available and merits and demerits of each
option
• Conclusions and recommendations based on merits and demerits
of each option.

Requirements:
Based on the mandate given by TRAI, the IN services like Free phone,
Virtual calling cards, Premium rate service etc., can be provided by any
Service provider.
However, the subscribers of all other service providers should be able
to access these services.

IN Features:

Free Phone - 1800 + SCP-Code + Number

Virtual Private Network (VPN) - 1801 + SCP-Code + VPN-ID +
Member-ID
Calling Card (VCC, ACC, CCC) - 1802 + SCP-ID + CC No
Tele-voting (chargeable to caller) - 1803 + SCP-ID + TV No
Tele-voting (not chargeable to caller) - 1861 + SCP-ID + TV No
Premium rate - 0900 + SCP-ID + PR No
Universal Access (local) - 1860 + SCP-ID + Sub No
Universal Access (Long distance) - 0901 + SCP-ID + Sub No
UPT - 0902 + SCP-ID + Sub No

SCP Codes are allocated by DOT for all service providers. This codes
need to be common across all circles for each service provider.
Methodology of implementation:
To meet the above requirements, TRAI has suggested following
options.

Option-1:
SSP owned by one Service provider should get interconnected to SCPs
of all other Service providers.
e.g. all TTSL MSCs or GMSCs (SSP) should get integrated with SCPs of
all other operators.

This requires upgrading INs and SSPs to support multiple technologies

i.e. multiple protocol stacks.

This involves additional investment for upgrading the IN platforms as

well as MSCs. This also involves higher lead-time for integration of
SSPs with all SCPs.

Option-2:
The Service provider will route the calls based on dialed digits to the
SSP of service provider where the IN services are hosted.

E.g. BSNL subscriber dials 1802209 for TTSL Calling card, BSNL should
route the call to TTSL POI. TTSL GMSC (SSP), which received the call,
will trigger IN for the service.

This is simple and feasible solution as there is no need for any up-
gradation of Switches and IN platforms

However, exclusive trunk groups should be created for each of the

service towards Access provider for individual services. Charging the
subscriber for using the services and defining IUC charges needs
further study.

Option-New:
All service providers share database related to IN services with other
Service providers. The service realization happens within service
provider.

E.g. Free phone service / Premium rate service of BSNL should also be
hosted in TTSL’s IN platforms . The data related to the service need to
be communicated to all Service providers to configure in their INs, prior
to launch of the service.

This is complex and the major issues are

 • Each Service provider should have IN platform, which should
support all IN features launched in the market by other service
providers. This involves investment in upgrading and enhancing
capacity of the IN.
• Each service provider should upgrade all MSCs (SSPs) if required,
to support triggers related to all features deployed in the market
• With the above points, only number translation services can be
provided. I.e. only Free phone, premium rate Universal Access
(local and Long distance) and Universal Personal
Telecommunication services can be provided.
• However other services like VPN & Tele-voting involves dynamic
data. Hence near real time updates between INs are required.
This requires the transparent data exchange between all
operators in near real time.
• Calling cards service involves money stored in the IN platform.
This can’t be shared with any other service provider. Hence, this
involves development of new protocol between INs for credit
allocation and confirmation of charges etc., similar to RTEC
interface we are using for data charging

Considering the above issues, this option is more complex than the
other options.

Conclusions and Recommendations:

Considering the all options suggested by TRAI, the best option with
minimum changes in MSCs and INs is Option –2.

With Option-2,
• There is no need for any additional investment on MSCs as well
as INs
• However, for all the services the actual destination number is not
known to originating service provider and hence, this leads to
o IUC charges can’t be differentiated based on local / Long
distance / ISD calls.
o Charging the subscriber (prepaid and Postpaid) for using
the IN services of other service provider needs further
analysis.
o Lawful interception will be more complex as actual B
number is not available in the originating MSC / Switch.

The other options are more complex than Option-2 for implementation.
They also need higher investment and higher lead-time for
implementation.