CLOUD COVER

Indie Fog: An Efficient Fog-Computing

Infrastructure for the However, fog computing faces its own challenges, such as equipment that works only with the service pro- viders’ technologies or only with cel- Internet of Things lular networks. In response, we have proposed Chii Chang and Satish Narayana Srirama, University of Tartu the Fog infrastructure, which utilizes consumers’ networking de- Rajkumar Buyya, University of Melbourne and Manjrasoft Pty Ltd. vices—such as their Wi-Fi access- point routers—to provide IoT service Fog computing can help with some of providers with a fog-computing en- vironment. This reduces the need the Internet of Things’ limitations but also for IoT service providers to deploy their own devices throughout a fog faces challenges of its own. The Indie Fog system. infrastructure could be a flexible, cost-effective Indie Fog would be flexible and cost-effective, support the IoT, and way to cope with these challenges. work with today’s technologies. THE IoT’S LATENCY he Internet of Things (IoT) has created many CHALLENGE technical and business opportunities but also The IoT represents the Internet’s next stage, in which has its limitations. For example, the traditional common objects such as vehicles, home appliances, office cloud-based IoT can experience more latency equipment, manufacturing facilities, and consumer elec- Tthan many target applications can tolerate. tronic devices connect to the Internet.1 This facilitates im- Fog computing, which moves computation and net- portant new -based services such as smart cities, working closer to the network edge, reduces the need to smart factories, smart agriculture, and ambient assisted communicate via the cloud and thus decreases latency. living (AAL).

92 COMPUTER PUBLISHED BY THE IEEE COMPUTER SOCIETY 0018-9162/17/$33.00 © 2017 IEEE EDITOR SAN MURUGESAN BRITE Professional Services; [email protected]

Central management server

Central management server Deploy

Deploy Data source Fog application package Data source

Fog application Indie Fog package Indie Fog Gateway (a) Application (b)

Figure 1. Two types of Indie Fog deployments. (a) In the integrated form, the functionality is provided by a gateway device integrated into the Indie Fog server, which connects to data sources and user devices. (b) In the collaborative form, the functionality is provided by a workstation in the same subnet as the data-source devices, to which it connects via an Internet gateway.

In the IoT’s , a cloud- home Internet router the provider various distributed computing tasks. based central server manages all ac- sends to the customer. This is different And Fon (fon.com) utilizes CPEs to es- tivities of IoT devices residing at the from public-cloud systems, in which tablish a global Wi-Fi network. These network edge. This cloud-centric IoT third-party infrastructure companies examples confirm that many consum- (CIoT) requires these devices to send offer generic platforms that work with ers are willing to let providers pay to use their data to the central server and wait multiple service providers. their equipment for offering services. for its response, thereby creating la- Recently, the European Telecom- We envision the CaP model ex- tency. Many emerging, data-intensive munications Standards Institute (ETSI) tending to fog computing, and we IoT-driven applications, such as AAL introduced the Mobile Edge Computing use this approach in Indie Fog. Indi- and smart-traffic services, can’t toler- (MEC) architecture,3 which lets CIoT viduals, not just organizations, could ate latency. Researchers have thus de- providers utilize cellular base stations’ configure their devices to provide veloped fog computing.2 virtual machine (VM)-enabled servers public fog services. The independent to perform distributed computational nature of such a deployment inspired FOG COMPUTING’S or networking processes at the cellular- us to use the name Indie Fog, much CHALLENGES network edge. However, because MEC as the term is used in areas such as By operating at the network edge, fog works only with cellular networks, its , indie music, indie , computing brings computation and usefulness is limited. and indie games.5 networking closer to users and data To address these limitations, we sources. This reduces latency and in- propose Indie Fog. INDIE FOG’S ROLE creases computational and communi- In general, Indie Fog services come cation efficiency. CONSUMER AS PROVIDER in two forms: integrated and collabo- Typically, network-infrastructure The popular Consumer as Provider rative (see Figure 1). In the integrated providers, ISPs, or cloud-service pro- (CaP) service-provision model4 has version, the Internet router itself viders offer fog services via customer- triggered a new form of service provi- provides the virtual server that acts premises equipment (CPE) designed sion in multiple domains. For example, as the fog node. In the collaborative specifically for the providers’ applica- the MQL5 Cloud Network distributed- version, a computer connected to the tions. For example, an ISP might en- computing project (cloud.mql5.com) Internet router provides the fog node. able fog services from the proprietary uses consumers’ equipment to perform Both Indie Fog types operate at the

SEPTEMBER 2017 93 CLOUD COVER

Cloud

Core network (regional)

Access/edge network (neighborhood) Private fog Public fog

Gateway/CPE Indie Fog Indie Fog (building/street) Private fog

Indie Fog

End points Private fog

Physical connection Virtual connection

Figure 2. Customer-premises equipment (CPE), computers embedded in vehicles, or mobile devices with Internet connections can host an Indie Fog system. Because the technology is software defined, Indie Fog nodes provide virtual connectivity across different layers of the cloud-centric Internet of Things (IoT) architecture.

fog computing architecture’s gateway devices that have OSs and Internet con- either hypervisor-oriented VM layer. nectivity—including consumer elec- technologies or containeriza- According to the OpenFog Consor- tronics, appliances, smartphones, and tion technologies. A trusted tium,2 the fog-computing architec- computers embedded in vehicles—at cloud-based coordinator ture has multiple layers (see Figure the gateway layer. service manages the registered 2). In general, the fog server can be Indie Fog has the following nodes. hosted in devices at the access layer characteristics: (such as a citywide Internet gateway), ›› Interoperability. Indie fog nodes INDIE FOG DEPLOYMENT at the gateway layer (such as within can interact with other fog nodes There are four basic Indie Fog deploy- a building or in the street), or within to create a software-defined ment models. various objects (such as vehicles, lap- network. tops, or smartphones) that serve as IoT ›› Scalability. A CIoT system can Clustered Indie Fog end points. form a scalable, software-defined When a group of stationary Indie Fog Commonly, service providers fol- cluster of Indie Fog nodes. Both nodes are in close proximity, such as low the private fog model, in which public and private fog systems within an ISP’s subnet or in the same they configure a fog server within a can use Indie Fog to extend their building, they are ideal for establish- device for use only by specified parties. networks. ing a software-defined grid-comput- In the public fog model, like that used ›› Cost efficiency. Because Indie Fog ing cluster (see Figure 3a). Such a clus- in the MEC architecture, providers uses customer equipment, it’s ter can perform, in the edge network, make fog services available via generic less expensive, particularly for high-performance preprocessing of platforms to any paying customer with large deployments. data collected by sensors and other the proper equipment. ›› Security. Indie Fog nodes provide sources. This reduces the bandwidth Figure 2 shows how Indie Fog serv- a sandbox-based software- needed to send the data to the cloud ers can be in various consumer-based deployment environment using and the cost of processing it.

94 COMPUTER WWW.COMPUTER.ORG/COMPUTER Cloud management server Cloud management server Cloud management server Cloud management server Deploy Deploy Deploy Deploy Deploy script source code Deploy Deploy Deploy Deploy Deploy

Indie Fog Indie Fog Indie Fog Indie Fog Indie Fog Indie Fog Indie Fog Indie Fog Indie Fog Indie Fog Indie Fog Sense Sense

Data source Data source Data source Physical world (a) (b) (c) (d)

Figure 3. Indie Fog facilitates the deployment of four types of software-defined cloud-centric IoT systems: (a) clustered Indie Fog, (b) infrastructural Indie Fog, (c) vehicular Indie Fog, and (d) smartphone Indie Fog.

Infrastructural Indie Fog dynamic, random connections. How- analyze data for context brokering, Indie Fog deployed in stationary sen- ever, mobile-device-based server which is the collection and analysis of sor devices, such as cameras, in an nodes could still be useful in urban data to provide context for subsequent urban outdoor area could provide an sensing. Smartphones could collect decision making. infrastructure for ubiquitous appli- many kinds of sensory data. If smart- cations that require temporary data phone users install Indie Fog servers Software-defined IoT orchestration. acquisition and processing in a short on their devices, the phones could Deploying a distributed IoT-driven period of time (see Figure 3b). For ex- provide and even preprocess their col- Business Process Management System ample, scientists could pay to use indi- lected data as a service.8 (BPMS)9 across a group of Indie Fog viduals’ or businesses’ Indie Fog serv- nodes could provide a composite IoT ers with pre-installed sensor functions Use cases service for interacting with wireless to collect and interpret urban data, There are several promising Indie Fog sensors, actuators, and readers with such as a neighborhood’s population use cases. minimal low- programming re- density, for research. quired. In addition, if the IoT service Ubiquitous care. Indie Fog nodes could uses semantic process execution, the Vehicular Indie Fog communicate with standards-based BPMS could dynamically and autono- Indie Fog is not limited to stationary smart devices in public urban areas to mously configure the deployment and nodes. In urban areas, vehicles could help, for example healthcare or elder- execution node to adapt to environ- also host nodes. This would facilitate care services track their patients in mental changes, such as the failure of the Internet of Vehicles,6 in which real time. a fog server. the CIoT system could dynamically deploy a software-defined vehicular Software-defined systems. By work- Commercial service. An Indie Fog fog7 for extending the urban-sensing ing with multiple Indie Fog nodes, the node in a bus, for example, could allow data-acquisition network, which col- CIoT could configure software-defined an advertiser to dynamically change lects traffic, metropolitan transit, networks. Similarly, by deploying the content, application, or advertis- and other information of interest to grid computing across multiple Indie ing it provides on seat-back monitors the public (see Figure 3c). Unlike sta- Fog nodes, the CIoT could configure a that passengers can view. For example, tionary nodes, vehicular nodes could software-defined cluster-computing a seat-back camera and application collect and process data on the move, infrastructure. could identify when a new passenger thereby enabling sequential data is in front of the monitor; analyze the streams and information on chang- Big data acquisition. Worldwide person’s age, gender, and other charac- ing environments. Indie Fog deployment could enable teristics; and try to provide appropriate CIoT systems to stream large vol- content, application, or advertising. Smartphone Indie Fog umes of raw sensory data for contin- Smart mobile devices might not be uous analysis. INDIE FOG ARCHITECTURE able to form a stable cluster-computing Users can implement Indie Fog via a environment because smartphone Context brokering. Indie Fog could service-oriented architecture (SOA), users move regularly and thus have be used to collect, preprocess, and as Figure 4 shows. In general, SOAs

SEPTEMBER 2017 95 CLOUD COVER

Indie Fog client Indie Fog registry Indie Fog server

Provisioning Wireless server Security Security sensors, actuators, OpenSSH OpenSSH and

Indie Fog agent Indie Fog agent readers AuthZ Federated AuthZ management End-user Message-level Message-level app security security

Physical world

Service Service description discovery (Open Data Protocol)

Federated repository

HTTP Representational State Transfer

Figure 4. A service-oriented Indie Fog system consists of three core elements: the Indie Fog client; the Indie Fog server; and the Indie Fog registry, formed by federated management servers and federated service-description repository servers.

involve three core entities: the service network, sensor, and other compo- publish-subscribe service-provisioning registry, the service provider, and the nents from the provider. However, the mechanisms. service consumer. Based on the World provider can’t observe consumer activ- Virtualization or containerization— Wide Web Consortium’s Web service ar- ities, which protects privacy. via, for example, OpenStack++ (elijah chitecture (www.w3.org/TR/ws-arch), Figure 5 illustrates a reference In- .cs.cmu.edu/development.html), both provider and consumer must host die Fog architecture with several core Linux Containers (linuxcontainers an agent to support communication elements. .org), Docker (www.docker.com), with other entities. To provide secure services, each and Open Container Initiative (www The registry, generally federated Indie Fog server must host an agent .opencontainers.org) technology— in nature, encompasses the reposi- that manages service publication and enables the runtime environment. tory of published services and han- secure access control, and that handles This lets Indie Fog clients deploy and dles identity and security manage- the deployment of consumer applica- operate their applications in the serv- ment. After using the registry, the tions in the virtualization or contain- er’s sandbox environment. provider and consumer interact on a erization environment. The agent also peer-to-peer basis. handles hardware-access permissions. CHALLENGES AND FUTURE Indie Fog service providers can gen- Middleware and adaptors take DIRECTIONS erally publish their service descriptions care of the interaction between the Indie Fog faces fog computing’s funda- to the repository in a standard format consumer-deployed application and the mental challenges,10 such as dynamic such as that called for by the Open Indie Fog host’s hardware components. process assignment among cloud- or Data Protocol (www.oasis-open.org The Indie Fog server describes its edge-based resources, mobility aware- /committees/odata). Consumers could hardware specification and location in ness, fault tolerance, and security. then select their ideal providers based a standard-format service-description on the providers’ location, as well as their document. The Indie Fog agent man- Standardization server and networking capabilities. ages the document’s publishing and Indie Fog servers must provide stan- The system’s sandbox-based secu- updating. dard deployment environments with- rity management provides the trust The agent uses its host interface out requiring users to install a specific that encourages consumers to access to communicate with other Indie API on clients for each server. How- the software-deployment environ- Fog agents. The host interface sup- ever, finding a common deployment- ment, as well as the permitted storage, ports both the request-response and platform standard is a challenge, as

96 COMPUTER WWW.COMPUTER.ORG/COMPUTER the OpenFog Consortium hasn’t re- Indie Fog registry Indie Fog leased a fog-deployment standard. agent A possible approach is extending (client) existing service-oriented architec- ture and web-service standards— such as OData (Open Data Protocol) or MQTT (Message Queue Telemetry Host interface

Transport)—to develop an Indie Fog App App App App specification. Service management

Middleware and adaptors

Adaptive service discovery Indie Fog agent Virtualization/ Indie Fog relies on a global federated reg- Secure access control containerization istry. The registry helps clients discover the best Indie Fog servers for their ap- Host OS plications, which involves both context Hardware components awareness and semantic descriptions Indie Fog host of servers in terms of both spatiotem- poral context and resource availability. It’s unlikely that a single regis- Figure 5. The Indie Fog server agent’s software handles communications with external try could satisfy the entire Indie Fog entities. The virtualization or containerization environment lets Indie Fog clients deploy ecology—particularly for organiza- and run their customized applications in the system’s secure sandbox environment. tions with far-flung facilities—because of the need for Indie Fog nodes to be close to one another to minimize la- MEC telecommunications-industry Elements, and Future Directions,” tency. Perhaps in the future, there will standard. For example, some users Future Generation Computer Systems, be a federated registry, but this would might have mobile devices that don’t vol. 29, no. 7, 2013, pp. 1645–1660. increase service-discovery complexity. have strong wireless signals. Also, be- 2. “OpenFog Reference Architecture for Another service-discovery chal- cause Indie Fog uses consumer-based Fog Computing,” OpenFog Consortium, lenge is that Indie Fog servers might equipment, location would affect its Feb. 2017; www.openfogconsortium not use the same semantics as tradi- availability. For instance, the ser- .org/wp-content/uploads/OpenFog tional webservers. vice might be less available in low- _Reference_Architecture_2_09_17 population suburbs or rural areas be- -FINAL.pdf Quality of service cause their CPE density is much lower 3. Mobile-Edge Computing–Introductory Indie Fog quality of service (QoS) faces than in urban areas. Because MEC, on Technical White Paper, white paper, three challenges: quality of connectiv- the other hand, is provided by equip- Mobile-Edge Computing (MEC) in- ity, quality of performance, and qual- ment located in cellular base stations, dustry initiative, Sept. 2014; portal ity of content or data delivery. it could support national or global .etsi.org/portals/0/tbpages/mec For example, Indie Fog providers availability. /docs/mobile-edge_computing might use heterogeneous servers with _-_introductory_technical_white different computational and network- _paper_v1%2018-09-14.pdf. ing capabilities. Ensuring these serv- ndie Fog could help CIoT providers 4. R. Sofia and P. Mendes, “User- ers’ QoS could thus be challenging. reduce fog-deployment costs by us- Provided Networks: Consumer as The management system might need Iing customer equipment and the CaP Provider,” IEEE Communications to provide trust and recommendation model to enable a flexible, software- Magazine, vol. 46, no. 12, 2008, pp. schemes to assist both clients and defined infrastructure. The approach 86–91. servers. could thus be a promising solution for 5. M.Z. Newman, “Indie Culture: In The quality of the data that the In- many CIoT service providers. It could Pursuit of the Authentic Autono- die Fog node delivers during informa- also make fog computing more popu- mous Alternative,” Cinema J., vol. 48, tion acquisition or context brokering lar and provide business opportunities no. 3, 2009, pp. 16–34. also affects QoS. for CPE owners. 6. M. Gerla et al., “Internet of Vehicles: From Intelligent Grid to Autonomous Availability REFERENCES Cars and Vehicular Clouds,” Proc. Indie Fog might not provide as much 1. J. Gubbi et al., “Internet of Things IEEE World Forum on Internet of Things availability as that called for by the (IoT): A Vision, Architectural (WF-IoT), 2014, pp. 241–246.

SEPTEMBER 2017 97 CLOUD COVER

7. X. Hou et al., “Vehicular Fog Com- puting: A Viewpoint of Vehicles as CHII CHANG is a research fellow the Infrastructures,” IEEE Trans. in the Mobile & Cloud Computing Vehicular Technology, vol. 65, no. 6, Laboratory at the University of 2016, pp. 3860–3873. Tartu’s Institute of Computer Science. 8. M. Liyanage, C. Chang, and S.N. Sri- Contact him at [email protected]. rama, “mePaaS: Mobile-Embedded WWW.COMPUTER.ORG Platform as a Service for Distributing SATISH NARAYANA SRIRAMA is an Fog Computing to Edge Nodes,” Proc. /COMPUTER associate professor at the University 17th Int’l Conf. Parallel and Distributed of Tartu and head of the Mobile & Computing, Applications, and Technolo- Cloud Computing Laboratory at gies (PDCAT 16), 2016, pp. 73–80. the school’s Institute of Computer 9. C. Chang, S.N. Srirama, and R. Science. Contact him at srirama@ Buyya, “Mobile Cloud Business ut.ee. Process Management System for the Internet of Things: A Survey,” ACM RAJKUMAR BUYYA is director of Computing Surveys, vol. 49, no. 4, the University of Melbourne’s Cloud 2017; doi:10.1145/3012000. Computing and Distributed Systems 10. A.V. Dastjerdi and R. Buyya, “Fog Read your subscriptions Laboratory and CEO of Manjrasoft Computing: Helping the Internet of through the myCS Pty Ltd. Contact him at rbuyya@ publications portal at Things Realize Its Potential,” Com- unimelb.edu.au. http://mycs.computer.org puter, vol. 49, no. 8, 2016, pp. 112–116.

IEEE TRANSACTIONS ON AFFECTIVE COMPUTING A publication of the IEEE Computer Society

Affective computing is the eld of study concerned with understanding, recognizing, and utilizing human emotions in the design of computational systems. IEEE Transactions on Affective Computing (TAC) is intended to be a cross-disciplinary and international archive journal aimed at disseminating results of research on the design of systems that can recognize, interpret, and simulate human emotions and related affective phenomena.

Subscribe today or submit your manuscript at: www.computer.org/tac

98 COMPUTER WWW.COMPUTER.ORG/COMPUTER