Get documents about "Technical ument ISO IEC JTC Study Group on Sensor Networks
Document Sample
ISO/IEC JTC 1
Technical Document of ISO/IEC JTC 1
Study Group on Sensor Networks (SGSN)
Study on Sensor Networks (Version 3)
This Technical Document (TD), entitled “Study on Sensor Networks (Version 3),” results from
SGSN’s activities in 2008 and 2009. The history of the SGSN TD is:
Version 1 (dated 10 October 2008) – Resulted from the 1 st SGSN meeting (Shanghai,
China, 26-27 June 2008) and also from the 2 nd SGSN meeting (Nürnberg, Germany,
15-19 September 2008)
Version 2 (dated 9 March 2009) – Resulted from the 3 rd SGSN meeting (Sidney,
Australia, 19-23 January 2009)
Version 3 (dated 24 August 2009) - Adds the contents of contributions and discussions
in the 4 th SGSN meeting (Oslo, Norway, 29 June – 3 July 2009). Version 3 TD is the
final TD of the SGSN activity
The role of SGSN is focused on fulfilling the Terms of Reference (ToR) from ISO/IEC JTC 1,
which is the study of Sensor Networks (SN); its role is not on the development of SN
standards. This TD includes the survey of generic SN technologies and functions, general
requirements, reference architecture and models, applications/services examples, and other
SN related areas.
SGSN recognizes that there are existing standards developed by international standards
developing organizations (SDOs) outside JTC 1, e.g., ISO, IEC, ITU-T, which are and/or can
be applicable to Sensor Networks. This TD attempts to recognize those relevant SDOs by
listing them and their standards in Annex D; however, SGSN acknowledges Annex D is not
exhaustive and complete. Many of the entries in Annex D are based on the contributions from
the SDOs.
Sensor Networks is a technology that has very broad in its applications and services covering
a wide range of technological domains, market spaces, and every day human lives. As the
new devices, subsystems, and systems appear in market places, new applications are
developed, and new technologies emerge, the sensor networks’ roles will evolve which may
require updating the existing standards and developing new standards.
SGSN sincerely expresses its appreciation to those who supported and contributed to the
study by attending the face-to-face meetings, via electronic means, and through other means
of communications.
03 September 2009
Source: ISO/IEC JTC 1 SGSN
Technical Document of -i-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Table of Contents
Table of Contents .................................................................................................................ii
Table of Figures................................................................................................................... ix
List of Tables ....................................................................................................................... xi
List of Acronyms ................................................................................................................ xiii
1 Purpose of this Document .............................................................................................. 1
2 Description of Sensor Networks ..................................................................................... 4
2.1 Vision Statement of Sensor Networks .................................................................... 4
2.2 Mission Statement of Sensor Networks Standardization ......................................... 4
2.3 Definitions of key Sensor Network Terminology ..................................................... 4
2.3.1 Definitions of Sensor, Actuator, Sensor Node, and Sensor Network
Gateway ................................................................................................... 4
2.3.1.1 Definition of Sensor .................................................................... 4
2.3.1.2 Definition of Actuator .................................................................. 4
2.3.1.3 Definition of Sensor Node ........................................................... 4
2.3.1.4 Definition of Sensor Network Gateway ......................................... 5
2.3.2 Definition of Sensor Networks ................................................................... 5
2.3.3 Definition of Sensor Network Services ....................................................... 5
2.3.4 Definition of User Services ........................................................................ 5
2.3.5 Definition of Sensor Network Applications .................................................. 5
3 Scope of Standardization on Sensor Networks in JTC 1 .................................................. 6
3.1 The Scope ............................................................................................................ 6
3.2 The Four Interfaces of Sensor Networks ................................................................ 7
4 Sensor Network’s Market Segments and Applications ....................................................10
4.1 Generalized Sensor Network Development and Evolution Stages for Target
Applications .........................................................................................................12
5 Characteristics and Requirements of Sensor Networks ..................................................15
5.1 Characteristics of Sensor Networks ......................................................................15
5.2 Generic and Generalized Requirements of Sensor Networks .................................19
5.2.1 Generic and Generalized System Requirements (GSR) .............................19
5.2.1.1 Communication ..........................................................................19
5.2.1.2 Security and Privacy ..................................................................19
5.2.1.3 Robustness ...............................................................................21
5.2.1.4 Scalability ..................................................................................21
5.2.1.5 Quality of Service (QoS) ............................................................21
5.2.1.6 Heterogeneity ............................................................................21
5.2.1.7 Deployment & Coverage ............................................................21
5.2.1.8 Mobility ......................................................................................21
5.2.1.9 Power/Energy Management .......................................................21
5.2.2 Generic and Generalized Functional Capability Requirements (FCR) .........22
5.2.2.1 Long Range Communication Service ..........................................22
5.2.2.2 Short Range Communication Service .........................................22
5.2.2.3 Clustering Services ....................................................................22
5.2.2.4 Routing Service .........................................................................22
Technical Document of - ii -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
5.2.2.5 Installation Service ....................................................................23
5.2.2.6 Security and Privacy Services ....................................................23
5.2.2.7 Data Storage Services ...............................................................23
5.2.2.8 Collaborative Processing Services .............................................23
5.2.2.9 Control Services ........................................................................23
5.2.2.10 Linkage Services .......................................................................24
5.2.2.11 Orientation Detection Services ...................................................24
5.2.2.12 Self-Localization Service ............................................................24
5.2.2.13 Monitoring Service for Communication Links ...............................24
5.2.2.14 General Sensing Service ............................................................25
5.2.2.15 Time Synchronization Service ....................................................25
5.2.2.16 Identification Service ..................................................................25
5.2.2.17 Data Entry Services ...................................................................25
5.2.2.18 Indication Services .....................................................................25
5.2.2.19 Display Services ........................................................................26
5.2.2.20 Sensor Interface ........................................................................26
5.2.2.21 High Data Rate Communication Service .....................................26
5.2.2.22 Low Data Rate Communication Service ......................................26
6 Sensor Network Reference Architecture (SNRA) ...........................................................27
6.1 Introduction .........................................................................................................27
6.2 Sensor Network Reference Architecture Element/Model/Case Description .............29
6.2.1 Sensor Network Reference Architecture Views and Artefacts ....................35
6.2.2 Sensor Network Device – A Sensor Node or Sensor Network
Gateway ..................................................................................................38
6.2.2.1 Description of Sensor Network Device ........................................39
6.2.2.2 Basic Functions Layer (BFL) ......................................................40
6.2.2.3 Service Layer ............................................................................41
6.2.2.4 Application Layer .......................................................................42
6.2.2.5 Device Management Entity .........................................................42
6.2.2.6 Service Access Points (SAP) ......................................................42
7 Recommended Sensor Network Standardization Areas for ISO/IEC JTC 1 .....................43
7.1 Terminology ........................................................................................................44
7.2 Requirement Analysis ..........................................................................................44
7.3 Reference Architecture ........................................................................................44
7.4 Application Profiles ..............................................................................................44
7.5 Interface ..............................................................................................................44
7.5.1 Sensor Interface ......................................................................................44
7.5.2 Data Type and Data Format .....................................................................45
7.6 Communication and Networking ...........................................................................45
7.6.1 Physical Layer (PHY) ...............................................................................46
7.6.2 Media Access Control (MAC) ....................................................................46
7.6.3 Networking ...............................................................................................46
7.6.4 Inter-working with Access and Backbone Networks ...................................47
7.7 Network Management ..........................................................................................47
7.8 Mobility Support ...................................................................................................48
7.9 Collaborative Information Processing ...................................................................49
7.10 Information Service Supporting ............................................................................49
Technical Document of - iii -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
7.10.1 Information Description ............................................................................50
7.10.2 Information Storage ..................................................................................50
7.10.3 Identification ............................................................................................50
7.10.4 Directory Service .....................................................................................50
7.11 Quality of Service (QoS) ......................................................................................51
7.12 Middleware Functions ..........................................................................................53
7.13 Security and Privacy of Sensor Networks .............................................................54
7.13.1 Security of Sensor Networks ....................................................................55
7.13.1.1 Security technology ...................................................................57
7.13.1.2 Security management ................................................................57
7.13.1.3 Security evaluation ....................................................................57
7.13.2 Privacy of Sensor Networks ......................................................................57
7.14 Conformance/Compliance and Interoperability Testing ..........................................58
7.14.1 Conformance/Compliance Testing ............................................................58
7.14.2 Interoperability Testing .............................................................................58
7.14.3 System Performance Testing ....................................................................58
8 Coordination Proposals to JTC 1 for Sensor Network Standardization ............................59
8.1 Sensor Network Standards and Related Activities by SDOs, Consortia, and
Fora ....................................................................................................................59
8.1.1 Activities within ISO/IEC JTC 1 .................................................................59
8.1.2 Activities outside ISO/IEC JTC 1 ..............................................................61
8.2 Mapping of SN Standardization Areas to JTC 1 SCs .............................................62
8.3 Other SDOs, Fora and Consortia for SN Standardization Areas for
Cooperation .........................................................................................................63
8.4 Organizational Options for SN Standardization Coordination .................................64
8.5 JTC 1/SGSN Oslo Resolution 6 – SGSN Long Term Role .....................................64
Annex A............................................................................................................................ A-1
A Sensor Network Applications....................................................................................... A-1
A.1 Logistics and Supply Chain Management: Theft Prevention System for High
Value Goods...................................................................................................... A-1
A.1.1 Description of Application ....................................................................... A-1
A.1.1.1 Motivation for Using Sensor Networks ...................................... A-1
A.1.1.2 Solution Approach ................................................................... A-1
A.1.1.3 Operational View and Description............................................. A-1
A.1.1.4 Software Architecture from a Functional Point of View .............. A-2
A.1.2 Requirements of Application ................................................................... A-3
A.2 Energy & Utility Distribution Industry: Sensor Network-Based Smart Grid
System .............................................................................................................. A-3
A.2.1 Description of Application ....................................................................... A-3
A.2.1.1 Motivation for Using Sensor Networks ...................................... A-3
A.2.1.2 Solution Approach ................................................................... A-3
A.2.1.3 Operational View and Description............................................. A-4
A.2.1.4 Software Architecture from a Functional Point of View .............. A-5
A.2.2 Requirements of Application ................................................................... A-5
A.3 Automation, Monitoring and Control of Industrial Production Processes:
Industrial Automation in General ........................................................................ A-6
Technical Document of - iv -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
A.3.1 Description of Application ....................................................................... A-6
A.3.1.1 Motivation for Using Sensor Networks ...................................... A-6
A.3.1.2 Solution Approach ................................................................... A-6
A.3.1.3 Operational View and Description............................................. A-6
A.3.1.4 Software Architecture from a Functional Point of View .............. A-8
A.3.2 Requirements of Application ................................................................... A-8
A.4 Asset Management: Blood Bag Monitoring and Status Tracking .......................... A-9
A.4.1 Description of Application ....................................................................... A-9
A.4.1.1 Motivation for Using Sensor Networks ...................................... A-9
A.4.1.2 Solution Approach ................................................................... A-9
A.4.1.3 Operational View and Description............................................. A-9
A.4.1.4 Software Architecture from a Functional Point of View ............ A-10
A.4.2 Requirements of Application ................................................................. A-10
A.5 Health Care and Medical Applications at Home and in Hospitals: Position and
Posture Monitoring........................................................................................... A-11
A.5.1 Description of Application ..................................................................... A-11
A.5.1.1 Motivation for Using Sensor Networks .................................... A-11
A.5.1.2 Solution Approach ................................................................. A-11
A.5.1.3 Operational View and Description........................................... A-12
A.5.1.4 Software Architecture from a Functional Point of View ............ A-12
A.5.2 Requirements of Application ................................................................. A-13
A.6 Civil Protection and Public Safety: SLEWS – Prototype Landslide Monitoring
and Early Warning System ............................................................................... A-14
A.6.1 Description of Application ..................................................................... A-14
A.6.1.1 Motivation for Using Sensor Networks .................................... A-14
A.6.1.2 Solution Approach ................................................................. A-14
A.6.1.3 Operational View and Description........................................... A-14
A.7 Automation and Control of Commercial Buildings and Smart Homes: Building
Energy Conservation System ........................................................................... A-16
A.7.1 Description of Application ..................................................................... A-16
A.7.1.1 Motivation for Using Sensor Networks .................................... A-16
A.7.1.2 Solution Approach ................................................................. A-16
A.7.1.3 Operational View and Description........................................... A-16
A.7.2 Requirements of Applications ............................................................... A-17
A.8 Intelligent Transportation and Traffic: Parking Management System.................. A-17
A.8.1 Description of Application ..................................................................... A-17
A.8.1.1 Motivation for Using Sensor Networks .................................... A-17
A.8.1.2 Solution Approach ................................................................. A-18
A.8.1.3 Operational View and Description........................................... A-18
A.8.1.4 Software Architecture from a Functional Point of View ............ A-19
A.8.2 Requirements of Application ................................................................. A-20
A.9 Intelligent Transportation and Traffic: Harbour Freight Intelligence System........ A-20
A.9.1 Description of Application ..................................................................... A-20
A.9.1.1 Motivation for Using Sensor Networks .................................... A-20
A.9.1.2 Solution Approach ................................................................. A-20
A.9.1.3 Operational View and Description........................................... A-21
A.9.1.4 Software Architecture from a Functional Point of View ............ A-22
A.9.2 Requirements of Application ................................................................. A-22
Technical Document of -v-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
A.10 Energy & Utility Distribution Industry: Automated Meter Reading....................... A-23
A.10.1 Description of Application ..................................................................... A-23
A.10.1.1 Motivation for Using Sensor networks ..................................... A-23
A.10.1.2 Solution Approach ................................................................. A-23
A.10.1.3 Operational View and Description........................................... A-23
A.10.1.4 Software Architecture from a Functional Point of View ............ A-24
A.10.2 Requirements of Application ................................................................. A-24
A.11 Asset Management: Management of Medical Devices in Hospitals .................... A-25
A.11.1 Description of Application ..................................................................... A-25
A.11.1.1 Motivation for Using Sensor Networks .................................... A-25
A.11.1.2 Solution Approach ................................................................. A-25
A.11.1.3 Operational View and Description........................................... A-25
A.11.1.4 Software Architecture from a Functional Point of View ............ A-26
A.11.2 Requirements of Application ................................................................. A-27
A.12 Homeland Security: Anti-Intrusion System for Border/Perimeter Control and
Virtual Fences ................................................................................................. A-27
A.12.1 Description of Application ..................................................................... A-27
A.12.1.1 Motivation for Using Sensor Networks .................................... A-27
A.12.1.2 Solution Approach ................................................................. A-28
A.12.1.3 Operational View and Description........................................... A-28
A.12.1.4 Software Architecture from a Functional Point of View ............ A-29
A.12.2 Requirements of Applications ............................................................... A-30
Annex B............................................................................................................................ B-1
B Reference Architecture Development Process ............................................................. B-1
B.1 The Two Main Questions to be Answered for Reference Architecture .................. B-1
B.2 Applying System Architecture Development Process for SNRA ........................... B-1
B.3 Using SNRA to Identify and Develop Sensor Network Standards......................... B-5
B.4 Some of the Key Referece/System Architecture Diagrams and Artefacts ............. B-5
Annex C ........................................................................................................................... C-1
C Sensor Networks Related Activities within JTC 1 ......................................................... C-1
C.1 ISO/IEC JTC 1 SC 2 – Code Character Sets....................................................... C-1
C.2 ISO/IEC JTC 1 SC 6 – Telecommunications and Information Exchange
between Systems .............................................................................................. C-1
C.3 ISO/IEC JTC 1 SC 7 – Software and Systems Engineering ................................. C-1
C.4 ISO/IEC JTC 1 SC 17 – Cards and Personal Identification .................................. C-2
C.5 ISO/IEC JTC 1 SC 22 – Programming Languages, Their Environments and
System Software Interfaces ............................................................................... C-2
C.6 ISO/IEC JTC 1 SC 23 – Digitally Recorded Media for Information Interchange
and Storage....................................................................................................... C-2
C.7 ISO/IEC JTC 1 SC 24 – Computer graphics, image processing and
environmental data representation ..................................................................... C-3
C.8 ISO/IEC JTC 1 SC 25 – Interconnection of Information Technology
Equipment ......................................................................................................... C-3
C.9 ISO/IEC JTC 1 SC 27 – IT Security Techniques.................................................. C-4
C.10 ISO/IEC JTC 1 SC 28 – Office Equipment .......................................................... C-5
Technical Document of - vi -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
C.11 ISO/IEC JTC 1 SC 29 – Coding of Audio, Picture, Multimedia and
Hypermedia Information ..................................................................................... C-6
C.12 ISO/IEC JTC 1 SC 31 – Automatic Identification and Data Capture
Techniques........................................................................................................ C-6
C.13 ISO/IEC JTC 1 SC 32 – Data Management and Interchange ............................... C-7
C.13.1 ISO/IEC JTC 1 SC 32 WG 1 ................................................................... C-8
C.14 ISO/IEC JTC 1 SC 34 – Document Description and Processing Language........... C-8
C.15 ISO/IEC JTC 1 SC 35 – User Interfaces ............................................................. C-8
C.16 ISO/IEC JTC 1 SC 36 – Information Technology for Learning, Education and
Training ............................................................................................................. C-9
C.17 ISO/IEC JTC 1 SC 37 – Biometrics..................................................................... C-9
Annex D ........................................................................................................................... D-1
D Sensor Networks Related Activities outside of JTC 1 ................................................... D-1
D.1 International Standardization Organization (ISO) ................................................ D-1
D.1.1 ISO TC 22: Road vehicles ...................................................................... D-1
D.1.2 ISO TC 184/SC 5: Automation systems and integration ........................... D-1
D.1.3 ISO TC 204: Intelligent transport systems ............................................... D-1
D.1.4 ISO TC 205: Building environment design ............................................... D-3
D.1.4.1 TC 205/WG 3: Building control systems design ......................... D-3
D.2 International Electrotechnical Commission (IEC)................................................. D-3
D.2.1 IEC TC 17: Switchgear and cotorlgear .................................................... D-3
D.2.2 IEC TC 22: Power electronic systems and equipment.............................. D-3
D.2.3 IEC TC 57 – Power Systems management and associated
information exchange ............................................................................. D-3
D.2.4 IEC TC 65: Industrial-process measurement, control and automation ...... D-4
D.3 ITU-T................................................................................................................. D-5
D.3.1 ITU-T SG 13 Q.3 [Y.USN-reqts] .............................................................. D-7
D.3.2 TU-T SG 16 Q.25 (Established 2009)...................................................... D-7
D.3.3 ITU-T SG 16 Q.25 [F.usn-mw] ................................................................ D-8
D.3.4 ITU-T SG 17 Q.9 X.usnsec-1 .................................................................. D-8
D.4 IEEE 802.15 ...................................................................................................... D-9
D.4.1 IEEE 805.15.5...................................................................................... D-11
D.4.2 IEEE 805.15.6...................................................................................... D-11
D.5 IEEE 1451 ....................................................................................................... D-11
D.5.1 IEEE 1451.0 – Standard for a Smart Transducer interface for Sensors
and Actuators - Common Functions, Communication Protocols, and
Transducer Electronic Data Sheet (TEDS) Formats ............................... D-12
D.5.2 EEE 1451.1 – Standard for A Smart Transducer Interface for Sensors
and Actuators – Network Capable Application Processor (NCAP)
Information Model ................................................................................ D-14
D.5.3 IEEE 1451.2 – Standard for a Smart Transducer Interface for
Sensors and Actuators - Transducer to Microprocessor
Communications Protocols and Transducer Electronic Data Sheet
(TEDS) Formats ................................................................................... D-16
D.5.4 IEEE 1451.3 – Standard for a Smart Transducer Interface for
Sensors and Actuators—Digital Communication and Transducer
Electronic Data Sheet (TEDS) Formats for Distributed Multidrop
Systems............................................................................................... D-17
Technical Document of - vii -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
IEEE 1451.4 – Standard for a Smart Transducer Interface for
D.5.5
Sensors and Actuators—Mixed-Mode Communication Protocols and
Transducer Electronic Data Sheet (TEDS) Formats ............................... D-18
D.5.6 IEEE 1451.5 – Standard for a Smart Transducer Interface for
Sensors and Actuators—Wireless Communication Protocols and
Transducer Electronic Data Sheet (TEDS) Formats ............................... D-20
D.5.7 IEEE 1451.6......................................................................................... D-21
D.5.8 IEEE 1451.7......................................................................................... D-22
D.6 IEEE 1588: Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems ................................................. D-24
D.7 ISA100 / ISA100.11: Wireless system for automation / Wireless
communication standard(s) optimized for industrial loop control. ....................... D-24
D.8 ZigBee Alliance ............................................................................................... D-26
D.9 IETF ................................................................................................................ D-26
D.9.1 IETF 6LOWPAN ................................................................................... D-27
D.9.2 IETF ROLL........................................................................................... D-27
D.10 Sensor Web Enablement.................................................................................. D-27
D.10.1 OpenGIS Specifications by OGC .......................................................... D-28
Annex E............................................................................................................................ E-1
E Indicative List of Standards to Certain Sensor Network Applications ............................ E-1
E.1 Indicative List of IEC Standards and Publications on Sensor Networks for
Industrial Automation and Power/Utility Systems ................................................ E-1
E.2 Indicative List of SC 6 Standards/Publications on Telecommunications and
Information Exchange Between Systems ............................................................ E-3
E.3 Indicative List of SC 25 Standards/Publications on Smart Homes and Home
Automation ........................................................................................................ E-5
E.4 Indicative List of JTC 1 SC 32 Standards on Operation Architecture.................... E-7
E.5 Indicative List of JTC 1 SC 37 Standards/Publications on Biometrics
Applications....................................................................................................... E-7
Technical Document of - viii -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Table of Figures
Figure 3-1. Primary interfaces and components for the scope of SN standardization............. 6
Figure 6-1. Zachman Framework TM for enterprise architecture. ...........................................29
Figure 6-2. Sensor Networks high level operational graphic. ...............................................36
Figure 6-3. Sensor networks entity/node connectivity diagram – an instantiation. ................37
Figure 6-4. SN system description for sensor node cluster control – an instantiation............37
Figure 6-5. Sensor networks systems architecture – Layer focused. ....................................38
Figure 6-6. Services/functionalities cut-across sensor networks layers. ...............................39
Figure 6-7. Operation layer view of sensor node device. .....................................................40
Figure 6-8. An example of component interconnections via service access points. ..............42
Figure 7-1. Fundamental platform standards framework and applications for SN..................43
Figure 7-2. Mobility in sensor networks...............................................................................48
Figure 7-3 Collaborative information processing (CIP). .......................................................50
Figure 7-4. Application data delivery model. .......................................................................52
Figure 7-5. Taxonomy analysis of sensor network QoS. ......................................................53
Figure 7-6. Functional model of sensor network middleware, its service layers, generic
functions within each middleware layer, and interfacing layer. .......................54
Figure 7-7. Layered security model of sensor networks. ......................................................55
Figure A-1. Operational view of a typical distribution network and theft prevention. ........... A-2
Figure A-2. Operational view of a multi-layer smart grid communication network. .............. A-4
Figure A-3. Typical sensor network Smart Grid system and software architecture. ............. A-5
Figure A-4. Industrial wireless network operational architecture view. ............................... A-7
Figure A-5. Nodal interconnectivity architecture diagram for industrial automation
systems using wireless sensor node. .......................................................... A-7
Figure A-6. Stack reference model. .................................................................................. A-8
Figure A-7. Blood temperature monitoring service........................................................... A-10
Figure A-8. Operational view of system architecture for position & posture monitoring. .... A-12
Figure A-9. SLEWS gateway and operational view. ......................................................... A-15
Figure A-10. SLEWS system architecture view. .............................................................. A-15
Figure A-11. Architecture of the BEC system. ................................................................. A-17
Figure A-12. Architecture of parking management system. .............................................. A-18
Figure A-13. Parking lot sensor network. ........................................................................ A-19
Figure A-14. Software architecture for intelligent parting management system................. A-19
Figure A-15. Container gate system operational architecture view (showed in red). ......... A-21
Figure A-16. RFID- and WSN-based harbour management. ............................................ A-22
Figure A-17. Operational view of infrastructure for management of medical devices. ....... A-26
Figure A-18 Operational view of a typical sensor network anti-intrusion system. .............. A-29
Figure A-19. Typical sensor network anti-intrusion system. ............................................. A-30
Technical Document of - ix -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Figure B-1. Architecture artifacts and their relationships. .................................................. B-3
Figure B-2. Architecture artifacts to standard mapping. ..................................................... B-4
Figure B-3. SNRA’s role in SN standard development. ...................................................... B-5
Figure B-4. Operational Node Connectivity Description. .................................................... B-6
Figure B-5. Sensor Network Operational Node Description. .............................................. B-6
Figure B-6. Use Case Operational Node Description. ........................................................ B-7
Figure B-7. System Interface Description (Node to Node Interface). .................................. B-8
Figure B-8. Interface Description (System to System Interface) ......................................... B-8
Figure B-9. Inter-nodal Interface Description. ................................................................... B-9
Figure D-1. ITU-T Sensor network architecture and concept. ............................................ D-6
Figure D-2. ITU-T Sensor network with networking and standards. .................................... D-6
Figure D-3. ISA100.11a reference model. ....................................................................... D-25
Figure D-4. ZigBee protocol stack over 802.15.4. ........................................................... D-26
Figure D-5. Sensor Web concept. ................................................................................... D-28
Figure D-6. IEEE 1451 in the Sensor Web Enablement (SWE) Interoperability Stack. ...... D-29
Technical Document of -x-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
List of Tables
Table 1-1. Mapping of ToR/Resolution to the TD chapter, section(s), and annex................... 2
Table 4-1. Market segments and applications for sensor networks. .....................................10
Table 5-1. Generic requirements for various sensor network applications. ...........................20
Table 6-1. Architecture framework used in industry. ............................................................28
Table 6-2. SNRA Basic functions layer components ............................................................40
Table 6-3. SNRA Service layer components. ......................................................................41
Table 6-4. Sensor network device management entity components. ....................................42
Table 8-1. Mapping of standardization areas to JTC 1 SCs. ................................................62
Table 8-2. Standardization areas to potential SDOs, Consortia, and Fora............................63
Table A-1. Required sensor network services. .................................................................. A-2
Table A-2. Theft prevention systems’ requirement description and specifications............... A-3
Table A-3. System requirements. ..................................................................................... A-5
Table A-4. System requirements. ..................................................................................... A-8
Table A-5. Software functions implemented on the different nodes. ................................. A-10
Table A-6. System requirements .................................................................................... A-11
Table A-7. Software functions implemented on the different nodes. ................................. A-13
Table A-8. System requirements. .................................................................................... A-13
Table A-9. System requirements of the BEC system. ...................................................... A-17
Table A-10. System requirements of parking management system. .................................. A-20
Table A-11. Software functions implemented on the different nodes. ............................... A-22
Table A-12. System requirements for harbour yard management system. ........................ A-22
Table A-13. Software functions implemented on the different nodes. ............................... A-24
Table A-14. System requirements................................................................................... A-25
Table A-15. Software functions implemented on the different nodes. ............................... A-26
Table A-16. System requirements................................................................................... A-27
Table A-17. System requirements................................................................................... A-30
Table C-1. Sensor ID. ...................................................................................................... C-7
Table C-2. JTC 1 SC 37 Working group scope and description........................................ C-11
Table D-1. Comparison between TC 204 Communications Access for Land Mobiles
(CALM) and other channel access method. ................................................. D-2
Table E-1. Indicative list of ISO and/or IEC standards and publications for industrial
automation application. .............................................................................. E-1
Technical Document of - xi -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Table E-2. Indicative list of IEC TC 57 standards on power system and its automation
application. ................................................................................................ E-2
Table E-3. Sensor network-relevant new projects in JTC 1 SC 6 on security and
reference architecture model, ..................................................................... E-3
Table E-4. Indicative list of JTC 1 SC 6 standards (published) on telecommunications
and information exchange between systems. .............................................. E-3
Table E-5. Indicative list of JTC 1 SC 6 standards (under development) on
telecommunications and information exchange between systems. ............... E-5
Table E-6. Indicative list of JTC 1 SC 32 standards on security and privacy for Home
Electronic Systems and Home Network. applications,.................................. E-5
Table E-7. Indicative list of JTC 1 SC 25 standards on security requirements for Home
Network. Home Automation applications. .................................................... E-6
Table E-8. Other indicative list of JTC 1 SC 25 standards on Home Electronic
Systems, Home Networks applications........................................................ E-6
Table E-9. Indicative list of JTC 1 SC 32 standards on operational architecture
application. ................................................................................................ E-7
Table E-10. Indicative list of JTC 1 SC 37 standards on security for biometric
applications................................................................................................ E-7
Technical Document of - xii -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
List of Acronyms
1-D One Dimensional FCR Functional Capability
2-D Two Dimensional Requirement
3-D Three Dimensional FEA RM Federal Enterprise Architecture
Reference Model
6LoWPA IPv6 over Low power WPAN
N FEAF Federal Enterprise Architecture
Framework
AAL Ambient Assisted Living
GIS Geographical Information
AODV Ad-hoc On-demand Distance System
Vector
GPRS General Packet Radio Service
APEC Asia-Pacific Economic
Cooperation GPS Global Positioning System
API Application Programming GSM Global System for Mobile
Interface communications
B2B Business-to-Business GSR General System Requirement
B2C Business-to-Consumer HART Highway Accessible Remote
Transducer
BEC Building Energy Conservation
HoD Head of Delegation
BFL Basic Function Layer
ID Identification [Number]
CBRN Chemical, Biological,
Radioactive, Nuclear IEC International Electrotechnical
Commission
CDE Capability Declaration Entity
IETF Internet Engineering Task Force
CDMA Code Division Multiple Access
IM Instant Messaging
CIP Collaborative Information
Processing IP Internet Protocol
CRSE Communication Requirement ISA International Society of
Specification Entity Automation
CSMA Carrier Sense Multiple Access ISO International Organization for
Standardization
CSPE Collaborative Strategy Planning
Entity IT Information Technology
DLL Dynamic-Link Library ITU-T Telecommunication
Standardization Sector
DMAP Device Manager Application
Process JTC 1 Joint Technical Committee 1
DoDAF Department of Defense LAN Local Area Network
Architecture Framework LED Light Emitting Diode
DSDV Destination-Sequenced Distance LET Learning, Education, and
Vector Training
DSL Digital Subscriber Line MAC Media Access Control
DSR Dynamic Source Routing MAC Message Authenticity Codes
ECG Electrocardiography MANET Mobile Ad-hoc NETwork
EEG Electroencephalography Mbus Maintenance Bus
EMC Electric Management Centre MLR Metadata for Learning
EMG Electromyography Resources
FAR False Alarm Rate NCAP Network Capable Application
Processor
Technical Document of - xiii -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
NWK Network [Layer] UMTS Universal Mobile
OECD Organisation for Economic Co- Telecommunications System
operation and Development URI Uniform Resource Identifier
OGC Open Geospatial Consortium URN Uniform Resource Name
OID Object Identifier WLAN Wireless Local Area Network
OSI Open System Interconnection WPAN Wireless Sensor Actuator (or
PHY Physical Layer Actor) Network
PV Photo Voltaic WSN Wireless Sensor Network
QoS Quality of Service
RFC Request for Comments
RFID Radio Frequency Identification
ROLL Routing Over Low power and
Lossy networks
SAP Service Access Point
SAR Synthetic Aperture Radar
SatCom Satellite Communication
SC Subcommittee
SDO Standard Developing
Organization
SGSN Study Group on Sensor
Networks
SLEWS Sensor-based Landslide Early
Warning System
SMS Short Message Service
SN Sensor Network or Sensor
Networks
SN-IS Sensor Network International
Standards
SNMP Simple Network Management
Protocol
SNRA Sensor Network Reference
Architecture
SoS System of Systems
SWE Sensor Web Enablement
TCP Transmission Control Protocol
TD Technical Document
TDMA Time Division Multiple Access
TEAF Treasury Enterprise Architecture
Frame
TM Trade Mark
ToGAF The Open Group Architecture
Framework
ToR Terms of Reference
TR Technical Report
UDP User Datagram Protocol
Technical Document of - xiv -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
1 Purpose of this Document
The primary purposes of this Technical Document (TD) are not only to record the outcomes of
the study carried out by the Study Group on Sensor Networks (SGSN), but also to recommend
potential work areas to JTC 1 and its appropriate subcommittees (SCs) to ensure that all
necessary aspects of Sensor Networks (SN) within the scope of JTC 1 are standardized.
The secondary purpose of this document is to recommend how the recommended work on
Sensor Networks can be efficiently and effectively coordinated and performed in JTC 1.
In 2008, this study was performed according to the Terms of Reference (ToR) of ISO/IEC JTC
1 SGSN defined at the 22 nd ISO/IEC JTC 1 Plenary Meeting, 13 October 2007, in Gold Coast,
Australia. In the 23 rd JTC 1 Plenary, held in Nara, Japan, in October 2008, SGSN’s activity
was extended for another year with the additional ToR (JTC 1 Nara Resolution 31) on Sensor
Networks issues on middleware and on privacy. This additional ToR was studied in 2009
along with refining the study contents of the ToR from 2008. The ToR from 2008 and Nara
Resolution 31 are listed below, which this study was focused on:
1) Review the current definitions, visions and requirements for target applications of Sensor
Networks within JTC1 and outside JTC1 in connection with different application areas (e.g.
home, medical informatics, transport informatics, industrial communications, RFID etc) as
well as JTC 1 SCs roles in these application areas.
2) Review and identify
The unique characteristics of Sensor Networks and the commonalities and differences
with other networks
The system architectures of Sensor Networks in terms of functionalities
The entities that together comprise Sensor Networks and their characteristics
Existing protocols that can be used for Sensor Networks and the elements of protocols
that are unique to Sensor Networks
The scope of infrastructure that can be considered to be a Sensor Network
The types of data that need to be handled (acquired, processed, transported, stored,
rendered etc) by Sensor Networks and any specific QoS attributes required by those
categories
The interfaces that need to be supported by Sensor Networks
The services that need to be supported by Sensor Networks
Aspects such as security, privacy, identification that may be relevant to specific
Sensor Networks
3) Monitor other activities in international standardization bodies and consortia and fora
where specifications related to Sensor Networks are being developed
4) Produce a report covering 1) and 2) above and information on other relevant
standardization activities
5) In the light of published SC scopes and work programmes and the results of 1) to 3)
recommend potential areas of work to JTC 1 and appropriate SCs to ensure that all
necessary aspects of Sensor Networks within the scope of JTC 1 are standardised.
6) Recommend how the work on Sensor Networks can be efficiently coordinated in JTC 1.
7) Hold workshops to gather requirements or publicise the results.
Technical Document of -1-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
8) Meetings of the group may be physical or via electronic means.
9) Nara Resolution 31
Sensor Networks issues on middleware and on privacy
Table 1-1 maps the ToR to this document’s chapter or its section(s) where the corresponding
ToR is answered, discussed, and/or described, fulfilling the 2008 responsibility of the SGSN
Table 1-1. Mapping of TOR/Resolution to the TD chapter, section(s), and annex.
ToR # Chapter Number(s)
1 Chapters 2, 3, and 4; all sections under Chapters 2, 3, and 4; Annex A
2 Chapters 5 and 6; all sections under Chapters 5 and 6; Annex B
3 Section 8.1, Annex C, Annex D, Annex E
4 The report is produced, which is this SGSN Technical Document.
Chapter 7 and its all sections (for potential work areas); Section 8.2 (for
5 appropriate JTC 1 SCs); and Section 8.3 (for potential collaboration with
SDO’s, consortia, fora outside SGSN)
Section 8.4 for organizational options for Sensor Network standardization
within JTC 1; and Section 8.5 for the SGSN’s final decision on the
6
organization for Sensor Network standardization organization, which is the
SGN Oslo Resolution 6.
A total of two SGSN workshops on Sensor Networks were conducted in 2008
and 2009:
7 The 1 st SGSN Workshop: Shanghai, China, 25 June 2008, a day prior to
the 1 st SGSN face-to-face meeting, 26-27 June 2008
The 2 nd SGSN Workshop: Seoul, Korea, 15-17 April 2009
A total of four face-to-face meetings were conducted in 2008 and 2009.
The 1 st SGSN meeting: Shanghai, China, 26-27 June 2008
8
The 2 nd SGSN meeting: Nürnberg, Germany, 15-19 September 2008
The 3 rd SGSN meting: Sidney, Australia, 19-23 January 2009
The 4 th SGSN meeting: Oslo, Norway, 27 June – 3 July 2009
Section 7.12 for sensor network middleware; Section 7.13 on privacy; and
the official responses to JTC 1 Nara Resolution 31 were sent:
JTC 1 Nara
Resolution 31 SGSN N151, “Standardization Issues for USN Middleware,” August 5, 2009.
SGSN N152, “Sensor Networks issues explored on privacy replying to JTC 1
Nara Resolution 31,” August 21, 2009.
Because of the comments from the liaison standards developing organizations (SDOs), it
should be made clear that SGSN is a study group for sensor networks under JTC 1. SGSN is
not a standards developing body under JTC 1. Therefore, the contents of this TD are the
SGSN study results in:
stating SN vision and mission statements and defining key SN terminology (Chapter 2)
providing the scope of JTC 1 SN standardization and discussing the scope (Chapter 3)
collecting and describing sensor network applications in different market segments
(Chapter 4 and Annex A)
Technical Document of -2-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
generating generic and generalized SN system and functional requirements (Chapter
5)
developing a foundation for SN reference architecture (Chapter 6 and Annex B)
identifying and describing SN standardization areas (Chapter 7),
recommending the allocation of the identified standardization areas to JTC 1 SCs,
identifying other SDOs for potential collaboration, and also recommending on how SN
standardization work can be effectively coordinated and performed in JTC 1 (Chapter
8, Annex C, and Annex D)
listing the liaison organization supplied standards relevant or potentially relevant to SN
standards (Annex E)
Technical Document of -3-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
2 Description of Sensor Networks
In describing Sensor Networks (SN), we start with SN vision and mission statements. The
vision provides the ultimate goal of the SN technology; the mission statement provides the
purpose, business need, and value of the SN standardization. Then we move on to define the
key SN terminology.
2.1 Vision Statement of Sensor Networks
Sensor Networks (SN) apply sensing, networking, and data/information processing
technologies to improve the quality of life and change the life style.
2.2 Mission Statement of Sensor Networks Standardization
The purpose: To establish SN standards for all aspects of SN applications and services
accepted by the international SN community and industry.
The business: Identifying and studying SN standardization need areas with industry experts
in order to develop the international SN standards.
The values: Interoperability and “plug & sense” of sensors and networks through the
standards bringing benefits of reducing cost, schedule and risk for SN developers and
implementers.
2.3 Definitions of key Sensor Network Terminology
For effective communications among the SN stakeholders, the key terminology across the SN
markets and applications need to be unified. SGSN reviewed the definitions form other
organizations. SGSN consolidated and/or updated these definitions to develop the definition
listed in this section.
2.3.1 Definitions of Sensor, Actuator, Sensor Node, and Sensor Network Gateway
In this section, we list the definitions of sensor, actuator, sensor node, and sensor network
gate way.
2.3.1.1 Definition of Sensor
A sensor is a device that observes phenomenon/phenomena, measures physical property and
quantity of the observation, and converts the measurement into a signal.
Note: (1) Signal can be electrical, chemical, or other types of sensory responses; (2) Signal
can be represented by 1-D, 2-D, 3-D, or higher dimensional data.
2.3.1.2 Definition of Actuator
An actuator is a device that performs a physical response caused by an input signal.
2.3.1.3 Definition of Sensor Node
A sensor node is a device that consists of at least one sensor and zero or more actuators, and
has processing and networking capabilities through wired or wireless means.
Technical Document of -4-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
2.3.1.4 Definition of Sensor Network Gateway
The sensor network gateway represents the bridge between the sensor network itself and the
back-end system.
Note: Therefore, a sensor network gateway is required to provide wired/wireless interface(s)
to other sensor nodes as well as a wired (e.g., Ethernet) or wireless (e.g., mobile Ethernet via
WLAN, UMTS or SatCom) interface to the existing IT infrastructures.
2.3.2 Definition of Sensor Networks
A sensor network is a system of distributed sensor nodes interacting with each other and also
interacting with other environments in order to acquire, process, transfer, and provide
information extracted from a physical world in order to perform certain responses to the
physical world.
Note: Sensor network is a system, at least, consisting of sensors, actuators, and
communication nodes.
2.3.3 Definition of Sensor Network Services
The sensor network service is the functions offered by the sensor nodes or sensor networks.
2.3.4 Definition of User Services
The user service is a service offered to a user by a provider.
Note: A sensor network application performs value-adding functions to sensor data according
to user requirements, and finally the processing results are provided as a service to the user.
2.3.5 Definition of Sensor Network Applications
The sensor network application is a use case of sensor networks supporting a set of sensor
network services for users.
Note: The services are, for example, home utility monitoring and control, industrial
automation, infrastructure and environment monitoring, weather and disaster condition
monitoring and emergency alert. More examples are listed in Section 4 and the description of
the sensor services are found in Annex A.
Note: Sensor network application implies the utilization of software and hardware that can be
performed in a fully or partially automatic way and can be accessed locally or remotely.
Technical Document of -5-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
3 Scope of Standardization on Sensor Networks in JTC 1
Sensor network (SN) is one of the unique technology enablers that supports both vertical and
horizontal markets. Sensor network technology and infrastructure support the horizontal
markets. Applications and services that utilize the sensor network technology and
infrastructure generate vertical markets. This dual market applicability of SN complicates SN
standardization process because SN standards must satisfy and be applicable to both
horizontal and vertical markets.
The SN standards should be sufficiently generic to be scalable, sensor/actuator-agnostic, and
protocol-agnostic to support and used by the SN infrastructure developers and system
manufacturers for the horizontal markets. At the same time, the SN standards should
encompass the common features in various application profiles (services, processing
functions, interfaces, operational attributes, etc.) to support and used by the developers in the
SN applications and services for vertical markets.
It is recognized that many sensor network related standards have been developed by many
standards developing organizations (SDOs), e.g., ISO, IEC, ITU-T, consortia and fora, for
various applications over the years. Therefore, sensor network standard development in JTC
1 should be coordinated with the SDOs that have developed the relevant standards for sensor
networks.
Figure 3-1 pictorially shows the four primary interfaces (see the yellow dialog boxes) in sensor
networks. The figure also shows that a sensor node consists of: (1) node hardware and
different types of sensors; (2) various services and basic sensor node functions; and (3)
application software modules. The sensor nodes in the network and the gateway connected
to “Rest of the World” communicate and collaborate with each other to support the needs of
“Rest of the World.” The “rest of the world” includes IT companies, service providers, and
end-users.
Sensor Node Rest of the World
Applications and Services
Interfaces between
Interfaces between service layer and
Service Provides and Users
service layer and node application layer
hardware Backbone Network
Interfaces between
sensor network and
S2 ..... Rest of the World
Services and S1 Gateway node
basic node ASM
functions
....
.
.
Node Wired or wireless
Application hardware Sensor
interfaces
Software node
between nodes of
Module sensor networks
Blue rings represent middleware and its functions.
Figure 3-1. Primary interfaces and components for the scope of SN standardization.
3.1 The Scope
The primary scope of sensor network standardization in JTC 1 is to specify the generic and
generalized interfaces (refer to Figure 3-1) between:
Technical Document of -6-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Node service layer and node application layer
Node service layer and node hardware (includes sensor, actuator, and/or
communication unit, etc.)
Nodes in sensor network via wired or wireless means
Sensor network and rest of the world (e.g., service providers and/or users)
The purpose of developing generic and generalized definition for the above four interfaces is
to promote the interoperability among sensor nodes (include sensor, actuator, and
communications units, and other hardware in the node), networks, and data supporting sensor
network developers and users.
The secondary scope of the sensor network standardization is to examine and specify key
technical areas of sensor networks to achieve the interoperability. These key sensor network
standardization areas are listed and discussed in Chapter 7 of this document. Chapter 7
includes the recommended standardization areas, e.g., terminology, reference architecture,
application profiles, sensor interface and data format, communications and networking.
Additional details of the standardization areas can be uncovered from the system architecture
process while building Sensor Network Reference Architecture (SNRA). SNRA will depict the
general system-level architecture representing sensor networks, and it may include
operational views, functional views, and technical views for example applications or use
cases.
3.2 The Four Interfaces of Sensor Networks
In the following paragraphs, the four interfaces as shown in Figure 3-1 which are the concerns
of the primary SN standardization scope are discussed in detail.
Interface between node service layer and node application layer 1 : The application
software modules can contain “business intelligence” information. At least, three different
standardization aspects discussed below should be investigated:
Identifying and analyzing sets of required sensor network services and basic functions:
The SN standardization body should make sure that the standards address all possible
sensor network applications. Reference applications which represent sets of similar
applications need to be identified and analyzed to develop the list of required services
and basic functions.
Application programming interfaces (APIs): For each and every service and basic
function, standard interfaces should be developed. Based on these APIs which are
considered as “construction modules,” application programmers will be able to deliver
solutions to users’ needs 2 over sensor networks. Descriptions on service scheduling
should also be defined to fulfill the requests from application module on the sensor
node.
Feedback description of service and basic function operations: It is necessary to
provide mechanisms to collect not only operating qualities (i.e. QoS) resulted from the
—————————
1 Review standards in http://www.opengeospatial.org for potential adaptation of Open Geospatial Consortium
(OGC) interface standards, e.g., SWE Architecture documents.
2 The “users” has at least two meanings in this context: (1) non-human system users, e.g., other sensor nodes,
gateway, a system in IT infrastructure, etc.; and (2) human users, e.g., system operator, IT developer, end-
user, etc.
Technical Document of -7-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
performance of services and basic functions, but also responding qualities resulted
from a user’s request for data/information exchange among services and basic
functions.
Interface between node service layer and node hardware: Interface mechanisms that
describe data/information between sensor node hardware and different services & functions in
the service layer should be defined and developed.
Integration of wired and wireless sensors: In some sensor network applications, using
both wired and wireless sensors may become necessary. Thus, the SN
standardization should examine how the existing standards for wired sensors (e.g.,
legacy sensors) and intelligent sensors/transducers can be integrated with wireless
sensor networks when developing the standards for wireless sensor networks.
Characterization of node hardware: Characteristics of sensor node hardware should be
explicitly described because the hardware supports different services and basic
functions with application software. Important hardware characteristic parameters
should be analyzed and specified during the standardization process.
Sensory signal/data characterization: Parameters on quality of physical sensor signals
should be developed in order to support target sensor network services aiming at
physical data/information delivery requirements.
Wired/wireless interface between sensor nodes: From the network viewpoint, standards
for physical layer, MAC layer, network layer, network management, and other related areas
should be investigated. Network protocols for sensor networks also need to be investigated.
Standards have to be either developed or leveraged (as there are existing standards that are
applicable) for wired/wireless communications and for routing of the data within the network
(e.g., Mobile Ad-hoc NETwork, MANET). Security is another aspect for standardization for
SN.
Wired/wireless communication: The physical layer and the media access control have
to be addressed. Main target is: (1) to interconnect single entities (e.g., sensor nodes,
sensor network gateway, etc.) of the sensor network; and (2) to deliver the
precondition for data transfer. Different types of sensor network applications might
require different types of communication protocols.
Routing of data within the network: On contrary to wired connections between the
sensor nodes, wireless connection allows dynamic and adaptive data routing paths
according to the mobility, node failure, and changing environments. Standards which
define routing mechanisms are needed.
Security issues: Wired/wireless connections inside and outside an organization are
vulnerable to attacks. During the standardization process, threat analysis has to be
carried out for representative reference application in order to define requirements and
to adopt the standards 3 .
Interface between sensor network and the rest of the world (application domain): Users,
e.g., human operator/user or a system outside a sensor network, have to access sensor
networks in order to configure and control the network. The network has to be able to push
data to and pull data from the application domain, that is, the “rest of the world.” Data
communications between the application domain and the sensor network have to be
—————————
3 Monitor IETF’s Routing Over Low-power and Lossy (ROLL) network group’s activity in the effort of controlling
sensor nodes on Bluetooth, WiFi, and 802.15.4 networks in order to link to the internet.
Technical Document of -8-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
standardized to support different sensor network applications and the users’ needs. A closer
examination shows that the following standardization aspects should be addressed:
Sensor network middleware: The middleware connects the sensor network gateway to
the applications and integration platforms used by commercial organizations, service
providers, and end-users (e.g., customers). Ideally, the sensor network middleware
would house common functions and services found in many SN applications, for
example data filtering, data mining, context modelling, estimation and decision,
forecasting, etc. Another task of the middleware is to manage sensor nodes and other
sensor network entities.
Note: Sensor network middleware is discussed above bullet paragraph. In Figure 3-1,
two other middleware are shown in the sensor node box: (1) the middleware between
the service layer and the node hardware; and (2) service layer and application layer.
These middleware all together is called the sensor network middleware. The sensor
network middleware is discussed further in Section 7.12.
RF interference compatibility of wired/wireless sensor networks and other wireless
communication systems: Some wireless communication systems and sensor networks
cannot be operated in the same networked infrastructure or environment. In some
applications, e.g., RFID-based sensor network, wireless transmission power is often
very weak, causing the sensor network vulnerable to jamming by other wireless
devices, communications, etc. Therefore, collaboration and cooperation with other
standardization bodies will be necessary.
Technical Document of -9-
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
4 Sensor Network’s Market Segments and Applications
As described in Chapter 3 above, sensor network market segments and applications are vast
and diverse covering both horizontal and vertical markets. Thus, SGSN requested
contributions from the SGSN members, JTC 1 subcommittees, and other liaison organizations
on the description of wired/wireless sensor network applications so that SGSN can develop
comprehensive list and description of sensor network markets and applications. The results
of this activity are the content of this chapter and Annex A. However, by no means, SGSN
claims that the markets and applications listed in Table 4-1 and the applications described in
Annex A are complete or exhaustive.
The sensor network potential market segments and their current and future applications that
employ wired/wireless sensor networks are listed in Table 4-1. The sensor network
standardization must consider requirements and specifications of the sensor network
applications to satisfy users’ needs in each market.
Because detailed description of each application listed in Table 4-1 is beyond the scope of
SGSN, we limited the analysis and description of the applications only to those highlighted
with blue in italic in the table. These analysis and description are found in Annex A – Sensor
Network Applications. During the SN standardization effort, additional applications should be
analyzed.
Table 4-1. Market segments and applications for sensor networks.
Market Segments Sensor Network Applications
Temperature monitoring for consumer goods industry
Monitoring of hazardous goods and chemicals
Logistics and Theft prevention in distribution systems for high value goods
Supply Chain Container monitoring in global supply chains
Management
Decentralized control of material flow systems
Identification of bottlenecks in process
Supply chain event management
Energy & Utility Sensor network-based smart grid system
Distribution
Industry Automated meter reading
Industrial automation in general
Automation, Quality control within production process
monitoring, and Machine Condition Monitoring
control of industrial
production Inventory Tracking and Surveillance
processes Monitoring of process parameters like temperature, pressure, flow
Control of manufacturing robots
Patient localization inside large hospital
Monitoring of vital parameters
Health care and Position and posture monitoring
medical
applications at Hospital personnel and equipment tracking
home and in Inventory management
hospital
Optimization of patient flow in hospital
Care for elderly people
Technical Document of - 10 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Market Segments Sensor Network Applications
Monitoring of building integrity for bridges, tunnels, gymnasiums
Civil protection and Early warning systems for detection of emerging forest fires
public safety SLEWS – A prototype landslide monitoring and early warning system
Localization and monitoring of fire fighters and other rescue staff
LET Collaboration application areas
LET Text based collaboration
LET Multimedia based collaboration
LET Learner communication (communication devices managed by
sensor networks)
Learning,
Education, and LET Augmented cognition application areas
Training (LET) LET Privacy application area
LET Biometric feedback application area
LET MLR for describing content to be sent over sensor network
LET Accessibility
LET Quality processes
Automation and Building energy conservation system
control of Adaptation of living environment to personal requirements
commercial
building and smart Monitoring and control of temperature, humidity, heating, etc.
homes Monitoring and control of light using occupancy and activity sensors
Monitoring of growing areas
Automation and
control of Crop disease management
agriculture Nutrient management
processes
Microclimate control
Parking management system
Harbor freight intelligent management system
Advanced travelers information systems
Advanced traffic management systems
Intelligent Advanced public transportation systems
transportation and
traffic Commercial vehicle operation systems
Advanced vehicle and highway information systems
Aircraft traffic management systems
Fleet management systems
Car-2-car communication for early warning systems
Monitoring of permafrost soil for early detection of problems
Detection of water pollution in nature reserves
Environment Temperature monitoring of coral reefs
observation, Detection of gas leakages in the chemical industry
forecasting, and
Weather observation and reports
protection
Environmental pollution including water and air
Seismic sensing and flood monitoring
Technical Document of - 11 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Market Segments Sensor Network Applications
Ocean observation network – ocean-borne sensors, airborne sensors,
Ocean observing satellites – for environmental monitoring
systems
Sea floor monitoring and mapping
Management of offices and large buildings
Facility
management Management of industrial sites
Management of transport infrastructure (road, tunnels, bridges)
Management of tools, for example, in the aviation industry
Management of medical devices in hospital
Blood bag monitoring and status tracking
Asset management
Audio and video surveillance, for example, at airport
Smoke, gas, and fire detection
Security systems for art work, windows, and doors
Battlefield monitoring
CBRN threat detection
Defence and Self-healing minefield
military
applications Military vehicle operations and maintenance
Monitoring of troop movement
Locating snipers
Disaster and crisis management
Container security in global supply chain
Homeland security
Monitoring of Infrastructure like transport/energy systems
Border control and virtual fences used as anti-intrusion systems
Automated inventory management
Retail applications
Security systems and theft prevention
Research Habitat monitoring
applications Remote ecological sensor networks, e.g., for endangered species
Active Tags /
Personnel tracking (e.g., coal mine security)
Mobile RFID
Ship & Airline Air traffic management and control
monitoring and
control Ship tracking and container tracking
Space Exploitation Planetary remote sensing; scientific research
4.1 Generalized Sensor Network Development and Evolution Stages for Target
Applications
Based on the observations from the sensor network applications and services examples
presented in Annex A, we can draw sensor network development/evolution stages that are
common or similar to most of the examples, for any target applications and services. For a
target application and its services, the developers of sensor networks will:
Generate the target sensor network’s system requirement
Technical Document of - 12 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Develop operational concept that leads to the sensor network application’s system
architecture
Develop hardware and software architectures
Implement hardware and software based on the system requirements, hardware and
software architectures to support the operational concept
Perform test and validation of all required functionality, including the target services, of
the implemented sensor network system
Deploy validated sensor network system
Another observation from the examples is that the reason for employing a sensor network is to
provide ubiquitous coverage of the area of interest, either small or large, for the target
applications to provide the services to the end-users.
The sensor network’s developmental evolution stages can also be viewed and discussed from
data/information processing point of view. The data/information processing is highly
dependent on: (1) characteristics and capabilities of new technologies for sensors, actuators,
and communication devices; (2) the application and service requirements for users’ needs;
and (3) the maturity and availability of computing hardware and software technologies. From
the processing point of view and the dependencies mentioned above, the three developmental
evolution stages are ordered in a growing magnitude of the sensor network’s capacity and
coverage, which can be achieved over time. Depending on application and service needs, the
development can be satisfied and completed at the end of each stage.
1. Sensor data pre-processing stage
This stage involves monitoring, measurement and data collection, data aggregation or
association at a sensor node or at a local group of sensor nodes. The data
aggregation is required at a sensor node if the sensor node has more than one
sensors attached. In case, a group of sensor nodes are performing the sensor data
pre-processing, the data can be aggregated or associated at a sensor network local
gateway or a group control station, having each sensor node sending its data to the
central location. Thus, depending on the data aggregation architecture schemes, the
data aggregation is performed at the centralized platform (e.g., Control Station for a
centralized data aggregation architecture). The data aggregation can also be
performed at multiple local host platforms (e.g., local gateways or host sensors for a
distributed data aggregation architecture). For some applications, user requirements
can be satisfied at this stage by certain basic functions of a single node such as
sensing, data gathering, and data forwarding.
2. Cooperative sensing stage
This stage typically involves transforming data into comprehensive information. This is
performed at a sensor network level but includes any information generated at the
sensor nodes and the groups of sensor nodes. The entire sensor network is
coordinated to perform collaborative processing either at a sensor node or at a local
group of the nodes level or the combination of the both levels. The coordination is
performed according to a pre-planned strategy based on cooperative sensing.
The size of the sensor network can grow large and complex over time; thus, the pre-
plan for the cooperative sensing can become complex, but should be scalable. The
pre-processed data discussed in the pre-processed data stage are sent to the control
or the operator’s station for collaborative processing to extract and generate
Technical Document of - 13 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
information according to the target applications. Furthermore, advanced processing is
performed to generate comprehensive and higher quality information to supports the
users’ needs for smarter services.
Then, the purpose of the cooperative sensing and collaborative processing is to
support the users’ desire to acquire intelligent services provided by the sensor
network. In order to achieve this purpose, the sensor data from the entire network
should be collaboratively processed by sensor nodes, processing layers and modules,
and subsystems.
3. Informational system of systems infrastructure – Ubiquitous coverage stage
The informational system of systems (SoS) infrastructure resulting from the
convergence of individual information and communication networks can provide a total
coverage for physical and informational spaces.
Sensor networks with embedded intelligence are merged with the existing, larger
information network infrastructures, e.g., Internet, cellular network, forming the
informational SoS infrastructure, providing ubiquitous services at anytime and
anywhere upon the user’s requests. The larger information networks could provide
additional factual, contextual, and historical information to the data/information from
the sensor networks.
The information from sensor network, Internet, and cellular network has to be merged
autonomously using smart or intelligent methods – that is, an automated information
convergence. Therefore, the sensor networks cover physical space; while the Internet
and cellular networks with its information databases and Internet-based knowledge
covers informational space. The new services from the SoS infrastructure can
enhance the user experience by providing value-added information/knowledge.
Technical Document of - 14 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
5 Characteristics and Requirements of Sensor Networks
In this chapter, we describe the unique characteristics of sensor networks compared with
traditional networks (e.g., communications network, legacy sensor networks or “sensors on
the net”). We list generic and generalized sensor network’s system and functional
requirements.
5.1 Characteristics of Sensor Networks
The applications described in Chapter 4 and Annex A illustrate that many differences can be
found between the emerging wired/wirelessly networked sensors and traditional wired/wireless
networks such as communications network. Compared with the traditional networks, not only
do sensor networks perform data transmission but also perform data processing, data
aggregation, data management, networking management, resource management, automation
(sense and actuate), and many other functions and services. The sensor network can
connect with existing infrastructures such as database, repository, and other systems through
IT backbone and Internet; thus become part of systems of systems (SoS) that provides
benefits to home and business. Therefore, although there are some common characteristics,
sensor networks have many unique characteristics that the traditional communication
networks do not.
End-user service models depend on end users and change dynamically according to
user requirements!
The existing legacy sensor networks (or sensors-on-the-network) have been installed for
specific application purposes such as structures monitoring, street light control, agriculture
monitoring and management, military surveillance, city facilities management, home utility
control, and flood and fire monitoring where consumer service models are not considered.
As an information service infrastructure to improve the quality of life, the sensor networks
should incorporate various service technologies such as sensor data gathering from
various data sources, for example, sensor nodes themselves, other service providers, and
private enterprises with functions including data filtering, data mining, context-aware
decision making, estimation and forecasting, and so on. Moreover, the type of services
provided depends on users’ service requirements and expectations; therefore, it is very
challenging to pre-determine the application/service features and relevant functions for a
wide variety of users. To satisfy the different levels of services for the different users, a
certain sensor data may be dynamically processed to meet individual user’s requests. As
in the example below, some users may ask for weather information from the weather
information services, but due to their different needs, they have different service
requirements demanding the different levels of services:
Fishermen may request on-demand and periodic weather information for fishing;
Tourists may request periodic and warning/alarming information of the nature’s
condition for a few days, a week, or a month by a service subscription;
Crewmen of a ship may request long-term weather forecasting information;
National disaster centre may request the whole weather information to observe the
natural phenomena of an area and detect emergency situations.
Technical Document of - 15 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Different sensor network applications inter-work with each other, forming a multi-
domain communication relationship!
There are many kinds of legacy sensor network applications such as industrial
automation, various types of monitoring and control applications, civil engineering,
intelligent building, home automation. And these applications usually operate in a
mutually exclusive manner. Technologically evolving capabilities and application of
sensor networks enables business partnerships whose business areas have been mutually
exclusive, e.g., auto industry and private safety/emergency monitoring services industry.
Thus, for certain business cases, the sensor network capabilities and functions should be
developed benefiting multiple business partnerships. Another general example is that a
sensor network service provider may need to interoperate with other sensor network
service providers to obtain sensor data, processed results, or information to improve the
service quality.
End users of sensor network applications and services could be arbitrary users as well
as dedicated users!
The existing legacy sensor network applications typically have a dedicated group of users.
But the emerging intelligent sensor networks and their applications/services aim at
arbitrary consumers and business partners. For example, weather information may be
provided to arbitrary consumers such as tourists and fishermen as well as business
partners such as airlines, shipping companies and travel agencies. Predefined users, i.e.
business partners, by contracts or agreements result in B2B-type sensor network services.
Arbitrary consumers by service subscription result in B2C-type sensor network services.
Wired/wireless sensor networks are the extension of Internet towards the physical
environment!
Wired/wireless sensor networks have to be regarded as an extension of Internet towards
the physical world (“Internet of Things”) connecting physical world with users which cannot
simply be regarded as a communication network. Sensors which never have been able to
communicate with their environment start to process sensor data and produce information
which is routed to a user. The “user” might be a man or machine. In most cases, the
human user does not stand in the foreground. Sensor nodes detect and monitor
environment conditions (i.e. “the physical world”) and/or other physical beings. The raw
data from the sensor’s observation (includes detect & monitor) is then transformedinto
different formats of data and/or information by various types of processing. These data
and information are routed to different users according to their requests.
Main objective of a sensor network implementation is to gather and pre-process sensor
data!
The main objective of a sensor network implementation is to gather and pre-process
sensor data. Therefore, intelligence on the sensor node is necessary. Sensor networks
have to ensure that all the information is available and comprehensive for the tasks given.
Communication/data links in the sensor network system have to be reliable and robust. If
one of the links is terminated, the wired/wireless sensor network has to self-organize and
find other ways to route the data or information to the gateway as no human intervention is
available to fix the broken link by rearranging or reconfiguring the sensor network.
To bring intelligence to a sensor node, a level of comprehensive data processing (e.g.,
data compaction, signal/image processing, etc.) is required. The “a level” is determined
by the sensor network’s target application. To enable the intelligence in the node, the
following needs should be considered:
Technical Document of - 16 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Sensor nodes in the network are automatically selected and organized to work
collaboratively and perform certain tasks or functions after processing their own
data collected from physical world;
Users take action according to information provided by the sensor networks.
Therefore, information provided to the users should be comprehensive and
reliable;
Nodes process data without the intervention of human decisions.
For many wired/wireless sensor network applications, sensor data have to be
associated with the source sensor’s location data!
For many wired/wireless sensor network applications, sensor data are required to be
associated with sensor’s location information. Thus, a sensor network needs to offer a
service to provide the sensor location information by a type of localization process, e.g.,
triangulation, data routing latencies, etc. For certain cases, sensors or sensor nodes in a
network have the ability to determine their own location, especially for mobile sensor
nodes, e.g., on-board GPS. Producing the location information of a sensor is one of the
most important services provided by a sensor network. The location information is then
associated with the sensor data. The localization processing in the sensor network should
be scalable because the networks may become very large and complex.
In most cases, sensor nodes have to work collaboratively in order to solve complex
sensing problems!
In many sensor network applications, the sensor nodes have to collaboratively work to
solve complex sensing problems, such as measurement, detection, classification, and
tracking in physical world. The data from a sensor may have to be pre-processed and
refined at the sensor node. Depending on applications, intermediary data/information,
such as features or estimated parameters, need to be extracted from raw sensor data
during the pre-processing. The results from this pre-processing should be shared among
the sensor nodes in the sensor network. Once shared, the intermediary data from multiple
sensor nodes can be transformed into context data and situation information by data
fusion. For data sharing in the network, the bandwidth must be considered. In many
applications, the sensor data processing may require a transmission of large amount of
data over the network; while other applications may only require transmitting a few bits
and bytes. Thus, sensor network standards should be sufficiently flexible and scalable to
facilitate collaboration information processing (CIP) and data/information transmission in
order to support various sensor network applications.
Sensor nodes have to communicate with each other without an existing communication
infrastructure!
Sensor nodes must communicate with each other without an existing communication infra-
structure. For this reason, a multi-hop capability and clustering algorithms will be
required. Efficient data communications among the sensor nodes are one of the important
traits for the measure of performance which is affected by bandwidth and latency. For
example, different applications dictate different requirements on latency time. For certain
applications, an alarm message has to be routed through a large network in less than a
few seconds; for other applications a minute or an hour may be acceptable. Therefore,
designing a flexible sensor network for different applications should carefully select data
routing schemes and communication protocols that support both types of applications.
The design must also consider the cost-effectiveness in developing and operating such a
sensor network.
Technical Document of - 17 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Computing has to computationally and power efficient due to the limited resources
especially within wireless sensor networks!
One of the most important characteristics of a wireless sensor network is the fact that
sensor nodes are energy-limited as they typically run on batteries; therefore, computing
has to consider the resource-limited nature of the sensor nodes. The more frequent the
sensor nodes become active to transmit data, the shorter life the sensor node has. It is
said that “every bit processed or transmitted is one bit closer to the dead battery 4 .”
For example, in the theft prevention system which is described in Annex A.1, its batteries
need to be quite large in order to operate sensor nodes and networks for two or three
months. In other applications, sophisticated energy management algorithms are needed
to keep the same energy level in all sensor nodes in a network so that the life time of each
sensor node and network can be predicted for maintenance. The wireless sensor network
power budget requirements are influenced by power consumption on average and on
frequency of peaks per given time period, low overall cost of installation and maintenance,
data rate, transmission bandwidth, and communication range. For wireless sensor
networks, low data rate, narrow transmission bandwidth, and short communication range
(when not using wireless relays to extend the range) are typical.
Sensor network topology has to adapt to the availability of data/communication link, to
the changing positions, energy levels and roles of nodes!
The topology of the wireless sensor network is rarely fixed. Normally, it has to adapt to
the availability of data/communication links between sensor nodes, to the changing
positions of objects to which sensor nodes are attached (e.g., mobility), to energy levels
(e.g., node drop out as battery runs out) and roles of sensor nodes. Applications where all
the nodes are fixed are relatively easy to handle. Applications where nodes move within
the network are more difficult to manage. The routing and communication protocols have
to be very fast and flexible, yet energy efficient. This flexibility in the sensor network
topology should not affect networks’ performance when sensor nodes enter or leave the
network, e.g., the self-healing and self-organizing nature of sensor networks.
Wireless sensor network has to operate for a long period of time without maintenance!
A wireless sensor network has to operate for a long period of time without maintenance.
For wireless sensor network’s operations, no operator is typically available to resolve any
problem. Maintenance and problem solution capabilities are restricted to remote
maintenance and resolution operations. Thus, the sensor networks are desired to have
basic functions such as self-maintenance, self-organization, redundancy and failure
tolerance. These functions are, in fact, based on the key concepts of sensor networks.
Without these embedded key functions, a sensor network-based product will have a very
difficult time to find its market in the real world.
Sensor networks are application-oriented/focused networks ultimately for human users!
Functions and services provided by sensor networks are quite diverse in many
applications and in various market segments. This diversity requires developing an
application profile to define an application’s requirements and operation concepts for each
sensor network application. In developing the application profile, the developer must
focus on the end-user of the system, typically the human users. As stated in the vision
statement in Chapter 2, the ultimate goal of sensor networks is “to improve quality of life
and change the life style.”
—————————
4 Ken Arnold, “Tutorial T11: Wireless sensor networks – An enabling technology,” Oceans 2003.
Technical Document of - 18 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
For example, the application profile for a subway station security monitoring network
should define types of sensor to be deployed (detectors for explosive, poisonous gas,
etc.), typical deployment locations, quantity of sensor nodes, information publish mode,
function and parameter set, etc. And the application profile should address how the
sensor network for the security monitoring system can benefit those people who use
subway stations in case of emergency.
5.2 Generic and Generalized Requirements of Sensor Networks
In this section, we will develop the generic and generalized requirements of sensor networks.
The generic requirements are captured from the commonalities and differences in the
applications described in Chapter 4 and Annex A. The generic requirements for various
sensor network applications are shown in Table 5-1. These generic requirements are then
generalized.
Generic requirements of sensor networks can be described from system and functional
aspects. The generic system requirements are considered to be generic for all sensor
network applications, while the generic functional requirements are used to realize specific
applications. The generic systems requirements are discussed in Section 5.2.1, and the
generic functional requirements in Section 5.2.2.
5.2.1 Generic and Generalized System Requirements (GSR)
The generic system requirements stated in this section can be considered as an “and” set;
thus, certain sensor network applications may not need to have some of the requirements in
this section. There could be additional generic system requirements that are not listed in this
section. The purpose of this section is to give the broad sense of the sensor network system
related requirements. Therefore, one should adopt and adapt these generic system
requirements to his or her target application. The sensor networks (SN) have the following
generic system requirements.
5.2. 1.1 Communication
SN-GSR 1. Sensor networks shall have communication ability between sensor nodes,
between sensor nodes and a gateway, between a gateway and another
gateway,
SN-GSR 2. One sensor network shall communicate with another sensor network.
Note: Sensor network communication can be performed by either wired or wireless
connections, or a combination of both connections. The communication ranges
can vary from short to long distances depending on situations and applications.
The data rate can vary from low to high data rates.
5.2.1.2 Security and Privacy
SN-GSR 3. Sensor networks shall ensure network security and user privacy.
Note: Security and privacy are of extreme importance for many of the proposed
applications of sensor networks. Standardization of security should provide
different security level for applications. And the privacy of users and user
information should be protected.
Technical Document of - 19 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Table 5-1. Generic requirements for various sensor network applications.
Sensor information Network Information Short Range Long Range Directory and
Latency time Throughput Scalability Lifetime Security Indication Localization
interface Processing coverage provision Comm Comm ID service
Theft EPC concept to
Less than 10 Simple Mobile Not more than a At least more
Prevention Global & 50 cm up to be used for Sustainability of
Local sec from alarm information network and few hundred than 3 month
System for Analogue district Low 10 or 20 identification of security algorithms Silent alarms A few meters
collaborative to indication at presentation SatCom nodes in a and up to
High Value covered meters node and at least 3 months
central PC to user systems cluster years
Goods product
Up to 300 Between some A few months
Local Processed Company
Industrial Between real Global & meters, in Internet, 10 and several up to years
Analogue collaborative Low, some rich specific Mid-high security Buzzer and
Automation in time and district some cases mobile 100 nodes, depending on A few meters
& digital and central times higher information identification level light signals
General several minutes covered up to some network sometimes order maintenance
processing presentation numbers;
kilo-meters of 10000 nodes cycles
Small Up to a
Less than a few Processed Sustainability of
Position and packages of Uncritical month LED for Resolution on
Analogue Local seconds District rich Up to 10 Mobile Directory and ID security defined by
Posture sensor data because only a without indication of room level is
& digital collaborative because vitally covered information meters network supporting system lifecycle
Monitoring and alarm few tags charging system status sufficient
important presentation (years)
messages batteries
Building Messages are
10 ms – 15 min Simple Internet, About 200 Sustainability of
Energy Analogue Central District inside transmitted as Up to 50 Some RFID or At least 2 Silent alarms
depending on information mobile nodes in a security algorithms A few meters
Conservation & digital processing Building a package and meters other concept years are sufficient
application presentation network building at least 3 months
System are small
Rich
At least 1
Tens of Rich information Computer
Parking Internet, Up to several year 24hrs
Analogue Central Less than 10 meters to Low data rate processed presentation Directory and ID Mid-high security Display and Less than 3
Management mobile thousands of on-duty time
& digital processing sec several transmission information and user- supporting level LED meters
System network nodes before next
kilometres presentation friendly indication
maintenance
interface
Less than 2 sec
EPC concept
from arrival to
Location could be used
Harbour pass the gate; Rich No more than a Sustainability of
messages are Internet, for identification
Freight Analogue Collaborative for less than 2 sec District processed Up to 200 hundred devices At least more one security Computer
transmitted as mobile of node and A few meters
Intelligence & digital local localization from location covered information meters on a shipping than 3 years session at least 3 Display
a packet or network product, and GB
System request to presentation yard months
short segment standards pre-
showing the
empt if available
location
Meter data Meter reading
Not more than
Automated must arrive Global & messages are Simple Internet, At least 10 years
Analogue Central 3 m up to 10 100 nodes in an Directory and ID At least 10 Computer
Meter within some district inside transmitted as information mobile sustainability for A few meters
& digital processing or 20 meters apartment supporting years Display
Reading minutes at the building small presentation network mechanism
building
master node packages
Small Tag to be
Management Not critical, 15 Rich EPC and or Up to 2 years Sustainability of
Collaborative packages Less than 50 Buzzer and assigned to
of medical Analogue minutes or 1 District processed Mobile equipment between two encryption
processing for containing Up to 3 meters devices in a optical rooms and
Devices in & digital hour is covered information network number of the maintenance mechanisms up to
localization position and cluster indication contexts (a
Hospitals acceptable presentation hospital events 2 years
condition data few meters)
Border Collaborative More than
Less than 5 sec High data rate At least 1
control and Multiple processing for tens of Rich
from intrusion transmission Internet, Up to tens of year 24hrs
virtual fences modality detection, hundred information Up to 200 Directory and ID Buzzer and
happening to supporting for mobile thousands on-duty time Several years A few meters
used as anti- sensor localization, nodes presentation meters supporting light signals
intrusion video image network nodes before next
intrusion supporting classification, covering 1~10 to user
detection sensors maintenance
systems and tracking Km distance
Technical Document of - 20 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
5.2.1.3 Robustness
SN-GSR 4. Sensor networks shall provide and maintain operational robustness.
Note: A sensor network should be able to keep working when some sensor nodes die or
leave the sensor network.
5.2.1.4 Scalability
SN-GSR 5. Sensor networks shall adapt dynamically to provide scalability for various
sensor network applications.
5.2.1.5 Quality of Service (QoS)
SN-GSR 6. A sensor networks shall provide quality of service (QoS) measures for the
services provided by the sensor network.
Note: Applications have different QoS requirements, such as data accuracy, reliability,
latency, etc.
5.2.1.6 Heterogeneity
SN-GSR 7. Heterogeneous sensor networks supporting an application or applications
shall have interoperability among the sensor networks.
Note: An application may consist of several different networks. The standards for the
interconnection of different networks for interoperability should be established.
5.2.1.7 Deployment & Coverage
SN-GSR 8. A sensor network shall provide information on deployment and coverage for
its prospective application.
Note: Application’s requirements for deployment and coverage are one of the most
important requirements for system implementation.
5.2.1.8 Mobility
SN-GSR 9. A sensor network with mobile sensor nodes shall support sensor node
mobility within the sensor network.
SN-GSR 10. A sensor network shall support the mobility of its sensor node to another
sensor network.
SN-GSR 11. A sensor network shall accept the transition of a sensor node from another
sensor network.
Note: Although not all applications have mobile sensor nodes, supporting mobility is very
important for some applications such as the applications in Intelligent Traffic
System.
5.2.1.9 Power/Energy Management
SN-GSR 12. Sensor networks with battery powered devices, e.g., sensor nodes,
gateway, etc., shall provide a power/energy management scheme.
Technical Document of - 21 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Note: Sensor network applications mainly powered by batteries need power/energy
management to optimize the sensor network’s operation life time.
5.2.2 Generic and Generalized Functional Capability Requirements (FCR)
Taking into account all the different applications which were introduced in Chapter 4 and
Annex A, there are many sensor network services that can be delivered by the sensor node as
well as the sensor network as a whole. These services are provided by functions
implemented in sensor network. In this section, we extract general functional capability
requirements for sensor networks.
Again, the purpose of this section is to give a broad sense of the sensor network functional
capability requirements. Therefore, one should adopt, adapt, and tailor these generic
functional capability requirements to his or her target application. The following list is only a
small number of the capabilities that can be realized by the sensor network.
5.2.2.1 Long Range Communication Service
SN-FCR 1. Sensor networks shall support long range communication capability for the
sensor data and services.
Note: For some applications sensor nodes have to “talk” with public communication
infrastructures like the Global System of Mobile Communication (GSM), Internet,
SatCom, etc.
5.2.2.2 Short Range Communication Service
SN-FCR 2. Sensor networks shall support short range communication capability for the
sensor data and services.
Note: Sensor nodes have to communicate with each other using energy efficient network
and data/communication protocols.
5.2.2.3 Clustering Services
SN-FCR 3. Sensor networks shall provide autonomous node clustering capability for
applications and power/energy management.
Note: Depending on the applications, autonomous clustering of sensor nodes is
necessary. The cluster concept is also used to level the energy consumption in
the entire network. Energy reservoirs in nodes have to scale down equally.
5.2.2.4 Routing Service
SN-FCR 4. A sensor network shall provide data/information routing capability from one
sensor node to another within the sensor networks.
SN-FCR 5. A sensor network shall provide data/information routing capability from the
sensor network to another sensor networks.
SN-FCR 6. A sensor network shall receive data/information packet through
data/information routing capability from another sensor network.
Note: Data/information or messages which have been created by application software on
the sensor nodes have to be routed from a node to another node to produce
information or to reach a gateway.
Technical Document of - 22 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
5.2.2.5 Installation Service
SN-FCR 7. Sensor networks shall provide all necessary application software
installation capability to support the sensor network or sensor node
functions required by target applications.
Note: A sensor node purchased from the manufacturer will be delivered without an
application software module in it. Sensor networks and sensor nodes have to
deliver a service which enables the installation of the functions on the sensor
nodes.
5.2.2.6 Security and Privacy Services
SN-FCR 8. Sensor networks shall ensure network security and protect data/user
privacy.
SN-FCR 9. Sensor networks shall provide privacy protection capabilities for users and
user information.
Note: There are many sensor network applications used in security environments.
Services on the sensor node have to make sure that the communication links, the
data storage as well as the application program on the node are secured.
5.2.2.7 Data Storage Services
SN-FCR 10. Sensor networks shall provide data storage capability.
Note: Data which comes from sensors in a sensor network has to be buffered in a
storage area. Data storage size depends on applications. Data storage or
buffering capability may be required.
5.2.2.8 Collaborative Processing Services
SN-FCR 11. Sensor network devices, e.g., sensor nodes, gateways, and other
computing units attached to sensor networks, shall provide collaborative
data processing capability when required by target applications and
services.
Note: Sensor nodes have to solve complex measurement problems in a cooperative way.
Intermediate results have to be calculated, communicated to other nodes,
compared with intermediate results coming from other nodes, etc. In order to do
the necessary calculations (e.g., sensor fusion), a data processing service is
required. Collaborative processing service concerns on how to fulfil dynamic tasks
specified by consumers.
5.2.2.9 Control Services
SN-FCR 12. Sensor networks and sensor nodes shall provide device control capability
for target applications that require an automated control of machines,
actuators, and servos.
Note: In some cases, sensor networks are used in applications where machines or servo
engines are controlled by a sensor node or sensor nodes. This task has to be
supported by special control services.
Technical Document of - 23 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
5.2.2.10 Linkage Services
SN-FCR 13. A sensor network shall provide linkage capability when a sensor node is
not physically attached to an object, ensuring that the sensor node and the
object are always associated during operations.
SN-FCR 14. A sensor network shall notify a sensor network operator, e.g., human
operator, when the link between sensor node and the associated object is
severed or disconnected.
Note: In applications where the sensor node is not physically part of an object but is
attached to one, it has to be made sure that nobody disconnects the two entities
without being notified. Especially logistics and security applications need a service
which guarantees a secure link between the sensor node and the physical object.
5.2.2.11 Orientation Detection Services
SN-FCR 15. A sensor node in a sensor network shall provide an orientation of a
physical object that is attached with the sensor node.
Note: For some applications, the relative orientation of a sensor node in space has to be
determined. A corresponding service has to be delivered by the sensor node.
5.2.2.12 Self-Localization Service
SN-FCR 16. A sensor network shall have the positional information of its all sensor
nodes so that the sensor network can provide sensor node positional
information as a capability.
SN-FCR 17. A sensor network shall be able to localize any sensor node within the
sensor network to provide the sensor node’s positional information as a
capability.
SN-FCR 18. The sensor node positional information shall be provided by an absolute
coordinate system in one of the standard reference frames that describe
three-dimensional space.
SN-FCR 19. The sensor node positional information shall be provided by a relative
coordinate system when the positional information of at least one sensor
network gateway or a sensor node is provided in an absolute coordinate
system in one of the standard reference frames that describe three-
dimensional space.
Note: Many sensor network applications need the location of the sensor nodes in the
sensor networks to work properly. Therefore, the sensor network has to be able to
determine the position of every sensor node and to hand the position information
to a gateway or master node. Manual configuration of sensor nodes locations
would be a very difficult task for large-scale networks or mobile sensor networks,
especially with a dynamic sensor networks where sensor nodes can leave or enter
a sensor network.
5.2.2.13 Monitoring Service for Communication Links
SN-FCR 20. Sensor nodes shall have capability to monitor status of communication
links to neighbouring sensor nodes.
Technical Document of - 24 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Note: In certain applications, e.g., the theft prevention scenario, the sensor nodes have
to monitor the communication links to the neighbouring nodes continuously. The
nodes therefore have to support monitoring services which can be called on by the
application module.
5.2.2.14 General Sensing Service
SN-FCR 21. A sensor node shall provide general sensing capability which consists of
operating the sensing hardware, transforming analogue measurements into
digital data, and supplying sensed data to the application module on the
sensor node.
5.2.2.15 Time Synchronization Service
SN-FCR 22. A sensor network shall provide time synchronization capability.
Note: Time synchronization service is one of the basic functions of the sensor network.
Almost all applications need time synchronization. Distributed wireless sensor
networks make extensive use of the synchronization service, but often have unique
requirements in the scope, lifetime, and precision of the synchronization to be
achieved, as well as the time and energy required to achieve it.
5.2.2.16 Identification Service
SN-FCR 23. Sensor network shall have a capability to identify all of its sensor nodes
within its sensor network
SN-FCR 24. A sensor network shall provide its sensor nodes’ unique identification code.
SN-FCR 25. A sensor node shall have its unique identification code.
SN-FCR 26. A sensor node shall provide its unique identification code when requested
by its sensor network.
Note: Sensor network applications need some mechanism to identify node which may
include node identification code, location, sensor information (sensor name, type,
for example), etc. For some applications, it is necessary to know a unique
identification code of the object to which the node is attached. For example, the
sensor node is required to operate a RFID reader and to hand the EPC or another
identification code to the application software on the node.
5.2.2.17 Data Entry Services
SN-FCR 27. A sensor node, for certain applications, shall provide data entry capability
which allows a human user to add information to the sensor node.
Note: In some applications, sensor nodes are attached to human beings. It might be
necessary that the human user gives information to the sensor node by keying in
information using a small panel. The information is then forwarded to the
application module on the node. The node has to deliver that functionality as a
service.
5.2.2.18 Indication Services
SN-FCR 28. A sensor node shall provide an indication capability to a human operator to
gain the operator’s attention.
Technical Document of - 25 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
SN-FCR 29. A sensor network shall provide an indication capability to a human operator
to gain the operator’s attention when its sensor node issues an indication.
Note: In some sensor network applications, the node is required to provide an indication,
e.g., alarm or warning, via a light-emitting diode (LED), acoustic alarm, etc. to gain
human operator’s attention for circumstances or situations that meet a pre-
determined sensing parameter or sensing parameters to initiate the alarm or
warning.
5.2.2.19 Display Services
SN-FCR 30. A sensor node shall have a capability to display the sensor node
information to a human user.
SN-FCR 31. A sensor network shall have a capability to display its sensor nodes’
information in order to communicate with a human user.
Note: Sensor nodes or sensor network may have to inform a human user by displaying
pictures, figures, or plain text. The sensor node has to be able to operate a
display to show information which has been generated by the application module
on the node.
5.2.2.20 Sensor Interface
SN-FCR 32. Sensor node shall provide standard sensor data interfaces that meets one
of sensor interface standards for the sensor resides within or attached to
the sensor node.
Note: Due to the diversity interfaces of various sensors, the standards need to be
developed to gather data/information among sensors, including analogue and
digital sensors and some interface protocols.
5.2.2.21 High Data Rate Communication Service
SN-FCR 33. A sensor network shall provide a high data rate communication capability
among its sensor nodes, and between sensor nodes and a sensor network
gateway for data exchange and transmission.
Note: In some application, high data rate communication service is required for vector
sensors (e.g., multimedia sensors) and for data exchange among gateway nodes.
5.2.2.22 Low Data Rate Communication Service
SN-FCR 34. A sensor network shall provide a low data rate communication capability
among its sensor nodes for data exchange.
Note: This is the normal service for data exchanging among sensor nodes within a region
of WSN.
Technical Document of - 26 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
6 Sensor Network Reference Architecture (SNRA)
In this chapter, we place a foundation for Sensor Network Reference Architecture (SNRA)
development. SNRA is generic and generalized reference architecture for sensor network
describing various, if not all, aspects of sensor networks. SNRA can be adopted and tailored
to specific application reference architectures. SNRA can also be the baseline information to
the implementation architectures, e.g., hardware architecture or software architecture, specific
to an application.
6.1 Introduction
In this section, we develop the need for system architecture 5 reflecting the generic and
generalized requirements of Sensor Networks (SN) developed in Chapter 5. The purpose of
system architecture development is to provide Sensor Network Reference Architecture
(SNRA) to depict the operational, functional, and technical commonalities captured from
Chapter 4, Annex A, and Chapter 5, subsequently, aiding the Sensor Network International
Standards (SN-IS) development.
SN standardization requires the evaluation and understanding of current SN’s applications in
various market segments – requirements, functions, interfaces, data types, and other related
factors. To effectively carry out this task, a systematic approach is necessary, such as
system architecture development process. The system architecture development process and
information can be found in Annex B. For generic and generalized sensor network system
architecture process will result in Sensor Network Reference Architecture (SNRA) which will:
Capture commonality in elements, components, modules, functions, etc., across many
SN applications, and also document differences among the applications;
Identify specific standardization need areas in SN, and also identify any existing
standards that could be applied to SN;
Visualize interfaces, data type, links between nodes, needed application layers,
service layers, data/communication layers, etc.;
Document the SN standardization process;
Provide SNRA that expresses the SN standards.
The SNRA is the baseline architecture to develop application-specific functional and
implementation architectures by tailoring SNRA. Since the system architecture development
procedure provides the co-incidence views of sensors, networks, data, and user interfaces
and interoperability simultaneously, the SNRA can provide:
Identification, evaluation, refinement, and validation of the generic requirements and
operational concepts;
Capture and document the commonalities and differences of the specific application
areas captured in Chapter 4 and described in Annex A;
Description of “AS-IS” generic sensor network;
—————————
5 ISO/IEC TR 14252 Open Systems Environment (OSE) and ISO/IEC 10746-1 Open Distributed Processing
(ODP) Reference Model can provide a general framework for architectural systems. As these two standards
are ISO standards, it would be appropriate to reference for sensor network architecture work.
Technical Document of - 27 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Development of “TO-BE” generic sensor network
Identification of key standardization areas in sensor network by acknowledging current
deficiencies, needs, and barriers.
Generation of SNRA that will provide developers the ability to design, analyze, and
tailor sensor networks of their interests
Iteration of operational concepts, requirements, SNRA, functional and implementation
architecture, and services will continue until it is brought to a convergence based on inputs
from SGSN members and other standards developing organizations (SDOs) involved in
sensor network standardization. Once the standards are established, the SNRA shall be
updated to reflect the sensor network standards. Then, SNRA shall be agreed and validated.
The SNRA with the sensor network standards will guide sensor and network designers and
manufacturers and service providers the following benefits:
Integrate new devices, software, and services efficiently (e.g., time and money) into
the existing sensor networks
Bridge gaps between different types of sensor networks
Enable an efficient and effective design of future sensor networks and applications
Share system data with stakeholders in other communities and application domains
Use the shared data to provide target services
Table 6-1 lists architecture frameworks used in industry. The table also shows the different
types of architectural views per architecture framework. These architectural views are the
descriptions of a system that is being or to be built from various perspectives of the system.
Table 6-1. Architecture framework used in industry.
Framework
Information Process Product Technology People Results
Name
Operational
View (OV), Technical
DoDAF OV SV --- ---
System View View (TV)
(SV)
Service
Data Business
Component Technical
Reference Reference
FEA RM Reference Reference --- ---
Model Model
Model Model (TRM)
(DRM) (BRM)
(SRM)
Data Applications Technology
FEAF --- --- ---
Architecture Architecture Architecture
Informational Functional Infrastructure Organizational
TEAF --- ---
View View View View
Data Application Technology Business
TOGAF --- --
Architecture Architecture Architecture Architecture
Technology
Zachman What How Where Who Why
Model
ISO/IEC Business Functional
--- --- --- ---
14662 Operational Service
Technical Document of - 28 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Framework
Information Process Product Technology People Results
Name
View (BOV) View
(FSV)
For the SNRA and Sensor Network standards development, Zachman Framework TM is
recommended because it creates the elements of the architecture in all aspects or views,
namely, information, process, product, technology, people, and results. In addition, the
Zachman Framework TM is neutral to a domain. From Zachman Framework TM element table,
shown in Figure 6-1, architectures can be developed for any framework (e.g., DoDAF, FEA
RM, FEAF, etc.) based on the information put into the Zachman element table. Figure 6-1
also shows the top-level description of Zachman Framework TM for enterprise architecture.
The use of Zachman Framework TM is a recommendation, and the actual choice of an
architecture framework will be left to the one or group who will actually work on the sensor network
reference architecture standards development.
Figure 6-1. Zachman FrameworkTM for enterprise architecture 6 .
6.2 Sensor Network Reference Architecture Element/Model/Case Description
In this section, we list the elements, models, and cases that need to be described and/or
developed in SNRA. These elements, models and cases are a preliminary list, and additional
ones may be added during the actual SNRA development. Some of models and elements can
be considered as the building blocks of the SNRA. Some of those listed is supporting
elements for SNRA. For example, “terminology” is a supporting element for standardization
which will be used in SNRA development unifying and promoting common meaning of the SN-
related terms and vocabulary used in the architecture views. Some of them can be described
by “use cases.” For example, “operational concept” can be described using use cases.
—————————
6 Use of Zachman Framework T M for Enterprise Architecture figure granted through a private conversation with Mr.
Tom Hokel of Zachman International, Inc. The framework is developed by Mr. John A. Zachman of Zachman
International, Inc.
Technical Document of - 29 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Building the actual SNRA models and elements is not performed under this study because it is
beyond the scope of SGSN. The contents of this section also maps to Chapters 5
(requirements) and 7 (recommended standardization areas).
(1) Terminology
The key SN terminology is listed in Section 2.3. The harmonization of the key SN
terminology may become necessary with the definitions from other SDOs.
(2) Requirements
The requirements (both system and functional) listed in Chapter 5 can be used as an
initial set for building SNRA. Additional generic and generalized requirements can be
found or derived during the SNRA development.
(3) Application profiles
To describe various basic and generic sensor network application profiles, SNRA
developers may need to develop a set of application profiles for SNRA, e.g., security
profile, industry control and monitor profile, intelligent mobility profile.
(4) Sensor Network Interface
Sensor network interface information should be established to provide the network level
data exchange between entities which will be described in SNRA. This interface is not
to be confused with interface standards of communications and networking.
(5) Interfaces
a. Sensor interface
Different types of sensors will have different interface types. In SNRA development,
each sensor type and its interfaces need to be determined in order to have
uniformity in the reference architecture development.
b. Data interface (data type and data format)
1-D data types and formats
1-D data types may include data from the following types of sensors: acoustic,
seismic, vibration, magnetic, infrared (light sensing – day or night),
electromagnetic (laser, radar), temperature, pressure, etc.
2-D data types and formats
2-D data types may include data from the imaging sensors of various kinds. The
data types may include: imagery (visual, infrared, and other spectra), video
(visual, infrared, and other spectra), electromagnetic (synthetic aperture radar,
SAR, inverse SAR)
3-D data types and formats
3-D data types may include data from sensors such as laser, more specifically
LIDAR and LADAR.
Technical Document of - 30 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
(6) Communications and Networking
Many aspects of communication and networking should be considered in the
development of SNRA
a. Networking
Networking will include network topology and data routing schemes for sensor
networks.
b. Various layers in Open System Interconnection (OSI) reference model 7 , e.g.,
physical layer (PHY), transport layer, etc., especially for PHY and MAC layers.
Adoption or adaptation of the existing communication or computer system
interconnection layers should be examined for sensor networks. They are already
used in sensor network domain.
Physical (PHY) Layer
Media Access Control (MAC) layer 8
Other layers
c. Inter-working with access and backbone networks
SNRA must consider the inter-working schemes or methodology in order to provide
data, communication, collaboration exchanges with other sensor networks, Internet
(e.g., web application and services), other types of networks (e.g., RFID network),
and backbone networks (e.g., service providers’ network, corporate enterprise IT
networks, etc.)
d. Protocols
There are existing protocols in wired/wireless communications and Internet which
are already used in sensor networks. The SNRA must consider these existing
protocols for sensor networks.
(7) Network Management
—————————
7 OSI Model from the website: http://en.wikipedia.org/wiki/OSI_model
OSI Model
Data Unit Layer # and Name Function
7. Application Network process to application
Host Data 6. Presentation Data representation and encryption
layers 5. Session Inter-host communication
Segment 4. Transport End-to-end connections and reliability
Packet 3. Network Path determination and logical addressing
Media
layers Frame 2. Data Link Physical addressing
Bit 1. Physical (PHY) Media, signal and binary transmission
8 MAC layer is a sub-layer of Data Link layer. See the OSI Model for Data Link layer in Footnote 6. Also see
Section 6.2.1 and Figure 6-4.
Technical Document of - 31 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
SNRA needs to address network management schemes and methodology. There are
existing network management schemes already in practice. SNRA development activity
should collect information on those existing network management schemes to be
considered for SNRA.
(8) Mobility Support
SNRA needs to address the dynamic nature of wireless sensor networks as sensor
nodes can roaming inside the sensor network, be dropped out from the sensor network,
and/or and sensor nodes from another network can join the network. Mobility support
will have to closely work with Networking and Network Management. The procedure in
autonomous reconfiguring of a sensor network, when sensor nodes move, drop, and/or
join the network, should be described.
(9) Collaborative Information Processing (CIP)
Collaborative nature of sensor network, e.g., data & information fusion, to provide
application and services dictate SNRA to address CIP. The CIP model entities may
include, are not limited to, capability declaration entity, collaborative strategy planning
entity, communication requirement specification entity, data and information description
entity.
(10) Information Service Support
SNRA will describe the information service support addressing the items below.
However, additional information service related area may be revealed during the SNRA
development.
a. Information description
b. Information storage
c. Identifier
d. Directory
(11) Quality of Service (QoS)
QoS can be viewed from at least two perspectives: Network and Information.
Regardless of the perspectives, the goal of service is to provide “right data/information
at the right time” to the user requested the data/information. QoS is discussed in detail
in Section 7.11.
Network perspective QoS, e.g., delay, throughput, etc., are well-known. However, these
traditional QoS may not be suitable for service-oriented sensor networks. Some
application level perceptual QoS, e.g., mean opinion score, image quality measure, are
much more meaningful QoS metrics for sensor networks. The new QoS metrics may
have to be developed during the SNRA development. The areas of consideration for
metric development are as follows, but not limited to:
Quality of information and decision: accuracy, resolution, value laxity
Quality of operation: energy per operation, lifetime
Technical Document of - 32 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Quality of Deployment: overall quality due to deployment affected by cost issue
Quality relation and requirements: open field to be explored
(12) Middleware and Functions
Although the development of middleware is not in the scope of SNRA, the middleware
and its functions are of interests as they play a critical role in having the sensor network
operational.
In Chapter 3, Figure 3-1 shows the four primary interfaces through middleware in
internal and external to a sensor node and also in a network gateway node to the “rest
of the world.” Although the SNRA does not address the interface inside of the
middleware, SNRA must address and define the interface between middleware and node
service layer, middleware and node hardware, middleware and node application layer.
The interface that allows node to node connectivity through middleware needs to be
addressed. In addition, interface between the gateway node middleware to the “rest of
the world” should also be defined.
(13) Security and Privacy
Security and privacy are very important and critical areas in sensor networks because
the failure of security and privacy affects not only the integrity of sensor network but
also the safety of the users, e.g., danger to physical body, misuse of personal data (e.g.,
medical, financial, personal identity data, etc.). SNRA properly address these issues
and should provide an architecture that ensures the security and privacy of sensor
network and the data/information from and to the sensor network.
a. Security of sensor network
Security should address the following items in terms of network (e.g., cyber attack)
and physical (e.g., physical intrusion or tempering).
Security technology
Security management
Security evaluation
b. Privacy of Sensor Network
The privacy is related to the data/information security and access control. In
addition, the privacy policy should be addressed in SNRA, which may involve legal
perspectives.
(14) Conformance and Interoperability Testing
SNRA also needs to address how the system can be tested for
conformance/compliance, interoperability, and performance. In fact, SNRA should
generate the test procedure with acceptable parameter ranges for these tests based on
the system and functional requirements.
a. Conformance testing (or compliance testing)
Technical Document of - 33 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
b. Interoperability testing
c. Performance testing
(15) Fault Tolerance
SNRA should include fault tolerance feature for sensor network operation. Sensor node
failure, gate node failure, external interference in wireless communication and data links,
and so on, should be considered in developing fault tolerant sensor network
architecture.
(16) Deployment and Installation
Deployment and installation is related to the actual implementation of sensor networks.
However, SNRA can address generic procedure in deployment and installation.
(17) Sensor Network Coverage
SNRA also provide variability in sensor network coverage as different applications have
different requirements for its coverage. For example, SNRA must include architectural
features in extending sensor network coverage for use by such applications.
(18) Power Sources and Management
SNRA can state power source requirement in general for generic applications. SNRA
should include power management methodology that can be adapted by the sensor
network developers and implementers.
(19) Operations
Although operations can be generically described in SNRA, it may not realistic.
Therefore, operations discussed in use cases handling application-specific operation
perspective. The following items in operation should be addressed in the use cases.
a. Operational concepts
b. Operational computation (processing algorithms)
c. Operational lifetime
d. Operational efficiency (power & energy management)
e. Operational environments (remote, unattended, factory floor, etc.)
(20) ~ilities
The following so-called “~ilities” needs to be addressed by SNRA. In developing SNRA,
the aspects of the items listed below should be addressed as they are important features
of sensor networks related to the key requirements and key performance parameters.
a. Scalability
b. Programmability
Technical Document of - 34 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
c. Maintainability
d. Survivability
e. Interoperability
f. Reliability
6.2.1 Sensor Network Reference Architecture Views and Artefacts
Sensor Network Reference Architecture (SNRA), describing generic and generalized sensor
network services, is an architectural representation of sensor network entities’ (e.g., sensor
nodes, gateway nodes, and other hardware in the node) functions, activities, and roles
through operation layer and interoperable interfaces to provide the SN developers and
implementers with reusable sensor network architecture for their target applications.
Figure 6-2 shows the high level graphic that depicts the customer as the top layer of any
sensor network. The sensor networks exist to serve the consumer or customer. To be able to
access the sensor network in a service-oriented application, the access services handles all of
the system access for both man and machine. This service is the gateway from the outside
world into the sensor network. It could be an open door or restricted.
Business services 9 explain the processes that the sensor network employs to provide the
services requested. The business services could have tasking service, collection service,
production service, and publishing service as shown in Figure 6-2. As we do not live in a
world with unlimited bandwidth and sensors cannot sense multiple objects of interest in
different areas, the tasking of these sensor networks must be a priority. Based upon the
tasking and the sensor type, the data must be collected and stored in a repository for system
use. This collected data could be raw data from the sensors or pre-processed data, or even
predefined processing could take place at the sensor and stored in the repository. The
production service is the area where fusion, exploitation, and end-to-end processing take
place. In a service oriented application, publish as subscribe is a request and delivery
method that allows the consumer the ability to monitor information on specific areas of interest
(AOI).
Management Services are where security, storage, data management, etc. allow the service-
oriented application to provide the services for the enterprise.
—————————
9 The majority of the geospatial sensor standards activities are driven and focused on the business and
management layers, refer Figure 6-2. More specifically, within these layers of the reference architecture, the
functionality of Sensor Web includes:
Discovery of sensor systems, observations, and observation processes that meet the immediate needs
Determination of a sensor capabilities and quality of measurements
Access to sensor parameters that automatically allow software to process and geolocate observations
Retrieval of real-time or time-series observations and coverage in standard encoding
Tasking of sensors to acquire observations of interest
Subscription to and publishing of alerts to be issued by sensors or sensor services based upon certain
criteria
The Sensor Web framework and architecture is described in some detail in a Best Practice document located at
http://portal.opengeospatial.org/files/?artifact_id=29405. The architecture and application work of the
geospatial community seems to be complementary to that of sensor networks. It is recommended to review the
geospatial community work for sensor network architecture work.
Technical Document of - 35 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Figure 6-2. Sensor Networks high level operational graphic.
Figure 6-3 shows the entities that are depicted in “Management Services” layer in Figure 6-2,
the high-level operational graphic, illustrating the entity (or node) connectivity. Thus, Figure
6-3 is called an entity or node connectivity diagram. This figure is an example on an
instantiation, and this does not represent or intend to be comprehensive, encompassing all
sensor network applications. The purpose of this type of architecture diagram is to show the
need of information exchange among the entities in sensor network system.
These types of architectural artefacts or diagrams show: who needs to exchange information,
whom to exchange, and what information needs to be exchanged. Each of the need-lines
(lines that show information need) carries multiple information exchanges. Each line carries
all of the information exchanges between the entities in the diagram. For example, the
Enterprise Service node has a need to exchange “Information to Post” to the Service
Manager. Contained in this need-line could be status on a request, or sensor status. It could
contain a message with the location of the data requested by a user, or it could push data to a
user depending on the request. After all this type of diagrams supports the function, activity,
and role of the entities described in the high-level graphic (Figure 6-2) and their need to
exchange information.
Technical Document of - 36 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Figure 6-3. Sensor networks entity/node connectivity diagram – an instantiation.
Figure 6-4 describes system activity for sensor node cluster control, which is a lower level
description using the Open System Interconnection (OSI) stack and how data flows through
the stacks from application layer to physical layer. This figure shows the architectural block
diagram on the top portion of the figure, and the lower portion of the figure shows the layer
and routing connectivity among the entities shown in the upper diagram. The physical layer P
is the hardware connectivity between sensor nodes on the network. The Data Link layer is
divided into two layers: the Logical Link Layer and the MAC Layer. The Data Link Layer
provides the functional and procedural means to transfer data between network entities and to
detect and possibly correct errors that may occur in the Physical Layer. The Logical Link
Layer is seldom used today except for X.25 protocol.
Figure 6-4. SN system description for sensor node cluster control – an instantiation.
Technical Document of - 37 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Figure 6-5 focuses on the application layer and the sub-layers that are created to service
multiple applications, e.g., theft protection, temperature monitoring, and sensor data
processing, as shown in the figure. This application layer interacts with software applications
that implement data/information communications. These application programs fall outside the
scope of the OSI stack. Application layer functions most often include identifying
communication partners, resource availability and management, and synchronizing
communication. The sensor network and sensor management will interface with this layer of
the OSI stack. This figure also shows the control hierarchy with numbers where “1” being the
top level in the hierarchy. It also lists some management entities in Service Layer, e.g.,
Communication Management, Data Management, Security Management, and Group
Management. The Basic Function Layer lists its entities such as network communication,
sensor driver, and clock. With these layers, the sensor node function sub-layers are
connected with Control/Collaboration Sub-layer through Application Layer and Service Layer.
Thus, this type of architectural diagram shows the SN network architecture from a view of
involved layers and their functions, activities, and roles.
Figure 6-5. Sensor networks systems architecture – Layer focused.
Figure 6-6 describes service and functional connectivity between the SN Application Layer
and Communication Network Layer. The figure shows all involved layers and sub-layers, their
purpose and what each layer’s part is in the sensor network communication process. This
figure is limited to the networking between sensors. The external nodes would also reside
above the Control/Collaboration Sub-layer. Thus, this figure is a different view of the SN
system architecture focusing on the layers compared to Figure 6-5.
6.2.2 Sensor Network Device – A Sensor Node or Sensor Network Gateway
In this section, we describe a sensor network device – sensor node and sensor network
gateway – in detail from the node layer and their functional entities point of view. Thus, this is
one of the architectural views of the sensor network device.
Technical Document of - 38 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Figure 6-6. Services/functionalities cut-across sensor networks layers.
6.2.2.1 Description of Sensor Network Device
From the layer architectural views, the sensor network device consists of:
three layers
o Application Layer
Application layer has the target application module(s) for the sensor node as
shown in the figure, e.g., theft protection, temperature monitoring, sensor data
processing. Depending on applications, the modules in the application layer can
be complex.
o Service Layer
Service layer has the services that are provided to the sensor network device itself
as well as to the external entities. These services are provided by communication
management, group management, data management, security management,
localization service, etc.
o Basic Functions Layer
Basic functions layer has the interfaces to physical connectivity such as network,
driver, clock, and other hardware (e.g., sensors and actuators) that support the
sensor node functionality.
a device management entity
The device management entity provides the functional services such as program
management, identification, and node resource management, and other functions.
Technical Document of - 39 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
These layers and entity along with the function blocks in each layer and management entity
are illustrated in Figure 6-7. In the following sections, we discuss each of the layers in Figure
6-7 in detail.
Sensor Network Device: Sensor Node & Sensor Network Gateway
Application Device
Layer Theft Temperature Management
Protection Monitoring Entity
Service Program
Group Security Management
Layer
Management Management
Identification
Communication Data Localization
Management Management Service
Basic Functions
Layer Network Resource
Sensor Driver Clock
Communication Management
Figure 6-7. Operation layer view of sensor node device.
6.2.2.2 Basic Functions Layer (BFL)
The Basic Functions Layer (BFL) consists of components which address the physical world.
The components are communication protocol stacks and drivers for interfaces, sensors,
actuators, etc. The components of the BFL offer standardized interfaces to the other layers
and the Device Management Entity. Table 6-2 shows SNRA’s basic functional areas for BFL
and corresponding components per each functional area.
Table 6-2. SNRA Basic functions layer components
Functional Areas Components
Interface to physical networks
Sensor interface Interface to sensor buses
Interface to sensor data
Interface to physical networks
Actuator interface
Interface to control actuators
Protocol stacks (comprising PHY, MAC, DLL, NWK)
Stateless or state auto-configuration
Mesh network establishment and management
Network topology management
Routing protocol
Network communication
Topology management
Routing table management
Network information reconfiguration
Reliable data transmission
Unreliable data transmission
Clock Real time clock
Technical Document of - 40 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
6.2.2.3 Service Layer
The Service Layer consists of components which offer generic services and management to
support applications. The services may use interfaces of the Basic Functions Layer (BFL)
components and can interact with other services. Table 6-3 shows the SNRA’s basic
functional areas for Service Layer and corresponding components per each functional area.
Table 6-3. SNRA Service layer components.
Functional Areas Components
Intra-area (e.g., WPAN) mobility function
Inter-area mobility function
Mobility Management
Network mobility function
Service mobility function
Establishment of Groups
Group Management
Group Communication
Service registration
Service discovery
Service description
Service Management
Service analysis
Service processing queue
Management of object identification
Topology management
Routing table management
Network information reconfiguration
Network management
Performance management
Configuration management
Time synchronization
Authentication
Authorization
Encryption
Security Management
Privacy protection
Key management
security routing mechanism
Data acquisition
Data compression
Data storage
Data sharing
Data synchronization
Data Management
Data directory
Data aggregation or fusion
Capability declaration entity (CDE),
Collaborative strategy planning entity (CSPE)
Communication requirement specification entity (CRSE)
Localization algorithms
Location table
Localization Service
Area Management
Neighbourhood table
Event generation
Event Management
Event filtering
QoS Management Admission control
Address conversion
Protocol Conversion
Protocol conversion
Technical Document of - 41 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
6.2.2.4 Application Layer
The sensor network applications are specific for each market segment and the needs of the
users in that market. The applications may use standardized interfaces of components of the
Service Layer, the Basic Functions Layer and the Device Management Entity.
6.2.2.5 Device Management Entity
The Device Management Entity manages the device resources. Table 6-4 shows the SNRA’s
basic functional areas of the Device Management Entity and corresponding components per
each functional area.
Table 6-4. Sensor network device management entity components.
Functional Areas Components
Power control
System management Start-up and shutdown
System parameter reconfiguration
Identification Sensor node identification
Program Management Migrating and updating of programs or components
Managing the node resources (e.g., memory, processing ability)
Resource Management
Energy Management
6.2.2.6 Service Access Points (SAP)
Within the sensor network device each component offers its services via a service access
point to other software modules. This is illustrated by the yellow arrowed in Figure 6-8.
Sensor Network Device: Sensor Node & Sensor Network Gateway
Application Device
Layer Theft Temperature Management
Protection Monitoring Entity
Service Program
Group Security Management
Layer
Management Management
Identification
Communication Data Localization
Management Management Service
Basic Functions
Layer Network Resource
Sensor Driver Clock
Communication Management
Figure 6-8. An example of component interconnections via service access points.
Technical Document of - 42 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
7 Recommended Sensor Network Standardization Areas for ISO/IEC JTC 1
Many new sensor network applications and services are emerging in market places. The
benefit of having situational and context-aware information and knowledge from sensor
networks not only will add more values to sensor network developers and users, but also can
provide better business opportunities to those who are involved in sensor-integrated
applications and services business. Some of the market places where the sensor networks
have been or will be effectively used include, but are not limited to logistics, home automation,
military, health care, environmental control and utility use management, civil engineering,
precision agriculture, transportation; and other areas. A more comprehensive list is found in
Table 4-1 in Chapter 4, and the application examples are described in Annex A.
Due to the diversity of sensor network applications, the trade-off between the specialty and
universality should be carefully considered in identifying the sensor network standardization
areas. The standardization areas of sensor networks can be divided largely into two parts:
the fundamental platform standards and the application profiles as shown in Figure 7-1.
Figure 7-1. Fundamental platform standards framework and applications for SN.
Based on the common characteristics and technology requirements for different sensor
network applications, the fundamental platform standards consist of standard areas such as
terminology, interface, communication and information exchange, collaborative information
processing, information services, security and testing. According to the specialty of specific
applications, the application profiles are intended to describe various application modes,
scenes, functions, node deployment and so on.
For each application profile of interest, the target application can be customized by tailoring
the requirements (and also the architecture artefacts) provided by each of standards areas in
Technical Document of - 43 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
the fundamental platform standard box in the figure. The fundamental platform standard box
is closely related to the Sensor Network Reference Architecture (SNRA).
Sensor networks and their applications/services have many technical issues to be tackled for
standardization. The standardization areas and SN applications in Figure 7-1 do not
encompass all SN standardization areas and applications. This figure is representative, but it
is not exhaustive or comprehensive.
7.1 Terminology
The key terms in sensor networks require the discussion to give them the clear definition.
This specification could be a part of ISO/IEC 2382 (Information Technology Vocabulary)
series standards.
7.2 Requirement Analysis
Requirements analysis is to extract service features and required functions from various
sensor network applications and services. Sensor network applications have the vertical
market characteristics and many functional capability requirements may be clarified by
analyzing sensor network applications and services. Therefore, the following studies should
be performed:
Analysis of sensor network application models and scenarios;
Analysis of service requirements and functional capability requirements in terms of
PHY/MAC, sensor networking aspects, inter-networking aspects, and application layer
issues; and
Analysis of further development and relevant standardization items.
Some of the generic and generalized sensor network system level requirements and
functional capability requirements are listed in Chapter 5.
7.3 Reference Architecture
Reference architecture for sensor network system, network configurations and interface
relationships needs to be developed because a variety of sensor network applications and
services can be established by many alternative networking approaches, middleware, and
application functions. Chapter 6 addresses the sensor network reference architecture
(SNRA).
7.4 Application Profiles
Application profiles’ specifications are required. Because sensor network applications are in
vertical market domain, each sensor network application will likely have unique requirements.
A sensor network application/service needs an application profile to define its service
features, processing functions, interface procedures, operation attributes, attribute values,
etc.
7.5 Interface
7.5.1 Sensor Interface
Due to the interface diversity within similar types of sensors and also among different types of
sensors, the sensor interface standards need to be developed by gathering and studying the
interface information. The interface information can be gathered from the sensors in the
market and those sensors under development using emerging technologies. Many analogue
Technical Document of - 44 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
and digital interfaces are widely used in sensor- and network-related applications, such as 4-
20mA, 0-5V, SPI, RS232, etc. At present, there exist some intelligent sensor interface
protocols, such as IEEE1451.x protocols and OGC Sensor Web interfaces.
7.5.2 Data Type and Data Format
Because of the diversity of sensors and applications, many types of data in different formats
should be digested by sensor networks. The diverse data types include, but are not limited to,
audio, video, graphics and text, and so on. All the data should be encoded/decoded or
described in different ways, such as MPEG, JPEG, ASN.1 and XML, etc. Additional details of
the data types are listed in Section 6.2.
Studying and understanding data types and formats are to develop generic and generalized
data interface definition that provides logical connections between components in the basic
function layer, service layer and application layer in the sensor network device, e.g., sensor
node and sensor network gateway as discussed in Section 6.2.2. There are other types of
data to be standardized, which is addressed below. We do not claim the list below is
complete and exhaustive. As the further study or actual standardization will be performed in
the future, and additional types of data may emerge.
Sensor Node Metadata: Sensor data interface describing the format of data about a
sensor node, e.g., sensor node metadata, including sensor type, measurement unit
type, node or sensor identifier, measuring phenomenon, e.g., temperature, humidity,
pressure, and so on;
Service Metadata: Sensor network service data interface describing the format of data
related to services. e.g., service metadata, including service type, service information
(e.g., requested time/date, delivery time/date, etc.), service management information
(e.g., configuration, etc.), and others;
Application Metadata: Sensor network application data interface describing the format
of data related to applications, e.g., application metadata, including sensor network
application type, application information, e.g. position, alarm status provided to users.
Basic Function Metadata: Sensor network basic functions interface describing the
format of data related to basic functions, e.g., basic function metadata, including type
of sensor network basic function performed, type of information generated resulting
from the basic function performed, e.g., communication, sensor drive and clock, and
so on.
In addition to the raw data from sensors, the intermediate data/results produced by data
processing modules, entities and/or layers should also be handled in sensor networks. These
data can be classified into different data levels, for example, raw data, feature data, and
decision data levels. The identification and format of these data levels should also be
consider in sensor networks.
7.6 Communication and Networking
From the viewpoint of network, standards for physical layer, MAC layer, network layer and
access to backbone network should be established. Network protocols for sensor networks
need to be self-organizing, self-configurable, robust, and scalable. There are many
communication standards covering these areas, and some of them are already used in sensor
network applications. Those standards should be examined and considered for adoption and
adaptation for sensor network applications.
Technical Document of - 45 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
7.6.1 Physical Layer (PHY)
PHY defines the means of transmitting raw bits rather than logical data packets over a
physical link connecting sensor network nodes. The PHY may consist of a set of technologies
which may be standardized according to the different requirement of sensor networks,
including, but not limited to, frequencies to broadcast, modulation scheme, short distance
communication scheme, long distance communication scheme, low data rate and high data
rate, etc.
Sensor nodes may be connected by wired or wireless means. There are many wired
communication techniques and standards such as RS-232, RS-422, RS-423, RS-485, PLC,
HFC, CAN, Ethernet, etc. There are various wireless communication techniques and
standards such as IEEE 802.15.3, IEEE 802.15.4, Bluetooth, Binary CDMA, WLAN, etc. But
new wireless networking techniques are still being developed to meet new challenges of
evolving sensor networks. Thus, the PHY standards should consider the emerging
technologies in data communication techniques which interconnect sensor nodes, gateways
and enterprise networks.
7.6.2 Media Access Control (MAC)
MAC supports a logical abstraction of physical network properties to higher layers. It provides
addressing and channel access control mechanisms that make it possible for several sensor
nodes to communicate within a multi-point network. Compared to other networks, wireless
sensor networks have additional limitations in terms of power, bandwidth, operation condition,
etc. Such limitations impose challenges that require energy-efficient MAC layer technical
solutions. Existing MAC protocols do not solve this limitation; therefore, current MAC
approach has to be extended or new MAC technology solutions should be developed to
support efficient sensor network operation. The following work items to improve MAC are
prospective solutions:
Extension of existing MAC protocols such as CSMA/CA, Dynamic TDMA, S-MAC, etc.
Sleep scheduling protocol
Channel access control mechanism
Flow and error control mechanism
Multiplexing mechanism
7.6.3 Networking
Networking corresponds to how to build a sensor network over PHY/MAC and may consist of
a set of technologies which may be standardized. Compared with wired sensor networks,
wireless sensor networks have more limitations in terms of power, bandwidth, operation
condition, etc. Such challenges may require new technical solutions:
Auto-configuration of network information
Address resolution between network and MAC addresses, such as ARP
Transmission of note-to-node data unit, such as IP, ZigBee network layer, etc.
Transmission of end-to-end data unit, such as TCP, UDP, ZigBee Application Support
Layer, etc.
Technical Document of - 46 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Implementation profiles for IP networking standards
Standards package to set up non-IP sensor network
Time synchronization and localization among sensor nodes and sensor gateway
Inter-networking between non-IP and IP sensor networks
Inter-working between different protocol families in terms protocol procedures,
message formats, application profiles, etc.
Supporting mobility including intra-mobility, inter-mobility, network mobility and service
mobility
As sensor networks have specific requirements on energy saving, data-oriented
communication, and inter-connection between non-IP and IP, sensor network-dedicated
routing protocols may be required, for examples:
Energy efficient routing scheme;
Routing schemes to handle nodes in sleeping mode;
Data-aware routing scheme; etc.
Routing protocols may depend on a sensor network solution. For example, ZigBee developed
an AODV (Ad-hoc On-demand Distance Vector) derivative for its network routing. IETF
6LoWPAN is studying about routing requirements. IETF ROLL (Routing Over Low power and
Lossy networks) has just started its research activity on routing protocol requirements to
enable L3 routing and reuse of existing IP routing protocols at its first meeting at IETF-71,
held in Philadelphia, USA, March 9-14, 2008.
In wired networks, generic cabling infrastructure for networking should be considered for wired
sensor networks which may be a stand-alone network serving a specific purpose or purposes;
or it could be part of a larger network which has several wired networks and wireless sensor
networks. Wired cabling standards have been studied and developed in JTC 1 SC 25 for
home and offices addressing cabling for wired connection among sensors, sensor-to-sensor
nodes, and sensor nodes to outside networks. This standards work in cabling can be further
explored and extended to the wired sensor network beyond home and offices. In addition to
the JTC 1 SC 25, the standards from IEC TC 65 also cover many wired and wireless sensor
networking for the industrial applications. Some of these standards are listed in Annex E.
7.6.4 Inter-working with Access and Backbone Networks
Sensor networks are usually connected to communication infrastructures for large scale
application. Accesses to communication infrastructures has to provide wired (e.g., Ethernet)
or wireless (e.g., mobile Ethernet via WLAN, UMTS or SatCom) interface to the
infrastructures. The special translation protocol and application programming interface in the
gateway of sensor network is the most important modules to be standardized in order to
support different applications by the sensor networks
7.7 Network Management
Sensor networks have new functional elements which have to be managed. Existing
management protocols don’t support them but the existing ones have to be extended or new
technology solutions may be developed. Following work items are prospective solutions:
Technical Document of - 47 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Extension of existing network management protocols such as SNMP, ZigBee Network
Layer Management, etc.
New network management protocol
Topology management protocol
Inter-working with different management protocols
7.8 Mobility Support
Mobility in wireless sensor networks , which means Network Dynamics, can be divided into
four main different areas, included in the group of network dynamics: Gateway Mobility, Node
Mobility, User Mobility, and Phenomenon (or Information) Mobility. Figure 7-2 graphically
shows the four areas of sensor network’s dynamic mobility.
Figure 7-2. Mobility in sensor networks.
The main objective of gateway mobility is to avoid the high cost of maintaining long multi-hop
paths. The sink supports the movement across the network, increasing the coverage and
decreasing the multi-hops to reach each node.
The node mobility is associated with movement, caused by any external power (e.g., wind or
water), or as a characteristic of the own node. Node mobility can be achieved natively or by
attaching to a mobile body. Independence of how the mobility is caused, node mobility can
increase the network coverage. With having energy-conservation algorithms (e.g., intelligent
power management, efficient computing algorithms, etc.), the network with mobile sensor
node is capable of providing its coverage for the largest possible area.
Sometimes the environmental phenomenon also presents some type of mobility. Others times
the user is mobile. Although, the mobility of users can be considered from different points of
view, it is divided into two main types. The first type considers the existence of a traditional
infrastructure network so that the mobile user can connect the gateway node through any
external point (like in the Internet). The second type is independent of the application:
Considers a non-infrastructure network, where mobile users can walk freely within the sensor
field, allowing the direct communication between nodes and users, without the intervention of
the sink node.
The specific case of node mobility can further categorized in two sub-groups:
Technical Document of - 48 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
A sensor node moves within sensor networks, called an intra-sensor-network mobility
A sensor node moves across multiple sensor networks, called an inter-sensor-network
mobility
We consider a network as a set of interconnected nodes sharing a common identifier, e.g., a
network ID or a network address prefix. All nodes are able to communicate with each other,
considering that all are on-link. Nodes can perform intra-mobility when they are moving but
remaining within the common identifiers or inter-mobility when new global identifiers are being
acquired along the path.
How the mobility support requirements are satisfied will depend on sensor networking
technologies. That is, IP-based sensor networks can be supported by existing IP mobility
technologies which have been developed at IETF. On the contrary, non-IP based sensor
networks have lack of studies yet on the mobility issues.
7.9 Collaborative Information Processing
Sensor network based information service system can be conceptually viewed from two
different perspectives: (1) information service consumer perspective and (2) information
service provider perspective. Information service consumer defines its requirements with
service specification entity, and information service provider implements these services by
using available sensory data and network resources.
Collaborative information processing (CIP) concerns how to effectively, efficiently fulfil tasks
specified by information service consumer with constraints in energy, computing, storage and
communication bandwidth. It also deals with technical challenges from issues such as task
dynamics, measurement uncertainty, node mobility and dynamic nature of the environmental.
CIP is one of the essential areas for sensor network standardization. It can be modelled with
three distinct entities, which are capability declaration entity (CDE), collaborative strategy
planning entity (CSPE) and communication requirement specification entity (CRSE).
Functional relationships among these entities are shown in Figure 7-3.
Capability declaration entity (CDE) declares capabilities of one sensor node to other nodes.
Collaborative strategy planning entity (CSPE) forms global or regional maps or scopes on
signal and information processing problems. With certain cost functions or utility measures,
CSPE finds a resource-efficient solution to achieve preferred information processing
performance. Communication requirement specification entity (CRSE) acts as interface
between information service provider and Communication and Information Exchange, refer the
figure for Communication and Information Exchange. CRSE defines parameters, languages
or protocol requirements on Communication and Information Exchange. Data flow in CDE,
CSPE, and CRSE processes need to be standardized.
7.10 Information Service Supporting
Information service supporting includes information description, information storage,
identification, and directory service. These topics are discussed in the sections below.
Technical Document of - 49 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Figure 7-3 Collaborative information processing (CIP).
7.10.1 Information Description
Specific information communicated among the nodes in a sensor network should be defined
and described exactly by the standards. The defined information is the basic requirement for
interoperability for the sensor network. The information can be described by existing
description language or notation, such as ASN.1 (ISO/IEC 8824 and ISO/IEC 8825serial
standards) and XML (W3C XML) specification.
7.10.2 Information Storage
The data/information storage attached to sensor networks, e.g., local storage at a sensor
node or at a network gateway, typically results in storage-constrained sensor network
applications. For such sensor network applications the measured data can typically be stored
by using an adaptable data resolution approach. This approach can reclaim storage spaces
by reducing the quality of stored data (e.g., coarse resolution vs. fine resolution of data by
varying data sampling frequency or by down-sampling a higher resolution data), which
compromises the precision. Compression of sensor data, correlation of the data, and
detection and cueing of events are three important areas in information storage for certain
applications.
7.10.3 Identification
Different types of identifiers should be defined and specified for sensor networks, e.g., sensor
node identifier, sensor node type identifier, information identifier, information type identifier,
application type identifier. The identifiers can be specified based on the existed identifier
standards, such as OID (ISO/IEC 9834 series standards), URI (RFC 3986), and URN (RFC
2141).
7.10.4 Directory Service
There are two directory service issues being discussed:
Technical Document of - 50 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
(1) A globally unique identifier may be assigned to every sensor node for management or
other purposes. Thus, the association between identifiers and relevant data/information
should be maintained all the time by a directory service.
(2) The other one is related to information service directory. Sensor data is collected
associated with a database system and processed properly using a context-based rule
sets for value-added services. The results from this processing are then exported into
information service repositories with which the database’s directory service. This directory
service provides how to find a specific data/information and deliver to end users. This
type of service directory is often found in public sensor network information services.
The information among the nodes in the sensor network should be assigned in the database
by the suitable directory which is important for finding the information easier. The directory
specification for the sensor network can be based on Directory standards (ISO/IEC 9594
series standards).
In sensor network applications, especially in dynamic environments, e.g., sensor node
mobility, web discovery of sensors and data, semantics and discovery are the two topics that
need to be addressed and discussed for the sensor network directory service standards
development.
7.11 Quality of Service (QoS)
Sensor network applications and services, whether mission-critical, time-critical, or general
purpose, should be managed based on the sensor network’s efficiency in performing the
requested task(s). To measure “efficiency” and “performance” of a sensor network, types of
quantitative metrics should be developed. These quantitative metrics are the measures of
QoS. However, developing “right” QoS metric is a very challenging technical problem.
Different applications require different QoS metrics and approaches. Thus, we categorize the
sensor network applications into three classes according to their data delivery model. These
three application classes are (1) continuous applications, (2) event-driven applications, and
(3) query-driven applications, as shown in Figure 7-4.
The continuous class represents applications that require sensor nodes to periodically report
their data to the sink node. In this class, real-time and non-real-time data may be included.
Examples are real-time voice or image from sensors, real-time continuous measurements of
any real parameter (e.g., temperature) and periodic data (non-real time) from the sensors in
the field.
The event-driven class are found in event-driven applications, i.e., applications that only send
data when a predefined event occurs. Examples are high temperature alerts from nodes and
gas leaks detection by nodes.
The query-driven class represents applications that only respond to queries made from other
nodes or by the sink. Examples are video surveillance WSANs, global positioning retrieval
from nodes and all the non-periodic data retrieval from nodes.
Although not included in the figure, a fourth class, a hybrid class, may also be added,
representing a mix of all the other three classes. This fourth class will not be considered in
the taxonomic analysis.
Technical Document of - 51 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Figure 7-4. Application data delivery model.
Conceptually, QoS in the sensor networks should be viewed from two different perspectives:
(1) the communication perspective; and (2) the information processing perspective. The
reason why we should consider QoS from the information processing perspective is that the
sensor networks are not just communication systems for information exchange. But the
sensor networks act as information systems to acquire, process, provide information or
knowledge from the physical world to the user.
Traditional QoS parameters like delay, jitter, bandwidth, or packet loss (from the
communication perspective) are not enough to characterize and quantify the needed
performance requirements of a sensor network. These networks, due to their nature, have
specific constraints and requirements. On the other hand, QoS parameters that characterize
the quality and the performance of the obtained information should be defined. Example
metrics in this perspective includes information gain, efficiency, and other application-specific
information metrics such as false alarm rate (FAR), correct target classification, target
localization error, etc.
To classify the QoS requirements, a taxonomic approach is presented as shown in Figure 7-5,
including typical performance measures and Network Dynamics, Security and Privacy,
Performance, Deployment and Coverage, as part of an overall performance measurement of
sensor networks. The aim using taxonomy analysis is to make these areas a target of specific
QoS measures, suitable to classify the service that can be supplied by the sensor networks,
including QoS.
Also, sensor networks demand new collective performance parameters. These new set of
requirements result on the fact that information is not only be generated from a single node,
but, some times, also from the contribution of many nodes in the network, e.g., CIP. In a
data-gathering application, collective packet loss would be the sum of individual packet losses
from all the sensor nodes that sent data at a specified time. Collective delay is the difference
between the time when the data was obtained and the time when the last packet arrived at the
sink form all designate sensor node for a given period of time.
Technical Document of - 52 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
QoS
Requirements
Information Communication
Processing Processing
Information Information Application- Network Security and Quality of Deployment Coverage
Gain Efficiency Specific Dynamics Privacy Performance
Metrics
Energy Gateway Authentication Accessibility Random Space
FAR Mobility / Availability
Resource Non- Controlled Time
Efficiency Classification Node repudiation Delivery
Mobility
Localization Confidentiality Accuracy
Error User Mobility
Integrity Latency
Phenomenon
Mobility Access Bandwidth
Control
Reliability
Availability
Accountability
Figure 7-5. Taxonomy analysis of sensor network QoS.
7.12 Middleware Functions
Middleware functions represent a set of functions commonly required by sensor network (SN)
applications and SN functions. The middleware functions may include sensor information
gathering, filtering by various policies and rules, data comparison and analysis, data mining,
context modelling, context-awareness processing, context-aware decision and estimation,
integrated management of sensor information, service integration, etc.
The middleware can be divided into three functional sub-layers as shown in Figure 7-6:
Support Functions are generic and locally available on the node.
Common Service Layer includes services which are available within the network and
can be used by other nodes or by the gateway via the backbone network. The
services offer basic functionalities which are common for sensor networks.
Domain Specific Services support the development of applications for a specific
market segment or application area.
For sensor network standardization, the following working packages need to be addressed for
middleware and middleware functions:
Identification of the different functions or services on the three middleware levels:
domain specific services, common services, and support functions
Description of the functions on a first level which is Domain Specific Services. The
details of the descriptions have to be worked out by companies who use the
middleware and by middleware developers.
Definition of interface between:
o Middleware and Application Layer
Technical Document of - 53 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
o Middleware and Basic Functions Layer
Collaborative
Application Software Rules QoS
Application Information
Layer Agent Engine Management
Processing (CIP)
Domain
Security
Specific Logistics Domain
Domain
Services
Resource Service / Data Network
Middleware
Security
Management Ressource Management Management
Common Management
Service
Service Discovery
Service
Code Group System
Layer Management
Time
Management Monitoring
Sync Service
Service Service
Ressource
Support Communication Self Management
Functions Support Localization
Device
Management
Basic
Network
Functions Communication
Hardware Driver Identification
Layer Management
Figure 7-6. Functional model of sensor network middleware, its service layers, generic
functions within each middleware layer, and interfacing layer.
The interface definition for each and every module inside the middleware, Application Layers,
and Basic Functions Layer is the job of software/middleware developers and implementers.
The sensor network designers and developers will provide the software/middleware
developers with sensor network system requirements and the interface definitions between
middleware and application layer and also the interface definition between middleware and
basic functions layer.
The functional model should be applied to middleware on the node, the gateway and the
“middleware” or integration platform which is used in order to connect sensor network
infrastructures to the information backbone within a company providing a sensor network
based service to a customer.
The following aspects also need to be addressed during standardization discussions:
Function interfaces on the node
Function interfaces on the gateways
7.13 Security and Privacy of Sensor Networks
Security and privacy are discussed in this section for standardization areas for sensor
networks. There are existing security and privacy standards that can be referenced for sensor
networks.
Technical Document of - 54 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
7.13.1 Security of Sensor Networks
Considering security, we distinguish between sensor network security and application
security. Sensor network services standards are domain independent which means standards
from other application areas may be used. Application security services, on the other hand,
depend on political, cultural, organizational, and ethical issues. They are domain-specific with
respect to which application security services to apply and which underlying mechanisms and
algorithms to choose from Figure 7-7 shows the details of the sensor network security and
application security.
Safety Security Quality
Concepts
Sensor Network Application
Security Security
Identification & Access
Integrity Confidentiality Authorization Confidentiality Audit
Authentication Services Control
Notary’s
Non- Availability
Accountability Functions Non- Notary’s
Repudiation Accountability Availability
Repudiation Functions
Access Control
Integrity Accuracy
Figure 7-7. Layered security model of sensor networks.
Security is of extreme importance for many of the proposed applications of sensor networks.
IP sensor nodes or even non-IP sensor nodes may be connected to global open networks, for
example, the IP-based Internet. They could be victims of hackers and must be protected
properly against cyber hacking attacks. That is, there are various security issues such as
device protection against system hacking and along with authentication, information
confidentiality and integrity, authorization and privacy protection. A tiny sensor node cannot
provide all such security features because it has severe system limitations such as low power,
narrow bandwidth, small memory, low computational power, etc.
Most wireless sensor networks are vulnerable to several types of threats:
Eavesdropping and insertion - insert forged packets into the WSN
Masquerading - a sensor node or an external entity pretends to have another entity’s
identity
Authorization violation - a sensor node or an external entity uses services without
authorization
Loss or modification of information - information stored in sensor node or in transit is
deleted or altered
Repudiation – an entity is able to claim that the entity is not responsible for some
action
Eavesdropping and insertion can lead to a purely passive attack, allowing an attacker to
access information without authorization and without interfering with the normal operations of
the network. On the other hand, the other threats can lead to active attacks, and are
Technical Document of - 55 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
potentially more disruptive to the normal network operations. For example, masquerading can
involve deletion and replaying of packets. Deletion or alteration of information can even lead
to sabotage. It is important to consider that any of the threats can potentially lead to attacks
placed on all the layers of the protocol stack.
Because of sensor networks’ unique properties, most notably limited resources and physical
exposure of sensor nodes, sensor networks require a new type of security protocols. These
protocols are tailored to the underlying system architecture, patterns of network traffic, and
specific security requirements so that the consumption by the security related resources can
be minimized. Physical exposure of nodes, as well as the threat that their cryptographic
secrets are potentially available to an adversary, demands that security protocols in sensor
networks protect the integrity of the network even if cryptographic secrets are compromised.
Therefore, network-provided security capabilities could be a solution for sensor node
protection and other security requirements. That is, a security proxy at an edge network
device could provide such security services to sensor networks. Other alternatives are also
possible.
Some generic security services to be met by sensor networks rely on
Confidentiality
It is at risk while data is being generated, transferred or stored. A classical threat is
the illegal capturing of personal information, e.g., by intruding on the sensors, sensor
networks, or the information attached to the sensor network such as database. This
can be avoided by encrypted sensor network protocols and communication protocols
between sensors and between sensor networks at the different levels of sensor
networks and encrypted storage.
Authenticity including non-repudiation
This is threatened by hampering the data at the front-end, e.g., mobile terminals, the
end-user’s application. If altered the information cannot be attributed to the sender or
the authorship of the information is being denied. Reliable safeguards are offered by
“Message Authenticity Codes (MAC)”.
Data Integrity
It is at risk during transmission or during storage. In this case, an intruder changes
the data. Countermeasures consist in adding redundancy codes, the so-called
“Message Integrity Codes (MIC)” to the data.
Accountability
This means that the users can rely on the information provided. It implies that all
actions are traceable. This requires ethical standards and legal regulations.
Authentication
This is the capability or the act of verifying or confirming the identity of some entity.
The entity may be a computer program, a program running on a sensor node, or the
actual user of a network service.
Technical Document of - 56 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Access Control
This is the capability or the act of controlling access to resources. Resources may be
physical or computational. For example, data available at a gateway or sink node may
require access control mechanisms employed at the network or application layers.
Availability
Availability refers to the capability of ensuring (with a predefined degree of confidence)
the normal operation of the network or computational resources during a specific time
period. For example, it may be expected that a sensor network guarantees the
availability of some critical services during its lifetime (in respect to available energy
for example), even in the presence of attacks or failures.
The availability of data is another necessity. Moreover, a set of control mechanism has to
ensure that the organization’s security policy is being met.
7.1 3.1.1 Security technology
The security technologies of sensor networks mainly focus on distributed key management,
security route protocols (such as DSDV, DSR, and SEAD), node cooperation and selfishness,
malicious power consumption, and intrusion detection model.
7.13.1.2 Security management
Referring to standard ISO/IEC 27002, security management of sensor networks also meets
following requirements: easy deployment and application, reducing manual operation,
maximum battery life, using existed security technology of encryption and authentication,
using existing security standards.
7.13.1.3 Security evaluation
It is helpful for the system owner to perform security evaluation to ensure the security of
sensor network activities before selecting the specific devices, analyzing security
requirements, constructing, rebuilding and running sensor networks, and connecting to
Internet.
7.13.2 Privacy of Sensor Networks
National laws shall always take precedence over International guidelines. Cases made to
International courts are likely to give precedence to a combination of the OECD
Recommendation and either the European Data Privacy Directive or APEC Privacy
Framework as appropriate.
Those requiring guidance in respect of specific data protection and data privacy requirements
and in respect of ITS 'Probe' Data are referred to ISO 24100, "Basic principles for personal
data protection in probe vehicle information services ".
Special concern needs to be given to the processing, transmission and storage of information,
with authorized access for allowed users and potential information flows with external entities
that may get involved.
Whenever appropriate, it is recommended to follow the guidelines defined for the
Management of Information Security in accordance with the ISO 2700x family of Standards,
with special reference to ISO 27002:2005. It is worth mentioning recommendations regarding
Technical Document of - 57 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
the management of communications and operations or the measures taken in relation with the
access control and privileges for authorized users.
There are a number of security related ISO Standards (including the ISO 2700x series) which
may assist in the achievement of privacy, and guidance is needed here for sensor networks.
7.14 Conformance/Compliance and Interoperability Testing
Sensor networks should be tested for the requirements of a target application. Any inter-
operation protocol for the target application requires conformance/compliance and
interoperability testing to evaluate implementation results. Conformance/compliance and
interoperability test cases should be specified according to inter-operation protocols. In
addition to the conformance/compliance and interoperability testing, performance testing
should be performed.
7.14.1 Conformance/Compliance Testing
Conformance/compliance testing is to confirm the consistency of Implementation Under Test
(IUT) and standard. The general approach is to compare the actual and expected output of a
black box test using a group of test case sequence under specific network condition. The
existing test methods are ISO/IEC 9646 series.
7.14.2 Interoperability Testing
Interoperability testing is to confirm whether a required functionality is supported by the target
equipment. The test is accomplished by evaluating the correctness of protocol standard
specified for interoperation between target implementation and the connected relative
implementation under network interoperating environment. Interoperability testing provides
important interconnection information, and is commonly used as testing between multiple
manufacturers during R&D stage or the model selection test for system developers.
7.14.3 System Performance Testing
Performance testing includes available test, test of response time, network throughput test,
evaluation and test of reliability, network bandwidth capacity test, etc.
Technical Document of - 58 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
8 Coordination Proposals to JTC 1 for Sensor Network Standardization
First, this chapter reviews the activities related to sensor networks by organizations within
JTC 1 (e.g., subcommittees) and by organizations outside JTC 1, (e.g., SDOs, consortia, and
fora). Second, this chapter presents the mapping of the SN standardization areas to relevant
JTC 1 SCs. The relevant SDOs, consortia and fora are also identified for the SN
standardization areas for potential cooperation in SN standard development. Different
coordination options for sensor network standardization are presented resulting from the
previous face-to-face meeting. Finally, the SGSN Oslo Resolution 6 – SGSN Long Term Role
is addressed as the SGSN’s recommendation for sensor network standard development and
coordination.
8.1 Sensor Network Standards and Related Activities by SDOs, Consortia, and Fora
Section 8.1 discusses the current understanding of sensor network related international
standardization activities within JTC 1 and outside JTC 1. The detailed activities of the listed
SDO in this section can be found in Annex C and Annex D. In addition, indicative lists of
standards that may be relevant to sensor network applications are shown in Annex E.
8.1.1 Activities within ISO/IEC JTC 1
We listed the JTC SCs in this section along with their relevancy to sensor networks. Each
SC’s scope, working groups, projects, and the relevance to the sensor network
standardization role are stated in Annex C.
ISO/IEC JTC 1 SC 2 – Code Character Sets
o No strong relevance to sensor networks.
ISO/IEC JTC 1 SC 6 – Telecommunications and Information Exchange Between
Systems
o Numerous work areas related to sensor networks. See SC 6 contributions in
SGSN N014 and N015.
ISO/IEC JTC 1 SC 7 – Software and Systems Engineering
o Does not handle network protocols including PHY, MAC, and NWK layers.
o Software and systems engineering may be applied to the development of network
software.
ISO/IEC JTC 1 SC 17 – Cards and Personal Identification
o Cards and personal identification themselves are not directly related with sensor
networks.
o However, personal identification codes or cards can be embedded in a terminal
that he/she carries.
Technical Document of - 59 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
ISO/IEC JTC 1 SC 22 – Programming Languages, Their Environments and System
Software Interfaces
o Programming language, their environments and system software interfaces are
important in developing higher layer protocol stacks than PHY of sensor networks.
o The technology itself is not directly related with the standardization works of
sensor networks.
ISO/IEC JTC 1 SC 23 – Digitally Recorded Media for Information Interchange and
Storage
o Not directly related with sensor networks
ISO/IEC JTC 1 SC 24 – Computer graphics, image processing and environmental data
representation
o Standardized environmental data representation is used for the sensor networks.
ISO/IEC JTC 1 SC 25 – Interconnection of Information Technology Equipment
o Home network systems which require sensors and sensor networks.
o Premises cabling which may serve as the backbone networks for the sensor
networks.
o Interconnection of computer systems and attached equipment
o Project team taxonomy and terminology
ISO/IEC JTC 1 SC 27 – IT Security Techniques
o Security is the most important element that wired/wireless sensor network system
needs to adopt.
o Encryption of data
o Network Security suite
ISO/IEC JTC 1 SC 28 – Office Equipment
o One of the biggest sensor network users for control purpose of office equipments.
ISO/IEC JTC 1 SC 29 – Coding of Audio, Picture, Multimedia and Hypermedia
Information
o ROSE: Representation of Sensory Effects information.
o MPEG-V: Information exchange with Virtual worlds including real world data
representation and data representation between real world and virtual worlds.
o M3W: Multimedia Middleware.
Technical Document of - 60 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
o MPEG-7 Multimedia Content Description Interface includes various description
schemes and descriptors relating to metadata relevant to sensor networks.
o MPEG-M: MPEG eXtensible Middleware.
o Camera-based sensors and data compressions are part of sensor networks.
ISO/IEC JTC 1 SC 31 – Automatic Identification and Data Capture Techniques
o See SC 31 contribution in SGSN N016.
o SC31 decided to focus on RFID and its extension to Mobile RFID technology.
ISO/IEC JTC 1 SC 32 – Data Management and Interchange
o SC32 is beginning working in capturing, storing (and discarding) and mining the
information from the sensors.
o SC32 is a good SDO that sensor network standardization needs to cooperate.
ISO/IEC JTC 1 SC 34 – Document Description and Processing Language
o Relevance to Sensor Networks: Not strong
ISO/IEC JTC 1 SC 35 – User Interfaces
o Some applications require aspects of user interface systems of SC35.
ISO/IEC JTC 1 SC 36 – Information Technology for Learning, Education and Training
o Weak relations with sensor networks
ISO/IEC JTC 1 SC 37 – Biometrics
o Standardization of Biometric data interchange formats, related biometric profiles,
and application of evaluation criteria to biometric technologies have many aspects
in common for sensor networks.
8.1.2 Activities outside ISO/IEC JTC 1
We listed other SDOs, consortia, and fora outside JTC 1 in this section. Each SC’s scope,
working groups, projects, standards, and/or the relevance to the sensor network
standardization role are stated in Annex D.
ISO TC 22: Road vehicles
ISO TC 184/SC 5: Automation systems and integration
ISO TC 204: Intelligent transport systems
ISO TC 205: Building environment design
Technical Document of - 61 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
International Electrotechnical Commission (IEC)
IEC TC 17: Switchgear and cotorlgear
IEC TC 22: Power electronic systems and equipment
IEC TC 57 – Power Systems management and associated information exchange
IEC TC 65: Industrial-process measurement, control and automation
ITU-T SG 13 Q.3 [Y.USN-reqts]
ITU-T SG 16 Q.25 (Established 2009)
ITU-T SG 16 Q.25 [F.usn-mw]
ITU-T SG 17 Q.9 X.usnsec-1
IEEE 802.15.x: Wireless PAN
IEEE 1451.x: Smart Transducers
IEEE 1588: Precision Clock Synchronization Protocol for Networked Measurement and
Control Systems
ISA100 / ISA100.11: Wireless system for automation / Wireless communication
standard(s) optimized for industrial loop control.
ZigBee Alliance
IETF 6LOWPAN
IETF ROLL
Sensor Web Enablement
OpenGIS Specifications by OGC
8.2 Mapping of SN Standardization Areas to JTC 1 SCs
Table 8-1 shows the mapping of SN standardization Areas to JTC 1 Subcommittees. Bold
letters indicates that SC has relevant projects or activities in the SN standardization areas.
Table 8-1. Mapping of standardization areas to JTC 1 SCs.
Standardization Areas ISO/IEC JTC 1 SCs
Terminology JTC 1 (all SCs)
Requirements Analysis SC 6, SC 17, SC 25, SC 32, SC 36, SC 37
Reference Architecture SC 6
Application Profiles SC 25, SC 31, SC 32, SC 36, SC 37
Sensor Interfaces SC 6, [SC 25), SC 31, SC 37
Technical Document of - 62 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
Standardization Areas ISO/IEC JTC 1 SCs
Data type and Data Format SC 6, SC 22, SC, 24, SC 25, SC 32, SC 36, SC 37
Communications SC 6, [SC 25]
Mobility Support SC 6, [SC 25]
Network Management SC 6, [SC 25]
Collaborative Information Processing SC 32, SC 37
Information Service Supporting SC 6, SC 24, [SC 25], SC 29, SC 31, SC 32
Quality of Service (QoS) SC 6, [SC 25]
Middleware SC 6, SC 25, SC 29, SC 32, SC 36
SC 6, SC 17, [SC 25], SC 27, SC 29, SC 32, SC 36,
Security & Privacy
SC 37
Conformance, Interoperability,
None Known [SC 25]
Performance Testing
Note: Items allocated to SC 25 in bracket were proposed by SC 25 Secretariat at the SGSN
Oslo meeting; however, they were not agreed during the SGSN Oslo meeting.
8.3 Other SDOs, Fora and Consortia for SN Standardization Areas for Cooperation
Table 8-2 shows that the SDOs, consortia and fora are identified for SN standardization areas
for potential cooperation in SN standard development.
Table 8-2. Standardization areas to potential SDOs, Consortia, and Fora.
Standardization Areas Other SDOs, Consortia, and Fora
Terminology ITU-T SG 13, 16, 17; JCA-NID
ISO TC 204, ISO TC 205, TC 211, IEC TC 65, ITU-T
Requirements Analysis SG 13, ITU-T SG 16, ITU-T SG 17, ISA100, IETF
6LoWPAN, ROLL WG, OGC
ITU-T SG 13, ITU-T SG 16, ISO TC 204, ISO TC
Reference Architecture
211
Application Profiles ZigBee Alliance, OGC, ITU-T SG 5
IEEE 1451.x, IEC SC 17B, EPCglobal, ISO TC 211,
Sensor Interfaces
ISO TC 205
ITU-T SG 16, ISO TC 211, ISO TC 205, W3C, IEC
Data type and Data Format
TC 57
IEC SC 65C, IEC TC 57, IEEE 802.15.x; IEEE 1588,
Communications
IPSO Alliance, ISO TC 205, ISA100
Mobility Support IETF MANET MIP WG
ZigBee Alliance, IETF SNMP WG, ITU-T SG 2, ITU-
Network Management
T SG 16, IEEE 1588
Collaborative Information Processing OGC; W3C
Information Service Supporting OGC, W3C, IETF ENUM WG, EPCglobal
Quality of Service (QoS) ITU-T, IETF
Middleware ISO TC 205, ITU-T SG 16
Security & Privacy ITU-T SG 17
Conformance, Interoperability, ZigBee Alliance, ITU-T SG 11, ITU-T SG 17, KNX,
Performance Testing LONMARK, ETSI, MTS
Technical Document of - 63 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
8.4 Organizational Options for SN Standardization Coordination
Standardization of sensor networks is a complex and challenging task. The study makes quite
clear that large part of standardization areas can be handled by the existing SCs. However,
the study results also show that there are many aspects of sensor network standardization
areas that have not been addressed today. The question is how to fill these gaps. Different
alternatives have been discussed during the SGSN face-to-face meetings in Germany,
Australia, and Norway: Summarizing the discussion held on this topic produced the following
five options for sensor network standard development and coordination:
1. No new organizations, but let an existing subcommittee (SC) or working group (WG)
Since there are needs for sensor network standardization, this option is not considered
desirable. Without new organization, the stovepipe standards development for sensor
networks will continue creating the interoperability issues.
2. A new (WG) under an existing subcommittee
This option is not desirable as the scope of WG is limited by the hosting SC’s scope
and there could be potential issues on coordinating with other JTC 1 SCs and SDOs
outside JTC 1. In addition, potentially a lengthy process will take to establish a new
WG under a SC, and which SC is also a question to be answered.
3. A new SC
Although this option is less limited compared to Option 2 above, the sensor networks
covers diverse technologies, applications, and market domains. Thus, this option may
cause objections from other JTC 1 SCs. The timeline is also a concern as establishing
a new SC could take a length process and to start a new project. It may also have
potential issue on coordinating other SCs and SDOs outside JTC 1.
4. A new Special Working Group (SWG) directly under JTC 1
Traditionally SWG does not develop standards, and there has been no SWG with
standards development role. In addition, JTC 1 SWG on Directives is likely updated
its Directives document clearly indicating that the SWG has no standard developing
role.
5. A new WG directly under JTC 1
All SGSN NB HoD and delegates desired to have the new entity to have a standard
development role and also the coordination role. This option could be accomplished
by transforming SGSN to a Working Group on Sensor Networks (WGSN). WGSN is to
coordinate the SN standardization activities with JTC 1 SCs and SDOs outside JTC 1
and to develop standards within the SN need areas that no SC has the work scope.
8.5 JTC 1/SGSN Oslo Resolution 6 – SGSN Long Term Role
th
In the 4 SGSN meeting in Oslo, Norway, June 29-July 3, 2009, the SGSN members,
including NB HoDs and delegates from China, Korea, Germany, Norway, UK, and US,
discussed on the long term role of SGSN as well as the new entity type for the SN
standardization. Among the options presented in Section 8.4 above, SGSN members who
participate in the Oslo meeting came together to recommend a Working Group on Sensor
Networks (WGSN), and this decision resulted in SGSN Oslo Resolution 6, stating:
Technical Document of - 64 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
ISO/IEC JTC 1
“SGSN recommends to JTC 1, subject to approval of appropriate work items, a
working group directly under JTC 1. One or more proposals for new work item(s) will
be submitted to JTC 1 for consideration at the JTC 1 Plenary meeting to establish the
working group.”
The new project proposals are being developed by the SGSN participating NB members.
Technical Document of - 65 -
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Annex A
A Sensor Network Applications
This annex provides a handful of sensor network applications from different markets shown in
Table 4-1. These selected applications do not represent all aspects of the sensor network
markets and applications.
The main purpose of the detailed descriptions of selected applications is to understand the
sensor networks’ main characteristics, generic requirements, services, architectures, and
other related subjects. Each description in this Annex contains a brief motivation of the
application, a description of the solution approach through sensor networks, and a top-level
outline of the hardware and the software architectures. Whenever appropriate, the
requirements associated with each application are also listed.
A.1 Logistics and Supply Chain Management: Theft Prevention System for
High Value Goods
A.1.1 Description of Application
A.1.1.1 Motivation for Using Sensor Networks
Within the supply chain distribution systems, a large number of the goods are stolen.
Manufacturers and logistics service providers have to secure and protect their shipments from
thefts. Passive technologies such as RFID do not solve the theft problem, while a type of
sensor network (SN) may provide a much better solution. Applying a sensor network to theft
problem in distribution systems bring secondary benefits besides the theft prevention, One of
the secondary benefits may be to allow customers access shipment’s static and dynamic
information on-demand from their computers. The static information is, for example,
production date, technical specifications of the shipping item(s), shipping date.. The dynamic
information may include the status of the product being shipped, for example, current location
of the shipping container or package, temperature of the inside/outside the package, and
other environmental data around the package.
A.1.1.2 Solution Approach
Sensor nodes can be attached or integrated into packaging material, pallets, or containers
which need to be secured and protected. The sensor nodes attached or embedded in
packages, pallets, or containers that are being shipped to a destination form a security
network. When the security network is breached, e.g., the connection of sensor nodes is
broken due to removal of package(s), pallet(s), or container(s), the security network issues an
alarm message and transmits the message to a communication infrastructure. The warning
message is delivered to a security officer providing shipment security and protection service.
The security officer then is able to impose a proper countermeasure to deter or stop the theft.”
A.1.1.3 Operational View and Description
High value goods flow in global supply chains. A typical distribution network is shown in
Figure A-1, left side of the arrow in the figure. On the right side of the figure, an operational
view of the approach illustrated with the hardware players forming a SN-based security
network to secure and protect valuable goods.
The theft prevention sensor network system has to work both in storage and while in shipping
route, in other words, has to work both inside and outside of buildings. To secure and protect
all goods, each product package must have an embedded sensor node. The nodes inside the
package build a network of the first level of the security network. If the sensor node is inside
the package, a light or a similar sensor can be used to detect the unauthorized opening of the
package. If an alarm is generated, the alarm message is routed to the second level sensor
node-based security network which is connected to the first level of the security network
(which is, for example, pallets with embedded sensor nodes). An alarm arriving from the first
Technical Document of Page A-1 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
level is transmitted to a network of anchor nodes which are installed on the ceiling of the
building.
Figure A-1. Operational view of a typical distribution network and theft prevention.
The sensor node in the pallet uses the anchor network to determine its position. The position
information is added to the alarm message. The anchor nodes are connected directly to the
internet or a communication link; therefore, connected to a security service provider. If there
are authorized activities inside a building, the security network can be deactivated by
authorized personnel. Outside of a building while being transported, the pallets will be in a
sea container. The containers are equipped with a third level security sensor network. If an
alarm is generated on the container level, the alarm message is routed to the service provider
using GSM or SatCom communication networks. The position of the container can be
determined via GPS or Galileo, etc.
A.1.1.4 Software Architecture from a Functional Point of View
To support this theft prevention system, distributed application software is necessary. Table
A-1 shows sensor network services that need to be integrated into the type of nodes. We
assumed that there are application modules on the sensor node that uses the sensor network
services identified in Table A-1.
Table A-1. Required sensor network services.
Functions / Nodes Product Pallet Container Anchor
Long range communication X
Short range communication X X X X
Security services X X X X
Data storage services X X X X
Data processing services X X X
Linkage services X X X
Self localization services X X
Neighbourhood monitoring
X X X
service
Sensing service X
Identification service X X X X
Indication service X X X
Technical Document of Page A-2 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
A.1.2 Requirements of Application
Table A-2 shows the list of main characteristics system requirements and its description
and/or specifications for the theft prevention system.
Table A-2. Theft prevention systems’ requirement description and specifications.
Requirement Description
Latency time Less than 10 sec from alarm to indication at central PC
Scalability No more than a view hundred sensor nodes in a cluster
Throughput Alarm messages are transmitted as a package is distributed
Lifetime At least more than 3 months and up to years
Long range communication Defined by GSM and SatCom
Short range communication 50 cm up to 10 or 20 meters
Security Sustainability of security algorithms, at least, 3 months
Data storage A few 10 Kbytes acceptable (estimation)
Processing power To be defined
Linkage service Critical due to security application
Loc resolution A few meters seem to be acceptable
Sensors on node Motion detector
ID service EPC concept to be used for identification of node and product.
Indication Silent alarms are sufficient.
A.2 Energy & Utility Distribution Industry: Sensor Network-Based Smart Grid
System
A.2.1 Description of Application
A.2.1.1 Motivation for Using Sensor Networks
Smart grid system is an electricity transmission and distribution network which adopts
advanced wireless sensor nodes as “ears and eyes” to collect detailed information about the
transmission and distribution of electricity. Integrated with robust bi-directional
communications and distributed computers, the smart grid is a self-adaptive system to counter
fluctuating and unstable demands of electricity in order to improve the efficiency, reliability,
and safety of power delivery. Unlike the traditional grid, the smart grid is a digital network
keeping pace with the modern digital and information age, allowing a flexible tariff scheduling
that encourages clients to use electricity more wisely. “Digital-grade electricity” is a new
concept for the power transmission and distribution industry.
Smart grid system needs to support "virtual power stations" or renewable energy sources
which mean blocks of wind farms, photo-voltaic system (e.g., solar cells PV), fuel cell system,
micro-turbine, and energy storage and so on. Load management of power grids and
transmission lines (only consumption considered) and automated "Intelligent Power System
Management" are to find failures faster and to avoid "black outs" in energy power stations and
transmission and distribution power networks.
A.2.1.2 Solution Approach
Smart grid resulted from the application of communications and Information Technology (IT) to
the electric power transmission and distribution networks. However, smart grid is more than
smart meters as smart meter involves replacing analogue mechanical meters with digital
meters. Smart grid system employs a sensor network as an infrastructure to monitor delivery
and usage of electricity. Various types of sensor nodes are installed in generating plants,
transmission lines, substations, and even in buildings to gather data (e.g., temperature,
Technical Document of Page A-3 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
luminance) to measure electricity consumption by electric equipments in the buildings.
Sensor nodes within the smart grid network, thus Smart Grid Sensor Network, can be
organized in ad-hoc or hierarchically-clustered network structure. The information from
sensor nodes is wirelessly delivered to smart meters, which we call as “smart terminal,”
integrated with computing and processing functions. All these “smart terminals” are
connected with Electric Management Centre (EMC) by fibre-optics, Ethernet, power-line
carrier, and other wireless technologies, such as WiFi, WiMAX, RF mesh, etc. Based on the
data collected from all these terminals, EMC can automatically adjust the specific electricity
distribution to target regions. Also, these data contain the information about consumption of
electric equipments. For example, EMC can track the electric consumption of every air-
conditioning unit in the target regions. Therefore, according to the tariff-grade scheduling,
EMC will charge clients based not only on the amount of electricity consuming, but also on
their electricity usage behaviours.
A.2.1.3 Operational View and Description
An operational view depicting system level architectural diagram of a smart grid
communication network is shown in Figure A-2.
buildings
generating
plants
substations
transmission
lines
Figure A-2. Operational view of a multi-layer smart grid communication network.
To achieve the envisioned functionality of smart grid, multi-tiered, distributed sensor network
architecture is required to provide different levels of service at each tier. The top-tier will
have a widest bandwidth and lowest latency (e.g., highest data rate), and it will be supported
with a combination of fibre-optics and microwave communication networks. For the top-tier
network, the highest level of reliability and redundancy is provided by a redundant microwave
network while a more cost effective alternative redundancy is provided by Ethernet over the
same infrastructure. In the middle-tier, WiMAX or Cell modem can provide a point-to-multi-
point wide area network (WAN) with adequate and economical redundancy, bandwidth and
latency. At the third-tier, the local area network (LAN), a network supported by IEEE 802.15.4
protocol stacks, for example, ZigBee or IPv6loPAN, would meet the requirements of the
connection between smart terminals and electric equipments such as air condition, lighting,
and computer.
Based on the infrastructure described above, various sensor nodes installed in generating
plants, transmission lines, substations and buildings gather important operating data to
monitor power load. The operating data will be transmitted from the lower-tier to the upper-
tier with data/information fusion, when necessary, and then finally to the Electric Management
Centre (EMC).
Technical Document of Page A-4 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Smart grid sensor network system is a bi-directional data communication network. After the
analysis of the operating data from the smart grid sensor network via the communication
networks, the resulting decisions of command and control will be transmitted to LAN in order
to automatically activate necessary functions, e.g., load adjustment, self-healing, smart
monitoring, etc.
A.2.1.4 Software Architecture from a Functional Point of View
Software architecture of a typical sensor network Smart Grid system is shown in Figure A-3.
Figure A-3. Typical sensor network Smart Grid system and software architecture.
The software architecture can be conceptually composed of three software platforms. From a
bottom-up view, there are sensor platform, multi-layer network platform, and electric
management platform. Smart Terminal can be considered as “bridge” between sensor
platform and multi-layer platform. The key to interoperability of this software architecture is
based on allowing different applications to interface with the most appropriate platform.
Compared with current grid system, the software architecture of Smart Grid System is a
distributed system supported by micro-chips installed in every sensor node. Therefore, the
whole system will be more secure and robust. GIS Database is one of the most important
components because GIS database enables clients and maintenance personnel to easily
understand the information that they need to take necessary actions.
A.2.2 Requirements of Application
Table A-3 shows the list of main characteristic system requirements and their description
and/or specification for this Smart Grid System application.
Table A-3. System requirements.
Requirement Description
Latency time Each tier has different latency times
Top-tier: lowest latency
Middle-tier: appropriate latency
Third-tier: highest latency
Response time Analogous to “Latency time” above
Network coverage Multi-layer network with thousands upon thousands sensor nodes
covers 10~50 Km distance
False negative rate Very low under various environment conditions
Technical Document of Page A-5 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Requirement Description
False positive rate Extremely low (approaching zero) under complex conditions
Bandwidth Low data rate transmission supporting for simple data
Information provision Rich information presentation and user-friendly interface
Communication range Different tiers with different communication range
On-duty time At least 1 year, 24 hrs on-duty time before next maintenance
Network and linkage Reliability transmission supporting for full 24 hrs on-duty time
Directory and ID service Directory and ID supporting
Database and storage GIS information and large historical storage in EMC centre
Security High security level in upper tier, proper security level in lower tier
A.3 Automation, Monitoring and Control of Industrial Production Processes:
Industrial Automation in General
A.3.1 Description of Application
A.3.1.1 Motivation for Using Sensor Networks
In industrial automation, there are numerous tasks to be considered, such as different means
of supporting emergency actions, safe operation of the plant, automated regulatory and
supervisory control, open loop control where a human operator is part of the loop, alerting and
information logging, information uploading and/or downloading. Some of these tasks are more
critical than others. The industrial automation systems are complex and often very expensive.
Wireless sensor networks may be applied to realize a cost effective and efficient automation
with simpler mechanisms, which fulfil the same functional solutions as the solutions that have
been in use.
A.3.1.2 Solution Approach
Wireless communication for industrial applications, such as WirelessHART (Highway
Addressable Remote Transducer) and ISA100.11a, can provide specifications to support
wireless process automation applications. The architectural elements are wireless
communications systems that consist of a single subnet or multiple subnets connected to a
single control room; or for a large site with multiple interconnected control rooms. Each
control room can be connected with multiple subnets. The subnets:
are used for control or safety where timeliness of communications is essential;
are used for monitoring and asset management;
can (but need not) support plant workers wirelessly and also support plant and civil
authority’s first responders;
can (but need not) require a proof that a device is authorized to operate in the network;
can (but need not) provide limited intrusion resistance within a wireless subnet;
can (but need not) provide, within a wireless subnet, a limited higher-layer message
confidentiality and resistance to traffic analysis;
can (but need not) provide extensive messaging security at the granularity of individual
communications sessions.
A.3.1.3 Operational View and Description
An operational view illustrating system level architectural diagram is shown in Figure A-4 for
industrial applications using wireless sensor networks.
Technical Document of Page A-6 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure A-5 shows another operational view of industrial automation systems based on
wireless sensor nodes. The network supports mesh, star-mesh, and star topologies. It has
capability for non-routing field devices with limited energy sources and is connected via a
gateway to a plant network. Simplex and optional full redundancy from field device to plant
network as well as device interoperability are two of the main and most important
characteristics of the network. Security, including data integrity, encryption, data authenticity,
replay protection, and delay protection are provided by the wireless network. It has the ability
to closely work with other wireless devices in the industrial workspace and provides
robustness in the presence of interference and with legacy systems.
Figure A-4. Industrial wireless network operational architecture view.
Figure A-5. Nodal interconnectivity architecture diagram for industrial automation
systems using wireless sensor node.
Technical Document of Page A-7 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
A.3.1.4 Software Architecture from a Functional Point of View
The software architecture is shown in Figure A-6. As shown here, each layer provides a
service access point (SAP). The services of a layer are defined as layer's functions and
capabilities exposed through the SAP to the surrounding layers. A layer's services are
defined by the data flowing through the SAP. In some cases, it is defined by the states that a
layer must provide and also by the state transitions that are driven by the interaction across
the SAP. Note that the device manager has a dedicated path to the lower protocol layers
within a device. This is to provide direct control over the operation of these layers and also to
provide direct access to diagnostics and status information. All devices are managed devices,
which mean that, even though they may not fully implement each protocol layer within the
stack, they shall implement each DMAP SAP as shown in Figure A-6.
Figure A-6. Stack reference model.
A.3.2 Requirements of Application
Table A-4 shows the list of main characteristic system requirements and their description
and/or specification for a typical industrial automation application.
Table A-4. System requirements.
Requirement Description
Latency time Between real time and several minutes
Between some 10 and several 100 nodes, sometimes order of 10000
Scalability
nodes
Throughput Small data packages, sometimes data streams
Lifetime A few months up to years depending on maintenance cycles
Short range
up to 300 meters, in some cases up to some kilo-meters
communication
A few months up to years depending on maintenance cycles, mid-
Security
high security level
Privacy Protection against unauthorised programs or persons
Data storage Depending on type of applications
Processing power To be defined
Technical Document of Page A-8 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Requirement Description
Control service Controlling of valves and other actuators
Loc resolution A few meters might be acceptable for mobile nodes
Orientation detection High resolution in order to position product components
General sensing Temperature, pressure, humidity etc.
ID service EPC and company specific identification numbers
Indication Buzzer and light signals
Environmental issues Nodes have to endure harsh requirements
Reliability of service Protection against network failure for the whole life cycle
A.4 Asset Management: Blood Bag Monitoring and Status Tracking
A.4.1 Description of Application
A.4.1.1 Motivation for Using Sensor Networks
In hospitals, blood bags are stored in fridges and cooling chambers. When transfusion
becomes necessary during a surgery, a blood bag or bags are brought to the operating room
and buffered until a patient requires the blood. It is important to make absolutely sure that the
quality of the blood is perfect. If the blood bag is exposed to the room temperature for an
extended period of time, the blood should not be used for transfusion. The danger and risk is
high for both the patient and hospital. Hospitals require “blood monitoring services,” and
sensor networks can help to monitor the temperature of the blood bags, to record the time that
it has been exposed to an undesirable temperature, and to minimize the risk for the patient.
These services may be delivered by professional service providers.
A.4.1.2 Solution Approach
The solution approach is to attach wireless sensor nodes to the blood bags and to the
infrastructure of the hospital, thus forming a wireless sensor networks. The main idea is to
monitor the temperature and to record the exposure time during the entire life cycle of a blood
bag. When a predetermined threshold for temperature and exposure time is exceeded, an
alarm message is generated and routed to a central monitoring centre. It is important that the
connection between the sensor nodes and the blood bags are maintained all the time.
A.4.1.3 Operational View and Description
Figure A-7 shows the operational concept of the blood bag monitoring and exposure time
tracking. The system may work as follows: The blood bag storage devices in the hospital –
fridges and cooling chambers – are equipped with a sensor node per device. These sensor
nodes become part of a wireless network interconnected with anchor nodes. A gateway node
links the anchor node network to a computer where an application software, e.g., “monitoring
cockpit,” is running. A blood bag with an integrated sensor node, stored in a fridge, connects
to the fridge sensor node. The blood bag sensor node downloads the context information
(e.g., “I am inside a fridge and the temperature should not be higher than 3°C.”). The blood
bag sensor node starts monitoring the temperature inside the fridge using its own temperature
sensor. In case that somebody leaves the fridge’s door open or the cooling mechanism
malfunctions, the sensor node will detect the anomalous temperature and will generate an
alarm message so that the message can be routed through the network to the “monitoring
cockpit” application software installed on the central PC. An acoustic alarm will cause a
hospital staff to react and to resolve the problem. If someone takes out a blood bag, the
connection with the fridge’s sensor node and the blood bag’s sensor node is broken. However,
the blood bag sensor node reconnects with a sensor node in the room where the fridge is
located and subsequently downloads the new context information (e.g., “I am outside of the
fridge, and an environmental temperature between 3°C and 30°C is acceptable for 20 minutes
at the most.”). Then, the monitoring process begins again. In case that the bag is buffered in
a fridge before the end of the 20 minutes period, no alarm message is generated. If the bag
Technical Document of Page A-9 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
is somehow misplaced or lost and an acceptable time period is exceeded, an alarm message
containing position information is again routed to the central PC. With a security time buffer
built in the threshold, the blood bag is found and “rescued” by bringing it back to a fridge or
cooling chamber.
A.4.1.4 Software Architecture from a Functional Point of View
To support this blood bag monitoring and status tracking application, a distributed application
software system is required. Table A-5 shows the application modules needed on the
different node types, e.g., fridge, blood bag, and anchor nodes.
A.4.2 Requirements of Application
Table A-6 shows the list of main characteristic system requirements and their description
and/or specifications for this blood bag monitoring and status tracking application.
blood temperature monitoring service
monitoring
„cockpit“
anchor network
storage storage
device if t > N min than „alarm+position“
device
blood bank surgery
t1 t2 room
Figure A-7. Blood temperature monitoring service.
Table A-5. Software functions implemented on the different nodes.
Functions / Nodes Fridge Blood Bag Anchor
Short range communication X X X
Security services X X X
Data storage services X X X
Data processing services X X X
Linkage services X
Self localization services X
General sensing service X X
Identification service X X X
Technical Document of Page A-10 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Table A-6. System requirements
Requirement Description
Latency time Critical; less than one minute
Scalability Less than 100 devices in a cluster
Throughput Small packages containing position and condition data
Lifetime A few month
Short range communication Up to 3 meters
Security Sustainability of encryption mechanisms up to a few month
Data storage 20 to 50 Kbytes minimum due to security requirements
Processing power To be defined
Linkage service Critical due to security applications
Loc resolution Tag to be assigned to fridges rooms and contexts (less 1 m)
Sensors Temperature
ID service EPC and or equipment number of the hospital
Regulatory issues Housing without slots which can be sterilized
A.5 Health Care and Medical Applications at Home and in Hospitals: Position
and Posture Monitoring
A.5.1 Description of Application
A.5.1.1 Motivation for Using Sensor Networks
Many elderly people have to leave their homes and move into a nursing home when the risk of
living alone becomes too high. For example, people suffering from dementia tend to fall down
while fulfilling simple and everyday tasks. Sometimes they are not able to stand up on their
own and the consequences could be fatal. Researchers from academia and industry are
trying to find solutions for this kind of problems involving the elderly, the handicapped, or
patients. One of these solutions is using a special type of sensor network attached to the
elderly person or a patient. The main advantage of this approach compared with other
simpler solution approaches is that the sensor nodes or tags are active and smart. The
sensor tags can detect uncommon body positions, and the tags can generate and transmit an
alarm message when detected. This application is also suitable to those who are short-term
patients, e.g., recovering from stroke, cancer, major surgeries, and other injuries. The short-
term patients eventually return to their normal life. The elderly as long-term patients may be
equipped with different sensors in their homes or care centres compared to those who are in
short-term care.
A.5.1.2 Solution Approach
The main idea is to attach sensor nodes or tags to the extremities of an elderly person or a
patient. The sensor nodes/tags monitor their own spatial orientation and their relative position
to each other. The sensor nodes or tags send the orientation/positional measurement data to
a central unit which compares the data with reference information in a database. In case that
the measurement data is not acceptable for the person or patient under monitoring, an alarm
message is generated and routed to a health monitoring service provider. Another potential
solution is the idea of Ambient Assisted Living (AAL) which have sensors built-in a house to
monitor the patients. AAL is being considered as one of the functions of smart homes. The
examples discussed in this section are mainly for the home environment, but they could
similarly be used in hospital settings.
Technical Document of Page A-11 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
A.5.1.3 Operational View and Description
Figure A-8 shows the operational view of the system architecture which supports the position
and posture monitoring service. The person lying on the floor of a bathroom is wearing
clothes with small and integrated sensor nodes. The nodes attached at the ends of the
person’s extremities are connected to a central unit attached to the person’s belt. All nodes
which build a “personal sensor node cluster” are able to determine their orientation in three-
dimensional space and also their position relative to each other. Movement models and
reference profiles for typical postures are stored in the central unit. In case that the person
comes into the bathroom, the central unit node communicates with the anchor node installed
in each room of the house. The central unit downloads context information (“You are now in a
bathroom.”) and compares the position and orientation data coming from the extremity nodes
continuously with the reference information. If there is a match between the measured values
and a typical lying posture reference profile, the central unit node generates an alarm
message because the person is in the bathroom. This message is then routed via the anchor
node network in the household to a gateway and then to a central server which is connected
to an emergency service provider. In this health care application, the system handles highly
private data. It has to provide maximum data security and privacy. If not, it will not be
accepted by the user, e.g., the elderly, patients, and others. Another important issue is that
the nodes have to be absolutely sure whether they are attached to a person or not. False
alarms are not acceptable from the user’s point of view. From the application point of view, it
also makes sense that the user is able to push a button to send an alarm message and that
the belt node communicates the status of the system to the user.
gateway &
server
to service
provider
belt node
sleeping room bathroom
anchor node
extremity node
Figure A-8. Operational view of system architecture for position & posture monitoring.
A.5.1.4 Software Architecture from a Functional Point of View
To support this position and posture monitoring service, distributed application software is
needed. Table A-7 shows that software functions or modules need be installed in the different
node types.
Technical Document of Page A-12 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Table A-7. Software functions implemented on the different nodes.
Functions / Nodes Extremity Belt Anchor Gateway
Long range communication X X X
Short range communication X X
Clustering Services X X
Security services X X X X
Data storage services X X
Data processing service X X
Linkage service X X
Orientation detection service X
Self localization service X X
Monitoring communication
X X X X
links
Data entry service X
Indication service X
A.5.2 Requirements of Application
Table A-8 shows the list of main characteristic system requirements and their description
and/or specification for this position and posture monitoring application.
Table A-8. System requirements.
Requirement Description
Latency time Less than a few seconds because vitally important
Scalability Uncritical because only a few tags
Throughput Small packages of sensor data and alarm messages
Lifetime Up to a month without charging batteries
Long range communication Up to 10 meters within the household, GSM outside
Short range communication Up to 2 meters
Clustering Services Clustering by IDs might be sufficient
Security services Sustainability of security defined by system lifecycle (years)
Data storage services Larger amounts of data only within the belt node
Data processing service To be defined
Linkage service Critical due to health care application
Orientation detection Less than 5 degree (angular)
Localization resolution Resolution on room level is sufficient
Data entry service One emergency button is sufficient
Indication service LED for indication of system status
Technical Document of Page A-13 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
A.6 Civil Protection and Public Safety: SLEWS – Prototype Landslide
Monitoring and Early Warning System 1
A.6.1 Description of Application
A.6.1.1 Motivation for Using Sensor Networks
Due to the progressive development of urban areas and infrastructure, more and more people
settle in environments that are or become endangered by mass movements. This situation is
being complicated by the fact that the dependency of our society on a functioning
infrastructure and number of human or objects in endangered areas increases at the same
time. Early warning and alarm systems are an efficient tool to face landslide hazard and
reduce the risk, especially when no other mitigation strategies are suitable. The existing
monitoring systems for early warning are available in terms of monolithic systems. This is a
very cost-intensive way considering its installation as well as operational and personal
expenses. This displays the demand for modern cost-efficient technologies to upgrade the
existing systems and develop new ones.
A.6.1.2 Solution Approach
The joint project “A Sensor-based Landslide Early Warning System (SLEWS)” aims at a
systemic development of a prototyping alarm and early warning system for different types of
landslides utilizing ad-hoc wireless sensor networks and spatial data infrastructure
technologies according to the OGC (Open Geospatial Consortium) guidelines for real-time
monitoring. The SLEWS system is characterized by a flexible structure, cost efficiency, and
high fail-safe level. The application of a wireless ad-hoc, multi-hop sensor network in
combination with low-cost, but precise micro-sensors provides an inexpensive and easy to set
up intelligent monitoring system for spatial data gathering in large areas. The gathered data
are provided by standardized interfaces following the OGC specifications for Sensor Web
Enablement (SWE) for user orientated processing and visualization by a spatial data
infrastructure. The open structure of the system allows a very rapid and flexible adjustment to
changed boundary conditions and permits a simple linkage also with other data sources or
other sensor networks.
A.6.1.3 Operational View and Description
The objective of the SLEWS project is to develop the suitable methods and technologies for
early warning systems, including a prototype system and applications to monitor and warn
potential landslide events. The planned monitoring and information system will include a
mobile infrastructure (e.g., geospatial information technologies and communication
components) as well as methods and models to estimate deformation parameters. The
measurements result in heterogeneous observation sets that have to be integrated in a
common adjustment and filtering approach. Reliable real-time information will be obtained
from which early warnings and prognosis may be derived.
Figure A-9 shows the SLEWS gateway and operational view. The gateway received the data
from the geographically distributed wireless sensors over the landslide monitoring area. The
data received from the sensors are sent to a computing station which provides data storage,
data analysis and visualization. The users can access the computing station via web-services
to get the current status or information of the monitoring area. Depending on the results of
data analysis at the computing station, a warning or alarm can be issued for end users. The
end users will follow the emergency plan to react to the warning or alarm and the additional
information provided to them via web-services and/or emergency communication channels
(e.g., radios, broadcasting, etc.).
1 Contents of this section is from http://slews.de/
Technical Document of Page A-14 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Sensor Node
Sensor Node
Data Sink
(Gateway)
End User Geo-service /
• Reaction Web-service
• Emergency
Planning
• Data Storage
• Data Analysis
• Visualization
Figure A-9. SLEWS gateway and operational view.
This project is to develop a prototype real-time monitoring and early warning system for mass
movements to enhance the information situation in the event case. Further aims are to realize
the spatial monitoring, sensor fusion to reduce false alarm rates and user centred warning. In
the context of this project, the whole chain from data gathering and acquisition, evaluation and
interpretation, up to data analysis, visualization and data supply for different end user will be
investigated. Of special interest are data retrieval, processing and visualization of real-time
data in open geographical information environments as little experience exists now. Besides
the technical aspects of alarm and early warning systems, the demands of the users and
requirements for an effective warning management are more important research fields within
the project.
Figure A-10 illustrates more detailed systemic operational view of the SLEWS to achieve the
objective and the project plan to develop the prototype.
Figure A-10. SLEWS system architecture view.
Technical Document of Page A-15 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
A.7 Automation and Control of Commercial Buildings and Smart Homes:
Building Energy Conservation System
A.7.1 Description of Application
A.7.1.1 Motivation for Using Sensor Networks
Accurate energy consumption monitoring of a building’s electric infrastructure, such as
elevator, lighting, air conditioning, fire alarm system, ventilation, high and low voltage power
distribution, etc., is one of the key issues to achieve an energy-saving or energy efficient
building. In the construction of new buildings and updating existing buildings to install the
energy consumption monitoring system to conserve energy, the most pressing issue is the
high cost of integrated wiring and the high cost of repairing after the update. Therefore, for
both the new building and the existing building, the best way to transmit a message is through
wireless means; however, the traditional wireless systems, such as GSM, WLAN, SCADA, etc.,
and their power and equipment costs are very high, yet, their network ability is limited. The
Building Energy Conservation (BEC) system based on wireless sensor network technology is
considered the best solution for the building energy consumption monitoring.
A.7.1.2 Solution Approach
BEC system based on wireless sensor network technology collects and distributes information
about environment parameters and energy delivery and usage. For example, on the one hand,
wireless sensor nodes collect the environment parameters, such as temperature; On the other
hand, the sensor nodes are connected with a variety of sensors/devices that collect the
energy information on delivery and usage of electricity, water, gas, etc. This sensor networks
consist of hundreds of sensor nodes which are self-organized to provide a reliable network.
Energy information can be monitored and processed in real-time for energy stability diagnosis,
energy consumption assessment, and energy transformation based on the results of the
energy consumption assessment.
A.7.1.3 Operational View and Description
Figure A-11 shows the top level operational architecture view of the BEC system. Hundreds
of sensor nodes are installed in a building, and the sensor nodes are self-organized to form a
wireless sensor network. The energy information is transmitted to the master node; and then
through a gateway, e.g., wireless or Internet gateway, to the servers. The BEC system should
be able to support multiple types of RF hardware and different frequencies depending on
countries in which the system operates. Sensor nodes can sleep to save battery life, and they
have a trigger mechanism that reacts to a specific signal to wake them up to operate. For
some sensor node may need to have a local data storage memory for larger amount of data.
If a wired network already exists in the building, more than one gateway can interface with the
wireless sensor network. The protocols and the distributed application software have to
support the interface between the existing wired network and the new wireless network.
Professional statistics and analysis software will allow the delivery of the BEC system’s
economic value to the user.
Technical Document of Page A-16 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure A-11. Architecture of the BEC system.
A.7.2 Requirements of Applications
Table A-9 shows the list of main characteristic system requirements and their description
and/or specification for this building energy conservation system application.
Table A-9. System requirements of the BEC system.
Requirement Description
10 ms – 15 min depending on application; 10 ms response time for
Ethernet to control some time critical devices up to 15 min for
Latency time
collecting data from metering system to a web server (Yello, EnBW,
E.ON).
Scalability About 200 nodes in a building
Throughput Messages are transmitted as a package and are small
Lifetime At least 2 years
Long range com Defined by GPRS or DSL
Security Sustainability of security algorithms at least 3 month
Data storage About 1KB
Sensors on node Temperature sensor
ID service Possibly RFID or other concept
Indication Silent alarms are sufficient
A.8 Intelligent Transportation and Traffic: Parking Management System
A.8.1 Description of Application
A.8.1.1 Motivation for Using Sensor Networks
Parking has always been one of the major nuisances for customers at big shopping malls,
theme parks, airports, and other public and private locations, especially during peak hours,
e.g., weekends and holidays. The lines forming in and out of the parking lots are a major
source of frustration and inconvenience for customers. Sensor networks are natural
candidates for parking management systems because the sensor network can accurately
monitor the status of each parking space. Wireless sensor networks have an advantage over
wired sensor network that the wireless one can be deployed in existing parking lots without
Technical Document of Page A-17 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
installing the cables for network and electricity to reach each sensor node. For this reason,
wireless sensor networks also can be used in road-side parking lots.
A.8.1.2 Solution Approach
Each parking space in the parking lot has a sensor node capable of detecting a vehicle via
magnetic sensor (or ultrasonic sensor). All the sensor nodes in the parking lot form a highly
reliable local sensor network. Gateway nodes are used to connect sensor network to local
area network. Parking service platform provides real time parking information and booking
service to end users. Once the status of a parking space changes, a sensor node can
immediately transmit a notification message via the gateway using a multi-hop wireless data
link. The occupation situation of the parking spaces on the parking service platform will be
updated simultaneously. Users can also query and book parking spaces by computers,
mobile phones, and other hand-held devices. The parking information can also be pushed to
target audiences by means of SMS message or IM message, etc.
A.8.1.3 Operational View and Description
Figure A-12 illustrates the architecture of a typical parking management system. The
system’s low-tier is the local sensor network deployed in a parking lot. Sensor nodes with
vehicle detection task are mounted on each parking space. Adjacent sensor nodes form
clusters and cluster heads connect with each other as a mesh network (see Figure A-13).
There can be one or more gateway nodes residing at the edge of the parking lot which
connects the sensor network to the local area network (see Figure A-13). Sensor data
generated by lower-tier sensor network is relayed to the parking service platform through the
local area network.
The upper-tier view of the system consists of several elements: parking service platform,
public network connection infrastructure, and user terminals. Parking service platform
provides functionalities such as data storage, parking guidance, and customer service like
query, booking, and billing. Public network connection infrastructure (Internet, etc.) connects
parking service platform and the end users.
GIS subsystem
Data Storage Subsystem
Traffic Management Center
Induce Information Disposal Subsystem Parking Enterprise
Network Management Disposal Subsystem Traffic-police Department
Billing Subsystem Public
Metropolitan Area Parking Area
Service Platform Internet
System Exploitation Enterprise
Server
Local Area Information
Local Area Local Area Information
Disposal Center
Disposal Center
VMS
VMS
Can be iMplemented by GPRS EDGE
TD Wifi‐City and other methods
GPRS or TD gateway GPRS or TD gateway GPRS or TD gateway GPRS or TD gateway
Parking Area
Charge Charge Charge Charge
Exit Exit Exit Exit
…… …… ……
Entrance Entrance Entrance Entrance
Figure A-12. Architecture of parking management system.
Technical Document of Page A-18 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure A-13. Parking lot sensor network.
A.8.1.4 Software Architecture from a Functional Point of View
The software architecture of a typical parking management system consists of two major parts:
(1) parking space sensing platform; and (2) parking management platform. Sensing platform
is the most fundamental part of the entire software system. Sensor nodes are self-organized
and networked. Sensor network service provision module exposes basic sensing services to
upper level parking management applications. Figure A-14 shows the structure of parking
management application platform and sensing platform. End users directly interact with the
user interface through which parking information is published and also services like query and
booking are provided. The core business logic is handled by backend service modules
including control, data storage, scheduling, guidance, and GIS.
Figure A-14. Software architecture for intelligent parting management system.
Technical Document of Page A-19 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
A.8.2 Requirements of Application
Table A-10 shows the list of main characteristic system requirements and their description
and/or specification for this parking management system application.
Table A-10. System requirements of parking management system.
Requirement Description
Sensor interface Multiple modality sensor supporting
Latency Less than 10 sec
Network coverage Up to several thousands of nodes deployed in a parking lot
False negative rate Very low under various environment conditions
False positive rate Extremely low (approximating zero) under complex conditions
Bandwidth Low data rate transmission
Information provision Rich information presentation and user-friendly interface
Communication range Tens of meters to several kilometers
On-duty time At least 1 year 24hrs on-duty time before next maintenance
Network and linkage Reliability transmission supporting for long 24hrs on-duty time
Location resolution Less than 3meters
Directory and ID service Directory and ID supporting
City scale information storage on parking management platform,
Database and storage
low storage requirement on sensor nodes
Security Mid-High Security level
A.9 Intelligent Transportation and Traffic: Harbour Freight Intelligence System
A.9.1 Description of Application
A.9.1.1 Motivation for Using Sensor Networks
With the growth of international container freight business, how to increase the harbour
throughput and harbour yard’s scheduling efficiency becomes a critical problem for efficient
harbour operations. Container trucks have to wait for a long time at the wharf container gate.
At the harbour yard, a large number of trucks run and operate without order. This problem
greatly obstructs the growth of the harbour throughput and consequently hinders maximizing
an overall financial earning potential of the yard. Thus, this situation becomes an urgent
issue to be resolved. In the harbour freight management system, cargo needs to pass
through a number of processing points, such as, truck companies, freight forwarders, stack-
yards, container gates, and the customs. The efficiency and safety at each processing station
will affect the entire freight management system. The processing points’ improvement needs
to keep up with the growth of the port throughput. With the development of active RFID and
wireless sensor network (WSN) technology, a sensor network-based freight management
system becomes a good solution to ensure the high efficiency, safety and lower cost for each
processing point.
A.9.1.2 Solution Approach
Each container truck will be equipped with an intelligent terminal with LCD display, which
integrates a UHF passive module and a 433MHz active module, which provide the longest
communication distance of about 10 meters and 200 meters, respectively. The active module
can be regard as active RFID tag or WSN node. RFID readers will be set up at truck
companies, freight forwarders, stack-yards, container gates, and the customs. These nodes
will construct themselves into a network via management software (Figure A-15).
Technical Document of Page A-20 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
A.9.1.3 Operational View and Description
Figure A-16 shows the operational concept for the RFID system on the left hand side and the
sensor node system on the right for a harbour freight intelligent system.
At stack-yards, anchor nodes are strategically positioned to locate all the facilities and
personnel. These nodes have known coordinates and form a wireless “position” network. The
active module in this terminal can also access this network under “localization mode.” Be able
to identify the container trucks is one of the essential tasks in the entire logistics process.
When a container truck passes through the processing points, a unique identification will be
reported via a UHF module. And then the network sends the harbour operation instructions
(including driving guides) to the truck driver, and the operational instructions will be received
at the truck via the 433MHz module. This automation can substitute the existing manual
check method (which avoids paper exchange time). The automation can greatly improve the
efficiency of the entire logistics chain. At the same time, system authorization is needed at
the intelligent terminal. All the processing data are encrypted to ensure system security,
privacy, and safety.
Figure A-15. Container gate system operational architecture view (showed in red).
Yard lifting system is another essential and important task of the entire logistics process in the
harbour operations. The real-time scheduling of the container trucks, container cranes, and
personnel can be performed by the localization mode of the sensor network system, which
increases the utility rate of the yard resulting in a better financial gain. Each 433MHz active
module processes the data with localization algorithms after receiving the location request
response signals from the WSN nodes. The result is sent to the neighbouring node, and then
to the control centre of the localization system via WSN network. With the location
information, the system will compute and deliver the location of the trucks, cranes, and
personnel. The location information will be sent to the scheduling algorithm.
Technical Document of Page A-21 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure A-16. RFID- and WSN-based harbour management.
A.9.1.4 Software Architecture from a Functional Point of View
In order to support this harbour operation scenario, a distributed application software system
becomes necessary. This means that some application modules or “software functions” have
to be installed on the RFID and/or WSN devices. Table A-11 shows the functions integrated
in each type of device.
Table A-11. Software functions implemented on the different nodes.
Functions / Nodes RFID reader RFID terminal Sink node Anchor node
Long range communication X
Short range communication X X X X
Security services X X X X
Data storage services X X X
Data processing services X X X
Linkage services X X X
Self localizing service X X
Routing service X X X
Identification service X X X X
Indication service X X X
A.9.2 Requirements of Application
Table A-12 shows the list of main characteristic system requirements and their description
and/or specification for this harbour freight intelligence system application.
Table A-12. System requirements for harbour yard management system.
Requirement Description
Less than 2 sec from arrival to pass the gate; less than 2 sec from
Latency time location request to showing the location on navigating terminal or
monitoring desktop in the office
Scalability No more than a hundred devices on a shipping yard
Location messages are transmitted as a packet or piggybacked as a
Throughput
short segment or normal data packet
Lifetime At least more than 3 years
Technical Document of Page A-22 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Requirement Description
Long range com Defined by Wi-Fi, GSM and SatCom-systems
Short range com Up to 200 meters
Security Sustainability of one security session at least 3 month
Data storage Hundreds kilo-Bytes acceptable (estimation)
Processing power Depend on device type, to be defined
Linkage service Critical to security application
EPC concept could be used for identification of node and product, and
ID service
GB standards pre-empt if available
A.10 Energy & Utility Distribution Industry: Automated Meter Reading
A.10.1 Description of Application
A.10.1.1 Motivation for Using Sensor networks
Reading energy and utility (e.g., water, gas, and electricity) meters in apartment buildings or
in residential areas is performed by simply “pinging,” e.g., transmitting a meter data request,
the meters to collect the meter data. The pings are sent out at a certain time interval, often
without any acknowledgement of correct reception of the data. One method in collecting the
meter data is to use a simple telemetry transmitter for pinging. The transmitter sends out the
pings, for example, every 10 seconds. The meter transmits its reading when it detects the
ping. The meter data is received by a receiver installed on a data collection car. This car
drives the street where the data is being collected a pre-selected speed to ensure the data
collection.
The disadvantages of the method described above are:
Since the transmitters of the meters are not synchronized, the reception at the receiver
is prone to packet collisions, resulting in data loss of some meter readings.
Because the meters do not know whether the transmitted meter data is received
correctly, these meters send the data over and over again whenever the pings are
received. This reduces the meter’s battery life.
This method is very limited and cannot be controlled because it is only a single
direction communication from a meter to the car (i.e. from car to a meter is a simple
pinging, not being considered as “communicating”).
Other method is to use an integrated GSM module, which is more reliable; however, this
approach will suffer due the needs of a lot of battery power and is also more expensive. Yet,
sensor network-based solutions are cost-effective and resolve those disadvantaged found in
the other methods. Cars or personal to read the meters will not be required, and a more
reliable data communication is established allowing less data loss and more flexible meter
control.
A.10.1.2 Solution Approach
The idea is that every meter device in an apartment building or residence is equipped with a
wireless sensor node. These sensor nodes on the meters are enabled to build a meshed
wireless network and can communicate bi-directionally with each other. Via a multi-hop
communication, the meter readings can be sent to a central master node which could be
located in the basement. All the meter data are gathered at the central master node and are
transferred to a data collection office or a billing centre office via a wide range communication
system like GSM or power line. Such a wireless sensor network-based system offers a very
reliable communication, that is, the sensor nodes are all synchronized and the data
communication between nodes is secured by acknowledgement of received packets. Because
Technical Document of Page A-23 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
the data is transmitted only to its direct neighbouring node, the system can operate at a very
low power extending the battery life potentially up to 10 years with standard batteries.
Another advantage of the sensor network based system is that all transmitted meter data will
be received, which provides operators a good view of gas or electricity consumption on a daily
basis. A wireless sensor network offers a bi-directional communication enabling the
transmission of the meter data to the master node and also the control messages from the
office to the metering devices, e.g., to ask for the actual meter reading because of a customer
request.
A.10.1.3 Operational View and Description
The operation description for the wireless sensor network-based automated meter system is
quite simple, it consists of two components:
Identical sensor nodes that can be integrated into meter devices and can communicate
with the meters via a serial interface using the MBus 2 message format.
The master node, from which the network is synchronized and organized in a tree-like
topology. The master node has an interface to a data storage or PC to save the
received meter data. It also interfaces to a wide range communication system to send
the data to the office or receive control data from the office.
A.10.1.4 Software Architecture from a Functional Point of View
To support this scenario, a distributed application software system is needed. Table A-13
shows the different functions needed on the different types of nodes.
Table A-13. Software functions implemented on the different nodes.
Functions / Nodes Sensor Master
Long range communication X
Short range communication X X
Clustering Services
Routing Services X
Security services X X
Data storage services X X
Control Services X X
Linkage services X
A.10.2 Requirements of Application
Table A-14 shows the list of main characteristic system requirements and their description
and/or specification for this automated meter reading application.
2 From http://www.networksorcery.com/enp/protocol/mbus.htm: Mbus is a lightweight message-oriented
coordination protocol for group communication between application components. The Mbus provides automatic
location of communication peers, subject based addressing, reliable message transfer and different types of
communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The
IP multicast scope is limited to link-local multicast.
From http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a00801e1dbf.shtml: The
Maintenance Bus (MBUS) is a 1 Mbps redundant Controller Area Network (CAN) serial bus that connects the
route processor (RP), the line cards (LCs), the switch fabric cards (SFCs), the power supplies, and the fans
(except for the 12008). Due to its high fault-tolerant design, the CAN bus is commonly used in the industrial
control area.
Technical Document of Page A-24 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Table A-14. System requirements.
Requirement Description
Meter data must arrive within some minutes at the master
Latency time
node
Scalability Not more than 100 nodes in an apartment building
Throughput Meter reading messages are transmitted as small packages
Lifetime At least 10 years
Defined by mobile network, power line-communication or
Long range communication
existing LAN/WAN (DSL)
Short range communication 3 meters up to 10 or 20 meters
Security At least 10 years sustainability for mechanism
Data storage A few Kbytes acceptable (estimation)
Linkage service Critical because manipulations have to be avoided
A.11 Asset Management: Management of Medical Devices in Hospitals
A.11.1 Description of Application
A.11.1.1 Motivation for Using Sensor Networks
Many medical devices used in hospitals are large and expensive (e.g., CT, MRI, etc.); yet,
many others are relatively smaller and inexpensive (e.g., EEG, ECG, EMG, etc.). The large
and expensive devices may not applicable for this application; but the smaller ones are.
Managing these devices is critical as they are directly related with the care for patients. This
management includes not only tracking the devices’ physical locations, but also their status,
e.g., repaired, disinfected, maintenance records, availability/schedule. To minimize the risk
for the patients, the devices have to be accessible and in good condition. Since maintenance
processes are based on paperwork, the real condition of devices often does not match with
the information in the hospital’s IT systems. Wireless sensor networks might be the solution
for this type of problem. The wireless sensor network technology promises searching time
reduction, simple inventory processes, and easy usage documentation, etc. The higher
demand in using the existing devices forces hospitals to work with a much smaller security
stock, e.g., back-up or spare devices. RFID does not solve the problem because of high
transmitting power which is not allowed in certain medical areas and insufficient spatial
coverage.
A.11.1.2 Solution Approach
The main idea is to attach miniaturized or micro sensor nodes to medical devices and to build
up an anchor network. The nodes on the devices are always wirelessly connected with one or
more anchor nodes. A user’s request for the position and state of a dedicated device sent to
the network will cause the network to generate the requested information and to send it back
to the user. Other information, e.g., maintenance records, last time disinfected, can be
retrieved from the database attached to the wireless sensor networks once the desired device
is located and available.
A.11.1.3 Operational View and Description
Figure A-17 shows the operational architecture view illustrating how the network determines
the location and state of a medical device. Anchor nodes which know their positions and
store context information, like “I am representing a maintenance centre and every device in
the same room with me is in a repairing process” or “I am representing a storage room and
Technical Document of Page A-25 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
everything in the same room with me is accessible for medical staff,” are installed at different
locations in a hospital.
Medical devices carry mobile nodes. These nodes communicate with the anchor nodes within
its reach, for example, signal strength indication mechanisms to assign themselves to the
anchor node and its context. The context information can then be used to create events. If a
node is assigned to a repair and maintenance shop node for more than two hours and if
maintenance staff has not started the maintenance procedure on the assigned device, the
node would send an alarm through the network. A supervisor sitting in front of an “asset
management cockpit” at a central PC will then be able to react and initiate the maintenance
process.
Backend App
user
gateway &
Server
device node
anchor node
medical device
Figure A-17. Operational view of infrastructure for management of medical devices.
Another situation might be that medical staff is looking for a working device for a surgery. In
this case, a broadcast message is sent to the network from a central point of use via an
application server to a gateway node which connects both the wired infrastructure in a
hospital and the wireless sensor network. All available devices of the same type will reply
with their identification number, state, and locations. Additionally, the hospital staff could be
equipped with a smart phone with an integrated node. If a member of the staff is near a
certain device, the person may use his or her phone to query the condition of the device.
A.11.1.4 Software Architecture from a Functional Point of View
To support this medical device management scenario, a distributed application software
system is needed. Table A-15 shows the different functions needed on the different types of
nodes.
Table A-15. Software functions implemented on the different nodes.
Functions /
Device Anchor Gateway Phone
Nodes
Short range
X X X X
communication
Security
X X X X
services
Data storage
X X X X
services
Technical Document of Page A-26 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Functions /
Device Anchor Gateway Phone
Nodes
Data processing
X X X X
services
Control service X
Linkage services X X
Self localization
X X
services
Identification
X X X X
service
Indication
X
service
A.11.2 Requirements of Application
Table A-16 shows the list of main characteristic system requirements and their description
and/or specification for this management of medical devices in hospitals application.
Table A-16. System requirements.
Requirement Description
Latency time Not critical, 15 minutes or 1 hour is acceptable
Scalability Less than 50 devices in a cluster
Throughput Small packages containing position and condition data
Lifetime Up to 2 years between two maintenance events
Short range
Up to 3 meters
communication
Security Sustainability of encryption mechanisms up to 2 years
Data storage 20 to 50 Kbytes minimum due to security requirements
Processing power To be defined
Control service Ability to make the device temporarily unserviceable
Linkage service Critical due to security applications
Loc resolution Tag to be assigned to rooms and contexts (a few meters)
ID service EPC and or equipment number of the hospital
Indication Buzzer and optical indication
Spatial requirements Minimum distance between node and device (e.g., 7 cm)
Regulatory issues Housing without slots which can be sterilized
A.12 Homeland Security: Anti-Intrusion System for Border/Perimeter Control
and Virtual Fences
A.12.1 Description of Application
A.12.1.1 Motivation for Using Sensor Networks
The objective of sensor network-based anti-intrusion system is to block intruders from
important, vital, or restricted regions, areas and/or buildings by an advanced, high security
level, virtual perimeter fences. Generic requirements for an anti-intrusion system include low
false alarming rate, low target-miss probability, instant event response, automatic warning
mechanism, and full surveillance coverage under various environments and conditions. Other
Technical Document of Page A-27 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
features such as robustness, extensibility, intelligence, and high-level information aggregation,
event localization, tracking and state prediction may also be needed. Sensor network is a
promising approach in designing sophisticated anti-intrusion system.
A.12.1.2 Solution Approach
Sensor nodes in the network are equipped with different types of sensors to detect various
intrusion events which originate from ground, underground, and even low-altitude airspace.
Sensors for underground intrusion detection, proximity detection, range measurement, and
even video sensors are collaboratively used not only to decrease false alarm rate in event
detections, but also to enhance correct probability of target classification and increase the
accuracy of intruder tracking. Different types of sensors have different capabilities in sensing
and detecting targets and events. Sensor nodes in the network are organized in an ad-hoc or
hierarchically clustered structure. Low level sensory data can be centrally fused in regional
cluster header nodes or collaboratively processed among sensor nodes in a distributed
manner. The post-processing information is then delivered to a control centre for high-level
information fusion. Based on the results, end users in the control centre can initiate a proper
event or emergency response operations, such as voice alarming, light warning or security
guard patrol actions. Normally, the sensor network size can be large due to wide coverage
area depends on applications.
Choosing right sensor types for target application is very important and sometimes it is not an
easy task. For example, nodes equipped with magnetic sensors can give high SNR signals in
sensing ferromagnetic targets; On the other hand, they have difficulties in detecting non-
ferromagnetic intruders. Another example is that seismic sensor nodes can successfully
discriminate human intruders from other objects, but they can easily give false alarms on
other types of vibrations if the sensor node does not have proper processing algorithms. A
simple infrared (IR) sensors used for motion detection can detect an intruder approaching, but
the detectable ranges could be much shorter than seismic sensors or other types of sensors.
In addition to the differences in sensing capability, sensor nodes in the networks may have
different communication properties, such as bandwidth and maximum transmission range,
varying storage capabilities, and different residual energy levels. These differences should
also be considered in designing the anti-intrusion system.
The dynamic information gathered from the sensor network is characterized by a capability
declaration entity (CDE) in Collaborative Information Processing (CIP). Before any CIP
procedures, the participating sensor nodes should know what their collaborating nodes are
capable of. Collaborative strategy planning entity (CSPE) handles problems which and how
sensor nodes should involved in collecting spatial and temporal data for CIP.
The other main entity in CIP is the communication requirement specification entity (CRSE).
When an event is detected by perimeter sensors in the system, an alarm or warning message
should be transmitted to an on-duty security guard as soon as possible without any delay. A
video node is triggered on-demand or automatically to visually verify an intruder, the
maximum bandwidth transmission is required to support high data rate of video
communication. CRSE specifies dynamic communication requirements in sensor network-
based anti-intrusion system.
A.12.1.3 Operational View and Description
An operational view and its architecture of a sensor network-based anti-intrusion system is
shown in Figure A-18. Nodes, units, and elements in the network are organized in a layered
structure. The lowest layer is for perimeter sensor node layer. Sensor nodes are deployed
along the boundary or border of the surveillance area. Multiple modality sensor nodes with
specific characteristics (three modalities shown in Figure A-18, the red, blue, brown shapes)
are used to detect different kinds of intrusion events. Sensor nodes in surveillance coverage
areas are normally overlapped purposely for reliable intrusion detection. Modality fusion and
collaboration information processing among these nodes decrease false alarm rate and event
miss probability. The middle layer consists of regional cluster header nodes. High data rate
sensors, such as video image sensors, can also be classified into the middle layer. Intensive
Technical Document of Page A-28 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
information abstraction, aggregation, and fusion should be implemented to meet constrained
communication bandwidth and to obtain high level information. The fusion and CIP
processing should also be performed collaboratively to support energy-efficiency. In case of
video or multimedia sensor data, high data rate transmission unit and information processing
unit are involved. The high layer in this architecture diagram is the user layer, which is mainly
covered by Command & Control Centre in Figure A-18. High capability server and large
capacity storage equipments are used to provide high level information fusion and user-
friendly information presentation. Response actions or operations on intrusion events are
triggered by components in this layer.
A.12.1.4 Software Architecture from a Functional Point of View
Software architecture of a typical sensor network-based anti-intrusion system is shown in
Figure A-19. The software architecture can be conceptually composed of four software
platforms – sensor, network, collaborative information processing, and service software
platforms. Different types of application act as service users on these platforms. Within this
architecture, Command & Control Centre is to implement the service platform. The right side
of Figure A-19 shows software components in Command & Control Centre. Command &
Control Centre has database, database management module, GIS server, processing module,
and information web publication as its main components. The centre’s concerns are mainly
on information provision, high-level information processing, event handling, system
maintenance and querying service providing. These concerns are the generic functionalities
of the service platform.
Figure A-18 Operational view of a typical sensor network anti-intrusion system.
Technical Document of Page A-29 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure A-19. Typical sensor network anti-intrusion system.
A.12.2 Requirements of Applications
Table A-17 shows the list of main characteristic system requirements and their description
and/or specification for this border control and virtual fences used as anti-intrusion systems
application.
Table A-17. System requirements.
Requirement Description
Sensor interface Multiple modality sensor supporting
Collaborative Critical for high performance in event detection, localization,
information Processing classification, and tracking
Latency time Less than 5 sec from intrusion happening to intrusion detection
Response time Less than 10 sec for triggering event handling operation
Network coverage More than tens of hundred nodes covering 1~10 Km distance
False positive rate (false Very low with interferences and changing environment conditions
alarm)
False negative rate Extremely low (approximating zero) under complex conditions
(miss)
High data rate High data rate transmission supporting for video image sensors
transmission
Information provision Rich information presentation and user-friendly interface
Actuator Intrusion handling mechanisms
Communication range Tens of meters to several kilometres
On-duty time At least 1 year 24hrs on-duty time before next maintenance
Network and linkage Reliability transmission supporting for long 24hrs on-duty time
Directory and ID service Directory and ID supporting
Database and storage GIS information and large historical storage in C&C centre
Technical Document of Page A-30 of 30
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Annex B
B Reference Architecture Development Process
In this annex, we discuss a system architecture process to develop sensor network reference
architecture (SNRA). We provide example architecture diagrams and views in order to aid the
discussions.
B.1 The Two Main Questions to be Answered for Reference Architecture
In developing Sensor Networks Reference Architecture (SNRA), there are two main questions
to be asked:
What functionalities should be described by SNRA?
a. Although there could be many functions/functionalities that can be provided by
sensor networks, there are basic functionalities (e.g., building blocks) in all sensor
networks, e.g., survey and/or search, detect and/or measure, locate and/or track,
etc.
b. The basic functionalities in SNRA include communication, networking, information
processing, storage, description, identification, directory and security, and other
functions.
What would be the approaches to SNRA?
a. Sensor networks (SN) are diverse in their applications and usages, and for this
reason, it would be challenging to develop a single reference architecture that
represents all sensor network applications and usages in all market domains.
However, it is also believed that good reference architecture allows the abstraction
of multiple implement patterns (e.g., application profiles). It is also recognized that
proper reference architecture representing each market domain can be beneficial
for those who are within that market domain. Then, the local reference
architecture (the market domain specific) can be derived from the global reference
architecture (the generalized abstraction or reference architecture of sensor
networks).
b. The sensor networks standards will greatly help in the development of such
reference architecture for different market segments.
c. Although sensor networks are diverse in its applications and usage, the unified
reference architecture still can be constructed because the commonalities and
rules can be described.
d. A flexible and scalable reference architecture which meets the diverse
requirements of applications needs to be developed. The essential functionalities
such as multiple tasks and data flow mode supporting, inter-network connection
should be implemented.
B.2 Applying System Architecture Development Process for SNRA
The SNRA, based on system architecture development, for studying and aiding sensor
network standards establishment will follow the following procedure:
1. Discussion how to use the SNRA for sensor networks standards development
a. Architecture understanding: Use the open group description to detail both architecture
and stakeholder requirements within the planned architecture development.
Technical Document of Page B-1 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
b. Architecture artefacts to standards mapping: System architecture elements and
models that map to a standard or a set of standards describe the target products (e.g.,
sensor network, applications, etc.) in terms of standard-driven requirements, e.g.,
technical standards and system requirements.
c. System communication description: (1) Depict pertinent information about
communication systems, communication links, and communication networks and (2)
Useful for document how interfaces are supported by physical media.
d. The steps between Concept to Architecture
Step 1: Determine Intended Use of Architecture: Describing the intended use
explains how the architecture is meeting data requirements of the organizational
process and why the architecture is being developed. The purpose also explains
what the architecture will accomplish and how it may affect organizations or
system development. The purpose shall clearly and concisely establish exit
criteria to measure the customer’s satisfaction with the architecture in meeting
overall requirements. All architecture development shall be preceded by an
approved purpose and scope portions of the Executive Summary.
Step 2: Determine Scope of Architecture: The scope defines the boundaries that
establish the depth and breadth of the architecture. It bounds the architecture’s
problem set and helps define its context. Other context considerations that shall
be defined are the environment, the organizational mission and vision, the subject
area, time frame, and intended users.
Step 3: Determine Data Required to Support Architecture Development: Based
upon the input from the process owner, the operational, systems and services, and
technical standards view data entities, attributes, and rules are selected. The
required level of detail to be captured for each of the entities and attributes is also
determined during this step. These considerations establish the type of data
collected in Step 4 that relates to the architecture structure.
Step 4: Collect, Organize, Correlate, and Store Architecture Data: All new
architecture development efforts shall leverage existing architecture artefacts to
the greatest extent possible by first accessing and reviewing registered
architecture content. Locating and reusing published and accessible architecture
content from other sources can significantly reduce initial development time and
redundant development efforts, while capitalizing on taxonomies of standardized
reference data. Once collected, the architecture data shall be catalogued,
organized, and correlated into automated repositories to permit subsequent
analysis and reuse. Discovery metadata shall be registered in a repository as
soon as it is available to support discovery and enable federation Enterprise
Architecture (EA) Business Reference Model (BRM).
Step 5: Conduct Analysis in Support of Architecture Objectives: The architecture
data shall be analyzed to determine its effective support of the initial process
owner requirements. Completion of this step prepares the architecture for
approval by the process owner. An additional result of this step is the
identification of additional data collection requirements to complete the
architecture and better facilitate its intended use through iteration of the
architecture process (repeat steps 3 through 5 as necessary).
Step 6: Document Results in Accordance with Architecture Framework: The final
step in the process involves rendering architecture products based on queries of
the underlying data. For presentation purposes, graphic and tabular products are
necessary to visualize concepts in a meaningful way to support the use of the
architecture by intended audiences as identified in the Executive Summary.
Standard user-defined custom products are used to illustrate the various aspects
of the architecture based on the underlying data. Any architecture visualization
Technical Document of Page B-2 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
should be reusable and shareable, and include the underlying data. A number of
architecture tools are available to support this step.
2. Systematic SNRA development based on system architecture development procedure
Lead to functional, physical, information architectures of the current, existing sensor
networks, if such architectures do not exist.
Perform comparison and contrast of various sensor networks, SN applications and
services for commonalities and differences identification.
Help evaluating and determining sensors, networks, data, and service standards for
interfaces and interoperability in sensor networks.
Determine the applications or market-segments that needs its own reference
architectures.
The development procedures are described pictorially in Figure B-1. The mapping of the
artefacts to the standard development is shown in Figure B-2.
Figure B-1. Architecture artifacts and their relationships 1 .
3. The following architecture products are the key ones that need to be developed and
recommended to be included in SNRA.
a. High level operational concept description
1 DoDAF Manual Volume 1, version 1.5.
Technical Document of Page B-3 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
b. Operational node connectivity description
c. Activity model
d. Operational information exchange matrix
e. Technical standard profile
f. System interface description
Figure B-2. Architecture artifacts to standard mapping 2 .
4. In addition, the following architecture products, depending of the levels of SNRA
description and standards needs, may be required.
a. System communications description
b. System data exchange matrix,
c. System functionality description
d. System performance parameter lists
e. System evolution description
f. Technical standards forecast
g. Conceptual data model
2 DoDAF Manual Volume 1, version 1.5.
Technical Document of Page B-4 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
h. Physical schema/data model
Reference architecture is the generalized architecture of several end systems that share one
or more common domains, giving direction downward and requiring compliance upward.
Reference architecture provides a consistent point of departure for implementing solutions so
that each implementation:
Follows a consistent decomposition and design pattern;
Reduces cost by exploiting opportunities for reuse of services, products, data
definitions, etc.;
Reduces schedule by starting with a Core Architecture to be tailored for
Implementation; and
Reduces risk by incorporating required global capabilities and profits from lessons
learned and related expertise
B.3 Using SNRA to Identify and Develop Sensor Network Standards
Figure B-3 pictorially describes how SNRA can help developing sensor networks standards.
Sensor networks do cover a large variety of business and applications. The concern would be
to have reference architecture so general it would be meaningless; therefore, the reference
architecture project should be approached with care.
Figure B-3. SNRA’s role in SN standard development.
B.4 Some of the Key Referece/System Architecture Diagrams and Artefacts
Some architecture models and artefacts are well suited for describing SNRA such as an
operational node description as shown in Figure B-4 and Figure B-5.
Technical Document of Page B-5 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure B-4. Operational Node Connectivity Description.
Figure B-5. Sensor Network Operational Node Description.
These operational node descriptions show, on a higher level, a group or large area of sensor
networks. This could be a building or larger network. The sensor network description as
shown in Figure B-4 could be a room or floor of the building. This is a lower level that
describes the information exchanges within a sensor network node where Figure B-5 shows a
wide area or grouping of sensor network nodes.
Also, there are common functions of the sensor network nodes such as monitor, detect, track,
react, and report. These could be shown in functional description or flow diagram. Each of
these architecture artefacts could be described using UML diagrams and use cases as shown
in Figure B-6.
Technical Document of Page B-6 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure B-6. Use Case Operational Node Description.
Each SNRA artefact needs to be judged by the depth of information required to make the
artefact. Some artefacts will require a lower level of information than others but each
architectural description needs to maintain the similar level of depth throughout the
architecture product. The reference architecture should contain the core architecture products
as described earlier and also listed below:
Executive Summary – Scope, purpose, intended users, environment depicted,
analytical findings
High-Level Operational Graphic – High-level graphical/textual description of
operational concept
Node Description – Operational nodes, connectivity, and information exchange need
lines between nodes
Information Exchange Matrix – Information exchanged between nodes and the
relevant attributes of that exchange
Activity Model – Capabilities, operational activities, relationships among activities,
inputs, and outputs; overlays can show cost, performing nodes, or other pertinent
information
Interface Description – Identification of systems nodes, systems, system items,
services, and service items and their interconnections, within and between nodes
Technical Standards Profile – Listing of standards that apply to Systems and
Services View elements in a given architecture
Additional products could and should be created to support the core architecture products.
These products would be part of the decisions made in the architecture planning sessions.
Each architecture product should be built with a purpose and be required by a stakeholder.
Architectures that are built without purpose or need will not be used; they will become shelf-
ware and wasted time and money.
System Interface description should be kept and information exchange level should not go
down to the physical level. The physical level should be described in a supporting product
Technical Document of Page B-7 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
called a Communications Description which is where the actual communications are described
(i.e. wireless or wired, topology, routing etc.).
A typical interface description may come in multiple flavours as shown in the following
diagrams – Node to node interface, system-to-system interface, and inter-nodal interface,
shown in Figure B-7, Figure B-8, and Figure B-9, respectively.
Figure B-7. System Interface Description (Node to Node Interface).
Figure B-8. Interface Description (System to System Interface)
Technical Document of Page B-8 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure B-9. Inter-nodal Interface Description.
In addition to depicting systems nodes and systems, the interface description addresses
system interfaces. An interface, as depicted in Interface Description, is a simplified, abstract
representation of one or more data/communications paths between systems nodes or between
systems (including communications systems) and is usually depicted graphically as a straight
line. The Interface Description depicts all interfaces that are of interest for the architecture
purpose. An interface is the systems representation of a Node Description depiction of a
need to exchange information through a need-line. A single need-line shown in the Node
Description may translate into multiple system interfaces. The actual implementation of an
interface may take more than one form (e.g., multiple physical links). Details of the physical
links and communications networks that implement the interfaces are documented in
Communication Description. Characteristics of the interface are described in Systems-
Systems Matrix. System functions and system data flows are documented in a Systems
Functionality Description, and the system data carried by an interface are documented in the
Systems Data Exchange Matrix.
An interface between systems nodes or systems may be annotated as a Key Interface (KI). A
KI is defined as an interface where one or more of the following criteria are met:
The interface spans organizational boundaries (may be across instances of the same
system, but utilized by different organizations).
The interface is mission critical.
The interface is difficult or complex to manage.
There are capabilities, interoperability, or efficiency issues associated with the
interface.
If desired, annotations summarizing the system data exchanges carried by an interface may
be added to Interface Description.
Several versions of Interface Description can be developed to highlight different perspectives
of the system interfaces. For example, an inter-nodal version of the product describes
systems nodes and the interfaces between them or the systems resident at the systems
nodes. An intra-system version describes subsystems of a single system and the interfaces
among them. Other versions may also be developed, depending on the purposes of the
particular architecture.
Technical Document of Page B-9 of 9
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Annex C
C Sensor Networks Related Activities within JTC 1
This annex discusses the current understanding of other activities on sensor networks in
international standardization bodies and consortia and fora where specifications related to
sensor networks are being developed.
C.1 ISO/IEC JTC 1 SC 2 – Code Character Sets
Standardizations of Coded Character Sets.
Scope: Standardization of graphic character sets and their characteristics, including
string ordering, associated control functions, their coded representation for information
interchange and code extension techniques. Excluded: audio and picture coding.
Relevance to Sensor Networks
o No strong relevance to sensor networks.
C.2 ISO/IEC JTC 1 SC 6 – Telecommunications and Information Exchange
between Systems
Standardization of telecommunications and information exchange between systems
Scope: Standardizations on standardization in the field of telecommunications dealing
with the exchange of information between open systems including system functions,
procedures, parameters, and equipment, as well as the conditions for their use. This
standardization includes both the lower layers that support the physical, data link,
network, and transport protocol and services, including private integrated services
networking, as well as the upper layers that support the application protocols and
services such as Directory and ASN.1.
Standards with 4 WGs
Relevance to Sensor Networks
o Numerous work areas related to SN: See SC 6 contributions in SGSN N014 and
N015.
o SC 6 has the two New Projects that are related to sensor networks:
ISO/IEC CD 29180 – Telecommunications and Information Exchange Between
Systems-- Security framework for ubiquitous sensor network.
ISO/IEC NP 29182 – Reference architecture model for Sensor network
applications and services.
C.3 ISO/IEC JTC 1 SC 7 – Software and Systems Engineering
Standardization of software and systems engineering.
Scope: Standardizations of processes, supporting tools and supporting technologies
for the engineering of software products and systems.
Relevance to Sensor Networks
o Does not handle network protocols including PHY, MAC, and NWK layers.
Technical Document of Page C-1 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o Software and systems engineering may be applied to the development of network
software.
C.4 ISO/IEC JTC 1 SC 17 – Cards and Personal Identification
Standardizations of cards and personal identification.
Scope: Standardization in the area of:
o identification and related documents,
o cards, and devices associated with their use in inter-industry applications and
international interchange.
Relevance to Sensor Networks
o Cards and personal identification themselves are not directly related with sensor
networks.
o However, personal identification codes or cards can be embedded in a terminal
that he/she carries.
C.5 ISO/IEC JTC 1 SC 22 – Programming Languages, Their Environments and
System Software Interfaces
Standardizations of programming languages, their environments and system software
interfaces.
Scope: Standardization of programming languages (such as Cobol, Fortran, Ada, C,
C++, Lisp and Prolog) and their environments (such as POSIX).
SC 22 also produces common language independent specifications to facilitate standardized
bindings between programming languages and system services, as well as greater interaction
between programs written in different languages.
A new project involves documenting the vulnerabilities of various programming
languages. Program portability between different implementations of the same
language is a key goal.
Relevance to Sensor Networks
o Programming language, their environments and system software interfaces are
important in developing higher layer protocol stacks than PHY of sensor networks.
o The technology itself is not directly related with the standardization works of
sensor networks.
C.6 ISO/IEC JTC 1 SC 23 – Digitally Recorded Media for Information
Interchange and Storage
Standardizations of digitally Recorded Media for Information Interchange and Storage
Scope: Standardization in the field of removable digital storage media utilizing optical,
holographic and/or magnetic recording technologies for digital information interchange,
including:
o algorithms for the lossless compression of data
o volume and file structure
o methods for determining the life expectancy of digital storage media
Technical Document of Page C-2 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o methods for error monitoring of digital storage media.
Relevance to Sensor Networks
o Not directly related with sensor networks
C.7 ISO/IEC JTC 1 SC 24 – Computer graphics, image processing and
environmental data representation
Standardizations of computer graphics, image processing and environmental data
representation
Scope: Standardization of interfaces for information technology based applications
relating to:
o computer graphics,
o image processing,
o virtual reality,
o environmental data representation and
o interaction with, and visual presentation of, information
Included are the following related areas: Modelling and simulation, related reference
models; application program interfaces; functional specifications; representation
models; interchange formats, encodings and their specifications, including metafiles;
device interfaces; testing methods; registration procedures; presentation and support
for creation of multimedia and hypermedia documents.
Excluded: Character and image coding; coding of multimedia and hypermedia
document interchange formats, JTC 1 work in user system interfaces and document
presentation; ISO TC 207 work on ISO14000 environment management, ISO TC211
work on geographic information and geomatics; and software environments as
described by ISO/IEC JTC 1 SC22.
Relevance to Sensor Networks
o Standardized environmental data representation is used for the sensor networks.
C.8 ISO/IEC JTC 1 SC 25 – Interconnection of Information Technology
Equipment
Standardizations of interconnection of information technology equipment
Scope: Standardization of microprocessor systems; and of interfaces, protocols and
associated interconnecting media for information technology equipment, generally for
commercial and residential environments. Development of standards for
telecommunication networks and interfaces to telecommunication networks is excluded.
Relevance to Sensor Networks
o WG1 – Home electronic systems
Task: Electronic systems for the interaction and control of electrical and electronic
devices in home and small business environments
Relevance: Home network systems which require sensors and sensor networks.
o WG3 – Customer premises cabling
Technical Document of Page C-3 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Task: Standardization of characteristics of cabling system for customer premises
including test procedures and planning and installation guides
Relevance: Premises cabling which may serve as the backbone networks for the
sensor networks.
o WG 4 – Interconnection of computer systems and attached equipment
Task: Standardization of microprocessor systems and of interfaces and protocols
for the interconnection of computer systems and computer peripheral equipment
o PTTT – Project team taxonomy and terminology
The Taxonomy project serves the purpose to find areas where standards are
missing and where standards are overlapping and competing. The Taxonomy
projects will result in a two part Technical Report. The first part describes a
method developed in PTTT whereby standards can be categorized, i.e. to find a
taxonomy scheme. The other part consists of the table containing the categorized
specifications based on the abovementioned scheme. This may for example lead
to the identification of NWIPs.
The Terminology project will collect the terms and their definitions found in
standards related to Intelligent Homes with the emphasis on Home-Networking. It
turns out that several terms have different definitions in different specifications,
which makes it difficult for SC 25 to coordinate the standardization activities.
Coordination requires the experts from different branches to clearly know what the
terms used actually means and stands for. In case several definitions for a single
term is used the project should identify which of the definitions is preferred.
Both the Taxonomy and Terminology projects will lead to Technical Reports that
will be regularly updated and will assist SC 25 in their effort to respond to the JTC
1 request
C.9 ISO/IEC JTC 1 SC 27 – IT Security Techniques
Standardizations of IT security techniques
Scope: The development of standards for the protection of information and ICT. This
includes generic methods, techniques and guidelines to address both security and
privacy aspects, such as
o Security requirements capture methodology;
o Management of information and ICT security; in particular information security
management systems (ISMS), security processes, security controls and services;
o Cryptographic and other security mechanisms, including but not limited to
mechanisms for protecting the accountability, availability, integrity and
confidentiality of information;
o Security management support documentation including terminology, guidelines as
well as procedures for the registration of security components;
o Security aspects of identity management, biometrics and privacy;
o Conformance assessment, accreditation and auditing requirements in the area of
information security;
o Security evaluation criteria and methodology.
Technical Document of Page C-4 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
SC 27 engages in active liaison and collaboration with appropriate bodies to ensure
the proper development and application of SC 27 standards and technical reports in
relevant areas.
Relevance to Sensor Networks
o Security is the most important element that wired/wireless sensor network system
needs to adopt.
o Encryption of data
o Network Security suite
o SC 27 projects that potentially relevant to sensor networks
− Digital signatures giving message recovery (ISO/IEC 9796)
− Message authentification codes (MACs) (ISO/IEC 9797)
− Entity Authentication (ISO/IEC 9798)
− Key management (ISO/IEC 11770)
− Trusted computing module (ISO/IEC 11889)
− Digital signatures with appendix (ISO/IEC 14888)
− Intrusion detection system (ISO/IEC 18043)
− Encryption algorithms (ISO/IEC 18033)
− Authenticated encryption (ISO/IEC 19772)
− Security evaluation of biometrics (ISO/IEC 19792)
− Guidelines on Cybersecurity (ISO/IEC 27032)
− Network security (ISO/IEC 27033 Parts 1 to 5)
− Application security (ISO/IEC 27034-1)
− Information security incident management (ISO/IEC 27035)
− Signcryption (ISO/IEC 29150)
− Lightweight Cryptography (ISO/IEC 29192)
C.10 ISO/IEC JTC 1 SC 28 – Office Equipment
Standardizations of office equipment
Scope: Standardizations of basic characteristics, test methods and other related items,
excluding such interfaces as user system interfaces, communication interfaces and
protocols, of office equipment and products such as Printers, Copying Equipments,
Digital scanners, Facsimile equipment and systems composed of combinations of
office equipment.
Relevance to Sensor Networks
Technical Document of Page C-5 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o SC 28 will be one of the biggest sensor network users for control purpose of office
equipments.
C.11 ISO/IEC JTC 1 SC 29 – Coding of Audio, Picture, Multimedia and
Hypermedia Information
Standardizations of coding of audio, picture, multimedia and hypermedia information
Scope: Standardization of coded representation of audio, picture, multimedia and
hypermedia information - and sets of compression and control functions for use with
such information - such as:
o Audio information
o Bi-level and Limited Bits-per-pixel Still Pictures
o Digital Continuous-tone Still Pictures
o Computer Graphic Images
o Moving Pictures and Associated Audio
o Multimedia and Hypermedia Information for Real-time Final Form Interchange
o Audio Visual Interactive Scriptware
Excluded: Standardizations of Character Coding
Relevance to Sensor Networks
o ROSE: Representation of Sensory Effects information.
o MPEG-V: Information exchange with Virtual worlds including real world data
representation and data representation between real world and virtual worlds.
o M3W: Multimedia Middleware.
o MPEG-7 Multimedia Content Description Interface includes various description
schemes and descriptors relating to metadata relevant to sensor networks.
o MPEG-M: MPEG eXtensible Middleware.
o Camera-based sensors and data compressions are part of sensor networks.
C.12 ISO/IEC JTC 1 SC 31 – Automatic Identification and Data Capture
Techniques
Standardizations of automatic identification and data capture techniques
Scope: Standardization of data formats, data syntax, data structures, data encoding,
and technologies for the process of automatic identification and data capture and of
associated devices utilized in inter-industry applications and international business
interchanges.
Excluded are work areas assigned to another international subcommittee or
international technical committee, including:
o ISO TC 104/SC 4/WG 2 in the area of work on Automatic Electronic Identification
for Containers and Container related Applications
Technical Document of Page C-6 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o ISO TC 23/SC 19/WG 3 in the area of work on Identification of Animals
o ISO TC 204 in the area of work on RFID for Transportation and Control Systems
o ISO/IEC JTC 1/SC 17 in the area of work on Cards and Personal Identification
o ISO TC 68/SC 6 in the area of work on Financial Transaction Cards, Related
Media, and Operations
o ISO TC 122/WG 4 in the area of work on Packaging Bar code Label.
Relevance to Sensor Networks
o See SC 31 contribution in SGSN N016.
o SC31 decided to focus on RFID and its extension to Mobile RFID technology.
JTC 1/SC 31 and IEEE 1451 have been actively working on sensor interface descriptions,
including those related to RFID. This work has culminated in IEEE 1451.7, approved by the
committee and attached herein. The unique identification of a sensor node has been
discussed in SC 31 & IEEE1451, and the unique sensor identifier standard has already been
established and published in 2004, as IEEE 1451.4. In Section 6.2 of the 1451 series (1451.7)
also clearly identifies the requirement for a 1451.4 sensor ID as shown in Table C-1.
Table C-1. Sensor ID.
Manufacturer Model Number Version Letter Version Serial Number
ID Number
14 bits 15 bits 5 bits Char 6 bits 24 bits
(17-16381) (0-32,767) (A-Z, data type (0-63) (0-16777215)
Char5)
C.13 ISO/IEC JTC 1 SC 32 – Data Management and Interchange
Standardizations of data management and interchange
Scope: Standards for data management within and among local and distributed
information systems environments. SC32 provides enabling technologies to promote
harmonization data management facilities across sector-specific areas.
o Specifically, SC32 standards include:
o reference models and frameworks for the coordination of existing and emerging
standards;
o definition of data domains, data types and data structures, and their associated
semantics;
o languages, services and protocols for persistent storage, concurrent access,
concurrent update and interchange of data; methods, languages, services and
protocols to structure, organize and register metadata and other information
resources associated with sharing and interoperability, including electronic
commerce.
Relevance to Sensor Networks
o SC32 is beginning working in capturing, storing (and discarding) and mining the
information from the sensors.
o SC32 is a good SDO that sensor network standardization needs to cooperate.
Technical Document of Page C-7 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
C.13.1 ISO/IEC JTC 1 SC 32 WG 1
Standardization in the field of generic information technology standards for open electronic
data interchange needed to attain global interoperability among the information technology
systems used by organizations. Such interoperability is viewed from both business and
information technology perspectives.
C.14 ISO/IEC JTC 1 SC 34 – Document Description and Processing Language
Standardizations of document description and processing languages
Standardization in the field of document structures, languages and related facilities for
the description and processing of compound and hypermedia documents, including:
o languages for describing document logical structures and their support facilities
o languages for describing document-like objects in web environments
o document processing architecture and formatting for logical documents
o languages for describing interactive documents
o multilingual font information interchange and related services
o final-form document architecture and page information interchange
o hypermedia document structuring language and application resources
o API's for document processing
Relevance to Sensor Networks: Not strong
C.15 ISO/IEC JTC 1 SC 35 – User Interfaces
Standardization of user interfaces
Scope: Standardization in the field of User-system interfaces between users (including
people with special needs) and systems encompassing input and output devices in
information technology environments, with a priority of meeting the JTC 1
requirements for cultural and linguistic adaptability
Included are the following related areas:
o Interfaces between users and devices such as keyboard, mice, pointers, pens;
visual displays, and forms of audio and tactile input/output, with the emphasis on
functionality;
o Rules for system control by voice, vision, movement,
o gestures, etc.;
o Presentations of technical mechanisms, icons, graphical symbols, etc. ;
o Dialogue control and navigation in interactions between humans and systems
assistance and tutoring.
Relevance to Sensor Networks
o Some applications require aspects of user interface systems of SC35.
Technical Document of Page C-8 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
C.16 ISO/IEC JTC 1 SC 36 – Information Technology for Learning, Education
and Training
Standardization of information technology for learning, education and training
Scope: Standardization in the field of information technologies for learning, education,
and training to support individuals, groups, or organizations, and to enable
interoperability and reusability of resources and tools.
There are some critical items involving sensor networks in SC36. Foremost is Learning,
Education, and Training (LET) Learner Communication, that is, communication devices
managed by sensor networks. SC36 WG3 is currently nearing the completion of two
Technical Reports (TR) in this domain. Thus, SC 36 WG 3 will need to collaborate with
the sensor network standard developing body in JTC 1. Another related area is LET
Augmented Cognition Application Areas, currently under study in SC36 WG2. Related
sensor network areas include Cognitive Sensors. Another critical aspect is Privacy. SC36
is developing privacy requirements for LET, including privacy requirements in the SC36
contribution to the SGSN on Privacy issues related to SNs.
Other non-critical areas, which in the future may become critical, are: LET Collaboration
Application Areas, LET MLR for describing content to be sent over sensor networks, LET
Accessibility, and LET Quality Processes.
Relevance to Sensor Networks
o There are some critical items involving sensor networks in SC36:
Foremost is Learning, Education, and Training (LET) Learner Communication,
that is, communication devices managed by sensor networks. SC36 WG3 is
currently nearing the completion of two Technical Reports (TR) in this domain.
Thus, SC 36 WG 3 will need to collaborate with the sensor network standard
developing body in JTC 1.
Another related area is LET Augmented Cognition Application Areas, currently
under study in SC36 WG2.
Related sensor network areas include Cognitive Sensors.
Another critical aspect is Privacy. SC36 is developing privacy requirements for
LET, including privacy requirements in the SC36 contribution to the SGSN on
Privacy issues related to SNs.
o Other non-critical areas, which in the future may become critical, are: LET
Collaboration Application Areas, LET MLR for describing content to be sent over
sensor networks, LET Accessibility, and LET Quality Processes.
C.17 ISO/IEC JTC 1 SC 37 – Biometrics
Standardization of Biometrics
Scope: Standardization of generic biometric technologies pertaining to human beings
to support interoperability and data interchange among applications and systems.
Generic human biometric standards include: common file frameworks; biometric
application programming interfaces; biometric data interchange formats; related
biometric profiles; application of evaluation criteria to biometric technologies;
methodologies for performance testing and reporting and cross jurisdictional and
societal aspects.
Excluded is the work in ISO/IEC JTC 1/SC 17 to apply biometric technologies to cards
and personal identification. Excluded is the work in ISO/IEC JTC 1/SC 27 for biometric
Technical Document of Page C-9 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
data protections techniques, biometric security testing, evaluations, and evaluations
methodologies.
The program of work is addressed by six Working Groups:
o WG 1 - Harmonized biometric vocabulary
JTC 1/SC37 WG 1 is developing a harmonized biometric vocabulary (terms and
definitions) to be used throughout JTC 1/SC 37 International Standards. The WG
serves as a source of expertise in this field to JTC 1/SC 37 as well as to other
organizations such as JTC 1/SCs, ISO TCs and external liaison organizations.
o WG 2 - Biometric technical interfaces
JTC 1/SC 37 WG 2 addresses the standardization of all necessary interfaces and
interactions between biometric components and sub-systems, including the
possible use of security mechanisms to protect stored data and data transferred
between systems. These standards include Application Programming Interfaces
(APIs) and data structures that can contain any type of biometric data and can be
used to protect the integrity and the confidentiality of biometric data.
o WG 3 - Biometric data interchange formats
JTC 1/SC 37 WG 3 addresses the standardization of the content, meaning, and
representation of biometric data formats which are specific to a particular biometric
technology or technologies. The ISO/IEC 19794 multi-part standard specifies
biometric data interchange formats for a number of biometric modalities including
finger, face, iris, signature/sign, vascular, voice, and DNA data. Biometric data
interchange format standards enable inter-operability across multiple biometric
vendors within a biometric technology. The first generation of biometric data
interchange standards has been published. Currently, revision projects for the data
formats are being developed. Additionally, a multi-part standard specifying
conformance testing methodologies for all the data format standards and a
multipart biometric sample quality standard are under development.
o WG 4 - Biometric functional architecture and related profiles
JTC 1/SC 37 WG 4 specifies biometric profiles to identify what base standards
apply to an application and what options and ranges of values in those base
standards are necessary and sufficient to ensure biometric interoperability for a
particular set of application functions. Two parts of the ISO/IEC 24713 standard
(biometric profile multi-part standard) have been published and another part is
almost complete. Standards developed by other SC 37/WGs such as WG 2 and
WG 3 provide a repository of base standards that can be used by WG 4 to develop
additional profiles for specific users and applications.
o WG 5 - Biometric testing and reporting
JTC 1/SC 37 WG 5 addresses the standardization of testing and reporting
methodologies and metrics that cover biometric technologies, systems and
components. Three parts of the ISO/IEC 19795 standard (framework, testing
methodologies for technology and scenario evaluation, and interoperability
performance testing) and a technical report on modality-specific testing have been
published. These standards provide uniform, repeatable methods for evaluating
and reporting performance of biometric technologies and systems.
o WG 6 - Cross-jurisdictional and societal aspects of biometrics.
JTC 1/SC 37 WG 6 addresses standardization in the field of jurisdictional and
societal aspects in the application of international biometrics standards. Within this
context, the scope of work includes the support of design and implementation of
Technical Document of Page C-10 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
biometric technologies with respect to accessibility, health and safety, support of
legal requirements and acknowledgement of cross jurisdictional and societal
considerations pertaining to personal information. WG 6 therefore is an important
component of the support that JTC 1/SC 37 can provide to other JTC 1/SCs, ISO
TC and other organizations.
Relevance to Sensor Networks
o Standardization of Biometric data interchange formats, related biometric profiles,
and application of evaluation criteria to biometric technologies have many aspects
in common for sensor networks.
o The following table also summarizes the potential impact on future JTC 1 SC 37
activities in support of biometric sensor network applications. Table C-2 shows the
scope and description of JTC 1 SC 37 working groups.
Table C-2. JTC 1 SC 37 Working group scope and description.
WG # Some potential impact on future JTC 1 SC 37 activities in support of
biometric sensor network applications
WG 1 Requirement for an extended or new vocabulary resulting from the integration
of biometric and sensor network technologies. Possible need to revise
existing vocabulary to address special needs of the new application domain.
WG 2 Need to work with sensor network standards community to ensure that
biometric interface standards and sensor network standards are harmonized.
WG 3 Potential requirements for biometric data format standards for new
modalities. Further work on biometric fusion models and fusion data formats.
Biometric data quality standards and quality of multi-modal fusion data
Casting of biometric data format standards into machine readable abstract
data representations.
WG 4 Potential requirement for biometric profiles matched to requirements of
biometric sensor network applications. Likely to need close cooperation with
WG 6 to reflect increased concerns about privacy and data protection.
WG 5 Performance testing standards for multi-modal and fused modality systems
Performance measurement and characterization of performance in relation to
quality of biometric data samples in both single mode and multi-modal
scenarios.
WG 6 Review and revise existing reports to accommodate special characteristics of
biometric sensor network applications in regard to privacy, data protection
etc. concerns. Work closely with WG 4 on profiles for biometric sensor
network applications as required.
Technical Document of Page C-11 of 11
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Annex D
D Sensor Networks Related Activities outside of JTC 1
This annex attempts to collect Standard Developing Organizations (SDOs) that are relevant to
sensor networks. The contents in this annex
D.1 International Standardization Organization (ISO)
D.1.1 ISO TC 22: Road vehicles
All questions of standardization concerning compatibility, interchangeability and safety, with
particular reference to terminology and test procedures (including the characteristics of
instrumentation) for evaluating the performance of the following types of road vehicles and
their equipment as defined in the relevant items of Article 1 of the convention on Road Traffic,
Vienna in 1968 concluded under the auspices of the United Nations:
mopeds (item m);
motor cycles (item n);
motor vehicles (item p);
trailers (item q);
semi-trailers (item r);
light trailers (item s);
combination vehicles (item t);
articulated vehicles (item u).
D.1.2 ISO TC 184/SC 5: Automation systems and integration
TC 184/SC 5 is named “Architecture, communications and integration framework.” It has
published standards in the areas of manufacturing message specifications, manufacturing
automation programming environments, time-critical communication architectures, open
systems application integration framework, profiles for Modbus TCP, EtherCAT and
ETHERNET Powerlink, and so on. It also published in the area of reference model and
architectures for identifying requirements.
ISO/TR 10314-1:1990: Industrial automation – Shop floor production – Part 1:
Reference model for standardization and a methodology for identification of
requirements
ISO/TR 10314-2:1991: Industrial automation – Shop floor production – Part 2:
Application of the reference model for standardization and methodology
ISO 15745-1:2003: Industrial automation systems and integration – Open systems
application integration framework – Part 1: Generic reference description
D.1.3 ISO TC 204: Intelligent transport systems
Standardization of information, communication and control systems in the field of urban and
rural surface transportation, including intermodal and multimodal aspects thereof, traveller
information, traffic management, public transport, commercial transport, emergency services
and commercial services in the intelligent transport systems (ITS) field.
Technical Document of Page D-1 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Standardization of ITS (Intelligent Transport System)
Standards with 16 WGs
o Architecture of ITS
o ITS Database technology
o Automatic Vehicle Identification/Automatic Equipment Identification
o ETC (Electronic Toll Collection)
o Public Transport and Emergency
o Traveller Information Systems
o DSRC (Dedicated Short Range Communications)
o Wide Area Communications (2G, 3G)
o Nomadic Environment: The most recently established WG
Relevance to Sensor Networks: High
Table D-1 compares TC 204 CALM with other types of channel access methods.
Table D-1. Comparison between TC 204 Communications Access for Land Mobiles
(CALM) and other channel access method.
New
Items CDMA D-TRS HSDPA WiBro DSRC ZigBee
CALM
Comm. Cost High High High High Medium Medium Low
Install. Cost High High High High High High Los
900
Frequency 900 MHz 2.1 GHz 2.3 GHz 5.9 GHz 2.4 GHz 2.4 GHz
MHx
384 250
Data Rate 384 Kbps 7.2 Mbps 14 Mbps 54 Mbps 4 Mbps
Kbps Kbps
Coverage 1.5 Km 6 Km 2 Km 2 Km 100 m 30 m 50 m
Power
High High High High High High Low
Consumption
Mesh
No No No No No No Yes
Capability
Mobility
Yes Yes Yes Yes Yes No Yes
Support
N/W
Limited Limited Limited Limited Limited Limited Yes
Expandability
Addressing m- m-
FH IEEE IEEE HBA NAA
Mode Sequence Sequence
Applications Voice Voice Voice Voice ITS u-Home u-City
Technical Document of Page D-2 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
D.1.4 ISO TC 205: Building environment design
ISO TC 205 establishes the standards in the design of new buildings and retrofit of existing
buildings for acceptable indoor environment and practicable energy conservation and
efficiency. Indoor environment includes air quality, and thermal, acoustic, and visual factors.
other ergonomic factors;
methods of measurement of air pollutants and of thermal, acoustic and lighting
properties;
methods of testing for performance and rating of building environmental equipment
and thermal insulation.
D.1.4.1 TC 205/WG 3: Building control systems design
WG 3 scope covers building control systems design.
D.2 International Electrotechnical Commission (IEC)
D.2.1 IEC TC 17: Switchgear and cotorlgear
SC 17B
o IEC 62026-1 (2007-06) Ed. 2.0 - Low-voltage switchgear and controlgear -
Controller-device interfaces (CDIs) - Part 1: General rules
o IEC 62026-1 (2007-06) Ed. 2.0 - Low-voltage switchgear and controlgear -
Controller-device interfaces (CDIs) - Part 2: Actuator sensor interface (AS-i)
o IEC 62026-3 (2008-01) Ed. 2.0- Low-voltage switchgear and controlgear - Controller-
device interfaces (CDIs) - Part 3: DeviceNet
D.2.2 IEC TC 22: Power electronic systems and equipment
IEC TC 22 scope is to prepare international standards regarding systems, equipment and their
components for electronic power conversion and electronic power switching, including the
means for their control, protection, monitoring and measurement.
Note 1.- Components which are comprised within the scope include electronic devices.
Note 2.- The scope does not include telecommunications apparatus other than power supplies
to such apparatus.
D.2.3 IEC TC 57 – Power Systems management and associated information exchange
IEC TC 57 scope is to prepare international standards for power systems control equipment
and systems including EMS (Energy Management Systems), SCADA (Supervisory Control
And Data Acquisition), distribution automation, teleprotection, and associated information
exchange for real-time and non-real-time information, used in the planning, operation and
maintenance of power systems. Power systems management comprises control within control
centres, substations and individual pieces of primary equipment including telecontrol and
interfaces to equipment, systems and databases, which may be outside the scope of TC 57.
The special conditions in a high voltage environment have to be taken into consideration.
Note 1: Standards prepared by other technical committees of the IEC and organizations such
as ITU and ISO shall be used where applicable.
Note 2: Although the work of TC 57 is chiefly concerned with standards for electric power
systems, these standards may also be useful for application by the relevant bodies to other
geographical widespread processes.
Technical Document of Page D-3 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Note 3: Whereas standards related to measuring and protection relays and to the control and
monitoring equipment used with these systems are treated by TC 95, TC 57 deals with the
interface to the control systems and the transmission aspects for teleprotection systems.
Whereas standards related to equipment for electrical measurement and load control are
treated by TC 13, TC 57 deals with the interface of equipment for interconnection lines and
industrial consumers and producers requiring energy management type interfaces to the
control system.
IEC 60834-1 (1999-10) Ed. 2.0 series on Teleprotection equipment of power systems -
Performance and testing
IEC 60870-5-1 (1990-02) Ed. 1.0 series on Telecontrol equipment and systems. Part 5:
Transmission protocols - Section One: Transmission frame formats
IEC 61334-4-33 (1998-07) Ed. 1.0 series on Distribution automation using distribution
line carrier systems
IEC 61850-4 (2002-01) Ed. 1.0 series on Communication networks and systems in
substations
IEC/TR 62325-102 (2005-02) Ed. 1.0 series on Framework for energy market
communications
IEC/TS 62351-4 (2007-06) Ed. 1.0 series on Power systems management and
associated information exchange
D.2.4 IEC TC 65: Industrial-process measurement, control and automation
IEC TC 65 scope is to prepare international standards for systems and elements used for
industrial-process measurement and control concerning continuous and batch processes, and
also to co-ordinate the standardization of those features of related elements which affect
suitability for integration into such systems.
These standardization works are to be carried out in the international fields for equipment and
systems operating with electrical, pneumatic, hydraulic, mechanical or other systems of
measurement and/or control.
TC 65 has its subcommittees which produces International Standards representing
requirements for industrial automation for sensor networks (TC 65 SC 65C), e.g., IEC 61158
series, IEC 61784 series, and IEC 61804 series. For wireless sensor actuator networks, there
is an approved new work item proposal (NP), several publicly available specifications (PAS),
and a CDV is in preparation. The various aspects of a sensor actuator networks are covered
in TC65, e.g., communication protocol and services, communication profiles, security,
functional safety, installation, integration technologies, system aspects, and application
profiles for sensors.
SC 65A: System aspect
To prepare international standards regarding the generic aspects of systems used in
industrial process measurement, control and manufacturing automation: operational
conditions (including EMC), methodology for the assessment of systems, functional
safety, etc. SC65A also has a safety pilot function to prepare standards dealing with
functional safety of electrical/electronic/programmable electronic systems.
SC 65B: Devices and Process Analysis
To prepare international standards regarding the devices (hardware and software)
used in industrial-process measurement, analysis, control and manufacturing
automation, including analyzing equipment for process measurement. The scope
ranges from simple devices to complex ones and covers such aspects as
interchangeability, performance evaluation, and definition of functionality.
Technical Document of Page D-4 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
SC 65C: Industrial networks
To prepare international standards on wired, optical and wireless industrial networks
for industrial-process measurement, control and manufacturing automation, as well as
for instrumentation systems used for research, development and testing purposes. The
scope includes cabling, interoperability, co-existence and performance evaluation.
o SC65/MT9 maintains a number of the industrial solutions standards, which offers
wired, optical, and wireless approaches.
o Industrial solutions
− CC-Link, EitherCAT, Fieldbus, HART Foundation, MODBUS, ODVA, PNET,
PROFIBUS, Safety Network, SERCOS
− SC65C has new work on addressing new wireless approaches, e.g.,
WirelessHART and WIA
SC 65E: Devices and integration in enterprise systems
To prepare international standards specifying:
(1) Device integration with industrial automation systems. The models developed in
these standards address device properties, classification, selection, configuration,
commissioning, monitoring and basic diagnostics.
(2) Industrial automation systems integration with enterprise systems. This includes
transactions between business and manufacturing activities which may be jointly
developed with ISO TC184.
D.3 ITU-T
Study Group 13: Future networks including mobile and NGN
Study Group 16: Multimedia coding, systems and applications
Study Group 17: Security
o Security must be dealt with after PHY and MAC with CPU processing power is
determined.
JCA-NID: Overall coordination on USN standardization activities within ITU-T Study
Groups including relevant SDOs outside ITU-T.
The work scopes of ITU-T SG13, 16, and 17 seem to exclude standardizations of
protocols of sensor networks.
Figure D-1 and Figure D-2 show the ITU-T’s work in sensor networks and their services at
the conceptual architecture diagrams.
Technical Document of Page D-5 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Figure D-1. ITU-T Sensor network architecture and concept.
Figure D-2. ITU-T Sensor network with networking and standards.
Technical Document of Page D-6 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
D.3.1 ITU-T SG 13 Q.3 [Y.USN-reqts]
Architecture of SN
ITU-T
o Access NW
o BB NW
o Applications
SGSN
o SN MW
o SN Applications
Draft Recommendation Title
o Requirements for support of Ubiquitous Sensor Network (USN) applications and
services in NGN environment
Work scope
o General characteristics of USN;
o Description of USN applications and services to identify service requirements, to
support USN applications and services
o Requirements of extended or new NGN capabilities based on the service
requirements to support USN applications and services
Status
o Approved as a new draft Rec. in Q.2/13 September 2007
o Updated in September 2008
Current document
o Draft Recommendation Y.USN-requirements : NGN-GSI/TD-690 (September 2008)
Future plan
o Consent: Q2/2009
D.3.2 TU-T SG 16 Q.25 (Established 2009)
Question Title: USN Applications and Services
Study Items
o Analysis of service and functional requirements
− Extract service features and required functions from various USN applications
and services
o Architectural service framework
− Define a reference framework for system and network configurations and
interface
Technical Document of Page D-7 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o Application profiling specifications
− Profile USN applications to define service features, processing functions,
operation attributes, attribute values, etc.
o Sensory information description language
− Machine-readable description language
o Middleware-relevant standards
− A set of relevant standards to develop middleware functions
o Sensor node identification scheme
− Unique identifier for sensor nodes
D.3.3 ITU-T SG 16 Q.25 [F.usn-mw]
Draft Recommendation Title
o Service description and requirements for USN middleware
Work scope
o Features of generic USN services
o USN service scenarios which use USN middleware
o Functional model of USN middleware
o Requirements for USN middleware
Status
o Initial proposal to Q.22/16 was made in June 2007.
o New work item was approved in January 2008.
o Initial draft Recommendation was developed in April 2008.
Current document
o Draft Recommendation F.usn-mw : TD-67 (August 2008)
D.3.4 ITU-T SG 17 Q.9 X.usnsec-1
Title
o Security Framework for Ubiquitous Sensor Network
Work scope
o Description of security threats and security requirements to USN
o Classification of security technologies by security functions that satisfy above
security requirements and by the place to which the security technologies are
applied in the model of the Ubiquitous Sensor Network.
o Functional requirements for each entity in the network and possible implementation
layer for security functions.
Technical Document of Page D-8 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Status
o Approved as a new draft Rec. in September 2007
o Updated in September 2008
Current document
o Draft Recommendation X.usnsec-1 : TD-4156(WP2/17) (September 2008)
D.4 IEEE 802.15
IEEE 802.15.4
o PHY and MAC specifications of Low Rate WPAN with both beacon mode and non-
beacon mode.
o Data Rate: 20 Kbps @ 800 MHz band with 1 channel, 40 Kbps @ 900 MHz band
with 10 channels, 250 Kbps @ 2.4 GHz band with 16 channels
IEEE 802.15.4a
o Low Rate UWB (Ultra WideBand) with Ranging and Positioning Capability as an
alternative PHY
IEEE 802.15.4b
o Sub GHz PHY Enhancement of IEEE 802.15.4 with Beacons transmitted in a
scheduling manner
IEEE 802.15.4c
o Chinese WPAN at 779 - 787 MHz band
IEEE 802.15.4d
o Japanese WPAN at 900 MHz band (not accurate yet.)
IEEE 802.15.4e
o Purpose
This functionality will facilitate Industrial applications (such as addressed by HART
7 and the ISA100 proposed standards), and those enhancements defined by the
proposed Chinese WPAN standard that aren't included in TG4c This amendment
will address coexistence with wireless protocols such as 802.11, 802.15.1,
802.15.3, and 802.15.4.
o Scope
The intention of this amendment is to enhance and add functionality to the
802.15.4-2006 MAC to a) better support the industrial markets and b) permit
compatibility with modifications being proposed within the Chinese WPAN.
Specifically, the MAC enhancements to be considered will be limited to the
following:
− TDMA: to provide a)determinism, b)enhanced utilization of bandwidth
− Channel Hopping: to provide additional robustness in high interfering
environments and enhance coexistence with other wireless networks
Technical Document of Page D-9 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
− GTS: to increase its flexibility such as a) supporting peer to peer, b)the length
of the slot, and c) number of slots
− CSMA: to improve throughput and reduce energy consumption
− Security: to add support for additional options such as asymmetrical keys
− Low latency: to reduce end to end delivery time such as needed for control
applications
IEEE 802.15.4g
o Purpose
To provide a global standard that facilitates very large scale process control
applications such as the utility smart-grid network. This amendment supports large,
geographically diverse networks with minimal infrastructure. Smart Metering Utility
Networks can potentially contain millions of fixed endpoints. The communication
range, robustness, and coexistence characteristics required for this class of
application have not been met with existing 802 standards (See explanatory notes
in Section 8.1 Doc#15-08-705).
o Scope
This Standard defines an amendment to IEEE 802.15.4. It addresses principally
outdoor Low Data Rate Wireless Smart Metering Utility Network requirements. It
defines an alternate PHY and only those MAC modifications needed to support its
implementation.
Specifically, the amendment supports all of the following:
− Operation in any of the regionally available license exempt frequency bands,
such as 700MHz to 1GHz, and the 2.4 GHz band.
− Data rate of at least 40 kbits per second but not more than 1000 kbits per
second
− Achieve the optimal energy efficient link margin given the environmental
conditions encountered in Smart Metering deployments.
− Principally outdoor communications
− PHY frame sizes up to a minimum of 1500 octets
− Simultaneous operation for at least 3 co-located orthogonal networks
− Connectivity to at least one thousand direct neighbors characteristic of dense
urban deployment
− Provides mechanisms that enable coexistence with other systems in the same
band(s) including IEEE 802.11, 802.15 and 802.16 systems
IEEE 802.15.5
o Recommended Practice of Low Rate and High Rate WPAN Mesh Network
o Mandatory tree routing with addressing based on ABA
o Supports unicast, multicast, and reliable broadcast.
Technical Document of Page D-10 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
IEEE 802.15.6
o PHY Specifications on Medical BAN.
o PAR approved and CFA solicited.
D.4.1 IEEE 805.15.5
Low rate WPAN mesh network running on the top of IEEE 802.15.4
o Upper MAC recommended practice of Low Rate WPAN
o No significant power saving mechanisms with non-beacon mode operation.
Adaptive Block Addressing
o Tree routing maintained.
o Long initialization time and long reset time
o Limited device mobility supported.
High rate WPAN mesh is also being standardized.
D.4.2 IEEE 805.15.6
PHY specifications for Medical Body Area Network
o PAR has been approved in 2007.
WPAN standard optimized for low power devices and operation on, in or around the hu
man body (but not limited to humans) to serve a variety of applications including medic
al, consumer electronics / personal entertainment and other.
Specifications on new MAC are not excluded.
Current Status
o Updating Call for Intent
o Updating Channel Model
o Updating Regulatory Matrix
D.5 IEEE 1451
IEEE Draft 1451.0, Draft Standard for a Smart Transducer Interface for Sensors and
Actuators – Functions, Communications Protocols and Transducer Electronic Data
Sheet (TEDS) Formats
IEEE Std 1451.1-1999, Standard for a Smart Transducer Interface for Sensors and
Actuators – Network Capable Application Processor (NCAP) Information Model
IEEE Std 1451.2-1997, Standard for a Smart Transducer Interface for Sensors and
Actuators – Transducer to Microprocessor Communication Protocols and Transducer
Electronic Data Sheet (TEDS) Formats
IEEE Std 1451.3-2003, IEEE Standard for a Smart Transducer Interface for Sensors
and Actuators – Digital Communication and Transducer Electronic Data Sheet (TEDS)
Formats for Distributed Multidrop Systems
Technical Document of Page D-11 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
IEEE Std 1451.4-2004, IEEE Standard for A Smart Transducer Interface for Sensors
and Actuators – Mixed-Mode Communication Protocols and Transducer Electronic
Data Sheet (TEDS) Formats
IEEE Draft 1451.5, Draft Standard for a Smart Transducer Interface for Sensors and
Actuators – Wireless Communication Protocols and Transducer Electronic Data Sheet
(TEDS) Formats
IEEE Draft 1451.6, [Cancelled] Draft Standard for A Smart Transducer Interface for
Sensors and Actuators – A High-speed CANopen-based Transducer Network Interface
for Intrinsically Safe and Non-intrinsically Safe Applications
IEEE 1451.7, Draft IEEE Standard: Sensors for RFID
D.5.1 IEEE 1451.0 – Standard for a Smart Transducer interface for Sensors and
Actuators - Common Functions, Communication Protocols, and Transducer
Electronic Data Sheet (TEDS) Formats
Scope: This project develops a set of common functionality for the family of IEEE
P1451 smart transducer interface standards. This functionality is independent of the
physical communications media. It includes the basic functions required to control and
manage smart transducers, common communications protocols, and media-
independent Transducer Electronic Data Sheet (TEDS) formats. It defines a set of
implementation-independent application programming interfaces (API). This project
does not specify signal conditioning and conversion, physical media, or how the TEDS
data are used in applications.
Purpose: There are several standards in the IEEE 1451 family that all share certain
characteristics, but there exists no common set of functions, communications protocols,
and TEDS formats that facilitate interoperability among these standards. This standard
provides that commonality and simplifies the creation of future standards for different
physical layers that are interoperable in the family.
Technical Brief
o Overview
This standard introduces the concept of a transducer interface module (TIM) and a
network capable application processor (NCAP) connected by a media specified by
another member of the IEEE 1451 family of standards. A TIM is a module that
contains the interface, signal conditioning, analogue-to-digital and/or digital-to-
analogue conversion and the transducer. A TIM may range in complexity from a
single sensor or actuator to units containing many transducers (sensors and
actuators). An NCAP is the hardware and software that provides the gateway
function between the TIMs and the user network or host processor. Another
member of the standards family provides the communications interface between an
NCAP or host processor and one or more TIMs. Three types of transducers are
recognized by this standard. They are sensors, event sensors, and actuators.
o User’s network
The user’s network is outside the scope of the IEEE 1451 family of standards. It
may be anything that the user desires. The only requirement that this places on the
NCAP is that the NCAP have the appropriate network interface hardware and
software. Different NCAPs are required for networks using different physical
communications media or protocols.
o NCAP IEEE 1451.0 services
The block defines the functions and services provided to the NCAP
communications module and to the NCAP applications. The functions provided by
Technical Document of Page D-12 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
this module are defined in this standard. These functions include the command set
and the TEDS. Features are included in the standard to support capabilities such
as triggering and synchronous sampling of sensors, but the detailed
implementation is left up to the other standards in the family.
o Physical interface (PHY)
The physical interface between the NCAP and the TIM is left up to the other
members of the standards family to define. It is not described in this standard.
Functions needed across this interface such as synchronization, if applicable, are
described but not their implementation.
o TEDS
The basic TEDS are defined in this standard along with the access methods for
them. However, some information that relates to the physical interface is defined in
other standards in the IEEE 1451 family.
o Plug-and-play capability
A TIM(s) and NCAP that are built to this standard shall be able to be connected
using a compatible physical communications media and shall be able to operate
without any changes to the system software. There shall be no need for different
drivers, profiles, or other system software changes to provide basic operation of
the transducer. Applications that use, produce, or display the data associated with
a transducer are not included in this statement. Features that go beyond the
requirements of this standard are allowed, but they impact the plug-and-play
capability of the TIM or NCAP.
o Commands
Commands are divided into two categories, standard and manufacturer-defined.
Regardless of the category, the command is divided into 2 octets. The most
significant octet shall be used to define the class of the command. The least
significant octet, called the function, shall identify the specific command within the
class.
o Transducer services API
The Transducer services API provides the interface between the applications
running on the NCAP and the functions defined by this standard.
o Module Communications API
The Module Communications API provides the interface between the functions
defined by the IEEE 1451.0 layer and the communications functions defined by
another member of the IEEE 1451 family of standards.
o HTTP protocol
The HTTP is a protocol used to transfer or convey information on the World Wide
Web. HTTP is a client–server protocol by which two processors can communicate
over a TCP/IP connection. An HTTP server is a program that resides in a
processor listening to a port for HTTP requests. An HTTP client opens a TCP/IP
connection to the server via a socket, transmits a request, and then waits for a
reply from the server. For this IEEE standard, the “client–server” model, which is
used to define HTTP, is analogous to the IEEE 1451.0 “NCAP-End User.” The
NCAP can be compared with the “server” as it serves data to the attached network,
and the End-User can be compared with the “client” as the end-user receives
sensor data to view from the server and sends commands and data to the server to
drive actuators.
Technical Document of Page D-13 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o Annex Content
− Annex A (informative) Bibliography
− Annex B (informative) Guidance to Transducer Services Interface
− Annex C (informative) Guidance to Module Communication Interface
− Annex D (informative) XML Schema for Text-based TEDS
− Annex E (informative) Example Meta-Identification TEDS
− Annex F (informative) Example Transducer Channel Identification TEDS
− Annex G (informative) Example Calibration Identification TEDS
− Annex H (informative) Example Commands TEDS
− Annex I (informative) Example Location and Title TEDS
− Annex J (informative) Example Units Extension TEDS
− Annex K (informative) Examples of Physical Units
− Annex L (informative) TEDS read and write protocols
− Annex M (informative) Trigger logic configurations
− Annex N (informative) Notation summary for IDL
− Annex O (informative) TEDS implementation of a simple sensor
D.5.2 EEE 1451.1 – Standard for A Smart Transducer Interface for Sensors and
Actuators – Network Capable Application Processor (NCAP) Information Model
Scope: This standard defines an interface for connecting network-capable processors
to control networks through the development of a common control network information
object model for smart sensors and actuators.
Purpose: Many control network implementations are currently available that allow
transducers to be accessed over a network. The purpose of this standard is to provide
a network-neutral application model that will reduce the effort in interfacing smart
sensors and actuators to a network.
Benefits
A system designed and built in conformance to this standard is expected to provide
the following benefits:
A uniform design model for system implementation
A uniform and network-independent set of operations for system configuration
Defined network-independent models for communication
Interoperability of all communications
Defined network-independent models for implementing application functionality
Portable application models
Technical Brief
o Information model
The IEEE 1451.1 standard specifies a software architecture. This architecture is
applicable to distributed systems consisting of one or more Network Capable
Technical Document of Page D-14 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Application Processors (NCAPs), communicating over a network. The NCAPs may
interact with the physical world via attached transducers.
The standard provides:
− A network abstraction layer
− A transducer abstraction layer
The standard specifies:
− The software interfaces between application functions on an NCAP and a
communication network in a manner independent of any specific network.
− The software interfaces between application functions on an NCAP and
transducers attached to that NCAP in a manner independent of any specific
transducer driver interface.
Systems implemented according to IEEE 1451.1 standard will achieve a high
degree of interoperability regardless of the underlying network or transducer
technologies.
The IEEE 1451.1 software architecture is defined via three types of models:
− An object model (for the software components of IEEE 1451.1 systems)
− A data model (for the information communicated across the specified object
interfaces)
− Two network communications models
o Network communication models
The IEEE 1451.1 standard provides two models of network communication
between objects in an IEEE 1451.1 system.
− A tightly coupled, point-to-point client-server model for one-to-one
communications
− A loosely coupled, publish-subscribe model, for one-to-many and many-to-
many communications
The communication models define the syntax and the semantics of the software
interfaces between application objects and a communications network. The IEEE
1451.1 standard does this by specifying Client, Publisher, and Subscriber Port
Objects and the Perform operation on Server Objects. These interfaces are
independent of the specific network being used.
The IEEE 1451.1 standard does not specify any network transfer syntax or
protocol. For each specific network, it is expected that network software suppliers
will provide code libraries that contain routines for the calls between the IEEE
1451.1 communication operations and the network. These libraries will include
marshaling and demarshaling routines for transforming IEEE 1451.1 datums to and
from their on-the-wire format. In this standard, the services provided by such a
library are collectively referred to as the network infrastructure.
o Annex Content
− Annex A (informative) Using the object model
− Annex B (informative) Client-server example
Technical Document of Page D-15 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
− Annex C (informative) Publish-subscribe example
− Annex D (informative) System configuration and operation examples
− Annex E (informative) NCAP interoperation and network-independent code
− Annex F (normative) IEEE 1451.1 String character set
− Annex G (normative) Assignment of enumeration values to ISO 639 language
codes
− Annex H (normative) IEEE1451.2 Transducer Block definition
− Annex I (informative) Bibliography
D.5.3 IEEE 1451.2 – Standard for a Smart Transducer Interface for Sensors and
Actuators - Transducer to Microprocessor Communications Protocols and
Transducer Electronic Data Sheet (TEDS) Formats
Scope: This standard defines a digital interface for connecting transducers to
microprocessors. It describes a TEDS and its data formats. It defines an electrical
interface, read and write logic functions to access the TEDS, and a wide variety of
transducers. This standard does not specify signal conditioning, signal conversion, or
how the TEDS data is used in applications.
Purpose: There is currently no defined independent digital communication interface
standard between transducers and microprocessors. Each vendor builds its own
interface. Without an independent, openly defined interface, transducer interfacing and
integration are time-consuming and duplicated efforts by vendors are economically
unproductive. This interface provides a minimum implementation subset that allows
self-identification and configuration of sensors and actuators, and also allows
extensibility by vendors to provide growth and product differentiation.
Technical Brief
The main objectives of this standard are to:
o Enable plug and play at the transducer (sensor or actuator) level by providing a
common communication interface for transducers.
o Enable and simplify the creation of networked smart transducers.
o Facilitate the support of multiple networks.
The existing fragmented sensor market is seeking ways to build low-cost, networked
smart sensors. Many sensor network or fieldbus implementations are currently
available, each with its own strengths and weaknesses for a specific application class.
Interfacing transducers to all these control networks and supporting the wide variety of
protocols represents a significant and costly effort to transducer manufacturers. A
universally-accepted transducer interface standard would not only allow for the
development of smart sensors and actuators, it could also lead to lower development
costs. Therefore, the objective of this project is not to propose another control network,
but to develop a smart transducer interface standard that will isolate the choice of
transducers from the choice of networks. This would relieve the burden from the
manufacturer of supporting a cross product of sensors versus networks, and would
help to preserve the user’s investment if it becomes necessary to migrate to a different
network standard. There is currently no defined common digital communication
interface standard between transducers and network capable application processors
(NCAPs). Each transducer manufacturer builds its own interface. Consequently,
transducer manufacturers cannot afford to support all of the control networks for which
their products may be suited. It was concluded at a series of five transducer interface
Technical Document of Page D-16 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
workshops that a common transducer communication interface standard be proposed.
This common interface would allow the transducer manufacturers to more easily
support multiple control networks. This standard will simplify the development of
networked transducers by defining hardware and software blocks that do not depend
on specific control networks. This project has developed a standard hardware interface
to connect a smart transducer interface module (STIM) to an NCAP. While the project
does not include specifications for signal conditioning or data conversion, it does
provide a mechanism for specifying the combination of transducer, signal conditioning,
and signal conversion to the rest of the system. This mechanism is the transducer
electronic data sheet (TEDS). The working group has defined a TEDS which supports
a wide variety of transducers as well as a digital interface to access the TEDS, read
sensors, and set actuators. This allows transducer manufacturers competitive
differentiation in areas of quality, feature set and cost, and at the same time affords
the opportunity to design to a common interface which can be used in a wide variety of
applications. The TEDS, which provides for self-identifying transducers, is at the core
of this effort. The TEDS contains fields that fully describe the type, operation, and
attributes of one or more transducers. By requiring that the TEDS be physically
associated with the transducer, the resulting hardware partition encapsulates the
measurement aspects in a STIM on one side of the digital interface, and the
application related aspects on the NCAP on the other side. In addition to control
networks, STIMs can be used with microprocessors in a variety of applications such as
portable instruments and data acquisition cards.
o Physical Interface support
The updated standard supports these physical serial interfaces: UART, RS232,
SPI, USB, and I2C, and TII (transducer independent interface)
o Annex Content
Annex A (informative) Bibliography
D.5.4 IEEE 1451.3 – Standard for a Smart Transducer Interface for Sensors and
Actuators—Digital Communication and Transducer Electronic Data Sheet
(TEDS) Formats for Distributed Multidrop Systems.
Scope: This standard defines a digital interface for connecting multiple physically
separated transducers. It leverages off the IEEE Standard 1451.1-1999 and IEEE Std
1451.2-1997 standards. This standard defines the TEDS format, the electrical
interface, channel identification protocols, hot swap protocols, time synchronization
protocols, and read/write logic functions used to access the TEDS and transducer data.
This standard does not specify signal conditioning, signal conversion, or how an
application uses the TEDS data.
Purpose: There is currently no defined independent standard for interfacing multiple
physically separated transducers that allows time synchronization of data. Without
such a standard, custom transducer interface solutions are required which are time-
consuming and costly. This standard provides a minimum implementation that allows
multi-drop, hot swapping, self-identification and configuration of transducers that may
not be located in the same enclosure, but are confined to a relatively small space.
Technical Description
IEEE 1451.3 utilizes the techniques designed to implement networking in the home by
interconnection devices on the telephone lines. For IEEE Std 1451.3-2003, a single
pair of conductors will be used to provide the following functions:
o synchronized data acquisition for an array of transducers
o communicating with an array of Transducer Bus Interface Modules (TBIM)
Technical Document of Page D-17 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o providing power for operation of transducers on the bus and their associated
electronics
Transducers built per this standard can be plugged into an IEEE Standard 1451.3-
2003 compatible system and be used without having to add special drivers, profiles or
make any other changes to the system. The IEEE Standard 1451.3-2003 TEDS
provides for self-identifying transducers. The TEDS contains fields that fully describe
the type, operation, and attributes of one or more transducers (sensors or actuators).
By having the TEDS associated with the transducer and module containing the
transducer, the resulting hardware partition encapsulates the measurement aspects to
a module. The application related aspects of the measurement are on the bus
controller or NCAP and do not become a concern for the transducer manufacturer.
Annex Content
o Annex A (informative) Bibliography
o Annex B (normative) XML schema for text-based TEDS
o Annex C (informative) Example Meta-Identification TEDS
o Annex D (informative) Example Transducer Channel Identification TEDS
o Annex E (informative) Example Calibration Identification TEDS
o Annex F (informative) Example Commands TEDS
o Annex G (informative) Example Location and Title TEDS
o Annex H (informative) Example physical units
o Annex I (informative) TEDS Read and Write protocols
o Annex J (informative) Trigger logic configurations
D.5.5 IEEE 1451.4 – Standard for a Smart Transducer Interface for Sensors and
Actuators—Mixed-Mode Communication Protocols and Transducer Electronic
Data Sheet (TEDS) Formats
Scope: This standard defines the protocol and interface that allows analog
transducers to communicate digital information with an IEEE 1451 object. It also
defines the format of the Transducer TEDS. The Transducer TEDS is based on the
IEEE 1451.2 TEDS. The standard does not specify the transducer design, signal
conditioning, or the specific use of the TEDS.
Purpose: An independent and openly defined standard for MMI and TEDS serves the
following purposes:
o Provide interoperability, which enables plug-and-play capability
o Simplify the implementation of mixed-mode smart transducer systems
o Accelerate the emergence and acceptance of the MMI and TEDS
IEEE 1451.4 Transducer
IEEE Standard 1451.4-2004 defines TEDS and MMI. The measurement/control device
can be or contain an NCAP conforming with IEEE Standard 1451.1-1999 and giving
direct network access to the transducers. An IEEE 1451.4 Transducer may be used to
sense or control multiple physical phenomena. Each phenomenon sensed or controlled
shall be associated with a node. If more than one node is included in an IEEE 1451.4
Transducer, one of the nodes shall have a memory block that holds the Node-List. The
Technical Document of Page D-18 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Node-List contains the IDs of the other nodes within the IEEE 1451.4 Transducer. An
IEEE 1451.4 Transducer has no more than one Node-List. If there is only one node
inside an IEEE 1451.4 Transducer, there is no Node-List. Each IEEE 1451.4
Transducer is connected to an IEEE 1451.4 MMI. Each IEEE 1451.4 MMI can have
several IEEE 1451.4 Transducers attached provided they are each capable of being in
a passive mode. Node-Lists are used to specify which nodes correspond to which
IEEE 1451.4 Transducer(s). This is needed if two or more nodes (in one or more IEEE
1451.4 Transducers) are connected to the same IEEE 1451.4 MMI.
Templates
This describes the usage of the template structure to read or write nodes and extract
TEDS data. A measurement/control device will be attached to a bus that will have one
or more IEEE1451.4 Transducers attached to the bus. Each attached IEEE1451.4
Transducer will contain one or more nodes. Each node of an attached IEEE1451.4
Transducer may be accessed by the measurement/control device via the Mixed-mode
Interface (MMI) of the IEEE1451.4 Transducer through that node’s Data Interface.
A template describes the memory structure of TEDS data that contains information
about the identity of the transducer and transducer specific data. It shall be written in
the TDL and templates shall reside in the Tblock. Templates shall be made available
to the T-block as one or more 8-bit ASCII text template description files with the
extension .tdl. The IEEE1451.4 T-block provides an interface between transducers and
application software in an IEEE 1451-compliant device. It includes methods for
extracting and encoding IEEE1451.4 TEDS data using the templates. The T-block also
permits the IEEE1451.4 Transducers and Interfaces to be configured and managed.
The template structure is designed with the main objective to use small-sized memory
in an efficient manner. Therefore, the template used defines the memory structure.
This means that a specific part of the memory may contain different types of
information depending on the specific template used in a particular transducer.
Template Description Language (TDL)
This describes the syntax and semantics of the language used in the templates. Using
this language, each template defines the bitmapping of its associated TEDS.
Mixed Mode Transducer Interface (MMI) specification
The IEEE 1451.4 MMI ensures the robust transfer of a transducer signal and digital
TEDS data between a transducer and an NCAP or data acquisition system.
Annex Content
o Annex A (normative) IEEE standard templates
o Annex B (normative) Property definitions
o Annex C (informative) TDL formal grammar
o Annex D (informative) Template file checksum example
o Annex E (informative) Family Codes
o Annex F (informative) IEEE 1451.4 XML device description schema
o Annex G (informative) Communication with nodes in sensors on remote locations
o Annex H (normative) Procedures for adding new IEEE templates and TDL items
and to get URNs
o Annex I (informative) IEEE P1451.4, version 0.9, and beta information
Technical Document of Page D-19 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o Annex J (normative) IEEE 1451.4 Manufacturer IDs and model numbers
o Annex K (normative) IEEE 1451.4 TBOM schema
o Annex L (normative) IEEE 1451.4 Transducer Block IEEE 1451.1 adapter definition
o Annex M (informative) Bibliography
D.5.6 IEEE 1451.5 – Standard for a Smart Transducer Interface for Sensors and
Actuators—Wireless Communication Protocols and Transducer Electronic Data
Sheet (TEDS) Formats
Scope: This project establishes a standard for wireless communication methods and
data format for transducers (sensors and actuators). The standard defines a TEDS
based on the IEEE 1451 concept and protocols to access TEDS and transducer data.
It adopts necessary wireless interfaces and protocols to facilitate the use of technically
differentiated, existing wireless technology solutions. It does not specify transducer
design, signal conditioning, wireless system physical design or use, or use of TEDS.
Purpose: Many companies are developing various wireless communication interfaces
and protocols for sensors. An openly defined wireless transducer communication
standard, which may accommodate various existing wireless technologies, will reduce
risk for users, transducer manufacturers, and system integrators. It will enhance the
acceptance of the wireless technology for transducers connectivity.
Technical Description
This standard introduces the concept of a Wireless Transducer Interface Module
(WTIM), connected wirelessly over an approved radio Communication Module to a
Network-Capable Application Processor (NCAP) Service Module. The IEEE 1451.5
approved radios (Dot5AR) are IEEE 802.11™, IEEE 802.15.4™, IEEE Bluetooth™,
and IEEE ZigBee™ technologies. A WTIM is a module that contains a
Dot5ApprovedRadio, signal conditioning, analogue-to-digital, and/or digital-to-
analogue conversion and in many cases the transducers (sensors and actuators). A
WTIM may range in complexity from a single sensor or actuator plus radio to units
containing many transducers plus radio. Although the WTIM contains a Dot5AR for
wireless communication, the NCAP in-turn contains a similar radio to complete the
wireless communication link between NCAP and WTIM. This specification for this
standard focuses on the communication modules that connect the WTIM and NCAP
using the Dot5AR protocols.
o Common IEEE 1451.5 Wireless Interface Definitions
This describes NCAP IEEE 1451.0 Services interface with the NCAP IEEE 1451.5
Communication Module through the IEEE 1451.0/5 Communications API. It
discusses the quality of service in this section.
o IEEE 802.11 radio sub-specification
This IEEE 802.11 radio specification for the IEEE 1451.5 system provides a
description of the functions, protocols, and interfaces that are to be performed and
provided by the IEEE 802.11 Communication Module between the Transducer
Access Module, or WTIM, and the NCAP Service Module. The IEEE 802.11 radio
specification for IEEE 1451.5 maps commands and messages from the IEEE
1451.5 higher convergence layer, bi-directionally through the IEEE 802.11 MAC
and PHY for radio-based communication between the WTIM and the NCAP Service
Module.
Technical Document of Page D-20 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o Bluetooth radio sub-specification
The IEEE 1451.5 implementation is responsible for control signaling and data flow
between the NCAP and the WTIM roles. BNEP is the Bluetooth Network
Encapsulation Protocol and is used to provide networking capabilities for Bluetooth
devices over L2CAP. The SLIP (Serial Link Internet Protocol) Layer translates
between a byte stream and a packet stream. RFCOMM provides emulation of
serial ports over L2CAP as a byte stream. SDP is the Bluetooth Service Discovery
Protocol used to discover peer device capabilities. The Link Controller, Link
Manager, and L2CAP are the OSI layer 1 and 2 Bluetooth protocols.
BNEP and RFCOMM are used as two alternative transport layers. For these
protocols, all requirements stated in their specifications apply except in those
cases where this document explicitly states deviations. It is intended that
extensions to BNEP, or other protocols running on top of BNEP, can be used to
implement network routing, including mesh networking, in IEEE 1451.5 Bluetooth
implementations. RFCOMM is included as a legacy protocol for point-to-point
solutions that is widely supported in commercial products.
o ZigBee radio sub-specification
The IEEE 1451.5 ZigBee network sub-specification specifically addresses the
requirements necessary to enable use of ZigBee networks to provide a transport
layer for implementing the IEEE 1451.5 system. The specification defines ZigBee
application profiles, security issues, and quality of service functionality, and it
defines a convergence layer for interface between the ZigBee network and IEEE
1451.0 functionality.
o 6LoWPAN Radio sub-specification
This 6LoWPAN radio specification for the IEEE 1451.5 system provides a
description of the functions, protocols, and interfaces required or provided by the
6LoWPAN Communication Module interconnecting WTIM and NCAP. This
specification defines the mapping between the IEEE 1451.5 convergence layer and
the 6LoWPAN mesh network protocol. The 6LoWPAN radio specification for the
IEEE 1451.5 system shall support the use of the IEEE 802.15.4 PHY. The main
goal of this specification is to provide a complete mapping from the IEEE 1451.5
convergence layer through the 6LoWPAN network stack down to the IEEE
802.15.4 MAC and PHY and the reverse path.
o Annex Content
− Annex A (informative) IPv4 reference
− Annex B (informative) IPv6 reference
− Annex C (informative) TCP reference
− Annex D (informative) UDP reference
− Annex E (informative) TEDS read and write protocols
− Annex F (informative) Bibliography
D.5.7 IEEE 1451.6
IEEE 1451.6 has been cancelled.
Technical Document of Page D-21 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
D.5.8 IEEE 1451.7
Scope: This standard defines communication methods and data formats for
transducers (sensors and actuators) communicating with RFID tags that follow the
ISO/IEC 24753 standard. The standard also defines Transducer Electronic Data Sheet
(TEDS) formats based on the IEEE 1451 family of standards and protocols for
accessing TEDS and transducer data. It adopts necessary interfaces and protocols to
facilitate the use of technically differentiated, existing technology solutions. It doesn’t
specify transducer design or signal conditioning.
Purpose: There is currently no openly defined independent interface standard
between transducers and RFID tags. Each vendor builds its own interface. Without
such standard, transducer interfacing and integration to RFID tags and systems are
time-consuming and all vendors’ duplicated efforts are economically unproductive. The
purpose of this standard is to provide interfaces and methods for interfacing
transducers to RFID tags and reporting transducer data within the RFID infrastructure.
It also provides means for device and equipment interoperability
Technical Brief
o Specifications
− Transducer and RFID System Interface Specification
• This standard specifies a set of features, which allow a smart transducer to
communicate with the outside world using the techniques employed by
RFID systems. The list below shows the four design elements that must be
embodied in all smart transducers, which conform to this standard.
− Essential elements of a conformant smart transducer
• Communications Protocol
• Command Structure
• TEDS
• Transducer Data
o Air Interface
− Air Interface Applicability (RFID and RTLS): The IEEE 1451.7 command
structure supports the air interface communications protocols described in
these ISO/IEC standards: Additional air interface protocols may be added by
declaring compliance with this standard.
• ISO/IEC 18000-2, Information technology — Radio frequency identification
for item management — Part 2: Parameters for air interface
communications below 135 kHz
• ISO/IEC 18000-3, Information technology — Radio frequency identification
for item management — Part 3: Parameters for air interface
communications at 13.56 MHz
• ISO/IEC 18000-4, Information technology — Radio frequency identification
for item management — Part 4: Parameters for air interface
communications at 2.45 GHz
• ISO/IEC 18000-6, Information technology — Radio frequency identification
for item management — Part 6: Parameters for air interface
communications at 860 MHz to 960 MHz
Technical Document of Page D-22 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
• ISO/IEC 18000-7, Information technology — Radio frequency identification
for item management Part 7: Parameters for active air interface
communications at 433 MHz
• ISO/IEC 24730-2, Information technology - Real-time locating systems
(RTLS) - Part 2: 2.4 GHz air interface protocol
• ISO/IEC 24730-5 Information technology automatic identification and data
capture techniques – Real Time Locating Systems (RTLS) – Part 5: Chirp
Spread Spectrum (CSS) at 2.4 GHz
− 1451.7 was designed to be completely air-interface agnostic
o Sensor Data Structure
− Sensor data structure - 2 levels
• The sensor type (e.g., temperature or relative humidity) determined by its
physical design.
• The data type defined by the measured or derived data extracted from the
sensor (e.g., present sampled value, or a count of occurrences of out-of-
limit samples, or a detailed data log).
− The data available for extraction from each sensor shall consist of:
• The Sensor Identifier
• The Sensor Characteristics Record
• The Sampling and Configuration Record
• The Event Administration Record
• The Event Record
o Command Overview
− The commands support one of four means of addressing a sensor:
• Using a port number determined by the RFID tag
• Using a port number declared by the sensor
• Using the 64-bit unique sensor identifier
• Using the first three Fields of the sensor characteristics TEDS, uniquely
identifying the type of sensor.
− A sensor shall support at least one of the addressing mechanisms and may
support others as defined.
• The choice can be affected by the choice of RFID air interface protocol and
tag architecture with which the sensor integrates. The addressing
mechanisms shall be declared on the sensor manufacturer's data sheet
o RFID Communications
− Support for Commands
• The commands and responses that are specified in 1451.7 are designed to
be encapsulated in an air interface command and response assigned to
Technical Document of Page D-23 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
support IEEE 1451.7. Such air interface transport commands and
responses shall be specified within the air interface protocol standard.
Once the RFID tag receives the transport command, the encapsulated
1451.7 command is passed to the sensor component for processing. The
sensor response when received by the RFID component is encapsulated in
the air interface transport response.
− Addressing Sensors
• supports a number of ways to address sensors, three of which use
mechanisms known only to the sensor, so the appropriate product
specification shall define if any of these and which are supported by the
sensor
o Technical Brief – Annex Content
• Annex A - Sensor Types: A list of sensor types supported by 1451.7
• Annex B - Extension Codes: Chemical substances currently supported by
1451.7
• Annex C - Physical Connections: A listing of physical connections supported by
1451.7
D.6 IEEE 1588: Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems
A protocol designed to synchronize real-time clocks in the nodes of a distributed system that
communicate using a network
IEEE 1588 is network neutral although it is recognized that Ethernet will be a dominant
network. IEEE 1588 does assume that the network supports multicast communications and is
a packet or equivalent based system.
D.7 ISA100 / ISA100.11: Wireless system for automation / Wireless
communication standard(s) optimized for industrial loop control.
Introduction
ISA100 Committee focuses on establishing standards and related information that will
define procedures for implementing wireless systems in the automation and control
environment on the field level. ISA 100.11a is one of the subcommittees in ISA100.
ISA100.11a utilizes radios compliant to IEEE 802.15.4-2006 operating in the 2.4GHz
band, with channel hopping across 16 direct sequence spread spectrum (DSSS)
channels. All the other layers like MAC layer, Network layer, Data link layer,
transportation layer, application layer are new designed.
ISA100.11a is the first of a family of standards to be defined by the ISA100 wireless
working group. ISA100.11a is intended to provide reliable and secure operation for
non-critical monitoring, alerting, supervisory control, open loop control, and closed
loop control applications. ISA100.11a defines the OSI stack, system management,
gateway, and security specifications for low data rate wireless connectivity with fixed,
portable, and moving devices supporting very limited power consumption requirements.
ISA100.11a’s application focus addresses performance needs for monitoring and
process control where latencies on the order of 100 ms can be tolerated, with optional
behaviour for shorter latency. ISA draws attention to the fact that it is claimed that
compliance with this standard may involve the use of patents. ISA takes no position
concerning the evidence, validity and scope of these patent rights.
Technical Document of Page D-24 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Work scope of ISA100.11a
To meet the needs of the industrial user, the ISA100.11a standard provides
robustness in the presence of interference found in harsh industrial environments and
with legacy systems. ISA100.11a addresses coexistence with other wireless devices
anticipated in the industrial work space, such as cell phones and devices based on
802.11x, 802.16x, and other relevant standards, as well as providing interoperability of
ISA100 devices.
o Categorizes the communications needs of industrial applications. Analysis of the
patterns of intended use of inter-device industrial wireless communications
resulted in a partitioning of such communications into six classes.
o Defines the protocol stack, system management, gateway, and security
specifications.
o Addresses performance needs for monitoring and process control where latencies
on the order of 100 ms can be tolerated, with optional behaviour for shorter latency.
Status of ISA 100.11a
o The current version is ISA_100_11a_Draft_D2a-2009-03-21.pdf.
o This draft is approved in April 2009 by ISA100 SP100 committee.
o It will be released as ANSI standards.
Relevance to Sensor Networks
o Industrial application is a large and important part of Sensor Network applications.
o Define reference model and protocols including PHY, MAC, NWK， APP layers.
o Cooperation potential area: requirements analysis, routing, communication,
network management and interoperability & performance testing.
Figure D-3 shows the ISA100.11a’s reference model in communication layer stack based
on the Open System Interconnection (OSI) reference model.
Figure D-3. ISA100.11a reference model.
Technical Document of Page D-25 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
D.8 ZigBee Alliance
NWK, APP, and Security running on the top of 802.15.4
ZigBee 2004
o Mesh network is supported without low latency power saving features.
o Hierarchical Block addressing with tree routing capability.
o Limited device mobility and depth.
ZigBee Pro
o Released in 2007.
o Stochastic addressing adopted to avoid the depth limitations with the tree routing
for the mesh network abandoned.
o The probability of address collisions increases as the number of nodes increases.
Figure D-4 shows the ZigBee protocol stack over 802.15.4. It also shows the PHY, MAC,
and application layers, and the functions in each layer.
Figure D-4. ZigBee protocol stack over 802.15.4.
D.9 IETF
IETF is focusing on Layer 3 specifications and higher, resulting in the prevention of
standardization in the area of MAC and PHY
6LoWPAN WG
o NWK specification with the capability of delivering IPv6 packets.
Technical Document of Page D-26 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o Tree Routing with Systematic Addressing
o Basis of IP-USN technology
MANET WG
o Mobile Ad Hoc Network
o Takes care of Mobile-IP Technologies.
D.9.1 IETF 6LOWPAN
6LowPAN (IPv6 over Low power WPAN) protocol running on the top of IEEE 802.15.4
and 4b
There are 2 RFCs
o RFC 4919 : IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals
o RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
D.9.2 IETF ROLL
ROLL (Routing over Low-power and Lossy Networks)
Aiming at L3 routing
Building on top of various PHY/MAC for sensor nodes
Energy efficient routing for sensor networks
Current I-Ds
o Urban WSNs Routing Requirements in Low Power and Lossy Networks
o Industrial Routing Requirements in Low Power and Lossy Networks
o Home Automation Routing Requirement in Low Power and Lossy Networks
D.10 Sensor Web Enablement
High Level Architecture of Sensor Networks
The SWE Standards Framework
o Observations & Measurements (O&M)
o Sensor Model Language (SensorML)
o TransducerML (TML)
o Sensor Observation Service (SOS)
o Sensor Planning Service (SPS)
o Sensor Alert Service (SAS)
o Web Notification Service (WNS)
Other Areas of Sensor Web Standards Harmonization
o IEEE 1451 Transducer interfaces
Technical Document of Page D-27 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
o Imaging Sensors
Figure D-5 shows the concept of connecting various types of sensors using SensorWeb
concept. It illustrates that all sensors report their positions, connected to the Web,
metadata registered and readable remotely. Some sensors can be controlled remotely via
Web.
Figure D-5. Sensor Web concept.
Functionalities of Sensor Web
o Discovery of sensor systems, observations, and observation processes that meet
an application’s or user’s immediate needs
o Determination of a sensor’s capabilities and quality of measurements
o Access to sensor parameters that automatically allow software to process and geo-
locate observations
o Retrieval of real-time or time-series observations and coverage in standard
encodings
o Tasking of sensors to acquire observations of interest
o Subscription to and publishing of alerts to be issued by sensors or sensor services
based upon certain criteria
D.10.1 OpenGIS Specifications by OGC
Observations & Measurements Schema (O&M)
o Standard models and XML Schema for encoding observations and measurements
from a sensor, both archived and real-time.
Sensor Model Language (SensorML)
o Standard models and XML Schema for describing sensors systems and processes;
provides information needed for discovery of sensors, location of sensor
observations, processing of low-level sensor observations, and listing of taskable
properties.
Technical Document of Page D-28 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Transducer Markup Language (TransducerML or TML)
o The conceptual model and XML Schema for describing transducers and supporting
real-time streaming of data to and from sensor systems.
Sensor Observations Service (SOS)
o Standard web service interface for requesting, filtering, and retrieving observations
and sensor system information. This is the intermediary between a client and an
observation repository or near real-time sensor channel.
Sensor Planning Service (SPS)
o Standard web service interface for requesting user-driven acquisitions and
observations. This is the intermediary between a client and a sensor collection
management environment.
Sensor Alert Service (SAS)
o Standard web service interface for publishing and subscribing to alerts from
sensors.
Web Notification Services (WNS)
o Standard web service interface for asynchronous delivery of messages or alerts
from SAS and SPS web services and other elements of service workflows.
Figure D-6 illustrates IEEE 1451 in the Sensor Web Enablement (SWE) interoperability
stack showing that the sensors are connected to the data source tier using NCAP and
adaptor via IEEE 1451. It also shows the Observation Cache and Service Tiers.
Figure D-6. IEEE 1451 in the Sensor Web Enablement (SWE) Interoperability Stack.
Technical Document of Page D-29 of 29
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Annex E
E Indicative List of Standards to Certain Sensor Network Applications
In this section, we listed indicative standards that may be relevant or related to sensor
network applications. Many of the standard numbers, titles, and descriptions listed in this
annex were supplied by the SDOs via the liaison letters to SGSN, and we listed them in this
section. Having the standards listed in this section does not mean that the standards are
relevant, related, and applicable to the technical areas of the sensor networks discussed in
this technical document. Further study and investigation of the listed standards must be
carried out before determining its usefulness for and applicability to sensor network
technologies for standardization. Close examination following the study and investigation are
also necessary and required in order not to duplicate the existing standards, and also to
correctly identify the gaps in standards.
We do not claim that the lists of the standards shown in this section are complete and
exhaustive. When the sensor network standardization starts, additional standards should be
searched and considered.
E.1 Indicative List of IEC Standards and Publications on Sensor Networks for
Industrial Automation and Power/Utility Systems
An indicative list of IEC standards and publications on industrial automation that may be used
for sensor network application is shown in Table E-1 with the standards/publication numbers
and their brief descriptions.
Table E-1. Indicative list of ISO and/or IEC standards and publications for industrial
automation application.
Standards/Publication SDO Standard/Publication Title and Description
ISO 23570 ISO TC184 Distributed Installation in Industrial Applications:
(1) Sensors & Actuators; (2) Hybrid
communications bus;(3) Power distribution bus
IEC TR 62390 IEC TC65 JWG Device Profile Guideline
ISO 11801 ISO/IEC JTC1 Generic cabling for customer premises
SC25 WG3
ISO 14763-n ISO/IEC JTC1 Implementation and operation of customer premises
SC25 WG3 cabling: (1) Administration -2 Planning and installation -
3 Testing of optical fibre cabling
ISO 24702 ISO/IEC JTC1 Generic cabling - Industrial premises
SC25
IEC 61918 IEC SC65C Installation of communications networks in industrial
JWG10 control systems
IEC 61784-5-n IEC SC65C Installation profiles for communication networks in
JWG10 industrial control.
IEC 62026 IEC TC17B Low-voltage switchgear and controlgear – controller
device interfaces (CDIs)
-1 General, -2 As-i, -3 DeviceNet, -4 blank [see 14908-
4] -5 SDS, -6 SMCB (Seriplex)
IEC 61491 IEC TC44 Sercos
IEC TR 61804-1 IEC SC65C Function Blocks for process control; - 1 Requirements
IEC 61804-2 WG7 and system aspects - 2 Specification of the FB concept
Technical Document of Page E-1 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Standards/Publication SDO Standard/Publication Title and Description
IEC SC65E - 3 Electronic device description languages (EDDL) - 4
WG7 EDD interoperability guidelines
IEC 61915 TS IEC SC17B Low-voltage switchgear and controlgear - Principles for
the development of device profiles for networked
industrial devices
IEC 61158-n IEC SC65C Fieldbus technical specifications by types
MT9
IEC 61784-1 IEC SC65C Fieldbus Profiles
MT9
IEC 61784-2 IEC SC65C Digital data communications for measurement and
WG11 control – Part 2: Additional profiles for ISO/IEC 8802-3
based communication networks in real time
application. (RTE profiles)
IEC 61784-3 IEC SC65C Digital data communications for measurement and
WG12 control – Part 3: Profiles for functional safe
communications in industrial
networks
IEC 61508–n IEC SC65A Functional safety
IEC 62443-n IEC SC65 Network and system security; -1 Framework and
WG10 threat-risk analysis -2 Security assurance: principles,
IEC SC65C policy and practice
WG13 -3 Sets of security requirements for security elements
LINKS TO ISA in typical scenarios
SP 99
IEC 62439 IEC SC65C High Availability Automation Networks
WG15
IEC PAS 62453 IEC SC65E Field Device Tool Interface Specification – FDT
WG4
IEC 61499 –n IEC TC65 Function blocks for industrial measurement and control
systems - part 1 architecture, - part 2 software tools, -
part 3
application guidelines
ISO 15745-n ISO TC184 SC5 Open systems application integration framework -1
Generic reference description
IEC 61800-7-n IEC SC22G Generic interface and use of profiles for power drive
WG10 systems (PDS)
-1 Interface definition -2 Profile specifications -3
Mapping of profiles to network technologies.
IEC TC57 has 119 current publications covering power systems and tele-control. Among
them, those standards indicative to sensor network application are listed in Table E-2 with the
standards/publication numbers and their brief descriptions.
Table E-2. Indicative list of IEC TC 57 standards on power system and its automation
application.
Standards/Publication SDO Standard/Publication Title and Description
IEC 60834-n IEC TC 57 Teleprotection equipment of power systems
IEC/TS 61085 IEC TC 57 General considerations for telecommunication services
for electric power systems
Technical Document of Page E-2 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Standards/Publication SDO Standard/Publication Title and Description
IEC/TR 61334 IEC TC 57 Distribution automation using distribution line carrier
systems
IEC/TS 61850-n IEC TC 57 Communication networks and systems for power utility
automation
IEC 61968-n IEC TC 57 English Application integration at electric utilities -
System interfaces for distribution management
IEC 61970-501-n IEC TC 57 Energy management system application program
interface (EMS-API)
IEC/TR 62210 IEC TC 57 Power system control and associated communications
- Data and communication security
IEC/TR 62325-n IEC TC 57 Framework for energy market communications
IEC/TS 62351-n IEC TC 57 Power systems management and associated
information exchange - Data and communications
security
IEC/TR 62357 IEC TC 57 Power system control and associated communications
- Reference architecture for object models, services
and protocols
E.2 Indicative List of SC 6 Standards/Publications on Telecommunications and
Information Exchange Between Systems
JTC 1 SC 6 currently has two new projects that are relevant to sensor networks. These two
projects are on security framework for ubiquitous sensor network and reference architecture
model for sensor network applications and services. These are listed in Table E-3.
Table E-3. Sensor network-relevant new projects in JTC 1 SC 6 on security and
reference architecture model,
Standards/Publication SDO Standard/Publication Title and Description
Telecommunications and Information Exchange
ISO/IEC JTC 1
ISO/IEC CD 29180 Between Systems-- Security framework for
SC 6
ubiquitous sensor network
ISO/IEC JTC 1 Reference architecture model for Sensor network
ISO/IEC NP 29182
SC 6 applications and services
JTC 1 SC 6 currently has a total of 355 published ISO standards under the direct
responsibility of SC 6. Among those standards, many are potentially applicable to sensor
networks, especially the communication technology related standards. An indicative list of
JTC 1 SC 6’ published standards on telecommunications and information exchange between
systems that may be referenced by sensor network applications is shown in Table E-4 with the
standards/publication numbers and their brief descriptions.
Table E-4. Indicative list of JTC 1 SC 6 standards (published) on telecommunications
and information exchange between systems.
Standards/Publication SDO Standard/Publication Title and Description
ISO/IEC JTC 1 Information technology -- Open Systems
ISO/IEC 8348:2002
SC 6 Interconnection -- Network service definition
ISO/IEC 8473-1:1998 ISO/IEC JTC 1 Information technology -- Protocol for providing
Technical Document of Page E-3 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Standards/Publication SDO Standard/Publication Title and Description
series SC 6 the connectionless-mode network service:
Protocol specification
ISO/IEC JTC 1 Information technology -- Protocol for providing
ISO/IEC 8602:1995
SC 6 the OSI connectionless-mode transport service
Information technology -- Telecommunications and
information exchange between systems -- Local
ISO/IEC JTC 1 and metropolitan area networks -- Specific
ISO/IEC 8802-11:2005
SC 6 requirements -- Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
specifications
ISO/IEC 8802- ISO/IEC JTC 1 Medium Access Control (MAC) Security
11:2005/Amd 6:2006 SC 6 Enhancements
Information technology -- Telecommunications and
ISO/IEC JTC 1
ISO/IEC TR 9575:1995 information exchange between systems -- OSI
SC 6
Routeing Framework
Information technology -- Open Systems
ISO/IEC JTC 1
ISO/IEC 9594-1:2001 Interconnection -- The Directory: Overview of
SC 6
concepts, models and services
ISO/IEC JTC 1 Information technology -- Open Systems
ISO/IEC 9594-2:2005
SC 6 Interconnection -- The Directory: Models
Information technology -- Open Systems
ISO/IEC JTC 1
ISO/IEC 9594-3:2005 Interconnection -- The Directory: Abstract service
SC 6
definition
Information technology -- Telecommunications and
ISO/IEC TR ISO/IEC JTC 1 information exchange between systems --
10172:1991 SC 6 Network/Transport Protocol interworking
specification
Information technology -- Telecommunications and
information exchange between systems --
Intermediate System to Intermediate System intra-
ISO/IEC JTC 1
ISO/IEC 10589:2002 domain routeing information exchange protocol for
SC 6
use in conjunction with the protocol for providing
the connectionless-mode network service (ISO
8473)
ISO/IEC TR ISO/IEC JTC 1 Information technology -- Quality of service --
13243:1999 SC 6 Guide to methods and mechanisms
ISO/IEC TR ISO/IEC JTC 1 Information technology -- Lower layers security
13594:1995 SC 6
Information technology -- Telecommunications and
information exchange between systems -- Private
Integrated Services Network -- Inter-exchange
ISO/IEC JTC 1
ISO/IEC 15429:2003 signalling protocol -- Wireless Terminal Location
SC 6
Registration supplementary service and Wireless
Terminal Information exchange additional network
feature
ISO/IEC JTC 1 Information technology -- Group management
ISO/IEC 16513:2005
SC 6 protocol
Information technology -- Telecommunications and
ISO/IEC JTC 1 information exchange between systems -- Private
ISO/IEC 17876:2003
SC 6 Integrated Services Network -- Inter-exchange
signalling protocol -- Private User Mobility (PUM) -
Technical Document of Page E-4 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Standards/Publication SDO Standard/Publication Title and Description
- Registration supplementary service
Information technology -- Telecommunications and
ISO/IEC JTC 1 information exchange between systems --
ISO/IEC 24771:2009
SC 6 MAC/PHY standard for ad hoc wireless network to
support QoS in an industrial work environment
Information technology -- Telecommunications and
ISO/IEC JTC 1
ISO/IEC 26907:2007 information exchange between systems -- High
SC 6
Rate Ultra Wideband PHY and MAC Standard
An indicative list of JTC 1 SC 6’ standards under development on telecommunications and
information exchange between systems that may be referenced by sensor network
applications is shown in Table E-5 with the standards/publication numbers and their brief
descriptions.
Table E-5. Indicative list of JTC 1 SC 6 standards (under development) on
telecommunications and information exchange between systems.
Standards/Publication SDO Standard/Publication Title and Description
Information technology -- Open Systems
ISO/IEC FDIS 9594-1 & ISO/IEC JTC 1 Interconnection – (1) The Directory: Overview of
2 SC 6 concepts, models and services & -- (2) The
Directory: Models
Information technology -- Open Systems
ISO/IEC JTC 1
ISO/IEC FDIS 9594-4 Interconnection -- The Directory: Procedures for
SC 6
distributed operation
Information technology – Telecommunications and
ISO/IEC JTC 1
ISO/IEC DIS 13157 information exchange between systems -- NFC-
SC 6
SEC: NFCIP-1 Security Services and Protocol
PHY/MAC specifications for short-range wireless
ISO/IEC FCD 29157 ISO/IEC JTC 1
low-rate applications in ISM band
Information technology – Enhanced
communications transport protocol: (4)
ISO/IEC DIS 14476-4 & ISO/IEC JTC 1
Specification of QoS management for duplex
6 SC 6
multicast transport & (6) Specification of QoS
management for N-plex multicast transport
E.3 Indicative List of SC 25 Standards/Publications on Smart Homes and
Home Automation
An Indicative list of JTC 1 SC 25 standards on security and privacy for home electronics and
home network that may be referenced by a sensor network application is shown in Table E-6
with the standards/publication numbers and their brief descriptions.
Table E-6. Indicative list of JTC 1 SC 32 standards on security and privacy for Home
Electronic Systems and Home Network. applications,
Standards/Publication SDO Standard/Publication Title and Description
Information technology -- Home Electronic System
ISO/IEC JTC 1 (HES) Application Model -- Part 4: Security
TR 15067-4:2001
SC 25 System for HES
Technical Document of Page E-5 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Standards/Publication SDO Standard/Publication Title and Description
This TR includes a number of privacy related
scenario like; Latch-key child, Medical alert,
Elderly person monitoring
ISO/IEC JTC 1 Information technology -- Home network security --
ISO/IEC 24767-1:2009
SC 25 Part 1: Security requirements
An indicative list of JTC 1 SC 25 standards specific to home network security requirements is
shown in Table E-7 with the standards/publication numbers and their brief descriptions.
Table E-7. Indicative list of JTC 1 SC 25 standards on security requirements for Home
Network. Home Automation applications.
Standards/Publication SDO Standard/Publication Title and Description
Information technology -- Home network security --
Part 1: Security requirements
This International standard specifies three
ISO/IEC JTC 1
ISO/IEC 24767-1:2009 architectural models for security for: owner supported
SC 25
single home HES (OSS), externally supported
multiple homes HES (ESM) and externally
supported single home HES (ESS), that influence
the implementation of middleware.
Other indicative list of the standards from JTC 1 SC 25 is shown in Table E-8 with the
standards/publication numbers and their brief descriptions. These standards are specific to
Home Electronic Systems, Home Networks, and Home Automation applications.
Table E-8. Other indicative list of JTC 1 SC 25 standards on Home Electronic Systems,
Home Networks applications.
Standards/Publication SDO Standard/Publication Title and Description
ISO/IEC 14543-n-n ISO/IEC JTC 1 Information technology - Home Electronic Systems
series SC 25 (HES) Architecture
ISO/IEC CD 29104-n ISO/IEC JTC 1 Information technology - Centralized Management
series SC 25 Protocol (CMP) for Ubiquitous Home Network Services
Information technology -- Home Electronic System --
ISO/IEC JTC 1
ISO/IEC 18012-1:2004 Guidelines for product interoperability -- Part 1:
SC 25
Introduction
ISO/IEC JTC 1 Information technology -- Home Electronic System --
ISO/IEC CD 18012-2
SC 25 Guidelines for product interoperability
ISO/IEC JTC 1 Information technology -- Home network security
SO/IEC 24767-n series
SC 25
Open Data Communication in Building Automation,
ISO/IEC DIS 14908-n ISO/IEC JTC 1
Controls and Building Management -- Control Network
series SC 25
Protocol
Interconnection of Information Technology Equipment -
ISO/IEC WD 29145-n ISO/IEC JTC 1
- WiBEEM Standard for Wireless Home Network
series SC 25
Services
Technical Document of Page E-6 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
E.4 Indicative List of JTC 1 SC 32 Standards on Operation Architecture
An indicative list of standards on the operational architecture aspects of eBusiness that may
be referenced to a sensor network application is shown in Table E-9 with the
standards/publication numbers and their brief descriptions.
Table E-9. Indicative list of JTC 1 SC 32 standards on operational architecture
application.
Standards/Publication SDO Standard/Publication Title and Description
ISO/IEC 14662 ISO/IEC JTC 1 Open-edi reference model – Business Operational
SC 32 View (BOV) and Functional Service view (FSV) for
e-business
ISO/IEC 15944 ISO/IEC JTC 1 Business Operational View (BOV) for eBusiness
SC 32 Functional Service View (FSV) for eBusiness
E.5 Indicative List of JTC 1 SC 37 Standards/Publications on Biometrics
Applications
An Indicative list of JTC 1 SC 37 standards and publications that may be applicable to sensor
networks use in biometric is shown in Table E-10 with the standards/publication numbers and
their brief descriptions.
Table E-10. Indicative list of JTC 1 SC 37 standards on security for biometric
applications.
Standards/Publication SDO Standard/Publication Title and Description
Information technology -- Biometric template protection
ISO/IEC JTC 1
ISO/IEC 24745 (CD) is focused on the essential security mechanisms
SC 37
required for the protection of biometric templates
Information Technology -- Security Techniques -- A
Framework for Identity Management e integrated
ISO/IEC JTC 1 concept of processes, policies and technologies that
ISO/IEC 24760 (CD)
SC 37 enable organizations and individual entities to facilitate
and control the use of identity information in their
respective relations)
Information technology -- Security techniques --
Authentication context for biometrics defines the
structure and the data elements of Authentication
Context for Biometrics (ACBio), which is used for
ISO/IEC JTC 1
ISO/IEC 24761 (IS) checking the validity of the result of a biometric
SC 37
verification process executed at a remote site. The
specification of ACBio is applicable not only to single
modal biometric verification but also to multimodal
fusion.
Information technology -- Security techniques --
Privacy framework provides a framework for defining
ISO/IEC JTC 1
ISO/IEC 29100 (CD) privacy safeguarding requirements as they relate to PII
SC 37
processed by any information and communication
system in any jurisdiction
e architecture is intended to provide a privacy
ISO/IEC JTC 1 reference architecture model that will describe best e
ISO/IEC 29101 (WD)
SC 37 the processing of personally identifiable information
(PII) in information and communication
Technical Document of Page E-7 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
Standards/Publication SDO Standard/Publication Title and Description
systems
Information technology -- Security techniques -- Entity
authentication assurance provides objective and
vendor neutral guidelines for assuring the
authentication of entities, i.e. persons, objects, or
ISO/IEC JTC 1
ISO/IEC 29115 (WD) applications. It also describes the guidelines or
SC 37
principles that must be considered in authentication
assurance and the rationale for why they are important
to an authentication decision. This project is a joint
project with ITU-T SG 17
Technical Document of Page E-8 of 8
ISO/IEC JTC 1 Study Group on Sensor Networks (SGSN)
