[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

6lowapp                                                          R. Gold
Internet-Draft                                                   S. Krco
Intended status: Informational                                  Ericsson
Expires: April 22, 2010                                        A. Gluhak
                                                    University of Surrey
                                                               Z. Shelby
                                                               Sensinode
                                                        October 19, 2009


                      SENSEI 6lowapp Requirements
                      draft-gold-6lowapp-sensei-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 22, 2010.

Copyright Notice




Gold, et al.             Expires April 22, 2010                 [Page 1]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This draft examines the requirements created by the SENSEI project
   which are relevant to the 6LowApp interest group.  The SENSEI project
   is a large-scale EU project dealing with the design and
   implementation of a framework for supporting applications wishing to
   use sensor information.



































Gold, et al.             Expires April 22, 2010                 [Page 2]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Markets and Scenarios . . . . . . . . . . . . . . . . . . . . . 5
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.1.  General . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.2.  Application Protocols . . . . . . . . . . . . . . . . . . . 7
     3.3.  Application Commissioning . . . . . . . . . . . . . . . . . 8
   4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



































Gold, et al.             Expires April 22, 2010                 [Page 3]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


1.  Introduction

   In order to fully realize the vision of intelligent machine-to-
   machine (M2M) communication, heterogeneous wireless sensor and
   actuator networks (WS&AN) have to be integrated into a common
   framework of global scale on the Internet.  This framework will need
   to make the resources of the WS&ANs available to services and
   applications via a set of open service interfaces.  The SENSEI
   project is a large European Union Framework 7 project started in 2008
   with a consortium of 19 partners [SENSEI].  This project has created
   an open architecture that fundamentally addresses the scalability
   problems for a large number of globally distributed WS&AN devices.
   It provides necessary network and information management services to
   enable reliable and accurate context information retrieval and
   interaction with the physical environment.  By adding mechanisms for
   accounting, security, privacy and trust it enables an open and secure
   environment for context-awareness and real world interaction.

   The SENSEI Framework represents sensors and actuators as resources.
   A Resource is a conceptual representation, in the SENSEI domain, of
   any information source that enables real world sensing or has the
   ability to act upon the environment and entities within it.  In
   addition to Resources that have direct access to the physical world,
   the concept covers also indirect information sources that acquire
   context information via aggregation, fusion or even inference from
   other SENSEI Resources.  The SENSEI Framework has been designed using
   fundamental concepts of the World-Wide Web. In order to enable the
   SENSEI framework on even the most constrained devices (simple
   sensors) and networks (such as 6LoWPAN [RFC4944]), it makes use of a
   SENSEI embedded resource concept extending the web resource model to
   minimal IPv6 nodes with very little overhead.

   SENSEI project has made the initial implementation of the designed
   global framework.  It consists of the SENSEI core components: -
   Resource Directory: serving as a rendez-vous point for resources and
   resource users, it is storing descriptions of all available
   resources.  XML is used to describe the resources.  There are two
   types of description: basic and advanced.  The basic descriptions
   contain simple text based tags identifying the resource.  Advanced
   resource descriptions contain semantic descriptions with detailed
   information about the context of the resource including its location,
   available operations, inputs, outputs, etc.  All resource
   descriptions are XML based. - Semantic Query Resolver: Responsible
   for analysis of high level user queries and discovery of suitable and
   available resources capable of providing information required to
   respond to the queries - Wireless sensor and actuator network islands
   that interact with the framework via their respective gateways.
   Implementation of a SENSEI resource end point wrapper is provided and



Gold, et al.             Expires April 22, 2010                 [Page 4]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


   can be applied to any gateway to make it SENSEI compliant.
   Communication between all framework components is implemented using
   RESTful interfaces.  POST, GET, UPDATE and DELETE messages are used
   to implement defined interfaces: RPI (Resource Publication
   Interface), RLI (Resource Lookup interface) and RAI (Resource Access
   Interface).  WS&AN Gateways are responsible for compression of these
   messages for the end sensor nodes using EXI.

   The SENSEI project has very similar goals to 6LowApp
   [I-D.bormann-6lowpan-6lowapp-problem], and has considered a wide
   range of M2M applications.  This document introduces selected markets
   and scenarios that SENSEI is addressing and the requirements which
   have been derived from them for achieving the SENSEI resource
   architecture.  We especially look at the SENSEI embedded resource
   concept, and the requirements related to that useful also in the
   scope of 6LowApp.  Finally the document concludes with possible
   contributions to the 6LowApp effort.


2.  Markets and Scenarios

   A large effort has been made in SENSEI to identify and study relevant
   markets and application scenarios for this technology.  In this
   section we look at a subset of these applications.

   Transportation: Modern cars along with the roads are becoming more
   instrumented with sensors.  Taking information from these different
   sources and presenting it to the driver and/or passengers of a car
   would allow better navigation and safety.  Collision avoidance
   systems and monitoring of transportation of hazardous materials are
   two typical examples.  Governmental authorities would also benefit
   from more accurate information about road traffic patterns for
   planning purposes.  Enterprises, such as freight companies, would be
   able to perform more effective route optimization which allows energy
   savings.

   Smart places: The major issues of the future have to be tackled in
   cities: environment, security and well-being.  To meet these needs,
   sensors and actuators will thrive preferably there thanks to
   economies of scale.  This will take the form of mapping the physical
   space into the Internet by allowing the public to interact, locally
   or remotely, with the physical environment through the Internet via
   the use of mobile devices.

   Building automation: Every building (houses, offices etc.) will have
   wireless sensor and actuator networks in order to automate some
   processes, to support in users' activities, to make people more
   comfortable and to secure their environment through more efficient



Gold, et al.             Expires April 22, 2010                 [Page 5]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


   energy consumption.  There is a critical opportunity for deploying
   Sin's in every building.  In addition to the standard WS&AN
   applications like the monitoring of temperature, humidity and other
   parameters in a certain area or room, applications improving energy
   management are of increasing importance.

   Supply chain management: Whilst SENSEI examines passenger transport,
   supply chain management is an equally important area focusing on
   goods transport.  As for passenger transport mobility is a key issue
   for future for goods transport as well, because supply chains are
   getting ever more global.  In particular for cross border shipments,
   companies have to stick to regulations imposed by external
   authorities, environmental or social regulations.


3.  Requirements

   Using the application scenarios identified for the project,
   requirements were extracted for achieving the global resource
   architecture of the project.  In this section the general project
   requirements are first summarized.  This is followed by an analysis
   of technical requirements related to realizing the SENSEI embedded
   resource concept that will be of interest to 6LowApp.

3.1.  General

   General requirements that have been derived from the SENSEI scope and
   problem statement are as follows:

   (1)  Horizontalisation: Facilitate the horizontal reuse of sensing,
        actuation and processing resources for a large number of
        applications.  This is similar to the idea of software reuse in
        software engineering.  Rather than having to recreate custom
        bespoke solutions from scratch, it would be more efficient to
        reuse the existing infrastructure.

   (2)  Heterogeneity: Accommodate a variety of different (technology,
        administrative domains) sensor and actuator networks at its
        edges.  Whilst there will undeniably be an enormous variety of
        sensors and actuators in the future, it is essential to use a
        common method for interacting with them.

   (3)  Reduced Complexity: Reduce the complexity of accessing sensing
        and actuation resources for applications.  Since many sensors &
        actuators and even gateways will have limited hardware
        resources, keeping the complexity to an absolute minimum will be
        crucial for the successful operation of the system.




Gold, et al.             Expires April 22, 2010                 [Page 6]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


   (4)  Simplicity: Reduce the barrier of participation for WS&ANs and
        thus facilitate deployment by ease of integration.  Related to
        the previous point, it is important that it is simple and
        straightforward for new WS&ANs to be connected to a SENSEI
        system and for these resources to be easily accessible.

   (5)  Evolvability: The architecture must be evolvable to withstand
        technological change forced upon by tussles carried out by
        actors in the eco-system.  For reasons of sustainability we wish
        to maximize the lifetime of the deployed system by allowing it
        to be retasked to support new sensors and also new applications.

3.2.  Application Protocols

   The SENSEI project has designed and implemented an embedded web
   resource protocol with similar goals to that of 6LowApp.  In this
   section we have extracted the key requirements used for this design.
   In the realization of SENSEI resources and components, their
   interfaces have been designed using RESTful principles.

   Application protocol requirements from SENSEI:

   (1)  Push & Pull methods of interaction need to be supported.
        Additionally, both one-time and periodic versions of these
        interaction methods need to be supported to support as wide a
        range of interactions as possible.  As sensor nodes are often
        available with a small duty cycle, a subscription-based PUSH
        feature is critical to the application protocol.  It should be
        noted here that push interaction without any optimization is
        quite resource-intensive as it requires soft-state to be kept at
        the resource as to who the subscribers are.

   (2)  URL identifiers for resources, with the ability to compress URLs
        with out-of-band identifiers.

   (3)  Caching and the ability to deal with sleeping nodes at the edge
        of IP sensor network (e.g. 6LoWPAN) islands.

   (4)  Support for REST methods (GET, POST, PUT, DELETE) allowing for
        easy interoperability with HTTP through a proxy.

   (5)  Support for UDP as a transport.  Wireless mesh networks suffer
        from packet losses and SENSEI transactions are often just a
        single packet exchange.  TCP is not suitable in such situations
        due to its sensitivity to large variations in latency which are
        typical of wireless cellular networks and also keeping a TCP
        connection up in the presence of mobility is a challenging task.




Gold, et al.             Expires April 22, 2010                 [Page 7]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


   (6)  Internet media type and transfer encoding type support.  The
        project uses RDF/XML and XML payloads which are encoded using
        EXI.

   (7)  A compact protocol header which is easy to parse.

3.3.  Application Commissioning

   SENSEI performs application commissioning using what is called the
   Resource Publication Interface (RPI).  This interface is realized
   with the same embedded web resource protocol on a well-known URL on
   the proxy (usually on the Edge Router of the WS&AN) supporting REST
   methods.  Embedded resources advertise themselves by sending an EXI
   encoded XML resource description, describing its resources available,
   the interfaces to access them and meta-data.

   Once resources have been published, they can subsequently be looked
   up by using the corresponding Resource Lookup Interface (RLI).  The
   RLI supports both one-shot lookups and longer-lasting lookup
   subscriptions.  Similar to the RPI above, it uses an embedded web
   resource protocol to provide this functionality.

   The only requirement this kind of application commissioning requires
   is for the embedded web protocol to support URLs and standard content
   and encoding types.  For more general use multicast support may also
   be required.


4.  Conclusions

   The SENSEI project has developed an architecture for globally
   scalable web resources for machines, sensors and actuators - The
   Internet of Things.  Part of this architecture includes an embedded
   resource concept enabling web resources on very constrained devices
   and networks while maintaining end-to-end IP principles and easy
   interoperability with existing web protocols.

   Potential contributions of this consortium to the 6LowApp effort may
   include:

   (1)  Input to the problem statement, objectives and requirements

   (2)  Participation in the design of an embedded web resource protocol

   (3)  Participation in the requirements and design of application
        commissioning





Gold, et al.             Expires April 22, 2010                 [Page 8]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


   (4)  Possible input on security, web architecture integration,
        scalability and resource mobility.


5.  Security Considerations

   No security issues have been identified in this draft.


6.  IANA Considerations

   This draft requires no IANA consideration.


7.  Acknowledgments

   We wish to thank our fellow members of the SENSEI consortium for many
   fruitful discussions.


8.  References

8.1.  Normative References

   [I-D.bormann-6lowpan-6lowapp-problem]
              Bormann, C., Sturek, D., and Z. Shelby, "6LowApp: Problem
              Statement for 6LoWPAN and LLN Application Protocols",
              draft-bormann-6lowpan-6lowapp-problem-01 (work in
              progress), July 2009.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

8.2.  Informative References

   [SENSEI]   The SENSEI Work Package 3 team, "Reference Architecture",
              Deliverable 3.2, 12 2008, <SENSEI>.













Gold, et al.             Expires April 22, 2010                 [Page 9]


Internet-Draft         SENSEI 6lowapp Requirements          October 2009


Authors' Addresses

   Richard Gold
   Ericsson
   Faeroegatan 6
   Kista  16480
   Sweden

   Phone: +46 76 11 53 725
   Email: richard.gold@ericsson.com


   Srdjan Krco
   Ericsson
   Milana Savica 60
   Novi Sad  N/A
   Serbia

   Phone: +38163531683
   Email: srdjan.krco@ericsson.com


   Alex Gluhak
   University of Surrey
   University of Surrey
   Guildford  GU2 7XH
   UK

   Phone: +44 1483 689124
   Email: a.gluhak@surrey.ac.uk


   Zach Shelby
   Sensinode
   Kidekuja 2
   Vuokatti  88600
   FINLAND

   Phone: +358407796297
   Email: zach@sensinode.com











Gold, et al.             Expires April 22, 2010                [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/