I don't think this goes into emcom, or deployment or anything else - it's really to define an application central to push more meaningful buildout of HSMM.
Thanks to these folks for getting the party started:
I've uploaded a powerpoint requesting your feedback. This is a very early draft, call it a strawman. We'll give it a few days and then start sending it out more broadly.
Here's the powerpoint: https://www.dropbox.com/sh/0up9dj1sgnglq34/AACeEqdRyd0FBEJuYzcKIme7a?dl=0
In case you don't have powerpoint, here is an exported video:
https://youtu.be/8jSSSOx-IsU
You can send your responses via email to me at patrick@RunThisProject.com
Or, reply to this post.
Before spending too much more time I'd like to see what interest level this generates.
Thanks and 73,
Patrick KM5L
Thanks to these folks for getting the party started:
•From AREDN: K6AH, AE6XE, KM5L, KA5TYW, N8NQH,
•From DAWG-HSMM: AE5IB, KD4HNX, WB6TAE, WA7NWP, K5LXP, W2TTT
I've uploaded a powerpoint requesting your feedback. This is a very early draft, call it a strawman. We'll give it a few days and then start sending it out more broadly.
Here's the powerpoint: https://www.dropbox.com/sh/0up9dj1sgnglq34/AACeEqdRyd0FBEJuYzcKIme7a?dl=0
In case you don't have powerpoint, here is an exported video:
https://youtu.be/8jSSSOx-IsU
You can send your responses via email to me at patrick@RunThisProject.com
Or, reply to this post.
Before spending too much more time I'd like to see what interest level this generates.
Thanks and 73,
Patrick KM5L
my comments:
We are looking at TicketsCAD as a "webEOC backup" in our ARES group. It has a few challenges (ie. full offline support, etc.), but, we are trying to work thru them. We plan to use it for resource management, assignments, mapping, etc.
Also, MeshChat is becoming a key system. With it's ability to fully support and event handling mechanism (action scripts), it provide a way to integrate with other systems (ie. BPQ, Winlink, etc.)
Andre, K6AH
I think we can agree that there may not be a single "Killer Application".
Patrick, thank you for asking a spectacularly important question.
Reasonable Functional Requirements Analysis of nearly every EmComm response as managed by the responsible Served Agency will reveal where the common elements are in a current net-centric EOC work flow and is moderately well specified in the free NIMS ICS "core 4" on-line courses.
This in no way devalues the idea of encouraging or contributing to a Killer App structure for an "EOC in a Go Box" that is mission specific and coupled with permanent AREDN and Public Service infrastructure. I suspect when this process is complete it will be a very valuable set of requirements and direction re: how to accomplish any number of mission (.. or Served Agency) specific localized 'Killer Apps' .
I believe the DropBox comments by PB re: his local ARES group never being asked (tasked) to support Fire Suppression probably also fits a double digit percentage of County ARES units, just exchange 'Fire Suppression' with whatever the more immediate traditional local EmComm needs are.
To be brutally frank - I'm suspicious that some local Served Agencies entertain local Amateurs only because they have heard we can be valuable *when nothing else works* and it is on a checklist on someone's Position Description or Performance Elements.
At the other extreme there there are some very well structured, trained and disciplined ARES and RACES units that do regularly get tasked with support of many localized Disaster Recovery efforts as well as immediate provisioning of All Risk Emergency Communications till more formal Agency level EmComm resources can be brought to bear. This is the paradigm that has Amateurs gaining recognition in Auxiliary Communications Units and ICS Training regimens at State and Federal levels. Remember - many agencies have decades of experience and relatively massive Federal and State funding to effect 'Emergency Communications', and have responsibly arrived at 'what works' in their environments.
Learning how we as Amateurs can provide 'what works' for our full time Professional EmComm Managers seems reasonable and is a very high value immediate undertaking.
The one thing I believe is of similar immediate high value, along with everything else already proposed here and in DropBox comments is;
Continue to focus on packaging and presenting AREDN to both Amateurs (without whom AREDN will never be fully realized) and Served Agency Professional EmComm Managers, many of whom will never do anything but cringe hearing us talk about 'OLSR', DHCP','Port Forwarding', 'SSH', or even 'Part 97'.
BTW - PB's idea of deploying AREDN capability in support of any Science Data Acquisition efforts that might be useful in any given area makes perfect sense and I believe will go a long way to shaping a much more 'Professional' perception among Served Agency Managers in areas where they do not already rely on local ARES and RACES units. Scientists are typically not bound by Policies, Procedures and Politics (other than the Scientific Method), earning creds in that community will open doors elsewhere. SkyWarn is frequently credited with saving lives by virtue of reliable, specific, timely anecdotal weather observations.
I'm 'all in' supporting your efforts in whatever minimal way I'm able to, though I usually find myself asking questions rather than trying to answer them<g>.
My hope is we never loose focus on achieving the requisite capabilities independent of the grid and the Internet.
Achieve this and 'they' will come to us.
73, ...dan wl7coo
Hey Dan,
Wow what a set of valuable nuggets you provided there. There have been a few developments in the last couple of days that seem to positively form up the stream of consciousness on this topic. I think I already made a mistake by putting any server or tool out there, even if it was to engage a strawman. The infrastructure strawman then became the focus, whereas really and truly the focus should remain on providing an incredibly valuable service, likely in a first or near first responder status. Anyway, you're 100% right in mentioning the NIMS ICS "core 4" on-line courses - this was also mentioned in my call with K1CE today - so we should make it a priority to line up there where possible.
No matter what "business solution" we propose to solve, no doubt it will end up with AREDN as the primary network infrastructure - and growing the masses of hams who will become excited to contribute will greatly expand due to a role in saving more lives and speeding up relief. That's what it's all about.
Quick note on the pi thing. When we first started kicking around a catch phrase like "killer app" - it was really meant as a way to describe something that causes a major uptick inflection point in use. For the internet, the killer app was the web browser (my opinion, I'm talking about major inflection). For AREDN the killer app indeed can be an app or a series of apps.. but most importantly, the grand enabler will be a prescriptive protocol/process defined where emcom hams can roll-in, deliver the service quickly and then roll out once normality returns. Anyway, the mention of pi was more for the strawman, get the juices flowing - and when I thought of it I was thinking (and still do) that each stack deployed would function autonomously, then when AREDN makes the connection we have a bunch of MySQL db's synching up very quickly. Not dictating, just using the technology to describe one possible way.
While I agree that valuable tools like VOIP PBX or phones, mobile data devices, cameras and the like would be a clear win-win, I would love it if those tools are shown as in support of the prescriptive response process. As a person who does business process stuff for a living I never lead with the technology, it comes soon enough.
I'm writing too much, thanks again.
Patrick
to avoid any single point of failure, which is the philosophy of the mesh. Relatively simple GO bags can do everything decentralized, including email, file transfer, chat, telephony, video etc. Having a number of such GO bags distributed among hams homes makes it likely that at least one of them will be available
to take to a served agency when needed.
Bob W8ERD
The application hosting could also be located at hardened 24x7 tower sites. We have a big rack with a tiny toughswitch on a shelf in the radio room where as everyone else has cabinets loaded with repeater equipment. We could setup an incident site literally anywhere within 40 miles of this 4000' mountain pk reaching most all of OC, Riverside, LA, SBD counties. the incident site only needs clients and simple go-kit -- and could enable laptop or cell phones with local wifi into the mesh to access all the applications.
I've heard multiple people express concern if the "Pi" can scale sufficiently for some of the applications. Probably a thread of it's own as the dialog evolves.
Joe AE6XE
Here I go with the technology - that's the downfall of being a tech junkie I guess :)
Patrick KM5L
Joe, is there a readily available link to the specs for the PTZ Camera (22 zoom?) used to create your awesome '747 final into John Wayne' video recording? That looks like it was captured circa 10 miles from the approach end of the runway.
This is a capability 'solution' I need to learn much more about which will be a huge asset for multiple local Served Agencies given our 'ridge to ridge' population center and highway corridor distances and increasing need for rapid response fire suppression in areas with millions of drought and /beetle killed pines surrounding both.
Ditto the same capability requirement re: pretty much every County Fair security workload not to mention remote wildlife habitat monitoring and isolated structure monitoring in both urban and 'non-urban' (assiduously avoiding 'wilderness') publicly owned and managed resources.
TIA, ...dan wl7coo
Try this link: http://www.longse.com/Info/View_pro.asp?id=1078
Also, credit Don KE6BXT. This is his investment contribution at the site.
I just noticed in the spec it has a heater-blower for the cold temps. Our POE ~100' cable isn't going to support this kind of power :). I didn't notice any issues going through last winter, it can freeze at 4000' in SoCal, however.
Joe
After being fine all winter, my tower camera has taken to getting the glass globe fogged up on the shady side of the camera, during the middle of the summer. I suppose that is what the blower is for....
I think trying to find a (meaning one) Killer App will be impossible. Instead, I think one should be thinking of a suite of 3 or 4 (or more?) apps that should be developed. And then, take the Suite of Apps to your Served Agency and see what interests them.
I'm thinking the Suite could be organized over these broad lines:
1. Video
2. Data Processing
3. Voice (including voip and roip)
Video would span the spectrum from stills all the way to HD streaming video. Take your pick of something in that range that makes sense for the job at hand and the bandwidth that is available.
Data Processing would include simple text messaging all the way up to the ability to field a data center of sorts. Again, get the useful app that works for your served agency and run with it. Included in here would be situational awareness apps to convey field conditions/needs/etc. to a central location.
Voice will be the ability to carry the spoken word to a distant point. This would include simple voip calling based on ip address, a full field pbx (such as asterisk running on a raspberry pi) giving features such as abbreviated dialling based on an alias (extension numbers such as PD, FD, ARC (Red Cross), etc.), voice mail, a conference bridge. This could be packaged in its own Go Kit and tranported to a field location.
Think of a way to connect the native telephone systems of various agencies in their mobile command posts together at an incident so that these agencies will not have to rely on any of the Interop channels (VTAC, UTAC, 8TAC, etc.) Many of these phone systems have provision for an external POTS line. Supply a POTS line to this system from an ATA connected to a mesh node.
Use the AllStar image produced by WA3DSP/KB4FXC and you now have roip (radio over ip). This can link radios together (patching as used by served agencies), repeater linking or access to a radio from a voip phone. Imagine having a radio system outside (away from indoor QRM) with more effective antennas accessed from various locations in a building with nothing more than a voip phone. Finally, connect an off-the-shelf AP to a mesh node, and have your served agency officials have this pbx service on their own smart phones via a common smartphone voip apps that are out there along with radio access.
A case for a fourth line of killer apps could be developed that extends the existing infrastructure of a served agency to a field location. Again, work with your served agency to see what is desirable and possible. Using the 3 broad categories mentioned above would help organize this thought process.
When you are thinking of these apps, keep in mind some of the logistics of deploying them.
1. They must be easy to deploy and use.
2. They must have minimal support requirements. In general, the more complex you make something, the more specialized will be the support requirements to keep them running.
3. They must require minimal personnel to deploy and maintain.
4. They must work! Do lots of testing/drills beforehand and get the bugs out and needed features in.
Get the experimenters amongst us to get the imagination and make those ideas work. Then get the emcomms people to understand the apps and then work with the served agencies to get them in use.
I'm confident that solutions for local AREDN Islands will be found if the common elements of the suggestions above are focused on - providing the essentials for each island's implementation for *their* locally Served Agencies.
I know I can't crank the clock back 35 years so as to arrive here and now with a fully functioning skillset, knocking out needed, fully documented, debugged and regression tested code on a daily basis, meeting the hundreds of different app requirements each of you reading this think is most important.<g>.
That is a hint re: how much I (& I expect thousands of other Amateurs) appreciate everyone else's good work.
73, ...dan wl7coo
This really is a game of tools and features. Features are the bread and butter - the business end of our solution(s) - the tools in the stack are very important and enable the features. "The killer app" that propels AREDN is more of a "Killer System" :)
Patrick KM5L
I'm thinking that one very crucial RasPi (or similar low power, distributed, auto synching at least on the MESH side) App - even in the presence of functioning WinLink on AREDN - in some circumstances will be a bi-directional Store and Forward (with *substantial buffering* ) into HF FLDigi/FLMsg also equipped with NIMS ICS Forms as part of a generic Forms Templates capability.
Here in the Mountains, this kind of capability will be specifically functioning with mobile-portable NVIS capability at some convenient temporary mid-mile installation(s).
Instinct and emerging technologies suggest that at some point , HF, Net Centric, Automated, NVIS technology will surface as (already is?) a 'no infrastructure' SHTF backbone for National Disaster Recovery purposes both Nationwide and Regionally.
WinLink continues to have it's adherents and is key to a large percentage of effective Amateur EmComm support so it must be acknowledged as a current 'must have' capability, however - it's mandatory use of a proprietary OS 'un-leverages' potential future utility.
Perhaps WinLink's email interop capabilities can be abstracted and incorporated in an open source version of a non real time, store and forward, error checked, delivery confirmed, Forms, Form Templates, Data (ascii and binary) and unstructured text exchange with a reliable, albeit painfully slower, HF Network..........?? "ARHFNet" <g>?
73 all, ...dan wl7coo
"Every Handler Gets the K9 They Deserve"
We (my local ARES group) have an OwnCloud server instance on the web that we use to distribute files to members.
We have a mesh hosted server in the EOC (with local internet access) with the OwnCloud client that runs periodically to stay in sync with the server.
On the mesh server, we use Apache to expose the owncloud sync'd directory to the mesh so they are ALWAYS available, regardless of internet.
Winlink may be restricted on the client, but its protocol was widely published (or at least it used to be) it was essentialy a BBS protocol for communications exchange with a few add ons.
I had talked about making an Android application a number of years back that speak to a TNC (this was pre mesh being big aka like 2006) and upload data.
Really its not that hard to handle the communications protocol. The LinBQP would would be a great foundation for Winlink over mesh (and other communications over mesh) (That said yes it still needs a good cross platform GUI, but supporting Windows gets you the VAST majority of the users you need, a web based frontend gets you the remainder)
Factor in some proprietary store and forward (the next gen IP world is known as 'Delay Tolerant Networking' what they plan to use for interplanetary communications) (Give the DTN docs a read its rather interesting) (simple version: broadcast the request set to everyone in range and eventually a response gets delivered by someone back via similar methods) (more complicated methods would be better like the device known history of going into the area in question for example)
This is a very interesting and important thread ("killer apps running on MESH technologies")! Below is my initial 2 cents ...
AREDN (and other regional ad-hoc network) proponents are at a bit of a disadvantage when attempting to influence served agencies, unless they themselves are higher up in those agencies decision making processes. Adjusting formal procedures of groups like ACS/RACES, Red Cross, or the County to incorporate processes based on ad-hoc networking as a fallback mechanism should be pursued, but often are difficult to achieve without proof of concept first. Usually such proof of concepts, at least in the San Diego area (and in my experience), are done by volunteers and often by those who have background straddling both the IT infrastructure and HAM communities. That is, usually bottom up efforts, while served agency procedures are adjusted top down.
That having been said, little will change unless such proof of concept infrastructures (like AREDN and anticipated "killer" applications that would make use of it) actually get built and demonstrated. There is no guarantee, of course, that that is enough, or that adoption into EMCOMM response procedures will come (let alone, come quickly). For many decades I have been part of designing and building very high speed research networks through a local university and most senior researchers always felt that "if we build (or demo) it, they will come and use it". They did, but always much later than expected. I saw this with the first wide area 10GigE, 40GigE and now 100GigE network testbeds (usually NSF funded, often in collaboration with national or international networking consortia such as CENIC, Internet2 or GLIF). A few early adopters were always attracted, but the real acceptance and usage only came much later when commercial adopters and economies of scale came into play.
I realize the above is more of a ramble than a plan ... but I just wanted to add my perspective. Today I help manage HPWREN (http://hpwren.ucsd.edu) which provides research support for scientific instruments in the field, as well as Public Safety support for the community, hosting 100+ near real time cameras on mountain tops around San Diego county (http://hpwren.ucsd.edu/cameras/ ) and bringing Internet access to 90+ rural Fire Stations in San Diego's back country.
If it is not already clear, I fully support the use of AREDN to enhance EMCOMM capabilities in San Diego County. Andre and I are working within the Red Cross to build a proof of concept testbed and to understand and hopefully influence response procedures to accept this additional tool in their EMCOMM toolkit.
Greg, KJ6HOV
Thanks for the kind words Ron. It took over a decade to build HPWREN into what it is today ... it started around 2000 as a proof of concept project funded by NSF and grew slowly mountaintop by mountaintop as stakeholders were identified and brought in (SD County, SDGE, CalFire, various science outreach groups, other Universities etc) so that by 2006 when NSF funding went away, we had enough customers to support a recharge model to keep the infrastructure going and growing. Now, with recent research in automated detection of ignition and smoke plumes from camera images, we are getting increased buy in sufficient to be expanding up into Orange and San Bernadino Counties (Santiago Peak is next). We had 2-3 "visionaries" among the supporters, one of whom had some deep pockets and is my boss, Larry Smarr, Director of UCSD's and UCI's Calit2 institute (www.calit2.net).