Modern IoT deployments do require considerable investments that might only be justified if the data being gathered could bemonetized, which leads to the need for a digital data marketplace. In many cases, the provider of the IoT data needs to process itlocally for data curation, aggregation, streamprocessing, etc. At the same time, the consumer could be interested in nearby data.Thisscenario resembles a fog computing architecture where companies require being able, keeping data under their control, to securelymake it available to other companies in a peer-to-peer fashion, without needing a cloud intermediary (like traditional marketplacesdo), thusmaximizing the locality of the processing and avoiding the existence of a bottleneckwhen the intermediarymakes the datadelivery for accounting purposes. Nevertheless, this imposes a hard requirement: by not having a central marketplace, the peers(seller and customer) need to trust each other, which, in turn, requires enforcing a nonrepudiation schema. In this paper, the authorspropose a distributed peer-to-peer architecture for such a data marketplace that takes advantage of the architectural fundamentalsof fog computing, in which data processing, filtering, and stream based event generation is done in a fog node along with the data,and where relationships, both commercial agreements and data delivery, are performed directly between producers and consumerswithout the need of mutual trust thanks to the usage of blockchain principles (e.g., distributed ledger, consensus mechanism).Theproposed architecture is validated through a case study involving a set of key issues regarding nonrepudiation commonly identifiedwhen moving from a centralized marketplace to a distributed one. Moreover, it is shown that the proposed solution does not bringin any limitation with regard to a centralized marketplace solution, in terms of pricing models (subscriptions, pay-per-use, etc.) orusage conditions (contract duration, updates rate, etc.).
1. Introduction
Data is becoming one of the most valuable assets, beingconsidered even more important than oil ([1, 2]). This state-ment applies to many data sources, including those generatedwith IoT sensors. Many companies which have modern IoTdeployments do require considerable investments that mightnot be justified for the expected revenue due to the exploita-tion of the generated information internally by the owner.This may generate reluctances among companies willing toexploit that information, especially when only a portionof that information is directly profitable for the company.Besides, such IoT deployments generate huge amounts ofdata that might be interesting both for companies in the
same sector (competitors) and for companies on other sectorsbut that do benefit from such information. In the lattercase, performing the deployment by themselves is even moreunlikely. In many cases, the provider of the IoT data needsto process it locally for data curation, data aggregation, andevent generation based on stream processing, etc. At thesame time, the consumer could be interested in nearby data,leading to a scenario that resembles fog computing ones.
An example of such scenario is a company owningthe air quality sensors deployed along a city in multiplefog nodes, each of them making local processing for theabove-mentioned purposes, and a number of smart buildingsdistributed all along the city, requiring the data from theclosest fog node to feed the algorithms controlling their
HindawiWireless Communications and Mobile ComputingVolume 2018, Article ID 5758741, 15 pageshttps://doi.org/10.1155/2018/5758741
smart systems (e.g., free cooling operation, air conditioningoptimization, predictive maintenance of air filters, and usersafety protocols).
This scenario introduces the need of a digital marketplaceto satisfy both interests: the owner of an IoT deploymentbeing able to monetize data by selling it, and other companiesbeing able to leverage on that data tomake their businesses oraccomplish their goals.
These interactions have traditionally taken place onelectronic marketplaces [3] which serve as central marketsto integrate offerings from multiple sellers providing notjust a product catalog for search, discovery, and comparison[4], but also transaction support in terms of negotiation,contracting, and settlement [5]. Traditional marketplaces,besides, represent a central point of failure, an interactionbottleneck and do play a special role in between sellers andconsumers, who both need to trust him.
To overcome this limitation, [6] proposes distribut-ing the marketplace as a peer-to-peer network. In such amarketplace, resembling a fog computing architecture asrequested in [7], there is no need of a cloud intermediary(like traditional marketplaces do [8]), thus maximizing thelocality of the processing and avoiding the existence of abottleneck when the intermediary makes the data delivery foraccounting purposes (e.g., Apigee). In addition, companiesare able on their own (under their control) to securely makethose data available to other companies when using a peer-to-peer fashion. Nevertheless, this imposes a hard requirement:by not having a central marketplace, the peers (producer andconsumer) need to trust each other, which, in turn, requiresenforcing a nonrepudiation schema.
Authors in [6, 9] propose the usage of blockchain prin-ciples [10] (e.g., distributed ledger, consensus protocol, andpublic key cryptographic system) to manage trust on peer-to-peer distributed marketplaces.
In this paper, the authors propose a distributed peer-to-peer architecture which takes advantage of the architecturalfundamentals of fog computing, in which data processing,filtering, and stream based event generation is done ina fog node along with the data, and where relationships,commercial agreements, data delivery, access control, andaccess log are performed directly between producers andconsumers without the need of mutual trust or central role,thanks to the usage of blockchain principles. The proposedarchitecture is validated through a study case involving a setof key issues regarding nonrepudiation commonly identifiedwhenmoving from a centralized marketplace to a distributedone. Moreover, it is shown that the proposed solution doesnot bring in any limitation with regard to a centralized mar-ketplace solution, in terms of pricing models (subscriptions,pay-per-use, etc.) or usage conditions (contract duration, rateof data updates, etc.).
2. Related Work
As explained, blockchain technology has been proposed fordistributing data marketplaces. Besides, some marketplacefunctions have also been implemented using distributedledger technologies and are relevant for the design of such a
distributed marketplace, such as how to distribute the data orhow to control the access to it considering privacy concerns.
For data distribution using blockchain technology, someauthors propose using an off-blockchain storage based ondistributed hash tables (DHT), where links to reallocationof data are encrypted inside blocks [11]. This scheme isreplicated on [12] for healthcare data sharing and on [13]for building a trackable and reputable distributed file systemcalled InterPlanetary File System (IPFS). The benefit isthe off-loading of the distributed ledger of the data itself,maintaining access-control and integrity capabilities. Thisdistribution mechanism, however, does not allow severalaccounting schemes required for usage-based price models,such as volume of information accessed.
Privacy management and access-control of shared dataare also tackled using blockchain technology, especially onthe medical sector for privately sharing Electronic MedicalRecords (EMRs) with institutions other than the ones thatgenerate such information, and giving the patient the controlof her data. The works [14, 15] are relevant proposals usingthis scheme. And regarding IoT data sharing, [16] proposesfine-grained smart contracts based access-control scheme.
Regarding the monetization of IoT data, there are purelycentralized proposals such as [17], marketplace centralizedboth on the data catalog and on the exchange itself where IoTdata providers register their offers and help the consumersfinding them. There is also a commercial centralized cloud-based marketplace call Terbine (http://www.terbine.com/)offering high control on how IoT data can be used.The paper[18] gives one step towards the decentralization by empow-ering data providers with the ability to define sharing prefer-ences and data privacy and deliver the data to consumers ina peer-to-peer fashion, whereas the data marketplace wheretheir offers are published is centralized.
There are also some approaches that propose a distributedsolution for the creation of an IoT data marketplace. Wornerdoes present on [19] (which extends [20]) a prototype of adecentralized data market directly payable API endpoint forpeer-to-peer data exchange and payments, based on Bitcoinmicropayments. OpenBazaar proposes peer-to-peer market-places to directly connect data providers and consumersusing Bitcoin as their digital cryptocurrency.Micropayments,however, have turned into unfeasible with cryptocurrencieswhose transaction fees have dramatically escalated such asBitcoin or Ethereum [21]. Latest proposals are not tied toany specific cryptocurrency or payment method such asIoT layer, a commercial blockchain-based security layer fordirect access to IoT devices with minimal access-by-paymentoptions, or Ocean Protocol [22], a recent decentralizedblockchain-based marketplace for data distribution with afocus on Artificial Intelligence and services execution on thedata location.
3. Case Study and Requirements
The case study presents a distributed data marketplace anddeals with the advertisement and acquisition of data betweentwo untrusted peers of the network, each of them havingtheir own fog node for local data processing. Company A
provides smart city services on different verticals. As part ofthese services, Company A owns a set of air quality sensorsalong different neighborhoods of the city, which generate rawdata, grouped together in a set of fog nodes each of themcapturing, curating, and processing raw data of a particulargeographic area. Within each of this fog nodes, raw sensordata is fine-tuned, aggregated, and processed to generate highlevel information. Besides, CEP (Complex Event Processing)is also performed at local level in order to detect anomaloussituations. Finally, processed data is sent to company facilitiesfor performing big data processing at a city level.
Within this scenario, Company A realizes that part of thedata produced in the different nodes could be monetized andshared with interested peers, generating an extra profit forthe company, under certain terms and conditions, such asnot using such data for creating competing solutions, or notreselling it.
Company B owns a smart building which includes aset of sensors and actuators for the optimization of theirHVAC systems (heating, ventilation, and air conditioning),controlling locally factors such as temperature, humidity,water flows, pump speeds, and fan speeds in order toautomatically maintain proper conditions while optimizingthe consumption of the systems.
In the described scenario, Company B decides to improvetheir HVAC management by incorporating a free coolingsystem, which optimizes the consumption using low externaltemperature levels to regulate building climatization by incor-porating air from the outside into the HVAC system. How-ever, this introduces extra control requirements of pollutantlevels to avoid unhealthy conditions and maintain air filters,requiring a stream of air quality information of the particulararea. This data stream can be acquired from the node thatCompany A owns in the area.
3.1. High Level Requirements. The proposed use case hassome high level requirements that the system used for thedata sharing and monetization has to satisfy in order tobe successful. First of all, there must exist interoperabilitybetween the fog nodes; that is, one fog node should beable to understand the format and the protocol of the datastreams of the other participants to be able to incorporate thisinformation into its processes.
Additionally, a data marketplace able to advertise datastreams, managing pricing, and usage terms has to be incor-porated.This system has to be able to grant access to acquireddata and make accounting of the consumption in order tosupport pay-per-use and validate that terms and conditionsare satisfied. However, for the proposed scenario where thedifferent participants process data locally in a fog node, acentralized approach is not suitable, since it introduces theneed for an intermediary playing an special role (which theparticipants have to trust on) and represent a central point offailure.
Distributing the marketplace introduces the need totrust about the validity of published offerings, the signedagreements between providers and consumers, and the datarequested and interchanged among peers. In a centralizedmarketplace, it acts as 3rd party performing the first two of
NGSI DataCEP
Data App
Non NGSIDevices
Context Broker
IoT Agent
NGSIDevices
Blockchain–basedCommunication
system
· · ·
Figure 1: Local node architecture for data processing.
them, provided that the peers trust the marketplace, but theformer is not easily realized.
4. Proposed Solution
In this paper, the authors present a distributed peer-to-peerdata marketplace in a fog computing scenario, enforcingtrust and nonrepudiation among peers. Trust is performedby using distributed ledger, leveraging blockchain technologyfor immutable and nonrepudiable advertisement of offerings,sign of agreements and for accounting on the data requestedand sent. We propose a fog computing architecture wheremarketplace peers are fog nodes providing or acquiring data,where nodes based on FIWARE (https://www.fiware.org)technology hold their generated and acquired data for localcomputation, relying on blockchain technologies for theacquisition and interchange of data.
4.1. FIWARE Fog Computing-Enabled Architecture. FIWAREis an open standards-based platform leveraging an open,public, and royalty-free architecture and a set of open speci-fications that allow developers, service providers, enterprises,and other stakeholders to develop and deploy innovativeproducts and digital services in a number of applicationdomains, including Smart Cities and Industry 4.0.
The proposed solution relies on FIWARE technologiesfor the interoperability of data within the fog nodes. TheFIWARE platform uses the FIWARE NGSI v2 (an enhancedversion of Open Mobile Alliance NGSI) and defines a setof Data Models (https://www.fiware.org/developers/data-models/) adding common syntax and semantics for differentverticals. Currently, around 90 cities from 19 countries inEurope, Latin America, and Asia-Pacific have signed upthe Open and Agile Smart Cities (OASC) alliance (http://oascities.org) membership meaning they intend to share andpublish their smart city data by means of FIWARE tech-nology.
Figure 1 depicts the architecture of the FIWARE-enabledfog node proposed by the authors. As can be seen, data ismodelled as NGSI entities, according to some data model,and managed by the FIWARE Context Broker. ContextBroker enables on-demand context informationmanagementbased on the FIWARE NGSI open specification, including
both queries (even geographic-based) and subscriptions forasynchronous notifications on changes. The Context Brokerholds the current value of all the different entities managed bythe platform being updated with the information provided bythe different IoT agents, which are isolated from the IoT layerspecifics. For data processing, a Complex Event ProcessingFIWARE component can be connected to theContext Broker.Finally, the Context Broker provides a federation mechanismwhich enables creating data registrations and forwardingqueries and subscriptions, supporting the execution of localapps using Context Broker data, irrespectively of the actuallocation.
For the exploitation of the data, local Data Apps connectto the Context Broker and query/subscribe for the entitiesusing the NGSI v2 API, irrespectively of the source ofsuch entities, local or remote. If data requested by DataApps comes from data sets acquired in the marketplace, theblockchain-based communication mechanism would requestthe information obeying agreements, generating access andusage logs, and retrieving the required date, as describedbelow. Besides, for the implementation of the marketplaceconcepts, we have taken as basis the Business API EcosystemFIWARE GE, implementing its business concepts.
4.2. Blockchain-Based Communication System. The distribu-tion of the marketplace implies interactions among nodes,which act as sellers, customers, or both, in the publicationof offerings, in the establishment of agreements, and in theexchange of the data itself. Such distribution is performedusing blockchain technology, as shown in Figure 2, whichprovides not only the distributed storage, but also the privacy,security, and trust of the distributed marketplace.
Given the nature of commercial transactions, our pro-posal relies on a permissioned blockchain solution, whereparticipants are identified, linking the marketplace with legalguarantees of the real world. Such permissioned scheme isimplemented as a certificate hierarchy, delegating the par-ticipation in the network to a main Certification Authority,whichmust sign the node certificates, therefore delegating onthe nodes the issuing of user certificates.
The blockchain-based communication system (Figure 3)deals with the data sharing and monetization capabilities at
Blockchain–based communication system
Business Layer
TX
TX
Business Business Interface Notification Ledger
Query Data Layer
Data Notification
Data Interface Ledger
Figure 3: Blockchain-based communication system.
two different layers: (1) the Business Layer, which managesall the aspects related to data advertising, location, andmonetization, and (2) the Data Layer, which deals with thedata sharing and accounting capabilities. Each of these layersincludes a distributed ledger which stores the associatedinformation in the form of immutable transactions, thebusiness logic dealing with such transactions, and an asyn-chronous REST API. These APIs hide from the complexityof the blockchain technologies, offering data interchangeand business high level actions, managing the correspondingcreation and monitoring of transactions.
The split on two different ledgers is due to the differentrequirements, in terms of throughput, delay, security, andfunctionality, exposed by each layer. In particular, the busi-ness layer requires strong participant identification, trans-actions to be validated before its data can be accessed, andsupport for smart contracts for validation and setting up ofagreements, not imposing big requirements on throughputand delay. On the other hand, the Data Layer requirestransaction information to be available as fast as possible inorder to avoid an excessive delay in the consumption of theacquired data, as well as the best possible throughput. Takinginto account these requirements, the proposed solution usestwo different distributed ledger technologies:
(i) The Business Layer uses Hyperledger Composer(https://www.hyperledger.org/projects/composer) ontop of Hyperledger Fabric (https://www.hyperledger.org/projects/fabric) in order to create a permissionednetwork composed only of the peer and orderernodes deployed by the participants of the peer-to-peer network proposed by our solution. HyperledgerComposer introduces abstraction level that enabledefining types of transactions and its attached smartcontracts tomanage a set of assets.These assets can becreated, modified, or deleted by the smart contractsof the transactions, composing the world state(https://hyperledger-fabric.readthedocs.io/en/master/ledger/ledger.html), which is a database with lateststate of every asset whose consistency is maintained
by the transactions stored in the ledger. In addition,Hyperledger Composer defines an ACL-based mech-anism used to specify the permissions that particularparticipants have in the network and to protect theinformation included in the created transactions andassets.
(ii) TheData Layer relies on Tangle (https://blog.iota.org/the-tangle-an-illustrated-introduction-4d5eae6fe8d4)using the main net of the IOTA (https://www.iota.org/) network relying on its Masked AuthenticatedMessage (https://github.com/iotaledger/MAM) (MAM)feature. It is important to remark that Tangle cannotbe considered a blockchain technology, as it doesnot use blocks. Instead, transactions are directlyincluded to the network by validating two previoustransactions called Tips, creating a Directed AcyclicGraph (DAG). In the Data Layer, rather than havinga private network as it is done in the businesslayer, the data interface is connected to the IOTAmain net using MAM, which features private andencrypted channels between peers in spite of beinga permissionless network. With this approachour solution benefits from the computing poweralready deployed as part of the IOTA main net whileensuring that the acquired data can only be readby the authorized participants. In addition, datatransactions sent though the MAM can be read asthey are attached to the network, while they areTips, without the need of waiting for their validation.This happens as the data transactions do not includetokens (cryptocurrency), so a double spendingcannot happen for this kind of transactions.
The result of having these two layers in the blockchain-basedcommunication system is that each node of the marketplaceintegrates a node of a private Hyperledger deploymenttogether with a node of the public IOTA main net. Mostof the actions of a layer are performed on its own ledger.However, there are crossed relations that represent the jointpoint among both layers. On the one hand, the data interfaceuses the business ledger for knowing details of the acquireddatasets whose data have to be requested through MAM, orfor enforcing the access policy at receiving data requests. Onthe other hand, the business interface introduces communi-cation details (identifier ofMAM channels) on the agreementsetup process. Figure 4 shows the particular implementationof the blockchain-based communication system.
4.2.1. Business Layer. The business layer is in charge ofthe traditional functionalities of a marketplace that is themanagement of offerings and the help in the establishmentof agreements. Regarding the offerings, the business layerimplements the commercialization part of the TM forum’sofferings lifecycle, namely, Active, Launched, and Depre-cated. However, the first one is treated as local status onlyaffecting the interaction with the user, only reflecting on thedistributed ledger the statuses of Launched and Deprecated.With respect to the establishment of agreements the states
Blockchain based communication system
Distributed Ledger
Hyperledger Fabric
Hyperledger Composer
Business Interface
Distributed Ledger
IOTA Full node
MAM
Data Interface
Figure 4: Blockchain-based communication system implementa-tion.
Seller Biz Interface Biz Ledger
1. Create Dataset2. Data Publication TX
3. Dataset Asset 4. Dataset
5. Create Offering6. Offering Publication TX
8. Offering7. Offering Asset
Figure 5: Offering publication.
Pending, Active, and Revoked are used to reflect whether anagreement is valid.
The Business Layer exposes the business interface to itsusers (API and Web) offering functionalities for creatingoffers, manage their life cycle including deprecation, definingthe price models, and manage the creation and maintenanceof agreements according to the different price models sup-ported.
(1) Management of Offerings. The published informationabout advertised data is split into two different concepts,the description of the data with all the information requiredto identify a particular stream and the description of thebusiness aspects related to its monetization and usage terms.Having these concepts uncoupled allows the definition ofricher scenarios, including having the same data advertisedin multiple offerings. For the publication of this informationin the business ledger, the business interface generates twodifferent types of transactions: the Data Publication Transac-tion and the Offering Publication Transaction as depicted inFigure 5.
Data Publication Transaction. The Data Publication Transac-tion exposes NGSI data managed by the Context Broker thatthe blockchain-based communication system is connectedto, by listing exposed entities and their offered attributes.Entities are specified using values or patterns for their id
or any of their attribute values, in a query-like style. Forthe particular case of geolocalized entities, such filter canadditionally include GeoJSON information used to filter theexposed entities. Examples of these definitions can be everyentity within a given area, entities of a particular type, orentities whose name starts by a given string.
The attribute-based level of granularity supports thepublication of a subset of attributes, keeping part of theentity private, thus not disturbing the existing processes andapplications when data is monetized. Moreover, customersare allowed to choose which of the published attributes orentities they want to acquire, given that the price modelssupport this situation.
The result of the consolidation of this transaction, that isthe execution of the attached smart contract, is the creation ofa dataset asset, being uniquely identified across the network,offered by the transaction issuer.
Offering Publication Transaction. The Offering PublicationTransaction provides pricing and business details. Specifi-cally, it holds a reference to the dataset identifier, the termsand conditions to be accepted by the customer on theacquisition, and the following monetization details:
(i) Contracts: they describe the duration of the agree-ment. The proposed solution deals with two kindsof contracts: (1) time-based contracts which specifythe duration in time and (2) usage-based contractswhich specify the acquired amount of data (e.g., 10000entities).
(ii) Characteristics: they define selectable characteristicsavailable to potential customers such as the query rateor subscription throttling.
(iii) Pricing models: they establish how and when thecustomers will be charged according to the chosendata, contract, and characteristics.
When more than one contract, characteristic values or pricemodels are defined, customer can choose the desired set, andthe final price adapts to such selection, as is explained in theprice model section.
The smart contract of the transaction is in charge ofverifying the existence of related dataset asset issued by thesame user and generates in the world state a new offeringasset.
Pricing Model. The pricing model used in the proposedsolution is based on three different concepts: basic model,price alteration, and modifiers.
The basic model is the core of the pricing and establishesthe period between charges, the information needed to com-pute them, and the basic price. In particular, the proposedsolution supports the following:
(i) One Time payments which are charged once atacquisition time. For this model the (initial) price tobe charged is specified.
(ii) Recurring payments which are charged periodicallybefore the specified period. For these models, the(initial) price to be charged periodically is specified.
(iii) Usage payments which are charged periodically, atthe end of the given period, and computed usingthe accounting information (usage) of the customeraccessing to the data. For these models both theaccounting unit and the (initial) price per accountingunit are specified.
Timing based contracts, namely, recurring or usage-basedmodels, specify a contract duration in which the user canrenew subscriptions. Under some conditions, the usermay beforced to renew the subscription during thewhole duration ofthe contract after each payment period (e.g., yearly contractwith monthly payments). A new contract is to be establishedat the end of the contract duration, therefore allowing theupdate of the conditions.
The price alterations allow richer pricing models estab-lishing how the final price should be increased or decreasedaccording to certain conditions or time frame that are verifiedat charging time. Price alterations can be classified accordingto two different criteria: whether they are applied always orunder certain conditions (e.g., the user has made more than100 calls) or whether they are applied just at acquisition timeor every time the customer is charged. Price alterations canbe used, for example, for setting up an initial fee to a usage-based model or to include a discount when the customermakes more than a certain number of calls. Admission feeand usage discounts are examples of price alterations thatmight be applied, for example, to a basic subscription.
Modifiers are used to make the final adjustments tothe charging price according to the different parametersselected by the customer when the offering was acquired.Modifiers use a weight based mechanism for the three typesof modifiers:
(i) Data attributes: they define a weight between 0 and1 for each published attribute, forcing a sum of 1.Therefore, acquiring all the published attributes foran entity does not change the price, while acquiringa subset makes a discount on it.
(ii) Contract: each of the available contracts is assigned amultiplying factor enabling us to increase or decreasethe final price according to the selected contract (e.g.,a 24-month subscription may be cheaper than a 12-month one).
(iii) Characteristics: each of the values of the includedcharacteristics is assigned a multiplying factor,enabling us to increase or decrease the final priceaccording to the selected values (e.g., a higher queryrate may be more expensive)
(2) Management of Agreements
Agreement Setup Process.TheBusiness Layermanages the dis-tributed set up of agreements between sellers and customersin order to acquire access to the published data, as depictedin Figure 6. It is worth remarking that the data deliveryperformed as a result of setting up an agreement betweentwo peers of the network is done through IOTA usingprivate MAM channels, where only a publisher can send
Wireless Communications and Mobile Computing 7
Customer C. Biz Interface Payment System Business Ledger S. Biz Interface
1. Acquire Data Offer
8. Confirm Payment Req
9. Confirm payment
2. Make Agreement TX 3. TX Notification
4. Attach Payment Info TX 5. TX Notification
6. Execute Payment
7. Confirm Payment Req
10. Confirm payment
11. Payment Accepted
12. Payment Complete TX13. TX Notification
14. Validate Payment Proof
15. Payment Proof Valid
16. AcceptAgreement TX
18. OK17. TX Notification
Figure 6: Agreement setup process.
transactions. In this regard, for the proposed solution twochannels are required per agreement, one for the customersto publish their data queries and other for the sellers tosubmit the data. In addition, both peers need to know theroot ID (address of the first message to be sent) and theencryption key for accessing a channel data.This informationis distributed as part of the agreement setup as described inthe following paragraphs.
The Make Agreement Transaction, run upon the acquisi-tion request made by the customer, triggers the agreementsetup and includes the chosen parameters, implying animplicit acceptance of the terms and conditions. In partic-ular, this transaction includes the ID of the offering asset,the selected data attributes, the chosen pricing model, theselected contract, and the selected characteristics. The smartcontract of this transaction computes the initial charge, unlessthe selected pricing is a usage model without initial fee, andcreates the agreement asset. This asset is created on pendingstate meaning that the customer does not have access to thedata until the pending payment is satisfied.
In addition, as part of the Make Agreement Transactionthe customer business interface includes the MAM root IDand encryption key to be used for sending queries related tothe ongoing agreement.This information is obtained from thedata layer through the MAM interface and is sent encrypted
using the public key of the data seller. This is the onlyinformation not accessible by the smart contract, since it isnot needed for any validation.
Once the agreement is created the customer has to pay thepending amount. The proposed architecture does not imposeany restriction about the payment method, intended tosupport PayPal, fiat or cryptocurrency transactions. Instead,it defines a pair of transactions used by the customer andseller, to verify external economic interchanges. In particular,Attach Payment Info Transaction is used by the seller node inorder to include in the agreement asset the needed paymentinformation that must be used by the customer node toperform the payment. Next, Payment Complete Transactionmust be provided by the customer business interface oncehaving paid, including the payment proofs. Note that theparticular nature of the proof will depend on the paymentmethod used.
Finally, the business interface of the data seller must issuean Agreement Accepted Transaction once finishing validatingthe payment proofs. The smart contract of this transactionchanges the asset state to ‘Active’ and sets up the times-tamp until which the agreement is valid. Additionally, thistransaction includes the answer channel details, that is theMAM root ID and encryption key, both encrypted with thepublic key of the customer. In the case of not requiring initial
8 Wireless Communications and Mobile Computing
payment, payment verification transactions are not used, butthis one remains due to the need of establishing the MAManswer channel.
Once the agreement has been created, the business inter-face of the customer node uses dataset asset details in orderto create a NGSI registration in the local Context Broker.This registration specifies the data interface of the blockchain-based communication system as the data source enabling theautomatic query forwarding.
It is noteworthy to mention that the seller does notdirectly interact in this process since it is performed automat-ically by her business interface after her having configured thepayment preferences.
Agreement Settlement Process. When using a recurring orusage-based model, the validity period of the agreementis the payment period, so at the end of it, customer isin charge of renovating the agreement and sending a newpayment according to the price model. For doing so, a newtransaction called Settle Agreement Transaction has beendefined, which in combination with Payment Complete andAccept Agreement Transactions are used to set up a newvalidity period, satisfy the payment conditions, and renew theMAM channels’ credentials.
The Settle Agreement Transaction smart contract calcu-lates the amount the customer has to pay for the particularsettlement. In this regard, for recurring models it calculatesthe amount the customer has to pay for renewing a newperiod, while for usage-based-models, the smart contractapplies the pricing model to the accounting information,whose gathering process is described in the Data Layersection. Finally, this transaction includes a flag used to specifywhether the agreement is going to be renewed for newvalidity period. However, if customer is not willing to renewa recurring model and there is not any payment pending, thistransaction is not needed since agreements are automaticallyinvalid when the validity period ends.
If the contract duration is over, the customer will not beable to renew the agreement, so a new one is to be createdwith aMake Agreement Transaction.
Note that the proposed architecture is intended to be ableto monitor the agreements and the payments, ensuring thenonrepudiation of the different interactions. The platformis not intended to make the effective enforcement of theagreement, but providing the tools to both customers andsellers to demonstrate without doubts that the agreements aresatisfied. The actions that have to be performed when there isa violation of the agreements are out of the scope of this paper.
4.2.2. Data Layer. TheData Layer is in charge of performingthe data delivery, enforcing access rights, and accountingfor the data consumption in order to support usage-basedpricing models and allow auditing customer service usage(e.g., for SLA enforcement). Data access is performed withinthe data ledger, therefore generating immutable trusted usageaccounting, just like the business layer assures offerings andagreements.
The Data Layer is transparent to data applicationsdeployed in the organization node, since every interaction
Blockchain–based communication system
Business Data Ledger Ledger
Business Interface Data Interface
Data Query Data
Data Query
Data App Context Broker Data
Figure 7: Data delivery architecture.
made by such apps to consume context information isdirectly performed against the Context Broker. This brokerleverages its federation mechanism, along with the NGSIRegistrations created during the agreement setup, to retrieveremote (acquired) context data, as can be seen in Figure 7.The broker forwards queries and subscriptions received fromthe data apps to the data interface, which encodes them in thedata ledger in the form of transactions for obtaining the data.Figure 8 shows the data delivery process for both data queriesand data subscriptions.
It is important to remark that the IOTA network is apermissionless distributed ledger, not allowing us to identify aparticular participant of the peer-to-peer network as definedin our solution. To overcome this issue, the proposed solutionuses the credentials (certificate and keys) of the businessledger to sign and hash-MAC all the messages included inthe different MAM channels.
Queries. The delivery process for queried data, as depictedin Figure 8, starts with a Data App making a query to theContext Broker. This component uses the NGSI registrationinformation to forward the query to the data layer of theblockchain-based communication system, whose data inter-face encodes the query as IOTA MAM message, the QueryTransaction, in order to attach it in the customerMAM chan-nel. The Query Transaction includes the agreement ID andall the information provided within the data query, includingrequested entities, attributes, filters, geographic area, etc.
Seller data interface is notified when the Query Transac-tion is attached to, which then checks the existence of thespecified agreement at the business ledger and validates thequeried data and the validity period through the HyperledgerComposer interface. If found, the requester is authorized toread the data, so the data interface performs the originalquery in the Seller Context Broker and encodes the result as aMAMmessage, the Data Transaction, which is then attachedto the seller channel. The data interface of the customerreceives a notification for the included Data Transaction, soit extracts the data and forwards it to the customer ContextBroker.
Wireless Communications and Mobile Computing 9
Data App C. Context Broker C. Data Interface Data Ledger Business Ledger S. Data Interface S. Context Broker
1. Query / Subscription2. Query / Subscription
11. data12. data
3. Query TX4. TX Notification
5. Get agreement
6. agreement
9. Data TX10. TX Notification
7. Query / Subscription
8. data
Figure 8: Data delivery process.
Subscriptions. The delivery process for subscribed data startsin a similar way as the queried data. A Data App or the CEPwilling to process a right-time data stream creates a subscrip-tion in the local Context Broker. If such subscription is partof a NGSI registration, the Context Broker gets subscribed tothe data source specified in the registration, which is indeedthe data interface of the blockchain-based communicationsystem.This component encodes the subscription as an IOTAMAMmessage in the customer channel (Query Transaction),which is received by the seller data interface. It checkswhether the customer can subscribe to the particular databy querying for a valid agreement in Hyperledger and, if thecustomer is authorized, the data interface of the seller getssubscribed to the requested data in the Seller Context Broker,using the validity period of the agreement for fine tuning theduration of the subscription.
With this approach a subscriptions chain is created, soeach time the subscribed entities are updated, the SellerContext Broker sends an asynchronous notification with therequested entities and attributes to the endpoint specified inthe subscription. Such endpoint is the seller data interface,which encodes the notification as a Data Transaction withinthe sellerMAMchannel in the IOTAnetwork.When theDataTransaction is read by the data interface of the customer node,the notification is extracted and forwarded to the customerContext Brokerwhich sends it to the subscriber app.Note thatin this process, the customer creates a single subscription, andthen, a regular data stream is created from the seller to thecustomer.
Accounting. The proposed approach saves all the requests,subscriptions, and data responses as part of the IOTA net-work, making it possible to validate how the acquired serviceis being provided. However, in order to support the usage-based pricingmodels and the charging calculation performedby the smart contract of the Settle Agreement transaction,aggregated accounting information needs to be saved in thebusiness ledger.
The accounting aggregation process is launched by theseller data interface, which retrieves all the Query and DataTransactions for a particular agreement on the data layer andgenerates an Attach Accounting Transaction in the business
layer. This transaction includes the ID of the agreement,the timestamps of the accounted period, and the aggregatedinformation which is useful for the usage-based models,including number of queries, number of downloaded entities,total bytes downloaded.
The validation of theAttach Accounting Transaction in thebusiness ledger generates an Accounting Asset in “Pending”state, which needs to be confirmed by the customer. Upon itsreception, the customer node checks the accounting infor-mation received against the data ledger and, if it is correct,it answers with an Accounting Verified Transaction in thebusiness ledger referencing the pendingAccountingAsset. Asa result of this transaction the state of the Accounting Assetis set to “Verified”.
The smart contract of the Settle Agreement Transactionuses the “Verified” Accounting assets in order to calculatethe fee on usage-based pricing model agreements, thereforeevolving the Accounting Asset state to “Charged”.
5. Validation of the Proposal
This section analyses the feasibility of the proposed solutionthought the case study described in Section 3 by describ-ing how the required distributed marketplace among thesmart building and the sensor company can be imple-mented according to the depicted architecture. In addition,it demonstrates how the usage of FIWARE technologies andFIWARE NGSI in a fog computing distributed scenario,where date is stored and processed locally, provides seamlessinteroperability between the deployed nodes. Figure 9 depictsthe architecture of how the use case is implemented accordingto the proposed solution.
State Prior to Data Sharing. In an initial step, both nodesinvolved in the case study use a FIWARE deployment forthe management of their internal data and IoT devices. Inparticular, the air quality node manages AirQualityObserved(http://fiware-datamodels.readthedocs.io/en/latest/Environ-ment/AirQualityObserved/doc/spec/index.html) NGSI enti-ties, which are created by its deployed IoT Agent fromthe raw IoT data of the node sensors. Additionally, aCEP is used to detect anomalous situations generating alerts
(http://fiware-datamodels.readthedocs.io/en/latest/Alert/doc/spec/index.html#alert-data-model). The AirQualityObservedentities include the timestamp and the location of theobservation, several weather information, and the value ofa set of pollutants. An example of an AirQualityObservedentity is shown below:
{
"id": "Madrid-AmbientObserved-01",
"type": "AirQualityObserved",
"address": {
"addressCountry": "ES","addressLocality": "Madrid","streetAddress":"Plaza de Espa~na"
On the other hand, the smart building manages NGSIinformation about the current status of its HVAC system(which incorporates free cooling) including temperature,humidity, water flows, pump speeds, and fan speeds, curatedby its IoT agents. The CEP processes the NGSI data streamgenerating actions by creating BuidingOperation (http://fiware-datamodels.readthedocs.io/en/latest/Building/Build-ingOperation/doc/spec/index.html) NGSI entities in theContext Broker.The IoT agents, subscribed toBuildingOpera-tion entities, use this information to actuate over the IoTnetwork.
Data Publication. With the operation of the different nodessetup, the owner of the air quality node wishes to publishsome of the curated right-time data following the processdefined in Figure 5. Every interaction mentioned in thissection is based on such diagram. For this particular scenario,the values of NO
2, NO, CO, and SO
2levels as well as
temperature for a given area are advertised by invoking thebusiness interface API (interaction 1 of the diagram).
To monetize the dataset, the seller creates an offering usingthe business interface API (interaction 5 of the diagram). Inthis example, the offering includes eligible 12- or 24-monthcontracts where the former gives a 10% discount on thepricing. The pricing model is based in IOTA cryptocurrency(expressed in 1 k or 1 M units) and defines a usage-basedpricing model of 1 KIOTA per downloaded entity with aninitial fee of 1 MIOTA. In addition, the pricing includes a10%discountwhen the customer downloadsmore than 10000entities within a charging period of onemonth. An excerpt ofthe offering creation request can be found below, excludingsome of the options for brevity:
POST https://bizinterface/api/offerings
{
"id": "mad-air-quality",
"dataset": "mad-air-quality-1",
"liveCycleStatus": "Active",
"terms": {
"title": "Non-Commercial Use","text": "The Offered data cannotbe used with commercial purposes
Upon each seller request, the business interface attaches atransaction in Hyperledger Composer (interactions 2 and 6of the diagram).These two transactions are introduced in theledger signed by the seller, keeping the offering conditionsimmutable and public. An example of Offering PublicationTransaction, where offering includes the monetizing informa-tion, can be found below.
Data Acquisition. Offerings and datasets are maintainedwithin the network as Hyperledger Composer assets, snap-shotted in the Fabric world state, and can be discovered usingthe search API provided by the business interface. Once asuitable offering has been found, and its details are obtained, itcan be acquired following the process detailed in the diagramof Figure 6. Every interaction mentioned in this section isbased on such diagram.
GET https://bizinterface/api/offerings?
filter=
[ {
"id": "mad-air-quality",
"dataset": "mad-air-quality-1",
"liveCycleStatus": "Active",
. . .
} ]
GET https://bizinterface/api/datasets/
mad-air-quality-1
{
"id": "mad-air-quality-1",
"description": "Temperature and NO2,
NO, CO and S02 levels in Madrid
Centre Area",
. . .
}
In the current case study, the smart building owner acquiresaccess to the air quality data stream so it can be incorporatedto the free cooling management, irrespectively of later accessthrough queries or subscriptions. From the air quality offer-ing she selects the 24-month contract and all the advertisedpollutants (NO
2, NO, CO, and SO
2) but not the temperature.
The process is initiated with the acquisition request made tothe business interface (interaction 1 of the diagram).
POST https://bizinterface/api/offerings/
mad-air-quality/acquisitions
{
"attributes": ["NO2", "NO", "CO",
"SO2"],
"characteristics": [ ] ,
"contract": "2y",
"pricing": "usage"
}
This acquisition request generates aMakeAgreement Transac-tion (interaction 2) whose smart contract calculates the initialfee, which is then included within the created agreementasset. The pricing model of the air quality data offeringincludes an initial fee of 1 MIOTAwhich in combination withthe multiply factor of the chosen contract and the weightsof the selected attributes results in a pending payment of 810KIOTA (1000 KIOTA ∗ 0.9 ∗ 0.9 = 810 KIOTA).
Since the current agreement includes a pending payment,the business interface of the seller submits anAttach PaymentInfo Transaction, including its IOTA addresses for receivingthe payment (interaction 4).
{
" $ class": "org.conwet.biznet.
AttachPaymentInfo",
"method": "IOTA",
"paymentInfo":
"SJEDHICBWBRGB9XDHCOL...
DEYOWVOSUPGIBBUALNGDTSJ9A",
"agreement": "resource:org.conwet.
biznet.
Agreement#agreement-1",
"owner": "resource:org.conwet.
biznet.
User#seller-1",
"transactionId":
"ef90f5696c4f4fff324d22cb322618d5",
"timestamp": "2018-06-04T14:25:17.
362Z"
}
After the execution of the agreement setup process, thecreated agreement asset is inActive state, including theMAMinfo for customer and seller channels, and the timestampwitha validity period of onemonth (the default for usage models).The world state contains such active status backed up by theimmutable transactions (interactions 2, 4, 12, and 16) andrelate to the original offeringwhich cannot bemodified. It canbe found below the resulting agreement asset after the process
Once the acquisition has finished, the business interfacecreates the NGSI registration for the pollutant information ofthe air quality data served by the seller, which is used by theContext Broker in order to forward queries and subscriptions.An NGSI registration example is written below:
Data Consumption. Within the smart building node, theprocessing of the air quality data for actuating in the freecooling system is done in the CEP. This component searchesfor patterns in data stream, which in this scenario impliesdetecting high pollutant levels during a given period of time.To set up the air quality data stream feeding the CEP, the pro-cess described in Figure 8 is started by creating the followingsubscription in the local Context Broker (interaction 1).
POST https://customerbroker/v2/
subscriptions
Fiware-Service: seller-1
{
"description": "",
"subject": {
"entities": [ {
"idPattern": ". ∗ ",
"type": "AirQualityObserved"
} ],
"condition": {
"attrs": ["NO2", "NO", "CO",
"SO2"]
}
},
"notification": {
"http": {
"url":
"http://cep/notifications/"
},
"attrs": ["NO2", "NO", "CO", "SO2"]
}
}
As a consequence, a subscriptions chain is created propagat-ing this subscription through the blockchain-based commu-nication system, permanently storing the Query Transactionused for the propagation (interactions 2 to 7).
Each time the value of a pollutant of the subscribedentities changes, a notification flows from the seller to thecustomer, as described in interactions 8 to 12 of the diagram,through the seller MAM channel as a Data Transaction.Bellow it can be found an example of Data Transaction(currency-less IOTA transaction with the MAM messageencoded in the field signatureMessageFragment as trytes).
The field signatureMessageFragment in such currency-lessIOTA transaction represents the actual MAM message. Themost relevant information of the content of such field isdecoded below:
In this scenario, the air quality data is offered under ausage pricing model. In this regard, in each charging period(monthly) the information available in both seller and cus-tomer channels (Query and Data Transactions) is aggregatedin anAttach Accounting Transactionwhich is submitted to thebusiness ledger by the seller and validated by the customer,having access to data ledger channels and their immutabledata sharing transactions acting as accounting records.
{
" $ class": "org.conwet.biznet.
AttachAccounting",
"agreement": "resource:org.conwet.
biznet.Agreement#agreement-1",
"start": "2018-06-04T14:25:17.362Z",
"end": "2018-07-04T14:32:19.574Z",
"accounting": {
"entities": "20000",
"mb": "2.27",
"calls": "1500"
},
"transactionId": "96acb5696c4f4
fff328cd6cb322618d5",
"timestamp": "2018-07-04T14:32:19.
574Z"
}
During the settlement of the agreement, the submittedaccounting is used for feeding the agreement pricing models.In this scenario, assuming the smart building has down-loaded 20000 entities, the pending payment would be 18MIOTA (20000 entities ∗ 1 KIOTA/entity = 20 MIOTA withthe 10% discount for downloading more than 10000 entities= 18MIOTA).This would be calculated by the smart contractof the Settle Agreement Transaction.
6. Conclusions
Distributed marketplaces with peer-to-peer data deliverymodels are more suitable than centralized approaches formonetizing data in fog scenarios, where produced data ispreferred to be stored and processed locally. This paperpresents such a peer-to-peer distributed data marketplacewith advanced business capabilities, where trust is assured bythe usage of blockchain technology. The solution combinesdifferent distributed ledgers in order to satisfy the require-ments of each layer.
Unlike other marketplace solutions using blockchaintechnology that only focuses on implementing aggregationand search functionality of data and offerings, and assistingin the agreement process, our solution goes a step furtherand also allows to register faithful and verifiable accountingrecords used on usage models of pricing when performing
Wireless Communications and Mobile Computing 15
the data distribution and access control in a peer-to-peer datamarketplace.
Moreover, the proposed distributed marketplace is com-patible with advanced information distribution schemas likethe FIWARE architecture of federated Context Brokers. Inthis scenario, query- or subscription-based access to acquireddata is performed transparently for the data applicationsrunning in the fog node, which access the local ContextBroker for getting the data without knowing whether thelatter is local or remote (i.e., acquired from a different nodeof the network).
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The research leading to these results was partially funded bythe European Commission Horizon 2020 Research Frame-work Programme FI-NEXT Project under Grant agreementsID 732851. This article expresses the opinions of the authorsand not necessarily those of the European Commission. TheEuropean Commission is not liable for any use that may bemade of the information contained in this paper.
References
[1] The Economist, “The worlds most valuable resource is nolonger oil,” https://www.economist.com/leaders/2017/05/06/the-worlds-most-valuable-resource-is-no-longer-oil-but-data.
[2] N. Kroes, “Digital Agenda and Open Data,” http://europa.eu/rapid/press-release SPEECH-12-149 en.htm.
[3] T. W. Malone, J. Yates, and R. I. Benjamin, “Electronic marketsand electronic hierarchies,” Communications of the ACM, vol.30, no. 6, pp. 484–497, 1987.
[4] J. Y. Bakos, “A strategic analysis of electronicmarketplaces,”MISQuarterly: Management Information Systems, vol. 15, no. 3, pp.295–310, 1991.
[5] C. C. Albrecht, D. L. Dean, and J. V. Hansen, “Marketplaceand technology standards for B2B e-commerce: progress, chal-lenges, and the state of the art,” Information &Management, vol.42, no. 6, pp. 865–875, 2005.
[6] P. Brody and V. Pureswaran, “Device democracy: Saving thefuture of the Internet of Things IBM,” IBM, 2015.
[7] B. Varghese, N. Wang, S. Barbhuiya, P. Kilpatrick, and D. S.Nikolopoulos, “Challenges and Opportunities in Edge Com-puting,” in Proceedings of the IEEE International Conference onSmart Cloud, SmartCloud ’16, pp. 20–26, USA, November 2016.
[8] E. (O’Reilly) Dumbill, “Data markets compared - A look atdata market offerings from four providers , OReilly Radar,” E.(O’Reilly) Dumbill, 2012, http://radar.oreilly.com/2012/03/data-markets-survey.html.
[9] S. Mansfield-Devine, “Beyond Bitcoin: using blockchain tech-nology to provide assurance in the commercial world,” Com-puter Fraud and Security, vol. 2017, no. 5, pp. 14–18, 2017.
[10] V. Gramoli, “From blockchain consensus back to Byzantineconsensus,” Future Generation Computer Systems, 2017.
[11] G. Zyskind, O. Nathan, and A. S. Pentland, “Decentralizing pri-vacy: Using blockchain to protect personal data,” in Proceedingsof the IEEE Security and Privacy Workshops, SPW ’15, pp. 180–184, IEEE, May 2015.
[12] P. B. Nichol and J. Brandt, “Co-Creation of Trust for Health-care: The Cryptocitizen Framework for Interoperability withBlockchain,” ResearchGate, 9 pages, 2016.
[14] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “MedRec:Using blockchain for medical data access and permission man-agement,” in Proceedings of the 2nd International Conference onOpen and Big Data, OBD ’16, pp. 25–30, Austria, August 2016.
[15] Q. Xia, E. B. Sifah, K. O. Asamoah, J. Gao, X. Du, and M.Guizani, “MeDShare: Trust-Less Medical Data Sharing amongCloud Service Providers via Blockchain,” IEEEAccess, vol. 5, pp.14757–14767, 2017.
[16] A. Ouaddah, A. Abou Elkalam, and A. Ait Ouahman, “FairAc-cess: a new Blockchain-based access control framework for theInternet ofThings,” Security and Communication Networks, vol.9, no. 18, pp. 5943–5964, 2017.
[17] K. Misura and M. Zagar, “Data marketplace for Internet ofThings,” in Proceedings of the 1st IEEE International Conferenceon Smart Systems and Technologies, SST 2016, pp. 255–260,Croatia, October 2016.
[18] C. Perera, S. Y. L. Wakenshaw, T. Baarslag et al., “Valorisingthe IoT Databox: creating value for everyone,” Transactions onEmerging Telecommunications Technologies, vol. 28, no. 1, 2017.
[19] D. Worner and T. Von Bomhard, “When your sensor earnsmoney: Exchanging data for cashwith Bitcoin,” inProceedings ofthe ACM International Joint Conference on Pervasive and Ubiq-uitous Computing, UbiComp ’14, pp. 295–298, ACM, September2014.
[20] K. Noyen, D. Volland, D. Worner, and E. Fleisch,When MoneyLearns to Fly: Towards Sensing as a Service Applications UsingBitcoin, 2014.
[21] J. McKane, “Bitcoin vs Ethereum – What to expect in 2018,”https://mybroadband.co.za/news/cryptocurrency/-bitcoin-vs-ethereum-what-to-expect-in-2018.html.
![Aalborg Universitet A Decentralized Control …...Wardah et al. [15] presented a partially distributed architecture, in which peer to peer electricity sharing was enabled by GSM based](https://static.documents.pub/doc/80x56/5e5bad0bae36fa5767727a98/aalborg-universitet-a-decentralized-control-wardah-et-al-15-presented-a-partially.jpg)
![Distributed Clustering from Peer-to-Peer Networkshy583/2010_presentations/Distr_Clustering.pdf · Distributed Clustering from Peer-to-Peer Networks ... (SDC) [2] is another approach](https://static.documents.pub/doc/80x56/5b8a1a797f8b9a9b7c8b92e0/distributed-clustering-from-peer-to-peer-hy5832010presentationsdistrclusteringpdf.jpg)
