[Telecom] Reverse 911

[Telecom] Reverse 911
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.telecom  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
[Telecom] Reverse 911 Rick Merrill 01-12-2008
Posted by Rick Merrill on January 12, 2008, 10:29 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Why is R911 currently "compatible ONLY with landlines?"

We have it here in Worcester County MA, and they are
"working to get it to cover" cellphones.

Obviously, cellphones move around, so I suppose that
the technical issue is to address a cell number only
if it can be reached from specified towers.


Network Magic 20% Off NMEASY coupon code spring banner 468x60
Posted by Robert Bonomi on January 12, 2008, 6:25 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
>Why is R911 currently "compatible ONLY with landlines?"
>
>We have it here in Worcester County MA, and they are
>"working to get it to cover" cellphones.
>
>Obviously, cellphones move around, so I suppose that
>the technical issue is to address a cell number only
>if it can be reached from specified towers.

It's worse than that -- what if a given tower covers _both_ part of
the area you want to reach -and- an area you do *not* want to reach.

What about a phone that is 'roaming' in the area of the R911 call-out?
Is R911 going to make a _long_distance_ call (who pays?) to the number
associated with -that- phone?


'Landline' numbers within a particular geographic area are fairly static.
they change only when somebody adds/drops service within that area. for
any given number, the average time between changes will be measured in
_years_.`

'cell' numbers are *much* more dynamic -- average time between changes (for
any reasonably compact geographic area) will be measured in hours, *at*most*,
with a heavy skewing towards some small number of minutes. given this, the
volume of 'database updates' utterly swamps the call-out usage.

It's one thing if there's a phone-number update every 3 years, on average, for
a service that is used 2-3 times a year.

Its something _quite_ different, if there's an update every 8 hours, on
average, for the same usage.

Among other things, in the first situation, if you call out from a database
that is 'a few months old', you'll get a fairly _small_ number of 'errors',
defined as:
1) numbers called that are no longer in service
2) numbers called, at a location _outside_ the R911 call-out area
3) numbers *NOT* called, at a location inside the R911 call-out area.

Use a database updated weekly, and the error probability goes _way_ down.
Use daily (end-of-business day) updates, and you can probably count errors
on your fingers.

For the second situation, unless you have 'real-time' updates of the database,
the error rate will be several (probably _many_) orders of magnitude higher.
higher. This, obviously, requires continuous tracking of -all- powered on
cell-phones -- *not* just those that have active conversations in progress.

For GPS-based location-reporting phones, they now have to report the GPS data
with every 'poll'/'keep-alive' packet from/to the tower.

For tower-based direction-finding, multiple towers have to co-ordinate on
every phone-originated packet. This may well over-tax the capabilities of
the tower-based system -- a "Too many phones, not enough time" problem. If
so, there is no easy solution for _that_ issue.


This kind of a system (R911) really works best on an "opt-in" basis. Let
the phone owner _choose_ what areas they wish to receive emergency alerts
for. People in care-giver roles may well _want_ to receive alerts for
places where _they_ are not at, at the time of the alert. Similarly,
people at work may well want toe receive alerts about things 'at home'.
This methodology works equally well for landlines, cell-phones, and/or VoIP.



Posted by Rick Merrill on February 10, 2008, 10:46 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Robert Bonomi wrote:
>> Why is R911 currently "compatible ONLY with landlines?"
>>
>> We have it here in Worcester County MA, and they are
>> "working to get it to cover" cellphones.
>>
>> Obviously, cellphones move around, so I suppose that
>> the technical issue is to address a cell number only
>> if it can be reached from specified towers.
>
> It's worse than that -- what if a given tower covers _both_ part of
> the area you want to reach -and- an area you do *not* want to reach.
>
> What about a phone that is 'roaming' in the area of the R911 call-out?
> Is R911 going to make a _long_distance_ call (who pays?) to the number
> associated with -that- phone?
>
>
> 'Landline' numbers within a particular geographic area are fairly static.
> they change only when somebody adds/drops service within that area. for
> any given number, the average time between changes will be measured in
> _years_.`
>
> 'cell' numbers are *much* more dynamic -- average time between changes (for
> any reasonably compact geographic area) will be measured in hours, *at*most*,
> with a heavy skewing towards some small number of minutes. given this, the
> volume of 'database updates' utterly swamps the call-out usage.
>
> It's one thing if there's a phone-number update every 3 years, on average, for
> a service that is used 2-3 times a year.
>
> Its something _quite_ different, if there's an update every 8 hours, on
> average, for the same usage.
>
> Among other things, in the first situation, if you call out from a database
> that is 'a few months old', you'll get a fairly _small_ number of 'errors',
> defined as:
> 1) numbers called that are no longer in service
> 2) numbers called, at a location _outside_ the R911 call-out area
> 3) numbers *NOT* called, at a location inside the R911 call-out area.
>
> Use a database updated weekly, and the error probability goes _way_ down.
> Use daily (end-of-business day) updates, and you can probably count errors
> on your fingers.
>
> For the second situation, unless you have 'real-time' updates of the database,
> the error rate will be several (probably _many_) orders of magnitude higher.
> higher. This, obviously, requires continuous tracking of -all- powered on
> cell-phones -- *not* just those that have active conversations in progress.
>
> For GPS-based location-reporting phones, they now have to report the GPS data
> with every 'poll'/'keep-alive' packet from/to the tower.
>
> For tower-based direction-finding, multiple towers have to co-ordinate on
> every phone-originated packet. This may well over-tax the capabilities of
> the tower-based system -- a "Too many phones, not enough time" problem. If
> so, there is no easy solution for _that_ issue.
>
>
> This kind of a system (R911) really works best on an "opt-in" basis. Let
> the phone owner _choose_ what areas they wish to receive emergency alerts
> for. People in care-giver roles may well _want_ to receive alerts for
> places where _they_ are not at, at the time of the alert. Similarly,
> people at work may well want toe receive alerts about things 'at home'.
> This methodology works equally well for landlines, cell-phones, and/or VoIP.
>

Thanks for raising these points! I've forwarded them to various parties.

THe ideal would be that a reverse 911 would go to all phones in the
geographical area, including those cellphones that just happen to be
driving through the area (or visiting): "be on the lookout for a
small boy in a red jacket who may have wandered away from home or may
have been abducted..."

Does a cell tower know which phones are within its range?


***** Moderator's Note *****

Is it just my incipient paranoia, or is this a setup for voice spam?
If cellphones are made with the capability to receive an "all stations
in range" broadcast, won't hucksters buy and use unlicensed cellular
transmitters?

"This urgent traveler advisory is brought to you by the East Side
Garage at 37th Street! Welcome to New York! While you're here, check
out Elaine's restaurant and Linda's boutique and Runway 69!"


Bill Horne
Temporary Moderator

(Please put [Telecom] in the subject line of your post, or I may never
see it. Thanks!)


Posted by AES on February 11, 2008, 9:46 am
If you were  Registered and logged in, you could reply and use other advanced thread options
> Bill Horne
> Temporary Moderator
>
> (Please put [Telecom] in the subject line of your post, or I may never
> see it. Thanks!)

Dear Bill,

I think we all appreciate what you're trying to accomplish with this
"insert {Telecom]" request (not to mention appreciating your filling in
as Moderator!).

A downside, is that (for me, anyway), a lengthy list of new postings
containing a bunch of lines on different subjects with differing
formats, e.g.

-- [Telecom] Some subject . . .
-- Re: [Telecom] Some subject . . .
-- [Telecom] Re: Some subject . . .
-- Some subject . . .
-- Re: Some subject . . .

become very hard to scan for the posts one wants to read -- and also
totally messes up the threading mechanism that's so useful in many
newsreaders.

Alternative ways to do this?

1) Could you have your system automatically filter out the [Telecom]
strings in posts once you've received them (and put a standard number of
space between "Re:" and "Some subject"?

(Downside: Requires programming, and doesn't remind people to put in
the {Telecom] string.)

2) Everybody put the {Telecom] string at the _end_ of the Subject line.

(Might make lists of posts easier to read, and let auto-threading
mechanisms work OK?)

3) Require instead some similar code phrase in some other Header line?

4) Other ideas?

Thanks again.


***** Moderator's Note *****

I can filter out the [Telecom] strings, but that means those composing
replies would have to manually add them again. I think most readers
would rather not. The "Re:" prefix in replies is inserted by the
newsreader, and the number of spaces after it should always be one,
unless the original post had spaces before the subject, in which case
the post was created by a borken newsreader or an ill advised
poster. I have been manually adding "[Telecom]" to subject lines for
some posts (Hi, Lisa!), and if I put in too many spaces that's my
fault.

I don't care if the [Telecom] string is at the end of the subject
line: the logic will detect it whereever it is. Threading isn't
affected either way, since it depends on the Message-ID and
In-Reply-To headers. Sorting by Subject, however, _would_ be easier
with the [Telecom] at the _end_ of the subject line.

Requiring a similar phrase in some other header wouldn't work,
because:

A. It assumes that readers have newsreaders which preserve headers,
so that replies will _also_ have the header.
B. It assumes that news servers don't delete any headers.
C. Very few news readers have the capability to add header info to
posts or replies, especially non-standard "X-<whatever>" headers.

Other ideas:

A. Require all submitters to sign their posts with PGP/GPG, and accept
only signatures with keys on the public keyservers.
B. Require all submitters to sign their posts via X.509 certificates
issued from a well-known certificate authority such as Thawte or
Verisign. (For a free email signing certificate, visit www.thawte.com).
C. Have a special version of American Gladiator during sweeps week,
with real weapons and only spammers competing. I'd _pay_ to watch!

Bill Horne
Temporary Moderator

(Please put [Telecom] in the subject line of your post, or I may never
see it. Thanks!)


Posted by on February 11, 2008, 12:52 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
> ***** Moderator's Note *****

> I have been manually adding "[Telecom]" to subject lines for
> some posts (Hi, Lisa!), and if I put in too many spaces that's my
> fault.

Adding to the end of the subject line (as I am doing here), is the
easiest.

I would ask that you NOT filter it out, so I don't have to go back and
keep adding it when I reply to messages.


Similar ThreadsPosted
Reverse 911 March 8, 2007, 4:46 pm
Re: Reverse 911 March 10, 2007, 11:13 am
Re: Reverse 911 March 12, 2007, 8:52 am
Re: Reverse 911 March 12, 2007, 4:40 pm
Re: Reverse 911 March 13, 2007, 10:47 am
Re: Reverse 911 March 15, 2007, 12:07 pm
EAS (was Reverse 911) March 16, 2007, 12:20 am
Re: EAS (was Reverse 911) March 17, 2007, 10:44 am
Re: Reverse 911 May 2, 2007, 9:40 am
Re: Reverse 911 May 2, 2007, 9:30 pm

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map