Connected home

9

Click here to load reader

Transcript of Connected home

Page 1: Connected home

© Tech Mahindra Limited 2011 © Tech Mahindra Limited 2010

Enabling the Connected Home – The Networked Consumer Authors: Raj Sahakari, Senior Consultant (Technology), NTSS CSU Sreekanth Vadakkepurakkal, Technical Associate, NTSS CSU

Abstract: In today’s connected world, we as consumers, are constantly battling the need to derive maximum value from the devices and gadgets that surround us, vis-à-vis the services that are available to us on these devices. Though technologies are in place to provide the ‘ideal’ connected lifestyle, service providers are not yet buoyant in their connected home offerings. This paper takes a peek at the various enablers that are available in realizing the networked consumer experience, and explores the possibilities of interconnecting the relevant technologies for generating a value proposition to both, consumers as well as service providers.

Page 2: Connected home

1 © Tech Mahindra Limited 2011

Table of Contents

Enabling the Connected Home – The Networked Consumer ................ 0

Introduction .................................................................................... 2

The Enablers ................................................................................... 2

UPnP .......................................................................................... 2

DLNA .......................................................................................... 4

OSGi Alliance .............................................................................. 5

HGI ............................................................................................ 6

Conclusion ...................................................................................... 7

References ...................................................................................... 8

Page 3: Connected home

2 © Tech Mahindra Limited 2011

Introduction The burgeoning market of consumer devices has undoubtedly overwhelmed the end consumer. The available choices of devices far outweigh their corresponding utility. The consumer is still in search of that ‘elusive’ value that these devices and associated services can provide to improve and complement his lifestyle. He is expectantly looking towards, a possibly connected environment to realize his objectives. Can a networked home be the answer? What are the enablers that contribute to such a digital lifestyle? This paper attempts to find out.

The Enablers A number of technologies have been playing their part in home networking. The physical layer technologies (based on layers 1 and 2) leverage existing connections in the home to exchange data between devices. The most common examples are coax, phoneline, powerline, Ethernet and WiFi. The more recent development has been G.hn, which supports networking over powerline, phoneline and coax.

The middleware layer technologies (based on layer 3 and upwards) on the other hand, help in realising richer applications to discover, control and protect content in the digital home. UPnP, DLNA, OSGi and HGI are some examples of such application-enabling middleware.

This paper further explores the latter category of digital home enabling technologies.

UPnP The Universal Plug and Play (UPnP) technology allows devices to seamlessly interconnect and form a network. It is agnostic to the operating system, network technology and programming language. The technology is governed by the UPnP Device Architecture (UDA) that uses TCP/IP and web technologies for transferring control information and data among devices in the home, office or in proximity. UPnP adopts popular internet-based technologies like TCP/IP, UDP, HTTP, XML and SOAP (Simple Object Access Protocol). It also uses a scheme for discovery of network services based on SSDP (Simple Service Discovery Protocol) and an event notification scheme based on GENA (General Event Notification Architecture). Fig-1 depicts the UPnP protocol stack.

The UPnP Forum has published Device Control Protocol (DCP) specifications based on the device architecture (UDA). DCPs have been specified for various device categories such as AV streaming (AV servers and AV renderers), home automation

Fig-1: UPnP Protocol Stack

Page 4: Connected home

3 © Tech Mahindra Limited 2011

(solar blinds, security camera, climate control, lighting control), networking (internet gateways and wireless access points), low power devices, device security, quality of service, etc. The UPnP Forum has been addressing evolving needs of the market through its working committees, which publish new versions of DCPs on an ongoing basis. In this context, the forum has recently published DCPs for remote access, content synchronization and device management. The UPnP Forum has also setup a new working committee on Home Energy Management and SmartGrid (HEMS).

The UDA broadly classifies the types of devices into (i) control point and (ii) controlled devices. Based on the device class, the controlled device varies. For example, in case of UPnP AV, the controlled devices are the media server (source) and media renderer (sink). The control point lists all the devices available on the network. Through a control point a user can initiate a communication between the source and the sink.

If we consider the case of AV Streaming, the typical interaction model between the control point, source device (media server) and sink device (media renderer) can be illustrated as shown in Fig-2. The figure depicts that the control point coordinates

and synchronises the behavior of the source and sink devices, configures them as needed, triggers the flow of content and then gets out of the way. The actual transfer of content takes place out-of-band between the media server and media renderer. Hence, the AV control point is mainly responsible for the UPnP actions that need to be executed based on the respective services offered by the media server and media renderer, viz. the content

discovery service, the connection manager service, the rendering control service and the AV transport service.

Similar to the protocol for AV Streaming, other DCPs for home automation, networking, etc., define the corresponding interaction between the control point and the respective controlled devices, e.g. air conditioning, lights, internet gateway, access points, and others.

The UPnP Device Architecture defines six steps which a UPnP device executes once connected to a network.

1. Addressing: Involves sending out DHCP request for IP address. If no DHCP offers are obtained, then IP address is automatically configured.

Fig-2: UPnP AV Device Interaction Model

Page 5: Connected home

4 © Tech Mahindra Limited 2011

2. Discovery: After obtaining an IP address, the UPnP device advertises its capabilities and services it offers, using the SSDP multicast messages. Any control point on the network can listen to the standard multicast address for availability of new capabilities.

3. Description: The control point retrieves capability documents from individual devices. The documents involve a device description document containing the details of the device such as model name and number, manufacturer name, etc., and a service description document mentioning the respective services (capabilities) offered by the device, including the actions and parameters required to invoke it.

4. Control: The control point, in order to invoke actions on a given service, sends SOAP messages to the control URL for the given service. The control URL is obtained from the device and service description documents.

5. Eventing: Each service offered by a device has associated state variables whose values model the status of that service at a given instance of time. Control points can subscribe for eventing, in which case it is notified of the changes in the state variables associated with the service. A control point may also explicitely poll for the state variable values to monitor any change of state for a non evented variable.

6. Presentation: The UPnP device may host a presentation page, in which case it provides a presentation URL in the device description. The control point can use this URL to get a web page over HTTP and load it onto a web browser. Depending on the capabilities of the page the user can control the device and/or view the device status.

DLNA Digital Living Network Alliance (DLNA) is an industry consortium which has defined guidelines to facilitate an interoperable network of PCs, consumer electronics and mobile devices in the home, thus enabling a seamless environment for sharing digital media and content services. The DLNA interoperable guidelines are primarily based on UPnP, viz. UPnP device architecture for device discovery and control, and UPnP AV protocol for media management and control. Similar to UPnP, DLNA uses HTTP for media transport and is agnostic to the underlying physical network. Fig-3 illustrates the functional components in the DLNA home networking architecture.

The DLNA guidelines have been constantly evolving to accommodate new device classes and usage scenarios. One of the significant value additions by DLNA has been the introduction of the mobile handheld devices category to the device classes, thus increasing the user scenarios significantly. DLNA has also added the home infrastructure category to the device classes (see device classes below), which

Fig-3: DLNA Functional Components

Page 6: Connected home

5 © Tech Mahindra Limited 2011

essentially helps in bridging the mobile handheld devices to the home network devices and also provides the necessary content transformation functionality therein. Apart from the integration of the internet, mobile and broadcast, ongoing work in DLNA involves supporting automotive applications, expanding remote access functionality, enhancing DRM interoperability, and adding new features such parental controls, closed captioning and emergency alert notifications.

Since DRM Interoperability is still being worked upon and in order to prevent this from being a roadblock, DLNA has defined Link Protection based on DTCP/IP (Digital Transmission Content Protection), for protecting content streaming between source and display devices.

The current device classes supported by DLNA include:

Home Network Devices: Digital Media Server (DMS), Digital Media Player (DMP), Digital Media Renderer (DMR), Digital Media Controller (DMC) and Digital Media printer (DMPr)

Mobile Handheld Devices: Mobile Digital Media Server (M-DMS), Mobile Digital Media Player (M-DMP), Mobile Digital Media Uploader (M-DMU), Mobile Digital Media Downloader (M-DMD), Mobile Digital Media Controller (M-DMC)

Home Infrastructure Devices: Mobile Network Connectivity Function (M-NCF) and Media Interoperability Unit (MIU)

Though DLNA enables a host of usage scenarios, the inherent technology, like its UPnP counterpart, is device-centric and does not have the notion of a user. This implies that all services that demand a user identity to be managed, require a solution that is external to DLNA but which can seamlessly integrate into the overall network. We shall look at such technologies in the subsequent sections.

OSGi Alliance The OSGi Alliance (formerly, Open Services Gateway initiative) has defined a standardized platform for network services based on a service-oriented architecture (SOA). When the OSGi Service Platform is added to a networked device, either an embedded CPE (e.g. home gateway) or a network-end equipment (e.g. server), it becomes possible to manage the lifecycle of the software components in the device from anywhere in the network. As a result, the software components can be installed, started, updated, stopped or uninstalled, without having to disrupt any operation of the device.

The OSGi Framework is primarily a Java-based application server on which Java applications, known as ‘bundles’, can be installed. The OSGi Alliance has specified several services in the form of Java interfaces, which can be implemented by a bundle. The installed bundles that offer specific services are registered with the service registry of the framework, and any other application that runs in the same OSGi Service Platform can dynamically discover and use these services. The platform specifies several standard services, which comprise of:

Page 7: Connected home

6 © Tech Mahindra Limited 2011

Framework services: Permission Admin, Package Admin, Start Level (set of bundles that should run together), URL Handler

System services: Log Service, Configuration Admin Service, Device Access Service, User Admin Service, IO Connector Service, Preferences Service, Component Runtime, Deployment Admin, Event Admin, Application Admin

Protocol services: HTTP Service, UPnP Service, DMT Admin (Device Management Tree)

Miscellaneous services: Wire Admin Service (to configure a connection of different services that need to work together), XML Parser Service

Fig-4 depicts the various layers in the OSGi architecture and the standard services supported by the framework.

The OSGi specifications were initially designed for enabling services in the home, but have now found wider applications in automotives, enterprise, communications, telematics, among many others.

In context of the home scenario too, the OSGi platform can be extended using the standard Java interfaces. For e.g. a UPnP

application bundle can implement a control point and

thus facilitate the discovery of other UPnP devices in the home network. Similarly, the HTTP service can be extended to discover the UPnP service and provide remote monitoring and control of the devices in the home. Other interesting use cases can be realized by implementing appropriate bundles. As a result, OSGi provides a platform of interest to service providers in order to offer advanced in-home services that are targeted at a wide range of user devices.

HGI The Home Gateway Initiative (HGI) is an industry body that aims at providing specifications and guidelines for home gateway (HG) devices. It adopts a use case approach to specify the technical requirements. The specifications are primarily aimed at fulfilling the service provider requirements of providing value-added services to the home, e.g. multi-play services. Also, the specifications are based on the premise that the home gateway would be a service-enabling device and would be provided and maintained by the service provider. It would therefore help in realising service awareness inside the home, a vital aspect that has been missing in home networks thus far.

Fig-4: OSGi Architecture

Page 8: Connected home

7 © Tech Mahindra Limited 2011

Some of the more specific use cases defined by HGI comprise of, home automation, home security, home surveillance, home office (SOHO), IMS based services, extended IPTV support, media servers support for providing content to different multimedia devices in the home, and providing IMS proxy for non-IMS devices on home networks. Based on these use cases, the HGI has defined requirements that the home gateway should satisfy, viz. end to end service delivery, ease of use, QoS, security, provision for remote management, performance monitoring and diagnostics of the services and devices. Fig-5 depicts a detailed architecture of the home gateway.

If we consider remote management as an example, the HGI use case facilitates the integration of UPnP technology for device and service discovery. It also allows the service provider to remotely manage the HG and all devices beyond it, i.e. inside the home area network, through a remote management system (RMS). In this context, HGI’s approach is based on DSL Forum’s TR-069 amendment that defines the CPE Remote Management Protocol. For end devices which do not support TR-069, the HG acts as a proxy and requires such end devices to support UPnP, DHCP or SIP, so that they are uniquely identified by the HG.

With regard to incorporating other technologies, it is also possible to integrate an OSGi gateway in the HG architecture.

This could be in the form of an integrated OSGi stack on the HG or separate OSGi devices interfaced with the HG.

As is evident, the HGI specifications are very flexible and thus open up a wealth of possibilities in enriching the functional capabilities of the home gateway and in increasing the level of service awareness inside the home premises.

Conclusion This paper provided a glimpse into some prominent service-enabling middleware technologies which contribute towards a digitally connected lifestyle. Though commercial implementations of in-home services are yet to gain momentum amongst service providers, we see that a combination of relevant technologies, such as UPnP-OSGi, OSGi-HGI, HGI-DLNA, can provide a platform to realize innovative services that can be monitored and controlled by the service provider. The paper also touched upon, how some of the key concerns of service providers, such as

Fig-5: Home Gateway Architecture

Page 9: Connected home

8 © Tech Mahindra Limited 2011

DRM, service protection and content security are being addressed by the enabling technologies.

References [1] UPnP Device Architecture 1.1

[2] UPnP AV Architecture, version 1.1

[3] UPnP® Certified Technology— Your Simple Solution for Home,Office and Small Business

Interoperability, Sep 2010

[4] http://www.upnp.org/

[5] Digital Living Network Alliance Home Networked Device Interoperability Guidelines

[6] DLNA for HD Video Streaming in Home Networking Environments

[7] http://www.dlna.org

[8] About the OSGi Service Platform, Technical Whitepaper, Revision 4.1

[9] OSGi Service Platform Core Specification, Version 4.2

[10] http://www.osgi.org

[11] Home Gateway Technical Requirements: Residential Profile, Version 1.0

[12] Home Gateway Initiative - Vision, Whitepaper

[13] http://www.homegatewayinitiative.org/