DLMS over TTN/Integration

Yes, That was me too last year or two (GIYF) :wink: , clients have LoRa/Mod-Bus & LoRa/WMBus solutions and ideas but its the direct messaging of DLMS interfacing with LoRa/LoRaWAN that’s now a challenge. There is a working group/team looking at this so I will likely have to wait 'til they spit something out…

at 50:18.

Some guys here in Russia have been trying to tunnel DLMS over LoRaWAN.

AFAIK it doesn’t work yet, even though there are two channels with no duty cycle restrictions here in Russia.

Good to know thanks

“ANDREA Informatique : ANDREA demonstrates the pertinence of the LoRa technology in the Smart Metering sector. In this example, Pegasus, the ANDREA’s DLMS certified meter, is a LoRa device and it is connected to the Actility LoRaWAN Network by means of the MultiTech Conduit AP gateway. ANDREA’s SmartHawk (The DLMS Meter Configuration Tool) is used as the meter reading application. SmartHawk will send requests to, and receive responses from, the Pegasus LoRa Meter. In the demo it is possible to read/write, among others, the Clock, Energy registers, Load Profile, etc.”

Those guys (Lartech) say that there’s “DLMS over LoRaWAN” working group somewhere in the deep dungeons of LoRa Alliance. EDF, Sagemcom… Lartech :slight_smile:

Hi everyone!
We’ve got a complete solution for DLMS thru LoRaWAN.
Send us a request and we’ll provide a datasheet for ORION METER LoRaWAN DLMS
info@orion-m2m.com
http://orion-m2m.com/en/product-catalog/equipment/orion-meter/

1 Like

can you explain how to connect with TTN ?

Collects data on consumption of hot and cold water, gas, electricity with further transfer through OrionM2M network to the service provider

Good to know - has it been validated and agreed through the DLMS Sub-working group within the LoRa Alliance? Are you engaged through that team also?

https://tools.ietf.org/html/draft-ietf-lpwan-schc-over-lorawan-04

This seems to be the basement for “the official implementation” of DLMS over LoRaWAN.

1 Like

Hi, for anyone who’s interested in utility metering over LoRaWAN using DLMS/COSEM, please see:

In my opinion this is going to be a big deal for LoRaWAN, both regarding serious uptake by utilities, and also because it establishes IETF SCHC as a true standard encoding.

This is the IEC, IETF and LoRa Alliance working together on standards… that can only be a good thing.

1 Like

https://lora-alliance.org/events/applications-dlms-over-lorawanr

Hi Jeff, if your interest for DLMS over LoRaWAN is still alive, I would be happy to help. We’re a LoRa Alliance member, DLMS member, Euridis member, and we have been heavy promoter of an IETF standard that now enables your dream to come true :slight_smile: Our first partner meter is about to be disclosed (PR to be released soon), or real field deployment is happening in a matter of days, and we’re involved in both LoRa and DLMS workgroups for promoting such capabilities. When it comes to TTN, we’re open. It’s just a beginning…

Hi All, for those interested in this topic, the implementation of the SCHC standard with LoRaWAN meters is now effective. This has been deployed and confirmed effective on the field with a utility testing remote data collection and connect/disconnect with multiple meters.

The solution is formally backed by both the DLMS/COSEM specifications and LoRa Alliance following a joint effort. The full end to end certification process is on its way, and the tools to integrate that in any DLMS meter with any LoRaWAN module are arriving in a few days.

It’s tested, uses approved/official standards end to end, and also fully compatible with TTN.
First deployments were on EU868 regional parameters and we are about to deploy in AU915 and AS923.

1 Like

From your field tests have you established typical base line traffic patterns for example use cases? # & size of uplinks/traffic volumes, ditto downlinks?

“…also fully compatible with TTN.” Remembering always TTN FUP, esp wrt downlinks and also limit is to be taken as exceptional and weekly or monthly rather than daily if to be fair to other ttn community users, especially at the scale of typical meter deployments :wink:

Hi Jeff-UK,

Thanks for the comment.
Regarding TTN compatibility, this is indeed to adjust to both the use case expectations/metering requirements and TTN specificities.

The use case we have tested with metering was involving another LNS but this showed that beyond the restriction of each LNS features, particularly in term of multicast or Firmware upgrade or Community Edition vs On Premise full featured deployment, LoRaWAN is able to support DLMS/COSEM. Regarding TTN, you are right regarding the downlink and I now remember that one of our engineers highlighted that point when relating to TTN.

Each case will be different, as it is a combination of available spectrum/local regulation and regional parameters, combined with the LNS capabilities and metering data to collect, at a given periodicity.

On a new project, we observe, analyse and take into account those parameters to define the suitability and performance we can expect from the LoRaWAN network and context. Traffic size is anticipated to ensure that ToA will enable us to effectively deploy the use case.

Regarding the tested case, the customer prevents us from publicly communicating detailed results as they are still unclear regarding which technology they want to deploy in the end, but we would be happy to discuss the context we were operating if this of interest for you.

What I can say is that the use case was covering a typical smart metering deployment, with meter reads every 30mn, plus daily, weekly and monthly data collected. We have defined a typical use case traffic that is a baseline that can be adjusted depending on each utility need.In other contexts, we are able to go down to 15mn reads.

The fragmentation mechanism involved makes it easier for LoRaWAN to transmit less frequently large amount of data, but collecting billing-grade and additional load/quality data on a recurring basis is fully validated, same for remote disconnect (downlink) or instantaneous read requests (a few seconds which was said to be a great performance compared to other widely deployed technologies).

Conclusions are:

  • we’re looking at larger volumes now to show that size does not matter and that the solution works at scale
  • we’re deploying in other context to confirm that the solution is suitable in different environments
  • we’d be happy to further discuss and while events keep being postponed, we will attend The Things Conference and also the LoRaWAN World Expo. In the meantime, we are open to discuss the topic
1 Like

I see it working well potentially with TTS - either cloud or self hosted (enterprise) instances but always wary of such projects at scale on TTS(CE) - TTN :slight_smile: For lower uplink rate deployments and where FUOTA not mandated then I’m sure it can play niceley with TTN and will look again at some old opportunities where it may apply. (Sadly COVID & associated repeat Lockdowns killed momentum there… :frowning: )

I assume that is looking at classic Industrial/Half-Hourly billing and suppplier switching type applications?

Still glad to hear it has made such progress…been watching this off and on since ~late 2015 and had 1st meter customer meets as far back as 1H 2016 so been a while coming! :tada:

Indeed we don’t see much demand for TTx interoperability because of the large scale context. But TTx is an opportunity to expand the adoption of the technology and enable anyone to try/test/experiment in their context or deploy at small scale.
Limited features/use cases in a TTx constrained environment is still an opportunity to expand LoRaWAN adoption for electricity metering, and at some point this is the benefit we are targeting. Not all utilities are equals and medium or small scaled cooperatives could still see an interesting option with TTx. Indirectly, more LoRaWAN networks for utility applications means more TTx users to develop more devices and more use cases in this segment. That’s also the reason why I’m not ashamed to post here though TTx is not the most common LNS we come across.

Single phase residential is the primary target and what we tested (this is also the largest market). 30mn reads is sufficient in most cases, though there’s a trend of demand pushing to the quarter, which remains feasible depending on the utility expectations (and budget. For Residential, LoRaWAN means a much much cheaper solution than a full featured cellular or overexpensive RF mesh based AMI.)

In Industrial, the cost justification is less significant. Here, the interest is more related to the versatility of the LoRaWAN network with multiple additional devices available to cover other use cases with the same network. But three phases have a cost and though it’s not impossible, billing+quality and load monitoring + Time of Use billing with multiple tarriffs are slightly more challenging than standard residential metering. In such case, applying different levels of SCHC compression really helps.

Regarding timeline, some utilities in different countries haven’t progressed much since 2015. Back at that time, I was hearing that most Brazil companies where expecting to deploy massively RF Mesh solutions. Same in Thailand and other markets. 6 years later, they haven’t reached 5% and I still hear the same melody. Luckily, if we don’t consider the EU+UK market, DLMS over LoRaWAN does not seem to arrive too late :slight_smile:

Happy to follow up around a coffee or beer :slight_smile:

1 Like

Hi Guys,

I failed to provide you with an update on this topic (should it still interest people in this community).

DLMS over LoRaWAN is now available to the community through Acklio Dev Program.
It’s free, and it’s there : https://ackl.io

Solution relies on the SCHC standard (RFC 8724) which is used to enable IPv6 over LoRaWAN (LoRa Alliance Tech Spec 010, also available on the Acklio website and also free).

Anyone interested can reach out to us, some of our staff will attend The Thing Conference.

Sony

1 Like

Thanks for the update Mr.N :slight_smile:
In the context of this forum and the community I noted that your website calls out existing operation with 5 other LoRaWAN/NS operators but no shout for TTN (for initial POC testing and dev of small qty devices perhaps) or more importantly TTI either OS, Hosted or Enterprise instances for medium or high volume DLMS over LoRaWAN commercial deployments, per previous thread discussion/comments. Can you confirm if this is already in place or in progress? If still WIP when planned available release. I know a few community and eco-system people who indeed were/still are interested in real implementations and will pass on link to your post :wink: