Last update: 2011/08/21
MPEG-21 and MPEG-M show a practical path to content-centric networks
My ability to present - and get approved - European projects dwindled after I left Telecom Italia. In the early days of the DMP a promoted the idea of a project on DRM Conformance (DRM-C). The project was proposed
as a first EU leading initiative towards the establishment of DRM conformance (DRM-C) practices. The project will provide a means for the development of EU based conformance testing IP in support of future development of interoperable DRM tools, components and solutions thus furthering the state of the art in digital content creation and distribution.
My lowered appreciation of the new European Commission environment was enhanced when I saw the following evaluation of the relevance of the proposal
DRM and interoperability are definitely within scope but conformance testing is less of a priority of the Strategic Objective.
How can one say that interoperability is important and conformance testing - the means to assess whether there is interoperability - is not? Mysteries of European project reviewing...
The Convergence project had a different story. it was presented three times and approved the third time - but only because it was submitted to a different area. In the following a presentation is provided.
Convergence is an ICT system consisting of a set of interconnected peers and nodes collectively called “CONVERGENCE devices”.
Peers are based on a 3-layer architecture. From the top
Nodes are devices that only include a Computing platform layer, specifically the CoNet layer.
A complete architecture of a peer is depicted in Fig. 1. Each of the 3 layers has its own structure and communicates with other layers via standard APIs.
Fig. 1 - Convergence peer
Users can download/install Apps to a peer and activate lower layer functionalities intended by the App developer – both local and remote – via the standard CoMid API. To expedite the development of Apps, Convergence defines special re-usable App elements called Tools so as to facilitate re-use of code in Apps. In the following the term App will be used to mean both App and Tool.
Middleware Engines are CoMid functionalities that can be activated by Apps. These are of two types: 1. Protocol Engines (PE) to activate functionalities in remote or local peers 2. Technology Engines (TE) that are typically called by PEs to execute specific functionalities.
An App call may involve more that one PE/TE. Therefore Convergence provides a standard mechanism for “aggregating” PEs and “orchestrating” TEs. Fig. 3 depicts how an App call may give rise to a chain of PEs/TEs. It is to be noted, however, that chains need not be linear and that Apps can also directly call TEs without PE intermediation.
Fig. 2 - A chain of Protocol and Technology Engines
The 3 lowest blocks belong to the Computing Platform layer:
Convergence users act on Versatile Digital Items (VDI). These are XML structures containing
Convergence has defined 4 types of VDI: Resource, Publication, Subscription and User. Their use enhances the features of the system.
A native functionality is the Convergence Core Ontology (CCO). The CCO allows for a semantic organisation of peers in a virtual overlay network of “fractals” defined on the basis of users’ interests in the different types of content distributed on Convergence. From the example of such a fractal organisation depicted in Fig. 3, it can be seen that a peer typically belongs to more than one fractal, depending on how users are interested in what kind of content (resources, VDIs etc.). Note that in general a fractal is populated by more than one peer to accommodate the fact that some peers may be off when access to them is needed.
Ontologies other than the CCO, namely domain and user ontologies, can also be used to define fractals. Typically SPs offer access to the former while the latter are created by the individual users. Therefore the fractal organisation can be seen as covering multiple “dimensions”, where each dimension is defined by an ontology. Thus, a peer may contain content which refers to concepts that are based on different ontologies in different dimensions.
Once a VDI has been created it receives a unique and persistent identifier. But a VDI may be “superseded” by a new version of it or a new independent VDI may appear that has some connection with the existing VDI. In all these cases it is useful to be able to place a semantic link between two VDIs. Convergence Ontology Services lets users establish such links.
Fig. 3 – Structure of Convergence fractals
The CO may also be used to define groups of peers called fractals representing some concept. All P-VDIs and S-VDIs related to a certain concept are stored in some peers (more than one because some peers may go off) of that fractal. Peers have the embedded ability to
Perform matches between P-VDIs and S-VDIs
Communicate any match to the specified users/peers depending on licences and ERRs
Remove from the match tables S-VDIs and P-VDIs when
Their expiration date has passed
An authorised user requests to remove them before their time
Security is an essential feature of Convergence that has to deal withsecurity expectations such as:
A first answer to this question is provided by Fig. 4. CoSec is a hardware-based security element that contains a private key with the ability to perform such basic security functionality as asymmetric encryption etc. Based on CoSec the Security TE can
Fig. 4 – Security in Convergence
Other Engines rely on the Security Engine to perform the following
Signing of VDI (VDI TE)
Symmetric encryption/decryption of resources (Media Framework TE)
Asymmetric encryption/decryption of a key (REL TE)
User Identification (Identify User TE)
User Authentication (Authenticate User TE)
Communications between peers is made possible by a content-centric network, called CoNet that lets users access remote named-resources as opposed to remote hosts. As Fig. 5 shows, named-resources can be:
Fig. 5 – Mapping between CoNet named-resources and middleware entities
Fig. 6 depicts the CoNet network architecture. CoNet is a system interconnecting CoNet Sub Systems (CSSs). A CSS contains CoNet nodes and exploits an under-CoNet technology to transfer data between CoNet nodes.
Fig. 6 – CoNet Architecture
