The Golden Gate gains life - with IoT

What is IoT?

Many people think, IoT means to connect Things as stupid stuff to the Internet. For me, it is
even more then this: Things can create an Inter-Networking with each other, they can cooperate and build
their own Inter-Net.

To connect stuff to our Internet is easy, but how to let sensors, actors, dead things inter-work with each other without our Internet?

Going to the Internet in order to do post-processing of aggregated data there is also easy, obvious. The main reason is
often: we have the Cloud Computing applications and computing power there. And we are familiar with hierarchical structures.
But why not to convert a dead object, a Thing, into a living object, a body which can interact with the
other parts of its body. Make such body capable to talk to us, telling us about its health. For instance, such Thing can ask for attention when sick, Why not? The step talking to the Internet is the last one because we as consumers and masters are there. Before, the IoT objects will do much more inter-net-working by its own.
The Internet is just a means to communicate, how and between what is not relevant. All my cells in my body are an
Internet, even my brain will not get notice of it completely. Many operations are done without my main processor.

My favorite example and illustration is the following:

Imagine: all the bolts on the Golden Gate Bridge. If I put on every bolt a sensor which can measure forces,
deformation, the degree of corrosion ... And if all these sensors talk to each other ... I cannot configure such a network,
I cannot bring all the sensors as separate devices to the Internet, no way. Instead, such sensor network has to configure itself, find out
what is my neighbor in order to find a route to a gateway. And the gateway is the final point to go to the
Internet because the collected data is processed there. The most important part is: how can all the sensors operate independently without the Internet, build their own Inter-Net?

If a maintenance person will drive with a car through the Golden Gate Bridge - the nearby sensor will realize when the
Gateway function is needed in order to connect to the car. The node near the car will take over the role of the Gateway. And the bridge will tell the driver in the car what the health condition of the bridge is,
where a bolt is in trouble, where the next maintenance should be done first.

A dead object becomes alive. And such a body can ask for attention. And via the Gateway the maintenance
staff can ask where the problem is, never mind how many new sensor devices were installed before or how the bridge internal network really looks like.

What do we need? Answer: an Inter-Net between all the nodes, a meshed network, smart routing so that important information
can travel from any sensor node to the appropriate gateway. And the network must configure itself: People cannot specify how it would look like if all sensers
would be mounted at the bolts, if sensor nodes would be add later, anytime. And where is the Gateway, from which direction the car will come?
The bridge will have several potential gateways, but why all must be active if not any maintenance car is there?

The bridge as a Thing becomes a living object, a body. It can tell the operator about his issues. It builds its own Inter-Net and connects in a flexible way to our Internet. This body can tell us his health.

What is Swarm Networking?

Now you get a clue: the sensor network on the Golden Gate Bridge will be huge, so many sensors, and all sensors are meshed. Such a network will
be installed in steps, new nodes will be added, some sensors will be active just on demand, e.g. after heavy rain, some nodes have additional features
and can take a temporary specific role, e.g. as a Gateway or Hub.

An operator will not be able to configure such a wireless sensor network, and there should not be a need to do so. The network should configure
itself: nodes will discover what their neighbors are, how to find a route through the network for messages and where can the traffic come in from or
go to the Internet (Cloud Services). Also possible to have more then one of such a Gateway: different regions of the swarm might use their more local
Gateway instead to flood the Swarm with traffic crossing it from one end to the other.

There are some simple constraints for a Swarm Network:

no central intelligence, no central hub nor management instance with a complete system view

simple functionality of the nodes, simplified information management in nodes, e.g. every node will just interact with ten neighbors

self-organization: due to neighbor relation and sub-swarm (cell) based operations the sensor network becomes a living object

nodes can figure out by trial-and-error, self-learning, what is the optimal route for traffic between nodes, through the swarm

information gathered, stored and used will fade away: nothing is static, nodes not visible anymore will disappear even from management
information tables, the nodes in a swarm will forget, have just short term storage which needs frequent refresh and update in order to stay
available and trustful

the traffic through such a Swarm Network will use fuzzy information items, pheromons: a route with more reliable parameters, without
congestions will be used by figuring out as the most likely used one, they smell still promissing

A Swarm Network should use Collission Avoidance instead of Collission Detection

A routing or any protocol in a Swarm Network should not use any Broadcast approach (avoid congestions and flooding)

A Swarm is a collection of nodes with quite simple functionalities. The entire organism will be more as the sum: it will be able
to perform much higher complexity compared to a node would be able to do. A central node used in a contrary approach would limit
from the beginning the entire swarm
capabilities. It creates also a single point of failure or congestions. Any extension of the swarm would need an extension of the central node as well.

An interesting aspect is the relationship between neighbors: not the neighbors close to each other, with strongest signal seen (located nearby),
as a geometrical region, e.g. a sub-cell as a circle or rectangle spanning around nodes - this cannot be the key concept of a swarm.

Instead, nodes will pick their neighbors in a bit random way, combined with the use of the statistical, fuzzy information items. The geometrical structure is not fix or regular. Instead, such sub-swarm will build
another meshed structure, a swarm cell. And two representatives of two different swarm cells will create also a neighbor relationship, creating an
inter-swarm link. So, the sub-swarm will build
a larger swarm. And if a relation will break, e.g. a node will disappear, it will be switched off or goes to sleep because it is not needed. The nodes
will try to rebuild the swarm structure frequently new again. A swarm does not rely on even currently working structures, it will try to improve all
the time, nothing is static or assumed as fix. A relation (link) has a statistical behavior, can get strong or weaker if used more often, or it fades
out automatically.

Or: a swarm is a meshed self-organizing structure of swarm cells, using the same approach and methods for inter-swarm-cell relations (links).
You could think about many levels of sub-swarms. So, the complexity remains always small and easy to manage.
Zoom in or out on a swarm - you find the reuse of the same organization approach and basic functionalities again,
similar to a Mandelbrot Set.

Therefore, a very reliable hierarchically meshed, dynamic network structure will be established, with self-learning, self-healing.
The network can re-configure itself, depending on the current situation and needs.

In a swarm the nodes are not just simple, they can change their role, on demand. For instance every node will be part of the same network with role as
a sensor/actor or hop node. But if they can provide also Internet access: their neighbors can figure out and make use of it. They can trigger another
nodes to let change their role. Due to the demand that traffic has to leave or
come in from Internet, such a node will change the role as Hub and support the swarm with this new, but temporary role.
If no access to Internet possible or needed then such nodes fall back
to the regular role as simple Hop-by-Hop node, supporting again the swarm in the best way.

So, the main aspects for a Swarm Network is to keep nodes simple, deal with distributed, but limit set of information, swarm cells, micro-cells,
statistical and stoachistic operations. The more decentralized and autonomous the swarm can operate - the more reliable and capable to adapt
to the needs and higher complexity, automatically. And the scalability is not limited by the limited resources and capacities of a specific, central node.

The meshed structure in a Swarm Network is not a full mesh, not every node with every other node. It is more a hierachical structure,
a tree of meshed structures. A Swarm will be able to fall apart, e.g. a link between sub-swarms has to be cut due to an interference
from the outside. But it can reconnect to the big swarm anytime again, eventually via other neighbor relations,
on other corners of the swarm. The number of inter-connections is limited and easier to manage and to re-establish:
always just via maximal ten relations or links, ten information items to manage in swarm nodes,
on every level and every node. Nothing in a Swarm needs a higher complexity then this.

What is Long Range?

The currently used technologies for wireless IoT solutions are Bluetooth LE (BLE) and WiFi.
Both can be considered as Short Range. Even when designers are working on long range versions, they remain quite short range.
Due to the issue that very high frequencies are used, e.g. 2.4 GHz, they need still Line Of Sight between the nodes.
It cannot penetrate walls, deal with obstacles or multi-path receptions, e.g. due to reflections,
caused by buildings in cities for instance.

The smaller the RF frequency the better for Long Range. We think about this one: if we would go towards lower frequencies, let's assume
even down to the 100 KHz range, then we could also penetrate water:
a swimmer in the ocean could be connected to an IoT network, e.g. to bring his health sensor
data into the Cloud when swimming miles away, offshore, or even when diving.

There are two other facts why such technologies might not suitable for meshed networks:
BLE is a peer-to-peer link, between one, your smartphone and one sensor mote. If more then six BLE devices are around you -
no way to manage or handle those.

OK, WiFi can handle many devices, but it is more a star topology. And: it is a central hub, a central intelligence. It is a contradiction to
a Swarm Network where not any central node or intelligence should be involved, it should not be mandatory.

Long Range is a wireless transmission technology using the Sub-GHz licence free bands or channels. Such lower frequencies can
extend the Line of Sight dramatically, can cope with multi-path reception and the most interesting aspect: it can penetrate walls,
it can go into building or
can be radiated from the inside there, possible to cover several levels in a building, an entire floor through several rooms what you can never
do with BLE or WiFi. Less nodes needed, easier to install: just drop where convenient, less RF polution, better spectrum utilization etc..

Long Range links would give us the oppprtunity to create more easily large Swarm Networks.
We can interact with nodes much more far away. We can
interleave and let overlap the swarm cells much better. There is no need to take the next nearby node as neighbor,
we can inter-link with a node far away into another
swarm cell.

Long Range will not just extend to coverage - we are talking really about several miles -
we can also create meshed structures without a central node,
without a central hub.

The much higher coverage, the longer distance of a link. It gives us also the opportunity to skip some nodes in our neighborhood.
If we do Hop-by-Hop communication, we can decide to step over a wider distance,
to skip nodes in between. We avoid congestions, have more options to establish a meshed structure and
to reduce the number of nodes needed for an end-to-end transmission.
We have higher capacity for alternative routes. Or other meshed structures are concurrently used without to overload single nodes (load balancing).

We think: Long Range is the key for a successful IoT deployment.

Long Range gives us also the option to extend your inhome IoT network, to use Long Range nodes inhouse and to have seamless connection to
a city-wide IoT network.

The Long Range solutions we use provide a much better efficiency in terms of power consumptions, even reliability and scalability. The
sensitivity is much higher compared to BLE or WiFi: smaller antennas are possible, a reduction in transmission power (just 20 dBm for 25 miles in rural
areas).

BLE and WiFi will be a technology to bridge to other networks, augmented to IoT Long Range,
e.g. to connect ordinary sensor motes with BLE via Long Range or to connect such an IoT Swarm Network to our Internet.

One fact has to be mentioned frankly: this Long Range is optimized for low bitrate services and data from sensors or to actors used in IoT
applications. This Long Range fits perfectly for almost all IoT solutions. But it is not the approach for high datarate services, such as video
streaming from/to sensor nodes as CCTV or transfering huge amount of data such as files via Long Range.

Long Range is the perfect means for large IoT networks, provides the features we need for
IoT Long Range Swarm Networks. Our Golden Gate Bridge will need just few (approx. 10) of such Long RangetINFINODEs and tINFIHUBs in order to span a meshed network over the entire bridge. We can reach any bolt sensor on it.
Just add additional sensor nodes anytime later to a Swarm and let the Swarm grow, manage and improve itself.

Dead things become alive, become a body, with IoT. We extend their lifetime, make it more reliable and healthy,
to all of our benefit and safety.