Subject: [ENUM] Comments to <draft-ietf-enum-e164-gstn-np-03.txt>

From: [email-masked]
Date: Thu, 7 Mar 2002 13:46:20 +0100

I want to make some comments and corrections to the Internet-Draft "Number
Portability in the GSTN: An Overview", draft version 03.

My comments concentrate on the sections for Europe.

(1) Comment to section 5.2 Europe:
In Europe the ETSI standards for Number Portability are the basis for
realising NP in the fixed network. Item (c) "ISUP triggerless translation"
is not standardised in the ETSI standards (and by the way also not
standardised in the ITU-T Recommendation and Supplements) and should not be
reflected in this NP overview document. If the "ISUP triggerless
translation" is used in european countries then this is a network operator
matter.

==> delete item (c) in section 5.2

(2) Comment to section 6.2 Europe:
The first two sentences explain one possibility to map the RN and DN to the
ISUP IAM.
In the fourth paragraph a reference is made to ITU-T Rec. Q.769.1. This
should be the corresponding baseline for the mapping of the RN and DN to
the ISUP protocol. By the way, in Europe ITU-T Rec. Q.769.1 is slightly
modified by ETSI EN 302 097 V.1.2.2 (2000-09).

Text proposal for the whole section 6.2:

[MM]
In a number portability environment, the directory number (DN) is not
sufficient to route the call. There is a need to derive a routing number
(RN) based on the methods defined in [CS1] and [CS2]. Once the RN has been
determined, the routing in the network will be based on this RN. As the RN
is always a complete address, sending of additional digits in overlap
operation applies only to the directory number (DN) information. The DN is
transferred along with the call to identify the called ported subscriber.

The enhancements in the ISUP protocol to support number portability are
briefly described below.

   Three methods can be used to transport the Directory Number (DN) and
   the Routing Number (RN):

   (a) Two separate parameters with the CdPN parameter containing the
      RN and a new Called Directory Number (CdDN) parameter containing
      the DN.  A new value for the Nature of Address (NOA) indicator in
      the CdPN parameter is defined to indicate that the RN is in the
      CdPN parameter.  The switches use the CdPN parameter to route the
      call as is done today.

   (b) Two separate parameters with the CdPN parameter containing the
      DN and a new Network Routing Number (NRN) parameter containing
      the RN.  This method requires that the switches use the NRN
      parameter to route the call.

   (c) Concatenated parameter with the CdPN parameter containing the RN
      plus the DN.  A new Nature of Address (NOA) indicator in the CdPN
      parameter is defined to indicate that the RN is concatenated with
      the DN in the CdPN parameter.  Some countries may not use new NOA
      value because the routing prefix does not overlap with the dialed
      directory numbers.  But if the routing prefix overlaps with the
      dialed directory numbers, a new NOA value must be assigned.
      Spain uses "XXXXXX" as the routing prefix to identify the new
      serving network and uses a new NOA value of 126.

As an example, in some european countries, a routing number is prefixed to
the dialed directory
   number.  The ISUP CdPN parameter in the IAM will contain the routing
   prefix and the dialed directory number.  For example, United Kingdom
   uses routing prefixes with the format of 5XXXXX and Italy uses
   C600XXXXX as the routing prefix.  The networks use the information
   in the ISUP CdPN parameter to route the call to the New/Current
   Serving Network.

   The routing prefix can identify the Current Serving Network or the
   Current Serving Switch of a ported number.  For the former case,
   another query to the "internal" NPDB at the Current Serving Network
   is required to identify the Current Serving Switch before routing
   the call to that switch.  This shields the Current Serving Switch
   information for a ported number from the other networks at the
   expense of an additional NPDB query.  Another routing number, may be
   meaningful within the Current Serving Network, will replace the
   previously prefixed routing number in the ISUP CdPN parameter.  For
   the latter case, the call is routed to the Current Serving Switch
   without an additional NPDB query.

   When the terminating switch receives the IAM and sees its own
   routing prefix in the CdPN parameter, it retrieves the originally
   dialed directory number after the routing prefix, and uses the
   dialed directory number to terminate the call.

   In addition to the addition of the routing prefix to the CdPN
   parameter, some other information may be added/modified as is listed
   in the ITU-T Recommendation Q.769.1 [ISUP] or ETSI EN 302 097 [ETSI
ISUP]..

   There is also a network option to add a new ISUP parameter called
   Number Portability Forwarding Information parameter.  This parameter
   has a four-bit Number Portability Status Indicator field that can
   provide an indication whether number portability query is done for
   the called directory number and whether the called directory number
   is ported or not if the number portability query is done.

   Please note that all those NP enhancements for a ported number can
   only be used in the country that defined them.  This is because
   number portability is supported within a nation or only within a
network.

   Within each
   nation, the telecommunications industry or the regulatory bodies can
   decide which method or methods to use.

[MM]:
The sentence in draft 03 "Number portability related parameters and coding
are never passed across the national boundaries." is not correct. The
passing of a number portability related parameter is dependent on the
agreements at the point of interconnections. Modify the sentence:

Number Portability related parameters and coding are passed across national
boundaries dependent on the agreements at the interconnection interface.
[MM]

  For example, a UK routing prefix can only be used in
   UK, and would cause routing problem if it appears outside UK.

   As indicated earlier, an originating wireless network can query the
   NPDB and concatenate the RN with DN in the CdPN parameter and route
   the call directly to the Current Serving Network.

   If NPDBs do not contain information about the wireless directory
   numbers, the call, originated from either a wireline or a wireless
   network, will be routed to the Wireless donor network.  Over there,
   an internal NPDB is queried to retrieve the RN that then is
   concatenated with the DN in the CdPN parameter.

   If MNP-SRF is supported, the Gateway Mobile Services Switching
   Center (GMSC) at the wireless donor network, when receiving a call
   from the wireline network, can send the GSM MAP Send Routing
   Information (SRI) message to the MNP-SRF.  The MNP-SRF interrogates
   an internal or integrated NPDB for the RN of the MNP-SRF of the
   wireless Current Serving Network and prefixes the RN to the dialed
   wireless directory number in the global title address information in
   the SCCP Called Party Address (CdPA) parameter.  This SRI message
   will be routed to the MNP-SRF of the wireless Current Serving
   Network, which then responds with an acknowledgement by providing
   the RN plus the dialed wireless directory number as the Mobile
   Station Roaming Number (MSRN).  The GMSC of the wireless donor
   network formulates the ISUP IAM with the RN plus the dialed wireless
   directory number in the CdPN parameter and routes the call to the
   wireless Current Serving Network.  A GMSC of the wireless Current
   Serving Network receives the call and sends an SRI message to the
   associated MNP-SRF where the global title address information of the
   SCCP CdPA parameter contains only the dialed wireless directory
   number.  The MNP-SRF then replaces the global title address
   information in the SCCP CdPA parameter with the address information
   associated with a Home Location Register (HLR) that hosts the dialed
   wireless directory number and forwards the message to that HLR after
   verifying that the dialed wireless directory number is a ported-in
   number.   The HLR then returns an acknowledgement by providing an
   MSRN for the GMSC to route the call to the MSC that currently serves
   the mobile station that is associated with the dialed wireless
   directory number.  Please see [MNP] for details and additional
   scenarios.

The last paragraph of section 6.2 describes only one possibility to realise
MNP. This should be clearly stated at the begin of the explanation.
[MM]

(3) Comment to Section12. Normative References

Replace
   [ISUP] ITU-T COM 11-R 162-E, Draft Recommendation Q.769.1,
        "Signaling System No. 7 - ISDN User Part Enhancements for the
        Support of Number Portability," May 1999.
With
   [ISUP] ITU-T Recommendation Q.769.1,
        "Signaling System No. 7 - ISDN User Part Enhancements for the
        Support of Number Portability," December 1999.

Replace
   [MNP] Draft GSM 03.66 V7.2.0 (1999-11) European Standard
        (Telecommunications series) Digital cellular telecommunications
        system (Phase 2+); Support of Mobile Number Portability (MNP);
        Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0
        Release 1998).
With
   [MNP] ETSI EN 301 716 (2000-10) European Standard
        (Telecommunications series) Digital cellular telecommunications
        system (Phase 2+); Support of Mobile Number Portability (MNP);
        Technical Realisation; Stage 2; (GSM 03.66 Version 7.3.1
        Release 1998).

And add
   [ETSI] ETSI EN 302 097 V1.2.2 (2000-09) European Standard
        (Telecommunications series) Integrated Service Digital Network
        (ISDN); Signalling System No.7 (SS7); ISDN User Part (ISUP);
        Enhancement for support of Number Portability (NP);
        [ITU-T Recommendation Q.769.1 (2000), modified]

#######################

Here end the comments and corrections to draft 03.

Nevertheless I have a general question. What is the aim of this
IETF-Draft???
As far as I can see it, this draft once again describes NP and MNP.
But this has already been done within ITU-T Recommendations and
Supplements, in ANSI standards and in ETSI standards.
It could happen that this draft does not correctly describe some issues of
NP and MNP and maybe contradicts to the standards.

Why don't we say:
"NP and MNP are defined in the following standards:
ITU-T Rec. ....
ANSI standard ....
ETSI standard ...."

What additional information is missing in those standards which shall be
reflected in the IETF-Draft?
Is it really necessary to know all the codings of a RN and the codings of
the protocol?

One issue, for instance, is not even mentioned in the draft, that is NP and
Completion of Calls to Busy Subscriber (CCBS) which requires mechanisms for
bearer unrelated signalling messages.

How should we proceed?

Kind regards,

Monika

++++++++++++++++++++++++++
Monika Muench
Alcatel SEL AG
Lorenzstrasse 10
70435 Stuttgart
Germany

mail:  [email-masked]
phone:  +49 711 821-41417
fax:     +49 711 821-40017
++++++++++++++++++++++++++

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

---

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 7 Mar 2002 14:59:30 +0100

Thank you Monika for this exhausting (eh, exhaustive) explanation.

> "NP and MNP are defined in the following standards:

Agreed, but:

I like the draft as an overview, as long as the correct references are
there, even with a warning, that the draft is not complete (they are
informational anyway). Contradictions can be removed, as you have shown.
This also holds for the related <draft-foster-e164-gstn-npusa-03.txt>, which
could even be more detailed, but nevertheless was intersting to read (for an
European).

I think, it saves people time to collect and read all the documents and find
out the relevant parts. ITU and ETSI documents are not so easy to read, and
the draft may serve as a guide. Of course, if you are seriously working, you
should read everything necessary, but we all know, how it is reality  ;-)

And I think there is another reason I have discovered recently: Some IETF
people do not like word documents ;-)

> reflected in the IETF-Draft?

good question, anybody any ideas?

> Is it really necessary to know all the codings of a RN and 

If I consider the currently starting discussion to use ENUM potentially for
everything, it may be not a so bad idea. Even to prove eventually, that you
can't use ENUM for everything!

BTW, I would like on the other side ONE document explaining and listing up
all attributes and parameters currently used or proposed by SIP, PINT, tel:
URIs and whatever-other-drafts in one place, just to be on the save side. 
 
> bearer unrelated signalling messages.

Lets make a list of the information considered missing and input it to the
draft, maybe only as references to the correct standards.

best regards
Richard

---

From: "Yu, James" <[email-masked]>
Date: Mon, 11 Mar 2002 15:59:58 -0600

Monica,

Thanks for your comments.  Please see the response marked with [YU].

James

> ==> delete item (c) in section 5.2

[YU] I'll take that one out because it is an implementation instead of a
standard.

> modified by ETSI EN 302 097 V.1.2.2 (2000-09).

[YU] Will update the references.

>    decide which method or methods to use.

[YU] You have re-arranged some paragraphs in your suggestion in addition to
some proposed texts.  I'll check and incorp. 

> boundaries dependent on the agreements at the interconnection 

[YU] Will incorporate.  I'd appreciate if you provide any known
examples/cases.
 
> MNP. This should be clearly stated at the begin of the explanation.

[YU]  Will do.

>         [ITU-T Recommendation Q.769.1 (2000), modified]

[YU] Will update the references.

[YU]  The purpose of this I-D is to give an overview of NP (including MNP)
with the intention to point out the possible impacts of NP on some works in
progress in IETF.  So the section on "potential implications" provide some
discussions.

One purpose for the ENUM WG is realize that NP will implact ENUM if the
telephony service providers'  (TSPs') NAPTR RRs are collocated with the end
users' NAPTR RRs under the same tree name, e164.arpa.  In the ENUM Forum
(U.S.), there is a consensus there that the TSPs should use a different tree
name is they want to use ENUM technology for the "network" services.

> "NP and MNP are defined in the following standards:

[YU] We hope that people find useful info. in one document.   I doubt that
someone without any knowledge about NP can collect the documents (ITU-T,
ETSI and ANSI, etc.) and sip thru them and get the understanding/feeling
about how NP/MNP is done in N.A. and Europe.  So this document is for IETF
people who don't have the telecom background to know how it works and what
may be the impacts on their works at IETF.

> bearer unrelated signalling messages.

[YU] We know how signaling is done in N.A. and Europe under NP environmnet.
We can add some brief discussions about how it is done without spending one
full section on that.  It is either done by 10-digit GTT or message relaying
(this latter one is similar to onward routing).

---

From: [email-masked]
Date: Wed, 13 Mar 2002 11:50:19 +0100

Hello James,

my general concern to the draft is that many examples for the RN coding and
the transfer of RN are listed.
>From my experience of all the NP and MNP customers of Alcatel I can say
that for every customer certain solutions for NP or MNP have to be analysed
and the detailed coding of the NP/MNP related parameters has to be defined
and checked if they all fit to the existing network requirements. It is not
so easy to provide you with detailed RN codings due to the fact that there
are so many realisations which uses sometimes different RN codings
dependent of the NP scenario, like Service Provider Portability (SPP) for
Geographic Numbers, SPP for Non-Geographic Numbers, Location Portability,
etc.
Maybe certain operators can provide you with detailed information.

Nevertheless, there is an easy way out of this situation. My proposal is
that we should use in the draft the logical terms of the NP related
parameters: Directory Number (DN), and Network Routing Number (RN). They
are used in the other standards as well (e.g. ITU-T Q.769.1).
As you can see in ITU-T Q.769.1, there are 3 different signalling methods
to map these logical terms to protocol parameters. This had been necessary
because within the ITU-T members it was not possible to get an agreement to
restrict the signalling enhancements for NP or MNP to only one solution.
This gives an impression how complicate it is to find a solution which fits
for all operators in the world. Therefore how the RN and DN are signalled
in the network and between networks is dependent on the involved operators.

For an ENUM environment it is sufficient to mention RN and DN, and as an
option the network specific parameter (network option).
That should be enough.

With regard to the complete description of all NP or MNP cases in this
draft I see the problem that, as mentioned in my previous email, some
scenarios in detailed descrption are missing, like SPP for Non-Geographic
Numbers, Location Portability, different scenarios for MNP (call related
and non-call related (e.g. for SMS)), ...
A lot of work has to be spent if the draft should reflect all scenarios in
the same kind of detailed descrption.

You mentioned in you answer that NP be realised based on "...10-digit GTT".
I think this is the realisation for U.S. I would say don't limit the GTT to
a certain value, because in some networks fewer digits could be enough and
other networks could need more digits for the GTT.

You mentioned in you answer that the bearer unrelated signalling can be
realised based on "...message relaying (this latter one is similar to
onward routing)." I do not agree that this is similar to onward routing, in
my opinion it is similar to All Call Query because every SCCP message is
analysed.

Kind regards,

Monika

---

From: "Yu, James" <[email-masked]>
Date: Wed, 13 Mar 2002 10:50:43 -0600

Monika,

Again, I want to emphasize that the purpose of the I-D is give the IETF
members an idea how NP is supported in Global Switched Telephone Network
(GSTN).  We tried to provide some "useful" information to show how NP is
done.  It took some efforts to collect the RN coding information and we are
sure that many readers may find the info. useful in understanding how RNs
vary in different countries.

We have no intention to list all the implementations worldwide and discuss
them in details.  As you pointed out, we did not describe NP for
non-geographical numbers.  Because our focus is to give a good NP overview
on geographical number.  We can certainly clarify this in the introduction. 

In terms of ENUM and NP, ENUM is not impacted by RN and DN.  It is just that
the new telephony service provider's (TSP's) NAPTR RRs for its
network-related services need to be used when NP happens and when the TSPs'
NAPTR RRs also use the same "golden tree," e164.arpa (e.g., the old TSP's
NAPTR RRs should be replaced by the new TSP's NAPTR RRs).

RN and DN do matter for iptel (TRIP) because the RN, instead of DN, should
be used for routing (e.g., check against the TRIP routing table).

So NP may impact some current works-in-progress at IETF (e.g., ENUM and
TRIP).  With a understanding of NP, one can see the potential implications
of NP on some of them.  Some may be related to RN/DN and some others may be
just that there is the new TSP to be dealt with.

In responding to your comments about non-call related signaling message
routing - the reason I said that Signaling Relay Function (SRF) was
similar/analogous to "onward routing" was because the signaling message is
first routed to the "donor network," which then relays/forwards the
signaling message to the current serving network.  Yes, 10-digit GTT is a US
implementation.  When we describe that, we'll certainly mention it as a U.S.
implementation and also mention the shorter/longer than 10 digits for GTT.
As a matter of fact, in some cases in the U.S., the application (TCAP)
message is examined to look up the DN in order to derive the RN because only
the first six digits (NPA+NXX in U.S.) of the DN are available in the global
title address info.  But it is too low-level for the readers to know.

Hope this address your comments/concerns.  This document is an
"informational" document, not a "standard track" document.  We hope that the
readers can learn the NP concept after reading the document and be able to
understand the potential implications on some of the works-in-progress at
the IETF, which is the objective of the document.

Again, thanks for your valuable comments.

James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2002 5:50 AM
> To: Yu, James
> Cc: [email-masked]
> Subject: RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn-np-03.txt>
> 
> 
> Hello James,
>

---

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 14 Mar 2002 09:00:30 +0100

Hi James,

> just that there is the new TSP to be dealt with.

Now I am confused. Is ENUM and the current works-in-progress impacted by NP
or not?

First, I think new TSP's cannot use the "golden tree" e164.arpa for NP or
other network-specific NAPTR RR's, because of the ENUM End User opt-in
principle. If the operators want to use a common tree for network-specific
RR, they may use e.g. the e164op.arpa "platinum tree"?

Anyway, if the TSP's use a "public" tree, there either needs to be a special
service and/or URI defined and registered e.g or the tel: URI is used with
additional attributes to indicate if the tel: URI is a DN or RN.

regards

Richard STASTNY
OeFEG
Arsenal Objekt 24
P.O. Box 147
A-1103 Vienna, Austria

Tel: +43 664 420 4100
Fax: +43 1 79780 13
[email-masked]
[email-masked]