# Gateway Architectures¶

## Gateway Architectures¶

Before digging into the nuts and bolts of organizing OTAU deployments and managing a fleet of IoT gateways, this section defines some topographies and separates them into Classes. It is important to understand how your IoT gateway fleet is organized because it can affect how OTAU deployments are executed and monitored/verified.

### Class A¶

A typical IoT environment where gateways are a part of the overall ecosystem generally look something like the representation below.

Important

Device Identity

In a Class A-D architectures, the CGA uses the connection identity and credentials of gwe. This is often done as a matter of convenience since using GWE can simplify identity and provisioning considerations.

### Class B¶

Another typical way IoT gateways are architected is when the CGA uses either the device-client python library or the gdc command-line interface to read/write/connect to Exosite.

### Class C¶

This IoT gateway architecture is when the CGA uses gmq to read/write/connect to Exosite.

### Class D¶

This IoT gateway architecture is when the CGA uses a mixed communication scenario. For instance, the CGA will use gmq to read/write/connect to Exosite as well as its own HTTPS/MQTT connection methods to communicate on the internet or to read configuration data from Exosite.

### Class AA¶

A Class AA architecture is similar to a Class A except that it breaks up the identity of the CGA from gwe. In this case, there will be two Products in a given Murano Business with different resources.

### Class BB¶

A Class BB architecture is similar to a Class B except that it breaks up the identity of the CGA from gwe. In this case, there will be two Products in a given Murano Business with different resources.

### Class CC¶

Similar to a Class C architecture, configuration is when the CGA uses gmq to read/write/connect to Exosite but does so with different a different identity and credentials than gwe.

### Class DD¶

Similar to a Class D architecture, the CGA uses a mixed communication scenario, but does so with different a different identity and credentials than gwe.

## IoT Fleet Management¶

Inevitably, an update to some software on atleast one gateway will need to be made. This section is not meant to be an exhaustive guide on Continuous Integration or Fleet Management, rather an overview on how IoT gateway fleet maintainers can do a minimum to create an environment to create a development/staging environment for vetting over the air updates with non-production assets.

### The Minimal Case¶

A minimal IoT gateway environment.

Though the environment described by the diagram is typical to most environments, it fails to address the problem of OTAU rollouts and fleet maintenance.

### A More Robust Case¶

Before deploying any over the air update, it should be tested in a test environment. To create a test environemt, make a copy of the production Murano Product and connect to test gateways to it and test the OTAU.