scribd.vpdfs.com architecture-of-microsoft-mediaroom

Architecture of Microsoft Mediaroom Microsoft Mediaroom Server 1.1 SP3.2 Product Documentation server11sp32-27feb09-2009-0227-1757 Microsoft Mediaroom was formerly known as Microsoft TV IPTV Edition. Titles, names, and logos have been updated to reflect the new product name, but some document content may refer to the previous product name. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 1 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2009 Microsoft Corporation. All rights reserved. Microsoft, Mediaroom, the Mediaroom logo, and/or other Microsoft products referenced herein are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 2 Documentation Feedback Microsoft welcomes your feedback on this documentation. Microsoft Mediaroom Customers and Partners: You can provide feedback to any member of your Microsoft Customer Account Team. Please use the procedure agreed on with your account team, such as filing an SR. Microsoft personnel: If appropriate, create a doc bug and, if needed, a KB Article, as described in Field_Doc_Bug_Process.doc, which you can obtain by looking in Process and Governance > Technical Publications Process Docs on the Microsoft Mediaroom (tv2) intranet site or by sending an email to mrdocbug. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 3 Contents Architecture of Microsoft Mediaroom...............................................................10 Using Architecture of Microsoft Mediaroom.......................................................................... 11 Audience........................................................................................................................... 11 Documentation Map ......................................................................................................... 11 High-Level Architecture ......................................................................................................... 13 Live TV Subsystem................................................................................................................. 21 Functional Flow from Capture Through Delivery............................................................ 21 Live TV Subsystem Software Components and Data Flow ............................................. 24 Live TV Acquisition Subsystem ...................................................................................... 25 Encoding.................................................................................................................... 25 Supported Data Streams ............................................................................................ 26 Failover Scenario....................................................................................................... 27 Live TV Acquisition Subsystem Software Components and Data Flow................... 27 Live TV Delivery Subsystem ........................................................................................... 31 Instant Channel Change............................................................................................. 32 ICC with Multicast .................................................................................................... 33 Reliable Live TV over RTP/UDP.............................................................................. 34 Failover Scenario....................................................................................................... 35 Service Replication.................................................................................................... 36 Live TV Delivery Subsystem Software Components and Data Flow ....................... 36 DServer/Client Command and Control ..................................................................... 38 DServer Machine Error Codes .................................................................................. 39 Command and Control Data Exchange ..................................................................... 39 Multiple Identical Live TV Delivery Subsystems ..................................................... 40 Scalability......................................................................................................................... 42 Video on Demand Subsystem ................................................................................................. 44 Functional Flow for Non-Distributed VOD Clusters ....................................................... 44 Functional Flow for Regionally Distributed VOD Clusters ............................................. 47 VOD Subsystem Software Components and Data Flow .................................................. 51 VOD Servers .................................................................................................................... 54 Multicast Asset Distribution............................................................................................. 55 Status Updates and Failover ...................................................................................... 57 VOD Clusters and Load Balancing .................................................................................. 58 Adaptive Asset Allocation......................................................................................... 59 Adaptive File Copy and Distributed Ingest ............................................................... 61 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 4 VOD Assets and Content Aggregation ............................................................................. 62 VOD Trick Streams .......................................................................................................... 62 VOD Acquisition Subsystem............................................................................................ 63 VOD Delivery Subsystem ................................................................................................ 64 Decrypting DRM Keys .............................................................................................. 65 VOD Session Management and Load Balancing....................................................... 66 Life Cycle of a VOD Session..................................................................................... 66 Packet Loss and Retry................................................................................................ 67 Service Failover ......................................................................................................... 67 Large Asset Playback................................................................................................. 68 VOD Asset Security ......................................................................................................... 68 Integrating a Branch with an EQoS Interface ................................................................... 69 Integrating a Branch with an EPOC System..................................................................... 70 Live Anytime Subsystem......................................................................................................... 71 Live2VOD Recording Server ........................................................................................... 72 Capturing and Recording Assets................................................................................ 72 Live2VOD Controller Machine ........................................................................................ 73 Live Anytime Recording Schedules .......................................................................... 73 Live Anytime Asset Deployment............................................................................... 73 Live Anytime Roles.......................................................................................................... 73 L2VDB....................................................................................................................... 74 l2vRecServer.............................................................................................................. 74 l2vControllerWS ........................................................................................................ 74 ossLiveToVOD .......................................................................................................... 74 smtLive2VOD............................................................................................................ 74 timeshiftMapServerWS.............................................................................................. 75 RDP Application Subsystem ................................................................................................... 76 RDP Application Subsystem Software Components and Data Flow................................ 76 Windows Server Terminal Services........................................................................... 79 TServer Windows Service ......................................................................................... 79 Terminal Server Session Starter................................................................................. 79 RDP Application Launcher........................................................................................ 80 TServerProxy COM+ Service.................................................................................... 81 Terminal Server Controller Private Web Service ...................................................... 81 Terminal Server Controller Public Web Service ....................................................... 81 Terminal Server Controller Database ........................................................................ 82 Windows Applications............................................................................................... 82 Connecting to RDP Sessions ............................................................................................ 82 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 5 Tracking Terminal Server Sessions.................................................................................. 83 Securing RDP Sessions .................................................................................................... 84 Managing RDP Sessions on Each Terminal Server ......................................................... 84 Scaling, Load Balancing, and Failover............................................................................. 85 Web Service Router ................................................................................................................ 86 Asset Store Subsystem ............................................................................................................ 88 Listings Subsystem.................................................................................................................. 90 Listings Distribution......................................................................................................... 90 Listings File Format ......................................................................................................... 93 Channel Maps................................................................................................................... 93 Media Discovery Subsystem................................................................................................... 95 Service Information Subsystem .............................................................................................. 98 Service Information Subsystem Software Components and Data Flow........................... 98 Client Startup Services.......................................................................................................... 101 Bootstrap Web Service................................................................................................... 101 Interaction of the Bootstrap Web Service with Other Microsoft Mediaroom Components............................................................................................................. 101 Sync Discovery Service Windows Service .................................................................... 103 Disaster Recovery Application ................................................................................ 103 UpgradeWS Web Service............................................................................................... 103 ClientUpgradeFiles role ................................................................................................. 104 Subscriber Management Subsystem...................................................................................... 105 Service Offerings............................................................................................................ 105 Default Entitlements....................................................................................................... 105 Subscriber Management Information ............................................................................. 105 Billing Events................................................................................................................. 106 SMS Software Components and Data Flow ................................................................... 106 Service Group Subsystem ..................................................................................................... 109 Scalability and Load Balancing...................................................................................... 109 Microsoft Mediaroom Software Upgrades ..................................................................... 109 Service Group Subsystem Software Components and Data Flow.................................. 109 Service Group Database ................................................................................................. 111 Web Services in Service Groups .................................................................................... 111 Service Group SMS Web Service .................................................................................. 112 Branch Management Subsystem ........................................................................................... 113 Bootstrap and Redirection .............................................................................................. 114 Branch Database Tables ................................................................................................. 114 Web Services in the Branch ........................................................................................... 115 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 6 Notification Subsystem.......................................................................................................... 116 Notification Subsystem Software Components and Data Flow...................................... 116 Message Handlers........................................................................................................... 119 Message Delivery and Heartbeat Protocol...................................................................... 119 Client Startup Communications with the Notification Subsystem ................................. 121 High Priority Notification Subsystem............................................................................. 122 Introduction.............................................................................................................. 123 Architecture ............................................................................................................. 123 Branch Routing Cache ...................................................................................... 123 Multicast to NDS in the Service Group ............................................................ 123 NTP-based Clock Synchronization ................................................................... 123 Redundant Message Handling at the Client ...................................................... 124 DVR Scheduler Subsystem ................................................................................................... 125 DVR Scheduling in a Multiple Set-Top Box Environment ............................................ 126 DVR Scheduler Subsystem Software Components and Data Flow................................ 126 User Store Subsystem............................................................................................................ 128 User Store Subsystem Software Components and Data Flow ........................................ 128 Session Key Authority Subsystem ........................................................................................ 130 Search Subsystem.................................................................................................................. 132 Logging Subsystem ............................................................................................................... 135 Logging Subsystem Software Components and Data Flow............................................ 139 Client Management Subsystem ............................................................................................. 143 Client Management Subsystem Software Components and Data Flow.......................... 143 NTP Server ............................................................................................................................ 148 Maintaining A/V Timing ................................................................................................ 149 Client Authentication and Rights Interpretation ............................................................. 150 Server Authentication ..................................................................................................... 150 NTP Server Categories ................................................................................................... 150 NTP Architecture............................................................................................................ 150 TV Services Management Tool............................................................................................. 151 TV Services Management Tool Pages and Associated Tasks ........................................ 151 Multiple and Simultaneous Interactions with TV Services Management Tool .............. 153 OSS Web Services................................................................................................................. 155 Backend Blackout Management Web Service................................................................ 157 Blackout Management Web Service............................................................................... 157 Branch Management Web Service ................................................................................. 158 Channel Management Web Service................................................................................ 158 Content Distribution Web Service .................................................................................. 159 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 7 Client Configuration Web Service ................................................................................. 159 Diagnostics Notification Web Service ........................................................................... 159 Emergency Alert System Web Service .......................................................................... 161 EPG Web Service........................................................................................................... 161 Fingerprint Web Service ................................................................................................ 161 High-Priority Notification Web Service......................................................................... 161 Live Anytime Web Service ............................................................................................ 162 Live Deployment Web Service ...................................................................................... 162 PPV Management Web Service ..................................................................................... 163 Remote Recording Web Service .................................................................................... 163 Restart Anytime Web Service ........................................................................................ 164 Service Substitution Web Service .................................................................................. 164 UI Notification Web Service .......................................................................................... 164 URL Management Web Service..................................................................................... 165 VOD Backend Management Web Service ..................................................................... 166 VOD Branch Management Web Service........................................................................ 166 BSS Web Services................................................................................................................. 168 Billing Record Management Web Service ..................................................................... 169 Grant Management Web Service.................................................................................... 169 Offer Management Web Service .................................................................................... 170 Package Management Web Service ............................................................................... 170 Principal Management Web Service .............................................................................. 171 Reporting Store Web Service ......................................................................................... 171 Microsoft Mediaroom Client................................................................................................. 173 User Interface Framework.............................................................................................. 174 Data Exchange................................................................................................................ 174 Audio/Video Service Support ........................................................................................ 176 DVR Engine, Storage, and Management........................................................................ 177 RDP Application Support............................................................................................... 177 Bootstrap and Client Authentication .............................................................................. 178 Client Remote Control.................................................................................................... 179 Client Upgrade ............................................................................................................... 180 Multiple Client Households............................................................................................ 181 Client Streams ......................................................................................................... 182 Set-Top Boxes with and Without Hard Disks ......................................................... 183 Stream Management.............................................................................................................. 184 Stream Definitions.......................................................................................................... 185 WAN Streams.......................................................................................................... 186 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 8 Ingress Streams ........................................................................................................ 186 Egress Streams ......................................................................................................... 187 Stream Contention .......................................................................................................... 190 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 9 Architecture of Microsoft Mediaroom This document defines the overall logical architecture of Microsoft® Mediaroom. It emphasizes key software components and their interfaces and illustrates how they support Microsoft Mediaroom deployments. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 10 Using Architecture of Microsoft Mediaroom Microsoft® Mediaroom delivers 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 such as Remote Desktop Protocol (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 Microsoft Mediaroom software components interact with one another. It is assumed that you are already familiar with the features of Microsoft Mediaroom and need to understand how those features are implemented. For information about Microsoft Mediaroom features, see Product Overview (p. 007). Documentation Map The Microsoft Mediaroom software distribution includes technical documents that represent the state of the Microsoft Mediaroom system at the time of publication. The following table provides pointers to additional Microsoft Mediaroom information. For information about See Microsoft Mediaroom system features Product Overview (p. 007) Finding information in the Microsoft Mediaroom Server Deployment and Operations documentation set Using the Documentation (p. 005) Encoding video for delivery as VOD assets VOD Encoding Guide (Microsoft Mediaroom Common Reference documentation set) Creating metadata for VOD assets VOD Metadata Guide and Reference (p. 007) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 11 For information about See Configuring, monitoring, and maintaining Microsoft Mediaroom Operations Guide (p. 015) Customizing the client user interface Client Customization and Localization Guide (Microsoft Mediaroom Client documentation set) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 12 High-Level Architecture The following diagram illustrates the logical organization of software components in the Microsoft Mediaroom system. TV/VOD Delivery Subsystems TV Services Management Tool TV/VOD Acquisition Subsystems Live TV Unicast Streams (UDP) Live TV Multicast Streams (UDP) VOD/RTP Streams (HTTP) Asset Store Subsystem RDP Application Subsystem Keys (HTTP) RDP Sessions Get and Set Value Pair Data Events (HTTP) Bootstrap Web Service Boot Information EPG Subsystem DVR Scheduler Subsystem Notification Subsystem (Common to all subsystems) Recording Schedule Events (HTTP) Media Discovery Subsystem Media Desc Info Search Web Service Search Queries (HTTP) Client Mgmt Subsystem Software Updates Logging Subsystem Client Events (HTTP) Web Services Router Subscriber Management Subsystem Service Information Subsystem Session Key Authority Subsystem User Store Subsystem Microsoft Mediaroom Client OSS Web Services Listings Data Share BSS Web Services Business Support Subsystem (BSS) Operational Support Subsystem (OSS) Cookies (HTTP) Service Group Subsystem Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 13 VOD Backend Management Web Service Backend Blackout Mgmt Web Service Live Backend Management Web Service VOD Branch Management Web Service Live TV Acquisition Subsystem OSS Web Services Multicast Streams (UDP) Unicast Streams (UDP) Microsoft Mediaroom Client Live TV Delivery Subsystem Multicast Streams (UDP) VOD RTP Streams (HTTP) VOD Delivery Subsystem Web Services Router VOD Acquisition Subsystem Subscriber Managemen Subsystem Asset Store Subsystem VOD/Live TV Acquisition and Delivery Subsystems Operations Support Systems Diagnostics Notification Web Service UI Notification Web Services VOD Backend Management Web Service VOD Backend Management Web Service OSS Web Services Notification Subsystem VOD Acquisition Subsystem TV Services Management Tool Live Backend Management Web Service Backend Blackout Mgmt. Web Service Channel Management Web Service Media Discovery Subsystem Live TV Acquisition Subsystem Service Information Subsystem Subscriber Management Subsystem Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 14 VOD Branch Management Web Service PPV Management Web Service EPG Subsystem Asset Store Subsystem VOD Delivery Subsystem Business Support Systems Billing Record Management Web Service Grant Management Web Service Package Management Web Service Offer Management Web Service Principal Management Web Service BSS Web Services Subscriber Management Subsystem In a Microsoft Mediaroom system, live TV, video on demand (VOD), and network (RDP) application services are first acquired and then delivered to Microsoft Mediaroom set-top boxes (also referred to as "clients" and "devices" in this document). For example, Microsoft Mediaroom acquires live TV services, which can arrive in a variety of formats. Microsoft Mediaroom then processes the streams to provide full-screen and picture-in-picture (PIP) versions of the services in a uniform manner so that they can be delivered from backend sites to one or more branches using Real-Time Transport Protocol (RTP). Some Microsoft Mediaroom subsystems perform the acquisition and delivery functions directly, while others perform a supporting role so that subscribers can discover and select the services they want to view. For example, the live TV acquisition subsystem processes incoming live TV services. Similarly, the VOD acquisition subsystem imports VOD assets. In addition, the media discovery subsystem provides service descriptions that appear in program listings. Microsoft Mediaroom defines a set of application programming interfaces (APIs) through which its service providers can integrate their business support systems (BSS) and operations support systems (OSS) with Microsoft Mediaroom. To coordinate the management of services and service information, custom applications can use a set of OSS Web services that enable operators to manage the entire system across their networks. Microsoft Mediaroom includes a Web application called the TV Services Management tool that uses the OSS Web services and provides a user interface for managing Microsoft Mediaroom services. Service providers can integrate business support systems through a set of BSS Web services that provide APIs for managing subscriber accounts, set-top boxes and other devices, billing events, service packages, offers, and service entitlements. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 15 Many subsystems contain a set of components (typically Web services and databases) that can be distributed across multiple security zones to support each service provider’s security policies. Microsoft Mediaroom also provides a dedicated Web service router that brokers all communications between Microsoft Mediaroom clients and the client-facing Web services. The following table summarizes each Microsoft Mediaroom system software component. Component Description Live TV Acquisition Subsystem (p. Acquires live video services and generates fullscreen and PIP streams. Encodes streams with the Windows Media 9 Series Audio and Video codecs in VC-1 and H.264 formats for full-screen content and VC-1 format for PIP streams. Encrypts and encapsulates streams in RTP transport streams for unicast or multicast delivery to one or more live TV delivery subsystems. 025) Note If the incoming service does not require live capture, only the PIP streams are encoded with the Windows Media 9 Series Audio and Video codecs. Live TV Delivery Subsystem (p. 031) Receives live TV services from the live TV acquisition subsystem. Manages the delivery of audio/video (A/V) streams to Microsoft Mediaroom clients over IP unicast. Deployed on machines known as Distribution Servers (DServers). Live Anytime Subsystem (p. 071) Records live TV services from the live TV acquisition subsystem, converts them to video on demand (VOD) format, and deploys them to the VOD delivery subsystem. VOD Acquisition Subsystem (p. Creates video on demand (VOD) assets and generates media and VOD asset metadata files for deployment to one or more VOD delivery subsystems. 063) VOD Delivery Subsystem (p. 064) Deploys VOD assets that are available on a VOD acquisition subsystem. Includes a set of Media Store virtual directories that deliver the VOD streams to set-top boxes on request over HTTP. RDP Application Subsystem (p. Enables subscribers to run remote Web or Windows Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 16 Component Description 076) applications through Remote Desktop Protocol (RDP). Web Service Router (p. 086) Brokers all Web service communications (SOAP over HTTP) between Microsoft Mediaroom clients and client-facing Web services. Asset Store Subsystem (p. 088) Stores metadata for network (RDP) applications and VOD assets that subscribers can browse, run, and, if necessary, purchase. Listings Subsystem (p. 090) Acquires listings data from third-party listings services. Delivers listings to the media discovery subsystem, which delivers the listings to Microsoft Mediaroom clients. Media Discovery Subsystem (p. Provides media descriptions that include content metadata and information about how to access the content. Exposes two identical Web services that support requests from the server-facing tier and the Web tier. 095) Service Information Subsystem (p. 098) Provides a central directory for all Microsoft Mediaroom services. Gives Microsoft Mediaroom clients the information they need to acquire video services. Bootstrap Web Service (p. 101) Authenticates Microsoft Mediaroom clients and logs them on to the Microsoft Mediaroom system. Contacts the subscriber management subsystem (SMS) to determine the subscriber status. Returns a list of URLs for Web services (TServerController Web service, upgrade Web service, and so on) from which the Microsoft Mediaroom clients can acquire configuration data. Sync Discovery Service Windows Service (p. 103) Provides clients with the location of resources that they can contact during regular start-up to retrieve an upgraded version of the client software, or to recover from client software failure, should one occur. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 17 Component Description Subscriber Management Subsystem Provides a central repository for information about subscriber entitlements. The bootstrap Web service uses the subscriber management subsystem (SMS) to determine whether subscribers are legitimate and are allowed to access the service. SMS also stores billing events when subscribers make purchases and exposes a Web service through which service provider BSS systems can modify billing-related data. (p. 105) Service Group Subsystem (p. 109) Stores account-specific data. Service Group SMS Web Service (p. Enables BSS Web services to access the service group database. 112) Branch Management Subsystem (p. 113) Notification Subsystem (p. 116) Provides a central database for subscriber information and a Web service to assign accounts to the appropriate service groups. Enables Microsoft Mediaroom services to send messages to set-top boxes. Part of the Microsoft Mediaroom Extensibility Framework. Custom applications can also send messages to Microsoft Mediaroom clients through the UI notification and diagnostics notification Web services (ossNotificationsWS). DVR Scheduler Subsystem (p. 125) Manages digital video recorder (DVR) recording schedules. Prompts clients to start and end recordings through the notification subsystem. User Store Subsystem (p. 128) Provides a generic mechanism for saving and retrieving persistent name/value pairs. Session Key Authority Subsystem (p. Generates, signs, and disseminates symmetric AES keys to Microsoft Mediaroom components. 130) Search Subsystem (p. 132) Manages Microsoft Mediaroom client requests for descriptions of media that meet various search criteria, such as title or actor names. Logging Subsystem (p. 135) Manages the various events generated by the Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 18 Component Description Microsoft Mediaroom server software components and Microsoft Mediaroom clients. Collects service logs and subscriber activity events, such as channel changes, and saves logs in a server-side database. Client Management Subsystem (p. 143) TV Services Management Tool (p. 151) OSS Web Services (p. 155) BSS Web Services (p. 168) Enables Microsoft Mediaroom service providers to upgrade software on set-top boxes in the field. Provides a Web-based UI through which Microsoft Mediaroom system operators manage live TV, VOD, and network (RDP) application services. Enables the TV Services Management tool and other OSS systems to manage the acquisition and delivery of live TV, VOD, Live to VOD, and network (RDP) application services. OSS Web services include: • The ossBackendBlackout Web service. • The ossBranchBlackout Web service. • The BranchMgmtWS Web service. • The osschannel Web service. • The diagnostics notification Web service (ossNotificationsWS). • The ossepg Web service. • The OssLiveBackend Web service. • The ossppv Web service. • The ossremoterecord Web service. • The UI notification Web service (ossNotificationsWS). • The ossurl Web service. • The ossLiveToVodWS Web service. • The ossVodBackendWS Web service. • The ossVodBranchWS Web service. Enables the integration of service provider billing systems with Microsoft Mediaroom. BSS Web Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 19 Component Description services include: Service provider's operations support systems and business support systems • The BillingRecordManagement Web service. • The GrantManagement Web service. • The PackageManagement Web service. • The OfferManagement Web service. • The PrincipalManagement Web service. • The reportingstore Web service. Provides the service provider’s operations and billing services. Typically in place for an existing subscriber base, these systems integrate with the Microsoft Mediaroom system through the OSS and BSS Web services. Microsoft Mediaroom integrates with the service provider’s OSS and BSS systems by exposing a set of Web services. The Web services enable external OSS and BSS systems to import and export data (get and set operations). Traditionally, these OSS and BSS systems include the service provider operations support systems and business support systems and the SMS. Microsoft Mediaroom Client (p. 173) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 20 An embeddable, IP-connected software component that runs on Microsoft Windows CE and can be installed in a set-top box or in devices such as televisions, DVD players, DVRs, or game consoles. Consumes video and data services delivered by Microsoft Mediaroom server machines. Presents a user interface (UI) that enables subscribers to discover and view or interact with those services. Live TV Subsystem The live TV subsystem acquires live (real-time) TV services and Pay Per View (PPV) content from various input sources, processes the service content, and delivers it to Microsoft® Mediaroom clients. The live TV subsystem has a separated backend/branch model, in which each branch requests and distributes a subset of the services made available by the backend. This method provides control over the distribution state of a live TV service and enables operators to manage the provisioning of services. Operators can control the following factors: • The time that a live TV service comes online. • The live backend that handles the service. • The branches that distribute the service to clients. A service provider creates live TV services using the TV Services Management tool in the live backend. Operators in any branch can then deploy a published live TV service from any authorized backend. After a branch deploys a live TV service to one or more Distribution Server (DServer) machines, all clients in the branch that have the corresponding channel in their channel lineup and are authorized for the service gain the ability to tune and receive the video content. The live TV subsystem consists of two subsystems: • Live TV acquisition subsystem. Acquires and processes live TV services and produces Real-Time Protocol (RTP) streams. This subsystem packages the RTP streams in multicast User Datagram Protocol (UDP) packets and delivers the packets to the live TV delivery subsystem and Microsoft Mediaroom clients. The live TV acquisition subsystem encrypts the content by using Digital Rights Management (DRM) technology, and makes the keys available for downstream branches to distribute to their clients. • Live TV delivery subsystem. Is responsible for the unicast delivery of live TV services to Microsoft Mediaroom clients, providing instant channel change (ICC) and reliable UDP. Functional Flow from Capture Through Delivery The following diagram illustrates the functional flow of a single live TV service from the point of capture through the delivery to Microsoft Mediaroom clients. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 21 The numbered steps that follow describe details of the process. 1) Live TV acquisition subsystems capture and process a live TV service. Backend operators use the TV Services Management tool to create and configure a live TV service. The configuration process defines the capture and process parameters, such as the transport stream source, the aspect ratio, and the bit rate, for the live TV acquisition subsystem. Live TV acquisition subsystems reside in the live backend. A single deployment can have one or more live backends. A live backend can be deployed nationally, regionally, or locally. For additional information on live backends, see Logical Deployment Architecture (p. 013) in Installation and Configuration Guide. For additional information on how to configure and publish a live TV service, see Operations Guide. 2) Live TV acquisition subsystems multicast each live TV service on a port with a unique multicast address. Although the multicast address for each live TV service must be unique, ports can be reused. Multicast packets are received by both the live TV delivery subsystem and Microsoft Mediaroom clients. Multiple branches and numerous clients can connect to a single multicast live TV service coming from a live TV acquisition subsystem. Branch operators use the TV Services Management tool to deploy a live TV service from the live TV acquisition subsystem. Each branch can deploy a different set of live TV services. If a branch deploys a live TV service as unicast, ICC with multicast, or multicast RUDP the live TV delivery subsystem receives the multicast Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 22 stream from the live TV acquisition subsystem. If the service is deployed as a multicast, the DServer machines ignore the service and the clients connect to it directly. Additionally, a process within the branch periodically polls the backend to retrieve the keys needed by clients to view the encrypted content. When configuring a live TV service for deployment, operators set up bulk delivery for the RTP streams to be either point-to-point (unicast) from the live TV delivery subsystem, or one-to-many from a multicast transmission. The distribution method for each live TV service is configured separately for each branch. If the live TV service is configured with unicast, clients receive all packets in the RTP stream as a unicast transmission from the live TV delivery subsystem. In this case, only the live TV delivery subsystem receives the multicast output from the live TV acquisition subsystem. Note Unicast delivery is not typically used for deployment If the live TV service is configured with ICC with IGMP, clients receive some unicast packets (on startup and for retries), but receive the bulk of the packets in the RTP stream directly from the multicast stream sent by the live TV acquisition subsystem. In this case, both the live TV delivery subsystem and the client could be receiving the multicast output from the live TV acquisition subsystem. Each fullscreen and PIP stream requires a unique multicast IP address and an assigned port. If a backend operator changes the parameters of a deployed live TV service, the Live Backend Update Windows service, which is running at the branch, gets the changed values and uses them to update the branch. The Live Backend Update Windows service polls the backend periodically for any service data changes. 3) Live TV delivery subsystems deliver the appropriate video content to clients. If the live TV service is in the client channel map and the subscriber has access rights to the live TV service, the client displays the live TV service when the subscriber tunes to the appropriate channel. If a subscriber does not have the appropriate access rights, a secondary video service can appear. For a live TV service, this secondary video service is typically some type of upsell trailer. When the client tunes to a live TV service, with ICC, the live TV delivery subsystem bursts the live TV service to the client, enabling it to begin displaying live video very quickly. For unicast delivery, this connection is kept open. For ICC with multicast, the client switches to multicast after the initial burst is complete. The DServer machine and client communicate through command and control protocol. Client authentication occurs during each command and control packet exchange. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 23 Note For channels deployed using ICC with multicast, when a program is recording in the background (not being displayed) on the client's DVR, ICC is not required, and so the client joins the multicast stream directly and uses the DServer machine for retries. 4) If the client detects lost packets, it requests that the live TV delivery subsystem deliver the lost packets from the DServer machine to which it is connected. Each session is bound to a particular DServer machine. If the client is connected to more than one streaming service at a time, each session is handled independently, and the sessions may or may not be sourced from the same DServer machine. Live TV Subsystem Software Components and Data Flow The following diagram shows the live TV subsystem software components and a very simple data flow. This diagram does not reflect scalability. See Also High-Level Architecture (p. 013) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 24 Live TV Acquisition Subsystem The live TV acquisition subsystem is an installation of hardware and software modules that take live MPEG-2 transport streams as TV data feeds and convert them into RTP streams. Live TV data feeds come from multiple media sources: • Real-time hardware encoders, such as VC-1, H.264, and MPEG-2 encoders. • Spooled files on a local hard disk drive, such as media files containing Microsoft 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 performs the following operations: • Captures live TV streams that are delivered to the Acquisition Server machine from MPEG2TS over multicast UDP. This operation includes capturing a secondary audio program (SAP) if the service is configured to do so. • Generates VC-1 picture-in-picture (PIP) streams or acquires PIP directly from encoders. PIP streams are a lower resolution, lower bit rate, video-only version of a live TV service. A PIP is typically used as a preview service for a channel other than the one the subscriber is currently viewing. • Encrypts video and audio elementary streams (ES) (full-screen video and audio, secondary audio, and PIP video). • Generates keys, rotates the keys that are used for encryption on content boundaries as dictated by operations support systems (OSS) and DRM, and stores the keys in a database. Once the live TV service is deployed on the branch, a polling mechanism keeps the keys up to date at the branch. • Encapsulates streams into RTP for multicast delivery to the live TV delivery subsystem and, depending on the configuration, to Microsoft Mediaroom clients through the service provider’s multicast-enabled network. • Marks the RTP stream with the appropriate Macrovision analog content protection control bits. The control bits instruct the Microsoft Mediaroom client to add analog content protection to the outgoing analog live TV stream. • Finds and marks RAP points in RTP headers. Encoding The live TV acquisition subsystem accepts external streams as MPEG-2 transport, sent over UDP multicast. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 25 Pre-encoded, full-screen or PIP services are packed into RTP packets. Local streams are MFRTP (for example: Acquisition Server machine-generated PIPs). The DServer machine 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 does not necessarily generate one for each stream. Having the Acquisition Server machine generate the PIP locally greatly decreases scalability. In the latter case, the live TV acquisition subsystem must first decode the stream, scale it down to the defined resolution, and then encode the PIP stream. PIPs that are externally generated, such as those created by the real-time encoders, are managed by the Acquisition Server machine as a separate process from the PIPs generated by the live TV acquisition subsystem. The streams are encrypted and passed through as usual. Supported Data Streams Microsoft Mediaroom supports several types of data streams. The following table lists the data streams supported by the system. Supported Data Stream Type Live-over-IP VOD DVR Playout Live-overDTT DVB-Teletext (EN 300 472) Yes Yes Yes Yes DVB-VBI (EN 301 775) for Teletext Yes Yes Yes Yes DVB-VBI (EN 301 775) for VPS Yes No No Yes AFD 2 Yes Yes Yes Yes DVB-Subtitles (EN 300 743) Yes Yes Yes Yes MHEG-5 No No 1 No 1 Yes EIA 608 Yes Yes Yes No EIA 708b Yes Yes Yes No 1 If present, because of Live to VOD for example, must be suppressed. 2 For WSS signaling Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 26 Failover Scenario When operators detect a failure in a server, they can manually change live TV service assignments from one Acquisition Server machine to another. This process requires the operator to have configured a designated backup Acquisition Server machine in the cluster. When failure is detected, the keys used by the initial Acquisition Server machine are reloaded by the new Acquisition Server machine, and the live TV service continues after a brief interruption. See Also Live TV Subsystem (p. 021) Live TV Delivery Subsystem (p. 031) Live TV Acquisition Subsystem Software Components and Data Flow The following diagram shows the software components and data flow of the live TV acquisition subsystem. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 27 The following table describes the software components of the live TV acquisition subsystem. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 28 Component Description Acquisition group controller Web service Coordinates live TV, PPV, and blackout acquisition activities across the Acquisition Server machines and delivers the appropriate details on live TV services to other Microsoft Mediaroom server components to enable delivery of streams and keys to Microsoft Mediaroom clients. A single Live Backend Controller machine can control multiple Acquisition Server machines. The Web service configures and coordinates the activities of the Acquisition Server machines. During startup, the Web service reads the service configuration information from the LiveBackend database and builds a table of Acquisition Server machines that are responsible for acquiring these services. All communications between the controller and the servers are HTTP connections initiated by the server. The controller cannot initiate a connection to an Acquisition Server machine. The controller detects whether a server is properly configured when the server periodically connects to the controller and requests instructions. The controller detects server failures by calculating the time elapsed since a particular server connected to the controller and requested instructions. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 29 Component Description Acquisition Server machine Captures, repackages, encrypts, and delivers live TV streams from external sources. In some cases, the live TV stream is decoded and the video re-encoded at a lower resolution. The Acquisition Server machine can also repackage or play back pre-encoded streams. Acquisition Server machines use processes to provide a way to group similar full-screen and PIP services. A process is a task that 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. A Microsoft Mediaroom installation can have any number of Acquisition Server machines with each Acquisition Server process running on an individual machine. The data that emerges from the Acquisition Server machine includes: • Boundary keys (used to encrypt data in audio and video streams). • Encrypted full-screen live TV services (A/V, and possibly data streams such as; subtitles, teletext, and a variety of other content). • Encrypted PIP services (video only). Acquisition Server machines can be clustered together. A cluster is a unit of network configuration and failover aggregation. A server belongs to no more than one cluster. An Acquisition Server machine cannot support a process unless it is assigned to a cluster because the cluster is what tells the Acquisition Server machine the subnet or subnets to use for ingress, egress, and so on. Communication between the Acquisition Server machine and the Live Backend Controller machine follows a polling model. The Acquisition Server machine periodically polls the Live Backend Controller machine for updated live TV service information. If services are added to or removed from the database, the Acquisition Server machine makes the appropriate updates to its current services. If a particular server does not poll for a certain amount of time, an alert is raised. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 30 Component Description Live backend database Contains the list of live TV services defined in the live TV subsystem, their associated properties, the cluster configurations, the list of servers in the backend, and keys associated with the services. The Live Backend Controller machine uses this information when configuring the Acquisition Server machines. You can modify the information by using the TV Services Management tool or external OSS Web services. Live TV Delivery Subsystem The live TV delivery subsystem sits near the edge of the service provider’s network. It receives one or more RTP streams emitted by the live TV acquisition subsystem, and delivers the live TV services to clients. The live TV delivery subsystem consists of a EdgeControllerFromEdgeWS Web service and multiple DServer machines. The EdgeControllerFromEdgeWS Web service manages a group of DServer machines. DServer machines distribute live TV services to clients, perform ICC, and handle reliable UDP. DServer machines can receive and deliver live TV services on the same or different subnets. Note The use of different subnets is recommended. Using the TV Services Management tool, operators define one or more ingress, egress, and retry subnets for the live TV delivery subsystem. For additional information, see Configuring Live TV Services (p. 114) in Operations Guide. The live TV delivery subsystem handles only point-to-point (unicast) delivery of RTP streams to Microsoft Mediaroom clients. Multicast RTP streams do not originate through this subsystem, although it does use them to support ICC with Multicast. Live TV is delivered over one of the four following protocols: • Unicast + ICC (RUDP) • Muticast + ICC (RUDP) • Multicast + RUDP • Multicast only Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 31 Instant Channel Change ICC is a tuning methodology that significantly reduces the time required for a live TV service to appear on a Microsoft Mediaroom client after a channel change. Switching channels in a digital environment is inherently slower than switching channels in an analog system. The delay is caused primarily 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 the client's caching of enough frames to prevent buffer underflow. To minimize this delay, the DServer machine 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 machine unicasts cached stream content, starting with an I-frame, to the Microsoft Mediaroom client at an accelerated rate. The rate is configurable through the TV Services Management tool at deployment time. Because the first frame is always an I-frame, the wait for an I-frame is completely eliminated. 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 cached content before a pure multicast tune would. After the live TV delivery subsystem sends enough cache content to “catch up” to live TV, it begins to send 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 system time clock/decode time stamp (STC/DTS) delay. Generally, the shorter those values, the shorter the ICC burst will be. Typical streams as deployed today have burst durations between 6 and 15 seconds. The following figure illustrates the ICC process. Provisioning DServer machine bandwidth depends on expected client activity. If 10,000 clients each change channels once a day at a different time, you do not need to provision nearly as much bandwidth in the DServer machine as you would if each client changes channel once a second. The more bandwidth that is reserved for each ICC burst, the less overlap exists between channel changes, but the more bandwidth must be available to each household. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 32 ICC with Multicast ICC with Multicast is an intermediate tuning methodology that combines elements of pure multicast tuning and ICC. ICC with Multicast uses the live TV delivery subsystem to enable the client to display full-motion video with the same response time as the ICC model. Note Both full-screen and PIP streams can be delivered using ICC and ICC with IGMP. 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 receiving an ordinary multicast stream. During the switch to ICC with IGMP, some packets typically are dropped, based on the data rate of the stream and speed of the IGMP join process. The DServer machine 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. The following figure illustrates the ICC with IGMP process. There is a trade-off between the length of time the client must remain attached to the DServer machine 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 machine, the DServer machine picks a key frame from some point in the past in its buffer and begins transmitting Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 33 data to the client from that point in the stream (thus enabling ICC). That initial time difference is called the “delay time.” For the DServer machine to catch the client up to the “live stream,” the DServer machine must transmit data in bursts at a higher data rate until it transfers not only all 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 percentage 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)/0.E Example: burst time = (3sec)/0.2 = 15sec 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 that must be reserved per subscriber on the DServer machine does not rely only on the amount of extra burst bandwidth provisioned; it also relies on the amount of time that a client spends in the burst state. Reliable Live TV over RTP/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 turned off at the branch, turned off on a service-by-service basis at the branch, or turned off on a service-by-service basis at the backend. All services deployed as ICC or ICC with multicast have UDP implemented between the delivery system and the client. When delivering RTP packets over UDP, the RTP packed is embedded directly behind the UDP header. Packet headers, RTP headers, and the packetized elementary stream (PES) headers within the content are not encrypted; only the ES data is encrypted. The following diagram shows the RTP packets within the UDP packets making up the stream. 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 34 The Microsoft Mediaroom Client (on the Set Top Box) does not report missing packets immediately, because packets can 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 machine to which the client is connected. The DServer machine 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 between the DServer machine and client are always delivered over the same network connection as that of the original unicast. Retry traffic between the Acquisition Server machine and the DServer machine can be routed over a separate connection. Prior to Microsoft Mediaroom 1.1 SP3.2, all retries were accomplished over unicast. In the case of a large failure, such as a backbone network failure between the Acquisition Server and DServer, the result is a flood of packet requests from both DServers and Clients exceeding the egress capacity of the Acquisition Server(s). In Microsoft Mediaroom 1.1 SP3.2 and later, a Multicast option has been added as an alternative approach to RUDP Unicast for servicing requests for lost packets where lost packets are re-injected into the multicast stream. The retry packets are sent on the same multicast stream as the original stream and reach the entire network. This Multicast RUDP (Inband RUDP) addresses scenarios where failures affect a large portion of the network. However, in the case of a local packet loss between the DServer and Acquisition Server the result would be flooding the DServer and Client network with unnecessary retry packets. The Acquisition Server, acting in the Autoselect Mode, automatically detects the nature of the failure (local loss or large scale network loss) and automatically selects the appropriate (Unicast vs. Multicast) mode to employ when transmitting retry packets. Failover Scenario While a Microsoft Mediaroom client is connected to a DServer machine, it periodically sends a command and control packet to the DServer machine and requests the status of the stream. If the connection fails or times out, the client detects a problem with the DServer machine. The client disconnects from the DServer machine, selects another one from its service-toDServer map, and tries to connect to the new DServer machine. If the first reconnect is successful, the subscriber perceives, at worst, only a few seconds of interrupted live TV 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, each individual DServer machine rejects connections that it cannot handle within its bandwidth Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 35 allocation, so if all DServer machines on the client’s current map reject the tune and the live TV service was originally deployed as ICC with IGMP, the client simply joins the service in “pure multicast” mode. The channel change time for pure multicast is large compared to the tune time for ICC. If the service is deployed as “ICC,” the client cannot recognize the multicast address, and therefore cannot join directly. If a client is tuned to a channel for the purposes of “background digital video recording” (the stream is recording but not currently displaying), there is no penalty for having a slightly slower channel tune. To improve system scalability, the client immediately joins the service in multicast mode. The client also initiates a connection to the DServer-to-service retries so that later viewing of the content has a complete packet stream. Service Replication For scalability and redundancy purposes, live TV service delivery is spread across multiple servers within a live TV delivery subsystem. A DServer machine 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 Microsoft Mediaroom system, they assign a percentage of DServer machines 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 DServer machines and the replication constant for a given service is set to 80 percent, 80 of the DServer machines 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 36 The following table describes the software components in the live TV delivery subsystem. Component Description DServer controller Manages DServer machines and coordinates the distribution of RTP streams. Web service Each EdgeControllerFromEdgeWS Web service can manage multiple DServer machines. Live configuration state Web service Exposes a Web service interface that enables external resources, such as the branch management Web service (ossbranch), to update the content in the BranchDB database. BranchDB database Contains the configuration information for each live TV service deployed in the live TV subsystem. This database also contains the mapping between live TV services and the DServer machines that distribute them. Service-to-DServer map Web service Exposes a Web service interface that enables clients to obtain the service-to-DServer map. This map tells clients the DServer Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 37 Component Description machine that is distributing each live TV service. A table inside the BranchDB database describes the services that are assigned to each DServer machine. The EdgeControllerFromEdgeWS Web service goes through the table and, for each service, randomly selects two DServer machines from the list. It collates the entries into the service-to-DServer map and returns the service-to-DServer map to the client. If a subscriber group is assigned to only one cluster, both servers will be in the same cluster. If the subscriber group is assigned to more than one cluster, then the subscriber group will be assigned to one server in each cluster. DServer Unicasts live TV services (RTP streams) to clients. The DServer machine also handles ICC and manages dropped packet requests. See Also Live TV Subsystem (p. 021) Live TV Acquisition Subsystem (p. 025) DServer/Client Command and Control All communication between DServer machines and Microsoft Mediaroom clients is through RTP/UDP. Before a DServer machine 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, Microsoft Mediaroom 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 DServer/client command and control packet starts with a 12-byte RTP header, followed by a 4-byte DServer command and control header. The following table contains the set of commands that are sent between the DServer machine and Microsoft Mediaroom clients. Value Description Sent By 0x01 Join request Client 0x02 Retry request Client Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 38 Value Description Sent By 0x04 Leave Client 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 Machine Error Codes The following error codes are sent from the DServer machine. Error Code Description Additional Information 0x0001 Service not yet buffered Service GUID 0x0002 Retry packet requested is not valid Synchronization source (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 version None 0x0007 Server full None 0xFFFF Session destroyed by server Session GUID Command and Control Data Exchange The following diagram, which shows a “join service” command and control exchange between a DServer machine and a Microsoft Mediaroom client, illustrates how the UDP Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 39 packets that are sent open a hole for bidirectional communication through any intermediate firewalls. Multiple Identical Live TV Delivery Subsystems In a typical Microsoft Mediaroom system, a single live TV delivery subsystem delivers all live TV services to all clients in a branch. You can configure the live TV subsystem 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 40 In this illustration, service groups A and B are in two different cities. The live TV delivery subsystems are physically located in these cities. The Branch Management machine can be physically located in either city. The Branch Management machine and the two live TV delivery subsystems all reside in the same logical branch. When an operator deploys a live TV service (or performs any service maintenance function), the service is automatically deployed to both live TV delivery subsystems. The DServer machine clusters in the live TV delivery subsystems are associated with the clients in their service groups through a subscriber group. In this example, two subscriber groups are used, set up so that in subscriber group A clients in service group A connect to DServer machines in service group A, and in subscriber group B clients in service group B connect to DServer machines in service group B. For the multiple live TV delivery subsystem feature to work, you must configure the system to meet the following requirements: • The backend database and Web services recognize only one live TV delivery subsystem. • Each client belongs to only one subscriber group. • Every client in a service group belongs to the same subscriber group. • The DServer machines in the live TV delivery subsystem belong to the same subscriber group. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 41 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 central office and multiple regional offices, you configure the live TV acquisition subsystems to acquire national services at the central office and local services at the regional office that is closest to the clients for those services. The individual regional offices can deliver all, some, or none of these services to their respective clients. The live TV delivery subsystems (distribution points) are located in the regional offices closest to the clients. The following diagram depicts this example of a central office and multiple regional offices and the configuration of the live TV acquisition subsystems. You use the TV Services Management tool to define the live TV services that are acquired by each live TV acquisition subsystem. Similarly, you use this tool to define the services that are deployed to each live TV delivery subsystem. For more information on scalability, see Scalability Guide (p. 005). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 42 See Also Live TV Subsystem (p. 021) Live TV Acquisition Subsystem (p. 025) Live TV Delivery Subsystem (p. 031) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 43 Video on Demand Subsystem The video on demand (VOD) subsystem acquires VOD assets and delivers them to Microsoft® Mediaroom clients. Typically, VOD assets are created and managed by thirdparty VOD asset content providers, who make the assets available to service providers. The Microsoft Mediaroom Video on Demand (VOD) subsystem supports the acquisition, import, and delivery of VOD assets that can be deployed to one or more VOD Servers. The VOD subsystem uses a deployment 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 for Non-Distributed VOD Clusters The following diagram illustrates the high-level steps for VOD encoding, importing, and deploying VOD assets within a VOD subsystem based on one cluster for each branch. A branch is a logical construct that defines a specific set of Microsoft Mediaroom server roles on a specific set of server machines. (A branch is not a physical location.) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 44 1) Content providers use third-party professional VOD encoding tools to encode VOD assets. During this process, they define 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 provide the VOD asset metadata. (Microsoft Mediaroom supports assets delivered with ADI 1.1 or Microsoft Mediaroom metadata. For more information about how Microsoft Mediaroom translates ADI metadata, see VOD Metadata Guide and Reference.) Asset metadata includes 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. 062). 2) Content providers deliver VOD assets to service providers through a secure mechanism such as a virtual private network (VPN) or catcher system to the vodassets folder at the service provider’s site. For information on creating the vodassets folder, see Creating a Folder for VOD Imports (p. 341). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 45 3) After a VOD asset is successfully delivered to the vodassets folder, Vod Import Preprocessor Windows® service can perform necessary translations to an asset or group of assets. These necessary translations include the following: translating ADI metadata to Microsoft Mediaroom metadata; translating .png graphics; and applying an operator’s rules-based modifications to the VOD asset metadata or verbs (for example, import and deploy). After Vod Import Preprocessor Windows service completes its tasks, a VOD backend operator might use the VOD Asset Management tool to modify certain metadata values. Such modifications could include, for example, the purchase price or the rental time frame. For more information on the metadata values that VOD backend operators can modify with the VOD Asset Management tool, see Modifying VOD Asset Metadata at the Backend (p. 347) in Operations Guide. 4) VOD backend operators use the VOD Asset Management tool to select VOD assets for import or auto-import. The VOD Creator Station imports and processes VOD assets that are stored in the vodassets folder. The VOD Creator Station encrypts VOD assets with Digital Rights Management (DRM) keys; applies Macrovision or CGMS-A messaging; generates Real-Time Transfer Protocol (RTP) streams for the main feature; generates trick streams; and stores the generated VOD asset content in one of the Staging folders. There can be more than one VOD Creator Station performing these tasks, and more than one Staging folder. For details, see VOD Acquisition Subsystem (p. 063). VOD backend operators can choose to have asset files automatically deleted from the Staging folder when their license window expires. If they select that choice, they can also choose to have the asset files automatically deleted from the vodassets folder at the same time. For more information on these choices, see Settings (for VOD Management) (p. 094) in TV Services Management Tool Reference. Note Fast forward and rewind trick streams are not created for the asset's trailer file (preview). The only supported trick stream for the trailer file is pause. 5) Branch operators choose the assets to deploy to the VOD delivery subsystem, or they have assets deployed automatically. Auto-deployment can be activated and can depend on rules defined by the VOD backend operator. Deployment of a VOD asset triggers an automated process that copies the VOD asset from the VOD backend Staging folder to the selected VOD clusters in the branch. For details, see VOD Delivery Subsystem (p. 064). After VOD asset deployment, branch operators can use the VOD Asset Management tool to modify the VOD metadata to reflect branch-specific parameters. 6) Subscribers can purchase and play a VOD asset, based on the business rules specified by each VOD asset's business metadata. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 46 7) The vodControllerWS Web service ensures that the VOD subsystem can support an additional VOD session prior to each play. Each play request to the VOD subsystem is authenticated to ensure that only valid clients are accessing VOD assets. For additional information on the vodControllerWS Web service, see VOD Delivery Subsystem (p. 064). When a client requests a VOD asset, the highest priority VOD cluster assigned to the subscriber group of which that client is a member is contacted. If that VOD cluster is offline, the next highest priority VOD cluster assigned to that subscriber group is contacted, and so on until an online VOD cluster with the requested VOD asset is found. If all VOD clusters assigned to the subscriber group are offline, an error code is returned to the client. 8) Each asset event is maintained by Microsoft Mediaroom to support the necessary audit, billing, and settlement. 9) Branch operators can either use the TV Services Management tool on the Branch Management machine to choose the assets to delete from each branch, or they can have assets deleted automatically based on the end of the license window, as specified in the VOD asset’s business metadata. 10) If the backend operator did not choose to have the VOD asset files automatically deleted from the Staging folders, they can use the VOD Asset Management tool on the VOD Management machine to manually delete the assets from the Staging folders. If the backend operator did choose to have the VOD asset files automatically deleted from both the Staging and vodassets folders, the VOD asset's files are automatically removed when its license window expires. 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 for Non-Distributed VOD Clusters (p. 044). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 47 Servers can be positioned closer to the set-top box to accommodate bandwidth constraints. To configure this, for each geographical region the operator sets up one cluster and one subscriber group. The operator uses the TV Services Management tool on the Branch Management machine or uses operations support systems (OSS) APIs to associate a subscriber group with a cluster. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 48 To conserve storage and bandwidth for more popular VOD assets, VOD Servers can be assigned to different VOD clusters that in turn can be associated with the same subscriber group. You place the more popular VOD assets on VOD clusters that are located at a site closer to the subscriber, and the less popular VOD assets on VOD clusters that are at the branch. When the subscriber chooses to view a VOD asset, the VOD cluster assigned the highest priority is contacted first. If that VOD cluster does not have the requested VOD asset or is offline, the VOD cluster assigned the next highest priority is contacted. This arrangement also provides additional failover capabilities. When the higher priority VOD cluster is offline, the next highest priority VOD cluster that has the requested VOD asset provides it to the client. The following diagram shows how a VOD asset is served from a specific VOD cluster based on the priority assigned to the VOD cluster. Note A VOD cluster should be associated with only one subscriber group. The vodMapServerWS Web service is hosted on a client-facing service group machine. When the vodMapServerWS Web service 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 VOD cluster. • If the associated VOD cluster has the requested VOD asset, it returns the IP addresses of two VOD Servers from the VOD cluster. • If the associated VOD cluster does not have the VOD asset, it returns an error code. The subscriber is in more than one subscriber group, but only one subscriber group is associated with a VOD cluster. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 49 • If the associated VOD cluster has the VOD asset, it returns the IP addresses of two VOD Servers from the VOD cluster. • If the associated VOD cluster does not have the VOD asset, it returns an error code to the set-top box. • The subscriber is in one or more subscriber groups; however, none are associated with a VOD cluster. An error code is returned to the 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. • • The associated VOD cluster that has the highest priority designation and which hosts a VOD Server that has the VOD asset provides it to the subscriber’s set-top box. • If the highest priority VOD cluster is offline, the next highest priority VOD cluster is contacted. If that VOD cluster has a VOD Server that has the VOD asset, it is provided to the subscriber's set-top box. • If none of the associated VOD clusters has the VOD asset, an error code is returned to the set-top box. The subscriber is in one or more subscriber groups, and one or more of those subscriber groups is associated with multiple VOD clusters. • The associated VOD cluster that has the highest priority designation and which hosts a VOD Server that has the VOD asset provides it to the subscriber’s set-top box. • If the highest priority VOD cluster is offline, the next highest priority VOD cluster is contacted. If that VOD cluster has a VOD Server that has the VOD asset, it is provided to the subscriber's set-top box. • If none of the associated VOD clusters has the VOD asset, an error code is returned to the set-top box. After a VOD cluster is selected, the load balancing algorithm is applied to select the appropriate VOD Server and interface within that VOD Server. Note A Microsoft Mediaroom operator assigns a VOD Server to a specific VOD cluster through an entry in the serverlayout.xml file. For information on assigning a VOD Server to a specific VOD cluster, see Creating a New Server Layout File (p. 094) in Installation and Configuration Guide. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 50 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 Microsoft Mediaroom subsystems to deliver VOD assets to Microsoft Mediaroom 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 folders. The following table describes each software component, server, and storage location used in the VOD subsystem. Component Description vodassets folder Contains the pre-imported VOD assets. The VOD Creator Station looks for the VOD assets in this folder. The location of this folder is configurable. VOD assets must be transferred to this folder after they are acquired from a VOD asset content provider. For information on Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 51 Component Description creating this folder, see Creating a Folder for VOD Imports (p. 341) in Operations Guide. For additional information on the asset store subsystem, see Asset Store Subsystem (p. 088). BranchDB database Database that stores the states of all assets and VOD Server machines. vodCatalogWS Web service Provides a client-facing Web service interface through which clients obtain VOD metadata. When a Microsoft Mediaroom client needs to construct a Video on Demand screen, it contacts the vodCatalogWS Web service to obtain a list of VOD assets and categories. The vodCatalogWS Web service contacts the subscriber management subsystem (SMS) to look up the subscriber to determine which assets the subscriber is entitled to view. The vodCatalogWS Web service returns the complete URL of each VOD asset. The vodCatalogWS Web service is not responsible for tracking VOD locations (service information). The vodCatalogWS Web service is installed on a Server-Facing Branch machine. VOD cluster A logical grouping of VOD Servers that manages how assets are distributed to the VOD Servers in the cluster. After deployment, VOD Servers periodically report their current asset load back to the VOD cluster. Microsoft Mediaroom provides one VOD cluster, named “default.” You assign one or more VOD Servers in the same branch to a VOD cluster. You can assign multiple VOD clusters to a subscriber group, assigning a priority to each VOD cluster to control which VOD cluster the subscriber group's VOD asset requests will go to in priority order. For information on creating additional VOD clusters, see Creating a New Server Layout File (p. 094) in Installation and Configuration Guide. VOD Server Serves VOD asset content to the subscriber’s set-top box. A VOD Server can store VOD assets in RAM or direct access storage (DAS) memory, depending on how popular the VOD asset is at a given time. For more information about how the load on a VOD Server is managed, see the VOD Clusters and Load Balancing (p. 058) section. VOD Creator Station Exposes an interface through which the vodCreatorControllerWS Web service controls the import process. There can be more than one Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 52 Component Description VOD Creator Station. During import, the interface takes VOD assets (content and metadata) from the vodassets 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 folder Contains imported VOD asset files. During deployment these files are copied from this folder to the Mediaxx folders on the VOD Servers at the branch. You can configure additional local Staging folders, or additional Staging folders on a remote machine. For more information about configuring Staging folders, see Configuring an Additional Staging Folder on a Local Disk (p. 313) and Configuring an Additional Staging Folder on a Remote Machine (p. 315) in Operations Guide. VOD COM+ server Contacts the vodControllerWS Web service every n seconds with status (including asset and session information). IIS Extension Responsible for streaming and client authentication. On any connection changes, IIS Extension updates the VOD COM+ server machine. Ingest adapter Uses a variety of methods of loading a VOD asset into a VOD Server (http and https). Ingest adapter can get assets from the peer VOD Server machines in the VOD cluster during deployment and replication. vodMapServerWS Web service Provides a client-facing Web service interface for set-top boxes to receive the URLs of asset locations. The vodMapServerWS role is installed on a client-facing server that has access to the ServiceGroupDB database. vodControllerWS Web service Handles communication between the VOD Server and Server-Facing Branch machine. The vodControllerWS Web service manages the transfer of VOD asset content from the BranchDB database to each Media Store virtual directory (Mediaxx) on VOD Servers in each cluster according to the operator-defined content list. vodBranchWS Web service Provides an interface for all branch-related operations; for example, deployment and replication. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 53 Component Description vodBackendWS Web service Provides an interface for all backend-related operations, for example, import, pre-processing, and vodBackend database access. VOD branch management Web service (ossVodBranchWS) Provides a wrapper around the vodBranchWS Web service to enable VOD asset management by the VOD Management tool. For more information, see VOD Branch Management Web Service (p. 166). VOD backend management Web service (ossVodBackendWS) Provides a wrapper around the vodBackendWS Web service to enable VOD asset management by the VOD Management tool. For more information, see VOD Backend Management Web Service (p. 166). VOD Servers The type of VOD Server you use to store VOD assets depends on the performance expectations and popularity of the stored assets: • RAM. A RAM-based media server serves assets from RAM; therefore, its disk performance is slower, but the egress capacity is higher. The vodControllerWS Web service puts the most popular VOD assets on RAM-based VOD Servers to fully utilize the faster egress capacity. • DAS. A DAS-based VOD Server serves assets from the hard disk; therefore, its egress capacity is lower, but it can accommodate more assets than a RAM-based VOD Server. The vodControllerWS Web service puts all but the most popular VOD assets on the DAS-based VOD Servers. VOD assets on a VOD Sever are stored in the Media folder. Under the media folder are subfolders named Mediaxx where xx is a positive integer. The Mediaxx sub-folders are either a local folder or a mount point to another hard disk. The name for each new Mediaxx sub-folder is incremented by one for each new folder or mount point that is added to the VOD Server for storing deployed VOD assets. VOD asset files for each VOD asset are stored under separate Assetxx sub-folders under a Mediaxx sub-folder. The name for each new Assetxx sub-folder is incremented by one for each new VOD asset deployed to the VOD Server. The following example shows the directory structure under the Media folder on a VOD Server that has three media folders that store the files for a total of six VOD assets: Media\ Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 54 \Media0 \Asset1 \Asset2 \Media1 \Asset3 \Media2 \Asset4 \Asset5 \Asset6 Multicast Asset Distribution The multicast asset distribution delivery system delivers VOD assets to the branch without impacting VOD play-out that may be occurring on the set-top boxes. Note This delivery system does not scale the bandwidth required on the WAN links as a function of the number of branches. The following diagram illustrates multicast asset distribution. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 55 There are four main components to multicast VOD deployment for multicast asset distribution: • ContentDistributionControllerWS. • ContentDistributionServer. • ContentDistributionReceiver. • OSS Content Distribution Web service. There are also three minor components in the existing Microsoft Mediaroom architecture that connect multicast asset distribution to the import and deployment process: • VODCreatorControllerWS Web service. • vodBackendWS Web service. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 56 • VOD VServer Windows service. ContentDistributionServer consists of a Windows service at the central office that interfaces with ContentDistributionController and the asset distribution engine. The engine includes the distributor driver responsible for streaming VOD assets over multicast and the user mode code that interfaces to it. ContentDistributionReceiver consists of a Windows service at each branch; the Windows service interacts with ContentDistributionController and the asset distribution receiver engine. The Receiver driver in the engine is tasked with receiving the multicast stream, and the OSS Content Distribution Web service stores the received VOD asset files according to the manifest. Note This feature is only available if the QFE116790 portion of the SP3.2 CP2 is installed in your Microsoft Mediaroom 1.1 SP3.2 server environment. For information on postinstallation configuration and the content distribution Web service (OSS), see “Appendix of Changes for QFE116790 - Multicast Asset Distribution” in QFE187577 Release Notes. For information on configuring multicast asset distribution, see Configuring Multicast VOD Asset Distribution (p. 320) in Operations Guide. Status Updates and Failover When a new task is assigned to a VOD Content Distribution Server, the server must ping the Content Distribution Controller every n seconds to inform the controller of its status. If a server fails to report task status within a predefined “server time-out” (default is 30 minutes), the controller flags the server as inactive, reschedules the task, and changes the primary server. After the task is rescheduled, it is assigned to any other idle server, and that server becomes the primary server. The Content Distribution Receivers time out on receiving the task from the original server and use the next address to get the manifest on the stream and receive the VOD asset. If the failed server is successfully restarted and reports its status, the controller continues to send the tasks to the new primary server. Every time a new server becomes a primary server, or an offline primary server comes back within the “server time-out”, the current task starts over again. There is no failover mechanism for the receiver, but the system supports receiver redundancy. A VOD cluster can have multiple active receivers, all receiving the VOD asset files at the same time. When the VOD Servers check the serverlayout.xml file for machines with local staging, the VOD Servers cycle through all the receivers in the VOD cluster before checking the VOD backend for local staging. Local staging, if configured, provides a local directory on the VOD Server for the receiver to use in writing assets. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 57 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 Servers, whereas assets with lower usage patterns are served from lower-capacity VOD Servers. The VOD clusters associated with the VOD Servers can also be distributed in different locations, in a central office or a remote location, to conserve storage and bandwidth for VOD assets that are viewed more frequently. This load balancing enables service providers to optimize the overall cost of the equipment required to manage and deliver VOD assets. The vodControllerWS Web service is primarily responsible for managing the VOD asset 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 Creating a New Server Layout File (p. 094) in Installation and Configuration Guide. • The operator associates subscriber groups to VOD clusters, assigning a priority number to each association (ranging from 1 to 10, with 1 as the highest priority). • The operator assigns content titles to each cluster. For more information, see Deploying Assets to VOD Clusters (p. 385) in Operations Guide. • The vodControllerWS Web service manages the transfer of VOD asset content from the vodBackend database to each Media Store virtual directory (the Mediaxx folders) 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 vodControllerWS Web service and registering itself. Thereafter, the VOD Server reports its status through the VOD COM+ Server to the vodControllerWS Web service every 10 seconds. If for any reason the VOD Server shuts down (either for normal maintenance or unexpected failure), the vodControllerWS Web service detects its absence when it does not receive a status update from the VOD COM+ server monitoring that VOD Server. A maximum of 10 seconds elapses before the server’s absence is detected. When the vodControllerWS Web service detects that the VOD Server has shut down, it updates the database with this information. After that point, load balancing and adaptive allocation continue with the assumption that this VOD Server is not available to serve assets to clients. The VOD Server’s former clients are redirected through the failover mechanism to another VOD Server that has the same VOD asset that the client requested. When the VOD Server reboots, it first initializes itself by calling the vodControllerWS Web service and re-registering itself with the vodControllerWS Web service so that it is immediately available to serve assets to clients. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 58 When a request for a VOD asset is received, the vodMapServerWS Web services uses its copy of the ServiceGroupDB database to determine which VOD Servers have the VOD 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 network interface cards (NICs) on that VOD Server. The least-loaded NIC is selected from both VOD Servers and is then used to deliver the VOD asset to the client. The vodControllerWS 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. You configure NICs to use for load-balancing clients in the vserver.xml file by specifying the maximum percentage of the bandwidth to use on a specific NIC (the default is 80 percent). For more information about the vserver.xml file, see Modifying the vserver.xml File for a VOD Server (p. 369) in Operations Guide. To ensure access, the requested VOD asset can be deployed to more than one VOD cluster. When a VOD asset is requested by a client in a subscriber group that is associated with more than one VOD cluster, the VOD cluster that was assigned the highest priority number is contacted first. If that VOD cluster is offline, the VOD cluster with the next highest priority number is contacted. If all of the VOD clusters associated with the subscriber group are offline, an error message is returned to the subscriber's device. Adaptive Asset Allocation A VOD asset is deployed first to a configurable number of DAS VOD Servers within the VOD cluster. (The number of servers in the cluster to which the VOD asset is initially deployed can be set in vodcontroller.xml, which is typically found in the installDir\config folder. The default is 2.) The DAS servers are chosen based on which has the most disk space available, or in a rotating fashion if both servers have the same amount of space available. You can free disk space by deleting the least popular VOD asset on the server, if that VOD asset exists on more than the configured minimum number of servers. If fewer than the minimum number of servers are available with sufficient disk space and no assets can be deleted to free up disk space, the VOD asset’s deployment will fail. The initial deployment is targeted to the VOD Server that currently has the most available storage space, directly from the backend Staging folder over HTTP or HTTPS. If the asset's initial deployment to a VOD Server fails, deployment to a different VOD Server in the cluster is not attempted and the asset deployment fails. Adaptive asset allocation only applies once the initial VOD deployment has succeeded. If necessary for security reasons, the VOD asset can first be copied to a temporary file system that the vodControllerWS Web service has access to, where it will then be copied to the Media Store virtual directory in the cluster. The temporary file system is the master storage Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 59 that is installed with the vodControllerWS Web service. Its usage is configurable, and the setting is stored in the BranchDB database. (By default, the setting is to not use the temporary file system, but to copy VOD asset files directly to the targeted VOD Server.) The subsequent copies are made from the first VOD Server to the second VOD Server in the cluster (the next server that has the most available storage space) through HTTP, using Windows NT® LAN Manager (NTLM) authentication. After that, the VOD asset is replicated to additional servers, as needed, based on demand. This process is called adaptive allocation. The algorithm for determining whether the VOD 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 VOD Server is above a configured threshold (TA), then the process continues with Step 2. The default for TA is 60 percent. 2) Replication of the most popular VOD asset on that VOD Server occurs. If the VOD asset is more popular than the least popular VOD asset in RAM, the VOD asset is replicated to a RAM-based VOD Server. If not, the VOD asset is replicated to a DAS-based VOD Server. 3) During replication, the system is analyzed to determine whether the VOD asset fits in the remaining storage. • For a RAM-based VOD Server, it is unlikely that the VOD asset fits in the remaining storage, so the least-used VOD asset is removed from the server, after ensuring that remaining servers can handle the current subscriber load for the removed asset. This may mean additional replication to another RAM- or DASbased VOD Server for the removed asset. The system will attempt to find the RAM-based VOD Server that requires the least amount of VOD asset movement. • For a DAS-based VOD Server, the list of available DAS-based VOD Servers is first sorted by network usage from least used to most used. A configuration variable determines how full the operator wants the disk system to grow to and once it hits that amount, any replication attempt to that server will result in first checking to see if a less popular VOD asset can be deleted. Once a VOD asset's usage goes down, it is not explicitly removed from a DAS-based VOD Server, but may be removed to make space for the replication of another VOD asset. 4) If a VOD asset is to be removed from a RAM-based VOD Server, it is first copied over to a DAS-based VOD Server and is then removed from the RAM-based VOD Server. If multiple assets are to be removed from the RAM-based VOD Server, as few assets as possible are removed by reviewing the sizes of the least popular assets. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 60 5) If any step in the process of VOD asset demotion from RAM-based VOD Server to DAS-based VOD Server fails, there is no rollover, and the whole job is marked as failure. 6) The VOD Servers that have the VOD asset (including the server chosen in Step 3) are evaluated to see whether, if any one of the VOD Servers went down, the remaining VOD Servers would exceed a configured threshold TB, given the existing load of connections. (TB is defined as the threshold of network utilization that when reached the VOD server will begin refusing connections.) If the configured threshold would be exceeded, the VOD asset is replicated to an additional VOD Server. 7) A race condition is avoided by having a single job queue for VOD asset replication and deletion on all VOD Servers. This job queue is stored in the Branch database. For example: • Asset A1 – 20%, Asset A2 – 35% • Request for Asset A3 received – uses 5% • Server’s total egress rate hits 60% • Trigger replication of Asset A2 Adaptive File Copy and Distributed Ingest When a VOD asset is delivered to a VOD Server, either for initial deployment or because of adaptive allocation, the vodControllerWS Web service tells the server the rate at which to copy the file. For initial deployment, the bit rate is set at 200 MBps. For replication, the vodControllerWS Web service selects the least-used NIC on the sending system and sets the bit rate to ensure it does not exceed the configured maximum percentage (the default is 50 percent) of the remaining bandwidth below TA. For example, if TA is 80 percent, the interface is capable of 1 Gbps, the adaptive copy percentage is 50, and the current usage of the least used interface is 500 MBps, the rate control would be set to 150 MBps: (1000*.8 – 500)*.5. Additionally, TC is defined as the maximum ingress capacity on a NIC interface. During adaptive file copy, the lower of the two values (maximum ingress capacity versus the percent of an NICs available bandwidth) is chosen as the ingress rate. This limits the impact of disk writes (W) on disk reads (R) delivery of VOD asset to client, because 1W=3R. Defining TC is simpler than tracking the disk read/write status in the Windows Performance Monitor. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 61 VOD Assets and Content Aggregation VOD asset content providers must deliver VOD assets in a specific format for service providers to import them into the Microsoft Mediaroom system. Each VOD asset consists of a set of files that include audio/video (A/V) data and related metadata. Content providers can use any Windows Media® 9, VC-1, or H.264 encoding tool that supports the Microsoft Mediaroom VOD compression parameters, such as Windows Media Encoder 9 Series. The VOD asset files include: • The audio/video (A/V) content itself in Advanced Streaming Format (ASF) or MPEG Single Program Transport Stream format (TS). • A trailer, in ASF or TS format. • Box or poster art in .jpg format. • Metadata describing the program (such as the feature title and actors), trailer, business data (such as price), and rights metadata (such as rental window), in CableLabs ADI 1.1 or Microsoft Metadata XML format. VOD content providers can generate VOD metadata files with any XML or text editor. If a VOD asset does not contain the proper set of files, the Microsoft Mediaroom system aborts the import process. VOD content providers should deliver VOD assets through secure mechanisms. Note Microsoft Mediaroom 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 Microsoft Mediaroom supports the following methods for the VOD Creator Station to use 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, the GOP size of assets that use it should be no more than two seconds. • High quality. This mechanism sets the quality of the encoded trick streams. The default setting is 30 percent. Trick streams are created and encoded in a single pass. Increasing the compression quality setting increases the VOD asset import time. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 62 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 a VOD asset’s main feature files. You cannot create trick streams for an asset’s trailer file. Note Trick stream speed cannot be set through a VOD 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 a VOD asset’s metadata specifically sets values for its trick streams. VOD Acquisition Subsystem The VOD acquisition subsystem manages the VOD manual import and automated import processes. A VOD Creator Station takes a VOD asset (content and metadata) from a local vodassets folder and generates a set of media and metadata files. The VOD Creator Station generates the processed assets in a specific location, known as the Staging folder. To expand storage for VOD assets without creating another VOD backend, the operator can configure additional Staging folders, either on the VOD Creator Station or another remote machine that does not have Microsoft Mediaroom installed. The Microsoft Mediaroom service provider at the branch can choose the assets to deploy with the VOD Asset Management tool. (For more information about configuring additional Staging folders, see Configuring an Additional Staging Folder on a Local Disk (p. 313) and Configuring an Additional Staging Folder on a Remote Machine (p. 315) in Operations Guide.) When a VOD asset arrives, it is automatically detected by the VOD pre-import process. The VOD pre-import process performs the following tasks: • If the metadata included with the VOD asset is in ADI format, converts it to Microsoft Mediaroom metadata format. • If rules are on and set, applies rules as appropriate. • Does basic repair such as case conversion and ensuring that fields are not too long. Once the VOD asset is successfully pre-processed, it becomes available for import. The VOD Creator Station performs the following tasks: • Validates assets. Assets can be rejected as part of the import process. • 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 Creator Station. During the deployment process, the private key associated with the backend certificate is used for decrypting Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 63 the RTP stream’s key file. For information about the deployment process, see VOD Delivery Subsystem (p. 064). • 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 VOD asset. • Sets the Macrovision state for VOD assets. During VOD asset import, DRM tags each frame of the RTP stream with the appropriate Macrovision analog content protection control bits, depending on the level of Macrovision protection for the VOD asset assigned either for the specific VOD asset or by a global setting. • Sets the CGMS-A state for VOD assets. During VOD asset import, DRM tags each frame of the RTP stream with the appropriate CGMS-A content protection control bits, depending on the level of CGMS-A protection for the VOD asset assigned either for the specific VOD asset or by a global setting. • 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 had previously watched the first 10 minutes of 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, trailer, 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 to deliver 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 (RAM-based servers), while assets with lower usage patterns are served from VOD Servers with more storage but less availability (DAS-based servers). 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. Operators use the VOD Asset Management tool to register each VOD cluster in the system and associate the VOD cluster with a set of VOD backends. Branch operators manually manage the allocation of VOD assets between clusters by taking advantage of the VOD asset usage information. Asset usage information includes data such as how many times a VOD asset was accessed in a particular time period. When deploying a VOD asset, the branch operator defines the VOD clusters that distribute the VOD asset and the subscriber groups that receive the VOD asset. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 64 By default, Microsoft Mediaroom is configured with an Everyone subscriber group. VOD assets deployed to the Everyone group are available to all subscribers. To deploy a VOD asset to a specific set of subscribers, the operator must first define the appropriate subscriber groups. For example, to test a new VOD asset before making it available for widespread purchase, the operator can create a Test subscriber group and specify it when deploying the VOD asset. Deploying a VOD 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 which you initially copy is configurable. The first copy is made from the Staging folder to the VOD Server that has the most storage space available. Subsequent copies are made from VOD Server to VOD Server to conserve bandwidth from the backend to the branch. The VOD delivery subsystem updates the SMS, service information (SI) subsystem, and BranchDB 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 the decryption of the DRM keys for each RTP stream. Decryption proceeds as follows: 1) The VOD delivery subsystem reads the branch certificates from the certificate store. The branch certificate is installed during Microsoft Mediaroom 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 VOD 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 devices. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 65 8) When a 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. 063). During the VOD asset deployment process, the VOD asset metadata is stored in the Asset Store Subsystem (p. 088) subsystem and rights data is stored in the Subscriber Management Subsystem (p. 105) (SMS) by the VOD Asset Management tool. VOD Session Management and Load Balancing Each VOD Server in the cluster reports its status to the vodControllerWS Web service on a regular basis (the default is every 10 seconds). This status includes the current bandwidth used on the VOD Server egress interfaces (or one interface, if NIC teaming is in use) and identifies which assets the VOD Server has available. This information is stored by the vodControllerWS Web service in the BranchDB database, which is then replicated out to the ServiceGroupDB databases. A new VOD session is created for the following actions: • When the subscriber goes from a stopped state to playing a trick stream (fast-forward or rewind) or from a stopped state to play the VOD asset. • When the subscriber tunes to any other channel, including other VOD channels. A new VOD session is not created when the subscriber goes from the play or pause state to fast-forward or rewind. When the client receives a subscriber request for a VOD asset, it contacts the vodMapServerWS Web service for a URL. The vodMapServerWS Web service determines the first and second least-loaded VOD Server interfaces from which the asset can be served and returns those URLs to the client. The client then uses those URLs to play the VOD asset. If the first URL fails, the client tries the second one. Life Cycle of a VOD Session VOD session information is kept on the VOD Server. When the VOD Server reaches its configured threshold, it will refuse any new connections. A new VOD session is created when: • A VOD asset is purchased and played. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 66 • The subscriber tunes back in to the VOD channel after tuning away. • The subscriber presses the Play button to resume viewing a VOD asset. A VOD session ends when: • A subscriber tunes away from the VOD channel. • A subscriber presses the Stop button. • The VOD asset finishes playing. If a subscriber uses the VOD asset’s trick streams (for example, to fast-forward through portions of the VOD asset), the current session remains open. If a subscriber pauses on a VOD asset for a long period of time, the VOD session is not closed. Packet Loss and Retry The Media Store virtual directories are the Mediaxx folders on a VOD Server that delivers VOD assets to Microsoft Mediaroom clients (“xx” is an incremental, unique integer assigned to the folder for each VOD asset). 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 The vodControllerWS Web service detects VOD Server failure when the VOD Server stops reporting its status. It detects failure within two intervals of server status reporting (by default, the interval between status reports is 10 seconds). The vodControllerWS Web service then updates the database status with this information so that the URL to that server is no longer returned to clients. Within a few seconds of the VOD Server’s failure, clients that are using the server for playback fail over to the second URL that was sent to them originally. If that secondary URL also fails, the client returns to the vodMapServerWS Web service to request another set of URLs. The TV Services Management tool on the Branch Management machine provides a way to manage VOD Servers, for example, to take a server offline for maintenance or decommission it and remove entries about it from the BranchDB database. For more information, see Managing VOD Servers (p. 420) in Operations Guide. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 67 Large Asset Playback The maximum size of a single file served by IIS is 2 GB. If a VOD main stream is larger than 2 GB due to the length of the feature, the stream is broken into multiple files. (Optionally, an operator can configure the import to break files into smaller segments.) 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 (trickstream 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 High-Level Architecture (p. 013) OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set) BSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set) VOD Asset Security The Microsoft Mediaroom system ensures the security of VOD assets within the system. It utilizes multiple security measures to ensure that only those subscribers who have access rights to a VOD asset can actually access the VOD asset. The Microsoft Mediaroom system uses the following mechanisms 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 Microsoft Mediaroom system after import. Microsoft Mediaroom clients decrypt VOD assets just prior to decoding the content. The system encrypts main feature and trailer streams using separate keys. Trick and trailer 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 recording devices by distorting the VOD assets over the analog interface. The Macrovision and CGMS-A states for VOD assets are set at import time on a per-asset basis or with a global setting. 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 Microsoft Mediaroom client to add analog content protection to the outgoing analog video. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 68 • CGMS-A 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 copies being made on recording devices that honor CGMS-A. The CGMS-A state for VOD assets is set at import time on a per-asset basis or with a global setting. During VOD asset import, DRM tags each frame of the RTP stream with the appropriate CGMS-A protection control bits. The control bits instruct the Microsoft Mediaroom client to add analog content protection to the outgoing analog video. • HDCP protection. High-Bandwidth Digital Content Protection (HDCP) is a form of Digital Rights Management developed by Intel Corporation to control digital A/V content as it travels across Digital Visual Interface (DVI) or High-Definition Multimedia Interface (HDMI) connections. Some countries require service providers to broadcast VOD asset content without encryption in the transmission or signal path. By default, Microsoft Mediaroom delivers VOD assets with HDCP enabled, but provides a way to disable HDCP through an entry in the VOD asset's metadata file or through creation of a VOD import rule to add or change the disableHDCP value to the file during the import process. On the client side the information is extracted from the service information (SI) subsystem data and then flagged to the HDCP driver. The driver sets the correct HDCP mode for the VOD asset, based on that flag. For information about the disableHDCP element in the VOD asset metadata file, see disableHDCP Child Element (p. 031) in VOD Metadata Guide and Reference. For information about creating VOD import rules, see Setting the VOD Asset Import Rules (p. 349) in Operations Guide. • Client authentication. VOD asset requests follow the same client authentication process that live TV content does (as do all requests for client access to the Microsoft Mediaroom system). The system authenticates all client requests made to the VOD subsystem. • Secure connection between VOD backend and branch. The system can be configured to use SSL when copying VOD assets between the VOD backend and a branch. • Subscriber access rights. The VOD subsystem provides the same subscriber access rights capabilities as live TV. Integrating a Branch with an EQoS Interface The branch can optionally be integrated with an external quality of service interface (EQI) to oversee the quality of service (QoS) during a subscriber’s VOD purchase experience, as well as interaction with the VOD asset itself (for example, playing or using trick speeds). For Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 69 information on implementing and deploying an EQI Web service, see Configuring the External Quality of Service Interface Web Service (p. 183) in Installation and Configuration Guide. For more information about integrating the branch with an EQI, see “External Quality of Service Interface Web Service” in OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Integrating a Branch with an EPOC System The EPOC Web service is a Web service that service providers can optionally implement and deploy to define the business logic for VOD purchases. Microsoft Mediaroom does not provide a sample implementation of the EPOC Web service. For information on implementing and deploying the EPOC Web service, see Configuring the External Purchase Offer Cycle Web Service (p. 179) in Installation and Configuration Guide. For details on the API that this Web service must implement to support EPOC, see “EPOC Web Service” in OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 70 Live Anytime Subsystem The Live Anytime subsystem enables operators to record selected live programs, convert and save them as VOD assets, generate offers, and make the programs available to subscribers through the Video on Demand screen. Note Originally Live Anytime was released as “Live to VOD.” The feature name has changed as of the Microsoft® Mediaroom Server 1.1 SP3.2 CP2 (SP3.2 CP2) release. While the latest release of the Microsoft Mediaroom documentation refers to the current feature name, many system components, such as services and configuration files, use the prerelease name. The following diagram illustrates the overall architecture and components of the Live Anytime subsystem. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 71 Live2VOD Recording Server The Live2VOD Recording Server resides in the branch and receives recording jobs from the Live2VOD Controller Machine (p. 073). The Live2VOD Recording Server automatically registers itself with the Live2VOD Controller and reports back to that machine every 10 seconds. Capturing and Recording Assets The Live2VOD Recording Servers join the appropriate live TV multicast streams according to configured schedules. The Live2VOD Recording Servers receive and convert the live TV streams to VOD format, generate trick streams and VOD asset metadata, and temporarily store the converted data on a local disk. If padding time was configured for the recording, the configured amount of time is added to the beginning and end of the scheduled recording. Fast-forward trick streams are generated simultaneously as the multicast stream is converted to VOD format. Rewind trick streams are generated after the program has finished recording. Metadata for the Live Anytime asset is generated from the Electronic Program Guide (EPG) data that was available when the recording was completed and stored on disk. After the program and the trick streams are recorded, a VOD metadata file is generated and index files (.idx) are created for the asset's full-screen, trailer, and trick stream files. At this point, the program appears as a typical VOD asset in the configured Staging folder that is used for all VOD assets. For more information about the files generated for a VOD asset during import, see VOD Acquisition Subsystem (p. 063). After the recording, trick stream, and metadata generation are completed and the resulting files are written to the Staging folder, the Live2VOD Recording Server notifies the Live2VOD Controller that the Live Anytime asset is ready to be deployed through the VOD delivery subsystem. If the option to create offers automatically when VOD assets are deployed is selected on the Settings (for Branch Management) (p. 100) page in the TV Services Management tool, an offer based on the Live Anytime asset's generated metadata is created. Note The Live Anytime subsystem also supports Live2VOD Recording Server redundancy to ensure that a server is available to record a scheduled live program. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 72 Live2VOD Controller Machine The Live2VOD Controller machine resides in the same tier as the Server-Facing Branch machines. The Live2VOD Controller controls the activities of the Live2VOD Recording Server (p. 072), which automatically registers itself with the Live2VOD Controller and reports back every 10 seconds. The Live2VOD Controller also does the following: • Creates and manages recording schedules. • Deploys recorded assets to the VOD delivery subsystem. • Creates offers for deployed Live Anytime assets. Live Anytime Recording Schedules The Live2VOD Controller creates and manages recording schedules (such as EPG changes and recording event changes) for each Live2VOD Recording Server based on: • Recording events created by the service provider. • EPG information. • Live2VOD Recording Server load (ingress bit rate). • Minimal deployment setting. • Padding to be added to the beginning and end of a recording. Live Anytime Asset Deployment When the Live2VOD Recording Server completes a recording job and notifies the Live2VOD Controller of that, the Live2VOD Controller then submits a deployment job for the recorded asset to the VOD delivery subsystem; the latter acts as a VOD backend for the job. Live Anytime Roles Live Anytime includes the following roles: • L2VDB (p. 074) l2vRecServer (p. 074) • l2vControllerWS (p. 074) • ossLiveToVOD (p. 074) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 73 • smtLive2VOD (p. 074) • timeshiftMapServerWS (p. 075) L2VDB The L2VDB role is responsible for storing the Live Anytime configuration. Because the load on this database is small, it typically coexists on the same machine with the BranchDB database. l2vRecServer The l2vRecServer role, which is typically installed on the Live2VOD Recording Server, is responsible for capturing and recording assets. Because of the intense nature of processing required for capture and recording operations, the Live2VOD Recording Server is typically a physically separate, high-performance server. l2vControllerWS The l2vControllerWS role is responsible for creating and managing recording schedules and deploying finished assets to the VOD delivery subsystem. The l2vControllerWS role typically resides on the Live2VOD Controller machine. ossLiveToVOD The ossLiveToVOD role enables service providers to write custom applications to monitor and configure the Live Anytime subsystem. smtLive2VOD The smtLive2VOD role provides the interface between the TV Services Management tool and the Live Anytime subsystem. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 74 timeshiftMapServerWS The timeshiftMapServerWS role is a client-facing role that updates the tuning information for clients who are enabled to receive Live Anytime services. The role was added to the sessionKeyAuthority_KeyGenerator.xml file with the release of Microsoft Mediaroom SP3.2 CP2. The TimeShiftMap.xml file sets the interval at which the timeshiftMapServerWS Web service polls for updates to the tuning information for Live Anytime services. For more information about the TimeShiftMap.xml file, see TimeShiftMap.xml (p. 258) in Operations Guide. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 75 RDP Application Subsystem The Remote Desktop Protocol (RDP) application subsystem enables Microsoft® Mediaroom clients to display customized applications that run on remote application servers. The subsystem uses RDP, the same protocol that is used by Windows® Server 2003 Terminal Services. The Microsoft Mediaroom client initiates, maintains, and terminates RDP connections to each application. Subscribers can start RDP applications (network applications) from menus and from 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 corresponding events to the Terminal Server. Microsoft Mediaroom enables rapid development and deployment of RDP applications. This development environment makes it easier to develop and deploy customized behaviors that suit set-top box requirements. Customer service and self-provisioning applications are good candidates for implementation as RDP applications. RDP Application Subsystem Software Components and Data Flow The following diagram shows the functional software components of the RDP application subsystem. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 76 The following table gives an overview of RDP application subsystem software functionality. Subsequent sections provide more detailed descriptions of each component. Component Description Windows Server Terminal Services (p. Reside at the service provider site and serve requests for RDP sessions from Microsoft Mediaroom clients. 079) TServer Windows Service (p. 079) Provides status updates to the Terminal Server controller private Web service and then executes actions returned by the private Web service. These actions include creating users, changing passwords, starting new RDP sessions, and shutting down existing RDP sessions. Terminal Server Session Starter (p. 079) Stand-alone application (TerminalServerSessionStarter.exe) that starts a Terminal Server session and then exits. RDP Application Launcher (p. 080) Launches and manages the lifetime of RDP applications. The launcher runs on a Terminal Server and uses a virtual channel Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 77 Component Description message from the Microsoft Mediaroom client to determine which application to run. The client then renders the application’s UI. TServerProxy COM+ Service (p. 076) Enables the TServer Windows service and the RDP application launcher to communicate with internal Microsoft Mediaroom Web services. Terminal Server Controller Private Web Service (p. 081) Receives session state information from the TServer Windows service on each Terminal Server and stores it in the tservercontroller database. Terminal Server Controller Public Web Service (p. 081) Runs on a client-facing machine and performs client authentication on all requests. Terminal Server Controller Database (p. Stores the status of available RDP sessions on Terminal Servers. 082) Windows Applications (p. 082) Installed on the Terminal Server and run by the RDP application launcher. Ideally, Windows applications are designed for display on TV screens and for operation within the constraints of Microsoft Mediaroom set-top boxes. Web Applications Web applications can be hosted on the RDP Application Server, on a separate Microsoft Mediaroom server, or on an external server running IIS. The RDP application launcher hosts an Internet 6.0 browser control and customizes the browser behavior for the Microsoft Mediaroom environment (some customization is available through the TV Services Management tool). For example, it blocks dialog boxes. The control simulates the Windows XP Media Center eHome shell to support Media Center applications. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 78 Windows Server Terminal Services Windows Server Terminal Services reside at the service provider site and serve requests for RDP sessions from Microsoft Mediaroom clients (set-top boxes). 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 Microsoft Mediaroom client contains an RDP client that connects to one of the available sessions in the pool of RDP sessions that the Terminal Server set up when it was started. The Microsoft Mediaroom client logs in to the existing RDP session by specifying the Terminal Server's 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 tservercontroller database. The Terminal Server controller private Web service returns a list of actions to the TServer Windows service, which the service then executes. These actions include creating users, changing passwords, starting new RDP sessions, and shutting down existing RDP sessions. The TServer Windows service repeats this cycle of status updates and task execution at regular intervals. 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 TServerController 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 79 RDP Application Launcher The RDP application launcher (launcher) runs on a Terminal Server and launches and manages the lifetime of RDP applications. The Microsoft Mediaroom client starts up the RDP application launcher through its RDP session with Windows Server Terminal Services. Windows Server Terminal Services then start 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 only launch the launcher the client starts through its RDP session, and not launchers for other Terminal Server applications. The launcher determines which application to run from a virtual channel message that the Microsoft Mediaroom client sends. The Microsoft Mediaroom 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 Microsoft Mediaroom environment (some customization is available through the TV Services Management tool). For example, it blocks dialog boxes. Web applications can be hosted on the RDP Application Server, on a separate Microsoft Mediaroom server, or on an external server that is running IIS. 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 VOD asset content. Instead of integrating VOD asset content on the server side and delivering the entire UI over RDP, the RDP application subsystem delivers all non-video content over RDP and relies on Microsoft Mediaroom clients to integrate live video or VOD asset content that it receives over the corresponding transports. Note Microsoft Mediaroom 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 Microsoft Mediaroom 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. The application retrieves the user’s language setting from the UserLanguages list in the HTTP request header (HttpContext.Current.Request.UserLanguages[0] in ASP.NET). The language names follow the RFC 1766 standard in the format languagecode2-country/regioncode2 (for example, enUS). Similarly, you can implement applications 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 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 80 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 alert the Microsoft Mediaroom client that the application has finished loading. It also sends notifications of 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 Microsoft Mediaroom, see RDP Application Developer’s Guide in the Microsoft Mediaroom ADK documentation set. 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 tservercontroller database. Terminal Server Controller Public Web Service The TServerController Web service runs on a client-facing machine and performs client authentication on all requests. It acquires RDP session information from the tservercontroller database that tells Microsoft Mediaroom clients which Terminal Server to contact and to Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 81 which session they should connect. For details on how clients acquire RDP sessions, see Connecting to RDP Sessions (p. 082). Terminal Server Controller Database The tservercontroller database stores the status of available RDP sessions on Terminal Servers. The TServerController Web service accesses this database to provide RDP session details to Microsoft Mediaroom clients that need to run RDP applications. The contents of this database are managed by the Terminal Server controller private Web service. Windows Applications The RDP application launcher can run Windows applications installed on the Terminal Server. Each Windows application runs in a separate process, but in the same RDP session as the RDP application launcher that started it. For the best user experience, Windows applications should be designed for display on TV screens and for operation within the constraints of Microsoft Mediaroom set-top boxes. For details on design and implementation guidelines, see Application Developer’s Guide in the Microsoft Mediaroom OSS/BSS Integration documentation set. 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 TServerController 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 TServerController Web service queries the tservercontroller database for available sessions. If a session is available, it sends the TServer Windows service the following information: • 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 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 82 • Security token for client authentication If no sessions are available, the TServerController Web service returns an error, and the client repeats its session request until a timeout limit is reached. If the TServerController Web service returns a session, the Microsoft Mediaroom client connects to the given Terminal Server session. The RDP application subsystem only creates one RDP session for each subscriber. Subscribers can start multiple applications one at a time, but each is delivered over the same RDP session. If Microsoft Mediaroom cannot 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 Microsoft Mediaroom client presents the “Application not available” error message. System operators can manage RDP application items in the Microsoft Mediaroom client menu with the UserStoreDo command. For details on customizing the client menu, see Client Customization and Localization Guide (Microsoft Mediaroom Client documentation set). Note Microsoft Mediaroom clients present available RDP applications to subscribers if they receive RDP application service information from the media discovery subsystem. Microsoft Mediaroom 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 tservercontroller database. A Terminal Server is placed into service when the Terminal Server controller private Web service receives a first status update (initialization message) from the Terminal Server. If the Terminal Server controller private Web service does not receive a status update from a Terminal Server within a timeout limit, it is assumed that the Terminal Server is out of service and the Terminal Server controller private Web service no longer enables new sessions for that Terminal Server. If that Terminal Server resumes sending status updates, it is placed back into service. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 83 Securing RDP Sessions Calls to the client-facing TServerController Web service go through the Web service router, which authenticates all clients. Only valid Microsoft Mediaroom clients can successfully request RDP sessions from the TServerController Web service. On a successful call, the device ID is stored in the tservercontroller 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 Terminal Servers. When a Microsoft Mediaroom client connects to a Terminal Server session, the RDP application launcher receives the device ID from the Microsoft Mediaroom client. The launcher calls the Terminal Server controller private Web service to get the device ID that it stored for the session to ensure that they match. If the device ID does not match, the RDP application launcher immediately disconnects the session to ensure that only authenticated Microsoft Mediaroom clients can 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 tservercontroller 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 can connect to the session with 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 shut down 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 do not already exist), changes the passwords, and starts new RDP sessions (if an RDP session does not already exist for the user) for the list of user name/password pairs. Managing RDP Sessions on Each Terminal Server The TServer Windows service reads the <Sessions> tag in the TServer.xml configuration file to obtain start, max, and increment parameters that control the number of sessions used on each Terminal Server. It then contacts the Terminal Server controller private Web service with an initialization message that lists all 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 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 84 TServer Windows service then changes the password for each user and starts a session for that user if a session does not already exist. When a Microsoft Mediaroom client connects to a Terminal Server, new sessions may be started if necessary. The TServer Windows service ensures that the number of available sessions is never less than start or the number of sessions in use plus increment, and never more than the maximum number of sessions (specified by max). When a client disconnects from a Terminal Server, the session on the Terminal Server is terminated unless it is still needed. If the number of sessions is more than start and more than the number of sessions in use plus increment, the session is terminated because there are not enough sessions available. To take a Terminal Server out of service (for example, for maintenance), you can stop the TServer Windows service. Existing sessions in use are not affected, and no more clients are connected to sessions on that Terminal Server. To minimize disruption of the service, you can wait for clients to disconnect on their own before doing anything that would terminate the sessions (such as rebooting the Terminal Server). Scaling, Load Balancing, and Failover Access to multiple Terminal Server machines is load balanced by the client-facing TServerController 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 TServerController Web service no longer enables new sessions on that Terminal Server machine, which causes all subsequent connection requests to fail over to the other Terminal Server machines. Because the TServerController Web service performs load balancing, Terminal Servers should not be load balanced by other mechanisms, such as network load balancing (NLB) in Windows Server. To improve availability of the TServerController Web service and Terminal Server controller private Web service, the machines running these Web services can be load-balanced with NLB or other mechanisms. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 85 Web Service Router The Web service router (WSR) brokers all Web service communications (SOAP over HTTP) between Microsoft® Mediaroom devices and client-facing Microsoft Mediaroom Web services. The WSR proxies Web service requests from Microsoft Mediaroom clients to Microsoft Mediaroom Web services in other security zones, where the calls are processed. When the call completes, the WSR returns the result to the client. For a list of client-facing Web services, see Server Layout Roles for Each Machine (p. 302) in Installation and Configuration Guide. The sole purpose of the WSR is to provide a buffer between Microsoft Mediaroom clients and the client-facing Web services. With the WSR in place, HTTP ports need to be open only between the application tier, where the application servers reside, and the interface tier on 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 Microsoft Mediaroom Web service. When a Microsoft Mediaroom 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 a restart of the IIS application pool for the changes to take effect. IIS supports a rolling restart, which drains connections from an existing worker process and sends a new request to a new worker process, thus ensuring no down time. The WSR builds its routing table from the routing information in the roles.xml file, specifically from the <roleURI> XML element. The following diagram shows how the WSR fits into a typical deployment. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 86 The WSR provides the following important benefits to securing Microsoft Mediaroom deployments: • Reduced attack surface. By moving all Web service application logic out of the Web tier, fewer public interfaces are exposed to Microsoft Mediaroom 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 does not require open ports to enable SQL communications. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 87 Asset Store Subsystem The Asset Store subsystem is a logical construct that stores metadata for RDP applications (network applications) and VOD assets that subscribers can browse, play, 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 VOD branch management Web service (ossVodBranchWS) Provides a Web service through which the TV Services Management tool initiates import operations and coordinates VOD asset deployment. vodBranchWS Web service Enables the VOD, RDP Application, and Search subsystems to retrieve VOD asset metadata over HTTP. vodCatalogPrivateWS Web service Builds the VOD catalog of assets that display in the Search screen for subscribers. The catalog of assets is the library of content that the subscriber has requested. The client displays these assets together in a listing that is viewable by the Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 88 Component Description subscriber. BranchDB database Database that stores the states of all assets and VOD Server machines. Maintains information about deployed VOD assets. See Also Video on Demand Subsystem (p. 044) RDP Application Subsystem (p. 076) Search Subsystem (p. 132) Subscriber Management Subsystem (p. 105) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 89 Listings Subsystem The listings subsystem enables operators to manage listings data (also known as Electronic Program Guide, or EPG, 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. This subsystem is sometimes referred to as the EPG subsystem. Listings Distribution Listings data originates from a listings provider, is imported into the Microsoft® Mediaroom branch, and is then distributed to Microsoft Mediaroom clients. The following diagram illustrates how the Microsoft Mediaroom system manages this process end-to-end. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 90 The following steps describe how the listings data from a listings provider is imported into the Microsoft Mediaroom listings subsystem. 1) A listings provider (of the service provider’s choosing) creates a Global Listings Format (GLF)-compliant listings data file. 2) The listings provider copies the listings data file to a secure location to which the service provider has access. 3) Branch operators define a method for securely copying the listings file. They copy the listings data file onto the Server-Facing Branch machine that can be accessed by the ListingsLibrarianWS Web service. Each branch must have its own copy of the listings data. 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 listings subsystem imports the listings data file into its own storage space. Import performs a complete update of the listings data file; the system does not currently support partial updates. Import is always done by the console application Listings Updater. There are two ways to import a listings data file: • Scheduled invocation method. Set up the IPTV Edition Scheduler Windows® service to invoke Listings Updater 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. This is the recommended method for importing a listings file. • Manual import. Invoke the Listings Updater application manually by running it on the command line. This method is not recommended outside of a lab trial, but can be used for an extraordinary maintenance importation or other special situation. 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 Configuring the EPG Import Process (p. 184) in Installation and Configuration Guide. The following diagram provides a close-up look at the interactions between the Listings LibrarianWS Web service and other Microsoft Mediaroom components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 91 1) The Listings Updater application continually queries the ListingsLibrarianWS Web service to determine whether listings data needs to be updated. When Listings Updater detects that a new import has been requested or that channel maps have changed, it reruns the import and listings data generation process. After the Listings Updater application import and listings data generation process completes, it updates the version number maintained by the ListingsLibrarianWS Web service. The ListingsLibrarianWS Web service maintains the version numbers and flags that indicate which data import processes need to be run. 2) The ListingsLibrarianWS Web service keeps track of certain EPG import process flags in the ListingsSettings database. This database is located on the Branch Database machine. The ListingsSettings database is always accessed through the ListingsLibrarianWS Web service. 3) After the EPG import process has completed, the ListingsLibrarianWS Web service also builds and maintains a local cache of listings data. This cache is available to other Mediaroom system components through a virtual directory (Web site) enabled in IIS. 4) Various Delivery Agent Windows services and other EPG-related Web services query the ListingsLibrarianWS Web service directly to obtain the latest listings data version information and the URLs of available data. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 92 5) If the components detect that a new version of listings data is available, the components access the updated listings data from the virtual directory. If the querying component is a Delivery Agent Windows service, the service updates its own local data caches. Listings File Format The listings subsystem uses the Microsoft Global Listings Format (GLF) data model to represent the listings data. The source listings data must be formatted in an XML GLF listings representation that uses a specific schema to ensure data integrity. Using XML representations, the listings 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 Microsoft Mediaroom service operator, or some other party) before Microsoft Mediaroom can import the data. The listings data file contains the program and scheduling information for a specific time period, such as the next 14 days of programming. The file should contain information that is relevant only to that particular period of time and should not contain any scheduling gaps. Avoid leaving unused data in the file, because the memory available on clients for listings data is limited. The listings data file is typically updated (imported) once a day. Avoid frequent updates (imports) of the listings data, because each time the data is updated it must be sent to each client in the network. Listings data is used primarily by Microsoft Mediaroom 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 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 93 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. Microsoft Mediaroom 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. Service collections enable operators to define which services to present to subscribers when they are authorized to view content and when they are not authorized (upsell condition). For example, when creating a VOD service collection, operators define both a primary and secondary set of full-screen and PIP services. The primary services are displayed if the subscriber is authorized to view the VOD asset. They typically contain the feature-length video and picture-in-picture (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. Note The listings subsystem does not manage channel maps, rate packages, or any type of subscriber-specific data preferences. See Also Media Discovery Subsystem (p. 095) DVR Scheduler Subsystem (p. 125) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 94 Media Discovery Subsystem The media discovery subsystem provides private server-facing and public client-facing Web services that process requests for media descriptions. Although the mdws Web service and MDWSPrivate Web service perform the same function, they serve different requestors (Microsoft® Mediaroom clients and the SearchWS Web service, respectively), and may reside in different zones for security purposes. Media descriptions are data sets that contain enough information from the metadata for a given piece of content (for example, a VOD asset) in sufficient detail to enable Microsoft Mediaroom software components to operate on the content (for example, to return information for a search query performed by the subscriber). Each request specifies a piece of content by a GUID known as a “media descriptor.” The mdws Web service contacts the service information subsystem for system information, and then it accesses the Listings Librarian Web service or BranchDB database to retrieve the matching media description. The following diagram shows the types of communication that the media discovery subsystem performs. The following table describes the media discovery subsystem software components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 95 Component Description mdws Web service Receives requests for media descriptions from Microsoft Mediaroom clients. Each request specifies a piece of content (for example, a VOD asset) by a GUID known as a “media descriptor.” The mdws Web service provides clients with the information required to assemble the channel map and Video on Demand screen, which is used to identify and access Microsoft Mediaroom services. The mdws Web service contacts the service information (SI) subsystem to retrieve service information about the content, and then gets listings metadata for the content from the listings subsystem. The mdwsWeb service uses the returned service information and EPG metadata to create a media description for the requested content and delivers it to the Microsoft Mediaroom client. MDWSPrivate Web service Receives requests for media descriptions from the SearchWS Web service. The MDWSPrivate Web service then handles the requests in the same manner as the mdws Web service. vodCatalogWS Web service Provides a client-facing Web service interface through which clients obtain VOD metadata. When a Microsoft Mediaroom client needs to construct a Video on Demand screen, it contacts the vodCatalogWS Web service to obtain a list of VOD assets and categories. The vodCatalogWS Web service contacts the subscriber management subsystem (SMS) to look up the subscriber to determine which assets the subscriber is entitled to view. The vodCatalogWS Web service returns the complete URL of each VOD asset. The vodCatalogWS Web service is not responsible for tracking VOD locations (service information). The vodcatalogWS Web service is installed on a Server-Facing Branch machine. vodCatalogPrivateWS Web service Builds the VOD catalog of assets that display in the Search screen for subscribers. The catalog of assets is the library of content that the subscriber has requested. The client displays these assets together in a listing that is viewable by the subscriber. See Also Listings Subsystem (p. 090) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 96 Search Subsystem (p. 132) Service Information Subsystem (p. 098) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 97 Service Information Subsystem The service information (SI) subsystem is the central directory for all Microsoft® Mediaroom services. The SI subsystem provides Microsoft Mediaroom clients with the information needed to acquire video and data services. Services include live video services, VOD assets, and RDP application services. Microsoft Mediaroom 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. Microsoft Mediaroom 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. Service Information Subsystem Software Components and Data Flow The following diagram shows the SI subsystem software components and how they interact with other Microsoft Mediaroom components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 98 The following table describes the SI subsystem software components. Component Description Service discovery Web service Provides a set of interfaces that enable other Microsoft Mediaroom server machines to access details for each service. BranchDB database Maintains base service information data in an SQL database. Base service information data includes the following: • 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 Microsoft Mediaroom system startup, the client service information handler connects to a bootstrap Web service where it acquires the appropriate service information data. It Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 99 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. 044) RDP Application Subsystem (p. 076) Live TV Subsystem (p. 021) Channel Management Web Service (p. 158) Media Discovery Subsystem (p. 095) Web Service Router (p. 086) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 100 Client Startup Services Microsoft® Mediaroom provides the following services for clients to use while starting up: • bootstrap Web service. Used when clients go through their startup sequence. • Sync Discovery Service Windows® Service. Used by clients during startup or disaster recovery to provide resource locations. • upgradeWS Web service. Used by clients that run a Microsoft Mediaroom Client release prior to 1.6.2 to download upgraded software. Clients that run Microsoft Mediaroom Client 1.6.2 or later use the upgradeWS Web service to locate the server that has the upgraded software files, which are stored on a machine that hosts the clientUpgradeFiles role. • clientUpgradeFiles role. Creates the location for downloadable upgrade software packages for clients that run a Microsoft Mediaroom Client release of 1.6.2 or later. These services are described in the following sections. Bootstrap Web Service The bootstrap Web service is the first Web service that Microsoft Mediaroom clients encounter when they go through the startup sequence. Microsoft Mediaroom clients acquire the URL of the bootstrap Web service by requesting the bootstrap service record from DNS or from the OEM configuration section of the client boot ROM. Interaction of the Bootstrap Web Service with Other Microsoft Mediaroom Components The following diagram shows how the bootstrap Web service interacts with other Microsoft Mediaroom components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 101 Note Microsoft Mediaroom clients begin their startup sequence by acquiring IP connectivity through a supported protocol from a local gateway, such as a DSL router. Currently, Microsoft Mediaroom client software supports only Dynamic Host Configuration Protocol (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 upgradeWS Web service. For more information about the client upgrade process, see Upgrading Devices (p. 582) in Operations Guide. The Microsoft Mediaroom 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, the ELS Web service can optionally redirect the set-top box to a “self-provisioning” RDP application that, for example, prompts subscribers to enter creditcard information, choose subscription packages, and so on. The bootstrap Web service authenticates the Microsoft Mediaroom client and logs it on to the Microsoft Mediaroom system. It then contacts the subscriber management subsystem (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 Microsoft Mediaroom client can acquire configuration data. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 102 Sync Discovery Service Windows Service The Sync Discovery Service Windows service hosted on the Sync and Discovery Server provides clients with the location of resources that they can contact during regular start-up or to recover from a failure. The application that clients use to recover from a failure, known as Disaster Recovery Application (p. 103) (DRA), helps the client restore configuration information and to acquire a new copy of the appropriate version of Microsoft Mediaroom client software. The Sync Discovery Service Windows service sends the client a URL for the appropriate DRA files for all client releases. The Sync Discovery Service Windows service implements a simple protocol based on the trivial file transfer protocol (TFTP) that lets clients specify a GUID so that the Sync Discovery Service Windows service can determine the most appropriate servers to obtain bootstrap information or the DRA for each client. Disaster Recovery Application The Disaster Recovery Application (DRA) is downloaded and executed by the boot ROM on the set-top box when the set-top box recovers from a disaster, on initial start-up of a set-top box when no client software is present on the set-top box, or after a catastrophic set-top box failure. The set-top box boot loader establishes communication with the Sync Discovery Service Windows Service (p. 103) through a URL that is returned by the Sync and Discovery Server, and the appropriate DRA is downloaded to the set-top box. When the set-top box is new and first run, there is no software present, and the DRA partitions and formats the storage device, acquires a bootstrap address, and loads or upgrades the client application as necessary. In a disaster case where the client software has been on the set-top box before and there are existing partitions, the DRA will only reformat the application partition, and will not touch the DVR partition. This means no recordings are lost. For more information, see Client Disaster Recovery (p. 605) in Operations Guide. UpgradeWS Web Service The upgradeWS Web service provides Web services for updating pre-1.6.2 clients, or returns a URL where 1.6.2 or later clients can obtain the appropriate upgrade package. The URL that is returned for 1.6.2 or later clients points to a machine that hosts the clientUpgradeFiles role which has the appropriate files for the client. The URL is created from the following items: Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 103 • Client OEM or make from the client’s certificate. • Client model sent by the client. • Client version from the Service Group Database. The resulting URL is in the following form: http://<clientUpgradeFiles>/<OEM_ID>/<Model_ID>/Application_<version>.dat This URL directs the client to a virtual directory on IIS. For more information, see Upgrading Devices (p. 582) in Operations Guide. ClientUpgradeFiles role The clientUpgradeFiles role creates a virtual directory on a Web server where the upgrade packages for 1.6.2 or later clients are located. Set-top boxes must be able to directly connect to this Web server, as this connection is not made through the Web service router. Clients download the appropriate upgrade package after receiving the package’s URL from the upgradeWS Web service. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 104 Subscriber Management Subsystem The subscriber management subsystem (SMS) provides access to a repository of information about Microsoft® Mediaroom 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. (For information about service groups, see Service Group Subsystem (p. 109).) The SMS includes: • A Microsoft Windows® service that polls for new keys for live TV services. • Web services through which other Microsoft Mediaroom 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 Microsoft Mediaroom service providers can grant default entitlements for individual services (for example, access rights to view a premium channel) and 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 Information The SMS maintains the following information about each subscriber: • Microsoft Mediaroom 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 105 Service providers extend a certain amount of credit for the purchase of billable services to subscribers. The SMS tracks and manages this limit. If a subscriber exceeds the credit limit, rights to any purchasable service are denied until the limit is reset. Microsoft TV provides applications that enable the service provider or the subscriber to reset the credit limit within limits imposed by the service provider’s business rules. The SMS does not collect or hold a subscriber’s billing information, such as a credit card number or payment information, but it does track the subscriber credit limit. Service provider personnel add the subscriber into the service provider’s business system, which then communicates the information to the SMS through the OSS and BSS Web services. The SMS maintains information about the subscriber and the associated devices, with billing information related to each device. Billing Events The SMS keeps track of billable Microsoft Mediaroom 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 Software Components and Data Flow The following diagram shows how the SMS software components interact with other Microsoft Mediaroom subsystems. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 106 The following table describes the SMS software components. Component Description Billing Web service Enables business support systems (BSS) to access subscriber billing events in the service group database. Client rights Web service Manages Microsoft Mediaroom 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 service Enables the live TV acquisition and VOD acquisition subsystems to update keys in the subscriber database. Principal management Web service Enables business support systems (BSS) to manage principals (subscribers, 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 Microsoft Mediaroom clients. Resource management Web Enables BSS systems to manage resources (live services, Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 107 Component Description service VOD assets, and RDP applications) in the service group database. Rights management Web service Enables BSS systems to manage rights in the service group 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, Microsoft Mediaroom 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. Microsoft Mediaroom 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 in the Microsoft Mediaroom OSS/BSS Integration documentation set. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 108 Service Group Subsystem Service groups are a subset of servers in the branch that divide the subscriber management tasks to distribute the processing load and provide a way to perform software upgrades with minimal service interruptions. Service groups enable operators to: • Scale up Microsoft Mediaroom systems to accommodate new subscribers. • Prevent service interruptions while performing system upgrades and other regular system maintenance. Scalability and Load Balancing Microsoft Mediaroom enables operators to add more subscribers by simply expanding their server capacity at their data centers. At the same time, Microsoft Mediaroom service groups enable operators move subscribers among different server pools for load balancing, or to partition their service groups based on any criteria, such as geographic proximity. Microsoft Mediaroom Software Upgrades Service groups support an upgrade methodology that maximizes service “uptime” and business continuity. To maintain service uptime while performing system upgrades, Microsoft Mediaroom 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. Microsoft Mediaroom data migration can be implemented with a fine granularity. A robust database migration tool minimizes the impact of data migration on subscriber experience. For details on database migration, see Installation and Configuration Guide. Service Group Subsystem Software Components and Data Flow The following diagram shows the software components that constitute the service group subsystem as well as the interaction between the service group subsystem and other parts of Microsoft Mediaroom. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 109 Each service group in the service group subsystem is supported by a database of information about accounts and devices assigned to that service group. The service group subsystem also provides a data access layer through which server-facing Web services in the service group access the service group database and a Web service that enables 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 for each service group 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. Because there is no contention among service groups, operators can scale out the Microsoft Mediaroom 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. An operator can deploy so that subscriber accounts are load-balanced evenly among service groups for scalability and best performance. Unless operators specify a service group when adding devices and accounts, Microsoft Mediaroom adds the new principals to a default service group. Operators specify the default service group through the TV Services Management tool, or they can use custom applications that manage service group defaults and data through the OSS Web services. While the branch management Web service enables OSS systems to set the default service group, all subscriber details are managed through the BSS Web services. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 110 See Also Branch Management Subsystem (p. 113) Service Group Database All subscriber group and service group metadata, as well as service and asset store metadata, is stored in the branch database. However, individual subscriber data for each service group is consolidated and stored in the corresponding service group database, which also incorporates subscriber group metadata and non-subscriber metadata for that service group. Subscriber group and non-subscriber metadata are replicated from the branch database to enhance scalability, and for read-only access. Because 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 system. Some service group 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 • Session key authority (replica) • Service information (replica) • Live Config and Cluster Assignment (replica) • SMS: devices and accounts • SMS: group and key (replica) Web Services in Service Groups The service group data access layer is a Windows library that enables server components to access the service group database through Web services in the service group. The following server-facing Web services are deployed in each service group: • dvrRemote • dvrScheduleUpdateService • mdWSPrivate Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 111 • notificationController • sessionKeyAuthorityWS • servicegroupSMSWS • SGepgWS • SGPrivateSessionKeyAuthorityWS • SGTraceLog • subscriberActivityLogDataWS • TServerController • vodCatalogPrivateWS • vodSGBranchWS The following client-facing Web services are deployed in each service group: • bootstrap • clientEdgeMapWS • clientLoggerWS • dvrV2WS • mdws • notificationWS • SearchWS • smsPublic • tsMonitorPublic • Upgrade • userstorePublicWS • vodCatalogWS • vodMapServerWS Service Group SMS Web Service The service group SMS management Web service enables 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 112 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 is stored centrally in the BranchDB database, and then replicated in the appropriate service group database. Instead of relying on Web service communication, however, Microsoft Mediaroom performs database replication through SQL stored procedures. The BranchDB database is managed by the following Microsoft Mediaroom server components: • The TV Services Management tool enables operators to define new service groups in a branch and to manage existing service groups. • The OSS branch management Web service enables OSS applications to retrieve and update service group definitions created by the TV Services Management tool. • BSS Web services enable BSS applications to manage accounts, billing records, grants, offers, and purchases, the details of which are stored in the BranchDB database and replicated as required in the appropriate service group databases. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 113 • The branch service group-facing Web service enables server components in each service group to retrieve information from the BranchDB database. For example, the bootstrap Web service accesses the BranchDB database when a client in the same service group starts. For details on the client bootstrap process, see Bootstrap and Redirection (p. 114). Bootstrap and Redirection When a device bootstraps to the server for the service group that the subscriber’s account was associated with during the previous bootstrap operations, the device checks the SMS to determine the current status of the subscriber account the device is assigned to. If the SMS indicates that the device does not exist in the current service group, the bootstrap server consults with the branch to decide whether the subscriber’s account is in another service group. If the account is in the same service group it was in during the previous bootstrap operation, the bootstrap server goes through the external login system to register the account. If the account is in a different service group than during the previous bootstrap operation, 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 device then bootstraps again, this time with the correct service group. Branch Database Tables The branch database includes tables for the following: • Asset store • Branch management • Live config state • Notification (stored procedure) • Session key authority • Service information • SMS (subscription group and key) • User store (global device values) • VOD Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 114 Web Services in the Branch The following server-facing Web services are deployed in the branch: • BranchMgmtWS • clientEventLogDataWS • EdgeControllerFromEdgeWS • epg Web service • LiveBackendUpdate • sessionKeyAuthority_KeyGenerator • sessionKeyAuthorityWS • serverEventLogDataWS • vodBranchWS • vodControllerWS Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 115 Notification Subsystem The notification subsystem is a general-purpose mechanism for delivering messages from other Microsoft® Mediaroom subsystems and services to Microsoft Mediaroom clients. Messages are typically delivered: • To inform clients that system information (such as listings) has changed and can be downloaded from Microsoft Mediaroom subsystems. • To inform clients of state changes, such as entitlement changes. • To communicate information to subscribers, in the form of short messages that appear on the subscriber’s screen. • To tell a client to upload diagnostic information to the logging subsystem. Each message can be scheduled for delivery at a specific time with an expiration time interval. In addition, you can add up to ten buttons to a notification message that allow users to tune to a specified channel or service. For details on configuring buttons in notification messages, see the related information in "UI Notification Web Service" in OSS Web Service Reference in the Microsoft Mediaroom OSS/BSS Integration documentation set. 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 the notificationController Web service, through which Microsoft Mediaroom subsystems can post messages for delivery. Microsoft Mediaroom provides Web services (for example, UI notification Web service and diagnostics notification Web service, and High Priority Notification Web Service) through which operations support systems (OSS) can post notification messages (packaged as XML data) for clients. For details on the OSS Web services that provide access to the notification subsystem, see UI Notification Web Service (p. 164), Diagnostics Notification Web Service (p. 159) and High Priority Notification Web Service. Notification Subsystem Software Components and Data Flow The following diagram shows how the notification subsystem interacts with other Microsoft Mediaroom subsystems. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 116 The following table describes the notification subsystem software components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 117 Component Description Notification delivery Windows service Delivers messages from Microsoft Mediaroom subsystems to Microsoft Mediaroom clients over UDP. It also retrieves messages from the notification controller for delivery and attaches corresponding client information (client ticket, and IP and NAT addresses and ports) from the service group database. The notification delivery Windows service accesses the service group database through the notification controller Web service. Depending on how the notification subsystem is configured during installation, messages are either delivered on a unicast or multicast address. Multicast notifications (when enabled) are only used for system messages, like EPG and service information changes. Clientspecific, subscriber-specific, or group–specific messages, like channel map changes, are always sent by unicast. In general, using multicast addresses provides better performance. The notification delivery Windows service also maintains regular communications with clients over a UDP “heartbeat” protocol. This enables the service to handle client status changes and keep NAT ports open if the client resides behind a residential gateway. The notification delivery Windows service stores the client status changes in the service group database. The notification delivery Windows service runs on the same host (the Client Gateway machine) as the Web service router. Clients receive the addresses of two hosts running the notification delivery Windows service from the client notification Web service. Clients should maintain communications with at least two notification delivery Windows services. Notification controller Web service Server-facing Web service. Enables Microsoft Mediaroom subsystems to query the service group database, set up messages to deliver to Microsoft Mediaroom clients, or cancel pending messages. Client notification Web service Provides clients with addresses of machines running the notification delivery Windows service. Uses a random algorithm for selecting two notification delivery Windows services for any given Microsoft Mediaroom client that logs on to the system. Clients get the addresses of machines running the client notification Web service from the bootstrap Web service. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 118 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. Message Handlers The Microsoft Mediaroom client is equipped with message handlers for messages that Microsoft Mediaroom services may generate. Microsoft Mediaroom 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. Message Delivery and Heartbeat Protocol Microsoft Mediaroom 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 Microsoft Mediaroom subsystem or from a custom application, the message details are stored in the service group database. Under normal conditions, the notification delivery Windows service polls the notification controller Web service for message delivery jobs every ten seconds. This interval may be shorter if the notification subsystem has no notifications to deliver. The only time this interval is longer than 10 seconds is when the number of messages in the delivery queue exceeds the maximum of 4000. If the maximum number of messages is Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 119 reached, the system sends messages to clients from the buffer. The notification subsystem requests 1000 messages at a time from the controller. The controller sends all of its messages, up to 1000 per request. 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 timestamp on the message itself. This timestamp is signed by the sender to guarantee authenticity. When the message is received, the recipient compares the difference between the transmission and reception timestamps 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 Microsoft Mediaroom system can be verified. Although these messages cannot be impersonated or modified, they can be intercepted and read, so they include no personally identifiable or secret information. Microsoft Mediaroom 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 Microsoft Mediaroom 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 an acknowledgment from the notification delivery Windows service. If this happens, or if the client’s list of services is empty, the client contacts the client notification Web service to start from the beginning. The notification delivery Windows service listens on UDP port 0xabba (43962). If a client resides behind a NAT residential gateway, it transmits messages over a dynamically received port. The client includes its NAT IP address and UDP port when it sends heartbeat UDP packets. The notification delivery Windows service stores this information in the service group database through the notification controller Web service. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 120 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. Client Startup Communications with the Notification Subsystem 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 starts up. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 121 High Priority Notification Subsystem The following diagram describes the relationship of the components of the High Priority Notifications system. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 122 Introduction The Microsoft Mediaroom High Priority Notification Web Service provides timely delivery of messages to Microsoft Mediaroom clients in a timely manner within a specified latency constraint. Notifications may be targeted to all clients in a single account with a single API call. Notifications are delivered in a timely and best effort manner. Timeliness and reliability of message delivery is dependant upon individual server response time and delays induced by the message's network path and the reliability of the underlying network and infrastructure. Architecture The following sections describe the architecture of the high-priority notification subsystem. Branch Routing Cache For SP3.2, the push model was added to the Notification Subsystem in addition to the pull model. The OSS layer now routes messages directly to the NDS servers. As a means to increase the speed of processing of branch-to-service and account-to-device mappings, and because only the NDS is aware of the devices for which it is responsible, a cache is created that contains account information, device IDs for each account, and service group information for all the accounts in the branch. Multicast to NDS in the Service Group All NDSs in the same service group listen to the same multicast IP address. Messages are sent to the multicast IP address of the NDS of the service group to which the destination clients belong. Each message appearing on an NDS server's multicast IP address is parsed for its destination device ID. If the destination device belongs to a particular server, the server sends a unicast message to the intended destination device. If the destination device does not belong to the server, it simply ignores the message. NTP-based Clock Synchronization Because notification messages need to be delivered to the destination device within the specified latency constraint, all the servers and the devices are synchronized to the NTP clock. Notification messages are discarded when they exceed the specified latency constraint. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 123 As a result, all the machines shown in the diagram under the High Priority Notification Subsystem (p. 122) section must be able to access the NTP servers. Redundant Message Handling at the Client Mediaroom clients maintain persistent connections with multiple NDS servers and may receive multiple copies of the same message sent by more than one server. Each message has a unique message ID (GUID); the client ignores all but the first message with a specified GUID. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 124 DVR Scheduler Subsystem The DVR scheduler subsystem schedules and manages digital video recordings for all Microsoft® Mediaroom 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 Microsoft Mediaroom client sends the recording information to the DVR scheduler subsystem. The DVR scheduler subsystem checks for conflicts with other recording schedule requests for the client. Any hard padding added to the schedule by the operator or subscriber is included as part of the check for scheduling conflicts, while soft padding added by the operator is discarded if it causes a conflict. If no conflicts are found, the DVR scheduler subsystem stores the schedule in the DVR database. If the IPTV Edition DVR Scheduler Updater Windows® service detects a recording conflict, the conflicting schedule information is sent back to the Microsoft Mediaroom client, which then prompts the subscriber to resolve the conflict. The DVR scheduler subsystem also provides a remote recording Web service, dvrV2, 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, remoteDVR, which would arrange for the appropriate set-top box to make the recording. Each client maintains its own schedule of programs to record, and starts and stops recordings based on that schedule. Clients periodically communicate with the DVR scheduler subsystem to verify that their schedules are up-to-date. The DVR scheduler subsystem can also notify a client that it needs to refresh its schedule (for example, when a recording is scheduled remotely through the Web service). The client stores recorded programs in 64 MB file “chunks.” A single recording consists of multiple chunks. The client also creates an index file for each recorded program to facilitate trick modes and program positioning. Metadata that is related to the program is also stored on the hard disk drive. Note Recording schedules are tied to services, not channel numbers. If a channel map is reconfigured or if a subscriber reorders the program guide, a scheduled recording still records the correct program. For example, a recording that is targeted at a program on the ESPN service still correctly records an ESPN program even after a channel number change. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 125 DVR Scheduling in a Multiple Set-Top Box Environment Each home is allocated a certain number of data “streams.” The number of streams allocated for a home is determined by the Microsoft Mediaroom service provider. The number of possible streams is determined by the amount of bandwidth available to the home. The amount of available bandwidth is different for each geographic area and service provider. The number of streams determines the number of live broadcasts and PPV offerings that the household can watch or record simultaneously. (A set-top box tuned to a recorded show does not use a stream.) If a household has n streams, the subscriber can record or watch a total of n shows at once. When a subscriber tries to schedule a show, the DVR scheduler subsystem determines whether the household has a stream available at that time. If all streams in the household are already scheduled 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 canceling one of the already-scheduled recordings or aborting the attempt to schedule a new recording. For more information, see Multiple Client Households (p. 181). DVR Scheduler Subsystem Software Components and Data Flow The following diagram shows how the DVR scheduler subsystem interacts with other Microsoft Mediaroom software components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 126 The following table describes the DVR scheduler subsystem software components. Component Description DVR Schedule Updater Windows service Provides activities used to resolve DVR scheduling conflicts. The role associated with this Windows service is dvrScheduleUpdaterService, a Server-Facing Service Group role that can be installed on multiple machines. dvrV2 Web service Provides the client-facing Web services for digital video recording. The role associated with this Web service is dvrV2WS, a Client-Facing Service Group role. In a multiple set-top box household, each set-top box communicates with the DVR scheduler subsystem independently, and this subsystem ensures that the set-top box with a hard disk drive receives all scheduling requests. For more information about multiple set-top box households, see Multiple Client Households (p. 181). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 127 User Store Subsystem The user store subsystem enables Microsoft® Mediaroom components to save and retrieve persistent information as name/value pairs. The information types that Microsoft Mediaroom 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 to maintain shared state information between Microsoft Mediaroom 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 Microsoft Mediaroom components. For simplicity, the diagram does not show secondary components that do not directly relate to the user store subsystem. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 128 The following table describes the user store subsystem software components. Component Description User store public Web service Web service interface through which client applications can set or get name/value pairs. The Microsoft Mediaroom client accesses this Web service to save state information. The user store public Web service ensures that only the client application that saves data can retrieve it. (userstorePublicWS) User store library DLL through which server-facing custom applications can set or get name/value pairs. See Also High-Level Architecture (p. 013) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 129 Session Key Authority Subsystem The session key authority subsystem generates symmetric session key authority (SKA) session keys, and then disseminates them to authorized servers in the Microsoft® Mediaroom branch. The following illustration shows the structure of the session key authority subsystem. The following table describes the session key authority subsystem components. Component Description SKA Key Generator Windows service Periodically generates symmetric server session keys for the various queues defined in the session key authority database tables. Session key authority database tables (in the BranchDB or ServiceGroupDB databases) Contains key queues that store protected (encrypted and signed) session keys and queue definitions. sessionKeyAuthorityWS Web service Web service through which authorized branch servers obtain information about available key queues and obtain session keys from the queues. The servers verify the authenticity of the keys before using them. SKA Loader A library associated with each authorized branch server that enables the branch serve to communicate with the Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 130 Component Description sessionKeyAuthorityWS Web service. The SKA Loader maintains a local cache of the session keys that the server obtains from the key queues. All SKA session keys are protected by headend certificates and asymmetric cryptography. Note The sessionKeyAuthorityWS Web service does not have access to the certificates that protect the keys it retrieves from the session key authority database tables, so the service can run in either an application or database security tier. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 131 Search Subsystem The search subsystem supports the Microsoft® Mediaroom 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 Microsoft Mediaroom subscriber interface. Subscribers can find programs to watch by using the remote control to enter the title of the program or the name of a person, such as an actor or director. Subscribers enter the search criteria using one of the following methods: • Pressing the remote control's number keys repeatedly to display the desired character on their screen, similar to the way text is entered on a cellular phone (also known as “triple tap”). • Using the arrow keys and OK button to select characters in the on-screen keyboard. 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, PPV, and VOD assets that match the search criteria. Subscribers can also limit their searches to Titles, People, and VOD-only. Subscribers can select the show they want from the list and then watch or purchase it. The following diagram illustrates how the SearchWS Web service interacts with other Microsoft Mediaroom software components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 132 The following table describes the search subsystem software components. Component Description SearchWS Web service Enables Microsoft Mediaroom clients to obtain media descriptions from the MDWSPrivate Web service that match various criteria for content (live TV, PPV, and VOD) that the subscriber has entered. mdws Web service Receives requests for media descriptions from Microsoft Mediaroom clients. Each request specifies a piece of content (for example, a VOD asset) by a GUID known as a “media descriptor.” The mdws Web service provides clients with the information required to assemble the channel map and Video on Demand screen, which is used to identify and access Microsoft Mediaroom services. The mdws Web service contacts the service information (SI) subsystem to retrieve service information about the content, and then gets listings metadata for the content from the listings subsystem. The mdwsWeb service uses the returned service information and EPG metadata to create a media description for the requested content and delivers it to the Microsoft Mediaroom client. MDWSPrivate Web service Receives requests for media descriptions from the SearchWS Web service. The MDWSPrivate Web service then handles the requests in the same manner as the mdws Web service. vodCatalogPrivateWS Web service Builds the VOD catalog of assets that display in the Search screen for subscribers. The catalog of assets is the library of content that the subscriber has requested. The client displays these assets together in a listing that is viewable by the subscriber. The search subsystem periodically requests media descriptions from the MDWSPrivate Web service (in Media Discovery Subsystem (p. 095)), 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 subsystem communicates directly with Microsoft Mediaroom clients, it is typically deployed on a Client Gateway machine. For more information on using the Microsoft Mediaroom client search feature, see Subscriber’s Guide in the Microsoft Mediaroom Client documentation set. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 133 See Also Media Discovery Subsystem (p. 095) Asset Store Subsystem (p. 088) Listings Subsystem (p. 090) Service Information Subsystem (p. 098) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 134 Logging Subsystem The logging subsystem manages various events within the Microsoft® Mediaroom servers and Microsoft Mediaroom clients. These events cause the affected software components to generate messages and send them to the logging subsystem for processing and storage. The following types of events are logged by the Microsoft Mediaroom logging subsystem: • 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 a Microsoft Mediaroom server or client; for example, a service has stopped. • Performance counters. Performance metrics are measured and reported. • Audit events. Events are received that track changes made from the TV Services Management tool or OSS/BSS APIs. Components of the logging subsystem are installed on all Microsoft Mediaroom server machines. These components route events to different storage entities based on a set of routing rules, configured in the logconfig.xml file. Routing rules are based, in part, on the type of event to be logged. Depending on the type of event, the routing destination may be: • A local Windows® Events Log. • A local text file. • A centralized SQL database. • A remote debug console. • A centralized Microsoft Operations Manager (MOM) console. Diagnostics Client diagnostics information such as crash logs enable service providers to determine the cause of set-top box failures. 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 Microsoft Mediaroom client. Service providers can use this information to improve customer marketing campaigns, advertising sales, and relationships with networks. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 135 Activity Log Information Flow The following figure describes the flow for logging subscriber activity events in the Microsoft Mediaroom system. 1) As subscribers perform prescribed tasks on the client, the client automatically logs an event containing details about the task in its local activity logging cache. 2) When the client accumulates 500 events, it uploads the content to the logging framework on the Microsoft Mediaroom 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 specific to each service group. Each service group has its own subscriber activity event logging database that contains only events from clients serviced by that branch. Logged Subscriber Activities Microsoft Mediaroom client creates a logging event when the subscriber: • Tunes the set-top box to a new channel. Note By default the set-top box must remain tuned to the channel for more than 20 seconds for an event to be logged. 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 136 • Purchases a PPV event. • Launches or closes the browse panel. • Launches an RDP application. • Disconnects from a launched RDP application. • Navigates away from a launched RDP application. • Transitions to a new trick state, such as fast-forward, play, or rewind. • Runs a client-resident application, such as the menu or the program guide. After the subscriber activity event log data is uploaded, operators can run reports, analyze the data, and use the information to help plan and deploy additional services. For more information on the contents of individual subscriber activity events, see Operations Guide. System Events All Microsoft Mediaroom software servers 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. Event Information 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 Microsoft Mediaroom documentation. • Event severity. • Critical error. A critical system problem that prevents the Microsoft Mediaroom system from functioning. • 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 event indicates 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 137 • Information. An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, an Information event is logged. • Debug. An event that assists Microsoft support personnel in the debugging of the code execution path on development workstations. These events are suppressed in a Production environment. • Universal date and time that the event occurred. • Computer on which the event occurred. • Application domain. .NET application domain of the component that generated the event. • Exception details. Exception type, exception message, stack trace, and other lowlevel details about the event. • Process Id. PID of the process that generated the event. • Thread Id. ID of the thread that generated the event. Event Storms During an “event storm” the logging subsystem accumulates and consolidates similar system 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 second and it has more than 1000 outstanding events to process. These thresholds are configurable and ESDC can be turned off. Service providers can customize which event stores they maintain in their system. They can also define which events or event groups are sent to each event store. For details on configuring the logging framework, see Operations Guide. Performance Counters As Microsoft Mediaroom 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 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 138 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 Microsoft Mediaroom 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. Audit Events Audit events are useful to service providers in determining who has accessed the system and for what purpose. Logging Subsystem Software Components and Data Flow The following diagram illustrates how the logging subsystem components are distributed across the Microsoft Mediaroom system. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 139 The following table describes each of the software components in the logging subsystem. Component Description Client logger Web service Handles events raised by Microsoft Mediaroom clients in response to subscriber activities and passes all events to the local log engine. The 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 140 Component Description 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 metric 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 diagnostic event sink Directs client diagnostic events to an external client diagnostics event sink agent Web service. Note Microsoft Mediaroom 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 OSS Web Service Reference in the Microsoft TV Microsoft Mediaroom OSS/BSS Integration documentation set. logdata Web service Receives log dumps from the SQL sink and writes them to the centralized subscriber activity log database and event log databases. Subscriber activity log database Contains subscriber activity events such as channel changes, trick mode access, and application starts. Subscriber activity logs help 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 Microsoft Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 141 Component Description Mediaroom 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 database Contains the server events. Events can be either 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 Microsoft Mediaroom 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 history database Contains historical subscriber activity logs. See Also High-Level Architecture (p. 013) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 142 Client Management Subsystem The client management subsystem facilitates the updating and provisioning of the Microsoft® Mediaroom 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 for devices that run a release prior to Microsoft Mediaroom Client 1.6.2 (1.6.2). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 143 The following diagrams show the software components of the client management subsystem for 1.6.2 or later clients. The first diagram illustrates the bootstrap process: The following diagram shows the DRA process: Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 144 The following diagram illustrates the upgrade process: The following table describes the software components of the client management subsystems. Componen t Description bootstrap Web Service The first service that all Microsoft Mediaroom clients encounter when they go through their startup sequence. The bootstrap Web service authenticates the Microsoft Mediaroom client and logs it on to the Microsoft Mediaroom system. It then contacts subscriber management subsystem (SMS) to determine the subscriber’s level of service, and returns a list of URLs for Web services (terminal service monitor, client upgrade, and so on) from which the client acquires configuration data. For more information on bootstrap Web service, see Bootstrap Web Service (p. 101). For more information on SMS, see Subscriber Management Subsystem (p. 105). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 145 Componen t Description upgradeWS Web service When a client is authenticated— at startup 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 resolved software version for the device, the bootstrap Web service returns an upgrade message that contains the URL of the upgradeWS Web service. For devices that run a Microsoft Mediaroom Client release prior to 1.6.2, the upgradeWS Web service downloads the stored client software to devices that require upgraded software. For devices that run Microsoft Mediaroom Client 1.6.2 or later, the upgradeWS Web service constructs a download link to send to the client. (The URL for this link is constructed with information about the OEM ID obtained from the client certificate, the model ID that the client reported, and the device software version that was resolved from the ServiceGroupDB database.) The URL that is returned to the client points to the machine that hosts the clientUpgradeFiles role from which the requesting client can download the appropriate client image. The URL is in the following format: http://<clientUpgradeFiles>/<OEMid>/<modelID>/Application_<version>.da t where clientUpgradeFiles is the address of the machine and <OEMid>/<modelID>/Application_<version>.dat is the path and upgrade file for the client to download. For more information, see Client Upgrade (p. 180). Sync Discovery Service Windows service The Sync Discovery Service Windows service provides clients with a Disaster Recovery Application (p. 103) (DRA) that they can run at startup when they are recovering from a failure. For more information on the Sync Discovery Service Windows service, see Sync Discovery Service Windows Service (p. 103). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 146 Componen t Description Sync and Discovery Server The “Sync Server” portion of the Sync Discovery Service Windows Service provides a client with the Disaster Recovery Application (DRA) when the client cannot boot normally, or when the client has no software at all, such as when a new client is first connected. If a client cannot bootstrap and contact the Microsoft Mediaroom server machine that contains the client upgrade files, the client is diverted to the Sync and Discovery Server to obtain the DRA. The “Discovery Server” portion of the Sync Discovery Service Windows service provides a client with the location of resources that it can contact during regular start-up, or to recover from software failure, should it occur. ClientFacing Service Group The Client-Facing Service Group machine hosts the upgradeWS Web service and the upgrade files for clients that run a Microsoft Mediaroom Client release prior to 1.6.2. IIS Cluster The IIS cluster, or another machine that hosts the clientUpgradeFiles role, downloads the stored client software to 1.6.2 or later set-top boxes that require upgraded software. Only the files for a particular version that need updating are sent to replace the old versions on the set-top box. When a client is authenticated— at startup 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 resolved software version for the device, the bootstrap Web service returns an upgrade message that contains the URL of the IIS cluster machine with the clientUpgradeFiles role that has the upgrade files the set-top box needs. For more information about client upgrades, see Upgrading Devices (p. 582) in Operations Guide. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 147 NTP Server The Microsoft® Mediaroom system uses Network Time Protocols (NTP) to synchronize time between clients and servers as well as between servers. By using NTP, senders and receivers can establish a correct and consistent interpretation of timestamps. Microsoft Mediaroom clients use an NTP time source. Microsoft Mediaroom 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 timestamp, can be assigned to network validation and resource access requests. Note The NTP source should exclude leap seconds to reduce the risk of platform problems that could result from their insertion. 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 of coordinating clocks between the source and sink of the audio/video (A/V) information; otherwise the receiver would play back at its own data rate. Significant differences in data rates can lead to frame repeats or drops, and eventually to under running or overflowing the network reception buffer from the source. In a traditional broadcast system, clients and servers cannot 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 148 The Microsoft Mediaroom 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). Given that the Microsoft Mediaroom environment has two distinct time sources, NTP and the Windows Time service, and that both are required, it is necessary for the forest root-level domain controller to synchronize with an authoritative time source that is external to the Windows infrastructure. This is important because various elements of the Microsoft Mediaroom infrastructure are time dependent, thus requiring that the Microsoft Mediaroom external time source and the Windows domain time source to remain synchronized for sustained operation of the Microsoft Mediaroom system. Maintaining A/V Timing Timestamps are used to deliver A/V samples at the correct time as well as for set-top box buffer management. In the Microsoft Mediaroom 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 can cause an A/V buffer underflow or overflow in the set-top box. Because the Microsoft Mediaroom 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 thereafter begin polling once every 64 seconds. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 149 Client Authentication and Rights Interpretation Each Microsoft Mediaroom client is authenticated using certificates. For the certificate-based client authentication to work properly, client and authentication servers must be timesynchronized. 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 A/V content without interruption, the branch servers and clients must be time-synchronized. Server Authentication Microsoft Mediaroom 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 Microsoft Mediaroom 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 150 TV Services Management Tool Microsoft® Mediaroom operators use the TV Services Management tool to configure and administer all Microsoft Mediaroom 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 Internet Information Services (IIS) server and hosted by Microsoft Internet Explorer. The IIS server handles management actions by interacting with the Web service interfaces of the Microsoft Mediaroom servers. This configuration enables Microsoft Mediaroom operators to configure multiple Microsoft Mediaroom servers in a simple, coordinated manner. For example, when an operator adds a live video service, the TV Services Management tool updates the databases for the related subsystems. Separate configuration and synchronization are unnecessary. For information about starting and operating the TV Services Management tool, see Operations Guide and TV Services Management Tool Reference. TV Services Management Tool Pages and Associated Tasks You use the pages of the TV Services Management tool on the Live Backend Management machine as follows to create Microsoft Mediaroom services. TV Services Management tool page Configuration tasks Quick Search Search tool that is used to find clusters, servers, processes, or services managed by the Live Backend Management machine. Dashboard Display the current status of the clusters, servers, processes, or services managed by the Live Backend Management machine. Clusters Create a logical grouping of the Acquisition Servers that are managed by the Live Backend Management machine. Servers Add and manage Acquisition Servers to host live TV and music services. Processes Add and manage processes containing one or more ongoing Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 151 TV Services Management tool page Configuration tasks tasks that must be performed by the same Acquisition Server Services Add and manage live TV and music services. You use the pages of the TV Services Management tool on the Branch Management machine as follows to manage Microsoft Mediaroom. TV Services Management tool page Configuration tasks Live Management Deploy live TV services from the Branch Management machine. Channel Map Manage service collections, channel maps, packages, offers, and grants, and deploy channel maps to subscriber groups. Modify validation rules and media profiles for VOD assets and import and deploy the assets to the Microsoft Mediaroom system. VOD Management Applications Subscriber Management Add a new RDP application or URL service to the Microsoft Mediaroom system and modify or delete an existing RDP application. Manage subscriber accounts, devices, and groups. You can either use the Subscriber Management pages to manage Microsoft Mediaroom subscriber information, or you can use another account management tool that integrates Microsoft Mediaroom with your business systems. If you use the Subscriber Management pages to manage subscriber information, you must configure a subscriber account for each household that accesses Microsoft Mediaroom 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. A subscriber can be associated with more than one subscriber group; however, only one of the subscriber groups assigned to a subscriber account should have an assigned channel map. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 152 TV Services Management tool page Configuration tasks PPV Management Configure Pay Per View (PPV) assets and add new PPV service collections. TimeShift Manage the TimeShift Recording Servers and enable services for Restart Anytime. Note This link is available after you install Microsoft Mediaroom Server 1.1 SP3.2 CP2. DTT Management Create and manage new digital terrestrial television (DTT) services. Live to VOD Configure and manage recording live TV streams that are converted to VOD assets for deployment through the VOD subsystem. Settings Configure parental control, RDP applications, subscriber activity logging, and various other settings for Microsoft Mediaroom servers and clients . See Also Multiple and Simultaneous Interactions with TV Services Management Tool (p. 153) Multiple and Simultaneous Interactions with TV Services Management Tool When users attempt to modify the same 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. There are different models for concurrency control. The TV Services Management tool follows the last-in-wins model to manage concurrency. In this model, additions and changes that are being written to the database are unavailable to users only while the database is updated. No effort is made to compare updates against the original record. When you save your updated information, the record is simply written out, potentially overwriting any changes made by other users since you last refreshed the records. For example, if several customer service representatives (CSRs) are updating subscriber records and two of them are working on the same record, the information is updated based on the changes made by the last person who saved the data. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 153 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: 1) User A fetches a record from the database. 2) User B fetches the same record from the database, modifies it, and writes the updated record back to the database. 3) 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 154 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. The following table provides brief descriptions of and links to more information about each OSS Web service. Web Service Description Backend Blackout Management Web Service (p. 157) (ossBackendBlackout) Enables OSS systems to manage service substitutions, also known as “blackouts,” at the backend. Blackout Management Web Service (p. 157) (ossBranchBlackout) Enables OSS systems to manage service substitutions, also known as “blackouts," at the branch. Branch Management Web Service (p. 158) (ossbranch) Enables applications to manage the configuration of service groups at a branch. For details on service groups, see Service Group Subsystem (p. 109). Channel Management Web Service (p. 158) (osschannel) Enables OSS systems to manage channel maps and media descriptions, and to assign channel maps to subscriber groups. Content Distribution Web Service (p. 159) (ossContentDistributionWS) Enables client applications to configure and monitor the VOD content distribution system. Client Configuration Web Service (p. 159) (upgrade) Enables service providers to target the software upgrades of Microsoft Mediaroom clients. Diagnostics Notification Web Service (p. 159) (Diagnostics) Enables OSS systems to send requests for diagnostics information through the notification subsystem to all Microsoft Mediaroom clients that are associated with a specific account. Emergency Alert System Web Service (p. 161) (EAS) Enables service providers to send alert messages to subscriber set-top boxes, interrupting whatever programming the Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 155 Web Service Description subscribers may be watching. EPG Web Service (p. 161) (ossepg) Enables Web clients to fetch information about the program schedule. Fingerprint Web Service (p. 161) (fingerprint) Enables the service provider to place a "fingerprint" on live video services to identify the source of pirated content. High-Priority Notification Web Service Enables service providers to send short, timesensitive messages to subscribers. (p. 161) (ossHighPriorityNotificationWS) Live Anytime Web Service (p. 162) (ossLiveToVod) Enables service providers to write custom applications that monitor and configure the Live Anytime subsystem. Live Deployment Web Service (p. 162) (ossLiveDeploymentWS) Enables operators to assign and reassign live services to clusters in a branch. PPV Management Web Service (p. 163) (ossppv) Enables OSS systems to manage the deployment of PPV assets. Remote Recording Web Service (p. 163) (ossremoterecord) Enables Web clients to remotely schedule recordings and modify previously scheduled recordings. Restart Anytime Web Service (p. 164) (ossTimeShift) Enables operators to manage time-shifted offerings. Service Substitution Web Service (p. Enables service providers to schedule service substitution ("blackout") events. 164) (ossServiceSubstitution) UI Notification Web Service (p. 164) (UI) Enables OSS systems to deliver through the notification subsystem short messages that appear on the screens of Microsoft Mediaroom clients. URL Management Web Service (p. 165) (ossurl) Enables service providers to create and modify special services based on Browser applications and Web content. VOD Backend Management Web Service (p. 166) (ossVodBackendWS) Enables the TV Services Management tool and other operations support systems (OSS) to Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 156 Web Service Description manage VOD asset importation at VOD backends. VOD Branch Management Web Service (p. 166) (ossVodBranchWS) Enables the TV Services Management tool and other operations support systems (OSS) to manage VOD asset deployment at VOD branches. Backend Blackout Management Web Service The backend blackout management Web service (ossBackendBlackout) enables OSS systems to manage service substitutions at the backend. (Service substitutions are also known as “blackouts.”) This Web service is mostly superseded by the service substitution Web service (ossServiceSubstitution) as of release 1.1 SP3.1, but it still provides some functionality. Note A number of different Web services must be used in concert to create and manage substitution events. For details on the backend blackout management Web service API, see "Real-Time Service Substitution" in OSS/BSS Integration Guide in the Microsoft® Mediaroom OSS/BSS Integration documentation set. Blackout Management Web Service The blackout management Web service (ossBranchBlackout) enables OSS systems to manage virtual channels for service substitution events. (Service substitutions are also known as “blackouts.”) In previous releases, this Web service provided more functionality related to service substitutions; however, as of release 1.1 SP3.0, this functionality has been superseded by the service substitution Web service. Note A number of different Web services must be used in concert to create and manage substitution events. For details on the backend blackout management Web service API, see "Real-Time Service Substitution" in OSS/BSS Integration Guide in the Microsoft Mediaroom OSS/BSS Integration documentation set. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 157 Branch Management Web Service The branch management Web service (ossbranch) enables applications to manage the configuration of service groups at a branch. Note Service groups can only be created through the server layout on the branch (see Configuring the Server Layout Files (p. 089) in Installation and Configuration Guide). The branch management Web service supports only reading existing service groups and assigning an existing service group to use as the default service group for new accounts. For more details on managing and migrating service groups, see Managing Service Groups (p. 032) in Operations Guide. For more information about the branch management Web service, see “Branch Management Web Service” in OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Channel Management Web Service The channel management Web service (osschannel) enables OSS systems to manage channel maps and media descriptions, and to assign channel maps to subscriber groups. The following diagram shows how the channel management Web service interacts with other Microsoft Mediaroom software components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 158 Content Distribution Web Service The content distribution Web service (ossContentDistributionWS) enables client applications to configure and monitor the VOD content distribution system. Using this Web service, client applications developed by service providers can fetch information about content distribution servers, receivers, tasks, and addresses. Client applications can also use this method to remotely schedule content distribution tasks. For more information about content distribution, see “Content Distribution Web Service” in the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Client Configuration Web Service The Client Configuration Web service (upgrade) enables you to start and stop mass upgrades of multiple set-top boxes. This Web service operates first in conjunction with the Principal Management Web Service (p. 171) to determine which boxes need to be upgraded, and then upgrades the set-top boxes during a time window determined by the service provider. With the Client Configuration Web service, the following targeted software upgrades can be made, at the service provider's discretion: • To a single device. • To all the devices or accounts in a special upgrade group. • To all the devices in a service group. • To all the devices in a branch. The ability to specify which devices or group of devices receive an upgrade enables the service provider to maintain a version hierarchy of client software. For more information about client configuration, see “Client Configuration Web Service” in the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Diagnostics Notification Web Service The diagnostics notification Web service (Diagnostics) enables OSS systems to send requests for diagnostics information through the notification subsystem to all Microsoft Mediaroom clients associated with a specific group or subscriber account. The notification subsystem delivers the request messages to the Microsoft Mediaroom clients over UDP/IP. The Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 159 Microsoft Mediaroom 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 Microsoft Mediaroom software components. See Also Notification Subsystem (p. 116) Logging Subsystem (p. 135) Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 160 Emergency Alert System Web Service The emergency alert system (EAS) Web service (osseas) enables service providers to send alert messages to subscriber set-top boxes, interrupting any programming that subscribers are watching. For more information about the EAS, see “Emergency Alert System Web Service” in the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). EPG Web Service The EPG Web service (ossepg) 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. 163). For more information about the EPG Web service, see “EPG Web Service” in the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Fingerprint Web Service The fingerprint Web service (fingerprint) enables service providers to add a visible identifier, or “fingerprint,” to live video services in a location specified by the service provider. The fingerprint is a short text string that identifies the specific set-top box that is displaying the video service. If the content is copied and distributed, the fingerprint can be used to identify the subscriber who copied it. Fingerprints are turned on and off on a per-service basis. If fingerprinting is enabled for a service, every set-top box tuned to that service will periodically display the set-top box's MAC ID code. The service provider can control how often and where on the screen the ID code is displayed. The service provider can also choose whether to display the fingerprint for one or more seconds, or just for a single frame. For more information about fingerprints, see “Fingerprint Web Service” in the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). High-Priority Notification Web Service The high-priority notification Web service (ossHighPriorityNotificationWS) enables service providers to send short, time-sensitive messages to subscribers. This Web service prioritizes Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 161 speed over reliability; if necessary, the Web service discards a message rather than deliver it after a long delay. This contrasts with the UI notification Web service, which prioritizes reliability and flexibility over speed of delivery. For more information about high-priority notifications, see “High Priority Notification Web Service” in the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Live Anytime Web Service The Live Anytime Web service (ossLiveToVod) enables service providers to write custom applications that monitor and configure the Live Anytime subsystem. The Live to VOD subsystem automatically generates and deploys VOD assets from the programming on live service groups. The following diagram shows how the Live Anytime Web service interacts with other Microsoft Mediaroom software components. Live Deployment Web Service The live deployment Web service (ossLiveDeploymentWS) enables operators to assign or reassign live services to clusters in a branch. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 162 When live services are added, moved, or removed in a cluster, the live deployment Web service does not immediately cause those changes to "go live." Instead, the Web service keeps track of all pending changes until the operator commits the changes. PPV Management Web Service The PPV management Web service (ossppv) enables OSS systems to manage the deployment of PPV assets. The following diagram shows how the PPV management Web service interacts with other Microsoft Mediaroom software components. Remote Recording Web Service The remote recording Web service (ossremoterecord) 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 listings subsystem and with individual set-top boxes. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 163 See Also EPG Web Service (p. 161) Restart Anytime Web Service The Restart Anytime Web service (ossTimeShift) enables operators to manage time-shifted offerings. Using the Restart Anytime feature (also known as "timeshift"), service providers can configure certain live services to be available for delayed play; a subscriber can watch the time-shifted service at any time during an operator-configurable window. Restart Anytime content is provided to subscribers by TimeShift Recording Servers. These servers are grouped into clusters. When creating a Restart Anytime service based on a live service, the service provider assigns the Restart Anytime service to one or more clusters and specifies how many servers within the cluster should provide the time-shifted service. An operator either designates a target number of servers to handle the service, which enables Microsoft Mediaroom server software to distribute the service to appropriate servers automatically (automatic assignment), or designates specific servers in the cluster to handle the service (manual assignment). Service Substitution Web Service The service substitution Web service (ossServiceSubstitution) enables service providers to schedule service substitution ("blackout") events. It is used in conjunction with the blackout management Web service (ossBranchBlackout) and the principal management Web service (BSS2). Note A number of different Web services must be used in concert to create and manage substitution events. For details on how the various Web services are used, see "Real-Time Service Substitution" in OSS/BSS Integration Guide in the Microsoft Mediaroom OSS/BSS Integration documentation set. UI Notification Web Service The UI notification Web service (UI) enables OSS systems to deliver short messages that appear on the screens of Microsoft Mediaroom 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 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 164 messages to Microsoft Mediaroom clients over UDP/IP. The Microsoft Mediaroom clients display the messages on screen until the messages expire or until the subscriber dismisses them. The following diagram shows how the UI notification Web service interacts with other Microsoft Mediaroom software components. Note If a message is larger than 2 KB, the UI notification Web service throws an exception. See Also Notification Subsystem (p. 116) URL Management Web Service The URL management Web service (ossurl) 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). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 165 VOD Backend Management Web Service The VOD backend management Web service (ossVodBackendWS) 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 Microsoft Mediaroom software components. VOD Branch Management Web Service The VOD branch management Web service (ossVodBranchWS) 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 Microsoft Mediaroom software components. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 166 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 167 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 management subsystem (SMS). (p. 169) 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. 171). Grant Management Web Service (p. 169) (GrantManagement) Manages the activities (play, pause, record) enabled on resources, such as live TV services, VOD assets, and RDP applications. Offer Management Web Service (p. 170) (OfferManagement) Manages the details of offers (price, tax, and expiration) associated with live TV services, VOD assets, and RDP applications. Package Management Web Service (p. 170) (PackageManagement) Manages packages, which can contain either a set of services or a set of other packages. Principal Management Web Service (p. 171) (PrincipalManagement) Manages Microsoft Mediaroom principals (devices, subscribers, accounts, and subscriber groups). Reporting Store Web Service (p. 171) (reportingstore) Enables applications to access billing records associated with subscribers in all service groups. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 168 Note Microsoft Mediaroom includes legacy versions of BSS Web services for backward compatibility with previous releases. The legacy Web services are deployed in different virtual directories than the one in which they were originally deployed. For example, the legacy version of the billing record management Web service has the following new endpoint: http://servername/bss/legacy/1.0.1/BillingRecordManagement.asmx, whereas the current version uses the following endpoint: http://servername/reportingstore/BillingRecordManagement.asmx. Billing Record Management Web Service Important This is a legacy Web service, provided for backward compatibility. At some point in the future, this Web service may be removed. For future development, you should use the Reporting Store Web Service (p. 171). 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 customer service representatives (CSRs) to view or delete billing records. The following diagram shows how the billing record management Web service interacts with other Microsoft Mediaroom software components. Grant Management Web Service The grant management Web service (GrantManagement) 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 Microsoft Mediaroom software components. The grant management Web service supports scenarios such as: Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 169 • 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 (OfferManagement) 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 Microsoft Mediaroom software components. Offer details are maintained in the SMS. Package Management Web Service The package management Web service (PackageManagement) 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 Microsoft Mediaroom software components. Packages are maintained in the SMS. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 170 Principal Management Web Service The principal management Web service (PrincipalManagement) enables BSS systems to manage Microsoft Mediaroom principals (devices, subscribers, accounts, and subscriber groups). Principals are maintained in the subscriber management subsystem (SMS). The following diagram shows how the principal management Web service interacts with other Microsoft Mediaroom software components. There are currently two external interfaces to the principal management Web service; these interfaces provide overlapping, but not identical, functionality. The older interface is called the primary principal management Web service, or simply the principal management Web service; the newer one is the principal management Web service (BSS2). Ultimately, all the principal management functionality will be made available through the BSS2 interface to the Web service, and the older interface will be deprecated. In the meantime, the interfaces are complementary, handling different tasks. Reporting Store Web Service The reporting store Web service (reportingstore) 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 affect Microsoft Mediaroom clients. • Deleting records from the central aggregation point does not affect Microsoft Mediaroom clients. • Applications do not have to access each service group individually. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 171 • 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. • The reporting store Web service 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 172 Microsoft Mediaroom Client The Microsoft Mediaroom client is an IP-connected device that consumes video and data services delivered by the Microsoft Mediaroom server machines. The Microsoft Mediaroom client presents a user interface (UI) that enables subscribers to discover and view or interact with those services. Microsoft Mediaroom clients run Microsoft Mediaroom client software, which is used to connect to and access Microsoft Mediaroom services. Each Microsoft Mediaroom device is assigned a unique ID or a hardware key by the manufacturer, which enables it to authenticate itself with the Microsoft Mediaroom server machines. After authentication, the Microsoft Mediaroom client receives a list of the URLs of Microsoft Mediaroom Web services that provide the configuration data the client requires to discover and use Microsoft Mediaroom services. The Microsoft Mediaroom client software is an embedded 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 Microsoft Mediaroom client software is designed to support extremely low-cost hardware implementations. The follow diagram shows the architecture of the Microsoft Mediaroom client. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 173 User Interface Framework The Microsoft Mediaroom 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 Microsoft Mediaroom 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 Client Customization and Localization Guide (Microsoft Mediaroom Client documentation set). 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) • Browser application pages, which display one or more picture-in-picture frames, as well as other text and/or graphics Browser application pages are written in XHTML, and then converted to a special 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 Browser application pages), see Configuring URL Services (p. 476) in Operations Guide. Data Exchange The UI consumes data that originates or is maintained at the Microsoft Mediaroom server machines. Some of this data, such as listings and subscriber rights, are cached at the client to Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 174 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 Microsoft Mediaroom server machines. Microsoft Mediaroom clients communicate only with the Microsoft Mediaroom server machines in the perimeter network, which is also sometimes referred to as the “demilitarized zone” (DMZ). The Terminal Server, DServer, and VOD Server machines also reside in the perimeter network, however, clients communicate with them through the Client Gateway machine. Other Microsoft Mediaroom server components also send data to Microsoft Mediaroom clients through the Client Gateway machine. The following diagram provides a high-level overview of the data exchange between the Microsoft Mediaroom server machines and Microsoft Mediaroom clients. For detailed interactions, refer to the specific subsystem descriptions. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 175 Audio/Video Service Support The Microsoft Mediaroom 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 Microsoft Mediaroom client uses command and control messages to synchronize with the machines delivering the content. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 176 The A/V engine includes codecs that decrypt audio and video data and decode it into video frames and uncompressed audio streams. The Microsoft Mediaroom client supports video and audio content in several formats. For the most up-to-date information on A/V support, see Audio Video Specification Guide in the Microsoft Mediaroom Common Reference documentation set. The A/V engine supports delivery of streams by Real-Time Protocol (RTP) transport. The device interacts with the Client Gateway machine that interfaces with the branch. The branch provides the device with keys that enable the subscriber to receive and consume media. DVR Engine, Storage, and Management The Microsoft Mediaroom subscriber UI enables subscribers to schedule a single recording or a series of recordings using local storage on the designated recording device in the household. DVR scheduling, however, is managed by the DVR Scheduler Subsystem (p. 125) on the Microsoft Mediaroom server machines. The Microsoft Mediaroom 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 a Microsoft Mediaroom 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 Microsoft Mediaroom 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, custom remote control key, 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. 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 177 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 Microsoft Mediaroom clients. Cookies are automatically moved from the Windows user profile on the Terminal Server to the subscriber database on disconnect, and are then moved back to the Windows user profile on reconnect. The cookies are preserved no matter which Terminal Server and Windows user is active when the subscriber accesses the application. For additional information on RDP applications, see RDP Application Subsystem (p. 076). Bootstrap and Client Authentication The Microsoft Mediaroom client boot ROM contains instructions for powering-up the device, initializing the system, and launching the Microsoft Mediaroom client software. Microsoft Mediaroom clients support both dynamic host configuration protocol (DHCP) and point-to-point protocol over Ethernet (PPPoE) for connecting to the Microsoft Mediaroom server machines. This enables support for households with or without routers in their networks. Whenever a device is initialized, normally when it is powered up or after the connection to the service is interrupted, the following client authentication sequence occurs: 1) The client establishes a connection with the bootstrap Web service, presents its (nonA/V) certificate and a randomly generated value or “nonce,” and then requests a ticket to contact services. 2) The bootstrap Web service validates the client certificate for authenticity. If the certificate is not 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 178 e) Transmits to the client the signed, encrypted session key, the signed nonce (an X.509 certificate identifying the branch and signing the challenge), the client ticket, the server public key, and the server certificate. 3) The client decrypts the session key with its private key, validates the server certificate, and then validates that the nonce was signed correctly by the server. If the server certificate is not authentic or if the nonce was not 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 is not logged on to the system using a different IP address from the one assigned to it or that the client certificate was not 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 the cloning or the certificate revocation check fails, the bootstrap Web service logs the event, and then closes the connection to the client. 6) When the client needs 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 Mediaroom client and the set-top boxes support the Microsoft Mediaroom 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 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. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 179 • MENU and GUIDE buttons provide access to the two most frequently used interactive applications. • RECORDED TV and VIDEOS buttons enable quick access to recordings and the Video on Demand screen. • EXIT TO TV button dismisses the subscriber UI and returns the subscriber to fullscreen TV. • INFO button invokes a description of the current or highlighted show. • BACK button returns the subscriber to the previous screen. For a complete description of the remote control buttons, see “Using the Set-Top Box Remote Control” in Subscriber’s Guide in the Microsoft Mediaroom Client documentation set. For information on how to assign one or more set-top box remote control buttons for launching network (RDP) or Microsoft Mediaroom Browser application, see Customizing a Remote Control Button to Launch an RDP Application (p. 468) and Customizing a Remote Control Button to Launch a URL Service (p. 482) in Operations Guide. Client Upgrade The Microsoft Mediaroom 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 Client-Facing Service Group machine. The bootstrap Web service compares the client’s current software version to its resolved version. If the version numbers do not match, the client is directed to one of the following resources to receive upgrade files during the next maintenance window configured by the operator: • Device upgrades for pre-1.6.2 devices are pushed to devices through the upgrade Web service. This service is responsible for downloading the upgraded software image to the set-top box. The upgrade Web service is installed by default on the Client-Facing Service Group machine. • Device upgrades for devices that run 1.6.2 or later are pushed to devices through a machine with the clientUpgradeFiles role. The clientUpgradeFiles role is installed in an Internet Information Service (IIS) cluster. Upgrade files are loaded into RAM for a period of time after the first retrieval, which provides a significant performance improvement over the upgrades for pre-1.6.2 devices. Software version precedence is determined through a hierarchical version stack. During a scheduled upgrade operation, the version the device had at its last bootstrap is compared to the current resolved version. An upgrade notification is only sent to the device if there is a difference. If there are multiple pending upgrade jobs for the same device, only one of the jobs is performed. For example, if you perform an individual device upgrade during the Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 180 device's usual scheduled upgrade window, the pending device group upgrade for that specific device is performed ahead of all other devices in the service group scheduled for that window. For more information about the software version precedence, see Software Version Precedence (p. 583) in Operations Guide. When a client’s software is upgraded, the set-top box receives only the files required to bring it up to date. After loading the new files, the set-top box reboots and repeats the client authentication process. Operators uses the options available in the Client Upgrade Settings (p. 309) page in the TV Services Management tool to configure a maintenance window for performing upgrades, set the number of upgrades to perform per second, and choose whether a subscriber can defer an upgrade: • Enabled, user snooze allowed. Devices are notified of an available upgrade. However, unless the upgrade is critical, the subscriber can choose to delay the upgrade. • Enabled, forced. Devices are notified of an available upgrade, and subscribers cannot delay the upgrade. • Blocked, notifications paused. Notifications are paused for normal upgrades. However, critical upgrades that result from disaster recovery, new set-top box initiation, and authenticator.xml minimum version changes still take place. Upgrades that result from disaster recovery, new-set-top box initiation, and minimum version changes in authenticator.xml are always enabled and forced. For additional information, see Client Management Subsystem (p. 143) and Upgrading Devices (p. 582) in Operations Guide. Multiple Client Households If a household has multiple set-top boxes and DVR Anywhere is enabled for the account, subscribers can watch any recorded show from any set-top box. When a recording is scheduled, Microsoft Mediaroom uses the account's designated recording device, which the operator can configure in the Edit Account (p. 215) page of the TV Services Management tool. (For more information, see Designating a Recording Device for an Account (p. 234) in Operations Guide.) An operator assigns a certain number of ingress streams to each account. The number of ingress streams determines how many services the household can watch at a time, regardless of how many devices are assigned to the account. When a subscriber watches one of the following types of services, a corresponding SD or HD stream is used: • Live TV programs. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 181 • Recording a live TV program or PPV event (although watching a recorded program does not use a stream). • Pay Per View (PPV) events. • VOD or SVOD assets. When a subscriber tries to use more streams than the account is entitled to, the Microsoft Mediaroom client displays a conflict resolution screen, prompting the subscriber to select which activities have higher priority. In addition to a set number of ingress streams, each household is also allocated a maximum ingress bandwidth. The household's maximum bandwidth is calculated automatically from the number of SD 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. For accounts with DVR Anywhere enabled, the operator also configures the number of SD and HD egress streams, and egress bandwidth that the account's designated recording device can serve to other playback-only devices in the household. When a subscriber plays back a recorded program from a playback-only device, the egress stream profile applies. Just as for playback on the designated recording device, none of the account's ingress stream or ingress bandwidth allocation is used for playing back the recorded program. For more information about the stream profiles, see Stream Management (p. 184). For the latest information on the maximum number of streams that are supported for a specific client, see the Microsoft Mediaroom Client documentation set for the version of the client software you are deploying. Client Streams Every household is allocated a certain number of streams. The streams are used to allocate full-stream video content. There are two different kinds of streams: • A high-definition (HD) stream can be used to watch or record high-definition or standard-definition content. • A standard-definition (SD) stream can be used to watch or record standard-definition content, but not high-definition content. 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 customer is using a set-top box to watch already-recorded content, the set-top box releases its stream. If no subscriber activity occurs 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 uses one of the stale streams. If an HD stream is being used to Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 182 play standard-definition content, the HD stream can also be designated as "stale". If a set-top box has a standard-definition stream but the subscriber wants to tune to a high-definition channel, the set-top box with the standard-definition stream can swap streams with the set-top box that currently has the HD stream. However, that swapped stream is still received in SD format at the set-top box. 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. If DVR Anywhere is enabled for the account, that set-top box handles all the recording for the entire household. As long as the designated recording device is powered on, from other playback-only devices in the household subscribers can watch recorded TV programs because the playback devices play recorded content from the designated recording device. Each set-top box communicates separately with the various Microsoft Mediaroom clientfacing servers, for example, for software upgrades and program guide updates. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 183 Stream Management Microsoft® Mediaroom clients from Microsoft Mediaroom Client 1.6 (1.6) and later enable each device in the account to manage streams for both ingress and egress. All streams—from live TV, video on demand (VOD), digital terrestrial television (DTT), and hybrid DTT services—are considered in the stream management profile. Each account has an ingress profile which defines the number of incoming streams permitted for the household. A recording device (DVR) can also have an egress profile, which defines the maximum number of playback streams are permitted for the device (excluding the DVR device itself, which does not use any of the allotted egress streams). The ingress profile is expressed as the number of high-definition (HD), standard-definition (SD), and DTT streams, and the maximum bit rate allowed for the account. The egress profile is expressed as the number of high-definition (HD) and standard-definition (SD) streams, and the maximum bit rate allowed for the device. Stream management events are captured as subscriber-activity logging events, which provide valuable insight on subscriber activity and usage patterns (see Subscriber Activity Log Events Reference (p. 617) in Operations Guide for more information). Any request for a stream goes through stream management policy enforcement, even though not all profiles apply perfectly to all devices. A device for an account with DVR Anywhere enabled plays one of the following roles. • A requester of remote playback streams. The requester is a playback device, which cannot provide streams to any other device in the household. • A provider of remote playback streams. The provider is the account’s designated recording device and can provide recorded streams to the playback devices in the household. Playback streams on the recording device do not subtract from the number of playback streams that are available for the non-recording devices in the household. The following diagram shows how the existing WAN profile for Microsoft Mediaroom Client 1.2.x devices and the ingress and egress profiles for 1.6.x clients apply to each device in the subscriber’s account. Incoming streams are streamed to the device. For accounts that have DVR Anywhere enabled, outgoing streams are streamed from the account’s designated recording device to other playback-only devices in the household. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 184 Stream Definitions WAN Streams (p. 186) are defined at the account level, and define the number of each ingress stream type that is shared by all devices in the household. Each account can have a separate set of defined Ingress Streams (p. 186), and the recording device can have a set of defined Egress Streams (p. 187). Account-level ingress streams are defined through the StreamManagementProfile class of the principal management Web service (BSS2). Device-level egress streams are defined through either the tv2config.xml file or the StreamManagementProfile class. For information about using tv2config.xml to define egress streams for an account, see “Configuring DVR Anywhere” in Client Configuration Guide (Microsoft Mediaroom Client documentation set). For information about using the BSS API to configure ingress streams for individual devices, and egress streams for an account that has DVR Anywhere enabled, see “Principal Management Web Service (BSS2)” (BSS Web Service Reference in the Microsoft Mediaroom OSS/BSS Integration documentation set). Note Stream profiles should only be deleted using the RemoveStreamManagementProfile method in the principal management Web service (BSS2). For more information, see “RemoveStreamManagementProfile Method” in BSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 185 WAN Streams WAN streams represent how many of each supported ingress stream type is supported at the account level. If not set for an account, the WAN stream profile that is configured as the global default setting is used. For more information on using the TV Services Management tool to define the global default account-level ingress profile, see Configuring the Global Client Settings (p. 058) in Operations Guide. Ingress Streams Ingress streams define the number of each type of incoming stream that is allotted to an account. The ingress-stream profile is applied to all devices configured for the account. If the device is the account’s designated recording device, this profile represents the number of each type of stream that can be used for recording. For playback (non-DVR) devices, this profile is less relevant, because such devices can tune only to one full-screen service at a time. Microsoft Mediaroom supports the following ingress streams. When there is contention for ingress streams, they are considered in the order of priority shown. 1) DVR Anywhere recording streams (HD, SD, and DTT). 2) VOD streams (HD and SD). 3) Live TV streams (HD, SD, and DTT). 4) Local and remote pause buffer streams (HD, SD, and DTT). 5) Browser application or picture-in-picture (PIP) streams (counted only for bandwidth, and not supported by DTT). The ingress profile is expressed in terms of the maximum stream count and the account's total ingress bit rate. Maximum stream count is expressed as a 3-tuple, which defines the number of HD streams, the number of SD streams, and the number of DTT streams. The account's total ingress bit rate is calculated by the following formula: (HD streams × HD max bit rate) + (SD streams × SD max bit rate) For example, if the account's ingress tuple is (2, 2, 2), the HD max bit rate is 9 Mbps, and the SD max bit rate is 3 Mbps, the total calculated ingress bit rate is 24 Mbps: Total calculated ingress bit rate = (2 × 3) + (2 × 9) = 24 Mbps Ingress streams can come from live TV or VOD services, or from DTT. For live TV or VOD streams, the total ingress bit rate is calculated with the preceding formula. For DTT services, there is no bandwidth limitation. Operators who need to control DTT bandwidth can control the number of DTT tuners through the device’s tv2config.xml file. For information, see “DTT Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 186 Client Configuration” in Client Configuration Guide (Microsoft Mediaroom Client documentation set). The ingress profile is stored in the ServiceGroupDB database. There is a default global device value that cannot be modified, and an account value that is configured through the BSS2 API. If a stream setting is not specified for a stream type, the stream type’s ingress profile is set to zero. An account's ingress profile can also be defined using the TV Services Management tool. The global account default value is defined using the TV Services Management tool. If an operator does not specify any stream values when provisioning an account, the global default stream settings are used. The account's ingress profile is the lesser of the WAN profile and the account-level ingress profile, where lesser is defined as: • The lesser value for HD streams. • The lesser value for SD streams. • The lesser value for DTT tuners. For example, if the WAN profile is set at 3 SD and 1 HD streams, and the account's ingress profile is set at 2 SD and 2 HD streams, the net ingress profile for that account is 2 SD and 1 HD. The server uses the ingress and WAN profiles to define the ingress profile for the recording device, which equates to the number and type of streams allowed for recording. It is important to note that while detuning a shared multicast live stream does not lower WAN bandwidth consumption, it does lower a device’s ingress stream count and bandwidth consumption. For more information about using the BSS2 API to configure the account ingress profile, see “StreamManagementProfile Class” in BSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). For more information on using the TV Services Management tool to configure the ingress profile for an account, see Modifying a Subscriber Account (p. 100) in Operations Guide. For more information on using the TV Services Management tool to define the global default ingress profile at the account level, see Configuring the Global Client Settings (p. 058) in Operations Guide. Egress Streams Egress streams define the number of each type of outgoing stream that a DVR device can serve to the account’s other devices that can perform playback-only functions. The value for egress streams is defined for the account’s designated recording device. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 187 Remote or local playback streams do not have a priority associated with them. The playback stream is unicast, and each playback stream is unique between two nodes, even if more than one node is viewing the recorded playback of the same program. Playback on the designated recording device does not count against the device’s egress profile. An HD playback stream can be used for either HD or SD content; however, an SD stream can be used only for SD content. Substitution of multiple SD streams for a single HD stream is not supported. The playback stream bit rate for each recording is either calculated at runtime or stored as a metadata value. For live TV and VOD recordings, the bit rate is stored with the recording. For DTT recordings, the bit rate data is not stored, and thus, the maximum HD bit rate that is defined in the device’s bootstrap.xml file is used. The account’s designated recording device receives the current defined egress profile from the server during bootstrap, or the device uses the local values that are defined in the tv2config.xml file. If the device’s egress profile is modified after the device bootstraps, the device does not honor the new settings until its next bootstrap. During bootstrap, the client gets the egress profile values from the server, or the client uses local values as outlined in this section. Changes to the egress profile that are made after the client has booted are not honored until the client is rebooted to take the new values. The egress profile can be based on bandwidth, stream count, or a combination of bandwidth and stream count. If the egress profile is based only on bandwidth, the profile is expressed as a total maximum bit rate. If the egress profile is based on stream count, the profile is expressed as the number of HD streams and the number of SD streams. If the egress profile is based on a combination of bandwidth and stream count, the profile is expressed as a 3-tuple that defines the number of HD streams, the number of SD streams, and the maximum bandwidth. The following examples show several possible egress profiles: • The operator specifies only the bandwidth. The resulting egress profile is: 0 SD egress streams, 0 HD egress streams, and 10Mbps. • The operator specifies only the stream count. The resulting egress profile is: 2 SD egress streams and 1 HD egress stream. • The operator configures both bandwidth and stream count. The resulting egress profile is 1 SD stream, 1 HD stream, and 10 Mbps. • DVR Anywhere is disabled by setting all egress profiles to zero (single-room DVR is still enabled). The resulting egress profile is 0 SD streams, 0 HD streams, and 0 Mbps. The egress profile is stored in the ServiceGroupDB database. There is a default global device value that cannot be modified, and an account or device value that is configured through the BSS2 API. The device value can also be specified in the tv2config.xml file for the device. If a stream setting is not specified for a stream type, that stream type’s egress profile is set to zero. Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 188 The device evaluates egress streams in the following order. 1) Device ingress policy a) Total bit rate (calculated) b) SD stream count c) HD stream count d) DTT tuner count 2) WAN policy a) Total bit rate (calculated) b) SD stream count c) HD stream count 3) DVB policy a) DTT tuner count 4) Device egress policy a) Total bit rate (input) b) SD stream count c) HD stream count Note If the device encounters a profile violation during the evaluation, a dialog screen is displayed to the subscriber. For more information, see “Resolving Multiple-Stream Conflicts” in Subscriber's Guide (Microsoft Mediaroom Client documentation set). If the request for a specific stream type satisfies the profile that it is mapped against, the request is granted and the corresponding stream is available for the subscriber to view. The device successfully tunes to the requested stream. If the request for a specific steam type does not satisfy the profile that it is mapped against, a stream contention event occurs. Most stream contention events result in a dialog screen that is displayed to the subscriber. Note Detuning a shared multicast live stream does not lower the WAN bandwidth consumption, but does lower the device’s ingress stream count and bandwidth consumption. For information on how to configure egress streams, see “StreamManagementProfile Class” in BSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set). For more information on how to configure egress streams in the device’s tv2config.xml file, see “Configuring DVR Anywhere” in Client Configuration Guide (Microsoft Mediaroom Client documentation set). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 189 For more information about the dialog screen that is presented when a requested stream is not available because of contention with the configured stream counts, see “Multiple-Stream Households” in Subscriber's Guide (Microsoft Mediaroom Client documentation set). Stream Contention When a device applies the stream profiles, it proceeds through them until one profile is either satisfied or violated. None of the available profiles matching is treated as though one of the profiles on the list was violated. If the tune service being evaluated is an IP stream (for example, download, UDP multicast or unicast stream, VOD, or application), it is evaluated in the following order and suborders: • • Ingress profile: • HD stream count. • SD stream count. • Total bit rate. WAN profile: • HD stream count. • SD stream count. • Total bit rate. If the tune being evaluated is a DVB tune, it is evaluated in the following order: • DVB profile: • DTT tuner count. If the request for a particular stream satisfies the profile it is mapped against, that request is granted, and the corresponding stream is available for use. The device will successfully tune to the request. If the request for a particular stream does not satisfy the profile condition it is mapped against, stream contention occurs. Most stream contentions result in a dialog box being presented to the subscriber. For more information, see “Resolving Multiple-Stream Conflicts” in Subscriber's Guide (Microsoft Mediaroom Client documentation set). Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 190 Architecture of Microsoft Mediaroom server11sp32-27feb09-2009-0227-1757 Page 192

scribd.vpdfs.com architecture-of-microsoft-mediaroom

Related documents

Products

Support

scribd.vpdfs.com architecture-of-microsoft-mediaroom

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib