Domains

Domains are used to segregate your ThingPark Enterprise subscription to serve multiple tenants, and restrict the visibility of base stations, devices and multicast groups by non-Administrator users. Each tenant would have access to resources bound to their perimeter.

Only the visibility of base stations, devices and multicast groups can be restricted using domains. The visibility restriction also applies to the related traffic and alarms. Connections, news, catalogs and the license remain cross-domain and shared by all tenants. However, when domain-based segregation is in use, the edition of connections is limited to Administrator users.

note

Regardless of the associated domains, every base station operating under the ThingPark Enterprise subscription continues to serve LoRaWAN® traffic from any device under this same subscription without any exclusion.

The following video gives you a quick outlook of domains and shows you the key steps to have your segregation use-case up and running:

Important Note

Tags and domains are 2 distinct attributes supported by devices and base stations. The main differences are summarized in the following table:

	Tags	Domains
Usage	Like free-text stickers, essentially used for resource categorization and filtering. Additionally, base station tags may be used for multicast purposes. Device tags are reported through connections to external IoT applications to allow segregated traffic processing.	User permission management. Note The domains associated with each device are also reported through connections.
Who can assign it?	Freely assigned by administrator and non-administrator users having write access to the resource in question.	Only pre-defined domains (created by an administrator user) can be associated with resources. While administrator users can associate a resource with any domain (except assigning several domains from the same group), non-administrator users can only assign domains in accordance with their own domain restrictions.
Can be used for permission management?	No, because tag addition/removal is freely opened for non-administrator users so it cannot be controlled by administrator users.	Yes, because domains are strictly controlled by administrator users.

Basic segregation

A typical example of segregation is the segregation based on geographical location. In such example, one domain is created for each possible geographical location as illustrated in the figure below.

Each domain is represented by a green badge in the above domains list. Domains are grouped in a Geography domain group that materialize the segregation based on geographical location.

Each base station, device and multicast group can be associated with at most one domain matching its geographical location.

The visibility of these resources can be restricted by configuring a domain restriction for non-administrator users. A domain restriction is composed of an exact domain or a domain prefix. In the latter case, hierarchical domain names must be defined by using the / character to define a parent/child hierarchy.

When a domain restriction is configured in a non-Administrator user account, only base stations, devices and multicast groups matching the domain restriction are visible to the user. Administrator users cannot have domain restriction and always have access to all the resources of the subscription. The following table provides an example of visibility rules depending on the configured domain restriction.

User scope	Domain restriction	Visible resources
Operates IoT network in Germany	EMEA/Germany	- Base stations, devices and multicast groups associated with the EMEA/Germany domain. - All connections.
Operates IoT network in USA	USA	- Base stations, devices and multicast groups associated with the USA/East-Coast domain or the USA/West-Coast domain. - All connections.
Operates IoT network worldwide	No domain restriction	- All base stations, devices and multicast groups regardless of associated domains. - All connections.

Advanced segregation with more than one domain group

More advanced segregation can be achieved by adding domain groups to introduce additional segregation scopes (i.e. segregation dimensions). For example, resources can be partitioned based on the use-case in addition to the geographical location, as illustrated in the figure below.

A second Use-case domain group is created to materialize the segregation based on use-case. In this domain group, one domain is created for each possible use-case. These new domains are represented by orange badges in the above domains list. Each domain group may be assigned a distinct color to be easily identifiable.

In the example above (with 2 domain groups), each base station, device and multicast group can be associated with at most two domains (one from each group):

• At most one domain belonging to the Geography domain group: this domain matches the geographical location of the resource.
• At most one domain belonging to the Use-case domain group: this domain matches the use-case of the resource.

note

Each domain belongs to a domain group. A domain group defines a segregation scope. All the domains grouped under the same scope are mutually exclusive to avoid segregation conflicts, i.e., a given resource cannot be associated with more than one domain from the same group. For instance, a device cannot be associated to both EMEA/France/Paris and EMEA/Germany domains that are grouped under the same Geography domain group.

In the same way, each non-Administrator user can be associated with at most two domain restrictions:

• At most one domain restriction matching an exact domain or a domain prefix in the Geography domain group. If defined, only resources associated with a Geography domain matching the domain restriction are visible by the user. Otherwise, no restriction applies regarding the Geography domain group.
• At most one domain restriction matching an exact domain or a domain prefix in the Use-case domain group. If defined, only resources associated with a Use-case domain matching the domain restriction are visible by the user. Otherwise no restriction applies regarding the Use-case domain group.

Important note

Domain restrictions may consist of several domains or domain prefixes, but they must belong to distinct domain groups. For each domain group, only the resources matching the related domain restriction can be accessed by the user.

If no domain restriction is defined for a given domain group, the user does not have any restriction for this group.

The following table provides an example of visibility rules depending on configured domain restrictions.

User scope	Domain restrictions	Visible resources
Operates IoT network in Paris for the Asset Tracking use-case	EMEA/France/Paris, Asset Tracking	- Base stations, devices and multicast groups associated with both EMEA/France/Paris domain and Asset Tracking domain. - All connections.
Operates IoT network in Germany for all use-cases	EMEA/Germany	- Base stations, devices and multicast groups associated with the EMEA/Germany domain regardless of associated domain in the Use-case domain group. - All connections.
Operates IoT network in USA for the Smart Building use-case	USA, Smart Building	- Base stations, devices and multicast groups associated with the USA/East-Coast domain or the USA/West-Coast domain, and the Smart Building domain. - All connections.
Operates IoT network worldwide for all use-cases	No domain restriction	- All base stations, devices and multicast groups regardless of associated domains. - All connections.

Interaction with user's roles

When domain restrictions are defined for a non-Administrator user, the access rights granted by the user's roles only apply to the resources matching the domain restrictions. All other resources are not accessible at all.

All resources added or updated by a non-Administrator user must match the domain restrictions. For example, if the user has the base station manager role:

• Base stations added by the user must match his/her domain restrictions to be successfully provisioned in the system. In other words, a user is not authorized to add a resource that does not comply with its own domain restrictions, otherwise this same user will not be able to access it afterwards.
• Likewise, updating the domains associated to a base station by the user must match his/her domain restrictions before and after the targeted update.
• Base stations deleted by the user must match his/her domain restrictions before it can be deleted.