SA/CLC/ENTR/000/2008-20
Production of a Roadmap for an integrated set of standards for SmartHouse and systems related to it and an Open Event
Final Report
CENELEC - The European Committee for Electrotechnical Standardization
This CENELEC Project Report SmartHouse Roadmap has been drafted by a project team and steering group of representatives of interested parties and was approved and endorsed on 9 February 2011 at an Open Enquiry meeting in Brussels. Neither the national members of CENELEC nor the CENELEC Central Secretariat can be held accountable for the 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 electro-technical 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.
Contents
List of Figures and Tables ...... 5
Foreword ...... 6
Grant Agreement, Steering Group and Project Team ...... 7
1. Introduction ...... 8 1.1 Motivation ...... 8 1.2 Purpose, scope and objective ...... 9 1.3 Document structure ...... 9
2 Analysis ...... 11 2.1 Technical, commercial, and deployment requirements for the SmartHouse ..... 11 2.2 Convergence and interoperability ...... 13 2.3 Problem Space: Application Domains, Ecosystems ...... 15 2.4 Challenge ...... 18 2.5 Project vision summary: overview of observations and assumptions ...... 19
3 Approach ...... 23 3.1 Starting point of the project approach: convergence and migration ...... 23 3.2 Project approach: overview ...... 23 3.3 Stakeholder Requirements: Use Cases ...... 25 3.4 Selection and analysis of a representative set of Ecosystem standards...... 26 3.5 SHR Reference Model (SHR-RM) ...... 26 3.6 Interoperability considerations ...... 29
4 Results ...... 31 4.1 Use cases ...... 31 4.2 Ecosystems ...... 31 4.3 Taxonomy ...... 32 4.4 Interoperability Profiles ...... 36 4.5 Solution Space...... 40
5 Summary and conclusions ...... 44
6 Recommendations ...... 46 6.1 Application Layer ...... 46 6.2 Communication layers ...... 47 6.3 Home Infrastructure ...... 47
References ...... 49
A Use Cases ...... 51 A.1 Template ...... 51 A.2 Intra-Ecosystem use cases ...... 53 A.3 Inter-Ecosystem convergence use cases ...... 64 A.4 Use cases for changing service providers ...... 75 B Acronyms ...... 85
C Long list of Smart House standards ...... 101
D Current initiatives ...... 115 D.1 Coordinating bodies ...... 115 D.2 Relevant European R&D projects ...... 117
E List of involved parties ...... 121
List of Figures and Tables
Figure 1 Convergence towards smart houses. Figure 2 An example of increased managerial hassle due to a proliferation of devices in the home. Figure 3 Flowchart of the SmartHouse Roadmap approach Figure 4 Reference model as used in ISO/IEC TR 29107 Figure 5 SmartHouse Roadmap Reference Model Figure 6 Service composition in SOA. The Service Consumer accesses a service, which under the hood is composed out of several generic Service Building Blocks (SBBs). Some SBBs may at the same time be used for other services. Figure 7 Generic object model of an Ecosystem Figure 8 Integrating multiple Ecosystems Figure 9 Integrating multiple Ecosystems
Table 1 The interoperability levels as identified in CWA IFRS [4]. The CWA defines conformity requirements only for levels 4-6 Table 2 Long-list of Ecosystems for the SmartHouse. Table 3 Short-list of Ecosystems, following from the use cases Table 4 Interoperability Profile for the SmartHouse Roadmap use case C-3 Table 5 Interoperability Profile for the SmartHouse Roadmap use case A-1 Table 6 Interoperability Profile for the SmartHouse Roadmap use case A-2 Table 7 Interoperability Profile for the SmartHouse Roadmap use case B-1 Table 8 object modelling paradigms Table 9 Who is interested in Interoperability?
Foreword
This report to EC/EFTA reflects the end results of the CENELEC Project SmartHouse Roadmap project. It has been prepared by the CENELEC Project Smart House Roadmap Project Team. A previous version has been reviewed by the project’s Steering Committee and was discussed in 2 plenary project meetings during 2010. The result was published on the Internet as draft document for open enquiry. Comments were discussed during the Open Enquiry meeting at 9 February 2011 in Brussels, After consensus was reached, the final report was endorsed by the meeting
The secretariat of the Project was held by NEC. Grant Agreement, Steering Group and Project Team
The ‘Production of a Roadmap for an integrated set of standards of SmartHouse and systems relating to it and an Open Event’ is funded under Grant Agreement SA/CLC/ENTR/000/2008-20 between CENELEC and the European Commission. The official starting date of the Grant Agreement has been January 1st, 2009. A call for experts regarding the establishment of the CENELEC Project SmartHouse Roadmap (SHR) Steering Group (SG) and Project Team (PT) was launched on April 28th, 2009. The Kick-Off meeting took place on 19th May 2009, and was attended by 26 participants.
Members of the SHR-SG: • Philippe Carpentier, Schneider Electric • Joost Demarest, KNX • Beatriz Novel, AFME • Mark Ossel, Echelon • Jean-Luc Detrez – Intel • Boudijn Uythof – Domotica Platform Nederland • Paolo Falcioni –CECED • Alan Knight-Scott, EDF • Walter von Pattay, ZVEI • Fred te Riet, ExperTel • Alain Lambert, LEGRAND (chairman)
4 SHR-PT Experts for a Paid Position for a totality of 96 person days: • Frank den Hartog, TNO (project editor) • John Parsons, BEAMA (expert editor) • Tom Suters, Suters Consultants Beheer BV (expert editor) • Josef Faller, HomeFibre Digital Network GMBH (expert editor)
The start-up of activities was set for 6 months after the date of signature, i.e. July 6th, 2009 by a first Face-to-Face Meeting between SHR-SG and SHR-PT. The first preliminary results are presented and discussed during a second Face-to- Face meeting which took place on September 21st 2009. A third Face-to-Face meeting, with 35 participants, took place at March 2nd 2010, and the final plenary meeting had 25 participants and took place at September 10th 2010. The draft final report was published in October 2010 and discussed at an Open Event on 9 February 2011, which attracted 76 attendants. They are included in the listed organizations which endorsed the CENELEC project SHR deliverables in Annex E. 1. Introduction
1.1 Motivation
There are many “independent” standards activities that cover aspects of the standardization of the SmartHouse. While all three primary European standardisation organizations (ESOs) already work together on the subject of SmartHouse this cooperation should be intensified and extended to also include relevant fora and consortia presently developing their own specifications. Additionally, there are a number of areas where standardization is required but is not being addressed. The need for work to complete a cohesive, integrated and interlocking set of SmartHouse Standards is clear. Appropriate and urgent measures are required from public and private policy and decision makers, in industry as well as governments, nationally as well as European.
Within residential premises, the SmartHouse Code of Practice [1] has already clearly shown that there are a great many organizations, “Technical Committees” and “Bodies”, working in the areas of standardization that are relevant to the SmartHouse. Unfortunately, coordination between them is weak and no coordinated output or integrated set of standards to support SmartHouse concepts is currently in process. The SmartHouse Code of Practice also showed that there is no structure for interoperability, architecture or common way to identify or describe systems, their components and how they interoperate in the SmartHouse. In addition there are a number of areas that will also be essential for the SmartHouse and these include Security (both physical and information), Management of Information, Energy Management, Wellbeing and Telecare and how such systems interact. The SmartHouse Code of Practice was published in 2005, and was the output of Phase II of the CENELEC SmartHouse horizontal activity. The SmartHouse Roadmap project, of which this report reflects the results, can loosely be seen as Phase III of this horizontal activity. It arose out of the SmartHouse Code of Practice, though it is not an enhancement or continuation of the same.
The SmartHouse Roadmap project responds to the section covering Horizontal Actions covering all Priority Domains of the 2008 ICT Standardisation Work Programme issued by the European Commission (CEU) [2]. The ESOs are invited to propose standardization related initiatives to further support the effective take up and implementation of standards in the priority domains listed by this Work Programme. These actions should cover awareness, promotion, information and education, as well as the implementation of pilot projects and interoperability testing.
The SmartHouse Roadmap project proposal is put forward to the Commission by CENELEC on behalf of NEC to identify the need for the future delivery of Standards in the area of the SmartHouse by the ESOs and the other stakeholders in the SmartHouse as identified by the SmartHouse Code of Practice. Because of its horizontal nature, the action will encompass areas of major importance in Europe such at Energy Management and Sustainability, and also the need to bring Healthcare and Telecare into the community – to people at home, going about their daily activities, who will also benefit from assisted living as they age. It especially shows what will be required to bring high level interoperability of services for people and applications in their homes.
1.2 Purpose, scope and objective
The purpose of the project is:
• to reflect a snapshot of the existing specifications and on-going initiatives in the SmartHouse field
• to collect and analyse the current and future needs of the consumer in respect of SmartHouse applications, services and planning confidence
• to recommend ways and means - for use by standardization bodies - to support competitive markets for equipment suppliers, system integrators and application and service providers (in particular highlighting overlaps and overcoming gaps)
The whole of snapshot, needs, and recommendations we call the SmartHouse Roadmap. The needs are represented by a collection of use cases from the industry and an overarching vision of the project team. The recommendations include an encouragement to use a tool developed by the project team to aid future standardization in the SmartHouse field.
The scope covered by the SmartHouse Roadmap includes all systems, networks and management that enable applications and services to be provided by vendors and service providers of all kinds to consumers in their homes anywhere in the European Union. As such, the Roadmap is focused on all standards for smart house devices including home (and home office) networks, home automation, and multi-media platforms, on associated services such as security, energy management and sustainability, health and tele-care, and includes applications for service providers of all types having particular relevance to the consumer in the provision of e-inclusion and accessibility. The Roadmap also includes some references to relevant areas which contribute to the overall goal of SmartHouse standardization.
The objective is to provide strategic direction and proposals for the standardization activities of the ESOs (ETSI, CEN and CENELEC), together with the many other bodies that are active in this space, to reflect properly the growth of the SmartHouse and all the services, applications, systems and networks associated with it, and to encourage future market growth. It is intended that all existing and any initiative or standardization work in the area are identified and, in this converging market, a co-ordination proposal be issued so that to the greatest extent existing and future work will deliver interoperable solutions for any “SmartHouse” service or application.
1.3 Document structure
This document is laid out as follows. In the following chapter a deeper analysis is given of the need for further standardization of the SmartHouse field and the role that our Roadmap should play in this. We, the project team, found that the core of our work should concern the enabling of interoperability between standards Ecosystems in order to react to the consumer’s demand for convergence of ICT and technology for CCCB (Control/Command Communications in Buildings) in the home. The Ecosystem of a standard is the core topic of our study and is defined as a group of interacting components that collectively perform the function of the standard. It, for instance, consists of the base standard of a protocol, but also test specifications, installation guidelines, safety requirements, certification programs, etc.
In chapter 3 the chosen approach is presented: we gathered use cases from the industry, deduced and classified the most relevant interoperability opportunities and issues, and designed a standards taxonomy. By plotting multiple standards on the taxonomy, it shows if interoperability between the multiple standards may be achievable and how. In chapter 4 we present our main result, i.e. the taxonomy. We also show how it works, by plotting the most relevant Ecosystems on it. They were derived from the use cases. Chapter 5 summarizes and concludes the main body of the report. It also describes briefly for which interoperability issues work is already underway. Chapter 6 gives the recommendations to the EC and the ESOs that follow from our work.
Furthermore, the report contains four annexes. The first one, Annex A, presents the use cases that led to the desired taxonomy and interoperability recommendations. Annex B is the glossary and list of abbreviations. For sake of readability we have not defined in-line every single abbreviation we used in the main text. For the meaning of any abbreviation which is not directly obvious we refer to Annex B. Annex C lists the standards and specifications that have been identified by the project team and the steering committee to be relevant for the Smart House, and useful to be classified with our taxonomy. Annex D gives a short overview of the current activities in Europe that aim to reach higher levels of interoperability in the SmartHouse.
2 Analysis
2.1 Technical, commercial, and deployment requirements for the SmartHouse
There are many (thousands) of standards and specifications that are relevant in one or another way for the home environment. Van der Kaa [3] counted 6,568 developed between 1996 and 2006 alone. And there are also many ways (tens) in which they can be classified. But not all standards, specifications, and taxonomies that exist for the home are relevant for the purpose of the project. The second and third purposes of the project (i.e. “to collect and analyse the current and future needs of the consumer” and “to recommend ways and means for use by standardization bodies to support competitive markets”) are therefore further detailed into technical, commercial, and deployment requirements that provide criteria for the selection of standards and taxonomies that are relevant.
The development of standards (sources and specifications) should not diverge but stimulate and support a competitive market of equipment suppliers, system integrators, application and service providers, and support the current and future needs (plug fast boxes, building blocks, easy configuring and control) of the customer. The Roadmap should be used by parties/ organizations with different roles in the market: • standardization bodies (sources and specifications) for development; • the SmartHouse value chain: service providers, device manufacturers, equipment suppliers, system integrators, application providers, construction companies, installation companies, etc. • any people interested in smart house service for their own home, to inform them about current and future possibilities, and to increase their planning confidence.
The first conclusion from this is that the Roadmap should not only consist of standards in the official meaning of the word, i.e. a technology, interface, test, requirement, etc. officially designated as a “standard” by an accredited standards development organization and openly available to the public. Many needs of the consumer and a competitive market are and can be served by more or less open specifications, often agreed upon by industry consortia and forums, but sometimes also closed proprietary specifications that have become a de facto standard. Throughout this document we therefore more broadly refer to a (relevant) “standard” as a technology, interface, test, requirement, etc. which is (or probably will be) on a large scale implemented and recognized by consumers and parties in the market. In our final recommendations we indicate which functionality, which may or may not exist already in the market today as a specification, need to be formally standardized in order to create a breakthrough in the SmartHouse market. The project does not recommend a single specification where there is competition in the market between specifications. However, if this competition is stifling market growth in the SmartHouse context, the project recommends development of standardization for the functions which are addressed by the specified technologies.
The technical requirements for the Roadmap that follow from the project’s purposes are: • Help manufacturers from industries to ship their products to a consumers home where they will be interoperable and provide services sharing resources by recommending a limited and helpful set of international (European) standards • Advise consumers who want to access services in- and outside the home on appropriate standards • Recommend a minimum of (existing) standards and specifications that fit in a common architecture providing seamless communication in and outside the home • Assure that standards reach a higher level of interoperability instead of the whole market having to move to one particular standard.
So, “interoperability” and “a common architecture enabling the sharing of resources in the home” have been found to be the guiding technical requirements that determine the choice of standards and taxonomies for our Roadmap. The interoperability requirement links this SmartHouse Roadmap project closely to the CENELEC Workshop 4 ‘An Interoperability Framework Requirements Specification for Services to the Home' (CLC WS 4 IFRS) and its recently published CWA [4].
The commercial requirements for the Roadmap that follow from the project’s purposes are: • Enable intra- and inter-domain applications & services, such as home automation, home appliances, entertainment, health/well-being, security, etc. • Support relevant existing Ecosystems. The Ecosystem of a standard is a group of interacting components that collectively perform the function of the standard. It, for instance, consists of the base standard of a protocol, but also test specifications, installation guidelines, safety requirements, certification programs, etc. • Support different business models for the different products: o Professional (b2b) and consumers (b2c) o Installers and retail/do-it-yourself (DIY), o Closed and open (3rd-party services) • Recommend ways for how installers or consumers can integrate different systems coming from different business models into one interoperable system. Said otherwise: support installers and consumers by providing them with a set of standards that interoperate. Industry may compete in the market with different systems based on different business models. But if industry chooses to cooperate, the Roadmap may help to realize interoperability. The differences in business model are relevant to the taxonomy of standards and the solutions we will propose.
The deployment requirements for the Roadmap that follow from the project’s purposes are • Allowing migration, innovation and change in technology, application domains, business models • Guarantee user experience within identified business models 2.2 Convergence and interoperability
Application domain is the first, obvious dimension for a taxonomy of SmartHouse standards. Traditionally, most specifications have been developed with a limited application domain in mind, such as: • Broadband communication services • Multimedia and Entertainment • Safety and Security • Home automation • Tele-care/health • Energy Management Services.
In early times, these domains were completely decoupled. This is schematically indicated in the left-hand side of Figure 1. A typical household in the nineties had white goods, brown goods, a gaming device, a fixed telephone, a thermostat and an electricity meter. These devices were not connected to a network, or to a stove-pipe delivery network of a service provider. The TV was only for entertainment and not for broadband communication or tele-care/health. Only intra-domain interoperability between standards and specifications was relevant, ensuring that TV’s from any manufacturer would perform consistently with a common signal. Each application domain has its own requirements and therefore its own solutions when it comes to home networking technology and standards. It should therefore not come as a surprise that within a home multiple incompatible “islands of connected devices” exist, each using their own domain specific and therefore, most of the time, different and incompatible home networking solutions.
Figure 1. Convergence towards smart houses.
However, times have changed and now a large drive for convergence is being observed, leading to an increased demand for inter-domain interoperability. This is indicated in the right-hand side of Figure 1. As services demand, devices communicate freely, robustly, and securely with each other and with any broadband access network via home gateways. In this way, the home is more and more becoming an integral part of the Internet or the Future Internet [5]. Devices and services are very personal, so which particular devices and services are actually present and interconnected can be very different for every house, whereas in the nineties there was much more uniformity. This fits in a more global trend of society migrating from the Industrial Era towards a global Information Society, in which the industry moves from mass production of goods to personalized service delivery.
The trend of convergence is the main cause for the need of an integral SmartHouse Roadmap. Most developers, integrators and regulators have an angle of view from a single domain, and lack the oversight over the other domains to make informed decisions towards convergence. However, it is the end user, and with him the service providers and regulators, who increasingly demands resources to collaborate and be shared, because he perceives added value from this. Especially energy management drives a strong need for interoperability from the viewpoint of a regulator. E.g. the same sensors can be used for multiple applications like security, energy management and lighting. The use cases we gathered show this clearly..
The vast majority of the European homes will have a broadband Internet connection during the implementation window of this Roadmap document (i.e. 2011-2016). Due to cost reductions it is becoming feasible to add smart functionality to more and more house system components. This will result in an increasing number of advanced connected devices in the SmartHouse that have capabilities, services, and content that users wish to share among other devices and services within or between Ecosystems.
This potential will be used for an increasing number of more or less intelligent applications within the SmartHouse. As well as lifestyle applications this also concerns sustainability and social applications, such as demand management and tele-care, respectively. These applications may require different solutions for control (by the end user) and security. It is known that consumers do not want a proliferation of dedicated remote control devices for these applications, i.e. one for every single new application. Without standardization, many devices (remote controls and others) will appear in the home that have (partially) the same function, but are allocated to a specific application. We also observe a proliferation of different wireless, wired, and no-new-wires communication networks appearing in current homes. Consumers would like to stop this proliferation because of the implied managerial hassle (see Figure 2) and co-existence problems.
Figure 2. An example of increased managerial hassle due to a proliferation of devices in the home.
Basically there are three types of benefits that follow from convergence: 1. Reduce deployment costs and increase sustainability by using each other’s infrastructure 2. Using generic infrastructures creates opportunities for additional intra- domain innovations 3. Using generic infrastructures may lead to opportunities for inter-domain innovations
In the current literature, inter-domain innovations are also often called trans- sector innovations [6]. The United States, Australia, New Zealand, Germany, Switzerland, Austria, and The Netherlands are seen as being front-runners in stimulating trans-sector innovation in the SmartHouse environment [7-10]. Outside the home context of the user, a typical example of a European trans-sector innovation is E-call [11].
One can easily see that inter-domain interoperability is still in its infancy, although on a national base there has been some progress for selected domains. This counts most notably for the broadband communications services domain, which is in itself already a converged domain of telecommunications and computer networks. Also, with the dawn of services such as IP TV, interactive TV and user- generated content (web 2.0), full convergence of the broadband communications services domain and the multimedia/entertainment domain can be expected in the short term. The properties of Internet technologies can be seen as the main technical enabler of this convergence. However, communication between domains is often limited by some industries that still tend to create stove-pipe ICT solutions, sometimes leading to poorly standardized, not-very-scalable, expensive and closed systems that have limited capabilities for interoperating with systems from other domains. The perceived lack of dependability and security of current Internet networks lie behind the design decisions of these systems.
This analysis supports the findings and conclusions given in the Digital Agenda for Europe 2010-2020 [12] published by the European Committee. The Digital Agenda says: “Europe does not yet reap the maximum benefit from interoperability. Weaknesses in standard-setting, public procurement and coordination between public authorities prevent digital services and devices used by Europeans from working together as well as they should. The Digital Agenda can only take off if its different parts and applications are interoperable and based on standards and open platforms. … The internet is the best example of the power of technical interoperability. Its open architecture gave interoperable devices and applications to billions around the world. But to reap the full benefits of ICT deployment interoperability between devices, applications, data repositories, services and networks must be further enhanced (ed. by): • Improving ICT standard-setting • Promoting better use of standards • Enhancing interoperability through coordination”
2.3 Problem Space: Application Domains, Ecosystems
2.3.1 What is the home network intended to do? The purpose of a home network differs per domain. In many cases the primary purpose of home networks is to connect devices in the home to an Access Network outside the home to get access to a Service. An Access Network is the part of a public network that connects a home or an end-user’s device to a Service provider. A Service is a specified set of user-information transfer capabilities provided to a group of users by a communications system. Examples are the coax cable in your home connecting the TV to the cable- or satellite broadcast network or the Ethernet cable or Wi-Fi network connecting all PCs in the home to the Internet. The same holds for smart metering and energy management domain where the primary goal of the utility company is collect data from multiple meters and to control appliances or energy generators in the home. These home networks are used as a point-to-(multi)point extension of the Access Network, as part of a vertical service delivery pipe. They are not primarily intended to enable devices in the home (whether in the same domain, let alone across domains) to communicate directly with each other.
Home Automation networks usually support both device-to-device and Access Network communication. They allow devices to communicate directly with each other (e.g. the thermostat to the HVAC system) as well as to connect to an Access Network (e.g. the security camera to the Internet).
So called Peripheral Networks support direct device-to-device communication in the home but only as a way to connect peripherals to a “master device”. Well known examples here are SCART or (wireless) HDMI to connect a DVD/BD or HDD player/recorders to a TV or USB to connect a mouse, keyboard, webcams, printers etc. to a PC. Communication only takes place between the master device (the TV or PC) and its peripherals, not between peripherals directly. An important category of peripheral devices are the well-known remote controls using Infrared or RF networks. So far however they usually only control one device and they are brand specific. For the SmartHouse Roadmap (SHR) having a good solution for controllers that enable users to control all kinds of devices from different domains is an essential element.
The “PC network” was from the very beginning invented to share PCs, storage and printers in the home as well as connect them to the Internet. It is also in this domain that it has become more and more customary to connect devices from the broadcast domain like the TV, the mobile phone, and mobile AV players to this PC network, turning it into a true home AV network. Since this home AV network evolved from the PC network that itself evolved from the Internet connection, it is no wonder that the PC and home AV network are all based on Ethernet, WiFi, IP and other protocols standardized by IEEE 802 Working Group, WiFi Alliance, IETF and W3C.
2.3.2 Quality of Service Home networks belonging to different domains have different characteristics when it comes to Quality of Service. Therefore home networks in different domains are not only different but were simply never intended or designed to be shared in the first place and are therefore sometimes even physically separated. The best example here is the Ethernet cable connecting a cable modem to a Set Top Box (STB) for digital TV distribution and a second Ethernet cable connecting the same cable modem to your home AV Network to share media as well as Internet access. It should be noted that the Internet connection of a modern Internet-TV is still separated from the network that connects the STB to the Access Network.
Aggregation of traffic of the TV and Internet domains occurs in the Home Gateway (in this case the cable modem) and in the shared Access Network where it can be properly managed. Digital TV Providers simply do not want to share “their home network” with devices and traffic they cannot control if it endangers their service. Only if there is a strong use case with added value for their viewers, or if they are forced by competition (Internet-TV) or regulation might they be willing to reconsider.
2.3.3 Security The same as in the previous section can be said about security. Home networks belonging to different domains have different characteristics when it comes to the implementation of network and data security. They were never intended or designed to be shared in the first place, and their obvious physical separation is an inherent part of the security provided. In the case of home security services, the need to ensure communications integrity has led security service providers to keep their networks completely separated from other applications. Although there may be a strong use case that shows the added value of interconnecting these domains, the lack of an overarching security architecture guaranteeing end-to-end security is a significant barrier for even trying.
2.3.4 Market Penetration There are also big differences between domains in their market penetration of home networks and therefore the number of devices as well as “infrastructure” that exist in homes today that support a specific domain. We refer to the many reports published and updated regularly by market research companies such as Forrester Research, Parks Associates, ABI Research, and Frost & Sullivan, but also to the statistics gathered and published by the Organisation for Economic Co- operation and Development (OECD, see Broadband Portal). The following observations can be made with respect to market penetration: • The penetration of broadband access is nearing 100%. At the end of 2009, about 80% of the homes in Scandinavian countries were connected, and more than 50% in most of the rest of Europe. More than 50% of the connected households have a broadband data network in the home, and most of them contain Wifi. • A significant amount of devices in the home support DLNA, such as Network Attached Storages, PCs, TVs, smart phones, and media players. Also Microsoft’s Operating System Windows 7 and many of the TVs sold today support the DLNA protocol suite. However, a clear standard for application support by TVs does not yet exist. • The market penetration of mobile phones is 100%. The market share of Internet-enabled browser-based smart phones is expected to grow over 50% in 2011, although there is strong competition between various non- interoperable operating systems for smart phones. All mobile phones support Bluetooth and all smart phone support Wifi in addition. In The Netherlands, about 80% of the homes have a DECT cordless phone, and we expect similar penetration elsewhere in Europe. • In the US, about 10% of the households have some form of home automation (or home control). While the European average is expected to be about the same some countries already do better. The market seems to be growing with new applications such as energy management becoming popular. The technology space is characterized by many (recently standardized) Ecosystems as well as proprietary technologies. 2.3.5 Industry Standards & Ecosystems It is important to note that in the past two decades, industry standards have become more and more important. Well known examples are the IETF and W3C standards for Internet and IEEE 802 and Wi-Fi as the home network solution for wireless Internet access. These industry standards have become very successful in terms of deployment and market success in a very short period of time. The main reason for this success is: • The Internet revolution as the single driving use case • The need to make Internet available on many different devices in the home • The desire not having to wire the home to connect all these devices to the broadband network in existing homes (for newly built homes or home to be retrofitted this is less of an issue) • Groups of industry leaders forming alliances representing complete Ecosystems of device manufacturers and technology suppliers willing to invest and to create new big markets compared to proprietary solutions. • A joint effort by these Ecosystems to create interoperability specifications. These specifications are usually subsequently offered to official standards bodies like ISO/IEC. ETSI, CEN/CENELEC for official standardization. • Certification and logo-ing programs to guarantee interoperability and recognition. • Joint marketing programs to explain the logoed technologies to the public.
Examples of other successful, European Ecosystems are DECT for cordless telephones in the home and Bluetooth as a peripheral network for mobile phones to connect headsets and to exchange audio, calendars and media (images, videos and music) with the PC and other phones. However, the quality of the guidance provided by the logos of these ecosystems is very different: some guarantee full interoperability, while others only allow only coexistence or sharing of a resource. As a result two devices with the same logo may or may not be interoperable. Similar issues are observed in Ecosystems like DLNA (sharing home AV media) and KNX (home automation).
2.4 Challenge
The challenge of the SmartHouse Roadmap project is to create a result from which guidelines and recommendations can be deduced which help the market in designing and deploying inter-domain systems that drive costs down and stimulate intra- as well as trans-sector innovation. In this way, the home of the user becomes really smart in terms of the user’s needs. This requires Roadmaps which are not specific to domains.
We assume that the technical barriers for convergence in the Smart House will diminish over time with cost reduction of components of communication interfaces, i.e. Moore’s law and the like will continue to prevail. The technical assumptions (requirements) underlying the architectures of current Ecosystems will therefore change over time. For example: in time, also simple low-power devices will be able to support the TCP/IP protocols cost effective. Our Roadmap therefore looks at what will be feasible over time. The recommendations address actions that can improve and rationalize the current situation as well as accommodate future technology developments.
There are two major challenges involved in deriving the Smart House Roadmap. Firstly, the aggregation of services from independent providers requires the replacing of the vertical integration model (service delivery pipe) with a so-called horizontal model to allow: • Providers sharing access networks and home networks to deliver their services to consumer devices • Consumers using portable and in-home devices to access multiple services • Consumers modifying, adding to and replacing his home services, devices, and appliances without losing control of the process over the lifetime of his home • Consumers changing to another service provider or service level without the need to install new networks or other infrastructure in the home (no service provider lock-in) Consumers enhancing his system with adding products from different sources (changing to another product vendor or enhanced product) without the need to install new networks or other infrastructure in the home (no product provider lock- in) Secondly, a horizontal model requires an agreed set of functions and interfaces for the horizontal layers in the protocol stack to enable some defined level of interoperability between service delivery pipes.
The SmartHouse Roadmap project thus aims to enable a transition in the 2011- 2016 time frame to a horizontal model for applications and services delivery pipes, by creating • A set of relevant use cases that have commercial value, are supported by key industry stakeholders and require extensions to current functionality (Annex A) • a clear vision on the role of and the need for standards in this transition to enable open markets and fair competition (Chapter 2) • A Roadmap of existing or to be developed standards and technologies that are best suited to facilitate this transition (Chapter 4) • A set of recommendations to stimulate a successful deployment of the Roadmap covering issues like transition scenarios and compliance testing (Chapter 6)
Enabling Migration of and Interoperability between Ecosystems in the home environment has been identified as the key goal for SHR.
2.5 Project vision summary: overview of observations and assumptions
Determining future issues and opportunities for interoperability must inevitably be based on a certain vision of the future digital home environment, here called “the SmartHouse”. This chapter elaborates that vision, which can best be summarized as a collection of observations and assumptions we make. They are listed below.
2.5.1 Observations
O1. We observe a proliferation of different wireless, wired, and no-new-wires communication networks appearing in current homes.
O2. We observe an increasing number of advanced devices in current homes with capabilities, services, and content that users wish to share among other devices in other Ecosystems.
O3. We observe an increasing number of more or less intelligent applications within current homes, and most of them have their own control interface (remote control).
O4. We observe increasing frustration amongst users and service providers because of the significant increase of managerial hassle and interoperability problems (such as co-existence) that often follow from the various forms of proliferation as mentioned above. Users and service providers increasingly wish to re-use existing devices and networks for new services. This is also stimulated by regulators, who increasingly demand efficient use of technology. Users, applications developers, service providers and regulators are the main forces that drive the need for interoperability and convergence in the SmartHouse.
O5. Convergence and interoperability mean that different services can use the same resources, and comparable services may choose to use different resources. However, different services need different levels of robustness (QoS, reliability, network diagnostics and repair, …) and security (encryption, authorization, …). Technologies for robustness and security do not yet have a significant market penetration, and the industry is still discussing their suitability and need. In the meantime more and more security- and robustness-unaware devices and services keep entering consumer’s homes, increasing the legacy and thus making adoption of standards and realization of interoperability more difficult. On the other hand, some applications, such as Security, have very high requirements for robustness and cannot yet compromise their QoS requirements when sharing resources.
O6. We observe that some good interoperability frameworks, containing standardized technologies for discovery, configuration, operation (sharing, control, etc), and management, are already implemented in today’s devices, but are switched “off” by factory default. Often they cannot be switched “on” by the user, and if they can, the user interface to do so is often not easily accessible and understandable for the non-specialist user. For instance, who knows that selecting “resource sharing” in the Windows Media Player is the way to switch UPnP “on” on the PC?
O7. We observe that Home Gateways fulfil a crucial role in interoperating WAN with SmartHouse Ecosystems, and in making SmartHouse Ecosystems interoperable among each other.
O8. In many domains (such as telecommunications, IT, and multimedia), networks using IP have proven to increase interoperability between Ecosystems, and to provide a platform for service innovation. We observe that adoption of IP by other domains (such as health care and energy) is often obstructed by lack of in-depth understanding of the TCP/IP Ecosystem. For instance, many people incorrectly think that the use of IP is inextricably connected to the use of Ethernet-like networking technologies on the data-link layer and physical layer. Also it is often not understood that supporting IP end-to-end offers advantages in terms of scalability compared to the use of IP gateways as we find them already deployed ubiquitously nowadays (e.g. for KNX networks).
O9. Various trials and deployments show that home networks will become significantly more simple, sustainable, and flexible for services if homes are by default provided with a high-bandwidth, highly reliable backbone infrastructure, either wireless or wired with many data access points. In practice, such a backbone infrastructure makes it easier to interconnect Ecosystems, to exchange them for other Ecosystems, to scale up a single- Ecosystem subnet, and to physically separate Ecosystems if a user prefers them not to interoperate.
O10. More and more specifications are developed in industrial consortiums and become de facto standard in the market that may or may not be subsequently officially standardized in a recognized (European) standards development organization.
2.5.2 Assumptions
A1. We assume that the vast majority of European homes will have a broadband Internet connection during the implementation window of this Roadmap document (i.e. 2011-2016).
A2. We assume that the number of advanced devices in the SmartHouse with capabilities, services, and content that users wish to share among other devices in other Ecosystems will continue to increase.
A3. We assume that consumers do not want a further proliferation of dedicated remote control devices for these applications, i.e. for every single new application one. We also assume that device manufacturers and service providers would rather not have to provide such dedicated remote controls.
A4. We assume that many more devices will appear in the home that have the same more or less generic function, but are allocated to a specific application.
A5. We assume that consumers would like to stop the various forms of proliferation mentioned above (of devices, remote controls, and networks) because of the implied managerial hassle and interoperability problems.
A6. We assume that many technical barriers for convergence in the SmartHouse will diminish over time with cost reduction of components of communication interfaces and increasing available bandwidth of home networks. Said otherwise, we assume that Moore’s law and the like will continue to prevail. The technical assumptions (requirements) underlying the architectures of current Ecosystems will therefore change over time. For example: Simple devices such as many sensors and controllers will at some stage need end-to-end addressability for energy, home-control, safety, and security applications. Moore’s law dictates that they will sometime be able to support the IP protocol cost effective, because the chipset needed for that has become commodity. The Roadmap recommendations should address actions that can improve and rationalize the current situation as well as accommodate future technology developments.
A7. We assume that governments are likely to introduce requirements for the deployment of back-bone network infrastructures in new houses to be built within the time frame of the SmartHouse Roadmap.
3 Approach
In this chapter, the process for developing the Smart House Roadmap will be described.
3.1 Starting point of the project approach: convergence and migration
Based on the above considerations around the diversity of all the different Ecosystem standards the approach of the SHR can be summarized as: • Application Domains are not well defined and the borders between Application Domains are constantly blurring over time. The best approach to uncovering interoperability challenges needs to be based on concrete use cases involving devices and existing Ecosystem standards. • Ecosystems address specific use cases and define or guarantee a certain level of interoperability between “their devices” in specific use cases. • SHR use cases include Internet multimedia services, in-home AV entertainment, broadcasting, home automation, smart metering and tele- care. Devices can range from PCs, TVs, multimedia players, video- and photo cameras to storage devices, (mobile) phones, HVAC devices, sensors, displays, controls etc as well as combinations of these. • SHR use cases need to enable access to these in-home devices from other in-home devices as well as multiple external services across different Ecosystems. • Multiple competing and/or incompatible Ecosystems will always exist, or new Ecosystems based on new technologies that overlap with use cases of existing Ecosystems will be developed as technology advances. SHR cannot and should not try to prevent this innovation. • SHR will not select between competing standards. Which standard(s) will prevail is considered outside the scope of the SHR and will be determined by the market. • Instead SHR needs to recommend how incompatible Ecosystems should migrate or converge to achieve some defined level of interoperability. SHR needs to give a taxonomy for these levels and a taxonomy for the standards themselves to determine these levels. • The value of the underlying use cases to the Ecosystem partners or otherwise regulatory pressure will determine whether the Ecosystem will migrate according to the SHR. As shown above in the example of digital TV distribution sharing devices and home networks is not always in the interest of all players in the value chain of these use cases and therefore will not happen even if it is desirable from a user point of view.
3.2 Project approach: overview
The complete project approach is schematically depicted in Figure 3. Phase 1 of the project concerned the gathering of all relevant information (use cases, reference models, standards, etc.) needed for deducing the main results of the project, i.e. the taxonomy and the recommendations (phase 2).
The core of phase 1 is the collection and description of about ten good use cases covering important application domains (and their convergence), with market relevance, describing: • Their value chain and main actors • Possible interactions as well as impossible but desired interactions within and between today’s relevant services from a user perspective • Today’s deployed standards and technologies for these interactions
The quality of these use cases is strongly dependant on the template one uses and the reference model used to visualize the use case with its standards and technologies. The template we chose is provided in Annex A. It is derived from what is used in DLNA, The reference model we used is new, and derived from many examples in the literature (e.g. [13-14]). It defines terminology to describe elements and interfaces within and between service delivery pipes. It does not deserve the name “architecture” as defined in e.g. [15], but it serves our purposes. We therefore speak about “reference model (RM)” rather than reference architecture.
From the use cases and the long list of existing Ecosystems relevant to the SmartHouse, we then create interoperability profiles which show at a more abstract level where the needs for interoperability really are, and a short list of standards relevant to the use cases. From the interoperability profiles we deduced a common taxonomy of standards as a tool capable of creating interoperability profiles from use cases. The SmartHouse Roadmap is formed by plotting our short list of standards from our use cases on the taxonomy thereby identifying the interoperability needs and challenges for our use cases. From the SHR Roadmap we then derived recommendations for the EC and the ESOs.
Phase 1 Phase 2
Figure 3. Flowchart of the SmartHouse Roadmap approach. The circles with red perimeter denote the project’s key results. 3.3 Stakeholder Requirements: Use Cases
The success of the SHR will be determined by its deployment and adoption by the industry during the time span it addresses (2011-2016). This depends however largely on whether there actually exist use cases that the industry is willing to invest in. The underlying technologies or standards play a secondary role.
Collection and verification of relevant use cases therefore formed an important part of the SHR approach and encompassed the first phase of the project. Use cases that require interoperability between Ecosystems are easily “invented” based on “common sense” assumptions on what we all would like to be possible as consumers to improve our life or what is desirable from a political point of view. However consumers only represent one part of the stakeholders of a use case. Unless the industry sees the value of such a use case and sees a business model for it, it is unlikely that steps are taken (preferably along the line of the SHR recommendations) to actually achieve the use case objectives unless this is stimulated by government regulation.
In the SmartHouse Plenary Meeting that was held on the 2 March 2010 we invited the industry and relevant Technical Committees from standards development organisations. We prepared and discussed several use cases for this workshop and a few more were developed during the workshop. The industry support of our use cases is mainly based on the input from the 35 participants of the face-to-face plenary meeting. This may be interpreted as a discrepancy between the need for convergence as felt by the end user and the willingness of the industry to actually develop the interoperability solutions for these use cases. We are therefore not claiming that the use cases are well supported by a large industry base.
To our knowledge none of the Ecosystems we consider is currently working on similar use cases. E.g. smart metering gets a lot of attention and is heavily pushed by the EC to reduce the energy footprint of consumers. Standards are being or have been developed and are partly starting to be deployed in trials but interoperability with other Ecosystems is not a high priority issue or is dismissed based on technical grounds. In other words this might lead to yet another vertical bit pipe into the home controlling individual appliances and requiring special control devices in the home while it might be rather simple to use existing devices such as the TV or mobile phone to control these appliances and at the same time communicate with the service provider.
In summary it remains therefore questionable whether we actually captured the main stakeholder requirements and if business models actually exist for the SHR use cases. In other words: are consumers willing to pay for it or do governments need to play a stimulating role here? Verifying the value and business models of our use cases with actual consumers and the industry via market research would require a major effort and is considered outside the scope of this SmartHouse Roadmap project. Our Roadmap is produced assuming that our use cases are relevant and have a valid business model. However, the objective has been to develop approaches and tools for others to use rather than to solve specific business problems. 3.4 Selection and analysis of a representative set of Ecosystem standards.
Many policy makers have expressed the need to have an overview of all standards of the SmartHouse in a structured way. Also during plenary meetings of the SmartHouse Roadmap project this wish could be heard. However, this is practically impossible, mainly because of the sheer amount of standards that exist for the SmartHouse in its most extended definition [3]. For this project we therefore constructed a much shorter long list of standards which we deem to be relevant for the SmartHouse in 2010, by using the following selection criteria as a filter: • Only standards and specifications that have a documented relevance to interoperability and convergence of Smart House specific applications • Only standards and specifications that have a documented relevance in the market • Preferably European standards and specifications. International (global) standards and specifications only if relevant and European equivalent are not available. National standards and specifications only if international and European equivalents are not available. • Only finalized standards and specifications. No drafts or non-normative guidelines and technical reports. • Only the latest versions of the standards and specifications, and older versions if they are still supported in the market
The resulting long list of standards is given in Annex C. They can be grouped in Ecosystems, and this long list of Ecosystems is given in Chapter 4. From the use cases we then constructed a short list of Ecosystems. They are the ones for which we created interoperability profiles (and to create a Roadmap and recommendations), highlighting the functions for which we need interoperability to achieve the interactions described by the use case. These functions then form the basis of our taxonomy dimensions. We expect that other standards of the long list can be classified and analysed as well using the taxonomy, but we leave the actual work up to any party with a particular interest in those standards. Our taxonomy is distinctly different from the one proposed in ISO/IEC 29107 [16]. Many of the proposed dimensions in ISO/IEC 29107 seem criteria for selecting standards given a certain context, and are not relevant for assessing interoperability.
3.5 SHR Reference Model (SHR-RM)
SHR-RM is a tool for describing use cases of smart house services and applications. As starting point we used the model from ISO/IEC TR 29107 [16] as depicted in Figure 4.
Figure 4: Reference model as used in ISO/IEC TR 29107
While this model gives a good overview of the networks involved, it purposefully abstracts from the actual devices and protocols in the home. Although it shows that multiple islands exist in the home each using their own protocols and interoperability solutions, we wanted to be able to describe and make visible: • Actual devices as they exist in homes • Actual networks as they are used in homes • All the players and roles of the value chain of the services • Relations between players, roles and device ownership
Besides, Figure 4 represents a domain view of the Smart House reference model. It assigns devices to clusters covering “similar applications” connecting them to one “abstract” domain specific home network. Unfortunately it is rather arbitrary what is deemed “similar”, and it is difficult to assign applications, devices and networks to one particular domain. There is also no one-to-one relation between domains and specific standards. Most domain standards use the same technologies and standards used by other domains. Continua, for instance, uses IEEE 802 and Bluetooth protocols used by PC/CE and telephony applications. We therefore conclude that a domain view is not very helpful when classifying standards and technologies (as a taxonomy) to discover interoperability (mis- )matches.
The reference model that we designed for the SmartHouse Roadmap is shown in Figure 5. It contains all the generic building blocks needed to describe any smart house service or application based on devices in the home. This model can be used to describe both applications wholly contained within the home, such as home automation, and applications depending on external services. A user may connect devices within the home, and a user may access a service through multiple devices (service sharing). A device may give access to multiple services from different Service Providers (SPs, device sharing). A device can be used in or outside the home (portable devices). A service may share networks with other services along the path from SP to device.
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
Figure 5. SmartHouse Roadmap Reference Model
Service providers (SP) provide a service (e.g. a Web service, ISP service, TV,voice) typically from outside the home to end user devices (EUD) in the home. Access Network providers (NP) provide the use of their AN (e.g. ADSL, Cable, Satellite) to the end user and to service- or other network providers (roaming). End-user devices (EUDs) in the home may provide in-home services to other EUDs in the home (e.g. home automation applications) or to the Internet.
The following definitions are used describing the infrastructure and networks. • Access Networks (AN): the last hop of the service delivery pipe that physically connects (indicated via thick line and black dots) an End-User device (EUD) or a Network Infrastructure Device (NID) in the home to an service delivery network outside the home. • EUDs: devices operated by the end user and offering a User Interface (UI) to the end user through which he can access services. EUDs can be managed and owned by o the service provider: SP-EUD, e.g. a Set Top Box or a Home Gateway). SP-EUDs are usually leased or given away for free by service providers as part of the service agreement. o the consumer: R-EUD (retail EUD). e.g. a TV or PC. The consumer buys these devices independent from the SP in the retail shop. • NIDs: EUDs that do not offer a UI to the end-user to access the service itself e.g. network terminators, bridges, switches, routers, gateways. NIDs carry and/or manage the data of the service delivery pipe. NIDs may provide a UI to the end-user to configure the functions of the NID or these devices may be managed remotely by the network provider (NP) or service provider (SP). The. Home Gateway is an example of a NID. • Home Networks (HN): physically interconnect (indicated via thick line and black dots) EUDs and NIDs inside the home. • Virtual Backbone (VB): virtually connects (indicated via dotted oval, thick line and white dots) an AN to a global infrastructure like the Internet or POTS or IMS backbone connecting NPs and SPs. How this is done is out of scope for the Reference Model. It may involve complete (inter-)networks running business- or management applications between SPs and NPs. • Peripheral Networks (PN): physically connects (indicated by thin line and black dots) peripheral devices (PD) to a master device, e.g. USB, HDMI, and Bluetooth. PDs typically connect to one master and do not exist stand- alone. The master may aggregate PD device functionality and make it accessible over the HN. Some PN technologies can in principle also be used for HN, e.g. Bluetooth, and IEEE 1394. EUDs and NIDs can have both PN and HN interfaces.
Relations between SPs and NPs in the value chain are indicated in the SHR-RM using colours. Identical colours indicate that an SP also is the NP of the AN over which the service is delivered. Different colours indicate that an SP (e.g. Web service, ISP) uses the AN from a 3rd party NP. An SP may control and manage the EUD or NID devices via which the service is accessed or distributed into the home. EUD and NID colours identify the SP or NP that manages and controls them. In-home services such as an HVAC controlled by a portable display, may or may not require interaction with an (external) SP. R-EUDs have a grey colour indicating they are not owned or managed by an SP or NP.
3.6 Interoperability considerations
Various levels1 of interoperability can be distinguished. A practical model for this is given by CWA IFRS [4]. The model is presented in Table 1. Convergence between Ecosystems as targeted by SHR does not require interoperability to conform to every single IFRS level. Technologies used in a single house must at least co-exist, i.e conform to IFRS level 1. The need for conformance at higher IFRS levels depends on the SHR use cases. A system is declared as not interoperable if the use case demands a higher level of interoperability than the technologies can deliver.
Table 1. The interoperability levels as identified in CWA IFRS [4]. The CWA defines conformity requirements only for levels 4-6
1 Interoperability levels are not to be confused with OSI layers Various ways exist to solve interoperability issues between Ecosystems. The best is to specify and standardize different protocols in such a way that they become interoperable, i.e. guarantee level 3 at least. For that, a separate standard shared between Ecosystems specifying the interoperability is often needed. Another way to solve interoperability issues between Ecosystems is to define Application Level Gateways (translation boxes) between non-interoperable Ecosystems. This would at least guarantee IFRS level 2 interoperability.
The interoperability profiles for the SHR use cases when plotted in our taxonomy only show for which part of a service (termed Service Building Block in the SHR taxonomy) multiple Ecosystems exist that may or may not be interoperable on a given protocol level (e.g. OSI level). If interoperability is required but not provided, further action may be needed to ensure interoperability.
Our taxonomy can be used to detect interoperability needs within or between Ecosystems. Ecosystems by definition target user-level interoperability between devices within the Ecosystem, so one does not expect interoperability conflicts within an Ecosystem. However: • optional features of the intra-Ecosystem standards often reduce user level interoperability (sometimes down to co-existence level) as devices may implement different or even disjunct sets of optional features. These sets are usually called profiles and are sometimes identified to users via sub- logos. • the need for new functions requires extending and changing of some intra- Ecosystem standards and thus may create interoperability issues (“backward compatibility) with other, older standards within the Ecosystem.
Interoperability conflicts between Ecosystems are much more common. An Ecosystem usually uses a “minimal” specification that only meets the technical and commercial requirements of its target application(s). Interoperability with other Ecosystems is typically not a requirement at the time the choices for an Ecosystem specification are made. Interaction between devices from different Ecosystems thus often results in interoperability conflicts, mostly on the higher IFRS levels, but sometimes also in co-existence.
Interoperability within or between Ecosystems typically concerns IFRS interoperability levels 0-3. IFRS levels 4-6 are more applicable to the interaction between specific parts of a service, typically concerning the configuration and management of the system, which are examples of Service Building Blocks in the SHR taxonomy. Apart from inter- and intra-Ecosystem interoperability use cases, we also distinguish a type of use cases which we call “changing between service providers”. Changing to another Service Provider can cause interoperability challenges between a service and a device in many different ways, e.g. new provider uses a different protocol stack, or a new service needs to reuse or share an existing Home Gateway (HG) to run a service specific stack. These use cases are basically a special case of inter-Ecosystem interoperability, but have a more temporal character, and highlight the need for flexibility and reuse of resources.
4 Results
4.1 Use cases
The following lists an overview of the 11 use cases we collected: • Intra-Ecosystem interactions o A-1: multiple stand-alone services (voice, TV, internet, PC) o A-2: migrating to DLNA Ecosystem and Remote UI o A-3: safety and security o A-4: migrating to DLNA Ecosystem and Remote UI including content format and protection issues • Inter-Ecosystem interactions o B-1: Remote operation of embedded generators o B-2: (Remote) Energy Management & Home Automation o B-3: (Remote) heating control, intrusion alarm, home automation, TV, voice and data communications o B-4: (Remote) energy control, intrusion alarm, home automation, TV, voice and data communications • Changing Service Providers interactions o C-1: changing AN-Ecosystem o C-2: open AN-Ecosystem o C-3: Changing network operator as well as metering provider Details can be found in Annex A.
In use case C-3, we have split up the deployment view into views per relevant dimension of our taxonomy. Splitting up as such makes deployment views easier to understand, and helps with the construction of interoperability profiles.
4.2 Ecosystems
The long-list of standards we collected is given in Annex C. The long-list of Ecosystems we derived from Annex C is given in Table 2. For ease of use only, we sorted them according to domain, even though the assignment is often rather arbitrary.
An important remark to make is that the table is populated with Ecosystems rather than single standards, even when the name of a single standard is used. For instance, TCP/IP here means the whole TCP/IP Ecosystem (including also UDP, HTTP, IPv6, etc.).
Mostly it is obvious how an Ecosystem should be named and what standards belong to it. But sometimes it is not. In those cases we have taken the freedom to name the Ecosystem pragmatically and to group standards to an Ecosystem as we see the market is using them.
The short-list of Ecosystems, following from the use cases, is given below in Table 3. The Ecosystems that appear in the use cases for Peripheral Networks are not mentioned though, because they do not play a role in the interoperability profiles.
Table 2. Long-list of Ecosystems for the SmartHouse.
Broadband Tele- Communications TCP/IP communications SIP 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 management 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
Table 3. Short-list of Ecosystems, following from the use cases
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
4.3 Taxonomy
The taxonomy we found after multiple iterations with the use cases and the interoperability profiles is given by only 2 dimensions:
1) protocol layer 2) generic service building block
Dimension 1) may be filled in with OSI layers. OSI-layers are the well-known 7 layers as standardized by ISO [17]: 1. Physical (media, signal and binary transmission) 2. Data Link (physical addressing 3. Network (path determination and logical addressing) 4. Transport (end-to-end connections and decryption) 5. Session (interhost communication) 6. Presentation (data representation, encryption) 7. Application (network process to application)
However, it is of crucial importance that the user of the taxonomy is given freedom on the level of focus he wants to apply, depending on his use case. One could use the 7 OSI layers. But if one, for instance, is looking at a use case which only deals with interoperating optical Ethernet (as used in the WAN nowadays) with in-home Ethernet, one really only needs to focus on the OSI-layers 1 and 2, but also their sub-layers (data-link, MAC-layer, convergence-layer, multiplexing, …).
For defining Dimension 2), the user of the taxonomy must unravel the service being discussed in a particular use case into its basic application building blocks. This should preferably be generic application building blocks. Similarly to Dimension 1) the user of the taxonomy has freedom to choose his application building blocks regarding the focus of his use case. Examples of such application building blocks are: • bulk data transport (this means a generic application building block to shift a large amount of data as quickly as possible from A to B, probably with medium delay and low packet loss) • delay sensitive control (this may be typical for gaming: not much data but with low delay and medium reliability; but can easily extended to more “serious gaming” applications, and maybe others) • device and service discovery (not much data, but with some broad- or multicast properties, with low delay requirements, but high reliability) • remote device and service management (session-independent fault, configuration and performance management of devices and applications; this may include non-ICT devices, and thus non-ICT services) • remote device and service control (session-dependent real-time reading and writing of parameters from and to a device or an application, so that the device or service now does what you want it to do; this typically includes signalling and may include non-ICT devices) • network control (end-to-end (e2e) flow control, error handling, retransmission, routing, load balancing, QoS control,….) • network management (session-independent fault, configuration and performance management of lower OSI-layers) • service security (authentication, authorization, encryption, intruder detection, digital rights management, …) • remote user interfacing • …
There is a strong relation here with the concept of Service Oriented Architectures or SOAs [18].SOA is a flexible set of design principles used during the phases of systems development and integration in computing. A system based on a Service Oriented Architecture will provide a loosely-coupled suite of service building blocks. The more generic these service building blocks are, the more they can be used and reused within multiple separate systems from several business domains. Said otherwise, if a service architecture is designed in the first place according the design principles of SOA, the chances are maximized that the system supporting that service contains various building blocks that can communicate with building blocks from other systems (for other services, possibly in other domains) that are also designed according to these principles. As such, the system exhibits a maximum capability to interoperate with other systems.
Obviously, not every service building block in a service architecture can be generic; otherwise services would all be the same. However, a recent analysis of activities performed (by people and/or machines) to provide a telecommunication service [19] showed that a large majority (>80%) of these activities is not specific for that telecommunication service. It can reasonably be assumed that analyses in other business domains would yield similar numbers. Thus, the opportunities for interoperability between and reuse of service building blocks are huge.
The SOA design principles are the following ([19], and others). “Service” here should be seen as “generic service building block”. • Standardized Service Contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents. • Service loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other. • Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world. • Service Reusability – Logic is divided into services with the intention of promoting reuse. • Service Autonomy – Services have control over the logic they encapsulate. • Service Statelessness - Services minimize resource consumption by deferring the management of state information when necessary • Service Discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. • Service Composability – Services are effective composition participants,regardless of the size and complexity of the composition. • Service optimization – All else equal, high-quality services are generally preferable to low-quality ones. • Service relevance – Functionality is presented at a granularity recognized by the user as a meaningful service. • Service encapsulation – Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
Loose coupling and standardized service contract is in practice often realized by using W3C Web Services as a communication protocol, and by standardizing the parameters in the data bases that these protocols act on. Examples of the application of these principles are the Ecosystems UPnP and TR-069. Other important principles for SHR are Reusability (as explained before), Discoverability (one of the building block identified above), Composability (that is what makes a building block a building block) and Relevance. The latter has a relation to granularity, which will we discussed in the next section. The principle of service composability is schematically drawn in Figure 6.
SBB
Service Consumer SBB
SBB
SBB
Composite Service
Figure 6. Service composition in SOA. The Service Consumer accesses a service, which under the hood is composed out of several generic Service Building Blocks (SBBs). Some SBBs may at the same time be used for other services.
The whole of SOA is set-up mainly for application in Enterprise IT architectures. However, we think that the design principle are highly applicable to any system, hardware or software, that requires high levels of interoperability with other, often still unknown, systems. Unfortunately, most of the current systems are not designed as such, partly because the principles of SOA are relatively new and not yet known to everyone, partly because applying them to a specific system may compromise other requirements to the architecture, such as total cost of material and performance (speed).
However, for designing interoperability profiles it is still useful to unravel any communicating system into its generic Service Building Blocks, even if they are not directly reflected in the architecture. The reason for that is that the functionality of a not-existing building block should still be present and provided by the system somehow, even if it not loosely coupled, etc. Only then one can investigate where interoperability (even only limited) with other systems can be achieved and how. A system designed a priori according to the SOA principles does not require any additional work to make the blocks interoperable: they are plug and play. Making two systems interoperable that are not designed as such may require extra effort to do so, such as designing an overarching protocol layer (overlay) or building an proxy/gateway box interconnecting the systems for one or more specific functions. This will be explained in the following sections.
“Reverse application” of the SOA principles to existing hardware and software Ecosystems that are not created with SOA in mind is one of the main innovative paradigms of our work described in this report. The other innovation is the allowance of freedom in choosing the granularity of the dimensions in the taxonomy. If we would determine the granularity here and now, the taxonomy would immediately become useless for many use cases we cannot think right now. This is maybe the biggest error made when designating the well-known 7 OSI-layers: it turned out that internetworking desires more layers under layer 3, and less above layer 4. The OSI-model is not flexible enough to accommodate for these observations.
4.4 Interoperability Profiles
To construct an interoperability profile from a use case, the following algorithm should be used: 1. Unravel the use case into its generic service building blocks. Only define and look at the building blocks that are interesting for your use case. It is important to define them as generic as possible: this increases the chance on finding interoperability opportunities or issues. 2. Analyze for every service building block the end-to-end communication paths involved, and where Ecosystems are crossed in a given path. Here, making use of the SHR Reference Model should help. 3. Now look for every single generic application building block separately how information is communicated with respect to all protocol layers involved, but only the protocol layers that are of interest given the use case. Thus write down for every single generic application building block the complete protocol stack used, but only for the layers of interest. Maybe one has to write down a complete protocol stack from OSI layer 1 to 7 first before seeing where the really interesting layer actually are. 4. One should also look at the granularity one chooses for the dissection of the service into its generic components, and the granularity one chooses for the protocol layers. A finer granularity means that if an opportunity for interoperability is detected, it is probably a good one: there will be a very good match between the functionality of protocols that end up in the same cell of the interoperability profile. But a finer granularity also means that there may be some overlap in functionality between various separated generic application building blocks (e.g. remote device control and remote device management) and between various protocol layers (e.g. link layer, network layer and transport layer). One then may miss opportunities for interoperability by plotting comparable protocols in different cells. Choosing a courser granularity then helps, but also means that interoperability may be so-so. For instance, combining remote device and service management and control into a single building block hints at interoperability between TR-069 and UPnP; which indeed exists, but is not great. 5. One may consider underlining or color coding the Ecosystems that, if found in the same cell in the interoperability profile, indeed need to interoperate, given the use case. One could also indicate for which Ecosystems inter-Ecosystem interoperability already has been achieved by the industry or not. None of these is done by the authors in the interoperability profiles below.
Interoperability profiles can be simply represented in 2-dimensional matrixes. For use case C-3 the interoperability profile is shown in Table 4.
Table 4 . Interoperability Profile for the SmartHouse Roadmap use case C-3
C-3 Data Transport Device and Service Management Control OSI 5-7 OpenIPTV, DLNA, OpenIPTV, OpenIPTV, TR-069, LON DLNA/UPnP, LON UPnP, LON
Given the interoperability profile, we now can make the following analysis and conclusions for use case C-3. The use case requires interoperability (of at least IFRS level 3) on the session, presentation and application layers, for data transport, control as well as management. Following the end-to-end paths, interoperability is not needed between all Ecosystems in a single cell in the profile. For instance, the use case does not demand interoperation between OpenIPTV and LON. Interoperability is needed between: • OpenIPTV and TR-069 • OpenIPTV and DLNA • UPnP and LON • TR-069 and UPnP Most of the interoperability is trivial, because the Ecosystems already arranged this: • OpenIPTV manages standard with TR-069. • OpenIPTV and DLNA have already defined an interworking function Less obvious is the need interoperability between UPnP and LON. However, ISO/IEC is already working to standardize interoperation between UPnP and LON (ISO/IEC JTC 1/SC 25 N 1795). Just as little obvious may be interoperability between UPnP and TR-069. However, also here the responsible bodies Broadband Forum , UPnP Forum and HGI are already working on this.
The interoperability profile of use case C-3 is fairly simple. Apparently the inventors of the use case are only interested in interoperating the application layers 5-7 with not much granularity. Only five Ecosystems play a relevant role there, for three different building blocks of the service. Interoperating at level 5-7 means in practice the application of a proxy/gateway between the LON system and the UPnP system, for instance. One could also, in theory, have opted for interoperating LON and Ethernet at level 3, by running the TCP/IP protocols on top of the OSI layers 1-2 of LON. LON then would have become an undistinguishable part of the routed network. The advantages of such an approach would have been an increase in scalability and a cheaper gateway (router). Disadvantages are the uselessness of legacy LON devices in such a network and the need for extra standards.
Table 5 shows the interoperability profile for use case A-1. The main cases for interoperability in this use case are: • Between DECT and VoIP on application level, or DECT and TCP/IP on network level. • Co-existence on the physical layer between DECT, Bluetooth, and Wi-Fi. • On the application layer between Bluetooth and DVB-MHP
DECT/IP interworking and DPRS (DECT Packet Radio Switching) have been part of the DECT standard already for a long time, and have recently been updated specifically for the support of operators’ VoIP services (Cat-iq). Proprietary VoIP/DECT phones have been on the market already for a while, and so are Skype/DECT phones. Further standardisation is needed to align the various VoIP and peer-to-peer telephony solutions currently on the market.
Co-existence between DECT and 2.4 GHz systems like Bluetooth and Wi-Fi is, in Europe, trivial because DECT works on a different carrier frequency. Interference between Bluetooth and Wi-Fi is a well-known phenomenon [20]. IEEE 802.15.2 provides a solution but is, as far as the authors know, not widely implemented. The new Wi-Fi standard IEEE 802.11n may provide a solution, because it can also operate on the 5 GHz band.
Any interoperating between DVB-MHP and Bluetooth is unknown to the authors, so if the demand for this use case from the market is high enough, this is an example of an interoperability gap detected with our method.
Table 5 . Interoperability Profile for the SmartHouse Roadmap use case A-1
A-1 real-time data Non real-time data Security, streaming, QoS, in- transfer, connection Authentication, band signalling control, network Access Control management, out-of- band signalling OSI 5- DECT, G.711, TCP/IP DECT, Microsoft P&P, DECT, DVB (MHP), 7 (RTP, RTCP), DVB (MHP), SIP, Microsoft P&P, DVB, Bluetooth Bluetooth Bluetooth OSI 3- DECT, TCP/IP, DECT, TCP/IP, 4 Bluetooth Microsoft P&P, Bluetooth OSI 1- DECT, Ethernet, Wi- DECT, Ethernet, Wi- DECT, Ethernet, Wif- 2 Fi, Bluetooth Fi, Bluetooth Fi, Bluetooth
A-1 Device and Service Discovery Remote Device Control, Device Management OSI DECT, TCP/IP (DNS), SIP, DECT, Microsoft P&P, SIP, DVB 5-7 Microsoft 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
The interoperability profile of use case A-1 shows that interoperability profiles can get complex fairly quickly with more advanced use cases. It is therefore advised that such use cases are subdivided in various more or less independent sub- cases.
The interoperability profile for use case A-2 is shown in Table 6. Case A-2 is basically the same as A-1, but John decided to throw his regular DECT phone, 3G phone, and STB away, and replace them with DLNA certified equivalents. The 3G phone is then replaced by a smart phone with Wi-Fi instead of Bluetooth and DLNA. As a result, Table 6 is much simpler than Table 5. The only interoperability issue in place seems to the user interfacing between smart phones and other DLNA devices.
The interoperability profile for use case B-1 is shown in Table 7. Here the service building blocks are seen to be too strongly coupled to distinguish different Ecosystems for, resulting in a fairly simple profile. DLC (Distribution Line Carrier) is not given in the long list nor the short list. It is a specification for signalling on low-voltage electrical installations in the frequency range 3 kHz to 148.5 kHz. The protocol is an access technology using EN 50065-1 as its lowest layer, and has a data rate up to 576 kbit/s. DLC is suitable (even in very large networks) for multiple realtime energy management applications. It is mostly used on the public electricity network for applications such as automated meter reading, and has thus the same position in the SmartHouse as Access Network communication protocols such as ADSL. We have therefore omitted it from our lists.
Table 6 . Interoperability Profile for the SmartHouse Roadmap use case A-2
A-2 Real-time data Non real-time data Security, streaming, QoS, in- transfer, connection Authentication, band signalling control, network Access Control management, out-of- band signalling OSI 5-7 DLNA DLNA DLNA, W3C OSI 3-4 DLNA DLNA DLNA OSI 1-2 DLNA DLNA DLNA
A-2 Device and Service Discovery Remote Device Control, Device Management OSI 5-7 DLNA DLNA, W3C OSI 3-4 DLNA DLNA OSI 1-2 DLNA DLNA
Table 7. Interoperability Profile for the SmartHouse Roadmap use case B-1
B-1 Data and Control OSI 7 EN 61850 OSI 3-4 TCP/IP, Zigbee, KNX, DLC OSI 1-2 Wi-Fi, KNX, Zigbee, DLC
However, some of the main interoperability issues in energy management lies between DLC and in-home protocols such as KNX. The issue for any external party accessing a HES network remotely is that they do not know beforehand which protocol they are going to encounter. Whilst it is possible to build a bridge for any combination, providing a general solution is not possible without some new approach to interoperability. U-SNAP provides a serial converter chip that is custom fitted for each meter to link the remote and local networks. ESNA is promoting an approach based on TCP/IP and W3C that would allow the meter bridge to self-configure.
Another interoperability issue to be solved is the fact that ZigBee has not yet been extended to support EN 61850-7-420 codes.
We did not produce interoperability profiles for every single use case. First of all because creating a good and useful interoperability profile requires deep knowledge of all Ecosystems involved. This is a skill which is not easily found within the limited context of the project. Discussions quickly go to the bits-and- bytes level of every Ecosystem involved. Furthermore, after having analysed the use cases A-1, A-2, B-1, and C-3, we came to the conclusion that for the ultimate goal of the project, producing the taxonomy and drafting recommendations for the EC, the ESOs, and the market, we did not gain much more information anymore by analysing yet another use case. The tables 5-7 thus only show interoperability profiles for use cases A-1, A-2, and B-1.
4.5 Solution Space
4.5.1 Object modelling paradigms and interoperability
The SHR intends to give generic recommendations to integrate incompatible Ecosystems instead of addressing the many specific interoperability challenges identified by the SHR use cases. Therefore it is first needed to carefully analyze the common causes for these interoperability issues. A generic object model of an Ecosystem is shown in Figure 7..
Controller Device D1 Controlled Device Di
Controller UI protocol A (OSI 1-7) Object a A i Object ai
Ecosystem A Service Building Blocks
Figure 7–generic object model of an Ecosystem
An Ecosystem models its Service Building Blocks in terms of objects and their external behaviour (commands, responses, events) in order to interact with another device over a network. These objects ai are implemented by one or more controlled devices Di and a protocol is defined that allows a control application A on device D to control these objects individually. The application logic in A integrates the Service Building Blocks ai into an application and may optionally implement a User Interface to interact with a human as part of this application. Furthermore there needs to be support in the Ecosystem to find and identify objects ai in the network. IFRS [4] describes this as a number of generic function steps in the lifetime of an object: discovery, binding, operation and (run-time) management2. These steps are present in some form in all Ecosystems.
From Figure 7 it can be seen why even a single Ecosystem may appear not interoperable to end users. Within an Ecosystem A many different Service Building Blocks (a1, a2, ..) may be defined, It then becomes impractical and too expensive for a controller to control all these Service Building Blocks. Usually manufacturers therefore ship their controlled devices with their own dedicated controller to ensure a user can control their device. The result is a myriad of different control devices in users’ homes. From an end-user perspective not being able to share controllers to control multiple devices across Ecosystems is one of the biggest roadblocks preventing interoperability.
This issue only becomes worse if a controller needs to integrate Service Building Blocks from Ecosystem A and B as depicted in Figure 8. • B usually extends the variety of different objects bi that need to be controlled. • If protocol A and B are different it is not possible for controller A or objects ai, to interact with objects bi directly and vice versa even if the objects model the same Service Building Block. D now needs to support both the A and B protocol. It also needs to implement and integrate the application logic of both A and B and if needed create an integrated UI for them. This is not scalable: when the number of Ecosystems grows this becomes impractical. • The application logic of A and B has to be built-in in D. When a user later installs devices of Ecosystem C the same interoperability challenge occurs or D has to be upgraded.
Controller Device D1 Controlled Device D2
Ecosystem A Service Building Blocks
Controller protocol A (OSI 1-7) Object a A 1 Object a1
UI
Controller protocol B (OSI 1-7) Object b B 1 Object b1
Ecosystem B Service Building Blocks
Figure 8 –integrating multiple Ecosystems
To enable the sharing of control devices you need to hide the differences between the objects and their protocols within and across Ecosystems as much as
2 These IFRS function steps can themselves be used in our taxonomy as Service Building Blocks to compare Ecosystems. possible. To what extent this can be achieved depends on the applied object modelling paradigm that an Ecosystem uses.
4.5.2 Object modelling paradigms
Three fundamentally different paradigms can be distinguished: • Functional models. This is the most common model deployed by current Ecosystems. Service Building Blocks are modelled as object command sets that require (sometimes detailed) knowledge in the controller of the functionality of the Service Building Block. Therefore the probability that different Ecosystems model the same Service Building Block (e.g. a temperature sensor) different is very high. Migration scenarios based on gateways that map command sets from different Ecosystems are needed to accommodate differences between Ecosystems. In this model it is possible for the controller to combine and aggregate the functionality of multiple Service Building Blocks in its application logic to the end-user as a single more capable application
Controller Device D1 Controlled Device D2
Ecosystem A Service Building Blocks
UI protocol A (OSI 1-7) UI Object a1 Object a1
UI protocol B (OSI 1-7) UI Object b1 Object b1
Ecosystem B Service Building Blocks
Figure 9 –integrating multiple Ecosystems
• Remote UI models. As can be seen from Figure 9, this model exports the control UI of the object instead of the control commands to the controller. The controller only needs to create and present a UI to the user from the UI description it receives and send back the UI responses from the user via the Remote UI protocol. In this model the controller does not need to be aware of the functionality of the Service Building Blocks it controls. Even if objects very much differ in their functionality there is usually a large commonality in the UI via which these objects can be controlled by a human. It is therefore much easier in this model to share a controller to control a large variety of Service Building Blocks. Remote UI models can of course only be applied to systems that have a human in the control loop. Furthermore it is not possible to aggregate functionality of Service Building Blocks. This task is shifted to the human behind the UI. This model requires a standard protocol to export UIs that should work with the common control devices in the home such as PC, TV and mobile phone. The best known example of a Remote UI protocol are web pages stored in devices that are displayed by a browser on the PC or TV. Migration between Ecosystems with different Remote UI protocols is difficult and not very common. Furthermore it is not possible to aggregate functionality of Service Building Blocks in this model without the controller needing knowledge of the Service Building Blocks. This task is shifted to the human behind the UI. • Hosting models. In this model the controller acts as a host that uploads and executes a control program from the controlled device that communicates with and controls the object on the controlled device. It resembles the driver model used e.g. for USB in the PC environment. The protocol between controller and controlled device can be proprietary and does not need to be known by the controller. This model requires a standard protocol to upload the command pogram plus a standardized run-time environment for the uploaded control program including APIs to create a UI or to communicate with other programs running on the controller. DVB-MHP (based on Java VM) or browsers running Javascript are good examples of this model. Furthermore it is not possible to aggregate functionality of Service Building Blocks in this model without the controller needing knowledge of the Service Building Blocks. This task is shifted to the human behind the UI. Migration scenarios between Ecosystems with different run-time environments are not possible in this model.
Table 8 gives an overview of the different paradigms.
Table 8 –object modelling paradigms
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
What particular modelling paradigm an Ecosystem uses is of course solely decided by that Ecosystem. Most Ecosystems and interoperability challenges from the use cases are based on the functional model and the use of command sets. Therefore migration scenarios using gateways are a feasible way forward. The good thing about migration scenarios is that they usually do not require any additional standardization. Every Ecosystem or every device manufacturer can decide for himself, based on market needs, when and for which Ecosystem protocols they want to add (optional) support to their devices.
5 Summary and conclusions
Based on the analysis of the use cases and the face-to-face discussions with the project members in terms of interoperability issues, the state of the SmartHouse can be summarized in the following way: • interoperability within SmartHouse Ecosystems can be achieved or regarded as already given (e.g. KNX, DLNA, ) • interoperability among different Ecosystems is often still missing or is based on proprietary solutions (interfaces, protocols…). In some cases the industry is already working on this, but in other cases the market needs more stimulation. • interoperability among different Ecosystems can be achieved the easiest by customised gateways. Feasibility is a matter of cost and depends on available information and interface specifications. When scalability becomes an issue, the possibilities for deploying gateways become limited. Full migration to TCP/IP for layers 3 and 4, and W3C for layers 5-7 should then be considered. • The interest of Ecosystems in interoperability to other Ecosystems is limited. The reasons are: o short-term commercial need for protection of system functionality o fear for technical complexity and related reliability issues o additional costs, because interoperability is yet another requirement o the need to protect proprietary technology and a corresponding lead in competition o no authority over and/or knowledge of other ecosystems
We observe that the need for interoperability is mainly driven from the demands of the end user, followed by the service provider (business that want to create applications that exist across ecosystems) and the regulator. That does not inevitably mean that technology providers see a market in it. Table 9 shows a collection of arguments we have heard during the project that may drive or may hamper progress in interoperability in the SmartHouse:
Table 9: Who is interested in Interoperability?
Who is interested Industry; Vendors Service Provider End User; Builder in interoperability Why is there an To increase the To be able to To integrate, interest in market and to be offer new expand and use interoperability able to offer added services and new services and value to systems advanced service functions in a and products models to a large smart home number of subscriber Why parties are Protection of Protect services Concern about not interested in market segments in competition privacy and interoperability High dependencies implementation Cost High complexity Reliability Issues
The use cases we gathered are all very realistic and show the future need for interoperability and convergence from an end-user point of view. Realizing interoperability wherever end users need it is the main way forward for the SmartHouse.
We developed a tool with which engineers and policy makers can iterate from a use case to a technical architecture and implementation that fully exploit any opportunities for interoperability. The tool consists of: • A uniform template and reference model for plotting the use case • A long list of relevant SmartHouse Ecosystems and corresponding standards to choose from, for implementing the use case • A taxonomy and algorithm to create interoperability profiles, and to analyze the interoperability issues and opportunities of the Ecosystems and standards chosen • A solution space with recommendations to create interoperability where desired
The SHR Taxonomy of relevant ecosystems and standards is recommended as the foundation and direction for the Roadmap transition process, towards the identified interoperability levels. The development of the SHR Taxonomy started off with more than 6000 standards, classifying them, selecting the relevant ones and selecting the ones that play an explicit role in the SHR Use Case. Selection criteria were the documented relevance of standards in the market, the maturity of the standard (no drafts), the relevance to interoperability and convergence of SmartHouse specific applications, and the European uniformity of the technology. As such, the Project Team reduced the grand amount of 6000+ SmartHouse related standards in existence to a long list of about 200 standards that are now relevant for the Roadmap, grouped into 59 Ecosystems. From this a short list of 24 Ecosystems is constructed, which are the ones that appear in the use cases. The SHR short list of relevant standards should be seen as important reference for the SmartHouse transition.
We further conclude that a taxonomy for interoperability in the SmartHouse contains only 2 dimensions (generic Service Building Block and protocol layer), and that it complements the CWA IFRS in the sense that we provide the bricks and mortar to reach higher interoperability levels and as such a smarter SmartHouse. The taxonomy is based on two innovative paradigms. First, we use “reverse application” of the SOA principles to existing hardware and software of Ecosystems that were not created with SOA in mind. Second, we allow freedom in choosing the granularity of the dimensions in the taxonomy. If we would determine the granularity here and now, the taxonomy would immediately become useless for many use cases we cannot think right now.
From analysing the 11 use case we collected with the tools we developed, we were not only able to improve our methods in an iterative way, but also to extract generic observations about interoperability in the SmartHouse, and from that deduce recommendations to the EC, the ESOs and the market place. These recommendations are listed in the following chapter. 6 Recommendations
In this section we focus on recommendations for the European Committee (EC) and the European Standards Organisations (ESOs) on how to support the EU citizen to fulfill his need for convergence. We recall the definition of an Ecosystem: a group of interacting components that collectively perform the function of a standard. An Ecosystem, for instance, consists of the base standard of a protocol, but also test specifications, installation guidelines, safety requirements, certification programs, etc.
6.1 Application Layer
6.1.1 Discovery and sharing
R1. For any new service or device intended to be able to discover services/capabilities provided by other devices in other Ecosystems, a standardized discovery protocol between Ecosystems should be used. A conceptual framework like being used by DLNA offers a good starting point for this: it must be advocated to other Ecosystems including discovery functionality.
R2. Standardization should not only happen for discovery but also for the actual sharing of digital resources, thus limiting the proliferation of devices and network technologies in the home. Sharing becomes possible when proper standards for configuration (binding), operation (control) and management are in place. A conceptual framework like that being used by DLNA offers a good starting point for this, and must be advocated to other Ecosystems.
R3. It is recommended that implemented interoperability frameworks, containing standardized technologies for discovery, configuration, operation (sharing, control, etc), and management, are actually switched “on” by factory default and can be switched “off” by the user via an easily accessible and understandable user interface. However, the framework should take adequate precautions are to protect the functionality of applications which have critical requirements, such as fire, burglar, social and medical alarm systems. It should also be able to handle energy efficiency states of devices and not use disproportional amounts of energy itself.
6.1.2 Security, privacy, reliability, QoS
R4. Proper and well accepted standards for robustness (QoS, reliability, …) and security (encryption, authorization, …) in the SmartHouse need to be developed. They should protect the functionality of critical applications when they are integrated with other systems. Common definitions are required that allow different Ecosystems to specify their network performance requirements. This must be a broad cross-industry effort, and therefore will be a complicated venture needing strong coordination. For security we recommend to follow the W3C approach and protocols as much as possible. Also, security standards should allow for different levels of security, such that the appropriate level can be chosen and implemented for any given use case. 6.1.3 Convergence of control points for configuration, operation and management of devices, networks and applications.
R5. New devices and applications must be required to expose their user interface in an application-independent standardized way for at least four generic types of devices in the home with a human input/output function for remote control: the (smart) mobile phone, the PC/laptop, touch screen panels, and in-home displays. A likely option for exporting and controlling such user interfaces would be browser-based solutions. These solutions must be properly standardized, which includes an architecture, a protocol as well as Common Information Models. Existing Ecosystems such as W3C and DLNA, provide a good starting point, and should be used wherever possible, but also need to be extended and harmonized across device types.
6.2 Communication layers
6.2.1 Home Gateways
R6. Standardization of Home Gateway functionality must be stimulated. At the moment, such standardization is distributed over various organizations, such as HGI, Broadband Forum, CableLabs, and the various smart metering and home electronics working groups in ITU, ISO/IEC and CEN/CENELEC. These initiatives need to be coordinated.
6.2.2 IP, subnetting, routers, bridges
R7. For any new service or device intended to be able to communicate with devices in other Ecosystems, a standardized network-layer communication protocol between Ecosystems should be used. The only apparent option for such a protocol is IP. The use of IP as the network- layer (OSI layer 3) protocol of choice must be stimulated, and then preferably version 6 of it, i.e. IPv6.
R8. If support of the IP protocol (by implementing a TCP/IP protocol stack) is not yet feasible because of techno-economic reasons, the developers and maintainers of non-IP-based Ecosystems must be stimulated to define and standardize an IP gateway as well as a migration strategy to scalable all- IP architecture in the future.
6.3 Home Infrastructure
Proper network infrastructure standards should be developed also for back-bone network infrastructures in the SmartHouse. The field covered by these new standards and their quality should be such that they can be referred to in future regulations for new houses to be built. It should also be possible to implement and deploy these new standards relatively easily, in houses to be built as well as in houses to be retrofitted. For back-bone infrastructures in existing lived-in homes, the use of existing wiring (power-line, coax, phone line, etc., i.e. the so-called no- new-wires approach) may instead be considered, besides easy-installable new wiring solutions (e.g. plastic optical fibre). Wherever appropriate, future regulations may already refer to the existing EN 50173 parts 1 and 4.Compliance.
R9. Our taxonomy should be used as a reference guide to support any new SmartHouse European standardization effort. In order to stimulate this, the EC might consider initiating a procedure to certify new and existing standards whether and how far they fulfil a set of SmartHouse interoperability encouraging requirements/guidelines to be developed. This may take the form of a “SmartHouse Ready” program. These requirements/guidelines are recommended to follow the CWA IFRS classification of interoperability, and decide on a per Ecosystem basis which level of interoperability should be achieved for what functions. The requirements and guidelines thus form an industry “SmartHouse Code of Conduct (CoC)” for reaching interoperability as desired by the user.
R10. Current European standardization activities in the field of SmartHouse technologies need to be coordinated with a future Coordination Action (CA). The CA should have the goal to develop a well-accepted European SmartHouse CoC, based on the deliverables of the SmartHouse Roadmap project, and specify a “SmartHouse Ready Domain” to be added into the EC 2010- 2013 ICT Standardisation Work Programme. This SmartHouse CA should provide a well-coordinated and high-quality aligned collaboration with the identified relevant ESOs, consortia and fora, and with ISO/IEC JTC-1 SC25 in particular.
References
[1] CENELEC Workshop Agreement “CWA 50487 SmartHouse Code of Practice”, CLC/TR 50487:2005, November 2005. [2] European Commission, “2008 ICT Standardisation Work Programme”, Version 2.0, March 2008. [3] Geerten van de Kaa, “Standards Battles for Complex Systems: Empirical Research on the Home Network”, Doctoral Thesis, ISBN 978-90-5892-205-2, May 2009. [4] CENELEC Workshop Agreement “CWA 50560 IFRS An Interoperability Framework Requirements Specification for the Smart Home,” CLC/TR 50560:2010, May 2010. [5] European Commission DG INFSO Project SMART 2008/0049, “Towards a Future Internet: Interrelation between Technological, Social and Economic Trends”, Interim Report, February 2010 [6] N. Baken, E. van Boven, and R. Beitsma, “Broadband Infrastructures and Services Trans-sector thinking, the difference between A Beneficial Sector or Tower of Babel”, Journal of The Communications Network, 2003 (2) pp. 94- 98. [7] P. Budde, “Australia - National Broadband Network - Design and Deployment Strategies”,“http://www.budde.com.au/Research/Australia-National- Broadband-Network-Design-and-Deployment-Strategies.html [8] Bert Schumann, “Multifunctionality in Community Center: Energy consumption for town and citizens made transparent”, KNX Journal 2 (2010), p. 12. [9] Hans Schuppli, “Multimedia mit KNX-Anbindung in der Küche: Betty Bossi hilft übers Internet”, BusNews 3/05, p. 13 [10] “Trendsetting Technology and Efficiency Comfort and Security Around the Home”, KNX Award 2006. [11] Aldona Jarašūnienė, Gražvydas Jakubauskas, “Improvement of Road Safety using Passive and Active Intelligent Vehicle Safety Systems”, TRANSPORT – 2007, Vol XXII, No 4, pp. 284–289. [12] European Committee, “A Digital Agenda for Europe (2010-2020)”. [13] “Home Gateway Technical Requirements: Residential Profile V1.01”, HGI- RD001-R2.01 (2008) [14] “Minimum set of functions for metering of electricity, gas and thermal energy for domestic customers”, NEC Netherlands Technical Agreement NTA 8130 (e) (2007) [15] “Recommended Practice for Architecture Description of Software-Intensive Systems”, ANSI/IEEE 1471-2000, as well as “Systems and Software Engineering – Recommended practice for architectural description of software-intensive systems”, ISO/IEC 42010:2007. [16] ISO/IEC TR 29107-1:2010, “Information technology - Intelligent homes - Taxonomy of specifications -- Part 1: The scheme”. [17] ISO/IEC 7498-1:1994, “Information Technology – Open Systems Interconnection – Basic Reference Model: The Basic Model. [18] Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”, Prentice Hall, ISBN:0131858580, 2005. [19] Carolyn Simmonds Zúňiga, Telecom sector modeling from a functional perspective”, Master of Science Thesis, http://repository.tudelft.nl/assets/ uuid:99c0a51d-653d-4977-b605- e32913580eb7/MSc_Thesis_CSimmonds_final.pdf , July 2009. [20] N. Golmie, R.E. van Dijck, A. Soltanian, A. Tonnerre, and O. Rébala ‘Interference Evaluation of Blautooth and IEEE 802.11b Systems’, Wireless Network 9, pp. 201-211, 2003 A Use Cases
A.1 Template
Slide 1:
Slide 2:
Slide 3:
Slide 4:
Slide 5:
A.2 Intra-Ecosystem use cases
A.2.1 Use Case A-1:Intra-Ecosystem: multiple stand-alone services (voice, TV, internet, PC)
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 Windows PC networking protocol suite.(Microsoft Protocols & Platforms).
Type intra-Ecosystem Use case Nr/Title A-1: co-existing multimedia services (voice, TV, internet, PC)
User Experience (Required)
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 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 phone
Type intra-Ecosystem Use case Nr/Title A-1: co-existing multimedia services (voice, TV, internet, PC)
Implementation Examples (Optional)
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.> ¾ 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 function or by migrating to one common protocol as shown in use case A2.
A.2.2 Use case A-2: Intra-Ecosystem: migrating to DLNA Ecosystem and Remote UI
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.
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI User Experience (Required)
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI User Experience (Required)
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 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 Phone
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI
Implementation Examples (Optional)
Type Intra-Ecosystem Use case Nr/Title A-2: migrating to DLNA ecosystem and Remote UI
Additional Data (Optional)
A.2.3 Use Case A-3: Intra-Ecosystem: Safety and Security
Type Intra Ecosystem Use case Nr/Title A-3 Safety & Security
Services used Broadband Internet, Fixed Line Telephone, GSM, LAN AN Ecosystems VDSL; used HN Ecosystems EN 50173, Ethernet, Wi-Fi, TCP/IP, Bluetooth, DECT, Used 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.
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 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. ¾ 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.
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 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, 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.
A.2.4 Use Case A-4:Intra-Ecosystem: migrating to DLNA Ecosystem and Remote UI including content format and –protection issues
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 DVB, 3G, ADSL, used HN Ecosystems The same as in A1, plus DLNA. Used
Assumptions: ¾ See A-1 ¾ John living room TV, PC, NAS, printer and 3G phone are now DLNA compliant using IP/802 HN Ecosystem
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 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. ¾ 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.
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 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 spoofing.
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.
A.3 Inter-Ecosystem convergence use cases
A.3.1 Use-case B-1: Inter-Ecosystem Convergence: Remote operation of embedded generators
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, DLC IEC 61850, U-SNAP, KNX, DLMS/COSEM, Zigbee, EN 50523, HN Ecosystems used DLNA, TCP/IP, W3C, Wi-Fi
Assumptions: (Required) • 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 display in the house
Type Inter-Ecosystem Convergence Use case Nr/Title B-1: Remote operation of embedded generators
User Experience (Required)
B-1: Remote operation of embedded generators
Type Inter-Ecosystem Convergence Use case Nr/Title B-1: Remote operation of embedded generators
Implementation Examples (Optional)
A.3.2 Use case,B -2: Inter-Ecosystem Convergence: (Remote) Energy Management & Home Automation
Type Inter-Ecosystem Convergence Use case Nr/Title B-2 (Remote) Energy Management & Home Automation
Services used Energy Management, internet, mobile phone AN Ecosystems 2.5G, Power Grid used HN Ecosystems KNX, LON, G.hn, ZigBee, DLNA, TCP/IP, Ethernet, Wi-Fi Used
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
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
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.
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 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. ¾ 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).
A.3.3 Use case B-3: Inter-Ecosystem Convergence: (Remote) heating control, intrusion alarm, home automation, TV, voice and data communications
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 Power grid; POTS telephony, Satellite TV, Broadband used Internet HN Ecosystems KNX, TCP/IP, Ethernet, EN 50173 used
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.
Type Inter-Ecosystem Convergence Use case Nr/Title B-3: (Remote) heating control, intrusion alarm & home automation
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.
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
A.3.4 Use case B-4: Inter-Ecosystem Convergence: (Remote) energy control, intrusion alarm, home automation, TV, voice and data communications
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 Power grid; ISDN, Cable TV, Internet used HN Ecosystems KNX, EN 50173, Ethernet, TCP/IP used
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 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 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.
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.
Type Inter-Ecosystem Convergence Use case Nr/Title B-4: (Remote) energy control, intrusion alarm, home automation, TV, voice and data communications
Implementation example - HN Eco-systems used KNX Telecommand on power lines ISDN Internet Cable TV EN 50173 (-1 and -4 ) Ethernet and TCP/IP Proprietary security service Cable TV
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. A.4 Use cases for changing service providers
A.4.1 Use-case C-1: Changing Service Providers interactions: changing AN Ecosystem
Type Changing service providers Use case Nr/Title C-1: changing AN-Ecosystem
Appl. Services used TV, voice, internet, mobile AN Ecosystems ADSL, POTS used HN Ecosystems DVB, Ethernet, TCP/IP, W3C, DECT, Microsoft P&P, EN used 50173
Assumptions: See use case A-1
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.
Type Changing service providers 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 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
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.
A.4.2 Use Case C-2: Changing Service Providers interactions: open AN-Ecosystem
Type Changing service providers Use case Nr/Title C-2: open AN-Ecosystem
Appl. Services used TV, voice, internet, mobile AN Ecosystems ADSL, POTS used HN Ecosystems DVB, Ethernet, TCP/IP, W3C, DECT, Microsoft P&P, EN 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
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 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 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.
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
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.
A.4.3 Use case C-3: Changing Service Providers interactions: changing network operator as well as metering provider
Type Service provider change C-3: Changing network operator as well as metering Use case Nr/Title provider
Services used IPTV, Internet, energy management AN eco-systems ADSL, Fiber used HN Eco-systems EN 50173, Ethernet, Wi-Fi, G.hn, HomePlug, LON, KNX, used TCP/IP, UPnP, DLNA, TR-069, Open IPTV
Type Service provider change C-3: Changing network operator as well as metering Use case Nr/Title 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.
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
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
cabling
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
cabling
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
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
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
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: before
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
OSI-layers 3 and 4
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
OSI-layers 3 and 4
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
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
OSI-layers 5-7
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
OSI-layers 5-7
Type Service provider change C-3: Changing network operator as well as metering Use case Nr/Title provider
User Experience ¾ John wants to switch network operator, because the higher bandwidth in the access network guarantees a better IPTV and Internet experience. ¾ 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 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.
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.
Type Service provider change C-3: Changing network operator as well as metering Use case Nr/Title 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 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. ¾ 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.
B Acronyms
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 Networks "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. 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 an audio compression format specified by MPEG-2 Coding 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 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 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) CENELEC Comité Européen de Normalisation Électrotechnique (European Committee for Electrotechnical Standardization) 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 Telecommunications domestic or 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 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 DLNA Digital Living Network DLNA intends to solve the problems inherent in Alliance using 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 commissioning KNX installation ETSI European The European Telecommunications Standards Telecommunications Institute (ETSI) is an independent, non-profit, Standards Institute standardization organization in the telecommunications industry (equipment makers and network operators) in Europe, 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 standardization body of ETSI, specializing in fixed for 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, 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 these networks on level 1/2 (media extender or -terminator, bridge), level 3 (router) or level 7 (application layer gateway – ALG) HGI Home Gateway nonprofit organization launched by a number of Initiative 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, Task Force cooperating 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 Subsystem architectural 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. 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 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- Interface centric 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 Association physical 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 KNX Protocol specifies a system structure for commands controls and communications in buildings: the KNX media (twisted pair, radio frequency, power line or IP/Ethernet) to which all bus devices are connected, that are able to exchange information and interwork. Bus devices can either be sensors or actuators needed for the control of building management equipment such as: lighting, blinds / shutters, security systems, energy management, heating, ventilation and air- conditioning systems, signalling and monitoring systems, interfaces to service and building control systems, remote control, metering, audio / video control, white goods, etc. All these functions can be controlled, monitored and signaled via a uniform system without the need for extra control centers. KNX is approved as an International Standard (ISO/IEC 14543-3) as well as European Standards (CENELEC EN 50090 and CEN EN 13321-1) and Chinese Standard (GB/Z 20965). The KNX trademark logo guarantees their interworking and interoperability. 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 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 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 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 It was devised to automatically slow down the rate at Protocol 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 Communication devices connecting HN segments device 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 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 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 A private branch exchange (PBX) is a telephone exchange 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 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 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) d'Appareils equipment together. It is also known as Péritel Radiorécepteurs et (especially in France, where the term SCART is Téléviseurs practically unknown), 21-pin EuroSCART (Sharp's marketing term for an attempt to market the connector in the Asian region, 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 SIP Session Initiation The Session Initiation Protocol (SIP) is a signaling 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 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 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 Protocol for 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 Association trade 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 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 Consortium World Wide Web (abbreviated WWW or W3).
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 Interface consumer 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 Interoperability for wireless transmission of data using a variety of Microwave Access transmission 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 Language for 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.
C Long list of Smart House standards
For this project we constructed the following long list of standards which we deem to be relevant for the SmartHouse in 2010, by using the following selection criteria as a filter: • Only standards and specifications that have a documented relevance to interoperability and convergence of Smart House specific applications • Only standards and specifications that have a documented relevance in the market • Preferably European standards and specifications. International (global) standards and specifications only if relevant and European equivalent are not available. National standards and specifications only if international and European equivalents are not available. • Only finalized standards and specifications. No drafts or non-normative guidelines and technical reports. • Only the latest versions of the standards and specifications, and older versions if they are still supported in the market
Mostly it is obvious how an Ecosystem should be named and what standards belong to it. But sometimes it is not. In those cases we have taken the freedom to name the Ecosystem pragmatically and to group standards to an Ecosystem as we see the market operate them
Ecosystem Standards Titles of the standards Extra information equiv alents 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 (Or:Converting 826 Resolution 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) IETF RFC DHCP Options and BOOTP 2132 Vendor Extensions IETF RFC Traditional IP Network 3022 Address Translator (Traditional NAT) IETF RFC STUN - Simple Traversal of 3489 User Datagram Protocol (UDP) 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 1034 and Facilities IETF RFC Domain Names – 1035 Implementation and Specification IETF RFC The User Class Option for 3004 DHCP IETF RFC Vendor Options for DHCPv4 3925 IETF RFC Network Time Protocol 1305 (Version 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 1122 Hosts --- 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 2617 and 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 1661 (PPP) 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 2516 PPP 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 3551 Video Conferences with Minimal Control IETF RFC RTP Control Protocol 3611 Extended Reports (RTCP XR) IETF RFC MIME Type Registration of 3555 RTP Payload Formats IETF RFC The Secure Real-time 3711 Transport Protocol (SRTP) SIP IETF RFC SIP: Session Initiation Protocol 3261 IETF RFC Session Description Protocol 3264 (SDP) IETF RFC Uniform Resource Identifiers 2396 (URI): Generic Syntax". IETF RFC The URI for Telephone 3966 Numbers 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 2934 1 UPnP UPnP Device Control At the moment of Device Protocols (DCPs) writing, there are 23 Control different DCPs Protocols 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 Platforms Platforms Apps, … KNX CENELEC Home and Building Electronic ISO/I EN 50090 Systems (HBES) EC 1454 3-3, CEN 1332 1-1 CEN 13321- Open Data Communication in 2 Building automation, Controls and Building Management - Home and Building Electronic Systems - Part 2: KNXnet/IP Communication EN50065-1 Specification for signalling on low-voltage electrical installations in the frequency range 3 kHz to 148.5 kHz. General requirements, frequency bands and electromagnetic disturbances 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 23.228 Project; Technical v9.2.0 Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 9) 3GPP TS 3GPP TS 21.202 V8.2.0 There are many 21.202 (2009-12) Technical 3GPP and ETSI Specification 3rd Generation TISPAN standards Partnership Project; Technical building the IMS Specification Group Services eco-system. This and System Aspects; document lists them Technical Specifications and for Release 8. Technical Reports relating to Development of the 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. Voice Extensible Markup The W3C's 1 Language (VoiceXML) 2.1 standard 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 P2P Universal Computing P2P network, Consortium Ver 1.0 Technical mobile integration, 1.0 specification. overlay 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 communication USB between devices and a host controller (usually a PC). DLNA DLNA Digital Living Network Alliance Cross-device Networked interface for Device systems like smart Interoperabili house, and other ty Guidelines content August 2009 transformation and redirection applications. DVB ETSI TS 102 Transport of MPEG-2 TS 034 V1.4.1 Based DVB Services over IP and TS 102 Based Networks (and 826 V1.2.1 associated XML) and DVB- IPTV Profiles ETSI TS 102 Architectural Framework for 033 V1.1.1 the Delivery of DVB-Services over IP-based Networks TS 102 905 DVB-HN (Home Network) Defines mapping V1.1.1 Reference Model Phase 1 with UPnP TS 102 685 High-level Technical 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 Based on GEM Platform 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 OSGi Service Platform module system and Service Release 4, V4.2 service platform for Platform the Java Release 4, programming V4.2 language that implements a dynamic component model ISO/IEC ISO/IEC Information technology: Provides architects, 15018 15018:2004 Generic 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. Structured cabling ISO/I 50173:2007 Generic cabling systems systems for EC general-purpose 1180 telecommunications 1 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 Ver.2.2.1 Common Interface (CI); Part 1: related to DECT. Overview. EN 300 175is the base standard ETSI EN 300 DECT; Common Interface (CI); 175-2 Ver. Part 2: Physical Layer (PHL). 1.4.2 ETSI EN 300 DECT; Common Interface (CI); 175-3 Ver. Part 3: Medium Access 1.4.2 Control (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. Telecommunications (DECT) 1.4.2 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 iq) Overview and Requirements. plus extension ETSI EN 301 Digital Enhanced Cordless 650 Ver. Telecommunications (DECT); 1.2.1 multiple access profile (DAMP); Application-specific access profile (ASAP); TR-069 TR-069 Broadband Forum: CPE WAN . Amendment Management Protocol v1.1 2 (CWMP) TR-181 Device Data Model for TR-069 Issue 2 TR-157 Component Objects for CWMP Amendment 2 TR-106 Data Model Template for TR- Amendment 069-Enabled Devices 4 TR-140 TR-069 Data Model for Amendment Storage Service Enabled 1 Devices TR-142 Framework for TR-069 Issue 2 enabled PON Devices TR-196 Femto Access Point Service Data Model TR-135 Data Model for TR-069 Enabled STB TR-104 Provisioning Parameters for VoIP CPE TR-124 Functional Requirements for Issue 2 Broadband Residential Gateway Devices ITU-T ITU-T H610 Full Service VDSL – System H.610 architecture and customer premises equipment Wifi IEEE Local and metropolitan area IEEE 802.11 a,b,g. ISO/I 802.11-2007 networks--Specific Not all parts of the EC requirements -- Part 11: WLAN standard are 8802- MAC and PHY specifications relevant for 11 SmartHouse IEEE 802.11n 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 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- Wi-Fi Alliance: Wi-Fi Peer-to- Mesh-networking of to-Peer Peer (P2P) Specification v1.1 Wi-Fi devices (P2P) Specification v1.1 Ethernet IEEE 802.3 - Local and metropolitan area Includes all older ISO/I 2008 networks--Specific Ethernet standards, EC requirements -- Part 3: including GBE, 8802- CSMA/CD access method and optical, VLAN… 3 PHY specifications 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 Standard for port-based Also suited for Wi- 802.1X-2010 Network Access Control Fi, but mostly used (PNAC) for enterprise ethernet networks FireWire IEEE 1394- A high performance serial bus 2008 ETSI HF EG 202 116 Human Factors (HF); V1.2.2 Guidelines for ICT products and services; "Design for All" EG 202 191 Human Factors (HF); V1.1.1 Multimodal 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 V1.1.1 Profile 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 (Ergonomics of human-system interaction) HGI HGI-RD001- Home Gateway Technical R2.01 plus Requirements: Residential additional Profile V1.01 Release 2 and Release 3 standards UWB WiMedia WiMedia MAC-PHY Interface UWB middleware, ECM MAC-PHY 1.5 wireless USB A Interface 1.5 369, ISO/I EC 2690 8 WiMedia WiMedia MAC Specification ECM MAC 1.5; WiMedia PHY A Specification Specification 1.5 368, 1.5; WiMedia ISO/I PHY EC Specification 2690 1.5 7 Zigbee Zigbee Zigbee Specification ZigBee Specification Document 053474r17 ZigBee ZigBee RF4CE specification. For RF remote RF4CE controls specification. IEEE Wireless Medium Access 802.15.4 Control (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 Bluetooth 1.2 Backwards 1.2 compatible with 1.1 Bluetooth Bluetooth 2.1+EDR Enhanced Data 2.1+EDR Rate 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 4 physical, media access, and link layer specifications HomePlug HomePlug HomePlug Audio/Vido Power line alliance AV (networking over power lines) HomePlug HomePlug Green PHY (GP) Medium bit rate for GP 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) 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 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 0.0.4 network 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 0.1.1 QoS 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 003 Internet 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 007 simulation services; Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification NGN OIP/OIR ETSI TS 183 TISPAN: PSTN/ISDN 008 simulation services; Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR); Protocol specification NGN TIP/TIR ETSI TS 183 TISPAN: PSTN/ISDN 011 simulation services: Anonymous Communication Rejection (ACR) and Communication Barring (CB); Protocol specification NGN ACR & CB ETSI TS 183 TISPAN: PSTN/ISDN 006 simulation services; Message Waiting Indication (MWI): Protocol specification NGN MWI ETSI TS 183 TISPAN: PSTN/ISDN 005 simulation services: Conference (CONF); Protocol specification NGN CONF ETSI TS 183 TISPAN: PSTN/ISDN 016 simulation services; Malicious Communication Identification (MCID); Protocol specification NGN MCID ETSI TS 183 TISPAN : CCBS, CCNR Stage 042 3 ETSI TS 183 TISPAN: PSTN/ISDN 029 simulation 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 LonT building automation, controls alk, and management (Open Data ANSI Communication in Building 709.1 Automation, Controls and / CEA Building Management – 709.1 Control 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 EN50065-1 Specification for signalling on low-voltage electrical installations in the frequency range 3 kHz to 148.5 kHz. General requirements, frequency bands and electromagnetic disturbances Home IEC TR Home server conceptual Server 62318 model 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 A 340 information exchange between protocol for simple systems – Near Field wireless Communication – Interface communication and Protocol (NFCIP-1) between close 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 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 OpenIPTV OIPF OpenIPTV Forum Release 2 specifications for an Release 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 OpenTher The OpenTherm A protocol used in m Communications Protocol: A central heating Point-to-point Communications systems between a System for HVAC Controls central heating Protocol specification boiler 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/programm able 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 Phy of G.hn networking transceivers ITU G.9961 Data link layer (DLL) for DLL of G.hn unified 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 - TS 62045-1 Guideline for privacy protection of equipment and systems in use and disused ISO ISO 18012-1 Home electronic system: 18012-1 Guidelines for product interoperability Continua Continua To improve the quality of e-health design Version personal health care guidelines 2010 Design Guidelines HDMI HDMI 1.4 High definition Multimedia a compact interface Specification Ver.1.4 audio/video interface for transmitting uncompressed digital data WHDI WHDI Wireless High Definition enables wireless interface Interface uncompressed HD specification video delivery s throughout the home. Wireless ECMA-387 High Rate 60 GHz PHY, MAC 60 GHz phy and HD and HDMI PAL mac 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 application program interface related 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 distribution line carrier systems plc/dlc - Data communication communication over protocols the power systems beyond the house DLMS/ IEC 62056 ( Electricity metering - Data Device Language COSEM plus 62054 exchange for meter reading, Message and 62052), tariff 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 EN 13757 consists and remote reading of meters - of a part “data Part 2: Physical and link layer; exchange” , which is 13757-1, which is DLMS compliant. EN 13757-3 Communication systems for EN 13757 consists and remote reading of meters - of a part “data Part 3: application layer; exchange” , which is 13757-1, which is DLMS compliant U-SNAP USNAP Utility Smart Network Access a solution that Serial Port, enables any Home Interface Area Network Specification standard to use any vendor's Smart Meter as a gateway into the home. HES ISO IEC TR Information technology – This document 15067-3 Home Electronic System defines a typical (HES) application model – Part security system and 3: Model of an energy describes the management system for HES communications services needed. A high-level model for an energy management system using HES is presented . ISO/IEC A residential gateway model 15045 for Home Electronic Systems EN 50523 EN 50523- Household Appliances New standard – 1:2009 interworking – Part 1: there is discussion Functional Specification about 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
D Current initiatives
D.1 Coordinating bodies
There are, have been, and will be many people active and creating new technologies for the SmartHouse. Lack of innovation is not a matter of too little money poured in. It is more a matter of diminishing marginal returns: the planning confidence of the end user and his willingness to invest diminishes with increasing uncertainty about standards and technology. Coordination of the current activities is therefore badly needed. In this section we single out 5 bodies that try to pertain such a role in the market.
ISO/IEC JTC-1 SC25 The scope of ISO/IEC JTC-1 SC25 is standardization of microprocessor systems; and of interfaces, protocols and associated interconnecting media for information technology equipment, generally for commercial and residential environments, for embedded and distributed computing environments, storage systems, and other input/output components. Development of standards for telecommunication networks and interfaces to telecommunication networks is excluded. JTC 1/SC 25 has published among others Standards for cabling infrastructure for homes; Home Electronic Systems including data security, applications, gateways and management, UPnP and is known for its efficient co-operation with other standardization bodies on international and regional level.
HGI The HGI, founded in 2004 by major broadband service providers (BSPs), and joined by leading vendors of digital home equipment, is shaping the way that IP services are delivered to the home. The HGI publishes requirements for digital home building blocks. Those building blocks are the hardware and software in the digital home that connect consumers and services. They include home gateways, home networks, and home network devices. HGI projects are triggered by the services vision of their BSP members, and build on the technical collaboration of all the HGI participants. The HGI welcomes BSPs and vendors from across the globe. Their members represent the entire spectrum of players in the broadband home area.
ATIS HNET The ATIS Home Networking (HNET) Forum was established in February 2009 to enable the interoperability, interconnection, and implementation of IP-based home networking systems/services, by proactively examining technologies and services and developing solutions supporting the rollout of these technologies and services, when appropriate. This forum will place an emphasis on ATIS member company needs in coordination with other regional and international standards development organizations. The objectives of the HNET Forum are to: • Take a leadership role in home networking; • Become the de-facto industry group for home networking standards; • Centralize disparate technologies that are used in the home network; • Prevent overlap in standards development by engaging other SDOs; • Lastly, develop and recommend specifications or technical requirements as appropriate to bridge existing gaps that cannot be filled by other organizations.
ITU-T JCA-HN In March 2005, the ITU-T established a Joint Coordination Activity on Home Networking (JCA-HN). The scope of this JCA is the co-ordination of Home Networking standardization work both inside and outside of the ITU-T. The objectives are: • The JCA-HN will stimulate the progression of management standardization work in a well-coordinated way. • The JCA-HN will facilitate work assignments among the involved Study Groups and co-ordination among other relevant SDOs/fora when it is not clear where the work should be carried out and recommend an allocation of tasks. • The JCA-HN will identify areas of duplication and facilitate harmonization of the related specifications and identify areas where specifications are needed. To support these activities, the JCA-HN will actively manage the harmonization and/or development of said specifications in the relevant ITU-T SGs and SDOs/fora by closely working with them and tracking their results. • The JCA-HN will act as a point of contact within ITU-T and with other SDOs/fora to support Home Networking specification co-ordination, harmonization, and generation. • In carrying out the JCA-HN’s internal co-ordination role, participants in the JCA-HN will include representatives of relevant ITU-T Study Groups and other ITU groups. • In carrying out the JCA-HN’s external co-ordination role, representatives from other relevant SDOs/fora and regional/national organizations will be invited to join the JCA-HN.
CENELEC SmartHouse SmartHouse is part of the ICT Horizontal Area of CENELEC. The overall objective of the SmartHouse project is to grow and sustain convergence and interoperability of systems, services and devices for the SmartHouse that will provide the European Citizen with access to increased functionality, accessibility, reliability and security that a SmartHouse, with common and open architectures, will deliver in an expanding broadband infrastructure throughout Europe. Since 2001, the European Committee for Electrotechnical Standardization (CENELEC) and the European Commission DG ENTR have been working together to develop understanding of requirements for the SmartHouse and have recently completed work on a Code of Practice for SmartHouse operation. The SmartHouse Standardisation Initiative aims to support initiatives ensuring that Service Providers, Government, Health, Learning and local community Services can interact with all the citizens of the EU. They will then be confident that their systems are communicating into homes with networks, systems and equipment that are constructed, installed and set up to known standards, are interoperable and interactive and will deliver predictable information and receive intelligible responses from any home in the EU. It is the contention of the SmartHouse Standardisation Initiative that while currently the majority of connected (to the Internet with or without broadband) citizens are reasonably well informed and can manage the multiple inconsistencies and incompatibilities of current services and broadband delivery, when the objectives of eEurope i2010 and beyond are achieved, every citizen will have access to a range of Broadband services and applications. Of these, many will be uninformed, many will be in demographic groups that find the use of new systems non-intuitive, many will be disadvantaged by disability, poor health, poor education and by old age. One of the objectives of SmartHouse is to make the new technology of the connected home accessible to all. ICT Standards Board SmartHouse Standards Steering Group (ICTSB/SHSSG)
The ICT Standards Board (ICTSB) is an initiative from the three recognized European standards organizations CEN, CENELEC and ETSI, with the participation of specification providers as partners to co-ordinate specification activities in the field of Information and Communications Technologies (ICT), under three vital objectives: 1) analyze and co-ordinate requirements, 2) translate requirements into standardization programmes or projects, and 3) allocate work to the most appropriate specifying body.
The ICTSB/SHSSG is a forum including market players, to make recommendations to the standards bodies, industry and the regulatory authorities on Smart House systems and services standardization issues. Smart House systems and services to be dealt with by the group are restricted to residential houses. The group aims to: • review the progress of the current standards work programme and propose a vision for end-user focussed future market needs; • provide a coherent interface with the European Commission on Smart House policy issues including the relationship with supported research projects; • co-ordinate between individual technical groups on a more detailed level than the ICTSB can manage and identify standardisation gaps and potential overlaps; • act as a cross-fertilisation mechanism between the groups concerned. They have been the initiators of the SmartHouse Code of Practice [1] within the CENELEC SmartHouse horizontal initiative, and have been dormant since the beginning of 2009, in expectation of the CENELEC SmartHouse Roadmap results.
D.2 Relevant European R&D projects
Some relevant European R&D projects currently aiming at creating and improving SmartHouse standards are the following:
OPEN Meter
The main objective of the OPEN meter project is to specify a comprehensive set of open and public standards for AMI, supporting electricity, gas, water and heat metering, based on the agreement of all the relevant stakeholders in this area, and taking into account the real conditions of the utility networks so as to allow for full implementation.
The Scope of the project is to address knowledge gaps for the adoption of open- standards for smart multi-metering equipment and all relevant aspects – regulatory environments, smart metering functions, communication media, protocols, and data formats – are considered within the project.
The result of the project will be a set of draft standards, based on already existing and accepted standards wherever possible. These standards include the IEC 61334 series PLC standards, the IEC 62056 DLMS/COSEM standards for electricity metering, the EN 13757 series of standards for utility metering other than electricity using M-Bus and other media. These existing standards will be complemented with new standards, based on innovative solutions developed within the project, to form the new body of AM / smart metering standards. The resulting draft standards will be fed into the European and International standardization process.
The project is strongly coordinated with the smart metering standardisation mandate given by the European Commission to the European Standardization Organizations, CEN, CENELEC and ETSI.
The project should remove a perceived barrier to the wide scale adoption of smart metering in Europe, by ensuring that the requirements for smart metering can be met by products and systems based on open, international standards to ensure interoperability, and which are accepted and supported by the widest possible circle of stakeholders.
The OPEN meter project is financed by the European Commission within the Seventh Framework Programme, Area 7/1: Smart Energy Networks / Interactive distribution energy networks, Topic 7/1/1: Open-Access Standard for Smart Multi- Metering Services.
ICT ALPHA
The ALPHA project addresses the challenges of building the future access and all types of in-building networks for home and office environments. The project supports the evolution towards a cognitive network by dynamically utilising the resources of an optical network infrastructure to support a heterogeneous environment of wired and wireless technologies.
The project investigates innovative architectural and transmission solutions based on the manifold of optical fibres (single-, multi-mode and plastic) as well as wireless technology to support both wired and wireless services in a converged network infrastructure. The focus is on using the newest physical layer achievements and adequate management and control algorithms to reach a yet unprecedented end-to-end provisioned capacity for access and in-building networks at a fraction of the price of today’s technologies and to simultaneously include the transport of existing 2G/3G and Beyond 3G (B3G) signals whether they are Internet Protocol (IP) or non-IP-based.
The project starts with analysing the potential future bandwidth and quality-of- service (QoS) requirements which can be posed by future services in the scope of access and in-building networks such as Ultra HD Video, Local Storage Area Network, remote medical applications and others, and mapping those requirements into network specifications. The questions on the best applicable media, necessity for optical layer dynamics, compatibility of network types at the physical layer, foundations for better QoS provisioning and embedding of 2G/3G and B3G signals into the networks are then addressed within the project.
The project pursues experimental validations of close-to-maturity technologies in laboratory tests and field trials by intensively exploiting the three project test beds. The project also includes long-term research activities targeting to improve the existing technologies, and follows an intensive dissemination and standardisation strategy
OMEGA
The OMEGA project will set a global standard for ultra-broadband home area networks. The new standard will enable transmission speeds of one gigabit per second (1 Gbps) via heterogeneous communication technologies, including power line communications and wireless connections. Thus, OMEGA aims to make home area networks as easy to use as electricity from the socket, putting an end to the coverage limitations as well as the wiring clutter in the home.
With OMEGA’s gigabit home network, users will get easy access to high- bandwidth information and communication services such as tele-presence, 3D gaming, enhanced interactivity, virtual reality, high-definition video as well as e- health applications and services for the exchange of user-generated business or multimedia content
The interdisciplinary project consortium consists of 20 European partners from industry and academia. OMEGA is an Integrated Project in the ICT area co- funded by the European Commission under EU Framework Programme 7 (FP7). It is running for three years from January 2008 to December 2010.
FIGARO - Future Internet Gateway-based Architecture of Residential networks
Future Internet services are rapidly moving towards an increasingly heterogeneous landscape with end users capable of creating, storing and delivering content and applications. To address this diversity FIGARO proposes an evolvable Future Internet architecture based on gateway-oriented federation of residential networks. The Internet has evolved from a technology-centric core networks to a user- and content-centric scenario that must support millions of users creating and consuming a variety of content and applications. It must be able to accommodate new services with diverse requirements while coping with heterogeneous networks and systems. Through a strong and committed industry- driven consortium, FIGARO proposes a Future Internet architecture that is structured around residential networks. In this architecture, federated home gateways have a key role as integrator of different networks and services, and as a coordinator of Internet-wide distributed content management. As “always on” devices interconnecting the residential networks with the Internet and responsible for aggregating a multitude of devices and services, home gateways become essential components for an efficient management of physical resources and applications. By building on an experimental approach that includes test bed prototyping of solution, FIGARO will deliver: • The design of a novel content management architecture that enables distributed content backup, search and access. • A network optimization framework, leveraging community networks and heterogeneous networks. • A network management architecture with new network monitoring and real-time troubleshooting techniques. • A deeper understanding of novel Internet-based communication and service solutions for emerging sectors, such as energy management and e-health care. Furthermore, the integration of new sectors into the future Internet will spur trans- sector innovation and create new businesses. Finally, FIGARO is expected to result in technologies that will strengthen Europe’s position and give competitive advantage to European industry in the areas of Future Internet technologies and services, residential gateways and home automation.
IEEE P1905.1
This working group within IEEE Standards Association aims at defining a standard for a Convergent Digital Home Network for Heterogeneous Technologies. The standard defines an abstraction layer for multiple home networking technologies. The abstraction layer provides a common data and control Service Access Point to the heterogeneous home networking technologies described in the following specifications: IEEE P1901, IEEE 802.11, IEEE 802.3 and MoCA 1.1. The standard is extendable to work with other home networking technologies. The abstraction layer supports dynamic interface selection for transmission of packets arriving from any interface (upper protocol layers or underlying network technologies). End-to-end Quality of Service (QoS) is supported. Also specified are procedures, protocols and guidelines to provide a simplified user experience to add devices to the network, to set up encryption keys, to extend the network coverage, and to provide network management features to address issues related to neighbor discovery, topology discovery, path selection, QoS negotiation, and network control and management.
E List of involved parties
The SHR – project deliverables are endorsed by this list of organizations.
Enterprise/organisation Name participant ABB Stotz Kontakt GmbH Hans Rohrbacher Abilia AB Peter Linghammar ABITANA N.V. Robert Laes AFME Beatriz Novel Alcatel-Lucent Christele Bouchat Alliander Bram Reinders BBC Peter Kerry BEAMA Limited John Parsons Bouygues Telecom Eric Bertrand Brunel University Malcolm Clarke Bticino S.p.A Stefano Tomasina CANDY HOOVER GROUP Davide Braggion CECED Paolo Falcioni Continua Michael Struebin Corporate Standards – Chairman CLC TC205 Dominique Beck CREG Christian Fontaine Danish Standards Foundation Niels Madelung DG ENTR – European Commission Emilio Castrillejo DG INFSO – European Commission Regilio Segovia Domotica Platform Nederland Boudijn Uythof DS2 Milan Erbes Eaton Electrical Pedro de la Horra Calomarde ECA David Stefanowicsz Echelon BV Sandra Top EDF Energy Martin Bell Elster Pieter Claes eMeter Neil Beckwith eMeter's software Alicia Carrasco Energy Services Network Association Mark Ossel ERGEG Ferruccio Villa ESMIG Klaus Axt Euralarm Secretariat Brian Harrington Expertel Fred te Riet o/g Scholten Expertel Guido van Alphen GEO Ltd Simon Anderson GFI - Association for the support of electrical installation Juergen Tretter Ghent University Koen Casier Ghent University – IBBT Jelle Nelis Ghent University Tom Verschueren GL Industrial Services Ltd. Rooktabir Nandan Sauba GPX International Ltd Egbert Bouwhuis Hager Group Arie Crielaard Hager Rob van Veldhuizen Enterprise/organisation Name participant Holst Centre / Imec Netherlands Arjan Breeschoten Holst Centre / TNO Jeroen van den Brand homefibre digital network gmbh Joseph Faller Homefibre digital network gmbh Gerhard Treffner IBM Nederland Alex Bouw IGNES Yves Boudou Infeneon Technologies AG Ingolf Karls Infineon Technologies AG Leo Stuehler Instituto Universitario de Investigación en Ingeniería de Aragón Javier Escayola Institute of Telecommunications and Multimedia Applications Inigo Artundo Intel Corporation SA Jean-Luc Detrez Interfusion Services Haris Neophytou ISAD e. V. Olaf Schwab ISO/IEC JTC1/SC25 Walther von Pattay Itron Marcel ten Cate ITS-Norway Asbjorn Hovsto KEMA Erik de Jong KEMA Consulting Robert Lassche KNX Association Joost Demarest Koninklijke Philips Electronics N.V. Eric van Nijhuis Lantiq Daniel Scharfen LEGRAND France SA Alain Lambert Lobeco Beveiligingen B.V. Reinier Lolkes de Beer Lonmark International Ernst Eder Mitsubishi Electric R&D Centre Europe Christophe Mangin Motive / Alcatel-Lucent Hugo Verbandt Nagra / Kudelski group Antoine Burckard National Physical Laboratory Michael Collett NEN / Netherlands Standardization Institute Marlou Bijlsma NEN / Netherlands Standardization Institute Shirin Golyardi NEN / Netherlands Standardization Institute Charlotte Mosies NEN / Netherlands Standardization Institute Ton van Bergeijk NEN / Netherlands Standardization Institute Bart Wams Niko NV Danielle van Hertum Niko NV Stijn van de Veire Norwegian post and telecommunication authority Svein Roar Jonsmyr Open IPTV Forum Yun Chao Hu Orange / France Telecom Philippe Calvet Orange Labs Poland Andrzej Tymecki Panasonic R&D Center Germany GmbH Hamid Amir-Alikhani Panasonic R&D Center Germany GmbH Ralph Becker Panasonic R&D Center Germany GmbH Lee Gould Product Marketing Director David Egan SAGEMCOM Jean Grappy SAGEMCOM Marc Legourrierec SCHNEIDER ELECTRIC Philippe Carpentier Sharp Laboratories of Europe Limited Lloyd Lukama Sharp Laboratories of Europe Ltd Martin Tillin Enterprise/organisation Name participant Siemens Udo Meinholt Sigma Designs Bent Sorensen Sistema Casa S.a.s. Paolo Mongiovi SPiDCOM Technologies Willy Scott SSBT spa Mike Bargauan Stichting Expertel Guido van Alphen STMicroelectronics Paul Rottier Strategic Engineering Peter Colebrook Suters Consultants Beheer B.V. Tom Suters TAHI (The Application Home Initiative) Alan Knight Scott TAHI Steve Pattenden Telecom Italia Secondo Gallo The Royal Bank of Scotland Peter Potgieser T.N.O. Frank den Hartog UL International Demko A/S Ole Albert Nielsen Universidade Lusiada de Lisboa C. Gomes UTC Fire & Security Dominique Taudin VTT Technical Research Centre of Finland Veijo Lappalainen Whirlpool Europe Srl Marco Signa Zigbee Alliance Europe Michael Bradley Zigbee Alliance Steven Ettles Zigbee Alliance B. Ritter Zigbee Alliance Larry Taylor