## 5 IoT Service Provisioning via NDN in the Smart Campus  
### Reference Scenario and Service Naming  
Our reference scenario is shown in Figure 2, which depicts four distinct 4-floor buildings composing a university campus. This is a smart environment where multiple NDN IoT devices are installed that sense and monitor the environment and produce a variety of data. They can range from simple environmental data, such as temperature, humidity, movements, and luminance values, to larger and complex information, such as video or audio files captured by cameras in specific areas of the buildings. Without loss of generality, in the following, we define as IoT service an operation that takes as input the raw data generated by the NDN IoT devices and processes them according to a certain computing function. The output of the computation is generally referred to as service _result_. It can be composed of a single data packet, e.g., a float value indicating the average temperature in a room or a boolean value indicating if there are movements in an area, or multiple data packets, e.g., a compressed video or a dataset indicating the average, maximum, and minimum humidity values in a room. Generally, there are no restrictions in the way a function must be implemented. According to the literature, functions are generic software programs that can be in the form of unikernel, as in Reference [8], or containers, as in Reference [42], or even \(\lambda\)-expressions. In the following, we assume that a function is a self-consistent code, identified by a unique name and with a well-defined list of optional input parameters, which can be specified by the consumer; otherwise, a default value will be used. For instance, a simple function computing the average over a set of float values is named _avgF_ and takes as input a number of \(s\) float samples over which the average is computed. If not specified, the default value \(s=2\) is considered. Instead, a function compressing flac audio files into mp3 files is named _flacToMp3_ and takes as input the kilobits per second value, which identifies the quality of the compression (128 kbps, 192 kbps, and 320 kbps). If not specified, the value 128 kbps is considered. The IoT service is uniquely named in a hierarchical structure with a name composed of three distinct parts: the content name, the function name, and the input parameters. While the first two components are mandatory, the last one is optional. The tag EXEC is used for separating the content and the function names. For instance, the name  
\[\text{campus/building1/floor4/classroomA/temp/EXEC/avgF/[s=5]}\]  
identifies a service that computes the average value over 5 temperature measurements collected from sensors installed in classroom A, located on the fourth floor of building 1 of the campus. Consumers, located in the campus as well request IoT services by sending interest packets that carry the service name. Of course, consumers can also request raw (non-processed) contents by  
Figure 2: Reference campus network topology. sending interests that carry only the traditional content name component, i.e., without the exec tag. To distinguish the two cases, in the following, we refer to as _service interest_ the packet requesting a named service. Vice versa, we call interest a standard NDN packet requesting a content. According to the standard ISO/IEC 11801 [48], a wired network is deployed in the campus that connects the IoT devices with a set of infrastructure elements acting as NDN content routers and fog nodes, which in the following is referred to as NDN-fog nodes. In addition to the traditional routing and forwarding operations, they are provided with storage and processing capabilities to dynamically offer IoT services. Of course, their resources are limited with respect to the cloud. As shown in Figure 2, the network resembles a fat tree topology, with 4 layers and 69 nodes. The root node connects the edge domain to the core network, which in turn is connected to a remote cloud facility.