Subject: RE: TRIP

From: James Yu <[email-masked]>
Date: Tue, 14 Dec 1999 10:41:41 -0600

As indicated by Mark Foster and me that N-1 really does not mean that N-1
network is the best place to perform N-1.  It is simply something like "if
nobody else has performed the NPDB query, you, the second to the last
network, should perform the NPDB query."  This will prevent the call from
being routed to a donor network/switch if the number has been ported out of
the donor switch.  In the U.S., N-1 network implies the long distance
carrier for a long distance call.  For a local call that may involves two
LECs, the originating LEC would be the N-1 network.

One reason is that the "long distance" carrier handles a long distance call
(charges the caller) in the U.S.  If the originating network is to perform
the NPDB query, the long distance carrier has to pay the originating network
for performing the query (through the business agreement).  Another reason
is that in the U.S. NPDB administration is divided into seven regions which
are aligned with the Regional Bell Operating Company (RBOC) regions (e.g.,
NYNEX, Bell Atlantic, US West, etc.).  A NPDB in one region only contains
the directory numbers in that region.  There can be many NPDBs in one
region.  A carrier may decide to deploy its own NPDB or may decide to use
another company's NPDB (paying for NPDB dips).  The originating network in
one region typically only access the NPDB in the same region.  To access a
NPDB in another region requires business agreement between the originating
network and the NPDB and there may be higher SS7 message transport cost.

I agree with the proposal of adding an indication whether a number range has
been ported or not because it would reduce the traffic into the NPDB or an
equivalent entity.  But not all the LSs are required to use the information
to perform the NPDB/DNS query.  The indicator would be useful for an entity
that is to perform the query (e.g., the first LS can route the call to
another LS where query is performed).  As discussed before, the NPDB dip
indicator may need to be carried in the SIP if ISUP is not encapsulated.
That indicator plus this proposed indicator will tell a LS that is to
perform the NPDB-like query whether it should perform such a query.

Since several GWs will be able to terminate SCN-termianted calls, it may be
useful to include antoher indicator that indicates the number of SCN switch
hops between the terminating GW and the serving SCN switch of the called
number if we don't plan to rely on the provisioning process to provide the
information.  The information would allow an LS to determine the GW that
provides the most efficient route to the SCN serving switch of the called
number.  This does not rule out the case where business agreement determines
the the selected GW.  If we want to provide more information, we may need to
indicate the number of non-SS7 signaling routes in addition to the number of
hops.   The intention of the indicator(s) is to provide some indication
about the post dialing delay contributed by the terminating route.  Those
indicators are not needed if contribution to the post dialing delay by the
terminating route is not a concern (e.g., most routes have similar post
dialing delay).

We may also want to consider the pricing information for a route/number
ranges if we don't plan to rely on business agreement to determine the GW.
The pricing info. is about the charge to be paid to the terminating GW for
accepting a call and routing it to the SCN terminating switch.  We may need
two types of pricing info. depending on whether NPDB query has been
performed or not.  Please ignore this if this issue has been debated before
and closed.

James

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, December 14, 1999 10:43 AM
To: [email-masked]
Cc: Mark D. Foster; 'John Mainwaring';
[email-masked]; 'James Yu';
[email-masked]
Subject: Re: TRIP

"Hussein F. Salama" wrote:
> 
> > In any case, determination of where the NPDB query is done is something
> > I don't think is within the scope of iptel to determine. All we need to
> > figure out is what kind of numbers are distributed in TRIP. Near as I
> > can tell, since LRNs still refer to the prefix of numbers served by a
> > switch, doing what we were doing all along works just fine.
> >
> 
> Yes what we're doing is OK, because the LRN is part of an office's
> NPA-NXX prefix. But we may have to add a new field to the
> ReachableRoutes attribute to mark a prefix as portable. A prefix is
> marked as portable if at lease one number has been ported out of this
> prefix.

Hmm, why is that? Are you basically saying that if a prefix is marked as
portable, an LS must do an LNP query before routing to numbers in that
prefix? Then, if marked as not portable, there is no need for queries?
If so, its an interesting idea. It solves the problem of N-1, which,
from what I understand, was done in part because only carriers near the
destination would need to install triggers to perform queries on
numbers. However, if information on what prefixes are ported is
distributed in TRIP, this information is effectively dynamically
distributed. This means its equally easy for the query to be done at the
first LS as the last.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com