Architecture of IPTV Edition

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) Microsoft Confidential

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:

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 3

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

4 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 5

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

6 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 7

Architecture of IPTV Edition

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 acquisition subsystem.

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)

8 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 9

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)

10 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 11

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.

See Also

High-Level Architecture (p. 014)

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:

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 25

• 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.

26 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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 Delivery Subsystem (p. 029)

Live TV Acquisition Subsystem Software Components and Data Flow

The following diagram shows the software components of the live TV acquisition subsystem. request boundary key key boundary boundary keys

Acquisition Group Controller

boundary boundary keys service keys request config info request LiveBackend boundary keys service configinfo/

service assignment database service config info/ service assignments

RTP transport streams acquisition acquisition Windows Acquisition Windows service Serverservice Retry packets encoder NIC Retry requests

Live TV Acquisition Subsystem

The following table describes the software components of the live TV acquisition subsystem.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 27

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 streams and keys to IPTV Edition clients. A single Acquisition controller Web Group Controller can control multiple Acquisition Servers. The service) 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 and the video reencoded at a lower resolution. The Acquisition Acquisition Server can also repackage or play back pre-encoded streams. Windows service) 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).

28 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 29

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 I- frame, 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

30 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 31

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.

32 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 33

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.

34 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

information configuration configuration usage statistics usage

live service-to- configuration service-to-DServer DServer Controller DServer map state Web map request Web service (HTTP) service

service usage config service assignments/ stats info assignments config info

config info config BranchDB database usage statistics service assignments/ config info info request config service assignments/

RTP Streams RTP Streams (UDP multicast) (UDP unicast) DServer

retry packets command and control (unicast) (UDP)

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 35

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

Live TV Subsystem (p. 021)

Live TV Acquisition Subsystem (p. 025)

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

36 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 37

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.

38 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 39

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

Live TV Subsystem (p. 021)

Live TV Acquisition Subsystem (p. 025)

Live TV Delivery Subsystem (p. 029)

40 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 41

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 branch- specific parameters.

6) Subscribers purchase and then view a VOD asset.

42 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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).

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 43

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.

44 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 45

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).

46 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 47

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:

48 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

• 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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 49

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%.

50 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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:

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 51

• 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.

52 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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).

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 53

• 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 fast- forward 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.

54 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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).

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 55

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-

56 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

OSS Web Services (p. 128)

BSS Web Services (p. 138)

High-Level Architecture (p. 014)

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 57

• 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.

58 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 59

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

60 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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-

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 61

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, en- US). 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.

62 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 63

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.

64 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 65

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 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

66 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 67

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 client- facing 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 XML element. The following diagram shows how the WSR fits into a typical deployment.

68 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 69

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

70 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

Component Description information about deployed VOD assets.

See Also

Video on Demand Subsystem (p. 041)

RDP Application Service Subsystem (p. 059)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 71

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-to- end.

1) An EPG listings provider (of the service provider’s choosing) creates a GLF- compliant listings data file.

72 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 73

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.

74 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 75

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

Media Discovery Subsystem (p. 078)

76 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

DVR Scheduler Subsystem (p. 104)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 77

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

78 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 79

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.

80 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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)

Live TV Subsystem (p. 021)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 81

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

82 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 83

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.

84 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 85

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.

86 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 87

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.

88 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 89

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

90 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Branch Management Subsystem (p. 095)

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)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 91

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

92 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

• userstorePublicWS • vodCatalogWS • vodMapServerWS

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 93

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.

94 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 95

• 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

Branch Management Subsystem (p. 095)

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

96 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

Web Services in the Branch

The following server-facing Web services are deployed in the branch: • BranchMgmtWS • clientEventLogDataWS • dserverController • epgWS • LiveBackendUpdate • sessionKeyAuthority_KeyGenerator • sessionKeyAuthorityWS • serverEventLogDataWS • vodBranchWS • vodControllerWS

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 97

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.

98 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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. Client- specific, 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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 99

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

100 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 101

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.

102 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 103

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.

104 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 105

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).

106 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 107

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

High-Level Architecture (p. 014)

108 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 109

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

110 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Media Discovery Subsystem (p. 078)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 111

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.

112 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 113

• 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.

114 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

• 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 low- level 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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 115

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.

116 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 117

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.

118 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

High-Level Architecture (p. 014)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 119

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,

120 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 121

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.

122 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 123

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.

124 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 125

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)

OSS Web Services (p. 128)

BSS Web Services (p. 138)

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

126 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 127

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

128 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 129

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.

130 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 131

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

Notification Subsystem (p. 098)

Logging Subsystem (p. 112)

132 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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 IPTV Edition software components.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 133

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.

134 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Notification Subsystem (p. 098)

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 135

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 other IPTV Edition software components.

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 other IPTV Edition software components.

136 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 137

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.

138 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

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 other IPTV Edition software components.

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 IPTV Edition software components.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 139

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 IPTV Edition software components.

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 IPTV Edition software components.

140 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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 other IPTV Edition software components.

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 141

• 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.

142 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 143

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.

144 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 145

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

146 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 147

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-to- point 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 (non- A/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.

148 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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.

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 149

• 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 full- screen 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

150 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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:

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 151

• 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 high- definition 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 set- top 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.

152 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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, accounts to service groups, 95 57 asymmetric server session keys account information, 89 distributing, 109 accounts generating, 109 assigning to service groups, 95 authenticating IPTV Edition clients, 14, acquisition controller Web service, 25 82 acquisition server authentication failover, 133 client, 148 acquisition Windows service, 25 AV timing, 122 Acquistion Server, 25 backend blackout management Web acquistionController, 25 service, 129 adaptive allocation bandwidth about, 50 VOD, 51 application tier, 68 billing events, 86 architecture storing, 14 client, 143 billing record management Web service, 14, 139 logical, 8, 12 billing Web service asset files SMS Web service, 86 VOD, 51 blackout management Web service, 130 asset security, 57 bootstrap asset store client, 148 database tables, 91 bootstrap Web service, 14, 82 Asset Store in service groups, 92 database, 70

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 153

bootstrapping, 96 bootstrap, 148 branch command and control, 146 server-facing Web services, 97 data exchange, 145 branch database, 91 DVR, 147 replicating, 89 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 session keys, 148 BSS startup sequence, 98 Web services, 14 UI framework, 144 BSS (business support systems), 14, 86, upgrading, 150 138 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 business support systems See BSS, 14 client holes, 29 business support systems See BSS, 86 client management subsystem, 14 certificates client messages, 98 protecting with asymmetric delivering on schedule, 98 cryptography, 109 client notification Web service, 98 CFZ client RDP sessions, 147 see client-facing zone, 68 client rights Web service channel changes SMS Web service, 86 logging, 14 client state channel management Web service, 14, 131 stored in service group database, 98 channel maps, 75 clientEdgeMapWS, 29 assigning, 75 clientEdgeMapWS Web service default, 75 in service groups, 92 managing, 131 clientEventLogDataWS client Web service in the branch, 97 A/V support, 146 client-facing Web services, 89, 92 architecture, 143 client-facing zone, 68 authentication, 148 clientLoggerWS Web service

154 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

in service groups, 92 databases clients branch, 91, 96 authenticating, 14, 82 replicating branch tables, 91 master (in multiple client service group, 91 environment), 104 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, configuration 98, 132 acquiring data, 14 diagram conflicts live TV acquisition subsystem, 25 detected by DVR scheduler live TV delivery subsystem, 29 subsystem, 104 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 client, 145 environment, 105 data migration, 89 discovery Windows® service, 84 database distributing VOD assets Asset Store, 70 about, 41 event log, 112 Distribution Server See DServer, 29 live acquisition service, 25 DRM live configuration state, 29 VOD, 57 replicating to service group database, DRM keys for VOD, 54 95 DServer, 29 subscriber activity log, 112 DServer controller Web service, 29 database migration tool, 89 DServer Windows service, 29

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 155

dserverController, 29 EPG listings Web service in the branch, 97 client update notification, 72 DServers data flow diagram, 72 deploying live TV delivery file import, 72 subsystems, 14 EPG subsystem, 72 dserverService, 29 EPG Web service, 133 DVR, 8, 12 epgWS client, 147 Web service in the branch, 97 database tables, 91 EPOC system integration, 58 on diskless set-top box, 151 EQoS system integration, 58 DVR (digital video recorder), 14 event log, 112 scheduling, 14 event sink, 112 DVR schedule updater Windows service, events 104 logging, 112 DVR scheduler subsystem, 14, 104 Extensibility Framework, 14 illustration, 105 external login server Web service, 82 DVR See Recorded TV, 147 external purchase offer cycle, 58 dvrRemote Web service external quality of service in service groups, 92 integrating, 58 dvrScheduleUpdateService Web service failover in service groups, 92 acquisition server, 133 dvrV2WS Web service failover scenario in service groups, 92 live TV acquisition subsystem, 25 eHome live TV delivery subsystem, 29 see Windows XML Media Center eHome shell, 61 firewalls Electronic Program Guide See EPG, 14 keeping NAT ports open, 98 Electronic Program Guide subsystem, 14 framework ELS subscriber UI, 144 see external login server Web service, generating VOD trick streams 82 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

156 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

high quality trick streams, 52 update notification, 72 high-level architecture, 14 live acquisition group management Web ICC, 29 service, 25 ICC with IGMP, 29 live acquisition service database, 25 importing VOD assets live backend management Web service, 14, 133 described, 53 live config and cluster assignment index file, 104 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 channel maps, 75 IPTV Edition clients EPG data flow diagram, 72 authenticating, 82 live TV acquisition subsystem, 14, 21, 25 upgrading software, 82 failover scenario, 25 key process flow, 25 change notifications, 98 scalability, 39 key generator Windows® service, 109 software components, 25 key management Web service live TV delivery subsystem, 14, 21, 29 SMS Web service, 86 failover scenario, 29 key manager Windows® service, 86 process flow, 29 language names reliable UDP, 29 RFC 1766, 61 retry strategy, 29 languages scalability, 39 supporting multiple in RDP software components, 34 applications, 61 live TV services listings acquiring and delivering, 14 acquiring, 14 live TV subsystem GLF format, 14 scalability, 39 listings data liveAcquisitionServiceDB, 25 client update notification, 72 liveAcquisitionServiceManagementWS, data flow diagram, 72 25 file import, 72 LiveBackendUpdate listings data share, 14 Web service in the branch, 97 listings file liveConfigStateDB, 29 import, 72 liveConfigStateWS, 29

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 157

load-balancing, 89 storing for RDP applications and logging VOD assets, 14 configuring, 112 VOD assets, 51 events, 112 migration sinks, 112 data, 89 logging subsystem, 14 MOM console, 112 logs multicast collecting service, 14 delivering streams to live TV delivery subsystems, 14 collecting subscriber activity, 14 multiple-client households, 150 Macrovision multi-view applications, 144 VOD, 57 NAT gateway traversal, 98 managing RDP sessions on each Terminal Server, 66 notification mdws Web service database tables, 91 in service groups, 92 notification controller Web service, 98 mdWSPrivate Web service notification delivery Windows service, 98 in service groups, 92 listening on port 43962, 98 Media Center notification subsystem, 14, 98 application support, 61 notificationController Web service object model support, 61 in service groups, 92 media descriptions, 14 notifications managing requests for, 14 broadcasting to all clients, 98 media descriptors delivery over UDP/IP, 98 identifying services, 86 heartbeat protocol, 98 media discovery 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 in service groups, 92 Message Delivery and Heartbeat Protocol, NTP server, 122 100 architecture, 122 messages categories, 122 sending to clients, 14 hierarchical, 122 metadata peer-to-peer, 122 generating VOD, 14 star, 122

158 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

offer management Web service, 14, 140 RAM servers one-time recordings, 104 VOD, 48 operations support systems See OSS, 14 RDP operations support systems See OSS, 86, assigning new sessions, 60 128 serving sessions, 60 OSS session pool, 60 posting notifications, 98 session requests, 60 OSS (operations support systems), 14, 86, RDP (Remote Desktop Protocol), 59 128 RDP application Web services, 14 client support, 147 OSS Web services, 86, 128 RDP application launcher, 61 package management Web service, 14, 140 RDP application subsystem, 14, 59 SMS Web service, 86 components, 59 packages diagram, 59 creating, 86 RDP applications, 8, 12 perimeter network, 68 blocking dialog boxes, 61 PIP channel maps, 75 delivering, 14 integrating video content, 61 PPPoE, 148 launching, 59, 61 PPV management Web service, 14, 133 lifetime, 61 principal management Web service, 14, multiple language support, 61 141 rendering UIs, 61 SMS Web service, 86 running, 14 process flow running remotely, 59 live TV acquisition subsystem, 25 stopping, 61 live TV delivery subsystem, 29 RDP sessions Program Activity screen connecting to, 64 using to allocate streams, 151 managing on each Terminal Server, program guide 66 channel map, 75 RDP virtual channels, 61 public key Real-Time Protocol See RTP, 14 client, 148 recording schedules purchase Web service linked to services, 104 SMS Web service, 86 recordings QoS system integration scheduling DVR, 14 integrating, 58 recurring recordings, 104

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 159

redirection self-provisioning application bootstrap, 96 integrating with the bootstrap Web regional VOD clusters, 43 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 Web service in the branch, 97 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 service group database, 91 retry strategy replicating branch database, 89 live TV delivery subsystem, 29 storing client messages for delivery, 98 rights management Web service service group SMS Web service, 94 SMS Web service, 86 service group subsystem, 89 routing table service groups, 89 for Web service router, 68 adding, 91 RTP (Real-Time Protocol), 14 assigning accounts to, 95 scalability, 89 default, 89 live TV subsystem, 39 managing, 89 scaling up, 89 specifying default, 89 search criteria, 14 Web services, 92 search public Web service, 110 service information search subsystem, 14, 110 change notifications, 98 SearchWS Web service database, 80 in service groups, 92 subsystem, 80 securing RDP sessions, 65 service information subsystem See SI, 14 security, 109 service interruptions client authentication, 57 preventing, 89 VOD, 57 service offerings, 86 security zones service tiers distributing subsystems across, 14

160 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

defining through BSS and OSS Web in service groups, 92 services, 86 SI servicegroupSMSWS Web service database tables, 91 in service groups, 92 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), sessionKeyAuthority_KeyGenerator 14, 86 Web service in the branch, 97 SMS database sessionKeyAuthorityWS accessing, 86 Web service in the branch, 97 smsPublic Web service SessionKeyAuthorityWS, 109 in service groups, 92 sessionKeyAuthorityWS Web service SNMP sink, 112 in service groups, 92 software set-top boxes upgrading client software, 120 households with more than one set- software components top box, 150 live TV acquisition subsystem, 25 recording schedules, 104 live TV delivery subsystem, 34 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 in service groups, 92 streams, 151 SGPrivateSessionKeyAuthorityWS Web allocated in multiple-client service environment, 105 in service groups, 92 encoding live TV, 14 SGTraceLog Web service

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 161

number of shows to record at one distributing across multiple security time, 105 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 search, 14 SMS, 14, 86 service group, 89 subscriberActivityLogDataWS Web service information, 14 service SMS, 14 in service groups, 92 user store, 14 subscribers VOD acquisition, 14 accommodating new, 89 VOD delivery, 14 billing information, 86 Sync Server, 120 credit limits, 86 URL, 120 device information, 86 sync Windows service, 85 package and service entitlements, 86 system clock subsystem, 14 NTP server, 122 Asset Store, 70 system upgrades EPG, 72 preventing service interruptions live TV, 21 during, 89 live TV acquisition, 21, 25 Terminal Server live TV delivery, 21, 29 failover, 67 media discovery, 78 load-balancing, 67 search, 110 scaling, 67 service information, 80 Terminal Server controller database, 63 SI, 80 storing status, 60 user store, 107 Terminal Server controller private Web VOD, 41 service, 63 subsystems Terminal Server controller public Web asset store, 14 service, 63 branch management, 91, 95 Terminal Server session starter, 61 client management, 14, 120 Terminal Server sessions starting, 61

162 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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 in service groups, 92 TServerController Web service userstoreServerWS, 107 in service groups, 92 video TServerProxy COM+ service, 63 playback control in RDP applications, tsMonitorPublic Web service 61 in service groups, 92 video content TV Services Management tool, 14 integrating in RDP applications, 61 multiple and simultaneous virtual directories interactions, 125 delivering VOD streams over HTTP, overview, 125 14 UDP, 29 VOD, 8, 12 UDP/IP access rights, 57 notifications delivery, 98 adaptive file copy described, 51 UI framework, 144 asset security, 57 UI notification Web service, 14, 98, 134 channel maps, 75 unicast client authentication, 57 delivering streams to live TV delivery DRM, 57 subsystems, 14 Macrovision, 57 upgrade Web service, 120 regional cluster distributions, 43 Upgrade Web service VOD acquisition subsystem, 14 in service groups, 92 VOD asset metadata, 51 upgrading client software, 14, 82 VOD asset replication, 50

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 163

VOD assets Web service in the branch, 97 deploying, 14, 136 vodMapServerWS Web service functional flow for, 41 in service groups, 92 importing, 14, 136 vodSGBranchWS Web service VOD backend management Web service, in service groups, 92 136 vserver XML file, 49 VOD branch management Web service, Web service 136 Asset Store, 70 VOD cluster DServer controller, 29 about, 54 live configuration state, 29 VOD components media discovery private, 78 description of, 46 media discovery public, 78 VOD delivery subsystem, 14 search public, 110 VOD end-to-end process service discovery, 80 description of, 41 service-to-DServer map, 29 VOD import user store private, 107 about, 53 user store public, 107 VOD management Web service, 14 Web service router, 14, 68 VOD media servers, 48 Web services VOD metadata authenticating requests, 68 generating, 14 backend blackout management, 129 VOD services billing record management, 14, 139 acquiring and delivering, 14 blackout management, 130 VOD session management bootstrap, 14 described, 54 branch management, 89, 131 VOD subsystem BSS, 14 described, 41 channel management, 14, 131 VOD trick streams client notification, 98 generating, 52 client-facing, 14, 89 vodBranchWS client-facing in service groups, 92 Web service in the branch, 97 diagnostics notification, 14, 98, 132 vodCatalogPrivateWS Web service EPG, 133 in service groups, 92 grant management, 14, 139 vodCatalogWS Web service in service groups, 92 in service groups, 92 live backend management, 14, 133 vodControllerWS

164 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

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 server-facing, 89 shell, 61 ® server-facing in service groups, 92 Windows services server-facing in the branch, 97 DVR schedule updater, 104 service group SMS, 94 notification delivery, 98 Terminal Server controller private, 63 WSR Terminal Server controller public, 63 see Web service router, 68 UI notification, 14, 98, 134

Microsoft Confidential Architecture of IPTV Edition (2006-09-15-1200) 165

166 Architecture of IPTV Edition (2006-09-15-1200) Microsoft Confidential

Click below to find more

Mipaper at www.lcis.com.tw