Download 3GPP report skeleton

GISFI Meeting # 10
Delhi, India – Sept 10-12, 2012
GISFI_IoT_201209292
Agenda item:
WG IoT
Source:
TCS
Title:
Naming and Addressing in IoT
Document for:
Discussion and approval to accept as input documents for the IoT
Framework Technical Report document
GISFI TR 09.001 V2.0.0 (2012-09)
Technical Report
Global ICT Standardisation Forum for India
Internet of Things
M-Health System Use cases
(Release 1)
GISFI TR 09.001 V2.0.0 (2012-09)
Technical Report
Global ICT Standardisation Forum for India;
Technical Working Group IoT;
Technical Report on Naming and Addressing (Release 1)
The present document has been developed within GISFI and may be further elaborated for the purposes of GISFI.
Release 1
3
GISFI TR 09.001 V2.0.0 (2012-09)
Keywords
Internet of Things, Naming, Addressing, Ubiquity, Identity
GISFI
GISFI office address
Global ICT Standardisation Forum for India (GISFI),
Singhad Campus, Gat 308/309, Kusgaon (Bk.)
Off. Mumbai– Pune Expressway, Lonavala, India
Tel.: +91 2114 304 353 / 401 Fax: +91 2114 278304
Internet
http://www.gisfi.org
E-mail: [email protected]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© 2010, GISFI
All rights reserved.
GISFI
Release 1
4
GISFI TR 09.001 V2.0.0 (2012-09)
Contents
Intellectual Property Rights ................................................................................................................................ 5
Foreword............................................................................................................................................................. 5
Introduction ........................................................................................................................................................ 5
1
Scope ........................................................................................................................................................ 6
2
References ................................................................................................................................................ 6
2.1
3
3.1
3.2
4
4.1
4.2
4.3
4.4
4.5
Normative references ......................................................................................................................................... 6
Definitions and abbreviations................................................................................................................... 6
Definitions ......................................................................................................................................................... 6
Abbreviations ..................................................................................................................................................... 7
Naming and Addressing in IoT ................................................................................................................ 7
Introduction........................................................................................................................................................ 7
Addressing Schemes .......................................................................................................................................... 8
Managing Names and Addresses ....................................................................................................................... 8
Names and Addresses by other Standard Bodies ............................................................................................... 9
Interface requirement for naming and addressing .............................................................................................. 9
GISFI
Release 1
5
GISFI TR 09.001 V2.0.0 (2012-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to GISFI. The information
pertaining to these essential IPRs, if any, is publicly available for GISFI members and non-members, and can be
found in GISFI yyy: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to GISFI
in respect of GISFI standards", which is available from the GISFI Secretariat. Latest updates are available on the
GISFI Web server (http://www.gisfi.org).
Pursuant to the GISFI IPR Policy, no investigation, including IPR searches, has been carried out by GISFI. No
guarantee can be given as to the existence of other IPRs not referenced in GISFI yyy (or the updates on the GISFI
Web server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by GISFI WG Internet of Things (IoT).
The present document may be referenced by other TRs and Technical Standards (TS) developed by GISFI WG IoT.
Introduction
IoT is an integrated part of the future Internet that could be defined as “a dynamic global network infrastructure with
self-configuring capabilities linking physical and virtual objects through the exploitation of data capture and
standard and inter-operable communication protocols”.
This infrastructure includes existing and evolving Internet and will offer specific object-identification and
addressing, sensor and connection capability as the basis for the development of independent and/or federated
services and applications. These will be characterized by a high degree of autonomous data capture, context and
event detection and transfer, network connectivity and interoperability at the protocol and semantic level with the
provision of handling security and privacy concerns of the users and the data being communicated.
Since the IoT core is envisioned as an IP based network and supports different telecommunication infrastructures
such as DSL, Cellular networks, etc, the gateway is connected to numerous sensors using interface I1. IoT
applications are connected to the sensor gateway over the core network. Since the sensors (which are IoT
devices/IoT limited devices) perform multiple functions associated with different resources like temperature,
humidity, GPS etc, they can be further classified into different groups based on their functionality, as well as using
specific syntax and semantics (name and address) for interoperation.
The present document discusses general requirements related to naming and addressing of IoT devices and the
approved content of this can be mapped to the Naming and Addressing (Section 9, Draft - GISFI_IOT_201106103)
in future.
GISFI
Release 1
1
6
GISFI TR 09.001 V2.0.0 (2012-09)
Scope
The present document specifies issues related to naming and addressing of IoT devices.
2
References
2.1
Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1]. Technical Report on IoT Reference Architecture (Draft - GISFI_IoT_201203175)
[2]. Frame-work document for Technical Report on IoT Service Requirements (Draft GISFI_IoT_201106103)
[3]. http://www.scribd.com/doc/81784648/ETSI-TS-102-690-v-1-1-2-2011
[4]http://tools.ietf.org/html/rfc3986
[5] http://www.ietf.org/rfc/rfc2396.txt
[6]http://tools.ietf.org/html/draft-shelby-core-resource-directory-04
2.2 Informative references
The following referenced documents are not essential to the use of the GISFI deliverable but they assist the user
with regard to a particular subject area. For non-specific references, the latest version of the referenced document
(including any amendments) applies.
[1].
[2]
ITU-T Study Group -2 document on National Numbering Plan (Docs related to ITU-T E.164)
Draft TISPAN MI [00058] V0.0.11 (2011-03), ETSI TISPAN Future Topics, March 2011
3
Definitions and abbreviations
3.1
Definitions
For the purposes of the present document, the following terms and definitions apply:
IoT System: IoT is an integrated part of the future Internet that could be defined as “a dynamic global network
infrastructure with self-configuring capabilities linking physical and virtual objects through the exploitation of data
capture and standard and inter-operable communication protocols”.
IoT Device: Entity capable of sensing the state/features of an object and has communication and computing
capability. It may run limited local applications. The IoT device connects to the IoT Core network either through a
gateway or directly through embedded gateway functionality.
IoT Limited Device: It is an IoT device without capability of local computing (applications). It can communicate to
another IoT device or gateway. From the IoT perspective, it is managed by the IoT device/gateway to which it
connected.
IoT Gateway: IoT Gateway acts as a proxy between the IoT devices and IoT Core network. It shall locally manage
the IoT devices (including IoT Limited Devices) and shall run IoT applications.
IoT Network: IoT Network includes the access network that connects the IoT devices to the gateway and core
network that connects the gateways to the IoT service platforms.
IoT Service Platform: It provides an open interface to IoT functions that can be shared by multiple applications. It
hides the intricacies of underlying IoT system and eases the application development. Further various system
management and control functions are also taken care here.
GISFI
Release 1
7
GISFI TR 09.001 V2.0.0 (2012-09)
IoT Applications: IoT applications are domain specific applications that use various services exposed by IoT
Service Platform.
3.2
Abbreviations
For the purposes of the present document, the following abbreviations apply:
IoT
IP
ARP
RFID
DNS
ONS
NAPTR
URI
4
Internet of Things
Internet Protocol
Address Resolution Protocol
Radio Frequency ID
Domain Name Services
Object Name Services
Naming Authority Pointer
Uniform Resource Identifier
Naming and Addressing in IoT
As discussed in the IoT reference architecture, each IoT device or limited device or things and gateways of IoT
should have names and addresses, such that individual device can be contacted for communication and other
management functionalities. However, the number of IoT devices are extremely large as they cater various
applications and services under IoT. This makes the naming and addressing schemes crucial and difficult. This
document presents issues related to naming and addressing of IoT devices.
4.1
Introduction
The IoT system should be flexible in supporting more than one naming schemes. It should support identification of
devices/things of IoT or group of devices by their names, temporary ID, pseudo-name, location or combination
thereof. It shall be possible to re-use these names and IDs for certain classes of devices or in an environment where
resources are constrained. The naming system should be flexible and should allow plug and play kind of
environment. Plug and play addressing in IoT should also support discovery of devices and capabilities. This should
be included in the naming and localization mechanism. Both Internet support for device and service localization, as
well as Intranet use cases should be supported by the proposed scheme. Factors dealing with device exchange,
failure, location change due to mobility), or service migration (shifted virtual process) should also be considered in
the addressing mechanism. Emphasis should be given for the use of unique IDs to the devices, such that ID based
security can be deployed in future. In short, the naming and addressing scheme under IoT should have following
key features:

Consistency – similar/same naming format for all devices

Scalability – with the increase in number of devices, the addressing scheme should not suffer.

Uniqueness – globally unique IDs should be used to ensure security, longevity in naming, effective routing
and quick address resolution.

Single vs. multiple IDs – one device can have one or more than one IDs (Private/Public).

Interoperability – devices should be used as plug-and-play devices without any service provider restriction.

Backward compatibility – should allow backward compatibility, in case new number scheme is deployed.

Management – device replacement, mobility, addition should be handled effectively.

Network information management – should define whether age old NMS (SNMP) should be used or not?

Hierarchy – should maintain hierarchy of different sensing resources as well as the hierarchy of domains and
sub-domains [3].

Hidden – the access network details should be kept hidden.
The end nodes can also use identifiers similar to Uniform Resource Identifier (URI). For example, URI specifying
CoAP (Constrained Application Protocol) protocol running on a Sensor Gateway (IoT device), locating a
temperature sensor or IoT device follows URI structure with these fields.
Syntax: URI = "coap:" "//" <HOST> [ ":" <PORT> ] <PATH> [ "?" <QUERY>]
GISFI
Release 1
8
GISFI TR 09.001 V2.0.0 (2012-09)
Example: coap://example.com:436/sensors/temp?min=10
4.2
Addressing Schemes
Since the IoT devices and the limited devices are the devices of Internet and Intranet, the IoT System shall allow
flexible addressing schemes, including:







IP V-4 and IP V-6 addressing
E.164 addresses (e.g. MSISDN, under ITU-T national numbering plan)
IMSI (International Mobile Subscription Identity)
RFIDs
URN (Uniform Resource Naming System), URL, e.g. SIP or e-mail addresses.
DOI – Digital Object Identifier
URI [4]
4.3

Managing Names and Addresses
Address Resolution under IoT – Which protocol should be used for address resolution?
Since IoT defines Layer-4 and above, ARP may not come under the scope of IoT. In addition, mapping
between link and networks layer also need to be considered. ONS (Object Name Services) may be considered
for address resolution. Since ONS is implemented using DNS with Naming Authority Pointer (NAPTR),
missing authorization and authentication connected to ONS may create problem in implementation.

Host configuration and address discovery protocols – when a node joins the network. IoT WG should
define the type of protocols to be used for this purpose.

Resource identification
Identification of resources by the gateway [1] is an important aspect for naming and addressing in IoT. How the
sensors are going to be exposed by the gateway is an important point to be considered. Exposing the resources or
the sensors or the end nodes as Web resources is an important step for identification of the resources.
Following example shows a URI structure, the URI generic syntax is described in ref[5].
The example of URI given in the section 4.1, where CoAP protocol running on a Sensor Gateway (IoT device),
locating a temperature sensor uses the syntax
Syntax: URI = "coap:" "//" <HOST> [ ":" <PORT> ] <PATH> [ "?" <QUERY>]
Authority
Example: coap://example.com:436/sensors/temp?min=10.
Where Query parameters are represented as traditional? Name=value [&...] URL parameters. Formation of query
may vary depending on the various scenarios and services expected from the resources.
The resource identification requires the following steps:
1. Maintaining a resource identification table or resource directory to keep track of the resource or end node
GISFI
Release 1
2.
3.
9
GISFI TR 09.001 V2.0.0 (2012-09)
details in the gateway.
Resource or end-node discovery which can be either done by the IoT gateway or by the end node obeying
a specific architecture, where the end-nodes discover the IoT gateway and its associated resource
identification table.
Registration by the end-nodes by specifying their own capabilities
URI based interfaces with defined paths following the REST architecture is a working option in this space.
[6] Example: An endpoint that wants to make itself discoverable occasionally sends a POST request to the ‘/.wellknown/core ‘URI of any candidate directory server having the resource directory that it finds, based on the
IoT reference architecture it may be located at sensor gateway .
Information exchange like device registration needs to be done by establishing a secured channel.

Service discovery
This function is associated with naming and addressing methodology. Since gateways interact with the Internet,
they may also contain web application. Knowing the URI of the gateway and its resources the resources and their
associated services can be identified. A resource identification table or resource directory is maintained by the
gateway, and each resource is identified by the specific URI.

4.4
Security based on identity
Names and Addresses by other Standard Bodies

ITU-T: Naming and addressing is being actively considered as a part of Study Group (SG) – 2, under
ITU-T. SG-2 is also involved in national numbering plans (ITU-T E.164) with backward
compatibility for a period of at-least 6 months.

ETSI: ETSI is also contributing individually and through ITU-T for defining names and addresses to
IoT devices.

IETF provides drafts towards the web based identification of the resources using URI.
4.5
Interface requirement for naming and addressing
Requirements of the various interfaces of the IoT architecture specific to naming and addressing are
discussed in this section. Following table summarizes the various requirements.
Since identification/naming or to address any object in IoT is based on control/management
functionalities the management type of interfaces demands specific need, where as data type of interfaces
do not have any specific requirement in this scenario.
The possible scopes for standardization are marked bold and underlined in the table, and in the section
4.4, these identifies are scope requires further discussion and study.
Table -1
GISFI
Release 1
Interfaces
10
Type
Requirements specific to naming and
addressing
I1
GISFI TR 09.001 V2.0.0 (2012-09)
Capabilities
I1a is the interface that has the
capability of handling the data path
between devices and gateway.
I1a
Data
Supports the generic requirement of the
I1a
I1b
Management
1. Exposing unique identification (example
URI) of the resource directory or resource
identification table. 2. Performing resource
or end-node discovery which can be
either done by the IoT gateway or by the
end node obeying specific methods,
where the end-nodes discover the IoT
gateway and its associated resource
identification table. Here some standard
method can be proposed based on the
resource optimization, concerning
security aspects 3. Registration by the
end-nodes by specifying their own
capabilities.4. Establishing a secured
channel during device registration.
I2
Device specific management functions
such as sensor sampling configuration,
security settings, device registration,
etc will be done through this interface.
This is the reference interface between
the IoT gateway and IoT service
platform. It has a data path as well as a
management path. The connectivity is
provided using IoT Core Network
which is predominantly an IP capable
core network infrastructure such as
xDSL, 3GPP, 3GPP2, etc.
I2a
Data
Supports the generic requirement of the
I2a.
I2b
Management
Exposing unique identification (example
URI) of the resource directory or resource
identification table to the IoT serviceplatform with proper identifiers (like path,
port etc. w.r.t URI) so that service platform
can identify the resources or sensors.
I2c
Self-loop
Similar
Gateways
This interface takes care of
communication between gateways to
enable mobility, resilience, and
scalability.
I3
This interface provides a uniform
access of various IoT services to the
domain specific vertical applications.
The applications may run at different
physical entities but they need to have
the IoT services access from multiple
service providers.
I3a
Data
Supports the generic requirement of the
I3a
GISFI
Standard
body
Release 1
11
I3b
Management
I3c
Intra-layer
communicati
ons
1. Exposing unique identification (example
URI) of the resource directory or resource
identification table to the applications for
the service identification by them.
2. Establishing a secured channel during
service discovery.
GISFI TR 09.001 V2.0.0 (2012-09)
This interface provides access to
various management and
administrative services. This includes
user management, device registration,
storage management, IoT application
store, access control, privacy etc.
It enables IoT Service Platform to
communicate with another IoT
Service Platform towards scalability
and data exchange with peer IoT
systems.
GISFI