Would be great to work on a feature to allow the application to work independently of application server, in the event of a WAN outage, and just managed via the central application UI (rather than have an app UI instance at each satellite site). Technically this could be partially achieved if each satellite lorawan GW had it’s own self contained network server, clustered postgres, redis db and clustered MQTT. The challenge is with the application server, which is responsible for higher level functions. Would require that the App server be split up into LoRaWAN features and management features. If all the management features were in a separate service, then the satellite sites could continue to run in the even of a WAN outage. To my knowledge this cannot be accomplished with the current version.
Nope.
The whole point is that network level state is shared rather than unique to a gateway, and the failure of any given gateway is largely irrelevant (only claiming to do things but not doing them is an issue).
Something like this might be possible, when you deploy the NS on premise and the AS in the cloud. However, it is quite hard to properly separate these two as the AS is responsible for encrypting the payloads (the fCnt is a property of the encryption scheme). However, the NS might use that fCnt for a mac-command only payload, and thus the whole queue needs to be re-encrypted with the updated fCnt sequence.
Please note that with the upcoming ChirpStack v4, the AS and NS are going to be merged to remove some complexity and to make it easier to setup ChirpStack.