Smart city projects require data to be transferred from one destination to the next using a number of different network protocols. The data pipelines involved in these smart city projects often have limited bandwidth or compute resources due to the low power nature of most embedded hardware. The data transferred between devices in these types of embedded systems are often structured in non-standard data schemata. Remote procedure calls (RPC) are implemented to transfer data between devices and switching between RPC implementations can be tricky due to the lack of standardization. There is no guarantee that an existing data schema will work with a different RPC implementation. This makes it difficult for a researcher or system developer to benchmark and compare different RPC im-plementations. In this paper, a conceptual infrastructure named SpeciServe is introduced where gRPC is used as a communication backbone due its support for flatbuffers and multiple server modes. Multiple software services are described to allow for dissimilar RPC implementations to be run in parallel. This system is intended to allow for researchers in machine learning, smart cities, and Internet of Things (loT) to be able test different versions of RPCs and provide support for system developers to define the functions of an edge service.

Point cloud data in the form of LiDAR is often utilized for its spatial qualities, especially in smart city projects for tasks involving vehicles and pedestrians. However, the process in which LiDAR data is acquired can be cumbersome to setup and automate. In this paper, we introduce a streaming and an on-demand pipeline for capturing LiDAR data from Velodyne Ultra Pucks placed along northern Nevada intersections known as the Living Lab as part of a smart city project for the city of Reno. The data coming from these intersections consist of the following formats: ROS 2 bag file, PCD, LAZ, Google Draco, and PCAP. A streaming point cloud service with PCD, LAZ, and Draco was implemented to stream any of these formats, as well as to allow the user to capture the current monitored point cloud. Additionally, two on-demand web services were implemented for both the PCAP and ROS 2 bag file to enable a user to start and stop the acquisition of LiDAR data in these formats. Through our analysis, it was discovered that Draco provided the best processing time and had a wider range of options that affected the quality of the point cloud. To evaluate this pipeline, the features of existing software were compared and a discussion was provided with an analysis of the point cloud formats.

In many smart city projects, a common choice to capture spatial information is the inclusion of LiDAR data, but this decision will often invoke severe growing pains within the existing infrastructure. In this paper, we introduce a data pipeline that orchestrates Apache NiFi (NiFi), Apache MiNiFi (MiNiFi), and several other tools as an automated solution in order to relay and archive LiDAR data captured by deployed edge devices. The LiDAR sensors utilized within this workflow are Velodyne Ultra Pucks sensors that capture at a rate of 10 frames per second and produces 6-7 GB packet capture (PCAP) files per hour. By both compressing the file after capturing it and compressing the file in real-time, we discovered that gzip produced a file of 5 GB and saved about 5 minutes in transmission time to NiFi, as well as saving considerable CPU time when compressing the file in real-time. Alternatively, we chose XZ as the compression algorithm for the ingestion of LiDAR data onto an institution compute cluster due to its high compression ratio. In order to evaluate the capabilities of our system design, the features of this data pipeline were compared against existing third-party services, namely Globus and RSync.