>> Victor Bahl: Well, thank you very much for coming. Apologies for being slightly late, we were at the
Commons, so just walking back took us a little longer than we thought. Anyway, I’m delighted to welcome Professor Sumi Helal. I’ve known him for a very long time. In fact when I first joined Microsoft he was, he use to work with the Development Services Team here and Citrix. Because at the time we had just decided to take some of their code and he use to work on Think Light. That’s how I got to know him.
Then I’ve, over a period of time we have stayed as friends. He has done quite a lot in the area. He’s very well known for smart spaces and smart homes. In fact one of the unique things about his research is that he got development. He got people to donate land, gave developers to build a house, and furniture people send the furniture, put all kind of like sensors in there. Did a real world deployment of it and studied that quite a bit. That was fairly unique.
They actually, he was telling me they would offer people to come and live there. They could live there for awhile so he could sort of study how they use those spaces and learned quite a bit from that.
He’s also, beyond that he’s an IEEE Fellow. He’s also; he was the General Chair of Mobicom a couple of years ago on my rotation. He’s also the Editor-in-Chief of IEEE Computer Magazine. If you know about that it goes to you know all of the IEEE, so it’s a flagship journal. He’s got a lot of [indiscernible]. He’s done a lot of papers. It’s great to have him here.
>> Sumi Helal: Thank you.
>> Victor Bahl: Welcome Sumi.
[applause]
>> Sumi Helal: Thanks Victor and I’m proud to be here. I’m happy to visit the Redmond Campus. It’s always great to be in Seattle. I’m here in CPS Week. They asked if I could come here and Victor was kind of enough to arrange. I really appreciate the, allowing me to come and give you a talk. I hope it’s not going to be boring. I hope it’s going to be of interest to you.
I’ll talk today about the Scalable Cloud-Sensor Architecture for the Internet of Things. I’m with the
University of Florida. This is the Gator Dixmore House logo. That is a house that Victor referred to.
Okay, so this is an incomplete expression by an artist of what the Smart City control dashboard would look like. She was so expensive so I have to pull the project out. I couldn’t continue to pay her because we had a kind of miscommunication. But one day when I have more money I will complete that project.
[laughter]

The idea is that it’s simple and if you have a Smart City then you need somebody to be like, feel he’s in control or she’s in control. You are able to you know melt down parking garage. You don’t want people to come in this area so you make this garage look like they’re full. We would go this way. You have control. But what you really have is real-time data coming up and real-time control going down in the
Smart City. Everybody’s looking in anticipation and talk about Internet of Things and Smart City. But we don’t really know exactly how things will develop.
Today, I will talk about a particular view of how the infrastructure and the development should perhaps go. Not that we know everything but we have enough evidence from our experience to suggest these architectures. They are not completely validated because they use Semele time data for validation. I have to warn you from that. They’re having a real massive city scale datasets is still something that we’re seeking, we don’t have up here.
Real-time sentience, real-time closed-loop control, this would be the feature of the application, the
Smart City. When we say control it’s like really actuation. Actuations, meaning you’re running a software service or actually actuating a hardware device, or attempt to actuate the user. A user actuation means you want the users to do something.
Sometime not able to be very forceful, very successful, sometime good luck. You have to work hard at promoting that the actuation should happen. This is an area called persuasive computing. There’s a whole conference called Persuasive. I think it’s the eleventh incarnation, eleven years now. It’s a whole area about how to model persuasion. How do we do human actuation?
But it’s an area that I got into recently with reasonable results from one of my PG students Dr. Ducky
Lee. He’s now with LG Electronics and the employ him in exactly this area.
The ecosystem for Smart City application would be one where you have numerous stakeholders, the city, the citizen, the government, private sector, many people. You ask whose data bus should you use to put this application on. Right, there’s the question like what is this application? Where are they originating? Who developed them or asked for the development? Where are they?
There’s that question multiple stakeholders. You will have small, medium, large developers including solution. You know IBM, Microsoft; of course global solution companies would play in but also small and medium. There would be no system integrators.
Now I started to look like I’m foretelling the future. It’s like future telling. It is not exactly that. But based on some experiments we have done. One of our research goals was actually to not allow system integration to be a friction in building systems like Smart Homes, and so forth. We have a sentiment against system integration. We tried to sort of find out what technology we need to have in place to avoid system integration. When I say no system integration is not telling the future but telling you the agenda that I’ve already worked on. Please, go ahead.

>>: Why is that you look at the city level. The city government is interested in working with one solution provider.
>> Sumi Helal: Yeah.
>>: You look at a home or a factory, or an office building. Let’s take this office building, Microsoft and
[indiscernible] one solution provider. Why are you making this such an important goal?
>> Sumi Helal: This is really important because you start off with an extremely fragmented world. The
Smart City will not go and give contract to a company, or two, or even a hundred, okay. The technology will keep evolving and insertion of new technology into the Smart City will be an ongoing process.
>>: Yeah.
>> Sumi Helal: You cannot afford the delay and the cost of system integration. You want to have things.
You’re going to revise the ecosystem where the things that you’re integrating in the Internet of Things.
>> Right.
>> Sumi Helal: Where everything has somehow an integration gene built into it. It knows how to integrate into bigger beings.
>>: You’re talking about, so one is like building a system.
>> Sumi Helal: Right.
>>: The other is evolving a system over time.
>> Sumi Helal: Right.
>>: You’re referring to the later not the former?
>> Sumi Helal: Yeah, exactly, yeah.
>>: Okay.
>> Sumi Helal: Smart City cannot be a project that you set a project plan and you have a timeline. It’s not a closed end project. It’s an open ended project.
>>: Right.

>>: In your second point all the different developers even though they might be different people developing and contributing. Do you see a central authority approving and whether they should be you know getting into the ecosystem or not?
>> Sumi Helal: Yes.
>>: Like perhaps the Apple you know and the [indiscernible] ecosystem or whatever. Or you just see it like [indiscernible] put it out and people pick?
>> Sumi Helal: Very good question. We do not assume that you have a particular class of developers.
We assume that even an independent small developer may have something of value to the Smart City.
It will then, if we don’t support him then the Smart City is not taking advantage, full advantage of that scenario. We’re assuming all of them.
I’ll talk about what Succo Federated services in a second here. That will show you why we will go in the whole spectrum. Yes?
>>: Are you assuming no bad actors in this ecosystem?
>> Sumi Helal: Yeah, there will be bad actors of course. I’ll also talk about this. But I have to warn you I don’t work on privacy or security. But I’m cognoscente and aware of that. But that’s not my area, okay.
>>: I’m just going to comment. I think this; the no system integrator is actually a very important architecture point, right? Because what you’re saying is you’re building large systems where you’re going to build it in component forms, so that different components can be moved in and out.
>> Sumi Helal: Exactly.
>>: That means that either through some standardization way or but essentially from an architecture perspective that’s how it has to be.
>> Sumi Helal: Right.
>>: That makes it a very, very interesting challenge I think to how to break up this large system into pieces that actually…
>> Sumi Helal: Yes, indeed.
>>: Can just be like…
>> Sumi Helal: Yes and it’s not that we’re wiping out the business of system integration.

>>: Yeah.
>> Sumi Helal: We’re just replacing it by something else. Business wise this is not detrimental. This idea is not, though you will see that there are other things, other tasks for people to do here. If I receive all these questions on one slide I’m doomed.
[laughter]
Okay, but I’ll try to go with you guys. That’s very refreshing. That’s very good. Okay, so leased cyber infrastructure that is expected. The Smart City’s not going to build its own cyber infrastructure so it’s going to be leased. When we say leased the Cloud immediately comes to mind. There would be secure physical deployments. Hopefully it’s secure.
Hey, how you doing?
Okay, we move forward. Why Cloud System? As the smart cities proliferate into massive scale, sensorbased applications would be pressed to move to the Cloud. Why? Because there is nowhere else to move to and it will not make sense. You need the economies of scale here. You need a neutral and common platform where various stakeholders can accept for that situation that the applications are there, okay.
You need a place for all these developers to develop their applications or these organizations to develop and put their applications. It’s going to be, it’s going to emanate from the Cloud. It’s not going to be anywhere else, okay.
Also think of Smart City that’s a big stake. If Smart City failed, if something doesn’t work one day the whole city feels it, right. You don’t want that, the ability to be stuck in one edge somewhere. That nobody knows edge is like in a steamy, hot steamy Chinese restaurant, okay.
What is wrong here? Use the steam environmental condition otherwise that edge is doing good. But you know it’s not reliable enough. You don’t want to put any application on edges. Or you don’t want them to emanate from the edge. You want them to emanate from a good standing and a good place that’s you know you can sort of quantify its reliability and dependability, and so forth. Everything is pushed to move to the Cloud.
Now, as a result what we’ll have here is that the application is up there. The sensors are out there so we have cyber-physical situation. The cyber-physical system now will cross. That crossing created a dilemma for us which is clouds offer resources. That’s why we’ll put the application there. That’s more reason. But the resources are external so there will be significant crossing back and forth between the application and the sensors. That is the dilemma right there.

Okay, so imagine you’re using something because you have to use it. It’s neutral. It has all kind of resources that you need. That’s where the, everything will be reliable. The applications have now a home; developers know where to develop, where to provision applications. Everything is stable and secure and leasable, you can lease that. You don’t want to own any of this as a city. That’s the right place to be in.
But the only spoiler is that these are all sensor based applications. They’re for the crossing back and forth is just a mess. Now we have to deal with this. Cloud-Sensor System will happen. Here is OnWorld,
OnWorld is like a Gardener but they specialize in smart sensors, smart buildings, smart home, wider sensor network and so forth that are the sensor guys. They show that the Cloud service is the fastest growing compared to equipment and installation. That is in the energy sector in the Smart City. They actually like quote them here. “Services are pressed to move to the cloud”. That’s one evidence and that’s a little out dated report. I didn’t have the money to buy the next report, okay. Though not as expensive as Gardener but they cost money.
What do we end up with? We end up with that you know pending situation, Smart Cities around the world. They’re all lacking Cloud-Sensor Infrastructure because we haven’t seen Cloud Sensor
Infrastructure. We tried to look at that space and see what we can do here.
The talk will be now that I covered why we need cloud-sensor system? I’ll talk about some challenges.
Then I will show you two architectures. One is the CEB or the Cloud-Edge-Beneath approach. That’s more geared toward the Smart City Scale and the Smart City dynamics.
Another one, which is the Spaceify architecture and that’s cloud-sensor architecture for smart spaces, it’s not a Smart City but it’s a smart space. That has slightly different dynamic and slightly different challenges, thank you. Whenever anybody calls you to tell you about challenges you have to realize that as we academicians we strive on challenges. I mean unless we create a big problem we don’t have anything to say, right.
But I started to hate that. Therefore I promised myself anytime I have a slide about challenges I have to put a slide about opportunities. You have to talk of something more cheerful so opportunity. What is a prospect? There are prospect in both and I will talk about this as well.
Key challenges, how can we support open-ended, friction-free, continuous integration of sensors and devices into the cloud? It’s right here. I’m not even thinking that integration is an option. But how can we do this? How can we program the cloud-sensor system? I’m not going to be very happy if I have a massive deployment that we don’t know how to program.
The idea of also, that’s another case against system integration. When you do system integration it’s not a programmable thing. It’s something that’s integrated. From the get go no system integration and one hundred percent commitment to programmability. Whatever I deploy I should be able to deploy it

without applications. It’s an application less deployment. Applications come later and I can change it anytime I want it. Then we’re in the good here, okay.
How can we program it? Do we have, do we understand the programming models? Do we have a programming model to catch up with that scale? That’s another challenge. The third challenge is how can we use the wisely? The cloud is just kind of a, it gives you that numb feeling because it’s elastic. It’s like don’t worry you know I’m elastic.
That’s true, but you have to remember that Smart City even though it’s a very sexy phrase. It is really a code name. It’s a code that city governors and countries use to refer to one simple fact economical hardship is about closing the gap between supply and demand in a Smart City. More people are moving to Seattle, urbanization is increasing.
Okay, in two thousand and eight for the first time the whole earth became now fifty percent urbanized.
In two thousand fifty we will be seventy percent urbanized. Seventy percent of people population or the earth population lives in cities. These are growth numbers. These are, okay, so what are we going to do with that?
The reason you’re doing Smart City is to try to bridge that gap. If we do this and end up sending a check every month, let’s say two hundred million dollar to Amazon because the Cloud is elastic then you haven’t done much. You could move this money into the development of your Smart City.
We have, how can we use the cloud wisely? How can we look at the cloud economical scalability? How to sustain the high system dependability? We cannot let the Smart City fail. That’s going to be the last thing you want to do. Like you know parking lots not work. The stadium light is flickering.
You know if we do this we better do it truly right or we all get a bad rap. We’re all out of business because like, okay, these guys are now entrenching to our life. These things are so smart and what they did failed, okay. You cannot do that. We cannot fail easily here.
>>: What would a Smart City do in the next power cut?
>> Sumi Helal: When the, in the power outage?
>>: Yes.
>> Sumi Helal: Well, that’s a good question. I mean these are the kind of discussion I would like to see coming let’s see to IEEE Computer. Victor said I’m Editor-in-Chief of IEEE Computer. We’re going to need thinkers to think about these things. Like we got a piece about what happened if an accident occur in a self driving car? Who’s at fault? The robot, so we need these issues.

What, you’re throwing out a big question. I learned enough not to take big question like this in a talk because then that diverts my entire talk. Okay, but it’s a perfect question to ask. What happened?
How can we discern the Smart City failure from, how can we factor it out from the traditional failure that could have happened?
We have AT&T had a major outage nineteen eighty-eight maybe. I can’t remember exactly. But we have when we have power failures, power grid failures. How can we prepare and condition the users to understand that landscape? These are big issues.
Okay, I better move fast here. We tried to address continuous integration through the Atlas architecture. That’s our previous work in the last eight years. We also looked at programming models.
We have SODA, that’s Service Oriented Device Architecture. We have done that programming model.
We tried to standardize. It was IBM, Emerging Standard Group, and Rally.
We tried our best to stand it out and we went and met with stakeholders in Europe, the United States of course North America. But it didn’t fly. I don’t want to be asked why because I don’t know why it didn’t fly. I still believe it’s a great standard. It’s a good way to program but it didn’t fly. I was just proud to be able to play with IBM, with a company as great as IBM. That was, to me I did my part. But I don’t know the dynamic of why it didn’t fly.
How can we use the cloud wisely? How can we look at the energy issue? Those are going to be the focus of the talk today.
Okay, so these were the challenges that I promised. What are the prospects? What are the opportunities? For the Smart City economically enable the smart city to bridge the gap between supply and demand. That is the upside.
Also economically as I will show later in the talk monetizing, so monetization in the smart spaces. Not in the smart city but in smart spaces. It turned out that smart spaces are one of the physical aspects that have not been really leveraged yet to the full extent that one can imagine.
You go to a mall. You go to a school. You go to a place and you ask yourself what are the informatics of that space? To what extent this space is really supported digitally and formatically? You’ll see that not much. You go to a mall and you see the slated place that you are here, okay. Let’s imagine maybe you go to Seoul Korea in a mall you see more dynamic arrows tell you where to go. Okay, so, okay that’s great.
But the whole thing is not as ubiquitous as pervasive compared to all the research you have been doing in pervasive computing. It’s still not affecting spaces. I think we need an architecture here to monetize on these spaces. When I say monetize I say that there is an opportunity for space owners. I’ll explain this opportunity later. I think it’s one of the, in my opinion one of the things that get me really excited is there’s significant industry to shape up on smart spaces. These are all prospect.

Finally, environmentally sustainable energy and greener life that’s on the upside. Then ostensibly better quality of life. If we do all this in a smart city we are not a hundred percent sure people will be happier or not. But happier or not if it works governments will move on with it. Because again it is about economies and try to get things to meet ends, so quality of life for the end user ostensibly would be better and enhanced user experience. But that is to be evaluated.
Okay, so now I’ll focus on two challenges. First one is Cloud Scalability Challenges. I just say that if you have hundreds of millions of sensors in a smart city each sensor will have one minute unit cycle. Then you have hundreds of billions of transaction daily, hundred millions, hundred billions. If you have a billion sensors you have a trillion transactions, okay, daily.
Imagine going getting that attention of the cloud that many times, okay. That reminded me with cellular data. When we had cellular data and we have a way to price it, to the end user. Then M2M came. Then the cellular industry did not know how to price this because here you have a trailer want to send just a few bytes to a server.
What kind of contract you have with a trailer? Turned out you don’t have a contract with the trailer or the driver. It was a company based on how many SIMS and how many data would be exchanged.
Similar thing will happen here, okay, because these are not user accounts. These are not developer accounts in the cloud. These are just a squirt, a simple attention needed, you know interaction.
Charging for interaction will not make sense. We don’t know how to charge. But never the less it will cost. That is how much interaction would be.
Then what we’re looking here is that even though the cloud is elastic its auto-scaling rate will be costprohibitive, if it is left unrestrained. Unrestrained mean we have to slow down the elasticity rate, against what? Against too growth processes, one growth process is the horizontal growth which is you keep adding more sensor. Just going and adding more and more sensor, light rail, this, that, smart meters. You keep adding things and that is one dimension. The other dimension is the application the abusing utilizing these sensors, okay.
Against these two growth processes you will tend to utilize cloud elasticity. Our job is to no, no, no, we have to restrain that elasticity as much as possible. That’s what we mean by scalability here. Okay, the second challenge is energy. The smart city with all this, you have multiple stakeholder, insurance company, the city, the citizen, everybody, and sensors. Everybody can actually ask a question.
Everybody tries to access the data. That is famous in database domain to the redundant data acquisition problem.
Okay, but here the problem isn’t only just performance. The problem is the more you hit on the sensor the more, the faster the sensor lifetime will go. The sensor will run out of energy. We don’t want that situation to happen.

There has been significant research in this area and IPSN, and Mobicom, and others. But I think we started to see now that if you bring the application from the top and involve the application in the optimization problem to minimize sensor energy consumption. Then you are moving into the second level of savings, okay. You cannot ignore the application. You cannot keep just doing, being energy efficient. Try to minimize energy consumption of sensors when the sensor is asked to sense, that’s too late. That’s too late. I need to first look at the application. Then I will realize that there’s more that can be done.
>>: Question?
>> Sumi Helal: Yes.
>>: You see [indiscernible] when we play bad and then sending information on their own?
>> Sumi Helal: Yeah, so okay, so when you have a smart city and Internet of Things. You have sensors you’re going to be, the default is that you are data driven. Data driven means you ask for the data you get it. Or you ask the sensor to please send me the data in every, frequently, every duty cycle. That’s called push; pull/push is raw data. That’s data driven. Or you move from data driven into model driven.
Model driven is richer. It’s powerful. Developers now can do really good stuff, right.
I will show a slide here shortly that show you that you know data driven is good but limited. But need to move to model. We have events. You have phenomena cloud because the city may just want to see a phenomena, phenomena means like a trend. What is a phenomena cloud? If there is any trend going on in something, okay, so that’s a phenomena. You can have an activity model. You can have a context; context is some kind of model, right. You can have a stream of sort. These are all more powerful things.
A programmer wants to ask we’re in a city stream and where do you want a stream? That’s a high level thing it’s not raw data, okay. As I will show you soon that we need to empower the developer and the smart city, by giving them these sentience abstractions, powerful sentience abstraction.
I will point to a major research problem that really will take genius to solve. I’m trying to get to it but I don’t have the rigor to do it, okay. I’m with a team with people who have the exact background to solve it. I’m looking at compiler of [indiscernible] people for example. I’ll explain that. But just to answer your question it is data driven or model driven.
>>: Yeah [indiscernible]. There are a lot of applications that have the full model of reading data from the sensor. Wouldn’t that also mean that the lower bound on the cloud is now going to be lower?
Because the sensors are not going to have you know billions of transactions on the cloud. Because they’re just going to have it and data work from them when I need it.
>> Sumi Helal: Right.

>>: I, so these are like you know. The more there are pull monitor applications then the less that is a challenge on the cloud side would you say?
>> Sumi Helal: Yes, absolutely, yeah. Pull/push envelope has to form; it has to be optimized, okay. If you are to get the data anyway you ask yourself should I pull on it when I want, or should I just ask it to come to me, okay?
We have done early work actually here. We published in MSWiM which is exactly called the Adaptive
Push/Pull Model, Push/Pull Envelope, in this kind of cloud-sensor system. We’ve done that to where we research and we published it. But then we realized it’s still inadequate. It’s missing pieces.
Let me go through it and I’ll show you more, okay.
>>: Okay.
>> Sumi Helal: Right, we’re doing better here. We get just a few questions and a number of slides.
That’s good.
Okay, so before we go any further I showed you two challenges. Okay, the scalability, so we make the thing work, not expensive we can use the cloud. I showed you that we need to do way more to enlarge this lifetime of sensors, energy.
Before we go any further we, even though these are the challenges. This would really be sort of the guiding principle is even if we solve the challenges and we look at the prospect and possible gain. We have to be driven by some, by value system.
Bob Metcalf he set very good precedence when he came up with this value of the network. He argued almost forty years later that his formulas still work which is debatable. But he’s at least having some notion of value. I don’t know how to access the value of the Internet of Things. I don’t know.
But I know like extremely strong imagine that it’s something like this. I would like to invite people to think about it because it’s not enough to have things that are connected. You can have an army of things that are all connected. But what is the value gained? Can we pinpoint the value?
During the World Cup last summer I started to get a sense of that value when I had the best mobile app for the World Cup in Brazil. I’m able to drill down and just keep saying oh that guy he did a really good job which I’m sexist because she might be a girl, okay. It’s an excellent app.
But now I know this is a guy drilled down, this is the game I wanted. By that point I have to put my
Smart Phone move to a different room, bunker down, mess with my DVR to set the recording of that particular game. What we have here we have an Internet of Thing. We have smart TV, smart recorder.
I have a Smart Phone, smart apps. But I am actually doing the work, okay.

In the Internet of Things that app done independently by somebody should realize opportunity. The recording should be a service immediately added to the app, okay. I’m able to record. But you know we’re not there yet at all.
The value of the internet is not on having things. No matter how much impressive we think we are because we try to impress people. But, see the small thing, very small here. This is part of the Internet thing. We seem to be so gratified by the fact that things are so small yet they’re connected. Okay, we have to get over this. That’s fine but everything will be small and we just get over that. That’s not enough.
What is needed that we have the ability to program in which many ways can we program that network of things. At what management cost? If we have to manage it, if we have to manage it by software or by money, or by human effort, all that’s management. If it’s not too much then we haven’t succeeded, okay, so we have to, we have to get the value out by allowing an end to this thing to be programmed in many different ways and at a reasonable cost.
>>: I think there has to be some term in there which doesn’t [indiscernible]. Because you think about the network affect and you think about the same thing in [indiscernible]. Are we talking about, so there should be a factor, multiplicative factor here which includes the continuity to connect more and more together.
>> Sumi Helal: Yes, yes, absolutely.
>>: And that’s how to prove it.
>> Sumi Helal: Here you go I like that.
>>: [inaudible]…
>> Sumi Helal: This is the soft source to you now Victor.
[laughter]
>> Victor Bahl: Okay.
>> Sumi Helal: I knew I don’t have the right, I’m just [indiscernible] I want to throw it to sort of the missionary about it. This is really important somebody needs to look at that.
Okay, so now let me get to the serious work which is the architecture itself. How do we connect sensors to the Cloud? We have the Cloud. I tried to convince you. I hope I did that everything has to connect to the Cloud. What happens is you get sensor deployments. In most cases sensors have jurisdictions and

have the concept of Gateway. Most sensor deployment has a notion of Gateway. You have to connect to something like a ZigBee Gateway, some of sorts.
If that’s not the case then imagine that, okay, you can force an edge to them. You have an edge layer here. Then from the edge there itself connect to the Cloud. Okay, so sensors are not a flat space. They are structured into jurisdictions, okay, organizations. They all have Gateways.
However, that’s one view of what the edge is. The other view is that the edge is actually a strategic agent of strategic importance. It’s something that sees up and sees down. It is an entity that has opportunity to understand the application and understand the data. This is a strategically important thing.
In fact it forges very interesting ideas like inverted Cloud. Inverted Cloud means if we just assume that you can even overpower this edge a little bit. You have a little bit of powerful edge, okay. Plus an edge has nothing, no states per se, nothing to worry about. You could replace an edge any day, right, okay.
If you have this then the Cloud can think of the edge as its own Cloud, that’s not clouded, the Cloud has approached Satya’s work and others. I shouldn’t just say Satya. But Satya and others work. The Cloud is about getting the Cloud to provide the support down closer from the application.
On the Cloud it worked. The applications are down here, okay, in a smart space. The application when I get one hub, one of you just as close as one hub from the Cloud. We get a little Cloud down to earth.
Okay, that is one world. That world I’ll talk about it later on when I talk about Spaceify, the smart space thing.
But here the application’s up not down, application is up. When we have an edge here and we start saying that edge look like a Cloud. It’s a Cloud not to the application. It’s a Cloud to the Cloud. I call that inverted Cloud. That’s a powerful concept because now we’re worried about the scalability of the
Cloud. The data stems from these things. A little bit of coordination on outsourcing into these edges will go a long way in playing into the scalability equation, okay.
When I say beneath in the picture below, beneath really mean the actual physical sensors and actuators.
Since not all physical sensor and actuator are smart we just force them to be smart. If something is not smart plug it into a sensor platform. Sensor platform is something that was smart and a thing, right.
Eventually these platforms like Arduino, Beagle bone black, and all these things, Raspberry Pi. These are smartners, okay. These smartners eventually will be so miniaturized it will be baked into these things.
We will not even talk about sensor platform in the future. But for now let’s talk this way. Question here?
>>: Actually I’m finding that the capabilities of Pi makes it an ideal edge platform.

>> Sumi Helal: Yeah, absolutely.
>>: The Bluetooth low energy and everything is underneath, I think.
>> Sumi Helal: I agree with you.
>>: Yeah.
>> Sumi Helal: You know if we’re talking about this Vietnamese Restaurant I’ll put the Raspberry Pi. If
I’m talking about a Marriott Hotel I’ll put the edge. Okay, because it depends how many sensors. This is why we said jurisdiction. That represented jurisdiction. Automatically I should assume that the edge had the right capacity for is jurisdiction, for its sensors and actuators.
>>: That’s assuming you want to talk to the Marriott through just one edge. Maybe there’s a separate security system, HVAC system.
>> Sumi Helal: Right.
>>: You know so there might be multiple edges.
>> Sumi Helal: Yeah, you could, you could. Nothing prevents you from taking one edge and structuring it into a group of, into a tree of edges, okay.
>>: I just find the Pi to be a really low cost node that’s fully programmable.
>> Sumi Helal: Yes, yes, yes.
>>: Be and edge on its own.
>> Sumi Helal: Absolutely.
>>: Yeah, okay.
>>: You talk about pushing the smarts down if it’s like power savings and other things in the Cloud also.
But how do you think about standardizing some of the common algorithms or the way of communicating with these different edges and the sensors themselves? Like how important it is to actually have a way to say I want the smarts as low as possible so that any developer can write an algorithm? Instead I push it as far down as possible, what are your thoughts on that?
>>: [inaudible]

>> Sumi Helal: Yeah that’s the end game. The architecture will wave this concern from the programmer. The programmer will just develop code.
>>: [inaudible]
>> Sumi Helal: The architecture will try to do something very simple. Try to get the most curious application. Let me say application fragment at that point, okay, with the most curious application fragment down as deep as possible and the most surprising data as high as possible.
Metaphorically that’s what Doc Fisher would do. But the programmer…
>>: [inaudible]
>> Sumi Helal: No, however we will utilize some corporation from the programmer. I’ll talk about it in once second. Okay?
>>: Are you [indiscernible] sort of a…
>> Sumi Helal: Yes, speak up a little.
>>: But, no, no I want to sort of, you have an incorrect understanding of what a clouder is. I was the second author on that paper so I know.
>> Sumi Helal: Oh, I’m sorry.
>>: That’s okay. The clouder is not about just from cloud to cloud net. It’s actually, on the paper for example, the second paper we wrote. It is about offloading computations from the device itself up to the edge.
>> Sumi Helal: Yes.
>>: Of course it’s also about producing latency as well to the Cloud.
>> Sumi Helal: Do you really think that…
>>: We sort of think about it is we think about it as multiple components and the program actually sits on all these components. How you partition the program into which of these components become the sort of interesting [indiscernible].
>> Sumi Helal: Yes, I referred partially only to the latency aspect of the Cloud.
>>: Yeah.

>> Sumi Helal: You’re absolutely right. Yeah the clouders are great. I’m just; I was trying to
[indiscernible] the difference between…
>>: We call it internally the way we think of this is we thing of for example what’s data centers to the
Clouds. We have this thing called Micro datacenters out of cloud nets.
>> Sumi Helal: Yes.
>>: Micro datacenters can be you know at least one server to multiple servers. I think what is being pointed out is you have this other [indiscernible] something just sitting right at the edge [indiscernible].
>> Sumi Helal: Yes, yes indeed.
>>: Alright, that’s cool.
>> Sumi Helal: Thanks for the clarification.
>>: I’ve just got to mention one interesting mobile code is the Amazon Lambda where there’s a fragment of a node.js application that you can push to various levels.
>> Sumi Helal: Yes.
>>: Yeah.
>> Sumi Helal: We have keen interest now in what I call diceable applications, or diceable programming models. Event driven models are diceable because you can cut; you come and cut in any part of the tree. That sub-tree becomes what you push down. That’s a fragment, application fragment. Even functional programming is diceable, POP sub is diceable.
All of a sudden diceable application models sort of become important. They’re more utilizable here in these architectures. Yeah, so far a lot of people going to events and I suppose this is the same that can be said here in Microsoft, one event driven application model.
>>: Yeah, in Azure we have you know service bus which includes a number of different services
[indiscernible]. We don’t have the partial programming concept that Lambda supports. Would they bolster your core?
>> Sumi Helal: Yes.
>>: Essentially start you when I think that happens. We push that to the application. But in a sense it’s very similar, right. It’s just that what, as a developer what are your concerns? Like in the Lambda model

you don’t really care. When you start up in our model for right now we have, you have to be concerned about a lot of throughput latency issues and so on, right.
>>: I’ve been automating my house and doing just this. Now you put names to what I’ve been building.
Basically what I want to do is I want to have like a Lambda function, node.js that when I open the front door my rules run on my local edge to turn my lights on and everything instantaneously. But I don’t have to worry about when I go to my phone or whatever and I want to change settings. That goes to the
Cloud. The Cloud is to set the truth.
>>: Yeah.
>>: But I don’t want to wait for a Cloud latency when I open my door for something to happen.
>>: We hear it from customers that they don’t want to have a sensor sending data to the Cloud that says I’m okay, I’m okay, I’m okay ninety-nine point nine percent of the time.
>>: Yeah.
>>: It makes total sense to push that intelligence down to the edge in some cases.
>>: Yeah.
>>: That you avoid that.
>>: Yeah, and I get excited about these fragment applications. The term you used.
>> Sumi Helal: Application fragments.
>>: Yeah, I like that term because those lend themselves to being moved up and down the hierarchy.
>> Sumi Helal: Right.
>>: That’s what I like about it.
>> Sumi Helal: Yeah, and that’s the point is the mobility of it.
>>: Yeah.
>> Sumi Helal: Okay, let’s move quickly now. This is architecture. It would be insane to go over it in one shot. I’m just going to describe a little bit. It provides autonomic integration. It’s a programming platform, an ecosystem for developers. It provides optimization. It is an optimization enabling platform.
It chooses data caching, application caching. It also is guided by energy efficiency principle and what I

call sentience efficiency principle. That is where we feel is new and that is thanks to consider the application and everything we do. Instead of being just energy efficient you become sentience efficient.
Let me go over what these principles here quickly. We all know energy efficiency, degree to which total energy used to provide sensor readings is minimized over a period of time. Okay, how close are you from optima that’s how efficient you are over a period of time. Now we throw in sentience efficiency to be the degree to which unnecessary sentience of a sensor readings is avoided over a period of time.
You have a Smart City. You have tons of applications and you have tons of data. You keep getting the data to the application. What you levy up may not all be used. Let’s say fifty-seven percent of it was not used. Then that is a deficit in the sentience efficiency because you could do without them. If you could tell the future, if you knew about. If you knew around the application you could avoid getting the thirtyseven percent. Then you are better off. Then now everything you do in energy efficiency becomes truly what you need to do. But there is no point in being highly energy efficient in getting a data that you don’t use. Yeah, it is highly efficient unnecessary thing. It doesn’t help you.
>>: It sounds like my definition of non-effecient, right.
>> Sumi Helal: That’s definitely efficient at the end.
>>: Your point before saying you have to be concerned by the, above, the concerns of the needs of the application to be efficient.
>> Sumi Helal: Exactly, yes, yeah. Part of doing all these acrobatic moves, application down, data up is to figure out what can we skip. What we shouldn’t really be sentient too without missing the application. If we’re able to dig there we are digging deep into better savings.
Okay, so process of dynamic is really a combination of both which is a minimized movement of requests down and data up. Now let me describe the architecture piece meal. That is a beneath layer. It has the actual physical hardware. This is the physical sensors and devices. This is the first layer.
Anything blue is our middleware, so three pronged middleware. Anything that is red is optimization element of our solutions. The architecture has built in optimization, distributed optimize. Red is optimizer, blue is the middleware itself. Now we have green and yellow. Green is data cached and yellow is application cached.
You can see here application can come down all the way to the sensor node. Data of course can be cached from the physics, from the physics itself. Like you got a reading, you keep that reading, and that’s your cache. That layer is built on the Atlas architecture that we have developed and uses SODA.
It allows you something called the Device Description Language. Any device has a Device Description
Language. It’s almost a device driver of the sensor.

But unlike the [indiscernible] driver when you get a printer of course you have UPMP now and others.
You get a printer before UPMP you have a device driver and the device drivers what you have to use the device, okay.
That’s what we do here. But we go one step further. We add a lot of things that are very important.
For example in which way I can play as a thing, okay, because really we ask what is a programming model? What is the application developed?
I can guarantee to you that the only way in to the thing would work. That when the programs are already partially written into the thing. Okay, very good I got a confident yes, thank you. Because I’m not confident I just wanted to hear that. It is when you develop the thing. You say how can people use it? In which way they can use it?
I go back to that World Cup scenario that really enlightened me because it was something very stupid.
But we were not there. We talk and I go give talks about internet things. I cannot record my game. If the DVR is able to express what it is in which way it can play. Then applications can find out what can be played. Then they’re able to sort of find out that they’re able to work together that’ll be great.
The place for this would be the device description language.
>>: DDL is that part of SODA?
>> Sumi Helal: No, SODA was a set of specifications.
>>: Yeah.
>> Sumi Helal: Our implementation at the University of Florida involved DDL.
>>: Is that a standard that is…
>> Sumi Helal: It didn’t, it set up the [indiscernible].
>>: Okay, so it was part of the SODA standard?
>> Sumi Helal: Yes, it was.
>>: Okay, I was just curious. To some extent independent of whatever standard survives, right?
>> Sumi Helal: Yes, yes…
>>: It makes total sense. The device needs to describe itself, right?

>> Sumi Helal: SODA died in a way but it entered into continuum, the continualize. If you go to the continual you will see actual pointer back to Universal Florida and also pointer to SODA. But it got phased into the continualize. Yes?
>>: In regards to putting the intelligence down into the device. The devices are really restrictive and could involve flashing and talking about you know code and RAM space. A proxy for the devices intelligence can be done on the edge. It’s like Cortana, right.
>> Sumi Helal: Yes, yes.
>>: It doesn’t recognize your speech the Cloud does.
>> Sumi Helal: Yes, absolutely.
>>: I think that model may, if your DDL and all that worked in many cases.
>> Sumi Helal: Yeah, yes. That’s a role to play by device management.
>>: Yeah.
>> Sumi Helal: With our standard for device management. Juan actually pointed me to some effort.
We’re looking at other device manager. The device manager will come to play about how to sort of prepare these things to play in some sense.
>>: There’s so much traversity in the small firmware driven devices right now to expect to re-flash them for application scenarios is going to be difficult.
>> Sumi Helal: Yes, yes.
>>: A proxy can be favorable.
>>: I’ll give you some feedback and I’ll find out what we’re driven to the industry for additional
[indiscernible]…
>>: Right.
>>: There are platforms in standard sensors that are real today that conform to this kind of a standard.
>>: Oh, even though in the [indiscernible] ideas.
>>: There would be the expert sensors.

>>: Yeah.
>>: There’s certain sensors that are built saying and I’m so cheap that I conform to the standard.
>> Sumi Helal: Yeah.
>>: To help to synch up really well.
>>: Yeah [indiscernible].
>> Sumi Helal: Who developed the DDL? That is a vendor of the thing, okay. What can be there can be many things? As we said how to use and which way it can be programmed or opportunistically programmed.
Also a bunch of things that we worry about like safety, so safety is very important in smart spaces. Like especially in the smart home where we had in Florida. Imagine an elder person wakes up in the middle of night because a speaker goes off in the middle of the night by some error, by some mistake. The poor man just gets a heart attack. It’s just so scary. Then again, that’s where our technology failed, okay.
How can you provide some measures of safety? We had a lot of research on safety, two PhDs on there.
But one thing we learned is that safety is one of these concepts that can become very domain specific.
But across all domains there is that kind of common thing, common ontology, common concerns. Like the word failure, the word safe, unsafe, the word dangerous, okay, desirable, undesirable, permissible, impermissible.
We found the world of almost fifty vocabularies that describe safety. We realized at least we can obligate device manufacturers and vendors to play. By tell us a little bit about the device in a way that we can utilize to develop safety oriented programming model.
For example if you have a Smart Knob. The Smart Knob is what’s going to strike and open the door for you. The manufacturer is bringing this now, its two thousand nineteen in this Internet of Things. It’s already settled down, everything’s Internet of Things.
Manufacturer in China ships we bring this thing here. Then we open the box. We get the knob and we install it. I want to go to DDL; I want to see the DDL. It should be somewhere. The DDL will tell me that this knob can handle at most seven strikes per second. If you have a bug in your program, you go in the loop and you’re trying to actually [indiscernible] strike fifty thousand times per second for a period of five seconds. That’s your bug for whatever reason it is, right. That would burn it, okay.
That’s a program of developing application, injecting bugs, debugging until the system is working. But the vendor doesn’t want to play in that space. The vendor now will tell you that maximum seven strikes

per second. Now you can program as much as you want it. The runtime system should sort of stop you and say, oh, no you, must be a bug. It will not obey fifty thousand times per second.
This was exactly similar to when you go to the fun park and get to these cars. The car gives you the illusion that you can turn forever. You could turn it forever, flat out, flat out, okay. It’s not flat out. Its fixed speed, maximum speed, and you can turn as much as you wanted. It’s not going to obey you.
That’s a safety measure for kids, right.
Same thing here, so this DDL is where you can actually inject these characteristic of limitation of your devices. You are able to play in a nice way. We utilize in many ways. You can actually get to see, I’m sorry here. You can get to download DDL from that link. I suppose this is recorded and also I can, I’ll be happy to send Victor the presentation. You can look at or just DDL Florida, University of Florida should get it to you. I forgot search engines.
Okay, so this is the lower layer. This is the Atlas architecture. It is something similar to the mode its
[indiscernible] based. It’s modular and everything but it’s not something that would program. It is something that we built so that we don’t program the thing. We connect the thing to it. Once we connect and power up that thing sort of get out into the rest of the internet as an object, as a software object.
Okay, so it’s about externalizing, okay. Most of the smartening we have done in the past was introvert.
It was like smart camera. It’s very smart. You put smartness into it. R2S and all kind of things it’s a smart thing.
For the Internet of Things you don’t want a smart in, you want a smart out. You want to smarten it out.
You want to connect, put something here so that when you power up whatever you connect to now has a much more powerful effect. It can be programmed. It can be picked up. It can be part of other things so it’s out not in.
Unlike the [indiscernible] we don’t program the Atlas. We program the Atlas effect outside using high level of concept like Java bundles for example. Atlas was commercialized by Pervasa. Like every business endeavor I tried it failed. I’m not a good business guy. But we won the best of sensors expo award in the year two thousand and seven. That’s the same year that xCrossbow won silver. We won the bronze. I went back to the University of Florida. I send a message to my Vice President of Research that we won the bronze and Crossbow and Berkley got the silver. He replied back to me and said good.
[laughter]
I talk, so today Atlas is dissolved, Pervasa is dissolved. The patents, amazingly the university gave me back the patents because they did not want to pay the renewal fees. All of a sudden I own back the two patents for Pervasa. The hardware is ceased. We stopped; we got out of the hardware business.

The firmware is redesigned to allow for thing-to-thing in addition to thing-to-edge because original version with thing-to-edge. Now we’re doing only thing-to-thing. We’re supporting other people’s hardware, Arduino’s, Libelium, and Beagle bone, Raspberry Pi, and also big things. Like we’re doing all the small things but we want to provide support for Android, for just bigger things because that’s, then everything connects together.
The middle layer and the edge layer once you connect a device its DDL is used by a bundle generator to generate a bundle. All of a sudden that physical hardware has a service, an edge service. Immediately the edge service is passed up to the Cloud. You have cloud sensor service and an edge sensor service.
That replication of service is very paramount for performance. That will enable significantly the cloud scalability because now you’re able to switch about where to do things.
That edge that I just made the case to be an inverted cloud or in the cloud, on the real cloud. But it’s just a matter of thinking then you don’t need to move anything. Okay, so that is very powerful concept right now to have this lightweight replication.
>>: Can I ask where does policy come within this?
>> Sumi Helal: Where is policy?
>>: Yeah, so for example device A can connect to device B.
>> Sumi Helal: Right.
>>: Or C.
>> Sumi Helal: Yes.
>>: But not to D.
>> Sumi Helal: Right...
>>: For various reasons because of you know policy reasons why.
>> Sumi Helal: Yeah, so that would be in DDL.
>>: That’s in the DDL?
>> Sumi Helal: Yeah, so I don’t have all this.
>>: Who writes the DDL, the device owner?

>> Sumi Helal: No, the DDL is an accumulation of things. The DDL, original DDL comes from the vendor, okay. Now you have a device manager. The device manager comes to, for example if you are a trucking company and you have some ZigBee sensor in your trailer. You don’t want your trailer to come to fill gas, stand next to another trailer. The sensors start exchanging messages together.
These sensors that you have there, each one of them has a DDL, okay, or have the same DDL let’s say.
You know what they are, what they can do, the limitation, blah, blah, blah, how to integrate them quickly. But then you’re adding things such as keys for example. These DDLs, these things can communicate only with an edge after a challenge. That is a key, so you need to add this thing into the
DDL, expand the DDL.
It’s all into device management. The [indiscernible] ones would be like this. You want to go to smart city, or you’re going to do an IoT deployment. You get your sensors. Sensors have say five different sensors, you have five different DDLs. You get them all. Now you’re preparing them, provisioning them for the application. To provision them you have to say these things about who’s your edge. Who can you connect to? You put limitation. In entertainment application you want them to be very promiscuous, very open.
>>: Why do that DDL you have a middleware there, right? Why not have a separate policy manager? Its part of your middleware. which can read the DDLs and can sort of decide whether certain matchings make sense or do not make sense.
>> Sumi Helal: You can do it this way. What…
>>: But then the video gets to [indiscernible].
>> Sumi Helal: Yes.
>>: I mean if everybody owns it then nobody owns it. If the device owner owns it then these are
[indiscernible]. But it’s a very tight version of it.
>> Sumi Helal: Yeah.
>>: And, yeah.
>> Sumi Helal: We will look at middleware as runtime, so it’s what happens at runtime. You can say that the device manager, device management tool it can be put here in that layer, you can. But it’s not going to be a runtime thing. It’s something you do to provision before you go into runtime.
Okay, so again the device has now two services an edge service and a cloud service. These are sensor services. This is actually part of our middleware here.

Let’s move over quickly. On the cloud we have the cloud sensor service as we saw here. We’re using actually OSGi Cloud. On the edge we use OSGi. On the cloud we use OSGi Cloud. Why? Why did we choose OSGi? It is just simple. We have moved on with it. We felt it can definitely change something else. But as a researcher it doesn’t help us to keep jumping around because we lose a little bit of steam this way.
What you’ll notice here is what is called ACM Atlas Cloud middleware. For every edge, remember the picture you have multiple edges? For every edge you have a framework, OSGi framework. You have multiple frameworks one for every edge.
Then you have other frameworks for the application. This is Cloud App Runtime. That’s an application.
The application has event services. Event services, event tree. The leaf, the bottom, the leaf parts are, have to be cloud services. The end is a cloud service. That’s your application. They are running under a
Cloud App Runtime.
Okay, let me just quickly. Let me skip this here. But I just, the one thing I want to say here is this. These are monistors, memory and processing monistors. It’s very important to track and know as the expansion in the smart city happens. As the aggregate applications are running we need to monitor which monistor is bigger.
You know is the ACM or the CAR. Also whether they are becoming, what is a dominate resource memory or CPU? The reason is we’re not going to dimension the cloud blindly. We’re not going to have a simplistic dimensioning. Because as the smart city grows the, or peak time. You want to be asking intelligently for what you’re going to pay for.
You want to ask for exactly what you want. Do you want more memory or you want more processing, or how much memory, how much processing? We need to know in which way to dimension. That would play a factor knowing the dominate resources in these two things.
I mentioned to answer your question that we do raw data and model. Okay, so we support only raw data or events. We don’t support any of this. That needs to be supported. The observation to make here is to empower developers in the smart city you want to give them all this, all these models. All these models have common nodes, right. Each one of these models, imagine the model is a graph.
These graphs are of course overlapping. Let’s talk about the same set of sensors, right. It is impossible to develop silos of models. You will not scale.
We need people to look at how to have these common complex graph that catered to all this and optimize them. They’re not expression trees. They’re not compiler optimization. But the guys who will be able to probably succeed are compiler guys. But they are not static expressions. These are expressions that have time and dimension into them. If we’re able to optimize these trees, combined trees, we would be doing really great. This is a complex problem. We started to see it. It needs brilliant solutions. We didn’t work on it.

Okay, I need to speed up here. But I just want to tell you that we use SODA, Service Oriented Device
Architecture. As you notice in the sensor is a SODA, is a service. Okay, but that is just a sensor. But the application itself is not service oriented. The application is actually rule based. You have ECA rules which are Event/Condition/Action. We don’t pay attention to the condition or the action. We focus on event, event service.
Event service can point to other event services. These are called virtual sensor. But at the end they point to Cloud Sensor Service. That is application to you. A bunch of rules, each rule is ECAs. Each event is a tree. That’s the application. These are our, or actually this the grammar that we use, event grammars.
The notable thing I want to point to is TFM. You can have an event defined to be an expression. After you define it you can say event equals TFM of event. That’s where we involve the programmer to tell us a little bit about the Time, Frequency, Modifier. Meaning, seriously this is an event.
How do you expect us to process for you? Should we evaluate it constantly? We can’t evaluate it constantly. Tell us how frequently should be evaluate it? Or what is you know what is the time characteristic of this event? For example air conditioning, a temperature in the room. You can’t do it; you don’t need to do it every, even every minute, okay. You can go less frequently. Okay, so involving the programmer to tell us as he defined or she defined the event. What is a TFM relaxation is a paramount importance to us?
That’s an example of a parking situation and showing you how the events are actually binary. But then they return parameters to find out the nearest parking lot. I don’t want to spend time here. I can imagine you’re very intelligent to understand that example can be looked at later if need be.
Okay, so that was architecture. How can we optimize it?
>>: Can I ask a question?
>> Sumi Helal: Now, we need to speed up, yeah.
>>: [indiscernible]
>> Sumi Helal: Let me, I’ll explain, this is complicated. I’ll explain it in a much simpler term here. This is easier. We optimize it; the optimization we have is sort of a waterfall model where we have several optimizations. But every optimization algorithm get like already partially optimized situation to deal with. It’s like a waterfall model. But it’s by directional’s which one like does water go up.

When I went to Brazil one day they told me that because we’re on different part of the world, when you flush the toilet the water will go this way. I was so impressed. Then they told me also when you take a shower the water will go up on the tile.
[laughter]
They really worked me, okay. That reminded me when we say by directional waterfall. It’s like wait a minute. Well it doesn’t fall up but that’s what [indiscernible] my student called it. I didn’t want to change it.
The first optimization is AFCA which is Application Fragment Caching Algorithm. Here you have the cloud, tons of application across framework, OSGi framework. Now you ask yourself there are parts of the application that’s better pushed into an edge. These applications running are accessing multiple edges.
Let’s talk about one edge. That edge here. You have all this application. Are there a bunch of problematic trees or sub applications, events that we can push down to that edge? You say yes we found it. Does the, is the edge ready to welcome them? Does the edge have a capacity because it has limited capacity? It looks like yes. Do we need to kick anybody out replacement algorithm? Yeah, probably kick these two guys out. You’re able to push down application fragment. This work was published in MSWiM two thousand fourteen.
Now that you have these shrubs here, you have these sub-trees. We go to the second optimization which is BPA-Shortcut. This is Branch Permutation Algorithm and Shortcut. The idea is we have these trees here that now are in one jurisdiction, one edge. We have sensor data. The edge now know about the data have been coming for awhile.
You look at these trees and you ask is there any shortcuts? Shortcuts since we have this binary situation you are able to do shortcut. When you shortcut you can wipe out a whole chunk of trees, right. One evaluation allows you to just phew throw the rest of it.
Once you pushed something down here by the way. Then what you do is you replace the total sub, application fragment. You replace it by one node. From that point on from the edge you do what is called sequel selective push, selective push. Only when that sub-tree evaluated through you send something. That’s called selective push, node push.
Now that you have those you ask yourself let’s reduce shortcut evaluation. We notice that if you do permutation. If we just rearrange the trees a little bit you have a much higher chance of shortcuts. Such a dumb idea but it has an effect. We started to figure out how to do a permutation. That gave us a lot of savings.

In the mean time, okay, we need to look down into even more aggressive savings. Application-Aware
Adaptive Sampling Algorithm down here on the sensor level. We all know about the Auto-Regressive
Moving Average model, the ARMA. I’ve done a lot of research on ARMA. Tons of beautiful research
[indiscernible], okay, he led the evaluation. ARMA has to do is like don’t keep sampling learn from what you’re sampling. Once you learn be predictive and change the frequency of sampling. Be smart don’t spend all the energy.
We have Globecom, Mocom, even Mobicom, IPSN, tons of research here, okay, beautiful research.
What we did is we respect all this research. All we did is we took the latest of that research that uses a constant SI. That constant is what we replaced by something else that come from the application. That tell us because here you’re, most of this, all that work looked at the data itself. But now we combine the data with the application because we have the cloud edge. We have both together. That made a big difference in how the performance of ARMA goes.
There’s a good opportunity down here. But hold on before I push down to catch this opportunity. I have to ask myself. If I have some fragments here if I push it further down to the sensor platform maybe
I’ll miss out on a great opportunity for shortcuts. Then we find ourselves in a good place. You know you say this is a good problem to have. That’s a good problem to have is where you can get saving this way or this way. You’re not sure which way to go. Well that’s a good problem to have.
But then that triggered us that our algorithm becomes cost and gain, and loss. What do we gain if we go down, if we cache down a fragment to the sensor platform? What do we gain? What could we miss?
The guy who actually does this is called AFCA two. That is Application Fragment Caching but not from the cloud to the edge, but from the edge to beneath. That is Application Fragment Caching two. That is a guy who computes the potential gain, potential loss. It’s a fourth or four models of optimizations.
Okay, we have done some experimental studies. We did not have the right datasets. We had to take existing datasets for a smaller thing. The MIT house and data, it’s actually better than even our house in the sense of the kind of sensor, the activities. We took this dataset. Then we analyzed. We studied the data.
We created a [indiscernible] network to understand the parameter. Then we used that network to be more generative of other houses. We generate two thousand homes. We’ll call it a small town. Now I have a small town of two thousand homes and that have all kind of interesting sensors. Then we added a few things that provide emergency, that sensor that were never there in the dataset so this SMI real dataset.
You can see we’re struggling here. We created this dataset and moved on with it, and looked at a few studies. First studied is cloud dimensioning. We needed to know the dominant resource. What happens as the sensors, number of sensors increase or the number of applications increase? You keep increasing those in terms of houses. How many houses are you experimenting with?

That is, and we wanted to know what happened. What is the dominant resource? We knew this ACM or CAR. We started to see what we were worried about. That f and f prime here these are the rates for, from. In the cloud you’re asking, you have a request to the runtime, to the ACM. You’re requesting from the sensor servers.
You say I want this data, so that’s f. If you have it you give it. If you don’t have it you have to go down to the edge and say edge help me I need this data. Okay, that’s f prime. This is a request rate. The request rate is increased. Now we see that the resources. These are the basically the memory utilization, CPU utilization.
We see that these resources flip as you increase the request dimension. At that point your elasticity should be different. You should be getting different servers. You should be requesting different servers.
You need to catch that otherwise you are getting things that will not help you and you’re paying for it.
I’m going to skip this and show you that the problem is even more with CAR. This is how flipped the dominant resource was, extremely flipped. If you don’t see that curve and you just keep asking for the same servers you are absolutely going astray.
One thing we learned is that you have to understand what is dominant and how it’s changing? Catch it as it change and dimension the cloud as you go based on that knowledge, no fixed dimensioning. That is one result that we had. We published in the [indiscernible] Journal of Internet of Things. We didn’t publish its accepted but it’s still going on.
I’m trying to give you one point of data here about. Well, let’s put the waterfall model and let’s see the difference. Its combination here, pure pull, add shortcut evaluation, add Branch Permutation, add AFCA two and selective push. Then we tried to see in which way we actually are able to save energy. We’re able to save energy. This is group four which is everything. We’re talking here about thirty percent saving of energy of the sensors. We’re able to save up to thirty percent.
Does this look like impressive results? We don’t believe we are finished with it. We just, this is our initial results. We didn’t have the right validation dataset. We didn’t implement all possible neat elements of the optimization. We have simplistic optimization algorithms. They’re complex but still simplistic. It’s a good trajectory that we’re in. We’re able to provide early evidence that we’re able to scale. We’re able to save energy.
Okay, I will stop here with the Cloud with CEB, Cloud Edge Beneath Architecture and moving into something else. That is moving into something else. That is Spaceify Architecture. Unlike CEB, CEB is a mess. We can definitely provide CEB for you. But it’s a penalty to you. It’s not yet ready for you.
What is ready is Spaceify. Spaceify is open source and actually you can go to Spacefiy.org and download the whole thing, and play with it. The whole point of it is actually that you don’t start from scratch. You play with something that exists.

I was a Finland Distinguish Professor for three years. I kept going back and forth to University of Helsinki and Aalto University. That’s a joint work with them. I should say they did actually most of the work more than the University of Florida.
But the idea is that in a space we need to have a cloud edge beneath architecture, or a cloud edge architecture. To allow that space to, sort of to monetize, to be a pleasant place, better experience for the user, and to monetize.
Again I like the Cloudlets is about, as you said the latency is about doing things such as you know video filtering, and video transformation. But before you go to the cloud it’s just one hub before. But our thing here we wanted to go further to bring in money to the space. We are so focused on monetization.
Specifically what we wanted…
>>: Kind of interesting you’re in academia and I’m in Microsoft and you’re focused on money.
[laughter]
I like that.
>> Sumi Helal: Well, we were trying to create things that…
>>: I’m joking, guessing.
>> Sumi Helal: Initially we wanted to patent all Spaceify. We racked out the patents. Then in November of last year I had a meeting in Helsinki and all stakeholders on the table decided this is the wrong way to go. We had only small application action Mobicom as a demo thing. We didn’t want to publish. But we decided patenting in the wrong way. It’s all open source that is a value for all the universities, for all stakeholders.
But the idea is this, a really simple idea. Now I’m going to spill it. The idea has a simple principle which is denial of ubiquity principle, denial of ubiquity principle. If you own a space, you own a garage; you own an entertainment like a restaurant, okay, or a mall, a small plaza. How are you monetizing on that space? You say, okay, I’m leasing. You are doing real estate leasing. You’re nine percent guy. That’s all you’re going to make, okay. Is that enough?
What you want to do is turn the space into a smart space. Use edge technology, edge cloud, and people have their client, okay. Now we need you to deny ubiquity of the whole thing, the whole web.
Whatever the web is come and stop right there. The space owner owns that space, doesn’t he or she?
She does.

Now for you to enter that space and not connect to the space network is almost dumb. Because you’ll miss out on so much stuff, you are forced to connect. Once you connect the whole web now has to obey your rules, okay. What comes in has to come in a particular form, Spacelets. Spacelets can enter the space. Spacelet means you play by the space rules.
When you enter the space, that spacelet’s not coming in to just display in an HTML five browser. The world doesn’t stop at HTML five. It doesn’t stop at tool browsing. You were right with stuff that will use a big screen that will use sensors, location, indoor location. The Microsoft is doing indoor location today or tomorrow alongside ISBN, ISP…
>> Victor Bahl: IPism.
>> Sumi Helal: IPism thank you. Now you have interesting sensors and devices, and big display, and multi-touch, multi-user. It’s an interesting world.
Okay, no problem. You want to enter here your rights were spacelets. You’re interacting, providing contents, everything. But now you pay me some money, okay. You monetize and you provide access.
They’re all measures for security and privacy, and everything. We wanted to create exactly that architecture to monetize smart spaces. That’s Spaceify.
As you see when we say cloud sensor system. It doesn’t stop at what I just showed you. It may mean this. It may mean actually other things. But somehow it will keep involving the clouds. That is actually the architecture. I don’t want to bug you because we don’t have too much time. But the result concept here is you have sensor in the space. You have user with all kind of devices and client. Our architecture is simply a Linux box with native support. We have the concept of an app store. An app owner, sorry a space owner can buy app to the space, that’s easy. Also dynamic content spacelet can come in anytime, all with agreement, and payments.
How many space owners are there in the world? Tons, so why don’t we create the opportunity for them? Get a cut out of it? Because we are the technology providers and that’s another way to make money. If you think there’s anything missed or lost. Nothing is missed. How much money Google makes out of a space right now? Nothing, maybe a little thing but nothing serious.
How much anybody is making out of any physical space? Nothing, so it’s not really about converting business or missing any business, it’s about creating business. This is certainly empowering and monetizing the space owner, and monetizing other technology provider as well, alright?
>>: I understand the desire for the space owner to try to monetize their space and their spectrum essentially, right. What about the other side of the marketplace, right? You have data that’s coming from the cloud that either will enter or not depending on whether they abide by the rules of the space, right. If I have a service that, where I want to play in that space, couldn’t I, do I, am I, how am I forced to

go through that essentially proxy, or through that filter, as opposed to going to their phone for example?
>> Sumi Helal: I mean, go through the phone that means you’re connecting to cellular.
>>: Yeah.
>> Sumi Helal: But once you get to a space there will be a lot of temptation a lot of pressure.
>>: You’re saying that, yeah that the service will feed from the space as much as the consumer will feed from the space?
>> Sumi Helal: Right.
>>: Okay.
>> Sumi Helal: The services come to, always to the edge, through the edge.
>>: Yeah.
>> Sumi Helal: If you don’t want to connect to the edge there’s no problem. But then you’d start missing out on many things and that for the persuasion and incentive play significantly here.
>>: Yeah you’re creating a marketplace.
>> Sumi Helal: You’re creating a marketplace, exactly, yes.
>>: Yep.
>> Sumi Helal: Yes, question?
>>: It seems to be the [indiscernible] in flights and some airlines. This frame might happen with a space of an airline, right.
>> Sumi Helal: Absolutely.
>>: [indiscernible]
>> Sumi Helal: Absolutely, very good.
>>: Yeah.

>>: Except it’s one sided though right?
>>: [inaudible].
>> Sumi Helal: Let me close here.
>>: It’s one sided.
>>: [inaudible]
>> Victor Bahl: He’s here to finish. That’s why you’re losing people.
>> Sumi Helal: Yes, let me…
>> Victor Bahl: It’s three o’clock. Lets…
>> Sumi Helal: Let me close here. Concluding remarks is that more focus is needed in high velocity data, not just big data. We need to look at high velocity. Let’s not run before we walk. We talk about mobile cloud. All research came out in mobile cloud. But what happened to the fixed mobile which is a sensor.
We didn’t, nobody told us is I think we should go back, talk about this, and make mobility to be the case on you know the extreme case or the next step case.
We need to do this. Let’s marry optimization with architecture because in everything we do now we have to have to have optimization gurus along with us. Let us search or build together massive city-scale datasets. We need to find that. I think Microsoft Research, Google Research, others. You are in more, in a better position to provide massive dataset to the research community that talk about smart city.
I’m looking for the day where these datasets will be available to us. That’s all I have here and thank you very much. I apologize for the lengthy talk.
[applause]
>> Victor Bahl: In interest of time it’s already three o’clock, thank you very much.
>> Sumi Helal: Thank you.
>> Victor Bahl: I guess if you want to ask questions they can. But I wouldn’t…
>> Sumi Helal: You can ask if they want already.
>> Victor Bahl: Thank you.

>> Sumi Helal: Thank you.