Digital Home Network Reference Architecture Definition

939 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
939
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Digital Home Network Reference Architecture Definition

  1. 1. Multimedia Networking IST-Project: FP6-507452 Digital Home Network Reference Architecture Definition Deliverable DA.3.1v2 Target release version: V2_0 Dissemination level: PU
  2. 2. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 1 Document Title Digital Home Network Reference Architecture Definition Type Deliverable Ref DA.3.1v2 Target version V2_0 Current issue V2_0 Status Released File DA.3.1v2_DigitalHomeNetworkReferenceArchitectureDefinition_V2_0 Author(s) Jurjen Eisink (PHI) Reviewer(s) WPA3 members Approver(s) Peter van Grinsven (SPC Leader), Serge Travert (SPA Leader) Approval date 25/11/2005 Release date 1/12/2005 2 Distribution of the release version Dissemination level PU Distribution list (for RE documents) 3 History Date Version Comment 07/05/2004 V0_1 Creation 01/10/2004 V0_2 Added input from MediaNet reference architecture 30/11/2004 V0_3 Reworked after first review 16/12/2004 V0_4 Reworked after review 21/12/2004 V1_0 Approved and released version (DA.3.1v1) 10/01/2005 V1_1 Addition of In Home Bandwidth Management 28/10/2005 V1_2 Reworked after review 11/11/2005 V1_3 Reworked after review 25/11/2005 V1_4 Some minor editorial changes 30/11/2005 V1_5 Minor addition to conclusions section 01/12/2005 V2_0 Approved and released version (DA.3.1v2) 4 References [RefArch] DA1.1 The MEDIANET Reference Architecture and Common Interfaces [IA3.3] Network Management [TR-058] Multi Service Architecture and Framework Requirements [TR-094] DSL Forum TR-094 MEDIANET 2/63 IST-Project: FP6-507452
  3. 3. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 5 Abbreviations ADSL Asynchronous Digital Subscriber Line AMI-C Automotive Multimedia Interface Collaboration ASG Application Service Gateway ASP Application Service Provider ATM Asynchronous Transfer Mode BB BroadBand CA Conditional Access CAC Call Admission Control CDC Connected Device Configuration CPE Consumer Premises Equipment DHCP Dynamic Host Configuration Protocol DLNA Digital Living Network Alliance DRM Digital Right Management DSL Digital Subscriber Line DVB Digital Video Broadcasting DVB-IPI Digital Video Broadcasting - Internet Protocol Infrastructure EPG Electronic Program Guide EUT End User Terminal FPD Functional Processing Device FTP File Transfer Protocol HDTV High Definition Television HN Home Network HTTP Hyper Text Transfer Protocol IP Internet Protocol ISP Internet Service Provider ITV Interactive Television LAN Local Area Network MIDP Mobile Information Device Profile MM Multimedia MP3 Moving Pictures Expert Group 1 Audio Layer 3 MPEG Motion Pictures Expert Group NAPT Network Address and Port Translation NAT Network Address Translation NSP Network Service Provider NVOD Near Video On Demand OSGi Open Service Gateway initiative PC Personal Computer PON Passive Optical Network PPPoE Point to Point Protocol over Ethernet PVR Personal Video Recorder QoS Quality of Service RG Routing Gateway RRS Resource Requirements Set RSS Resource Selection Set MEDIANET 3/63 IST-Project: FP6-507452
  4. 4. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 RSVP Resource Reservation Protocol SIP Session Initiation Protocol SLA Service Level Agreement STB Set Top Box TCP/IP Transmission Control Protocol / Internet Protocol TV Television UPnP Universal Plug and Play VDSL Very high date rate Digital Subscriber Line VLAN Virtual Local Area Network VoIP Voice over IP VPN Virtual Private Network WAN Wide Area Network WEP Wired Equivalency Protocol WPA Wi-Fi Protected Access XML eXtensible Markup Language 6 Abstract This document describes the In-home reference Network Architecture. The In- home reference architecture is defined using the MediaNet reference architecture and the requirements imposed by the various Use-Cases defined within the MediaNet project. MEDIANET 4/63 IST-Project: FP6-507452
  5. 5. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 7 Content 1 Document ........................................................................................................................................ 2 2 Distribution of the release version ................................................................................................... 2 3 History.............................................................................................................................................. 2 4 References ...................................................................................................................................... 2 5 Abbreviations................................................................................................................................... 3 6 Abstract............................................................................................................................................ 4 7 Content ............................................................................................................................................ 5 8 Introduction ...................................................................................................................................... 7 8.1 Executive summary................................................................................................................ 7 8.2 Project description.................................................................................................................. 7 8.3 Document Goal ...................................................................................................................... 9 9 Reference Architecture.................................................................................................................. 12 9.1 DSL-forum ............................................................................................................................ 14 9.1.1 WAN Management Protocol ............................................................................................ 15 9.2 UPnP .................................................................................................................................... 15 9.3 DLNA.................................................................................................................................... 15 9.4 OSGi..................................................................................................................................... 15 9.5 Quality of Service ................................................................................................................. 16 10 Requirements ........................................................................................................................... 17 10.1 DSL forum Requirements..................................................................................................... 17 10.1.1 Video Conferencing ..................................................................................................... 17 10.1.2 Remote Education ....................................................................................................... 17 10.1.3 Digital video ................................................................................................................. 17 10.1.4 Digital Media Server/Receiver..................................................................................... 17 10.1.5 Web browsing/Internet Sharing ................................................................................... 17 10.1.6 File and Peripheral sharing ......................................................................................... 17 10.1.7 Game Consoles........................................................................................................... 17 10.1.8 External Connectivity................................................................................................... 17 10.1.9 Intra Home Connectivity .............................................................................................. 18 10.1.10 WAN QoS .................................................................................................................... 18 10.1.11 Home Network QoS..................................................................................................... 18 10.1.12 Storage ........................................................................................................................ 19 10.1.13 Device Powering.......................................................................................................... 19 10.1.14 Requirements for functional components:................................................................... 19 10.1.15 U-R interface ............................................................................................................... 21 10.1.16 Tpdn interface.............................................................................................................. 21 10.1.17 Tcn interface................................................................................................................ 22 10.1.18 Home Network Management Functionality ................................................................. 22 10.1.19 Home Network Security............................................................................................... 24 10.2 Bandwidth Diagram.............................................................................................................. 25 10.3 Use Case Requirements ...................................................................................................... 26 10.3.1 Concurrent Use Use-Case (PHI)................................................................................. 26 11 In-Home Management.............................................................................................................. 29 11.1 Goals of In-Home Management........................................................................................... 29 11.2 In-Home Management Architecture Approach..................................................................... 29 11.3 Resources and Services ...................................................................................................... 29 11.4 Middleware ........................................................................................................................... 31 11.5 Discovery.............................................................................................................................. 31 11.6 State Management............................................................................................................... 32 11.7 Eventing Mechanism............................................................................................................ 34 11.7.1 Event Capabilities........................................................................................................ 35 11.7.2 Event subscription ....................................................................................................... 35 MEDIANET 5/63 IST-Project: FP6-507452
  6. 6. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 11.7.3 One Shot Events for state related events ................................................................... 35 11.7.4 Continuous events for non-state related events.......................................................... 36 11.7.5 Event notification ......................................................................................................... 36 11.7.6 Event re-arming for state related events ..................................................................... 36 11.7.7 De-subscription............................................................................................................ 36 11.7.8 Overview Event Mechanism, Subscribe, ReArm & DeSubscribe ............................... 37 11.8 Resource Management........................................................................................................ 37 11.8.1 Service – Resource Matching ..................................................................................... 38 11.8.2 Availability of Resources ............................................................................................. 39 11.8.3 Claiming Resources .................................................................................................... 39 11.8.4 Managing Device Specific Resources......................................................................... 40 11.8.5 Detecting Resource Conflicts ...................................................................................... 42 11.9 Service Management ........................................................................................................... 44 11.9.1 Lifetime control of Root Service .................................................................................. 45 11.9.2 Lifetime control of Services ......................................................................................... 45 11.9.3 Root Service – User Interaction .................................................................................. 47 11.9.4 Resolving Service Conflicts......................................................................................... 48 11.9.5 User Eventing .............................................................................................................. 48 12 Bandwidth Management........................................................................................................... 50 12.1 Bandwidth Management between LAN and WAN ............................................................... 50 12.2 In-Home Bandwidth management concept.......................................................................... 50 12.2.1 Bandwidth Resource ................................................................................................... 50 12.2.2 Routing resource ......................................................................................................... 53 12.3 Bandwidth management in relation with in-home management middleware ...................... 55 12.4 Relation UPnP QoS ............................................................................................................. 57 12.5 Bandwidth Enforcement ....................................................................................................... 57 12.6 Combining Resource Management and Bandwidth Management ...................................... 58 13 Conclusions .............................................................................................................................. 60 14 Appendix: Use Cases ............................................................................................................... 61 MEDIANET 6/63 IST-Project: FP6-507452
  7. 7. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 8 Introduction 8.1 Executive summary The role of this document is to describe the digital In-home network reference architecture. The digital In-Home network reference architecture is defined by the requirements imposed on the home network by the various applications, currently existing In-Home network technologies and the MediaNet Overall Architecture. This digital In-home network reference architecture serves as bases for any In-Home device and the overall In-Home networking topology. The main extension of the MediaNet In-Home networking architecture is the introduction of In-Home management allowing a uniform and open manner of interoperation between Services, including both Services offered by external Service Providers and In-Home Application Services. These extensions improve deployment of Networked Services and allow for a more user-friendly way of control of Application Services. The MediaNet In-Home management extension can be used as input for standardization. Possible target standardization bodies are the UPnP forum, DSL forum, DLNA and OSGi. 8.2 Project description MediaNet addresses the domain of digital multimedia personal communication and content distribution, as well as cooperation schemes between content owners, Service Providers, network access operators, and telecommunication, computer, components and consumer electronics industries. The objective is to remove the obstacles to end-to-end digital communications and content exchange, from content/Service Providers to customers and between persons, over shared broadband access and home network infrastructures at the same time. Assuming an open system reference architecture model (figure), MediaNet partners jointly study a number of critical constituents of the on-line delivery chain (the e-media chain), made of various technologies, equipment or Services, that are considered as pre-requisite elements for the creation of a myriad of new media Services, supplied by multiple – and sometimes cooperating sometimes competing - Providers and vendors in Europe. MediaNet also tackles DRM and economical models issues. MEDIANET 7/63 IST-Project: FP6-507452
  8. 8. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 home access application Services Appl Appl Appl Appl platform platform Appl Appl Appl Network Appl platform Home Access platform Network Services TCN U-R A10 Appl Appl platform platform Appl Appl Appl Appl Appl Appl Application Network End-user Service Access Home Provider Provider Environment Application Provider Customer Specific Application Application Shared ASP CPE Platform Application Application Platform Platform A10 U-R TCN Common CPN N-Service Residential Infrastructure Distribution Platform Gateway Network MEDIANET 8/63 IST-Project: FP6-507452
  9. 9. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 8.3 Document Goal This document describes the MediaNet Home network reference architecture. The home network reference architecture has to support the various use cases as described in the overall project and sub-projects of MediaNet. Some examples of use cases are listed in chapter 14 of this document. The architecture builds upon technology solutions from the various work-packages in WPA3/SPC, viz. o SPC1: residential gateway o SPC2: wireless networks o SPC3: distributed storage The reference architecture is defined using a top down approach, meaning that we start with the MediaNet use-cases, distil requirements from these use-cases and define a suitable architecture that satisfies these requirements. Usage Scenarios Requirements Reference Architecture Figure 1, Architectural definition process As a solid foundation for the MediaNet in home reference architecture the choice is made to re-use/extend the DSL forum reference architecture. Therefore only the technical extensions/differences to this architecture are included within this document. Assumptions for the home network: • Broadcast content is distributed in the home over coax up to the receiver module. This receiver can be hosted in e.g. a TV, set-top box or a PVR. After reception of analog content it is either rendered immediately or stored for e.g. time-shifted viewing. • All stored content or other content and control data is carried as IP traffic over wired or wireless links over the in-home network. Within WPA3 we concentrate on “functions” or “modules” rather than the actual packaging in “boxes” and on the corresponding protocols/standards that are needed to enable Services. This means that if we use the term “residential gateway”, we mean the “gateway function”, MEDIANET 9/63 IST-Project: FP6-507452
  10. 10. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 whether it is packaged in a separate box or integrated with other functions. In this way we distinguish roughly the following modules/functions: o Network termination (tuner, ADSL modem, cable modem, V90 modem etc.) o Residential gateway (hosting the DHCP, NAT/NAPT, routing/bridging functions etc.) o Service hosting function o Distributed Media Storage modules (recording and streaming of content) o Media Rendering module (including audio/video codecs etc.) o Display module (TV screen, monitor) Within MediaNet we have studied various interfaces of these modules/functions and pros and cons of possible locations of these functions/modules in the home network (centralized vs. distributed model). The project has focused on the following areas: o System architecture and corresponding protocols for (remote) managing the in-home network and for enabling managed Services o Residential gateway (SPC1) o Service hosting/management (OSGi, centralized vs. distributed, combination with UPnP) o Plug and Play of new Services/modules The goal is to deliver a complete solution of gateway, in-home devices and corresponding protocols for Service delivery and (remote) management. It is the intention to develop an open framework for Service delivery based as much as possible upon open standards. The Service concept is based on the idea of loosening the traditional association between the application and its enabling device. For this reason, the interface between the HN and the Devices (MM Mobile Term, MM Term, STB, storage) should be described and explained. By doing this, it should become clear how applications (running on other devices or the Service Hosting Platform) can use the device functions. (Media Rendering, storage, …) The application is decomposed in its basic functions and for each function a device is chosen in the network where the function is executed. This allows for example to implement a videophony application using a combination of media adapter, TV, web-cam and VoIP-phone instead of requiring a dedicated video-telephony device. Another advantage is the possibility to share the storage of all networked devices, e.g. Hard Disk Drives, which are part of many modern devices like PVR (Personal Video Recorder1). If needed or just to ease the system usage, the whole storage capacity may of course be extended with additional storage devices (SPC3: Distributed Storage System2). Some decisive benefits are revealing if the storages are shared. For instance, recordings may be seamlessly carried on, in cases when the storage capacity of the recording device is exhausted unexpectedly during recording time of a live broadcast for instance. Since the networked storage functions are co-operating together without the need of any user administrations, they are looking for free storage capacity in the system by themselves. An additional crucial advantage is the increase of data security if the stored data are mirrored. This may be done in a nifty manner: the data of two different storage devices may be “dovetailed” appropriately, so that consequently the total physical storage allocation will be nearly the same, as if no data would have been mirrored. 1 A PVR is also referred to as a hard disk recorder (HDR), digital video recorder (DVR), personal video station (PVS) , or a personal TV receiver (PTR) 2 The co-operation concept of the shared storage is being developed within the SPC3 working package Distributed Storage MEDIANET 10/63 IST-Project: FP6-507452
  11. 11. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 Application decomposition is also where Service management plays a role: discovering, enabling and controlling devices for running certain applications. Reference models (including the relationship with OSGi and UPnP) are developed and tested for delivery of Services from a server somewhere in the network towards the end-terminal in the home. MEDIANET 11/63 IST-Project: FP6-507452
  12. 12. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 9 Reference Architecture The MediaNet reference architecture [RefArch] follows the DSL Forum model issued in [TR- 058] (Service provisioning and public access part) and in [TR-094] (customer premises) depicted in the Figure 2 below. According to TR-58 Service Network End-user * A10 access U-R TCN S Home Providers provider Environment Content Creation ? According to TR-94 S (not in TR-094) Figure 2: Medianet reference architecture according to the DSL Forum model The DSL Forum provides the definition of reference points between segments on one hand and between common and dedicated elements on the other hand, for all the scenarios elements considered in MediaNet. Remark: The interfacing between the segments ‘content creation’ and ‘Service provisioning’ is not formalised today and this formalisation is outside the scope of MediaNet. The current state of the art is based on a number of standardised or proprietary media content formats, including related metadata, and ad hoc business interfaces, still implying ‘bricks and mortar’ approaches. The seamless integration of the content creation domain into the end-to-end e- media chain, incorporating DRM/CP schemes, is for further study. Within and between the 3 other segments, four main interfaces have to be considered in the descriptions of MediaNet scenario architectures: MEDIANET 12/63 IST-Project: FP6-507452
  13. 13. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 - The A10 interface between the Application/Network Service Provider networks and the Regional/Access network (A10/ASP and A10/NSP respectively) - The U-R interface connecting the Customer Premise to the Access Provider network - using the specific broadband access technology (xDSL, cable, Ethernet…) - The TCN interface between the routing gateway (RG) and the various distribution technologies connecting the different IP-capable customer devices within the customer premises. The later are of different types: o Functional Processing Device (FPD) associated to one of several End User Terminal (EUT) o Functional Processing Device and Terminal (FPD/T). The EUT is here embedded in the FPD. o Application Service Gateways (ASG) towards non IP-based sub-networks and devices The S interface (only mentioned in TR-058) between each IP-based customer device and the distribution technologies implemented in the home network Every scenario can therefore be described according to the generic architecture depicted in the Figure 3 below. 3 levels are considered: - The Application Specific Level: it includes all the dedicated functions for the application that cannot be shared by any other applications - The Cluster-Shared level, incorporating the functions that can be shared among a ‘cluster’ of applications of the same type, and either belonging to the same ASP or “sourced” to a service provider suppling several ASPs. For example: o In the Service Provisioning segment, the cluster-shared functions can be a CDN or a service platform environment. o In the End-user Home environment, it can be a common shared platform embedding an operation system (Windows, Linux, PalmOS, …) or an open middleware suitable for several applications (MHP, MHEG, JVM…). - The Common Infrastructure level, covering both the Access and Customer Premises Networks, and shared by all scenarios. Remark: Cluster-shared elements are described together with related scenarios and under the responsibility of scenario owners/contributors MEDIANET 13/63 IST-Project: FP6-507452
  14. 14. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 Application Network End-user Service Access Home Provider Provider Environment Application Provider Customer Specific Application Application APFI/P APFI/C Shared ASP CPE Platform Application Application Platform Platform A10 U-R TCN Common CPN N-Service Residential Infrastructure Distribution Platform Gateway Network Figure 3, generic application scenario architecture 9.1 DSL-forum The DSL forum document TR-94 defines an in-home networking architecture suitable for concurrent multi-Service multi-user home environments. Within TR-94 the following list of goals are to be achieved with the home networking architecture. • Ensure that the home network and its functionality are agnostic to the access technology used to deliver the broadband Services and QoS. This permits a wide array of access technologies (e.g., ADSL, ADSL2plus, VDSL., PON) to be used to deliver broadband Services to the home and minimizes the impact of changes in the access technology on existing home networking applications. • Assure interoperability and compatibility with network based Services. • Ensure that the home network and applications take advantage of the benefits delivered by the DSL access. In fact, the home network architecture should be an enabler to delivering multiple applications, both with and without QoS. • Minimize CPE complexity without sacrificing QoS functionality or flexibility. • Provide flexibility in the bundling of functions to enable equipment vendors and Service Providers to provide customers with enticing home network enabled applications tailored to their needs. • Provide a home network Management capability that is flexible enough to provide a ‘Plug it in and it works’ experience for those customers that choose to have a Service Provider manage their home network as well as a shared management role between the Service Provider and the technically savvy customers that wish to take an active role in their home network management. These goals largely correspond with the MediaNet goals. MEDIANET 14/63 IST-Project: FP6-507452
  15. 15. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 9.1.1 WAN Management Protocol To ensure the possibility to provide a “Plug it in and it works” experience to the home users, the DSLForum provides a complete framework described in TR-069. The primary capabilities are: - Auto-configuration and dynamic service provisioning - Software/firmware image management - Status and performance monitoring - Diagnostics All this framework and environment are exposed in details in MediaNet IA3.3 [IA3.3] deliverable. 9.2 UPnP According to the UPnP Forum: “UPnP™ technology is all about making home networking simple and affordable for users so the connected home experience becomes a mainstream experience for users experience and great opportunity for the industry. UPnP™ architecture offers pervasive peer-to-peer network connectivity of PCs of all form factors, intelligent appliances, and wireless devices. UPnP™ architecture leverages TCP/IP and the Web to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and everywhere in between. UPnP™ technology can be supported on essentially any operating system and works with essentially any type of physical networking media - wired or wireless - providing maximum user and developer choice and great economics” UPnP is the main in-home interoperability standard for networked devices. UPnP basically defines a separation between functions (called UPnP Service) and application (called UPnP control point), ways to control UPnP Services, discover UPnP Services and an eventing mechanism. Using UPnP it becomes possible to deploy applications which make use of multiple devices from multiple vendors. 9.3 DLNA The Digital Living Network Alliance defines guidelines for interoperability within the home. The DLNA guidelines are based on existing standards (e.g. UPnP and TCP/IP) and ensure that devices that conform to the DLNA guidelines are interoperable with each other. 9.4 OSGi The OSGi™ specifications define a standardized, component oriented, computing environment for networked Services. Adding an OSGi Service Platform to a networked device (embedded device as well as performant servers), adds the capability to manage the life cycle of the software components in the device from anywhere in the network. Software components can be installed, updated, or removed on the fly without ever having to disrupt the operation of the device. Software components are libraries or applications that can dynamically discover and use other components. Software components can be bought off the shelf or developed in house. The OSGi Alliance has developed many standard component interfaces that are available from common functions like HTTP servers, configuration, logging, security, user MEDIANET 15/63 IST-Project: FP6-507452
  16. 16. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 administration, XML, and many more. Plug compatible implementations of these components can be obtained from different vendors with different optimizations. The OSGi specifications were initially targeted at residential Internet gateways with Home Automation applications. However, the attributes of the standard made it applicable to other markets. For example, Nokia and Motorola are driving an OSGi based standard for the next generation smart phones. The vehicle industry adopted the OSGi specifications by making it an intrinsic part of the AMI-C specifications, which is supported by many car manufacturers. Also, the OSGi Service Platform has become a standard part of the BMW high-end telematics platform. OSGi technology also finds it way on the desktop, with Eclipse (a platform where tools can be plugged in) as an example how the OSGi specifications helped to solve the problem of dynamically updating the plug-ins that Eclipse is built upon. And last, but not least, OSGi technology is even ending up in consumer electronics, with the Philips iPronto as a prime example. The OSGi specifications are so widely applicable because it is a small layer that allows multiple, Java™ based, components to efficiently cooperate in a single Java Virtual Machine. The OSGi Framework can run on top of small footprint Java Virtual Machines (Java2 Micro Edition, CDC profile), up to more performing platforms. It provides a security model –based on Java 2 fine-grained security- so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments (Like MIDP). More information on OSGi can be found at www.osgi.org, where a white paper is available. In MediaNet, OSGi and its complementarily with UPnP is studied in Work Package C1 : see deliverable DC.1.2_ServiceHostingPlatform_V0_2.doc. 9.5 Quality of Service Quality of Service or QoS refers to the nature of the differentiated traffic delivery Service provided, as described by parameters such as achieved bandwidth, packet delay, and packet loss rates. Traditionally, the Internet has offered a Best Effort delivery Service, with available bandwidth and delay characteristics dependent on instantaneous load. There are different types of QoS: Best Effort: This term is used to refer to a traffic delivery Service without any bounds on QoS parameters. Relative QoS: This term is used to refer to a traffic delivery Service without absolute bounds on the achieved bandwidth, packet delay or packet loss rates. It is used to handle certain classes of traffic differently from other classes; Guaranteed QoS: This term is used to refer to a traffic delivery Service with certain bounds on some or all of the QoS parameters. These bounds may be hard ones, such as those encountered through such mechanisms as an ATM Call Admission Control (CAC) function or RSVP reservation. Other sets of bounds may be contractual, such as those defined in Service level agreements (SLAs) that often typically define a monetary penalty should a certain threshold be crossed or missed. MEDIANET 16/63 IST-Project: FP6-507452
  17. 17. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 10 Requirements Within this chapter the specific requirements imposed by DSL forum, application bandwidth demands and the MediaNet use-cases are described. 10.1 DSL forum Requirements Within the DSL forum a large number of requirements are defined for the In-Home network, these are: 10.1.1 Video Conferencing Req 1. Home networks SHOULD support video conferencing 10.1.2 Remote Education Req 2. Home networks SHOULD support 2 way interactive remote education. 10.1.3 Digital video Req 3. The home network MAY support different QoS for the niche video if required. 10.1.4 Digital Media Server/Receiver Req 4. The home network MUST support Digital Media devices with the collection, storage and delivery of digital content from the WAN. 10.1.5 Web browsing/Internet Sharing Req 5. The home network MUST support simple web browsing and sharing this capability among multiple PCs in the home. 10.1.6 File and Peripheral sharing Req 6. The home network MUST support file and printer network Services which allow for sharing and printing among multiple PCs in the home. 10.1.7 Game Consoles Req 7. The home network MUST support the evolving broadband enabled game consoles and SHOULD evolve to provide QoS capabilities that improve the gaming experience. 10.1.8 External Connectivity Req 8. Enable sharing of the BB access within the home by many devices, users and applications. Req 9. Provide physical connectivity to the access network for any device connected to the home network. The home network MUST provide these MEDIANET 17/63 IST-Project: FP6-507452
  18. 18. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 components with seamless access to the BB access capabilities (multiple channels, QoS). Req 10. Support connectivity to multiple Application Service Providers (ASPs) and Internet Service Providers (ISPs). Req 11. Support incoming as well as outgoing access to the Home Network for both customer and Service Providers. Req 12. Provide appropriate QoS delivery from the WAN to and from the home network. Req 13. Support IP multicast to the extent needed to permit reception of 1 or more multicast streams by devices within the home network simultaneously. Req 14. Be transparent to the applications connected to the home network (e.g., support of SIP sessions for IP telephony, IP VPN transparency). 10.1.9 Intra Home Connectivity Req 15. The home network MUST support intra-home connectivity. 10.1.10 WAN QoS Req 16. The home network architecture MUST support ATM, IP and Ethernet QoS mechanisms used with traffic arriving at and leaving the customer premises. 10.1.11 Home Network QoS Req 17. The relative QoS within the home network MUST be based on the IEEE 802.1q (VLAN) and IEEE 802.1D Annex H.2 (User Priorities and Traffic Classes) standards. Any L3 and above QoS mechanisms will be carried transparently between devices in the home and the routing gateway. Applications operating within the home network may mark IP traffic with different DiffServ code points; however they must encapsulate those IP packets in a tagged Ethernet frame constructed with an appropriate traffic class in the priority field of the IEEE 802.1q VLAN tag. Req 18. A mapping function between the WAN and LAN QoSs SHOULD be employed. Req 19. Two or more traffic classes SHOULD exist in the home network. A ‘Best Effort’ traffic class will always exist and provide the default mode of QoS operation. This ensures backward compatibility with the ad hoc home networks being created by customers today. Req 20. One or more higher quality traffic classes SHOULD exist within the home network Req 21. All devices and applications using these additional traffic classes MUST be aware of and behave responsibly within the QoS home network so as to ensure acceptable application performance. Req 22. The IEEE 802.1D Annex H.2 priority field SHOULD be mapped as defined in CEA-2007. This standard creates four types of QoS that can operate simultaneously in the same network. The four types are: 1. Best Effort effectively implies that no QoS treatment is applied to traffic MEDIANET 18/63 IST-Project: FP6-507452
  19. 19. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 marked with this priority. 2. Prioritized QoS represents traffic with relative QoS. Any prioritized QoS traffic gets better treatment than Best Effort. 3. Parameterized QoS represents traffic that requires a guarantee of one or more QoS parameters e.g. latency, jitter or packet loss. Parameterized QoS traffic gets better treatment than Prioritized QoS traffic. 4. Critical QoS is normally reserved for network control messages (channel changes, device mgmt., etc) and not used for content. 10.1.12 Storage Req 23. The home network SHOULD support some form of network-attached storage for caching and/or long-term storage. 10.1.13 Device Powering Req 24. To meet this expectation, the home network MAY be required to have a backup power source for both the home network infrastructure itself (i.e., the broadband modem and the LAN switches) as well as provide power to the VoIP terminal devices. 10.1.14 Requirements for functional components: Figure 4, functional component according DSL Forum TR-94 10.1.14.1 Broadband network termination Req 25. The B-NT function MAY be integrated with the RG in many products to simplify the implementation and control of QoS between the home network and the DSL access. Req 26. When the B-NT is not combined with the RG, The B-NT MUST support 10/100BaseT Ethernet toward the home network. Req 27. The B-NT SHOULD implement the WAN side QoS mechanisms and make them accessible via the ‘TPDN’ interface. MEDIANET 19/63 IST-Project: FP6-507452
  20. 20. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 Req 28. The xTU-R function terminates the BB access line in the customer premises. The specific type of xTU-R function will be determined by the particular access technology used to deliver BB Service to the home network. 10.1.14.2 Routing Gateway Req 29. The RG SHOULD support a minimum of one PPPoE termination with the ability to connect directly with a BRAS. Req 30. The RG SHOULD support a capability of initiating multiple PPPoE sessions. Req 31. The RG SHOULD support a PPPoE pass-through capability to permit appropriately featured Functional Processing Devices (FPD) with the ability to connect directly with a BRAS. Req 32. There SHOULD be only one RG function for each home network. Req 33. The RG MUST implement Relative QoS awareness at layer 2 (IEEE 802.1Q and IEEE 802.1D Annex H) on the LAN side. Req 34. The RG SHOULD implement IP based QoS mechanisms (DiffServ) on the WAN side of the RG. Req 35. On the LAN side, an RG MAY distinguish the different traffic classes using either physical means (i.e., physical ports are mapped to one traffic class) and/or using frame-by-frame techniques (i.e., using the user priority field of the IEEE 802.1Q VLAN tag). Req 36. The RG SHOULD map between the various Relative QoS Services used in the home network and the appropriate QoS enabled virtual channel(s) available from the network. The mapping will be based on one or more characteristics of the data, one being the Relative QoS from the LAN side. The specific policies for doing so will be managed by the access Service Provider. Req 37. The RG SHOULD provide firewall and network address with port translation (NAPT) capabilities for the home network. When the RG provides these functions, it MUST also provide the functions required for applications to work through or across the firewall and the NAPT. Req 38. The RG should play a major role in the management of the home network. At a minimum, the RG SHOULD be involved with: LAN+WAN connection mapping QoS mapping and policy Local IP address management (e.g., DHCP) Security configuration 10.1.14.3 Premises distribution Req 39. The home network MUST be capable of supporting IP packets encapsulated by IEEE 802.3 Ethernet frames. Req 40. Any intra-home connectivity SHOULD be implemented using LAN switch technology in order to provide the best possible application performance. Shared media hub devices SHOULD NOT be used. Req 41. LAN switches used for home networks SHOULD provide multiple physical connections for connected devices within the home network allowing MEDIANET 20/63 IST-Project: FP6-507452
  21. 21. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 the DSL access to be shared by multiple end users and applications within the home. Req 42. LAN switches used for home networks SHOULD support 10/100BaseT connections and include automatic speed as well as duplex (half or full) negotiation. Req 43. Cascading of multiple LAN switches SHOULD be avoided to prevent congestion and poor application performance that could result from overloaded ‘uplink’ network segments. Req 44. LAN switches for home use SHOULD support QoS features. Req 45. Any premises distribution technology used to support a L2 QoS aware device MUST be capable of providing the necessary support to maintain the distinction between traffic with varying types of QoS. Req 46. Structured wiring SHOULD be used for the home network whenever possible. Req 47. All FPDs MUST be IP aware and will function as an application specific IP host on the home network. This does not preclude the implementation of multiple FPD entities within a single physical device. Req 48. The connectivity Services provided by the home network and broadband access MAY be used by the application to manage the FPD. 10.1.14.4 Supplementary Application Network Req 49. The ASG MAY support a Home Distribution function running in addition to the Premises Distribution function already supported by the Home Network. In addition, the Supplementary Application Network MAY utilize the Premises Distribution network if the latter supports transport of non-IP traffic." 10.1.15 U-R interface Req 50. The B-NT MUST terminate at a single broadband U-interface. 10.1.16 Tpdn interface Req 51. When the B-NT and RG are implemented in separate devices, the TPDN interface MUST be limited to being a point-to-point layer 1+2 connection between the RG and the B-NT. Req 52. The data link layer MUST support Ethernet in accordance with IEEE 802.2/ IEEE 802.3 (Ethernet) Req 53. The data link layer MUST support the bidirectional delivery of PPP over Ethernet frames in accordance with IETF RFC 2516. Req 54. The data link layer MUST support the operation of DHCP. Req 55. The data link layer SHOULD support Ethernet virtual LANs (IEEE 802.1Q). Req 56. The data link layer SHOULD support Ethernet precedence of LAN traffic (IEEE 802.1D Annex H). Req 57. The data link layer SHOULD support the bidirectional delivery of IP packets. Req 58. The logical link controller sub layer sub interface MUST support Ethernet in accordance with IEEE 802.2. MEDIANET 21/63 IST-Project: FP6-507452
  22. 22. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 Req 59. The medium access control sub layer sub interface MUST support Ethernet in accordance with IEEE 802.3. Req 60. The physical layer for the TPDN interface MUST be a 10/100BaseT interface, using an RJ45 connector. Req 61. The TPDN interface MUST support the automatic negotiation of the speed without customer intervention. Req 62. The TPDN interface MUST support full duplex operation to ensure that traffic in the downstream or upstream direction does not affect traffic in the opposite direction. 10.1.17 Tcn interface Req 63. There MUST be a minimum of one TCN interface presented by an RG for connection to the premises distribution network. Req 64. The network layer MUST support IP version 4 in accordance with IETF RFC 1042. Req 65. The network layer SHOULD support IP version 6 in accordance with IETF RFC 2460. Req 66. The network layer interface SHOULD support IP precedence based on differentiated Service (Diffserv) code points in accordance with IETF RFC 3140. Req 67. The DiffServ requirements defined in TR-059 SHOULD be supported. Req 68. The home network MUST support DHCP functions. Req 69. The home network MUST support DNS functions. Req 70. The home network MUST support NAPT functions. Req 71. The home network MUST support UDP and TCP. Req 72. The data link layer MUST support Ethernet in accordance with IEEE 802.2/ IEEE 802.3 (Ethernet). Req 73. The data link layer MUST support the transport of PPP over Ethernet frames in accordance with IETF RFC 2516. Req 74. The data link layer SHOULD support Ethernet precedence of LAN traffic (IEEE 802.1Q and IEEE 802.1d Annex H). Req 75. The logical link controller sub layer sub interface MUST support Ethernet in accordance with IEEE 802.2. Req 76. The medium access control sub layer sub interface MUST support Ethernet in accordance with IEEE 802.3. Req 77. The TCN interface MUST support 10/100BaseT. Req 78. The TCN interface MUST support both full and half duplex operation. Req 79. The TCN interface MUST support the automatic negotiation of both the speed and duplex without customer intervention. 10.1.18 Home Network Management Functionality 10.1.18.1 Service Provider Management Req 80. Prime aspects of the home network that MAY be managed within the M domain include: B-NT configuration MEDIANET 22/63 IST-Project: FP6-507452
  23. 23. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 RG configuration including: o Connection mapping o NAPT configuration o QoS policy configuration Content security and digital rights management (DRM) Home network access security Req 81. It is anticipated that the RG will be a prime component of the home network involved in the SP management domain. The interaction of the RG with the network SHOULD be in line with the recommendations described in DSL Forum TR-69. 10.1.18.2 Customer Managed Domain Req 82. XML based technologies SHOULD be employed within the U domain in order to facilitate inter-working between customer and SP management. Req 83. Prime aspects of the home network that MAY be managed within the U domain include: RG configuration including o Mapping configuration o NAPT configuration o IP Addressing Home network access security Static and dynamic application configuration 10.1.18.3 IP Address Management Req 84. The home network MUST support IPv4 addressing. Req 85. The home network SHOULD be ready to support IPv6. Req 86. When the RG supports bridged connections, IP address assignment for FPD.s associated with these connections MUST be performed by mechanisms (DHCP, static) from within the ISP or ASPs network. Req 87. Any use of private IP addressing MUST be done in accordance with [DSL Forum TR-069, .CPE WAN Management Protocol.]. Req 88. The RG SHOULD support the following IP address assignment techniques on WAN interfaces: o IPCP within PPPoE o DHCP o Static IP configuration Req 89. The RG MUST accept any and all IP address assignments from the network. Req 90. The RG MAY be capable of accepting a subnet range of IP addresses from the WAN side for re-assignment to the LAN side of the home network. Req 91. When IPv6 support is available, the RG SHOULD be capable of accepting a subnet range of IP addresses from the WAN side for re- assignment to the LAN side of the home network. Req 92. When using routed IP connections, the following requirements apply: A: DHCP MUST be available for end users to assign addresses for those MEDIANET 23/63 IST-Project: FP6-507452
  24. 24. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 devices using the routing functions of the RG. B: Static IP addresses SHOULD NOT be used. C: Persistent IP address assignment (i.e., the same IP address is always assigned to a particular device) SHOULD be supported because it will be required by some applications. D: IP addresses on the TCN side of the RG SHOULD be assigned within a default IP address subnet. E: A home network MAY support multiple IP subnets within itself and the routing between them. F: In multiple PVC situations where bridged connections could be utilized, FPDs on the home network associated with those bridged connections will be assigned IP addresses from the network. This will normally be done using DHCP. Req 93. IP addresses SHOULD be assigned using IPCP within the device specific PPPoE session by the responding BRAS based on Service description (dynamic or persistent). Req 94. 1 IP address SHOULD be assigned per PPPoE session initiated. Req 95. The IP address assigned to the PPPoE FPD MUST NOT conflict with any IP addresses on the WAN or LAN side of the RG. 10.1.18.4 Domain Name Services Req 96. Dynamic DNS update capabilities MAY be implemented by RGs and PPPoE enabled FPDs to communicate IP address assignments to Dynamic DNS Services. 10.1.19 Home Network Security Req 97. The home network MUST provide protection from unwanted connection to the home network from outside. The two main aspects of this include: 1. Undesired connection from the WAN access into the home network as well as restricting specific LAN devices from accessing the WAN. This protection is usually provided by a device providing firewall functions between the home network and the WAN. 2. Unwanted access to the home network infrastructure itself when that infrastructure includes premises distribution media that are susceptible to unwanted access from outside the home. Examples of these types of media include 802.11 wireless and HomePlug. Protection from this type of unwanted access is achieved by the use of technologies such as the Wired Equivalency Protocol (WEP), Wi-Fi Protected Access (WPA), WPA v2, 802.11i and DES. Req 98. The home network SHOULD protect against and aid other security functions to protect against the following threats: 1. Trojan horse programs 2. Back door and remote administration programs 3. Denial of Service 4. Being an intermediary for another attack 5. Unprotected Windows shares MEDIANET 24/63 IST-Project: FP6-507452
  25. 25. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 Req 99. The home network SHOULD provide protection from unauthorized device configuration from within the home network; either by unauthorized users or rogue software (e.g., Trojan horse applications). Req 100. The home network MAY provide filtering and parental control of content; however, SP based filtering/control can also be applied. Req 101. The home network SHOULD support conditional access (CA) and digital rights management (DRM) mechanisms to prevent unauthorized use of content. Req 102. The home network MUST support remote access VPN clients. This support MUST be available to multiple FPD.s operating simultaneously on the home network. Req 103. The home network MUST support the use of encryption both within the home network and toward the broadband network. 10.2 Bandwidth Diagram The following bandwidths are assumed for the following applications, according DSL forum: TV Focused Services Typical Typical Delay Packet On bandwidth bandwidth bound loss demand (upstream) (downstream) Broadcast TV – e.g. MPEG2 2-6 Mb/s ~1s 105 Yes High definition TV – HDTV 12-19 Mb/s ~1s 105 Yes Pay Per View and NVOD – e.g. 2-6 Mb/s ~1s 105 Yes MPEG2 Navigator and EPG (can be locally <0.5 Mb/s N/a N/a No launched and updated in non real time) Picture in Picture – two MPEG2 Up to 12 Mb/s ~1s ~1% Yes channels Picture in Browser – one MPEG2 Up to 9 Mb/s ~1s 105 Yes ITV – TV telephony features <64 kb/s <64 kb/s <400ms ~1% Yes (RTT) ITV – TV browser Up to 3 Mb/s N/a N/a Yes/No ITV – TV e-mail 128 – 640 kb/s Up to 3 Mb/s N/a N/a No ITV – TV Instant Messaging 128 – 640 kb/s Up to 3 Mb/s N/a N/a No ITV – TV Chat 128 – 640 kb/s Up to 3 Mb/s N/a N/a No ITV – TV on screen notification <64 kb/s N/a N/a No ITV – TV interactive games 128 – 640 kb/s Up to 3 Mb/s ~10 ms 105 Yes ITV – TV audio Juke Box <128 kb/s ~1s <1% Yes Table 1, TV based bandwidth requirements Note that ongoing developments in video compressing can lead to a lower demand in bandwidth for related applications. MEDIANET 25/63 IST-Project: FP6-507452
  26. 26. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 PC Focused Services Typical Typical Delay Packet On bandwidth bandwidth bound loss demand (upstream) (downstream) High Speed Internet Access (browsing, IM, Chat, FTP, VPN, access, etc) - Residential (typical asymmetric) 128 – 640 kb/s Up to 3 Mb/s N/a N/a Yes/No - SME/SOHO (typical symmetric) Up to 6 Mb/s Up to 6 Mb/s N/a N/a Yes/No Server based E-mail As above As above N/a N/a No Live TV on PC 300 – 750 kb/s ~1s ~1% Yes Video on Demand 300 – 750 kb/s ~1s ~1% Yes/No Video Conferencing 300 – 750 kb/s 300 – 750 kb/s <400ms ~1% Yes/No (RTT) Voice/Video telephony 64 – 750 kb/s 64 – 750 kb/s <400ms ~1% Yes (RTT) Interactive Games 10 – 750 kb/s 10 – 750 kb/s ~10ms 105 Yes Remote Education 300 – 750 kb/s ~1s ~1% Yes/No Table 2, PC based bandwidth requirements 10.3 Use Case Requirements This paragraph contains the requirements added by the different MediaNet use- cases. 10.3.1 Concurrent Use Use-Case (PHI) 10.3.1.1 U-R interface This use-case adds additional requirements regarding bandwidth usage between Access-Network and Residential Gateway. In order to be able to control the bandwidth usage per application both upstream and downstream bandwidth negotiation has to be performed between consumer application and Service Provider. Req 104. Rationale: best effort traffic may not interfere with guaranteed Services. It must be possible to dynamically define QoS parameters for incoming streams at the U-R interface. Req 105. Rationale: best effort traffic may not interfere with guaranteed Services. It must be possible to dynamically allocate bandwidth for outgoing streams at the U-R interface. Req 106. Rationale: peer 2 peer networking must be supported. It must be possible to dynamically control QoS management from within the Home Network. 10.3.1.2 Tcn Interface Req 107. Rationale: Best effort in-home Services may not interfere with guaranteed Services. It must be possible to dynamically define QoS parameters for traffic at the Tcn interface. MEDIANET 26/63 IST-Project: FP6-507452
  27. 27. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 Req 108. Rationale: Managed Services must be controllable in Lifetime It must be possible to discover Services within the in-home network Req 109. Rationale: Managed Services must be controllable in Lifetime It must be possible to start Services within the in-home network. Req 110. Rationale: Managed Services must be controllable in Lifetime It must be possible to stop Services within the in-home network. Req 111. Rationale: Resource conflicts between managed Service must be avoided It must be possible to detect resources within the In-home network Req 112. Rationale: Resource conflicts between managed Service must be avoided It must be possible to claim resources for a managed Service Req 113. Rationale: Resource conflicts between managed Service must be avoided It must be possible to determine if resources can be claimed. Req 114. Rationale: Resource conflicts between managed Service must be avoided It must be possible determine which Service has claimed which resources 10.3.1.3 APFI/C interface Req 115. Rationale: Services must be manageable A Service must be able to add itself as a managed Service Req 116. Services must be manageable A Service must be able to remove itself as a managed Service Req 117. Services must be manageable It must be possible to discover all in-home managed Services. Req 118. It must be possible to start any managed Service Req 119. It must be possible to stop any managed Service Req 120. It must be possible to determine which Services can be started Req 121. It must be possible to determine which Services can be stopped. Req 122. A Service must be capable of defining its resource need during registration. Req 123. Rationale: Resources must be manageable A resource must be able to add itself as a manageable resource to the in- home network. Req 124. A resource must be able to remove itself as a manageable resource. Req 125. A resource must be claimable Req 126. A claim on a resource must be removable Req 127. It must be possible to detect which resources are claimed Req 128. It must be possible to detect which resources are claimable Req 129. It must be possible to detect who has claimed a resource. Req 130. Rationale: Control of Services must not influence current Services. Control related to the in-home management system must not interfere with currently active Services. Req 131. It must be possible to notify users, e.g. incoming phone call. Req 132. Events towards users must not interfere with currently active Services. MEDIANET 27/63 IST-Project: FP6-507452
  28. 28. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 MEDIANET 28/63 IST-Project: FP6-507452
  29. 29. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 11 In-Home Management This chapter contains an introduction about In-Home management without a specification of which functions are available at what interface. 11.1 Goals of In-Home Management In-Home networking protocols/architectures like UPnP offer ways to discover and control resources within the home. This enables interoperability between devices, but still leaves a gap when it comes to interoperability between Services/Applications. The goal of In-home management is to extend on interoperability standards, thereby enabling interoperability between Services. Using In-Home management the following benefits are created: • Concurrent use of multiple applications • Discovery of Services/Applications • Uniform life-time control of Services/Applications • Matching between (on-line) Services and in-home Resources • Personalisation of Services/Applications • ‘Plug and Play’ for Services/Applications 11.2 In-Home Management Architecture Approach In-Home management functions can be implemented using different architectures. One approach can be to use a Client – Server approach in which one device plays a central role. This could for instance be the Gateway or the In-home pc. Another approach is to use a distributed approach in which all in-home devices equally contribute to In-Home management. For the following reason the choice is made to use a distributed approach: • In-Home management extends to UPnP, UPnP uses a distributed approach • Prevent a Single point of failure • In-Home management is not a stand-alone function, so no market for an ‘In-home manager’ device • Evolutionary scenario: o must work without a PC o support existing gateways • Multiple parties benefit from In-Home management, therefore a single party will not be interested in paying for this functionality (e.g. provider paid gateway) 11.3 Resources and Services In order to enable a Plug and Play in-home architecture in which users can add new Resources to their in-home network and use these newly added Resources, an abstraction has to be introduced for Resources and applications. MEDIANET 29/63 IST-Project: FP6-507452
  30. 30. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 A Resource is comparable to an UPnP device and a Service is comparable to a UPnP Control Point. Comparable to UPnP, the current convention that a single device is capable of hosting a number of Services has to be replaced by a convention that a device implements a set of Resources and that a Service needs a set of Resources. Using this convention it becomes possible to host Services using a set of Resources, where these Resources can be implemented by a set of devices. The advantage of this separation is that the synergy between a set of devices is now available for Services. This creates both an added value for Service Providers and end-users (new Services without additional hardware). Resource1 Device1 Servi ce1 Resource2 Resource3 Device2 Servi ce2 Resource4 Figure 5, Devices, Resources and Services Example: Within a home the following devices and Resources are available: o VoIP telephone set; capable of rendering and capturing audio. o An IP connected display; capable of rendering video. o An IP connected camera; capable of capturing video. Using these Resources it becomes possible to create a video telephony Service, which uses the telephone set for voice rendering and capturing, the display for video rendering and the camera for video capturing. In the remainder of this chapter the system is further decomposed into individual functions and Resources, without taking into account their physical location in devices in the home or in the network. For the moment it is assumed that any combination of Resources is possible that is needed to run a Service. The set of Resources, their actual physical packaging (device) and the set of Services will vary over the life time of the In-Home system and the set of In-Home management supporting equipment attached to each other. MEDIANET 30/63 IST-Project: FP6-507452
  31. 31. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 11.4 Middleware A separation between Resources and Services is very nice, however one of the most complicating factors remains location dependency. If Resources and Services must operate in a true plug and play fashion much common functionality related to communication, discovery and eventing can be located in a single piece of middleware which ensures true location independence and distribution across the home. In-Home Host A Service S APFI/C Middleware In-Home Host B In-Home Host C Resource Resource Service Resource Resource S Resource Resource APFI/C APFI/C Middleware Middleware Figure 6, Middleware, Services and Resources The different Middleware instances communicate with each other using the Tcn interface. The Services and Resources communicate with each other and the middleware using the APFI/C interface. 11.5 Discovery In order to use resources and to control Services, these resources and Services first need to be discovered within the home of the end-user, therefore a mechanism is needed that is capable of discovering the Resources of the end-user terminals and Services offered within the home. Discovery is to be performed both at the Tcn and APFI/C interface. For the Tcn interface discovery is done per device including the Resources and Services per MEDIANET 31/63 IST-Project: FP6-507452
  32. 32. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 device. At the APFI/C interface discovery is done per type, meaning that all Resources are discovered or all Services are discovered. In-Home Host A Service S Middleware Discovery In-Home Host B In-Home Host C Resource Resource Service Resource Resource S Resource Resource Middleware Middleware Discovery Discovery Figure 7, Discovery 11.6 State Management State management is used to determine the state of resources and Services within the Home Network. States can for instance be used to determine if a resource is in use, can be claimed etc. The most important state is a state indicating if the entity is operational. Every entity within the in-home network (e.g. Resource and Service) must have at least an operational state, indicating whether or not the entity is able to perform its function. This operational state has two possible values: Enabled and Disabled. MEDIANET 32/63 IST-Project: FP6-507452
  33. 33. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 Disabled Enabled Figure 8, Operational State Upon creation of an entity the operational state becomes disabled. When the entity becomes operational, the state changes to Enabled. When the entity becomes non- operational the state changes to Disabled. Note that an entity first has to become non-operational before it can exit. Depending on the type of entity additional states may be required. Resources have two additional states. - A Claimable state which indicates if a Resource can be Claimed or Not - A Claimed state which indicates if a Resource is claimed or not. Note that the actual state behaviour depends on the resource itself. For example: a UPnP MediaServer can be claimed multiple times concurrently while a UPnP MediaRenderer can be claimed only 1 time concurrently. Services also have an additional state: - Service state that indicates if a Service cannot be started, could be started, can be started or can be stopped. o A Service can be started if all needed resources are detected, operational and free to use. o A Service could be started if all needed resources are detected and operational. o A Service cannot be started if not all needed resources are detected or operational. o A Service can be stopped if the Service has started. MEDIANET 33/63 IST-Project: FP6-507452
  34. 34. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 11.7 Eventing Mechanism One of the minimal requirements to perform management is a reliable way to synchronise states. Besides state variables also other variables need to be synchronised between components. Furthermore information about the availability of the connection between components located on different hosts needs to be synchronised. For these reasons an event mechanism is defined which is reliable, ensures synchronisation and provides information on the connection. This event mechanism is to be implemented by any component within the Managed Services concept. The event mechanism is reliable in the following way: In case an event is sent from component A to component B, the event either arrives at B or both A and B are triggered that the connection between A and B is lost. The reliable event mechanism is to be built on a reliable transport protocol like TCP. The event mechanism provides synchronisation in the following way: All events are self contained, meaning that no previous knowledge of related (state) variables is required for the event sink. For example: the event OperationalStateChanged contains the state variable operational state. Furthermore a client receives the current value of (state) variables related to an event, during subscription on that event. Connection related information is provided in the following way: In case the connection between an event source A and an event sink B is lost, the event sink will automatically receive an event indicating the connection loss between A and B. Eventing is expressed at the APFI/C interface by offering an interface towards: - EventSinks: to subscribe to event notifications - EventSources: to offer events to other components - Middleware: To notify EventSinks of subscribed events - Middleware: To notify EventSinks and EventSources of connection losses. The Eventing functionality in the Middleware is implemented in an EventHandler. This EventHandler propagates event between host, handles connection losses, performs event related garbage collection and multiplies a single events multiple subscribed sinks. Eventing is expressed at the Tcn interface by offering an interface between different Event Handlers, each handler is located at a different host. Using this interface, event handlers can pass events and subscriptions towards each other and use the discovery mechanism to detect connection losses between event handlers. MEDIANET 34/63 IST-Project: FP6-507452
  35. 35. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 In-Home Host A In-Home Host B EventSource EventSink Middleware Middleware EventHandler EventHandler Discovery Discovery Figure 9, Eventing 11.7.1 Event Capabilities Although the event mechanism itself is universal for every component, not every component implements the same events. For this reason a definition of the supported events and the related event values is defined at design time of the component. For example: every component supports the event OperationalStateChanged, but only components of type Resource support the event ClaimableStateChanged. This also means that event sinks only have to know the events that they need for performing their function. This makes it for instance possible to create a monitor component capable of monitoring the operational state of any component (even the undefined ones). In order to support extension of component types at runtime, every component implements the function to retrieve the list of supported events. The event IDs contained within the list are defined uniquely within the system. 11.7.2 Event subscription An event sink can subscribe itself to a supported event of any other component. During subscription the event sink defines its call-back interface and the event-ID to the component. The component returns the current event related values on success, thereby assuring synchronisation and removing the need for additional GET functionality on event related values (e.g. GetOperationalState). 11.7.3 One Shot Events for state related events One of the major problems in a distributed system are event storms, either caused by the fact that one error condition triggers other error conditions, traffic jams caused by events or oscillating event conditions. MEDIANET 35/63 IST-Project: FP6-507452
  36. 36. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 In order to prevent this behaviour the choice is made to have one shot event for events which are based on state values; meaning that an event fires only when the subscription is armed. After firing the subscription is automatically disarmed and needs to be rearmed by the event sink. Initially an event subscription is always armed. 11.7.4 Continuous events for non-state related events Events that are not based on state values but are based on triggers (e.g. the discovering of a new framework, detection of a transmission failure) are capable of firing continuously without rearming. It is however important that a component can only fire continuous events when the component is operational. 11.7.5 Event notification In case an event occurs (e.g. when an event related value changed) the component fires an event notification to all subscribed client, provided that their subscription is armed. During this notification again all event related values are transmitted, to ensure synchronisation. After firing the related event subscription is disarmed. 11.7.6 Event re-arming for state related events After an event notification the event subscription is no longer ‘armed’, so changed to the event condition will not lead to an event notification for that event subscription anymore. In order for the event sink to receive again an event notification the event has to be ‘armed’ again, this is accomplished by a ‘ReArm’ call. Due to the fact that between the event notification and the rearm the event condition could be changes, the current event state value is returned with the rearm call. In this way the event sink becomes again synchronised to the state value. 11.7.7 De-subscription Analogue to subscribing to an event, an event sink also needs to de-subscribe to an event. De-subscription is done in two ways: • A subscribed event sink de-subscribe by calling the corresponding method • The middleware instance of the component notifies the component that the connection is lost. At roughly the same time the middleware instance of the event sink notifies that the connection is lost. Both connection loss notifications remove the event subscription related resources. MEDIANET 36/63 IST-Project: FP6-507452
  37. 37. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 11.7.8 Overview Event Mechanism, Subscribe, ReArm & DeSubscribe Rearm([out] D) Values Notify2(A) Notify2(C) Subscribe2 ([out] A) Rearm([out] A) DeSubscribe() D C B A Figure 10, Event Mechanism The above figure gives an example of how to use the event mechanism. First an event sink must subscribe to an event. The event sink receives the actual value (in this case A). After a while the value changes to C and the event sink is notified, including the value C in the notification. After some time the event sink is again interested and rearms the event. The actual value is returned within the rearm call, being D. When this value changes again the event source is notified that the value has changes to A. The event source can again rearm the event; receive an event notification etc. In case the event source is no longer interested in the event it de- subscribes itself, leading to a deletion of its subscription. 11.8 Resource Management Resource management is management related to the usage of Resources and includes: Monitoring of appearance and disappearance of Resources Validating Resource availability for Clients Claiming and releasing of Resources When multiple Services are to be deployed concurrently within the same in-home network it must be possible to detect and solve conflicts between these Services. MEDIANET 37/63 IST-Project: FP6-507452
  38. 38. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 11.8.1 Service – Resource Matching To be able to detect which Services could run within the home situation, the following information is needed. The resources needed by the Service The resources contained within the in-home network. The set of resources contained within the in-home network is provided by discovery. Resulting in a set of resources. The definition of which resources a Service needs has to be provided by the Service itself. This is called a Resource Requirement Set (RRS). If all resources required by a Service are discovered a Service could run within the In-Home network.3 One of the Resource Management functions of the middleware is to track if a RRS as defined by a Service is detected. Using this functionality a Service can easily track if it could be started or not at a certain point of time. For example: The My Music Service needs a UPnP MediaServer as content source and a UPnP MediaRenderer to play the music. It is of no use to offer this Service to a user in case not both the MediaRenderer and the MediaServer are discovered. Each RRS related to a Service is managed within the middleware during the lifetime of the Service by a component called Resource Selection Set. In-Home Host Service 1 Middleware n Resource Selection Set Figure 11, Resource Selection Set 3 Note that an RRS could be quite complex when resources are optional and/or multiple resources of the same type are needed. It could even be possible that a Service defines multiple RRS instances. These situations are specified in [IA3.3]. MEDIANET 38/63 IST-Project: FP6-507452
  39. 39. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 11.8.2 Availability of Resources In case the Resources needed by a Service are detected, the question if these Resources can be used has to be answered. The answer depends on the availability of the individual resources. If all resources are available, the Service can be started. One of the functions of the middleware is to track if certain combination of resources that fulfils a RRS is available. Using this functionality a Service can easily track if it can be started at this moment in time. For example: Using the same My Music Service. In case there is only one MediaRenderer discovered and this MediaRenderer is used by another Service, the My Music Service can not be started at that moment of time. The availability of resources is defined by two states from the Resource. The first state is the Operational State (11.6) indicating if a Resource is working or not. The second state is the Claimable state, indicating if a Resource can be used or not. Claimable Not Claimable Figure 12, Claimable State Besides a Resource also a RSS has a Claimable State with the same state diagram. The Claimable State of an RSS defines whether or not a set of resources has been found which are claimable at this point in time and meet the RRS. 11.8.3 Claiming Resources In case a Service can be started, the Resources needed for that Service need to be claimed to prevent that another Service uses these Resources concurrently4. This is done by performing a claim, resulting in a claim of a set of resources that comply to the RRS and are currently available. These Resources are now assigned to the Service and can be used by the Service. 4 Note , that some Resources can be used multiple times concurrently, in this case these Resources can be claimed multiple times concurrently. MEDIANET 39/63 IST-Project: FP6-507452
  40. 40. DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0 For example: Using the same My Music Service. Upon starting the My Music Service the MediaServer and MediaRenderer are claimed, making it impossible for any other Service to use the MediaRenderer. In this way conflicts between Services are prevented. The Service performs a Claim at the RSS and the RSS claims that set of capabilities that comply to the RRS by performing individual claims at the resources. Service RSS Resource A Resource B Claim Cl aim Claim Figure 13, Claiming Resources 11.8.4 Managing Device Specific Resources The specific implementation of a device defines which resources are included and how these resources can be used concurrently. For example: A device is both an UPnP MediaRenderer and an UPnP MediaServer. When the device is not rendering any media it can stream two content items concurrently, when the device is rendering media it can stream only one stream concurrently. Due to this kind of complexities it is not possible to decide if a Resource is claimable or not within the Middleware itself. Therefore a new component is introduced, called Resource Container that is implemented by the device and controls whether or not resources can be claimed. MEDIANET 40/63 IST-Project: FP6-507452

×