Steve, All, re: Wireless LNP, OSSes, and SS7
This week's feature story in Telephony Magazine touches on one of our favorite topics: Wireless Local Number Portability, or LNP. The article, which I've copied below, was written by David Cox, director of Product Marketing for Tekelec's [ TKLC ] Network Switching Division.
Enjoy, and Regards, Frank Coluccio
===============
internettelephony.com
February 22, 1999
Wireless LNP:
The time to act is now
Carriers waiting in the wings to implement local number portability might be wise
to change their strategy--models show that early adoption may not be such a bad
idea
DAVID P. COX
Think your business won't be affected by local number portability until 2002?
Think again. Although the FCC recently extended the LNP implementation
deadline for wireless providers to November 2002, the arrival of number porting
can seriously affect a carrier's quality of service and operating costs today.
Although the mandate for wireless operators to implement local number
portability (LNP) has been delayed, the significant volume of wireless-to-wireline
calls within typical wireless networks is forcing them to seriously consider
adopting an LNP solution early.
With several options available, operators must study their choices carefully to
determine the best course of action for their business needs. To fully evaluate the
factors affecting these choices, wireless operators should understand the
implementation methods, network architecture and business impacts of LNP.
The challenge: How to implement LNP
Implementing LNP requires carriers to retool their network architecture, rethink
the role of the intelligent network, and dismantle proprietary gateways and
restrictions on network ingress and egress. Nevertheless, LNP represents an
opportunity to leverage the intelligent network to enable future revenue-generating
applications and services.
The network impact and cost of implementing LNP is a direct function of how
numbers are decoupled, or separated from the physical switch location. If a
wireless operator cannot check if a dialed number has been ported, it may incur
a dip charge for every call a customer places to a ported exchange from the
carrier that performed the query--whether the number being dialed has been
ported or not.
What does this mean to wireless carriers? Industry statistics have indicated that
up to 90% of wireless outbound calls are intraLATA, and 80% of those calls
terminate to a wireline number. With each customer placing an average of 2.25
calls a day, the dip volume can quickly become staggering--100,000 subscribers
can generate a dip volume of 4.05 million calls a month (Table 1). Although the
formula may seem complex, the bottom line is simple: At a per dip charge of
0.3¢, if the wireless implementation date is extended by five years as requested
in one waiver, carriers could end up paying significant unrecoverable costs.
Eight number portability administration centers (NPACs) currently operate in
North America. Each NPAC receives number porting requests from carriers and
coordinates the transfer of numbers between them. It also provides administrative
services to carriers in the region participating in LNP and maintains the "master"
number portability database for that region. The NPAC tracks all changes made
to individual carriers' databases and sends updated information electronically to
all carriers in the region.
In an LNP environment, even POTS calls require a database query and response.
Figure 1 provides an example of how a location routing number (LRN) translation
is performed. Two new operations support systems (OSSs) have to be added to
the SS7 network to enable number portability: the local service order
administration system and the local service management system.
The local service order administration system provides the interface from the
existing service order OSS to the NPAC. The local service management system
is the vehicle through which NPAC downloads information on ported numbers to
the LNP database deployed in each carrier's network (Figure 2).
The new service provider's local service order administration system places the
request to port a customer's number to the NPAC. The NPAC then
communicates to the previous carrier, identifying the number requesting the port.
The NPAC records the port information in the master database and downloads
the ported number and associated information to each carrier's local service
management system. The carrier's local service management system then
updates its LNP database. The synchronization of databases in the network is
critical to the success of number portability.
Engineering LNP in the network
When determining how to engineer a network for LNP, it's important to remember
that SS7 traffic and database activity are not directly proportional to the number
of subscribers who have ported. When just one subscriber in a 10,000 block is
ported, every number in that block is marked as ported. Every call to any number
in the block then requires an LNP query. Existing intelligent network service
control points (SCPs) will likely not have adequate capacity to provide intelligent
network services and LRN translation. Three options are available for deployment
of LRN functionality: default routing to the incumbent or leasing service from a
service bureau; deploying LRN-capable SCP databases; or deploying integrated
signal transfer point (STP)/SCP LRN databases.
Outsourcing LNP functionality. Depending on a carrier's specific business
needs and current network architecture, one alternative for LNP
deployment is to outsource the LRN database queries. Carriers can do
this either by defaulting to the N-1 carrier to perform the dip or by
leasing service from a service bureau. This solution does eliminate many
of the costs associated with capital deployment by spreading payment
out over a period of time on a usage basis. However, carriers need to
consider two key areas: cost recovery and network control (see story on
page 38).
Because the FCC will allow carriers to recover only direct costs of LNP
implementation over a period of five years, carriers that have not deployed their
own LNP solutions must continue to lease the service after the cost recovery
period has expired or deploy LNP capability at a later date.
Depending on the date deployed and the cost of the implementation, the cost
recovery mechanism in place may be insufficient or nonexistent. Very similar to
the age-old "buy vs. rent" question in home ownership, the long-term aspects of
choosing to outsource LNP capability should be considered and the decision
based on specific business needs and objectives.
Of equal importance in analyzing outsourced LNP capability is network control
and management. A wireless operator should consider its ability either to
implement and maintain an LNP solution with existing resources or hire
additional staff as required. Again, the longer-term implications are a key
decision factor. Carriers should consider the impact of managing network routing
and client information instead of depending on the LNP service provider.
The database decision. In a non-LNP environment, SCPs have served as
databases for intelligent network services that require translation
capabilities. Most carriers in major metropolitan areas have already
installed SCPs to support intelligent network/AIN services and assume
that existing SCP platforms can readily support LNP with the addition
of application software. But this is usually not the case.
In a non-LNP network, 5% to 10% of all calls require translation. With the
implementation of LNP, query volume becomes a major issue. In the U.S.,
surveyed wireline service providers--already well into LNP
implementation--anticipate a 75% increase in SS7 traffic, with nearly half of the
respondents anticipating a 100% increase in SS7 traffic as a direct result of LNP.
If the percentage of calls requiring queries reaches 100%, the overall increase in
SS7 network usage could jump as high as 1900%.
SCP vs. integrated STP-based approach. An important concern for wireless
operators as they equip their networks for LNP is capacity. SS7 protocol
defines a link as one 56 kb/s circuit. Up to 16 links can be grouped into
one link set. Adjacent network elements such as STPs and SCPs can be
connected by no more than two
16-link link sets. The protocol further dictates that links and link sets
can be engineered to no more than 40% of their theoretical capacity.
What does all this mean? Today's SCP solutions are limited to a maximum
transaction rate of 896 transactions per second, based on an average
query/response message size of 100 bytes with each link engineered at 40%
capacity. In large metropolitan areas, analysts forecast that LNP queries will
generate 4000 to 8000 transactions per second. Nine SCPs and 288 links are
required to support a transaction rate of 8000 transactions per second.
An alternative to the SCP-LNP approach is to integrate the LNP solution directly
into the STP, which is essentially a packet switch on the SS7 network. The
integrated STP/SCP platform, a new concept in AIN deployment, provides
significant improvement in performance over an SCP-based approach (Figure 3).
For example, Tekelec's Eagle STP with integrated LNP can be provisioned to
handle more than 20,000 transactions per second for up to 12 million records on
a single platform that supports more than 400 SS7 links. Capital investment and
recurring expenses are reduced by eliminating the need for external SCPs and
the associated links and facilities. Overall system reliability can be improved
because there are fewer network elements and fewer points of failure. The total
"round trip" delay from query to response associated with LNP transactions is a
key concern in call processing. The integrated STP/SCP approach eliminates the
signaling hop between the STP and SCP.
Triggerless or triggerbound?
Once a wireless operator has decided on its method of LNP database
implementation, it must determine how to launch, or trigger, LNP queries to that
database. The number of trunk groups from the carrier's mobile switching center
(MSC) to the public network will largely determine how many options the operator
has.
The first option is to load triggers in the MSC to launch the LNP query to the LNP
database. The database then does a lookup to determine if the dialed number
has been ported. The database returns the LRN for the dialed number to the
MSC. The return message also provides information used by the MSC to select
the trunk group for routing the call. This solution is suitable for MSCs with one or
more trunk groups.
If an MSC routes to a single access tandem, or if the trigger software for the
MSC is not available yet or the carrier simply doesn't want to invest in costly
software to upgrade its MSC switch, the triggerless option may be the solution.
With the triggerless option, the MSC sends the initial address message with the
dialed number to the LNP node (either an integrated STP or SCP). The node
queries its LNP database and determines whether the number has been ported.
If the number has not been ported, the initial address message is switched
through to the access tandem without modification. If the destination number has
been ported, the triggerless-equipped LNP node modifies the initial address
message to include the LRN and routes the call to the access tandem.
It's all about choices--lots of choices that must be weighed against each wireless
provider's network size and configuration as well as business objective. The best
advice on how to go about making these crucial choices is to work with a
knowledgeable and experienced LNP vendor and hub provider that can help
evaluate the situation and help determine how best to proceed.
David P. Cox is Director of Product Marketing for Tekelec's Network Switching
Division, Morrisville, N.C. His e-mail address is dave.cox@tekelec.com .
For questions or comments,
contact Web Editor Karen Murphy msblues@earthlink.net .
Please report any problems with this site to:
Webmaster@internettelephony.com.
www.internettelephony.com
Telephony February 22 |
