Digital Home Network Reference Architecture Definition

Multimedia Networking IST-Project: FP6-507452

Digital Home Network Reference Architecture Definition

Deliverable DA.3.1v2

Target release version: V2_0

Dissemination level: PU

DA.3.1v2 – Digital Home Network Reference Architecture Definition – V2_0

MEDIANET IST-Project: FP6-507452 2/63

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



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



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.



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



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



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.



SharedPlatform

ApplicationSpecific

ApplicationServiceProvider

Network AccessProvider

End-user Home

Environment

CPEApplication

Platform

ASPApplication

Platform

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10

Provider Application

Customer Application

CommonInfrastructure

SharedPlatformShared

Platform

ApplicationSpecific

ApplicationSpecific



End-user Home

Environment

CPEApplication

Platform

CPEApplication

Platform

CPEApplication

Platform

ASPApplication

Platform

ASPApplication

Platform

ASPApplication

Platform

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10




Appl

Appl

Appl

Appl

Appl

Appl

Appl

Appl

Network Access

Services

Home

Network

platform

platform

platform

platform

platform

platform

Appl

Appl

Appl

Appl

Appl

Appl

Appl

Appl

TCN U-R A10

home access application Services



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.

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”,

Usage Scenarios

Requirements

ReferenceArchitecture

Usage Scenarios

Requirements

ReferenceArchitecture



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



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.



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.

Content Creation

ServiceProviders

Network access

provider

End-user * Home

Environment

According to TR-58

According to TR-94

U-R TCN S

S(not in TR-094)

A10

?

Content CreationContent Creation

ServiceProviders

Network access

provider

End-user * Home

Environment

According to TR-58

According to TR-94

U-R TCN S

S(not in TR-094)

A10

?

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:



- 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



SharedPlatform

ApplicationSpecific



End-user Home

Environment

CPEApplication

Platform

ASPApplication

Platform

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10


APFI/P


APFI/C


SharedPlatformShared

Platform

ApplicationSpecific

ApplicationSpecific





End-user Home

Environment

End-user Home

Environment

CPEApplication

Platform

CPEApplication

Platform

CPEApplication

Platform

ASPApplication

Platform

ASPApplication

Platform

ASPApplication

Platform

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

N-ServicePlatform

ResidentialGateway

CPNDistribution

Network

U-R TCNA10


APFI/P


APFI/P


APFI/C


APFI/C


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.



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



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.



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



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



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.



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



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.



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



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



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



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

bandwidth (upstream)

Typical bandwidth (downstream)

Delay bound

Packet loss

On demand

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. MPEG2

2-6 Mb/s ~1s 105 Yes

Navigator and EPG (can be locally launched and updated in non real time)

<0.5 Mb/s N/a N/a No

Picture in Picture – two MPEG2 channels

Up to 12 Mb/s ~1s ~1% Yes

Picture in Browser – one MPEG2 Up to 9 Mb/s ~1s 105 Yes ITV – TV telephony features <64 kb/s <64 kb/s <400ms

(RTT) ~1% Yes

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.



PC Focused Services Typical

bandwidth (upstream)

Typical bandwidth (downstream)

Delay bound

Packet loss

On demand

High Speed Internet Access (browsing, IM, Chat, FTP, VPN, access, etc) - Residential (typical asymmetric) - SME/SOHO (typical symmetric)

128 – 640 kb/s Up to 6 Mb/s

Up to 3 Mb/s Up to 6 Mb/s

N/a N/a

N/a N/a

Yes/No 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

(RTT) ~1% Yes/No

Voice/Video telephony 64 – 750 kb/s 64 – 750 kb/s <400ms (RTT)

~1% Yes

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.



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.



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.



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).

Device1

Resource2

Resource1

Service1

Device2

Resource4

Service2

Resource3

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.



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 C

Middleware

ResourceResource

Resource

In-Home Host B

Middleware

SServiceResource

ResourceResource

In-Home Host A

Middleware

SService

APFI/C

APFI/C APFI/C

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



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 C

Middleware

ResourceResource

Resource

In-Home Host B

Middleware

SServiceResource

ResourceResource

In-Home Host A

Middleware

SService

Discovery 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.



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.



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.



In-Home Host B

Middleware

In-Home Host A

Middleware

EventSource EventSink

Discovery Discovery

EventHandler EventHandler

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.



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.



11.7.8 Overview Event Mechanism, Subscribe, ReArm & DeSubscribe

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.

Values

A

B

C

D

Subscribe2 ([out] A

)

Notify2(C

)

Rearm

([out] D)

Notify2(A

)

Rearm

([out] A)

DeS

ubscribe()



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

Middleware

Service

1

n

ResourceSelection 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].



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.



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

ClaimClaim

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.



In-Home Host

Middleware

ResourceResourceContainer

ResourceResource

Figure 14, Resource Container

The introduction of the Resource Container adds the following changes to the resource management mechanism. The RSS no longer scans each discovered resource individually but requests each Resource Container for those sets of resources that partly solve the resource requirements for the Service. These sets of resources are contained in a container component called a Resource Set. During the Claim the RSS claims simply the needed Resource Sets containing the correct capabilities.

In-Home Host

Middleware

Service

1

n

ResourceSelection Set

ResourceContainer Resource

ResourceSet

1 n

1

n

n

m

1 n

Figure 15, Components involved in resource management

The sequence diagram of the resource requirements discovery now becomes the following:



Service

Resource Requirement Set

Resource Container

Resource Resource

Resource Set

CreateRequirement

SolveRequirement

CreateResourc eSet

Figure 16, Resource Requirement Discovery

Resulting in the following sequence diagram for a Claim:

Service Resource Requirement Set

Resource Container

Res ource A Resource SetResource B

Claim

Claim

Claim(A+B)

Claim

Claim

Figure 17, Resource Claim

11.8.5 Detecting Resource Conflicts

Now that we are able to discover resources, match resources with Services and claim resources it is easy to detect possible resource conflicts between Services. Note that solving these resource conflicts is part of Service Management, not resource management.



A Service can easily detect if a needed resource is not discovered or not available. In case a resource is not available the device that implements that resource knows which Service has claimed a Resource or which Resource prevents the claiming of the needed resource. Of course this mechanism is distributed over the different objects, every object has the following responsibilities within this Conflict Detection. The Service uses the Operational State of the Resource Selection Set to detect if at least one set of resources is detected that solves the Resource Requirements Specification. If the Operational State of the RRS is Enabled at least one set of Resource is detected that solves the Resource Requirements Specification. The Service can now look at the claimable state of the RRS to see whether or not a suitable set of resources can be claimed. In case the claimable state is equal to not claimable, a resource conflict exists. The Service can now request to the RRS for an array of sets of Services that cause the resource conflict. Note that only the conflict with one element of that array has to be resolved to remove the resource conflict. For example: The My Music Service needs a UPnP MediaRenderer, Two UPnP MediaRenderer are detected, one is used by Service A, the Other by Service B. When the My Music Service requests for the sets of Services that cause a resource conflict two sets are returned; one containing Service A, the other one containing Service B. The conflict can be resolved by either stopping Service A or Stopping Service B. The RRS creates the list of sets of Service by enumerating over each possible set of resources that solve the resource requirements, and asking the non-claimable Resource Set components of each set of resources that Services are causing the conflicts. By combining the Services received from the individual Resource Sets a Set of Services id generated for each possible set of resources that solve the resource requirements. Each Resource Set asks the Resource Container for those Services that block claiming of the Resource Set and returns the answer to the RRS. Note that the individual Resources are not involved, because of the fact that some resources can be mutual exclusive with other resources.



Service Resource Requirement Set

Resource Container A

Resource Set A

Resource Set B

Resource Container B

Specify Conflict

Specify Conflict

Specify Conflict

Specify Conflict

Specify Conflict

Figure 18, detecting Resource Conflicts

11.9 Service Management Service Management consists of the following functions:

Lifetime control of Services. This includes full lifetime control from installation to starting/stopping and to deletion.

Resolving resource conflicts between Services Sending non-disruptive messages towards users: User Eventing

Service management is performed by a separate component called a Root Service. Multiple Root Services can exists simultaneously within a single In-Home network, but only one Root Service, called the Active Root Service, can Resolve resource conflicts. The active Root Service is elected.



In-Home Host C

Middleware

ResourceResource

Resource

In-Home Host B

Middleware

SService

ResourceResource

Resource

In-Home Host A

Middleware

SService

Discovery Discovery

Discovery

RootService

RootService

RootService

- Active

Figure 19, Root Service

11.9.1 Lifetime control of Root Service

Every Service Provider can offer its Root Service. Depending on the owner of the system/boxes within the system, more Root Services can be installed. The administrator of the system is in control which root service has preference. 11.9.2 Lifetime control of Services

The lifetime of a Service is controlled by multiple components within the system. First of all the Root Service of the Service Provider is responsible for installation and removal of the Service. After installation of Service, the Service defines its requirements towards the framework and enters the installed state. In case the requirements could be fulfilled by the system the Service enters the idle state. In case the requirements can be fulfilled by the system the Service enters the In-active state. In this state the Service can be started.



A Service can be started by either a Root Service (e.g. user action) or by itself (e.g. timed recording or incoming phone call). A Service can be stopped by either a Root Service (e.g. user action) or by itself (e.g. Service has ended). De-installation of a Service is performed by the Root Service of the Service Provider or by the System itself (maintenance)

Ins talled

Install

Idle

Inactive Active

RRS Operational State = Enabled

De-install

RRS Operational State = Disabled

RRS Claimable State = True

Start

RRS Claimable State = False

Stop

RRS Operat ional State = Disabled

De-install

Figure 20, Service State Diagram

11.9.2.1 WAN Services When using WAN Services, e.g. a web based VoD service, the application logic resides within the WAN. In such a case only a definition of the needed In-Home resources and a definition of how to connect these resource to the WAN Service is needed for In-Home Management. In this case a Root Service can just install a Service stub, consisting of the Resource Requirements and the logic needed to connect these resources to the WAN Service. Lifetime control of the WAN Service is than controlled by proxy via the Service Stub.



In-Home Host C

Middleware

ResourceResource

Resource

In-Home Host B

Middleware

SService

ResourceResource

Resource

In-Home Host A

Middleware

SService

stub A

Discovery Discovery

Discovery

RootService

RootService

RootService

- Active

Service A

Service B

WAN LAN

NT/GW

Figure 21, WAN Service

11.9.3 Root Service – User Interaction

Although the Interaction of a User with the System is out of the scope of this Document, some possible ways of interaction are described here to create an idea of possible ways the user interacts with the System. 11.9.3.1 Local Root Service Interaction The simplest way for user-root Service interaction is to allow only local interaction between user and a local Root Service within the box. For example: a set-top box contains a pre-installed Root Service that can be used to control the lifetime of all Services within the Home. E.g. the user uses the remote control to retrieve a list of all Service with an inactive or active Service State. This local root Service can however not always be used for resolving Service conflicts because it must be the active Root Service. This can be solved by extending the communication between Root Services (possible options ranging from using a Remote UI protocol to becoming the Active Root Service)



11.9.3.2 Remote User Interface to push active Root Service to correct end user terminal Another option is to implement a remote UI protocol by every End User Terminal. This Remote UI protocol can be used by the Active Root Service to present its User Interface and control the System. In this case the Active Root Service is always used to start, stop and resolve conflicts between Services. In-active Root Services are only able to install and de-install Services. 11.9.4 Resolving Service Conflicts

As defined in [11.8.5] the middleware is capable of detecting possible conflicts between Services. The middleware however does not resolve these conflicts. It is the responsibility of the active root Service to resolve this conflicts. The main reasons to move this functionality to the active root Service is that this component is the only component that has a single instantiation, is replaceable and is capable of user interaction. Conflicts can be solved in a number of ways. The simplest solution is to simply stop the conflicting Service(s). Another option is to use user-eventing to ask the user to resolve the conflict. E.g. the system is capable of answering video calls and playing digital video, but not concurrently. A Service conflict is created when an incoming video call is happening when the user is watching a movie. This Service conflict can be solved by stopping the playback of video or by ignoring the call. Which option must be made can be difficult because it can for instance depend on the caller. The ways in which resource conflicts are resolved are for the moment out of scope for this document. 11.9.5 User Eventing

The division of application into Services and Resources and the accompanying Resource management make it difficult for a Service to contact the User without claiming a number of resources. This creates a kind of chicken egg problem when for instance the resources needed to contact the user are not available. For this reason functionality is added which allows the system to contact the user without intervention of current running applications/Services, this functionality is called User Eventing. User Eventing allows the transmission of event (e.g. audible sound, images etc) to a specific user or groups of users. Included in the definition of a user event is also a number of response reactions. For example: Upon receiving of an incoming video call the Video Call Service sends an user event, containing a ring tone and an telephone icon and caller name, to the user. This event contains the option to accept the call (start Video Call Service) or to ignore the call (resulting in a message added to the answering machine). User eventing is regulated by the active root Service that has also claimed the resource needed for user eventing. In this way the normal resource management



mechanism is re-used, but multiple Services and the middleware can use the user eventing mechanism concurrently. The user events however are serialised by the Active Root Service per User.



12 Bandwidth Management This chapter discusses In-Home bandwidth management, its relation to QoS and WAN QoS, its relation to UPnP QoS and the relation with Resource Management. Bandwidth management involves the control and monitoring the flow of data in a network to provide a guaranteed, consistent, reliable and predictable flow of traffic. 12.1 Bandwidth Management between LAN and WAN Looking at end-to-end services, multiple parties are involved in the service offering. If any of these parties cannot fulfil the requirements of the end-to-end service, the service cannot be guaranteed. Due to the fact that the in-home network both accommodates end-to-end services and local services, the in-home network must actively participate in guaranteeing end-to-end delivery. For this reason the home network is responsible for its own bandwidth management. In the same manner the Network Access Provider is responsible for the bandwidth management of the traffic on the access network. The Home network and the access network interface at the U-R interface, for this reason the bandwidth management of this interface is shared. The Network Access Provider is responsible for managing the bandwidth of all traffic towards the home. The In-Home network is responsible of bandwidth management of all traffic towards the access network. The control of the bandwidth management of the different parties is to be performed by the end-to-end service. This control is performed out of band and can for example be done using SIP. 12.2 In-Home Bandwidth management concept Bandwidth management involves management of streams between a source and a destination . At least the Source or the Destination is within the home, resulting in the following traffic types:

Source Destination Traffic type In-Home In-Home Local traffic In-Home Outside-Home Outgoing traffic Outside-Home In-Home Incoming traffic

Table 3, traffic types

In the best possible scenario traffic flows directly from source to destination without any intermediate hops (like a router, access point or switch) in-between. For the MediaNet scenarios however at least one local hop is included. 12.2.1 Bandwidth Resource

Bandwidth has to be managed at all points passed by the traffic; being at the source side, the links, the hops and at the destination side. Each point passed by the traffic is modelled as a bandwidth resource. A bandwidth resource has a bandwidth budget that can vary over time. Each stream consumes a



certain amount of this bandwidth budget. Within the bandwidth resource, the total budget is known and the amount of bandwidth that is being consumed. Source bandwidth resource The bandwidth budget of the bandwidth resource of a source represents the amount of traffic the source can generate. The type of network connection or the available processing power can for example limit this amount of traffic. Destination bandwidth resource The bandwidth budget of the destination bandwidth resource represents the amount of traffic the destination can handle. This can for example depend on the network connection, the processing power etc. Link bandwidth resource The bandwidth budget of the link bandwidth resource represents the amount of bandwidth the link can handle. Depending on the type of link a link is represented with one or more link bandwidth resources. For example a 100 Mb/s Ethernet link is represented as a single link bandwidth resource with a budget close to 100 Mb/s. An ADSL link for instance is represented as two separate link bandwidth resources one for the upstream traffic and one for the downstream traffic. A WiFi link is represented as two separate link bandwidth resources, one for traffic towards the access point, the other for traffic from the access point; the budget however of the two link bandwidth resources is shared5. Bandwidth resource for a hop Every router, gateway, access point etc. is modelled using the bandwidth resources of the links it is offering. These link bandwidth resources share the budget of the hop bandwidth resource that represents the amount of traffic this hop can process. The representation of a hub can in this way also be expressed as a single bandwidth resource, given the fact that all traffic flows in all directions. Hubs and cascaded hubs are assumed to be modelled in the nearest active hub e.g. gateway or access point.

5 For this example the wifi network uses infrastructure mode. Ad-hoc mode is not supported in the bandwidth management model.



Content SourceContent Sink

Hub - Ethernet - 100 mb/s

Access Point - 802.11 g

Modem

Gateway / Router

Figure 22, typical in-home network configuration

In the figure above a typical home networking configuration is drawn, consisting of a modem (cable orADSL), a gateway, an access point (might be integrated within the gateway), a hub (might be integrated within the gateway) and a number of devices (wired and wireless). This set-up results in the following abstract bandwidth resources:



Wired linkBandwidth Resource

DownstreamADSL

BandwidthResource

(stub)

UpstreamADSL

BandwidthResource

RouterBandwidth Resource

Wired linkBandwidthResource

Access PointBandwidth Resource

IncomingWireless linkBandwidthResource

OutgoingWireless linkBandwidthResource

(Destination)Bandwidth Resource

(Source)BandwidthResource

HubBandwidthResource





DownstreamADSL

BandwidthResource

(stub)

UpstreamADSL

BandwidthResource






(Destination)Bandwidth Resource

(Source)BandwidthResource

HubBandwidthResource




Figure 23, bandwidth management abstraction of in-home network

In Figure 23 the example home network is abstracted into the various bandwidth resources and the paths traffic may use between them. Also an example of a local stream (green) and an end-to-end stream (red) is given. Bandwidth budget of all bandwidth resources crossed by a stream is used to deliver the stream. 12.2.2 Routing resource

One of the main issues is to find out the path a stream has to travel through the home network. Routing resources provide this answer. Each active component (Host, router, access point and modem) has a routing resource. Such a routing resource is capable of telling which routing resources it can reach and which bandwidth resources are involved. So asking the routing resource of the source (or the stub for the source, in case of incoming traffic) for the path starts the discovery process.



Routing resources can discover each other using lower layer network specific mechanisms like the ARP protocol (RFC 826). Note that at least one active component (router, modem, gateway or switch) is needed by this mechanism. Also due to the fact that a hub is not an active component, the hub needs to be modelled explicitly in one of the active components. Cascading hubs in the home network are modelled implicitly, because all traffic still travels across every cascaded hub. Every routing resource contains a local table with the following information: • A FROM field: Containing the unique address or address range of sending active

network element. This can for instance be the local IP or MAC address if the localhost is the sender.

• A TO field: containing the unique address or address range of receiving sending active network element. This can for instance be the local IP or MAC address if the localhost is the receiver.

• A Routing Resources field containing the ID of the next routing resource involved. This might be empty in case the localhost is the receiver

• A Bandwidth Resources field containing the ID of bandwidth resources that are involved.

For example: Using the following network setup:


DownstreamADSL

BandwidthResource

(stub)

UpstreamADSL

BandwidthResource


Wired link 1BandwidthResource




(Source)Bandwidth Resource




ADSL Modem Routing ResourceGateway Routing Resource

Access Point Routing Resource

Source Host Routing Resource

MAC = AP

MAC = R1

MAC = R2

MAC = R3

MAC = S

MAC = M

Figure 24, network setup including routing resources



This creates the following table at the gateway routing resource: From To Routing Resources Bandwidth Resource MAC AP MAC S - Source Host - Wired Link 1

- Wired Link 2 - Router

MAC S MAC AP - Access Point - Wired Link 1 - Wired Link 2 - Router

MAC AP MAC M - ADSL Modem - Wired Link 1 - Wired Link 3 - Router

MAC M MAC AP - Access Point - Wired Link 1 - Wired Link 3 - Router

MAC S MAC M - ADSL Modem - Wired Link 2 - Wired Link 3 - Router

MAC M MAC S - Source Host - Wired Link 2 - Wired Link 3 - Router

MAC AP MAC R1 - - Wired link 1 - Router

MAC R1 MAC AP - Access Point - Wired link 1 - Router

MAC S MAC R2 - - Wired link 2 - Router

MAC R2 MAC S - Source Host - Wired link 2 - Router

MAC M MAC R3 - - Wired link 3 - Router

MAC R3 MAC M - ADSL Modem - Wired link 3 - Router

Table 4, routing resource table

Every Routing resource further knows which traffic originates from that host. For example the ADSL modem routing resource is the source for all traffic having a public address other than the external home address. This information is needed to find the Routing resource representing the source. Using the routing resource, the route and the bandwidth resources involved, can be resolved. The routing table is constructed/extended at runtime using discovered routing information. 12.3 Bandwidth management in relation with in-home management middleware Bandwidth Management is one of the functions of the In-home management middleware. Bandwidth management extends resource management as defined in paragraph 11.8. The Bandwidth resources and the Routing resources are in fact just a specialisation of the generic resource. A Bandwidth Container controls the Routing resource and



the related Bandwidth resources. The bandwidth container defines the type of function the device performs. Examples of bandwidth containers would be a Modem bandwidth container and an access point bandwidth container. The bandwidth container registers its routing resource and bandwidth resources at its local framework. BandwidthStream Resource Bandwidth management is performed using a new type of resource called a BandwidthStream resource. The BandwidthStream resource is implemented by any local middleware instance and is able to find the correct routing resources and bandwidth resources related to a data stream. Using the BandwidthStream resource the application is capable of requesting bandwidth by requiring a BandwidthStream resource between source and destination with the desired amount of bandwidth. Upon such a request a new instance of the BandwidthStream resource is created. This instance looks for the Routing resource that represents the source and starts discovering the possible route and the routing and bandwidth resources involved. If the route is discovered the BandwidthStream resource will create a new requirement to the local framework containing all routing and bandwidth resources contained in the path.

Service Middlwware

BandwidthStream resource

Routing Resource 1

Routing Resource 2

Bandwidth Resource 1a

Bandwidth Resource 1b

Bandwidth Resource 2a

CreateRequirem ent(B andwidthSt ream,src,dest ,bandwidth)

SolveRequirement(src,dest,bandwidh)

RoutingSourceOf?(Src)

RoutingSourceOf?(src)

No

OK (disabled)

Yes

SolveRoute(src,dest)

BandwidthResource 2a, Routing Resource 1

SolveRoute(src,dest )

BandwidthResource 1a + Bandwidth Resource 1b, NULL

CreateRequirment(...)

Figure 25, Solving bandwidth requirement

Bandwidth requirements are identical to resource requirements from a Service/Application point of view. The Service defines the bandwidth it needs between the source and destination including stream type and needed bandwidth.



The middleware creates a BandwidthStream resource that will first discover the routing path and create a new requirement for the routing and bandwidth resources involved. These resources are then treated as any other resource. 12.4 Relation UPnP QoS The bandwidth management functionality described here is equivalent to the centralized QoS manager described in UPnP QoS V1.0. The main functional difference is the fact that the bandwidth management functionality is distributed. Therefore the relation with UPnP QoS is based on reuse of concepts and interfaces of UPnP for interoperability. The bandwidth management functionality will expose itself as an UPnP QoS manager for non-managed middleware enabled devices/applications. Furthermore the bandwidth management functionality can use the UPnP QoS Policy Holder for retrieval of traffic policies and can use UPnP QoS Device Services for bandwidth enforcement. From an abstract point of view the bandwidth management functionality can be seen as an (distributed) implementation of an UPnP QoS Manager. Note that UPnP QoS v1.0 is mainly based on priority, although admission control to allocate network resources can be performed using the optional Tspec. Future versions of UPnP QoS may and will include broader support for bandwidth management described here, e.g. end-to-end bandwidth, admission control, airtime etc. Major improvements compared to UPnP QoS are:

♦ Distributed bandwidth management ♦ Possibility to monitor the availability of bandwidth

12.5 Bandwidth Enforcement Bandwidth enforcement involves the actual enforcing of the bandwidth management. Bandwidth enforcement is out of scope for the bandwidth manager, however support for different kinds of enforcement is included. The bandwidth management supports relative QoS and guaranteed QoS as bandwidth enforcement methods. Using relative QoS a priority is used to differentiate between managed traffic and best effort traffic. Using guaranteed QoS, the managed traffic is virtually separated from best-effort traffic using guaranteed virtual channels. Depending on the actual implementation of the resources that enforce bandwidth management the choice is made to use guaranteed QoS, relative QoS or a combination of both. For example: Guaranteed QoS can be used for one part of the home network, while relative QoS is used in another part. This is implemented by both controlling the bandwidth in the guaranteed part, while also assigning a priority to the traffic for the relative part.



12.6 Combining Resource Management and Bandwidth Management When combing resource management and bandwidth management, guarantees can be offered by applications that are in line with the current available resources and bandwidth within the end-to-end system. Furthermore high-level middleware functions can be offered to services that take care of application requirements. For example: a Multimedia service needs a UPnP MediaRenderer and a UPnP MediaServer, both need to support some common content types and the bandwidth between those two needs to be available. The complex part of this requirement is the fact that the supported content types and needed bandwidth are to be filled in at runtime. For instance: a MediaServer contains MP3 and MPEG4 content, while a MediaRenderer supports MP3 and MPEG2 content. The combination of these two results that only MP3 content can be rendered. To solve these run-time changing requirements, requirement variables are introduced. Requirement variables are solved at runtime by negotiating the values between resources. Requirement variables are denoted as $n (n is the variable id) For example: Using requirement variables the requirement of the service would become:

- A: 1 UPnP MediaServer, Codecs = $1, BandwidthRange = $2 - B: 1 UPnP MediaRenderer, Codecs = $1, BandwidthRange = $2 - C: 1 BandwidthStream resource, Source = A, Destination = B,

BandwidthRange = $2, traffic type = Streaming Media The middleware solves this requirement in a number of steps. A first iteration only involves the discovery, for example:

- A UPnP MediaServer is discovered which returns the following values for the requirement variables: $1 = {WMA, WMV, MPEG4, MP3, MPEG2} $2 = {50..12000} kbit/s

- A UPnP MediaRenderer is discovered which returns the following values for the requirement variables: $1 = {MP3, MPEG2, JPEG} $2 = {96..9000} kbit/s

- A BandwidthStream is discovered between A and B which returns the following values for the requirement variable: $2 = {1..4000} kbit/s

The middleware combines the individual requirement variables and computes the new values based on the common results. This results in the following values:



- $1 = {MP3, MPEG2} - $2 = {96..4000}

Using these values the individual resources are asked to re-check the variables according the computed values. leading to the following results:

- The MediaServer: o $1 = {MP3} ; because no MPEG2 content is available with a bitrate

lower than 4000 kbit/s o $2 = {96..256} ; because the MP3 content is within this range

The changed values returned by the MediaServer, lead to a new computation of the common results. This results in the following values:

- $1 = {MP3} - $2 = {96..256}

If the new values are accepted by all resources, the result is a successful solution for the requirement. Note that the resulting service is a Music service capable of playing MP3 files. Within the above example the bandwidth caused the disappearance of the function to render MPEG2 content. While the mismatch between supported codecs between MediaServer and MediaRenderer caused the disappearance of the functionality to render WMA, WMV, MPEG4 and JPEG content. Extensions to the matching mechanism for requirement variables can include the calculation for possible fall-back options for services, depending on available resources (including bandwidth). So could for instance a service capable of playing all content be split in a high bandwidth variant and a low bandwidth variant, the latter only capable of rendering low bandwidth content.



13 Conclusions Different consortia like DLNA, the UPnP forum and the DSL forum are specifying requirements and architectures for service delivery to and in the home. These architectures fulfil the requirements for delivery of a single service concurrently. However when multiple services are to be delivered concurrently towards and in the home, additional requirements pop-up which are not covered by current architectures. These additional requirements are covered by the addition of a distributed in-home management architecture, which allows the concurrent use of multiple services. The distributed in-home management architecture extends on existing architectures to enable a seamless evolutionary introduction approach and offers both benefits for the user and the providers. Users benefit from a more uniform, simplified way of in-home networking; providers will benefit from the additional guarantees offered for their services. The concepts described in this document offer enhanced functionality compared to current state of the art in UPnP and DLNA. It is the intention to propose these concepts for future versions of these standards.



14 Appendix: Use Cases The various partners will describe the actual use cases for MediaNet in separate documents. These documents that describe the individual use cases and scenarios in detail are not available yet. Not just the individual use cases are relevant for the Home Network Reference Architecture, but “running multiple use cases concurrently” is the real challenge that needs to be addressed by the reference architecture. Therefore, since the details of the individual use cases are not available yet, the use case described in this document is a high-level description of a number of possible individual use cases. It is just meant to sketch the context of applications and give some feeling about possible resource constraints and conflicts that need to be handled by the home network.

Typical classes of applications that may run in a home are:

- Content delivery from a Service Provider via the access network to the home o Examples are for instance DVB-IPI video delivery, Internet radio, on-line

music Services - Peer-to-peer applications

o Data exchange (e.g Kazaa) - Communication Services

o IP-telephony and videophony - In-home applications

o Playback of locally stored video or music on a rendering device in the home



These are roughly the type of applications that are expected to be active concurrently in a home. The corresponding bit rate and QoS requirements are listed in Table 1 and Table 2. The following scenario is derived from a scenario of the ITEA HomeNet2Run project. It shows some situations where a number of resource conflicts may occur:

- Bandwidth conflicts on the broadband access network o Video multicast, Internet access, music downloads

- Bandwidth conflicts on the in-home network o Watching live programs and playback of stored music and video

- Resource conflicts on the storage devices o Multiple applications might use the same device for recording and streaming

The Smith family: Mr and Mrs Smith, and their three children: Cathy, Sarah and John. 1 Mrs Smith Mrs Smith is preparing dinner in the kitchen. She is using a portable display, which shows the recipe and some pictures of the dishes she wants to prepare, both downloaded from the Internet. She has instructed the Home Server to record meanwhile her favourite talk show on the Network Storage Device in the home. Now and then she switches her display to this video channel to get a snapshot of what is going on. After dinner Mrs Smith goes to the living room to watch on the big TV screen her favourite talk show, which was recorded when she was preparing dinner. When she has finished watching the talk show, she takes her laptop computer to make a virtual tour through the Prado museum in Madrid. 2 Mr Smith At five PM, when Mr Smith comes home from work he turns on his TV to watch the news program. When he is watching the news he receives a phone call. He presses the record button on his remote control to store the news program on the PVR for watching it after the call. It is a call from his friend who asks him to go that evening to the pub to watch the soccer match together. 3 Cathy Cathy is preparing here thesis on the desktop PC in her room. She is browsing the Internet to look for specific information on the subject she is working on. She has to download quite some pictures and she hopes that the network is not too busy. Thanks to the high-speed Service of the broadband network, she can finish her work early, so she can go out with her boyfriend after dinner. She calls her boyfriend using the videophone to chat a little bit and to discuss where to go that evening. 4 John After dinner he goes to his room to finish the last part of his homework, since he wants to watch the soccer game. He has an AmigoTV in his room that allows him to chat with his friends that are also watching the same soccer game. In parallel he records a movie from a different channel to watch after the soccer match and before going to sleep. 5 Sarah While Sarah is doing her homework, she is downloading new MP3 files into the Network Storage Device to extend her collection. When Sarah has finished her homework, she wants



to watch her favourite music programme on the TV in her room. After dinner Sarah is going to her room to listen to the new MP3 files she has been downloading.

Digital Home Network Reference Architecture Definition

Documents

Transcript of Digital Home Network Reference Architecture Definition