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.Data.ContextBroker R3 - FIWARE Forge Wiki

FIWARE.OpenSpecification.Data.ContextBroker R3

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Data.ContextBroker
Chapter Data/Context Management,
Catalogue-Link to Implementation Orion Context Broker
Owner Telefonica I+D, Fermin Galan (TID)



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.

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


Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (implicit patents license) to understand the rights to use these specifications.


Introduction to the Context Broker GE

The Context Broker GE will enable publication of context information by entities, referred as Context Producers, so that published context information becomes available to other entities, referred as Context Consumers, which are interested in processing the published context information. Applications or even other GEs in the FI-WARE platform may play the role of Context Producers, Context Consumers or both. Events in FI-WARE based systems refer to something that has happened, or is contemplated as having happened. Changes in context information are therefore considered as events that can be handled by applications or FI-WARE GEs.

The Context Broker GE supports two ways of communications: push and pull towards both the Context Producer and the Context Consumer. It does mean that a Context Producer with a minimal or very simple logic may continuously push the context information into the Context Broker, when the information is available or due to the internal logic of the Context Producer. The Context Broker on its side can request the context information from Context Producers if they provide the ability to be queried (Context Producers able to act as servers are also referred as Context Providers). In a similar way, Context Consumers can pull the context information from the Context Broker (on-request mode), while the Context Broker can push the information to Contest Consumer interested in it (subscription mode).

A fundamental principle supported by the Context Broker GE is that of achieving a total decoupling between Context Producers and Context Consumers. On one hand, this means that Context Producers publish data without knowing which, where and when Context Consumers will consume published data; therefore they do not need to be connected to them. On the other hand, Context Consumers consume context information of their interest, without this meaning they know which Context Producer has published a particular event: they are just interested in the event itself but not in who generated it. As a result, the Context Broker GE is an excellent bridge enabling external applications to manage events related to the Internet of the Things (IoT) in a simpler way hiding the complexity of gathering measures from IoT resources (sensors) that might be distributed or involving access through multiple low-level communication protocols.

Target usage

The Context Broker is a GE of the FI-WARE platform that exposes the (standard) interfaces for retrieval of the context information, events and other data from the Context or Data/Event Producers to the Context or Data/Event Consumers. The consumer doesn’t need to know where the data are located and what is the native protocol for their retrieval. It will just communicate to the Context Broker GE through a well-defined interface specifying the data it needed in a defined way: on request or on subscription basis. The Context Broker GE will provide the data back to the consumer when queried, in case of "on-request", or when available, in case of "on-subscription" communication mode.

Example Scenarios

The number of potential context sources permanently connected through 3G links, e.g. mobile user terminals, embedded sensors, microphones and cameras, is expected to increase significantly in the coming years. By processing and inferring this raw information, a variety of useful information will be available in future communication and content management systems. It is likely for smart spaces to grow from smart homes/offices to urban smart spaces in which plenty of artifacts and people are interconnected over distance. This will enable all sorts of innovative interactive pervasive applications as perceived by Weiser [1].

A few examples of how usage of the Context Broker GE may improve the user experience and enrich a service are given below.

Next figure shows a context-aware advertising service (described in [3]) sending an invitation and a coupon to a customer in proximity to a boutique. Also the goods are chosen for that customer based on her/his preferences and previous acquisition. Therefore advertisement messages traffic is significantly reduced, targeting only potential clients, and the clients' user experience is not suffering from a "broadcast" of advertisement messages with zero or very low value. This scenario is possible because the customer or a service provider on her/his behalf, subscribes to some content (e.g. advertisement message and coupon) under certain conditions (the customer is close to the boutique and matching the preferences).

Example of context-aware advertising service

Another example might be context-aware content exchange shown in the figure below, where a customer sees only the content published by social friends (friends in a social network the customer is member of) only when this content is related to her location as well as when that content was originally "placed" in that location. Using interfaces provided by the Context Broker. the application used by the customer can subscribe to be informed based on recommendations related to her/his current location, her/his preferences and coming from friends of the Social Networks the customer is member of. Recommendation would be handled as content information provided by recommender systems or individuals.

Example of context-aware content exchange

The following figure shows a logical architecture of the Context Broker GE with its main components and the basic information it handles to enrich traditional Mobile Advertisement and Content Share services.

Logical architecture of the Context Broker GE

Basic Concepts

All the communications between the various components of the Context Broker high-level architecture occur via two different interfaces/protocols, which are described in the following sections:

  • ContextML/CQL built on top of HTTP in RESTlike way and allowing to publish or to retrieve context in a very simple, easy and efficient way, especially for mobile devices environments;
  • NGSI RESTful interface inspired and based on the OMA NGSI specification [4]. This is a standard interface allowing to handle any type of data, which may include meta-data.

Context Elements

Aligned with the standard OMA NGSI specification, Context Information in FI-WARE is represented through generic data structures referred to as Context Elements. A Context Element refers to information that is produced, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. It has associated a value defined as consisting of a sequence of one or more <name, type, value> triplets referred to as context element attributes. FI-WARE will support a set of built-in basic data types as well as the possibility to define structured data types similarly to how they are defined in most programming languages.

A Context Element typically provides information relevant to a particular entity, being it a physical thing or part of an application. As an example, a context element may contain values of the “last measured temperature”, “square meters” and “wall color” attributes associated to a room in a building. That's why they typically contain an EntityId and an EntityType uniquely identifying the entity. Finally, there may be meta-data (also referred to as semantic data) linked to attributes in a context element. However, the existence of meta-data linked to a context element attribute is optional.

In summary, context information in OMA NGSI is represented through data structures called context elements, which have associated:

  • An EntityId and EntityType, uniquely identifying the entity to which context data refers.
  • A sequence of one or more data element attributes (<name, type, value> triplets)
  • Optional meta-data linked to attributes (also <name, type, value> triplets)

As an example, we may consider the context element linked to updates on:

  • attributes “speed”, “geolocation”, “current established route” of a “car”, or
  • attributes “message geolocation”, “message contents” of a “user”

The EntityId is a string, and can be used to designate “anything”, not necessarily “things” in the “real world” but also application entities.

A cornerstone concept in FI-WARE is that context elements are not bound to a specific representation formalism. As an example, they can be represented as:

  • an XML document (SensorML, ContextML, or whatever)
  • a binary buffer being transferred
  • as an entry in RDBMS table (or a number of entries in different tables),
  • as a number of entries in a RDF Repository
  • as entries in a NoSQL database like MongoDB.

A key advantage of this conceptual model for context elements is its compliance with IoT formats (SensorML) while enabling further extensions to them.

Basic Actors in the Context Broker GE Model

Context Broker

As already mentioned the Context Broker (CB) is the main component of the architecture. It works as a handler and aggregator of context data and as an interface between architecture actors. Primarily the CB has to control context flow among all attached actors; in order to do that, the CB has to know every Context Provider (CP) in the architecture; this feature is done through an announcement process detailed in the next sections.

Typically, the CB provides a Context Provider Lookup Service, a Context Cache and a Context History Service.

Context Provider

A Context Provider (CP) is an actor that provides context information on demand, in synchronous mode; that means that the Context Broker or even the Context Consumer can invoke the CP in order to acquire context information. A CP provides context data only further to a specific invocation. Moreover, a CP can produce new context information inferred from the computation of input parameters; hence it is many times responsible for reasoning on high-level context information and for sensor data fusion. Every CP registers its availability and capabilities by sending appropriate announcements to the CB and exposes interfaces to provide context information to the CB and to Context Consumers.

Context Source

A Context Source (CS) spontaneously updates context information, about one or more context attributes or scopes. A CS sends context information according to its internal logic and does not expose the same interfaces as the CP to the CB and to Context Consumers.

Compared to the pull based CP-CB communication, the communication between CS and CB is in push mode, from the CS to the CB.

Context Consumer

A Context Consumer (CC) is an entity (e.g. a context based application) that exploits context information. A CC can retrieve context information sending a request to the CB or invoking directly a CP over a specific interface. Another way for the CC to obtain information is by subscribing to context information updates that match certain conditions (e.g., are related to certain set of entities). The CC registers a call-back operation with the subscription for the purpose, so the CB notifies the CC about relevant updates on the context by invoking this call-back function.


Every exchange of context data here is referred to a specific entity, which can be in its order a complex group of more than one entity. An entity is the subject (e.g. user or group of users, things or group of things, etc.), which context data refer to. It is composed of two parts: a type and an identifier. Every Context Provider supports one or more entity types and this information is published to the Context Broker during an announcement process described later.

A type is an object that categorizes a set of entities; for example entity types are:

  • human users - identified by username;
  • mobile devices - identified by imei;
  • mobile users - identified by mobile (GSM phone number);
  • SIP accounts - identified by SIP uri;
  • groups of other entities - identified by groupid;

The entity identifier specifies a particular item in a set of entities belonging to the same type. Every human user of the context management platform could be identified by multiple means and not just based on the username. That means that a process that provides identity resolution could be necessary. Considering for example a CP that provides geographical cell based location for mobile devices; if the location information is obtained from the computation of parameters provided by mobile devices, this CP supports entities that are mobile users identified by the type mobile. When the CB receives a getContext request about location of a human user, therefore identified by username, the CB could not invoke the provider previously described because it does not support this entity type, but if the user has a mobile device, information about his location is probably available in the system. If the CB could retrieve all entities related to this user, it could invoke the provider using, if it is possible, identifiers of entities it knows how to process. This feature could be provided using a detailed database collecting all information about users; it means that the CB could refer to this DB in order to retrieve all entities connected to a specific user. In this way the example described previously could work because, when the CB receives the request, it invokes the database and retrieves the entity of type mobile related to the user; afterwards, the CB could invoke the location provider using the obtained entity and could send response with location data to the requester.

Context scopes

Context information attributes managed by the Context Broker can be defined as part of a “scope”, which is a set of closely related context attributes. Every context attribute has a name and belongs to only one scope. Using a scope in operation exported or invoked by a Context Broker is very useful because attributes in that scope are always requested, updated, provided and stored at the same time; it means that creation and update data within a scope is always atomic so data associated to attributes in a scope are always consistent. Scopes themselves can be atomic or aggregated, as union of different atomic context scopes.

For example take into account the scope position referring to the geographic position in which an entity is. This scope could be composed of parameters latitude, longitude and accuracy (intended as error on location) and these are always handled at the same time. Updating for example the latitude value without updating longitude, if is changed, and vice versa is obviously not correct.

Advanced Features and Functionalities

Context caching

Context information received by the Context Broker (from a Context Source or as a result of a request to a Context Provider) is stored in a context cache. If another Context Consumer requests the same context information to the Context Broker, it can be retrieved from the cache, unless entries in the cache have expired (see next Chapter 3.4). This way, the Context Broker does not need to invoke the same Context Provider again and context delivery speeds up.

Context validity

Any scope used during exchange of context information is tagged with a timestamp and expiration time. The expiry time tag states the validity of the scope. After this time, the information is considered not to be valid any more, and should be deleted. The setting of the expiration time is in charge of the Context Source or Context Provider that generates the context information and the Context Broker can only change it to synchronize to its clock.

When the Context Broker is asked for a scope, it first looks for it in its cache. If the information is found, the expiry time is checked. If the expiration time is reached, the Context Broker removes it from the context cache and requests it from a registered Context Provider.

Context history

Every context information exchanged between the Context Broker and Context Providers or Context Sources is logged in the context history. The context history is different from the context cache, which stores only currently valid information (i.e., current values of attributes associated to context entities). The context history makes past context information about an entity also available, without reference to current validity. Context reasoning techniques could be applied to the context history in order to correlate contexts and deduce further context information, e.g. about situations, user intentions (sub-goals) and goals.

FI-WARE NGSI Specification

Most of this GE's API operations regarding Events/Context retrieval and notification are inspired on the OMA (Open Mobile Alliance) NGSI Context Management specifications.

However, the FI-WARE team has identified potential updates to the standard to guarantee its correct exploitation in this context, solve some ambiguities and extend its capabilities according to the FI-WARE vision. Therefore, we will speak onwards about the FI-WARE NGSI specification, which is still under discussion and, hence some contents in the FI-WARE NGSI API description included in the present document will vary to be aligned with the final FI-WARE NGSI API specifications. FI-WARE NGSI specifications differ from the OMA NGSI specifications mainly in the binding, as far as OMA doesn’t have any binding by definition. However FI-WARE NGSI improves some of the OMA NGSI aspects, which could be improved in the OMA as well, and finally, probably not all the mandatory/optional definitions will be respected in the FI-WARE binding. Therefore the FI-WARE NGSI is mainly the technological binding for the OMA specifications with very little omits and differences.

Main Interactions

Using 'FI-WARE NGSI API' to interact with the Context Broker GE

Notions about OMA NGSI Specs

OMA NGSI (Next Generation Service Interface) Operations are grouped into two major interfaces:

  • NGSI-10
    • updateContext
    • queryContext
    • subscribeContext / unsubscribeContext / updateContextSubscription
    • notifyContext
  • NGSI-9
    • registerContext
    • discoverContextAvailability
    • subscribeContextAvailability / unsubscribeContextAvailability / updateContextAvailabilitySubscription
    • notifyContextAvailability

The FI-WARE specification is an evolution/modification proposal of the OMA NGSI specification which aims to maximize the role of NGSI for massive data collection from the IoT world, where a myriad of IoT resources are providing context elements occurrence/updates involving low level protocols. In other words FI-WARE NGSI is mainly the binding over OMA NGSI, however some small differences, out of scope of this documents, have been implemented in FI-WARE NGSI with respect to OMA specification.

Basic Interactions and related Entities

The following diagram depicts the basic interactions of the Context Broker GE with its natural counterparts, that is the Context Producers and the Context Consumers.

  • Context Producers publish data/context elements by invoking the updateContext operation on a Context Broker.
  • Some Context Producers may also implement a queryContext method. Context Brokers may invoke it at any given time to query on values of a designated set of attributes linked to a given set of entities
  • Context Consumers can retrieve data/context elements by invoking the queryContext operation on a Context Broker
  • Context data is kept persistent by Context Brokers and ready to be queried while not exceeding a given expiration time. This is a distinguishing feature of the OMA Context Management model as compared to some Event Brokering or Event Notification standards.

Interactions related to query-able Context Producers

Context Producers publish data/context elements by invoking the updateContext operation on a Context Broker. Some Context Producers may also export a queryContext operation Context Brokers may invoke at any given time to query on values of a designated set of attributes linked to a given set of entities

  • Context Consumers can retrieve data/context elements by invoking the queryContext operation on a Context Broker
  • Context data is kept persistent by Context Brokers and ready to be queried while not exceeding a given expiration time. This is a distinguishing feature of the OMA Context Management model as compared to some Event Brokering standards.

Interactions to force Context Consumers to subscribe to specific notifications

Some Context Consumers can be subscribed to reception of data/context elements which comply with certain conditions, using the subscribeContext operation a ContextBroker exports. A duration may be assigned the subscriptions.

  • Subscribed consumers spontaneously receive data/context elements compliant with that subscription through the notifyContext operation they export
  • Note that the Application which subscribes a particular Context Consumer may or may not be the Context Consumer itself

Extended Operations: Registering Entities & Attributes availability

The registerContext operation in Context Brokers can be used not only for registering ContextProducers on which queryContext operations can be invoked (Context Providers) but also to register existence of entities in the system and availability of attributes.

  • Context Brokers may export operations to discover entities or even attributes and attribute domains that have been registered in the system.

Extended Operations: Applications subscription to Entities/Attributes registration

Some applications can be subscribed to registration of entities or availability of attributes, and attribute domains, which comply with certain conditions. They do so by means of using the subscribeContextAvailability operation a Context Broker may export. A duration may be assigned to the subscriptions.

  • Subscribed applications spontaneously receive updates on new entities, attributes or attribute domains compliant with that subscription through the notifyContextAvailability operation they export
  • Note that the subscriber and subscribed applications may not be the same

Using ContextML to interact with the Context Broker GE

In order to allow a heterogeneous distribution of information, the raw context data needs to be enclosed in a common format understood by the CB and all other architectural components. Every component in the Context Management Framework that can provide context information has to expose common interfaces for the invocations. A light and efficient solution could be REST-like interfaces over HTTP protocol, allowing components to access any functionality (parameters or methods) simply invoking a specific URL. It should be compliant with the following pattern:


The returned data are formatted according to the Context Management Language (ContextML) proposed for this architecture.

ContextML Basics

'ContextML' [5] is an XML-based language designed for use in the aforementioned context awareness architecture as a common language for exchanging context data between architecture components. It defines a language for context representation and communication between components that should be supported by all components in the architecture. The language has commands enabling Context Providers to register themselves to the Context Broker. It also has commands and enabling potential Context Consumers to discover the context information they need. Context information could refer to different context scopes.

ContextML allows the following features:

  • Representation of context data
  • Announcement of Context Providers toward Context Broker
  • Description of Context Providers published to the Context Broker
  • Description of context scopes available on Context Broker
  • Representation of generic response (ACK/NACK)

The ContextML schema is composed by:

  • 'ctxEls': contains one or more context elements
  • 'ctxAdvs': contains the announcement of Context Provider features toward the Context Broker
  • 'scopeEls': contains information about scopes actually available to the Context Broker
  • 'ctxPrvEls': contains information about Context Providers actually published to the Context Broker
  • 'ctxResp': contains a generic response from a component

Context Data

Any context information given by a provider refers to an entity and a specific scope. When a Context Provider is queried, it replies with a ContextML document which contains the following elements:

  • ContextProvider: a unique identifier for the provider of the data
  • Entity: the identifier and the type of the entity which the data are related to;
  • Scope: the scope which the context data belongs to;
  • Timestamp and expires: respectively, the time in which the response was created, and the expiration time of the data part;
  • DataPart: part of the document which contains actual context data which are represented by a list of a features and relative values through the <par> element (“parameter”). They can be grouped through the <parS> element (“parameter struct”) and/or <parA> element (“parameter array”) if necessary.

The figure below shows ContextML context data provided from a Context Provider that supports the civilAddress scope.


civilAddress Scope Example
ContextML Naming Conventions

The following naming conventions are applied to scope names, entity types, and to ContextML parameters (<par>), arrays (<parA>) and parameters structs (<parS>)

  • names should be lower case, with the capital letters if composed by more than one word
    • example: cell, longitude, netType
  • special chars like *_:/ must be avoided
  • MAC addresses or Bluetooth IDs should be written without ':' separator, using capital letters
    • example: MAC address 00:22:6B:86:85:E3 should be represented: 00226B8685E3

ContextML API

A description of available methods and examples can be found in ContextML API.

ContextQL (CQL)

ContextQL or CQL [8] is an XML-based language allowing subscriptions to the Context Broker by scope conditions and rules consisting of more then one conditions. The applications may request or subscribe to the broker for the real-time context and for history data placing certain matching conditions and rules directly into a (subscription) request. ContextQL is based on ContextML described above for the data representation and communication between the components within the Pub/Sub GE architecture (a response to a CQL query is a ContextML document). The ContextML objects within filters and conditions are elements of the ContextQL matching or conditional rules.

Context Query

A context query allows to send to the Context Broker a complex request consisting of many rules with conditions and matching parameters over the data available to the broker in real-time (including the context cache) and in the history. A query may contain the following elements:

  • action – an action to undertake as response to the query The type of the actions is determined by the response of the broker
  • entity – a subject or an object (an entity) or set of entities to which the query refers to
  • scope – scope to which a query refers to
  • timerange – period of time interval to which a query refers to. This parameter (expressed by two attributes from and to that indicates the begin and the end of the range respectively) indicates if data to be considered within context cache or in the context history on in both
  • conds – set of conditions that express a filter of the query

The following actions can be represented in CQL:

  • SELECT – allow to request to broker the context information regarding certain entity and certain scope matching certain conditions. A wildcard e.g. entityType|* or username|* is allowed
  • SELECT with the option LIST – allows to retrieve a list of all entities of a certain type that satisfying in their context to certain conditions
  • SELECT with the option COUNT – allows to count all the entities which context satisfy certain conditions
  • SUBSCRIBE – subscribes to the broker for a certain scope matching certain conditions. The requests such as entityType|* are permitted. The subscription is limited to certain time or period indicated in the subscription request and might be shortened by the broker down to refusal of the subscription. Therefore a subscription shall be periodically renewed. Any accepted subscription is associated by the broker to a unique subId, which shall be used by the application submitting the subscription request. An unsubscribe request can be implemented by a subscription with a certain subId of an existing subscription setting the validity period to zero.

The following conditions can be expressed in CQL:

  • ONCLOCK – conditions that shall be checked in a certain period of time returning a result. This is an asynchronous request therefor can be executed only in SUBSCRIBE requests
  • ONCHANGE – conditions that will be respected when one of matching parameters will be changed. This is an asynchronous request therefor can be executed only in SUBSCRIBE requests
  • ONVALUE – conditions that shall match certain parameters to observe. This might be both a synchronous and an asynchronous requests therefore could be executed as both SELECT and SUBSCRIBE actions


XSD schema of a ContextML query

The conds tag may contain one or more conditions for any condition type. If there are more then conditions elements they shall be linked condOp. The following table indicated the conditions combinations of different types that can be handled by the broker.

Combinations of possible conditions in the broker

For example a subscription request to position scope for 5 minutes and every time the position is retrieved by GPS will be accepted.

A single condition may contain one or more tag constraints, in this case the conditions are linked by a logical operator tag logical and limited to one only depth level.

Every constraint element has at maximum 4 attributes and its evaluation depends on the applied conditions:

  • param – identifies parameters to which refers a condition and its value shall be the same context type to match e.g. scope.par, scope.parS.par, scope.parA[n].par. This attribute does not exist if the condition ONCLOCK
  • op – identifies operator to apply to a parameter. This attribute exists only in the conditions ONVALUE. Currently defined attributes are of arithmetic and string-based types, which are listed in the below table

ContextQL operators

  • value – identifies a value matched in the condition. This attribute exists only if condition is ONVALUE or ONCLOCK (in this case indicates the number of seconds when the condition will be verified). In case of ONVALUE condition this attribute doesn't exist for some operations such as e.g. EX and NEX
  • delta – used only in conditions ONVALUE and if matching parameter have value within certain interval. Identifies a tolerance threshold in condition matching e.g. param=position.latitude, op=EQ, value=45, delta=0.2, where the constraint matching for latitude values included within 44.8 e 45.2.


A description of Context Query Language with some examples can be found in CQL API

Basic Design Principles

Conceptual Decoupling

Context and data distribution is the process through which information is distributed and shared between multiple data and context producing and consuming entities in a context(data)-aware system. For efficient data/context management, including context/data distribution, it is imperative to consider communication schemes with respect to the decoupling they provide. Various forms of decoupling are supported:

  • Space Decoupling: The interacting parties do not need to know each other. The publishers (providers) publish information through an event/information service and the subscribers (consumers) receive information indirectly through that service. The publishers and subscribers do not usually hold references to each other and neither do they know how many subscribers/publishers are participating in the interaction.
  • Time Decoupling: The interacting parties do not need to be actively participating in the interaction at the same time i.e., the publisher might publish some information while the subscriber is disconnected and the subscriber might get notified about the availability of some information while the original publisher is disconnected.
  • Synchronization Decoupling: Publishers are not blocked while producing information, and subscribers can get asynchronously notified (through call-backs) of the availability of information while performing some concurrent activity i.e. the publishing and consumption of information does not happen in the main flow of control of the interacting parties.

This decoupling is important to cater for because decoupling of production and consumption of information increases scalability by removing all explicit dependencies between the interacting participants. Removing these dependencies strongly reduces coordination requirements between the different entities and makes the resulting communication infrastructure well adapted to distributed environments. This advantage becomes more beneficial when mobile entities exist in a distributed system (owing to their limited resources, intermittent connectivity etc.).



Weiser, M., "The computer for the 21st century", Human-computer interaction: toward the year 2000, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1995.


Lamorte L., Licciardi C. A., Marengo M., Salmeri A., Mohr P., Raffa G., Roffia L., Pettinari M. & Salmon Cinotti T., 2007, “A platform for enabling context aware telecommunication services”, 3rd Workshop on Context Awareness for Proactive Systems, University of Surrey, UK, June 2007.


Moltchanov B., Knappmeyer M., Licciardi C. A., Baker N., 2008, “Context-Aware Content Shariing and Castiing”, ICIN2008, Bordeaux, France, UK, October 2008.


Open Mobile Alliance (OMA) Next Generation Services Interface (NGSI) Specification http://www.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0-20101207-C/OMA-TS-NGSI_Context_Management-V1_0-20100803-C.pdf


Moltchanov B., Knappmeyer M., Liaquat Kiani S., Fra' C., Baker N., 2010, “ContextML: A Light-Weight Context Representation and Context Management Schema”, IEEE International Symposium on Wireless Pervasive Computing, Modena, Italy, May 2010.


Sumi, Y., Etani, T., Fels, S., Simonet, N., Kobayashi, K. & Mase, K., 1998, “C-map: Building a context-aware mobile assistant for exhibition tours”, Community Computing and Support Systems, Social Interaction in Networked Communities, Springer-Verlag, UK, pp.137–154.


Cheverst, K., Davies, N., Mitchell, K., Friday, A. & Efs-tratiou, C., 2000, “Developing a context-aware electronic tourist guide: some issues and experiences”, Proceedings of the SIGCHI conference on Human Factors in Computing Systems, ACM Press, New York, USA, pp.17–24.


Moltchanov B., Fra' C., Valla, M., Licciardi C. A., 2011, “Context Management Framework and Context Representation for MNO”, Activity Context Workshop / AAAI2012, San Francisco, USA, August 2012.


Gu, T., Pung, H.K. & Zhang, D.Q., 2004, “A middleware for building context-aware mobile services”, Proceedings of IEEE Vehicular Technology Conference (VTC), Milan, Italy


Fahy, P. & Clarke, S., 2004, “CASS – a middleware for mobile context-aware applications”, Workshop on Context Awareness, MobiSys 2004.


MobiLife, an Integrated Project in European Union’s IST 6th Framework Programme, http://www.ist-mobilife.org


Service Platform for Innovative Communication Environment (SPICE), An Integrated Project in European Union’s IST 6th Framework Programme, http://www.ist-spice.org


Open Platform for User-centric service Creation and Execution (OPUCE), An Integrated Project in European Union’s IST 6th Framework Programme.


Context-aware Content Casting (C-CAST), A Research Project in European Union's ICT 7th Framework Programme.

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

Other Specifications

Re-utilised Technologies/Specifications

Most of this GE's API operations regarding Events/Context retrieval and notification are inspired on the OMA (Open Mobile Alliance) NGSI Context Management specifications.

However, the FIWARE team has identified potential updates to the standard to guarantee its correct exploitation in this context, solve some ambiguities and extend its capabilities according to the FIWARE vision. Therefore, we will speak onwards about the FIWARE NGSI specification. FIWARE NGSI specifications differ from the OMA NGSI specifications mainly in the binding, as far as OMA doesn’t have any binding by definition. However FIWARE NGSI improves some of the OMA NGSI aspects, which could be improved in the OMA as well, and finally, thus not all the mandatory/optional definitions may be respected in the FIWARE binding. Therefore the FIWARE NGSI is mainly the technological binding for the OMA specifications with very little omits and differences.

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

  • Data refers to information that is produced, generated, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. Data in FIWARE has associated a data type and avalue. FIWARE will support a set of built-in basic data types similar to those existing in most programming languages. Values linked to basic data types supported in FIWARE are referred as basic data values. As an example, basic data values like ‘2’, ‘7’ or ‘365’ belong to the integer basic data type.
  • A data element refers to data whose value is defined as consisting of a sequence of one or more <name, type, value> triplets referred as data element attributes, where the type and value of each attribute is either mapped to a basic data type and a basic data value or mapped to the data type and value of another data element.
  • Context in FIWARE is represented through context elements. A context element extends the concept of data element by associating an EntityId and EntityType to it, uniquely identifying the entity (which in turn may map to a group of entities) in the FIWARE system to which the context element information refers. In addition, there may be some attributes as well as meta-data associated to attributes that we may define as mandatory for context elements as compared to data elements. Context elements are typically created containing the value of attributes characterizing a given entity at a given moment. As an example, a context element may contain values of some of the attributes “last measured temperature”, “square meters” and “wall color” associated to a room in a building. Note that there might be many different context elements referring to the same entity in a system, each containing the value of a different set of attributes. This allows that different applications handle different context elements for the same entity, each containing only those attributes of that entity relevant to the corresponding application. It will also allow representing updates on set of attributes linked to a given entity: each of these updates can actually take the form of a context element and contain only the value of those attributes that have changed.
  • An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. Events typically lead to creation of some data or context element describing or representing the events, thus allowing them to processed. As an example, a sensor device may be measuring the temperature and pressure of a given boiler, sending a context element every five minutes associated to that entity (the boiler) that includes the value of these to attributes (temperature and pressure). The creation and sending of the context element is an event, i.e., what has occurred. Since the data/context elements that are generated linked to an event are the way events get visible in a computing system, it is common to refer to these data/context elements simply as "events".
  • A data event refers to an event leading to creation of a data element.
  • A context event refers to an event leading to creation of a context element.
  • An event object is used to mean a programming entity that represents an event in a computing system [EPIA] like event-aware GEs. Event objects allow to perform operations on event, also known as event processing. Event objects are defined as a data element (or a context element) representing an event to which a number of standard event object properties (similar to a header) are associated internally. These standard event object properties support certain event processing functions.
Personal tools
Create a book