Docstoc

Technical ument ISO IEC JTC Study Group on Sensor Networks

Document Sample
Technical ument ISO IEC JTC Study Group on Sensor Networks Powered By Docstoc
					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)

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:21
posted:7/29/2011
language:English
pages:166