Hi Forumites…don’t suppose anyone here has experience of looking at use of DLMS on TTN? I did a quick search of TTN forum over Easter period and no thread searches for DLMS or IEC 62056 showed up, same this week. Anyone experienced with DLMS over LoRa? I see a couple of poss pilot opps in smart metering apps in Eu & developing countries where TTN or TTI might be option…
Have seen (elsewhere) ref to DLMS conversions to other protocols (e.g. ModBus) via ‘gateways’ that I guess might then lend themselves to messaging over LoRa but that sounds inefficient.
I have experience with DLMS but I don’t keep track of applications.
You can certainly send it over LoRaWAN but you will be limited to small unconfirmed messages sent upstream only. By small I mean perhaps a single accumulated register, plus maybe some status information.
I expect the reason to use DLMS would be because you are plugging into an existing system and/or want to use the same end-to-end security you would have if connecting to the meter by some other means.
DLMS encoding is reasonably compact but LoRaWAN is severely constrained at the lowest data rates. DLMS messages would look quite large compared to what most people plan on sending.
Thanks @cjhdev was afraid that might be the case. May have to look at constraiing to SF<=10 to keep data rate up…also the new Semtech Si supporting SF<7 for higher density networks might help in built up urban areas for metering…
Yes, That was me too last year or two (GIYF) , 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…
“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.”
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.
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 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.
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
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
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 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… )
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!
, 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…
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…
)