- Messages
- 2
- Reactions
- 0
JavaScript is disabled
Our website requires JavaScript to function properly. For a better experience, please enable JavaScript in your browser settings before proceeding.
A bit about me, and CRISIS-FORCE...
- Thread Starter CRISIS-FORCE
- Start date
- Messages
- 4,164
- Reactions
- 11,935
Welcome! You will love it here.
- Messages
- 101
- Reactions
- 77
Welcome! How do we learn more about Crisis-Force?
- Messages
- 2
- Reactions
- 0
- Thread Starter
- #5
Hi Folks! Sorry I took six months to reply... I've been fairly overwhelmed (and will continue to be for at least a couple more months) and have not been monitoring forums.
RockyC > How do we learn more about Crisis-Force?
8ball> Interested to hear... Is it based on a self organizing mesh network?
Thanks for asking! Unfortunately, there's no good way to find out more about CRISIS-FORCE right now, except what I've included below, which is more than I was planning to say (sorry about the verbosity).
With respect to whether the communications is based on self-organizing mesh networks, I would say "Yes, and No." We are using layer 2 meshes as a "virtual switch" to implement access (and access controls) -- in a manner not unlike a traditional mesh that has Wi-Fi access point capability. A layer 3 virtual mesh is used for routing between layer 2 meshes, both within a community and between communities across the country (there are also layer 3 mesh nodes that do not connect to any layer 2 mesh). The layer 3 nodes also have switch-like access to any gateways (including Internet gateways) which may be directly attached to layer 2 mesh nodes.
The links that participate in layer 3 mesh routing are implemented as secure virtual links over any/all available media (terrestrial, wireless, satellite), which generally involve gateways which know nothing about the mesh that overlays them. The intelligent layer 3 routers act in concert (something like a cluster) to perform FEC encoding/decoding and dynamically multiplex communications over the available routes according to priority, cost, link quality, link capacity, availability, latency, etc. Thus, a rural community with only dial-up lines and a few old satellite internet dishes may enjoy a usable aggregate bandwidth to the Internet, with quite a bit higher bandwidth to nearby communities (which may provide access to mutual aid even if the Internet itself has become inaccessible). To capitalize on whatever meager bandwidth may be available, every intelligent router node also provides caching, storage, proxy, and web service functionality.
CRISIS-FORCE hasn't launched its public website, but will in 2015. Our current website (crisis-force.org) only provides a place for the engineering team to log in.
When I can come up for air, I will try to make it a point to post some additional preliminary information to this forum. One problem is that we actually have too much information available, much of which cannot be presented any time soon, because the dead-ends greatly increase the "noise" and would reduce the signal-to-noise (S/N) ratio. The underlying architectural and engineering work has been in progress since 2006, and we have gained a pretty solid understanding of what approaches will NOT work. Explaining the details of that would require more resources than we have available. Fortunately, we're also zeroing in on what WILL work, so that's want we want to focus on in the information we initially release.
Also, we're not yet in a position to take advantage of volunteers (although we really, REALLY want to). As much as we would welcome all the help we can get, from multiple disciplines, we're not prepared to coordinate that effort yet, even though we feel that we are "late" and time is running out (there's a saying in the software world, "Adding people to a late project makes it later..."). We have some thorny issues we have to work out before widening the exposure of the architecture. The engineers who are doing development work right now are able to work more or less independently, because they're doing tasks that require very specific expertise, and they would be doing some of those tasks anyway.
Here are some tidbits I can tell you now. CRISIS-FORCE is a not-for-profit, but it is not yet a registered 501(c3) and doesn't yet accept donations (that should change in 2015). CRISIS-FORCE has several technology programs, each with a number of projects that will need help from people with skills. What the programs and projects have common is a technological focus on survivable infrastructure and a people-oriented focus on readiness for emergency response. The CRISIS-FORCE name bears no relationship to the video game (circa 1991), and is actually a pair of acronyms:
Communities
Responsibly
Implementing
Survivable
Infrastructure
Services
Family-
Oriented
Response to
Community
Emergencies
The various survivable infrastructure services primarily have to do with meeting physiological or psychological needs at the level of individuals, family, or community, such as those which could be described by "Maslow's Hierarchy of Needs" (air, water, food, shelter, belonging, relationship, etc.).
The CRISIS-FORCE Emergency Network (CFEN) is the first and most complex of the CF programs, because of what it can enable as a communications network, and because its mechanisms for communication must accommodate the rules of multiple federal regulatory agencies (FCC, DoJ, FAA, etc.), as well as those of state, county, and municipal governments. Moreover, some of the CFEN technological problems are quite difficult to solve in the first place, and especially difficult to solve in a way that the resulting equipment is both "survivable" and "affordable" (without government sponsorship or strings attached).
In the case of radio equipment, for example, the ancillary cost of protecting and powering the radio equipment exceeds the cost of the radios by an order of magnitude (i.e., by ~10X). Thus, survivability is not without cost. On the other hand, if a radio node for emergency communication does not survive the threat(s) which materialize (and possibly cause the emergency in the first place), then its value is zero. With much of today's radio/router gear (including what you probably have in your home), a device can stop operating correctly all on its own (e.g., due to an internal memory error, or a software bug), with no ability to fix itself, which means it certainly cannot be relied on to operate unattended in an emergency.
Most commercial communications network are designed to maximize profits in the normal case, so "survivability" tends to be designed in (or added on) only to the extent that it helps to maximize profit, which may include meeting mandatory government regulations (to avoid being shut down).
For example, after Hurricane Katrina, federal regulators mandated that cell towers have at least eight hours of backup power in case main power fails, in order to make the nation's communication system more reliable. In a regulatory filing, the FCC's view was "... the benefits of ensuring sufficient emergency backup power, especially in times of crisis involving possible loss of life or injury, outweighs the fact that carriers may have to spend resources, perhaps even significant resources, to comply with the rule." There was quite a big fight over that issue, because it could cost an average of $15,000 per site, and with 210,000 sites at the time, some carriers were saying things like, [it would lead to] "staggering and irreparable harm" (to their company). While the carriers could make good points in exceptional cases, the only point I'm making here is that the carriers will only add "survivability" if forced to, because it consumes capital and generates no profit. For the record, CFEN design goals do not consider eight hours of backup power to be enough anyway, except perhaps for portable equipment.
The design goals of CFEN are oriented in directions that tend to be opposite those which are trending in industry today. For example, CFEN is concerned with connecting as many people as possible, with each consuming only a negligible fraction of the bandwidth. In contrast, most people today are becoming accustomed to ever-increasing broadband speeds (at my house I have broadband connections with multiple carriers, the fastest of which is around 60 Mbps), so CFEN can be viewed as going the opposite direction.
As a more detailed example, on the assumption that it may be a long reach from one radio node to the next (even if directional antennas are used), CFEN would use much narrower channels (e.g., 5 MHz instead of 20 MHz) in the ISM bands (0.9, 2.4, 5 GHz) to quadruple the power spectral density, which would nearly double the range, while also cutting the basic data rate by a factor of four. In contrast, a modern 802.11ac Wi-Fi router might use a wide swath of spectrum (more than 20 MHz) to gain very high data rates, but have very poor range. To get back part of the data rate lost with narrow channels, CFEN uses MIMO for radio bands that support it, with antennas of complementary polarization (left/right circular, or sometimes vertical/horizontal). To take better advantage of whatever data rate is available, the "chatty-ness" of the protocols also has to be reduced or eliminated. Retries due to lost packets need to be eliminated through better use of multi-cast with forward error correction (FEC), and better compression algorithms need to be used for all data types.
CFEN users might also need to gain a new perspective on sound quality and latency:
1) With respect to sound quality, given a 128 Kbps channel, which is a "better" goal for an emergency network, a single 128 Kbps conversation where "you can hear a pin drop" or sixty-four simultaneous 2 Kbps conversations which sound like a good-quality portable radio, but are completely secure? The latter is the CFEN approach, using advanced low-bandwidth CODECs like codec2 in conjunction with encryption.
2) With respect to latency, which is a "better" goal for an emergency network, a "low-latency" conversation (e.g., traditional VoIP on a fast, stable link), but with with drop-outs and occasionally garbled words or even disconnections due to NOT HAVING a fast, stable link -- or, rather, a solid high-latency-but-decent-quality conversation that has the equivalent of a half-second to one-second satellite delay? The latter is the CFEN approach, which uses FEC to split up data packets and send them over multiple routes simultaneously (some routes may be very slow, and others may fail). When the communications needs to travel a long distance over potentially slow routes, a CFEN assumption is that it's better to impose an intentional "satellite delay" which allows time for buffering and collecting enough FEC-encoded packets so as to enable reconstructing the conversation completely in a non-jerky way, even though some packets might take a while (possibly hundreds of milliseconds) to arrive, and others may never arrive.
Although I would welcome any comments and inputs, it will likely be a while before I am able to get back to this forum to respond. Your patience will be appreciated.
Thank you for your kind welcome!
Dave (CFEN)
RockyC > How do we learn more about Crisis-Force?
8ball> Interested to hear... Is it based on a self organizing mesh network?
Thanks for asking! Unfortunately, there's no good way to find out more about CRISIS-FORCE right now, except what I've included below, which is more than I was planning to say (sorry about the verbosity).
With respect to whether the communications is based on self-organizing mesh networks, I would say "Yes, and No." We are using layer 2 meshes as a "virtual switch" to implement access (and access controls) -- in a manner not unlike a traditional mesh that has Wi-Fi access point capability. A layer 3 virtual mesh is used for routing between layer 2 meshes, both within a community and between communities across the country (there are also layer 3 mesh nodes that do not connect to any layer 2 mesh). The layer 3 nodes also have switch-like access to any gateways (including Internet gateways) which may be directly attached to layer 2 mesh nodes.
The links that participate in layer 3 mesh routing are implemented as secure virtual links over any/all available media (terrestrial, wireless, satellite), which generally involve gateways which know nothing about the mesh that overlays them. The intelligent layer 3 routers act in concert (something like a cluster) to perform FEC encoding/decoding and dynamically multiplex communications over the available routes according to priority, cost, link quality, link capacity, availability, latency, etc. Thus, a rural community with only dial-up lines and a few old satellite internet dishes may enjoy a usable aggregate bandwidth to the Internet, with quite a bit higher bandwidth to nearby communities (which may provide access to mutual aid even if the Internet itself has become inaccessible). To capitalize on whatever meager bandwidth may be available, every intelligent router node also provides caching, storage, proxy, and web service functionality.
CRISIS-FORCE hasn't launched its public website, but will in 2015. Our current website (crisis-force.org) only provides a place for the engineering team to log in.
When I can come up for air, I will try to make it a point to post some additional preliminary information to this forum. One problem is that we actually have too much information available, much of which cannot be presented any time soon, because the dead-ends greatly increase the "noise" and would reduce the signal-to-noise (S/N) ratio. The underlying architectural and engineering work has been in progress since 2006, and we have gained a pretty solid understanding of what approaches will NOT work. Explaining the details of that would require more resources than we have available. Fortunately, we're also zeroing in on what WILL work, so that's want we want to focus on in the information we initially release.
Also, we're not yet in a position to take advantage of volunteers (although we really, REALLY want to). As much as we would welcome all the help we can get, from multiple disciplines, we're not prepared to coordinate that effort yet, even though we feel that we are "late" and time is running out (there's a saying in the software world, "Adding people to a late project makes it later..."). We have some thorny issues we have to work out before widening the exposure of the architecture. The engineers who are doing development work right now are able to work more or less independently, because they're doing tasks that require very specific expertise, and they would be doing some of those tasks anyway.
Here are some tidbits I can tell you now. CRISIS-FORCE is a not-for-profit, but it is not yet a registered 501(c3) and doesn't yet accept donations (that should change in 2015). CRISIS-FORCE has several technology programs, each with a number of projects that will need help from people with skills. What the programs and projects have common is a technological focus on survivable infrastructure and a people-oriented focus on readiness for emergency response. The CRISIS-FORCE name bears no relationship to the video game (circa 1991), and is actually a pair of acronyms:
Communities
Responsibly
Implementing
Survivable
Infrastructure
Services
Family-
Oriented
Response to
Community
Emergencies
The various survivable infrastructure services primarily have to do with meeting physiological or psychological needs at the level of individuals, family, or community, such as those which could be described by "Maslow's Hierarchy of Needs" (air, water, food, shelter, belonging, relationship, etc.).
The CRISIS-FORCE Emergency Network (CFEN) is the first and most complex of the CF programs, because of what it can enable as a communications network, and because its mechanisms for communication must accommodate the rules of multiple federal regulatory agencies (FCC, DoJ, FAA, etc.), as well as those of state, county, and municipal governments. Moreover, some of the CFEN technological problems are quite difficult to solve in the first place, and especially difficult to solve in a way that the resulting equipment is both "survivable" and "affordable" (without government sponsorship or strings attached).
In the case of radio equipment, for example, the ancillary cost of protecting and powering the radio equipment exceeds the cost of the radios by an order of magnitude (i.e., by ~10X). Thus, survivability is not without cost. On the other hand, if a radio node for emergency communication does not survive the threat(s) which materialize (and possibly cause the emergency in the first place), then its value is zero. With much of today's radio/router gear (including what you probably have in your home), a device can stop operating correctly all on its own (e.g., due to an internal memory error, or a software bug), with no ability to fix itself, which means it certainly cannot be relied on to operate unattended in an emergency.
Most commercial communications network are designed to maximize profits in the normal case, so "survivability" tends to be designed in (or added on) only to the extent that it helps to maximize profit, which may include meeting mandatory government regulations (to avoid being shut down).
For example, after Hurricane Katrina, federal regulators mandated that cell towers have at least eight hours of backup power in case main power fails, in order to make the nation's communication system more reliable. In a regulatory filing, the FCC's view was "... the benefits of ensuring sufficient emergency backup power, especially in times of crisis involving possible loss of life or injury, outweighs the fact that carriers may have to spend resources, perhaps even significant resources, to comply with the rule." There was quite a big fight over that issue, because it could cost an average of $15,000 per site, and with 210,000 sites at the time, some carriers were saying things like, [it would lead to] "staggering and irreparable harm" (to their company). While the carriers could make good points in exceptional cases, the only point I'm making here is that the carriers will only add "survivability" if forced to, because it consumes capital and generates no profit. For the record, CFEN design goals do not consider eight hours of backup power to be enough anyway, except perhaps for portable equipment.
The design goals of CFEN are oriented in directions that tend to be opposite those which are trending in industry today. For example, CFEN is concerned with connecting as many people as possible, with each consuming only a negligible fraction of the bandwidth. In contrast, most people today are becoming accustomed to ever-increasing broadband speeds (at my house I have broadband connections with multiple carriers, the fastest of which is around 60 Mbps), so CFEN can be viewed as going the opposite direction.
As a more detailed example, on the assumption that it may be a long reach from one radio node to the next (even if directional antennas are used), CFEN would use much narrower channels (e.g., 5 MHz instead of 20 MHz) in the ISM bands (0.9, 2.4, 5 GHz) to quadruple the power spectral density, which would nearly double the range, while also cutting the basic data rate by a factor of four. In contrast, a modern 802.11ac Wi-Fi router might use a wide swath of spectrum (more than 20 MHz) to gain very high data rates, but have very poor range. To get back part of the data rate lost with narrow channels, CFEN uses MIMO for radio bands that support it, with antennas of complementary polarization (left/right circular, or sometimes vertical/horizontal). To take better advantage of whatever data rate is available, the "chatty-ness" of the protocols also has to be reduced or eliminated. Retries due to lost packets need to be eliminated through better use of multi-cast with forward error correction (FEC), and better compression algorithms need to be used for all data types.
CFEN users might also need to gain a new perspective on sound quality and latency:
1) With respect to sound quality, given a 128 Kbps channel, which is a "better" goal for an emergency network, a single 128 Kbps conversation where "you can hear a pin drop" or sixty-four simultaneous 2 Kbps conversations which sound like a good-quality portable radio, but are completely secure? The latter is the CFEN approach, using advanced low-bandwidth CODECs like codec2 in conjunction with encryption.
2) With respect to latency, which is a "better" goal for an emergency network, a "low-latency" conversation (e.g., traditional VoIP on a fast, stable link), but with with drop-outs and occasionally garbled words or even disconnections due to NOT HAVING a fast, stable link -- or, rather, a solid high-latency-but-decent-quality conversation that has the equivalent of a half-second to one-second satellite delay? The latter is the CFEN approach, which uses FEC to split up data packets and send them over multiple routes simultaneously (some routes may be very slow, and others may fail). When the communications needs to travel a long distance over potentially slow routes, a CFEN assumption is that it's better to impose an intentional "satellite delay" which allows time for buffering and collecting enough FEC-encoded packets so as to enable reconstructing the conversation completely in a non-jerky way, even though some packets might take a while (possibly hundreds of milliseconds) to arrive, and others may never arrive.
Although I would welcome any comments and inputs, it will likely be a while before I am able to get back to this forum to respond. Your patience will be appreciated.
Thank you for your kind welcome!
Dave (CFEN)
Last Edited:
- Messages
- 17,768
- Reactions
- 43,340
Welcome aboard!!!
- Messages
- 401
- Reactions
- 305
welcome glad you made it
that is a hard act to follow
that is a hard act to follow
Upcoming Events
Central Wyoming Machine Gun And Cannon Shoot
- Laramie, WY
Ladies only beginning trap shooting
- Albany, OR
Classic Sportsman Gun & Knife Show
- Monroe, WA
New Classified Ads
-
-
Trijicon AGOG 3.5x35 TA11H Red Horseshoe .223 Ballistic
- Started by gun_dude
- Replies: 0
-
-
-
Diamondback15 with prism sight and metal case of 500 rounds
- Started by mrmime
- Replies: 1
-
3 Glock 19 Ban era LE/MIL marked 15rd magazines $95 shipped- Started by aljames
- Replies: 0
-
12.5 Geissele Barrel with CMT Tano Rail
- Started by BeardedLegend
- Replies: 0
-
Staccato xl never fired with bag, paperwork and original mags- Started by AlaskinAssasin
- Replies: 0
-