Transcript M2M architecture - Docbox

M2M Architecture
ETSI Workshop on RFID and The Internet Of
Things, 3rd and 4th December 2007
Inge Grønbæk,
Telenor R&I
Outline
 Introduction
 Ubiquitous topology examples
 Service requirements and API
 Role of API and example service
 Requirements
 Service aggregation and sub-layering
 RESTful approach to API
 Allocation of functionality to each layer
 Architecture





New network elements
Allocation of functionality to network elements
Protocol stacks
Reference points and interfaces
NGN and IMS capabilities
 Implementation
 Alternatives for concrete API
RFID and The Internet Of Things, ETSI, December 2007
2
Example Architecture
Service provider B
Business
logic
Service provider A
Service A
co
Business
logic
co
Service B
co
Device
Network
co
Service C
co
co
Telco
hub
Mobile
or
Fixed
Public
Network
Service
Platform
co
Telco / Newco position
Data
Repos.
RFID and The Internet Of Things, ETSI, December 2007
3
Leaf topology – (Ref.FP6 IP “RUNES”)
Telco
hub
Device
Network
Service C
co
co
co
RFID and The Internet Of Things, ETSI, December 2007
4
Functionality and network elements
”Sensors”
RVS: Rendezvous Server
RH: Resolution Handler
ONS: Object Naming Server
CO-leaf
GW: Gateway
HIT
Radio
GW
Bootstrap
RVS
RH
ONS
DNS
”Sensors”
GPRS
CO
IP network,
e.g. Internet
GPRS
HIT
GW
IMS
Parlay-X
HIT
GW
CO
CO
CO-leaf
CRM
CO
Applications
& Hosting
Logging,
Rating,
Billing
RFID and The Internet Of Things, ETSI, December 2007
5
HIT gateway
 The HIT gateway supports global addressing while allowing IPv4
addresses. (A single public IP-address is assigned to a gateway
potentially controlling large group of COs.)
 The gateway applies the HIT (Host Identity Tag) for addressing and/or
identifying the actual CO.
 The HIT gateway also support localized mobility management as the IPaddress of a CO would only change when the CO moves outside the
control of its current gateway.
 The HIT gateway shall keep track of the location of all COs under its
control.
 Each gateway shall be allocated a coverage area allowing identification of
objects within that area.
 Each gateway shall furthermore keep track of all its physical neighbours to
allow extended area search for COs.
RFID and The Internet Of Things, ETSI, December 2007
6
HIT gateway protocol stack
Network side
Mapping
Censor side
CO application
CO (part) application
Web services (XML, WSDL,
UDDI)
CO presentation
HTTP
Transparent?
TCP
UDP
HIP with security, mobility
and multicast
Transparent?
Transparent?
IPv4
E.g. ETHERNET
E.g. MAC
RFID and The Internet Of Things, ETSI, December 2007
7
Host Identity Protocol security architecture
Host Identity (HI) is public/private key pair:
IP header
Identity defined
by holder of
private key
Public key used
by others
to authenticate
control messages
SHA-1 hash of public key forms a
“Host Identity Tag (HIT)”
- used where 128 bit fields are needed
- self-referential (i.e., HIT can be
securely used instead of HI)
IPSec (ESP)
HIT is
implied
by the SPI
value in
IPsec header
Encrypted
Header and
Transport
Payload
HIP incurs
no per-packet
overhead
RFID and The Internet Of Things, ETSI, December 2007
8
Rendezvous Server (RVS)
 The basic functionality of the Rendezvous Server (RVS) is to offer
mobility- and multicast group anchoring, i.e. Maintenance of the
HIT to address bindings.
 It will also engage in location of COs outside gateway control.
 It may also be engaged in traffic forwarding in cases where
privacy is required.
 Event reporting shall also be handled by the RVS serving the
target CO (i.e. the CO at which events are monitored for
reporting).
 The Registrar and notification functionality is located at the RVS.
RFID and The Internet Of Things, ETSI, December 2007
9
Name resolution (additional to DNS)
 Resolution Handler (RH)
 URI -> (HI -> HIT) -> IP address
-> CO characteristics (e.g. protocol stack support)
 Object Name Server (ONS)
 EPC -> EPC-IS (EPC Information Service offered by manager)
• EPC-DS (EPC Discovery Services ) an application.
RFID and The Internet Of Things, ETSI, December 2007
10
GPRS/HIP interworking protocol stack
Higher
layers
Relay
GTP-C
HIP MM
Relay
HIP MM
HIP
IP
GTP-U
HIP
IP
UDP
UDP
IP
IP
IP
L2
L2
L2
L1
L1
L1
GGSN/HIP
RVS
Control plane MM
IP
L2
L2
L2
L1
L1
L1
GGSN/HIP
CO
User plane
RFID and The Internet Of Things, ETSI, December 2007
11
CO reference points
CO-core
”Sensors”
B
A
E
CO-leaf
(e.g. CO)
IP transit,
e.g. Internet
H
CO-leaf
A
F
C
G
GPRS
D
CO-core
CO-leaf
RFID and The Internet Of Things, ETSI, December 2007
12
Interface at reference point A
 The initial interface and protocol stack at reference point A is
based on the IP protocol as shown in the figure. The choice of
lower layer (i.e. sub IP) protocol is not restricted at the interface.
IPv4 (with Diffserv.)
Sub IP protocol layers
RFID and The Internet Of Things, ETSI, December 2007
13
Interface at reference point B
 The figure depicts the protocol stack at the CO-core to CO-core
NNI. (is considered the best choice to meet the generic CO
requirements in the short timeframe).
Web services (XML, WSDL, UDDI)
HTTP
TCP
UDP
HIP with security, mobility and multicast
IPv4
RFID and The Internet Of Things, ETSI, December 2007
14
Interface at other reference points
 The interface at reference point C equals reference point B.
 The interface at reference point D equals reference point A.
 The interface at reference point E is currently proprietary, but the HIT
gateway architecture defined in this document to be applied for mapping
between the interface at reference point E and the interface at reference
point B (=C).
 The interface at reference point F equals the reference point B.
 The interface at reference point G equals reference point B. HIT based
nodes communicate transparently (e.g. via or helped by the RVS). The
GPRS HIT gateway provides interconnect of the GPRS and CO
architectures allowing native non HIT GPRS nodes to communicate with
HIT COs.
 The interface at reference point H is identical to reference point B/C
except for the radio access.
RFID and The Internet Of Things, ETSI, December 2007
15
NGN and IMS capabilities
 IMS may be used to support the functionality of the CO serviceprimitives.
 The major challenge is to handle small amounts of real-time data
efficient within the session oriented framework of IMS.
 The Use of the SIP MESSAGE method for such data exchange is a
possible solution.
 A better solution would be to offer a general QoS controlled
connectionless service at the network layer, i.e. the IP bearer.
 The session orientation of IMS makes it very suitable for high
volume streaming, but multicast is missing for low volume
transient real-time data.
 The bottom line is that IMS supports high volume streaming very
well, but IMS needs to be upgraded to effectively support the
class of non session oriented applications.
RFID and The Internet Of Things, ETSI, December 2007
16
Alternative concrete API approaches (1)
 Web Services
 Parlay
• CORBA
(too heavy)
 Parlay-X (For IMS service access)
• Based on SOAP
 REST (excluding SOAP envelope)
 J2ME
(Not mature before 2010)
 Native APIs (required for constrained applications)
RFID and The Internet Of Things, ETSI, December 2007
17
Summary of supported functionality
 Ubiquitous (cross domain) support of CO services.
 Name and addressing flexibility, e.g. not limited by IP constraints.
 New services require only additional data definitions and builds on
existing service components accessed via standard API.
 CO service connectivity with UMTS/GPRS.
 Access to OSA Parlay functionality.






Security.
Privacy (in terms of location and identity).
Mobility management (including network mobility).
M:N multicast also for mobile objects.
Presence, location and Notification.
Efficient interfacing of proprietary and/or power constrained
devices.
 Protocol-stack flexibility.
 Topological hierarchy
RFID and The Internet Of Things, ETSI, December 2007
18