distributedstoragemanagersystemforsynchronizedand...

Hindawi Publishing CorporationInternational Journal of Digital Multimedia BroadcastingVolume 2011, Article ID 687071, 8 pagesdoi:10.1155/2011/687071

Research Article

Distributed Storage Manager System for Synchronized andScalable AV Services across Networks

Frank X. Sun,1 John Cosmas,2 Muhammad Ali Farmer,1 and Abdul Waheed1

1 British Institute of Technology & E-Commerce, 258-262 Romford Road, London E7 9HZ, UK2 Department of Electronic & Computer Engineering, School of Engineering and Design, Brunel University,Middlesex UB8 3PH, UK

Correspondence should be addressed to Frank X. Sun, [email protected]

Received 29 July 2010; Revised 11 March 2011; Accepted 11 April 2011

Academic Editor: Stefania Colonnese

Copyright © 2011 Frank X. Sun et al. This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

This paper provides an innovative solution, namely, the distributed storage manager that opens a new path for highly interactiveand personalized services. The distributed storage manager provides an enhancement to the MHP storage managementfunctionality acting as a value added middleware distributed across the network. The distributed storage manager system providesmultiple protocol support for initializing and downloading both streamed and file-based content and provides optimum controlmechanisms to organize the storing and retrieval of content that are remained accessible to other multiple heterogeneous devices.

1. Introduction

In the Savant project (http://dea.brunel.ac.uk/project/Sa-vant/), as part of the overall system architecture providingthe end-to-end application for producing, delivering, andusing of enriched interactive TV content, the content accesssystem (CAS) presents the scalable (where scalability meanscontent personalization, device independence and networkindependence) and synchronized service to the user bymeans of multiple heterogeneous devices [1]. It is designedas a home media server which adapts the service so that itcan be consumed in a personalized way using three differentdevice classes with different properties: a conventional TVset for traditional viewing, a TabletPC as a portable powerful,highly interactive personal device, and a PDA as a portablelightweight personal device. While the TV set is connecteddirectly to the home media server, the portable deviceswill communicate with the server using IP via a WLANconnection. Additional content to be synchronized with themain content, such as a signer or multiple camera views, canbe delivered over broadband or broadcast networks. The CASsupports the presentation synchronization transparently.

Multimedia home platform (DVB-MHP) is an openmiddleware system standard designed by the DVB project for

interactive digital television. The MHP enables the receptionand execution of interactive, Java-based applications ona TV set. Interactive TV applications can be deliveredover the broadcast channel, together with audio and videostreams. These applications can be, for example, informationservices, games, interactive voting, e-mail, SMS, or shopping.Although there is a certain amount of storage managementincorporated with multimedia home platform (MHP 1.2)specification, this is not sufficient for the storage require-ments of the home media server system [2]. At present,the storage management functionality specified by MHP isrestricted and based on the Java File I/O. These operationspermit file access to persistently stored content and accessto content downloaded using a specific broadcast channel.Nonetheless, additional control mechanisms are necessary tosort out multiple content formats that are consumed by theterminal in a variety of ways. In addition, there is no supportfor managing the downloading and extraction of contentby means of multiple protocols used within the broadcastnetwork. Therefore, an additional storage managementsystem needs to be defined and implemented.

This paper provides an innovative solution, namely, thedistributed storage manager that opens a new path forhighly interactive and personalized services. The presented

2 International Journal of Digital Multimedia Broadcasting

Digital receiver,home media server

In-home

WLANADSL/VDSLTabletPC

PDA

TVTV connected to a

Content provider(s)

DVBnetwork

set top box

(IP based)

Figure 1: Scalable rich media TV service.

functionality of distributed storage manager provides anenhancement to the MHP 1.2 storage management func-tionality acting as a value-added middleware distributedacross the network. The distributed storage manager systemprovides multiple protocol support for initializing anddownloading both streamed and file-based content andprovides optimum control mechanisms to organize thestoring and retrieval of content that are remained accessibleto other multiple heterogeneous devices such as Set TopBox, TabletPC, and PDA. A novelty distribution modulebased on the CORBA distributed computing environmentwhich was embedded in the distributed storage managerwas designed. The distributed storage manager provideslocation transparency of service and the functionality totransport multimedia content from server to client or viceversa.

This paper first describes the key parts of the contentaccess system and then describes the architecture of thedistributed storage manager system, introduces each of thecomponents, and describes their functions within the system.Finally, conclusions are drawn.

2. Content Access System (CAS) Architecture

For the purpose of supporting service scalability, a contentaccess system has been developed [3]. The content accesssystem (CAS) was considered as an engine for controllingand managing services. It presents the scalable service to theuser by means of multiple heterogeneous devices (Figure 1).The setup of the CAS consists of a home media server(HMS), a Fujitsu-Siemens Activity 300, and three clients,a TabletPC (Fujitsu-Siemens Stylistic (ST Series)), a PDA(Fujitsu-Siemens PocketLoox), and a TV which is connectedto a set top box (another Fujitsu-Siemens Activity 300).

The HMS receives all information from the servicedelivery system (SDS), stores essence and metadata, andmakes it accessible for the clients via the client service system.With the exception of the client devices, all components built

Content

presentation

engineDistributedstorage

manager

Content

adaptation

engine

Servicedescription

manager

Service Xlet

TabletPCplayers

PDAplayers

TVplayers

MHP

Client devices

IP DVB

Home media server

Client service system

Tomcat

To SDS

Figure 2: System architecture of content access system.

upon MHP (multimedia home platform) middleware shownin Figure 2 reside on the HMS.

The CAS presents the scalable service to the user bymeans of multiple heterogeneous devices. The core elementof the CAS is a home server at the premises of the customerthat provides fine-granular scalability and personalizationof the service. It will adapt the service such that it can beconsumed using three different device classes with differentproperties: a conventional TV set for linear viewing, aTabletPC as a portable powerful, highly interactive personaldevice, and a PDA as a portable lightweight personal device.To realize this, content transcoding may be necessary on thehome server. While the TV set will be connected directlyto the home server, the portable devices will communicatewith the server using IP via a WLAN connection. Using the

International Journal of Digital Multimedia Broadcasting 3

service on the three different device classes is termed servicescalability. If service components have been transmittedusing multiple networks, it is the responsibility of the CASto reassemble these components to form a composite serviceand to present them synchronously.

The content presentation engine presents and synchro-nizes content to the user in the form specified by theuser interface, so it has two purposes: content delivery andcontent synchronization. The service description manageris responsible for receiving, updating, maintaining, andinterpreting the service description and triggers processesdepending on the information found there. It resides insidethe MHP world and is composed of two logical subparts,called passive and active parts, respectively. The contentadaptation engine is responsible to adapt multimedia contentsuch that it can be displayed on a variety of terminals withdifferent resources and can be transferred over networksof varying properties. The service Xlet fulfils two purposeswithin the CAS. First it signals a DVB service, for example,a TV programme, which carries a specific service. Aftertuning into the channel, the service Xlet is started throughthe MHP application manager. The service Xlet then con-trols the application in the CAS. The second function ofthe service Xlet is to transfer the metadata to the CASmodules.

3. Distributed Storage ManagerSystem Architecture

3.1. Functional Overview of Distributed Storage ManagerSystem. Although there is a certain amount of storagemanagement facilities incorporated with MHP, this is ratherrudimentary and not sufficient for the storage requirementsof terminal system since it is restricted and based onthe Java.File.IO package. Also an MHP-enabled terminalrequires additional content management and control specif-ically if content/data is being delivered over multiple trans-port protocols, channels, and networks. There are not controlmechanisms to organize multiple content formats that areconsumed by the terminal in various ways. Additionalstorage and retrieval management is required for multimediacontent that is associated with the main AV multimedia con-tent. The current storage management mechanisms providedby MHP do not distinguish between the various uses ofcontent, and it does not implement any particular searchingmechanism, so it makes the process of content retrievalinefficient. So a storage manager system for MHP wasrequired as part of the terminal middleware to accomplisha rather complex task involving the access and extractionof content via different DVB data delivery channels, suchas DVB object carousel, DVB PES, DVB private sections,DVB IP sections (multicast IP/UDP packages via MPE), andvarious IP transport channels. In addition, the location ofcontent extracted over such channels must be recorded in aconsistent manner. This permits the search and retrieval ofthe absolute file location of content in an efficient and timelymanner.

The storage manager system has access to an interfaceto download content on to multiple heterogeneous devices.

There are three different user devices as the heterogeneousdevices:

(i) Set top box (Fujitsu-Siemens Activy 300) is connectedwith TV and remote control. It provides large storage,and its components include a wavelancard, IP con-nection (also accessible via UMTS), and a DVB card.

(ii) TabletPC (Fujitsu-Siemens Stylistic (ST Series)) isoperated via touch screen and keyboard and usedas a portable device at home. Its components are aDVB-T card and a wavelancard for the local network.

(iii) PDA (Fujitsu-Siemens PocketLoox) is used asthe mobile device for “on-the-move” usage. It isequipped with storage media and can automaticallyconnect to the STB. Its components are wavelancardand UMTS connection.

So as one of the fundamental objectives of the storagemanager system was to allow multiple heterogeneous devicesand multiple server processes in a distributed environment.There is no mechanism for distributing content to differenttypes of terminal devices within MHP, so the storagemanagement system has to be implemented on a distributedplatform. Therefore, an additional storage managementsystem needs to be defined and implemented to providesolutions to these issues.

Meanwhile, the storage manager system is responsible forstoring, retrieving, and organising input content from theobject carousel, private sections (broadcast channel), and IPcontent (DSL, GPRS) via the broadband channel as well astranscoded content from the content adaptation engine. Thestorage manager provides the access control with functionsto trigger and extract content from the delivery channels, thatis, DVB broadcast channel and IP broadband channel [4–7].These functions include the following:

(i) DSMCC object carousel, DVB PES, and DVB pri-vate sections downloading from the DVB transportstream,

(ii) IP extraction within multiprotocol encapsulation(private sections)

(iii) IP extraction from the broadband channel.

The storage manager, is also responsible for the storing,retrieval, managing and maintaining of persistently storedcontent decided by the user and also manages the removalof no longer used content. The SM runs on the home mediaserver; it provides a mechanism for organizing and managingthe persistent storage on the home media server. When anycontent is persistently saved to disk, any metadata describingthe content is also persistently saved with the content. Thestorage manager also stores metadata that describes the userprofile/preferences during the system initialization process.

A structured database is generated by the storage man-ager from metadata, which contains the location of contenton the hard disk. The storage manager also is responsiblefor providing absolute file locations of content that is storedon disk to external other CAS system components, forexample, service description manager or content adaptation


engine. The storage manager allows external access to it andexecutes storage manager functionality. This therefore allowsthese external other CAS components to drive the contentpresentation engine and present content to the user. Thestorage manager provides a reference or pointer (URL orabsolute file path) of the content and forwards it to thecalling component. The storage manager reports the currentlocation of content to the service description manager, thuskeeping the service description up to date.

3.2. Storage Manager System Functional Components. Thestorage manager system enables applications to store andretrieve content to/from the home media server persistentfile systems. For the storage manager (SM) to communicateto external software components (i.e., service descriptionmanager, content adaptation engine), java events/listenersare used and an external interface is provided for externalsoftware entities to submit requests to the storage manager.

The SM triggers the carousel download when a servicehas been selected. The SM sets the carousel root basedon MHP properties and the selected service locator (DVBlocator). It also controls access to the content containedwithin the carousel. The request coming from the servicedescription manager for carousel content consists of therelative file path of the desired carousel content. The relativefile path is combined with the carousel root, and then theabsolute file path of the content is provided. After the SMhas confirmed that the content is available on the carousel,then the absolute file location is returned.

A section filter (ring filter) is used to extract data carriedwithin the private sections of the transport stream (DVB overIP). This software component assumes that the payload ofthe private section is IP packets, that is, MPE. The payloadof the IP packets and the use of the IP packets are designspecific. The Java.net package is used to create sockets thussupporting the sending and receiving of IP (UDP) packetsvia the return channel. The SM loads a user profile once alogin has been successful. The contents of the user profile aredesign specific although the profile should at least providethe SM with the user’s persistent root directory.

The current implementation supports transmission ofmedia items over the DSMCC object carousel and privatesections. After receiving a DVB locator, the module decidesby way of the DVB SI if the media item is transferred in anobject carousel or in private sections. The term “media item”is used for a set of files, for example, HTML pages usuallyrefer to pictures, style sheets, and other files. Media itemsin the object carousel are stored immediately after they wererequested. This means that the file has to be in the carouselwhen the request comes in. The actual extraction of files fromthe object carousel is part of the MHP implementation. Themodule therefore uses the MHP DSMCC API to make use ofit.

After a media item has been stored, the storage managerinforms its listeners by events that there is a new contentavailable. There are two kinds of events: one indicates thatthe storing succeeded (Storage Event), and the other oneindicates that the storing failed (Request Failed Event).Failure of storing media items can occur for instance if some

sections of a media item get lost. The components of storagemanager and their relationships are listed below and shownin Figure 3.

(i) Properties manager: the properties manager is usedto store and load system properties, terminal charac-teristics, user preferences, and user profiles.

(ii) Persistent storage: the persistent storage facility isprovided by the storage manager.

(iii) Storage manager implementer: the storage managerimplementer provides the root class of the storagemanager subsystem and provides overall control ofthe software components created by it.

(iv) Media item manager: the media item manager isdefined for the storage manager so that the storagemanager knows which media item it has downloaded,where to find the media item it should remove (i.e.,delete from the persistent storage), and how to do aclean-up operation.

(v) Download clients: the download clients defines aninterface for all the clients to trigger a file downloadand proposes a common abstract interface for alldownload clients.

(vi) Carousel manager: the carousel manager is centralinstance to manager locating and attaching of DSM-CC object carousel.

(vii) Content location table: the content location tableis used to construct a table, based on the suppliedmetadata, containing information about content.

(viii) Content container object: it represents a storage con-tainer for content description data fields including acontent item’s relative filename, absolute file name,a collection of associate content relative filenames,segment start time, and segment duration.

3.3. Storage Event Dispatching Algorithm. When a requestmedia item event is issued by the service description man-ager, the storage manager uses the following algorithm todetermine if and how the media item should be downloadedand which storage event is thrown:

(i) with checking in the persistent storage file, if themedia item is already locally available and has alreadybeen cached, then the event will be ignored;

(ii) if the media item has an RTSP (real-time streamingprotocol) media locator point to the service deliverysystem (SDS), save the information that it is availablein the media item management and dispatch eventthat the media item is now available with this medialocator;

(iii) if the media item has a DVB locator, initiate down-load of media item and when successfully down-loaded, save the information that it is locally availablein the media item management and dispatch eventthat the media item is now available (overwriting itscurrent availability status) with a new local medialocator.


managerStoragemanager

Carouselmanager

Persistentstorage

Storage manager

implementer

Properties

manager

Contentlocation

table

Contentcontainer

objectEvent

managerDownload

clients

Archive client

Media item

FTP media item clientHTTP media item clientLocal storage clientMPE media item clientObject carousel clientRTSP media item clientVirtual media item client

Figure 3: The distributed storage manager system components.

If media item has a DVB locator (not RTSP, ftp, orhttp), then the media item is normally downloaded withthe appropriate download client. As usual, the media itemmanagement is notified that the media item has beendownloaded. The media item might already be availablebecause it has a second RTSP media locator. So if the mediaitem has two media locators (RTSP and DVB), then thestorage manager dispatches two storage events: one for theRTSP that is dispatched directly after the media item has beenrequested that indicates the content is available on the servicedelivery system (SDS). In parallel, the storage manager isdownloading the content signaled in the DVB locator andwhen this download is finished, dispatches a second storageevent for the same media item, saying that the media item isnow available in the persistent storage, thus sparing the SDSfrom further requests.

3.4. Principle of Storage Manager System Operations. Thestorage manager (SM) is initialised at terminal boot upduring the MHP environment initialisation. This is doneduring the system runtime. Therefore, the SM is integratedinto the implemented MHP stack extending its currentrudimentary persistent storage system. Since the storagemanager implementer is the root software entity, it isresponsible for the initialisation of all other SM softwarecomponents and processes.

Upon initialisation the storage manager is loaded by thejava runtime class loader. The storage manager implementersets the service locator when the user selects a new service.An empty content location table (CLT) is initialised by thestorage manager implementer; the CLT attempts to locatethe persistent storage configuration file. This configuration

file contains CLT entries of content that were persistentlystored during the previous terminal operation. The file isthen parsed recreating new content container objects (CCOs)of the previous persistent storage entries. The newly createdCCOs are then added by the CLT.

The requests from the service description manager arehandled by storage manager to make media items contentavailable. The SM finds out where to get the requested mediaitem from by analyzing the media locator and uses theappropriate module to access the content. By analyzing therequest media item event, the SM gets the type of downloadand then passes the request to appropriate download clientto download. Download client defines the interfaces forthe internal storage manager modules. Each downloadclient handles one media item transport mechanism; it alsoprovides a common method to dispatch events and to call asuitable download client for a specific media item request.

Upon receiving a request from an external software sub-system, the request is passed to the storage manager imple-menter where the request is processed. If the request is for theabsolute location of content, the relative filename is extractedfrom the request. The storage manager implementer thenqueries the CLT that performs a binary search of CCO.The CCO performs a matching function and validates theexistence of the file using the stored absolute file location. Ifthis search is successful, the corresponding CCO is extractedby the CLT and passed to the storage manager implementer.The storage manager implementer extracts the absolute filelocation and associate content file names and returns themto the external software sub-system that initiates the request.If no match is found or the validation test fails, an NULL isreturned.

Since some form of content requires associated content(e.g., an HTML page may embed an image, therefore thelocation of this image is also required), the storage managerstores the mapping between content file names and associatecontent file names. If the request is to store a contentitem, the storage manager implementer extracts the relativefilename and associate content file names from the request.The storage manager implementer then searches the absolutefile location and relative filename. A new CCO is created bythe storage manager implementer, which then instructs theCLT to store the CCO. If the request is to delete a contentitem, the storage manager implementer instructs the CLTto search and retrieve the target CCO. If found and theCCO validates the existence of the content file, the storagemanager implementer instructs to remove the content withthe corresponding absolute file location from the hard disk.

When a terminating signal is received by the MHPsystem, that is, the session had ended, the mechanism isprovided by the storage manager implementer to allow theMHP system to inform the storage manager implementerof the termination. When this notification is received, thestorage manager implementer instructs the CLT to createa backup of all persistently stored entries to the persistentstorage configuration file.

3.5. Components and System Testing. To test all the internalcomponents and input and output of the storage manager,


three testing environments were created to allow it to betested in an integrated way. All the testing processes in thetesting environments were as predicted and were successful.The three testing environments are presented as follows.

(i) Simulate MHP: a class known as “simulate MHP” wascreated to load all the storage manager componentsinto a regular Java runtime environment. The aimof this environment is to enable all components tobe tested. It is clear that since crucial parts of thedistributed storage manager rely on MHP, not allcomponents can be tested with this or will fully workeven if they run.

(ii) Offair package (Stand-alone CAS without DVBinput): an environment was created that relies onMHP but not on DVB input (off-air package).The aim of this environment is to set up the fullworkflow in the CAS. This especially allows testingcommunication between the components. Therefore,all components should implement the off-air func-tionality. The off-air storage manager class simulatesdownloading files by having all files available aslocal files and throwing storage events after somepredefined schedules. It sends storage events thatcontain new locators for requested media items aftersome configurable time. So it is basically a translatorof media locators. The information when whichmedia item should arrive can be found in an XMLconfiguration file located in the carousal directory.This file is parsed by the off-air storage managerconfig file parser that creates pairs of media itemsand time “stamps” to simulate that the media itemis downloaded after a certain time. To schedule therequested media items (if they have been found in theconfiguration file), the media item arrival scheduleris used. This environment focuses on home mediaserver functionalities rather than TV client function-alities. The prerequisite here is to have the MHP-RI available, and this means that this environmentis set up on the terminal. This environment wouldallow testing of all (server) components in their “nat-ural” environment and testing of storage managerfunctionalities that do not need DVB input (FTP,etc.). Such an environment would be independent ofDVB streams, so that it does not have to rely on thecreation of a DVB stream for the off-air testing.

(iii) Stand-alone version with DVB input: play preparedDVB transport stream from hard drive. The storagemanager gets its DVB input not from the DVBchannel but from a DVB stream stored on disk. Thisalso includes video playback of main video on TV.

By using the three integrated testing environments, thefollowing points were accomplished, and all the componentstesting results have passed:

(i) storage manager Impl: testing of the initialization ofall software components and interfaces within storagemanager;

(ii) carousel manager: testing the interfaces to the MHPAPI by downloading DSM-CC object carousel;

(iii) download client: the download of content onto thehard disk from various download clients and theaddition of CCO within the CLT;

(iv) media item management: testing of media itemdownloaded to the CAS. Add/remove a media itemto/from the persistent storage;

(v) content location table: testing of the insertion,retrieval, and deletion of CCO. Testing of accessmethods and “synchronized” blocks and testing ofbinary search performance.

(vi) content container object: testing of access methodsfor storing and retrieving file names, file locations,and associated content file names.

3.6. Networking and Services

3.6.1. Distribution and the Use of CORBA. One of thefundamental objectives of the storage manager was to allowmultiple clients and multiple server processes in a distributedenvironment. For this purpose, CORBA was used as itsobject request broker (Figure 4). CORBA is a mechanism insoftware for normalizing the method-call semantics betweenapplication objects residing either in the same address space(application) or remote address space (same host, or remotehost, on a network). All CORBA code is encapsulated instorage manager servant, storage manager server and storagemanager client classes that work at the interface level of thecalling classes. This allows the CORBA transport layer to bereplaced by different CORBA implementations.

To translate overloaded class methods into separateCORBA methods, this work goes into an IDL (interfacedefinition language) file, which autogenerates the CORBAcode during its compile process. The JDK1.3+ comes withthe idlj compiler, which is used in this case to mapIDL definitions into Java declarations and statements. Thestorage manager servant, storage manager server, and storagemanager client class codes must deal with the translation stepbetween the overloaded methods and the differently namedCORBA equivalents.

3.6.2. Naming Service. Each object is registered with thenaming service (Figure 5) at instantiation. It operates ina manner analogous to a file directory structure, addingthe names of objects to each node of a branch, where thefirst level branch is the “context” and the second level thecomponent. When CORBA methods need to find an object,a request is sent to the naming service to get the object’slocation. The naming service is in charge and searches byname. Components must be uniquely named, otherwise theoriginal component will be overwritten by subsequent ones.

3.6.3. Event Service. The event service usually, but notnecessarily, runs on the same machine as the naming service,listens for event notifications from the server(s), and isresponsible for getting these events across the network. The


ServiceXlet

Distributestorage

manager

Servicedescription

manager

Contentadaptation

engine

Clientservice system

Contentpresentation

engine

Home media server

PDA players

TabletPC players

players

Client devices

Object request broker

GIOP/IIOP

TCP/IP(network device)

TCP/IP(network device)

10 Mbps ethernet LAN/WAN

IP DVB

TV/set top box

Figure 4: Structure of distributed platform for storage manager.

Clients

Event service

Naming service

Object server

Multiple server

Figure 5: The underlying principle of multiple clients and servers.

event service uses the “push” model, that is, events arepushed out from the service to all registered clients. Aconcrete class on the object server sends a notify message overthe event service to its companion on the client.

3.6.4. Object Server. This process is at the centre of the dis-tributed storage manager architecture. The object server classcontains the main entry point for the object server process.

Once the object server has an ORB, it can register theCORBA service. It starts by getting a reference to the rootof the naming service. This returns a generic CORBA objectand then transferred into a naming context object to registera CORBA service with the naming service.

For the client deployment, once a reference to the namingservice has been obtained, it can be used to access the namingservice and find the service such that the media item transferservice is found, and then the download media item methodis invoked.

With the use of the distribution module (Figure 4), therequest and response messages between the client and theserver are exchanged through the 10 Mbps Ethernet LAN forthe TV sets (set top box), for the portable device (PDA, TabletPC) via a WLAN connection. A web server was constructedwith the home media server, and the basis for commu-nication (requests and responses) is HTTP. The storagemanager instantiates and controls all components that runwithin the Tomcat environment. The object request brokers(ORBs) in both sides use the GIOP/IIOP (generic inter-orbprotocol/internet inter-ORB protocol) protocol to exchangethe messages. The client applications call the functionssupported by storage manager to get the multimedia contentstransparently from the object server, which is dispersed onthe communication network.

3.6.5. Distribution Module Testing. To test the functionalityof the distribution module, an application was developedon the basis of the distributed storage manager API. Thisapplication provides the interactive video retrieval servicefor video on demand (VOD). The distributed storagemanager provides the client devices with various operations


to transport and control multimedia data in a locationtransparent manner. The client application and the serverobjects running on the heterogeneous system communicateinteractively according to the VOD scenarios. The distribu-tion module uses the storage manager API to obtain variousmultimedia data from the networks and parses and interpretsthe data encoded. The distribution module presented theinterpreted data to the client devices and transferred theinputs from the client devices to the home media server. Allthe testing processes are as predicted and successful.

4. Conclusions

The distributed storage manager provides a solution forextending the MHP middleware, and it provides an imple-mentation of interfaces to the MHP 1.2 API that permitsother external software entities to make requests and receiveresponses from the storage manager. It provides the capa-bility to retrieve content from multiple network interfacesutilizing various protocols provided by the MHP platform;this permits the downloading and extraction of file-basedand streaming content delivered by different DVB transportprotocols, namely, DSM-CC object carousel, DVB PES,MPEG-2 private sections, multicast UDP/IP via MPE, andvarious IP transport protocols. The presented functionalitiesof the distributed storage manager have an added value overthe already provided functionalities by the most recent MHPversion 1.2, also it supports for currently popular DVB-IPDCdata carousels such as FLUTE to deliver files over the Internetor unidirectional systems from one or more senders to one ormore receivers.

The distributed storage manager also provides multipleprotocol support for initializing and downloading bothstreamed and file-based content. In addition, complex butoptimum control mechanisms are provided to organize thestoring and retrieval of content that are remained accessibleto other multiple heterogeneous devices.

The distributed storage manager also organizes thedownloaded content upon the hard disk to permit efficientretrieval of content file locations and provides access mech-anisms to the downloaded content. It performs the taskof organizing content that involves providing a structureddatabase to store the mapping of absolute file locations,relative file names, and relative associate file names on thehard disk. This permits the distributed storage managerto service applications/external software components (i.e.,content presentation engine) or decoders/players with thephysical location of requested content. It also permits otherexternal software entities to make requests and receiveresponses from the storage manager.

Compared to the storage management incorporated withmultimedia home platform, the distributed storage managerpermits a metadata search and retrieval of stored contentbased on a set of generated keywords; in addition, submissionof multiple keywords is permitted. The resulting list willcontain various content tiles with their matching score andallows a faster content presentation to the end user.

The distributed storage manager works with DVB-J(service Xlet) application that is executed via MHP. The

storage manager enables, interoperability of various imple-mented MHP applications. The distributed storage managerAPI is a set of high-level functions, data structures, andprotocols which represent a standard interface for platform-independent application software. It is object oriented and isbased on the Java programming language. Furthermore, theAPI enhances the flexibility and reusability of the distributedstorage manager functionalities.

A novelty distribution module embedded in the dis-tributed storage manager was designed and implemented.This module is based on the CORBA distributed computingenvironment, and the interfaces that define the distributionservices are in the form of OMG IDL. The distributed storagemanager provides location transparency of service and thefunctionality to transport multimedia content from server toclient or vice versa.

References

[1] P. Wolf, G. Durand, G. Kazai, M. Lalmas, and U. Rauschenbach,“A metadata model supporting scalable interactive TV services,”in Proceedings of the 11th International Multi-Media ModellingConference (MMM ’05), Melbourne, Australia, January 2005.

[2] J. Cosmas, A.n Lucas, K. Krishnapillai, and M. Akhtar, “Storagemanger system for DVB terminals,” in Proceedings of theTelecommunications, Networks and Broadcasting(PG Net ’01),EPSRC, Liverpool UK, June 2001.

[3] U. Rauschenbach, W. Putz, P. Wolf, R. Mies, and G. Stoll, “Ascalable interactive service supporting synchronized deliveryover broadcast and broadband networks,” http://dea.brunel.ac.uk/project/savant/pub/IBC04-SAVANT-rauschenbach et al-updated.pdf.

[4] U. Rauschenbach, J. Heuer, and K. Illgner, “Next-Generationinteractive broadcast services,” http://www.rauschenbach.net/Publications/docs/wsdb2004 rauschenbach etal.pdf

[5] B. Heidkamp, A. Pohl, and U. Schiek, “Demonstrating thefeasibility of standardized application program interfaces thatwill allow mobile/portable terminals to receive services com-bining UMTS and DVB-T,” International Journal of Services andStandards, vol. 1, no. 2, pp. 228–42, 2004.

[6] A. Centonza, T. J. Owens, J. Cosmas, and Y. H. Song, “Dif-ferentiated service delivery in cooperative IP-based broadcastand mobile telecommunications networks,” IMA Journal ofManagement Mathematics, vol. 18, pp. 245–267, 2007.

[7] Y. Zhang, C. H. Zhang, J. Cosmas et al., “Analysis of DVB-Hnetwork coverage with the application of transmit diversity,”IEEE Transactions on Broadcasting, vol. 54, no. 3, pp. 568–577,2008.

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2010

RoboticsJournal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery


Hindawi Publishing Corporation http://www.hindawi.com

Journal ofEngineeringVolume 2014

Submit your manuscripts athttp://www.hindawi.com

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation http://www.hindawi.com

Volume 2014

The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014

SensorsJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks


distributedstoragemanagersystemforsynchronizedand...

Documents