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
FIWARE.OpenSpecification.I2ND.S3C - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.I2ND.S3C
Chapter I2ND,
Catalogue-Link to Implementation [N/A ]



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


All four GEs of I2ND have a different focus but will be interconnected through interfaces and the Service Capability, Connectivity and Control (S3C) generic enabler will be the central control and management entity/GE. However, to the outside world, each GE has an interface towards the network infrastructure as well partly to the FIWARE services, applications and Cloud services. The interface format towards the network infrastructure will be handled by the respective GE. The Interface towards the Cloud services, FIWARE services and applications should be a common interface and is under discussion.

The interfaces between the GEs will be network oriented and up to now the template of IEEE 802.x standards for multiple layer management as described in IEEE 802.11 (Section 10 on Layer Management) [1] will be used. The specific layer management was designed to sustain the communication between the multiple layers for strict time constraint environments, involved through a simple set of primitives. The same format was further used by IEEE for multiple standards such as IEEE 802.11a, 802.11g, 802.16, 802.21. This format/template might be a good template for the exchanging the necessary information between the GEs. The specific implementation of the communication template proposed depends on the specific protocols selected for each of the reference points. For the time being, we are considering this template format in any cases where we have IP interfaces. An exception is the interface between S3C and NetIC and other legacy networks, a specific internal interface of the Evolved Packet Core (EPC) will be used and extended for exchanging the necessary information. The EPC (based on OpenEPC)enables prototyping of IP connectivity related features like QoS and charging, mobility management, access and security for 3GPP and non-3GPP wireless technologies including 3GPP Long Term Evolution (LTE). It supports the new paradigms such as Machine Type Communication, Mobile Clouds, and IP Multimedia Subsystem (IMS).

Target usage

The S3C Generic Enabler is the manifestation of an adaptation layer between the targeted network control layer for fixed-mobile-convergence: Evolved Packet Core (EPC) and all possible applications and services.

Driven by the rollout 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 (3GPP) defined the 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 3G only 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. This supports 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 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.

Due to the resource reservation mechanisms, the services have a guaranteed quality of service for 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.

Due to the transparent mobility feature, the mobile devices maintain the same IP address while changing the radio access network used. Additionally, the core network ensures that no data packet is lost during mobility. These transparent features of the EPC core network provide additional value for the broadband communication, as services do not have to be aware and handle any mobility related feature.

EPC provides also a set of control mechanisms between the service platform and the network core. Through these mechanisms, applications can transmit indications on the network resources (e.g. bandwidth) 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 current 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 as not in the main goal of the standard, 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.

EPC provides only connectivity service in carrier grade mobile network operator environments. For additional basic and value added carrier grade services, 3GPP standardized the IP Multimedia Subsystem (IMS), which, using the Session Initiation Protocol (SIP) provides a basic service platform on top of the IP connectivity especially oriented towards multimedia services such as voice, video, or messaging.

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.

Basic Concepts

S3C aims at providing a unified and scalable control of the connectivity of the devices over heterogeneous access networks and core network technologies, transparent to the devices and to the services deployed on top. For this, S3C contains automated functionality related to the management of the various features related to connectivity such as the usage of the network context data and events for triggering resource management, mobility, connectivity management, and security operations. Additionally, it provides to the application and services platforms an extended service API that enables the configuration and control of the connectivity service with different complexity, granularity, and application specific requirement levels.

The S3C GE will have different interfaces towards other work packages, operators, third party operators, other I2ND-GEs and the S3C-assets (e.g. network devices). A service API (S3C API) will be defined that can be used by other work packages, use case projects and other third party state of the art service platforms and applications. It contains two main different interfaces and protocol technologies to interact towards the service providers. One is used for the telecommunication services (SIP) and another for the Over-The-Top Web-services (HTTP). This HTTP interface includes a Telecom server able to work through SOAP, REST and will provide an OneAPI interface. A specific OneA PI enabler for MMS/SMS is there as well. There is an API mediation layer to manage HTTP APIs..

An extension of the OMA Next Generation Services Interface (NGSI) is included in order to provide flexible connectivity control for Over-The-Top (OTT) services, including resource reservation and access network selection (interface 19 the following figure).

The connection towards other operator networks (interface 5 in the following figure) is established and controlled, such as described D4.3 [10] of the EU Project ETICS (Economics and Technologies for Inter-Carrier Services, [11]). They have defined an Abstraction/Intermediate Layer especially for the interconnection of operators: ETICS Deliverable D4.2 [2]. The other operators may deploy legacy or S3C based network operator control infrastructure.

Between the GEs Connected Device Interface (CDI) and Cloud Edge (CE) (interface 13 the figure) protocols like Plain IP and OMA Device Management (DM) ([3]) are used. Towards NetIC the control-interface from the EPC (a Diameter Gx interface [15]) is in place.

Within the S3C, it is planned to use plain IP, IMS SIP and the Diameter protocol (through interfaces such as the 3GPP Rx for resource reservations ([15]), Sh for subscriber profile management ([16]) and Rf for charging correlation ([17])) to interlink with the assets.

Overview of the interfaces and features of the S3C GE

Example Use Case scenario

The challenge in S3C is remarkable given the requirement for user connectivity coverage in a wide range of scenarios. A significant role S3C plays is in the field of eHealth. Where a typical use case scenario is an accident of several cars on the highway, in which a number of people have been injured. In such a case, people will call the ambulance and contact doctors through voice, video conferencing, and augmented reality aiming for highest quality local support. Being on a highway the emergency call is most likely to be done by a person in the area of the accident, in this case a caller’s location is not a fixed static address, but rather a mobile device somewhere on a mobile network. It is also highly expected that the person calling the ambulance is not able to accurately describe the place of the accident on the highway. Determining the exact position of the accident is a significant aspect in such a scenario because lives, or threatening situations to life, depend on it. Given the accurate position of the accident is determined, injured people will be transported to the hospital via the ambulance or helicopter. Augmented reality, video conferencing, and voice support helps on deciding for the process to select the heavy injured ones and to receive medical records in real time.

  • The request is processed via SIP connections and will be handled by “Telecom AS” towards the IMS core (For the prototypes the OpenIMS [9] platform is used).
  • The Positioning Enabler mechanism, used for location-based services, is used for determining the location of the mobile device from which the emergency call is originated, and hence obtain the exact place of the accident. Moreover, it is used to route the call to the ambulance in closest proximity or to the appropriate public safety answering points (PSAP), the caller's phone number and fixed location is automatically displayed for quick-response dispatching.
  • Via the functions “Seamless Connectivity”, “Network Identity Management” and “OpenEPC”, the request can be classified as important and will be treated with highest service quality through the plain legacy operator network. Or through a request to NetIC, a special QoS path can be established for end-to-end interconnection in one single domain. The resource reservations as well as the basic reachability and data exchange will be maintained transparently while the caller is on move and thus changing the radio attachment point to the network, even when changing the access network type for example trough connecting to the hospital internal network.
  • Additional communication with less importance will be safely delivered directly to other actors, who may be involved in the procedure such as the health insurance companies, the car manufacturers and other legal entities. The API mediation layer enables to control the user and server interaction here.
  • In the case of an end-to-end connection through several domains, the ETICS interface [11] can be used to set-up an end-to-end-QoS path.

Differentiation between feature groups

The S3C Abstraction layer/Generic Enabler contains independent features, which will interact to each other. The features are grouped into three different classes, depending on the requirements that lead to their development.

  • Internal Features – features that enable a scalable and efficient operation of the core network, transparent to the applications and services. These features provide a high capacity, low delay, secure communication over one or more access networks at the same time.
    • SeamlessNetworkConnectivity.SCC
      The Seamless Connectivity Client provides the functionality for tunnel and flow management on the mobile client side for devices that connect over multiple radio accesses at the same time.
    • SeamlessNetworkConnectivity.FlowController
      This Feature takes decisions on which connection the flow has to use based on rules defined at the Flow Controller for devices that connect over multiple radio accesses at the same time.
    • SeamlessNetworkConnectivity.SCS
      The Seamless Connectivity Server provides functionalities for tunnel and flow management on the network side for devices that connect over multiple radio accesses at the same time.
    • OpenEPC.OperatorSA4C
      Operator Security, Authentication, Authorization, Accounting, Auditing and Charging & Legal Interception. The feature will support the network internal mechanisms for security, AAA, auditing and charging. Through this means the appropriate usage of the network is ensured. The specific features rely on the specific network identity of the device. Through this identity and through the specific credentials, the device usage of the network is authorized and a binding is created between the current attachment point in the network and the services used. Lawful interception will give defined authority the restricted and lawful controlled access to network and used IDs.
    • OpenEPC.ConnectivityManagementEntity
      Monitoring and controlling the connectivity state of the devices. It helps to support the efficient monitoring and the control of network devices. This includes M2M equipment addressing, the scalable control of multiple devices pertaining to the same entity, such as multiple sensor and actuator devices in the same administrative domain or enterprise controlled devices.
    • OpenEPC.ResourceManagement
      This feature will support the overall network resource management including the interconnection and information transfer towards the NetIC. The resource management functionality enables the external entities to require a specific level of resources between different nodes in the network. This may represent mobile devices, data centers or any other operator entity able to communicate, as well as the entities that enable the communication with the other network operators. Based on these requirements, the resource management makes policy decisions and generates specific QoS and charging rules. These rules are then installed on the data path, guaranteeing that the resources are reserved according to the service applications. The installation may be done on plain legacy and operator networks or on the open networks controlled through the NetIC Generic Enabler. In case the resources cannot be guaranteed, due to a congestion state at the network level, a notification is transmitted as response to the resource requirements, enabling the connectivity requirements to be adapted to the current status of the network.
    • OpenEPC.ConnectionToAccessNetworks
      OpenEPC connects either directly or through third party radio hardware and software to various access networks including LTE, UMTS, GPRS, WiFi, WiMAX, CDMA 2000 etc. The Radio Access Networks and the Core Network have to be deployed together in order to offer connectivity over a carrier grade operator network, simply named "network". Due to this, the standardization of core networks and radio access networks contains, in a large amount, the integration features. Thus, from an interface-to-networks perspective, the interface between the core network and the radio access networks is considered internal.
    • OpenEPC.CoreNetworkMobilityManagement
      This feature includes the transparent vertical handover using Proxy Mobile IP (PMIP) or GPRS Tunneling Protocol (GTP) and the correspondent functionality in the evolved Packet Data Gateway (ePDG), Serving Gateway (S-GW) and Packed Data Network Gateway (PDN GW). Through this feature, the mobile device will receive the same IP address regardless of the radio access network to which it connects to being of the same or of different radio technology. Due to this connectivity support, the applications do not have to handle any mobility related functionality and can regard the mobile devices similar to non-mobile devices.
    • OpenEPC.NetworkEventManagement
      Provides to the core network information related to the changes in status of the connectivity of the devices, e.g. loss of connectivity. As part of the considered services in this class, the basic reachability through network attachment as well as the sessions of the specific services. This functionality is offered to the specific applications through the IMS core for SIP based services. It can also be acquired by other non-IMS services using the OpenEPC.NetworkContextDataManagement described as part of the External Features underneath.
  • External Features – features exposed to the application and services enabling the communication of requirements and events as well as of the actual data transferred between the devices and their correspondent nodes
      The GSMA OneAPI v2 [11] defines a set of RESTful HTTP APIs for various telecom services, and among them SMS/MMS-sending APIs. Using such industry-standard APIs have the following benefits for developers and publishers:
      • Add network capabilities to their development toolkit.
      • Reduce proprietary integrations to multiple operators.
      • Mashup network APIs into desktop and mobile Web applications.
        The proposed components will implement these APIs, while relying on standard SMS-C/MMS-C protocols on the network-side, to ensure maximum sustainability of the architecture in a LTE-switching context.
    • NetworkIdentityManagement.IntelligentDeviceIdentification
      As a Service Provider, a SIP Request gets forwarded towards a device, which has feasible capabilities regarding the requirements of this request (SDP, Context). Also a manual by the end user routing of this request is possible. It is only one public and one private identity necessary for the end-user, which means less effort in administration on the network provider's side.
    • NetworkIdentityManagement.VirtualIdentities
      A user can have more than one identity towards a service for different purposes and accounting mechanisms. The Identity Management has to pick the identity of a previous set up selection table and forward the updated SIP request towards the service. Future releases can provide also small toggle application on mobile devices for a fast switch of the identities in a SIP environment.
    • NetworkPositioningEnabler.PositioningPrivacyMngmt
      To permit the user to dynamically configure her/his privacy measures when being positioned by 3rd party entities. Prior to initiation of a third party for a positioning request, it is required that it properly identifies itself (via e-mail address or mobile phone number) to the Positioning Enabler. The target then either grants permission to the third party or declines the positioning request.
    • NetworkPositioningEnabler.PositioningNotification
      As soon as a location event that the client device has previously subscribed for via the Positioning Enabler is fulfilled, the Positioning Enabler sends the client a notification message.
    • NetworkPositioningEnabler.PositioningRequest
      Enables users to request their position from the Positioning Enabler. The Positioning Enabler in return computes the position of a client device from the core network, EPC.
    • NetworkPositioningEnabler.PositioningTracking
      The user's position is continuously tracked in the background for determining location events, Geofencing. Enables client to subscribe for certain location events on the Positioning Enabler. Hence, the Positioning Enabler will continuously track the client device in the background via the core network, EPC, creating a geofence.
    • OpenEPC.ConnectionToApplications
      OpenEPC includes a Diameter interface towards the different application platforms for resource reservation and data path event notification as well as a Diameter interface towards the Home Subscriber Server for sharing subscription profile information between core networks and applications. This Diameter interface is wrapped in a HTTP/REST interface enabling applications from both the network and the mobile devices to request resource reservations. The wrapper provides network specific functionalities by a simplified means; specifically addressing application developers. Data path communication is plain IPv4 or IPv6. This feature represents the realization of the OpenEPC API as part of the S3C API in form of specification and GE reference implementation.
    • OpenEPC.ClientMobilityManagement
      OpenEPC supports policy-based access network discovery and operator assisted access selection through an Access Network Discovery and Selection Function (ANDSF) in the core network and a client mobility manager for Linux OS based mobile devices. An HTTP/REST wrapper interface is part of the OpenEPC API towards applications, enabling them to select the preferred access network over which the communication should be executed.
    • OpenEPC.NetworkContextDataManagement
      Location, device status, user status/activity, and user role are provided through this feature towards applications. It will help to optimize the efficient usage of network resources and will support the FI-WARE and usage area services and applications. The network context data management is not related directly to any active service on the mobile device. Selected information from these functions will be exposed to the external entities communicating through an S3C operator network as part of the Device Connection and Operator OpenEPC APIs. The exact features depend on the use cases requirements while maintaining the subscriber privacy and information protection. The information is currently available in the Home Subscriber Server (HSS), a common storage entity between EPC and IMS. It is foreseen that the same entity will be used for retrieving the data for other services.
    • OpenEPC.InterCarrierManagement
      Management of inter-operation issues. It is/will be defined by the ETICS project. It will offer the possibility to complete the end-to-end service connectivity for the case in which the communicating parties are pertaining to different operators.
    • Telecom AS.Telecom AS
      As a platform, the TelecomAS enabler currently offers "audio-mixing" for conferencing and automated dialog (speech synthesis, voice recognition, Dual-tone multi-frequency signaling (DTMF) recognition). The northbound interface uses SOAP (order from service logic, service notifications to logic) and the south interface works with Session Initation Protocol (SIP) / Real-Time Protocol (RTP). SOAP REST is possible but not yet in place directly on this TelekomAS. It is a server, not a software. It provides a layer between servers, services, administration and users. To servers it acts as a Telco client proxy, to clients it acts as a Telco server proxy, to services it exposes an administration interface making it possible to create new services, modify and destroy them easily. To the operator it exposes also an administration interface.
      Interfaces functionalities: VoIP signaling and media to telecom networks, orders / notifications to the service logic, Call Data Records (CDR) (not existing on this TelecomAS). The multi-service aspect will involve notions of limitations of a priori traffic service (not yet available on this TelecomAS immediately).
    • API mediation.API mediation
      This API mediation layer belongs to S3C northbound interface. Its role is to publish/expose API and to authorize users, manage contract terms and create CDR if needed. API mediation layer's south interface interconnects with heterogeneous and legacy networks. Northbound interface exposes those networks interfaces to HTTP services.
      It enables HTTP services to query and to use the network communication services for the specific service delivery.
      It is important to be able to expose networks APIs to the HTTP realm in a managed way without the hassle to have to implement a mediation layer in each applications or network enabler. Third party providers could use Telco APIs to improve their own HTTP services. Network APIs should be easily discovered and used by end users. It should also be able to charge easily end users and third parties.
      The API mediation component provides the functionalities needed to manage the exposed interfaces to several actors interacting with the network infrastructure.
      The API mediation component deals with publishing, discovering and exposing APIs to stakeholders as well as managing some non-functional aspects such as provisioning and monitoring. It doesn't create or host APIs nor manage/provision customers, but makes it possible for API providers to register new APIs sets to the Exposition, QoS and resource management.
  • Special requirements/features – features addressing special requirements from the different application areas related to the efficient and scalable data delivery. These features can be in a less efficient manner being supported through the internal and external features previously described.
    • OpenEPC.Multicast/BroadcastManagement
      To optimize the network resources for information, which do not necessarily be handled by unicast connections. Some services are delivered at the same time to different users or devices. In this case, a multicast or broadcast delivery will optimize the usage of the network resources. This feature depends on the capacity of the applications to provide multi-cast groups to which devices may join.
    • OpenEPC.SmallDataPush/Pull
      For limited small information, e.g. sensor data. Small information “packets” might not necessarily be transferred through IP packet because of the addressing overhead. This feature will offer a scalable solution for a high number of connected devices. Such feature is implemented through Simple Messages Service (SMS) over 2G, 3G and LTE networks.
    • OpenEPC.NetworkDataCachingAndAggregation
      To optimize network resources and for applications which are time critical, then it makes sense to optimize the information close to the terminal for all kind of data transfers. It will support locally information delivery to optimize and to reduce the end-to-end resource usage for Internet applications. The actual data storage pertains to the specific applications. This feature will provide a special data path which ends where the data is cached, thus not requiring a loop to the centralized locations of the operator core network.

Main interactions

For S3C, we have nine interfaces towards the world (in principle and especially to FI-WARE GEs, usage area projects, and other operators) (marked in light green) and two towards the three GEs of I2ND (marked in light red). Interface 21 and 22 are interfaces to the central proxy API provided by S3C. However most of the requests will just be forwarded to the interfaces below. Details of how to use the interfaces and the proxy will be given within the open specifications.

Northbound Interfaces

These interfaces will be described in the following:

  • Interface to Network Identity Management (12,13)
    • Description: The Network Identity Management tries to map identities for telco providers in a Next-Generation-Network environment, which is based on SIP/IMS communication. Therefore it has a SIP interface towards SIP Application Services where the enriched SIP Messages be sent to. The customer data is stored in the Security.IdM and the NIM retrieves this data over a secured channel to map the data into the SIP messages. Next to this, over the OneAPI (JSON) Specification, you are able to control third party calls from client to client as well as AS to client.
    • Main Actors: Use Case Projects / Operators / Application / Webservice
    • Data: The transmitted data will be filtered profile data sets from the customer database of the Security.IdM. This data will be mapped into SIP messages. For device identification, a service is able to get a list of all connected devices of a specific subscriber as well as the current capabilities.
    • Prerequisites: There should be an IMS Application Server which can benefit from additional P-Header fields, which are described in the Open Specification. Next to this, an HTTP Interface for controlling is required to identify and control the user agents devices. The subscriber needs IP connectivity, a subscriber identity in the IMS network and a User-Agent for the IMS/SIP communication.
  • Interface to Telecom AS (14)
    • Description: The purpose of this Interface is to expose an API making it possible to create new Telecom services fast in a few lines. The functionalities and features of interface consist of OneAPI messages that are exchanged between a user application and a server. In addition an administrative interface (not represented), makes it possible to create services. Creating services is done with small scripts such as "create an Interactive Voice Response".
    • Main Actors: Telecom service developers/Use Case Projects.
    • Data: The data that is exchanged over the interface consist of REST API that are aligned on the OneAPI syntax
    • Prerequisites: 1) Having the right to use this interface (granted through a registration process). 2) The capability to write scripting code able to do HTTP request.
  • Interface to OneAPI SMS/MMS (15)
    • Description: The purpose of this Interface is to offer OneAPI compatible SMS and MMS servers. The functionalities and features accessed through this interface consist of sending SMS/MMS with a mobile phone to a recipient. This is an exercise to provide real OneAPI functionalities to be able to test OneAPI clients. The syntax follows this model: Verb, Parameter name, Description, Response.
    • Main Actors: Developers
    • Data: Data is in the following formats:
      • XML (text/xml): if the application accepts header containing XML
      • JSON (application/json): if the application accepts header containing JSON
      • Else : text/plain if the application doesn't accept XML nor JSON)
    • Prerequisites: 1) Having the right to use this interface (granted through a registration process). 2) The SMS OneAPI API, allows developers to easily send plain/text SMS MT (Mobile Terminating) messages to mobile phones (in a defined operator network) in a limited number of countries (FR, UK, BE and RO).
  • Interface to API Mediation (16)
    • Description: This interface enables the interaction of users and third parties with the Telecom core network API users. It intercepts queries and answers made by applications to network servers such as OneAPI SMS/MMS. A key aspect is that not only Apps on user's mobile phone can request network's APIs but third parties, offering APIs to end users, might also use this interface when they want to interact with the network servers. Main administrative functionalities (the administrative interface is not represented) are enabling/forbidding access and accounting API usage by users and third parties. A provisioning API for the administrative interface is provided that allow administration to manage dynamic access accounts, credentials and technical service contracts related to REST/RESTful services exposed via API Mediation.
    • Main Actors: Operators, third parties and end users.
    • Data: The data that is exchanged over the interface consists of HTTP queries to internal or external servers, we can't specify what is it because the user applications and the servers are third parties to the network. Nevertheless those queries and answers can, at the moment, only be formulated in HTTP or a protocol that uses HTTP as a bearer protocol, such as SOAP, REST, OneAPI, OpenID, OAuth, etc.
    • Prerequisites: 1) Having the right to use this interface is granted through a registration process. 2) Using a Web browser (HTTP client).
  • Interface to Positioning Enabler (17)
    • Description: This interface enables the interaction of users and third parties with the Positioning Enabler. Through this interface, the user registration and subscription for location events functionalities are accessed. Moreover, privacy management as well as user notification and background tracking is controlled via this interface.
    • Main Actors: Use Case Projects, Operators and Applications.
    • Data: The data exchanged over this interface includes user registration data, e-mail address (OpenID), accept/reject messages (opt-in) of tracking requests for privacy management and notification alerts for fulfillment of location events.
    • Prerequisites: A smartphone with WiFi capabilities is required.
  • Interface to Seamless Network Connectivity (18)
    • Description: This interface enables the access of the rule sets from an external service. This means an external service can list/create/change/udpate rules for specific applications and user.
    • Main Actors: Operator, Users
    • Data: Decision Rule Sets
    • Prerequisites: The end device should use the Seamless Connectivity Client (SCC) to be able to use the enhanced service delivery. If there is no user using the SCC nothing can be controlled with this interface.
  • Interface to OpenEPC (19)
    • Description: This interface allows services to transmit their requirements directly towards the core network. It provides the means for applications to reserve resources and thus to realize the required QoS characteristics. Additionally, it provides the means for the applications to indicate the access network over which the communication should be executed. Also it provides to the applications an interface towards the network context information of the specific subscribers such as connectivity status, IP address and access network to which the device is connected etc.
    • Main Actors: Over-The-Top application developers from operators, use cases, and webservice areas
    • Data: The data exchanged over the interface consists of HTTP queries towards the EPC core network wrapper enabling resource reservations, resource reservation terminations and access network selection indications. Additionally it includes SQL queries towards the HSS in order to determine the momentary subscriber context.
    • Prerequisites: For using the interface a contractual agreement between the operator (as the legal entity providing the network through which the device communicates including the interface towards the EPC) and the service provider (as the legal entity providing the service to mobile devices through the EPC connectivity service) is required. It addresses services deployed on IP capable devices connected to carrier grade operator networks.
  • Interface for Intercarrier Management (20)
    • Description: The interface will allow the possibility to set-up end-to-end QoS aware traffic bundles between different network service provider domains. The end-to-end QoS management framework (ETICS management framework) negotiates the end-to-end connectivity. The request for the resources reservation is done through this interface after successful negotiation.
    • Main Actors: Network Service providers (Operators) and content service providers (at the edge of the end-to-end QoS path). Both have to participate in the ETICS community
    • Data: QoS parameters (bandwidth, delay, jitter)
    • Prerequisites: The interface allows the set-up of end-to-end QoS paths. Please note, we will have traffic/flow bundles not individual flows. The QoS bundle is including data flows of IP capable devices that are connected to a carrier grade operator network.

Two other GEs of I2ND will communicate through S3C, therefore the S3C is the central GE. The interfaces are defined in the following.

  • Interface to CDI (10)
    • Description: This interface allows the CDI enabler to transmit the QoS requirements of the applications residing on the mobile device as well as information related to the access network preferred for the communication from the perspective of the user of the mobile device.
    • Main Actors: CDI GE and S3C GE. This interface is internal to the I2ND representing the interaction between the network and the devices related to connectivity service.
    • Data: HTTP messages formatted as OMA DM messages for access network discovery and selection features and as OMA NGSI REST messages for resource reservations,
    • Prerequisites: An S3C enabled carrier grade operator infrastructure and a CDI enabled mobile device subscribed for connectivity service to the S3C operator.
  • Interface to NetIC (11)
    • Description: This interface allows S3C to communicate with the underlying transport infrastructure from which the backhaul networks are realized of. It enables the operator network to transmit to the open network controller of NetIC QoS requirements and expects a confirmation whether these resource requirements could be fulfilled
    • Main Actors: CDI GE and S3C GE. This interface is internal to the I2ND representing the interaction between the carrier grade operator core network (EPC) and the open transport network (NetIC)
    • Data: Diameter messages including rules with QoS reservation information as specified for the 3GPP Gx interface
    • Prerequisites: An S3C enabled carrier grade operator infrastructure and a NetIC enabled transport network of the S3C operator.


[1] IEEE “IEEE Standard for Information technology— Telecommunications and information exchange between systems— Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC)”, IEEE Std 802.11™-2007 (Revision of IEEE Std 802.11-1999), IEEE Standards, http://standards.ieee.org/getieee802/download/802.11-2007.pdf.

[2] ETICS Deliverable D4.2, https://www.ict-etics.eu/fileadmin/documents/publications/deliverables/D4_2_ETICS_architecture_and_functional_entities_high_level_design.pdf.

[3] Open Mobile Alliance Device Management Working Group, http://www.openmobilealliance.org/Technical/DM.aspx.

[4] Second release of FI-WARE High Level Description and reception of Requirements from UC projects, Deliverable D2.2b, http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Interface_to_Networks_and_Devices_(I2ND).

[5] SIP: Session Initiation Protocol, IETF Request for Comments, RFC 3261, http://www.ietf.org/rfc/rfc3261.txt.

[6] Hypertext Transfer Protocol -- HTTP/1.1, IETF Request for Comments, RFC 2616, http://www.ietf.org/rfc/rfc2616.txt.

[7] Diameter Base Protocol, IETF Request for Comments, RFC 3588, http://www.rfc-editor.org/rfc/rfc3588.txt.

[8] OMA Secure User Plane Location (SUPL), http://www.openmobilealliance.org/technical/release_program/supl_v2_0.aspx

[9] OpenIMS http://www.openimscore.org/

[10] ETICS Deliverable D4.3 https://bscw.ict-etics.eu/pub/bscw.cgi/d37005/ETICS_D4.3_v1.0.pdf

[11] Economics and Technologies for Inter-Carrier Services (ETICS) https://www.ict-etics.eu/

[12] GSMA OneAPI http://www.gsma.com/oneapi/

[13] 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”;

[14] 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses (Release 12)”;

[15] 3GPP TS 23.203, “Policy and charging control architecture”

[16] 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2

[17] 3GPP TS 32.260: "Telecommunication Management; Charging Management; IP Multimedia Subsystem (IMS) charging".

Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

Re-utilised Technologies/Specifications

  • Network Identity Manager, Telecom enabler and SMS/MMS Enabler use OneAPI compliant APIs: http://oneapi.gsma.com/
  • API mediation and the Network Identity Management uses HTTP based APIs to the Service Provider, so it manages any kind of HTTP APIs, including OneAPI.
  • Network Identity Management and API Mediation are based of the functionality of http://www.openimscore.org
  • Seamless Network Connectivity based on the connectivity environment provided by http://www.openepc.org
  • The Network Identity Management is using the database of the Identity Management of the FI-WARE Security Chapter for the predefined user profiles in the SIP environment

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). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • 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).
  • OpenEPC: OpenEPC is a prototype implementation of the 3GPP Evolved Packet Core (EPC) – Release 10 – that enables academia and industry researchers and engineers around the world to obtain a practical look and feel of the capabilities of the Evolved Packet Core. OpenEPC Rel. 3, the current version available, includes all the components of the 3GPP architecture including the interfaces with various access technologies and service platforms.
  • M2M: Machine-to-Machine is a method for interconnect machines to each other to exchange their information,e.g. between sensor and actor-networks over an instance which is controlling the end points
  • Diameter: Diameter is the successor of the common known RADIUS for centralized AAA functionality. It is more secure by using a tcp connectivity than udp and supports more functionality
Personal tools
Create a book