De Turck, Filip

Develder, Chris

Leroux, Philip

Roobroeck, Klaas

Vanhecke, Kris

English

Ghent University Academic Bibliography

Experimental Characterisation of an Open Out-of-homeMHP-based DVR ServicePhilip LerouxGhent University-IBBT-INTECG. Crommenlaan 8 bus 201,B-9050 Gent, Belgiumphilip.leroux@intec.ugent.beKris VanheckeGhent University-IBBT-INTECG. Crommenlaan 8 bus 201,B-9050 Gent, Belgiumkris.vanhecke@intec.ugent.beKlaas RoobroeckGhent University-IBBT-INTECG. Crommenlaan 8 bus 201,B-9050 Gent, Belgiumklaas.roobroeck@intec.ugent.beChris DevelderGhent University-IBBT-INTECG. Crommenlaan 8 bus 201,B-9050 Gent, Belgiumchris.develder@intec.ugent.beFilip De TurckGhent University-IBBT-INTECG. Crommenlaan 8 bus 201,B-9050 Gent, Belgiumfilip.deturck@intec.ugent.beABSTRACTMHP (Multimedia Home Platform) is an open standard forinteractive TV middleware that was designed by the DigitalVideo Broadcasting (DVB) alliance and is found on manycommercially deployed set-top boxes (STBs). In this paper,a detailed system architecture is presented which enablescustomers of digital television providers to use their MHP-based DVR from an out-of-home location through their mo-bile phone. Building further on the openness of the MHPplatform, special focus was on the overall scalability, secu-rity and extensibility of the system and the efficient andfast communication between mobile phone and set-top box.Technical challenges are imposed by the limited hardwareresources that are available on most of the currently de-ployed STBs and by the delays that are introduced by themobile communication networks. In order to characterisethe system’s performance, extensive throughput and scala-bility tests were performed on commercial DVRs. It is shownthat the overall system performance meets the predefined re-quirements even under heavy load.Categories and Subject DescriptorsH.5.1 [Information Systems Applications]: Multime-dia Information Systems; D.2.11 [Software Engineering]:Software Architectures— Domain-specific architectures, Service-oriented architecture (SOA)General TermsDesignKeywordsDistributed Software design, Web Services, Java ME, MHP1. INTRODUCTIONDue to the abundance of media, people have become moreselective with regard to what they want to watch on tele-vision. This is confirmed by the growing sales of videorecorders and the increasing popularity of services such asvideo-on-demand. In spite of their success, the current prod-ucts and services on the market still provide no conclusivesolution for a number of problems. The hardware capabili-ties of the devices are often limited (especially with respectto the CPU and RAM) and it is still necessary to be athome when programming the DVR. However, people oftenremember to record a program when outdoors and as suchare forced to pay for view it on demand later on.In this article, a generic architecture is presented that tack-les this problem. It enables the user to configure his DVRremotely by using his mobile phone while taking into ac-count the limited resources of both the set-top boxes and(most) mobile phones. This out-of-home recording may beprovided as a service by the television provider, which im-plies that no additional configuration has to be done by theuser nor does he has to purchase additional hardware.The rest of the paper is organized as follows. In Section II,related work is discussed and we explain how our systemarchitecture differs from other implementations. In SectionIII, we amplify on some requirements that our architectureat least should fulfill. Section IV provides an architectureoverview, detailing each specific component and the interac-tion between these components. In section V, the interactionmechanism between the different components is described.In section VI results of the extensive performance tests thatwere performed on the implemented prototype are detailed.Finally, section VII states our conclusions.2. RELATEDWORKRecently, several commercial operators started with offeringsimilar out-of-home configuration options. Contrary to oursystem architecture, all these implementations are specifi-cally targeting one specific architecture and one specific enduser platform. Popular examples of these closed source im-plementations are DirecTV [1] in the USA and Sky [2] in theUnited Kingdom. Both implementations allow their clientsto configure their DVR through a web application or by us-ing an iPhone application. Additionally, Sky customers canconfigure their DVR by sending an SMS. The work that ispresented in this paper differs from these closed source im-plementations as it is an open and extensible framework thatis built upon international standards and for more genericplatforms, both for the mobile client side as on the STB.For the latter, all components were compliant with the MHPspecification. MHP (Multimedia Home Platform) [3], is thecollective name for a compatible set of middleware specifi-cations developed by the Digital Video Broadcasting (DVB)alliance [4] and is currently deployed on many commercialSTBs.Other related work focuses on the out-of-home configura-tion of the DVR by deploying a home media center thatis running at the customer premises [5]. Contrary to thiswork, we propose an architecture that will require no in-stallation or configuration of additional components at theuser’s houses. Instead, a central deployable component witha general interface to the operator’s management and pay-ment components is introduced.3. FUNCTIONAL REQUIREMENTSAfter evaluation of related implementations and patents, itwas defined that our architecture should enable the followingfunctional requirements:• By using his mobile device, the user should be able tosecurely login to the system and select a DVR from alist of DVRs that are linked to his account.• An Electronic Program Guide (EPG) can be retrievedand browsed on the device.• Based on the program selection in this EPG, the usercan send a recording request to the DVR.• Furthermore, a list of all scheduled records and recordedprograms on a specific DVR can be retrieved.• Scheduled records from this list can be deleted.• Finally, the client application can also retrieve capacityinformation from every DVR linked to his account.The main quality attribute requirements of the system, listedby decreasing importance, are: usability, performance, scal-ability, interoperability and modifiability.4. ARCHITECTURE DESCRIPTIONOne of the initial design decisions was the use of a central,management component that works as an intermediate layerbetween the user’s mobile phone and STB. The use of suchan intermediate layer was chosen, as direct communicationbetween STB and mobile phone would introduce some in-conveniences. First of all, in order to communicate withthe STB, the STB’s IP address needs to be known and ithas to be accessible from outside the service provider’s net-work where the STB is connected to. However, for securityreasons, most service providers don’t allow direct communi-cation to their STBs from devices outside their private net-work. Second, the user would need to configure the mobileapplication to connect with that specific IP address.Figure 1: Low level system architecture.As shown in the low level system architecture of Figure 1,three layers can be distinguished in the the general archi-tecture: the client layer, the central service layer and theSTB layer. The client layer consists of the client applicationwhich provides the presentation and communication to theuser. The second layer contains the centralized processes. Itconsists of the DVR Access Server, which authenticates theuser, manages all DVRs that are linked with this service andforwards all instructions to the correct DVR. The other com-ponents in the service layer are the Playout Server, whichprovides EPG data to the client application and a databasecomponent. This central layer is typically found in the back-end of the service provider who manages all the STBs andmost of the time also the digital video services. In the STBlayer, an MHP application will run on the STB and processall incoming instructions. This is the DVR MHP Serverapplication.4.1 DVR Access ClientThe main component (GUI) of the mobile application de-fines and initializes all graphical components and determinesthe flow of the user application. Two additional packagescontaining Web Service clients were added to communicatewith the service layer. More specifically, AS Communicationmanages all communication with the DVR Access Serverwhile the PS Communication packet is responsible for thePlayout Server related communication. In both cases, theSimple Object Access Protocol (SOAP) was used. Once theuser has logged into the system, he receives a list with allDVRs that are coupled with his user account. After selecting(a) (b)Figure 2: Screen shots of the client application ((a):EPG overview, (b): Recording information).a specific DVR he can consult the program guide, request-ing the current capacity of this DVR, consult and manage allscheduled recordings on this DVR or choose another DVR.Figure 2 shows two screen shots of the prototype client ap-plication. In order to target as many devices as possible,the mobile client was developed by using the Java Platform,Micro Edition (Java ME).4.2 DVR Access ServerThe DVR Access Server is the central component of the sys-tem and will be deployed in the back end layer at the serverpark of the service provider. This component is responsiblefor user authentication and distribution of the instructionsto the various DVRs. The prototype that was tested duringthe performance analysis (detailed in Section VI), was devel-oped by making use of Java EE (Java Enterprise Edition). Itconsists of several packages containing a number of statelesssession beans, all providing different functionalities. Onepackage is responsible for user authentication and manage-ment of sessions, while others retrieve database informationor communicate with the DVRs. Two Web Services are de-signed, one to communicate with the DVR Access Clientapplication and one with the DVR MHP Server.4.3 Playout ServerThe Playout Server is a Java EE application that is alsopart of the back end layer and whose Web Service can becalled to retrieve all EPG data from a database. During theperformance tests, live EPG data was used. Note that inoperational systems, this component is already present inthe backend of the service provider.4.4 DVR MHP ServerApart from the main module, that is controlled by the MHPApplication Manager to start, pause and stop the applica-tion, four other modules are present. When the main appli-cation is started, the AS Communication module is initial-ized and starts listening to incoming messages from the DVRAccess Server. When an instruction is received throughthis channel, it will be forwarded to the Dispatching unitfor quick handling of the messages. All capacity relatedrequests are then handled by the State Manager while allrecord related instructions are finally handled by the RecordManager. The prototype for the DVR MHP Server was de-veloped using the MHP 1.1.2 Specification [3].5. COMMUNICATION DETAILSOne of the main challenges for this use case, was the com-munication between the central service layer and the STBlayer, due to the limited hardware resources of the STB. Asa result, the communication between the DVR Access Serverand DVR MHP Server applications is performed in an atyp-ical manner. While the application client of the mobile layeruses the services of the service layer applications by address-ing their Web Service, another approach has to be followedin this case. Due to the limited resources of the STB, noWeb Service engine can run on the recording device.In order to keep all advantages of a Web Service, followingcommunication method was used: when an instruction ar-rives at the DVR Access Server application, the correspond-ing parameters are stored locally. An asynchronous socketmessage is sent to the DVR MHP Server, which triggersthe device to call the server’s Web Service and retrieve thenecessary information to successfully execute the instruc-tion. The result is then sent to the DVR MHP server usingthe same Web Service. To complete the process, the DVRMHP Server sends a socket message back to the DVR Ac-cess Server. The DVR Access Server will then evaluate thesuccess of the operation and provide feedback to the user.6. PERFORMANCE RESULTSIn order to evaluate the performance and scalability of thesystem, the developed prototype was subject to several tests.The prototype application was running on a commercialSTBs that is currently used in many Belgian households.In cooperation with Belgian cable operator Telenet NV [8],this STB was running and fully functioning in their commer-cial cable network, which offers digital TV to hundreds ofthousands subscribers. This had a major impact on the mea-surement results as on such commercial and fully functioningSTBs, operators are typically running their own middlewareprocesses in the background, already taken up a large por-tion of the STB’s (limited) processing power. The main ad-vantage of this approach, is that all results are representablefor real life (out of the lab) situations. As all television chan-nels were live data streams, automatic parsing of an up todate (external) program guide was performed in the Play-out Server. During our tests, the Round Trip Time (RTT)of a request is measured in order to identify the numerousinfluences that cause a certain amount of delay.In a first category of tests, only one request was sent to theDVR Access Server. The tests indicate that the data rateof the mobile communication channel, has an important im-pact on the RTT of a request. This is shown in Figure 3where the average results of 10 tests are shown. For theUMTS connection, the network of the Belgian telecommu-nications operator Proximus was used. This UMTS networkhas a download link with an average data speed of 384 Kbps,which is a much lower data rate than a typical WiFi connec-tion (802.11g) coupled with broadband internet access. Asa result the RTT when using the UMTS network is signif-icantly longer than when using the WiFi connection. Still,it is shown that even the heaviest operation addRecord()remains under the 5 seconds barrier. This 5 seconds bar-Figure 3: RTT (ms) for different mobile data trans-mission protocols.Table 1: Time difference of instructions (ms) de-pending on the recording activity.Operation Not Recording Recordingget capacity 97,7 105,0get records 87,1 138,4add record 1429,0 1675,8remove record 192,0 196,0rier follows from a study performed by the Aberdeen Groupwhere they wanted to investigate the correlation between thedelay in a web application and the consumer’s satisfactionof the service. Their report [7] states that the RTT shouldbe limited to 5.1 seconds.The impact of the recording activity is shown 1. These mea-surements were performed starting from the DVRCommu-nication module in order to filter out other influences. It isshown that the recording activity of the DVR will have asmall negative impact on the execution time of all the in-structions. The biggest absolute time difference (i.e. 246.8ms) was measured when executing the addRecords() instruc-tion. This is due to the fact that this relatively heavy in-struction is imposed to the RecordManager of the MHP ap-plication, which is already responsible for the dispatching ofthe current recording.Figure 4 shows a test using login requests. The RTTs weremeasured in every run, which differed in the amount of si-multaneous login requests that were executed. A trend isadded to predict the RTT using more requests. The greenline represents the maximum RTT of 5 seconds consideredacceptable by the user. The graph shows that the RTT isstill acceptable when 1097 people log in at the same time.7. CONCLUSIONSIn this paper, an open system architecture is described forthe out-of-home configuration of a DVR by using a mobilephone. The system architecture requires no installation ofadditional components at the user’s premises. Instead, acentral component was installed at the Service provider’sbackend. This central component may interface with theFigure 4: RTT (ms) of the login procedure as a func-tion of the number of simultaneous login requests.Service provider’s existing management system. One of themain challenges of the system was the implementation of ef-ficient and reliable communication between different compo-nents with limited resources. This was implemented by com-bining synchronous and asynchronous communication calls.Additionally, decent user feedback is supported throughoutthe whole architecture. All functional requirements werefulfilled and the architecture was designed with usability,modifiability, interoperability, performance and scalabilityin mind. In order to evaluate the performance and scala-bility of the architecture, a prototype system was designedand thoroughly and successfully tested using live EPG data,a live transport stream and currently deployed commercialdevices.AcknowledgmentThe authors would like to thank Bart Catrysse from TelenetN.V.[8] for his valuable input. Chris Develder is a Post-Doctoral Fellow of the Fund for Scientific Research, Flanders(FWO-V).8. REFERENCES[1] DIRECTV, http://www.directv.com/.[2] Sky remote record service, http://www.sky.com/.[3] Digital Video Broadcasting, Multimedia Home PlatformSpec. 1.1.2, DVB Bluebook A068 Rev. 1, April 2005.[4] Digital Video Broadcasting, http://www.dvb.org/.[5] Shih-Hsiang Lo, Chi-Chia Lin, and Ming-Syan Chen,Controlling Digital TV Set-Top Box with MobileDevices via an IP Network, IEEE Trans. on ConsumerElectronics, vol. 152, number 3, 2006.[6] Digital Video Broadcasting, Digital RecordingExtension to Globally Executable Multimedia HomePlatform, ETSI TS 102 817 V1.1.1, September 2007.[7] Bojan Simic, Aberdeen Group, Monitoring theEnd-User Experience for Web Applications: What GetsMeasured, Gets Done, January 2008.[8] Telenet N.V., http://telenet.be/.

Experimental characterisation of an open out-of-home MHP-based DVR service

https://biblio.ugent.be/publication/1935536/file/1935539.pdf

Experimental characterisation of an open out-of-home MHP-based DVR service

Abstract

Similar works

Full text

Available Versions

Ghent University Academic Bibliography