Re: [earlywarning] Finishing the Charter Text Discussions

["DALY, BRIAN K (ATTCINW)" <[e-mail]>]

Actually the part in parenthesis is not speculative but law - it is part
of the WARN Act passed by Congress, and included in Part 10 of the FCC
rules.

Regarding the discussion on network stress, it is relatively easy to
stress the network in times of disaster. While the 9/11 and London
bombings may be an extreme, the more subtle cases are the Minneapolis
bridge disaster, the threat of a tsunami due to the earthquake in Chili
(which stressed the systems in SoCal when they tried to issue a tsunami
advisory). Even "benign" large scale messages such as to a college
campus can result in network stress. We have extensively studied and
modeled network behavior due to emergency situations, and the results of
these studies went into the 10 month long process developing and
optimized solution for commercial mobile networks.

The other factor is how time critical is the message - a brush fire
threat advisory is not that critical, so if it is delayed by a half
hour, hour, or several hours, no big deal. However, a tornado warning
may have only minutes of reaction time and if the message is delayed
tens of minutes to hours, then it becomes not only a useless message,
but also jeopardizes the integrity of the entire alerting system.

Actually localized alerts are as problematic - if not more than - alerts
covering a large geographic area. Wireless network are not engineered to
allow everyone to be able to access resources simultaneously - it is
based on statistical traffic modeling and historical data- the so-called
"busy hour". And the technology has limitations - for example, you can
only send 2 SMSs/second/sector as a rule of thumb. Likewise, there are a
limited number of Radio Access Bearers (RABs) available per sector, and
a limit on the number of PDP contexts that can be established at the
SGSN. So if ATOCA required users to have a PDP context established and a
push service to send the data to the device, if there are a large number
of devices per sector then you can see the congestion problem. This is
why any point to point mechanism - be it SMS, IP "push" or whatever,
will fail in alerting scenarios and why broadcast mechanisms are
required.

CMAS solves the localization of alerts that you mention as GSM has the
capability to target down to the cell site (it is an operator choice on
how fine a geographic area to deliver the alerts).

CMAS solves all the problems and use cases you mention using a mechanism
designed to take advantage of the efficiency of the "layer 2" networks.
I saw discussion that it is character limited - 90 is the real number,
not 140 as a previous post suggested. However this is only for the
initial deployment, and in the future multimedia capabilities will be
added (see the CMSAAC report).

Brian Daly

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of ken carlberg
Sent: Thursday, April 08, 2010 5:18 AM
To: DRAGE, Keith (Keith)
Cc: [e-mail]; SENNETT, DEWAYNE A (ATTCINW);
[e-mail]; Tschofenig; [e-mail]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Keith,

first, thanks for the well thought out comments.  I agree with a number
of specific points you made (which are snipped out), but other things I
find some disagreement with...

> However this usage is only good for broadcasting to all users within
the cell that have turned on that type of alert (with varying degrees of
optionality - the US government may not allow you to opt out of a
presidential alert except by turning your phone off).

ouch, the part in parenthesis is quite speculative, at best.

> Note that cell broadcast is not the same as IP multicast - it happens
at the levels below IP. IP multicast in cellphone networks will normally
result in multiple point-to-point communications. Potentially MBMS could
be used if deployed to support IP multicast, but that still uses the
same traffic channels as other voice users.

agreed, but lets not constrain our view to just the UE->tower.  Parts of
the backhaul can be prone to congestion as well, and in a direction of
LTE, more components will be IP based and thus taking advantage of a
layer-3 tree distribution structure.

> I believe Janet is correct that emergency alerts happen at times of
network stress. Even if the incident to which they relate is not
generating traffic in its own right, I suspect the first response to
receiving a flood alert is to pick the phone up and call the remainder
of your family to check what precautions they are taking, thus resulting
in additional network traffic.

I would disagree with the above assertion.  From what I've gathered, its
only a small subset of alerts that happen at times of network stress.
Clearly the 9/11 attack and the London bombings are the most acute
instances of an event that grabs a lot of attention and subsequent load
on networks.  However, existing systems send alerts quite often that are
localized and do not automatically correlate to network stress.  

A few years ago, I spoke with several local county emergency management
directors along the I-95 corridor in the North East U.S., and their
day-to-day concern isn't focused on terrorism or natural disasters, but
rather on hazardous materials on the highways.  Their interest is in
using mechanisms like inverse-911 and localizing the alerts.

As a different example, a friend of mine in DC received an alert on his
cell phone yesterday of brush fire warnings -- not that a brush fire
existed, but that the conditions were favorable for one to occur.  And
there certainly wasn't any corresponding stress on the cell network. 

> Therefore it is likely that 3GPP network operators have to shed
traffic when major alerts are being given. Certain traffic is tagged as
having special handling on the wireless part (emergency calls and
authority to citizen / authority). There are two aspects to this:
> 
> -	Can they identify non-essential traffic and discard a larger
proportion of this as opposed to essential traffic.
> 
> -	Can they ensure that traffic is not duplicated in the first
place.
> 
> In regard to the ATOCA proposal given above, neither of these are
dealt with in the charter.

My concern about the above position is that it places a requirement on
ATOCA to assume that something in layer 2, or some walled garden, exists
and is *deployed*.  I think all of us are in agreement with the point
that Dave Oran made a while back that its ideal to take advantage of
mechanisms that can optimize ATOCA solutions.  But we need to be careful
in assuming that the specification of other mechanisms does not
guarantee their deployment.

-ken 
_______________________________________________
earlywarning mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/earlywarning