draft
CENELEC Project Report Smart House Roadmap
Date 15 October 2010
Author(s) Frank den Hartog, Tom Suters, John Parsons, Josef Faller
Version Draft 1.0 for Open Enquiry
This CENELEC project report has been drafted by a project team and steering group of representatives of interested parties and is to be endorsed on 2010 11 23. Neither the national members of CENELEC nor the CEN CENELEC Management Centre can be held accountable for the
draft technical content of this CENELEC project report or possible conflicts with standards or legislation. This CENELEC project report can in no way be held as being an official standard developed by CENELEC and its members. This CENELEC project report is publicly available as a reference document from the CENELEC members.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
CENELEC European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung CEN-CENELEC Management Centre: Avenue Marnix 17, 1000 Brussels
© 2010 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
2
1 Contents
List of2 Figures and Tables ...... 5 draftForword3 6 Grant4 Agreement, Steering Group and Project Team...... 7
1. 5 Introduction...... 8 1.1 6 Motivation...... 8 1.2 7 Purpose, scope and objective ...... 8 1.3 8 Document structure ...... 9
2 9 Analysis ...... 11 2.1 10 Technical, commercial, and deployment requirements for the SmartHouse...... 11 2.2 11 Convergence and interoperability ...... 12 2.3 12 Problem Space: Application Domains, Ecosystems...... 15 2.4 13 Challenge ...... 18 2.5 14 Project vision summary: overview of observations and assumptions ...... 19
3 15 Approach...... 22 3.1 16 Starting point of the project approach: convergence and migration...... 22 3.2 17 Project approach: overview...... 22 3.3 18 Stakeholder Requirements: Use Cases...... 23 3.4 19 Selection and analysis of a representative set of Ecosystem standards...... 24 3.5 20 SHR Reference Model (SHR RM)...... 25 3.6 21 Interoperability considerations...... 28
4 22 Results ...... 30 4.1 23 Use cases...... 30 4.2 24 Ecosystems...... 30 4.3 25 Taxonomy ...... 31 4.4 26 Interoperability Profiles...... 35 4.5 27 Solution Space...... 39
5 28 Summary and conclusions...... 43
6 29 Recommendations ...... 45 6.1 30 Application Layer...... 45 6.2 31 Communication layers ...... 46 6.3 32 Home Infrastructure ...... 46 6.4 33 Compliance ...... 46
References34 ...... 48
A 35 Use Cases...... 49 A.1 36 Template...... 49 A.2 37 Intra Ecosystem use cases...... 51 A.3 38 Inter Ecosystem convergence use cases...... 62 A.4 39 Use cases for changing service providers...... 72
3
B 1 Acronyms ...... 82
C 2 Long list of Smart House standards ...... 96 draftD 3 Current initiatives ...... 109 D.1 4 Coordinating bodies ...... 109 D.2 5 Relevant European R&D projects...... 110 6
4
1 List of Figures and Tables
2 Figure 1 Convergence towards smart houses. draft3 Figure 2 An example of increased managerial hassle due to a proliferation of devices 4 in the home. 5 Figure 3 Flowchart of the SmartHouse Roadmap approach 6 Figure 4 Reference model as used in ISO/IEC TR 29107 7 Figure 5 SmartHouse Roadmap Reference Model 8 Figure 6 Service composition in SOA. The Service Consumer accesses a service, 9 which under the hood is composed out of several generic Service Building 10 Blocks (SBBs). Some SBBs may at the same time be used for other services. 11 Figure 7 generic object model of an Ecosystem 12 Figure 8 integrating multiple Ecosystems 13 Figure 9 integrating multiple Ecosystems 14 15 Table 1 The interoperability levels as identified in CWA IFRS [4]. The CWA defines 16 conformity requirements only for levels 4 6 17 Table 2 Long list of Ecosystems for the SmartHouse. 18 Table 3 Short list of Ecosystems, following from the use cases 19 Table 4 Interoperability Profile for the SmartHouse Roadmap use case C 3 20 Table 5 Interoperability Profile for the SmartHouse Roadmap use case A 1 21 Table 6 Interoperability Profile for the SmartHouse Roadmap use case A 2 22 Table 7 Interoperability Profile for the SmartHouse Roadmap use case B 1 23 Table 8 object modelling paradigms 24 Table 9 Who is interested in Interoperability? 25 26 27
5
1 Forword
2 This report to EC/EFTA reflects the end results of the CENELEC Project SmartHouse draft3 Roadmap project. It has been prepared by the CENELEC Project Smart House 4 Roadmap Project Team. A previous version has been reviewed by the project’s Steering 5 Committee and was discussed in 2 plenary project meetings. 6 7 The secretariat of the Project is held by NEC.
6
1 Grant Agreement, Steering Group and Project Team
2 The ‘Production of a Roadmap for an integrated set of standards of SmartHouse and draft3 systems relating to it and an Open Event’ is funded under Grant Agreement 4 SA/CLC/ENTR/000/2008 20 between CENELEC and the European Commission. The 5 official starting date of the Grant Agreement has been January 1st, 2009. A call for 6 experts regarding the establishment of the CENELEC Project SmartHouse Roadmap 7 (SHR) Steering Group (SG) and Project Team (PT) was launched on April 28th, 2009. 8 The Kick Off meeting took place on 19th May 2009, and was attended by 26 9 participants. 10 11 Members of the SHR SG: 12 • Philippe Carpentier, Schneider Electric 13 • Joost Demarest, KNX 14 • Beatriz Novel, AFME 15 • Mark Ossel, Echelon 16 • Jean Luc Detrez – Intel 17 • Boudijn Uythof – Domotica Platform Nederland 18 • Paolo Falcioni –CECED 19 • Alan Knight Scott, EDF 20 • Walter von Pattay, ZVEI 21 • Fred te Riet, ExperTel 22 • Alain Lambert, LEGRAND (chairman) 23 24 4 SHR PT Experts for a Paid Position for a totality of 96 person days: 25 • Frank den Hartog, TNO (project editor) 26 • John Parsons, BEAMA (expert editor) 27 • Tom Suters, consultant (expert editor) 28 • Josef Faller, HomeFibre (expert editor) 29 30 The start up of activities was set for 6 months after the date of signature, i.e. July 6th, 31 2009 by a first Face to Face Meeting between SHR SG and SHR PT. The first 32 preliminary results are presented and discussed during a second Face to Face meeting 33 which took place on September 21st 2009. A third Face to Face meeting, with 35 34 participants, took place at March 2 nd 2010, and the final plenary meeting had 25 35 participants and took place at September 10 th 2010. The final report will be published 36 and discussed at an Open Event, which will take place at November 23 rd 2010.
7
1 1. Introduction draft2 1.1 Motivation 3 There are many “independent” standards activities that cover aspects of the 4 standardization of the SmartHouse. However, standardization activity in all three 5 primary European Standardization Organizations (ESOs) in this area is not currently 6 coordinated let alone the activities of Fora and Consortia creating their own 7 specifications. Additionally, there are a number of areas where standardization is 8 required but is not being addressed. The need for work to deliver a cohesive, integrated 9 and interlocking set of SmartHouse Standards is clear. Appropriate and urgent measures 10 are required from public and private policy and decision makers, in industry as well as 11 governments, nationally as well as European. 12 13 Within residential premises, the SmartHouse Code of Practice [1] has already clearly 14 shown that there are a great many organizations, “Technical Committees” and 15 “Bodies”, working in the areas of standardization that are relevant to the SmartHouse. 16 Unfortunately, coordination between them is weak and no coordinated output or 17 integrated set of standards to support SmartHouse concepts is currently in process. The 18 SmartHouse Code of Practice also showed that there is no structure for interoperability, 19 architecture or common way to identify or describe systems, their components and how 20 they interoperate in the SmartHouse. In addition there are a number of areas that will 21 also be essential for the SmartHouse and these include Security (both physical and 22 information), Management of Information, Energy Management, Wellbeing and 23 Telecare and how such systems interact. The SmartHouse Roadmap project arose out of 24 the SmartHouse Code of Practice, though it is not an enhancement or continuation of 25 the same. 26 27 The SmartHouse Roadmap project responds to the section covering Horizontal Actions 28 covering all Priority Domains of the 2008 ICT Standardisation Work Programme issued 29 by the European Commission (CEU) [2]. The ESOs are invited to propose 30 standardization related initiatives to further support the effective take up and 31 implementation of standards in the priority domains listed by this Work Programme. 32 These actions should cover awareness, promotion, information and education, as well as 33 the implementation of pilot projects and interoperability testing. 34 35 The SmartHouse Roadmap project proposal is put forward to the Commission by 36 CENELEC on behalf of NEC to identify the need for the future delivery of Standards in 37 the area of the SmartHouse by the ESOs and the other stakeholders in the SmartHouse 38 as identified by the SmartHouse Code of Practice. Because of its horizontal nature, the 39 action will encompass areas of major importance in Europe such at Energy 40 Management and Sustainability, and also the need to bring Healthcare and Telecare into 41 the community – to people at home, going about their daily activities, who will also 42 benefit from assisted living as they age. It especially shows what will be required to 43 bring high level interoperability of services for people and applications in their homes.
44 1.2 Purpose, scope and objective
45 The purpose of the project is:
8
1 2 • to reflect a snapshot of the existing specifications and ongoing initiatives in the 3 SmartHouse field 4 draft5 • to collect and analyze the current and future needs of the consumer in respect 6 of SmartHouse applications, services and planning confidence 7 8 • to recommend ways and means for use by standardization bodies to support 9 competitive markets for equipment suppliers, system integrators and 10 application and service providers (in particular highlighting overlaps and 11 overcoming gaps) 12 13 The whole of snapshot, needs, and recommendations we call the SmartHouse Roadmap. 14 The needs are represented by a collection of use cases from the industry and an 15 overarching vision of the project team. The recommendations include an 16 encouragement to use a tool developed by the project team to aid future standardization 17 in the SmartHouse field. 18 19 The scope covered by the SmartHouse Roadmap includes all systems, networks and 20 management that enable applications and services to be provided by vendors and 21 service providers of all kinds to consumers in their homes anywhere in the European 22 Union. As such, the Roadmap is focused on all standards for smart house devices 23 including home (and home office) networks, home automation, and multi media 24 platforms, on associated services such as security, energy management and 25 sustainability, health and tele care, and includes applications for service providers of all 26 types having particular relevance to the consumer in the provision of e inclusion and 27 accessibility. The Roadmap also includes some references to relevant areas which 28 contribute to the overall goal of SmartHouse standardization. 29 30 The objective is to provide strategic direction and proposals for the standardization 31 activities of the ESOs (ETSI, CEN and CENELEC), together with the many other 32 bodies that are active in this space, to reflect properly the growth of the SmartHouse 33 and all the services, applications, systems and networks associated with it, and to 34 encourage future market growth. It is intended that all existing and any initiative or 35 standardization work in the area are identified and, in this converging market, a co 36 ordination proposal be issued so that to the greatest extent existing and future work will 37 deliver interoperable solutions for any “SmartHouse” service or application.
38 1.3 Document structure
39 This document is laid out as follows. In the following chapter a deeper analysis is given 40 of the need for further standardization of the SmartHouse field and the role that our 41 Roadmap should play in this. We, the project team, found that the core of our work 42 should concern the enabling of interoperability between standards Ecosystems in order 43 to react to the consumer’s demand for convergence of ICT and technology for CCCB 44 (Control/Command Communications in Buildings) in the home. The Ecosystem of a 45 standard is the core topic of our study and is defined as a group of interacting 46 components that collectively perform the function of the standard. It, for instance, 47 consists of the base standard of a protocol, but also test specifications, installation 48 guidelines, safety requirements, certification programs, etc. 49
9
1 In chapter 3 the chosen approach is presented: we gathered use cases from the industry, 2 deduced and classified the most relevant interoperability opportunities and issues, and 3 designed a standards taxonomy. By plotting multiple standards on the taxonomy, it 4 shows if interoperability between the multiple standards may be achievable and how. In draft5 chapter 4 we present our main result, i.e. the taxonomy. We also show how it works, by 6 plotting the most relevant Ecosystems on it. They were derived from the use cases. 7 Chapter 5 summarizes and concludes the main body of the report. It also describes 8 briefly for which interoperability issues work is already underway. Chapter 6 gives the 9 recommendations to the EC and the ESOs that follow from our work. 10 11 Furthermore, the report contains four annexes. The first one, Annex A, presents the use 12 cases that led to the desired taxonomy and interoperability recommendations. Annex B 13 is the glossary and list of abbreviations. For sake of readability we have not defined in 14 line every single abbreviation we used in the main text. For the meaning of any 15 abbreviation which is not directly obvious we refer to Annex B. Annex C lists the 16 standards and specifications that have been indentified by the project team and the 17 steering committee to be relevant for the Smart House, and useful to be classified with 18 our taxonomy. Annex D gives a short overview of the current activities in Europe that 19 aim to reach higher levels of interoperability in the SmartHouse. 20
10
1 2 Analysis draft2 2.1 Technical, commercial, and deployment requirements for the SmartHouse 3 There are many (thousands) of standards and specifications that are relevant in one or 4 another way for the home environment. Van der Kaa [3] counted 6,568 developed 5 between 1996 and 2006 alone. And there are also many ways (tens) in which they can 6 be classified. But not all standards, specifications, and taxonomies that exist for the 7 home are relevant for the purpose of the project. The second and third purposes of the 8 project (i.e. “to collect and analyze the current and future needs of the consumer” and 9 “to recommend ways and means for use by standardization bodies to support 10 competitive markets”) are therefore further detailed into technical, commercial, and 11 deployment requirements that provide criteria for the selection of standards and 12 taxonomies that are relevant. 13 14 The development of standards (sources and specifications) should not diverge but 15 stimulate and support a competitive market of equipment suppliers, system integrators, 16 application and service providers, and support the current and future needs (plug fast 17 boxes, building blocks, easy configuring and control) of the customer. The Roadmap 18 should be used by parties/ organizations with different roles in the market: 19 • standardization bodies (sources and specifications) for development; 20 • the SmartHouse value chain: service providers, device manufacturers, 21 equipment suppliers, system integrators, application providers, construction 22 companies, installation companies, etc. 23 • any people interested in smart house service for their own home, to inform 24 them about current and future possibilities, and to increase their planning 25 confidence. 26 27 The first conclusion from this is that the Roadmap should not only consist of standards 28 in the official meaning of the word, i.e. a technology, interface, test, requirement, etc. 29 officially designated as a “standard” by an accredited standards development 30 organization and openly available to the public. Many needs of the consumer and a 31 competitive market are and can be served by more or less open specifications, often 32 agreed upon by industry consortia and forums, but sometimes also closed proprietary 33 specifications that have become a de facto standard. Throughout this document we 34 therefore more broadly refer to a (relevant) “standard” as a technology, interface, test, 35 requirement, etc. which is (or probably will be) on a large scale implemented and 36 recognized by consumers and parties in the market. In our final recommendations we 37 indicate which functionality, which may or may not exist already in the market today as 38 a specification, need to be formally standardized in order to create a breakthrough in the 39 SmartHouse market. The project does not recommend a single specification where there 40 is competition in the market between specifications. However, if this competition is 41 stifling market growth in the SmartHouse context, the project recommends development 42 of standardization for the functions which are addressed by the specified technologies. 43 44 The technical requirements for the Roadmap that follow from the project’s purposes 45 are:
11
1 • Help manufacturers from industries to ship their products to a consumers home 2 where they will be interoperable and provide services sharing resources by 3 recommending a limited and helpful set of international (European) standards 4 • Advise consumers who want to access services in and outside the home on draft5 appropriate standards 6 • Recommend a minimum of (existing) standards and specifications that fit in a 7 common architecture providing seamless communication in and outside the 8 home 9 • Assure that standards reach a higher level of interoperability instead of the 10 whole market having to move to one particular standard. 11 12 So, “interoperability” and “a common architecture enabling the sharing of resources in 13 the home” have been found to be the guiding technical requirements that determine the 14 choice of standards and taxonomies for our Roadmap. The interoperability requirement 15 links this SmartHouse Roadmap project closely to the CENELEC Workshop 4 ‘An 16 Interoperability Framework Requirements Specification for Services to the Home' (CLC 17 WS 4 IFRS) and its recently published CWA [4]. 18 19 The commercial requirements for the Roadmap that follow from the project’s purposes 20 are: 21 • Enable intra- and inter-domain applications & services, such as home 22 automation, home appliances, entertainment, health/well being, security, etc. 23 • Support relevant existing Ecosystems. The Ecosystem of a standard is a group 24 of interacting components that collectively perform the function of the 25 standard. It, for instance, consists of the base standard of a protocol, but also 26 test specifications, installation guidelines, safety requirements, certification 27 programs, etc. 28 • Support different business models for the different products: 29 o Professional (b2b) and consumers (b2c) 30 o Installers and retail/do it yourself (DIY), 31 o Closed and open (3 rd party services) 32 • Recommend ways for how installers or consumers can integrate different 33 systems coming from different business models into one interoperable system. 34 Said otherwise: support installers and consumers by providing them with a set 35 of standards that interoperate. Industry may compete in the market with 36 different systems based on different business models. But if industry chooses to 37 cooperate, the Roadmap may help to realize interoperability. The differences in 38 business model are relevant to the taxonomy of standards and the solutions we 39 will propose. 40 41 The deployment requirements for the Roadmap that follow from the project’s purposes 42 are 43 • Allowing migration, innovation and change in technology, application 44 domains, business models 45 • Guarantee user experience within identified business models
46 2.2 Convergence and interoperability
47 Application domain is the first, obvious dimension for a taxonomy of SmartHouse 48 standards. Traditionally, most specifications have been developed with a single 49 application domain in mind, such as:
12
1 • Broadband communication services 2 • Multimedia and Entertainment 3 • Safety and Security 4 • Home automation for comfort services draft5 • Tele care/health 6 • Energy Management Services. 7 8 In early times, these domains were completely decoupled. This is schematically 9 indicated in the left hand side of Figure 1. A typical household in the nineties had white 10 goods, brown goods, a gaming device, a fixed telephone, a thermostat and an electricity 11 meter. These devices were not connected to a network, or to a stove pipe delivery 12 network of a service provider. The TV was only for entertainment and not for 13 broadband communication or tele care/health. Only intra domain interoperability 14 between standards and specifications was relevant, ensuring that TV’s from any 15 manufacturer would perform consistently with a common signal. Each application 16 domain has its own requirements and therefore its own solutions when it comes to home 17 networking technology and standards. It should therefore not come as a surprise that 18 within a home multiple incompatible “islands of connected devices” exist, each using 19 their own domain specific and therefore, most of the time, different and incompatible 20 home networking solutions. 21
22 23 Figure 1 . Convergence towards smart houses. 24 25 However, times have changed and now a large drive for convergence is being 26 observed, leading to an increased demand for inter domain interoperability. This is 27 indicated in the right hand side of Figure 1. As services demand, devices communicate 28 freely, robustly, and securely with each other and with any broadband access network 29 via home gateways. In this way, the home is more and more becoming an integral part 30 of the Internet or the Future Internet [5]. Devices and services are very personal, so 31 which particular devices and services are actually present and interconnected can be 32 very different for every house, whereas in the nineties there was much more uniformity. 33 This fits in a more global trend of society migrating from the Industrial Era towards a 34 global Information Society, in which the industry moves from mass production of goods 35 to personalized service delivery. 36 37 The trend of convergence is the main cause for the need of an integral SmartHouse 38 Roadmap. Most developers, integrators and regulators have an angle of view from a 39 single domain, and lack the oversight over the other domains to make informed 40 decisions towards convergence. However, it is the end user, and with him the service 41 providers and regulators, who increasingly demands resources to collaborate and be 42 shared, because he perceives added value from this. Especially energy management
13
1 drives a strong need for interoperability from the viewpoint of a regulator. E.g. the same 2 sensors can be used for multiple applications like security, energy management and 3 lighting. The use cases we gathered show this clearly.. 4 draft5 The vast majority of the European homes will have a broadband Internet connection 6 during the implementation window of this Roadmap document (i.e. 2011 2016). Due to 7 cost reductions it is becoming feasible to add smart functionality to more and more 8 house system components. This will result in an increasing number of advanced 9 connected devices in the SmartHouse that have capabilities, services, and content that 10 users wish to share among other devices and services within or between Ecosystems. 11 12 This potential will be used for an increasing number of more or less intelligent 13 applications within the SmartHouse. As well as lifestyle applications this also concerns 14 sustainability and social applications, such as demand management and telecare, 15 respectively. These applications may require different solutions for control (by the end 16 user) and security. It is known that consumers do not want a proliferation of dedicated 17 remote control devices for these applications, i.e. one for every single new application. 18 Without standardization, many devices (remote controls and others) will appear in the 19 home that have (partially) the same function, but are allocated to a specific application. 20 We also observe a proliferation of different wireless, wired, and no new wires 21 communication networks appearing in current homes. Consumers would like to stop 22 this proliferation because of the implied managerial hassle (see Figure 2) and co 23 existence problems. 24
25 26 Figure 2 . An example of increased managerial hassle due to a proliferation of devices in the home. 27 28 Basically there are three types of benefits that follow from convergence: 29 1. Reduce deployment costs and increase sustainability by using each others 30 infrastructure 31 2. Using generic infrastructures creates opportunities for additional intra 32 domain innovations 33 3. Using generic infrastructures may lead to opportunities for inter domain 34 innovations 35 36 In the current literature, inter domain innovations are also often called trans-sector 37 innovations [6]. The United States, Australia, New Zealand, and The Netherlands are 38 seen as being front runners in stimulating trans sector innovation in the SmartHouse 39 environment [7]. Outside the home context of the user, a typical example of a European 40 trans sector innovation is E call [8]. 41
14
1 Looking at the domains mentioned above, it can be easily seen that some domains are 2 further ahead than others in enabling inter domain interoperability. This counts most 3 notably for the broadband communications services domain, which is in itself already a 4 converged domain of telecommunications and computer networks. Also, with the dawn draft5 of services such as IP TV, interactive TV and user generated content (web 2.0), full 6 convergence of the broadband communications services domain and the 7 multimedia/entertainment domain can be expected in the short term. The properties of 8 Internet technologies can be seen as the main technical enabler of this convergence. 9 However, innovation in the other four domains is still somewhat dominated by a 10 tendency to create stove pipe ICT solutions, sometimes leading to poorly standardized, 11 not very scalable, expensive and closed systems that have limited capabilities for 12 interoperating with systems from other domains. The perceived lack of dependability 13 and security of current Internet networks lie behind the design decisions of these 14 systems.
15 2.3 Problem Space: Application Domains, Ecosystems
16 2.3.1 What is the home network intended to do? 17 The purpose of a home network differs per domain. In many cases the primary purpose 18 of home networks is to connect devices in the home to an Access Network outside the 19 home to get access to a Service. An Access Network is the part of a public network that 20 connects a home or an end user’s device to a Service provider. A Service is a specified 21 set of user information transfer capabilities provided to a group of users by a 22 communications system. Examples are the coax cable in your home connecting the TV 23 to the cable or satellite broadcast network or the Ethernet cable or Wi Fi network 24 connecting all PCs in the home to the Internet. The same holds for smart metering and 25 energy management domain where the primary goal of the utility company is collect 26 data from multiple meters and to control appliances or energy generators in the home. 27 These home networks are used as a point to (multi)point extension of the Access 28 Network, as part of a vertical service delivery pipe. They are not primarily intended to 29 enable devices in the home (whether in the same domain, let alone across domains) to 30 communicate directly with each other. 31 32 Home Automation networks usually support both device to device and Access Network 33 communication. They allow devices to communicate directly with each other (e.g. the 34 thermostat to the HVAC system) as well as to connect to an Access Network (e.g. the 35 security camera to the Internet). 36 37 So called Peripheral Networks support direct device to device communication in the 38 home but only as a way to connect peripherals to a “master device”. Well known 39 examples here are SCART or (wireless) HDMI to connect a DVD/BD or HDD 40 player/recorders to a TV or USB to connect a mouse, keyboard, webcams, printers etc. 41 to a PC. Communication only takes place between the master device (the TV or PC) 42 and its peripherals, not between peripherals directly. An important category of 43 peripheral devices are the well known remote controls using Infrared or RF networks. 44 So far however they usually only control one device and they are brand specific. For the 45 SmartHouse Roadmap (SHR) having a good solution for controllers that enable users to 46 control all kinds of devices from different domains is an essential element. 47
15
1 The “PC network” was from the very beginning invented to share PCs, storage and 2 printers in the home as well as connect them to the Internet. It is also in this domain that 3 it has become more and more customary to connect devices from the broadcast domain 4 like the TV, the mobile phone, and mobile AV players,to this PC network, turning it draft5 into a true home AV network. Since this home AV network evolved from the PC 6 network that itself evolved from the Internet connection, it is no wonder that the PC and 7 home AV network are all based on Ethernet, WiFi, IP and other protocols standardized 8 by IEEE 802 Working Group, WiFi Alliance, IETF and W3C.
9 2.3.2 Quality of Service 10 Home networks belonging to different domains have different characteristics when it 11 comes to Quality of Service. Therefore home networks in different domains are not 12 only different but were simply never intended or designed to be shared in the first place 13 and are therefore sometimes even physically separated. The best example here is the 14 Ethernet cable connecting a cable modem to a Set Top Box (STB) for digital TV 15 distribution and a second Ethernet cable connecting the same cable modem to your 16 home AV Network to share media as well as Internet access. It should be noted that the 17 Internet connection of a modern Internet TV is still separated from the network that 18 connects the STB to the Access Network. 19 20 Aggregation of traffic of the TV and Internet domains occurs in the Home Gateway (in 21 this case the cable modem) and in the shared Access Network where it can be properly 22 managed. Digital TV Providers simply do not want to share “their home network” with 23 devices and traffic they can not control if it endangers their service. Only if there is a 24 strong use case with added value for their viewers, or if they are forced by competition 25 (Internet TV) or regulation might they be willing to reconsider.
26 2.3.3 Security 27 The same as in the previous section can be said about security. Home networks 28 belonging to different domains have different characteristics when it comes to the 29 implementation of network and data security. They were never intended or designed to 30 be shared in the first place, and their obvious physical separation is an inherent part of 31 the security provided. In the case of home security services, the need to ensure 32 communications integrity has led security service providers to keep their networks 33 completely separated from other applications. Although there may be a strong use case 34 that shows the added value of interconnecting these domains, the lack of an overarching 35 security architecture guaranteeing end to end security is a significant barrier for even 36 trying.
37 2.3.4 Market Penetration 38 There are also big differences between domains in their market penetration of home 39 networks and therefore the number of devices as well as “infrastructure” that exist in 40 homes today that support a specific domain. We refer to the many reports published and 41 updated regularly by market research companies such as Forrester Research, Parks 42 Associates, ABI Research, and Frost & Sullivan, but also to the statistics gathered and 43 published by the Organisation for Economic Co operation and Development (OECD, 44 see Broadband Portal). The following observations can be made with respect to market 45 penetration: 46 • The penetration of broadband access is nearing 100%. At the end of 2009, about 47 80% of the homes in Scandinavian countries were connected, and more than 50%
16
1 in most of the rest of Europe. More than 50% of the connected house holds have a 2 broadband data network in the home, and most of them contain Wifi. 3 • A significant amount of devices in the home support DLNA, such as Network 4 Attached Storages, PCs, TVs, smart phones, and media players. Also Microsoft’s draft5 Operating System Windows 7 and many of the TVs sold today support the DLNA 6 protocol suite. However, a clear standard for application support by TVs does not 7 yet exist. 8 • The market penetration of mobile phones is 100%. The market share of Internet 9 enabled browser based smart phones is expected to grow over 50% in 2011, 10 although there is strong competition between various non interoperable operating 11 systems for smart phones. All mobile phones support Bluetooth and all smart phone 12 support Wifi in addition. In The Netherlands, about 80% of the homes have a 13 DECT cordless phone, and we expect similar penetration elsewhere in Europe. 14 • In the US, about 10% of the households have some form of home automation (or 15 home control). In Europe it is expected to be the same or less. The market seems to 16 be growing with new applications such as energy management becoming popular. 17 The technology space is characterized by many (recently standardized) Ecosystems 18 as well as proprietary technologies.
19 2.3.5 Industry Standards & Ecosystems 20 It is important to note that in the past two decades, industry standards have become 21 more and more important. Well known examples are the IETF and W3C standards for 22 Internet and IEEE 802 and Wi Fi as the home network solution for wireless Internet 23 access. These industry standards have become very successful in terms of deployment 24 and market success in a very short period of time. The main reason for this success is: 25 • The Internet revolution as the single driving use case 26 • The need to make Internet available on many different devices in the home 27 • The desire not having to wire the home to connect all these devices to the 28 broadband network in existing homes (for newly built homes or home to be 29 retrofitted this is less of an issue) 30 • Groups of industry leaders forming alliances representing complete Ecosystems 31 of device manufacturers and technology suppliers willing to invest and to 32 create new big markets compared to proprietary solutions. 33 • A joint effort by these Ecosystems to create interoperability specifications. 34 These specifications are usually subsequently offered to official standards 35 bodies like ISO/IEC. ETSI, CEN/CENELEC for official standardization. 36 • Certification and logo ing programs to guarantee interoperability and 37 recognition. 38 • Joint marketing programs to explain the logoed technologies to the public. 39 40 Examples of other successful Ecosystems are DECT for cordless telephones in the 41 home and Bluetooth as a peripheral network for mobile phones to connect headsets and 42 to exchange audio, calendars and media (images, videos and music) with the PC and 43 other phones. However, for these Ecosystems it was more difficult to explain the logo 44 to the public because the standards cover multiple use cases (applications) and not every 45 device necessarily supports all these applications. As a result two devices with the same 46 logo may or may not be interoperable.... Similar issues are observed in Ecosystems like 47 DLNA (sharing home AV media) and KNX (home automation).
17
1 2.4 Challenge
2 The challenge of the SmartHouse Roadmap project is to create a result from which 3 guidelines and recommendations can be deduced which help the market in designing draft4 and deploying inter domain systems that drive costs down and stimulate intra as well 5 as trans sector innovation. In this way, the home of the user becomes really smart in 6 terms of the user’s needs. This requires Roadmaps which are not specific to domains. 7 8 We assume that the technical barriers for convergence in the Smart House will diminish 9 over time with cost reduction of components of communication interfaces, i.e. Moore’s 10 law and the like will continue to prevail. The technical assumptions (requirements) 11 underlying the architectures of current Ecosystems will therefore change over time. For 12 example: in time, also simple low power devices will be able to support the TCP/IP 13 protocols cost effective. Our Roadmap therefore looks at what will be feasible over 14 time. The recommendations address actions that can improve and rationalize the current 15 situation as well as accommodate future technology developments. 16 17 There are two major challenges involved in deriving the Smart House Roadmap. Firstly, 18 the aggregation of services from independent providers requires the replacing of the 19 vertical integration model (service delivery pipe) with a so called horizontal model to 20 allow: 21 • Providers sharing access networks and home networks to deliver their 22 services to consumer devices 23 • Consumers using portable and in home devices to access multiple services 24 • Consumers modifying, adding to and replacing his home services, devices, 25 and appliances without losing control of the process over the lifetime of his 26 home 27 • Consumers changing to another service provider or service level without the 28 need to install new networks or other infrastructure in the home (no service 29 provider lock in) 30 • Consumers changing to another product vendor or enhanced product without 31 the need to install new networks or other infrastructure in the home (no 32 product provider lock in) 33 34 Secondly, a horizontal model requires an agreed set of functions and interfaces for the 35 horizontal layers in the protocol stack to enable some defined level of interoperability 36 between service delivery pipes. 37 38 The SmartHouse Roadmap project thus aims to enable a transition in the 2011 2016 39 time frame to a horizontal model for applications and services delivery pipes, by 40 creating 41 • A set of relevant use cases that have commercial value, are supported by key 42 industry stakeholders and require extensions to current functionality (Annex 43 A) 44 • a clear vision on the role of and the need for standards in this transition to 45 enable open markets and fair competition (Chapter 2) 46 • A Roadmap of existing or to be developed standards and technologies that are 47 best suited to facilitate this transition (Chapter 4) 48 • A set of recommendations to stimulate a successful deployment of the 49 Roadmap covering issues like transition scenarios and compliance testing 50 (Chapter 6)
18
1 2 Enabling Migration of and Interoperability between Ecosystems in the home 3 environment has been identified as the key goal for SHR. 4 draft 5 2.5 Project vision summary: overview of observations and assumptions
6 Determining future issues and opportunities for interoperability must inevitably be 7 based on a certain vision of the future digital home environment, here called “the 8 SmartHouse”. This chapter elaborates that vision, which can best be summarized as a 9 collection of observations and assumptions we make. They are listed below.
10 2.5.1 Observations 11 12 O1. We observe a proliferation of different wireless, wired, and no new wires 13 communication networks appearing in current homes. 14 15 O2. We observe an increasing number of advanced devices in current homes with 16 capabilities, services, and content that users wish to share among other devices 17 in other Ecosystems. 18 19 O3. We observe an increasing number of more or less intelligent applications within 20 current homes, and most of them have their own control interface (remote 21 control). 22 23 O4. We observe increasing frustration amongst users and service providers because of 24 the significant increase of managerial hassle and interoperability problems 25 (such as co existence) that often follow from the various forms of proliferation 26 as mentioned above. Users and service providers increasingly wish to re use 27 existing devices and networks for new services. This is also stimulated by 28 regulators, who increasingly demand efficient use of technology. Users, 29 applications developers, service providers and regulators are the main forces 30 that drive the need for interoperability and convergence in the SmartHouse. 31 32 O5. Convergence and interoperability mean that different services can use the same 33 resources, and comparable services may choose to use different resources. 34 However, different services need different levels of robustness (QoS, 35 reliability, network diagnostics and repair, …) and security (encryption, 36 authorization, …). Technologies for robustness and security do not yet have a 37 significant market penetration, and the industry is still discussing their 38 suitability and need. In the mean time more and more security and robustness 39 unaware devices and services keep entering consumer’s homes, increasing the 40 legacy and thus making adoption of standards and realization of 41 interoperability more difficult. On the other hand, some applications, such as 42 Security, have very high requirements for robustness and cannot yet 43 compromise their QoS requirements when sharing resources. 44 45 O6. We observe that some good interoperability frameworks, containing standardized 46 technologies for discovery, configuration, operation (sharing, control, etc), and 47 management, are already implemented in today’s devices, but are switched 48 “off” by factory default. Often they cannot be switched “on” by the user, and if 49 they can, the user interface to do so is often not easily accessible and 50 understandable for the non specialist user. For instance, who knows that
19
1 selecting “resource sharing” in the Windows Media Player is the way to switch 2 UPnP “on” on the PC? 3 4 O7. We observe that Home Gateways fulfil a crucial role in interoperating WAN with 5 SmartHouse Ecosystems, and in making SmartHouse Ecosystems interoperable draft6 among each other. 7 8 O8. In many domains (such as telecommunications, IT, and multimedia), networks 9 using IP have proven to increase interoperability between Ecosystems, and to 10 provide a platform for service innovation. We observe that adoption of IP by 11 other domains (such as health care and energy) is often obstructed by lack of 12 in depth understanding of the TCP/IP Ecosystem. For instance, many people 13 incorrectly think that the use of IP is inextricably connected to the use of 14 Ethernet like networking technologies on the data link layer and physical layer. 15 Also it is often not understood that supporting IP end to end offers advantages 16 in terms of scalability compared to the use of IP gateways as we find them 17 already deployed ubiquitously nowadays (e.g. for KNX networks). 18 19 O9. Various trials and deployments show that home networks will become 20 significantly more simple, sustainable, and flexible for services if homes are by 21 default provided with a high bandwidth, highly reliable backbone 22 infrastructure, either wireless or wired with many data access points. In 23 practice, such a backbone infrastructure makes it easier to interconnect 24 Ecosystems, to exchange them for other Ecosystems, to scale up a single 25 Ecosystem subnet, and to physically separate Ecosystems if a user prefers them 26 not to interoperate. 27 28 O10. More and more specifications are developed in industrial consortiums and become 29 de facto standard in the market that may or may not be subsequently officially 30 standardized in a recognized (European) standards development organization.
31 2.5.2 Assumptions 32 33 A1. We assume that the vast majority of European homes will have a broadband 34 Internet connection during the implementation window of this Roadmap 35 document (i.e. 2011 2016). 36 37 A2. We assume that the number of advanced devices in the SmartHouse with 38 capabilities, services, and content that users wish to share among other devices 39 in other Ecosystems will continue to increase. 40 41 A3. We assume that consumers do not want a further proliferation of dedicated remote 42 control devices for these applications, i.e. for every single new application one. 43 We also assume that device manufacturers and service providers would rather 44 not have to provide such dedicated remote controls. 45 46 A4. We assume that many more devices will appear in the home that have the same 47 more or less generic function, but are allocated to a specific application. 48 49 A5. We assume that consumers would like to stop the various forms of proliferation 50 mentioned above (of devices, remote controls, and networks) because of the 51 implied managerial hassle and interoperability problems. 52
20
1 A6. We assume that many technical barriers for convergence in the SmartHouse will 2 diminish over time with cost reduction of components of communication 3 interfaces and increasing available bandwidth of home networks. Said 4 otherwise, we assume that Moore’s law and the like will continue to prevail. 5 The technical assumptions (requirements) underlying the architectures of draft6 current Ecosystems will therefore change over time. For example: Simple 7 devices such as many sensors and controllers will at some stage need end to 8 end addressability for energy, home control, safety, and security applications. 9 Moore’s law dictates that they will some time be able to support the IP protocol 10 cost effective, because the chipset needed for that has become commodity. The 11 Roadmap recommendations should address actions that can improve and 12 rationalize the current situation as well as accommodate future technology 13 developments. 14 15 A7. We assume that governments are likely to introduce requirements for the 16 deployment of back bone network infrastructures in new houses to be built 17 within the time frame of the SmartHouse Roadmap. 18
21
1 3 Approach
2 In this chapter, the process for developing the Smart House Roadmap will be described. draft 3 3.1 Starting point of the project approach: convergence and migration
4 Based on the above considerations around the diversity of all the different Ecosystem 5 standards the approach of the SHR can be summarized as: 6 • Application Domains are not well defined and the borders between Application 7 Domains are constantly blurring over time. The best approach to uncovering 8 interoperability challenges needs to be based on concrete use cases involving 9 devices and existing Ecosystem standards. 10 • Ecosystems address specific use cases and define or guarantee a certain level of 11 interoperability between “their devices” in specific use cases. 12 • SHR use cases include Internet multimedia services, in home AV 13 entertainment, broadcasting, home automation, smart metering and telecare. 14 Devices can range from PCs, TVs, multimedia players, video and photo 15 cameras to storage devices, (mobile) phones, HVAC devices, sensors, displays, 16 controls etc as well as combinations of these. 17 • SHR use cases need to enable access to these in home devices from other in 18 home devices as well as multiple external services across different Ecosystems. 19 • Multiple competing and/or incompatible Ecosystems will always exist, or new 20 Ecosystems based on new technologies that overlap with use cases of existing 21 Ecosystems will be developed as technology advances. SHR cannot and should 22 not try to prevent this innovation. 23 • SHR will not select between competing standards. Which standard(s) will 24 prevail is considered outside the scope of the SHR and will be determined by 25 the market. 26 • Instead SHR needs to recommend how incompatible Ecosystems should 27 migrate or converge to achieve some defined level of interoperability. SHR 28 needs to give a taxonomy for these levels and a taxonomy for the standards 29 themselves to determine these levels. 30 • The value of the underlying use cases to the Ecosystem partners or otherwise 31 regulatory pressure will determine whether the Ecosystem will migrate 32 according to the SHR. As shown above in the example of digital TV 33 distribution sharing devices and home networks is not always in the interest of 34 all players in the value chain of these use cases and therefore will not happen 35 even if it is desirable from a user point of view.
36 3.2 Project approach: overview
37 The complete project approach is schematically depicted in Figure 3. Phase 1 of the 38 project concerned the gathering of all relevant information (use cases, reference models, 39 standards, etc.) needed for deducing the main results of the project, i.e. the taxonomy 40 and the recommendations (phase 2). 41 42 The core of phase 1 is the collection and description of about ten good use cases 43 covering important application domains (and their convergence), with market relevance, 44 describing: 45 • Their value chain and main actors
22
1 • Possible interactions as well as impossible but desired interactions within and 2 between today’s relevant services from a user perspective 3 • Today’s deployed standards and technologies for these interactions 4 draft5 The quality of these use cases is strongly dependant on the template one uses and the 6 reference model used to visualize the use case with its standards and technologies. The 7 template we chose is provided in Annex A. It is derived from what is used in DLNA, 8 The reference model we used is new, and derived from many examples in the literature 9 (e.g. [9 10]). It defines terminology to describe elements and interfaces within and 10 between service delivery pipes. It does not deserve the name “architecture” as defined 11 in e.g. [11], but it serves our purposes. We therefore speak about “reference model 12 (RM)” rather than reference architecture. 13 14 From the use cases and the long list of existing Ecosystems relevant to the SmartHouse, 15 we then create interoperability profiles which show at a more abstract level where the 16 needs for interoperability really are, and a short list of standards relevant to the use 17 cases. From the interoperability profiles we deduced a common taxonomy of standards 18 as a tool capable of creating interoperability profiles from use cases. The SmartHouse 19 Roadmap is formed by plotting our short list of standards from our use cases on the 20 taxonomy thereby identifying the interoperability needs and challenges for our use 21 cases. From the SHR Roadmap we then derived recommendations for the EC and the 22 ESOs. 23
SHR PHASE 1 SHR PHASE 2
SHR-RA instantiation Generic SHR OUT: view Roadmap & SHR IN: Visualized by SHR-RM Recmmendations Stakeholder Deployment Market view contains requirements contains Described by Use Cases HN Device Common EcosystemHN DeviceInterop instantiation shows HN Device interoperability Ecosystem InteropProfile Interop. Ecosystem Interop Taxonomy Profile Use Case issues Profile defines instantiation template between 24 25 26 Figure 3. Flowchart of the SmartHouse Roadmap approach
27 3.3 Stakeholder Requirements: Use Cases
28 The success of the SHR will be determined by its deployment and adoption by the 29 industry during the time span it addresses (2011 2016). This depends however largely 30 on whether there actually exist use cases that the industry is willing to invest in. The 31 underlying technologies or standards play a secondary role. 32
23
1 Collection and verification of relevant use cases therefore formed an important part of 2 the SHR approach and encompassed the first phase of the project. Use cases that require 3 interoperability between Ecosystems are easily “invented” based on “common sense” 4 assumptions on what we all would like to be possible as consumers to improve our life draft5 or what is desirable from a political point of view. However consumers only represent 6 one part of the stakeholders of a use case. Unless the industry sees the value of such a 7 use case and sees a business model for it, it is unlikely that steps are taken (preferably 8 along the line of the SHR recommendations) to actually achieve the use case objectives 9 unless this is stimulated by government regulation. 10 11 In the SmartHouse Plenary Meeting that was held on the 2 March 2010 we invited the 12 industry and relevant Technical Committees from standards development organisations. 13 We prepared and discussed several use cases for this workshop and a few more were 14 developed during the workshop. The industry support of our use cases is mainly based 15 on the input from the 35 participants of the face to face plenary meeting. This may be 16 interpreted as a discrepancy between the need for convergence as felt by the end user 17 and the willingness of the industry to actually develop the interoperability solutions for 18 these use cases. We are therefore not claiming that the use cases are well supported by a 19 large industry base. 20 21 To our knowledge none of the Ecosystems we consider is currently working on similar 22 use cases. E.g. smart metering gets a lot of attention and is heavily pushed by the EC to 23 reduce the energy footprint of consumers. Standards are being or have been developed 24 and are partly starting to be deployed in trials but interoperability with other 25 Ecosystems is not a high priority issue or is dismissed based on technical grounds. In 26 other words this might lead to yet another vertical bit pipe into the home controlling 27 individual appliances and requiring special control devices in the home while it might 28 be rather simple to use existing devices such as the TV or mobile phone to control these 29 appliances and at the same time communicate with the service provider. 30 31 In summary it remains therefore questionable whether we actually captured the main 32 stakeholder requirements and if business models actually exist for the SHR use cases. In 33 other words: are consumers willing to pay for it or do governments need to play a 34 stimulating role here? Verifying the value and business models of our use cases with 35 actual consumers and the industry via market research would require a major effort and 36 is considered outside the scope of this SmartHouse Roadmap project. Our Roadmap is 37 produced assuming that our use cases are relevant and have a valid business model. 38 However, the objective has been to develop approaches and tools for others to use 39 rather than to solve specific business problems.
40 3.4 Selection and analysis of a representative set of Ecosystem standards.
41 Many policy makers have expressed the need to have an overview of all standards of 42 the SmartHouse in a structured way. Also during plenary meetings of the SmartHouse 43 Roadmap project this wish could be heard. However, this is practically impossible, 44 mainly because of the sheer amount of standards that exist for the SmartHouse in its 45 most extended definition [3]. For this project we therefore constructed a much shorter 46 long list of standards which we deem to be relevant for the SmartHouse in 2010, by 47 using the following selection criteria as a filter: 48 • Only standards and specifications that have a documented relevance to 49 interoperability and convergence of Smart House specific applications
24
1 • Only standards and specifications that have a documented relevance in the 2 market 3 • Preferably European standards and specifications. International (global) 4 standards and specifications only if relevant and European equivalent are not draft5 available. National standards and specifications only if international and 6 European equivalents are not available. 7 • Only finalized standards and specifications. No drafts or non normative 8 guidelines and technical reports. 9 • Only the latest versions of the standards and specifications, and older versions if 10 they are still supported in the market 11 12 The resulting long list of standards is given in Annex C. They can be grouped in 13 Ecosystems, and this long list of Ecosystems is given in Chapter 4. From the use cases 14 we then constructed a short list of Ecosystems. They are the ones for which we created 15 interoperability profiles (and to create a Roadmap and recommendations), highlighting 16 the functions for which we need interoperability to achieve the interactions described by 17 the use case. These functions then form the basis of our taxonomy dimensions. We 18 expect that other standards of the long list can be classified and analysed as well using 19 the taxonomy, but we leave the actual work up to any party with a particular interest in 20 those standards. Our taxonomy is distinctly different from the one proposed in ISO/IEC 21 29107 [12]. Many of the proposed dimensions in ISO/IEC 29107 seem criteria for 22 selecting standards given a certain context, and are not relevant for assessing 23 interoperability.
24 3.5 SHR Reference Model (SHR-RM)
25 SHR RM is a tool for describing use cases of smart house services and applications. As 26 starting point we used the model from ISO/IEC TR 29107 [12] as depicted in Figure 4. 27
28 29 30 Figure 4 : Reference model as used in ISO/IEC TR 29107 31 32 While this model gives a good overview of the networks involved, it purposefully 33 abstracts from the actual devices and protocols in the home. Although it shows that 34 multiple islands exist in the home each using their own protocols and interoperability 35 solutions, we wanted to be able to describe and make visible: 36 • Actual devices as they exist in homes
25
1 • Actual networks as they are used in homes 2 • All the players and roles of the value chain of the services 3 • Relations between players, roles and device ownership 4 draft5 Besides, Figure 4 represents a domain view of the Smart House reference model. It 6 assigns devices to clusters covering “similar applications” connecting them to one 7 “abstract” domain specific home network. Unfortunately it is rather arbitrary what is 8 deemed “similar”, and it is difficult to assign applications, devices and networks to one 9 particular domain. There is also no one to one relation between domains and specific 10 standards. Most domain standards use the same technologies and standards used by 11 other domains. Continua, for instance, uses IEEE 802 and Bluetooth protocols used by 12 PC/CE and telephony applications. We therefore conclude that a domain view is not 13 very helpful when classifying standards and technologies (as a taxonomy) to discover 14 interoperability (mis )matches. 15 16 The reference model that we designed for the SmartHouse Roadmap is shown in 17 Figure 5. It contains all the generic building blocks needed to describe any smart house 18 service or application based on devices in the home. This model can be used to describe 19 both applications wholly contained within the home, such as home automation, and 20 applications depending on external services. A user may connect devices within the 21 home, and a user may access a service through multiple devices (service sharing). A 22 device may give access to multiple services from different Service Providers (SPs, 23 device sharing). A device can be used in or outside the home (portable devices). A 24 service may share networks with other services along the path from SP to device. 25
SHR Reference Model (SHR-RM)
Service Access Network SP/NP Home Network RetaiL Peripheral Providers Providers Ecosystems devices Ecosystems devices Networks & Devices
NP 1 NP 2 NP 3 HN HN HN PN PN Eco Eco Eco Eco1 Eco2 Eco3 Eco1 Eco2
PD 1 R-EUD 1
PD 2
NP-NID 1 (network terminator) SP1
SP-NID R-EUD 2 (home gateway) SP2
Virtual Backbone PD 3
SP-EUD 1
SP3 R-EUD 3 SP-EUD 2
26 27 Figure 5. SmartHouse Roadmap Reference Model 28 29 Service providers (SP) provide a service (e.g. a Web service, ISP service, TV,voice) 30 typically from outside the home to end user devices (EUD) in the home. Access 31 Network providers (NP) provide the use of their AN (e.g. ADSL, Cable, Satellite) to the 32 end user and to service or other network providers (roaming). End user devices
26
1 (EUDs) in the home may provide in home services to other EUDs in the home (e.g. 2 home automation applications) or to the Internet. 3 4 The following definitions are used describing the infrastructure and networks. draft5 • Access Networks (AN): the last hop of the service delivery pipe that 6 physically connects (indicated via thick line and black dots) an End User 7 device (EUD) or a Network Infrastructure Device (NID) in the home to an 8 service delivery network outside the home. 9 • EUDs: devices operated by the end user and offering a User Interface (UI) to 10 the end user through which he can access services. EUDs can be managed and 11 owned by 12 o the service provider: SP EUD, e.g. a Set Top Box or a Home 13 Gateway). SP EUDs are usually leased or given away for free by 14 service providers as part of the service agreement. 15 o the consumer: R EUD (retail EUD). e.g. a TV or PC. The consumer 16 buys these devices independent from the SP in the retail shop. 17 • NIDs: EUDs that do not offer a UI to the end user to access the service itself 18 e.g. network terminators, bridges, switches, routers, gateways . NIDs carry 19 and/or manage the data of the service delivery pipe. NIDs may provide a UI to 20 the end user to configure the functions of the NID or these devices may be 21 managed remotely by the network provider (NP) or service provider (SP). The. 22 Home Gateway is an example of a NID. 23 • Home Networks (HN): physically interconnect (indicated via thick line and 24 black dots) EUDs and NIDs inside the home . 25 • Virtual Backbone (VB): virtually connects (indicated via dotted oval, thick line 26 and white dots) an AN to a global infrastructure like the Internet or POTS or 27 IMS backbone connecting NPs and SPs. How this is done is out of scope for 28 the Reference Model. It may involve complete (inter )networks running 29 business or management applications between SPs and NPs. 30 • Peripheral Networks (PN): physically connects (indicated by thin line and 31 black dots ) peripheral devices (PD) to a master device, e.g. USB, HDMI, and 32 Bluetooth. PDs typically connect to one master and do not exist stand alone. 33 The master may aggregate PD device functionality and make it accessible over 34 the HN. Some PN technologies can in principle also be used for HN, e.g. 35 Bluetooth, and IEEE 1394. EUDs and NIDs can have both PN and HN 36 interfaces. 37 38 Relations between SPs and NPs in the value chain are indicated in the SHR RM using 39 colours. Identical colours indicate that an SP also is the NP of the AN over which the 40 service is delivered. Different colours indicate that an SP (e.g. Web service, ISP) uses 41 the AN from a 3rd party NP. An SP may control and manage the EUD or NID devices 42 via which the service is accessed or distributed into the home. EUD and NID colours 43 identify the SP or NP that manages and controls them. In home services such as an 44 HVAC controlled by a portable display, may or may not require interaction with an 45 (external) SP. R EUDs have a grey colour indicating they are not owned or managed by 46 an SP or NP.
27
1 3.6 Interoperability considerations
2 Various levels 1 of interoperability can be distinguished. A practical model for this is 3 given by CWA IFRS [4]. The model is presented in Table 1. Convergence between draft4 Ecosystems as targeted by SHR does not require interoperability to conform to every 5 single IFRS level. Technologies used in a single house must at least co exist, i.e 6 conform to IFRS level 1. The need for conformance at higher IFRS levels depends on 7 the SHR use cases. A system is declared as not interoperable if the use case demands a 8 higher level of interoperability than the technologies can deliver. 9 10 Table 1. The interoperability levels as identified in CWA IFRS [4]. The CWA defines conformity 11 requirements only for levels 4 6 12
13 14 15 Various ways exist to solve interoperability issues between Ecosystems. The best is to 16 specify and standardize different protocols in such a way that they become 17 interoperable, i.e. guarantee level 3 at least. For that, a separate standard shared between 18 Ecosystems specifying the interoperability is often needed. Another way to solve 19 interoperability issues between Ecosystems is to define Application Level Gateways 20 (translation boxes) between non interoperable Ecosystems. This would at least 21 guarantee IFRS level 2 interoperability. 22 23 The interoperability profiles for the SHR use cases when plotted in our taxonomy only 24 show for which part of a service (termed Service Building Block in the SHR 25 taxonomy) multiple Ecosystems exist that may or may not be interoperable on a given 26 protocol level (e.g. OSI level). If interoperability is required but not provided, further 27 action may be needed to ensure interoperability. 28 29 Our taxonomy can be used to detect interoperability needs within or between 30 Ecosystems. Ecosystems by definition target user level interoperability between devices 31 within the Ecosystem, so one does not expect interoperability conflicts within an 32 Ecosystem. However: 33 • optional features of the intra Ecosystem standards often reduce user level 34 interoperability (sometimes down to co existence level) as devices may 35 implement different or even disjunct sets of optional features. These sets are 36 usually called profiles and are sometimes identified to users via sub logos.
1 Interoperability levels are not to be confused with OSI layers
28
1 • the need for new functions requires extending and changing of some intra 2 Ecosystem standards and thus may create interoperability issues (“backward 3 compatibility) with other, older standards within the Ecosystem. 4 draft5 Interoperability conflicts between Ecosystems are much more common. An Ecosystem 6 usually uses a “minimal” specification that only meets the technical and commercial 7 requirements of its target application(s). Interoperability with other Ecosystems is 8 typically not a requirement at the time the choices for an Ecosystem specification are 9 made. Interaction between devices from different Ecosystems thus often results in 10 interoperability conflicts, mostly on the higher IFRS levels, but sometimes also in co 11 existence. 12 13 Interoperability within or between Ecosystems typically concerns IFRS interoperability 14 levels 0 3. IFRS levels 4 6 are more applicable to the interaction between specific parts 15 of a service , typically concerning the configuration and management of the system, 16 which are examples of Service Building Blocks in the SHR taxonomy. Apart from 17 inter and intra Ecosystem interoperability use cases, we also distinguish a type of use 18 cases which we call “changing between service providers”. Changing to another Service 19 Provider can cause interoperability challenges between a service and a device in many 20 different ways, e.g. new provider uses a different protocol stack, or a new service needs 21 to reuse or share an existing Home Gateway (HG) to run a service specific stack. These 22 use cases are basically a special case of inter Ecosystem interoperability, but have a 23 more temporal character, and highlight the need for flexibility and reuse of resources. 24
29
1 4 Results draft2 4.1 Use cases 3 The following lists an overview of the 11 use cases we collected: 4 • Intra Ecosystem interactions 5 o A 1: multiple stand alone services (voice, TV, internet, PC) 6 o A 2: migrating to DLNA Ecosystem and Remote UI 7 o A 3: safety and security 8 o A 4: migrating to DLNA Ecosystem and Remote UI including content 9 format and protection issues 10 • Inter Ecosystem interactions 11 o B 1: Remote operation of embedded generators 12 o B 2: (Remote) Energy Management & Home Automation 13 o B 3: (Remote) heating control, intrusion alarm, home automation, 14 TV, voice and data communications 15 o B 4: (Remote) energy control, intrusion alarm, home automation, 16 TV, voice and data communications 17 • Changing Service Providers interactions 18 o C 1: changing AN Ecosystem 19 o C 2: open AN Ecosystem 20 o C 3: Changing network operator as well as metering provider 21 Details can be found in Annex A. 22 23 In use case C 3, we have split up the deployment view into views per relevant 24 dimension of our taxonomy. Splitting up as such makes deployment views easier to 25 understand, and helps with the construction of interoperability profiles.
26 4.2 Ecosystems
27 The long list of standards we collected is given in Annex C. The long list of 28 Ecosystems we derived from Annex C is given in Table 2. For ease of use only, we 29 sorted them according to domain, even though the assignment is often rather arbitrary. 30 31 An important remark to make is that the table is populated with Ecosystems rather than 32 single standards, even when the name of a single standard is used. For instance, TCP/IP 33 here means the whole TCP/IP Ecosystem (including also UDP, HTTP, IPv6, etc.). 34 35 Mostly it is obvious how an Ecosystem should be named and what standards belong to 36 it. But sometimes it is not. In those cases we have taken the freedom to name the 37 Ecosystem pragmatically and to group standards to an Ecosystem as we see the market 38 is using them. 39 40 The short list of Ecosystems, following from the use cases, is given below in Table 3. 41 The Ecosystems that appear in the use cases for Peripheral Networks are not mentioned 42 though, because they do not play a role in the interoperability profiles. 43 44 45
30
1 Table 2. Long list of Ecosystems for the SmartHouse. 2 Broadband Tele- Communications TCP/IP communications SIP draft Microsoft P&P Femtocell Apple P&P IMS Google Platforms DECT W3C ETSI HF PUCC Bluetooth G.hn ETSI TISPAN OSGi TR 069 Multimedia and ISO/IEC 15018 ITU T H610 Entertainment UPnP Wi Fi DLNA Ethernet DVB HGI IEC 62045 HomePNA MoCA HomePlug OpenIPTV IEC Home Server Home KNX ETSI NGN HAN management of EN 50173 appliances, Zigbee Energy LON comfort services, 6LowPAN managment HES safety&security IEC 61850 services and CIM OpenTherm health care IEC 61334 Insteon DLMS/COSEM Z wave M bus EN 61508 U SNAP EN 60335 Continua ISO 18012 1 EN 50523
Peripheral USB HDMI Networks UWB WHDI NFC Wireless HD RFID FireWire 3 4 Table 3. Short list of Ecosystems, following from the use cases 5 TCP/IP Zigbee TR 069 Microsoft P&P HomePlug Ethernet G.hn Open IPTV EN 50523 LON Wi Fi EN 50173 SIP UPnP U SNAP DECT OSGi Continua KNX IEC 61850 Bluetooth DLNA DLMS/COSEM HGI
6 4.3 Taxonomy
7 The taxonomy we found after multiple iterations with the use cases and the 8 interoperability profiles is given by only 2 dimensions: 9 1) protocol layer 10 2) generic service building block
31
1 2 Dimension 1) may be filled in with OSI layers. OSI layers are the well known 7 layers 3 as standardized by ISO [13]: 4 1. Physical (media, signal and binary transmission) draft5 2. Data Link (physical addressing 6 3. Network (path determination and logical addressing) 7 4. Transport (end to end connections and decryption) 8 5. Session (interhost communication) 9 6. Presentation (data representation, encryption) 10 7. Application (network process to application) 11 12 However, it is of crucial importance that the user of the taxonomy is given freedom on 13 the level of focus he wants to apply, depending on his use case. One could use the 7 14 OSI layers. But if one, for instance, is looking at a use case which only deals with 15 interoperating optical Ethernet (as used in the WAN nowadays) with in home Ethernet, 16 one really only needs to focus on the OSI layers 1 and 2, but also their sub layers (data 17 link, MAC layer, convergence layer, multiplexing, …). 18 19 For defining Dimension 2), the user of the taxonomy must unravel the service being 20 discussed in a particular use case into its basic application building blocks. This should 21 preferably be generic application building blocks. Similarly to Dimension 1) the user of 22 the taxonomy has freedom to choose his application building blocks regarding the focus 23 of his use case. Examples of such application building blocks are: 24 • bulk data transport (this means a generic application building block to shift a 25 large amount of data as quickly as possible from A to B, probably with medium 26 delay and low packet loss) 27 • delay sensitive control (this may be typical for gaming: not much data but with 28 low delay and medium reliability; but can easily extended to more “serious 29 gaming” applications, and maybe others) 30 • device and service discovery (not much data, but with some broad or multicast 31 properties, with low delay requirements, but high reliability) 32 • remote device and service management (session independent fault, 33 configuration and performance management of devices and applications; this 34 may include non ICT devices, and thus non ICT services) 35 • remote device and service control (session dependent real time reading and 36 writing of parameters from and to a device or an application, so that the device 37 or service now does what you want it to do; this typically includes signalling 38 and may include non ICT devices) 39 • network control (end to end (e2e) flow control, error handling, retransmission, 40 routing, load balancing, QoS control,….) 41 • network management (session independent fault, configuration and 42 performance management of lower OSI layers) 43 • service security (authentication, authorization, encryption, intruder detection, 44 digital rights management, …) 45 • remote user interfacing 46 • … 47 48 There is a strong relation here with the concept of Service Oriented Architectures or 49 SOAs [14].SOA is a flexible set of design principles used during the phases of systems 50 development and integration in computing. A system based on a Service Oriented 51 Architecture will provide a loosely coupled suite of service building blocks. The more
32
1 generic these service building blocks are, the more they can be used and reused within 2 multiple separate systems from several business domains. Said otherwise, if a service 3 architecture is designed in the first place according the design principles of SOA, the 4 chances are maximized that the system supporting that service contains various building draft5 blocks that can communicate with building blocks from other systems (for other 6 services, possibly in other domains) that are also designed according to these principles. 7 As such, the system exhibits a maximum capability to interoperate with other systems. 8 9 Obviously, not every service building block in a service architecture can be generic; 10 otherwise services would all be the same. However, a recent analysis of activities 11 performed (by people and/or machines) to provide a telecommunication service [15] 12 showed that a large majority (>80%) of these activities is not specific for that 13 telecommunication service. It can reasonably be assumed that analyses in other business 14 domains would yield similar numbers. Thus, the opportunities for interoperability 15 between and reuse of service building blocks are huge. 16 17 The SOA design principles are the following ([14], and others). “Service” here should 18 be seen as “generic service building block”. 19 • Standardized Service Contract – Services adhere to a communications 20 agreement, as defined collectively by one or more service description 21 documents. 22 • Service loose coupling – Services maintain a relationship that minimizes 23 dependencies and only requires that they maintain an awareness of each other. 24 • Service Abstraction – Beyond descriptions in the service contract, services hide 25 logic from the outside world. 26 • Service Reusability – Logic is divided into services with the intention of 27 promoting reuse. 28 • Service Autonomy – Services have control over the logic they encapsulate. 29 • Service Statelessness Services minimize resource consumption by deferring 30 the management of state information when necessary 31 • Service Discoverability – Services are supplemented with communicative meta 32 data by which they can be effectively discovered and interpreted. 33 • Service Composability – Services are effective composition 34 participants,regardless of the size and complexity of the composition. 35 • Service optimization – All else equal, high quality services are generally 36 preferable to low quality ones. 37 • Service relevance – Functionality is presented at a granularity recognized by 38 the user as a meaningful service. 39 • Service encapsulation – Many services are consolidated for use under the SOA. 40 Often such services were not planned to be under SOA. 41 42 Loose coupling and standardized service contract is in practice often realized by using 43 W3C Web Services as a communication protocol, and by standardizing the parameters 44 in the data bases that these protocols act on. Examples of the application of these 45 principles are the Ecosystems UPnP and TR 069. Other important principles for SHR 46 are Reusability (as explained before), Discoverability (one of the building block 47 identified above), Composability (that is what makes a building block a building block) 48 and Relevance. The latter has a relation to granularity, which will we discussed in the 49 next section. The principle of service composability is schematically drawn in Figure 6. 50 51
33
SBB draft Service Consumer SBB
SBB
SBB
Composite Service
1 2 Figure 6. Service composition in SOA. The Service Consumer accesses a service, which under the 3 hood is composed out of several generic Service Building Blocks (SBBs). Some SBBs may at the 4 same time be used for other services. 5 6 The whole of SOA is set up mainly for application in Enterprise IT architectures. 7 However, we think that the design principle are highly applicable to any system, 8 hardware or software, that requires high levels of interoperability with other, often still 9 unknown, systems. Unfortunately, most of the current systems are not designed as such, 10 partly because the principles of SOA are relatively new and not yet known to everyone, 11 partly because applying them to a specific system may compromise other requirements 12 to the architecture, such as total cost of material and performance (speed). 13 14 However, for designing interoperability profiles it is still useful to unravel any 15 communicating system into its generic Service Building Blocks, even if they are not 16 directly reflected in the architecture. The reason for that is that the functionality of a 17 not existing building block should still be present and provided by the system 18 somehow, even if it not loosely coupled, etc. Only then one can investigate where 19 interoperability (even only limited) with other systems can be achieved and how. A 20 system designed a priori according to the SOA principles does not require any 21 additional work to make the blocks interoperable: they are plug and play. Making two 22 systems interoperable that are not designed as such may require extra effort to do so, 23 such as designing an overarching protocol layer (overlay) or building an proxy/gateway 24 box interconnecting the systems for one or more specific functions. This will be 25 explained in the following sections. 26 27 “Reverse application” of the SOA principles to existing hardware and software 28 Ecosystems that are not created with SOA in mind is one of the main innovative 29 paradigms of our work described in this report. The other innovation is the allowance of 30 freedom in choosing the granularity of the dimensions in the taxonomy. If we would 31 determine the granularity here and now, the taxonomy would immediately become 32 useless for many use cases we cannot think right now. This is maybe the biggest error 33 made when designating the well known 7 OSI layers: it turned out that internetworking 34 desires more layers under layer 3, and less above layer 4. The OSI model is not flexible 35 enough to accommodate for these observations.
34
1 4.4 Interoperability Profiles
2 To construct an interoperability profile from a use case, the following algorithm should 3 be used: draft4 1. Unravel the use case into its generic service building blocks. Only define and 5 look at the building blocks that are interesting for your use case. It is important 6 to define them as generic as possible: this increases the chance on finding 7 interoperability opportunities or issues. 8 2. Analyze for every service building block the end to end communication paths 9 involved, and where Ecosystems are crossed in a given path. Here, making use 10 of the SHR Reference Model should help. 11 3. Now look for every single generic application building block separately 12 how information is communicated with respect to all protocol layers involved, 13 but only the protocol layers that are of interest given the use case. Thus write 14 down for every single generic application building block the complete protocol 15 stack used, but only for the layers of interest . Maybe one has to write down a 16 complete protocol stack from OSI layer 1 to 7 first before seeing where the 17 really interesting layer actually are. 18 4. One should also look at the granularity one chooses for the dissection of the 19 service into its generic components, and the granularity one chooses for the 20 protocol layers. A finer granularity means that if an opportunity for 21 interoperability is detected, it is probably a good one: there will be a very good 22 match between the functionality of protocols that end up in the same cell of the 23 interoperability profile. But a finer granularity also means that there may be 24 some overlap in functionality between various separated generic application 25 building blocks (e.g. remote device control and remote device management) 26 and between various protocol layers (e.g. link layer, network layer and 27 transport layer). One then may miss opportunities for interoperability by 28 plotting comparable protocols in different cells. Choosing a courser granularity 29 then helps, but also means that interoperability may be so so. For instance, 30 combining remote device and service management and control into a single 31 building block hints at interoperability between TR 069 and UPnP; which 32 indeed exists, but is not great. 33 5. One may consider underlining or color coding the Ecosystems that, if found in 34 the same cell in the interoperability profile, indeed need to interoperate, given 35 the use case. One could also indicate for which Ecosystems inter Ecosystem 36 interoperability already has been achieved by the industry or not. None of these 37 is done by the authors in the interoperability profiles below. 38 39 Interoperability profiles can be simply represented in 2 dimensional matrixes. For use 40 case C 3 the interoperability profile is shown in Table 4. 41 42 Table 4 . Interoperability Profile for the SmartHouse Roadmap use case C 3 43 C 3 Data Transport Device and Service Management Control OSI OpenIPTV, DLNA, OpenIPTV, OpenIPTV, TR 069, 5 7 LON DLNA/UPnP, LON UPnP, LON 44 45 Given the interoperability profile, we now can make the following analysis and 46 conclusions for use case C 3. The use case requires interoperability (of at least IFRS
35
1 level 3) on the session, presentation and application layers, for data transport, control as 2 well as management. Following the end to end paths, interoperability is not needed 3 between all Ecosystems in a single cell in the profile. For instance, the use case does not 4 demand interoperation between OpenIPTV and LON. Interoperability is needed draft5 between: 6 • OpenIPTV and TR 069 7 • OpenIPTV and DLNA 8 • UPnP and LON 9 • TR 069 and UPnP 10 Most of the interoperability is trivial, because the Ecosystems already arranged this: 11 • OpenIPTV manages standard with TR 069. 12 • OpenIPTV and DLNA have already defined an interworking function 13 Less obvious is the need interoperability between UPnP and LON. However, ISO/IEC 14 is already working to standardize interoperation between UPnP and LON (ISO/IEC JTC 15 1/SC 25 N 1795). Just as little obvious may be interoperability between UPnP and 16 TR 069. However, also here the responsible bodies Broadband Forum , UPnP Forum 17 and HGI are already working on this. 18 19 The interoperability profile of use case C 3 is fairly simple. Apparently the inventors of 20 the use case are only interested in interoperating the application layers 5 7 with not 21 much granularity. Only five Ecosystems play a relevant role there, for three different 22 building blocks of the service. Interoperating at level 5 7 means in practice the 23 application of a proxy/gateway between the LON system and the UPnP system, for 24 instance. One could also, in theory, have opted for interoperating LON and Ethernet at 25 level 3, by running the TCP/IP protocols on top of the OSI layers 1 2 of LON. LON 26 then would have become an undistinguishable part of the routed network. The 27 advantages of such an approach would have been an increase in scalability and a 28 cheaper gateway (router). Disadvantages are the uselessness of legacy LON devices in 29 such a network and the need for extra standards. 30 31 Table 5 shows the interoperability profile for use case A 1. The main cases for 32 interoperability in this use case are: 33 • Between DECT and VoIP on application level, or DECT and TCP/IP on 34 network level. 35 • Co existence on the physical layer between DECT, Bluetooth, and Wi Fi. 36 • On the application layer between Bluetooth and DVB MHP 37 38 DECT/IP interworking and DPRS (DECT Packet Radio Switching) have been part of 39 the DECT standard already for a long time, and have recently been updated specifically 40 for the support of operators’ VoIP services (Cat iq). Proprietary VoIP/DECT phones 41 have been on the market already for a while, and so are Skype/DECT phones. Further 42 standardisation is needed to align the various VoIP and peer to peer telephony solutions 43 currently on the market. 44 45 Co existence between DECT and 2.4 GHz systems like Bluetooth and Wi Fi is, in 46 Europe, trivial because DECT works on a different carrier frequency. Interference 47 between Bluetooth and Wi Fi is a well known phenomenon [16]. IEEE 802.15.2 48 provides a solution but is, as far as the authors know, not widely implemented. The new 49 Wi Fi standard IEEE 802.11n may provide a solution, because it can also operate on the 50 5 GHz band. 51
36
1 Any interoperating between DVB MHP and Bluetooth is unknown to the authors, so if 2 the demand for this use case from the market is high enough, this is an example of an 3 interoperability gap detected with our method. 4 draft5 Table 5 . Interoperability Profile for the SmartHouse Roadmap use case A 1 6 A 1 real time data streaming, Non real time data Security, Authentication, QoS, in band signalling transfer, connection Access Control control, network management, out of band signalling OSI DECT, G.711, TCP/IP DECT, Microsoft P&P, DECT, DVB (MHP), 5 7 (RTP, RTCP), Bluetooth DVB (MHP), SIP, Microsoft P&P, DVB, Bluetooth Bluetooth OSI DECT, TCP/IP, DECT, TCP/IP, 3 4 Bluetooth Microsoft P&P, Bluetooth OSI DECT, Ethernet, Wi Fi, DECT, Ethernet, Wi Fi, DECT, Ethernet, Wif Fi, 1 2 Bluetooth Bluetooth Bluetooth 7 A 1 Device and Service Discovery Remote Device Control, Device Management OSI DECT, TCP/IP (DNS), SIP, Microsoft DECT, Microsoft P&P, SIP, DVB 5 7 P&P, Bluetooth (MHP) OSI DECT, TCP/IP, Microsoft P&P, DECT, TCP/IP, Microsoft P&P 3 4 Bluetooth OSI DECT, Ethernet, Wi Fi, Bluetooth DECT, Ethernet, Wi Fi 1 2 8 9 The interoperability profile of use case A 1 shows that interoperability profiles can get 10 complex fairly quickly with more advanced use cases. It is therefore advised that such 11 use cases are subdivided in various more or less independent sub cases. 12 13 The interoperability profile for use case A 2 is shown in Table 6. Case A 2 is basically 14 the same as A 1, but John decided to throw his regular DECT phone, 3G phone, and 15 STB away, and replace them with DLNA certified equivalents. The 3G phone is then 16 replaced by a smart phone with Wi Fi instead of Bluetooth and DLNA. As a result, 17 Table 6 is much simpler than Table 5. The only interoperability issue in place seems to 18 the user interfacing between smart phones and other DLNA devices. 19 20 The interoperability profile for use case B 1 is shown in Table 7. Here the service 21 building blocks are seen to be too strongly coupled to distinguish different Ecosystems 22 for, resulting in a fairly simple profile. EN 50065 is not given in the long list nor the 23 short list. It is a specification for signalling on low voltage electrical installations in the 24 frequency range 3 kHz to 148.5 kHz. The protocol is also called Distributed Line 25 Carrier (DLC) and has a data rate up to 576 kbit/s. DLC is suitable (even in very large 26 networks) for multiple realtime energy management applications. It is mostly used on 27 the public electricity network for applications such as automated meter reading, and has 28 thus the same position in the SmartHouse as Access Network communication protocols 29 such as ADSL. We have therefore omitted it from our lists. 30
37
1 Table 6 . Interoperability Profile for the SmartHouse Roadmap use case A 2 2 A 2 Real time data Non real time data Security, Authentication, streaming, QoS, in band transfer, connection Access Control draft signalling control, network management, out of band signalling OSI DLNA DLNA DLNA, W3C 5 7 OSI DLNA DLNA DLNA 3 4 OSI DLNA DLNA DLNA 1 2 3 A 2 Device and Service Discovery Remote Device Control, Device Management OSI DLNA DLNA, W3C 5 7 OSI DLNA DLNA 3 4 OSI DLNA DLNA 1 2 4 5 Table 7. Interoperability Profile for the SmartHouse Roadmap use case B 1 6 B 1 Data and Control OSI EN 61850 7 OSI TCP/IP, Zigbee, KNX, EN 50065 3 4 OSI Wi Fi, KNX, Zigbee, EN 50065 1 2 7 8 However, some of the main interoperability issues in energy management lies between 9 EN 50065 and in home protocols such as KNX. The issue for any external party 10 accessing a HES network remotely is that they do not know beforehand which protocol 11 they are going to encounter. Whilst it is possible to build a bridge for any combination, 12 providing a general solution is not possible without some new approach to 13 interoperability. U SNAP provides a serial converter chip that is custom fitted for each 14 meter to link the remote and local networks. ESNA is promoting an approach based on 15 TCP/IP and W3C that would allow the meter bridge to self configure. 16 17 Another interoperability issue to be solved is the fact that ZigBee has not yet been 18 extended to support EN 61850 7 420 codes. 19 20 We did not produce interoperability profiles for every single use case. First of all 21 because creating a good and useful interoperability profile requires deep knowledge of 22 all Ecosystems involved. This is a skill which is not easily found within the limited 23 context of the project. Discussions quickly go to the bits and bytes level of every 24 Ecosystem involved. Furthermore, after having analysed the use cases A 1, A 2, B 1, 25 and C 3, we came to the conclusion that for the ultimate goal of the project, producing
38
1 the taxonomy and drafting recommendations for the EC, the ESOs, and the market, we 2 did not gain much more information anymore by analysing yet another use case. The 3 tables 5 7 thus only show interoperability profiles for use cases A 1, A 2, and B 1. draft4 4.5 Solution Space
5 4.5.1 Object modelling paradigms and interoperability 6 7 The SHR intends to give generic recommendations to integrate incompatible 8 Ecosystems instead of addressing the many specific interoperability challenges 9 identified by the SHR use cases. Therefore it is first needed to carefully analyze the 10 common causes for these interoperability issues. A generic object model of an 11 Ecosystem is shown in Figure 7.. 12
Controller Device D1 Controlled Device D i
Controller UI protocol A (OSI 1-7) Object a A i Object ai
Ecosystem A Service Building Blocks
13 14 Figure 7–generic object model of an Ecosystem 15 16 An Ecosystem models its Service Building Blocks in terms of objects and their external 17 behaviour (commands, responses, events) in order to interact with another device over a 18 network. These objects a i are implemented by one or more controlled devices D i and a 19 protocol is defined that allows a control application A on device D to control these 20 objects individually. The application logic in A integrates the Service Building Blocks 21 ai into an application and may optionally implement a User Interface to interact with a 22 human as part of this application. Furthermore there needs to be support in the 23 Ecosystem to find and identify objects a i in the network. IFRS [4] describes this as a 24 number of generic function steps in the lifetime of an object: discovery, binding, 25 operation and (run time) management 2. These steps are present in some form in all 26 Ecosystems. 27 28 From Figure 7 it can be seen why even a single Ecosystem may appear not 29 interoperable to end users. Within an Ecosystem A many different Service Building 30 Blocks (a 1, a 2, ..) may be defined, It then becomes impractical and too expensive for a 31 controller to control all these Service Building Blocks. Usually manufacturers therefore 32 ship their controlled devices with their own dedicated controller to ensure a user can 33 control their device. The result is a myriad of different control devices in users’ homes. 34 From an end user perspective not being able to share controllers to control multiple 35 devices across Ecosystems is one of the biggest roadblocks preventing interoperability. 36
2 These IFRS function steps can themselves be used in our taxonomy as Service Building Blocks to compare Ecosystems.
39
1 This issue only becomes worse if a controller needs to integrate Service Building 2 Blocks from Ecosystem A and B as depicted in Figure 8. 3 • B usually extends the variety of different objects b i that need to be controlled. 4 • If protocol A and B are different it is not possible for controller A or objects a i, draft5 to interact with objects b i directly and vice versa even if the objects model the 6 same Service Building Block. D now needs to support both the A and B 7 protocol. It also needs to implement and integrate the application logic of both 8 A and B and if needed create an integrated UI for them. This is not scalable: 9 when the number of Ecosystems grows this becomes impractical. 10 • The application logic of A and B has to be built in in D. When a user later 11 installs devices of Ecosystem C the same interoperability challenge occurs or D 12 has to be upgraded. 13 Controller Device D1 Controlled Device D2
Ecosystem A Service Building Blocks
Controller protocol A (OSI 1-7) Object a A 1 Object a 1
UI
Controller protocol B (OSI 1-7) Object b B 1 Object b 1
Ecosystem B Service Building Blocks
14 15 Figure 8 –integrating multiple Ecosystems 16 17 To enable the sharing of control devices you need to hide the differences between the 18 objects and their protocols within and across Ecosystems as much as possible. To what 19 extent this can be achieved depends on the applied object modelling paradigm that an 20 Ecosystem uses.
21 4.5.2 Object modelling paradigms 22 23 Three fundamentally different paradigms can be distinguished: 24 • Functional models. This is the most common model deployed by current 25 Ecosystems. Service Building Blocks are modelled as object command sets that 26 require (sometimes detailed) knowledge in the controller of the functionality of 27 the Service Building Block. Therefore the probability that different Ecosystems 28 model the same Service Building Block (e.g. a temperature sensor) different is 29 very high. Migration scenarios based on gateways that map command sets from 30 different Ecosystems are needed to accommodate differences between 31 Ecosystems. In this model it is possible for the controller to combine and 32 aggregate the functionality of multiple Service Building Blocks in its 33 application logic to the end user as a single more capable application 34
40
Controller Device D1 Controlled Device D2
Ecosystem A Service Building Blocks draft UI protocol A (OSI 1-7) UI Object a 1 Object a 1
UI protocol B (OSI 1-7) UI Object b 1 Object b 1
Ecosystem B Service Building Blocks
1 2 3 Figure 9 –integrating multiple Ecosystems 4 5 • Remote UI models. As can be seen from Figure 9, this model exports the 6 control UI of the object instead of the control commands to the controller. The 7 controller only needs to create and present a UI to the user from the UI 8 description it receives and send back the UI responses from the user via the 9 Remote UI protocol. In this model the controller does not need to be aware of 10 the functionality of the Service Building Blocks it controls. Even if objects 11 very much differ in their functionality there is usually a large commonality in 12 the UI via which these objects can be controlled by a human. It is therefore 13 much easier in this model to share a controller to control a large variety of 14 Service Building Blocks. Remote UI models can of course only be applied to 15 systems that have a human in the control loop. Furthermore it is not possible to 16 aggregate functionality of Service Building Blocks. This task is shifted to the 17 human behind the UI. This model requires a standard protocol to export UIs 18 that should work with the common control devices in the home such as PC, TV 19 and mobile phone. The best known example of a Remote UI protocol are web 20 pages stored in devices that are displayed by a browser on the PC or TV. 21 Migration between Ecosystems with different Remote UI protocols is difficult 22 and not very common. Furthermore it is not possible to aggregate functionality 23 of Service Building Blocks in this model without the controller needing 24 knowledge of the Service Building Blocks. This task is shifted to the human 25 behind the UI. 26 • Hosting models. In this model the controller acts as a host that uploads and 27 executes a control program from the controlled device that communicates with 28 and controls the object on the controlled device. It resembles the driver model 29 used e.g. for USB in the PC environment. The protocol between controller and 30 controlled device can be proprietary and does not need to be known by the 31 controller. This model requires a standard protocol to upload the command 32 pogram plus a standardized run time environment for the uploaded control 33 program including APIs to create a UI or to communicate with other programs 34 running on the controller. DVB MHP (based on Java VM) or browsers running 35 Javascript are good examples of this model. Furthermore it is not possible to 36 aggregate functionality of Service Building Blocks in this model without the
41
1 controller needing knowledge of the Service Building Blocks. This task is 2 shifted to the human behind the UI. Migration scenarios between Ecosystems 3 with different run time environments are not possible in this model. 4 draft5 Table 8 gives an overview of the different paradigms. 6 7 Table 8 –object modelling paradigms 8 Model Ease of Control Standardized Migration examples integration aggregation protocol Functional Low yes Command gateways KNX, sets UPnP, Zigbee Remote UI High no Remote UI no Bitmaps control browsers Hosting High no Hosting no OSGi control plus DVB run time HGI execution browsers environment 9 10 What particular modelling paradigm an Ecosystem uses is of course solely decided by 11 that Ecosystem. Most Ecosystems and interoperability challenges from the use cases are 12 based on the functional model and the use of command sets. Therefore migration 13 scenarios using gateways are a feasible way forward. The good thing about migration 14 scenarios is that they usually do not require any additional standardization. Every 15 Ecosystem or every device manufacturer can decide for himself, based on market needs, 16 when and for which Ecosystem protocols they want to add (optional) support to their 17 devices. 18
42
1 5 Summary and conclusions
2 Based on the analysis of the use cases and the face to face discussions with the project draft3 members in terms of interoperability issues, the state of the SmartHouse can be 4 summarized in the following way: 5 • interoperability within SmartHouse Ecosystems can be achieved or regarded as 6 already given (e.g. KNX, DLNA, ) 7 • interoperability among different Ecosystems is often still missing or is based on 8 proprietary solutions (interfaces, protocols…). In some cases the industry is 9 already working on this, but in other cases the market needs more stimulation. 10 • interoperability among different Ecosystems can be achieved the easiest by 11 customised gateways. Feasibility is a matter of cost and depends on available 12 information and interface specifications. When scalability becomes an issue, 13 the possibilities for deploying gateways become limited. Full migration to 14 TCP/IP for layers 3 and 4, and W3C for layers 5 7 should then be considered. 15 • The interest of Ecosystems in interoperability to other Ecosystems is limited. 16 The reasons are: 17 o short term commercial need for protection of system functionality 18 o fear for technical complexity and related reliability issues 19 o additional costs, because interoperability is yet another requirement 20 o the need to protect proprietary technology and a corresponding lead in 21 competition 22 o no authority over and/or knowledge of other ecosystems 23 24 We observe that the need for interoperability is mainly driven from the demands of the 25 end user, followed by the service provider (business that want to create applications that 26 exist across ecosystems) and the regulator. That does not inevitably mean that 27 technology providers see a market in it. Table 9 shows a collection of arguments we 28 have heard during the project that may drive or may hamper progress in interoperability 29 in the SmartHouse: 30 31 Table 9: Who is interested in Interoperability? 32 Who is interested in Industry; Vendors Service Provider End User; Builder interoperability Why is there an To increase the To be able to offer To integrate, interest in market and to be new services and expand and use interoperability able to offer added advanced service new services and value to systems and models to a large functions in a smart products number of home subscriber Why parties are not Protection of market Protect services in Concern about interested in segments (e.g. main competition privacy and interoperability power socket in EU) dependencies High implementation Cost High complexity Reliability Issues 33
43
1 The use cases we gathered are all very realistic and show the future need for 2 interoperability and convergence from an end user point of view. Realizing 3 interoperability wherever end users need it is the main way forward for the 4 SmartHouse. draft5 6 We developed a tool with which engineers and policy makers can iterate from a use 7 case to a technical architecture and implementation that fully exploit any opportunities 8 for interoperability. The tool consists of: 9 • A uniform template and reference model for plotting the use case 10 • A long list of relevant SmartHouse Ecosystems and corresponding standards to 11 choose from, for implementing the use case 12 • A taxonomy and algorithm to create interoperability profiles, and to analyze the 13 interoperability issues and opportunities of the Ecosystems and standards 14 chosen 15 • A solution space with recommendations to create interoperability where 16 desired 17 18 The SHR Taxonomy of relevant ecosystems and standards is recommended as the 19 foundation and direction for the Roadmap transition process, towards the identified 20 interoperability levels. The development of the SHR Taxonomy started off with more 21 than 6000 standards, classifying them, selecting the relevant ones and selecting the ones 22 that play an explicit role in the SHR Use Case. Selection criteria were the documented 23 relevance of standards in the market, the maturity of the standard (no drafts), the 24 relevance to interoperability and convergence of SmartHouse specific applications, and 25 the European uniformity of the technology. As such, the Project Team reduced the 26 grand amount of 6000+ SmartHouse related standards in existence to a long list of 27 about 200 standards that are now relevant for the Roadmap, grouped into 59 28 Ecosystems. From this a short list of 24 Ecosystems is constructed, which are the ones 29 that appear in the use cases. The SHR short list of relevant standards should be seen as 30 important reference for the SmartHouse transition. 31 32 We further conclude that a taxonomy for interoperability in the SmartHouse contains 33 only 2 dimensions (generic Service Building Block and protocol layer), and that it 34 complements the CWA IFRS in the sense that we provide the bricks and mortar to reach 35 higher interoperability levels and as such a smarter SmartHouse. The taxonomy is based 36 on two innovative paradigms. First, we use “reverse application” of the SOA principles 37 to existing hardware and software of Ecosystems that werenot created with SOA in 38 mind. Second, we allow freedom in choosing the granularity of the dimensions in the 39 taxonomy. If we would determine the granularity here and now, the taxonomy would 40 immediately become useless for many use cases we cannot think right now. 41 42 From analyzing the 11 use case we collected with the tools we developed, we were not 43 only able to improve our methods in an iterative way, but also to extract generic 44 observations about interoperability in the SmartHouse, and from that deduce 45 recommendations to the EC, the ESOs and the market place. These recommendations 46 are listed in the following chapter. 47
44
1 6 Recommendations
2 In this section we focus on recommendations for the European Committee (EC) and the draft3 European Standards Organisations (ESOs) on how to support the EU citizen to fulfill 4 his need for convergence. We recall the definition of an Ecosystem: a group of 5 interacting components that collectively perform the function of a standard. An 6 Ecosystem, for instance, consists of the base standard of a protocol, but also test 7 specifications, installation guidelines, safety requirements, certification programs, etc.
8 6.1 Application Layer
9 6.1.1 Discovery and sharing 10 11 R1. For any new service or device intended to be able to discover services/capabilities 12 provided by other devices in other Ecosystems, a standardized discovery 13 protocol between Ecosystems should be used. A conceptual framework like 14 being used by DLNA offers a good starting point for this: it must be advocated 15 to other Ecosystems including discovery functionality. 16 17 R2. Standardization should not only happen for discovery but also for the actual 18 sharing of digital resources, thus limiting the proliferation of devices and 19 network technologies in the home. Sharing becomes possible when proper 20 standards for configuration (binding), operation (control) and management are 21 in place. A conceptual framework like that being used by DLNA offers a good 22 starting point for this, and must be advocated to other Ecosystems. 23 24 R3. It is recommended that implemented interoperability frameworks, containing 25 standardized technologies for discovery, configuration, operation (sharing, 26 control, etc), and management, are actually switched “on” by factory default 27 and can be switched “off” by the user via an easily accessible and 28 understandable user interface. However, the framework should only be 29 switched “on” if adequate precautions are taken to protect the functionality of 30 applications which have critical requirements, such as fire, burglar, social and 31 medical alarm systems.
32 6.1.2 Security, privacy, reliability, QoS 33 34 R4. Proper and well accepted standards for robustness (QoS, reliability, …) and 35 security (encryption, authorization, …) in the SmartHouse need to be 36 developed. They should protect the functionality of critical applications when 37 they are integrated with other systems. Common definitions are required that 38 allow different Ecosystems to specify their network performance requirements. 39 This must be a broad cross industry effort, and therefore will be a complicated 40 venture needing strong coordination. For security we recommend to follow the 41 W3C approach and protocols as much as possible.
42 6.1.3 Convergence of control points for configuration, operation and management of 43 devices, networks and applications. 44 45 R5. New devices and applications must be required to expose their user interface in an 46 application independent standardized way for at least four generic types of
45
1 devices in the home with a human input/output function for remote control: the 2 (smart) mobile phone, the PC/laptop, touch screen panels, and in home 3 displays. A likely option for exporting and controlling such user interfaces 4 would be browser based solutions. These solutions must be properly 5 standardized, which includes an architecture, a protocol as well as Common draft6 Information Models. Existing Ecosystems such as W3C and DLNA, provide a 7 good starting point, and should be used wherever possible, but also need to be 8 extended and harmonized across device types.
9 6.2 Communication layers
10 6.2.1 Home Gateways 11 12 R6. Standardization of Home Gateway functionality must be stimulated. At the 13 moment, such standardization is distributed over various organizations, such as 14 HGI, Broadband Forum, CableLabs, and the various smart metering and home 15 electronics working groups in ITU, ISO/IEC and CEN/CENELEC. These 16 initiatives need to be coordinated.
17 6.2.2 IP, subnetting, routers, bridges 18 19 R7. For any new service or device intended to be able to communicate with devices in 20 other Ecosystems, a standardized network layer communication protocol 21 between Ecosystems should be used. The only apparent option for such a 22 protocol is IP. The use of IP as the network layer (OSI layer 3) protocol of 23 choice must be stimulated, and then preferably version 6 of it, i.e. IPv6. 24 25 R8. If support of the IP protocol (by implementing a TCP/IP protocol stack) is not yet 26 feasible because of techno economic reasons, the developers and maintainers 27 of non IP based Ecosystems must be stimulated to define and standardize an IP 28 gateway as well as a migration strategy to scalable all IP architecture in the 29 future.
30 6.3 Home Infrastructure
31 R9. Proper network infrastructure standards should be developed for back bone 32 network infrastructures in the SmartHouse. The field covered by these new 33 standards and their quality should be such that they can be referred to in future 34 regulations for new houses to be built. It should also be possible to implement 35 and deploy these new standards relatively easily, in houses to be built as well 36 as in houses to be retrofitted. For back bone infrastructures in existing lived in 37 homes, the use of existing wiring (power line, coax, phone line, etc., i.e. the so 38 called no new wires approach) may instead be considered.
39 6.4 Compliance
40 R10. Our taxonomy should be used as a reference guide to support the SmartHouse 41 Roadmap to any new SmartHouse European standardization effort. In order to 42 stimulate this, the EC might consider initiating a procedure to certify new and 43 existing standards whether and how far they fulfil a set of SmartHouse 44 interoperability encouraging requirements/guidelines to be developed. This 45 may take the form of a “SmartHouse Ready” program. Theses 46 requirements/guidelines are recommended to follow the CWA IFRS
46
1 classification of interoperability, and decide on a per Ecosystem basis which 2 level of interoperability should be achieved for what functions. The 3 requirements and guidelines thus form an industry “SmartHouse Code of 4 Conduct (CoC)” for reaching interoperability as desired by the user. 5 draft6 R11. Current European standardization activities in the field of SmartHouse 7 technologies need to be coordinated with a future Coordination Action (CA). 8 The CA should have the goal to develop a well accepted European SmartHouse 9 CoC, based on the deliverables of the SmartHouse Roadmap project, and 10 specify a “SmartHouse Ready Domain” to be added into the EC 2011 2014 11 ICT Standardisation Work Programme. This SmartHouse CA should provide a 12 well coordinated and high quality aligned collaboration with the identified 13 relevant ESOs, consortia and fora, and with ISO/IEC JTC 1 SC25 in particular. 14 15
47
1 References
2 [1] CENELEC Workshop Agreement “CWA 50487 SmartHouse Code of Practice”, draft3 CLC/TR 50487:2005, November 2005. 4 [2] European Commission, “2008 ICT Standardisation Work Programma”, Version 5 2.0, March 2008. 6 [3] Geerten van de Kaa, “Standards Battles for Complex Systems: Empirical Research 7 on the Home Network”, Doctoral Thesis, ISBN 978 90 5892 205 2, May 2009. 8 [4] CENELEC Workshop Agreement “CWA 50560 IFRS An Interoperability 9 Framework Requirements Specification for the Smart Home,” CLC/TR 10 50560:2010, May 2010. 11 [5] European Commission DG INFSO Project SMART 2008/0049, “Towards a Future 12 Internet: Interrelation between Technological, Social and Economic Trends”, 13 Interim Report, February 2010 14 [6] N. Baken, E. van Boven, and R. Reitsma, “Broadband Infrastructures and Services 15 Trans sector thinking, the difference between A Beneficial Sector or Tower of 16 Babel”, Journal of The Communications Network, 2003 (2) pp. 94 98. 17 [7] P. Budde, “Australia National Broadband Network Design and Deployment 18 Strategies”,“http://www.budde.com.au/Research/Australia National Broadband 19 Network Design and Deployment Strategies.html 20 [8] Aldona Jarašūnien÷, Gražvydas Jakubauskas, “Improvement of Road Safety using 21 Passive and Active Intelligent Vehicle Safety Systems”, TRANSPORT – 2007, 22 Vol XXII, No 4, pp. 284–289. 23 [9] “Home Gateway Technical Requirements: Residential Profile V1.01”, HGI 24 RD001 R2.01 (2008) 25 [10] “Minimum set of functions for metering of electricity, gas and thermal energy for 26 domestic customers”, NEC Netherlands Technical Agreement NTA 8130 (e) 27 (2007) 28 [11] “Recommended Practice for Architecture Description of Software Intensive 29 Systems”, ANSI/IEEE 1471 2000, as well as “Systems and Software Engineering 30 – Recommended practice for architectural description of software intensive 31 systems”, ISO/IEC 42010:2007. 32 [12] ISO/IEC TR 29107 1:2010, “Information technology Intelligent homes 33 Taxonomy of specifications Part 1: The scheme”. 34 [13] ISO/IEC 7498 1:1994, “Information Technology – Open Systems Interconnection 35 – Basic Reference Model: The Basic Model. 36 [14] Thomas Erl, “Service Oriented Architecture: Concepts, Technology, and Design”, 37 Prentice Hall, ISBN:0131858580, 2005. 38 [15] Carolyn Simmonds Zúňiga, Telecom sector modeling from a functional 39 perspective”, Master of Science Thesis, http://repository.tudelft.nl/assets/ 40 uuid:99c0a51d 653d 4977 b605 41 e32913580eb7/MSc_Thesis_CSimmonds_final.pdf , July 2009. 42 [16] N. Golmie, R.E. van Dyck, A. Soltanian, A. Tonnerre, and O. Rébala, 43 “Interference Evaluation of Bluetooth and IEEE 802.11b Systems”, Wireless 44 Networks 9, pp. 201–211, 2003. 45 46
48
A 1 Use Cases
A.1 2 Template draft 3 Slide 1:
4 5 6 Slide 2:
7 8 9 Slide 3:
10 11 12
49
1 Slide 4:
draft
2 3 4 Slide 5:
5
50
1 A.2 2 Intra-Ecosystem use cases
A.2.1 3 Use Case A-1:Intra-Ecosystem: multiple stand-alone services (voice, TV, internet, PC) draft4 Type intra-Ecosystem Use case Nr/Title A-1: co-existing multimedia services (voice, TV, internet, PC) Services used TV, voice, internet, Windows PC home networking AN Ecosystems used DVB, ADSL, 3G HN Ecpsystems used TCP/IP, Ethernet, Wi-Fi, DVB, DECT, Bluetooth, Microsoft P&P
Assumptions: (Required) John has subscriptions to an ADSL service for voice and data. John owns several DECT phones connected to the DECT base station function in the home gateway that he leases for free from the ADSL network operator. Jon uses a 3rd party independent ISP for internet access over his ADSL connection. John uses a 3G service for voice and internet from a mobile service provider.that operates its own 3G network John has a digital TV service subscription from a satellite operator. It includes a basic set of free broadcast services plus a pay-TV sports channel with advanced interactive services using DVB-MHP John has several TVs in his home. He leases a STB from his TV service provider connected to the living room TV to watch the pay-TV service. On the other TV s he can only watch the free TV services. John has several PCs in different rooms, a laptop from work, a NAS and a network printer, all hooked up via Wi-Fi and Ethernet using the Microsoft 5 Windows PC networking protocol suite.(Microsoft Protocols & Platforms). 6
Type intra-Ecosystem Use case Nr/Title A-1: co-existing multimedia services (voice, TV, internet, PC)
User Experience (Required)
7 8
51
Type intra-Ecosystem Use case Nr/Title A-1: co-existing multimedia services (voice, TV, internet, PC)
Schematic Illustration (Required)
TV Service AN SP/NP HN/ Retail PN draft Providers Ecosystems devices Ecosystems devices Ecosystems
DVB ADSL 3G DECT 802.3, Wi-Fi NP NP NP Analog TV NT Analog TV over coax HDMI
Web STB DVB-MHP TCP/IP, Internet,, VoIP DVB-S BBF PC
ISP Global backbone W-PC Netw HG BT TV TCP/IP TV Bcst NAS 3G W-PC Netw
John’s printer Phone W-PC Netw Voice “POTS”
Mobile
DECT 1 phone 2
Type intra-Ecosystem Use case Nr/Title A-1: co-existing multimedia services (voice, TV, internet, PC)
Implementation Examples (Optional)
52
Type intra-Ecosystem Use case Nr/Title A-1: co-existing multimedia services (voice, TV, internet, PC)
Additional Data (Optional): Other information that may help explain or constrain
the scenario.> draft The voice service uses 3 ecosystems (DECT, 3G and VoIP) but there is no interoperability between them e.g. to relay calls. The STB uses the TCP/IP network as return channel for the DVB-MHP service but there is no interoperability between the STB and the other TV or the PCs or the DECT phones to watch the pay-TV services or to listen to the radio. The Ethernet and Wi-Fi ecosystems carry three other ecosystems:: the Microsoft P&P Networking (file/priner sharing between PCs), internet and VoIP. This use case shows interoperability between a service (TV, DECT, mobile phone, VoIP, internet) and its corresponding device in the home (STB, DECT phone, , mobile phone, PC).. The PC home networking ecosytem is the only example of an in-home service where a device provides services to other devices in the home (printing, storage). The PC is connected to three ecosystems (internet, VoIP, Microsoft P&P networking) and could act as a gateway to achieve interoperability between devices in these ecosystems. The Home Gateway could do the same for the DECT and VoiP ecosystems. To do this the differences as shown in the interoperability profile belong to this case need to be solved either via a gateway 1 function or by migrating to one common protocol as shown in use case A2. 2 3 A.2.2 4 Use case A-2: Intra-Ecosystem: migrating to DLNA Ecosystem and Remote UI 5
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI
Services used TV, voice, internet, Windows PC home networking AN Ecosystems used DVB, ADSL, 3G HN Ecpsystems used Same as in A1, but now including DLNA Assumptions: See A-1 John living room TV, PC, NAS, printer and 3G phone are now DLNA compliant Peter’s phone and John’s TV both support DLNA link protection to prevent spoofing. 6 7
53
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI User Experience (Required)
1 2
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI User Experience (Required)
3
54
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI
Schematic Illustration (Required)
TV Service AN SP/NP HN Retail PN draft Providers Providers devices Ecosystems devices Ecosystems
802.3, Wi-Fi DVB ADSL 3G NP NP NP TV NT Analog TV 3GPP over coax IrDA
BBF DLNA Web DVB-S HDMI STB DVB-MHP TV-RC Global Backbone TCP/IP, Internet, ISP PC
DLNA TV HG TCP/IP, internet TV Bcst DLNA DLNA NAS Voice John’s DLNA “POTS” Phone printer DLNA Mobile DLNA
Peter’s 1 Phone 2
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI
Implementation Examples (Optional)
55
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI
Additional Data (Optional) scenario.> draft In this migration scenario most of the devices of use case A-1 are replaced by or upgraded to ones that support DLNA. Otherwise separate “DLNA gateway or proxy devices” are needed that represent or proxy non-DLNA devices in a DLNA compliant manner The advantage of a RUI protocol is that the display device does not need to know anything about the application it is controlling. If John would use a different mobile phone he would have automatically access to all the specific calendar features of that new phone without having to change anything in his TV, provided that they use the same RUI protocol. The disadvantage of a RUI protocol is that it is not possible for the display device to perform a sequence of actions involving multiple devices. There are two RUI protocols in this use case. One between the mobile phone browser and the HTTP server in the HG and one between the DLNA browser on the TV and the HTTP server in the mobile phone using the DLNA RUI browser (based on CEA-2014 a.k.a CE- HTML. CEA-2014 does support HTTP streaming of stored AV media but HTTP may cause problems for a real-time voice stream being pushed to the TV. This use case uses only two HN ecosystems: the “internet” (between HG and PC) and DLNA (between all other device combinations) for two independent usages. Nevertheless this use case does describe an interoperability gap inside DLNA wrt authentication and streaming of real-time voice stream. 1 2 A.2.3 3 Use Case A-3: Intra-Ecosystem: Safety and Security 4 Type Intra Ecosystem Use case Nr/Title A 3 Safety & Security Services used Broadband Internet, Fixed Line Telephone, GSM, LAN AN Ecosystems used VDSL; HN Ecosystems Used EN 50173, Ethernet, Wi Fi, TCP/IP, Bluetooth, DECT, W3C, OSGi Assumptions: John’s father, Max, is a bed bound invalid and lives in a separate room in John’s house. A nurse is carrying for him during the day. When the nurse arrives, Max needs to opens the front door if the nurse has no key. The video stream of the surveillance camera at the front door can be viewed at the TV set in the room of Max. The front door can be opened remotely. There are separate electronic keys for the family and the nurse. 5 Type Intra Ecosystem Use case Nr/Title A 3 Safety & Security User Experience John activates/deactivates the control unit with the handheld bluetooth transmitter. In case of an alarm event the central station deactivates the alarm either on receiving the alarm password or John deactivates it using the handheld bluetooth transmitter. In case of an alarm the central station notifies police or fire department if not receiving the alarm password within 3 minutes. In case of an alarm the control unit activates the sirene, the IP cameras and send the 56 alarm event (security breach, fire alarm) to the central station using the fixed telephone line. If the motion sensor in the outside entrance area detects a motion the IP camera is switched on and the content is streamed to the display in the entrance area. draft Since the family has a dog the IP cameras are only switched on, if the pet motion sensor was not activated. Magda activates the outside entrance IP camera on pressing the view button on the display and the content is streamed to and displayed at the door bell equipment screen. John activates an IP camera on entering the address of the IP camera in the W3C browser, pressing the view button on the web page and the content can be viewed at the PC display. On pressing the save button the content is stored in parallel locally on the disk. John configures the control unit that in case of motion detected the video streams shall be recorded and stored on a NAS drive share. If the nurse enters the house with her key a ringing ton with image appears on the TV. In case the nurse rings at the front door, a view pops up at Max’s TV set and the content is streamed to that view by the surveillance camera. Additionally an open button appears on the screen. Max opens the front door by pressing the open button on the screen with his remote control. 1 3 2 3 Type Intra Ecosystem Use case Nr/Title A 3 Safety & Security Implementation Examples In the current scenario no home gateway prepared for multi service integration is available. The access Modem is owned by the ISP. The IP based Applications in the Home Network are using the Ethernet based home 57 network backbone (Plastic Optical Fiber or Copper Cat5) infrastructure in combination with Wi Fi network clusters. The internet service is based on the W3C and TCP/IP standards and uses the AN service from other providers. The HN for the internet service is based on the Wi Fi, draft Ethernet, and TCP/IP standards. The access network service for the fixed line service is based on VDSL. The communication with the IP Cameras for activating, viewing and saving content is based on W3C Webservices The control unit implements a service platform based on the OSGi standard to integrate IP cameras, motion sensors, smoke detectors of different suppliers. The support of such devices will be updated periodically by the control unit by downloading and installing device bundles from the central unit. 1 2 3 58 draft 1 2 A.2.4 3 Use Case A-4:Intra-Ecosystem: migrating to DLNA Ecosystem and Remote UI 4 including content format and –protection issues 5 Type Intra Ecosystem Use case Nr/Title A 4: migrating to DLNA Ecosystem and Remote UI incl content format and copyright issues Services used In home PC, internet, mobile phone AN Ecosystems used DVB, 3G, ADSL, HN Ecosystems Used The same as in A1, plus DLNA. Assumptions: See A 1 John living room TV, PC, NAS, printer and 3G phone are now DLNA compliant using IP/802 HN Ecosystem 6 Type Intra Ecosystem Use case Nr/Title A 4: migrating to DLNA Ecosystem and Remote UI incl content format and copyright issues User Experience John switches on the TV after a day at the office and docks his 3G phone to recharge the batteries a small widget appears at the bottom of the TV screen indicating that several MSN video calls and e mails and tweets were received on his PC while he was away. He uses his TV Remote Control (RC) to browse through them. His TV only renders the audio of the MSN video calls while displaying “unsupported video format”. He then watches the news on TV Suddenly an icon appears showing there is an 59 incoming call on his 3G phone from his friend Peter. He takes the call on the TV Peter asks if he can come over the next day to show the pictures from the weekend they spent together. Peter uses the RC of the TV to browse and set the appointment in the calendar in his 3G phone. draft The next day Peter stops by. John configures the HG via the PC to grant Peters phone holding the pictures “guest access” to his HN allowing him only to render content on John’s DLNA rendering devices. Peter uses his mobile phone and John the remote of the TV to browse together through the pictures on the TV. Peter also renders some protected art pictures on his phone and uploads them to John’s NAS. Later when John tries to render them on his TV he gets an error saying the TV does not have the proper licenses for that. John uses the remote of the TV to copy several of the pictures from Peter’s phone to his NAS. He prints one of them on his printer after Peter allows this on his phone. 1 2 4 3 4 Type Intra Ecosystem Use case Nr/Title A 4: migrating to DLNA Ecosystem and Remote UI incl content format and copyright issues Implementation Examples John uses the browser on the PC to remotely display the UI of the HG to allow Peters phone access to his Wi Fi network. The TV uses the DLNA Remote UI protocol to display the received e mails and tweets from the PC and the received calls from the DECT Base Station Voice Recorder in the HG and to control the calendar of his 3G phone. Peter’s mobile phone controls the TV though DLNA commands over Wi Fi to show the pictures John’s TV controls Peter’s phone, the NAS and the printer though DLNA 60 commands to copy the pictures to his NAS and to print them. The access control restrictions in the use case require some form of (secure) authentication. This is currently not provided by DLNA. Peter’s phone and John’s TV both support DLNA link protection to prevent draft spoofing. 1 Type Intra Ecosystem Use case Nr/Title A 4: migrating to DLNA Ecosystem and Remote UI incl content format and copyright issues Additional Data In this migration scenario some of the devices of use case A 1 are replaced by or upgraded to DLNA. Otherwise separate “DLNA adapter devices” are needed. The devices, services and HN Ecosystems from A 1 that are not upgraded to DLNA are still present but are not drawn anymore in the diagram for clarity reasons. The advantage of a RUI protocol is that the display device does not need to know anything about the application it is controlling. If John would use a different mobile phone he would have automatically access to all the specific calendar features of that new phone without having to change anything in his TV, provided that they use the same RUI protocol. The disadvantage of a RUI protocol is that it is more difficult to perform coordinated sequence of actions involving multiple devices. There are two RUI protocols in this use case. One between the PC browser (e.g. IE8) and the HTTP server in the HG and one between the DLNA browser on the TV and the HTTP server in the mobile phone using the DLNA RUI browser . Note that all DLNA services use the TCP/IP and Wi Fi Ecosystems and share it with the W3C based internet services. Note that DECT phones cannot be used in this use case as the DECT and DLNA Ecosystem are incompatible. This could be resolved if the HG (not shown) would implement a gateway function. Rendering the protected pictures from Peter’s phone on John’s TV is possible if both support e.g. DLNA link protection to prevent spoofing. Uploading it on John’s NAS is also possible but John can only render it from his NAS if he has a proper license that can be verified by the copyright owner independent from the Digital Rights Management system that John’s devices use and that the copyright owner used when releasing the content. 2 61 1 A.3 2 Inter-Ecosystem convergence use cases A.3.1 3 Use-case B-1: Inter-Ecosystem Convergence: Remote operation of embedded draft4 generators 5 Type Inter-Ecosystem Convergence Use case Nr/Title B-1: Remote operation of embedded generators The external and in-home services that the user uses e.g,. Services used 2.5/3G, smart metering, home automation, internet AN Ecosystems used 2.5/3G, DLMS, EN 50065 (DLC) IEC 61850, U-SNAP, KNX, DLMS/COSEM, Zigbee, EN 50523, HN Ecosystems used DLNA, TCP/IP, W3C, Wi-Fi Assumptions: (Required) Type Inter-Ecosystem Convergence Use case Nr/Title B-1: Remote operation of embedded generators User Experience (Required) 8 9 62 B-1: Remote operation of embedded generators draft 1 2 Type Inter-Ecosystem Convergence Use case Nr/Title B-1: Remote operation of embedded generators Implementation Examples (Optional) 63 Services used Energy Management, internet, mobile phone AN Ecosystems used 2.5G, Power Grid HN Ecosystems Used KNX, LON, G.hn, ZigBee, DLNA, TCP/IP, Ethernet, Wi Fi draft Assumptions: John has agreed a contract with his energy utility service provider (USP) to accept remote adjustment of appliances in the home for the purpose of managing system loads. The USP has provided an energy monitor where the details of the current tariff can be viewed and decisions made on whether to accept or override control signals. It connects to the smart meter using U SNAP peripheral network. The USP will send a control signal via the smart meter to any devices in the customer’s home that are subject to energy usage control. It expects to see a desired response in the load. The USP and Mobile SP have a secure web interface that can be accessed over the internet. John’s mobile phone charger and whitegood appliances have a KNX/G.hn powerline interface John also has a controllable lighting system with sensors and actuators using ZigBee John also has a controllable HVAC system with sensors and actuators using LON over IP/G.hn). The PC and TV have a DLNA interface over TCP/IP over Ethernet or Wi Fi The PC also has a W3C/IETF internet interface over TCP/IP over Ethernet or Wi Fi 1 Type Inter Ecosystem Convergence Use case Nr/Title B 2: (Remote) Energy Management & Home Automation User Experience John switches on his energy controlled washing machine to a white wash program but an indicator on the washing machine shows that the amount of energy would exceed the cheap energy tariff limit of his house as agreed in his contract with the utility company. The machine suggests a scheduled time for later that evening. John acknowledges the suggested time. Then he goes over to his friend Peter for dinner and locks the house in low energy mode. During dinner he gets an SMS message on his mobile phone reporting someone has unlocked the low power mode. Through the browser on his phone John logs into the USP. After typing in his security code he looks at the log file and sees the name of his son as the person who unlocked the low energy mode. After dinner John goes home and puts his mobile phone in the recharger. He looks at the energy display to view the current energy consumption of his home. He sees the washing machine is now running and that his mobile is doing a power charge. He changes it to a slow charging mode to improve battery life. At night, lying in bed he wonders whether he has switched off the lights and the TV in the living room and has programmed the thermostat for the bathroom for next morning. He wished he could use the bedroom TV to check and control all his home automation equipment in the home including the energy management operations from his USP 64 1 draft 2 3 Type Inter Ecosystem Convergence Use case Nr/Title B 2: (Remote) Energy Management & Home Automation Implementation Examples John’s USP sends SMS messages via the web interface from its mobile provider, typically a different mobile provider then the one from John. John’s mobile phone can access the web interface of his utility provider USP to read and control his subscriber account and execute certain actions The link from USP to Smart Meter is secure and proprietary and uses the power grid of the USP who also owns the Smart Meter. 4 Type Inter Ecosystem Convergence Use case Nr/Title B 2: (Remote) Energy Management & Home Automation Additional Data There are four different HN Ecosystems involved here that are not interoperable on user level : DLNA, ZigBee, LON and KNX. Note that this use case assumes KNX and LON share the G.hn HN Ecosystems. In reality they may use different powerline technologies The PC in home service using DLNA or the internet service using W3C is not used in this use case. The smart meter does not offer a Remote UI to let other devices control it or read out power usage data This use case does not add interfaces to devices to solve HN Ecosystem interoperability but on a high level shows interoperability roadblocks between these HN Ecosystem. The security aspect plays an important role in this use case and helps to set the security requirements for the interoperability solution between the Ecosystems. The USP expects to be able to send his control signals without making 65 consideration of the details of the network and protocols in the customer’s home. Differences if there is a direct message or if the presence of a coordinator (Energy Box) manages the loads planning. Fundamental the role of appliances in managing the signals. The customer can always override the commands. draft The customer expects the USP system to operate within it’s contracted terms and to have control over it (the ability to override any control signal (depending on the contract between the customer and the utility) using a specific interface or some other control interface within the home). 1 2 A.3.3 3 Use case B-3: Inter-Ecosystem Convergence: (Remote) heating control, intrusion 4 alarm, home automation, TV, voice and data communications 5 6 Type Inter Ecosystem Convergence Use case Nr/Title B 3: (Remote) heating control, intrusion alarm & home automation TV, voice and data communications Appl. Services used Remote power switching, POT, Internet, security service, HVAC service, remote home control AN Ecosystems used Power grid; POTS telephony, Satellite TV, Broadband Internet HN Ecosystems used KNX, TCP/IP, Ethernet, EN 50173 Assumptions: John is not permanently in his house, that he wants to be attended also in his absence and wants it to be warm when he returns from a travel, that he uses as home office if present. John has contracts with the HVAC installer and a security service to look after his house and react on messages from the home control system. John is connected to the telephony services provided by the Telecom that also provides the Internet access. John has joined in a contract with his energy utility service provider (USP) to accept remote opening/blocking the power for rain pipe heating for his and his neighbours’ house. John shares a satellite dish with his neighbours. John has a Home Automation Network (HAN) using KNX specifications. John has equipped his windows with opening contacts and glass with built in integrity circuits, his radiators with electric valves, rooms with KNX temperature sensor/control and KNX switches, connected many lights to KNX actuators, connected the dishwasher to the power via a KNX actuator, the control unit of the heat source as well as the KNX network to the Telecontrol, the path to his neighbours with a KNX moving detector and the lighting for this path with an KNX actuator. A PBX connects the phones in the different rooms to the POTS. The wall outlets for PCs in the rooms are connected to the Internet modem/router with help of category 7 cables (EN 50173), Ethernet and TCP/IP The wall outlet for TVs are connected by a coaxial cables with a distributor for TV signal. 7 66 1 Type Inter Ecosystem Convergence Use case Nr/Title B 3: (Remote) heating control, intrusion alarm & home automation draft User Experience The utility will send a control signal to a switch that opens and closes the power for all the customers’ equipment that are subject to controlled power, in this case the rain type heating control decides whether it uses the power not. The temperature in the rooms are individually controlled by opening and closing the radiator valves taking into account the time of day and the presence/short time absence of inhabitants. When a window is opened the radiator valve is closed. For the living room there is a choice of lighting scenes that are chosen at the central switch. When one opens the door to go to the terrace during night be outside lights are switched on. When one goes to bed one can switch off all lights on ground floor, in the staircase and corridor and also cut off the power on first floor in order to avoid electromagnetic smog while sleeping. When John and his family leave the house for short time the heating is switched to “standby”, the KNX system is set to intrusion alarm and all the lights are switched off. When John and his family leave the house for long time the heating is switched to “freeze protection”, home appliances are disconnected from power with the exception of the Frigidaire and the dishwasher that is disconnection with a delayed by 90 minutes. The KNX system is set to intrusion alarm and the lighting system may be set to simulation of a “lived in home”. A day before a member of John’s family returns to the house the heating is set to “comfort mode” using any telephone’s keypad and listening to the voice answers from the telecontrol. Should the heating be interrupted during the absence the telecontrol calls up the HVAC as well as John. Should a window be opened or broken during the absence the telecontrol calls up the security service as well as John. 2 67 draft 1 2 Type Inter Ecosystem Convergence Use case Nr/Title B 3: (Remote) heating control, intrusion alarm & home automation Implementation example Telecommand on power lines POTS telephone service Internet Satellit TV EN 50173( 1 and 4) Ethernet and TCP/IP KNX Cable TV 3 A.3.4 4 Use case B-4: Inter-Ecosystem Convergence: (Remote) energy control, intrusion alarm, 5 home automation, TV, voice and data communications 6 Type Inter Ecosystem Convergence Use case Nr/Title B 4: (Remote) energy control, intrusion alarm, home automation, TV, voice and data communications Services used Remote energy control, ISDN, Internet, security service, remote home control AN Ecosystems used Power grid; ISDN, Cable TV, Internet HN Ecosystems used KNX, EN 50173, Ethernet, TCP/IP Assumptions: John is not permanently in his house, that he wants to be attended also in his absence and wants it to be warm when he returns from a travel, that he uses as 68 home office if present. John has a contract with a security service to react on messages from his security system. John is connected to ISDN provided by the Telecom that also provides the Internet draft access. John has a contract with his energy utility service provider (USP) for remotely switch cheap power for the night storage heating for the floors of bathrooms and home offices. These floors can be switched to normal power with help of actuators. John is connected to the cable TV service. He has a Home Automation Network (HAN). He has an alarm system that watches windows & doors for opening and glass for integrity and is connected to a security service via the telephone network. He has a combined control for the heating source and solar panel that receives temperatures of rooms, the solar panel and the boilers and forwards is status and commands via KNX to third parties. John has equipped radiators with electric valves, rooms with temperature sensors/control and few switches, connected some power lines, e.g. that for the dishwasher to actuators. The network is bridged to the Internet with help of an IP controller. A PBX connects the phones in the different rooms to the ISDN The wall outlets for PCs in the rooms are connected to the Internet modem/router with help of category 7 cables (EN 50173), Ethernet and TCP/IP The TV is connected by a coaxial cable plus a category 7 cable & baluns with the incoming TV signal. The dishwasher is connected to the hot water pipe the washing machine to cold and hot water. John has insulated the roof, uses hot water from solar panel for heating, washing of laundry and dishes. John has intelligent control of heating source, solar panels and temperatures of individual rooms. 1 Type Inter Ecosystem Convergence Use case Nr/Title B 4: (Remote) energy control, intrusion alarm, home automation, TV, voice and data communications User Experience When John goes to bed he can switch off all lights on ground floor, in the staircase and corridor and also cut off the power on first floor in order to avoid electromagnetic smog while sleeping with a single command. When John leaves the house empty for a short time he sets the house profile with a single command. This switches the heating to “standby”, the alarm system is activated and the power of many consumer devices is taken away. When John leaves the house empty for a long time he sets the house profile with a single command. This switches the heating to “freeze protection”, home appliances are disconnected from power with the exception of the fridge/freezer and the dishwasher is disconnection after a delay of 90 minutes. The intrusion alarm is activated. A day before John returns to an empty house he activates the appropriate usage profile via Internet so that the rooms have the temperatures he/she expects. During his absence John can always check the status of his heating system with help of the following presentation and in more detail with help of KNX ETS. 69 1 2 draft 3 4 5 6 7 8 Type Inter Ecosystem Convergence Use case Nr/Title B 4: (Remote) energy control, intrusion alarm, home automation, TV, voice and data communications 70 Implementation example - HN Eco-systems used KNX Telecommand on power lines draft ISDN Internet Cable TV EN 50173 ( 1 and 4 ) Ethernet and TCP/IP Proprietary security service Cable TV 1 Type Inter Ecosystem Convergence Use case Nr/Title B 4: (Remote) energy control, intrusion alarm, home automation, TV, voice and data communications Additional Data The utility will send a control signal to open and close the power provided at the cheap rate. temperature sensors in the floors decide whether the power is used or not. In case gas and solar heating fail under house risks to freeze the floor heating as well as a cartridge heater can be switched to normal power. The temperature in the rooms are individually controlled by opening and closing the radiator valves taking into account the persons that are in the house, their timewise usage profile of the rooms. Should a window be opened or broken during the absence an alarum will activate the security service. In winter the flowers in the garage get minimum heat and light depending on theoretical sunshine. Watching of laundry and dishes can be conditioned on a surplus of some energy. 71 A.4 1 Use cases for changing service providers A.4.1 2 Use-case C-1: Changing Service Providers interactions: changing AN Ecosystem 3 draft Type Changing service providers Use case Nr/Title C 1: changing AN Ecosystem Appl. Services used TV, voice, internet, mobile AN Ecosystems used ADSL, POTS HN Ecosystems used DVB, Ethernet, TCP/IP, W3C, DECT, Microsoft P&P, EN 50173 Assumptions: See use case A 1 4 Type Changing service providers Use case Nr/Title C 1: changing AN Ecosystem User Experience John decides to cancel his TV service subscription from the cable operator and to switch to the latest HD service from a AS P that also is his internet A SP and ADSL AN SP. Also the EPG service comes from the new AS P. He cannot subscribe to a TV or EPG service from another AS P over his ADSL AN SP even though he prefers their offering of TV channels. He gets a new HG and a new STB from the ADSL AN SP. John needs to make a separate wired connection from the new HG to his new Set Top Box (STB) to ensure the QoS of the HD service. 5 6 7 Type Changing service providers 72 Use case Nr/Title C 1: changing AN Ecosystem Implementation Examples DVB IPI is the most used base standard to deliver IPTV over an ADSL AN to a draft home in Europe. ADSL AN Ecosystem is shared between all three services: voice, internet and TV However most operators do not (fully) adhere to it and use proprietary interfaces (e.g. Microsoft TV). They use their own Conditional Access (CA) system and/or AV formats. General trends are to use MPEG4/AAC for HD AV coding format but the applied encoding techniques and parameters as well as resolutions differ 1 Type Changing service providers Use case Nr/Title C 1: changing AN Ecosystem Additional Data The biggest issue in this use case is the QoS. Most A SP/AN SP mandate that the IPTV traffic in the homer must be separated from all other IP traffic (internet) in the home and uses a separate Ethernet cable (EN 50173) between HG and STB QoS is fully managed in the HG based on traffic type/class using priority queuing. The split between encrypted digital (pay TV) channels and the analog free to air channels can occur in the HG (see diagram) or in the STB. The analog channels are carried over the RF coax HN Ecosystem to the other TVs in the home. 2 A.4.2 3 Use Case C-2: Changing Service Providers interactions: open AN-Ecosystem 4 Type Changing service providers Use case Nr/Title C 2: open AN Ecosystem Appl. Services used TV, voice, internet, mobile AN Ecosystems used ADSL, POTS DVB, Ethernet, TCP/IP, W3C, DECT, Microsoft P&P, EN HN Ecosystems used 50173 Assumptions: See use case C 1 The HG is an open platform where SW from another A SP can be installed and executed. The AN SP and new A SP have agreed a tariff system for the the use of the AN Ecosystem The AN SP can deliver the new A SP traffic over his ADSL network from the A SP to the new STB with an agreed QoS 5 Type Changing service providers Use case Nr/Title C 2: open AN Ecosystem User Experience John decides to cancel his TV service subscription from the cable operator and to 73 switch to the latest HD service from a AS P that is different from his ADSL AN SP. He gets a new STB from his new A SP. John needs to make a separate wired connection from the HG to his new STB to draft ensure the QoS of the HD service. After John has been informed that the new service has been installed on his HG John switches on his TV and STB The new TV service appears on the screen. 1 2 3 Type Changing service providers Use case Nr/Title C 2: open AN Ecosystem Implementation Examples Most signaling occurs on the HG, the AN Ecosystem, the AN SP and the new A SP to detect and deliver the traffic from the new STB to the new A SP and vv with an agreed QoS No major impact on the HN Ecosystem 4 Type Changing service providers Use case Nr/Title C 2: open AN Ecosystem Additional Data The biggest issue in this use case is the QoS. Most A SP/AN SP mandate that the IPTV traffic in the homer must be separated from all other IP traffic (internet) in the home and uses a separate Ethernet cable (EN 50173) between HG and STB QoS is fully managed in the HG based on traffic type/class using priority queuing. The split between encrypted digital (pay TV) channels and the analog free to air channels now MUST occur in the STB as the HG does not know the format of the signal provided by the new A SP. The analog channels are carried over the normal RF coax HN Ecosystem to the other TVs in the home. 74 1 2 A.4.3 3 Use case C-3: Changing Service Providers interactions: changing network operator as 4 well as metering provider draft5 6 Type Service provider change Use case Nr/Title C 3: Changing network operator as well as metering provider Services used IPTV, Internet, energy management AN eco-systems used ADSL, Fiber EN 50173, Ethernet, Wi Fi, G.hn, HomePlug, LON, KNX, HN Eco-systems used TCP/IP, UPnP, DLNA, TR 069, Open IPTV 7 8 Type Service provider change Use case Nr/Title C 3: Changing network operator as well as metering provider Assumptions: John has a subscription to an independent ISP and independent service providers for IPTV and energy management. The IPTV service is provided via an ADSL access network, owned and operated by a network operator Every TV in the house is equipped with a managed UPnP enabled IP STB. Some are managed with TR 069, and controlled with UPnP. Some are managed as well as controlled with just UPnP. They communicate with the UPnP enabled (control point), HGI requirements based ADSL home gateway, via the best effort, unmanaged TCP/IP home network. There are also non managed content caches in the home network, such as a NAS and various PCs, which are all UPnP enabled. All the UPnP devices in the home are fully interoperable. For the AV devices this is achieved by means of DLNA compliance. The home gateway is remotely managed by the ADSL operator with TR 069. It contains a TR 069/UPnP converter The energy management service comprises of automatic meter reading and a coaching application. It is provided via a public powerline network, owned by a utility company, and the Internet. The electricity meter is read and remotely managed via an LON interface by a metering provider. The coaching service is provided by the energy management service provider over the Internet. The coaching is done based on knowledge of the metering data as well as knowledge of the power consumption of the various devices in the home (network). The local cable company has just migrated its access network to a very fast full fiber network. It also remotely manages with TR 069 The metering provider is not keeping to the Service Level Agreement (SLA), and is sending faulty bills regularly. 9 10 75 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: before draft Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber NP NP NP TV/HTS STB STB Internet,IMS, PC PowerGrid Home ISP Gateway phoneline NAS IPTV Meter ing powerline EN 50173, meter ISM wireless, phone line, coax cable, or power line 1 cabling 2 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: after Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber Power NP NP NP TV/HTS line STB STB Internet,IMS, PC PowerGrid Home ISP Gateway Optical fibre NAS IPTV Gate- Meter way ing powerline EN 50173 meter ISM wireless, phone line, coax cable, or power line 3 cabling 4 76 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: before draft Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber NP NP NP TV/HTS STB STB Internet,IMS, PC PowerGrid Home ISP Gateway (HGI) NAS IPTV Meter ing meter Ethernet, Wi-Fi, G.hn, HomePlug 1 OSI-layers 1 and 2 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: after Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber LON NP NP NP TV/HTS STB STB Internet,IMS, PC PowerGrid Home ISP Gateway (HGI) NAS IPTV Gate- Meter way ing meter Ethernet, Wi-Fi, G.hn, HomePlug 2 OSI-layers 1 and 2 3 77 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: before draft Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber NP NP NP TV/HTS STB STB Internet,IMS, PC PowerGrid Home ISP Gateway (HGI) NAS IPTV Meter ing TCP/IP (incl. UDP, HTTP(S), RTP/RTSP, RTCP, ...) meter 1 OSI-layers 3 and 4 2 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: after Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber LON NP NP NP TV/HTS STB STB Internet,IMS, PC PowerGrid Home ISP Gateway (HGI) NAS IPTV Gate- Meter way ing TCP/IP (incl. UDP, HTTP(S), RTP/RTSP, RTCP) meter 3 OSI-layers 3 and 4 4 78 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: before draft Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber NP NP NP TV/HTS STB STB Internet,IMS, PC PowerGrid Home ISP Gateway (HGI) NAS IPTV TR-069 Meter ing W3C, UPnP, meter DLNA, TR-069, OpenIPTV 1 OSI-layers 5-7 2 Type Service provider change Use case Nr/Title C-3: Changing network operator as well as metering provider Schematic Illustration (Required) Application & Service Provider view: after Service AN SP/NP HN Retail Providers Providers CPE devices Ecosystems CPE devices power ADSL fiber LON NP NP NP TV/HTS STB STB Internet,IMS, PC PowerGrid Home ISP Gateway (HGI) NAS IPTV TR-069 Gate- Meter way ing W3C, UPnP, meter DLNA, TR-069, OpenIPTV 3 OSI-layers 5-7 4 Type Service provider change Use case Nr/Title C 3: Changing network operator as well as metering provider User Experience John wants to switch network operator, because the higher bandwidth in the access network guarantees a better IPTV and Internet experience. 79 Besides, the fiber company claims it can also read and manage the electricity meter. So John grabs the opportunity and also switches the metering provider. John realizes he needs a different home gateway now, but for the rest he does not want to change any of the other devices, including the managed STBs and draft electricity meter. John terminates the subscriptions with the ADSL provider and the metering provider, and enlists with the fiber provider. The fiber provider sends him a new home gateway by mail. The new home gateway has the same home network interfaces as the old one, and therefore misses the LON interface. However, the gateway comes with a separate LON / UPnP Wi Fi converter (gateway) John plugs in the new home gateway and connects it to the fiber and the fixed Ethernet interfaces. He connects the LON / UPnP Wi Fi converter to the electricity meter. Within a few minutes everything seems to be working as before. No other configurations needed. John now enjoys higher quality IPTV, faster browsing, and a less faulty energy management service. 1 2 Type Service provider change Use case Nr/Title C 3: Changing network operator as well as metering provider Implementation Examples The STBs may be from different companies and/or built in in the TV sets. Switching service providers without changing STBs means that the STBs need to be interoperable with different service platform. The use of OpenIPTV may achieve this. The home network is in principle an unmanaged TCP/IP subnetwork and can be implemented as any mix of twisted pair or (plastic) optical fiber (EN 50173), coax Ethernet, or any of the older broadband powerline standards, and any variety of Wi Fi. STBs, PCs, home gateway and the NAS are all connected to this . The remote metering could also be performed with KNX instead of LON. This use case implies that the smart meter can be read via an external home gateway, i.e. not built in the smart meter. This may imply that the meter is installed with a separate home gateway in the first place. Today, there are still a number of issues on ownership, cost sharing, and installation practice that need to be solved for this. 3 Type Service provider change Use case Nr/Title C 3: Changing network operator as well as metering provider Additional Data After changing service provider, also the meter is connected to the home network (via the LON / UPnP connector) instead of directly communicating with the public power line network. If the electricity meter was not yet equipped with a LON or KNX interface it has to be replaced with a new meter. After changing service providers, devices need to rediscovered and then remotely reprovisioned and managed. This is where, for this use case, UPnP and TR 069 come into play. The new home gateway discovers all devices and their capabilities 80 with UPnP. With a, still to be developed and standardized, TR 069/UPnP converter in the home gateway, the network operator can then discover and configure the network parameters of the devices remotely. That should be enough for devices and independent service providers to contact each other again on the application layer. draft Also the remote meter will thus be discovered and can then be remotely monitored and configured via the broadband home gateway by the metering provider. 1 2 3 4 5 6 81 B 1 Acronyms 2 draft Acronym Name Description 2.5G second and a half generation 3G third generation 3GPP 3rd Generation collaboration between groups of telecommunications Partnership Project associations, to make a globally applicable third generation (3G) mobile phone system specification within the scope of the International Mobile Telecommunications 2000 project of the International Telecommunication Union (ITU). 3GPP specifications are based on evolved Global System for Mobile Communications (GSM) specifications. 3GPP standardization encompasses Radio, Core Network and Service architecture. 6LowPAN IPv6 over Low power 6lowpan is an acronym of IPv6 over Low power Wireless Personal Area Wireless Personal Area Networks, or (as the "personal" Networks qualification is no longer relevant), IPv6 over LoW Power wireless Area Networks. 6lowpan is the name of a working group in the internet area of the IETF. The 6lowpan group has defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent to and received from over IEEE 802.15.4 based networks. IPv4 and IPv6 are the work horses for data delivery for local area networks, metropolitan area networks, and wide area networks such as the Internet. Likewise, IEEE 802.15.4 devices provide sensing communication ability in the wireless domain. The inherent natures of the two networks though, is different. The base specification developed by the 6lowpan IETF group is RFC 4944. The problem statement document is RFC 4919. 6lowpan is an acronym of IPv6 over Low power Wireless Personal Area Networks, or (as the "personal" qualification is no longer relevant), IPv6 over LoW Power wireless Area Networks. 6lowpan is the name of a working group in the internet area of the IETF. The 6lowpan group has defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent to and received from over IEEE 802.15.4 based networks (ZigBee). IPv4 and IPv6 are the work horses for data delivery for local area networks, metropolitan area networks, and wide area networks such as the Internet. Likewise, IEEE 802.15.4 devices provide sensing communication ability in the wireless domain. The inherent natures of the two networks though, is different. The base specification developed by the 6lowpan IETF group is RFC 4944. The problem statement document is RFC 4919. AAC Advanced Audio Coding an audio compression format specified by MPEG 2 and MPEG 4, and successor to MPEG 1’s “MP3” format. ADSL Asymmetric Digital one form of the Digital Subscriber Line technology, a Subscriber Line data communications technology that enables faster data transmission over copper telephone lines than a 82 conventional voiceband modem can provide. It does this by utilizing frequencies that are not used by a voice telephone call. A splitter or microfilter allows a single telephone connection to be used for both ADSL service and voice calls at the same time. ADSL can generally only be distributed over short distances from draft the central office, typically less than 4 kilometres (2 mi), but has been known to exceed 8 kilometres (5 mi) if the originally laid wire gauge allows for farther distribution. ALGS Application level an application level gateway (also known as ALG or gateway application layer gateway) consists of a security component that augments a firewall or NAT employed in a computer network. It allows customized NAT traversal filters to be plugged into the gateway to support address and port translation for certain application layer "control/data" protocols such as FTP, BitTorrent, SIP, RTSP, file transfer in IM applications etc. In order for these protocols to work through NAT or a firewall, either the application has to know about an address/port number combination that allows incoming packets, or the NAT has to monitor the control traffic and open up port mappings (firewall pinhole) dynamically as required. Legitimate application data can thus be passed through the security checks of the firewall or NAT that would have otherwise restricted the traffic for not meeting its limited filter criteria. AMI Advanced Metering Infrastructure AN Access network AV Audio visual BBF Broadband Forum The Broadband Forum is a non profit global industry consortium dedicated to developing broadband network specifications. Its members include leading industry players covering telecommunications, equipment, computing, networking and service provider companies. Its service provider make up is primarily fixed line operators. Bcst Broadcast BRB-F Broadband Forum Cam Camera CAT. X Category X commonly referred to as Cat x, is a cable standard for Gigabit Ethernet and other network protocols that are backward compatible with the Category 5/5e and Category 3 cable standards. Compared with Cat 5 and Cat 5e, Cat 6 features more stringent specifications for crosstalk and system noise. The cable standard provides performance of up to 250 MHz and is suitable for 10BASE T, 100BASE TX (Fast Ethernet), 1000BASE T / 1000BASE TX (Gigabit Ethernet) and 10GBASE T (10 Gigabit Ethernet). Category 6 cable has a reduced maximum length when used for 10GBASE T; Category 6a cable, or Augmented Category 6, is characterized to 500 MHz and has improved alien crosstalk characteristics, allowing 10GBASE T to be run for the same distance as previous protocols. Category 6 cable can be identified by the printing on the side of the cable sheath. CE Consumer Electronics CEA Consumer Electronics Association CEN Comité Européen de Normalisation (European Committee for Standardization) 83 CENELEC Comité Européen de Normalisation Électrotechnique (European Committee for Electrotechnical Standardization) draft CIM Common Information In electric power transmission and distribution, the Model Common Information Model (CIM), a standard developed by the electric power industry that has been officially adopted by the International Electrotechnical Commission (IEC), aims to allow application software to exchange information about the configuration and status of an electrical network. The CIM is currently maintained as a UML model. It defines a common vocabulary and basic ontology for aspects of the electric power industry. The central package within the CIM is the 'wires model', which describes the basic components used to transport electricity. The CIM can be used to derive 'design artifacts' (e.g. XML Schema, RDF Schema) as needed for the integration of related application software. Managed by IEC TC57. Coax Coaxial COSEM COmpanion Specification for Energy Metering CPE Common Platform Enumeration CPE Customer Premises Equipment CSS Customer Service System CU DC Downloadable content DECT Digital Enhanced an ETSI standard for digital portable phones (cordless Cordless home telephones), commonly used for domestic or Telecommunications corporate purposes. It is recognised by the ITU as fulfilling the IMT 2000 requirements and thus qualifies as a 3G system. Within the IMT 2000 group of technologies, DECT is referred to as IMT 2000 Frequency Time (IMT FT) DECT was developed by ETSI but has since been adopted by many countries all over the world. The original DECT frequency band (1880 MHz–1900 MHz) is used in all countries in Europe. Outside Europe, it is used in most of Asia, Australia and South America. In the United States, the Federal Communications Commission in 2005 changed channelization and licensing costs in a nearby band (1920 MHz–1930 MHz, or 1.9 GHz), known as Unlicensed Personal Communications Services (UPCS), allowing DECT devices to be sold in the U.S. with only minimal changes. These channels are reserved exclusively for voice communication applications and therefore are less likely to experience interference from other wireless devices such as baby monitors and wireless networks. DLC Data Link Control The same initialism, standing for the same phrase, is also a network protocol in its own right, comparable to better known protocols such as TCP/IP or AppleTalk. DLC is a transport protocol used by IBM SNA mainframe computers and peripherals and compatible equipment. In PC networking, it is typically used for communications between network attached printers and 84 PCs and servers, for example by HP in their JetDirect print servers. While it was widely used up until the time of Windows 2000, the DLC protocol is no longer included in Windows XP, but available for download . DLMS Device Language Message specification draft DLNA Digital Living Network DLNA intends to solve the problems inherent in using Alliance digital media between different consumer electronic devices. For example, a DLNA compliant TV will interoperate with a DLNA compliant PC to play music, photos or videos. The specification also includes DRM, a scheme to ensure that the "content must be protected from unauthorized copying and use". DLP Digital loop carrier a system which uses digital transmission to extend the range of the local loop farther than would be possible using only twisted pair copper wires. A DLC digitizes and multiplexes the individual signals carried by the local loops onto a single datastream on the DLC segment. DNP3 Distributed Network a set of communications protocols used between Protocol components in process automation systems. Its main use is in utilities such as electric and water companies. Usage in other industries is not common, although technically possible. Specifically, it was developed to facilitate communications between various types of data acquisition and control equipment. It plays a crucial role in SCADA systems, where it is used by SCADA Master Stations (aka Control Centers), Remote Terminal Units (RTUs), and Intelligent Electronic Devices (IEDs). It is primarily used for communications between a master station and RTUs or IEDs. ICCP, the Inter Control Centre Protocol, is used for inter master station communications. DVB Digital Video Broadcasting DVB-C Digital Video the DVB European consortium standard for the Broadcasting Cable broadcast transmission of digital television over cable. This system transmits an MPEG 2 or MPEG 4 family digital audio/video stream, using a QAM modulation with channel coding. DVB-IPI Digital Video an open DVB standard that enables Audio/Video Broadcasting IPI services to be delivered to and through the home via Internet Protocol networking. DVB IPTV was formerly known as DVB IPI. DVI Digital Visual Interface EC European Commission EMS Energy Management System EPCGlobal EPCglobal is a joint venture between GS1 (formerly known as EAN International) and GS1 US (formerly the Uniform Code Council, Inc.). It is an organization set up to achieve world wide adoption and standardization of Electronic Product Code (EPC) technology. The main focus of the group currently is to create both a world wide standard for RFID and the use of the Internet to share data via the EPCglobal Network. ESI Energy Services Interface ESO European Standards Organisations ESU Energy Supplying Unit ETS Tool Software for KNX ETS in von Patay use case 85 commissioning KNX installation ETSI European The European Telecommunications Standards Institute Telecommunications (ETSI) is an independent, non profit, standardization Standards Institute organization in the telecommunications industry (equipment makers and network operators) in Europe, draft with worldwide projection. ETSI has been successful in standardizing the GSM cell phone system and the TETRA professional mobile radio system. Significant ETSI standardization bodies include TISPAN (for fixed networks and Internet convergence). ETSI inspired the creation of, and is a partner in 3GPP. ETSI HF ETSI Human Factors ETSI ETSI Telecoms & The Telecoms & Internet converged Services & TISPAN Internet converged Protocols for Advanced Networks (TISPAN) is a Services & Protocols for standardization body of ETSI, specializing in fixed Advanced Networks networks and Internet convergence. It was formed in 2003 from the amalgamation of the ETSI bodies Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) and Services and Protocols for Advanced Networks (SPAN). TISPAN's focus is to define the European view of the Next Generation Networking (NGN), though TISPAN also includes much participation from regions outside Europe. EUD End User Device perform an end user function Examples are TV, PC, home AV server, phones, lights, camera’s, thermostat, heater valves, personal health care devices, white goods, etc. FHDMC Fixed Home Area Network Devices with Metering Capability G.hn G. Home network G.hn is the common name for a new home network technology standard being developed under the International Telecommunication Union (ITU) and promoted by the HomeGrid Forum and several other organizations Because it supports networking over power lines, phone lines and coaxial cables with data rates up to 1 Gbit/s, G.hn's proponents believe that it will become a universal standard for home networking. GEM Generic Equipment Model GSM Global System for Mobile Communications: HA Home Area HAN Home Area Network HBES Home and Building Electronic System HCS Home Control System HDMI High Definition compact audio/video interface for transmitting Multimedia Interface uncompressed digital data. It represents a digital alternative to consumer analog standards, such as radio frequency (RF) coaxial cable, composite video, S Video, SCART, component video, D Terminal, or VGA. HDMI connects digital audio/video sources— such as set top boxes, Blu ray Disc players, personal computers (PCs), video game consoles (such as the PlayStation 3 and some models of Xbox 360), and AV receivers—to compatible digital audio devices, 86 computer monitors, and digital televisions. HES Home Entertainment System HES Home Electronic System HG Home Gateway are NIDs possibly combined with an EUD that also provide a connection to one or more ANs . They connect draft these networks on level 1/2 (media extender or terminator, bridge), level 3 (router) or level 7 (application layer gateway – ALG) HGI Home Gateway Initiative nonprofit organization launched by a number of telephone companies (Belgacom, BT, Deutsche Telekom, France Telecom, KPN, Teliasonera, NTT, Telefonica, Telecom Italia) in December 2004 to provide a place where operators, content providers, service providers and manufacturers can discuss the key specifications and standards of home gateways. Several manufacturers have also joined the alliance. HN Home network HTLM HyperText Markup Language HTS Home Theater System also commonly called home theater, are home entertainment set ups that seek to reproduce the movie theater going experience and mood with the help of video and audio equipment in a private home. HTTP Hypertext Transfer Protocol HVAC Heating, Ventilating, and Air Conditioning ICT Information and Communication Technology IE8 Internet Explorer 8 IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering develops and promotes Internet standards, cooperating Task Force closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the TCP/IP and Internet protocol suite. It is an open standards organization, with no formal membership or membership requirements. All participants and managers are volunteers, though their work is usually funded by their employers or sponsors; for instance, the current chairperson is funded by VeriSign and the U.S. government's National Security Agency. IFRS Interoperability Framework Requirements Specification IHD In Home Display IMS IP Multimedia The IP Multimedia Subsystem (IMS) is an architectural Subsystem framework for delivering Internet Protocol (IP) multimedia services. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), as a part of the vision for evolving mobile networks beyond GSM. Its original formulation (3GPP R5) represented an approach to delivering "Internet services" over GPRS. This vision was later updated by 3GPP, 3GPP2 and TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed line. 87 Insteon INSTEON technology is a dual band mesh topology employing AC power lines and a radio frequency (RF) protocol to communicate with and automate home electronic devices and appliances, which normally work independently. It is a home automation networking technology invented by SmartLabs, Inc. INSTEON was draft developed, based on the X10 model, for control and sensing applications in the home. IOF Interoperability Function IOP Interoperability Profile IP Internet Protocol the primary protocol in the Internet Layer of the Internet Protocol Suite and has the task of delivering distinguished protocol datagrams (packets) from the source host to the destination host solely based on their addresses. For this purpose the Internet Protocol defines addressing methods and structures for datagram encapsulation. The first major version of addressing structure, now referred to as Internet Protocol Version 4 (IPv4) is still the dominant protocol of the Internet, although the successor, Internet Protocol Version 6 (IPv6) is being deployed actively worldwide. IP/802 Internet protocol / IEEE 802.x IPI Intelligent Peripheral Intelligent Peripheral Interface (IPI) was a server centric Interface storage interface used in the 1980s and early 1990s with an ISO 9318 standard. The general idea behind IPI was that the disk drives themselves are as simple as possible, containing only the lowest level control circuitry, while the IPI interface card encapsulated most of the disk control complexity. The IPI interface card, as a central point of control, was thus theoretically able to best coordinate accesses to the connected disks, as it "knew" more about the states of the connected disks than would, say, a SCSI interface. IPTV Internet Protocol a system through which digital television service is television delivered using the architecture and networking methods of the Internet Protocol Suite over a packet switched network infrastructure, e.g., the Internet and broadband Internet access networks, instead of being delivered through traditional radio frequency broadcast, satellite signal, and cable television (CATV) formats. See Internet television. IR Infrared IrDA Infrared Data The Infrared Data Association (IrDA) defines physical Association specifications communications protocol standards for the short range exchange of data over infrared light, for uses such as personal area networks (PANs). ISDN Integrated Services Digital Network ISM Industrial, Scientific and Medical radio bands ISO International Organization for Standardization ISO Independent System Operator ISP Internet Service Provider ITU-T International Telecommunications Union Standardisation Sector KNX KNX 88 LonWorks LonWorks is a networking platform specifically created to address the needs of control applications. The platform is built on a protocol created by Echelon Corporation for networking devices over media such as twisted pair, powerlines, fiber optics, and RF. It is used for the automation of various functions within buildings draft such as lighting and HVAC; see Intelligent building. LUI Local user interface M-Bus Meter Bus European standard (EN 13757 2 physical and link layer, EN 13757 3 application layer) for the remote reading of gas or electricity meters. M Bus is also usable for other types of consumption meters. The M Bus interface is made for communication on two wire, making it very cost effective. A radio variant of M Bus (Wireless M Bus) is also specified in EN 13757 4. MHDMC Mobile Home Area Network Devices with Metering Capability MHP Multimedia Home Multimedia Home Platform (DVB MHP) is an open Platform middleware system standard designed by the DVB project for interactive digital television. The MHP enables the reception and execution of interactive, Java based applications on a TV set. Interactive TV applications can be delivered over the broadcast channel, together with audio and video streams. These applications can be for example information services, games, interactive voting, e mail, SMS or shopping. For all interactive applications an additional return channel is needed. MoCa Multimedia over Coax The Multimedia over Coax Alliance develops Alliance specifications for home networking over in home coaxial cable, which is commonly used for antenna connections to TVs and radios, and cable TV. MPEG Moving Picture Experts The MPEG compression methodology is considered Group asymmetric in that the encoder is more complex than the decoder. The encoder needs to be algorithmic or adaptive whereas the decoder is 'dumb' and carries out fixed actions. This is considered advantageous in applications such as broadcasting where the number of expensive complex encoders is small but the number of simple inexpensive decoders is large. This approach of the ISO to standardization in MPEG is considered novel because it is not the encoder which is standardized; instead, the way in which a decoder shall interpret the bitstream is defined. A decoder which can successfully interpret the bitstream is said to be compliant. The advantage of standardizing the decoder is that over time encoding algorithms can improve yet compliant decoders will continue to function with them. The MPEG standards give very little information regarding structure and operation of the encoder and implementers can supply encoders using proprietary algorithms. This gives scope for competition between different encoder designs which means that better designs can evolve and users will have greater choice because of different levels of cost and complexity can exist in a range of coders yet a compliant decoder will operate with them all. MPEG also standardizes the protocol and syntax under which it is possible to combine or multiplex audio data with video data to produce a digital equivalent of a television program. Many such programs can be multiplexed and MPEG defines the way in which such multiplexes can be created and transported. The 89 definitions include the metadata used by decoders to demultiplex correctly. MPEG4 absorbs many of the features of MPEG 1 and MPEG 2 and other related standards, adding new features such as (extended) VRML support for 3D rendering, object oriented composite files (including audio, video and draft VRML objects), support for externally specified Digital Rights Management and various types of interactivity. AAC (Advanced Audio Coding) was standardized as an adjunct to MPEG 2 (as Part 7) before MPEG 4 was issued. MTP Micro Transport Protocol It was devised to automatically slow down the rate at which packets of data are transmitted between users of peer to peer file sharing torrents when the file sharing traffic interferes with other applications. For example, it should in principle automatically allow the sharing of an ADSL line between a BitTorrent application and a web browser. As it is difficult for some people to type the Greek letter mu, TP is often written uTP. NAS Network attached storage NFC Network File Control Network File Control (NFC) is a common point of "command and control" for file data delivering a common set of network resident services, centrally defined and managed via policy, then applied across a heterogeneous file storage infrastructure. NFC's associated services are delivered "within the network" and affects the treatment of file data from its "origination to destination". NFC plays an integral role in controlling the various aspects of file management for a Global Namespace. NFS Network File System Network File System (NFS) is a network file system protocol originally developed by Sun Microsystems in 1984, allowing a user on a client computer to access files over a network in a manner similar to how local storage is accessed. NFS, like many other protocols, builds on the Open Network Computing Remote Procedure Call (ONC RPC) system. The Network File System is an open standard defined in RFCs, allowing anyone to implement the protocol. NID Network interface device Communication devices connecting HN segments and do not perform an end user function Examples are network terminators, bridges, switches, routers, etc. NP Network provider NT network terminator OBIS OBject Identification System oBIX Open Building Information Xchange OCAP OpenCable Application OpenCable Application Platform, or OCAP, is an Platform operating system layer designed for consumer electronics that connect to a cable television system like Comcast or Cox. Unlike operating systems on a personal computer, the cable company controls what OCAP programs run on the consumer's machine. Designed by CableLabs for the cable networks of North America, OCAP programs are intended for interactive services such as eCommerce, online banking, Electronic program guides, and digital video recording. Open IPTV IPTV that is not limited to one recording studio, production studio, or cast. Open IPTV uses the Internet or other means to pool efforts and resources together to 90 create an online community that all contributes to a show OSGi OSGi Alliance formerly known as the Open Services Gateway initiative, now an obsolete name) is an open standards organization founded in March 1999. The Alliance and its members have specified a Java based service draft platform that can be remotely managed. The core part of the specifications is a framework that defines an application life cycle management model, a service registry, an Execution environment and Modules. Based on this framework, a large number of OSGi Layers, APIs, and Services have been defined. OSI Open Systems Open Systems Interconnection (OSI) is an effort to Interconnection standardize networking that was started in 1977 by the International Organization for Standardization (ISO), along with the ITU T. PAN/802 Personal area network a computer network used for communication among computer devices, including telephones and personal digital assistants, close to one's person. The devices may or may not belong to the person in question. The reach of a PAN is typically a few meters. PANs can be used for communication among the personal devices themselves (intrapersonal communication), or for connecting to a higher level network and the Internet (an uplink). Personal area networks may be wired with computer buses such as USB and FireWire. A wireless personal area network (WPAN) can also be made possible with network technologies such as IrDA, Bluetooth, UWB, Z Wave and ZigBee PBX private branch exchange A private branch exchange (PBX) is a telephone exchange that serves a particular business or office, as opposed to one that a common carrier or telephone company operates for many businesses or for the general public. PBXs are also referred to as: PC Personal Computer PCT Programmable Communicating Thermostat PD Peripheral device PDA Personal digital assistant PLC Power Line Communications PN Peripheral network POF Plastic optical fiber Plastic optical fiber (POF) (or fibre) is an optical fiber which is made out of plastic. Traditionally PMMA (acrylic) is the core material, and fluorinated polymers are the cladding material. Since the late 1990s however, much higher performance POF based on perfluorinated polymers (mainly polyperfluorobutenylvinylether) has begun to appear in the marketplace. POTS Plain old telephone system PPP Point to Point Protocol In networking, the Point to Point Protocol, or PPP, is a data link protocol commonly used to establish a direct connection between two networking nodes. It can provide connection authentication, transmission encryption privacy, and compression. PT Project Team PUCC P2P Universal P2P Universal Computing Consortium (PUCC) is Computing Consortium promoting research and development of an open P2P/Overlay network service platform that connects 91 multi types of devices users use, and conducts the standardization efforts. QoS Quality of Service In the field of computer networking and other packet switched telecommunication networks, the traffic engineering term quality of service (QoS) refers to resource reservation control mechanisms rather than the draft achieved service quality. Quality of service is the ability to provide different priority to different applications, users, or data flows, or to guarantee a certain level of performance to a data flow. For example, a required bit rate, delay, jitter, packet dropping probability and/or bit error rate may be guaranteed. Quality of service guarantees are important if the network capacity is insufficient, especially for real time streaming multimedia applications such as voice over IP, online games and IP TV, since these often require fixed bit rate and are delay sensitive, and in networks where the capacity is a limited resource, for example in cellular data communication. In the absence of network congestion, QoS mechanisms are not required. R Retail RA Referecne Architecture R-CPE Retail conumer peripheral equipment R-EUD Retail end user device RF Radio Frequency RF4CE Radio Frequency for ZigBee RF4CE Consumer Electronics On March 3, 2009 the RF4CE (Radio Frequency for Consumer Electronics) Consortium agreed to work with the ZigBee Alliance to jointly deliver a standardized specification for radio frequency based remote controls. ZigBee RF4CE is designed to be deployed in a wide range of remotely controlled audio/visual consumer electronics products, such as TVs and set top boxes. It promises many advantages over existing remote control solutions, including richer communication and increased reliability, enhanced features and flexibility, interoperability, and no line of sight barrier. RSS Really Simple Syndication RTP/RTCP Real time Transport (Control) Protocol RUI Remote User Interface SATA Serial AT attachment The serial ATA or SATA computer bus, is a storage interface for connecting host bus adapters to mass storage devices such as hard disk drives and optical drives. The SATA host adapter is integrated into almost all modern consumer laptop computers and desktop motherboards. Serial ATA was designed to replace the older ATA (AT Attachment) standard (also known as EIDE). It is able to use the same low level commands, but serial ATA host adapters and devices communicate via a high speed serial cable over two pairs of conductors. In contrast, the parallel ATA (the redesignation for the legacy ATA specifications) used 16 data conductors each operating at a much lower speed. SCART Syndicat des French originated standard and associated 21 pin Constructeurs connector for connecting audio visual (AV) equipment d'Appareils together. It is also known as Péritel (especially in Radiorécepteurs et France, where the term SCART is practically unknown), Téléviseurs 21 pin EuroSCART (Sharp's marketing term for an attempt to market the connector in the Asian region, 92 Euroconector or EuroAV. In America, another name for SCART is EIA Multiport (an EIA interface). SHA-RA SHA Reference Architecture SHR Smart Homes Roadmap SIG Special interest group draft Session Initiation The Session Initiation Protocol (SIP) is a signaling SIP Protocol protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol (IP). The protocol can be used for creating, modifying and terminating two party (unicast) or multiparty (multicast) sessions consisting of one or several media streams. The modification can involve changing addresses or ports, inviting more participants, adding or deleting media streams, etc. Other feasible application examples include video conferencing, streaming multimedia distribution, instant messaging, presence information and online games. SLA Service Level Agreement SMS Short Message Service a communication service component of the GSM mobile communication system, using standardized communications protocols that allow the exchange of short text messages between mobile phone devices. SMS text messaging is the most widely used data application in the world, with 2.4 billion active users, or 74% of all mobile phone subscribers. Because of its ubiquity, the term SMS is used as a synonym for all types of short text messaging, as well as the user activity itself, in many parts of the world. SOAP Simple Object Access SOAP, originally defined as Simple Object Access Protocol Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on eXtensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope which defines what is in the message and how to process it a set of encoding rules for expressing instances of application defined datatypes, and a convention for representing procedure calls and responses. SP Service provider SP-CPE Security Content Automation Protocol SPDIF Data Link Layer protocol and a set of Physical Layer specifications for carrying digital audio signals between devices and stereo components over either optical or electrical cable. The name stands for Sony/Philips Digital Interconnect Format (more commonly known as Sony Philips Digital InterFace), Sony and Philips being the primary designers of S/PDIF. S/PDIF is standardized in IEC 60958 where it is known as IEC 60958 type II. S/PDIF is essentially a minor modification of the original AES/EBU standard, for consumer use, providing small differences in the protocol and requiring less expensive hardware. SRS System Requirements Specification STB Set Top Box 93 S-video Separate Video more commonly known as S Video, also called Y/C, and sometimes incorrectly referred to as Super Video is an analog video signal that carries video data as two separate signals: luma (luminance) and chroma (color). This differs from composite video, which carries picture information as a single lower quality signal, and draft component video, which carries picture information as three separate higher quality signals. S Video carries standard definition video (typically at 480i or 576i resolution), but does not carry audio on the same cable. TCP/IP Transmission Control The Internet Protocol Suite (commonly known as Protocol / Internet TCP/IP) is the set of communications protocols used for Protocol the Internet and other similar networks. It is named from two of the most important protocols in it: the Transmission Control Protocol (TCP) and the Internet Protocol (IP), which were the first two networking protocols defined in this standard. Today's IP networking represents a synthesis of several developments that began to evolve in the 1960s and 1970s, namely the Internet and LANs (Local Area Networks), which emerged in the mid to late 1980s, together with the advent of the World Wide Web in the early 1990s. Telco Telecommunications company TOU Time of Use U SP utility service provider UI User Interface UPA Universal Powerline The Universal Powerline Association (UPA) is a trade Association association which covers all power line communication markets and all power line communication applications. The UPA aims to promote the growth of power line communication technology by delivering certified products that comply with agreed specifications. UPnP Universal Plug and Play set of networking protocols promulgated by the UPnP Forum. The goals of UPnP are to allow devices to connect seamlessly and to simplify the implementation of networks in the home (data sharing, communications, and entertainment) and in corporate environments for simplified installation of computer components. UPnP achieves this by defining and publishing UPnP device control protocols (DCP) built upon open, Internet based communication standards. The term UPnP is derived from plug and play, a technology for dynamically attaching devices directly to a computer, although UPnP is not directly related to the earlier plug and play technology. UPnP devices are "plug and play" in that when connected to a network they automatically announce their network address and supported device and services types, enabling clients that recognize those types to immediately begin using the device. USB Universal Serial Bus USB (Universal Serial Bus) is a specification to establish communication between devices and a host controller (usually personal computers). USB is intended to replace many varieties of serial and parallel ports. USB can connect computer peripherals such as mice, keyboards, digital cameras, printers, personal media players, flash drives, and external hard drives. UTP unshielded twisted pair cabling UWB Ultra wideband >500 MHz VB Virtual backbone 94 VDSL Very High Bitrate Digital Subscriber Line VoD Video on Demand vpn Virtual private network W3C World Wide Web main international standards organization for the World Consortium Wide Web (abbreviated WWW or W3). draft Founded and headed by Sir Tim Berners Lee, the consortium is made up of member organizations which maintain full time staff for the purpose of working together in the development of standards for the World Wide Web. As of 8 September 2009, the World Wide Web Consortium (W3C) has 356 members. WG Working Group WHDI Wireless Home Digital Wireless Home Digital Interface (WHDI) is a consumer Interface electronic industry initiative to set a standard specification for wireless high definition connectivity with in and throughout the home. WHDI will enable wireless uncompressed HD video delivery throughout the home, allowing consumers to connect any source in the home to any display devices Wi-Fi Trademark of the Wi Fi Alliance that manufacturers may use to brand certified products that belong to a class of wireless local area network (WLAN) devices based on the IEEE 802.11 standards. Wimax Worldwide telecommunications technology that provides wireless Interoperability for transmission of data using a variety of transmission Microwave Access modes, from point to multipoint links to portable and fully mobile internet access. The technology provides up to 10 Mbps broadband speed without the need for cables. The technology is based on the IEEE 802.16 standard (also called Broadband Wireless Access). The name "WiMAX" was created by the WiMAX Forum, which was formed in June 2001 to promote conformity and interoperability of the standard. The forum describes WiMAX as "a standards based technology enabling the delivery of last mile wireless broadband access as an alternative to cable and DSL". XML Extensible Markup XML (Extensible Markup Language) is a set of rules for Language encoding documents electronically. It is defined in the XML 1.0 Specification produced by the W3C and several other related specifications; all are fee free open standards. ZigBee ZigBee is a specification for a suite of high level communication protocols using small, low power digital radios based on the IEEE 802.15.4 2003 standard for wireless personal area networks (WPANs), such as wireless headphones connecting with cell phones via short range radio. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs, such as Bluetooth. ZigBee is targeted at radio frequency (RF) applications that require a low data rate, long battery life, and secure networking. 1 2 3 95 C 1 Long list of Smart House standards 2 For this project we constructed the following long list of standards which we deem to be draft3 relevant for the SmartHouse in 2010, by using the following selection criteria as a filter: 4 • Only standards and specifications that have a documented relevance to 5 interoperability and convergence of Smart House specific applications 6 • Only standards and specifications that have a documented relevance in the 7 market 8 • Preferably European standards and specifications. International (global) 9 standards and specifications only if relevant and European equivalent are not 10 available. National standards and specifications only if international and 11 European equivalents are not available. 12 • Only finalized standards and specifications. No drafts or non normative 13 guidelines and technical reports. 14 • Only the latest versions of the standards and specifications, and older versions if 15 they are still supported in the market 16 17 Mostly it is obvious how an Ecosystem should be named and what standards belong to 18 it. But sometimes it is not. In those cases we have taken the freedom to name the 19 Ecosystem pragmatically and to group standards to an Ecosystem as we see the market 20 operate them 21 Ecosystem Standards Titles of the standards Extra information equiva lents TCP/IP IETF RFC Internet Protocol 791 IETF RFC Internet Protocol, Version 6 2460 (IPv6) specification IETF RFC Security Architecture for the 3401 Internet Protocol IETF RFC Using Advanced Encryption 3409 Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) IETF RFC Internet Control Message 792 Protocol IETF RFC Internet Control Message 4443 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification IETF RFC Transmission Control Protocol 793 IETF RFC An Ethernet Address Resolution (Or:Converting 826 Protocol Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware) IETF RFC User Datagram Protocol 768 IETF RFC Dynamic Host Configuration 2131 Protocol IETF RFC Dynamic Host Configuration 3315 Protocol for IPv6 (DHCPv6) 96 IETF RFC DHCP Options and BOOTP 2132 Vendor Extensions IETF RFC Traditional IP Network Address 3022 Translator (Traditional NAT) IETF RFC STUN Simple Traversal of User 3489 Datagram Protocol (UDP) draft Through Network Address Translators (NATs) IETF RFC Address Allocation for Private 1918 Internets IETF RFC Dynamic Configuration of IPv4 3927 Link Local Addresses IETF RFC IPv6 Stateless Address 4862 Autoconfiguration IETF RFC Domain Names – Concepts and 1034 Facilities IETF RFC Domain Names – Implementation 1035 and Specification IETF RFC The User Class Option for DHCP 3004 IETF RFC Vendor Options for DHCPv4 3925 IETF RFC Network Time Protocol (Version 1305 3) IETF RFC SNTP Version 4 for IPv4, IPv6 2030 and OSI IETF RFC HyperText Transfer Protocol / 2616 HTTP 1.1 IETF RFC Requirements for Internet Hosts 1122 Communication layers IETF RFC Use and interpretation of http 2145 version numbers Web family IETF RFC A Universally Unique IDentifier 4122 (UUID) URN Namespace IETF RFC HTTP Authentication: Basic and 2617 Digest Access Authentication IETF RFC IGMP v3 3376 IETF RFC The PPP Internet Protocol 1332 Control Protocol (IPCP) IETF RFC PPP Authentication Protocol 1334 IETF RFC The Point to Point Protocol (PPP) 1661 IETF RFC PPP Internet Protocol Control 1877 Protocol Extensions for Name Server Addresses IETF RFC PPP Challenge Handshake 1994 Authentication Protocol (CHAP) IETF RFC A Method for Transmitting PPP 2516 Over Ethernet (PPPoE) IETF RFC PPP Over AAL5 2364 IETF RFC RTP: A Transport Protocol for 3550 Real Time Applications IETF RFC RTP profile for Audio and Video 3551 Conferences with Minimal Control IETF RFC RTP Control Protocol Extended 3611 Reports (RTCP XR) IETF RFC MIME Type Registration of RTP 3555 Payload Formats IETF RFC The Secure Real time Transport 97 3711 Protocol (SRTP) SIP IETF RFC SIP: Session Initiation Protocol 3261 IETF RFC Session Description Protocol 3264 (SDP) IETF RFC Uniform Resource Identifiers draft 2396 (URI): Generic Syntax". IETF RFC The URI for Telephone Numbers 3966 IETF RFC SIP: Specific Event Notification 3265 IETF RFC Initiated Dialog Event Package 4235 for SIP IETF RFC SIP Refer Method 3515 IETF RFC A Message Summary and 3842 Message Waiting Indication Event Package for SIP IETF RFC Indicating User Agent 3840 Capabilities in SIP IETF RFC Caller Preferences for SIP 3841 IETF RFC DHCP for IPv4 Option for SIP 3361 Servers UPnP UpnP Device UpnP Device Architecture ISO/I Architecture Version 1.1 EC Version 1.1 29341 UPnP Device UPnP Device Control Protocols At the moment of Control (DCPs) writing, there are 23 Protocols different DCPs standardized for 9 device categories and 4 categories of add on services Microsoft Microsoft Network File System, Rally, P&P Protocols & DPWS, extensions of Internet Platforms Explorer, etc. Apple P&P Apple’s Bonjour, Mobile Me, Apps, … Protocols & Platforms Google Google Chrome specifics, Android Apps, Platforms Platforms … KNX CENELEC Home and Building Electronic ISO/I EN 50090 Systems (HBES) EC 14543 3, CEN 13321 1 CEN 13321 2 Open Data Communication in Building automation, Controls and Building Management Home and Building Electronic Systems Part 2: KNXnet/IP Communication Femtocell 3GPP ETSI 3GPP femtocells. TS 122 120, 125 367, 125 467, 125 469, 132 (581 584) (Home Node B) IMS 3GPP TS 3rd Generation Partnership 98 23.228 v9.2.0 Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 9) 3GPP TS 3GPP TS 21.202 V8.2.0 (2009 There are many 3GPP draft 21.202 12) Technical Specification 3rd and ETSI TISPAN Generation Partnership Project; standards building the Technical Specification Group IMS eco system. This Services and System Aspects; document lists them Technical Specifications and for Release 8. Technical Reports relating to the Development of Common IP Multimedia Release 9 has just Subsystem (IMS) (Release 8) started, and such a mapping table does not exist yet. W3C XML 1.1 Extensible Markup Language (XML) 1.1 (Second Edition) VoiceXML2.1 Voice Extensible Markup The W3C's standard Language (VoiceXML) 2.1 XML format for specifying interactive voice dialogues between a human and a computer Xhtml 1.0 Xhtml 1.0: Extensible HyperText Markup Language 1.0 CEA 2014 A A Web based Protocol and Framework for Remote User Interface on UPnP™ Networks and the Internet (Web4CE) HTML4.01 HTML 4.01 Specification, Since 1999. Soon to HyperText Markup be superseded by HTLM 5 Language PUCC PUCC Ver 1.0 P2P Universal Computing P2P network, mobile Consortium Ver 1.0 Technical integration, overlay specification. network protocols, and application/service integration. Interoperability with UPnP, ECHONET and IEEE1394 defined in the standard USB USB 2.0, Universal Serial Bus A specification to USB 3.0, establish Wireless USB communication between devices and a host controller (usually a PC). DLNA DLNA Digital Living Network Alliance Cross device interface Networked for systems like smart Device house, and other Interoperabilit content y Guidelines transformation and August 2009 redirection applications. DVB ETSI TS 102 Transport of MPEG 2 TS Based 034 V1.4.1 DVB Services over IP Based and TS 102 Networks (and associated XML) 826 V1.2.1 and DVB IPTV Profiles 99 ETSI TS 102 Architectural Framework for the 033 V1.1.1 Delivery of DVB Services over IP based Networks TS 102 905 DVB HN (Home Network) Defines mapping with V1.1.1 Reference Model Phase 1 UPnP TS 102 685 High level Technical draft V1.1.1 Requirements for QoS for DVB Services in the Home Network ETSI EN 300 Digital Video Broadcasting 468 V1.11.1 (DVB): Specification for Service Information (SI) in DVB systems ETSI EN 301 Digital Video Broadcasting 192 V1.4.2 (DVB): Specification for data broadcasting ETSI TS 102 Digital Video Broadcasting 727 v.1.1.1 (DVB); Multimedia Home Platform (MHP) specification 1.2.2 (DVB MHP) ETSI TS 102 Digital Video Broadcasting 728 v.1.1.1 (DVB); Globally Executable MHP (GEM) Specification 1.2.2 (including IPTV) OCAP 2.0 Open Cable Application Platform Based on GEM v 2.0 ETSI TS 102 Digital Video Broadcasting 824 V1.2.1) (DVB); Remote Management and Firmware Update System for DVB IP Services TS 102 005 Digital Video Broadcasting V1.4.1 (DVB); Specification for the use of Video and Audio Coding in DVB services delivered directly over IP protocols TS 102 825 Digital Video Broadcasting V1.1.1 (DVB); Content Protection and Copy Management Specification; OSGi OSGi Service OSGi Service Platform Release 4, module system and Platform V4.2 service platform for Release 4, the Java programming V4.2 language that implements a dynamic component model ISO/IEC ISO/IEC Information technology: Generic Provides architects, 15018 15018:2004 Cabling for Homes building owners and and Amd installers with more 1 :2009. certainty for the planning of multimedia home cabling. EN 50173 EN Information technology. Generic Structured cabling ISO/I 50173:2007 cabling systems systems for general EC purpose 11801 telecommunications including analogue and ISDN telephony, various data communications standards, building control systems and factory automation.. DECT ETSI EN 300 Digital Enhanced Cordless There is a whole 175 1 Telecommunications (DECT); range of ENs related 100 Ver.2.2.1 Common Interface (CI); Part 1: to DECT. EN 300 Overview. 175is the base standard ETSI EN 300 DECT; Common Interface (CI); 175 2 Ver. Part 2: Physical Layer (PHL). 1.4.2 draft ETSI EN 300 DECT; Common Interface (CI); 175 3 Ver. Part 3: Medium Access Control 1.4.2 (MAC) Layer. ETSI EN 300 DECT; Common Interface (CI); 175 4 Part 4: Data Link Control (DLC) Layer. ETSI EN 300 DECT; Common Interface (CI); 175 5 Part 5: Network (NWK) Layer. ETSI EN 300 Digital Enhanced Cordless 444 Ver. 1.4.2 Telecommunications (DECT) Generic Access Profile (GAP) ETSI EN 300 Digital Enhanced Cordless 175 and Telecommunications (DECT); related Common Interface (CI); (European standard) ETSI TS 102 Digital Enhanced Cordless IP over DECT: 527 (NG Telecommunications(DECT); Combination of DECT / Cat New Generation DECT; DECT and DPRS plus iq) Overview and Requirements. extension ETSI EN 301 Digital Enhanced Cordless 650 Ver. 1.2.1 Telecommunications (DECT); multiple access profile (DAMP); Application specific access profile (ASAP); TR 069 TR 069 Broadband Forum: CPE WAN . Amendment 2 Management Protocol v1.1 (CWMP) TR 181 Issue Device Data Model for TR 069 2 TR 157 Component Objects for CWMP Amendment 2 TR 106 Data Model Template for TR Amendment 4 069 Enabled Devices TR 140 TR 069 Data Model for Storage Amendment 1 Service Enabled Devices TR 142 Issue Framework for TR 069 enabled 2 PON Devices TR 196 Femto Access Point Service Data Model TR 135 http://www.broadband forum.org/technical/downloa d/TR 135.pdf Data Model for TR 069 Enabled STB TR 104 Provisioning Parameters for VoIP CPE TR 124 Issue Functional Requirements for 2 Broadband Residential Gateway Devices ITU T ITU T H610 Full Service VDSL – System H.610 architecture and customer premises equipment Wifi IEEE 802.11 Local and metropolitan area IEEE 802.11 a,b,g. ISO/I 2007 networks Specific requirements Not all parts of the EC Part 11: WLAN MAC and PHY standard are relevant 8802 specifications for SmartHouse 11 IEEE 802.11n 101 IEEE Modified PHY and MAC to 60GHz 802.11ad enable very high throughput operation at 60 GHz Wi Fi Wi Fi Alliance: Wi Fi Protected Push button Protected Setup Specification 1.0 authentication, a.o. Setup draft Specification 1.0 WMM Wi Fi Alliance: WMM QoS based on IEEE Specification Specification v1.1 802.11e a.o. v1.1 Wi Fi Peer to Wi Fi Alliance: Wi Fi Peer to Mesh networking of Peer (P2P) Peer (P2P) Specification v1.1 Wi Fi devices Specification v1.1 Ethernet IEEE 802.3 Local and metropolitan area Includes all older ISO/I 2008 networks Specific requirements Ethernet standards, EC Part 3: CSMA/CD access including GBE, 8802 method and PHY specifications optical, VLAN… 3 IEEE Std. IEEE Standards for Local and 802.1Q 2003 Metropolitan Area Networks : Virtual Bridged LANs ISO/IEC Information technology – IEEE 8802 2 Telecommunications and 802.2 information exchange between systems Local and metropolitan area networks Specific requirements Part 2: Logical link control ISO/IEC Information technology – IEEE 8802 6 Telecommunications and 802.6 information exchange between systems Local and metropolitan area networks Specific Requirements Part 6: Distributed Queue Dual Bus (DQDB) Access method and PHY specifications IEEE 802.1X Standard for port based Network Also suited for Wi Fi, 2010 Access Control (PNAC) but mostly used for enterprise ethernet networks FireWire IEEE 1394 A high performance serial bus 2008 ETSI HF EG 202 116 Human Factors (HF); Guidelines V1.2.2 for ICT products and services; "Design for All" EG 202 191 Human Factors (HF); Multimodal V1.1.1 interaction, communication and navigation guidelines EG 202 132 Human Factors (HF); User Ver. 1.1.1 Interfaces; Guidelines for generic user interface elements for mobile terminals and services EG 202 325 Human Factors (HF); User Profile V1.1.1 Management ES 202 975 Human Factors (HF); V1.2.1 Harmonized Relay Services ES 202 076 Human Factors (HF); User V2.1.1 Interfaces; Generic spoken command vocabulary for ICT devices and services ISO 16071 Human – computer interfaces 102 (Ergonomics of human system interaction) HGI HGI RD001 Home Gateway Technical R2.01 plus Requirements: Residential Profile additional V1.01 Release 2 and draft Release 3 standards UWB WiMedia WiMedia MAC PHY Interface UWB middleware, ECM MAC PHY 1.5 wireless USB A 369, Interface 1.5 ISO/I EC 26908 WiMedia WiMedia MAC Specification 1.5; ECM MAC WiMedia PHY Specification 1.5 A 368, Specification ISO/I 1.5; WiMedia EC PHY 26907 Specification 1.5 Zigbee Zigbee Zigbee Specification ZigBee Specification Document 053474r17 ZigBee ZigBee RF4CE specification. For RF remote RF4CE controls specification. IEEE Wireless Medium Access Control 802.15.4 (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs) 6LowPAN RFC 4944 Transmission of IPv6 packets over IEEE802.15.4 Networks Bluetooth Bluetooth 1.2 Bluetooth 1.2 Backwards compatible with 1.1 Bluetooth Bluetooth 2.1+EDR Enhanced Data Rate 2.1+EDR for faster data transfer Bluetooth Bluetooth 3.0+HS Theoretical data 3.0+HS speeds of up to 24Mb/s IEEE Wireless MAC and PHY Phy and MAC of 802.15.1 Specifications for Wireless Bluetooth 1.2 Personal Area Networks (WPANs) HomePNA HomePNA Phoneline networking G.995 3.1 transceivers Enhanced physical, 4 media access, and link layer specifications HomePlug HomePlug HomePlug Audio/Vido Power line alliance AV (networking over power lines) HomePlug GP HomePlug Green PHY (GP) Medium bit rate for smart grid applications IEEE 1901 Standard for Broadband over Combination of 2010 Power Line Networks: Medium HomePlug AV and Access Control and Physical Panasonic PLC. Layer Specifications ETSI NGN ETSI TR 102 ETSI Next Generation Home HAN 160 1 Network family: Home networking, home access network technology, home network application, security, copyright, QoS, etc. (2002) 103 ETSI TR 102 NGN, Home Area Networks, 160 2 1 Access Network: Compatibility of Analogue/ISDN TE ETSI TR 102 NGN, Home Area Networks, 160 2 2 Access Network: Home networking technologies draft ETSI TR 102 NGN, Home Area Networks, 160 3 Access Network: Applications and Services ETSI TR 102 NGN, Home Area Networks, 160 4 Ver. Access Network: Residential 0.0.1 gateway specifications ETSI TR 102 NGN, Home Area Networks, 160 5 Ver. Access Network: Access network 0.0.4 technologies ETSI TR 102 NGN, Home Area Networks, 160 6 Ver. Access Network: Security and 1.1.1 Copyright issues ETSI TR 102 NGN, Home Area Networks, 160 7 Ver. Access Network: End End QoS 0.1.1 ETSI ETSI ES 282 NGN Functional Architecture TISPAN 001 Release for TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) ETSI ES 283 Telecommunications and Internet 003 converged Services and Protocols for Advanced Networking (TISPAN); Network Attachment Sub System (NASS); e4 interface based on the DIAMETER protocol ETSI TS 182 TISPAN: NGN architecture to 009 support emergency communication from citizen for authority ETSI TS 183 TISPAN: PSTN/ISDN simulation 007 services; Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification NGN OIP/OIR ETSI TS 183 TISPAN: PSTN/ISDN simulation 008 services; Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR); Protocol specification NGN TIP/TIR ETSI TS 183 TISPAN: PSTN/ISDN simulation 011 services: Anonymous Communication Rejection (ACR) and Communication Barring (CB); Protocol specification NGN ACR & CB ETSI TS 183 TISPAN: PSTN/ISDN simulation 006 services; Message Waiting Indication (MWI): Protocol specification NGN MWI ETSI TS 183 TISPAN: PSTN/ISDN simulation 005 services: Conference (CONF); Protocol specification NGN 104 CONF ETSI TS 183 TISPAN: PSTN/ISDN simulation 016 services; Malicious Communication Identification (MCID); Protocol specification NGN MCID draft ETSI TS 183 TISPAN : CCBS, CCNR Stage 3 042 ETSI TS 183 TISPAN: PSTN/ISDN simulation 029 services: Explicit Communication Transfer (ECT); Protocol specification NGN ECT ETSI TS 183 TISPAN : AOC 047 EN 383 001 TISPAN, SIP, BICC, ISUP Ver. 1.1.1 Lon EN 14908 3 Energy performance in building LonTa automation, controls and lk, management (Open Data ANSI Communication in Building 709.1 Automation, Controls and / CEA Building Management – Control 709.1 Network Protocol – Part 3: Power Line Channel Specification) EN 14908 4 Open Data Communication in Building Automation, Controls and Building Management – Control Network Protocol – Part 4: IP Communication Home IEC TR Home server conceptual model Server 62318 for multimedia systems IEC TR Model and framework for 61998 standardization in multimedia equipment and systems IEC TR Multimedia data storage : 62291 Application program interface for UDF based file systems IEC 60581 High Fidelity Audio Equipment (all parts) and Systems IEC 61925 Multimedia systems and equipment: Multimedia home server systems vocabulary of home server IEC 62328 Multimedia home server systems – Interchangeable volume/file structure adaptation for broadcasting receivers IEC 62251 Multimedia systems and equipment: Quality assessment of Audio Video communication systems NFC ISO/IEC Information technology – It specifies the ECM 18092 Telecommunications and interface and protocol A 340 information exchange between for simple wireless systems – Near Field communication Communication – Interface and between close Protocol (NFCIP 1) coupled devices with transfer rates of 106, 212, and 424 kbps. Moca MoCA 1.0 Multimedia over CoAx 1.0 Home networking MAC/PHY specification over in home coaxial cable, commonly used for antenna 105 connections to TVs and radios, and cable TV (Multimedia Over Coax Alliance) MoCA 1.1 Multimedia over CoAx 1.1 !75 Mbps and QoS extension to MoCA 1.0 addition draft OpenIPTV OIPF Release OpenIPTV Forum Release 2 specifications for an 2 end to end platform for the deployment of IPTV Services RFID EPCGlobal Development of industry driven standards for the Electronic Product Code™ (EPC) to support the use of Radio Frequency Identification (RFID). There are different ISO/IEC standards available for RFID, but EPCGlobal seems to have most of the traction OpenTherm The OpenTherm Communications A protocol used in Protocol: A Point to point central heating Communications System for systems between a HVAC Controls Protocol central heating boiler specification and a thermostat or controller. Insteon Insteon Insteon Next, compatible version of X 10. Z wave Z wave Z wave Wireless Home control systems. Proprietary de facto standard EN 61508 Functional safety of electrical/electronic/programmabl e electronic safety related systems EN 60335 EN 60335 Specification for safety of household and similar electrical appliances G.hn ITU G.9960 Next generation home networking Phy of G.hn transceivers ITU G.9961 Data link layer (DLL) for unified DLL of G.hn high speed wire line based home networking transceivers ITU G.9972 Coexistence mechanism for Also known as G.cx wireline home networking transceivers IEC 62045 IEC Multimedia Security Guideline TS 62045 1 for privacy protection of equipment and systems in use and disused ISO 18012 ISO 18012 1 Home electronic system: 1 Guidelines for product interoperability Continua Continua To improve the quality of e health design Version 2010 personal health care guidelines Design Guidelines HDMI HDMI 1.4 High definition Multimedia a compact interface Specification Ver.1.4 audio/video interface 106 for transmitting uncompressed digital data WHDI WHDI Wireless High Definition enables wireless interface Interface uncompressed HD specifications video delivery draft throughout the home. Wireless ECMA 387 High Rate 60 GHz PHY, MAC 60 GHz phy and mac HD and HDMI PAL for wireless HD. A specification for the next generation wireless digital network interface for wireless high definition signal transmission for consumer electronics products CIM IEC 61970 3 Energy management system An Ecosystem related application program interface to electricity (EMS API) Part 3: Common distribution systems Information Model (CIM) that is increasingly looking to remotely interact with home automation. IEC 61334 IEC 61334 Distribution automation using Standards for plc/dlc distribution line carrier systems communication over Data communication protocols the power systems beyond the house DLMS/ IEC 62056 ( Electricity metering Data Device Language COSEM plus 62054 exchange for meter reading, tariff Message and 62052), and load control specification” a and EN generalised concept 13757 1 for abstract modelling of communication entities. COSEM: “COmpanion Specification for Energy Metering” sets the rules, based on existing standards, for data exchange with energy meters.European standard for meter data communicatons – mostly relevant because of load control signals M bus EN 13757 2 Communication systems for and EN 13757 consists of remote reading of meters Part 2: a part “data Physical and link layer; exchange” , which is 13757 1, which is DLMS compliant. EN 13757 3 Communication systems for and EN 13757 consists of remote reading of meters Part 3: a part “data application layer; exchange” , which is 13757 1, which is DLMS compliant U SNAP USNAP Serial Utility Smart Network Access a solution that enables Interface Port, any Home Area Specification Network standard to use any vendor's Smart Meter as a 107 gateway into the home. HES ISO IEC TR Information technology – Home This document 15067 3 Electronic System (HES) defines a typical application model – Part 3: Model security system and of an energy management system describes the draft for HES communications services needed. A high level model for an energy management system using HES is presented . ISO/IEC A residential gateway model for 15045 Home Electronic Systems EN 50523 EN 50523 Household Appliances New standard – there 1:2009 interworking – Part 1: Functional is discussion about Specification combining it with 59/537/NP Guidelines for Networked Home Appliances from China EN 50523 Household appliances 2:2009 interworking Part 2: Data structures; IEC 61850 IEC 61850 Communication networks and standard for the systems in substations design of electrical substation automation. It defines abstract data models which can be mapped to a number of protocols. Mapping to Web Services is under development 1 108 D 1 Current initiatives D.1 2 Coordinating bodies draft 3 There are, have been, and will be many people active and creating new technologies for 4 the SmartHouse. Lack of innovation is not a matter of too little money pored in. It is 5 more a matter of diminishing marginal returns: the planning confidence of the end user 6 and his willingness to invest diminishes with increasing uncertainty about standards and 7 technology. Coordination of the current activities is therefore badly needed. In this 8 section we single out 5 bodies that try to pertain such a role in the market. 9 10 ISO/IEC JTC 1 SC25 11 The scope of ISO/IEC JTC 1 SC25 is standardization of microprocessor systems; and 12 of interfaces, protocols and associated interconnecting media for information 13 technology equipment, generally for commercial and residential environments, for 14 embedded and distributed computing environments, storage systems, and other 15 input/output components. Development of standards for telecommunication networks 16 and interfaces to telecommunication networks is excluded. 17 18 HGI 19 The HGI, founded in 2004 by major broadband service providers (BSPs), and joined by 20 leading vendors of digital home equipment, is shaping the way that IP services are 21 delivered to the home. The HGI publishes requirements for digital home building 22 blocks. Those building blocks are the hardware and software in the digital home that 23 connect consumers and services. They include home gateways, home networks, and 24 home network devices. HGI projects are triggered by the services vision of their BSP 25 members, and build on the technical collaboration of all the HGI participants. The HGI 26 welcomes BSPs and vendors from across the globe. Their members represent the entire 27 spectrum of players in the broadband home area. 28 29 ATIS HNET 30 The ATIS Home Networking (HNET) Forum was established in February 2009 to 31 enable the interoperability, interconnection, and implementation of IP based home 32 networking systems/services, by proactively examining technologies and services and 33 developing solutions supporting the rollout of these technologies and services, when 34 appropriate. This forum will place an emphasis on ATIS member company needs in 35 coordination with other regional and international standards development organizations. 36 The objectives of the HNET Forum are to: 37 • Take a leadership role in home networking; 38 • Become the de facto industry group for home networking standards; 39 • Centralize disparate technologies that are used in the home network; 40 • Prevent overlap in standards development by engaging other SDOs; 41 • Lastly, develop and recommend specifications or technical requirements as 42 appropriate to bridge existing gaps that cannot be filled by other organizations. 43 44 ITU T JCA HN 45 In March 2005, the ITU T established a Joint Coordination Activity on Home 46 Networking (JCA HN). The scope of this JCA is the co ordination of Home 47 Networking standardization work both inside and outside of the ITU T. The objectives 48 are: 109 1 • The JCA HN will stimulate the progression of management standardization 2 work in a well coordinated way. 3 • The JCA HN will facilitate work assignments among the involved Study 4 Groups and co ordination among other relevant SDOs/fora when it is not clear draft5 where the work should be carried out and recommend an allocation of tasks. 6 • The JCA HN will identify areas of duplication and facilitate harmonization of 7 the related specifications and identify areas where specifications are needed. To 8 support these activities, the JCA HN will actively manage the harmonization 9 and/or development of said specifications in the relevant ITU T SGs and 10 SDOs/fora by closely working with them and tracking their results. 11 • The JCA HN will act as a point of contact within ITU T and with other 12 SDOs/fora to support Home Networking specification co ordination, 13 harmonization, and generation. 14 • In carrying out the JCA HN’s internal co ordination role, participants in the 15 JCA HN will include representatives of relevant ITU T Study Groups and 16 other ITU groups. 17 • In carrying out the JCA HN’s external co ordination role, representatives from 18 other relevant SDOs/fora and regional/national organizations will be invited to 19 join the JCA HN. 20 21 CENELEC SmartHouse 22 SmartHouse is part of the ICT Horizontal Area of CENELEC. The overall objective of 23 the SmartHouse project is to grow and sustain convergence and interoperability of 24 systems, services and devices for the SmartHouse that will provide the European 25 Citizen with access to increased functionality, accessibility, reliability and security that 26 a SmartHouse, with common and open architectures, will deliver in an expanding 27 broadband infrastructure throughout Europe. Since 2001, the European Committee for 28 Electrotechnical Standardization (CENELEC) and the European Commission DG 29 ENTR have been working together to develop understanding of requirements for the 30 SmartHouse and have recently completed work on a Code of Practice for SmartHouse 31 operation. The SmartHouse Standardisation Initiative aims to support initiatives 32 ensuring that Service Providers, Government, Health, Learning and local community 33 Services can interact with all the citizens of the EU. They will then be confident that 34 their systems are communicating into homes with networks, systems and equipment 35 that are constructed, installed and set up to known standards, are interoperable and 36 interactive and will deliver predictable information and receive intelligible responses 37 from any home in the EU. It is the contention of the SmartHouse Standardisation 38 Initiative that while currently the majority of connected (to the Internet with or without 39 broadband) citizens are reasonably well informed and can manage the multiple 40 inconsistencies and incompatibilities of current services and broadband delivery, when 41 the objectives of eEurope i2010 and beyond are achieved, every citizen will have access 42 to a range of Broadband services and applications. Of these, many will be uninformed, 43 many will be in demographic groups that find the use of new systems non intuitive, 44 many will be disadvantaged by disability, poor health, poor education and by old age. 45 One of the objectives of SmartHouse is to make the new technology of the connected 46 home accessible to all. 47 D.2 48 Relevant European R&D projects 49 Some relevant European R&D projects currently aiming at creating and improving 50 SmartHouse standards are the following: 110 1 OPEN Meter 2 3 The main objective of the OPEN meter project is to specify a comprehensive set of 4 open and public standards for AMI, supporting electricity, gas, water and heat metering, draft5 based on the agreement of all the relevant stakeholders in this area, and taking into 6 account the real conditions of the utility networks so as to allow for full 7 implementation. 8 9 The Scope of the project is to address knowledge gaps for the adoption of open 10 standards for smart multi metering equipments and all relevant aspects – regulatory 11 environments, smart metering functions, communication media, protocols, and data 12 formats – are considered within the project. 13 14 The result of the project will be a set of draft standards, based on already existing and 15 accepted standards wherever possible. These standards include the IEC 61334 series 16 PLC standards, the IEC 62056 DLMS/COSEM standards for electricity metering, the 17 EN 13757 series of standards for utility metering other than electricity using M Bus and 18 other media. These existing standards will be complemented with new standards, based 19 on innovative solutions developed within the project, to form the new body of AM / 20 smart metering standards. The resulting draft standards will be fed into the European 21 and International standardization process. 22 23 The project is strongly coordinated with the smart metering standardisation mandate 24 given by the European Commission to the European Standardization Organizations, 25 CEN, CENELEC and ETSI. 26 27 The project should remove a perceived barrier to the wide scale adoption of smart 28 metering in Europe, by ensuring that the requirements for smart metering can be met by 29 products and systems based on open, international standards to ensure interoperability, 30 and which are accepted and supported by the widest possible circle of stakeholders. 31 32 The OPEN meter project is financed by the European Commission within the Seventh 33 Framework Programme, Area 7/1: Smart Energy Networks / Interactive distribution 34 energy networks, Topic 7/1/1: Open-Access Standard for Smart Multi- Metering 35 Services . 36 37 ICT ALPHA 38 39 The ALPHA project addresses the challenges of building the future access and all types 40 of in building networks for home and office environments. The project supports the 41 evolution towards a cognitive network by dynamically utilising the resources of an 42 optical network infrastructure to support a heterogeneous environment of wired and 43 wireless technologies. 44 45 The project investigates innovative architectural and transmission solutions based on 46 the manifold of optical fibres (single , multi mode and plastic) as well as wireless 47 technology to support both wired and wireless services in a converged network 48 infrastructure. The focus is on using the newest physical layer achievements and 49 adequate management and control algorithms to reach a yet unprecedented end to end 50 provisioned capacity for access and in building networks at a fraction of the price of 111 1 today’s technologies and to simultaneously include the transport of existing 2G/3G and 2 Beyond 3G (B3G) signals whether they are Internet Protocol (IP) or non IP based. 3 4 The project starts with analysing the potential future bandwidth and quality of service draft5 (QoS) requirements which can be posed by future services in the scope of access and in 6 building networks such as Ultra HD Video, Local Storage Area Network, remote 7 medical applications and others, and mapping those requirements into network 8 specifications. The questions on the best applicable media, necessity for optical layer 9 dynamics, compatibility of network types at the physical layer, foundations for better 10 QoS provisioning and embedding of 2G/3G and B3G signals into the networks are then 11 addressed within the project. 12 13 The project pursues experimental validations of close to maturity technologies in 14 laboratory tests and field trials by intensively exploiting the three project testbeds. The 15 project also includes long term research activities targeting to improve the existing 16 technologies, and follows an intensive dissemination and standardisation strategy 17 18 OMEGA 19 20 The OMEGA project will set a global standard for ultra broadband home area networks. 21 The new standard will enable transmission speeds of one gigabit per second (1 Gbps) 22 via heterogeneous communication technologies, including power line communications 23 and wireless connections. Thus, OMEGA aims to make home area networks as easy to 24 use as electricity from the socket, putting an end to the coverage limitations as well as 25 the wiring clutter in the home. 26 27 With OMEGA’s gigabit home network, users will get easy access to high bandwidth 28 information and communication services such as telepresence, 3D gaming, enhanced 29 interactivity, virtual reality, high definition video as well as e health applications and 30 services for the exchange of user generated business or multimedia content 31 32 The interdisciplinary project consortium consists of 20 European partners from industry 33 and academia. OMEGA is an Integrated Project in the ICT area co funded by the 34 European Commission under EU Framework Programme 7 (FP7). It is running for three 35 years from January 2008 to December 2010. 36 37 FIGARO Future Internet Gateway based Architecture of Residential networks 38 39 Future Internet services are rapidly moving towards an increasingly heterogeneous 40 landscape with end users capable of creating, storing and delivering content and 41 applications. To address this diversity FIGARO proposes an evolvable Future Internet 42 architecture based on gateway oriented federation of residential networks . The Internet 43 has evolved from a technology centric core networks to a user and content centric 44 scenario that must support millions of users creating and consuming a variety of content 45 and applications. It must be able to accommodate new services with diverse 46 requirements while coping with heterogeneous networks and systems. Through a strong 47 and committed industry driven consortium, FIGARO proposes a Future Internet 48 architecture that is structured around residential networks. In this architecture, federated 49 home gateways have a key role as integrator of different networks and services, and as a 50 coordinator of Internet wide distributed content management. As “always on” devices 51 interconnecting the residential networks with the Internet and responsible for 112 1 aggregating a multitude of devices and services, home gateways become essential 2 components for an efficient management of physical resources and applications. By 3 building on an experimental approach that includes testbed prototyping of solution, 4 FIGARO will deliver: draft5 • The design of a novel content management architecture that enables distributed 6 content backup, search and access. 7 • A network optimization framework, leveraging community networks and 8 heterogeneous networks. 9 • A network management architecture with new network monitoring and real 10 time troubleshooting techniques. 11 • A deeper understanding of novel Internet based communication and service 12 solutions for emerging sectors, such as energy management and e health care. 13 Furthermore, the integration of new sectors into the future Internet will spur trans sector 14 innovation and create new businesses. Finally, FIGARO is expected to result in 15 technologies that will strengthen Europe’s position and give competitive advantage to 16 European industry in the areas of Future Internet technologies and services, residential 17 gateways and home automation. 113 • ITCP/IP, Wi-Fi, Ethernet, KNX enabled white goods and HVAC, Energy display, smart meters, PLC link from meter to WAN (see B2) • IEC 61850 compliant DER, 2.5/3G link to Decentralized Energy Resource (DER) • John has a PV panel on his roof. • DER is managed by an aggregator, DM contract with Supplier, • John has no involvement in PLC or 2.5/3G link to DER, John contracts with: broadband provider, energy Supplier, energy aggregator • John allows remote control and monitoring of DER, white goods and HVAC subject to DM contract (see B2) • John allows remote control of home appliances and DER equipment provided that he has power to over ride control • The aggregator can monitor the pv panel remotely and send messages to the energy 6 display in the house 7