M2M Architecture Inge Grønbæk, Telenor R&I ETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007
Mar 27, 2015
M2M Architecture
Inge Grønbæk,
Telenor R&IETSI Workshop on RFID and The Internet Of Things, 3rd and 4th December 2007
RFID and The Internet Of Things, ETSI, December 2007 2
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 3
Example Architecture
Service C
Service B
Service A
Business logic
Service provider B
Public Network Service
Platform
Data Repos.
co Business
logic co
Telco / Newco position
Service provider A
Device Network
Telco hub
Mobile or
Fixed
co
co
co
co
co
RFID and The Internet Of Things, ETSI, December 2007 4
Leaf topology – (Ref.FP6 IP “RUNES”)
Telcohub
Service C
Device Network
co
co
co
RFID and The Internet Of Things, ETSI, December 2007 5
Functionality and network elements
HIT Radio GW
HIT GW
RVS RH
ONS DNS Bootstrap
GPRS IP network, e.g. Internet CO-leaf
”Sensors”
Applications& Hosting
IMS Parlay-X
Logging, Rating, Billing
CRM CO CO CO
CO
CO-leaf
”Sensors”
GPRS HIT GW
RVS: Rendezvous ServerRH: Resolution HandlerONS: Object Naming Server
GW: Gateway
RFID and The Internet Of Things, ETSI, December 2007 6
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 IP-address 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 7
HIT gateway protocol stack
IPv4
HIP with security, mobility and multicast
TCP UDP
HTTP
Web services (XML, WSDL, UDDI)
E.g. ETHERNET
Transparent?
Transparent?
Transparent?
CO presentation
E.g. MAC
CO (part) application CO application
Network side Mapping Censor side
RFID and The Internet Of Things, ETSI, December 2007 8
IP header
IPSec (ESP)
Encrypted Header and Transport Payload
Host Identity (HI) is public/private key pair:
Identity definedby holder of private key
Public key usedby others to authenticatecontrol 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 besecurely used instead of HI)
HIT isimplied
by the SPIvalue in
IPsec header
HIP incursno per-packet
overhead
Host Identity Protocol security architecture
RFID and The Internet Of Things, ETSI, December 2007 9
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 10
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 11
GPRS/HIP interworking protocol stack
Relay
L2
L1
IP
GGSN/HIP
UDP
L2
L1
HIP MM GTP-C
L2
L1
HIP MM
RVS
IP IP
Control plane MM
Relay
L2
L1
IP
GGSN/HIP
UDP
L2
L1
GTP-U
L2
L1
HIP IP
CO
Higher layers
HIP IP
User plane
RFID and The Internet Of Things, ETSI, December 2007 12
CO reference points
CO-core GPRS
IP transit, e.g. Internet
CO-leaf
CO-core
CO-leaf
D
C G
F A
A
E
”Sensors”
CO-leaf (e.g. CO)
B
H
RFID and The Internet Of Things, ETSI, December 2007 13
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 14
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).
IPv4
HIP with security, mobility and multicast
TCP UDP
HTTP
Web services (XML, WSDL, UDDI)
RFID and The Internet Of Things, ETSI, December 2007 15
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 16
NGN and IMS capabilities IMS may be used to support the functionality of the CO service-
primitives. 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 17
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 18
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