Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap Signalin g & Number Portability Database Queries

From: James Yu <[email-masked]>
Date: Mon, 13 Dec 1999 14:17:05 -0600

Matt,

It is a good summary of the key points.  You mentioned iptel that I forgot
to cc to.  So I'm adding it to the cc list.

My point is that the WGs should address their respective agendas while
keeping those issues in mind so that the solution(s) developed by each
individual WG can all work together.

James

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Monday, December 13, 1999 3:01 PM
To: James Yu
Cc: [email-masked]'; [email-masked]'
Subject: Re: [Enum] Nation-Specific ISUP implementations, Overlap
Signaling & Number Portability Database Queries

You certainly seem to pack alot of things into this note.  An attempt to
summarize:
(a) ISUP interworking between gateways
(b) Call routing decisions based on ISUP capabilities
(c) Timing/location of portability query
(d) Complexity of originating switch performing NPDB queries due to
national variants
(e) Overlap signalling and its complexities to call signalling,
particularly international

Here's a 2-bit opinion on some of these things...

(a) ISUP interworking was discusesed for a bit in IPTEL, and it looked
like the consensus was that gateways must be ready to fall back to some
common denominator ISUP capability set if they don't support any common
ISUP variation.

(b) Right now, the call routing portion of the solution (TRIP) is not
considering ISUP variations when making call routing decisions.  It was
discussed, but the consensus appeared to be that falling to a common
international capability set was an acceptable solution.  So it looks
like ISUP variations won't impact the route the call takes to a
destination gateway.

(c) By just reading the notes, it looks like there might be consensus to
perform the portability query before initiating the call and accessing
things like call routing.

(d) I would hope that enum does not require the querier to know all of
the possible national variants to NPDB queries.  Enum should define a
common query mechanism that is independent of national variants.  The
system should be a superset of the national variants and be able to
coordinate the information across nation's boundries.  Without this, the
whole thing seems like very unhelpful.  Enum queries really have to be
international.  

(e) About a month ago there was alot of discussion on overlap signalling
in SIP.  If you haven't read the discussion, you might want to review
it.  There were several proposals on how to handle it.  I don't recall
how well the interaction between overlap signalling and LNP was
discussed, but I recall it being mentioned a few times.  I'm sure others
can provide further elaboration of those discussions.    

James Yu wrote:
> 
> The following discussions focus on SCN-IP-SCN calls.
> 
> There are nation-specific variatoins in ISUP implementations.  I don't
know
> whether this issue has been discussed (I'm new to IETF).  When we have
only
> a few GWs, it is fine that those GWs support many ISUP implementations.
But
> when many GWs are deployed, it is not likely that every GW will support
many
> ISUP implementations.  Some may be used only for domestic use.  So it is
> likely that an international call may need to be routed to an
> "international" GW (or more than one) that interworks between two
> nation-specific ISUP implementations.  To fully use the IP network, then
the
> "international" GW will further route the call to a "domestic" GW
> (destination GW) that terminates the call into the SCN.  The call can
> certainly be routed to the destination SCN but the call charge may be
> higher.
> 
> This would seem to be inefficient that the user traffic must be routed
> through additional GW(s).  ISUP interworking probably can be done via a
pure
> signaling conversion/mapping so that the user traffic can be routed
directly
> to the destination GW.
> 
> If we need to perform number portability queries, then a good place would
be
> the destination "international" GW because it is close to the destination
> country and supports the destination country's Number Portability Database
> (NPDB) interface.  In that case, simple ISUP interworking mentioned above
> won't be sufficient.  A NPDB query also needs to be launched. The response
> to the NPDB query will decide the destination GW that should terminate the
> call.
> 
> Due to number portability, the called party's serving SCN switch changes
> when the called user switches to a new service provider.  Whenever that
> happens, the NPDB will reflect the current new serving switch or network
> information (via Location Routing Number in the North America or Routing
> Prefix in the Europe), and the "destination" GW that can reach the serving
> switch or network may change.  So a NPDB query is required to determine
the
> correct GW to terminate the call.
> 
> At ENUM, we have been discussing where to perform the NPDB queries.  The
> originating GW needs to support all nation-specific NPDB interfaces if it
is
> to query those NPDBs.  This would be expensive.  Also there is an issue
> about the encapsulated ISUP message in the SIP if originating GW's
> nationa-specific ISUP message is encapsulated (may be everyone should use
> ITU-T ISUP that is used between international switches for communicating
> among the entities in the IP domain).  The destination GW can support
> specific NPDB interface; however, it may be the wrong GW because it cannot
> reach the serving switch in the SCN that serves the called party.
> 
> Overlap signaling would make the issue more complicate.  If the call
routing
> decision is to route to the "international" GW, it is fine because number
> portability is confined within a national domain.  That "international" GW
> will then wait for additional address information and performs the NPDB
> query, if required.  But if the call is to be routed directly to the
> destination GW, and if the originating GW is the one to perform the NPDB,
> then it has to collect all the address information before it can launch
the
> query.  But the issue is that the originating GW may not know it has
> collected all the address digits.
> 
> It seems that the best entity that knows that it has collected all the
> digits and can perform the NPDB query would be the destination
> "international" GW.
> 
> I have linked several issues (nation-specific ISUP implementations, number
> portability, and user traffic routing efficiency) together that need to be
> addressed as a whole.  There may be other issues.  It is hoped that one or
> more solutions can be identified and finalized.
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: James Yu <[email-masked]>
Date: Wed, 15 Dec 1999 16:39:40 -0600

Bert,

I misunderstood the term "portable no." in your previous message.  I thought
it was an E.164 number that can be dialed.  But you mentioned "as Internet
name" so it is something like 4.3.2.1.3.3.5.2.0.2.1.e164.int or
[email-masked].  But you mentioned after NPDB query, so the E.164
number would be a routing prefix or LRN (with country code).  The routing
prefix or LRN can assist in call routing to the serving network or switch,
but it is the dialed number that can be used by the serving switch to
terminate the call.

Please inserts below for other comments/inputs.

James

> From: Albert Manfredi [mailto:[email-masked]]
> Sent: Wednesday, December 15, 1999 2:36 PM
> To: James Yu
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Enum] Nation-Specific ISUP implementations, Overlap
> Signaling & NumberPortability Database Queries
> 
> 
> James Yu [mailto:[email-masked]] wrote:
> 
> >
> > Bert,
> >
> > Please see inserts marked by ****.
> >
> > James
> >
> > **** It is not clear what "why not just map each portable
> > number only to an
> > E.164 number in the NPDB?" means.  Please clarify. ****
> 
> I was suggesting here that the number portability database (NPDB)
> would be a database which maps
> 
> portable number <---> E.164 "home" number,
> 
> in its simplest incarnation, and that therefore putting this
> function within the existing DNS, as in
> 
> portable no.(as Internet name) <--> IP addr <--> E.164 (in AESA)
> 
> ought to work. A portable number is just a globally unique arbitrary
> ID, after all, much like the Internet name is.
> 
> > **** I assume that the "E.164" in the reply means the
> > routing prefix or the
> > LRN (with country code). ****
> 
> It means the standard E.164 format, with country code etc., but not
> in any one national dialing plan. In the US, for instance, you would
> have to add "011" in front of it to dial out.
> 
> > Smart terminals can query the NPDB (DNS) directly and
> > translate the
> > E.164 number returned into something in the local dialing plan. Or
> > use the IP address, if available.
> >
> > **** It is not clear why "local dialing plan" is involved
> > in this example if
> > the smart device is already connected with the internet. ****
> 
> Because it is possible that the destination side is not
> IP-connected. In the general case, the smart terminal might have to
> initiate a telephone call, and the local dialing plan would be
> needed. Or are you assuming the use of MEGACO or something like
> that?

If NPDB query is done, then the E.164 number would be a routing number.  The
smart terminal won't be able to use that number to dial out via the SCN.
The SCN will treat that number as the dialed number and a NPDB query will be
performed if it is a ported number.  If the smart terminal is to dial out
from Internet (e.g., via a SIP server), then "dialing plan" won't be
involved.

> 
> > **** If the smart
> > terminal uses the internet to get the routing prefix or
> > LRN but accesses the
> > SCN for call initiation, there is no way this "smart
> > terminal" can provide
> > both the dialed number and the routing prefix/LRN to the SCN. ****
> 
> Not sure what this means.

See the comment above.

> 
> > The simplest way to accommodate mobile terminals is to have them
> > operate through a home server, as if they are always at that home
> > location. This seems wasteful when one is roaming.
> >
> > Alternatively, the mobile station, when accessing the the NPDB via
> > its roaming access base station, can have that base station
> > translate the E.164 number returned by the NPDB into the local
> > dialing plan.
> >
> >
> > **** It won't be a "base station" performing that
> > function.  Either a mobile
> > (services) switching center (MSC) or some interworking
> > function will perform
> > that function. ****
> 
> Good point.
> 
> > **** But it is not clear why a mobile station
> > will need to access
> > the NPDB directly unless it is the "smart terminal" you
> > mentioned earlier
> > and is using Internet to reach the called party.  ****
> 
> Good point again, but again, the smart user might need to call a
> dumb telephone. Take the case where I fly from Wash DC to Paris with
> my roaming host, and want to dial a portable number of my French
> buddy, who happens to be located in Paris. I want the number
> returned from the NPDB to be translated into the local Paris
> numbering plan. (Perhaps this is not a problem if we assume MEGACO.)
> I would not want to make that local Paris call via Wash DC.
> 
> In any event, if a roaming mobile station needs to dial a non-IP
> called party with portable number, that destination portable number
> will need to be translated into the roaming station's _current_
> national numbering plan. That was the only point I was trying to
> make. Someone has to translate the E.164 number returned by the NPDB
> into something that can be dialed locally. (This is not an enum
> issue, though.)

I don't quite get your point.  The "translation" you mentioned is a feature
called "optimal routing" in GSM (European cellular standards).  Technically,
it can be done.  The requirement is for the originating switch (or
intermediate switch) to query the dialed mobile station's "home location
register (HLR)" which gets a routing number (called Mobile Station Roaming
Number in GSM or Temporary Local Directory Number in U.S. ANSI (American
National Standards Institute)-41 standard) from the "visitor location
register (VLR)/Mobile Switching Cetner(MSC)(MSC)" of the the cellular system
that currently serves the roaming mobile station.  If this originating or
intermediate switch is a wireline switch, it means that it needs to check
for every outgoing call to see whether it is "mobile"-terminated (not a
small task in many cases) and to support Mobile Application Part (MAP) that
is specific to the dialed mobile station's "home" system (e.g., GSM or
ANSI-41).  The MAP interface to be supported is the one between the Gateway
MSC and the HLR that requests for routing information. The other problem is
charging.  What if you are calling a mobile station that is not in Paris but
in Africa.  If the call charge from Paris to Africa is much higher than the
call from Paris to U.S., the caller would not be happy if he thinks it is a
Paris to U.S. call (e.g., $0.20/min) but ends up paying a much higher rate
($.60/min).   Those are the main reasons why the optimal routing method for
mobile-terminated calls has not been supported.

Also, you used "portable number" for the mobile directory number.  The
mobile directory numbers are E.164 numbers, and they reveal some physical
location information such as a particular country, a cellular network (e.g.,
with nation-wide coverage), or a cellular switch/system in a specific
geographic area (e.g., my mobile directory number is +1-202-256-1200 which
is in D.C.).

> 
> > **** Please list those acronyms.  I can provide the info.
> >  They might have
> > been provided in earlier messages. ****
> 
> SCN, LRN, and GW. I think GW means gateway. The others are obviously
> telephone number formats.

SCN - Switched Circuit Network
LRN - Location Routing Number.  Every local exchange (with access line
termiations to the users) in the North America that is required to support
number portability is assinged a LRN (format is NPA+NXX+0000). It is used by
the SCN to route a call in the number portability environment.  You can
access NeuStar's web site (http://www.neustar.com) for the official
definition of LRN and some other number portability or North American
Numbering Plan related information.
GW - Gateway

> Bert
> [email-masked]
>