Final report

I recently discovered this painting by Paul Gauguin and it fascinates me since that moment. The painting, seen from right to left, is an allegory of human life passing through birth, D’ou Venons Nous – Where do we come from?, the present, Que Sommes Nous – What are we?, and death, Où Allons Nous – Where are we going?.

In this post, we make a similar journey through our participation in the Eclipse Open IoT Challenge 4.0 with the project trusted indoor positioning system for nursing homes. First of all, we start with our proposal. Then, it is shown what we have achieved and what we have learned. Finally, the post concludes with our eyes on the future.

Before we start, we would like to issue a warning. This is our seventeenth post (listed at the end) and we are not going to paraphrase what we have already written in the sixteen previous posts. It would be a waste of time for us and unfair to anyone who has read the previous ones. Therefore, when we use recycled material, we will warn you about it, providing the link to the original source, just in case you want to go deeper.

Having that said, let’s start.

Executive Summary

• Where do we come from? Motivation and proposal

  • A system which provides you with a proof that you can use as an evidence of a fact.
  • Our proposal is focused on nursing homes.
    • Guaranteeing an appropriate care of the elderly in these centres.

• What we are. Results and lessons

  • How we compete
    • To gain experience, improve ourselves and try to win.
  • What we are
    • Computer engineers focused on research.
    • We have a bit knowledge about Eclipse IoT stack tools.
  • Approach
    • We focus on an interesting, useful and realizable idea.
    • We have always prioritized what we considered most necessary, to validate our PoC.
  • Technological Stack
    • Our proposal is built using Kura.
    • Besides Kura: MQTT, React, Java Servlets, Websockets, IOTA, Android….
  •  Community
    • We know very well the importance of disseminating the obtained results.
    • We have posted seventeen times, sometimes about the proposal, sometimes about technology and others about parts of the system.
  • Results
    • Jura: “It swears”; a set of Kura’s components to deploy trusted indoor positioning systems.
    • Mide: “It measures”; A repository in which we have generalized some of the experiments that we have carried out as analysis tools.
    • Mira: “It looks”; Android app focused on the relatives of nursing home’s residents and built using the Anonymous Trusted IPS of Jura.
  • Lessons learned
    • If we had not competed in the challenge trying to give the best of us, we would never have done anything of what we have done. Looking back we are proud of what we have achieved.
    • We think that this is a wonderful opportunity for many professional profiles. Students, recent graduates, entrepreneurs, curious, or like us, researchers looking to gain experience in the field.
    • We are so convinced of the advantages of blockchain technologies that we have a stack of blockchain’s books that we will study eagerly during the next weeks.

• Where we go. Future works

  • We have an overflow of ideas.
  • The results are good enough to propose more ambitious goals, but we do not know yet what will be our next step.

Where do we come from? Motivation and proposal

You do not really understand something unless you can explain it to your grandmother – unknown and wrongly attributed to Albert Einstein.

Perhaps, the closest concept to describe our initial idea is a notary system. It is not the best definition, but it is what we would say to our grandmas. A system which provides you with a proof that you can use as an evidence of a fact.

Could you think more than 5 situations in which the reading of a sensor would serve to prove something? We are pretty sure that you can think much more than 5 situations. In our case, there are dozens of situations which come to mind.

Often the events are used to prove something, but they lack any probative value to a third party since for this we must guarantee some properties in the events such as authentication, non-repudiation or integrity (anyone else thinking about keeping them in a blockchain?). However, it is not enough to store an event with those properties, but we should also guarantee that the event is real.

For us, guaranteeing the latter is much more complicated than the former, and now that the challenge comes to the end, we must say that the difficulty to find a solution which satisfied us, almost made us renounce. In the end, we found a solution that convinced us, so we should focus on win-win situations.

This led us to make a proposal focused on nursing homes.

We firmly believe that a system which allows guaranteeing an appropriate care of the elderly in these centres, is good for everyone:

• It is positive for our loved ones to have a guarantee that they will receive the best care by the staff of the nursing home.
• It is excellent for relatives, to be informed of any incident and to have mechanisms that enforce their rights.
• It is the best transparency policy for a nursing home.

We had several ideas about what kind of information to guarantee and finally, we decided to develop an Indoor Positioning System (IPS) using Bluetooth Low Energy beacons (BLE beacons or simply beacons) that would allow us to guarantee the location of people.

[16] When we speak of an IPS, the image of a plan with moving points, quickly comes to mind. This is not what we want. We want to use the locations in a way that allows us to say something similar to: X certifies that Y was in place Z at time T.

To do that, we believe that, currently, there is no better technology than blockchain. Storing the locations in a blockchain allows us guaranteeing that [9]:

1. The locations are stored in a distributed ledger and it is not possible to block their access.
2. A message cannot be repudiated.
3. It is not possible to modify or remove registered locations.
4. It is not possible to add past information that can be trusted. The timestamp of the location and the timestamp of the transaction will determine if the message should be trusted or not.

We do not want to cheat you, we would have liked to develop a visualization tool too. At the beginning of the challenge, we even started to develop a tool for it (among other things) [12]. A picture is worth a thousand words.

Why did we abandon the development of this tool? The main reason was that we had to prioritize and focus our efforts on the certification processes instead of the visualization.

To make it even clearer, we finished with the IPS in mid-February, and we had a full version of our proposal by the end of that month. We could have finished this visualization tool. Instead, we preferred to use the available time on what we considered most necessary, validating our Proof of Concept (PoC), the scalability [10,13,14] and the usability [12,15,16].

This is the general idea of our proposal. We have tried to explain it in a simple way, but since it never rains to everyone’s taste, for some of you it might have been too long and for others too short. For the latter, we refer you to these posts [2,13] in which we try to explain in more detail what is the approach that we propose.

What we are. Results and lessons

How we compete

Since the challenge began, we have had an idea in mind, we are competing. Our goal is to gain experience, but if we are competing, we will try to win, and because of that, we have tried to do our best 😉

And we want to highlight the above because it is probably one of the greatest personal lessons we have learned during the challenge. If we had not competed in the challenge trying to give the best of us, we would never have done anything of what we have done. Looking back we are proud of what we have achieved. We do not want to encourage anyone to become a psychopath obsessed with victory, but to set goals and give the best of themselves to achieve them. It’s great to compete, even against oneself.

We summarize below those things which we believe that are important to analyze in order to know how we have competed: i) what we are, ii) our approach, iii) our technological stack and iv) our relationship with the community. Due to its importance, we will show the results in a separate section.

What we are

We present ourselves. So you can get an idea of our background, we quote from [4]:

Our team consists of three computer engineers; all of us from different fields, with great interest and curiosity about IoT but inexperienced in it. Because we work with some Eclipse tools we knew about the challenge, which we thought was a great opportunity to gain experience and (why not?) get some cool gadgets for free!

We knew some Eclipse IoT stack tools, but we had worked only a little with them (Kura, Mosquitto, Paho and maybe some other). For this reason, and based on the limited knowledge we had, we started looking for an (i) interesting, (ii) useful and (iii) realizable idea.

Although we are computer engineers, so far we have dedicated more time to research than to development. Francisco J. Quesada is a PhD student, Francisco Moya is also a PhD student (he also works as Android developer), and Fco Javier Estrella is a PhD in Computer Sciences since 2015 (he recently has focused on software development).

Now, that the end of the challenge is near, we can say that this is the first time that we have participated in this kind of projects, and it has been a fantastic and enriching experience for us. We think that this is a wonderful opportunity for many professional profiles. Students, recent graduates, entrepreneurs, curious, or like us, researchers looking to gain experience in the field.

Approach

Despite being computer engineers, we have dedicated much more time on research than on development. This has conditioned us both when making the proposal and when developing it. In what way?

We believe that our strengths lie in proposing solutions and verifying their viability.  Because of that [4] we focus on an (i) interesting, (ii) useful and (iii) realizable idea and [9] we did not want to propose anything that seemed like a good idea, but in practice would not be feasible. As it is indicated in the proposal, we have always prioritized what we considered most necessary, to validate our PoC.

We do not believe that our approach is better than others. We think that it is the best one for our profiles. As we said before, in our opinion, the challenge is a great chance because it allows the participation of professionals of various types of profiles.

Technological Stack

In the past years we had developed some Eclipse RCP applications, so we knew OSGi. For us [5] OSGi is ideal for managing IoT gateways and we believe that it is a wise movement that Kura has been developed using it. It is difficult to explain OSGi in a simple way and it may be even more difficult to explain its benefits (http://tuhrig.de/when-modularity-comes-down-to-osgi/). For us, Kura is one of the best examples to prove the suitability of OSGi in certain scenarios.

Our proposal is built using Kura, being its versatility vital for our proposal. [4] Something that makes us feel especially happy is that everything works in Kura. We know that for some parts of the system there are better alternatives, but deploying everything in the same tool will help in its deployment, management and maintenance.

Obviously, we use other things besides Kura:

1. MQTT. Kura provides an MQTT broker, Artemis, and a MQTT client, Paho. Is not it great? 🙂
2. React. We have developed two websites [7,11] as Kura components that use this library.
3. Java servlets and WebSockets. We use them in Kura to provide the backend of the websites and the Android app. Moreover, we had to patch some Jetty packages in order to be able to use WebSockets in Kura.
4. The Apache Commons Mathematics Library. We had integrated this library in Kura to execute least squares methods.
5. The Legion of the Bouncy Castle Libraries. These libraries were also integrated into Kura. In this case, they are used to sign an encrypt locations.
6. IOTA. A blockless distributed ledger. We have integrated in Kura a patched version of JOTA that allows us to communicate with an IOTA node to make and read transactions.
7. Android.

We would like to highlight that [12] in our proposal we do not use the official version of Kura, but a fork in which we solved an iBeacon’s bug in the Raspberry 2. Notice that once we certainly figure out if this is a failure of Kura or an incompatibility with our system, we will carry out a pull-request.

By the way, we are pleased to tell you that we have already made a small contribution to Kura and that makes us extremely happy 🙂

Community

Due to our professional background, we know very well the importance of disseminating the obtained results. We know that this can be extremely boring, but the effort is worthy.

In our case, we started this blog when we applied for the challenge [1]. Since then, we have posted seventeen times. Sometimes with articles in which we explain the proposal [2,4,9], sometimes with more technical articles explaining the parts of our solution in detail  [6,7,8,11,14,16] and other times with more general articles [1,3,5,10,12,13,15].

In addition to the dissemination of the results in the blog, we have also created the twitter account @trustiot in which we have been tweeting our results.

Thanks to this, and to the members of Eclipse IoT who have helped us to spread our work, we have obtained quite acceptable levels of dissemination:

• Our newly created blog has received 3165 visits.
• Our newly created twitter account has 33 followers. Ok, only with us there are already three followers…, but you will not take away our happiness :). For a newly created account that specifies that it is for a challenge, we think this number of followers reflects that there are people interested in what we propose.
• We were surprised to find that we received some visits from Reddit (#1, #2, #3, #4).
• We were even more surprised to realize that in the #ict channel of Discord community of IOTA some users were analyzing if what we published in one of our last posts [14] could be useful for this project. After analyzing the ICT project we believe that what we do is not valid for that project, but who knows, maybe something of we do might help them to see something clearer (perhaps communicating IOTA nodes using MQTT to create a cluster is not a bad idea).

At the beginning of this section, it is said that all this work is boring, and we have not changed our opinion, but in view of the results, we think that all this effort was well spent.

We want to end the section indicating that everything we have developed is open source. There are three repositories at your disposal:

• JURA (https://github.com/trustingiot/jura) [6,7,8,11,14]: Trusted Indoor Positioning System for Kura.
• MIDE (https://github.com/trustingiot/mide) [10,12,13,15]: A set of experiments conducted for the challenge.
• MIRA (https://github.com/trustingiot/mira) [16]: An Android app for nursing homes.

Results

Our most tangible results can be seen just before the title of this section, three software repositories. If someone is curious about the origin of the names, clarify that we (almost) always use the third person singular of a Spanish verb (jura=it swears, mide=it measures, mira=it looks, …).

Do you want to know what you can find in each repository? We tell you.

Jura

[11] Jura is not a monolithic tool, it is a Kura’s components based tool:

• Jura: “It swears”; a set of Kura’s components to deploy trusted indoor positioning systems.
  • Faro [6]: “Lighthouse”; a multimodal beacon.
  • Graba [7]: “It records”; a recording system.
  • Ubica [8]: “It locates”; an indoor positioning system.
  • Firma [11]: “It signs”; a signer, encrypter and validator of locations.
  • IOTA’s worker [14]: A node to make IOTA’s transactions in a distributed way.

What does the above mean? It means that in each particular device it is only deployed what is necessary.

We said earlier that we have tried to do our best and we think that the parts of Jura are an example of this. We have not only implemented the basic functionality, but everything we think is useful (different beacons protocols, different positioning algorithms, different systems for the certification of locations, …).

We invite you to review the different post to discover all the functionality. Some of them even include gifs that show what the system can do [7,11].

Mide

Usually, when we develop a PoC we spend more time performing tests than building the final solution. Our case has not been an exception.

When we made the proposal we decided to use some tools that we had never used before. Due to this, we spent the first months of the challenge doing all kinds of tests and it was not until the end of January when we were able to connect all the pieces [4].

What is Mide? A repository in which we have generalized some of the experiments that we have carried out as analysis tools.

Mira

Our PoC has two parts. The main one is Jura, the other part is Mira.

Mira is an Android app focused on the relatives of nursing home’s residents and built using the Anonymous Trusted IPS of Jura.

Mira allows access to the records of resident’s locations from an Android phone. Since it uses the [11] Anonymous Trusted IPS of Jura it can guarantee that all locations are encrypted independently and that it is not possible (or at least it is not easy) to apply heuristic methods to associate transactions with a user.

Mira not only allows to check the resident’s locations by decrypting the transactions and validating its digital signature but also allows to share them with other Mira’s users using MQTT. As each location is sent to a unique address and is encrypted using a unique key, sharing an event does not compromise the resident’s security and anonymity.

Does the nursing home had some careless attitude with your relative and you have an event that proves it? Share it with who you need (your brother, your lawyer, your insurance company, …) and enforce your rights.

Do you want to know more about Mira? In its post, we show you what it does with a use case full of videos [16].

Where we go. Future works

We are very happy with our experience in the challenge as well as with the results obtained. It is said that when you are happy, it shows.

At this moment, we might say that we have something like an overflow of ideas 🙂

A proof of concept is only a proof, but we believe that the results are good enough to propose more ambitious goals. We do not know yet what will be our next step. Perhaps we will propose a more general solution or maybe we will contact nursing homes in the area to obtain their feedback, or even carry out an experimental trial. If you found interesting our proposal, we encourage you to add our blog to your bookmarks. We have the feeling that in the future we will post much more interesting things 😉

Regarding IOTA, in our opinion, it is the future. Well, maybe not IOTA, but it will be very similar. When the challenge began we had a general notion of blockchain technologies. At this moment, we are so convinced of the advantages of those technologies, but we are not experts yet. For this reason,  during the next months, we are going to eagerly study a stack of blockchain’s books with the aim of understanding these technologies in depth.

Throughout the challenge, we have realized that there is room for a huge number of solutions in this area. Some, as in the case of our proposal, will use these technologies whereas others will improve the way in which we interact with them. We believe that this is the biggest cake to be shared in the coming years and that all of us can take our part. As before, we are still unclear about the next step to take in this area. However, we are calmed because we know that while we read the books, we will have time to think about it 🙂

As a curiosity about the latter, in the last days, we have started to be interested in IOTA nodes, especially thinking about permanodes. Who knows? Maybe in a few weeks you will find a new IOTA public node powered by Up Squared 🙂

Posts

1. Kick-off (Nov 13, 2107).
2. Our Approach. Part I. Indoor Positioning System (Dec 3, 2017).
3. In the top 12 proposals!!! (Jan 25, 2018).
4. Preliminary results (Jan 28, 2018).
5. Building Deployment Packages for Kura (Feb 2, 2018).
6. Faro: A Multimodal BLE Beacon (Feb 7, 2018).
7. Graba: A BLE Beacons Recording System (Feb 12, 2018).
8. Ubica: An Indoor Positioning System (Feb 21, 2018).
9. Our Approach. Part II. Trusted IPS (Mar 1, 2018).
10. The Race to the Tangle (Mar 1, 2018).
11. Firma: In IOTA We Trust (Mar 2, 2018).
12. Testing: One, two, three (Mar 4, 2018).
13. The Race to the Tangle II. Teamwork (Mar 7, 2018).
14. Parallelizing IOTA transactions in Kura (Mar 10, 2018).
15. Testing: Four, five, six (Mar 14, 2018).
16. Mira: To Enforce your Rights (Mar 15, 2018).
17. Final report (Mar 15, 2018).

Our Approach. Part II. Trusted IPS

We have been waiting to post this for weeks. It is not because we are playing hard to get, we just wanted to see how far we could go 🙂

Let’s contextualize. When we conceive our proposal we made the following reasoning:

1. In several situations, the reading of a sensor can be enough evidence to prove something. Thinking about location examples, the above could be useful if:
   • A person wants to prove that he/she was in a certain place at a given time.
   • A delivery person must bring a package to an address.
   • A worker who must be in an area for a period of time.
   • …
2. If someone wants to use a reading as evidence of a fact, he/she should be the one detected. The reason is very simple, false readings can be generated:
   • A child who plays truant from school.
   • A delivery person who sets a fake GPS location.
   • A worker who wants to pretend that he/she works more than he/she actually did.
3. For the same reason, detections should not be used as accusatory evidence:
   • A person can simulate that another person was in a restricted area.
   • A person can simulate that another person was in a place to deny that he/she could be elsewhere.
   • A person could use a stolen device to commit any felony.
   • A person could use a modified device to impersonate another person.
4. In addition, the absence of detections should not be used as accusatory evidence either, since the readings could be deliberately omitted.
   • A person does not want to register the delivery person who goes to his/her home.
   • A company does not register an action of its clients to cancel any of their rights.
5. To be able to use a reading as an evidence to a thrid party, it should be recorded in a way that ensures that:
   • The authentication of the sender of the message can be checked.
   • The message is registered when it occurs.
   • The message can not be modified.
   • The message can not be repudiated.

Before explaining our approach we would like to make a small point. Our starting point was: let’s use IoT as evidence to prove facts. We believe that extreme generalizations are extremely bad, and we are convinced that the reader can come up with several solutions to the above problems. We did not want to propose anything that seemed like a good idea but in practice would not work at all. Why our proposal is a Trusted IPS for Nursing Homes? Because we believe it is useful and we can deal with the above problems in this area.

Our proposal

We believe that the best scenarios to deploy a proposal are those in which the following requirements are maximized:

1. The detected one obtains benefits:
   • Direct: He/she can prove a fact.
   • Indirect: The processing of data provides some benefits (emergency attention, customized care, …).
2. The detector obtains benefits:
   • Direct: Location of workers, logistics optimization, sale of data, …
   • Indirect: Transparency policies, analytics, …
3. The detected one should not be interested in cheating the system.
4. The detector should not be interested in cheating the system.

How do these requirements fit with a nursing home?

Detected benefits

Residents and their relatives can obtain great benefits:

• Guarantee of adequate attention.
• Help in emergency situations.
• Behavioral study for the early detection of diseases (degree of mobility, level of physical exercise, sociability, dementia, Alzheimer, …).

Detector benefits

The owners and staff of the nursing home can also obtain great benefits:

• If one of your loved ones must be admitted to a nursing home and you must choose one. How would you rate one that offers you a guarantee of the care of its residents and that gives you mechanism to enforce your rights?
• Location of residents.
• Location of staff.
• Processes automation.

Interest in cheating by the detected

This requirement is the most complex to maximize because necessity is the mother of invention, and we know that some people may try to cheat the system to obtain other benefits (better care, financial compensation, etc).

However, we must understand that the value of the data is proportional to the security policies implemented. The reading of an isolated detection sensor should not have the same value as that of a set of them following a sequence, plus a NFC reading, plus … . To clarify, we do not encourage to use 20 different types of sensors, we encourage to establish the necessary mechanisms to avoid fraudulent use of the system.

We know that our proposal suffers from not addressing this point with the necessary depth. This is due to two reasons: i) only the analysis of the necessary security policies could take months and ii) without analyzing the day-to-day in a nursing home we are not qualified to do so. For our proposal we ‘only’ use BLE Beacons for the reasons mentioned here.

On the other hand, we would like to highlight that we think it would be relatively easy to convince residents to carry a beacon with them because many of them already carry a device of similar size to call emergency services (or why not, improve the current devices).

Interest in cheating by the detector

Here the question to be asked should be: What is better for the nursing home? That it can modify the data or that it can guarantee that it can not modify the data? For us there is no doubt that the second is much more beneficial both from the ethical and from the economic point of view. And how can they give this guarantee? We can think of two ways to do it:

1. Using an intermediary. An outside company hired by the nursing home (could be you 🙂 ) would be responsible for recording the readings and ensure they are real.
2. Storing the data in a blockchain.

Trusted IoT

This part has given us more headaches than any other since the technology used is more complex and abstract. When the challenge began, our knowledge of the blockchain was basic. After a few months experimenting with this technology we feel that we still know very little, but at least we have unlearned some misconceptions.  Our vision of the blockchain is that:

1. Forget the money! The most outstanding feature of the blockchain is that it allows us to decentralize trust. Obviously this is ideal for monetary operations so we believe that the association Blockchain=Money will prevail for a long time.
2. Integrity and non-repudiation is guaranteed by design.
3. IoT and blockchain combine perfectly.
4. There is a lot of misinformation. Many people still underestimate the blockchain and many others overestimate what can be done in its current phase.
5. The smart contracts will be the trigger for the use of the blockchain in all areas, but we believe that not in the current conception of the smart contracts.

When you start to study the blockchain, the first thing you should do is not to think about it as a whole, since there are multiple proposals that experiment with multiple concepts. There are public, private and hybrid blockchains, with support for smart contract or not, for general use or for niches, based on mining, preminated, … .

In our case, after analyzing several blockchains we decided to use IOTA since it allows us to i) store data, ii) with no fees iii) quickly. We are not going to talk much about the IOTA since the only thing we would do would be to paraphrase its website. But we would like to encourage you to investigate about it since for us, it is the blockchain with better future prospects.

We only use IOTA to store locations, in which we will delve into our next post. To understand how we do it, we must understand that:

1. We talk about IOTA as blockchain, but IOTA is blockless and it is based on tangle.
2. A transaction validates two previous transactions. Thanks to this, the miners have no place. Neither the fees. It is possible to make transactions with zero value.
3. If a transaction has no value, it is not necessary to prove that we own the private key corresponding to the address that generates the transaction.
4. If it is not necessary to prove that you own the private key, you can use the field for the signature of the message to store any other data, in our case messages with the location that we have previously signed with PGP and, if necessary, encrypted with AES.

The way in which we use the IOTA to store locations allows us to guarantee that:

1. The locations are stored in a distributed ledger and it is not possible to block their access.
2. A message can not be repudiated.
3. It is not possible to modify or remove registered locations.
4. It is not possible to add past information that can be trusted. The timestamp of the location and the timestamp of the IOTA’s transaction will determine if the message should be trusted or not.

As we have anticipated, in the next post we will present the last feature of Jura and we will explain exactly how we do the above.

We would like to finish this post highlighting that in our proposal we only use a minimum part of what IOTA offers. Once we have the data in the tangle, i) why not sell them?, ii) why not offer a better service on demand?, iii) why not use them to build an oracle for a smart contract?, iv) thinking about IOTA snapshots, why not deploy a permanode that allows access to the data under a freemium model?

Our Approach. Part I. Indoor Positioning System

For the Open IoT Challenge 4.0 we propose a “trusted indoor positioning system for nursing homes” but, first of all, it is necessary to ask ourselves, do we know what is this?. In these first entries, we will try to explain it in a simple way.

The basis of our proposal is an Indoor Positioning System, IPS, which is a system capable of positioning people or objects inside buildings. Let’s assume a building plan like the following.

An IPS would allow us to know remotely the location of people or objects in this building. From now on we will refer generically to the location of elements, understanding that an element could be anything either people or objects.

For our IPS Proof of Concept, PoC, we will use some wireless technology such as wireless networks or Bluetooth. We have opted to use Bluetooth Low Energy beacons, BLE beacons, hereafter beacons.

These beacons allow us to calculate the distance by measuring the attenuation of the signal power. The simplicity of these devices, their low cost, low weight and low energy consumption makes them the perfect candidates for the PoC of our IPS.

Usually, the IPSs based on beacons use fixed advertisers and mobile scanners (commonly smartphones). This occurs thanks to i) systems that can work for years using small batteries, ii) the small number of Bluetooth signals in the particular environment or iii) greater anonymity of the users.

Reverse IPS based on beacons, with fixed scanners and mobile advertisers, are less common since they imply several limitations such as i) the Bluetooth signals interfere with each other so the number of elements to be positioned is limited, ii) the IPS calculates the position of the elements, so it scales worse, iii) lower anonymity of the users, iv) higher energy consumption of the system, among others.

However, if the above limitations are not a problem for a specific solution to be deployed, two interesting properties should be considered:

1. Carrying a device of reduced size, weight and long-life battery, an element can be positioned for years.
2. The IPS captures the signals, so it can trust them. This property is one of the bases of our proposal. We will write about it in the next entry. For now, it is enough to say that in our approach we will develop a kind of IPS which has this property.

In order to deploy our IPS, we will need to install scanners in the buildings. These scanners can be any kind of programmable devices with BLE and network connectivity. We believe that Low Cost Single-Board Computers, LCSBC, are the best option. The location and number of scanners to be used in each building should be analysed in each particular case.

The following image shows the same building plan with four scanners (grey boxes hanged on the walls), which could be four LCSBC.

Locating the scanners in the building and calibrating the IPS, any element equipped with a beacon advertiser can be scanned by the system. In our case, the elements to be positioned in the building will be people, each one carrying a beacon advertiser. These devices emit BLE signals that can be captured by the scanners and so, each particular element in the building can be located by the system.

In our proposal, the scanners publish the captures to a general log. A service capable of positioning each element using the captures will be subscribed to this general record. To build the proposal, we will analyse different factors such as the most appropriate beacon protocol, the most suitable LCSBC, the best IoT protocol for our IPS, the positioning accuracy or the technology stack to be used.

In order to carry out the analysis of these issues, we are currently developing PANAL ( from Position ANALyzer) the Spanish term for honeycomb. We will write about this resource in the coming weeks.

PANAL is currently a set of Eclipse Kura components that will allow us to i) configure an LCSBCs either as a beacon scanners or as a beacon advertiser by using different protocols (Eddystone and iBeacon), ii) build datasets, iii) test different positioning algorithms, iv) measure the positioning accuracy and v) calibrate the IPS.

In the next post, we will continue explaining the pillars of our proposal, addressing one of the most interesting and challenging issues, how we are going to approach the construction of a Trusted IPS.