# Feasibility Assessment of a Fine-Grained Access Control Model on Resource Constrained Sensors
## 3 Access Control Model
### Authorization Policy Language and Codification
#### 3.2.2 Measurable Policy Instance Examples
## 4 Performance Evaluation Model

The performance analysis of the access control model that leads to the final feasibility assessment shall be conducted in three ways: analytical evaluation, generic or specific network simulation and prototype implementation. An analytical performance evaluation, which covers the computation of the crucial theoretical performance parameters referring to a concrete scenario and under a set of assumptions is conveyed in [7]. There are basically four criteria considered for the three remaining methods. The first and most relevant criterion is the veracity of the resulting data. The other three criteria are the agility of the software development, the scalability of the deployment and the reuse of the software. Therefore, a real test-bed will be implemented using sensor nodes and hardware hosts. Even if it requires a larger effort and lacks broad testing scalability, the resulting testing results are more valuable and conclusive for the final feasibility assessment. ### Hidra Test-Bed Implementation

The Hidra test-bed implementation is described in the following, which also presents the reference scenario conveying the platform selection as well as the implementation through the software codification and configurations. #### 4.1.1 Hidra Test-Bed Scenario

The test scenario for the experimental performance evaluation is graphically depicted in Figure 5. In this scenario, a subject is connected to the Internet and establishes an E2E connection with a resource running as a tiny server on a CDS in an IEEE 802.15.4 network in the 2.4 GHz band. A 6 LoWPAN router (in orange) acts as the LowPAN coordinator and connects a beacon-enabled lineal structure to the Internet. The IEEE 802.15.4 network is 2-hops deep, which is considered significantly large for validation purposes. The PAN router coordinator has a child coordinator, which controls one leaf node. In this node, the CDS exposes resources as management services. Both the coordinator router and the sensor node are class C0 and C1 CDSs [1], and thus, proper operating systems and hardware platforms shall be selected for this purpose. Neither traditional general-purpose operating systems nor real-time operating systems are suitable for typical applications on CDSs. Therefore, the selected platform focuses on operating systems specifically designed for CDSs, aiming at higher efficiency, flexibility, portability and lightness as well as smaller footprints. The operating system should be easily programmable and configurable, and it should be based on low complexity operations because of the low cycle speeds of the micro-controllers (MCU) of the CDSs. Therefore, the key features are the kernel architecture (monolithic, layered or multi-layered), the programming model (in terms of parallelism, memory hierarchy and concurrency), the scheduling strategy (real time and multitasking support), networking (light-weight communication protocol support), memory management (static versus dynamic) and portability to different hardware platforms. All these features significantly impact the performance, programmability as well as the manageability; for various use cases, many operating systems are being proposed and implemented in several IoT platforms. Figure 5: Performance evaluation scenario. Hidra protocol implementation conveying the hardware, operating system, network stack and Hidra software modules. From the research point of view, considering the openness, maturity and the adoption by the community as well as the technical features described in [31], three operating system have been examined: TinyOS, Contiki OS and Riot OS, as summarized in Table 5. The technical features of Riot OS are the most complete and promising, but according to a broad IoT developer survey of 2017 [32], current adoption and research community support are higher for Contiki OS, and therefore, Contiki OS is the selected platform. Contiki OS [33] is an open-source operating system for sensor nodes.