New features common to self-hosted ThingPark Enterprise and SaaS

Passive Roaming RDTP-4710 RDTP-9402

Passive Roaming allows a device to maintain its LoRaWAN® session when it roams away from its home network to a visited network. In this scenario, the visited (or forwarding) Network Server (fNS) relays the LoRaWAN frames between the device and the serving/home Network Server (sNS) as per the following diagram:

More details

The LoRaWAN® MAC session remains controlled by the home/serving Network Server, i.e., all the MAC commands, ADR and downlink routing decisions are handled by the home network. Additionally, only the home Network Server has an interface with the device's Application Server.

For more details about Passive Roaming and its message flows, please refer to LoRaWAN® Backend Interfaces v1.1 specification.

note

Passive Roaming implementation in the current release is based on stateless mode, i.e., fNS does not keep any session context of visiting devices. Thanks to its simplicity, this mode is compatible with all the network server implementations and thus offers higher interoperability with non-Actility network servers.

Roaming use-cases

• Roam-in means that foreign devices belonging to your agreed roaming partners are allowed to be served by your Radio Access Network (RAN) to route their LoRaWAN® uplink/downlink packets to/from their home network. In roaming-in mode, your network server acts as a forwarding Network Server (fNS).

• Roam-out means that your own devices (provisioned in your TPE account) are allowed to roam outside of your RAN coverage area, while being served by gateways supplied by your agreed roaming partners and routing your device's traffic to your network server. In roaming-out mode, your network server acts as a serving/home Network Server (sNS/hNS).

  note

  Roam-out use-case requires assigning a dedicated NetID > 000001 to your roaming devices, since private NetIDs (000000 and 000001) do not support roaming-out.

ThingPark 7.0 supports the following roaming use-cases:

• Roam-in only: you open-up your RAN to serve foreign devices belonging to your agreed roaming partners, besides your own devices.

  • Roam-in is useful to mitigate RF collision/interference, as detailed in the "Key customer benefits" section.

  • This use-case does not require a dedicated NetID, so you may use private NetID=000001 but this implies that your roaming partners also support v1.1 of the LoRaWAN® Backend Interfaces standard.

• Roam-in + roam-out: full bidirectional roaming allowing foreign devices (from agreed peers) to roam into your network while your own devices can be served by foreign gateways belonging to your agreed roaming partners.

  • This use-case requires a dedicated NetID: You may either get your own NetID from the LoRa Alliance or use a chunk of Actility's NetID (NetID = 000002).

    note

    Non-roaming devices shall use NetID=000000, to preserve the entire DevAddr pool of your dedicated NetID for roaming devices.

  • Using a chunk of Actility's NetID=000002, you shall automatically leverage Actility's global roaming agreements, sparing you the effort to negotiate agreements with the different LoRaWAN® network operators.

    note

    Using Actility's NetID=000002 also implies that your roaming partners support v1.1 of the LoRaWAN® Backend Interfaces standard.

Notes

Unless your peer roaming partners support v1.1 of the LoRaWAN® Backend Interfaces standard, the only possibility to roam with them is to use your own dedicated NetID (assigned to you by the LoRa Alliance), since v1.0 of the Backend Interfaces standard does not allow using shared NetIDs.

TPE customers neither interested in roam-in nor roam-out modes shall set their NetID to 000000.

Roaming in ThingPark Enterprise is only provided via ThingPark Exchange (TEX) hub. To learn more, see Integration with ThingPark Exchange for roaming and activation use-cases.

See Feature activation for more details about global activation process for TPE SaaS and self-hosted TPE, including the selection of the target roaming modes.

Once the feature is configured globally at the TPE subscription level, the TPE GUI allows activating/deactivating roam-out mode individually for each device:

• During unitary device creation step:

  

• Or during mass import of device list, by setting the value-added features associated to each device in column "H". This "Features" column supports a comma-separated list of features among "NetworkGeolocation" and "PassiveRoaming" options.

• Updating an existing device, through the Device Status widget:

  

note

Roam-out traffic is displayed with "PR" icon in TPE GUI in Device's "Last 10 Packets" widget and Connection's "Last 25 packets" widget.

Wireless Logger impact

WLogger application displays both roam-in and roam-out traffic.

The packet icon is updated for passive roaming uplink/downlink packets:

• 'fPR' is displayed for uplink/downlink packets routed by TPE for foreign devices (roam-in traffic). In this role, TPE acts as a forwarding network server.

• 'sPR' is displayed for uplink/downlink packets of home devices served by foreign gateways belonging to roaming partners (roam-out traffic). In this role, TPE acts as a serving network server.

Reporting to Application Servers

For roam-out traffic, the metadata reported to Application Servers is enhanced with the following additional information:

• A flag to indicate that the packet was forwarded (uplink) or delivered (downlink) through a third-party roaming network, the gateway of which was elected as the "best serving gateway" by the serving Network Server (sNS).

• The NetID of this third-party roaming operator (forwarding Network Server).

The new fields added to the uplink and downlink_sent_indication reports are:

Roaming	Indicates the type of roaming. This field is set to 1 only when the LoRaWAN® uplink/downlink frame was forwarded from/to the device through a foreign network and the sNS selected this foreign gateway as best serving gateway.
ForwardingNetID	The NetID of the forwarding NS. This field is filled only when “roaming” = 1.
ForwardingNSID	The NSID of the forwarding NS. This field is filled only when “roaming” = 1 and the roaming interface uses LoRaWAN® Backend protocol version 1.1.

Traffic segregation

Another enhancement brought by this feature is the traffic segregation between the different TPE subscriptions in a multi-tenant SaaS environment: Starting release 7.0, segregation is enforced subscription-wide, which means that TPE subscription-A's devices shall only be served by subscription-A's Base Stations, not by Base Stations belonging to TPE subscription-B; except in one of the following cases:

• There is a valid roaming agreement between Subscription-A and Subscription-B.

• Subscription-A's devices and subscription-B's Base Stations use the same dedicated NetID (NetID different from 000000 and 000001). In this case, the network traffic between subscriptions A & B (for instance, sharing Actility's NetID 000002) is not segregated as they are considered part of the same network. This rule does not apply if subscriptions A & B use private NetID 000000 or 000001.

• Subscriptions A & B are explicitly configured to use the same Segregation-ID in Device Manager / Network Manager GUI. This use-case would be relevant for ThingPark-Embedded customers managing multiple subscriptions within the same TPE SaaS platform and willing to share their Base Stations' coverage across their different subscriptions.

Key customer benefits

Passive Roaming feature is crucial to:

• Maximize the LoRaWAN® coverage through collaborative networks, by leveraging Radio Access Networks (RAN) deployed by your roaming partners instead of relying solely on your home RAN's coverage. Passive Roaming offers an excellent trade-off between network deployment cost and end-to-end QoS to achieve the best performances while minimizing the device's battery draining and optimizing the air-interface resources.

• Improve the LoRaWAN® compatibility with mobility use-cases: end-devices can seamlessly roam away from their home network without losing their LoRaWAN® connectivity.

• Minimize RF collision & interference caused to your gateways by foreign devices, by opening-up "roam-in" use-case: By routing the uplink frames already received by your gateways to the foreign device's home network, roaming-in improves the RF macro diversity and reduces the foreign device's time-on-air (through a reduced Spreading Factor/faster data rate and lower number of repetitions) and also lower its uplink TxPower.

note

Passive Roaming has a significant advantage over Handover Roaming in that it is fully transparent to the LoRaWAN® version of end-devices; therefore, passive roaming is fully compliant to release 1.0.x devices. Additionally, Passive Roaming fully exploits the RF macro diversity concept by allowing the same device to be served through a mix of gateways belonging to different roaming partners.

Another advantage of this feature is the enhanced traffic segregation between the different TPE SaaS subscriptions sharing the same regional platform.

Feature activation

On TPE side, Passive Roaming is deactivated by default.

For self-hosted TPE:

• The platform-wide feature activation/deactivation is managed in Cockpit, under "TPE Configuration" > "LoRa configuration" > "Roaming/Activation" field.

  note

  This field is also used for activation of OTA devices on ThingPark Activation Service, as explained in Integration with ThingPark Activation (TPA) service RDTP-3381.

• Then, the platform administrator must set the LoRaWAN® NetID according to the target roam-in/roam-out use cases as described in the "Feature Description" section.

  NetID consists of 6 hexadecimal digits (case insensitive) restricted to the following list in TPE release 7.0:

  • 000000 (private NetID 0) – forbidden if roam-out is enabled

  • 000001 (private NetID 1) – forbidden if roam-out is enabled

  • 000002-00003F (dedicated NetID type 0)

  • 600000-7FFFFF (dedicated NetID type 3)

  • C00000-DFFFFF (dedicated NetID type 6)

    note

    Starting release 7.0 (thanks to RDTP-9402), the self-hosted TPE platform administrator may change the NetID at any time, but the corresponding DevAddr of OTA devices will only change upon the next Join Request initiated by those OTA devices after changing the NetID in cockpit.

    note

    Self-hosted TPE administrators may configure, in Cockpit, specific DevAddr ranges for each platform, so that the same dedicated NetID is reused across several platforms. This is also known as NetID subnetting, where each platform is assigned a distinct pool of DevAddr values within the bigger NetID.

• The administrator must also configure the ThingPark Exchange account details, based on the information provided by Actility.

  note

  NSID is provided by Actility NetOps team, it must be unique for self-hosted TPE platform.:

  

• Then, roaming-out may be activated/deactivated per device in TPE GUI.

For TPE SaaS:

• Passive roaming is deactivated by default, since the default NetID is set to 000000 once the regional SaaS platforms are migrated to release 7.0.

• To activate roaming, the Actility Support team shall configure your subscription in Network Manager & Device Manager GUIs:

  • In Network Manager settings, set the subscription Base Station NetID:

    

    • To activate "roam-in only" mode, set Base Station NetID = 000001 if you do not own a dedicated NetID.

    • To activate "roam-in + roam-out" mode, set Base Station NetID to the desired dedicated NetID (i.e., different from the private 000000 or 000001 NetIDs).

  • In Device Manager settings, set the subscription NSID as well as NetID for non-roaming and roaming devices, as per the following screenshot:

    

    • To activate "roam-in + roam-out" mode, set "roaming devices NetID" to the desired dedicated NetID, leave "non-roaming devices NetID" empty, so it keeps the default setting = 000000.

    • For "roam-in only" mode, leave "roaming devices NetID" empty, so it keeps the default setting = 000000, as roaming-out use case is disabled.

      note

      Any change of NetID/NSID settings must be followed by a full reprovisioning of the objects associated with the impacted subscription. Full reprovisioning can be handled only by the platform administrator, so you should contact Actility Support team to complete this task.

      Then, roaming-out may be activated/deactivated per device in TPE GUI.

Important

Besides roaming activation in TPE, a Network Server must be declared in ThingPark Exchange (TEX) for your TPE subscription. Your roaming agreements with your peer Network Servers must also be directly configured in TEX. To learn more, see Integration with ThingPark Exchange for roaming and activation use-cases.

Feature limitations

In the current release, TPE customers using a chunk of Actility's NetID (= 000002) cannot freely negotiate their own roaming agreements, they inherit Actility's global set of roaming agreements. Additionally, the same DevAddr pool applies to all the TPE SaaS subscriptions using NetID 000002 within a given regional TPE SaaS platform.

Integration with ThingPark Activation (TPA) service RDTP-3381

ThingPark Activation (TPA) is Actility's managed service offering secure activation to LoRaWAN® OTA devices through a secure Join Server (JS). All the LoRaWAN® keys are secured by a Hardware Security Module (HSM) embedded in TPA service.

More details

A typical process of OTA device activation consists of the following steps:

Stage	Description
#1 - Pre-commissioning	The Device Manufacturer imports the device information (DevEUI, JoinEUI, AppKey, NwkKey (for LoRaWAN® 1.1 devices)) into TPA. Upon successful pre-commissioning, the Device Manufacturer gets an Owner-token from TPA to act as a proof of ownership for this DevEUI. Device manufacturer should communicate this Owner-token to the device buyer/owner; for instance, by including it in the standard QR code specified by LoRa Alliance. At this stage, the device is said to be “generic”, meaning it is not yet personalized for (nor associated with) any LoRaWAN® Network Server (NS).
#2 - Commissioning	When a ThingPark Subscriber buys this generic device, the two following tasks should be performed to complete the device commissioning step: Provision the device in ThingPark Enterprise, by providing the DevEUI, JoinEUI and selecting the option “External Join Server”. Claim the device’s ownership on ThingPark Activation Key Manager, by presenting the Owner-token and setting the Home NetID. The claim procedure is automatically managed by ThingPark Enterprise towards ThingPark Activation’s Key Manager application without having the end-user to connect to TPA and manually claim the device. At the end of the commissioning stage, the Join Server (ThingPark Activation) is ready to handle Join Requests forwarded by the home Network Server (NS) for this device.
#3 - Activation	When a commissioned OTA device is power-on, it sends a Join Request message that is routed to the competent Join Server (JS), identified by its JoinEUI. JS processes the request and generates a Join Answer. At the end of this over-the-air activation step, the device shall generate its MAC session keys and hold a secure LoRaWAN® session with the network.

This three-step process is illustrated by the following diagram:

The following diagram shows the different states of OTA device during its life cycle, as specified by LoRaWAN® Backend Interfaces:

On ThingPark Enterprise UI, the end-user shall provision the device with the option Activation mode = "Over-the-Air Activation (OTAA) with external Join Server" and sets the Owner-token, as per this example:

Once the device is provisioned in TPE, the claim procedure is automatically triggered towards TPA, based on the Owner-token provided by the end-user.

If the claim procedure fails for any reason (for instance, the device has not been pre-commissioned on TPA, the device is already claimed, Owner-token is invalid...), the device creation in ThingPark Enterprise shall fail with the following error:

This automatic claim procedure applies to both unitary device creation and mass import use cases.

When the device is deleted from ThingPark Enterprise, an unclaim request is automatically triggered towards TPA Key Manager if the device was already commissioned on TPA.

note

For sake of simplifying the integration with third party Application Servers (AS), device's uplink payloads are decrypted by ThingPark Enterprise (using AppSKey) before being forwarded to AS. Likewise, AS shall send decrypted downlink payload to TPE, delegating the encryption step to the TPE Network Server.

Key customer benefits

ThingPark Activation service offers a secure way to activate OTA devices:

• Secure storage of LoRaWAN® root keys through Hardware Security Module (HSM): HSM is self-protected and ensures that, regardless of the hosting location or owner, the data protected by the HSM is as safe as if it was hosted by a Trusted Third Party. HSM also ensures that if a hosting platform is compromised, for instance accessed by unauthorized attackers, the protected data is still safe. Under physical attack, an HSM will self-destroy before releasing the protected data. Typically, an HSM will release its secret data only when provided with a set of (two or more) smart cards.

  HSMs represent the state of the art of secret data protection, they are used by banks worldwide to keep smart card root secrets.

• Using a secure activation service significantly simplifies and secures the exchange process between device manufacturers and device owners: instead of unreliably sharing the LoRaWAN® root keys (AppKey in LoRaWAN® 1.0.x) in clear text, the root keys are securely provisioned by the device manufacturer in the Join Server and do not need to be directly shared with the device owner. Only the Owner-token is then communicated to the device, as a proof of ownership during claim process.

  Additionally, AppKeys cannot be printed on QR codes (for security reasons), whereas Owner-tokens are already present in the standard QR code defined by the LoRa Alliance. Use of standard QR codes drastically simplifies the device onboarding process.

• OTA device activation away from home, that is to say a device sending a Join Request through a foreign LoRaWAN® network, can only be supported when device activation is managed by a central Join Server (as opposed to the combined NS-JS approach).

Feature activation

The activation of this feature requires the following actions:

• On ThingPark Enterprise (TPE) side: a TEX account is required and NSID must be allocated by Actility NetOps.

  • For self-hosted TPE, the feature activation is managed by Cockpit, under "TPE Configuration" > "LoRa configuration" > "Roaming/Activation" field.

    Note This field is also used for roaming configuration, as explained in Passive Roaming (RDTP-4710 and RDTP-9402).

    

  • For TPE SaaS, the TEX account is directly configured by Actility NetOps team, together with a global platform-wide NSID.

• On ThingPark Exchange (TEX) side:

  • For TPE SaaS: each TPE SaaS instance using a dedicated NetID must be declared on TEX as a Network Server. This declaration is done by Actility NetOps team. TPE SaaS instances using private NetID 0 or 1 shall reuse Actility's Network Server account on TEX.

  • For self-hosted TPE: each self-hosted TPE instance using TPA services (whatever the NetID) must be declared as a distinct Network Server on TEX. This declaration is done by Actility NetOps team.

    To learn more about TPE integration with TEX, see Integration with ThingPark Exchange for roaming and activation use-cases.

This feature requires ThingPark Exchange version 1.2.0 or higher.

Note Self-hosted TPE platforms must have internet access to connect with ThingPark Exchange.

Once the ThingPark Enterprise instance is successfully connected to ThingPark Activation, through ThingPark Exchange hub, the activation of this feature is managed device-wise from TPE UI: during device creation, use the option Activation mode = "Over-the-Air Activation (OTAA) with external Join Server" and set the Owner-token provided by the device manufacturer (or scanned via the LoRa Alliance's standard QR code format).

Feature limitations

By default, this feature considers that Application Servers continue to delegate the payload encryption/decryption step to ThingPark Network Server. If the end-user wants to activate end-to-end payload encryption mode between the device and the Application Server, they should associate their devices with an Application Server Transport Key (ASTK) in TPA's Key Manager (this action is not currently supported through TPE UI).

Integration with ThingPark Exchange for roaming and activation use-cases

LoRaWAN® roaming and OTA activation features require Network Servers (NSs) and Join Servers (JSs) to be configured in a way that they would process incoming messages from their peers and route them to their respective destinations based on roaming agreements. Configuration parameters include URIs or IP addresses corresponding to JoinEUIs and NetIDs, firewall rules (e.g., allowing incoming TCP connections from given IP addresses), HTTP authentication credentials, LoRaWAN® roaming policies (e.g., allowing Passive Roaming, incoming roaming devices, etc.), Usage Data Records (UDRs)...etc.

As the number of nodes (NSs, JSs) involved in roaming increases, dealing with the exponentially increasing number of peer-to-peer configuration and record keeping/reporting becomes difficult to setup and maintain.

A Roaming Hub helps transform the interconnection among several NSs/JSs from a mesh topology to a star topology by inserting itself in-between any two nodes. Such a change in topology helps reduce the complexity of roaming management from O(n2) to O(n).

Without star topology, a direct interconnection shall be required between each two Network Server or Join Server nodes, as per the following illustrative diagram:

Whereas a centralized hub offers a star topology to minimize the number of interconnections and hence drastically simplify the backend configuration within the enterprise. This is illustrated by the following diagram:

ThingPark Exchange (TEX) is the state-of-the-art Roaming Hub, providing a star topology to inter-connect Network Servers and Join Servers and support LoRaWAN® roaming and device activation flows.

More details

To offer seamless integration between ThingPark Enterprise and ThingPark Exchange, a control-plane interface is supported between TPE Network Server (also known as LRC) and ThingPark Exchange (TEX). This ThingPark-internal interface allows TEX to dynamically update TPE LRC's configuration of its peer NS and JS nodes. In other words, configuring roaming agreements between your Network Server and peer Network Servers, as well as adding Join Servers to your Network Server's scope, is fully controlled from ThingPark Exchange end. Then, TEX automatically sends to LRC the up-to-date technical configuration related each peer Network Server / Join Server, such as routing profiles, security credentials, Backend protocol version supported by peer node...

Moreover, this control-plane interface between TPE and TEX allows in-band synchronization - through TEX - of the forwarding NS's RF channel plans (also known as RF Regions) with its peer serving NS nodes having a common roaming agreement. This synchronization is essential to guarantee that each NS is aware of the channel plan (RF Region) used by gateways belonging to its roaming peer (forwarding NS), as channel mismatch shall yield uplink packet loss for roam-out devices.

• For TPE SaaS, exporting RF Regions and uploading to TEX is directly managed by Actility's NetOps team.

• For self-hosted TPE, to achieve this RF Region synchronization, TPE administrators shall export their relevant RF Region configurations from Cockpit and share them with Actility to be uploaded to TEX as RFParamSet elements.

Enhancements brought by this feature for self-hosted TPE Cockpit:

Cockpit is enhanced to support a new "TEX operations" menu, under the "TPE Services" panel:

• TEX synchronization: allows checking the synchronization status between TPE and TEX.

• Export RF Regions: export a tgz file containing all RF Regions matching the configured ISM band(s).

  note

  Maintenance menu is renamed "TPE cluster operations".

Key customer benefits

ThingPark Exchange (TEX) offers the following advantages:

• Easy and scalable integration between LoRaWAN® backend nodes (Network Servers and Join Servers): thanks to its star topology, ThingPark Exchange provides a single routing profile for outgoing traffic of each backend node to avoid defining point-to-point routing profiles between the different backend nodes of the LoRaWAN® ecosystem.

• Enhanced configurability, thanks to the TPE-TEX control-plane interface.

• Centralized and extensible policy control.

• Security shield against NS/JS peering nodes.

• Billing and monitoring capabilities: UDRs, traffic statistics, dashboards...etc.

Feature activation

Connecting a ThingPark Enterprise SaaS instance with ThingPark Exchange (TEX) is entirely under the control of Actility NetOps team. This includes the following tasks:

• Assigning a globally-unique NSID (Network Server ID) to each TPE SaaS subscription using a dedicated NetID > 000001.

• On TEX side:

  • Declare the Network Server corresponding to this TPE subscription in TEX, alongside all the technical information of this Network Server: NSID, NetID, LRC-TEX mutual authentication credentials, applicable RF Regions (also known as RFParamSets in TEX)...

  • Configure the roaming agreements of this Network Server with other Networks.

  • Associate this Network Server with partner Join Servers, to serve OTA device activation use-case.

• On TPE SaaS side:

  • Configure LRC table O with the dedicated NetID + TEX credentials of the TPE subscription.

  • Configure the NSID and NetID of the TPE subscription in Device Manager / Network Manager GUIs, as described in Passive Roaming RDTP-4710 RDTP-9402.

Connecting a self-hosted ThingPark Enterprise platform with ThingPark Exchange (TEX) requires the following tasks:

• Prerequisite The self-hosted ThingPark Enterprise server must have internet access to connect with ThingPark Exchange.

• Actility NetOps team shall assign a globally-unique NSID (Network Server ID) to each self-hosted TPE platform.

• Self-hosted TPE administrator shall communicate the following information to Actility NetOps team:

  • NetID

  • TPE URL(s)

  • Relevant RF Regions (also known as RFParamSet(s) in TEX) that TEX will share with peer Network Servers.

  • Dedicated NetID subnets /DevAddr pools, relevant only in case when the same dedicated NetID (> 000001) is reused across several self-hosted TPE platforms with a distinct DevAddr pool per platform.

• Then, Actility NetOps team shall perform the following operations in TEX:

  • Declare the Network Server corresponding to this TPE subscription in TEX, alongside all the technical information of this Network Server: NSID, NetID, LRC-TEX mutual authentication credentials, applicable RF Regions (RFParamSets), subnet ID, TPE URL(s)...

  • Configure the roaming agreements of this Network Server with other Networks.

  • Associate this Network Server with partner Join Servers, to serve OTA device activation use-case.

• Finally, Actility NetOps team shall communicate back the following information with the self-hosted TPE administrator who should configure them in Cockpit as explained in the feature activation section of Passive Roaming RDTP-4710 RDTP-9402 and Integration with ThingPark Activation (TPA) service RDTP-3381:

  • The allocated NSID
  • TEX URL
  • HTTP credentials (i.e., LRC-TEX mutual authentication credentials)

This feature requires ThingPark Exchange version 1.2.0 or higher.

Feature limitations

None.

Downlink multicast RDTP-9925

Multicast is a crucial feature for downlink transmission, it allows sending the same downlink frame to many devices at the same time. This is particularly interesting for Class B and Class C devices acting as actuators where the application server can control many end-devices by sending a single downlink frame (for instance, switch on/off streetlamps or gas meters...etc.).

Multicast feature drastically optimizes the downlink capacity and avoid overload of the air-interface resources for many class B/C use cases. Additionally, multicast is a mandatory feature to support Firmware Upgrade Over the Air (also known as FUOTA).

Details

More details

 

How multicast works

To support multicast, an end-device must be configured with a multicast DevAddr, multicast NwkSKey and multicast AppSKey in addition to its unicast DevAddr/session keys.

While the unicast DevAddr/session keys are distinct for each device, the multicast DevAddr/session keys must be the same for all the devices belonging to the same multicast group. Therefore, a multicast group consists of a "virtual" device with a DevAddr, NwkSKey and AppSKey.

End-devices must monitor both unicast and multicast addresses.

There are two ways to configure end-devices with the multicast group DevAddr/session keys:

1. Either via a personalized configuration hardcoded in the device stack, which is analogous to using ABP mode for multicast, even if the device uses OTA mode for unicast.

2. Or using over-the-air configuration via application layer configuration messages, as specified by the LoRa Alliance.

From ThingPark standpoint, the network server (LRC) does not know the mapping between the "virtual" multicast device and the "real" devices associated to it. The following figure illustrates the end-to-end downlink transmission flow:

To support multicast, end-devices must either use class B or class C mode. Native Class-A devices can still use multicast if they are configured by application-layer to switch to class B or C during the multicast session scheduling period. For more details, see the LoRaWAN® Remote Multicast Setup Specification v1.0.0.

Downlink packet transmission in multicast mode:

As specified by LoRaWAN, downlink multicast frames use "unconfirmed" mode, and do not include any MAC commands.

• Class B multicast session: For Class B multicast, end-devices listen to the multicast address over specific pingslots that are not necessarily the same as unicast ping slots. The multicast pingslot periodicity is directly provisioned in the Multicast Group, alongside the multicast pingslot data rate and channel frequency.

  Since class B operation implies that LRRs are perfectly synchronized by GPS, a downlink multicast frame can be safely transmitted synchronously over all the LRRs without any risk of collision, leveraging the constructive interference effect which is already the case for the synchronized transmission of beacon signals.

  Note In case the base station LRR cannot transmit the multicast frame over the programmed pingslot, it automatically reattempts transmission over the remaining available pingslots within the current and next beacon periods (like unicast mode) before sending a failure indication back to the LRC network server.

• Class C multicast session: For Class C multicast, end-devices must use the same RX2 data rate and frequency for both unicast and multicast modes. The multicast frequency and data rate are configured in the Multicast Group.

  To avoid radio collision between the different base stations (LRR) participating to the same multicast session, the LRC network server applies the collision-avoidance algorithm as illustrated by the following figure:

  

• For all the LRRs that are GPS-synchronized (green base stations in the above figure): The LRC schedules a simultaneous transmission like for class B devices => Perfectly synchronized transmissions (with +/- 1 μs precision) mitigate collision risk.

• For other LRRs (not GPS-synchronized), the LRC uses a clustering algorithm to group the LRRs that are sufficiently spaced away into the same cluster whereas neighbor LRRs are put in different clusters. The minimum distance required between two LRRs to share the same cluster is defined as "Class C Collision Avoidance Distance" and set to 7 Km.

  The LRC network server schedules multicast transmission sequentially for each cluster: All the LRRs within the same cluster transmit their downlink multicast frames at the same time (interference is mitigated by the distance separating those LRR base stations) while the multicast transmission over distinct clusters do not overlap in time to avoid collision. This case is illustrated by the orange gateways in the figure above.

  note

  In case the LRR location is not provisioned in ThingPark (blue gateways in the figure above), the LRC considers each LRR as a separate cluster.

In case the first transmission scheduled by the LRC fails for some LRRs (eventually after the LRR autonomously reattempts the transmission before giving up), the LRC shall re-attempt the transmission of the multicast frame until the maximum number of attempts is reached (set to 3 attempts in TPE).

The following figure illustrates the retransmission scheme used by the LRC network server for multicast frames:

Multicast summary reports

The LRC network server reports the transmission status of each multicast frame to the Application Server, in Multicast Summary Reports. To learn more, see LRC-AS Tunnel Interface Developer Guide.

The transmission status of multicast packets is also displayed in TPE UI in the Multicast Group dashboard, with the following color legend:

• Downlink fully sent

• Downlink partially sent (successfully sent on ≥80% of the target base station LRRs)

• Downlink partially sent (successfully sent on ≥30% and <80% of the target base station LRRs)

• Downlink partially sent (successfully sent on <30% of the target base station LRRs).

  

Multicast Configuration

To configure multicast, a Multicast Group must be created in ThingPark Enterprise. To learn more about creating a Multicast Group, see Feature Activation section.

Key customer benefits

Multicast feature brings major advantages to ThingPark customers, it allows an efficient support of the following use cases while minimizing the radio congestion and optimizing the downlink air interface resources:

• Firmware Upgrade Over the Air (FUOTA): This service allows application servers (for instance, Actility's Reliable Multicast Server) to upgrade the device's firmware and/or LoRaWAN® stack over the air. Since, the same content is valid for a group of devices, it is wasteful/impractical to use unicast mode for such upgrade campaigns.

• Massive Device Reconfiguration: Automated reconfiguration of a group of end-devices over the air.

• Street lighting use case: Synchronized action on a group of devices, typically switching on/off streetlamps.

• Metering use cases: In case of emergency, electrical / gas / water actuators can reliably cut distribution with minimum delay. Multicast can be used to switch-on these actuators once the emergency is over.

Feature activation

TPE users may create new Multicast Groups from the "Manage" panel on the left pane, then "Multicast Groups" > Create.

Then, the user shall fill the Multicast Group information as well as the RF configuration - depending on the target multicast class (B or C) -- and associate the group with one or several application connections.

note

Each Multicast Group must be associated with at least one base station tag, to define the base stations eligible to route the downlink multicast packets for this group. If several tags are selected, the union of all the base stations belonging to those tags will constitute the list of multicast base stations.

note

The data rate and channel frequency proposed by the UI are inherited from the RF Region configuration of the base stations associated with the Multicast Group (through the base station tags).

Feature limitations

Multicast payloads cannot be automatically decoded in Wireless Logger application because there is no device profile / driver metadata associated with Multicast Groups.

Device provisioning by QR code RDTP-12749

LoRa Alliance™ defines a standard device onboarding tag to simplify device provisioning step. This tag is typically printed as a QR code via a sticker pasted on the device.

More details

The tag content includes the following mandatory information elements:

• DevEUI: unique device identifier (8 bytes),

• JoinEUI: unique identifier of the LoRaWAN® Join Server where the device has been pre-commissioned (8 bytes),

• ProfileID: identifier of the device profile to be associated with the device. ProfileID consists of a VendorID (assigned by LoRa Alliance for each device manufacturer) + a VendorProfileID (assigned by the device manufacturer, distinct VendorProfileID should be distinct for devices with different Device Profiles or payload encodings).

The tag may also include the Owner-token as an optional element. This element is relevant when devices are pre-commissioned on an external Join Server by the device manufacturer. It is then used by the device owner as a proof of physical ownership during provisioning step in TPE. To learn more about Owner-tokens and pre-commissioning process, see Integration with ThingPark Activation (TPA) service RDTP-3381.

For detailed information about the LoRa-Alliance technical specification, see https://lora-alliance.org/resource_hub/tr005-lorawan-device-identification-qr-codes/.

Impact to ThingPark Enterprise UI

Device creation page is enhanced to give users the choice to create a device using an onboarding tag or manually (manual creation being the approach supported in previous releases).

To create a device using an onboarding tag, users can either:

• Use a physical QR code scanner connected to the user's PC/tablet.

• Click on the camera button to open the camera QR code scanner. This option is specifically relevant for tablet users.

• Copy/paste an onboarding tag to the text bar.

Upon scanning a valid QR code, the device creation form gets automatically filled with the filled with all data extracted from the corresponding onboarding tag. The device model is automatically filled if there is a one-to-one match between the ProfileID read from the QR code and the DeviceProfileID available in ThingPark catalog. In case several profiles match the onboarding tag's ProfileID, the user should manually select the proper model.

note

In release 7.0, the device may still be manually by selecting a device manufacturer, then the user is directed to the regular device creation form.

When the user wants to provision several devices in a raw by scanning their QR code, the chained creation requires a minimal number of clicks thanks to the "Create another" option:

• The device name is set to the DevEUI by default, but the user may change it as needed.

• Whenever relevant, the information set during the creation step of one device is reused as default setting (prefilled in the creation form) for the following devices. This is valid for the activation mode, the list of Connections associated to the device, additional information, as well as its location mode and position.

Impact to Device mass import

Onboarding tags can also be used for mass import of OTAA devices. The onboarding tag must be provided in the column B (DevEUI), in which case columns D, E, F and Y become optional. If any of these optional columns is filled in the csv import file, its value takes the precedence over the corresponding information included in the onboarding tag.

Key customer benefits

This feature drastically simplifies the device onboarding process for TPE users, by scanning LoRaWAN-standard QR codes instead of typing long hexadecimal strings.

Additionally, thanks to this feature, scanning a QR code allows automatic mapping of each device with its ThingPark Device Profile.

It also enhances the user experience when creating devices in chain, through the "Create another" option.

Feature activation

This feature is automatically available in release 7.0.

Scanning the QR code can either be done via the user's camera (essentially relevant for tablet users) or through a QR code scanner connected to the user's PC.

Only LoRaWAN-standardized onboarding tags are supported by this feature. Proprietary QR codes are not interpreted by ThingPark Enterprise.

Feature limitations

None.

[UI/UX]: Device and base station tagging RDTP-2274

Starting release 7.0, ThingPark Enterprise users may associate one or several tags to each device or base station.

• Device tags are reported to Application Servers.
• Base station tags are required to configure multicast groups.

More details

Tags are case sensitive, and the maximum tag length is 40 characters. The allowed characters are [0-9][a-z][A-Z]@-_#&:\s.

TPE user interface offers several ways to tag devices or base stations:

• Either from the list view, by selecting the objects to tag and clicking the tag button:

  

  In the list view, unitary device or base station tagging is also possible through the "tag" action accessible via the icon in the last column of the list.

• Or from the map view, by tagging/untagging objects displayed on map. This option is handy to define geographically-based tags.

• Or individually tag a device or base station from the detailed object's dashboard:

  

When available, tags are displayed in Wireless Logger application (in the expandable panel).

Key customer benefits

Tags could be very useful to address the following use-cases:

• Define administrative tags to simplify end-user's fleet management, for instance easily group objects and retrieve device or base station list through tag-based filtering options.

• Specific tags on base stations to make them contribute to transmission of downlink multicast packets. To learn more about multicast, see Downlink multicast RDTP-9925.

• Implement segregated tag-based routing of device traffic to Application Server, as well as implementing segregated processing of uplink device packets according to the device's measurement function.

Feature activation

This feature is automatically available in ThingPark Enterprise release 7.0.

Feature limitations

None.

[UI/UX]: Enhanced filtering and sorting capabilities RDTP-11832

TPE release 7.0 brings several enhancements to the list view of devices and base stations:

• Users can filter the device or base station list according to one or several criteria:

  • For devices: by name or identifier (DevEUI or DevAddr), by health state, by last known battery level, by associated tags or by minimum severity of active - but not acknowledged - alarms).

    

  • For base stations: by name or identifier (LRR-UUID or LRR-ID), by health state, by LRR software version, by associated tags, by RF Region or by minimum severity of active - but not acknowledged - alarms).

    

• The total number of objects (devices or base stations) in the (filtered) list is displayed, even when the list is paginated.

• The page size is configurable, as well as the page number so that users can freely navigate between pages without having to scan them one by one.

• New columns are now available (for instance, object's creation date, active alarms, tags...). Default display shows the most relevant columns, but users may easily select which columns to show or hide.

• The list may be sorted ascendingly or descending, for instance by object name, creation date, last uplink or downlink timestamp, device PER or SF...

• Possibility to export the full (filtered) list to csv format, including columns hidden in the GUI:

  

Additionally, starting release 7.0, users may copy/paste DevEUI/DevAddr or LRR-ID including hyphens between TPE UI and Wireless Logger without having to remove hyphens.

More details

Key customer benefits

Enhanced user experience by easily spotting misbehaving devices or base stations through relevant filtering and sorting actions.

Feature activation

This feature is automatically available in ThingPark Enterprise release 7.0.

Feature limitations

The csv export size is limited to maximum 50 000 objects (devices or base stations).

[UI/UX]: Map view of device and base station lists RDTP-11831

Besides the tabulated list view of base stations and devices, ThingPark Enterprise 7.0 provides a map view to display and search devices or base stations on a map.

More details

Additionally, users may spot a geographical area and search devices or base stations in this area.

The left side of the map displays the paginated list of devices or base stations. It also displays a short summary of individual devices or base stations when users click this specific object.

Map view may be displayed in full-screen mode.

Key customer benefits

Thanks to this feature, ThingPark Enterprise users can easily visualize all their devices or their base stations on the same map screen.

It enhances the user experience by offering a simple way to assess device and base station densities on the map and define potential bad-coverage spots, for instance due to lack of enough number of base stations in each area.

With map view, users have an easy way to tag devices or base stations according to their geographical location.

Feature activation

This feature is automatically available in ThingPark Enterprise release 7.0.

However, it can only be used if a valid map service has been configured by the platform administrator. ThingPark Enterprise supports the following map options:

• Google maps
• Open Street Maps
• Baidu maps

Feature limitations

Clustering of base stations or devices on the map – when number of objects to display is too big - is only available starting ThingPark Enterprise release 7.1.

[UI/UX]: Improved representation of connection status RDTP-12952

Prior to release 7.0, the colored status associated with each Application (renamed Connection in TPE 7.0) in the list displays only the activation status of each connection: green when the connection is activated, orange when it is deactivated.

Starting release 7.0, the colored bullet displayed alongside the logo of each Application/Connection in the list shows the Connection's current health state, combining the activation status with the deployment status (relevant for TPX IoT Flow type of connections).

More details

• ACTIVE: the Connection is active, everything is OK
• INIT: transient state
• ERROR: abnormal state
• DEACTIVATED: the Connection is deactivated by the user

For TPX type of connections, a mouse-over provides the user with a tooltip about the current IoT Flow connection state.

note

If the Connection has been suspended by the system due to expiration of the TPE license, it appears with status "DEACTIVATED" in the UI. To learn more about suspending Connections due to license expiration, see License management enhancements RDTP-12789.

Additionally, the health state of each Connection is displayed in the Connection details:

Key customer benefits

This improvement provides ThingPark Enterprise users with a more comprehensive representation of the actual health state of each Connection, instead of only reference its activation status.

Feature activation

This improvement is directly available once the ThingPark Enterprise platform is upgraded to release 7.0 or higher.

Feature limitations

None.

[UI/UX] Enhanced presentation of the different types of application connections RDTP-16525

Starting release 7.0, the connections towards external Application Servers (AS) are presented in 3 categories:

• ThingPark X IoT Flow connections, leveraging a rich set of cloud connectors as well as general-purpose MQTT and HTTPS connectors. TPX Iot Flow also embeds a driver engine to provide decoded/ready-to-use uplink payloads to AS.

• Basic HTTPS connections, using the LRC-AS tunnel interface. This is the legacy type of connections with direct mode between the network server and AS, unlike the HTTPS connection provided by ThingPark X IoT Flow. Payloads are exchanged with AS in raw/encoded format, as opposed to the payload decoding capabilities offers to TPX Iot Flow.

• Node-RED connection, only relevant for self-hosted TPE. It may be used as an alternative to TPX Iot Flow for resource-constrained deployments with limited CPU/RAM resources.

More details

Additionally, in TPE 7.0, "Applications" are renamed "Connections", for sake of consistency between TPE and TPX user interfaces.

note

All existing AWS, Azure, IBM, MQTT, and ThingWorx application connections are now displayed as TPX connections with TPX logo.

Key customer benefits

ThingPark X IoT Flow connection options are better presented in this release, harmonizing the user experience for AWS, Azure, MQTT, Watson and ThingWorx connections created by users before TPE release 6.1.5.

Feature activation

This improvement is automatically available in ThingPark Enterprise release 7.0.

Feature limitations

None.

License management enhancements RDTP-12789

The scope of this feature is to update TPE SaaS licensing framework to align it with self-hosted TPE.

Starting release 7.0, TPE SaaS subscription licensing relies on a license file automatically uploaded by Actility Central to the TPE SaaS platform, once the Channel Partner creates the subscription/transaction in Actility Central.

Therefore, each TPE SaaS subscription is now associated with a license expiration date, like self-hosted TPE.

More details

For both TPE SaaS and self-hosted TPE, once the license has expired, the TPE administration GUI and DX-API switch to read-only mode, i.e., it is neither possible to add new devices/base stations/connections nor update existing objects.

At the end of the grace period (currently set to 6 months) following the license expiration, the traffic towards external Application Servers is stopped, i.e., uplink packets are not delivered anymore to AS and downlink packets are not accepted anymore from AS.

Warning messages are displayed in TPE GUI to alert the user about license expiry. By default, the first warning is displayed in GUI 30 days before the license expiration date.

Additionally, starting TPE 7.0, the number of granted devices and/or base stations may be "unlimited", this is fully controlled by the license file generated by Actility Central during the subscription creation/update/renewal.

Key customer benefits

This feature offers several enhancements:

• Automation of TPE SaaS subscription creation/update through Actility Central, removing the manual actions performed by Actility's Operations team to manually create/configure each TPE SaaS subscription through Device Manager and Network Manager GUIs.

• User notification in TPE GUI about license expiration, through warning messages.

• Consistent licensing model, offering comprehension enforcement mechanisms to encourage end-customers to renew their subscriptions: Expired subscriptions do not continue serving packets to/from Application Servers after the end of the grace period.

Feature activation

This feature is automatically activated in self-hosted TPE, starting release 7.0.

For TPE SaaS, the following actions must be conducted by Actility's Operations team, upon the upgrade of each SaaS platform to release 7.0:

1. Make sure that the new Connectivity Plans and application options required in release 7.0 have been already created; otherwise, they should be manually created. More details about this task are included in the internal document "ref-tpw7.1-tpe-offer-data-modeling".

2. Update existing TPE Vendors, by adding the new TPE SaaS offers. To perform this task, the Actility team shall use the "vendor update script" as described in this internal technote.

3. Update the TPE SaaS version to "7.0" in Actility Central and use Central API to generate and upload the license files of existing TPE SaaS subscriptions related to this specific SaaS platform.

4. Migrate existing TPE SaaS subscriptions to the new licensing mode, via the migration script provided in this internal technote.

Important

At the end of this migration step:

• TPE SaaS subscriptions having expired since less than 6 months will automatically be switched to read-only mode, until their license is renewed in Actility Central.

• All TPE SaaS subscriptions having already expired since more than 6 months shall automatically be switched to read-only mode and stop exchanging uplink/downlink packets with Application Servers until their license is renewed in Actility Central.

Feature limitations

None.

Display cellular (3G/4G) and WiFi backhaul indicators (RDTP-2420 and RDTP-12898)

This feature provides ThingPark Base Station administrators with specific information related to cellular (3G or 4G) and WiFi types of backhaul between the Base Station and the core network server (also known as LRC).

More details

This information is reported by the Base Station LRR and displayed by TPE GUI in "Networks" widget under each base station.

• For cellular backhaul, the GUI provides the following additional information compared to previous releases:

  • Cellular Operator name and network technology ("3G" or "4G")

  • Received signal strength:

    • If network technology is "3G", it refers to the RSCP (Reference Signal Code Power, click here for detailed definition).

    • If network technology is "4G", it refers to RSRP (Reference Signal Received Power, click here for detailed definition).

      Cellular signal strength is represented by RSCP/RSRP bars, the color depends on the last average value reported by the Base Station (averaged over 10 measurement samples):

	3G	4G
5 green bars	RSCP ≥ -60 dBm	RSRP ≥  -80 dBm
4 green bars	-60 > RSCP ≥ -75	-80 > RSRP ≥ -90
3 orange bars	-75 > RSCP ≥ -85	-90 > RSRP ≥ -100
2 orange bars	-85 > RSCP ≥ -95	-100 > RSRP ≥ -110
1 red bar	-95 > RSCP ≥ -120	-110 > RSRP ≥ -120
0 bar	RSCP < -120 dBm	RSRP < -120 dBm

• For WiFi backhaul, the GUI provides the following information (not supported in previous releases):

  • IP address

  • Total traffic: cumulated amount of data transmitted and received through this interface

  • Round-trip latency: average ping round-trip time for this interface.

  • Network: WiFi SSID + Wi-Fi signal strength, represented by Received Signal Strength Indicator (RSSI) bars, the color depends on the last average RSSI value reported by the Base Station (averaged over 10 measurement samples):

    • 4 green bars: RSSI ≥ -50 dBm

    • 3 green bars: -50 dBm > RSSI ≥ -60 dBm

    • 2 orange bars: -60 dBm > RSSI ≥ -70 dBm

    • 1 orange bar: -70 dBm > RSSI ≥ -80 dBm

    • No bar: RSSI < -80 dBm

Additional cellular indicators shall be supported by TPE GUI in release 7.1 : IMEI, IMSI, ICCID, RSSI, Ec/Io (3G network) as well as RSSI, RSRQ and SINR (4G network).

The definition of the cellular interface state is also enhanced by this feature:

• Up and Used: Cellular interface is up and actively used to connect the Base Station with the core network.

• Ready/Backup: Cellular interface is ready to be used as backup (secondary) interface in case the primary interface fails.

• Service down: Cellular modem is up but the network is down.

• No IP: Cellular modem cannot get a valid IP address from the Mobile Network.

• Registration failed: Cellular modem failed to attach/register to the mobile network.

• Disabled: Cellular modem is currently disabled (not started).

note

The ethernet interface state definition has also been enhanced in release 7.0, for sake of consistency with other interface types: the same definitions above apply to ethernet interface except "Registration failed" that is replaced by "Link down".

Wi-Fi interface states are defined as follows:

• Up and Used: Wi-Fi interface is up and actively used to connect the Base Station with the core network.

• Ready/Backup: Wi-Fi interface is ready to be used as backup (secondary) interface in case the primary interface fails.

• Service down: Wi-Fi modem is up but the network is down.

• No IP: Wi-Fi modem cannot get a valid IP address from the Access Point.

• No signal: Wi-Fi modem cannot scan a valid SSID, or there is no valid RF signal.

• Disabled: Wi-Fi modem is currently disabled (not started).

Key customer benefits

Thanks to this feature, ThingPark network administrators can easily monitor the backhaul connectivity over cellular 3G/4G modems or WiFi and take the appropriate corrective actions in case this connectivity does not offer good-enough quality (for instance a too low RF signal reception, network registration issue, authentication issues...).

Feature activation

This feature is activated by default for any Base Station supporting cellular and/WiFi type of backhaul connectivity and configuring it either as a primary or a secondary network interface. For cellular backhaul, the Base Station should be equipped with a valid 3G/4G SIM card.

note

This feature requires LRR version 2.8.11 or higher.

Feature limitations

None.

[Basic HTTPS connections]: Uplink packet transmission status towards AS RDTP-13837

The scope of this new feature is to display in TPE GUI and Wireless Logger the transmission status of reports sent by the LRC network server to third party Application Servers (AS) over HTTPS tunnel interface.

More details

A report may not be successfully sent to an AS for two reasons:

• The delivery to an AS destination has failed: for instance, due to HTTP error, network error, DNS error, etc.

• Report transmission is dropped by LRC because the AS is either in "Overload" or "Blacklist" state. Routing profiles may fall in this state when they consumed too many handlers. A handler is required to transmit a report to AS destination. As handlers are a limited resource, LRC implements a protection mechanism against irresponsive/very slow AS destinations consuming too many handlers.

Prior to release 7.0, when a report fails to be sent to an AS, no information is reported to the user.

Starting release 7.0, the user can see the transmission status in TPE GUI as well as in Wireless Logger application. This status is available for all the reports sent by LRC to third party AS over HTTPS tunnel interface:

• Uplink Frame Reports (DevEUI_uplink)

• Downlink Frame Sent Reports (DevEUI_downlink_Sent)

• Multicast Summary Reports (DevEUI_multicast_summary)

• Device Location Reports (DevEUI_location)

• Device Notification Reports (DevEUI_notification)

To learn more about these reports, see LRC-AS Tunnel Interface Developer Guide.

Delivery status in ThingPark Enterprise GUI

On Connection dashboard, in "Last 25 packets" widget, a new column "Delivery to app." is added to display the transmission status of uplink reports sent to Application Servers.

note

This column is available only for Basic HTTPS types of connections.

Delivery status in WLogger application

This feature brings the following changes to packet display in WLogger:

• Uplink icon is enhanced to display AS delivery error. If report failed to be delivered to an AS, the icon × is displayed instead of . For passive roaming uplink, ×PR is displayed.

• For all types of packets/reports, the expansion panel is enriched with a new array: Delivery status and transmission errors to all targeted AS destinations is displayed, as per the following illustrative example.

  • A global transmission status is displayed alongside the status of each individual AS destination (URL).

  • Whenever relevant for a given AS destination (URL), an error message is provided for debug purposes: In case of HTTP error for example, the message would be <Error code> HTTP Error. If the error is not caused by the Application Server, the message would be "Network server internal error".

    

Key customer benefits

This feature provides ThingPark Enterprise users with real-time information about the delivery status of the network reports towards third party Application Servers. This information is very useful to debug delivery issues to AS and take the appropriate corrective actions by AS developers in case AS behavior is too slow / occasionally blacklisted.

Feature activation

This feature is activated automatically upon system upgrade to release 7.0.

Feature limitations

This scope of this feature is limited to Application Servers using Basic HTTPS protocol over the LRC-AS tunnel interface. It does not cover TPX connectors (Azure, AWS, generic MQTT, HTTPS...) offered by ThingPark X Iot Flow.

Quick access to ThingPark Marketplace from TPE UI RDTP-7922

A new button "Marketplace" is added in the top banner, besides the search space:

It allows users to navigate to ThingPark Marketplace to buy IoT things.

More details

Key customer benefits

Improved user experience to directly navigate to ThingPark Market when users want to buy IoT things, going from accessories through devices or base stations up to full solution kits.

Through ThingPark Market, users can easily consult the available offers for each IoT vertical:

Feature activation

This feature is activated by default in release 7.0.

It may be deactivated by the ThingPark Enterprise partner:

• For self-hosted TPE: the marketplace URL is configurable in TPE Cockpit, under TPE Configuration panel > ThingPark service configuration > Proxy settings.

  

• For TPE SaaS: Each partner entitled with a Vendor role may enable/disable the display of the marketplace URL for the underlying TPE subscriptions.

  

Feature limitations

None.

Support LoRaWAN® 1.0.4 RDTP-14248

Starting release 7.0, LoRaWAN® 1.0.4 becomes officially supported by ThingPark. You can download the LoRaWAN® 1.0.4 specification from the LoRa Alliance website.

More details

The main changes related to LoRaWAN® 1.0.4 are:

• ADR modifications:

  • A new value (0xF, decimal 15) has been introduced in TXPower and DataRate fields to represent a "don't care" setting. Hence, if the device unsets ADR-bit in uplink frame header (ADR-bit = 0), while the network may still send LinkADRReq commands to update the Channel Mask, it uses the value 0xF for TXPower and DataRate to let the device keep its current settings for those fields.

  • A new definition of the ADR-bit of DL frames: When the device sees that the network has unset the ADR-bit in the DL frames, it understands that the network is unable to control its uplink ADR. Hence, the device may disable network-controlled ADR by putting ADR-bit = 0 in UL frames.

    Hence, starting release 7.0, the network server sets downlink ADR-bit to 1 by default, unless the LinkADRReq command is not activated in the Device Profile.

Key customer benefits

This feature allows ThingPark users to onboard the most recent devices into their networks, leveraging the latest LoRaWAN® release 1.0.4 issued by the LoRa Alliance.

LoRaWAN® 1.0.4 bundles a set of clarifications and security enhancements to the MAC layer such as:

• Prohibition of frame counter reset for ABP devices

• Security enforcement during Join procedure of OTA devices, through the enforcement of counter-based DevNonce/JoinNonce

• Miscellaneous clarifications on device behavior to avoid implementation glitches.

Feature activation

This feature is available once the platform is upgraded to release 7.0.

To provision LoRaWAN® 1.0.4 devices in ThingPark, the subscriber shall associate them with a profile supporting LoRaWAN® 1.0.4.

note

Actility's Device Profile catalog has been enriched with new generic device profiles associated with LoRaWAN® 1.0.4.

Feature limitations

LoRaWAN® 1.0.4 brought some terminology changes compared to previous LoRaWAN® versions:

• MType is renamed Ftype

• In DevStatusAns payload, the Margin field is renamed RadioStatus

• [Class C]: the extended RX2 window is renamed RXC.

Some of these fields are displayed in Wireless Logger application but the pre-1.0.4 terminology still applies in release 7.0.

Support LoRaWAN® backend interfaces 1.1 RDTP-11369

LoRaWAN® backend interfaces specification defines a standard interface to exchange messages between Network Servers, to support roaming between home and visited networks. It also defines a standard data plane interface between Network Servers and Join Servers, to support activation call flow of OTA devices.

In release 7.0, ThingPark Network Servers and Join Servers support the latest official LoRaWAN® backend interfaces v1.1 besides the original v1.0 supported from previous releases.

More details

You can download the latest LoRaWAN® Backend Interfaces specification v1.1.0 from the LoRa Alliance website.

Here are some changes brought by Backend Interfaces v1.1 compared to v1.0 (non-exhaustive list):

• Support of network geolocation for roaming devices (to learn more, see Geolocation in passive roaming RDTP-5820.

• Additional result codes over NS-NS and NS-JS interfaces, for instance to indicate frame replay situations...

• Enhanced management of uplink frame duplication on serving NS, via the explicit flag "DupUL".

• Support of alternative NS identification by "NSID", besides NetID.

• Addition of a PRStartNotif message (to report the transmission status of JoinAccept to serving/home NS) and ErrorNotif message (error notification of invalid answer messages).

• RFRegion clarification and new RFParamSetID (useful to support multiple RF Regions per forwarding NS, differentiated by their ID).

• Serving NS reporting of the device's unique identifier (DevEUI) to forwarding NS in the PRStartAns (in case of success).

Both v1.0 and v1.1 versions of the LoRaWAN® Backend Interfaces specification remain supported as of release 7.0, which guarantees backward compatibility with third-party NS/JS vendors that have not yet adopted v1.1.

Key customer benefits

Thanks to the support of LoRaWAN® Backend Interfaces v1.1, ThingPark supports additional roaming/activation use cases as of release 7.0:

• Roaming for Networks using a shared NetID (with NetID > 1); in this case, the routing of roaming messages to/from these Networks becomes based on NSID (unique NS identifier per ThingPark core network platform) rather than the shared NetID.

• Roam-in for Networks using private NetID (0 or 1), meaning that a LoRaWAN® network using NetID 0 or 1 can still forward UL frames from foreign devices to their home Network if this latter has a dedicated NetID > 1.

• Activation of OTA devices on external Join Servers, when the home Network uses NetID 0, 1 or another shared NetID.

Additionally, this new feature makes it possible to implement device-based billing policies, since fNS knows the DevEUI of each visiting device.

Feature activation

Using v1.1 of the Backend Interface protocol requires that both sender and receiver parties support this version. If at least one party does not support v1.1, the communication protocol shall use v1.0. ThingPark Exchange (TEX) propagates the protocol version of each peer NS/JS to the home Network Server.

Additionally, to activate the use of v1.1, each LRC Network Server should be associated with a unique NSID, assigned by Actility NetOps team.

• For TPE SaaS: NSID is directly configured by Actility's NetOps team, alongside the backend protocol version, in LRC's Operator table (table O).

• For self-hosted TPE: NSID is configured by the ThingPark Enterprise administrator or system integrator, under TPE Configuration > LoRa configuration > TEX configuration.

Feature limitations

None.

Geolocation in passive roaming RDTP-5820

LoRaWAN® Backend Interface specification v1.1 introduced the support of network geolocation use-case for roaming devices, through the amendment of the uplink metadata sent by forwarding network servers (fNS) with geolocation-specific information. To learn more about LoRaWAN® Backend Interface v1.1, see TS002-1.1.0 LoRaWAN® Backend Interfaces.

The additional geolocation-specific uplink metadata includes the AntennaID, Fine timestamp (a high-resolution timestamp with nanosecond precision) and gateway altitude besides other gateway information such as longitude/latitude.

More details

Key customer benefits

This feature extends the use-cases supported in passive roaming mode, by allowing the serving NS (sNS) to leverage RF macro diversity (that is the ability to receive the same LoRaWAN® uplink frame through several gateways) offered by fNS in its network geolocation offer.

• In case of overlapping/complementary coverage between the home network's own gateways and roaming partners' gateways: thanks to this feature, sNS can rely on the combined coverage of home + foreign gateways to enhance the precision of the location resolution without deploying new gateways.

• If there is no coverage overlap between sNS and fNS: this feature allows sNS  network administrators to continue supporting network geolocation services even when their devices roam away from home, ensuring value-added service continuity for such roaming devices.

Feature activation

To use this feature, both the forwarding (fNS) and serving (sNS) network servers should be configured to use LoRaWAN® backend interfaces v1.1 (to learn more, see Support LoRaWAN® backend interfaces 1.1 RDTP-11369.

Additionally, both roaming and network geolocation features should be activated for the devices in question.

Feature limitations

In the current release, the resolution of the device location is done by the device's home network (sNS, serving Network Server). The other mode defined by LoRaWAN® specification (allowing the forwarding NS to directly compute the location resolution and send it to sNS) is not supported in this ThingPark release.

[UI/UX]: Simplified mass import of devices RDTP-8481

When creating devices by mass import in TPE GUI, the device model ID of each created device must be specified in the CSV file.

• Prior to release 7.0, users can find the model ID information by searching for the model in the GUI (under device creation page or in the device management dashboard), the model ID is displayed in the device model drop-down menu.

• With this improvement in release 7.0, the TPE user can download a CSV file containing the list of device model IDs from the GUI. The file is called "Models list":

  

  -> Only device models compatible with configured ISM bands are present in this list.

More details

Key customer benefits

Enhanced user experience for device mass import.

Feature activation

Not applicable.

Feature limitations

None.

[UI/UX]: Enhanced login/authentication experience (RDTP-6894 and RDTP-10501)

Starting TPE release 7.0, TPE portal GUI and Wireless Logger GUI use Open ID Connect authentication flows, based on OAuth2 protocol.

More details

Key customer benefits

Enhanced user experience for login/logout and session management.

Feature activation

This enhancement is automatically available after upgrade to release 7.0.

Feature limitations

None.