Re: [earlywarning] Finishing the Charter Text Discussions

["DRAGE, Keith (Keith)" <[e-mail]>]

What I am not seeing from this extended discussion is anything that will assist in permitted deployment of this in 3GPP networks (and probably 3GPP2 networks).

The existing 3GPP cell broadcast mechanism uses spare capacity that is not used for any other purpose than cell broadcast. It is not used for point-to-point traffic. Therefore at time of government alert that capacity automatically gets used for goverment alerts at the expense of any other cell broadcast traffic, but not at the expense of other point-to-point data and voice. 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). 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.

Therefore within 3GPP networks there is still a use for directed communication whereby the cellphone is treated as an internet endpoint. This would be for the type of alerts, for example, that schools send to its pupils only indicating that their own school is closed. The rest of the population does not want these events, nor do pupils of other schools who may be in the same cell coverage area. Message identifiers are not a means of excluding this communication. Now under many usages of terminology, those situations do not comprise "emergency events" using the terms in this charter. My assumption is that such events will be defined by this charter, but that is not clear at the moment. 

Now lets consider what happens under aspects of 3GPP network stress. I believe Henning has said in the past that on 9-11, the only thing that kept working was the internet. It was not possible to make cellphone calls. A similar think happened in London on the underground bombings. Except where cellsite infrastructure itself was destroyed, what will have happened here is that the cell broadcast channel was indeed still working, but the network was so overloaded with signalling attempts that it was shedding traffic. Indeed 3GPP operators have algorithms for what traffic is shed under such circumstances. IP data, CS voice data and Voice over IP all use the same radio channels. Any of them occur at the expense of the other (although the split between CS voice usage and IP (and voice over IP) is configured.

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.

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.

In the absence of any mechanisms to identify specific traffic as essential, or to identify such traffic at all, the net result will be that all such traffic will be deemed non-essential and will not be given authority to authority priority. Conceivably, that means that there will be no alerts at time of crisis using ATOCA mechanisms because all IP communication except voice over IP, and authority to authority data has been killed. Rather than give their users a false sense of security that they will receive ATOCA alerts under times of network stress, this may well mean that 3GPP operators actively discourage ATOCA subscriptions in the first place.

If the alerts that duplicate those made using the cell broadcast service are not made in the first place, and cellphone users are restricted to targetted alerts rather than those for the whole public, then it is possible that 3GPP operators will be be able to treat ATOCO alerts differently, rather than killing everything. I don't know how we handle that in RFCs, but that should form part of the study of providing this mechanism.

Saying "let the market decide" at this point of charter discussion will therefore not result in the scenario where coexistence can occur under emergency overload. The charter needs to investigate means of enhancing coexistence with other delivery mechanisms, rather than just acknowledging that they exist.

regards

Keith


________________________________

	From: [e-mail] [mailto:[e-mail]] On Behalf Of Janet P Gunn
	Sent: Wednesday, April 07, 2010 11:03 PM
	To: SENNETT, DEWAYNE A (ATTCINW)
	Cc: [e-mail]; Hannes Tschofenig; [e-mail]
	Subject: Re: [earlywarning] Finishing the Charter Text Discussions
	
	

	I don't have a dog in this fight (and I am not even "working") this week- but I can't resist putting in my 2 cents. 
	
	1) Typically, the greatest congestion occurs close to the "edges", whether you call it "the access network" or "the last mile". 
	  
	2) There is often (but by no means always) a positive correlation between events that trigger both "citizen to authority" and "authority to citizen" messages,  and localized network congestion. 
	
	3) Any mechanism to support either "citizen to authority" or "authority to citizen" , or "authority to authority", "special" treatment should do so in a manner that does not exacerbate the localized congestion.
	
	Janet 
	
	This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. 
	NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 
	
	[e-mail] wrote on 04/07/2010 04:20:38 PM:
	
	> [image removed] 
	> 
	> Re: [earlywarning] Finishing the Charter Text Discussions 
	> 
	> SENNETT, DEWAYNE A (ATTCINW) 
	> 
	> to: 
	> 
	> ken carlberg 
	> 
	> 04/07/2010 04:21 PM 
	> 
	> Sent by: 
	> 
	> [e-mail] 
	> 
	> Cc: 
	> 
	> Hannes Tschofenig, earlywarning 
	> 
	> In regards to the comment on the first sentence, all services have to be
	> evaluated for impact before they are implemented in any live
	> environment.  However, a service that is designed from the beginning
	> with no consideration of the impacts to the access technologies is a
	> very badly designed service.  ATOCA will have an adverse effect to at
	> least some of the access technologies and if ATOCA is designed without
	> any considerations of the capabilities and limitations of the access
	> technologies, it will fail and it will cause adverse effects to the
	> access technologies.
	> 
	> The proof of network congestion already exists.  This is demonstrated
	> repeatedly as "all circuits busy" error responses, dropped calls,
	> fast-busy tones, delayed delivery of SMS messages, etc. 
	> 
	> Since ATOCA is the new communications entity beginning proposed, the
	> burden of proof is on ATOCA to prove that it will not adversely impact
	> any of the associated access technologies.
	> 
	> DeWayne 
	> 
	> 
	> -----Original Message-----
	> From: [e-mail]
	> [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf Of ken carlberg
	> Sent: Wednesday, April 07, 2010 12:48 PM
	> To: SENNETT, DEWAYNE A (ATTCINW)
	> Cc: Hannes Tschofenig; [e-mail]
	> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
	> 
	> 
	> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
	> 
	> > "The ATOCA solutions will not adversely affect the ability of any
	> access
	> > technology to provide emergency services to the citizens (e.g. 9-1-1
	> > calls) or to provide communication services to first responders or
	> other
	> > authorized emergency services personnel.  Additionally, ATOCA is not
	> > replacement solution for any authority to citizen alerting supported
	> by
	> > any access technology."
	> 
	> given the previous thread on this list, I'm a bit leery of that first
	> sentence.  But, if it were agreed to add it in, then I would expect the
	> individuals who make a claim that an ATOCA solution adversely affects
	> 9-1-1 type calls will be required to prove it instead of simply stating
	> a position.
	> 
	> as for the second sentence, that is out of scope of the IETF.  any
	> deployment of what is considered an ATOCA solution is a market decision.
	> 
	> -ken
	> 
	> _______________________________________________
	> earlywarning mailing list
	> [e-mail]
	> https://www.ietf.org/mailman/listinfo/earlywarning <https://www.ietf.org/mailman/listinfo/earlywarning> 
	> _______________________________________________
	> earlywarning mailing list
	> [e-mail]
	> https://www.ietf.org/mailman/listinfo/earlywarning <https://www.ietf.org/mailman/listinfo/earlywarning>