This migrates the device-sessions from Redis into PostgreSQL. This fixes
a performance issue in case the same DevAddr is reused many times
(e.g. devices rejoining very often or a NetID with small DevAddr space).
There were two issues:
The Redis key containing the DevAddr -> DevEUIs mapping could contain
DevEUIs that no longer used the DevAddr. This mapping would only expire
from the Redis database after none of the devices would use the DevAddr
for more than the configured device_session_ttl.
The other issue with the previous approach was that on for example a
Type 7 NetID, a single DevAddr could be re-used multiple times. As each
device-session could be stored on a different Redis Cluster instance,
there was no option to retrieve all device-sessions at once. Thus a high
re-usage of a single DevAddr would cause an increase in Redis queries.
Both issues are solved by moving the device-session into PostgreSQL
as the DevAddr is a column of the device record and thus filtering on
this DevAddr would always result in the devices using that DevAddr, as
well all device-sessions for a DevAddr can be retrieved by a single
query.
Note that to migrate the device-sessions, you must run:
chirpstack -c path/to/config migrate-device-sessions-to-postgres
A nice side-effect is that a PostgreSQL backup / restore will also
restore the device connectivity.
Closes#362 and #74.
Note that the integration events will contain the application +
device-profile + device tags. Integration events will NOT contain the
tenant tags. Most likely tenant tags will be used to store information
about the tenant, data that is unrelated to the integration events.
Fixes#211.
The gw_time defines the RX time by the gateway, the ns_time defines when
it was received by the NS. The latter could for example help to debug
latency between the GW <> NS.
The JSON encoding should only be used for debugging purposes! However
this change avoids showing errors in case there are unknown fields in the
JSON payload. This would happen when for example the MQTT Forwarder
and ChirpStack uses a different API version (which in case of Protobuf
would be fine, as long as the major version remains the same).
This implements end-to-end encryption between the end-device and
end-application. The encrypted AppSKey or SessionKeyID is forwarded to
the end-application which should be able to decrypt or request the
AppSKey to decrypt the uplink payload. As well the end-application will
be able to enqueue encrypted application payloads.
Using this mechanism, ChirpStack will never have access to the uplink
and downlink application-payloads.
