1. Topics
  2. [External] : [Hyperledger Fabric] IoT with frequent data and possibly incorrect data sometimes

[External] : [Hyperledger Fabric] IoT with frequent data and possibly incorrect data sometimes

Mark Rakhmilevich
 

You can register the IoT devices as client orgs of the trusted node with their own signing certs. Instead of sending an avg, send the actual data and let the chaincode maintain a running average and filter the outliers.

Regards,
     Mark



On Apr 28, 2021, at 4:21 AM, mahwish.anwar@... wrote:

In an IoT scenario, multiple nodes are sending frequent data. It is not feasible to create a fabric network with all devices.
Instead, a fabric node acts as an aggregator, that takes all values from 100s of devices. Note, some of these values can be wrong. So the aggregator filters outliers. Then the aggregator sends an average - one stream to the server so it can take decisions. The aggregator is a fabric peer so is trusted.

One, if a single stream is sent over to the server, then we lose the information - which IoT device sent which data. Any other way?
Second, there is a single point of failure. What else can be a good option? How else to drop outliers?
Mahwish Anwar
 

Thanks for your reply.
You mean, like we register users in an org? 
These users are defined in crypto-config.yaml and cryptogen assigns IDs to all. New users are added via the client API.
When devices are added from the API (similar to the way users are now added), are they supposed to be mentioned in any config file?

For simulation purposes, how could it be done?
Nikos Karamolegkos
 

So you propose each IoT end device (ED) to be an organization? The EDs can not support fabric to run the a fabric client application and  start a transaction, somehow a proxy (or a IoT) should translate the IoT data and send them to BC. Is this feasible?
Mark Rakhmilevich
 

If you are using client SDK for Fabric, use register() and enroll() APIs to register client orgs and issue their enrollment cert.

Mark


On Apr 29, 2021, at 1:41 AM, mahwish.anwar@... wrote:

Thanks for your reply.
You mean, like we register users in an org? 
These users are defined in crypto-config.yaml and cryptogen assigns IDs to all. New users are added via the client API.
When devices are added from the API (similar to the way users are now added), are they supposed to be mentioned in any config file?

For simulation purposes, how could it be done?

Mark Rakhmilevich
 

Yes, an aggregator running the client SDK would be needed.  In Oracle Blockchain Platform we provide a built in aggregator with REST APIs.  If the IOT devices can make REST calls, that’s all that’s needed.

Mark


On Apr 29, 2021, at 2:10 AM, Nikos Karamolegkos <nkaram@...> wrote:

So you propose each IoT end device (ED) to be an organization? The EDs can not support fabric to run the a fabric client application and  start a transaction, somehow a proxy (or a IoT) should translate the IoT data and send them to BC. Is this feasible?

Nikos Karamolegkos
 

Can you give more details about your use case? Is each end device a different organization? Also can you tell me more about the type of EDs you use and how you set up the general architecture of the BC network? For example all these device in the same channel? Are there IoT GWs?

On 30 Apr 2021 03:36, Mark Rakhmilevich <mark.rakhmilevich@...> wrote:
If you are using client SDK for Fabric, use register() and enroll() APIs to register client orgs and issue their enrollment cert.

Mark


On Apr 29, 2021, at 1:41 AM, mahwish.anwar@... wrote:

Thanks for your reply.
You mean, like we register users in an org? 
These users are defined in crypto-config.yaml and cryptogen assigns IDs to all. New users are added via the client API.
When devices are added from the API (similar to the way users are now added), are they supposed to be mentioned in any config file?

For simulation purposes, how could it be done?

Mahwish Anwar
 

I see. This aggregator does not have to be then part of the fabric NW? 
Anything that becomes part of fabric will have access to view the blockchain.
Nikos Karamolegkos
 

So mark in order to recap, you propose each ED to be a different user which send data via REST to an aggregator (i.e a BC client) who acts as intermediate to match the data from each ED to the respective BC user? Are this EDs belong to the same organization in order use the same aggregator?
Mark Rakhmilevich
 

Hi Nikos,

   Yes, that’s one common approach we’ve seen.  The EDs don’t have to belong to the same organization, they could send their data to different aggregators if desired based on some contractual agreements, geolocation, etc..  The point is that a Fabric org with an MSPId can register and enroll client orgs, which then get a unique certificate – with the MSPId of the issuing org but the unique enrollment name in CN field.  Their transaction is then signed by that cert and the chaincode can extract the unique CN to apply any relevant access rules or other business logic.

 

Best Regards,

   Mark

 

From: fabric@... <fabric@...> On Behalf Of Nikos Karamolegkos
Sent: Wednesday, May 5, 2021 2:13 AM
To: fabric@...
Subject: Re: [External] : [Hyperledger Fabric] IoT with frequent data and possibly incorrect data sometimes

 

So mark in order to recap, you propose each ED to be a different user which send data via REST to an aggregator (i.e a BC client) who acts as intermediate to match the data from each ED to the respective BC user? Are this EDs belong to the same organization in order use the same aggregator?

Mahwish Anwar
 

Thanks for all replies. 
So, we are saying that, 

ED register via REST. These ED can be same or different orgs.
ED send messages via REST with their tokens. I am using JWT. Any better option? This token is a private key for the ED.

I am doing the same to register users for an org.

Back to my question, so theoretically I can assume user or ED - depending on the scenario. Nothing changes in terms of implementation?
--
Regards,
Mahwish Anwar.
1 - 10 of 10