We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
Interface to Networks and Devices (I2ND) Architecture R3 - FIWARE Forge Wiki

Interface to Networks and Devices (I2ND) Architecture R3

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Introduction

I2ND defines an enabler space for providing Generic Enablers (GEs) to run an open and standardised network infrastructure. The infrastructure will have to deal with highly sophisticated terminals, as well as with highly sophisticated proxies, on one side, and with the network operator infrastructure on the other side. This latter will be implemented by physical network nodes, which typically are under direct control of an operator, or the node functionality will be virtualised – in this case the I2ND functionality can be accessed by further potential providers, like virtual operators.

Architecture Overview

The I2ND architecture covers four Generic Enablers (GEs). The four GEs have interfaces and APIs according to their underlying technologies:

  • CDI (Connected Device Interface) towards the Connected Devices. These devices include, but are not limited to, mobile terminals, tablets, set top boxes and media phones, and have features such as remote access from a control environment, exposure of own functionality (device status, sensors, etc).
  • CE (Cloud Edge) towards the Cloud Proxies. Cloud Proxies are gateways, which connect and control a set-up of nodes towards the Internet or/and an operator network. The nodes might be either accessible or not accessible from the outside networks.
  • NETIC (NETwork Information and Control) towards Open Networks. Open Networks are following the idea of flow based controlled networks, and can be used for virtualisation of networks.
  • S3C (Service Capability, Connectivity and Control) towards Underlying Networks. The underlying networks are following standards such as Next Generation Networks (NGNs) or Next Generation Mobile Networks (NGMNs). In the case of the S3C specified in I2ND the baseline underlying network is the Evolved Packet Core (EPC) by 3GPP.
The I2ND Global Architecture


Each of the GEs of I2ND has specific interfaces towards Application Developers, Cloud Services, FI-WARE and other Use Case GEs and projects. The respective interfaces are described in the GE sections.

The GE S3C is the central point of the I2ND architecture. I2ND develops an enabling environment which can be used by network operators. Together with NetIC, both GEs will build the environment of an operator, which might even be a virtual operator. S3C can be seen as the GE to run and steer the network infrastructure.

A special role in I2ND is devoted to the interface towards other operators. Since the Future Internet infrastructure will follow the Internet philosophy of a multi domain/end-to-end path through different network operators, it is necessary to interface with other operators. In I2ND the interface description provided by the ETICS project ([1] [2]) is adopted. The interface between NetIC and other operators promotes to the future of network interface virtualisation down to the network layer. This interface might be restricted by the owner of the network infrastructure, thus offering a sub-set of whole interactions.

The interfacing between S3C and CDI provides status and control information exchange of the device and remote control capabilities. A respective interface template is used.

Cloud proxies might be part of an operator infrastructure. Therefore it is necessary to have access to these network nodes through a standardised interface.

More details about the interfacing mechanisms among the GEs in the I2ND chapter are given in the wiki pages describing the respective GE architecture.

Architecture description of GEs

The following pages describe the architecture of the Generic Enablers defined in the I2ND chapter.

Interfaces to other Chapters

Interaction between the I2ND chapter and other chapters within FI-WARE is necessary for realization of a complete Future Internet Core Platform. The I2ND chapter interacts with four other chapters within FI-WARE, in the following the relevant chapters are highlighted.

IoT

In the current specification Device Management interfaces between CDI and IoT GEs are not included. A new type of Device management specifications for M2M applications, OMA LightweightM2M ([3]), has been recently released by OMA-DM group at the end of 2013; due to the recentness of these candidate specifications, they have not been included in the current FI-WARE architecture.

Data

An interaction to exchange information is expected between S3C and Data GEs. In the current specification there is no explicit interface defined between S3C and Data GEs described, since the interface depends on the data to be exchanged and the Data/Context Management GEs to be used for processing. Several Data Broker GEs can be used to publish and subscribe I2ND related network and subscriber data. For instance relevant contextual and metadata information relevant for third party organizations using FI-WARE such as availability, reachability and location of users, applications resources and devices can be provided and processed by Data/Context Management GEs.

Security

The main interaction with Security GEs concerns the Network Identity Management. The interface can connect one of the Security.IdentityManagement GEs with the I2ND.NetworkIdentityManagement. Over this interface, customer profile data from the Customer Database of the Security.IdentityManagement can be retrieved and mapped into SIP signalling for service enhancements as well as different identities towards an application server in a NGN environment. Based on HTTP/REST, the interchanged data can be structured in JSON-format.

References

[1] ETICS Deliverable D4.2: Economics and Technologies for Inter-Carrier Services https://www.ict-etics.eu/fileadmin/documents/publications/deliverables/D4_2_ETICS_architecture_and_functional_entities_high_level_design.pdf

[2] ETICS Deliverable D4.3: Revision of ETICS Architecture and Functional Entities https://bscw.ict-etics.eu/pub/bscw.cgi/d37005/ETICS_D4.3_v1.0.pdf

[3] OMA LightweightM2M v1.0 Specifications http://technical.openmobilealliance.org/Technical/release_program/lightweightM2M_v1_0.aspx

[4] ETICS Website: https://www.ict-etics.eu/

Personal tools
Create a book