[atoca] Proposal for gap analysis.

["'Mark Wood'" <[e-mail]>]

 

Friends,

 

There are some similarities and some differences between EU-ALERT/CMAS, (now
known as WEA) and IP multicasting. IP multicast has some strengths that Cell
Broadcast does not have, and some apparent weaknesses that may be either
solvable or at least we can mitigate them. I have an expert knowledge of
cellular multicast but am new to IP technologies, but learning fast. I am
humble enough to accept correction as needed. 

 

But fist, there is a step we need to take as soon as practical. 

 

After a lot of 'too-ing' and 'fro-ing', its now widely agreed that any
multicast based system would be greatly simplified by having a standard
block of addresses dedicated to the function of public warning. 

 

Now the latest version of the 3GPP standard on 023.041 V11.1, does indeed
reserve a generous block of addresses for this purpose. 

 

This would make it very easy for administrated system (AS) administrators to
open a specific block of multicast addresses on distribution routers by
default, without any worry about torrents of broadcast data flooding his
network nor worry about if the message were truly authentic (as the
government gateway guaranties this). And yet this does not preclude the
administrator from opening other non governmental gateways at the policy of
the AS if she wants to. 

 

 

Proposal 1

 

I believe that a good place to start would be to reserve a block of 255
multicast addresses, both in IP4 and IP6, for future development for
multicast based public warning systems, and other civic purposes at the
discretion of the member state.

 

 

 

Then we can take a look at two alternative protocols, and look for a good
way to emulate the geo-specificity feature of CB.

 

1.	Should we create a sort of 'Cell Broadcast over IP Encapsulation
protocol' in which cell broadcast messaging is wrapped up in a package
format suitable for transmission by IP networks, and then rely on an app at
the host to present the result to the user? There are two advantages to this
approach. Information presently created at the originator system has been
created in such a way as to respect the limitations that the mobile networks
have placed upon the emergency management community, that the message must
have less than 90 characters (80 bytes). Therefore a separate message
origination systems, separate gateways and separate trust protocol rule set
in the aggregator gateway system is not needed. Furthermore the user will
see the same message exactly and in the same format no matter what device he
looks at. All of this helps in a confused and panicky situation. The
university of Delft noted that people like to see three different
confirmations of something before they believe it. Furthermore such a small
message payload will not raise any broadcast storm worries. 

 

2.	Or should we create a separate format and protocol designed to
exploit the fact that IP networks do not have the restraints that 2G cell
broadcast systems have, and can send megabytes of data in very rich multi
media formats? The advantage would be much more functionality for the
solution, but at the cost of complexity at the message originator side
because message inputs would now become a lot more involved with many more
functions to choose from. Nevertheless I think in the future this should be
the goal, a sort of EU-ALERT V2.

 

Maybe we should work on both, as they are not incompatible with each other;
there is no problem in running them both side by side. Clearly it will be a
few years down the road before the emergency management profession are
sufficiently familiar with EU-ALERT/WEA to be confident enough with
something much more demanding.  

 

Proposal 2

 

I believe we should look at how we should create a CB over IP encapsulation
protocol. 

 

Proposal 3

 

We should look at how a more flexible public messaging multicast format
would need to be framed.

 

 

Geo specificity

 

One area of significance is that of geo specificity. CB is attractive also
because it is natively and passively geo specific (well, bluntly, but good
enough). In the present IPAWS OPEN system, the originators signal their
proposals to a gateway unit, which analyses the polygon and distributes it
to networks which have service area under the polygon. Within the networks,
a Cell Broadcast Centre (CBC) analyses the polygon and send the message only
to cells which have service area under the polygon. Since a cell is
typically about a few KM across, we have resolution down to about a
neighbourhood. *However this is normally good enough*. All this is done
passively without any position reporting, polling, data base interrogation,
paging, SS7 signalling or any network signalling at all.  

 

We need to find a way to passively emulate this.  I think it may not be as
tough as all that, here is what I propose. 

 

The administrator of any system knows the physical location of access level
switches and access wireless access points. Typically the distribution layer
of routers in located on one campus and subnets rarely cover more than one
building (at least subnets go with LANs which are normally in one building
due to Ethernet limitations). Since Protocol Independent Multicast protocol
(PIM) requires the setting up of RV points at which administrators control
access to subsequent multicast addresses and their distribution, it should
be fairly easy for an administrator to associate all of the public warning
range of multicast addresses with a collective location, such as a ZIP code
provided by a CUG at that Gateway. A development of PIM would automate this
if we know something of the location of the distribution router. Yes, it's
not rocket science, but it is way good enough for this application as it
matches the geo specificity of Cell Broadcast really quite well (in fact is
normally better). 

 

It's optional for us to use Internet Gateway Multicast Protocol IGMP,
because you can subscribe a subnet to a multicast address by informing the
Ethernet port on the distributing router that it has subscribed this subnet
to this range of addresses. So therefore IGMP may not be as big a problem as
anyone thinks. Remember that civic messages are very short (80 bytes) and
quite rare, (one every 20 minutes for maybe a few days a year). This is
trivial amounts of data so an administrator is not opening himself up to
broadcast storms by doing this as they sometimes fear, (BPDU's are much more
but no one thinks of switching spanning tree off). 

 

If someone would like to tell me what text is needed to make this an
official suggestion, I am quite ready to oblige.

 

We could not have done this before the 3GPP finished its work (this march),
but they have, so It is time to do this now. 

 

Warm regards Mark Wood DRCF.

 

PS

 

A FRIEND OF MINE RECENTLY GOT HIS VERY FIRST GENUINE REAL CMAS MESSAGE ON
HIS BLACKBERY, SO IT IS RUNNING CODE!!