My ability to present – and get approved – European projects dwindled after I left Telecom Italia. In the early days of the DMP a convinced a group of European DMP members to propose a project on “DRM Conformance” (DRM-C). In the abstract we wrote that the project was meant to be
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 Brussels environment was enhanced when I saw the text of the 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.
This answer defies my intellect. How can one say that interoperability is important and conformance testing is not? Maybe the reviewers didn’t know what a standard is (no problem), but if you are revieweing a project on interoperability of something you cannot say that the means to assess whether there is interoperability are not important. It would be like saying that laws are important but tribunals are not. Unless, I mean, interoperability is one of the nice words which everybody pays lip service to – and then keep on erecting walls.
I had a better chance with two project proposals that I submitted in later years. The first was CONVERGENCE, a project submitted by a consortium of 12 European partners and the second GreenICN, submitted by two separate 6-partner consortia – one from Europe and one from Japan – with a common work plan. Even though the two projects are independent, and sequential in time, they are tightly connected for the latterto be considered as the continuation of the former as far as CEDEO is concerned.
Internet has been quite successful in responding to the expanding needs of its users. However, the internet has shortcomings, e.g. the unpredictable bitrates available over long distances. Peer-to-Peer (P2P) Networks and Content Distribution Networks (CDN) are overlay networks that use content replication strategies to lower the probability to findnetwork bottlenecks. The interesting point is that they move away from a host-based to a content-based communication model.
Information Centric Networking (ICN) is an emerging communication paradigm in which each information unit is stored as an individually identified entity at an appropriate granularity level, so that it is possible to retrieve it by simply using its identifier. This is alternative to retrieving an information unit from a logical location whose physical address is provided by the Domain Name System (DNS). Therefore ICN can be seen as an incorporation of P2P and CDN functionalities into the network layer.
CONVERGENCE is an ICT system consisting of a set of interconnected peers and nodes collectively called “CONVERGENCE devices”.
Figure 1 – CONVERGENCE devices
Fig. 1 depicts three different kinds of ICN device, namely CoNet, a network node; CoSec, a security node; and Peer, a user device. CoNet is a node device running the ICN stack of functionalities, CoSec is a node device responsible for handling the majority of cryptographic protocols and security related tasks and Peer is a layered device, based on a 3-layer architecture. From the bottom
- Computing Platform includes computing resources and operating system interfaces (API) able to run concurrently CoNet and CoSec implementations;
- CoMid is a middleware exposing interfaces (API) to applications;
- Apps include applications.
GreenICN uses and expands the same architecture with different names.
Peers, the means through which users access network functionalities, are essential components for an ICN. The GreenICN peer architecture is based on MPEG-M and uses a number of other MPEG standard technologies. A complete architecture of a Peer is depicted in Fig. 2.
Each of the 3 layers has its own structure and communicates with other layers via standard APIs.
Figure 2 – GreenICN peer architecture
The GreeICN Peer exposes the High Level API defined in the Table below.
| API name | Function |
| Storage and retrieval | Called by Store and Publish app |
| Pub/Sub Service | Called by Store and Publish, and Subscribe and Play apps |
| Network Service | Called by Peer Management app |
| Energy management | Called by Peer Management app |
| Security | Called by Peer Management app |
Currently the GreenICN Peer supports the Protocol and Technology Engines defined in the Table below.
| Engine | Acron. | Definition |
| Authorise User | AUPE | A Protocol Engine that authorises a user |
| Create Licence | CLPE | A Protocol Engine that enables a user to cr eate a REL licence |
| Identify Content | ICPE | A Protocol Engine that handles requests for content identification |
| Identify User | IUPE | A Protocol Engine that handles requests for user identification |
| Digital Item | DITE | Processes Digital Items |
| Event Report | ERTE | Processes Event Report Request and generates Event Reports |
| GreenNet | GNTE | Manages communication with the Green ICN networking layer |
| GreenTech | GTTE | Controls energy consumption to achieve a given energy consumption plan |
| Match | MATE | Matches metadata with a query |
| Media Framework | MFTE | Processes media data (encoding, transport and decoding) |
| Media Query | MQTE | Handles queries related to media content |
| Metadata | MDTE | Generates and parses metadata |
| Orchestrator | ORTE | Manages operations of a plurality of Technology Engines |
| Overlay | OLTE | Manages Peer and Semantic Overlay Network communication |
| Rights Expression | RETE | Generates and parses REL licences |
| Security | SETE | Performs security operation (symm/asymm encryption etc.) |
The GreeICN Peer exposes the Low Level API defined in the Table below.
| Name | Function |
| Local resources | Provides access to Computing Platform specific API |
| GreenNet | Provides access to GreenICN networking |
| Security | Provides access to trusted environment (e.g, smartcard) functionality |
| Energy Storage | Provides access to energy management (battery etc.) |
With reference to the Publish/Subscribe (PubSub) communication paradigm, and in particular the Publish/Subscribe Aplication Format (PSAF), GreenICN peers have the embedded ability to
- Perform matches between PIs and SIs
- Communicate any match to the specified users/peers
Currently a demo has been developed that supports a use case called “Managed advertising for real estate”. In the use case Toshiki, a real estate businessman, applies a windowing policy for his offers of vacation apartments. For two weeks his clients are pre-emptively offered available apartments but, after that, everybody, including non-clients, can access the apartments on offer. The actors of the Managed advertising for real estate are:
- Nozomu, an apartment owner
- Toshiki, a real estate businessman
- Mary, Toshiki’s administrative assistant
- John and Keiko, Toshiki’s customers.
The GreenICN peer offers a number of features that map very well with Toshiki’s promotion strategy as shown by Figure 5 where the main steps of the walkthrough can be identified:
- Toshiki requests Segmenter Peer to prepare video (DASH segmentation, encryption, data identification) and store it to GreenICN
- Upon notification that Segmenter Peer has completed its job, Toshiki requests Licence Peer to create licences for his customers (currently John and Keiko)
- When Keiko requests to play the video, her Peer request Licence Peer to provide the means to decrypt the video
- Upon reception of decryption key Keiko can decrypt and see Toshiki’s video.is is the sequence of steps:
Figure 4 depicts how Publish/Subscribe works in CONVERGENCE.
Figure 4 – The GreenICN Real Estate Advertising demo
The demo makes use of a number of MPEG technologies, besides MXM, namely
- Digital Item
- Digital Item Identifier
- Simple Metadata Profile
- MPEG Query Format
- Rights Expression Language
- Event Reporting