Swiss Priority Programmes

2 October 2018.1/24

Division IV

Swiss Priority Programmes

Final Report Form

Funding Period 2000 – 2002

Basic data

Programme name / SPP-ICS 2000
Project / 5003-057755
Title / StreamCom - Commercialization of Streamed Information
Main applicant
Name, first name
Academic degree
Institution, address
Office phone number
Fax number
E-mail address
/ Prof Dimitri Konstantas
University of Geneva – CUI
24 Rue General Dufour
1211 Geneva 4

Co- applicants

Name, first name, institution, place
Schiper, Andre, EPFL – LSE, Lausanne
Hubaux, Jean-Pierre, EPFL – ICA, Lausanne
Wegman, Alain, EPFL – ICA, Lausanne
Schmid, Beat, MCM, St. Gallen
Haeuschen, Harald, University of Zurich – IFI, Zurich
Maas, Wolfgang, Information Objects AG, St. Gallen

I hereby confirm the veracity of all the details given in this final report. They were prepared in agreement with the persons involved.

Place, date: Geneva, June 14, 2002 Signature:

List of contents

Summary (max. 1 A4 page)[13]
Results

2.1Overview of scientific results (max. 6 A4 pages)[14]

2.2Overview of knowledge and technology transfer results (max. 4 A4 pages)

2.3Activities in the field of training and education (max. 2 A4 pages)

Relevance of the project [15]

3.1Scientific relevance (max. 1 A4 page)

3.2Relevance for the praxis (e.g. Industry) (max. 1 A4 page)

3.3Relevance for society (max. 1 A4 page)

Co-operation with partners outside the project (max. 2 A4 pages)

4.1Description of the co-operation [16]

4.2List [17]

Goals and achievements (max. 2 A4 pages)[18]
Experiences, problems and suggestions (max. 1 A4 page)[19]
Lists

7.1Degrees and Awards [20]

7.1.1Degrees

7.1.2Awards

7.2Knowledge transfer [21]

7.2.1Scientific publication with peer review

7.2.2Scientific publication without peer review

7.2.3Reports

7.2.4Popular science publications

7.2.5Congresses, fairs

7.2.6Discursive forms

7.2.7Other

7.3Technology transfer [22]

7.3.1Patents

7.3.2Licenses

7.3.3Start-ups

7.3.4Processes, prototypes, products

Follow-up projects (max. 1 A4 page) [23]

1. Summary

Today, video production and video trading is one of the major commercial activities around the world. Private and public organizations provide the globe with information, education and entertainment on a daily basis. The produced video is delivered to the public either as broadcast video, via wireless or wired (cable) distribution, or as rented/sold video on video tapes and CDs. However, a major problem in the distribution of video is the protection of intellectual rights of the producer. Video producers want on one hand to protect their intellectual rights, and on the other hand to diffuse their production to a public as large as possible. Existing systems, like video coding (pay-TV) provide insufficient protection of intellectual rights, although they allow the video producer a certain control and revenue collection. Any recipient can copy the decoded video and redistribute it without the consent of the rights holder. A recent example is Napster with the distribution of MP3-coded music over the Internet where high-fidelity music can be downloaded in a few seconds completely dissociated from copyright management information. This together with the recent hack of the DVD copy-protection mechanism has awakened content distributors who are becoming demanding for copyright protection mechanisms.

The StreamCom project studied the problems and issues related to the commercialization of streamed information, focusing on video streams. In particular concepts for the commercial distribution of video and the protection of the video producer's intellectual property rights were developed and payment concepts such as pay-per-use based on electronic ticketing and new forms of on-line delivery and bandwidth reservation for life-video were explored. Prototypes developed in the project demonstrated both the concepts and the related problems and issues.

Furthermore, the project developed an e-commerce model for streamed information. The main goal of the modeling part was to specify a model that describes at different level of abstractions how solutions provided by different partners can be integrated in one system. The specification of a system at the high level of abstraction allow for the generalization of the StreamCom model. The general StreamCom model was done with two complementary techniques: role modeling (ICA modeling partner) and Component-based Reference Model for Electronic Commerce (MCM modeling partners).

In the context of the project a start-up company (Betrust Concepts sarl) was set up to commercialize the Enhanced Secure Socket Layer (ESSL) protocol that was partially developed and tested within the StreamCom project.

The analysis and documentation of the community view of media platforms has been jointly refined into a method called “Organizational Design” which has been successfully applied in real world projects of Informationobjects A.G

The StreamCom project work also contributed in the completion of a number of Diploma and PhD thesis.

2. Results

2.1Overview of scientific results

The work in the StreamCom project was done in two parts: the technical part concentrating in the development of the mechanisms for the video commercialization and the modeling part concentrating in the development of the e-commerce model.

2.1.1 Technical Part

For the commercialization of video over open networks, several issues need to be faced and resolved, ranging from infrastructure considerations, like the availability of the required bandwidth and quality of service of the communication channel, to payment mechanisms and author rights protection. In the StreamCom project we investigate several of the related issues namely Video protection, payment mechanisms, bandwidth reservation and quality of service (QoS), as well as contracting issues handling the commercial transaction.

2.1.1.1 Video Protection : The COiN-Video model

The target of the video protection mechanism developed in the StreamCom project was to overcome the most important restrictions posed by “traditional” video protection models, and namely:

Video redistribution protection : In existing mechanisms and models once a subscriber gets hold of the decoded stream, in analog or digital format, he can easily store it, modify it and re-distribute it without the possibility of being easily identified.
Vulnerability of decoding hardware : In existing systems the copy protection mechanism depends to a large extent on a set-top box on the consumer-side. This makes the system vulnerable to attacks on the consumer side.
Scalability : Existing systems providing secure personalized distribution do not scale to serve very large number of consumers.

COiN-Video is a model developed in the StreamCom project for the commercial dissemination of video based on a scalable approach combining copyright protection and copyright enforcement of digital video distribution, and allowing trace-back of each consumer. The basic idea of the model is to provide each consumer with a uniquely identifiable video stream without requiring an individual video stream for each viewer. In the following we present the basic idea of the COiN-Video model as applied to analogue and digital video.

Analog video commercialization using the COiN-Video

The first step of the COiN model for video distribution is to divide each frame of the video into segments. For demonstration purposes we use an example where the video is divided into 6 segments, as shown in Figure 1.

Figure 2. Replicated Video Segments Figure 3. Recomposed Video

Each segment is replicated and each replicate is watermarked with a different watermark. For our example we will use a 6 times replication, as shown in Figure 2. Thus we have in total 36 video segments. Each segment is transmitted as an independent video-segment stream. Each video-segment stream is encrypted with a different key and they are all broadcasted so that they are received by all viewers. The viewer wishing to view the original video will need to reconstruct it by composing different segments. To do so he will need to obtain the decryption keys for a given combination of segments. For our example the user will need to obtain the decryption keys of 6 different video-segment streams (Figure 3). As a result the recomposed video will be characterized by a signature of the 6 watermarks of the different segments. The total number of combinations is NoStreamsNoFrameSegments, and in our example 66 = 46.656. That means that with a total bandwidth of 6 video streams segmented in 6 pieces, we can uniquely identify 46.656 viewers. If the video is segmented into 8 pieces and we replicate again 6 times, then the total number of identifiable viewers is 68 = 1.679.616 !

The basic approach can easily be extended to allow the identification of more viewers without any increase in the bandwidth and without further segmentation of the video, by simply using a different watermark (and encryption) for each field (rather than frame). This way total number of combinations becomes (NoStreamsNoFrameSegments)2, and for our 6 x 6 example it becomes 2.176.782.336!

COiN-Video Model With Digital Video

While the COiN-video model works with uncompressed analog video streams, the most common scenario nowadays is to transmit digital compressed video, like for example MPEG2. There are two ways to apply the COiN video to digital compressed video: the first is to use watermarking schemes that resist compression and proceed in a similar manner as with uncompressed video, and the second is for the cases where the video stream is pre-compressed, as is the case for the majority of commercial broadcasts today.

Although uncompressed digital video is still used in certain cases (ex. post-production processing) the final video is stored in compressed format, and namely today MPEG2 format. In the following we describe the approach for precompressd MPEG2 video, which is the de-facto standard for digital video distribution today and which has been implemented in the context of the StreamCom project.

The first step to applying the COiN model to MPEG video is to separate bulk and significant information of the video stream. The bulk information of the video consists of the part of the video which caries the major percentage of the video information but which is unviewable without the missing part: what we call the significant information of the video. The significant part of the stream is the part in which encryption and watermarking schemes can be applied and are propagated to the rest of the stream in the process of decoding. The idea is to split the MPEG stream into these two parts, with the bulk part carrying more than 90% of the information and the significant part carrying the rest.

Bulk information consists of P and B frames. By definition P and B frames are encoded with respect to reference frames; that is I frames or previously decoded P frames. The lack of the reference I frames make P and B encoded frame information unusable. In order to further reduce significant information we will go to MPEG encoded macroblock level of I frames. Macroblocks consist of luminance and chrominance blocks in the frequency domain. Since high frequency coefficients are not significant without the block’s low-frequency coefficients they can be also included in the bulk information. Thus in our example (and the prototype implementation) the bulk information stream includes the P and B frame information, and the high frequency coefficients of the I frames. Note that other segmentations of the MPEG stream are also possible, depending on the implementation and needs.

Figure 4. COiN-video model with pre-compressed video

The second step is to produce the required number of streams carrying the significant information and apply watermarking and encryption. For this example twelve streams of significant information are produced: two for each segment of the video. A different watermark is applied in each of these streams by a watermarking scheme that works in the low-frequency DCT coefficients chosen. Once the watermark is inserted each stream is encrypted with a different encryption key. At the end of the process twelve separate encrypted streams are produced as well as the bulk-information stream. Each user needs the bulk stream and six significant streams in order to reconstruct the original stream. Figure 5 illustrates the complete process.

Each consumer is required to pay and receive decryption keys in order to access the streams arriving. The keys sold to each user represent a unique combination which is stored into a database together with the user identification. In the example the consumer might receive keys K1, K8, K3, K10, K5, K12 which can only decrypt significant information streams (1, 8, 3 10, 5, 12) respectively. Of course the combination of keys received should be such that it can decrypt complementary streams in order to be able to reconstruct the original stream. Notice that if a user has the decryption keys to decrypt streams 1 and 4, she/he may only receive those significant information streams and not the ones she/he cannot decrypt. This way the bandwidth required on the consumer side does not depend on the streams served by the server. This can be achieved on Internet by the IP Multicast protocol which allows a user to select the multicast group(s) she/he wants to subscribe. Once the consumer receives the keys to decrypt “her/his” combination of streams, the system has to reconstruct the original stream from the bulk information and the separate significant information stream segments.

2.1.1.2Video delivery

The quality of a video transmission depends on different parameters. Most important are the resolution and the number of frames per second. For example, a frame rate of 25 frames per second is required for a good quality of a live TV video-transmission. In the case of stored video transmission as it is investigated in StreamCom the required bandwidth for the video is a priori fixed and depends on the compression algorithm. The bandwidth must be available at the time of the tranmsmission, because video stream adaptation is not possible in real-time.

However, bandwidth is still a problem in both the Internet backbone and the access networks. Our approach for supporting high quality video delivery is to guarantee the required bandwidth using reservation mechanisms. In our case, we use Differentiated Services (DiffServ) as a scalable mechanism for Quality-of-Service (QoS) support in the Internet.

StreamCom video transmission is based on broadcast / multicast methods. In the Internet this is supported by IP multicast. In this case, the sender transmits a single packet copy to a multicast address, i.e. along the multicast distribution tree for the corresponding multicast group. To receive the data, the users / end systems must just join the appropriate multicast group. However, the problem is that any end system can join this multicast group, because there is no admission control for joining IP multicast groups.

For bandwidth reservation, it is necessary to contact the Internet Service Provider (ISP) and ask for the desired bandwidth of an (aggregated) flow. In the StreamCom scenario an ISP is represented by a QoS broker, which has two functions. First, it must handle the QoS requests received from the broker component that is responsible to ask for QoS on behalf of the customer and, second, it must control / manage the network it is responsible for.

To send a request to the QoS Broker, the Broker Signaling Protocol (BSP) is being used. This protocol has initially been developed for the communication of collaborating QoS brokers, but in a simpler form, it can also be used to request the service from a component representing the end customer such as the broker.

However, the integration of DiffServ and IP multicast introduces some problems.

As mentioned above every end system can join the multicast group used for video delivery, because there is no admission control. The problem is that if QoS is enabled for the entire multicast group, all members will benefit from it, but only some clients will pay for it. All other clients who joined the multicast group without having a ticket for receiving the video, i.e. all non-paying clients, will increase the total costs for delivering the video over the multicast tree, i.e. the costs for the paying users.
Assume a multicast tree with DiffServ support on all its branches. If a new member joins the multicast group not enough bandwidth might be available on the branch to which this new member is connected. If the new member is a paying client, then he has the right to join the StreamCom service. However, if no bandwidth on the new branch is available, then we have the problem that the contract between the ISP and the Content Server is broken and the QoS for the whole multicast group is compromised.

In order to solve these problems two mechanisms are needed. For the first problem control mechanisms to distinguish between paying clients and other members of the multicast group are needed. If the location of the paying clients is known, we can configure the DiffServ routers in such a way, that only branches with paying clients will benefit from DiffServ while the others will not. In some way we need a kind of admission control to the multicast group.

To solve the second problem, we need a mechanism to check the available bandwidth on the branches of a multicast tree. This can be achieved in two ways. First, we use the information from the ISP about its network topology. The QoS broker can check whether the requested bandwidth of the new branch is available. If it is, then the new branch can benefit from DiffServ. An alternative solution is to check the available bandwidth by injecting traffic between the content server and the client. The client counts the received / marked packets and estimates the available bandwidth from that. If it is too low, then the client does not join the StreamCom service.

We developed concepts and mechanisms allowing the negotiation and setup of the desired Quality-of-Service of audio/video streams with the input form a content provider, and the set up of multicast sessions with QoS support across multiple ISP networks with automatic elimination of unneeded multicast tree branches. The developed system allows clients to join and leave dynamically during a session using active or hybrid active/passive measurement techniques for admission control. The approach is related to the so-called measurement based admission control. Finally the delivery system allows to scalably transport authentication information from client systems to the upstream ISPs, in order to ensure guaranteed service for paying customers and prohibit waste of reserved bandwidth resources for unauthorized clients at the same time.