Audio/Video Interconnectivity domain and analysis of interoperability standards BY Khaleel Ali COMP 529
Overview of the presentation Different worlds of electronics Brief history of PC including Statistics UPNP Description, Implementation and problems Digital Living Network A k lliance (DLNA) Some UPnP products HAVI HA Description, Implementation and problems Conclusion
Three different worlds Personal computer or PC Monitor, or printer, er scanner, anner etc Consumer electronic products or CE Stereo, receiver, ver DVD player etc And Mobile Laptop, PDA, cell phone etc
Examples of some Consumer electronic products (CE)
Examples of some Consumer electronic products (CE)
WHY IS THIS HAPPENING NOW A NOW ND WHAT WHA ARE FA F CTORS THAT THA ARE CAUSING THIS INTERCONNECTIVITY OF PC, CE AND MOBILE DEVICES ?
First factor Price of PC has dropped to the lowest level in history. ry 10 years ago, cost of computers was around $3000 or more. Now one can buy a good system for about $300. eMachine Cel-2.6GHz Desktop + 17" CRT + Printer $210 after $400MIR from Bestbuy. y com Bundling PCs with online access services Extra rebates for signing up for an online service
Results of first factor By the end of 1999, 52% of U.S households had at least one PC, and 25% had multiple PCs according to International Data Corporation. By 2004 IDC expects 62% of households in U.S. will have at least one PC and 43% will have multiple PCs. Most households have at least one CE product.
Second factor Increasing growth of home-based offices More and more people are creating home offices for their own businesses and for completing tasks for their fulltime jobs. This subsegment of the home networking marketplace is less price sensitive and much more focused on the productivity returns of a given networking peripheral.
Third factor Increasingly Knowledgeable Consumers driving new applications. Consumers are more educated now than ever about the potential that PCs represent. No longer satisfied with just word-processing and e-mail, many consumers now demand Internet sharing, file sharing, gaming both within the same household and across the Internet, peripheral sharing including networked printers and even DVD video applications. Consumers using the ful est extent of the Internet are early adopters, their needs and focus on a wide variety of applications is already having an impact on how standards are defined and devices are designed and manufactured. Consumers are acquiring, viewing, and managing an increasing amount of digital media on devices in the CE, mobile and PC domains. They want to enjoy this content easily and conveniently – regardless of the source – across different
devices and locations in the home.
Results of second and third factors Users want faster home networks and access to internet
Now can the three worlds ever merge? Personal computers (PC) and consumer electronic products (CE) have always been viewed as separate entities. Speakers for computers, and stereo in a single room. TV and then a monitor connected to a PC in a single room. But technologies exist that can interconnect PC with CE. Common Digital media formats EX MP3, WAV A , V DVD, MPEG etc We can transfer media using: Wired and wireless networks as a backplane for device connectivity. y Broadband Internet connections for high-speed
access to Internet-based content.
So what was causing the delay in convergence? Standards were missing a widely-adopted, standards-based network technology to allow devices from the PC and CE worlds to offer their functionalities and advertise their services to other network devices. Consumers want Products designed for the home should be easy to install, provide obvious user value and be affordable. Digital home products must interoperate with each other and with existing consumer electronic devices such as TVs and stereos. Product Developer’s Dilemma Open industry standards are often too flexible – products built by different vendors al too often fail to interoperate wel . Design choices should be narrowed through industry consensus to better achieve interoperability. y Current end-to-end solutions based on proprietary vertical
implementations bring products to market early but have little impact on rapidly establishing a new category of products.
THE STANDARDS HAVE ARRIVED
First standard UPnP Universal Plug and Play Device Architecture (UPnP) Introduced in 1999 and backed by Microsoft, UPnP technology has been the preferred device discovery and control protocol. UPnP is more than just a simple extension of the plug and play peripheral model. There are more than 738 vendors in consumer electronics, computing, home automation, home security, a ity ppliances, printing, photography, y computer networking, and mobile products. Examples of UPnP devices Scanners, cameras, CD players, internet gateways etc Digital Media Adapters (DMAs), which allow the user to view content from the PC on the TV. V SOON Garage door openers, lights, and switches will be available with UPnP technology. y
Network of devices UPnP
So what is UPnP? UPnP Supports peer-to-peer architecture that allows network connectivity of intel igent appliances, wireless devices, and PCs of all form factors. Also supports DHCP and DNS servers and are used only if available on the network. (optional) offers Easy-to-use, flexible and standard-based connectivity to ad-hoc or unmanaged networks whether in home, smal business, public spaces, or attached to the Internet. Is designed to support zero-configuration, "invisible" networking, and automatic discovery device categories from a wide range of vendors. A devi A ce can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. A devi A ce can leave a network smoothly and automatically without leaving any unwanted state behind.
What is UPNP? (cont..) UPnP leverages TCP/IP, P UDP, P HTTP, TP SOAP, P the Document Object Model, and XML and the Web technologies to enable networking in addition to control and data transfer. er uses IP internetworking because of its proven ability to span different physical media to enable real world multiple-vendor interoperation and to connect with the Internet and many home and office intranets. Further, r via bridging, UPnP accommodates media running non-IP protocols when cost, technology, y or legacy prevents the media or devices attached to it prevents the media or de vices attached to it from running IP. P
The UPnP protocol stack
Devices in UPnP UPnP devices are a logical container with a unique type. provide self-describing information such as the manufacturer, r model name, and serial number. r offer any number of services, each service with its own unique service type. services provide the real functionality. y may also contain other devices logical composition of devices al ows the embedded device to be discovered and used indep endently from the main container device.
Class diagram of the UPnP Device
Device and their services in UPnP UPnP device is similar to an object, the services are like interfaces supported by the object, and the actions in a service are like functions in an interface. Each service in a UPnP device may contain any number of actions that Can have a set of input arguments return value Has a unique Service ID Uniform Resource Identifier (URI) variables that represent that service's current status
Class diagram of UPnP Service
Control Points in UPnP A A control point is a network entity that invokes a device's functionality. y In client/server computing terms, the control point is the client and the device is the server. r Control points invoke actions on services, providing any required input parameters and receiving any output parameters and possibly a return value. A A control point discovers devices, invokes actions on a device's services, and subscribes to event notifications. A A device, on the other hand, responds to invoked actions, sends events when state variables change, and supports a Web page for administrative control
A c A ontrol point invoking an action on a service
How does UPnP work? 1. Addressing
Device requests IP from DHCP if available. 2. Discovery
Control points and/or devices must discover each other. r 3. Description
Device sends its information to control point 4. Control
Control points can now send action messages to device(s) 5. Eventing
Changes in device status is sent to control point 6. Presentation
Addressing is the process by which a device automatically acquires an IP address. is the first step in the operation of a UPnP device. allows a device to join the network and to prepare to communicate with other UPnP devices and control points. protocols are built in to UPnP devices which allow devices to join an IP network dynamically and to acquire an address without user configuration. takes into account whether a device is operating in an unmanaged or managed network. A A device first attempts to contact a DHCP service to acquire an address. If it fails to locate a DHCP server, ver the device uses Auto- IP, P which enables devices to select addresses without a DHCP server being present to assign that address. The addresses are taken from a set of well-known, non-routable addresses. DHCP is a UDP-based protocol, while A e uto-IP uses the A he ddress Resolution Protocol (ARP).
Description Description al ows devices to list the functionality they provide. Description of devices and their services are contained in XML-based description documents. Device description document contains device information such as manufacturer, r make, model, and serial number; a list of services provided by the device; and a list of embedded devices. A A service description document contains detailed information about a device's service, the actions that service provides, and the service's parameters and return value. The description documents are used by control points in the device discovery process to learn more about a
Discovery defines how a device announces its presence, and how control points discover it. A UPn A P device is like a mini network server that can be discovered and controlled by a UPnP control point. process enables control points to find devices and services of interest and retrieve information about them. Is done by Simple Service Discovery Protocol (SSDP). SSDP extends the HTTP (Hypertext Transfer Protocol) header to provide a simple multicast-based discovery protocol. Once a device has acquired an IP address, that device periodically advertises itself and its services on the network. A dev A ice includes a URL of its device description XML XML document in its advertisement and discovery responses. That URL provides control points with the information those control points need to retrieve the device and service descriptions. The description documents are retrieved by control points and parsed to understand all about that device. A ven A dor can add extensions beyond the basic functions and include those extensions in the description docs. That extension mechanism allows a control point to prefer an optional or vendor-specific interface over the standard one.
Discovery (Cont..) Every service contained in a device maintains three URLs that provide the information necessary for control points to communicate with that service: The ControlURL is where control points post requests to control the service. A . UP A nP device vendor specifies one for each device. The EventSubURL is where control points post requests to subscribe to events. There is one EventSubURL for each service in a device. The DescriptionURL tells control points the location to retrieve the service description document from.
Control Control is the UPnP phase when control points invoke the actions of a device's services. When a service receives a control message, that service acts upon that message. UPnP relies on the Simple Object Access Protocol (SOAP) for device control. SOAP brings together XML and HTTP to provide a Web-based messaging and remote procedure cal mechanism. XML expresses the message content, while HTTP sends messages to their destination. SOAP is specified as a set of conventions that govern the format and processing rules of SOAP messages.
SOAP The SOAP message is the basic unit of communication between peers. SOAP messages are written in XML, making SOAP platform independent: any system capable of creating and parsing XML documents can send and receive SOAP messages. The power of XML al ows SOAP messages to be fairly complex in structure and to transmit highly complex data types. SOAP consists of four parts: The SOAP envelope: An XML An XML schema that defines a framework for describing what is in a message, how to process it, and whether that processing is optional or mandatory. ry The SOAP encoding rules Ano s ther XML er XML schema that defines a set of rules for expressing instances of application-defined data types. The SOAP binding: A g: A convention for using different transport protocols. SOAP can potentially be used in combination with a variety of other transport protocols (however SOAP messages are most commonly carried by HTTP). The SOAP RPC representation: A on: conv A ention for representing remote procedure calls and responses.
Eventing An event is a message from a service to subscribed control points. Events keep control points informed of changes in state associated with a service. Control points subscribe to events, and the service notifies interested control points of events. A A control point interested in receiving notification of state variable changes subscribes to an event source by sending a subscription request that includes: The service of interest A A URL to which the events can be sent A A subscription time for the event notification A A subscription is a request to receive al state variable changes. If a service accepts the subscription request, that service responds with a unique subscription identifier and the duration for the subscription. The duration specifies the length of time that the subscription is
valid and maintained by the service.
Eventing (cont..) Al subscribers are sent al event messages. Subscribers receive event messages for al evented variables, and event messages are sent regardless of the reason the state variable changed. UPnP's only guarantees that a message gets delivered to a subscriber is that it the eventing protocol (GENA) uses TCP for transport. When a subscription expires, the subscription identifier becomes invalid, and the publisher stops sending event messages to that subscriber. r Al subscriptions must be renewed periodical y for the control points to continue to receive notifications. To T keep a subscription active, a control point must send a renewal message before that subscription expires. When a control point no longer wants to receive events from a service, the control point can cancel its subscriptio n.
Presentation Presentation is the process where a device presents a browser-based user interface for manual user control and to al ow viewing of that device's status. Each UPnP device contains an internal HTTP Web server and may provide a Web page for browser-based clients. That Web page serves as the device's manual interface that complements the device's programmatic SOAP- based control interface. The browser-based interface is used to control the device, to change operational parameters, to view device and service information, or for any other device-specific functionality implemented by the manufacturer. r The presentation page provides a simple, consistent way to work with UPnP devices and requires no custom software.
DIGITAL LIVING NETWORK ALLIANCE (DLNA) AND ITS VISION • To have a computer (PC) or consumer electronic product (CE) that controls the whole house entertainment system(s). • Reasons: – Convenience and availability • All movies, music, pictures etc available on any device in network. • Access to all equipment that are part of the network. • Management of all equipment that are part of the network. • Re mote sharing of resources.
DLNA ex DLNA pectations The Internet, mobile and broadcast islands will integrate through a seamless, interoperable network that will provide a unique opportunity for manufacturers and consumers alike. Digital homes wil contain one or more intelligent platforms, such as an advanced set-top box (STB) or a PC. These intelligent platforms will manage and distribute rich digital content to devices such as TVs and wireless monitors from devices such as digital stil s cameras, camcorders and multimedia mobile phones.
DLNA in A teroperability guidelines V1.0
DLNA in A teroperability guidelines V1.0 (cont..)
DLNA in A teroperability guidelines V1.0 (cont..)
UPnP products in market
Problems with UPnP
Problems with UPnP (cont..) • DVD resolution is 720 x 540. • The gross transfer rate is generally somewhere between 12 and 14 Mbit/s, making the real rate around 5.5 to 6 Mbit/s. That's enough to play MPEG-1/2 videos in (S)VCD and mid-range DVD quality. y This test was conducted by Tom T shardware.com • Price of UPnP entertainment center and other products is high.
SECOND STA T NDARD HAV A I Home A e udio Video interoperability (HAV A i) provides a home networking standard for seamless interoperability between digital audio and video consumer devices. The main reason for having a dedicated HAV A i is the exchange of high quality digital video and audio signals. HAV A i is an initiative from eight major Consumer Electronics companies: Grundig AG, Hitachi, Matsushita , Panasonic, Philips , Sharp, Sony Corp, Thomson Multimedia and To T shiba Corp. More than 30 companies are involved in the development of HAV A I.
HAV HA i architecture The HAV A i architecture is open, scaleable in implementation complexity, y platform-independent and language neutral, i.e. HAV A i can be implemented in any programming language and on any CPU or real-time operating system. In order to be able to handle both commands and multiple digital audio and video streams, HAV A i uses the digital IEEE-1394, 1394a and future extensions, and IEC 61883 interface standards network. IEEE-1394 currently provides a bandwidth of up to 800 Mb/s and is capable of isochronous communication which makes it suitable to simultaneously handle multiple real-time digital AV A streams. Longer transmission distances under the IEEE 1394 standard are near to completion and wil allow the IEEE-1394 network to span multiple rooms in a home.
A HA A V HA i network
Promises of HAV of HA i Time synchronization between different devices. TV set might get the correct time from the broadcast stream and the other devices can query the TV and set their own clocks according to it. Recording can be as simple as just browsing the program information, selecting the desired program and pressing one button to activate recording. automatic directing of an oncoming videophone cal to the TV screen or part of it and muting al other sounds. camera placed outside the door detects movement, the picture is automatical y connected to the TV screen notifying the user about a possible visitor.
Promises of HAV HA i (cont..) The interoperability of HAVi devices not complex. Devices are hot-pluggable and they automatical y announce their presence and capabilities to other devices and configure themselves when connected to the Network. This saves the user from reading installation instructions and configuring network addresses and drivers. HAVi standard promises to be future proof by maintaining current functionality while making it easy to upgrade and add new capabilities. Non-HAVi devices can also be connected to the network if at least one of the HAVi devices supports the interface the legacy device provides. Two categories of legacy devices are non-1394 devices 1394 devices not supporting the HAVi Architecture
HAVi’s Future-Proof Support the HAVi Architecture supports future devices and protocols through several software-based mechanisms. These include: persistent device-resident information describing capabilities of devices a write-once, run-everywhere language (Java), used for software extensions a device independent representation of user interface elements Each HAVi-compliant device may contain persistent data concerning its user interface and device control capabilities. This information can include Java bytecode that can be uploaded and executed by other devices on the home network. As manufacturers introduce new models with new features they can modify the bytecode shipped with the device. The new functionality added to the bytecode mirrors the new features provided by the device. Similarly new user interface elements can be added to the stored UI representation on the device.
Plug-and-Play Support Home network consumer devices are easy to instal , just connect the cables and no configuration is necessary. In the HAVi Architecture, a device configures itself, and integrates itself into the home network, without user intervention. Home networking technology offers “hot” plug-and-play (not requiring the user to switch off devices), and safe and reliable connections. Low-level communication services provide notification when a new device is identified on the network. Instal ing a device on the home network wil be simpler than stand-alone instal ation since new devices can obtain configuration information from those already on the network.
a DTV receiving time signals via digital broadcast.
HAV HA i A i rchitecture The HAVi architecture can be divided into several different layers. On the bottom there is always vendor specific hardware and software Application Programming Interface (API) that HAVi is built upon. there is the connecting IEEE 1394 wiring, which HAVi devices use as a connecting medium. Medium layer a media manager for IEEE 1394 is needed as well as a messaging system. On top of the messaging system there are several software modules: Registry, Event Manager, Stream Manager, Resource Manager, Device Control Modules (DCM) and DCM managers. Top layer Havlets and application for user interaction with UI mechanism
Diagram of HAV HA i A i rchitecture
HAV A i A i rchitecture 1394 Communication Media Manager – al ows other software elements to perform asynchronous and isochronous communication over 1394. Messaging System – responsible for passing messages between software elements. Registry – serves as a directory service, al ows any object to locate another object on the home network. Event Manager – serves as an event delivery service. An event is the change in state of an object or of the home network. Stream Manager – responsible for managing real-time transfer of AV and other media between functional components. Resource Manager – facilitates sharing of resources and scheduling of actions. Device Control Module (DCM) – a software element used to control a device. Within a DCM code unit are code for the DCM itself plus code for Functional Component Modules (FCMs) for each functional component within the device. DCM Manager – responsible for installing and removing DCM code units on FAV and IAV devices.
DCM is the heart of HAV HA i The first DCM characteristic is how the DCM is obtained by the controller: embedded DCM – a DCM that is part of the resident software on a control er. uploaded DCM – a DCM that is obtained from some source external to the controller and dynamically added to the software on the control er. The second characteristic is whether a DCM is platform (controller) dependent or platform independent: native DCM – a DCM that is implemented for a specific platform, it may include machine code for a specific processor or access platform specific APIs. bytecode DCM – a DCM that is implemented in Java bytecode. Final y, DCMs can be distinguished by their functionality (or, conversely, their range of use): standard DCM – a DCM that provides the standard HAVi APIs. Such a DCM provides basic functionality but is able to control a wide range of devices. proprietary DCM – a DCM that provides vendor-specific APIs (in addition to the standard HAVi APIs). Such a DCM would offer additional features and capabilities over a standard DCM but could control a narrower range
of devices, perhaps only a specific device or model.
HAV HA i devices
HAVi devices HAVi devices are classified into four categories Ful AV devices (FAV), Intermediate AV devices (IAV) Base AV devices (BAV) and Legacy AV devices (LAV). HAVi compliant devices fall into the first 3 categories and all other devices belong to the 4th category. FAVs and IAVs are controlling devices in the HAVi network. BAVs and LAVs are the devices they control.
Full AV devices (FAV), A A Ful A V A device contains a complete set of the software elements comprising the HAV A i Architecture. FA F V A supports a complex software environment. FA F V A devices have a runtime environment for Java bytecode. This al ows an FA F V A to upload bytecode from other devices and so provide enhanced capabilities for their control. Example of FA F V A devices are Set To T p Boxes (STB), Digital TV receivers (DTV), general purpose home control devices
and Home PC’s.
Intermediate AV (IAV) Intermediate AV devices are lower in cost than FAV devices and more limited in resources. They do not provide a runtime environment for Java bytecode. Cannot act as controllers for arbitrary devices within the home network. IAV may provide native support for control of particular devices on the home network.
Base AV devices (BAV) These devices implement future-proof behavior by providing uploadable Java bytecode, but do not host any of the software elements of the HAVi Architecture. These devices can be controlled by an FAV device via the uploadable bytecode or from an IAV device via native code. The protocol between the BAV and its controller may or may not be proprietary. Communication between a FAV or IAV device and a BAV device requires that HAVi commands be translated to and from the command protocol used by the BAV device.
Legacy AV devices (LAV) LAV devices are devices that are not aware of the HAVi Architecture. These devices use proprietary protocols for their control, and quite frequently have simple control- only protocols. Such devices can work in the home network but require that FAV or IAV devices act as a gateway. Communication between a FAV or IAV device and legacy device requires that HAVi commands be translated to and from the legacy command
HAV HA I configuration
IAV or FAV as controller
IAV or FAV as Display
Interoperability in the HAVi Architecture The first and foremost goal of the HAVi Architecture is to support interoperability between AV equipment. This includes existing equipment and future equipment. Because of the need to support existing devices, and because of product cost considerations, the HAVi Architecture supports two levels of interoperability. Level 1 and Level 2. The flexibility of choosing different levels of interoperability gives vendors the freedom to design and build devices at al points on the cost/capability spectrum.
Level 1 Interoperability Level 1 interoperability addresses the general need to allow existing devices to communicate. Level 1 interoperability defines and uses: a generic set of control messages (commands) that enable one device to talk to another device and a set of event messages that it should reasonably expect from the device.
Level 1 Interoperability (cont..) Device discovery HAVi Architecture has adopted is to utilize Self Describing Device (SDD) data, required on al FAV, IAV and BAV devices. SDD data contains information about the device which can be accessed by other devices. Communication a general communication facility al owing applications to issue requests to devices. This service is provided by the HAVi Messaging Systems and DCMs. The application sends HAVi messages to DCMs, the DCM then engages in proprietary communication with the device. HAVi message set: is a wel defined set of messages that must be supported by al devices of a particular class. This ensures that a device can work with existing as wel as future devices, irrespective of the manufacturer. The HAVi message set includes those messages used for the DDI protocol and so al ows DCMs (and applications) to construct
a UI on display-capable IAVs and FAVs.
Level 2 Interoperability To support non-standard features of existing products and to support future products, the HAVi Architecture allows uploaded DCMs as an alternative to embedded DCMs. Uploaded DCMs are implemented in Java bytecode. Level 2 only requires that one device provide a runtime environment for the uploaded DCM obtained from the new device. The concept of uploading and executing bytecode also provides the possibility for applications called havlets. Havlets may be device specific Havlets can be uploaded and installed by each FAV device on the network. Havlet can be supplied by DCMs and/or the user via Level 2 UI. Display-cap able FAVs will allow a us er to upload and execute the havlet of any DCM or Application Module.
Security in HAV HA i HAVi uses a two-level protection scheme. When a software element is created it is assigned an access level which is one of trusted or untrusted. When one software element sends a request to another software element the receiver decides whether or not to honor the request by examining the access level of the requester.
Security in HAV A i Al uploadable DCM code units shall be signed. The HAVi Certification Authority (HCA) also issues several pairs of private key and public key to each vendor on request, with the HCA's digital signature for the vendor unique public key. A HAVi-signed code unit includes some specific files necessary for authentication in the JAR file. When an FAV is to install a HAVi-signed code unit, it has to verify the code unit with these files in advance to install the software element.
Certificate File The signature file is verified with the ‘vendor-unique public key’ which corresponds to the vendor-unique private key that is used to generate the signature. The ‘vendor-unique public key’ must be certified by the HCA. The verifier module in an FAV can find the ‘vendor-unique public key’ to verify the signature in this file, and shall verify whether the public key is trusted.
PROBLEMS WITH HAVI HAVi as a technology hasn’t been widely tested and utilized in real environments. One of the most important goals is platform- independent interoperability. FireWire stil isn’t as flexible and has proven to be very complicated to implement. The only guarantee is that devices of the same brand and same and same kind of proprietary programming wil most likely work together. Until al the major problems with FireWire have been solved, they wil hinder HAVi. One important issue when dealing with home entertainment is digital rights management. HAVi has no digital rights management
PROBLEMS WITH HAVI (cont..) Faulty device might get an update containing a virus which it then uploads to every other device. Cost of HAVi products are high. Very few products on market as of yet. Linux and java have problems such as real-time resource management and making the memory footprint small enough. Competition by UPnP, and now UPnP with Pre N technology. Communication medium needed to connect to internet. HAVi doesn’t support XML and SOAP.
CONCLUSION HAV ON HA i or UPnP No devices available for HAV r HA i More problems associated with HAV HA i UPnP is fairly new but functional UPnP is in sync with today’s technology XML, SOAP, P WEB, wireless etc Bridge between UPnP and HAV A i is missing or just on paper. r Digital management and security in HAV A i