Architecture of IPTV Edition

Transcription

Microsoft TV IPTV Edition 1.1
Revision 2006-09-15-1200
Microsoft Confidential
Architecture of IPTV Edition (2006-09-15-1200) 1
© 1996-2006 Microsoft Corporation. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means,
electronic, mechanical, photocopying, recording or otherwise, without the prior written consent of the publisher.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed
as of the date of publication. Because Microsoft Corporation must respond to changing market conditions, it should not be
interpreted to be a commitment on the part of Microsoft Corporation, and Microsoft Corporation cannot guarantee the
accuracy of any information presented. This document is for informational purposes only. MICROSOFT CORPORATION
MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Microsoft Corporation may have patents
or pending patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this
document. The furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other
intellectual property rights. Microsoft Corporation does not make any representation or warranty regarding specifications
in this document or any product or item developed based on these specifications. MICROSOFT CORPORATION
DISCLAIMS ALL EXPRESS AND IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND FREEDOM FROM
INFRINGEMENT. Without limiting the generality of the foregoing, Microsoft Corporation does not make any warranty of
any kind that any item developed based on this document, or any portion of the document, will not infringe any copyright,
patent, trade secret, or other intellectual property right of any person or entity in any country. It is your responsibility to
seek licenses for such intellectual property rights where appropriate. Microsoft Corporation shall not be liable for any
damages arising out of or in connection with the use of these specifications, including liability for lost profit, business
interruption, or any other damages whatsoever.
ActiMates, Active Accessibility, Active Desktop, Active Directory, ActiveMovie , ActiveStore, ActiveSync, ActiveX,
Advisor FYI, Age of Empires, Age of Mythology, Amped, Authenticode, Automap, AutoRoute, AutoRoute Express,
AutoRoute Plus, AutoSum, Azurik, BackOffice, Bankshot Billiards, BattleTech, bCentral , BizTalk, Blinx, Blood Wake,
Bookdings, Bookshelf, Brigand, Brute Force, Bungie, Candara, Carpoint, ClearLead, ClearType, Computing Central,
Constantia, Cortana, Crimson Skies, DataTips, DaunPenh, Devastator, Developer Studio, Dexterity, Digital Anvil,
Direct3D, DirectAnimation, DirectBand, DirectDraw, DirectInput, DirectMusic, DirectPlay, DirectShow, DirectSound,
DirectX, Encarta, Ensemble Studios, Entourage, Exhibition, FASA Studio, Finty Flush, Fist of the Lotus, Forza
Motorsport, Freelancer, Fringer, FrontPage, Fuzion Frenzy, Georgia, Great Plains, Halo, HDCD, Hexic, HighMAT, High
Road to Revenge, HomeAdvisor, HomeClick, Home Essentials, Hotmail, InfoPath, Inside Pitch, IntelliEye, IntelliMirror,
IntelliMouse, IntelliSense, IntelliShrink, IntelliSpeed, Iskoola Pota, J/Direct, Jawbreaker, JScript, Kung Fu Chaos,
LineDrive, Links, LinkExchange, Links Extreme, Liquid Motion, Mapbase, MapManager, MapPoint, MapVision, Marine
Mania, MechAssault, MechCommander, MechWarrior, Microsoft, Microsoft Power Sense, Microsoft Press, Microsoft
TaxSaver, Midtown Madness, Monster Truck Madness, Motocross Madness, Mozaki, MS-DOS, MSDN, MSN, Music
Central, Natural, NetMeeting, Nina, OneNote, OpenType, OptiMatch, Outlook, OutSmart, PGR, Phantom Dust,
PhotoDraw, Picture It!, PivotChart, PivotTable, PowerPoint, Precision Racing, Project Gotham Racing, Quantum Redshift,
QuickShelf, Realmation, Realty Desktop, Revenge of Arcade, Revenue Avenue, Rise of Nations, Rise of Perathia,
Rushmore, SharePoint, ShapeSheet, SideWinder, Slate, SmartConnectors, SmartScreen, SmartShapes, Sneakers,
Starlancer, Starts Here, Sudeki, Tahoma, Tao Feng, Tex Murphy, The Age of Kings, The Time Sweeper, The Unseen,
TipWizard, Top Spin, Trekker, TrueImage, TutorAssist, UltimateTV, Verdana, VGA, Virtual Golf Association, Visio,
Visual Basic, Visual C++, Visual C#, Visual FoxPro, Visual InterDev, Visual J++, Visual J#, Visual Web Developer,
Visual SourceSafe, Visual Studio, Voodoo Vince, WebBot, WebCourier, Webdings, WebTV, WebTV Network,
Whacked!, Win32, Win32s, Windows, Windows Media, Windows Mobile, Windows NT, Windows Server, Windows
Server System, WinFX, Wingdings, XBN, Xbox, Xbox Live, XNA, Your Potential. Our Passion., ZoneFriends, ZoneLAN,
ZoneMessage, and Zoo Tycoon are either registered trademarks or trademarks of Microsoft Corporation in the United
States and/or other countries. All other company, brand, and product names may be registered trademarks or trademarks of
their respective companies and are hereby recognized.
© The Royal National Institute For the Blind and Bitstream Inc. All Rights Reserved. Tiresias is a trademark of The Royal
National Institute For the Blind.
Your right to copy this documentation is limited by copyright law and the terms of the software license agreement. As the
software licensee, you may make a reasonable number of copies or printouts for your own use. Making unauthorized
copies, adaptations, compilations, or derivative works for commercial distribution is prohibited and constitutes a
punishable violation of the law.
2 Architecture of IPTV Edition (2006-09-15-1200)
Documentation Feedback
We welcome your feedback. You can provide feedback in either of the following ways:
•
Fill out a copy of this brief form with your comments and send it to
[email protected].
•
Ignore the form and send a free-form email to [email protected].
Note Your feedback to [email protected] is converted to a documentation bug,
which is triaged, tracked, and handled by the IPTV Edition documentation team.
Product
Release
Your name
Your job
Document you were using
Document date or version
Task you were trying to do
Information you were looking for
Comments:
Contents
Architecture of IPTV Edition ...............................................................................8
Using Architecture of IPTV Edition ....................................................................................... 12
Audience........................................................................................................................... 12
Other Documentation ....................................................................................................... 12
High-Level Architecture ......................................................................................................... 14
Live TV Subsystem................................................................................................................. 21
Functional Flow................................................................................................................ 22
Live TV Subsystem Software Components and Data Flow ............................................. 24
Live TV Acquisition Subsystem ...................................................................................... 25
Live TV Acquisition Subsystem Software Components and Data Flow................... 27
Live TV Delivery Subsystem ........................................................................................... 29
Live TV Delivery Subsystem Software Components and Data Flow ....................... 34
DServer/Client Command and Control ..................................................................... 36
Multiple Identical Live TV Delivery Subsystems ..................................................... 38
Scalability......................................................................................................................... 39
Video on Demand Subsystem ................................................................................................. 41
Functional Flow................................................................................................................ 41
Functional Flow for Regionally-Distributed VOD Clusters............................................. 43
VOD Subsystem Software Components and Data Flow .................................................. 46
VOD Media Servers ......................................................................................................... 48
VOD Clusters and Load Balancing .................................................................................. 49
Adaptive Asset Allocation......................................................................................... 50
Adaptive File Copy and Distributed Ingest ............................................................... 51
VOD Assets and Content Aggregation............................................................................. 51
VOD Trick Streams.......................................................................................................... 52
VOD Acquisition Subsystem ........................................................................................... 53
VOD Delivery Subsystem ................................................................................................ 54
VOD Asset Security ......................................................................................................... 57
Integrating a Branch with an EQoS Interface................................................................... 58
Integrating a Branch with an EPOC System .................................................................... 58
RDP Application Subsystem................................................................................................... 59
RDP Application Subsystem Software Components........................................................ 59
Windows Server Terminal Services .......................................................................... 60
TServer Windows Service ......................................................................................... 60
Terminal Server Session Starter ................................................................................ 61
RDP Application Launcher........................................................................................ 61
TServerProxy COM+ Service.................................................................................... 63
Terminal Server Controller Private Web Service ...................................................... 63
Terminal Server Controller Public Web Service ....................................................... 63
Terminal Server Controller Database ........................................................................ 63
Windows Applications............................................................................................... 63
Connecting to RDP Sessions ............................................................................................ 64
Tracking Terminal Server Sessions .................................................................................. 65
Securing RDP Sessions..................................................................................................... 65
Managing RDP Sessions on Each Terminal Server.......................................................... 66
Scaling, Load-Balancing, and Failover............................................................................. 67
Web Service Router................................................................................................................. 68
Asset Store Subsystem............................................................................................................. 70
Electronic Program Guide Subsystem ..................................................................................... 72
Listing File Format.............................................................................................. 74
Channel Maps ..................................................................................................... 75
EPG Subsystem Software Components and Data Flow...................................... 76
Media Discovery Subsystem ................................................................................................... 78
Service Information Subsystem............................................................................................... 80
Bootstrap Web Service ............................................................................................................ 82
Discovery Windows Service ................................................................................................... 84
Sync Windows Service............................................................................................................ 85
Subscriber Management Subsystem ........................................................................................ 86
Service Group Subsystem........................................................................................................ 89
Service Group Subsystem Software Components ............................................................ 89
Service Group Database............................................................................................. 91
Web Services in Service Groups ...................................................................................... 92
Service Group SMS Management Web Service...................................................................... 94
Branch Management Subsystem ............................................................................................. 95
Bootstrap and Redirection ................................................................................................ 96
Databases in the Branch.................................................................................................... 96
Web Services in the Branch.............................................................................................. 97
Notification Subsystem............................................................................................................ 98
Message Delivery and Heartbeat Protocol...................................................................... 100
DVR Scheduler Subsystem ................................................................................................... 104
DVR Scheduling in a Multiple Set-Top Box Environment ............................................ 105
DVR Scheduler Subsystem Software Components and Data Flow................................ 105
User Store Subsystem............................................................................................................ 107
User Store Subsystem Software Components and Data Flow........................................ 107
Session Key Authority Subsystem ........................................................................................ 109
Search Web Service .............................................................................................................. 110
Logging Subsystem............................................................................................................... 112
Logging Subsystem Software Components and Data Flow ........................................... 117
Client Management Subsystem............................................................................................. 120
Client Management Subsystem Software Components and Data Flow ......................... 120
NTP Server............................................................................................................................ 122
TV Services Management Tool............................................................................................. 125
Multiple and Simultaneous Interactions with TV Services Management Tool.............. 126
OSS Web Services ................................................................................................................ 128
Backend Blackout Management Web Service ............................................................... 129
Blackout Management Web Service .............................................................................. 130
Branch Management Web Service ................................................................................. 131
Channel Management Web Service ............................................................................... 131
Diagnostics Notification Web Service ........................................................................... 132
EPG Web Service........................................................................................................... 133
Live Backend Management Web Service ...................................................................... 133
PPV Management Web Service ..................................................................................... 133
Remote Recording Web Service .................................................................................... 134
UI Notification Web Service .......................................................................................... 134
URL Management Web Service..................................................................................... 136
VOD Backend Management Web Service ..................................................................... 136
VOD Branch Management Web Service........................................................................ 136
BSS Web Services................................................................................................................. 138
Billing Record Management Web Service ..................................................................... 139
Grant Management Web Service.................................................................................... 139
Offer Management Web Service .................................................................................... 140
Package Management Web Service ............................................................................... 140
Principal Management Web Service .............................................................................. 141
Reporting Store Web Service ......................................................................................... 141
IPTV Edition Client .............................................................................................................. 143
User Interface Framework.............................................................................................. 144
Data Exchange................................................................................................................ 145
Audio/Video Service Support ........................................................................................ 146
DVR Engine, Storage, and Management........................................................................ 147
RDP Application Support............................................................................................... 147
Bootstrap and Client Authentication .............................................................................. 148
Client Remote Control.................................................................................................... 149
Client Upgrade................................................................................................................ 150
Multiple Client Households ............................................................................................ 150
Set-Top Boxes With and Without Hard Disks......................................................... 151
Client Streams.......................................................................................................... 151
Index....................................................................................................................153
This document defines the overall logical architecture of Microsoft® TV IPTV Edition (IPTV
Edition). It emphasizes key software components and their interfaces and illustrates how they
support IPTV Edition deployments.
In This Section
Using Architecture of IPTV Edition (p. 012)
Describes the intended use of this document and where to find related information.
High-Level Architecture (p. 014)
Provides a high-level overview of the IPTV Edition software architecture.
Live TV Acquisition Subsystem (p. 025)
Describes the software subsystem that acquires live TV services and generates full-screen
and PIP streams.
Live TV Delivery Subsystem (p. 029)
Describes the software subsystem that receives live TV services from the live TV
acquisition subsystem.
VOD Acquisition Subsystem (p. 053)
Describes the software subsystem that imports video on demand (VOD) assets and
generates media and metadata files for delivery to one or more VOD delivery
subsystems.
VOD Delivery Subsystem (p. 054)
Describes the software subsystem that deploys VOD assets that are available on a VOD
RDP Application Subsystem (p. 059)
Describes the software subsystem that lets subscribers run remote Windows® applications
through the Windows Remote Desktop Protocol (RDP).
Web Service Router (p. 068)
Describes the software that brokers all communications between IPTV Edition client
devices and client-facing Web services.
Asset Store Subsystem (p. 070)
Describes the software subsystem that stores metadata for RDP applications and VOD
assets that subscribers can browse, run, and, if necessary, purchase.
Electronic Program Guide Subsystem (p. 072)
Describes the software subsystem that acquires listings data from third-party listings
services.
Media Discovery Subsystem (p. 078)
Describes the software subsystem that provides media descriptions that include content
metadata and information about how to access the content.
Service Information Subsystem (p. 080)
Describes the software subsystem that provides a central directory for all IPTV Edition
services.
Bootstrap Web Service (p. 082)
Describes the software that authenticates IPTV Edition clients and logs them on to the
IPTV Edition system.
Discovery Windows Service (p. 084)
Describes the software that provides clients with the location of resources that they can
contact during regular startup or to recover from client software failure.
Sync Windows Service (p. 085)
Describes the software that provides clients with an initial application that they can run at
startup when they are recovering from a failure.
Subscriber Management Subsystem (p. 086)
Describes the software subsystem that provides a central repository for information about
subscriber entitlements.
Service Group Subsystem (p. 089)
Describes the subsystem that stores account-specific data.
Branch Management Subsystem (p. 095)
Describes the subsystem that provides a central database for subscriber information and a
Web service through which it defines the assignment of accounts to the appropriate
service groups.
Notification Subsystem (p. 098)
Describes the software subsystem that enables IPTV Edition services send messages to
subscribers.
DVR Scheduler Subsystem (p. 104)
Describes the software subsystem that manages DVR recording schedules.
User Store Subsystem (p. 107)
Describes the software subsystem that provides a generic mechanism for saving and
retrieving persistent name/value pairs.
Session Key Authority Subsystem (p. 109)
Describes the software subsystem that generates, signs, and disseminates symmetric AES
keys to IPTV Edition components.
Search Web Service (p. 110)
Describes the software subsystem that manages IPTV Edition client requests for media
descriptions for media that meets various search criteria, such as title or actor names.
Logging Subsystem (p. 112)
Describes the software subsystem that manages the various “events” generated by the
server software components and IPTV Edition clients.
Client Management Subsystem (p. 120)
Describes the software subsystem that enables IPTV Edition service providers to upgrade
software on clients in the field.
NTP Server (p. 122)
Explains how the IPTV Edition system uses Network Time Protocols (NTP) to
synchronize time between client and servers as well as between servers. By using NTP,
both senders and receivers can establish the same understanding of time, leading to the
correct interpretation of time stamps.
TV Services Management Tool (p. 125)
Describes the software subsystem that provides a Web-based UI through which IPTV
Edition system operators manage live TV, VOD, and RDP application services.
OSS Web Services (p. 128)
Describes the software subsystems that enable the TV Services Management tool and
other OSS systems to manage the acquisition and delivery of live TV, VOD, and RDP
application services.
BSS Web Services (p. 138)
Describes the software subsystems that enable network operator billing systems to
integrate with the IPTV Edition system.
IPTV Edition Client (p. 143)
Describes the software subsystem that acquires video and data services and renders them
to subscriber video and audio systems.
Using Architecture of IPTV Edition
Microsoft® TV IPTV Edition (IPTV Edition) enables the delivery of high-quality live TV and
video on demand (VOD) over diverse IP network infrastructures. It is a robust platform that
also enables service providers to offer compelling interactive TV services to subscribers, such
as RDP applications, an Electronic Program Guide (EPG), and a digital video recorder
(DVR).
Audience
This document is intended for anyone who needs to understand how IPTV Edition software
components interact with one another. It assumes that you are already familiar with the
features of IPTV Edition and need to understand how those features are implemented. For
information about IPTV Edition features, see Product Overview.
Other Documentation
The IPTV Edition software distribution includes technical documents that represent the state
of the IPTV Edition system at the time of publication. The following table provides pointers
for locating additional IPTV Edition information.
For details on this
See this document
IPTV Edition system features
Product Overview
Finding information in the IPTV Edition
Using the Documentation
documentation set
Encoding video for delivery as VOD assets
VOD Encoding Guide
Creating metadata for VOD assets
VOD Metadata Guide and
Reference
Designing and implementing custom applications for
Application Developer’s Guide
IPTV Edition
Configuring, monitoring, and maintaining IPTV
Operations Guide and Reference
For details on this
See this document
Edition
Customizing the client user interface
User Interface Customization
Guide
High-Level Architecture
The following diagram illustrates the logical organization of software components in the
IPTV Edition system.
In an IPTV Edition system, live TV, VOD, and RDP application services are first acquired
and then delivered to IPTV Edition clients. For example, IPTV Edition acquires live TV
services, which may arrive in a variety of formats, and then processes the streams to provide
full-screen and PIP versions of the services in a uniform manner so they can be delivered
from backend sites to one or more branches using Real-Time Protocol (RTP).
Some IPTV Edition subsystems perform the acquisition and delivery functions directly, while
others perform a supporting role so that subscribers can discover and select the services they
want to view. For example, the live TV acquisition subsystem processes incoming live TV
services. Similarly, the VOD acquisition subsystem imports VOD assets. In contrast, the
media discovery subsystem provides service descriptions that appear in program listings.
IPTV Edition defines a set of application programming interfaces (APIs) through which IPTV
Edition service providers can integrate their business support systems (BSS) and operations
support systems (OSS) with IPTV Edition.
To coordinate the management of services and service information, custom applications can
use a set of OSS Web services that let operators manage the entire system across their
networks. IPTV Edition includes a Web application called the TV Services Management tool
which uses the OSS Web services and provides a user interface for managing IPTV Edition
services.
Service providers can integrate business support systems through a set of BSS Web services
that provide an API for managing subscriber accounts, devices, billing events, service
packages, offers, and service entitlements.
Many subsystems contain a set of components (typically Web services and databases) that
can be distributed across multiple security zones to support each operator’s security policies.
IPTV Edition also provides a dedicated Web service router that brokers all communications
between IPTV Edition clients and the client-facing Web services.
The following table summarizes each IPTV Edition system software component.
Component
Description
Live TV acquisition subsystem (p.
Acquires live video services and generates full-
025)
screen and PIP streams. Encodes streams with the
Windows® Media Audio and Video 9 Series
codecs in VC-1 and H.264 format for full-screen
content and VC-1 for picture-in-picture (PIP)
streams. Encrypts and encapsulates streams in RTP
transport streams for unicast or multicast delivery
to one or more live TV delivery subsystems.
Note If the incoming service does not require
live capture, only the PIP streams are encoded
with the Windows Media® Audio and Video
Series 9 codecs.
Live TV delivery subsystem (p.
Receives live TV services from the live TV
029)
acquisition subsystem. Manages the delivery of
Component
Description
AV streams to IPTV Edition clients over IP
unicast. Deployed on machines known as
Distribution Servers (DServers).
VOD acquisition subsystem (p.
Ingests video on demand (VOD) assets and
053)
generates media and metadata files for deployment
to one or more VOD delivery subsystems.
VOD delivery subsystem (p. 054)
Deploys VOD assets that are available on a VOD
acquisition subsystem. Includes a set of Media
Store virtual directories that deliver the VOD
streams to clients on request over HTTP.
RDP application subsystem (p.
Lets subscribers run remote Web or Windows
059)
applications through the Windows Remote
Desktop Protocol (RDP).
Web service router (p. 068)
Brokers all Web service communications (SOAP
over HTTP) between IPTV Edition client devices
and client-facing Web services.
Session Key Authority subsystem
Generates, signs, and disseminates symmetric AES
(p. 109)
keys to IPTV Edition components.
Asset Store subsystem (p. 070)
Stores metadata for RDP applications and VOD
assets that subscribers can browse, run, and, if
necessary, purchase.
Electronic Program Guide subsystem
Acquires listings data from third-party listings
(p. 072)
services. Delivers listings to the media discovery
subsystem, which delivers the listings to IPTV
Edition clients.
Listings data share
Offers EPG listings in GLF format. May reside at
third-party listings data provider site.
Media discovery subsystem (p.
Provides media descriptions that include content
078)
metadata and information about how to access the
content. Exposes two identical Web services that
Component
Description
support requests from the server-facing tier and the
Web tier.
Service information subsystem (p.
Provides a central directory for all IPTV Edition
080)
services. The service information (SI) subsystem
provides IPTV Edition clients with the information
they need to acquire video services.
Service Group Subsystem (p. 089)
The subsystem that stores account-specific data.
Branch Management Subsystem (p.
Provides a central database for subscriber
095)
information and a Web service through which it
defines the assignment of accounts to the
appropriate service groups.
Subscriber management subsystem
Provides a central repository for information about
(p. 086)
subscriber entitlements. The bootstrap Web service
uses the subscriber management subsystem (SMS)
to determine if subscribers are legitimate and
allowed to access the service. The SMS also stores
billing events when clients make purchases and
exposes a Web service through which service
provider BSS systems can modify billing-related
data.
Bootstrap Web service (p. 082)
Authenticates IPTV Edition clients and logs them
on to the IPTV Edition system. Contacts the SMS
to determine the subscriber status. Returns a list of
URLs for Web services (terminal service monitor,
client upgrade, and so on) from which the IPTV
Edition client can acquire configuration data.
Discovery Windows Service (p.
Provides clients with the location of resources that
084)
they can contact during regular start-up or to
recover from client software failure, should one
occur.
Sync Windows Service (p. 085)
Provides clients with an initial application that
they can run at startup when they are recovering
Component
Description
from a failure.
Notification subsystem (p. 098)
Lets IPTV Edition services send messages to
subscriber devices. Part of the IPTV Edition
Extensibility Framework.
Custom applications can also send messages to
IPTV Edition clients through the UI notification
and diagnostics notification Web services.
DVR scheduler subsystem (p. 104)
Manages DVR recording schedules. Notifies
clients to start and end recordings through the
notification subsystem.
User store subsystem (p. 107)
Provides a generic mechanism for saving and
retrieving persistent name/value pairs.
Search Web Service (p. 110)
Manages IPTV Edition client requests for media
descriptions for media that meets various search
criteria, such as title or actor names.
Logging subsystem (p. 112)
Manages the various “events” generated by the
server software components and IPTV Edition
clients. Collects service logs and subscriber
activity events, such as channel changes, and saves
logs in a server-side database.
TV Services Management tool (p.
Provides a Web-based UI through which IPTV
125)
Edition system operators manage live TV, VOD,
and RDP application services.
Client management subsystem (p.
Lets IPTV Edition service providers upgrade
120)
software on clients in the field.
OSS Web services (p. 128)
Let the TV Services Management tool and other
OSS systems manage the acquisition and delivery
of live TV, VOD, and RDP application services.
The OSS Web services include:
•
Backend blackout management Web
Component
Description
service.
BSS Web services (p. 138)
•
Blackout management Web service.
•
Branch management Web service.
•
Channel management Web service.
•
Diagnostics notification Web service.
•
EPG Web service.
•
Live backend management Web service.
•
PPV management Web service.
•
Remote recording Web service.
•
UI notification Web service.
•
URL management Web service.
•
VOD backend management Web service.
•
VOD branch management Web service.
Let service provider billing systems integrate with
IPTV Edition. The BSS Web services include:
•
Billing record management Web service.
•
Grant management Web service.
•
Package management Web service.
•
Offer management Web service.
•
Principal management Web service.
•
Reporting store Web service.
Service providers’ operations support
Provide the service provider’s operations and
systems and business support
billing services. Typically in place for an existing
systems
subscriber base, these systems integrate with the
IPTV Edition system through the OSS and BSS
Web services.
IPTV Edition integrates with the service provider’s
OSS and BSS systems by exposing a set of Web
services.
Component
Description
The Web services enable external OSS and BSS
systems to import and export data (get and set
operations). Traditionally, these systems include
the service provider billing subsystem and the
SMS.
IPTV Edition client (p. 143)
Acquires video and data services and renders them
to subscriber video and audio systems.
Live TV Subsystem
The live TV subsystem is responsible for acquiring live TV services from varied input
sources, processing the service content, and delivering live TV services to IPTV Edition
clients. The live TV subsystem also acquires and processes Pay Per View (PPV) content. PPV
content is acquired and processed the same as any other live TV service.
The live TV subsystem has a separated backend/branch model, where each branch requests
and distributes a subset of the services made available by the backend. This method provides
control over the distribution state of a live TV service and enables operators to provision
services in a managed fashion. Operators can control:
•
When a live TV service comes online.
•
Which acquisition group backend handles the service.
•
Which branches distribute the service to clients.
Using the TV Services Management tool in the acquisition group backend, an operator creates
live TV services. Operators in any branch can then deploy any published live TV service from
any authorized backend. After a branch deploys a live TV service and the service is deployed
to one or more DServers (Distribution Servers), all clients in the branch that have the
corresponding channel in their channel lineup and are authorized for the service gain the
ability to tune and watch the video.
The live TV subsystem consists of two subsystems:
•
Live TV acquisition subsystem. Responsible for acquiring and processing live TV
services and for producing Real-Time Protocol (RTP) streams. This subsystem
packages the RTP streams in multicast UDP packets and delivers them to the live TV
delivery subsystem and IPTV Edition clients. It also encrypts the content using DRM
technology, and makes the keys available for downstream branches to distribute to
their clients.
•
Live TV delivery subsystem. Responsible for the unicast delivery of live TV
services to IPTV Edition clients, providing instant channel change (ICC), and
reliable UDP.
Functional Flow
The following diagram illustrates the functional flow of a single live TV service from the
point of capture through the delivery to IPTV Edition clients. Details of the process are
described in subsequent sections.
Branch 1 and
Service Groups
4
3
Acquisition Group
Backend
1
IPTV
Edition
clients
Live TV delivery
subsystem
2
Encoder
Live TV acquisition
subsystem
Branch n and
Service Groups
4
3
Live TV delivery
subsystem
IPTV
Edition
clients
1) Live TV acquisition subsystems capture and process live TV services.
Backend operators use the TV Services Management tool to create and configure live
TV services. The configuration process defines the capture and process parameters,
such as the transport stream source, aspect ratio, and bit rate, for the live TV
Live TV acquisition subsystems reside in the acquisition group backend. A single
deployment can have one or more acquisition group backends. An acquisition group
backend can be deployed nationally, regionally, or locally.
For additional information on acquisition group backends, see Logical Deployment
Architecture (p. 011) in Installation and Configuration Guide. For addition
information on how to configure and publish a live TV service, see Operations Guide
and Reference.
2) Live TV acquisition subsystems multicast each live TV service on a unique multicast
address and port. While the multicast address must be unqiue, ports may be reused.
Multicast packets are received by both the live TV delivery subsystem and IPTV
Edition clients. Multiple branches and numerous clients can connect to a single
multicast live TV service coming from a live TV acquisition subsystem.
Branch operators use the TV Services Management tool to deploy live TV services
from the live TV acquisition subsystem. Each branch can deploy a different set of
live TV services. If a branch deploys a live TV service as unicast or MulticastICC,
the live TV delivery subsystem receives the multicast stream from the live TV
acquisition subsystem. If the service is deployed as multicast, the DServers ignore it
and the clients connect to it directly. Additionally, a process within the branch
periodically polls the backend to retrieve the keys needed by clients to view the
encrypted content.
When a live TV service is deployed, operators configure bulk delivery for the RTP
streams to be either point-to-point (unicast) from the live TV delivery subsystem, or
one-to-many from a multicast transmission. The distribution method for each live TV
service is configured separately for each branch.
If the live TV service is configured with unicast, clients receive all packets in the
RTP stream as a unicast transmission from the live TV delivery subsystem. In this
case, only the live TV delivery subsystem is listening to the multicast output from the
live TV acquisition subsystem.
If the live TV service is configured with ICC with IGMP (Internet Group
Management Protocol), clients receive some unicast packets (on startup and for
retries), but receive the bulk of the packets in the RTP stream directly from the
multicast stream sent by the live TV acquisition subsystem. In this case, both the live
TV delivery subsystem and the client could be listening to the multicast output from
the live TV acquisition subsystem. Each full-screen and PIP stream requires a unique
multicast IP address and port.
If a backend operator changes the parameters of a deployed live TV service, the
LiveBackendUpdateService, running at the branch, gets the changed values and uses
them to update the branch. LiveBackendUpdateService is a Windows® service
running at the branch that polls the backend periodically for any service data
changes.
3) Live TV delivery subsystems deliver the appropriate video content to clients.
If the live TV service is in the client’s channel map and the subscriber has access
rights to the live TV service, the client displays the live TV service when the
subscriber tunes to the appropriate channel. If a subscriber does not have access
rights, a secondary video service may appear. For live TV services, this secondary
service is typically some type of upsell trailer.
When the client tunes to a live TV service, the live TV delivery subsystem bursts the
live TV service to the client, enabling the client to begin displaying live video very
quickly. In the case of unicast delivery, this connection is kept open. In the case of
ICC with IGMP, the client switches over to multicast after the initial burst is
complete. The Distribution Server (DServer) and client communicate through
command and control packets. Client authentication occurs during each command
and control packet exchange.
There is a special optimization for channels deployed using ICC with IGMP in the
case where a program is being recorded on the client’s DVR “in the background”
(that is, it is not being displayed while it is being recorded). In this case, because
instant channel change is not required, the client will simply join the multicast stream
directly, and use the DServer for retries.
4) If the client detects lost packets, it requests the lost packets from the live TV delivery
subsystem. The client requests that the lost packets be delivered from the DServer to
which it is connected. Each session is bound to a particular DServer. Note that if the
client is connected to more than one streaming service at a time, each of those
sessions are handled independently, and may or may not actually be sourced from the
same DServer machine.
Live TV Subsystem Software Components and Data Flow
The following diagram shows the live TV subsystem software components and a very simple
data flow. This diagram does not take scalability into account.
See Also
Live TV Acquisition Subsystem
The live TV acquisition subsystem is an installation of hardware and software modules that
take live MPEG transport streams as TV data feeds and converts them into RTP streams. Live
TV data feeds come from multiple media sources:
•
Real-time hardware encoders, such as VC-1, H.264, or MPEG-2 encoders.
•
Spooled files on a local hard disk drive, such as MF files containing Windows media
audio and video, with only a single audio stream.
•
Pre-encoded digital input streams from sources such as a satellite system.
The live TV acquisition subsystem is responsible for:
•
Capturing live TV streams from external sources, delivered to the Acquisition Server
over multicast UDP. This includes capturing a secondary audio program (SAP) if the
service is configured to do so.
•
Generating VC-1 picture-in-picture (PIP) streams.
PIP streams are a lower resolution, lower bit rate, video-only version of a live TV
service. PIPs are typically used as a preview service for a channel other than the one
the subscriber is currently viewing.
•
Encrypting video and audio elementary streams (full-screen video and audio,
secondary audio, and PIP video).
•
Generating keys, and rotating which keys are used for encryption on content
boundaries as dictated by OSS and DRM, and storing the keys in a database. Once
the service has been deployed on the branch, these keys are kept up to date at the
branch using a polling mechanism.
•
Encapsulating streams into RTP for multicast delivery to the live TV delivery
subsystem and, depending on the configuration, to IPTV Edition clients through the
service provider’s multicast-enabled network.
•
Marking the RTP stream with the appropriate Macrovision analog content protection
control bits. The control bits instruct the IPTV Edition client to add analog content
protection to the outgoing analog live TV stream.
Encoding
The live TV acquisition subsystem accepts external streams as MPEG transport, UDP
multicast.
Pre-encoded, full-screen services are packed into RTP packets. Pass-through streams are RFC
2250 (any externally generated stream). Local streams are MF-RTP, such as spooled channels
and Acquisition Server-generated PIPs. The DServer and client can handle either type of RTP
stream.
The live TV acquisition subsystem can generate a PIP stream for each live TV service, but
not does not necessarily do so for each stream. Having the Acquisition Server generate the
PIP locally greatly decreases scalability. The live TV acquisition subsystem must first decode
the stream, scale it down to the defined resolution, and then encode the PIP stream.
Externally-generated PIPs, such as those created by the real-time encoders, are managed by
the Acquisition Server as a separate process, and the streams are encrypted and passed
through as usual.
Failover Scenario
Upon failure detection, operators manually change service assignments from one Acquisition
Server to another. An OSS API is also provided, allowing an operator to write an automated
script which detects failed servers and performs automated failover. This requires configuring
a designated backup Acquisition Server in the cluster. When failure is detected, the keys used
by the initial Acquisition Server are reloaded by the new Acquisition Server, and the service
continues after a brief interruption.
See Also
Live TV Subsystem (p. 021)
Live TV Acquisition Subsystem Software Components and Data Flow
boundary keys
boundary key
request
The following diagram shows the software components of the live TV acquisition subsystem.
encoder
NIC
boundary
service
boundary keys
request config info
keys
boundary keys
service config info/
service assignments
service config info/
service assignment
request
Acquisition Group Controller
acquisition
acquisition
Windows
Windows
Acquisition
service
service
Server
LiveBackend
database
RTP transport streams
Retry packets
Retry requests
Live TV
Acquisition Subsystem
The following table describes the software components of the live TV acquisition subsystem.
Component
Description
Acquisition Group
Coordinates live TV, PPV, and blackout acquisition activities across
Controller
the Acquisition Servers and delivers the appropriate service details
(also known as the
to other IPTV Edition server components to enable delivery of
acquisition group
controller Web
service)
streams and keys to IPTV Edition clients. A single Acquisition
Group Controller can control multiple Acquisition Servers. The
Acquisition Group Controller configures and coordinates the
activities of the Acquisition Servers. During startup, the Acquisition
Group Controller reads the service configuration information from
the live backend database and builds a table of Acquisition Servers
that are responsible for acquiring these services. All communications
between the controller and the servers are HTTP connections
initiated by the server. There is no way for the controller to initiate a
connection to an acquisition server. The detection of whether a
server is properly configured is done when the server periodically
connects to the controller and asks for instructions. Crash detection
is done by seeing how long it has been since a particular server
connected to the controller and asked for instructions.
Acquisition Server
Captures, repackages, encrypts, and delivers live TV streams from
(also known as the
external sources. In some cases, the live TV stream will be decoded
IPTV Edition
Acquisition
Windows service)
and the video reencoded at a lower resolution. The Acquisition
Server can also repackage or play back pre-encoded streams.
Acquisition Servers use processes to provide a way to group similar
full-screen and PIP services. A process is a task which must be
performed by a single server, such as reading a network stream,
generating a PIP, and emitting both services. Processes can manage
network input or disk input.
An IPTV Edition installation can have any number of Acquisition
Servers with each Acquisition Server process running on an
individual machine. The data that emerges from the Acquisition
Server includes:
•
Boundary keys.
•
Encrypted full-screen services (audio and video, and
possibly subtitles, teletext, and a variety of other content).
•
Encrypted PIP services (video only).
Component
Description
Acquisition Servers can be clustered together. A cluster is the unit of
network configuration and failover aggregation. A server belongs to
no more than one cluster, and cannot support a process unless
assigned to a cluster. Acquisition Servers cannot support a process
unless assigned to a cluster because the cluster is what tells the
Acquisition Server which subnet(s) to use for ingress, egress, and so
on.
Communication between the Acquisition Server and the Acquisition
Group Controller follows a polling model. The Acquisition Server
periodically asks the Acquisition Group Controller for updated
service information. If services are added to or removed from the
database, the Acquisition Server makes the appropriate updates to its
current services. If a particular server does not poll for a certain
amount of time, an alarm is raised.
Live backend
Contains the list of services defined in the live TV subsystem, their
database
associated properties, the cluster configurations, the list of servers in
the backend, and keys associated with services. The Acquisition
Group Controller uses this information when configuring the
Acquisition Servers. The information is modified through the TV
Services Management tool or through external OSS Web services.
Live TV Delivery Subsystem
The live TV delivery subsystem sits near the edge of the service provider’s network. It
monitors one or more RTP streams emitted by the live TV acquisition subsystem, and
delivers the services to clients. This subsystem consists of a DServer controller and multiple
DServers. The DServer controller manages a group of DServers. DServers distribute services
to clients, perform ICC, and handle reliable UDP. DServers can receive and deliver live TV
services on the same or different subnets. Operators define one or more ingress, egress, and
retry subnets for the live TV delivery subsystem to use using the TV Services Management
tool. For additional information, see Configuring Live TV Services (p. 083) in Operations
Guide and Reference.
The live TV delivery subsystem handles only point-to-point (unicast) delivery of RTP
streams to IPTV Edition clients. Multicast RTP streams do not originate through this
subsystem although it does use them to support ICC with IGMP.
Instant Channel Change
ICC is a tuning methodology that significantly reduces the time required for a live TV service
to appear on an IPTV Edition client after a channel change.
Switching channels in a digital environment is inherently slower than switching channels in
an analog system. The delay is primarily caused by the wait for the start of a Group of
Pictures (GOP), or key frame, before the client displays the live TV service. Another source
of delay is that the client must cache enough frames to prevent buffer underflow.
To minimize this delay, the DServer maintains a continuously updated circular buffer of the
entire recent content of the stream. When a client requests a channel change from the live TV
delivery subsystem, the selected DServer unicasts cached stream content, starting with an Iframe, to the IPTV Edition client at an accelerated rate. The rate is configurable through the
Services Management Tool at deployment time. Because the first frame is always an I-frame,
the wait for an I-frame is completely eliminated, and the wait for the buffering to be satisfied
is also greatly reduced because data is arriving at a faster than normal data rate, allowing the
client to begin playing back before a pure multicast tune would.
After the live TV delivery subsystem sends enough cache content to “catch up” to live TV, it
backs off to sending new video content at the nominal bit rate of the stream. The burst
duration varies depending on the content of the stream, its associated GOP distance, and its
maximum STC/DTS delay. Generally, the shorter those values, the shorter the ICC burst will
be. Typical streams as deployed today will have burst durations between six and 15 seconds.
Provisioning DServer bandwidth depends on expected client activity. If there are 10,000
clients, and each of them changes channels once a day at a different time, you do not need to
provision nearly as much bandwidth in the DServer as if each client channel changes once a
second. The more bandwidth that is reserved for each ICC burst, the less overlap there is
between channel changes, but the more bandwidth must be available to each household.
ICC with IGMP
ICC with IGMP (Internet Group Management Protocol) is an intermediate tuning
methodology between pure multicast tuning and unicast ICC. It uses the live TV delivery
subsystem to enable the client to see full-motion video with the same response time as the
ICC model. Like ICC, the live TV delivery subsystem unicasts a burst of video frames to the
client at an accelerated rate. After the client buffers enough data to prevent an underflow
condition (which can be between 1 and 5 seconds of video content depending on the encoding
parameters), the client returns to listening to an ordinary multicast stream.
During the switch to IGMP, some packets are typically dropped, based on the data rate of the
stream and speed of the IGMP join process. The DServer backfills these packets before the
client needs to access them. The time between the channel tune request and the multicast
switchover point can vary depending on the stream parameters, how far the initial I-frame
was from the actual live stream, and the bandwidth reserved for unicast.
There is a trade-off between the length of time the client must remain attached to the DServer
at the burst data rate and the amount of network bandwidth used for the initial burst.
Whenever a client connects to a managed stream from the DServer, the DServer picks a
keyframe from some point in the past in its buffer, and begins transmitting data to the client
from that point in the stream (thus enabling ICC). That initial time difference can be called
the “delay time.” For the DServer to catch the client up to the “live stream,” the DServer must
burst data at some higher data rate until it transfers not only all of the original delayed data,
but also all additional data that came in during the transfer.
If the nominal bit rate of the stream is 1 and the ratio of extra bandwidth available for the
burst is “E,” the amount of time that the client must remain connected to the burst to catch up
to live (“burst time”), is as follows:
burst time = (delay time)/E
As the delay time increases, without modifying the amount of extra bandwidth reserved, the
burst time increases. As the amount of extra bandwidth available for ICC increases, the
amount of burst time required decreases. However, the amount of aggregate output bandwidth
which must be reserved per subscriber on the DServer does not simply rely on the amount of
extra burst bandwidth provisioned. It also relies on the amount of time that a client spends in
the burst state.
Note Both full-screen and PIP streams can be delivered using ICC and ICC with IGMP.
Reliable UDP
The live TV delivery subsystem implements a mechanism for delivering reliable live TV over
RTP/UDP. This technique is used between the live TV acquisition subsystem and live TV
delivery subsystem, as well as between the live TV delivery subsystem and clients. The retry
mechanism between the live TV acquisition subsystem and the live TV delivery subsystem
can be disabled at the branch, disabled on a service-by-service basis at the branch, or disabled
on a service-by-service basis at the backend. All services deployed as ICC or ICC with IGMP
will have reliable UDP implemented between the delivery system and the client.
When delivering RTP packets over UDP (as is the case for multicast delivery from the
Acquisition Server, and unicast delivery from the DServer), the RTP header is directly
embedded behind the UDP header.
Packet headers are not encrypted nor are RTP headers or the PES (packetized elementary
stream) headers within the content; only the elementary stream data is encrypted.
If a client drops one or more UDP packets, it reports the session ID and the missing packet
sequence numbers to the live TV delivery subsystem over the command and control protocol.
The live TV delivery subsystem then resends the dropped packet or packets.
The retry protocol does not report missing packets immediately, because packets may be
reordered during delivery. Periodically, the client makes an analysis of any holes it currently
has in the RTP stream and reports all or a subset of those holes to the DServer to which the
client is connected. The DServer examines the report and resends the missing packets.
Note The time period between client hole analyses is 100 milliseconds. This value is not
currently configurable.
Retries are always delivered over the same network connection that the original unicast was
delivered over for the connection between the DServer and client. For the connection between
the Acquisition Server and DServer, retry traffic can be routed over a separate connection.
Failover Scenario
While an IPTV Edition client is connected to a DServer, it periodically sends a command and
control packet to the DServer and requests the status of the stream. If the connection fails or
times out, the client knows that there is a problem with the DServer. The client disconnects
from the DServer, selects another DServer from its service-to-DServer map, and tries to
connect to the new DServer.
If the first reconnect is successful, the subscriber perceives, at worst, only a few seconds of
interrupted services. If the client was in the “multicast” portion of an ICC with IGMP channel
session, the subscriber might not perceive a service interruption. However, if all of the
DServers on the client’s current map reject the tune, and the service was originally deployed
as ICC with IGMP, the client simply joins the service in “pure multicast” mode, and channel
changing is correspondingly slower. If the service is deployed as “unicast ICC,” the client
does not know the multicast address, and therefore cannot join directly.
Each individual DServer rejects connections that it cannot handle within its bandwidth
allocation. If this occurs, the client switches to another DServer handling the same service. If
all DServers reject the tune, and the service was originally deployed as ICC with IGMP, the
client joins the stream through pure multicast. The channel change time for pure multicast is
large compared to the tune time for ICC.
If a client is tuned to a channel for the purposes of “background digital video recording” (the
stream is recording a stream but not currently displaying), there is no penalty for having a
slightly slower channel tune. To improve system scalability, the client immediately joins the
service in multicast mode. The client also initiates a connection to the DServer to service
retries, so that later viewing of the content has a complete packet stream.
Service Replication
For scalability and redundancy purposes, live TV service delivery is spread across multiple
servers within a live TV delivery subsystem. A Distribution Server (DServer) is the server
machine in the live TV delivery subsystem that delivers live TV content to clients. When
operators define a live TV service in the IPTV Edition system, they assign a percentage of
DServers to manage the distribution of the service. This percentage is called the replication
constant.
The replication constant is specified on a percentage basis. For example, if there are 100
DServers and the replication constant for a given service is set to 80%, 80 of the DServers
distribute that live TV service.
Live TV Delivery Subsystem Software Components and Data Flow
The following diagram shows the live TV delivery subsystem software components.
usage statistics
configuration
information
usage statistics
service assignments/
config info request
service assignments/
config info
DServer Controller
live
configuration
state Web
service
service
usage
assignments/
stats
config info
service-toDServer map
Web service
config
info
service-to-DServer
map request
(HTTP)
service
assignments
BranchDB database
RTP Streams
(UDP multicast)
RTP Streams
(UDP unicast)
DServer
command and control
(UDP)
retry packets
(unicast)
Live TV Delivery Subsystem
The following table describes the software components in the live TV delivery subsystem.
Component
Description
DServer Controller
Manages DServers and coordinates the distribution of RTP
(also known as the
streams.
DServer controller
Each DServer Controller can manage multiple DServers.
Web service)
Live configuration
Exposes a Web service interface that enables external resources
state Web service
such as the live branch management Web service to update the
content in the live configuration state database.
BranchDB database
Contains the configuration information for each live TV service
deployed in the live TV subsystem. It also contains the mapping
between live TV services and the DServers that distribute them.
Service-to-DServer
Exposes a Web service interface that enables clients to obtain the
map Web service
service-to-DServer map. This map tells clients which DServer is
Component
Description
distributing which live TV services.
A table inside the BranchDB database describes which services are
assigned to each DServer. The DServer Controller goes through
the table and, for each service, randomly selects two DServers
from the list. It collates the entries into the service-to-DServer map
and returns it to the client.
DServer
Unicasts live TV services (RTP streams) to clients. The DServer
(also known as the
also handles ICC and manages dropped packet requests.
DServer Windows
service)
See Also
DServer/Client Command and Control
All communication between DServers and IPTV Edition clients is through UDP. Before a
DServer responds to a client command and control packet, the client is authenticated. In
addition, all command and control packets are encrypted.
To overcome UDP’s inherent unreliability, IPTV Edition sends command and control packets
multiple times to ensure that the destination receives at least one copy of the packet. The
number of times a packet is sent is configurable; the default value is two.
Each packet starts with a twelve byte RTP header, followed by a four byte DServer Command
and Control header. The following table contains the set of commands that are sent between
the DServer and IPTV Edition clients.
Value
Description
Sent By
0x01
Join request
Client
0x02
Retry request
Client
0x04
Leave
Client
Value
Description
Sent By
0x08
Status (for example, stat or ping)
Client
0x81
Join response
DServer
0x82
Burst complete
DServer
0x84
Known hole in stream
DServer
0xFF
Error
DServer
DServer Error Codes
The following are the error codes that are sent from the DServer.
Error Code
Description
Additional Information
0x0001
Service not buffered yet
Service GUID
0x0002
Retry packet requested is not valid
SSRC and sequence number
0x0003
No such service
Service GUID
0x0004
No such session
Session GUID
0x0005
Bad session
Session GUID
0x0006
Unsupported command and control
None
version
0x0007
Server full
None
0xFFFF
Session destroyed by server
Session GUID
Command and Control Data Exchange
The following diagram shows a “join service” command and control exchange between a
DServer and an IPTV Edition client, illustrating how the UDP packets sent open a hole for
bidirectional communication through any intermediate firewalls.
Multiple Identical Live TV Delivery Subsystems
In a typical IPTV Edition system, a single live TV delivery subsystem delivers all live TV
service to all clients in a branch. The live TV subsystem can be configured to enable separate,
identical live TV delivery subsystems to service different physical locations without the
operational overhead of maintaining multiple branches.
The following diagram illustrates such a configuration.
In this illustration, service groups A and B are two different cities. The live TV delivery
subsystems are physically located in these cities. The Branch Management machine and the
two live TV delivery subsystems all reside in the same logical branch. The Branch
Management machine can be physically located in either one of the two cities.
When an operator deploys a service (or performs any service maintenance function), the
service is automatically deployed to both live TV delivery subsystems.
For this feature to work, the backend database and Web services see only one live TV
delivery subsystem. Each DServer has a domain name service (DNS) name that matches a
DServer in the other live TV delivery subsystem. The DNS resolution is set up so that clients
in service group A connect to DServers in service group A, and clients in service group B
connect to DServers in service group B.
For this feature to work the system must be set up with the following:
•
Each live TV delivery subsystem must be identical. There must be the same number
of DServers in each subsystem.
•
Clients use DNS names instead of IP address to access DServers.
•
DServers are configured with corresponding DNS names from the server layout file.
Scalability
Live TV subsystem components can be distributed throughout a service provider’s network to
ensure optimum acquisition and delivery of live TV services. The overall acquisition goal is
to process any unique live TV service only once. Live TV services should be acquired at the
point that best aligns with their distribution range. For example, if a service provider’s
network contains a super headend office (SHO) and multiple video hub offices (VHOs), you
would configure the live TV acquisition subsystems to acquire national services at the SHO
and local services at each of the VHOs. The individual VHOs can deliver all, some, or none
of these services to their respective clients. The live TV delivery subsystems (distribution
points) are located in the VHOs closest to the clients.
The following diagram depicts this example.
You use the TV Services Management tool to define which live TV services are acquired by
which live TV acquisition subsystem. Similarly, you also use this tool to define which
services are deployed to which live TV delivery subsystems.
See Also
Video on Demand Subsystem
The video on demand (VOD) subsystem is responsible for acquiring VOD assets and
delivering them to IPTV Edition clients. Typically, VOD assets are created and managed by
third-party content providers, who make the assets available to service providers.
IPTV Edition supports the production, acquisition, and delivery of VOD services through a
set of subsystems that can be deployed in one or more sites. The VOD subsystem uses a
publish/subscribe (or deploy) method for distributing VOD assets. This method enables
operators to control the distribution state of VOD assets for each individual branch while
maintaining one or more centralized VOD backends.
Functional Flow
The following diagram illustrates the high-level steps for importing, publishing, and
deploying VOD assets within a VOD subsystem based on one cluster for each branch.
1) Content providers use third-party professional encoding tools to encode the VOD
assets. During this process, they define the VOD encoding parameters such as aspect
ratio, output resolution, bit rate, quality, and buffer window. For more information
about the compression parameters, see VOD Encoding Guide.
Content providers also define the initial VOD asset metadata using the IPTV Edition
VOD Asset Creator tool. The VOD Asset Creator tool formats the metadata for the
main feature, trailer, and the poster art. It also enables the operator or content
provider to define the business rules (for example, sales period and price) and the
rights information (for example, rental window). For details, see VOD Assets and
Content Aggregation (p. 051).
2) Content providers deliver VOD assets through a secure mechanism such as a virtual
private network (VPN) or Catcher System to the VOD asset folder at the service
provider’s site.
3) VOD backend operators can modify some, but not all, of the metadata values.
Modifications might include such things as the purchase price or the rental time
frame. For more information on the metadata that service providers can modify, see
“Modifying VOD Asset Metadata at the Backend” in Operations Guide and
Reference.
4) VOD backend operators use the VOD Asset Management tool to import VOD assets.
The VOD acquisition subsystem imports and processes VOD assets stored in the
VOD assets folder. It encrypts VOD assets with DRM keys and generates Real-Time
Protocol (RTP) streams for the main feature and trick streams. It then stores the
generated content in the Staging folder. For details, see VOD Acquisition Subsystem
(p. 053).
5) Branch operators choose the assets to deploy to the VOD delivery subsystem or have
assets deployed automatically. This causes the VOD asset to be copied from the
VOD backend to the selected clusters in the branch. For details, see VOD Delivery
Subsystem (p. 054).
After deployment, branch operators can modify the VOD metadata to reflect branchspecific parameters.
6) Subscribers purchase and then view a VOD asset.
7) The VOD Controller ensures the VOD subsystem can support the additional VOD
session before it allows the subscriber to view the VOD asset. Each client request to
the VOD subsystem is authenticated to ensure that only valid clients are accessing
VOD assets. For additional information on the VOD Controller, see VOD Delivery
Subsystem (p. 054).
Functional Flow for Regionally-Distributed VOD Clusters
The following diagram illustrates the high-level steps for importing, publishing, and
deploying VOD assets within a VOD subsystem based on multiple clusters for each branch.
For more information about each step, see Functional Flow (p. 041).
Servers can be positioned closer to the set-top box when necessary due to bandwidth
constraints. To configure this, for each geographical region the operator sets up one cluster
and one subscriber group. The TV Services Management tool on the Branch Management
machine or OSS APIs is used to associate the subscriber groups to the clusters.
Note A VOD cluster should be associated with only one subscriber group.
When the VOD Map Server receives a request from a set-top box, one of the following cases
applies:
•
The subscriber is in only one subscriber group, and that subscriber group is
associated with one cluster.
•
If the associated cluster has the requested asset, it returns two servers from the
cluster.
•
•
If the associated cluster does not have the asset, it returns an error code.
The subscriber is in more than one subscriber group, but only one of the subscriber
groups is associated with a VOD cluster.
•
•
If the associated cluster has the asset, it returns two servers from the cluster.
•
If the associated cluster does not have the asset, it returns an error code.
The subscriber is in one or more subscriber groups; however, none are associated
with a VOD cluster. Any cluster that has the asset can provide it to the subscriber's
set-top box.
•
The subscriber is in more than one subscriber group, and more than one of those
subscriber groups is associated with a VOD cluster.
•
Any associated cluster that has the asset can provide it to the subscriber's set-top
box.
•
•
If none of the associated clusters have the asset, an error code is returned.
The subscriber is in one or more subscriber groups, and one or more of those
subscriber groups is associated with multiple clusters.
•
Any associated cluster that has the asset can provide it to the subscriber's set-top
box.
•
If none of the associated clusters have the asset, an error code is returned.
After a cluster is selected, the load balancing algorithm is applied to select the right server
and interface within that server.
Note A server is assigned to a specific cluster through an entry in the serverlayout.xml file.
VOD Subsystem Software Components and Data Flow
The following diagram shows the software components of the VOD subsystem and the data
that flows between the components. It also shows how the VOD subsystem interacts with
other IPTV Edition subsystems to deliver VOD assets to IPTV Edition clients.
The division of VOD acquisition and delivery subsystems enables each to be installed and
operated by one organization or for the VOD acquisition subsystem to be outsourced to a
separate organization. In either case, the VOD delivery subsystem must have secure access to
the VOD acquisition subsystem to access the assets in the Staging folder.
The following table describes each software component, server, and storage location used in
the VOD subsystem.
Component
Description
Asset folder
Contains the pre-imported VOD assets. The VOD import process looks for
the VOD assets in this folder. The location of this folder is configurable.
VOD assets must be transferred to this folder after acquiring them from a
content provider. For additional information on the asset store subsystem,
see Asset Store Subsystem (p. 070).
Component
Description
Import
Contains the status of each asset that the VOD import process imports.
status
database
BranchDB
Database that stores the states of all assets and VOD Server machines.
database
VOD
Provides a client-facing Web service interface through which clients obtain
catalog Web
VOD metadata.
service
When an IPTV Edition client needs to construct a Video on Demand screen,
it contacts the VOD catalog Web service to obtain a list of VOD assets and
categories. The VOD catalog Web service contacts the subscriber
management subsystem (SMS) to look up the subscriber to determine which
assets the subscriber is entitled to view. The VOD catalog Web service
returns the complete URL of each VOD asset. The VOD catalog Web
service is not responsible for tracking VOD locations (service information).
VOD import
Exposes an interface through which the VOD backend Web service controls
process
the import process.
During import, it takes VOD assets (content and metadata) from the asset
folder and encrypts and generates the RTP format files for the full-screen
and trick streams. These processed files are then placed in the Staging
folder with the corresponding metadata and DRM key files.
Staging
Contains imported VOD asset files. During deployment these files are
folder
copied from this folder to the media servers at the branch.
VOD
Contacts the VOD Controller machine every n seconds with status
COM+
(including asset and session information).
Server
IIS
Responsible for streaming and authentication. On any connection changes,
Extension
IIS Extension updates the VOD COM+ Server machine.
Ingest
Uses a variety of methods of loading an asset into the server (http and
Adapter
https). Ingest Adapter can get assets from the peer VOD Server machines
during deployment and replication.
Component
Description
VOD Map
Directs clients to the appropriate server for delivering a VOD asset.
Server
VOD map
Provides an interface for set-top boxes to receive the URLs of asset
server Web
locations.
service
VOD
Tracks and controls the status of the VOD Server machines (including
Controller
Add/Update/Delete assets).
VOD
Handles communication between the VOD Server and VOD Controller.
controller
Web service
VOD
Provides an interface for all branch-related operations; for example,
branch Web
deployment and replication.
service
VOD
Provides an interface for all backend-related operations; for example,
backend
import and pre-processing, and Asset Store database access.
Web service
VOD
Provides a wrapper around the VOD branch Web service to allow managing
branch
assets through the VOD Management tool. For more information see VOD
management
Branch Management Web Service (p. 136).
Web service
VOD
Provides a wrapper around VOD backend Web service to allow managing
backend
assets through the VOD Management tool. For more information, see VOD
management
Backend Management Web Service (p. 136).
Web service
VOD Media Servers
The type of server to use for storing VOD assets depends on the performance expectations
and popularity of the stored assets:
•
RAM. A RAM-based media server serves assets from RAM, therefore, its disk
performance is slower but the egress capacity is higher. The VOD Controller puts the
most popular VOD assets on RAM-based media servers to fully utilize the faster
egress capacity.
•
DAS. A DAS-based media server serves assets from the hard disk, therefore, its
egress capacity is lower but it can accommodate more assets than a RAM server. The
VOD controller will put the all but the most popular VOD assets on the DAS-based
media server.
VOD Clusters and Load Balancing
VOD clustering optimizes the equipment required to deliver a diverse offering of VOD assets.
Operators can deploy assets based on their usage patterns. VOD assets that subscribers view
often are placed on high-capacity VOD clusters while assets with lower usage patterns are
served from lower-capacity VOD clusters. This enables service providers to optimize the
overall cost of the equipment required to manage and deliver VOD assets.
The VOD controller Web service is primarily responsible for managing the content on each
VOD cluster:
•
The operator configures VOD Server machines to be part of a VOD cluster (one
load-balanced IP address assigned per cluster). For more information, see Installation
and Configuration Guide.
•
The operator assigns content titles to each cluster. For more information, see
Operations Guide and Reference.
•
The VOD controller Web service manages the transfer of VOD content from the
VOD Backend database to each Media Store virtual directory in each cluster
according to the operator-defined content list.
To load balance, when a VOD Server boots up, it initializes itself by calling the VOD
controller Web service and registering itself. Thereafter, the VOD Server reports its status to
the VOD controller Web service every 10 seconds.
If for any reason, the VOD Server shuts down (either for normal maintenance or unexpected
failure); the VOD controller Web service detects its absence when it does not receive a status
update from that VOD Server. A maximum of 10 seconds will elapse before the server's
absence is detected. When the VOD controller Web service detects that the VOD Server has
shut down, it updates the database with this information. After that point, load balancing and
adaptive allocation continue with the assumption that this VOD Server is not available to
serve assets to clients. The VOD Server's former clients are re-directed through the failover
mechanism to another VOD Server that has the same asset that the client requested.
When the VOD Server reboots, it first initializes itself by calling the VOD controller Web
service and re-registering itself with the VOD controller Web service so that it is immediately
available to serve assets to clients.
When a request for an asset is received, the VOD Map Server machine uses its copy of the
database to determine which VOD Servers have the asset and which two of those servers are
currently the least loaded. Least loaded is defined as having the most remaining bandwidth
for the combined NICs on that server. The least-loaded NIC is selected from both VOD
Servers and is then used to deliver the asset to the client.
The VOD controller Web service knows the current load on each NIC on the VOD Servers,
where load is defined as the current bandwidth being used on that NIC. The configuration for
which NICs on the server to use for load-balancing clients is expressed in the vserver.xml file
as the maximum percentage of the bandwidth to use on a specific NIC (the default is 80%).
For more information about the vserver.xml file, see “Modifying the vserver.xml File for a
VOD Server” in Operations Guide and Reference.
Adaptive Asset Allocation
An asset is first deployed to configurable number of DAS servers (default 2) within the VOD
cluster. This initial deployment is done to the first server directly from the Staging folder,
over HTTP or HTTPS. If necessary for security reasons, the asset can first be copied to a
temporary file system that the VOD Controller machine has access to, where it will then be
copied to the Media Store server. The subsequent copies are made from the first server to the
second server through HTTP, using NTLM authentication.
After that, the asset is replicated to additional servers, as needed, based on demand. This
process is called adaptive allocation. The algorithm for determining whether the asset should
be replicated is as follows:
1) When a request comes in, the load balancing algorithm is used. If the selected
interface on the selected server is above a configured threshold (TA), then the process
continues with Step 2. The default for TA is 60%.
2) The media servers that have the asset are evaluated to see whether, if any one of the
servers went down, the remaining servers would exceed a configured threshold (TB,
default 80%), given the existing load of connections. If the answer is “yes,” the
process continues with Step 3. If the answer is “no,” there is no need to replicate the
asset to other servers.
3) Replication occurs. If the asset is more popular than the least popular asset in RAM,
the asset is replicated to a RAM-based Media Store server. If not, the asset is
replicated to a DAS-based Media Store server.
During replication, the system is analyzed to determine whether the asset fits in the
remaining storage. For RAM-based media servers, the asset will likely not fit, so the
least-used asset currently stored in RAM is removed from the server, after the VOD
Controller machine ensures that the remaining servers can handle the current
subscriber load. This may result in additional replication of the removed asset to
other RAM or DAS media servers. For DAS-based Media Store servers, there is a
configurable variable for determining how full the operator wants the hard disk
system to be.
Adaptive File Copy and Distributed Ingest
When an asset is delivered to a Media Store server, either for initial deployment or because of
adaptive allocation, the VOD Controller machine tells the server the rate at which to copy the
file. The VOD Controller machine selects the least-used NIC on both the receiving and (in the
case of replication) sending systems, and sets the rate so that it does not exceed a configured
maximum percentage of the remaining bandwidth below TB (the default setting is 80%). For
example, if the TB setting is 70%, the interface is capable of 1 Gbps, the adaptive copy
percentage is 50, and the current usage of the two interfaces is 600 Mbps and 500 Mbps, the
rate control should be set to 100 Mbps: (1000*.8 – 500)*.5.
VOD Assets and Content Aggregation
VOD content providers must deliver VOD assets in a specific format for service providers to
import them into the IPTV Edition system. Each VOD asset consists of a set of files that
include audio and video data and related metadata. Content providers can use any Windows®
Media 9, VC-1, or H.264 encoding tool that supports the IPTV Edition VOD compression
parameters, such as Windows Media® Encoder 9 Series.
The VOD asset files include:
•
The A/V content itself in Advanced Streaming Format (ASF) or MPEG Transport
Stream format (TS).
•
A trailer, in Media Frames or ASF format, which includes program metadata as well
as the A/V content itself.
•
Box or poster art in .jpg format.
•
Metadata describing the program (such as the feature title and actors), business data
(such as price), and rights metadata (such as rental window), in CableLabs ADI 1.1
or Microsoft® Metadata XML format.
•
Per category themes and background images in .jpg format.
VOD content providers can generate VOD metadata files with any XML or text editor.
If a VOD service does not contain the proper set of files, the IPTV Edition system aborts the
import process. VOD content providers should deliver VOD assets through secure
mechanisms.
Note IPTV Edition does not provide inventory or version control systems for managing
VOD assets. Each service provider is responsible for performing those tasks using other tools.
VOD Trick Streams
IPTV Edition supports the following methods for generating trick streams for a VOD asset:
•
High performance. This mechanism generates trick streams without decompressing
the original stream. Instead it uses the I-frames from the encoded main stream and
selects only the number necessary to produce the desired speed. It plays the I-frames
at a reduced number of frames per second to keep the trick stream bit rate equal to
the bit rate of the main stream. For this mechanism to work well, it is recommended
that the GOP size of assets that use it be no more than 1 second.
•
High quality. This mechanism sets the quality of the encoded trick streams. The
default setting is 30%. Trick streams are created and encoded in a single pass.
Increasing the compression quality setting increases the asset import time.
You can configure trick streams globally and on a per-asset basis. The per-asset settings
override the global settings. Trick streams can be configured only for an asset's main feature
files. You cannot create trick streams for an asset's trailer file.
Note Trick speed cannot be set through an asset's metadata. Trick speed is defined globally.
If trick streams are turned off through the global setting, the system can still have a global
trick speed setting that is used only when an asset's metadata specifically sets values for its
trick stream.
VOD Acquisition Subsystem
The VOD acquisition subsystem manages the VOD manual or automated import process. The
VOD import process takes a VOD asset (content and metadata) from a local asset folder and
generates a set of media and metadata files. The VOD import process generates the processed
assets in a specific location, known as the Staging folder. The IPTV Edition service provider
at the branch can selectively choose the assets to deploy with the VOD Asset Management
tool.
When an asset arrives, it will be automatically detected by the VOD pre-import process. The
VOD pre-import process performs the following tasks:
•
If the metadata included with the asset is in ADI format, converts it to MSFT
metadata format.
•
If rules are on and set, applies rules as appropriate.
•
Does basic repair such as making sure fields are not too long and case conversion.
Once the asset has been successfully pre-processed, it becomes available for import. The
VOD import process performs the following tasks:
•
Validates assets. Assets can be rejected as part of the import process. Rejection is
based on simple validation rules.
•
Generates trick stream files for use when the client fast forwards or rewinds.
•
Generates RTP streams for the main feature and trick streams.
•
Encrypts the assets and their associated DRM key files. The key file associated with
each RTP stream is encrypted using the backend certificate public key. The operator
installs the backend certificate on the VOD Import machine. During the deployment
process, the private key associated with the backend certificate is used for decrypting
the RTP stream’s key file. For information about the deployment process, see VOD
Delivery Subsystem (p. 054).
•
Stores encrypted RTP streams and encrypted DRM keys in the Staging folder for
deployment to various branches. The other metadata information (program, business,
rights metadata) is stored as an XML file associated with the asset.
•
Sets the Macrovision state for VOD assets to both attack color signaling and
composite output resynchronization. During VOD asset import, DRM tags each
frame of the RTP stream with the appropriate Macrovision analog content protection
control bits.
•
Generates index files (saved as .idx files). Each VOD asset also includes a set of
index files. An index file is a mapping of media times to byte offsets within the file.
For example, if you know you are 10 minutes into a movie and you want to fastforward to the place you left off, the client uses the trick stream index file to
determine where to start streaming the associated trick stream media file. Each VOD
asset has one index file for each generated VOD asset, full-screen, PIP, and all trick
streams.
VOD Delivery Subsystem
The VOD delivery subsystem manages the deployment and delivery processes. It optimizes
the equipment required to deliver a diverse offering of VOD assets through VOD clusters. A
VOD cluster is a set of server machines that is optimized for delivering VOD assets based on
their usage pattern. VOD assets that subscribers view most often are generally placed on
VOD servers with less storage capacity but higher availability, while assets with lower usage
patterns are served from VOD servers with more storage but less availability. This enables
providers to optimize the overall cost of the equipment required to manage and deliver VOD
assets.
A branch can have any number of VOD clusters. Each VOD cluster is registered in the
system using the VOD Asset Management tool and is associated with a set of VOD backends.
Branch operators manually manage the allocation of VOD assets between clusters by taking
advantage of the asset usage information. Asset usage information provides data on such
things as how many times a VOD asset was accessed in a particular time period. When a
branch operator deploys a VOD asset, they define the VOD clusters that distribute the asset
and the subscriber groups that receive the asset.
By default, IPTV Edition is configured with an Everyone subscriber group. VOD assets
deployed to the Everyone group are available to all subscribers. To deploy a VOD asset to a
specific set of subscribers, the operator must first define the appropriate subscriber groups.
For example, to test a new VOD asset before making it available for widespread purchase, the
operator can create a Test subscriber group and specify it when deploying the VOD asset.
Deploying an asset causes the VOD asset to be copied from the Staging folder in the VOD
backend to one or more of the VOD Servers in the specified cluster. Typically, it is copied to
at least two VOD Servers for redundancy. The number of servers to initially copy to is
configurable. The first copy is made from the Staging folder to the VOD Server. Subsequent
copies will be made from VOD Server to VOD Server to conserve bandwidth from the
backend to the branch. The VOD delivery subsystem updates the SMS, SI, and Asset Store
databases to reflect the new asset distribution.
The VOD delivery subsystem uses an SSL connection to copy the block, index, and metadata
files from the Staging folder in the VOD backend to the VOD Server in the branch.
Decrypting DRM Keys
The VOD deployment process also includes decrypting the DRM keys for each RTP stream.
To decrypt the DRM keys:
1) The VOD delivery subsystem reads the branch certificates from the certificate store.
The branch certificate is installed during IPTV Edition installation.
2) The VOD delivery subsystem sends the branch public key from the branch to the
VOD acquisition subsystem over the SSL channel.
3) The VOD acquisition subsystem verifies that the branch’s public key is valid.
4) The VOD acquisition subsystem reads the key file for each RTP stream.
5) The VOD acquisition subsystem decrypts the encrypted keys for the requested asset
using the VOD acquisition subsystem’s private key and re-encrypts it with the branch
public key.
6) The VOD acquisition subsystem returns the encrypted keys to the branch.
7) When the branch receives the encrypted keys, it decrypts them (using the branch
private key) and stores them for use by client devices.
8) When a client device establishes a VOD session, the VOD delivery subsystem
encrypts the content keys with the client A/V session key and delivers the encrypted
keys to the client. Clients also receive keys to VOD assets for which they have rights
at boot time.
For information about the DRM encryption process, see VOD Acquisition Subsystem (p.
053).
During the VOD asset deployment process, the asset metadata is stored in the Asset Store (p.
070) database and rights data is stored in the subscriber management subsystem (p. 086)
(SMS) by the VOD Asset Management tool.
VOD Session Management and Load Balancing
Each VOD server in the cluster reports its status to the VOD Controller on a regular basis (the
default is every 10 seconds). This status includes the current bandwidth used on the VOD
Server egress interfaces (or interface, if NIC teaming is in use) along with which assets the
VOD Server has available. This information is stored by the VOD Controller in the branch
database, which is then replicated out to the service group databases.
When the client wants to access an asset, it contacts the VOD Map Server for a URL. The
VOD Map Server determines the first and second least-loaded VOD Server interfaces from
which the asset can be served and returns those to the client. The client then uses those URLs
to play the asset. If the first URL fails, the client will try the second one.
Retry
The Media Store virtual directory delivers VOD assets to IPTV Edition clients. Media Store
virtual directories are deployed on Internet Information Services (IIS) servers. IIS servers
handle packet loss and retry by using TCP for the stream transport. TCP delivers packets
error-free and in order.
Service Failover
When a server goes down, the VOD Controller recognizes this when the server stops
reporting its status. This happens within two intervals of the status message (by default, each
interval is 20 seconds). The VOD Controller then updates the database status with this
information so that the URL to that server is no longer returned to clients.
Clients that are currently using that failed server for playback will notice the server going
down within a few seconds, and will then failover to the second URL that was originally sent
to them. If that secondary URL also fails, the client will return to the VOD Map Server to
request another set of URLs to try.
Large Asset Playback
The maximum size of a single file server by IIS is 2 GB. If a VOD main stream is larger than
2 GB due to the length of the feature, it is broken into multiple files. The client opens an
HTTP/TCP session for each file that is required (main streams, trick-play files) and continues
to pull down that file until the client either runs to the end of the file or switches mode (trick-
stream play or back to main stream). At that point, a new HTTP/TCP session is initiated. This
process is transparent to the subscriber.
See Also
VOD Asset Security
The IPTV Edition system ensures the security of VOD assets within the system. It employs
multiple security measures to ensure that only those subscribers who have access rights to a
VOD asset can actually access the VOD asset.
The following outlines the mechanisms the IPTV Edition system uses to secure VOD assets:
•
DRM protection. The VOD acquisition subsystem encrypts VOD assets during
import with strong encryption (AES). VOD assets remain encrypted all the way
through the IPTV Edition system after import. IPTV Edition clients decrypt VOD
assets just prior to decoding the content.
The system encrypts main feature and trailer streams using separate keys. Trick and
PIP streams share keys with their respective main stream.
•
Macrovision protection. Macrovision prevents unauthorized copying of VOD assets
to DVD recorders and VCRs. Content protection is transparent when subscribers
view the VOD asset, but prevents or substantially degrades copies made on analog
recording devices by distorting the VOD assets over the analog interface. During
VOD asset import, DRM tags each frame of the RTP stream with the appropriate
Macrovision analog content protection control bits. The control bits instruct the IPTV
Edition client to add analog content protection to the outgoing analog video.
The Macrovision state for VOD assets is always set to both attack color signaling and
composite output resynchronization.
•
Client authentication. VOD asset requests follow the same client authentication
process as live TV content (as do all requests for client access to the IPTV Edition
system). The system authenticates all client requests made to the VOD subsystem.
•
Secure connection between VOD backend and branch. The system can be
configured to use SSL when copying VOD assets between the VOD backend and a
branch.
•
Subscriber access rights. The VOD subsystem provides the same subscriber access
rights capabilities as live TV.
Integrating a Branch with an EQoS Interface
The branch can optionally be integrated with an external quality of service (EQoS) interface
to oversee the quality of service during a subscriber's VOD purchase experience, as well as
interaction with the asset itself (for example, playing or using trick speeds). For more
information about integrating the branch with an EQoS interface, see “External Quality of
Service Web Service” in Integration Reference.
Integrating a Branch with an EPOC System
The external purchase offer cycle (EPOC) Web service is a Web service that service
providers can optionally implement and deploy to define the business logic for VOD
purchases. IPTV Edition does not provide a sample implementation of the EPOC Web
service. For details on the API that this Web service must implement to support EPOC, see
External Purchase Offer Cycle Web Service (p. 023) in Integration Reference.
RDP Application Subsystem
The RDP application subsystem lets IPTV Edition clients display applications that run on
remote application servers. It uses the Windows® Remote Desktop Protocol (RDP), the same
protocol that is used by Windows Server 2003 Terminal Services. The IPTV Edition client
initiates, maintains, and terminates RDP connections to each application.
Subscribers can launch RDP applications from menus and the program guide. The Terminal
Server sends application graphics to the client, which then renders the application UI. When
the subscriber presses remote control keys, the client sends events to the Terminal Server.
IPTV Edition enables rapid development and deployment of RDP applications. This
development environment makes it easier to develop and deploy customized behaviors that
suit your set-top box requirements. Customer service and self-provisioning applications are
good candidates for implementation as RDP applications.
RDP Application Subsystem Software Components
The following diagram shows the functional software components of the RDP application
subsystem.
The following sections describe the RDP application subsystem software components:
•
Windows Server Terminal Services (p. 060)
•
TServer Windows Service (p. 060)
•
Terminal Server Session Starter (p. 061)
•
RDP Application Launcher (p. 061)
•
TServerProxy COM+ Service (p. 063)
•
Terminal Server Controller Private Web Service (p. 063)
•
Terminal Server Controller Public Web Service (p. 063)
•
Terminal Server Controller Database (p. 063)
•
Windows Applications (p. 063)
Windows Server Terminal Services
Windows Server Terminal Services reside at the service provider site and serve requests for
RDP sessions from IPTV Edition clients. At startup, the Terminal Server machine sets up a
pool of RDP sessions that are left in a disconnected state until clients connect to them.
The IPTV Edition client contains an RDP client that connects to existing RDP sessions on a
Terminal Server.
The IPTV Edition client logs in to the existing RDP session by specifying the machine
connection string, user name, password, domain, port number, and session ID.
TServer Windows Service
The TServer Windows service provides status updates to the Terminal Server controller
private Web service, which then stores the new status in the Terminal Server controller
database. The Terminal Server controller private Web service returns a list of actions to the
TServer Windows service that it then carries out. This includes creating users, changing
passwords, starting new RDP sessions, and shutting down existing RDP sessions. The
TServer Windows service repeats this cycle of sending status updates and carrying out the list
of actions in the response on a regular interval.
This Windows service runs on each Terminal Server machine hosting Windows Server
Terminal Services. If it fails to provide service within a specified timeout period, the
Terminal Server controller public Web service ceases to assign new RDP sessions to the
corresponding Terminal Server.
The TServer Windows service obtains configuration parameters from an XML configuration
file (TServer.xml) that it reads when it starts. If you modify TServer.xml, the changes take
effect after you stop and restart TServerService.exe. The control panel for this Windows
service is called IPTV Edition TServer.
Calls from the TServer Windows service to the Terminal Server controller private Web
service are routed through the TServerProxy COM+ service.
Terminal Server Session Starter
The Terminal Server session starter is a stand-alone application
(TerminalServerSessionStarter.exe) that starts a Terminal Server session and then exits. The
session starter is launched by the TServer Windows service when it needs to start a new
session.
RDP Application Launcher
The RDP application launcher (launcher) runs on a Terminal Server and launches and
manages the lifetime of RDP applications. The IPTV Edition client launches the RDP
application launcher through its RDP session with Windows Server Terminal Services.
Windows Server Terminal Services launch an instance of the RDP application launcher for
each RDP session.
During deployment, the RDP application subsystem’s access control lists (ACLs) are set up
so that the Terminal Server can launch only the launcher. The launcher determines which
application to run from a virtual channel message that the IPTV Edition client sends. The
IPTV Edition client then renders the application’s UI.
For Web-based applications, the launcher hosts an Internet Explorer 6.0 browser control and
customizes the browser behavior for the IPTV Edition environment. For example, it blocks
dialog boxes. Web applications can be hosted on the same server, on a separate IPTV Edition
server, or on an external server. The control simulates the Windows XP Media Center eHome
shell to support Media Center applications.
By supporting a subset of the Media Center object model, the launcher supports RDP
applications that incorporate video content. Instead of integrating video content on the server
side and delivering the entire UI over RDP, the RDP application subsystem delivers all non-
video content over RDP and relies on IPTV Edition clients to integrate live video or VOD
content that it receives over the corresponding transports.
Note IPTV Edition does not support the Media Center object model for Windows
applications.
The Internet Explorer 6.0 control intercepts playback control API calls so that live TV is not
delivered over RDP. Instead, the playback controls are delivered as client messages over RDP
virtual channels. The IPTV Edition client uses these messages to acquire the appropriate
media streams and integrates those streams with the UI content delivered over RDP. The
launcher also stores cookies for each user in the user store subsystem.
Note Because subscribers can choose language preferences, Web applications can be
implemented to support multiple languages as well. The application retrieves the user’s
language setting from the UserLanguages list in the HTTP request header
(HttpContext.Current.Request.UserLanguages[0] in ASP.NET). The language names follow
the RFC 1766 standard in the format languagecode2-country/regioncode2 (for example, enUS). Similarly, applications can be implemented to support multiple display resolutions.
For Windows applications, which run on the Terminal Server, the launcher launches the
application maximized (with window frame and menus removed). The launcher stops the
application when the application session is done. The service provider must install the
Windows applications on the Terminal Server.
The RDP application launcher sends a notification over RDP virtual channels to let the IPTV
Edition client know that the application finished loading. It also sends notifications for
various error conditions.
The RDP application launcher communicates with the Terminal Server controller private
Web service when clients connect and disconnect to authenticate clients and to manage the
number of the sessions in the session pool. Calls from the RDP application launcher to the
Terminal Server controller private Web service are routed through the TServerProxy COM+
service. All other calls from the RDP application launcher to internal Web services are also
routed through the TServerProxy COM+ service and Terminal Server controller private Web
service.
For details on developing RDP applications for IPTV Edition, see Application Developer’s
Guide.
TServerProxy COM+ Service
The TServerProxy COM+ service enables the TServer Windows service and the RDP
application launcher to communicate with internal Web services. All calls from the TServer
Windows service and the RDP application launcher to internal Web services are routed
through the TServerProxy COM+ service and Terminal Server controller private Web
service. To make the system more secure, the TServerProxy COM+ service only exposes
access to the necessary internal Web services. The TServer Windows service and the RDP
application launcher do not have the credentials to call the internal Web services directly.
Terminal Server Controller Private Web Service
The Terminal Server controller private Web service receives session state information from
the TServer Windows service on each Terminal Server and stores it in the Terminal Server
controller database.
Terminal Server Controller Public Web Service
The Terminal Server controller public Web service runs on a client-facing machine and
performs client authentication on all requests. It accesses the Terminal Server controller
database to acquire RDP session information for IPTV Edition clients so they know which
Terminal Server to contact and to which session to connect. For details on how clients acquire
RDP sessions, see Connecting to RDP Sessions (p. 064).
Terminal Server Controller Database
The Terminal Server controller database stores the status of available RDP sessions on
Terminal Servers. The Terminal Server controller public Web service accesses this database
to provide RDP session details to IPTV Edition clients that need to run RDP applications. The
contents of this database are managed by the Terminal Server controller private Web service.
Windows Applications
The RDP application launcher can run Windows applications installed on the Terminal
Server. Each Windows application runs in a separate process, but in the same RDP session as
the RDP application launcher that started it.
For the best user experience, Windows applications should be designed for display on TV
screens and for operation within the constraints of IPTV Edition set-top boxes. For details on
design and implementation guidelines, see Application Developer’s Guide.
Connecting to RDP Sessions
When a subscriber chooses an RDP application from the program guide or the main menu, the
client contacts the client-facing Terminal Server controller public Web service to request an
RDP session.
The client ID is included in the client’s request for an RDP session as part of the client
authentication ticket.
The Terminal Server controller public Web service queries the Terminal Server controller
database to see if any sessions are available. If a session is available, it sends the TServer
Windows service the:
•
Terminal Server connection string (machine name or public IP address if specified).
•
Port number.
•
User name.
•
Password.
•
Domain.
•
Session ID of the session to use.
•
Security token used to authenticate the client.
If there are no available sessions, it returns an error and the client repeats its session request
until a timeout limit is reached.
If the client reaches its timeout limit and the Terminal Server controller public Web service
doesn’t return a session, the client presents an “Application not available” error message to
the subscriber.
If the Terminal Server controller public Web service returns a session, the IPTV Edition
client then connects to the given Terminal Server session.
The RDP application subsystem only creates one RDP session for each subscriber.
Subscribers can launch multiple applications one at a time, but each is delivered over the
same RDP session.
If IPTV Edition is unable to connect to the Terminal Server session, or does not get
confirmation from the Terminal Server that the application launched successfully within a
timeout limit, the IPTV Edition client presents the “Application not available” error message.
System operators can manage RDP application items in the IPTV Edition client menu with
the UserStoreDo command. For details on customizing the client menu, see User Interface
Customization Guide.
Note IPTV Edition clients present available RDP applications to subscribers if they receive
RDP application service information from the media discovery subsystem. IPTV Edition
operators create media descriptions for the media discovery subsystem with the TV Services
Management tool.
Tracking Terminal Server Sessions
The TServer Windows service that runs on each Terminal Server periodically calls the
Terminal Server controller private Web service to provide updated status of all sessions
running on that machine. In turn, the Terminal Server controller private Web service saves
current session state information in the Terminal Server controller database.
Each Terminal Server is placed into service when the Terminal Server controller private Web
service receives a first status update (initialization message) from it. If the Terminal Server
controller private Web service doesn’t receive a status update from a Terminal Server within
a timeout limit, it assumes that the Terminal Server is out of service and no longer gives out
sessions for that Terminal Server. If that Terminal Server resumes sending status updates, it is
placed back into service.
Securing RDP Sessions
Calls to the client-facing Terminal Server controller public Web service go through the Web
service router (WSR) Web service, which authenticates all clients. As a result, only valid
IPTV Edition clients can successfully request RDP sessions from the Terminal Server
controller public Web service. On a successful call, the client device ID is stored in the
Terminal Server controller database and associated with the appropriate RDP session.
The Terminal Server must be configured to run only the RDP application launcher. This
precaution prevents clients from running unauthorized applications residing on the Terminal
Servers.
When an IPTV Edition client connects to a Terminal Server session, the RDP application
launcher receives the client device ID from the IPTV Edition client. The launcher calls the
Terminal Server controller private Web service to get the client device ID that it stored for the
session to ensure that they match. If the client device ID does not match, the RDP application
launcher immediately disconnects the session to ensure that only authenticated IPTV Edition
clients are able to use the Terminal Server.
The Terminal Server controller private Web service generates new passwords for each user
on each Terminal Server and stores them in the Terminal Server controller database.
Passwords are reset each time that a new user is created or a new session is started. Passwords
are also reset each time a client connects to a session, so that no other clients are able to
connect to the session using the same password.
Each time the TServer Windows service on the Terminal Server sends the Terminal Server
controller private Web service a status update, the Web service returns a list of sessions to
shutdown and a list of user name/password pairs to reset. The TServer Windows service shuts
down the sessions listed and creates the users (if they don’t already exist), changes the
passwords, and starts new RDP sessions (if there isn’t already an RDP session for the user)
for the list of user name/password pairs.
Managing RDP Sessions on Each Terminal Server
The TServer Windows service reads the <Sessions> tag in the TServer.xml configuration file
to obtain start, max, and increment parameters that control the number of sessions used on
each Terminal Server. It then contacts the Terminal Server controller private Web service
with an initialization message that lists all of the current sessions on the Terminal Server.
The Terminal Server controller private Web service returns a list of user name/password pairs
for sessions that should be started to bring the number of sessions up to the start value. The
TServer Windows service then changes the password for each user and starts a session for
that user if there isn’t already one.
When an IPTV Edition client connects to a Terminal Server, new sessions may be started if
necessary. The TServer Windows service ensures that the number of available sessions is
never less than start or the number of sessions in use plus increment, and never more than
the maximum number of sessions (specified by max).
When a client disconnects from a Terminal Server, the session on the Terminal Server is
terminated unless it is still needed. If the number of sessions is more than start and more than
the number of sessions in use plus increment, the session is terminated because there are not
enough sessions available.
To take a Terminal Server out of service (for example, for maintenance), you can stop the
TServer Windows service. Existing sessions in use are not affected, and no more clients are
connected to sessions on that Terminal Server. To minimize disruption of the service, you can
wait for clients to disconnect on their own before doing anything that would terminate the
sessions (such as rebooting the Terminal Server).
Scaling, Load-Balancing, and Failover
Access to multiple Terminal Server machines is load balanced by the client-facing Terminal
Server controller public Web service. It uses session state information from all of the
Terminal Servers to load balance and decide which Terminal Server the requesting client
should use.
When a Terminal Server machine goes down or is taken out of service, the Terminal Server
controller public Web service no longer gives out sessions on that Terminal Server machine,
which causes all subsequent connection requests to fail over to the other Terminal Server
machines.
Because the Terminal Server controller public Web service performs this service, Terminal
Servers should not be load-balanced by other mechanisms, such as the NLB in Windows
Server.
To improve availability of the Terminal Server controller public Web service and Terminal
Server controller private Web service, the machines running them can be load-balanced with
NLB or other mechanisms.
Web Service Router
The Web service router (WSR) brokers all Web service communications (SOAP over HTTP)
between IPTV Edition client devices and client-facing Web services. The WSR proxies Web
service requests from clients to other Web services where the calls are processed. When the
call completes, the WSR returns the result to the client.
The WSR’s sole purpose is to provide a buffer between IPTV Edition clients and the clientfacing Web services. With the WSR in place, HTTP ports need to be open only between the
application zone and the perimeter network, which is also sometimes referred to as the
"demilitarized zone" (DMZ).
The WSR maintains a routing table that keeps track of the server machines running each
IPTV Edition Web service. When an IPTV Edition client tries to contact a Web service, the
WSR looks in its routing table for a server machine that hosts the requested Web service. If
no entry is found, the WSR returns a “404 Not Found” error. If the Web service is found in
the routing table, the WSR passes the request to that Web service.
Note The WSR routing table is loaded one time when the first request arrives. Any changes
to the configuration that affect the routing table require restarting the IIS application pool for
the changes to take effect.
The WSR builds its routing table from the configuration system, which currently obtains the
routing information from the roles.xml file, specifically from the <roleURI> XML element.
The following diagram shows how the WSR fits into a typical deployment.
The WSR provides the following important benefits to securing IPTV Edition deployments:
•
Reduced attack surface. By moving all Web service application logic out of the
Web tier, fewer public interfaces are exposed to IPTV Edition clients.
•
Application code is located in a secure zone. Application servers that access
databases can reside in different zones than client-facing servers. The perimeter
network, which is also sometimes referred to as the "demilitarized zone" (DMZ),
does not require open ports to allow SQL communications.
Asset Store Subsystem
The Asset Store subsystem stores metadata for RDP applications and VOD assets that
subscribers can browse, run, and, if necessary, purchase.
The following diagram shows the Asset Store subsystem software components.
The following table describes the Asset Store subsystem software components.
Component
Description
Asset Store Web service
Lets the VOD, RDP application, and search subsystems retrieve
asset metadata over HTTP.
It also provides a Web service through which the TV Services
Management tool initiates import operations and coordinates
VOD asset deployment.
Asset Store database
Contains RDP application and VOD asset metadata. Maintains
Component
Description
information about deployed VOD assets.
See Also
Video on Demand Subsystem (p. 041)
RDP Application Service Subsystem (p. 059)
Electronic Program Guide Subsystem
The Electronic Program Guide (EPG) subsystem enables operators to manage listings data for
traditional live TV services. The listings data describes services, programs, and schedules for
these programs. It does not contain information specific to any subscriber, device type, or
provisioning rights.
EPG Listing Distribution
Listings data originates from a listings provider, is imported into the IPTV Edition EPG
database, and is then distributed to IPTV Edition clients.
The following diagram illustrates how the IPTV Edition system manages this process end-toend.
1) An EPG listings provider (of the service provider’s choosing) creates a GLFcompliant listings data file.
2) The listings provider copies the listings data file to a secure location to which the
service provider has access.
3) Branch operators define a method for securely copying the listings file. They copy
the listings data file onto the branch server machine that can be accessed by the EPG
database. Each branch must have its own copy of the listings data file.
Each branch can have the same or different listings data files. For example, two
branches might contain an English-based listings data file while another branch has a
French-based listings data file.
4) The EPG subsystem imports the listings data file into the EPG database. Import
performs a complete update of the listings data file; the system does not currently
support partial updates.
There are three ways to import a listings data file:
•
Manual import. Use the OSS EPG Web service to manually import the listings
data file each day. This method is not recommended outside of a lab trial.
•
Scheduled invocation method. Set up a SQL job to import the listings data file
at a specific time. The file is imported at the same time each day regardless of
whether its content changed.
•
Web service invocation method. Develop an external application that uses the
OSS EPG Web service to automatically update the listings data file when the
content changes.
During import, the import process does not disturb the current listings data tables; it
writes all listings information to a secondary set of listings tables. After the import is
complete, the import changes the secondary listings tables to the primary listings
tables. Using this method, clients can still request listings data while an import is in
progress and, if the import should fail, the listings data remains intact. For more
information, see the “Configuring the EPG Listings Import” section in Installation
and Configuration Guide.
5) After the import process is complete, the EPG subsystem updates the import
timestamp in its state table. The EPG data is replicated to each service group in the
branch.
6) The media discovery Web service monitors the state table. When it detects a
timestamp change, it sends an update message to each client over UDP/IP. Clients
store messages in a queue and process them in the order in which they arrive.
7) The client processes the notification and checks to see if it already has the latest
version of the listings data file. If not, the client sends a request for a listings data file
update to the media discovery Web service.
8) The media discovery Web service receives the request, obtains the available service
list from the SI subsystem, and obtains the client’s channel map from the user store
database. The service list contains entries for all of the services that are deployed in
the branch.
If the media discovery Web service is busy and cannot process the client’s request,
the client request times out and the client automatically retries the request.
Subsequent retries are done at a progressively decreasing rate. For example, the first
retry request is 30 seconds after the failure, the second is 1 minute after the second
failure, and so on, each retry request increasing in length (up to a maximum of 1
day).
9) The media discovery Web service queries the read only EPG database for the
updated listings data. The Web service requests listings data only for the services
defined in the client’s channel map.
The read only EPG database passes back the requested listings data.
10) The media discovery Web service delivers the updated listings data to the client
using a compact format also known as a “dense” guide. A dense guide requires a
smaller client memory footprint than traditional guide data formats.
11) The client caches the updated listings data and updates its listings data version value.
Listing File Format
The EPG subsystem uses the Microsoft® Global Listings Format (GLF) data model to
represent the listings data. The source listings data must be formatted in XML GLF listings
representation that uses a specific schema to ensure data integrity. Using XML
representations, the EPG subsystem provides format uniformity, schema-based validation,
and a consistent transformation mechanism.
Listings providers who provide metadata in other formats are required to have the data
converted to GLF (either by the listings provider, the IPTV Edition service operator, or some
other party) before IPTV Edition can import the data.
The listings data file contains the program and scheduling information for a specific time
period, such as the next 14 days of programming. The file should contain information that is
relevant only to that particular period of time and should not contain any scheduling gaps.
Avoid leaving unused data in the file as the memory available on clients for listings data is
limited.
The listings data file is typically updated (imported) once a day. You should avoid frequent
updates (imports) of the listings data because each time the data is updated it must be sent to
each of the clients in the network.
Listings data is used primarily by IPTV Edition clients to:
•
Populate the program guide.
•
Provide program details on the Program Info page, channel panel, and browse panel.
•
Define program categories.
•
Search by program title and roles.
•
Assign ratings to programs.
•
Schedule series recordings.
Channel Maps
Channel maps associate services to virtual television channels. A channel map can contain
any number of virtual channels. Channel maps enable service providers to offer different
channel lineups while using the same set of services. They also enable the creation of test
channel maps when service providers try out new services.
IPTV Edition clients use channel maps to determine which service to display when
subscribers press number buttons or the channel up and down buttons on the remote control.
A subscriber can be associated with only a single channel map.
In a channel map, a virtual channel is associated to a service collection. Service collections
define a group of related services such as:
•
Full-screen (live TV, VOD, and PPV).
•
PIP (live TV, VOD, and PPV).
•
VOD trailers.
•
RDP applications.
•
Slide shows.
Service collections enable operators to define which services to present to subscribers when
they are authorized to view content and when they are not (upsell condition). For example,
when creating a VOD service collection, operators define both a primary and secondary set of
full-screen and PIP services. The primary services are displayed if the subscriber is authorized
to view the VOD asset. They typically contain the feature-length video and PIP. The
secondary services are displayed as an upsell promotion if the subscriber is not authorized to
view the VOD asset. They typically contain the full-screen and PIP trailers.
EPG Subsystem Software Components and Data Flow
The following diagram shows the software components of the EPG subsystem.
The following table describes the software components of the EPG subsystem.
Component
Description
EPG Web
Provides identity management for services and programs. It provides a
service
Web service that enables other IPTV Edition components to receive the
listings data.
EPG
Incorporates new data from the EPG importer without interruption.
database
The EPG relational SQL database cannot reside on the same physical
machine as the EPG Web service.
Note The EPG subsystem does not manage channel maps, rate packages, or any type of
subscriber-specific data preferences.
See Also
DVR Scheduler Subsystem (p. 104)
Media Discovery Subsystem
The media discovery subsystem provides media descriptions that include content metadata
and service information about how to access the content. It exposes two identical Web
services that support requests from the server-facing tier and the Web tier.
Media descriptions are data sets that describe the metadata for a given piece of content in
sufficient detail to enable IPTV Edition software components to operate on it.
The following diagram shows the types of communication that the media discovery
subsystem performs.
The following table describes the media discovery subsystem software components.
Component
Description
Media
Receives requests for media descriptions from IPTV Edition clients. Each
discovery
request specifies a piece of content by a GUID known as a “media
public Web
descriptor.” The media discovery public Web service contacts the SI
service
subsystem for service information and then gets metadata from the EPG
subsystem. The media discovery public Web service creates a media
description from the returned data and delivers it to the IPTV Edition
client.
Media
Receives requests for media descriptions from the search public Web
Component
Description
discovery
service. The media discovery private Web service then handles the
private Web
requests in the same manner as the media discovery public Web service.
service
Although the media discovery public and private Web services perform the same function,
they serve different clients (IPTV Edition clients and the search public Web service,
respectively), and may reside in different zones for security purposes.
See Also
Electronic Program Guide Subsystem (p. 072)
Search Subsystem (p. 110)
Service Information Subsystem
The service information (SI) subsystem is the central directory for all IPTV Edition services.
The SI subsystem provides IPTV Edition clients with the information needed to acquire video
and data services. Services include live video services, VOD services, and RDP application
services.
IPTV Edition clients communicate with the SI subsystem to:
•
Discover available video and data service collections.
•
Associate various mixed modes (live TV, VOD, RDP application, image) with a
single top-level service collection.
•
Determine which version of a channel to display (for example, full-screen, PIP, or
upsell) depending on context.
The SI subsystem does not maintain or access subscriber, client, or service rights.
IPTV Edition clients receive data maps in XML format that enable them to discover and
access live, VOD, and RDP application services. This information may be attached on a
service-by-service basis or to the subsystem description. If the information is attached to a
subsystem, it applies to all services carried by that subsystem.
The following diagram shows the SI subsystem software components and how they interact
with other IPTV Edition components.
The following table describes the SI subsystem software components.
Component
Description
Service discovery
Provides a set of interfaces that enable other IPTV Edition server
Web service
machines to access details for each service.
Service information
Maintains base service information data in an SQL database. Base
database
service information data includes the:
•
Service map, which contains detailed information about
individual services.
•
Service collection map, which bundles services together to
present a consistent display across various display contexts.
•
Media description map, which associates a media descriptor
(a GUID that identifies a specific media description) with
listings data and a service collection.
At IPTV Edition system start time, the client service information handler connects to a
bootstrap Web service where it acquires the appropriate service information data. It
immediately delivers the configuration data for each subsystem from the data map to the
appropriate subsystem. The subsystems can then begin acquiring any specific data required.
See Also
Video on Demand Subsystem (p. 041)
RDP Application Subsystem (p. 059)
Bootstrap Web Service
The bootstrap Web service is the first Web service that IPTV Edition clients encounter when
they go through the startup sequence. IPTV Edition clients acquire the URL of the bootstrap
Web service by requesting the _bootstrap service record from DNS.
The following diagram shows how the bootstrap Web service interacts with other IPTV
Edition components.
The bootstrap Web service authenticates the IPTV Edition client and logs it on to the IPTV
Edition system. It then contacts the SMS to determine the subscriber’s billing status and
returns a list of URLs for Web services (terminal service monitor, client upgrade, and so on)
from which the IPTV Edition client can acquire configuration data.
Note IPTV Edition clients begin their startup sequence by acquiring IP connectivity through
a supported protocol. Currently, IPTV Edition client software supports only DHCP.
The bootstrap Web service enforces service policies for authenticated clients. For example, it
checks the client for a valid certificate and required minimum software version. If the client
software version is below a minimum number, the bootstrap Web service initiates an upgrade
through the client upgrade Web service.
The IPTV Edition bootstrap Web service can make use of an external login server (ELS) Web
service, if the service provider provides one. The bootstrap Web service calls the ELS Web
service whenever a set-top box is powered on or connected to the network. The ELS Web
service provisions the set-top box if necessary, verifies that the set-top box is entitled to
connect to the service provider, and returns information signaling the result of the
authentication. In addition, if the ELS Web service needs to provision a set-top box, it can
optionally signal that the set-top box should run a “self-provisioning” RDP application; which
(for example) might prompt subscribers to enter credit-card information, choose subscription
packages, and other options.
Discovery Windows Service
The discovery Windows service provides clients with the location of resources that they can
contact during regular start-up or to recover from client software failure, should it occur.
Clients only contact the discovery Windows service if they do not know the location of a sync
Windows service or bootstrap Web service. In situations where a client is recovering from a
failure, the client contacts the discovery Windows service first.
The discovery Windows service implements a simple protocol based on the trivial file
transfer protocol (TFTP) that lets clients specify a GUID so that the discovery Windows
service can determine the most appropriate servers for each client. The discovery Windows
service resides in the perimeter network, for example on the same machine as the Web service
router.
Sync Windows Service
The sync Windows service provides clients with an initial application that they can run at
startup when they are recovering from a failure. This application, known as the disaster
recovery application, helps the client restore configuration information, which it acquires
from the bootstrap Web service, and ultimately to acquire a new copy of the IPTV Edition
client software. IPTV Edition clients do not contact the sync Windows service under normal
startup conditions.
The sync Windows service implements a simple protocol based on the trivial file transfer
protocol (TFTP) that lets clients specify their set-top box model so that the discovery
Windows service can return the appropriate version of the disaster recovery application. The
sync Windows service can reside on any client-facing machine.
Subscriber Management Subsystem
The subscriber management subsystem (SMS) provides access to a repository for information
about IPTV Edition subscriber entitlements within a branch. The SMS stores service offerings
(live TV, VOD, and RDP applications), default entitlements for all branch subscribers, and
subscriber-specific entitlements in the service group database.
It includes:
•
A Microsoft® Windows service that polls for new keys for live TV services.
•
Web services through which other IPTV Edition components can access the service
group database.
Service Offerings
The SMS uses media descriptors to identify all services, whether they provide a live TV,
VOD, or an RDP application service. Media descriptors enable service providers to define
services, service collections, and service packages.
Default Entitlements
IPTV Edition service providers can grant default entitlements for individual services (for
example, access rights to view a premium channel) or for packages of services (for example,
access rights to a collection of premium channels).
If the SMS receives changes to subscriber rights, it may proactively notify the affected
devices.
Subscriber Management
The SMS maintains information about each subscriber that includes the:
•
IPTV Edition devices that are installed at the subscriber’s residence.
•
Services and service packages that each account or device is entitled to consume.
•
External billing system ID and credit limit.
Service providers extend a certain amount of credit for the purchase of billable services to
subscribers. The SMS tracks and manages this limit. If a subscriber exceeds the credit limit,
rights to any purchasable service are denied until the limit is reset. Microsoft TV provides
applications that enable the service provider or the subscriber to reset the credit limit within
limits imposed by the service provider’s business rules.
The SMS does not collect or hold a subscriber’s billing information, such as a credit card
number or payment information, but it does track the subscriber credit limit.
Service provider personnel add the subscriber into the service provider’s business system,
which then communicates the information to the SMS through the OSS and BSS Web
services. The SMS maintains information about the subscriber and the associated devices,
with billing information related to each device.
Billing Events
The SMS keeps track of billable IPTV Edition transactions for each subscriber and device,
including VOD purchases, Pay Per View (PPV) purchases, and subscriptions to services and
channels. When subscribers purchase services, the SMS creates the billing events and stores
them in the service group database. The billing events can then be accessed through BSS Web
services.
SMS Architecture
The following diagram shows how the SMS software components interact with other IPTV
Edition subsystems.
The following table describes the SMS software components.
Component
Description
Billing Web service
Lets business support systems (BSS) access subscriber
billing events in the service group database.
Component
Description
Client rights Web service
Manages IPTV Edition client requests for service access
rights and keys. Checks the service group database and
returns valid content protection keys to the client if service
access rights are granted by default or if the subscriber
purchased the service.
Key management Web
Lets the live TV acquisition and VOD acquisition
service
subsystems update keys in the subscriber database.
Principal management Web
Lets business support systems (BSS) manage principals
service
(users, devices) in the service group database. BSS systems
access this Web service through the BSS principal
management Web service, which is a proxy that exposes the
same API.
Purchase Web service
Manages purchase requests from IPTV Edition clients.
Resource management Web
Lets BSS systems manage resources (live services, VOD
service
services, and RDP applications) in the service group
database.
Rights management Web
Lets BSS systems manage rights in the service group
service
database.
Business logic resides in the service provider’s operations support systems (OSS) and
business support systems (BSS) rather than in the SMS. For example, IPTV Edition exposes
Web services to store live service package information. Through these Web services, the OSS
and BSS can define multiple service tiers (for example, basic, silver, and gold) that include
different sets of live channels. The SMS, however, does not track relationships between these
tiers. For example, the SMS does not indicate if the basic tier is a subset of the silver or gold
tiers.
IPTV Edition provides a set of Web services (billing record management, grant management,
offer management, package management, and principal management), through which BSS
systems monitor and manage SMS data.
For details on the BSS Web service APIs, see BSS Web Service Reference.
Service Group Subsystem
A service group is a pool of servers that IPTV Edition dedicates to a group of subscribers.
Service groups let operators:
•
Scale up IPTV Edition systems to accommodate new subscribers.
•
Prevent service interruptions while performing system upgrades and other regular
system maintenance.
Scalability and Load Balancing
IPTV Edition allows operators to add more subscribers by simply expanding their server
capacity at their data centers. At the same time, IPTV Edition service groups let operators
move subscribers among different server pools for load balancing, or to partition their service
groups based on any criteria, such as geographic proximity.
Service groups do not add significant complexity to IPTV Edition management and the
expansion of service groups does not increase maintenance tasks beyond the regular planned
maintenance that the additional servers require.
IPTV Edition Software Upgrades
Service groups support an upgrade methodology that maximizes service “uptime” and
business continuity. To maintain service uptime while performing system upgrades, IPTV
Edition requires minimal spare hardware system resources. For example, operators can use
one service group as a standby group to be shared by all the active service groups.
IPTV Edition provides upgrade paths that can be accomplished by carrying out the data
migration with fine granularity. To minimize the impact of data migration on subscriber
experience, IPTV Edition provides a robust database migration tool. For details on database
migration, see Installation and Configuration Guide.
Service Group Subsystem Software Components
The following diagram shows the software components that comprise the service group
subsystem.
The service group subsystem supports the service group concept with a database for
information about accounts and devices-assigned to that service group. It also provides a data
access layer through which server-facing Web services in the service group can access the
service group database and a Web service that allows BSS Web services to access the
database.
Each service group is self-contained in terms of handling client requests, presenting offers,
and enabling purchasing and billing. The service group database includes read-only copies of
services, resources, packages, and group offer data, all of which are replicated from the
branch database.
When multiple service groups are deployed, all servers in each service group operate
completely independently of servers in the other service groups. Since there is no contention
among service groups, operators can scale out the IPTV Edition system with service groups
by adding new subscribers to a service group and also by adding more service groups as
needed, without running into scalability problems. It can be planned ahead for operator to
deploy in a way that all the user accounts are load-balanced evenly among service groups for
scalability and best performance.
Unless operators specify a service group when adding devices and accounts, IPTV Edition
adds the new principals to a default service group. Operators specify the default service group
through the TV Services Management Too, or they can use custom applications that manage
service group defaults and data through the OSS Web services. While the branch management
Web service enables OSS systems to set the default service group, all subscriber details are
under managed through the BSS Web services.
See Also
Service Group Database
All subscriber group and service group metadata, as well as service and asset store metadata
are stored in the branch database. However, individual subscriber data is consolidated and
stored in the service group database, which also incorporates subscriber group metadata and
non-subscriber metadata, which are replicated from the branch database to enhance
scalability, and for read-only access. Since the service groups are independent of each other,
operators can continue to add more subscribers by adding new service groups, to scale out the
overall capacity of their IPTV system.
Some databases are maintained at the service groups. Others are replicas of databases
managed at the branch. The branch management subsystem uses SQL replication to ensure
that account information is kept current in the appropriate service groups.
The service group database includes tables for the following subsystems:
•
Asset Store (replica)
•
DVR
•
Notification
•
sessionKeyAuthority (replica)
•
SI (replica)
•
Live Config and Cluster Assignment (replica)
•
SMS: devices and accounts
•
SMS: group & key (replica)
•
User Store: individual device values
•
User Store: global device values (replica)
Web Services in Service Groups
The service group data access layer is a Windows library that allows server components to
access the service group database. It is intended primarily to provide database access from
Web services in the service group.
The following server-facing Web services are deployed in each service group:
•
dvrRemote
•
dvrScheduleUpdateService
•
mdWSPrivate
•
notificationController
•
sessionKeyAuthorityWS
•
servicegroupSMSWS
•
SGepgWS
•
SGPrivateSessionKeyAuthorityWS
•
SGTraceLog
•
subscriberActivityLogDataWS
•
TServerController
•
vodCatalogPrivateWS
•
vodSGBranchWS
The following client-facing Web services are deployed in each service group:
•
bootstrap
•
clientEdgeMapWS
•
clientLoggerWS
•
dvrV2WS
•
mdws
•
notificationWS
•
SearchWS
•
smsPublic
•
tsMonitorPublic
•
Upgrade
•
userstorePublicWS
•
vodCatalogWS
•
vodMapServerWS
Service Group SMS Management Web Service
The service group SMS management Web service lets BSS Web services, which are deployed
centrally at the branch, to access the service group database. When BSS Web services need to
access information about a specific account, they contact the branch management subsystem
to find out the service group to which the account is assigned. The BSS Web services can
then determine the endpoint URL of the appropriate service group SMS management Web
service, and access the service group database.
Branch Management Subsystem
The branch management subsystem provides a central database for subscriber information
and a Web service through which it defines the assignment of accounts to the appropriate
service groups. While data that is unique to each service group is stored in the corresponding
service group database, account data stored centrally in the branch management database, and
then replicated in the appropriate service group database. Instead of relying on Web service
communication, however, IPTV Edition performs database replication through SQL stored
procedures.
The branch management database is managed by the following IPTV Edition server
components:
•
The TV services management tool (SMT) lets operators define new service groups in
a branch, and manage existing service groups.
•
The branch management Web service lets OSS applications retrieve and update
service group definitions created by the SMT.
•
The BSS Web services let BSS applications manage accounts, billing records, grants,
offers, and purchases, the details of which are stored in the branch amangement
database and replicated as required in the appropriate service group databases.
•
The service group-facing Web service lets server componenets in each service group
retrieve information from the branch management database. For example, the
bootstrap Web service accesses the branch management database when a client in the
same service group starts. For details on the client bootstrap process, see Bootstrap
and Redirection (p. 096).
See Also
Bootstrap and Redirection
When bootstrapping: to determine the subscriber’s status. When SMS indicates the device
does not exist in the current service group, the bootstrap consults with the branch to decide
whether the account is in another service group.
If the account is in the same service group, the bootstrap server goes through the external
login system to register the account. If the account is in another service group, the branch
returns HTTP status code 301 with the fully-qualified domain name of the load balancer for
the Web service routers of the appropriate service group. The client then bootstraps again
with the correct service group.
Databases in the Branch
The branch database includes tables for the following:
•
Asset store
•
Branch management
•
Live config state
•
Notification (stored procedure)
•
sessionKeyAuthority
•
SI
•
SMS (subscription group and key)
•
User store: (global device values)
•
VOD
Web Services in the Branch
The following server-facing Web services are deployed in the branch:
•
BranchMgmtWS
•
clientEventLogDataWS
•
dserverController
•
epgWS
•
LiveBackendUpdate
•
sessionKeyAuthority_KeyGenerator
•
•
serverEventLogDataWS
•
vodBranchWS
•
vodControllerWS
Notification Subsystem
The notification subsystem provides a general-purpose mechanism for delivering messages to
IPTV Edition clients. Messages are typically delivered:
•
To inform clients that system information (such as EPG listings) has changed and
can be downloaded from IPTV Edition subsystems.
•
To inform clients of state changes, such as entitlement changes.
•
For delivering short messages that appear on subscribers’ screens.
•
To tell a client to upload diagnostic information to the logging subsystem.
Each message can be scheduled for delivery at a specific time.
The notification subsystem delivers the messages over UDP/IP to clients, which then put the
messages in a queue and process them in the order in which they arrive.
The notification subsystem exposes a Web service through which IPTV Edition subsystems
can post messages for delivery. IPTV Edition provides two Web services (UI notification
Web service and diagnostics notification Web service) through which operations support
systems (OSS) can post notification messages (packaged as XML data) for clients.
The following diagram shows how the notification subsystem interacts with other IPTV
Edition subsystems.
The following table describes the notification subsystem software components.
Component
Description
Notification
Delivers messages to IPTV Edition clients over UDP/IP. It also
delivery Windows
retrieves messages for delivery and attaches corresponding client
service
information (client ticket, and IP and NAT addresses and ports)
from the service group database, which it accesses through the
notification controller Web service.
Depending on how the notification subsystem is configured during
installation, messages are either delivered on a unicast or multicast
address. Multicast notifications (when enabled) are only used for
system messages, like EPG and service information changes. Clientspecific, subscriber-specific, or group–specific messages, like
channel map changes, are always sent by unicast. In general, using
multicast addresses provides better performance.
The notification delivery Windows service also maintains regular
communications with clients over a UDP “heartbeat” protocol. This
enables the service to handle client status changes and keep NAT
ports open if the client resides behind a residential gateway. The
notification delivery Windows service stores the client status
changes in the service group database.
The notification delivery Windows service runs on the same host
(the Client Gateway machine) as the Web service router.
Clients receive the addresses of two hosts running the notification
delivery Windows service from the client notification Web service.
Clients can maintain communications with up to two notification
delivery Windows services.
Notification
Server-facing Web service. Enables IPTV Edition subsystems to
controller Web
query the service group database, set up messages to deliver to IPTV
service
Edition clients, or cancel pending messages.
Client notification
Provides clients with addresses of machines running the notification
Web service
delivery Windows service. Uses a random algorithm for selecting
two notification delivery Windows services for any given IPTV
Edition client that logs on to the system.
Clients get the addresses of machines running the client notification
Web service from the bootstrap Web service.
Note Because client state is maintained in a database, the client-facing services can scale to
match the number of clients. Any client can communicate with any notification delivery
Windows service or with any client notification Web service.
The IPTV Edition client is equipped with message handlers for a set of messages that IPTV
Edition services may generate. IPTV Edition clients support several types of messages,
including:
•
Rights change messages, which ensure that the client has the appropriate access
rights for services to which it is entitled.
•
Service information change messages, which ensure that the client has current media
descriptions. These messages originate in the EPG and SI subsystems and are
typically sent as multicast notifications at repeat intervals.
•
Text messages, which the client presents to television viewers through a simple UI.
These messages can be generated by custom applications that interface with the UI
notification Web service.
•
Diagnostics request messages, which cause the client to upload diagnostic
information.
If the client has handlers for a message it receives, it processes the message. New or existing
services can post new types of messages to the client, but the client processes only those
messages it is equipped to handle.
Messages can be delivered to individual clients, or they can be broadcast to all clients
simultaneously.
For details on the OSS Web services that provide access to the notification subsystem, see UI
Notification Web Service (p. 134) and Diagnostics Notification Web Service (p. 132).
Message Delivery and Heartbeat Protocol
IPTV Edition delivers notifications to clients over UDP/IP, using a unique heartbeat protocol
designed to reduce message delivery latency and to improve NAT gateway traversal.
When the notification subsystem receives a message to deliver from another IPTV Edition
subsystem or from a custom application, the message details are stored in the service group
database. The notification delivery Windows service polls the notification controller Web
service for message delivery jobs and buffers the jobs until it reaches its maximum capacity
of 4000 messages. It then sends messages to clients from the buffer. It requests more jobs if
the number of messages in the buffer reaches a lower threshold of 1000.
The notification delivery Windows service sends the message to the appropriate clients. After
receiving messages, clients respond over UDP/IP to acknowledge and identify the message
received.
To ensure that clients handle only authentic messages, communication between clients and
servers is encrypted. When sending a message, the client or server includes a time stamp on
the message itself. This time stamp is signed by the sender to guarantee authenticity. When
the message is received, the recipient compares the difference between the transmission and
reception time stamps with the Maximum Delivery Threshold Time parameter.
Multicast messages (for example, system messages) are not encrypted but they are signed so
their origin in the IPTV Edition system can be verified. Although these messages cannot be
impersonated or modified, they could be intercepted and read, so they include no personally
identifiable or secret information.
IPTV Edition clients maintain periodic communication with the notification subsystem to
keep NAT firewall ports open. They also indicate if they can still communicate over UDP/IP
by describing their current operational state (for example, power-on, stand-by, or
unavailable).
Under normal conditions, clients send the notification delivery Windows service ping
messages every 30 seconds (not a configurable interval). If IPTV Edition is configured with
two machines running the notification delivery Windows service, the clients send pings every
15 seconds to alternating machines, so that each machine receives a ping every 30 seconds.
Clients use the pings to track the availability of the notification delivery Windows service. If
a client fails to get an acknowledgment from a machine within eight message-ping intervals,
the client considers the notification delivery Windows service dead and contacts the client
notification Web service to get the address of another notification delivery Windows service
to contact.
If a client is removed from the service group database (which is extremely unlikely due to the
pinging), it receives a “nack” from the notification delivery Windows service. If this happens,
or if the client’s list of services is empty, the client contacts the client notification Web
service to start from the beginning.
The notification delivery Windows service listens on UDP port 0xabba (43962). If a client
resides behind a NAT residential gateway, it transmits messages over a dynamically received
port. The client includes its NAT IP address and UDP port when it sends heartbeat UDP
packets. The notification delivery Windows service stores this information in the service
group database through the notification controller Web service.
The following diagram illustrates how notification subsystem components interact when
clients communicate over UDP/IP.
The UDP/IP-based heartbeat protocol supports messages containing no more than 1000 bytes.
The notification delivery Windows service encrypts messages with the corresponding client’s
certificate, which it obtains from the bootstrap Web service. If the message itself is less than
1000 bytes, the ping message includes the encrypted message.
Startup Sequence
On startup, clients contact the client notification Web service to register with the notification
subsystem and get a list of hosts running the notification delivery Windows service. The list
of notification delivery Windows service machines identifies one host as primary and another
as secondary. The designation of “primary” and “secondary” is for notation only; there is no
functional difference between the hosts.
After receiving the host list, the client sets up the multicast receive socket if multicast is
enabled. It then initiates the UDP/IP heartbeat protocol. Initially, the client uses a 5-second
ping interval to establish communications with the notification delivery Windows service
hosts. After receiving acknowledgment messages, the client switches to a 30-second interval.
The following diagram illustrates the communications that occur within the notification
subsystem when a client powers up.
DVR Scheduler Subsystem
The DVR scheduler subsystem schedules and manages digital video recordings for all IPTV
Edition clients. This subsystem can manage two types of recording schedules:
•
One-time recording. A recording that is scheduled to happen one time only. For
example, recording a specific movie at a specific time.
•
Recurring recording. A recording that is scheduled to happen multiple times. For
example, recording the next six episodes of a specific program, or recording a
program every Tuesday.
When subscribers create or modify a recording schedule, the IPTV Edition client sends the
recording information to the DVR scheduler subsystem. The DVR scheduler subsystem
checks for any conflicts with other recording schedule requests for the client. If no conflicts
are found, the DVR scheduler subsystem stores the schedule in the DVR database. If the
DVR schedule updater Windows service detects a recording conflict, the conflicting schedule
information is sent back to the IPTV Edition client, which then prompts the subscriber to
resolve the conflict.
The DVR scheduler subsystem also provides a Remote Recording Web service, which can be
used to schedule recordings remotely. For example, a service provider might write a Web
page that enables subscribers to log in remotely and schedule programs to record. The Web
page would communicate with the DVR scheduler subsystem's Web service, which would
arrange for the appropriate set-top box to make the recording.
Each client maintains its own schedule of programs to record, and starts and stops recordings
based on that schedule. Clients periodically communicate with the DVR scheduler subsystem
to verify that their schedules are up-to-date. The DVR scheduler subsystem can also notify a
client that it needs to refresh its schedule (for example, when a recording is scheduled
remotely through the Web service).
The client stores recorded programs in 64 MB file “chunks.” A single recording consists of
multiple chunks. The client also creates an index file for each recorded program to facilitate
trick modes and program positioning. Metadata that is related to the program is also stored on
the hard disk drive.
Note Recording schedules are tied to services, not channel numbers. If a channel map is
reconfigured or if a subscriber reorders the program guide, a scheduled recording still records
the correct program. For example, a recording that is targeted at a program on the ESPN
service still correctly records an ESPN program even after a channel number change.
DVR Scheduling in a Multiple Set-Top Box Environment
If a home has several set-top boxes, the home will be allocated a certain number of data
"streams." This determines the number of live broadcasts or PPV offerings that the household
can watch or record simultaneously. (Set-top boxes that are tuned to recorded shows or VOD
offerings do not use up streams.)
If a household has n streams, it can record n shows at once. When a subscriber tries to
schedule a show, the DVR scheduler determines whether the household has a stream available
at that time. If all of the household's streams are already going to be used for recordings, the
DVR scheduler subsystem provides full information about the conflicts to the set-top box.
The client then prompts the subscriber to resolve the conflict by either cancelling one of the
already-scheduled recordings or aborting the attempt to schedule a new recording.
For more information, see Multiple Client Households (p. 150).
DVR Scheduler Subsystem Software Components and Data Flow
The following diagram shows how the DVR scheduler subsystem interacts with other IPTV
Edition software components.
In a multiple set-top box household, each STB communicates with the DVR scheduler
independently, and the scheduler makes sure that the STB with a hard disk drive receives all
scheduling requests. For more information about multiple set-top box households, see
Multiple Client Households (p. 150).
User Store Subsystem
The user store subsystem enables IPTV Edition components to save and retrieve persistent
information as name/value pairs.
The information types that IPTV Edition clients store in the user store subsystem include:
•
Last channel tuned.
•
Last VOD purchase.
•
Last VOD tuned.
•
Parental control PIN and block level.
•
Subscriber channel map.
The following are examples of system-wide client configuration data stored in the user store
subsystem:
•
Notification polling interval.
•
Number of guide days to load.
•
Subscriber UI menus.
•
VOD-only client setting that determines whether the UI enables or disables live TV
and DVR pages.
The user store subsystem can also be used for maintaining shared state info between IPTV
Edition clients and servers.
User Store Subsystem Software Components and Data Flow
The following diagram shows the software components of the user store subsystem and how
they interact with other IPTV Edition components. For simplicity, the diagram does not show
secondary components that do not directly relate to the user store subsystem.
The following table describes the user store subsystem software components.
Component
Description
User store public
Web service interface through which client applications can set or
Web service
get name/value pairs. The IPTV Edition client accesses this Web
(userstorePublicWS)
service to save state information. The user store public Web
service ensures that only the client application that saves data can
retrieve it.
User store private
Web service interface through which server-facing custom
Web service
applications can set or get name/value pairs.
(userstoreServerWS)
See Also
Session Key Authority Subsystem
The session key authority subsystem generates, signs, and disseminates symmetric server
session keys keys to IPTV Edition components. The following illustration shows the structure
of the session key authority subsystem.
The session key authority subsystem includes the following components:
•
The key generator Windows service that periodically generates symmetric server
session keys for the various queues defined in the session key authority database.
•
The session key authority database that contains tables for storing protected
(encrypted and signed) session keys and queue definitions.
•
The session key authority Web service (SessionKeyAuthorityWS) through which
IPTV Edition components get information about available key queues and refresh
keys. All IPTV Edition servers verify the authenticity of the keys that they obtain
from the session key authority Web service before using them.
All session keys are protected with headend certificates using asymmetric cryptography.
Note The session key authority Web service does not have access to the certificates that
protect the keys it retrieves from the session key authority database, so it can run in either an
application or database security tier.
Search Web Service
The search public Web service supports the IPTV Edition client search feature that enables
subscribers to easily locate specific live TV, PPV, and VOD content. It returns sorted sets of
media descriptions when subscribers initiate a search from the IPTV Edition user interface.
Subscribers can find programs to watch by entering the title of the program or the name of a
person, such as an actor or director, using the remote control. Subscribers enter the search
criteria by pressing number keys repeatedly, similar to text entry on a cellular phone.
Subscribers do not have to enter the full title or name. Search uses a “search as you type”
mechanism that displays search results as the subscriber enters search criteria, which provides
quicker response to search queries.
As the subscriber “types,” the search feature displays a list of currently playing TV programs,
future TV programs, and VOD assets that match the search criteria. Subscribers can select the
show they want from the list and then watch it.
The following diagram displays the search subsystem software components.
The following table describes the search public Web service.
Component
Description
search public Web service
Lets IPTV Edition clients obtain media descriptions that
Component
Description
match various criteria for live TV from the media discovery
private Web service.
The search public Web service periodically requests media descriptions from the media
discovery private Web service (in Media Discovery Subsystem (p. 078)), and caches a local
copy of the media description in memory. The process enables the search subsystem to
quickly perform searches and return sorted lists of media descriptions when they are
requested.
Because the search public Web service communicates directly with IPTV Edition clients, it is
typically deployed on a Client Gateway machine.
For more information on using the IPTV Edition client search feature, see Subscriber’s
Guide.
See Also
Logging Subsystem
The logging subsystem manages various occurrences within the IPTV Edition servers and
IPTV Edition clients. These occurrences cause the affected software components to generate
messages and then send the messages to the logging subsystem for processing and storage.
The following occurrences cause this type of action to occur:
•
Diagnostics. A set-top box sends diagnostics information.
•
Subscriber activity events. A subscriber performs an activity on the client that is
being tracked, such as a channel change.
•
System events. An error is detected on an IPTV Edition server or client, such as a
service is down or an event occurs that provides operational historical information.
•
Performance counters. Performance metrics are measured and reported.
•
Audit events. Events are received that track changes made from the Services
Management tool (SMT) or OSS/BSS APIs.
Subscriber Activity Events
Subscriber activity events enable service providers to gain a better understanding of the
services and features that subscribers are using on the IPTV Edition client. Service providers
can use this information to improve customer marketing campaigns, advertising sales, and
relationships with networks.
Activity Log Information Flow
The following figure describes the flow for logging subscriber activity events in the IPTV
Edition system.
1) As subscribers perform prescribed tasks on the client, the client automatically logs an
event containing details about the task in its local activity logging cache.
2) When the client accumulates 500 events, it uploads the content to the logging
framework on the IPTV Edition server.
3) The logging framework stores the subscriber activity events in the subscriber activity
SQL database.
4) Service providers can use the SQL Reporting engine or third-party applications, such
as Crystal Reports, to generate subscriber activity reports.
Subscriber activity event logs are branch-specific. Each branch has its own subscriber activity
event logging database that contains only events from clients serviced by that branch.
Logged Subscriber Activities
IPTV Edition client creates a logging event when the subscriber:
•
Tunes the set-top box to a new channel.
Note The subscriber must remain on the channel for more than 20 seconds (this
value is configurable).
•
Turns the set-top box on or off.
•
Selects an item from any menu.
•
Purchases a VOD asset.
•
Purchases an RDP application.
•
Purchases a PPV event.
•
Launches or closes the browse panel.
•
Launches an RDP application.
•
Disconnects from a launched RDP application.
•
Navigates away from a launched RDP application.
•
Transitions to a new trick state, such as fast-forward, play, or rewind.
•
Runs a client-resident application, such as the menu or the program guide.
After the subscriber activity event log data is uploaded, operators can run reports, analyze the
data, and use the information to help plan and deploy additional services.
For more information on the contents of individual subscriber activity events, see Operations
Guide and Reference.
System Events
All IPTV Edition software components (both client and server) use the logging subsystem to
report system events. System events flag errors, warn of potential problems, or provide
notification of processes that have taken place. Service providers can use system event
information to tune system maintenance and to troubleshoot problems.
System events contain the follow types of information:
•
Event name. Fully qualified class name and class namespace that generated the
event.
•
Event ID. Unique number that identifies the event. Use this information to locate
event cause and corrective actions in Troubleshooting Guide.
•
Event severity.
•
Critical error. A crucial system problem occurred that no longer enables the
IPTV Edition system to function.
•
Error. A significant problem, such as loss of data or loss of functionality. You
should not see any error message events under normal operating conditions. The
error level captures exceptions such as out-of-memory errors and errors returned
from a system call. An error means that the application or service cannot
continue processing the current request.
•
Warning. An event that is not necessarily significant, but might indicate
potential future problems. You should not see any warning message events under
normal operating conditions. For example, when disk space is low, a Warning
event might be logged.
•
Information. An event that describes the successful operation of an application,
driver, or service. For example, when a network driver loads successfully, an
Information event is logged.
•
Debug. An event that assists Microsoft® support personnel in the debugging of
the code execution path on development workstations. These events are
suppressed in a Production environment.
•
Universal date and time that the event occurred.
•
Computer on which the event occurred.
•
Application domain. .NET application domain of the component that generated the
event.
•
Exception details. Exception type, exception message, stack trace, and other lowlevel details about the event.
•
Process Id. PID of the process that generated the event.
•
Thread Id. ID of the thread that generated the event.
Event Sinks
Components of the logging subsystem are installed on all IPTV Edition machines. These
components route events to different storage entities based on a set of configurable routing
rules. Through these routing rules system events can be:
•
Sent to a local Windows® Events Log.
•
Stored in a local text file.
•
Stored in a centralized SQL database.
•
Sent to a remote debug console.
•
Sent to a centralized MOM console.
Note Critical errors and errors are sent to the MOM console by default.
During an “event storm” the logging subsystem accumulates and consolidates like events and
posts a single event with a counter that reflects the number of times it received the particular
event. This process is called Event Storm Detection and Consolidation (ESDC). ESDC occurs
when the logging subsystem receives more than 400 events per seconds and it has more than
1000 outstanding events to process. These thresholds are configurable and ESDC can be
turned off.
Service providers can customize which event stores they maintain in their system. They can
also define which events or event groups are sent to each event store. For details on
configuring the logging framework, see Operations Guide and Reference.
Performance Counters
As IPTV Edition operates over time, the values of the various counters begin to show a
pattern. Routine monitoring over periods ranging from days to months enables operators to
establish a baseline for system performance. The baseline is an indicator of how individual
system resources or groups of resources are used during periods of normal activity.
When determining a baseline, it is important to know the types of work being done and the
days and times when the work is being done. That information helps you to associate work
with resource usage and to determine the reasonableness of performance during those
intervals.
When operators acquire sufficient performance data reflecting periods of low, average, and
peak usage, they can make a subjective determination of what constitutes acceptable
performance for the system. That determination is the baseline. Operators use the baseline to
detect when bottlenecks are developing or to watch for long-term changes in usage patterns
that require an increase in capacity.
The IPTV Edition system defines the performance data it collects in terms of objects,
counters, and instances. A performance object is any resource, application, or service that can
be measured. Using MOM, operators can select performance objects, counters, and instances
to collect and present data about the performance of system components or installed software.
Each object has performance counters that are used to measure various aspects of
performance, such as transfer rates for disks or, for processors, the amount of processor time
consumed. The object may also have an instance, which is a unique copy of a particular
object type; not all object types support multiple instances.
Specific performance counter numbers are not generally important. What matters is that the
continual performance is in an acceptable range. Typically, acceptable performance counter
ranges differ for each installation and are driven by factors such as:
•
Number of set-top boxes supported.
•
Number of services offered.
•
Available bandwidth.
Logging Subsystem Software Components and Data Flow
The following diagram illustrates the logging subsystem components and how they are
distributed across the IPTV Edition system.
The following table describes each of the software components in the logging subsystem.
Component
Description
Client logger
Handles events raised by IPTV Edition clients in response to
Web service
subscriber activities. It passes all events to the local log engine. The
Component
Description
client logger Web service typically resides on the Client Gateway
machine.
Logger
Writes the events it receives from server software components to the
local event queue and then calls the log engine.
Log engine
Routes events into various sinks based on the information in the
logging configuration file.
Event Log sink
Directs logging events to the local Windows Events log.
Trace sink
Directs logging events from the log engine to TraceSink.Log, the
local, text-based, trace log file. This log “rolls over” when it reaches a
maximum size or at a specific interval (hourly/daily/monthly) as
defined in the configuration file. When rollover occurs, the current
TraceSink.Log file overwrites the history log file Tracesink.old.log
and an empty TraceSink.Log is created.
SQL sink
Directs logging events to the log data Web service. The SQL sink bulk
inserts events based on an internal non-configurable timer. The timer
duration is based on heuristics such as the number of outstanding
events. This ensures that the timer does not “sleep” for too long and it
has a reasonable number of events to process at one time.
Debug sink
Directs logging events to a debug console if one exists. You can set
the verbosity of the debug information and the port to route the debug
events in the logging configuration file.
Client
Directs client diagnostic events to an external client diagnostics event
diagnostic
sink agent Web service.
event sink
Note IPTV Edition does not include an implementation of the client
diagnostics event sink agent Web service. Service providers must use
a Web service that implements the client diagnostics event sink agent
Web service API. For details on the client diagnostics event sink agent
Web service API, see the OSS Web Service Reference (p. 015).
Log data Web
Receives log dumps from the SQL sink and writes them to the
service
centralized subscriber activity log database and event log databases.
Component
Description
Subscriber
Contains subscriber activity events such as channel changes, trick
activity log
mode access, and application starts. Subscriber activity logs help
database
service providers understand subscriber viewing patterns and usage.
Service providers can generate custom reports with reporting tools
such as SQL Reporting Services and Crystal Reports.
This database contains the subscriber activity logs from all IPTV
Edition clients, which can become very large. Periodically, operators
must move the data from this database to an activity log history
database or prune the data tables.
The activity log database is partitioned into 24 tables with 1 master
view. The 24 tables represent the 24 hours in a day. Operators can
truncate or move records without affecting continuous logging. New
events continue to be logged while a section of the database is locked
for maintenance.
Event
Contains the server and client events. Events can be either
databases
informational, such as letting an operator know that a process
successfully completed, or an alert regarding an error condition. Error
events have severities of warning, error, and critical error.
This database contains the events generated by the entire IPTV
Edition system (central repository).
Recycler job
Trims respective database tables if they grow beyond a configurable
maximum size. By default, this SQL job is scheduled to run every
hour.
Activity log
Contains historical subscriber activity logs.
history
database
See Also
Client Management Subsystem
The client management subsystem facilitates the updating and provisioning of the IPTV
Edition client software on set-top boxes. Through this subsystem, set-top boxes in the field
can be automatically updated with the latest client software.
Client Management Subsystem Software Components and Data Flow
The following diagram shows the software components of the client management subsystem.
The following table describes the software components of the client management subsystem.
Component
Description
Upgrade Web service
Downloads the stored client software to set-top boxes that request
it.
When a client is authenticated—during power up or when the
session key expires—the client sends its current software version
to the bootstrap Web service. If the client software version does
not match the software version in the bootstrap configuration file,
Component
Description
the bootstrap Web service returns an upgrade message that
contains the URL of the upgrade Web service.
The IPTV Edition client then contacts the upgrade Web service to
acquire the software upgrade and installs the new version of the
client software.
Sync Server
Client software upgrade method of last resort. If a set-top box
cannot access the bootstrap Web service or has a corrupt software
image and does not know the URL of the bootstrap Web service,
the set-top box contacts the Sync Server to upgrade its software
image. The URL of the Sync Server is burned into the boot ROM
of the set-top box.
NTP Server
The IPTV Edition system uses Network Time Protocols (NTP) to synchronize time between
client and servers as well as between servers. By using NTP, both senders and receivers can
establish the same understanding of time, leading to the correct interpretation of time stamps.
Unlike analog broadcast systems, where display time synchronization is inherent in the signal
itself, compressed video systems receive frames for display at different time offsets relative to
one another, and possibly out of order. Each frame is typically labeled with a “presentation
time,” which indicates when the frame is to be displayed. Because no two clocks progress at
exactly the same rate, compressed video systems must have a means for coordinating clocks
between the source and sink of the AV information, otherwise the receiver would be playing
back at its own data rate. If the differences are significant enough, this could lead to frame
repeats or drops, as well as eventually under running or overflowing the network reception
buffer from the source.
In a traditional broadcast system, there is no way for clients and servers to synchronize time
except to rely on:
•
Time information that is in the stream.
•
Characteristics of the broadcast channel, such as fixed delays and fixed transport bit
rates.
Traditional MPEG transport systems handle time synchronization by assuming a constant
network delay (that is, it takes the same amount of time for each packet leaving an encoder to
arrive at a decoder). The MPEG transport defines a “program clock reference” (PCR), which
is basically a number carried in the stream that says “when you receive the last bit of this
number, the exact time is the value encoded by that number.” This time synchronization
method works well for systems such as satellite and coaxial broadcast, where the variance in
network delay is insignificant.
The IPTV Edition transport does not have a constant channel delay, both because of the
nature of IP transport and because of the instant channel change (ICC) burst from the
Distribution Server (DServer).
IPTV Edition clients use a NTP time source. IPTV Edition servers, which are based on the
Windows® infrastructure, synchronize with the Windows Time service. The Windows Time
service also uses NTP to synchronize computer clocks on the network so that an accurate
clock value, or time stamp, can be assigned to network validation and resource access
requests.
Given that there are two distinct time sources within the IPTV Edition environment and that
both are required, it is necessary for the forest root-level primary domain controller to
synchronize with an authoritative time source that is external to the Windows infrastructure.
This is important because various elements of the IPTV Edition infrastructure are time
dependant, thus requiring that the IPTV Edition external time source and the Windows
domain time source remain synchronized for sustained operation of the IPTV Edition system.
Maintaining AV Time
Timestamps are used for delivering AV samples at the correct time as well as for set-top box
buffer management. In the IPTV Edition system, the timestamps associated with audio and
video samples are tied to NTP using correspondences in the Real-Time Protocol (RTP)
transport.
It is critical that the slope of change in time is low so that the Acquisition Server and set-top
box time do not drift apart. A drift in time could cause an AV buffer underflow or overflow in
the set-top box.
Because the IPTV Edition system leverages the NTP server for clock reconstruction between
the Acquisition Server and client, the networking connection between the encoder and
Acquisition Server must have very low jitter. This minimizes the clock drift and enables the
Acquisition Server to inherently trust the PCR information emanating from the real-time
encoder.
When the Acquisition Server receives the PCR information from the real-time encoder, it
inserts a “correspondence” into the RTP stream. This correspondence associates a PCR
representing the real-time encoder time with an NTP timestamp from the NTP server system.
This association enables clock recovery to occur on the client.
Acquisition Servers and clients poll the NTP server once every five seconds for
approximately two minutes, and then back off to once every 64 seconds. No further NTP
polling adjustments are made after the system backs off to once every 64 seconds.
Client Authentication and Rights Interpretation
Each IPTV Edition client is authenticated using certificates. For the certificate-based client
authentication to work properly, both the client and authentication servers must have the same
understanding of time.
Additionally, the subscriber management subsystem (SMS), maintains the records of rights
and purchases for each subscriber account. For the rights management functionality to work
and for the client to have the appropriate keys to decrypt AV content without interruption, the
branch servers and clients must have the same understanding of time.
Server Authentication
IPTV Edition servers use integrated Windows authentication. This authentication method
relies on NTP to provide an accurate understanding of time between servers. Windows Server
2003 implements an NTP stack to establish and maintain correct time within a forest.
NTP Server Categories
NTP servers are usually categorized in terms of strata, where a lower stratum signifies a level
closer to the root of the hierarchy and typically higher time accuracy. A stratum 1 server
typically gets its time directly from an attached atomic clock or GPS receiver. A stratum 2
server gets its time from the stratum 1 server, and so on. Microsoft® TV recommends the
usage of stratum 1 servers dedicated to the IPTV Edition deployment.
NTP Architecture
NTP is typically deployed in one of three different architectures:
•
Star
•
Peer-to-Peer
•
Hierarchical
Microsoft recommends that NTP servers be deployed in a hierarchical fashion for reliability,
stability, and scalability.
TV Services Management Tool
The TV Services Management tool is the administration tool that operators use to configure
and administer all IPTV Edition server components and services. The TV Services
Management tool provides centralized management regardless of the geographical location of
individual server machines and components.
The TV Services Management tool is a Web application delivered by an IIS server and hosted
by Microsoft® Internet Explorer. The IIS server handles management actions by interacting
with the Web service interfaces of the IPTV Edition servers. This configuration enables
network operators to configure multiple IPTV Edition servers in a simple, coordinated
manner. For example, when adding a live video service, the TV Services Management tool
updates the related subsystems. Separate configuration and synchronization are unnecessary.
For information about starting and operating the TV Services Management tool, see
Operations Guide and Reference.
You can use one of the following TV Services Management tool pages to configure IPTV
Edition services:
Live Management at the Acquisition Group Backend
You can use the Live Management page at the acquisition group backend machine to
create, assign, and publish live TV services.
Live Management at the Branch
You can use the Live Management page at the branch to deploy live TV services.
Channel Map
You can use the Channel Map pages to manage service collections, channel maps,
packages, offers, and grants, and to deploy channel maps to subscriber groups.
VOD Management
You can use the VOD Management page to modify validation rules and media profiles
for VOD assets and import and deploy the assets to the IPTV Edition system.
Applications
You can use the Applications page to add a new RDP application to the IPTV Edition
system and modify or delete an existing RDP application.
Subscriber Management
You can use the Subscriber Management pages to manage subscriber accounts, devices,
and groups. You can use these pages to manage your IPTV Edition subscriber
information only if your IPTV Edition system is not integrated with your business
system. You must configure a subscriber account for each household that accesses IPTV
Edition services. You must associate at least one set-top box (device) with each account.
Subscriber groups enable you to categorize subscribers with common functional and
access rights into a single set and manage the group instead of individual subscribers.
PPV Management
You can use the PPV Management page to configure PPV assets and add new PPV
service collections.
Settings
You can use the Settings page to configure parental control, RDP applications, subscriber
activity logging, and other miscellaneous IPTV Edition server and client settings.
See Also
Multiple and Simultaneous Interactions with TV Services Management Tool (p. 126)
Multiple and Simultaneous Interactions with TV Services Management
Tool
When users attempt to modify data at the same time, one user’s modifications have the
potential to adversely affect modifications from simultaneous users. A concurrency control
system is necessary to handle this situation.
Note The TV Services Management tool supports one user per backend and one user per
branch simultaneously.
There are different models for concurrency control. The TV Services Management tool
follows the last-in-wins model to manage concurrency. In this model, a row is unavailable to
users only while the data is actually being updated. However, no effort is made to compare
updates against the original record. When you update, the record is simply written out,
potentially overwriting any changes made by other users since you last refreshed the records.
For example, if several customer service representatives (CSRs) are updating subscriber
records and two of them are working on the same record, the information is updated based on
the changes made by the last person who saved the data.
With a last-in-wins model, no check of the original data is made, and the update is simply
written to the database. It is understood that the following scenario can occur:
•
User A fetches a record from the database.
•
User B fetches the same record from the database, modifies it, and writes the updated
record back to the database.
•
User A modifies the “old” record and writes it back to the database.
In the preceding scenario, User A never sees the changes that User B made, and the database
does not reflect the change made by User B.
OSS Web Services
The operations support systems (OSS) Web services enable the TV Services Management
tool and other OSS systems to manage the acquisition and delivery of live TV, VOD, and
RDP application services.
Web Service
Description
Backend Blackout Management Web
Enables OSS systems to manage service
Service (p. 129)
substitutions, also known as “blackouts,” at the
backend.
Blackout Management Web Service (p.
Enables OSS systems to manage service
130)
substitutions at the branch, also known as
“blackouts.”
Branch Management Web Service (p.
Enables applications to manage the
131)
configuration of service groups at a branch.
For details on service groups, see Architecture
of IPTV Edition (p. 008).
Channel Management Web Service (p.
Enables OSS systems to manage channel maps
131)
and media descriptions, and assign channel
maps to subscriber groups.
Diagnostics Notification Web Service
Enables OSS systems to send requests for
(p. 132)
diagnostics information to all IPTV Edition
clients associated with a specific account
through the notification subsystem.
EPG Web Service (p. 133)
Enables Web clients to fetch information about
the program schedule.
Live Backend Management Web Service
The live backend management Web service
(p. 133)
enables operations support systems (OSS) to
retrieve information about live TV services and
control failover from one DServer to another.
PPV Management Web Service (p.
Enables OSS systems to manage the
Web Service
Description
133)
deployment of Pay Per View (PPV) assets.
Remote Recording Web Service (p.
Enables Web clients to remotely schedule
134)
recordings and modify previously-scheduled
recordings.
Reporting Store Web Service (p. 141)
Enables applications to access billing records
associated with subscribers in all service
groups.
UI Notification Web Service (p. 134)
Enables OSS systems to deliver short messages
that appear on the screens of IPTV Edition
clients through the notification subsystem.
URL Management Web Service (p.
Enables service providers to create and modify
136)
special services based on multi-views and Web
content.
VOD Backend Management Web
Enables the TV Services Management tool and
Service (p. 136)
other operations support systems (OSS) to
manage VOD asset importation at VOD
backends.
VOD Branch Management Web Service
Enables the TV Services Management tool and
(p. 136)
other operations support systems (OSS) to
manage VOD asset deployment at VOD
branches.
Backend Blackout Management Web Service
The backend blackout management Web service enables OSS systems to manage service
substitutions at the backend. Service substitutions are also known as “blackouts.”
The backend blackout management Web service coordinates with the live TV subsystem to
ensure that main and PIP streams are encrypted and encapsulated with blackout information.
Each IPTV Edition client uses the information delivered in the streams and information it
receives through notifications to determine if the subscriber can view the blacked-out event,
or if the subscriber should view the alternate services.
The backend blackout management Web service can define substitution events but it cannot
specify the subscriber groups that are prevented from viewing the event because subscriber
groups are defined at the branch, and stored in the branch management database. The
subscriber group list can be added through the blackout management Web service afterwards,
however. Backend OSS applications can define the service details of a blackout and each
branch can then specify subscriber groups at that branch afterward.
Note Operators cannot define blackouts through the TV Services Management tool. For
details on the backend blackout management Web service API, see Backend Blackout
Management Web Service (p. 017).
Blackout Management Web Service
The blackout management Web service enables OSS systems to manage service substitutions
at the branch. Service substitutions are also known as “blackouts.”
Branch operators define blackouts by identifying properties of a substitution event, including:
•
The main and PIP services on which the event is delivered. Both services must come
from the same live backend.
•
A time window within which the event starts and ends.
•
A set of subscriber groups that should not be allowed to view the event.
•
The main and PIP services (referred to as "alternate" services) that subscribers see
instead of the blacked-out event if they are members of any of the specified
subscriber groups.
Service substitution is implemented through coordination of rights management (at the
backend) and notifications (at the branch). The blackout management Web service provides a
single API through which OSS applications can define service substitutions. The blackout
management Web service coordinates the appropriate data flow between the IPTV Edition
server components to implement the substitution.
The blackout management Web service is deployed at the branch. A similar Web service, the
backend blackout management Web service resides at the backend.
The branch instance of the blackout management Web service is intended for access by OSS
applications. It coordinates with the notification subsystem and with the backend instance of
the blackout management Web service.
Branch Management Web Service
The branch management Web service enables applications to manage the configuration of
service groups at a branch.
Note Service groups can only be created through the TV Services Management tool. The
branch management Web service supports only reading and updating existing service groups.
For more details on branch management and service groups, see Architecture of IPTV Edition
(p. 008).
Channel Management Web Service
The channel management Web service enables OSS systems to manage channel maps and
media descriptions, and assign channel maps to subscriber groups.
The following diagram shows how the channel management Web service interacts with other
IPTV Edition software components.
Diagnostics Notification Web Service
The diagnostics notification Web service enables OSS systems to send requests for
diagnostics information to all IPTV Edition clients associated with a specific account through
the notification subsystem. The notification subsystem delivers the request messages to the
IPTV Edition clients over UDP/IP. The IPTV Edition clients respond to the request by
uploading diagnostic information to the logging subsystem. The logging system can then
upload the client diagnostics to a custom client diagnostics event sink Web service.
The following diagram shows how the diagnostics notification Web service interacts with
other IPTV Edition software components.
See Also
Logging Subsystem (p. 112)
EPG Web Service
The EPG Web service enables Web clients to fetch information about a service's program
schedule. This information can be useful when scheduling recordings with the Remote
Recording Web Service (p. 134).
The EPG Web service interacts with the EPG subsystem.
Live Backend Management Web Service
The live backend management Web service enables OSS systems to retrieve information
about live TV services and control acquisition server failover.
The following diagram shows how the live acquisition group management Web service
interacts with other IPTV Edition software components.
PPV Management Web Service
The PPV management Web service enables OSS systems to manage the deployment of Pay
Per View (PPV) assets.
The following diagram shows how the PPV management Web service interacts with other
Remote Recording Web Service
The remote recording Web service enables Web clients to remotely schedule recordings, as
well as view and manage previously-scheduled recordings, for a particular set-top box. It
interacts with the DVR scheduler subsystem, which in turn interacts with the EPG subsystem
and with individual set-top boxes.
See Also
EPG Web Service (p. 133)
UI Notification Web Service
The UI notification Web service enables OSS systems to deliver short messages that appear
on the screens of IPTV Edition clients through the notification subsystem. Applications
contact the UI notification Web service to schedule messages for delivery to specific clients
or for broadcast to all clients. The notification subsystem delivers the messages to IPTV
Edition clients over UDP/IP. The IPTV Edition clients display the messages on screen until
the messages expire or until the subscriber dismisses them.
The following diagram shows how the UI notification Web service interacts with other IPTV
Edition software components.
Note If a message is larger than 2 KB, the UI notification Web service throws an exception.
See Also
URL Management Web Service
The URL management Web service enables service providers to create and modify special
services based on Web content or "multi-view" (services that display several video feeds at
one time).
VOD Backend Management Web Service
The VOD backend management Web service enables the TV Services Management tool and
other operations support systems (OSS) to manage VOD asset importation at VOD backends.
The following diagram shows how the VOD backend management Web service interacts with
VOD Branch Management Web Service
The VOD branch management Web service enables the TV Services Management tool and
other operations support systems (OSS) to manage VOD asset deployment at VOD branches.
The following diagram shows how the VOD branch management Web service interacts with
BSS Web Services
The business support systems (BSS) Web services enable BSS systems to manage the
acquisition and delivery of live TV, VOD, and RDP application services.
Web Service
Description
Billing Record Management Web Service
Manages billing records in the subscriber
(p. 139)
management subsystem (SMS).
Important This is a legacy web service,
provided for backward compatibility. At some
point in the future, this web service may be
removed. For future development, you should
use the Reporting Store Web Service (p.
141).
Grant Management Web Service (p.
Manages the activities (play, pause, record)
139)
enabled on resources, such as live TV
services, VOD assets, and RDP applications.
Offer Management Web Service (p.
Manages the details of offers (price, tax, and
140)
expiration) associated with live TV services,
VOD assets, and RDP applications.
Package Management Web Service (p.
Manages packages, which can contain either a
140)
set of services or a set of other packages.
Principal Management Web Service (p.
Manages IPTV Edition principals (devices,
141)
users, accounts, and subscriber groups).
Principal Management Web Service
BSS2 version of the principal management
(BSS2) (p. 094)
Web service, which lets business support
systems (BSS) read information about
subscriber groups.
Reporting Store Web Service (p. 141)
Enables applications to access billing records
associated with subscribers in all service
groups.
Note IPTV Edition includes legacy versions of BSS Web services for backward
compatibility with previous releases. The legacy Web services are deployed in different
virtual directories than the one in which they were originally deployed. For example, the
legacy version of the billing record management Web service has the following new
endpoint: http://servername/bss/legacy/1.0.1/BillingRecordManagement.asmx whereas the
current version uses the following endpoint:
http://servername/reportingstore/BillingRecordManagement.asmx.
Billing Record Management Web Service
Important This is a legacy web service, provided for backward compatibility. At some
point in the future, this web service may be removed. For future development, you should use
the Reporting Store Web Service (p. 141).
The billing record management Web service provides an API through which BSS systems
manage billing records in the SMS. For example, custom applications can enable CSRs to
view or delete billing records.
The following diagram shows how the billing record management Web service interacts with
Grant Management Web Service
The grant management Web service enables BSS systems to manage the activities (purchase
and play) enabled on resources, such as live TV services, VOD assets, and RDP applications.
Grants are maintained in the SMS.
The following diagram shows how the grant management Web service interacts with other
The grant management Web service supports scenarios such as:
•
Granting the right to a resource for a subscriber; for example, free premium service
for the next two days.
•
Extending a grant; for example, extending the expiration for VOD.
•
Assigning the principals to a particular resource; for example, assigning all
subscriber groups for a particular VOD asset.
•
Getting the resources for a particular principal; for example, getting all VOD assets
for a single subscriber group.
•
Revoking a grant.
Offer Management Web Service
The offer management Web service enables BSS systems to manage the details of offers
(price, tax, and expiration) associated with live TV services, VOD assets, and RDP
applications.
The following diagram shows how the offer management Web service interacts with other
Offer details are maintained in the SMS.
Package Management Web Service
The package management Web service provides an API through which BSS systems manage
packages. Each package contains either a set of services or a set of other packages.
The following diagram shows how the package management Web service interacts with other
Packages are maintained in the SMS.
Principal Management Web Service
The principal management Web service enables BSS systems to manage IPTV Edition
principals (devices, users, accounts, and subscriber groups).
The following diagram shows how the principal management Web service interacts with
Principals are maintained in the SMS.
Reporting Store Web Service
The reporting store Web service enables applications to access billing records associated with
subscribers in all service groups. It exposes an API that is nearly identical to the billing record
management Web service, which resides at the service group level and has direct access to the
service group database. Although applications can access the billing record management Web
service, the reporting store Web service is designed specifically for use by OSS and BSS
applications.
The reporting store Web service is supported by an aggregation engine that collects billing
records from all service groups within a branch. Because the aggregation engine runs hourly,
billing records may appear up to one hour after they are created.
The reporting store Web service's central billing aggregation point offers many advantages:
•
The heavy load of monthly billing does not impact IPTV Edition clients.
•
Deleting records from the central aggregation point does not impact IPTV Edition
clients.
•
Applications do not have to access each service groups individually.
•
The daily load associated with managing billing records is moved from the service
group server to the server running the reporting store Web service, which improves
service group performance.
•
It maintains a history of reference data so that at month end, even if an asset is
deleted from the branch, its details can be accessed and used for billing purposes.
Note The reporting store Web service manages billing records that include more data than
the records managed by the billing record management Web service. Specifically, the
reporting store Web service billing records include rating and tax information.
IPTV Edition Client
The IPTV Edition client is an IP-connected device that consumes video and data services
delivered by the IPTV Edition server machines. The IPTV Edition client presents a user
interface (UI) that enables subscribers to discover and view or interact with those services.
IPTV Edition clients run IPTV Edition client software, which is used to connect to and access
IPTV Edition services. Each IPTV Edition client device is assigned a unique ID or a hardware
key by the manufacturer, which enables it to authenticate itself with the IPTV Edition server
machines. After authentication, the IPTV Edition client receives a list of the URLs of IPTV
Edition Web services that provide the configuration data the client requires to discover and
consume IPTV Edition services.
The client is an embeddable software component that runs on Microsoft® Windows® CE and
can be installed on a set-top box or in devices such as televisions, DVD players, digital video
recorders (DVRs), or game consoles. The IPTV Edition client is designed to support
extremely low-cost hardware implementations.
The follow diagram shows the architecture of the IPTV Edition client.
User Interface Framework
The IPTV Edition subscriber UI is a managed application that runs on the Microsoft .NET
Compact Framework (CF) with a custom rendering engine.
The subscriber UI uses .xml data files to define the text strings, graphics files, fonts, and other
elements in the UI. By modifying the content of these .xml data files, you can customize the
UI without having to rebuild the client software.
The IPTV Edition client enables you to customize the following UI elements:
•
Logo
•
Color
•
Font
•
Language
•
Text strings
•
Menu
•
Graphics
•
Triple-tap keys
For details on UI customization, see User Interface Customization Guide.
Service providers can also create special URL services. These services deliver material
located on an HTTP server to client set-top boxes. The URL services can deliver two kinds of
data:
•
Images (graphics in the JPEG or PNG formats)
•
Multi-view pages, which display one or more picture-in-picture frames, as well as
other text and/or graphics
Multi-view pages are written in XHTML, then converted to a special IPTV XML format
suitable for delivery to the set-top box. The converted XML file is actually hosted on the
HTTP server, and delivered to the client; the XHTML file is used only as source material to
generate that XML file.
For more information about creating and deploying URL services (whether single-image or
multi-view pages), see Operations Guide. For information about coding multi-view pages and
converting them to the IPTV format, see Multi-View Application Developer's Guide.
Data Exchange
The UI consumes data that originates or is maintained at the IPTV Edition server machines.
Some of this data, such as listings and subscriber rights, are cached at the client to enable
faster access. If the cached information changes at the server machine, a notification message
is sent to the client to update its cache. Similarly, if session keys or boundary keys expire and
are rejected or the client cannot connect to a Distribution Server (DServer), the client requests
updated information from the IPTV Edition server machines.
IPTV Edition clients communicate only with the IPTV Edition server machines in the
perimeter network, which is also sometimes referred to as the "demilitarized zone" (DMZ).
The Terminal Server, DServer, VOD Server, and Client Gateway machines all reside in the
perimeter network. Other IPTV Edition server components send data directly to IPTV Edition
clients. The following diagram provides a high-level overview of the data exchange between
the IPTV Edition server machines and IPTV Edition clients. For detailed interactions, refer to
the specific subsystem descriptions.
Audio/Video Service Support
The IPTV Edition client includes an A/V engine that supports the acquisition, decryption, and
display of decompressed (both real-time and time-shifted) A/V data. The IPTV Edition client
uses command and control messages to synchronize with the machines delivering the content.
The A/V engine includes codecs that decrypt audio and video data and decode it into video
frames and uncompressed audio streams. The IPTV Edition client supports video content in
VC-1 H.264, or MPEG-2 format, and audio content in Windows Media® Format 9 Series and
MPEG-1 layer 2.
The A/V engine supports delivery of these stream types by Real-Time Protocol (RTP)
transport. The client device interacts with the Client Gateway machine that interfaces with the
branch. The branch provides the client device with keys that enable the subscriber to receive
and consume media.
DVR Engine, Storage, and Management
The IPTV Edition subscriber UI enables subscribers to schedule a single recording or a series
of recordings using local storage on the set-top box. DVR scheduling, however, is managed
by the DVR Scheduler Subsystem (p. 104) on the IPTV Edition server machines.
The IPTV Edition client keeps track of pending recordings and starts and stops the recording
based on these schedules. Recording schedules may be cached in volatile storage, but when
an IPTV Edition client powers up, it does not assume that pending recordings are cached.
Instead it queries the DVR scheduler subsystem for scheduling information.
RDP Application Support
The IPTV Edition client includes a Remote Desktop Protocol (RDP) client software module
that enables subscribers to launch and interact with applications that run on the RDP
application subsystem. Subscribers access RDP applications through the client menu or
through the program guide.
RDP applications can be in the form of Web applications or stand-alone Windows
applications and can interact with remote resources, such as Web servers and databases.
Sample RDP applications include the billing, self-provisioning of services, and credit limit
applications.
To protect restricted content, the client receives the location of the RDP Application Server
machine only after the system authenticates the client through the bootstrap process. Every
version of RDP uses RSA Security’s RC4 cipher. RC4 uses secure network communications
like those found in protocols such as SSL.
In Windows Server 2003, administrators can encrypt RDP data using a 56-bit or 128-bit key.
By default, 56-bit keys are used in bidirectional encryption.
Most PC Web-based applications include an option that (after initial logon) enables the user
to log on automatically during subsequent visits to the Web site from that PC. User
credentials are stored in a cookie in the Windows user profile on the PC and sent to the Web
site on subsequent visits. The same automatic logon experience works for Web-based
applications accessed over RDP by subscribers with IPTV Edition clients. Cookies are
automatically moved from the Windows user profile on the Terminal Server to the subscriber
database on disconnect, and are then moved back to the Windows user profile on reconnect.
The cookies are preserved no matter which Terminal Server and Windows user is active when
the subscriber accesses the application.
For additional information on RDP applications, see RDP Application Subsystem (p. 059).
Bootstrap and Client Authentication
The IPTV Edition client boot ROM contains instructions for powering-up, system initializing,
and launching the IPTV Edition client software.
IPTV Edition clients support both dynamic host configuration protocol (DHCP) and point-topoint protocol over Ethernet (PPPoE) for connecting to the IPTV Edition server machines.
This enables support for households with or without routers in their networks.
Whenever a client logs on to the system, normally at boot time or after the connection to the
service is interrupted, the following client authentication sequence occurs:
1) The client establishes a connection with the bootstrap Web service, presents its (nonA/V) certificate and a randomly generated value or “nonce,” and then requests a
ticket to contact services.
2) The bootstrap Web service validates the client certificate for authenticity. If the
certificate isn’t authentic, the bootstrap Web service logs the event, and then closes
the connection. If the certificate is valid, the bootstrap Web service does the
following:
a) Generates a symmetric key for session encryption (session key).
b) Encrypts the session key with the client’s public key.
c) Signs both the encrypted session key and the nonce.
d) Creates a client ticket.
The client ticket is fully opaque to, and not modifiable by, the client. The client
ticket contains the client’s non-A/V session key and the client ID, which are
encrypted with the branch key.
e) Transmits to the client the signed, encrypted session key, the signed nonce, the
client ticket, the server public key, and the server certificate.
3) The client decrypts the session key with its private key, validates the server
certificate, and then validates that the nonce was signed correctly by the server. If the
server certificate isn’t authentic or if the nonce wasn’t encoded properly, the client
closes the connection, and then posts an error message to the screen.
4) If the client authenticates the server, the client attempts to log on to the service. The
client encrypts each session with the symmetric session key and presents its client
ticket to the bootstrap Web service.
5) The bootstrap Web service checks for cloning and, optionally, certificate revocation.
The bootstrap Web service queries the subscriber management subsystem (SMS) to
ensure that the client isn’t logged on to the system using a different IP address or that
the client certificate wasn’t revoked. Revocation involves permanently disabling a
subscriber from accessing a piece of content. The revoked device is no longer able to
decrypt the revoked content. After content is revoked, the only way to restore or
regain access to the particular piece of content is to reissue a license for it.
If the client is valid, the bootstrap Web service returns the service list to the client. If
either of the checks fails, the bootstrap Web service logs the event, and then closes
the connection to the client.
6) When the client wants to contact a service, it looks up the service on the service list,
and then presents the client ticket to prove its right to access the service.
Client Remote Control
Both the Microsoft TV IPTV Edition PC Client (PC Client) application and the set-top boxes
support the IPTV Edition infrared (IR) remote control. The remote control is designed to be
familiar to any subscriber and to provide quick access to features such as the Video on
Demand screen and digital video recordings.
The remote control includes the following functionality:
•
Channel up (+), channel down (-), and the number buttons are consistent with
standard TV remote controls.
•
Playback control buttons enable fast-forward, rewind, pause, replay, skip, and stop
for digital video recording content.
•
Directional navigation buttons enable subscribers to navigate the subscriber UI and
activate Browse mode to preview programs.
•
MENU and GUIDE buttons provide access to the two most frequently used
interactive applications.
•
RECORDED TV and VIDEOS buttons enable quick access to recordings and the
Video on Demand screen.
•
EXIT TO TV button dismisses the subscriber UI and returns the subscriber to fullscreen TV.
•
INFO button invokes a description of the current or highlighted show.
•
BACK button returns the subscriber to the previous screen.
For a complete description of the remote control buttons, see Subscriber’s Guide.
Client Upgrade
The IPTV Edition system supports automatic upgrades of client software in the field. During
the client authentication process, the client sends its software version to the bootstrap Web
service on the server machines. The bootstrap Web service compares the client’s software
version to the “current” client software version defined in an operator-configurable XML file.
If the version numbers do not match, the client is rerouted to the upgrade Web service. This
service is responsible for downloading the upgraded software image to the set-top box.
When a client’s software is upgraded, the set-top box receives a completely new software
image (partial updates are not supported). After loading the new image, the set-top box
reboots and reinvokes the client authentication process.
Subscribers cannot opt out of upgrading the software on the set-top box.
For additional information, see Client Management Subsystem (p. 120).
Multiple Client Households
IPTV Edition supports individual households having more than one set-top box. In this
situation, one set-top box has a hard disk and records programming for the entire household.
If a household has multiple set-top boxes, subscribers can watch any recorded show from any
set-top box. When a recording is scheduled, IPTV Edition uses an idle set-top box to record
the program, if possible.
Each household is assigned a certain number of streams. The number of streams determines
how many live TV offerings the household can watch at a time. When a set-top box watches
or records a live TV program, one stream is used. (Watching already recorded shows,
including VOD, does not use a stream; neither does running an RDP application.) When a
subscriber tries to use more streams than the household is entitled to, the IPTV Edition client
shows a conflict resolution screen, prompting the subscriber to select which activities have
higher priority.
In addition to a set number of streams, each household is also allocated a maximum
bandwidth. The household's maximum bandwidth is calculated automatically from the
number of standard and HD streams allocated to that household. If a subscriber tries to
perform an activity which would cause the household to exceed its maximum bandwidth, a
conflict resolution screen is shown.
Set-Top Boxes With and Without Hard Disks
If a household has several set-top boxes, generally only one set-top box has a hard disk. That
set-top box handles all the recording for the entire household. To a subscriber in this situation,
there is no difference between a set-top box with or without a hard disk. Any function that a
subscriber can perform at one set-top box, can be performed at any set-top box in the
household. For example, as long as the set-top box with the hard disk is turned on, subscribers
can:
•
Watch recorded TV programs because the diskless set-top box fetches content from
the set-top box with the hard disk.
•
Pause and rewind live TV because the diskless set-top box fetches the stored data
from the set-top box with the hard disk.
Each set-top box communicates directly with the various IPTV Edition servers. The various
set-top boxes in a household communicate with each other to notify the other set-top boxes of
scheduled recordings. Whenever a set-top box communicates with the DVR scheduler
subsystem, the set-top box checks to see if its program guide information is out of date. If it
is, the set-top box notifies the other set-top boxes in the household that the program guide
needs to be updated.
Client Streams
Every household is allocated a certain number of streams. The streams are used to allocate
full-stream video content. There are two different kinds of streams:
•
A high-definition (HD) stream can be used to watch or record high-definition or
standard-definition content.
•
A standard-definition (SD) stream can be used to watch or record standard-definition
content, but not high-definition content.
Subscribers can monitor how streams are allocated by using the Program Activity screen.
Subscribers can transfer streams from one set-top box to another and configure the Program
Activity screen to require a PIN before moving streams.
If a set-top box goes into standby mode and is not recording a program, it releases any stream
it may have, allowing another set-top box to use it. Similarly, if a set-top box is watching
already-recorded content, it releases its stream.
If there is no subscriber activity on a set-top box for an operator-configured period of time,
the stream is designated as "stale". If another set-top box needs a stream and no unused
streams are available, the set-top box can use one of the stale streams. If an HD stream is
being used to play standard-definition content, the HD stream can also be designated as
"stale". If another set-top box has a standard-definition stream but wants to tune to a highdefinition channel, it can swap streams with the set-top box that currently has the HD stream.
Actions Which Do Not Require a Stream
If a set-top box does not have a stream, it cannot record live TV or watch PPV or VOD
content. However, it can do the following things:
•
Watch prerecorded content, whether standard-definition or high-definition (including
previously recorded PPV offerings).
•
Use RDP applications.
•
"Follow" the stream being watched by another set-top box. In this situation, one settop box has a stream and watches or records content normally. The other set-top box
does not have a stream, but follows the programming watched by the first set-top
box. The streamless set-top box cannot change channels, and cannot pause, rewind,
or fast-forward through the content viewed by the first set-top box. If the first set-top
box changes channels, the second set-top box follows the programming watched by
the first set-top box.
Note A set-top box with a standard-definition stream can follow a high-definition
broadcast being viewed by the set-top box with the HD stream.
Index
_bootstrap DNS record, 82
subsystem, 70
A/V support
Web service, 70
client, 146
asset store subsystem, 14
access rights, 86
assigning
assigning VOD rights to subscribers,
57
accounts to service groups, 95
asymmetric server session keys
account information, 89
distributing, 109
accounts
generating, 109
assigning to service groups, 95
acquisition controller Web service, 25
authenticating IPTV Edition clients, 14,
82
acquisition server
authentication
failover, 133
client, 148
acquisition Windows service, 25
AV timing, 122
Acquistion Server, 25
acquistionController, 25
backend blackout management Web
service, 129
adaptive allocation
bandwidth
about, 50
VOD, 51
application tier, 68
billing events, 86
architecture
client, 143
logical, 8, 12
asset files
VOD, 51
asset security, 57
asset store
database tables, 91
Asset Store
database, 70
storing, 14
billing record management Web service,
14, 139
billing Web service
SMS Web service, 86
blackout management Web service, 130
bootstrap
client, 148
bootstrap Web service, 14, 82
in service groups, 92
bootstrapping, 96
bootstrap, 148
branch
command and control, 146
server-facing Web services, 97
branch database, 91
replicating, 89
data exchange, 145
DVR, 147
PPPoE, 148
branch databases, 96
public key, 148
branch management subsystem, 91, 95
RDP application support, 147
branch management Web service, 89, 131
receiving updated EPG listings, 72
BranchMgmtWS
remote control, 149
Web service in the branch, 97
BSS
Web services, 14
BSS (business support systems), 14, 86,
138
session keys, 148
startup sequence, 98
UI framework, 144
upgrading, 150
X.509 certificate, 148
BSS Web services, 86, 138
client authentication, 57
business logic, 86
client authentication timing, 122
business support systems See BSS, 138
client clock, 122
client holes, 29
client management subsystem, 14
certificates
client messages, 98
protecting with asymmetric
cryptography, 109
CFZ
see client-facing zone, 68
channel changes
logging, 14
channel management Web service, 14,
131
channel maps, 75
assigning, 75
default, 75
managing, 131
client
delivering on schedule, 98
client notification Web service, 98
client RDP sessions, 147
client rights Web service
SMS Web service, 86
client state
stored in service group database, 98
clientEdgeMapWS, 29
clientEdgeMapWS Web service
clientEventLogDataWS
A/V support, 146
client-facing Web services, 89, 92
architecture, 143
client-facing zone, 68
authentication, 148
clientLoggerWS Web service
databases
clients
branch, 91, 96
authenticating, 14, 82
replicating branch tables, 91
master (in multiple client
environment), 104
service group, 91
Terminal Server controller, 63
recording schedules, 104
debug sink, 112
upgrading software, 14, 82, 120
default channel map, 75
clusters
delivering VOD assets
VOD regional, 43
described, 54
command and control
device information, 89
client, 146
DHCP
components
establishing IP connectivity, 82
VOD description of, 46
diagnostics notification Web service, 14,
98, 132
configuration
acquiring data, 14
diagram
conflicts
live TV acquisition subsystem, 25
detected by DVR scheduler
subsystem, 104
live TV delivery subsystem, 29
live TV subsystem, 22
connecting to RDP sessions, 64
user store subsystem, 107
credit limits, 86
dialog boxes
DAS servers
blocking in RDP applications, 61
VOD, 48
digital video recorder See DVR, 14
data access layer
digital video recording
service group subsystem, 89
management of, 104
data exchange
scheduling in multiple client
environment, 105
client, 145
data migration, 89
discovery Windows® service, 84
database
distributing VOD assets
about, 41
Asset Store, 70
event log, 112
Distribution Server See DServer, 29
live acquisition service, 25
DRM
VOD, 57
live configuration state, 29
replicating to service group database,
95
DRM keys for VOD, 54
subscriber activity log, 112
DServer controller Web service, 29
database migration tool, 89
DServer, 29
DServer Windows service, 29
dserverController, 29
DServers
deploying live TV delivery
subsystems, 14
EPG listings
client update notification, 72
data flow diagram, 72
file import, 72
EPG subsystem, 72
dserverService, 29
EPG Web service, 133
DVR, 8, 12
epgWS
client, 147
database tables, 91
EPOC system integration, 58
on diskless set-top box, 151
EQoS system integration, 58
DVR (digital video recorder), 14
scheduling, 14
DVR schedule updater Windows service,
104
DVR scheduler subsystem, 14, 104
illustration, 105
DVR See Recorded TV, 147
dvrRemote Web service
dvrScheduleUpdateService Web service
dvrV2WS Web service
eHome
see Windows XML Media Center
eHome shell, 61
Electronic Program Guide See EPG, 14
Electronic Program Guide subsystem, 14
ELS
see external login server Web service,
82
event log, 112
event sink, 112
events
logging, 112
Extensibility Framework, 14
external login server Web service, 82
external purchase offer cycle, 58
external quality of service
integrating, 58
failover
acquisition server, 133
failover scenario
firewalls
keeping NAT ports open, 98
framework
subscriber UI, 144
generating VOD trick streams
about, 52
encoderService, 25
GLF format, 14
encoding live TV services, 25
global VOD trick stream settings, 52
entitlements
grant management Web service, 14, 139
granting default, 86
heartbeat protocol, 98
storing in SMS database, 86
high performance trick streams, 52
EPG, 8, 12
high quality trick streams, 52
high-level architecture, 14
update notification, 72
ICC, 29
live acquisition group management Web
service, 25
ICC with IGMP, 29
live acquisition service database, 25
importing VOD assets
live backend management Web service,
14, 133
described, 53
index file, 104
live config and cluster assignment
database tables, 91
individual VOD asset trick stream
settings, 52
live configuration state database, 29
instant channel change See ICC, 29
live configuration state Web service, 29
IPTV Edition client
live TV
startup sequence, 98
IPTV Edition clients
authenticating, 82
upgrading software, 82
channel maps, 75
EPG data flow diagram, 72
live TV acquisition subsystem, 14, 21, 25
failover scenario, 25
process flow, 25
key
change notifications, 98
key generator Windows® service, 109
key management Web service
SMS Web service, 86
scalability, 39
software components, 25
live TV delivery subsystem, 14, 21, 29
failover scenario, 29
key manager Windows® service, 86
process flow, 29
language names
reliable UDP, 29
RFC 1766, 61
languages
supporting multiple in RDP
applications, 61
listings
acquiring, 14
GLF format, 14
listings data
client update notification, 72
retry strategy, 29
scalability, 39
software components, 34
live TV services
acquiring and delivering, 14
live TV subsystem
scalability, 39
liveAcquisitionServiceDB, 25
data flow diagram, 72
liveAcquisitionServiceManagementWS,
25
file import, 72
LiveBackendUpdate
listings data share, 14
listings file
import, 72
liveConfigStateDB, 29
liveConfigStateWS, 29
load-balancing, 89
logging
configuring, 112
events, 112
sinks, 112
storing for RDP applications and
VOD assets, 14
VOD assets, 51
migration
data, 89
logging subsystem, 14
MOM console, 112
logs
multicast
collecting service, 14
collecting subscriber activity, 14
Macrovision
VOD, 57
managing RDP sessions on each Terminal
Server, 66
mdws Web service
mdWSPrivate Web service
Media Center
application support, 61
object model support, 61
media descriptions, 14
managing requests for, 14
media descriptors
identifying services, 86
media discovery
delivering streams to live TV delivery
subsystems, 14
multiple-client households, 150
multi-view applications, 144
NAT gateway traversal, 98
notification
database tables, 91
notification controller Web service, 98
notification delivery Windows service, 98
listening on port 43962, 98
notification subsystem, 14, 98
notificationController Web service
notifications
broadcasting to all clients, 98
delivery over UDP/IP, 98
heartbeat protocol, 98
message delivery, 98
private Web service, 78
posting, 98
public Web service, 78
sending to specific clients, 98
subsystem, 78
time stamping, 98
media discovery subsystem, 14
notificationWS Web service
delivering listings, 14
Message Delivery and Heartbeat Protocol,
100
messages
sending to clients, 14
metadata
generating VOD, 14
NTP server, 122
architecture, 122
categories, 122
hierarchical, 122
peer-to-peer, 122
star, 122
offer management Web service, 14, 140
one-time recordings, 104
RAM servers
VOD, 48
operations support systems See OSS, 14
RDP
operations support systems See OSS, 86,
128
assigning new sessions, 60
OSS
session pool, 60
posting notifications, 98
serving sessions, 60
session requests, 60
OSS (operations support systems), 14, 86,
128
Web services, 14
RDP (Remote Desktop Protocol), 59
RDP application
client support, 147
OSS Web services, 86, 128
RDP application launcher, 61
package management Web service, 14,
140
RDP application subsystem, 14, 59
components, 59
SMS Web service, 86
diagram, 59
packages
RDP applications, 8, 12
creating, 86
perimeter network, 68
blocking dialog boxes, 61
PIP
channel maps, 75
integrating video content, 61
delivering, 14
PPPoE, 148
launching, 59, 61
PPV management Web service, 14, 133
lifetime, 61
principal management Web service, 14,
141
multiple language support, 61
SMS Web service, 86
process flow
Program Activity screen
using to allocate streams, 151
program guide
channel map, 75
public key
client, 148
purchase Web service
SMS Web service, 86
QoS system integration
integrating, 58
rendering UIs, 61
running, 14
running remotely, 59
stopping, 61
RDP sessions
connecting to, 64
managing on each Terminal Server,
66
RDP virtual channels, 61
Real-Time Protocol See RTP, 14
recording schedules
linked to services, 104
recordings
scheduling DVR, 14
recurring recordings, 104
redirection
bootstrap, 96
regional VOD clusters, 43
self-provisioning application
integrating with the bootstrap Web
service, 82
reliable UDP, 29
server authentication timing, 122
remote control
server capacity
client, 149
expanding, 89
Remote Desktop Protocol See RDP, 59
server clock, 122
remote recording Web service, 134
server session keys, 109
replicating
serverEventLogDataWS
branch database, 89
replication of VOD assets, 50
server-facing Web services, 89, 92
reporting store Web service, 141
service collections, 75
resource management Web service
service discovery Web service, 80
SMS Web service, 86
retry strategy
rights management Web service
SMS Web service, 86
routing table
for Web service router, 68
RTP (Real-Time Protocol), 14
scalability, 89
live TV subsystem, 39
scaling up, 89
search criteria, 14
search public Web service, 110
search subsystem, 14, 110
SearchWS Web service
securing RDP sessions, 65
security, 109
VOD, 57
security zones
distributing subsystems across, 14
service group database, 91
replicating branch database, 89
storing client messages for delivery,
98
service group SMS Web service, 94
service group subsystem, 89
service groups, 89
adding, 91
assigning accounts to, 95
default, 89
managing, 89
specifying default, 89
Web services, 92
service information
change notifications, 98
database, 80
subsystem, 80
service information subsystem See SI, 14
service interruptions
preventing, 89
service offerings, 86
service tiers
defining through BSS and OSS Web
services, 86
SI
servicegroupSMSWS Web service
database tables, 91
SI subsystem, 14, 80
service-to-DServer map Web service, 29
sink
session key authority database, 109
client diagnostic event, 112
session key authority subsystem, 109
debug, 112
session key authority Web service, 109
event log, 112
session keys
SNMP, 112
client, 148
SQL, 112
storing, 109
trace, 112
session management
SMS
VOD, 54
architecture, 86
sessionKeyAuthority
database tables, 91
database tables, 91
SMS (subscriber management subsystem),
14, 86
sessionKeyAuthority_KeyGenerator
SMS database
accessing, 86
smsPublic Web service
SessionKeyAuthorityWS, 109
sessionKeyAuthorityWS Web service
SNMP sink, 112
software
set-top boxes
upgrading client software, 120
households with more than one settop box, 150
software components
recording schedules, 104
remote control, 149
logical architecture, 8, 12
upgrading, 150
SQL communications, 68
upgrading software, 120
SQL sink, 112
with and without hard disks, 151
startup sequence
SGepgWS Web service
IPTV Edition clients, 98
streams, 151
SGPrivateSessionKeyAuthorityWS Web
service
allocated in multiple-client
environment, 105
encoding live TV, 14
SGTraceLog Web service
number of shows to record at one
time, 105
distributing across multiple security
zones, 14
sharing between clients, 150
DVR scheduler, 14, 104
subscriber activity log, 112
Electronic Program Guide, 14
subscriber database, 86
live TV delivery, 14
subscriber entitlements, 14
logging, 14
subscriber groups
media discovery, 14
assigning channel maps, 131
notification, 14
subscriber management, 86
RDP application, 14
subscriber management subsystem See
SMS, 14, 86
search, 14
subscriberActivityLogDataWS Web
service
service information, 14
subscribers
accommodating new, 89
billing information, 86
credit limits, 86
device information, 86
package and service entitlements, 86
subsystem, 14
Asset Store, 70
EPG, 72
live TV, 21
live TV acquisition, 21, 25
service group, 89
SMS, 14
user store, 14
VOD acquisition, 14
VOD delivery, 14
Sync Server, 120
URL, 120
sync Windows service, 85
system clock
NTP server, 122
system upgrades
preventing service interruptions
during, 89
Terminal Server
live TV delivery, 21, 29
failover, 67
media discovery, 78
load-balancing, 67
search, 110
scaling, 67
service information, 80
SI, 80
user store, 107
VOD, 41
subsystems
Terminal Server controller database, 63
storing status, 60
Terminal Server controller private Web
service, 63
asset store, 14
Terminal Server controller public Web
service, 63
branch management, 91, 95
Terminal Server session starter, 61
client management, 14, 120
Terminal Server sessions
starting, 61
tickets, 109
upgrading clients, 150
time stamps
upgrading software
notifications, 98
client, 120
timestamps, 122
URL management Web service, 136
to IPTV Edition clients, 14
user interface framework
trace logs, 112
See UI framework, 144
trace sink, 112
user store
tracking Terminal Server sessions, 65
database tables, 91
trick streams
user store private Web service, 107
VOD, 52
user store public Web service, 107
TServer Windows service, 60
user store subsystem, 14, 107
configuration file, 60
diagram, 107
starting new sessions, 61
userstorePublicWS, 107
timeout, 60
userstorePublicWS Web service
TServer.xml file, 60
TServerController Web service
userstoreServerWS, 107
video
TServerProxy COM+ service, 63
playback control in RDP applications,
61
tsMonitorPublic Web service
video content
integrating in RDP applications, 61
TV Services Management tool, 14
virtual directories
multiple and simultaneous
interactions, 125
delivering VOD streams over HTTP,
14
overview, 125
VOD, 8, 12
UDP, 29
access rights, 57
UDP/IP
adaptive file copy described, 51
notifications delivery, 98
UI framework, 144
asset security, 57
UI notification Web service, 14, 98, 134
channel maps, 75
unicast
delivering streams to live TV delivery
subsystems, 14
upgrade Web service, 120
Upgrade Web service
upgrading client software, 14, 82
DRM, 57
Macrovision, 57
regional cluster distributions, 43
VOD acquisition subsystem, 14
VOD asset metadata, 51
VOD asset replication, 50
VOD assets
deploying, 14, 136
functional flow for, 41
importing, 14, 136
VOD backend management Web service,
136
VOD branch management Web service,
136
VOD cluster
about, 54
VOD components
description of, 46
VOD delivery subsystem, 14
VOD end-to-end process
description of, 41
VOD import
about, 53
VOD management Web service, 14
VOD media servers, 48
VOD metadata
generating, 14
VOD services
acquiring and delivering, 14
VOD session management
described, 54
VOD subsystem
described, 41
VOD trick streams
generating, 52
vodBranchWS
vodCatalogPrivateWS Web service
vodCatalogWS Web service
vodControllerWS
vodMapServerWS Web service
vodSGBranchWS Web service
vserver XML file, 49
Web service
Asset Store, 70
DServer controller, 29
live configuration state, 29
media discovery private, 78
media discovery public, 78
search public, 110
service discovery, 80
service-to-DServer map, 29
user store private, 107
user store public, 107
Web service router, 14, 68
Web services
authenticating requests, 68
backend blackout management, 129
billing record management, 14, 139
blackout management, 130
bootstrap, 14
branch management, 89, 131
BSS, 14
channel management, 14, 131
client notification, 98
client-facing, 14, 89
client-facing in service groups, 92
diagnostics notification, 14, 98, 132
EPG, 133
grant management, 14, 139
live backend management, 14, 133
notification controller, 98
upgrade, 120
offer management, 14, 140
URL management, 136
OSS, 14
VOD backend management, 14, 136
package management, 14, 140
VOD branch management, 14, 136
PPV management, 14, 133
Web service router, 14
principal management, 14, 141
Windows applications, 63
remote recording, 134
Windows Server Terminal Services, 60
reporting store, 141
Windows XML Media Center eHome
shell, 61
server-facing, 89
Windows® services
server-facing in service groups, 92
server-facing in the branch, 97
DVR schedule updater, 104
service group SMS, 94
notification delivery, 98
Terminal Server controller private, 63
Terminal Server controller public, 63
WSR
see Web service router, 68
UI notification, 14, 98, 134
Click below to find more
Mipaper at www.lcis.com.tw
Mipaper at www.lcis.com.tw

Architecture of IPTV Edition

Transcription

Similar documents

Shaw Direct Satellite TV

Khalil Abd El

Age of Empires III Age of Empires III

Case Study: OSI Restaurant Partners

AppRiver - Franchise services Inc.

JUN 2006 issue of TOE - Channel Islands PC Users Group

M2M Ecosystem Development

Towards a more cost-effective Recruitment solution

Opportunities to solve the mass-hiring challenge

TouchSmart tm2-2050us Notebook PC

Subscription Order Form