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
FI-WARE Interface to Networks and Devices (I2ND) - FIWARE Forge Wiki

FI-WARE Interface to Networks and Devices (I2ND)

From FIWARE Forge Wiki

Jump to: navigation, search

IMPORTANT NOTE: This page is deprecated. Please refer to the most updated description of the FI-WARE Interface to Networks and Devices (I2ND) Architecture

Overview

Contents

The growing number of heterogeneous devices which can be used to access a variety of physical networks, contents, services, and information provided by a broad range of network, application and service providers has clearly created the conditions required for an increasing number of users to be always in touch with what is going on in the world, both for personal and work-related purposes. Driven by mobility, more and more services are consumed on the move. Therefore mobility is to be provided, and a certain Quality of Experience (QoE) and security are expected. Unfortunately, the complexity of the problem, as well as the lack of standardised interfaces and protocols, makes it difficult to easily and seamlessly support such features at the application layer.

Moreover, in the attempt to differentiate the offer, device manufacturers are continuously introducing new and more sophisticated features in their products. Further, to make the scenario even more fragmented, a variety of development paradigms and technologies are available for different types of connected devices. We can broadly define three programming paradigms as reference for developers interested to deploying their applications on connected devices (and not only for them), i.e. the native programming technologies (Java, Objective-C, C, C++, etc.), the interpreted programming technologies (Java, .NET, Python, etc.) and the script programming technologies (HTML, CSS, Javascript, XML, etc.). The difficulties found in the interoperability among applications running on different devices and the portability of applications across devices, both due to lack of standards and existence of fragmented paradigms, are often a big issue in the development of global Internet Applications. FI-WARE will address the definition of Generic Enablers implementing a common and standard Interface to Devices that helps to minimize these limitations.

As a further element to be addressed, in the past communication solutions were mainly developed according to their usage. Typical examples are mobile communication, analogue and digital telephony, and Internet. Each of these technologies had their own platforms, environments, and infrastructures. This resulted to silo platforms within the infrastructures of telecommunication providers. With the fixed-mobile-convergence (FMC) strategy, where mobile and fixed and Internet grew together, it was necessary to build and replace the communication technologies by one specific and unique technology and protocol environments. Driven by the economic benefits (relatively cheap network nodes) and the success of Internet end-systems (such as laptops and desktop computers) the packet based technology had its triumphal procession. The Internet is based on a simple transport stack (TCP/IP). To solve the specific application and usage area challenges, overlays were built. More and more the overlay philosophy enabled the clustering of technologies, service and application management, and the control of networks. The Internet had also the philosophy to push the intelligent of networks to the edge, using transport networks as dumb pipes and developing applications/services “over the top”.

FI-WARE considers the Intelligent Connectivity at the basis of the Future Internet. The Intelligent Connectivity concept will mean connecting applications and application platforms to the network intelligently, leveraging on the full potential of the features of the network, through the definition of Generic Enablers implementing a standard Interface to the Networks. This way, FI-WARE will be capable of exploiting the features of networks offering “smart pipe” functionalities as compare to just be designed to run “over the top”.

The Generic Enablers provided to implement a standardised Interface to Networks and Devices (I2ND), can be used by other FI-WARE elements, such as Cloud Hosting, Internet of Things, etc. They can also be directly used by the applications in multiple Usage Areas.

A fundamental challenge for the implementation of the required interfaces is that the network functionality is typically distributed over different elements potentially implemented internally in different ways (in multi-vendor environments), and that the interfaces have to take into account the constraints of different providers (in multi-network service scenarios) as well as legal and regulatory requirements.

For logical reasons, explanations, and implementation issues, a common reference model is needed. The model should reflect the standard communication understanding as well as future and ongoing activities in the field of packet (Internet) based communication, traffic engineering, and service offering. The control and the management of packet (Internet) based networks should be included as well.

A good reference communication model is an extension of the model from the Telemanagement Forum (TMF) [TMF] – the three Strata Model [StrataModel] from the IPsphere Project [IPsphere] is shown in Figure 63. These strata can be seen as overlays; which is in line with the already mentioned overlay philosophy of the Internet.


Three strata model for communication in an IP driven operator infrastructure


TMF, within the Service-structuring stratum, addresses essential requirement of composition of services across multiple stakeholders and multiple technologies. In (TR158_IPsphere_ R2-0 Arch_Doc), the TM Forum IPsphere Framework (IPSF) is introduced, a framework for service providers to service provider Business-to-Business (B2B) interactions and automated collaboration. This IPSF contains main functionalities for service negotiation (Publishing, composition, fulfilment and assurance) that are key aspects for delivering of network services based on Service Level Agreement.

Remark: In the framework of this activity it is planned to use the existing results from IPsphere/TMF and the related EU-R&D-activities, which are in cooperation with IPsphere/TMF. It is also planned to push new – in the framework of FI-WARE developed – results by help of the partners into the TMF for discussion and to shape new releases.

Therefore, all FI-WARE Generic Enablers aiming at the provisioning of services with agreed QoS (like Generic Enablers in the Cloud Hosting chapter) shall need to take into account that ‘Negotiation’ processes can be put in place with the control stratum of the Networks and Devices infrastructure, using the interfaces being defined in the FI-WARE I2ND chapter. By implementing this negotiation, they will be able to bring a differential value compared to other application platforms merely designed over the top.

In [Cube01] and [Cube02], the authors have extended the Strata Model with three planes: the Data plane, the Control plane, and the Management plane according to Figure 64


600
Three strata model for communication extended by NGN principles


The previous figure depicts in the left the current situation in the Internet. Within domains, different interfaces and protocols are implemented to support the operator in the more or less difficult task to run a network efficiently and to give access to end-customer, third party providers, content providers as well as interconnection to other network service providers. On the right side, this is mapped to the proposed communication model, where:

  • The Packet Handling Stratum represents the communication technology. Typical examples include access networks such as the 3GPP Long Term Evolution (LTE) or Digital Subscriber Lines (DSL), as well as backbone/core technologies like Carrier Grade Ethernet and other optical network technologies.
  • The Control and Policy Stratum is a layer that is responsible for inter-technology issues within operator/network service provider environments. A potential implementation in wireless access networks can be based on the Evolved Packet Core (EPC).
  • The Service Structuring Stratum deals with the end-to-end-service provisioning.

The architecture of communication networks can further be separated into three planes: data plane, control plane, and management plane. For illustration and for simplification the following description uses the “three Strata Model” without explicitly distinguishing their respective separation in the data plane, control, and management plane according to the NGN architecture.


I2ND high-level Architecture

The I2ND chapter will address four different classes of interfaces: connected device, cloud proxy, open networking, and network services. These four functional components directly follow from the four different entities that an interface can refer to: (1) Interfaces to end devices (addressed by connected device), (2) interfaces to gateways (cloud proxy), (3) interfaces to connectivity functions inside the network (open networking), and (4) interfaces to services offered by the network operators (network services).

In each case, the purpose of the interface is both to expose the corresponding network state information to the user of the interface as well as to offer a defined level of control and management (network operation), in order to overcome the limitations of today's network and device interfaces. A control and policy strata/system handles interactions between these different functional components and inter-domain operation.

The four classes of interfaces can be mapped to the Communication Model (without the planes) as depicted in Figure 65


Mapping of the Generic Enablers into the Communication Model


The I2ND chapter addresses the interfaces at the level of different strata. The Service Structuring Stratum includes interfaces towards applications in a wide range of Usage Areas. The chapter will not handle the implementation of the Service Structuring Stratum inside the network. The Packet Handling Stratum in the devices and Cloud proxies, as well as the Policy and Control Stratum in the Cloud Proxies, are well defined and standardised and therefore well established interfaces will be used.

Figure 66 provides a high level view of the Interface to Network and Devices architecture, composed of the following four Generic Enablers:

  • Connected Device Interfacing (CDI): this is the Generic Enabler (GE) providing to FI-WARE and Use Case Project applications the possibility to exploit the device features and capabilities, through the implementation of interfaces and related APIs towards the connected devices. The CDI GE interfaces the FI-WARE applications providing unified APIs for app developers. It also interfaces services offered by other FI-WARE GEs, through the internal interface with the S3C Generic Enabler shown as a dotted line in Figure 66 The interfaces provided by CDI GE will reflect the status and the situation of devices and their connected users. Network context information, location data (generated by network nodes) and subsets of the user profiles will be provided in a open, standardised way towards the executing systems. Current standards and discussions in international initiatives and bodies, in particular GSMA (oneAPI), WAC and W3C, will be taken into account, as well as the evolution of device platforms (e.g. MeeGo, Android). The CDI GE, on one hand, will specify interfaces and APIs according to the standardised frameworks mentioned, and will also further improve them, by contributing to the relevant initiatives with proposals for an evolution, which takes into account the Future Internet requirements emerging from FI-WARE and the Use Case Projects.
  • Cloud Edge (CE): this is the GE in charge of interfacing the Cloud Proxies with the FI-WARE and legacy cloud services. Users own and use more and more complex home networks connecting many consumer electronic devices and broadband home gateways providing more and more advanced functionalities. The interface and interoperability between all these devices is still a challenge, even after years of development of interoperability standards such as UPNP or DLNA. In the future, gateways will be further extended to specifically include cloud functionality, e. g., in the form of “nano data centres” or “advanced home hubs” that support private cloud functions, execution of downloadable applications in virtualised environments, advanced storage, intelligent content distribution, or translation to local IoT-related networks. This means that home gateways have to be able to expose interfaces towards the FI-WARE platform to access cloud proxy features, including the interfaces to access objects and devices connected to the cloud proxy, to manage/access local data and to manage devices. The interfaces provided by the CE GE cover a variety of cloud proxies functionalities: end-device communication, home system management, virtual machine management, protocol adaptation, etc. The CE interfaces are also used internally by the S3C Generic Enabler to control the cloud proxies.
  • Network Information & Control (NetIC): this is the GE providing a homogeneous access to heterogeneous open networking devices. It exposes network status information and it enables a certain level of programmability within the network, e.g., concerning flow processing, routing, addressing, and resource management at flow and circuit level. Such interfaces also enable network virtualisation, i. e., the abstraction of the physical network resources as well as their control by a virtual network provider. A key advantage of open networking is the implementation of tailored network mechanisms (own addressing schemes or protocols, dynamic tunnels, etc.). Also, premium network services can be implemented, e.g., for the interconnection of private and public clouds by dedicated links with guaranteed Quality-of-Service (QoS). Potential users of NetIC interfaces include network service providers or other components of FI-WARE, such as cloud hosting. Network operators, but also virtual network operators and service providers within the constraints defined by contracts with the operators may access, by means of specific FI-WARE services, the open networks to both set control policies and optimally exploit the network capabilities, and also to retrieve information and statistics about network utilization (e.g., a usage area implementing a smart grid application will rent from an operator resources to build its own virtual network, then this usage area will interface directly with NetIC). This GE also offers a set of I2ND internal interfaces to the S3C in order to control the open networks.
  • Service, Capability, Connectivity and Control (S3C): this is the GE providing access to legacy network devices features, capabilities and services. In particular, the aim of this GE is to mitigate the challenges of packet core networks by offering extended interfaces for various service platforms. S3C defines interfaces that are used to control the access to the heterogeneous network infrastructures, and interfaces that provide information from the network management and/or operation support systems, such as auditing data-sets that can be used for billing and charging, or legal interception information that can be used in case of violation of the network environment usage rules. The S3C functional component therefore mainly considers interfaces at service level, whereas the NetIC interface focuses on transport mechanisms. Yet, both functional components may depend on each other, e. g., in case of inter-domain operation, and I2ND will therefore align these interfaces. A central instantiation of the network management is the policy and control system. The targeted policy and control system is a further developed IP Multimedia Subsystem (IMS) and/or Evolved Packet Core (EPC) platform. For inter-connection of network service providers and their domains for example the provisioning of QoS, an inter-carrier sub-enabler will be defined. The enabler will not be accessible directly only through a high level interface for other operators and application developers In addition, it also exposes a set of interfaces to the CE GE that may be used by Cloud Services


Image:General_Architecture_of_I2ND.jpg
General Architecture of Interface to the Network and Devices (I2ND)


The four I2ND Generic Enablers build the interface between the legacy domain (Devices, Open networks, Legacy network services and Cloud proxies) and the rest of the FI-WARE domain (applications, services and clouds) as illustrated in Figure 66. The dashed lines shown in Figure 66 represent the internal (within the I2ND scope) interfaces; the dotted lines represent the interactions between the I2ND Generic Enablers and the underlying legacy domain elements; the solid lines represent the interfaces between the I2ND Generic Enablers and the rest of the FI-WARE platform. The S3C GE is the central component, which interfaces all other three GEs (CDI, CE, and NetIC) to one common I2ND platform.

The interfaces provided externally (solid lines) by the I2ND Generic Enablers are used by:

  • Applications: applications running on connected devices and interacting with the end user by means of proper graphic user interface. Applications make use of device features (i.e. sensors, profile information, stored data, etc.) as well as features or information accessible remotely (i.e. network services or cloud services) by means of the connectivity device capabilities;
  • FI-WARE Services: business-to-business or business-to-consumer services provided by the FI-WARE platform that make use of the I2ND interfaces to get access to the underlying features, functionalities and information. In particular, the FI-WARE services are provided by other FI-WARE Generic Enablers that interact with the I2ND Generic Enablers;
  • Cloud Services: they include both legacy cloud services as well as dedicated cloud services provided by the FI-WARE platform.

Generic Enablers

Connected Devices Interfacing (CDI)

Target Usage

The Connected Devices Interface (CDI) Generic Enabler (GE) will provide, to FI-WARE chapters and Use Case Projects applications and services, the means to detect and to optimally exploit capabilities and aspects about the status of devices, through the implementation of interfaces and application program interfaces (APIs) towards device features.

More specifically (see Figure 67) the CDI is a GE located in the connected device with the aim to provide to the network services and the developer’s applications common APIs to exploit the device capabilities, resources, contextual information and contents.


Connected Devices Interfacing (CDI) target usage


CDI will expose proper APIs to control all the capabilities and to get the related information of the connected device, including battery power, network status, location systems, quality of service, media capabilities, phone available features and sensors, profile information, status information and remote management facilities. As shown in Figure 67, as an example, the CDI can be exploited by the applications developers thanks to a common set of APIs exposed by the CDI allowing each app to get access to the device capabilities independently from the handset manufacturer, the OS vendor or the specific software embedded into the device. Also, the network operator can exploit the CDI APIs to remotely manage the parameters used by the device for establishing the connectivity to the network such as policies for access network discovery and selection, attachment and connectivity policies as well as management of the Quality of Service control and in-device routing policies in order to enable the mobile device to best match and react on its own to contextual situation (e.g. coexistence of WiFi and 3G coverage, usage of another connection over another access network for better QoS etc.) The result is that end user can enjoy his favourite contents, anywhere and anytime, using his preferred apps across heterogeneous networks and connected devices.

This means that same applications and network services can be used consistently over dissimilar connected devices, if they are equipped with the CDI. Moreover, the apps provided by FI-WARE application developers will be able to exploit the capabilities and features the specific device platforms provide. This allows cloud hosted application services for example, to render their interfaces to make best use of individual devices and their relative connectivity. To realise this, the CDI GE will offer a uniform and standardized access and easy portability across multiple device classes of the features mentioned.

Here the term “connected devices” refers to a broad range of networked electronic components, including Handsets (cellular phones, smartphones), Tablets, Media phones, Smart TVs, Set-Top-Boxes, In-Vehicle Infotainment, Information kiosks, each being able to connect to a communication network.

To look at this in terms of practical benefits, a hypothetical scenario may involve a cloud-hosted media rich service which is accessed by many consumers across fixed or mobile terminal devices. The service provider will want to ensure that all consumers get the best possible experience, as a function of their connectivity, and the display and processing power (noting remaining battery power) of their device. By programmatically enabling the service with the ability to detect relevant details of the client device and its connectivity, decisions can be made at run-time in terms of selecting different levels of media ‘richness’ including sizing, resolution, 2d or 3d, etc., for individual users

Another example might relate to location-based services, where the location of the device (shopping mall), might be a useful indication of the customer’s intention, and suggest useful sidebar links in the form of advertising offers. Yet another might be the availability of triaxial accelerometers on the device and a user profile indicating a preference for this as a user input modality, which could be comprehended directly into the rendered UI configuration of a service.

GE description

Overview

The CDI GE is in charge of addressing a broad set of connected devices, not only the mobile ones, each adopting specific technology solutions in terms of hardware, software, middleware and runtime platforms, in particular concerning the development of applications.

A first challenge to be faced by the CDI GE is to provide homogeneous interfaces for application development. It is recognised that the extreme fragmentation of platforms adopted for connected devices, including a variety of different OSes and programming languages, is introducing several troubles to develop once for all the application and make it run on all such devices. As introduced in Section 3.1, different programming paradigms can be considered, which are exemplified in Figure 68. One step towards solution to fragmentation is represented by the adoption of middleware technologies (Java is one of the most relevant in this context), although not equally well supported by the majority of connected device platforms. Other emerging solutions rely on web based technologies available on most terminals. This trend seems to favour the development of applications which can run on web browsers or runtime engines.


Applications programming paradigms


To cope with such heterogeneity of available but not winning solutions to fragmentation, the CDI GE tries to find a convergence point at least on the interfaces. The basic assumption for the definition of CDI interfaces is that they will be defined as much independent as possible from specific technology implementation and programming paradigm, thus creating a sort of layer on top of the technology dependent layer(s) of the devices that communicates with the applications and the network service by means of a interface layer as shown in Figure 69


CDI virtualisation features of the connected device


As shown in the figure, the CDI GE interfaces the FI-WARE services and applications with the connected device capabilities, such as: embedded sensors (cameras, GPS, accelerometer, compass, etc.), connectivity (short range radio, radio interfaces, wifi, bluetooth, streaming, etc.), data (PIM, user profile, memory, etc.), management, graphics and so on. In order to cope with already available solutions, the CDI GE decouples a technology dependent adaptation layer from the technology independent interface layer. While the CDI GE interfaces are common for FI-WARE services and applications, their implementation and deployment on the connected device depends on the specific adaptation layer used to support the interface layer.

The adaptation layer can be implemented, as an example, as a stand-alone application (e.g. Java or C/C++), as a stand-alone run-time environment (e.g. OSGi), or as a web based run-time environment (e.g. WAC). Whatever solution is chosen for the adaptation layer it interfaces the connected device capabilities exploiting the primitives offered by the operating system. Thus the adaptation layer is technology dependent.

Instead, the interface layer relies exclusively on the required interfaces to support the FI-WARE chapters and Use Case Projects applications and services. The interface layer will not be defined from scratch. It will inherit the experience gained from other initiatives (such as WAC and W3C) and most of the interfaces will be re-used. However a gap analysis performed against the FI-WARE chapters and Use Case Projects requirements will lead to the identification of missing interfaces that will be formalised in the interface layer.

High level architecture

The high level architecture of the CDI GE derives from the convergence of current trends on widget execution environments architectures. An example of these standard, reference architectures is depicted below:


Reference execution environment for applications (widgets)


The architecture of the CDI GE, as anticipated earlier, is composed of two main elements: the interface layer and the adaptation layer (Figure 71). The first element, namely the Connected Device Interfacing Layer (CDIL), is in charge to provide to the higher layers the CDIL-NET and CDIL-APP interfaces. These interfaces can be further decomposed into a number of elementary interfaces, each exposing the specific APIs for a given feature of the connected device. The Platform Adaptation Layer (PAL) deals with interaction towards the specific platform, in order to adapt to the different architectures, programming paradigms, OSes, etc. This element can optionally expose the technology independent FI-WARE CDIL-PAL interfaces or directly interact with the Connected Device Interfacing Layer with proprietary, technology or language or OS dependent APIs.


Layered architecture of CDI Generic Enabler


The Connected Device Interface Layer (CDIL) element exposes a set of interfaces providing open access to several features of connected devices. As shown in Figure 72 the CDIL exposes a set of interfaces to the apps created by the application developers (CDIL-APP), as well as to the network services owned by the network operators (CDIL-NET). On the other hand, the CDIL exposes a set of interfaces to interact with the underlying connected device capabilities, features, information, etc. (CDIL-PAL). It is worth to note that all the CDIL set of interfaces are totally technology independent. They do not rely on specific technology requirements such as hardware constraints, operating system limitations, programming language syntax and semantic or whatever. The CDIL interfaces are specified using a formal language (UML, IDL, etc.) and any implementation which is compliant with that specifications, can be part of the FI-WARE platform, execute FI-WARE apps and exploit in a transparent way the FI-WARE network services as well as the device capabilities.


Overview of the CDI interfaces


In order to cope with the fragmentation of available technologies, networks, devices, sensors, applications, it is necessary to introduce well defined standardized interfaces among well-defined layers. This layer-isolation paradigm has assured some convergence especially in the telecommunication field. The TCP/IP represent at the moment a good point of convergence. But TCP/IP is only the basis on which applications, services, contents and information rely to be provided to the end users. End users enjoy their applications over dissimilar equipment, using heterogeneous operating systems, software and runtime platform. To limit this fragmentation, it is MANDATORY for the CDI GE to define proper CDIL-NET and CDIL-APP interfaces specifying their syntax, pre and post conditions, exceptions, semantics, implementation details, etc.. While the CDIL-NET and CDIL-APP interfaces are mandatory, is it not the same as for the CDIL-PAL. Indeed while it is mandatory to solve fragmentation at least at the top of the layered structure, just below the layer where application and network services run, it is not necessary to solve the fragmentation below. Thus CDIL aims to provide a mandatory set of interfaces usable by app developer and network operators to develop application and network services independently from the end user equipment. In order to provide the CDIL-NET and CDIL-APP interfaces the CDI must interact with the underlying hardware, software and middleware capabilities offered by the connected device.

The CDIL can optionally rely on proper CDIL-PAL interfaces in order to interact with the connected device capabilities by means of an intermediate Platform Adaptation Layer (PAL) that virtualizes the heterogeneous device hardware and software capabilities into homogeneous, syntactically and semantically specified interfaces. If the CDI adopts the CDIL-PAL interfaces is it fully technology independent. But a CDI implementation can also get direct access to the connected device capabilities, thus becoming technology dependent. It means that if a new hardware, software or middleware version on which the CDI is relying on is released, the whole CDI must be updated as well. Instead, in case the CDI adopts the CDIL-PAL interfaces, only the Platform Adaptation Layer must be updated, while the CDIL and its interfaces remains unaltered.

The FI-WARE decision to make the CDIL-NET and CDIL-APP interfaces MANDATORY has been done to solve the fragmentation problem, adopting an user-centric paradigm (where the user is intended the network service provider or the app developer). On the other hand, the decision to make the CDIL-PAL interfaces OPTIONAL, is to give the maximum freedom to the CDIL implementation and to guarantee at the same time the maximum backward compatibility with the already existent initiatives and standards (i.e. WAC) that do not rely necessary on a two layers (CDIL + PAL) architecture.

The architecture shown in Figure 73 is a functional view of what will be practically exposed to the users of the CDI GE, i.e. the FI-WARE network services and applications. The internal developments might be slightly different from the schematic view of Figure 73. Nonetheless, the main impact on the users will be hidden by the clear and open definition of the interfaces and related APIs on top of the CDI GE.

Clearly not all the interfaces to the device features are currently defined: the set of interfaces already identified in Figure 73 as interfaces which can enrich the application development of FI-WARE users comes from the identified needs by the project partners. However a deeper gap analysis of currently available interfaces and APIs against the required ones will be performed. What is found missing will be added in response to the requirements expressed by the Use Case Projects, and by the other sources of requirements the FI-WARE team is considering, and will refine the CDI GE architecture.

As a matter of fact, most device interfaces have been already considered by different standardisation initiatives (OMA, W3C, WAC, etc). The aim pursued in the definition of CDI GE is to operate in a sort of ‘closed loop’ taking as foundation of its architecture the wealth of information and specifications (even reference implementations) produced by such initiatives, adopting them wherever already well consolidated, encouraging their adoption through the FI-WARE Instances, extending those portions and features which are at the moment missing and, finally, promoting and supporting their inclusion in the standards evolution.. In this way, the CDI GE will be able to offer enhanced specifications to connected device features, that can be more complete and valuable to programmers, thus supporting successfully the wave of application developments of the Future Internet.


Functional architecture CDI Generic Enabler


List of functionalities

A number of functionalities will be provided by the CDI GE through the CDIL interfaces to the upper layers. A preliminary list includes:

  • Communication Services
    • Network Status: of the device is represented by static information on the device itself (e.g. the number of device interfaces available), dynamic information on the connectivity (e.g. connected to 3G network) as well as the information received from the network operator on the possible available resources in the vicinity of the mobile device (e.g. a specific WiFi access in the vicinity can be used if more resources are required by the applications). This information has to be gathered from the network and from the device information and then presented in a unique form to the applications on the mobile device. Applications may need a connection towards the Internet, or towards other devices, in order to exchange information or to retrieve data or contents. Usually, devices are provided with several different communication interfaces (e.g., 3G, Wi-Fi, Bluetooth, etc.) and it is important to expose to the applications and services the communication features of the device, together with relevant information regarding the status of the connection and its availability.
    • Quality of Service/Quality of Experience (QoE) is a fundamental task for the IT Industry and it will play even more important role in the Future Internet. Quality of Service is an important feature for measure QoE but it is not the only one. The implementation of passive (like users' habits or zapping) and active (MOS, OneClick, etc.) estimations for measure QoE is a determinant step for refine it. Combining these elements will provide a better service for the end-users while the operators will be more reliable. A joint QoS/QoE approach must be faced off by the CDI GE, providing a feasible set of dedicated APIs to measure, at the end point, the QoS as well as the QoS perceived by the end user, thus the QoE.
  • Device Services
    • Sensors are today part of the devices and are important as they provide a set of information that can be used by applications and services. As an example, the GPS receiver provides location information that can be used for location oriented application and services. Other examples of sensors usually integrated with today’s devices are the accelerometer and the camera, but the interface will not limit the exposure of sensors, as it will be designed in a modular way so that it will be possible to expose also other sensors whenever available.
    • Device Features (information about the device: battery, physical device properties, CPU, etc?) FI-Ware and hosted application services will need to determine the features, capabilities and status of the connected device, in order to optimise the experience of the devices user. I/O status and options, physical device properties (touch UI, T9/Qwerty keyboard, stylus support, mouse, rollball, jog wheel), local computing and memory and remaining battery power, accessed via the CDIL API can be used to make run-time decisions on service rendering. Emerging features such as hardware enabled authentication or accelerated encryption can make end-to-end security less burdensome on the end user.
    • Inclusion of Short Range Radio (or proximity) and contactless technologies in the CDI interfaces eases the interaction of connected devices with IoT, enabling the interconnection and exchange of information with surrounding things and nodes. The radio capabilities should be able to manage virtually any kind of possible technologies. This is however a challenging aspect, and needs a thorough exploration during the interface definition phase, to include at least the most common technologies and those recently emerging (e.g. Bluetooth Low Energy, ZigBee, NFC).
    • Privacy and security aspects will be faced in conjunction with other chapters of FI-WARE (i.e. Security one), and will be in line with the approach followed by other initiatives (e.g. WAC includes mechanisms to securely manage how applications access device features, along with supporting privacy policies as defined by W3C) and other standardization bodies. This interface will thus deal with the secure access to device features and user’s data, as well as to assure the origin and the integrity of the application and service running on the device.
    • Remote Management aspects will be considered as to empower the mobile device with information on the vicinity network status including access networks discovery information, inter-system mobility and routing policies enabling the selection and the forwarding of data traffic from the mobile device to the most appropriate access network based on the connectivity requirements of the various applications on the mobile device and according to the indications of the network providers.
  • Personal/Data Services
    • User Profile (Identity, Authentication, etc) information is fundamental to provide advanced user-aware services, it is hence necessary to correctly and safely develop a functionality to identify the user of the device. This is a functionality which requires a strong cooperation with the general security aspects provided by the FI-WARE developments (see Security chapter).
    • Access to Personal Information Management (PIM) provides a functionality to access, add, remove or update information there contained. Elements of PIM include the Calendar (collection of events described in specific formats, according to standards definitions like e.g. RFC 5545) , Contacts (information about a person, including e.g. phone numbers, email addresses, etc) collected into an Address Book and Tasks (a list of items to be done/completed, each described e.g. with a priority, deadline, etc).
    • Access to Local Data of a device will be ensured by this interfacing functionality. This will enable the application developers to get access to and manage e.g. pictures, videos, data files, applications, etc stored on the device. One particular aspect to be carefully evaluated is to limit the access strictly to specified data, making sure no other portions of local data will be affected in any way.
    • Messaging capabilities like sending messages through different technologies (SMS, MMS, Email, etc) are among the most typical device capabilities which can be exploited by an application, therefore corresponding APIs are necessary to satisfy such requirements.
  • Media Services
    • Graphics rendering rich media and graphically oriented application services will need to be both interoperable (through scaling) with a broad range of devices, but also to make the best use of facilities on the more advanced devices. Determining the capabilities of different device classes at run-time enables the most optimal rendering for the end-user. The following set of graphical properties will be detected by the CDI:
      • 3D Hardware support (WebGL, OpenGL ES etc)
      • 3D Visual Display (e.g. LG OPtimus 3D P920)
      • Physical Graphical Properties (Screen resolution, colour depth and DPI)
      • HD Out support (e.g. Nokia N8)
      • Screen rotation support
    • Streaming Features (transcoding capabilities, etc) similar to the Graphics Rendering situation, the presence of onboard accelerators or specific codecs can signal to a hosted service that a particular device class is capable of receiving a richer format of graphical or other data. Such a decision would need to comprehend availability and cost of the necessary bandwidth also. The two key run time device capabilties considered here are:
      • Video Codec Support (e.g. Quick Time, MP4, DivX, XCiVD, WMV, H.264, H263 etc)
      • Connection type and connection speed (Edge, 3G, HSDPA, LTE, WiFi, WiMAX etc)

Critical product attributes

  • Consistent access to device capabilities and context from both hosted and native running services regardless of device class or middleware/OS, through a simple API layer.
  • API layer to be readily extensible to accommodate future device classes and software stacks, resulting in significant efficiency, scalability and flexibility benefits for service providers and application developers, and expanded choice and optimal Quality of Experience for service consumers


Cloud Edge

Target Usage

The concept of Cloud Proxy has been introduced in the “Cloud Hosting” Chapter. We just remind here the concept of cloud proxy and a few associated illustrative use cases.

The concept of cloud proxy comes from the assessment that, despite the apparent inexhaustible computing or storage resources offered by the cloud concept, the link between the end-user and the cloud remains unique, providing a relative low bandwidth (compared to the internal home network bandwidth, in particular). The idea consists in using an intermediate entity, called cloud proxy, located in the home network and provided with computing and storage capabilities. The cloud proxy can therefore take benefit of the high speed connection with each device of the home network and is in a position to act as a Cloud agent closer to end devices.

To illustrate this concept, we also described some use cases in the Cloud Hosting chapter. One, from the cloud to the user, consists in pushing part of a VOD catalogue‘s content in the cloud proxy (including movies trailers for instance). The purpose is to accelerate the browsing of the database which may be considered as a key element of the VOD application attractiveness.

Another use case, from user to cloud this time, consists in, when uploading data into the cloud, to first upload it in the intermediate storage offered by the cloud proxy. Time required to upload data directly in the cloud may be relatively long, while relatively short in the cloud proxy (hours versus minutes for the same amount of data). Using the intermediate storage of the cloud proxy makes possible for the user to leave the home network after the few minutes required for the local upload, while the cloud proxy shall then be in charge to upload data in the cloud as a background task.

Lastly, the possible support in the cloud proxy of gaming acceleration features is also considered.

The following figure illustrates the concept of cloud proxy.


Image:Cloud_proxy_concept.jpg
Cloud Proxy concept


The IaaS Cloud-edge Resource Management GE defined in the Cloud Hosting chapter comprises those functions that enable to allocate virtual computing, storage and communication resources in cloud proxies. However, FI-WARE will not only define and develop the software linked to the IaaS Cloud-edge Resource Management GE but also software linked to middleware technologies and common facility libraries that will be used in VM images to be deployed in cloud proxies. These middleware technologies and common facility libraries are defined and developed with the I2ND chapter and described in the following section in more detail.

GE description

We give here a high level description of the different functional modules and associated interfaces of the cloud proxy, as represented in Figure 75

End-device communication

End-devices do implement various communication protocols. Consumer Electronic devices may preferably use UPNP/DLNA protocols, while PCs may use NFS or SMB-CIFS depending on their Operating System (Linux/Windows). Lastly some devices like iPhone may require a dedicate software for communication as far as they do not allow a direct communication with the file system level.

The end-device communication module is in charge of implementing ad-hoc protocols and software in order to ensure an optimized data exchange between end-devices and the cloud proxy. Exact list of used protocols has to be precised.

Home system management

UPNP is a zero-configuration protocol, requiring no user manipulation to establish the connection between two devices. This is not the case for SMB or NFS and many other protocols which the end-device abstraction layer may implement. In order to avoid to the user complex manipulations requiring specific skills, user manipulation required by the various communication protocols shall be automated. This is the first task of the Home system management module.

This module shall also be in charge of creating ad-hoc storage spaces on the end-devices as well as on the cloud proxy storage capabilities, and possibly perform various monitoring task on these devices. It shall eventually report to the applications the resources available in the home environment.

The home network management module will be in contact with other modules of the cloud proxy, in particular the Outside communication module and the end-device communication module. APIs between these modules shall be defined. Exact content of these APIs have to be detailed.

Outside communication module

We just mentioned that the Home system organisation module may report information to applications regarding resources available in the home environment. Exchanges with the Cloud may also concern end-devices or the permanent storage module via the end-device communication module, when a cloud application may download data in the home system for instance.

Outside communication may also concern inter-home system communication. In case of distributed application, cloud proxies may directly interact together.

A set of APIs shall be defined, comprising API to the home system organisation module, basically for monitoring or resource description, and API to end-devices and permanent storage, basically for data exchange. The APIs may include the Connected Device Interfacing Layer (CDIL) as defined for the CDI GE. Exact content of theses APIs has to be precised.

Virtual machines management

Cloud application developers may wish to download and execute piece of software in the cloud proxy. For the sake of security (both in term of insulation of data and software execution) and flexibility (installation of a service close to the user), the cloud proxy may support the deployment of Virtual Machines (VMs). The detailed definition of this module can be found in, the FI-WARE chapter devoted to Cloud Hosting. We however mention it here, in order to provide a complete picture of components running on the cloud proxy.

Protocol adaptation

The “outside communication”, “end device communication” and “device management” blocks include a “protocol adaptation” subfunction. This subfunction can translate various protocols to an unified internal vision that is much easy to manipulate, it can also give the cloud proxy the opportunity to embed protocols inside protocols (for example, do some tunnelling). It must be also noticed that in some cases, this “protocol adaptation” can act transparently, even for non-standard protocols. For example, a virtual machine deployed on the cloud proxy could implement a iTunes-compatible module and could transparently communicate with an end-device such as an Apple product (iPad, iPhone …). Another example is the implementation of the “Internet of things” concepts inside a virtual machine that could include protocol / language interfaces to non-standard home-automation devices.


Image:Cloud_proxy_main_functional_modules_and_APIs.jpg
Cloud proxy main functional modules and APIs


Summary of Interfaces

The set of interfaces related to the CE GE is identified by the numbers in Figure 75. We can broadly divide the interfaces in internal (i.e. inside the Cloud Proxy GE and not exposed to outside entities) and external (i.e accessible by outside entities). Internal interfaces can further be related to Cloud Hosting chapter implementation or shared between that chapter and I2ND. The former are listed here for the sake of uniformity, but will be taken care of in Cloud Hosting chapter, the latter will be part of the CE GE. Here is a short description of the functionality they implement:

  1. (external): interface between the applications hosted in the cloud proxy and external applications. These interfaces depend on the application and cannot be standardized. They are application-dependent, for example, a specific application can be architectured in such a way it is executed partly in the cloud and partly inside the cloud proxy, the interface between these 2 parts depends on the application architecture itself. The cloud proxy provides the basic communication protocols to implement this API.
  2. (external): interface between external applications and the cloud proxy. All the communications between external applications and the cloud proxy itself (except for the VM-related and specific communications) are transported through this interface. This API will provide ways for the cloud-based application to communicate with the management features of the cloud proxy and will support transparent or adapted communications to the end devices.
  3. (internal): communication with other cloud proxies. A potential extension allowing applications running on different proxies to communicate using optimized protocols and also enabling multiple cloud proxies mutualising their resources in order to support Cloud Hosting functions.
  4. (internal): interface between the VMs and the VM-management entity. This API allows the cloud-based application and/or the cloud proxy itself to interact and to manage the VMs (life cycle management (load, unload, launch, kill and get/set status of the VMs).
  5. (internal): interface between the cloud proxy management and the VM management entities. Transport of the life cycle management controls to/from the VMs.
  6. (internal): interface between the outside communication entity and the management. Transports the various management / control / status coming from externa applications or the Cloud Hosting functions linked to VM management.
  7. (internal): interface between the inside communication entity and the management. Same as 6. Allows local devices to have interaction with the management entity.
  8. (internal): communication with the local devices. This interface is device-dependant (ie: an iPod will not interact the same way a uPnP/Dlna device will). Support of standard protocols will be the 1st priority, especially uPnP/Dlna
  9. (internal): interface to the local storage. This interface will give access to permanent local storage. Available APIs (VFS, NFS, FTP …) will be used
  10. (internal): interface between outside and inside worlds. This interface will transport data and controls between external applications and the local devices (main channel). The protocol adaptations will allow protocol / language transformations as well as possible tunnelling if required.


Critical product attributes

  • Cloud proxy as evolution of the home hub, able to federate the connected devices and expose functionalities to support a large variety of service bundles
  • API layer provided by the Cloud proxy to allow the cloud-based applications to interface properly and easily with devices associated to the home environment and manage/access to local data.


Network Information and Control (NetIC)

Target usage

The Network Information and Control (NetIC) Generic Enabler will provide to FI-WARE chapters as well as usage area applications and services the means to optimally exploit the network capabilities, by means of the implementation of an interfaces and APIs towards networking elements. NetIC will both expose related network state information to the user of the interface as well as offer a defined level of control and management of the network.

The beneficiaries of the interfaces include, among others, content providers, cloud hosting providers, context providers/brokers, and (virtual) network providers/operators, which need to have information about the network between them and their clients and which might want to set up flows/virtual networks between them and their clients and may want to control such flows/virtual networks in order to respect pre-defined Service Level Agreements (SLAs), for example in terms of provided Quality of Service (QoS). There are several use cases for the NetIC Generic Enabler, for example the following:

  • A cloud hosting provider has a couple of data center locations. In order to distribute the allocation of VMs and applications to the various locations, the cloud hosting provider should know about the characteristics of the paths between the locations (delay, available capacity). To get this information, the cloud hosting provider can request via NetIC from the network provider (regularly or per scheduling event) the characteristics of the paths between his data centers. NetIC will provide the requested information by a corresponding interface. In addition, when dealing with migration of VMs and applications across data centers, the cloud hosting provider may request to setup temporal virtual private connections with a certain quality of service being guaranteed during the time of migration.
  • To deliver a service to a client, a service provider may need a certain minimum link quality, e. g., for a high-definition live video streaming service. If the client is willing to pay for this, the service provider will request via NetIC from the network provider the setup of a virtual connection with certain quality characteristics between the server and the client. NetIC will do so if capacity is available.
  • A network service provider wants to implement new business models based on the "pay-as-you-go" paradigm, setting up a specialized service for a group of clients. The specialized service is built orchestrating the network resources dynamically. For this he needs a virtual network (optical or packet based) connecting some servers, network elements and the involved clients, potentially running customized protocols. The service provider can request via NetIC from the network provider to setup a virtual network between the involved endpoints, possibly also with some specified constraints (quality characteristics, isolation against other virtual networks, energy efficiency metrics)
  • A service provider wants to set up a specialized service for a group of clients. For this he needs a virtual network connecting some servers and the involved clients, potentially running customized protocols. The service provider can request via NetIC from the network provider to setup a virtual network between the involved endpoints, possibly also with some specified quality characteristics and isolation against other virtual networks.
  • A cellular service provider wants to run its business on top of a virtual network which is able to “breathe” (to be re-configured as demand changes) since load in idle and busy hours differ significantly. Benefits are reduced expenses (CAPEX turned into pay-per-use OPEX), reduction of energy consumption and management flexibility. Today mobile traffic is mapped into static MPLS tunnels, and the infrastructure providing these tunnels are owned by the cellular service provider, too.

A fundamental challenge for the implementation of NetIC is that the network functionality is typically distributed over different elements potentially implemented internally in different ways (in multi-vendor environments), and that the interfaces have to take into account the constraints of different providers (in multi-network service scenarios) as well as legal and regulatory requirements. This problem has been solved in the past by different standardized control plane solutions. This readily available functionality could be re-used by NetIC in order to provide a smooth evolution path rather than a disruptive revolution. NetIC instances may be deployed by the different involved parties (e.g. virtual network providers/creators, and virtual network operators/users running a business on top). As a consequence, several instances of NetIC with different scopes may have to work together to deal with a request from e.g. a service provider or an application. Each might cover a different part of the network, for instance in horizontal direction (i.e., type of access) or in vertical direction (i.e., ownership, virtual network).

GE description

NetIC will implement interfaces (potentially split into several sub interfaces in later phases of definition) that provide open access to network status and forwarding functions inside the network (see Figure 76). NetIC will provide an abstraction of the physical network resources, as well as the capability to control them (up to certain limitations given by the physical resources’ owner and operator), opening the way to the utilization of the same network infrastructure by different (even virtual) network providers. Within these limitations, a key advantage of open networking is the possibility for each different network operator to implement its tailored network mechanisms even relying on the same common network infrastructure (own addressing schemes or protocols, dynamic tunnels, etc.). Also, premium network services (in respect to virtual network providers) can be implemented, e. g., for the interconnection of private and public clouds by dedicated links with guaranteed Quality of Service (QoS). The NetIC GE provides an interface for dynamically controlling network QoS parameters inside one administrative domain. The interdomain provisioning of QoS guarantees will likely have to use the API exposed by the S3C GE, since it requires authentication, authorization, accounting, and SLA conformance checks.

On the one hand, NetIC will provide access to network status information. Network status information will be used by the users of the interface in order to both collect statistics regarding the utilization of the network and to acquire near real-time information about the status of the network. As for example, typical network status information of interest for the users may be related to the network topology, interface status, and end-to-end path performance in terms of delay, jitter, packet loss, available bandwidth, etc.

The capability to acquire information from the network will enable service providers or applications to either scale their services to the effective conditions in the network to deliver optimum Quality of Experience (QoE) or to select the best suited access point for a certain service. In particular, resource management algorithms as well as other optimization algorithms (e.g. algorithms related to mobility management and handover optimization) will benefit from near real-time input information describing the status of the network. The information will be consolidated in the abstraction layer, where the network operator will bundle the information to forward the respective parameters to the usage area specific Enabler platforms and the different core-platform entities.

On the other hand, NetIC will provide access to the forwarding functions of the network nodes. The advantage of having this is twofold. As an immediate result, the capability offered by NetIC to have a direct and controlled access to nodes’ forwarding functions will enable a certain level of programmability within the network, fostering the Software Defined Networking (SDN) paradigm. According to the SDN paradigm, the user of the interface can develop software application to automatically control and manage the network on the basis of its rules and policies, e.g. flow processing, routing, and addressing. Furthermore, there can be access to the network resource management functions. At the same time, NetIC will also provide the mean to enable network virtualisation to open a controlled way for virtual network provider operations. Figure 76 shows the main NetIC functions and APIs of NetIC.


Image:Main_NetIC_functions_and_APIs.jpg
Main NetIC functions and APIs


The NetIC Generic Enabler is expected to provide access to the following functions:

  • Interface Control: This function will provide information about the status of a network element interface. Callers may also be able to change selected parameters. An example would be interface activation or deactivation.
  • Topology: This function will provide abstract information about the nodes, edges, and how they are interconnected. Furthermore it may allow the modification of network topology. An example for the latter case would be the setup of a virtual network.
  • Path Statistics: This function will allow querying the properties of an end-to-end path. An example query function would be an estimation of the available bandwidth on a path, or its packet end-to-end delay.
  • Path Control: This function will provide mechanisms to change the current status of a path. The realization of this function as well as its actual scope of operation will be technology dependent due to, e.g., the different realization of packet-oriented and circuit-switched networks. It will affect the setup, modification, and teardown of paths. An example control function would be the definition of a customized routing scheme via the OpenFlow interface. This supports implementation of QoS by isolation of paths (IntServ).
  • Traffic Statistics: Various types of information about the network usage may be of interest. This function will provide access to such statistics and potentially a control over the monitoring process.
  • Traffic Control: This function will allow influencing, e.g., the handling of different traffic types in the network (e.g. priorization of traffic according to DiffServ). This enables differentiated provisioning of QoS.

There are further relevant network functions that might be of interest to be exposed via NetIC API, and further analysis is required whether corresponding interfaces will be needed. For instance, address resolution could be a potential use case to find out whether a given address is present in a network.

Depending of the network, the types of nodes, and policies, only a subset of these functions may be available to a user of the NetIC interface. Therefore, the NetIC generic enabler will also provide a mechanism that will advertise the actually supported features.

The challenge for providing network status information is to find a good trade-off between accuracy, timeliness, and overhead. Providing accurate information and a global insight of the network situation may require extensive continuous measurements. Furthermore, data may be unreliable, incomplete, inconsistent, or misleading, or not even be available due to operator policies (inter-domain topology hiding paradigm). In this respect, NetIC has to address several open issues in order to provide to its users the information they really may need with an adequate level of accuracy. Several techniques to obtain network measurements and status information will be considered, spanning from active techniques to passive approaches.

The monitoring process regarding physical resources consists of gathering metrics about the state of the resources available on each network element that is part of the monitored infrastructure. This is performed by a monitoring agent installed on each element, which will send the gathered data to a collector for processing and persistence.

The challenge for providing some means for network control is that such a generic interface should be technology and implementation independent as far as possible. Specifically, it should support packet switching as well as circuit switching, e. g., in optical networks. This is challenging since networking technologies differ in the granularity of capacity that can be allocated. There are existing and emerging standards in that domain, such as General Switch Management Protocol (GSMP) or the Forwarding and Control Element Separation (ForCES) standardized in the Internet Engineering Task Force (IETF). Another interface is OpenFlow, which is driven by the Open Networking Forum (ONF). But all those solutions are still limited to specific networking environments and they offer limited control and management capabilities. They also have limitations concerning scalability and flexibility, and they are still not well integrated into cloud management solutions. In this respect, NetIC aim is to define a proper interface to enable network control, which will be based on the mentioned available protocols and will maybe extend them in order to cope with all the requirements coming both from other FI-WARE GEs and applications running on top of FI-WARE Instances.

The challenge of common sets of parameters well understood by the different usage areas will be the translation. The underlying network infrastructure will follow different standardisation rules. Currently the Internet world follows mainly the IETF, the mobile communication follows 3GPP, whereas the fixed line world have standards from ETSI, ITU-T and IEEE. All of them have to be translated into a common language and interface description.

The NetIC generic enabler targets open networks that expose interfaces. Technological limitations, network operator policies, or other constraints may prevent such open interfaces. For instance, the NetIC generic enabler may not be applicable in walled garden environments, such as 3GPP cellular access networks. In that case, certain functions may partly be available by other means, e. g., by the S3C generic enabler. In general, the NetIC and S3C generic enablers will have to be aligned. Most notably, the inter-domain usage of NetIC functions may require authentication, authorization, and accounting, for instance by using the corresponding service-level interface of the S3C generic enabler, which then calls the NetIC interface.

Critical product attributes

  • The NetIC Generic Enabler will provide to its users access to network status information. Interfaces available today are already able to provide specific information, but the interface highly depends on the specific network technology. The aim of NetIC is to define a set of general functions to access network status information in a technology independent way, overcoming the heterogeneity of today’s solutions.
  • There are several standard technology and implementation dependent interfaces to control and manage specific networks. To overcome this heterogeneity, the objective of the NetIC Generic Enabler is to provide a generic interface to control and manage open networks, which shall be technology and implementation independent.


Service, Capability, Connectivity, and Control (S3C)

Target usage

The Service, Capability, Connectivity, and Control (S3C) Generic Enabler is the manifestation of an adaption layer between the targeted network control layer for Fixed-Mobile-Convergence: Evolved Packet Core (EPC) and all possible applications and services.

Driven by the roll-out of new wireless access technologies providing only packet transport capabilities like the 3GPP Long Term Evolution (LTE), the future massive wireless broadband environment is bound to transform into a data dominant environment. In order to respond to the requirements of the new environment, 3rd Generation Partnership Project defined the Evolved Packet Core (EPC) as a new IP connectivity control platform enabling wireless access network diversity (including LTE, UMTS, WiMAX, WiFi etc.) and offering seamless connectivity for the various service platforms. It maintains the same central concepts as previous 3GPP architectures, like IMS: policy based QoS and charging, subscription based access control, handover support and security, offering a scalable alternative to the current deployed architectures.

By using all-IP based communication protocols and functionality, the EPC is designed to support large number of subscribed devices, their signaling and data exchanges through its flat network design supporting mobility management inside the same or in different access technologies, subscription based resource management and accounting along with security support of the communication.

EPC provides a transparent convergent network layer for the IP Services. From the perspective of a service provider without a modification of the way the services communicate, it enables a high degree of satisfaction, by transparently supporting features like access control, QoS assurance, seamless mobility between the different access networks, prioritization and security.

Also due to the resource reservation mechanisms, the services have a guaranteed quality of the communication which is an addition to the typical IP communication and a high added value for broadband communication on mobile devices with reduced processing power.

EPC provides also a set of control mechanisms between the service platform and the network core. Through these mechanisms, the EPC aware applications can transmit indications on the resources that have to be reserved for the specific users at specific moments of time. They can also receive upon request information on events happening at the link and network layers e.g. the connected device lost connectivity or a handover to another access network occurred. By these mechanisms, the applications can be adapted to the momentary context of the mobile device and to offer services customized not only based on the service level user profile, but also to the mobile device in use, the mobility pattern and to the surrounding network context.

Although not yet standardized, EPC is able to export a set of enablers to the applications which offer even more flexibility in the service delivered to the mobile user. For example, services may use the location of the connected device or even ambient information on the vicinity of the connected device and the subscriber identity of the mobile device, in order to further more adapt to the environment conditions and to ensure a more secure communication.

With the deployment of new devices such as sensors and actuators along with the further increase in usage of the IP capable mobile devices such as laptops, tablets and smartphones, it is foreseen a high increase in signaling and data traffic expanding the overall required resources from the network.

Also new service paradigms are expected to be further developed such as mobile cloud computing or machine-to-machine communication which will even more broaden the types of communication both as communication patterns, mobility and resources required.

However, the EPC was designed with point-to-point human communication as the main service paradigm which will require a new adjustment in customizing the IP connectivity according to the momentary needs of a high number of devices using the broad future internet services.

GE description

The S3C Generic Enabler comes to mitigate these challenges of the packet core networks by offering an extended API for the various service platforms and by dynamically adapting these requirements for the packet core network. This adaptation includes novel optimized data transmission mechanisms for broadcast/multicast and for small data exchanges as well as mechanisms for data caching and aggregation. S3C also provides the control of the network resources through the inclusion and the orchestration of the new management functionality addressing both the subscribers and the services such as network identity and network connectivity, events, resources, charging and inter-carrier management, security AAA and accounting as well as network context data management such as location enablers.

Currently, the EPC has an open API through the Diameter protocol enabling a minimal synchronous reservation of resources which implies that any communication has to be signalled between the mobile device and the service platform as well as between the service platform and the core network control. However, for legacy services, such an interface is not available, thus the functionality of the EPC can not be enabled to legacy and Web-services (e.g. REST or SOAP services). In order to tailor better these types of operations and to reduce the overhead signalling and data required, the S3C will execute an interpretation and a translation of the specific service requirements and will interact directly with the core network accordingly.

Also the S3C can transmit its resource requirements directly to the NetIC Generic Enabler for an optimized handling of the subscriber based functionality at the forwarding level as well as to the CDI-Net enabler as part of the connectivity management inside the mobile devices.


Image:Function_blocs_whitin_the_adaptation_layer_between_FMC_control_layer_and_service_layer.jpg
Function blocks within the adaptation layer between FMC control layer and service layer


Functional blocks within the S3C GE will identify the different needs for “translation”:

  • Network Event Management (NEM)
The NEM function of the S3C Generic Enabler provides to the different services mechanisms for subscribing and receiving notifications on data path events related to the mobile devices.
The events, to which a service platform subscribes includes the loss of connectivity from the mobile device, the access network change, modification of the charging characteristics etc.
Through this mechanism the services are able to receive information which enables the establishment, adaptation or smooth termination of the active sessions.
  • Resource Management (RM, e.g. Computation, QoS)
For the various services to be able to communicate with the mobile devices, the S3G Generic Enabler includes a Resource Management function which enables the aggregation and convergent presentation of the applications requirements towards the core network.
The functionality of the Resource Management includes the management of the required resources at specific locations for the mobile device, the mobility management and the access network discovery and selection enabling the optimization of the usage of the core network resources for various purposes such as load balancing, scalable usage of the network resources, access network and data traffic offload enabling an efficient network support for services such as computation offload which require low delay and high throughput for short time intervals.
The Resource Management sends these requirements dynamically, based on the connectivity status of the mobile devices to the control entities of the core network enabling it to establish the parameters of the communication of the mobile devices accordingly.
  • Network Identity Management (NIM)
The NIM functionality of the S3C GE allows the secure management of identities in the network. Hereby, identities refer not only to user identities, but also to identities of devices, services, applications or end device functionalities and groups of such. This puts users and services in the position to verify the identities of each other, so that a user/device/service can be sure to perform transaction with the correct peer.
Services are enabled to create and manage network level groupings of identities for optimal communication purposes, e.g. exploit network multicast building blocks. The NIM also provides methods to authenticate identities, e.g. by use of cryptographic methods.
Identities are associated with different attribute sets, according to the context in which they appear. E.g. an online shop application may only retrieve the relevant attributes, belonging to that applications context.
The NIM also supports S3C internal charging and billing by resolving identity groups to separate chargeable identities, related to service users, but also to service providers.
Last but not least, these functions have to coexist with and/or provide support to the functions provided by Identity Management GEs in the FI-WARE Security chapter.
  • Operator SA4C (OSA4C) including Legal Interception (LI)
The OSA4C function will deal with different sub functions:
    • Security – in the sense of encryption and decryption algorithms and of keying and key management.
    • Authentication, Authorisation, Accounting, and Charging – Authentication and Authorisation are responsible to get access, whereas Accounting in Charging ensue to fulfil the possibility to perform business aspects for an operator.
    • Auditing – will offer the possibility to keep track with the business transfer.
Accounting and in auditing mechanisms are also the base for Legal Interception. Which data and which aggregated state will be provided to governmental institutions are defined in each country separately, even so in a globalised market it would be good to come to a common few.
The challenge is to implement a system function to optimise the access to third party providers as well as not to loose the control for the network service provider, which own the virtual or real infrastructure. This requires analysis of how this functions can coexist with GEs defined in the FI-WARE Security chapter.
  • Connectivity Management Entity (CME)
The CME is responsible for monitoring and controlling the attachment of mobile devices. In other words, the CME controls via which access networks/interfaces a mobile device connects to the core network.
Monitoring involves maintaining a list of available access nodes for every mobile device. An available access node is a node to which the mobile device could potentially set up a connection. Monitoring also involves keeping track of the mobile device states and the access node status, e.g. the number of connected devices.
Controlling involves initial configuration and association of an interface to an access node. In principle it can be distinguished between single technology devices and multi technology devices. In the first case the CME controls to which access node of the available technology the mobile node should connect to. In the second case the CME controls which access node of which technology to use for a specific service. This could also mean that multiple interfaces (technologies) on a single device can be active at the same time to serve different applications.
In addition to that the controller could also initiate handovers (horizontal and vertical) from one access node to another.
The CME also has an interface to the Resource Management function in order to base its decisions on current resource situation in the network.
  • Multicast/Broadcast (MC/BC) Management (MC-BC-M)
In an end-to-end communication pattern, many networks and network types are typically involved. This starts with the RAN at the mobile terminal or other last-mile network for DSL, then goes through the access and core networks until it either reaches a service or another mobile/fixed terminal. These networks can offer specific properties for MC or BC communication within their own scope.
The MC-BC-M function has the purpose to exploit such properties and to enable the usage of such to services in order to allow an optimized communication, especially towards fixed/mobile terminals, e.g. by exploiting the broadcast capabilities of a RAN.
The main use case is optimized real time video broadcasting to mobile terminals, but also group information services.
  • Network Data Caching and Aggregation (NDCA)
Parameters from (mobile) terminals and network nodes close to the terminals will over a huge range of information to optimise the network, application, and service usage in the network as well as in the devices and the cloud.
In special cases, it is not necessary to access the terminal which acts as an information source directly. Such cases are, when there was no change in the network context information. This information can be stored and cached in the node close to the terminal. So that spare resources – e.g. the air interface or the energy in a terminal is low – will not be used and the information can be requested from these nodes (e.g. a base station). The node is also responsible to aggregate the information and to provide a full information packet to the requesting network instance.
The challenge is to use existing protocols to build and manage such an environment and define the proper information data set and interface to transfer the information to the cloud infrastructure.
  • Small Data Pull/Push (SDPP)
SDPP messages are required for various applications, e.g. to request new data or to notify a specific service (running on the device or in the cloud) about events. Such messages are very small in size compared to ordinary messages. SDPP aims at providing data channels that can be used to transmit small messages (e.g. a few bytes) to a specific application.
There are existing concepts that allow for SDPP (e.g. Apple Push Notification Service, Android Cloud to Device Messaging). However, they utilize plain TCP connections and involve a lot of unnecessary overhead (e.g. keep alive messages, radio module needs to stay powered on etc). The latter problem is caused by the plurality of applications, which run in the background and frequently request or receive information from distant servers.
The challenge for SDPP is to design an interface at the networking layer that accepts push and pull request from multiple sources and delivers them efficiently by taking into account the characteristics of the wireless carrier. On the other hand, the ways in which this capability can be exploited in the implementation of Publish/Subscribe Broker GEs as defined in the FI-WARE Data/Context Management chapter have to be explored.
  • Network Context Data Management (NCDM)
Context data comprises information such as location, device status or user activity, but also network context data that is derived from nearby network nodes.
The NCDM aims at collecting and provisioning such data to mobile services and applications as well as Internet services and applications. The challenge related to NCDM is to define an appropriate interface that enables the access to the context data and allow e.g. to subscribe to certain context- and location-based events. The way in which these functions link to Data/Context Management GEs in FI-WARE, have to be analyzed.
  • Inter Carrier Management (ICM)
The Internet is an accumulation of different Internet network service providers, which run their business in a quite independent way. Even in the current Best-Effort basis, there are some Service Level Agreements in place.
Since the service request for the Internet will become in the framework of Fixed-Mobile-Convergence highly dynamic, we need mechanisms in place to support these dynamics.
Currently a lot of effort is done in the framework definition, optimisation, and integration of dynamic and QoS based peering. The necessary protocols will be used and extended to the needs of the Use Case projects and other potential Use Case areas.

Critical product attributes

  • Based on the philosophy of Future Internet, Fixed-Mobile-Convergence, and all-IP communication, S3C GE will bundle – and if needed – extend existing standards and implementations to manage and control all up-coming services and applications independently on top of a heterogeneous network infrastructures and multi-provider domain scenarios including connected third party provider, content providers, and cloud infrastructure providers.
  • In details, the S3C GE will provide a unique convergence layer towards the current and future communication world by implementing interfaces for the operator driven network infrastructure (SIB-driven), and for the Web and Cloud community services (REST and SOAP-driven), as well as towards the rest of applications and services which have no defined APIs and interfaces .
  • S3C GE will enable a higher level of scalability for the core network operations through customization on a subscriber base with the goal of enabling a higher number of devices to connect and to access their services in an efficient manner without requiring any more physical and functional extensions.
  • S3C GE will include certain interfaces and APIs for business and legal functions and processes.


Question Marks

This section lists a number of questions that remain open. Further discussion on the questions will take place in the coming months.

Security aspects

Identity Management

Management of Identity of user is a mechanisms expected to be provided for connected devices, cloud proxies, as well as network connections, services and applications running on top of the FI-WARE platform. It is however necessary a detailed analysis of the best solutions to be applied through the GE functionalities. Connected devices can offer additional functionality that can be used to improve the capabilities of the Security mechanisms. In particular, at least a subset of the devices (typically the mobile handsets, but this can be also the case of In-vehicle Infotainment units, or even some M2M modules) can provide specific capabilities offered by a secure element, which might be exploited to re-inforce the security functionality, e.g support the identity management. This can be obtained for instance through downloading with secure and standardised mechanisms Certificates, or other security elements (crypto keys, etc), as well as providing certified user profile information, which is made available in a controlled mode to the applications running on the Connected Device.

Secure Exposure of Control Functionality towards Application Platforms

The applications are able to control the data path offered by the network for the specific services synchronous to the communication provided that the application platforms have a business agreement with the core network provider. For example, this can be realized through the transmission of the communication requirements at the service establishment from the service platform to the core network. This issue does not relate to the actual data delivery between devices and application platforms. The exposure API of the core network which receives these requirements has to be able to identify and authorize the correct application platforms as well as to ensure that the communication over this exposure interface is established with the appropriate level of privacy. Also this interface should include the accounting and the validation of the Service Layer Agreements fulfilment from the side of the core network.

Secure Control Environment for Open Networking and Network Services

It is expected that the control environment which automatically executes decisions for the various functions part of the interface towards the networks is automatically validated through operation monitoring and behaviour evaluating the possible cyber-attacks in this part of the functionality. This includes the monitoring of data path traffic for open networking and network services, the abnormality detection and reporting towards the control functions for appropriate remediation. This is especially beneficial in case of self-organizing features which have to maintain the appropriate adaptation level according to the network circumstances.

Privacy Protection of Subscriber Information towards Applications

The Network Services GE exposes subscriber related information towards the FI-WARE internal and external use cases such as notifications on data path events and network context information such as device status, presence information, information on the vicinity of the device etc. This information exposure in most of the I2ND GEs (not only in Network Services but also in Connected Devices and Cloud Proxy) has to be controlled by means of rules, anonymized wherever necessary, and secured based on the requirements of the various applications and on the exposure levels allowed by the FI-WARE network operator. Also bulk data reporting should be possible in which all the information related to specific subscribers is converged under the unique identity of the network provider.

Other topics still under discussion

Interoperability of Generic Enablers

There are functionalities that, at first sight, might be considered as possible superposition among the Generic Enablers. While this is an issue to be surely addressed in some situation where the complete and precise functionality is not yet fully explored (this will be one important activity in the next project period), in general the apparently similar functionalities are rather inter-operation functionalities among the different GEs.

This is the case of CDI and S3C Generic Enablers; both GEs provide functionalities concerning network connectivity, where:

  • CDI offers management info/policies which the device uses to better manage on its own connectivity parameters (e.g. when to attach to a network, to which interface to forward a data packet) which are further exposed to applications,
  • S3C offers a control of the communication operations (e.g. how the data pipe is established over a connection of the device).

On the other hand, the interconnection and its flow among the GEs (unidirectional/bidirectional), as shown in Figure 66, is based on the current definition of the functional elements belonging to each GE. It is expected that, due to further requirements coming in the future (e.g. from Use Case projects) such interconnections will be updated according to the emerging needs. The same will apply of course for the inter-operability with all the other GEs of the FI-WARE architecture.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP)

  • Connected Devices: A connected or smart device can be an advanced device located at home, such as a set top box and multimedia device (including advanced TVs), PCs, storage (NAS like), indoor handset (home/advanced DECT), or game consoles. Furthermore, mobile devices, such as mobile/smart phones (GSM/3-4G), tablets, netbooks, on-board units, (in-car devices) or information kiosks are connected devices, too. It is very likely that new devices will appear and fall into this “smart devices” category during the project execution (femto cells, etc.).
  • Cloud Proxy: A device encompassing broadband connectivity, local connectivity, routing and networking functionalities as well as service enabling functionalities supported by a modular software execution environment (virtual machines, advanced middleware). The “Cloud Proxy” or “Home Hub” is powerful enough to run local applications (for example home automation related tasks such as heating control or content related ones such as Peer to Peer (P2P) or content backup). It will also generally include local storage and may be an enabler for controlling privacy as some content or data could be stored locally and could be controlled only by the user without having the risk of seeing his/her data controlled by third parties under consideration of the overall security architecture.
  • Open Networking: Open networking is a concept that enables network nodes to provide intelligent network connectivity by dynamic configuration via open interfaces. Examples for provided features are the fulfillment of bandwidth or quality requirements, seamless mobility, or highly efficient data transport optimised for the application (e. g., with minimum network resource or energy consumption).
  • Network Service: Network Service is a control and policy layer/stratum within the network architecture of a service provider. The Network Service provides access to capabilities of the telecommunication network, accessed through open and secure Application Programming Interfaces (APIs) and other interfaces/sub-layers. The Network Service concept aims at providing stratum that serves value-added services and applications at a higher application and service layer and exploits features of the underlying transport and technology layer (e. g. via NetIC interfaces).


References

[IPsphere]

IPsphere project within the Telemanagement Forum, http://www.tmforum.org/ipsphere

[StrataModel]

T. Nolle, “A New Business Layer for IP Networks”, July 2005 Issue of Business Comunications Review, 999 Oakmont Plaza Drive, Suite 100, Westmont, IL 60559, 630/986-1432, www.bcr.com –http://www.ipsphereforum.org/Files/A New Business Layer for IP Networks –-TN1.pdf

[TMF]

Telemanagement Forum, http://www.tmforum.org/

[Cube01]

R. Aguiar, H. J. Einsiedler, J. I. Moreno, “An Operational Conceptual Model for Global Communication Infrastructures”, Wireless Personal Communications – Global Information Multimedia Communication Village (GIMCV), Volume 49, Number 3, May 2009, Springer Press Netherlands, Selected topics from the Strategic Workshop, May 28-30, 2008, Madeira, Portugal , ISSN 0929-6212 (Print) 1572-834X (Online).

[Cube02]

R. Aguiar, H. J. Einsiedler, J. I. Moreno, “A Requirements Analysis for the Protocol Stack of the Future Internet”, International Conference on Communications 2009 (IEEE ICC 2009), International Workshop on the Network of the Future 2009, 18 June 2009, Dresden, Germany.

Personal tools
Create a book