A Framework for Internet Media Services Delivery to ... - Springer Link

J Netw Syst Manage (2013) 21:99–127 DOI 10.1007/s10922-012-9228-2

A Framework for Internet Media Services Delivery to the Home Environment Tiago Cruz • Paulo Simo˜es • Edmundo Monteiro Fernando Bastos • Alexandre Laranjeira

•

Received: 1 April 2011 / Revised: 15 February 2012 / Accepted: 18 February 2012 / Published online: 28 February 2012 Springer Science+Business Media, LLC 2012

Abstract In this paper, we propose a framework that enables Internet service providers (ISPs) to provide multimedia content to generic devices located inside the domestic networks of their customers (such as PCs and generic media players) in a seamless manner. In order to achieve this transparent integration between ISPprovided multimedia content and generic consumer media players, the domestic gateway becomes a managed UPnP AV/DLNA (Universal Plug and Play/Digital Living Network Alliance) media server, which can be dynamically updated by the broadband operator using Broadband Forum’s CPE (Customer Premises Equipment) WAN Management Protocol (CWMP) extensions specifically designed for this purpose. This framework enables the domestic gateway to become a mediator for both operator-provided and Internet media content, provided through UPnP services visible inside the domestic LAN. The adoption of a neutral UPnP/DLNA architecture that uses plugins to abstract each service allows it to become independent of the domestic gateway platform, allowing ISPs to easily add support for new media services while better coping with protocol updates. The proposed framework has been developed and validated in the scope of the project S3P, in T. Cruz (&) P. Simo˜es E. Monteiro Departamento de Engenharia Informa´tica, Faculdade de Cieˆncias e Tecnologia da Universidade de Coimbra, Po´lo II, Pinhal de Marrocos, 3030-290 Coimbra, Portugal e-mail: [email protected] P. Simo˜es e-mail: [email protected] E. Monteiro e-mail: [email protected] F. Bastos A. Laranjeira PT Inovaçaõ, Rua Eng. Jose´ Ferreira Pinto Basto, 3810-106 Aveiro, Portugal e-mail: [email protected] A. Laranjeira e-mail: [email protected]

123

100

J Netw Syst Manage (2013) 21:99–127

cooperation between the University of Coimbra and Portugal Telecom’s PT Inovaçaõ innovation and R&D unit. Keywords

Media services CWMP UPnP DLNA Home networks

1 Introduction The proliferation of interconnected media devices inside domestic households, such as media players or similar appliances that provide access to contents such as video or music, has contributed to transform the domestic Local Area Network (LAN). This was one of the key factors in the evolution of domestic LANs from its former role (supporting file, printer, and Internet sharing for PCs) to a private media distribution infrastructure. Specifically, devices that combine traditional media with new functionalities, such as ‘‘smart’’ TV sets, Game Consoles, or Blu-ray players are becoming more common in domestic LANs. Nevertheless, some of those appliances are frequently designed to operate exclusively inside LAN boundaries, accessing local media repositories located on other local devices. Those devices are becoming increasingly capable, with feature sets supporting other kinds of media services available from external sources, such as Internet media (YouTube [1], Flickr [2], etc.), or content providers (Netflix [3], Hulu [4], etc.). However, a simple protocol or Application Program Interface (API) change can render them useless until a firmware update is available—which may never happen, depending on the support status of the device. In fact, protocol changes are sometimes used by content providers to thwart unauthorized or unlicensed usage. YouTube is one such example, with various API ‘‘upgrades’’ rendering unlicensed devices inoperable [5]. As third-party content providers strive to enhance their service offerings, the separation between the LAN and the media distribution infrastructures is sometimes solved by adding new devices (such as set-top boxes supporting specific protocols and APIs for media delivery) to an already heterogeneous environment. Some content providers add their own frameworks and devices to this mix, like Google TV-based appliances [6, 7]. As a result, the domestic LAN becomes cluttered with several media rendering and control devices that support different protocols and services which, by their turn, become useless as their end-of-life support status is reached and updates cease. As such, it would be desirable to provide broadband media services in a seamless way, integrated with existing protocols and media delivery frameworks, such as UPnP AV [8] (Universal Plug and Play Audio Video) and DLNA [9] (Digital Living Network Alliance), which were designed from the ground up for such purposes. However, the DLNA specifications and their core UPnP AV functionalities were designed for use on LAN environments, being unable to properly operate across the LAN boundaries, over broadband access networks. In this paper, we propose a managed architecture that makes use of Broadband Forum’s CWMP [10, 11], together with UPnP/DLNA framework components to enable a Domestic Gateway to become a Media Server for contents delivered over

123


101

broadband networks. This architecture enables the domestic gateway to become a mediator for both operator-provided and Internet media contents provided as UPnP resources made visible inside the domestic LAN and managed using a CWMP protocol extension specifically designed for this purpose. The adoption of a neutral and portable UPnP architecture that uses plugins to abstract each service, also makes the UPnP layer independent of the domestic gateway platform (hardware and software), allowing operators to easily add new media services while better coping with protocol updates. The rest of this paper is organized as follows. The base components of the solution are discussed in Sect. 2. Section 3 introduces the architecture for the proposed media delivery framework, and how its components fit together. Section 4 discusses how the proposed architecture may be used to foster new application scenarios around its managed service delivery concept. Section 5 addresses implementation and validation. Section 6 discusses related work and Sect. 7 concludes the paper.

2 Base Components In this section, we will present the technologies in which the proposed solution is based, summarily describing not only their basic conceptual and operational model, but also their limitations and/or advantages in the context of the proposed solution. 2.1 The UPnP Framework A UPnP network is a collection of wired or wirelessly interconnected computers, network appliances, mobile phones, media players and similar devices that use UPnP protocols [12] to advertise, discover, and access network services in a seamless way, with minimum user intervention. UPnP protocols are defined by a consortium of companies reunited on the UPnP Forum and are based on open communication standards such as TCP/IP for network communications and W3 Consortium standards such as Hypertext Transfer Protocol (HTTP), Hypertext Markup Language (HTML), Extensible Markup Language XML, and Simple Object Access Protocol (SOAP) [13] to provide a framework for device discovery, device and service description, control, and presentation. Figure 1 presents the reference UPnP protocol stack [14].

Discovery

Eventing

Control

Description / Presentation

Fig. 1 UPnP protocol stack

123

102


The generic UPnP device initialization and configuration process goes through different stages, namely, •

•

•

Automatic address configuration Through which devices get a network address, typically using the Dynamic Host Configuration Protocol (DHCP) [15]. When a DHCP server is not available, the UPnP framework provides an alternative based on AutoIP [16]. Device discovery Devices announce their presence to control points (managing entities, in UPnP terminology) without any user intervention using Simple Service Discovery Protocol (SSDP, in Fig. 1) [17] multicast UDP messages, which provide basic information about devices, services, and a description URL that can be followed to gather further information about the device (see Fig. 2). Also, control points can send unicast or multicast SSDP messages searching for specific devices or services (that are answered using unicast SSDP messages). Device description Using the URL provided in the discovery process, a control point can access an XML description of the managed device via HTTP, including manufacturer information, model, embedded devices, embedded services, and the URLs used to access such features (see Fig. 2). An UPnP service description includes a list of commands (or actions) to which the service responds, and parameters (or arguments) for each action. A service description

I. Device discovery

II. Device description

Media Control Point

Media Control Point

2. SSDP Search Response

Set-top Box 1. SSDP Advertise

1. SSDP Search

1. Get device description 2. Send descrition

1. SSDP Advertise

UPnP/AV Media Server

1. Get device description 2. Send descrition

Multicast Group 1. SSDP Advertise

Media Control Point Set-top Box (Media Renderer ) 2. Control

1. Browse

UPnP/AV Media Server

Notify

Notify 3. Request Media

UPnP/AV Media Server 4. Send Media

III. Content management, control and eventing Fig. 2 Basic UPnP (AV) operation and communication

123

Set-top Box (Media Renderer )


•

•

•

103

also includes a list of variables that are used to model the state of the service at run time, described in terms of their specific characteristics (data type, range, and event properties). Command and control Each control point is able to execute actions on the managed UPnP devices, executing the SOAP methods described on the corresponding device description in XML, via specific URLs provided on the description stage (see Fig. 2). Event generation Control points can subscribe for receiving events corresponding to the change of notification-enabled variables on remote devices. These messages are XML-formatted and use UPnP’s General Event Notification Architecture (GENA, in Fig. 1) [18]. Device Presentation A device may provide a presentation URL pointing to a web page that can allow further interaction with the device. This way a user can resource to a web browser to directly control specific device features, monitor its status, or any other abilities.

The UPnP Forum [19] also established a series of working groups to develop device and service profiles for specific device categories, such as Audio/Video (AV), Internet Gateway Devices (IGD), Printing, Scanning, Lighting Control, Heating, Ventilation and Air Conditioning (HVAC), among others [12]. For each category, the respective working group defined a series of XML schemas representing the baseline set of functions and services that each specific device type was required to support (the so-called Device Control Protocols or DCPs). 2.1.1 UPnP AV and DLNA Among the UPnP categories, one of the most relevant in terms of digital media is the UPnP AV (Audio Video) specification. It has three fundamental components (see Fig. 2): • • •

The multimedia control point that discovers media servers and media renderers, and connects them. The media server that stores content on the network for access by media renderers. The media player that renders content from a media server.

When a multimedia control point is started (like a UPnP AV remote control, for instance), it may send a multicast message to the network asking for media servers and media renderers (otherwise, a control point may learn of a device of interest because that device sent discovery messages advertising itself). When the UPnP devices receive the message sent by the UPnP control point, each one responds to the control point requester. At this point, the UPnP control point knows about all of the connected UPnP devices (Stage 1—Device discovery, in Fig. 2). When a control point is interested in a device and wants to learn more about it and its capabilities, or wants to interact with it, it must retrieve a description of the device and its capabilities from the URL provided by the device in the discovery message (Stage 2—Device description, in Fig. 2).

123

104


The user, using the interface provided by the control point, browses and selects any media content item listed by the UPnP media server. After the selection is finished, the user chooses a media renderer that will render (play) the multimedia item. Next, the user clicks on the Play button of the UPnP control point, and the media renderer starts to play the multimedia stream sent by the media server. Also, a control point might subscribe to service events, in order to receive notifications to track and monitor its status (Stage 3—Content management, control and eventing, in Fig. 2). Another standard related to UPnP AV is the Digital Living Network Alliance (DLNA). It is defined by a consortium formed in 2003 in order to develop interoperable digital media devices for the home, having among its members some of the biggest global brands in PC, Consumer Electronics (CE), and mobile devices. Its goal is to allow seamless sharing of multimedia content among interoperable devices (like PCs, CE, and Mobile devices, among others) within the home, using already established industry standards. It also developed a certification process, complementary to its interoperability guidelines. The UPnP AV framework is the cornerstone technology for the DLNA architecture that defines baseline guidelines, called Interoperability Requirements, organized into eight categories (see Fig. 3): • • • •

Network connectivity Ethernet, WiFi, and Bluetooth are specified as baseline network connectivity technologies Security Mandatory support for WPA2 [21] on WLAN QoS Support for WiFi Multimedia (WMM) [22] QoS Device discovery By using UPnP protocols, devices can find and identify each other. Media player devices will automatically search for Media Server devices that meet its specific criteria. DLNA specifies UPnP v1 as a baseline requirement for version 1.5.

Fig. 3 DLNA version 1.5 interoperability guidelines (adapted from [20])

123


• • •

•

105

Content discovery UPnP mechanisms are used to search and browse content in Media Server devices as requested by Media Players. Media Transport HTTP (mandatory) or Real-time Transport Protocol (RTP) [23] (optional) might be used for stream transport. Media format profiles DLNA version 1.5 mandates JPEG [24] for still images, Linear PCM for audio, and MPEG-2 [25] for video. Optionally, Dolby Digital/ AC-3 [26] audio or MPEG-4 [27] video are also supported Content protection DLNA 1.5 defines the use of DTCP-IP (Digital Transmission Content Protection over IP) [28] for link protection purposes

2.1.2 UPnP Limitations The UPnP framework and related protocols were designed for use on small, domestic LANs. In such environments, the burden of management protocol traffic and scalability are secondary issues, due to available bandwidth resources and the relatively reduced number of devices involved. For example, the use of the Simple Service Discovery Protocol (SSDP) over Multicast UDP for UPnP device discovery has two serious shortcomings that are incompatible with operation on WAN environments. These shortcomings are the use of a multicast UDP (which is frequently blocked on edge routers) and the sheer number of UDP messages involved in the device discovery process, which are sent to overcome the unreliability of UDP, creating a traffic burden. Also, UPnP does not contemplate any kind of security measures for protecting its eventing and control mechanisms from malicious abuse, a vital issue in WAN environments. As such, and despite the fact that the UPnP Forum has published a Device Control Protocol specification for bridging UPnP devices with an UPnP network across the Internet [29] (using an unmanaged method with a limited application scope), the use of the UPnP framework on WAN environments is neither secure nor desirable. Consequently, this also applies to DLNA devices. 2.2 CWMP The CPE Wan Management Protocol (CWMP) [11] suite, also known as TR-069 (Technical Report 069) was conceived to allow operators to remotely manage equipment inside the customer premises on broadband environments, allowing for secure auto-configuration, dynamic service provisioning, diagnostics, software/ firmware management, and status/performance monitoring of such devices. Originally conceived to manage DSL modems, CWMP’s management scope was later expanded to home gateways and more recently, to all types of customer premises devices (CPEs). The CWMP protocol is an industry standard proposed by the Broadband Forum [10]. CWMP is based on an API of Remote Procedure Calls (RPCs) supported by a set of standard data models defined by related documents such as TR-098 [30], TR-106 [31], or TR-104 [32]. The RPC mechanism is based on SOAP web-services.

123

106


The standard data model for a CWMP-capable device follows a common set of requirements for which the detailed structure—hierarchically organized like a directory tree that always has a single root object—depends on the nature of the device. For instance, in the case of a home gateway, TR-098 specifies the root object to be InternetGatewayDevice. CWMP session security is enforced by using Secure Socket Layer (SSL) [33] (supported until Amendment 3 of the TR-069 v1.2 protocol) or Transport Layer Security (TLS) [34] for transport. Sessions can be initiated by the operator or by the CPE. In CWMP terminology, the remote management server is designated as the Auto-Configuration Server (ACS). CWMP was chosen because it is the de facto standard for remote management of CPE equipment on broadband access network environments. Instead of designing and developing a new specific-purpose solution from the ground up to manage the proposed media delivery framework, this option brings the benefits of a mature, tried and tested protocol, while leveraging existing CWMP-compliant Operation Support Systems (OSS) from operators.

3 Using UPnP AV and CWMP to Deliver Operator-Provided Media Services on Broadband Environments The idea of using the UPnP AV/DLNA frameworks to deliver media contents over broadband networks has the main advantage of allowing for seamless distribution to a wide range of devices that already support those protocols. This avoids the need to push for another protocol stack or specific device into the domestic LAN. In this context, it would be desirable that the UPnP AV/DLNA frameworks could inherently operate across the access network boundaries, which is currently not possible due to reasons already discussed in Sect. 2.1.2. As such, we designed a solution to provide managed media delivery using CWMP and UPnP AV/DLNA, which will be presented in this section. 3.1 A Managed Architecture to Deliver Media Content Using UPnP AV/DLNA and CWMP To overcome UPnP AV limitations, we propose a managed architecture in which the domestic gateway abstracts media content provided by sources outside the LAN using a DLNA-compliant embedded UPnP AV media server (see Fig. 4). This approach solves the aforementioned problems, extending the reach of the UPnP AV/DLNA device ecosystem beyond the domestic LAN premises, thus allowing providers (operators and/or third-parties) to seamlessly deliver media content. For clients, it means that existing DLNA/UPnP AV devices can be used to access a new range of contents and services that are external to the domestic network. The media server embedded on the domestic gateway is based on a modular architecture. It makes use of plugins that enable it to deliver a diverse range of contents and services available outside the LAN environment, abstracted as media

123


107

Content providers Internet Service Provider /Operator Value-added services

Content Networks

Web 2.0 Media

Cloud Services

Cloud Service/3rd Party Providers

Cloud Services

Web 2.0 Media

Domestic Gateway (embedded UPnP Media Server)

tM ed ia

3. R eq u es

1. Browse

Domestic LAN 1. Browse

4. Send Media 4. Send Media

3. Request Media 2. Control

Media Control Point

2. Control PC with UPnP-aware Media player (media renderer+ control point)

Set-top Box (Media Renderer)

Fig. 4 Using UPnP AV services to deliver media content on broadband networks

items residing on a regular UPnP AV media server that is advertised inside the domestic LAN (see Fig. 5). More than one instance of a specific backend type may be available, each one configured to provide content from a different source, identified and advertised in the UPnP Network as different UPnP Media Servers. In this scenario, CWMP is used to manage the UPnP AV media server embedded on the gateway, allowing the operator to define which specific backends are available (as well as their customized instance configuration). For this purpose, a CWMP bridging subagent was developed to map the configuration of the UPnP AV media server and its associated plugins into the CWMP data model of the domestic gateway. The operator ACS can then use CWMP to remotely access and configure all media server properties. 3.2 CWMP Bridging Mechanism To enable media server configuration using CWMP, there must be some kind of bridging mechanism for context translation. The proposed solution makes use of a CWMP dynamic agent extensibility framework that decouples CWMP protocol services (concentrated in a so called ‘‘Master Agent’’) from the device and servicespecific management interfaces to be provided via CWMP (distributed across ‘‘subagents’’). Each subagent is responsible for its own TR-106 CWMP data model

123

108


ISP/Operator OSS

Cloud service Providers

Value-added services

CWMP ACS

CWMP Mngmt. Agent

Local storage

Streamed Video backend plugin

Cloudstorage media library plugin

Streamed Audio backend plugin

Discovery

Eventing

Internet Media backend plugin

Control

Local storage backend plugin

Description / Presentation

UPnP/AV Media server UPnP/AV Media Content

Domestic Gateway (embedded UPnP Media Server )

UPnP/AV Device Network on Customer Premises

Fig. 5 UPnP AV modular media server embedded on the home gateway

extensions, mapped and registered on the data model of the master CWMP agent, which acts as a management bridgehead for all existing subagents. Master agents are responsible for receiving, converting and forwarding requests. The processing of each request is performed by the subagent(s) associated with the related managed service(s), parameters, and objects. A detailed discussion of this generic mechanism, which is outside the scope of this paper, is available at [35]. In our specific case, the subagent resides on the domestic gateway itself (Fig. 6) and acts as a bridge that maps on its CWMP data model the configuration of the UPnP AV media server, associated plugins, and existing instances. Upon initialization of the UPnP media server, all available plugins are enumerated and initialized, one by one. Each plugin registers its configuration ISP OSS CWMP ACS

CWMP Master Agent

CWMP Mediaserver bridging subagent

CWMP Mngmt. Agent

Backend Plugin A

Backend Plugin C

CWMP plugin registration

Media Server configuration

HTTP Presentation Service

UPnP/AV Media server

Domestic Gateway (embedded UPnP Media Server)

Fig. 6 CWMP bridging subagent general operation model

123

Backend Plugin B


109

parameters on the CWMP bridging agent, which updates the CWMP data model for the UPnP media service with the new parameters. This solution allows the ACS to use the CWMP API to remotely access and configure all existing media server parameters and related backend plugins. When the ACS creates a new instance of a backend service or modifies any existing media server backend associated object or parameter, the CWMP subagent on the home gateway accordingly updates the media server configuration. 3.3 CWMP Data Model Extension Mechanism Generically, when the CWMP bridging subagent registers on the master agent it must become associated with the CWMP Data Model objects and parameters for which it is responsible. After a registration attempt passes validation, the subagent is ready to receive requests. Standard UPnP AV/DLNA capabilities embedded on the domestic gateway are declared using the proper TR-157 [36] data model parameters under the UPnP object, albeit only for strict compliance. Information and properties of the UPnP AV media server and its plugins are embedded on the home gateway CWMP data model through the use of TR-106 data model service objects and parameters. This way, the CWMP subagent maps the UPnP AV media server configuration namespace data into the CWMP data model. Specifically, TR-106 enables the possibility of embedding such information by using specific service object instances that contain the correspondent data model information. The Services object on the CWMP data model (see Fig. 7) of the domestic gateway will have a vendor-specific entry for configuration of the UPnP AV media server framework (embedded on the X_\OUI[_UPnPMediaServer object, where the Organizational Unique Identifier (OUI) [37] is defined as 000000 for test purposes). Inside, each backend instance will be represented by a specific object, named \Backend Name[.{instance}. Integration of the UPnP media server data model into CWMP is done using static mapping. Specific CWMP parameters and objects inside each \Backend Name[ and respective plugin instances are mapped into the media server configuration attributes. In this case, the ACS only needs to manipulate conventional CWMP parameters. Specific mapping rules are stored on a registry accessed by the CWMP subagent, which contains all mapping rules and extensions that are used to update the CWMP supported data model of the domestic gateway (accessible to the ACS). 3.4 Backend Plugin and Instance Management All backend plugins must be enumerated and initialized when the media server first starts. Upon initialization, each backend plugin has to register itself on the CWMP subagent, using an existing mapping profile or one provided by the plugin itself. Next, the subagent will initialize all backend plugin instances, creating the associated CWMP objects and parameters. New plugin instances can be created using the CWMP AddObject method—to create a new object instance of the

123

110


InternetGatewayDevice DeviceSummary DeviceInfo ManagementServer (...) Services X_000000_UPnPMediaServerNumberOfEntries = 1 X_000000_UPnPMediaServer.1 (...) ISPVideoServiceNumberOfEntries = 2 ISPVideoService.1 URL UUID Name Refresh ISPVideoService.2 (...)

(...) http://ispvideoserver_fqdn/idx.xml 07f8b4fd-0fce-4591-bbb9-fcd0eff0f243 ISPVideo 10 ISPVideoservice (...)

Fig. 7 CWMP TR-106 parameters for the embedded media server

supported data model object associated with a specific backend, for which the subagent will translate the information, mapped to the native media server configuration. The plugin management solution is designed to support different mapping profile versions for different versions of the same backend plugin using the \plugin name[ \version[ naming convention to identify each plugin version and mapping profile entry. 3.5 CPE Management and Capabilities From the point of view of CPE management (configuration and software updates), the proposed framework fits into the scope of typical CWMP device management practices. This means that managing a CPE that supports this framework is no different from managing a generic CWMP-compliant CPE. Such management platforms are already widespread in real world scenarios with up to millions of managed CPE, such as domestic gateways or set-top boxes. Once a particular plugin is deployed and provisioned on a home gateway, it only requires occasional updates or reconfigurations, corresponding to typical component lifecycle management procedures or end-user service configuration and subscription options. This situation is akin to the management of other devices and services, such as home gateways or IPTV set-top boxes regularly subjected to firmware or service

123


111

updates and reconfiguration operations. In terms of management infrastructure scalability, the proposed solution does not impose a significant management overhead. From a CPE capabilities standpoint, most CWMP-capable gateways already support embedded managed execution environments (usually Linux or Java based) that are able to host the proposed framework components. Management of those components can be performed using generic TR-157 operations, which do not depend on specific execution environments. As such, most CWMP-capable gateways with managed execution environment capabilities can accommodate the proposed solution. Legacy CPE can also support the proposed framework, although at the possible cost of custom software development. From a resource management point of view, as discussed in Sect. 5, the proposed CPE components consume an amount of resources (CPU, memory) easily supported by current CPE devices.

4 Application Scenarios In this section, we will present three potential application scenarios for the proposed managed media delivery framework. 4.1 Operator-Controlled Media Distribution Using the proposed architecture, the domestic gateway can become a distribution hub for media content provided by the operator or specific content providers with whom it has established Service-Level Agreements (SLA). This distribution hub becomes available to all UPnP AV-DLNA media renderer devices inside the customer premises (Fig. 8). Once the broadband user subscribes a specific media service, two operations might take place. First, if the media server plugin that allows access to the service is not already deployed on the domestic gateway (or is outdated), the operator will upload the most recent version. Once the update is detected, the embedded media server will reload its configuration, enabling the new plugin, which, in turn will update its own configuration parameters on the CWMP management subsystem. The recently-introduced TR-157 CWMP software module management methods [36] are used for this purpose. Second, the operator will remotely configure and enable the new plugin, from the ACS (by using CWMP). Additional security and QoS transport features might be ensured by using a VPN (Virtual Private Network) or VCI (Virtual Circuit Interface) tunnel, which can also be configured using CWMP standardized data model extensions. Those mechanisms not only provide traffic separation and increased security, but also a simple way to differentiate traffic at the gateway level (e.g. for QoS policy enforcing purposes). This approach allows the operator to deliver media content to all kinds of UPnP AV or DLNA-enabled media playing devices inside the subscriber premises—in a controlled way, without directly exposing its backend infrastructure.

123

112


Operator-controlled media distribution

Cloud-service media library 3rd party

ISP/Operator OSS

VPN/VCI

ISP Content backend plugin

Client updates content from anywhere

CWMP

CWMP ACS

CWMP Mngmt. Agent

VPN/SSL/TLS

Domestic Gateway

Cloud Storage Backend plugin

CWMP Mngmt. Agent

UPnP/AV Media server UPnP/AV Media Content

Cloud Service

UPnP/AV Media server Domestic Gateway

UPnP/AV Media Content

UPnP/AV-DLNA ecossystem on the domestic LAN Fig. 8 Application scenarios

4.2 Cloud Service Integrated DLNA Media Libraries As with distributing content media, a plugin may be developed to access a storage container on a cloud service, exposing its media content to the customer premises though the media server (Fig. 8). Content can be updated from anywhere, becoming available to the UPnP AV-DLNA ecosystem on the domestic network of the service subscriber. For instance, a user travelling abroad may sync its photo collection on the cloud storage or media library service (using his notebook, from any place with an available Internet connection) to share with his family back at home, who will be able to watch the pictures on a Smart TV or other capable UPnP AV-DLNA media renderer. This capability can be available directly as a customizable feature to the end-user or as a value-added service from the service provider (with whom the third-party provider might have an established SLA). When compared with a typical cloud-based storage service, such as Dropbox [38], the proposed solution has several advantages: •

•

The proposed solution does not require a dedicated client application—any DLNA device is able to access and reproduce media content without any modifications. Dropbox client implementations are inadequate for integration within media devices (which are embedded devices with modest resources, in comparison to

123


•

113

PCs). Generally, Dropbox clients for smaller embedded devices (such as smartphones) have several limitations in comparison with the full-fledged PC version (e.g. the absence of local caching). Lastly, as a file synchronization service, Dropbox is inadequate for real-tine streaming since it offers only a best-effort service. Instead, the proposed solution builds on the operator OSS infrastructure to provide adequate performance.

4.3 Seamless Internet Media Services Access for DLNA Devices The same solution may also be used to provide Internet media service content (from a service like Flickr, for instance) for devices unable to directly access it. This solution offers a simple way for end-users to retrieve and play on their DLNAcompliant devices media content from Internet services. Similar to the previous application scenario, this feature might be available as a customizable feature to the end-user or as a value-added service from the service provider (with whom the third-party provider might have an established SLA). Our prototype, as detailed in Sect. 5, already bundles proof-of-concept plugins for some of these services (such as Flickr and Apple Movie Trailers, among others) that are fully integrated with the managed solution. When compared with unmanaged solutions for Internet-to-DLNA streaming, such as Skifta [39] and TVersity [40], the proposed solution offers several advantages: •

•

•

Skifta and TVersity require specific applications to be installed in the devices that mediate content transfer. While Skifta was designed for smartphones (requiring a PC client application for specific use cases, such as remote DLNA library access), TVersity requires installation in a PC. Our proposal is based on a platform-neutral solution for domestic gateways, not requiring further devices or software installations. Skifta and TVersity devices (PCs, smartphones) with the installed applications are required to be permanently available (i.e. powered on and accessible). In contrast, the proposed solution relies on domestic gateways, a device that is already permanently powered on. Skifta and TVersity do not offer any QoS support. Our solution builds on the operator OSS infrastructure to provide adequate performance.

5 Validation In this section, we will delve into validation work, focusing first on specific details of the implemented prototype, its specific components and their integration, together with a proof-of-concept managed media delivery service used for validation purposes. Next, the validation of the proposed solution will be addressed, including test methodologies and discussion of obtained results.

123

114


5.1 Prototype Implementation This subsection discusses specific details regarding the implementation of the key components of the managed architecture presented here: the Media Server, the management subsystem and a proof-of-concept plugin implemented for validation purposes. 5.1.1 UPnP AV Media Server The media server component of the domestic gateway is one of the basic building blocks of the proposed architecture. It has to fulfill three fundamental requisites: to be open-source, portable, and modular. In the selection process to find an adequate UPnP framework for this purpose, the BriSA [41], Coherence [42], and Cling [43] projects stood out as potential candidates, since they complied with the three basic premises. However, among the three, the Coherence UPnP framework was found to be better suited, for a number of reasons. First, Coherence is entirely developed in Python, a language that was intended from its conception to be platform-neutral and portable. Additionally, Python is available for a wide range of operating systems and environments, including embedded systems. Second, Coherence is based on a modular architecture that uses plugins to extend its functionality. Plugins can be easily added or updated by simply importing their source file into the plugin library directory. Third, Coherence supports the most complete set of specifications, including UPnP v1, v2 and DLNA v1.5. The Coherence framework architecture is divided into three parts: core, devices, and device backends (see Fig. 9). •

The core provides the building blocks for UPnP operation: an SSDP server; an MSEARCH [17] client; server and client for HTTP/SOAP requests; and server and client for GENA eventing. It also supports interfaces for implemented UPnP services and devices.

Fig. 9 Coherence framework architecture (from [44])

123


•

•

115

Device implementations link to the core using their respective UPnP service interfaces. For example, a media server must at least bind to the ContentDirectory and ConnectionManager service interfaces, when registering to the core. The backends are the interfacing points of the UPnP framework with the exterior. Backends are plugins that implement the methods to deal with external sources such as filesystems, hardware or user interfaces. Backend plugins can be used to integrate new media sources on the media server, such as local storage devices, Internet media services (such as Flickr or YouTube) and cloud services, among others.

When a UPnP device implementation registers with the core, it declares which service interfaces it uses, attaching hooks that map service actions to its backend. After that, the core generates a Universally Unique Identifier (UUID) [45] for the device and creates the data structures that support it and its UPnP device and service description. From then on, the core will take care of the ‘‘frontend’’ UPnP work, sending periodic SSDP announcements, managing GENA subscriptions for state variables, and interfacing SOAP service action calls for the respective backends. Nevertheless, from a user point of view, each backend plugin instance is seen and announced on the LAN as a separate UPnP AV device with its own UUID. 5.1.2 Plugin and Instance Management via CWMP One of the limitations of the Coherence framework has to do with the lack of manageability mechanisms, a weakness shared by all evaluated UPnP frameworks. Coherence does not provide interfaces for integration on operator-scale management infrastructures, relying instead on an XML-formatted text file to store its configuration. To solve this problem, we developed a bridging mechanism to enable configuration of the embedded media server using CWMP. To integrate the configuration of the media server with the CWMP management framework, the code of the Coherence plugin subsystem had to be adapted so that each plugin has the ability to register on the CWMP management subsystem. Since each plugin is responsible for registering itself on the CWMP bridging agent (that updates the CWMP data model for the UPnP media service), the Coherence plugin subsystem was also modified to integrate the CWMP registration mechanism, so that each backend plugin is responsible for declaring its own configuration options to the CWMP bridging logic. When the media server first starts (see Fig. 10), the directory containing all the backend plugins will be scanned (1) and initialized (2). Upon initialization, each plugin will attempt to register its availability on the CWMP subagent (3), which will check the mapping registry (4) for an existing mapping profile (that will be requested from the plugin, if not found). The subagent will scan the media server configuration file for all backend plugin instances (5), creating the associated CWMP objects and parameters under the X_000000_UPnPMediaServer service object (Fig. 10). When a new instance of a specific backend plugin is created (using the CWMP AddObject method to create a new object instance of the corresponding data model object) the subagent will

123

CWMP bridging subagent

CWMP Master Agent

CWMP Mngmt. Agent

5a. Instance configuration

P lugin C instance

4. DM mapping

Mapping registry 5. Instance config. query

P lugin C instance


P lugin B instance

116

Media Server configuraton file

6. Runtime instance management 2. Plugin initialization

3. Initial registration

HTTP Server

Core

Media 5b. Config. Server Reload

Plugin C Plugin B Plugin A

Media Server plugin directory

1. Plugin scan

Domestic gateway

Fig. 10 Initialization of the embedded media server

translate the information. This information will then be written to the media server configuration file (5a), refreshing the media server configuration (5b) and creating a device UUID for the new instance. For each operating backend instance, the CWMP subagent will use the UPnP presentation HTTP interface provided by the media server to query and manage runtime operation (6), accessing an URL of the form http://www.localhost: \configuredport[/\media server instance device UUID[/config (see Fig. 10). All media server configuration changes are written to persistent storage (maintained on a local file) allowing the service to use the last known configuration, in case of temporary management infrastructure failures. Plugin updates follow similar rules (see Fig. 11). When a new plugin is uploaded to the system (using software module management methods provided by TR-157), it will be dropped on a specific directory, which is monitored using the inotify API [46] (1). This will generate an event (2) forcing the media server to reload its configuration (3) and initialize the new plugin (4), which will proceed with its initial registration (5). Upon the initial registration process, the CWMP subagent will require the plugin to additionally declare its mapping profile to the mapping registry (6), which will also be used to update the CWMP supported data model (7). To create an instance of the newly available backend plugin, the ACS invokes the CWMP AddObject method. This instantiates an object for the related plugin (whose structure is declared on the supported data model namespace of the domestic gateway, available to the ACS) and fills its configuration properties. 5.1.3 Proof-of-Concept Plugin For proof-of concept purposes, a backend plugin was implemented to provide access to a video content delivery service (Fig. 12). This plugin, called ISPVideo, was

123


117

Mapping registry Media Server 7. Update event 6. Config. attribute registration configuraton file CWMP bridging subagent

4. Plugin initialization

5. Initial registration Plugin C

CWMP Master Agent

1. Plugin upload

Media Server

2. Update event

Plugin B Plugin A

Media Server plugin directory

CWMP Mngmt. Agent

3. Config. Reload

Domestic gateway

Fig. 11 Backend plugin update

Content delivery infrastructure

Domestic gateway ISPVideo backend plugin instance

4. Request media

5. Requested stream

2. Update content

UPnP/AV Media server

Content server 1 . Access content index 3. Browse id x .x

4 . Request stream 6. Receive media stream

m l

Catalog server

UPnP/AV Media Player (renderer + control point)

ISP/Operator

Domestic LAN

Fig. 12 The ISPVideo backend plugin (CWMP management infrastructure omitted for clarity)

designed to provide managed access to MPEG video streams (available on an operator video content delivery infrastructure) to DLNA-UPnP AV devices. The ISPVideo backend plugin uses a simple approach. The content/service provider publishes and periodically updates an XML document (idx.xml) available via HTTP on the service catalog server (1), describing available content, its location and metadata (such as title, duration, URLs for locating thumbnails of movie posters, and such). This information is used by the plugin to build the UPnP AV media server catalog, instantiated on the DIDL-Lite [47] scheme structures for its ContentDirectory service (2).

123

118


From the domestic user standpoint, the DLNA-compliant device on the LAN is able to browse (3) the entries available on the selected media server instance, in the same manner as it would in a conventional UPnP AV media server. Once a specific entry is selected (4), the plugin will follow the provided URL source for the selected media stream that will be downloaded from the content server (4, 5) and proxied for the DLNA device on the LAN via HTTP transport (6). It should be mentioned that the adopted media server framework has support for transcoding, implemented using the gstreamer [48] software. However, this feature was judged to be overwhelming to the modest processing capabilities of domestic gateways. As such, content providers might provide several streams encoded using different codecs (i.e. MPEG-2 and MPEG-4) to match the capabilities of the UPnP AV/DLNA CE devices. Apart from this ISPVideo backend, we also integrated Coherence plugins for a number of services (such as Flickr). Nevertheless, all the tests described in Sect. 5.2 were performed using the ISPVideo plugin. 5.2 Testbed and Test Plan A prototype home gateway platform was implemented, integrating the CWMP management support, media server, and proof-of-concept plugin. For validation purposes, this prototype was deployed on a testbed specifically conceived to reproduce all relevant aspects of the proposed managed media service architecture (Fig. 13).

DLNA/UPnP-AV ecossystem (renderers and control points )

ACS server

Ethernet switch

Webserver

ISP/Operator level Fig. 13 Testbed architecture

123

Dummynet emulator

Domestic Router (Prototype platform)

Ethernet switch

PC with UPnP Media Player

Customer premises environment


119

At the operator level there is a CWMP ACS and a webserver. The webserver acts as the content and catalog server for the ISPVideo service. On the customer premises side, the domestic LAN is equipped with the prototype home gateway hereby described together with some DLNA/UPnP AV renderers and control points (used for compliance testing) and a PC, equipped with a UPnPenabled media player for performance testing. The prototype home gateway is a Linux system with two network interfaces, a CWMP agent (with the bridging subagent) and the media server, where the ISPVideo plugin is deployed. It is based on a platform with modest computing capabilities (using cheap, off-the-shelf components and a single-core Atom CPU clocked at 1.6 GHz, paired with 512 MB of RAM) to mimic, as much as possible, the hardware constraints of typical commercial routers. In order to emulate the conditions and restrictions imposed by the broadband access link, a transparent Dummynet emulator [49] interconnects the two environments (ISP/Operator and Customer premises). This testbed hosted a series of measurements, following a test methodology devised to validate three different aspects of the proposed architecture: •

•

•

Functional validation Functional interoperability tests were performed using the prototype implementation, in conjunction with commercial, off-the-shelf, DLNA devices, with the purpose of verifying its compatibility requirements. Performance Operation latency was measured on different scenarios, in order to assess the performance of the solution on different broadband access network technologies. The Dummynet system was used to emulate typical access network scenarios, taking into account the technology and protocol overhead for specific access network technologies [50]. Table 1 presents the reference scenarios used for the tests. Resource usage Overall resource usage (CPU and memory) of the architecture components embedded on the prototype router was measured in order to verify its ability to operate on the more constrained embedded platforms typically used on commercial routers.

Because the test plan intended to evaluate the performance of the prototype using a stream within the capabilities of all emulated scenarios, a 480p MPEG-4 encoded video stream (with a bitrate of 2,957 Kb/s and 9:56 of duration) was used for all performance and resource test runs. This stream is publicly available at [51].

Table 1 Broadband test reference scenarios

ADSL GPON

Nominal bandwidth (Mb/s)

Effective bandwidth (Mb/s)

Down

Down

Up

RTT latency (ms)

Pkt. loss (%)

Up

12

1

10.02

0.835

20

0.1

20

1

16.7

0.835

20

0.1

30

3

100

10

27.9

2.79

5

0

93

9.3

5

0

123

120


6 Results and Discussion Functional validation was performed using a set of UPnP AV-compliant and DLNA-certified devices and software components, deployed on the LAN side of the testbed network. For each device, the same basic interoperability test was performed—consisting of browsing, selecting and playing a set of audio and video files. The availability and usability of basic play controls was also tested. The results are shown on Table 2. Apart from one device, all tests performed satisfactorily, with all devices and software components providing expected minimum functionality, albeit with minor problems in some cases—which can be tracked down to incomplete or incompatible DLNA/UPnP AV implementations. For performance assessment, runs of 20 tests were executed for each emulated network access scenario, to estimate the average latency of media player operations (Fig. 14). Each test consisted of a mix of basic control commands (Play, Pause, Stop, Seek to 50%) starting with a content browsing operation, on a container with 1,000 entries. For this purpose, the Cling Workbench [52] tool was used on the test PC to control the XBMC (Xbox Media Center) [53] media player and to measure the latency of media control operations. Special care was taken to obtain a reliable measure of user-interactivity, instead of simple operation latency measurements. For instance, instead of simply measuring the elapsed time between a UPnP AVTransport.Play method invocation and the reception of the corresponding event confirming the change of state on the media player, we ensured that no subsequent buffering-related immediate pauses were detected—which would mean that from the user standpoint the video stream was not yet playing.

Table 2 List of devices and software solutions used for functional validation Product

Type

Platform

Status

Microsoft Xbox 360

Game Console

Dedicated hw

Works

Popcorn Hour A-110

Media Player

Dedicated hw

Works

Sony PlayStation 3

Game Console

Dedicated hw

Works

XBMC

Media Center Software

Windows

Works (problems with content list refresh)

Foobar 2000

Audio Player

Windows

Works

Windows Media Player 12

Media Player

Windows

Works

Windows Media Center

Media Center Software

Windows

Works

Samsung LCD TV LE32C550

LCD TV with DLNA support

Dedicated hw

Works (only basic controls—no seek)

LG BD570

Blu-ray Player

Dedicated hw

Not working

Western Digital WD TV Live

Media Player

Dedicated hw

Works

ASUS O!Play HD2

Media Player

Dedicated hw

Works

AndroMote

Remote Control Software

Android

Works

123


121

Fig. 14 Media player operation performance (values in s)

Results show the average operation latency to be adequate for normal usage, with some specific operations, like Play and Seek, to be more prone to influence from access network technology conditions. This is, for instance, the case for the 19.4 s pause averaged on seek operations on the emulated 12 Mb/s ADSL scenario, due to buffering. This can be related to the proof-of-concept plugin implementation, which acts as a simple connectivity proxy—most UPnP AV/DLNA media players are designed to operate on LAN environments and do not implement adequate buffering techniques needed for streaming content across the access network. This problem could be handled with an improved plugin implementation, adopting pre-buffering techniques together with support of HTTP range requests and partial responses (both in the operator media server and plugin) to improve seek performance, albeit with a possible increase on resource footprint usage. In addition, this matter becomes less of an issue as the bandwidth on broadband connections increases and latency decreases. The resource footprint of the prototype components was measured for every access network scenario (and also for conventional 100 Mbit Fast Ethernet, for reference purposes). Five series of tests were run, each one composed by five individual runs of the same video streamed to the XBMC media player on the test PC. Data collection was performed using the top utility [54] (which allows for system resource monitoring in real-time) with a sampling rate of 2 s, averaged over a period of 10 min to cover the entire duration of the video stream. For each series of 5 runs, the corresponding average and standard deviation were calculated (see Fig. 15). Results show the resource consumption of the media gateway to be compatible with the capabilities of the current generation of domestic gateway devices. Further investigation showed the DLNA media server framework to be responsible for using the largest share of memory and processing power, consistently above 70% of the

123

122


Fig. 15 Average resource consumption on domestic gateway

total component resource usage, both for CPU and memory, reaching peak values of 85% in some situations. This is partly due to the nature of the Python environment, but it can also be traced to the implementation of the proof-of-concept plugin that does not implement any kind of throttling or adaptive streaming mechanisms (such as dynamic buffering) that could help mitigate this situation.

7 Related Work In terms of CWMP-UPnP integration, TR-157 [36] standardized a set of data model elements allowing it to embed some information about UPnP devices existing on the customer premises. It has also been proposed to further integrate the generic device discovery and configuration features of UPnP on CWMP environments, using control points embedded on domestic gateways [55, 56]. However, those proposals did not encompass other kinds of service-specific integration approaches. Instead, they embed UPnP operation semantics within CWMP for remote configuration, troubleshooting, and diagnostic purposes. For instance, in [56] it is discussed how the QoS properties of a wireless router could be remotely configured to solve streaming media performance problems. Outside the CWMP scope, the OSGi [57] management framework also incorporates provisions for accommodating UPnP device control points and generic device implementations as part of its specifications [58]. Projects like Apache Felix [59] have developed generic components to bridge UPnP discovery and control with OSGi platforms (compliant with the OSGi UPnP specification). However, to our knowledge, no one has attempted to use such mechanisms to implement the kind of managed service hereby proposed. The idea of extending the reach of UPnP devices beyond the domestic LAN scope, which is one of the main concepts presented on this paper, has already been the subject of some work. The use of VPNs and DLNA proxies to enable cross-LAN interoperability is proposed by [60], optionally using social networking mechanisms for access control. In this solution, management can be provided by SNMP [61] and/ or NETCONF [62] plugins. A proposal based on deployable OSGI components to

123


123

enable cross-LAN UPnP interoperability, using SIP for inter-gateway signaling, is presented in [63]. Another solution for device interoperability, using P2P protocols to create an extended home space for devices and services, is provided by [64]. These three approaches are based on gateway-oriented peer-to-peer solutions for device interoperability, which are not suitable to establish structured managed media delivery architectures as proposed by our approach. The UPnP forum has published a Device Control Protocol specification for bridging UPnP devices with a UPnP network across the Internet [29]. An evolution of this specification is scheduled for late 2010 but not yet published. Similarly to [60] and [63], this solution is focused on bridging disparate devices on domestic networks over broadband access networks, in order to allow UPnP devices on each side to interoperate in a transparent way. This makes it possible to constitute ad-hoc topologies for media sharing, but lacks integration with operators, contentdistributors and other kinds of service providers. As for content-oriented device and service interoperability, which is closer to the spirit of our proposal, there are several proposals, mostly based on unmanaged adhoc sharing topologies. Qualcomm, for instance, recently announced the Skifta service [39], which aims to tunnel content from local or external sources to DLNA devices on domestic networks (‘‘media shifting’’, according to Qualcomm’s terminology). Skifta uses Android smartphones as intermediaries. It is a locally installed application that bypasses operator and service provider management infrastructures. While the Skifta content-adaptation mechanisms are exclusively hosted at the service provider, our solution allows them to be totally or partially moved to the domestic gateway. TVersity [40] is a similar application, designed to be deployed on PCs. An architecture that uses UPnP and OSGi to enable users to access content from multimedia servers outside their home network is presented by [65]. This approach transforms the home gateway in a proxy media server for multimedia providers reachable outside the LAN. Another proposal, designed for large-scale media broadcast, is presented by [66]. This proposal enables multicast video delivery for DLNA devices inside the customer LAN, using domestic gateways as media proxies. However, these two proposals lack an integrated operator-oriented management approach, leaving management mechanisms out of the discussion. Solutions to allow domestic LAN content (stored on UPnP media servers) to become available to remote clients are proposed by [67, 68]. Both proposals integrate in a social networking context for access control of shared content. While an interesting proposition, these solutions do not encompass any management mechanisms being targeted towards ad-hoc usage. The Openiptv forum [69] has been developing a specification that supports optional gateway capabilities to allow set-top boxes to stream IPTV content to DLNA CE devices [70]. Apart from being IPTV-centric, the specification has not yet been finalized and no compliant products exist as of 2011 [71]. To our knowledge, the architecture hereby presented is the first proposal to integrate the UPnP AV/DLNA and CWMP frameworks together, in order to provide media distribution over broadband networks as a managed service.

123

124


8 Conclusion and Future Work In this paper, we proposed a framework that allows UPnP AV/DLNA CE devices to extend their reach beyond the domestic LAN in a managed way, providing seamless access to media distribution services provided by operators, content distributors, or third-parties. First, we described the basic building technological blocks that constituted the proposed solution, explaining their purpose and the reasons for their choice. Next, we presented the outline of the proposed architecture for managed media service delivery, its basic premises and operation model, followed by a discussion of potential application scenarios. Finally, implementation issues were addressed, examining each of the functional components that form the proposed architecture, their operation models and integration, complemented by an experimental study focused on validating the solution—addressing functional, performance, and compliance validation. Overall, the advantages of the presented approach are manifold. First, by allowing already existing UPnP AV/DLNA CE devices to access and use new services without any modifications, it protects users’ investments from obsolescence, since any DLNA-compliant device will be able to access content beyond the end of its long-term support period (when firmware updates cease and native support for media services stops working due to protocol or API changes). Second, content providers and operators are able to reach a wider device base, instead of only targeting purpose-built devices equipped with specific firmware support for each service. Finally, it provides a managed and extensible content delivery platform, which can be easily updated and managed using already existing management protocols, tools, and infrastructure. This solution is orthogonal to the Digital Rights Management (DRM) and content-protection mechanisms already provided by DLNA. Plans for future work include support for media upload features in order to synchronize content with personal media libraries on cloud providers directly from DLNA-compliant CE devices and applications. Replacing HTTP by RTP for content streaming between the operator infrastructure and the domestic gateway is another hypothesis under study. RTP is more efficient for media delivery purposes and its adoption would be especially adequate for operator-specific media content service plugins not requiring interaction with third-party content providers. Acknowledgments This research work was partially funded by Fundaçaõ para a Cieˆncia e Tecnologia (FCT grant SFRH/BD/29118/2006) and by PT Inovaçaõ, in the context of the S3P Project.

References 1. 2. 3. 4. 5.

YouTube website: http://www.youtube.com/t/about_youtube. Accessed March 2011 Flickr photo sharing service website: http://www.flickr.com. Accessed March 2011 Netflix Inc.: http://www.netflix.com. Accessed March 2011 Hulu video-on-demand service: http://www.hulu.com. Accessed March 2011 Gizmodo: Youtube shuts down API access, leaves set-top boxes high and dry (updated). Available at: http://www.gizmodo.com/5409504/youtube-shuts-down-api-access-leaves-set?top-boxes-high-anddry-updated. Accessed March 2011

123


125

6. Google TV: Available at: http://www.google.com/tv. Accessed September 2011 7. Logitech Revue: Available at: http://www.logitech.com/en-us/smartTV/revue. Accessed September 2011 8. UPnP Forum: UPnP AV Architecture:1 for UPnP Version 1.0 (2008) 9. DLNA Consortium: DLNA Networked Device Interoperability Guidelines (2009) 10. Broadband Forum website: http://www.broadband-forum.org. Accessed March 2011 11. Broadband Forum: TR-069—CPE WAN Management Protocol specification v1.2, Amendment 3 (2010) 12. UPnP Forum: Standards: Device Control Protocols. Available at http://www.upnp.org/sdcps-and-cer tification/standards/sdcps/. Accessed March 2011 13. W3C Consortium: SOAP Version 1.2 Part 1: Messaging Framework, 2nd edn (2007) 14. UPnP Forum: UPnP Device Architecture 1.1 (2008) 15. Droms, R.: IETF RFC 2131—Dynamic Host Configuration Protocol (1997) 16. Cheshire, S., Aboba, B., Guttman, E.: IETF RFC3927—Dynamic Configuration of IPv4 Link-Local Addresses (2005) 17. Goland, Y., Cai, T., Leach, P., Gu, Y., Albright S.: Simple Service Discovery Protocol/1.0 Operating without an Arbiter (IETF Draft) (1999) 18. Cohen, J., Aggarwal, S.: General Event Notification Architecture Base (IETF draft) (1998) 19. UPNP Forum website: http://www.upnp.org 20. Chou, J., Simerly, T.: DLNA, UPnP Pave Way for Home Video Nets, EE Times Asia (2006). Available at http://www.eetasia.com/ARTICLES/2006MAR/PDF/EEOL_2006MAR16_DSP_NETD_ OPT_TA.pdf. Accessed March 2011 21. IEEE Computer Society: IEEE 802.11i-2004: Amendment 6: Medium Access Control (MAC) Security Enhancements (2004) 22. IEEE Computer Society: IEEE 802.11e-2005: Amendment 8: Medium Access Control (MAC) Quality of Service Enhancements (2005) 23. Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.: IETF RFC3550—RTP: A Transport Protocol for Real-Time Applications (2003) 24. ISO/IEC Joint Pictures Expert Group: Information Technology—Digital Compression and Coding of Continuous-tone Still Images: Requirements and Guidelines: Recommendation T.81, ISO/IEC International Standard 10918-1 (1994) 25. ISO/IEC: Information Technology—Generic coding of Moving Pictures and Associated Audio Information: Systems, ISO/IEC International Standard 13818-1:2007 (2007) 26. Todd, C., Davidson, G., Davis, M., Fielder, L., Link, B., Vernon, S.: AC-3: flexible Perceptual Coding for Audio Transmission and Storage. In: 96th Convention of the Audio Engineering Society (1994) 27. ISO/IEC Motion Pictures Expert Group: Information Technology—Coding of Audio-Visual Objects—Part 1: Systems, ISO/IEC International Standard 14496-1:2010 (2010) 28. Hitachi, Ltd., Intel Corp., Panasonic Corp., Sony Corp., Toshiba Corp.: DTCP Volume 1 Supplement E: DTCP Volume 1 Supplement E -Mapping DTCP to IP (Informational Version) Revision 1.31(2010) 29. UPnP Forum: Remote Access Architecture:1 (2009) 30. Broadband Forum: Internet Gateway Device Data Model for TR-069, TR-098 Amendment 1 (2006) 31. Broadband Forum: Data Model Template for TR-069 Enabled Device, TR-106 Amendment 3 (2010) TM 32. Broadband Forum: DSLHome Provisioning Parameters for VoIP CPE (TR-104) (2005) 33. Freier, A., Karlton, P., Kocher, P.: The SSL Protocol Version 3.0 (Internet Draft) (1996) 34. Dierks, T., Allen, C.: RFC 2246—the TLS Protocol, Version 1.0 (1999) 35. Cruz, T., Simo˜es, P., Batista, P., Almeida, J., Monteiro, E., Bastos, F., Laranjeira, A.: CWMP extensions for enhanced management of domestic network services. In: Proceedings of LCN’2010 (The 35th IEEE Conf. on Local Computer Networks), Denver, USA (2010) 36. Broadband Forum: Component Objects for CWMP, TR-157 Amendment 3 (2010) 37. IEEE OUI Registration Authority: http://www.standards.ieee.org/ develop/regauth/oui/public.html. Accessed February 2011 38. Dropbox website: http://www.dropbox.com 39. Skifta media-sharing service: What is media shifting? Available at http://www.skifta.com/ support/ media-shifting 40. Tversity website: http://www.tversity.com

123

126


41. BriSA UPnP Framework Project website: https://www.garage.maemo.org/projects/brisa, last accessed on February 2011 42. Coherence UPnP Framework Project website: http://www.coherence.beebits.net, last accessed on March 2011 43. Cling Project website: http://www.teleal.org/projects/cling/support. Accessed March 2011 44. Coherence Project: Coherence Architectural Overview, Available at http://www.coherence.beebits. net/wiki/ ArchitecturalOverview. Accessed March 2011 45. ISO/IEC: Information technology—Open Systems Interconnection—Remote Procedure Call, ISO/ IEC standard 11578:1996 (1996) 46. Linux Kernel Documentation: Why Not dnotify and Why inotify. Available at http://www.kernel. org/pub/linux/kernel/people/rml/inotify/README. Accessed February 2011 47. UPnP Forum: DIDL-Lite schema for UPnP A/V ContentDirectory services, version 2.0. Available at http://www.upnp.org/schemas/av/didl-lite-v2.xsd. Accessed arch 2011 48. Gstreamer: open-source multimedia framework. Available at http://www.gstreamer.freedesktop.org. Accessed March 2011 49. Carbone, M., Rizzo, L.: Dummynet revisited. In: Proceedings of SIGCOMM CCR, vol. 40, no. 2 (2009) 50. Cruz, T., Simo˜es, P., Bastos, F., Monteiro, E.: Integration of PXE-based desktop solutions into broadband access networks. In: Proceedings of CNSM’2010 (the 6th IEEE/IFIP Conference on Network and Services Management), Niagara Falls, Canada (2010) 51. Big Buck Bunny Project website: http://www.bigbuckbunny.org. Accessed March 2011 52. Cling Workbench: Available at http://www.teleal.org/projects/cling/workbench. Accessed March 2011 53. XBMC Media Center Project website: http://www.xbmc.org, last accessed on March 2011 54. LeFevre, W.: Unix Top, http://www.unixtop.org. Accessed February 2011 55. Delphinanto, A., Hillen, B., Passchier, I., van Schoonhoven, B., den Hartog, F.: Remote discovery and management of end-user devices in heterogeneous private networks. In: Proceeding of the 6th Annual IEEE Consumer Communications and Networking Conference (CCNC 2009), Las Vegas, 2009 56. Nikolaidis, A., Papastefanos, S., Doumenis, G., Stassinopoulos, G., Polichronis, M., Drakos, K.: Local and remote management integration for flexible service provisioning to the home. IEEE Commun. Mag. 130–138 (2007) 57. OSGi Alliance: http://www.osgi.org. Accessed March 2011 58. OSGi Alliance: OSGI Service Compendium, Release 4, http://www.osgi.org/Specifications/HomePage, last accessed on March 2011 59. Apache Felix Project website: http://www.felix.apache.org. Accessed March 2011 60. Kamil, A., Hamid, A., Song, T., Wada, K., Asami, T.: Network management architecture toward universal communication. In: Proceedings of the IUCS’2009 (3rd International Universal Communication Symposium), Tokyo, Japan (2009) 61. Case, J., Mundy, R., Partain, D., Stewart, B.: IETF RFC 3410—Introduction and Applicability Statements for Internet Standard Management Framework (2002) 62. Enns, R., Bjorklund, M., Schoenwaelder, J., Bierman, A.: IETF RFC 6241—Network Configuration Protocol (NETCONF) (2011) 63. Martıńez, J., Madrid, N., Seepold, R.: End to End UPnP AudioVisual Service Provisioning and Management. Intelligent Technical Systems—lecture notes in electrical engineering, Springer, vol. 38, part I, pp. 45–58 (2009) 64. Park, H., Lee, I., Hwang, T., Kim, N.: Architecture of home gateway for device collaboration in extended home space. IEEE Trans. Consumer Electron. 54(4), 1692–1697 (2008) 65. Kang, D., Kang, K., Choi, S., Lee, J.: UPnP AV architectural multimedia system with a home gateway powered by the OSGi platform. IEEE Trans. Consumer Electron. 51(1), 87–93 (2005) 66. Hwang, T., Park, H., Paik, E., Chung, J.: EAFR-based DLNA proxy for high-quality video distribution in extended home space. IEEE Trans. Consumer Electron. 57(1), 120–125 (2011) 67. Belimpasakis, P., Moloney, S., Stirbu, V., Costa-Requena, J.: Home media atomizer: remote sharing of home content—without semi-trusted proxies. IEEE Trans. Consumer Electron. 54(3), 1114–1122 (2008) 68. Song T., Kawahara, Y., Asami, T.: Using SNS as access control mechanism for DLNA content sharing system. In: Proceedings of CCNC’2009 (The 6th IEEE Consumer Communications and Networking Conference), Las Vegas, USA (2009)

123


127

69. Open IPTV Forum: Open IPTV Forum Whitepaper (2009). Available at http://www.openiptvforum. org. Accessed March 2011 70. Open IPTV Forum: OIPF Service and Platform Requirements, v2.0 (2008) 71. Open IPTV Forum: Questions & Answers. Available at http://www.openiptvforum.org/questions answers.html (Deliverables section). Accessed March 2011

Author Biographies Tiago Cruz is a researcher at the Centre for Informatics and Systems of the University of Coimbra, Portugal. His research interests include (but are not restricted to) Broadband Network Architectures, Systems and Network Management, Security and Embedded Systems Design. He is currently finishing his PhD thesis. Paulo Simo˜es is Auxiliary Professor at the University of Coimbra, Portugal, from where he got his PhD in Informatics Engineering. His research interests include Network and Systems Management, Computer Networks, Critical Infrastructure Protection and Security. He is author of over 100 papers in national and international refereed books, journals and conferences. Edmundo Monteiro is Full Professor at the University of Coimbra, Portugal, form where he got his PhD in Electrical Engineering, Informatics Specialty. His research interests are Computer Networks, Wireless Communications, Service Oriented Infrastructures and Security. He is author of several publications including books, patents, and over 200 papers in national and international refereed books, journals and conferences. Edmundo Monteiro is the Portuguese representative in IFIP-TC6, he is member of IEEE Communications, IEEE Computer, and ACM Communications groups. Fernando Bastos graduated in Electrotechnical Engineering by the University of Coimbra in 1984, with a MSC in Telecommunications from the University of Aveiro in 2001. He started his experience in telecommunications at the R&D Center of Portugal PTT company, and participated in the developing of TMN systems, in European standardization groups and in national and international development projects, for QoS, Fraud, and Network Inventory Systems. He is responsible for the Architectures and Innovation Division for OSS in PT Inovaçaõ. Alexandre Laranjeira graduated in Electronics and Telecommunications by the University of Aveiro in 2000. It is responsible for the Mediation and Activation Division of the OSS department at PT Inovaçaõ, the technology company of Portugal Telecom (PT). Prior to his current position he was development team leader for the automatic provision platform for the Netb@nd Network solutions line, comprising technological solutions for access, aggregation/metro and core segments of transport networks. He also participated on IST R&D projects.

123