20070705 ANEVIA VoD Solution Overview - TV Digital

Anevia VOD solution 

Architecture Overview 

This document may neither be reproduced nor communicated to a third party without written authorisation from ANEVIA


Architecture Overview 1/2 



Table of contents 

1 VOD SOLUTION OVERVIEW............................................................................ 4 

1.1 GENERAL OVERVIEW ........................................................................................ 4 

1.1.1 Platform Overview .................................................................................. 4 

1.1.2 Main components .................................................................................. 5 

1.1.3 Functionalities ....................................................................................... 5 

1.2 VOD PLATFORM SPECIFICATIONS ............................................................................ 7 

1.2.1 Scheme of a VoD network....................................................................... 7 

1.2.2 Supported architectures ......................................................................... 9 

1.2.3 Load balancing .................................................................................... 10 

1.2.4 Fail over ............................................................................................. 11 

1.2.5 Streaming capacity extension................................................................. 12 

1.2.6 Storage capacity extension .................................................................... 12 

2 VOD SERVER DESCRIPTION (TOUCAN) ......................................................... 14 

2.1 SYSTEM INTERFACING ...................................................................................... 14 

2.2 HARDWARE ................................................................................................. 14 

2.2.1 Storage.............................................................................................. 15 

2.3 OS............................................................................................................ 15 

2.4 SYSTEM MONITORING....................................................................................... 15 

2.5 HIGH AVAILABILITY ......................................................................................... 16 

2.6 INTERFACES.................................................................................................. 16 

2.6.1 RTSP support...................................................................................... 16 

2.6.2 Multimedia Formats support.................................................................. 16 

2.7 CONFIGURATION............................................................................................. 17 

2.7.1 WEB interface..................................................................................... 17 

2.7.2 SSH prompt access ............................................................................. 17 

2.8 SPECIFIC CHARACTERISTICS................................................................................ 18 

2.8.1 Trick modes........................................................................................ 18 

2.8.2 Content validating tool .......................................................................... 18 

3 SERVICE MANAGER (APALIS) ...................................................................... 19 

3.1 SYSTEM INTERFACING ...................................................................................... 19 

3.2 HARDWARE ................................................................................................. 19 

3.3 OS............................................................................................................ 19 

3.4 SYSTEM MONITORING....................................................................................... 19 

3.4.1 SNMP................................................................................................ 20 

3.4.2 Web services...................................................................................... 20 

3.5 HIGH AVAILABILITY.......................................................................................... 20 

3.6 INTERFACES.................................................................................................. 20 

3.6.1 Physical interfaces ............................................................................... 20 

3.6.2 RTSP support...................................................................................... 20 

3.6.3 XML .................................................................................................. 20 

3.6.4 Conditional Access Rights ..................................................................... 20 

3.7 CONFIGURATION............................................................................................. 21 

3.7.1 Log management................................................................................. 22 




4 SECURITY POLICY ...................................................................................... 22 

5 APPENDICES ............................................................................................. 23 

5.1 APPENDIX A: COMPATIBILITIES............................................................................ 23 

5.1.1 Encoders............................................................................................ 23 

5.1.2 CAS & DRM systems ........................................................................... 23 

5.1.3 STB ................................................................................................... 23 

5.1.4 Middlewares ....................................................................................... 24 

5.2 APPENDIX B: VOD SERVER PERFORMANCES ............................................................ 25 

5.3 APPENDIX C: REFERENCES ................................................................................ 26 



1 VOD Solution overview 

1.1 General Overview 

1.1.1 Platform Overview 


ANEVIA’s platform is a complete and modular solution for the VoD service from 

content ingest to content availability for the end-user. 

It relies on different components: 

• Best server selection for a given end user (APALIS Manager) 

• Streaming (Toucan) 

• High-availability on the streamers (APALIS Manager) 

Middleware 

Apalis 

Toucan 

HTTP 

Figure 1 – Platform overview 


This document may neither be reproduced nor communicated to a third party without written authorisation from ANEVIA 

RTSP 

Video

1.1.2 Main components 

1.1.3 Functionalities 

VOD Solution Elements 


APALIS Manager 

• Network Control Point & Supervision 

• Supervises the Streaming Servers 

• Hosts the RTSP server (STB interface) 

• Manages High Availability & Load Balancing 

• Drives Content Distribution 

TOUCAN streaming servers 

• Ingest & Stream contents 

• RTSP server as an autonomous server 

The ANEVIA platform on On-Demand services supports the following features: 

• Video on demand 

• Network PVR 

• TV on Demand 

• Network Time Shifting (Catch up TV) 

• Trickmodes MPEG2/MPEG4 AVC 

• Unlimited FF/FR speeds 

• Negligible overhead data due to the use of trick index instead of trick 

files, unrelated to the desired number of FF/FR speeds. 

• Play restart at the exact Pause position 

• SNMP traps and syslog 

The ANEVIA solution was originally designed as a Network Time Shifting 

solution and the whole architecture was designed with this idea in mind. 

Particularly, streaming of a content can start immediately at ingestion (thanks 

to the trick index mechanism), and ingestion does not significantly impact the 

streaming performances. 

The ANEVIA solution is a Linux-based software solution which can be ported 

over different market standard hardware platforms to comply with various 

requirements such as small PoPs for example. 

Not all the above elements are necessary. They are separate elements which 

can be part of the overall solution depending upon the requirements. 



Toucan 

Toucan 

Apalis 

Managing 

Configuration RTSP 

Monitoring 

MPEG2-TS 

Video 

Figure 2 – Basic principle 


In that architecture, no specific software client is required in the set top box. 

This enables the operator to change easily its set top box provider with almost 

no additional cost for development. 


This document may neither be reproduced nor communicated to a third party without written authorisation from ANEVIA 

STB

1.2 VoD platform specifications 

1.2.1 Scheme of a VoD network 


ANEVIA uses clusters various notions to describe the architecture of a 

platform: 

• Streaming cluster: a set of TOUCAN (VoD servers) 

• Deployment cluster: a set of TOUCAN 

• Management cluster: a set of APALIS (management servers) 

• Farm: the association of some streaming clusters managed by a 

management cluster 

A TOUCAN could be associated to multiple deployment clusters or multiple 

streaming clusters. Also a cluster could be composed of a unique server. 

BO 

Webservice 

Billing server 

Access control 

Anevia farm 

Cluster manager 

Load balancer Anevia protocol 

Cluster (streaming servers) 

Storage capacity 

RTSP server 

RTSP 

session 

SNMP Listener 

STB STB STB STB 

Figure 3 – Clusters in a farm 





H264/MPEG2TS/UDP 




All STB could address the management cluster to ask for a service. The 

management cluster is than in charge of dedicated a link from the STB to a 

VoD server depending on different criteria: 

• Geographical distance (first priority) 

• Content availability on the VoD server (read the hybrid architecture 

paragraph for more explanations) 

• Load of the server 

• Load of the network 

Deployment cluster 

A deployment cluster has two possible deployment policies: 

• All or a part of the contents must be available on all VoD servers of a 

cluster, 

• All or a part of the contents must be available on a cluster dispatched on 

all VoD servers. 

However some servers of the cluster could be used as a “cache” i.e. a part or 

the totality of its storage could be dedicated to dynamic content loading. 

For example if a frequently requested content is not available on the nearest 

VoD server from the asking STB, this latter is immediately deployed if the 

server is not overloaded. 

If the storage area of this VoD server is nearest full, less requested contents 

are deleted from the server to begin the upload of the requested content. 

The “cache” mode allows beginning the streaming of the content during the 

ingestion. Of course the usage of the trick modes is limited on the already 

ingested parts of the content. 

Streaming cluster 

Streaming cluster insures the availability and the quality of the content 

streaming over the network. 

Each cluster has a limited storage capacity and streaming bit rate capacity. 

The access priority to a specific cluster is defined in first through the 

geographic proximity from the STB. 

ANEVIA recommends the use of a streaming cluster by POP (or NRA). 

Shared servers 

Storage/streaming/ingestion capacity constraints are defined for each server. 

The priority of each service is managed through this order: 

1. Contents high availability, 

2. Contents persistency in each cluster (even after a failure), 

3. New strategies application, 



4. Add of new contents. 

1.2.2 Supported architectures 


ANEVIA’s solution supports several architecture types which can evolve in time 

for one to another. 

Centralized architecture 

• High streaming capacity over a geographical area 

• High storage capacity 

• Powerful and cumbersome hardware 

Figure 4 – Centralised architecture 

Decentralized architecture (distributed) 

• Limited streaming capacity (limited footprint at the PoP) 

• Limited storage capacity 

• Compact hardware 

Figure 5 – Decentralized architecture 



Hybrid architecture 


• Made of central content servers at network nodes and cache servers at 

the small PoPs 

1.2.3 Load balancing 

Figure 6 – Hybrid architecture 

Streaming/Deployment clusters 

The APALIS server checks in real-time the load of each TOUCAN composing a 

cluster. Using this information the APALIS is able to manage the load balancing 

on the entire set of TOUCAN server. 

The load balancing is done through specific equipment without any “REDIRECT” 

connection mapping. This method accelerates the connection to the stream 

and simplifies the protocol of connection. 



90% 

90% 

30% 

VOD 1 

VOD 2 reported to VOD 3 STB 

VOD 3 

Figure 7 – RTSP REDIRECT vs. ANEVIA 


Management clusters 

The solution of load balancing is perfectly scalable for a management of several 

hundreds of thousand STB. Indeed, the load balancing is automatic if the 

number of customers requires it over the APALIS managers: each TOUCAN 

server supports easily to be piloted by several APALIS; We define in that case 

a management cluster by geographical zone, and the load balancing could be 

made using the DNS resolution. 

1.2.4 Fail over 

4 / overloaded, 

reported to VOD2 

5 / Request 

3 / Request 

6 / Overloaded, 

7 / Request 

8 / Streaming 

ANEVIA Solution 

90% 

90% 

30% 

VOD 1 

VOD 2 

VOD 3 

1 / Asks for the server list 

2 / Send of the server list 

Other solutions 

2 / Request 

Apalis 

3 / Streaming 

1 / Request 

TOUCAN fail-over management 

The ANEVIA’s solution proposes a new and reliable technology to manage the 

fail-over of a streaming server. When a breakdown is detected, or when the 

STB 




server is unreachable all streams handled by this server are automatically 

resend by the most appropriate server of the current streaming cluster. 

This functionality is totally independent from the STB and relies only on the 

platform. 

According to the nature of the breakdown (network, hard disk, stop of the 

server) and in some dangerous cases (break of the IP link with the backbone, 

equipment failure, not detectable breakdown by the system as the beginning of 

disk crashing), this can possibly results in an interruption of some seconds. 

Once the fail-over done, the stream restarts at the same position and in the 

same state. 

The main variables of detection of breakdowns are manageable. 

APALIS fail-over management 

The APALIS are used in 1:1 redundancy. In case of a master APALIS failure, 

the slave one starts over immediately. The VRRP protocol is used to implement 

this redundancy. 

1.2.5 Streaming capacity extension 

If specific needs for streaming capacity are necessary, the operator may 

subscribe to additional streaming licences to use the full capacity of the 

hardware already deployed. 

If some bottlenecks exist in the network, or if more bandwidth is needed for 

some geographical areas, 2 possibilities are offered: 

Add a TOUCAN server 

This new server would simply be added to the list of Apalis’ managed severs. 

Automatically, streaming capacity will be increased, and the content will be 

duplicated. 

Change the hardware platform 

By using a more powerful hardware for the VoD platform, the total capacity 

would automatically be increased. ANEVIA’s software can be easily modified to 

run on different hardware types: powerful servers for central nodes and light 

servers for small PoPs. ANEVIA mainly works with IBM, Intel and HP. 

1.2.6 Storage capacity extension 

If the volume of the content to be stored is more than the capacity of the 

deployed solution, different solutions are offered to the operator: 

Add a TOUCAN server 

As each Toucan has its own storage capacity, adding a server would increase 

the total storage capacity. 




Change the hardware platform 

It is naturally possible to use some hardware with a larger storage capacity 

(either by changing the full system or by adding an external storage device). In 

this case, no additional license is to be purchased to ANEVIA. 

Move to a hybrid architecture 

Depending on the capability to reorganize all POP, the choice of hybrid 

architecture allows to dispatch the content storage between each secondary 

area – 20% of the contents – and a primary area – 80% of the contents using 

more equipments or more storage capacity. 



2 VoD server description (TOUCAN) 


More effectively than certain architectures, there is no necessity in the 

ANEVIA’s solution of maintaining an operating system. The product proposed by 

ANEVIA is in the form of Disc on Module (DOM) containing the software set i.e. 

the operating system and the application software. 

2.1 System interfacing 

The streaming servers are not directly connected with the STB. The TOUCAN 

servers are in charge of the ingestion and the streaming of the UDP and RTP 

streams. The TOUCAN servers are totally managed by the APALIS manager 

with which they communicate by using a protocol with weak latency. The 

APALIS manager contains the RTSP server and manages information 

exchanges between the STB and the TOUCAN server. 

2.2 Hardware 

TOUCAN servers are proposed in two flavours: the first one the TOUCAN 100 

is limited to 60 simultaneous streams and the TOUCAN 500 which is limited to 

100 simultaneous streams. 

Until the end of this document the TOUCAN server will refer to the TOUCAN 

500 server based on a X3650 IBM hardware. 

Toucan 500 Server 

• x3650, Dual-Core Intel Xeon 5160 3.00 GHz/1333MHz 

• 8 GB RAM (4x2GB) PC2-5300 667 MHz ECC Chipkill DDR2 

• NetXtreme II 1000 Express G Ethernet Adapter 

• 6 discs 300GB Hot-Swap 3.5" 10K RPM Ultra320 SAS HDD 

Toucan 100 Server 

• 1U Appliance 

• Anevia typical hardware for 60 simultaneous streams 

• Up to 3 discs 750GB SATA 

Ambient & Physical 

• Operating Temperature: 10°C – 35°C 

• Temperature (Server Off): 10°C to 43°C 

• Temperature (Shipping): -40°C to 60°C 

• Relative Humidity: 8% - 80% 

• Width: 443.6 mm 

• Depth: 698.0 mm 

• Height: 85.4 mm 



2.3 OS 


Recommendations 

The adaptation and the optimization of the TOUCAN server on the X3650 

hardware had required 4 weeks of work between IBM and ANEVIA engineers. 

You can contact the project leader to have more information about this product 

integration: 

2.2.1 Storage 

Contact available on request 

The RAID system used – software RAID - is 

RAID 0 

an assembly of RAID 0 on RAID 5. The 

RAID 5 

RAID 5 

optimal size of the blocks of RAID for the 

Disk1 Disk2 Disk3 

Disk1 Disk2 Disk3 

X3650 server was determined further to 

benchmarks made with the experts of IBM. 

The choice of a software RAID is conditioned by the fact than most of the RAID 

card material manage sizes of memory blocks adapted to databases and not to 

streaming of voluminous video files. 

Both RAID levels are managed by our modified Linux kernel to optimize hard 

disks accessing. 

In the appendix B, you can check the results of our performance benchmarks. 

These tests had been also realized in the case of defective hard disk units. 

TOUCAN servers are based on a basic Linux kernel optimized for the specific 

needs of the streaming. 

HAL Layers of the hard disk were modified to adapt itself to the constraints of 

writing/reading disk appropriate for the nPVR and for the VOD applications. 

The network layer arranges a packet dispatcher for regular streams (low jitter) 

and high bit rates. 

The IP stack was adapted to the unicast streaming of video to obtain the best 

performances removing all unused tasks of the stack. 

2.4 System monitoring 

All TOUCAN servers are managed by the APALIS manager. 



2.5 High Availability 

TOUCAN server uses redundancy mechanisms: 


• All disks are mounted in double RAID 

• OS and software applications are embedded on a DOM which allows to 

boot even without any available had disk drives inside 

• Double power food 

When a breakdown is detected, or when the server is unreachable all streams 

handled by this server are automatically resend by the most appropriate server 

of the current streaming cluster by guaranteeing: 

• Restarting at the same point in the stream 

• Restarting in the same state (play/pause/fast forward/fast reward) 

2.6 Interfaces 

Ethernet interfaces are Gigabit Ethernet (RJ45). The number of Ethernet 

interfaces depends on the network topology and on the network bandwidth 

constraints. 

TOUCAN server can dispose of: 

• N streaming interfaces depending on the maximum of bandwidth 

required 

• M streaming interfaces reserved for redundancy 

• 1 interface reserved for the management channel 

This Ethernet interface mapping is totally dynamic. 

2.6.1 RTSP support 

TOUCAN server exchanges directly with the APALIS Manager using RTSP. 

2.6.2 Multimedia Formats support 

MPEG2-TS transport over UDP or RTP is implemented for MPEG-2 and MPEG- 

4 SD/HD video codecs. TOUCAN servers can stream and store simultaneously 

both SD and HD streams encoded with MPEG-2 and MPEG-4. 



2.7 Configuration 


TOUCAN server can be configured using these both interfaces without the use 

of an APALIS manager: 

2.7.1 WEB interface 

The WEB interface allows all operations: 

• Access server status 

• FTP server activation 

• Show used bandwidth 

• Show content inventory 

• HDD, RAID and network drive configuration 

• IP configuration 

• NTP server configuration 

• Logs visualization and configuration 

• Firmware upgrade operation 

• Built-in RTSP server activation 

• SNMP activation 

2.7.2 SSH prompt access 

Figure 8 – TOUCAN administration interface 

Through the prompt command line in SSH, all these operations are allowed: 

• Access server status 

• FTP server activation 

• Show content inventory 

• IP configuration 

• NTP server configuration 

• Firmware upgrade operation 



2.8 Specific characteristics 

2.8.1 Trick modes 


The system generates "trick indexes" during the ingestion to allow trick modes 

even if the file is not totally uploaded (typical case: nPVR). When other solutions 

use “trick files” which required a lot of disk space, “trick indexes” do require 

little disk space. 

This system optimizes the disk usage maintaining the server performances. 

Advantages: 

• Disk space optimization 

• unlimited range of speeds for reading/forward/reward 

• No monopolization of the CPU during the ingestion 

• Trickplay activation without any delay in nPVR and nTS usage 

2.8.2 Content validating tool 

An online validating tool is available to check a MPEG-2 TS stream before any 

ingestion. Using it before and after the encryption allows checking if the 

CAS/DRM encryption does not modify the stream validity for the streaming 

and the use of trick modes. 



3 Service manager (APALIS) 


THE APALIS is the coordinator of the VoD network. Its configuration contains 

the list of the streaming clusters and of the deployment clusters as well as 

their properties. The APALIS manager is responsible for the load balancing, for 

the high availability and for the fail-over policy. It guarantees a breakdown is 

transparent for the final customer; the availability of the service and the quality 

of streaming are then also guaranteed. 

The APALIS manger is the gateway of the VoD network. It allows to consult the 

history of any session and clusters/servers state. 

3.1 System Interfacing 

APALIS manager is the interface of connection of the STB. It manages the 

state of all the RTSP sessions running on its farm of clusters. Thanks to the 

connection maintained with every streaming server, it insures the availability of 

the service and the access of all actions through the STB. 

3.2 Hardware 

3.3 OS 

Apalis Manager Server 

• x3650, Dual-Core Intel Xeon 5140 2.33 GHz/1333MHz 

• 2 GB RAM (1x2GB) PC2-5300 667 MHz ECC Chipkill DDR2 

• NetXtreme II 1000 Express G Ethernet Adapter 

• No discs (DOM only) 

• Gigabit Ethernet (RJ45) network interfaces 

Ambient & Physical 

• Operating Temperature: 10°C – 35°C 

• Temperature (Server Off): 10°C to 43°C 

• Temperature (Shipping): -40°C to 60°C 

• Relative Humidity: 8% - 80% 

• Width: 443.6 mm 

• Depth: 698.0 mm 

• Height: 85.4 mm 

APALIS manager is based on a Linux kernel embedded on a DOM. 

3.4 System monitoring 

APALIS manager allows to access these different interfaces: 

• Deployment/Streaming clusters configuration 

• Contents library checking 



• History of ingestion/streaming sessions 

• Servers state checking (Bandwidth, load, system, etc.) 

• Content ingestion driving 

3.4.1 SNMP 


The solution can be interfaced with a centralized supervision system using 

SNMP traps and MIB. All ANEVIA equipments indeed has a SNMP interface, 

the MIB is available on the support site (http://support.anevia.com) 

3.4.2 Web services 

Some web services are called at the beginning and the end of a streaming to: 

• Count all VOD requests 

• Write an history 

• Calculate statistics on the service 

• Check each user rights to access a specific service 

3.5 High availability 

APALIS manager uses redundancy mechanisms: 

• No hard disk drive 

• OS and software applications are embedded on a DOM 

• Double power food 

• Redundant Ethernet card (bonding activate in the Linux kernel) 

3.6 Interfaces 

3.6.1 Physical interfaces 

The number of interfaces is defined according to the constraints of bandwidth 

and the network topology. Generally, two interfaces are enough for assuring 

the redundancy. 

3.6.2 RTSP support 

APALIS manager embeds a RTSP server respecting the RFC2326 standard. 

3.6.3 XML 

An API XML is proposed to access all monitoring information. 

3.6.4 Conditional Access Rights 

A web service is also installed on APALIS manager to double check the access 

control level. 



3.7 Configuration 


As for the TOUCAN server, the configuration can be managed either through 

the WEB interface or through the SSH prompt. 

Here are some examples of the web interface menus: 

Figure 9 – Add of a TOUCAN server in a farm 

Figure 10 – Load balancing monitoring 



3.7.1 Log management 


Furthermore, in its permanent regards over opened standards, ANEVIA 

proposes exporting in the form of "network syslog" all the logs, the messages 

of information and alerts from all equipments of the solution. 

4 Security policy 

All ANEVIA equipments are designed to guarantee the security of the solution: 

• Two level of management are available in all interfaces of the products 

• All accesses are protected by password 

• Command prompt interface secured through ssh 

• STB connecting network and management network are split 

(internal/external) 

• Communication between TOUCAN-APALIS are limited by IP filtering 

• TOUCAN server only responds on IGMP protocol on the external network 

• APALIS manager only responds on IGMP and RTSP protocols on the 

external network 

The RTSP interface of the APALIS manager is secured. 



5 Appendices 

5.1 Appendix A: Compatibilities 

5.1.1 Encoders 


ANEVIA’s VoD servers are totally compliant with H.264 streaming. All these 

encoders have been validated to be used with an ANEVIA VoD solution: 

• Tandberg 

• Harmonic 

• GrassValley 

• Terayon 

• Allegro 

• Ateme 

• Envivio 

• MainConcept Encoder 

5.1.2 CAS & DRM systems 

All these CAS or DRM systems are currently fully supported: 

• Verimatrix 

• NDS 

• Latens 

• Irdeto 

These CAS are partially supported: 

• Viaccess 

• Widevine 

• SecureMedia 

The Nagra-IP CAS compliance is theoretically validated. Real tests are running. 

5.1.3 STB 

ANEVIA’s streaming servers has been validated – in particular for the trick 

modes compliancy – with: 

• SAGEM 

• AMINO 

• KREATEL (MOTOROLA) 

• TILGIN 

• NETGEM 



5.1.4 Middlewares 


ANEVIA’s streaming servers has been also validated and integrated with a wide 

range of middlewares: 

• Minerva Networks 

• Quative 

• iStreams 

• Eona 

• Vianeos 

• Northport 

• Nordija 

• Ortikon 

• HTTV 

• Netris 

• Dreampark 

• EasyTV 

• Zygnal 

• eScentra 

• BeeSmart 

• ABS 



5.2 Appendix B: VoD server performances 


For a specified hardware/software configuration, streaming performances rely 

on some parameters: 

• The media library [750 movies] 

• Usage scenario, here [70%] of streams are blockbusters, so [70%] of 

the bandwidth is used for the consumption of 10% of the contents. 

Some movies can be stored in RAM 

• The size of streaming UDP packets [1316 octets] 

• Number of ingested streams in real-time [2 streams] 

• Failure of one hard disk during the streaming 

• Size of the hard disk drive and rotating speed [300 GB, 10 kRPM] 

900 st . 

800 st . 

700 st . 

600 st . 

500 st . 

400 st . 

300 st . 

200 st . 

100 st . 

0 st . 

Max streams / Upload 

0 1 2 3 4 5 6 7 8 9 10 

U pl oa ds ( N b) 

Figure 11 - Performances 


75% blockbust ers 





5.3 Appendix C: References 

Hardware IBM 

Set-top boxes SAGEM 

Middleware interne Alice 

DRM VERIMATRIX 

Architecture hybride 

Project planning 


August 2006 ANEVIA is chosen for the VoD platform. 

September 2006 Verimatrix CAS integration (15days) 

October 2006 SAGEM STB integration (mpeg4, trickmode et fail-over) 

(2months) 

November 2006 Alice Middleware Integration (15days) 

Beta Testing ran on the beginning of November and the Commercial use on 

December, 14 2006. 

Customer notes 

• « Le choix d’ANEVIA s’est fait essentiellement sur la capacité de cette 

jeune société à accompagner de manière très proche Telecom Italia 

France tout au long de son déploiement, et sur sa capacité technique à 

faire évoluer ses produits pour proposer une solution toujours à la pointe 

de la technologie […] Je suis satisfait de ce choix.» 

• « La plateforme déployée offre une stabilité et une qualité de service qui 

permet d’atteindre 95% de satisfaction client. » 

Contact 

Alice (Telecom Italia France) 




Hardware INTEL 

Project planning: VOD/nPVR 

November 2005 First VOD testing 

January 2006 Latens CAS integration (15days) 

June 2006 First nPVR testing 

September 2006 Middleware and STB integration (nPVR) 

November 2006 CAS and nPVR testing (2months) 

Customer notes 


• « Alcom a commencé à travailler avec ANEVIA sur sa gamme de produit 

Flamingo. Convaincus par le sérieux de la société et la stabilité des 

produits, nous avons consulté ANEVIA sur l’appel d’offre VOD. 

L’architecture de la solution nous a particulièrement séduit et ANEVIA 

était la seule solution capable d’offrir un vrai service de nPVR et 

nTimeShifting distribué.» 

• « L’interopérabilité en nPVR avec le solution ANEVIA et la solution CAS 

Latens a été menée dans les temps. Les services nPVR et VOD ont été 

lancés fin 2006 et je suis pleinement satisfait par le choix de la solution 

ANEVIA. La solution supporte aujourd’hui le nTimeShifting qui devrait être 

déployé dans un avenir prochaine ». 

Contact 

Alcom (Finlandia) 

Set-top boxes KREATEL (Motorola) 

Middleware interne NORTHPORT 

CAS LATENS 

Architecture décentralisée

20070705 ANEVIA VoD Solution Overview - TV Digital

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?