How many paths for ported-out numbers?
xx-g...@telefog.com
them in its California tariffs) for
remote-call-forwarding numbers and how they
differ from "paths" for ported numbers.
First, here's my understanding of RCF paths.
Standard ATT residential remote call forwarding
service ($17 per month) will permit only one call
to be forwarded at a time; any additional calls
made to the RCF while a call is already in progress
will get a busy signal. ATT would say that this
RCF service has one "path." An RCF subscriber can
subscribe to additonal paths for $17 each per
month. So for roughly $85 per month, the RCF
service could have a total of five paths. (The
pricing and path particulars are the same for
business RCF service.)
I wonder whether ported numbers are similarly set
up. For example, say that for my business I
have the Verizon Wireless cellular number
343-999-5050 (fictitious area code for this
example), and the business grows such that I
convert the Verizon Wireless number to a landline
and make it the head number of a five-line hunt
group. Of course, this five-line hunt group would
accommodate up to five inbound calls at once, but
because all of the calls are routed to me via a
Verizon Wireless switch, I'd guess that my
quantity of simultaneous inbound calls via
999-5050 would be determined by how many paths
Verizon Wireless establishes for my number on
their switch. And if Verizon Wireless gives
999-5050 only one path, 999-5050 would be much
less useful to my business.
So my question is this: Do FCC rules or state
regulations say that any company (of any type:
cellular or CLEC or ILEC) that owns a switch
must provide an adequate or minimum quantity
of call paths for a phone number that has been
ported out from the switch and is now receiving
a volume of calls that would require the
additional paths?
(I'm not in the telecom industry, so please
correct any errors or misconceptions that
you see in my text above.)
***** Moderator's Note *****
I don't think any restriction applies on a
ported-out number: your old wireless switch
would almost never know the call existed.
When you port a number out, from any kind of
switch, the number goes in the national
database of ported tn's. Then, when someone
calls that number, the _originating_ switch
will "dip" the database, and obtain the
routing number associated with you _new_
serving central office. The originating
switch then routes the call as it would any
other, and no interaction with your _former_
central office is needed.
Bill Horne
Temporary Moderator
John Levine
>***** Moderator's Note *****
>When you port a number out, from any kind of switch, the number goes
>in the national database of ported tn's. Then, when someone calls
>that number, the _originating_ switch will "dip" the database, and
>obtain the routing number associated with you _new_ serving central
>office. The originating switch then routes the call as it would any
>other, and no interaction with your _former_ central office is
>needed.
Right. When they were figuring out how to implement portability, one
of the alternatives they considered and rejected was one that did it
by call forwarding. As Bill notes, LNP completely removes the former
carrier from the path of calls to a forwarded number. This was a good
move, since if they had routed calls through the old switch, carriers
would have an incentive to make calls to ported away numbers work as
poorly as possible.
Rick Merrill
When numbers are 'routed', how are they routed? Is there some other
way to represent where a number "goes"?
Robert Bonomi
The answer to that gets -complicated-.
Before 'portability', each telco maintained a list of where ad *WHO* they
handed off calls to any given NPA and/or NPA/NXX to. If the call didn't
terminate 'locally' in the telco's network, they would consult the routing
list, and see who to hand it off to. *THAT* carrier was responsible for
delivering it to the proper called party.
With 'portability', it is no longer practical or each telco to keep a
static list of the required hand-offs. THEREFORE, a national database
was set up that contains records for all ported numbers -- the number,
and the telco that services it.
This database is available for *real*time* querying by dial-tone providers.
With that schema in place there are three possible ways that call routing
can be done:
1) *every* number is in the database -- an 'inconsequential' detail is
whether all numbers expressly enumerated, or whether there is provision
for a 'default' for blocks of arbitrary size.
Then, at the beginning of every call, the caller's "swith" does a
database 'dip', to see what carrier to route the call to.
2) ONLY 'ported' numbers are in the database. A 'dip' is done during
initial call set-up, and if =that= query returns "no match", the old-
fashioned 'static' list is consulted, and the call routed according to
_that_ data.
3) As in 2), only ported numbers are the database. Procedurally,it is
different -- the calling switch consults the static list *first*
and starts a call toward that destination telco. *IF* that telco
says 'not mine', *THEN* the database 'dip' is done to find the proper
carrier.`
Whichever method is actually used, the information required to hand off the
call to the appropriate destination phone company is acquired and used.
Every telephone company has a database of 'what phone number is associated
with what wire-pair (or logical equivalent) out of which central office".
It was just a SMOP ('small matter of programming') a little more
'generalization' to that database, and the 'look-up' logic so that
the number was no longer required to b in minimum-sized 'contiguous'
block of numbers.
Either the number exists on the telco system or it _doesn't.
If it does, the line gets rung.
If not a 'not in service,' or a 'not mine' is propagated back to
the calling switch, for it to decide to try alternate routing, or
abandon the call attempt.
John Levine
>>way to represent where a number "goes"?
>
>The answer to that gets -complicated-.
>
>static list of the required hand-offs. THEREFORE, a national database
>was set up that contains records for all ported numbers -- the number,
>and the telco that services it.
Well, sort of. There are still static tables that map each NPA-NXX to
a switch. In some areas, they suballocate NXX by thousands so
222-1XXX might be on one switch and 222-2XXX on another.
>With that schema in place there are three possible ways that call routing
>can be done:
> 2) ONLY 'ported' numbers are in the database. A 'dip' is done during
> initial call set-up, and if =that= query returns "no match", the old-
> fashioned 'static' list is consulted, and the call routed according to
> _that_ data.
That's what they actually do. The database maps each dialed number to
a routing number. For numbers that haven't been ported (most of them)
there's no entry and the routing number is the dialed number. For
ported number, the routing number is one that is assigned to the
switch. A confusing part of this is that as the call is routed and
delivered, both the dialed and routing number are passed along, so
it's fine to use the same routing number for all calls to a given
switch.
There's actually a database per LATA (perhaps several in really big
LATAs). For intra-LATA calls, the originating switch does the
database dip. For inter-LATA calls, the IXC does the lookup at its
tandem in the terminating LATA. This setup avoids having every switch
in the country have to know how to look up every number in the
country; the switch just has to be able to route intra-LATA and
default to the appropriate IXC tandem for inter-LATA calls.
RFC 3482 has a good description of this whole process.
Rick Merrill
>In article <fZSdnZimKMniCJPa...@comcast.com>,
>Rick Merrill <rick0....@NOSPAM.gmail.com> wrote:
>>When numbers are 'routed', how are they routed? Is there some other
>>way to represent where a number "goes"?
>>
>
>The answer to that gets -complicated-.
>
>handed off calls to any given NPA and/or NPA/NXX to. If the call didn't
>terminate 'locally' in the telco's network, they would consult the routing
>list, and see who to hand it off to. *THAT* carrier was responsible for
>delivering it to the proper called party.
>
>static list of the required hand-offs. THEREFORE, a national database
>was set up that contains records for all ported numbers -- the number,
>and the telco that services it.
>
>
I helped build the Stratus system that gives 99.999% uptime to the
national database, but I never learned (nor needed) how a "telephone
company" is addressed - e.g. do telco have IP numbers?
***** Moderator's Note *****
Telco switches use the SS7 packet data network for this and most other
call routing chores. The core protocols of SS7 predate the Internet,
and there are more differences than similarities.
Each switch and node is assigned an SS7 identifier, analogous to an
Internet Protocol address. There is no DNS capability, since there
are no logical equivalents to the domain name system in SS7.
Bill Horne
Temporary Moderator
Paul Timmins
wrote:
> Date: 12 Oct 2007 07:33:02 -0000
> From: "Robert Bonomi" <bon...@host122.r-bonomi.com>
> To: edi...@telecom-digest.org
> Subject: Re: How many paths for ported-out numbers?
> Message-ID: <13gu8pe...@corp.supernews.com>
> >>> I wonder whether ported numbers are similarly set up.
> >>
> >>
> goes
> >>> in the national database of ported tn's. Then, when someone calls
> >>> that number, the _originating_ switch will "dip" the database, and
> >>> obtain the routing number associated with you _new_ serving
> central
> >>> office. The originating switch then routes the call as it would
> any
> >>> other, and no interaction with your _former_ central office is
> >>> needed.
> >>
> >> Right. When they were figuring out how to implement portability,
> one
> >> of the alternatives they considered and rejected was one that did
> it
> >> by call forwarding. As Bill notes, LNP completely removes the
> former
> >> carrier from the path of calls to a forwarded number. This was a
> good
> >> move, since if they had routed calls through the old switch,
> carriers
> >> would have an incentive to make calls to ported away numbers work
> as
> >> poorly as possible.
> >>
> >>
> >
> other
> >way to represent where a number "goes"?
> >
>
> The answer to that gets -complicated-.
>
> Before 'portability', each telco maintained a list of where ad *WHO*
> they
> handed off calls to any given NPA and/or NPA/NXX to. If the call
> didn't
> terminate 'locally' in the telco's network, they would consult the
> routing
> list, and see who to hand it off to. *THAT* carrier was responsible
> for
> delivering it to the proper called party.
>
> With 'portability', it is no longer practical or each telco to keep a
> static list of the required hand-offs. THEREFORE, a national database
> was set up that contains records for all ported numbers -- the number,
> and the telco that services it.
>
> This database is available for *real*time* querying by dial-tone
> providers.
>
> routing
> can be done:
>
> 2) ONLY 'ported' numbers are in the database. A 'dip' is done
> during
> initial call set-up, and if =that= query returns "no match", the
> old-
> fashioned 'static' list is consulted, and the call routed
> according to
> _that_ data.
>
> Every telephone company has a database of 'what phone number is
> associated
> with what wire-pair (or logical equivalent) out of which central
> office".
>
What happens is close. In most switches, you build the manual routes for
each NPA/NXX in your local area (since you hand off long distance and
local long distance to the customer's choice of long distance carrier
this may be yourself, but in the case of an ILEC, it often is not).
In those route tables, there is a flag that says whether the prefix is
ported or not. If any numbers in the npa/nxx are ported (or thousands
block pooling is done), then the block is marked portable.
If the block is not portable (blocks allocated to paging providers
aren't portable, for example) then you just route the call like the old
days. If the blocks *are* portable, you need to set that flag.
If the portable flag is set, you do an IN or AIN dip to (one of) the
regional LSMS, which stores a real time copy of the LNP activity in the
region. (When you port a number, it is done with a group called the
NPAC, or Number Portability Administration Center. As soon as the port
is activated in their system, an update is triggered to the regional
LSMSes to update their copy of the LNP database to reflect the ported
number information.)
The LNP query, or dip, as it's called, will reply with either an LRN, or
the number you searched for as the response. If the reply matches the
number you searched for, the number is NOT ported, and you may proceed.
If you get something other than that, you route the call as IF you were
routing to the LRN, but when you actually send the call to the selected
carrier, you send them the original number that was dialed (and a flag
saying the call already had an LNP dip done on it, and here's the LRN,
as well as a local npa/nxx of yours in the JIP field, for billing
purposes, so they know what provider they owe for dropping off the call,
but I digress.)
So for example, if you call my cell, 248-379-7***
You look up 248-379 in your routing tables.
Seeing that the prefix is portable, you trigger an AIN query over SS7 to
the regional LSMS. It replies back with the LRN of 5179029788 (which is
the actual result if you were to do this with my unredacted phone
number! (don't worry, you can't call me using that information)). The
original prefix belonged to the old nextel. The 517-902 prefix belongs
to the local Sprint PCS switch. So the switch then looks up the route
for 517-902-9788. Using the selected route, (we'll say, for example, you
hand it to the Verizon tandem in Adrian, which wouldn't be an
inappropriate choice in this circumstance), but you hand it over with
the original source and destination number, along with data indicating
"I already dipped this and it's headed to sprint pcs". Then the verizon
tandem sends the call to Sprint PCS, and my phone starts ringing.
If you were call the next number above mine, the above procedure would
be done, except the LRN returns the same thing as the number you looked
up, so you'd just send it to nextel in the standard way, and that guy's
phone would ring.
If a nextel customer calls me, there's a TAT trigger assigned to my old
number in nextel's switch. This tells the nextel switch that it needs to
do an LNP dip since I'm not really a nextel customer anymore (otherwise
it would be confused since I clearly have a nextel phone number). It
follows the same process, determining I'm on sprint PCS now. Since
nextel and sprint PCS are basically the same company now*, there's
likely some direct trunking between their switch and sprint's, and they
would just use that to route the call between each other seamlessly.
* company naming nonwithstanding, they still have mostly completely
seperate infrastructure for the CDMA based Sprint PCS than they do for
the legacy IDEN based Nextel. (And yes, AT&T/Cingular/Whatever is much
the same way as well)
Congratulations for making it this far without falling asleep. :)
-Paul
Fred Goldstein
<bon...@host122.r-bonomi.com> wrote,
>>When numbers are 'routed', how are they routed? Is there some other
>>way to represent where a number "goes"?
>>
>
>The answer to that gets -complicated-.
>...
>With that schema in place there are three possible ways that call routing
>can be done:
There's actually one method that's used.
> 1) *every* number is in the database -- an 'inconsequential' detail is
> whether all numbers expressly enumerated, or whether there is provision
> for a 'default' for blocks of arbitrary size.
> Then, at the beginning of every call, the caller's "swith" does a
> database 'dip', to see what carrier to route the call to.
> 2) ONLY 'ported' numbers are in the database. A 'dip' is done during
> initial call set-up, and if =that= query returns "no match", the old-
> fashioned 'static' list is consulted, and the call routed according to
> _that_ data.
> 3) As in 2), only ported numbers are the database. Procedurally,it is
> different -- the calling switch consults the static list *first*
> and starts a call toward that destination telco. *IF* that telco
> says 'not mine', *THEN* the database 'dip' is done to find the proper
> carrier.`
[moderator snip]
Before LNP, a local phone number was an address, and routing was
based on NPA-NXX, and could be determined from the LERG (then the
Local Exchange Routing Guide, now formally the more redundant LERG
Routing Guide, both Telcordia trademarks). Now, though, a phone
number is usually not an address but a just name, a human-readable
string of digits. And a name needs to be looked up to turn into an address.
The LERG lists all NPA-NXX codes; two of the (many) flags associated
with each are whether or not it's portable or pooled (assigned by
blocks of 1000). Most codes nowadays are portable. If a code is not
portable, then its numbers are still addresses, and won't be in the
LNP database, so you can route on them.
If an NPA-NXX code is portable or pooled, then the "N-1" (one hop
away from the destination) switch -- any switch that may connect
directly to the switch that nominally owns that code -- has to do a
database lookup to see where the number actually is. Sometimes
carriers will dip all calls anyway, even long distance calls, but
it's the N-1 switch that has to have the database results. A tandem
switch is the most common N-1 switch. If a small CLEC or wireless
carrier sends all of its calls to the tandem, then it doesn't have to
dip. But once a switch starts carrying any serious amount of
traffic, it needs to establish direct trunks to its top destination
switches. So it's an N-1 carrier for those switches. The point is
that you shouldn't send a number to an end switch that the number has
been ported away from -- that's an error, and either the switch owner
rejects the call or (more common for Bells) they handle it but apply
a special surcharge.
If the number has been ported, then it will be in the database, which
will return the Location Routing Number (LRN) of the switch that
actually has the number in question. (If it hasn't been ported, I
think the database returns the queried number as if it were the LRN,
which means it really does get routed on the NPA-NXX.) An LRN is one
particular 10-digit number that each switch has, technically making
it the address of the switch. So the N-1 switch routes a ported call
to the LRN of the call, based on the LRN's NPA-NXX, and passes along
the 10-digit dialed number to that switch.
Number pooling is what has prevented the huge proliferation of area
code splits that preceded it. Nowadays numbers are assigned by the
thousand, not full NXX. Most new prefix codes and many old ones are
pooled, enabling different carriers to assign numbers from it. So an
NPA-NXX nowadays designates a rate center, but not even a switch or
carrier. Pooling is implemented via the LNP database. When a
carrier needs a block of numbers to assign to new subscribers in a
given database, it's more likely than not to have to pull a pooled
block. All pooled numbers are in the LNP database. So an N-1 switch
doesn't have to worry about thousands blocks; switches really only
need to worry about NPA-NXX. Each NPA-NXX has a single "A" block
owner, the carrier that initially owned it. LRNs are always taken
from an A block. So a new switch needs one new NPA-NXX code,
regardless of the number of rate centers it serves, so its LRN can be
on that A block; all but that code's one rate center can be served
via pooled blocks.
>Every telephone company has a database of 'what phone number is associated
>with what wire-pair (or logical equivalent) out of which central office".
The database is not held by each phone company. It's operated, under
FCC contract, by Neustar. Telcordia is now asking the FCC for a
share of that business. The cost is recovered via a small charge for each
dip.
>Either the number exists on the telco system or it _doesn't.
>
>If it does, the line gets rung.
>
>If not a 'not in service,' or a 'not mine' is propagated back to
>the calling switch, for it to decide to try alternate routing, or
>abandon the call attempt.
Good try but that's not it. In fact, many A-block switches don't
even exist any more. Many CLECs have tanked. But the numbers ported
or pooled away from them still work.
--
Fred Goldstein k1io fgoldstein "at" ionary.com
ionary Consulting http://www.ionary.com/
Justa Lurker
> I helped build the Stratus system that gives 99.999% uptime to the
> national database, but I never learned (nor needed) how a "telephone
> company" is addressed - e.g. do telco have IP numbers?
>
> ***** Moderator's Note *****
>
> Telco switches use the SS7 packet data network for this and most other
> call routing chores. The core protocols of SS7 predate the Internet,
> and there are more differences than similarities.
>
> Each switch and node is assigned an SS7 identifier, analogous to an
> Internet Protocol address. There is no DNS capability, since there
> are no logical equivalents to the domain name system in SS7.
>
Google for "SS7 point code" and you will find lots of details. Hope
this helps.
Rick Merrill
As VoIP services expand, won't that put a strain on the 24 bit point codes?
***** Moderator's Note *****
I _started_ to write "No", because I'm used to thinking of VoIP
switches as PBX's that subtend a "real" central office, and which
therefore don't have SS7 connectivity.
But, you bring up a very interesting question, and I'll ask the
Digest's readers to respond. Claude Shannon once said that bandwidth
and switching balance each other, i.e., that more bandwidth means less
switching, vice versa.
So, the question: will Internet, or other , bandwidth ever become
plentiful enough that it obviates the need for a traditional
circuit-switched PSTN? What form will the "new" telephone network
take? Who pays? Who wins? Who loses?
Bill Horne
Temporary Moderator
Raqueeb Hassan
> The database is not held by each phone company. It's operated, under
> FCC contract, by Neustar. Telcordia is now asking the FCC for a
> share of that business. The cost is recovered via a small charge for each
> dip.
Hi,
Are all calls needing to lookup real-time (all call query, ACQ) to
that selector database? Where are those reference and query databases
located? Or all CSPs and TSP's have their own edge DB replicated to
NeuStar. I know it won't happen, but what kind of redundancy is being
maintained in NeuStar, because it will be mess if that is down? Are
STPs for legacy network based on hosted service or operator based?
What kind of revenue sharing model NeuStar has with all the telcos? It
sounds pretty complicated. Where do I get more details on that,
please? Thanks in advance.
--
Raqueeb Hassan
Bangladesh