Subject: RE: TRIP

From: James Yu <[email-masked]>
Date: Wed, 8 Dec 1999 02:32:06 -0600

-----Original Message-----
From: John Mainwaring [mailto:[email-masked]]
Sent: Tuesday, December 07, 1999 4:02 PM
To: 'Jonathan Rosenberg'
Cc: [email-masked]'; James Yu; [email-masked]'
Subject: RE: TRIP

|From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 

|I'm less sure about deferring the LNP query to N-1. In the SIP 
|architecture, 
|at least, each proxy is responsible for doing a translation function 
|(called the 
|location service), which is similar in concept to an LNP 
|database query. 

I understand that SIP is different from the tandem network of circuit
switches.  I think SIP will require the originator to know LNP information,
but I'm not sure that existing collection of SCPs accessed by the TCAP/SS7
signaling system is the place to get it.

 *********  For SCN to SCN via IP or IP to SCN calls, the internet is the
N-1 network (although many networks may be involved in the IP-domain
routing), the entity that performs the LNP query via TCAP/SS7 over IP or
real-time or non-real-time LNP-like mechanism via DNS) can be the
originating GW/GK/SIP server or an intermediate GW/GK/SIP server but won't
be the terminating GW/GK/SIP server because it may be too late to perform
LNP query to find out that it does not reach the serving switch identified
by the LRN.  There are certainly many issues if the originating GW/GK/SIP is
to perform the LNP query.  For example, several protocols can be used
between a switch and a NPDB.  In Europe, I heard that there are
country-specific variations to the switch-NPDB interface protocol.  For the
originating GW/GK/SIP server to query all the NPDBs worldwide would be a big
burden.  

One possible solution is that a standardized query can be launched by the
entity which will be mapped by an interworking like entity to
country-specific NPDB query to reach the existing NPDBs.  Another potential
solution is to have NPDBs in the internet that support the standardized IP
entity-to-NPDB interface.  Certainly this does not rule out that the
existing NPDB from being enhanced to support this new IP-domain interface.
*************

 |I'll also 
|note that I have been told that the LNP dip being done at the N-1 
|carrier is 
|only a north american thing, and that in Europe, its done differently. 

Of course. 

Actually, last I heard the Europeans were still considering Release to
Pivot, which might be a plausible model for SIP.  Initiate to the default
code owner first, and allow for a "refuse with redirection" or something. 
It's got its weaknesses, which include putting a burden on the donor of the
ported number and relying on an uninvolved third party to set up a call, but
it does keep the supporting infrastructure simple. 

******* Release to Pivot will not work in the U.S. because the FCC has ruled
out any solution that relies on the donor network to complete the call. 
Also, the "donor" switch and the "pivot" switch at least must be upgraded to
support this solution.  If the switch does not store the new LRN/routing
prefix information for a ported-out number, a database dip must be performed
in order to provide the LRN/routing prefix in the ISUP Release message.  If
a "donor" switch stores the information, the provisioning/administration of
the information is not a simple process. **********

Another interesting working model is wireless roaming.  It is capable of
dynamically redirecting you anywhere (at least within a continent or so) and
it works at the level of individual telephone numbers.  Of course a single
wireless operating company owns all the numbers in an NPA NXX, which avoids
the major problem LNP was designed to create.  (No, that's not a typo, it's
editorial comment.) 

Probably it's more of an administrative problem than a technical one.  It's
so easy to fall into the trap of thinking there are technical solutions to
administrative problems, although technical solutions can certainly help
perpetuate administrative problems. 

******** FCC has granted a delay for the wireless carriers in the U.S. to
support local number portability (LNP) because the new entrants - PCS
carriers are too busy in deploying their networks.  LNP is intended to help
the new entrants to compete with the incumbent carriers.  So if the new
entrants ask for a delay, FCC certainly has no reason to push wireless LNP. 
Also there are issues on roaming where the roaming markets may not be
required to support LNP (LNP is to be supported in the top 100 major
Statistical Trading Areas in phases).  But I believe that the delay is
temporary because FCC's goal may be nation-wide number portability which
allows the subscriber to switch from wireline service provider to a wireless
service provider and move from one location to another location.  The LRN
method will allow that with minimum system upgrades.  The major issue about
location portability is the call charing/rating.  If flat rate is used for
all toll calls (e.g., 10 cents per minute regardless of the distance between
the calling party and called party), location portability can be supported
easily. 

            Wireles is a similar model if we view the "donor switch" as the
"home" system" and the "serving switch" as the "vistied system."  However,
there are differences.  The "home system" in the wireless model is the
service provider of the "roamer."  It authorizes the visited system to
provide the services to the roamer and guarantees the payment even if the
subscriber does not pay his/her bill.  Also, Mobile Application Part (MAP)
is used between the visited and home systems to register the "roamer" and to
get a temporary routing number to route the call to the visited system. 
Either the call must always be routed through the home system to reach the
visited system or a query to the home system must be performed first to
perform optimal routing to the visited system directly.  NPDB approach
actually allows the query to be done (for optimal routing) without the
involvement of the "donor" network.  *************

 John Mainwaring 
Nortel Networks 
[email-masked] 

---------
This message came from the IETF IPTEL Working Group Mailing List.