Pair Identification; or, how the heck do BOC's keep track of pairs ?
Kamal
I have always wondered this, how are pair's kept track of and ID'd ? One
has a cable with hundreds or more pairs, they hit a pin out board, certain
pairs are caried along various cables until they reach the customer's
house. How does the switch map phone number's to the actual pairs and,
when various frequent change procedures need to be applied, how do they
keep track of the mess ?
Example: say Joe doe has two lines, he wants caller ID and distinctive
ringing on them. How does the BOC know which pairs to instruct ESS to add
these features ? Now say Joe Doe has lots of line noise of the line
carried on pair B, as it turns out pair B is in a cable that has alot of
water damage. To save problems they move his line to pair c. How are
these pairs identified to begin with and, when another line is pulled, how
is this Identified ? Or am I asking silly questions :-/
--
I say that this is a sophisticated form of propaganda and slavery.
You grow up hearing all about our great country and climbing up the
corporate and financial ladder to live rich full lives. Work hard, enjoy
life less, prosper financially, and die young. -- Demonika
E. E. Holling
The LEC does not apply the features to a pair, they apply them to the software controlling the port.
The port is physically connected to the cable pair.
--
---------------------------------------------------------------------------
Ernie Holling Mailto: Hol...@Intech-Group.com
The InTech Group, Inc. (610)-524-8400
Consultants and Analysts FAX:(610)-524-8440
305 Exton Commons, Exton, PA 19341
A Member of The Society of Telecommunications Consultants
The Eastern Technology Council
MultiMedia Telecommunications Association
Building Industry Consulting Service International
To receive Telecommunications FYIs send e-mail to list...@intech-group.com
---------------------------------------------------------------------------
Kamal wrote in message <68uljc$jqj$1...@news.ececs.uc.edu>...
Tony Pelliccio
In article <690129$qgn$1...@usenet76.supernews.com>, holling@intech-
group.com casts forth...
> The LEC does not apply the features to a pair, they apply them to the =
> software controlling the port.
>
> The port is physically connected to the cable pair.
Thanks Ernie. I sent him email explaining that features are all switch
side vs. line side.
This brings up an interesting point. To change a RingMate(tm) number it
only costs $3.00 but to change a main number it costs $25.00 here in Bell
Atlantic/New England. I happen to know that changing a number is just
changing an asssigned number on a port, perhaps 30 keystrokes total. Just
another example of the incumbent carrier raping the consumer. I have
heard though that BA is going to re-adjust business rates as they're
getting killed by Brooks and they're scared crapless by Cox coming online
with dialtone in the next Q or two. How I love the fact that a baby
bell is running scared is beyond mere words.
Tony
Joe Vallender
Kamal wrote:
>
> I have always wondered this, how are pair's kept track of and ID'd ? One
> has a cable with hundreds or more pairs, they hit a pin out board, certain
> pairs are caried along various cables until they reach the customer's
> house. How does the switch map phone number's to the actual pairs and,
> when various frequent change procedures need to be applied, how do they
> keep track of the mess ?
>
from the telco wire center/central office to the customer location); a
frame (a piece of equipment or structure to connect cable pairs to
switch locations); and the switch itself.
When a new cable is laid it is given a unique identification number.
It's pairs are connected to the frame in the central office in a
recorded order. When switch line equipment is added (the line cards in
the switch providing service), they are wired to recorded locations on
the other side of the frame. Then when a customer is assigned service, a
telephone number and features are assigned to a switch line card
location. That line card location on the frame is jumpered to a specific
cable pair location on the other side of the frame. All of these
locations, TN, line card, cable and pair are kept in a database(s)
maintained by the telco.
If a customer has trouble with service and the cable pair is
suspected, records identify which cable pair is being used, which are
vacant and jumpers are changed at the frame and cable terminating post
at the customer location. Of course, the records have to be kept up to
date or chaos reigns.
Christopher Zguris
>another example of the incumbent carrier raping the consumer. I have
>heard though that BA is going to re-adjust business rates as they're
>getting killed by Brooks and they're scared crapless by Cox coming online
>with dialtone in the next Q or two. How I love the fact that a baby
>bell is running scared is beyond mere words.
Talk about raping the customer - here in New York City, for business
lines, BA charges $8.95/mo _per_line_ for numeric caller ID, and
$9.95/mo _per_line_ for caller ID with name.
I was speaking with the rep for a company that makes CLID decoder
circuits, he was stunned that BA considers it two different services.
He told me the original spec is CLID with name _period_, BA decided to
seperate the two (for revenue enhancement).
Christopher Zguris, czg...@interport.net
http://www.users.interport.net/~czguris
Terry Kennedy
Christopher Zguris <czg...@interport.net> writes:
> I was speaking with the rep for a company that makes CLID decoder
> circuits, he was stunned that BA considers it two different services.
> He told me the original spec is CLID with name _period_, BA decided to
> seperate the two (for revenue enhancement).
No, the original spec was number only, and slightly different - there was
an "again" indicator if you got an out-of-area call from the same party
twice in a row.
201-332 (then a 1A ESS) was the initial field trial, and St. Peter's Col-
lege was the initial test customer. This was on a special 1A release with
prototype Western Electric decoder boxes. We might still have some of the
WECO boxes in service, though most have failed.
On the 1A ESS extra hardware (senders) were needed on the switch, with
a quantity sufficient to handle the maximum number of simultaneous ICLID
deliveries. In the field trial, the 1A delivered ICLID on *all* calls com-
pleted to it, requiring a large number of senders (201-332 had something
like 130,000 TN's on it before 201-200, a 5ESS, started taking them away).
Given that LATA 132 (downstate NY, particularly NYC and neighboring areas)
was predominantly 1A's (now undergoing a massive conversion to 5ESS-2000's)
there was a substantial hardware cost to the telco to provision the 1A's
with senders. Of course, many of the downstate 1A's didn't have SS7 and thus
couldn't do ICLID outside their own serving area.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.spc.edu St. Peter's College, Jersey City, NJ USA
+1 201 915 9381 (voice) +1 201 435-3662 (FAX)
Kamal
Hi guys ! To everyone who responded, by post or email, thanks. This
really cleared up things a lot in my mind.
Now how do multiplexed T1's change things ? Here you don't have real pairs
on the Trunks, just multiplexed channels. How do these intersect the main
frames in the CO ? I hope this isn't a dumb question :-/
Take care !
Bill Horne
czg...@interport.net wrote:
: Talk about raping the customer - here in New York City, for business
: lines, BA charges $8.95/mo _per_line_ for numeric caller ID, and
: $9.95/mo _per_line_ for caller ID with name.
: I was speaking with the rep for a company that makes CLID decoder
: circuits, he was stunned that BA considers it two different services.
: He told me the original spec is CLID with name _period_, BA decided to
: seperate the two (for revenue enhancement).
BA doesn't 'consider' these to be two different services: they ARE two
different services.
Caller ID information, which is the telephone number and presentation
bits (non-list, non-pub, etc.) passes from originating to terminating
CO along with the same SS7 messages that set up the path for the call.
Caller NAME information, however, must be obtained from the Line
Information Data Base (LIDB), which is a different process. When the
terminating CO retrieves the terminating customer's line profile and
finds Caller Name Delivery specified, it must suspend normal processing
and perform a "dip" into the LIDB for the name.
That means more traffic into/out of the LIDB, more SS7 links, associated
maintenance, and unpaid holding time on the trunk(s) involved - all of
which costs are dwarfed by the software license fees switch vendors
charge BA to allow use of the capability in the first place.
--
Bill Horne
bho...@lynx.neu.edu
Floyd Davidson
[posted and emailed]
Kamal <sout...@oz.fd1.uc.edu> wrote:
>
>Hi guys ! To everyone who responded, by post or email, thanks. This
>really cleared up things a lot in my mind.
>
>Now how do multiplexed T1's change things ? Here you don't have real pairs
>on the Trunks, just multiplexed channels. How do these intersect the main
>frames in the CO ? I hope this isn't a dumb question :-/
For identification purposes, there is no significant difference.
Without the database records it is _all_ virtually impossible to
decypher, hence tracking pairs on metalic facilities, or
tracking timeslots on T1 facilities, is exactly the same: look
it up in the database!
But the advent of computer technology has changed the database
dramatically. Once upon a time it was all done with paper and
pencil, literally. Updating cable records that showed which
pairs were cross-connected to other pairs, and equipment
assignment records which showed where equipment connections were
located on the frame and showed circuits and cross connections,
were an extremely important part of a technician's daily work.
Today, when it is done right, the technician has very little to
do with keeping records in the database!
Once upon a time the worst thing that could happen was for a
tech to make changes to cable pairs or equipment assignments and
fail to update the records. Today the worst thing that can
happen is for an engineer to design as system that requires
manual updates to track assignments! Any reasonable system will
require inputting of all required information for tracking
before the process of assignment can be completed, and then
automatically update _all_ databases with the right information.
One difficulty that many companies have is engineering economy
into the wrong part of a system design. For example, many
digital cross connect systems can be ordered with a minimal
amount of functionality, which might not include sufficient
hardware and software to keep adaquate records. I work daily
with a DCS DEX-CS1 system that only keeps a record the port
numbers for a cross connect and has no way to relate that to a
circuit number or any other external reference. We are reduced
to keeping paper and pencil style records for it! (The cross
connect is entered into one system, and the record of it must be
manualy entered into an entirely different system.) It is now
very common to find a cross connect but to not find any
reference to what circuit it is for, or visa versa. Manually
tracing it out is a waste of expensive labor. I am sure that the
cost of those records over the past 10 years has far exceeded
the cost of including that functionality when the system was
engineered and the "economy" model from DCS was ordered. (Of
course I'm also reminded that the mind set of many at the time
it was bought too, as in "Put it over there in the corner, cause
we will never have more than a few dozens of circuits that need
it anyway." Now the idea is that _everything_ goes through a
digital cross connect.
Likewise to a great degree technicians no longer even manually
lookup information in the databases. Instead the test equipment
does it automatically. Digital switching systems, digital cross
connect systems, and remote testing systems all require only one
point of reference to access the entire circuit and all of the
facilites involved. A technician might test an entire circuit
or trunk from one end to another and never bother to notice
which actual facilities are involved.
Floyd
--
Floyd L. Davidson <fl...@tanana.polarnet.com> Salcha, Alaska
Adam H. Kerman
In article <692j4p$cs6$1...@isn.dac.neu.edu>,
Bill Horne <bho...@lynx.dac.neu.edu> wrote:
>Caller NAME information, however, must be obtained from the Line
>Information Data Base (LIDB), which is a different process. When the
>terminating CO retrieves the terminating customer's line profile and
>finds Caller Name Delivery specified, it must suspend normal processing
>and perform a "dip" into the LIDB for the name.
>That means more traffic into/out of the LIDB, more SS7 links, associated
>maintenance, and unpaid holding time on the trunk(s) involved - all of
>which costs are dwarfed by the software license fees switch vendors
>charge BA to allow use of the capability in the first place.
Do Local Exchange Carriers charge each other for exchanging such information?
In case of an interLATA call, does the long-distance IXC charge the terminating
LEC anything for passing the data request along?
Terry Kennedy
Floyd Davidson <fl...@tanana.polarnet.com> writes:
> One difficulty that many companies have is engineering economy
> into the wrong part of a system design. For example, many
> digital cross connect systems can be ordered with a minimal
> amount of functionality, which might not include sufficient
> hardware and software to keep adaquate records.
A competing carrier operating in the NY Metro region (and lots of other
places) was too stingy to buy the order administration system for their
switch, so all records are maintained in an Excel spreadsheet and typed
in manually on the maintenance console. You can imagine the wonderful er-
rors that can happen due to this - I had a 216-line hunt group that had
8 numbers near the front start ringing at a brokearage firm because some-
one mistyped the prefix. And of course this carrier doesn't have anything
like CCRS for Centrex rearrangements - you have to place a request with
your sales agent and wait a few weeks, and then (from experience) it will
be done incorrectly (if at all).
Jeffrey Rhodes
Adam H. Kerman wrote:
While it is possible to send the Calling Party Name information forward,
it requires enhanced ISUP service at each switch supporting the call's
route to pass this parameter, so this technique will not guarantee
delivery. Besides, if the called number is not paying for the Name
display, who would pay the IXC for the Calling Party Name delivered by
ISUP? Enhanced Caller ID probably has no better than 50% penetration at
a LEC, alot of places probably only 10%. A LEC is far more likely to use
an AIN terminating trigger on the called line of a subscriber who is
paying for Enhanced Caller ID, to send an AIN query back to the calling
LEC (avoiding any IXC's SS7 network for transport of the query) to get
the Calling Party Name. If the Calling Party Name just happens to show
up for free, or if the Calling Party Number is marked private, then the
reverse database dip is avoided.
Which means most LECs will "let you see mine, if you let me see yours".
Failing this agreement, a LEC will use Global Title Translation of the
received Calling Party Number to access their own Reverse Whitepages
database to fill in something like "SNET", or when the Calling Party
Number is not available, but is filled instead with a trunk id,
something like "West Coast" in lieu of "Out of Area".
Jeffrey Rhodes at jeffrey...@attws.com
Steve Ligett
In article <34B3E9...@sprintmail.com>
Joe Vallender <javal...@sprintmail.com> writes:
> Of course, the records have to be kept up to
> date or chaos reigns.
And in fact, from what I've seen, number two is the winner. They have no idea
what pairs are in use, are bad, etc.
Jim Fain
On 12 Jan 1998 16:20:08 GMT, steve....@dartmouth.edu (Steve Ligett)
wrote:
That isn't true here. For the most part the first facilities at least
are in order.
Jim (JC) Fain in Charlotte, NC
To send e-mail remove "NOSPAM"
from name.