Data Model

The N2N DL data model is built around devices, users or API keys and groups

Devices

In N2N DL Sensors and actuators are all considerd devices.

All devices support data uplink - sending data to N2N DL - but only some devices have downlink capabilities for remote control or configuration.

Most devices on the market come with multiple sensors. To support this N2N DL groups device readings - where the parsing takes place - in channels (one per sensor).

Depending upon the device all or only some channels may be reported with each uplink so a device reading may contain a variable number of channel readings.

Users and API Keys

A valid user or API key is needed to interact with N2N DL.

They both behave very similary and share a nearly identical data model.

Access Levels

There are 3 levels of access: reseller, admin and readOnly

Enterprises

An enterprise represents a NNNCo client in the multitenanted architecture. Each device is owned by one enterprise.

Enterprises are organised in a hierarchy or tree model where the non-leaf nodes are called resellers .

Each enterpriseId contains the names of the resellers above like in the following example:

Groups

N2N DL groups are the most interesting and powerful features in the N2N DL data model: they govern access to devices, users, api-keys and enterprises.

Every entity in N2N DL belongs to one or more group.

Master groups

Every enterprise has an associated master group.

For example the enterprise nnn has a nnn.master group

Every device that belongs to nnn will belong at least to nnn.master

Subgroups

Within an enteprise subgroups can also exist.

Roughly speaking every group name that doesn’t end in .master is considered a subgroup.

Example:

enterpriseId: nnn

master group: nnn.master

subgroup: nnn.water

Access to devices

Users and API keys gain access to devices, other users and API keys by belonging to 1 or more matching groups (either master or subgroups)

Users and API keys can belong to multiple groups like in the following example:

Example:

user test@test.com belongs to nnn.client1.master and nnn.client2.master.

It can access all devices linked to enterprises nnn.client1 or nnn.client2

In order to delete or update a user or API key the same level of access (group list) or superior is required.

Groups and hierarchy

Group membership automatically expands and cascades according to the hierarchy

Given the following hierarchy:

Example:

nnn -> client1

nnn -> client2

nnn -> client3 -> client4

nnn -> client5 -> client6

If a user has access to group nnn.client3.master it automatically gains access to nnn.client3.master, nnn.client4.master - cascaded access

If a user has access to group nnn.master it automatically gains access to nnn.client1.master, nnn.client2.master, nnn.client3.master, nnn.client4.master, nnn.client5.master, nnn.client6.master

Subgroups and access

Users are considered with limited access if have access only to subgroups like in the following example:

Example:

user: test@test.com

groupList: nnn.binsensors

Subgroup access does not cascade.

Subgroups and enrollment

LoRaWAN device enrollment requires access to 1 or more master groups.

Subgroup access only is only for data sharing.