CEBus Demystified: The ANSI EIA 600 User's Guide

CEBus Demystified This page intentionally left blank. CEBus Demystified The ANSI/EIA 600 User’s Guide Grayson Evans...

Author: Grayson Evans

121 downloads 708 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

CEBus Demystified

This page intentionally left blank.

CEBus Demystified The ANSI/EIA 600 User’s Guide Grayson Evans

McGraw-Hill New York • Chicago • San Francisco • Lisbon • London Madrid • Mexico City • Milan • New Delhi • San Juan • Seoul Singapore • Sydney • Toronto

abc

McGraw-Hill

Copyright © 2001 by The McGraw-Hill Companies, Inc. All rights reserved. Manufactured in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher. 0-07-141465-7 The material in this eBook also appears in the print version of this title: 0-07-137006-4.

All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps. McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please contact George Hoare, Special Sales, at [email protected] or (212) 904-4069.

TERMS OF USE This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensors reserve all rights in and to the work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill’s prior consent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the work may be terminated if you fail to comply with these terms. THE WORK IS PROVIDED “AS IS”. McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom. McGraw-Hill has no responsibility for the content of any information accessed through the work. Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise. DOI: 10.1036/0071414657

Want to learn more? We hope you enjoy this McGraw-Hill eBook! If you’d like more information about this book, its author, or related books and websites, please click here.

Notable Conventions CEBus CEBus Standard According to guidelines published by the EIA, the trademark “CEBus” is an adjective, not a noun. “CEBus” should always be used with the word “standard,” “compliant,” or other appropriate word since CEBus refers only to the ANSI/EIA-600 standard. A product that complies with ANSI/EIA-600 should be referred to as a “CEBus standard compliant” product, or “CEBus compliant.” However, to make this book easier to read (and to write), the word “standard” is often implied. Wherever the word “CEBus” is used, assume this means “CEBus Standard.” In this book, CEBus, EIA-600, and ANSI/EIA-600 are used to refer to the same official standard: ANSI/EIA-600

Conflicts with the CEBus Standard If there are any differences between the information in this book about the CEBus Standard and the information contained in ANSI/EIA-600, the information in ANSI/EIA-600 should prevail.

Copyright © 2001 by The McGraw-Hill Companies, Inc. Click here for terms of use.


For more information about this title click here.

CONTENTS

Chapter 1

Chapter 2

Chapter 3

Introduction

1

What Is CEBus? Why Residential Networks? Why Make a Standard? CEBus Development Goals Development History This Book’s Goals How This Book is Organized

2 3 5 6 6 8 8

CEBus Document Overview

11

EIA-600 EIA-600 Attributes The Standard Parts An Introduction to EIA-600 Parts The Physical Layers The Protocol The Language The Design Constraints Security Issues

12 12 13 16 16 17 18 19 20

The CEBus Benefit

23

The Benefits of Networked Products What CEBus Products Say Control Messages Status Messages Typical CEBus Applications The Future Potential The Plug-n-Play Concept Interoperability Defined Communications Level Interoperability Application Level Interoperability Scenario Interoperability

24 25 25 26 26 28 29 30 30 31 33


viii

Contents Chapter 4

Chapter 5

CEBus Basics

35

How CEBus Works—An Overview The CEBus Product Model Nodes Network Communications Models Network Control Model CEBus Reference Architecture and Media Channels Packets and Messages Symbol Encoding Network Attributes CAL:What CEBus Products Say to Each Other CAL View of Products

36 36 37 40 41 42 44 47 48 50 51 51

The Media and Physical Layers

53

The CEBus Network Topology Architecture Assumptions Node O Router and Brouter Requirements Medium, System, and Global Networks Connection to the Outside World The PL Network Power-Line Topology CEBus Signaling on the PL Packet Encoding Physical Layer Implementation PL Performance The TP Network TP Cable and Wire Use TP Control Channel TP Physical Layer The CX Network The Cable CX Network Topology Cable Connectors and Outlets Node O Distribution Device Coax Control and Data Channels CX Physical Layer CEBus RF CEBus RF Signaling

54 54 55 56 60 61 62 62 64 67 68 70 71 71 74 75 76 77 78 79 80 81 83 84 84

ix

Contents RF Control Channel Encoding RF Physical Layer

Chapter 6

Protocol A Little Protocol Background CEBus Protocol Overview The ISO vs. CEBus Model The Peer-to-Peer Layer Model Transmission Failures Application Layer vs. the Application Packet Format Layer Responsibilities Application Layer The APDU Header Basic Service APDU Extended Service APDU Basic Service Details Explicit_Invoke Service Synchronous Service and the Invoke_IDs Reject APDUs When to Use What Service Application Layer Extended Services Authentication Authentication Algorithms Encryption Using Secure Services Network Layer The NPDU Header Network Layer Extended Services More on IR/RF Packets and Duplicate Rejection IR/RF Packet Examples ID Packets Data Link Layer DLL Structure Packet Format EOFs, EOPs, and Leading Zero Suppression Channel Access Protocol DLL Packet Delivery Services Unacknowledged Service Addressed Unacknowledged Service

85 87

91 92 92 95 95 97 98 98 99 99 101 101 103 105 105 110 112 112 114 115 116 117 117 118 119 122 130 131 133 135 136 137 139 140 145 146 146

x

Contents

Chapter 7

Addressed Unacknowledged Sequence/Address Association Acknowledged Service The Physical Layer The PL and RF Medium SES CEBus Addresses The System Address The Node Address Acquiring and Keeping Addresses Implementation Issues Layer System Management

147 148 154 156 157 157 158 160 160 161

CAL

163

CAL Goals How CAL Models the Consumer Product World The Context Data Structure Contexts Objects Object Definitions Context Data Structure Object Network Types Object Binding: How Contexts Work Together Context Examples The Universal Context Context Control Object Determining Product Capability Where Do Contexts Come From? Messages: Object Communications Command ASDUs Response ASDUs Methods Message Generation Implementation Example Resource Allocation Address Resources and Address Allocation Node Addressing Address Self-Acquisition The CAL Interpreter Transporting Non-CAL Messages Generic CAL (ANSI/EIA.721) Differences between Generic and CEBUS CAL

164 165 166 166 167 171 178 179 180 185 186 190 191 191 192 192 193 195 199 204 204 205 207 208 213 214 215 215

xi

Contents Chapter 8

Chapter 9

Appendix A

Interoperability and HomePnP

220

HomePnP Overview Some New Ideas Interoperability and HomePnp State Vectors Configuration Additional Problems Addressed by HomePnP

220 222 223 224 225 225

Product Development

227

Design Considerations for Networked Products Security Addressing Interoperability Partitioning of Processing Tasks Creating CEBus Applications: An Overview The Design Problem Getting It Built Product Benefits Minimum Requirements—Deciding What to Implement Data Link Layer Network Layer Application Layer CAL Certification (ANSI/EIA-633) Plug Lab

228 229 230 231 232 234 235 244 245 246 246 247 247 248 249 250

Object Definitions

251

Common Object IV Labels Manufacturer IVs Object Tables Object Categories Table Notes 03 Data Channel Receiver 04 Data Channel Transmitter 05 Binary Switch 06 Binary Sensor 07 Analog Control 08 Analog Sensor 09 Multiposition Switch

251 252 252 252 253 254 255 256 256 257 258 259

xii

Contents 0A Multiposition Sensor 0B Matrix Switch 0F Meter 10 Display 11 Medium Transport 13 Dialer 14 Keypad 15 List Memory 16 Data Memory 17 Motor 19 Synthesizer/Tuner 1A Tone Generator 1C Counter/Timer 1D Clock

Appendix B

260 261 262 263 264 265 266 267 268 269 270 271 272 273

Sample Contexts

275

Context 10 (Audio) Context 21 (Light)

275 280

Appendix C

Response Error Codes

285

Appendix D

CEBus Resources

287

Index

289

CEBus Demystified


CHAPTER

1 Introduction


2

Chapter One In April 1984, 12 people representing 12 member companies of the Electronics Industries Alliance (EIA) met in a hotel room in Washington, D.C. They were there at the invitation of the EIA Consumer Electronics Group to help formulate some form of common communication standard for consumer devices used in homes. This standardization effort was a result of an earlier attempt to develop a common infrared remote control standard. If these 12 men had any idea that they were about to begin a task that would occupy a considerable portion of their lives—and the lives of dozens of others—for the next 10 years, it is unlikely that they would have continued the task. But, of course, they could not possibly have known what they were about to undertake. What these people started is known as the Consumer Electronic Bus (CEBus) home automation communication standard—a standard that defines a communications protocol, language, and media interface specification that enables any device in the home to communicate with any other device. The CEBus effort, which culminated in 1992, was an impressive accomplishment. No other standard-setting activity that the EIA has ever undertaken approaches CEBus in scale and complexity. More than 400 people and companies were involved in the successful development of CEBus. You are about to reap the benefits of their effort!

What Is CEBus? CEBus (pronounced “see-bus”) is the common name for ANSI/EIA-600, a communications standard for residential consumer products. The standard specifies how products send and receive information, the media available to use the products, and what products say to each other. CEBus solves the traditional problems of integrating products and systems made by different manufacturers by establishing a standard, reliable interface to each CEBus-compliant product in the home. The standard provides A standardized physical interface between devices in the home so that information can be easily and reliably exchanged A standardized way for devices to interoperate and “talk” to each other using a common language

3

Introduction

CEBus enables stand-alone products to become networked products, sharing information and product “resources.” Its standardized common language ensures built-in interoperability and a rich set of capabilities. CEBus also establishes a unified, high-quality cabling standard to handle all of the data communication needs of the home (audio, video, CEBus product communications, computer data, etc.) for the foreseeable future. The cabling standard has become the basis for all current residential infrastructure wiring products and was the basis of the revised ANSI/TIA/EIA-570A residential wiring standard.

Why Residential Networks? During the 1990s, there was a growing need to solve a related set of communication problems in the home. These problems are the result of new technology products in the home (such as home computers, home automation systems, home theater, energy management systems, and telecommunication products) and the rise of wideband service providers. Deregulation of the communication industry in the United States has created new market opportunities for service providers to offer access to a host of wideband information “services.” Cable TV companies can now provide telephone and other high speed two-way communication services. Telephone companies can provide cable TV services such as pay-per-view movies and information services, as well as voice and data communications. Utility companies can provide appliance monitoring and energy management services, and can offer variable electric rates based on their access to and ability to control in-home appliances. These new technologies depend on reliable communications in the home. Present residential wiring will not be capable of providing these services due to the poor quality of most existing in-home telephone and coaxial cable. A new residential network technology is needed. The network must provide three things: A universal, low-cost method for devices in the home to communicate regardless of manufacturer. There must be a way to distribute control and data about the operation of appliances and systems throughout the home. This information allows products to interoperate— sharing information such as time and temperature, the current electric rate, house occupancy, and so on. Without this capability, there can never be a reasonable market for home automation.

4

Chapter One A reliable way to provide for in-home distribution of wideband (wide area network) outside services. Wideband services can be broadly categorized as part of the “information superhighway.” These services include delivery of digital telephony, pay-per-view video, interactive gaming, electrical load management, “house sitting,” computer network access, and the like. These services will arrive at the home via the local cable company, the telephone company, the power company, and wireless (RF) service providers. Many of these services require bandwidths that are not supportable with the present wiring (telephone, cable) in the majority of homes. A reliable way to distribute wideband services that originate from products in the home. There must be a way to distribute in-homegenerated information. This includes video and data from multimedia computers, home theater equipment, VCRs, security cameras, audio equipment, and the new generation of high-tech “set-top boxes.” Audio and video distribution is becoming increasingly important as consumers become more media oriented. CEBus meets all of these needs by forming a local area network in the home for the distribution of in-home and outside data and services. The network has these characteristics: Provides for distributed rather than centralized control Supports the distribution of audio, video, and data, as well as control messages Uses a variety of physical transmission media Provides a flexible application language Enables very-low-cost implementations that are intended for consumer products CEBus delivers a common product interface and a common network infrastructure. It specifies completely the use of the power-line wiring (PL), radio frequency (RF), and infrared (IR), and the installation and use of twisted-pair (TP) and coaxial (CX) cable. The standard is flexible enough to allow CEBus compliant products to be used in existing homes using the PL, RF, IR, and most existing TP wiring. The standard completely specifies how products connect to the network and the communications protocol.

5

Introduction

Why Make a Standard? The committee members understood that future consumer products will be interconnected and that future capabilities will demand access to data and control information from outside the home and between products in the home. A standard for product interconnection is inevitable to future consumer product growth. So, why make one from scratch? Standards arise from a dominant usage of an existing technology— some dominant product manufacturer establishes a technology and other companies copy it—or from a standards-setting organization (EIA, IEEE, or ANSI) at the request of an industry group of companies. In the case of a residential product standard, one that interconnects all products in the home, there is no one product category that could dictate a standard, similar to how IBM and Microsoft standardized the personal computer industry. There are too many unrelated product categories. Because no one product manufacturer is dominant enough to generate a de facto standard, it had to come from a standards organization. To establish a standard from “scratch,” it is essential to set the requirements up front and ensure that there is agreement from all participants before undertaking the technical details. The three requirements for CEBus that were established early in the process are: 1. To allow introduction of new products and services to homes at minimum cost and confusion to consumers. This is the whole point of CEBus. It is designed to remove the entry barrier for products that can communicate. The standard opens the potential for hundreds of new products and services for the homeowner, but it must do so without causing confusion in the marketplace. If the committee on the CEBus technology used a litmus test, it is the test of “…minimum confusion to consumers.” A reliable network technology that is installable by the average homeowner is difficult. Some confusion is inevitable, but every effort was made to minimize any additional confusion. 2. To meet the majority of anticipated home control and information distribution requirements with a single multimedia network standard. CEBus had to handle the control requirements of all existing appliances and products in the home, as well as any future device that manufacturers might think up. It must be usable on any or all of the media present in the home, such as the power line or

6

Chapter One telephone wiring. It must handle the bandwidth requirements for distribution of outside services to any device in the home. 3. To minimize the redundancy of control and operation methods among products in the home. In theory, CEBus can actually simplify the operation of appliances and products in the home by enabling a common interface to develop. For example, CEBus has the capability to enable a television to present menus to allow setting of thermostats, microwave ovens, VCRs, security systems, and the like, with a common onscreen interface. To meet the requirements for CEBus, the technical goals for the technology were clear: it must be retrofittable; it must support distributed intelligence; it must not be product specific; it must have an open architecture; and it must be expandable. The goals were met by IS-60, and products demonstrating the capability were built.

CEBus Development Goals A stated motivation for developing CEBus is to encourage new companies to enter, or reenter, the consumer electronics business. CEBus is viewed by many of its developers, including the EIA, as a major commitment to help U. S. companies regain a foothold in consumer product manufacturing. The standard will spur the development of literally hundreds of new consumer products, and provide an opportunity for small and startup companies to get into (or back into) the consumer electronics business. By providing an open yet controlled standard, CEBus opens the home automation market to a large number of new product ideas—most previously unthought of. You will, undoubtedly, see a host of new products from many new (and existing) companies that have decided to enter the market due to the perseverance of the EIA and the CEBus committee.

Development History The beginning of CEBus occurred in April 1984, when representatives of 12 companies attended the first EIA-sponsored meeting in Washington, D.C., of the Consumer Electronics Bus Committee (CEBC).

Introduction

7 1984—During that first year, the basic scope of the “bus,” as it was called, was established and the major work tasks were assigned to a set of working groups. 1985—The committee started work on a field-test program to determine the characteristics of residential power-line wiring systems by taking actual measurements from hundreds of homes throughout the country. A Language Working Group was formed to begin work on a common product command language. 1986—The committee adopted Homenet (GE’s power-line protocol that GE had developed for HomeMinder) for the foundation of the CEBus protocol. “CEBus” became the de facto name for the standard. 1987—Early versions of the PL physical layer were built using the 1 Kbps ASK technique and preliminary testing was performed in several houses. 1988—In early 1988, the committee decided to demonstrate CEBus in a booth at the 1989 Winter Consumer Electronics Show. The first pass of the language protocol and PLBus physical layer specification was completed. 1989−1990—The first versions of the TPBus, CXBus, SRBus, Node 0, and Application Layer documents were completed. The ASK PLBus and protocol specifications were released for industry ballot, marking another major milestone. 1991—The Intellon spread-spectrum transceiver technology was selected to officially replace the existing ASK PLBus standard. The new PL specifications were completed in draft and released for ballot. 1992—On November 6, the CEBus Committee held its sixty-seventh meeting in Victoria, B. C., Canada. IS-60 became an official EIA document. 1993—The EIA incorporated the CEBus Industry Council (CIC) to serve as a cross-industry association for companies developing CEBus products and services. 1995—IS-60 underwent a final review of changes in an effort to become a joint ANSI/EIA standard: EIA-600. Each part of the standard was reballoted as an EIA-600 document. 1998—Version 1.0 of the Home Plug-and-Play specification was released, incorporating CAL as a standard interoperability language. 1999—The generic CAL specification, providing transport protocol independence, was released as ANSI/EIA-721.

8

Chapter One

This Book’s Goals This book was written to supplement the EIA CEBus standard document. While this book may be all you want to know about the standard, it does not eliminate the need to consult the EIA-600 document if you plan to develop CEBus products or adapt an existing product. The detailed specifications in the standard are essential. Rather, this book is designed to make the standard understandable. It provides a technical overview for nearly all sections of the standard, and provides implementation information that is not available elsewhere. The book provides many diagrams, tables, and explanatory material that will prove beneficial in getting the most from the standard documents. This book covers only the Node communications protocol, the protocol intended for consumer devices. It does not cover the Router and Brouter communications protocols described in Volumes 5 and 6 of the standard. However, because the Router and Brouter protocols are a modified subset of the Node protocol, they should be easy to understand once you understand the operation of the Node protocol.

How This Book Is Organized Chapter 2, CEBus Document Overview, provides introductory material on the standard, including an overview of the CEBus documents, how the standard is organized, the design goals, the design constraints, the target environment, and how the goals were achieved. It also contains a brief development history. Chapter 3, The CEBus Benefit, details some typical applications, describes residential network goals and advantages, and what problems CEBus solves. Chapter 4, CEBus Basics, provides a technical introduction to network concepts, terminology used in the standard, and an explanation of some of the basic technology adopted in CEBus. You should read this chapter before you read Chapter 6, 7, or 8. Chapter 5, CEBus Media and Physical Layers, describes the physical layer portions of the standard, including network topology, symbol encoding, the physical layer interface to each media, and the electrical and mechanical requirements of each medium. This chapter covers most of the material given in EIA-600.3 (PL/RF Symbol Encoding, Symbol Encoding, PL, RF, IR, CX, TP, and Node 0).

Introduction

9 Chapter 6, CEBus Protocol, describes the network protocol used by CEBus. This chapter provides an overview of the protocol requirements and of the basic attributes of the protocol used by CEBus, and covers the requirements of each nonphysical protocol layer (Data Link, Network, and Application). This chapter covers most of the material in EIA-600.4. Chapter 7, CAL, provides a complete description of the CEBus language. The chapter describes how to use CAL, what products say to each other, how messages are generated, CEBus product interoperability goals, and the design requirements of a CAL language interpreter. This chapter covers most of the material given in EIA-600.8 (CAL Language). The chapter also includes an overview of the generic CAL specification (ANSI/EIA-721). Chapter 8, Interoperability and HomePnP, provides an overview of the theory of interoperability, describes some of the problems inherent in product interoperability that CEBus does not address, and discusses how the Home Plug-and-Play specification resolves these problems. Chapter 9, Product Development, discusses the development process of making a CEBus-compliant product, including networked product considerations. This chapter uses what was learned previously in the book to convert a traditional stand-alone product into a CEBus network product. The Appendix contains reference material on the protocol and CAL. A list of CEBus resources (trade associations, manufacturers, consulting companies, and so on) is also given.


CHAPTER

2



12

Chapter 2 This chapter introduces the standard documents and provides the necessary background material to understand why the standard is the way it is, and why certain design tradeoffs were made. The design constraints of the residential environment set many design and operating limits on the complexity of CEBus. The design goals and the design constraints often conflicted, thereby limiting the CEBus capability. However, nearly all goals were met and the standard provides a high-speed, reliable communication network for a wide range of products in the home.

EIA-600 The CEBus standard was developed by the Electronics Industries Alliance (EIA). The EIA is one of the oldest trade organizations in the United States, and is responsible for many of the consumer and commercial standards used by electronics industries throughout the world (for example EIA-232, EIA-485, telephone, television, radio, and audio standards). CEBus is available for purchase, as are all EIA standards, from Global Engineering as a two-volume set (see the Appendix for address and number). CEBus is just a document. While it specifies how all parts of the network are built and installed, it is neither hardware nor software, nor does it describe how to build hardware or software. There is no such thing as “a CEBus.” There are only CEBus-compliant products and devices. Manufacturers create or adapt existing products to comply with the hardware and software portions of the standard applicable to their product.

EIA-600 Attributes EIA standards are usually written as open, performance specifications, and EIA-600 is no exception. EIA-600 was written using three EIA criteria: It is a performance specification. The standard describes how CEBus devices must perform, not how they are built. The standard gives only the electrical and timing specifications of a CEBus device as seen from the network. The performance specifications are written in terms of the packet content, transmission timing, protocol performance, and network electrical and physical characteristics.


13

It is open and nonproprietary. Open means that the development, review, and modification of the standard is available to anyone with a legitimate business interest in the technical accuracy and usability of the standard. More than 400 companies have contributed to the development of CEBus. These companies have a tremendous influence on the development of capabilities, operation, and so on. You can also participate in the continued refinement and support of the standard. The diversity of supporting companies contributes to the strength of CEBus. It is a minimum requirement for compatibility. The CEBus standard describes those features and capabilities that must be implemented for products to communicate reliably in the home using the CEBus protocol. It allows for easy extensions as needs change and future product categories are invented. It allows wide flexibility in implementation. Manufacturers are free to meet the standard using any combination of hardware or software, and by using existing or new components.

The Standard Parts The CEBus standard can be divided into three major areas: the physical media and media topology (power line, coax, twisted-pair, and so on, and how they are connected); the communication protocol (used for network access and constructing messages); and the communication language (allowing devices to communicate using a common set of commands). The standard is divided into eight volumes, and volumes are divided into numbered parts. The description of each volume in the following paragraphs gives the EIA-600 volume/part number. EIA-600.10 Introduction This volume covers the overview, background, scope, and goals of the standard. It also includes a set of minimum requirements for CEBus-compliant products, and a set of word usages and global definitions for the entire standard. EIA-600.20 Description This volume provides an overview description of the EIA-600 standard starting with the general architecture; a discussion of the media and topologies used with each medium; and an overview of the message protocol and command language used by

14

Chapter 2 all EIA-600 devices. As of the publication of this book, this section was still incomplete. EIA-600.30 Physical Layer and Media This volume consists of nine parts covering all of the EIA-600 allowed media and the physical layer interface to the media (OSI Layer 1), plus a discussion of all network support functions, including Router and Brouter physical layer descriptions. EIA-600.31 PL, Physical Layer. Describes the physical layer interface requirements for connection and use of the residential power-line wiring. EIA-600.32 TP Physical Layer. Describes the physical layer interface requirements for connection and use of twisted-pair cabling, including the telephone wiring. EIA-600.33 Coaxial Cable Physical Layer. Describes the physical layer interface requirements for connection and use of a coaxial cable network. EIA-600.34 IR Physical Layer. Describes the physical layer interface requirements for use of infrared as a single-room communications medium. EIA-600.35 RF Physical Layer. Describes the physical layer interface requirements for use of RF as a whole-house communications medium. EIA-600.36 Fiber Optic Physical Layer. Currently not used. EIA-600.37 Symbol Encoding Sublayer. Describes the requirements for network symbol encoding for the twisted-pair, coax, and infrared physical layers. The symbol-encoding sections are considered a “sublayer” of the physical layer. EIA-600.38 PL/RF Symbol Encoding Sublayer. Describes the requirements for network symbol encoding for the RF and PL physical layers. EIA-600.39 Node 0. Describes the physical network support functions for power, twisted-pair, and coaxial cable. EIA-600.40 Node Communications Protocol This volume consists of six numbered parts covering a complete description of the OSI protocol layers used by EIA-600 and the resulting message packet format. EIA-600.41 Data Link Layer Descriptions. Describes the requirements and functions of the Data Link portion of the protocol. The Data Link layer is divided into two sublayers: the Medium Access Control sublayer, and the Logical Link sublayer. EIA-600.42 Medium Access Control Sublayer. Describes the functions of the Medium Access Control sublayer in terms of a state machine


15

and its interface to the Logical Link sublayer and Symbol Encoding sublayers. EIA-600.43 Logical Link Sublayer. Describes the functions of the Logical Link sublayer in terms of a state machine and its interface to the Network and Medium Access Control sublayer. EIA-600.44 Network Layer Description. Describes the requirements and functions of the Network portion of the protocol. EIA-600.45 Network Layer. Describes the function of the Network layer in terms of a state machine and its interface to the Application layer and Data Link layer. EIA-600.46 Application Layer. Describes the functions of the Application layer and the state machine and layer interfaces. The Application defines the interface to the user application (or user element) and the Network layer. While the Application layer formally includes the CAL language interpreter function, it is described in a separate document (EIA-600.08). EIA-600.50 Router Communication Protocol This volume consists of four parts covering a complete description of the OSI layers necessary to implement a Router function between EIA-600 physical media. EIA-600.60 Brouter Communication Protocol This volume consists of four parts covering a complete description of the OSI layers necessary to implement a Brouter function between EIA-600 nonphysical media (RF, IR) and physical media. EIA-600.70 Supplemental Data This volume is reserved for any future “supplemental data” found necessary to use or understand the standard. It is presently not used. EIA-600.80 Common Application Language This two-part volume covers the high-level command language (CAL) used by all CEBus-compliant devices. EIA-600.81 CAL. This part describes the data structure and message syntax of the CAL language. It also covers the interface to the rest of the application layer. EIA-600.82 CAL Contexts. This part furnishes the four general CAL Contexts (Universal, Data Channel, Time, and User Interface). The remaining contexts are the published Home PnP (Home Plug-and-Play) specifications (see Chapter 8).

16

Chapter 2

An Introduction to EIA-600 Parts The following sections introduce the three major parts of the standard: physical layers, protocol, and language.

The Physical Layers EIA-600.30 describes the media used by CEBus, how CEBus devices connect to and transmit on the media, and the signaling technique used on each media. While the communication protocol and language are common to all CEBus devices, the installed media and topology may vary considerably from home to home depending on the needs and types of devices used in the home. Devices can connect to and communicate over any (or several) of the following media: The existing 110/220V power-line (PL) wiring of the home accessible by devices that normally plug into an electrical outlet. A four twisted-pair (TP), or four-pair, cable that can be used by CEBus-compliant devices that normally use low-voltage wiring (thermostats, security sensors, and the like), and communication products (telephones and intercoms). The four-pairs (called TP pairs) can be used in place of the normal telephone wiring or can supplement existing wiring. The pairs in the cable are named TP0, TP1, TP2, and TP3. CEBus distributes DC power (18 volts) on TP0 to power devices that attach to TP such as thermostats or sensors. The new Telecommunications Industry Association telephone premise wiring standard and CEBus TP wiring are designed to be compatible. A pair of coaxial (CX) cables used by CEBus devices normally connected to video cable such as TVs and VCRs. The coax pair delivers CEBus messages, cable TV programming, and in-homegenerated video (cameras, VCRs, computers) to any video device in the home. One cable in the pair is dedicated to externally provided widebandwidth services, and one wire is used to distribute in-home-generated signals. Radio frequency (RF) communications throughout the home centered at 915 MHz. Infrared (IR) communications for line-of-sight distances (usually single room) using IR wavelengths similar to hand-held remotes.


17

Due to the wide choice of media, existing homes can begin using the standard as easily as new homes. An existing home can immediately use the power line for new CEBus devices, and the devices obviously require no installation tasks. As a family becomes comfortable with the technology and comes to rely on CEBus products, additional media can be retrofitted if desired. New homes can begin to take advantage of the new and CX capability. The TP wiring requires a four-pair twisted telecommunications cable (good quality telephone wire). Homes wired to the new telephone industry wiring standard (TIA-570) will be CEBus ready. The CX media standard requires the installation of a pair of coaxial cables (equivalent to RG-6), branched from a central location to each room or area in the home. The standard classifies the media into two groups: wired and nonwired media. The wired media are PL, TP, and CX. The nonwired media are RF and IR. The different medium networks connect by devices called Routers and Brouters. A Router is a two-way CEBus device that connects any two wired media (PL to TP, PL to CX, or CX to TP). Messages that originate on one medium are routed to the other connected medium. A Brouter is a two-way CEBus device that connects a nonwired medium to a wired medium such as RF to PL. Messages that originate on RF or IR are routed to a wired media. Routers and Brouters are required to make the different media used in a home appear to each CEBus device as one medium. If a CEBus device transmits a message, it must reach all other CEBus devices in the home, regardless of the medium used.

The Protocol EIA-600.40 describes the Node Communications Protocol. The network protocol used by CEBus is based on the ISO Open Systems Interconnect (OSI) seven-layer network protocol model. A protocol defines the format of the data, or “packets,” sent and received by network devices; the access to the physical network media; and the services provided by the protocol, such as error detection, reception acknowledgment, priority, and so on. The protocol is defined in six parts that detail the operation and requirements for the three network layers used: Data Link, Network, and Application. Each layer represents a division of responsibility of the protocol, and follows the divisions established by the OSI standard for protocol tasks.

18

Chapter 2 The Data Link layer (DLL) is responsible for the low-level task of reliable message delivery on a single medium—the medium used by the device. It handles error detection, packet retransmission, address recognition, packet timing, and buffering. The DLL is defined in two separate documents: the Medium Access Control sublayer (MAC), and the Logical Link Control sublayer (LLC). These documents divide the DLL responsibilities into separate parts, although this is only a documentation convenience. The MAC handles most of the layer tasks; the LLC is little more than an interface with the Network. The Network layer is responsible for reliable message delivery across network media. It handles medium selection, routing, and duplicate packet rejection for packets that originate on a nonwired medium. The Network layer also is responsible for message flow control; it ensures that a long message that is divided into several shorter messages arrives at its destination in the right order. The Application layer is responsible for message generation, reception, and execution. The Application layer uses an end-to-end acknowledgment service to determine that a message sent to another node is received and executed, and that any required result is returned. The Application layer contains the CAL language parser and interpreter, and the interface to the products application “element”—the application hardware or software that operates the product.

The Language EIA-600.80 describes the Common Application Language (CAL). CAL is an element, or part, of the Application layer, but because the description of CAL is rather lengthy, it is given its own separate volume. The CAL specification defines the message structure, syntax, and data structure necessary to model and control any consumer product operation. The description of CAL is divided into two separate parts. Part 1 defines the message structure, syntax, and capabilities of the language. Part 2 defines the major data structures, called Contexts, that define specific functions of consumer products. The most general Contexts are supplied as part of EIA-600. The remaining industry-specific Contexts (HVAC, security, lighting, and so on) are published as separate documents available from the CEBus Industry Council. See Chapter 7 for more information on Context documents.


19

The Design Constraints The difficulties of designing a residential network that can be installed by a homeowner are immense. To make the task practical, design constraints were imposed on the standard that bounded the difficulties. The scope of the network capability must be adequate to ensure successful consumer operation, yet be low cost and simply implemented. The following are the major resulting design requirements and constraints. A CEBus network may be installed—unknowingly—by family members. This is, by far, the most severe design constraint. CEBus products are usually purchased one at a time, brought home, installed by the homeowner, configured in some way, and expected to work. No network engineer is employed by the family. It cannot be known in advance what products will be installed or the order of installation. Dealers or custom home installation specialists may be used when a home automation system or a home theater is being installed, but the standard is developed as though these services are not available. The requirement to have products work correctly without the assistance of a specialist is still a concern of the Interoperability Working Group of the CEBus committee and the CIC. CEBus products may be installed by knowledgeable installers such as the companies that install security systems, heating and air conditioning equipment, or custom entertainment equipment. These avenues of installation are an important part of the early market usage, and in the installation of products requiring more than plug-and-play skills. However, the standard must be able to support installation of plug-and-play products by the consumer (such as toasters, clocks, and CD players). The installer/user of the network is unskilled. The typical homeowner is not a network engineer. The network must be installable and usable by anyone in the home. Even if the original installation was done or assisted by a trained specialist, products will be added by the homeowner. There is no preconceived network. It is not possible to know what wiring is available in the home or what medium will be used for installed CEBus devices. Provisions must be made to allow any medium in the home that meets the standard to be used.

20

Chapter 2 CEBus is primarily a residential network. CEBus is a home network standard, designed to handle typical residential consumer products and systems, using the media available in the home. Specific commercial requirements (large size, harsh environments, and the like) were not considered. While CEBus is certainly capable of being used in commercial environments—and is being used in offices and malls—it was designed primarily for the needs of residential products. CEBus must be fast enough to handle existing residential tasks. Network message delays must be kept to a minimum, typically less than 0.1 second. This is considered the longest time delay allowable from the time a light switch is toggled until the light turns on or off— a real time-sensitive event for consumers. Messages must also have a priority scheme that allows high-priority messages to get through faster than noncritical messages. Yet, no one device can dominate the network. All CEBus devices must be guaranteed network access. Network “troubleshooting” will be difficult. Network troubleshooting— regardless of the network—is always difficult. If the network develops trouble, if CEBus products fail, or if the network is damaged, it will be almost impossible for the homeowner to determine the fault without the assistance of extra equipment, diagnostic tools, or outside help. For this reason, high reliability and fault tolerance are part of the design criteria.

Security Issues The security of any network (residential, commercial, or industrial) is always a concern, particularly as more people acquire technology allowing easy network access. While CEBus networks are limited in scope to one house or apartment, there is concern over possible access to the network from outside “malicious” users, as well as from in-home “hackers.” The concern is valid because several users of the network—such as electric utilities, telephone, and cable companies—may pass rate and usage charge information over the network. The standard does not attempt to protect the network from intentional malicious access. It is possible for someone or some device to “jam” one or more of the medium networks in a home, preventing any


21

message communication. However, this is true of any existing home technology, such as security systems (particulary RF systems), telephone, cable TV, and the like. The standard provides a compromise between the need for high security and the requirements for low-cost implementation. While access to the network is difficult to control, an optional software technique is specified in the standard to allow devices to employ a combination of message authentication and/or message encryption. Message authentication requires both the sender and receiver of a message to possess a set of security “keys.” The message is readable, but the authentication algorithm prevents an unauthorized user from generating the same or similar message. Message encryption can also be employed, using the same set of keys, to prevent the message from being read. Both authentication and encryption are optional security features, and only devices that absolutely need the level of security provided by the techniques (electric meters, cable TV boxes) need to implement the extra software.


CHAPTER

3

The CEBus Benefit


24

Chapter Three When I explain CEBus to those not familiar with the technology, or to the press, I usually get the question: “But what does a toaster say to a television?” It’s a good question, but a better question—never asked—is, “Why would a toaster want to say anything to a television?” After all, what benefit could there be in having a toaster communicate with anything? The answer is twofold: 1. The toaster—or thermostat, hot tub, VCR—can rely on the resources or features of the TV without having to have these resources built into the toaster. 2. The toaster can do more. Once the toaster has access to other products, it can use the features of those products “for free.” It may announce that the toast is ready over the intercom; it may operate only when the coffee pot is finished brewing; or it may sound a security alarm if the toast burns. This extra capability can be achieved for a small incremental cost and enable the toaster to command a higher market price.1 The extra capability can also provide excellent marketplace differentiation, particularly in a mature market in which there is little to distinguish one toaster from another, except price.

The Benefits of Networked Products Historically, all consumer products, even computers, were designed to operate as stand-alone products. Everything that a product needed to operate—to be used by the consumer—had to be built into the product. All user interface parts (displays, keypads, and the like), clocks, sensors, memory, setup/configuration information, signal sources—all resources—had to be contained in the product. There was no way to distribute the needed parts between products. Today, almost all consumer products are still designed this way. Although entertainment products (TVs, VCRs, stereo receivers) are intended to operate together, they have to

1

There seems to be a common misconception among consumer product makers (particularly audio/video equipment makers) that consumers will not pay for additional product features. The companies that believe this must not have any experience with the computer industry.

The CEBus Benefit

25

be physically interconnected with a rats nest of specialized wire and are limited to exchanging audio and video signals. Computer products also began as stand-alone products. The personal computer industry started with essentially a series of custom computers. Each computer used a different operating system, a different hardware structure (processor, bus), and peripheral devices were, for the most part, made specifically for each individual computer. Each computer needed everything necessary to provide all the functions it could do: compute, store, print, and display. Today, of course, almost all computer products network together. Interoperation of computer products made by different manufacturers is the rule rather than the exception. Once the networking trend started in the late 1980s, and once users realized its benefits, manufacturers quickly adopted network interfaces for their products. The same will happen to the rest of consumer products, including TVs, thermostats, hot water heaters, and toasters. Ten years from now, only the most trivial of products will operate as stand-alone products. The benefits of networking are too compelling.

What CEBus Products Say CEBus-compliant devices exchange two fundamental types of messages: control messages and status messages. Control messages enable one product to control the operation of another product. Status messages convey information about the status, condition, or sensor value from one product to another.

Control Messages The concept of allowing one product to control another is relatively easy to comprehend. Many products already allow the consumer, to a limited extent, to remotely control other products. An infrared remote control and the garage door opener are typical examples of one product controlling another. Many people enjoy the benefits of the X-10 line of products that allow light switches to be remotely located from the lights they control. CEBus allows any product to acquire the capability to control the operation of any other CEBus-compliant product. This has one immediate benefit to product manufacturers: it allows multiple product operation to be centralized and performed through a common user

26

Chapter Three interface. Typical examples of two products that can take immediate advantage of this benefit are the TV and home computer. Both products provide a potentially simple user interface for other products in the home that are not simple to operate, such as the microwave oven, VCR, clothes washer, programmable thermostat, and security system.

Status Messages CEBus also enables devices to share information about the operation of the home, such as the time, temperature, occupancy state, and status of equipment. The capability to share information allows Redundant product functions to be centralized in one product The removal of the cumbersome user interface from many products An easy delivery method for outside service information Products simply “place” the information on the network, such as the outside temperature, and the information is picked up by products that can use the information to their advantage. Again, the information can originate in the home, or from service providers outside the home. One of the first examples of this feature is the delivery of electric rate information by the electric utilities. CEBus products such as electric water heaters, dryers, and other high-energy-consuming appliances can receive the rate information off the network and delay operation until rates are lower.

Typical CEBus Applications The ability to network products provides a market opportunity for a whole new category of products: resource providers. These products do nothing by themselves; they are like plug-in cards for PCs. They will provide common information or services to other products on the network, or a common hardware or software resource. The simplest of these products will provide a basic piece of information or service to the network such as time, temperature, security status, or house occupancy. A plug-in-the-wall time module is one of the simplest, yet most useful, service providers. This little device, the same size

The CEBus Benefit

27

and shape as a small wall-mounted power supply, simply broadcasts the date and time to any device in the house that needs it. It contains an accurate clock circuit and a backup battery. The advantages of having a common time broadcast should be obvious. Networked products no longer need to have a clock circuit that flashes 12:00 because no one remembers how to set it. There are many more examples of devices that can provide useful network information. A simple outside temperature sensor that broadcasts the outside temperature to products such as a thermostat, a heat pump compressor, exhaust fan, or television. A CEBus-compliant electric meter that provides the current electric rate (as well as future rates), the energy used this month (in kilowatt hours), and the current kilowatts being used by the house. This information can be used by high-energy-consuming appliances such as an electric water heater, pool heater, heat pump, or other appliances that may defer operation until rates are lower or total house demand is lower (to avoid peak usage charges). Chapter 7 describes how products can easily receive any of this network information without requiring any special product configuration when installed. There are also many examples of products that provide resources for other products to use. The most useful of these is the video interface device, more commonly referred to as a TV. A television provides a convenient and potentially easy user interface for the operation of other products that cannot afford to incorporate a good user interface. A thermostat, particularly a programmable thermostat, needs only occasional attention to set or adjust heating schedules, but usually has a poor user interface (a liquid crystal numeric display and a few cryptic buttons). A CEBus-compliant thermostat can allow a CEBus-compliant TV to act as its user interface, providing easy-to-read onscreen menus and instructions. The personal computer is the second most popular user interface device in a growing percentage of homes. While it may not be as convenient (at least for a few more years) as a TV, its user interface capability is more advanced. As more consumers become comfortable with using home computers, its role as a common user interface for home control and management will increase significantly. Computer manufacturers are already building CEBus interface circuitry into their PCs.

28

Chapter Three

The Future Potential As more networked product resources and information become available in the home, a market develops for more complex applications. For example, one of the most difficult yet most useful pieces of information to obtain about a home is whether it is occupied. This information can often be inferred from a security system if the system is armed in an “away” mode. Many homeowners, however, either don’t use their security system or forget to arm it when they leave. Knowing whether the house is occupied must be inferred from a more complex heuristic. Having access to information about the operation of the house available off the network can allow a product to build probability tables about device activity (lights, security devices, even plumbing). A lack of activity, when there is a high probability that there should be activity, may indicate that the house is unoccupied (or that the occupants need medical assistance). Tables of who is home at what times of day can also be created. The inverse information—activity in the house when it is expected to be unoccupied—is easy to obtain. Safeguards can be built into the product to test whether a house is unoccupied (by announcing the house state, placing messages on TVs, and the like) to ensure higher reliability. Even if the occupancy state is calculated accurately 98 percent of the time, the benefits are potentially terrific. As long as no serious action is taken (alerting the police, turning on or off critical appliances), being wrong 2 percent of the time is a minor inconvenience. If a device knows the home is unoccupied, it can provide a valuable resource. It can arm the security system, turn off appliances, set back temperatures, turn off (or on) lights, and, in general, look after things. This may seem farfetched, but prototypes of this function have been used with good success in home automation systems. The difference is that the home automation system had to be purchased and installed as a system and cost tens of thousands of dollars. In a CEBus environment, this capability could be purchased for a few hundred dollars at Circuit City and installed by the homeowner. The occupancy calculator is typical of higher level products that make inferences from the information available on the network. There are many other possible applications given a critical mass of network resources. Fault or malfunction detector. This device looks for fault conditions from products on the network (many CEBus products are capable of reporting fault conditions), for example, a malfunctioning

29

The CEBus Benefit

device such as a smoke detector, or a network problem such as two products with the same address. It then reports the problem to the homeowner via the TV, printer, or by voice synthesis. Emergency “watch dog.” This is a variation of the occupancy state device. It looks for anticipated activity from the house occupant(s). If there is no activity over a period of time, it can place a call to alert a remote family member or a medical service. Network configuration devices. This hardware or software product helps installation and configuration of CEBus-compliant devices using a rich user interface. This application typically runs on a PC and keeps a database of CEBus context use, installed products, and the features of all networked devices. This product also allows the homeowner to configure interproduct scenarios (described in the next section).

The Plug-n-Play Concept For most of the applications described in this chapter to become a reality and easily installed at low cost, it is essential that CEBus-compliant products be plug-n-play whenever possible. The concept of plug-n-play (the contraction of plug-and-play) is basic to a consumer-oriented network technology such as CEBus. Plug-and-play design allows products to access and use information in other products in a uniform way. It allows one product to control another class of product without programming or custom installation tasks. CEBus has the potential to achieve plug-nplay compatibility between a large number of products if the standard is used correctly. The benefits are substantial, but a clear understanding of what the plug-n-play concept means is essential. Plug-n-play implies a level of interoperability that is difficult to achieve in a typical network. Interoperability means the ability of products to work together over a network using a predefined level of interaction built into the protocol. Protocol interoperability is a requirement for achieving plug-n-play products. The term interoperability is often misused because the concept of working together, like plug-n-play, means different things to different people, particularly between manufacturers, developers, and consumers. If a product claims to be interoperable with other products on a network, does that mean that the product knows how to operate other products on

30

Chapter Three the network? How much can it operate? What features are available? What product information is available? Can it tell whether another product is on the network? For CEBus consumer plug-n-play products, interoperability is a primary requirement; thus, it is important to clearly understand what it means. This means understanding how CEBus networks will be built by consumers. The CEBus Committee assumed that CEBus-compliant products will be purchased, brought home, plugged in, and work. Products are purchased incrementally, in any order, and added to over time as new products replace older, nonnetworked, products. This network growth model requires a very high level of product interoperability because it does not rely on any type of central control, or on an installation expert (human or machine). To ensure this level of interoperability, all aspects of product interoperation must be defined. This includes everything from connectors, wire, signaling, and product language, to how products share information. This explains the need for the level of detail present in the CEBus standard document.

Interoperability Defined Because product interoperability is so important to successful use of CEBus, it is important to clearly understand what interoperability means and how it applies at different stages of product development, installation, and use. CEBus product interoperability can be divided into three levels: communications interoperability, applications interoperability, and scenario interoperability.

Communications-Level Interoperability Communications-level interoperability refers to the capability of products to send and receive packets over the network and successfully understand the content of those packets. This requires that all CEBuscompliant products adhere to a proper implementation of the basic CEBus protocol design, including the physical layer and the use of the communicating medium. This level of interoperability is built into the protocol code and into the product network hardware interface. Products must use the protocol to access the attached medium, transmit and receive packets on the medium without interfering with other

The CEBus Benefit

31

devices on the network, and interpret the contexts of the packet successfully. Products must also understand a minimum set of CAL messages. The minimum set includes commands for resource allocation and configuration, as well as commands to access basic information about the product, such as its network address, serial number, and product class. This level of interoperability is fundamental to the technology and adherence is an absolute requirement. The guideline for ensuring communications interoperability is ANSI/EIA-600 where these requirements are clearly defined. Interoperability can only be obtained if the standard is implemented correctly. While this level of interoperability is critical, it is the easiest to test. A product can be subjected to a standardized series of packet reception and transmission tests to ensure that packet format, timing, and protocol usage adheres to the specifications. The CEBus Conformance Specifications (EIA-633) can be used by a manufacturer to ensure that its product meets the minimum protocol requirements for certification.

Application-Level Interoperability Application-level interoperability defines how products know to use (control and share resources and information with) other devices on the network, and is the basis for plug-n-play product design. This is the level that the consumer is most concerned about and where real benefits are achieved. Understandably, this is the most difficult level of interoperability to achieve for two reasons: 1. It requires detailed agreements on the definition of product operation—an area that has previously been the exclusive domain of the manufacturer. 2. It is difficult to test. The basic CEBus tool for insuring application interoperability is the CAL language and its associated context data structure definitions. Contexts establish a standardized data structure for each and every consumer product function. A product implements those contexts that define all of the functions the product is capable of supporting via CEBus. The syntax and operation of the CAL language are defined in EIA-600. The actual context data structures that pertain to real product functionality are defined in separate documents (grouped by industry functional category, such as lighting, audio/video, security, and HVAC).

32

Chapter Three These documents are developed jointly by the CEBus Industry Council and working groups of representatives from companies in each product category. Contexts are designed to be extended as new product functions emerge in each product category. Contexts define how products are “seen” over the network. By reading and writing to variables in the context data structure, a product can be used by another device on the network. The definition for each product function is standardized so that, for example, the audio amplifier function in a stereo receiver is operated in the same way as the audio amplifier function in an intercom or PC. Contexts are designed to allow predefined pairing or “binding” of the contexts in one device with the contexts in another device. The concept is similar to the way hardware functions are distributed over a computer bus. The data output of a device has a predefined context destination in one device or a group of devices. The model also allows devices to broadcast information on the network for use by any other device that can use the information. To receive the information (such as the current electric rate, temperature, or time), a device need only instantiate a copy of the context that receives the information. For example, consider the following situation in which two devices are completely interoperable as far as correct implementation of their Context data structures, yet, they do not communicate: An HVAC equipment vendor makes a temperature-sensing device that provides the current temperature to any device that asks (reads the IV containing the temperature). A different HVAC manufacturer makes a thermostat for use with a remote temperature sensor. This device assumes the temperature sensor will announce its temperature (send a message to a receiving context) each time the temperature changes. Because the thermostat never asks, and the temperature sensor never announces, the two devices do not operate together even though they both use CEBus communications layers properly and both agree on how to represent the temperature in CAL. This problem can be avoided by careful planning and development of the context models.

In principle, context binding can allow many products to interoperate in the home by simply bringing them home and plugging them in (thus, plug-n-play). Little or no consumer configuration of intelligent control is required. A core level of the most common and desirable applications can be achieved by purchasing off-the-shelf products. For most consumers, this basic interoperability will be all that is necessary for many beneficial automation features.

33

The CEBus Benefit

Scenario-level Interoperability Scenario-level interoperability defines how two or more products use CEBus application-level capabilities to cooperate to perform a predefined set of actions in the home. The action is usually initiated by an event such as a time of day, light level, arming or disarming of a security system, and so on. The following scenarios are typical of those possible between CEBusnetworked products: When a homeowner returns home and disarms the security system, the heating temperature is set to 72°, the hot-tub turns on to 102°F, the curtains open in the living room and family room, the TV turns on to CNN, the telephone answering machine is set to answer on the eighth ring (instead of the first ring), and the PC retrieves any waiting email. The utility company sends a broadcast message to all devices containing the appropriate context to receive the current price schedule. When electric rates exceed a predetermined value, the hot tub turns off, nonessential lights turn off, the air conditioning is set 3° higher, the hot water temperature is set 10° lower, and the pool pump stops circulating. When rates drop to previous levels, the process is reversed. Unlike basic application-level interoperability, these scenarios require agreement on the order in which messages are given and on which devices are the senders and which are the receivers of messages. Because a device must be separately programmed to send and receive a specific set of messages, agreement on this subject is important. This kind of interoperability may appear to be unmanageable. However, to some degree, agreements can be achieved on the relative roles of sensing and controlling devices and related system behaviors. These agreements can provide manufacturers with guidelines to achieve interoperability relating to scenarios. The CIC works to achieve these agreements through a consensus of member companies.


CHAPTER

4 CEBus Basics


36

Chapter 4 This chapter provides an overview of how CEBus works and introduces the basic concepts and terminology that are used in the remainder of the book. Most of the material in this chapter is discussed in more detail in the next three chapters on the physical media, protocol, and CAL.

How CEBus Works—An Overview CEBus-compliant products work by momentarily “connecting” to another product on the network to perform a sense or control operation. This “virtual connection” is achieved by gaining exclusive use of the medium that connects the two products long enough to transmit a command or request. After communication is complete, the transmitting devices release the use of the medium. The medium can be the power-line wiring, twisted-pair cable, coaxial cable, RF, or IR. The messages are transmitted by either placing a signal on the wire, or transmitting an RF or IR carrier. Messages are short, lasting an average of 25 ms, and contain 50 to 300 bits. By keeping messages short, many devices can share the medium without conflict because messages between any two products are relatively infrequent. To ensure high message delivery reliability, and to ensure that products do not all transmit at the same time, CEBus devices adhere to a strict message protocol. A protocol is a set of rules that define how and when messages are sent, how to recover from transmission errors, the format of messages, and so on. The messages contain commands in a common command language (CAL) that is understood by each product. The command language is specifically designed for information sharing and control of residential consumer products. CEBus-compliant products are required to understand a minimum subset of the command language and that portion of the language specific to their product category.

The CEBus Product Model This section describes the basic assumptions about the design and operation of a CEBus-compliant product.

37

CEBus Basics

Nodes Any CEBus-compliant device attached to a medium is referred to as a CEBus node. A node is any device that Can transmit and receive CEBus packets on at least one medium Adheres to the CEBus message protocol Uses and understands a minimum set of the CAL language The minimum CAL language requirements comprise a common set of network management commands plus commands that are specific to the device category. For example, a CEBus light switch must understand the commands to turn on and off the light, but does not need to understand a command to “turn to channel 13.” All CEBus nodes consist of the three major parts shown in Figure 4.1. This diagram represents a simple internal model of every node. The parts can be implemented using any combination of hardware or software. The PROTOCOL is the same in each CEBus-compliant device and is responsible for reliable message delivery. The protocol software defines the format of the transmitted packets, the packet delivery “services” (error detection, message priority, retransmission of lost messages, responses to messages), and the technique for accessing and transmitting messages on each medium. The CAL portion of the model is responsible for converting product application events into a CAL language message—or “words”—that other CEBus nodes understand. Likewise, it interprets received messages and affects product operation.

Figure 4.1 Simple CEBus product model.

38

Chapter 4 The APPLICATION represents the specific node application for the product, and contains the hardware and software that define the product operation. Figure 4.2 shows the model in terms of the formal protocol layers that define node operation. The protocol software consists of four layers or subfunctions: the Physical layer, the Data Link layer, the Network layer, and the Application layer. The CAL interpreter is formally part of the Application layer. A Message Transport sublayer, also part of the Application layer, provides many of the services traditionally found in a protocol Session and Transport layer. Figure 4.2 highlights the major tasks performed in each layer. Figure 4.3 shows the model in block diagram form. The I/O and application routines handle the interface of the device hardware and application software to the Context data structure and the protocol routines. The Application reads and writes the context data structure to reflect prod-

Figure 4.2 Product model in terms of the protocol layers.

Product Application

APPLICATION LAYER CAL interpreter Context data structure MESSAGE TRANSPORT SUBLAYER Message authentication/encryption End-to-end acknowledged service NETWORK LAYER Intermedia routing Segmented service/flow control DATA LINK LAYER CSMA protocol Error detection, retransmission DL acknowledged service PHYSICAL LAYER Medium interface Symbol timing/encoding Superior/inferior state generation Medium

CEBus Basics

39

Figure 4.3 Block diagram form of product model showing division of Protocol, CAL, and Application.

uct operation. The context data structures serve as the interface from the CEBus network to the product resources. The application can generate messages by writing to the Context data structure, or by forming a message “manually” and passing it to the Message Transport sublayer (responsible for receiving and generating messages). The Context data structure represents a software model of the product’s operation to the rest of the network. The CAL interpreter translates changes in the context data structure to an appropriate message to another node. Received messages are interpreted and the context data structure is updated accordingly. Formally, the CAL interpreter and its associated Context data structures are part of the protocol stack—the Application layer—but considering the interpreter as the protocol application is convenient because its function is unique to CEBus. The CEBus standard and this book treat the CEBus protocol as the Physical layer through the Message Transport sublayer. The protocol is covered in detail in Chapter 6. CAL is treated as the CEBus application and is covered in Chapter 7.

40

Chapter 4

Network Communications Models Every communications protocol makes assumptions about the hierarchy of device-to-device communications in terms of network access control and device control. To gain a better insight into the design of the CEBus protocol layers, it is helpful to know the CEBus design assumptions. The CEBus protocol uses a peer-to-peer communications model (Figure 4.4). This means that the protocol is designed to enable any node on any medium to communicate (send and receive messages) with any other node in the home. There is no communication hierarchy or restrictions on product-to-product communications over any media. This communications model is essential if CEBus-compatible products are to be installed in the home incrementally. As devices are added to the network, they must be able to communicate with any existing products. There can be no assumptions about the order or the type of devices added to the network. The communications model also assumes that there is only one CEBus medium shared by all nodes. Though many physical media types are used (twisted-pair, coaxial cable, RF, and the like), they are treated as a single medium, and any message generated by any node will arrive at all other nodes on the medium. The various physical media are interconnected by Routers and Brouters, which are described in more detail in Chapter 5. The job of Routers and Brouters is to make the different media behave as one medium to the connected nodes. CEBus uses a connectionless service protocol. This means that devices gain access to the network media only long enough to transmit a message and then get off. Because messages are short, many devices can share

Figure 4.4 CEBus communications model. Each product communicates on a peer-topeer level with all other products. There is no communications hierarchy.

41

CEBus Basics

the medium. No connection is formed between two communicating devices and the network is not tied up during their “conversation.” This is different from a typical connected service network such as the telephone network in which two nodes establish a communication connection and retain exclusive use of the media until all conversation is complete, then hang up, releasing the network resources for another call.

Network Control Model The protocol supports two control models (Figure 4.5). A control model defines which nodes can control other nodes on the network. The CEBus protocol assumes a peer-to-peer distributed control model, allowing any node to control any other node. This is also a result of CEBus networks being built incrementally and in random order. Any product can control any other product in the home, if it is capable of doing so. No type of central control device or automation system is necessary in CEBus. The absence of central control was a development goal of the standard. Products may be added anytime by the homeowner without having to notify or program a central system. While CEBus is not dependent on central control, it does not exclude it, or the most common variation, the cluster control model. Cluster control allows one or more nodes to assume the task of controlling several other nodes. This model is employed for system-oriented products in the home, such as HVAC systems, security systems, and lighting control systems, and it is the model used by these systems for control by people. To set the temperature in the downstairs air conditioning zone to 69°F, a user might use an onscreen menu on the living room television. The television would send a message to the downstairs thermostat requesting a new temperature. The thermostat, in turn, would send the necessary control (over TP) to the HVAC air handling unit, compressor, motors, and

Figure 4.5 CEBus control model. CEBus allows combinations of distributed and cluster control. Product clusters are assumed to be controlled by one node.

42

Chapter 4 so on, required to achieve 69°F. The television could send messages directly to the HVAC air handler, compressor, motors, and so on, but it would not know what to tell these devices; it does not contain any HVAC system control algorithms. Telling the thermostat is easier and lets the thermostat keep track of the HVAC system. The same control scenario applies to the lighting control and security systems. The necessary system-control software is contained in one easy-to-use node.

CEBus Reference Architecture and Media The CEBus standard establishes a set of Physical layer medium specifications to handle all the data communications needs of the home (audio, video, computer data, and so forth). It defines the use of the power-line wiring (PL), radio frequency (RF), and infrared (IR), and the installation and use of twisted-pair (TP) and coaxial (CX) cable. Figure 4.6 illustrates the reference architecture, or topology, for all media supported by CEBus as well as the interconnection of the media in the home and to outside service providers. Figure 4.6 illustrates all of the medium support components that might be used in a typical residential environment for CEBus message communications, as well as maximum utilization of internally and externally supplied wideband services. The standard is flexible enough, however, to allow the use of CEBus products in existing homes using the PL, RF, IR, and a majority of existing TP wiring with a minimum of additional components. Power-line-based products, for example, require a minimum of infrastructure support. There is no initial “network” to purchase and install. As products are purchased that utilize more of the capability of the media, additional infrastructure support components can be added incrementally. All media support components are collectively known as Node 0. The term Node 0 refers to all the physical components necessary to support the various medium networks. Node 0 consists of all Routers, Brouters, Data Bridges, and the TP, CX, and PL support hardware necessary for a given installation. The TP network requires a power supply and a distribution/termination device. The CX network requires a distribution device containing block conversion, amplification, and control-channel regeneration functions.

CEBus Basics

Figure 4.6 Brouters.

43

Reference media topology for CEBus networks. Media are interconnected by Routers and

Routers connect CEBus messages between two of the wired media (PL, TP, CX). Brouters connect CEBus messages between RF or IR and a wired media. Data Bridges connect any audio, video, or other wideband signals between media. The TP network architecture is based on TIA-570 (Residential and Light Commercial Premise Wiring standard). Branch runs of four-pair jacketed cable originate at the distribution device and run to each room where they connect to one or more outlets. Two of the pairs are used for external services, two are reserved for CEBus communications.

44

Chapter 4 The CX network consists of a pair of RG-6 cables that originate at the distribution device and run to each room where they split to one to four dual outlets. One cable handles delivery of external services (such as cable TV), the other cable is for distribution of in-home-generated control and data. Network Interface Units (NIU), typically supplied by an external service provider, provide the interface between the electrical characteristics of the external network and the electrical characteristics of the CEBus network. A NIU may interface any external network medium (coax, twisted-pair, RF) to any CEBus medium.

Channels The CEBus standard defines two types of communication channels available on each CEBus medium (Figure 4.7): a required control channel for device message communication, and a set of optional data channels for distribution of audio, video, or any wideband signals. The control channel is used on every medium to transmit and receive CAL messages. The control channel uses a frequency spectrum on each medium that is always available and completely defined by a fixed frequency allocation, amplitude, and encoding method. The control channel is required by all CEBus-compliant products to send and receive messages between nodes. Data channels are a reserved frequency space available on some media that may be used by CEBus devices equipped to send and/or receive analog or digital data. The data may be any information (music, computer

Figure 4.7 Each CEBus media is capable of supporting a Control Channel and one or more Data Channels.

CONTROL Channel 1 0 11 0 1 0

0 11 0 1 0 1

•CEBus packets

DATA Channel (optional) •Voice •Music (analog, digital) •Video (analog, digital) •Data files

CEBus Basics

45 files, compressed video, voice) as long as it is confined to the frequency and amplitude specified for the medium used. Data channels are currently available on TP and CX, although the standard allows data channels on all media. A VCR that sends its video output to an upstairs TV over the coaxial medium is a typical example of data channel use. The VCR and TV use the control channel—exchanging resource allocation messages—to establish the connection, and the data channels are used to send the video, freeing the control channel for other tasks while the data transfer continues on the data channels. Figure 4.8 illustrates the allocation of the frequency space on one of the two CX coaxial cables. The control channel is assigned the frequency space between 4.5 and 5.5 MHz. This frequency space is reserved for devices attached to CX for sending and receiving messages. The figure also shows the frequency allocation of the predefined data channels. The frequency space from 54 to 150 MHz is used for transmission of data on one or more 1.5 MHz channels. These channels are block converted in Node 0 to the 324 to 420 MHz range for reception by any CX node. The use of data channels is always optional. Access to the data channels is independent from access to the control channel. A product that uses data channels will have a separate transceiver (potentially frequency agile) to send and receive digital or analog data (Figure 4.9). There are two major differences between the control and the data channels. 1. While CEBus messages on the control channel are sent and received in packets that are completely defined by the CEBus protocol, the format and content of the data channels are open. A manufacturer can use data channels to send any data that can be transmitted in the frequency allocations and amplitude available for the channel or channels used.

Figure 4.8 Example of data channel use on CX.

46

Chapter 4

Figure 4.9 Each CEBus node must have access to the control channel. It may also access one or more data channels. The transceiver electronics for each channel may share the same coupling components and connector.

2. As described in the section on the CEBus communications model, the control channel is used for connectionless service only. Devices wait until the control channel is not being used, transmit a message, and relinquish control of the channel. This service is required because there is only one control channel shared by all devices. Each data channel, however, is used for connected service. Devices negotiate for the use of one or more data channels (using messages on the control channel) depending on the bandwidth required for the data to be transmitted. If no other node is using the requested channel(s), the requesting device can use the channel(s) as long as necessary to transmit the data. To transmit a computer data file, the connection might last for several seconds. In the example of the VCR transmitting to the upstairs TV, the channel might be in use for several hours. There are usually multiple data channels available on each medium so that several devices (64 in the case of CX) can have access simultaneously. Additional (non-CEBus) frequency space may be available on each medium for use by outside service providers (cable companies, telephone companies, and the like) who share the same medium. This allows products to have access to outside services as well as CEBus control and data channels on the same medium. For example, products such as set-top boxes can access cable company-supplied program material and control messages (pay-per-view video, utility company rates, database access), and CEBus data and control channels all on the same coax cable pair. The frequency allocation of each CEBus medium is described in Chapter 5.

47

CEBus Basics

Packets and Messages Information is transmitted over the control channel in packets of data at about 10,000 bits per second (bps) (regardless of the medium used). Packets contain the necessary “housekeeping” information, such as the address of the originator and destination node, as well as the message (the CAL commands directed to the destination node). A simple analogy can be made between the information contained in a CEBus packet and the information in a typical letter (see Figure 4.10). The message contains the packet “payload” as a CAL message or reply that a node wishes to send. The message is typically 4 to 10 bytes—only about one-fourth to one-half of the packet length. The addresses and service bytes make up the remainder of the packet. For a letter (message) to reach its intended receiver successfully, the letter is sent in an envelope (packet), and the envelope is addressed to a receiver (the TO address). To inform the receiver of the address of the sender (or to allow the letter to be successfully returned if it could not be delivered), the return address (the FROM address) is included on the envelope. Each CEBus product has its own unique address, acquired

Message

C ER TI FI ED

A

IR

M

A

IL

PACKET

CEBus Packet preData Link amble services

Figure 4.10

TO Address

FROM address

Network services

Application services

CAL message

FCS

CEBus packet structure illustrating the analogy of typical letter parts to packet fields.

48

Chapter 4 when the product is installed in the home. The address has two parts: a house address (that all products in one house or apartment share) and a device or node address that is unique to the product. When sending letters, the envelope can indicate one or more post office services, such as certified mail, next day delivery, or return receipt requested. Packets contain similar information. The Data Link services (handled by the Data Link layer) determine network access priority, and, thus, delivery priority, as well as a “return receipt requested” acknowledged service. The Network services (handled by the Network layer) determine packet routing through the network. The Application services (handled by the Application layer) determine whether a reply is requested from the receiver and message security. Message authentication can be requested in the Application services to prevent unauthorized users from accessing or changing information in some products. For example, the electric rate information stored in a CEBus electric meter can be read and changed by the electric utility because it has the correct authentication keys, but the information cannot be changed by nonutility devices that do not have the keys. The Preamble and Frame Check Sequence (FCS) shown at the front and end of the packet in Figure 4.10 are fields used by the Data Link layer protocol. The packet preamble, the first byte of the packet, is used for transmission collision detection. The FCS is used for received bit error detection.

Symbol Encoding When a CEBus device sends a packet, the data in the packet is converted from internal binary form to physical medium symbols. CEBus uses a set of four medium symbols, rather than the more common binary symbols used internally in computers. 1: binary one 0: binary zero EOF: End-of-Field—used to separate packet fields EOP: End-of-Packet—used to identify the end of a transmitted packet

CEBus Basics

49 Using four symbols instead of the usual two makes transmission and reception of packets easier. It allows an inexpensive and easy data compression technique, which is described in Chapter 6. All CEBus nodes encode symbols by generating one of two physical medium states. The two states are defined as the SUPERIOR state and the INFERIOR state. These terms generically define two electrical conditions of the medium that are easily detected by a receiving node. The state names imply that the SUPERIOR state can always override or be detected over the INFERIOR state. The idle state of the medium—the state when no packets are being transmitted—is always the INFERIOR state. Each CEBus medium uses different electrical conditions, appropriate to the medium, to represent the two states. Typical representations of the SUPERIOR and INFERIOR state on each medium are shown in Figure 4.11. The four symbols are encoded on each medium by using the time that the INFERIOR or SUPERIOR state remains on the media, not whether the INFERIOR or SUPERIOR state is used. The time is measured from the transition between states. The 1 symbol is represented by the shortest interval of either the SUPERIOR or INFERIOR state (100 s); the 0 is twice the interval of the 1; the EOF is three intervals; and the

Figure 4.11 Typical symbol encoding showing the four symbols and symbol times. The transition time between states determines the symbol.

50

Chapter 4 EOP is four intervals. Note that any symbol can be represented by either a SUPERIOR or INFERIOR state. The end of one symbol and the start of the next occurs at the transition from one state to another. Therefore, states alternate between SUPERIOR and INFERIOR for each new transmitted symbol in a packet. Because the idle state of the medium is always the INFERIOR state, the first symbol transmitted in a packet is always encoded with the SUPERIOR state. The packet can end in either state. The symbol time for the shortest symbol (1) is defined as the Unit Symbol Time (UST) and represents the minimum SUPERIOR or INFERIOR period. The UST is the basic unit of measure for timing in the protocol software. The packet data rate is the same for all CEBus media and is stated as 10,000 “one-bits” per second, because a packet containing all “1” symbols would transmit all symbols at 100 s, or 10,000 bps. In practice, because each packet contains a mix of the four symbols, the actual data rate varies with each packet, averaging about 8,500 bps. Compression techniques are used in the protocol to reduce the use of zeros where possible. The signaling technology used on each medium is tailored for the lowest cost implementation while providing the highest reliability. PL transceivers use a novel 100- to 400-kHz spread spectrum carrier technology developed by the Intellon Corporation. TP transceivers use a simple 10-kHz, 250-mV carrier; CX transceivers use an equally simple 4.5- to 5.5MHz carrier; and IR uses a 100-kHz, 850- to 1000-nM carrier. RF uses a digitally synthesized spread spectrum carrier centered at 915 MHz.

Network Attributes The symbol-encoding technique used in CEBus allows a uniform packet data rate and encoding on all media in the home. All nodes, regardless of the medium used, transmit packets using the same data rate, the same media states (SUPERIOR/INFERIOR), the same protocol (CSMA/CDCR, which are described in Chapter 5), and the same packet format. This allows packets transmitted on one medium to be routed to another medium with a minimum of conversion. The only difference is the electrical representation of the SUPERIOR and INFERIOR states in each medium. A product that uses the power line can be adapted to use twisted-pair by changing only the Physical layer transceiver electronics. All other parts of the interface and node software remain the same. This makes the job of Routers and Brouters much easier because they only need to convert media states.

51

CEBus Basics

CAL: What CEBus Products Say to Each Other The message portion of each packet contains the CAL command. CAL provides a common language interface so that products know how to communicate with other products without knowing how each specific product operates, who built it, or what features it has. CAL is responsible for implementing application-level interoperability. To achieve true interoperability on a large scale—to get products to work together in the home—there must be some predefined model of how products operate and a common set of commands to perform the operations. A TV built by Sony and a TV built by RCA should operate, from a CEBus standpoint, in the same way. A PC or a toaster needs to know how to change the channel on any CEBus-compliant TV regardless of manufacturer, and without having to consult with the manufacturer. This goal has been achieved by a set of predefined (but extensible) models for all consumer device functions in the home.

CAL View of Products The design of CAL is based on the assumption that all electrical appliances and products in the home have a hierarchical structure of common parts or functions, and the basic operation of the common functions is the same from product to product. CAL treats each product as a collection of one or more of these common parts called Contexts. A CEBus TV, for example, appears as a collection of Contexts at a network address as in Figure 4.12. A typical TV might consist of a video display Context, an audio amplifier Context, a tuner Context, a clock Context, a user interface Context, and so on, depending on the features of the model. CAL defines more than 50 different Contexts for everything from lighting, security, heating/air conditioning, to washing and drying. Each Context, regardless of what product it is in, operates the same way. The audio amplifier in the TV, in the stereo receiver, in the speaker phone, and in the intercom all work alike and “look” alike to the network. Each Context consists of one or more objects. An object is a software model of a well-defined control or sensing task. Objects model the way Context functions are normally performed manually. The volume, bass, and treble analog control objects and the mute binary switch object rep-

52

Chapter 4

Figure 4.12 Each CEBus node consists of one or more Contexts. Each Context is made up of the objects necessary to control available product functions.

Figure 4.13 Sample object table for an analog control object (object class 08). The object operation is defined by its nine variables.

resent controls typically found in audio amplifiers. CAL uses 26 predefined objects to model all control functions required for all known consumer/residential products. Objects, in turn, are defined by a set of instance variables (IVs). IVs are like variables in any software program, having a size and a data type. All network operations on Contexts are performed by reading and writing object IVs. The IVs that define each object are listed in the object tables in the CAL specification. Figure 4.13 is a representation of a typical object table.

CHAPTER

5 The Media and Physical Layers


54

Chapter Five In order for products to be successfully installed in the home, the specifications of the media used to make CEBus networks must be completely defined. Medium specifications allow manufacturers to make devices that they know can be installed in any home if the required medium has been installed correctly. For example, to use the power line to communicate, a manufacturer must at least know its electrical characteristics, the carrier signaling, data rate, and so on. On media such as TP and CX, a manufacturer must also know such things as the type of connector and cable to use. All aspects of physical interoperability must be defined. This chapter discusses the physical and electrical requirements of each of the media usable by CEBus: power line (PL), coaxial cable (CX), twisted-pair (TP), and radio frequency (RF). The physical media (PL, CX, and TP) are referred to as wired media and RF as the nonwired media. This chapter also discusses the design of the PL physical layer (PHY) in detail and the basic design of the TP, CX, and RF physical layers.

The CEBus Network Topology A network topology defines how nodes are connected to each other over the network medium. The topology defines how the medium or media are interconnected, the path from node to node over the medium, and routing of messages over the medium. A network (singular) implies a single uniform transmission path interconnecting all CEBus devices in the home. The job of making plugand-play products means making a network in the home easy to use, but creating that network is difficult due to the multiplicity of wiring, and the size and types of homes.

Architecture Assumptions Creating a usable network out of the power-line wiring, telephone wiring, coaxial cable, RF, and the like, requires a clear specification of how the media must be used, connected to, and interconnected. To simplify the task, the CEBus committee made some basic assumptions about the specified media, the minimum media requirements, and media interconnection. The first assumption was the basic medium reference architecture design described in Chapter 4 and shown here in Figure 5.1. This


55

architecture defines the supported media and how the media are connected for the supported communications channels. The second assumption, which can be seen in Figure 5.1, is that the medium architecture forms a tree topology. A tree topology means that there is only one path from any node on the network to any other node. Like the leaves on a tree, there is only one path to get from any leaf to any other leaf. A tree topology also means that there is only one route from any medium to any other medium. This model allows all nodes to treat the several media that make up the network as though they were one medium and removes the burden of message routing from the nodes. The third assumption is that the tree is formed from the individual media by a set of Routers and Brouters. They handle the job of message routing and medium interconnection to ensure that a tree network is maintained.

Node 0 The term Node 0 (spoken “node zero”) refers to all the physical components necessary to support the various medium networks (see Figure 5.1).

Figure 5.1 CEBus reference architecture.

56

Chapter Five Node 0 collectively consists of all Routers, Brouters, Data Bridges, plus the TP, CX, and PL support hardware. The TP network requires a power supply and a distribution/termination device. The CX network requires a distribution device containing block conversion, amplification, and control-channel regeneration functions. The term Node 0 originated in the mid-1980s when some members of the CEBus committee thought that all support hardware for all networks (Routers, distribution devices, and so on) would be built into a single piece of hardware, purchased by the homeowner, and plugged into the power line, a TP outlet, and a CX outlet. This hardware would be the first CEBus component installed in the home, and would, therefore, be called Node 0. The concept that all necessary support hardware would be contained in a single device has long been abandoned, but the terminology stuck.1 Now any component built for network support is called a Node 0 device. There is a separate section in EIA-600 devoted to the various hardware interface requirements of Node 0.

Router and Brouter Requirements Routers and Brouters comprise one of the components of Node 0. They are the devices that “glue” the individual medium networks together to form one logical network. Routers

A Router has two jobs:

To connect the control channel of two wired media To maintain a tree topology A Router is a device that connects the control channel of one wired medium to the control channel of another wired medium. A Router may be connected between PL and CX, or PL and TP, or TP and CX. The job of a Router is to ensure that packets originating on one of its connected medium are retransmitted on the other connected medium. Its primary function is to make sure that the control channel of all the wired media are connected together so that nodes do not have to know what medium other nodes use. A packet transmitted on PL will wind up on the medium used by the destination node. 1

This is not to imply that a single Node 0 device cannot be built. In fact, one of the first Node 0 devices on the market, built by Grayfox Systems, contains all Node 0 support hardware for all media (including Router) in one box.


57

Routers build an internal address directory of what node addresses are on the side of the network that they route to. This allows a more efficient packet-routing technique. Packets are only routed to another medium if the destination address is on that “side” of the network (that is, if the node is on one of the media that can be reached through the Router). There may be more than one Router installed between two media. This occurs if a consumer installs more than one CEBus-compliant device in the home that contains a Router. For example, a television may contain a Router that connects between the PL and CX media (because a CEBus-compliant TV connects to both). A purchased CEBus-compliant VCR—perhaps from a different manufacturer—may also contain a PL to CX Router because it connects to both media as well (see Figure 5.2). This violates the tree topology because a packet that originates on PL will be routed to CX by both Routers—the one in the TV and the one in the VCR. To prevent this condition, one Router must disconnect or stop routing. To maintain a tree topology, regardless of the type, location, and number of Routers installed between the wired medium networks, Routers have their own Router protocol. Routers exchange messages between themselves to determine which Routers should remain on-line and which must disconnect. The technique is best described by example. Assume, as shown in Figure 5.3, that a Router exists between PL and TP, and between PL and CX. Packets that originate on any of the wired media will be routed to all wired media. Now assume that another device (Figure 5.4) is added to the network that contains a CX to TP Router (perhaps a DSS receiver). This Router destroys the tree topology. Packets that originate on CX will be routed directly to TP by the CX-TP Router, and indirectly to TP by first being routed to PL by the PL-CX Router, and then to TP by the PL-TP Router.

Figure 5.2 Multiple Routers between two media may exist because products that connect between the two media may have internal Routers.

58

Chapter Five

Figure 5.3 Standard Router configuration between the three wired media.

This generates two copies of the same packet on TP. The problem is avoided by having one of the Routers stop routing. This is accomplished by communication between Routers. Every few seconds, each connected Router transmits what is called a HELLO packet on both of its attached media simultaneously. A HELLO packet is addressed only to Routers and contains information for Routers to use for configuration. Assume, in our example, that the PL-CX Router transmits a HELLO packet first (Figure 5.5). The packet is picked up by the PL-TP Router from PL, and by the CX-TP Router from CX. By chance, the PL-TP Router routes the message to TP before the CX-TP Router. The CX-TP Router picks up the message from TP. When the Router detects the same packet (that originated from the same Router) on both media, it determines it is forming a loop, and disconnects (that is, it stops routing). The CX-TP Router continues to receive packets from both media, but it does not forward packets. As long as the loop condition continues, it remains off-line. If another Router is disconnected (for example, the PL-TP Router), it will go back on-line again and begin routing. Brouters Brouter is an abbreviation of Bridging Router. Brouters are like Routers except that they route packets between nonwired and the wired media; that is, between RF and one of the wired media (PL, CX, or TP). An RF Brouter can be located anywhere in the home that allows reliable reception and transmission of RF throughout the house (like a portable phone). The range of an RF Brouter is typically 100 feet. This means that one RF Brouter is usually sufficient for a typical home, but more than one may be installed. The need to maintain a tree topology is also true of Brouters, but the technique used to prevent multiple packets is different. More than one Brouter may receive the same packet.


59

Figure 5.4 Router configuration after CX-TP Router is added.

Figure 5.5 Use of the Router protocol to resolve multiple Router conflicts.

This results in more than one packet on the wired medium when only one was transmitted. The additional duplicate packets must be eliminated. Brouters cannot use the same technique for self-detachment that Routers use because there is no guaranteed transmission path on the nonwired side of Brouters. Because of this problem, duplicate RF packets must be eliminated using detection techniques in the CEBus node protocol. The technique is described in detail in the Network Layer Protocol section in Chapter 6. Data Bridges A Data Channel Bridge is like a Router for the data channels. Currently, only the wired media support data channels. If a device originates a data channel transmission on one media, it can be put on another wired media by a Data Channel Bridge. The Bridge receives one or more data channels on one medium and retransmits the information on another data channel on another medium. The Bridge changes the data channel output frequency to correspond to a valid channel on the output medium, and it can optionally change the modulation technique. Data Channel Bridges can operate only one way, receiving on one medium and transmitting on another, or they can be bi-directional, simultaneously translating between two media. A Data Channel Bridge must adhere to the same channel access protocol as any node; therefore, it must use the control channel on the medium

60

Chapter Five it transmits on to determine whether the desired data channel is available, or if it is being used by another device.

Medium, System, and Global Networks The interconnection of the various media in the home results in the formation of three different sub- and supertopologies as a result of how homes are wired: the medium network, the system network, and the global network. A medium network (Figure 5.6) consists of all nodes connected to one physical medium, such as the PL or TP medium. The size of the network is determined by the physical size of the medium. In the case of the TP and CX medium, the medium network is contained within one house or apartment. The PL medium network, however, extends to multiple houses and apartments because the physical wiring extends beyond the walls of the home. The system network (Figure 5.7) consists of all nodes on the network that share a common system address. The system network is a logical

Figure 5.6 A medium network.

Figure 5.7 The system network contains all nodes with the same system address on all media.


61

division with all the nodes connected by all the media, regardless of physical house location, to a particular home. All CEBus nodes have a unique address pair: a system address and a node address. The system address is the same for all nodes in a house or apartment, while each node address—in a given system address—is unique. The purpose of the system address is to logically isolate the nodes in one house from the nodes in another house, particularly on medium networks that span multiple houses (PL, RF). Messages addressed to a node in one system address cannot be received by nodes in another system address. The global network (Figure 5.8) consists of all nodes that can communicate or hear each others’ packets. The best examples occur on the PL and RF medium network. The PL medium networks in adjacent homes are interconnected, forming a global network. For example, the packets transmitted by PL nodes in my house can be heard by nodes on the PL network in my neighbor’s house. The same is true of RF. The RF transmissions in my house can be expected to be heard by RF nodes in my neighbor’s house. All the nodes that can hear each other form a global network for that medium.

Connection to the Outside World The connection from the CEBus medium architecture to a Wide Area Network (WAN) such as the Internet, is through one or more Network Interface Units (NIUs). WAN services include twisted-pair telephone service, cable service, ISDN, cable telephone service, high-speed Internet access, and the like. An NIU performs at least two functions: It terminates the electrical characteristics of the external medium and translates, if necessary, to the local electrical characteristics. For

Figure 5.8 The global network consists of all nodes that are able to communicate.

62

Chapter Five example, it may connect between an external fiber-optic network and the house power line. It translates external signaling techniques and message formats to CEBus packets on CEBus media (and possibly from CEBus to an external format as well). For example, it may receive RF high-speed messages from an external cable network and translate them to standard CEBus packets on the house TP network. An NIU may be strictly used for data channels, control channels, or both. It may be part of Node 0 or connect to a medium like any other node. As long as it provides the necessary interface and isolation function, there are no other specific requirements.

The PL Network Power-line wiring is the most common CEBus medium because it is always available. All CEBus products use electricity and most connect to the power line for their power; therefore, it is natural to use the power line as a communications medium. However, while the medium is always available, it is not the easiest to use. The power line is not intended for any purpose other than to transport 60-cycle, 120-volt, high-current power, and its design is not at all conducive to data communications. The CEBus PL technology was developed to overcome many of the disadvantages and hardships of using the power line for data communications, including noise, severe attenuation, and a medium network that spans many houses.

Power-Line Topology Power-line wiring in the home consists of a series of wiring branches (carrying 120 volts AC) from a central circuit breaker (Figure 5.9). Several outlets connect to each branch, enough to average less than 15 to 20 amps for typical appliances. The breaker box is connected to a “service entrance” cable consisting of three wires, called L1, L2, and Neutral. There is 120 volts between L1 and Neutral, and between L2 and Neutral. There is 240 volts between L1 and L2. All 120 volt branches in the home use L1 and N, or L2 and N. All 240 volt branches use L1 and L2. The three-wire service is connected to a local distribution transformer (located on a concrete pad


63

or on a pole) that steps the high voltage power company feed down to 240 volts for distribution to neighborhood houses or an apartment building. As many as ten houses (or twenty apartments) may connect in parallel to the same distribution transformer. All power-line wiring from the distribution transformer, including all branches in all attached houses, comprise the PL medium network. A physical connection exists between the outlets in any house with the outlets in all other houses connected to the same distribution transformer. This connection provides a signal path for all CEBus devices connected to the PL medium network. Figure 5.10 shows how the network appears to each node. This schematic shows that, as far as the PL wiring from the distribution transformer is concerned, there are no houses. Each 120-volt CEBus PL device

Figure 5.9 Physical representation of a typical PL network from a distribution transformer. There are typically 5 to 10 houses on one transformer.

Figure 5.10

Electrical diagram of the physical PL network from the distribution transformer.

64

Chapter Five transmits packets using L1 and N, or L2 and N, depending on the pair it is plugged into. Every 240-volt CEBus PL device transmits packets on L1L2. The network is large, and the loads are constantly changing. CEBus devices are also constantly being connected and disconnected. This means that the signal attenuation of the wiring and noise induced by appliances, such as motors and switching power supplies, is constantly changing as well. Packets transmitted in one house (or apartment) may travel to all other houses on the PL medium network. To prevent device interference between homes, CEBus creates system networks in each house using the system address partition. The system address logically isolates the nodes in one house from the nodes in another house. The address configuration algorithm employed by CAL ensures that no two houses (or apartments) have the same system address.2

CEBus Signaling on the PL To overcome the problems inherent in the power line, CEBus uses a spread-spectrum signaling technology for the control channel. Spreadspectrum signaling works by spreading a transmitted carrier over a range of frequencies rather than using a single frequency. The CEBus PL carrier is spread over the range of 100 to 400 kHz during each bit in the packet. Unlike traditional spread-spectrum techniques that use frequency-hopping or direct-sequence spreading, the CEBus PL carrier sweeps

Figure 5.11

Power line spread-spectrum waveform for a SUPERIOR state 1 symbol.

2

Several types of power-line carrier-isolation devices are available to electrically isolate a house or apartment from its neighbors. These devices usually take the form of an inductive filter placed in series with the incoming electric service. They attenuate both incoming and outgoing packets.

65


through a range of frequencies as it is transmitted. A typical spread-spectrum waveform, representing the CEBus “1” bit, is shown in Figure 5.11. The waveform is synthesized from a table of 360 digitized values given in the standard. The points were chosen to maximize in-band energy while keeping harmonic out-of-band content to a minimum. Notice that the waveform frequency starts at 200 kHz and sweeps to 400 kHz, jumps to 100 kHz, and then sweeps to 200 kHz. The phase transition from 400 to 100 kHz was kept within the body of the waveform to better control the abrupt transition. The complete 200–400/100–200 kHz frequency sweep (called a chirp) takes 25 cycles in 100 s. Bandpass of Chirp The odd shape of the spread-spectrum carrier waveform is due to several technical and FCC requirements, and results in the frequency spectrum shown in Figure 5.12. The energy of the chirp is concentrated in the band of frequencies between 100 and 400 kHz. The amplitude of any out-of-band energy above 400 kHz must be less than 1 mV to not only meet FCC conducted emission limits, but to ensure that packets on PL will not cause interference with inexpensive AM radios attached to the same wiring. The amplitude of any out-of-band energy below 100 kHz must be less than 5 mV. This level also meets FCC limits and prevents potential interference with services such as LORAN.3 By literally hand “tweaking” the waveform, the band edges are fine-tuned to achieve a high degree of out-of-band attenuation while allowing up to 7 volts peak within the band. Filtering is still required to and from a PL transceiver, but is minimized by the wave shape.

7.0 V

Figure 5.12 Frequency spectrum of the PL spread-spectrum waveform. PL carrier spectrum 5 mV

1 mV

100 kHz 3

400 kHz

LORAN operates at 100 kHz throughout the United States and provides air and marine radio navigation.

66

Chapter Five Encoding States The waveform in Figure 5.11 represents the SUPERIOR state. Because it lasts for 100 s, it is a SUPERIOR 1. The 0, EOF, and EOP symbols are formed by repeating the waveform every 100 s. The INFERIOR state is represented differently during different parts of the packets. During the Preamble (the first byte of the packet), the INFERIOR state is represented by the absence of a spread-spectrum carrier—the normal form of the CEBus INFERIOR state. During the information portion of the packet (everything except the Preamble), the INFERIOR state is represented by the inverse SUPERIOR state; that is, the SUPERIOR state chirp is inverted 180° as shown in Figure 5.13. The “normal” SUPERIOR state is called the SUPERIOR Ø1. The INFERIOR state is referred to as the SUPERIOR Ø2 state (the phase inversion of SUPERIOR Ø1). The INFERIOR state is represented by the SUPERIOR Ø2 because it is necessary to have the carrier on at all times during the information portion of the packet to keep the receiver “locked” onto (to correlate and track) each Unit Symbol Time (UST) in the packet and to still be able to use the INFERIOR/SUPERIOR distinction to represent symbols. This greatly enhances received signal reliability. The INFERIOR state is represented by the absence of a signal during the Preamble to allow the Data Link layer (DLL) access protocol to function properly. This protocol relies on the detection of another node’s SUPERIOR state

Figure 5.13 The SUPERIOR Ø1 waveform and the INFERIOR state version of the waveform, the SUPERIOR Ø2 waveform.


67

Figure 5.14 Portion of a PL packet showing two symbols of the Preamble and two symbols of the rest of the packet.

during the INFERIOR state (the absence of a carrier) to detect a collision with another transmitting node. A spread spectrum receiver works by recognizing the pattern of the received signal. It compares, or correlates, the received signal pattern with an internal representation of the pattern. If enough of the received pattern matches, the signal is detected. After the received signal pattern is initially matched, the receiver “locks on” to the carrier and its detection job becomes easier, because each following symbol must occur at regular 100 s intervals. It may take several USTs of carrier for the receiver to match the incoming spread-spectrum waveform correctly, but once locked to the waveform, symbol detection is robust.

Packet Encoding Figure 5.14 shows part of a typical PL packet. A packet starts with a Preamble consisting of a pseudorandom pattern of eight 1 or 0 symbols followed (on PL and RF only) by a Preamble EOF symbol consisting of eight SUPERIOR 1 symbols. The first symbol of the Preamble always starts in the SUPERIOR state. The Preamble EOF is followed by the information portion of the packet. A small portion of the Preamble and the information portion of the packet are shown in Figure 5.14. Notice that during the Preamble, the SUPERIOR state is represented by the presence of a carrier (the SUPERIOR Ø1 state), and the INFERIOR state is the absence of a carrier. During the information portion of a packet, the SUPERIOR and INFERIOR states are represented by the SUPERIOR Ø1 state and the SUPERIOR Ø2 state, respectively. One of the two versions of the carrier is on at all times. The timing of the states during the Preamble is slightly different. This timing difference allows easier detection of the Preamble, especially during noisy conditions, and prevents

68

Chapter Five the receiver from mistaking the Preamble for the information portion of the message if a collision occurs during the Preamble. The advantage of the spread-spectrum signaling used by CEBus is that it can overcome the two worst PL signaling problems: attenuation of a band of frequencies by certain electrical loads, and noise generated by dimmers, motors, and the like. The CEBus spread-spectrum carrier can tolerate attenuation and noise over many frequencies as long as enough of the signal gets through to the receiver. Because spread-spectrum receivers work by recognizing the pattern of the waveform and because they are relatively insensitive to the amplitude, the signal can withstand attenuation and noise that destroys nearly half the waveform and still be recognized by the receiver. This makes CEBus PL signaling highly reliable.

Physical Layer Implementation The PL physical layer is responsible for generating and detecting the presence of INFERIOR (both types) and SUPERIOR states on the PL medium. Figure 5.15 illustrates the typical components of the power line physical layer. The CELinx IC is a CEBus spread-spectrum symbol generator/detector. Symbol data is passed from the Data Link layer to the IC (1, 0, EOF, EOP). The IC generates the necessary spread-spectrum waveform that is bandpass filtered, amplified, and coupled to the AC line. The bandpass filter provides additional out-of-band attenuation. The coupling network consists of a toroid impedance-matching transformer and a 60-Hz blocking capacitor. Coupling is between Neutral and L1 or L2. Protection should also be provided for high-voltage AC transients coupled from the power line.

Figure 5.15 PL physical layer components for a typical power-line interface.


69

The output network (amplifier, filter, coupling components), needs to provide an output signal between 100 and 400 kHz at a signal level on the power line of between 2.5 volts and 7.0 volts peak-peak into an impedance of 10 to 2 k. Power-line impedances vary greatly over this frequency range. The localized, lumped impedance of the power-line wiring in a home over the 100 to 400 kHz frequency range will vary from a low of 0.8 to 20 or more depending on the appliances connected to the network. Most of the attenuation experienced on the PL comes from attached devices, but because the power-line wiring has a typical impedance in the CEBus frequency range of about 10 per 100 feet, the wiring impedance tends to isolate transceivers from severe loads if they are far enough away. Reception of the spread-spectrum carrier is through the same coupling network as the transmitter and a receive bandpass filter. The bandpass filter reduces out-of-band received noise and prevents front-end overload. The receiver must be capable of detecting symbols correctly with a received signal amplitude of 0.5 mV to 7.0 volts while in the presence of impulse and continuous noise. This represents about a 65-dB received signal dynamic range. Figure 5.16 is a block diagram of a typical PL spread-spectrum IC. The received signal is amplified, A/D converted, and fed to the heart of the chip, the matched transversal filter. The filter provides correlation of the received signal with an internal template of the SUPERIOR Ø1 and SUPERIOR Ø2 waveform. The magnitude of the correlation is directly related to the quality of the received chirp. The state of the correlation (SUPERIOR Ø1 or Ø2) is determined by the phase of the chirp. Once the filter has begun to track the incoming data, it will maintain tracking with only marginal signals for over 1 ms before indicating a

Figure 5.16 Block diagram of typical PL transceiver IC. This example is based on the CELinx IC from Intellon Corp.

70

Chapter Five loss. The filter outputs an indication of a match with either waveform. The digital logic uses symbol-detection indication timing from the filter to compute received symbols and pass them to the attached Data Link layer. Transmitted symbols are fed to the output waveform generator. The waveform generator consists of three parts: a ROMed wavetable, a D/A converter, and an output amplifier. The 360-point wavetable contains the binary image of the output chirp. An address generator clocks through the complete table for each chirp transmitted. Either the “true” or inverted version of the wavetable data is output to a 6-bit D/A, depending on the SUPERIOR phase required. The IC also contains the CRC computation logic. As the packet is transmitted, the CRC logic computes a 16-bit CRC. When the EOP is received and transmitted by the chip, the 16-bit CRCs are appended to the packet. As a packet is being received, and the end of the Preamble is detected, the CRC logic does the same calculation on the received bits of the information part of the packet. When the EOP is received, the remaining 16 bits are internally stored and compared with the calculated CRC. The results of the comparison are passed to the Data Link as a “good packet” or “bad packet” indication.

PL Performance The reliability of the CEBus spread-spectrum control channel in a typical residential PL network is very good. Packets are typically delivered error free well over 98 percent on the first try. With the packet retry mechanisms built into the Data Link layer (described in Chapter 6), message delivery can approach 100 percent. However, no PL signaling technology is perfect and conditions can exist in a home that will severely interfere or completely block transmission. The problems—caused by other appliances that connect to the power line—fall into two categories: devices that generate power-line “noise,” and devices that absorb powerline signals. Devices that generate noise include broadband “blasters” such as wireless intercoms, baby monitors, and PL music distribution devices. The music distribution system is the worst. These devices transmit the output of stereo receivers or CD players to remote speakers plugged into the power line. The interference from these devices is worse when they are located near a CEBus PL receiver. Devices that absorb power-line signals are becoming more troublesome with the increasing popularity of PCs in the home and the accompanying proliferation of surge protectors. PCs limit the noise


71

they couple to the power line by typically placing a large capacitor (0.1 f) across the power line at the power supply. This capacitor shorts noise from the PC as well as any other “noise” on the power line where it is connected, including CEBus spread-spectrum “noise.” A worse problem, however, is the proliferation of inexpensive surge protectors built into outlet strips and other power connection devices. To cut costs, these things simply place a large capacitor (and a MOV or two) across the power line and call themselves “protection.” These devices provide little protection, but potentially a lot of trouble. A CEBus node (or any device that uses a power-line carrier) plugged into one of these devices will usually not communicate. The only solution is to eliminate or inductively isolate them. A good surge protection device uses inductive isolation for attached loads. This prevents communications through the device but does not interfere with signals on the power line.

The TP Network The TP Physical Layer of the CEBus standard is based on the Telecommunication Industry Association (TIA) residential telephone wiring standard (ANSI/TIA/EIA-570A). TIA-570A is a residential telephone premise wiring standard that describes how new homes should be wired for high-quality telephone service. In the home, the standard specifies that a four-pair twisted and jacketed cable be run from a central location—or distribution point—to outlets in each room. Incoming telephone service is connected at the distribution device to each branch cable. CEBus builds on TIA-570 to include all the requirements necessary to transmit control and data channels on the same cable. The added CEBus requirements include the addition of a power supply to one of the pairs, and defining proper lengths and termination necessary to support the signal bandwidth used for control and data channels.

TP Cable and Wire Use The TP cable specified by the CEBus standard is the same as that specified in TIA/EIA-570A: four twisted, unshielded, jacketed pairs. This type of cable is referred to as UTP (unshielded twisted-pair) and is shown in Figure 5.17.

72

Chapter Five

Figure 5.17 TP cable uses four twisted-pairs labeled TP0, TP1, TP2, and TP3. Each pair uses a colored wire with a white stripe, and a white wire (which may have a small stripe of the same color).

Note that the TIA-570A specification specifies the use of Category 3 rated cable or better, while the CEBus specification is intended to use any twisted-pair cable rated Level 2 or better. TP cable ratings are described in ANSI/TIA/EIA-568 and TIA TSB-67. Each pair in the cable is color coded. The cable must use 22 or 24 AWG solid conductors with a maximum resistance of 29 per 1,000 feet. The cable must also meet the specifications listed in the following table. These specifications are easily met by 24-gauge Category 3 or better cable.

TP Cable Specifications Characteristic

Minimum

Maximum

DC resistance (per 1000 ft) 22 AWG:

18

24 AWG:

29 Ω

Mutual Capacitance

20 pf/ft

Attenuation (per 1000 ft) at 1 kHz:

0.5 dB

at 1 MHz:

7.8 dB

73

The Media and Physical Layers TP Cable Specifications (Continued) Characteristic

Minimum

Maximum

at 1 kHz:

500

700

at 1 MHz:

85

115

Characteristic Impedance

These specifications allow the four-pair twisted cable already installed in many homes to be used for control and data channel transmission. This minimum specification will give acceptable results with basic (Level 2) four-pair twisted cable with the length restrictions specified in the standard. Wire Color The pair coloring specified in the CEBus standard is based on the standard TIA-570A pair coloring and given in the following table.

TP Pair Coloring Specifications TIA Pair

CEBus Designation

Pair Color

Pair 4

TP0

Brown White/Brown

Pair 3

TP1

Green White/Green

Pair 2

TP2

Orange White/Orange

Pair 1

TP3

Blue White/Blue

Wire Pair Use Table 5.1 shows how each wire pair is used by the CEBus standard. Wire pairs are named TP0, TP1, TP2, and TP3. TP0 is used for the control channel and data channels. TP1, TP2, and TP3 are optionally used for data channels only. The use of data channels on TP is entirely optional and can be used only if the cable is dedicated to CEBus use. The selection of the wire pairs for CEBus is intended to allow easy coexistence with other services likely to be used on TP cable, including

74 TABLE 5.1 TP cable-pair usage showing control and data channel assignments to each pair.

Chapter Five 18V DC

TPO

Brown/White White

Control Channel

Data Ch. 4-32

TP1

Green/White White

Data Ch. 32-63

TP2

Orange/White White

Data Ch. 64-95

TP3

Blue/White White

Data Ch. 96 -128

voice, ASDL, Ethernet, and so on. It does not conflict with the newer HomePNA technology (that uses Pair 1—the blue pair). TP0 can also be used to distribute 18 volts DC to power low-voltage attached devices. The table shows the assignment of the control channel and data channels to each pair.

TP Control Channel The TP control channel is a 10-kHz square wave transmitted at baseband on TP0 in a reserved frequency band from 0 to 128 kHz. The remainder of TP0 and all of TP1 to 3 is reserved for data channels. The data channel frequency space on each pair is divided into 32 channels (each channel is 32 kHz wide). Figure 5.18 illustrates the control channel encoding. The control channel uses a low-voltage 10-kHz differential signal superimposed on the power supply voltage to encode the SUPERIOR and INFERIOR states. A SUPERIOR state is represented by the presence of either a positive or negative differential voltage relative to the average DC supply voltage present on the TP0. The encoding waveform can be thought of as the output of a 10kHz square-wave generator, gated on and off in multiples of 100 s to represent the symbols. Gating the square wave on for 100 µs (one-half cycle of the 10-kHz waveform) represents a SUPERIOR 1 symbol. Removing the waveform for 100 µs represents an INFERIOR 1. Notice that the SUPERIOR state waveform must be generated in such a way that there are an equal number, on average, of positive and negative half-cycles. This prevents TP control channel transmitters from inducing a DC bias. The voltage amplitude of the SUPERIOR state can vary between ±150 to 600 mV. The absence of a differential voltage (zero volts


Figure 5.18

75

TP control channel encoding using a grated differential square wave.

with respect to the DC level) represents the INFERIOR state. The allowed output voltage variation for the control-channel waveform makes it relatively easy to meet a wide impedance variation by using a simple current drive output stage.

TP Physical Layer The TP physical layer requirements can be met in a number of ways. No specific TP transceiver ICs were available at the time this book was written. The TP physical layer can be implemented using existing ICs or discrete components. The basic transceiver requirements are shown in Figure 5.19. The control channel transmitter must be able to deliver a differential baseband signal in the range of 150 to 600 mV and be able to reliably receive the control-channel signal down to 25 mV. The input impedance must be 2.5 k or more while not transmitting. Out-of-channel signal amplitudes from the control channel waveform must be less than 2.5 mV above 128 kHz. Figure 5.20 shows a representative control channel transceiver in more detail. Coupling to and from TP0 is via a hybrid transformer with windings for the receiver section and transmitter section. The TP winding is D C blo cked by a capacitor. Power is extrac ted through a bucking choke to filter control and data channel AC components and to maintain a high input impedance at frequencies above about 2 kHz.

76

Chapter Five

Figure 5.19 Typical control channel electronics using inductive coupling to TP0. A simple blocking filter must be used if the device obtains power from TP0. The SE sublayer is the portion of the Physical layer that encodes and decodes symbols.

Figure 5.20 CX cable pairs. The Internal cable is bidirectional for all control and in-home data channels. The External cable is single directional (unless a reverse channel is used by the cable company).

Control Channel Data Channels 1-64

Internal

In-home-generated video

Cable TV Off-air (VHF/UHF/FM)

External

Optional in-home-generated video

The CX Network The CEBus coaxial cable (CX) network distributes audio, video, and wideband signal sources throughout the home. The network replaces the traditional single coax cable TV wiring and provides additional capability for distributing high data bandwidth source material. The network was designed by the CEBus Committee to distribute signals reliably up to 1 GHz to or from any coaxial outlet in the home. This bandwidth will handle any expansion of cable TV channel capacity for the foreseeable future. The CX network, like the TP network, originates at a central location in the home and provides branch cables to each room of the house. Unlike the TP network, CX is a true transmission—line network—each branch consists of a pair of coaxial cables, driven and terminated separately. One cable of the pair, the EXTERNAL cable, provides all source material (video, audio, data) from outside the home, such as cable televi-

77


sion services or off-air broadcasts. The other cable, the INTERNAL cable, is used for all in-home–generated material such as video from VCRs, security cameras, data from computers, and audio from CD players. Figure 5.20 shows application assignment.

The Cable The CEBus coaxial cable specification is designed to be met by existing good quality RG-6 (or better) cable to handle signals up to 1 GHz with minimum attenuation and minimum radiation and leakage (into and out of the cable). The cable must meet the electrical and mechanical specifications in the following table. Coax Cable Specifications Characteristic

Minimum

Maximum

0.039”

0.042”

Center conductor Diameter:

36

Resistance/1000 ft: Dielectric O.D.

0.175”

0.185”

Shield % foil coverage: % braid coverage:

100% 59% 5

Resistance/1000 ft: Jacket O.D.

0.265”

0.281”

Impedance

72

78

Capacitance

17 pf/ft

Attenuation (dB/100 ft) at: 5 MHz:

0.80

1.2

100 MHz:

2.1

2.6

500 MHz:

5.0

6.1

800 MHz:

6.4

7.9

1000 MHz:

7.2

8.9

78

Chapter Five RG-6 coax should have at least two layers of foil and braid shielding; however, four layers (two foil and two braid) are recommended. Because two cables are used in each branch, it is preferable to install “siamesed” coax—two cables that are joined together like the two conductors of common lamp cord. The two cables must use different color PVC jackets (black and white) or be marked INTERNAL and EXTERNAL to distinguish between the internal and external cables.

CX Network Topology The CX network topology is shown in Figure 5.21. Cable-pair branches originate at a central distribution amplifier and block converter, and branch to a four-way cable splitter in each room. Within each room, up to four branches are run to dual cable outlets. In-home–generated data channel sources transmit on the INTERNAL cable. These signals are received at the amplifier/block converter, block converted to a higher frequency band, amplified, and then distributed back on all INTERNAL cable branches. External video sources (cable or off-air) are amplified and distributed on the EXTERNAL cable. An attached device, such as a television, can view outside services from the EXTERNAL cable, and in-home sources from the INTERNAL cable. The cabling topology must adhere to these rules: All unused outlet connectors and unused splitter connectors must be terminated in a 75 resistive termination. Each branch must have one to four CX wall connectors attached to the four-way splitter.

Off-air antenna

INTERNAL Cable EXTERNAL Cable

Cable Service

4 way Splitter

Amp./Block Conv. Distribution Device

Wall connector pair

4 way Splitter

Figure 5.21 CX cable topology. Any number of branches can be made from distribution device if proper amplification is provided. Each branch can also be “homerun,” instead of using a splitter (recommended).

150' MAX


79

The maximum distance for any one branch from the Node 0 distribution device to the farthest wall connector must be no more than 150 ft. The signal input/output specifications must be met for the Node 0 distribution device to be capable of handling any number of cablepair branches. While the standard assumes that the outlets from any splitter are used in one room, the outlets may be placed anywhere as long as the total cable branch from the distribution device to the outlet does not exceed the cable branch limit of 150 ft. Because each branch contains two cables, the four-way splitter shown in Figure 5.21 really consists of two four-way splitters: one for the INTERNAL cable and one for the EXTERNAL cable. The signal attenuation inherent in the splitter is compensated for in the distribution electronics. The splitter can be installed anywhere as long as it is accessible for service. There is no specific location requirement for the placement of the four-way splitter in the branch. In fact, the four-way splitter can be inside the Node 0 distribution device. This produces a slightly different equivalent topology in which each branch cable run originates at the Node 0 distribution device and terminates at the wall connector. This is the way most coax distribution devices on the market operate. As long as the signal amplitude is the same from the distribution device as it is out of the splitter, the four-way splitter can be functionally integrated in the distribution device to allow “home runs” to each outlet.

Cable Connectors and Outlets Connection to the CX network is via a dual coax outlet as shown in Figure 5.22. The connectors are standard coax F-style screw-on feed-through jacks. The outlet must label the INTERNAL and EXTERNAL jack. Unused jacks must be terminated in 75 resistance, either by connecting to an external terminator, or by using a self-terminating jack. The standard recommends that the coax male connectors employ a push-on-and-lock mechanism to maintain connection with the female jack, and a self-crimping mechanism over an internal mandrel to maintain connection with the coax cable. The standard also recommends using polarized cable connectors that prevent a cable from being attached to the wrong outlet jack. The EXTERNAL cable connector is polarized with two tabs set 180° apart,

80 Figure 5.22 CX wall plate showing the two required connectors for INTERNAL and EXTERNAL cables. Distance shown between connectors is to allow attachment of a molded dual cable connector.

Chapter Five

INTERNAL

0.75" min.

EXTERNAL

while the INTERNAL cable connector is polarized with two tabs set 90° apart. Polarizing slots are shown in Figure 5.20.

Node 0 Distribution Device Figure 5.23 is a func tional blo ck diagram of the No de 0 amplifier/block converter/distribution device. The diagram only shows the general construction of the distribution device and is not meant to imply a specific implementation. Not all the items shown in the diagram are required. Control-channel packets are transmitted by CX nodes on the INTERNAL cable modulated at 5.5 MHz, and are received and combined at the INTERNAL splitter. A control channel regeneration device converts the packets to 4.5 MHz and amplifies them for distribution back on each INTERNAL cable branch. CX Node 0 Distribution Device Data channel signals transmitted from nodes on the INTERNAL cable are also received and combined at the INTERNAL splitter. They are passed through a 54–150-MHz bandpass filter prior to the block converter. The block converter converts the received 54–150 MHz band to a 450–546 MHz HI band (or to a 318–414 MHz LO band, selectable on the block converter). The blockconverted data channels are then amplified and placed back onto the INTERNAL cable.


81

Figure 5.23 CX distribution device block diagram. The functions may be provided as separate components or combined in one box. Most of the functions are optional, including the return channel path for cable service.

An optional output selector can place the block-converted data channels onto the EXTERNAL cable if the frequency space is not in use by a cable service. The block diagram shows two sources of external video: an off-air antenna input and a cable input. One or the other can be used. Whichever source is selected, it is amplified and placed on the EXTERNAL cable. An optional low-frequency (5–50 MHz) return cable path is shown for use by cable service providers that have reverse channel capability.

Coax Control and Data Channels The frequency allocation for each cable is shown in Figure 5.24. The CX data channel resides at 4.5–5.5 MHz on the INTERNAL cable.

82

Chapter Five Attached devices transmit the control channel on 5.5 MHz, and the distribution device regenerates the signal back onto all attached INTERNAL cables at 4.5 MHz. The INTERNAL cable is used for distribution of all in-home–generated video. There are sixty-four 1.5 MHz data channels available from 54 MHz to 150 MHz. Standard NTSC video signals transmit on four contiguous data channels (6 MHz). Thus, 16 standard television channels can be transmitted simultaneously. The data channels are block converted to 450–546 MHz and amplified for redistribution back on the INTERNAL cable for reception by CX devices. The data channel frequencies were chosen to enable transmitted video channels to be viewed on standard cable television channels 70 through 85. Figure 5.24 shows two versions of EXTERNAL cable frequency use. One is for cable television, the other is for off-air (VHF and UHF) reception. The typical bandwidth used by cable companies is 54 to 450 MHz for cable channels 2 to 69, but many cable operators furnish additional channels and services up to 850 MHz. Off-air VHF and UHF frequencies are also shown. It is possible to place the block-converted data channels on the EXTERNAL cable for viewing by devices that only connect to the EXTERNAL

Figure 5.24

CX frequency allocations on the EXTERNAL and INTERNAL cable.

83


cable. If cable service is being received and no cable signals are present above 450 MHz, the HI block-converted band can be placed on the EXTERNAL cable. If off-air service is being received, the LO block-converted band (318–414 MHz) can be placed on the EXTERNAL cable. These frequencies, however, are cable channel frequencies, and to view them, the receiver must tune to cable rather than off-air channels. CX Control Channel The CX control channel transmitter uses an amplitude shift-keyed 5.5 MHz carrier. The carrier output amplitude is nominally 100 mV peak to peak. The time the carrier is on or off determines the symbol. The presence of the carrier represents the SUPERIOR state, and the absence of a carrier represents the INFERIOR state. Figure 5.25 shows typical encoding for a CX control channel. The carrier is received by the control channel receiver at 4.5 MHz, having been block converted and amplified in the Node 0 distribution device.

CX Physical Layer The CX physical layer can be easily implemented using discrete components. The basic transceiver requirements are shown in Figure 5.26. The control channel transmitter must deliver a nominal 100 mV of 5.5 MHz ASK carrier. This can be easily implemented by gating a 5.5 MHz oscillator from the symbol data stream. The receiver must recognize the carrier down to 16 mV, and demodulate the AM back to a symbol data stream.

100 s "1"

200 s "0"

200 s "0"

200 s "0"

100 s 100 s 100 s "1" "1" "1"

5.5MHz 100 mV

SUPERIOR STATE

INFERIOR STATE

SUPERIOR STATE

INFERIOR STATE

SUPERIOR INFERIOR SUPERIOR STATE STATE STATE

Figure 5.25 CX control channel encoding. Nodes transmit an ASK 5.5 MHz carrier. Nodes receive the control channel at 4.5 MHz.

84

Chapter Five

Figure 5.26 CX Physical layer transceiver block diagram. Nodes transmit at 5.5 MHz and receive at 4.5 MHz.

CEBus RF CEBus RF communication uses the 902–928 MHz radio band. This band is just above the cellular phone band and is shared by other licensed and unlicensed users. This band was chosen because of the wide frequency space available for low-power unlicensed consumer devices, and because transceiver technology for this band is widely available due to the introduction of many 902–928 MHz consumer products. The CEBus RF medium is similar to PL in two ways: First, it is used by other services. The 902–928-MHz band is used by consumer unlicensed products such as portable phones, baby monitors, remote IR repeaters, and other low-cost consumer products. It is also used by some licensed applications such as vehicle locators and amateur radio. Second, it is not limited to a single apartment or house. Because CEBus RF devices have a range of about 100 ft, they can easily be received by neighboring houses and apartments. Therefore, all of the potential interference problems inherent in PL also exist on RF. While RF does not suffer like PL does from attenuating devices on the medium, it does have additional unique problems. RF signals at frequencies as high as 900 MHz are subject to relatively small metal obstructions, such as metal building framing, filing cabinets, refrigerators, and similar objects, that can cause signal reflections and blockage. Care must be taken during installation of RF devices to make sure that a usable signal path exists with other devices in the home.

CEBus RF Signaling The CEBus RF control channel also uses a spread-spectrum signaling technique. While the PL spread-spectrum carrier used an analog waveform, the RF carrier is digitally synthesized.


85

The control channel is generated using a 4.3- to 6.2-MHz directsequence spreading function to modulate a 915-MHz carrier. This results in a double sideband output spectrum with sidebands centered at 5.25 MHz above and below the carrier frequency. The receiver can tune either or both sidebands. Like PL, the RF receivers are sensitive to the pattern of the received signal rather than the amplitude, and once the receiver “locks on” to a signal, it can still receive the packet in the presence of considerable interference, including other CEBus RF signals. The data rate and packet format is the same on RF as it is on CX, PL, and TP. While a frequency allocation is possible for a data channel, one has not yet been specified for CEBus RF. The CEBus RF specifications require that CEBus RF devices be able to communicate over a free space distance of 100 ft. In a home, the distance will be reduced depending on the materials in the home and device placement. While RF signals may be transmitted or received from a neighbor’s house, the different device system addresses will prevent message interference.

RF Control Channel Encoding Like PL, the RF control channel relies on the spread-spectrum carrier being always on during the information portion of the packet. This results in the need for two SUPERIOR states during the information portion of the packet, the SUPERIOR Ø1 and Ø2 to represent the INFERIOR state. The basic SUPERIOR Ø1 state is generated by a digital “spreading sequence” that modulates a 915 MHz carrier. Figure 5.27 illustrates that each SUPERIOR UST is made up of seven substates. A substate is generated from a series of 360 25.2-MHz bits that last for one-seventh of a UST and form a 4.3–6.2-MHz spreading sequence. Seven substates are combined (2,520 bits from seven spreading functions) to form one complete UST. There are two different, and opposite, spreading sequences. The top sequence shown in Figure 5.27 represent the bit order of the forwardspreading sequence. The 1 and 0 bit pattern of this sequence starts, as can be seen, from three 1s, then three 0s, then three 1s, and so on, forming a 4.2-MHz square wave. The bit sequence is dithered from three 1s and three 0s to a series of two 1s and two 0s (6.3 MHz) by the end of the sequence. In between, sequences of three 1s and 0s are mixed with two 1s and 0s, so that there is an even frequency distribution between 4.2 and 6.3 MHz. The bottom sequence in the figure is just the reverse; it

86

Chapter Five

Figure 5.27 RF UST encoding. Each UST consists of one of two combinations of a 360-chip sequence. One combination forms the SUPERIOR Ø1; the other combination forms the SUPERIOR Ø2.

spreads from 6.3 MHz to 4.2 MHz and is called the reverse-spreading sequence. The normal SUPERIOR state, the SUPERIOR Ø1, is formed by combining the spreading sequences in the order shown in Figure 5.25: forward, forward, forward, reverse, reverse, forward, reverse. The SUPERIOR Ø2 UST, used to represent the INFERIOR state during the information portion of the packet, is formed by combining the spreading sequences in just the opposite order. The reverse pattern makes it easy for the spread-spectrum receiver to differentiate between the two states. The spreading sequence that makes up each SUPERIOR state is repeated as many times as necessary to form each symbol (twice for zero, three times for an EOF, and four times for an EOP). During the Preamble, the INFERIOR state is represented by the absence of a spread-spectrum carrier. The absence of a carrier or signal is the normal form of the CEBus INFERIOR state. During the information portion of the packet, the INFERIOR state is represented by the reverse SUPERIOR sequence; that is, the SUPERIOR Ø2 spreading sequence in Figure 5.25. The INFERIOR state is represented as a SUPERIOR Ø2 state because of the necessity of having the carrier always on during the information portion of the packet so as to keep the receiver “locked”


87

onto the packet while still using the INFERIOR/SUPERIOR distinction to represent symbols. This greatly enhances received signal reliability. The INFERIOR state is represented by the absence of a signal during the Preamble to allow the Data Link layer (DLL) access protocol to function properly. The protocol relies on the detection of a carrier during the INFERIOR state to detect a collision with another transmitting node. A spread-spectrum receiver works by recognizing the pattern of the received signal. It compares, or correlates, the received signal pattern with an internal representation of the pattern. If enough of the received pattern matches, the signal is detected. Once the received signal pattern is initially matched, the receiver locks on and its job becomes easier because each following symbol must occur at regular 100 s intervals. Figure 5.28 shows a sample of the packet waveform. During the preamble portion of the packet, the SUPERIOR state is represented by the presence of the SUPERIOR Ø1 carrier spreading (although slightly modified), and the INFERIOR state is represented by the absence of a carrier. During the information portion of the packet, the SUPERIOR state is represented by the SUPERIOR Ø1 carrier spreading and the INFERIOR state is represented by the SUPERIOR Ø2 carrier spreading. The timing of the spreading sequence during the preamble is slightly modified (the symbol time is 114 s, and a slight delay is placed between each substate). This timing difference enables easier detection of the Preamble, especially during noisy conditions, and prevents the receiver from mistaking the Preamble for the information portion of the message if a collision occurs during the Preamble.

RF Physical Layer The RF physical layer is responsible for generating and detecting the presence of INFERIOR (both types) and SUPERIOR states to and from the RF medium. Figure 5.29 illustrates the typical components of the RF physical layer. This diagram is based on the CELinx RF CEBus spreadspectrum IC made by the Intellon Corporation. The RF CELinx IC is a digital spreading-sequence symbol generator/detector. Symbol data is passed from the Data Link layer to the IC (1, 0, EOF, EOP). The IC generates the necessary digital spreading sequence for SUPERIOR Ø1 or SUPERIOR Ø2. The digital spreading sequence is bandpass filtered and mixed with the output of a 915-MHz local oscillator. The outputs of the mixer (both mixing products) are

88

Chapter Five

Figure 5.28 Portion of the RF packet showing two bits of the preamble and two bits of the information portion of the packet. During the Preamble, the formation of the SUPERIOR UST is altered to prevent false receiver synchronization.

Figure 5.29 Typical RF transceiver block diagram. Output of the spreadspectrum digital IC is converted to the RF frequencies by a 915MHz local oscillator.

amplified and coupled to an antenna. The RF output spectrum looks like Figure 5.30. The mixer generates two 2.1-MHz sidebands, one centered at 909.75 MHz, the other centered at 920.25 MHz. The radiated output power of the transmitter depends on the antenna design and other product physical characteristics. The minimum power should produce a signal strength of 58 mV/meter measured at 3 m. Maximum power cannot exceed the radiated power limits prescribed by the FCC for Part 15 operation. The receiver section amplifies the antenna signal through a bandpass front-end filter. The receiver can use either sideband, or it can switch between sidebands to avoid interference. The received signal is mixed

89


Figure 5.30 Mixing the chip data stream with the local oscillator forms two sidebands that are 10.5 MHz apart and centered at 915 MHz.

2.1 MHz

909.75 MHz LSB

2.1 MHz

915.0 MHz carrier center frequency

920.25 MHz USB

with the 915-MHz local oscillator to directly recover the spreading sequence bitstream. This is amplified, limited, and fed to the RF CELinx IC. The IC performs state detection by correlating the received bit sequence with an internal model of the sequence; if a match occurs, it generates an indication to the DLL of the received symbol. The IC also contains CRC computation logic. As the packet is transmitted, the CRC logic computes a 16-bit CRC. When the EOP is received and transmitted by the chip, the 16 CRC bits are appended to the packet. As a packet is being received, and the end of the Preamble is detected, the CRC logic does the same calculation on the received bits of the information part of the packet. When the EOP is received, the remaining 16 bits are internally stored and compared with the calculated CRC. The results of the comparison are passed to the Data Link layer as a “good packet” or “bad packet” indication.


CHAPTER

6 Protocol


92

Chapter Six The CEBus protocol provides a dependable, two-way, flexible message delivery system for large volumes of traffic on each medium. The CEBus protocol defines the format of the transmitted packets (the order of transmitted fields), the packet delivery “services” (error detection, message priority, retransmission of lost messages, responses to messages, and so on), and the technique for accessing and using the control channel on each medium.

A Little Protocol Background CEBus inherited much of its original protocol design from Homenet. In the early 1980s, a newly formed group at General Electric, led by Jack Francis, developed Homenet—the first communication protocol specifically designed for the home. Homenet was used in GE’s HomeMinder product. It was the first home automation system available to the consumer that provided whole-house automation using low-cost two-way communications on the power line. Over years of review and refinement, many changes were made to the protocol to reflect demands for higher speeds, greater reliability, and security, and much of the Homenet design was lost. However, the Data Link layer still retains many of the original Homenet concepts.

CEBus Protocol Overview In the early 1980s, the International Standards Organization (ISO) adopted a model for open communications systems, which is known as the Open Systems Interconnect (OSI) reference model. This model was intended to be used in the definition of actual protocols. The protocol used by CEBus is described in EIA-600 using the OSI model. The OSI model defines the functions and services available in any communications protocol, and is used as a basis for protocol designs. The operation of most existing communications protocols (Ethernet, TCP/IP, Novell IPX/SPX, AppleTalk, Fishnet, and so on) can be described using the OSI model. Due to its wide use and acceptance, the CEBus Committee also chose this model to describe the CEBus protocol, and the EIA-600 sections on protocol are based on the OSI format and terminology.

93

Protocol

The model has several advantages. It takes all the complexity of communications software and divides the functions into seven predefined “layers.” For this reason, the model is often called the OSI seven-layer model, or the OSI seven-layer protocol stack. A diagram of the stack is shown in Figure 6.1. The model defines the seven protocol functions in a hierarchical way, each layer of the model relying on the “services” of the layers below it. Each layer has a specified set of responsibilities and, ideally, only communicates with the layer above and below. Starting at the Application layer, each layer below provides a more “primitive” protocol service for the layer above. The top layer, the Application layer, corresponds to the application using the protocol. The lowest layer, the Physical layer, corresponds to the lowest-level tasks, usually associated with the hardware necessary to transmit each bit of the data on the connected medium. The model is similar to the way software languages use subroutines. Each layer “calls” the layer below to provide a more primitive function. Each layer is assigned a general set of services: The Physical layer is responsible for reliably transmitting and receiving each bit, or symbol, on the attached medium. All issues ISO Open Systems Interconnection Model APPLICATION PRESENTATION

CEBus Model

APPLICATION TRANSPORT

SESSION TRANSPORT NETWORK

NETWORK

DATA LINK

DATA LINK

PHYSICAL

PHYSICAL

MEDIA

Network Layer Management

Figure 6.1 CEBus protocol model vs. traditional OSI seven-layer model.

94

Chapter Six dealing with mechanical and electrical implementation are determined at this layer, including signal levels, bit transmission timing, bit error detection, and maintaining proper physical and electrical characteristics on the medium. The Data Link layer provides reliable communications between nodes on the same medium. The Data Link layer defines the fundamental unit of data transfer, which is often referred to as a packet or frame. The packet is the concatenation of preamble, addresses, headers, message information, and error-control codes. The Data Link’s primary responsibility is proper access of the media, including collision avoidance and detection. It also performs packet error detection, packet transmission timing, address recognition, duplicate packet rejection, and packet transmission failure detection and retransmission. The Network layer provides reliable communication across multiple media, including networkwide communication functions such as network address management. The Network layer provides routing services to ensure a packet arrives at the correct destination node on the correct medium. The Transport layer provides end-to-end service between source and destination nodes on the network. This is performed by requiring the destination node to acknowledge successful message reception and retransmission of packets that are not acknowledged. The Transport layer also handles large message fragmentation and reassembly, and the creation and maintenance of network connections that are required by the Session layer. The Session layer manages communication sessions or connections. Sessions allow nodes to establish single or bidirectional logical connection until all communication is complete, and then relinquishes the connection. This service is typically used for connected service protocols such as time-sharing service access, telephone systems, and the like. The Presentation layer provides any necessary translation of application data into a form used for packet transmission. It is responsible for converting transmitted and received data to a form usable by the Application layer. The Presentation layer is typically used to convert file formats (graphics, bitmaps, and so on) and handle the conversion of a local format to a remote node format. This layer can also implement data compression/decompression to yield higher throughput on the network.

95

Protocol

The Application layer is the application using the communication services of the lower layers. This may be an operating system, a communication program, telemetry software, and the like. The OSI model is just that—a model—and no one protocol adheres to all services and layers of the model. Specific protocols use a subset—as appropriate to the communication services offered by the network—of the services of each layer. Specific implementations of protocols also take liberties where different services reside and how layers are implemented. The model is used as a guideline for specific implementations.

The ISO vs. CEBus Model Figure 6.1 also shows the CEBus protocol model in relation to the OSI model. CEBus implements a Physical layer, a Data Link layer, a Network layer, and an Application layer. In addition to the protocol functions defined by the OSI model, the CEBus standard also defines the physical characteristics of each of the allowed media. It also implements many of the functions of a Transport layer, but instead of establishing a separate Transport layer, the needed functions are included in the Application layer and the Network layer. CEBus also defines Network layer management functions of each layer and the interaction between layers. Network layer management includes the housekeeping functions required between layers such as power-on states, error resets, and resource management. Because CEBus is a connectionless service protocol, no Session layer functions are used. The Presentation layer is not necessary because there is no requirement for conversion of data to or from a format used by the Application (the Application in CEBus is the CAL language interpreter).

The Peer-to-Peer Layer Model The concept of peer-to-peer node communications (introduced in Chapter 4) is applicable to each protocol layer. Each protocol layer communicates on a peer-to-peer basis with the corresponding layer of the node it is sending to or receiving from. The concept is illustrated in Figure 6.2. The task of the protocol, including the CAL interpreter, is to make the application (the hardware) of the node behave as though it is connected, for a short time, to the hardware in another node. The protocol establishes this “virtual” connection by transporting the hardware function from one node to another. The CAL interpreter converts the

96

Chapter Six connection request into words (CAL commands), which are sent to the other node in the CAL message. The CAL interpreter in the originating node then communicates with the CAL interpreter in the destination node, which converts the words back into an action on the destination hardware. This may result in a reply message from the destination CAL interpreter back to the originating node CAL interpreter. The CAL interpreter in the originating node relies on the services of the rest of the protocol “stack” to reliably deliver the message to the CAL interpreter in the destination node. To deliver the message, the CAL interpreter passes the message to the Application layer for delivery. The Application layer software prepends an Application layer message to the CAL message to form an Application Protocol Data Unit (APDU). The APDU is sent to the Application layer in the destination node. The added APDU information informs the destination Application layer about requested services, such as whether the message is encoded and whether a message acknowledgment is requested. The added bytes are called the APDU Header and are intended for the destination Application layer to determine what Application layer services are requested. The Application layer, in turn, passes the APDU to the Network layer for transmission. The Network layer software prepends a Network layer message to the APDU to form the Network Protocol Data Unit (NPDU). The NPDU is sent to the Network layer in the destination node. The prepended information is called the NPDU Header and is used by the destination Network layer to determine what network wide services are requested. For example, the APDU may be too large to send in one packet (a single APDU is limited to 31 bytes). The Network layer can segment the APDU into two or more messages and inform the destination Network layer, in the NPDU Header, how many segments are being sent. The destination Network layer reassembles the segments prior to passing

Figure 6.2 Each layer of the protocol communicates directly with the same layer in the destination node.

application CAL APPLICATION NETWORK DATA LINK PHYSICAL

FUNCTION

application

CAL message

CAL

APDU NPDU DLPDU

message

APPLICATION

APDU

NETWORK

NPDU

DATA LINK

DLPDU

PACKET

PHYSICAL

97

Protocol

the APDU to the Application layer. The NPDU Header information is also used by network Routers and Brouters to determine how the packet is to be routed through the network. The Network layer, in turn, passes the NPDU to the Data Link layer for transmission. The Data Link layer software prepends a Data Link layer message to the NPDU to form the Data Link Protocol Data Unit (DLPDU). The DLPDU is sent to the Data Link layer (DLL) in the destination node. The prepended information is called the DLPDU Header. The DLPDU Header contains the destination node network address and the originating node address, as well as a request for one of several possible acknowledgments from the destination node. The destination node DLL determines whether the destination address matches its own address and returns any requested acknowledgment to the originating DLL to indicate the packet was successfully received. The Data Link layer must gain access to the time-shared medium using a CSMA/CDCR protocol (Carrier Sense, Multiple Access/with Collision Detection and Collision Resolution). Once access is obtained, the DLL passes the assembled DLPDU to the Physical layer serially, a symbol at a time, for transmission on the medium. The Physical layer converts the symbols to either a SUPERIOR or INFERIOR state for reception by the destination node Physical layer.

Transmission Failures The CAL message transmission from the originating node to the destination node may fail anywhere along the path from the originating CAL interpreter to the destination CAL interpreter. If a failure occurs in the originating node “down” the path from the application to transmission by the Physical layer, the requesting layers are informed of the error by the lower layer where the failure occurred. For example, if the Data Link layer was unable to transmit the message (if it was unable to gain control channel access after a certain period of time), it will inform the layer that requested the transmission (the Network layer). That layer will, in turn, inform the layer above, up to the application. Each layer may attempt to retry, or if the retry fails, give up. Eventually, the application must decide how to handle the error (try again, inform the user, or give up). If the failure occurs in the destination node, each destination layer is responsible for communicating back to the corresponding originating layer that it is unable to handle the message. For example, if the originating node

98

Chapter Six Application layer requested secure services from the destination node (by indicating that the originating CAL message is encrypted), and the destination node is not able to handle secure messages—encrypting is an optional service—then the destination node Application layer must send an APDU Header back to the originating Application layer. The returned message (an APDU reject message) will indicate that the message was rejected because the destination node could not handle secure messages. The returned packet contains only an APDU Header, no CAL message. The originating Application layer may then inform the device application that message transmission failed at the destination node.

Application Layer vs. the Application The distinction between references to the CEBus product application and the protocol Application layer can be confusing. Practically, the CEBus node application, as far as the protocol is concerned, is the CAL interpreter. It is the originator and receiver of messages. Formally, however, the CAL interpreter is considered an element of the protocol Application layer. The node application is the hardware and software that performs the application of the node, such as turning on or off a light or operating a television set. Formally, the device application is the user. The device application (user) calls on the services of the protocol, via the CAL interpreter, to connect to the application in another node. While most messages originate as the result of an application changing a context data structure (resulting in the CAL interpreter generating a message), the application can also generate a message directly and request message delivery from the Application layer (this is why the Application layer, in Figure 6.2, “touches” the device application).

Packet Format The CEBus packet structure (Figure 6.3) reflects the contribution of each protocol layer to the packet. The DLPDU, NPDU, and APDU are built by the Data Link layer, Network layer, and Application layer respectively. The remaining non-PDU parts of the packet are the Preamble and the Frame Check Sequence (FCS). The Preamble is a random 8-bit value prepended to the start of the packet by the Data Link layer. The Preamble is used during the medium access protocol to detect and resolve collisions between transmitting nodes. The FCS is a packet-level error-detection field appended by the Data Link layer (an 8-bit checksum) or the

99

Protocol

Physical layer (a 16-bit CRC) depending on the medium used by the node.1 Packets vary in size from about 50 bits (the smallest packet) to about 350 bits (the largest packet) depending on the size of the CAL message and the content of the PDU headers.

Layer Responsibilities The rest of this chapter describes the functions and services of each protocol layer. It is important for anyone using CEBus—whether you write protocol software, buy it, or use an IC containing it—to be familiar with the services that the protocol provides. This is because the services must be requested by the device application; they are not determined automatically. When sending a message to another node, the application is responsible for knowing where the message goes (the destination address of the receiving node or nodes), as well as how to get it there (the protocol services necessary for successful transmission). The following protocol layer sections explain the services provided by the layer well enough for you to know where and when to use the services of that layer.

Application Layer The CEBus Application layer is responsible for the interface with the node application. Figure 6.4 illustrates the Application layer in more

Figure 6.3 Representation of the packet format. Each portion of the packet is contributed by one of the three layers of the protocol. 1

An 8-bit checksum is used on TP, IR, and CX. A 16-bit CRC is used on RF and PL. FCS formation is covered in the Data Link Layer Section and the Physical Layer Section.

100

Chapter Six detail. The Application layer is made from two subparts: The CAL Interpreter Element and the Message Transfer Element. The CAL Interpreter receives messages, parses them, and updates the Context data structure accordingly. It also generates a message for transmission if a reporting condition in the Context data structure requires it. The Message Transfer Element (MT Element, or MTE) builds the APDU. It receives message transfer requests from either the CAL Interpreter or directly from the application, builds the APDU, and passes it to the Network layer. It receives APDUs from the Network layer, parses the APDU Header, and passes the message to either the CAL Interpreter or directly to the application, depending on the type of message. The specific responsibility of each application element is shown in Tables 6.1 and 6.2. The CAL Interpreter element tasks are given in Table 6.1. This table indicates the tasks performed when receiving or sending a message. The Message Transfer Element tasks are given in Table 6.2. The table indicates the tasks performed when receiving or sending an APDU. The MT Element receives requests to transmit messages from either the CAL Interpreter or directly from the application along with the Application and lower protocol layer service requests. It builds the APDU and passes it down to the Network layer along with service requests for the Network and other protocol layers. Upon APDU reception, the MT Element parses the APDU Header from the message, performs the service requested in the header, and passes the message to

Figure 6.4 Application layer structure. The Application layer contains the CAL Interpreter and the Message Transfer Element.

101

Protocol TABLE 6.1

ELEMENT

Sending Task

Receiving Task

CAL

Monitor reporting IVs

Parse messages

Generate report messages

Update context data structure

Generate response messages

Handle error conditions

CAL Element tasks

Generate error messages

Table 6.2 Message Transfer Element tasks.

ELEMENT

Sending Task

Receiving Task

MT

Build APDU

Parse APDU

Handle authentication response

Handle authentication requests

Handle acknowledged service timing

Handle acknowledged service requests

Handle APDU retransmission

either the CAL Interpreter or to the application depending on the type of message received, and which element originated the message in the sending node. The MT Element is responsible for two primary protocol services offered by CEBus: end-to-end acknowledged service and authentication.

The APDU Header The APDU Header is built by the originating MTE for use by the destination MTE. There are two forms of the header: A 1-byte Basic Service header used for nonsecure service requests, and a multibyte Extended Service header used for security authentication services. The format of the Basic Service header is shown in Figure 6.5. The format of the Extended Service header is shown in Figure 6.6.

Basic Service APDU The content of the 1-byte Basic Service APDU Header is illustrated in Figure 6.5. This is the most common form of the APDU and is used for all nonsecure messages.

102

Chapter Six

Figure 6.5 Basic Service APDU header. The first two bits (27, 26) are always set to 1 for this service. The remaining contents of the byte infer the type of message.

Figure 6.6 Extended Service adds authentication to the basic APDU services. The first two bits in the first byte are always 1,0. The authentication algorithm used determines the contents and number of the optional authentication data fields surrounding the CAL message.

The basic APDU consists of a 1-byte header followed by a 0- to 30-byte message. The header determines the Application layer services. The Mode bit (MSB) is always a 1. It indicates the message service is CEBus. This bit may be used in the future to indicate transport of other, non-CEBus information.

103

Protocol

The Type bit is 1 for 1-byte Basic Service APDU (0 for variable length Extended Service). The APDU type is a 3-bit field indicating the type of service requested of the originating and destination MT Elements. The services are explained in detail in the section on Basic MT Delivery Services. The 3-bit invoke_ID field is used with the APDU type bits as a message number tag to allow MT Elements to track outstanding “invoke” requests to other nodes. The invoke_ID is assigned by the originating MTE. Any response from a destination node contains the same ID that was used in the original request.

Extended Service APDU The content of the multibyte Extended Service variable length APDU Header is illustrated in Figure 6.6. Extended Service APDUs are only used for secure message transfer using a message authentication process with optional encryption. The first two bytes of the header are always present. The remaining bytes (3−n) contain the CAL message and a variable number of authentication data bytes, depending on the authentication algorithm used. The Mode and Type bits are used the same as in the Basic Service APDU. The Type bit is set to 0 to indicate Extended Service. The ENCryption bit is used to indicate that the included CAL message is encrypted. The APDU type is a 5-bit field indicating the type of authentication service requested of the originating and destination MT Elements. The services are the same as the Basic Service APDU with the addition of the first two types listed (Challenge_request and Authenticate_response). The second byte of the Header contains a 5-bit Authentication Algorithm ID field. This field indicates the type of authentication used by the originating node and allows implementation of 32 different algorithms. The invoke_ID field is the same 3-bit field used in the Basic Service APDU. The remaining variable number of bytes in the header are used for the CAL message and the message authentication data. The number and

104

Chapter Six location of bytes used for authentication data depends on the Authentication Algorithm used as indicated by the Algorithm ID. The use of Extended Service APDU and an explanation of authentication is given in the Security Section of this chapter. Basic MT Delivery Services The MT Element offers several delivery services to the CAL Interpreter or application. The services ensure reliable message delivery by requiring that the receiving node (or nodes) generates a response message to the sending node. The response serves two purposes. First, it indicates that the destination node received the message successfully, and second, it provides a mechanism to return result data back to the originating node. For example, if a message is sent to a thermostat asking for the current heating setting, the value of the heating setting is returned to the sender in the response message. There are four basic MTE services: implicit_invoke, explicit_invoke, conditional_invoke, and explicit_retry. The MTE Extended Services combine these with message authentication. Implicit_invoke is a simple one-way service—a message is transmitted but no response is requested. This service is typically used when a message is broadcast to a large number of nodes using the broadcast system address or a group address when a replay is not needed from the receiving nodes. Explicit_invoke, conditional_invoke, and explicit_retry services are variations on the same service; however, a response from the destination node is requested. Explicit_invoke service requires an end-to-end acknowledgment from the destination MTE. This service is used to ensure that the destination node receives the message and the result of the message is returned. End-to-end means that the service operates over the entire network regardless of the media connection of the communicating nodes. A result will always be returned even if the result is just an indication that the message was executed. This service is also used when a value is read from the destination node. Conditional_invoke service requests a response if, and only if, the transmitted message produces a positive result in the destination CAL interpreter. Conditional_invoke is typically used to find which of many nodes meet a certain criterion.

105

Protocol

Explicit_retry is the same as explicit_invoke with the addition of an automatic retry service performed in the MTE. When a reply to the APDU is not received within a fixed time interval (typically 1.5 seconds), the MTE retransmits the APDU a second time. NOTE: The use of explicit_retry service is optional and is not recommended because a receiving node may not support this service in its MTE. This service is easily implemented in the application code that originates the message. If a reply is not returned, the application simply retries the message. The remaining APDU types are returned as a result of using the above services. Result is the APDU type of a returned message containing a result generated by an Explicit or Conditional request. Reject is the APDU type returned when the MTE in the destination node encounters an error condition and cannot process the message. Receipt_Ack is the APDU type returned when using explicit_invoke service and the destination node is delayed in responding.

Basic Service Details The following sections describe the operation of explicit_invoke, conditional_invoke, and explicit_retry service in enough detail for you to understand the basic operation of each service and when it is used.

Explicit_invoke Service Explicit_invoke service is used anytime a message is sent to one or a small group of nodes and a response is desired from the destination node(s). The response indicates that the message was received and acted on. This service provides a high degree of message delivery reliability and is used whenever possible. This service must be used when a value is read from the destination node and a returned result is required. The returned message will have a Result APDU type with the same invoke_ID as the original explicit_invoke APDU, and a result code (along with any returned value) in the message portion of the APDU. The possible returned results are:

106

Chapter Six A result complete code (the message was executed by the destination CAL) A result complete code followed by the result value An error code followed by an error number The result message format and error message codes are discussed in detail in Chapter 7. Figure 6.7 illustrates the action of the MTE in the sending and receiving node, as well as the packets generated during an explicit_invoke service request. The figure indicates the cause-and-effect actions that take place in each layer for each step of the message transfer. Time is indicated vertically (that is, time passes from the top to the bottom of the figure). The transmitting node MTE receives a request to send a message2 and builds an APDU indicating explicit_invoke service with a new invoke_ID. The APDU is then sent (via the Network layer) and the MTE starts a 1.5second MT Response Timer.3 This timer sets the maximum time that the MTE will wait for a response from the destination node before giving up or trying again.

Figure 6.7 Sequence of events for explicit_invoke message request from the receiving node. 2

The MT Element can receive a request for message transmission from either the CAL Interpreter or the device application. However, because requests for explicit_invoke service invariably originate from the application, the application is always shown as the originator of the message in the examples. 3

The minimum recommended time for a reply is 1.5 seconds. This timer can be adjusted based on knowledge of the anticipated packet transmission time. Packets that are routed via Brouters, or that use segmented service, will require longer roundtrip acknowledge times.

107

Protocol

At the destination MTE, the message is received from the Network layer. The APDU is parsed, and the message portion is passed to CAL. If explicit_invoke service is requested, the MTE starts a 100 ms MT Wait Timer. This timer sets the maximum time that the MTE will wait for a result from the CAL interpreter. Assuming CAL returns a result before the MT Wait Timer expires, the MTE builds a Result APDU (using the received ID) with the CAL result, and transmits the APDU via the Network layer. The originating MTE receives and parses the APDU, matches the Result APDU with an outstanding message request ID, and passes the result back to the application. There are several variations of explicit_invoke service that should be understood. The second example, illustrated in Figure 6.8, shows what happens if the destination node result packet is lost (or the transmitted packet never arrived at the receiving node). If a result APDU is not received within 1.5 seconds, the originating nodes MT Response Timer expires and the MTE notifies the application of the failure. It is up to the application to decide what action to take as a result of the failure. Typically, the message is resent. The third example, illustrated in Figure 6.9, shows what happens if the CAL interpreter at the destination takes too long to return a result to the MTE. If generating a result takes longer than 100 ms, the MT Wait Timer expires and the MTE sends a receipt_ack APDU back to the originating

Figure 6.8 Sequence of events when explicit_invoke result packet is lost in transmission.

108

Chapter Six node MTE. The receipt_ack service is intended to notify the originating node that the original APDU was received but a result has been delayed. This APDU says, in effect, “we’ll get back to you.” This prevents the originating node from initiating a retry prematurely. In practice, the MT Wait timer is usually not necessary. It is unlikely a message will require more than 100 ms processing time on the part of the CAL interpreter because messages read or write to variables that are part of the context data structure. This data should always be immediately available. There may be cases, in particular implementations, in which the processor time available to the CAL interpreter is interrupted for more than 100 ms by an application task. The originating MTE, upon reception of the receipt_ack APDU, stops its MT Response Timer and notifies the application. The application can then choose to continue to wait for the result, or continue without the result. When the result is finally received, the originating MTE passes the result to the application.

Figure 6.9 MTE sequence of events for sending a receipt _ack packet when the receiving node CAL element cannot respond within 100 ms.

109

Protocol

Conditional_Invoke Service Conditional_invoke service is identical to explicit_invoke service except for the criteria used by the receiving CAL interpreter to generate a result, and the lack of a receipt_ack from the destination node MTE. Conditional_invoke service requests a response from the destination node(s), if and only if, the transmitted message produces a positive result by the destination CAL interpreter. A positive result means that the CAL interpreter generates a result value based on the received message or performs a requested operation successfully. Any error condition or failure to perform a requested CAL method does not generate a response. Because the destination node MTE does not send a receipt_ack APDU, a response APDU is only sent if a result is generated by CAL. Conditional_invoke service is intended to minimize result traffic, and result processing. It is typically used when the destination address is other than a single node address; that is, where more than one node is used as the destination. This usually occurs when the destination address is a group address or the broadcast address. Conditional_invoke can be used to find out which of many devices on the network meet a certain criteria. For example, a node might transmit a message that says, “If your product class is TV then return your node address.” This enables the node to find the network address of all TVs in the house. If explicit_invoke service is used, all nodes on the network will respond, whether they are a TV or not,4 causing a large number of responses, tying up the network, and requiring the originating node to filter out the undesired results. If conditional_invoke service is used, only the nodes that are TVs will respond. Explicit_Retry Service Explicit_retry service is described in the EIA600 document. It allows the MT Element to contain an automatic retry mechanism (similar to the Data Link layer) to resend a message if an explicit_invoke response is not received and the MT Response timer expires. This MTE service is described in this section but the author recommends that the service be implemented in the application. If a response is not received, simply generate a new MT message delivery request. Because reception and processing of an explicit_retry APDU are optional, it is best to avoid using the service because it may generate a reject response from the receiving node.

4

Nodes that are not a TV will respond with a “false evaluation” result.

110

Chapter Six Explicit_retry is the same as explicit_invoke, but with the addition of an automatic retry service performed in the source MTE. When a result message is not received from the destination node within the time interval of the MT Retry Timer, the MTE retransmits the APDU a second time. The usefulness of the service is illustrated in Figure 6.10. If the original APDU is lost, the MT Response timer expires and the MTE resends the APDU. The remaining operations are the same as for explicit_invoke service. The example in Figure 6.11 is almost the same, except that the cause of the retransmission is the loss of the original Result APDU from the destination node. This causes the original APDU to be resent. The destination node, upon receiving the second explicit_retry message with the same invoke_ID, discards the message (does not pass it to CAL), but resends the Result APDU.

Synchronous Service and the Invoke_IDs The CEBus Application layer operates synchronously with other nodes. This means that a node can only have one outstanding message to the

Figure 6.10

Example MTE sequence of events when an explicit_retry service is used.

111

Protocol

Figure 6.11 Example MTE sequence of events when a Result packet is lost during explicit_retry service.

same node at a time. Before sending another message, the receiving node must have processed the previous message and returned a result (if using explicit_invoke service). However, a node can have several messages outstanding to different nodes. The sending node must keep track of which returned result is associated with which transmitted message. This is where the invoke_ID is used. The invoke_ID field in the APDU Header allows MT Elements to track outstanding invoke operations. The invoke_ID is a 3-bit number (0−7) assigned sequentially to each new explicit/conditional_invoke message sent by the MTE (wrapping around from 7 to 0).5 The destination MTE handling the invoking operation returns the same invoke_ID in any Result, Reject, or receipt_ack APDU. This process allows an invoking MTE to associate incoming responses with a particular invoke. An originating MTE may not use an invoke_ID that is still pending a response from a remote MTE. An MTE that receives a duplicate invoke_ID from the same source address MTE must reject the duplicate invoke. This 5

The invoke_ID for an implicit_invoke service is always set to 7 (111).

112

Chapter Six implies that the MT Element must remember an association between the source address of an explicit-type APDU and the invoke_ID long enough to recognize a duplicate message. The duplicate might be caused by a lost Result APDU. In fact, an association must be kept (in an association table) for each outstanding message sent to a different node address, and for each received request for an explicit service. The received message association must be kept to reject a duplicate request from the same node. The association time should be kept for a reasonable network delay time after a response is returned or a duplicate response is returned (nominally 12 seconds). The transmitted message association must be kept until a result message is returned successfully or until a sufficient amount of time has passed for a response to have been received (network round trip delay plus receiver response time). This time should be longer than the receiver association timer (nominally 20 seconds). This will prevent the transmitter from reusing the same ID to the same node prior to the association being discarded in the receiver.

Reject APDUs A Reject APDU is generated by a destination node MT Element anytime the MTE is unable to process the received APDU. The resultant Reject APDU contains a 1-byte code (in the CAL message position) to indicate the reason for the reject in the returned message. The codes are as follows: APDU type is not supported:

30 Hex

Extended Service APDU types not supported:

31 Hex

The Application layer is busy:

32 Hex

Authentication failed:

33 Hex

The third reject code, Application layer busy, is typically the result of the MTE or CAL Interpreter processing a previous APDU.

When to Use What Service Which Application layer service to use must be determined when a message is sent to the MT Element for transmission. This means that when the application or the CAL Interpreter generates a message, it must furnish, along with the message, all the information necessary to transmit

113

Protocol

the message. This includes the Application layer service, the Network layer service, and the Data Link layer service requests, as well as the destination address of the message. This information exchange between the application and Message Transfer, and between the CAL Interpreter and Message Transfer is shown in Figures 6.12 and 6.13 using C-like function calls. An implementer is free, however, to “hide” the selection of layer services in the protocol layer code by making service selections based on the type of message or destination address. In Figure 6.12, the application is free to generate any type of message using any type of Application layer service. The application must know the destination address as well as the service necessary from each protocol layer. Generally, the application is the only element that originates a message that generates a result (such as requesting the current temperature, or the status of the security system) using explicit_invoke or conditional_invoke service. The reply, from each node addressed, is returned from Message Transfer along with the source address (shown in the rec_reply call). The source address is necessary because it is not always the original destination address of the message that generates the response. The message may have been sent to the broadcast address (for example, to get the node address of all TVs) and generated several replies.6 The CAL Interpreter is more limited. CAL can receive a message to read or write a value to its Context data structure (Figure 6.13). The operations can be conditional based on other values in the Context data structure. CAL can also generate a message (called a reporting message) based on a condition in an object. For example, it can send a Figure 6.12 Interface from the application code to MT code (*message is a pointer to the message to send, *reply is a pointer to the received message).

6

This is one technique for acquiring destination addresses on the network.

114

Chapter Six message any time a light switch changes from on to off, or off to on. The value change will generate a message to set a value in another node, so it will know the state of the light. The message generated by the interpreter does not generate a reply or return any result (excluding any explicit_invoke acknowledgment). When CAL generates a Reporting message, it must know the destination address as well as the service necessary from each protocol layer. The destination address is either obtained from the received message (requesting a result) or is stored in the object that generates a reporting message. The protocol services used are determined from a set of rules built into the interpreter. The rules for using the Application layer basic services by the application and the CAL Interpreter are given in Table 6.3. When an application uses conditional_invoke service, it must be prepared to process Result messages from several nodes.

Application Layer Extended Services The Application layer Extended Services provide message security. Message security means that an unauthorized node (person, hacker, and the

Figure 6.13 Interface from the CAL interpreter to MT.

115

Protocol Table 6.3 Rules for deciding which Application layer service to use for message delivery.

Service

Application

CAL

Implicit_invoke

Use when a response is not desired, or when transmitting to a group or broadcast address.

Use for message reporting when transmitting to a group or broadcast address.

Explicit_invoke

Always use when transmitting to a node address.

Use for message reporting when transmitting to a node address. Used for message delivery confirmation only.

Conditional_invoke

Use when conditionally reading a value from a group address.

Not used.

like) cannot read a message, decode it, and then possibly resend it to duplicate its results. It is intended to prevent unauthorized operation of CEBus devices or unauthorized reading or writing of data in CEBus devices. Message security cannot prevent a person or a device from “jamming” the network to prevent a message from being sent or received. It is difficult to prevent electrical access to the network, but relatively easy to prevent message traffic from being decoded.

Authentication Authentication is an umbrella term for two types of CEBus message security: message sender authentication and message encryption. Either or both services may be used for any message. Authentication provides a means for a destination device to verify the authenticity of a message originating device. This capability allows the node manufacturer to prevent selected data in the node from being written (or even read) by an unauthorized node. For example, CEBuscompliant electric meters contain the current electric rate and accumulated electricity usage for the house. This information can be read by a node in the house, but cannot be changed without knowing the authentication access keys to change the data. This information can be read and written by the electric utility because it possesses the current keys for access.

116

Chapter Six

Authentication Algorithms All secure service code is contained in the MT Element. There are two general forms of authentication algorithms allowed by MTE Extended Service: a one-way authentication algorithm, and a two-way algorithm. The one-way algorithm transmits all necessary information in the APDU for the receiving node to verify the transmitter. The two-way algorithm requires a message handshake between nodes. The goal of either algorithm is to make it impossible for someone (by reading network traffic) to determine how to duplicate the traffic or decode the algorithm and send messages to read or alter secure node data. Both algorithms ensure that the message contains enough randomness that decoding the data is extremely difficult. Two-Way Authentication Algorithm The two-way authentication algorithm requires that two Authentication Keys (S1 and S2) be maintained in each node that uses the algorithm. The keys are stored in the Node Control Object of the Universal Context. S1 and S2 must be known by the node issuing a secure command and the node executing the command. Both nodes must also know the same encoding algorithm, E. E is a predefined encoding function that accepts a key and a random number and then produces a value. When a destination node CAL Interpreter receives a command and the command requires authentication, CAL instructs the MTE to issue a challenge_request APDU. The MTE generates a random number R, and then calculates X E(S1, R), encoding R with key S1. It then sends the challenge_request APDU with X in the Authentication Data field (starting at byte 3) of the APDU (see Figure 6.6). When the originating node MTE receives the challenge_request APDU, it first calculates A E1(S1, X) and then B E(S2, A) and then sends B in the Authentication Data field of the authenticate_response APDU. When the destination node receives the authenticate_response APDU, it calculates R′ E1(S2, B). If R′ equals the original R, then MTE informs CAL and the original command is executed; otherwise, an authenticate_reject APDU is returned with a reject code of 33 Hex (authentication failed). Obviously, both nodes must know both S1 and S2, and the encoding algorithm E. How the nodes acquire S1, S2, and E is up to the manufacturer. One-Way Authentication The one-way authentication algorithm allows authentication data to be passed in the original command request. This service only requires one key, S1, and the encoding algo-

117

Protocol

rithm E, but both nodes must know the same random number R. R must be a random value that changes with time (for example, the time of day). When an originating node knows that a command requires authentication, the application or CAL requests one of the authenticate services from the MTE. The MTE calculates X E(S1,R) and transmits the authenticate service APDU with X in the authenticate data field followed by the CAL message. The destination node MTE calculates A E1(S1,X). If A equals the destination node’s present value of R, the command contained in the message field is passed to CAL for execution. Otherwise, an authenticate_reject APDU is returned with a reject code of 33 Hex (authentication failed). Both nodes must know S1, the encoding algorithm E, and how to calculate a value for R that is the same in each node over a short period of time. Existing techniques for this algorithm use a number R generated from the value of the current time. Because the time in both nodes should be equal over a short period, both nodes can calculate the same value of R.

Encryption Message encryption can be used either with or without authentication. Encryption means that the bits in the message (and any authentication data sent in the APDU) are scrambled using a technique known to both the transmitter and receiver so the receiver can unscramble the bits. Encryption provides an additional layer of security for sensitive messages. If encryption is desired for a message, extended services must be used and the ENC bit in byte 1 of the Extended Service Header byte must be set. The encryption algorithm is specified using the Authentication Algorithm ID field in the second byte. The field may specify an authentication algorithm, an encryption technique, or both.

Using Secure Services Application layer Extended Services are optional and add a significant software burden on the node. They should be used only when message security is an absolute requirement and it is known that the destination node employs it. Message security is used whenever messages or context data contain potentially sensitive data to the homeowner or a utility, such as financial information or the status of a security system.

118

Chapter Six It is easy to get paranoid, especially in today’s scary society, about the security of mundane messages and network information, such as the state of light switches. Fears of hacking a house are exaggerated. It is possible, but the risk is small because the reward-to-effort ratio is large (little reward, high effort). It is one thing to hack an electric meter to steal electricity, and another to turn on someone’s bedroom lights as a prank. The latter can be done with existing technology—houses using X-10 can be easily hacked to turn on or off lights and appliances, and security systems can be easily jammed or defeated. But it just doesn’t happen. It is either too much trouble for limited results (in the case of hacking X-10) or unnecessary (in the case of defeating security systems).

Network Layer The Network layer is responsible for networkwide services across any media used in the home. The Network layer in each node communicates with the Network layer in other nodes, as well as with the Network layer in Routers and Brouters. The CEBus Network layer (NL) interfaces with the Message Transfer Element of the Application layer, and the Data Link layer. The Network layer receives requests for message transmission from the Application layer and notification of received messages from the Data Link layer. The Network layer responsibilities for message transmission and reception are given in Table 6.4. The MT Element makes requests to the NL for APDU transmission using selected NL services. The Network layer then builds the appropriate NPDU Header and forms an NPDU for transmission. The Network layer passes the NPDU to the Data Link layer with a request for required DLL services. Table 6.4

ELEMENT

Sending Task

Receiving Task

Network layer responsibilities

Network

Build NPDU

Parse NPDU

ID Packet Generation

Detect ID packet requests

Optional segmented service

Optional segmented service

Optional flow control

Optional flow control IR/RF duplicate packet rejection

119

Protocol

When an NPDU is received from the Data Link layer, the NPDU Header is parsed and the requested Network layer services are performed (if possible). The APDU is then passed to the MT Element.

The NPDU Header The NPDU Header is built by the originating NL to communicate with the destination NL. It is 1 to 8 (or more) bytes long and reflects the desired NL services requested by the originating Network layer. Figure 6.14 illustrates the NL Header structure. The figure shows, on the left side, the order of each possible byte in the header. Where appropriate, the content of most of the bytes is expanded on the right. This figure is referenced throughout the discussion of the Network layer. The NL Header size depends on the services requested. The first byte shown in Figure 6.14 is the NL Service byte and is the only required byte in the header. It indicates, primarily, the services requested of Routers or Brouters to get the packet to its destination. All remaining bytes are optional and exist only if a corresponding flag bit is set in the NL Service byte. NL Service Byte This section describes the structure and function of each bit field of the NL Service byte. The most significant bit (MSB) of the NL Service byte is reserved for some unspecified “privileged” service. It is always zero. The Routing bits indicate the type of Router and Brouter service requested. Flood Routing (1,1) instructs Routers to route the packet to every allowed medium in the network.7 Directory Routing (1,0) instructs Routers to forward the packet onto only the branches of the network in a direct path to the destination node. Routers keep track, using address tables, of which network addresses are on which side of their two media. If the destination address of a received packet is known to be on the other side (other branch) of the network and Directory Routing is requested, the Router will forward the packet. 7

When an application requests Flood Routing of a packet, all Routers on the network will receive and forward the packet. For this reason, Data Link layer-acknowledged services (described in the DLL section) cannot be used because it requires an acknowledgment from each receiving node, including Routers.

120

Chapter Six

Figure 6.14 Format of the NPDU header. There are one to eight (or more) possible bytes in the header. The bit function of each service byte is shown on the right.

ID Packet (0,1) and Request ID (0,0) are used for NL ID packet operations and are explained in the ID Packet section that follows later in this Network layer discussion. The FP and Ext bits are used for extended services requested of the destination node and are explained in the Network layer Extended Service section. The AM bit indicates Allowed Media. When this bit is a zero (cleared), Routers and Brouters are free to route the packet on all media. When this bit is set, an additional Allowed Media byte follows the NL Service byte (after any Brouter address bytes) to indicate which media are allowed for packet forwarding. This byte has a bitmapped correspondence to each CEBus medium type. Each bit in the byte controls packet forwarding onto the medium for that bit position. A 1 bit enables forwarding; a 0 bit blocks forwarding. These bits take precedence over all other routing decisions. The bit positions correspond to the following media:

121

Protocol Position Medium 20

Power Line

2

1

Twisted-Pair

2

2

Coaxial Cable

2

3

Fiber-Optic Cable

2

4

A/V Bus (medium used by AV equipment)

2

5

RF

2

6

Infrared

The Allowed Media (AM) byte has limited usefulness. If used incorrectly, it will prevent message delivery. It can only be used when a message-originating node knows what medium the receiving node is on and wants to reduce unnecessary network traffic (possibly when using Flood routing). If a message uses Directory Routing, the AM byte is unnecessary. The B2 and B1 bits indicate included Brouter addresses. If either bit is set, a 2-byte Brouter address will follow the NL Service byte (as shown in Figure 6.14). If both bits are set, 4 bytes of Brouter address will follow: the first Brouter address (2 bytes) followed by the second Brouter address (2 bytes). Brouter Addresses and Routing A Brouter is a device that forwards between either IR or RF and any other wired media. The NPDU Header Brouter address fields allow a packet to originate, for example, at an IR device, be picked up by the Brouter in the same room as the originating IR device, be forwarded onto a power line to another Brouter in another room, and retransmitted to an IR device in that room (an ambitious packet). The first Brouter address (B1) is the node address of the Brouter that will forward the packet onto the wired media. The second Brouter address (B2) is used when an IR or RF device transmits a packet that must be forwarded onto a wired media and then forwarded again to either an RF or IR destination. The second Brouter address determines which Brouter will forward from wire back to IR or RF. The Duplicate IR/RF Packet Problem If there is more than one Brouter in a room where an IR device transmits a packet, all Brouters within the line of sight will pick up the packet and attempt to forward it to its destination. This will result in duplicate packets arriving at the destination node. There are two techniques available to IR or RF devices to prevent duplicate packets. The first technique relies on knowing the node address of one Brouter in the room where the transmitting device

122

Chapter Six is being used. If the address of a Brouter able to receive the packet is known, its address may be included in the transmitted packet in the B1 address field of the NPDU Header. This will ensure that the packet is only forwarded by one Brouter. The second technique is used if the address is not known, and requires that the transmitter uniquely identify each packet to the receiver. This is done by assigning a sequential packet number to the packet, and relying on the IR/RF duplicate packet rejection capability of the destination nodes Network layer. The duplicate packet rejection capability is one part of the optional Network layer Extended Services described in the next section. Because this service is optional, it cannot be relied on for duplicate rejection. In practice, there should only be one RF Brouter in a house or apartment because an RF Brouter should be capable of transceiving packets to any RF device in the house. This should reduce the risk of RF duplicate packets. Because IR devices are line-of-sight, there needs to be at least one RF Brouter in each room or space in which an IR device is expected to be used. There may, however, be more than one Brouter in a room because AV devices (TVs, VCRs, and the like) may have an IR Brouter built in. Knowing the Brouter address is an advantage.

Network Layer Extended Services Network layer Extended Services are optional NL services requested of the destination node. Extended Services are only used to handle CAL messages (and APDUs) that are too large to send in one packet, and to handle Brouter duplicate-packet rejection. The Extended Services are the most complex part of the protocol. You can skip this section if you are not interested in segmented service or duplicate-packet rejection. The Need for Segmented Service The total size of an NPDU is limited to 32 bytes. This size limit allows products to implement small, fixed-size buffers at the Data Link layer. This size includes all the CAL message, the APDU Header bytes, and the NPDU Header bytes. Because CAL messages are usually short—8 to 10 bytes—and most Application layer and Network layer services require only one header byte, the 32byte limit is usually not a problem. There are times, however, when large messages are required. This usually occurs when a CAL message is used to read a large data value or when a large text string needs to be sent and the message plus header bytes exceed 32 bytes. In this case, the node has

Protocol

123 two choices to overcome the NPDU size limit. The application can read or send the data in smaller chunks, or the message can be segmented using Network layer segmented service. Segmented service takes a large APDU and breaks it up into smaller packets (called segments) for reassemble in the destination node’s Network layer. Segmented service is an optional Network layer service, and if implemented, comes with or without a flow control service. Flow control adds additional reliability to segmented service by allowing Network layers to periodically keep track of segment transmission progress. It is typically used when the APDU is large (more than 100 bytes) and requires transmission of many segments (more than 6 to 8). Specifying Extended Service Extended Service is indicated by setting the Ext bit in the NPDU Service byte. Setting the Ext bit to 1 means that the NPDU will contain at least two additional extended service bytes: the Extended Service byte and one or more Packet Number bytes (see Figure 6.15). The FP (First Packet) bit is used with the Ext bit to indicate the first segment of a multisegment packet. It is set to 1 to indicate that the NPDU contains the first segment. It is clear (0) for any subsequent segments. This bit is set to one when extended service is not used. Extended Service Byte Description When the Ext bit is set in the NPDU Service byte, an Extended Service byte will follow any Brouter address bytes and Allowed Media byte. The format of the Extended Service byte is shown below for reference.

Figure 6.15 Portion of NPDU header. When extended service is used (Ext 1), the Extended Service byte, along with one or more Packet Number bytes, will be included in the header.

124

Chapter Six

The high order 4 bits (27−24) indicate the type of extended service used and the associated reply types. 1100 Seg_service

Segmented Service. This NL Service type supports segmented service with or without flow control.

0110 Num_Packet

Numbered Packet Service. This NL Service type is used by IR and RF devices to transmit or forward singlepacket messages without including a specific address for the forwarding Brouter. This NPDU type permits the identification and rejection of duplicate packets that result from forwarding by multiple Brouters.

1011 Pos_ack 1010 Neg_ack

Positive and Negative responses from a destination node, used with flow control to indicate either positive reception of a window of packets, or a negative reception (error). Used with flow control only.

1001 No_serv_support

No Service Support. Used as a reply to a segmented service request from a destination that does not support segmented service (because it is optional).

0100 Seg_service_busy

Segmented Service Busy. Used as a reply to a segmented service request to indicate that the destination node is either already in the process of receiving a segmented message and it cannot handle another one, or that its message buffer is full. This indicates a temporary condition, and transmission of the segmented message may be attempted later.

0010 Error_msg_len

Message Length Error. Used as a reply to a segmented service request to indicate that the destination node cannot process the message because its Network layer input buffer size (used to reassemble a segmented NPDU) cannot handle the entire message (calculated as the Packet Number times 32).

The use of the remaining four bits in the Extended Service byte depends on the Extended Service type selected in the first four bits. In general, their use is as follows: M#

Message Number bit. This bit is toggled with each new Application layer APDU. The Message Number bit remains the same throughout all segments of the same

125

Protocol

APDU. The Message Number bit distinguishes one group of segments from another. FC Window

Flow Control bit. Indicates (if set to 1) that flow control is requested. Window Size bits (2). Used only with flow control, these bits define the segment transmission “window” size. Window size is 2 plus the binary value of these bits (therefore window size must be 2, 3, 4, or 5). This field is set to 1,1 if flow control is not used.

Packet Number Bytes At least one or more Packet Number bytes follow the Extended Service byte. The Packet Number bytes are used to indicate the number of segments to follow, or an IR/RF packet number, depending on the Extended Service Type used. When Seg_service is used, the Packet Number byte(s) represent the number of segments to follow. The first segment of a message (denoted by the FP bit) has a Packet Number that is one less than the total number of segments. Packet Numbers decrement with each segment. Zero indicates the last segment. When more than 254 segments need to be sent, additional length bytes are used. The initial byte is set to FFh (255) and the following byte contains the remainder segment count. As many bytes are used as needed until the last byte is less than 255. For example, to pass 600 segments, the segment number of the first packet sent would be FFh, FFh, 5Ch (3 bytes). Each additional segment (599 of them) would decrease the segment number by one. When Num_packet service is used by a node on IR or RF for duplicate packet rejection, the Packet Number contains a unique sequence number to enable duplicate IR or RF packets to be identified and discarded by the destination node. The Packet Number is a free-running 8bit counter that starts at 255 and decrements for each new packet. If an IR/RF packet arrives that has the same sequence number from the same source address within a 5-second window (the maximum network delay), the second (or more) packet is discarded as a duplicate. Segmented Service Example The first example is a simple case using segmented service without flow control. The originating node MTE requests transmission of a large APDU using segmented service. The NL breaks the APDU into three segments.8 This example is shown 8

The CEBus Network layer specification does not specify how the Network layer breaks up the APDU. Each segment can contain any number of bytes less than or equal to 32, but the recommended procedure is to send the largest message possible in each segment.

126

Chapter Six in Figure 6.16. The Figure shows the transmission of NPDUs between Network layers of two nodes. The header shows the NL Service byte, the Extended Service byte, and the Packet Number byte used in each NPDU transmitted. The first NPDU shows the NL Service byte with the FP and Ext bits set to indicate the first segment of extended service. The Extended Service byte shows that Seg_service is being used (4 most significant bits have a value of 12), the M# happens to be 1 (for all segments in this APDU), and the FC bit is clear (no flow control). The Packet Number byte starts at 2. The second segment has the same values except that the FP bit in the NL Service byte toggles to 0, and the Packet Number decrements to 1. The last segment has the Packet Number set to 0 to indicate it is the last segment of the APDU. The receiving NL reassembles the segments into a

Figure 6.16 Example of segmented service showing the action of the Network layer of the sending and receiving nodes. The contents of the NPDU header are shown for each packet sent.

Protocol

127 complete APDU, and when the last segment is received, it passes the APDU to the MT Element. Flow Control Flow control can be used with segmented services. When using flow control, the source and destination node Network layers coordinate the delivery of the segments. Flow control allows the originating node to keep track of the progress of segment transmission during segmented service by requiring the destination node to acknowledge reception of a “window” of transmitted segments. The window, or segment group, can be either 2, 3, 4, or 5 segments, and is determined by the value in the 2-bit Window field in the Extended Service byte. If flow control (FC) is used, the FC bit is set in the Extended Service byte and the Window field is set to the desired window size minus 2 (that is, to have a window size of 4, the Window field is set to 2). Errors, such as missing or out-of-sequence segments, are corrected by having the source back up and retransmit all segments after the last correctly received segment. Upon transmission of window-size number of segments, or the last segment, the NL waits for a Pos_ack or Neg_ack response from the destination, or a timeout condition. After window-size segments are successfully received at the destination node (or the last segment) without error, the destination returns a Pos_ack with the Packet Number set to the last received Packet Number value. The acknowledgment packet contains a null APDU (that is, an NPDU Header only). If a missing or out-of-sequence segment is detected during reception, the receiving node immediately transmits a Neg_ack with the Packet Number set to the last correctly received segment number. The source node then begins retransmitting with the next segment after the last good one. Flow control should only be used when transmitting to a single node, because transmitting to a group would cause multiple positive and negative acknowledgments. It is not possible for a node to then retransmit a portion of segments to one node of the group. Flow Control Examples The second example (Figure 6.17) illustrates the use of flow control. The same APDU as in the first example is transmitted, resulting in the same number of segments, but flow control is used with a window size of 2. The first segment shows the same NL Service byte as the first example, but the Extended Service byte shows that Seg_service is requested and the window size field is set to 0,0 indicating a window size of 2 (size 2 window_size). The Packet Number starts, again, at 2.

128

Chapter Six

Figure 6.17 Example of segmented service using flow control with a segment size of 2. The contents of the NPDU header are shown for each packet sent.

After two segments are sent, the sending NL starts an acknowledgment Wait Timer of 10 seconds and waits for a positive acknowledgment from the receiving node. When the receiving node receives the last segment of a window correctly, it will immediately send a Pos_ack NPDU Header with the Packet Number of the last correctly received segment in the window. When the sending node receives the Pos_ack, it will continue with the next window of segments. In the example shown, there is

Protocol

129 only one more segment. When the last segment is received (Packet Number 0), the receiving node also returns a Pos_ack. The third example (Figure 6.18) shows what happens when one of several possible errors occur in APDU transmission. The example is similar to the previous example but the APDU is longer, requiring more segments and

Figure 6.18 Example of segmented service with flow control showing what happens when one of the packets from the sending node to the receiving node is lost.

130

Chapter Six the window size set at 3. The second segment in the first window is lost and never received by the destination node. The destination node does receive the third segment and immediately detects the Packet Number error. Because it is the last segment of the window, a Neg_ack NPDU response is sent to the sending node with the Packet Number of the last correctly received segment prior to the detected error. The originating node then begins retransmission of the APDU at the segment following the last correctly received segment. Similar error conditions can occur if the receiving node does not receive the last segment of a window. In that case, its Wait Timer expires and a Neg_ack is sent with the Packet Number of the next-to-last segment. This causes the originating node to retransmit the last segment and wait for an acknowledgment as usual.

More on IR/RF Packets and Duplicate Rejection When an IR or RF device originates a packet for transmission by a Brouter to a wired medium, the device NL can either use the node address of the intended Brouter in the NL Header, or rely on the IR/RF duplicate packet rejection algorithm in the receiving node. If it chooses a Brouter address, the transmitted NPDU contains 3 bytes (at least) as shown below.

If the device relies on Extended Service duplicate-packet rejection, then the transmitted NPDU Header contains 5 bytes as shown below.

131

Protocol

Notice that a Brouter address is still inserted even though it is not being used. It is set to the Brouter broadcast address (FFFFh). When a receiving Brouter forwards the packet onto a wired medium, it replaces the FFFF with its own node address. Num_Packet Extended Service is used to indicate that the packet originated on either IR or RF and a Brouter address was not used. The Packet Number byte is set to 255. The Packet Number decrements with each new packet sent to the same destination address within a 5-second window. Duplicate packet rejection software requires, in both the transmitting and receiving side, that the NL maintain a Packet Number/source address association list for each transmitted and received packet. Once the first packet to that address is transmitted, a 5-second timer associated with the destination address is started. If the IR/RF device makes another transmission to the same destination before the timer expires, the Packet Number is decremented by one and the timer is reset to 5 seconds. The Packet Number continues to decrement for each new transmission to the same destination address until the timer expires. After the timer expires, the association is discarded. At the destination node, when an Extended Service NPDU Header arrives with a Brouter address, the node knows the packet originated on an IR or RF media and the duplicate packet rejection algorithm is used. The received Packet Number is compared to the list of previously saved packet numbers. If it is a new packet, a 5-second timer is started for that source address and the Packet Number is saved. As each new IR/RF packet is received, the timer is restarted and the new Packet Number is compared to the list of those already received from that source address. A packet is discarded if it is already in the list. Expiration of the timer allows the Packet Number list to be cleared.

IR/RF Packet Examples The example shown in Figure 6.19 shows an RF packet being transmitted from a hand-held remote control device. The packet is picked up by two RF Brouters in the house.9 The remote control transmitted the packet using the node address of one of the Brouters (the one with address 38). The NPDU Header bytes are shown in the “window” pointing to the RF “energy.” Extended Service is not used. Instead, the B1 bit is 9

Two RF Brouters should not be needed in an average size house. Two are used in the example only to illustrate NPDU usage.

132

Chapter Six set and the Brouter address is included. The packet is routed only by the intended Brouter to the power line for reception by the TV. In the second example (Figure 6.20), the hand-held remote control transmits the same message but does not use the Brouter address (it is not known). In this case, the remote control uses Extended Service for duplicatepacket rejection. Both Brouters pick up the RF packet and route the packet to PL. They substitute their own node address for the FFFF Brouter address in the RF packet. The first packet received by the TV will set up an association table entry with the source address of the hand-held remote and Packet Number 255. When the second packet arrives (well within the 5-second limit), the TV will discover that it has the same association as the first packet from the remote, and correctly discard the packet as a duplicate. The third example (Figure 6.21) illustrates using two Brouters to get a packet to its destination. The RF Brouter picks up the packet from the remote. The packet is using Extended Service. Because two Brouters are

Figure 6.19

Example of routing RF packets when the address of the Brouter is included in the NPDU header.

133

Protocol

Figure 6.20 Example of RF packet routing through multiple Brouters. The NPDU headers of the original IR packet are shown along with the headers of the routed packets from the Brouters.

being used for delivery, two Brouter addresses must be included in the packet (B1 and B2 is set). The first Brouter substitutes its own address for B1 and routes the packet to PL. The second Brouter picks up the packet, substitutes its own address for B2, and retransmits the packet on IR for reception by the TV (the destination node address). The TV knows the complete address return path for any reply message.

ID Packets An ID Packet is a special network management packet used to maintain directory routing tables in Routers. ID Packets must be generated by every node on a power-up condition (only if the node has a valid system

134

Chapter Six

Figure 6.21 Example of an RF packet that is routed to an IR medium via a wired medium. The NPDU header bytes for each packet (RF, wired, IR) are shown.

and node address) after a short random delay period. The random delay period (based on the device’s node address) insures that all nodes on the network do not attempt to transmit their ID Packets at the same time. ID Packets originate in the NL after an indication (via Network layer management) from the node’s application software that a power-up condition has occurred. The NL also generates an ID Packet any time it receives a packet with the Routing bits set to 0,0. This combination indicates an ID Packet request from a Router.

135

Protocol

The ID Packet contains only a 1-byte NPDU Header. There is no APDU in the packet. They originate and terminate in the NL. ID Packets are flood routed through the network by Routers. As the ID Packet passes through a Router, the Router updates its Directory Routing Table entry for that particular address. When an ID packet is transmitted by a nodes NL, the NL sets the destination system address to the system address of the node, and the destination node address is set to 00FF (one of the reserved group addresses of Routers). A typical ID packet is shown in Figure 6.22.

Data Link Layer The Data Link layer (DLL) is responsible for reliable transmission and reception of packets over the attached medium. The Data Link layer in each node communicates with the Data Link layer in all other nodes on the attached medium. The Data Link layer receives requests for NPDU transmission from the Network layer and notification of received symbols from the Physical layer. The CEBus DLL does three things: It builds and parses the complete packet including the DLPDU It executes the channel-access protocol It provides an immediate acknowledged packet delivery service on the attached medium. The individual responsibilities for message transmission and reception are listed in Table 6.5. The Network layer makes requests to the Data Link layer for NPDU transmission using requested DLL services. When an NPDU is passed from the Network layer, the DLL Builds the complete DLPDU Gains channel access using the channel access protocol Transmits the packet serially, one symbol at a time

Figure 6.22 Format of an ID packet.

136

Chapter Six

Table 6.5

ELEMENT

Sending Task

Receiving Task

Data Link layer responsibilities.

Data Link

Build DLPDU

Packet reception

Generate preamble

Packet fragment filtering

Leading zero suppression

Bit error detection

Channel access protocol

FCS detection (TP CX IR)

FCS generation (TP CX IR)

Parsing DLPDU

Packet transmission

Address recognition

Acknowledge packet generation

Duplicate packet rejection

Waits for any required acknowledgment of packet reception and performs a retransmission of the packet if necessary When a complete packet is received, the DLL Checks the packet for completeness and lack of reception errors Compares the packet destination address to the DLL node and group addresses Parses the NPDU and passes it to the Network layer if a match occurs Generates and transmits an acknowledge packet if an acknowledgment packet is required The DLL is the most time-critical protocol layer because it operates in real time to keep up with packet reception and transmission.

DLL Structure The CEBus EIA-600 document divides the Data Link layer into two distinct sublayers: The Logical Link Control (LLC) sublayer, and the Medium Access Control (MAC) sublayer. The division occurred early in the development of the CEBus protocol, mainly because it is how Ethernet is designed and the Committee used Ethernet as a protocol model. As DLL functions were refined over the years, the separation proved a burden and all functions migrated to the MAC sublayer. Today, the LLC serves only as a pass-through layer and is kept only as an administrative convenience. All of the DLL services are performed in the MAC sublayer. This is why much of the Data Link layer terminology refers to the

137

Protocol

“MAC this” and the “MAC that.” Terminology such as the “MAC address,” referring to the device node address, still persists. This chapter refers only to the Data Link layer and avoids the LLC/MAC distinction.

Packet Format The first thing that the DLL does after receiving the NPDU from the Network layer is to build the remainder of the packet. The packet consists of the Preamble, Control field, Destination Address, Source Address, NPDU, and an error-detection Frame Check Sequence (FCS). The format of the packet is shown in more detail in Figure 6.23. The Preamble is an 8-bit random value (randomly derived for each transmitted packet) used for collision detection and resolution during channel access. The Control field identifies the type of packet and DLL services for the packet. The format of the Control field is shown in Figure 6.24. The field is divided into the following subfields: S#

The Sequence Number bit toggles between 0 and 1 for each new NPDU transmitted. This bit is used for duplicate-packet rejection at the Data Link layer when using one of the “addressed” services (described later in this section).

SC

Service Class bit. This bit is currently always 0 for basic CEBus service. Extended service (SC 1) is reserved for some future extended capability such as longer packets, different packet formats, and so forth.

X

The next bit is reserved for future use. It is always set to 0.

Priority

The priority bits denote the channel access priority of the packet. The three priority levels determine how long a node waits to transmit a packet.

Figure 6.23 Packet format showing the contribution of the DLL. An EOF symbol separates each field in the DLPDU header.

138

Chapter Six

Figure 6.24 Content of the DLL control field.

Service

The least significant three bits are used to denote the DLL-acknowledged service requested of the receiving node. There are four basic services and two associated replies. The services are described later in this section.

The Destination (To) address and the Source (From) address follow the Control field. Both of these fields are 32 bits and consist of a 16-bit node address and a 16-bit system address. The system address defines a specific address partition for the home to separate it from addresses used in neighboring homes. The node address is either the unique individual node address of the destination node, a group address, or the broadcast address (0000). A destination address is always required. A source address is only required if the destination node needs to return a reply. If a mess age is s ent us ing Applic ation layer implicit_invoke service, and is not using a Network layer Extended Service, and not using a Data Link addressed service, then the source address can be omitted. The trailing Frame Check Sequence (FCS) is either an 8-bit checksum for packets on IR, TP, or CX, or a 16-bit CRC for packets on RF or PL. For a node on IR, TP, or CX, the DLL is responsible for generating the 8-bit checksum. The checksum is a simple addition of all bytes in the packet (excluding the preamble) with carries discarded. For nodes on PL and RF, the Symbol Encoding sublayer of the Physical layer generates a 16-bit

139

Protocol

CRC as symbols are passed down from the Data Link layer, and appends the CRC to the end of the packet.

EOFs, EOPs, and Leading Zero Suppression All fields of the packet, excluding the NPDU, are variable length and delimited by the end-of-field (EOF) symbol. The packet ends in the end-ofpacket (EOP) symbol following the FCS.10 The EOF symbol allows the DLL to perform leading zero suppression. Leading zero suppression does just what it says. Each field is stripped of any leading (insignificant) zeros prior to the first 1 bit used in the field. This accomplishes a simple data compression on the packet. Leading zero suppression is applied to all fields except the Preamble “Packet format:preamble” and the NPDU. The biggest benefit is gained in reducing the size of the address fields. Each address field (destination and source) is 32 bits, yet most system and node addresses used by devices in a typical home will be less than 8 or 9 bits. A high degree of compression is achieved on these fields, shortening packet transmission time. For example, assume that the destination and source address (decimal) of two nodes are as follows: Source system address

5

Source node address

13

Destination system address

5

Destination node address

27

Without leading zero suppression, these addresses would be transmitted as 0000000000011011 0000000000000101 0000000000001101 0000000000000101

taking 117 Unit Symbol Times (11.7 ms). With leading zero suppression, this is actually transmitted as 11011 EOF 101 EOF 1101 EOF 101 EOF

taking 31 Unit Symbol Times (3.1 ms). 10

For packets on RF and PL, the EOP follows the NPDU because it is generated by the DLL. The Symbol Encoding sublayer appends the CRC after the EOP.

140

Chapter Six At the receiving end, the receiving node DLL does not need to reinsert the zeros because the addresses are used directly or converted to an internal (integer) format.

Channel Access Protocol The DLL performs a simple—and inexpensive to implement—channel access protocol called CSMA/CDCR. It sounds a lot more complicated than it is. A node that wishes to transmit a packet waits until the channel is “clear,” that is, no other packet is being transmitted. It then begins to transmit its packet. If, during the transmission, a collision is detected with a packet being transmitted by another node, the node stops transmission and waits again for another clear period. The technique is a little more complex, but that’s the basic idea. The technique is identical to the technique people use to access a telephone line shared by a number of telephones (such as on a party line, or in a home with multiple phones connected to the same telephone line). When you pick up the line and hear someone talking, you hang up and try again later. CSMA/CDCR stands for Carrier Sense Multiple Access with Collision Detection and Collision Resolution. Carrier Sense Multiple Access simply means that many nodes have access to, and are sharing, the same medium, and sense the state of the medium (for a “carrier”) to know when to gain access. Collision Detection means that each node is capable of detecting when a transmission collision occurs with another node transmitting at the same time. Collision Resolution means that a collision can be resolved in favor of one node. The goal of a CSMA/CDCR protocol is to optimize channel access— to allow as many nodes to use the medium as possible without interfering with each other. The strategy used to optimize channel access can be summarized in three methods (the telephone use analogy is given in italics under each one): 1. Avoid contention. If the channel is in use, wait until the channel is idle. If you pick up the phone and someone is already talking, hang up and try again. 2. If contention occurs, resolve in favor of only one node. If two or more nodes attempt to transmit at the same time, all but one should stop transmission.

Protocol

141 If you and someone else pick up the phone at the same time and attempt to talk, the best strategy is for one of you to hang up and let the other person continue, if you both hang up, the situation will just happen again. 3. If a transmission failure occurs, allow the sending node to retry without relinquishing control of the channel. A node should be allowed to attempt retransmission without contention for the channel. If you pick up the phone and begin talking and someone was already on the line talking, the best strategy is for you to hang up and allow the other person to repeat what they were saying, rather than have you both hang up. 1. Avoiding Contention The best technique to optimize channel access is to avoid contention in the first place. The CEBus DLL access protocol uses three methods to avoid contention. Prioritization of channel access. Each transmitted packet can be assigned a channel access priority. The packet priority is used by the sending node to determine how soon it can contend for channel access after an initial 10 UST quiet period after the last packet. Packets are categorized into three priorities: high, standard, and deferred. High-priority packets can contend for channel access during the eleventh UST from the end of previous packet. Standard-priority packets can contend during the fifteenth UST. Deferred-priority packets contend during the nineteenth UST following the last packet. The three priority start times are illustrated in Figure 6.25. All times shown in the figure are referenced from the receiving node. This scheme insures that high-priority packets will only contend with other high-priority packets to gain channel access. Standard- and deferred-priority packets only gain access if there are no high-priority packets. Deferred-priority packets will only gain access if there are no highor standard-priority packets waiting to transmit. Priority Selection A packet channel’s access priority is determined by the node application. The priority is selected based on the type and use of the message. There are no fixed rules for selecting priority, but the following guidelines should be considered. High priority should be used for packets that involve user feedback events where any delay in packet delivery would cause a noticed delay in a control function. For example, the most critical “user

142

Chapter Six

Figure 6.25 Packet priority is based on the start time of the packet from the time the last transmitted packet ends. High-priority packets can start, followed by standard-priority, and then deferred-priority packets.

feedback” timing occurs when a light switch is turned on or off. The user expects the associated light to turn on or off instantaneously. This is due to past experience with lights. If packet delivery takes longer than about 0.1 seconds, the user detects an annoying delay and may attempt to toggle the switch repeatedly, thinking the switch or light is broken or “flaky.” Similar user feedback situations occur when changing channels on a TV, or turning an appliance on or off. Deferred priority should be used whenever there is no rush to deliver the information and there is no user feedback or time-critical events associated with the packet. Deferred priority can be used by devices such as temperature sensors, thermostats, light-level detectors, or other devices that report changes that typically occur slowly. A difference of a few seconds in reporting that the outside temperature has changed from 78° to 79° is not time critical. Standard priority is used for everything else. Standard priority packets are typically used for routine message traffic that is not associated with user feedback but which requires delivery quicker than deferred priority. The packet priority is transmitted in the Priority subfield of the Control byte even though the information is primarily used by the sending DLL to gain channel access. The priority of the packet is available at the receiving node for use by CAL or the application to set the priority of any reply packet returned to the message orig-

143

Protocol

inator. The reply priority is always the same as the original message priority. Round-robin queuing within priority levels. A queuing algorithm is used within priority levels to prevent higher priority packets from “hogging” the medium. Packet queuing is used to enhance the fairness of channel access priority. A packet waiting for transmission can be in one of two queued priority states: queued and unqueued. When a packet is in the queued state, it can be transmitted at the earliest time available for its priority. If the DLL gains channel access without contention and transmits the packet, it then enters the unqueued state for that priority. This means that the next packet it needs to transmit at the same priority will have to wait an additional 4 USTs prior to attempting channel access. The queued/unqueued intervals are shown on the packet transmission times in Figure 6.25. If, while attempting to transmit in the unqueued state, contention occurs and transmission is stopped, the DLL reverts back to the queued state for that priority. The next attempt to transmit the packet will subtract 4 USTs from the access time. This scheme allows, for example, standard-priority packets to compete equally for channel access with high-priority packets from nodes that have successfully transmitted high-priority packets previously. The same situation occurs between standard- and deferred-priority packets. This technique prevents a node with only high-priority packets (such as a light switch) from dominating channel access and preventing standard-priority nodes from transmitting. Randomization of start delay intervals. A random variable is also used to lower the probability of two nodes trying to transmit at the same time. To increase fairness and further reduce contention, a random number (from 0 to 3) is added to the earliest start UST time of the packet. Prior to packet transmission, once the earliest start time for the packet is determined based on priority and queued state, an additional delay of 0 to 3 USTs is added.11 This delay is shown under the queued/unqueued time intervals for each priority in Figure 11

Calculated as the sum of the least significant two bits of the current Preamble and the least significant two bits of the node address.

144

Chapter Six 6.25. The added random delay reduces the possibility that two or more nodes that are in the same priority/queuing time slot try to access the channel at the same time. 2. Resolving Contention in Favor of One Node If contention does occur, each node should attempt to resolve the contention in favor of one node. The technique used to resolve contention is called SUPERIOR state deference. SUPERIOR state deference is the primary means to avoid contention and is the reason why all CEBus media encode packet data in a SUPERIOR and INFERIOR state. Because the SUPERIOR state can be detected over the INFERIOR state, a node can always detect a SUPERIOR state on its medium when it is in the INFERIOR state. If it detects a SUPERIOR state when it is transmitting an INFERIOR state, it knows that another node is attempting channel access at the same time. The first node to detect the contention stops transmitting its packet and waits until the packet being transmitted is completed. This is best illustrated by the example in Figure 6.26. Assume that three nodes (node A, B, and C) all attempt to transmit at exactly the same time.12 The first thing each node transmits is the packet Preamble “Packet format:preamble,” a random 8-bit value. The first state transmitted by each node is the SUPERIOR state because the idle state of the medium is the INFERIOR state. By random chance, all three nodes begin with a 1. At the end of the 1, they all transition to the INFERIOR state (regardless of the next symbol). Node A’s next symbol is a 0 that will last 2 Unit Symbol Times; node B and C’s next symbol is another 1. Node B and C transition to a SUPERIOR 0 symbol after 1 Unit Symbol Time. Node A, still in the INFERIOR state, detects the SUPERIOR state and halts packet transmission. Node B and C continue. Node B and C then transition to the INFERIOR state. Node C’s next symbol is a 1, and node B’s a 0. The same thing happens at node B. It detects Node C’s SUPERIOR state while still in the INFERIOR state, and halts its packet transmission. Node C continues to transmit its packet without interference. All other nodes on the network will receive Node C’s packet successfully, including node A and B. The contention for the medium was resolved in favor of only one node (node C). 12

”Exactly the same time” means within ±25 s of each other. This is the minimum SUPERIOR State recognition time. Anything more and the SUPERIOR State can be detected by any node also attempting to transmit.

145

Protocol

Figure 6.26 Illustration of what happens during SUPERIOR State deference. The example assumes that three nodes begin transmission at exactly the same time.

3. Allow Retransmission without Relinquishing the Channel The third strategy is to allow the sending node to retry without relinquishing control of the channel if a transmission failure occurs. This is implemented in the DLL acknowledged service technique. The 10 UST channel quiet time after each packet allows the transmitting node to regain channel access if its first attempt at delivering a packet failed. This service is described in the following section.

DLL Packet Delivery Services The DLL provides a front-line packet delivery acknowledgment, known as immediate acknowledged service. This lets the DLL know, within 300 s from the end of packet transmission, whether the packet arrived successfully at its destination on the attached medium (or at a Router that will forward it to its destination on another medium). The destination node transmits a short acknowledgment packet immediately upon successful reception of the original packet. If the packet is not delivered, and/or the acknowledgment is not received, the sending DLL can immediately retransmit the message without relinquishing access of the control channel. There are four basic variations on the service that the transmitting application can choose to tailor the delivery service. Unacknowledged service Addressed unacknowledged service Acknowledged service Addressed acknowledged service

146

Chapter Six Each service is accomplished between the Data Link layer of the source and destination nodes. There are two service categories: unacknowledged service and acknowledged service. Unacknowledged service is used when the destination address is a group address or the broadcast address, or when an acknowledgment is not desired. Acknowledged service enables the sending node to determine the success or failure of the transmitted message to a single node across a single medium. Due to the way the channel access protocol works, acknowledged service can only be used when the destination address is a single-node address.

Unacknowledged Service Unacknowledged service is the absence of an acknowledgment from the receiving node or nodes. The DLL transmits the packet once and no acknowledgment is generated by a receiving node or nodes. This service is similar to the Application layer implicit_invoke service. It is usually used when the packet is sent to a group of nodes from which a Data Link acknowledgment is not possible. The service may be used to transmit to a single node, a group of nodes, or to the broadcast address (all nodes on the network). Unacknowledged service is indicated by the use of unack_request (010) in the Service subfield of the Control byte. The control byte looks like:

The Sequence Number (S#) is not used; instead, it is set to 0, the Service Class (SC) is Basic (0), the priority is set to the desired packet priority, and the service bits are set to Unack_request (0 1 0). A Source address field may be used if another protocol layer requires it, otherwise it is omitted.

Addressed Unacknowledged Service Addressed unacknowledged service is similar to unacknowledged service in that no reply is generated by the destination DLL, but it adds an additional level of reliability. Addressed unacknowledged service requests that the DLL transmit the message multiple times to increase the probability of successful reception. The number of times the DLL may transmit a

147

Protocol

packet is governed by a number of variables kept in the DLL software. The variables determine the maximum number of retransmissions, the minimum delay between retries, and the maximum total time allowed for retries. Basically, the DLL may transmit the packet as many times as it can during a 750-ms maximum window (known as the max_retrans_time). The 750-ms window begins at the start of the first successful packet transmission and includes the time required for the last transmission. The DLL must contend for channel access on each transmission at the priority level of the packet. In practice, this allows the sending node to transmit the packet three or four times at most. Typical DLL implementations usually send the packet twice because this is the maximum number of times that the longest packet can be retransmitted. Addressed unacknowledged service is indicated by the use of the addr_unack_request (1 1 1) value in the Service field of the Control byte. The DLL uses the following Control byte:

The Sequence Number toggles between 0 and 1 for each different message sent to the same node (this is used for duplicate packet rejection, explained shortly). During retransmission of a packet, the Sequence Number remains the same. The Service is 0, the priority is selected by the application, and the Service is set to addr_unack_request. The Source Address must be included for duplicate-packet rejection at the receiving node (this is why the service is called Addressed unacknowledged service).

Addressed Unacknowledged Sequence/Address Associations Because several duplicates of the packet are transmitted to the same destination address, a mechanism must be used in the DLL to reject received duplicates. This is accomplished using the Sequence Number and source address in combination at the receiving node to detect a duplicate packet. This service requires that an association be kept between the destination address and the Sequence Number in the sending node DLL, as well as between the source address and the Sequence Number in the receiving node DLL.

148

Chapter Six The association in the receiving node is used to reject all duplicate packets that the sending node might send in the 750-ms retransmission time. All retransmitted packets will have the same Sequence Number (0 or 1) from the same source address. The association (kept in a received association table) must be kept for 938 ms (1.25 750 ms). This time provides for processing and timing differences between the two nodes. Once this time expires, or a new packet is received from the same node (with a new Sequence Number), the association can be removed. In the sending node, the association must be kept to prevent a new packet to the same node from using the same Sequence Number. The association keeps the destination address with the Sequence Number (kept in a transmit association table) for 1,125 ms measured from the last-transmitted packet to that address. This time insures that the receiver will always release the association first. Addressed unacknowledged service is intended to provide higher reliability for messages to group addresses or the broadcast address. It should not be used when an acknowledged service could be used.

Acknowledged Service Acknowledged service requires that the destination node return an acknowledgment to the sending node if the packet arrives without errors (the FCS indicates no bit errors), and if the destination address matches the destination node or group address. To allow nodes to send acknowledgments without having to contend for channel access, the protocol has a 10-Unit Symbol Time acknowledgment window built into the channel-access protocol. This window is free of other traffic and is used to allow a node to acknowledge reception of the packet that just ended. The acknowledgment, in the form of an Acknowledge packet, must be sent by the destination node within 2 Unit Symbol Times (200 s) of the end of the received EOP symbol of the originating packet. The acknowledgment timing is illustrated in Figure 6.27. The originating node expects to receive the acknowledgment within 6 Unit Symbol Times (600 s) of the end of the EOP symbol of its packet. The time difference is to allow for timing differences in the nodes, turn around times, and propagation delay on the medium. The 200 s is referenced from the receiving node. The 600 s is referenced from the sending node. Therefore, the acknowledgment will arrive at the sending node anytime between the third and sixth Unit Symbol Time. The acknowledgment protocol occurs prior to the earliest access possible by a high-priority packet queued for transmission.

Protocol

149 If, for some reason, the originating node does not receive the acknowledgment by the end of the sixth Unit Symbol Time, it will automatically retransmit the message starting during the seventh Unit Symbol Time without relinquishing control of the channel. This automatic retry is part of the acknowledged service protocol. If an acknowledgment is not returned after the retry, the DLL gives up and reports the transmission failure to the Network layer. Acknowledged service is indicated by the use of the ack_request (0 0 1) value in the Service field of the Control byte. The Control byte looks like

The Sequence Number is not used; instead, it is set to 0. The Service class is Basic (0), the priority is set to the desired packet priority, and the Service bits are set to ack_request (0 0 0). A Source address field may be used if another protocol layer requires it, but it is not necessary for acknowledged service. Acknowledged Packet Format The destination node’s DLL returns an Acknowledge packet if the originating packet was received correctly. This packet (Figure 6.28) has a different form than the normal message packet. The Acknowledge packet contains only the Preamble “Packet format:preamble,” the Control field, an optional Information Field, and the FCS. This packet is generated and used exclusively by the DLL. The Preamble “Packet format:preamble” is the same as an application packet. The control field uses a service of Ack (0 0 0) as shown (Fig. 6.28).

Figure 6.27 DLL acknowledgment packet transmission timing. A 10-UST window is always available after a packet is transmitted to allow the receiving node to generate an acknowledgment without contention.

150

Chapter Six

Figure 6.28 Acknowledge packet format.

The Sequence Number is not used, and the Service Class is 0. The Priority bits are not used; they are set to 0,0. The Service class is Ack (0 0 0). An optional Information field is also returned. This field contains additional DLL status information that may be used by the originating node. The possible values of the information field vary with the Service type used. For acknowledged service, only a value of zero (meaning success) is used. Because leading zero suppression is applied to all fields except the Preamble “Packet format:preamble,” both the Control field and the Information field become null. The resulting Acknowledge packet is therefore just [Preamble, EOF, EOF, FCS]

Fail Packet If the destination node receives the packet correctly, but cannot process the packet for some reason (it may be in an error condition or trying to recover from an error condition), a Fail Acknowledgment packet is returned. This will prevent the transmitting node application from retransmitting to the same node repeatedly. The Fail packet is similar to the Acknowledge packet, but the Control and Information fields always contain a non-null value. The Control field contains 1, 0, 0 in the Service subfield. The information field contains one of the two values shown in the following table

Information field value

Condition

Cause

01

Remote Busy

Packet received successfully, but receiving node is busy and cannot process the packet now.

80

Remote Reject

Packet received successfully, but receiving node unable to process packets.

Either returned value indicates that the destination node did not process the packet. The sending node must report the failure to the Network layer.

Protocol

151 Addressed Acknowledged Service Addressed acknowledged service combines the immediate retry service of acknowledged service, with the multiple packet transmission feature of addressed unacknowledged service. Addressed acknowledged service uses the same immediate retry mechanism used by acknowledged service. The destination node must transmit a reply. If the reply is not received within 6 Unit Symbol Times, the sending node retransmits the message starting at the seventh Unit Symbol Time. Unlike acknowledged service, if an Acknowledgment packet is not received after the immediate retry, the DLL can attempt another delivery. It must, however, repeat a normal channel access cycle to retransmit (that is, it must compete with other nodes for channel access after the 10-unit Symbol Time channel-access quiet time). The DLL may attempt to retransmit the packet as many times as it can during the 750-ms max_retrans_time. The 750-ms retransmit time starts at the beginning of the first successful packet transmission and does not expire until the last transmission is complete. The DLL must contend for channel access on each transmission at the priority level of the packet. In practice, this allows the sending node to transmit the packet three or four times at most. As in addressed unacknowledged service, typical implementations chose to send the packet twice because this is the maximum number of times that the longest packet can be retransmitted. Addressed acknowledged service is indicated by the use of the addr_ack_request (1 0 1) value in the Service subfield of the Control byte shown below:

The Sequence Number (S#) toggles between 0 and 1 for each different message sent to the same node for duplicate-packet rejection. During retransmission of the same packet, the Sequence Number remains the same. The Service class (SC) is 0, the priority is selected by the application, and the Service is set to addr_ack_request. The source address must be included for duplicate-packet rejection at the receiving node. Addressed Acknowledged Sequence/Address Associations Just like addressed unacknowledged service, both the sending and receiving nodes must keep an address/sequence number association. Because several duplicates of the packet may be transmitted to the same destination address (excluding the normal immediate retry), the Packet Number and source address are used by the receiving node to detect duplicate addr_ack_request packets. This service requires that an association be kept between the desti-

152

Chapter Six nation address and the Packet Number in the sending node DLL, and between the source address and the Packet Number in the receiving node DLL. The requirements are identical to the addressed unacknowledged service; the timing requirement for the association is explained in that section. Acknowledged Packet Format Like acknowledged service, the destination node’s DLL returns an Acknowledge packet. This packet (Figure 6.29) is different from the normal message packet. The Acknowledge packet contains only the Preamble “Packet format:preamble,” the Control field, the originating node’s source address, an optional Information Field, and the FCS. This packet is generated and used exclusively by the DLL. The Control field will use a service of addr_ack (1 1 0) as below to indicate it is an acknowledgment to the addr_ack_request.

The Sequence Number is the same as the originating packet. The Priority bits are not used and set to 0. An optional Information field is also returned. This field contains additional DLL status information that may be used by the originating node. The possible values of the information field vary with the service type used. For addressed acknowledged service, the information field return values are shown in the following table.

Figure 6.29 Addressed Acknowledge packet format.

Information field value

Condition

Cause

00

Success

Packet received successfully and processed.

01

Remote Busy

Packet received successfully, but receiving node is busy and cannot process the packet now. Try again later.

80

Remote Reject

Packet received successfully, but receiving node unable to process packets.

100-FFFF

Other

Reserved for future use.

Protocol

153 The data in the information field can be used by the originating node to process a retransmission more efficiently. The Remote Reject condition indicates a failure condition in the receiving node. The Remote Busy condition indicates that the packet was received successfully but that the packet could not be processed. This is similar to a receipt_ack indication in the Application layer. Receipt of either condition will stop the sending node’s DLL from retransmitting the packet. Busy Queuing The Remote Busy indication means that the node is tied up with another packet and cannot process the received node. It is an invitation to attempt retransmission after a delay. This indication may be returned by a node whose Network layer is busy assembling a segmented packet, or from a Router whose output buffer (to the routed medium) is full. When this condition is received, the sending DLL will requeue the packet for transmission in the Busy Queue state. This state adds a delay of 12 Unit Symbol Times to the packet’s existing channel-access delay before attempting channel-access again. This added time gives the destination node time to become unbusy and prevents unnecessary channel traffic. When the access delay expires the packet is retransmitted. If another Remote Busy condition is received, the 12-Unit Symbol Time remains in effect for future retransmissions. If no acknowledgment is received, the delay is set to 0 Unit Symbol Times. DLL Service Support A node’s Data Link layer has some flexibility in choosing which DLL service to use. In general, a node can choose to use any of the four DLL services on transmission, depending on the destination address type. A node must be able to support any of the four DLL services on receive. The following guidelines should be used by the application when requesting a DLL service. Unacknowledged service must be used any time that the destination address is anything other than a single-node address (that is, a group address or the broadcast address). Addressed unacknowledged service provides higher reliability than unacknowledged service, but does require more channel access and generates more traffic. Acknowledged service should be used anytime the destination is a single-node address.

154

Chapter Six Addressed acknowledged service provides higher reliability than acknowledged service. It only requires more channel access if the first packet is lost. Because this should be a low probability, addressed acknowledged service should always be used if implemented. Addressed service not only increases reliability by being capable of transmitting a packet several times, but it can also help eliminate what is called the PL or RF “near-far problem.” As an example of the problem, assume three nodes on the power line: nodes A, B, and C (see Figure 6.30). Nodes A and C are far apart on the network and communication between them is marginal. Node B is somewhere between A and C. If nodes A and C happen to transmit a packet to B simultaneously, and node C’s packet is interfered with during transmission (an interfering low impedance or noise source near node C appears during node C’s transmission), node B will only hear node A’s packet and generate an acknowledgment. The acknowledgment will be received by both A and C. C will assume, incorrectly, that its own packet was received and acknowledged. Addressed acknowledgment prevents this because the source address of the destination is returned in the acknowledgment. A typical DLL implementation need only implement one of the unacknowledged and one of the acknowledged services for transmission.

The Physical Layer The Physical layer is pretty much what is sounds like: it is where the “rubber meets the road” or the “bits meet the net.” The packet assembled by the DLL must be transmitted serially, one symbol at a time, on the attached medium. Arriving packets are received one symbol at a time and passed to the DLL for reconstruction. The Physical layer is responsible for transmission and reception of symbols (1, 0, EOF, EOP). It receives requests for DLPDU symbol trans-

Figure 6.30 Simple example of near-far problem.

155

Protocol

mission from the Data Link layer and sends notification of received symbols to the Data Link layer. The CEBus Physical layer does four things: It provides symbol timing. It detects valid symbols on reception. For PL and RF media, it adds a 16-bit CRC at the end of the packet on transmission and checks the CRC on reception. It keeps the DLL informed of the current state of the medium for the DLL’s access protocol. The Physical layer is really two separate parts, which were formally called the Symbol Encoding sublayer (SES) and the Medium Dependent Sublayer (MDS). The Medium Dependent sublayer consists of physical hardware that is dependent on the medium used by the node. It consists of whatever components or chips are necessary to electrically generate the SUPERIOR and INFERIOR states on the medium. The Symbol Encoding sublayer may or may not be physical hardware, depending on the medium and the implementation. Implementations of the Physical layer, including the Symbol Encoding sublayer, for PL and RF are typically all done in an IC.13 The simpler Physical layers for CX, IR, and TP typically implement the Symbol Encoding sublayer in the same microcontroller where the DLL resides. The individual responsibilities for the two sublayers are summarized in Table 6.6.

Table 6.6 Physical layer responsibilities

ELEMENT

Sending Task

Receiving Task

Symbol Encoding Sublayer

Symbol encoding

Symbol decoding

Symbol timing

Bit-error detection

CRC generation (PL, RF)

Channel state detection CRC checking (PL,RF)

Medium Dependent Sublayer

13

SUPERIOR/INFERIOR state generation

SUPERIOR/INFERIOR state detection

Medium interface

Medium interface

Typical of all hardware implementations are Intellon Corporation’s spread-spectrum IC’s for PL and RF.

156

Chapter Six When the SES receives symbols from the DLL, it performs the symbol timing. It alternately generates SUPERIOR and INFERIOR states, and must turn on the Physical layer for the correct amount of time to generate a SUPERIOR state and an INFERIOR state. The timing of the symbols is given in the following table.

Symbol

Transmission timing

Reception timing

1

100 s

50 to 150 s

0

200 s

150 to 250 s

EOF

300 s

250 to 350 s

EOP

400 s

350 to 450 s

Any state of the medium less than 50 s or greater than 450 s is assumed to be a bit error. As well as encoding and decoding symbols to and from the DLL, the SES must also inform the DLL of the state of the medium so that the DLL can implement its channel-access protocol. When the medium enters the SUPERIOR state, the SES informs the DLL that the channel is active (in the SUPERIOR state). When the medium enters the INFERIOR state, the SES informs the DLL the channel is quiet (in the INFERIOR state). The channel quiet indication is passed to the DLL each Unit Symbol Time that the channel remains in the INFERIOR state (this is so the DLL can count channel quiet time). On media other than PL and RF, the state detection must occur within the first 25 s of the start of the state on the medium. On PL and RF, because the symbols use a spread-spectrum carrier, detection of a valid state can only occur after the complete arrival of the state symbol. Therefore, detection of the state occurs after the arrival of the previous state (that is, the SES is always one symbol behind the medium).

The PL and RF Medium SES The PL and RF SES calculate a 16-bit CRC FCS and appends this value to the end of the packet. All bits of the packet, excluding the Preamble “Packet format:preamble,” are used in the CRC calculation. Starting with the first bit of the packet, the SES calculates the CRC starting with the first bit following the Preamble. After the DLL sends the final EOP

157

Protocol

symbol of the packet, the SES appends the additional 16 bits that comprise the packet’s FCS. At the receiving node, starting with the first bit following the preamble, the SES calculates the CRC of the arriving packet, symbol by symbol. After the final EOP is detected by the SES, it takes the following 16 bits as the packets FCS and compares the received value with its own computed CRC on the received packet. If they match, the SES informs the DLL of a successful match. The DLL then assumes that the packet is error free. If the CRCs do not match, the SES informs the DLL of a “bad packet” and the packet is discarded by the DLL.

CEBus Addresses Device addresses are one of two CEBus resources; the other resource being Data Channels. A device’s address is made up of two parts: the system address and the node address. Together, they comprise the device’s complete address on the global network. Every CEBus node must have a system and node address before it can operate properly on the network.

The System Address The device system address (SA) is a 16-bit number in the range of 0 to 65,536 (0 to FFFF hex). The system address is used to partition the address space of devices in one home from devices in another home or apartment residing on the same medium (such as RF or PL). The system address is often called the “house code” because its primary function is to identify the house address.14 There can be more than one system address in a house or apartment, although this makes device installation more challenging. The system address range is divided into reserved and nonreserved ranges as shown in Figure 6.31. Address zero (0000) is reserved as the system broadcast address. A packet that is addressed to SA 0000 will be received by all nodes on the global network; that is, all nodes that can hear the packet, regardless of their current system address. 14

”House code” is also the term that X-10 uses for part of its module addresses that serve the same function.

158

Chapter Six

Figure 6.31 System address range.

Addresses in the ranges 0001 to 7FFF and 8001 to EFFF hex are available for use as individual system addresses. Address 8000 hex is reserved for use by any node performing address acquisition (see Chapter 7 for an explanation). Addresses in the range F000 to FFFF are reserved for some future use.

The Node Address The device node address (NA) is a 16-bit number in the range 0 to 65,536 (0000 to FFFF hex). The node address identifies a unique device within a particular system address. Each node address within a system address must be unique. The NA is often called the MAC address because, along with the system address, it is stored in the Medium Access Control sublayer of the DLL. The node address range is divided into reserved and nonreserved ranges as shown in Figure 6.32. Node address zero (0000) is reserved as the broadcast node address. A packet that is addressed to NA 0000 will be received by all nodes in the house with the same system Address ranges 0001 to 00ED, 1001 to 7FFF, and 8001 to EFFF are available for individual node addresses. Addresses 00FE and 00FF are Router broadcast addresses. These addresses are used by Routers to distribute Router configuration messages. Addresses 0101 to 0FFF are reserved for group addresses (allowing 3,839 groups per system address). Group addresses are a special class of node addresses that can be shared by more than one node. They allow the formation of a logical group of devices addressable with one address. Group addresses are optional, and a device can acquire as

159

Protocol

Figure 6.32 Node address range.

Node Broadcast Address

many group addresses as it has the memory to hold. The example shown in Figure 6.33 shows two groups of outside lights on a house. One group has group address 0102 hex, and consists of all the outside lights. This group is controlled by the light switch on the right. Every node in this group has the same group address in addition to its own unique node address (all these nodes are assumed to be in the same system address). The other group has group address 0114 hex, and consists of the outside lights that are on the front of the house. These lights are controlled by the light switch on the left. Three of the lights are in both groups; that is, they are outside lights and front lights. The remaining two lights are in only one group, the outside lights that are not on the front. The center light (NA 2005), for example, will respond to messages with a destination address of 0102, 0114, or 2005. There is no priority of addresses; it will respond equally to a message from either the left or the right switch. The light simply performs the last message received. Group addresses allow several devices—outside lights in this example— to be controlled by a single message using a single address. The controlling device need only store one destination address. Group addresses are a powerful tool for gaining channel efficiency and flexibility.

160

Chapter Six

Figure 6.33 An example use of group addresses for lights. Each light switch transmits packets to a different group address.

Acquiring and Keeping Addresses A node must acquire a valid (that is, non-zero) system and node address when installed in a CEBus network. A device can optionally acquire as many group addresses as it is capable of acquiring. There are two basic techniques for acquiring the system and node address: self-acquisition and directed acquisition. Self-acquisition means that a node acquires its own address over the network. Directed acquisition means that another node on the network tells the node what address to acquire. Both techniques are explained in Chapter 7. Group addresses are inherited; the “inherit” command is used to tell a node to “join” a group (that is, add a group address). Nodes can leave a group by being sent a “disinherit” command with the group address to leave. This causes the node to remove or “forget” the group address. Once addresses are acquired (node, system, group) they must be kept in nonvolatile memory. Addresses must be retained when the device is not powered or removed from the network. A node keeps its addresses until given a new address, or until it is “reset” in some way that causes it to return to the factory default condition of no address. Nodes may also need to acquire the addresses of other nodes. In the example of the outside lights, the light switches acquired and retained

161

Protocol

the group address of the light group they control. The addresses of other nodes are acquired the same way as the device addresses, by selfacquisition or directed acquisition. Application software in a node may locate nodes on the network it wishes to communicate with, or another device on the network (a controller or configuration device) may get the address(es) and download it into the appropriate node. In either case, the addresses are stored in the application software of the node (in the case of self-acquisition), or in the CAL Context/Object data structure reporting variables (in the case of directed acquisition). Regardless of where it is stored, the addresses of other nodes must also be nonvolatile.

Implementation Issues The description of the protocol layers given in this chapter generally follows the description given in the EIA-600 document. As mentioned at the beginning of the chapter, the description of the protocol is intended to represent a model in which each layer operates independently from other layers, and communication between layers is by a set of “service primitive” calls with arguments. Timing of events within each layer is also treated independently. In practice, the functions of each layer are closely interrelated, and an actual software implementation can combine timers, buffers, and overlapping error conditions. The EIA-600 protocol parts describe a protocol behavior. They are not intended to describe an implementation. A CEBus-compliant node, when tested for proper operation, must exhibit the specified protocol behavior in terms of packet construction, correct use of packet fields, and correct transmission and reception timing. How the behavior is actually achieved is up to the product developer. The following implementation guidelines may be helpful. Each protocol layer maintains several event timers. These timers should be closely coordinated. For example, the explicit_invoke Wait Timer in the Application layer MTE should take into account the services used at lower layers (Network, and Data Link). If segmented service is used, the transmission time of a packet will be multiplied by the number of segments sent and/or received. Many timers can be combined into a set of general timer registers, used as required by each layer.

162

Chapter Six Message-association tables used in each layer can generally be allocated from one association table “pool.” If large messages are supported in the node (where segmented service is used), only one message buffer is needed (for each direction), and that buffer can be shared by the Application layer (MTE and CAL) and the Network layer. Typical implementations of the protocol make the entire packet (DLPDU) available to each layer, from origination at the application or upon reception by the Data Link layer. The packet fields define the services required by each layer.

Layer System Management The EIA-600 protocol layer description relies on an element called layer system management that coordinates the global operation of the protocol software layers, and handles conditions such as startup and reset conditions, errors, and other management tasks. In practice, layer system management software is the node appellation software—that part of the application software that interfaces to the protocol code to manage its operation. Some of the required tasks of layer system management are given in the following list. Setting the protocol software to a known state upon powerup or reset. This includes clearing and setting buffers, timers, tables, and the like. Resetting the protocol software to a known state if a nonrecoverable error condition occurs in the protocol. Causing the Network layer to generate an ID packet on powerup or reset. Transferring any new system, node, or group address from the CAL Context data structure to fields in the Data Link layer (for use by the DLL for address comparison). Setting temporary system and node addresses in the Data Link layer during address acquisition. It is also responsible for any housekeeping task that is not isolated to a single protocol layer.

CHAPTER

7 CAL


164

Chapter Seven The message portion of the packet (the message portion of the APDU) contains the CAL commands. The CEBus Common Application Language (CAL) provides a comprehensive command syntax for residential product control. CAL defines what products say to each other. By establishing a common product model and common set of commands, residential products are able to communicate with other products without knowing how each specific product operates, who built it, or what’s in it. The name CAL is really a misnomer because it is not a formal programming language like C or Pascal.1 CAL consists of two major parts: the definition of a data structure that models product operation, and a command syntax that defines the operation of a set of methods on the data structure. Although CAL adheres to many object-oriented principles typically found in languages such as C, it is not an object-oriented language. CAL messages originate from, and are received and parsed by, the CAL interpreter. The CAL interpreter is an element within the Application layer. It provides services to the application, including resource allocation and control functions. CAL, in turn, uses the services provided by the Message Transfer Element (MT Element) of the Application layer to communicate with other nodes.

CAL Goals CAL’s design requirements were determined early in its development by the CEBus Language Working Group: It must be common among all residential devices. CAL’s strength is its capability to model and control any consumer device found in the home through a common set of data structures. These predefined data structures ensure application-level interoperability. It must allow both control and data acquisition functions. Devices must be capable of performing control functions, and to acquire data from other devices, either actively by asking for the data, or passively by providing a destination for data broadcast on the network. It must allow network management administration and management functions. All of the “housekeeping” functions required by a node 1

When CAL was originally developed, it was intended to be a programming language. The purpose and syntax was later changed to a command “language,” but the name stuck.

165

CAL

must be performed by the language. Tasks such as acquiring an address, allocating resources, finding out what devices are on the network, configuring other nodes, and the like, can be performed by any node using CAL. It must be reusable and extensible. The independence of Context operation allows CAL to adapt easily to future products in the home without having to foresee every conceivable new product. If new products require some new Context (a toastwasher, for instance), then a new Context can be created. It must be customizable. A manufacturer must be capable of handling unique product functions not provided in the published CAL specifications. The syntax must allow the use of manufacturer-developed Context and object data structures, as well as custom commands, while still being assured that they will not interfere with or be interfered with by other nodes on the network. It must be easy to implement in common microcontrollers. A CAL interpreter and data structure must be capable of being coded and must run efficiently in 8-bit microcontrollers with memory space available for the protocol and application code. It should be possible to add necessary CEBus software to existing microcontrollers in existing applications without the need to add additional processors. Manufacturers must be free to trade-off complexity for speed and available memory resources depending on the application. All of these requirements have been met. CAL, and all other CEBusrequired components, have been implemented successfully in devices as simple as a light switch and as complex as wide screen TVs.2 CAL can be implemented at a reasonable cost in any consumer product.

How CAL Models the Consumer Product World It is not possible to know how to operate all consumer products in the home over a network. There are just too many different kinds of products. 2

A light switch is considered to be a “lowest form of life” product. It is used as a benchmark for determining the minimum requirements that a CEBus device must meet.

166

Chapter Seven A more logical approach is to analyze all of the functions that consumer products perform and try to find a commonality, by product category, among those. CAL’s design is based on the assumption that all electrical appliances and products in the home have a hierarchical structure of common parts or functions, and that the basic operation of the common functions is the same from product to product. CAL treats each product as a collection of one or more of these common parts called Contexts. Contexts are designed to allow access to product functions in a uniform way. They are designed to work together over the CEBus network to implement Application layer interoperability between products.

The Context Data Structure The CAL Context data structure is a software model in each CEBus-compliant product that models the operation of all the functions available in the product. The data structure is defined by the Context definitions in EIA-600 and the Context documents published by the CEBus Industry Council.

Contexts A Context defines a functional “subunit” of a product whose operation can be defined and remains the same regardless of where it’s used. A typical example of the Context model can be found in a CEBus-compliant TV. A television is too general a product category to be modeled directly because TV is not specific enough. Some TVs have a clock, some have an audio amplifier, some a tuner, and some have built-in surround sound. TVs, however, are made up of one or more audio/video functions such as tuning, video display, audio amplification, and so on. E ach individual function can be well defined. Any CEBus-compliant TV, therefore, can be modeled as a collection of Contexts at a network node address (see Figure 7.1). Depending on the features of the model, a CEBus-compliant TV might contain a video display Context, an audio amplifier Context, a tuner Context, a clock Context, a user interface Context, and so on.

167

CAL

Figure 7.1 CEBus nodes consist of one or more Contexts. Each Context defines a generic product function.

CAL defines over 60 different contexts for everything from lighting, security, and heating/air conditioning to washing and drying. Each Context, regardless of what product it’s in, operates the same way. The audio amplifier in the TV, stereo receiver, the speakerphone, and the intercom all work alike. If a CEBus product knows how to set the volume in the audio Context in one product, it knows how to set the volume in all CEBuscompliant products. The current list of CEBus Contexts is given in Table 7.1. The list is organized by Context class number and by industry group. Because Context development is a continuing activity, the list is changing and growing. For the most current list, contact the CIC. The section “Where Do Contexts Come From,” later in this chapter, discusses the development of Contexts. Two other Context industry groups exist for future context development: Communications and Computers.

Objects As shown in Figure 7.2, each Context consists of one or more objects. An object represents a software model of a control function of a Context. In the figure, only 4 of the 20 objects used in the actual CEBus Audio Context are shown. The volume, bass, and treble analog control objects, and the mute binary switch object represent control functions typically found in audio amplifiers. Objects model tasks performed by users to control a product. To turn a light off or on, you use a two-position switch (off and on positions) defined in CEBus as a Binary Switch Object. To adjust the volume on a

168 Table 7.1

Existing CEBus Contexts

Chapter Seven Class

Context Name

Class

Context Name

General

Utility

00

Universal

50

Utility Metering

02

User Interface

51

Utility Monitoring

04

Data Channel

54

Load Center

05

Time

55

Load Center Control

56

Energy Control

57

Energy Management

Audio/Video

Security

10

Audio Amp

60

Security Sensor

11

Medium Transport

61

Security Zone

12

Tune

62

Security Partition

13

Video Display

63

Security Partition Control

14

Audio Equalizer

64

Security Alarm Status

15

Camera

65

Security Alarm

17

Switch

18

A/V System

19

A/V System Control Lighting

Appliance

20

Light Sensor

70

Washer

21

Light

72

Water Heating

22

Lighting Zone

73

Dryer

23

Light Status

74

Refrigerator/Freezer

24

Lighting Zone Control

75

Range

76

Oven

77

Coffee Maker

Environmental Control

Convenience

40

Environmental Zone

80

Window

41

Environmental Sensor

81

Window Control

42

Environmental Status

82

Door/Gate

169

CAL Table 7.1

Existing CEBus Contexts (Continued)

Class

Context Name

Class

Environmental Control

Context Name

Convenience

43

Environmental Zone Control

83

Door/Gate Control

44

Environmental Zone Equip.

84

Pool/Spa

45

Environmental System

85

Pool/Spa Control

46

Damper Control

86

Bath

87

Fountain

Figure 7.2 Each Context consists of a set of objects. Objects model the control functions of the Context.

stereo receiver, or to raise or lower the temperature on the thermostat, you use a control (knob), defined in CEBus as an Analog Control Object. All analog controls are similar; they have minimum and maximum values, and can be set to any value between. Other controls found on consumer products include multiposition switches (such as the switch that selects the audio source on the stereo receiver) and keypads. In addition to control objects, sensor objects provide information about a product function such as temperature, position, level, or time. Analog sensors, such as temperature sensors or light-level sensors, are the sensing equivalent of an analog control—they have minimum and maximum values, and can assume any value between. The definition of an object is generic, modeling a general class of control or sensing tasks. However, when an object is used in a specific context, it assumes a specific instantiation of a function of the Context, such as volume or temperature control. In the previous example of the TV, the audio amplifier Context shows a binary switch object for mut-

170

Chapter Seven

Figure 7.3 Icon representation of the objects used to model the various control and sense functions of a context. The diagram of each object contains its class number and name. When used in Context diagrams, the object name is replaced with the name of the object function.

ing, and three analog control objects for volume, bass, and treble. These represent instantiated uses of the Binary Switch object, and the Analog Control object for this application. CAL has 23 predefined object models available for use in making Contexts. Figure 7.3 shows a graphic representation of each of the 23 objects.3 Each object in the figure is labeled with the name of the object and its class number, and an icon for easy identification in Context diagrams. The purpose of the arrowlike shape of each object is explained later in this chapter and in the section on object binding. Certain objects handle functions unique to CEBus-compliant products such as the Data Channel Receiver and Transmitter, and Node Control and Context Control objects. The Node Control and Context Control objects provide storage locations for information about the product and implemented Contexts. 3

The EIA-600 CAL specification lists 29 objects. However, several of the objects (Ganged Analog Control, for example) are left over from earlier versions of CAL and are not recommended for new product design.

171

CAL

Object Definitions Objects are defined by a set of instance variables (IVs), as illustrated in Figure 7.4, that specify the operation of the control or sensing function of the object. The Binary Switch object shown in the figure contains a variable (current_position) that indicates whether the switch is on or off, the default position (default_position) of the switch, and several other optional IVs. IVs are just like variables in any software program, having a length or size and a data type. All network operations on Contexts are performed by reading or writing to object IVs. The IVs that define an object are listed in the object tables in the CAL specification. There is a table for each of the 23 objects. Appendix A contains a version of the CAL object tables. Figure 7.5 is a copy of the Analog Control object table. The object class and name are given on the top line. The description section gives the general intended use of the object including any restrictions, special use information, or recommendations. The description is followed by a listing of all IVs defined for the object class. The IV list contains the label, storage class, data type, name, and description. Any IV label and name in bold type (such as the current_value in the table) represents a required IV in the object. If the object is used, the required IVs must be supported per the requirements of EIA-600 for the data type. IV Categories The IVs in an object can be categorized into three general groups: support IVs, reporting IVs, and active IVs. Support IVs are usually read-only variables that define the installation use of the object and operation of the active IV. These values usually define the units of measure, minimum and maximum values, or other attributes of the active IV. Their use is almost always optional, and they provide other nodes on the network more detailed information about a product’s operation. In the analog control object in Figure 7.5, the first

Figure 7.4 An object consists of a group of instance variables that define the operation of the object.

172

Chapter Seven

Figure 7.5 Analog Control object table as given in the EIA-600 document. The table contains an entry for each IV showing the IV label, access, data type, name, and a description of the use of the IV. This figure illustrates the general categories of IVs in the object: support, active, and reporting.

group of IVs fall into this category. They are optional, read-only IVs used to define the behavior of the active IV. The active IV (or IVs) of an object is the variable that is primarily set or read to operate the object. This variable is usually called the current_value, current_position, or current-something. It is always required and contains the state or value of the object. It may be read-only or read/write. The reporting IVs are always present if an object is capable of generating a message via the CAL Interpreter using object reporting. These IVs contain the reporting address, condition, and message fragment (header) information necessary for the CAL interpreter to know when and where to send the message. Reporting IVs may be read-only or read/write depending on how the IVs are to be configured (at the factory or in the field). IV Labels In each object table, IVs are identified by an ASCII label in the left column. IV labels are an ASCII string of one or more characters. The object definitions use a set of reserved one-character labels, indicat-

173

CAL

ed by uppercase, for IVs that commonly occur in most objects. The remaining IVs in each object, unique to the object, are labeled using lowercase letters. There are only a few, seldom used, IVs that require more than one character. Read/Write Access IVs are specified as either read/write or read-only. The access is referenced from the network, not internally from the product application software. In Figure 7.5, the second column indicates which IVs are read-only (R), or read/write (R/W). For example, the units_of_measure IV, U, is read-only, meaning that other devices on the network can read the IV but cannot change it. The current_value IV, C, can be read or written by other nodes. If an IV is specified as R/W in the standard, it must be implemented as read/writable, but if an IV is given as R, it can be implemented as read-only or read/write at the discretion of the manufacturer. Write-only IVs are allowed but, as of the writing of this book, none have been defined. IV Data Types IVs have a data type just as do variables in a programming language. In CAL, there are four data types: Boolean (b), numeric (n), character string (c), and data (d). The third column in Figure 7.5, indicates the data type of the IV. For example, the units_of_measure IV is numeric. The following paragraphs define the data types and indicate how the data is represented in IVs and in a CAL message. A boolean variable can hold one of two values: 0 or 1 hex, corresponding to False and True respectively. Boolean values are transmitted in a message as a 0 or 1 hex byte.

Boolean

A numeric variable may contain any numeric value; integer or real. Numeric values are always transmitted in a message as an ASCII string of the general form ±n.nE±n, where n is any sequence of digits (ASCII characters 0 to 9). For example, the number 35.8 is transmitted as ASCII characters , 3, 5, ., 8. The standard recommends that numbers that can be represented by four or fewer digits be transmitted in the form ±n.n. Numbers longer than four digits may be exchanged using scientific notation. For example, 1788 and 89.55 are transmitted as shown, while the number 0.00008 may be transmitted as 8.0E-5.4 Numeric

4

The range of numbers needed to control consumer products is small and rarely exceeds values that can be represented by four digits. Most numbers can be stored as signed values in 1 byte (127 to 128).

174

Chapter Seven How numbers are represented in a product is not specified. Numbers may be stored as integer or real values at whatever precision is sufficient for the application. For example, if an IV value is stored internally using 8 bits, and the number 24.39 is received, only 24 (the integer portion) is used and retained. The range of values a particular numeric IV can assume is usually defined in the Context definition containing the object. It is the responsibility of the manufacturer to hold the specified range of numbers given in the Context definition. Character String A character string is any stream of bytes in the range

of 00…7F hex. This range represents the printable and “control” characters of the ASCII character set.5 A character IV must be capable of holding as many characters as necessary for the application. The length of the string is usually defined in the Context definition containing the object. A character string is transmitted in a message in the form:

The LITERAL token (EC hex) is needed to parse the bytes as a character string where it might be confused as an IV label. Note: In the syntax examples used in this book, anything enclosed in the “< >” characters is an element identifier and may be made up of one or more simpler elements. Anything enclosed in bracket characters “[ ]” is optional. Tokens are a set of reserved bytes in the E0 to FE range that are used in the message syntax to represent predefined operations or to simplify message parsing. Data A data variable is defined as a fixed length block of memory. A

data IV can hold any number of bytes (up to its length) of any binary value 00…FF hex. The application and/or CAL Interpreter must keep track of the length of the last data written and the total length of the IV. Data values are transmitted in a message with a data identifier header indicating the size of the data. The format is: <ESCAPE>

For example, the five bytes 1A 01 4F 45 48 are transmitted as: 5

The standard specifies an “escape” sequence that can be used to handle special characters in languages other than English, such as á, õ, ë, and so on.

175

CAL 35 <ESCAPE> 1A 01 4F 45 48

or F4 35 F6 1A 01 4F 45 48

(the length is a number sent as ASCII characters) Required vs. Optional IVs Each object specification indicates which IVs are required in the object when implemented in a context. Other IVs listed in the object are optional. All required and optional IVs used in an object must conform to the object specification. The required IVs provide operational information necessary to use the object. The current_value exists in most objects and contains the primary modeling parameter of the object. In Figure 7.5, only the current_value IV is required in this object (it is bold); all other IVs are optional. IV Volatility IVs containing CEBus resource information (the system, node, group addresses, and data channel numbers) must be stored in nonvolatile memory and must be retained during a power outage. Readonly IVs, when used, are normally kept in ROM. Read/write IVs are normally kept in volatile memory (RAM). The type of memory used depends on the application and whether the last value in an IV needs to be retained during power loss. For example, the current channel number of the Tuner object is a read/write IV, but it may be necessary to retain the last value of the IV when the TV containing the IV is turned on. The manufacturer should always consider the consequences of losing the value of an IV or resetting the IV to a default value due to a powerout or power-up condition. Using Support and Reporting IVs Generally, read-only IVs are not used directly by the product; they are provided so that other nodes— that care to read them—can determine the specific application of the object. For example, in the Analog Control object in Figure 7.5, the units_of_measure, step_size, step_rate, min_value, max_value, and default_value IVs are used to define the characteristics of a particular use of the object. None of these IVs are required, but they may benefit other nodes for two reasons: The IVs may hold values that differ from the default or recommended values given in the Context specifications where the object is used

176

Chapter Seven The manufacturer provided the values to aid in using the object where no default or Context specification values exist Many objects contain a set of reporting IVs: reporting_condition, report_header, report_address, and previous_value. These IVs are used as a group to determine the conditions that cause an object to send a message to another node. Their use is described in more detail later in this chapter. Manufacturer-Defined IVs The IVs listed in the object tables are the minimum needed to define the operation of the object. However, when an object is instantiated in a Context, additional IVs may be added for a unique function required by the object in a specific Context. These IVs are defined when the Context is created by the working group that developed the Context, and become a permanent part of the object only in that particular Context. Manufacturers may also add additional IVs to an object if their particular product requires them. Additional IVs must behave according to the rules for the IV data type, and not interfere with the function of predefined IVs. IV labels starting with the letters I, J, K, L, W, X, Y, and Z are reserved for manufacturer use only. IVs added by manufacturers exist only in that manufacturer’s product, and are not recognized as part of the CAL specification. Object Instantiation Contexts, like objects, are defined by a set of tables that give the definition of the Context, the Context class, and a list of the objects used in the Context. Contexts contain no data or information other than the objects that comprise the Context. When a Context class is created, object classes are instantiated in the Context. Instantiation occurs when an instance of an object class is given a specific function in a Context, and the IVs take on specific values applicable to the Context. Figure 7.6 shows how the Analog Control object (class 07) is used in the Audio Amplifier Context (class 10). This figure shows the Context table entry for the Volume Control—an instantiation of the Analog Control object. Here the object is given a particular function, that of controlling the volume level of the amplifier. The table entry shows the name of the object (Volume Control), its object class (Analog Control), the function of the object, and the standard list of IVs used in the object. The list includes the IV Context function that gives any specific values or use of the IV in the Context. In this example, the first seven IVs are assigned a specific value or range of values for the volume function. When this object is used in a

CAL

177

Figure 7.6 Analog Control object instantiated in Audio Context as a volume control object.

product with an audio amplifier function, using the Audio Amplifier Context, each IV (if implemented) must use the values shown in the Context table. The current_value IV is the only IV required, and assumes the values 0 to 100 (because the units_of_measure is a percentage of full scale). The current_value range corresponds to the minimum and maximum volume range. Figure 7.7 shows an example of the same Analog Control object when used in a different Context. This example shows the Heating Setting object in the Environmental Zone Context (40). Here, the same object is instantiated for a different function. The same IVs are used, but they assume a different meaning. The current_value IV assumes the function of the current heating setting. When implemented, this IV can only assume values between the min_value and max_value IV values. If a message attempts to set the IV to a value outside this range, an error message (value out of range) is returned to the sender. Error message details are given in the Message Responses section in this chapter. Objects are reusable both within the same Context and across Contexts. By using the same model for different instances of objects, the operation of each object is the same regardless of where it is used. This assures the operation of CAL commands on the same object class in different products will produce the same result. Contexts are also reusable within the same product and across products. If a product knows how to operate an Audio Amplifier function in a TV, it can operate an Audio Amplifier in the intercom, speaker phone, or stereo receiver.

178

Chapter Seven

Figure 7.7 This is the same Analog Control object shown in Figure 7.6 except that here it is instantiated as the Heating Setting object in the Environmental Zone Context.

Context Data Structure The Context and object data structure in a product is designed as a tree structure (see Figure 7.8). The message portion of received packets is directed toward a particular object in a particular Context. Each Context is referenced by its class number, while the objects in each Context are referenced by the order in which they are listed in the Context definition, starting at 01. Objects are referenced, within the Context, by their number rather than their class because there are typically many copies of the same class within each Context. Every CEBus product contains the Universal Context (00). The Universal Context contains the general product data, address, and other productwide information. All other Contexts are optional and depend on the functions that the product supports. Object Implementation Objects are coded as a set of IV data variables, and application software associated with the variables. Figure 7.9 illustrates the interface between the object IVs, the application code, and the CAL Interpreter. Unlike objects in C, or other object-oriented languages, CAL object variables are “exposed” to the network through the CAL Interpreter. The application code that implements the function of the object is hidden. IVs may be thought of as the interface between the product application and the “outside world” of the network. Unless protected, IVs can be read or written by any node on the network. Incoming messages either read the values of the variables or write new values. The application code does the same; it checks for changed values and acts accordingly, or updates the values. The CAL interpreter can be

179

CAL

Figure 7.8 Representation of the Context/object data structure. A device may contain any number of Contexts, depending on the functions that the product supports or interoperates with on the network.

Figure 7.9 Representation of object implementation. The object data structure (IVs) is accessible by the CAL Interpreter and the object application code.

programmed to send any new IV value—changed by the application software or by an incoming message—to any other object on the network, in any product or group of products.

Object Network Types Objects can be divided into three general categories: network output, network input, and network input/output. These categories define

180

Chapter Seven whether the object is primarily a sender of messages, a receiver of messages, or both. Objects are represented by one of three symbols corresponding to the network type.

Network output objects generate messages. The current_value IV is read-only and the object is used to originate report messages. Typical network output objects include the binary sensor, analog sensor, and multiposition sensor. Messages are generated when the obj ect current_value changes by some amount.

Network input objects receive messages. The object’s current_value IV can be set from an incoming message, but it does not generate a message. Typical network input objects include the Meter, Display, and Synthesizer/Tuner.

Network input/output objects can receive or send messages, or both, depending on the application. The current_value IV is read/write (R/W), which can be set from an incoming message. Messages can also be sent based on local current_value changes. The change may be the result of an incoming message, or a local application change. Typical network I/O objects are the Analog Control, Binary Switch, and Multiposition Switch. All of the objects (except the Node Control and Context Control objects) fall into one of the three network type categories, as shown in Figure 7.10. The object type symbols are used to develop Context interconnect diagrams that show the interconnectivity or binding from an object in one Context, to an object in another Context.

Object Binding: How Contexts Work Together Object binding establishes an address correspondence (stored in the object reporting IVs) between a network output object and one or more network input objects. Network output objects always send their output

181

CAL

Figure 7.10 Classification of each object as Network Output, Network Input/Output, or Network Input.

Network Output

Network Input/Output

Binary Sensor

Binary Switch

Analog Sensor

Analog Control

Multiposition Sensor

Multiposition Switch

Keypad

Medium Transport

Counter/Timer

Matrix Switch Clock Dialer

Network Input Data Channel Trans

Motor

Data Channel Rcvr

Synth./Tuner

Meter

Tone Generator

List Memory

Display

Data Memory

to network input objects. For example, in Figure 7.11, the Binary Sensor object in the light switch binds to the Binary Switch object in the light. The output of a Binary Sensor object is always sent to a Binary Switch object. There is no other object that can receive the binary value output of a Binary Sensor object. The only information required for binding by the Binary Sensor object is the system/node address and Context of the destination node. The destination object (Binary Switch) is implied. This relationship between specific object classes is intentional. Most network output objects bind to specific network input (or input/output) objects of the same data type (that is, the data type of the reported IV and receiving IV are the same). Binding also extends to Contexts. Most of the objects in each CAL Context are intended to work (or bind) directly with specific objects in other Contexts. Context binding implies a predefined interoperability between Context classes. A Context interconnect diagram defines Context binding and illustrates how two or more Contexts work together. Figure 7.12 shows a

182

Chapter Seven

Figure 7.11 Example of object binding. Output objects always send messages to network input (or input/output) objects.

Figure 7.12 Context interconnect diagram for two of the HVAC Contexts.

simple example of a Context interconnect diagram for two of the HVAC Contexts. The Environmental Sensor (41) Context is intended to reside in any device that measures temperature and/or humidity. The objects in this Context bind to a set of corresponding network input objects in the Environmental Status Context (42), which is intended to be used in any product that needs or wants to know the inside or outside temperature or humidity. This might be a thermostat, a TV, or a PC. The objects in the Environmental Sensor Context send messages reporting a change in temperature or humidity to the Environmental Status Context—there is no other Context/object for the output message to go. This design makes interconnecting or binding products in the field easy because only the system and node address of the device containing the Environmental Status Context needs to be known. A product designer knows where network output object messages will be sent. The diagram also indicates another important attribute. The diagram removes any ambiguity about which Context supplies information and which Context receives information. A product designer that incorporates the Environmental Sensor Context knows that the product will send new temperature and/or humidity values, rather than wait for another product to read the values. A product designer that uses the Environmental Status Context knows that if temperature and/or humidity is available (another product is measuring it), it will be written to the

CAL

183 corresponding objects. The product does not have to read it. This prevents a situation where one manufacturer assumes the information in his product will be read, and another manufacturer assumes the information will be written, and neither product communicates correctly. Figure 7.13 is a portion of another HVAC Context interconnect diagram. This shows the Environmental Zone Control Context (43) and the Environmental Zone Context (40). The Environmental Zone Control Context is intended to be used in products that need to control heating/air-conditioning equipment. This Context might be in a television, a PC, or a home automation system. The Environmental Zone Context is intended to be used in heating/air-conditioning equipment, in particular, a thermostat or equivalent product. Note that the Environmental Zone Context is bound to another Context not shown (the Environmental Equipment Context (44)). Context 43 is typical of many Contexts intended to be used in control products (that is, products that contain a user interface, or control algorithms, and that allow them to directly control other classes of products). An example is a television or PC with an onscreen menu that allows the user to select the heating and cooling setting for the house. User selections change the values in the Zone Control Context. This causes messages to be sent to the Environmental Zone Context in the thermostat to change its settings. Contexts do not have to bind to or be bound by other Contexts, but Contexts do provide a convenient control model. Many Contexts (the

Figure 7.13 Context interconnect diagram for two HVAC Contexts. Context 43 is intended to be used in non-HVAC products that need to control or monitor HVAC zones. Context 40 is intended to perform the functions normally associated with a thermostat.

184

Chapter Seven Audio Amplifier (10), Time (04), Camera (16), and so on) do not have a published predefined binding with other contexts. They are used “as is,” and any binding must be developed during installation or provided by the manufacturer.6 The Context Development Committee of the CIC is constantly working to develop interoperable relationships between most of the industry contexts. Binding in the Field Binding can occur in one of several ways, depending on the scale and application of the receiving group. Consider, for example, the relationship between a light switch node and a light node in which the light switch controls the light. The Light Level Setting object in the Lighting Context (found in the light switch) is designed to bind to the Light Level Control object (found in the light). For this one-to-one binding between a light switch and light, the Light Level Setting usually binds to the Light Level Control Object in a specific light node or groups of light nodes. This is because light switches usually control a specific light, selected when they are installed. All that is required is the system/node address of the light. The Light Level Setting Object always sends its messages to the Light Level Control object in the Lighting Context. A more general (and desirable) binding exists for many types of consumer products that do not require the destination node address. Figure

Figure 7.14 An example of object binding to all of a particular Context/object in the system address. All nodes that contain Context 42, object 3 (outside temperature) will process the broadcast message.

6

This may change as more refinements are made to the Context documents.

185

CAL

Figure 7.15 Typical Context header information. This is the header and first object of the Audio Context (10).

The Audio context contains necessary objects for the majority of audio amplifier functions. The basic context usage assumes one or two channels, but additional objects are provided for four-channel and surround sound applications. Intended for use in A/V as well as nonA/V use (such as in intercoms, speakerphones, etc.).

7.14 illustrates an outside temperature sensor device. The temperature sensor device contains the Environmental Sensor Context (41), and uses the Outside Temperature object (03). This product is intended to bind to ALL Environmental Status Contexts (42) and Outside Temperature objects (03) in the home, reporting outside temperature to any product that needs or wants the information. When the Outside Temperature object in Context 41 sends a message reporting an outside temperature, it uses the house system address, Broadcast node address (0000), so that it will be received by all nodes in the house. The message containing the outside temperature is picked up by any node in the house containing the Environmental Status Context/Outside Temperature object, such as the living room television and the heat pump thermostat. Binding via the broadcast node address makes field installation of products an easy task.

Context Examples Appendix B contains two sample Context tables (Audio and Lighting). Each of the Context descriptions starts with a header that defines the name of the Context, and the Context class number (in hex), followed by a brief description of the general use of the Context (Figure 7.15). The Audio Context contains necessary objects for the majority of audio amplifier functions. The basic Context usage assumes one or two channels, but additional objects are provided for four-channel and surround sound applications. The Audio Context is intended for use in A/V as well as non-A/V use (such as in intercoms and speakerphones).

186

Chapter Seven The Context definition then lists all of the objects used in the Context. Objects are numbered sequentially starting at 01 for the Context Control object. Objects are referenced in a Context by number, not class.

The Universal Context Every CEBus node must contain the Universal Context (00). The Universal Context does not model any functional system of a product. Rather, it stores the global CEBus housekeeping information about the node in the Node Control object. The Universal Context may optionally contain a special function Data Memory object called an Event Manager. The Event Manager object can be used to download program code, CAL commands, or other data to the node over the network.7 The information in the Event Manager object is assumed to be manufacturer specific. Node Control Object The Node Control object (01) is the storage location for global device information such as the system and node address, the product serial number, and other information that applies to the entire product. IVs in the Node Control object are provided to facilitate product identification on the network, aid address configuration, and determine product capability. Figure 7.16 shows the contents of the node control object. Only the IVs in bold type are required. However, many of the IVs are designed to enhance interoperability and should be used if possible. A brief discussion of some of the key IVs follows. The optional power IV (w) is intended to control the “global” power to a device and is applicable only to products whose on/off function is not included as part of other contexts in the device. Typical products that might use the power IV are TVs, VCRs, and computers. The on_offline IV (l) can be implemented to allow a device to go offline for service or manual control. When on_offline (l 0), a node will only respond to a message to put the device back on-line (set the IV to 1) or resource allocation requests. The serial_# IV (s) contains a manufacturer-assigned product serial number. It should be 18 characters or less and contain any combination of ASCII characters. Knowing the serial number of a product allows unique identification of the node and is useful for device address configuration. 7

Use of the Event Manager object is very rare. It is primarily intended to enable controller devices to download executable code to a node over the CEBus network.

187

CAL

Figure 7.16 Node Control object used only in the Universal Context.

The CIC can assign a manufacturer a unique first five-character code to be used as the first five characters of a manufacturer-supplied serial number for all products built by that manufacturer. This insures that no two CEBus-compliant products will inadvertently have the same serial number. The product_class IV (c) is used for product-type identification. The IV contains a number indicating that the product belongs to a specific product category. The list of numbers is given as an appendix to the CAL specification. A portion of the list is provided below (numbers are decimal). 1

TV

50

Microwave

2

Video Monitor

51

Stovetop

3

VCR

52

Oven

4

Audio Recorder

53

Refrigerator

5

Amplifier

54

Freezer

188

Chapter Seven 6

Pre-Amp

55

Coffee Maker

7

Audio Processor

8

Audio Receiver

61

Light Switch

9

CD Player

62

Light Sensor

64

Wall Outlet

20

Temperature Sensor

21

Hygrometer

73

Computer

22

Damper

74

Printer

23

Thermostat

75

CD-ROM

77

Fax

30

Clock

31

Radio

80

Water Heater

32

Clothes Washer

82

Electric Meter

33

Clothes Dryer

83

Gas Meter

34

Dish Washer

84

Water Meter

35

Door

37

Shower

91

Motion Sensor

40

Toilet

92

Security Interface

Class numbers are designed to help locate products on the network. For example, to locate all the VCRs in the house, a message is sent to the broadcast node address to retrieve the specific node address of devices with product_class of 3: [00,01] if (‘c’ EQ 33h) getArray ‘a’ (getArray is a “method” [describing the action to be performed] to return an array of data from the IV)

Manufacturers are encouraged to implement product class IV because it is very useful for network configuration. The system_address (h) and unit_address (a) each hold a 16-bit binary address forming a 32-bit network address for the product. Prior to being installed, a product’s system and node address are unknown (usually set to zero). When installed, these addresses must be acquired. The group_address (g) optionally holds one or more 16-bit group addresses. The number of group addresses that a product can hold is up to the manufacturer, but a minimum of one is recommended. The storage allocation for the IV must be adequate to

189

CAL

hold the desired number of group addresses. The inherit and disinherit methods are used to add and remove group addresses from the IV. The capability_class IV (b) is a rough indicator of the CAL capability of the node. Currently, the IV is a number from 0 to 3 defining four classes. The number defines the minimum guaranteed capability, but the product may always do more. Class 0 devices support only the minimum object/IV/method requirements. Class 1 devices support all objects/methods/IVs that are explicitly identified in the Context specifications used. Class 2 devices support class 1 devices plus a minimum of two group addresses and all basic methods (excluding do, while, repeat, copyValue, and the like). Class 3 devices support class 2 devices plus all methods. The context_list IV (o) is a data array, set by the manufacturer, of all contexts used in the node. The context list uses the context ID syntax: context number followed by the context class (two bytes) for each context used. This IV can be read by the getArray method to determine what contexts are in the node. The configured, setup, user_feedback, and config_master IVs are used for address configuration; to allow the node to acquire a system and node address and, if implemented, allow address propagation to other nodes. The recommended procedure to acquire a system and node address and to propagate a system address to other nodes in the same house, is described in the section on address configuration in this chapter. The configured IV (f) indicates whether the device has acquired a valid system and node address. Prior to installation and configuration, the IV is FALSE. After configuration, the IV is set to TRUE by the node software. The setup IV (i) is used in the address configuration algorithm. It is set to 1 during installation and is incremented to ensure only one device is trying to configure the node. The user_feedback IV (u) is intended to provide, through an application interface, an indication to the user. The indication is primarily intended to assist in address configuration, but it can be used for other functions as well. Some user_feedback values have been preassigned to assist address configuration. 0 Off, no feedback. 1 Initiate an external indication for a specific length of time, such as blinking an LED for 30 seconds, so that the user can locate the

190

Chapter Seven device being configured. The IV value returns to zero following the indication. 2 Provide feedback that the configuration process completed successfully. 3 Provide feedback that the configuration process did not complete successfully. The config_master (t) is a boolean IV implemented only in devices that can acquire and propagate their system address. The IV is always FALSE unless the node has acquired the config_master resource. The source_unit_addr (d) and source_system_addr (e) hold the source node and system address of the last received message. The conformance_level (v) is a character string that indicates a version of CAL that the product is using. The present level of the released standard is 1.0. This value will only change if a significant change is made to the language to add additional capability. The authentication_keys (k) are used in the message authentication algorithm. They are only implemented if message authentication is required in the node. Finally, the reporting IVs can be used to report a change of condition such as power changing from on or off.

Context Control Object The Context Control object is found in every context. It contains only one read-only IV, the object_list (o). The IV is read with the getArray method to obtain a list of all the objects implemented in the context containing the Context Control object. The returned object list contains 2 bytes per object: the object class followed by the object number. For example, if a context contains three objects (number 1, the Context Control object (02); number 3, an Analog Control object (07); and number 6, another Analog Control object (07)), the data stored in the object_list is: 01 02 03 07 06 07

The Context Control object is object number 01 in all contexts except the Universal Context where it is number 02.8 8

This exception is due to the fact that the Context Control object was created after the Node Control object/Universal Context was used in early products.

191

CAL

Determining Product Capability CAL contains many “hooks” in the Context/object data structure to allow a node to determine the function and capability of any other node on the network. Information contained in the Node Control object and the Context Control objects can be used to build a complete profile of a product’s CAL capability. The IVs intended for this purpose include: Node Control object product_class—determines the general category of the node. capability_class—determines general CAL support. conformance_level—CAL version level. context_list—contains a list of all implemented contexts in the device. This is the primary indicator of what a node can do in terms of interoperability. Context Control object object_list—contains a list of all implemented objects in the context. This is the primary indicator of what each context is capable of doing. The context_list and object_list IVs are required; thus, it is always possible to tell what functions a product contains. This allows intelligent nodes (PCs, controllers) to present a user with a list of available functions. It also allows scenarios to be developed for more complex automation tasks in the home.

Where Do Contexts Come From? EIA-600 contains Context specifications for only four Contexts, which are called the General Contexts: Universal, Time, Data Channel, and User Interface. The Universal Context is required in every product: the other three are used across industry product groups. Other Context specifications are developed by the CEBus Industry Council (CIC) in industry-specific working groups. Context working groups exist for each major industry category, such as HVAC, Security, Lighting, Utilities, and so on. Each working group is made up of representatives from companies that have a business interest in the product category. The working group develops the Contexts. When completed, Contexts are reviewed by the Context Development Committee and

192

Chapter Seven submitted for ballot to all members of the CIC. Context specifications are available from the CIC by industry group.

Messages: Object Communications CAL messages are generated by objects via the CAL Interpreter or the object’s application code. Objects communicate with other objects by setting or reading their IVs. The message portion of the packet is formally known as the Application Layer Service Data Unit (ASDU). There are two types of ASDU: The command message and the response message. The command message is sent to a device to perform an action such as setting or reading the value of an IV. If a command message is sent that generates a return value (such as reading an IV), a response message is returned.

Command ASDUs The command message ASDU contains one or more CAL commands.9 The message syntax of a CAL command is shown in Figure 7.17. The message consists of a context ID, followed by an object number, followed by a method, optionally followed by an IV and one or more IV arguments. The byte value F5 is a DELIMITER token. Token names (reserved byte values used to parse the message) are given in uppercase.10 The example message in the syntax figure sets the channel of a tuner to 15. The context ID is 12 (the Tuner Context); the object number is 03 (the Channel object); the method is setValue (45 hex), which sets the IV to the value given as an argument; the IV is the current_value (43 hex); the F5 token separates the IV label from the argument; and the argument is the number 15 represented in ASCII. Because the current_value is a numeric data type, the argument is numeric, and numbers are transmitted as ASCII characters (remember?) 1, 5. Message Address The context ID object # pair forms the destination object address for the message. It identifies a particular object in 9

Refer to the CAL specification for the syntax for multicommand ASDUs. Because being able to parse an ASDU with more than one command is optional, it is seldom used.

10

Tokens are represented by single byte values in the range of hex values (E0 to FE).

193

CAL

Figure 7.17 Syntax of CAL message portion of packet. The example message is for the Tuning Context (12), Channel object (03), to set value (setValue 45) of the current_position IV (43) to 15.

FROM address

NPDU header

APDU header

CAL message

<method>[[<arguments>]] 12

03

45

43 F5

31 35

a particular context in the product. The context ID is made up of two parts. Its syntax is = []

The first part of the context ID is an optional context number. Each context in a product is numbered because there may be more than one instance of the same context class in a product. The number is only used if there is more than one context of the same class in the product. In the previous tuner example, the Context number is omitted. Context class values run from 00…9E hex. Context number values run from A0…DE hex. The context number DE is reserved to indicate the message should be applied to all contexts of the class in the device. For example, a context ID of DE 10 indicates that the message is addressed to all Audio Amplifier Contexts (Context class 10) in the device. Context class values 90…9E are reserved for custom Contexts. Manufacturers may create unique Contexts for a particular product by assigning the Context a class number in the range 90…9E. The object number is the sequential number of the object in the Context. The class of the object (except for a special case) is not used. Object numbers occupy the range 01…3E. A seldom-used construct of the object number is used to identify all objects of a particular class in a context. The construct is 00 object class (that is, 00 hex followed by the object class). This construct means that the message is addressed to all objects of the given class in the Context.

Response ASDUs A response ASDU is generated by a node whenever a node receives an explicit-invoke APDU, regardless of the command message. The returned

194

Chapter Seven response always uses the Result APDU (APDU type 010). The response may contain information returned to a node as the result of a command message. The general syntax for the response ASDU is <status token> []

The status token is a 1-byte indicator of the type of response, and the returned data is any data returned as a result of the command message. The status token is one of three values: COMPLETED (FE), FALSE (FC), or ERROR (FD). The COMPLETED token (FE) is returned if the last received command message was executed successfully, or a command with a boolean expression evaluated to true. If the method in the command message does not generate a returned value (such as a setON, or increment), only the COMPLETED token is returned. If the command message reads the value of an IV (using getValue, getArray, and the like), the returned value follows the COMPLETED token. If the command message contains an if, do, or while method followed by a boolean expression, the expression evaluation will always generate a response byte, in addition to any response generated as a result of the rest of the message. If the boolean expression evaluates true, a COMPLETED token will be returned. If the true evaluation also causes a message to be executed successfully, the response contains two COMPLETED tokens: one to indicate the boolean expression evaluated true, and another to indicate the message executed successfully. For example, assume that the current_value of an analog control object is a numeric data type and currently has the value 67. A command to read the IV is received (using explicit_invoke APDU service): getValue ‘C’

If the message is executed successfully, the response is: 36 37

or FE 36 37

However, if the command is: if (‘C’ 0) BEGIN getValue ‘C’ END

195

CAL then the returned response is: 36 37

or FE FE 36 37

The first FE indicates the boolean expression was true; the second FE indicates the getValue executed successfully. The FALSE token (FC) is returned if the received command message contains a boolean expression that evaluates to false and, therefore, the message is not executed. For example, if the following message were executed (given the same IV value of 67): if (‘C’ 0) BEGIN getValue ‘C’ END

the returned result would be just FC, indicating a false result from the boolean expression. The ERROR token (FD) is returned if the received command message is not executed by the CAL Interpreter. The ERROR token is always followed by an error code as the returned data . For example, if a command message is sent to a light switch, to the Lighting Context, Light Level Control object, to set the value of the units_of_measure IV to 13, the light switch will return the following response: FD 31 35

which is error 15 (IV is read-only). The error codes are listed in Appendix C.

Methods A method identifies an action to be performed by the CAL Interpreter on one or more IVs in an object. A method identifier is a single byte value (in the range 40 to 7E hex) that is followed by one or more arguments separated by the DELIMITER token. Each method operates on a specific IV data type. Method Table The following table lists all of the CAL methods in order of their hex value. Each entry contains the method name, the argument list, and the data types of the IV on which the method operates. This is followed by a brief description of the method operation.

196

Chapter Seven Methods whose ID is underlined, must be implemented if an object contains an IV on which the method can operate. The following symbols are used in the table: Data Types: Boolean, Numeric, Character, Data Method operates on this IV data type Method does not support this data type ❚ F5 delimiter Data types Hex METHOD

Operates on: ARGUMENTS

B

N

C

D

IV

40 nop No operation 41 setOFF

Sets a boolean IV to 0 (FALSE) 42 setON

IV

Sets a boolean IV to 1 (TRUE) 43 getValue

IV

Returns the contents of the IV in a response message 44 getArray

IV [❚ [offset ] [❚ count ]]

Returns count number of bytes of the data IV starting at the offset byte. The default offset is 0 (beginning of the data); the default count is all of the data. 45 setValue

IV [❚ value ]

Sets the IV to value . If no value is given, then the IV is set to the value of the object’s default_value IV. 46 setArray

IV ❚ [offset ] ❚ data

Stores data bytes into a data IV starting at an offset number of bytes. The default offset is 0 (beginning of the IV). 47 add

IV1 ❚ IV2 [❚ IV3]

If only IV1 and IV2 are given, then IV2 IV2 IV1. If IV3 is given, then IV3 IV1 IV2. 48 increment

IV [❚ number ]

Increments IV by number . If number omitted, IV increments by step size IV.

197

CAL Data types Hex

Operates on:

METHOD

ARGUMENTS

B

N

C

D

49 subtract

IV1 ❚ IV2 [❚ IV3]

If only IV1 and IV2 are given, then IV2 IV2 IV1. If IV3 is given, then IV3 IV2 IV1. 4A decrement

IV [❚ number ]

Decrements IV by number . If number is omitted, then IV decrements by step size IV. 4B compare

IV ❚ argument

Used to compare the magnitude of IV with argument . argument can be an IV label or a value. The data type of IV and argument must be the same. Returns 1 (31 hex) if IVGT argument , 2 if IV LT argument , or 3 if IV EQ argument . 4E swap

IV1 ❚ IV2

Exchanges the contents of IV1 and IV2. Data types of both arguments must be the same. 4F report

IV

Initiates a reporting message from an object regardless of any predefined reporting_condition in the object. The value reported is IV. The reporting IVs must be set up correctly. 52 exit

[value ]

Ends the current level of execution. If used within a loop (do, while, repeat), the loop is terminated and execution continues after the END token. If value is given, all parsing terminates and value is returned in a response packet. 53 alias

alias ID [string ]

Used to equate a commonly used character string to a 1-byte alias ID. alias ID must be in the range 80 to CE. If no string , then the alias ID is canceled. 54 inherit

IV ❚ value

Used to assign a value to a resource IV (system address, node address, group address, data channel number). The CAL Interpreter must hail for the resource (except for the group address). 55 disinherit

IV [❚ value ]

Used to disinherit a value from a resource IV. IV must be the group address IV or a data channel IV. value is a group address or data channel number that has previously been inherited. 56 if

boolean-expr BEGIN message list [ELSE message list ] END

198

Chapter Seven Data types Hex METHOD

Operates on: ARGUMENTS

B

N

C

D

Used for the conditional execution of message list based on the result of booleanexpr . message list can contain any message that is valid for the object. booleanexpr may contain any IV that is used in the object. 57 do

boolean-expr BEGIN message list END

Used to perform a do-while—style loop. One execution of message list will occur prior to testing boolean-expr . Execution of message list will terminate when boolean-expr evaluates false. 58 while

boolean-expr BEGIN message list END

Used to perform a while-do—style loop. boolean-expr is tested prior to executing message list . Execution of messages will terminate when boolean-expr evaluates false. 59 repeat

value BEGIN message list END

Will repeat the execution of messages for value number of times. 5A build

macro ID BEGIN message list END

Used to create a macro identifier for one or more messages frequently sent to an object. macro ID must be in the range 80 to CE. 5B copyValue

argument ❚ IV [❚ context ID object # ]

Allows copying an IV from one object to another object in the same product. Copies argument to IV in the same object or in context ID object # in the product. argument is usually an IV in the object receiving this method but can be a value.

Required and Optional Methods A product need not be able to parse and execute all methods. The methods in the previous table whose ID is underlined must be implemented if an object used in the product contains an IV on which the method can operate. The following rules must be followed. If an implemented object contains a boolean IV, then the interpreter must be able to execute the setON, setOFF, setValue, and getValue methods on that IV. If an implemented object contains a numeric or string IV, then the interpreter must be able to execute the getValue and setValue method on that IV. If the object contains a data IV, the interpreter must be able to execute the setArray and getArray method on that IV.

199

CAL

If an object contains an IV that is a CEBus resource (address, data channel), the interpreter must be able to execute the inherit, disinherit, and if methods on the IV, in addition to whatever other method is appropriate for the IV data type. In practice, almost all operations required of objects can be performed by using the basic set of required methods (setOFF, setON, getValue, setValue, getArray, setArray, if, and inherit/disinherit). If a method is used on an object and it is not supported, an error response (unknown method) is returned. Macros A message may contain a macro identifier instead of a method. A macro identifier is a 1-byte value in the range 80…CE hex that takes the place of a method. A macro means the same in CAL as in most programming environments; it identifies a predetermined action or group of actions performed in place of using or sending a list of those actions. In CAL, a macro defines a predetermined set of messages to be performed on or by the receiving object. Macros are defined in the CAL specification for some very common operations and are additionally defined in some context documents. In each case, the macro performs an operation that is so common that defining a macro identifier makes sense. Like a method, a macro identifier may take an argument. The best example of the use of a macro argument is in the address configuration algorithms described later in this chapter.

Message Generation Binding implies a message exchange between the bound objects. Objects originate messages to other objects in one of two ways: the object’s associated application code generates a message, or the object’s reporting condition IVs cause the CAL Interpreter to generate a message automatically (Figure 7.18). The former is called an application message: the latter is called a reporting message. Reporting Message Generation The reporting message capability of CAL is the most common way to accomplish object binding. Whenever the value of the desired IV changes in a predetermined way (increases, decreases, becomes true, and so on), the CAL Interpreter sends a message to another device (or group of devices) to update the value of a “target” IV at a Context/object address. The advantage of using reporting is that it can be preprogrammed in network output objects because the destination Context/object is

200

Chapter Seven

Figure 7.18 Messages originate from the CAL Interpreter using the reporting IVs or an object, or from the object’s application code.

usually already known. It can also be easily programmed in the field, so binding relationships can be established when products are installed. Reporting uses a set of predefined IVs available in all network output and network input/output objects: report_condition, report_header, report_address, and previous_value. These IVs are usually at the end of an object IV list. They are used as a group by the CAL Interpreter to determine when and where to send a message to another node. Their function is illustrated in Figure 7.19. Report_condition: A data variable containing a boolean expression describing a condition in the object to test to determine whether a report message should be sent. The expression uses standard CAL boolean expression syntax. Report_address: A data variable containing the node and system address of the destination device. Report_header: A data variable containing the CAL message to send to the destination device (less the current_value argument). The message contains the Context, object, method, and IV. The IV argument is appended from the current_value of the object. Previous_value: The value of the current_value when the last message was generated. It is the same data type as current_value. Used by the CAL interpreter to compare against the present value of current_value. The CAL interpreter automatically updates it whenever a report is sent. For an object to generate a report, the report_condition, report_address, and report_header must be set to valid values by manually coding them or sending messages to the object to set the IVs.

201

CAL

Figure 7.19 Use of the reporting IVs in network output objects. Reporting generates a message to the report_address. The message is contained in the report_header with the current_value appended.

Whenever report_condition evaluates true, the message in the report_header (with the object’s current_value appended) is sent to the address in report_address to update the value of a “target” IV. The report_header contains the target Context/object address. Using the Report_condition IV The report_condition IV is used by the CAL interpreter to determine whether a report message should be sent. If report_condition contains a valid CAL boolean expression of the form: [AND/OR/XOR ]

the CAL Interpreter will test the boolean expression on a regular basis.11 If it evaluates false, nothing happens. Whenever the expression evaluation transitions from false to true, the Interpreter performs two tasks: 11

Testing is done as often as possible when the Interpreter is not processing an incoming or outgoing message. The frequency depends on the application needs.

202

Chapter Seven 1. It generates a message using the report_header and report_address IV to form the message (Figure 7.19). 2. It replaces the previous_value IV with the value of the current_value IV. CAL appends the current_value IV to the report_header and sends the message to the report_address. A report will not be generated again until the expression evaluates from false to true (that is, it must first transition from true to false and then false to true). The form of the relational expression is: (IV or ) GT/GTE/LT/LTE/EQ/NEQ/DELTA (IV or )

The IV(s) used in the relational expression must be in the object containing the expression, and the value must be the same data type as the IV type. The boolean expression always evaluates to true or false. The implemented length of the report_condition IV must hold the largest boolean expression anticipated. Typical examples of reporting condition expressions are: ‘C’ GT 34 (43 E4 33 34) ‘s’ EQ “00347A” (73 E8 EC 30 30 33 34 37 41) ‘C’ GT 150 OR ‘C’ LT 95 (43 E4 31 35 30 E1 43 E6 39 35)

String values are preceded by the LITERAL token (the EC in the second example) so they will not be parsed as an IV label. The DELTA operator evaluates as “changed by” and tests whether an IV has changed by a value amount. The test is performed by comparing the IV used in the expression to the previous_value IV. For example, the expression: ‘C’ 25

is evaluated as: ABS(‘C’ - previous_value) > 25

To test an IV for ANY change since the last report, the comparison value of 0 (zero) is used. For example, ‘C’ 0

tests C for any change since the last report. This will cause the CAL Interpreter to generate a new report message any time the value of ‘C’ changes. This is a very common expression.

203

CAL

Because reporting messages originate in the CAL Interpreter, the Interpreter usually uses implicit_invoke APDU service as a reply is not expected. The report message NPDU is usually set to all media, directory routing. The NPDU and DLPDU services are chosen by the implementer. There are no required protocol services for message reporting. Using the Report_header IV message header in the form:

The report_header IV contains a valid

setValue [ IV F5h [LITERAL]]

When the message is sent, the current_value IV of the object is appended to the header bytes following the F5 token. If current_value is a character data type, the header ends in the LITERAL token, and the character contents of current_value are appended to the LITERAL . The context and object must be a valid Context/object address in the target device or group of devices. The method should be setValue,12 and the IV should be the target IV character identifier. If the current_value IV is a numeric, the [IV F5] construct of the setValue argument should be used. If the current_value IV is a character string, the [IV F5 LITERAL ] construct should be used. For example, if the reporting object’s current_value IV ‘C’ contains a numeric value of 12, and the report_header IV contains 21 02 45 43 F5, then the message sent will be: 21 02 45 43 F5 31 32

The allocated size of report_header IV should be set to the longest length anticipated for a message header. Using the Report_address IV The contents of report_address IV determine whether reporting is “on” or “armed” in the object. If the IV contains a valid 4-byte target device system and node address, reporting is on. If the report_address is set to zero (0) or null,13 reporting is turned off and no reports will be generated. The address is stored in the order: 12

Because the current_value of all objects that are capable of generating a report is numeric, string, or boolean, and receiving IV must be of the same data type, the setValue method is always used in a report message.

13 Using setArray A DELIMITER DELIMITER DATA 31 ESCAPE 00. This should be the default value of the IV prior to being set.

204

Chapter Seven system MSB, system LSB, node MSB, node LSB

The node address may be a group address or the broadcast address. The system address must be a non-zero address. A system address of FFFF implies that the node should obtain the system address from its own system_address IV in the Node Control object. The data length for the report_address IV should always be 4 bytes.

Implementation Example Figure 7.20 shows an example implementation of a Context/object data structure in two simple products: an outside temperature sensor device and part of a thermostat. The example illustrates the use of object binding using the reporting IVs in the temperature sensor. The outside temperature sensor device contains the data structure for object 03, the Outside Temperature object, of the Environmental Sensor Context (41). The application code updates the current_value IV from the A/D converter. The report_condition C delta 1 will cause the CAL Interpreter to send a message any time the current_value changes by 1 as a result of a change in temperature. The CAL interpreter checks the current_value against the previous_value IV. When they differ by 1 degree, the interpreter generates a new message to the report_address of FFFF, 0000 (the node’s system address, the broadcast node address). The message is to context 43, object 03 to update the value of its current_value to the most recent temperature value. The message is acted on by any node in the house containing the Environmental Status Context/Outside Temperature object, such as the living room television and the heat pump thermostat. The application code in the thermostat updates the outside temperature display from the current_value. Note that in both products, only the objects needed for the application are used, and only the IVs needed are used. Binding via the broadcast node address makes field installation of products a trivial task.

Resource Allocation The resource allocation function of CAL is concerned with requesting, using, and releasing CEBus resources. These resources include individual node

CAL

205

Figure 7.20 Example implementation of a temperature sensor device showing the use of the Environmental Sensor Context.

addresses, group addresses, system addresses, and data channels. Every CEBus node must be capable of handling resource allocation. The basic rules for resource usage on the network are simple and are summarized here. If a node needs to use a resource (address, data channel), it asks for it. If any node is using the resource, the node responds that the resource is not available. If no node responds, the resource is available and can be used. When a node acquires a resource, the resource must be “defended” (that is, if any node asks for it, a reply must be made that the resource is in use).

Address Resources and Address Allocation The most common resource allocation task is address allocation. Each node on the house network must have the same system address, and a

206

Chapter Seven unique node address.14 CAL provides sufficient resource allocation commands to acquire address resources over the network. The primary technique used for resource allocation is hailing. Hailing is a request, to all nodes in an address subset, for a desired resource. The general form of the hail is: if ( EQ <requested resource>) BEGIN exit ‘8’ END

where resource IV is the IV containing the desired resource, and requested resource is the value of the resource desired. If the expression equates true in a receiving node, the exit ‘8’ command is executed. This returns a result COMPLETE response with an argument of ‘8’ (FE 38). The response means the resource exists and is in use on the network, and is not available. The message is sent using conditional_invoke service to the Context/object containing the resource IV. Only the node containing the resource will respond if the expression evaluates true. If it evaluates false, no response is generated. If no response is received (in the 1.5 second MT Wait Time), the request message is resent. If a reply is not received after the second request, the resource is available. For example, to hail for a node address of 0021, the following message is sent to the broadcast node address (0000), the Universal Context, and the Node Control object because it contains the node_address IV: if (‘a’ EQ 0021) BEGIN exit ‘8’ END15

The message is sent using the conditional_invoke APDU service, so that only nodes that evaluate the expression as true will generate a response message. This hailing message format is used to acquire other resources such as data channels. The following example hails for data channel 17h. It is 14

More than one system address can be used in a house or apartment. In practice, a different system address may be used for each medium used in the home, depending on what order media are used and when Routers are installed. However, to keep the explanation of address acquisition and address propagation simple, this book assumes that there is only one system address used in the house.

15

This is an easier to read message format. The actual form of the message is: if ‘a’ EQ DATA 32 ESCAPE 00 21 BEGIN exit 38 END

or 56 61 E8 F4 32 F6 00 21 F7 52 38 F8

207

CAL

sent to the broadcast node address (0000), the Data Channel Context (04), and all class 04 nodes (00 04) in the context.16 [04 00 04] if (‘C’ EQ 17) BEGIN exit ‘8’ END

A hail for a node address can be simplified because the resource hailed for is implied by the destination address of the message. Only the message exit ‘8’ needs to be sent to the node address hailed for. In the previous example of a hail for node address 0021, the simplified hail would send the message to the current system address, node address 0021, rather than to the broadcast node address. If a node already has the node address 0021, then sending the message to that address is equivalent to broadcasting to everyone and testing for node address 21. The message is: [00 01] exit ‘8’

In this case, the message is sent using explicit_invoke APDU service.

Node Addressing When a new CEBus node is installed in a house or apartment, it must acquire a valid system and node address. The node must acquire the same system address as other nodes in the house, and a unique node address. If it is the first device installed in the home, it must acquire a unique system address, different from the system address that is being used by neighboring houses or apartments. As each new device is added, the new device must acquire the same system address as the first node, and a node address not used by any node previously installed (at the system address). How not to Acquire Addresses The standard does not specifically rule out letting a user pick and set a product address.

16

This message might also be sent using an NL service that selects an allowed medium that the data channel is known to use.

208

Chapter Seven However, allowing the homeowner to set product network addresses using DIP switches or rotary switches—even if they could represent all 65,000 system and node addresses—simply does not work. Consumers are not generally capable of understanding addressing concepts and keeping track of what device has what address. If devices are addressed incorrectly, troubleshooting the network is beyond the capability of most consumers, even for those with a technical background. The solution is to require devices to acquire their own addresses using self-acquisition or directed acquisition techniques. The CAL portion of the standard details an address acquisition and propagation algorithm that will accomplish the required acquisition tasks uniformly for all nodes. The standard describes the CAL message interaction of the algorithm, but not how the algorithm is implemented in the node. It does not describe how the algorithm is initiated or how any user interaction is performed. The algorithm does not rule out the use of more sophisticated manufacturer-dependent algorithms.

Address Self-Acquisition Self-acquisition of a system and node address means that the installed node must be capable of negotiating for a new or existing system address and a new node address. The process is different for the first node installed in a new system versus a node installed in an existing system. Getting That First System Address The first node installed in the home must acquire a unique system address. From a resource allocation standpoint, the task is straightforward. First, the node picks a random system address to try from the range of possible 16-bit address values. Once picked, the node hails for the resource. The message uses the selected system address and the broadcast node address (0000) as the destination address,17 to the Universal Context, Node Control object using explicit_invoke service: [00 01] exit ‘8’

17

The source address should be the selected system address, node address 0100. Because a nonzero node address must be used, 0100 is recommended as no node will have this address (it is reserved).

209

CAL

If any nodes on the global network have the selected system address and receive the message, they will respond.18 If no responses are heard, the requesting node can use the system address and set its system_address IV (after repeating the request one or more times to ensure the message got through). If a response is heard, the node must pick another system address and try again. The process continues until an address is picked that produces no response. After the node acquires a system address, it can set its node_address IV to any valid node address value. No hailing is necessary because there are no other nodes at the new system address. How this process is initiated—the user interface used—is up to the manufacturer, and depends mostly on the user interface available on the node. It may be as simple as a button on the back of the device labeled “push if first CEBus device,” or as complex as an onscreen menu selected by an IR remote. When nodes other than the first node are installed, the process is a little more complex. New nodes need to acquire the system address of the already installed node(s), and a unique node address. To accomplish this, one or more existing nodes must be able to “propagate” their system address to the new node. This must be accomplished without interfering with possible new nodes in a neighbors house. The Address Propagation Algorithm The algorithm to propagate a system address uses the address resource allocation IVs in the Node Control object (configured, config_master, setup, and user_feedback). The algorithm works by establishing two classes of “addressing” nodes: the Address Configuration Master node and the Address Configuration Slave node. The Master node already has a valid system and node address—its configured IV is TRUE. It acquired its system and node address either by hailing or by being configured by another node. The Slave does not have an address and needs to be configured. Any CEBus node can be either a Master or a Slave.19 The algorithm is illustrated in Figure 7.21. The process assumes that some action starts the algorithm in the Master and Slave device. This could be a user pressing a button, or making an onscreen menu selection, or by using a controller device such as a hand-held remote. The user feedback events in the algorithm assume some notification to the user or controller. 18

Because the hail was sent using explicit_invoke service, many nodes may respond. The hailing node can discard all but the first response.

19

The software to perform address propagation is not required in a node if another means is provided to address the node.

210

Chapter Seven

Figure 7.21 The address propagation algorithm illustrated between two nodes. A user must initiate the algorithm in both nodes using some interface provided by the manufacturer.

The first step in the algorithm is for the Master node to acquire the config_master resource. The config_master IV is used as a networkwide flag to indicate—to the network—that a node is propagating its house code. Only one node on a global network can have config_master TRUE at a time. This prevents two neighboring house codes from performing house code propagation at the same time, which would cause a Slave device to get the wrong system address. This is only one of several safeguards built into the algorithm to prevent inadvertent propagation. The Master hails for config_master using a macro method to simplify the message structure.20 The message is sent to the broadcast system and to node address (0000,0000): [00 01] M1

M1 is macro #1, sent as 80h (macro 2 is 81h, macro 3 is 82h, and so on). M1 is equivalent to: [00 01] if (config_master EQ TRUE) BEGIN send macro M5 END 20

Almost all the address configuration messages have been standardized into a set of predefined macro instructions because every node must be able to perform most of the macros.

CAL

211 The hail is performed twice, with a minimum 2-second wait between each try. If the hail was successful—no responses were received—the Master sets its config_master IV to TRUE and notifies the user that propagation can continue. When a Master has config_master TRUE, it will also receive messages addressed to system address 8000. Once config_master is acquired, it stays set for 5 minutes (recommended). This gives the user time to initiate the Slave algorithm. If, during the 2-second wait following transmission of the M1 macro messages, an M5 macro message is received, it means that another node already has config_master set. The Master provides a negative notification to the user that propagation is not possible now (user_feedback IV set to 3). The user can try the process again later. The user, or controller device, also starts the algorithm in a Slave node. After the algorithm starts, the Slave sets its configured IV to FALSE, and sets system_addr to 8000. System address 8000 is reserved exclusively for Master/Slave communications during address configuration. The Slave then hails for a temporary node address using system address 8000, node address 0100. When acquired, the Slave broadcasts macro M2 (meaning I am setup and ready) to address 8000,0000. When received by the Master, the Master immediately transmits macro M3 back to the Slave at address 8000,NA and begins a 5-second wait. When M3 is received by the Slave node, it increments the setup IV by one. M3 is equivalent to [00 01] increment setup. After the 5-second wait, the master then transmits macro M4 to address 8000,NA (using explicit_invoke service). This macro causes the Slave node to complete the propagation process. The Slave checks whether the setup IV has a value of 2. If it does, it will set its system_addr to the source system address field of the received message—the system address of the Master—and hail for a new node address. When a node address is acquired, configured IV is set to TRUE, and the user is notified the process completed successfully (user_feedback set to 2). The Slave returns a reply APDU with a Results Complete ASDU. The reply message source address has the Slave’s new node address. This may be useful to the Master. If the setup IV is anything other than 2 when M4 is received by the Slave, it means that two Masters (somehow) are attempting to propagate, and the Slave ignores the message and notifies the user that propagation did not work (user_feedback 3). Directed Address Acquisition Address configuration can also be performed by a third-party device that manages node addresses. Many

212

Chapter Seven variations of address configuration are possible if enough intelligence is available to a configuring device. Other IVs, such as the serial_# and product_class used with user_feedback, can also be used to accomplish address configuration.21 If a device’s serial number (stored in the serial_# IV) is known at installation, this value can be used to directly set the system and node address using a message to the broadcast system and node addresses (0000, 0000): [00 01] if (serial_# EQ ) setArray ‘h’ <system address>

The node address can be set the same way. A device can broadcast its serial number “in the blind” (using context 0) for use by an address configuration: 00 <serial number length> <ESCAPE> <serial number>

This is the syntax for a user-defined message. The serial number is transmitted as data to the Universal Context. This might happen when the device is unconfigured and powers up. A controller device can also cause all nodes that have not been configured to return their serial numbers by broadcasting the following message to (0000, 0000): [00 01] if (configured EQ FALSE) getValue serial_#

All nodes that are on the network and not configured will return their serial number. The nodes can then be individually located by broadcasting the message: [00 01] if (serial_# EQ <specific # >) setValue user_feedback ‘1’

This causes something on the device to indicate that it should be configured. The user can then perform some action, such as causing it to enter the Slave mode of address propagation. Controller devices can also keep track of what addresses are on the network and what type of devices are at each address by reading the product_class IV. 21 The CEBus Industry Council will assist manufacturers in selecting a serial number range that is not used by other manufacturers. CIC maintains a list of assigned serial number prefixes.

213

CAL

The CAL Interpreter The CAL Interpreter is the element of the Application layer responsible for parsing and executing most ASDUs. The Interpreter performs two tasks: it parses and acts on incoming messages, and it generates any messages required by the reporting condition of objects. The CAL Interpreter must handle these minimum tasks: Parse incoming messages Perform numeric conversion on message numbers Handle resource allocation requests Handle address configuration Interpret reporting conditions and generate report messages Interface to application code Detect message error conditions and send error messages Although there are many ways to implement software that will perform these tasks, the most common is a simple interpreter. An interpreter can handle the widest class of received messages and generalize method execution and object access. An interpreter must have some data structure that represents the implemented Contexts, objects, and IVs, so that IVs can be read, written, and tested. The data structure must also be accessible from the device application software. The parsing is straightforward. The CAL Interpreter looks at the incoming message, determines whether it can be performed based on what is supported in the device, and executes the method (see Figure 7.22). If anything about the message causes parsing and execution to fail, and if explicit_invoke service was used, then an error reply message must be generated. An example Context/object data structure is shown in Figure 7.23. This example shows the data structures implemented as a series of linked lists. The Context list contains one list element per Context. The Figure 7.22 General parsing scheme for a typical CAL message. If any of the conditions fail, an error response is returned.

214

Chapter Seven

Figure 7.23 Example implementation of CAL Context data structure and its interface to the application I/O routines.

Context element contains a list of implemented objects and a pointer to the object IV data structure. The object structure contains a pointer to the application code (if any) associated with the object. The CAL Interpreter may call the application routines for execution, or the application routines may be contained in a “main” routine and call the Interpreter. In either case, execution timing requirements must be carefully watched. The CAL Interpreter must keep up with incoming messages. Application routines need to keep up with changing IV values and the application requirements. Simple CAL Interpreters that are capable of only the minimum requirements have been written in small microcontrollers in less than 5K bytes of code. A full CAL Interpreter that is capable of executing the majority of parsing and reporting requirements will probably require between 10K and 20K bytes.

Transporting Non-CAL Messages The CEBus Application layer can transport any type of message, not just CAL. Setting the APDU mode bit in the APDU header to 0 indi-

215

CAL

cates that the packet is transporting non-CAL data. As long as the data length restrictions of the APDU are maintained, any type of data may be transported. The transported data might be proprietary commands that can only be understood by certain manufacturer’s products, or commands from other protocols such as X-10 or LonWorks. However, to use the information, the receiving node must have some way of knowing the contents of the message field. This is up to the product implementer.

Generic CAL (ANSI/EIA-721) In 1997, the EIA began a separate effort to “spin-off” the CAL language from the CEBus protocol. The EIA, as well as the CEBus Committee, had received many requests for information about using CAL with other protocols. Also, because the HomePnP specification (see Chapter 9) had adopted CAL as an interoperability language, and because HomePnP was intended to be used with any transport protocol, there was a definite need for a generic version of CAL that was not tied to the specifics of the other CEBus protocol layers. To perform a clean “stage separation,” the EIA elected to create a new, CEBus-independent specification for the language. It was assigned the number EIA-721 and named Generic CAL. The goal of Generic CAL is to provide a protocol-independent language specification that can be adapted (through a “protocol adapter”) to any protocol capable of operating reliably in a home and providing twoway message transport. The network Adapter layer takes the place of the Message Transfer Element in CEBus and provides the interface between the Generic CAL Interpreter and the lower levels of the protocol, implementing the receive and send message transfer interface.

Differences between Generic and CEBus CAL EIA-721 is nearly identical to CEBus CAL except for items in the language that were designed around the lower-level protocol assumptions. The major difference is in how Generic CAL and CEBus CAL handle addressing and the network address space. Other differences include timing and quality-of-service issues.

216

Chapter Seven

Figure 7.24 Generic CAL interface to a non-CEBus protocol stack.

Addressing CAL always assumes the CEBus standard address space of a 16-bit system address and a 16-bit unit address. Other protocols, however, use different address space sizes and designations. In Generic CAL, a Device Address may be specified in one of two formats: a Short Device Address and a Long Device Address. The address bytes are grouped into 16-bit words named addr1, addr2, addr3, addr4, addr5, addr6, addr7, and addr8. The first two words, addr1 and addr2, appear in both length formats. Thus, the Short Device Address consists of 4 bytes (two 16-bit words). The long format may include one to six additional words: addr3 up to and including addr8. The short format is backward compatible with EIA-600. In that case, addr1 represents the unit address and addr2 the system address. The two-part address format of EIA-600 is appropriate for network media that span more than one logical area, such as a house, office, or apartment. In this case, the address is composed of two components: area address and unit address. Each logical area that shares a medium, such as power line or radio, would be assigned a unique area address (corresponding to the system address in EIA-600), while devices sharing a logical network within an area are assigned unique unit addresses. For networks that accommodate multiple media, some of which span more than one area, this two-part addressing scheme is suggested for all media to facilitate internetworking.

217

CAL

A device can determine its unit address and area address, using the same address configuration algorithms listed earlier for CEBus CAL. The long format for device addresses is appropriate when implementing Generic CAL on some protocols, such as the Internet Protocol. Version 6 of the Internet Protocol specifies 128 bits (16 bytes) per address. Group addresses, if implemented, can also be determined statically or dynamically. Membership in a group is determined by the user. For instance, a bank of lights in a room may always be turned on or off together. By selecting a group address and asking each of the lights to join the group, a single transmission can be used to manipulate all of the lights together. Timing Issues CEBus CAL established several timing restrictions on the interface between the MT Element and the CAL Interpreter Element (see Basic Service Details section of Chap. 7). These timing restrictions, such as explicit_invoke response times, were designed assuming a CEBus network, and will have to be adjusted (or eliminated) for other non-CEBus networks or mixed protocol networks. Quality-of-Service Issues CEBus CAL assumed a certain quality of service provided by the lower protocol layers, such as DL Acknowledged service. When implementing Generic CAL, it may be necessary or desirable to implement a way for the CAL Interpreter to know the quality-ofservice capability of the lower protocol layers. This information can be transferred to the CAL Interpreter Element via Layer System Management (or the equivalent). The following quality-of-service factors may effect the operation of the Generic CAL interpreter and should be made available from the lower protocol layers: Transport layer Segmentation allowed/disallowed Maximum message size End-to-end error management Network layer Flood versus directory routing capability Media supported Media restrictions for particular message types Data Link layer Support for unacknowledged retries

218

Chapter Seven Support for immediate acknowledgment with up to n retries Support for packet acknowledgment with up to n retries Whether source address may be omitted Whether packet priority levels are supported Whether specific service classes are supported

CHAPTER

8



220

Chapter Eight Having a broad range of truly interoperable, out-of-the-box, plug-andplay products has always been a “holy grail” of the home automation industry. It would stimulate a wealth of new products and allow home automation to reach the consumer on a large scale. But despite the development of new “interoperable” network technology and standards over the past few years, that goal remains elusive. A big problem has been a lack of understanding of how to achieve plug-and-play interoperability. The first hurdle is understanding the often misused interoperability word. There are (at least) three levels of network interoperability: communications, applications, and plug-and-play. Communications interoperability implies that products can successfully communicate with each other—send information from product A to product B—using a common protocol and physical medium. Network protocols such as Echelon’s LonTalk, the CEBus protocol, the X-10 message protocol, and RS-232 all provide communications interoperability. Application interoperability, requires products to use a common “language” at the application level. CEBus’s CAL is the best example. CAL lets products understand what other products are “saying.” But manufacturers have already learned the hard way that even with the same communications protocol and application language, unless product applications are specifically designed to work together and are installed correctly, interoperation between products from different manufacturers is unlikely. It requires plug-and-play interoperability, meaning that products from different manufacturers, in different product categories, can be purchased, connected, and self-configured, so that they operate together in a way that can only be achieved by predefined cooperative interaction. Several years ago, a group of companies set out to write a complete specification about how consumer products should “behave” together to achieve plug-and-play interoperability. Intended as a consensus agreement between manufacturers, the HomePnP (Home Plug-n-Play) specification was finished in September 1997. The specification defines how networked products can achieve a plug-and-play level of interoperability regardless of the communications protocol used (CEBus, IEEE-1394, TCP/IP, and so on).

HomePnP Overview The HomePnP specification defines exactly what product manufacturers need to successfully make network products that will work together out of the box.


221

Figure 8.1 Domain of the HomePnP Specification relative to various Transport protocols.

The above Figure 8.1 shows the domain of the specification in terms of traditional protocol design. The specification builds on the common application language (CAL) of the CEBus standard by defining a complete interoperable product function data structure, and a set of interoperability guidelines for the proper use of those data structures. CAL was used as a basis for HomePnP because it is a general, flexible, object-oriented language designed for consumer product operation and because it already had the mechanism for network management and product interoperation. The Context data structures are defined in a set of subsystem definitions and represent tremendous industry consensus-building regarding the operation of subsystem for security, lighting, environmental, energy management, utility, computer, and entertainment applications. Each CAL Context is a predefined data structure built from reusable objects, and represents a common consumer product function such as tuner, time, and a temperature sensor. The system guidelines define device behavior necessary to make products that correctly use the subsystem models. The guidelines also define procedures for difficult plug-and-play problems such as self-configuration, resource allocation and conflict resolution, resource subscription, product zoning, locking, and message scope and security. None of the components of HomePnP rely on any particular Transport protocol capability. To make implementation on different transports easier, a new transport-independent version of the CEBus CAL language (referred to as Generic CAL) was defined in EIA-739. HomeP-

222

Chapter Eight nP allows manufacturers to use a Single-Application protocol and to separately select an independent Transport protocol appropriate for the subsystem.

Some New Ideas HomePnP established several new techniques and principles to achieve its goals: Inter- and intrasubsystem interoperability State broadcasts Predefined hierarchies Resource configuration and management House and subsystem state vectors HomePnP relies on the principle that all products in the home can be grouped into functional subsystems (lighting, environmental, entertainment, and so on) and that communications between products in a subsystem and between subsystems is hierarchical. Each subsystem is specified by a set of context data structures that define intersubsystem communications—messages between peer subsystems in the home— and intrasubsystem communications—communications between devices or device components within a subsystem (Figure 8.2). Most intersubsystem communications are in the form of status and request

Figure 8.2 Subsystem interoperability is defined by two types of context communications: intersubsystem (between different subsystems) and intrasubsystem (within the same subsystem).

223


messages; status information is broadcast to indicate the general status of the subsystem (the security system arming status or the heating/cooling settings), or to request a subsystem operation (home theater mode or a lighting scene). Each subsystem context represents a product or subsystem function and is typically dedicated to either providing or accepting status information or commands. During installation configuration, each context acquires an identification number ID (similar to a network address) to uniquely identify and bind its function on the local home network. Communications between subsystems rely on loose coupling between Contexts. Status and requests, in the form of state vectors, are broadcast to network functions (Contexts), not products, by using Context ID numbers as a form of function address. The majority of HomePnP deals with intersubsystem (loose coupled) communications, which greatly simplifies product installation. Intrasubsystem communication is command/status oriented (set the VCR to play, TV to channel 13, the temperature is 73) and provides the details necessary to supply subsystem status or implement subsystem requests. Communications between functions within a subsystem typically rely on tight coupling or binding. Status and requests are directed to functions in specific products or network addresses. The inter- and intrasubsystem context design reflects the typical physical nature of how product categories are organized in the home. Figure 8.3 illustrates a typical portion of an A/V subsystem and an HVAC subsystem. A/V products use a local 1394 bus for intrasubsystem communi-

Figure 8.3 Typical subsystem (inter- and intra-) communications often reflect the physical “clustering” of devices in the home.

HVAC equip. TV 73

Thermostat

VCR

1394

TP Intrasubsystem Messages

PL

Intrasubsystem Messages

Intrasubsystem Messages

224

Chapter Eight cations, and HVAC products use a twisted-pair (TP) network for intrasubsystem communications. These messages are typically tightly coupled (but can also use loose coupling). Intersubsystem communication (status and requests between subsystems) relies on broadcast, loosely coupled messages over the power line.

State Vectors To increase the efficiency of subsystem communications, HomePnP developed a new form of CAL message called the state vector: a hierarchical string of data providing a synopsis of a subsystem status or requested operation. The hierarchical vector data is abstracted from the details of the subsystem with the first element (one or more bytes) of the string being the most significant data, the second element modifying the first, and so on (Figure 8.4). Listening devices only parse to the level of detail they can act on. Not all HomePnP state vectors (or messages) are strictly between two subsystems or functions within subsystems. Some information is network “global,” applicable to all subsystems. One of the best examples of a global state vector is used to represent the house mode—the overall “activity” or state of the house. The first element of the house-mode vector defines the house occupancy (occupied, unoccupied, or uncertain), the second element defines probability (certain, probable), the remaining three elements are house state modifiers that add increasing details to the actual or desired state of the house (occupancy activity, remaining time unoccupied, and so on). Any device can contain Contexts to generate or receive the house mode state vector and the information can be used to change the operating mode of each subsystem.

Figure 8.4 HomePnP state vector design. The state vector (sv) elements are hierarchical; the first conveying top level information, the second modifying the first, etc.


225

Configuration A big contribution of the HomePnP specification is the details of product self-configuration. HomePnP product configuration requires a lot more than just obtaining a valid network address. It covers the procedures for dynamic loose (Context number) binding, manual loose binding, resource allocation, resource subscription, conflict resolution, group addressing (tight coupling), and installation tool-assisted binding. Products can provide two types of network resources: information (such as time, temperature, electric use) and function (user interface, display, storage). These resources must be allocated so that there is no conflict between two providers (such as two devices providing the time) and each is uniquely identified. Resource users must be able to “subscribe” to or locate and receive the type of resource information desired (such as the time from the DSS receiver). Both procedures use dynamic Context ID generation during installation to differentiate resources and to allow resource users to match their context numbers to those of providers.

Additional Problems Addressed by HomePnP Many other network requirements are dealt with in the specification (currently included or in the works) to solve more complex network issues. Security and privacy—Several levels of message and data security commensurate with the protection needed and the complexity that can be afforded by an application. Scheduling—A common way to express device operation schedules so they use a similar data structure and can be edited in a uniform way. Locking—The capability to “lock” a device function by one product to prevent interference by other products during an operation or interaction. User Interface—A common user interface model so that users see a consistent interface with the subsystems in the home, and applications can take advantage of any available interface.


CHAPTER

9

Product Development


228

Chapter Nine This chapter builds on the information presented in the previous chapters to outline how to create CEBus-compliant products. An example product development process is given for a typical networked product, emphasizing the requirements for network interoperation with other products. A CEBus-compliant product developer has complete freedom to implement the necessary CEBus network interface in any way that the developer chooses. Products may be developed using any combination of hardware and software, designed from “scratch” or purchased from other vendors. This implementation freedom gives the designer plenty of room to innovate—which is intentional—but also provides the freedom to make numerous mistakes. Care must be taken to ensure correct implementation of the standard and to correctly use network resources. This chapter should clarify many of the product design decisions necessary to successfully make networked products.

Design Considerations for Networked Products Many of the problems encountered by developers of new CEBus-compliant products are not technical but typically deal with proper network operation. While the problems associated with making a product communicate over a residential network are not trivial, they are straightforward. The CEBus physical layers and protocol solve the basic problem of getting two products on the network to communicate. The more difficult problem is understanding what to do with the network capability: what resources to use in other products; what products to control; and what resources to make available to other products. The designer of a networked interoperable product, especially a consumer product, must make several decisions above and beyond the traditional ones of cost/feature trade-offs, market size, and service. The designer must consider at least the following: How the product will be used with other products: what resources can it use in other products, and what resources can it make available to other products Network installation issues: how customers or dealers will install the product successfully

Product Development

229

Acquiring network addresses: Is the intelligence to do this in the product or is it assumed to be in another product? Product security: preventing unauthorized “user” access to product data or operation The network medium to use must also be considered. Because the designer of CEBus products has a choice of at least five media, selecting the best medium is a trade-off of medium availability, transceiver cost, installation ease, and power needs. The following sections consider some of these issues in more detail.

Security Product security is a concern for any networked product. The designer must consider the implications of providing access to product information and control from other products and users, potentially in another house. This influences what functions in a product are accessible by Context implementation. For example, take the operation of a hypothetical CEBus-compliant Black and Decker iron. The iron uses the power line as a network medium. While there is a CEBus Context that might be used to allow the iron to be controlled over the network (Context 72, Water Heating) its implementation in the iron is unlikely. This Context would allow the iron to be turned on and its temperature set by another product. If operated at the wrong time, even accidentally, this could result in a fire if the iron was unattended. From a practical viewpoint, there is little to be gained by controlling an iron from another product anyway. In reality, Black and Decker chose not to implement the heating Context, but to implement the Security Control Context (63) in the product. This Context (Figure 9.1) contains an object (Partition Status) that will receive the arming state of any CEBus-compliant security system in the house. If the system is armed in the “away” mode—meaning that the interior of the home is armed and no one is home—then it will broadcast the state to all products containing Context 63. This will be received by the Context in the iron, and the iron can use this information to turn off. That is, the iron will automatically turn off whenever the house is unoccupied; a more appropriate and safe use of the technology. For more sensitive network transactions, such as setting the electric meter rates, arming or disarming the security system, it is appropriate to use the message authentication algorithm described in Chapter 6. The software overhead of this algorithm is significant and the designer must

230

Chapter Nine

Figure 9.1 Portion of Security Partition Control Context. The Partition Status object monitors the arming status of any security system.

weigh the trade-offs of increased security verses potentially increased cost. Another consideration of message security is the requirement that the transmitter of the message must have the necessary keys and encoding algorithm. This means that both the transmitting node and the receiving node must be built by the same manufacturer, or the manufacturers must agree (privately and secretly) on how the key information is propagated at installation. While message authentication provides a high degree of security, its implementation carries a significant software burden and should be used only where warranted.

Addressing A product manufacturer must decide how its products will acquire a network system and node address when installed. The need for an address is a new requirement for consumer products. Consumers are not familiar with the concept, technique, or the need. If address self-acquisition is used, some means must be incorporated into the product to make the product hail for a new system and node address, or to use the address propagation algorithm. This might be an onscreen display, a separate button, or some other technique. Manufacturers are understandably reluctant to add a button or to switch to a product that may only be used once when the product is installed. They are more likely to use existing user interface elements in some unique way. The trade-off is potential consumer confusion versus cost savings. Whatever technique is used, it must be explained to the consumer and it must be easy for the consumer to accomplish. Some form of user feedback to indicate when address acquisition was successful must also be provided. Using directed acquisition is potentially simpler but requires that the user already have, or purchase, a device to access and address the node. There is no standardized way—or industry-accepted way—to do directed

Product Development

231

acquisition. This may change as more manufacturers leverage off configuration nodes from other manufacturers.

Interoperability There are two general types of product interoperability to consider when developing a new product: intraproduct interoperability and interproduct interoperability. The concept is illustrated in Figure 9.2. The primary consideration of product designers is interproduct interoperability, or interoperability across industry categories. This offers the consumer the greatest potential gain in added convenience, safety, flexibility, and enhanced features. This type of interoperability is generally concerned with information to and from other products rather than product control. Each Context group deals with interproduct communications by providing one or more Contexts that specifically provide status and possibly control information to and from one or more contexts in other industry groups. This allows monitoring and control of product subsystems on a whole-house basis. Of secondary consideration is intraproduct interoperability, or interoperability within a product category. This is the kind of operation that most manufacturers think of when they consider network operation. This deals with status and control from, for example, the thermostat to the heating/cooling equipment, the light switch to the light, the security sensor to the security panel, and so on. Each existing Context group contains the necessary Contexts to enable interoperation of almost all

Figure 9.2 The basic model of inter- and intraproduct category interoperability.

232

Chapter Nine types of equipment and/or functions within a product category. This allows the details of subsystem component operation to be handled within the subsystem, and high-level subsystem operation to be controlled and monitored by other product categories. Most Contexts in a product category are for intraproduct communications.

Partitioning of Processing Tasks Product designers must consider the software partitioning of the entire CEBus software “stack” from the low-level physical layer to the product application software, considering the processor time allocation requirements of each layer (see Figure 9.3). The Data Link layer is obviously timing intensive. It must keep up with the arrival and transmission of symbols at 100 s intervals on PL and RF, and must sample incoming symbols on TP, CX, and IR every 25 s. This process cannot be interrupted by application routines. If the application software is process intensive, it may need to be in its own dedicated microcontroller. If it is performing a simple sensor task (monitoring a switch or temperature sensor), it can run in the background when no other layers are processing. The CAL interpreter needs to parse incoming messages fast enough to keep up with arriving messages and to handle reporting conditions within a reasonable period of time. If the protocol and application are sharing the same microcontroller, careful use must be made of interrupt processing to prevent the loss of incoming symbols, and to keep transmission timing of outgoing symbols accurate. If the protocol software is divided between two or more processors, then the optimum place for division is between the Data Link and Network layers, and between CAL and the application. If an application does not require fast processor response and requires only minimum application software overhead—a light switch or thermostat, for example—a single microcontroller can implement all software functions (Figure 9.4). The only additional IC required is a transceiver (for PL or RF). An application that uses TP, IR, or CX might only need the microcontroller and might rely on discrete components to implement the transceiver function. The example of the light switch is typical of implementations in products that do not use a microcontroller in their existing, stand-alone design. It must bear the highest overhead for conversion to network operation. Existing microcontrollers, such as the Motorola 68HC705 series, can easily handle the protocol and a small application in such products.

Product Development

233

Figure 9.3 Typical partitioning of the protocol stack. The DLL is the most time-critical layer, while the application and I/O routines are potentially the most process intensive.

Figure 9.4 A light switch is typical of applications that contain no existing microcontroller. An added microcontroller must implement all protocol and application code.

Products that already use a small microcontroller/processor may choose to implement the upper layers of the protocol in the existing processor and add an inexpensive dedicated microcontroller (for example, 6805, 8051) to handle the Data Link layer (Figure 9.5). The DLL chip interrupts the higher layers whenever a complete packet has been successfully received and needs processing. Likewise, the DLL chip can provide an interrupt upon successful completion of packet transmission. The Intellon Corp. makes a special version of their PL transceiver chip that integrates the DLL with the transceiver for a one-chip solution to this implementation option.

234

Chapter Nine

Figure 9.5 Products with an existing microcontroller may choose to implement the higher-level layers in the existing processor and add a Data Link microcontroller to handle the fast-response tasks of the DLL.

Products that incorporate more complex microprocessors have the option of implementing the whole software stack, including the Data Link layer, in the existing processor (Figure 9.6). If the processor is capable of keeping up with 100 s interrupts, this becomes an attractive implementation because no additional microcontroller is required.

Creating CEBus Applications: An Overview This section describes how to create a simple CEBus application. It illustrates the design considerations discussed previously. The process consists of defining the needs of the application, the hardware to be used, and the control functions to be implemented. The following steps are straightforward. 1. Design the basic operation of the product including hardware and software requirements. 2. Determine what parts of the product should be accessible from other devices on the network, considering the potential benefit vs. potential problems. 3. Determine what information (status, state, values) will be received from or sent to other products. What resources in other products will be beneficial and add value, and what resources in the product under design will be made available to other products. 4. Choose a set of Contexts that best represents the function of the product, and that provide interoperability with other industry groups.

Product Development

235

Figure 9.6 Products with existing microprocessors may choose to add all of the necessary software in the existing processor memory.

5. Select the minimum working set of objects in each Context necessary to meet the basic operation, and provide information to other products. 6. Determine what output objects need to generate messages, and set the IVs accordingly, using network broadcast whenever possible. 7. Test the model in a development system by observing behavior of the model while sending and receiving message with other products. 8. Compile the Context data structure with the application code and protocol stack. 9. Download the compiled Context data structures, the CAL Interpreter, and the I/O routines to the target hardware environment. 10. Test the application by monitoring message traffic against application operation.

The Design Problem This section steps through the design of a typical consumer product; discusses the design process emphasizing network requirements; illustrates how the product is built; and demonstrates the benefits of interoperation with other products. The product used for the example is a residential thermostat. The thermostat is easy to understand and simple in operation, yet makes an interesting design example. Product Requirements Our CEBus-compliant thermostat will perform most of the tasks found in conventional thermostats plus some additional functions only possible with CEBus. The thermostat can be retrofitted to an existing heating/cooling system, or it can be used over the CEBus network to operate networked heating/cooling equipment. The basic requirements are straightforward.

236

Chapter Nine It will control one heating and/or cooling source for one zone (gas/electric/oil furnace, forced air or convection, air conditioner, heat pump). It will maintain the desired setpoint (set manually at the thermostat, or by another networked product) based on the temperature measured at the thermostat. It can control the system air circulation fan (if equipped). Fan control modes are: ON, AUTO. It will measure the air temperature electronically at the thermostat. It will display the outside temperature if available. It has an LCD display to show the inside temperature, the outside temperature, the current setpoint, and configuration information. The desired temperature setpoint, entered at the thermostat, will be used to set the heating setting and cooling setting as appropriate for heating-only equipment, cooling-only equipment, or both (heat pump). To save energy, the thermostat can use the arming state of a CEBus-compliant security system (if available) to set back or set forward the desired temperature. Network Requirements The operating mode, fan control, and heating and cooling setpoint can be set or read over the network by any other CEBus-compliant product. The inside temperature measured by the thermostat can be broadcast to other networked products. The outside temperature will be received and displayed if available. The arming state of an existing security system can be received. System variables, such as the thermostat system and node address, serial number, and Context list, can be set and/or read as necessary. The product will use self-acquisition techniques to acquire a system and node address. Design Requirements The thermostat design requirements will be kept as simple as possible. It will be based on a simple 8-bit microcontroller.

Product Development

237

All software (protocol, CAL Interpreter, and application software) will be contained in on-chip memory if possible. Nonvolatile memory will be required to store the system and node address, and two group addresses, plus the addresses of other nodes (HVAC equipment) to receive generated messages. It will be equipped with a conventional screw-terminal interface to conventional equipment wiring for retrofit installation. It can use either the power line or twisted-pair (but not both) to communicate because either medium can supply operating power. The Hardware Figure 9.7 is a simple block diagram of the thermostat that meets the functional requirements. The microcontroller has sufficient OTP or FLASH RAM to hold the software; RAM to hold a limited amount of variables; I/O ports to interface to the user display and controls; a triac or relay interface to equipment wiring; a serial or parallel port for the temperature sensor (internal or external A/D function); and parallel I/O lines for the network transceiver. The processor needs to be fast enough to keep up with incoming and outgoing packets at 10 Kbps and still have idle time available for temperature control algorithms and the user interface. Because the temperature control software is not time critical, this should be no problem with a microcontroller clock speed of 8 MHz or more. The user interface consists of an LCD display, setpoint up/down buttons, a fan switch, and a system on/off switch. The thermostat obtains its power from the network (either 120V AC or 10—15V DC from twistedpair) depending on which network interface is used. The Software Figure 9.8 is a block diagram of the software structure. The product contains the necessary application software to handle the user interface and control calculations. As a CEBus-networked product, it must contain the interface to the network variables and contain the protocol code, including a simple CAL Interpreter. The processor’s time is allocated to the software in the following priority: 1. Process incoming packets and generate necessary acknowledgments 2. Handle user inputs 3. Handle outgoing packet transmission 4. Execute background control algorithm

238

Chapter Nine

Figure 9.7 Hardware block diagram of the thermostat used for the design example. The design can use either the PL or TP as a network medium.

Figure 9.8 Software block diagram of the thermostat.

The network design of this product (the choice of CAL Context data structures) is based on the existing CEBus HVAC contexts. Figure 9.9 shows a portion of the Context interconnect diagram for the contexts that will be used for the thermostat implementation. The Context interconnect diagram defines how this product will work with other products on the network, what information is available from

Product Development

239

other products, and what information is provided by our thermostat. The Contexts to be implemented in the thermostat are shown in the center. The Environmental Zone Context (40) is intended to be implemented in devices such as thermostats that control heating/air conditioning equipment. This is the main Context in our design. Only a few of the 15 objects in the Context will be needed for network operation of the thermostat. The Environmental Zone Control (43) Context is used in products in other product categories (such as a TV) that want to interoperate with a thermostat. The objects in this Context bind to equivalent objects in Context 40.

Figure 9.10 Graphical representation of Context data structure for thermostat product. The Context Control object in each Context is not shown.

240

Chapter Nine The Environmental Zone Equipment (44) Context is implemented in heating or cooling equipment in the same product category, such as a furnace, heat pump, or base-board heater. The objects in this Context also bind to equivalent objects in Context 40. The Environmental Sensor (41) Context contains the Inside Temperature object. This object holds the current value of the measured temperature in degrees Fahrenheit. In addition to being used internally, the value will be broadcast to any Environmental Status (42) Contexts in the home, such as in a PC or TV, for onscreen viewing. The Environmental Status (42) Context will use the one Outside Temperature object. This object will receive any outside temperature broadcast by an optionally installed outside temperature sensor. If there is no broadcast value, the object will use a default value to indicate no valid value has been received. The received value, besides being displayed for the user, can be used by the thermostat application software to anticipate heating and cooling requirements. The Security Partition Control (62) Context is part of the Security Context group. This Context is intended to be in any product that wants to control or monitor the status of the house security system. The Partition Status object is used to monitor the arming state of the security system (broadcast from the Security Partition Context (62), Partition State object). The received value is used to alter the settings of the thermostat for more efficient operation. The binding between Contexts 43 and 40 and between Contexts 62 and 63 provide interproduct interoperability. The binding between Contexts 44 and 40 and between Contexts 41 and 42 provide intraproduct interoperability. Context 40 will contain only five of the objects available in that Context (in addition to the Context Control object): the Zone Mode, the Zone Operating State, the Fan Control, the Heat Setting, and the Cooling Setting objects, because this is all that the thermostat is capable of doing. The Zone Mode object (in Context 40) is a network input/output object that sets the operating mode for the zone: OFF (0), AUTO (1), HEAT (2), and COOL (4). It can be set locally by application software as a result of input from the user interface, or from Context 43. The Zone Operating State is a network output object that contains a value computed by the thermostat—OFF (0), HEAT ON (1), or COOLING ON (2)—based on the Zone Mode, the desired temperature, and the Inside Temperature. This value is transmitted to the equivalent object in Context 44 to control the heating/cooling equipment accordingly. The Fan Control object is a binary switch class, network input/output object that can be set from the thermostat or by a message from the Fan Control object in Context 43. Its value is binary: AUTO (0) or ON (1).

Product Development

241

The Heat Setting and Cooling Setting objects can be set over the network from Context 43, or they can be set locally by the thermostat. If the desired temperature on the thermostat is changed by user input, new values for the Heat Settings and Cooling Settings objects are computed.1 The current_value of the Heating Setting is set to the desired temperature dt (delta temperature), and the Cooling Setting is set to the desired temperature dt, where dt is a temperature offset established by the user or fixed in the software (usually 1 to 3 degrees). If the Partition Status object in Context 63 receives a value that indicates that the security system is armed in the AWAY mode, meaning the house is unoccupied, then the thermostat will adjust its heating/cooling setting by a changing dt to a larger value (usually 3 to 5 degrees). When the object value is anything other than AWAY, dt is reset to its original value. Figure 9.10 shows the resultant CAL Context/object data structure. Five contexts are used: Universal, Environmental Zone, Environmental Sensor, Environmental Status, and Security Partition Control. Implementation requires creating a small data structure of variables to hold the necessary IVs used in each object. This data structure is typically implemented as a set of C structures; one to contain the implemented Context numbers with a pointer to each object structure, and the others to hold the object variables. Every CEBus node contains a Universal Context (00), Node Control object (class 01) that contains the node’s system, node, and group addresses, as well as the context_list. Our implementation will also contain a serial number, product class, group address, and several other variables for field addressing. The product_class (23) identifies this product as a thermostat. Typical values are shown where applicable for each implemented IV in each implemented object. The Zone State, Fan Control, and Inside Temperature objects will bind to other input objects, and will therefore contain the reporting IVs necessary to generate report messages to other contexts. Each of their report_condition IVs contains C delta 1 (when C changes by 1). The report_header IVs contain the destination Context ID/object number, followed by the setValue C method and IV, followed by the ESCAPE token. The reporting_address is shown as SA,0000, that is, the system address and the broadcast node address (0000). The system address will be determined when the thermostat is installed. For installations in which there is only one heating/cooling zone, using the broadcast node address works fine. If there are multiple zones and the thermostat 1

The desired temperature setpoint entered at the thermostat is used to calculate an actual heating and cooling setpoint stored in the objects.

242

Chapter Nine

Figure 9.10 Graphical representation of Context data structure for thermostat product. The Context Control object in each Context is not shown.

needs to be part of the equipment in one zone only, a valid node address must be acquired. Address Configuration The thermostat will acquire its system and node address by using either address self-acquisition or directed acquisition. Self-acquisition will be accomplished using the “address configuration” button on the thermostat. This is a combination momentary

243

Product Development

push-button and LED. The button is used to perform all the tasks necessary to have the thermostat get a new system and node address, acquire an existing system address from another node in the house, or propagate its acquired system address to another node. When the thermostat is first installed, it is unconfigured; the configured IV is FALSE and its system_address and node_address IVs contain zero. Whenever the configured IV is FALSE, the address configuration button LED blinks at a 1 second rate (similar to a flashing 12:00). When the configured IV is TRUE (and the thermostat is not executing address configuration software) the LED is out. During address configuration, the LED is used to indicate the state of the configuration process (success, waiting, and so on). The following table itemizes the use of the button/LED to perform the various address configuration tasks.

Desired Event

User Action

LED indication

Get new system and node address (first device in home).

Press and hold button at least 3 seconds.

If successful, blinks twice quickly and goes out. Otherwise continues to blink at 1 second rate.

Enter address acquisition Slave mode. Get a system address from another node.

Press button once.

Blinks rapidly. When configured by Master, LED goes out. If process times out unsuccessfully, LED returns to 1 second rate.

Enter address acquisition Master mode. Propagate system address to another node.

Press button twice (within 1 second).

If config-master is acquired, LED remains on steady If config master is in use, LED remains out. Remains on steady until config. master times out.

As an aid to directed acquisition, anytime the thermostat enters the address acquisition Slave mode, it broadcasts the contents of its serial_# IV using the following message syntax: 00 F4 F6 <serial number>

This broadcasts to Context 00 a data value containing the serial number. This may be used by an existing address configuration device (such as a PC), to then send a valid system and node address using the serial number to condition the command.

244

Chapter Nine CAL Interpreter Design The CAL Interpreter used in the thermostat is a simple parser/interpreter The Interpreter has two tasks to perform: 1. Parse incoming messages and update the data structure based on the message. 2. Scan the data structure to determine whether a reporting condition has been met, and generate a reporting message. This task is performed in the background when there are no incoming messages to process. Parsing incoming messages consists of performing a lookup on the target Context/object to determine whether it is implemented. If it is not implemented, an error message is returned. If it is implemented, the method is performed on the argument IV. If the method generates a returned value (from a getValue or getArray method), then the value is returned in a reply message. Regardless, the result of the method (error or success) is returned to the MT Element. The application software also has access to the Context data structure (typically through a call to the CAL Interpreter), to write updated values or to look for any new, network-updated values. Typically, a flag bit is used in the object data structure to indicate a new value.

Getting It Built The easiest way to build this product is to use one of the CEBus development system products available. CEBench from the Intellon Corp. in Florida, and CEBox and CELab from Domosys Lab Corp. in Quebec, are the most complete development system products. CEBench is Motorola 6811 series based and CELab is 8051 based. B oth systems run on PC/Windows and provide a library of CEBus Contexts and objects for most industries. They supply a portion of the protocol and CAL Interpreter that can be linked to and downloaded with customer-developed application code. While these systems are loaded with nice-to-haves, development can be done with any existing microcontroller development system. The source code for the CEBus protocol and CAL Interpreter can be purchased, modified for the features desired, and combined with application code using an existing development system. Other tools, such as CEBus power line ISA cards, serial modems, network analyzers, transceivers, and prototype boards, are also available. After the product is prototyped, its network operation can be tested by using

Product Development

245

the tools in the development systems, or by using network monitoring software and a PC modem. Because the Data Link layer code is the most time critical, it is available ROMed into several small microcontrollers (such as the Motorola 6805). This might be a good alternative for a product with an existing microprocessor that is tied up with fast response-time requirements. Intellon Corp. makes an IC with the Data Link layer and power line transceiver on one chip. Domosys makes a perfect IC (CEWay) for our thermostat. It has an 8051 application processor, a separate on-chip protocol processor, a power-line transceiver, RAM, NVRAM, OTP EPROM, LCD driver, A/D converter, I/O ports, and so on, on one chip—nothing else to buy!

Product Benefits So what has been gained by networking what was previously a standalone product? Our networked thermostat has many advantages over a similar conventional product. It can be easily installed anywhere, communicating over an existing medium and obtaining temperature readings from a remote temperature sensor. It can provide the status of the heating system and the temperature to other products. It can use information from other products (remote temperature, outside temperature, security state, and the like), providing more efficient and economical operation. It can be operated by (and from) any other CEBus-compliant product. It can operate any manufacturer’s CEBus-compliant heating equipment. This thermostat is a typical “transition” product. It contains both a conventional user interface as well as a network interface. As networked consumer products become more prevalent—as CEBus-compliant TVs and PCs enter the market—future versions of this thermostat can eliminate the user interface and conventional HVAC wiring interface, greatly lowering cost. In fact, the conventional thermostat will likely disappear altogether. There will only be networked temperature sensors; the computation being absorbed by the heating equipment or a PC.

246

Chapter Nine

Minimum Requirements— Deciding What to Implement As this book has stated many times, CEBus is intended to be extended and enhanced. As a result, the standard has many protocol and language features that are extensions of the minimum required implementation. The intent was, whenever possible, to weigh the cost of a feature (such as authentication) against the potential uses and consequences of having the feature required rather than optional. The test for requiring a protocol or CAL service is usually the resulting impact on a light switch (the lowest form of CEBus life). If it is required, then a light switch must have it. For this reason, many of the capabilities of the CEBus protocol and CAL are optional, including certain contexts, objects, and IVs. However, a basic set of core requirements must be met in every node, including the light switch. The basic set of minimum requirements is given in the following list by protocol layer.

Data Link Layer Any CEBus-compliant node Data Link layer must perform the following tasks: Receive all of the DL packet types: Ack_request, Ack, Addr_ack_request, Addr_ack, Unack_request, Addr_unack_request, and Fail. Reject duplicate packets of type Ack_request, Addr_ack_request, or Addr_unack_request. Rejection of Addr_ack_request, and Addr_unack_request requires that at least one address/sequence number association be maintained. Respond to Ack_request with an Ack or Fail, and to an Addr_ack_request with an Addr_ack that contains a success or failure code. Generate a Fail or Addr_ack (failure) response if a packet was received intact with the correct packet check sequence and address, but cannot be processed for any reason. Generate the necessary Ack or Addr_ack if a packet is received correctly requesting Ack service (Ack_request or Addr_ack_request).

Product Development

247

Maintain and supply the system and node address if requested from a higher layer. Recognize own system, node, and group addresses, and the broadcast system and node address (0000). System, node, and any used group address must be retained during power off.

Network Layer The network layer should perform the following tasks. Must send and correctly receive and parse a nonextended service, nonprivileged, 1-byte NPDU header with the FP, Ext, AM, B2, and B1 bits cleared. Must be capable of receiving packets with an NPDU header of more than 1 byte under the following conditions: 1. If AM 1, then the allowed media byte is parsed but ignored 2. If BR1 or BR2 1, then the address bytes are parsed but ignored Generate a proper ID_Packet when first configured (addresses installed), upon power-up after being configured, or after the system or unit address changes. Generate a proper ID_Packet if a request_ID NPDU header is received.

Application Layer Following are tasks of the application layer. Shall receive and process a nonsecure 1-byte header with the following APDU types: implicit_invoke, explicit_invoke, conditional_invoke, and explicit_retry. Shall reject duplicate messages for any of the above types by maintaining at least one invoke ID/source address association. Shall generate the necessary Result response with the correct invoke ID, in response to explicit_invoke or explicit_retry, or conditional_invoke if a result condition exists.

248

Chapter Nine Shall generate the necessary Reject response with the correct invoke ID and reject_reason, in response to explicit_invoke or explicit_retry for any of the listed Message Transfer reject reasons. Shall use an explicit_invoke or explicit_retry to return the requested Instance Variable value when required by certain CAL messages (getValue, getArray). Shall include a source address in the packet when required by explicit_invoke, explicit_retry, and conditional_invoke

CAL General

A node shall respond to a hail from another device for its own node or system address (see Methods below) anytime a device is connected and powered (regardless of any IV state, including on_offline). Syntax

Parser shall handle at least a single command in the message field of the packet (context ID, object, method, optional argument). The full context ID syntax shall be parsed. Object class bytes (used with object number) shall be parsed. Methods

A device shall be able to parse and perform a minimum set of methods on implemented object IVs. The minimum set is: setON, setOFF, getValue, setValue, on boolean IV’s getValue, setValue, on numeric IVs getValue, setValue, on character IVs getArray, setArray on data IVs with the following limits: getArray IV to retrieve all of the IV setArray IV DELIMITER DELIMITER data Inherit, disinherit on resource IVs, if implemented. Exit method followed by an argument The IF syntax with the following format: IF IV.EQ.Value BEGIN simple method END

Product Development

249

IVs

All required IVs in an object shall be implemented. If reporting is supported in the object, then the reporting_condition, report_header, and report_address IV shall be implemented. Objects

All required objects in a Context shall be implemented. The Context Control object shall be implemented in every Context and the object_list IV shall be supported. Contexts

The Universal Context shall be implemented and must contain the Node Control object. Context number usage shall be supported (A0 to DF) followed by the Context class if multiple contexts of the same class are used. Errors

An error shall always be returned in response to an explicit_invoke if the requested message cannot be executed properly.

Certification (ANSI/EIA-633) Concurrent with the development of EIA-600, the EIA and the CEBus Committee set about the task of developing a rigorous test procedure for products implementing CEBus. This “certification” document was released in the late 1990s as EIA-633. EIA-633 is structured almost identically to EIA-600 on a chapter-by-chapter basis to provide a complete test procedure for each layer of the protocol. A test procedure is outlined for each of the possible physical layers (PL, RF, TP, CS, and IR) providing specifications of such parameters as interference levels and signal strengths. Complete test procedures are given for the nonphysical layers, including the CAL Interpreter, to make sure a given implementation meets all the required functions of each layer including timing requirements and current error responses. Test parameters are also listed for optional services such as Network layer segmented service.

250

Chapter Nine The intent of EIA-600 is to enable a product developer to perform all the necessary tests on a product to determine whether it will work reliably with other manufacturers’ CEBus-compliant products on the same network without having to resort to a trial-and-error process in the market. If a product passes the tests described in EIA-633, it will work with other products that also pass the tests.

PlugLab In 1996, the CEBus Industry Council began working with Purdue University to form an independent testing facility for CEBus- and HomePnP-compliant products. The facility was designed to provide complete facilities to test CEBus-compliant products to EIA-633, and HomePnPcompliant products to the HomePnP Specification. The facility is now an official department of IUPUI (Indiana University/Purdue University in Indianapolis) and is officially called PlugLab. Its role is to provide testing and/or certification services for products that use the CEBus protocol and/or that implement the HomePnP specification. HomePnP can be tested independently from the transport protocol. The facility also provides testing and certification services for other home-related network technologies, including HomePNA and HomeRF.

APPENDIX A OBJECT DEFINITIONS This appendix contains a list of the CAL object tables and reference data regarding their proper use. The tables give a definition of the CEBus CAL Objects. All usable objects are given (excluding the Node Control and Context Control objects). The tables describe the object class, the typical object binding, and the IVs used in the object.

Common Object IV Labels Many of the object definitions use a set of reserved letters, indicated by uppercase, to label commonly used IVs that occur in most objects. The remaining IVs in each object, unique only within the object, are labeled using lowercase letters. The ASCII code of an IV is the data transmitted in a CAL Method to indicate a particular IV. The reserved, uppercase letters of some IVs are listed below.

Label

IV Name

IV Description

R

reporting_condition

Data value (Boolean expression) used to indicate under what condition a report message will be generated.

A

dest_address

Contains the address to which a report should be sent.

H

report_header

Contains the CAL header for reported data.

P

previous_value

Contains the previous value of an IV being reported.

U

units_of_measure

The units of measure identifier that indicates the units of the other IVs in the object. (See Appendix B)

C

current_value

The primary variable of the object. May be named specific to the object such as current_count or current_channel.

M

maximum_value

The maximum value that current_value can assume.

N

minimum_value

The minimum value that current_value can assume.

D

default_value

The default value of the current_value (if any).

S

step_size

The minimum step size of the units of measure of the current_value.

251 Copyright © 2001 by The McGraw-Hill Companies, Inc. Click here for terms of use.

252

Appendix A Label

IV Name

IV Description

F

function_of_position

A data array that stores a text string description of each of the positions of the current_position IV of a switch-type object. Each element of the array is eight characters. The getArray and setArray methods are used to read or write one or more elements of the IV. To read a switch position use the getArray method with set to the desired position and set to 1. The text strings used are given in the Context document in which the switch object is used.

Manufacturer IVs Eight IV labels are protected for use by manufacturers. The labels I, J, K, L, W, X, Y, and Z are not used within any objects. Therefore, these labels may be used in devices for “private” applications in which standardized interoperability is not necessary.

Object Tables The following object tables are given in object class number order.

Object Categories The objects can be generally divided into two categories: general purpose and special purpose. The general purpose objects can be used to model many different control and sensing functions in a broad category of contexts. Ninety-five percent of the objects used in all contexts consist of the following general purpose list: 05 Binary Switch 06 Binary Sensor 07 Analog Control 08 Analog Sensor 09 Multiposition Switch 0A Multiposition Sensor 0B Matrix Switch

253

Appendix A 0C Meter 10 Display 14 Keypad 15 List Memory 16 Data Memory 1C Counter/Timer

The special purpose objects are used only in one or two contexts and model a unique function found only in a few applications. The objects were developed to make implementation of the modeled function easier by providing IVs for the unique features in the objects. 01 Node Control 02 Context Control 03 Data Channel Receiver 04 Data Channel Transmitter 11 Medium Transport 13 Dialer 17 Motor 19 Synthesizer/Tuner 1A Tone Generator 1D Clock Many of the functions of these objects could have been modeled by using combinations of the general purpose objects, but would require keeping track of many IVs across object boundaries.

Table Notes The possible binding shown in each table is the most likely, cross-context binding for the object. Other bindings may be possible if the range and values of the reported IV are restricted. The IV definitions use the following headings L IV Label R/W the Read/Write access of the IV T data type (b boolean, d data, c character, n numeric)

254

Appendix A

255

Appendix A

Object notes: The current_band IV can be set by a setValue method if the message originator knows that the band is not in use, or it can be set with the inherit method. If an inherit method is received, the node will hail for the requested band. If the hail is successful (band is available), ‘C’ assumes the band and a response message (status COMPLETED) is returned. If the band is not available, an error response is returned (resource in use).

256

Appendix A

257

Appendix A

Object notes: current_value can take on any real number value in the range min_value to max_value (if given) to any precision necessary for the application. In practice, all known residential applications can be handled with a range of ±nnn.n.

258

Appendix A

Appendix A

259

260

Appendix A

261

Appendix A

Object notes: The Matrix Switch object should only be used in special applications where the unique feature of the object can not be modeled with two multiposition switches. This object is currently used in only one Context (16 Switch).

262

Appendix A

Appendix A

263

264

Appendix A

Object notes: The Medium Transport object is used (currently) only in the Medium Transport Context to model the operation of a disk or tape medium controller. The values for each IV are given in that Context document.

265

Appendix A

Object notes: The Dialer object is a special-purpose object used to model the operation of a telephone dialing function. It is used in telecommunications contexts (modem, telephone, etc.).

266

Appendix A

Object notes: The Keypad object models a character oriented “input” device (i.e. current_keys is set from the application). It can report a single character or a string of characters. new_key is used if reporting is not used to indicate if the current_key is new and has not been read.

267

Appendix A

Object notes: It is typical to implement the object with only the ‘1’ IV for cases where the object provides a location to hold a single character or string.

268

Appendix A

Object notes: The Data Memory object must be written to directly from application software since there is no output object that generates a data value.

269

Appendix A

Object notes: The Motor object is a special-purpose object that models the operation of a typical motor control function found in motorized appliances. It has not been used in an existing context.

270

Appendix A

Object notes: The Synthesizer/Tuner can model either a tuning function such as found in FM receivers, TVs, etc., or a frequency synthesizer function.

271

Appendix A

Object notes: This object was intended to model an audible alarm function that might be found on clocks, timers, security alarms, etc. Usually, only the alarm_state IV is implemented (the alarm is on or off). The other IVs are for special-purpose audible sound-generating functions where the duty cycle and sound frequency can be varied.

272

Appendix A

273

Appendix A

Object notes: The clock object is used in any device that keeps track of the real time. It should only be used in the Clock Context.


APPENDIX B SAMPLE CONTEXTS This appendix contains sample Context tables for two common Contexts. Not all of the objects in the Contexts may be shown. Consult the Context tables directly for the full Context document. Because most Contexts were still under review when this book was written, these Contexts may have changed. Check with the CIC.

Context 10 (Audio) The Audio Context is part of the A/V industry group and illustrates how typical audio amplifier functions are implemented. Only the first ten objects are listed.


276

Appendix B

Appendix B

277

278

Appendix B

Appendix B

279

280

Appendix B

Context 21 (Light) Context 21 is used in simple light switches or light controllers. It is one of the few Contexts that is intended to bind to itself (that is, another Light Context) since it contains objects for either a device that sends messages to a light, or for a device to receive messages at a light. The Light Context contains the necessary objects for control of a single light/light switch device. It can be used in a light switch device to control a remote light, or in the light, or both. This Context binds with another Context 21.

281

Appendix B

Predefined Values for the feature IV: 0– No feature selected/stop feature 1– Ramp brightness to maximum 2– Ramp brightness to minimum 3– Store ‘C’ to ‘s’ and turn off 4– Store ‘C’ to ‘s’ and ramp off 5– Turn on to ‘s’ brightness level 6– Ramp on to ‘s’ brightness level 7– Turn on to local brightness level 8– Ramp on to local brightness level 9– Set current brightness to minimum 10– Save ‘C’ to ‘s’ and flash brightness level on/off 11–99 Reserved for future use.

282

Appendix B

Appendix B

283


APPENDIX C RESPONSE ERROR CODES The following table gives the error codes returned in a response ASDU when the returned STATUS token is an ERROR (FD). The code number (ASCII string) follows the ERROR token.

Code

Name

Description

0

Unknown Context ID

Referenced context is not in device.

1

Unknown Object ID

Referenced object is not in context.

2

Unknown Method ID

Method cannot be performed on the object.

3

Unknown IV Label

Referenced IV is not implemented in the object

4

Malformed expression

Expression (relational, boolean, argument) not composed correctly.

5

Macro not defined

Attempted to use an undefined macro.

6

Alias not defined

Attempted to use an undefined alias.

7

Syntax error

A syntax error in the message causes a CAL parsing error.

8

Referenced resource in use

The resource hailed for is in use. Usually returned as a result of an exit method.

9

Command Too Complex

Message list too elaborate for device (that is, complex methods nested too deep).

10

Inherit Disabled

Error returned after a request to inherit if device disallowed to inherit resources.

11

Value Out of Range

Attempted to set an IV to a value outside of its allowable range.

12

Bad Argument Type

Attempted to perform an operation on an IV of improper data type.

13

Power Off

Attempted to execute a method while the power IV in the Node Control object was off.

14

Invalid Argument

Attempted to use an argument not accepted by the method.

15

IV Read Only

Attempted to modify a read-only IV.


286

Glossary Code

Name

Description

16

No Default

Tried to use a default value when one did not exist.

17

Cannot Inherit Resource

Error code returned when resource allocation fails and no other error code applies (for example, cannot join any other groups).

18

Precondition Incomplete

Attempted to perform an operation when some required previous operation had not occurred (for example, send a report with dest_addr not set).

19

Application Busy

The device application is occupied and cannot complete the operation.

20

No Support

The requested operation is not supported by the application. This error is used when other errors (Unknown Context, Object, and so on) do not apply.

21

Temp No Support

The requested operation is temporarily not supported by the device.

22

Application Error

Allows the application to return an Error message. Error/Response codes 0−99 are reserved for assignment by the EIA. Values greater than 99 can be used by manufacturers for other (product-specific) indications.

APPENDIX D CEBUS RESOURCES CEBus Industry Council Industry trade organization for companies with a business interest in CEBus. Provides technical and marketing services such as certification, Context generation, and trade show production (CEBus Pavilion). Provides Context documents and related CEBus documentation Phone: 317-545-6239 Internet: www.cebus.org Global Engineering Global Engineering sells the EIA-600 document(s). They are the document production facility for the EIA. Contact: standard sales 800-854-7179 www.global.ins.com



INDEX



A Acknowledged service, 148–154 Addresses/addressing, 157–160 acquiring/keeping, 160 allocation of, 205–207 node address, 158–159 and product design, 230–231, 242–243 self-acquisition, address, 208–212 system address, 157–158 Analog Control object, 257 Analog Sensor object, 258 ANSI/EIA-600, 2, 12–18 brouter communication protocol, 15 CAL, 15, 18 description, 13–14 introduction, 13 node communications protocol, 14–15, 17–18 physical layers, 14, 16–17 router communication protocol, 15 supplemental data, 15 ANSI/EIA-633, 249–250 ANSI/EIA-721, 7, 215–218 ANSI/TIA-570, 43 ANSI/TIA-570A, 3, 71 APDU (see Application Protocol Data Unit) Application layer, 48, 95 CEBus protocol, 98–118 APDU Header, 101–105 and CEBus product application, 98 choice of service, 112–114 conditional_invoke service, 109 explicit_invoke service, 105–108 explicit_retry service, 109–111 Extended (security) Services, 114–118 invoke_ID, 111–112 Reject APDUs, 112

Application layer, CEBus protocol (Cont.): subparts, layer, 100–101 synchronous service, 110, 111 minimum requirements for, 247–248 Application Protocol Data Unit (APDU), 96, 97 Header, APDU, 101–105 Reject APDUs, 112 Application-level interoperability, 31–32 Audio Context, 275–279 Balance Control object, 278 Bass Control object, 278 Context Control object, 275 Input Mode Switch object, 277 Mute Setting object, 279 Processing Switch object, 277 Source Switch object, 276 Treble Control object, 279 Volume Control object, 276 Authentication, 21, 48, 115–117

B Balance Control object (Audio Context), 278 Basic Service APDU Header, 101–103 Bass Control object (Audio Context), 278 Binary Sensor object, 256 Binary Switch object, 256 Boolean variables, 173 Brouters, 58, 59, 121, 122

C Cable TV, 3 Cabling: CX networks, 77–80

291

292

Index Cabling (Cont.): PL networks, 62–64 TP networks, 71–74 CAL (see CEBus Common Application Language) CAL Interpreter, 39, 213–215 in Application layer, 100–101, 112–114 and peer-to-peer communications, 95–96 CEBC (see Consumer Electronic Bus Committee) CEBench, 244 CEBox, 244 CEBus (see Consumer Electronic Bus) CEBus Common Application Language (CAL), 51–52, 164–218 assumptions of, 165–166 and CEBus product model, 37–39 Contexts in, 166–192 Context Control object in, 190 current (list), 167–169 examples of, 185–191 function of, 166 and objects, 167, 169–185 and product capability, 191 specifications for, 191–192 Universal Context, 186–190 in EIA-600, 15, 18 Generic CAL, 215–218 goals of, 164–165 implementation example, 204, 205 Interpreter, CAL. (see CAL Interpreter) messages in, 192–204 command messages, 192–193 generation of, 199–204 and methods, 195–199 non-CAL messages, transporting, 214–215 response messages, 193–195 minimum requirements for, 248–249 objects in, 167, 169–185 binding, object, 180–185 categories of, 179–181 definition of, 169–178

CEBus Common Application Language, objects in (Cont.): function of, 167, 169 implementation of, 178–179 predefined, 170 resource allocation in, 204–212 address allocation, 205–207 node addressing, 207–208 self-acquisition, address, 208–212 CEBus Industry Council (CIC), 7, 33, 191, 287 CEBus protocol, 92–162 addresses in, 157–160 acquiring/keeping addresses, 160 node address, 158–159 system address, 157–158 Application layer of, 98–118 APDU Header, 101–105 CEBus product application vs., 98 choosing service in, 112–114 conditional_invoke service, 109 explicit_invoke service, 105–108 explicit_retry service, 109–111 Extended (security) Services, 114–118 invoke_ID, 111–112 Reject APDUs, 112 subparts of, 100–101 synchronous service, 110, 111 Data Link layer of, 135–154 and CSMA/CDCR, 140–145 end-of-field (EOF) symbol, 139 end-of-packet (EOP) symbol, 139 functions of, 135–136 leading zero suppression, 139–140 packet delivery services in, 145–154 packet format in, 137–139 structure of, 136–137 and Homenet, 92 implementation issues with, 160–162 and layer system management, 161–162 Network layer of, 118–135 Extended Services, 122–130 ID Packets, 133–135

293

Index CEBus protocol, Network layer of (Cont.): IR/RF Packets, 130–134 NPDU Header, 119–122 and OSI model, 92–95 and peer-to-peer node communications, 95–97 Physical layer of, 154–157 and transmission failures, 97–98 CELab, 244 Certification (for CEBus-compliant products), 249–250 Channels, 44–46 control, 44 data, 44 Character string variables, 174 Chirp, 65, 69, 70 CIC (see CEBus Industry Council) Clock object, 273 Cluster control model, 41 Command messages, 192–193 Communication channels, 44–46 Communications-level interoperability, 30–31 Conditional_invoke service, 109 Connectionless service protocols, 40, 41 Consumer Electronic Bus (CEBus): design constraints with, 19–20 development goals of, 6 features of, 2–3 future potential of, 28–29 history of, 2, 6–7 network topology of, 54–62 global network, 61 medium networks, 60 Node 0, 55, 56 reference architecture, 54–55 router/brouter requirements, 56–60 system network, 60, 61 WAN, connection to, 61–62 requirements established for, 5–6 as residential network, 4 resources on, 287 security issues with, 20–21 typical applications for, 26–27 (See also specific headings)

Consumer Electronic Bus Committee (CEBC), 6–7 Context Control object, 190, 191 Audio Context, 275 Light Context, 280 Contexts, 51–52, 166–192 Context Control object in, 190 current (list), 167–169 examples of, 185–191, 275–283 function of, 166 and objects, 167, 169–185 and product capability, 191 specifications for, 191–192 Universal Context, 186–190 Control channels, 44 Control function, 167 Control messages, 25–26 Control models, 41–42 Counter/Timer object, 272 CSMA/CDCR protocol, 97, 140–145 and channel access optimization, 140–141 contention, avoidance of, 141–144 contention, resolution of, 144–145 goal of, 140 retransmission, allowing, 145 Current_value IV, 180 CX (coaxial) network, 76–84 cable specification for, 77–78 connectors for, 79–80 control channel for, 83, 84 data channel for, 81–83 Node 0 distribution device for, 80–81 physical layer implementation for, 83, 84 topology of, 78–79

D Data Channel Bridges, 59–60 Data Channel Receiver, 254 Data Channel Transmitter, 254 Data channels, 44 Data Link layer, 48, 94 CEBus protocol, 135–154 and CSMA/CDCR, 140–145

294

Index Data Link layer, CEBus protocol (Cont.) : end-of-field (EOF) symbol, 139 end-of-packet (EOP) symbol, 139 functions, 135–136 leading zero suppression, 139–140 packet delivery services, 145–154 packet format, 137–139 structure, layer, 136–137 minimum requirements for, 246–247 Data Link Protocol Data Unit (DLPDU), 97 Data Memory object, 268 Data variables, 174–175 Deregulation of communication industry, 3 Dialer object, 265 Display object, 263 Distributed control model, 41 DLPDU (Data Link Protocol Data Unit), 97 Domosys Lab Corp., 244, 245 Duplicate IR/RF packet problem, 121–122, 130–134

E EIA (see Electronics Industries Alliance) Electric meter, 27 Electronics Industries Alliance (EIA), 2, 6, 12 Encryption, 21, 117 End-of-field (EOF) symbol, 139 End-of-packet (EOP) symbol, 139 Error codes (list), 285–286 Explicit_invoke service, 105–108 Explicit_retry service, 109–111 Extended Service APDU Header, 103–105 Extended Services: Application layer, 114–118 authentication, 115–117 encryption, 117

Extended Services (Cont.): Network layer, 122–130 bytes, 123–125 and flow control, 127–130 segmented service example, 125–127 specifying Extended Service, 123

F Fault detector, 28–29 FCS (see Frame Check Sequence) Feature Select object (Light Context), 282 Frame Check Sequence (FCS), 48, 98–99 Frames, 94

G General Electric (GE), 7 Generic CAL, 215–218, 221–222 Global Engineering, 287 Global network, 61

H Hardware, product design and, 237 Homenet, 7, 92 HomePnP, 220–225 and CEBus-compliant products, 249–250 and Generic CAL, 221–222 goals of, 222–223 problems addressed by, 225 self-configuration of, 225 state vector in, 224 House mode, 224 HVAC systems, 41–42

I IBM, 5 ID Packets, 133–135

295

Index INFERIOR state, 49–50, 66–67, 74, 75, 86–87, 144, 155, 156 Input Mode Switch object (Audio Context), 277 Instance variables (IVs), 52, 171–177 active IVs, 172 boolean, 173 character string, 174 current_value IV, 180 data variables, 174–175 labels identifying, 172–173, 251–252 manufacturer-defined, 176, 252 numeric, 173–174 and object instantiation, 176–177 read/write vs. read-only, 173 reporting IVs, 172, 176 required vs. optional, 175 support IVs, 171, 172 volatility of, 175 Intellon Corp., 244, 245 International Standards Organization (ISO), 92 Interoperability, 30–33, 220 application-level, 31–32 communications-level, 30–31 and plug-n-play, 29–30 and product design, 231–232 scenario-level, 33 Invoke_ID, 111–112 ISO (International Standards Organization), 92 IVs (see Instance variables)

K Keypad object, 266 Keys, 21

L Layer system management, 161–162 Leading zero suppression, 139–140 Level Display object (Light Context), 283 Light Context, 280–283 Context Control object, 280

Light Context (Cont.): Feature Select object, 282 Level Display object, 283 Light Level Control object, 281 Light Level Setting object, 282 Light Level Control object (Light Context), 281 Light Level Setting object (Light Context), 282 List Memory object, 267 Locking, 225 LonTalk, 220 LORAN, 65

M MAC sublayer (see Media Access Control sublayer) Macros, 199 Malfunction detector, 28–29 Matrix Switch object, 261 MDS (Medium Dependent Sublayer), 155 Media, wired vs. nonwired, 54 Media Access Control (MAC) sublayer, 136–137 Medium Dependent Sublayer (MDS), 155 Medium networks, 60 Medium Transport object, 264 Message Transfer Element (MT Element), 100, 101, 104–114 conditional_invoke service, 109 explicit_invoke service, 105–108 explicit_retry service, 109–111 invoke_ID, 111–112 and Network layer, 118 Messages, 47–50 authentication/encryption of, 21, 48, 115–117 in CAL, 192–204 command messages, 192–193 generation, message, 199–204 and methods, 195–199 non-CAL messages, transporting, 214–215 response messages, 193–195

296

Index Messages (Cont.): control, 25–26 status, 26 Meter object, 262 Methods, 195–199 macro identifiers in, 199 required vs. optional, 198–199 table, method, 195–198 Microsoft, 5 MoneMinder, 7 Motor object, 269 MT Element (see Message Transfer Element) Multiposition Sensor object, 260 Multiposition Switch object, 259 Mute Setting object (Audio Context), 279

N Network configuration devices, 29 Network control model, 41–42 Network Interface Units (NIUs), 44, 61, 62 Network layer, 48, 94 CEBus protocol, 118–135 Extended Services, 122–130 ID Packets, 133–135 IR/RF Packets, 130–134 NPDU Header, 119–122 minimum requirements for, 247 Network layer management, 95 Network Protocol Data Unit (NPDU), 96, 97, 119–122 brouter addresses, 121 and duplicate IR/RF packet problem, 121–122 routing, 121 Service byte, NL, 119–121 Networked products, benefits of, 24–25 NIUs (see Network Interface Units) Node 0, 55, 56, 80–81 Node address, 158–159 Node addressing, 207–208

Node Control object, 191 Nodes, 37, 38, 42, 49 Nonwired media, 54 NPDU (see Network Protocol Data Unit) Numeric variables, 173–174

O Objects, 51–52, 167, 169–185 binding, object, 180–185 categories of, 179–181 definition of, 169–178 function of, 167, 169 implementation of, 178–179 predefined, 170 tables, object, 252–273 One-way authentication, 116–117 OSI model, 92–95

P Packets, 47–50, 94 in DLL, 145–154 acknowledged service, 148–154 addressed unacknowledged sequence, 147–148 addressed unacknowledged service, 146–147 unacknowledged service, 146 format for, 98–99, 137–139 PL, 67–68 Peer-to-peer communications, 40, 95–97 Personal computer, 27 Physical layer, 42, 93, 94 CEBus protocol, 154–157 CX networks, 83, 84 in EIA-600, 14, 16–17 PL networks, 68–70 RF communication, 87–89 PL (power-line) network, 62–71 CEBus signaling on, 64–67 packet encoding on, 67–68 performance considerations with, 70–71

297

Index PL (power-line) network (Cont.): physical layer implementation for, 68–70 topology of, 62–64 Plug-n-play, 29–30. (See also HomePnP) Predefined objects (CAL), 170 Presentation layer, 94 Processing Switch object (Audio Context), 277 Products, CEBus-compliant, 228–250 benefits of, 24–25, 245 building the product, 244–245 certification for, 249–250 design of, 228–232, 234–244 and address configuration, 242–243 and addressing, 230–231 CAL interpreter, 244 and design requirements, 236–237 hardware, 237, 238 and interoperability, 231–232 and network requirements, 236 and product requirements, 235–236 and security, 229–230 software, 237–242 steps in, 234–235 and HomePnP specification, 249–250 minimum requirements for, 246–249 Application layer, 247–248 CAL, 248–249 Data Link layer, 246–247 Network layer, 247 model for, 36–42 partitioning of processing tasks in, 232–234 Protocol (see CEBus protocol)

R Reject APDUs, 112 Report_address IV, 203–204 Report_condition IV, 201–203 Report_header IV, 203

Reporting IVs, 172, 176 Residential network technology, need for, 3–4 Resource allocation (in CAL), 204–212 address allocation, 205–207 node addressing, 207–208 self-acquisition, address, 208–212 Resource providers, 26 Response ASDUs, 193–195 Response error codes (list), 285–286 RF (radio-frequency) communication, 84–89 encoding for, 85–87 physical layer implementation for, 87–89 spectrum signaling for, 84–85 Routers, 56–59 RS-232, 220

S Scenario-level interoperability, 33 Security issues, 20–21 Application layer, 114–118 and HomePnP, 225 Network layer, 122–130 and product design, 229–230 SES (see Symbol Encoding Sublayer) Session layer, 94 Software, product design and, 237–242 Source Switch object (Audio Context), 276 State vectors, 224 Status messages, 26 Subsystem definitions, 221 SUPERIOR state, 49–50, 66–67, 74, 85–87, 144, 155, 156 Support IVs, 171, 172 Symbol encoding, 48–50 Symbol Encoding Sublayer (SES), 155–157 Synthesizer/Tuner object, 270 System address, 157–158 System guidelines, 221 System network, 60, 61

298

Index

T Telecommunication Industry Association (TIA), 71 Telephone companies, 3 Television, 3, 166 Temperature sensor, 27 TIA (Telecommunication Industry Association), 71 Tight coupling, 223 Time module, plug-in-the-wall, 26–27 Tone Generator object, 271 TP (telephone) network, 71–76 cable/wire specifications, 71–74 control channel for, 74–75 physical layer implementation for, 75–76 Transport layer, 94 Treble Control object (Audio Context), 279 Two-way authentication, 116

U Unit Symbol Time (UST), 50, 67 Universal Context, 186–190 UST (see Unit Symbol Time) Utility companies, 3, 33

V Video interface device, 27 Volume Control object (Audio Context), 276

W “Watch dog,” emergency, 29 Wide Area Networks (WANs), 61–62 Wideband services, 4 Wired media, 54 Wiring (see Cabling)

X X-10 message protocol, 220

About the Author Grayson Evans has been actively involved in home automation and communication network development and training for the past two decades. He is the founder of The Training Department, a company specializing in CEBus and residential technology training. For the past 12 years, he has also been an engineering consultant to the EIA for the development of the CEBus Standard (EIA-600), the AVBus Standard (EIA-140), and related network standards. He was a founding board member of the CEBus Industry Council and provides engineering consulting to the Home Plug & Play Specification of the CIC. He holds a Master’s Degree in Computer Science, and a Bachelor’s Degree in Architecture from the Georgia Institute of Technology.

299

CEBus Demystified: The ANSI EIA 600 User's Guide

The Linux users' guide

Users' Guide to Logic Audio 5 (Users' Guide To...)

LAPACK95 Users' Guide

LINPACK Users' Guide

LINPACK Users' Guide

LAPACK users' guide

LAPACK Users' Guide

Kindle Users Guide

Algebra Demystified : A Self Teaching Guide (Demystified)

Physics Demystified : A Self-Teaching Guide (Demystified)

Physics Demystified : A Self-Teaching Guide (Demystified)

SPSS Base Users Guide 13.0

Oxford Users' Guide to Mathematics

Oxford Users' Guide to Mathematics

SPSS 13.0 Base Users Guide

Windows Home Server Users Guide

ANSI C63.4 - (Revision of ANSI C63.4)

REBOL core 2.3 users guide

The Windows 7 Power Users Guide

Teradata Users Guide: The Ultimate Companion

Język ANSI C

Jezyk ANSI C

600 окончаний

2008_52(600)

The Ansi C Programming Language

The Ansi C Programming Language

Users' Guide to Propellerhead Reason 2

The Ansi C Programming Language

Supersymmetry Demystified: A Self-Teaching Guide (Demystified Series)

600 окончаний

CEBus Demystified: The ANSI EIA 600 User's Guide

The Linux users' guide

Users' Guide to Logic Audio 5 (Users' Guide To...)

LAPACK95 Users' Guide

LINPACK Users' Guide

LINPACK Users' Guide

LAPACK users' guide

LAPACK Users' Guide

Kindle Users Guide

Algebra Demystified : A Self Teaching Guide (Demystified)

Physics Demystified : A Self-Teaching Guide (Demystified)

Physics Demystified : A Self-Teaching Guide (Demystified)

SPSS Base Users Guide 13.0

Oxford Users' Guide to Mathematics

Oxford Users' Guide to Mathematics

SPSS 13.0 Base Users Guide

Windows Home Server Users Guide

ANSI C63.4 - (Revision of ANSI C63.4)

REBOL core 2.3 users guide

The Windows 7 Power Users Guide

Teradata Users Guide: The Ultimate Companion

Język ANSI C

Jezyk ANSI C

600 окончаний

2008_52(600)

The Ansi C Programming Language

The Ansi C Programming Language

Users' Guide to Propellerhead Reason 2

The Ansi C Programming Language

Supersymmetry Demystified: A Self-Teaching Guide (Demystified Series)

600 окончаний

Recommend Documents