Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29182-6 — Sensor Networks: SNRA — Part 6: Applications
Application-driven sensor network design patterns and domain-specific guidance
Sensor Network Applications and the SNRA
ISO/IEC 29182-6 focuses on the application layer of the Sensor Network Reference Architecture, providing guidance on how sensor network capabilities are exposed to and consumed by applications. Unlike traditional communication networks where the application is a separate concern, sensor networks are inherently application-driven — the network’s purpose, topology, and operational parameters are strongly influenced by the application domain. Part 6 provides a framework for mapping domain requirements to SNRA capabilities.
When developing a sensor network application, start with Part 6’s application mapping framework rather than jumping directly to protocol selection. This top-down approach ensures that the application’s quality-of-service requirements, data models, and interaction patterns drive the architecture rather than being constrained by it.
The standard identifies several application domains that benefit from the SNRA: environmental monitoring, industrial automation, smart agriculture, healthcare, smart buildings, transportation, and defence. For each domain, Part 6 provides guidance on typical deployment patterns, data characteristics, and quality-of-service requirements. This domain-specific guidance helps architects select the appropriate configurations from the generic SNRA framework.
Application Interaction Patterns
Part 6 defines three fundamental interaction patterns between applications and sensor networks. The “Pull Pattern” involves the application querying the sensor network for specific data, suitable for on-demand monitoring. The “Push Pattern” involves the sensor network proactively sending data to the application, appropriate for continuous monitoring and event detection. The “Hybrid Pattern” combines both, with scheduled push for routine data and on-demand pull for detailed investigations.
| Interaction Pattern | Data Flow | Latency Requirement | Typical Applications |
|---|---|---|---|
| Pull (Polling) | Application → Network → Application | Seconds to minutes | Historical data analysis, compliance reporting, manual inspection |
| Push (Event-Driven) | Network → Application | Milliseconds to seconds | Alarm detection, real-time monitoring, threshold alerts |
| Hybrid (Scheduled + On-Demand) | Bidirectional | Variable | Predictive maintenance, smart agriculture, building management |
| Streaming (Continuous) | Network → Application | Sub-milliseconds to milliseconds | Industrial process control, audio/video monitoring, vibration analysis |
Mismatch between the interaction pattern and the actual application requirements is a common architectural mistake. Using a pull pattern for time-critical alarm detection introduces polling interval latency that may delay emergency response. Always choose the interaction pattern based on the most stringent application requirement.
Domain-Specific Application Guidance
For environmental monitoring, the standard recommends low-power wide-area network (LPWAN) technologies combined with a push pattern for periodic data upload and a pull pattern for configuration changes. Smart agriculture applications benefit from the hybrid pattern, with soil moisture sensors pushing data every hour and the application pulling high-resolution weather forecasts on demand. Industrial automation demands the streaming pattern with strict real-time guarantees, often implemented over Time-Sensitive Networking (TSN) or industrial Ethernet.
A particularly insightful example from Part 6 is the integration of heterogeneous sensors in precision agriculture. The same SNRA architecture simultaneously supports low-rate soil sensors (every 30 minutes), medium-rate weather stations (every 5 minutes), and high-rate drone imagery (on-demand flights). The layered architecture allows these diverse data sources to coexist without interference.
The standard also covers application-level security, privacy, and data sovereignty. Healthcare applications must comply with patient data protection regulations, requiring fine-grained access control and audit trails. Smart building applications may need to separate public data (temperature, humidity) from private data (occupancy patterns, personal preferences). Part 6 provides a data classification framework that maps application data types to security and privacy controls.
Data sovereignty is an increasingly critical concern. When deploying cross-border sensor network applications, architects must consider where data is stored, processed, and analysed. Part 6 warns against assuming that cloud-based processing is always acceptable — some jurisdictions require data to remain within national borders, necessitating local processing or edge computing architectures.
Frequently Asked Questions
Q: Can the SNRA support real-time video streaming applications?
A: Yes, but with caveats. The SNRA architecture can support video streaming, but the high bandwidth and low latency requirements may necessitate specialised communication views and careful resource planning. The standard recommends separate planning for streaming and non-streaming applications within the same network.
A: Yes, but with caveats. The SNRA architecture can support video streaming, but the high bandwidth and low latency requirements may necessitate specialised communication views and careful resource planning. The standard recommends separate planning for streaming and non-streaming applications within the same network.
Q: How does Part 6 address application scalability?
A: Part 6 defines scalability in terms of three dimensions: number of sensor nodes, data volume, and application complexity. It recommends a tiered architecture where edge nodes handle local processing, gateways aggregate and filter, and cloud platforms provide long-term storage and analytics.
A: Part 6 defines scalability in terms of three dimensions: number of sensor nodes, data volume, and application complexity. It recommends a tiered architecture where edge nodes handle local processing, gateways aggregate and filter, and cloud platforms provide long-term storage and analytics.
Q: Is the SNRA suitable for consumer IoT applications?
A: While the SNRA is designed primarily for professional and industrial applications, many of its concepts — particularly the interaction patterns and entity models — are applicable to consumer IoT. However, the standard’s formality may be excessive for simple consumer use cases.
A: While the SNRA is designed primarily for professional and industrial applications, many of its concepts — particularly the interaction patterns and entity models — are applicable to consumer IoT. However, the standard’s formality may be excessive for simple consumer use cases.
Q: Does Part 6 prescribe specific application protocols?
A: No. Part 6 provides requirements and guidance but does not mandate specific protocols. It does, however, provide compatibility matrices mapping common application protocols (MQTT, CoAP, HTTP, OPC UA) to different interaction patterns and application domains.
A: No. Part 6 provides requirements and guidance but does not mandate specific protocols. It does, however, provide compatibility matrices mapping common application protocols (MQTT, CoAP, HTTP, OPC UA) to different interaction patterns and application domains.
