IPTV Design Document The Pearl Qatar

IPTV Design Document
The Pearl Qatar
TPQ-GP55-DOC-0126
Version 0.7
Contributors
The contributors to this document are noted here and may be contacted regarding any
changes or to discuss other aspects of the content.
Contact Information
Name
Organization
Email Address
Andre Mendes
Widevine
[email protected]
Karel Debrouwere
Scientific Atlanta
[email protected]
Kashif Rashid
Cisco Systems
[email protected]
Jim White
Scientific Atlanta IP STB’s
[email protected]
Marco Bonomi
Minerva Networks
[email protected]
Robert Giacomuzzi
Cisco/Scientific Atlanta
[email protected]
Simone Arvigo
Media Power SeaChange
[email protected]
Venkataramanaiah R
Mannai
[email protected]
Silju Pillai
Mannai
[email protected]
Srihari Moningi
Mannai
[email protected]
Jeby Mathew Philip
Mannai
[email protected]
TPQ-GP55-DOC-0126
Version 0.7
2
Table of Contents
1. Introduction---------------------------------------------------------------------------------------- 5
2. Objective of this Project ------------------------------------------------------------------------- 5
3. Scope of Work (SoW) ----------------------------------------------------------------------------- 5
3.1 IPTV Logical Design -------------------------------------------------------------------------------------------- 6
4. Scientific Atlanta ----------------------------------------------------------------------------------- 7
4.1 IPTV Head-End System Description------------------------------------------------------------------------ 7
4.1.1 Sequential traffic flow from QSPK to IP Stream------------------------------------------------------ 7
4.1.2 Satellite Dish Farm and L band Signal Distribution system. --------------------------------------- 8
4.1.3 IPTV Head end System. ----------------------------------------------------------------------------------- 11
4.2 System Description ------------------------------------------------------------------------------------------- 14
4.2.1 MPEG2 Encoder- Model D9022. ------------------------------------------------------------------------ 14
4.3 MPEG2 vs. MPEG4 -------------------------------------------------------------------------------------------- 17
4.4 Major Assumptions ------------------------------------------------------------------------------------------- 18
4.4.1 Headend Topology solution------------------------------------------------------------------------------ 18
4.4.2 Scenarios ----------------------------------------------------------------------------------------------------- 19
4.5 Set Top Box Basic Information ----------------------------------------------------------------------------- 21
4.6 Network Management -------------------------------------------------------------------------------------- 22
5. Minnerwa Networks ----------------------------------------------------------------------------- 23
5.1 Services and Architecture overview ---------------------------------------------------------------------- 24
5.2 Technologies implemented and main components -------------------------------------------------- 26
5.2.1 Oracle DB 10g----------------------------------------------------------------------------------------- 27
5.2.2 Oracle Application Server 10g------------------------------------------------------------------- 27
5.2.3 Linux ------------------------------------------------------------------------------------------------------ 27
5.2.4 Java ------------------------------------------------------------------------------------------------------- 27
5.2.5 Swift MQ JMS ----------------------------------------------------------------------------------------- 28
5.2.6 Swing ----------------------------------------------------------------------------------------------------- 28
5.3 The Database Server ----------------------------------------------------------------------------------------- 31
5.4 The BackOffice Server --------------------------------------------------------------------------------------- 31
5.5 The Application Server--------------------------------------------------------------------------------------- 32
5.6 The Boot Server ----------------------------------------------------------------------------------------------- 32
5.7 Servers and Platforms --------------------------------------------------------------------------------------- 33
TPQ-GP55-DOC-0126
Version 0.7
3
6. Widevine Technologies ------------------------------------------------------------------------ 34
6.1 Widevine Cypher: A Comprehensive Security Solution---------------------------------------------- 34
6.2 Conditional Access and Digital Rights Management ------------------------------------------------- 35
6.3 Renewable Security ------------------------------------------------------------------------------------------ 36
6.4 Protection for Untrusted Platforms ---------------------------------------------------------------------- 36
6.5 Application-Level Encryption------------------------------------------------------------------------------- 37
6.6 Widevine Cypher Overview -------------------------------------------------------------------------------- 38
6.6.1 Widevine Cypher Certificate Authority --------------------------------------------------------------- 39
6.6.2 Widevine Cypher Broadcast ----------------------------------------------------------------------------- 40
7. SeaChange ----------------------------------------------------------------------------------------- 44
7.1 Axiom Core Functions---------------------------------------------------------------------------------------- 45
7.2 VOD architecture: Axiom command centre and the VOD servers -------------------------------- 48
7.3 Features --------------------------------------------------------------------------------------------------------- 51
8. Networking Part of IPTV ----------------------------------------------------------------------- 53
9. Booting Process --------------------------------------------------------------------------------- 57
10. References --------------------------------------------------------------------------------------- 58
TPQ-GP55-DOC-0126
Version 0.7
4
1. Introduction
The purpose of this document is to provide a detailed design about the IPTV
implementation in Pearl Qatar Island, integrated with five various vendor components,
namely, Cisco, Scientific Atlanta, Minerva, Widevine, and SeaChange with a proven
ecosystem
2. Objective of this Project
The objective of this project is to design and implement an Ethernet to the
Home/Business (ETTx) access network to the PEARL Residential/Business customers.
The main criteria is to have a converged IP network where the network shall be able to
support multiple services such as Internet, VoIP, IPTV etc, on a single connection.
3. Scope of Work (SoW)
This document defines the Detailed Design of the IPTV solution provided to “The Pearl
Qatar Project”. IPTV Solution is integrated with four different IPTV vendor components:
1. Scientific Atlanta, 2. Minerva Networks, 3. Widevine, and 4. SeaChange
1. Scientific Atlanta deals with the Head End System and IP STB
2. Minerva Networks deals with the Middleware
3. Widevine deals with Content Security (CAS)
4. SeaChange deals with Video on Demand (VoD)
This document details only the IPTV solution design. The design details that shall
support the IPTV solution will be provided in the Data Center and WAN Services Module
Detailed design document. The Network requirements for the IPTV solution are gathered
and documented in TPQ-GP55-DOC-0119 and hence is not discussed as well in this
document.
TPQ-GP55-DOC-0126
Version 0.7
5
3.1 IPTV Logical Design
Logical Diagram
A proven/tested ecosystem has been considered and built for the Pearl IPTV network.
The logical diagram for IPTV network is shown above. As per this diagram, the IPTV
Network is segregated into separate VLANs and discussed in the Networking Part of
IPTV.
TPQ-GP55-DOC-0126
Version 0.7
6
4. Scientific Atlanta
4.1 IPTV Head-End System Description
4.1.1 Sequential traffic flow from QSPK to IP Stream
1.
Receives L-band QPSK signal from Satellite using the Dishes installed at the
dish farm.
2.
LNB’s connected to the dishes will convert these QSPK signal to IF and send to
Amplifiers for boosting the signal before splitting it and sending to multiple
devices.
3. IF splitters will split these signals to multiple IF feeds to feed IRD's, and to Pay
channel decoders using IF splitters and L-band test point.
4. The IRD will tune a particular transponder and pulls out the contents in ASI
format.
4.1
The ASI output from IRD goes to ASI splitter and further fed to main DCM
and redundant DCM.
4.1.1
DCM will further process the selected channel from the transponder to IP
format (MPEG2 transport) and send it to the distribution network.
4.2
Again output of some IRD’s goes to Transport Stream Descrambler to
descramble the scrambled channels and send to DCMs.
4.2.1
DCM will process the selected channel from the transponder to IP format
and send it to the distribution network
5. Pay Channel decoder gets IF signal and is tuned to one channel according to the
smart card subscription from the channel provider, which is inserted in it.
5.1
Composite Video & analog audio signals from Pay Channel Decoders
goes to MPEG2 Encoder (D9022). And the ASI out of these is fed to
DCM’s.
5.2
The DCM will process those selected channel from the pay channel
decoder fed through MPEG2 encoder to IP format and send it to the
distribution network.
TPQ-GP55-DOC-0126
Version 0.7
7
The system consists of mainly 2 sections
1.
Satellite dish farm and 200 L Band signal feed for IPTV Head End system
2.
IPTV Head End system.
4.1.2 Satellite Dish Farm and L band Signal Distribution system.
The Satellite dish farm consists of 6 dishes and will be located on the Roof top of the
BDC (Back up Data Centre). Three satellite dishes will receive and distribute L-Band
signals and for redundancy three more dishes shall serve as backup. Following are the
Satellites that are considered:
•
Hot Bird-13°East,
•
Arab Sat-26 °East
•
Nile Sat 7 ° W.
The L-band feed from satellite Dish/LNB are fed to the Coaxial patch panel installed in
the standard rack located in BDC building data centre room. The equipment rack is
provided with “Test Point” for all the feeds, as well as TV monitor and DTH receiver to
monitor the live programs from each feed. To provide 200 L-Band feeds to IPTV head
end (12 Main feed + 12 Redundant feed) in the data centre room, we propose two 42 U
standard racks.
LNB: A low-noise block converter (LNB, for low-noise block, or sometimes LNC, for lownoise converter) The LNB is usually fixed on the satellite dish. As Microwave satellite
signals do not easily pass through walls, roofs or even glass windows, satellite antennas
are normally installed outdoors, and the signal needs to be passed indoors via cables.
The job of the LNB is to take a wide block (or band) of relatively high frequencies (Lband), amplify and convert them to similar signals carried at a much lower frequency
(called intermediate frequency or IF , frequency ranging from 950Mhz to 2150 Mhz).
Quattro universal LNB: A Quattro LNB has four fixed outputs and is used only in "head
end" I.F. distribution systems. The four outputs of the LNB are as follows.
Horizontal Polarization Low Band.
TPQ-GP55-DOC-0126
Version 0.7
8
Horizontal Polarization High Band.
Vertical Polarization Low Band.
Vertical Polarization High Band.
The LNB amplifies the relatively weak signals, filters the block of frequencies in which
the satellite TV signals are transmitted, and converts the block of frequencies to a lower
frequency range in the L-band range. These lower frequencies travel through cables with
much less attenuation of the signal to provide best quality picture.
CABLES: Coaxial cable (or "coax") is the most common cable used for transmitting IF
signals. The name "coaxial" refers to the common axis of the two conductors. A coaxial
cable has a solid copper or copper-clad-steel centre conductor surrounded by a nonconductive dielectric insulating material.
The dielectric is surrounded by foil shield/s and/or copper braid/s which form the outer
conductor and also shield against electromagnetic interference (EMI). The outer
conductor/shield is encased in a PVC jacket. Most coaxial cables for video applications
have a nominal impedance of 75 ohms. Their differing electrical and physical
characteristics make it important to select the correct type of cable to suit the application.
All types of coax cables will lose signals. The extent of the loss will depend on the quality
of the cable. However, all coax cable will lose more signals at higher frequencies (2150
MHz+) than at lower frequencies (950 MHz).These losses are compensated by an IF
amplifier.
The L-band feed from satellite Dish/LNB ranging from 950 MHz to 2150 MHz with an
input signal level of -25dBm to -65dBm is fed to the coaxial patch panel. These virgin
signals are further splits and distributed to IRD and to Pay Channel decoders, with the
help of appropriate IF splitters. The required amount is 200 L-band signal feed carrying
different polarizations as per the required channel mapping.
TPQ-GP55-DOC-0126
Version 0.7
9
IF splitters:- A splitter is a small device that has one input (the 75 ohm load) and 2 or
more outputs, such as 2 ways, 3ways, 4 ways, 6way and 8 ways. Each ports driving a
separate 75ohm load. In TPQ, all these types of splitters as to attain the 200 no’s of IF
signals.
Essentially they are transformers that split the power in the input signal to multiple
outputs, while maintaining the 75 ohm impedance. However, Every time you split an IF
signal with a splitter, you drastically decrease the signal's strength logic dictates that
splitting this signal in two with a "passive" device will result in two signals that each have-at most--half of the original signal's strength. To overcome these losses an IF amplifier
is used.
IF amplifier: - Boost the IF signal to get more mileage and compensate for the cable
loss in the distribution system. This is used to compensate for signal loss when the IF
signal is split into a number of IF signals (200 no’s) by passive splitting. a set of two SAT
900 (IF amplifier), one set of main and another set is redundant amplifier. This design
ensures the availability of IF signal (950 MHz – 2150 MHz) with relevant signal level that
ranges from -25dBm to -65dBm.
Three dishes are designed for redundant use, these dishes are tracked and tuned for the
same 3 satellites (Hot Bird-13°East, Arab Sat-26 °East & Nile Sat 7 ° W.) to ensure the
availability of IF signal always in case of failure from main dish feed..
The equipment rack is provided with “Test Point” for all the feeds, makes possible to
determine/ measure the signal level without interrupting the signal fed to the IRD’s and
pay channel decoders.
A LCD monitors and a FTA satellite receiver (Free to Air) is provided and is connected
through a multi switch to monitor the programs from each satellite feed. (I.e. all the 12 IF
feed for Nilesat, Arabsat and Hotbird)
Multi switch: -
This makes possible to select one satellite and transponder from
different dishes through one cable. This is done via a multiswitch distribution system.
DiSEqC (Digital Satellite Equipment Control) pronounced "Die-Sec" is a special
communication protocol for use between a satellite receiver and a device such as a
multi-dish switch or a small dish antenna rotor. A DiSEqC switch is a device which
TPQ-GP55-DOC-0126
Version 0.7
10
enables you to connect multiple LNB’s to a satellite receiver; here this is used as we
have 3 dishes.
All the testing points and monitoring equipments will be in one rack, and second rack will
be equipped with all passive and active equipments for distributing the L-band signals,
carrying different polarizations as per the required channel mapping.
4.1.3 IPTV Head end System.
Solution is based on MPEG-2 technology platform.
A centralized MPEG-2 head end is installed in single geographical location (BDC
building), providing DCM redundancy.
The system currently comprises four parts:
Acquisition
Encoding
Multiplexing
Monitoring
Acquisition
In the Acquisition, we will be using the D9850 program receivers together with the
Indus Stream Descramblers for the scrambled channels.
MPEG-2 FTA Channels (Free to Air)
Satellite program is received and decoded by scientific Atlanta’s D9850 FTA and
power key transport-stream QPSK satellite receiver and fed directly to Scientific
Atlanta’s DCM’s ASI board.
TPQ-GP55-DOC-0126
Version 0.7
11
MPEG-2 Scrambled Channels
Satellite program is received and decoded by Scientific Atlanta’s D9850 FTA and
Power key transport-stream QPSK satellite receiver and fed to scientific Atlanta’s
INDUS MKII transport-stream descrambler. Each descrambler board carries 2
CAM slots that can be used in cascade for multiple descrambling capabilities of
the same transport stream. The descrambled (Clear) stream will be fed to
Scientific Atlanta’s DCM’s ASI board.
Encoding
Satellite program will be received and decoded by the Service providers’
proprietary satellite decoder (Pay channel Decoders to be decided & procured by
the operator). Since the output of the Decoder is audio video baseband
(Composite video and analog audio), these signals need to be re-encoded and
converted to MPEG-2 single transport stream. This task will be performed by
Scientific Atlanta’s D9022 MPEG-2 Encoder. These are further fed to the DCM.
These Encoders can be also be used for the advertisement insertion (in-house
channels) and displayed as a TV Channel. The source media is to be decided
and procured by the operator, taking into consideration that the source media
output should be Audio Video Baseband (Composite video and analog audio).
Multiplexing
In Multiplexing part, we will have the Digital Content Manager which receives the
ASI input from the D9850s/D9022s and the Output for the DCMs will be Gigabit,
which will be fed to the Aggregation switch in the network. To ensure
redundancy, the DCM’s will be connected in 1+1 configuration, ensuring
maximum availability for the system. There will be a total of 14 DCM’s, which will
be used in the project with 7 as main DCM’s and 7 as back up.
Monitoring
TPQ-GP55-DOC-0126
Version 0.7
12
For monitoring, we will be using the Copernicus MKIV server together with the
ROSA system software. For the complete system monitoring, interfacing will be
done with the 10/100 Base-T IP network and all the systems will be further
connected to the monitoring server with the help of the Ethernet cables.
The Acquisition/Encoding network will receive the input from the L-Band splitting
network for the satellite signal. At the Acquisition phase, we will be having 200
ASI outputs, which will further be going to the DCM. These 200 ASI outputs will
be in 1+1 configuration. This will provide fall-back procedure for the DCM in case
of any downtime on the primary/backup DCMs. These 200 streams have been
calculated as follows:
•
Out of the 100 D9850s in total, 70 D9850s Receivers are used for the
Free to Air channels. The output from these D9850s will be connected
directly to the DCM and there will be no interfacing equipment in between.
As every D9850 has only one ASI out and our requirement is to connect
the ASI inputs to both the primary and redundant DCM, we will be using
70 ASI splitters, which will be providing us with 70x2 ASI streams. The
output from the ASI splitters will be connected to both the main and
Backup DCM.
•
The output for the remaining 30 D9850s will be going into the Galaxy
System rack containing the Indus MKII Descrambler Cards. As the INDUS
has 2 outputs per card so both these outputs can be used for connecting
to the main and redundant DCMs. For these 30 Encrypted streams as we
will have 1+1 output for every stream so no ASI splitting is required and
we will have 30x2 ASI streams into the DCM.
•
The D9022s which will be used for the digital encoding will be having a
1+1 output at each output. So, one will be connected to the main DCM
and the other will be connected to the secondary DCM. This will give as
100x2 ASI streams at the input of the DCM.
All the 14 DCM’s receive the 200x2 ASI input. Main DCM 1-6 will be having 30 ASI
inputs and the DCM 7 will be having only 20 ASI inputs. The same scheme will be used
for the redundant DCM’s also.
TPQ-GP55-DOC-0126
Version 0.7
13
The detailed connectivity for all the HE components will further be given in the Rack
Layout and System Cabling diagrams. Refer TPQ-ITV-GP55-DWG-0001 drawing for
more details.
4.2 System Description
4.2.1 MPEG2 Encoder- Model D9022.
Description:
Designed to deliver high quality MPEG-2 video and supports ASI output. Control of the
encoder is supported via the front panel interface, an on-board web browser, and open
communication protocol (SNMP).
Features:
Web-based GUI and SNMP management interface for interfacing to third-party
management systems to control the encoder. 1 Ru, Low power consumption, stackable.
Adaptive comb-based composite video encoder, 0.5 to 15 Mbps. Two audio stereo
channels as either analog or digital audio output. Contact closure alarm outputs.
Specifications:
Standard Composite input for video systems PAL (B, D, G, H, I, and K)
and 75Ω unbalanced impedance. BNC connector with aspect ratio of 4:3,
16:9.
Analog and digital AES-3id audio inputs.
BNC and terminal block connector.
Two stereo pairs or four mono number of channels.600Ω or ≥20 kΩ
balanced impedance.
Single-ended 75Ω impedance. Having 0.5 to 2 Vpp nominal input level.
Encoding MPEG-2 video and audio processing. Has an encoding rate of
0.5 to 1.5 Mbit/s for 4:2:0
DVB-ASI output. Two transport outputs and also used BNC connector.
Has 75Ω output impedance. Two IPTS output in eight-pin RJ-45, MDI.
Power consumption of ≤45W fully equipped at the voltage range of 100V
to 120V AC or 200V to 240V AC ±10%.
4.2.2 Program Receiver - Model D9850
TPQ-GP55-DOC-0126
Version 0.7
14
Description:
The PowerVu® Model D9850 receiver is designed for satellite content distribution
applications requiring 4:2:0 video decoding.
Features:
This has four L-band inputs and PowerVU conditional access. With Aspect ratio
conversion (4:3, 16:9 and 14:9) and Active Format Descriptor (AFD) control.
Specifications:
MPEG-2/ DVB Compatible system with Quadrature Phase Shift Keying (QPSK)
De-modulation process.
Variable Field Error Correction (FEC) (1/2, 2/3, 3/4, 5/6 OR 7/8).
Tuner frequency range 950MHz up to 2150MHz using C-band and KU-band
satellites frequencies. Input impedance of 75Ω and symbol rate range of 1.0 to
45Msymbols/s. RS-232 asynchronous data at rates up to 38.4 kb/s data outputs.
Power consumption of 50Wmax and voltage range of 100V to 240V AC.
4.2.3 Digital Content Manager (DCM) Model D9900
Description:
A compact MPEG processing platform capable of supporting extremely high numbers of
video stream processing. The DCM comes in a compact 2RU chassis with hot
swappable and redundant power supplies. The unit can be configured with up to 4 I/O
cards, with each card having either 10 ASI ports or 4 Gbe ports. The DCM supports up to
8Gbps of input and output capability.
Features:
Interface up to 40 ASI interfaces ports ( 30 ASI ports per ASI I/O card, having 3available
card slots and 1 card slot dedicated for IPTV ).Re-multiplexing of services and content
routing from any input to any output port.Transrating of single SD ( Standard Digital ) and
HD ( High Definition ) programs, ( recompression to lower bit rates.10 Gbps internal
processing throughput with 8 Gbps of I/O capability.
Specifications:
TPQ-GP55-DOC-0126
Version 0.7
15
This has 10 ports per ASI interface card, each port configurable as input and
output. Using a BNC-type connector and an output impedance of 75Ω. Bit rate of
0.1 to 213 Mbps.
Power consumption of 250W fully loaded. Nominal input voltage 100-240V AC.
4.2.4 Transport Stream Descrambler -INDUS MKII
Description:
Capable of simultaneously descrambling selected programs in a transport stream to
provide a
“clear” digital signal. The removable Common Interface Module allows the
operator to easily select the required CA System for transport stream descrambler.
Features:
Simultaneous descrambling of the selected services in a transport stream. Bays for two
DVB Common Interface Conditional Access Modules ( CAMs ). Descrambling capacity of
services depends on the used CAMS. It also supports all Common Interface compliant
CA systems. Provide ASI input and Dual ASI output and selection of Programs or
individual PIDs.
Specifications:
Having 1 main input and 2 outputs. Using a BNC-type of connector (on panel
board). Input impedance of 75Ω. Maximum bit rate of 56Mbps. Having 2 CI slots
using PCMCIA connector type I and II.
Nominal power consumption is 10W.
4.2.5 Modular Rack System-Galaxy
Description:
The Galaxy Sub-Rack Concept is housed in a 3ru unit designed with a common power
and communication interface to all inserted modules. Physically consist of an interfacing
rear-card module and the application front-card module. The power supply can be either
single or dual power supply with a free choice of AC and DC.
Features:
TPQ-GP55-DOC-0126
Version 0.7
16
Holds up to 12 application cards of the Galaxy family in only 3RU. Multiple powering
possibilities with or without redundancy. Hot-swappable, easy accessible application
cards and low power consumption.
Specifications:
A relay contact type which has 2x25-pins female Sub D connector. Maximum
load of 60 VDC, 250 Ma, 5 VA. Communication port of 9-pins male Sub D
connector type RS-485. Capable of transmission speed up to 19200 bit/s. Power
supply of 100 to 240 VAC ±10%, 47 TO 65 Hz.
4.3 MPEG2 vs. MPEG4
MPEG-4 is a technology that reduces the bandwidth requirement of a network, but
only in the core and distribution layers, and does not improve video quality. In the
case of an existing data (internet)/voice network that is to be to a “triple play”
network that includes Video, there always arises bandwidth issues. Therefore, the
bandwidth constrains are overcome at the last mile (access layer) with an MPEG-4
solution, without the need to upgrade the entire network.
TPQ-GP55-DOC-0126
Version 0.7
17
In the case of a Pearl network, which is built from the beginning, taking into account all
three major services (internet, voice and video), and the bandwidth engineering is
considered.
4.4 Major Assumptions
In the case of a detailed channel plan to be received and agreed between the supplier
and the customer showing satellites, transponders, conditional access, etc., the number
of satellite receivers and encoders can be reduced since at the moment, the worst-case
scenario has been considered:
(1) 100 satellite receivers for 100 channels. (2) 100
channels
via
encoders
for
proprietary transmission with the appropriate decoder in the customer premises
provided by the content provider (Show Time, ART & Orbit)
As an example, if multiple channels are part of the same transport stream received from
the satellite, one single satellite receiver is needed.
4.4.1 Headend Topology solution
1. A centralized MPEG-2 solution in a single geographical location (Backup Data
Center) providing DCM redundancy.
TPQ-GP55-DOC-0126
Version 0.7
18
4.4.2 Scenarios
Dish Farm and L-Band Distribution
Three main scenarios have been considered:
1.
MPEG-2: Free To Air (FTA) Channels
Satellite program is received and decoded by Scientific Atlanta’s D9850 Free to Air and
PowerKey Transport-Stream QPSK Satellite Receiver and fed directly to Scientific Atlanta’s
Digital Content Manager’s ASI Board.
2.
MPEG2: Scrambled Channels
Satellite program is received and decoded by Scientific Atlanta’s D9850 Free to Air and
PowerKey Transport-Stream QPSK Satellite Receiver and fed to Scientific Atlanta’s
INDUS MKII Transport-Stream Descrambler. Each Descrambler Board carries two
CAM slots that can be used in cascade for multiple Descrambling capabilities of the
TPQ-GP55-DOC-0126
Version 0.7
19
same Transport Stream. The descrambled (Clear) Stream will be fed to Scientific Atlanta’s
Digital Content Manager’s ASI Board.
3. Proprietary Services like Show Time, Orbit, and ART and others where no
descrambling CAMs are available
Satellite Program will be received and decoded by the Service Provider’s Proprietary
Satellite Decoder. Since the output of the Decoder is Audio Video Base Band (AV BB), the
signal need to be re-encoded and converted to MPEG-2 Single Transport Stream
(STPS). This task will be performed by Scientific Atlanta’s D9022 MPEG-2 Encoder
and the encoded STPS will be fed to Scientific Atlanta’s Digital Content Manager’s ASI
Board.
Sl.No
1
2
3
4
5
6
7
DCM Pair
IP Address (Slot-1/Slot-2)
VLAN
Channels
DCM Pair 1-1
192.168.120.101-104
120
FTA
DCM Pair 1-2
192.168.120.105-108
120
FTA
DCM Pair 2-1
192.168.120.109-112
120
FTA
DCM Pair 2-2
192.168.120.113-116
120
FTA
DCM Pair 3-1
192.168.120.117-120
120
FTA
DCM Pair 3-2
192.168.120.121-124
120
FTA
DCM Pair 4-1
192.168.125.101-104
125
Premium 1
DCM Pair 4-2
192.168.125.105-108
125
Premium 1
DCM Pair 5-1
192.168.125.109-112
125
Premium 1
DCM Pair 5-2
192.168.125.113-116
125
Premium 1
DCM Pair 6-1
192.168.127.101-104
127
Premium 2
DCM Pair 6-2
192.168.127.105-108
127
Premium 2
DCM Pair 7-1
192.168.127.109-112
127
Premium 2
DCM Pair 7-2
192.168.127.113-116
127
Premium 2
TPQ-GP55-DOC-0126
Version 0.7
20
4.5 Set Top Box Basic Information
Two types of set-top boxes are designed for this project.
IPP330HD:
For Minerva middleware
For Widevine CAS using auto-entitled or dynamic encryption @ 25% level
For SeaChange VOD with 4x, 16x, 64x and 256x trick mode speeds
Utilizes Sigma Designs 8634 System-on-chip (SoC) silicon
256MB DRAM / 64MB Flash memory
Supports MPEG-2 and MPEG-4 for SD and HD content
Supports RCMM IR protocol @ 36Khz
Supports IGMPv2
Supports 188 byte MPEG-2 transport
Composite output fixed 576i PAL B/G format
HDMI output configurable via settings page using Minerva middleware.
If the
display does not support the selected size it will auto-negotiate.
RGB output via SCART is disabled
Component output is YPrPb and tracks HDMI setting
7 segment display will provide boot status during boot up. It is controllable via
Minerva middleware. For the initial deployment it is disabled.
Teletext and teletext subtitle supported via VBI pass-through only
USB ports are disabled
Supported displays 4:3, 4:3 letterbox, 16:9 with universal change across all outputs
Supports English font only with standard Minerva “Swirl” user interface
No SNMP support
Example of the IPP330 and front and rear panel connectors is shown below:
TPQ-GP55-DOC-0126
Version 0.7
21
IPP430MC:
Same as IPP330 above, except that MPEG-2 HD is not supported (only MPEG-4 is
recommended for HD content for DVR models)
Includes fanless 160GB hard disk drive for DVR services, supports DVR trick mode,
speeds 2x, 15x, 50x and 300x
4.6 Network Management
The proposed solution is managed centrally from the Rosa Network Management with focus
on:
Fault Management
Configuration Management
Performance Management
Security Management
SNMP to 3rd Party Devices (excluding IP set-tops)
TPQ-GP55-DOC-0126
Version 0.7
22
5. Minnerwa Networks
This section of the document is an introduction to iTV Manager’s features, terms, and concepts.
It’s meant to act as a primer for iTV Manager Administrators.
iTVManager 3.2 is a scalable enterprise solution that manages the distribution of video, television
and other data services over an IP Network. iTVManager offers true Video on Demand (VOD),
live television, and complete web integration. As the cornerstone of the IP television headend,
iTVManager is a scalable, interactive television management suite.
iTVManager is comprised of two major components:
1. the server software or BackOffice and
2. the set top box software, the Think application.
The BackOffice suite of software includes:
•
•
Tools that let you manage:
Subscribers
Channels
STB device inventory
Service and pricing
Asset management
Billing
EPG (Electronic Programming Guide) Loader that manages the data that is ingested from
an EPG provider and sent to the Set-Top Boxes (STB)
•
VOD (Video On Demand) Delivery System (VODDS) module that talks to VOD content
providers to automatically deliver to iTVManager the most up-to-date VOD assets
The Think application presents a UI that lets the television viewer see the EPG, purchase VOD
programs, search for titles in the EPG and VOD catalog and schedule recordings and program
TPQ-GP55-DOC-0126
Version 0.7
23
reminders. The user interface, through customization can be used to present custom branding
and layout design.
5.1 Services and Architecture overview
The following table summarizes the services that are included with iTVManager 3.2 and those
that are provided through third-party components:
Services
Broadcast
Video
Included with iTV Manager 3.2
Electronic Program Guide (EPG) ingestion.
Channel lineup management that maps EPG
channels to multicast addresses
Not included with iTV Manager 3.2
Video encoders that generate multicast IP
streams that carry Live TV video content.
Conditional Access scramblers in the
headend and descramblers on the STBs.
Electronic Program Guide data.
VOD metadata ingestion.
VOD asset ingestion (for VOD content
suppliers that don’t supply their own ingestion
functionality).
Video on
Demand
Delivery of VOD catalog listings to the STBs.
VOD asset categorization (“Drama”, “Sports”,
“Comedy”, etc.).
Supply of VOD asset and metadata.
VOD streaming.
RTSP server for “trick play” functionality
(Pause, Fast Forward, Rewind).
VOD purchase.
VOD playback bookmarks.
Customer
Management
Collection and storage of “real world” data
(address, phone number, SSN, etc)
Assignment of the devices, service package,
and entitlements.
Storage of the Customer's purchased assets,
blocked channel lists, "favorites" lists, and so
on.
It’s anticipated that most medium-to-large
Telco’s will want to (at least) import existing
customer records from their own database
systems into the Minerva database, and
thereafter “share” customer information.
Ability to tag a customer record with an
"external ID", thus allowing a Telco to easily
import and export customer records database.
Purchases (and other transactions) are
recorded in the iTV Manager database.
Billing
Invoice generation.
Flat-file "Billing Reports generation that can
be fed into the Telco's existing billing system
TPQ-GP55-DOC-0126
Version 0.7
It's anticipated that most medium-to-large
Telco’s will want to manage billing through
their own systems
24
Conditional
Access
Client UI and
Graphics
Other
Features
iTVManager doesn’t provide Conditional
Access functionality directly. However...(next
column)
Complete, off-the-shelf UI for the EPG, VOD
catalog, SVOD catalog,“Vault” (the customer’s
repository of purchases and messages), PVR
access, user preferences screens, and so on
The Search module and onscreen keyboard
let the user search for keywords in the EPG
and VOD catalog.
UI customization is provided through the
proprietary, text-based thinkstuff language.
All UI strings are stored in a localized string
table for easy translation.
The user can choose a specific UI skin (or
“Theme”).
Caller ID messages, generated by an external
mechanism, can be posted to the server
which then distributes the message to the
appropriate STB, or they can be sent directly
to the STBs themselves.
User Event Logging (“Transaction Profiling”).
The STB can record the user’s events, such
as channel changes, program recording,
trickplay use, and so on, and then send a log
of the events back to the server for data
mining.
Emergency Alert System (EAS). The full
range of EAS messages are understood by
the server and broadcast to all STBs. In
addition, you can configure the system to
force a channel change to the EAS
information channel.
TPQ-GP55-DOC-0126
Version 0.7
Minerva works with Conditional Access
providers (sometimes through STB vendors)
to ensure that complete Conditional Access is
provided. This includes both a server and an
STB component.
STB manufacturers implement a well-defined
API (called the “MvLayer”) that lets the Think
application talk to the STB hardware.
Some of these features have a third-party
component:
1. Caller ID: An external system has to
listen for incoming calls and generate
the caller ID information that’s sent to
the STB.
2. EAS: An external EAS box must be
connected to the system.
25
The diagram below shows a high level picture of an iTVManager 3.2 system, with components
supplied by Minerva in green and components supplied by 3rd Parties in pink.
Mozilla
Think
X
Porting API (MvLayer)
Porting Library, HW/ OS
CA Client
STB
3rd Party
Admin
GUI
Admin
GUI
Admin
Applets
dhcp
VOD
CA
Servers Servers
Broadcast
Catcher
Network
Backoffice
SDK
(Enhydra)
Admin
Servlets
(Enhydra)
STB Unicast
Services
(Configuration,
Packages,
Transactions,
VOD, Apps)
Content
STB
Multicast
(Skins,
Apps,
Listings)
VOD
CA
Connector
APIs
Integration Managers
(VOD, CA, VODDS
etc.)
Server Middleware
Billing
Reports
Customers, STBs, Lineups, Skins, Config,
Listings, Applications, Entitlements,
Transactions, Stored Procedures
EPG
Ingest
Guide Listing
Services
Data
5.2 Technologies implemented and main components
A variety of technologies are utilized by iTVManager.
The following is a description of the
technologies and applications that are used by iTVManager.
TPQ-GP55-DOC-0126
Version 0.7
26
5.2.1 Oracle DB 10g
The Oracle database is central to the iTVManager system. The only implementation detail that
functionally ties the product to Oracle is a variety of stored procedures. Some of these are in the
process of being migrated to Java. The procedures that are most embedded are those that are
part of the billing process.
Two other features of Oracle that are leveraged by iTVManager are its widely recognized
methods of scaling and reliability.
5.2.2 Oracle Application Server 10g
Most of the iTVManager Java components are hosted within an Oracle Application Server 10g
environment.
The main features utilized by iTVManager are:
• Java VM
• J2EE
• JDBC connections
5.2.3 Linux
iTVManager server side components are written to the Java layer. iTVManager is distributed with
specific versions of Linux to allow for configuration and compatibility with other tools such as
Oracle.
For the client side, Linux is the predominant environment on IPTV STBs (like the Scientific Atlanta
ones). Think is therefore kept compatible with all flavors of Linux used on the STBs.
5.2.4 Java
Java is a technology that allows software designed and written just once for an idealized "virtual
machine" to run on a variety of computers, including Windows PCs, Macintoshes, and Unix
computers.
J2EE defines most of the base platform and is also used for the BackOffice Console GUI.
TPQ-GP55-DOC-0126
Version 0.7
27
Java Platform, Enterprise Edition (Java EE) is the industry standard for developing portable,
robust, scalable and secure server-side Java applications.
5.2.5 Swift MQ JMS
SwiftMQ is a micro-kernel based J(ava)M(essage)S(ystem) enterprise messaging platform.
There is some messaging within the server using JMS; however, this is not extensive and is only
used for some selected situations.
5.2.6 Swing
Swing is a GUI toolkit for Java. It is one part of the Java Foundation Classes. Swing includes
graphical user interface widgets such as text boxes, buttons, split-panes and tables. The admin
GUI is written using Swing.
TPQ-GP55-DOC-0126
Version 0.7
28
Coming to the software components of the platform and their distribution across multiple physical
machines, below is a description of the various supported implementations.
On the headend side, iTVManager is a suite of applications and processes that are spread across
two servers:
TPQ-GP55-DOC-0126
Version 0.7
29
TPQ-GP55-DOC-0126
Version 0.7
30
The Database Application is installed on one server, the BackOffice Server, the Application
Server, and the Boot Server installed on the second server. In this document, we’ll focus on each
of these servers.
5.3 The Database Server
The Database Server hosts the iTV Manager Database, which is currently implemented using
Oracle Database 10g software. The function of the Database might seem obvious: It stores
records that describe customers, devices, channels, VOD assets, channel packages, and so on—
everything you need to populate the persistent, “material” content of an IPTV deployment. What’s
not as obvious is that the Database, as employed by iTV Manager, stores nearly everything that
describes the system, even ephemeral data such as STB-bound messages and the running
states of certain processes. It does this to facilitate a common means of communication: Rather
than talking directly to each other, one iTV Manager Process will write to the Database, and then
another will read from it. This approach yields slow but reliable communications.
5.4 The BackOffice Server
The BackOffice Server (or, simply, the BackOffice) knows how to read data from and write data to
the Database. During normal operation, the BackOffice is the only way for an administrator to
modify Database data. There are two ways to access the BackOffice: Through the Web-based
BackOffice Console, or by calling the functions in the BackOffice Software Development Kit
(SDK):
The BackOffice Console is a set of HTML/DHTML pages and Java applets that are hosted
by the BackOffice Server’s built-in Web server. The Console is divided into modules that
correspond, roughly, to the different Database entities: There’s a Customer module, a
Device module, a Channel Management module (for channels and lineups), and so on.
Access to the modules is selectively protected through the use of BackOffice user
accounts.
The BackOffice SDK is a procedural API that communicates with the BackOffice through
http posts and XML replies. The BackOffice SDK and the BackOffice Console share the
same pool of user accounts: If you use the Console to create a user who can only access
the Customer module, the SDK will let that user invoke Customer procedures only.
TPQ-GP55-DOC-0126
Version 0.7
31
These two BackOffice access methods—Console and API—perform the same functions. For
example, if you want to add a customer, you can either open the BackOffice Console’s Customer
page, press the Add button, and fill out the customer’s data, or you can invoke the SDK’s
md_cst.add_customer() procedure. The difference between the two methods is mostly a matter of
scale: If you’re adding thousands of customers at a time, you’ll want to automate the task by
writing a script that invokes BackOffice SDK procedures. On the other hand, if you just want to
change the address of a single user, you’ll want to use the BackOffice Console.
Implicit in this description is that the BackOffice is an administrative tool. It’s meant to be used by
an iTV Manager administrator who needs to modify, augment, or fine-tune some aspects of the
system. Of course, since almost all iTV Manager data and state are stored in the Database, it
means that the other iTV Manager processes, including the Think application running on an STB,
need to access the Database...but they do not use the BackOffice for this; instead, they either talk
to the Database directly, or they use the Data Service applications.
5.5 The Application Server
The Application Server’s most important role is to act as an interface for unicast communication
between the Database and the STBs. It does this through an iTV Manager process called Data
Services, which provides an interface between the other iTV Manager processes and the
Database. For example, when a user rents a VOD asset through the STB, the Think application
(on the STB) sends a message to Data Services, and Data Services logs the purchase in the
Database. Data Services then retrieves, from the Database, the IP of the VOD’s video server and
passes it back to the STB so that the two components (the STB and the video server) can create
a unicast connection, thus allowing the user to watch his movie.
5.6 The Boot Server
The Boot Server handles “informational” multicast communication between the iTV Manager
headend and the STBs and hosts most of the processes that act as interfaces to third-party
modules. The Boot Server’s most important process is the Dispatcher, which sends boot-up and
runtime messages to the STBs. The Boot Server also hosts the Video on Demand Delivery
System
(VODDS) and
the
Video Server
Manager (VSM); these are
the processes that,
respectively, ingest VOD metadata into the Database and download and store actual VOD
content (i.e. movies) on the third-party Video Server (such as those provided by Entone or
TPQ-GP55-DOC-0126
Version 0.7
32
Bitband). Other Boot Server processes include the interfaces to the Emergency Alert System,
Caller ID, and the Conditional Access system.
5.7 Servers and Platforms
The two iTV Manager Servers are “servers” in the sense of “software hosts.” Both servers can
reside on the same (physical) platform. In the case of Pearl Qatar, two-tier installation is
considered as a part of the design
In a two-tier installation, the Database Server runs on a platform that’s placed behind a
firewall, and the other Servers are run on a second platform. A minimal amount of
hardware is used, thus reducing the overall cost and administration.
In the diagram mentioned below, there are the communications between STB and Minerva during
the "steady status" which happens once the box has already booted up and keeps the fingerpath
with the middleware through the Announcement Stream configurable (happening after the RunTime Stream and the Boot Stream).
All the main actions, such as “Purchase Transactions”, “Edit Favorites”, “Play VOD”, etc., are
summarized and described in the section “User Actions”, where there are all the choices that the
customer has from the STB side and that require a communication with the Application Server.
TPQ-GP55-DOC-0126
Version 0.7
33
6. Widevine Technologies
Widevine Cypher is the first and only “session-based” content security system for interactive TV
(IPTV).
6.1 Widevine Cypher: A Comprehensive Security Solution
Widevine Cypher offers a comprehensive content protection solution that secures content delivery
to a wide range of consumer devices and video formats. Designed to secure content delivery
over any network, a single Widevine Cypher system can secure TV, PC and mobile services,
each with potentially different video formats and consumer devices. This unique multiplatform and
multiformat capability means that operators efficiently get the content protection required, while
retaining the flexibility, choice and control over future devices and service options.
The most integrated solution in the industry today, Cypher works with most major middleware
vendors, VOD server vendors and consumer device manufacturers for complete operator
flexibility and control. In the home, Cypher Virtual SmartCard clients enforce secure consumption
of content and can lock down consumer piracy across an entire subscriber base in minutes to
hours. Cypher’s optional digital copy protection keeps content protected after it is decrypted using
a patented method of monitoring, detecting and responding to potential piracy on PC-based
consumer platforms.
Cypher's patented application-level encryption also keeps operational costs low. It enables linear
broadcast, VOD, streamed media and file downloads to be encrypted once and to remain
encrypted throughout the entire video distribution chain, accommodating storage on CDN or P2P
networks and during VOD ingestion, digital ad insertion and trick play on consumer devices.
Cypher Management Console makes system management simple through an intuitive browserbased interface that is compatible with major fault and performance management systems.
Widevine Cypher is underpinned and protected with eight patents that cover all aspects of
downloadable CAS, DRM and real-time piracy detection and prevention. This patented protection
offers operators the ability to operate freely in the patent-laden world of content protection, now
and in the future.
TPQ-GP55-DOC-0126
Version 0.7
34
Widevine Cypher can protect content on set top boxes, personal computers, personal video
recorders, home media gateways, mobile phones, and a wide range of consumer electronics
devices.
The following details the benefits of utilizing Widevine and particularly Widevine Cypher to protect
Pearl Qatar’s video deployment.
6.2 Conditional Access and Digital Rights Management
There are two ways to protect video content: conditional access (CAS) and digital rights
management (DRM).
Legacy CAS products were designed for the specific requirements of
broadcast television in the cable and satellite domain. The systems function by protecting content
only during transport. Decryption occurs when the transport session was terminated upon
reaching a set top box. This security architecture ensures that content is secured in transit from a
head-end to a receiving device. Since legacy CAS technologies only protect content during
transport, content stored on devices to accommodate for VOD is stored “in the clear” and is
susceptible to theft.
DRM systems are designed to protect files and are historically targeted at industries where
ownership is transferred, yet the rights of the new 'owner' to copy or distribute content are
restricted. DRM is based on the idea that there will be an electronic “certificate of ownership”
issued to someone or something as proof that rights have been assigned. Ideally, the certificate
cannot be copied or tampered and the item the certificate protects can only be used in
conjunction with the certificate itself. If the certificate is not present, the item cannot be used.
Encryption is applied at the file level at the point of encoding and rights are maintained by the
content copyright holder (i.e. a movie may be distributed as a file amongst many users but its
DRM properties require the owner to be paid each time a unique user attempts to watch the
movie).
DRM deals with the concept of ownership and is only appropriate for file-based content. CAS is
aimed more at permitting access without transfer of ownership and is only appropriate for
broadcasted content. However, today’s IPTV deployments require a combination of both
technologies. Content is distributed in its digital file format and needs persistent encryption, while
TPQ-GP55-DOC-0126
Version 0.7
35
the access control is essential to the operator’s revenue. Therefore, the content security solution
of choice would ideally deliver both in a single system, giving service operators the ability to
deliver media in the most efficient, profitable manner.
Widevine has designed a comprehensive system that together delivers CAS to secure linear
broadcast and DRM to secure VOD. The value to Pearl Qatar is that a Widevine Cypher system
can be used for securing multimedia content delivered in multiple formats, platforms and content
types, including linear broadcast, VOD, streamed media, file downloads and progressive
downloads (Widevine owns the patent on encrypted session-based video delivery).
This multiplatform, multiformat approach ensures that IPTV Design in Pearl Qatar has the
flexibility to choose the video delivery infrastructure, video formats and consumer devices that
meet business and technical requirements today and tomorrow.
6.3 Renewable Security
Widevine introduces and uses the concept of a renewable security client, a unique software
approach to the functionality of a smart card. Widevine’s Cypher Virtual SmartCard technology
eliminates all of the cost of ownership and vulnerabilities of the physical smart cards used in
legacy CAS systems while still maintaining all of the security benefits. By implementing the
management and use of keys, the highly secure Cypher Virtual SmartCard can be renewed within
minutes to hours and at no additional charge to the operator. This coupled with the lower fixed
cost burden provides a much lower cost of entry and ownership.
6.4 Protection for Untrusted Platforms
Cypher for the PC is an extension of the industry-leading Widevine Cypher. Designed for wide
consumer device support, it secures PC-based platforms such as Windows, Macintosh and Linux
devices. Built for complete multimedia protection, it secures all major video formats such as
MPEG2, H.264, VC-1, Windows Media, QuickTime, RealMedia and Adobe Flash.
Cypher for the PC enhances security at the client side by adding digital copy protection on de
devices. This digital copy protection ensures that content is monitored for potential piracy in what
TPQ-GP55-DOC-0126
Version 0.7
36
is known as the digital hole — the place content resides after decryption and before being display
on the screen.
Widevine developed digital copy protection to secure untrusted platforms such as PC-based
consumer devices that are highly vulnerable to piracy. This solution detects and responds to the
many utilities used to record and redistribute media. The technology is also applicable for
protecting STB and PVR devices.
6.5 Application-Level Encryption
A key challenge in the encryption and delivery of content across a video network is how to keep
the content secure through the entire video distribution chain, while keeping the content available
for optimization and modification when needed. Legacy CAS systems encrypt at the network
(transport) layer and traditional DRM solutions wrap an entire video file or broadcast stream in an
encrypted packet. Therefore, the only way that operators can ingest and create trick play files for
VOD or splice in digital ads or programming before distribution to subscribers is to decrypt the
content. (Please see Figure 1 below for an illustration of typical encryption and decryption
processes that are employed in a content delivery network.) This need to intermediate decryption
introduces points of vulnerability both at the operator’s head-end and on the consumer device,
which is contrary to studio and broadcaster content security requirements. To rectify this
weakness, traditional content security systems must employ an extensive integration effort
between the security system and both the VOD server and playback application. This solution
adds cost in terms of headcount and equipment in order to accommodate this.
Figure 1: Traditional encryption-decryption process. Each
decryption process is a point of vulnerability in the network
In response to this issue, Widevine Cypher offers application-level encryption: a patented
alternative approach that keeps content persistently encrypted through the entire video
TPQ-GP55-DOC-0126
Version 0.7
37
distribution but allows VOD ingestion, trick-play file creation and digital ad/program insertion in the
encrypted content. With application-level encryption, only the video data are encrypted, leaving
key aspects of the video stream such as the control and metadata in the clear. This method
enables trick-play ingestion and file creation without having to decrypt the entire video stream,
preventing points of vulnerability in the network. (Please see Figure 2 below for an illustration of
application-level encryption). Application-level encryption further enables persistent protection of
linear content (i.e. broadcast channels) even when used with network personal video recorder
(nPVR) and client (cPVR) applications.
Figure 2: Application-level encryption process
Widevine’s Application Level Encryption enables pre-encryption. Application Level Encryption
(ALE) provides stronger security than traditional encryption methods because it keeps content
persistently encrypted. Widevine Cypher uses application level encryption to encrypt multimedia
content once, early in the content distribution chain, and to keep it encrypted throughout the entire
delivery cycle. Only at the point of consumption is content decrypted.
ALE equals pre-encryption. With ALE VOD, Time Shift TV, digital program insertion and
connected home solutions are made possible.
6.6 Widevine Cypher Overview
Widevine Cypher uniquely combines CAS and DRM into a single content security system for IPTV
and broadcast deployments. The system is vendor, protocol and device agnostic, which lowers
the cost to integrate security across an operator’s network. The modular design of Widevine
Cypher permits it to be utilized independently or as a consolidated package. The following
diagram depicts the components and how they will be integrated into a typical head-end:
TPQ-GP55-DOC-0126
Version 0.7
38
Figure 3: Widevine Cypher Architecture
The below sections detail the components comprising the Widevine Cypher solution.
6.6.1 Widevine Cypher Certificate Authority
Cypher Certificate Authority (CA) manages the generation and distribution of encryption keys to
Cypher Broadcast and Cypher VOD encryption appliances and the delivery of entitlements to
subscribers enforcing the digital rights. Using the time-tested model of Entitlement Control
Message (ECM) and entitlement management message (EMM) distribution, with strong
renewable encryption, it ensures subscribers only access and view content they have paid for.
Designed to scale to the requirements of fast-growing telco, cable, internet, mobile and satellite
service environments, Cypher CA enables operators to deliver a comprehensive content
protection system for video deployments of all sizes. Cypher CA’s comprehensive approach
enables operators to deliver a single-content security system for broadcast and file-based
content.
Cypher CA is also responsible for the communication with other video ecosystem components
and manages encryption key exchange with Widevine Cypher Virtual SmartCard clients. This
highly secure and bandwidth-efficient approach enables the secure delivery of multimedia content
TPQ-GP55-DOC-0126
Version 0.7
39
to Widevine Secure devices, including set top boxes, PVRs, PCs, portable media players and
mobile devices.
Cypher CA is scalable to an unlimited number of subscribers and offers hot failover options
should an operator require them.
6.6.2 Widevine Cypher Broadcast
Cypher Broadcast is a real-time encryption appliance for securing the distribution of live streams
and linear broadcast channels. Utilizing Widevine’s patented application-level encryption, it
enables operators to encrypt content once and keep it encrypted throughout the entire video
distribution chain, even when stored on content delivery networks and in nPVR or cPVR
applications. This unique encryption capability further lowers the operational costs typically
associated with having to decrypt and re-encrypt content for digital ad and program insertion.
Designed to scale to the high-demand channel requirements of video operators globally, Cypher
Broadcast offers line-speed encryption performance in a single appliance. This solution supports
DVB-CSA or AES encryption. Utilizing next-generation appliances, Cypher Broadcast has a realtime encryption throughput of 900 Mbps of standard or high definition content.
It receives content constraints and encryption keys from Cypher Certificate Authority before
distributing encrypted linear broadcast content to a Widevine Secured consumer device. Through
Widevine’s patented Application Level Encryption (ALE), Cypher Broadcast enables all linear
broadcast content to retain interactive television capabilities such as PVR, trick-play, stream
splicing and custom ad insertion.)
1 Cypher Broad Cast unit supports up to 900 Mbits/s.
In order to dimension correctly, one must only dimension the bandwidth needed for the planned
live TV channels.
The following table has been used to determine the bandwidth, and thus Cypher Broadcast
dimensioning for PEARL-QATAR.
TPQ-GP55-DOC-0126
Version 0.7
40
Compression / Definition
MPEG 2
MPEG 4
Standard Definition
5 Mbits/s
3 Mbits/s
High Definition
18 Mbits/s
9 Mbits/s
Eg 20 SD channels and 5 HD channels
•
180 SD X 3 = 540 Mbits/s
•
20 HD/MPEG4 X 9 = 180 Mbits/s
•
Total of 720Mbits/sec initial bandwidth needed with an extra bandwidth of 180 Mbits/s
available. 1 Cypher Broadcast Unit is needed.
6.6.3 Widevine Cypher VOD
Cypher VOD is a pre-encryption system designed to protect file-based multimedia content. The
system applies encryption keys and content owner constraints to multimedia files before
distribution to a VOD or asset management system. With Cypher VOD, a multimedia asset can
be persistently encrypted, stored and consumed on set top boxes, PVRs, PCs, portable media
players and mobile devices.
Cypher VOD utilizes Widevine’s patented application-level encryption which enables encrypted
assets to be ingested into a VOD server without having to decrypt, resulting in a highly secure
and streamlined workflow. It also enables stream splicing and customer ad and program insertion
on encrypted assets for a more targeted and customized video delivery. This unique encryption
capability further lowers the operational costs typically associated with having to decrypt and reencrypt content through support of digital ad and program insertion on Widevine encrypted
content.
In the home, Cypher VOD enables secure consumption of content along with critical trick-play
functions (Stop, FF, Rewind, Pause, Play) through any Widevine Secure device. This highly
available solution supports DVB-CSA or AES encryption. Utilizing next-generation appliances,
Cypher VOD can encrypt one GB of content in one minute or less.
No real scaling limitations on the Cypher VOD dimensioning; only a few practical observations
were made.
•
Cypher VOD encrypts/decrypts at 1 min/Gb for AES and 8:30/Gb for DVB-CSA
TPQ-GP55-DOC-0126
Version 0.7
41
•
e.g. Cypher VOD encrypts/decrypts a 2-hour movie in less than 4 minutes.
(TVN
Entertainment customer source: Widevine encrypts a 2-hour movie in 1.5 min / NDS
encrypts a 2-hour movie in 45 minutes )
Knowing that, for security reasons, it is advised to re-encrypt a part (or all) of the VOD assets
every X time period, once the VOD vault becomes rather big, it may be interesting to expand the
Cypher VOD rack with 1 or 2 more units.
e.g. 1000 VOD assets at each 2 hours/asset = 1000 X max 4 min = 4.000 min of total VOD asset
re-encryption time
6.6.4 Widevine Cypher Virtual SmartCard
Cypher Virtual SmartCard clients bind the identity of a consumer device so that it only receives
content that is has paided for. This secure and highly renewable approach eliminates the potential
for device cloning, theft of service and content piracy that can occur on devices within a
subscriber’s home. Designed to work in concert with Widevine Cypher components in the headend, each client can be configured to refresh encryption keys, entitlements and digital rights for
any subscriber in the network.
The Cypher Virtual SmartCard interfaces to the Cypher CA for key exchange and entitlement
management.. Because of the Cypher Virtual SmartCard, every consumer device on the network
can be uniquely identified, providing the basis for unicast delivery and stopping any attempts at
cloning.
6.6.5 Widevine Cypher Management Console
Widevine Cypher Management Console offers intuitive configuration and monitoring of Widevine
Cypher suite. This secure, web-based interface provides detailed real-time status monitoring,
including overall appliance performance, SNMP, client licensing and consumer device
provisioning.
TPQ-GP55-DOC-0126
Version 0.7
42
Enhanced logging of Cypher appliances and Virtual SmartCard clients enables quick
troubleshooting of the entire system, including the status of entitlements delivery, device
connections, health status, service delivery and more.
A well defined MIB and the support for SNMP v1 and v2 traps offer the capability to seamlessly
integrate and communicate with third-party management systems. Designed for use in a
centralized head-end or in remote locations, access can be made using a secure, SSL-based
connection, so operators always know what’s happening with Widevine Cypher.
Cypher Management Console allows users to:
•
View state of services
•
Stop, start or restart services
•
View logs
•
View SNMP traps
•
Monitor server states
•
CPU load (numerical and graphical representation)
•
View memory usage
•
View licensing information
TPQ-GP55-DOC-0126
Version 0.7
43
7. SeaChange
The features that will be employed at present and in the future for the Sea Change Video Server
for Pearl Qatar Project are described below.
Video Server will be integrated with other partner products (Minerva, Widewine, Scientific
Atlanta) to generate a modern and powerful IPTV system.
Figure 4: Cypher Management Console offers
at a glance status of the Cypher system.
Some important
features
supported
and in continuous implementation by SeaChange developers
Convenient
“stop light”
graphics
identify
Figure 5: Service status and SNMP traps can be
actionable
responses
are given
below:for fast troubleshooting.
easily accessed anytime, anywhere, reducing time to
identifying and troubleshooting potential problems.
•
Video server HDS200: The
SeaChange MediaServer
HDS Series
represents
SeaChange focus on bringing greater economical solution to on-demand television
applications. This video server is designed for deployment as a stand- alone server
or as part of MediaCluster configurations, with several MediaServer HDS units
forming a single virtual server providing fault-resilience with SeaChange patented
RAID advantages. The SeaChange
MediaServer HDS 200 - based on commodity
technologies - is a leap forward in economically delivering a greater number of
simultaneous video streams and video assets in slim line 2RU rack system. With
up to six MediaServer HDS units per cluster, operators
than
1,600
hours of
VOD
programming
to
can reliably
thousands
offer
more
of subscribers from a
single cluster . The flexibility of the MediaServer HDS is marked by its ability to
provide a range of output types
–
including Gigabit
Ethernet for IP
transport
of MPEG, On2,
•
Contents Provider: SeaChange can provide a proposal for contents and metadata
production.
•
Asset Manager for VOD contents: Contents stored can be streamed free of charge
TPQ-GP55-DOC-0126
Version 0.7
44
or with price. Contents can be rented with various prices, mode and durations.
•
Multiuser Access: It is to possible to create more than one user on a single STB.
This can manage parental control and other types of filters.
•
Multiplatform System: Contents
from
the
same
user
can
be
viewed
on
different platforms (for example one content can be purchased on pc and viewed
in part on TV and other parts on 3G phone).
•
Data Warehouse : The
variety
SeaChange®
Video
Server
can
record
a
wide
of information that provide system operators with a comprehensive view of
system operation. Information can
scheduled
for execution
at
be
specific
obtained
interactively,
or
can be
times. Scheduled reports can be configured
to be run daily, weekly or monthly. A complete schedule of reports can be set
through the administration screens.
7.1 Axiom Core Functions
The Core Services designates the essential functions that manage core on-demand network
resources (servers, bandwidth, storage, etc.). Core services are the heart of every on-demand
system, automatically optimizing network resources to serve requests from every client in the
most efficient manner possible.
Session and Resource Manager Service – manages network bandwidth to insure that content
can be delivered efficiently. It presents a highly available interface for requesting the streaming
of video and controlling the streaming process. It presents a logically abstracted deliverynetwork-independent interface to the client or service.
Propagation Service – optimizes both network usage and storage by continually monitoring
demand for content, and moving content to locations where it is needed most. Allowing you to
maximize your capital investments ensures that popular content is replicated to the edge servers
closest to clients, and less popular content is moved to central locations. Operational staffing
requirements are minimized because replica management across the network is completely
TPQ-GP55-DOC-0126
Version 0.7
45
automated.
Connection Manager Service – mediates client requests, establishing the shortest path
between the client and the requested content. The Connection Manager ensures that content is
streamed from the closest storage location to the requesting client, delivering a high quality user
experience with minimal latency.
Asset Manager Service – manages the life cycle of content stored on the system. Content is
typically created, uploaded, activated, deactivated and deleted by the Asset Manager in
accordance with business rules supplied by the operator. The Asset Manager provides full
visibility into the location and state of managed content through a browser-based GUI. recording
Service – captures broadcast programs and publishes them as VOD content. The Recording
Service can simultaneously ingest multiple channels of broadcast content inreal time, which are
then distributed to the VOD system for on-demand viewing by clients. Capabilities in this service
include ‘playout while record,’ enabling time-shifted viewing of broadcast TV programs.
Axiom fault-resiliency
To help ensure that the services running on the Command Center server remain available in the
event of server failure, the Command Center servers are typically paired together in twin-server
Command Center clusters running Legato® Corporation’s CoStandbyServer™. It provides a bidirectional failover mechanism so that, in the event of a hardware failure on one Command
Center cluster member, the surviving member (in addition to maintaining its own tasks)
automatically assumes the tasks and the identity of the failed member, permitting continuing
operation of all ITV services ordinarily provided by both members of the cluster.
To support the CoStandbyServer failover mechanism, both servers in a Command Center cluster
maintain identical Windows registry configurations and identical file sets on their respective C:\
drives. Each server maintains a dedicated, high-speed Ethernet link to its partner over which the
instances of CoStandbyServer software running on each machine communicate with each other
and continuously monitor the operational status of both systems.
Automatic Failover
When CoStandbyServer detects and verifies that a failure has occurred on one of the cluster
members, it automatically ‘moves’ (fails over) the failed server’s failover group from its home
server location to its away server location on the surviving cluster member which, in addition to
TPQ-GP55-DOC-0126
Version 0.7
46
its own tasks, begins performing the tasks of its failed companion.
For example, if a failure is detected on Server 1, the CoStandbyServer software running on
Server 2 automatically moves the Server 1 failover group to Server 2 and (while continuing to
process its own tasks) starts the services listed in Server 1’s failover group on Server 2. After the
transplanted services have successfully completed their startup sequences, all services
ordinarily provided by both cluster members will be running on Server 2.
VOD server: HDS 200
This video server is designed for deployment as a standalone server or as part of MediaCluster
configurations, with several MediaServer HDS units forming a single virtual server providing
fault-resilience with SeaChange’s patented RAID2® advantages.
The SeaChange MediaServer HDS 200TM – based on commodity technologies – is a leap
forward in economically delivering a greater number of simultaneous video streams and video
assets in slim line 2RU rack system. With up to six MediaServer HDS units per cluster, operators
can reliably offer more than 1,600 hours of VOD programming to thousands of subscribers from
a single cluster.
The flexibility of the MediaServer HDS is marked by its ability to provide a range of output types
– including Gigabit Ethernet for IP transport of MPEG, On2, Windows Media and many other
advanced compression formats. The MediaServer HDS provides guaranteed delivery of video
output to meet the challenges of television operations and their demanding subscribers.
The unsurpassed capacity and modular scalability of SeaChange’s VOD System is derived from
its patented MediaCluster technology, working in tandem with the System’s automated
Command Center software or several standards-based VOD back office software packages. Our
MediaCluster technology permits the addition of servers to a rack and the addition of racks to a
system.
MediaCluster enables a single copy of video to be accessible to every output in the cluster movie, commercial, TV program - to support thousands of simultaneous viewers, thereby
significantly reducing the stream cost for a large video library with maximum reliability.
MediaServer HDS includes best-of-breed technology components, including off-the-shelf disk
TPQ-GP55-DOC-0126
Version 0.7
47
drives, Windows® Server 2003 operating software, high performance processors, switched PCI
buses and a range of standard network interfaces optimized for video.
7.2 VOD architecture: Axiom command centre and the VOD servers
AXIOM is the command center for the VOD: it has all the logic and the processes to ingest
content, generates trick files, propagate the content to the video server, order a VOD
server to start streaming etc.
The Video Server is the streamer: it sends the VOD mpeg stream to the STB.
The network communication conducted between and among the various component systems and
services that make up the VOD system is logically divided into the following categories:
TPQ-GP55-DOC-0126
Version 0.7
48
The management network, also called Server-to-Server network is used for the servers
to communicate together. The communication on the server-to-server network consists
primarily of control data, messaging, and other high-priority communication. So the
servers will be manageable from this interface usually using Mstsc (Microsoft Remote
Desktop).
The Propagation network is the network where the content is copied from the ingestion
point to the media cluster. In our example, this is very simplistic: it is just a link between
the Axiom command center and the video server. In a live deployment, this dedicated
network is key because the assets (mpeg files) are transiting through it.
The Client-to-Server network is where all the traffic between the set top boxes and the
servers flow. For the VOD, it mainly consists in control commands (DSMCC) and web
traffic generated by TV business when the subscriber browses the VOD catalog.
The Video Delivery network is the network that connects the media source (VOD server)
and the cable set-top boxes used by the subscriber. The first part between the VOD server
and the QAM is also called transport network (usually based on IP). The second part
between the QAM and the set top box is RF: the set top box tunes into an RF channel to
see the VOD. Please note that the VOD server REQUIRES an active Gigabit Ethernet
(GigE) port to stream.
Asset Manager Workstation
The VOD Asset Manager Workstation provides a complete asset management system that can
download content files from a Content Receiver, create assets, add and modify information
about VOD sites, applications, and assets. The VOD Asset Manager Workstation includes the
following software components:
Asset Manager Application
Service Management Utility
Encryption and Trick File (ETF) Service
TPQ-GP55-DOC-0126
Version 0.7
49
Asset Distribution Interface (ADI) Service
The VOD Asset ManagerPLUS Workstation is a central asset manager location to which assets
are downloaded. Assets can then be copied and distributed to multiple VOD sites from the VOD
Asset ManagerPLUS Workstation. A VOD Asset ManagerPLUS workstation is used to move
assets to multiple VOD sites from which the assets are streamed. The VOD Asset
ManagerPLUS Workstation includes the following software components:
Asset Manager Application
Service Management Utility
Encryption and Trick File (ETF) Service
Asset Distribution Interface (ADI) Service
Propagation Service (PS)
Directory Service (DS)
Asset Manager Service (IAM)
The VOD Asset Manager Workstations include these software components:
Asset Manager Application
The Asset Manager application is the component you use to manage and monitor VOD System
assets. This application allows you to set up system information, such as VOD site information,
default values, and default behavior for the system. You can add and modify asset information,
import or export assets, and find and respond to errors.
Service Management Utility
The Service Management Utility displays information about the variables associated with various
SeaChange VOD System services. The values of service variables can help you troubleshoot
the VOD System.
Encryption and Trick File Service (ETF)
The ETF service is used to encrypt content and to create the trick files of the encrypted content
before the Propagation service loads the content files to the Upload cluster.
Asset Distribution Interface Service (ADI)
TPQ-GP55-DOC-0126
Version 0.7
50
The ADI service provides a method to transfer assets from a content provider to multiple Asset
Management Systems.
Propagation Service (PS)
The Asset ManagerPLUS workstation requires the Propagation service to manage the work
queue entries correctly. However, when the Propagation service is on the Asset ManagerPLUS
workstation, it does not load content files for VOD assets onto the VOD MediaClusters.
Directory Service (DS)
The Asset ManagerPLUS workstation requires the Directory service, which maintains the asset
management data for a VOD site. It manages and controls access to the Master Directory
database, which stores the asset management information.
Asset Manager Service (IAM)
The Asset ManagerPLUS workstation requires the Asset Manager Service, which manages a
VOD site’s assets. It imports assets from asset data files, monitors and manages assets and
asset elements throughout their life cycle, stores and maintains asset management data in the
Directory database, and maintains the work queue that shows work that must be completed
automatically by another service or manually by an operator.
SQL Database
The Asset ManagerPLUS workstation requires the MS SQL 2000 database.
7.3 Features
Receives assets imported from a Content Receiver
Stores asset information (metadata) in the VOD master Directory database
Lets you configure VOD site information, such as the addresses of the Directory Server,
details about automatic import, and information about content providers
Lets you add and modify information about VOD applications (for example, Movies on
Demand)
Allows you to manually add or modify all asset information
TPQ-GP55-DOC-0126
Version 0.7
51
Allows you to pre-encrypt content files and generate the corresponding trick files
Allow you to view the status of assets within the VOD System, and manage the assets
(modify, remove, or move)
Lets you monitor work queues
Lets you inspect assets that have been loaded into the VOD MediaClusters, but have not
yet been made available to subscribers
AMPLUS workstation allows copying files to local sites
TPQ-GP55-DOC-0126
Version 0.7
52
8. Networking Part of IPTV
TPQ-GP55-DOC-0126
Version 0.7
53
8.1 IP Addressing and Naming convention
Following are the VLAN details defined for IPTV network.
Sl.#
VLAN Name
Description
IP Range
Mask
1
5
NMS
Management
192.168.5.0
255.255.255.0
2
120
FTA
Free to Air Channels
192.168.120.0 255.255.255.0
3
121
IPTVSBEN
IPTV Servers Back End Network
192.168.121.0 255.255.255.0
4
122
IPTVSFEN
IPTV Servers Front End Network
192.168.122.0 255.255.255.0
5
123
VoDDN
VoD Delivery Network
192.168.123.0 255.255.255.0
6
124
VoDPN
VoD Propagation Network
192.168.124.0 255.255.255.0
7
125
Premium1
Pay channels
192.168.125.0 255.255.255.0
9
126
Premium1 Enc
Encrypted Channels to Network
192.168.126.0 255.255.255.0
10
127
Premium2
Pay Channels
192.168.127.0 255.255.255.0
11
128
Premium2 Enc
Encrypted Channels to Network
192.168.128.0 255.255.255.0
Sl.#
1
2
3
4
5
6
7
Subnet Purpose
IPTV - DCM pair 1
IPTV - DCM pair 2
IPTV - DCM pair 3
IPTV - DCM pair 4
IPTV - DCM pair 5
IPTV - DCM pair 6
IPTV - DCM pair 7
TPQ-GP55-DOC-0126
Subnet
239.232.1.0
239.232.2.0
239.232.3.0
239.232.4.0
239.232.5.0
239.232.6.0
239.232.7.0
Version 0.7
Mask
255.255.0.0
255.255.0.0
255.255.0.0
255.255.0.0
255.255.0.0
255.255.0.0
255.255.0.0
54
BDC-DC2
Services
Server Name
Server IP address
DC-Switch Name
DC-Switch Port
IPTV
DCM1-1
192.168.120.101
BDC-DC2
Gi 10/25
IPTV
DCM2-1
192.168.120.109
BDC-DC2
Gi 10/26
IPTV
DCM3-1
192.168.120.117
BDC-DC2
Gi 10/27
IPTV
DCM4-1
192.168.125.101
BDC-DC2
Gi 10/28
IPTV
DCM5-1
192.168.125.109
BDC-DC2
Gi 11/29
IPTV
DCM6-1
192.168.127.101
BDC-DC2
Gi 11/30
IPTV
DCM7-1
192.168.127.109
BDC-DC2
Gi 11/31
IPTV
DCM1-2
192.168.120.105
BDC-DC2
Gi 10/32
IPTV
DCM2-2
192.168.120.113
BDC-DC2
Gi 10/33
IPTV
DCM3-2
192.168.120.121
BDC-DC2
Gi 10/34
IPTV
DCM4-2
192.168.125.105
BDC-DC2
Gi 10/35
IPTV
DCM5-2
192.168.125.113
BDC-DC2
Gi 10/36
IPTV
DCM6-2
192.168.127.105
BDC-DC2
Gi 10/37
IPTV
DCM7-2
192.168.127.113
BDC-DC2
Gi 10/38
SA
BDC-DC4
Service
Server Name
Server IP address
DC-Switch Name
DC-Switch Port
Axiom -AM
192.168.121.63
BDC-DC4
Gi 10/26
192.168.124.63
BDC-DC4
Gi 11/4
192.168.121.64
BDC-DC4
Gi 10/27
192.168.124.64
BDC-DC4
Gi 11/5
192.168.122.64
BDC-DC4
Gi 11/6
192.168.121.65
BDC-DC4
Gi 10/28
192.168.124.65
BDC-DC4
Gi 11/7
192.168.122.65
BDC-DC4
Gi 11/8
192.168.121.71
BDC-DC4
Gi10/29
192.168.123.71
BDC-DC4
Gi11/9
192.168.124.71
BDC-DC4
Gi 11/10
192.168.121.72
BDC-DC4
Gi 10/30
192.168.123.72
BDC-DC4
Gi11/11
192.168.124.72
BDC-DC4
Gi 11/12
192.168.121.73
BDC-DC4
Gi 10/31
192.168.123.73
BDC-DC4
Gi11/13
192.168.124.73
BDC-DC4
Gi 11/14
192.168.121.74
BDC-DC4
Gi 10/32
192.168.123.74
BDC-DC4
Gi11/15
192.168.124.74
BDC-DC4
Gi 11/16
Seachange
IPTV
IPTV
Axiom -DS
IPTV
IPTV
IPTV
IPTV
IPTV
Axiom -DS
Seachange Srv1
Seachange Srv2
Seachange Srv3
Seachange Srv4
SA
IPTV
DCM1-1
192.168.120.103
BDC-DC4
Gi 10/19
IPTV
DCM2-1
192.168.120.111
BDC-DC4
Gi 10/20
DCM3-1
192.168.120.119
BDC-DC4
Gi 10/21
TPQ-GP55-DOC-0126
Version 0.7
55
IPTV
DCM4-1
192.168.125.103
BDC-DC4
Gi 10/22
IPTV
DCM5-1
192.168.125.111
IPTV
Gi 10/23
IPTV
DCM6-1
192.168.127.103
BDC-DC4
Gi 10/24
IPTV
DCM7-1
192.168.127.111
BDC-DC4
Gi 10/25
IPTV
DCM1-2
192.168.120.107
BDC-DC4
Gi 10/12
IPTV
DCM2-2
192.168.120.115
BDC-DC4
Gi 10/13
IPTV
DCM3-2
192.168.120.123
BDC-DC4
Gi 10/14
IPTV
DCM4-2
192.168.125.107
BDC-DC4
Gi 10/15
IPTV
DCM5-2
192.168.125.115
BDC-DC4
Gi 10/16
IPTV
DCM6-2
192.168.127.107
BDC-DC4
Gi 10/17
IPTV
DCM7-2
192.168.127.115
BDC-DC4
Gi 10/18
IPTV
Boot/App/Admin Srv
192.168.121.11
BDC-DC4
Gi 10/33
192.168.123.11
BDC-DC4
Gi 10/34
IPTV
DB
192.168.121.12
BDC-DC4
Gi 10/35
Cypher Broadcast Srv1
192.168.121.47
BDC-DC4
Gi 10/36
192.168.125.47
BDC-DC4
Gi 10/37
192.168.126.47
BDC-DC4
Gi 10/38
192.168.121.46
BDC-DC4
Gi 10/39
192.168.127.46
BDC-DC4
Gi 10/40
192.168.128.46
BDC-DC4
Gi 10/41
192.168.121.45
BDC-DC4
Gi 10/42
192.168.124.45
BDC-DC4
Gi 11/17
192.168.121.42
BDC-DC4
Gi 10/43
192.168.122.42
BDC-DC4
Gi 10/44
Minerva
WideVine
IPTV
IPTV
IPTV
IPTV
Cypher Broadcast Srv2
Cypher VOD Srv
Cypher Core Srv
IPTV
Cypher EIM Srv
192.168.121.43
BDC-DC4
Gi 10/45
IPTV
Cypher EMMG Srv
192.168.121.44
BDC-DC4
Gi 10/46
192.168.122.44
BDC-DC4
Gi 10/47
With respect to the Networking part for IPTV, detail designing is described in the “Data Center
Design Documentation, TPQ-GP55-DOC-0143 “.
TPQ-GP55-DOC-0126
Version 0.7
56
9. Booting Process
STB initial process of proceeding for Booting up with various vendor components and their
respective versions
•
Middleware: Minerva iTVManager 3.1
•
Conditional Access: Widevine 4.0.x
•
Video on Demand: SeaChange 3.5.2.525
•
Set Top Box: SA IPP 330
Sequential steps and the procedure for Booting Process and Renting an Asset
Flow during the Booting Process of STB
1. From the STB to the DHCP Server
The STB boots up
The internal OS starts
The STB asks a DHCP address from the Data Center server
The DHCP Server assigns an IP address to the STB
2. From the STB to the CAS
The STB with the assigned IP starts the client/communications with the CAS
3. From the STB to the Middleware
The STB starts the communications with iTVManager to gather the info needed
MW info: Subscribers, Channels, Subscribed channels, etc…
Flow during the Renting of an Encrypted Asset
1. From the STB to the Middleware
The STB requests to purchase an asset from the asset list
The request reaches iTVManager
2. From the Middleware to the CAS and back to the STB
iTVManager sends the key-request to the CAS
TPQ-GP55-DOC-0126
Version 0.7
57
iTVManager sends playback info (VOD location) to the STB
3. From the CAS to the STB and from the STB to the VOD server
The CAS gives the key to the STB
The STB sends playback request to the Video Server
10. References
1.
2.
3.
4.
5.
TPQ-GP55-DOC-0119, “ Network Requirements for The Pearl Qatar IPTV Solution ”
TPQ-GP55-DOC-0143, “ Data Center & Services Module BoD”
TPQ-GP55-DOC-0125, “ Metro Ethernet Infrastructure BoD ”
TPQ-ITV-GP55-DWG-0001, “ IPTV HeadEnd System Design for BDC”
TPQ-ITV-GP55-DOC-0002, “ Channel List ”
6. TPQ-ITV-GP55-DWG-0003, “ IPTV HeadEnd System for PDC ”
TPQ-GP55-DOC-0126
Version 0.7
58